Vitalik：이더리움의 다중 클라이언트 개념은 ZK-EVM과 어떻게 상호작용할까요?

원문 제목：How willEthereum'smulti-client philosophy interact with ZK-EVM?

원문 저자：Vitalik Buterin

편집：첸원，ChainCatcher

이더리움은 다중 클라이언트 단 철학을 통해 보안성과 탈중앙화를 유지하는 것이 매우 중요하지만, 이에 대한 심도 있는 논의는 부족했다. 이더리움은 모든 사람이 기본적으로 실행할 수 있는 "참조 클라이언트"를 설계하지 않았고, 대신 사용자 협력 관리의 규범을 설정했다(최근 가독성이 좋지만 속도가 느린 Python으로 작성됨). 여러 팀이 이 규범(즉, "클라이언트")을 구현하고 있으며, 이는 사용자가 실제로 실행하는 것이다.

*모든 이더리움 노드는 하나의 합의 클라이언트와 하나의 실행 클라이언트를 실행한다. 현재까지 네트워크에서 2/3 이상의 점유율을 차지하는 합의 또는 실행 클라이언트는 없다. 만약 점유율이 1/3 미만인 클라이언트가 * 오류 *를 발생시키면, 네트워크는 * 정상 *적으로 * 작동 *할 것이다. 만약 점유율이 1/3에서 2/3 사이인 클라이언트(예: Prysm, Lighthouse 또는 Geth)가 * 오류 *를 발생시키면, 체인은 계속해서 블록을 추가하지만 블록의 최종 확정이 중단되어, * 개발자 가 개입할 시간을 갖게 된다.

이더리움 증명의 검증 방식 중 하나는 충분히 논의되지 않았지만 다가오는 중요한 변화는 ZK-EVM의 부상이다. EVM 실행을 증명하는 SNARK는 수년간 개발되어 왔으며, 이 기술은 ZK 롤업이라는 L2 프로토콜에서 적극적으로 채택되고 있다. 일부 ZK 롤업은 메인넷에서 활발히 운영되고 있으며, 더 많은것들이 곧 등장할 예정이다. 그러나 장기적으로 ZK-EVM은 롤업에만 국한되지 않고, 1층의 실행 상황을 검증하는 데에도 사용하고자 한다.

이렇게 되면 ZK-EVM은 사실상의 세 번째 이더리움 클라이언트가 되며, 현재의 실행 클라이언트와 합의 클라이언트와 마찬가지로 네트워크의 보안에 중요한 역할을 하게 된다. 이는 자연스럽게 질문을 불러일으킨다: ZK-EVM은 다중 클라이언트 철학과 어떻게 상호작용할 것인가? 해결된 난점 중 하나는 이미 존재한다: 우리는 여러 ZK-EVM 구현을 보유하고 있으며, 적극적으로 개발 중이다. 그러나 다른 어려운 부분은 여전히 존재한다: 우리는 어떻게 "다중 클라이언트" 생태계를 ZK 증명을 통해 이더리움 블록의 정확성에 실제로 적용할 것인가? 이 질문은 몇 가지 흥미로운 기술적 도전을 가져오며, 물론 이러한 절충이 가치가 있는지에 대한 시급한 질문도 있다.

이더리움의 다중 클라이언트 철학의 초기 동기는 무엇인가?

이더리움의 다중 클라이언트 철학은 탈중앙화의 한 형태로, 일반적인 탈중앙화와 마찬가지로, 사람들은 아키텍처의 탈중앙화가 가져오는 기술적 이점과 정치적 탈중앙화가 가져오는 사회적 이점 모두에 주목할 수 있다. 궁극적으로 다중 클라이언트 철학은 이 두 가지에 의해 촉진되며, 이 두 가지를 위해 봉사한다.

기술적 탈중앙화

기술적 탈중앙화의 주요 이점은 간단하다: 소프트웨어의 하나의 오류가 전체 네트워크의 완전한 붕괴를 초래할 위험을 줄인다. 이러한 위험을 나타내는 역사적 사례는 2010년 비트코인의 오버플로우 버그이다. 당시 비트코인 클라이언트 코드는 거래 출력의 총합이 오버플로우되는지를 검사하지 않았고(264-1을 초과하는 최대 정수를 더하여 0으로 돌아감), 따라서 누군가 오버플로우 거래를 수행하여 수십억 개의 비트코인을 얻었다. 이 오류는 몇 시간 내에 발견되었고, 수정 프로그램이 서둘러 전체 네트워크에 배포되었다. 만약 당시 성숙한 생태계가 있었다면, 이러한 토큰은 거래소, 브리지 및 기타 기관에서 수용되었을 것이고, 공격자는 자금을 빼돌릴 수 있었을 것이다. 그러나 만약 당시 다섯 개의 서로 다른 비트코인 클라이언트가 있었다면, 이들이 모두 동일한 취약점을 가질 가능성은 낮았을 것이고, 즉시 분열이 발생했을 것이며, 취약점이 있는 쪽이 패배했을 것이다.

다중 클라이언트를 사용하여 재앙적인 취약점의 위험을 줄이는 것은 대가가 따른다: 당신은 합의 실패의 취약점을 얻을 가능성이 있다: 만약 두 개의 클라이언트가 특정 프로토콜 규칙에 대한 해석에서 미세한 차이를 보인다면, 두 가지 해석 모두 자금 도용을 방지하는 데 매우 합리적일지라도, 이러한 분열은 체인이 두 개로 나뉘게 만든다. 이러한 유형의 심각한 분열은 이더리움 역사에서 한 번 발생한 적이 있다(더 작은 분열도 발생했다).

단일 클라이언트 접근법의 옹호자들은 합의 실패를 인용하며, 여러 구현이 필요 없다고 주장한다: 만약 하나의 클라이언트만 있다면, 그 클라이언트는 스스로와 분열되지 않을 것이다. 그들이 클라이언트 수가 위험을 초래한다고 주장하는 모델은 다음과 같을 수 있다:

물론, 나는 이러한 분석에 동의하지 않는다. 왜냐하면 (1) 2010년의 재앙적인 취약점도 고려해야 하며, 당시 상황도 심각했기 때문이다; (2) 단일 클라이언트 상황은 실제로 존재하지 않았다. 이는 2013년 비트코인 포크 사건에서 가장 뚜렷하게 나타났다: 두 개의 서로 다른 버전의 비트코인 클라이언트 간의 분열로 인해, 하나의 버전이 단일 블록에서 수정 가능한 객체 수에 대해 예기치 않은, 기록되지 않은 제한을 두어 체인이 분열되었다. 따라서 이론적인 "하나의 클라이언트"는 실제로는 두 개의 클라이언트가 되는 경우가 많고, 이론적인 다섯 개의 클라이언트는 실제로는 여섯 개 또는 일곱 개의 클라이언트가 될 수 있다. 그러므로 우리는 위험 곡선(위 그림)의 오른쪽을 선택하여, 적어도 몇 개의 서로 다른 클라이언트를 보유하는 것이 좋다.

정치적 탈중앙화

독점적인 클라이언트 개발자는 큰 정치적 권력을 가진다. 만약 클라이언트 개발자가 변화를 제안하고 사용자가 동의하지 않는다면, 이론적으로 그들은 업데이트된 버전을 다운로드하는 것을 거부하거나, 해당 버전이 없는 포크를 생성할 수 있다. 하지만 실제로 사용자는 이를 수행하기가 어렵다. 만약 이러한 불쾌한 프로토콜 변화가 필수적인 보안 업데이트와 함께 묶여 있다면? 만약 주요 팀이 탈퇴하겠다고 위협한다면? 또는 더 일반적인 경우는, 독점적인 클라이언트 팀이 프로토콜 지식 측면에서 가장 전문적인 유일한 그룹이라면? 이 경우 생태계의 다른 구성원들은 클라이언트 팀이 제안하는 기술적 주장이 적절한지 판단하기 어려워지며, 클라이언트 팀은 자신의 목표와 가치관을 추진할 수 있는 큰 공간을 가지게 된다. 이러한 목표와 가치관은 커뮤니티의 더 넓은 추구와 일치하지 않을 수 있다면 어떻게 해야 할까?

프로토콜 정치에 대한 관심은 특히 2013-14년 비트코인 OP_RETURN 전쟁에서 비롯되며, 당시 일부 참여자들은 특정 용도에 대한 차별적 체인을 공개적으로 지지했다. 이는 이더리움이 초기 다중 클라이언트 철학을 채택하는 중요한 요소 중 하나로, 이러한 상황이 다시 발생하는 것을 피하기 위한 것이다. 이더리움 생태계에 대한 관심, 즉 이더리움 재단 자체에 권력이 집중되는 것을 피하는 것도 이 방향을 더욱 지지한다. 2018년 팀은 이더리움 PoS 프로토콜(즉, 현재의 "합의 클라이언트")을 이더리움 재단이 구현하지 않도록 결정하고, 이 작업을 완전히 외부 팀에 맡기기로 했다.

ZK-EVM은 앞으로 1층에서 어떻게 나타날 것인가?

현재 ZK-EVM은 롤업에 사용되고 있다: 비용이 많이 드는 EVM 실행을 체인 외부에서 몇 번 수행하고, 다른 사람들은 체인에서 EVM 실행 계산이 올바른지 검증하는 SNARK를 검증하여 확장을 가능하게 한다. 또한 일부 데이터(특히 서명)는 수수료를 절약하기 위해 체인에 포함되지 않을 수 있다. 이는 많은 확장성 이점을 제공하며, ZK-EVM과 데이터 가용성 샘플링을 결합하면 큰 확장성을 가져올 수 있다.

그러나 오늘날 이더리움 네트워크는 제2층 확장 솔루션이 해결할 수 없는 다른 문제에 직면해 있다: 제1층은 검증하기 어려워서, 자신의 노드를 실행하는 사용자가 많지 않다. 반대로, 대부분의 사용자는 제3자 공급업체만 신뢰한다. Helios와 Succinct와 같은 경량 클라이언트가 이 문제를 해결하기 위해 조치를 취하고 있지만, 경량 클라이언트는 완전한 검증 노드가 아니다: 경량 클라이언트는 무작위 검증자(일명 "동기 위원회")의 서명만 검증하고, 체인이 실제로 프로토콜 규칙을 준수하는지 여부는 검증하지 않는다. 사용자가 실제로 체인이 규칙을 준수하는지 검증할 수 있도록 하려면 변화를 만들어야 한다.

옵션 1: 제1층 축소, 거의 모든 활동을 제2층으로 강제 전환

우리는 각 블록의 제1층 가스 목표를 1500만에서 100만으로 점진적으로 줄일 수 있다. 이는 하나의 블록이 SNARK와 일부 입출금 작업을 포함할 수 있을 만큼 충분하지만, 너무 많은 다른 작업을 수행할 수 없게 하여 거의 모든 사용자 활동을 제2층 프로토콜로 전환하도록 강제한다. 이러한 설계는 각 블록에서 많은 롤업을 제출하는 것을 여전히 지원할 수 있다: 우리는 맞춤형 빌더가 운영하는 체인 외 집계 프로토콜을 사용하여 여러 제2층 프로토콜에서 SNARK를 집계하고 하나의 SNARK로 병합할 수 있다. 이렇게 되면 제1층의 유일한 기능은 제2층 프로토콜의 교환 센터가 되어, 제2층의 증명을 검증하고, 가끔 그들 간의 대규모 자금 이동을 촉진하는 것이다.

이 방법은 작동할 수 있지만, 몇 가지 중요한 약점이 있다:

1. 사실상 하위 호환성이 없다. 즉, 많은 기존 L1 기반 애플리케이션이 경제적으로 실행 불가능해질 것이다. 수수료가 너무 비싸져서 이러한 계좌를 비우는 비용을 초과할 수 있으며, 사용자의 자금이 동결될 수 있다. 사용자가 정보를 서명하여 대규모로 L2로 전환하는 것을 허용하면 이 문제를 해결할 수 있지만, 이는 전환의 복잡성을 증가시킨다. 또한, 진정한 저비용을 실현하려면 제1층에서 어떤 형태의 SNARK를 구현해야 한다. SELFDESTRU와 같은 경우에는 일반적으로 하위 호환성을 깨는 것에 동의하지만, 이 경우에는 하위 호환성을 포기하는 것을 권장하지 않는다.

2. 검증 비용이 크게 줄어들지 않는다. 이상적으로 이더리움 프로토콜은 노트북뿐만 아니라 휴대폰, 브라우저 플러그인, 심지어 다른 체인 내에서도 쉽게 검증할 수 있어야 한다. 체인을 처음 동기화하거나 오랜 시간 오프라인 후에 체인을 동기화하는 것도 쉬워야 한다. 노트북 노드는 약 20밀리초 내에 100만 가스를 검증할 수 있지만, 이 경우에도 오프라인 상태에서 하루가 지나면 동기화하는 데 54초가 걸린다(단일 슬롯의 종단 시간https://notes.ethereum.org/@vbuterin/singleslotfinality 시간이 32초로 증가한다고 가정할 때). 휴대폰이나 브라우저 플러그인의 경우, 각 블록은 몇 백 밀리초가 걸릴 수 있으며, 이는 여전히 무시할 수 없는 배터리 소모를 초래할 수 있다. 이러한 수치는 통제 가능하지만, 우리의 이상적인 기대에 부합하지 않는다.

3. L2 우선 생태계에서도 L1은 비용이 적게 이익을 얻을 수 있다. Validiums는 더 강력한 보안 모델로부터 이익을 얻을 수 있으며, 사용자가 새로운 상태 데이터가 더 이상 사용 가능하지 않다고 판단하면 자금을 철회할 수 있다. 경제적으로 실행 가능한 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 의 두 가지 주요 도전 과제는 다음과 같다:

1) 지연: 악의적인 공격자가 블록과 클라이언트에 유효한 증명의 게시를 지연시킬 수 있으며, 이는 다른 클라이언트에 유효한 증명을 생성하는 데 오랜 시간이 걸릴 수 있다(즉, 15초가 걸릴 수 있음). 이 시간은 임시 분기를 생성하고 몇 개의 시간 슬롯 내에서 체인에 간섭할 수 있는 충분한 시간이다.

2) 데이터 효율성 저하: ZK-SNARK의 이점 중 하나는 검증과 관련된 데이터(때때로 "증인 데이터"라고 불림)를 블록에서 제거할 수 있다는 것이다. 예를 들어, 서명을 검증한 후에는 블록에 해당 서명을 보관할 필요가 없으며, 이 서명이 유효하다는 것을 나타내는 비트만 저장하고, 블록에 모든 유효한 서명의 존재를 확인하는 증명을 저장할 수 있다. 그러나 우리가 하나의 블록에 대해 여러 유형의 증명을 생성하려면, 원래 서명이 실제로 공개되어야 한다.

지연 문제는 신중하게 설계된 단일 슬롯 결정성 프로토콜을 통해 해결할 수 있다. 단일 슬롯 결정성 프로토콜은 각 슬롯에서 두 번 이상의 합의를 요구할 수 있으며, 따라서 첫 번째 라운드에 블록을 포함하고, 노드가 세 번째 라운드(또는 마지막 라운드)에서 서명하기 전에 증명을 검증하도록 요구할 수 있다. 이는 블록 게시 마감 시간과 예상 증명 가용성 시간 사이에 항상 중요한 시간 창을 남길 수 있다.

데이터 효율성 문제를 해결하려면 검증 관련 데이터를 집계하기 위한 별도의 프로토콜이 필요하다. 서명의 경우, 우리는 BLS 집계를 사용할 수 있으며, ERC-4337은 이 기능을 지원한다. 검증과 관련된 또 다른 주요 데이터 유형은 ZK-SNARK이며, 이는 프라이버시 보호에 사용된다. 이러한 데이터는 일반적으로 자체 집계 프로토콜을 가진다.

또한 SNARK-검증 제1층은 중요한 이점이 있다: 체인에서 EVM 실행이 더 이상 각 노드에 의해 검증될 필요가 없으므로, EVM 실행량이 크게 증가할 가능성이 있으며, 이는 제1층의 가스 한도를 크게 늘리거나 내재된 롤업 (enshrined rollup)을 도입하거나 두 가지 모두를 채택하여 실현할 수 있다.

결론

다중 클라이언트 ZK-EVM 생태계의 원활한 운영을 구현하는 것은 쉽지 않다. 그러나 좋은 소식은 이러한 작업의 대부분이 이미 진행 중이거나 곧 진행될 것이라는 점이다:

• 우리는 여러 강력한 ZK-EVM 구현을 보유하고 있으며, 이들은 아직 1형 EVM(완전히 이더리움과 동일함)은 아니지만, 그 중 많은 수가 이 방향으로 적극적으로 발전하고 있다.

• 경량 클라이언트(예: Helios 및 Succinct)에 대한 작업은 궁극적으로 이더리움 체인 PoS 합의에 대한 보다 포괄적인 SNARK 검증으로 이어질 수 있다.

• 클라이언트는 ZK-EVM을 사용하여 이더리움 블록의 실행을 스스로 증명하기 시작할 수 있으며, 특히 우리가 무상태 클라이언트를 구현할 수 있을 때, 기술적으로 각 블록을 직접 재실행하지 않고도 상태를 유지할 수 있다. 우리는 클라이언트가 이더리움 블록을 재실행하여 검증하는 것에서, 대부분의 클라이언트가 SNARK 증명을 확인하여 이더리움 블록을 검증하는 것으로 점진적인 전환을 진행할 수 있다.

• ERC-4337 및 PBS 생태계는 곧 BLS 및 증명 집계와 같은 집계 기술을 사용하여 수수료 비용을 절감하기 시작할 수 있다. BLS 집계에 대한 관련 작업도 시작되었다.

이러한 기술이 자리 잡으면 미래는 밝다. 이더리움 블록은 지금보다 더 작아질 것이며, 누구나 자신의 노트북이나 심지어 휴대폰 또는 브라우저 플러그인에서 완전 검증 노드를 실행할 수 있게 될 것이며, 이 모든 것은 이더리움의 다중 클라이언트 철학을 유지하는 데 필요할 것이다.

더 먼 미래에는 모든 일이 일어날 수 있다. 어쩌면 인공지능이 형식 검증의 성능을 크게 향상시켜 ZK-EVM 구현의 동등성을 쉽게 증명하고, 이들 간의 차이를 초래하는 모든 취약점을 식별할 수 있게 될 것이다. 우리는 지금 이 프로젝트를 시작해야 할지도 모른다. 만약 이러한 형식 검증 기반 접근 방식이 성공한다면, 프로토콜의 지속적인 정치적 권력 탈중앙화를 보장하기 위한 다양한 메커니즘을 구축해야 할 것이다. 아마도 그때는 프로토콜이 "완전한" 것으로 간주되고, 불변의 규범이 더 강력해질 것이다. 그러나 심지어 먼 미래에도 개방형 다중 클라이언트 ZK-EVM은 결국 도래할 세계이다.

단기적으로는 모든 것이 험난할 수 있다. ZK-EVM은 이미 등장했지만, ZK-EVM이 제1층에서 진정으로 실행 가능해지려면 1형 ZK-EVM이 되어야 하며, 빠르고 실시간으로 증명을 생성해야 한다. 충분한 병렬성을 확보하면 이를 실현할 수 있지만, 여전히 많은 작업이 필요하다. KECCAK, SHA256 및 기타 해시 함수의 사전 컴파일 수수료를 높이는 것과 같은 합의 변화도 미래 청사진의 중요한 부분이 될 것이다. 전환의 첫 단계는 우리가 예상하는 것보다 더 빨리 발생할 수 있다: 우리가 워커 트리와 무상태 클라이언트로 전환하면, 클라이언트는 점진적으로 ZK-EVM을 사용하기 시작할 수 있으며, "개방형, 다중 ZK-EVM" 세계로의 전환은 자동으로 발생할 수 있다.