대량의 트랜잭션을 유발한 각인 문구로 인해 주목받은 zkSync가 어떻게 압력 테스트를 완벽하게 통과할 수 있었는가?
글: Haotian
서론: 최근 극도로 열광적인 인스크립션 운동은 주요 퍼블릭 블록체인들에 대한 대규모 시험대였다. 일부 블록체인은 다운되었고, 또 다른 일부는 가스 수수료가 폭등했다. 이 시험 속에서 zkSync는 성능과 가스 안정성 측면에서 완벽하게 시험을 통과했다.
의문이 들 수도 있다. zkSync도 인스크립션으로 다운되지 않았나? 진실은 블록 탐색기 프론트엔드 표시에 문제가 있었던 것이지, 체인 자체의 문제는 아니었다. 본문은 기술 원리 관점에서 zkSync가 왜 뛰어난 성능을 보이는지, 왜 처리하는 트랜잭션 양이 많아질수록 가스비가 더 저렴해지는지를 설명한다.
zkSync 체인에 인스크립션을 새기는 것은 단시간에 엄청난 트랜잭션이 몰리는 L2 퍼블릭 블록체인의 "스트레스 테스트"였지만, 그 결과는 "다운"이 아니라 정반대로,zkSync의 공개된 실전 훈련이었으며, TPS 피크와 가스 안정성 등 모든 면에서 완벽하게 시험을 통과했다.
처음 듣기엔 직관에 어긋나는 것처럼 들릴지도 모른다. 아래에서 기술적 논리를 바탕으로 명확히 설명하겠다:
zkSync의 블록 생성 방식은 간단히 말하면 이렇다.사용자가 트랜잭션을 생성하여 zkSync 시퀀서(Sequencer)의 정렬 큐에 들어가면, 시퀀서는 가스비가 높은 순서대로 트랜잭션을 묶어 블록을 만들고, 이후 증명 시스템을 통해 검증한 후 메인넷에 제출하여 최종 확정(finality) 상태를 완성한다.
-여기서 두 가지 핵심 포인트가 있는데, 이로 인해 사용자 경험상 "매우 나쁨"이라는 잘못된 인식이 생길 수 있다:
1) 사용자 트랜잭션 생성 단계: 대부분의 사용자는 Metamask 등의 지갑을 통해 트랜잭션을 시작한다. 지갑을 통해 zkSync에 트랜잭션을 보내면, 해당 트랜잭션은 먼저 RPC 원격 호출 서버를 거쳐 시퀀서의 대기열에 들어간다. 이 대기 시간은 짧게는 몇 초, 길게는 수 분까지 걸릴 수 있으며, 사용자가 오래 기다리면 Metamask는 해당 트랜잭션이 실패한 것으로 판단하고 프론트엔드에서 실패 메시지를 반환한다.
하지만 이는 트랜잭션이 실제로 실패했다는 의미가 아니다.Metamask의 RPC 응답 시간과 피드백 로직이 zkSync 시퀀서의 대기 및 패키징 로직과 "호환되지 않기 때문"이다. 그래서 일부 Metamask에서는 실패로 표시되지만, 잠시 기다리면 백엔드 서버에서는 성공했다고 나타나는 현상이 발생하는 것이다.
사용자가 지갑 경로가 아닌 직접적으로 백엔드 코드를 통해 zkSync의 RPC를 호출한다면, 응답 시간 초과나 실패 알림 같은 문제는 발생하지 않으며, 사용자 경험은 매우 매끄럽다. 이는 백엔드 코드 명령을 사용할 수 있는所谓 '과학자들'에게 일정한 이점을 주지만, 본질적으로는 지갑 사용자 경험의 문제일 뿐, zkSync 체인의 처리 능력과는 무관하다.
2) 시퀀서의 공정한 정렬 단계: 사용자가 짧은 시간 내에 RPC 대기열에 트랜잭션을 보낼 경우, 각 트랜잭션은 nonce 값 0부터 차례로 증가한다. 이전 트랜잭션이 아직 대기 중이고 nonce가 0이라면, 사용자가 새로운 트랜잭션(nonce=1)을 보내면 zkSync 시퀀서는 시간 순서에 따라 nonce 값을 할당하고 정렬한다.
그러나 사용자가 Metamask 프론트엔드에서 이전 트랜잭션이 실패했다고 표시되면, 동시에 새로운 트랜잭션을 다시 제출할 수 있는데,지갑과 zkSync API 인터페이스 호출 간의 문제로 인해 일부 트랜잭션이 실제로 RPC 대기열에 제대로 전달되지 않을 수 있다. 사용자는 많은 트랜잭션을 보냈다고 생각하지만, 실제로 zkSync는 그 일부만 받았을 뿐이며, 받은 트랜잭션은 모두 정렬 및 처리된다.
따라서 사용자가 Metamask에서 트랜잭션 실패를 보고 계속해서 새로운 트랜잭션을 제출하는 행동은 사실상 많은 트랜잭션 실패를 유발하며,이유는 트랜잭션이 zkSync 체인의 백엔드에 제출되지 않았기 때문이며, 단지 프론트엔드에서 제출했다고 착각했을 뿐이다.
결국,Metamask 지갑의 RPC 응답 시간 로직 문제와 사용자가 체인 상에 트랜잭션을 서두르는 행동이 함께 작용하여 다수의 트랜잭션 "실패"를 유도한다. zkSync 백엔드의 트랜잭션 처리 흐름을 이해한다면 이러한 사용자 경험상의 문제를 쉽게 회피할 수 있다.
-위 내용을 바탕으로 다시 "다운" 문제를 명확히 하자:
zkSync 체인이 "다운"된 것이 아니라, 브라우저 프론트엔드의 표시 문제였다. 브라우저는 zkSync의 RPC 인터페이스를 통해 최신 데이터를 가져오지만, 인터페이스 응답에는 지연이 발생하며, 많은 신규 트랜잭션이 이를 더욱 느리게 만든다.
즉,브라우저의 데이터 동기화 속도가 대기 중인 트랜잭션의 급증 속도를 따라잡지 못하는 것이며, 이는 브라우저 프론트엔드의 문제지, 체인 운영과는 무관하다. 일반적으로 트랜잭션 속도가 적절히 느려지고 나면, 브라우저가 새로운 데이터를 수집할 수 있게 되면서 문제가 해결된다.
브라우저가 작동하지 않을 때는 다른 zkSync 블록 데이터를 동기화하는 브라우저를 이용해 교차 확인할 수 있다. 예: https://hyperscan.xyz
-실제 체인의 "운영 성능"은 어떠한가?
1)所谓 '다운' 소문이 돌았음에도 불구하고, zkSync 공식 담당자 Anthony Rose는 트위터를 통해 연이어 TPS 갱신 기록을 발표했다.실제로 zkSync의 TPS는 187.9라는 최고치에 도달했으며, 평소에는 50~100 수준이었음을 감안하면, 대량의 신규 트랜잭션이 몰렸음에도 zkSync는 압력을 잘 견뎌냈다는 의미다. 이는 미래에 수천에서 수만 TPS를 목표로 하는 충분한 "스트레스 테스트" 역할도 했다.
2) ZK-Rollup 고유의 메커니즘은 처리되는 트랜잭션 양이 많을수록 가스비가 더 저렴해진다는 특성을 가진다. 실제로 zkSync의 가스비는 더 저렴해졌으며, 비용이 분산되기 때문이다. growthepie 데이터에 따르면,최근 24시간 동안 zkSync의 평균 가스비는 5.2% 하락했고, 약 $0.19 수준을 유지했다. 개인별 경험은 다를 수 있지만, 전체 체인 운영 데이터를 종합하면 실제로 저렴해졌다. 이는 ZK-Rollup이 더 부드러운 사용자 경험을 제공하려면 현재의 사용자 규모를 한 단계 더 끌어올려야 함을 입증한다.
-인스크립션 사태가 L2 퍼블릭 블록체인에 미친 영향은?
Dune 데이터에 따르면, Sync의 인스크립션 발행은 14시간 만에 500만 건의 트랜잭션을 추가했으며, 이미 65,575명의 홀더가 참여했다. 앞서 언급했듯, zkSync 공식팀은 커뮤니티가 자발적으로 진행한 이 "스트레스 테스트"를 인지하고, zkSync 체인의 원활한 운영을 위해 긴급 조치를 취했다.
이 데이터는 zkSync 입장에서 매우 좋은 스트레스 테스트 실험이었으며, 긍정적 영향이 부정적 영향보다 크다.장기적으로 보면, 인스크립션 사건은 L2의 성능을 원점으로 되돌린다는 소문과 달리, L2의 추가적인 성능 최적화에 실질적인 경험을 제공했다.
내가 아는 한, Sync 외에도 다른 인스크립션들이 발행되고 있으며, Sync만큼 FOMO(두려움) 수준은 아니지만, 여전히 이 스트레스 테스트에 불을 지피고 있다.
어쨌든 결과는 전반적으로 긍정적이며, zkSync 백엔드의 정렬 및 블록 생성 기술 로직을 이해하고, 여기에 존재하는 "경험상의 문제"를 바로잡는다면, 모든 것이 정상적으로 운영되고 있음을 알 수 있다. 우리는 L2에 대해 더 많은 신뢰를 가져야 한다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
Haotian | CryptoInsight
