Visão geral da atualização do Etrog
A atualização do Etrog para Polygon zkEVM será concluída em fevereiro de 2024. Esta atualização é a atualização mais significativa desde o lançamento da rede principal do Polygon zkEVM. Ela não apenas completa o suporte para vários contratos pré-compilados no circuito subjacente, mas também otimiza o empacotamento e o mecanismo de geração de blocos da própria cadeia, enquanto reconstrói a própria cadeia. toda a arquitetura do contrato. Ele fornece a base para o ecossistema Polygon CDK subsequente e novos recursos, como AggLayer e Unified Bridge. No geral, esta atualização melhora a compatibilidade entre Polygon zkEVM e Ethereum, traz grandes otimizações para execução de nós e eficiência de consulta e amplia as possibilidades do ecossistema Polygon CDK.
Este artigo analisará profundamente os detalhes técnicos desta atualização da perspectiva do contrato Polygon zkEVM e do código do nó. Ao mesmo tempo, com base no esquema de atualização Rollup de código aberto, ele classificará e concluirá de forma abrangente o caminho de atualização desde o início. versão do CDK Validium para a versão Etrog.
Reconstrução de contrato
Antes da atualização do Etrog, o contrato Polygon zkEVM consistia principalmente em duas partes: o contrato de consenso e o contrato de ponte.
Contrato de consenso
O contrato de consenso registrará a maioria das informações da cadeia de segunda camada, incluindo algumas informações básicas, como ID e versão da cadeia, bem como informações de status em tempo real da cadeia de segunda camada, como registros de envio de lotes e provas. Além disso, para Validium, os dados originais da transação no lote não serão registrados no contrato de consenso, mas serão salvos no grupo de nós DA fora da cadeia por meio de um contrato de comitê adicional. Ao combinar essas informações básicas com informações de status em tempo real, qualquer pessoa pode restaurar completamente o status de uma cadeia de segunda camada.
contrato de ponte
Por outro lado, o contrato de ponte utiliza um conjunto de gerenciamento de estado raiz de saída, registra todos os estados de cadeia cruzada entre a primeira e a segunda camadas e completa o fluxo de ativos entre a primeira e a segunda camadas por meio do modelo Lock/Mint. Os nós filhos que saem da raiz são atualizados simultaneamente pelo contrato de ponte e pelo contrato de consenso. O primeiro mantém o status da transação de depósito da camada um para a camada dois, e o último mantém o status da camada dois para a camada um para retirar por meio do envio. da prova ZK.
A maior mudança trazida pela atualização do Etrog no nível do contrato é a introdução de uma solução multi-rede, usando um conjunto de contratos para apoiar o gerenciamento e manutenção de redes múltiplas de camada 2, em vez da rede original de camada única 2, e contando com na recém-introduzida Ponte Unificada para conectar esses ativos, a interoperabilidade entre redes da camada 2 fornece uma base melhor para o desenvolvimento futuro do ecossistema geral.
Como a estrutura original do contrato não suporta a implantação de múltiplas redes, a atualização do Etrog reconstruiu toda a estrutura do contrato.
O contrato RollupManger é introduzido para gerenciar todas as informações da rede da camada 2;
As estruturas do contrato de ponte e do GlobalExitRoot foram modificadas para permitir que mantenham o status de cadeia cruzada de todas as redes para garantir a interoperabilidade de ativos entre diferentes redes de camada 2.
Consulte a estrutura detalhada do contrato
Para a rede Polygon zkEVM camada 2 executada abaixo da versão Etrog, essas modificações são altamente destrutivas para os dados do contrato, portanto, a solução de atualização correspondente é um grande desafio. Aqui ainda apresentamos os detalhes específicos por trás do plano de atualização do contrato de consenso e do contrato ponte, respectivamente.
Contrato de consenso
A maior mudança na parte do contrato de consenso da atualização do Etrog é a introdução de um novo contrato RollupManager. Como a maioria das operações do contrato, como gerenciamento de permissões na nova versão, estão concentradas no contrato RollupManager recém-introduzido, no plano de atualização oficial do Polygon, a implementação do agente Polygon zkEVM original será atualizada para o contrato RollupManager, e uma nova implantação será be O contrato de sub-rede PolygonZkEVMExistentEtrog serve como o novo contrato de consenso da rede original e grava as informações globais da rede Rollup quando o novo contrato RollupManger é inicializado. Comparado com o contrato de rede usual de segunda camada PolygonZkEVMEtrog após a atualização do Etrog, o PolygonZkEVMExistentEtrog implementa um método inicializeUpgrade adicional para lógica de transição durante o processo de atualização.
Para garantir que os slots das variáveis do contrato do agente sejam consistentes após a atualização, RollupManager herda um contrato LegacyZKEVMStateVariables usado especificamente para armazenar variáveis de versões antigas. Por outro lado, para garantir a consistência do status do lote antes e depois da atualização, o RollupManager também realizou uma série de operações durante a inicialização, reatribuiu os dados históricos ao novo contrato e gerou um forçadoBatch na primeira camada de acordo com o regras atualizadas como lote de transição de atualização Etrog para processamento de nó.
contrato de ponte
A atualização Etrog fornece ao contrato de ponte a função de personalizar tokens de gás e também modifica o esquema de geração globalExitRoot para garantir que os dados originais sejam consistentes e compatíveis com a atualização das raízes de saída de múltiplas cadeias de segundo nível para alcançar multi- interoperabilidade de ativos de nível dois.
Atualização de nó
Em termos de nós, a atualização do Etrog atualiza principalmente os módulos sequenciadores e sincronizadores, e também atualiza o contrato abi, que é usado para interagir com a nova versão do contrato.
módulo sequenciador
Esta atualização modifica a lógica de empacotamento de blocos e lotes. Antes do Etrog, cada bloco da segunda camada continha apenas uma transação, e o tempo do bloco era consistente com o tempo do lote em que o bloco estava localizado. Este design é bastante diferente do modelo Ethereum. Para aplicações on-chain, a lógica comumente usada de transações de passagem de bloco é muito incompatível. Portanto, após a atualização do Etrog, a lógica de empacotamento de todo o bloco da segunda camada foi ajustada para produzir blocos em um horário fixo, e um único bloco pode conter múltiplas transações, o que melhora os problemas de incompatibilidade nas versões históricas.
módulo sincronizador
As mudanças do Etrog estão divididas em duas partes. A primeira é se adaptar aos eventos da nova versão do contrato e à lógica de processamento correspondente, incluindo como lidar com lotes de transição, como lidar com novos eventos de envio de lote/prova e eventos de atualização de info_tree, etc. A outra parte é reconstruir a lógica geral de sincronização. Nas versões pré-Etrog, toda a lógica de sincronização era serial. Para nós sem permissão, é necessário aguardar que uma camada de dados seja completamente sincronizada em lote antes de continuar a sincronizar os dados a serem enviados do nó mestre. Isso significa que sempre haverá um atraso entre os dados desses nós e o nó mestre. A atualização do Etrog reconstruiu completamente esta parte da lógica, dividindo as tarefas de sincronização da primeira e segunda camadas em seus próprios threads para gerenciamento, o que não apenas resolve o problema de atraso acima, mas também acelera a eficiência de sincronização da primeira camada. dados.
Atualização do CDK Validium para Lumoz
A rede zkEVM convencional pode usar completamente o código-fonte aberto no armazém oficial para concluir o processo de atualização, mas o plano de atualização do Validium não é oficialmente suportado. Após pesquisa e desenvolvimento, a equipe Lumoz concluiu o plano de atualização do Validium e atualizou com sucesso vários testnets e a rede principal Merlin baseada no CDK Validium. Esta seção apresentará principalmente o caminho de atualização específico para Validium.
Implementação de código
Aspectos contratuais
O plano de atualização do Validium pode basicamente referir-se às alterações oficiais do Rollup para implementar um contrato PolygonValidiumExistentEtrog para o contrato de consenso do Validium. Este contrato será baseado no contrato CDKValidium original. Assim como zkEVMExistentEtrog, ele precisa implementar um método inicializeUpgrade, herdar dados históricos durante a execução da transação de atualização e gerar um lote de atualização para o nó processar. A diferença do zkEVM é que o endereço DataCommittee da nova versão do CDK Validium será mantido pelo contrato PolygonValidiumExistentEtrog recém-implantado, portanto, o endereço CDKDataCommittee original precisa ser redefinido para a variável dataAvailabilityProtocol durante o processo de atualização.
Aspecto do nó
A nova versão oficial do código do nó Validium não implementa a lógica de processamento para o evento updateEtrogSequence, portanto, não pode ser usada diretamente. No entanto, ainda pode ser implementada referindo-se ao fluxo de processamento Rollup. Por outro lado, também é necessário modificar a abi do contrato da qual o código depende para que possa se adaptar à interface do contrato Valdium e substituir a interface original do contrato Rollup.
Observe que se você optar por pular o Etrog e atualizar diretamente para a versão Eldberry ou superior, algumas modificações adicionais serão necessárias no nó devido aos diferentes métodos de processamento de dados em lote. Durante o processo de atualização do contrato, a transição forçadaBatch gerada pela primeira camada ainda é gerada na versão Etrog. Ao processar o lote, o nó não pode usar o processador Eldberry padrão, mas precisa reutilizar o processador da versão Etrog, caso contrário, haverá problemas de incompatibilidade. pode ocorrer.
Processo de atualização
Antes da atualização, todas as novas versões de contratos, incluindo RollupManager, ValidiumExistentEtrog, GlobalExitRootV2, BridgeV2, etc., precisam ser implantadas nas redes de primeira e segunda camadas, respectivamente. Para obter detalhes, consulte o script de atualização oficial e substitua o contrato relacionado ao zkEVM pelo contrato relacionado ao Validium. Após a conclusão da implantação do contrato relevante, os dados de transação do proxy para atualização do CDKValidium podem ser pré-gerados e o método de inicialização recém-implementado pode ser chamado para concluir a reatribuição de dados e a geração de lote de transição mencionadas acima. Posteriormente, o endereço da autoridade relevante do contrato Timelock chama o método schdule para reservar a transação de atualização e aguarda o tempo de bloqueio do contrato Timelock. Semelhante às operações na primeira camada, também é necessário pré-gerar os dados da transação de atualização do contrato ponte na segunda camada e reservar a transação de atualização no contrato Timelock na segunda camada.
Como a lógica de inicialização do RollupManager precisa verificar se a prova foi enviada para a versão mais recente para garantir que a execução em lote e a prova antes e depois da atualização estejam na mesma versão, alguns ajustes nos nós confiáveis ainda precisam ser feitos após a o tempo de bloqueio é atingido. Para minimizar o tempo de inatividade durante a atualização, você pode predefinir o parâmetro StopSequencerOnBatchNum no serviço sequenciador com antecedência para interromper o empacotamento das transações após atingir o lote, deixando tempo suficiente para o envio do lote e do certificado correspondente. Por outro lado, como as versões antiga e nova do Validium foram modificadas no arquivo de migração pool_db, os registros relevantes de 'supernets-0001.sql' no banco de dados precisam ser processados manualmente ou no código do nó para alinhar o estrutura do banco de dados da nova versão do nó.
Depois que a prova for enviada para o mais recente e o banco de dados for classificado, você pode usar o endereço de permissão relevante do contrato Timelock de primeira camada para chamar o método execute para executar a operação de atualização agendada anteriormente, atualizar todos os arquivos de configuração e atualizar todas as versões de serviço dos nós confiáveis ao mesmo tempo. Depois que o nó confiável retomar o serviço e reiniciar as transações de empacotamento, todos os nós sem permissão também precisarão atualizar o arquivo de configuração e reiniciar o serviço usando o novo código de versão. A operação de atualização de segunda camada também pode executar o método execute após atingir o tempo definido pelo Timelock para concluir a atualização do contrato de ponte de segunda camada.
Como uma parte importante do ecossistema Polygon CDK, a Lumoz tem prestado atenção a cada atualização do Polygon CDK, realizou diversas pesquisas, desenvolvimentos e otimizações e explicou ao público os detalhes por trás das atualizações de uma forma fácil de entender, na esperança de classificá-los e complementá-los de forma abrangente. O caminho de atualização da versão inicial do CDK Validium para a versão Etrog amplia efetivamente os limites de desenvolvimento do Polygon CDK e até mesmo de toda a indústria de blockchain.
