Trận chiến khốc liệt của Lớp 2 đang diễn ra sôi nổi và có rất nhiều phe phái zkVM.

Văn bản gốc: "Tóm tắt hàng tuần của iOSG | Cách sống sót ZKVM, giải thích chi tiết về tranh chấp phe phái #159"

Tác giả: Bryan, IOSG Ventures

Mục lục

Triển khai mạch của hệ thống chứng minh ZKP - dựa trên máy ảo VS dựa trên mạch (dựa trên vm)

Nguyên tắc thiết kế ZKVM

So sánh giữa các máy ảo dựa trên STARK

Tại sao Risc0 lại thú vị

Trọng tâm chính của cuộc thảo luận về triển khai trong năm 2022 vừa qua dường như tập trung vào ZkEVM, nhưng đừng quên rằng ZkVM cũng là một phương tiện mở rộng 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 giữa ZkVM và ZkEVM ở một số khía cạnh:

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 chúng là khác nhau. 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 dapps, khả năng tương thích. không phải là ưu tiên. 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ể đoán trước được. Nút thắt chính của ZkEVM là chi phí phát sinh thêm khi 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. Đ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. Trải nghiệm của nhà phát triển: ZkEVM loại II (chẳng hạn 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, mã EVM ở cấp Bytecode trở lên 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ữ trưởng thành hơn hiện có như C++/Rust (chẳng hạn như Risc0). 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. Nhiều người vẫn nên nhớ 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 trong ý tưởng thiết kế.

Trước khi thảo luận về ZkVM, trước tiên chúng ta nghĩ về cách triển khai hệ thống chứng minh ZK trong blockchain. 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 kiểm chứng; hệ thống dựa trên máy ảo thực thi chương trình thông qua tập lệnh (ISA). dấu vết. 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.

Chương trình zkp trong máy ảo có thể trải qua quá trình sau:

Tín dụng hình ảnh: Bryan, IOSG Ventures

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

Từ quan điểm 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 sự hiểu biết sâu sắc về chi phí của từng 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ừ quan điểm của người xác minh, các hệ thống dựa trên mạch và máy ảo khác nhau đáng kể về tính tổng quát của các mạch, giả sử cùng một SNARK thuần túy được sử dụng làm phần phụ trợ. 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ớ vào thiết kế và mục đích của việc sử dụng hệ thống mạch là cải thiện hiệu suất của 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 nhiều độ 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à máy khách, v.v. So sánh, hệ thống mạch đơ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à dựa trên máy ảo khác nhau hiện có trong L1/L2:

Tín dụng hình ảnh: Bryan, Nguyên tắc thiết kế của iOSG Ventures 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 cách thức hoạt động 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ó càng ít ràng buộc càng tốt để cả việc thực thi và xác minh chương trình đều 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 Risc0. 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 rộng ra, trình biên dịch dần dần dịch ngôn ngữ lập trình thành 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 (R1CS, 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 hiện có trong ZK - ví dụ: trong ZK, các biểu diễn mạch bắt đầu từ 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 Risc0 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 ở 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 (bảo mật) và chi phí xác minh (verifier cost)

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 càng cao. 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 sự sẵn có của biểu diễn trung gian cho 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ư R1CS 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 sẽ khó khăn.

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

Nhược điểm của việc sử dụng mô hình có 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.

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

Trước giao thức Pinocchio: Đã triển khai các tính toán có thể kiểm chứng 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 ngắn hơn thời gian thực hiện của chương trình) và dựa trên cơ sở. trên Circuit system Giao thức TinyRAM: So với giao thức Pinocchio thì TinyRAM giống một máy ảo hơn, giới thiệu ISA nên loại bỏ một số hạn chế như truy cập bộ nhớ (RAM), control flow (luồng điều khiển), v.v. Giao thức vnTinyRAM: cho phép tạo khóa (tạo khóa) không phụ thuộc vào mọi chương trình, mang lại tính linh hoạt bổ sung. 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ý các máy ảo, STARK và Plonk dường như là một phụ trợ phù hợp hơn, về cơ bản vì hệ thống ràng buộc của chúng phù hợp hơn để triển khai logic giống CPU.

Tiếp theo, bài viết này sẽ giới thiệu ba máy ảo dựa trên STARK - Risc0, MidenVM và CairoVM. Nói tóm lại, ngoại trừ việc cả hai đề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:

Risc0 tận dụng Risc-V để đơn giản hóa tập lệnh. R0 biên dịch trong 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à 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 họ:

* Cách đọc bảng trên như thế nào? 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 khi chọn độ dài từ CPU (32/64 bit).

Truy cập bộ nhớ - Risc0 sử dụng các thanh ghi chủ yếu vì tập lệnh Risc-V dựa trên 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 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 pháp mast root, nó cần được giải mã khi lệnh được xử lý, 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 hơn. Các phương pháp tải khởi động 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 thực hiện các hoạt động này trực tiếp thông qua DSL có thể dễ dàng dẫn đến việc cạn kiệt các chu trình chứng minh.

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

Ở cuối bài viết, tôi muốn nói về sự phát triển hiện tại của Risc0 và lý do tại sao nó khiến tôi hứng thú.

R0 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ố đổi mới thú vị, chẳng hạn như mở rộng trường, có thể đạt được các tham số bảo mật vững chắc hơn và hoạt động trên các 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, Risc0 sử dụng lớp trừu tượng hóa phần cứng để cho phép phát triển tốt hơn về mặt phần cứng.

d.Vẫn đang trong quá trình hoàn thiện! Vẫn đang được 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 nay, các mạch SHA256 chuyên dụng đã được triển khai tuy nhiên chưa đáp ứng được hết 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ẽ phụ thuộc vào trường hợp sử dụng do Risc0 cung cấp. SHA256 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ư 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ì Risc0 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à thuộ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 Risc0 đư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, các trường hợp sử dụng thú vị hơn 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ó các 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 Risc0 VM hơn.

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

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

Cảm ơn Xin Gao, Boyuan từ p0xeidon, Daniel từ Taiko và Sin7Y vì sự hỗ trợ và đề xuất sửa đổi bài viết này!