Nguồn: Vitalik Buterin, Ethereum Magicians; Người dịch: Tao Zhu, Jinse Finance
Bài viết đề xuất một ý tưởng cấp tiến cho tương lai của lớp thực thi Ethereum, một ý tưởng đầy tham vọng như những nỗ lực của Beam Chuỗi 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 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à phương pháp.
Ý tưởng: Sử dụng RISC-V làm ngôn ngữ máy ảo để viết hợp đồng thông minh EVM.
Giải thích quan trọng:
Các khái niệm như tài khoản, cuộc gọi liên hợp đồng, 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 và CALL 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 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 mới hơn. Có một số phương pháp để 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 thế này?
Trong ngắn hạn, những điểm nghẽn chính trong 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 mở rộng Ethereum Layer 1 là:
Lấy mẫu dữ liệu khả dụng và tính ổn định của các giao thức lưu trữ lịch sử
Mong muốn duy trì thị trường sản xuất khối cạnh tranh
Khả năng xác minh ZK-EVM
Tôi cho 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).
Sau đâ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 lượng lớn thời gian: deserialize_inputs, initialize_witness_db, state_root_computation và block_execution.
Cả 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 lượng lớn 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 lần mỗi giây trên máy tính xách tay (so với khoảng lần 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ể Prover 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ả Prover 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 Prover 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 trong một số trường hợp hạn chế, điều này có thể tăng hiệu quả lên hơn 100 lần:
Trên thực tế, tôi hy vọng thời gian chứng minh 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 chuyển sang 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; ngay cả khi đó, lợi nhuận sẽ không ấn tượng như vậy, nhưng 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 gần đúng 50/50 giữa “EVM” và “thứ gì đó khác” cũng xảy ra trong quá trình thực hiện EVM thông thường và theo trực giác, chúng ta mong đợi rằng lợi nhuận từ việc loại bỏ EVM khỏi vai trò “trung gian” cũng sẽ lớn như nhau)
Chi tiết thực hiện
Có nhiều phương pháp để thực hiện những khuyến nghị như vậy. Phương pháp í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 cuộc gọi, 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 tin nhắn này sẽ hiểu đó là một CALL.
Một phương phá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ó 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ó của chú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ớ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 nó — 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 Đề án 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ế, cách tiếp cận này có thể là phương pháp khả thi duy nhất, vì ngay cả những cải tiến 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 lợi nhuận tương tự.
