TL;DR

Giới thiệu:

Bài viết này cung cấp giải thích về sách trắng của BitVM, giải thích cách tiếp cận của BitVM: Dữ liệu ban đầu không cần phải có trên chuỗi; nó được xuất bản và lưu trữ ngoài chuỗi, chỉ có Cam kết được lưu trữ trên blockchain.

Tiêu đề bài viết gốc được chuyển tiếp: Giải thích đơn giản về BitVM: Cách xác minh bằng chứng gian lận trên Blockchain BTC (Thực thi EVM hoặc các mã máy ảo khác)

Lời nói đầu: Hiện tại, Bitcoin Lớp 2 đã trở thành xu hướng, với hàng chục dự án tự nhận mình là “Bitcoin Lớp 2”. Nhiều người trong số này, tự xưng là “Rollups”, tuyên bố rằng họ đang sử dụng phương pháp tiếp cận được đề xuất trong báo cáo chính thức của BitVM, định vị BitVM là một phần nổi bật của hệ sinh thái Bitcoin.

Tuy nhiên, hầu hết các tài liệu hiện có về BitVM không giải thích các nguyên tắc của nó theo thuật ngữ thông thường. Bài viết này, dựa trên việc chúng tôi đọc báo cáo chính thức BitVM dài 8 trang và sau khi tham khảo các tài nguyên liên quan đến Taproot, cây MAST và Bitcoin Script, sẽ đưa ra một bản tóm tắt đơn giản. Để hỗ trợ cho sự hiểu biết, chúng tôi đã thay đổi một số cách diễn đạt so với những cách diễn đạt trong báo cáo chính thức của BitVM, giả sử người đọc có một số kiến thức về Lớp 2 và có thể nắm bắt được ý tưởng cơ bản về “bằng chứng gian lận”.

Khái niệm sơ bộ về BitVM có thể được tóm tắt trong một vài câu: nó loại bỏ nhu cầu về dữ liệu trên chuỗi, ban đầu xuất bản và lưu trữ dữ liệu ngoài chuỗi, chỉ với một Cam kết được lưu trữ trên chuỗi khối. Trong trường hợp có thách thức hoặc bằng chứng gian lận, chỉ những dữ liệu cần thiết mới được đưa vào chuỗi để chứng minh mối liên hệ của nó với Cam kết trên blockchain. Sau đó, mạng chính BTC sẽ xác minh dữ liệu trên chuỗi xem có vấn đề gì không và liệu nhà sản xuất dữ liệu (nút xử lý giao dịch) có tham gia vào các hoạt động độc hại hay không. Cách tiếp cận này tuân thủ nguyên tắc Razor của Occam— “Các thực thể không nên được nhân lên một cách không cần thiết” (nếu nó có thể ở ngoài chuỗi, hãy giữ nó ở ngoài chuỗi).

Nội dung chính: Cái gọi là chương trình xác minh bằng chứng gian lận blockchain BTC dựa trên BitVM, theo thuật ngữ thông thường:

1. Thứ nhất, máy tính/bộ xử lý là một hệ thống đầu vào-đầu ra bao gồm một số lượng lớn các mạch cổng logic. Một trong những ý tưởng cốt lõi của BitVM là sử dụng Bitcoin Script để mô phỏng hiệu ứng đầu vào-đầu ra của các mạch cổng logic. Về mặt lý thuyết, miễn là các mạch cổng logic có thể được mô phỏng, thì có thể tạo ra một máy Turing, hoàn thành tất cả các nhiệm vụ có thể tính toán được. Điều này có nghĩa là nếu bạn có đủ nguồn lực và nhân lực, bạn có thể tập hợp một nhóm kỹ sư để trước tiên mô phỏng các mạch cổng logic bằng mã Bitcoin Script thô sơ, sau đó sử dụng một lượng lớn mạch cổng logic để triển khai các chức năng của EVM hoặc WASM .

(Ảnh chụp màn hình này là từ một trò chơi giáo dục: “Turing Complete”, trong đó nội dung cốt lõi là xây dựng một bộ xử lý CPU hoàn chỉnh, đặc biệt là sử dụng các mạch cổng logic như cổng NAND.)

Một số người đã ví cách tiếp cận của BitVM giống như việc xây dựng bộ xử lý M1 trong “Minecraft” bằng cách sử dụng các mạch đá đỏ. Hoặc, nó giống như việc xây dựng Tòa nhà Empire State ở New York bằng các khối LEGO.

(Người ta nói rằng ai đó đã dành một năm để xây dựng một “bộ xử lý” trong “Minecraft”.)

1. Vậy tại sao lại sử dụng Bitcoin Script để mô phỏng EVM hoặc WASM? Chẳng phải điều đó rất cồng kềnh sao? Lý do là hầu hết các giải pháp Bitcoin Layer 2 thường chọn hỗ trợ các ngôn ngữ cấp cao như Solidity hay Move, trong khi ngôn ngữ duy nhất hiện có thể chạy trực tiếp trên blockchain Bitcoin là Bitcoin Script. Ngôn ngữ này là ngôn ngữ nguyên thủy, bao gồm một loạt các mã opcode duy nhất và chưa hoàn chỉnh bằng Turing.

(Ví dụ về mã Bitcoin Script)

Nếu Lớp 2 của Bitcoin nhằm mục đích xác minh bằng chứng gian lận trên Lớp 1 như các giải pháp Lớp 2 của Ethereum như Arbitrum, để kế thừa rất nhiều tính bảo mật của BTC, thì nó cần phải xác minh trực tiếp “giao dịch bị tranh chấp” hoặc “mã hoạt động bị tranh chấp” trên chuỗi khối BTC. Điều này có nghĩa là ngôn ngữ Solidity/mã EVM được Lớp 2 sử dụng cần phải được thực thi lại trên chuỗi khối Bitcoin. Thử thách tóm gọn lại là:

Sử dụng Bitcoin Script, ngôn ngữ lập trình gốc nhưng thô sơ của Bitcoin, để đạt được hiệu quả của EVM hoặc các máy ảo khác.

Do đó, từ góc độ các nguyên tắc biên dịch, cách tiếp cận BitVM chuyển các mã opcode EVM / WASM / JavaScript thành các mã opcode Bitcoin Script, với các mạch cổng logic đóng vai trò là biểu diễn trung gian (IR) giữa “mã opcode EVM -> mã opcode Bitcoin Script”.

(Sách trắng BitVM thảo luận về cách tiếp cận chung để thực hiện một số “hướng dẫn tranh chấp” nhất định trên chuỗi khối Bitcoin)

Dù sao, hiệu ứng cuối cùng được mô phỏng là xử lý các hướng dẫn mà ban đầu chỉ có thể được xử lý trên EVM / WASM, trực tiếp trên chuỗi khối Bitcoin. Mặc dù giải pháp này khả thi nhưng khó khăn nằm ở chỗ làm thế nào để sử dụng một số lượng lớn mạch cổng logic làm dạng trung gian để thể hiện tất cả các opcode EVM/WASM. Hơn nữa, việc sử dụng kết hợp các mạch cổng logic để thể hiện trực tiếp một số luồng xử lý giao dịch cực kỳ phức tạp có thể dẫn đến khối lượng công việc lớn.

1. Hãy cùng thảo luận về một khái niệm cốt lõi khác được đề cập trong báo cáo chính thức của BitVM, đó là “Bằng chứng gian lận tương tác” rất giống với khái niệm được Arbitrum sử dụng.

Bằng chứng gian lận tương tác liên quan đến một thuật ngữ được gọi là khẳng định. Thông thường, người đề xuất Lớp 2 (thường được thực hiện bởi trình sắp xếp thứ tự) xuất bản một xác nhận trên Lớp 1, tuyên bố rằng dữ liệu giao dịch nhất định và kết quả chuyển đổi trạng thái là hợp lệ và không có lỗi.

Nếu ai đó tin rằng khẳng định do người đề xuất gửi có vấn đề (dữ liệu liên quan không chính xác), tranh chấp sẽ xảy ra. Tại thời điểm này, người đề xuất và người thách đấu trao đổi thông tin theo từng vòng và sử dụng phương pháp tìm kiếm nhị phân trên dữ liệu đang tranh chấp để nhanh chóng xác định hướng dẫn hoạt động rất chi tiết và phân đoạn dữ liệu liên quan của nó.

Đối với hướng dẫn vận hành đang tranh chấp này (Mã OP), cần phải thực thi nó trực tiếp trên Lớp 1 cùng với các tham số đầu vào của nó và xác thực kết quả đầu ra (các nút Lớp 1 so sánh kết quả đầu ra mà chúng đã tính toán với kết quả đầu ra được người đề xuất công bố trước đó). Trong Arbitrum, điều này được gọi là “Bằng chứng gian lận một bước”. (Trong giao thức chống gian lận tương tác của Arbitrum, tìm kiếm nhị phân được sử dụng để nhanh chóng xác định hướng dẫn đang tranh chấp và kết quả thực thi của nó, sau đó bằng chứng gian lận một bước được gửi đến Lớp 1 để xác minh lần cuối).

Theo dõi về điều này:

1. Quá trình này mang tính tương tác, với việc cả hai bên thay phiên nhau. Một bên phân đoạn dữ liệu lịch sử có trong Khối tổng hợp và bên kia chỉ ra phân đoạn dữ liệu nào có vấn đề. Điều này giống như một phương pháp nhị phân (trong thực tế, là một quá trình thu hẹp dần phạm vi, N/K).

2. Sau đó, có thể xác định thêm giao dịch và kết quả nào có vấn đề, sau đó thu hẹp hơn nữa vào một lệnh máy cụ thể trong giao dịch đang bị tranh chấp đó.

3. Hợp đồng ChallengeManager chỉ kiểm tra xem “phân đoạn dữ liệu” được tạo bằng cách chia nhỏ dữ liệu gốc có hợp lệ hay không.

4. Sau khi người thách thức và người bị thách thức đã xác định được lệnh máy cần thách thức, người thách thức sẽ gọi oneStepProveExecution(), gửi bằng chứng gian lận một bước để chứng minh rằng có vấn đề với kết quả thực thi của lệnh máy này.

(Trong giao thức chống gian lận tương tác của Arbitrum, quy trình này bao gồm việc sử dụng tìm kiếm nhị phân để nhanh chóng xác định hướng dẫn đang tranh chấp và kết quả thực thi của nó từ dữ liệu do Người đề xuất công bố. Sau khi xác định phần dữ liệu hoặc mã hoạt động gây tranh cãi, bằng chứng gian lận một bước sẽ được gửi đến Lớp 1 để xác minh lần cuối.)

Người giới thiệu:

Cựu đại sứ kỹ thuật Arbitrum giải thích cấu trúc thành phần của Arbitrum (Phần 1)

(Biểu đồ luồng bằng chứng gian lận tương tác của Arbitrum, lời giải thích tương đối thô thiển)

Đến thời điểm này, khái niệm về bằng chứng gian lận một bước trở nên khá đơn giản: phần lớn các hướng dẫn giao dịch xảy ra trên Lớp 2 không cần phải được xác minh lại trên chuỗi khối BTC. Tuy nhiên, nếu một phân đoạn/mã hoạt động dữ liệu tranh chấp cụ thể bị thách thức thì nó phải được phát lại trên Lớp 1.

Nếu kết quả xác minh chỉ ra rằng dữ liệu được Người đề xuất công bố trước đó có vấn đề thì tài sản đặt cọc của Người đề xuất sẽ bị cắt giảm. Nếu Người thách thức bị phát hiện có lỗi thì tài sản đặt cược của Người thách đấu sẽ bị cắt giảm. Những người chứng minh không phản ứng kịp thời với các thách thức cũng có thể bị cắt giảm.

Arbitrum thực hiện các hiệu ứng nói trên thông qua các hợp đồng trên Ethereum, trong khi BitVM nhằm mục đích đạt được chức năng tương tự bằng cách sử dụng Bitcoin Script để triển khai khóa thời gian, đa chữ ký và các tính năng khác.

4.Sau khi thảo luận về “Bằng chứng gian lận tương tác” và “Bằng chứng gian lận một bước”, chúng ta sẽ nói về cây MAST và Bằng chứng Merkle. Trước đây, chúng tôi đã đề cập rằng trong giải pháp BitVM, lượng lớn dữ liệu giao dịch và mạch cổng logic được xử lý ngoài chuỗi ở Lớp 2 không được đưa trực tiếp vào chuỗi. Chỉ một lượng tối thiểu các mạch cổng dữ liệu/logic được đưa vào chuỗi khi cần thiết. Tuy nhiên, chúng tôi cần một cách để chứng minh rằng dữ liệu này, vốn ban đầu nằm ngoài chuỗi và bây giờ cần được đưa vào chuỗi, không phải là dữ liệu bịa đặt. Đây là lúc khái niệm Cam kết trong mật mã phát huy tác dụng và Bằng chứng Merkle là một dạng của Cam kết như vậy.

Đầu tiên, hãy nói về cây MAST. Tên đầy đủ của MAST là Cây cú pháp trừu tượng Merkelized, là sự chuyển đổi của AST (Cây cú pháp trừu tượng) từ lĩnh vực nguyên tắc biên dịch thành Cây Merkle. Vậy AST là gì? Nói một cách đơn giản, đó là cấu trúc dữ liệu dạng cây, chia nhỏ một lệnh phức tạp thành một loạt các đơn vị hoạt động cơ bản thông qua phân tích từ vựng.

(Ví dụ về cây AST sẽ chia nhỏ các phép tính đơn giản như “x=2, y=x*3” thành các mã và dữ liệu hoạt động cơ bản. )

Khi đó, cây MAST là kết quả của việc áp dụng Merkleization cho cây AST, hỗ trợ Bằng chứng Merkle. Một ưu điểm của cây Merkle là khả năng “nén” dữ liệu một cách hiệu quả. Ví dụ: nếu bạn muốn xuất bản một phân đoạn dữ liệu từ cây Merkle trên chuỗi khối BTC khi cần thiết, đồng thời làm cho nó đáng tin rằng phân đoạn dữ liệu này thực sự tồn tại trên cây Merkle và không được chọn tùy tiện, bạn sẽ làm gì?

Bạn chỉ cần ghi lại trước Root của cây Merkle trên blockchain. Trong tương lai, việc đưa ra Bằng chứng Merkle chứng minh một phần dữ liệu tồn tại trên cây Merkle tương ứng với Gốc là đủ.

(Mối quan hệ giữa Merkle Proof/Branch và Root)

Do đó, không cần lưu trữ cây MAST hoàn chỉnh trên chuỗi khối BTC; chỉ cần tiết lộ trước Root của nó dưới dạng Cam kết là đủ. Khi cần thiết, việc trình bày phân đoạn dữ liệu + Bằng chứng Merkle/Chi nhánh là đủ. Điều này làm giảm đáng kể lượng dữ liệu trên chuỗi trong khi vẫn đảm bảo rằng dữ liệu trên chuỗi thực sự tồn tại trên cây MAST. Hơn nữa, chỉ tiết lộ một phần nhỏ các phân đoạn dữ liệu + Bằng chứng Merkle trên chuỗi khối BTC, thay vì tất cả dữ liệu, có thể tăng cường đáng kể khả năng bảo vệ quyền riêng tư.

Tài liệu tham khảo:Giữ lại dữ liệu và chống gian lận: Tại sao Plasma không hỗ trợ hợp đồng thông minh

(Ví dụ về cây MAST)

Trong giải pháp của BitVM, tất cả các mạch cổng logic được thể hiện bằng các tập lệnh Bitcoin, được tổ chức thành một cây MAST khổng lồ. Các lá dưới cùng của cây này, được biểu thị là Nội dung trong sơ đồ, tương ứng với các mạch cổng logic được triển khai trong tập lệnh Bitcoin. Người đề xuất của Lớp 2 thường xuyên xuất bản gốc của cây MAST trên chuỗi khối BTC, với mỗi cây MAST được liên kết với một giao dịch liên quan đến tất cả các tham số đầu vào/mã hoạt động/mạch cổng logic của nó. Điều này hơi giống với việc Người đề xuất xuất bản Khối tổng hợp của Arbitrum trên chuỗi khối Ethereum.

Khi tranh chấp xảy ra, người thách thức tuyên bố trên blockchain BTC về Root mà họ muốn thách thức, sau đó yêu cầu Người đề xuất tiết lộ một phân đoạn dữ liệu cụ thể tương ứng với Root. Sau đó, Người đề xuất đưa ra Bằng chứng Merkle, liên tục tiết lộ các phân đoạn nhỏ trong chuỗi dữ liệu của cây MAST cho đến khi mạch cổng logic tranh chấp được định vị chung với người thách thức. Sau đó, một Slash có thể được thực thi.

(Nguồn:https://medium.com/crypto-garage/deep-dive-into-bitvm-computing-paradigm-to-express-turing-complete-bitcoin-contracts-1c6cb05edfca)

1. Cho đến thời điểm này, các khía cạnh quan trọng nhất của giải pháp BitVM đã được đề cập phần lớn. Mặc dù một số chi tiết có thể vẫn còn hơi mơ hồ nhưng tin rằng người đọc có thể nắm được bản chất và những điểm chính của BitVM. Về “cam kết giá trị bit” được đề cập trong báo cáo nghiên cứu chuyên sâu của mình, nó được thiết kế để ngăn Người đề xuất gán cả 0 và 1 cho các giá trị đầu vào của cổng logic khi bị thách thức và buộc phải xác minh mạch cổng logic trên chuỗi, do đó tạo ra sự mơ hồ và sự nhầm lẫn.

Tóm lại, sơ đồ BitVM bắt đầu bằng cách sử dụng tập lệnh Bitcoin để thể hiện các mạch cổng logic, sau đó sử dụng các mạch này để thể hiện các opcode của EVM/các VM khác, từ đó thể hiện luồng xử lý của bất kỳ lệnh giao dịch cụ thể nào và cuối cùng tổ chức chúng thành cây Merkle/cây MAST. Nếu luồng xử lý giao dịch được biểu thị bằng cây như vậy rất phức tạp thì nó có thể dễ dàng vượt quá 100 triệu lá, do đó, điều quan trọng là phải giảm thiểu không gian khối bị chiếm giữ bởi các cam kết và phạm vi bị ảnh hưởng bởi bằng chứng gian lận.

Mặc dù bằng chứng gian lận một bước chỉ yêu cầu một lượng dữ liệu rất nhỏ và tập lệnh cổng logic trên chuỗi, Cây Merkle hoàn chỉnh phải được lưu trữ ngoài chuỗi trong một thời gian dài để có thể truy cập trên chuỗi bất kỳ lúc nào. thời gian nếu có ai đó thách thức nó. Mỗi giao dịch trong Lớp 2 tạo ra một Cây Merkle lớn và người ta có thể tưởng tượng áp lực tính toán và lưu trữ lên các nút. Hầu hết mọi người có thể không muốn chạy các nút (tuy nhiên, dữ liệu lịch sử như vậy có thể bị loại bỏ và mạng B^2 đặc biệt giới thiệu các bằng chứng lưu trữ zk tương tự như Filecoin để khuyến khích các nút lưu trữ bảo tồn dữ liệu lịch sử lâu dài).

Tuy nhiên, Rollups lạc quan dựa trên bằng chứng gian lận không cần quá nhiều nút vì mô hình tin cậy của chúng là 1/N, nghĩa là miễn là một trong N nút trung thực và có thể bắt đầu bằng chứng gian lận tại thời điểm quan trọng, mạng Lớp 2 sẽ an toàn.

Tuy nhiên, có rất nhiều thách thức trong việc thiết kế các giải pháp Lớp 2 dựa trên BitVM, chẳng hạn như:

1) Về mặt lý thuyết, để nén dữ liệu hơn nữa, không cần thiết phải xác minh opcode trực tiếp trên Lớp 1. Luồng xử lý của opcode có thể được nén thêm thành bằng chứng zk, cho phép những người thách thức thử thách các bước xác minh của bằng chứng zk. Điều này có thể làm giảm đáng kể lượng dữ liệu trên chuỗi. Tuy nhiên, các chi tiết phát triển cụ thể có thể rất phức tạp.

2) Người đề xuất và Người thách thức cần tạo ra các tương tác ngoài chuỗi nhiều lần. Giao thức nên được thiết kế như thế nào và quy trình cam kết và thử thách cần được tối ưu hóa hơn nữa như thế nào trong quy trình xử lý sẽ đòi hỏi rất nhiều nỗ lực trí tuệ.

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được in lại từ [Geek Web3], Chuyển tiếp Tiêu đề gốc “Giải thích tối giản về BitVM: Cách xác minh bằng chứng gian lận trên chuỗi BTC (thực thi mã hoạt động của EVM hoặc VM khác)”, bản quyền thuộc về tác giả gốc [Trăng Faust & Sương mù]
   . Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn , họ sẽ xử lý kịp thời.
2. Tuyên bố miễn trừ trách nhiệm pháp lý: Các quan điểm và ý kiến trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Việc dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch đều bị cấm.