이더리움의 PoS "The Merge"로의 전환은 애플리케이션 계층에 어떤 영향을 미칩니까?

星球君的朋友们

Odaily资深作者

2021-11-30 22:44 (UTC+8)

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

병합은 최종 사용자, 스마트 계약 및 dapp 작동 방식에 미치는 영향을 최소화하면서 전환하도록 설계되었습니다.

AI 요약

펼치기

병합은 최종 사용자, 스마트 계약 및 dapp 작동 방식에 미치는 영향을 최소화하면서 전환하도록 설계되었습니다.

원천:

원천:공식 이더리움 블로그

이더리움 네트워크의 지분 증명(The Merge)으로의 전환이 임박했습니다. 이제 개발 네트워크가 구축되고 사양이 확정되며 커뮤니티 지원을 위한 준비가 본격적으로 시작되었습니다. 병합은 최종 사용자, 스마트 계약 및 dapp 작동 방식에 미치는 영향을 최소화하면서 전환하도록 설계되었습니다. 즉, 그 과정에서 강조할 가치가 있는 몇 가지 작은 변경 사항이 있습니다. 변경 사항을 살펴보기 전에 The Merge의 전체 아키텍처에 대한 통찰력을 제공하는 몇 가지 링크는 다음과 같습니다.

로드맵 진화
병합된 클라이언트 아키텍처

이 기사의 나머지 부분에서는 독자가 위의 내용에 익숙하다고 가정합니다. 좀 더 깊이 파고들고 싶은 분들을 위해 아래에서 The Merge의 전체 사양을 확인할 수 있습니다.

합의 계층
합의 계층
엔진 API

1 블록 구조

Ethereum 합병 후 PoW(작업 증명)는 더 이상 네트워크에 존재하지 않습니다. 대신, 이전 PoW 부분은 비콘 체인에서 생성된 블록의 필수 부분이 됩니다. 그런 다음 비콘 체인을 이전 PoW 합의 계층을 대체하는 이더리움의 새로운 PoS 합의 계층으로 생각할 수 있습니다. Beacon Chain 블록에는 현재 PoW 체인의 블록과 병합된 ExecutionPayloads가 포함됩니다. 아래 다이어그램은 이 관계를 보여줍니다.

최종 사용자 및 애플리케이션 개발자에게 이러한 ExecutionPayload는 Ethereum과 상호 작용할 수 있는 장소입니다. 이 계층의 트랜잭션은 실행 계층 클라이언트(Besu, Erigon, Geth, Nethermind 등)에서 계속 처리됩니다. 다행스럽게도 The Merge는 실행 계층의 안정성으로 인해 최소한의 주요 변경 사항만 도입합니다.

2 채광 및 Ommer 블록 필드

병합 후 이전에 PoW 블록 헤더에 포함되었던 여러 필드는 PoS와 관련이 없기 때문에 더 이상 사용되지 않습니다. 도구 및 인프라의 중단을 최소화하기 위해 이러한 필드는 데이터 구조에서 완전히 제거되지 않고 0 또는 해당 데이터 구조로 설정됩니다. EIP-3675에서 블록 필드에 대한 전체 변경 사항을 찾을 수 있습니다.

PoS는 PoW처럼 자연스럽게 ommers(일명 엉클 블록)를 생성하지 않기 때문에 각 엉클 블록(ommers)의 이러한 목록은 비어 있고 이 목록의 해시(ommersHash)는 RLP로 인코딩된 해시 목록의 빈 해시가 됩니다. 또한 PoW에는 난이도와 nonce도 포함되어 있기 때문에 이후에는 0으로 설정하여 바이트 크기 값을 부여합니다.

마이닝과 관련된 또 다른 필드인 mixHash는 0으로 설정되지 않고 비콘 체인의 RANDAO 값을 포함하게 됩니다. 아래에서 이에 대해 자세히 알아보세요.

3 BLOCKHASH 및 DIFFICULTY opcode 변경

병합 후에도 BLOCKHASH opcode는 계속 작동하지만 PoW 해싱 절차에 의해 더 이상 위조되지 않는다는 점을 감안할 때 이 opcode가 제공하는 유사 무작위성은 훨씬 약할 것입니다.

이와 관련하여 DIFFICULTY opcode(0x44)가 업데이트되고 이름이 RANDOM으로 변경됩니다. 병합되면 비콘 체인에서 제공하는 임의의 비콘 출력을 반환합니다. 따라서 BLOCKHASH와 비교할 때 이 opcode는 여전히 편견이 있지만 응용 프로그램 개발자가 사용할 수 있는 더 강력한 무작위성 소스가 될 것입니다.

RANDOM에 의해 노출된 값은 PoW 계산과 관련된 mixHash 값을 저장하는 ExecutionPayload에 저장됩니다. Payload의 mixHash 필드 이름도 random으로 변경됩니다.

다음은 병합 전후에 DIFFICULTY 및 RANDOM opcode가 작동하는 방식에 대한 그림입니다.

병합 전에 0x44 opcode가 블록 헤더의 어려움 필드를 반환하는 것을 볼 수 있습니다. 병합 후 RANDOM으로 이름이 변경된 opcode는 이전에 mixHash가 포함된 블록 헤더 필드를 가리키며 이제 비콘 체인 상태의 임의 값을 저장합니다.

EIP-4399에 공식화된 이 변경 사항은 온체인 애플리케이션에 병합이 발생했는지 여부를 평가하는 방법도 제공합니다. 이 EIP의 도입에 따르면:

또한 이 EIP에서 제안한 변경 사항을 통해 스마트 계약은 PoS로의 업그레이드 여부를 결정할 수 있습니다. 이는 DIFFICULTY opcode의 반환 값을 분석하여 수행할 수 있습니다. 값이 2**64보다 크면 트랜잭션이 PoS 블록에서 실행되고 있음을 의미합니다.

4 차단 시간

합병은 이더리움의 평균 블록 시간에 영향을 미칠 것입니다. 현재 PoW에서는 평균 약 13초마다 블록이 생성되며 실제 블록 간격 시간은 상당한 차이가 있습니다. 지분 증명에서 블록 간격은 검증자가 오프라인 상태가 되거나 제 시간에 블록을 커밋하지 않아 슬롯이 누락되지 않는 한 정확히 12초가 됩니다. 실제로 이것은 슬롯에서 발생합니다.<1%。

이는 네트워크의 평균 블록 시간이 ~1초 단축된다는 의미입니다. 계산에서 특정 평균 블록 시간을 가정하는 스마트 계약은 이를 고려해야 합니다.

5 안전 헤드 및 최종 블록

PoW에서는 블록 재구성이 항상 가능합니다. 애플리케이션은 일반적으로 새 안전 헤드에서 몇 개의 블록이 채굴될 때까지 기다렸다가 정식 체인에서 제거되거나 이미 "확인"될 가능성이 없다고 생각합니다. 병합 후 우리는 최종적이고 안전한 헤드 블록이라는 개념을 갖게 됩니다. 이러한 블록은 "확인된" PoW 블록보다 더 안정적으로 사용할 수 있지만 올바르게 사용하려면 이해의 변화가 필요합니다.

최종 블록은 검증인의 2/3 이상이 정식으로 승인한 블록입니다. 충돌하는 블록을 생성하려면 공격자는 총 스테이킹된 ETH의 최소 1/3을 태워야 합니다. 이는 작성 당시 ETH에서 100억 달러(또는 >250만) 이상을 의미합니다.

안전한 헤드는 정상적인 네트워크 조건에서 표준 체인에 포함하고 싶은 블록입니다. 네트워크 대기 시간이 4초 미만이라고 가정하면 대부분의 유효성 검사기는 정직하고 포크 선택 규칙에 대한 공격이 없으므로 안전 헤드는 고아 블록이 되지 않습니다. 다양한 상황에서 안전한 머리를 계산하는 방법을 자세히 설명하는 프레젠테이션은 여기에서 볼 수 있습니다. 또한 안전 헤드의 가정과 보장은 다음 논문에서 공식적으로 정의되고 분석될 것입니다.

병합 후 실행 계층 API(예: JSON RPC)는 기본적으로 최신 블록을 요청하면 안전 헤드를 반환합니다. 정상적인 네트워크 조건에서 안전 헤드와 체인의 실제 상단은 동일합니다(몇 초 동안만 안전 헤드와 테일). 안전한 헤드는 현재 PoW 최신 블록에 비해 재구성될 가능성이 적습니다. PoW 체인의 실제 팁을 노출하기 위해 JSON RPC에 안전하지 않은 플래그가 추가됩니다.

확정된 블록은 또한 새로운 확정 플래그를 통해 JSON RPC를 통해 노출됩니다. 그런 다음 PoW 증명에 대한 강력한 대안이 될 수 있습니다. 아래 표에 요약되어 있습니다.

다음 단계