Toàn văn đề xuất lớp thực thi L1 dài hạn của Vitalik: Thay thế EVM bằng RISC-V
Tuyển chọn TechFlowTuyển chọn TechFlow
Toàn văn đề xuất lớp thực thi L1 dài hạn của Vitalik: Thay thế EVM bằng RISC-V
Mục tiêu là nâng cao đáng kể hiệu suất và sự đơn giản ở tầng thực thi, đồng thời phá vỡ điểm nghẽn về khả năng mở rộng.
Chuyên sâu báo cáo Web3Nguồn: Vitalik Buterin
Biên dịch: KarenZ, Foresight News
Ngày 20 tháng 4, Vitalik Buterin đã đưa ra một đề xuất quan trọng về lớp thực thi L1 dài hạn của Ethereum trên nền tảng Ethereum Magicians. Ông đề xuất sử dụng kiến trúc RISC-V thay thế cho EVM (Ethereum Virtual Machine) hiện tại làm ngôn ngữ máy ảo để viết hợp đồng thông minh, nhằm nâng cao hiệu quả vận hành của lớp thực thi Ethereum, vượt qua một trong những điểm nghẽn mở rộng chính hiện nay, đồng thời đơn giản hóa đáng kể kiến trúc lớp thực thi.
Foresight News xin biên dịch toàn văn đề xuất này nhằm giúp bạn đọc hiểu rõ hơn về ý tưởng công nghệ này. Dưới đây là nội dung bản dịch nguyên bản:
Bài viết này trình bày một ý tưởng táo bạo về tương lai của lớp thực thi Ethereum, mức độ tham vọng không kém gì kế hoạch Beam Chain ở tầng đồng thuận. Đề xuất này hướng tới việc tăng mạnh hiệu suất của lớp thực thi Ethereum, giải quyết một trong các điểm nghẽn mở rộng chính và đơn giản hóa đáng kể lớp thực thi — thực tế có thể đây là con đường duy nhất đạt được mục tiêu này.
Ý tưởng cốt lõi: Thay thế EVM bằng RISC-V làm ngôn ngữ máy ảo để viết hợp đồng thông minh.
Lưu ý quan trọng:
-
Các khái niệm như hệ thống tài khoản, gọi chéo giữa các hợp đồng, lưu trữ... sẽ được giữ nguyên hoàn toàn. Những thiết kế trừu tượng này hoạt động tốt và nhà phát triển đã quen thuộc. Các opcode như SLOAD, SSTORE, BALANCE, CALL sẽ trở thành các system call của RISC-V.
-
Theo mô hình này, hợp đồng thông minh có thể được viết bằng Rust, tuy nhiên tôi dự đoán phần lớn nhà phát triển vẫn sẽ tiếp tục dùng Solidity (hoặc Vyper), các ngôn ngữ này sẽ hỗ trợ RISC-V như một backend mới. Bởi vì hợp đồng viết bằng Rust thực tế khó đọc hơn, trong khi Solidity và Vyper rõ ràng và dễ hiểu hơn. Trải nghiệm phát triển gần như không bị ảnh hưởng, thậm chí nhà phát triển có thể không nhận ra sự thay đổi.
-
Các hợp đồng EVM cũ sẽ tiếp tục chạy và tương thích hai chiều hoàn toàn với các hợp đồng RISC-V mới. Có nhiều cách triển khai điều này, sẽ được thảo luận chi tiết sau.
Nervos CKB VM đã đi tiên phong, về cơ bản chính là một triển khai RISC-V.
Tại sao nên làm điều này?
Trong ngắn hạn, các EIP sắp tới (như danh sách truy cập cấp khối, thực thi trì hoãn, lưu trữ lịch sử phân tán và EIP-4444) có thể giải quyết các điểm nghẽn mở rộng chính của L1 Ethereum. Trung hạn, vô trạng thái (statelessness) và ZK-EVM sẽ giải quyết thêm nhiều vấn đề. Về dài hạn, các yếu tố giới hạn chính đối với khả năng mở rộng L1 Ethereum sẽ là:
-
Độ ổn định của giao thức lấy mẫu tính sẵn sàng dữ liệu và lưu trữ lịch sử
-
Nhu cầu duy trì tính cạnh tranh trong sản xuất khối
-
Khả năng chứng minh của ZK-EVM
Tôi sẽ lập luận rằng việc thay thế ZK-EVM bằng RISC-V có thể giải quyết các điểm nghẽn then chốt trong (2) và (3).
Bảng dưới đây cho thấy số chu kỳ cần thiết để proofer ZK-EVM Succinct chứng minh từng bước thực thi EVM:
Ghi chú biểu đồ: Bốn bước tốn thời gian chính là deserialize_inputs, initialize_witness_db, state_root_computation và block_execution
Trong đó, initialize_witness_db và state_root_computation liên quan đến cây trạng thái, deserialize_inputs liên quan đến quá trình chuyển đổi dữ liệu khối và bằng chứng sang biểu diễn nội bộ — thực tế hơn 50% tỷ lệ thuận với kích thước bằng chứng.
Bằng cách thay thế cây Merkle Patricia 16-phân keccak hiện tại bằng cây nhị phân sử dụng hàm băm dễ chứng minh, các thành phần này có thể được tối ưu hóa mạnh mẽ. Nếu dùng Poseidon, chúng ta có thể chứng minh 2 triệu giá trị băm mỗi giây trên laptop (so với khoảng 15.000 hash/giây đối với keccak). Ngoài Poseidon còn nhiều lựa chọn khác. Nhìn chung, các thành phần này còn dư địa tối ưu rất lớn. Hơn nữa, chúng ta có thể loại bỏ accrue_logs_bloom bằng cách loại bỏ bloom.
Phần block_execution còn lại chiếm khoảng một nửa tổng số chu kỳ chứng minh hiện tại. Để đạt được hiệu quả chứng minh tổng thể tăng 100 lần, hiệu quả chứng minh EVM cần tăng ít nhất 50 lần. Một giải pháp là tạo triển khai chứng minh hiệu quả hơn cho EVM; phương án khác là nhận ra rằng các proofer ZK-EVM hiện tại thực tế đang chứng minh bằng cách biên dịch EVM sang RISC-V — vậy tại sao không cho phép nhà phát triển hợp đồng trực tiếp truy cập vào máy ảo RISC-V đó?
Một số dữ liệu cho thấy hiệu quả có thể tăng hơn 100 lần trong một số trường hợp cụ thể:
Trong thực tế, thời gian chứng minh còn lại có thể chủ yếu do các thao tác precompile hiện tại chiếm giữ. Nếu dùng RISC-V làm máy ảo chính, biểu Gas sẽ phản ánh đúng thời gian chứng minh thực tế, áp lực kinh tế sẽ thúc đẩy nhà phát triển giảm dùng các precompile tốn kém. Dù vậy, lợi ích có thể không nổi bật như vậy, nhưng chúng ta có lý do đầy đủ để tin rằng lợi ích sẽ rất đáng kể.
(Lưu ý rằng trong thực thi EVM thông thường, tỷ lệ thời gian giữa "các thao tác EVM" và "các thao tác khác" cũng gần 50/50, do đó ta có thể trực giác rằng việc loại bỏ EVM như một "lớp trung gian" sẽ mang lại lợi ích tương tự)
Chi tiết triển khai
Đề xuất này có thể được thực hiện theo nhiều cách. Phương án ít phá vỡ nhất là hỗ trợ song song cả hai máy ảo, cho phép hợp đồng chọn viết bằng một trong hai. Cả hai loại hợp đồng đều có thể truy cập cùng chức năng: lưu trữ bền vững (SLOAD/SSTORE), khả năng nắm giữ số dư ETH, khởi tạo/nhận lời gọi, v.v. Hợp đồng EVM và RISC-V có thể gọi lẫn nhau — từ góc nhìn RISC-V, gọi một hợp đồng EVM giống như thực hiện một system call với tham số đặc biệt; còn một hợp đồng EVM nhận tin nhắn sẽ diễn giải nó như một lệnh CALL.
Một cách tiếp cận triệt để hơn về mặt giao thức là chuyển đổi các hợp đồng EVM hiện tại thành việc gọi một hợp đồng thông dịch EVM viết bằng RISC-V để chạy mã EVM hiện tại. Nghĩa là, nếu một hợp đồng EVM có mã C, và trình thông dịch EVM nằm ở địa chỉ X, thì hợp đồng đó sẽ được thay thế bằng logic tầng trên: khi bị gọi từ bên ngoài với tham số D, nó sẽ gọi X với (C, D), đợi kết quả trả về rồi chuyển tiếp. Nếu chính trình thông dịch EVM gọi lại hợp đồng này yêu cầu thực hiện CALL hoặc SLOAD/SSTORE, thì hợp đồng sẽ thực hiện các thao tác đó.
Phương án trung gian là dùng cách thứ hai, nhưng giao thức hỗ trợ rõ ràng khái niệm "trình thông dịch máy ảo", yêu cầu logic của nó phải viết bằng RISC-V. EVM sẽ là ví dụ đầu tiên, trong tương lai có thể hỗ trợ thêm các ngôn ngữ khác (Move có thể là ứng cử viên).
Ưu điểm cốt lõi của phương án thứ hai và thứ ba là chúng có thể đơn giản hóa mạnh mẽ đặc tả lớp thực thi. Khi mà ngay cả việc đơn giản hóa dần như loại bỏ SELFDESTRUCT cũng gặp khó khăn, cách tiếp cận này có thể là con đường khả thi duy nhất. Tinygrad tuân thủ quy tắc cứng nhắc "không quá 10.000 dòng mã", trong khi blockchain lý tưởng tối ưu lẽ ra phải dễ dàng đáp ứng và còn tinh gọn hơn nữa. Kế hoạch Beam Chain hứa hẹn đơn giản hóa mạnh mẽ tầng đồng thuận Ethereum, và nếu muốn lớp thực thi đạt được bước tiến tương tự, một thay đổi táo bạo như thế này có thể là con đường duy nhất khả thi.
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
@VitalikButerin
