Đề xuất lớp thực thi L1 dài hạn của Vitalik: Thay thế EVM bằng RISC-V

Tiêu đề gốc: Đề xuất lớp thực thi L1 dài hạn: thay thế EVM bằng RISC-V

Nguồn gốc: Vitalik Buterin

Bản dịch gốc: KarenZ, Foresight News

Vào 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ế EVM (Máy ảo Ethereum) hiện tại làm ngôn ngữ máy ảo để viết hợp đồng thông minh, nhằm mục đích cải thiện cơ bản hiệu quả hoạt động của lớp thực thi Ethereum, phá vỡ một trong những điểm nghẽn mở rộng lớn hiện nay và đơn giản hóa đáng kể tính đơn giản của lớp thực thi.

Foresight News đã biên soạn toàn văn đề xuất để giúp độc giả hiểu được khái niệm kỹ thuật này. Sau đây là bản tổng hợp đề xuất ban đầu:

Bài báo này đề xuất một ý tưởng cấp tiến cho tương lai của lớp thực thi của Ethereum, không kém phần tham vọng so với kế hoạch của Beam Chain cho lớp đồng thuận. Đề xuất này nhằm mục đích cải thiện đáng kể hiệu quả của lớp thực thi của Ethereum, giải quyết một trong những điểm nghẽn chính về khả năng mở rộng và đơn giản hóa đáng kể lớp thực thi — trên thực tế, đây có thể là cách duy nhất để đạt được mục tiêu này.

Khái niệm cốt lõi: Sử dụng RISC-V để thay thế EVM 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, cuộc gọi hợp đồng chéo và lưu trữ sẽ được giữ nguyên hoàn toàn. Những sự trừu tượng này hoạt động tốt và các nhà phát triển đã quen với chúng. Các mã lệnh như SLOAD, SSTORE, BALANCE, CALL, v.v. sẽ được chuyển đổi thành các lệnh gọi hệ thống RISC-V.

· Ở chế độ này, hợp đồng thông minh có thể được viết bằng Rust, nhưng tôi hy vọng hầu hết các nhà phát triển sẽ tiếp tục viết hợp đồng bằng Solidity (hoặc Vyper), vốn sẽ được chuyển thể thành RISC-V làm nền tảng mới. Bởi vì các hợp đồng thông minh được viết bằng Rust thực sự khó đọc hơn, trong khi Solidity và Vyper rõ ràng và dễ đọc hơn. Trải nghiệm phát triển có thể hầu như không bị ảnh hưởng và các nhà phát triển thậm chí có thể không nhận thấy sự thay đổi.

· Các hợp đồng EVM cũ sẽ tiếp tục chạy và hoàn toàn tương thích theo cả hai chiều với các hợp đồng RISC-V mới. Có một số cách để đạt được điều này, chúng tôi sẽ thảo luận chi tiết ở phần sau của bài viết này.

Nervos CKB VM đã tạo ra tiền lệ và về cơ bản là một triển khai RISC-V.

Tại sao phải làm như vậ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 chậm trễ, 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 Ethereum L1. Trong trung hạn, nhiều vấn đề hơn sẽ được giải quyết thông qua tình trạng vô quốc tịch và ZK-EVM. Về lâu dài, các yếu tố hạn chế chính đối với việc mở rộng Ethereum L1 sẽ trở thành:

1. Tính ổn định của dữ liệu khả dụng lấy mẫu và giao thức lưu trữ lịch sử

2. Nhu cầu duy trì thị trường sản xuất khối cạnh tranh

3. 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ác nút thắt chính trong (2) và (3).

Bảng sau đây hiển thị số chu kỳ cần thiết cho mỗi bước của lớp thực thi EVM bằng chứng Succinct ZK-EVM:

Mô tả 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 số đó, initialize_witness_db và state_root_computation liên quan đến cây trạng thái và deserialize_inputs liên quan đến quá trình chuyển đổi dữ liệu khối và chứng kiến thành các biểu diễn nội bộ - trên thực tế, hơn 50% tỷ lệ thuận với kích thước của dữ liệu chứng kiến.

Những phần này có thể được tối ưu hóa đáng kể bằng cách thay thế cây Merkle patricia 16-ary keccak hiện tại bằng một cây nhị phân sử dụng hàm băm dễ chứng minh. Khi sử dụng Poseidon, chúng ta có thể chứng minh 2 triệu băm mỗi giây trên máy tính xách tay (so với khoảng 15.000 băm/giây đối với keccak). Ngoài Poseidon còn có nhiều lựa chọn khác. Nhìn chung, có rất nhiều chỗ để tối ưu hóa các thành phần này. Ngoài ra, chúng ta có thể loại bỏ accrue_logs_bloom bằng cách xóa bloom.

Phần block_execution còn lại chiếm khoảng một nửa số chu kỳ chứng minh hiện tại. Để đạt được hiệu quả kiểm tra tổng thể được cải thiện gấp 100 lần, hiệu quả kiểm tra EVM cần phải tăng ít nhất 50 lần. Một giải pháp là tạo ra một triển khai chứng minh hiệu quả hơn cho EVM, một giải pháp khác là lưu ý rằng trình chứng minh ZK-EVM hiện tại thực sự thực hiện chứng minh bằng cách biên dịch EVM sang RISC-V, cung cấp cho các nhà phát triển hợp đồng thông minh quyền truy cập trực tiếp vào máy ảo RISC-V.

Một số dữ liệu cho thấy hiệu quả cải thiện có thể vượt quá 100 lần trong một số trường hợp nhất định:

Trong các ứng dụng thực tế, thời gian còn lại của trình chứng minh có thể chủ yếu dành cho hoạt động biên dịch trước hiện tại. Nếu RISC-V được sử dụng làm máy ảo chính, lịch trình Gas sẽ phản ánh thời gian kiểm tra thực tế và áp lực kinh tế sẽ thúc đẩy các nhà phát triển giảm việc sử dụng biên dịch trước có chi phí cao. Ngay cả khi đó, lợi nhuận thu được cũng không quá lớn, nhưng có lý do chính đáng để tin rằng chúng sẽ rất đáng kể.

(Cần lưu ý rằng thời gian dành cho "hoạt động EVM" và "hoạt động khác" trong quá trình thực thi EVM thông thường cũng gần bằng 50/50, do đó, theo trực giác, chúng tôi cho rằng việc loại bỏ EVM khỏi "lớp trung gian" sẽ mang lại lợi ích đáng kể như nhau)

Chi tiết triển khai

Đề xuất này có thể được triển khai theo nhiều cách. Giải pháp ít gây gián đoạn nhất là hỗ trợ cả hai máy ảo cùng một lúc, cho phép viết hợp đồng trên một trong hai máy. Cả hai loại hợp đồng đều có quyền truy cập vào cùng một chức năng: lưu trữ liên tục (SLOAD/SSTORE), khả năng giữ số dư ETH, thực hiện/nhận lệnh gọi, v.v. Hợp đồng EVM và RISC-V có thể gọi cho nhau - theo quan điểm của RISC-V, việc gọi hợp đồng EVM tương đương với việc thực hiện lệnh gọi hệ thống với các tham số đặc biệt; và hợp đồng EVM nhận được tin nhắn sẽ hiểu đó là một CALL.

Một cách tiếp cận triệt để hơn theo quan điểm giao thức là chuyển đổi các hợp đồng EVM hiện có để gọi một hợp đồng thông dịch EVM được viết bằng RISC-V, chạy mã EVM hiện có của hợp đồng đó. Nghĩa là, nếu hợp đồng EVM có mã C và trình thông dịch EVM ở địa chỉ X, thì hợp đồng sẽ được thay thế bằng logic cấp cao nhất, khi được gọi từ bên ngoài với đối số gọi D, sẽ gọi X và truyền vào (C, D), sau đó đợi giá trị trả về và chuyển tiếp giá trị đó. Nếu trình thông dịch EVM tự gọi hợp đồng, yêu cầu chạy CALL hoặc SLOAD/SSTORE, thì hợp đồng sẽ thực hiện các hoạt động đó.

Giải pháp thỏa hiệp là áp dụng phương án thứ hai, nhưng hỗ trợ rõ ràng khái niệm "trình thông dịch máy ảo" thông qua giao thức và yêu cầu logic của nó phải được viết bằng RISC-V. EVM sẽ là bản triển khai đầu tiên, các ngôn ngữ khác sẽ được hỗ trợ trong tương lai (Move có thể là một ứng cử viên).

Ưu điểm cốt lõi của tùy chọn thứ hai và thứ ba là chúng có thể đơn giản hóa đáng kể các thông số kỹ thuật của lớp thực thi. Do ngay cả việc đơn giản hóa gia tăng, chẳng hạn như loại bỏ SELFDESTRUCT, cũng khó khăn, nên cách tiếp cận này có thể là con đường đơn giản hóa khả thi duy nhất. Tinygrad tuân theo quy tắc cứng nhắc là "không quá 10.000 dòng mã" và lớp blockchain cơ bản tối ưu phải có thể dễ dàng đáp ứng được hạn chế này và hợp lý hóa hơn nữa. Dự án Beam Chain hứa hẹn sẽ đơn giản hóa đáng kể lớp đồng thuận của Ethereum và sự thay đổi cơ bản này có thể là con đường khả thi duy nhất để đạt được những cải tiến tương tự ở lớp thực thi.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia