Bài viết này đến từ: Nhà phát triển Ethereum levochka.eth
Biên soạn bởi Odaily Planet Daily ( @OdailyChina ); Được dịch bởi Azuma ( @azuma_eth )
Ghi chú của biên tập viên:
Hôm qua, nhà đồng sáng lập Ethereum Vitalik đã xuất bản một bài viết mang tính đột phá về việc nâng cấp lớp thực thi của Ethereum (xem “ Bài viết mới mang tính đột phá của Vitalik: Việc mở rộng lớp thực thi đòi hỏi ‘sự đột phá’, EVM phải được lặp lại trong tương lai ”). Bài viết đề cập đến hy vọng sử dụng RISC-V để thay thế EVM làm ngôn ngữ máy ảo cho hợp đồng thông minh.
Ngay sau khi bài viết này được đăng tải, nó đã ngay lập tức gây chấn động trong cộng đồng nhà phát triển Ethereum và nhiều nhà lãnh đạo kỹ thuật đã bày tỏ ý kiến khác nhau về kế hoạch này. Ngay sau khi bài viết được xuất bản, levochka.eth, một nhà phát triển Ethereum hàng đầu, đã viết một bài viết dài bên dưới văn bản gốc để bác bỏ quan điểm của Vitalik. Ông tin rằng Vitalik đã đưa ra những giả định không chính xác về hệ thống chứng minh và hiệu suất của nó, và rằng RISC-V không thể tính đến cả khả năng mở rộng và khả năng bảo trì và có thể không phải là lựa chọn tốt nhất.
Sau đây là nội dung gốc của levochka.eth, được dịch bởi Odaily Planet Daily.
Xin đừng làm thế.
Kế hoạch này không hợp lý vì bạn đưa ra những giả định không đúng về hệ thống chứng minh và hiệu suất của nó.
Xác minh giả thuyết
Theo tôi hiểu, những lý lẽ chính cho cách tiếp cận này là khả năng mở rộng và khả năng bảo trì.
Đầu tiên, tôi muốn thảo luận về khả năng bảo trì.
Trên thực tế, tất cả các máy ảo zk RISC-V đều yêu cầu sử dụng “tiền biên dịch” để xử lý các hoạt động tính toán chuyên sâu . Bạn có thể tìm thấy danh sách SP 1 được biên dịch sẵn trong tài liệu của Succinct và bạn sẽ thấy rằng nó bao gồm hầu hết các mã lệnh tính toán quan trọng trong EVM.
Do đó, mọi sửa đổi đối với các nguyên hàm mật mã lớp cơ sở đều yêu cầu phải viết và kiểm tra các mạch mới cho các biên dịch trước này, đây là một hạn chế nghiêm trọng.
Thật vậy, nếu hiệu suất đủ tốt thì khả năng bảo trì các phần “không phải EVM” của máy khách thực thi có thể tương đối dễ dàng. Tôi không chắc liệu hiệu suất có đủ tốt hay không, nhưng tôi không tin tưởng lắm vào phần này vì những lý do sau:
Tính toán cây trạng thái thực sự có thể được tăng tốc đáng kể nhờ quá trình biên dịch trước thân thiện (như Poseidon).
Nhưng vẫn chưa rõ liệu quá trình khử tuần tự hóa có thể được xử lý theo cách tinh tế và dễ bảo trì hay không.
Ngoài ra, còn có một số chi tiết phức tạp (như đo khí và nhiều kiểm tra khác) có thể thuộc về thời gian đánh giá khối nhưng thực tế nên được phân loại là các bộ phận không phải EVM và các bộ phận này thường dễ chịu áp lực bảo trì hơn.
Tiếp theo là phần về khả năng mở rộng.
Tôi cần nhắc lại rằng không có cách nào RISC-V có thể xử lý khối lượng công việc EVM mà không sử dụng biên dịch trước, hoàn toàn không.
Vì vậy, tuyên bố trong bài viết gốc rằng thời gian chứng minh cuối cùng sẽ bị chi phối bởi các hoạt động biên dịch trước hiện tại, mặc dù về mặt kỹ thuật là đúng, nhưng lại quá lạc quan - nó giả định rằng sẽ không có biên dịch trước nào trong tương lai, trong khi thực tế (trong kịch bản tương lai này) biên dịch trước vẫn tồn tại và hoàn toàn phù hợp với các mã lệnh tốn nhiều tính toán trong EVM (chẳng hạn như ký, băm và có thể là các hoạt động tương tự số lớn).
Về ví dụ về Fibonacci, thật khó để đánh giá mà không đi sâu vào các chi tiết rất cơ bản , nhưng sức mạnh của nó ít nhất một phần đến từ:
Sự khác biệt giữa diễn giải và chi phí thực hiện;
Mở vòng lặp (giảm luồng điều khiển cho RISC-V, không chắc Solidity có thể thực hiện được điều này hay không, nhưng ngay cả một mã lệnh duy nhất vẫn sẽ tạo ra nhiều luồng điều khiển/truy cập bộ nhớ do chi phí giải thích);
Sử dụng các kiểu dữ liệu nhỏ hơn;
Tôi muốn lưu ý ở đây rằng để đạt được lợi thế của điểm 1 và 2, chi phí giải thích phải được loại bỏ. Điều này phù hợp với khái niệm RISC-V, nhưng đây không phải là RISC-V mà chúng ta đang thảo luận mà là một (?)RISC-V tương tự - nó cần có một số khả năng bổ sung, chẳng hạn như hỗ trợ khái niệm hợp đồng.
Đây là vấn đề
Vậy nên, có một số vấn đề ở đây.
Để cải thiện khả năng bảo trì, bạn cần một RISC-V (có biên dịch trước) có thể biên dịch EVM - về cơ bản đây là tình hình hiện tại.
Để cải thiện khả năng mở rộng, cần có thứ gì đó hoàn toàn khác - một kiến trúc mới, có thể giống như RISC-V, hiểu được khái niệm hợp đồng, tương thích với những hạn chế của thời gian chạy Ethereum và có thể thực thi trực tiếp mã hợp đồng (mà không cần chi phí giải thích).
Tôi cho rằng hiện tại bạn đang nói đến trường hợp thứ hai (vì phần còn lại của bài đăng có vẻ ám chỉ điều đó). Tôi xin lưu ý rằng tất cả mã bên ngoài môi trường này vẫn sẽ được viết bằng ngôn ngữ zkVM RISC-V hiện tại, điều này có ý nghĩa quan trọng trong việc bảo trì.
Các khả năng khác
Chúng ta có thể biên dịch bytecode từ opcode EVM cấp cao. Trình biên dịch có trách nhiệm đảm bảo rằng chương trình được tạo ra sẽ bảo toàn các bất biến, chẳng hạn như ngăn chặn tràn ngăn xếp. Tôi muốn thấy điều này được chứng minh trong EVM nguyên bản. Có thể cung cấp SNARK được biên dịch đúng cách cùng với hướng dẫn triển khai hợp đồng.
Chúng ta cũng có thể xây dựng một “bằng chứng chính thức” chứng minh rằng một số bất biến nhất định là đúng. Theo như tôi biết, cách tiếp cận này (thay vì ảo hóa) đã được sử dụng trong một số ngữ cảnh trình duyệt. Bằng cách tạo ra SNARK của bằng chứng chính thức này, bạn có thể đạt được kết quả tương tự.
Tất nhiên, lựa chọn dễ nhất là cứ thực hiện thôi...
Xây dựng một MMU xích tối thiểu
Bạn có thể đã ám chỉ điều này trong bài đăng của mình, nhưng hãy để tôi nhắc lại: nếu bạn muốn loại bỏ chi phí ảo hóa, bạn phải thực thi trực tiếp mã đã biên dịch - nghĩa là bạn cần phải ngăn chặn hợp đồng (bây giờ là một chương trình thực thi) ghi vào bộ nhớ kernel (không phải triển khai EVM).
Do đó, chúng ta cần một loại Đơn vị quản lý bộ nhớ (MMU). Cơ chế phân trang của máy tính truyền thống có thể không cần thiết vì không gian bộ nhớ vật lý gần như vô hạn. MMU này phải càng tinh gọn càng tốt ( vì nó ở cùng cấp độ trừu tượng với chính kiến trúc ), nhưng một số chức năng (như tính nguyên tử của giao dịch ) có thể được chuyển đến lớp này.
Tại thời điểm này, EVM có thể chứng minh được sẽ trở thành chương trình hạt nhân chạy trên kiến trúc này.
RISC-V có thể không phải là lựa chọn tốt nhất
Điều thú vị là, trong tất cả những điều kiện này, kiến trúc tập lệnh (ISA) tốt nhất cho nhiệm vụ này có thể không phải là RISC-V, mà là thứ gì đó tương tự như EOF-EVM , vì những lý do sau:
Các mã lệnh “nhỏ” thực sự dẫn đến số lượng lớn các lần truy cập bộ nhớ, rất khó để xử lý hiệu quả bằng các phương pháp chứng minh hiện có.
Để giảm chi phí phân nhánh, bài báo gần đây của chúng tôi Morgana cho thấy cách chứng minh mã bằng bước nhảy tĩnh ( tương tự như EOF ) ở hiệu suất cấp độ tiền biên dịch.
Đề xuất của tôi là xây dựng một kiến trúc mới thân thiện với bằng chứng, với MMU tối thiểu cho phép chạy hợp đồng dưới dạng các tệp thực thi riêng biệt. Tôi không nghĩ nó nên là RISC-V, mà là một ISA mới được tối ưu hóa cho các ràng buộc của giao thức SNARK , hoặc thậm chí là một ISA kế thừa một phần tập hợp con các mã lệnh EVM có thể sẽ tốt hơn - như chúng ta đã biết, biên dịch trước sẽ vẫn tồn tại dù chúng ta có thích hay không, do đó RISC-V không mang lại bất kỳ sự đơn giản hóa nào ở đây.
