Phân tích công nghệ mở rộng Bitcoin Layer2: Bằng chứng hiệu lực và Bằng chứng gian lận
Tuyển chọn TechFlowTuyển chọn TechFlow
Phân tích công nghệ mở rộng Bitcoin Layer2: Bằng chứng hiệu lực và Bằng chứng gian lận
Trong phạm vi 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 tinh vi khác nhau để phá vỡ những giới hạn này.
Chuyên sâu báo cáo Web3Tác giả: mutourend & lynndell, Bitlayer Labs
1 Giới thiệu
Đối với một thuật toán f nhất định, hai bên tham gia không tin tưởng lẫn nhau là Alice và Bob có thể thiết lập niềm tin theo các cách sau:
-
Alice nhập x, chạy thuật toán f, nhận được kết quả y. Bob cũng dựa trên cùng đầu vào x để chạy thuật toán f, thu được kết quả y'. Nếu y = y', thì Bob công nhận đầu vào x và đầu ra y do Alice cung cấp. Đây là một cơ chế bằng chứng hiệu lực đặc biệt, thường dùng trong đồng thuận blockchain. Trong đó, Alice là nút đóng gói khối, Bob là nút tham gia đồng thuận.
-
Alice nhập x, thực hiện chương trình zk.prove đối với thuật toán f, thu được kết quả y và bằng chứng proof. Bob dựa vào f, y và proof để chạy chương trình zk.verify. Nếu kết quả là true, Bob công nhận kết quả y của Alice; nếu là false thì không công nhận. Đây là bằng chứng hiệu lực (validity proof). Trong đó, Bob có thể là hợp đồng trên chuỗi.
-
Alice nhập x, chạy thuật toán f, thu được kết quả y. Bob cũng dựa trên cùng đầu vào x để chạy thuật toán f, thu được kết quả y'. Nếu y = y' thì không làm gì cả; nếu y ≠ y', Bob khiếu nại Alice, nội dung khiếu nại là chương trình f. Số lần tương tác giữa Alice và Bob có thể là một hoặc nhiều lần. Việc trọng tài được thực hiện dựa trên quy trình phản hồi khiếu nại. Đây là bằng chứng gian lận (fraud proof). Trong đó, Bob là người khiếu nại, giám sát ngoài chuỗi và khiếu nại trên chuỗi.
-
Alice nhập x, thực hiện chương trình zk.prove đối với thuật toán f, thu được kết quả y và bằng chứng proof. Bob dựa vào f, y và proof để chạy chương trình zk.verify. Nếu kết quả là true thì không làm gì cả; nếu là false, Bob khiếu nại Alice, nội dung khiếu nại là chương trình zk.verify. Số lần tương tác giữa Alice và Bob có thể là một hoặc nhiều lần. Trọng tài được thực hiện dựa trên quy trình phản hồi khiếu nại. Đây cũng là bằng chứng gian lận. Trong đó, Bob là người khiếu nại, giám sát ngoài chuỗi và khiếu nại trên chuỗi.
Đối với các trường hợp 2, 3, 4 ở trên, đặt x là giao dịch Layer2 và trạng thái khởi đầu, f là chương trình đồng thuận Layer2, y là trạng thái cuối giao dịch, thì sẽ tương ứng với các giải pháp mở rộng blockchain Layer2. Cụ thể:
-
Bằng chứng hiệu lực (Validity Proof): Dựa trên giả định bi quan, phải chứng minh hiệu lực trước khi chấp nhận, và có hiệu lực ngay lập tức. Trong bằng chứng hiệu lực, cần cung cấp bằng chứng về việc chuyển đổi trạng thái L2 đúng đắn, phản ánh quan điểm bi quan về thế giới – chỉ khi nào chứng minh một trạng thái là đúng mới chấp nhận trạng thái đó.
-
Bằng chứng gian lận (Fraud Proof): Dựa trên giả định lạc quan, mặc định chấp nhận, chỉ từ chối khi có người chứng minh sai sót. Có thời gian chờ khiếu nại (challenge window), chỉ có hiệu lực sau khi hết thời gian này. Trong bằng chứng gian lận, cần cung cấp bằng chứng rằng chuyển đổi trạng thái L2 là không đúng, phản ánh quan điểm lạc quan về thế giới – mặc định chuyển đổi trạng thái là đúng, trừ khi có chứng minh ngược lại.
Bảng 1: Các phương thức thiết lập niềm tin
Ngoài ra, cần lưu ý:
-
Mấu chốt phân biệt bằng chứng gian lận và bằng chứng hiệu lực không nằm ở việc có sử dụng hệ thống bằng chứng ZK như SNARK/STARK hay không. Hệ thống bằng chứng ZK thể hiện phương pháp chứng minh được dùng, còn việc là bằng chứng gian lận hay hiệu lực thì biểu thị nội dung được chứng minh. Đây cũng là lý do tại sao nói rằng tình huống 1 trong Bảng 1 đại diện cho bằng chứng hiệu lực.
-
Bằng chứng hiệu lực có tính thời gian tốt hơn, nhưng độ phức tạp xác minh trên chuỗi tương đối cao; bằng chứng gian lận có độ phức tạp xác minh thấp hơn trên chuỗi, nhưng tính thời gian tương đối kém.
-
Đối với trường hợp 2 và 4 trong Bảng 1, nhờ kỹ thuật đệ quy và tổ hợp ZK, có thể nén phép tính của nhiều f, giảm đáng kể chi phí xác minh trên chuỗi cho phép tính ngoài chuỗi.
Hiện nay, nhờ hợp đồng thông minh Turing-complete của Solidity, các công nghệ bằng chứng hiệu lực và bằng chứng gian lận đang được áp dụng rộng rãi trong mở rộng Layer2 Ethereum. Tuy nhiên, trong khuôn khổ Bitcoin, do bị giới hạn bởi số lượng opcode hạn chế, giới hạn 1000 phần tử stack,... các công nghệ này vẫn đang trong giai đoạn thăm dò. Bài viết này tổng hợp các hạn chế và công nghệ đột phá trong khuôn khổ Bitcoin, nghiên cứu công nghệ bằng chứng hiệu lực và bằng chứng gian lận, đồng thời hệ thống hóa kỹ thuật phân chia script độc đáo riêng có trong khuôn khổ Bitcoin, nhằm phục vụ cho mở rộng Layer2 Bitcoin.
2 Hạn chế và đột phá trong khuôn khổ Bitcoin
Khuôn khổ Bitcoin có rất nhiều hạn chế, nhưng có thể dùng nhiều phương pháp hoặc công nghệ tinh vi để vượt qua những hạn chế này. Ví dụ, cam kết bit (bit commitment) có thể vượt qua giới hạn UTXO vô trạng thái, taproot có thể vượt qua giới hạn không gian script, connector output có thể vượt qua giới hạn cách thức tiêu dùng UTXO, và covenant có thể vượt qua giới hạn ký trước (pre-sign).
2.1 Mô hình UTXO và giới hạn script
Bitcoin sử dụng mô hình UTXO, mỗi UTXO đều bị khóa bởi một script khóa (locking script), script này định nghĩa điều kiện cần thỏa mãn để tiêu dùng UTXO đó. Script Bitcoin có các hạn chế sau:
-
Script Bitcoin là vô trạng thái;
-
Đối với loại đầu ra P2TR, tổng số opcode trong một giao dịch tối đa khoảng 4 triệu, đủ để lấp đầy toàn bộ khối; với các loại đầu ra khác chỉ có khoảng 10.000 opcode;
-
Cách tiêu dùng một UTXO đơn lẻ là hạn chế, thiếu sự khám phá về cách kết hợp tiêu dùng;
-
Không hỗ trợ chức năng covenant linh hoạt;
-
Giới hạn kích thước stack tối đa 1000 phần tử (altstack + stack), mỗi phần tử lớn nhất 520 byte;
-
Các phép toán số học (như cộng, trừ) chỉ giới hạn ở phần tử 4 byte. Không thể sửa thành phần tử dài hơn như 20 byte hoặc lớn hơn, nhưng đây là điều cần thiết cho các phép toán mật mã;
-
Các opcode như OP_MUL và OP_CAT đã bị cấm, nếu mô phỏng bằng opcode hiện có thì chi phí cực kỳ cao, ví dụ mô phỏng một vòng băm BLAKE3, kích thước script khoảng 75K.
2.2 Cam kết bit: Vượt qua giới hạn vô trạng thái của UTXO
Hiện tại script Bitcoin hoàn toàn vô trạng thái. Khi thực thi script Bitcoin, môi trường thực thi sẽ được thiết lập lại sau mỗi script. Điều này khiến script Bitcoin không thể hỗ trợ bản chất ràng buộc giá trị x giống nhau trong script 1 và script 2. Tuy nhiên, có thể dùng một số phương pháp để vượt qua vấn đề này, tư tưởng cốt lõi là ký tên lên một giá trị theo một cách nào đó. Nếu có thể tạo chữ ký cho một giá trị, thì có thể thực hiện script Bitcoin có trạng thái. Nghĩa là cần kiểm tra chữ ký giá trị x trong cả script 1 và script 2, để buộc giá trị x sử dụng trong script 1 và script 2 phải giống nhau. Nếu xuất hiện chữ ký mâu thuẫn, tức ký 2 giá trị khác nhau cho cùng biến x, thì có thể trừng phạt. Giải pháp này chính là cam kết bit (bit commitment).
Nguyên lý cam kết bit tương đối đơn giản. "Bit" ở đây nghĩa là với từng bit trong thông điệp cần ký, thiết lập 2 giá trị hash khác nhau, tức hash0 và hash1. Nếu bit cần ký có giá trị là 0, tiết lộ tiền ảnh (preimage) preimage0 của hash0; nếu bit cần ký có giá trị là 1, tiết lộ tiền ảnh preimage1 của hash1.
Lấy thông điệp đơn bit m ∈ {0,1} làm ví dụ, script mở khóa tương ứng của cam kết bit chỉ là một số tiền ảnh: nếu giá trị bit là 0, script mở khóa tương ứng là preimage0 – «0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140»; nếu giá trị bit là 1, script mở khóa tương ứng là preimage1 – «0x47c31e611a3bd2f3a7a42207613046703fa27496». Như vậy, nhờ cam kết bit, có thể vượt qua giới hạn vô trạng thái của UTXO, thực hiện script Bitcoin có trạng thái, từ đó làm cho nhiều tính năng mới thú vị trở nên khả thi.
OP_HASH160
OP_DUP
<0xf592e757267b7f307324f1e78b34472f8b6f46f3> // Đây là hash1
OP_EQUAL
OP_DUP
OP_ROT
<0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // Đây là hash0
OP_EQUAL
OP_BOOLOR
OP_VERIFY
// Bây giờ giá trị cam kết bit nằm trên stack. Có thể là “0” hoặc “1”.
Hiện tại có 2 cách triển khai cam kết bit:
-
Chữ ký một lần Lamport: Nguyên lý tương đối đơn giản, chỉ cần dùng hàm băm, do đó thân thiện với Bitcoin. Với mỗi bit trong thông điệp, đều cần cam kết 2 giá trị băm, dẫn đến dữ liệu chữ ký tương đối lớn. Nói cách khác, với thông điệp v bit, độ dài khóa công khai là 2v bit, độ dài chữ ký là v bit.
-
Chữ ký một lần Winternitz: So với chữ ký Lamport, có thể giảm đáng kể độ dài chữ ký và khóa công khai, nhưng tăng độ phức tạp ký và xác minh. Sơ đồ này có thể linh hoạt thiết lập độ dài chuỗi băm d khác nhau để cân bằng giữa độ dài và độ phức tạp. Ví dụ, đặt d=15, độ dài khóa công khai và chữ ký ngắn hơn khoảng 4 lần, nhưng độ phức tạp xác minh tăng gấp 4 lần. Về bản chất là đánh đổi giữa không gian stack và kích thước script trên Bitcoin. Chữ ký Lamport có thể coi là trường hợp đặc biệt của chữ ký Winternitz khi d=1.
Hiện nay, trong thư viện BitVM2, đã triển khai chữ ký Winternitz dựa trên hàm băm Blake3. Độ dài chữ ký tương ứng mỗi bit khoảng 26 byte. Từ đó thấy rằng, việc đưa trạng thái vào thông qua cam kết bit là tốn kém. Do đó, trong triển khai kỹ thuật BitVM2, trước tiên thực hiện băm thông điệp để có giá trị băm 256 bit, sau đó mới thực hiện cam kết bit trên giá trị băm, nhằm tiết kiệm chi phí, thay vì cam kết trực tiếp từng bit của thông điệp gốc dài.
2.3 Taproot: Vượt qua giới hạn không gian script
Đợt nâng cấp soft fork Taproot của Bitcoin từ tháng 11 năm 2021 bao gồm 3 đề xuất: chữ ký Schnorr (BIP 340), Taproot (BIP 341) và TapScript (BIP 342). Đưa ra một loại giao dịch mới – giao dịch Pay-to-Taproot (P2TR). Giao dịch P2TR kết hợp ưu điểm của Taproot, MAST (Merkle Abstract Syntax Tree) và chữ ký Schnorr, có thể tạo định dạng giao dịch riêng tư hơn, linh hoạt và mở rộng tốt hơn.
P2TR hỗ trợ hai cách tiêu dùng: tiêu dùng theo key path hoặc script path.
Theo quy định trong Taproot (BIP 341), khi tiêu dùng theo script path, độ dài Merkle path tương ứng tối đa không vượt quá 128. Điều này nghĩa là số lượng tapleaf trong taptree không vượt quá 2^128. Kể từ đợt nâng cấp segwit năm 2017, mạng Bitcoin đo lường kích thước khối bằng đơn vị weight, tối đa hỗ trợ 4 triệu weight units (khoảng 4MB). Khi một đầu ra P2TR bị tiêu dùng theo script path, thực tế chỉ cần tiết lộ một script tapleaf duy nhất, nghĩa là khối chỉ đóng gói script của một tapleaf duy nhất. Điều này nghĩa là, với giao dịch P2TR, kích thước script của mỗi tapleaf tương ứng tối đa khoảng 4MB. Tuy nhiên, theo chiến lược mặc định của Bitcoin, nhiều nút chỉ chuyển tiếp giao dịch nhỏ hơn 400K, giao dịch lớn hơn muốn được đóng gói thì cần hợp tác với thợ đào.
Sự dư thừa không gian script mà Taproot mang lại khiến việc mô phỏng các phép toán mật mã như phép nhân, băm bằng opcode hiện có 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 tương ứng không còn bị giới hạn ở 4MB, mà có thể chia phép tính thành nhiều hàm con, phân bố trên nhiều tapleaf, từ đó vượt qua giới hạn không gian script 4MB. Thực tế, thuật toán Groth16 verifier được triển khai trong BitVM2 hiện nay có kích thước lên tới 2GB. Tuy nhiên, có thể chia nhỏ và phân bố trên khoảng 1000 tapleaf, kết hợp với cam kết bit, thông qua ràng buộc tính nhất quán giữa đầu vào và đầu ra của các hàm con, để ràng buộc tính toàn vẹn và tính đúng đắn của toàn bộ phép tính.
2.4 Connector output: Vượt qua giới hạn cách tiêu dùng UTXO
Hiện tại, Bitcoin cung cấp hai cách tiêu dùng UTXO đơn lẻ: tiêu dùng theo script hoặc theo khóa công khai. Do đó, chỉ cần cung cấp chữ ký khóa công khai đúng hoặc thỏa mãn điều kiện script là có thể tiêu dùng UTXO đó. Hai UTXO có thể được tiêu dùng độc lập, không thể thêm biện pháp giới hạn để ràng buộc hai UTXO, buộc chúng phải thỏa mãn một số điều kiện bổ sung mới được tiêu dùng.
Tuy nhiên, Burak, người sáng lập giao thức Ark, đã khéo léo tận dụng cờ SIGHASH để thực hiện connector output. Cụ thể, Alice có thể tạo một chữ ký, gửi BTC của mình cho Bob. Nhưng vì chữ ký có thể commit nhiều Inputs, Alice có thể đặt chữ ký của mình là có điều kiện: chữ ký này chỉ hợp lệ đối với giao dịch Take_tx khi và chỉ khi giao dịch đó tiêu thụ input thứ hai. Input thứ hai này được gọi là connector, nối UTXO A và UTXO B. Nói cách khác, giao dịch Take_tx chỉ hợp lệ khi và chỉ khi UTXO B chưa bị tiêu dùng bởi giao dịch Challenge_tx. Do đó, bằng cách tiêu hủy connector output, có thể ngăn chặn giao dịch Take_tx có hiệu lực.
Hình 1: Minh họa connector output
Trong giao thức BitVM2, connector output đảm nhiệm chức năng if...else. Một khi connector output bị tiêu dùng bởi một giao dịch, nó không thể bị tiêu dùng bởi giao dịch khác, nhằm đảm bảo tính độc quyền khi tiêu dùng. Trong triển khai thực tế, để dành chu kỳ phản hồi khiếu nại, thêm UTXO có timelock. Ngoài ra, connector output tương ứng cũng có thể thiết lập các chiến lược tiêu dùng khác nhau theo nhu cầu, ví dụ có thể đặt giao dịch khiếu nại cho phép bất kỳ ai tiêu dùng, trong khi giao dịch phản hồi chỉ cho phép operator tiêu dùng hoặc cho phép bất kỳ ai tiêu dùng sau khi quá hạn.
2.5 Covenant: Vượt qua giới hạn ký trước
Hiện tại, script Bitcoin chủ yếu giới hạn điều kiện mở khóa, mà không giới hạn cách UTXO đó được tiêu dùng tiếp theo. Lý do là script Bitcoin không thể đọc nội dung giao dịch, tức không thể thực hiện tự kiểm tra giao dịch (transaction introspection). Nếu script Bitcoin có thể kiểm tra bất kỳ nội dung nào của giao dịch (bao gồm cả output), thì có thể thực hiện chức năng covenant.
Các cách hiện thực covenant hiện nay có thể chia thành hai loại:
-
Ký trước (Pre-sign): Dựa trên khả năng hiện có của script Bitcoin, xây dựng covenant có chức năng hạn chế và được xác định trước thông qua ký trước. Tức là thiết kế và ký tất cả các giao dịch tương lai có thể xảy ra trước, khóa các bên tham gia vào khóa riêng cụ thể và tỷ lệ phí nhất định. Một số giải pháp thậm chí yêu cầu các bên tham gia tạo khóa riêng ngắn hạn dùng cho tất cả các giao dịch đã ký trước. Sau khi ký trước hoàn tất, an toàn xóa các khóa riêng ngắn hạn này, khiến kẻ tấn công không thể lấy được, từ đó đá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, đều cần lặp lại quá trình trên, dẫn đến chi phí bảo trì nặng nề. Ví dụ, Lightning Network thực hiện covenant hai bên thông qua ký trước, và nhờ kỹ thuật Hash Time Lock Contract (HTLC), đạt được chức năng định tuyến nhiều covenant hai bên, từ đó thực hiện chiến lược mở rộng tối thiểu hóa niềm tin. Tuy nhiên, Lightning Network cần ký trước nhiều giao dịch và chỉ giới hạn hai bên, hơi cồng kềnh; trong BitVM1, mỗi lần khởi tạo cần ký trước hàng trăm giao dịch, trong BitVM2 đã tối ưu hóa vẫn cần ký trước vài chục giao dịch. Dù là BitVM1 hay BitVM2, chỉ có operator tham gia ký trước mới đủ tư cách được hoàn tiền. Nếu có n bên tham gia ký trước, mỗi bên cần ký trước m giao dịch, thì độ phức tạp ký trước của mỗi bên sẽ là n × m.
-
Giới thiệu opcode covenant: Giới thiệu opcode chức năng covenant mới, có thể giảm đáng kể độ phức tạp truyền thông và chi phí bảo trì giữa các bên tham gia covenant, từ đó mang lại cách hiện thực covenant linh hoạt hơn cho Bitcoin. Ví dụ, OP_CAT: dùng để nối các chuỗi byte. Mặc dù chức năng rất đơn giản, nhưng sức mạnh rất lớn, có thể giảm đáng kể độ phức tạp BitVM; OP_TXHASH: có thể kiểm soát hành động trong covenant với độ chi tiết tốt hơn. Nếu dùng trong BitVM, có thể hỗ trợ tập hợp operator lớn hơn, cải thiện đáng kể giả định an toàn của BitVM, làm cho nó tối thiểu hóa niềm tin. Ngoài ra, cách ký trước định sẵn khiến trong thiết kế BitVM, operator chỉ có thể dùng quy trình ứng trước hoàn trả, hiệu suất sử dụng vốn thấp; trong khi với opcode covenant mới, có thể thực hiện thanh toán trực tiếp cho người rút tiền từ pool peg-in, nâng cao hiệu suất vốn. Do đó, mô hình covenant linh hoạt sẽ hiệu quả vượt qua giới hạn ký trước truyền thống.
3 Mở rộng Layer2 Bitcoin: Bằng chứng hiệu lực và bằng chứng gian lận
Cả bằng chứng hiệu lực và bằng chứng gian lận đều có thể dùng cho mở rộng L2 Bitcoin, sự khác biệt chính giữa hai bên được thể hiện trong Bảng 2.
Bảng 2: Bằng chứng hiệu lực và bằng chứng gian lận
Dựa trên cam kết bit, taproot, ký trước và connector output, có thể xây dựng bằng chứng gian lận dựa trên Bitcoin. Dựa trên taproot, đồng thời giới thiệu opcode covenant như OP_CAT, có thể xây dựng bằng chứng hiệu lực dựa trên Bitcoin. Ngoài ra, tùy theo Bob có hay không chế độ准入, bằng chứng gian lận có thể chia thành bằng chứng gian lận theo giấy phép (permissioned) và bằng chứng gian lận không theo giấy phép (permissionless). Trong bằng chứng gian lận theo giấy phép, chỉ nhóm cụ thể mới có thể làm Bob để khiếu nại, trong khi bằng chứng gian lận không theo giấy phép, bất kỳ bên thứ ba nào cũng có thể làm Bob để khiếu nại. Bảo mật của loại không theo giấy phép tốt hơn loại theo giấy phép, có thể giảm rủi ro thông đồng làm hại giữa các bên được cấp phép.
Tùy theo số lần tương tác giữa Alice và Bob trong quy trình khiếu nại và phản hồi, bằng chứng gian lận có thể chia thành bằng chứng gian lận một vòng và nhiều vòng, như Hình 2.
Hình 2: Bằng chứng gian lận một vòng và nhiều vòng
Như Bảng 3, bằng chứng gian lận có thể thực hiện 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 và tương tác nhiều vòng
Trong khuôn khổ mở rộng Layer2 Bitcoin, BitVM1 sử dụng cơ chế bằng chứng gian lận nhiều vòng, BitVM2 sử dụng cơ chế bằng chứng gian lận một vòng, bitcoincircle stark sử dụng bằng chứng hiệu lực. Trong đó, BitVM1 và BitVM2 có thể triển khai mà không cần sửa đổi giao thức Bitcoin, trong khi bitcoin-circle stark cần giới thiệu opcode mới OP_CAT.
Đối với hầu hết các nhiệm vụ tính toán, signet, testnet và mainnet Bitcoin đều không thể biểu diễn đầy đủ bằng script 4MB, cần dùng kỹ thuật Split script – tức chia script biểu diễn phép tính đầy đủ thành các chunk nhỏ hơn 4MB, phân bố vào các tapleaf khác nhau.
3.1 Bằng chứng gian lận nhiều vòng trên Bitcoin
Như Bảng 3, bằng chứng gian lận nhiều vòng phù hợp với các trường hợp muốn giảm lượng tính toán trọng tài trên chuỗi, và (hoặc) không thể xác định ngay phần tính toán lỗi. Bằng chứng gian lận nhiều vòng, như tên gọi, cần nhiều lần tương tác giữa người chứng minh và người xác minh để xác định phần tính toán lỗi, sau đó mới trọng tài dựa trên phần tính toán đã xác định.
Whitepaper BitVM ban đầu của Robin Linus (thường gọi là BitVM1) sử dụng bằng chứng gian lận nhiều vòng. Giả sử mỗi vòng khiếu nại kéo dài một tuần, dùng phương pháp tìm kiếm nhị phân để xác định phần tính toán lỗi, thì chu kỳ khiếu nại và phản hồi trên chuỗi cho Groth16 Verifier sẽ lên tới 30 tuần, tính thời gian rất kém. Mặc dù hiện nay có nhóm nghiên cứu phương pháp tìm kiếm n-ary hiệu quả hơn tìm kiếm nhị phân, nhưng so với chu kỳ 2 tuần của bằng chứng gian lận một vòng, tính thời gian vẫn thấp hơn nhiều.
Hiện nay, bằng chứng gian lận nhiều vòng trong khuôn khổ Bitcoin đều dùng kiểu khiếu nại theo giấy phép, trong khi bằng chứng gian lận một vòng đã thực hiện kiểu khiếu nại không theo giấy phép, giảm rủi ro thông đồng giữa các bên, do đó an toàn hơn. Vì vậy, Robin Linus đã tận dụng đầy đủ lợi thế của taproot để tối ưu BitVM1. Không chỉ giảm số vòng tương tác xuống 1, mà còn mở rộng kiểu khiếu nại thành không theo giấy phép, nhưng đổi lại là tăng lượ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
Chỉ cần một lần tương tác giữa người chứng minh và người xác minh để hoàn tất xác minh bằng chứng gian lận. Trong mô hình này, người xác minh chỉ cần khiếu nại một lần, người chứng minh chỉ cần phản hồi một lần. Trong phản hồi này, người chứng minh cần cung cấp một bằng chứng, tuyên bố phép tính của họ là đúng. Nếu người xác minh có thể tìm thấy sự không nhất quán trong bằng chứng này, thì khiếu nại thành công, nếu không thì thất bại. Đặc điểm của mô hình bằng chứng gian lận một vòng như trong Bảng 3.
Hình 3: Bằng chứng gian lận một vòng
Robin Linus ngày 15 tháng 8 năm 2024 đã phát hành whitepaper kỹ thuật BitVM2: Bridging Bitcoin to Second Layers, sử dụng cách thức tương tự Hình 3, theo kiểu bằng chứng gian lận một vòng, thực hiện cầu nối chéo chuỗi BitVM2.
3.3 Bitcoin + OP_CAT thực hiện bằng chứng hiệu lực
OP_CAT là một phần của ngôn ngữ script khi Bitcoin ra mắt ban đầu, bị cấm năm 2010 do lỗ hổng bảo mật. Tuy nhiên, trong nhiều năm, cộng đồng Bitcoin đã thảo luận về việc kích hoạt lại nó. Hiện nay OP_CAT đã được cấp số 347 và đã được bật trên signet Bitcoin.
Chức năng chính của OP_CAT là kết hợp hai phần tử trong stack và đẩy kết quả nối lại vào stack. Tính năng này mở ra khả năng covenant và STARK Verifier trên Bitcoin:
-
Covenant: Andrew Poelstra đề xuất CAT and Schnorr Tricks I, dùng OP_CAT và thủ thuật Schnorr để thực hiện covenant trên Bitcoin. Trong đó, thuật toán Schnorr là chữ ký số cho loại đầu ra P2TR; với các loại đầu ra khác, có thể dùng thủ thuật ECDSA tương tự, xem Covenants with CAT and ECDSA. Nhờ covenant OP_CAT, có thể hỗ trợ chia thuật toán STARK Verifier thành nhiều giao dịch, xác minh từng bước toàn bộ STARK proof.
-
STARK Verifier: Về bản chất, STARK Verifier là nối dữ liệu và băm chúng. Khác với phép toán đại số, phép toán băm là thao tác native của script Bitcoin, có thể tiết kiệm rất nhiều chi phí. Lấy OP_SHA256 làm ví dụ, cách native chỉ cần một opcode, trong khi mô phỏng cần hàng trăm nghìn opcode. Các phép toán băm chính trong STARK là xác minh đường dẫn Merkle và biến đổi Fiat-Shamir. Do đó, OP_CAT rất thân thiện với thuật toán STARK Verifier.
3.4 Kỹ thuật Split script Bitcoin
Mặc dù sau khi được chứng minh bằng SNARK/STARK, lượng tính toán cần thiết để chạy thuật toán verifier tương ứng để xác minh proof nhỏ hơn nhiều so với việc chạy trực tiếp phép tính gốc f. Tuy nhiên, khi chuyển đổi sang hiện thực thuật toán verifier bằng script Bitcoin, lượng script cần thiết vẫn rất lớn. Hiện nay, dựa trên opcode Bitcoin hiện có, sau tối ưu, kích thước script Groth16 verifier và Fflonk verifier vẫn đều lớn hơn 2GB. Tuy nhiên, kích thước khối đơn lẻ Bitcoin chỉ 4MB, không thể chạy toàn bộ script verifier trong một khối. Tuy nhiên, sau nâng cấp taproot, Bitcoin hỗ trợ thực thi script theo tapleaf, có thể chia script verifier thành nhiều chunk, sau đó dùng mỗi chunk làm tapleaf, xây dựng taptree. Các chunk khác nhau dùng cam kết bit để đảm bảo tính nhất quán giá trị giữa các chunk.
Trong trường hợp có covenant OP_CAT, có thể chia STARK Verifier thành nhiều giao dịch chuẩn nhỏ hơn 400KB, từ đó có thể hoàn tất xác minh toàn bộ bằng chứng hiệu lực STARK mà không cần hợp tác với thợ đào.
Mục này tập trung vào tình huống hiện tại chưa giới thiệu hoặc kích hoạt opcode mới nào, liên quan đến kỹ thuật Split script Bitcoin.
Khi chia script, cần cân bằng các khía cạnh sau:
-
Kích thước script chunk đơn lẻ không vượt quá 4MB, cần chứa không gian script cam kết bit đầu vào, chữ ký giao dịch, v.v.
-
Kích thước stack chunk đơn lẻ tối đa không vượt quá 1000. Do đó nên để stack của từng chunk chỉ giữ các phần tử cần thiết, từ đó dành đủ không gian stack phục vụ tối ưu kích thước script. Vì phí giao dịch Bitcoin không phụ thuộc vào kích thước stack sử dụng.
-
Cam kết bit trên Bitcoin là tốn kém. Hiện nay 1 bit tương ứng 26 byte, nên giảm thiểu số bit đầu vào và đầu ra giữa hai chunk liền kề.
-
Để thuận tiện kiểm toán, chức năng của mỗi chunk nên rõ ràng nhất có thể.
Hiện nay, cách chia script chủ yếu chia thành 3 loại lớn:
-
Chia tự động: Dựa trên kích thước stack và kích thước script, tìm cách chia sao cho kích thước script khoảng 3MB và kích thước stack nhỏ nhất. Ưu điểm: Không phụ thuộc vào thuật toán verifier cụ thể, có thể mở rộng cho việc chia script mọi phép tính. Nhược điểm: (1) Cần đánh dấu riêng logic khối, như khối code OP_IF không thể chia, nếu không kết quả thực thi script sau khi chia sẽ không đúng; (2) Kết quả thực thi chunk có thể tương ứng nhiều phần tử trên stack, cần căn cứ logic tính toán thực tế để đánh dấu số phần tử stack cần áp dụng cam kết bit; (3) Tính dễ đọc chức năng logic script chunk thấp, không thuận tiện kiểm toán; (4) Stack có thể chứa các phần tử không cần dùng cho chunk tiếp theo, lãng phí không gian stack.
-
Chia theo chức năng: Chia theo các hàm con chức năng trong phép tính, giá trị đầu vào và đầu ra của hàm con rõ ràng, trong khi chia script cũng thực hiện script cam kết bit cần thiết cho từng chunk, miễn là tổng kích thước script chunk cuối cùng nhỏ hơn 4MB, kích thước stack nhỏ hơn 1000. Ưu điểm: Chức năng rõ ràng, logic chunk đơn lẻ rõ ràng, dễ đọc, thuận tiện kiểm toán. Nhược điểm: Biểu đạt logic tính toán gốc và biểu đạt logic cấp script không khớp, có thể tối ưu ở cấp tính toán con không có nghĩa là tối ưu ở cấp script.
-
Chia thủ công: Điểm chia script không nằm ở hàm con chức năng, mà do con người thiết lập điểm chia. Đặc biệt phù hợp với trường hợp kích thước hàm con đơn lẻ lớn hơn 4MB. Ưu điểm: Có thể chia thủ công các hàm con script nặng như các hàm tính toán liên quan Fq12; logic chunk đơn lẻ rõ ràng, dễ đọc, thuận tiện kiểm toán. Nhược điểm: Bị giới hạn bởi khả năng điều chỉnh thủ công, khi tổng script được tối ưu, các điểm chia thủ công đã thiết lập trước đó có thể không còn tối ưu, cần điều chỉnh lại.
Ví dụ, Groth16 verifier sau nhiều lần tối ưu, kích thước script giảm từ khoảng 7GB xuống khoảng 1,26GB. Ngoài việc tối ưu tính toán tổng thể, còn có thể tối ưu riêng từng chunk để tận dụng tối đa không gian stack. Ví dụ có thể giới thiệu thuật toán bảng tra cứu tốt hơn, và tải/unload bảng tra cứu động, để tiếp tục giảm kích thước script từng chunk.
Chi phí tính toán và môi trường chạy của ngôn ngữ web2 hoàn toàn khác với chi phí và môi trường chạy script Bitcoin, do đó việc hiện thực script Bitcoin cho các thuật toán khác nhau không thể chỉ dịch đơn thuần từ hiện thực hiện có. Vì vậy, cần xem xét các tối ưu sau cho kịch bản Bitcoin:
-
Tìm thuật toán tối ưu tính cục bộ bộ nhớ, dù phải hy sinh một phần lượng tính toán, để giảm số bit đầu vào và đầu ra giữa các chunk, từ đó giảm lượng dữ liệu cần cam kết trong giao dịch assertTx của thiết kế BitVM2.
-
Tận dụng tính giao hoán của các phép toán liên quan (như phép toán logic) x&y = y&x, tiết kiệm gần nửa bảng tra cứu.
-
Hiện nay, lượng script tương ứng phép toán Fq12 rất lớn, có thể xem xét dùng Fiat-Shamir, Schwartz-Zipple và sơ đồ cam kết đa thức để giảm đáng kể độ phức tạp tính toán phép toán mở rộng trường Fq12.
4 Tổng kết
Bài viết trước tiên giới thiệu các hạn chế script Bitcoin, và giới thiệu cách dùng cam kết bit để vượt giới hạn vô trạng thái UTXO, dùng Taproot để vượt giới hạn không gian script, dùng connector output để vượt giới hạn cách tiêu dùng UTXO, dùng covenant để vượt giới hạn ký trước. Sau đó toàn diện hệ thống và tổng kết đặc điểm bằng chứng hiệu lực và bằng chứng gian lận, đặc điểm bằng chứng gian lận theo giấy phép và không theo giấy phép, đặc điểm bằng chứng gian lận một vòng và nhiều vòng, và kỹ thuật chia script Bitcoin.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@BitlayerLabs
