Vi um amigo reclamando que o @zkSync está sempre fora do ar. Na verdade, chamar de "tempo de inatividade" é um pouco exagerado. Para ser mais preciso, é "geração de blocos instáveis".
Essencialmente, o tempo final verificado da transação enviada pelo sequenciador é instável, mas a percepção do usuário não é óbvia no final interativo, porque o design de verificação do zkSync tem um atraso de confirmação.
A instabilidade na futura fase de descentralização será atenuada. Eu desenhei um fluxo de trabalho para discutir com você.
A razão pela qual os usuários percebem "tempo de inatividade" pode ser a falha da transação causada por alguns DApps e a compatibilidade subjacente da cadeia. Afinal, desenvolver DApps no próprio zkSync é muito desafiador.
Demora cerca de 30min-1 hora para eu observar a mudança de status de Commit para Verified no navegador oficial, enquanto o DApp interativo do lado do usuário dificilmente é afetado por isso.
Este artigo enfoca a lógica subjacente da tecnologia zkSync de ciência popular e oferece uma compreensão clara do zkSync.
Conforme mostrado no fluxo de trabalho, o zkSync é executado nas seguintes etapas:
O usuário envia transações em lote para o Sequencer por meio de retransmissão;
O sequenciador é responsável por classificar transações, agregar e empacotar lotes em uma árvore Merkle;
zkPorter gera certificados zk-SNARK da árvore Merkle; certificados zk-SNARK são retransmitidos respectivamente para validadores L2 e cadeia principal L1 para gerar hash de confirmação; validadores são responsáveis pela verificação
A correção da prova zk-SNARK é submetida ao contrato inteligente L1 para gerar um Hash de verificação;
O contrato inteligente zkSync em L1 verifica a correspondência de Commit Hash e Verify Hash;
Após a correspondência bem-sucedida, uma Transação Verificada é gerada e a transação é finalmente carregada na cadeia;
Se a correspondência falhar, o Commit Hash original será invalidado e o sequenciador reenviará o lote e passará pelo processo novamente.
É preciso enfatizar aqui que o zkSync adota "confirmação de duas fases (2PC)" e, finalmente, determina o lote de transação legal por meio da verificação de Hash dos dois estágios de Commit Hash e Verify Hash.
Por um lado, isso pode garantir a consistência e a segurança dos dados no processo de operação do sistema. No meu entendimento pessoal, também é uma manifestação da ideia de descentralização que restringe os dois componentes do sistema, Sequencer e Validator, e vale a pena de louvor.
O fluxo de trabalho do zkSync tem principalmente quatro papéis: Relay, Sequencer, zkPorter e Validator.Haverá muitos "fatores instáveis" no trabalho de coordenação.
Pode ser resumido como a estabilidade das funções do nó, a estabilidade da cooperação do nó e a complexidade dos algoritmos e protocolos subjacentes. Qualquer erro em qualquer link pode causar atraso de bloqueio. As falhas técnicas comuns do Arbitrum Sequencer são típicas e o zkSync enfrentará apenas mais desafios.
Quanto à complexidade do algoritmo, esse é o destino da cadeia zkSync, e os desenvolvedores ecológicos precisam trabalhar duro para superá-lo. Quanto à estabilidade da inteligência e colaboração do nó, acho que após a chegada do estágio de descentralização no futuro, ela será efetivamente melhorada. A lógica também é simples:
Vários nós distribuídos podem evitar a instabilidade da rede causada por um único ponto de falha, e o sistema é robusto; o mecanismo de incentivo de token distribuído pode fornecer aos desenvolvedores uma fonte de motivação para manter a estabilidade do nó.
Pensando por outro ângulo, o longo tempo de Verifing não é um problema na fase inicial da ecologia, pode efetivamente melhorar a segurança da cadeia e evitar que alguns nodos do sistema façam mal.
Resumindo, se você esclarecer todo o processo de operação do zkSync e entender melhor a complexidade técnica da camada 2 e o mecanismo "especial" projetado para segurança, poderá fortalecer sua confiança na trilha técnica L2.
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
O mecanismo de operação do zkSync é resolvido, não "tempo de inatividade" com frequência
Vi um amigo reclamando que o @zkSync está sempre fora do ar. Na verdade, chamar de "tempo de inatividade" é um pouco exagerado. Para ser mais preciso, é "geração de blocos instáveis".
Essencialmente, o tempo final verificado da transação enviada pelo sequenciador é instável, mas a percepção do usuário não é óbvia no final interativo, porque o design de verificação do zkSync tem um atraso de confirmação.
A instabilidade na futura fase de descentralização será atenuada. Eu desenhei um fluxo de trabalho para discutir com você.
A razão pela qual os usuários percebem "tempo de inatividade" pode ser a falha da transação causada por alguns DApps e a compatibilidade subjacente da cadeia. Afinal, desenvolver DApps no próprio zkSync é muito desafiador.
Demora cerca de 30min-1 hora para eu observar a mudança de status de Commit para Verified no navegador oficial, enquanto o DApp interativo do lado do usuário dificilmente é afetado por isso.
Este artigo enfoca a lógica subjacente da tecnologia zkSync de ciência popular e oferece uma compreensão clara do zkSync.
Conforme mostrado no fluxo de trabalho, o zkSync é executado nas seguintes etapas:
O usuário envia transações em lote para o Sequencer por meio de retransmissão;
O sequenciador é responsável por classificar transações, agregar e empacotar lotes em uma árvore Merkle;
zkPorter gera certificados zk-SNARK da árvore Merkle; certificados zk-SNARK são retransmitidos respectivamente para validadores L2 e cadeia principal L1 para gerar hash de confirmação; validadores são responsáveis pela verificação
A correção da prova zk-SNARK é submetida ao contrato inteligente L1 para gerar um Hash de verificação;
O contrato inteligente zkSync em L1 verifica a correspondência de Commit Hash e Verify Hash;
Após a correspondência bem-sucedida, uma Transação Verificada é gerada e a transação é finalmente carregada na cadeia;
Se a correspondência falhar, o Commit Hash original será invalidado e o sequenciador reenviará o lote e passará pelo processo novamente.
É preciso enfatizar aqui que o zkSync adota "confirmação de duas fases (2PC)" e, finalmente, determina o lote de transação legal por meio da verificação de Hash dos dois estágios de Commit Hash e Verify Hash.
Por um lado, isso pode garantir a consistência e a segurança dos dados no processo de operação do sistema. No meu entendimento pessoal, também é uma manifestação da ideia de descentralização que restringe os dois componentes do sistema, Sequencer e Validator, e vale a pena de louvor.
O fluxo de trabalho do zkSync tem principalmente quatro papéis: Relay, Sequencer, zkPorter e Validator.Haverá muitos "fatores instáveis" no trabalho de coordenação.
Pode ser resumido como a estabilidade das funções do nó, a estabilidade da cooperação do nó e a complexidade dos algoritmos e protocolos subjacentes. Qualquer erro em qualquer link pode causar atraso de bloqueio. As falhas técnicas comuns do Arbitrum Sequencer são típicas e o zkSync enfrentará apenas mais desafios.
Quanto à complexidade do algoritmo, esse é o destino da cadeia zkSync, e os desenvolvedores ecológicos precisam trabalhar duro para superá-lo. Quanto à estabilidade da inteligência e colaboração do nó, acho que após a chegada do estágio de descentralização no futuro, ela será efetivamente melhorada. A lógica também é simples:
Vários nós distribuídos podem evitar a instabilidade da rede causada por um único ponto de falha, e o sistema é robusto; o mecanismo de incentivo de token distribuído pode fornecer aos desenvolvedores uma fonte de motivação para manter a estabilidade do nó.
Pensando por outro ângulo, o longo tempo de Verifing não é um problema na fase inicial da ecologia, pode efetivamente melhorar a segurança da cadeia e evitar que alguns nodos do sistema façam mal.
Resumindo, se você esclarecer todo o processo de operação do zkSync e entender melhor a complexidade técnica da camada 2 e o mecanismo "especial" projetado para segurança, poderá fortalecer sua confiança na trilha técnica L2.