The Trailing Finality Layer: Um trampolim para o Proof of Stake na Zcash
AElectric Coin Co. (ECC) está explorando uma transição na Zcash do atual consenso de Proof of Work (PoW) para um consenso Proof of Stake (PoS). A equipe está propondo uma etapa nesse caminho chamada ‘‘Trailing Finality Layer (TFL).’’ Se implantado, isso seria combinado com o consenso existente da Zcash; o protocolo de consenso resultante nesse ponto seria um híbrido de PoW e PoS.
O objetivo geral é habilitar finalidade e PoS na Zcash de maneira minimamente disruptiva. Finality é uma garantia de que uma vez que um bloco é finalizado, aquele bloco e as transações que ele contém não podem ser revertidas. Finality pode reduzir atrasos para alguns casos de uso (como tempos de espera de depósitos de câmbio centralizados) e permitir novas melhorias, como bridges cross-chain mais seguras.
Se a abordagem TFL for adotada pela comunidade Zcash, ela poderá permitir alguns novos casos de uso, como staking em ZEC para ganhar recompensas de protocolo, minimizando a interrupção dos casos de uso existentes. A mineração é um exemplo de processo que seria impactado em um modelo híbrido, pois as recompensas da mineração seriam reduzidas, enquanto o restante da infraestrutura e dos processos de mineração permaneceriam inalterados.
Também visamos minimizar a interrupção da análise da segurança do consenso, pois muitas das propriedades de consenso existentes permanecem intactas em um modelo híbrido.
Apenas começamos a definir o design deste protocolo híbrido PoW/PoS. Muitos detalhes importantes permanecem em aberto, conforme expandimos abaixo. Ao compartilhar essa abordagem no início deste processo, a ECC pretende coletar e incorporar feedback à medida que avançarem, encontrando colaboradores em potencial e estimulando 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 aprender mais e participar da conversa é participar (pessoalmente ou virtualmente) do workshop Interactive Design of a Zcash Trailing Purpose Layer que foi conduzido na Zcon4. Também fique à vontade para enviar um email a Nate por nathan@electriccoin.co, sobre seu interesse. ECC está procurando colaboradores de uma ampla gama de origens, incluindo técnicos, produtos, comunidade e quaisquer usuários da Zcash que queiram contribuir à medida que a proposta evolui.
PoS | Background de Transição
A ECC compartilhou anteriormente uma justificativa do por que acreditarem que é do melhor interesse dos usuários atuais e futuros fazer essa transição de protocolo para Proof of Stake em um blog no site da Zcash. Em 2022, a ECC publicou uma visão geral de alto nível de nossa abordagem de pesquisa sobre o Proof of Stake, uma postagem complementar mais detalhada sobre essa abordagem, contendo seu foco e próximas etapas, além de elaborarem uma ótima apresentação na Zcon3 sobre desafios de design de alto nível em PoS.
Proof of Stake | Caminhada para Transição
A visão da ECC para uma transição para o Proof of Stake inclui pelo menos dois marcos principais:
Movendo a Zcash de seu modelo atual de Proof of Work para um sistema híbrido PoW/PoS.
Movendo a Zcash de um sistema PoW/PoS híbrido para PoS puro.
A principal motivação para propor (pelo menos) duas etapas é minimizar a interrupção da usabilidade, segurança, proteção e ecossistema durante cada etapa.
Essa abordagem de transição híbrida de PoW para PoS foi executada pela Ethereum com a implantação da Beacon Chain (híbrida) e depois The Merge (PoS puro).
Metas de Design para o Sistema PoW/POS Híbrido
A ECC está refinando o design da TFL com vários objetivos em mente e possivelmente adicionaremos mais à medida que continuamos a desenvolver esta proposta. Atualmente:
Queremos minimizar a interrupção dos casos de uso de carteira e UX existentes. Por exemplo, nada deve mudar nos fluxos do usuário para armazenar ou transferir fundos, o formato dos endereços etc.
Queremos minimizar a complexidade das análises de segurança, preservando os resultados de análises existentes sempre que possível.
Queremos habilitar novos casos de uso de PoS que permitam aos usuários de carteira blindada móvel obter um retorno sobre o ZEC delegado.
Queremos habilitar pontes de confiança minimizada e outros benefícios, fornecendo um protocolo com finalidade.
Queremos melhorar a modularidade do protocolo de consenso. A modularidade tem vários significados vagamente definidos e relacionados, por exemplo, é possível entender algumas propriedades de consenso apenas com o conhecimento de um componente do protocolo e é possível implementar regras de consenso em componentes de código modular com interfaces limpas.
Trailing Finality Layer em Poucas Palavras
O protocolo PoW/PoS híbrido que a ECC vislumbra é estruturado como o protocolo Zcash NU5 de hoje com uma nova camada de finalização final. Nós o descrevemos como uma camada, porque os nós existentes e a maior parte de sua lógica continuarão a operar em grande parte como estão com alterações mínimas, enquanto grande parte da nova funcionalidade será fornecida por novos componentes suplementares e protocolos de rede.
O diagrama à esquerda mostra a rede atual da Zcash, com um detalhe que ilustra como dois nodes estão conectados entre si dentro do contexto de toda a rede. A direita mostra a adição do TFL após a implantação: Cada node continua a ter seu componente PoW original, mas agora possui um componente TFL adicional. Os componentes PoW ainda se conectam entre si, como antes, e os componentes TFL usam conexões distintas com outros componentes TFL.
Essa nova camada fornece a blockchain uma garantia de finalização final: depois que os blocos são minerados, eles podem ser finalizados, o que significa que não podem ser revertidos. Essa garantia se estende a qualquer uma das transações dentro dos blocos. Ele está atrás porque essa propriedade de finalidade segue o sistema de mineração PoW “raste 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 a Zcash atualmente - embora a garantia da Finality possa parar, como descrevemos a seguir.
Por que a Finality é Importante?
O consenso Nakamoto PoW, introduzido com o Bitcoin e herdado pela Zcash, fornece uma finality probabilística. Isso significa que a chance de um bloco ser revertido diminui à medida que mais blocos são extraídos.
Em nossa opinião, o principal desafio com esse tipo de finalidade é que diferentes participantes reagem independentemente a reversões. Por exemplo, provavelmente a maioria dos participantes antecipa reversões de 1 bloco (que são relativamente comuns), mas à medida que o tamanho das reversões aumenta, surgem três:
Diferentes participantes podem ter políticas diferentes, portanto, no caso de uma grande reversão, o ecossistema pode se fragmentar, pois diferentes participantes discordam sobre como se recuperar.
Quando as contrapartes exigem uma tolerância suficientemente baixa para reversões, sua interação deve incorrer em um atraso substancial.
Reversões maiores tornam-se mais raras, então alguns participantes podem não ter um processo ou política para lidar com essa situação
Exemplo: Trusted-Minimized Bridge.
Para esclarecer este ponto, considere o valioso caso de uso de um trusted-minimized bridge: o ZEC enviado para uma bridge deve ser bloqueado enquanto um número equivalente de tokens de proxy é emitido em outra rede.
Se uma reversão reverter um depósito da bridge depois que os tokens de proxy forem emitidos em outro lugar, esses ZEC não estarão mais bloqueados na bridge e os tokens de proxy agora não terão respaldo. Isso quebra o pino da ponte e muitos usuários da ponte perderão fundos simultaneamente. Se os projetistas da ponte decidirem exigir blocos PoW suficientes para tornar a probabilidade desse evento astronomicamente pequena, a emissão dos tokens de proxy na outra rede terá um atraso extremamente grande.
Exemplo: Depositos em Exchanges
Se um usuário depositar ZEC em uma bolsa centralizada, sua conta na bolsa receberá o valor apropriado. Se ocorrer uma reversão desse depósito, a contabilidade da bolsa agora tem mais ZECs do que o ZECs mantidos.
As Exchanges procuram resolver isso exigindo mais blocos PoW para atingir uma probabilidade suficientemente baixa desse evento. No entanto, este é um ato de equilíbrio: se uma troca impõe um atraso de n horas, a probabilidade ainda não é “astronomicamente pequena”, então os usuários são incomodados por n horas e a troca ainda carrega um risco prático de um evento de responsabilidade excessiva.
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 ao aceitar menos confirmações de bloco.
Finality
Em contraste com a finalidade probabilística, um protocolo de consenso pode fornecer uma garantia de finalidade.
Os protocolos que fazem isso garantem que todos os participantes concordem sobre qual conjunto de blocos e transações são finais.
A desvantagem é que a finalidade pode não progredir no caso de interrupções na rede. Uma vez que a rede se recupera, a finalização à direita pode “alcançar” os blocos PoW que foram produzidos nesse ínterim.
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 de tempo arbitrariamente longo.
A Finality aborda todos os três desafios até certo ponto:
Todos os participantes concordam exatamente quais blocos e transações são finais, embora possam discordar sobre como reagir se a finalidade ficar paralisada por longos períodos de tempo.
Os participantes agora podem contar com a garantia de finalização para garantir que só reajam a algumas transações quando não houver chance de a transação ser revertida.
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 em tempo hábil.
Alguns exemplos abaixo:
Todas as exchanges podem usar a mesma garantia de Finality, 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). A desvantagem é que, se a Finality parar, novos depósitos também serão paralisados, embora todas as bolsas se comportem de maneira consistente a esse respeito.
Uma trusted-minimized bridge pode contar com a Finality para emitir tokens de proxy. Isso garante que a bridge nunca será sub-colateralizada. A desvantagem é que, enquanto a Finality parar, as transferências entre as bridges também ficarão paralisadas.
O resultado final para os usuários é que algumas interações de alto valor (como as bridging ou depósitos em Exchanges) agora serão mais rápidas e seguras na maioria das vezes. Às vezes, a Finality pode parar. Quando a finalização recomeçar, ela "alcançará" a cadeia PoW, para que os usuários que não precisam da garantia da Finality para continuar usando este protocolo híbrido, da mesma forma que usam a Zcash hoje, e não serão afetados se a Finality parar.
Status e Perguntas Abertas
Esta introdução de postagem de blog cobre a maior parte de nossa pesquisa e desenvolvimento, até agora, no design do TFL. Ainda há muitos problemas em aberto que precisam ser resolvidos com a colaboração e a contribuição da comunidade Zcash antes que um design TFL esteja pronto como uma proposta para uma atualização da Zcash.
Uma lista incompleta de problemas que ainda precisam ser resolvidos inclui:
1. Essa abordagem geral é aceitável para a comunidade Zcash?
2. Como a nova emissão de ZEC será distribuída entre PoW, PoS e qualquer potencial sucessor do Dev Fund? Esta é uma preocupação fundamental para mineradores e potenciais participantes ou delegadores.
3. Como podemos integrar outras mudanças na mecânica de emissão, como o Fundo de Sustentabilidade Zcash?
4. Toda a mecânica contábil do PoS, como funciona a vinculação, como funciona a delegação, que tipos de cortes podem ocorrer, atrasos e mecânicas de retirada, etc.
5. Como as operações de PoS interagiriam com todas as outras atividades do livro Zcash, como pools blindados, etc.? Esta será uma área chave para entender como a privacidade e as apostas interagem.
6. A ponta da corrente deve parar para limitar o espaço entre o bloco finalizado e a ponta da corrente?
7. Análises de segurança detalhadas, incluindo segurança econômica, uma análise de caso de captura de PoW, captura de PoS, segurança de rede (especialmente considerando dois protocolos/camadas de rede separados).
8. Como podemos garantir que as carteiras blindadas móveis sejam participantes de primeira classe? Por exemplo, podemos garantir que eles possam delegar estaca com segurança e eficiência e gerenciar cargos de delegação de estaca? Isso inclui problemas de UX, como fluxos de interface do usuário de delegação, bem como implementação, como alterações no protocolo lightwalletd.
9. Como integrar quaisquer alterações do protocolo TFL com outras alterações de protocolo propostas de maneira segura e oportuna. Exemplos: Zcash Sustainability Fund, Zcash Shielded Assets, esforços de ponte, integrações Namada, etc.
10. Seleção de um protocolo PoS de finalização específico. Atualmente, estamos nos concentrando em usar o Tendermint e o ABCI como uma forma de prototipar e validar rapidamente o design.
11. Protótipos, testnets, arquitetura de código, etc.
À medida que a ECC aborda as questões acima, especialmente a interação com outros recursos de protocolo e a coordenação com essas equipes no tempo, podemos começar a refinar um cronograma de implantação.
Próximos Passos
ECC divulgou que suas próximas etapas para esta iniciativa de P&D do TFL são obter feedback da comunidade neste blog, realizar um workshop na Zcon4 e produzir atualizações de P&D sobre os problemas em aberto acima.
À medida que a ECC colabora com outras equipes de desenvolvimento de protocolo, mais motivados ficam para criar um cronograma de implantação experimental que incorpore todos os outros esforços de recursos de protocolo, como o Zcash Sustainability Fund, Zcash Shielded Assets e possíveis esforços de bridges entre chains.
Por fim, a ECC está procurando por outras equipes ou indivíduos interessados em colaborar neste projeto TFL.
Em um protocolo PoS de finalização pura, as “stalls” equivalentes são, na verdade, paradas em toda a rede. Um ponto forte desse design híbrido é que o PoW não precisa ser interrompido e, caso contrário, os usuários que não dependem da finality para continuarem usando a rede.