---
# System prepended metadata

title: 'The Trailing Finality Layer: A stepping stone to proof of stake in Zcash'

---

![](https://hackmd.io/_uploads/B1Zf2hr9h.png)
Na Electric Coin Co. (ECC), estamos explorando uma transição no Zcash, passando do atual consenso de prova de trabalho (PoW) para um consenso de prova de participação (PoS). Estamos propondo um passo nesse caminho que chamamos de "Trailing Finality Layer" (TFL). Se implementado, isso seria combinado com o consenso existente do Zcash; o protocolo de consenso resultante nesse ponto seria uma combinação de PoW e PoS.

O objetivo geral é permitir a finalidade e PoS no Zcash de maneira minimamente disruptiva. A finalidade é uma garantia de que, uma vez que um bloco seja finalizado, esse bloco e as transações que ele contém não podem ser revertidos. A finalidade pode reduzir atrasos para alguns casos de uso (como tempos de espera de depósitos em exchanges centralizadas) e possibilitar novas melhorias, como pontes mais seguras entre blockchains.

Se a abordagem TFL for adotada pela comunidade do Zcash, ela poderá possibilitar alguns novos casos de uso, como stake de ZEC para ganhar recompensas do protocolo, ao mesmo tempo em que minimiza a interrupção nos casos de uso existentes. A mineração é um exemplo de processo que seria impactado em um modelo híbrido, pois as recompensas de mineração seriam reduzidas enquanto o restante da infraestrutura e processos de mineração permaneceriam inalterados.

Também buscamos minimizar a interrupção na análise da segurança do consenso, pois muitas das propriedades existentes do consenso permanecem intactas em um modelo híbrido.

Ainda estamos começando a definir o projeto desse protocolo híbrido PoW/PoS. Muitos detalhes-chave permanecem como questões em aberto, como detalharemos abaixo. Ao compartilhar nossa abordagem no início deste processo, nosso objetivo é coletar e incorporar feedback conforme avançamos, encontrar colaboradores em potencial e estimular a discussão sobre essa abordagem.

## Envolva-se

Se você estiver interessado em fornecer feedback ou colaborar neste projeto, entre em contato! Uma boa oportunidade para saber mais e participar da conversa é participar (presencialmente ou virtualmente) do workshop "Interactive Design of a Zcash Trailing Finality Layer" que estou liderando na Zcon4. Sinta-se à vontade para me enviar um e-mail em nathan@electriccoin.co, sobre o seu interesse. Estamos buscando contribuidores de diversos backgrounds, incluindo técnicos, de produtos, da comunidade e qualquer usuário do Zcash que queira opinar enquanto a proposta evolui.

### Antecedentes da transição para PoS

Anteriormente, a ECC compartilhou nossa justificativa para acreditar que é do melhor interesse dos usuários atuais e futuros do ZEC realizar a transição do protocolo para prova de participação no post do blog "Should Zcash transition from Proof of Work to Proof of Stake?" e na apresentação "Motivations of Proof of Stake" na Zcon3. Em 2022, publicamos uma visão geral de alto nível de nossa abordagem de prova de participação em pesquisa, um post complementar mais detalhado sobre abordagem, foco e próximos passos, e fizemos uma apresentação na Zcon3 sobre desafios de alto nível no design da prova de participação.

### Um caminho de transição de prova de participação
Nossa visão para a transição para a prova de participação inclui pelo menos duas etapas importantes:

1-Mover o Zcash de seu modelo atual de prova de trabalho para um sistema híbrido PoW/PoS.

2-Mover o Zcash de um sistema híbrido PoW/PoS para uma prova de participação pura.
Nossa principal motivação para propor (pelo menos) duas etapas é minimizar a interrupção da usabilidade, segurança, ecológica e do ecossistema durante cada etapa.

Essa abordagem de transição do PoW para híbrido para PoS foi executada pelo Ethereum com a implantação do Beacon Chain (híbrida) e depois The Merge (PoS puro).

### Metas de design para um sistema híbrido PoW/PoS

A ECC está aprimorando o design do TFL com várias metas em mente, e podemos adicionar mais conforme continuamos a desenvolver esta proposta. Atualmente:

1-Queremos minimizar a interrupção nos casos de uso e na experiência de usuário das carteiras existentes. Por exemplo, nada deve mudar nos fluxos de usuário para armazenar ou transferir fundos, no formato dos endereços, etc.

2-Queremos minimizar a complexidade das análises de segurança, preservando os resultados das análises existentes, quando possível.

3-Queremos permitir novos casos de uso de PoS que permitam aos usuários de carteiras blindadas móveis ganhar um retorno em ZEC delegado.

4-Queremos possibilitar pontes com minimização de confiança e outros benefícios, fornecendo um protocolo com finalidade.

5-Queremos melhorar a modularidade do protocolo de consenso. A modularidade tem vários significados vagamente definidos e relacionados, como a possibilidade de entender algumas propriedades do consenso apenas com o conhecimento de um componente do protocolo e a possibilidade de implementar regras de consenso em componentes de código modular com interfaces limpas.

### O Trailing Finality Layer em resumo

O protocolo híbrido PoW/PoS que imaginamos na ECC é estruturado como o protocolo Zcash NU5 de hoje, com uma nova camada chamada Trailing Finality Layer. A chamamos de camada porque os nós existentes e a maioria de suas lógicas continuarão operando em grande parte como estão, com mudanças mínimas, enquanto grande parte das novas funcionalidades será fornecida por novos componentes e protocolos de rede adicionais.

![](https://hackmd.io/_uploads/SyHcT3r9h.png)

O diagrama à esquerda mostra a rede atual do Zcash, com um detalhe que ilustra como dois nós estão conectados entre si no contexto de toda a rede. À direita, mostra a adição do TFL após a implantação: Cada nó continua tendo seu componente PoW original, mas agora possui um componente adicional TFL. Os componentes PoW ainda se conectam entre si, como antes, e os componentes TFL usam conexões distintas para outros componentes TFL.

Essa nova camada fornece à blockchain uma garantia de finalidade "trailing finality": após a mineração dos blocos, eles podem ser finalizados, o que significa que eles não podem ser revertidos. Essa garantia se estende a qualquer uma das transações dentro dos blocos. É chamada de "trailing" porque essa propriedade de finalidade segue o sistema de mineração PoW "trailing behind it" (atrasado atrás dele).

Como esse design híbrido depende totalmente do PoW para produzir novos blocos, esse protocolo é resistente a interrupções da mesma forma que o Bitcoin ou o Zcash atual — embora a garantia de finalidade possa estagnar, como descreveremos a seguir. Esse paradigma de design tem um histórico teórico e prático: ele é analisado em um artigo de pesquisa chamado "Ebb-and-Flow Protocols", e é o mesmo paradigma usado pelo Ethereum tanto no design híbrido da Beacon chain pré-Merge quanto no Ethereum atual.

### Por que a finalidade é importante
O consenso de prova de trabalho de Nakamoto, introduzido com o Bitcoin e herdado pelo Zcash, oferece finalidade probabilística. Isso significa que a chance de um bloco ser revertido diminui à medida que mais blocos são minerados.

Na nossa visão, o desafio principal com esse tipo de finalidade é que diferentes participantes reagem independentemente a reverter blocos. Por exemplo, a maioria dos participantes espera por reverter 1 bloco (o que é relativamente comum), mas à medida que o tamanho das reversões cresce, surgem três desafios:

1-Reversões maiores se tornam mais raras, então alguns participantes podem não ter um processo ou política para lidar com essa situação.

2-Diferentes participantes podem ter políticas diferentes, então, em caso de uma reversão grande, o ecossistema pode se fragmentar, pois diferentes participantes discordam sobre como se recuperar.

3- Quando contrapartes exigem uma tolerância suficientemente baixa para reversões, suas interações devem incorrer em um atraso substancial.

#### Exemplo: Ponte de minimização de confiança
Para ilustrar esse ponto, considere o caso de uso valioso de uma ponte de minimização de confiança: o ZEC enviado para uma ponte deve ser bloqueado enquanto um número equivalente de tokens proxy é emitido em outra rede.

Se uma reversão reverter um depósito da ponte depois que os tokens proxy são emitidos em outro lugar, aqueles ZEC não estão mais bloqueados na ponte, e os tokens proxy agora não têm lastro. Isso quebra a ancoragem da ponte, e muitos usuários da ponte perderão fundos simultaneamente. Se os projetistas da ponte decidirem exigir um número suficiente de blocos PoW para tornar a probabilidade desse evento astronomicamente pequena, então a emissão dos tokens proxy na outra rede sofrerá um atraso extremamente grande.

#### Exemplo: Depósitos em exchanges
Se um usuário depositar ZEC em uma exchange centralizada, sua conta na exchange é creditada com a quantia apropriada. Se ocorrer uma reversão desse depósito, a contabilidade da exchange terá agora mais passivos em ZEC do que ZEC efetivamente detido.

As exchanges procuram resolver isso exigindo mais blocos PoW para atingir uma probabilidade suficientemente baixa desse evento. No entanto, isso é um ato de equilíbrio: Se uma exchange impõe um atraso de n horas, a probabilidade ainda não é "astronomicamente pequena", então os usuários são prejudicados por n horas e a exchange ainda tem um risco prático de um evento de passivo em excesso.

Além disso, devido ao desafio número 2 acima, diferentes exchanges exigem diferentes atrasos de depósito, o que potencialmente confunde os usuários e coloca as exchanges em competição para assumir mais riscos, aceitando menos confirmações de blocos.

Finalidade
Ao contrário da finalidade probabilística, um protocolo de consenso pode fornecer uma garantia de finalidade. Protocolos que fazem isso garantem que todos os participantes concordem com qual conjunto de blocos e transações são considerados finais. O trade-off é que a finalidade pode falhar em progredir em caso de interrupções na rede. Uma vez que a rede se recupera, a finalidade atrasada pode "alcançar" os blocos PoW que foram produzidos no intervalo.

Na prática, isso significa que, se os participantes estiverem esperando que uma transação se torne final, às vezes eles podem precisar esperar um período arbitrariamente longo.

A finalidade aborda todos os três desafios em certo grau:

1-Os participantes agora não precisam mais antecipar reversões de probabilidades variadas ao projetar seus procedimentos e políticas. Em vez disso, eles devem antecipar o risco de que, às vezes, a finalidade não progrida de forma oportuna.

2-Todos os participantes concordam exatamente com quais blocos e transações são finais, embora possam discordar sobre como reagir se a finalidade estagnar por longos períodos de tempo.

3-Os participantes agora podem confiar na garantia de finalidade para garantir que eles só reajam a algumas transações quando não houver chance de a transação ser revertida.

Nos exemplos acima:

*Uma ponte de minimização de confiança pode confiar na finalidade para emitir tokens proxy. Isso garante que a ponte nunca esteja subcolateralizada. O trade-off é que, enquanto a finalidade estagna, as transferências entre pontes também ficarão estagnadas.

*Todas as exchanges podem usar a mesma garantia de finalidade, para que os usuários possam esperar o mesmo atraso de depósito em todos os lugares (e é provável que seja notavelmente menor do que o status quo). O trade-off é que, se a finalidade estagnar, novos depósitos também ficarão estagnados, embora todas as exchanges se comportem de forma consistente nesse aspecto.

*O resultado final para os usuários é que algumas interações de alto valor (como pontes ou depósitos em exchanges) agora serão mais rápidas e seguras na maior parte do tempo. Às vezes, a finalidade pode estagnar. Quando a finalidade retomar, ela "alcançará" a cadeia PoW, de modo que os usuários que não precisam da garantia de finalidade podem continuar usando esse protocolo híbrido, assim como usam o Zcash hoje, sem serem afetados se a finalidade estagnar.

### Status e questões em aberto

Esta introdução do post aborda a maior parte de nossa pesquisa e desenvolvimento sobre o design do TFL até o momento. Ainda existem muitas questões em aberto que precisam ser resolvidas com a colaboração e contribuição da comunidade do Zcash antes que o design do TFL esteja pronto como uma proposta para uma atualização do Zcash.

Uma lista incompleta de questões que ainda precisam ser resolvidas inclui:

1-Essa abordagem geral é aceitável para a comunidade do Zcash?

2-Como a nova emissão de ZEC será distribuída entre PoW, PoS e qualquer possível sucessor do Fundo de Desenvolvimento? Isso é uma preocupação-chave tanto para os mineradores quanto para potenciais apostadores ou delegadores.

3Como podemos integrar quaisquer outras mudanças nas mecânicas de emissão, como o Fundo de Sustentabilidade do Zcash?

3-Todas as mecânicas contábeis do PoS, como o funcionamento do bonding, como a delegação

4-funciona, quais tipos de penalidades podem ocorrer, atrasos e mecânicas de retirada, etc.

5-Como as operações do PoS interagirão com todas as outras atividades do livro-razão do Zcash, como as pools protegidas, etc.? Isso será uma área-chave para entender como a privacidade e o staking interagem.

6-Deve a ponta da cadeia parar para limitar o intervalo entre o bloco finalizado e a ponta da cadeia?

7-Análises de segurança detalhadas, incluindo segurança econômica, uma análise de caso de captura PoW, captura PoS, segurança de rede (especialmente dadas duas redes/protocolos separados).

8-Como integrar quaisquer mudanças de protocolo TFL com outras mudanças de protocolo propostas de forma segura e oportuna. Exemplos: Zcash Sustainability Fund, Zcash Shielded Assets, esforços de interconexão, integrações Namada, etc.

9-Seleção de um protocolo PoS de finalização específico. Atualmente, estamos concentrando nossos esforços em usar Tendermint e ABCI como uma maneira de prototipar e validar rapidamente o design.

10-Protótipos, testnets, arquitetura de código, etc.

Ao abordarmos as questões abertas acima, especialmente a interação com outros recursos do protocolo e a coordenação com essas equipes em relação ao cronograma, podemos começar a refinar uma linha do tempo de implantação.

### Próximos passos

Nossa próxima etapa para esta iniciativa de P&D da TFL é obter feedback da comunidade sobre este blog, realizar um workshop na Zcon4 e fornecer atualizações de P&D sobre as questões em aberto mencionadas acima.

Enquanto colaboramos com outras equipes de desenvolvimento de protocolo, gostaríamos de criar um cronograma provisório de implantação que incorpore todos os outros esforços de recursos do protocolo, como o Zcash Sustainability Fund, Zcash Shielded Assets e possíveis esforços de ponte entre cadeias.

Por fim, estamos buscando outras equipes ou indivíduos interessados em colaborar neste projeto da TFL. Se você está interessado, por favor, consulte a seção "Envolver-se" acima.