Tác giả: Dragan Rakita, Bản dịch mô hình: Shan Oppa, Golden Finance
EOF (Định dạng đối tượng EVM)
EOF (Định dạng đối tượng EVM) là một tập hợp các EIP nhỏ được thiết kế để cải thiện EVM. Nó giới thiệu một định dạng mã byte mới để chuẩn bị EVM cho tương lai.
Ưu điểm của EOF
Giá trị của EOF rất khó giải thích vì nó không phải là một điều duy nhất. Và lời giải thích trở nên phức tạp hơn bởi nhiều sự chậm trễ trong quá trình phân nhánh và sự phát triển của các phiên bản khác nhau trong nhiều năm phát triển và nghiên cứu.
Mục đích của bài viết này là tóm tắt những ưu điểm đó và giải thích chúng trong một câu:
Ưu điểm:< /h3>EOF cho phép thay đổi giá gas đối với các mã opcode< /p>
Loại bỏ khả năng quan sát khí
< ul class= " list-paddingleft-2">Điều này có nghĩa là loại bỏ mã hoạt động GAS và các hạn chế về gas trong CALL/DELEGATECALL/STATICCALL.
Cho phép L2 thay đổi khí dựa trên trường hợp sử dụng của nó
< /li> Giảm kích thước mã byte và giảm mức sử dụng gas
li>Dữ liệu ban đầu cho thấy việc giảm mã/kích thước mã khởi tạo và mức sử dụng gas:
< /li> Việc triển khai Uniswap-v3 giúp giảm mã khởi tạo và mã triển khai xuống 6,5%.
Việc triển khai UniswapV3Factory sử dụng ít gas hơn khoảng 14% và gọi runTest sử dụng ít gas hơn khoảng 9%.
Việc triển khai ENS DNSRegistrar giúp giảm khoảng 6% mã khởi tạo và khoảng 1,5% mã triển khai.
ENS gọi provenAndClaim: sử dụng ít gas hơn khoảng 10%.
Cho phép chuyển đổi và nâng cấp mã byte
li>Xóa khả năng quan sát mã có nghĩa là xóa các mã opPC, CREATE/CREATE2, EXTCODEHASH, EXTCODESIZE, EXTCODECOPY, CODESIZE và CODECOPY.
Nếu mã bị thay đổi, hợp đồng truyền thống sẽ không chạy.
Điều này sẽ cho phép chúng tôi thực hiện bất kỳ sửa đổi nào đối với mã byte EOF khi verkle được giới thiệu trong tương lai.
EOF cho phép mã hóa giá trị tức thời
< ul class=" list-paddingleft-2">Bật khả năng mã hóa SWAPN, DUPN và EXCHANGE.
Điều này mang lại cho Solidity nhiều tự do hơn về kích thước ngăn xếp và giải quyết vấn đề về độ sâu ngăn xếp quá mức trong Solidity.
Xóa phân tích mục tiêu nhảy đắt tiền
Trong Reth, kết quả phân tích được lưu cùng với mã byte, nhưng điều này không xảy ra với các ứng dụng khách khác. Loại bỏ phân tích mục tiêu nhảy trước khi thực hiện hợp đồng sẽ cải thiện tốc độ.
Với việc loại bỏ phân tích, chúng tôi có thể tăng kích thước mã byte tối đa trong tương lai.
Việc phân tích tĩnh trở nên dễ dàng hơn
< ul class =" list-paddingleft-2">Các chương trình con buộc một luồng điều khiển có cấu trúc chặt chẽ hơn, giúp việc kiểm tra fuzz hiệu quả hơn và cho phép phân tích tĩnh theo thời gian tuyến tính.
Dữ liệu và mã được tách biệt, giúp việc suy luận trở nên dễ dàng hơn.
Mã byte EOF có thể được biên dịch thành mã byte nhanh hơn p>
EVM phù hợp với tương lai
Việc lập phiên bản và cấu trúc của mã byte cho phép khả năng mở rộng của nó. Điều này đặc biệt hữu ích cho L2 và tiêu chuẩn hóa.
Một ví dụ là EIP-7701: trừu tượng hóa tài khoản cục bộ bằng EOF, thêm phần tiêu đề mới.
Phần mở rộng không gian địa chỉ
Tích hợp với EVM hiện tại
Một vấn đề quan trọng đối với các nhà phát triển là nỗ lực cần thiết để thực hiện các thay đổi, chi phí thử nghiệm và chi phí duy trì các mã hoạt động này.
Các opcode mới sẽ không xung đột với các opcode truyền thống và việc xác minh EOF sẽ không chạm đến các opcode không được dùng nữa.
Mã hóa và giải mã EOF có thể bị làm mờ. Xác thực là một điều mới và có khoảng 500 dòng mã trong Revm, nhưng có rất nhiều trường hợp đặc biệt cần đề cập và tập trung vào việc thực hiện đúng trong từng triển khai riêng lẻ.
Tạo một giao dịch được sử dụng làm vật mang cho mã byte EOF, tương tự như EOFCREATE nhưng yêu cầu xác minh trước khi thực hiện.
Hầu hết các opcode đều rất đơn giản:
EXTCALL (0xf8), EXTDELEGATECALL (0xf9), EXTSTATICCALL (0xfb)
Có cùng bản thiết kế với CALL không được dùng nữa, nhưng loại bỏ các trường đầu ra bộ nhớ và gas_limit.
Trước khi giới thiệu RETURNDATALOAD (trong một nhánh phân nhánh rất sớm), đầu ra bộ nhớ của opcode CALL phải được thực thi trước Thao tác CALL Đặt trước mã. Điều này không cho phép đầu ra động.
EOFCREATE và RETURNCONTRACT
TRAO ĐỔI (0xe8), SWAPN (0xe7), DUPN (0xe6), SAO CHÉP DỮ LIỆU (0xd3) , KÍCH THƯỚC DỮ LIỆU (0xd2), TẢI DỮ LIỆU (0xd1), TẢI DỮ LIỆU (0xd0), RJUMP (0xe0), RJUMPI (0xe1), RJUMPV (0xe2), TẢI DỮ LIỆU TRẢ LẠI
CALLF (0xe3), RETF (0xe4) và JUMPF (0xe5)
Yêu cầu con Sự phức tạp của việc xác minh ngăn xếp chương trình và ngăn xếp yêu cầu khoảng 20-30 dòng mã.
Nhà phát triển phải mất khoảng 2-3 tháng. Công việc thử nghiệm đã bắt đầu. Hiện có khoảng 2.000 bài kiểm tra xác minh viết tay và công việc kiểm tra trạng thái cũng đang được tiến hành.
Các thay đổi tập trung ở EVM, do đó việc tích hợp với phần còn lại của máy khách phụ thuộc vào kiến trúc của client và cách nó được lưu Vị trí của mã byte.
EXTCODESIZE và EXTCODEHASH cần biết tài khoản có phải là EOF hay không và trả về giá trị được xác định trước (kích thước và hàm băm 0xEF00), điều này có thể thay đổi một chút Cách tích hợp của khách hàng. Một ý tưởng là lưu cờ is_eof trong bảng tài khoản thông thường để bỏ qua việc tải mã byte khi bất kỳ mã opcode nào thuộc loại EXTCODE được gọi.
Tác động đến L2
Câu hỏi lớn là tại sao L2 không thực hiện những thay đổi này? Chúng ta có nên ngừng cải tiến EVM trên Ethereum L1 không?
Thực tế là L2 vẫn chưa sẵn sàng và không những vậy, họ còn chưa có nền tảng để giúp tích hợp những đổi mới này. Phiên bản mã byte giúp xây dựng nền tảng mà L2 có thể sử dụng, việc loại bỏ khả năng quan sát mã giúp giảm bớt các vấn đề về khả năng nâng cấp và các thay đổi về khí giúp ZK L2 loại bỏ vectơ DDoS cho bom khí (ví dụ: băm trong zk Giá trị rất đắt).
Quan trọng hơn, EOF không chỉ là một định dạng, nó còn yêu cầu hỗ trợ ngôn ngữ (Solidity/Vyper/Huff) và có thể sử dụng hỗ trợ chuỗi công cụ. Nó đòi hỏi một hệ sinh thái để sử dụng nó và định dạng này mang lại cho L2 sự ổn định hơn để đổi mới trên nó.
Nhược điểm: Mã byte truyền thống vẫn tồn tại
Đây là vấn đề thường gặp. Mã byte truyền thống vẫn còn tồn tại và nếu chúng tôi không cung cấp giải pháp thay thế, chúng tôi sẽ gặp rắc rối. Việc có các định dạng mã byte thay thế cho phép chúng tôi chuyển đổi và xóa mã byte cũ trong tương lai khi trạng thái hết hạn.
Tóm tắt
EOF không phải là thứ sáng bóng tiếp theo, nó là một bản sửa lỗi cho di sản của phiên bản EVM ban đầu Các vấn đề khi duy trì EIP, không có cách nào khác để giải quyết những vấn đề này ngoài việc phá hủy nó. Nó là cần thiết cho sự phát triển hơn nữa và chứng minh EVM trong tương lai.