EIP-3675: Upgrade consensus to Proof-of-Stake (한글 번역 + 내용 추가)

프동프동·2023년 10월 23일
3675BitcoinEIPPoSProof of Stakeconsensuseip3675ercethereumpow이더리움작업증명지분증명
1

EIP

목록 보기
1/1
post-thumbnail

EIP-3675: Upgrade consensus to Proof-of-Stake

지분 증명을 도입하는 이더리움 메인넷의 합의 메커니즘 업그레이드에 대한 사양입니다.

Abstract

이 EIP는 작업 증명(PoW)을 더 이상 사용하지 않으며, 비콘 체인에 의해 구동되는 새로운 지분 증명 합의 메커니즘(PoS)으로 대체합니다.
새로운 합의 메커니즘의 부트스트랩에 대한 정보는 EIP-2982에 문서화되어 있습니다. 비콘 체인의 전체 사양은 ethereum/consensus-specs 저장소에서 확인하실 수 있습니다.

이 문서는 합의 방식 업그레이드에 의해 도입된 블록의 구조, 블록 처리, 포크 선택 규칙, 그리고 네트워크 인터페이스의 변경 세트를 명세하고 있습니다.

Motivation

  • 비콘 체인 네트워크는 2020년 12월 부터 가동되었습니다. 이 기간 동안 안전성이나 지속성에 관한 문제가 발견되지 않았습니다. 이런 오랜 기간 동안 문제 없는 운영은 비콘 체인 시스템의 지속 가능성과 Ethereum 메인넷의 보안 제공자가 될 준비가 되어 있다는 것을 보여줍니다.
  • Proof-of-Stake(PoS) 합의 메커니즘을 도입하는 동기에 대해 이해하려면 EIP-2982의 Motivation 섹션을 참조하면 됩니다. EIP-2982: Serenity Phase 0

Specification

Definitions

  • PoW block: 기존의 작업 증명(Proof-of-Work) 메커니즘에 의해 구축되고 검증된 블록입니다. 다시 말해, 합의 업그레이드 이전의 Ethereum 네트워크의 블록을 의미합니다.
  • PoS block: 새로운 지분 증명(Proof-of-Stake) 메커니즘에 의해 구축되고 검증된 블록입니다.
  • Terminal PoW block: PoW 방식의 마지막 블록으로, 특정 조건을 만족하는 블록입니다. 이 조건은 Ethereum 네트워크가 Proof-of-Stake (PoS)로 전환되기 직전의 마지막 PoW 블록을 식별하는데 사용됩니다.
    • 조건은 다음과 같습니다.
      • 해당 PoW 블록의 총 난이도 (pow_block.total_difficulty)는 TERMINAL_TOTAL_DIFFICULTY 값보다 크거나 같아야합니다.
      • 그리고 해당 PoW 블록의 부모 블록의 총 난이도(pow_block.parent_block.total_difficulty)는 TERMINAL_TOTAL_DIFFICULTY 값보다 작아야합니다.
    • 이 조건을 만족하는 블록은 PoW에서 PoS로의 전환을 표시하는 마지막 PoW 블록이 됩니다.
      • 또한 네트워크 내에서 이러한 조건을 만족하는 여러 종단 PoW 블록이 존재할 수 있습니다.

        특정 조건을 만족하는 PoW 블록이 여러개 있을 수 있습니다. 이는 PoW에서 PoS로 바뀌는 그 시점에도 여러 블록이 동시에 만들어질 수 있다는 것을 의미합니다.
        예를 들면, 블록 A와 블록 B가 동시에 특정 조건을 만족할 수 있습니다. 이 두 블록은 같은 ‘이전 블록’을 기반으로 하지만, 다른 내용을 가질 수 있습니다. 이런 상황에서는 네트워크 참여자들이 더 긴 체인을 선택하는 규칙을 따라 하나의 블록을 선택하게 됩니다. 결국, 더 많은 작업이 이루어진 ‘정식’체인이 선택되게 됩니다.

  • TERMINAL_TOTAL_DIFFICULTY: Ethereum이 새로운 PoS 방식으로 바뀌게 되는 특정 ‘난이도’ 값입니다. Ethereum 메인넷에서는 이 값을 반드시 58750000000000000000000로 설정해야합니다.
    • 네트워크의 총 난이도가 이 특정 값에 도달하면, Ethereum은 현재의 Proof-of-Work (PoW) 방식에서 새로운 Proof-of-Stake(PoS) 방식으로 전환됩니다.
  • TRANSITION_BLOCK: ‘정식 체인’에서 가장 처음으로 나타나는 PoS 블록을 의미합니다. 다시 말하면 모든 PoS 블록 중에서 가장 낮은 블록 번호를 가진 블록을 말합니다.
    • PoW방식에서 PoS방식으로 전환되면서 처음으로 생성되는 PoS 블록을 TRASITION_BLOCK이라고 부릅니다.
  • POS_FORKCHOICE_UPDATED: Proof-of-Stake(PoS) 방식에서 ‘포크 선택’의 상태가 바뀔 때 발생하는 이벤트를 말합니다.
    • 블록체인에서 ‘포크 선택’은 여러 블록이 동시에 발견될 때, 어떤 블록 또는 블록 체인을 유효하게 인정할 것인지를 결정하는 규칙입니다. 이 이벤트는 그러한 선택 규칙이 업데이트 될 때마다 발생합니다.
  • FORK_NEXT_VALUE: 다가오는 합의(consensus) 업그레이드를 위해 FORK_NEXT 파라미터로 설정된 블록 번호를 나타냅니다.
    • Ethereum 네트워크에서 다음 합의 업그레이드가 발생할 예정인 특정 블록 번호를 FORK_NEXT_VALUE로 지정하게 됩니다. 이 값는 네트워크가 그 블록 번호에 도달하면 업그레이드를 시작하게 됩니다.
  • TERMINAL_BLOCK_HASH: 설정된 경우, 즉 0x0000000000000000000000000000000000000000000000000000으로 스텁되지 않은 경우 터미널 PoW 블록의 해시를 지정합니다.
    • 마지막으로 생성된 PoW 블록의 고유한 '해시' 값을 나타냅니다. 만약 이 값이 설정되어 있다면, 그것은 마지막 PoW 블록의 해시를 의미합니다. 그러나 만약 이 값이 0x0000000000000000000000000000000000000000000000000000000000000000로 설정되어 있다면, 그것은 아직 해당 해시 값이 설정되지 않았음을 의미합니다.
  • TERMINAL_BLOCK_NUMBER: TERMINAL_BLOCK_HASH가 설정된 경우 터미널 PoW 블록의 번호를 지정합니다.
    • 마지막으로 생성된 PoW 블록의 번호입니다.

PoS events

  • 이름에 POS_ 접두사가 붙은 이벤트들을 PoS 이벤트라고 합니다. 이 이벤트들은 새로운 PoS 메커니즘에 의해 생성됩니다.
  • 이는 Event에 지정된 블록에 대한 특정 assertion이 이루어졌음을 나타냅니다.
  • PoS Event의 기본 로직은 비콘 체인 명세서에서 찾을 수 있습니다.
  • 각 PoS 이벤트가 발생할 때, 이 EIP에 의해 지정된 해당 액션을 취해야합니다.

PoS Event에 대한 추가 정보

  • 다른 형태가 명시적으로 지정되지 않은 경우에는 PoS Event에 포함된 블록에 대한 참조는 블록 해시의 형태로 제공됩니다.
    • PoS 이벤트에서 블록을 참조할 때 기본적으로 그 블록의 '해시 값'을 사용하여 해당 블록을 지칭합니다. 이 '해시 값'은 각 블록마다 고유하기 때문에, 이 값을 통해 특정 블록을 정확하게 식별할 수 있습니다.그러나 문장에서 "unless another is explicitly specified"라는 부분은, 특별한 경우나 조건에서는 다른 방식의 참조가 사용될 수 있다는 것을 의미합니다. 즉, 문서나 규격에서 명시적으로 다른 참조 방식을 지정하면, 그 방식을 따르게 됩니다.
  • POS_FORKCHOICE_UPDATED: Event는 canonical 체인의 Head와 가장 최근에 finalized된 블록에 대한 참조를 포함합니다. 시스템에서 첫 번째 블록이 발생하기 전에, 이 이벤트에 의해 제공된 확정 블록 해시는 0x0000000000000000000000000000000000000000000000000000000000000000으로 초기화됩니다.
    • canonical chain head: 가장 최근에 추가된 블록을 의미한다.
    • most recent finlized block: 네트워크 참여자들에 의해 검증되고 확정된 가장 최근의 블록

    그런데 시스템에서 첫 번째 확정 블록이 발생하기 전에는, 이 이벤트에 의해 제공되는 확정 블록의 해시 값은 '0x0000000000000000000000000000000000000000000000000000000000000000'으로 초기화됩니다. 이 값은 임시로 사용되는 값으로, 실제 확정 블록의 해시 값이 아닙니다.
    간단히 말하면, POS_FORKCHOICE_UPDATED 이벤트는 현재 체인의 최신 블록과 최근에 확정된 블록에 대한 정보를 제공합니다. 그리고 첫 확정 블록이 아직 발생하지 않았다면, 임시 해시 값으로 초기화됩니다.

  • FIRST_FINALIZED_BLOCK: POS_FORKCHOICE_UPDATE에 의해 지정되며, 스텁과 다른 해시를 가진 첫번째 최종 블록을 나타냅니다.
    • 중요한 점은 이 블록의 해시 값이 앞서 언급한 임시 해시값 0x0000000000000000000000000000000000000000000000000000000000000000과 다르다는 것입니다. 간단히 말하면 FIRST_FINALIZED_BLOCK은 PoS **체인에서 첫 번째로 확정된 블록을 의미하며, 이 블록은 POS_FORKCHOICE_UPDATED** Event에 의해 특별히 지정됩니다. 그리고 이 블록의 해시 값은 임시 값이 아닌 실제 블록의 고유한 해시 값을 가집니다.

Client software configuration

Client software는 Ethereum 네트워크와 상호 작용하는 프로그램입니다. 이 소프트웨어를 구성할 때, 몇가지 중요한 매개변수를 포함시켜야합니다.

이 매개변수들은:

  • TERMINAL_TOTAL_DIFFICULTY: PoW에서 PoS로 전환을 시작하는 데 필요한 총 난이도 값
  • FORK_NEXT_VALUE: 다가오는 합의 업그레이드를 위한 블록 번호
  • TERMINAL_BLOCK_HASH: 마지막 PoW 블록의 해시 값
  • TERMINAL_BLOCK_NUMBER: 마지막 PoW 블록의 번호

이러한 매개변수들은 Client Software의 바이너리 배포버전에 반드시 포함되어야합니다.

추가적인 참고사항으로는 만약 TERMINAL_BLOCK_HASH가 임시 해시 값 0x0000000000000000000000000000000000000000000000000000000000000000으로 설정되어 있다면, TERMINAL_BLOCK_HASH와 TERMINAL_BLOCK_NUMBER 매개 변수는 효력이 없게 됩니다.

PoW Block processing

PoW 블록 처리에 관한 내용입니다.

  • "PoW blocks that are descendants of any terminal PoW block MUST NOT be imported.":
    • “terminal PoW block”은 PoW 방식에서 마지막으로 생성된 블록을 의미합니다.
    • 이 문장은 terminal PoW 블록 이후에 생성된 모든 PoW 블록들은 네트워크에 추가되어서는 안 된다는 것을 의미합니다.
  • “This implies that a terminal PoW block will be the last PoW block in the canonical chain.":
    • 이 문장은 terminal PoW 블록이 Canonical chain에서 마지막 PoW 블록이 될 것임을 의미합니다.

Ethereum이 PoW에서 PoS로 전환될 때, 마지막으로 인정한 PoW 블록 이후에는 어떠한 PoW 블록도 네트워크에 추가되어서는 안된다는 의미입니다.

Constants

NameValue
MAX_EXTRA_DATA_BYTES32

Ethereum Block Header에 포함될 수 있는 Extra data의 최대 바이트 크기를 나타냅니다.

extra data는 블록을 생성한 마이너에 의해 추가될 수 있는 추가 정보를 포함하는 필드입니다.

Block structure

  • TRANSITION_BLOCK 부터 몇몇 블록 필드들의 값이 고정된 상수 값으로 변경되며, 아래 표에 낭려된 각 블록 필드는 반드시 해당 상수 값으로 대체해야 합니다.
    FieldConstant valueComment
    ommersHash0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347= Keccak256(RLP([]))
    difficulty0
    mixHash0x0000000000000000000000000000000000000000000000000000000000000000
    nonce0x0000000000000000
    ommers[]RLP([]) = 0xc0
    • ommerHash: 이전의 “ommer” 또는 “uncles”의 해시 값이 이제는 고정된 값으로 설정됩니다. 이 값은 빈 리스트의 Keccak256 해시 값과 동일합니다.
    • difficulty: 블록의 난이도 값이 0으로 설정됩니다.
    • mixHash: 이 필드의 값이 0으로 설정됩니다.
    • nonce: 이 필드의 값이 0으로 설정됩니다.
    • ommers: ‘ommers’ 또는 ‘uncles’ 리스트가 빈 리스트로 설정됩니다.

TRANSITION_BLOCK부터 블록의 extraData 필드의 유효성 검사가 변경됩니다. 블록의 extraData 길이는 MAX_EXTRA_DATA_BYTES 바이트보다 작거나 같아야합니다.

참고

  • 여기서 명시되지 않은 블록 필드의 로직과 유효성 조건은 변경되지 않아야합니다. 또한 전체 블록 형식도 변경되지 않아야 합니다.
  • 후속 EIP는 추가 기능을 제공하기 위해 위에서 지정된 상수 값을 재정의할 수 있습니다. 예를 들어, ERP-4399를 참조하십시오

Block validity

TRANSITION_BLOCK 부터 블록 유효성 검사 조건은 반드시 다음과 같이 변경해야합니다.

  • 블록의 difficulty 값에 대한 검증을 제거합니다. 이전에는 특정 공식에 따라 블록의 difficulty 값을 검증했지만, 이제는 그렇지 않습니다.
  • 블록의 nonce 값과 mixHash 값에 대한 Ethash 함수를 사용한 검증을 제거합니다.

Ethash는 Ethereum의 PoW 알고리즘입니다.

  • ‘ommers’ 또는 ‘uncles’라고 불리는 블록 리스트와 이 리스트의 각 멤버에 대한 모든 유효성 검사 규칙을 제거합니다.
  • Block structure 섹션에 기록된 필드의 검증을 추가합니다.

참고:
새로운 규칙 중 하나가 실패하면 해당 블록은 무효화되어야 합니다.
위의 목록에서 지정되지 않은 유효성 규칙은 변경되지 않아야합니다.

Transition block validity

위의 조건을 만족하는 것 외에도 TRANSITION_BLOCK 은 terminal PoW block의 자식 블록이어야합니다. 여기서 terminal PoW block은 PoW 방식에서 생성된 마지막 블록을 의미합니다. 즉 TRANSITION_BLOCK의 부모들은 terminal PoW block의 조건을 만족해야 합니다.

Ethereum 네트워크가 PoW에서 PoS로 전환을 시작할 때, 그 시작점이 되는 TRANSITION_BLOCK은 PoW 방식에서 생성된 마지막 블록의 바로 다음 블록이어야 한다는 것을 의미합니다.

Block and ommer rewards

TRANSITION_BLOCK 부터 Block 및 ommer(uncle) 보상에 대한 변경 사항을 설명합니다.

블록체인에서 마이너나 검증자는 블록을 생성하거나 검증하는 작업에 대한 보상을 받습니다. Ethereum에서도 마이너는 블록을 생성하거나 ommer(uncle) 블록을 포함시키는 것에 대한 보상을 받습니다.

TRANSITION_BLOCK 부터 Block 및 ommer(uncle) 보상이 폐기되거나 중단됩니다. 이는 Ethereum이 PoW에서 PoS로 전환됨에 따라 블록 생성에 대한 보상 방식이 변경되기 때문입니다.

구체적으로 다음과 같은 조치가 취해져야합니다.

  • 블록 보상에 따라 블록의 수혜자 계정의 잔액을 증가시키는 것을 제거합니다. 즉, 블록을 생성한 마이너나 검증자에게 주어지던 보상이 없어집니다.
  • 각 ommer(uncle)에 대한 ommer 포함 보상에 따라 블록의 수혜자 계정의 잔액을 증가시키는 것을 제거합니다. 이는 메인 블록에 ommer(uncle) 블록을 포함시킬 때 주어지던 추가 보상을 의미합니다.
  • 각 ommer(uncle)에 대한 ommer 블록 보상에 따라 ommer의 수혜자 계정의 잔액을 증가시키는 것을 제거합니다. 이는 ommer(uncle) 블록을 생성한 마이너에게 주어지던 보상을 의미합니다.

참고: 블록의 수혜자 계정에 영향을 주는 트랜잭션 수수료 메커니즘은 그대로 유지되어야합니다. 이는 블록 보상이 폐기되더라도, 마이너나 검증자가 트랜잭션을 처리하는 것에 대한 수수료는 계속 받게 됨을 의미합니다.

"수혜자 계정"은 Ethereum에서 블록을 생성하거나 특정 작업을 수행한 마이너나 검증자에게 보상을 지급하기 위한 대상 계정을 의미합니다. 블록을 생성할 때, 마이너는 자신의 주소를 블록의 "수혜자" 또는 "beneficiary"로 설정합니다. 그런 다음, 블록이 성공적으로 네트워크에 추가되면, 이 "수혜자 계정"은 블록 보상과 해당 블록에 포함된 모든 트랜잭션 수수료를 받게 됩니다.

Fork choice rule

Fork choice rule은 블록체인 네트워크에서 여러 가능한 체인 중 어떤 체인을 “정식” 또는 “canonical” 체인으로 간주할 것인지 결정하는 규칙입니다.

  1. Longest Chain (가장 긴 체인):
    • 이 규칙은 가장 많은 블록을 포함하는 체인, 즉 가장 긴 체인을 메인 체인으로 선택하는 것을 기반으로 합니다.
    • Proof-of-Work (PoW) 기반의 초기 블록체인 시스템에서 사용되는 기본적인 포크 선택 규칙입니다.
    • "가장 긴 체인" 규칙은 단순히 체인의 길이, 즉 체인에 포함된 블록의 수를 기준으로 합니다.
  2. Heaviest Chain (가장 무거운 체인):
    • 체인의 "무게"는 그 체인에 포함된 블록들에 소비된 전체 컴퓨팅 파워를 기반으로 합니다.
    • 따라서 "가장 무거운 체인"은 가장 많은 작업 증명이 된 체인을 의미합니다.
    • 이 규칙은 블록의 수뿐만 아니라 각 블록에 소비된 작업의 양도 고려합니다.

TERMINAL_BLOCK_HASH 매개변수가 설정된 경우, 해당 매개변수는 PoW heaviest 체인 규칙에 다음과 같은 영향을 미칩니다.

  • Canonical 블록체인은 TERMINAL_BLOCK_HASH 매개변수로 정의된 해시를 가진 블록을 포함해야합니다. 이 블록은 TERMINAL_BLOCK_NUMBER 매개변수로 정의된 해시를 가진 블록을 포함해야합니다.

참고: 이 규칙은 client software 구현에 이미 존재하는 hash 화이트 리스트 차단 기능과 유사합니다.

첫 번째 POS_FORKCHOICE_UPDATED event 부터 Fork choice rule은 다음과 같이 변경되어야합니다.

  • 기존의 PoW heaviest chain rule을 제거합니다.
  • 새로운 PoS LMD-GHOST rule을 따릅니다.

새로운 PoS LMD-GHOST fork choice rule은 다음과 같이 명시됩니다.

Ethereum 네트워크에서는 여러 가능한 체인 중 어떤 체인을 "정식" 또는 "캐노니컬(canonical)" 체인으로 간주할 것인지 결정하는 규칙이 필요합니다. LMD-GHOST는 이러한 결정을 내리는 새로운 규칙입니다.

  • POST_FORKCHOICE_UPDATED event가 발생할 때마다, 다음 조치를 취해야합니다.
    • Canonical 블록체인 결정
      • Event에 의해 지목된 헤드 블록으로 끝나는, 제네시스에서 시작하는 체인을 Canonical 블록체인으로 간주합니다
    • Canocical 블록체인의 헤드 설정
      • Event에 의해 지목된 블록을 canonical 헤드로 설정합니다.
    • 최근 확정된 블록 설정
      • FIRST_FINALIZED_BLOCK 부터 시작하여, 이벤트에 의해 지목된 블록을 최근 확정된 블록으로 설정합니다.
  • 블록 트리 저장소의 원자적 변경
    • 위에서 언급한 조치와 관련되어 블록 트리 저장소의 변경 사항은 원자적으로 적용되어야 합니다.

      “원자적으로”라는 용어는 이러한 변경 사항이 모두 한 번에 적용되거나 모두 적용되지 않아얗마을 의미합니다.

참고

  • 이 규칙은 엄격하게 준수되어야합니다.
  • 새로운 블록이 메인 체인의 헤드로 설정되려면 특정 이벤트(POS_FORKCHOICE_UPDATED)가 동반되어야합니다.

Network

Fork identifier

Ethereum 네트워크는 여러 버전의 프로토콜이 동시에 실행될 수 있기 때문에, 노드들이 서로 어떤 버전의 프로토콜을 사용하고 있는지 알아야합니다. 이를 위해 “Fork identifier”라는 것을 사용합니다.

EIP-2124 Fork identifer를 적용하는 노드는 FORK_NEXT라는 매개변수를 FORK_NEXT_VALUE 값으로 설정해야 합니다. 이렇게 함으로써 다른 노드들에게 “나는 이 EIP를 적용한 버전을 사용하고 있다”라고 알릴 수 있습니다.

devp2p

devp2p는 Ethereum 노드들이 서로 통신하기 위한 프로토콜입니다. 노드들은 블록 정보, 트랜잭션 등의 데이터를 교환하기 위해 여러 종류의 메시지를 주고 받습니다.

그런데, 이 EIP의 적용으로 인해 일부 메시지 유형은 더 이상 사용되지 않게 됩니다.

  • 마지막 PoW 블록 이후에 생성된 블록들의 정보를 네트워크에 전파하는 행위를 하는 경우 아래의 메시지를 전송해서는 안됩니다.
    • NewBlockHashes (0x01)
    • NewBlock (0x07)
  • **FIRST_FINALIZED_BLOCK**을 받은 후부터 네트워크는 다음과 같은 들어오는 메시지를 무시해야합니다.
    • NewBlockHashes (0x01)
    • NewBlock (0x07)
  • FIRST_FINALIZED_BLOCK 바로 다음에 오는 finalized block을 받은 후부터 네트워크는 다음 메시지에 대한 핸들러를 제거해야합니다.
    • NewBlockHashes (0x01)
    • NewBlock (0x07)

참고: 이 섹션에 영향을 받지 않은 메시지 처리 로직은 그대로 유지되어야합니다.

Rationale

이 EIP에서 제시된 변경사항들은 기존의 작업 증명(Proof-of-Work, PoW) 합의 알고리즘을 이미 운영 중인 비콘 체인에 의해 대표되는 새로운 지분 증명(Proof-of-Stake, PoS) 합의 알고리즘으로 안전하게 교체하기 위한 최소한의 필요한 변경사항들을 목표로 합니다.

이 EIP는 Ethereum 네트워크의 현재 합의 알고리즘을 실시간으로 교체하는 복잡성을 최소화하기 위해 설계되었습니다. 이러한 작업의 안전성과 생산까지의 시간 모두 고려되었습니다. 또한, 최소한의 변경사항만을 도입함으로써 대부분의 스마트 컨트랙트와 서비스가 전환 도중 및 전환 후에도 의도한 대로 계속 작동되도록 보장하며, 거의 또는 전혀 개입할 필요가 없게됩니다.

Total difficulty triggering the upgrade

See EIP-3675: Upgrade consensus to Proof-of-Stake

Parameterizing terminal block hash

See EIP-3675: Upgrade consensus to Proof-of-Stake

Halting the import of PoW blocks

See **Halt the importing of PoW blocks**

EIP-3675: Upgrade consensus to Proof-of-Stake

Replacing block fields with constants

  • 블록 필드를 고정된 값(상수)으로 교체
    • Ethereum의 업그레이드 과정에서 일부 블록 필드는 더 이상 사용되지 않게 됩니다. 이런 필드들을 “deprecated”또는 “폐기 예정”이라고 합니다. 이 EIP에서는 이러한 폐기 예정의 블록 필드를 일정한 값(상수)으로 교체하도록 제안하고 있습니다.

      예를 들어 PoW에서 PoS로 전환될 때 difficulty와 같은 값은 더 이상 필요하지 않게 됩니다. 이런 필드들을 특정 고정값으로 설정하여 더 이상 변경되지 않도록 할 수 있습니다.

  • 하위 호환성 유지
    • 이러한 변경은 기존의 블록 형식과 호환성을 유지하기 위해 이루어집니다. 이는 기존의 스마트 컨트랙트와 서비스가 이전과 동일한 방식으로 계속 작동할 수 있도록 도와줍니다.
  • Merkle 증명의 중요성
    • 특히, 트랜잭션, receipt 포함 여부와 상태를 검증 하기위해 Merkle 증명을 사용하는 스마트 컨트랙트에게 이 변경은 중요합니다. 이러한 스마트 컨트랙트는 제공된 블록 헤더의 해시 값을 BLOCKHASH 연산을 통해 반환된 값과 비교하여 검증합니다.

      스마트 계약 중 일부는 이 Merkle 증명을 사용하여 특정 트랜잭션이 블록 내에 포함되어 있는지 확인합니다. 만약 블록의 형식이 변경된다면, 이런 스마트 계약의 동작에 문제가 발생할 수 있습니다. 따라서, 필드를 상수로 변경하여 이런 문제를 방지하려는 것입니다.

  • 추가 유효성 규칙
    • 이 변경으로 인해 “폐기 예정”의 블록 필드를 상수로 교체하는 것을 강제하는 추가적인 유효성 규칙이 도입되었습니다.

Replacing difficulty with `0

작업 증명을 더 이상 사용하지 않게 되면 difficulty라는 개념이 더 이상 존재하지 않으며 블록 헤더 난이도 필드를 0 상수로 대체하는 것이 의미론적으로 옳습니다.

Changing block validity rules

  • PoW rule의 대체
    • PoW와 관련된 rule은 더 이상 필요하지 않게 됩니다. 따라서 이를 PoS와 관련된 새로운 rule로 대체해야합니다. 이는 Ethereum 네트워크의 합의 방식이 변경되기 때문입니다.
  • 폐기 예정의 블록 필드 검증
    • 폐기 예정의 블록 필드가 올바르게 상수 값으로 설정되었는지 검증하는 추가 규칙이 도입됩니다.

Removing block rewards

  • 블록 생성 및 검증 보상 폐지
    • PoW 메커니즘과 함께 기존의 블록 생성 및 검증에 대한 보상이 폐지됩니다.
  • PoS의 책임
    • 새로운 PoS 합의 방식은 블록을 검증하고 보상을 발행하는데 책임이 있게됩니다. 이는 이 제안이 적용되면 시작합니다.

Supplanting fork choice rule

작업 증명 메커니즘의 fork choice rule은 업그레이드 완전히 무의미해지며 새로운 지분 증명 합의 메커니즘의 해당 규칙으로 대체됩니다.

Remove of POS_CONSENSUS_VALIDATED

이 EIP의 이전 초안 버전에서는 블록의 유효성 검사 조건으로 추가적인 POS Event인 POS_CONSENSUS_VALIDATED가 필요했습니다. 이 Event는 블록을 블록 트리에 완전히 통합할 것인지, 아니면 블록 트리에서 해당 블록을 제거할 것인지에 대한 신호를 주었습니다.

그러나 이 Event는 두 가지 주요한 이유로 제거되었습니다.

  1. 불필요한 최적화
    • 이 Event는 “불량” 블록을 블록 트리에서 제거하기 위해 불필요한 최적화를 수행했습니다. 이러한 최적화는 필요하지 않습니다. 왜냐하면 PoS 합의는 이러한 “불량”블록이나 그 후손에 대해 POS_FORKCHOICE_UPDATED를 전송하지 않았기 때문입니다. 결국, 블록 트리의 다른 분기에서 PoS finality event가 발생한 후에 이러한 블록들은 제거될 수 있었습니다.
  2. 위험한 시나리오
    • 어떤 시나리오에서는 하나의 블록이 두 개의 다른 상충하는 PoS 분기에 의해 참조될 수 있었습니다. 따라서 일부 시나리오에서 동일한 블록에 대해 POS_CONSENSUS_VALIDATED == TRUE 이벤트와 POS_CONSENSUS_VALIDATED == FALSE 이벤트가 동시에 전송될 수 있었으며 이는 (1)에서 안전하게 최적화를 수행하는 능력을 완전히 무효화하였습니다.

EIP-2124 fork identifier

이 부분은 Ethereum 네트워크의 포크 관련 정보를 어떻게 처리할 것인지에 대한 설명입니다. 특히, 다음 포크 블록 번호를 미리 알 수 없는 경우에 대비하여 별도의 값(FORK_NEXT_VALUE)을 사용하여 처리하는 방법을 설명합니다.

  • EIP-2124의 FORK_NEXT의 값은 주어진 노드가 알고 있는 다음 포크의 블록 번호를 나타냅니다. 만약 노드가 다음 포크에 대한 정보를 모르면, 이 값은 0이 됩니다.
  • TRANSITION_BLOCK의 번호는 전환 트리거 조건의 동적 특성 때문에 미리 알 수 없습니다. 따라서 블록 번호가 사전에 알려지지 않기 때문에 노드들은 FORK_NEXT에 이 번호를 사용할 수 없습니다. 이 사실을 고려하여 명시적으로 설정된 FORK_NEXT_VALUE가 대신 사용됩니다.

Removing block gossip

새로운 비콘 체인 네트워크의 Block gossip 방식을 사용하게되어 기존의 Block gossip 방식이 더 이상 안전하지 않게 되어 폐기됩니다.

  • 합의 메커니즘이 업그레이드 된 후에는 비콘 체인 네트워크만이 블록을 검증하기 위한 충분한 정보를 가지게 됩니다. 따라서, Ethereum 네트워크 프로토콜에 의해 제공되는 Block gossip은 안전하지 않게되며, 비콘 체인 네트워크에 존재하는 Block gossip을 위해 더 이상 사용하지 않는 방향으로 폐기됩니다.
  • 클라이언트 소프트웨어는 P2P 컴포넌트의 처리 부하를 줄이기 위해 마지막 PoW 블록의 후손을 전파하지 않는 것이 권장됩니다. 또한 알려지지 않은 보안 속성을 가진 환경에서의 작동을 중단하는 것이 좋습니다.

Block gossip: 블록 정보를 네트워크의 다른 노드들에게 전파하는 것을 말합니다.

Restricting the length of extraData

합의 방식이 바뀌면서 긴 extraData 필드가 더 이상 필요하지 않기 때문에 길이를 32bytes로 제한하려는 제안입니다.

  • extraData field: Ethereum 블록 헤더에 포함된 정보 중 하나로, 추가적인 데이터를 저장할 수 있는 공간입니다.
  • Yellow Paper: Ethereum의 기술 사양서로, 여기서 extraData 필드의 최대 길이는 32 bytes로 정의되어 있습니다.
  • 메인넷과 대부분의 PoW 테스트넷: 이들 네트워크에서는 extraData 필드의 값이 32 bytes로 제한됩니다.
  • clique 테스트넷과 다른 네트워크: 이들 네트워크에서는 특별한 서명 또는 합의 체계를 포함하기 위해 extraData 필드의 길이가 32 bytes보다 길게 설정될 수 있습니다.
  • 이 EIP의 제안: Ethereum이 다른 합의 메커니즘에서 비콘 체인 PoS 합의 메커니즘으로 전환될 때, 더 긴 extraData 필드는 더 이상 필요하지 않습니다. 따라서, 이 EIP에서는 extraData 필드의 길이를 32 bytes로 제한하도록 제안하고 있습니다.

Backwards Compatibility

  • 이전 버전과의 호환성 문제
    • 이 EIP는 블록의 유효성, 블록 보상, 그리고 fork choice rule에서 이전 버전과의 호환성 문제를 도입합니다.
  • 합의 업그레이드의 설계
    • 이 문서에 명시된 합의 업그레이드의 설계는 Ethereum 위에 구축된 기존의 응용 프로그램과 서비스에 대한 호환성을 깨뜨리지 않습니다. 단, 아래의 EVM 섹션에서 설명된 것처럼 또는 다른 방식으로 PoW 합의에 크게 의존하는 것을 제외합니다.

EVM

이번 EIP는 EVM에 명시적인 변경 사항을 도입하지는 않지만, 기존 스마트 컨트랙트의 로직에 영향을 줄 수 있는 몇 가지 부분이 있습니다.

DIFFICULTY

이 EIP가 적용된 후에는 DIFFICULTY 연산이 항상 0을 반환하고 DIFFICULTY 필드를 0 상수로 대체하여 더 이상 사용되지 않습니다.

참고: 비콘 체인에 의해 축적된 무작위성을 반환하도록 DIFFICULTY 시맨틱을 변경하는 것은 고려중이며, 별도의 EIP에서 도입될 예정입니다.

BLOCKHASH

BLOCKHASH 작업의 출력으로 얻은 의사 난수는 이 EIP가 적용되고 (블록해시의 가변성을 감소시키는) 작업 증명 메커니즘이 지분 증명으로 대체된 이후에는 더욱 안전하지 않게 됩니다.

Test Cases

Test Cases 섹션은 제안된 변경사항이 실제로 Ethereum 네트워크에 적용될 때 어떻게 동작해야 하는지에 대한 테스트 시나리오를 제시하고 있습니다.

  • Block validity
    • TRANSITION_BLOCK부터 다음 중 하나라도 해당하면 블록이 무효화됩니다:
      • ommersHash != Keccak256(RLP([]))

        이 조건은 블록에 "ommer" 블록이 포함되어서는 안된다는 것을 나타냅니다.

      • difficulty != 0

        이 조건은 블록의 difficulty 값이 0이 아니어야 한다는 것을 나타냅니다.

      • nonce != 0x0000000000000000

        이 조건은 블록의 nonce 값이 0x0000000000000000 (즉, 0)이 아니어야 한다는 것을 나타냅니다

      • len(extraData) > MAX_EXTRA_DATA_BYTES

        이 조건은 extraData의 길이가 MAX_EXTRA_DATA_BYTES보다 길면 안된다는 것을 나타냅니다.

    • TRANSITION_BLOCK부터는 블록 보상이 beneficiary계정에 추가되지 않습니다.
  • 클라이언트 소프트웨어는 PoS LMD-GHOST 규칙을 준수합니다.
    • 헤드와 확정된 블록은 최근 POS_FORKCHOICE_UPDATED 이벤트에 따라 설정됩니다.
    • POS_FORKCHOICE_UPDATED 이벤트가 수신되지 않으면 포크 선택 상태가 업데이트되지 않습니다.
  • Transition process: 여러 전환 프로세스가 있으며, 이는 PoW에서 PoS로의 전환을 안전하게 관리하기 위한 것입니다.
    • 클라이언트 소프트웨어는 "terminal PoW block" 이후의 어떤 PoW 블록도 처리해서는 안됩니다. 즉, PoW로 생성된 마지막 블록 이후의 블록들은 무시됩니다.
    • TRANSITION_BLOCK부터 시작하여, 클라이언트 소프트웨어는 새로운 블록 유효성 규칙을 적용합니다. 이는 PoW에서 PoS로의 전환을 나타내며, 이 시점부터 블록의 유효성을 검사하는 규칙이 변경됩니다
    • 첫 번째 POS_FORKCHOICE_UPDATED 이벤트를 받은 후, 클라이언트 소프트웨어는 포크 선택 규칙을 PoS LMD-GHOST로 전환합니다. 이는 클라이언트가 어떤 블록 체인을 메인 체인으로 간주할지 결정하는 방식을 변경하는 것을 의미합니다.
    • TRANSITION_BLOCK은 "terminal PoW block"의 자식 블록이어야 합니다. 즉, PoS로의 전환을 시작하는 블록은 마지막으로 PoW로 생성된 블록 바로 다음에 와야 합니다.
    • FIRST_FINALIZED_BLOCK을 받은 후, 네트워크 메시지인 NewBlockHashes (0x01)와 NewBlock (0x07)은 무시됩니다. 이는 PoS 전환 후에는 이전 방식의 블록 전파 메시지를 더 이상 사용하지 않는다는 것을 의미합니다.

Security Considerations

Beacon chain

EIP-2982의 보안 고려 사항 섹션을 참조하세요.

EIP-2982: Serenity Phase 0

Transition process

이 부분은 Ethereum 네트워크가 PoW에서 PoS로 전환하기 위한 과정이 일반적인 하드포크보다 훨씬 복잡하다는 것을 설명하고 있습니다.

이 전환 과정은 일반적인 하드포크보다 더 복잡한 버전입니다. 이 과정은 단순한 하드포크의 일반적인 블록 높이 지점 조건 대신 여러 연속적인 단계를 거칩니다. 이 업그레이드 과정의 복잡성은 합의 메커니즘 내의 실행 계층이 아닌 기본 합의 메커니즘을 대상으로 하는 하드 포크에서 비롯됩니다. 설계는 가능한 한 단순성을 추구하지만, 이 전환 과정에서 safety와 liveness를 우선적으로 고려했습니다.

Terminal total difficulty vs block number

미리 정의된 블록 번호를 하드포크에 사용하는 것은 전환 도중 PoS 포크 선택이 우선 순위를 가지기 때문에 안전하지 않습니다.

“미리 정의된 블록 번호를 하드포크에 사용하는 것”은 Ethereum 네트워크가 특정 블록 번호에 도달하면 자동으로 합의 메커니즘을 변경하도록 설정하는 것을 말합니다. 블록 번호만을 기반으로 합의 메커니즘을 변경한다면, 악의적인 공격자가 이를 악용하여 네트워크를 혼란스럽게 만들 수 있습니다. 공격자는 PoW와 PoS 간의 전환 시점을 악용하여 블록체인을 분기시킬 수 있고, 이로 인해 네트워크의 안정성이 위협 받을 수 있습니다.

공격자는 해시 파워의 소수를 사용하여 블록 높이 요구 사항을 만족시키는 악의적인 체인 포크를 구축할 수 있습니다. 그런 다음 이 적대적인 포크에서의 PoW 블록 위에 첫 번째 PoS 블록이 악의적으로 제안될 수 있으며, 이 블록이 헤드가 되어 전환의 보안을 손상시킬 수 있습니다.

이러한 공격 시나리오로부터 네트워크를 보호하기 위해, 체인에 의해 누적된 total difficulty가 업그레이드를 트리거하는 데 사용됩니다.

따라서 체인의 총 난이도를 기반으로 업그레이드를 결정하는 방식을 채택하여 이러한 위험을 방지하려고 합니다.

Ability to jump between terminal PoW blocks

이 부분은 네트워크 분할로 인해 일부 참가자들이 마지막 PoW 블록을 관찰하지 못하는 상황을 고려하여, 전환 과정 중에 발생할 수 있는 문제점과 그에 대한 해결 방안을 설명하고 있습니다.

  • 일시적인 네트워크 분할로 인해 대다수의 네트워크 참여자가 마지막 PoW 블록을 준수하지 못하는 경우가 있을 수 있습니다.
  • 이런 상황에서 이 소수는 자신이 관찰한 소수의 마지막 PoW 블록을 기반으로 한 PoS에서 제공하는 새로운 규칙으로 포크 선택을 전환합니다.
  • 전환 과정은 두 가지 조건이 만족되어야합니다.
    • (a) 블록들이 마지막 PoW 블록의 조건을 만족하고
    • (b) FIRST_FINALIZED_BLOCK이 아직 수신되지 않았어야합니다.
  • 이는 전환 과정 중 불리한 네트워크 조건에 대한 복원력을 제공하고 복구 불가능한 포크/분할을 방지합니다.

Halt the importing of PoW blocks

Ethereum이 PoW에서 PoS로 전환하는 과정에서 발생할 수 있는 문제와 그에 대한 해결 방법을 설명합니다.

  • 문제 상황
    • Client Software의 일부가 비콘 체인 네트워크에 연결되어 있지만, Ethereum 네트워크가 TERMINAL_TOTAL_DIFFICULTY에 도달하기 전에 오프라인 상태가 되고, 네트워크가 이 임계값에 도달하는 동안 오프라인 상태를 유지한다고 가정해봅니다.

      Ethereum 네트워크는 TERMINAL_TOTAL_DIFFICULTY라는 특정 난이도 값을 도달하려고 합니다. 이 값에 도달하면 PoW에서 PoS로 전환됩니다.

    • 이러한 상황은 Client Software가 PoS로 전환하는 것을 방해하고, PoW 체인이 마지막 PoW 블록을 넘어서 계속 생성되는 경우 이 체인을 계속 따를 수 있습니다. 비콘 체인 부분이 얼마나 오래 오프라인 상태였는지에 따라 다음과 같은 다양한 부작용이 발생할 수 있습니다:

      그런데 문제는 클라이언트 소프트웨어의 일부(비콘 체인 네트워크에 연결된 부분)가 임계값에 도달하기 전에 인터넷 연결이 끊기는 등의 이유로 오프라인 상태가 된다는 것입니다. 그리고 이 오프라인 상태가 계속 유지됩니다.

  • 예상되는 부작용

    • 클라이언트가 마지막 PoW 블록의 post-state(후속 상태)를 가지고 있지 않을 수 있습니다. 이 상태는 이미 삭제(가지치기) 되었기 떄문입니다.

      • 이로 인해 클라이언트는 PoS 체인으로 재구성(re-rog)하는 것을 방해받게됩니다. 따라서 클라이언트는 복구를 위해 처음부터 동기화하는 것 밖에 선택사항이 없게됩니다.

    • 응용 프로그램, 사용자 또는 서비스가 잘못된 포크(계속 생성되는 PoW 체인)의 데이터를 사용할 수 있습니다. 이렇게 잘못된 포크의 데이터를 사용하게 되면 응용 프로그램, 사용자 또는 서비스 측에서 보안 문제가 발생할 수 있습니다.

      클라이언트가 오프라인 상태로 인해 PoS 체인으로 제대로 전환하지 못하면, 클라이언트는 필요한 데이터를 잃어버리거나 잘못된 체인의 데이터를 사용하게 되어 다양한 문제가 발생할 수 있습니다.

  • 해결 방안
    • 마지막 PoW 블록을 넘어서는 PoW 블록의 가져오지 않도록 하면 소프트웨어 또는 구성 오류 발생 시 안전성/재구성에 미치는 liveness failure을 방지할 수 있습니다.

      Safety: 시스템이 잘못된 것을 하지 않는 것(예: 잘못된 데이터 제공)
      Liveness: 시스템이 올바른 것을 계속 수행하는 것(예: 요청에 응답)
      Liveness failure: liveness 속성이 손상되었음을 의미한다. 즉, 시스템이 멈추거나, 응답을 하지 않거나, 예상대로 작동하지 않을 때 발생한다.
      블록체인에서 liveness failure는 새로운 블록이 생성되지 않거나 네트워크가 트랜잭션을 처리하지 않는 상태를 의미할 수 있다.

Terminal PoW block overriding

Ethereum의 합의 메커니즘을 PoW에서 PoS로 전환하는 과정에서 발생할 수 있는 비상 상황과 그에 따른 대응 방안에 대해 설명합니다.

  • 비상 상황 시나리오
    • 네트워크 해싱 레이트가 감소하여 업그레이드가 크게 지연되는 경우
    • 업그레이드 이전에 PoW 네트워크를 대상으로 한 공격이 발생한 경우
  • 첫 번째 시나리오 대응

    매개변수를 업데이트 하여 안전하게 가속화할 수 있습니다.

    • 네트워크 해싱 레이트 감소는 TERMINAL_TOTAL_DIFFICULTY 값을 조정하여 업그레이드 시점을 가까운 시간으로 조정함으로써 안전하게 가속화할 수 있습니다.
    • FORK_NEXT_VALUE도 그에 따라 조정됩니다.
  • 두 번째 시나리오 대응

    더 심각한 공격 시나리오의 경우, 더 광범위한 조치가 필요합니다.

    • TERMINAL_BLOCK_HASH를 특정 블록의 해시로 설정하여 해당 블록을 마지막 PoW 블록으로 지정합니다.
    • TERMINAL_BLOCK_NUMBER 는 TERMINAL_BLOCK_HASH에 의해 지정된 블록의 번호로 설정됩니다.
    • TERMINAL_TOTAL_DIFFICULTY 는 TERMINAL_BLOCK_HASH 에 의해 지정된 블록의 Total difficulty 값으로 설정됩니다.
    • FORK_NEXT_VALUE도 그에 따라 조정됩니다.

참고: 두 번째 경우의 가속화는 Ethereum 메인넷에서 중대한 활동 중단을 초래할 수 있기 때문에 가장 극단적인 시나리오에 대한 것으로 간주합니다.

Ancient blocks are no longer a requisite for a network security

PoW 네트워크에서는 체인의 유효성을 증명하기 위해 모든 블록의 기록을 유지하는 것이 중요하지만, PoS 네트워크에서는 약한 주관성 체크포인트를 사용하여 이러한 전체 기록을 검증할 필요가 없습니다. PoS는 이 체크포인트를 기반으로 동기화를 수행하며, 이 체크포인트 이전의 블록은 더 이상 필요하지 않습니다.

weak subjectivity checkpoints에 대한 명세는 ethereum/consensus-specs 저장소에서 찾을 수 있습니다.

profile
프동프동
좋은 개발자가 되고싶은

0개의 댓글