체인피드 요약:
실시간 ZK가 없으면 진정으로 사용 가능한 상호 운용성 사용자 경험(UX)을 구현하기 어렵습니다.
기사 출처:
https://www.techflowpost.com/article/detail_29532.html
기사 작성자:
imToken Labs
관점:
imToken Labs: 12월 4일, 이더 사카(Fusaka) 업그레이드가 메인넷에서 공식적으로 활성화되었습니다. 하지만 덴쿤(Dencun) 업그레이드와는 달리, 이번 업그레이드는 큰 주목을 받지는 못했고, 시장의 관심은 주로 블롭(Blob) 확장과 피어DAS(PeerDAS)에 집중되었으며, L2 데이터 비용 추가 절감에 대한 논의가 활발했습니다. 그러나 이러한 관심 속에는 이더 L1 zkEVM과 실시간 증명을 구현하는 데 있어 가장 큰 장애물을 제거한, 겉보기에는 사소해 보이는 EIP-7825 제안이 있었습니다. 이는 상호 운용성의 최종 목표를 향한 길을 조용히 닦고 있다고도 할 수 있습니다. 이번 후사카 업그레이드의 핵심은 거의 전적으로 확장성에 맞춰졌습니다. 블롭 용량이 8배 증가하고, 피어DAS의 무작위 샘플링 검증이 도입되면서, 데이터 가용성(DA) 관련 비용 문제는 이제 완전히 과거의 이야기가 되었습니다. 물론 L2 캐시 가격 인하는 좋은 일이지만, 이더 장기적인 ZK 로드맵에 있어 EIP-7825는 진정한 게임 체인저입니다. 왜냐하면 이더 트랜잭션 하나에 대한 가스 상한선(약 1,678만 가스)을 설정했기 때문입니다. 아시다시피, 이더 블록 가스 한도는 올해 6천만으로 증가했습니다. 하지만 이론적으로, 가스 가격이 엄청나게 높다면 누군가는 여전히 블록의 6천만 가스 용량을 모두 채워 블록 전체를 마비시키는 초고속 "메가 트랜잭션"을 보낼 수 있습니다. 그렇다면 왜 단일 트랜잭션의 크기를 제한해야 할까요? 사실 이 변경 사항은 일반 사용자 전송에는 영향을 미치지 않지만, ZK Prover(증명 생성기)에게는 생존이 걸린 문제이며, 이는 ZK 시스템의 증명 생성 방식과도 밀접하게 관련되어 있습니다. 간단한 예를 들자면, EIP-7825 이전에는 블록에 6천만 가스를 소모하는 "메가 트랜잭션"이 포함되어 있을 경우, ZK Prover는 이 매우 복잡한 트랜잭션을 순차적으로 처리해야 했습니다. 분할하거나 병렬화할 수 없었죠. 마치 좁은 외길 고속도로에서 거대한 트럭이 아주 느리게 달리고, 뒤따라오는 작은 차량들(다른 트랜잭션들)은 모두 그 트럭이 지나가기를 기다려야 하는 것과 같습니다. 이는 "실시간 증명"에 치명적인 결과를 초래할 수밖에 없었습니다. 증명 생성 시간이 완전히 예측 불가능하고 수십 분 또는 그 이상 걸릴 수 있었기 때문입니다. EIP-7825 이후에는 블록 크기가 향후 1억 가스까지 확장되더라도, 각 트랜잭션의 가스 소모량이 1,678만 가스로 강제로 제한되기 때문에, 각 블록은 예측 가능하고, 제한적이며, 병렬 처리가 가능한 "작은 작업 단위"로 분할됩니다. 이는 이더 의 증명 생성 과정이 까다로운 "논리 퍼즐"에서 순수한 "돈 문제"로 바뀌었음을 의미합니다. 충분한 병렬 해시레이트 해시레이트 투자된다면, 이러한 작은 작업들을 매우 짧은 시간 안에 동시에 처리하여 거대한 블록에 대한 ZK 증명을 생성할 수 있습니다. 하지만 EIP-7825는 단일 트랜잭션의 크기를 제한함으로써 실시간 증명 생성을 위한 물리적 경로(병렬화)를 마련했지만, 이는 동전의 한 면일 뿐입니다. 다른 한 면은 이더 메인넷 자체가 이 기능을 어떻게 활용하는가에 있습니다. 이는 이더 로드맵에서 가장 핵심적인 부분인 L1 zkEVM과 관련이 있습니다. zkEVM은 오랫동안 이더 확장성의 "성배"로 여겨져 왔는데, 이는 성능 병목 현상을 해결할 뿐만 아니라 블록체인의 신뢰 메커니즘을 재정의하기 때문입니다. zkEVM의 핵심 아이디어는 이더 메인넷이 ZK 증명을 생성하고 검증할 수 있도록 하는 것입니다. 즉, 이더 각 블록이 실행된 후 검증 가능한 수학적 증명을 출력할 수 있으므로 다른 노드(특히 라이트 노드 및 L2)는 계산을 반복하지 않고도 결과의 정확성을 확인할 수 있습니다. ZK 증명 생성 기능이 이더 프로토콜 레이어(L1)에 직접 통합되면, 제안자는 블록을 패키징하고 매번 ZK 증명을 생성하게 되며, 검증 노드는 더 이상 트랜잭션을 다시 실행할 필요 없이 이 간단한 수학적 증명만 검증하면 됩니다.
콘텐츠 출처 
