Vitalik đề xuất mới: Thay thế EVM hiện tại bằng RISC-V

Bài viết này đưa ra một ý tưởng táo bạo về tương lai của lớp thực thi Ethereum, ý tưởng này cũng tham vọng như những nỗ lực của chuỗi Beam đối với lớp đồng thuận. Nó nhằm mục đích cải thiện đáng kể hiệu suất của lớp thực thi Ethereum, giải quyết một trong những nút thắt mở rộng chính, và cũng có thể cải thiện đáng kể sự đơn giản của lớp thực thi - thực tế, đây có thể là cách duy nhất.

Ý tưởng: Sử dụng RISC-V thay thế EVM làm ngôn ngữ máy ảo để viết hợp đồng thông minh (Chú thích của người dịch: RISC-V là kiến trúc tập lệnh mở được xây dựng dựa trên nguyên tắc RISC của kiến trúc tập lệnh giảm bớt, V đại diện cho thế hệ thứ năm của RISC).

Quan trọng làm rõ:

• Tài khoản, gọi chéo hợp đồng, lưu trữ và các khái niệm khác sẽ giữ nguyên hoàn toàn. Những trừu tượng này hoạt động rất tốt, các nhà phát triển cũng đã quen với chúng. Các mã hoạt động như SLOAD, SSTORE, BALANCE, CALL sẽ trở thành các cuộc gọi hệ thống RISC-V.
• Trong một thế giới như vậy, hợp đồng thông minh có thể được viết bằng Rust, nhưng tôi dự đoán rằng hầu hết các nhà phát triển sẽ tiếp tục viết hợp đồng thông minh bằng Solidity (hoặc Vyper), điều này sẽ phù hợp với việc thêm RISC-V làm backend. Điều này là vì hợp đồng thông minh được viết bằng Rust thực tế khá xấu xí, trong khi tính đọc hiểu của Solidity và Vyper cao hơn nhiều. Có lẽ sự thay đổi của devex là rất nhỏ, các nhà phát triển có thể gần như không nhận thấy sự thay đổi này.
• Hợp đồng EVM kiểu cũ sẽ tiếp tục có hiệu lực và sẽ hoàn toàn tương tác hai chiều với hợp đồng RISC-V kiểu mới. Có một số cách để thực hiện điều này, tôi sẽ giới thiệu ở phần sau của bài viết.

Một tiền lệ là Nervos CKB VM, nó cơ bản là RISC-V.

Tại sao lại làm như vậy?

Trong ngắn hạn, những nút thắt chính về khả năng mở rộng L1 của Ethereum sẽ được giải quyết thông qua các EIP sắp ra mắt, chẳng hạn như danh sách truy cập theo khối, thực thi chậm và lưu trữ lịch sử phân tán cũng như EIP-4444. Trong trung hạn, chúng tôi sẽ giải quyết thêm các vấn đề về trạng thái không và ZK-EVM. Trong dài hạn, các yếu tố hạn chế chính về mở rộng Layer1 của Ethereum là:

• Sự ổn định của mẫu khả dụng dữ liệu và giao thức lưu trữ lịch sử
• Hy vọng duy trì tính cạnh tranh của thị trường sản xuất khối.
• Khả năng xác minh ZK-EVM

Tôi nghĩ rằng việc thay thế ZK-EVM bằng RISC-V có thể giải quyết một nút thắt quan trọng trong (2) và (3).

Đây là bảng số lần lặp lại của các phần khác nhau của lớp thực thi EVM mà Succinct ZK-EVM sử dụng để chứng minh:

Có bốn phần đã chiếm nhiều thời gian: deserialize_inputs, initialize_witness_db, state_root_computation và block_execution.

initialize_witness_db và state_root_computation đều liên quan đến cây trạng thái, deserialize_inputs chỉ quá trình chuyển đổi dữ liệu khối và chứng kiến thành biểu diễn nội bộ; do đó, thực tế hơn 50% tỉ lệ thuận với quy mô chứng kiến.

Có thể tối ưu hóa đáng kể các phần này bằng cách thay thế cây Merkle patricia 16 phần hiện tại bằng cây nhị phân sử dụng hàm băm thân thiện với người chứng minh. Nếu chúng ta sử 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 (trong khi keccak chỉ khoảng 15.000 giá trị băm mỗi giây). Ngoài Poseidon, còn nhiều lựa chọn khác. Tóm lại, chúng ta có cơ hội giảm đáng kể các thành phần này. Là phần thưởng, chúng ta có thể loại bỏ accrue_logs_bloom bằng cách từ bỏ bloom.

Phần còn lại là block_execution, nó chiếm khoảng một nửa chu kỳ chứng minh mà chúng ta đã chi tiêu hôm nay. Nếu chúng ta muốn tăng hiệu suất của bộ chứng minh tổng thể lên 100 lần, thì chúng ta không thể tránh khỏi thực tế rằng ít nhất cần phải tăng hiệu suất của bộ chứng minh EVM lên 50 lần. Một điều chúng ta có thể làm là cố gắng tạo ra một phiên bản EVM hiệu quả hơn về mặt chu kỳ chứng minh. Một điều khác mà chúng ta có thể làm là nhận thấy rằng bộ chứng minh ZK-EVM hôm nay đã hoạt động thông qua việc chứng minh biên dịch thành EVM RISC-V và 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 VM RISC-V đó.

Một số dữ liệu cho thấy, trong những trường hợp hạn chế, điều này có thể nâng cao hiệu suất lên hơn 100 lần:

Trên thực tế, tôi dự đoán rằng thời gian chứng minh còn lại sẽ chủ yếu do việc biên dịch trước ngày hôm nay chi phối. Nếu chúng ta sử dụng RISC-V làm máy ảo chính, thì kế hoạch gas sẽ phản ánh thời gian chứng minh, do đó sẽ có áp lực kinh tế để ngừng sử dụng các biên dịch trước đắt hơn; nhưng ngay cả như vậy, lợi nhuận cũng sẽ không ấn tượng như vậy, nhưng chúng tôi có lý do chính đáng để tin rằng, lợi nhuận sẽ rất đáng kể.

(Nhân tiện, sự phân chia khoảng 50/50 giữa “EVM” và “những thứ khác” cũng xuất hiện trong việc thực hiện EVM thông thường, chúng tôi trực quan dự đoán rằng lợi ích được loại bỏ từ EVM như một “người trung gian” cũng nên lớn như nhau)

Chi tiết thực hiện

Có nhiều cách để thực hiện các đề xuất như vậy. Phương pháp ít gây hại nhất là hỗ trợ hai máy ảo và cho phép viết hợp đồng trong bất kỳ máy ảo nào. Cả hai loại hợp đồng đều có thể sử dụng cùng một loại cơ sở vật chất: lưu trữ lâu dài (SLOAD và SSTORE), khả năng giữ số dư ETH, khả năng thực hiện và nhận cuộc gọi, v.v. Hợp đồng EVM và RISC-V có thể tự do gọi lẫn nhau; từ góc độ của RISC-V, việc gọi hợp đồng EVM dường như là một cuộc gọi hệ thống với một số tham số đặc biệt; hợp đồng EVM nhận được thông điệp đó sẽ giải thích nó như một CALL.

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

Lộ trình trung gian là lựa chọn thứ hai, nhưng cần tạo ra một chức năng giao thức rõ ràng cho nó - về cơ bản, tôn vinh khái niệm “trình giải mã máy ảo” và yêu cầu logic của nó được viết bằng RISC-V. EVM sẽ là cái đầu tiên, nhưng cũng có thể có những cái khác (ví dụ, Move có thể là một ứng cử viên).

Lợi ích chính của hai đề xuất thứ hai và thứ ba là chúng đơn giản hóa đáng kể quy định của lớp thực thi - thực tế, ý tưởng này có thể là phương pháp duy nhất khả thi, vì ngay cả việc đơn giản hóa dần dần như xóa SELFDESTRUCT cũng rất khó khăn. Tinygrad có một quy định nghiêm ngặt rằng lượng mã không bao giờ vượt quá 10.000 dòng; lớp nền blockchain tốt nhất nên có khả năng phù hợp tốt với những giới hạn này, thậm chí còn nhỏ hơn. Nỗ lực của Beam Chain có nhiều hy vọng trong việc đơn giản hóa đáng kể lớp nhận thức chung của Ethereum. Nhưng đối với lớp thực thi, để đạt được những lợi ích tương tự, sự thay đổi triệt để này có thể là phương pháp duy nhất khả thi.