Paradigm: Ethereum sau nâng cấp Cancun là gì?
Tuyển chọn TechFlowTuyển chọn TechFlow
Paradigm: Ethereum sau nâng cấp Cancun là gì?
Việc tăng giới hạn gas L1 thực tế sẽ không mang lại hiệu quả lớn do nhu cầu bị kích thích.
Chuyên sâu báo cáo Web3Tác giả: Georgios Konstantopoulos
Biên dịch: TechFlow
Dẫn luận
Mục đích của bài viết này là phác thảo quan điểm hiện tại của nhóm Reth thuộc Paradigm về các EIP (Đề xuất Cải tiến Ethereum) nên được đưa vào hard fork Prague (hard fork EL tiếp theo sau hội nghị Cancun), cũng như kế hoạch "phát triển cốt lõi EL" cho năm 2024. Các quan điểm trong bài chỉ đại diện cho nhóm Reth và không nhất thiết phản ánh quan điểm của toàn bộ đội ngũ Paradigm.
Tóm tắt
Chúng tôi cho rằng hard fork Prague có thể được triển khai trên mạng thử nghiệm Ethereum vào quý III năm 2024 và trên mạng chính vào cuối năm. Hard fork này nên bao gồm:
-
Bất kỳ EIP nào liên quan đến staking, ví dụ như EIP-7002 hỗ trợ re-staking và các pool staking không cần tin cậy.
-
Các thay đổi độc lập đối với EVM.
-
Chúng tôi sẵn sàng hợp tác với bất kỳ đội ngũ nào để điều tra sâu hơn các vấn đề phức tạp cho hard fork Prague hoặc các hard fork EL tương lai, đồng thời sẵn lòng cung cấp hướng dẫn hoặc hỗ trợ điều chỉnh kho mã nguồn Reth.
Những việc nên làm:
-
Chúng tôi cho rằng các EIP sau đây cần được ưu tiên: 7002, 6110, 2537.
-
Chúng tôi ủng hộ đặc tả rõ ràng về EOF (EVM Object Format), nhưng mong muốn phạm vi được xác định sớm và tạo ra một meta-EIP dành riêng cho phạm vi đó.
-
Chúng tôi sẵn sàng tăng giới hạn tối đa Blob Gas của EIP-4844. Chúng tôi chưa có quan điểm cụ thể về con số phù hợp, nhưng mời các chuyên gia phân tích dữ liệu hợp tác cùng chúng tôi nghiên cứu chủ đề này.
-
Chúng tôi sẵn sàng triển khai phiên bản EIP-7547: danh sách bao gồm (inclusion list), nhằm giúp chống kiểm duyệt ở cấp cơ sở.
Những việc không nên làm:
-
Chúng tôi không ủng hộ việc đưa Verkle Tries vào hard fork Prague, nhưng ủng hộ các đội phát triển client bắt đầu nỗ lực triển khai từ quý II năm 2024 và cam kết phát hành nó trong hard fork Osaka vào giữa/đầu cuối năm 2025.
-
Chúng tôi cho rằng không nên tăng giới hạn Gas thực thi L1 hay kích thước hợp đồng, nhưng mời các chuyên gia phân tích dữ liệu hợp tác cùng chúng tôi điều tra tác động lên mạng lưới. Chúng tôi sẵn sàng xem xét lại lập trường dựa trên kết quả thử nghiệm trước đây (cho thấy nút Reth có thể chịu tải khi tải trọng tăng).
-
Chúng tôi cho rằng các EIP về ví/tài khoản trừu tượng cần thêm thử nghiệm thực tế để hiểu rõ hơn về sự đánh đổi giữa chúng. Nếu các EIP này không loại trừ nhau, chúng tôi sẽ sẵn sàng triển khai nhiều EIP liên quan đến AA trong tương lai.
-
Nếu cộng đồng chấp nhận lời đồn về lối thoát hậu môn NSA (NSA backdoor), chúng tôi có thể đưa ra quyết định về EIP-7212 (secp256r1).
-
Các chủ đề lộ trình khác: Chúng tôi không có ý kiến trực tiếp về các EIP CL hay ghép nối hard fork CL/EL, nhưng EIP 7549 và 7251 trông rất hứa hẹn. Chúng tôi cũng sẵn sàng đóng góp từ phía EL cho công việc PeerDAS nếu có thể. Hiện tại, chúng tôi muốn tránh việc đưa vào gốc SSZ (EIP 6404, 6465, 6466). Cuối cùng, chúng tôi lưu ý rằng có cơ hội để xây dựng giải pháp lưu trữ dữ liệu dài hạn cho blob hết hạn, lịch sử và trạng thái, vì cả EIP-4844 lẫn EIP-4444 đều chưa quy định điều này, và vẫn chưa rõ Ethereum có muốn cung cấp giải pháp như vậy hay không.
Sau đây là phần giới thiệu chi tiết đầy đủ.
Những việc nên làm:
Tóm lại, chúng tôi ủng hộ:
-
Tiếp tục thu hẹp khoảng cách giữa CL và EL
-
Các sửa đổi EVM có thể được thực hiện độc lập bởi một người, cho phép kiểm thử song song và độc lập.
EIP-7002
EIP này cho phép hợp đồng thông minh ở phía EL điều khiển một hoặc nhiều validator ở phía CL, qua đó mở khóa khả năng re-staking và các pool staking không cần tin cậy. Theo quan điểm của chúng tôi, đây là một EIP dễ dàng triển khai, ít tốn kém, ít rủi ro, vì nó ít nhất sẽ giúp các pool staking hiện tại loại bỏ một lớp trung tâm hóa khỏi hợp đồng rút tiền.
Việc đưa precompile có trạng thái vào EVM là một dạng trừu tượng mới mà chúng ta cần xử lý trong triển khai EVM, nhưng ngoài điều đó ra, chúng tôi cho rằng đây là một EIP có thể triển khai trực tiếp.
EIP-6110
EIP này đưa việc gửi tiền (deposit) vào trạng thái EL, đơn giản hóa quản lý trạng thái cần thiết trên CL. Về cơ bản, nó tương tự như việc theo dõi lệnh rút tiền trên CL, do đó tổng thể chúng tôi cho rằng đây cũng là một EIP dễ và độc lập để triển khai.
EIP-2537
Hiện đã có nhiều triển khai BLS12-381, và đường cong này được dùng phổ biến trong nhiều SNARKs, thuật toán chữ ký BLS và cả trong EIP-4844. Chúng tôi cho rằng độ phức tạp triển khai thấp, vì nó chỉ đơn thuần là công bố các thuật toán xác minh của đường cong thông qua giao diện precompile. Chúng tôi cũng có thể cần một giao diện hash cho precompile đường cong BLS12-381.
EOF
Tóm lại: Ủng hộ một phiên bản được định nghĩa rõ ràng mà Solidity và Vyper sẽ áp dụng. Việc định dạng mã và điều chỉnh xác thực sẽ giúp việc phân tích dễ dàng hơn – điều này là chắc chắn. Ngoài ra, chúng tôi đề nghị cân nhắc thận trọng. Chúng tôi đề xuất áp dụng các EIP sau đây, nhưng cũng mở cửa cho việc lược bỏ thêm.
Ưu điểm:
-
Chỉ liên quan đến thay đổi EVM, có thể kiểm thử qua ethereum/tests và được một người triển khai
-
Là những thay đổi EVM mà Vyper và Solidity mong muốn
-
Giúp cải thiện hiệu suất và tăng giới hạn kích thước hợp đồng
-
Loại bỏ nhu cầu EVM phân tích bytecode lúc chạy, vốn có thể chiếm tới 50% thời gian (không tính cache) và tăng theo kích thước hợp đồng
-
Hỗ trợ tải mã từng phần, giúp thực thi các hợp đồng thông minh lớn hơn
-
Trải nghiệm phát triển: Cho phép khắc phục lỗi “stack quá sâu” nhờ dupN/swapN và các công cụ cải tiến khác
-
Hướng tới tương lai: Có thể an toàn đưa chức năng mới vào L2, và các công cụ biết rõ cái gì là tương thích
Nhược điểm:
-
Phạm vi rộng và mục tiêu thay đổi liên tục
-
Thiếu người thúc đẩy mạnh mẽ để đưa nó vào
-
Vẫn phải hỗ trợ mã cũ (legacy code)
-
Sự phân mảnh tạm thời giữa mainnet Ethereum và các chuỗi EVM khác trước khi áp dụng
Chúng tôi cho rằng nên triển khai các chức năng EOF sau đây vào năm 2024. Chúng tôi đề nghị xác định phạm vi càng sớm càng tốt và cam kết thực hiện. Những nội dung khác nên được xem xét triển khai sau. Gợi ý của chúng tôi bao gồm:
-
EIP-3540: EOF - Định dạng Đối tượng EVM v1: Giới thiệu container mã và dữ liệu, thêm cấu trúc và kiểm soát phiên bản cho bytecode Ethereum.
-
EIP-3670: EOF - Xác thực mã: Từ chối triển khai bất kỳ hợp đồng nào không tuân theo định dạng EOF. Triển khai mã có cấu trúc hơn và vô hiệu hóa các lệnh không hợp lệ và chưa được định nghĩa.
-
EIP-663: Các lệnh SWAP và DUP không giới hạn: Giải quyết vấn đề “stack quá sâu” trong Solidity, có giá trị ngay lập tức; tuy nhiên việc phân tích JUMPDEST có thể gây tác dụng phụ. Điều này rất hấp dẫn với các ngôn ngữ EVM.
-
EIP-4200: EOF - Nhảy tương đối tĩnh: Phân tích tĩnh tốt hơn, không có nhảy không xác định. Nhảy tương đối giúp tái sử dụng mã tốt hơn.
-
EIP-4750: EOF - Hàm: Giải quyết vấn đề tiểu chương trình khi dùng nhảy tĩnh thay vì nhảy động. Ngoài ra, nó còn cho phép tải mã từng phần, phối hợp tốt với Verkle và tăng giới hạn kích thước hợp đồng.
-
EIP-5450: EOF - Xác thực ngăn xếp: Xác minh yêu cầu mã và ngăn xếp. Loại bỏ mọi kiểm tra tràn/xảy ngăn xếp lúc chạy đối với tất cả các lệnh ngoại trừ CALLF (EIP-4750).
-
EIP-7480: EOF - Lệnh truy cập phần dữ liệu: Cho phép truy cập phần dữ liệu của bytecode.
-
EIP-7069: Lệnh CALL được cải tiến: Cho phép loại bỏ khả năng quan sát gas từ CALL, giúp việc định giá lại gas dễ dàng hơn trong tương lai. Mặc dù độc lập với EOF, chúng tôi cho rằng đây là cơ hội tốt để đưa vào.
Chúng tôi chưa chắc chắn về EIP-6206: EOF - JUMPF và các hàm không trả về. Mặc dù nó cho phép tối ưu hóa gọi đuôi (tail-call optimization) trong các hàm EOF, nhưng chúng tôi vẫn cần thấy phân tích ngôn ngữ về tính hữu ích của nó. Nếu không có những điều đó, chúng tôi cho rằng có thể loại nó khỏi phạm vi và đưa vào các bản cập nhật EOF sau này.
Chúng tôi ước tính khối lượng công việc trên đây tương đương một người toàn thời gian làm trong 1-2 tháng. Nếu điều đó giúp duy trì đà phát triển, chúng tôi sẵn sàng thu hẹp thêm phạm vi trên.
Ghi chú về bytecode cũ:
-
Mặc dù chúng ta có thể cấm bytecode cũ/không phải EOF mới, nhưng không thể loại bỏ bytecode cũ đang tồn tại, thực chất coi như “v0” của EOF. Bytecode cũ vẫn cần phân tích JUMPDEST sau EOF, và vẫn cần mã xử lý đặc biệt để phân đoạn vào Verkle Tries.
-
Theo chúng tôi biết, hiện không có phương pháp xác minh nào để chuyển bytecode không phải EOF sang EOF mà không cần mã nguồn, nhưng chúng tôi sẵn sàng khám phá các cơ chế hỗ trợ việc chuyển đổi này.
-
Ngoài ra, chúng tôi cũng sẵn sàng xem xét phương pháp hết hạn buộc di dời trạng thái sang EOF.
Tăng số lượng Blob của EIP-4844
Chúng tôi mở cửa với việc sửa đổi này, theo ngữ cảnh EIP-4844, điều này tương đương với việc tăng MAX_BLOB_GAS_PER_BLOCK và TARGET_BLOB_GAS_PER_BLOCK:
-
TARGET_BLOB_GAS_PER_BLOCK và MAX_BLOB_GAS_PER_BLOCK hiện đặt mục tiêu lần lượt là 3 blob mỗi khối (0,375 MB) và tối đa 6 blob (0,75 MB). Những giới hạn ban đầu nhỏ này nhằm giảm thiểu áp lực của EIP này lên mạng, và dự kiến sẽ được tăng dần trong các nâng cấp tương lai khi mạng chứng minh được độ ổn định dưới khối lớn hơn.
-
Thực tế đây là một thay đổi mã nhỏ, chúng tôi cần điều tra ảnh hưởng thực tế của nó lên txpool, nhưng nghĩ rằng có thể tái sử dụng hạ tầng kiểm thử tải của EIP-4844 cho việc này. Có thể CL sẽ khó lan truyền nhiều blob hơn, chúng tôi lắng nghe ý kiến từ các đội CL.
Những việc không nên làm
Verkle Tries
Tóm lại, chúng tôi không nhìn thấy con đường triển khai Verkle tries vào cuối năm 2024/đầu 2025. Chúng tôi đề nghị các đội ngũ phân bổ nguồn lực từ quý II năm 2024 và cam kết triển khai trong hard fork Osaka vào quý II–III năm 2025.
Ưu điểm:
-
Cho phép light client rẻ hơn nhờ bằng chứng lưu trữ nhỏ hơn.
-
Cho phép thực thi vô trạng thái bằng cách đưa đọc trạng thái trước vào tiêu đề khối, đồng thời cải thiện hiệu suất nhờ truy cập trạng thái tĩnh.
-
Tăng giới hạn kích thước hợp đồng bằng cách chia nhỏ bytecode và bật tải mã từng phần.
-
Làm cho việc hết hạn trạng thái trở nên dễ chấp nhận hơn vì chi phí khôi phục trạng thái thấp hơn.
Nhược điểm:
-
Ảnh hưởng của thay đổi và khối lượng tích hợp, triển khai, kiểm thử lớn.
-
Thay đổi cách tính gas: Verkle Tries đưa kích thước bằng chứng vào hàm tính gas. Chúng tôi lo ngại rằng việc định giá lưu trữ chưa được nghiên cứu kỹ (ví dụ: chi phí của các tác nhân tiêu tốn gas hàng đầu sau Verkle sẽ là bao nhiêu?).
-
Tích hợp ứng dụng: Các ứng dụng có bộ xác minh MPT nên xử lý thế nào trong thời gian chuyển đổi Overlay? eth_getProof nên hoạt động ra sao?
Mặc dù hiểu được lợi ích của Verkle Tries, chúng tôi cho rằng cần suy xét thêm về việc các công cụ/hợp đồng bên thứ ba cần điều chỉnh thế nào, cũng như ảnh hưởng của quá trình chuyển đổi đến các giải pháp Layer 2. Ban đầu, chúng tôi nghi ngờ về chiến lược di dời vì nó yêu cầu cập nhật cây Verkle khi đọc trạng thái từ MPT hiện tại, nhưng giờ dường như tình hình đã thay đổi. Vì vậy, chúng tôi ủng hộ phương pháp cây phủ (overlay tree) như một lộ trình di dời khả thi.
Tài liệu về chiến lược di dời cây Verkle nói chung đã lỗi thời, phần lớn tài nguyên vẫn khẳng định rằng cây Verkle nên được cập nhật khi đọc trạng thái từ MPT, mặc dù thực tế không còn như vậy. Chúng tôi mong muốn thấy các tài liệu chuyển tiếp then chốt được cập nhật theo phương pháp mới nhất, ví dụ như tài liệu tuyệt vời này. Chúng tôi cũng mong muốn thấy một bản nháp EIP về chiến lược di dời.
Do đó, chúng tôi vẫn ủng hộ việc ra mắt vào năm 2025, nhưng không cho rằng có khả năng triển khai hệ thống này trong hard fork Prague.
Giới hạn Gas L1
Chúng tôi cho rằng việc tăng giới hạn gas L1 sẽ không mang lại hiệu quả lớn do nhu cầu phát sinh. Chúng tôi cũng cho rằng hầu hết các client có thể xử lý mức tải trung bình tăng lên, nhưng muốn thận trọng với các trường hợp xấu nhất, do đó hiện tại chúng tôi chưa thể đề xuất tăng giới hạn gas L1. Chúng tôi cho rằng việc tăng giới hạn blob gas trong ngắn hạn là một giải pháp hứa hẹn hơn.
Chúng tôi mời mọi người hợp tác cùng chúng tôi nghiên cứu lĩnh vực này, thường xoay quanh việc phá vỡ việc đo lường tài nguyên trong EVM. Bài báo Broken Metre là một điểm khởi đầu tốt cho hướng nghiên cứu này.
Tài khoản trừu tượng
Chúng tôi sẵn sàng đưa vào một hoặc nhiều EIP (hoặc ERC) này, nhưng lý tưởng nhất là muốn thấy thêm so sánh về trải nghiệm người dùng và nhà phát triển của từng đề xuất, để hiểu rõ hơn về không gian đánh đổi và khối lượng công việc tích hợp công cụ. Chúng tôi đang theo dõi các EIP/ERC sau đây, nhưng cũng hoan nghênh đề xuất thêm từ cộng đồng:
Cần lưu ý rằng, trong các nội dung trên, “tài khoản trừu tượng” ám chỉ “trừu tượng hóa hàm xác thực”, mục tiêu chính là cho phép luân chuyển khóa, biến multisig thành công nghệ hạng nhất, và cung cấp đường đi kháng lượng tử tự động — chỉ áp dụng cho 4337 và 7560, trong khi các đề xuất khác chia thành hai nhóm: tài trợ gas và thao tác theo lô.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
Paradigm
