Nota do editor: A faixa de inscrição ainda está quente, a cadeia zkSync foi inundada com um grande número de transações em um curto período de tempo, neste "teste de estresse", zkSync está fora do ar por causa da inscrição, ou foi testado perfeitamente? O pesquisador de criptomoedas Haotian (X:@tmel0211) esclareceu a ilusão e a incompreensão da "má experiência" do zkSync a partir da lógica técnica, e o Odaily Planet Daily resolveu da seguinte forma:
A inscrição gravada na cadeia zkSync e o influxo de curto prazo de transações altíssimas são de fato um "teste de estresse" do desempenho da cadeia pública de Camada 2, mas o resultado não é um "tempo de inatividade", pelo contrário, este é um treinamento público @zksync, e o resultado é que o pico TPS, a estabilidade do GAS, etc. foram perfeitamente testados. **
À primeira vista, não parece um pouco contraintuitivo? Em seguida, com lógica técnica, deixe-me esclarecer para você:
O princípio de funcionamento dos blocos de empacotamento do zkSync é simplesmente o seguinte: os usuários constroem transações na sequência de classificação do zkSync Sequencer e, em seguida, o Sequencer os empacota em blocos de acordo com a classificação das taxas de gás e, em seguida, passa os blocos para o sistema de Prova para verificação e, finalmente, os envia à rede principal para confirmação completa do status de finalidade. **
-Existem 2 pontos-chave aqui, que são fáceis de criar a ilusão de "má experiência":
Os usuários constroem links de transação: A maioria dos usuários iniciará transações através de carteiras como Metamask, e enviará transações para zkSync através de carteiras, e as transações entrarão primeiro no servidor de chamada remota RPC e, em seguida, o Sequencer receberá essas transações e entrará na sequência enfileirada. O tempo de fila aqui pode ser tão curto quanto alguns segundos ou tão longo quanto alguns minutos, e se você esperar por um longo tempo, o MetaMask assumirá que a transação falhou e, em seguida, o front-end retornará uma mensagem de que a transação falhou.
No entanto, isso não significa que a transação realmente falhou, mas apenas devido à "incompatibilidade" entre o tempo de resposta RPC e a lógica de feedback do Metamask e a lógica de transação do pacote em fila do zkSync. **Esta é a razão pela qual algumas transações que parecem ter falhado no MetaMask mostram sucesso novamente depois de esperar por um tempo.
Se o usuário não passar pelo pipeline da carteira e usar diretamente o código de back-end para chamar o RPC do zkSync, não haverá tempo limite de resposta e falha de prompt, e a experiência será relativamente suave. Isso dá uma vantagem para alguns "cientistas" que podem usar instruções de código de back-end, mas é essencialmente um problema no lado da experiência da carteira e não tem nada a ver com o poder de processamento da cadeia zkSync.
Sessão de Ordenação Justa do Sequencer: Quando o usuário envia uma transação para a fila RPC por um curto período de tempo, cada transação será empilhada a partir do valor nonce de 0, se a transação anterior ainda estiver no estado da fila, o nonce é 0, então o usuário inicia uma nova transação com um nonce de 1, e o Sequencer do zkSync atribuirá um nonce a essas transações de acordo com o tempo e, em seguida, as classificará em ordem.
No entanto, se o usuário enviar uma nova transação ao mesmo tempo depois de ver que a transação anterior falhou na seção anterior do MetaMask, é provável que algumas das transações recém-enviadas não sejam enviadas com êxito para a fila RPC devido ao problema do lado da carteira e da chamada da interface da API zkSync. Os usuários pensam que muitas transações foram enviadas, mas na verdade o zkSync recebeu apenas uma parte delas, e assim que as receberem, elas as classificarão.
Olhando dessa forma, os usuários veem que o MetaMask relata que as transações falharam, e o ato de enviar constantemente novas transações também causará um grande número de falhas de transação, porque não há nenhum envio para o backend da cadeia zkSync, mas você acha que o enviou no frontend. **
No geral, os problemas de lógica de tempo de resposta RPC da carteira MetaMask e a pressa dos usuários em sobrepor transações on-chain causarão um grande número de "falhas" de transações, e é relativamente mais fácil evitar esses problemas de experiência de otimização se você tiver clareza sobre o fluxo de trabalho de processamento de transações de back-end do zkSync.
-Com base na ciência popular acima, vamos esclarecer o problema do "tempo de inatividade":
A cadeia zkSync não está "para baixo", é apenas um problema de exibição no front-end do navegador, porque o navegador puxará os dados mais recentes através da interface RPC do zkSync, mas haverá um atraso na resposta da interface, e um grande número de novas transações retardará a resposta.
Em suma, a velocidade da sincronização de dados pull do navegador não consegue acompanhar o aumento de transações em fila, o que é um problema com o front-end do navegador e não tem nada a ver com a operação da cadeia. **O problema geralmente é resolvido quando a velocidade da transação diminui adequadamente e o navegador pode capturar novos dados.
Quando o navegador não funciona, você pode usar outros navegadores que sincronizam as informações de dados do bloco zkSync para verificação cruzada, como:
-Qual é o "desempenho operacional" da cadeia real?
Depois que os chamados rumores de interrupção estouraram, a equipe oficial do zkSync @anthonykrose tuitou atualizações do TPS. Na verdade, zkSync TPS subiu para um pico de 187,9, e em circunstâncias normais, o TPS é apenas cerca de 50-100, o que indica que há um enorme influxo de novas transações, e zkSync realmente resistiu à pressão. Isso fornece um "teste de estresse" completo para milhares, se não dezenas de milhares, de TPS no futuro.
O mecanismo especial do ZK-Rollup determina que quanto maior o volume de transações processadas, mais barata é a taxa de gás, na verdade, a taxa de gás do zkSync é realmente mais barata, porque o custo de transação também é compartilhado, de acordo com dados de growthepie, **Nas últimas 24 horas, o gás médio do zkSync também diminuiu 5,2%, com uma média de cerca de US $ 0,19, esses dados podem não ser os mesmos para todos, mas os dados de operação da cadeia integrada são realmente mais baratos. **Isso prova que a experiência mais suave do ZK-Rollup requer um aumento de ordem de magnitude na escala de usuário existente.
-O impacto dos eventos de inscrição nas cadeias públicas da camada 2?
De acordo com os dados da dune, a cunhagem de inscrições da Sync adicionou 5 milhões de transações em 14 horas, e 65.575 titulares participaram. Como mencionado acima, os funcionários do zkSync estão cientes deste "teste de estresse" iniciado pela comunidade e estão tomando medidas urgentes para garantir que a cadeia zkSync funcione de forma ordenada.
Estes dados são de facto uma boa experiência de teste de stress para o zkSync, e os seus efeitos positivos superam os negativos. **A longo prazo, o incidente de inscrição não rumore, mas sim forneceu experiência prática para uma maior otimização de desempenho da Camada 2. **
No entanto, tanto quanto sei, há outras inscrições sendo cunhadas além do Sync, que não são tão fomo quanto o Sync, mas adicionam combustível ao fogo deste teste de estresse.
De qualquer forma, os resultados são geralmente bons, se você esclarecer a lógica técnica dos blocos de classificação de back-end do zkSync, e depois se livrar do mal-entendido de "má experiência", você deve entender que tudo está funcionando bem, e precisamos dar à camada 2 um pouco mais de confiança.
Link para o artigo original
Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
Sob o teste de estresse de inscrição, o zkSync completou um "treinamento aberto" bem-sucedido
Autor Original: Haotian (X: @tmel0211)
Nota do editor: A faixa de inscrição ainda está quente, a cadeia zkSync foi inundada com um grande número de transações em um curto período de tempo, neste "teste de estresse", zkSync está fora do ar por causa da inscrição, ou foi testado perfeitamente? O pesquisador de criptomoedas Haotian (X:@tmel0211) esclareceu a ilusão e a incompreensão da "má experiência" do zkSync a partir da lógica técnica, e o Odaily Planet Daily resolveu da seguinte forma:
A inscrição gravada na cadeia zkSync e o influxo de curto prazo de transações altíssimas são de fato um "teste de estresse" do desempenho da cadeia pública de Camada 2, mas o resultado não é um "tempo de inatividade", pelo contrário, este é um treinamento público @zksync, e o resultado é que o pico TPS, a estabilidade do GAS, etc. foram perfeitamente testados. **
À primeira vista, não parece um pouco contraintuitivo? Em seguida, com lógica técnica, deixe-me esclarecer para você:
O princípio de funcionamento dos blocos de empacotamento do zkSync é simplesmente o seguinte: os usuários constroem transações na sequência de classificação do zkSync Sequencer e, em seguida, o Sequencer os empacota em blocos de acordo com a classificação das taxas de gás e, em seguida, passa os blocos para o sistema de Prova para verificação e, finalmente, os envia à rede principal para confirmação completa do status de finalidade. **
-Existem 2 pontos-chave aqui, que são fáceis de criar a ilusão de "má experiência":
No entanto, isso não significa que a transação realmente falhou, mas apenas devido à "incompatibilidade" entre o tempo de resposta RPC e a lógica de feedback do Metamask e a lógica de transação do pacote em fila do zkSync. **Esta é a razão pela qual algumas transações que parecem ter falhado no MetaMask mostram sucesso novamente depois de esperar por um tempo.
Se o usuário não passar pelo pipeline da carteira e usar diretamente o código de back-end para chamar o RPC do zkSync, não haverá tempo limite de resposta e falha de prompt, e a experiência será relativamente suave. Isso dá uma vantagem para alguns "cientistas" que podem usar instruções de código de back-end, mas é essencialmente um problema no lado da experiência da carteira e não tem nada a ver com o poder de processamento da cadeia zkSync.
No entanto, se o usuário enviar uma nova transação ao mesmo tempo depois de ver que a transação anterior falhou na seção anterior do MetaMask, é provável que algumas das transações recém-enviadas não sejam enviadas com êxito para a fila RPC devido ao problema do lado da carteira e da chamada da interface da API zkSync. Os usuários pensam que muitas transações foram enviadas, mas na verdade o zkSync recebeu apenas uma parte delas, e assim que as receberem, elas as classificarão.
Olhando dessa forma, os usuários veem que o MetaMask relata que as transações falharam, e o ato de enviar constantemente novas transações também causará um grande número de falhas de transação, porque não há nenhum envio para o backend da cadeia zkSync, mas você acha que o enviou no frontend. **
No geral, os problemas de lógica de tempo de resposta RPC da carteira MetaMask e a pressa dos usuários em sobrepor transações on-chain causarão um grande número de "falhas" de transações, e é relativamente mais fácil evitar esses problemas de experiência de otimização se você tiver clareza sobre o fluxo de trabalho de processamento de transações de back-end do zkSync.
-Com base na ciência popular acima, vamos esclarecer o problema do "tempo de inatividade":
A cadeia zkSync não está "para baixo", é apenas um problema de exibição no front-end do navegador, porque o navegador puxará os dados mais recentes através da interface RPC do zkSync, mas haverá um atraso na resposta da interface, e um grande número de novas transações retardará a resposta.
Em suma, a velocidade da sincronização de dados pull do navegador não consegue acompanhar o aumento de transações em fila, o que é um problema com o front-end do navegador e não tem nada a ver com a operação da cadeia. **O problema geralmente é resolvido quando a velocidade da transação diminui adequadamente e o navegador pode capturar novos dados.
Quando o navegador não funciona, você pode usar outros navegadores que sincronizam as informações de dados do bloco zkSync para verificação cruzada, como:
-Qual é o "desempenho operacional" da cadeia real?
Depois que os chamados rumores de interrupção estouraram, a equipe oficial do zkSync @anthonykrose tuitou atualizações do TPS. Na verdade, zkSync TPS subiu para um pico de 187,9, e em circunstâncias normais, o TPS é apenas cerca de 50-100, o que indica que há um enorme influxo de novas transações, e zkSync realmente resistiu à pressão. Isso fornece um "teste de estresse" completo para milhares, se não dezenas de milhares, de TPS no futuro.
O mecanismo especial do ZK-Rollup determina que quanto maior o volume de transações processadas, mais barata é a taxa de gás, na verdade, a taxa de gás do zkSync é realmente mais barata, porque o custo de transação também é compartilhado, de acordo com dados de growthepie, **Nas últimas 24 horas, o gás médio do zkSync também diminuiu 5,2%, com uma média de cerca de US $ 0,19, esses dados podem não ser os mesmos para todos, mas os dados de operação da cadeia integrada são realmente mais baratos. **Isso prova que a experiência mais suave do ZK-Rollup requer um aumento de ordem de magnitude na escala de usuário existente.
-O impacto dos eventos de inscrição nas cadeias públicas da camada 2?
De acordo com os dados da dune, a cunhagem de inscrições da Sync adicionou 5 milhões de transações em 14 horas, e 65.575 titulares participaram. Como mencionado acima, os funcionários do zkSync estão cientes deste "teste de estresse" iniciado pela comunidade e estão tomando medidas urgentes para garantir que a cadeia zkSync funcione de forma ordenada.
Estes dados são de facto uma boa experiência de teste de stress para o zkSync, e os seus efeitos positivos superam os negativos. **A longo prazo, o incidente de inscrição não rumore, mas sim forneceu experiência prática para uma maior otimização de desempenho da Camada 2. **
No entanto, tanto quanto sei, há outras inscrições sendo cunhadas além do Sync, que não são tão fomo quanto o Sync, mas adicionam combustível ao fogo deste teste de estresse.
De qualquer forma, os resultados são geralmente bons, se você esclarecer a lógica técnica dos blocos de classificação de back-end do zkSync, e depois se livrar do mal-entendido de "má experiência", você deve entender que tudo está funcionando bem, e precisamos dar à camada 2 um pouco mais de confiança.
Link para o artigo original