Các nhà phát triển bác bỏ Vitalik: các giả định là sai và RISC-V không phải là lựa chọn tốt nhất

Bài viết này từ: Nhà phát triển Ethereum levochka.eth

compilation|Odaily Planet Daily (@OdailyChina); @azuma_eth Ghi chú của biên tập viên

:

Hôm qua, người đồng sáng lập Ethereum Vitalik đã phát hành một bài báo triệt để về việc nâng cấp lớp thực thi của Ethereum (xem "Bài viết mới triệt để của Vitalik: Mở rộng lớp thực thi "Không bị phá vỡ, không đứng", EVM phải được lặp lại trong tương lai), đề cập rằng ông hy vọng sẽ thay thế nó bằng RISC-V EVM như một ngôn ngữ máy ảo cho các hợp đồng thông minh.

Ngay sau khi bài viết này được công bố, nó ngay lập tức gây náo động trong cộng đồng nhà phát triển Ethereum và nhiều ông lớn về kỹ thuật đã bày tỏ quan điểm khác nhau về kế hoạch này. Ngay sau khi bài báo được xuất bản, nhà phát triển Ethereum cấp 1 levochka.eth đã viết một bài báo dài bên dưới bài báo gốc bác bỏ lập luận của Vitalik rằng Vitalik đã đưa ra các giả định sai lầm về hệ thống chứng minh và hiệu suất của nó, và RISC-V có thể không phải là lựa chọn tốt nhất vì nó không thể cân bằng "khả năng mở rộng" và "khả năng bảo trì".

Sau đây là bài viết gốc trên levochka.eth, được biên soạn bởi nhật báo Odaily.

Xin đừng làm điều này.

Kế hoạch này không có ý nghĩa, bởi vì bạn đang đưa ra những giả định sai lầm về việc chứng minh hệ thống và hiệu suất của nó.

Giả thuyết xác thực

tôi hiểu, các lập luận chính cho sơ đồ này là "khả năng mở rộng" và "khả năng bảo trì".

Đầu tiên, tôi muốn nói về khả năng bảo trì.

Trên thực tế, tất cả các máy ảo RISC-V zk đều yêu cầu "biên dịch trước" để xử lý các hoạt động sử dụng nhiều điện toán. Danh sách SP 1 được biên soạn sẵn có thể được tìm thấy trong tài liệu của Succinct và bạn sẽ thấy rằng nó bao gồm hầu hết tất cả các opcode "tính toán" quan trọng trong EVM.

Kết quả là, tất cả các sửa đổi đối với các nguyên thủy mật mã lớp cơ sở đều yêu cầu các "mạch" mới được viết và kiểm tra cho các quá trình biên dịch trước, đây là một hạn chế nghiêm trọng.

Thật vậy, nếu hiệu suất đủ tốt, có thể tương đối dễ dàng thực hiện khả năng phục vụ của phần "không phải EVM" của máy khách. Tôi không chắc liệu nó có đủ tốt hay không, nhưng tôi kém tự tin hơn về 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 rất nhiều với tính năng biên dịch trước thân thiện như Poseidon.

• Tuy nhiên, không rõ liệu "deserialization" có thể được xử lý một cách thanh lịch và có thể duy trì hay không.
  

• Ngoài ra, có một số chi tiết phức tạp (chẳng hạn như đo khí và các kiểm tra khác nhau) có thể thuộc "thời gian đánh giá khối" nhưng thực sự nên được phân loại là các bộ phận "không phải EVM", có xu hướng dễ bị tổn thương hơn bởi áp lực bảo trì.

Thứ hai, phần về khả năng mở rộng.

Tôi cần nhắc lại rằng RISC-V không thể xử lý tải 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 văn bản gốc rằng "thời gian chứng minh cuối cùng sẽ bị chi phối bởi hoạt động biên dịch trước hiện tại" là đúng về mặt kỹ thuật, nhưng nó quá lạc quan - nó giả định rằng sẽ không có quá trình biên dịch trước trong tương lai, trong khi trên thực tế (trong kịch bản tương lai này) tiền biên dịch sẽ vẫn tồn tại và hoàn toàn giống với các opcode chuyên sâu về tính toán trong EVM (chẳng hạn như chữ ký, hàm băm và có thể là các chất tương tự lớn).

Thật khó để đánh giá ví dụ Fibonacci mà không đi sâu vào các chi tiết tinh tế nhất, nhưng những lợi thế ít nhất đến một phần:

• sự khác biệt giữa Giải thích và chi phí thực hiện;

• Tháo cuộn theo chu kỳ (giảm "luồng điều khiển" của RISC-V, không chắc chắn liệu Solidity có thể được triển khai hay không, nhưng ngay cả một opcode duy nhất vẫn có thể tạo ra một số lượng lớn luồng điều khiển / truy cập bộ nhớ do chi phí diễn giải);

• sử dụng các kiểu dữ liệu nhỏ hơn;

Ở đây tôi muốn chỉ ra rằng để nhận ra lợi ích của điểm 1 và điểm 2, "chi phí giải thích" phải được loại bỏ. Điều này phù hợp với triết lý của 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ó đòi hỏi một số khả năng bổ sung, chẳng hạn như hỗ trợ cho các khái niệm hợp đồng.

Đây là vấn đề

, vì vậy, 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ó tính năng biên dịch trước) biên dịch EVM - đó là khá nhiều.

• Để cải thiện khả năng mở rộng, cần có một cái gì đó hoàn toàn khác – một kiến trúc mới có thể tương tự như RISC-V hiểu khái niệm "hợp đồng", tương thích với các giới hạn thời gian chạy Ethereum và có thể thực thi mã hợp đồng trực tiếp (mà không có "chi phí diễn giải").

Bây giờ tôi cho rằng bạn đang đề cập đến trường hợp thứ hai (vì phần còn lại của bài viết dường như ngụ ý điều đó). Tôi cần thu hút sự chú ý của bạn đến thực tế là 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ữ RISC-V zkVM hiện tại, điều này có tác động đáng kể đến việc bảo trì.

Thay vào đó,

chúng ta có thể biên dịch bytecode từ opcode EVM cấp cao. Trình biên dịch chịu trách nhiệm đảm bảo rằng trình tạo vẫn bất biến, chẳng hạn như không gặp phải "tràn ngăn xếp". Tôi muốn thấy điều này được hiển thị trong một EVM bình thường. Các SNARK được biên dịch đúng cách có thể được cung cấp 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 được bảo tồn. Theo như tôi có thể nói, cách tiếp cận này (không phải "ảo hóa") đã được sử dụng trong một số ngữ cảnh trình duyệt. Bằng cách tạo 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ắn đạn và làm ......

Xây dựng một MMU "chuỗi" tối thiểu

, mà bạn có thể thể hiện một cách ngầm trong bài viết, nhưng hãy để tôi cảnh báo rằng nếu bạn muốn loại bỏ chi phí ảo hóa, bạn phải thực thi mã đã biên dịch trực tiếp - có nghĩa là bạn cần phải bằng cách nào đó ngăn hợp đồng (hiện đang thực thi) ghi vào bộ nhớ hạt nhân (không phải triển khai EVM).

Do đó, chúng ta cần một số 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 tinh gọn nhất có thể (vì nó ở cùng mức độ trừu tượng hóa với chính kiến trúc), nhưng một số tính năng như tính nguyên tử của các giao dịch có thể được chuyển sang lớp này.

Tại thời điểm này, EVM có thể chứng minh 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ả các đ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à một cái gì đó tương tự như EOF-EVM vì những lý do sau:

• Opcode "nhỏ" thực sự dẫn đến nhiều truy cập bộ nhớ, điều này khó xử lý hiệu quả đối với các phương pháp chứng thực hiện có.

• Để giảm chi phí phân nhánh, chúng tôi đã chỉ ra cách chứng minh mã "nhảy tĩnh" (EOF) với hiệu suất ở cấp độ tiền biên dịch trong bài báo gần đây của chúng tôi, Morgana.

Đề xuất của tôi là xây dựng một kiến trúc thân thiện với bằng chứng mới với MMU tối thiểu cho phép hợp đồng chạy như một tệp thực thi riêng biệt. Tôi không nghĩ rằng nó được cho là RISC-V, mà là một ISA mới được tối ưu hóa cho các hạn chế của giao thức SNARK và thậm chí một ISA kế thừa một phần tập hợp con của các opcode EVM có thể tốt hơn - như chúng ta đã biết, biên dịch trước vẫn ở đây, cho dù chúng ta có thích hay không, vì vậy RISC-V không mang lại bất kỳ sự đơn giản hóa nào ở đây.