Như mọi người biết, bằng chứng gian lận là một giải pháp kỹ thuật phổ biến trong không gian blockchain. Chúng bắt nguồn từ cộng đồng Ethereum và đã được các giải pháp Ethereum Layer 2 nổi tiếng như Arbitrum và Optimism áp dụng. Sau sự phát triển của hệ sinh thái Bitcoin vào năm 2023, Robin Linus đề xuất một giải pháp gọi là BitVM, dựa trên các công nghệ Bitcoin hiện có như Taproot, tập trung vào bằng chứng gian lận và cung cấp một mô hình an ninh mới cho Bitcoin Layer 2 hoặc cầu nối.

BitVM đã ra mắt một số phiên bản lý thuyết, từ BitVM0 sớm nhất, sử dụng mạch mạch cổng logic như nguyên tố, đến các phiên bản sau như BitVM2, tập trung vào Bằng Chứng Gian Lận ZK và mạch xác minh Groth16. Các con đường triển khai kỹ thuật liên quan đến BitVM đã phát triển và trưởng thành, thu hút sự chú ý của nhiều chuyên gia trong ngành. Các dự án như Bitlayer, Citrea, BOB, Fiamma và Goat Network đều sử dụng BitVM là một trong những công nghệ cốt lõi của họ, triển khai các phiên bản khác nhau dựa trên nền tảng này.

Với sự khan hiếm và phức tạp của các giải thích công khai về BitVM, chúng tôi đã phát động 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 liên kết sâu sắc 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 ZK, sử dụng ngôn ngữ đơn giản và dễ hiểu để giải thích những khái niệm này.

(Cơ chế chứng minh gian lận tương tác của Nguyên tắc lạc quan)

OutputRoot và StateRoot

Optimism là một dự án Optimistic Rollup nổi tiếng, và cơ sở hạ tầng của nó bao gồm một bộ ghi chú (với các mô-đun chính bao gồm op-node, op-geth, op-batcher và op-proposer) và hợp đồng thông minh trên chuỗi Ethereum.

Sau khi trình tự xử lý một lô dữ liệu giao dịch, dữ liệu DA này sẽ được gửi đến Ethereum. Miễn là bạn có khả năng chạy một máy khách nút Optimism, bạn có thể tải xuống dữ liệu được tải lên bởi trình tự vào máy địa phương của bạn. Sau đó, bạn có thể thực thi các giao dịch này ở cấp địa phương và tính toán băm tập hợp 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.v.).

Nếu bộ xử lý tải lên một băm tập hợp trạng thái không chính xác lên Ethereum, băm tập hợp trạng thái mà bạn tính toán cục bộ sẽ khác nhau. Trong trường hợp này, bạn có thể đưa ra một thách thức thông qua hệ thống bằng chứng gian lận. Dựa trên sự xét xử, hệ thống sẽ áp đặt hạn chế hoặc xử phạt đối với bộ xử lý hoặc không hành động.

Khi đề cập đến thuật ngữ “state set,” các chuỗi khối dựa trên EVM thường sử dụng một cấu trúc dữ liệu giống như Merkle Tree để ghi lại state set, được gọi là World State Trie. Sau khi giao dịch được thực thi, trạng thái của một số tài khoản sẽ thay đổi, và World State Trie cũng sẽ thay đổi, dẫn đến việc thay đổi đến hash cuối cùng của nó. Ethereum gọi hash cuối cùng của World State Trie là StateRoot, đại diện cho các thay đổi trong state set.

Sơ đồ sau minh họa cấu trúc của stateRoot của Ethereum. Như chúng ta có thể thấy, số dư của các tài khoản khác nhau, mã hash liên quan đến các tài khoản hợp đồng thông minh, và dữ liệu khác đều được tổng hợp vào World State Trie, từ đó stateRoot được tính toán.

Hệ thống tài khoản và cấu trúc dữ liệu của Optimism nói chung tương thích với Ethereum, cũng sử dụng trường StateRoot để biểu diễn các thay đổi trong tập hợp trạng thái. Người ghi sổ OP định kỳ tải lên một trường khóa gọi là OutputRoot đến Ethereum, được tính toán dựa trên StateRoot và hai trường khác.

Quay trở lại câu hỏi ban đầu, khi bạn chạy khách hàng nút OP và tính toán StateRoot và OutputRoot hiện tại cục bộ, nếu bạn phát hiện rằng kết quả bạn tính toán không khớp với những kết quả được tải lên bởi trình tự OP, bạn có thể khởi động một bằng chứng gian lận. Vậy, cơ chế cụ thể đằng sau điều này là gì? Dưới đây, chúng tôi sẽ giới thiệu lần lượt xác minh trạng thái máy ảo MIPS và bằng chứng gian lận tương tác.

MIPS Máy Ảo và Cây Merkle Bộ Nhớ

Như đã đề cập trước đó, giả sử bạn phát hiện ra rằng OutputRoot được gửi bởi OP sequencer là không chính xác, và bạn muốn khởi đầu một “thách thức.” Quá trình thách thức yêu cầu hoàn thành một loạt các tương tác trên chuỗi, sau đó các hợp đồng thông minh liên quan sẽ xác định xem OP sequencer đã tải lên một OutputRoot không chính xác hay không.

Để xác minh tính chính xác của OutputRoot trên chuỗi bằng cách sử dụng hợp đồng thông minh, phương pháp đơn giản nhất sẽ là triển khai một client nút OP trên chuỗi Ethereum, sử dụng các tham số đầu vào giống như bộ sắp xếp OP, thực thi chương trình tương tự và kiểm tra xem kết quả tính toán khớp hay không. Phương pháp này được gọi là Chương trình chứng minh lỗi. Mặc dù triển khai ngoại chuỗi khá dễ dàng, nhưng rất khó chạy trên chuỗi Ethereum do hai vấn đề:

1. Hợp đồng thông minh trên Ethereum không thể tự động nhận được các tham số đầu vào cần thiết cho bằng chứng gian lận.
2. Giới hạn gas block của Ethereum là hạn chế, và nó không hỗ trợ các nhiệm vụ tính toán cực kỳ phức tạp. Do đó, chúng tôi không thể triển khai đầy đủ nguồn cấp dữ liệu OP trên chuỗi.

Vấn đề đầu tiên tương đương với việc yêu cầu hợp đồng thông minh trên chuỗi đọc dữ liệu ngoại chuỗi, điều này có thể được giải quyết bằng cách sử dụng một giải pháp tương tự như một oracle. OP đã triển khai hợp đồng PreimageOracle trên chuỗi Ethereum, và các hợp đồng liên quan đến bằng chứng gian lận có thể đọc dữ liệu cần thiết từ hợp đồng này. Lý thuyết, bất kỳ ai cũng có thể tải lên dữ liệu lên hợp đồng này, nhưng hệ thống chứng minh gian lận của OP có cách để xác minh liệu dữ liệu đó có cần thiết hay không, mặc dù quá trình này sẽ không được mô tả chi tiết ở đây, vì nó không quan trọng đối với chủ đề chính của bài viết này.

Đối với vấn đề thứ hai, nhóm phát triển OP đã viết một máy ảo MIPS bằng Solidity để thực hiện một số chức năng của khách hàng nút OP đủ cho hệ thống bằng chứng gian lận. MIPS là một kiến trúc bộ chỉ thị CPU phổ biến, và mã nguồn của trình xử lý 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 Golang/Rust thành các chương trình MIPS và xử lý chúng thông qua máy ảo MIPS trên chuỗi Ethereum.

Nhóm phát triển OP đã viết một chương trình đơn giản bằng Golang cho bằng chứng gian lận, mô phỏng các module trong nút OP thực thi giao dịch, tạo khối và tạo ra OutputRoot. Tuy nhiên, chương trình đơn giản này vẫn không thể “thực thi hoàn toàn.” Nói cách khác, mỗi khối OP chứa nhiều giao dịch. Sau khi xử lý lô giao dịch này, sẽ tạo ra một OutputRoot. Trong khi bạn biết rằng OutputRoot của chiều cao khối nào đó không chính xác, việc chạy tất cả các giao dịch trong khối đó trên chuỗi để chứng minh rằng OutputRoot tương ứng là sai là không thực tế. Hơn nữa, trong quá trình thực thi mỗi giao dịch, một loạt các mã opcode MIPS được xử lý theo trình tự. Sẽ không thực tế để chạy toàn bộ loạt mã opcode này trên máy ảo MIPS được thực thi trong một hợp đồng chuỗi, vì áp lực tính toán và tiêu thụ gas sẽ quá lớn.

(Nguyên lý hoạt động của Bộ chỉ thị MIPS)

Để giải quyết vấn đề này, nhóm Optimism đã thiết kế một hệ thống tương tác chống gian lận nhằm phân tích sâu hơn quy trình xử lý giao dịch của OP. Bằng cách quan sát toàn bộ quá trình tính toán của OutputRoot, hệ thống xác định tại opcode MIPS nào mà máy ảo MIPS của OP sequencer đã mắc lỗi. Nếu lỗi được xác nhận, có thể kết luận rằng OutputRoot được cung cấp bởi sequencer là không hợp lệ.

Do đó, vấn đề trở nên rõ ràng: quá trình đóng gói giao dịch của trình tự OP thành các khối có thể được chia nhỏ thành việc xử lý theo thứ tự của một số lượng lớn các mã lệnh MIPS. Sau mỗi mã lệnh MIPS được thực thi, băm trạng thái của máy ảo thay đổi. Những bản ghi này có thể được tổng hợp thành một cây Merkle.

Trong quá trình chứng minh gian lận tương tác, mục tiêu là xác định sau mã OP MIPS nào mà băm trạng thái máy ảo của bộ điều khiển OP trở nên không chính xác, sau đó tái tạo trạng thái của máy ảo MIPS trên chuỗi, thực thi mã OP và quan sát xem băm trạng thái kết quả có khớp với băm được nộp bởi bộ điều khiển không. Vì chỉ có một mã OP MIPS được thực thi trên chuỗi, độ phức tạp là thấp và quá trình tính toán có thể hoàn thành trên chuỗi Ethereum. Tuy nhiên, để đạt được điều này, chúng ta cần tải lên thông tin trạng thái của máy ảo MIPS, chẳng hạn như dữ liệu bộ nhớ một phần, lên chuỗi.

Về việc triển khai mã, các hợp đồng thông minh trên chuỗi Ethereum liên quan đến bằng chứng gian lận sẽ hoàn thành quá trình thực thi opcode MIPS cuối cùng thông qua một chức năng được gọi là Bước:

Các tham số trong hàm trên, _stateData và _proof, đại diện cho các mục dữ liệu phụ thuộc cho việc thực thi của một lệnh opcode MIPS duy nhất, chẳng hạn như trạng thái đăng ký của máy ảo MIPS, băm trạng thái bộ nhớ, v.v. Sơ đồ được hiển thị dưới đây:

Chúng ta có thể nhập các thông số môi trường máy ảo MIPS này thông qua _stateData và _proof, chạy một chỉ thị MIPS duy nhất trên chuỗi và nhận được một kết quả uy tín. Nếu kết quả uy tín nhận được trên chuỗi khác biệt so với kết quả được gửi bởi sequencer, điều này cho thấy sequencer là độc ác.

Chúng tôi thường đề cập đến hash của _stateData như statehash, có thể được hiểu đại khái là hash của toàn bộ trạng thái máy ảo MIPS. Trong số các trường trong _stateData, memRoot là thiết kế tinh xảo nhất. Như chúng ta đã biết, trong quá trình thực thi chương trình, một lượng lớn bộ nhớ được sử dụng, và CPU tương tác với dữ liệu ở một số địa chỉ bộ nhớ cụ thể bằng cách đọc và ghi. Do đó, khi chúng ta thực thi một opcode MIPS trên chuỗi thông qua hàm VM.Step, chúng ta cần cung cấp dữ liệu từ một số địa chỉ bộ nhớ cụ thể trong máy ảo MIPS.

OP sử dụng kiến trúc 32 bit cho máy ảo MIPS, và bộ nhớ của nó chứa 2^27 địa chỉ, có thể được tổ chức thành cây Merkle nhị phân 28 cấp. Các nút lá ở cấp thấp nhất đếm 2^27, với mỗi nút lá ghi lại dữ liệu từ một địa chỉ bộ nhớ cụ thể của máy ảo. Hash được tính từ tất cả dữ liệu trong các lá là memRoot. Sơ đồ dưới đâ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 nội dung từ một số địa chỉ bộ nhớ cụ thể, và nội dung này được tải lên chuỗi Ethereum thông qua trường _proof trong hàm bước. Ngoài ra, bằng chứng Merkle dựa trên cây Merkle bộ nhớ cần được tải lên để chứng minh rằng dữ liệu bạn (hoặc người sắp xếp) cung cấp thực sự tồn tại trong cây Merkle bộ nhớ, thay vì được chế tạo.

Interactive bằng chứng gian lận

Trong phần trước, chúng tôi đã giải quyết vấn đề thứ hai bằng cách hoàn thành việc thực thi trên chuỗi của các mã lệnh MIPS và xác minh trạng thái máy ảo. Nhưng làm thế nào để người thách thức và người xếp hàng có thể xác định chính xác mã lệnh MIPS bị tranh cãi?

Nhiều người có thể đã đọc những giải thích đơn giản về bằng chứng gian lận tương tác trực tuyến và nghe về phương pháp tìm kiếm nhị phân đứng sau chúng. Nhóm OP đã phát triển một giao thức gọi là Trò chơi Tranh chấp Lỗi (FDG). Giao thức FDG bao gồm hai vai trò: thách thức và bảo vệ.

Nếu chúng tôi phát hiện rằng OutputRoot được gửi bởi người xếp hàng trên chuỗi không đúng, chúng tôi có thể đóng vai trò là người thách thức trong FDG, với người xếp hàng đóng vai trò là người bảo vệ. Để giúp xác định mã MIPS cần được xử lý trên chuỗi, giao thức FDG yêu cầu các bên tham gia xây dựng cây Merkle cục bộ gọi là GameTree, cấu trúc cụ thể của nó như sau:

Chúng ta có thể thấy rằng GameTree khá phức tạp, với cấu trúc lồng ghép theo hình thức phân cấp, bao gồm một cây cấp đầu tiên và các cây con ở cấp độ thứ hai. Nói cách khác, các nút lá của cây cấp đầu tiên chứa một cây con.

Như đã đề cập trước đó, mỗi khối được tạo ra bởi bộ sắp xếp chứa một OutputRoot, và các nút lá của cây cấp đầu tiên trong GameTree đại diện cho các OutputRoots của các khối khác nhau. Người thách thức và người bảo vệ cần tương tác trong cây Merkle được hình thành bởi các OutputRoots để xác định OutputRoot của khối nào đang gây tranh cãi.

Sau khi xác định khối bị tranh cãi, chúng tôi đi sâu vào cấp độ thứ hai của GameTree. Cây cấp độ thứ hai cũng là một cây Merkle, với các nút lá của nó là các băm trạng thái của máy ảo MIPS, như đã giới thiệu trước đó. Trong kịch bản bằng chứng gian lận, người thách thức và người bảo vệ sẽ có sự không nhất quán trong các nút lá của GameTree mà họ xây dựng cục bộ. Băm trạng thái sau khi xử lý một mã opcode cụ thể sẽ khác nhau.

Sau nhiều tương tác trên chuỗi, các bên cuối cùng xác định được mã opcode tranh chấp chính xác, xác định mã opcode MIPS cụ thể cần chạy trên chuỗi.

Tại thời điểm này, chúng tôi đã hoàn thành toàn bộ quy trình bằng chứng gian lận tương tác. Để tóm lại, hai cơ chế cốt lõi của bằng chứng gian lận tương tác là:

1. FDG (Fault Dispute Game) đầu tiên xác định mã opcode MIPS cần phải được thực thi trên chuỗi, cùng với thông tin trạng thái VM tại thời điểm đó;
2. Máy ảo MIPS được triển khai trên chuỗi Ethereum thực thi mã opcode, tạo ra kết quả cuối cùng.

Bằng chứng gian lận ZK

Bằng chứng gian lận ZK Như chúng ta có thể thấy, phương pháp bằng chứng gian lận truyền thống liên quan đến các tương tác rất phức tạp, đòi hỏi nhiều vòng tương tác trong quá trình FDG và việc chạy lại từng hướng dẫn cá nhân trên chuỗi. Tuy nhiên, giải pháp này có một số thách thức:

Cần kích hoạt nhiều vòng tương tác trên chuỗi Ethereum, dẫn đến hàng chục lượt tương tác gây ra chi phí gas đáng kể. 2. Quá trình chứng minh gian lận tương tác mất thời gian, và khi tương tác bắt đầu, Rollup không thể xử lý 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 các hướng dẫn rất phức tạp, với độ khó phát triển cao.

Để giải quyết những vấn đề này, Optimism giới thiệu khái niệm Bằng chứng gian lận ZK. Ý tưởng cốt lõi là khi một người đốt đánh giá một thách thức, họ xác định giao dịch họ tin rằng cần phải được chơi lại trên chuỗi. Sequencer Rollup cung cấp một bằng chứng ZK cho giao dịch bị thách thức, sau đó được xác minh bởi một hợp đồng thông minh trên chuỗi Ethereum. Nếu việc xác minh thành công, kết luận rằng không có lỗi trong việc xử lý giao dịch, và nút Rollup không có lỗi.

Trong sơ đồ, Challengerđề cập đến bên phía đưa ra thách thức, và Defenderlà trình tự OP. Dưới điều kiện bình thường, trình tự OP tạo ra các khối dựa trên các giao dịch nhận được và gửi các cam kết trạng thái của các khối khác nhau đến Ethereum. Những cam kết trạng thái này có thể đơn giản được hiểu là các giá trị băm của các khối. Người thách thức có thể thách thức dựa trên giá trị băm khối. Sau khi chấp nhận thách thức, Người bảo vệ tạo ra một bằng chứng ZK để chứng minh rằng kết quả tạo khối là chính xác. Trong sơ đồ, Bonsailà thực sự là một công cụ tạo bằng chứng ZK. So với bằng chứng gian lận tương tác, ưu điểm lớn nhất của Bằng chứng gian lận ZK là nó thay thế nhiều vòng tương tác bằng một vòng tạo bằng chứng ZK và xác minh trên chuỗi. Điều này tiết kiệm thời gian đáng kể và giảm chi phí gas. Hơn nữa, khác với ZK Rollups, OP Rollups dựa trên Bằng chứng gian lận ZK không yêu cầu tạo bằng chứng mỗi khi một khối được tạo ra. Thay vào đó, họ chỉ tạo ra một bằng chứng ZK tạm thời khi bị thách thức, điều này cũng giảm chi phí tính toán cho các nút Rollup.

Khái niệm ZK Fraud Proof cũng được BitVM2 áp dụng. Các dự án sử dụng BitVM2, chẳng hạn như Bitlayer, Goat Network, ZKM và Fiama, triển khai chương trình xác minh ZK Proof thông qua các tập lệnh Bitcoin, đơn giản hóa đáng kể kích thước của các chương trình cần được đưa vào chuỗi. Do hạn chế về không gian, bài viết này sẽ không đi sâu vào chi tiết về chủ đề này. Hãy theo dõi bài viết sắp tới của chúng tôi về BitVM2 để hiểu sâu hơn về lộ trình triển khai của nó!

Miễn trừ trách nhiệm:

1. Bài viết này được sao chép từ [GodRealmX] , bản quyền thuộc về tác giả gốc [Shew & Noah], nếu bạn có bất kỳ ý kiến nào về việc sao chép, vui lòng liên hệ Cổng Tìm hiểu và nhóm sẽ xử lý sớm nhất theo các thủ tục liên quan.
2. Tuyên bố từ chối trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ đại diện cho quan điểm cá nhân của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Các phiên bản ngôn ngữ khác của bài viết được dịch bởi nhóm Gate Learn và không được đề cập trong Gate.io, bài dịch không được sao chép, phân phối hoặc đạo văn.