"0x10" 주소의 가스 소비 차이로 인한 베를린 하드포크 버그

블록의 Ethereum OpenEthereum 단일 클라이언트 #12244294의 버그로 인해 당시 이더리움 네트워크가 종료되었고 문제 블록이 생성된 후 네트워크를 따라잡지 못했습니다. 그렇다면 이 사고의 원인은 무엇이었을까요?

사고를 유발한 트랜잭션을 보려면 Tokenview Ethereum 브라우저를 사용하십시오.https://eth.tokenview.com/cn/tx/0x7006f38fa2e6654fae1a781aefc5885fe0cb8f778b1add10636eaf7e34279247

KuCoin 거래소에서 다른 주소로 ETH를 분배하는 컨트랙트 콜 거래입니다.

계약 호출 프로세스를 주의 깊게 분석해 보겠습니다.

1. 브라우저의 "데이터 입력" 열에 계약 호출의 매개변수가 표시됩니다. 첫 번째 줄은 주소 목록이 "40"(16진수) 바이트, 즉 64바이트에서 시작함을 나타냅니다. 네 번째 줄은 그림, 두 번째 줄은 이체 금액 목록이 데이터 입력 열의 15번째 줄인 "1a0"(16진수) 바이트, 즉 416바이트부터 시작함을 나타냅니다.

2. 전송은 주소록 순서대로 이루어지며, 각 주소로 전송된 양은 하나씩 전송 데이터 목록에 해당합니다.

3. 이제 주소 목록을 탐색하기 시작합니다. 세 번째 줄의 "10"(16진수)을 보면 ETH를 다음 16개 주소로 전송할 것임을 의미합니다.

그림의 순서에 따라 10까지 세면 찾은 값은 "10"이 됩니다. 이 값은 실제로 이체 금액을 나타내는 목록의 길이입니다. 그러나 세 번째 줄의 지침에 따라 16개의 주소로 전송해야 하며, 그러면 계약은 "0x10"을 주소로 사용하여 전송 작업을 계속하고 0 ETH를 "0x10" 주소로 전송합니다.

실제로 "0x10"은 EVM의 "특수 주소" 중 하나이며 EVM의 미리 컴파일된 계약 목록에 완전히 포함됩니다. BLS 페어링 암호화 프로그램에 대해 EIP-2537에서 주장하는 미리 컴파일된 계약이지만이 EIP는 아직 메인넷에 배포되지 않았습니다.

보조 제목

"0x10" 주소의 가스 소비는 다양합니다.

베를린 하드포크는 EVM에서 가스 소비 측정 방식을 변경했습니다. EIP-2929 구현 후 트랜잭션에서 동일한 스토리지 슬롯에서 상태 저장 작업이 여러 번 수행되면 첫 번째 실행에서 더 많은 가스를 소비하고 후속 실행에서는 더 적은 가스를 소비합니다.

이것이 블록 #12244294에 있는 OpenEthereum 버그의 원인입니다. OpenEthereum에는 미리 컴파일된 EVM 구현 목록이 포함되어 있습니다.따라서 OpenEthereum은 이 트랜잭션에서 "0x10"에 액세스하는 트랜잭션에 대해 가스 할인을 제공합니다. 그러나 네트워크의 대부분의 활성 클라이언트는 이러한 방식으로 EIP-2929를 구현하지 않으며 활성화된 미리 컴파일된 계약에 액세스하는 트랜잭션에 대해서만 가스 할인을 제공합니다.

결과적으로 OpenEthereum 클라이언트의 거래에 의해 소비된 Gas의 양에 대한 계산은 네트워크의 다른 클라이언트와 다릅니다.

가스 소비 다이버전스로 인한 이 OpenEthereum 단일 클라이언트 중단 시간은 주요 체인 포크를 유발할 만큼 심각하지는 않지만 저항을 개선하기 위해 다중 클라이언트 구현을 사용하도록 상기시켜 줍니다.

블록체인 기술은 여전히 ​​끊임없이 시도하고 발전하는 과정에 있음을 부인할 수 없습니다. .체인 세계.