Vào ngày 20 tháng 4, Vitalik Buterin đã đưa ra một đề xuất quan trọng về lớp thực thi L1 dài hạn của Ethereum trên nền tảng Ethereum Magicians. Ông đề xuất sử dụng kiến trúc RISC-V thay thế cho EVM (Máy ảo Ethereum) hiện tại làm ngôn ngữ máy ảo để viết hợp đồng thông minh, nhằm nâng cao hiệu quả hoạt động của lớp thực thi Ethereum một cách cơ bản, vượt qua một trong những nút thắt mở rộng chính hiện tại, đồng thời đơn giản hóa đáng kể sự đơn giản của lớp thực thi.
Foresight News đã dịch toàn văn đề xuất này, nhằm giúp độc giả hiểu rõ hơn về ý tưởng công nghệ này. Dưới đây là nội dung dịch của văn bản gốc của đề xuất:
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, có tham vọng không thua kém gì kế hoạch Beam Chain của lớp đồng thuận. Đề xuất này nhằm mục đích nâng cao đá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à đơn giản hóa đáng kể lớp thực thi - thực tế, đây có thể là cách duy nhất để đạt được mục tiêu này.
Ý tưởng cốt lõi: Sử dụng RISC-V thay thế EVM, như một ngôn ngữ máy ảo để viết hợp đồng thông minh.
Lưu ý quan trọng:
Hệ thống tài khoản, gọi hàm qua hợp đồng, lưu trữ và các khái niệm khác sẽ được giữ nguyên 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 mã thao tác như SLOAD, SSTORE, BALANCE, CALL sẽ được chuyển đổi thành các lệnh gọi hệ thống RISC-V.
Trong chế độ này, hợp đồng thông minh có thể được viết bằng Rust, nhưng tôi dự đoán rằng phần lớn các nhà phát triển vẫn sẽ tiếp tục sử dụng Solidity (hoặc Vyper) để viết hợp đồng, những ngôn ngữ này sẽ thích ứng với RISC-V như một backend mới. Bởi vì hợp đồng thông minh được viết bằng Rust thực tế có khả năng đọc kém hơn, trong khi Solidity và Vyper thì rõ ràng và dễ đọc hơn. Trải nghiệm phát triển có thể gần như không bị ảnh hưởng, 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 phiên bản cũ sẽ tiếp tục hoạt động và hoàn toàn tương thích hai chiều với hợp đồng RISC-V phiên bản mới. Có một số cách để thực hiện điều này, bài viết này sẽ thảo luận chi tiết trong phần sau.
Nervos CKB VM đã mở ra một tiền lệ, bản chất của nó chính là việc thực hiện RISC-V.
Tại sao lại làm như vậy?
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 hoãn lại, lưu trữ lịch sử phân tán và EIP-4444) sẽ giải quyết các tắc nghẽn quy mô lớn của Ethereum L1. Trong trung hạn, nhiều vấn đề sẽ được giải quyết với tình trạng không 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 L1 sẽ trở thành:
Tính khả dụng dữ liệu, mẫu và sự ổn định của giao thức lưu trữ lịch sử
Giữ cho nhu cầu cạnh tranh trong thị trường sản xuất khối.
Khả năng chứng minh của ZK-EVM
Tôi sẽ chứng minh rằng việc thay thế ZK-EVM bằng RISC-V có thể giải quyết các nút thắt chính trong (2) và (3).
Bảng dưới đây trình bày số chu kỳ cần thiết cho từng giai đoạn của lớp thực thi EVM trong chứng minh Succinct ZK-EVM:
Giải thích biểu đồ: Bốn giai đoạn tốn thời gian chính là deserialize_inputs, initialize_witness_db, state_root_computation và block_execution
Trong đó, initialize_witness_db và state_root_computation liên quan đến cây trạng thái, deserialize_inputs liên quan đến quá trình chuyển đổi dữ liệu khối và dữ liệu nhân chứng thành biểu diễn nội bộ - thực tế hơn 50% tỷ lệ với kích thước dữ liệu nhân chứng.
Bằng cách thay thế cây Merkle patricia 16-ary keccak hiện tại bằng cây nhị phân sử dụng hàm băm dễ chứng minh, các phần này có thể được tối ưu hóa đáng kể. Nếu 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 máy tính xách tay (so với keccak khoảng 15.000 hash/sec). Ngoài Poseidon, còn nhiều lựa chọn khác. Tổng thể, các thành phần này có rất nhiều không gian tối ưu hóa. Hơn nữa, chúng ta có thể loại bỏ bloom để xóa accrue_logs_bloom.
Phần còn lại của block_execution chiếm khoảng một nửa chu kỳ chứng minh hiện tại (prover cycles). Để đạt được mức tăng hiệu suất chứng minh tổng thể gấp 100 lần, hiệu suất chứng minh EVM cần ít nhất phải tăng 50 lần. Một trong những giải pháp là tạo ra một triển khai chứng minh hiệu quả hơn cho EVM, giải pháp khác là nhận ra rằng trình chứng minh ZK-EVM hiện tại thực chất là thông qua việc biên dịch EVM thành RISC-V để thực hiện 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 trong những trường hợp cụ thể, hiệu suất có thể tăng hơn 100 lần:
Trong thực tế, thời gian prover còn lại có thể chủ yếu do các thao tác biên dịch trước (precompiles) hiện tại chiếm giữ. Nếu RISC-V được sử dụng làm máy ảo chính, lịch trình Gas sẽ phản ánh thời gian chứng minh thực tế, áp lực kinh tế sẽ thúc đẩy các nhà phát triển giảm sử dụng các biên dịch trước có chi phí cao. Dù vậy, lợi ích cũng sẽ không rõ ràng như vậy, nhưng chúng tôi có lý do đầy đủ để tin rằng, những lợi ích này sẽ rất đáng kể.
(Cần lưu ý rằng, trong quá trình thực thi EVM thông thường, tỷ lệ thời gian tiêu tốn cho "hoạt động EVM" và "các hoạt động khác" cũng gần 50/50, do đó chúng tôi trực quan 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ể tương tự)
Chi tiết thực hiện
Đề xuất này có nhiều cách thực hiện. Phương án ít gây phá hủy nhất là hỗ trợ đồng thời hai loại máy ảo, cho phép hợp đồng chọn một trong hai để viết. Cả hai loại hợp đồng đều có thể truy cập cùng một chức năng: lưu trữ bền vững (SLOAD/SSTORE), khả năng nắm giữ số dư ETH, khởi xướng / nhận cuộc gọi, v.v. Hợp đồng EVM và RISC-V có thể gọi lẫn nhau - từ góc nhìn của RISC-V, việc gọi hợp đồng EVM tương đương với việc thực hiện một cuộc gọi hệ thống với tham số đặc biệt; trong khi hợp đồng EVM nhận tin nhắn sẽ giải thích nó như một cuộc gọi 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 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 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 bằng đối số cuộc gọi D, gọi X và chuyển (C, D), sau đó đợi giá trị trả về và chuyển tiếp. Nếu bản thân thông dịch viên EVM 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 hoạt động này.
Giải pháp trung gian là áp dụng phương án thứ hai, nhưng thông qua thỏa thuận rõ ràng hỗ trợ khái niệm "trình thông dịch máy ảo", yêu cầu logic của nó được viết bằng RISC-V. EVM sẽ là trường hợp đầu tiên, trong tương lai còn có thể hỗ trợ các ngôn ngữ khác (Move có thể là phương án ứng cử).
Lợi thế cốt lõi của phương án thứ hai và thứ ba là chúng có thể đơn giản hóa đáng kể các quy định của lớp thực thi. Xét rằng ngay cả việc loại bỏ SELFDESTRUCT cũng là một sự đơn giản hóa có tính tiến bộ đầy khó khăn, thì tư duy này có thể là con đường đơn giản hóa khả thi duy nhất. Tinygrad tuân theo quy định cứng "mã không quá 10.000 dòng", trong khi một blockchain tối ưu lý tưởng nên dễ dàng đáp ứng giới hạn này và tiếp tục tinh giản hơn nữa. Kế hoạch Beam Chain dự kiến sẽ đơn giản hóa đáng kể lớp đồng thuận của Ethereum, trong khi lớp thực thi nếu muốn đạt được sự nâng cao tương tự, thì sự thay đổi triệt để này có thể là con đường khả thi duy nhất.
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Toàn văn đề xuất L1 thực thi dài hạn của Vitalik: Thay thế EVM bằng RISC-V
Nguồn: Vitalik Buterin
Biên dịch: KarenZ, Foresight News
Vào ngày 20 tháng 4, Vitalik Buterin đã đưa ra một đề xuất quan trọng về lớp thực thi L1 dài hạn của Ethereum trên nền tảng Ethereum Magicians. Ông đề xuất sử dụng kiến trúc RISC-V thay thế cho EVM (Máy ảo Ethereum) hiện tại làm ngôn ngữ máy ảo để viết hợp đồng thông minh, nhằm nâng cao hiệu quả hoạt động của lớp thực thi Ethereum một cách cơ bản, vượt qua một trong những nút thắt mở rộng chính hiện tại, đồng thời đơn giản hóa đáng kể sự đơn giản của lớp thực thi.
Foresight News đã dịch toàn văn đề xuất này, nhằm giúp độc giả hiểu rõ hơn về ý tưởng công nghệ này. Dưới đây là nội dung dịch của văn bản gốc của đề xuất:
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, có tham vọng không thua kém gì kế hoạch Beam Chain của lớp đồng thuận. Đề xuất này nhằm mục đích nâng cao đá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à đơn giản hóa đáng kể lớp thực thi - thực tế, đây có thể là cách duy nhất để đạt được mục tiêu này.
Ý tưởng cốt lõi: Sử dụng RISC-V thay thế EVM, như một ngôn ngữ máy ảo để viết hợp đồng thông minh.
Lưu ý quan trọng:
Hệ thống tài khoản, gọi hàm qua hợp đồng, lưu trữ và các khái niệm khác sẽ được giữ nguyên 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 mã thao tác như SLOAD, SSTORE, BALANCE, CALL sẽ được chuyển đổi thành các lệnh gọi hệ thống RISC-V.
Trong chế độ này, hợp đồng thông minh có thể được viết bằng Rust, nhưng tôi dự đoán rằng phần lớn các nhà phát triển vẫn sẽ tiếp tục sử dụng Solidity (hoặc Vyper) để viết hợp đồng, những ngôn ngữ này sẽ thích ứng với RISC-V như một backend mới. Bởi vì hợp đồng thông minh được viết bằng Rust thực tế có khả năng đọc kém hơn, trong khi Solidity và Vyper thì rõ ràng và dễ đọc hơn. Trải nghiệm phát triển có thể gần như không bị ảnh hưởng, 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 phiên bản cũ sẽ tiếp tục hoạt động và hoàn toàn tương thích hai chiều với hợp đồng RISC-V phiên bản mới. Có một số cách để thực hiện điều này, bài viết này sẽ thảo luận chi tiết trong phần sau.
Nervos CKB VM đã mở ra một tiền lệ, bản chất của nó chính là việc thực hiện RISC-V.
Tại sao lại làm như vậy?
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 hoãn lại, lưu trữ lịch sử phân tán và EIP-4444) sẽ giải quyết các tắc nghẽn quy mô lớn của Ethereum L1. Trong trung hạn, nhiều vấn đề sẽ được giải quyết với tình trạng không 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 L1 sẽ trở thành:
Tính khả dụng dữ liệu, mẫu và sự ổn định của giao thức lưu trữ lịch sử
Giữ cho nhu cầu cạnh tranh trong thị trường sản xuất khối.
Khả năng chứng minh của ZK-EVM
Tôi sẽ chứng minh rằng việc thay thế ZK-EVM bằng RISC-V có thể giải quyết các nút thắt chính trong (2) và (3).
Bảng dưới đây trình bày số chu kỳ cần thiết cho từng giai đoạn của lớp thực thi EVM trong chứng minh Succinct ZK-EVM:
Giải thích biểu đồ: Bốn giai đoạn tốn thời gian chính là deserialize_inputs, initialize_witness_db, state_root_computation và block_execution
Trong đó, initialize_witness_db và state_root_computation liên quan đến cây trạng thái, deserialize_inputs liên quan đến quá trình chuyển đổi dữ liệu khối và dữ liệu nhân chứng thành biểu diễn nội bộ - thực tế hơn 50% tỷ lệ với kích thước dữ liệu nhân chứng.
Bằng cách thay thế cây Merkle patricia 16-ary keccak hiện tại bằng cây nhị phân sử dụng hàm băm dễ chứng minh, các phần này có thể được tối ưu hóa đáng kể. Nếu 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 máy tính xách tay (so với keccak khoảng 15.000 hash/sec). Ngoài Poseidon, còn nhiều lựa chọn khác. Tổng thể, các thành phần này có rất nhiều không gian tối ưu hóa. Hơn nữa, chúng ta có thể loại bỏ bloom để xóa accrue_logs_bloom.
Phần còn lại của block_execution chiếm khoảng một nửa chu kỳ chứng minh hiện tại (prover cycles). Để đạt được mức tăng hiệu suất chứng minh tổng thể gấp 100 lần, hiệu suất chứng minh EVM cần ít nhất phải tăng 50 lần. Một trong những giải pháp là tạo ra một triển khai chứng minh hiệu quả hơn cho EVM, giải pháp khác là nhận ra rằng trình chứng minh ZK-EVM hiện tại thực chất là thông qua việc biên dịch EVM thành RISC-V để thực hiện 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 trong những trường hợp cụ thể, hiệu suất có thể tăng hơn 100 lần:
Trong thực tế, thời gian prover còn lại có thể chủ yếu do các thao tác biên dịch trước (precompiles) hiện tại chiếm giữ. Nếu RISC-V được sử dụng làm máy ảo chính, lịch trình Gas sẽ phản ánh thời gian chứng minh thực tế, áp lực kinh tế sẽ thúc đẩy các nhà phát triển giảm sử dụng các biên dịch trước có chi phí cao. Dù vậy, lợi ích cũng sẽ không rõ ràng như vậy, nhưng chúng tôi có lý do đầy đủ để tin rằng, những lợi ích này sẽ rất đáng kể.
(Cần lưu ý rằng, trong quá trình thực thi EVM thông thường, tỷ lệ thời gian tiêu tốn cho "hoạt động EVM" và "các hoạt động khác" cũng gần 50/50, do đó chúng tôi trực quan 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ể tương tự)
Chi tiết thực hiện
Đề xuất này có nhiều cách thực hiện. Phương án ít gây phá hủy nhất là hỗ trợ đồng thời hai loại máy ảo, cho phép hợp đồng chọn một trong hai để viết. Cả hai loại hợp đồng đều có thể truy cập cùng một chức năng: lưu trữ bền vững (SLOAD/SSTORE), khả năng nắm giữ số dư ETH, khởi xướng / nhận cuộc gọi, v.v. Hợp đồng EVM và RISC-V có thể gọi lẫn nhau - từ góc nhìn của RISC-V, việc gọi hợp đồng EVM tương đương với việc thực hiện một cuộc gọi hệ thống với tham số đặc biệt; trong khi hợp đồng EVM nhận tin nhắn sẽ giải thích nó như một cuộc gọi 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 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 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 bằng đối số cuộc gọi D, gọi X và chuyển (C, D), sau đó đợi giá trị trả về và chuyển tiếp. Nếu bản thân thông dịch viên EVM 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 hoạt động này.
Giải pháp trung gian là áp dụng phương án thứ hai, nhưng thông qua thỏa thuận rõ ràng hỗ trợ khái niệm "trình thông dịch máy ảo", yêu cầu logic của nó được viết bằng RISC-V. EVM sẽ là trường hợp đầu tiên, trong tương lai còn có thể hỗ trợ các ngôn ngữ khác (Move có thể là phương án ứng cử).
Lợi thế cốt lõi của phương án thứ hai và thứ ba là chúng có thể đơn giản hóa đáng kể các quy định của lớp thực thi. Xét rằng ngay cả việc loại bỏ SELFDESTRUCT cũng là một sự đơn giản hóa có tính tiến bộ đầy khó khăn, thì tư duy này có thể là con đường đơn giản hóa khả thi duy nhất. Tinygrad tuân theo quy định cứng "mã không quá 10.000 dòng", trong khi một blockchain tối ưu lý tưởng nên dễ dàng đáp ứng giới hạn này và tiếp tục tinh giản hơn nữa. Kế hoạch Beam Chain dự kiến sẽ đơn giản hóa đáng kể lớp đồng thuận của Ethereum, trong khi lớp thực thi nếu muốn đạt được sự nâng cao tương tự, thì sự thay đổi triệt để này có thể là con đường khả thi duy nhất.