1 Giới thiệu

Đối với một thuật toán f, hai bên không tin tưởng lẫn nhau, Alice và Bob, có thể xác định niềm tin theo cách sau:

1. Alice nhập x, chạy thuật toán f, và nhận kết quả y. Bob cũng chạy thuật toán f với cùng đầu vào x, kết quả là y′. Nếu y = y′, thì Bob công nhận đầu vào x và đầu ra y của Alice. Đây là một cơ chế bằng chứng hợp lệ đặc biệt thường được sử dụng trong sự đồng thuận blockchain, nơi Alice là nút đóng gói khối và Bob là nút tham gia vào sự đồng thuận.
2. Alice nhập x, chạy chương trình zk.prove trên thuật toán f, và nhận kết quả y và chứng minh proof. Bob chạy chương trình zk.verify dựa trên f, y, và proof. Nếu kết quả là đúng, thì Bob xác nhận kết quả y của Alice; nếu kết quả là sai, thì Bob không xác nhận kết quả y của Alice. Điều này là một bằng chứng hợp lệ, nơi mà Bob có thể là một hợp đồng trên chuỗi.
3. Alice nhập x, chạy thuật toán f và nhận kết quả y. Bob cũng chạy thuật toán f với cùng đầu vào x, kết quả là y'. Nếu y = y', thì không làm gì; nếu y ≠ y', thì Bob thách thức Alice, với chương trình bị thách thức là f. Số lượt tương tác giữa Alice và Bob có thể là một hoặc nhiều. Trọng tài được đạt được thông qua quá trình thách thức-đáp ứng. Đây là một bằng chứng gian lận, trong đó Bob là người thách thức, lắng nghe ngoài chuỗi và thách thức trên chuỗi.
4. Alice nhập vào x, chạy chương trình zk.prove trên thuật toán f và nhận được kết quả y và bằng chứng proof. Bob chạy chương trình zk.verify dựa trên f, y và proof. Nếu kết quả là đúng, thì không làm gì; nếu kết quả là sai, thì Bob thách thức Alice, với chương trình bị thách thức là zk.verify. Số lần tương tác giữa Alice và Bob có thể là một hoặc nhiều. Trọng tài được đạt được thông qua quá trình thách thức-đáp trả. Đây là một bằng chứng gian lận, trong đó Bob là người thách thức, lắng nghe ngoài chuỗi và thách thức trên chuỗi.

Đối với các trường hợp 2, 3 và 4 ở trên, cho x là các giao dịch Layer2 và trạng thái ban đầu, f là chương trình đồng thuận Layer2, và y là trạng thái cuối của giao dịch, tương ứng với giải pháp mở rộng Layer2 trên blockchain. Trong đó:

• Bằng chứng hợp lệ: Dựa trên một giả định bi quan, nó phải được chứng minh là hợp lệ trước khi được chấp nhận, và nó có hiệu lực ngay lập tức. Trong một bằng chứng hợp lệ, phải được cung cấp bằng chứng về các chuyển tiếp trạng thái L2 đúng, phản ánh một quan điểm bi quan về thế giới - chỉ khi một trạng thái được chứng minh là đúng thì nó mới được chấp nhận.
• Bằng chứng gian lận: Dựa trên giả định lạc quan, nó được chấp nhận mặc định trừ khi ai đó chứng minh nó không chính xác. Nó có một giai đoạn cửa sổ thách thức, chỉ có tác dụng sau giai đoạn cửa sổ thách thức. Trong một bằng chứng gian lận, phải cung cấp bằng chứng về các chuyển tiếp trạng thái L2 không chính xác, phản ánh một quan điểm lạc quan về thế giới - một chuyển tiếp trạng thái được cho là chính xác trừ khi chứng minh ngược lại.

Bảng 1: Cách thiết lập niềm tin

Ngoài ra, quan trọng phải lưu ý:

• Chìa khóa để phân biệt giữa bằng chứng gian lận và bằng chứng hợp lệ không phải là việc sử dụng hệ thống chứng minh ZK như SNARK/STARK hay không. Hệ thống chứng minh ZK diễn đạt phương pháp chứng minh được sử dụng, trong khi gian lận hoặc hợp lệ đại diện cho nội dung được chứng minh. Đây là lý do tại sao tình huống 1 trong Bảng 1 được cho là đại diện cho một bằng chứng hợp lệ.
• Bằng chứng hợp lệ có độ kịp thời tốt hơn, nhưng độ phức tạp của việc xác minh trên chuỗi khối là cao; bằng chứng gian lận có độ phức tạp của việc xác minh trên chuỗi khối thấp hơn, nhưng độ kịp thời của chúng tương đối kém.
• Đối với trường hợp 2 và 4 trong Bảng 1, bằng cách sử dụng kỹ thuật đệ quy ZK và kỹ thuật kết hợp, nhiều f có thể được tính toán và nén lại, giảm đáng kể chi phí xác minh của tính toán off-chain trên chain.

Hiện tại, nhờ vào hợp đồng thông minh Turing-complete của Solidity, công nghệ chứng minh gian lận và chứng minh tính hợp lệ được sử dụng rộng rãi trong việc mở rộng Layer2 của Ethereum. Tuy nhiên, dưới mô hình Bitcoin, bị hạn chế bởi chức năng opcode hạn chế của Bitcoin, 1000 phần tử ngăn xếp và các hạn chế khác, việc áp dụng các công nghệ này vẫn đang ở giai đoạn khám phá. Bài viết này tóm tắt các hạn chế và công nghệ đột phá dưới mô hình Bitcoin trong bối cảnh mở rộng Layer2 của Bitcoin, nghiên cứu công nghệ chứng minh tính hợp lệ và chứng minh gian lận, và đề cập đến công nghệ phân đoạn script độc đáo dưới mô hình Bitcoin.

2 Giới hạn và Đột phá dưới Paradigm Bitcoin

Dưới mô hình Bitcoin, có nhiều hạn chế nhưng có thể sử dụng các phương pháp hoặc kỹ thuật thông minh khác nhau để vượt qua những hạn chế này. Ví dụ, cam kết bit có thể vượt qua hạn chế không có trạng thái UTXO, taproot có thể vượt qua hạn chế không gian kịch bản, đầu ra connector có thể vượt qua hạn chế phương pháp tiêu thụ UTXO và hợp đồng có thể vượt qua hạn chế chữ ký trước.

2.1 Mô hình UTXO và các hạn chế của Kịch bản

Bitcoin áp dụng mô hình UTXO, trong đó mỗi UTXO được khóa trong một tập lệnh khóa xác định các điều kiện phải đáp ứng để tiêu thụ UTXO đó. Kịch bản Bitcoin có các hạn chế sau:

1. Kịch bản Bitcoin là vô trạng thái;
2. Đối với loại đầu ra P2TR, số lượng mã opcode tối đa có thể được chứa trong một giao dịch duy nhất là khoảng 4 triệu, lấp đầy toàn bộ khối, trong khi đối với các loại đầu ra khác, chỉ có 10.000 mã opcode;
3. Phương pháp chi tiêu của một UTXO đơn lẻ bị giới hạn, thiếu khả năng khai thác các phương pháp chi tiêu kết hợp;
4. Chức năng hợp đồng linh hoạt không được hỗ trợ;
5. Kích thước ngăn xếp bị giới hạn tối đa là 1000 phần tử (altstack + stack), và kích thước tối đa của một phần tử duy nhất là 520 byte;
6. Các phép toán số học (như cộng trừ) được giới hạn đối với các phần tử 4 byte. Chúng không thể được sửa đổi thành các phần tử dài, chẳng hạn như 20 byte hoặc lớn hơn, mà cần thiết cho các phép toán mật mã;
7. Các mã opcode như OPMUL và OPCAT đã bị vô hiệu hóa, và mô phỏng chúng bằng các mã opcode hiện tại gây ra chi phí cực kỳ cao, như mô phỏng một vòng BLAKE3 hash, với kích thước script khoảng 75K.

2.2 Bit Commitment: Vượt qua hạn chế không trạng thái UTXO

Hiện tại, các kịch bản Bitcoin hoàn toàn không có trạng thái. Khi thực thi một tập lệnh Bitcoin, môi trường thực thi của nó được đặt lại sau mỗi tập lệnh. Điều này dẫn đến việc các tập lệnh Bitcoin không có khả năng hỗ trợ các tập lệnh ràng buộc 1 và 2 có cùng giá trị x. Tuy nhiên, vấn đề này có thể được giải quyết thông qua một số phương pháp, với ý tưởng cốt lõi là ký một giá trị theo một cách nào đó. Nếu một chữ ký có thể được tạo cho một giá trị, có thể đạt được các tập lệnh Bitcoin trạng thái. Nghĩa là, bằng cách kiểm tra chữ ký của giá trị x trong tập lệnh 1 và 2, có thể thực thi rằng cùng một giá trị x được sử dụng trong cả hai tập lệnh. Nếu có một chữ ký xung đột, có nghĩa là hai giá trị khác nhau được ký cho cùng một biến x, một hình phạt có thể được áp dụng. Giải pháp này được gọi là cam kết bit.

Nguyên tắc cam kết bit khá đơn giản. Một bit đề cập đến việc thiết lập hai giá trị hash khác nhau, hash0 và hash1, cho mỗi bit trong thông điệp cần ký. Nếu giá trị bit cần ký là 0, preimage0 của hash0 được tiết lộ; nếu giá trị bit cần ký là 1, preimage1 của hash1 được tiết lộ.

Ví dụ, với một tin nhắn bit đơn m ∈{0,1}, kịch bản mở khóa cam kết bit tương ứng chỉ là một số bức ảnh trước: nếu giá trị bit là 0, kịch bản mở khóa tương ứng là bức ảnh trước 0 - “0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140”; nếu giá trị bit là 1, kịch bản mở khóa tương ứng là bức ảnh trước 1 - “0x47c31e611a3bd2f3a7a42207613046703fa27496”. Do đó, với cam kết bit, có thể vượt qua giới hạn không trạng thái của UTXO và đạt được các kịch bản Bitcoin có trạng thái, tạo ra các tính năng mới thú vị khả dĩ.

OP_HASH160

OP_DUP

0xf592e757267b7f307324f1e78b34472f8b6f46f3> // Đây là hash1

OP_EQUAL

OP_DUP

OP_ROT

0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // Đây là hash0

OP_EQUAL

OP_BOOLOR

OP_VERIFY

// Hiện giá trị cam kết bit đang nằm trên ngăn xếp. Hoặc là “0” hoặc là “1”.

Hiện tại, có 2 cách thực hiện cam kết bit:

• Chữ ký một lần Lamport: Nguyên tắc tương đối đơn giản và chỉ yêu cầu sử dụng các hàm băm, làm cho nó thân thiện với Bitcoin. Đối với mỗi bit trong tin nhắn, cần cam kết hai giá trị băm, dẫn đến dữ liệu chữ ký tương đối lớn. Nói cách khác, đối với một tin nhắn có độ dài v bit, độ dài khóa công khai là 2v bit và độ dài chữ ký là v bit.
• Chữ ký một lần Winternitz: So với chữ ký Lamport, nó làm giảm đáng kể độ dài của chữ ký và khóa công khai nhưng làm tăng độ phức tạp của việc ký và xác minh. Sơ đồ này cho phép thiết lập linh hoạt các độ dài chuỗi băm khác nhau d, do đó cân bằng độ dài và độ phức tạp. Ví dụ: đặt d = 15 dẫn đến cả độ dài khóa công khai và độ dài chữ ký ngắn hơn khoảng 4 lần, nhưng độ phức tạp xác minh sẽ tăng gấp 4 lần. Đây thực chất là sự đánh đổi giữa không gian ngăn xếp và kích thước tập lệnh của Bitcoin. Chữ ký Lamport có thể được xem là một trường hợp đặc biệt của chữ ký Winternitz khi d = 1.

Hiện tại, thư viện BitVM2 triển khai các chữ ký Winternitz dựa trên hàm băm Blake3. Độ dài của chữ ký tương ứng với một bit đơn là khoảng 26 byte. Do đó, có thể thấy rằng giới thiệu trạng thái thông qua cam kết bit là tốn kém. Do đó, trong việc triển khai BitVM2, thông điệp được băm trước để thu được giá trị băm 256-bit, sau đó thực hiện cam kết bit trên giá trị băm để tiết kiệm chi phí, thay vì cam kết từng bit của thông điệp ban đầu dài hơn.

2.3 Taproot: Vượt qua giới hạn không gian kịch bản

Bản nâng cấp Bitcoin Taproot soft fork, kích hoạt vào tháng 11 năm 2021, bao gồm ba đề xuất: chữ ký Schnorr (BIP 340), Taproot (BIP 341) và TapScript (BIP 342). Nó giới thiệu một loại giao dịch mới - giao dịch Pay-to-Taproot (P2TR). Giao dịch P2TR có thể tạo ra định dạng giao dịch riêng tư, linh hoạt và có khả năng mở rộng hơn bằng cách kết hợp những ưu điểm của Taproot, MAST (Merkel Abstract Syntax Tree) và chữ ký Schnorr.

P2TR hỗ trợ hai phương pháp chi tiêu: chi tiêu theo đường dẫn khóa hoặc đường dẫn script.

Theo quy định trong Taproot (BIP 341), khi chi tiêu qua đường dẫn tập lệnh, đường dẫn Merkle tương ứng không được vượt quá độ dài tối đa là 128. Điều này có nghĩa là số lượng tapleaf trong taptree không thể vượt quá 2 ^ 128. Kể từ khi nâng cấp SegWit vào năm 2017, mạng Bitcoin đo kích thước khối theo đơn vị trọng lượng, với mức hỗ trợ tối đa là 4 triệu đơn vị trọng lượng (khoảng 4MB). Khi đầu ra P2TR được chi tiêu qua đường dẫn tập lệnh, nó chỉ cần hiển thị một tập lệnh tapleaf duy nhất, có nghĩa là khối được đóng gói với một tập lệnh tapleaf duy nhất. Điều này ngụ ý rằng đối với các giao dịch P2TR, kích thước tập lệnh tương ứng với mỗi tapleaf có thể tối đa khoảng 4MB. Tuy nhiên, theo chính sách mặc định của Bitcoin, nhiều nút chỉ chuyển tiếp các giao dịch nhỏ hơn 400K; Các giao dịch lớn hơn cần phải cộng tác với các thợ đào để được đóng gói.

Khả năng tăng giá trị mang lại bởi Taproot làm cho việc mô phỏng các hoạt động mật mã như nhân và băm bằng các opcode hiện có trở nên quý giá hơn.

Khi xây dựng tính toán xác thực dựa trên P2TR, kích thước script tương ứng không còn bị giới hạn trong các ràng buộc 4MB, mà có thể được chia thành nhiều phần con được phân tán trên nhiều tapleafs, qua đó phá vỡ giới hạn không gian script 4MB. Trên thực tế, thuật toán xác minh Groth16 được thực hiện trong BitVM2 hiện tại có kích thước lên đến 2GB. Tuy nhiên, nó có thể được chia thành khoảng 1000 tapleafs và kết hợp với cam kết bit, sự nhất quán giữa các đầu vào và đầu ra của mỗi phần con tính toán có thể được ràng buộc, đảm bảo tính toàn vẹn và đúng đắn của toàn bộ tính toán.

2.4 Đầu ra Connector: Vượt qua giới hạn phương thức chi tiêu UTXO

Hiện tại, Bitcoin cung cấp hai phương pháp chi tiêu gốc cho một UTXO: chi tiêu bằng tập lệnh hoặc bằng khóa công khai. Do đó, miễn là chữ ký khóa công khai hoặc điều kiện tập lệnh chính xác được đáp ứng, UTXO có thể được sử dụng. Hai UTXO có thể được chi tiêu độc lập và không có hạn chế nào có thể được thêm vào để hạn chế hai UTXO, có nghĩa là phải đáp ứng các điều kiện bổ sung để chúng được chi tiêu.

Tuy nhiên, Burak, người sáng lập giao thức Ark, đã thông minh sử dụng cờ SIGHASH để đạt được đầu ra của bộ nối. Cụ thể, Alice có thể tạo ra một chữ ký để gửi BTC của mình cho Bob. Tuy nhiên, vì chữ ký có thể cam kết đến nhiều đầu vào, Alice có thể đặt chữ ký của mình là điều kiện: chữ ký chỉ hợp lệ cho giao dịch Taketx nếu và chỉ nếu giao dịch đó tiêu thụ đầu vào thứ hai. Đầu vào thứ hai được gọi là bộ nối, liên kết UTXO A và UTXO B. Nói cách khác, giao dịch Taketx chỉ hợp lệ nếu và chỉ nếu UTXO B chưa được tiêu thụ bởi Challengetx. Do đó, bằng cách phá hủy đầu ra của bộ nối, hiệu quả của giao dịch Taketx có thể bị chặn.

Hình 1: Minh họa Đầu ra Kết nối

Trong giao thức BitVM2, đầu ra của trình kết nối hoạt động như một nếu... chức năng khác. Khi đầu ra của trình kết nối được chi tiêu bởi một giao dịch, nó không thể được chi tiêu bởi một giao dịch khác để đảm bảo chi tiêu độc quyền của nó. Trong triển khai thực tế, để cho phép một giai đoạn phản ứng thách thức, các UTXO bổ sung với khóa thời gian được giới thiệu. Hơn nữa, đầu ra trình kết nối tương ứng cũng có thể được thiết lập với các chiến lược chi tiêu khác nhau khi cần thiết, chẳng hạn như cho phép bất kỳ bên nào chi tiêu trong trường hợp giao dịch thách thức, trong khi chỉ cho phép nhà điều hành chi tiêu hoặc cho phép bất kỳ ai chi tiêu sau thời gian chờ cho các giao dịch phản hồi.

2.5 Hợp đồng: Vượt qua giới hạn trước khi ký

Hiện tại, kịch bản Bitcoin chủ yếu giới hạn các điều kiện để mở khóa, mà không hạn chế cách UTXO có thể được tiêu thụ tiếp theo. Điều này bởi vì các kịch bản Bitcoin không thể đọc nội dung của giao dịch chính nó, có nghĩa là chúng không thể thực hiện kiểm tra giao dịch. Nếu các kịch bản Bitcoin có thể kiểm tra bất kỳ nội dung của giao dịch nào (bao gồm các đầu ra), chức năng hợp đồng có thể được thực hiện.

Các triển khai hợp đồng hiện tại có thể được chia thành hai loại:

• Ký trước: Dựa trên khả năng kịch bản Bitcoin hiện có, các hợp đồng được xác định trước chức năng hạn chế được xây dựng thông qua ký trước. Điều này có nghĩa là thiết kế và ký trước tất cả các giao dịch có thể có trong tương lai, khóa người tham gia vào các khóa riêng và mức phí cụ thể. Một số chương trình thậm chí còn yêu cầu người tham gia tạo khóa riêng ngắn hạn cho tất cả các giao dịch được ký trước. Sau khi ký trước hoàn tất, các khóa riêng ngắn hạn này sẽ bị xóa an toàn, ngăn kẻ tấn công lấy chúng và đánh cắp tiền. Tuy nhiên, mỗi khi một người tham gia mới được thêm vào hoặc một hoạt động được cập nhật, quá trình trên cần phải được lặp lại, dẫn đến chi phí bảo trì cao. Ví dụ: Lightning Network đạt được hợp đồng hai bên thông qua ký trước và sử dụng công nghệ Hợp đồng khóa thời gian băm (HTLC) để thực hiện các chức năng định tuyến cho nhiều hợp đồng hai bên, do đó đạt được chiến lược mở rộng quy mô giảm thiểu sự tin cậy. Tuy nhiên, Lightning Network yêu cầu ký trước nhiều giao dịch và bị giới hạn ở hai bên, khiến nó hơi cồng kềnh; trong BitVM1, hàng trăm giao dịch cần được ký trước ở mỗi lần khởi tạo, trong khi trong BitVM2 được tối ưu hóa, số lượng giao dịch cần được ký trước ở mỗi lần khởi tạo cũng lên tới hàng chục. Trong cả BitVM1 và BitVM2, chỉ những nhà khai thác tham gia ký trước mới đủ điều kiện để được hoàn trả. Nếu n người tham gia tham gia ký trước và mỗi người tham gia cần ký trước m giao dịch, độ phức tạp trước khi ký cho mỗi người tham gia sẽ là n * m.
• Giới thiệu Opcodes hợp đồng: Giới thiệu opcodes chức năng hợp đồng mới có thể làm giảm đáng kể sự phức tạp trong giao tiếp và chi phí bảo trì giữa những người tham gia hợp đồng, do đó giới thiệu một phương pháp thực hiện hợp đồng linh hoạt hơn cho Bitcoin. Ví dụ: OPCAT: được sử dụng để nối các chuỗi byte. Mặc dù chức năng của nó rất đơn giản, nhưng nó rất mạnh mẽ và có thể làm giảm đáng kể độ phức tạp của BitVM; OPTXHASH: cho phép kiểm soát chi tiết hơn các hành động trong hợp đồng. Nếu được sử dụng trong BitVM, nó có thể hỗ trợ một nhóm các nhà khai thác lớn hơn, do đó cải thiện đáng kể các giả định bảo mật của BitVM và giảm thiểu sự tin tưởng. Ngoài ra, phương thức ký trước vốn có nghĩa là các nhà khai thác trong BitVM chỉ có thể áp dụng quy trình hoàn trả, dẫn đến hiệu quả sử dụng vốn thấp hơn; Trong khi thông qua các opcode hợp đồng mới, có thể thanh toán trực tiếp từ nhóm quỹ chốt cho người dùng đầu ra, cải thiện hơn nữa hiệu quả vốn. Do đó, một mô hình hợp đồng linh hoạt sẽ phá vỡ hiệu quả các giới hạn trước khi ký kết truyền thống.

3 Bitcoin Layer2 Scaling: Bằng chứng hợp lệ và Bằng chứng gian lận

Cả bằng chứng hợp lệ và bằng chứng gian lận đều có thể được sử dụng cho việc mở rộng Bitcoin L2, với những khác biệt chính được hiển thị trong Bảng 2.

Bảng 2: Bằng chứng Hợp lệ so với Bằng chứng Gian lận

Dựa trên cam kết bit, taproot, ký trước và đầu ra kết nối, bằng chứng gian lận dựa trên Bitcoin có thể được xây dựng. Dựa trên taproot, bằng chứng hợp lệ dựa trên Bitcoin cũng có thể được xây dựng bằng cách giới thiệu các opcode hợp đồng, chẳng hạn như OP_CAT. Ngoài ra, tùy thuộc vào việc Bob có hệ thống nhập học hay không, bằng chứng gian lận có thể được chia thành bằng chứng gian lận được phép và bằng chứng gian lận không được phép. Trong bằng chứng gian lận được phép, chỉ các nhóm cụ thể mới có thể đóng vai trò là Bob để bắt đầu thử thách, trong khi trong bằng chứng gian lận không được phép, bất kỳ bên thứ ba nào cũng có thể đóng vai trò là Bob để bắt đầu thử thách. Tính bảo mật của bằng chứng gian lận không được phép vượt trội so với những bằng chứng được phép, giảm nguy cơ thông đồng giữa những người tham gia được phép.

Dựa vào số lần tương tác thách thức-phản hồi giữa Alice và Bob, bằng chứng gian lận có thể được chia thành bằng chứng gian lận một vòng và bằng chứng gian lận nhiều vòng, như được thể hiện trong Hình 2.

Hình 2: Bằng chứng gian lận một vòng so với bằng chứng gian lận nhiều vòng

Như được hiển thị trong Bảng 3, bằng chứng gian lận có thể được thực hiện thông qua các mô hình tương tác khác nhau, bao gồm mô hình tương tác một vòng và mô hình tương tác nhiều vòng.

Bảng 3: Tương tác một vòng vs. Tương tác nhiều vòng

Trong mô hình mở rộng Layer2 của Bitcoin, BitVM1 áp dụng cơ chế bằng chứng gian lận đa vòng, trong khi BitVM2 sử dụng cơ chế bằng chứng gian lận một vòng, và bitcoin-circle stark sử dụng bằng chứng hợp lệ. Trong số này, BitVM1 và BitVM2 có thể được thực hiện mà không cần thay đổi bất kỳ điều gì trong giao thức Bitcoin, trong khi bitcoin-circle stark yêu cầu giới thiệu một mã opcode mới là OP_CAT.

Đối với hầu hết các nhiệm vụ tính toán, signet, testnet và mainnet của Bitcoin không thể đại diện hoàn toàn cho một tập lệnh 4MB, buộc phải sử dụng công nghệ chia tách tập lệnh - tức là chia tách tập lệnh tính toán hoàn chỉnh thành các phần nhỏ hơn 4MB, phân phối trên các tapleafs khác nhau.

3.1 Bằng Chứng Gian Lận Đa Vòng Trên Bitcoin

Như thể hiện trong Bảng 3, bằng chứng gian lận nhiều vòng phù hợp với các tình huống có mong muốn giảm tính toán trọng tài trên chuỗi và / hoặc khi không thể xác định các phân đoạn tính toán có vấn đề trong một bước. Bằng chứng gian lận nhiều vòng, như tên cho thấy, yêu cầu nhiều vòng tương tác giữa người chứng minh và người xác minh để xác định các phân đoạn tính toán có vấn đề, tiếp theo là trọng tài dựa trên các phân đoạn được xác định.

Trong báo cáo BitVM đầu tiên của Robin Linus (thông thường được gọi là BitVM1), đã sử dụng bằng chứng gian lận đa vòng. Giả sử mỗi giai đoạn thử thách kéo dài một tuần và sử dụng phương pháp tìm kiếm nhị phân để định vị các đoạn tính toán gây sự cố, thời gian phản hồi thử thách trên chuỗi cho Bộ xác minh Groth16 có thể kéo dài lên đến 30 tuần, dẫn đến độ chính xác thấp. Mặc dù hiện có các nhóm nghiên cứu phương pháp tìm kiếm n-ary hiệu quả hơn so với tìm kiếm nhị phân, tuy nhiên độ chính xác của chúng vẫn thấp hơn đáng kể so với chu kỳ 2 tuần trong bằng chứng gian lận một vòng.

Hiện tại, các bằng chứng gian lận đa vòng trong mô hình Bitcoin sử dụng thử thách có sự cho phép, trong khi bằng chứng gian lận một vòng đã đạt được phương pháp thử thách không cần sự cho phép, giảm thiểu nguy cơ kết đồng trong số các thành viên và do đó tăng cường an ninh. Với mục tiêu này, Robin Linus đã tận dụng hoàn toàn những ưu điểm của Taproot để tối ưu hóa BitVM1. Không chỉ là số vòng tương tác đã giảm xuống còn một, mà phương pháp thử thách cũng được mở rộng thành một phương pháp không cần sự cho phép, mặc dù có tác động tăng cường tính toán trọng tài trên chuỗi.

3.2 Bằng chứng gian lận một vòng trên Bitcoin

Trong mô hình này, việc xác minh bằng chứng gian lận có thể được hoàn thành thông qua một tương tác duy nhất giữa người chứng minh và người xác minh. Người xác minh chỉ cần bắt đầu một thử thách và người chứng minh chỉ cần trả lời một lần. Trong phản hồi này, người chứng minh phải cung cấp bằng chứng tuyên bố rằng tính toán của họ là chính xác. Nếu người xác minh có thể tìm thấy sự mâu thuẫn trong bằng chứng đó, thách thức đã thành công; nếu không, nó không thành công. Các đặc điểm của bằng chứng gian lận tương tác một vòng được thể hiện trong Bảng 3.

Hình 3: Bằng chứng gian lận một vòng

Vào ngày 15 tháng 8 năm 2024, Robin Linus đã phát hành bản tóm tắt kỹ thuật BitVM2: Bridging Bitcoin to Second Layers, triển khai một cầu nối cross-chain sử dụng phương pháp bằng chứng gian lận một vòng tương tự như được hiển thị trong Hình 3.

3.3 Bằng Chứng Hợp Lệ trên Bitcoin với OP_CAT

OPCAT là một phần của ngôn ngữ script gốc khi Bitcoin được phát hành nhưng đã bị vô hiệu hóa vào năm 2010 do lỗ hổng bảo mật. Tuy nhiên, cộng đồng Bitcoin đã thảo luận về việc kích hoạt lại nó trong nhiều năm qua. OPCAT hiện đã được gán số 347 và đã được kích hoạt trên Bitcoin’s signet.

Chức năng chính của OP_CAT là kết hợp hai phần tử trong ngăn xếp và đẩy kết quả hợp nhất trở lại ngăn xếp. Chức năng này mở ra khả năng cho các hợp đồng và STARK Verifiers trên Bitcoin:

• Hợp đồng: Andrew Poelstra đề xuất CAT và Schnorr Tricks I, sử dụng các kỹ thuật OPCAT và Schnorr để thực hiện hợp đồng trên Bitcoin. Thuật toán Schnorr là chữ ký số cho các loại đầu ra P2TR; đối với các loại đầu ra khác, có thể sử dụng các kỹ thuật tương tự ECDSA, như đã thấy trong Covenants với CAT và ECDSA. Với sự trợ giúp của các hợp đồng OPCAT, thuật toán STARK Verifier có thể được chia thành nhiều giao dịch, từ từ xác minh toàn bộ chứng minh STARK.
• STARK Verifier: STARK Verifier về cơ bản kết nối dữ liệu với nhau và băm nó. Không giống như các phép toán đại số, băm là một hoạt động tập lệnh Bitcoin gốc có thể tiết kiệm một lượng đáng kể chi phí. Ví dụ: OPSHA256 là một opcode duy nhất ở dạng gốc, trong khi phiên bản mô phỏng yêu cầu hàng trăm mã K opcode. Các hoạt động băm chính trong STARK liên quan đến việc xác minh các đường dẫn Merkle và các phép biến đổi Fiat-Shamir. Do đó, OPCAT rất thân thiện với thuật toán STARK Verifier.

3.4 Công nghệ chia tách Bitcoin Script

Mặc dù tải phần tính toán cần thiết để chạy thuật toán xác minh tương ứng để xác minh chứng minh sau bằng chứng SNARK/STARK nhỏ hơn nhiều so với phần tính toán gốc f, nhưng lượng script cần thiết khi chuyển đổi nó để thực hiện thuật toán xác minh trong kịch bản Bitcoin vẫn rất lớn. Hiện tại, dựa trên các opcode Bitcoin hiện có, kích thước script xác minh Groth16 tối ưu hóa và kích thước script xác minh Fflonk vẫn lớn hơn 2GB cả hai. Tuy nhiên, kích thước của một khối Bitcoin duy nhất chỉ là 4MB, khiến việc chạy toàn bộ script xác minh trong một khối duy nhất trở nên không thể. Tuy nhiên, kể từ khi nâng cấp Taproot, Bitcoin hỗ trợ thực thi script bằng tapleaf, cho phép script xác minh được chia thành nhiều phần, với mỗi phần phục vụ như một tapleaf để xây dựng một taptree. Sự nhất quán của các giá trị giữa các phần có thể được đảm bảo thông qua cam kết bit.

Trong sự hiện diện của các hợp đồng OP_CAT, Trình xác minh STARK có thể được chia thành nhiều giao dịch tiêu chuẩn nhỏ hơn 400KB, cho phép việc xác minh toàn bộ bằng chứng hợp lệ STARK được hoàn thành mà không cần phối hợp với các nhà đào tạo.

Phần này tập trung vào công nghệ chia nhỏ liên quan đến Bitcoin scripts trong điều kiện hiện tại mà không giới thiệu hoặc kích hoạt bất kỳ opcode mới nào.

Khi thực hiện phân tách script, các chiều thông tin sau phải cân bằng:

• Kích thước của một tập lệnh đoạn duy nhất không được vượt quá 4MB và phải bao gồm các tập lệnh cam kết bit đầu vào, chữ ký giao dịch và không gian khác.
• Kích thước ngăn xếp tối đa của một khối không được vượt quá 1000. Do đó, mỗi ngăn xếp của khối chỉ nên giữ lại các yếu tố cần thiết để dành đủ không gian ngăn xếp để tối ưu hóa kích thước tập lệnh, vì phí giao dịch Bitcoin không phụ thuộc vào kích thước ngăn xếp được sử dụng.
• Cam kết bit trên Bitcoin rất tốn kém. Do đó, số bit trong đầu vào và đầu ra giữa hai phần tử kế tiếp nên được tối thiểu hóa, vì hiện tại, 1 bit tương ứng với 26 byte.
• Để dễ kiểm toán, chức năng của mỗi phần nên rõ ràng nhất có thể.

Hiện tại, phương pháp chia script có thể được chia thành ba danh mục chính sau đây:

• Tự động tách: Phương pháp này tìm kiếm cách tiếp cận phân tách trong đó kích thước tập lệnh khoảng 3MB và kích thước ngăn xếp được giảm thiểu dựa trên kích thước ngăn xếp và kích thước tập lệnh. Ưu điểm của phương pháp này là nó độc lập với các thuật toán xác minh cụ thể và có thể được mở rộng để tách tập lệnh cho bất kỳ tính toán nào. Những nhược điểm là: (1) toàn bộ khối logic phải được đánh dấu riêng, chẳng hạn như OP_IF khối mã không thể tách ra; nếu không, kết quả thực thi của tập lệnh phân tách sẽ không chính xác; (2) kết quả thực thi của một đoạn có thể tương ứng với nhiều phần tử trên ngăn xếp, yêu cầu đánh dấu số lượng phần tử ngăn xếp cần áp dụng cam kết bit dựa trên logic tính toán thực tế; (3) khả năng đọc của chức năng logic được thực hiện bởi mỗi tập lệnh đoạn kém, làm cho việc kiểm toán trở nên khó khăn; (4) ngăn xếp có thể chứa các yếu tố không cần thiết cho đoạn tiếp theo, lãng phí không gian ngăn xếp.
• Phân chia Chức năng: Phương pháp này phân chia dựa trên các chức năng phụ chức năng khác nhau trong tính toán, với giá trị đầu vào và đầu ra rõ ràng cho các chức năng phụ. Trong quá trình chia nhỏ kịch bản, nó cũng thực hiện các kịch bản cam kết bit cần thiết cho mỗi khối, đảm bảo rằng kích thước kịch bản tổng cộng của các khối cuối cùng nhỏ hơn 4MB và kích thước ngăn xếp nhỏ hơn 1000. Các lợi ích là: chức năng rõ ràng, logic rõ ràng cho mỗi khối, dễ đọc và dễ kiểm tra. Nhược điểm là: biểu thức của logic tính toán ban đầu có thể không phù hợp với logic cấp độ kịch bản, và các chức năng phụ tính toán ban đầu có thể tối ưu nhưng không đại diện cho tính tối ưu cấp độ kịch bản.
• Phân chia thủ công: Phương pháp này không dựa trên các phân chia dựa trên các phân hàm con chức năng mà được đặt thủ công. Điều này đặc biệt phù hợp cho các trường hợp mà kích thước một chức năng con đơn vượt quá 4MB. Các lợi ích là: nó cho phép phân chia thủ công các chức năng con có kích thước đoạn kịch nặng, chẳng hạn như các phép tính liên quan đến Fq12; logic rõ ràng cho mỗi đoạn, dễ đọc và dễ kiểm tra. Các nhược điểm là: bị giới hạn bởi khả năng điều chỉnh thủ công, khi tổng thể đoạn kịch đã được tối ưu hóa, các điểm phân chia được đặt trước đó có thể không tối ưu và cần phải điều chỉnh lại.

Ví dụ, sau nhiều vòng tối ưu hóa, kích thước kịch bản của bộ xác minh Groth16 đã được giảm từ khoảng 7GB xuống còn khoảng 1.26GB. Ngoài việc tối ưu hóa tính toán tổng thể này, mỗi mảnh cũng có thể được tối ưu hóa riêng lẻ để tận dụng tối đa không gian stack. Ví dụ, bằng cách giới thiệu các thuật toán dựa trên bảng tra cứu tốt hơn và tải và dỡ bảng tra cứu một cách động, kích thước kịch bản của mỗi mảnh có thể được giảm thêm.

Chi phí tính toán và môi trường thời gian chạy của các ngôn ngữ lập trình web2 hoàn toàn khác biệt so với ngôn ngữ Bitcoin, vì vậy việc dịch đơn giản các thực hiện hiện có cho các thuật toán khác nhau thành Bitcoin scripts không khả thi. Do đó, cần xem xét các tối ưu hóa cụ thể cho tình huống Bitcoin:

• Tìm kiếm các thuật toán tối ưu hóa vùng nhớ, ngay cả khi phải trả giá bằng một số tải tính toán, để giảm số lượng bit đầu vào / đầu ra giữa các khối, từ đó giảm lượng dữ liệu cần thiết cho cam kết trong thiết kế giao dịch assertTx của BitVM2.
• Sử dụng tính chất giao hoán của các phép toán liên quan (ví dụ, phép toán logic), chẳng hạn như x&y = y&x, để tiết kiệm gần một nửa bảng tra cứu.
• Hiện tại, kích thước kịch bản tương ứng với các hoạt động Fq12 là lớn; xem xét việc sử dụng các hệ thống Fiat-Shamir, Schwartz-Zipple và cam kết đa thức để giảm đáng kể phức tạp tính toán của các hoạt động mở rộng Fq12.

4 Tóm tắt

Bài viết này trước tiên giới thiệu những hạn chế của các tập lệnh Bitcoin và thảo luận về việc sử dụng các cam kết Bitcoin để khắc phục giới hạn không trạng thái UTXO, sử dụng Taproot để vượt qua các giới hạn về không gian tập lệnh, sử dụng đầu ra của trình kết nối để vượt qua các hạn chế về phương thức chi tiêu UTXO và sử dụng hợp đồng để khắc phục các hạn chế trước khi ký. Sau đó, nó cung cấp một cái nhìn tổng quan và tóm tắt toàn diện về các đặc điểm của bằng chứng gian lận và bằng chứng hợp lệ, các tính năng của bằng chứng gian lận được phép và không được phép, sự khác biệt giữa bằng chứng gian lận một vòng và nhiều vòng và công nghệ tách tập lệnh Bitcoin.

Miễn trách nhiệm:

1. Bài viết này được sao chép từ [aicoin]. Tất cả bản quyền thuộc về tác giả gốc [ mutourend & lynndell, Bitlayer Labs]. Nếu có ý kiến ​​phản đối về việc tái in này, vui lòng liên hệ với Gate Learnđội ngũ và họ sẽ xử lý nhanh chóng.
2. Miễn trừ trách nhiệm về trách nhiệm: Quan điểm và ý kiến được thể hiện trong bài viết này chỉ là quan điểm và ý kiến của tác giả và không đại diện cho bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của 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ó thông báo, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là cấm.