EVM 객체 형식(EFO) 종합 업그레이드 분석

저자: 드라간 라키타, 패러다임 번역: 굿오바, 골든파이낸스

EOF (EVM 객체 형식)

< p style="text-align: left;">EOF(EVM 객체 형식)는 EVM을 개선하기 위해 설계된 작은 EIP 집합으로, 미래를 대비하는 새로운 바이트코드 형식을 도입합니다.

EOF의 이점

EOF의 가치는 단일화된 것이 아니며 수년간의 개발과 연구를 통해 여러 차례 포크를 거치며 발전해왔고 여러 릴리스에 걸쳐 진화했기 때문에 설명하기 어렵습니다. 더 복잡해졌습니다.

이 글의 목적은 이러한 장점을 요약하여 한 문장으로 설명하는 것입니다:

장점:

1. 장점:

   1. EOF는 옵코드에 대한 가스 가격 변경을 허용합니다

   • 다음과 같은 경우 가스 가격이 변경되면 기존 바이트코드가 다르게 작동할 수 있습니다.

   2. 가스 관측 가능성 제거

   • 이것은 GAS 옵코드와 CALL/DELEGATECALL/STATICCALL의 가스 제한을 제거하는 것을 의미합니다.

   3. L2가 사용 사례에 따라 가스를 변경하도록 허용

   • 예를 들어, zk L2의 높은 해시 연산 비용.

   • EIP-7667: 해시 함수의 가스 비용 증가.

   4. 바이트코드 크기를 줄이면 가스 사용량이 줄어듭니다

   • 초기 데이터에 따르면 코드/초기화 코드 크기와 가스 사용량이 감소했습니다:

   • Uniswap-v3 배포는 초기화 코드와 배포 코드를 6.5% 줄였습니다.

   • 유니스왑V3팩토리 배포는 약 14%, 런테스트 호출은 약 9%의 가스를 덜 사용합니다.

   • ENS DNSRegistrar 배포는 초기화 코드를 ~6%, 배포 코드를 ~1.5% 줄입니다.

   • ENS 호출 proveAndClaim: 가스 사용량 ~10% 감소.

   5. 바이트코드 변환 및 확장성 허용

   • 코드 가관측성을 제거한다는 것은 PC, CREATE/CREATE2, EXTCODEHASH, EXTCODESIZE, EXTCODECOPY, CODESIZE 및 CODECOPY 옵코드를 제거한다는 의미입니다.

   • 코드가 변경되면 레거시 컨트랙트가 작동하지 않습니다.

   • 향후 버클을 도입할 때 EOF 바이트코드에 어떤 종류의 변경도 가능합니다.

   6. EOF 사용 옵코드 즉시

   • 스왑, 다운, 교환 옵코드 가능성을 열어보세요.

   • 이를 통해 솔리디티는 스택 크기에서 더 많은 자유를 얻고 스택 깊이가 너무 깊다는 문제를 해결할 수 있습니다.

   7. 고비용 점프 타깃 분석 제거

   • Reth에서는 분석이 바이트코드와 함께 저장되지만 다른 클라이언트에서는 저장되지 않습니다. 컨트랙트 실행 전에 점프 타겟 분석을 제거하면 속도가 향상됩니다.

   • 분석을 제거하면 향후 최대 바이트코드 크기를 늘릴 수 있습니다.

   8. 더 쉬워진 정적 분석

   • 서브루틴은 보다 구조화된 제어 흐름을 강제하여 퍼지 테스트를 보다 효율적으로 만들고 선형 시간 내에 정적 분석을 가능하게 합니다.

   • 데이터와 코드가 분리되어 추론이 더 쉬워집니다.

   9. EOF 바이트코드를 더 빠른 바이트코드로 컴파일할 수 있습니다

   • EOF 바이트코드는 머신 코드로 컴파일할 수 있습니다.

   10. 미래 보장형 EVM

   • 바이트코드의 버전 관리와 구조는 확장성을 가능하게 합니다. 이는 특히 L2 및 표준화에 유용합니다.

   • 예시로는 새로운 헤더 섹션이 추가된 EIP-7701: EOF를 사용한 로컬 계정 추상화를 들 수 있습니다.

   11. 주소 공간 확장

   • 새로운 EXT*CALL 연산 코드는 주소 필드를 0으로 채우도록 요구하여 향후 주소 확장에 대비합니다. 이더넷이 주소 공간을 확장하기로 결정했을 때 EOF는 이미 이러한 변화에 대비하고 있었습니다.

   현재 EVM과의 통합

   개발자에게 중요한 문제는 변경 사항을 구현하는 데 필요한 노력, 테스트 비용, 이러한 옵코드 유지 관리 비용입니다. .

   새 옵코드는 레거시 옵코드와 충돌하지 않으며, EOF 유효성 검사는 사용되지 않는 옵코드를 건드리지 않습니다.

   EOF 인코딩 및 디코딩은 퍼지 테스트가 가능합니다. 유효성 검사는 새로운 기능이며 Revm에는 약 500줄의 코드가 있지만, 다루어야 할 에지 케이스가 많고 구현 전반에 걸쳐 올바르게 적용하는 데 집중해야 합니다.

   EOF 바이트코드의 캐리어로 사용할 트랜잭션을 생성하는 것은 EOFCREATE와 유사하지만 실행 전에 유효성 검사가 필요합니다. EXTDELEGATECALL (0xf9), EXTSTATICCALL (0xfb)

• 더 이상 사용되지 않는 CALL과 동일한 청사진을 가지고 있지만 gas_limit 및 메모리 출력 필드가 제거되었습니다.

• RETURNDATALOAD가 도입되기 전(초기 포크)에는 CALL 옵코드를 실행하기 전에 CALL 옵코드의 메모리 출력을 설정해야 했습니다. 이로 인해 동적 출력이 허용되지 않았습니다.

2. EOFCREATE 및 RETURNCONTRACT

• EOF에 새로 추가되었으며 특별한 처리가 필요합니다.

3. EXCHANGE (0xe8), SWAPN (0xe7), DUPN (0xe6), DATACOPY (0xd3), DATASIZE (0xd2), DATALOADN. (0xd1), DATALOAD (0xd0), RJUMP (0xe0), RJUMPI (0xe1), RJUMPV (0xe2), RETURNDATALOAD

• 로직은 간단하며, 대부분 10~20줄의 코드만 있으면 구현할 수 있습니다. 다루어야 할 엣지 케이스가 많지 않습니다.

4. CALLF(0xe3), RETF(0xe4), JUMPF(0xe5)

• 서브루틴 스택과 스택 유효성 검사가 필요하며 약 20~30줄의 복잡한 코드가 필요합니다.

• 개발자에게 약 2~3개월이 소요됩니다. 이미 테스트가 시작되었습니다. 현재 약 2000건의 수기 검증 테스트가 진행 중이며 상태 테스트 작업이 진행 중입니다.

변경 사항은 EVM을 중심으로 이루어지므로 나머지 클라이언트와의 통합은 클라이언트의 아키텍처와 바이트코드가 저장되는 위치에 따라 달라집니다.

EXTCODESIZE와 EXTCODEHASH는 계정이 EOF인지 확인하고 미리 정의된 값(0xEF00 크기 및 해시)을 반환해야 하므로 클라이언트 측 통합이 약간 변경될 수 있습니다. 한 가지 아이디어는 일반 계정 테이블에 is_eof 플래그를 저장하여 EXTCODE 유형 옵코드를 호출할 때 바이트코드 로딩을 건너뛰는 것입니다.

L2에 미치는 영향

큰 문제는 왜 L2에서 이러한 변경 사항을 구현하지 않느냐는 것입니다. 이더넷 L1의 EVM 개선을 중단해야 할까요?

현실은 L2가 준비가 되어 있지 않을 뿐만 아니라 이러한 혁신을 통합하는 데 도움이 되는 플랫폼이 없다는 것입니다. 바이트코드 버전 제어는 L2가 사용할 수 있는 플랫폼을 구축하는 데 도움이 되고, 코드 가시성 제거는 확장성 문제를 완화하는 데 도움이 되며, 가스 변경은 ZK L2가 가스 폭탄을 위한 DDoS 벡터(예: zk의 해시는 매우 비싸다)를 제거하는 데 도움이 됩니다.

더 중요한 것은 EOF는 단순한 형식이 아니라 이를 사용하려면 언어(솔리디티/바이퍼/허프) 지원과 툴체인 지원이 필요하다는 점입니다. 이를 사용하려면 에코시스템이 필요하며, 이 포맷은 L2가 혁신할 수 있는 더 많은 안정성을 제공합니다.

단점: 레거시 바이트코드가 여전히 존재

이것은 일반적인 문제입니다. 레거시 바이트코드는 항상 존재할 것이며, 대안을 제공하지 않으면 문제가 발생할 수 있습니다. 바이트코드에 대한 대체 형식을 사용하면 향후 상태 만료가 발생하면 레거시 바이트코드를 전환하고 제거할 수 있습니다.

요약

EOF는 차세대 반짝이는 것이 아니라 초기 EVM 버전의 레거시 문제를 수정하는 유지 관리 EIP이며, 이러한 문제를 해결할 수 있는 다른 방법은 없습니다. 이는 EVM의 추가 개발과 미래 대비를 위해 필요합니다.