피드백과 리뷰를 제공한 Justin Drake에게 특별히 감사드립니다.
이더리움이 보안과 분산화를 유지하는 데 있어 충분히 논의되지 않았지만 매우 중요한 방법 중 하나는 다중 클라이언트 철학 입니다. Ethereum에는 의도적으로 모든 사람이 기본적으로 실행하는 "참조 클라이언트"가 없습니다. 대신 공동으로 관리되는 사양(현재는 읽기 쉽지만 매우 느린 Python으로 작성됨)이 있으며 여러 팀이 이에 대해 작업하고 있습니다. 사양의 구현(또한 "클라이언트"라고 함)는 사용자가 실제로 실행하는 것입니다.
각 Ethereum 노드는 합의 클라이언트와 실행 클라이언트를 실행합니다. 현재로서는 네트워크의 2/3 이상을 차지하는 합의 또는 실행 클라이언트가 없습니다. 해당 카테고리에서 클라이언트의 점유율이 1/3 미만인 경우 네트워크는 계속해서 정상적으로 작동합니다. 해당 카테고리(예: Prysm, Lighthouse 또는 Geth)에서 1/3~2/3을 공유하는 클라이언트에 버그가 있는 경우 체인은 계속해서 블록을 추가하지만 완료를 중지하여 개발자가 개입할 시간을 제공합니다.
충분히 논의되지 않았지만 여전히 매우 중요한 이더리움 체인 검증 방식의 다가오는 주요 변화는 ZK-EVM의 등장입니다. EVM 실행을 증명하는 SNARK는 수년간 개발되었으며, 이 기술은 ZK 롤업 이라는 L2 프로토콜에서 활발히 사용됩니다. 이러한 ZK 롤업 중 일부는 현재 메인넷에서 활성화되어 있으며 더 많은 롤업이 곧 출시될 예정입니다. 그러나 장기적으로 ZK-EVM은 롤업에만 사용되는 것이 아니라 L1 실행을 검증하는 데도 사용하고 싶습니다(참조: the Verge ).
이러한 일이 발생하면 ZK-EVM은 오늘날 실행 클라이언트 및 합의 클라이언트만큼 네트워크 보안에 중요한 세 번째 유형의 이더리움 클라이언트가 될 것입니다. 이는 자연스럽게 다음과 같은 질문을 제기합니다. ZK-EVM은 여러 클라이언트와 어떻게 상호 작용합니까? 어려운 부분 중 하나는 이미 완료되었습니다. 우리는 이미 여러 ZK-EVM 구현을 활발하게 개발하고 있습니다. 그러나 다른 어려움은 여전히 남아 있습니다. 이더리움 블록의 정확성을 증명하기 위해 ZK를 위한 "다중 클라이언트" 생태계를 어떻게 만들 수 있습니까? 이 문제는 몇 가지 흥미로운 기술적 과제를 제기하며 물론 절충이 가치가 있는지에 대한 의문도 제기됩니다.
Ethereum의 다중 클라이언트 아이디어에 대한 원래 동기는 무엇입니까?
이더리움의 멀티 클라이언트 개념은 일종의 탈중앙화로 일반적인 탈중앙화와 마찬가지로 사람들은 구조적 탈중앙화의 기술적 이점과 정치적 탈중앙화의 사회적 이점에 집중할 수 있습니다. 궁극적으로 다중 클라이언트에 대한 아이디어는 두 가지 모두에 의해 주도됩니다.
기술을 분산화하는 이유
기술적 분산화의 주요 이점은 간단합니다. 소프트웨어의 버그로 인해 전체 네트워크가 붕괴될 위험이 줄어듭니다. 2010년 비트코인 오버플로 취약점은 이러한 위험의 전형적인 예입니다. 당시 비트코인 클라이언트 코드는 트랜잭션 출력의 합이 오버플로되었는지(최대 정수 264-1을 합산하여 0으로 만드는지) 확인하지 않았기 때문에 누군가 트랜잭션을 만들어 자신에게 수십억 비트코인을 제공했습니다. 취약점은 몇 시간 만에 발견되어 수정이 빠르게 완료되어 네트워크 전체에 신속하게 배포되었지만, 당시 생태계가 성숙해 있었다면 거래소, 브릿지, 기타 구조물에 의해 코인이 차단되었을 것입니다. 공격자가 받아들였습니다. 돈을 많이 벌었을 수도 있어요. 5개의 서로 다른 비트코인 클라이언트가 있는 경우 모두 동일한 버그가 있어서 즉시 포크될 가능성이 낮으며 버그가 있는 포크 측이 실패할 가능성이 높습니다.
치명적인 오류의 위험을 최소화하기 위해 다중 클라이언트 접근 방식을 사용하면 비용이 발생합니다. 대신 합의 실패 오류가 발생하게 됩니다. 즉, 두 명의 클라이언트가 있는 경우 클라이언트가 특정 프로토콜 규칙에 대해 미묘하게 다른 해석을 가질 위험이 있으며 두 해석 모두 합리적이고 돈을 훔치는 것을 허용하지 않지만 불일치로 인해 체인이 절반으로 분할됩니다. . 이러한 유형의 심각한 포크는 이더리움의 역사에서 한 번 발생했습니다 (이전 버전의 코드를 실행하는 네트워크의 아주 작은 부분이 포크된 다른 작은 분할이 있었습니다). 단일 클라이언트 접근 방식을 옹호하는 사람들은 여러 클라이언트 구현을 채택하지 않는 이유로 합의 실패를 언급합니다. 클라이언트가 하나만 있는 경우 해당 클라이언트는 동의하지 않을 수 없습니다. 고객 수가 어떻게 위험으로 변환되는지에 대한 모델은 다음과 같습니다.
물론 나는 이 분석에 동의하지 않는다. 내가 동의하지 않는 주요 사항은 (i) 2010년에 발생한 것과 같은 치명적인 버그가 중요하다는 점과 (ii) 실제로 클라이언트가 단 하나뿐인 경우가 없다는 점 입니다. 후자의 점은 2013년 비트코인 포크 에서 가장 분명하게 드러났습니다: 비트코인 클라이언트의 서로 다른 두 버전 간의 불일치로 인해 체인이 포크되었으며, 그 중 하나는 예기치 않게 단일 블록의 트랜잭션 수를 제한했습니다. 따라서 이론적으로 한 명의 클라이언트는 실제로는 두 명의 클라이언트인 경우가 많으며 이론적으로 다섯 명의 클라이언트는 실제로는 여섯 명 또는 일곱 명의 클라이언트가 될 수 있습니다. 따라서 우리는 위험을 감수하고 최소한 몇 명의 다른 클라이언트에서 위험 곡선의 오른쪽으로 이동해야 합니다.
정치적 분권화의 사례
독점 클라이언트 개발자는 막강한 정치적 권력을 가진 위치에 있습니다. 클라이언트 개발자가 변경 사항을 제안했지만 사용자가 동의하지 않는 경우 이론상으로는 업데이트된 버전의 다운로드를 거부하거나 업데이트 없이 브랜치를 생성할 수 있지만 실제로는 사용자가 이를 수행하기 어려운 경우가 많습니다. 만족스럽지 못한 프로토콜 변경이 필요한 보안 업데이트와 함께 제공되면 어떻게 되나요? 만약 일이 뜻대로 되지 않으면 메이저 팀이 그만두겠다고 위협한다면 어떻게 될까요? 또는 더 간단하게 말하면 독점 클라이언트 팀이 최고의 프로토콜 전문 지식을 갖춘 유일한 팀이 되어 클라이언트 팀의 기술적 주장을 판단할 때 생태계의 나머지 부분을 불리하게 만들고 클라이언트 팀에게 큰 공간을 제공하게 됩니다. 더 넓은 커뮤니티의 목표와 가치와 일치하지 않을 수 있는 자신의 특정 목표와 가치를 홍보하기 위해?
프로토콜 정치에 대한 우려, 특히 일부 행위자가 블록체인의 특정 사용에 공개적으로 반대했던 2013~14년 비트코인 OP_RETURN 전쟁 의 맥락에서 이더리움이 다중 클라이언트 철학을 조기에 채택하는 데 중요한 요소였으며 그 목적은 다음과 같습니다. 그러한 결정은 소수의 사람들에게는 더 어렵습니다. 이더리움 생태계에 특정한 우려 사항, 즉 이더리움 재단 자체 내 권력 집중을 피하는 것은 이러한 방향에 대한 추가 지원을 제공합니다. 2018년에 재단은 이더리움 PoS 프로토콜(즉, 현재 "합의 클라이언트"로 알려진 프로토콜)을 의도적으로 구현하지 않기로 결정하여 해당 작업을 전적으로 외부 팀에 맡겼습니다.
ZK-EVM은 앞으로 어떻게 Layer 1에 진입하게 될까요?
현재 ZK-EVM은 Rollup에 사용됩니다. 이는 값비싼 EVM 실행이 오프체인에서 몇 번만 발생하도록 허용함으로써 확장성을 높이는 반면, 다른 사람들은 EVM 실행 계산의 정확성을 입증하기 위해 온체인에서 발행된 SNARK를 간단히 검증할 수 있습니다. 또한 일부 데이터(특히 서명)가 체인에 포함되지 않도록 하여 가스 비용을 절약할 수 있습니다. 이는 우리에게 많은 확장성 이점을 제공하며 확장 가능한 컴퓨팅을 ZK-EVM과 결합하고 확장 가능한 데이터를 데이터 가용성 샘플링과 결합하면 더욱 확장할 수 있습니다.
그러나 오늘날의 이더리움 네트워크에는 다른 문제도 있습니다. 레이어 2 확장이 아무리 많아도 자체적으로 해결할 수 없는 문제입니다. 레이어 1은 확인하기 어렵기 때문에 자체 노드를 실행하는 사용자가 많지 않습니다. 대신 대부분의 사용자는 단순히 타사 공급자를 신뢰합니다. Helios 및 Succinct와 같은 라이트 클라이언트는 이 문제를 해결하기 위한 조치를 취하고 있지만 라이트 클라이언트는 완전한 유효성 검사 노드와는 거리가 멀습니다. 라이트 클라이언트는 단순히 동기화 위원회라고 불리는 유효성 검사기의 무작위 하위 집합의 서명을 확인합니다. 프로토콜 규칙을 따릅니다. 사용자가 체인이 규칙을 따르는지 실제로 확인하려면 다른 작업을 수행해야 합니다.
옵션 1: 레이어 1을 압축하여 거의 모든 활동을 레이어 2로 이동시킵니다.
시간이 지남에 따라 우리는 블록당 레이어 1 가스 목표를 1,500만 개에서 100만 개로 낮출 수 있습니다. 이는 블록이 단일 SNARK와 일부 입출금 작업을 포함하기에 충분하지만 다른 작업은 너무 많지 않으므로 거의 모든 사용자 활동이 레이어 2 프로토콜로 이동했습니다. 이러한 설계는 여전히 블록당 많은 롤업 제출을 지원할 수 있습니다. 맞춤형 빌더가 실행하는 오프체인 집계 프로토콜을 사용하여 여러 레이어 2 프로토콜에서 SNARK를 수집하고 이를 단일 SNARK로 결합할 수 있습니다. 이러한 세계에서 레이어 1의 유일한 기능은 레이어 2 프로토콜에 대한 정보 교환소 역할을 하고, 그 증거를 확인하고, 때로는 프로토콜 간의 대규모 자금 이체를 촉진하는 것입니다.
이 접근 방식은 효과적이지만 몇 가지 중요한 약점이 있습니다.
• 기존의 많은 L1 기반 애플리케이션이 경제적으로 실행 불가능해지기 때문에 사실상 이전 버전과 호환되지 않습니다 . 수수료가 너무 높아져 계정을 비우는 데 드는 비용을 초과하면 최대 수백 또는 수천 달러의 사용자 자금이 좌초될 수 있습니다. 이 문제는 사용자가 프로토콜 내에서 선택한 L2로의 대량 마이그레이션을 선택하는 메시지에 서명하도록 함으로써 해결될 수 있습니다(여기에서 초기 구현 아이디어 참조). 그러나 이로 인해 전환이 복잡해지고 충분히 저렴해집니다. 어쨌든 레이어 1에는 일종의 SNARK가 필요합니다. 나는 일반적으로 SELFDESTRUCT opcode와 같은 경우 이전 버전과의 호환성을 깨는 것을 좋아하지만 이 경우에는 절충이 덜 유리한 것 같습니다.
• 여전히 검증 비용이 충분히 저렴하지 않을 수 있습니다. 이상적으로 이더리움 프로토콜은 노트북뿐만 아니라 휴대폰, 브라우저 확장 프로그램, 심지어 다른 체인에서도 쉽게 확인할 수 있어야 합니다. 처음으로 체인을 동기화하거나 장기간 오프라인 상태를 유지한 후에도 쉽게 체인을 동기화할 수 있습니다. 랩톱 노드는 약 20밀리초 안에 100만 개의 가스를 검증할 수 있지만, 이는 오프라인으로 하루를 보낸 후 동기화하는 데 54초가 걸린다는 것을 의미합니다(단일 슬롯의 최종 결과로 인해 슬롯 시간이 32초로 증가한다고 가정). 전화 또는 브라우저 확장 기능을 사용하는 경우 각 블록은 수백 밀리초가 걸리며 여전히 무시할 수 없을 만큼 배터리가 소모될 수 있습니다. 이 수치는 관리 가능하지만 이상적이지는 않습니다.
• L2 우선 생태계에서도 L1은 어느 정도 저렴합니다. 사용자가 새로운 상태 데이터를 더 이상 사용할 수 없다는 사실을 알았을 때 자금을 인출할 수 있다면 Validium은 더 강력한 보안 모델의 이점을 누릴 수 있습니다 . L2를 통한 경제적으로 실현 가능한 직접 전송을 위한 최소 크기가 더 작다면 특히 더 작은 토큰의 경우 차익 거래가 더 효율적이 될 것입니다.
따라서 ZK-SNARK를 사용하여 레이어 1 자체를 확인하는 방법을 찾는 것이 더 합리적으로 보입니다.
옵션 2: SNARK – 레이어 1 확인
유형 1(이더리움과 완전히 동일) ZK-EVM은 이더리움 블록의 (계층 1) EVM 실행을 검증하는 데 사용할 수 있습니다. 블록의 합의 측면을 확인하기 위해 더 많은 SNARK 코드를 작성할 수 있습니다. 이는 어려운 엔지니어링 문제가 될 것입니다. 오늘날 ZK-EVM은 이더리움 블록을 확인하는 데 몇 분에서 몇 시간이 걸리며 실시간으로 증명을 생성하려면 (i) SNARK에 적합하지 않은 구성 요소를 제거하기 위해 이더리움 자체를 개선하고, (ii) 전용 하드웨어를 통한 엄청난 효율성 향상, (iii) 더 많은 병렬 처리를 통한 아키텍처 개선. 그러나 이것이 불가능할 근본적인 기술적 이유가 없기 때문에 수년이 걸리더라도 그렇게 될 것이라고 예상합니다.
여기서는 다중 클라이언트 패러다임과의 교차점을 볼 수 있습니다. ZK-EVM을 사용하여 레이어 1을 인증하는 경우 어떤 ZK-EVM을 사용합니까?
세 가지 옵션이 있습니다.
1. 단일 ZK-EVM: 멀티 클라이언트 패러다임을 버리고 단일 ZK-EVM을 선택하여 블록을 검증합니다.
2. 폐쇄형 다중 ZK-EVM: 특정 다중 ZK-EVM 세트에 대한 합의에 도달하고 이를 합의 계층 프로토콜 규칙에 봉인합니다. 즉, 블록은 전체 ZK-EVM 중 절반 이상의 증명이 필요합니다. 유효한 것으로 간주되도록 설정됩니다.
3. 여러 ZK-EVM 열기: 서로 다른 클라이언트는 서로 다른 ZK-EVM 구현을 갖고 있으며, 각 클라이언트는 유효한 블록을 수락하기 전에 자체 구현과의 호환성 증명을 기다립니다.
나에게는 (3)이 이상적이라고 생각됩니다. 적어도 우리 기술이 모든 ZK-EVM 구현이 서로 동등하다는 것을 공식적으로 증명할 수 있는 지점까지 발전하여 가장 효율적인 구현을 선택할 수 있기까지는 그렇습니다. (1) 다중 클라이언트 모델의 이점이 희생되고, (2) 새로운 클라이언트 개발 가능성이 닫히고 보다 중앙화된 생태계로 이어질 것입니다. (3) 어려움이 있지만 적어도 현재로서는 다른 두 가지 옵션보다 덜 어려워 보입니다.
(3)을 구현하는 것은 그리 어렵지 않습니다. 각 증명 유형에 대해 p2p 하위 네트워크가 있으며, 한 가지 유형의 증명을 사용하는 클라이언트는 해당 하위 네트워크를 수신하고 유효성 검사기가 유효하다고 간주하는 증명을 받을 때까지 기다립니다.
(3)의 두 가지 주요 과제는 다음과 같습니다.
• 지연 챌린지 : 악의적인 공격자는 클라이언트에 유효한 블록 및 증명의 게시를 지연시킬 수 있습니다. 다른 클라이언트에게 유효한 증명을 생성하는 데는 실제로 오랜 시간이 걸립니다(예: 15초라도). 이는 임시 포크를 생성하고 여러 슬롯의 체인을 끊을 수 있을 만큼 충분히 깁니다.
• 데이터 비효율성 : ZK-SNARK의 한 가지 이점은 검증에만 관련된 데이터(때때로 "증인 데이터"라고도 함)를 블록에서 제거할 수 있다는 것입니다. 예를 들어 서명이 검증되면 서명을 블록에 저장할 필요가 없습니다. 서명이 유효하다는 것을 나타내는 비트만 저장하고 모든 유효한 서명이 존재하는지 확인하기 위한 증거를 블록에 저장하면 됩니다. 그러나 블록에 대해 여러 유형의 증명을 생성하려면 원본 서명이 실제로 게시되어야 합니다.
단일 슬롯 터미널 프로토콜을 설계할 때 신중하게 처리하면 대기 시간 문제를 해결할 수 있습니다. 단일 슬롯 최종 프로토콜은 슬롯당 2회 이상의 합의 라운드가 필요할 수 있으므로 첫 번째 라운드에는 블록을 포함해야 하고 노드는 세 번째(또는 최종) 라운드에 서명하기 전에 증명만 확인하면 됩니다. 이를 통해 블록 게시 마감일과 증거가 제공될 것으로 예상되는 시간 사이에 항상 상당한 시간 간격이 있음을 보장합니다.
데이터 효율성 문제는 집계 및 검증 관련 데이터에 대해 별도의 프로토콜을 사용하여 해결해야 합니다. 서명의 경우 ERC-4337에서 이미 지원하는 BLS 집계를 사용할 수 있습니다. 검증 관련 데이터의 또 다른 주요 범주는 개인 정보 보호를 위한 ZK-SNARK입니다. 다행스럽게도 이러한 프로토콜에는 일반적 으로 자체 집계 프로토콜이 있습니다 .
SNARK 검증 레이어 1에도 중요한 이점이 있다는 점은 언급할 가치가 있습니다. 온체인 EVM 실행은 더 이상 각 노드의 검증이 필요하지 않으므로 EVM 실행 수가 크게 늘어날 수 있습니다. 이는 레이어 1 가스 한도를 대폭 늘리거나 내장된 롤업을 도입하거나 두 가지를 모두 수행하여 달성할 수 있습니다.
결론적으로
개방형 다중 클라이언트 ZK-EVM 생태계가 제대로 작동하려면 많은 작업이 필요합니다. 하지만 정말 좋은 소식은 대부분의 작업이 진행 중이거나 곧 시작된다는 것입니다.
• 우리는 이미 여러 가지 강력한 ZK-EVM 구현을 보유하고 있습니다. 이러한 구현은 아직 Type 1(Ethereum과 완전히 동일함)은 아니지만 많은 구현이 이 방향으로 적극적으로 움직이고 있습니다.
• Helios 및 Succinct 와 같은 라이트 클라이언트에 대한 작업은 결국 이더리움 체인의 PoS 합의 측면에서 보다 완전한 SNARK 검증으로 바뀔 수 있습니다.
• 클라이언트는 Ethereum 블록의 실행을 증명하기 위해 ZK-EVM을 시도하기 시작할 수 있습니다. 특히 상태를 유지하기 위해 기술적으로 각 블록을 직접 재실행할 필요가 없는 상태 비저장 클라이언트가 있는 경우 더욱 그렇습니다. 재실행을 통해 이더리움 블록을 검증하는 클라이언트에서 SNARK 증명을 확인하여 이더리움 블록을 검증하는 대다수 클라이언트로 전환할 가능성이 크며 이는 느리고 점진적인 전환이 될 것입니다.
• ERC-4337 및 PBS 생태계는 가스 비용을 절약하기 위해 BLS 및 증명 집계와 같은 집계 기술을 곧 사용하기 시작할 수 있습니다. BLS 집계 작업은 이미 시작되었습니다 .
이러한 기술을 통해 미래는 매우 밝아 보입니다. 이더리움 블록은 오늘날보다 작을 것이며 누구든지 이더리움 다중 클라이언트 철학을 동시에 유지하면서 노트북, 휴대폰 또는 브라우저 확장에서 완전히 검증된 노드를 실행할 수 있습니다.
장기적으로는 물론 어떤 일이든 일어날 수 있습니다. 아마도 인공 지능은 공식 검증을 강화하여 ZK-EVM 구현이 동등하다는 것을 쉽게 증명하고 둘 사이의 차이를 유발하는 모든 버그를 식별할 수 있습니다. 그러한 프로젝트는 지금부터 시작해야 할 것일 수도 있습니다. 이러한 공식적인 검증 기반 접근 방식이 성공한다면 프로토콜의 지속적인 정치적 분산 구현을 보장하기 위해 다양한 메커니즘을 마련해야 합니다. 어쩌면 그때쯤이면 프로토콜이 "완전"하다고 간주되어 불변성 표준이 더욱 강화될 것입니다. 그러나 이것이 더 먼 미래라고 하더라도 개방형 다중 클라이언트 ZK-EVM 세계는 어쨌든 일어날 수 있는 자연스러운 디딤돌처럼 보입니다.
단기적으로 이것은 여전히 긴 여정입니다. ZK-EVM은 이미 존재하지만 ZK-EVM이 레이어 1에서 실제로 실행 가능하려면 유형 1이 되어야 하며 실시간으로 발생할 수 있을 만큼 빠르게 입증되어야 합니다. 충분한 병렬화가 가능하다면 실현 가능하지만 거기에 도달하려면 여전히 많은 작업이 필요합니다. KECCAK, SHA256 및 기타 해시 함수의 사전 컴파일 가스 비용 증가와 같은 합의 변화도 그림의 중요한 부분이 될 것입니다. 즉, 전환의 첫 번째 단계는 예상보다 빨리 발생할 수 있습니다. 일단 Verkle 트리와 상태 비저장 클라이언트로 전환하면 클라이언트는 점차적으로 ZK-EVM을 사용하여 "개방형 다중 ZK-EVM으로의 전환" 세계로 이동할 수 있습니다. 자체적으로 시작될 수 있습니다.
