비문 스트레스 테스트에서 zkSync는 성공적인 공개 교육을 완료했습니다.
원저자: Haotian(X: @tmel0211)
편집자 주: Inscription 트랙은 여전히 인기가 있으며 짧은 시간 내에 엄청난 양의 트랜잭션이 zkSync 체인으로 넘쳐났습니다. 이번 스트레스 테스트에서 zkSync가 Inscription 때문에 다운되었다고요? 아니면 완벽함이 테스트되었나요? 암호화폐 연구원Haotian(X: @tmel0211) 기술적인 논리에서 zkSync의 나쁜 경험에 대한 환상과 오해를 해명했습니다. Odaily는 이를 다음과 같이 요약했습니다.
zkSync 체인에 새겨진 비문과 짧은 시간에 쏟아져 들어오는 엄청난 양의 트랜잭션은 그야말로 Layer 2 퍼블릭 체인의 성능에 대한 스트레스 테스트였지만, 그 결과는 다운타임이 아니었습니다. .이는 @zksync의 공개 훈련이며, 그 결과 TPS 최고값, GAS 안정성 등이 모두 완벽하게 테스트되었습니다.
얼핏 보면 반직관적으로 들리나요? 다음으로 기술적인 논리를 사용하여 이를 명확히 하겠습니다.
간단히 말해서 zkSync 패키징 블록 생산의 작동 원리는 다음과 같습니다.사용자는 트랜잭션을 구성하고 zkSync Sequencer의 정렬 시퀀스를 입력한 다음 Sequencer는 이를 Gas Fee에 따라 블록으로 정렬 및 패키징한 다음 검증을 위해 블록을 Proof 시스템에 전달하고 최종적으로 메인 네트워크에 제출하여 완료합니다. 최종 상태 확인.
-여기에는 나쁜 경험이라는 환상을 쉽게 만들 수 있는 두 가지 핵심 사항이 있습니다.
1) 사용자는 거래 링크를 구성합니다.대부분의 사용자는 Metamask와 같은 지갑을 통해 트랜잭션을 시작하고 지갑을 통해 zkSync에 트랜잭션을 보냅니다. 트랜잭션은 먼저 RPC 원격 호출 서버에 들어간 다음 Sequencer가 이러한 트랜잭션을 수신하고 대기열 시퀀스에 들어갑니다. 여기서 대기 시간은 짧게는 몇 초, 길게는 몇 분일 수 있으며, 사람이 오랫동안 기다리면 MetaMask는 트랜잭션이 실패했다고 판단한 후 프런트 엔드에서 트랜잭션이 실패했다는 메시지를 반환합니다. 실패한.
그러나 이는 트랜잭션이 실제로 실패했다는 의미는 아닙니다.이는 Metamask의 RPC 응답 시간 및 피드백 논리와 zkSync의 Sequencer 대기열 및 패키징 트랜잭션 논리 간의 비호환성 때문입니다.이것이 바로 MetaMask가 명확하게 표시한 일부 트랜잭션이 실패한 이유입니다. 일정 시간을 기다린 후 백엔드 서버가 다시 성공을 표시합니다.
사용자가 지갑 파이프라인을 거치지 않고 백엔드 코드를 직접 사용하여 zkSync의 RPC를 호출하는 경우 응답 시간 제한 및 실패 프롬프트 문제가 없으며 경험이 비교적 원활할 것입니다. 이는 실제로 백엔드 코드 지침을 사용할 수 있는 일부 과학자에게 이점을 제공하지만 이는 본질적으로 지갑 경험 측면의 문제이며 zkSync 체인의 처리 능력과는 아무런 관련이 없습니다.
2) 시퀀서 공정 정렬 링크:사용자가 짧은 시간 동안 RPC 큐에 트랜잭션을 보내면 각 트랜잭션은 nonce 값 0부터 중첩됩니다. 이전 트랜잭션이 아직 큐에 있으면 nonce는 0입니다. 사용자는 nonce 값 0으로 새 트랜잭션을 시작합니다. 1. zkSync의 Sequencer는 시간을 기준으로 이러한 트랜잭션에 nonce를 할당한 다음 순서대로 정렬합니다.
하지만 사용자가 MetaMask 이전 단계에서 이전 트랜잭션이 실패한 것을 확인하고 동시에 새로운 트랜잭션을 제출하는 경우,새로 제출된 트랜잭션 중 일부가 지갑 및 zkSync API 인터페이스 호출 문제로 인해 RPC 대기열 시퀀스에 성공적으로 제출되지 않았을 가능성이 있습니다.사용자는 많은 트랜잭션이 제출되었다고 생각하지만 실제로 zkSync는 그 중 일부만 수신했으며 수신하는 한 정렬 및 처리됩니다.
이렇게 보면 사용자가 MetaMask에서 트랜잭션 실패를 보고하는 것을 볼 때 지속적으로 새로운 트랜잭션을 제출하는 행위도 많은 트랜잭션 실패를 유발하게 됩니다.왜냐하면 zkSync 체인의 백엔드에는 전혀 제출이 없는데 프런트엔드에 제출했다고 생각하기 때문입니다.
전반적으로 MetaMask 지갑의 RPC 응답 시간 논리 문제와 체인에 트랜잭션을 추가하려는 사용자의 행동으로 인해 많은 트랜잭션 실패가 발생합니다.zkSync의 백그라운드 트랜잭션 처리 워크플로우를 이해한다면 이러한 최적화 경험 문제를 피하는 것이 상대적으로 더 쉽습니다.
-위의 대중 과학을 바탕으로 다운타임 문제를 명확히 해보겠습니다.
zkSync 체인은 다운되지 않으며 브라우저 프런트 엔드 디스플레이 문제일 뿐입니다. 브라우저가 zkSync의 RPC 인터페이스를 통해 최신 데이터를 가져오지만 인터페이스 응답이 지연되고 많은 수의 새로운 트랜잭션이 느려지기 때문입니다. 응답을 아래로.
즉,브라우저의 풀 데이터 동기화 속도가 대기 중인 트랜잭션의 급증을 따라잡을 수 없습니다. 이는 브라우저 프런트 엔드의 문제이며 체인 작동과 관련이 없습니다.일반적으로 문제는 트랜잭션 속도가 충분히 느려지고 브라우저가 새 데이터를 크롤링할 수 있게 되면 해결됩니다.
브라우저가 작동하지 않는 경우 zkSync 블록 데이터 정보를 동기화하는 다른 브라우저를 통해 교차 검증할 수 있습니다. 예: https://hyperscan.xyz
-실제 체인의 운영 성과는 어떤가요?
1) 이른바 다운타임 루머가 터진 후 zkSync의 공식 직원인 @anthonykrose는 트위터에 TPS 갱신 소식을 자주 게시했습니다.실제로 zkSync TPS는 187.9까지 최고치까지 치솟았는데, 일반적인 상황에서는 TPS가 50~100 정도에 불과한데, 이는 zkSync가 실제로 대량의 신규 트랜잭션 유입으로 인한 압박을 견뎌냈음을 보여줍니다.이는 실제로 향후 수천 또는 수만 TPS에 대한 충분한 스트레스 테스트를 제공합니다.
2) ZK-Rollup의 특별한 메커니즘은 처리되는 거래량이 많을수록 가스비가 저렴하다고 판단합니다. 실제로 zkSync의 가스비는 거래 비용도 공유되기 때문에 실제로 저렴합니다. 성장피 데이터에 따르면,지난 24시간 동안 zkSync의 가스 평균은 5.2% 하락하여 평균 약 0.19달러였습니다. 이 데이터에 대한 모든 사람의 경험은 다를 수 있지만 종합 체인의 운영 데이터를 기준으로 보면 실제로 더 저렴합니다.이는 ZK-Rollup의 보다 원활한 경험을 위해서는 기존 사용자 규모를 몇 배나 늘려야 함을 증명합니다.
- 비문 사건이 레이어 2 퍼블릭 체인에 어떤 영향을 미치는가?
모래 언덕 데이터에 따르면 Sync의 비문 캐스팅은 14시간 만에 500만 건의 거래를 추가했으며 65,575명의 홀더가 참여했습니다. 위에서 언급한 바와 같이, zkSync 관계자는 커뮤니티가 주도한 이 스트레스 테스트 활동을 인지하고 있으며 zkSync 체인의 질서 있는 진행을 보장하기 위해 긴급 조치를 취했습니다.
이 데이터는 실제로 zkSync에 대한 더 나은 스트레스 테스트 실험이며 긍정적인 영향이 부정적인 영향보다 큽니다.장기적으로 Inscription 사건은 소문처럼 레이어 2 성능을 프로토타입으로 되돌리지 않고 대신 레이어 2의 추가 성능 최적화를 위한 실용적인 경험을 제공했습니다.
그러나 내가 아는 한 Sync 외에도 다른 비문이 발행되고 있으며 Sync만큼 fomo는 아니지만 이 스트레스 테스트에 연료를 추가합니다.
어쨌든 결과는 대체적으로 좋다.zkSync의 백그라운드 정렬 및 블록 생성에 대한 기술적인 논리를 명확히 한 다음 나쁜 경험에 대한 오해를 없애면 모든 것이 잘 돌아가고 있다는 것을 이해해야 하며 레이어를 제공해야 합니다. 2 조금 더 자신감을 가지세요.
