의견: 데이터 가용성 엔진으로서의 Eth2

편집자 주: 이 기사의 출처는이더리움 애호가(ID: ethfans)편집자 주: 이 기사의 출처는

이더리움 애호가(ID: ethfans)

이더리움 애호가(ID: ethfans)

, 저자: Casey Detrio, 번역자 및 교정자: Min Min & A Jian, 승인을 받아 Odaily에서 복제.

편집자 주: 이 기사의 원래 제목은 "Phase One and Done: eth2 as a data availability engine"입니다. 발행 당시(2019년 4월) 저자는 Phase 2를 대체할 Eth2.0 로드맵을 제안하려고 했습니다. 즉, 데이터 가용성을 보장하기 위해 샤딩만 사용하는 경우 그러한 시스템이 유용한지, 유용하게 만들기 위해 어떤 부분을 추가해야 하는지입니다. 놀랍게도 1년 반 전에 저자는 zk-rollup과 같은 시스템의 경우 하단 레이어가 "상태 전환 실행과 데이터 가용성이 원자적으로 결합되어야 함"을 보장해야 하므로 기본 레이어에 매우 단순한 상태 비저장 실행일지라도 실행할 수 있는 능력, 게다가 (저자는 또한 추론의 레이어를 통해 지적했습니다) 사용자 경험을 보장하기 위해 여전히 누락된 주요 부분은 데이터를 샤딩하는 절차입니다 수수료 지불 계약 (이 두 가지 이해 지점은 오늘날에도 여전히 최첨단, 심지어 고급이라고 할 수 있음). 수수료 프로토콜은 2단계 사양에 아직 없습니다.

그런데 이 글의 저자는 Ewasm 팀의 일원으로 이전에 Phase 2에 대한 많은 아이디어를 제공한 Casey Detrio입니다. Eth2가 도착하면 정상적으로 실행됨" .0. 저평가된 개발자입니다.

현재 Eth1 처리량을 제한하는 병목 현상은 상태 성장입니다. 따라서 이더리움을 확장하려는 경우 논리적으로 독립적인 상태를 가진 1000개의 샤드가 처리량을 1000배 증가시킬 수 있습니다.

그러나 Eth1.x 경로에서 Eth1.x는 저장소(storage)와 트랜잭션 데이터(tx data)라는 두 가지 리소스 유형의 비용을 크게 조정하려고 합니다. 현재 스토리지는 가격이 저렴하고 트랜잭션 데이터는 가격이 비쌉니다. 이는 dApp 개발자가 계약을 작성할 때 트랜잭션 데이터보다 더 많은 스토리지를 사용하도록 장려하여 스토리지가 처리량 병목 현상이 되도록 합니다. 이 문제에 대해 제안된 솔루션은 스토리지 가격을 높이고 트랜잭션 데이터의 가격을 낮추는 것입니다. 이러한 비용 조정을 통해 개발자는 스토리지보다 트랜잭션 데이터를 더 많이 사용하도록 장려됩니다(즉, 상태 저장 계약 대신 상태 비저장 계약을 더 많이 작성하게 됨). 따라서 가까운 장래에(Eth1.x 로드맵이 널리 채택되면) Eth1 처리량이 스토리지가 아닌 트랜잭션 데이터에 의해 제한될 것으로 예상합니다.

처리량이 트랜잭션 데이터에 의해 제한된다고 가정하면 Serenity의 샤드가 Ethereum을 확장하기 위해 상태 저장이 필요하지 않습니다. 상태 비저장 계약의 트랜잭션 데이터에 의해 처리량이 제한되는 경우 1,000개의 상태 비저장 샤드는 처리량을 1,000배 증가시킵니다.

이것은 좋게 들리지만 2단계까지 기다릴 계획인 샤딩을 통해 구현해야 합니다. 동시에 1단계를 데이터 가용성 엔진으로 사용할 수 있습니다. 데이터 가용성 엔진이라는 용어가 인기를 얻고 있는 것 같습니다. 그것이 어떻게 작동하는지 생각해 봅시다.

zk-rollup을 예로 들면 zk-rollup은 데이터 가용성에 따라 제한됩니다. Eth1의 zk-rollup 계약이 Eth2를 브리징 가용성 보장 공급자로 효과적으로 사용할 수 있습니까? 실행 중에 데이터 가용성을 보장할 수 없는 경우(예: SNARK 증명 확인 및 상태 루트 업데이트) 플라즈마와 같은 zk-롤백 시스템으로 끝납니다. 이 시스템은 TPS를 크게 향상시킬 수 있지만 복잡한 트레이드 오프를 도입하고 운영자의 문제와 플라즈마와 같은 종료 메커니즘을 처리해야 합니다. 가용성 챌린지에서는 누구나 가용성을 증명하기 위해 데이터를 제공할 수 있으므로 브리지된 Eth2 샤드에 데이터를 넣는 것이 작업을 더 쉽게 만들 것인지는 확실하지 않습니다.

이제 다른 버전의 zk-rollup인 500 TPS zk-rollup을 사용하면 모든 것이 훨씬 쉬워집니다. 더 이상 지정 운영자가 필요하지 않으며 누구나 언제든지 릴레이 역할을 할 수 있으며 SNARK 증명을 생성하여 상태를 업데이트할 수 있습니다. 실제로 데이터 가용성 보장에는 항상 상태 업데이트가 수반되므로 플라즈마와 같은 운영자 문제 및 종료 메커니즘을 처리할 필요가 없습니다. 그러나 이를 위해서는 실행과 데이터 가용성이 모두 동일한 트랜잭션에서 발생해야 합니다. 불행하게도 브리지 가용성 엔진으로는 수행할 수 없습니다. 즉, 브리징은 zk-rollback과 같은 사기 방지 시스템에는 충분하지만 zk-rollup과 같은 유효성 증명 시스템에는 충분하지 않습니다. 결론은 레이어 2의 유효성 증명을 단순화하기 위해 레이어 1의 가용성 엔진이 가져야 하는 중요한 기능은 데이터의 가용성과 상태 전환 실행이 원자적으로 함께 발생하는지 확인하는 것입니다.

아마도 우리는 이러한 깨달음에 놀라지 말아야 할 것입니다. (실행 없이) 데이터 가용성만 유용하다면 아무도 0이 아닌 블롭(이진 대형 객체)의 가용성을 보장하기 위해 1단계가 시작되었다고 주장하지 않을 것이며 아무도 Eth2가 들어와 다음 단계가 실제로 시작됩니다(PoS 제외). 우리는 데이터 가용성 엔진으로 1단계에서 작업하고 있지만 여전히 아무 작업도 수행하지 않아 실망스럽습니다. (와우, 우리는 Mastercoin 2.0을 만들 수 있습니다!)

그렇다면 1단계가 실행과 충돌하는 이유는 무엇입니까? 상태 저장 실행을 가정하면 각 샤드는 일부 로컬 상태를 유지합니다. 유효성 검사기가 많은 로컬 상태를 유지해야 하는 경우 유효성 검사기 셔플은 훨씬 더 복잡합니다. 반대로 구현이 없으면 로컬 상태에 대해 걱정하지 마십시오. 유효성 검사기 셔플은 훨씬 간단할 것입니다. 데이터 블롭으로 샤드를 구축하는 데 집중하고 샤드를 더 빠르게 시작할 수 있습니다.

그러나 실행이 상태 저장이라고 가정하지 마십시오. 매우 간단한 상태 비저장 가상 머신으로 시도하면 어떻게 될까요?

비콘 체인 상태에 code, stateRoot 및 deploymentShardId와 같은 3개의 새 유효성 검사기 필드가 있다고 가정합니다. process_deploy 함수도 있습니다(process_transfer 바로 아래). 코드가 배포되면 검증자는 계정 잔액이 특정 임계값 이하로 떨어지지 않도록 해야 합니다[최소 1 ETH가 잠겨 있습니다. 코드에 자체 파괴 프로그램(SELFDESTRUCT)이 없으면 ETH의 이 부분은 파괴되는 것과 동일하며 코드는 영구적으로 배포됩니다].

이제 전역 상태의 코드가 있는 일부 계정이 이미 있다고 가정해 보겠습니다.

다음으로 특정 데이터 blob을 샤드에 압축하려고 합니다. 하지만 어떻게 해야 할까요? 내가 아는 한, 1단계 샤드 유효성 검사기가 샤드 블록에 어떤 데이터 블롭을 압축할지 결정하는 것은 여전히 ​​열려 있는 질문입니다. 이것이 1단계 사양에 자세히 설명되어 있지 않다고 가정합니다. 그런 다음 사용자가 자신의 데이터 blob을 샤드로 압축하려는 경우 두 가지 방법이 있습니다. 샤드의 블록 제안자로 무작위로 선택됨) 데이터 블롭을 샤드에 압축합니다. 이 두 가지 방법 모두 나쁜 생각입니다.

더 나은 접근 방식은 테이블에 물건을 가져오고 유효성 검사기가 거래 계약을 통해 현재 블록 제안자에게 지불하도록 허용하는 것입니다. 그 대가로 블록 제안자는 유효성 검사기의 데이터 blob을 샤드 체인에 패키징합니다. 그러나 이 접근 방식은 비콘 체인 블록 작업(예: 유효성 검사기 전송)에 최소 용량 요구 사항이 있는 경우 작동하지 않습니다. "데이터 가용성 엔진으로서의 1단계" 사용 사례는 검증자가 데이터 blob 패킹의 우선 순위를 지정할 수 있는 트랜잭션 프로토콜 없이는 불가능합니다(비콘 체인에 대한 브리지를 통해 연결된 eth1 계약이든 Truebit, Mastercoin 2.0, 또는 이전에 들어 본 다른 데이터 가용성 사용 사례). 어쨌든, 샤드 제안자가 "실행 없는 데이터 가용성 엔진" 모드에서 데이터 블롭을 패킹하는 방법에 관계없이 "단순 상태 비저장 실행이 있는 데이터 가용성 엔진" 모드에도 있을 수 있다고 가정해 봅시다.

좋습니다. 특정 데이터 blob을 블록으로 묶을 수 있다고 가정해 보겠습니다. 각 블록은 실행을 하나의 트랜잭션으로 제한합니다(예: 전체 데이터 BLOB가 하나의 트랜잭션으로 포함되어야 함). 트랜잭션이 키로 서명되는지(트랜잭션 계약이 있음) 또는 서명이 필요하지 않은지(트랜잭션 계약이 없음) 아직 명확하지 않습니다. 후자를 가정하고 코드는 자체 서명 확인을 구현합니다(계정 추상화와 유사합니다. 블록 가스 제한이 있지만 수수료 전송 메커니즘이 없으므로 가스 가격과 GASPAY opcode가 없습니다). Blob이 트랜잭션으로 성공적으로 디코딩될 수 있으면 데이터 및 현재 상태 루트를 입력으로 사용하여 대상 계정 코드가 실행됩니다. 실행이 성공하면 반환 데이터는 새로운 상태 루트입니다.

유효성 검사기 계정의 stateRoot를 어떻게 업데이트합니까? 각 샤드 블록의 BeaconState(비콘 체인 상태)에서 상태 루트를 업데이트할 수 없습니다(비콘 체인 작업의 수가 엄격히 제한되기 때문). 그러나 비콘 체인 상태의 단편화 필드는 교차 링크로 업데이트됩니다. shard_state_root(샤드 상태 루트)를 얻기 위해 해시되었다고 가정하고 동일한 샤드에 있는 모든 계정의 업데이트된 상태 루트를 가져옵니다. shard_state_root는 이미 1단계 설계에 있는 crosslink_data_root와 유사해 보입니다(둘 다 이전 샤드 블록 콘텐츠의 해시에 따라 다름).

물론 비콘 체인 블록이 채굴될 때마다 모든 샤드 상태 루트가 업데이트되는 것은 아니므로 일부 로컬 상태가 있습니다. 그러나 계정이 전역인 경우 상태 루트 데이터가 최소화됩니다. 이는 셔플 중에 유효성 검사기 간에 일부 샤드 블록 데이터를 전송해야 하는 것과 유사합니다.

물론 여기서는 많은 세부 사항이 생략됩니다. 내가 전달하려는 것은 상태 비저장 실행에 대한 대부분의 요구 사항이 1단계에서 충족되는 것 같다는 것입니다. 내 생각에 가장 큰 문제는 사용자가 체인에서 블롭을 패키징하는 방법이 아직 명확하지 않다는 것입니다(이 문제가 해결되지 않으면 1단계는 브리지 사용성 엔진이 될 수 없습니다). 아마도 이것은 첫 번째 문제일 뿐이며 내가 간과한 다른 심각한 문제가 있습니다. 내가 무엇을 놓치고 있습니까? 사용자가 1단계(또는 원하는 경우 1.1단계)에서 어떻게든 온체인에 Blob을 패키징하도록 허용하는 데 있어 가장 어려운 부분은 무엇입니까?