iOSG: Cách sinh tồn của ZKVM, giải thích chi tiết về tranh chấp phe phái giữa zkVM và zkEVM

Tiêu đề gốc: " Tóm tắt hàng tuần của iOSG ｜ZKVM Survival, một bài viết giải thích chi tiết về tranh chấp phe phái 》

Tác giả gốc: Bryan, IOSG Ventures

Trọng tâm chính của các cuộc thảo luận về việc triển khai trong năm 2022 vừa qua dường như tập trung vào ZkEVM, nhưng khác Hãy quên rằng ZkVM cũng là một phương tiện mở rộng quy mô khác. Mặc dù ZkEVM không phải là trọng tâm của bài viết này nhưng cũng cần nhắc lại sự khác biệt về một số khía cạnh giữa ZkVM và ZkEVM:

Khả năng tương thích: Mặc dù cả hai đều là bản mở rộng, nhưng Trọng tâm của ZkEVM là trực tiếp đạt được khả năng tương thích với EVM hiện có, trong khi định vị của ZkVM là đạt được sự mở rộng hoàn toàn, nghĩa là tối ưu hóa logic và hiệu suất của dapp. Khi lớp dưới cùng được thiết lập, khả năng tương thích EVM cũng có thể đạt được.

Hiệu suất: Cả hai đều có những hạn chế về hiệu suất tương đối có thể thấy trước. Điểm nghẽn chính của ZkEVM là khả năng tương thích với EVM, không phù hợp để đóng gói trong hệ thống chứng nhận ZK. chi phí. Điểm nghẽn của ZkVM là do sự ra đời của tập lệnh ISA nên các ràng buộc đối với đầu ra cuối cùng phức tạp hơn.

Kinh nghiệm của nhà phát triển: ZkEVM loại II (như Scroll, Taiko) tập trung vào khả năng tương thích với EVM Bytecode, nói cách khác là EVM ở cấp Bytecode trở lên. Tất cả các mã đều có thể tạo ra bằng chứng không có kiến thức tương ứng thông qua ZkEVM. Đối với ZkVM, có hai hướng. Một hướng là tạo DSL của riêng mình (chẳng hạn như Cairo) và hướng còn lại là tương thích với các ngôn ngữ hoàn thiện hơn hiện có như C++/Rust (chẳng hạn như Risc 0). Trong tương lai, chúng tôi hy vọng rằng các nhà phát triển Ethereum vững chắc sẽ có thể di chuyển sang ZkEVM miễn phí và các ứng dụng mới hơn, mạnh hơn sẽ chạy trên ZkVM.

Chắc hẳn nhiều người vẫn còn nhớ Trong bức tranh này, CairoVM không liên quan gì đến ZkEVM. Lý do cơ bản dẫn đến cuộc đấu tranh giữa các phe phái là sự khác biệt về ý tưởng thiết kế

Trước khi thảo luận về ZkVM, điều đầu tiên chúng ta phải làm. hãy nghĩ đến cách Triển khai hệ thống bằng chứng ZK trong chuỗi khối. Nói rộng ra, có hai cách để triển khai các mạch - hệ thống dựa trên mạch và hệ thống dựa trên máy ảo (dựa trên vm).

Trước hết, chức năng của hệ thống dựa trên mạch là chuyển đổi trực tiếp chương trình thành các ràng buộc và gửi chúng đến hệ thống chứng minh dựa trên máy ảo. được thực thi thông qua tập lệnh (ISA) và dấu vết thực thi được tạo ra trong quy trình. Dấu vết thực thi này sau đó sẽ được ánh xạ thành các ràng buộc và sau đó được gửi đến hệ thống chứng minh.

Đối với hệ thống dựa trên mạch, việc tính toán chương trình bị hạn chế bởi mỗi máy thực thi chương trình. Đối với các hệ thống dựa trên máy ảo, ISA được nhúng trong bộ tạo mạch và tạo ra các ràng buộc chương trình. Đồng thời, bộ tạo mạch có các hạn chế về tập lệnh, chu trình chạy, bộ nhớ, v.v. Máy ảo cung cấp tính linh hoạt, nghĩa là bất kỳ máy nào cũng có thể chạy chương trình miễn là điều kiện chạy của chương trình nằm trong các giới hạn trên.

Một chương trình zkp trong máy ảo có thể trải qua quy trình sau:

Nguồn hình ảnh: Bryan, IOSG Ventures

Ưu điểm và nhược điểm:

Từ góc độ của nhà phát triển, việc phát triển các hệ thống dựa trên mạch thường đòi hỏi Có sự hiểu biết sâu sắc về chi phí của mỗi ràng buộc. Tuy nhiên, để viết các chương trình máy ảo, mạch ở dạng tĩnh và các nhà phát triển cần quan tâm hơn đến các hướng dẫn.

Từ góc độ của người xác minh, giả sử cùng một SNARK thuần túy được sử dụng làm phụ trợ, các hệ thống dựa trên mạch và máy ảo có điểm chung trong các mạch. Có sự khác biệt lớn trong các khía cạnh. Hệ thống mạch tạo ra một mạch khác nhau cho mỗi chương trình, trong khi máy ảo tạo ra cùng một mạch cho các chương trình khác nhau. Điều này có nghĩa là trong một bản tổng hợp, hệ thống mạch cần triển khai nhiều hợp đồng xác minh trên L1.

Từ góc độ ứng dụng, máy ảo làm cho logic ứng dụng trở nên phức tạp hơn bằng cách nhúng mô hình bộ nhớ (bộ nhớ) vào thiết kế. Mục đích của việc sử dụng hệ thống mạch là để. cải thiện hiệu suất chương trình.

Từ góc độ phức tạp của hệ thống, các máy ảo kết hợp sự phức tạp hơn vào hệ thống, chẳng hạn như mô hình bộ nhớ, giao tiếp giữa máy chủ và khách (khách), v.v., mạch so sánh thì hệ thống đơn giản hơn.

Sau đây là bản xem trước của các dự án dựa trên mạch và máy ảo khác nhau hiện có trong L1/L2:

Nguồn hình ảnh: Bryan, IOSG Ventures

Nguyên tắc thiết kế của máy ảo

Trong máy ảo, có hai nguyên tắc thiết kế chính. Đầu tiên, hãy đảm bảo chương trình được thực thi chính xác. Nói cách khác, đầu ra (tức là ràng buộc) và đầu vào (tức là chương trình) phải khớp chính xác. Thông thường việc này được thực hiện thông qua tập lệnh ISA. Thứ hai, đảm bảo rằng trình biên dịch hoạt động chính xác khi chuyển đổi từ ngôn ngữ cấp cao sang định dạng ràng buộc thích hợp.

1. Tập lệnh ISA

Chỉ định chế độ làm việc của bộ tạo mạch. Trách nhiệm chính của nó là ánh xạ chính xác các hướng dẫn thành các ràng buộc, sau đó được đưa vào hệ thống chứng minh. tất cả các hệ thống zk đều sử dụng RISC (bộ hướng dẫn rút gọn). Có hai tùy chọn ISA:

Đầu tiên là xây dựng một ISA tùy chỉnh (ISA tùy chỉnh), có thể thấy trong thiết kế của Cairo. Nói chung, có bốn loại logic ràng buộc như sau.

Trọng tâm thiết kế cơ bản của ISA tùy chỉnh là đảm bảo rằng có ít ràng buộc nhất có thể để việc thực thi và xác minh chương trình có thể chạy nhanh chóng.

Thứ hai là sử dụng ISA hiện có (ISA hiện có), được áp dụng trong thiết kế của Risc 0. Ngoài việc nhắm mục tiêu thời gian thực thi rõ ràng, các ISA hiện có như Risc-V còn mang lại các lợi ích bổ sung như thân thiện với các ngôn ngữ front-end và phần cứng phụ trợ. Một câu hỏi (có thể chưa được giải quyết) là liệu các ISA hiện tại có bị chậm trễ về thời gian xác minh hay không (vì thời gian xác minh không phải là mục tiêu thiết kế chính của Risc-V.

2. Trình biên dịch

Nói chung, trình biên dịch sẽ dịch dần dần ngôn ngữ lập trình sang mã máy. Trong ngữ cảnh của ZK, nó đề cập đến cách biểu diễn mã cấp thấp được biên dịch thành một hệ thống ràng buộc (R 1 CS, QAP, AIR, v.v.) bằng cách sử dụng các ngôn ngữ cấp cao như C, C++, Rust, v.v. . Có hai phương pháp,

Thiết kế trình biên dịch dựa trên các biểu diễn mạch zk hiện có - ví dụ: trong ZK, biểu diễn mạch là từ Bắt đầu với các thư viện có thể gọi trực tiếp như Bellman và các ngôn ngữ cấp thấp như Circom. Để tổng hợp các cách biểu diễn khác nhau, một trình biên dịch như Zokrates (bản thân nó là DSL) nhằm mục đích cung cấp một lớp trừu tượng có thể được biên dịch thành các cách biểu diễn cấp thấp hơn tùy ý.

Xây dựng trên cơ sở hạ tầng trình biên dịch (hiện có). Logic cơ bản là sử dụng biểu diễn trung gian cho nhiều giao diện người dùng và phụ trợ.

Trình biên dịch của Risc 0 dựa trên biểu diễn trung gian đa cấp (MLIR) và có thể tạo ra nhiều IR (tương tự như LLVM). Các IR khác nhau mang lại sự linh hoạt cho các nhà phát triển, bởi vì các IR khác nhau có những ưu tiên thiết kế riêng. Ví dụ, một số IR được tối ưu hóa riêng cho phần cứng nên các nhà phát triển có thể lựa chọn theo mong muốn của riêng mình. Những ý tưởng tương tự có thể được thấy trong vnTinyRAM và TinyRAM sử dụng GCC. ZkSync là một ví dụ khác về việc tận dụng cơ sở hạ tầng trình biên dịch.

Ngoài ra, bạn cũng có thể thấy một số cơ sở hạ tầng trình biên dịch cho zk, chẳng hạn như CirC, cũng mượn một số ý tưởng thiết kế từ LLVM.

Ngoài hai bước thiết kế quan trọng nhất được đề cập ở trên, còn có một số bước cần cân nhắc khác:

1. Sự cân bằng giữa bảo mật hệ thống và chi phí xác minh

Số lượng bit được hệ thống sử dụng càng cao (tức là bảo mật càng cao), thì chi phí xác minh cao hơn. Tính bảo mật được phản ánh trong trình tạo khóa (giống như đường cong elip được biểu thị trong SNARK).

2. Khả năng tương thích với front-end và back-end

Khả năng tương thích phụ thuộc vào hiệu quả của việc biểu diễn trung gian của mạch. IR cần đạt được sự cân bằng giữa tính chính xác (đầu ra của chương trình có khớp với đầu vào không + đầu ra có phù hợp với hệ thống kiểm chứng không) và tính linh hoạt (hỗ trợ nhiều giao diện người dùng và mặt sau). Nếu IR ban đầu được thiết kế để giải quyết các hệ thống ràng buộc cấp độ thấp như R 1 CS, thì khả năng tương thích với các hệ thống ràng buộc cấp độ cao khác như AIR là khó khăn.

3 Cần có các mạch thủ công để nâng cao hiệu quả

Sử dụng phổ biến Nhược điểm của mô hình (mục đích chung) là nó kém hiệu quả hơn đối với một số thao tác đơn giản không yêu cầu các hướng dẫn phức tạp.

Mô tả ngắn gọn một số lý thuyết trước đây,

Trước giao thức Pinocchio: Tính toán có thể kiểm chứng được, nhưng thời gian xác minh rất chậm

Giao thức Pinocchio: cung cấp tính khả thi về mặt lý thuyết về khả năng xác minh và tỷ lệ xác minh thành công (tức là thời gian xác minh là Cần một thời gian ngắn để thực hiện chương trình) và là một hệ thống dựa trên mạch

Giao thức TinyRAM: So với giao thức Pinocchio, TinyRAM giống một máy ảo hơn và giới thiệu ISA nên loại bỏ của Có một số hạn chế như truy cập bộ nhớ (RAM), luồng điều khiển (control flow), v.v.

vnGiao thức TinyRAM: để việc tạo khóa không phụ thuộc trên mỗi chương trình, cung cấp thêm tính linh hoạt. Mở rộng bộ tạo mạch, tức là có thể xử lý các chương trình lớn hơn.

Các mô hình trên đều sử dụng SNARK làm hệ thống chứng minh phụ trợ, nhưng đặc biệt khi xử lý máy ảo, STARK và Plonk có vẻ là phụ trợ phù hợp hơn, Về cơ bản mà nói , đó là do hệ thống ràng buộc của nó phù hợp hơn để thực hiện logic tương tự như CPU.

Tiếp theo, bài viết này sẽ giới thiệu ba máy ảo dựa trên STARK - Risc 0, MidenVM, CairoVM. Nói tóm lại, ngoại trừ việc tất cả đều sử dụng STARK làm hệ thống chứng minh, chúng đều có một số điểm khác biệt:

Risc 0 sử dụng Risc-V để đạt được sự đơn giản trong hướng dẫn đặt giới tính. R 0 được biên dịch bằng MLIR, một biến thể của LLVM-IR được thiết kế để hỗ trợ nhiều ngôn ngữ lập trình đa năng hiện có như Rust và C++. Risc-V cũng có một số lợi ích bổ sung, chẳng hạn như thân thiện với phần cứng hơn.

Miden đặt mục tiêu tương thích với Máy ảo Ethereum (EVM), về cơ bản là một bản tổng hợp của EVM. Miden hiện có ngôn ngữ lập trình riêng nhưng cũng đang nỗ lực hỗ trợ Move trong tương lai.

Cairo VM được phát triển bởi Starkware. Hệ thống chứng minh STARK được ba hệ thống này sử dụng được phát minh bởi Eli Ben-Sasson, hiện là chủ tịch của Starkware.

Chúng ta hãy xem xét kỹ hơn sự khác biệt của chúng:

* Làm thế nào để đọc bảng trên? Một số lưu ý...

Kích thước từ - Vì hệ thống ràng buộc mà các máy ảo này dựa trên là AIR nên nó hoạt động tương tự như kiến trúc CPU. Vì vậy, sẽ thích hợp hơn nếu chọn độ dài từ của CPU (32/64 bit).

Truy cập bộ nhớ (đọc bộ nhớ) - Risc 0 Lý do sử dụng thanh ghi (register) chủ yếu là tập lệnh Risc-V dựa trên các thanh ghi. Miden chủ yếu sử dụng ngăn xếp để lưu trữ dữ liệu vì AIR hoạt động giống như ngăn xếp. CairoVM không sử dụng các thanh ghi đa năng vì chi phí truy cập bộ nhớ (bộ nhớ chính) trong mô hình Cairo thấp.

Nguồn cấp dữ liệu chương trình (thực thi chương trình) - Có sự cân bằng giữa các phương pháp khác nhau. Ví dụ, đối với phương thức mast root, nó cần được giải mã trong khi xử lý lệnh, do đó chi phí của bộ chứng minh sẽ cao hơn trong các chương trình có nhiều bước thực hiện

Bootloading Cách tiếp cận này cố gắng đạt được sự cân bằng giữa chi phí của người chứng minh và chi phí của người xác minh trong khi vẫn duy trì quyền riêng tư.

Tính không xác định - Tính không xác định là một tính chất quan trọng của các bài toán NP-đầy đủ. Khai thác tính không xác định giúp nhanh chóng xác minh các lần thực thi trong quá khứ. Mặt khác, nó bổ sung thêm nhiều ràng buộc hơn và do đó có một số thỏa hiệp trong việc xác thực.

Tăng tốc các hoạt động phức tạp - Một số phép tính chạy rất chậm trên CPU. Ví dụ: các hoạt động bit như XOR và AND, các chương trình băm như ECDSA và kiểm tra phạm vi...chủ yếu có nguồn gốc từ công nghệ chuỗi khối/mã hóa chứ không phải hoạt động gốc của CPU (ngoại trừ hoạt động bit).

Việc triển khai các hoạt động này trực tiếp thông qua DSL có thể dễ dàng dẫn đến sự cạn kiệt của chu trình chứng minh.

Hoán vị/nhiều tập hợp (hoán vị/kết hợp nhiều cột) - được sử dụng rộng rãi trong hầu hết các zkVM cho hai mục đích - 1. Hoàn thành thực thi bằng cách giảm dấu vết lưu trữ (dấu vết thực thi) để giảm chi phí của người xác minh 2. Chứng minh rằng người xác minh biết dấu vết thực thi hoàn chỉnh

Cuối bài viết, tác giả muốn nói về sự phát triển hiện tại của Risc 0 Và điều gì khiến nó trở nên thú vị đối với tôi.

R 0 Sự phát triển hiện tại:

a. Cơ sở hạ tầng trình biên dịch “Zirgen” tự phát triển đang được phát triển. Sẽ rất thú vị khi so sánh hiệu suất của Zirgen với một số trình biên dịch dành riêng cho zk hiện có.

b. Một số cải tiến thú vị, chẳng hạn như mở rộng trường, cho phép các tham số và phép toán bảo mật mạnh hơn trên số nguyên lớn hơn.

c. Chứng kiến những thách thức trong quá trình tích hợp giữa các công ty Phần cứng ZK và Phần mềm ZK, Risc 0 sử dụng lớp trừu tượng hóa phần cứng để tạo điều kiện phát triển tốt hơn về mặt phần cứng .

d.Vẫn đang trong quá trình phát triển!

Hỗ trợ các mạch thủ công và hỗ trợ nhiều thuật toán băm. Hiện tại, các mạch SHA 256 chuyên dụng đã được triển khai nhưng chưa đáp ứng được mọi nhu cầu. Tác giả tin rằng việc lựa chọn cụ thể loại mạch nào để tối ưu hóa sẽ tùy thuộc vào trường hợp sử dụng do Risc 0 cung cấp. SHA 256 là một nơi rất tốt để bắt đầu. Mặt khác, ZKVM được định vị là mang đến cho mọi người sự linh hoạt, chẳng hạn như họ không phải lo lắng về Keccak nếu họ không muốn :)

Đệ quy: Đây là một chủ đề lớn và tôi không muốn đi sâu vào nó trong báo cáo này. Điều quan trọng cần biết là vì Risc 0 có xu hướng hỗ trợ các trường hợp/chương trình sử dụng phức tạp hơn nên nhu cầu đệ quy trở nên cấp bách hơn. Để hỗ trợ đệ quy hơn nữa, họ hiện đang nghiên cứu giải pháp tăng tốc GPU phía phần cứng.

Xử lý tính không xác định: Đây là đặc tính mà ZKVM phải xử lý, trong khi các máy ảo truyền thống không gặp phải vấn đề này. Tính không xác định có thể giúp máy ảo hoạt động nhanh hơn. MLIR tương đối tốt hơn trong việc xử lý các vấn đề liên quan đến máy ảo truyền thống và thật đáng mong đợi về cách Risc 0 đưa tính không xác định vào thiết kế hệ thống ZKVM.

Điều gì làm tôi phấn khích:

a. Đơn giản và có thể kiểm chứng được!

Trong một hệ thống phân tán, PoW yêu cầu mức độ dự phòng cao vì mọi người không tin tưởng người khác và do đó cần phải thực hiện các phép tính giống nhau nhiều lần để đạt được sự đồng thuận. Và bằng cách tận dụng các bằng chứng không có kiến thức, việc nhận ra trạng thái sẽ dễ dàng như việc đồng ý rằng 1+ 1 = 2.

b. Các trường hợp sử dụng thực tế hơn:

Ngoài việc mở rộng trực tiếp nhất, Thêm các trường hợp sử dụng thú vị sẽ trở nên khả thi, chẳng hạn như học máy không có kiến thức, phân tích dữ liệu, v.v. So với các ngôn ngữ ZK cụ thể như Cairo, Rust/C++ có nhiều chức năng phổ biến và mạnh mẽ hơn, đồng thời có nhiều trường hợp sử dụng web2 chạy trên máy ảo Risc 0 hơn.

c. Cộng đồng nhà phát triển trưởng thành/toàn diện hơn:

Dành cho STARK và các nhà phát triển quan tâm đến blockchain không cần học lại DSL, họ chỉ cần sử dụng Rust/C++.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia