A mania de inscrição é transmitida para a Camada 2, por que o zkSync pode passar no teste de estresse da negociação altíssima?

Escrito por: Haotian

A inscrição gravada na cadeia zkSync e o influxo de curto prazo de transações altíssimas é de fato um “teste de estresse” do desempenho da cadeia pública layer2, mas o resultado não é um “tempo de inatividade”, pelo contrário, este é um treinamento público do zkSync, e o resultado é que o pico TPS e a estabilidade do GAS 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 é simples: os usuários constroem transações na sequência de classificação do zkSync Sequencer e, em seguida, o Sequencer as empacota em blocos de acordo com a classificação da taxa de gás e, em seguida, passa os blocos para o sistema de Prova para verificação e, finalmente, os envia para a rede principal para confirmação completa do status de finalidade.

Existem 2 pontos-chave aqui que podem facilmente criar a ilusão de uma “má experiência”:

1. Os usuários constroem transações: 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 de fila. 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 porque há uma “incompatibilidade” entre o tempo de resposta RPC e a lógica de feedback do Metamask e a lógica de enfileiramento e empacotamento do Sequencer do zkSync. É por isso que, depois de esperar um pouco, o servidor back-end mostra que algumas transações que o MetaMask mostra como falhando.

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.

2. Link de ordenação justa do sequenciador: quando o usuário envia uma transação para a fila RPC por um curto período de tempo, cada transação será sobreposta 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, 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 zkSync só recebeu algumas 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 comportamento 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, a lógica de tempo de resposta RPC da carteira MetaMask e a pressa do usuário em sobrepor transações na cadeia causarão um grande número de “falhas” de transações, e é relativamente 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 em segundo plano 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 a velocidade da proliferação de transações em fila, o que é um problema com o front-end do navegador e não tem nada a ver com o funcionamento da cadeia. Normalmente, o problema será resolvido quando a velocidade da transação diminuir adequadamente e o navegador puder capturar os 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?

1. Depois que os chamados rumores de interrupção surgiram, Anthony Rose, um membro oficial da equipe do zkSync, frequentemente tuitou relatórios de atualização do TPS. Na verdade, o zkSync TPS subiu para um pico de 187,9, e em circunstâncias normais, o TPS é apenas em torno de 50-100, o que indica que há um grande influxo de novas transações, e o zkSync realmente resistiu à pressão. Este é, de facto, um “teste de stress” suficiente para milhares ou mesmo dezenas de milhares de TPS no futuro.

2. 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 é rateado, de acordo com dados do 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 precisa aumentar a escala de usuário existente em uma ordem de magnitude.

Qual é 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 do 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 do backend zkSync classificando blocos, e depois se livrar do mal-entendido de “má experiência”, você deve entender que tudo está funcionando bem, e temos que dar à layer2 um pouco mais de confiança.