Vitalik đấu các nhà phát triển hàng đầu: Cuộc họp bàn tròn ảo về cuộc tranh luận máy ảo Web3
Tuyển chọn TechFlowTuyển chọn TechFlow
Vitalik đấu các nhà phát triển hàng đầu: Cuộc họp bàn tròn ảo về cuộc tranh luận máy ảo Web3
EVM theo đuổi sự tương thích hệ sinh thái, RISC-V tập trung vào hiệu suất phần cứng, WASM hướng tới phát triển đa ngôn ngữ, MoveVM nhấn mạnh an toàn tài sản, còn FuelVM thì đột phá giới hạn hiệu năng.
Chuyên sâu báo cáo Web3Mỗi blockchain đều có những điểm nổi bật và câu chuyện riêng biệt, về mặt kỹ thuật thì các mô-đun mã nguồn của blockchain là tương tự nhau, đều bao gồm giao tiếp nút, đạt đồng thuận và thực thi, nhưng mỗi hệ thống lại chọn công nghệ và thuật toán phù hợp nhất với mình, đặc biệt là thuật toán đồng thuận và công nghệ máy ảo ở tầng thực thi. Gần đây, Ethereum muốn chuyển từ mã nút EVM sang tập lệnh RISC-V khiến lĩnh vực công nghệ tương đối kín đáo này được công chúng biết đến nhiều hơn.
Hai ngày trước, tôi đã tổng hợp một bài viết phổ biến kiến thức về RISC-V để mọi người hiểu rõ quá khứ và tương lai của nó.
EVM thành RISC-V? Cùng tìm hiểu về lịch sử hình thành, phát triển và ứng dụng trong lĩnh vực Web3 của RISC-V
Ngày hôm nay, tôi mong muốn toàn diện và tổng hợp hơn nữa để chia sẻ với mọi người một số nội dung liên quan đến máy ảo. Bản thân tôi không chuyên sâu nghiên cứu học tập về máy ảo, nên tôi sẽ mượn ý tưởng thiết kế hoặc nhận xét từ các chuyên gia hàng đầu về máy ảo trên mạng Internet, sau đó tổng hợp lại để mọi người có thể hiểu được sự khác biệt giữa các loại máy ảo.
Khi sắp xếp tài liệu, tôi cảm thấy sự va chạm quan điểm này đặc biệt giống thời kỳ Chiến Quốc nhà Xuân Thu ở Trung Quốc khi trăm nhà tranh luận. Vì vậy, tôi chợt nảy ra ý tưởng kết hợp cách diễn đạt của họ theo định dạng hội nghị tròn / Space đang thịnh hành hiện nay, trình bày một "cuộc họp bàn tròn ảo" cho mọi người, làm nổi bật động thái "tranh luận", quân tử hòa mà không đồng nhất.
Để nắm bắt nhanh các luận điểm cốt lõi, phần này so sánh ngang qua bảng biểu cấu trúc các đặc tính chính của các máy ảo Web3 chủ lưu, tóm tắt từ cuộc thảo luận sâu sắc của hơn 10 lãnh đạo kỹ thuật trong toàn văn.
Bao gồm kiến trúc thiết kế, hiệu suất và thách thức triển khai của 9 loại giải pháp như RISC-V, WASM, EVM: (lướt trái phải để xem bảng đầy đủ)
Năm 2024, đề xuất thay thế EVM bằng RISC-V trong cộng đồng Ethereum gây ra tranh luận dữ dội, chúng tôi mời ảo hóa các nhà thiết kế VM thuộc các trường phái khác nhau, tranh luận trực diện trên các khía cạnh như bản chất kỹ thuật, tính thích nghi sinh thái, tính thân thiện ZK...
Người dẫn chương trình: Trước tiên xin chào đón @VitalikButerin[1], đồng sáng lập Ethereum, EVM là máy ảo mang tính đột phá, giờ đây mọi người đều biết anh muốn đổi mới tốt hơn, anh có thể nói thêm với chúng tôi không?
@VitalikButerin: Chào các bạn网友! Tôi là Vitalik, bạn网友 Trung Quốc thường gọi tôi là "tiểu v" (cười~). Mọi người đều biết gần đây tôi đã đưa ra đề xuất EVM -> RISC-V, mọi người có thể vào diễn đàn đọc bản gốc [2] (bản tiếng Trung [3]), ở đây tôi sẽ không lặp lại, chỉ nói một vài điểm chính:
• Ý tưởng dùng RISC-V thay thế EVM làm ngôn ngữ máy ảo để viết hợp đồng thông minh tuy có phần cực đoan ——thực tế, đây có lẽ là con đường duy nhất để đạt được mục tiêu này.
• Mở rộng L1 Ethereum tồn tại một số yếu tố hạn chế, trong đó hiệu quả thực thi là một trong những nút thắt chính, chúng ta cần nâng cao hiệu quả và đơn giản hóa đáng kể tầng thực thi.
• Hợp đồng EVM cũ sẽ tiếp tục chạy, hoàn toàn tương thích hai chiều với hợp đồng RISC-V mới. Có nhiều cách thực hiện:
• Phương án ít phá hoại nhất là hỗ trợ đồng thời cả hai máy ảo.
• Phương pháp táo bạo hơn là chuyển đổi hợp đồng EVM hiện tại thành việc gọi hợp đồng trình thông dịch EVM được viết bằng RISC-V để chạy mã EVM hiện tại.
• Thông qua giao thức hỗ trợ rõ ràng 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à ví dụ đầu tiên.
• Tương lai còn có thể hỗ trợ các ngôn ngữ khác (Move có thể là ứng cử viên).
• Trải nghiệm phát triển có thể hầu như không bị ảnh hưởng, thậm chí nhà phát triển có thể không nhận ra sự thay đổi.
• Nervos CKB VM đã đi tiên phong, về bản chất chính là thực hiện RISC-V[4].
Người dẫn chương trình: Cảm ơn @VitalikButerin đã chia sẻ kế hoạch mới nhất của Ethereum với chúng tôi, tôi thấy rất nhiều người bày tỏ ủng hộ trong bài đăng gốc, cũng có một bộ phận cho rằng phương án cần nghiên cứu thêm, do chủ đề lần này là thảo luận ưu nhược điểm ngang hàng của máy ảo, chúng ta sẽ không đi sâu vào chi tiết khả thi của RISC-V trong bài gốc. Tất nhiên, chúng tôi cũng mời một số khách mời phù hợp chủ đề này tham gia các chủ đề bên dưới.
Người dẫn chương trình: Xin mời vị khách mời thứ hai hôm nay của chúng tôi: @IAmNickDodson[5], Fuel Network[6] người sáng lập & CEO, cựu thành viên ConsenSys, tham gia phát triển cơ sở hạ tầng và công cụ Ethereum, tham gia sâu vào tối ưu hóa các client Ethereum (như Geth hay Parity), là người có nhiều kinh nghiệm và tiếng nói trong thiết kế và thực hiện VM.
@IAmNickDodson: Trước hết, bài viết của Vitalik thật đáng phấn khích. Tôi bắt đầu tiếp xúc với EVM từ trước khi mainnet Ethereum lên sóng, có thể khẳng định chắc chắn —— lúc đó chúng tôi đã biết nó có khuyết điểm, đến nay những vấn đề này vẫn tồn tại. Nhưng không thể phủ nhận, nó đã trở thành nền tảng xây dựng ứng dụng phi tập trung thực sự, chúng tôi rất biết ơn điều này. [src[7]]
Người dẫn chương trình: Xin hỏi vì sao các anh chọn phát triển FuelVM thay vì áp dụng các giải pháp sẵn có khác?
@IAmNickDodson: Khi thiết kế FuelVM, chúng tôi đã nghiên cứu nhiều kiến trúc: Kiến trúc tập lệnh (ISA): MIPS, RISC-V, x86, ARM, các phương án máy ảo: WASM, và các VM chuyên dụng blockchain: EVM, BitcoinScript, MoveVM, SVM v.v. Mỗi cái đều có điểm mạnh, nhưng không cái nào hoàn toàn đáp ứng nhu cầu của chúng tôi, lát nữa tôi sẽ chia sẻ phân tích và suy nghĩ của mình về các lựa chọn này. Trước đó, tôi hy vọng bạn trước màn hình cũng cùng suy nghĩ ba câu hỏi cốt lõi này: Kiến trúc này có được thiết kế riêng cho tình huống blockchain không? Có thể duy trì hiệu suất trong môi trường tính phí đối kháng không? Có thực sự cải tiến so với EVM không? [src[8]]
Người dẫn chương trình: Được rồi, cảm ơn lời giới thiệu bản thân của các vị khách mời trên, tiếp theo chúng ta sẽ chọn một số dự án / công nghệ VM tiêu biểu theo trình tự nghiên cứu của @IAmNickDodson, xin mỗi vị chia sẻ quan điểm và phân tích, nếu có quan điểm khác xin cứ tham gia bất cứ lúc nào.
MIPS/RISC-V
@IAmNickDodson: Các tập lệnh CPU này ban đầu được thiết kế cho vi mạch sớm và thiết bị nhúng
Ưu điểm là:kiến trúc đơn giản, tài liệu đầy đủ, hệ sinh thái mã nguồn mở, có thể biên dịch thành mã máy gốc (đôi khi cần xử lý bổ sung) vàhỗ trợ đa ngôn ngữ (Rust/Go v.v.).
Nhược điểm là:bản chất là tập lệnh CPU (không phải kiến trúc tính toán ảo), tập lệnh MIPS quá cơ bản, để hoàn thành chức năng một lệnh đơn của x86 hoặc VM chuyên dụng cần nhiều opcode hơn (xem phần CISC phía sau) ,chưa tính đến việc tính phí trong môi trường đối kháng, chưa tối ưu cho tình huống blockchain, hiệu suất xử lý bằng chứng kiến thức không (ZK) thấp (tham khảo nghiên cứu của Starkware/Valida).
Dù công nghệ ZK có thể giảm nhu cầu tính phí nút, trong tình huống thông lượng cao vẫn cần tính toán trước / chia sẻ bằng chứng, lúc đó vẫn cần cơ chế chống DoS (việc tính phí vẫn có giá trị). [src[9]]
Georgios Konstantopoulos[10] (CTO kiêm đối tác Paradigm[11]) Nếu bạn thích đề xuất của @VitalikButerin, vậy bạn chắc chắn sẽ thích R55 mà chúng tôi âm thầm phát triển trong vài tháng qua... [src[13]]
0xpedro.eth/acc[14]: R55 cho phép bạn viết hợp đồng thông minh thuần bằng Rust và thực thi trong client Ethereum thông qua RISC-V. Thông thường Solidity sẽ biên dịch thành bytecode EVM, nhưng R55 sẽ biên dịch Rust thành lệnh RISC-V, đây là một khuôn khổ mã nguồn mở có thể giải phóng tiềm năng tối ưu phần cứng. Dùng Rust trên Ethereum? Thú vị nhưng khó khăn. Bản thân RISC-V không hiểu trạng thái Ethereum (lưu trữ, gọi v.v.), vì vậy R55 thêm các lệnh gọi hệ thống. Sử dụng ecall của RISC-V, hợp đồng Rust có thể đọc lưu trữ (ví dụ SLOAD), gọi hợp đồng hoặc gửi nhật ký —— từ đó nối liền Rust với Ethereum một cách liền mạch.
R55 vẫn đang phát triển, cần điều chỉnh gas và bảo mật, nhưng tương lai rất hấp dẫn: rollup hoặc chuỗi ứng dụng có thể chạy hợp đồng Rust gốc, hoặc zkEVM có thể tận dụng RISC-V cho thao tác mã hóa. Theo tôi, tính an toàn và tốc độ của Rust khiến nó trở thành vũ khí lợi hại cho Ethereum. R55 có thể mang đến làn sóng nhà phát triển Rust cho Ethereum không? Có lẽ bây giờ còn quá sớm, nhưng đáng để theo dõi. [src[15]]
Dave Rauchwerk[16]: @VitalikButerin Đây là một ý tưởng tuyệt vời. Một lợi thế then chốt của RISC-V là khả năng mở rộng rõ ràng. Chúng ta nên nghiên cứu định nghĩa một bộ lệnh RISC-V tùy chỉnh, chuyên dùng để tăng tốc các opcode hoạt động trọng yếu hiệu suất của EVM. Đặc tính mở của RISC-V cho phép thực hiện bằng phần cứng chuyên dụng (ASIC, FPGA) ngoài thực thi CPU thông thường. Điều này tạo ra con đường nâng cao đáng kể TPS L1 thông qua việc tăng tốc trực tiếp logic EVM cốt lõi trong silicon, tốc độ có thể nhanh hơn nhiều bậc so với phương pháp giải thích phần mềm hoặc JIT hiện tại.
Xác minh và bảo mật: So với ISA truyền thống phức tạp, thiết kế mô-đun và gọn nhẹ của RISC-V dễ xác minh hình thức hơn. Một nhân RISC-V đã xác minh hình thức thực thi logic EVM có thể đảm bảo hành vi runtime mạnh mẽ hơn, điều này rất quan trọng để bảo vệ an toàn hợp đồng thông minh giá trị cao. RISC-V có thể được tăng cường bằng lệnh tùy chỉnh lấy EVM làm trung tâm, tạo ra con đường hấp dẫn hướng tới lớp 1 hiệu suất cao hơn, an toàn hơn và mở rộng tốt hơn.
Thêm nữa, hãy so sánh benchmark giữa thực hiện EVM hiện tại và mô hình phần mềm RISC-V tiềm năng. revive/PolkaVM trông rất tuyệt - hiện tại chỉ hỗ trợ RV32EM, đáng để thảo luận. [src[17]]
Koute[18] (người phụ trách PolkaVM tại Parity Technologies[19]): Vừa nhắc đến PolkaVM, vậy tôi sẽ giải thích chi tiết PolkaVM là gì và nguyên lý hoạt động của nó.
PolkaVM hiện tại hỗ trợ riscv64emac với mở rộng Zbb, nhưng khác với hầu hết (tất cả?) các máy ảo RISC-V khác, nó không thể chạy tệp nhị phân RISC-V nguyên bản (thực tế nó không phải là máy ảo RISC-V!). Ngoại tuyến, chúng tôi sẽ trích xuất tệp nhị phân ELF RISC-V bình thường do bạn xây dựng bằng trình biên dịch thông thường, sau đó chuyển đổi thành bytecode tùy chỉnh bị ràng buộc hơn, hiệu quả hơn, được thiết kế riêng cho việc sử dụng máy ảo (chứ không phải phần cứng gốc như RISC-V). Ý tưởng của chúng tôi là loại bỏ tối đa độ phức tạp của bản thân máy ảo (cần chạy trên chuỗi), đưa càng nhiều độ phức tạp càng tốt vào công cụ ngoại tuyến (có thể chạy ngoài chuỗi), đồng thời nâng cao bảo mật bằng cách xóa các chức năng không cần thiết (ví dụ, trong RISC-V gốc, bạn có thể nhảy đến bất kỳ địa chỉ nào; trong bytecode PolkaVM, không gian địa chỉ mã hoàn toàn ảo hóa, bạn không thể nhảy đến đâu tùy ý, và bytecode thậm chí sẽ không được tải vào bộ nhớ truy cập được bởi chương trình).
Về hiệu suất, chúng tôi rất gần với hiệu suất máy trần[1]; nhanh như VM WASM tiên tiến nhất * wasmtime nhưng đảm bảo thời gian biên dịch lại O(n) và tăng tốc độ biên dịch lại chương trình thành mã gốc hàng trăm lần. Cụ thể, bắt đầu từ bytecode PolkaVM gốc để biên dịch lại chương trình thành mã gốc nhanh hơn nhiều so với việc lưu lại artifact đã biên dịch lại và tra cứu theo hash của nó (nói cách khác, biên dịch lại chương trình nhanh hơn tính toán hash của nó), và điều này còn không * hy sinh hiệu suất thực thi runtime.
Chúng tôi chủ yếu sử dụng RISC-V không phải vì nó là bytecode đặc biệt tốt cho VM (thực tế nó không quá tốt), mà vì nó đơn giản, được hỗ trợ tốt và tương đối dễ chuyển đổi sang thứ khác, nhờ đó chúng tôi có thể vừa có lợi ích kép —— tương thích phần mềm tuyệt vời (bạn có thể sử dụng trình biên dịch và ngôn ngữ lập trình hiện có, ví dụ vài ngày trước tôi đã di chuyển Quake sang PolkaVM), nhưng bạn cũng nhận được lợi ích của bytecode tùy chỉnh, tối ưu hóa (tốc độ biên dịch cực nhanh, hiệu suất gần bằng máy trần, tính đơn giản và khả năng tùy chỉnh). [src[20]]
dilrong[21]: @VitalikButerin tuyên bố rằng thay thế Máy ảo Ethereum (EVM) bằng RISC-V có thể nâng cao hiệu suất bằng chứng kiến thức không (ZK) từ 50 đến 100 lần. Tuy nhiên, RISC-V thực sự vượt trội hơn sao? EVM đã vận hành ổn định khoảng chín năm, là một nền tảng đã được kiểm chứng, trong khi RISC-V thiếu kinh nghiệm thực tiễn phong phú trong môi trường thực thi blockchain. Mặc dù PolkaVM đã áp dụng RISC-V, nhưng tôi cho rằng nó chưa được xác minh đầy đủ vì chưa được kiểm chứng kỹ lưỡng trên mainnet.
EVM được tối ưu hóa riêng cho việc thực thi hợp đồng thông minh, trong khi RISC-V được thiết kế làm kiến trúc chung, có thể thiếu tối ưu hóa tùy chỉnh cho trường hợp sử dụng blockchain. Mặc dù tính linh hoạt của RISC-V cho phép sử dụng ngôn ngữ lập trình của các blockchain khác, nhưng chính Vitalik chỉ ra rằng cải tiến dựa trên Solidity hiện có là lựa chọn ưu việt hơn. Việc chuyển đổi toàn bộ hệ sinh thái sang kiến trúc mới là một thử thách lớn.
Thực hiện RISC-V trong phần mềm không tránh khỏi việc giảm hiệu suất. Việc thực thi dựa trên phần mềm bằng bộ mô phỏng đặt ra câu hỏi về khả năng xử lý nhiệm vụ hiệu quả. Mặt khác, việc áp dụng phần cứng RISC-V sẽ tạo ra chi phí chuyển đổi khổng lồ. Tôi cho rằng ZK-EVM đã có thể đáp ứng nhu cầu hiện tại. Xét về chi phí phát triển, khối lượng công việc chuyển đổi và khả năng xảy ra lỗi không lường trước, việc thay thế EVM bằng RISC-V dường như không phải là một giải pháp khả thi.
Mặc dù chuyển đổi sang RISC-V có thể mang lại lợi ích tiềm năng, tôi cho rằng cải tiến ZK-EVM và tối ưu hóa EVM hiện tại là các giải pháp thay thế thực tế và ổn định hơn. [src[22]]
Eduardo Bart[23] (nhà phát triển cốt lõi VM Cartesi[24]): Là một nhà phát triển tích cực tham gia phát triển máy ảo RISC-V dành cho ứng dụng blockchain – Cartesi Machine[25], tôi muốn chia sẻ một số quan điểm ủng hộ việc khám phá RISC-V trong tầng thực thi Ethereum.
Tôi cho rằng một trong những lợi thế lớn nhất khi áp dụng RISC-V là có thể truy cập ngay lập tức vào các công cụ và hệ sinh thái trưởng thành. Không cần xây dựng môi trường hoàn toàn tùy chỉnh, việc sử dụng RISC-V cho phép các nhà phát triển (và giao thức cốt lõi) tận dụng tối đa kinh nghiệm tích lũy hàng thập kỷ từ các trình biên dịch như GCC và LLVM, trình gỡ lỗi, thư viện, thậm chí cả hệ điều hành đầy đủ như Linux. So với các chuỗi công cụ mới hơn, chưa được kiểm chứng thực tiễn, điều này giảm đáng kể rào cản cho nhà phát triển và có thể giảm rủi ro do lỗi trình biên dịch. Điều này rất phù hợp với mục tiêu cho phép các hợp đồng viết bằng ngôn ngữ như Rust hay thậm chí C++ được biên dịch thông qua backend chuẩn, nhằm mục tiêu Ethereum. Đối với những người nghi ngờ về lỗi trong LLVM hay GCC, việc sử dụng trình biên dịch đã được xác minh hình thức như CompCert[26] hiện có thể nhắm mục tiêu RISC-V để tăng cường an ninh là khả thi. Nhìn xa hơn, thậm chí có thể chạy ứng dụng trên nhân hệ điều hành RISC-V đã được xác minh chính thức (ví dụ seL4[27]) trong máy ảo (ví dụ như tôi đang phát triển) bao gồm đặc tả ISA đặc quyền RISC-V, đây là một khả năng cho các ứng dụng phức tạp hơn yêu cầu chạy trong môi trường hệ điều hành.
Những lo ngại về hiệu suất do một số người nêu ra không phải là vô căn cứ, nhưng có thể giải quyết. Theo kinh nghiệm của tôi, RISC-V khi được thực hiện đúng cách sẽ không hy sinh hiệu suất thực thi. Mặc dù các thao tác u256 tự nhiên sẽ phân tách thành nhiều lệnh, nhưng trong thực tế, trong một máy ảo RISC-V được tối ưu hóa tốt, chi phí này trong hầu hết các trường hợp không ảnh hưởng quá nhiều đến hiệu suất. Hơn nữa, các kỹ thuật tối ưu hóa ở cấp độ máy ảo có thể giảm đáng kể chi phí này, vì ISA RISC-V đủ linh hoạt để thêm các phần mở rộng tùy chỉnh dành riêng cho blockchain, từ đó tối ưu hóa các thao tác mã hóa phổ biến (ví dụ Keccak256).
Tôi cho rằng xây dựng tầng thực thi tương lai trên một ISA chuẩn hóa, mở và được hỗ trợ tốt như RISC-V sẽ cung cấp nền tảng vững chắc. Nó mở ra con đường tận dụng hệ sinh thái phần mềm hiện có, có thể đơn giản hóa trải nghiệm nhà phát triển và hưởng lợi từ những tiến bộ phần cứng tương lai trong lĩnh vực RISC-V.
Dù con đường phức tạp, tôi tin rằng những lợi thế tiềm năng của RISC-V về khả năng mở rộng, độ trưởng thành của công cụ và khả năng bảo trì dài hạn khiến nó trở thành một hướng đi rất đáng theo đuổi cho môi trường thực thi blockchain trong tương lai. Hiện tại, nhiều máy ảo RISC-V blockchain hiện hữu chứng minh rằng việc thực hiện RISC-V bền vững và sẵn sàng sản xuất là khả thi. Cụ thể, tôi cho rằng Cartesi Machine thể hiện sức mạnh của việc tận dụng ISA mở chuẩn. Đây là một bộ mô phỏng RISC-V ổn định, hiệu suất cao, thực hiện ISA RV64GC chuẩn, có thể chạy toàn bộ ngăn xếp phần mềm Linux và các tệp nhị phân ELF RV64GC chưa sửa đổi. Quan trọng là, nó hoàn toàn xác định, thậm chí cả thao tác dấu phẩy động. Đối với những ai tò mò và muốn tìm hiểu khả năng vận hành của nó, tôi khuyên dùng thử nghiệm WebCM[28] của tôi, một terminal không máy chủ, chạy Linux ảo trực tiếp trong trình duyệt thông qua mô phỏng máy RISC-V do bộ mô phỏng Cartesi Machine biên dịch thành WebAssembly điều khiển.
Hiện tại, đề xuất L1 tập trung vào bằng chứng kiến thức không, trong khi Cartesi hiện tại đạt được xác minh trên chuỗi thông qua bằng chứng gian lận tương tác, tận dụng thực thi xác định và bằng chứng Merkle trạng thái. Mặc dù cơ chế xác minh khác nhau, Cartesi xác nhận rằng xây dựng môi trường thực thi xác minh được và xác định trên RISC-V là khả thi và đáng giá.
Tất nhiên, tích hợp trực tiếp RISC-V vào L1 và thực hiện bằng chứng kiến thức không sẽ mang lại những thách thức độc đáo và nghiêm trọng, đặc biệt trong việc tính phí Gas, định nghĩa lệnh gọi hệ thống chính xác cho tương tác trạng thái và tối ưu hóa mạch kiến thức không cho lệnh RISC-V. Hiệu suất trong môi trường bằng chứng kiến thức không cụ thể cũng cần nghiên cứu sâu. May mắn thay, nhiều dự án máy ảo RISC-V kiến thức không đã đang nghiên cứu và phát triển các khía cạnh này.
Về chiến lược thực hiện, tôi cho rằng nên cân nhắc nghiêm túc một "phương pháp táo bạo", tức là định nghĩa một giao thức, đưa khái niệm trình thông dịch máy ảo được biên dịch thành RISC-V vào đó. Phương pháp này sẽ mở ra con đường, giúp máy ảo RISC-V cốt lõi của Ethereum giữ mức tối thiểu và đơn giản, đồng thời vẫn đủ linh hoạt để chứa các trình thông dịch máy ảo khác ngoài EVM, từ đó mang lại tự do hơn cho nhà phát triển trong phát triển máy ảo.
Tóm lại, tôi tin rằng việc tận dụng một chuẩn như RISC-V mang lại lợi thế to lớn về công cụ, sự quen thuộc của nhà phát triển, tính linh hoạt, thậm chí cả tiềm năng tăng tốc phần cứng dài hạn. Kinh nghiệm làm việc với Cartesi Machine củng cố quan điểm rằng RISC-V là nền tảng mạnh mẽ và khả thi cho thế hệ tiếp theo của tính toán blockchain xác minh được. Tôi rất hào hứng khi thấy nó được xem xét nghiêm túc cho tầng thực thi cốt lõi của Ethereum. [src[29]]
Xuejie Xiao[30]: Xin chào mọi người, tôi là người thiết kế ban đầu và hiện là người duy trì CKB-VM của Nervos. Theo quan điểm Nervos, việc chọn CKB-VM hoàn toàn dựa trên tư duy nguyên lý đầu tiên: chúng tôi muốn một hộp cát đơn giản, an toàn, nhanh chóng, và chạy nhẹ nhất có thể trên CPU thương mại. Thực tế chứng minh, tập lệnh CPU là lựa chọn tốt nhất, và RISC-V nổi bật giữa các lựa chọn khác, tất nhiên còn có các nhân RISC CPU mã nguồn mở khác, nhưng theo chúng tôi, RISC-V được chú ý nhiều nhất, điều này có nghĩa sẽ có nhiều người tham gia phát triển chuỗi công cụ. Với chúng tôi, đây là lợi thế lớn.
Khi thảo luận EVM và RISC-V, tôi đề nghị chúng ta đi xa hơn, so sánh ưu nhược điểm của cả hai khi đều có hoặc đều không có tiền biên dịch. Chúng ta đừng so sánh EVM có tiền biên dịch với RISC-V không có tiền biên dịch, hoặc ngược lại, theo tôi, cách so sánh này không phù hợp. Giả sử sử dụng thực hiện RISC-V JIT hoặc AOT, hoặc đưa vào lệnh AVX, chúng ta có thể đạt được hiệu suất tương đương EVM không có tiền biên dịch RISC-V ảo.
Theo chúng tôi biết, RISC-V là giải pháp tốt nhất 7 năm trước, trong tương lai có thể dự đoán, nó vẫn là giải pháp tốt nhất theo quan điểm chúng tôi. Nếu ai nói RISC-V là giải pháp phần cứng, thì cứ thế, chúng tôi đã thực hiện bằng phần mềm thuần túy, và nó vẫn đáp ứng hoàn hảo nhu cầu của chúng tôi. Về mặt này, chúng tôi hài lòng với tình hình hiện tại, và sẽ tiếp tục theo con đường này. [src[31]]
Người dẫn chương trình: CKB-Virtual Machine (CKB-VM) là một máy ảo dựa trên tập lệnh RISC-V, dùng để thực thi hợp đồng thông minh trên Nervos CKB, viết bằng Rust. Ai quan tâm có thể đọc bài viết năm 2018 của @Xuejie Xiao: Giới thiệu về Nervos CKB-VM[32], xem suy nghĩ của họ lúc đó, chia sẻ rất hay!
ZKM[33]: Kế hoạch RISC-V của @VitalikButerin dành cho Ethereum rất táo bạo, nhưng độ trưởng thành và truyền thống của MIPS khiến nó trở thành một đối thủ đáng gờm —— một tập lệnh cố định rất phù hợp cho bằng chứng ZK độ trễ thấp. MIPS đã vận hành các hệ thống trọng yếu suốt 40 năm —— Ethereum có thể tận dụng sự ổn định này để đạt được hiệu quả nâng cao tương tự (hoặc thậm chí tốt hơn), đồng thời giảm rủi ro khi đặt cược vào một ISA như RISC-V đang bị thổi phồng quá mức và vẫn đang trưởng thành. Khi MIPS đã được kiểm chứng, tại sao phải chấp nhận đau đớn trưởng thành của RISC-V? [src[34]]
WebAssembly (WASM)
@IAmNickDodson: Được thiết kế để thực thi mã tùy ý trong trình duyệt / môi trường cô lập: Ưu điểm: Hỗ trợ đa ngôn ngữ/môi trường, có thể biên dịch thành mã gốc, quy tắc mã nguồn mở rõ ràng, chức năng tính phí được bổ sung sau (nhưng gây thêm chi phí), Nhược điểm: kiến trúc dựa trên ngăn xếp (nghiên cứu học thuật cho rằng hiệu suất thấp, nhưng cần nhìn nhận biện chứng), không được thiết kế riêng cho blockchain, chức năng tính phí là miếng vá bổ sung, ảnh hưởng hiệu suất, trải nghiệm gỡ lỗi cực kỳ tệ.
Lý thuyết thì WASM là lựa chọn không tồi, nhưng thực tế phát triển gỡ lỗi cực kỳ đau khổ. Nhiều đội All in WASM trao đổi với chúng tôi đều nói hối hận. So với RISC-V/MIPS dễ hiểu hơn, có lẽ đây là lý do các đội như Succinct/RISC0 chọn chúng. [src[35]]
Peter Kieltyka[36] (đồng sáng lập Sequence[37]): @VitalikButerin Tôi biết điều này hơi gượng ép, nhưng hãy cân nhắc EVM+/Stylus do đội Offchain Labs phát triển làm tầng thực thi L1 tương lai. Nó hoàn toàn tương thích bytecode EVM, có thể chạy trong VM WASM, hỗ trợ mọi ngôn ngữ hỗ trợ WASM (ví dụ Rust), hiệu suất tăng đáng kể, đồng thời duy trì khả năng tương tác hoàn toàn với hợp đồng bytecode EVM trong runtime. Cảm giác đây là con đường nâng cấp đơn giản nhất khi giữ được tính tương thích. [src[38]]
Xuejie Xiao[39]: Nhiều người cho rằng WASM là lựa chọn lý tưởng cho máy ảo blockchain, chủ yếu vì WASM được thiết kế cho việc thực hiện phần mềm (nếu điều này có ý nghĩa, chúng ta tạm bỏ qua). Bạn có biết, trước khi WASM ra đời, một tập con của JavaScript là asm.js từng thịnh hành? asm.js sau này tiến hóa thành WASM, và vô tình trở nên lớn hơn nhiều so với tầm nhìn ban đầu của asm.js (xin lỗi, giờ WASM trông giống JVM được thiết kế sạch sẽ, mới mẻ hơn là asm.js). Nhưng chúng ta đừng quên mục tiêu ban đầu của asm.js: mọi người khao khát một IR phần mềm có thể ánh xạ xác định đến lệnh CPU gốc, chứ không phải JIT chỉ làm được 90% thời gian. Nếu RISC-V có thể đạt được mục tiêu này, tôi cho rằng nó rất phù hợp làm máy ảo phần mềm. [src[40]]
Hazel Hu[41] (Delphinus Lab[42]): Dù @VitalikButerin nhiệt tình ủng hộ RISC-V, nhưng máy ảo ZK không chỉ có một con đường kỹ thuật này. Máy ảo ZK cũng không riêng của ETH, nó là một thứ độc lập có thể lớn hơn hệ sinh thái ETH, ETH cần ZKVM, nhưng ZKVM không bị giới hạn trong hệ sinh thái Ethereum. [src[43]]
Hệ thống ZK sử dụng RISC tức tập lệnh thu gọn, ở đây lại có hai lựa chọn, thứ nhất là Cairo như ngôn ngữ ZK riêng tự xây một tập lệnh tùy chỉnh (đường cong học tập quá dốc), thứ hai là dùng tập lệnh hiện có. RISC-V là một trong số đó. Các dự án máy ảo ZK dựa trên RISC-V bao gồm @RiscZero[44], @SuccinctLabs[45], @NexusLabs[46] và Jolt được @a16z[47] hỗ trợ.
Sớm từ năm 2018, hệ sinh thái Ethereum đã khởi động dự án eWASM, người phát minh EVM @gavofyork[48] từng nói về khả thi thay thế EVM bằng WASM, người sáng lập Polygon @sandeepnailwal[49] cũng luôn là người ủng hộ kiên định WASM. Tuy nhiên, eWASM cuối cùng không được áp dụng rộng rãi, lý do bao gồm độ phức tạp kỹ thuật, điều chỉnh ưu tiên và sự trỗi dậy của giải pháp L2, trong lộ trình phát hành sau đó, eWASM bị đình chỉ.
Sau khi @VitalikButerin công bố đề xuất, người sáng lập Zebra @shumochu[50], cộng sự nghiên cứu 1kx @_weidai[51] v.v. đều chỉ ra WASM có lẽ phù hợp hơn RISC-V cho tầng thực thi Ethereum, lý do như sau:
Quy trình thuận tiện hơn: RISC-V ban đầu được thiết kế cho thực hiện phần cứng, không phải làm biểu diễn trung gian. Nếu dùng làm tầng thực thi hợp đồng Ethereum, vẫn cần xây một tầng máy ảo để xử lý tiêu thụ gas và kiểm soát luồng thực thi, điều này làm tăng độ phức tạp.
Thân thiện với phân tích tĩnh: WASM không có lệnh nhảy, cấu trúc mã đơn giản, dễ xác minh thuộc tính hợp đồng.
Hỗ trợ ngôn ngữ rộng: Nhà phát triển có thể dùng hầu hết mọi ngôn ngữ lập trình chủ lưu hiện nay để biên dịch thành WASM, giảm mạnh chi phí học tập. Người sáng lập Miden @bobbinth[52] còn đề xuất, nếu theo đuổi tính thân thiện ZK, có thể thiết kế tập lệnh tốt hơn RISC-V, hoặc dùng mô hình thành phần WASM. [src[53]]
Đơn vị tôi @Delphinuslab[54] đã mã nguồn mở máy ảo ZKWASM đầu tiên trong ngành, hiện tại tuy chỉ có SDK solidity, nhưng thực tế, việc thanh toán hợp đồng ZKVM có thể diễn ra trên bất kỳ chuỗi nào, tương lai hoàn toàn có thể mở rộng sang các chuỗi không đồng EVM như Solana, Sui v.v.
Máy ảo ZKWASM thực sự có thể dùng để làm gì?
1. Cho phép nhiều nhà phát triển hơn sử dụng ngôn ngữ lập trình quen thuộc nhất bước vào thế giới blockchain, không bắt buộc ai cũng học Solidity (và các ngôn ngữ blockchain nhỏ hẹp, phức tạp hơn)
2. Cho phép nhiều ứng dụng nhỏ web2.5 có thể lên chuỗi một cú nhấp, nếu hoàn toàn thông suốt, hàng ngàn ứng dụng trình duyệt nhỏ có thể nhanh chóng triển khai lên blockchain
3. Phá vỡ tam giác bất khả thi, đạt được cân bằng giữa phi tập trung, hiệu quả và an toàn. [src[55]]
x86/ARM
@IAmNickDodson: Hai tập lệnh CPU này đều không mã nguồn mở: ARM thuộc RISC tập lệnh thu gọn, x86 thuộc CISC tập lệnh phức tạp. Theo sự tiến hóa phần cứng CPU, cả hai đều trở nên cực kỳ phức tạp. Lưu ý rằng, mặc dù CISC do độ phức tạp dần bị RISC thay thế trong lĩnh vực CPU, nhưng trong tình huống blockchain thì CISC lại có lợi thế hơn. [src[56]]
Xuejie Xiao[57]: x64 quá nặng (khi chúng tôi lần đầu thử RISC-V,居然有人正在使用 x64 构建区块链虚拟机！)，而 Arm có thể có vấn đề giấy phép, cũng có thể không. [src[58]]
Bitcoin Script
@IAmNickDodson: VM blockchain đầu tiên, được thiết kế riêng cho lập trình Bitcoin:
Ưu điểm: Được tạo riêng cho blockchain và mô hình giao dịch Bitcoin, thích ứng với môi trường đối kháng, hỗ trợ các thao tác cơ bản như đa chữ ký
Nhược điểm: Chức năng cực kỳ hạn chế, bị giới hạn nghiêm trọng bởi khả năng xử lý mạng Bitcoin.
Chúng tôi kế thừa từ Bitcoin Script phạm trù mạnh mẽ P2SH (thanh toán tới băm script) —— lập trình điều kiện. Mô hình chương trình có thể cắt tỉa này (sau thực thi có thể xóa khỏi nút đầy đủ) hỗ trợ được: giao dịch ngoài chuỗi / ví đa chữ ký / đấu giá hàng hóa v.v. Kiến trúc Bitcoin启示 chúng tôi: Thiết kế VM phải phối hợp sâu sắc với mô hình giao dịch. [src[59]]
MoveVM
@IAmNickDodson: VM chuyên dụng blockchain do đội Meta phát triển, nhấn mạnh tính an toàn:
Ưu điểm: Thiết kế gốc blockchain, hỗ trợ tính phí đối kháng, ngôn ngữ riêng kèm theo là Move
Nhược điểm: Đánh đổi linh hoạt trạng thái lớn để đổi lấy an toàn, quá RISC hóa (xem phân tích trước), phân mảnh hệ sinh thái (SUI/Aptos có biến thể không tương thích).
Năm 2020-21 hệ sinh thái Move gần như đình trệ. Chúng tôi từ bỏ vì không muốn bị giam cầm trong kiến trúc người khác không thể đổi mới, và đặc tính "an toàn" của nó phần lớn chỉ là đóng gói hệ thống RISC, không thể ngăn chặn việc viết mã kém. Xác minh hình thức lúc đó chỉ phù hợp phương pháp đơn giản chứ không phải ứng dụng đầy đủ, tỷ lệ hiệu suất cực thấp. [src[60]]
EVM
@IAmNickDodson: Có thể gọi là PHP trong giới blockchain, hỗ trợ hàng nghìn tỷ giá trị hợp đồng thông minh:
Ưu điểm: Thiết kế gốc blockchain, cơ chế tính phí hoàn thiện, tương thích toàn hệ sinh thái, ngôn ngữ Solidity đã được kiểm chứng lâu dài
Nhược điểm: Thiết kế độ dài từ 256 bit, chỉ hỗ trợ gọi/hợp đồng, thiếu chức năng script, thiếu lập trình điều kiện (không có vật tương đương P2SH), dựa trên mô hình giao dịch đơn giản hóa quá mức, hiệu suất thấp (thiết kế độ dài từ và opcode gây lãng phí tính toán lớn), thiết kế trạng thái hóa cao khiến truy cập lưu trữ thành nút thắt hiệu suất.
Dù một số đội tuyên bố đã giải quyết vấn đề bằng cơ sở dữ liệu mới hoặc phương án truy cập trạng thái, nhưng bản chất những tính toán này có thể tránh được. EVM phù hợp để nhanh chóng xây dựng hệ sinh thái, nhưng về mặt mô hình giao dịch và không gian thiết kế thì thiếu đổi mới. Có lẽ lời kêu gọi của Vitalik chính là nhận ra điều này. [src[61]]
Alex Vlasov[62]: Chưa rõ RISC-V có thực sự tốt hơn EVM không. EVM dựa trên ngăn xếp, do đó tập thanh ghi của nó rất nhỏ. EVM thao tác số 256 bit, nếu các giá trị nhỏ hơn chiếm ưu thế, điều này có thể thành vấn đề. Tuy nhiên, bộ chứng minh có thể truy cập đường đi thực thi thực tế, do đó có thể chọn lựa thực hiện nhẹ hơn cho các giá trị nhỏ hơn (ví dụ, phân tích byte của giá trị 32 bit chiếm ít hàng hơn so với phân tích byte của giá trị 256 bit). [src[63]]
Một khía cạnh khác là chi phí xác minh hình thức hợp đồng thông minh. Tập lệnh (ISA) của EVM giới hạn hơn RISC-V, do đó F/V tổng thể sẽ phức tạp hơn. Hợp đồng thông minh RISC-V thường chứa nhiều vòng lặp và thao tác bộ nhớ hơn, cả hai đều gây vấn đề cho F/V.
Ví dụ, một nghiên cứu (/www.cs.utexas.edu/~isil/solis.pdf[64]) cho thấy khoảng một phần năm hợp đồng thông minh EVM chứa một hoặc nhiều vòng lặp. Do EVM thao tác giá trị 256 bit, cần nhiều vòng lặp hơn trong mã RISC-V. Ngay cả khi mở rộng vòng lặp, cũng dẫn đến truy vấn SMT lớn hơn.
RISC-V có mô hình bộ nhớ phong phú hơn, nên sẽ có nhiều thao tác bộ nhớ hơn (ví dụ, EVM có 1024 ngăn xếp 256 bit, trong khi EVM có 16-32 thanh ghi 32/64 bit). Do đó, hiện tượng chồng chéo (hai biểu thức cú pháp khác nhau trỏ đến cùng vị trí bộ nhớ) sẽ nghiêm trọng hơn. Điều này ngược lại ảnh hưởng đến phân tích tĩnh, ví dụ tái tạo đồ thị gọi hàm, phân tích trỏ v.v.
Tôi dự đoán, việc suy luận hình thức cho hợp đồng thông minh RISC-V có vòng lặp/chồng chéo sẽ khó khăn hơn so với hợp đồng thông minh EVM. [src[65]]
SVM
@IAmNickDodson: Máy ảo Solana trỗi dậy trong những năm gần đây:
Ưu điểm: Thiết kế gốc blockchain, hỗ trợ tính phí đối kháng, có thể biên dịch thành mã gốc, thiết kế hiệu suất cao
Nhược điểm: Kiến trúc phức tạp khó hiểu, trải nghiệm phát triển ngôn ngữ như Rust kém, thiếu ngôn ngữ riêng trưởng thành.
Chúng tôi không chọn SVM chủ yếu do giả định mô hình giao dịch —— thiết kế đơn giản giống Ethereum theo đuổi tốc độ hơn là thanh toán nhiều bên phức tạp, không khớp với mô hình giao dịch chúng tôi dự định. [src[66]]
CarioVM
Akash Balasubramani (quản lý hệ sinh thái StarkWare): @IAmNickDodson phân tích tuyệt vời! Giá mà có thêm CarioVM thì tốt hơn. [src[67]]
@IAmNickDodson: Không bao gồm chỉ vì lúc điều tra năm 2020/21 nó chưa lọt vào tầm mắt chúng tôi. Tôi là fan trung thành của Cairo và công nghệ STARK. [src[68]]
Eli Ben-Sasson (đồng sáng lập StarkWare): @IAmNickDodson thảo luận tuyệt vời! Chỉ đề xuất thêm phân tích Cairo. Tôi thử bổ sung: Ưu điểm: Thiết kế riêng cho blockchain + hiệu quả zkSTARK, an toàn kiểu tuyến tính, tính phí Gas hiệu quả (Sierra), Nhược điểm: Độ nổi tiếng / độ hoàn thiện chuỗi công cụ thấp :) [src[69]]
Người dẫn chương trình: Cảm ơn các bạn đã có những bình luận tuyệt vời, cuối cùng kết luận của các bạn là gì? Có những hiểu biết nào có thể chia sẻ với mọi người không?
@IAmNickDodson: Sau khi nghiên cứu tất cả VM, chúng tôi nhận ra: tầm quan trọng của bản thân máy ảo bị đánh giá quá cao. Về lý thuyết các VM này đều có thể (ngoại trừ BitcoinScript) hoàn thành tính toán cần thiết với hiệu suất khác nhau. Điều thực sự then chốt là thiết kế phối hợp giữa VM và mô hình giao dịch. Nhiều chuỗi quá chú trọng VM mà bỏ qua mô hình giao dịch —— mới là cốt lõi hành vi blockchain. [src[70]]
Điểm độc đáo của FuelVM nằm ở đây, đây là các tối ưu tổ hợp FuelVM [src[71]]:
• Hiệu quả bộ nhớ (giảm sao chép bằng cách chia sẻ ngữ cảnh bộ nhớ)
• Tận dụng thông minh thanh ghi và bộ nhớ (ví dụ đặt toàn bộ giao dịch vào bộ nhớ nhìn thấy được để tự kiểm tra runtime)
• Giảm tối đa truy cập IO
• Tăng cường khả năng tầng giao dịch (cho giao dịch đảm nhận nhiều hơn, VM đảm nhận ít hơn)
• Mô hình giao dịch có khả năng truy cập trạng thái và luân chuyển đa tài sản / đa điều kiện / đa chế độ thực thi
• Cân bằng vàng giữa CISC và RISC
• Không có cây trạng thái toàn cục (mô hình UTXO phòng chống double-spend tự nhiên bằng cách hồi thời gian)
• Tất cả opcode được tối ưu cho hiệu quả tính phí
• Hỗ trợ các loại chương trình đa dạng như lập trình điều kiện vị từ
• Ngôn ngữ Sway đi kèm vừa có hiệu suất Rust vừa có trải nghiệm phát triển Solidity
Nhận thức truyền thống cho rằng VM blockchain nên theo đuổi lệnh cực đơn giản (do an toàn và biên dịch mã gốc). Nhưng vấn đề nằm ở chỗ: trong kịch bản xác minh lạc quan, mỗi thao tác đều cần tính phí. VM càng đơn giản, cần càng nhiều opcode để thực hiện chức năng giống nhau, lượng tính toán tính phí trên chuỗi càng lớn. Do đó FuelVM chọn thiết kế nhiều opcode hiệu quả hơn —— dùng ít thao tác hơn để làm được nhiều việc hơn. Bạn có thể coi FuelVM là sự kết hợp giữa CISC và RISC. Mặc dù lệnh nhiều hơn thường nghĩa là kích thước bytecode lớn hơn (sẽ ảnh hưởng trong tình huống giới hạn băng thông, nhưng nén có thể giảm nhẹ), nhưng điều này có thể giảm đáng kể chi phí tính phí xác minh lạc quan, cung cấp công cụ mạnh mẽ hơn cho nhà phát triển. Ngay cả trong kịch bản ZK, thao tác tổ hợp cũng có thể đạt được hiệu quả tối ưu tốt hơn.Đơn giản ≠ Tốt hơn. [src[72]]
Người dẫn chương trình: Có điều gì muốn nói với các kỹ sư lựa chọn công nghệ VM khác không? Ví dụ Ethereum :)
@IAmNickDodson: Nếu Ethereum chọn con đường RISC, phải đồng thời cân nhắc mô hình giao dịch. VM chỉ là một mảnh ghép —— RISC-V không thể giải quyết kế toán token, vượt qua mô hình hợp đồng thông minh, xây dựng ứng dụng blockchain hiệu suất cao phục vụ toàn nhân loại và robot. Fuel chọn làm điều đúng đắn chứ không phải điều phổ biến, điều này nghĩa là chịu đựng liên tục (nhìn vào token của chúng tôi là biết), nhưng cũng cung cấp mẫu thiết kế mới cho hệ sinh thái blockchain mã nguồn mở.
Nếu bạn đang cân nhắc xây dựng blockchain, và cần kiến trúc phù hợp sâu sắc bản chất blockchain, FuelVM/Sway đáng để cân nhắc. Hiệu suất còn điên rồ hơn: 150.000 TPS trên bộ xử lý M4, xác nhận mềm 10ms, có thể chạy từ máy nướng bánh đến siêu máy tính. Bạn có thể tìm hiểu thêm về FuelVM: Tại sao FuelVM là EVM nhưng được cải thiện đáng kể và ý nghĩa điều này với tương lai blockchain[73]
Xuejie Xiao[74]: Về ZK thêm một điểm, trước tiên đây chỉ là quan điểm cá nhân tôi về kiến thức không, RISC-V có hai trường hợp sử dụng khác nhau liên quan đến kiến thức không: 1) máy ảo /IR dùng để biểu đạt chương trình sẽ được chứng minh ZK, 2) nền tảng底层 nơi trình xác minh ZK chạy. Một phép so sánh đơn giản nhưng không chính xác là, có một máy ảo trên thuật toán bằng chứng kiến thức không (điểm 1), và cũng có một máy ảo dưới thuật toán bằng chứng kiến thức không (điểm 2). Chúng nên được thảo luận riêng.
CKB-VM Nervos áp dụng thiết kế không tiền biên dịch nghiêm ngặt, hoàn toàn phù hợp điểm thứ hai: bạn có thể biên dịch mã trình xác minh ZK thành mã RISC-V, và chạy trình xác minh ZK đó trên CKB-VM Nervos. Theo nghĩa này, Nervos CKB sẽ có thể linh hoạt hỗ trợ bất kỳ giải pháp ZK nào. Nói cách khác, tôi cho rằng CKB-VM Nervos là lựa chọn tốt cho máy ảo (VM) dưới thuật toán ZK.
Điểm thứ nhất sẽ là một trường hợp sử dụng riêng biệt, tôi không quen thuộc với cơ chế bên trong bằng chứng kiến thức không, do đó không thể phán đoán RISC-V có phải là giải pháp phù hợp hay không. Tôi nghi ngờ một số đặc tính của thuật toán bằng chứng kiến thức không có thể ảnh hưởng đến lựa chọn xây dựng máy ảo trên thuật toán bằng chứng kiến thức không.
Tôi có thể sai, nhưng tôi cảm giác @VitalikButerin có lẽ đang nói về điểm 2, hoặc VM phù hợp dưới thuật toán ZK, vậy có lẽ chúng ta không cần thảo luận RISC-V có phù hợp với bằng chứng ZK không?
porter | ZKsync[75]: ZKsync đã sẵn sàng cho những thay đổi sau: Hệ thống chứng minh mới Boojum2 đã là RISC-V, có một số việc sẽ mang lại lợi ích cho toàn bộ Ethereum (không chỉ ZKsync): Bộ biên dịch hoàn toàn mới Solidity -> LLVM -> RISC-V sắp ra mắt. [src[76]]
@alacheng[77]: Hướng ZK (nếu mở rộng L1 khi nút xác minh không cần thực thi lại thì một vài zkvm này sẽ thay thế zkevm), @SuccinctLabs[78] và @RiscZero[79] đều là zk risc-v vm, @UntoLabs[80] là một nhà phát triển cốt lõi từ hệ sinh thái sol làm chuỗi, vm tầng thực thi là risc-v vm. [src[81]]
Người dẫn chương trình: Rất cảm ơn các vị đại佬 đã chia sẻ tuyệt vời, buổi "hội nghị tròn ảo" lần này đến đây là kết thúc. Do thời gian và篇幅 giới hạn, còn nhiều máy ảo đặc sắc chúng tôi không thể giới thiệu từng cái một, có lẽ tương lai tôi sẽ tiếp tục cập nhật hoặc thêm buổi thứ hai. Các khán giả nếu muốn tìm hiểu chi tiết, có thể nhấn vào [src] ở cuối mỗi quan điểm/bài phát biểu.
Tổng kết
Trong buổi "hội nghị tròn ảo" này, chúng ta thấy các dự án blockchain khác nhau chọn con đường kỹ thuật hoàn toàn khác biệt —— EVM theo đuổi tương thích hệ sinh thái, RISC-V tập trung vào hiệu quả phần cứng, WASM ôm trọn phát triển đa ngôn ngữ, MoveVM nhấn mạnh an toàn tài sản, FuelVM thì phá vỡ giới hạn hiệu suất. Điều này chính xác cho thấy, trong thế giới blockchain, không có giải pháp tối ưu nào áp dụng khắp nơi, chỉ có sự cân nhắc lựa chọn phù hợp nhất với mục tiêu phát triển riêng.
Thông qua cuộc tranh luận kỹ thuật này, chúng ta có thể thoáng thấy:
• Ethereum chọn nâng cấp bảo thủ, vì ưu tiên giá trị hệ sinh thái
• Nervos ôm trọn RISC-V, xuất phát từ theo đuổi cực hạn thân thiện phần cứng
• Aptos/Sui đặt cược MoveVM, thể hiện sự ám ảnh an toàn
• Fuel đi lối riêng, dùng kiến trúc hỗn hợp phá vỡ nút thắt hiệu suất
Phía sau những lựa chọn này, là câu trả lời khác nhau của các đội về "blockchain nên là gì". Hiểu logic ra quyết định kỹ thuật này, có lẽ còn giá trị hơn tranh luận ưu nhược —— nó cho chúng ta thấy sự đa dạng thực sự của lĩnh vực này, cũng báo hiệu格局 đa dạng nở rộ trong tương lai Web3, rất tuyệt vời, phải không?
Khước từ trách nhiệm
Nội dung bài viết này là tổng hợp và tái tổ chức các cuộc thảo luận kỹ thuật công khai, nhằm so sánh và phân tích khách quan các công nghệ máy ảo Web3 chủ lưu hiện nay. Tất cả các dự án, giải pháp kỹ thuật và sản phẩm được đề cập trong bài (bao gồm nhưng không giới hạn EVM, RISC-V, WASM, MoveVM, FuelVM v.v.) đều được tổng hợp từ nội dung thảo luận cộng đồng nhà phát triển công khai, chỉ phản ánh quan điểm cá nhân của người phát biểu liên quan, không đại diện cho lập trường của tác giả bài viết hoặc nền tảng phát hành.
Người đọc lưu ý:
1. Tính trung lập kỹ
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
