의견: Ethereum의 로드맵이 변경되어야 합니까?
편집자 주: 이 기사의 출처는이더리움 애호가(ID: ethfans), 저자: A Jian, Odaily에서 승인을 받아 복제했습니다.
이더리움 애호가(ID: ethfans)중국어 번역이더리움 애호가(ID: ethfans)
, 저자: A Jian, Odaily에서 승인을 받아 복제했습니다."롤업 중심의 이더리움 로드맵"에서 (중국어 번역
) 기사가 게시된 이후 전체 커뮤니티에서 이더리움(특히 이더리움 2.0)의 로드맵에 대한 질문을 제기했습니다.
발췌문의 중국어 번역
), Vitalik은 로드맵이 변경되었음을 분명히 했습니다. 즉, Eth1-Eth2의 합병 후 비콘 체인 블록에 직접 트랜잭션이 포함되는 실행 기능이 있습니다. 병합은 병렬로 추진되며, 어느 모듈이든 준비가 되는 즉시 롤아웃됩니다.
Eth2.0의 3단계 로드맵
0단계: PoS를 합의 메커니즘으로 사용하는 비콘 체인
1단계: 다중 샤드 체인
2단계: 모든 샤드에 실행 기능 추가
지난 2년 동안 널리 퍼진 Eth2.0 로드맵은 세 가지 순차적 구성 요소를 계획했습니다.
0단계: PoS를 합의 메커니즘으로 사용하는 비콘 체인
1단계: 다중 샤드 체인
2단계: 모든 샤드에 실행 기능 추가
이 로드맵에서 이더리움 2.0의 원래 목표는 "샤드 실행" 시스템을 만드는 것임을 분명히 알 수 있습니다. 즉, 각 샤드에는 자체 상태가 있으며 이러한 상태는 다음과 같이 나뉩니다. 각 샤드의 상태 전환 규칙은 다음과 같습니다. 변경된 상태는 비콘 체인에 의해 확정되므로 이더리움 2.0은 여러 개의 샤드가 병렬로 트랜잭션을 처리할 수 있는 시스템이 됩니다. 이것은 또한 이더리움 2.0이 "합의"와 "트랜잭션 처리(검증)"의 분리된 시스템임을 의미합니다. 각 샤드에 할당된 검증자는 트랜잭션 및 상태의 정확성을 검증할 책임이 있습니다. 비콘 체인의 획기적 종료 메커니즘으로 인해 두 프로세스가 완전히 동기화되지 않았습니다.
이 "PoS 비콘 체인 + 다중 샤드" 아키텍처는 또한 PoS 알고리즘 자체의 특성을 잘 활용하는 것으로 보입니다. 즉, 지분이 없는 문제를 해결하기 위해(PoS 블록은 계산을 지불할 필요가 없으므로 그들은 자격이 있습니다 블록을 생성한 계정은 동시에 다른 포크에서 블록을 생성하려고 시도하여 시스템이 무너지게 합니다. 블록 생성을 위해 검증자가 블록 생성 자격을 남용하는 경우(예: 동시에 두 개의 포크를 지원하는 경우) 예치금에 벌금이 부과됩니다. 서로 독립적으로 변경: 하나는 보통이고 다른 하나는 사용자의 상태이고 다른 하나는 검증자의 블록 가중치 상태입니다. 합의 프로세스는 블록 가중치 상태를 기반으로 하며 합의에 도달하면 블록도 변경됩니다. 가중치 상태; 따라서 합의 프로세스는 결합을 해결할 수 있는 사용자 트랜잭션의 검증과 본질적으로 독립적입니다. 샤드 병렬 실행이 가능해집니다.
그 확장성에 관해서는 이더리움 샤딩 기술인 "Quadratic sharding(Quadratic sharding)"이라는 이름이 실마리를 드러냅니다. 그런 다음 조각화된 실행 아키텍처는 참여 노드의 처리 용량이 선형적으로 증가함에 따라 전체 시스템의 처리 용량을 2차적으로 증가시킬 수 있습니다. 상식적으로 말하면, 네트워크에 참여하는 노드(평균)가 일정 시간 내에 4개의 블록 헤더를 검증할 수 있다면, 샤드에 참여하는 노드는 동시에 4개의 트랜잭션을 검증할 수 있다는 의미입니다. 시스템은 4 샤드 × 4 트랜잭션/샤드 = 16 트랜잭션이며, 노드의 처리 용량이 8(2배)이 되면 처리 용량은 64 트랜잭션(4배)이 됩니다.
좋게 들리지만 "제곱 수준 확장" 인수에는 다음과 같은 가정이 포함됩니다.
(1) 샤드 트랜잭션의 검증을 블록 헤더 검증과 같은 난이도로 단순화하는 기술이 있습니다.
(2) 교차 샤드 트랜잭션이 없습니다. 즉, 각 샤드의 트랜잭션은 서로 전혀 의존하지 않습니다. 크로스 샤드 트랜잭션은 여러 샤드의 처리 용량을 점유해야 하며 비콘 체인의 처리 용량도 점유해야 확장성이 크게 감소합니다.
(1)과 관련하여 이 가정이 충족될 가능성이 높습니다. 상태 비저장이 그러한 기술입니다. 그 아이디어는 거래를 전파할 때(또는 블록을 전파할 때) 교환기(목격자)의 액세스 상태에 대한 증거가 있으므로 트랜잭션 검증자는 트랜잭션 실행 시 상태 데이터를 보유하지 않고도 트랜잭션의 유효성을 검증할 수 있습니다. 이는 매우 중요합니다.무국적 상태가 없으면 샤드 검증에 참여하는 검증자는 샤드의 상태를 저장해야 합니다. 즉, 모든 샤드의 블록을 지속적으로 다운로드하고 트랜잭션을 처리해야 전체 시스템이 큰 블록 시스템으로 붕괴됩니다(예: 16개의 트랜잭션을 처리할 수 있는 리소스를 투자하고 16개의 트랜잭션을 처리). 불행히도 지금까지 Ethereum 1.0은 충분히 가벼운 상태 비저장 방법을 개발하지 못했습니다.
의심스러운 확장성 외에도 샤드 실행은 경제적으로 흥미로운 여러 가지 문제를 제기합니다. 예를 들어 크로스 샤드 트랜잭션의 처리 시간이 내부 샤드 트랜잭션의 처리 시간을 초과하는 경우(이는 불가피함) 다른 샤드의 ETH 값이 동일하지 않음을 의미합니다. 마치 미국 안에 있는 1달러가 실제로 미국 밖의 1달러와 같지 않은 것과 같습니다. 얼마나 많은 샤드가 있든 간에 적어도 두 개의 ETH 가격이 있을 것인데, 하나는 금융 애플리케이션이 가장 풍부한 샤드(즉, Eth1 샤드)의 ETH 가격이고, 다른 하나는 다른 샤드의 ETH 가격입니다. 샤드 후자는 일정 수수료를 지불해야 하고 전자와 교환되기까지 일정 시간을 지불해야 하므로 전자에 대한 약간의 할인이 있어야 합니다. 마찬가지로 각 샤드에 유니스왑이 있더라도 서로 다른 샤드에서 시장의 트랜잭션 슬리피지는 달라야 하고 결국 모두가 하나의 샤드로 수렴하게 되는데 모두가 모일 때 유동성이 가장 풍부하기 때문이다. 자본 효율성이 가장 높습니다. . 어느 정도는 크로스 샤드 트랜잭션이 거의 필요하지 않다고 생각할 수 있지만 이는 다른 샤드의 유휴 트랜잭션 처리 용량이 전혀 의미가 없음을 의미하기도 합니다.
분할 실행 시스템의 기술적 어려움은 여기서 반복하지 않을 것이며 이해 당사자는 분할 실행 시스템이 처리 수수료를 지불하는 방법에 대해 생각할 수 있습니다. 그러나 여기서 말하고 싶은 것은 파편화된 실행 시스템의 설계 개념은 모든 사람의 실제 요구에 위배되며 사물의 발전 법칙에도 위배된다는 것입니다. 글로벌 상태(결합성)는 문제가 아니라 모두에게 꼭 필요한 것입니다. 프로토콜 계층에서 가치 순환을 위해 마찰을 일으키는 것은 자멸적입니다. 좋은 기본 레이어가 있으면 이 기본 레이어를 유지하고 사용자가 나머지를 선택하게 하고 생태가 스스로 진화하도록 하는 방법을 찾아야 합니다. 디자인이 생태를 디자인할 수 있다고 생각하지 마십시오. 모두에게.
단편화된 실행(2단계)의 보류는 그 어려움을 증명합니다. 가까운 미래에 이 경로는 만족스러운 결과를 생성하지 못할 것입니다. 그렇다고 해서 Eth2.0의 연구자들이 3단계 로드맵을 완전히 포기한 것은 아니라고 비탈릭도 강조했다.
그러나 사실 조각화 실행을 포기하는 것이 이더리움이 선택해야 할 길이다.
보조 제목
실행 가능한 비콘 체인 로드맵
이더리움 2.0의 새로운 로드맵에서 가장 눈에 띄는 점은 비콘체인 블록이 병합된 Eth1 샤드의 트랜잭션을 담게 된다는 것, 즉 비콘체인이 실행 기능을 갖는다는 점이다. 다른 샤드는 데이터를 저장하는 기능만 있습니다.
사실, 새로운 로드맵에서 "데이터 샤딩"의 포지셔닝은 "롤업을 위한 데이터 가용성(data availability) 계층"입니다.
실행 가능한 샤딩이 없으면 2차 확장이 불가능합니다. 그렇다면 이 "PoS Layer-1 + 롤업 + 롤업 데이터가 메인 체인 블록 공간을 차지하지 않는다" 아키텍처의 확장성은 무엇입니까?
이 질문에 답하기 위해 롤업 방식과 메인 체인 간의 상호 작용 모드를 살펴보겠습니다.
먼저 롤업 시스템을 상태 비저장 계약으로 이해할 수 있습니다.이 계약의 내부 상태(사용자가 얼마나 많은 돈을 가지고 있는지)는 외부 세계에 표시되지 않지만 계약에서 발생하는 모든 트랜잭션의 데이터는 정기적으로 공개하고 메인 체인에 게시하여 제3자가 이러한 데이터를 얻은 후 계약의 내부 상태를 재구성할 수 있도록 합니다.
유효성 증명을 사용하는 롤업(예: zkRollup)의 특성은 다음과 같습니다. 계약이 트랜잭션 데이터를 공개할 때마다 이러한 트랜잭션이 올바르게 실행되었다는 "계산 무결성 증명"이 제공되므로 새로운 상태 루트는 XXX여야 합니다. 증명이 계약 검증을 통과할 수 있으면 계약은 상태 루트를 업데이트하고 증명이 검증을 통과하지 못하면 계약은 업데이트를 거부합니다.
오류 증명을 사용하는 롤업(예: 낙관적 롤업) 방식은 그 반대입니다. 계약에 대한 거래 데이터를 공개할 때마다 보증금을 예치하고 계약의 새로운 상태 루트가 YYY라고 주장해야 합니다. , 누구든지 예치금을 입금하고 주장에 이의를 제기하기 위해 거짓 증거를 발행할 수 있습니다. 거짓 증거는 트랜잭션 배치에 결함이 있거나 트랜잭션 처리 후 새로운 상태가 전혀 YYY가 아님을 증명합니다. 허위 주장을 한 사람 보증금이 손실되며 일정 기간 동안 아무도 이의를 제기하지 않으면 계약 업데이트 상태 루트는 YYY입니다.
이 두 가지 솔루션은 체인에 데이터를 게시해야 하므로 체인의 공간을 차지하게 되며, 또한 체인의 공간 크기에 따라 롤업 시스템의 단위 시간당 처리 용량(예: TPS)이 결정됩니다. 조금 더 깊이 생각해보면 이러한 트랜잭션 데이터를 데이터 제약이 적은 곳, 즉 Layer-1 블록의 공간을 차지하지 않는 곳에서 해제할 수 있다면 처리 용량을 두 배로 늘릴 수 있습니다. 그런 곳이 많으면 배가되는 효과도 낼 수 있다.
(1) "다운로드하려면 다운로드하고 다운로드하지 않으려면 다운로드하지 마십시오"라는 이 방법은 zk 롤업에서 전혀 작동하지 않습니다. zk 롤업이 상태 루트를 업데이트하려고 할 때 zk 롤업 계약 업데이트 작업(즉, Layer-1)도 증명을 수락할 때 증명에 해당하는 트랜잭션 데이터를 얻어야 합니다. 그렇지 않으면 검증을 통과하지 못합니다. (트랜잭션 데이터를 제공할 필요가 없으며 롤업이 아닌 Validium이라는 증명만 검증하여 계약 상태의 루트를 승격시키는 솔루션도 있습니다.) 즉, zk 롤업만 고려한다면 "데이터 샤딩" 방식은 대역폭 측면에서 큰 블록과 다르지 않습니다. 데이터가 누구에게 전송되고 처음에 어디에 저장되었는지에 관계없이 모든 노드는 데이터를 다운로드해야 합니다.
결론적으로
(2) 낙관적 롤업의 경우 보다 낙관적인 가정을 할 의향이 있다면 물론 할 수 있습니다.거래 데이터를 전혀 다운로드할 수 없으며 최신 상태 최종 루트만 유지합니다.분쟁 발생 시에만 다운로드 전체 노드의 관점에서 볼 때 계약 상태를 확인할 수 있는 능력을 잃지는 않지만 사용자의 관점에서는 상황이 완전히 다릅니다. 상태를 재구성할 수 있는지 확실하지 않습니다. 언제든지 인출을 완료합니다. 즉, 사용자는 낙관적 롤업을 사용하는지 플라즈마를 사용하는지 확신할 수 없습니다. 원래 낙관적 롤업 솔루션은 모든 전체 노드가 과거 트랜잭션의 백업을 가지고 있도록 하여 사용자가 자신의 상태를 쉽게 재구성하고 완전한 인출을 위해 상태 증명(또는 어설션)을 제출할 수 있도록 하는 것입니다. 내가 주를 재건할 수 있는지 확신합니다. 낙관적 롤업의 보안도 영향을 받습니다: 보안 가정은 트랜잭션 데이터를 얻은 사람 중 적어도 한 명이 계약을 준수한다는 것입니다. 데이터 샤딩 모드에서는 얼마나 많은 사람들이 갈지 알 수 없습니다. 거래 데이터.
대체로 "데이터 샤딩" 모드를 zk 롤업과 결합하면 대역폭 측면에서 더 큰 확장성을 제공할 수 없지만 블록 공간을 확장하는 것과 동일한 효과가 있습니다. 확장성 이점은 문제의 빈도에 반비례합니다. 더 심각하게는 낙관적 롤업을 플라즈마로 퇴보시킬 위험이 있습니다(정의상 낙관적 롤업은 더 이상 존재하지 않으며 낙관적 롤업과 플라즈마 사이의 다른 이름으로 언급되어야 합니다).
보조 제목
결론적으로
롤업 솔루션은 사실상 Layer-2 개발 과정에서 피비린내 나는 교훈을 배우고 날아온 불사조다. 가장 큰 특징은 사용자 자금의 안전을 위해 충분한 보호를 제공한다는 것입니다. 거래 데이터를 얻은 사람은 누구나 상태를 재구축할 수 있고 블록체인은 이러한 거래 데이터의 지속적인 데이터 가용성을 보장하기 때문에 롤업 체계는 계층 2 체계 중에서 누구에게도 뒤지지 않는 사용자 보호를 제공할 수 있습니다. 이러한 솔루션이 있어야만 사용자가 실제로 사용할 수 있습니다. 이 이점을 포기하고 최대 성능에 대한 낙관적 가정을 기반으로 시스템을 설계하면 사용자가 사용하기를 두려워하는 것만 설계할 수 있습니다.


