Tác giả: Shew & Noah, GodRealmX
Như chúng ta đã biết, chống gian lận là một giải pháp kỹ thuật được sử dụng rộng rãi trong lĩnh vực blockchain. Nó bắt nguồn từ cộng đồng Ethereum và được Ethereum Layer2 nổi tiếng như Arbitrum và Optimism áp dụng. Sau sự trỗi dậy của hệ sinh thái Bitcoin vào năm 2023, Robin Linus đã đề xuất một giải pháp có tên là BitVM, lấy bằng chứng gian lận làm ý tưởng cốt lõi và cung cấp một mô hình bảo mật mới cho lớp thứ hai hoặc cầu nối của Bitcoin dựa trên các công nghệ Bitcoin hiện có như Taproot.
BitVM đã tung ra một số phiên bản lý thuyết, từ BitVM0 đầu tiên dựa trên mạch cổng logic, đến BitVM2 sau này với ZK Fraud Proof và mạch xác minh Groth16 làm cốt lõi. Con đường triển khai kỹ thuật liên quan đến BitVM không ngừng phát triển và hoàn thiện, thu hút sự chú ý của nhiều học viên. Các dự án Bitlayer, Citrea, BOB, Fiamma và Goat Network mà mọi người đều đã nghe đến đều sử dụng BitVM làm một trong những nền tảng kỹ thuật của họ và đã triển khai nhiều phiên bản khác nhau trên cơ sở này.
Do thông tin trên thị trường giải thích một cách có hệ thống về BitVM tương đối khan hiếm và khó hiểu, chúng tôi đã cho ra mắt một loạt bài viết nhằm mục đích phổ biến kiến thức về BitVM. Xét đến mối quan hệ sâu xa giữa BitVM và bằng chứng gian lận, bài viết này sẽ tập trung vào bằng chứng gian lận và Bằng chứng gian lận ZK và giải thích chúng bằng ngôn ngữ dễ hiểu nhất có thể.
Chúng tôi sẽ sử dụng sơ đồ chống gian lận của Optimism làm tài liệu để phân tích sơ đồ dựa trên máy ảo MIPS và chống gian lận tương tác, cũng như những ý tưởng chính của chống gian lận dựa trên ZK.
(Nguyên lý cơ chế chống gian lận tương tác của Optimism)
OutputRoot và StateRoot
Optimism là một dự án Optimistic Rollup nổi tiếng, có cơ sở hạ tầng bao gồm một trình sắp xếp (các mô-đun chính bao gồm op-node, op-geth, op-batcher và op-proposer) và các hợp đồng thông minh trên chuỗi Ethereum.
Khi trình sắp xếp xử lý một loạt dữ liệu giao dịch, dữ liệu DA sẽ được gửi đến Ethereum. Miễn là bạn có khả năng chạy máy khách nút Optimism, bạn có thể tải dữ liệu được trình sắp xếp tải lên máy tính cục bộ của mình. Sau đó, bạn có thể thực hiện các giao dịch này cục bộ và tính toán băm trạng thái hiện tại của Optimism (bao gồm nhưng không giới hạn ở số dư hiện tại của mỗi tài khoản và dữ liệu khác).
Nếu trình sắp xếp tải lên băm tập hợp trạng thái sai lên Ethereum,thìbăm tập hợp trạng thái mà bạn tính toán cục bộ sẽ khác với nó. Lúc này, bạn có thể đặt câu hỏi thông qua hệ thống chống gian lận.Hệ thống sẽ hạn chế, trừng phạt hoặc không trừng phạt trình sắp xếp dựa trên kết quả phán đoán.
Khi nói đến thuật ngữ "bộ trạng thái", blockchain EVM thường sử dụng cấu trúc dữ liệu theo kiểu Cây Merkle để ghi lại bộ trạng thái, được gọi là World State Trie. Sau khi giao dịch được thực hiện, trạng thái của một số tài khoản sẽ thay đổi, World State Trie sẽ thay đổi và giá trị băm cuối cùng cũng sẽ thay đổi. Ethereum gọi hàm băm cuối cùng của World State Trie StateRoot, được sử dụng để biểu diễn những thay đổi trong tập hợp trạng thái.
Hình bên dưới cho thấy thành phần của Ethereum stateRoot. Chúng ta có thể thấy rằng số dư của các tài khoản khác nhau trong Ethereum, mã băm liên quan đến tài khoản hợp đồng thông minh và dữ liệu khác sẽ được tổng hợp vào World State Trie và stateRoot sẽ được tính toán dựa trên điều này.
Hệ thống tài khoản và cấu trúc dữ liệu của Optimism khá giống với Ethereum và cũng sử dụng trường StateRoot để phản ánh những thay đổi trong tập hợp trạng thái. Trình sắp xếp OP định kỳ tải một trường khóa có tên là OutputRoot lên Ethereum và trường OutputRoot được tính toán bởi StateRoot và hai trường còn lại.
Quay lại câu hỏi ban đầu. Khi bạn chạy node client của OP và tính toán StateRoot và OutputRoot hiện tại cục bộ, nếu bạn thấy kết quả bạn tính toán không nhất quán với kết quả do trình sắp xếp OP tải lên, bạn có thể khởi tạo bằng chứng gian lận. Vậy cơ chế cụ thể của nó là gì? Dưới đây chúng tôi sẽ giới thiệu lần lượt về xác minh trạng thái máy ảo MIPS và bằng chứng gian lận tương tác.
Máy ảo MIPS và cây Merkle bộ nhớ
Như đã đề cập trước đó, nếu tôi thấy có vấn đề với OutputRoot do trình sắp xếp OP gửi, tôi có thể khởi tạo "thách thức". Quá trình thách thức yêu cầu một loạt các hành động tương tác phải được hoàn thành trên chuỗi. Sau khi tương tác hoàn tất, hợp đồng thông minh có liên quan sẽ xác định xem trình sắp xếp OP có tải lên OutputRoot sai hay không.
Nếu bạn muốn sử dụng hợp đồng thông minh trên chuỗi để xác minh tính chính xác của OutputRoot, cách dễ nhất là triển khai một máy khách nút OP trên chuỗi Ethereum, sử dụng cùng các tham số đầu vào như trình sắp xếp OP, thực thi cùng một chương trình và kiểm tra xem kết quả tính toán có nhất quán hay không. Kế hoạch này được gọi là Chương trình chống lỗi, dễ triển khai ngoài chuỗi nhưng rất khó chạy trên chuỗi Ethereum. Bởi vì có hai vấn đề: 1. Hợp đồng thông minh trên Ethereum không thể tự động lấy các tham số đầu vào cần thiết để chống gian lận; 2. Giới hạn Gas của mỗi khối trong Ethereum bị giới hạn và không hỗ trợ các tác vụ tính toán quá phức tạp. Chúng tôi không thể triển khai đầy đủ máy khách nút OP trên chuỗi. Vấn đề đầu tiên tương đương với việc cho phép hợp đồng thông minh trên chuỗi đọc dữ liệu ngoài chuỗi, có thể giải quyết bằng giải pháp tương tự như oracle. OP đã triển khai hợp đồng PreimageOracle đặc biệt trên chuỗi Ethereum. Các hợp đồng liên quan đến chống gian lận có thể đọc dữ liệu cần thiết trong PreimageOracle.
Về lý thuyết, bất kỳ ai cũng có thể tải dữ liệu lên hợp đồng theo ý muốn, nhưng hệ thống chống gian lận của OP có cách để xác định xem dữ liệu có cần thiết hay không. Quy trình cụ thể sẽ không được thảo luận ở đây vì nó không quan trọng đối với chủ đề cốt lõi của bài viết này.
Đối với câu hỏi thứ hai, nhóm phát triển OP đã viết một máy ảo MIPS sử dụng Solidity, triển khai một số chức năng trong máy khách nút OP, đủ cho hệ thống chống gian lận. MIPS là kiến trúc tập lệnh CPU phổ biến và mã của trình sắp xếp OP được viết bằng các ngôn ngữ cấp cao như Golang/Rust. Chúng ta có thể biên dịch các chương trình được viết bằng Golang/Rust thành các chương trình MIPS, sau đó xử lý chúng thông qua máy ảo MIPS trên chuỗi Ethereum.
Nhóm phát triển của OP đã sử dụng Golang để viết chương trình đơn giản nhất cần thiết để chống gian lận, về cơ bản là phù hợp với các chức năng mô-đun thực hiện giao dịch, tạo khối và OutputRoot trong nút OP. Tuy nhiên, quy trình hợp lý này vẫn chưa thể được "triển khai đầy đủ".
Tức là mỗi khối OP chứa nhiều giao dịch. Sau khi xử lý xong lô giao dịch này, OutputRoot sẽ được lấy. Mặc dù bạn biết OutputRoot sai ở độ cao khối nào, nhưng việc chạy tất cả các giao dịch có trong khối trên chuỗi để chứng minh rằng OutputRoot tương ứng sai là không thực tế.
Ngoài ra, quy trình thực hiện của mỗi giao dịch liên quan đến việc xử lý theo thứ tự một loạt các mã lệnh MIPS. Bạn không thể chạy chuỗi các mã lệnh này trong máy ảo MIPS được triển khai theo hợp đồng trên chuỗi vì chi phí tính toán và mức tiêu thụ Gas liên quan quá lớn.
(Nguyên lý hoạt động của bộ lệnh MIPS)
Để đạt được mục đích này, nhóm Optimism đã thiết kế một hệ thống chống gian lận tương tác, có mục đích là tinh chỉnh sâu luồng xử lý giao dịch của OP. Từ toàn bộ quá trình tính toán của OutputRoot, chúng ta có thể thấy mã lệnh MIPS nào mà máy ảo MIPS của trình sắp xếp OP gặp lỗi khi xử lý. Nếu xác định được lỗi, có thể kết luận rằng OutputRoot do trình sắp xếp cung cấp là không hợp lệ.
Sau đó, vấn đề trở nên rõ ràng: quá trình xử lý các khối đóng gói giao dịch của trình sắp xếp OP có thể được chia nhỏ thành quá trình xử lý có thứ tự một số lượng lớn các mã lệnh MIPS. Sau khi mỗi mã lệnh MIPS được thực thi, hàm băm trạng thái của máy ảo sẽ thay đổi và các bản ghi này có thể được tóm tắt thành một cây Merkle.
Trong quy trình chống gian lận tương tác, cần xác định mã lệnh MIPS nào mà trình sắp xếp OP thực thi và mã băm trạng thái của máy ảo có vấn đề,sau đó tái tạo trạng thái của máy ảo MIPS tại thời điểm đó trên chuỗi, thực thi mã lệnh và quan sát xem mã băm trạng thái sau đó có nhất quán với kết quả do trình sắp xếp gửi hay không. Vì chỉ có một mã lệnh MIPS được thực thi trên chuỗi nên độ phức tạp không cao và quá trình tính toán có thể được hoàn tất trên chuỗi Ethereum. Nhưng để đạt được điều này, chúng ta cần tải thông tin trạng thái của máy ảo MIPS, chẳng hạn như một số dữ liệu bộ nhớ, lên chuỗi.
Ở cấp độ triển khai mã, hợp đồng thông minh liên quan đến bằng chứng gian lận trên chuỗi Ethereum sẽ hoàn tất quy trình thực thi mã lệnh MIPS cuối cùng thông qua hàm có tên là Bước sau:
_stateData và _proof trong các tham số hàm trên biểu thị các mục dữ liệu phụ thuộc của một lần thực thi mã lệnh MIPS duy nhất, chẳng hạn như trạng thái thanh ghi của máy ảo MIPS, hàm băm trạng thái bộ nhớ, v.v. Sơ đồ như sau:
Chúng ta có thể nhập các tham số môi trường của các máy ảo MIPS này thông qua _stateData và _proof, chạy một lệnh MIPS duy nhất trên chuỗi và thu được kết quả có thẩm quyền. Nếu kết quả có thẩm quyền thu được trên chuỗi không nhất quán với kết quả do trình sắp xếp gửi đến, điều đó có nghĩa là trình sắp xếp đang làm điều xấu.
Chúng tôi thường gọi hàm băm của _stateData là statehash, có thể hiểu nôm na là hàm băm của toàn bộ trạng thái máy ảo MIPS. Trong số nhiều trường của _stateData, memRoot là trường có thiết kế khéo léo nhất. Như chúng ta đã biết, một chương trình sẽ chiếm một lượng bộ nhớ lớn trong quá trình thực thi và CPU sẽ có các tương tác đọc và ghi với dữ liệu trong một số địa chỉ bộ nhớ. Do đó, khi chúng ta thực thi mã lệnh MIPS thông qua hàm VM.Step trên chuỗi, chúng ta cần cung cấp dữ liệu trong địa chỉ bộ nhớ của máy ảo MIPS.
OP sử dụng máy ảo MIPS 32 bit, bộ nhớ của máy này chứa tổng cộng 2 mũ 27 địa chỉ, có thể được tổ chức thành Cây Merkle nhị phân 28 lớp. Lớp dưới cùng có 2 mũ 27 lá, và mỗi lá ghi lại dữ liệu trong một địa chỉ bộ nhớ của máy ảo. Sau khi dữ liệu trong tất cả các nhánh được tổng hợp, giá trị băm được tính toán là memRoot. Hình sau đây cho thấy cấu trúc của cây Merkle ghi lại dữ liệu bộ nhớ của máy ảo MIPS:
Chúng ta cần cung cấp một phần nội dung trong địa chỉ bộ nhớ, được tải lên chuỗi Ethereum thông qua trường _proof trong hàm step. Tại đây, bạn cũng cần tải lên bằng chứng Merkle dựa trên cây Merkle trong bộ nhớ để chứng minh rằng dữ liệu do bạn/người sắp xếp cung cấp thực sự tồn tại trong cây Merkle trong bộ nhớ chứ không phải là dữ liệu bịa đặt.
Bằng chứng gian lận tương tác
Ở trên, chúng ta đã giải quyết được vấn đề thứ hai và hoàn tất việc thực thi mã lệnh MIPS trên chuỗi và xác minh trạng thái máy ảo, nhưng làm thế nào để đối thủ và trình sắp xếp có thể xác định được lệnh mã lệnh MIPS gây tranh cãi?
Tôi tin rằng nhiều người đã đọc lời giải thích đơn giản về bằng chứng gian lận tương tác trên Internet và đã nghe về sự phân đôi của nó. Nhóm OP đã phát triển một giao thức gọi là Trò chơi tranh chấp lỗi (FDG). Trong FDG, có hai vai trò: người thách đấu và người bảo vệ.
Nếu chúng ta thấy có vấn đề với OutputRoot được trình sắp xếp gửi đến chuỗi, thì chúng ta có thể đóng vai trò là người thách thức trong FDG và trình sắp xếp sẽ đóng vai trò là người bảo vệ. Để tạo điều kiện thuận lợi cho việc định vị các mã lệnh MIPS được đề cập ở trên cần được xử lý trên chuỗi, giao thức FDG yêu cầu những người tham gia xây dựng một cây Merkle cục bộ, được gọi là GameTree, có cấu trúc cụ thể như sau: Chúng ta có thể thấy rằng GameTree thực sự khá phức tạp, với mối quan hệ lồng nhau theo thứ bậc, bao gồm một cây cấp một và một cây con cấp hai. Nói cách khác, lá dưới cùng của cây cấp một tự nó chứa một cây.
Như đã giới thiệu trước đây, mỗi khối do trình sắp xếp tạo ra đều chứa một OutputRoot và các nút lá của cây cấp một của GameTree là OutputRoot của các khối khác nhau. Bên thách đấu và bên phòng thủ cần tương tác trên cây Merkle bao gồm Output Root để xác định OutputRoot của khối nào đang bị tranh chấp.
Sau khi xác định các khối đang tranh chấp, chúng ta sẽ đi sâu vào cấp độ thứ hai của GameTree. Cây cấp độ thứ hai cũng là cây Merkle và các nhánh cấp độ dưới cùng là hàm băm trạng thái của máy ảo MIPS được giới thiệu ở trên. Trong trường hợp chống gian lận, một số nút lá của GameTree do các bên tranh chấp xây dựng cục bộ sẽ không nhất quán và hàm băm trạng thái máy ảo sau khi xử lý một mã lệnh nhất định sẽ xuất hiện khác nhau.
Sau đó, hai bên đã tương tác nhiều lần trên chuỗi và cuối cùng đã xác định được khu vực tranh chấp và xác định được mã lệnh MIPS duy nhất cần chạy trên chuỗi.
Tại thời điểm này, chúng tôi đã hoàn tất toàn bộ quá trình chống gian lận tương tác. Tóm lại, bằng chứng gian lận tương tác bao gồm hai cơ chế cốt lõi: 1. Đầu tiên, FDG xác định vị trí mã lệnh MIPS cần được thực thi trên chuỗi và thông tin trạng thái VM tại thời điểm đó; 2. Thực thi mã lệnh trong máy ảo MIPS được triển khai trên chuỗi Ethereum để có được kết quả cuối cùng.
Chứng minh gian lận dựa trên ZK
Chúng ta có thể thấy rằng tương tác của chứng minh gian lận truyền thống ở trên cực kỳ phức tạp, đòi hỏi nhiều vòng tương tác trong quy trình FDG và sau đó phát lại một lệnh duy nhất trên chuỗi. Tuy nhiên, giải pháp này có một số khó khăn: 1. Nhiều vòng tương tác cần được kích hoạt trên chuỗi Ethereum, đòi hỏi hàng chục tương tác và sẽ phát sinh rất nhiều chi phí gas; 2. Quá trình chứng minh gian lận tương tác rất dài. Sau khi tương tác được bắt đầu, Rollup không thể thực hiện giao dịch bình thường; 3. Việc triển khai một VM cụ thể trên chuỗi để phát lại hướng dẫn phức tạp hơn và độ khó phát triển cực kỳ cao. Để giải quyết những vấn đề này, Optimism đã chính thức đề xuất khái niệm ZK Fraud Proof. Cốt lõi là khi người thách thức đưa ra thách thức, anh ta chỉ định một giao dịch mà anh ta tin rằng cần phải được phát lại trên chuỗi. Trình tự Rollup cung cấp bằng chứng ZK cho giao dịch bị thách thức, được xác minh bởi hợp đồng thông minh trên Ethereum. Nếu xác minh thành công, có thể coi là luồng xử lý của giao dịch là chính xác và nút Rollup không làm bất cứ điều gì xấu.
Challenger trong hình trên là Challenger, còn Defender là OP sequencer. Trong những trường hợp bình thường, trình sắp xếp OP tạo ra các khối dựa trên các giao dịch đã nhận và gửi các cam kết trạng thái của các khối khác nhau tới Ethereum, có thể được coi đơn giản là giá trị băm của khối. Người thách đấu có thể thách đấu dựa trên khối băm. Sau khi chấp nhận thử thách, Defender tạo ra bằng chứng ZK để chứng minh rằng không có lỗi trong kết quả tạo khối. Cây cảnh trong hình trên thực chất là công cụ tạo ra ZK Proof.
So với bằng chứng gian lận tương tác, lợi thế lớn nhất của ZK Fraud Proof là nó thay đổi nhiều vòng tương tác thành một vòng tạo bằng chứng ZK và xác minh trên chuỗi, giúp tiết kiệm rất nhiều thời gian và chi phí gas. So với ZK Rollup, OP Rollup dựa trên ZK Fraud Proof không cần tạo bằng chứng cho từng khối. Nó chỉ tạm thời tạo bằng chứng ZK khi bị thách thức, điều này cũng làm giảm chi phí tính toán của nút Rollup.
Ý tưởng về bằng chứng gian lận dựa trên ZK cũng được BitVM2 áp dụng. Các dự án sử dụng BitVM2, chẳng hạn như Bitlayer, Goat Network, ZKM, Fiama, v.v., triển khai chương trình xác minh ZK Proof thông qua các tập lệnh Bitcoin và đơn giản hóa đáng kể kích thước của chương trình cần tải lên chuỗi. Do giới hạn về không gian, bài viết này sẽ không đi sâu vào chi tiết. Bạn có thể chờ các bài viết tiếp theo của chúng tôi về BitVM2 để hiểu sâu hơn về lộ trình triển khai của nó. Hãy theo dõi!
Catherine
