이더리움(ETH) 바이트코드 및 코드 청크 분석
코드 청킹은 바이트코드를 더 작은 청크로 나누는 전략으로, 증인 크기를 줄이는 데 도움을 줍니다. 그러나 이 접근 방식은 실행 중에 바이트코드의 상대적으로 작은 부분만 접근되는 경우에만 효과적입니다. 이 분석은 코드 청킹의 유용성을 평가하기 위해 바이트 및 청크 접근 패턴을 탐색합니다.
방법론
데이터 수집 및 분석 코드를 포함한 전체 저장소는 여기에서 찾을 수 있습니다.
분석
주요 데이터셋 통계
- 블록 범위: 15537394 (더 머지)–22000000
- 블록 수: 100898 (블록 범위에 고르게 분포)
- 총 컨트랙트 상호작용: 19,934,701
- 블록당 최소 고유 컨트랙트 상호작용: 1
- 블록당 고유 컨트랙트 상호작용의 중앙값: 187
- 블록당 최대 고유 컨트랙트 상호작용: 659
- 상호작용한 총 고유 컨트랙트: 1,220,017
평균 바이트 접근 비율
- 원본: 22.8%
- 코드 크기 포함: 54.0% (+31.2%)
- 코드 복사 포함: 31.5% (+8.7%)
평균 청크 접근 비율
- 원본: 29.6%
- 코드 크기 포함: 57.8% (+28.2%)
- 코드 복사 포함: 37.6% (+8.0%)
코드 접근 명령어를 포함한 후, 우리는 접근 비율의 중간 정도 증가를 볼 수 있습니다. 하지만 이는 주로 코드 크기 연산 코드 때문입니다. 앞서 언급했듯이, 계정 필드에 코드 크기를 추가하면 코드 복사 연산 코드가 전체 바이트코드에 접근하는 유일한 명령어가 됩니다. 코드 복사 명령어의 양이 상당히 적기 때문에 전체 접근 비율은 낮습니다.
코드 청킹은 실행 가능한 해결책인가?
<이더리움 개선 제안(EIP)-2926>을 참조하면, 코드 청킹의 주요 목적은 증인 크기를 줄이는 것입니다. 현재 상황에서는 전체 바이트코드를 코드 증명에 사용해야 합니다.
우리의 분석 결과, 계약의 바이트코드에 있는 모든 바이트가 사용되는 것은 아닙니다. 실제로 바이트와 청크의 상대적으로 작은 부분만 사용됩니다. 현재 접근 패턴을 기반으로, 코드 청킹을 구현한다면 코드 증인에 포함된 실제 사용 바이트의 양을 크게 줄일 수 있습니다.
EIP2926의 계정 필드에 코드 크기를 추가하면 코드 복사 연산 코드가 전체 바이트코드에 접근해야 하는 유일한 명령어가 됩니다. 또한 우리의 발견에서 볼 수 있듯이, 코드 복사 연산 코드의 양은 코드 크기보다 상당히 적습니다. 따라서 현재 접근 패턴을 기반으로 평균 코드 증인 크기를 더욱 줄일 수 있습니다.
추가로 탐색할 수 있는 부분은 최적의 청크 크기를 결정하는 것입니다. EIP-2926에서는 31바이트 청크를 사용합니다. 우리는 청크당 활용되는 바이트 수를 최대화하기 위해 16바이트와 같은 더 작은 청크 크기를 탐색해 볼 수 있습니다. 하지만 이는 추가적인 해시 오버헤드를 수반합니다. 따라서 최적의 균형을 찾기 위해 다양한 청크 크기로 실험해야 합니다.
