Đề xuất mới của Vitalik: RISC-V là ngôn ngữ máy ảo cho hợp đồng thông minh EVM

Nguồn: Vitalik Buterin, Ethereum Magicians; Người dịch: Tao Zhu, Golden Finance

Bài viết 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, một ý tưởng đầy tham vọng như những nỗ lực của Beam chain cho lớp đồng thuận. Mục đích của nó là 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à cũng cải thiện đáng kể tính đơn giản của lớp thực thi — trên thực tế, đây có thể là cách duy nhất để thực hiện điều đó.

Ý tưởng: Sử dụng RISC-V làm ngôn ngữ máy ảo để viết hợp đồng thông minh EVM.

Làm rõ quan trọng:

• Các khái niệm về tài khoản, lệnh gọi hợp đồng chéo, lưu trữ, v.v. sẽ vẫn giữ nguyê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ẽ trở thành lệnh gọi hệ thống RISC-V.

• Trong thế giới như vậ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 thông minh bằng Solidity (hoặc Vyper), ngôn ngữ này sẽ được điều chỉnh để thêm RISC-V làm nền tảng. Nguyên nhân là do các hợp đồng thông minh được viết bằng Rust thực sự khá xấu, trong khi Solidity và Vyper dễ đọc hơn nhiều. Có lẽ sự thay đổi trong devex quá nhỏ đến mức các nhà phát triển khó có thể nhận thấy sự thay đổi.

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

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

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

Trong ngắn hạn, những điểm nghẽn chính trong khả năng mở rộng Ethereum L1 sẽ được giải quyết thông qua các EIP sắp tới như danh sách truy cập cấp khối, thực thi chậm trễ 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 đề liên quan đến 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 quy mô Ethereum Layer1 là:

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

• Mong muốn duy trì một thị trường sản xuất khối cạnh tranh

• Khả năng xác minh ZK-EVM

Tôi tin rằng việc thay thế ZK-EVM bằng RISC-V có thể giải quyết được nút thắt chính trong (2) và (3).

Dưới đây là bảng về số chu kỳ mà Succinct ZK-EVM sử dụng để chứng minh các phần khác nhau của lớp thực thi EVM:

Có bốn phần tốn 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, còn deserialize_inputs đề cập đến quá trình chuyển đổi dữ liệu khối và dữ liệu chứng kiến ​​thành biểu diễn nội bộ; do đó, trên thực tế, hơn 50% tỷ lệ thuận với quy mô nhân chứng.

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 thân thiện với trình 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 mỗi giây đối với keccak). Ngoài Poseidon còn có nhiều lựa chọn khác. Nhìn chung, chúng ta có cơ hội giảm đáng kể 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ỏ bloom.

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

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

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

(Nhân tiện, sự phân chia gần đúng 50/50 giữa "EVM" và "thứ gì đó khác" cũng xảy ra trong quá trình thực thi EVM thông thường và theo trực giác, chúng ta mong đợi rằng lợi ích từ việc loại bỏ EVM khỏi vai trò "trung gian" cũng sẽ lớn như vậy)

Chi tiết triển khai

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

Theo quan điểm giao thức, một cách tiếp cận triệt để hơn sẽ là chuyển đổi các hợp đồng EVM hiện có thành các hợp đồng gọi hợp đồng thông dịch EVM được viết bằng RISC-V, chạy mã EVM hiện có. 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ới (C, D) rồi đợi giá trị trả về và chuyển tiếp giá trị đó. Nếu trình thông dịch EVM tự gọi vào hợp đồng, yêu cầu chạy lệnh CALL hoặc SLOAD/SSTORE, thì hợp đồng sẽ thực hiện.

Một giải pháp trung gian sẽ là chọn phương án thứ hai, nhưng tạo một hàm giao thức rõ ràng cho phương án này — về cơ bản là đưa ý tưởng về "trình thông dịch máy ảo" vào và yêu cầu logic của nó phải được viết bằng RISC-V. EVM sẽ là ứng cử viên đầu tiên, nhưng có thể còn những ứng cử viên khác (ví dụ như Move).

Lợi ích chính của đề xuất thứ hai và thứ ba là chúng đơn giản hóa đáng kể thông số kỹ thuật của lớp thực thi - trên thực tế, ý tưởng này có thể là cách tiếp cận khả thi duy nhất, vì ngay cả việc đơn giản hóa gia tăng như loại bỏ SELFDESTRUCT cũng rất khó khăn. Tinygrad có quy định nghiêm ngặt là không bao giờ được vượt quá 10.000 dòng mã; các lớp cơ sở blockchain tốt nhất phải phù hợp với những ranh giới này hoặc thậm chí nhỏ hơn. Nỗ lực phát triển chuỗi Beam hứa hẹn sẽ đơn giản hóa đáng kể lớp đồng thuận của Ethereum. Nhưng đối với các nhà điều hành, sự thay đổi triệt để như vậy có thể là con đường khả thi duy nhất để đạt được những lợi ích tương tự.