Vi alguns amigos reclamando que o zkSync está sempre fora do ar. Na verdade, chamar de "tempo de inatividade" é um pouco exagerado. Para ser mais preciso, significa "geração de bloco instável". Em essência, a transação enviada pelo Sequencer, o tempo verificado final é instável, mas a percepção do usuário não é óbvia no final interativo, porque o design Verify do zkSync tem um atraso de confirmação. ** A instabilidade na futura etapa 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, 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 se estiver correto;
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 de Transação Verificada é gerada e 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 **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 **node, acho que após a chegada do estágio de descentralização no futuro, ela será efetivamente melhorada. **A lógica também é simples:
1) Nodos multidistribuídos podem evitar a instabilidade da rede causada por ponto único de falha, devido à robustez do sistema;
**2) O mecanismo de incentivo de token distribuído pode fornecer aos desenvolvedores uma fonte de motivação para manter a estabilidade do nó. **
Pensando de outra perspectiva, o longo tempo de **Verifing não é um problema no estágio 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 serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Por que o zkSync é sempre "tempo de inatividade"? Um artigo discutindo o fluxo de trabalho do zkSync
Vi alguns amigos reclamando que o zkSync está sempre fora do ar. Na verdade, chamar de "tempo de inatividade" é um pouco exagerado. Para ser mais preciso, significa "geração de bloco instável". Em essência, a transação enviada pelo Sequencer, o tempo verificado final é instável, mas a percepção do usuário não é óbvia no final interativo, porque o design Verify do zkSync tem um atraso de confirmação. ** A instabilidade na futura etapa 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, 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 se estiver correto;
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 de Transação Verificada é gerada e 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 **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 **node, acho que após a chegada do estágio de descentralização no futuro, ela será efetivamente melhorada. **A lógica também é simples:
1) Nodos multidistribuídos podem evitar a instabilidade da rede causada por ponto único de falha, devido à robustez do sistema;
**2) O mecanismo de incentivo de token distribuído pode fornecer aos desenvolvedores uma fonte de motivação para manter a estabilidade do nó. **
Pensando de outra perspectiva, o longo tempo de **Verifing não é um problema no estágio 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.