Um amigo reclamou que o zkSync está sempre fora do ar. Na verdade, chamá-lo de "tempo de inatividade" é um pouco exagerado. Para ser mais preciso, significa "geração de bloco instável". Em essência, 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 de transação causada por alguns DApps e a compatibilidade subjacente da cadeia. Afinal, desenvolver DApps no próprio zkSync é um grande desafio. Demora cerca de 30 minutos a 1 hora para eu observar a mudança de status de Confirmado para Verificado no navegador oficial, e 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, para trazer a você 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 classificador do Sequencer por meio de retransmissão;
O sequenciador é responsável por classificar transações, agregar e empacotar lotes em árvores Merkle;
zkPorter gera uma prova zk-SNARK da árvore Merkle;
zk-SNARK prova que o relay gera Commit Hash para L2 Validators e L1 main chain, respectivamente
O Validador é responsável por verificar a exatidão da prova zk-SNARK e enviá-la ao contrato inteligente L1 para gerar um Hash de verificação após correto; 6) O contrato inteligente zkSync em L1 verifica a correspondência do Hash de confirmação e Verify Hash; 7) Gera um Verified após correspondência bem-sucedida A transação Transaction é finalmente carregada na cadeia; 8) Se a correspondência falhar, o Commit Hash original será invalidado e o Sequencer 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 Workflow do zkSync tem principalmente quatro funções: 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:
Nodos multidistribuídos podem evitar a instabilidade da rede causada por ponto único de falha, devido à robustez do sistema;
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 outra perspectiva, o longo período de Verificação não é um problema na fase inicial da ecologia, pode efetivamente melhorar a segurança da cadeia e evitar que alguns nós do sistema façam o 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á consolidar sua confiança na trilha técnica L2. Todos são bem-vindos para encaminhar e compartilhar, DM a qualquer momento, e vamos ter uma troca e estudo aprofundados do zkSync.
Ver original
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Por que o zkSync é sempre "tempo de inatividade"? Um artigo discutindo o fluxo de trabalho do zkSync
Um amigo reclamou que o zkSync está sempre fora do ar. Na verdade, chamá-lo de "tempo de inatividade" é um pouco exagerado. Para ser mais preciso, significa "geração de bloco instável". Em essência, 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 de transação causada por alguns DApps e a compatibilidade subjacente da cadeia. Afinal, desenvolver DApps no próprio zkSync é um grande desafio. Demora cerca de 30 minutos a 1 hora para eu observar a mudança de status de Confirmado para Verificado no navegador oficial, e 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, para trazer a você 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 classificador do Sequencer por meio de retransmissão;
O sequenciador é responsável por classificar transações, agregar e empacotar lotes em árvores Merkle;
zkPorter gera uma prova zk-SNARK da árvore Merkle;
zk-SNARK prova que o relay gera Commit Hash para L2 Validators e L1 main chain, respectivamente
O Validador é responsável por verificar a exatidão da prova zk-SNARK e enviá-la ao contrato inteligente L1 para gerar um Hash de verificação após correto; 6) O contrato inteligente zkSync em L1 verifica a correspondência do Hash de confirmação e Verify Hash; 7) Gera um Verified após correspondência bem-sucedida A transação Transaction é finalmente carregada na cadeia; 8) Se a correspondência falhar, o Commit Hash original será invalidado e o Sequencer 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 Workflow do zkSync tem principalmente quatro funções: 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:
Nodos multidistribuídos podem evitar a instabilidade da rede causada por ponto único de falha, devido à robustez do sistema;
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 outra perspectiva, o longo período de Verificação não é um problema na fase inicial da ecologia, pode efetivamente melhorar a segurança da cadeia e evitar que alguns nós do sistema façam o 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á consolidar sua confiança na trilha técnica L2. Todos são bem-vindos para encaminhar e compartilhar, DM a qualquer momento, e vamos ter uma troca e estudo aprofundados do zkSync.