Toàn văn đề xuất lớp điều hành L1 dài hạn của Vitalik: thay thế EVM bằng RISC-V

Nguồn: Vitalik Buterin

Biên soạn: KarenZ, Foresight News

Vào ngày 20 tháng 4, Vitalik Buterin đã trình bày một đề xuất quan trọng trên nền tảng Ethereum Magicians cho lớp thực thi L1 dài hạn của Ethereum. Ông đề xuất thay thế EVM (Máy ảo Ethereum) hiện có bằng kiến trúc RISC-V như một ngôn ngữ máy ảo để viết các 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 của Ethereum, vượt qua một trong những nút thắt cổ chai mở rộng lớn hiện tại và đơn giản hóa đáng kể sự đơ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 tầm nhìn kỹ thuật này. Sau đây là tổng hợp đề xuất ban đầu:

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

Ý tưởng cốt lõi: Thay thế EVM bằng RISC-V làm ngôn ngữ máy ảo cho các 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 hợp đồng chéo, lưu trữ, v.v., sẽ được giữ lại hoàn toàn. Những thiết kế trừu tượng này hoạt động tốt và các nhà phát triển đã quen với việc sử dụng chúng. CÁC OPCODE NHƯ SLOAD, SSTORE, BALANCE, CALL, V.V., ĐƯỢC CHUYỂN ĐỔI THÀNH LỆNH GỌI HỆ THỐNG RISC-V.

• Ở chế độ này, các 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), sẽ thích ứng với RISC-V như một phần phụ trợ mới. Bởi vì các hợp đồng thông minh được viết bằng Rust thực sự ít dễ đọc hơn, trong khi Solidity và Vyper rõ ràng hơn 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.

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

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

Tại sao?

Trong ngắn hạn, các EIP sắp tới (ví dụ: 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) sẽ giải quyết các nút thắt cổ chai mở rộng quy mô chính của Ethereum L1. Nhiều vấn đề sẽ được giải quyết trong trung hạn với tình trạng không trạng thái và ZK-EVM. Về lâu dài, các yếu tố hạn chế chính cho việc mở rộng quy mô Ethereum L1 sẽ trở thành:

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

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

3. Bằng chứng về 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 nút thắt cổ chai chính trong (2) và (3).

Bảng sau đây minh họa số chu kỳ cần thiết cho mỗi bước của lớp thực thi Succinct ZK-EVM Proof EVM:

Mô tả sơ đồ: Bốn phân đoạn tốn thời gian chính là deserialize_inputs, initialize_witness_db, state_root_computation và block_execution

initialize_witness_db và state_root_computation có 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à nhân chứng thành các biểu diễn nội bộ - hơn 50% trong số đó thực sự tỷ lệ thuận với kích thước của dữ liệu nhân chứng.

Các phần này có thể được tối ưu hóa đáng kể bằng cách thay thế cây keccak 16-ary Merkle patricia hiện tại bằng một cây nhị phân sử dụng hàm băm dễ chứng minh. Nếu chúng ta 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 cho 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 loại bỏ hoa.

block_execution còn lại chiếm khoảng một nửa chu kỳ chứng minh hiện tại. Để đạt được hiệu suất chứng minh tổng thể tăng 100 lần, hiệu suất chứng minh EVM ít nhất là 50 lần là cần thiết. Một giải pháp là tạo ra một triển khai bằng chứng hiệu quả hơn cho EVM và giải pháp thứ hai là lưu ý rằng người chứng minh ZK-EVM hiện tại thực sự biên dịch EVM thành RISC-V để chứng minh, cho phép các nhà phát triển hợp đồng thông minh 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ả tăng hơn 100 lần có thể xảy ra trong một số tình huống nhất định:

Trong thực tế, thời gian prover còn lại có thể chủ yếu được sử dụng bởi hoạt động biên dịch trước hiện tại. Với RISC-V là máy ảo chính, lịch trình gas sẽ phản ánh thời gian chứng minh 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 tiền biên dịch chi phí cao. Ngay cả khi đó, lợi ích sẽ không quá đáng kể, nhưng chúng tôi có lý do chính đáng để tin rằng chúng sẽ đáng kể.

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

Chi tiết triển khai

Có một số cách để thực hiện đề xuất này. Giải pháp ít gián đoạn nhất là hỗ trợ cả hai máy ảo và cho phép hợp đồng được viết bằng một trong số chúng. Cả hai loại hợp đồng đều có quyền truy cập vào các tính năng giống nhau: lưu trữ liên tục (SLOAD/SSTORE), khả năng giữ số dư ETH, bắt đầu/nhận cuộc gọi, v.v. Hợp đồng EVM và RISC-V có thể được gọi cho nhau - từ góc độ 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 thông số đặc biệt; Hợp đồng EVM nhận được tin nhắn sẽ diễn giải nó là CALL.

Một cách tiếp cận triệt để hơn từ góc độ giao thức là chuyển đổi hợp đồng EVM hiện có thành lệnh gọi đến hợp đồng thông dịch EVM được viết bằng RISC-V để chạy mã EVM hiện có của nó. Nghĩa là, nếu một 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, gọi X và truyền vào (C, D), sau đó đợi giá trị trả về và chuyển tiếp. 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 thao tác này.

Sự thỏa hiệp là lựa chọn thứ hai, nhưng với sự hỗ trợ rõ ràng cho khái niệm "trình thông dịch máy ảo" thông qua một giao thức yêu cầu logic của nó phải được viết bằng RISC-V. EVM sẽ là trường hợp đầu tiên, với sự hỗ trợ cho các ngôn ngữ khác 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 đơn giản hóa đáng kể đặc tả lớp thực thi. VỚI KHÓ KHĂN THẬM CHÍ LOẠI BỎ NHỮNG SỰ ĐƠN GIẢN HÓA GIA TĂNG NHƯ TỰ HỦY, DÒNG SUY NGHĨ NÀY CÓ THỂ LÀ CON ĐƯỜNG KHẢ THI DUY NHẤT ĐỂ ĐƠN GIẢN HÓA. Tinygrad tuân thủ quy tắc cứng là "không quá 10.000 dòng mã" và blockchain cơ bản tối ưu sẽ có thể dễ dàng đáp ứng giới hạn này và hợp lý hóa nó hơn nữa. Sáng kiến Beam Chain hứa hẹn sẽ đơn giản hóa đáng kể lớp đồng thuận của Ethereum và một thay đổi triệt để như vậy có thể là cách duy nhất để đạt được sự thúc đẩy tương tự ở lớp thực thi.