
이더리움 병합 시간 노드가 다가옴에 따라 오늘 우리는 이더리움이 합병 후 어떤 규제 문제와 애플리케이션 계층 문제에 직면할지 논의할 것입니다.
2022년 8월 16일, 이더리움 공동 창업자인 Vitalik Buterin(V God)은 트위터에서 "특정 프로토콜(Lido, Coinbase 등)을 통과한 검증인들이 이더리움 커뮤니티는 어떻게 반응할 것인가"라는 토론에 참여했습니다. 이 검토를 이더리움에 대한 공격으로 간주하고 더 넓은 합의(사회적 합의)를 통해 이러한 검증인의 약속된 권리와 이익을 파괴하는 것을 선택할 것이라고 말했습니다.
이 논의의 계기는 최근 미국 재무부 해외자산통제국(OFAC)이 토네이도 캐시 관련 이더리움 주소를 제재 대상 목록에 추가한 것입니다. 그러나 현재의 제재는 모두 중앙화 수준이며 탈중앙화를 수반하는 스마트 컨트랙트 부분에 기술적 제재를 가할 수 없다.
이는 미국이 토네이도 현금을 완전히 제재하려면 기본 이더리움 체인을 통제해야 한다는 것을 보여줍니다.그렇다면 미국 정부가 이더리움을 규제한다면 어떤 일을 겪게 될까요?
미국 정부가 이더리움을 규제하고 싶다면 가장 큰 가능성은 대규모 PoS 서약 서비스 제공업체가 이더리움에서 프로토콜 수준의 트랜잭션 검토를 수행하도록 요구하는 것입니다.간단히 말해서,
간단히 말해서,승인된 주소에서 보낸 모든 요청을 모니터링하고 승인된 주소의 트랜잭션이 포함된 모든 블록을 거부하는 것입니다 블록이 66% 이상의 지분 검증 투표를 통과하지 못하면 해당 블록의 모든 트랜잭션 요청이 롤백됩니다. 승인된 주소는 어떤 작업도 수행할 수 없으며 유효성 검사기는 어떠한 불이익도 받지 않습니다.
지금까지 이더리움 전체 네트워크에서 약정된 ETH의 양은 약 1,300만 ETH이며 Lido를 통해 약정된 ETH의 양은 약 30.9%, Coinbase는 약 14.7%, Kraken은 약 8.5%를 차지했습니다.
이미지 설명
Dune Analytics의 그림
위의 가능한 상황을 목표로 Ethereum 커뮤니티는 OFAC가 검증 노드를 통해 Ethereum을 규제하는 경우 수행할 작업을 논의하기 위해 Twitter에서 투표를 시작했습니다. V God은 위의 상황을 Ethereum에 대한 공격으로 간주하고 더 넓은 합의를 통해 이러한 노드의 약속된 권리와 이익을 파괴하는 것을 지지합니다.
다음으로 애플리케이션 계층에 대해 이야기하겠습니다.
우리는 이전 기사에서 언급했습니다. 계획에 따르면 Ethereum의 Merge는 "최소 손상"의 원칙에 따라 수행되므로 원래 실행중인 응용 프로그램 클라이언트는 아무런 의미없이 PoS로 전환할 수 있습니다. 즉, "최소한의 혼란"에도 불구하고 여전히 주목할 가치가 있는 몇 가지 작은 변경 사항이 있습니다. 이 섹션에서는 애플리케이션 개발의 관점에서 합병 후 주의해야 할 측면을 주로 소개합니다.
합병 후 현재 Eth1 및 Eth2 클라이언트는 Ethereum의 실행 계층 및 합의 계층(또는 엔진)이 됩니다.즉, Eth1 또는 비콘 체인 클라이언트의 노드 운영자는 완전히 검증된 노드를 얻기 위해 스택의 "나머지 절반"을 실행해야 합니다.텍스트
이미지 설명
병합된 클라이언트 아키텍처 Danny Ryan의 이미지 제공
블록 구조
병합이 발생하면 비콘 노드는 현재 PoW 체인을 모니터링하고 TERMINAL_TOTAL_DIFFICULTY라고 하는 미리 정의된 총 난이도 임계값에 도달할 때까지 기다립니다. 즉, PoW 체인이 전체 난이도가 >= TERMINAL_TOTAL_DIFFICULTY인 블록을 생성하면 체인의 마지막 PoW 블록으로 간주됩니다.
결과적으로 PoW 블록에 포함된 데이터는 비콘 체인 블록의 데이터 구성 요소가 되며 비콘 체인은 이전 PoW 합의 레이어를 대체하는 이더리움의 새로운 PoS 합의 레이어로 간주될 수 있습니다.
동시에 합의 확인을 수행할 때 비콘 노드는 실행 엔진(업그레이드 전 이더리움 클라이언트)과 통신하고 ExecutionPayloads를 생성하거나 확인하도록 요청합니다. ExecutionPayloads에는 상위 해시, 상태 루트, 기본 요금 및 실행할 트랜잭션 목록과 같은 정보가 포함되어 있습니다.
이러한 데이터가 생성되거나 확인되면 비콘 노드는 이를 p2p 네트워크의 다른 노드와 공유합니다.
이미지 설명
대니 라이언의 이미지 제공
실행 엔진
합병 후 실행 엔진은 주로 상태 관리, 블록 생성 및 검증 기능을 담당하며 더 이상 합의와 관련된 작업을 포함하지 않습니다. 따라서 실행 엔진이 부분적으로 수정되었으며 이러한 수정 사항은 주로 다음 세 가지 사항을 포함하여 EIP-3675에 설명되어 있습니다.
먼저 블록의 일부 데이터 필드가 수정됩니다.원본 블록의 여러 PoW 관련 필드를 0(또는 이에 상응하는 데이터 구조)으로 설정합니다. 특히 마이닝(난이도, mixHash, nonce), 삼촌 블록 보상(ommers, ommersHash)과 관련됩니다. 또한 extraData의 길이도 메인넷에서 32바이트로 제한됩니다.
둘째, 병합된 Beacon Chain만이 블록을 생성할 수 있기 때문에 실행 엔진은 블록 및 엉클 블록 보상 처리를 중지합니다.그러나 트랜잭션 수수료는 여전히 처리됩니다. 즉, 실행 엔진이 ExecutionPayload를 생성할 때 모든 트랜잭션의 개시자가 최소한 현재 baseFeePerGas 수수료를 지불하고 나머지 트랜잭션 수수료를 feeReceipient로 보낼 수 있는지 확인해야 합니다. feeReceipient는 비콘 체인 유효성 검사기 주소가 아니라 업그레이드 전의 이더리움 주소를 나타냅니다.
마지막으로 PoS가 PoW를 대체하면 실행 엔진은 더 이상 브로드캐스트 블록을 담당하지 않지만 여전히 p2p 네트워크를 통해 트랜잭션을 브로드캐스트합니다.구체적인 프로세스는 먼저 사용자가 로컬 RPC 요청을 통해 컨센서스 클라이언트에 트랜잭션을 전송하는 것입니다. 여기서 트랜잭션은 비콘 블록으로 패키징됩니다. 그러면 컨센서스 클라이언트는 p2p 네트워크에서 비콘 블록을 브로드캐스트합니다.
이미지 설명
대니 라이언의 이미지 제공
BLOCKHASH 및 DIFFICULTY opcode 변경
병합 후에도 BLOCKHASH opcode는 계속 사용할 수 있지만 더 이상 작업 증명을 통해 해당 해시 값을 생성하지 않기 때문에 이 opcode가 제공하는 의사 무작위성이 크게 약화됩니다.
동시에 DIFFICULTY opcode(0x44)는 RANDOM으로 이름이 바뀌고 비콘 체인에서 제공하는 임의의 값을 반환합니다. 따라서 이 값은 BLOCKHASH를 응용 프로그램 개발자가 사용할 수 있는 더 나은 무작위성 소스로 대체할 것입니다(편향은 여전히 존재하지만).
RANDOM 값은 작업 증명 계산과 관련된 원본 mixHash 대신 ExecutionPayload에 저장됩니다. 이 값은 업그레이드 후 임의로 이름이 변경되었습니다.
이미지 설명
대니 라이언의 이미지 제공
병합하기 전에 0x44 opcode가 블록 헤더의 어려움 필드를 반환하는 것을 볼 수 있습니다. 병합 후 난수 생성을 담당하는 RANDOM opcode는 이름이 random으로 변경된 원래 mixHash 필드를 가리킵니다.
차단 시간
합병은 이더리움의 평균 블록 시간에 영향을 미칠 것입니다. 현재 PoW에서는 평균 13초마다 블록이 생성되지만 실제 블록 간격 시간은 네트워크 정체로 인해 크게 달라질 것입니다. 그러나 PoS에서는 검증자가 오프라인 상태이거나 제 시간에 블록을 제출하지 못하고 특정 슬롯을 놓치는 등 극단적인 상황이 발생하지 않는 한 블록 간격은 12초로 고정됩니다.
참조:
참조:
《원본 링크》