Ethereum 2.0이 1.0과 어떻게 병합되는지 자세히 설명하십시오.

편집자 주: 이 기사의 출처는배빗 정보 (ID: bitcoin8btc)편집자 주: 이 기사의 출처는

배빗 정보 (ID: bitcoin8btc)

참고: 원저자는 이더리움 2.0의 코디네이터인 Danny Ryan(djrtwo)입니다. 클라이언트는 PoS 및 샤드 합의의 복잡성을 처리할 수 있으며 연결된 eth1 클라이언트는 상태, 트랜잭션, 가상 머신 등의 복잡성을 처리할 수 있는 eth1 엔진이 될 수 있습니다.

이미지 설명

(사진출처: tuchong.com)<-> eth2 보조 제목Ethereum 1.0과 Ethereum 2.0 클라이언트 간의 관계

Vitalik이 2019년 12월 초기 eth1을 제안한 이후

그 이후로 소프트웨어 관점에서 이 합병의 가능한 형태를 고려하기 위해 연구원들 사이에서 활발한 논의가 있었고 프로토타이핑에 대한 기대는 더욱 커졌습니다. 우리의 비전은 이더리움 2.0 클라이언트(이하 eth2 클라이언트)가 핵심 합의 작업을 관리하고 이더리움 1.0 엔진(이하 eth1 엔진)이 상태/블록을 관리하는 하이브리드를 만드는 것입니다. 그들은 함께 eth1+eth2 결합 클라이언트를 형성합니다.

이 기사는 대화, 사양 작성 및 프로토타이핑을 위한 더 나은 기반을 제공하기 위해 eth2 클라이언트와 연결된 eth1 엔진 간의 책임을 보다 명확하게 분리하는 것을 목표로 합니다. 이 문서는 프로토콜의 세부 사항(예: eth1 클라이언트가 eth2 엔진을 호출하는 정확한 방법)을 정의하지 않으며 이 문서에 포함된 모든 예제는 설명 및 후속 논의를 돕기 위한 것일 뿐입니다.

이 글의 내용을 이해하기 위해서는 이더리움 2.0과 stateless 이더리움의 개념에 기본적으로 익숙해야 합니다.

보조 제목

명확한 노동 분업

간단히 말해서 오늘날 우리가 생각하는 eth2 클라이언트는 코어 PoS와 샤드 합의를 처리합니다. 본질적으로 eth2 프로토콜과 eth2 클라이언트는 데이터와 (최종) 상태로 가득 찬 많은 샤드 체인인 "물건" 묶음에 대한 합의를 생성하고 도달하는 데 매우 능숙하도록 설계되었습니다. eth1의 현재 PoW 컨센서스 레이어와 비교할 때 eth2의 "컨센서스 레이어"는 훨씬 더 발전되고 복잡합니다.

오늘날 eth1 클라이언트는 상대적으로 단순하고 얇은 합의 레이어를 가지고 있으며 하나의 체인만 가지고 있으며 PoW는 오프 프로토콜 하드웨어의 복잡성 대부분을 처리합니다. eth1 클라이언트의 복잡성과 최적화의 대부분은 사용자 계층(상태 저장/관리, 상태 동기화, 가상 머신 실행, 트랜잭션 처리, 트랜잭션 풀링 등 포함)에 있습니다.

이러한 관심사의 분리는 eth1이 샤드로 eth2에 통합될 때 좋은 페어링을 만듭니다. eth2 클라이언트는 PoS 및 샤드 합의의 복잡성을 처리할 수 있으며 보조 eth1 클라이언트는 eth1 엔진이 될 수 있습니다. , 트랜잭션, 가상 머신 및 사용자 영역에 더 가까운 것들.

보조 제목

로컬 커뮤니케이션을 위한 최소한의 변경

eth1과 eth2 클라이언트 소프트웨어를 결합하는 방법에는 여러 가지 방법(예: 완전한 병합, eth1을 라이브러리로 가져오기, 둘 사이의 통신 프로토콜을 통해 등)이 있지만 이 기사에서는 다음 중 하나에 중점을 둘 것입니다. 가장 최소 침입 및 모듈식 접근 방식 - eth2 클라이언트와 단순화된 eth1 엔진 간의 기본 통신 프로토콜.

eth1 및 eth2 클라이언트 구현의 다양성을 고려할 때 이 접근 방식은 클라이언트 소프트웨어가 어느 한쪽에 고정되지 않도록 하여 클라이언트 팀이 독립적으로 유지하고 자체 R&D 노력에 집중할 수 있도록 하여 신속한 프로토타이핑을 위해 소프트웨어 프로젝트를 대체로 안정적으로 유지합니다.

그래서 어떻게 생겼을까요?

대략적으로 eth1+eth2 결합 클라이언트는 다음과 같습니다.

• 그 중 eth2 엔진과 eth1 엔진은 함께 구동되며 eth2 클라이언트가 구동하는 RPC를 통해 로컬에서 통신한다.

• 둘 다 자체 p2p 인터페이스를 유지하고 피어에 연결하며 각 특정 도메인과 관련된 네트워크 프로토콜을 처리합니다.

• 이더리움 2.0 클라이언트

• Beacon Chain 및 Beacon State(시스템의 나머지 부분을 구성하는 핵심 합의 개체)

• 샤드 체인(1, eth1 샤드 체인, 2, 많은 데이터 전용 샤드 체인)

Mempool 작업[표시되지 않음](증명, 입금, 종료 등)

• P2P 인터페이스(1, 컨센서스 레이어 정보, 2, eth1 샤드 블록 가십 포함);

• eth1 엔진에 대한 RPC(모든 호출은 eth2 클라이언트에 의해 구동됨)

• 이더리움 1.0 엔진

• EVM 가상 머신(eth1 샤드 블록 실행 및 확인)

• P2P 인터페이스(1. 현재 Ethereum의 트랜잭션 가십, 2. 상태 동기화, 3. eth1 샤드 블록 가십 없음);

의견 일치

eth2 클라이언트의 RPC(모든 호출은 eth2 클라이언트에 의해 구동됨)

보조 제목

의견 일치

특히 연결된 eth1 엔진은 자체 합의를 유지할 수 없기 때문에 eth2 클라이언트에 액세스할 수 있어야 합니다. 오늘날 이더리움의 PoW에서 eth1 클라이언트는 작업 증명을 확인하고 트리 구조를 형성하며 포크 선택 규칙을 실행하여 체인의 최상위를 찾습니다. eth2에서는 이러한 메커니즘이 상당히 다르기 때문에 eth2의 핵심 합의에 대한 깊은 이해가 필요합니다. eth2 클라이언트는 eth1 엔진이 eth1 상태의 정확한 보기를 유지할 수 있도록 eth1 샤드 체인 헤드에 대한 최신 정보를 제공합니다.

eth1 엔진은 합의를 촉진하기 위해 eth2 클라이언트에 전적으로 의존하기 때문에 eth2 클라이언트와 eth1 엔진 간의 통신은 eth2 클라이언트가 호출하는 eth1 엔진의 모든 메서드(예: addBlock, getBlockProposal 등)라고 제안합니다. 이는 시스템 추론의 복잡성을 줄이고 eth1 엔진에 필요한 비즈니스 로직을 제한하기 위해 리더/팔로워 관계를 강화합니다.

eth2 클라이언트 및 핵심 합의 관점에서 eth1 샤드 체인은 다른 모든 샤드 체인(포크 선택, 교차 링크, 블록 구조, 서명 등)과 거의 동일하게 처리됩니다. 주요 차이점은 샤드 블록 콘텐츠가 eth1 엔진에 대해 실행될 수 있으므로 eth1 샤드 블록 데이터의 형식은 eth1에 상대적이어야 하며 이 성공적인 실행을 위해 추가 검증을 수행해야 합니다.

보조 제목

상태

eth2는 소위 "비콘 상태"라고 하는 핵심 합의와 관련된 상태를 가지고 있습니다. 비콘 상태 데이터는 작으며(유효성 검사자 세트의 크기에 따라 약 10-40MB) 핵심 합의를 이해하고 샤드 체인을 처리하는 방법에 필요한 모든 정보가 포함되어 있습니다. 실제로 샤드 체인의 합의 관련 부분을 처리하려면 클라이언트가 비콘 상태(예: 샤드 체인 포크 선거를 실행하는 최신 교차 링크, 현재 유효성 검사 세트 또는 임의로 할당된 셔플링)에 액세스할 수 있어야 합니다.

eth2의 상태는 항상 사용자 계층의 상태와 상호 작용하지 않으며 가장 중요한 상호 작용은 샤드 체인 데이터의 가용성입니다. 실제 사용자 계층 데이터 루트는 샤드 체인 데이터에 있으며 eth1 샤드 체인의 경우 현재 이더리움 사용자 상태 루트입니다.

eth2 클라이언트와 관련된 다양한 eth1 상태 사례는 아래에서 설명합니다.

3. 상태 저장 eth1 엔진이 있는 eth2 클라이언트는 추가 eth1 엔진이 있는 eth2 프로토콜을 실행하고 eth1 상태를 완료하여 eth1 샤드 블록을 생성할 수 있는 유효성 검사기를 실행해야 합니다. 간단). 그런 다음 로컬 상태 및 트랜잭션 메모리 풀(TX mempool)을 사용하여 요청 시 새로운 유효한 블록을 형성할 수 있습니다(자세한 내용은 아래 참조).

회로망

유효성 검사기 외에도 많은 사용자/애플리케이션 노드가 블록 탐색기, 아카이브 노드, 상태 제공자 등과 같은 완전한 상태 저장 eth1 엔진과 함께 실행될 수 있습니다.

회로망

ENR

간단하게 하기 위해 eth2와 eth1은 초기에 별도의 네트워크 스택과 프로토콜을 유지합니다. 책임 이동(예: eth1 샤드 블록 가십)에 대응하여 개발자는 기존 eth1 프로토콜(예: eth1 샤드 블록 가십) 중 일부를 더 이상 사용하지 않고 eth2 프로토콜로 대체했습니다. 초기 프로토타이핑 단계 후 또는 추가 단계에서 네트워크 스택을 통합하기 위해 eth1 프로토콜을 libp2p로 마이그레이션해야 할 수 있지만 필수 사항은 아닙니다.

eth2 클라이언트와 eth1 엔진은 동일한 discv5 DHT에 액세스할 수 있지만 독립적으로 적절하게 유능한 피어를 찾고 독립적으로 연결을 유지합니다.

보조 제목

eth1 기능(상태, 트랜잭션 등)은 ENR의 기존 eth(또는 새 eth1) 키로 표시됩니다.

eth2 기능(핵심 합의)은 ENR에서 eth2 키로 표시됩니다.

각 프로토콜의 존재는 노드가 기본 네트워크 프로토콜의 유형을 식별할 수 있고 식별할 의향이 있음을 의미합니다.

보조 제목

유선 프로토콜

1. eth2 프로토콜 1. eth2 요청/응답(1. 상태, 2. 비콘 블록 동기화, 3. 샤드 블록 동기화) 2. 핵심 합의 가십(1. 비콘 블록, 2. 증명, 3. 블록, eth1 샤딩 포함) , 4, 기타 유효성 검사기 작업), 2, eth1 프로토콜 1, eth1 유선 프로토콜의 하위 집합(1, 트랜잭션 가십, 2, getnodedata 또는 새 메서드와 같은 동기화 방법, 3, 영수증 받기 )

3. eth2 클라이언트가 eth1 블록 가십을 처리하는 이유 eth2는 샤드 블록의 생성, 가십 및 검증을 처리하는 데 특별히 사용됩니다. 우리의 목표는 eth1 샤드가 표준이 되고 나머지 샤드와 가능한 한 일관성을 유지하는 것입니다. 핵심 합의와 관련하여 다른 샤드와 비교하여 eth1 블록의 주요 차이점은 eth1 엔진에 대해 블록 콘텐츠를 실행/검증하는 기능입니다.

유효성 검사기가 eth1 샤드 블록을 비콘 체인으로 분기할 때 eth2 클라이언트는 eth1 엔진을 다시 호출하여 블록을 실행하고 유효성을 검사합니다.

상태 저장 eth1+eth2 결합 노드가 새로운 eth1 샤드 블록을 수신하면 eth2 클라이언트는 eth1 엔진을 다시 호출하여 블록을 검증하고 로컬 상태 저장소를 업데이트합니다.

보조 제목

트랜잭션 가십 및 스토리지 풀 mempool

eth1 샤드 블록은 연결된 eth2 클라이언트에서 eth1 엔진으로 공급됩니다. 이러한 블록에 포함된 트랜잭션은 현재 이더리움 메인넷 PoW 블록과 유사한 방식으로 스토리지 풀에서 제거되어야 합니다.

블록 생산

연결된 eth2 클라이언트에 따라 스토리지 풀 mempool의 콘텐츠에서 eth1 샤드 블록이 생성됩니다. 이 RPC 메서드 및 기본 기능은 getWork와 유사하지만 해시가 아닌 전체 블록 콘텐츠를 반환합니다.

보조 제목

블록 생산

비콘 블록 및 비 eth1 샤드 블록의 경우 eth2 클라이언트는 유효한 블록을 생성하는 데 필요한 모든 것을 갖추고 있습니다.

eth1 샤드 블록의 경우 eth2 클라이언트는 유효한 블록을 생성하기 위해 eth1 상태, 트랜잭션 및 기타 기본 eth1 구조에 즉시/항상 액세스할 수 있습니다. 반대로 지정된 검증자가 eth1 블록을 생성하면 eth2 클라이언트는 실행 가능한 eth1 블록 데이터(TX, 상태 루트 등)를 eth1 엔진에 요청합니다. 그런 다음 eth2 클라이언트는 이 eth1 블록 데이터를 완전한 샤드 블록(슬롯, positer_index, positer_signature 등 추가)으로 압축하고 블록을 네트워크에 브로드캐스트합니다.

eth1 엔진은 현재 이더리움 메인넷에서 사용하는 것과 같은 방식으로 eth1 트랜잭션 저장소 풀을 관리하고 eth2 클라이언트 정보의 업데이트를 통해 최신 eth1 헤드 상태를 유지하기 때문에 유효/실행 가능한 eth1 블록 데이터를 생성할 수 있습니다.

• 보조 제목

• 다음 단계는 무엇입니까?

• 이 일반 설계에 동의하면 다음 단계는 다음과 같습니다.

• eth1 엔진을 구동하는 eth2 클라이언트에 대한 가정이 기존 eth1 소프트웨어와 일치하고 기존 eth1 소프트웨어에 의도하지 않은 부담을 주지 않도록 합니다.

• new_head(block), validate_block_transition(block), get_proposal(parent_root) 등과 같이 eth1 엔진을 구동하는 데 사용되는 통신 프로토콜을 보다 명확하게 정의합니다.

필요한 eth1 프로토콜의 하위 집합 및 구체적으로 ENR을 사용하는 방법과 같은 네트워크 구성 요소를 정의합니다.