BitcoinLayer 2 mở rộng Phân tích kỹ thuật：bằng chứng hợp lệ và bằng chứng gian lận

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 như sau:

1. Alice nhập x, chạy thuật toán f, nhận kết quả y. Bob cũng sử dụng cùng đầu vào x để chạy thuật toán f và nhận y′. Nếu y và y′ bằng nhau, Bob sẽ chấp nhận đầu vào x và đầu ra y mà Alice cung cấp. Đây là một cơ chế chứng minh hợp lệ phổ biến, thường được áp dụng trong chuỗi khối nhận thức chung, trong đó Alice là nút đóng gói khối và Bob là nút tham gia nhận thức chung.
2. Alice nhập x, chạy chương trình zk.prove, nhận được 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, Bob chấp nhận kết quả y của Alice; nếu kết quả là sai, Bob không chấp nhận kết quả y của Alice. Đây là một bằng chứng hợp lệ, Bob có thể là hợp đồng on-chain.
3. Alice nhập x, chạy thuật toán f, nhận được kết quả y. Bob cũng sử dụng cùng đầu vào x để chạy thuật toán f, nhận được y’. Nếu y và y’ bằng nhau, không làm gì; nếu y và y’ khác nhau, Bob sẽ thách thức Alice, chương trình thách thức là f. Số lần tương tác giữa Alice và Bob có thể là một vòng hoặc nhiều vòng. Trọng tài được thực hiện thông qua cơ chế thách thức-phản hồi. Đây là một bằng chứng gian lận, Bob là người thách thức, nghe lén ngoại tuyến và thách thức trực tuyến.
4. Alice nhập x, chạy chương trình zk.prove, 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, không làm gì cả; nếu kết quả là sai, Bob sẽ thách thức Alice, chương trình thách thức là zk.verify. Số lần tương tác giữa Alice và Bob có thể là một lượt hoặc nhiều lượt. Thực hiện trọng tài thông qua cơ chế thách thức-phản ứng. Đây là một loại bằng chứng gian lận, Bob là người thách thức, theo dõi ngoại tuyến và phát động thách thức trực tuyến.

Đối với 2, 3 và 4, giả sử x là giao dịch Layer2 và trạng thái ban đầu, f là chương trình Nhận thức chung Layer2, y là trạng thái cuối cùng của giao dịch, tương ứng với giải pháp mở rộng Layer2 của blockchain.

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

Bảng 1: Phương pháp xây dựng niềm tin

Ngoài ra, cần chú ý đặc biệt là:

• Sự khác biệt giữa bằng chứng gian lận và bằng chứng hợp lệ không phải nằm ở việc sử dụng hệ thống chứng minh ZK như SNARK hoặc STARK. Hệ thống chứng minh ZK chỉ là cách diễn đạt phương pháp chứng minh được sử dụng, trong khi gian lận hoặc tính hợp lệ đại diện cho nội dung của chứng minh. Do đó, tình huống 1 trong bảng 1 được gọi là bằng chứng hợp lệ.
• Điều này có nghĩa là bằng chứng hợp lệ có thời gian hiệu lực tốt hơn, nhưng phức tạp hơn trong việc xác minh on-chain; trong khi đó, việc xác minh on-chain của bằng chứng gian lận đơn giản hơn, nhưng thời gian hiệu lực kém hơn.
• Đối với trường hợp 2 và 4 trong bảng 1, thông qua việc sử dụng công nghệ lặp và kết hợp ZK, có thể tính toán và nén nhiều f, do đó giảm đáng kể chi phí xác minh tính toán on-chain so với off-chain.

Hiện tại, nhờ vào các hợp đồng thông minh Turing hoàn thành của Solidity, các công nghệ bằng chứng gian lận và bằng chứng hợp lệ đang được áp dụng rộng rãi trong việc mở rộng Layer2 trên Ethereum. Tuy nhiên, trong bối cảnh của BTC, do các hạn chế về chức năng mã hoạt động của BTC bị hạn chế, số lượng phần tử trong ngăn xếp chỉ là 1000 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 về các hạn chế và công nghệ đột phá dưới cấu trúc BTC, nghiên cứu về các công nghệ bằng chứng hợp lệ và bằng chứng gian lận, và tổng quan về công nghệ đoạn mã script độc đáo dưới cấu trúc BTC.

Giới hạn và đột phá trong kiểu BTC 2

Trong khung của Bitcoin tồn tại nhiều hạn chế, nhưng có thể vượt qua những hạn chế này thông qua các phương pháp hoặc công nghệ tinh tế khác nhau. Ví dụ, sử dụng Bit cam kết có thể vượt qua hạn chế vô trạng thái của UTXO, Taproot có thể giải quyết hạn chế không gian kịch bản, đầu ra kết nối có thể vượt qua hạn chế của cách tiêu thụ UTXO, trong khi hợp đồng thông minh có thể vượt qua hạn chế của chữ ký trước.

2.1 Mô hình UTXO và giới hạn của tập lệnh

BTC sử dụng mô hình UTXO, trong đó mỗi UTXO đều bị khóa trong một kịch bản khóa, kịch bản này xác định các điều kiện cần đáp ứng để tiêu thụ UTXO đó. Kịch bản BTC có các hạn chế sau:

1. Bitcoin Script không có trạng thái;
2. Đối với loại đầu ra P2TR, một giao dịch có thể chứa tối đa khoảng 4 triệu mã hoạt động, lấp đầy toàn bộ Khối, trong khi đối với các loại đầu ra khác, chỉ có thể sử dụng 10.000 mã hoạt động;
3. Cách tiêu thụ UTXO đơn lẻ bị hạn chế, thiếu sự khám phá về cách tiêu thụ kết hợp;
4. Các chức năng hợp đồng linh hoạt không được hỗ trợ;
5. Kích thước của ngăn xếp được giới hạn tối đa là 1000 phần tử (bao gồm altstack và stack), kích thước tối đa của một phần tử là 520 byte;
6. Các phép toán số học (như cộng và trừ) được hạn chế thành các phần tử 4 byte, không thể mở rộng thành các phần tử dài 20 byte hoặc lớn hơn, điều này là cần thiết trong quá trình mã hóa;
7. Các mã hoạt động như OPMUL và OPCAT đã bị vô hiệu hóa, việc mô phỏng chúng bằng các mã hoạt động hiện có rất tốn kém, ví dụ mô phỏng một lần Hàm băm BLAKE3, kích thước script khoảng 75K.

2.2 Bit承诺：突破UTXO无状态限制

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

Bit承诺的原理相对简单。每个Bit都对应两个不同的哈希值，hash0 和 hash1。如果待签名的Bit值为 0，则揭示 hash0 的前像；如果Bit值为 1，则揭示 hash1 的前像。

Với một tin nhắn Bit đơn lẻ m ∈ {0,1} làm ví dụ, tập lệnh mở khóa Bit tương ứng chỉ bao gồm một số tiền ảo trước: nếu giá trị Bit là 0, thì tập lệnh mở khóa là preimage0 - “0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140”; nếu giá trị Bit là 1, thì tập lệnh mở khóa là preimage1 - “0x47c31e611a3bd2f3a7a42207613046703fa27496”. Do đó, thông qua Bit cam kết, ta có thể vượt qua hạn chế không có trạng thái của UTXO, thực hiện tập lệnh BTC có trạng thái, từ đó tạo ra khả năng cho các tính năng mới thú vị.

OP_HASH160

OP_DUP

0xf592e757267b7f307324f1e78b34472f8b6f46f3> // Đây là hash1

OP_EQUAL

OP_DUP

OP_ROT

0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // Đây là hash0

OP_EQUAL

OP_BOOLOR

OP_VERIFY

// Giá trị Bit được cam kết hiện đang trên ngăn xếp. Có thể là “0” hoặc “1”.

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

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

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

2.3 Taproot：突破脚本空间限制

Cải cách mềm Taproot của BTC được kích hoạt vào tháng 11 năm 2021 và bao gồm ba đề xuất: Chữ ký Schnorr (BIP 340), Taproot (BIP 341) và TapScript (BIP 342). Cải cách này giới thiệu một loại giao dịch mới - giao dịch Pay-to-Taproot (P2TR). Bằng cách kết hợp lợi ích của Taproot, MAST (Cây cú pháp trừu tượng Merkel) và chữ ký Schnorr, giao dịch P2TR có thể tạo ra định dạng giao dịch bảo mật hơn, linh hoạt hơn và có khả năng mở rộng hơn.

P2TR hỗ trợ hai cách chi tiêu: thông qua Chìa khoá bảo mật hoặc đường dẫn script. Theo quy định của Taproot (BIP 341), khi chi tiêu thông qua đường dẫn script, độ dài của đường dẫn Merkle tương ứng không thể vượt quá 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ừ nâng cấp SegWit vào năm 2017, mạng BTC đo lường kích thước Khối bằng đơn vị trọng số, hỗ trợ tối đa 400 triệu đơn vị trọng số (khoảng 4MB). Khi đầu ra P2TR được chi tiêu thông qua đường dẫn script, chỉ cần tiết lộ một script tapleaf duy nhất, điều này có nghĩa là Khối chỉ chứa một script tapleaf. Do đó, đối với giao dịch P2TR, kích thước tối đa của mỗi script tương ứng với mỗi tapleaf có thể đạt tới khoảng 4MB. Tuy nhiên, theo chính sách mặc định của BTC, nhiều Nút chỉ chuyển tiếp giao dịch nhỏ hơn 400K; giao dịch lớn hơn cần hợp tác với Người khai thác để đóng gói.

TAPROOT mang lại một giá trị script space premium, làm cho việc mô phỏng các hoạt động mật mã như phép nhân và Hàm băm bằng các mã hoạt động hiện tại trở nên có giá trị hơn. Khi xây dựng tính toán có thể xác minh dựa trên P2TR, kích thước script không còn bị giới hạn bởi 4MB, mà có thể được chia thành nhiều chức năng con, phân phối trên nhiều tapleaf khác nhau, qua đó vượt qua hạn chế không gian script 4MB. Thực tế, kích thước của Thuật toán xác minh Groth16 được thực hiện trong BitVM2 hiện nay lên đến 2GB. Tuy nhiên, nó có thể được chia thành khoảng 1000 tapleaf và phân phối thông qua kết hợp với Bit承诺, ràng buộc tính nhất quán giữa đầu vào và đầu ra của mỗi chức năng con, đả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 của kết nối: Vượt qua hạn chế cách chi tiêu UTXO

Hiện tại, BTC cung cấp hai phương thức thanh toán nguyên gốc cho mỗi đầu ra giao dịch chưa được sử dụng (UTXO): thanh toán thông qua script hoặc thanh toán thông qua Khóa công khai. Do đó, chỉ cần đáp ứng chính xác chữ ký của Khóa công khai hoặc điều kiện script, UTXO có thể được thanh toán. Hai UTXO có thể được thanh toán độc lập và không thể giới hạn bằng cách áp dụng các ràng buộc cho hai UTXO này, điều này có nghĩa là phải đáp ứng các điều kiện bổ sung để thanh toán chúng.

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

Hình 1: Sơ đồ đầu ra của bộ kết nối

Trong giao thức BitVM2, đầu ra của bộ kết nối đóng vai trò như một hàm if…else. Một khi đầu ra của bộ kết nối đã được chi tiêu bởi một giao dịch nào đó, nó sẽ không thể được chi tiêu bởi các giao dịch khác nữa, đảm bảo tính độc quyền của nó. Trong triển khai thực tế, để cho phép chu kỳ thách thức-phản hồi, đã được giới thiệu một UTXO bổ sung với khóa thời gian. Ngoài ra, đầu ra của bộ kết nối cũng có thể được cài đặt với các chiến lược chi tiêu khác nhau theo nhu cầu, ví dụ 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 người điều hành chi tiêu hoặc cho phép bất kỳ ai chi tiêu sau khi hết thời gian chờ.

2.5 Hợp đồng: Phá vỡ giới hạn ký trước

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

Hiện tại, việc triển khai hợp đồng có thể chia thành hai loại:

• Trước khi ký: Xây dựng hợp đồng đặt hàng có chức năng giới hạn dựa trên khả năng kịch bản BTC hiện có. Điều này có nghĩa là các bên tham gia cần thiết kế và ký tất cả các giao dịch tiềm năng trong tương lai có thể, từ đó khóa chúng trên Khóa riêng và tỷ lệ phí cụ thể. Một số kế hoạch yêu cầu các bên tham gia tạo ra Khóa riêng ngắn hạn cho tất cả các giao dịch được ký trước. Ngay khi việc ký trước hoàn thành, các Khóa riêng ngắn hạn này sẽ bị xóa an toàn để ngăn chặn kẻ tấn công lấy và đánh cắp tiền. Tuy nhiên, mỗi khi thêm bên tham gia mới hoặc cập nhật thao tác, quá trình này phải được lặp lại, dẫn đến chi phí bảo trì cao. Ví dụ, Lighting Network sử dụng trước khi ký để thực hiện hợp đồng song phương và định tuyến cho nhiều hợp đồng song phương bằng kỹ thuật Hợp đồng khóa thời gian Hàm băm (HTLC), từ đó thực hiện chiến lược mở rộng tối thiểu tin cậy. Tuy nhiên, Lighting Network cần phải trước khi ký nhiều giao dịch và chỉ giới hạn trong hai bên, điều này làm cho việc sử dụng nó trở nên phức tạp; trong BitVM1, mỗi lần khởi tạo đều cần phải ký trước hàng trăm giao dịch, 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 đến vài chục. Trong BitVM1 và BitVM2, chỉ những người vận hành tham gia trước khi ký mới có thể được bồi thường. Nếu có n bên tham gia tham gia trước khi ký và mỗi bên tham gia cần phải ký trước m giao dịch, thì độ phức tạp trước khi ký của mỗi bên tham gia sẽ là n * m.
• Đưa vào mã hoạt động hợp đồng: Việc đưa vào mã hoạt động chức năng hợp đồng mới có thể thấy rõ sự phức tạp và chi phí bảo trì của việc giao tiếp giữa các bên tham gia hợp đồng, từ đó cung cấp một cách thức triển khai hợp đồng linh hoạt hơn cho Bitcoin. Ví dụ, mã hoạt động OPCAT được sử dụng để kết nối chuỗi byte. Mặc dù chức năng của nó đơn giản, nhưng lại rất mạnh mẽ, có thể thấy rõ sự phức tạp của BitVM; Mã hoạt động OPTXHASH cho phép kiểm soát chi tiết hơn về các hoạt động trong hợp đồng. Nếu sử dụng trong BitVM, có thể hỗ trợ phạm vi hoạt động lớn hơn, từ đó cải thiện đáng kể tính an toàn của BitVM và giảm thiểu sự tin cậy. Ngoài ra, phương pháp ký trước về bản chất có nghĩa là người điều hành trong BitVM chỉ có thể sử dụng quy trình hoàn trả, dẫn đến hiệu quả sử dụng vốn thấp; và thông qua mã hoạt động hợp đồng mới, có thể trực tiếp thanh toán từ hồ bơi tiền peg-in cho người dùng đầu ra, từ đó tăng cường hiệu quả vốn. Do đó, mô hình hợp đồng linh hoạt sẽ hiệu quả phá vỡ giới hạn ký trước truyền thống.

3 Bitcoin Layer2 mở rộng: bằng chứng hợp lệ và bằng chứng gian lận

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 Layer2 của BTC, sự khác biệt chính xem trong bảng 2.

Bảng 2: bằng chứng hợp lệ与bằng chứng gian lận

Dựa trên cam kết của Bit, Taproot, chữ ký trước và đầu ra kết nối, có thể xây dựng bằng chứng gian lận dựa trên BTC. Đồng thời, bằng cách giới thiệu các mã hoạt động hợp đồng (ví dụ OP_CAT), cũng có thể xây dựng bằng chứng hợp lệ dựa trên Taproot của BTC. Ngoài ra, bằng chứng gian lận có thể được phân thành bằng chứng gian lận có sự cho phép và bằng chứng gian lận không có sự cho phép dựa trên việc xem xét hệ thống lên xe của Bob. Trong bằng chứng gian lận có sự cho phép, chỉ có nhóm cụ thể mới có thể thách thức Bob, trong khi trong bằng chứng gian lận không có sự cho phép, bất kỳ bên thứ ba nào cũng có thể thách thức Bob. Bảo mật của bằng chứng gian lận không có sự cho phép tốt hơn so với bằng chứng gian lận có sự cho phép, vì nó thả rủi ro của việc kết hợp giữa các bên tham gia.

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 đơn lẻ và bằng chứng gian lận đa vòng, như được hiển thị trong hình 2.

Hình 2: Bằng chứng gian lận đơn và bằng chứng gian lận đa vòng

Như đã thể hiện 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 lượt và mô hình tương tác nhiều lượt.

Bảng 3: Tương tác một lượt và tương tác nhiều lượt

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

Đối với hầu hết các tác vụ tính toán, signet, testnet và mainnet của BTC không thể hoàn toàn hỗ trợ tập lệnh 4MB, do đó cần sử dụng kỹ thuật phân tách mã lệnh, tức là phân tách toàn bộ mã lệnh tính toán thành các khối nhỏ hơn 4MB và phân phối chúng trên các Tapleaf khác nhau.

3.1 BTC Multiple Rounds bằng chứng gian lận

Như đã thấy ở Bảng 3, bằng chứng gian lận nhiều vòng phù hợp với những người muốn giảm thiểu tính toán xét xử on-chain hoặc không thể xác định vấn đề tính toán một cách đơn bước. Bằng chứng gian lận nhiều vòng, như tên gọi, yêu cầu sự tương tác nhiều vòng giữa người chứng minh và người xác thực để tìm ra đoạn tính toán có vấn đề, sau đó thực hiện xét xử dựa trên những đoạn đó.

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

Hiện tại, Bitcoin (BTC) đang sử dụng cả bằng chứng gian lận nhiều vòng trong phương pháp thử thách có giấy phép, trong khi bằng chứng gian lận một vòng đã thực hiện phương pháp thử thách không cần giấy phép, từ đó Thả rủi ro việc kết hợp giữa các bên tham gia và tăng cường tính an toàn. Vì vậy, Robin Linus đã tận dụng lợi thế của Taproot để tối ưu hóa BitVM1, không chỉ giảm số vòng tương tác xuống còn một vòng, mà còn mở rộng phương pháp thử thách thành không cần giấy phép, mặc dù điều này làm tăng chi phí tính toán tranh chấp on-chain.

3.2 Bitcoin một vòng bằng chứng gian lận

Trong mô hình này, chứng minh gian lận chỉ cần một lần tương tác giữa người chứng minh và người xác thực. Người xác thực chỉ cần đưa ra một thách thức một lần và người chứng minh chỉ cần phản hồi một lần. Trong phản hồi đó, người chứng minh phải cung cấp bằng chứng để chứng minh tính chính xác của tính toán của họ. Nếu người xác thực phát hiện ra sự không nhất quán trong bằng chứng, thì thách thức được coi là thành công; nếu không, thì thách thức thất bại. Đặc điểm của chứng minh gian lận trong một vòng tương tác đơn như bảng 3.

Hình 3: Bằng chứng gian lận đơn lẻ

Ngày 15 tháng 8 năm 2024, Robin Linus đã phát hành White Paper kỹ thuật “BitVM2: Kết nối BTC với Lớp hai”, trong đó thực hiện một phương pháp cầu nối Cross-chain tương tự như phương pháp gian lận đơn vòng được mô tả trong hình 3.

3.3 Sử dụng BTC OP_CAT bằng chứng hợp lệ

OP_CAT là một phần của ngôn ngữ kịch bản được phát hành cùng với BTC, 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 BTC đã thảo luận về khả năng kích hoạt lại OP_CAT trong nhiều năm qua. Hiện tại, OP_CAT đã được gán mã 347 và đã được kích hoạt trên mạng lưới signet của BTC.

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ả trở lại ngăn xếp. Chức năng này mở ra những khả năng mới cho hợp đồng trên BTC và máy xác minh STARK:

• Hợp đồng: Andrew Poelstra đề xuất CAT và Schnorr Tricks I, sử dụng OP_CAT và Schnorr thuật toán để triển khai hợp đồng trên BTC. Thuật toán Schnorr là một loại chữ ký số phù hợp cho loại đầu ra P2TR; cho các loại đầu ra khác, có thể sử dụng công nghệ ECDSA tương tự, như được thể hiện trong hợp đồng sử dụng CAT và ECDSA. Với hợp đồng OP_CAT, thuật toán xác minh STARK Validator có thể được phân tách thành nhiều giao dịch, từng bước xác minh toàn bộ chứng minh STARK.
• STARK verifier: Chức năng chính của STARK verifier là kết nối các dữ liệu lại với nhau và thực hiện Hàm băm. Khác với phép toán đại số, Hàm băm là một phép toán nguyên thủy trong BTC script, có thể giảm thiểu đáng kể chi phí. Ví dụ, OPSHA256 trong dạng nguyên thủy là một mã hoạt động độc lập, trong khi phiên bản mô phỏng cần hàng trăm mã hoạt động. Các phép toán Hàm băm chính trong STARK bao gồm xác minh đường dẫn Merkle và chuyển đổi Fiat-Shamir. Do đó, OP_CAT rất thân thiện với thuật toán của STARK verifier.

3.4 Kỹ thuật phân tách kịch bản BTC

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

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

Phần này sẽ tập trung giới thiệu về kỹ thuật tách rời BTC script trong điều kiện hiện tại mà không đưa ra hoặc kích hoạt bất kỳ mã hoạt động mới nào.

Trong quá trình phân tách script, cần cân nhắc thông tin từ một số phương diện sau:

• Kích thước script của một khối không được vượt quá 4MB và phải bao gồm script cam kết đầu vào, chữ ký giao dịch và nội dung 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 đó, ngăn xếp của mỗi khối chỉ nên giữ lại các phần tử cần thiết để đảm bảo có đủ không gian ngăn xếp để tối ưu kích thước kịch bản, vì Rửa tiền của Bitcoin không liên quan đến kích thước ngăn xếp.
• Trên Bitcoin, chi phí của các bit cam kết cao. Vì vậy, cố gắng giảm thiểu số lượng bit nhập và bit xuất giữa hai khối liền kề càng nhiều càng tốt, hiện tại 1 bit tương ứng với 26 byte.
• Để thuận tiện cho việc kiểm toán, chức năng của mỗi khối nên được làm rõ càng nhiều càng tốt.

Hiện tại, phương pháp tách kịch bản có thể chia thành ba loại sau đây:

• Tách tự động: Phương pháp này tìm cách tách một cách sao cho kích thước script khoảng 3MB, và tối thiểu hóa kích thước stack dựa trên kích thước stack và script. Ưu điểm của nó là độc lập với thuật toán xác thực cụ thể, có thể mở rộng thành bất kỳ tách script tính toán nào. Nhược điểm bao gồm: (1) Các khối logic toàn bộ phải được đánh dấu riêng biệt, ví dụ như không thể tách các khối mã OP_IF; nếu không, kết quả thực thi của script tách có thể bị sai lệch; (2) Kết quả thực thi của khối có thể tương ứng với nhiều phần tử trên stack, cần đánh dấu số lượng phần tử stack cần áp dụng cam kết bit theo logic tính toán thực tế; (3) Chức năng logic của mỗi script khối có tính khó đọc, khó kiểm tra; (4) Stack có thể chứa các phần tử không cần thiết cho khối tiếp theo, lãng phí không gian stack.
• Phân tách chức năng: Phương pháp này phân tách theo các hàm con chức năng trong quá trình tính toán, xác định đầu vào và đầu ra của từng hàm con. Trong quá trình phân tách script, cần triển khai các script cam kết bit cần thiết cho mỗi khối để đảm bảo kích thước tổng script của khối cuối cùng nhỏ hơn 4MB và kích thước stack nhỏ hơn 1000. Ưu điểm là chức năng rõ ràng, logic sạch sẽ, dễ đọc, dễ kiểm tra. Nhược điểm là logic tính toán gốc có thể không phù hợp với logic script, hàm con gốc có thể là tốt nhất nhưng không nhất thiết là tốt nhất ở mức script.
• Phân chia thủ công: Điểm phân chia trong phương pháp này không dựa trên các hàm con chức năng, mà được thiết lập thủ công. Phương pháp này đặc biệt phù hợp khi kích thước của mỗi hàm con lớn hơn 4MB. Ưu điểm là cho phép phân chia thủ công các hàm con của script lớn, ví dụ như các hàm con liên quan đến tính toán Fq12; mỗi khối logic rõ ràng, dễ đọc, thuận lợi cho việc kiểm định. Nhược điểm là bị hạn chế bởi khả năng tinh chỉnh thủ công, sau khi tối ưu hóa toàn bộ script, điểm phân chia thủ công được thiết lập trước đó có thể không còn là tối ưu nhất 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 nhà xác thực Groth16 đã được giảm từ khoảng 7GB Thả xuống còn khoảng 1.26GB. Ngoài việc tối ưu tính toán tổng thể, mỗi khối cũng có thể được tối ưu riêng để tận dụng tối đa không gian ngăn xếp. Ví dụ, bằng cách áp dụng thuật toán bảng tra cứu hiệu quả hơn và tải và gỡ bỏ bảng tra cứu theo cách động, kích thước kịch bản của mỗi khối có thể được giảm thêm.

Vì chi phí tính toán và môi trường chạy của ngôn ngữ lập trình Web2 khác hoàn toàn so với kịch bản BTC, do đó, việc chuyển đổi đơn giản các thuật toán hiện có sang kịch bản BTC không khả thi. Do đó, cần xem xét tối ưu hóa cụ thể cho tình huống BTC:

• Tìm kiếm các thuật toán có thể tối ưu hóa cục bộ bộ nhớ, ngay cả khi điều này có thể thêm một số gánh nặng tính toán, để giảm số lượng bit đầu vào / đầu ra giữa các khối, do đó 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 hoán đổi của các hoạt động liên quan (ví dụ như phép toán logic), chẳng hạn như x&y = y&x, để tiết kiệm gần một nửa không gian bảng tra cứu.
• Hiện tại, kích thước của script được thực hiện bởi Fq12 là khá lớn; có thể xem xét sử dụng Fiat-Shamir, Schwartz-Zipple và các phương án cam kết đa thức, nhằm làm gia tăng đáng kể tính phức tạp của việc mở rộng hoạt động của Fq12.

4 Tổng kết

Bài viết này đầu tiên thảo luận về giới hạn của kịch bản BTC và thảo luận về một số giải pháp: sử dụng cam kết BTC để vượt qua giới hạn trạng thái không có của UTXO, sử dụng Taproot để vượt qua giới hạn không gian kịch bản, bằng cách kết nối đầu ra để vượt qua giới hạn phương pháp chi UTXO, và giải quyết giới hạn của chữ ký trước bằng hợp đồng. Tiếp theo, bài viết tổng quan toàn diện về đặc điểm của bằng chứng gian lận và bằng chứng hợp lệ, bao gồm đặc điểm của bằng chứng gian lận được cấp phép và không được cấp phép, sự khác biệt giữa một vòng và nhiều vòng của bằng chứng gian lận và các nội dung liên quan đến công nghệ phân tách kịch bản BTC.

Tuyên bố:

1. Bài viết này được sao chép từ [aicoin]，著作权归属原作者[mutourend & lynndell, Bitlayer Labs]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
2. Tuyên bố miễn trừ trách nhiệm: Quan điểm và ý kiến được thể hiện trong bài viết chỉ là quan điểm cá nhân của tác giả, không có bất kỳ lời khuyên đầu tư nào.
3. Phiên bản tiếng khác của bài viết được dịch bởi nhóm Gate Learn, không được sao chép, phát tán hoặc sao chép bài viết đã được dịch mà không được đề cập đến Gate.io.