IOSG: Phân tích đa chiều về tranh chấp phe phái giữa zkVM và zkEVM
Tác giả: Bryan, IOSG mạo hiểm
Trong năm 2022 vừa qua, trọng tâm chính của các cuộc thảo luận về rollup dường như là về 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 đáng để 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ù đều là bản mở rộng, nhưng trọng tâm 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 chỉnh, tức 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à chính. 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ó các nút cổ chai hiệu suất tương đối dễ đoán. Nút cổ chai chính của ZkEVM là khả năng tương thích với EVM, không phù hợp để đóng gói chi phí bổ sung được tạo ra trong hệ thống bằng chứng ZK. Nút cổ chai của ZkVM là các ràng buộc đối với đầu ra cuối cùng phức tạp hơn do sự ra đời của tập lệnh ISA.
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, các mã EVM ở cấp độ Bytecode trở lên có thể tạo bằng chứng không kiến thức tương ứng thông qua ZkEVM. Đối với ZkVM, có hai hướng, một là tạo DSL của riêng mình (chẳng hạn như Cairo), hai là tương thích với các ngôn ngữ trưởng thành 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 solidity bản địa sẽ có thể chuyển sang ZkEVM miễn phí và các ứng dụng mới hơn và mạnh hơn sẽ chạy trên ZkVM.
Hẳn nhiều người vẫn còn nhớ bức ảnh này, CairoVM không liên quan gì đến ZkEVM, nguyên nhân cốt yếu dẫn đến sự đấu đá phe phái của ZkEVM chính 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 tôi nghĩ đến là cách triển khai hệ thống bằng chứng ZK trong chuỗi khối. Nói chung, có hai cách tiếp cận để thực hiện các mạch - hệ thống dựa trên mạch (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 nó đến hệ thống chứng minh; 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) và trong quá trình Tạo một dấu vết thực hiện. Quỹ đạo thực hiện này sau đó được ánh xạ thành các ràng buộc, sau đó được đưa vào hệ thống bằng chứng.
Đối với một 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 một hệ thống dựa trên máy ảo, ISA được nhúng trong một 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ế như tập lệnh, chu kỳ hoạt động và bộ nhớ. Máy ảo cung cấp tính tổng quát, nghĩa là bất kỳ máy nào cũng có thể chạy chương trình miễn là các điều kiện hoạt động của chương trình nằm trong các giới hạn nêu trên.
Mô tả hình ảnh
Tín dụng hình ảnh: Bryan, IOSG mạo hiểm
Ư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 trong 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, các mạch là tĩnh và các nhà phát triển cần quan tâm nhiều 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ử rằng các SNARK thuần túy giống nhau được sử dụng làm phụ trợ. Hệ thống mạch tạo ra các mạch khác nhau cho từng chương trình, trong khi máy ảo tạo ra các mạch giống nhau cho các chương trình khác nhau. Điều này có nghĩa là trong một lầ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ừ quan điểm ứng dụng, máy ảo làm cho logic của ứ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ế và mục đích 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 (độ phức tạp), máy ảo kết hợp 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ủ (máy chủ) và máy khách (khách), v.v., so với hệ thống mạch đơn giản hơn.
Mô tả hình ảnh
tiêu đề cấp đầu tiên
Nguyên tắc thiết kế máy ảo
tiêu đề phụ
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. Hệ thống zk sử dụng RISC (Reduced Instruction Set). Có hai lựa chọn ISA:
Đầu tiên là xây dựng một ISA tùy chỉnh (custom ISA), có thể thấy điều nà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 một ISA tùy chỉnh là đảm bảo rằng có càng ít ràng buộc càng tốt để cả quá trình thực thi và xác minh chương trình đều chạy nhanh.
tiêu đề phụ
2. Trình biên dịch
Nói rộng ra, một trình biên dịch dần dần dịch một ngôn ngữ lập trình thành mã máy. Trong ngữ cảnh của ZK, nó đề cập đến các biểu diễn mã cấp thấp được biên dịch thành các hệ thống ràng buộc (R 1 CS, QAP, AIR, v.v.) bằng các ngôn ngữ cấp cao như C, C++, Rust, v.v. Có hai phương pháp,
Thiết kế một trình biên dịch dựa trên các biểu diễn mạch zk hiện có -- giả sử 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ư Circcom. Để tổng hợp các 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 một 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 một 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 Risc 0 dựa trên biểu diễn trung gian đa cấp (MLIR), 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ó trọng tâm thiết kế riêng, chẳng hạn như một số IR được tối ưu hóa riêng cho phần cứng, vì vậy các nhà phát triển có thể lựa chọn theo mong muốn của riêng họ. Những ý tưởng tương tự có thể được nhìn thấy trong vnTinyRAM và TinyRAM sử dụng GCC. ZkSync cũng là một ví dụ khác về khai thác 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 vay mượn một số khái niệm 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ố cân nhắc khác:
1. Sự đánh đổi giữa bảo mật hệ thống (security) và chi phí xác minh (verifier cost)
Số bit được hệ thống sử dụng càng nhiều (nghĩa 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 các trình tạo khóa (chẳng hạn như trong SNARK đại diện cho các đường cong elip).
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 một đại 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 + đầu ra có khớp với hệ thống bằng chứng không) và tính linh hoạt (hỗ trợ nhiều giao diện người dùng và phụ trợ). Nếu IR ban đầu được thiết kế để giải quyết các hệ thống hạn chế cấp độ thấp như R 1 CS , thì khả năng tương thích với các hệ thống hạn chế cấp độ cao khác như AIR là khó khăn.
3. Để nâng cao hiệu quả, cần phải làm mạch thủ công
Nhược điểm của việc sử dụng mô hình mục đích chung là nó kém hiệu quả hơn đối với một số hoạt động đơn giản không yêu cầu 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 đượ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 (nghĩa là thời gian xác minh ngắn hơn thời gian thực hiện chương trình) và đây 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, giới thiệu ISA nên loại bỏ được một số hạn chế như truy cập bộ nhớ (RAM), luồng điều khiển (control flow), v.v.
Giao thức vnTinyRAM: Tạo khóa độc lập với từng chương trình, cung cấp thêm tính linh hoạt. Bộ tạo mạch mở rộng, tức là có thể xử lý các chương trình lớn hơn.
Tất cả các mô hình trên đều sử dụng SNARK làm hệ thống chứng minh phụ trợ của chúng, 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 - Risc 0, MidenVM, CairoVM. Nói tóm lại, ngoài việc cả hai đều sử dụng STARK làm hệ thống bằng chứng, chúng đều có một số điểm khác biệt:
Risc 0 tận dụng Risc-V để đơn giản hóa tập lệnh. R 0 biên dịch trong MLIR, một biến thể của LLVM-IR được thiết kế để hỗ trợ một số ngôn ngữ lập trình đa năng hiện có như Rust, C++. Risc-V cũng có một số lợi ích bổ sung, chẳng hạn như thân thiện hơn với phần cứng.
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 sử dụng bởi ba hệ thống này đượ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 sâu hơn về sự khác biệt của chúng:
* Cách đọc mẫu 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ẽ phù hợp hơn khi chọn độ dài từ CPU (32/64 bit).
Truy cập bộ nhớ (đọc bộ nhớ) - Lý do tại sao Risc 0 sử dụng các thanh ghi chủ yếu là do 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ì chức năng AIR 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) thấp trong mô hình Cairo.
Nguồn cấp dữ liệu chương trình (thực thi chương trình) - các phương pháp khác nhau có sự đánh đổi. Ví dụ, đối với phương pháp mast root, nó cần phải giải mã khi xử lý các lệnh nên chi phí chứng minh cao trong các chương trình có nhiều bước
Phương pháp tải khởi động cố gắng đạt được sự cân bằng giữa chi phí chứng minh và chi phí xác minh trong khi duy trì quyền riêng tư.
Tính không tất định - Tính không tất định là một tính chất quan trọng của các bài toán NP-đầy đủ. Tận dụng tính không xác định giúp nhanh chóng xác minh các lần thực hiện trong quá khứ. Đổi lại, nó thêm nhiều ràng buộc hơn, do đó sẽ có một số thỏa hiệp trong quá trình xác thực.
Tăng tốc cho các hoạt động phức tạp - Một số tính toán 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... hầu hết có nguồn gốc từ chuỗi khối/tiền điện tử chứ không phải hoạt động riêng 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 sẽ dễ dàng dẫn đến cạn kiệt chu kỳ của bằng chứng.
Permutation/multiset (hoán vị/kết hợp nhiều cột) - được sử dụng nhiều trong hầu hết các zkVM, có hai mục đích - 1. Giảm chi phí của trình xác minh bằng cách giảm lưu trữ dấu vết thực thi hoàn chỉnh (dấu vết thực thi) 2. Chứng minh rằng trình xác minh biết dấu vết thực hiện đầy đủ
Ở 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 đồng và lý do tại sao nó làm tôi phấn khích.
R 0 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, Risc 0 sử dụng lớp trừu tượng phần cứng để 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à 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, tuy nhiên không phải tất cả các yêu cầu đều được đáp ứng. Tác giả tin rằng việc lựa chọn mạch nào để tối ưu hóa phụ thuộc vào trường hợp sử dụng do Risc 0 cung cấp. SHA 256 là một điểm khởi đầu rất tốt. Mặt khác, ZKVM được định vị để cung cấp cho mọi người sự linh hoạt, chẳng hạn như không bận tâm đến Keccak nếu họ không muốn :)
Đệ quy: Đây là một chủ đề lớn và tôi có xu hướng không đi sâu vào nó trong báo cáo này. Chỉ cần lưu ý rằng 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 về đệ quy càng cấp thiết hơn. Để hỗ trợ thêm cho đệ quy, 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 sự cố máy ảo truyền thống và cách Risc 0 nhúng tính không tất định vào thiết kế hệ thống ZKVM rất đáng mong đợi.
WHAT EXCITES ME:
a.Đơn giản và có thể kiểm chứng!
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, do đó, cùng một phép tính cần được thực hiện lặp đi lặp lại để đạt được sự đồng thuận. Và bằng cách sử dụng các bằng chứng không có kiến thức, việc thực hiện trạng thái sẽ dễ dàng như đồ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 kiến thức, phân tích dữ liệu, v.v. So với một ngôn ngữ ZK cụ thể như Cairo, Rust/C++ linh hoạt và mạnh mẽ hơn, đồng thời có nhiều trường hợp sử dụng web2 hơn chạy trên máy ảo Risc 0.
c. Cộng đồng nhà phát triển toàn diện/trưởng thành hơn:
Các nhà phát triển quan tâm đến STARK và chuỗi khối không cần phải học lại DSL, chỉ cần sử dụng Rust/C++.
