이더리움 2단계 진행(2019-12)

以太坊爱好者

特邀专栏作者

2019-12-17 09:00 (UTC+8)

이 기사는 약 8647자로, 전체를 읽는 데 약 13분이 소요됩니다

Ethereum 2.0 작업 2단계는 계속 진행됩니다. 이 문서에서는 현재 최신 개발에 대해 설명합니다.

AI 요약

Ethereum 2.0 작업 2단계는 계속 진행됩니다. 이 문서에서는 현재 최신 개발에 대해 설명합니다.

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

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

, 저자: Will Villanueva, 번역 및 교정: A Jian & Zeng Mi, 승인을 받아 Odaily에서 복제.

Ethereum 2.0 작업 2단계는 계속 진행됩니다. 이 문서에서는 현재 최신 개발에 대해 설명합니다. 2단계 작업의 대부분은 Ewasm 팀과 Ethereum Foundation의 Quilt 팀 간의 공동 작업으로 수행되었습니다.

이 기사의 다른 부분에 있는 내용은 다른 분야를 가리키는 경우가 많고 교차점이 거의 없으므로 읽고 싶은 부분을 선택하십시오. 이 글을 읽기 전에 다음 자료를 통해 Phase2의 배경지식과 실행환경제안(EE)에 대해 먼저 이해하시기 바랍니다.

Eth 2 Phase 2 및 Phase 2 테스트넷으로 가는 길(이것은 Devcon 5의 강연이며 강연에 사용된 슬라이드입니다)

이더리움 2.0 2단계에 대한 EthHub의 심층 해석

Eth2 Phase2 주변 여행(일부 지식 포인트는 구식임)

Ewasm 2.0: Eth2.0의 주 집행(고급 읽기)

첫 번째 레벨 제목

2단계에 영향을 미치는 프로토콜 레이어 변경 사항

Vitalik의 제안 2는 제안 1과 Eth2의 새로운 개념을 상태 비저장 프로토콜로 개선합니다(이 블로그 게시물에는 상태 비저장이 무엇인지 간략하게 설명하는 "샤드 체인에는 상태가 필요하지 않음"이라는 제목의 섹션이 있습니다).

현재 2단계 설계는 발의안 2 아이디어에서 크게 벗어나지 않습니다. 역사적으로 비콘 체인 로드 밸런싱 개념이 도입되었을 때 제안의 일부가 변경되었습니다. 이 로드 밸런싱 아이디어는 샤드 체인을 순수한 컴퓨팅 프로세스로 이해하고 EE가 사전 지정된 샤드 체인에서 동적으로 실행될 수 있도록 제안합니다. 본질적으로 이 아이디어는 비콘 체인에 정의된 로드 밸런싱 계약을 통해 컴퓨팅 로드를 다른 샤드 체인에 균형을 맞추는 것입니다. 이 설계 개념은 매우 흥미롭고 여러 다른 모드의 크로스 샤드 동기 트랜잭션이 협력 릴레이어를 통해 실현될 수 있다는 점을 강조할 가치가 있습니다. 우리의 연구에 더 많은 노력을 기울일 가치가 있습니다.신뢰할 수 있다면 이 도구를 향후 샤드 체인에 추가할 수 있습니다(아마도 온라인으로 전환된 후).

첫 번째 레벨 제목

Scout

프로토타입 구축과 실행 환경의 초기 구현에서 상당한 진전을 이루었습니다. 먼저 실행 환경이 상태 비저장 모드에서 작동할 수 있는지 확인해야 합니다. 이 실행 환경에 필요한 증거/증인 데이터의 양이 너무 많습니까? 상태 전환을 수행하기 위해 증명을 사용하는 데 너무 오래 걸립니까? 이러한 질문에 답하기 위해 우리는 많은 실행 환경을 만들어 이러한 질문을 연구하는 데 사용했지만 먼저 프로토타입을 빌드하기 위한 엔진인 Scout가 필요합니다.

보조 제목

Scout는 Ethereum 2.0 Phase 2 실행 프로세스 프로토타이핑 엔진(원래 Alex Beregszaszi가 개발)으로 Ewasm API용 래퍼를 개발하여 개발자가 이를 사용하여 실행 환경의 프로토타입을 구축하고 벤치마크 테스트(벤치마킹)를 수행할 수 있습니다. 또한 어셈블리 스크립트와 C++ 포트도 있습니다.

보조 제목

Eth1 관련 EE

Eth1에서 Eth2로의 전환을 지원하려면 Eth1의 상태 전환 규칙을 Eth2의 실행 환경으로 만들어야 합니다. 이 스위치의 주요 과제는 Eth1을 상태 비저장 모델로 변환한 다음 EVM 및 트랜잭션/계정 모델을 실행 환경으로 변환하는 것입니다. 아래에 언급된 EE는 Eth1 EE의 전신입니다. Eth1 EE를 중심으로 한 개발에 중점을 둔 작업 그룹이 최근 구성되었습니다. 그들은 초기 작업 계획을 세우고 eth 연구 포럼에 친절하게 자신을 소개했습니다.

무국적 메르켈 패트리샤 트리(SMPT) 토큰

주요 출처: Github, Sina Mahmoodi의 Devcon 5 프레젠테이션

상태 비저장 토큰 EE의 첫 번째 프로토타입은 Eth 1.0의 아키텍처를 모방하는 것을 목표로 합니다. 패리티의 코드 기반을 사용하여 Eth1 상태 트리(Hexary Merkle-Patricia Trie) 및 RLP 인코딩 규칙을 구현합니다. 또한 릴레이어가 일련의 트랜잭션에 대한 여러 증명을 생성할 수 있는 기본 릴레이어 구현을 통합합니다.

벤치마크: 70개의 트랜잭션 및 5000개의 계정/리프 노드

Turbo Token

소요 시간: 5초

증거 크기: 235kb

실행 실행 및 증거 크기에서 상당한 개선이 여전히 필요하지만 이러한 초기 결과에서도 진전이 분명합니다. 문제 중 하나는 Parity의 녹 라이브러리를 wasm 코드로 컴파일하는 것과 관련되어 많은 memcopy(메모리 복사) 작업 및 기타 비효율성을 초래했습니다. 일반적으로 녹을 웹 어셈블리로 컴파일하는 것은 매우 어려운 것으로 입증되었습니다. 또한 서명 확인 항목은 총 5초 중 4초가 소요되었습니다.

주요 정보: Turboproof 개요(편집자 주: 중국어 번역은 기사 끝에 있는 하이퍼링크 참조), Turboproof Rust Github, Turbo Token Github, Guillaume Ballet의 Devcon 5 연설, Sina Mahmoodi의 Devcon 5 연설

Turbo Token 모델에 사용된 터보프루프 기술은 초기에 Alexey Akhunov가 Eth1 상태 비저장 라이트 클라이언트를 구현하기 위해 연구한 것입니다. 데이터 트리를 업데이트합니다. Casey Detrio와 Sina는 어셈블리 스크립트와 Rust로 초기 단일 분기 프로토타입을 개발하여 터보 방지가 충분히 효율적인지 확인했습니다. 단일 분기 프로토타입에서 초기에 만족스러운 결과를 얻은 후 Casey는 어셈블리 스크립트를 사용하여 간단하고 가장 기본적으로 사용 가능한 터보 증명 토큰 EE를 구현했습니다. Sina Mahmoodi는 이 구현을 복사한 다음 Guillaume의 터보 프루프 풀 러스트 코드베이스 및 생성기를 TypeScript로 포팅했습니다.

벤치마크: 70개의 트랜잭션 및 5000개의 계정/리프 노드

경과 시간: 140ms

증거 크기: 50kb

EVM 인터프리터 EE

요약하다

Eth1 EE를 지원하기 위해 실행 엔진에서 (웹 어셈블리 사용 가능) EVM 인터프리터를 개발해야 합니다. Hugo는 프로토타입을 만들고 add 및 mul256 컨트랙트에 대해 테스트했습니다. 앞으로 이 프로토타입을 개선하기 위해 더 많은 계약과 벤치마크를 도입해야 합니다.

요약하다

위에서 언급한 모든 실험 작업은 Eth1 실행 환경을 구현하는 것입니다. 프로토타입 제작을 시작했지만 아직 고려해야 할 성능 문제가 많습니다. 위에서 언급한 바와 같이, 워킹 그룹은 최근 Eth1 EE를 개발하고 Eth1 상태 비저장 모델을 만드는 데 집중하기 시작했습니다.

C Merkle Token

보조 제목

Eth2를 중심으로 한 EE

이 섹션에서는 Eth1 -> Eth2 마이그레이션을 위해 완전히 개발되지 않은 EE를 소개합니다. Eth2는 Eth1이 사용하는 트랜잭션, 계정 및 누산기 모델이 최적이 아니기 때문에 Eth1의 계정 및 트랜잭션 모델과 다른 새로운 계정 기반 실행 환경을 사용합니다. 또한 낙관적 롤업, ZK 롤업과 같은 모델도 연구해야 합니다. Eth2 EE의 설계 공간은 활짝 열려 있으며 다음은 초기 아이디어 및 프로토타입입니다.

주요 정보: Github, Devcon 5 Presentation

Paul Dworzanski의 이진 머클 트리(희소 머클 트리 대신)를 사용하여 상태 비저장 머클 토큰의 C 구현. 데이터 트리의 검증 및 업데이트는 최적의 메모리 분배를 사용하고 고유한 다중 증명 형식을 배열합니다. 이 모델의 검증 및 업데이트 데이터 트리 작업은 단일 패스(single pass)로 완료되며(따라서 메모리 복사 작업(memcopy 및 duplication) 방지) Eth1의 16진수 데이터 트리에서 사용할 가능성이 매우 높습니다. 그러나 Eth1 데이터 트리에서 데이터 트리 업데이트 알고리즘을 사용할 수 있는지 여부는 명확하지 않습니다(Eth1 기반 모델은 일반적으로 여러 패스를 사용하기 때문).

벤치마크: 증명에 관련된 222개 계정 중 40개

ZK Rollup

경과 시간: 20ms(서명 확인 제외)

증거 크기: 25kb

Shard Ether (Sheth)

현재 테스트에 사용된 구현은 이미 가장 효율적입니다. 서명 확인은 벤치마크에 포함되지 않지만 추가로 30밀리초만 소요될 것으로 예상됩니다. 또한 컴퓨팅 시간과 크기를 줄이기 위한 캐싱 해시 및 증명과 같은 많은 추가 최적화 솔루션이 있습니다. 적응형 해시 길이 방식(네트워크가 커짐에 따라 해시 길이가 증가함)도 증명 크기를 더 줄일 수 있습니다. 마지막으로 더 나은 해시 함수 구현으로 계산 시간이 단축됩니다.

주요 정보: 일반 ZK 롤업 개요(편집자 주: 중국어 번역의 경우 기사 끝에 있는 "ZK 롤업 대 낙관적 롤업" 하이퍼링크 참조), Devcon 5 연설, EE stark 검증기 예, WASM 증명 검증기, 웹 스나크

ZK 롤업은 레이어 2 확장 솔루션으로, 복잡한 종료 챌린지 메커니즘과 잠금 메커니즘을 사용하지 않기 때문에 기존 레이어 2 솔루션의 일반적인 사용자 경험 문제를 피할 수 있습니다. 여기에 나열된 다른 토큰 전송 체계와 비교하여 ZK Rollup은 데이터 가용성에 대한 요구 사항을 크게 낮춥니다. 여기에 나열된 구현은 snark 확인 또는 기타 페어링 기능에 사용할 수 있는 wasm에 구현된 생성기인 web snark를 사용합니다. EE를 개발하기 위해 Jared는 websnark를 채택하여 Groth16 증명을 검증하기 위한 별도의 wasm 라이브러리를 개발했습니다. 이 EE는 아직 초기 프로토타입이며 계속 개발되어야 합니다.

주요 소스: Github, Matt Garnett의 Devcon 5 토크, Internal Quilt 토크(자세한 내용), SSZ 개요

Sheth는 Eth2 계약 EE의 선구자입니다(Eth1을 기반으로 하지만 wasm/Eth2에 더 적합하도록 반복됨). Sheth는 Eth2에서 사용되는 SSZ(Simple Serialization Encoding Specification)를 기반으로 하며 희박한 Merkle 트리 체계를 사용하고 터보 방지 opcode를 차용하지만 다른 형식을 사용하여 읽기, 쓰기 및 업데이트 요구 사항을 관리합니다. Diederik Loerakker의 설계 아이디어는 오프셋 목록을 저장하여 전체 데이터 트리를 순회하는 방법을 결정하는 것입니다. 희소 머클 트리 증명의 강점은 참조하는 데이터의 전체 인덱스를 컴파일 타임에 정적으로 정의할 수 있다는 것입니다. 또한 노드가 데이터 트리에 삭제되거나 삽입되지 않기 때문에 상태를 업데이트하는 데 필요한 논리를 크게 단순화합니다. Sheth에는 중계자 또는 상태 공급자 역할을 할 수 있는 명령줄 클라이언트도 포함되어 있습니다.

벤치마크: 50개 계정 및 50개 트랜잭션

증거 크기: 517kb

SimpleUmbrella — Eth2 스마트 계약 EE

주요 자료: Eth Research 포럼에서 제안, 코드 호스트 기능 PR 실행

첫 번째 레벨 제목

Ewasm - 해석기, 컴파일러 및 전산 메트릭스

보조 제목

번역가

보조 제목

통역사

보조 제목

전산 지표

Paul Dworzanski는 그의 Devcon 5 강연에서 이 영역을 깊이 탐구했습니다. 계산을 측정하기 위해 use_gas 호출은 wasm 계약이 배포되고 확인될 때 wasm 바이트코드(EE에서 실행 중이든 상위 EE에서 실행 중이든)를 주입합니다. 주입 및 검증의 복잡성은 의심할 여지 없이 계약 배포 비용에 영향을 미칩니다. 현재 벤치마크는 컴퓨팅 메트릭을 주입한 후 wasm 코드가 1.04-2.4배 더 느리게 실행되는 것을 보여줍니다. 주입 프로세스 및 레지스트리 어셈블리의 더 나은 패턴을 벤치마킹하면 추가 최적화를 가리킬 것입니다.

Lighthouse 클라이언트 또는 2단계 시뮬레이션의 1단계 및 2단계 프로토타입

우리는 1단계와 2단계 클라이언트가 어떻게 구축되고 구현을 개발하는 팀이 어떻게 지원되는지 시뮬레이션하고 싶었습니다. 또한 이 작업을 사용하여 실제 환경에서 여러 샤드에서 실행되는 EE를 시뮬레이션하고 테스트할 수 있기를 바랍니다. Devcon 5에서 저는 우리가 구축한 시뮬레이션에 대해 이야기했습니다. 우리는 Lighthouse 클라이언트에서 매우 간단한 1단계 프로토타입(네트워킹 구성 요소가 추가되지 않음)을 개발/도입했으며 클라이언트에 2단계 Ewasm 런타임을 포함했습니다. 우리는 Sheth(Sheth는 중계자 및 상태 제공자 역할을 함)와 상호 작용하고 Lighthouse에서 기본 EE 또는 토큰 전송을 시뮬레이션할 수 있습니다.

Lighthouse 클라이언트는 여전히 활발히 개발되고 있기 때문에 Lighthouse 클라이언트의 포크를 유지하고 그 위에서 개발하는 것이 처음에 생각했던 것보다 더 어려울 것이라는 것을 깨달았습니다. 그래서 우리는 초기 프로토타입에서 영양분을 가져와 Scout 내에서 추상 스텁 버전을 개발하기로 결정했습니다. 우리는 계속해서 비콘 체인과 샤드 체인의 작동을 시뮬레이션할 것이지만, 우리의 초점은 실행 환경 및 교차 샤드 벤치마킹에 대한 연구에 있기 때문에 논리를 크게 단순화할 수 있습니다. 작업의 이 부분은 Quilt 팀의 두 명의 새로운 구성원이 관리하고 있습니다.

첫 번째 레벨 제목

John Adler는 이 주제에 대해 매우 포괄적인 개요를 작성했습니다. 그의 기사는 또한 Eth2 제안의 흥미로운 진화를 알려줍니다. 요약하자면, Vitalik의 최신 샤딩 단순화 제안은 우선 릴레이어 모델과 관련된 많은 문제를 제거합니다. 그러나 상태 공급자가 트랜잭션을 블록 생산자에게 보내는 방법과 블록 생산자가 트랜잭션 번들을 적절한 다중 증명에 통합하는 방법에 대해서는 아직 미해결된 질문이 많이 있습니다. 제안 중 하나는 증명 병합 스크립트를 사용하여 새로운 실행 환경을 배포하는 것입니다.

결국 릴레이어 또는 상태 제공자는 web3.js 또는 ethers.js가 연결된 RPC 끝점을 상속합니다. 여러 EE에서 이러한 작업에 대한 일련의 표준을 제시하는 것이 중요합니다.

첫 번째 레벨 제목

크로스 샤드 트랜잭션

보조 제목

비동기 크로스 샤드 트랜잭션
Vitalik의 최신 0단계 및 1단계 제안은 교차 샤드 트랜잭션과 결합성 모두에 희소식입니다. 새로운 제안에서는 교차 샤드 호출이 단 하나의 시간 슬롯(6초) 지연으로 완료될 수 있는 반면, 과거 제안에서는 호출이 완료되기까지 12~18분의 지연을 기다려야 했습니다. 따라서 샤드 간에 상태(또는 eth)를 전송하는 것이 매우 빨라집니다. 이전에는 낙관적 루트를 사용하여 호출 속도를 높이고 싶었지만 이러한 솔루션은 매우 복잡했습니다.
dApp 개발자의 관점에서 교차 샤드 호출은 멀티 스레드 프로그래밍의 비동기 패러다임 및 방법만 따르면 됩니다. 스마트 계약을 작성할 때 HLL(Slodity) 및 DSL(Vyper)은 교차 샤드 동작을 비동기 패러다임으로 추상화하는 데 필요한 도구를 제공해야 합니다. 전체 스키마는 다음과 같을 것입니다.
단순 비동기 호출(비동기 대기, 콜백 등)

2단계 확인(원자성)

잠금 - 읽기/쓰기(계약 양킹)

EE 또는 기본 계약에서 이러한 패턴을 지원하는 방법은 추가 연구가 필요합니다. 위에서 언급한 시뮬레이션(및 아래에 언급된 오케스트레이션 도구)은 이러한 모델을 사용한 실험의 기초를 제공해야 하지만 실제로는 이것이 중요한 연구 영역이며 사람들이 기꺼이 참여한다면 우리는 매우 행복하세요. 이 게시물에 설명된 대로 하위 수준에서 사전 프로세스 및 사후 프로세스 동작을 지정하면 계약 내에서 실행을 일시 중지하고 이후에 계속 실행하기 위한 합리적인 프레임워크를 제공할 수 있습니다.

크로스 샤드 트랜잭션 동기화

이전에 Vitalik은 국가 체계에 대해 논의하는 게시물을 게시했습니다. 이러한 솔루션의 핵심은 체인의 Layer-2 모드이며 단편화는 데이터 가용성 계층으로만 사용됩니다. 이러한 모델(즉, 이전에 전설적인 "지연된 상태 실행" 모델, "지연 실행" 모델 또는 "섀도 체인")은 실제로 소위 낙관적 롤업의 전신입니다. 낙관적 롤업 체계를 위한 데이터 가용성 계층으로 여러 샤드를 사용하면 샤드 간에 트랜잭션을 동기화할 수 있습니다. 그리 멀지 않은 미래에 이 개념을 기반으로 프로토타입을 개발할 수 있습니다.

보조 제목

샤드를 가로질러 호출해야 합니까?

추가 연구할 가치가 있는 또 다른 관점은 Eth2의 본체가 상태 채널, 낙관적 롤업 및 zk 롤업(이러한 체계가 성숙한 후)에 기울어야 한다는 것입니다. 이러한 사고 방식에서 Eth2 자체는 데이터 가용성 계층이며 교차 샤드 호출은 이러한 체계를 연결할 때 또는 종료 챌린지/거짓 증명 중에만 사용됩니다. 롤업은 여전히 Eth1 또는 Eth2 실행 환경의 경계 내에서 정의되어야 하지만 오류 증명을 제출해야 하는 경우 계산은 온체인에서만 수행하면 됩니다.

첫 번째 레벨 제목
2단계 툴체인
연구를 발전시키기 위해 개발자가 사용해야 하는 도구 체인을 제안합니다. 위의 "Lighthouse의 1단계 및 2단계 프로토타입" 섹션에서 언급한 것처럼 우리는 여러 샤드에서 실행 환경을 테스트하고 실행하기 위한 일련의 시뮬레이션을 적극적으로 개발하고 있습니다. 그러나 스마트 계약 운영 모드를 최적화하기 위해서는 많은 오케스트레이션 도구를 추가해야 합니다. 이 게시물에서는 이러한 도구에 대해 자세히 설명합니다.
1단계 및 2단계 시뮬레이션
1단계 클라이언트의 런타임 환경 삽입