Bài đăng này đề xuất một ý tưởng triệt hạ cho tương lai của lớp thực thi Ethereum, một ý tưởng mà cũng mạnh mẽ như nỗ lực chuỗi beam đối với lớp đồng thuận. Nó nhằm mục tiêu 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 hạn chế chính về khả năng mở rộng và cũng có thể cải thiện đáng kể tính đơn giản của lớp thực thi - thực sự, có lẽ đó là cách duy nhất để làm điều đó.

Ý tưởng: thay thế EVM bằng RISC-V như ngôn ngữ máy ảo mà hợp đồng thông minh được viết bằng.

Sự làm rõ quan trọng:

• Các khái niệm về tài khoản, cuộc gọi chéo giữa hợp đồng, lưu trữ, vv sẽ vẫn giữ nguyên. Những 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ã vận hành như SLOAD, SSTORE, BALANCE, CALL, vv, 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 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), mà sẽ thích nghi để thêm RISC-V vào như là backend. Điều này bởi vì hợp đồng thông minh viết bằng Rust là thực sựkháxấu, và Solidity và Vyper là rất nhiều more đọc được. Tiềm năng, devex có thể thay đổi rất ít và nhà phát triển có thể chỉ nhận thấy sự thay đổi rất nhỏ hoặc không nhận thấy sự thay đổi hoàn toàn.
• Hợp đồng EVM kiểu cũ sẽ tiếp tục hoạt động và sẽ hoàn toàn tương thích hai chiều với hợp đồng RISC-V kiểu mới. Có một vài cách để làm điều này, mà tôi sẽ thảo luận sau trong bài viết này.

Một tiền lệ cho điều này là Nervos CKB VM, mà là về cơ bản là RISC-V.

Tại sao làm vậy?

Trong tương lai ngắn, những rào cản chính đối với khả năng mở rộng L1 của Ethereum được giải quyết với các EIP sắp tới như danh sách truy cập cấp khối, thực hiện trì hoãnvà lưu trữ lịch sử phân phối cộng với EIP-4444Trong dài hạn, chúng tôi sẽ giải quyết các vấn đề khác với trạng thái không quốc tịchvàZK-EVMs. Trong thời gian dài, các yếu tố hạn chế chính trên Ethereum L1 scaling trở thành:

1. Sự ổn định của giao thức lấy mẫu sẵn có dữ liệu và lưu trữ lịch sử
2. Mong muốn giữ cho việc sản xuất khối là một thị trường cạnh tranh
3. Khả năng chứng minh ZK-EVM

Tôi sẽ bào chữa rằng việc thay thế ZK-EVM bằng RISC-V giải quyết một vấn đề chính trong (2) và (3).

Đây là một 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 mất rất 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, và deserialize_inputs đề cập đến quá trình chuyển đổi dữ liệu khối và nhân chứng thành biểu diễn nội bộ; do đó, một cách thực tế hơn 50% của nó tỉ lệ thuận với kích thước nhân chứng.

Các phần này có thể được tối ưu hóa mạnh mẽ bằng cách thay thế cây Merkle patricia 16-ary hiện tại bằng một cây nhị phân sử dụng một hàm băm thân thiện với bằng chứng chuyên nghiệp. 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âytrên một laptop (so với ~15.000 hash/giây cho keccak). Cũng có nhiều tùy chọn khác ngoài Poseidon. Tóm lại, có cơ hội giảm đáng kể các thành phần này. Như một phần thưởng, chúng ta có thể loại bỏ accrue_logs_bloom bằng cách, vâng,loại bỏ sự bùng nở.

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

Một số con số cho thấy rằng trong những trường hợp có hạn chế, điều này có thể mang lại lợi ích về hiệu suất lên đến 100 lần:

Trong thực tế, tôi mong đợi rằng thời gian chứng minh còn lại sẽ trở nên chuyên nghiệp bởi những gì hiện nay được gọi là các precompile. Nếu chúng ta làm cho RISC-V trở thành VM chính, thì lịch trình gas sẽ phản ánh thời gian chứng minh, và do đó sẽ có áp lực kinh tế để ngừng sử dụng các precompile đắt tiền hơn; nhưng ngay cả khi vậy, những lợi ích sẽ không được ấn tượng như vậy, nhưng chúng ta có lý do tốt để tin rằng chúng sẽ rất quan trọng.

(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 thi thông thường của EVMvà chúng tôi mong đợi một cách trực giác rằng lợi ích từ việc loại bỏ EVM như một “người trung gian” sẽ tương tự lớn

Chi tiết triển khai

Có một số cách để triển khai loại đề xuất này. Cách ít gây rối nhất là hỗ trợ hai VM, và cho phép hợp đồng được viết trong bất kỳ cái nào. Cả hai loại hợp đồng đều có quyền truy cập vào cùng loại tiện ích: lưu trữ liên tục (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. Các hợp đồng EVM và RISC-V sẽ được tự do gọi vào nhau; từ góc nhìn của RISC-V, việc gọi một hợp đồng EVM sẽ xuất hiện từ góc nhìn của nó như đang thực hiện 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 tin nhắn sẽ giải thích nó như là một CALL.

Một cách tiếp cận cách mạng hơn từ góc độ 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 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ọ. Đó là, nếu một hợp đồng EVM có mã C và trình thông dịch EVM sống tại địa chỉ X, sau đó hợp đồng được thay thế bằng logic cấp cao, khi được gọi từ bên ngoài với các tham số gọi D, gọi X với (C, D), và sau đó đợi giá trị trả về và chuyển tiếp nó. Nếu trình thông dịch EVM chính nó gọi hợp đồng, yêu cầu chạy một CALL hoặc SLOAD/SSTORE, sau đó hợp đồng làm như vậy.

Một tuyến đường trung gian là thực hiện tùy chọn thứ hai, nhưng tạo một tính năng giao thức rõ ràng cho nó - về cơ bản, tôn trọng khái niệm của một “trình thông dịch 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ó các cái khác (ví dụ, Move có thể là ứng cử viên).

Một lợi ích chính của đề xuất thứ hai và thứ ba là chúng giúp đơn giản hóa đáng kể bản đặc tả lớp thực thi - thực sự, loại ý tưởng này có thể là cách thực tế duy nhất để làm điều đó, khi mà việc giảm đơn giản ngay cả các phần tử nhỏ như loại bỏ SELFDESTRUCT đều gặp khó khăn. Tinygrad có quy tắc nghiêm ngặt củakhông bao giờ vượt quá 10000 dòng mã; một lớp cơ sở blockchain tối ưu phải có thể phù hợp tốt trong những ranh giới đó và thậm chí còn nhỏ hơn. Nỗ lực chuỗi tia mang lại hứa hẹn lớn cho việc đơn giản hóa lớp đồng thuận của Ethereum. Nhưng đối với lớp thực thi để thấy được những lợi ích tương tự, loại thay đổi cấp độ cực đoan này có thể là con đường duy nhất.

Miễn trừ trách nhiệm:

1. Bài viết này được sao chép từ [Ethereum Magicians]. Tất cả bản quyền thuộc về tác giả gốc [Vitalik Buterin]. Nếu có ý kiến ​​phản đối về việc tái in này, vui lòng liên hệ với Gate Họcđội ngũ, và họ sẽ xử lý nó ngay lập tức.
2. Tuyên bố từ chối trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Đội ngũ Gate Learn thực hiện dịch bài viết sang các ngôn ngữ khác. Việc sao chép, phân phối hoặc đạo văn bản dịch là không được phép trừ khi có được đề cập.