Có nhiều hạn chế trong mô hình Bitcoin, nhưng có thể sử dụng nhiều phương pháp hoặc công nghệ thông minh khác nhau để vượt qua những hạn chế này.
Bài viết liên quan: (Phân tích các kỹ thuật mở rộng quy mô Bitcoin Layer2: Bằng chứng hợp lệ và Bằng chứng gian lận)
Được viết bởi: mutourend & lynndell, Bitlayer Labs
1 Giới thiệu
Đối với một thuật toán f nhất định, hai người tham gia Alice và Bob không tin tưởng lẫn nhau có thể thiết lập lòng tin theo cách sau:
Alice nhập x, chạy thuật toán f và nhận được kết quả y. Bob cũng chạy thuật toán f dựa trên cùng một đầu vào x và kết quả là y′. Nếu y = y′ thì Bob chấp nhận đầu vào x và đầu ra y do Alice cung cấp. Đây là một cơ chế chứng minh tính hợp lệ đặc biệt thường được sử dụng trong sự đồng thuận của blockchain. Trong số đó, Alice là nút đóng gói khối và Bob là nút tham gia đồng thuận.
Alice nhập x, chạy chương trình zk.prove trên thuật toán f và thu được kết quả y và bằng chứng. Bob chạy chương trình zk.verify dựa trên f, y và proof. Nếu kết quả đúng thì Bob chấp nhận kết quả y của Alice; nếu kết quả sai thì Bob không chấp nhận kết quả y của Alice. Đây là bằng chứng về hiệu quả. Trong số đó, Bob có thể là một hợp đồng trực tuyến.
Alice nhập x, chạy thuật toán f và nhận được kết quả y. Bob cũng chạy thuật toán f dựa trên cùng một đầu vào x và kết quả là y′. Nếu y = y′, không làm gì cả; nếu y ≠ y′, thì Bob thách thức Alice và chương trình bị thách thức là f. 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 thực hiện dựa trên quá trình phản hồi thách thức. Đây là bằng chứng của sự lừa đảo. Trong số đó, Bob là người thách thức, giám sát chuỗi và thách thức trên chuỗi.
Alice nhập x, chạy chương trình zk.prove trên thuật toán f và thu được kết quả y và bằng chứng. 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ả sai, Bob thách thức Alice và chương trình bị thử thách là zk.verify. Số lần tương tác giữa Alice và Bob có thể là một hoặc nhiều. 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 thực hiện dựa trên quá trình phản hồi thách thức. Đây là bằng chứng của sự lừa đảo. Trong số đó, Bob là người thách thức, giám sát chuỗi và thách thức trên chuỗi.
Đối với 2,3,4 ở trên, gọi x là giao dịch Lớp 2 và trạng thái bắt đầu, f là chương trình đồng thuận Lớp 2 và y là trạng thái kết thúc giao dịch, tương ứng với kế hoạch mở rộng lớp 2 của blockchain. TRONG:
Bằng chứng về tính hợp lệ: Dựa trên các giả định bi quan, nó phải được chứng minh là có hiệu quả trước khi được chấp nhận và nó sẽ có hiệu lực ngay lập tức. Trong chứng minh tính hợp lệ, cần đưa ra bằng chứng cho thấy sự chuyển đổi trạng thái L2 là đúng, phản ánh cái nhìn bi quan về thế giới - một trạng thái sẽ được chấp nhận khi và chỉ khi nó được chứng minh là đúng.
Bằng chứng gian lận: Dựa trên các giả định lạc quan, được chấp nhận theo mặc định và bị từ chối trừ khi được chứng minh là sai. Có một khoảng thời gian trong cửa sổ thử thách và nó sẽ không có hiệu lực cho đến sau khoảng thời gian trong cửa sổ thử thách. Trong bằng chứng gian lận, cần phải có bằng chứng cho thấy việc chuyển đổi trạng thái L2 là không chính xác, phản ánh quan điểm lạc quan về thế giới—việc chuyển đổi trạng thái là đúng theo mặc định trừ khi được chứng minh là không chính xác.
Bảng 1: Cách xây dựng niềm tin
Ngoài ra, xin lưu ý:
Chìa khóa để phân biệt bằng chứng gian lận với bằng chứng hợp lệ không phải là xác định liệu hệ thống bằng chứng ZK như SNARK/STARK có được sử dụng hay không. Hệ thống chứng minh ZK thể hiện phương pháp chứng minh được sử dụng, trong khi sự gian lận hoặc tính hợp lệ thể hiện nội dung của bằng chứng. Đây là lý do tại sao Kịch bản 1 trong Bảng 1 được coi là bằng chứng về tính hiệu quả.
Bằng chứng hợp lệ có tính kịp thời tốt hơn, nhưng độ phức tạp của xác minh trên chuỗi tương đối cao; bằng chứng gian lận có độ phức tạp thấp hơn của xác minh trên chuỗi, nhưng tính kịp thời tương đối kém.
Đối với trường hợp 2 và 4 trong Bảng 1, với sự trợ giúp của công nghệ kết hợp và đệ quy ZK, nhiều f có thể được tính toán và nén, khấu hao đáng kể và giảm chi phí xác minh của các tính toán ngoài chuỗi trên chuỗi.
Hiện tại, được hưởng lợi từ sự vững chắc của các hợp đồng thông minh Turing-complete, công nghệ chống 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 Ethereum Lớp 2. Tuy nhiên, theo mô hình Bitcoin, các ứng dụng kỹ thuật này vẫn đang trong giai đoạn khám phá do những hạn chế như chức năng opcode hạn chế của Bitcoin và 1.000 phần tử ngăn xếp. Theo kịch bản mở rộng Lớp 2 của Bitcoin, bài viết này tóm tắt các hạn chế và công nghệ đột phá theo mô hình Bitcoin, nghiên cứu công nghệ chứng minh tính hợp lệ và chống gian lận, đồng thời phân loại công nghệ phân đoạn tập lệnh độc đáo theo mô hình Bitcoin.
2 Hạn chế và đột phá theo mô hình Bitcoin
Có nhiều hạn chế trong mô hình Bitcoin, nhưng có thể sử dụng nhiều phương pháp hoặc công nghệ 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 giới hạn không trạng thái UTXO, taproot có thể vượt qua giới hạn không gian tập lệnh, đầu ra của trình kết nối có thể vượt qua giới hạn phương thức chi tiêu UTXO và hợp đồng có thể vượt qua giới hạn ký trước.
2.1 Giới hạn về mô hình và tập lệnh UTXO
Bitcoin sử dụng mô hình UTXO và 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 để chi tiêu UTXO đó. Bitcoin Script có những hạn chế sau:
Các tập lệnh bitcoin không có trạng thái;
Đối với loại đầu ra P2TR, tổng số opcode có thể được cung cấp trong một giao dịch lên tới xấp xỉ 4 triệu, sẽ lấp đầy toàn bộ khối, trong khi đối với các loại đầu ra khác chỉ là 10.000 opcode;
Các phương thức chi tiêu của một UTXO duy nhất bị hạn chế và thiếu sự khám phá các phương thức chi tiêu kết hợp;
Không hỗ trợ các chức năng hợp đồng linh hoạt;
Kích thước ngăn xếp được giới hạn tối đa 1000 phần tử (altstack + stack) và kích thước tối đa của một phần tử là 520 byte;
Các phép toán số học (chẳng hạn như cộng, trừ) được giới hạn ở các phần tử 4 byte. Không thể 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, nhưng cần thiết cho các hoạt động mã hóa;
Các opcode như OP_MUL và OP_CAT đã bị vô hiệu hóa. Nếu bạn sử dụng các opcode hiện có để mô phỏng, chi phí sẽ rất cao. Ví dụ: để mô phỏng hàm băm BLAKE3 một vòng, kích thước tập lệnh là khoảng 75K.
Cam kết 2.2 Bit: Vượt qua các giới hạn không trạng thái của UTXO
Các tập lệnh Bitcoin hiện tại hoàn toàn không có trạng thái. Khi thực thi các tập lệnh Bitcoin, môi trường thực thi của chúng sẽ được đặt lại sau mỗi tập lệnh. Điều này dẫn đến việc Bitcoin Script không thể hỗ trợ nguyên bản tập lệnh ràng buộc 1 và tập lệnh 2 để có cùng giá trị x. Tuy nhiên, có nhiều cách để giải quyết vấn đề này, ý tưởng cốt lõi là ký một giá trị theo một cách nào đó. Nếu bạn có thể tạo chữ ký trên một giá trị, bạn có thể triển khai các tập lệnh Bitcoin có trạng thái. Nghĩa là, bạn có thể buộc cùng một giá trị x trong Tập lệnh 1 và Tập lệnh 2 bằng cách kiểm tra chữ ký của giá trị x trong Tập lệnh 1 và Tập lệnh 2. Điều này có thể bị phạt nếu có chữ ký xung đột, tức là cùng một biến x được ký với 2 giá trị khác nhau. Giải pháp là cam kết bit.
Nguyên tắc cam kết Bit tương đối đơn giản. Cái gọi là bit đề cập đến việc thiết lập hai giá trị băm khác nhau cho mỗi bit trong thông báo chữ ký, đó là hash0 và hash1. Nếu giá trị bit cần được ký là 0 thì preimage0 của hash0 sẽ được hiển thị; nếu giá trị bit cần được ký là 1 thì preimage1 của hash1 sẽ được hiển thị.
Lấy một thông báo bit đơn m ∈ {0,1} làm ví dụ, tập lệnh mở khóa cam kết bit tương ứng chỉ là một tiền ảnh: nếu giá trị bit là 0, thì tập lệnh mở khóa tương ứng là preimage0 - "0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140" nếu giá trị bit là 1, tập lệnh mở khóa tương ứng là preimage1——"0x47c31e611a3bd2f3a7a42207613046703fa27496". Do đó, với sự trợ giúp của cam kết bit, giới hạn không trạng thái của UTXO có thể bị phá vỡ và các tập lệnh Bitcoin có trạng thái có thể được triển khai, tạo ra nhiều tính năng mới thú vị khác nhau.
OP_HASH160
OP_DUP
0xf592e757267b7f307324f1e78b34472f8b6f46f3> // Đây là hash1
OP_BẰNG
OP_DUP
OP_ROT
0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // Đây là hash0
OP_BẰNG
OP_BOOLOR
OP_XÁC MINH
// Bây giờ giá trị của cam kết bit nằm trên ngăn xếp. Hoặc là ”0” hoặc ”1”.
Bit Commitment hiện có 2 phương thức triển khai:
Chữ ký một lần của Lamport: Nguyên tắc tương đối đơn giản và chỉ yêu cầu sử dụng hàm băm nên thân thiện với Bitcoin. Đối với mỗi bit trong tin nhắn, cần phải 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, đối với một thông báo có độ dài v bit, độ dài khóa chung 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ó có thể giảm đáng kể độ dài của chữ ký và khóa chung, nhưng làm tăng độ phức tạp của việc ký và xác minh. Giải pháp này có thể linh hoạt thiết lập các giá trị d có độ dài chuỗi băm khác nhau để tạo ra sự cân bằng giữa độ dài và độ phức tạp. Ví dụ: khi d = 15 được đặt, độ dài khóa công khai và độ dài chữ ký sẽ ngắn hơn khoảng 4 lần, nhưng độ phức tạp của việc xác minh chữ ký sẽ tăng lên 4 lần. Đây thực chất là sự đánh đổi giữa không gian ngăn xếp Bitcoin và kích thước tập lệnh. Chữ ký Lamport có thể được coi là trường hợp đặc biệt của chữ ký Winternitz khi d =1.
Hiện tại, trong thư viện BitVM2, hàm băm dựa trên Blake3 triển khai chữ ký Winternitz. Độ dài chữ ký tương ứng với một bit đơn là khoảng 26 byte. Có thể thấy rằng chi phí đưa trạng thái thông qua cam kết bit là rất tốn kém. Do đó, trong quá trình triển khai dự án BitVM2, thông báo trước tiên được băm để thu được giá trị băm 256 bit, sau đó thực hiện cam kết bit trên giá trị băm, nhờ đó tiết kiệm chi phí thay vì trực tiếp thực hiện thao tác băm trên mỗi bit của lời hứa dài hơn ban đầu.
2.3 Taproot: Vượt qua giới hạn về không gian tập lệnh
Có 3 đề xuất được đưa vào bản nâng cấp soft fork Bitcoin Taproot được kích hoạt kể từ tháng 11 năm 2021: Schnorr Signature (BIP 340), Taproot (BIP 341) và TapScript (BIP 342). Một loại giao dịch mới được giới thiệu - Giao dịch trả tiền cho Taproot (P2TR). Giao dịch P2TR tạo ra định dạng giao dịch riêng tư, linh hoạt và có thể mở rộng hơn bằng cách kết hợp các ưu điểm của Taproot, MAST (Cây cú pháp trừu tượng Merkle) và chữ ký Schnorr.
P2TR hỗ trợ hai phương thức chi tiêu: chi tiêu dựa trên đường dẫn chính hoặc đường dẫn tập lệnh.
Theo quy định tại Taproot (BIP 341), khi chi tiêu bằng đường dẫn script thì độ dài tối đa của đường dẫn Merkle tương ứng không vượt quá 128. Điều này có nghĩa là số lượng lá vòi trong cây vòi không vượt quá 2128. 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 (tức là khoảng 4MB). Khi đầu ra P2TR được sử dụng thông qua đường dẫn tập lệnh, chỉ một tập lệnh tapleaf duy nhất cần được hiển thị, nghĩa là khối được đóng gói dưới dạng một tập lệnh tapleaf duy nhất. Điều này có nghĩa là đối với các giao dịch P2TR, kích thước tập lệnh tối đa tương ứng với mỗi tapleaf là khoảng 4MB. Tuy nhiên, trong chiến lược mặc định của Bitcoin, nhiều nút chỉ chuyển tiếp các giao dịch nhỏ hơn 400K. Nếu các giao dịch lớn hơn muốn được đóng gói, họ cần hợp tác với các thợ mỏ.
Phí bảo hiểm không gian tập lệnh do Taproot mang lại giúp việc sử dụng các mã hoạt động hiện có để mô phỏng các hoạt động mã hóa như nhân và băm trở nên có giá trị hơn.
Khi xây dựng một phép tính có thể kiểm chứng dựa trên P2TR, kích thước tập lệnh tương ứng không còn bị giới hạn ở 4 MB. Thay vào đó, phép tính có thể được chia thành nhiều hàm phụ và phân bổ trên nhiều tapleaf, nhờ đó vượt qua giới hạn về kích thước tập lệnh 4MB. Trên thực tế, kích thước của thuật toán xác minh Groth16 hiện được triển khai trong BitVM2 cao tới 2GB. Tuy nhiên, việc có thể phân chia và phân phối nó trong khoảng 1000 tapleaf, kết hợp với cam kết bit, có thể hạn chế tính toàn vẹn và tính chính xác của toàn bộ phép tính bằng cách hạn chế tính nhất quán giữa đầu vào và đầu ra của từng chức năng phụ.
2.4 Đầu ra của trình kết nối: Vượt qua những hạn chế của phương thức chi tiêu UTXO
Bitcoin hiện cung cấp các phương thức chi tiêu gốc cho một UTXO duy nhất: chi tiêu theo tập lệnh hoặc chi tiêu bằng khóa chung. Do đó, UTXO có thể được sử dụng miễn là chữ ký khóa công khai chính xác tương ứng được cung cấp hoặc đáp ứng các điều kiện của tập lệnh. Hai UTXO có thể được chi tiêu độc lập và không thể thêm các hạn chế để hạn chế hai UTXO để chúng phải đáp ứng một số điều kiện bổ sung trước khi có thể chi tiêu.
Tuy nhiên, Burak, người sáng lập giao thức Ark, đã nhận ra đầu ra của trình kết nối bằng cách sử dụng cờ SIGHASH một cách khéo léo. Cụ thể, Alice có thể tạo chữ ký để gửi BTC của mình cho Bob. Tuy nhiên, vì chữ ký có thể cam kết nhiều Đầu vào, Alice có thể đặt chữ ký của mình có điều kiện: chữ ký hợp lệ cho giao dịch Take_tx khi và chỉ khi giao dịch đó sử dụng đầu vào thứ hai. Đầu vào thứ hai được gọi là đầu nối, kết nối UTXO A và UTXO B. Nói cách khác, giao dịch Take_tx hợp lệ khi và chỉ khi UTXO B chưa được Challenge_tx chi tiêu. Do đó, bằng cách hủy đầu ra của trình kết nối, giao dịch Take_tx có thể bị chặn hiệu lực.
Hình 1: Sơ đồ đầu ra của đầu nối
Trong giao thức BitVM2, đầu ra của trình kết nối hoạt động như một hàm if...else. Sau khi giao dịch sử dụng đầu ra của trình kết nối, giao dịch khác sẽ không thể sử dụng giao dịch đó để đảm bảo tính độc quyền của giao dịch đó. Trong triển khai thực tế, UTXO với khóa thời gian cũng được giới thiệu để dành thời gian phản hồi thử thách. Ngoài ra, đầu ra của trình kết nối tương ứng cũng có thể đặt các chiến lược chi tiêu khác nhau nếu cần. Ví dụ: giao dịch thử thách có thể được đặt thành có thể chi tiêu bởi bất kỳ ai, trong khi giao dịch phản hồi có thể được đặt thành chỉ người điều hành mới có thể chi tiêu hoặc bất kỳ ai cũng có thể chi tiêu sau khi hết hạn. .
2.5 Hợp đồng: Vượt qua các hạn chế trước khi ký kết
Tập lệnh Bitcoin hiện tại chủ yếu giới hạn các điều kiện để mở khóa, nhưng không giới hạn cách UTXO có thể được chi tiêu thêm. Lý do là tập lệnh Bitcoin không thể đọc được nội dung của giao dịch, tức là nó không thể thực hiện việc xem xét nội tâm giao dịch. Nếu tập lệnh Bitcoin 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ì chức năng hợp đồng có thể được triển khai.
Phương pháp thực hiện hợp đồng hiện nay có thể được chia thành hai loại:
Ký trước: Dựa trên khả năng viết kịch bản Bitcoin hiện có, ký trước sẽ xây dựng các hợp đồng được xác định trước với chức năng hạn chế. Nghĩa là, tất cả các giao dịch có thể xảy ra trong tương lai đều được thiết kế và ký kết trước, khóa người tham gia vào các khóa và tỷ lệ riêng tư cụ thể. Một số kế hoạch thậm chí còn yêu cầu các bên tạo khóa riêng có thời hạn sử dụng ngắn cho tất cả các giao dịch được ký trước. Khi quá trình ký trước hoàn tất, các khóa riêng ngắn hạn này sẽ bị xóa một cách an toàn để kẻ tấn công không thể lấy được khóa riêng ngắn hạn và đánh cắp tiền. Tuy nhiên, mỗi lần người tham gia mới được thêm vào hoặc hoạt động được cập nhật, quy trình trên cần phải được lặp lại, dẫn đến chi phí bảo trì lớn. Ví dụ: Lightning Network thực hiện hợp đồng 2 bên thông qua việc ký trước và sử dụng công nghệ Hash Time Lock (HTLC) để triển khai chức năng định tuyến của nhiều hợp đồng 2 bên, từ đó đạt được chiến lược mở rộng giảm thiểu độ 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, điều này hơi cồng kềnh; trong BitVM1, hàng trăm giao dịch cần phải được ký trước mỗi khi nó được khởi tạo, trong khi ở BitVM2 được tối ưu hóa thì cần phải có. được ký trước mỗi lần khởi tạo. Số lượng giao dịch được ký trước cũng lên tới hàng chục. Cho dù đó là BitVM1 hay 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 có n người tham gia ký trước và mỗi người tham gia cần ký trước m giao dịch thì độ phức tạp của việc ký trước của mỗi người tham gia sẽ là n ∗ m.
Giới thiệu các opcode hợp đồng: Việc giới thiệu các opcode chức năng hợp đồng mới có thể làm giảm đáng kể độ 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, từ đó giới thiệu một phương thức triển khai hợp đồng 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 của nó rất đơn giản nhưng nó rất mạnh mẽ và có thể giảm đáng kể độ phức tạp của BitVM; OP_TXHASH: có thể kiểm soát các hành động trong hợp đồng với mức độ chi tiết tốt hơn. Nếu được sử dụng trong BitVM, nó có thể hỗ trợ một nhóm toán tử lớn hơn, từ đó cải thiện đáng kể các giả định bảo mật của BitVM và giảm thiểu độ tin cậy. Ngoài ra, phương thức ký trước dành cho thiết kế BitVM mà nhà điều hành chỉ có thể sử dụng quy trình hoàn trả khoản tạm ứng và hiệu quả sử dụng vốn thấp với mã hoạt động hợp đồng mới, có thể thanh toán trực tiếp cho người dùng rút tiền mặt từ người dùng; nhóm quỹ cố định, nâng cao hơn nữa hiệu quả sử dụng vốn. Do đó, mô hình hợp đồng linh hoạt sẽ vượt qua các hạn chế trước khi ký kết truyền thống một cách hiệu quả.
Chia tỷ lệ 3 Bitcoin Layer2: Bằng chứng xác thực 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 để mở rộng Bitcoin L2. Sự khác biệt chính giữa hai loại này được thể hiện trong Bảng 2.
Bảng 2: Bằng chứng xác thực và bằng chứng gian lận
Dựa trên cam kết bit, taproot, ký trước và đầu ra của trình 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 và bằng cách giới thiệu các mã hợp đồng như OP_CAT, bằng chứng hợp lệ dựa trên Bitcoin có thể được xây dựng. Ngoài ra, tùy thuộc vào việc Bob có hệ thống truy cập hay không, bằng chứng gian lận có thể được chia thành bằng chứng gian lận được cấp phép và bằng chứng gian lận không được phép. Trong số đó, trong bằng chứng gian lận được cấp phép, chỉ một nhóm cụ thể mới có thể thách thức với tư cách là Bob, trong khi ở 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ể thách thức với tư cách là Bob. Tính bảo mật của hệ thống không được phép tốt hơn so với hệ thống được phép, điều này có thể làm giảm nguy cơ mỗi người tham gia được phép tham gia vào các hành vi xấu xa.
Theo số lượng tương tác phản hồi thử thách giữa Alice và Bob, bằng chứng gian lận có thể được chia thành một vòng bằng chứng gian lận và nhiều vòng bằng chứng gian lận, như trong Hình 2.
Hình 2: Một vòng chứng minh gian lận và nhiều vòng chứng minh gian lận
Như được trình bày trong Bảng 3, bằng chứng gian lận có thể đạt được 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 so với tương tác nhiều vòng
Theo mô hình mở rộng Bitcoin Layer2, BitVM1 áp dụng cơ chế chống gian lận nhiều vòng, BitVM2 áp dụng cơ chế chống gian lận một vòng và bitcoincircle stark áp dụng bằng chứng hợp lệ. Trong số đó, BitVM1 và BitVM2 có thể được triển khai mà không cần bất kỳ sửa đổi nào đối với giao thức Bitcoin, trong khi vòng tròn bitcoin hoàn toàn yêu cầu giới thiệu mã opcode mới OP_CAT.
Đối với hầu hết các tác vụ điện toán, cần phải sử dụng tập lệnh 4MB, tập lệnh biểu diễn phép tính hoàn chỉnh, tập lệnh biểu diễn phép tính hoàn chỉnh thành các đoạn nhỏ hơn 4 MB và được phân phối cho hầu hết các tác vụ điện toán. .
3.1 Nhiều vòng chứng minh gian lận trên Bitcoin
Như được hiển thị 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 mà bạn muốn giảm số lượng tính toán trọng tài trên chuỗi và/hoặc khi không thể xác định được đ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 đoạn tính toán có vấn đề, sau đó tiến hành phân xử dựa trên các đoạn tính toán được định vị.
Sách trắng BitVM đầu tiên của Robin Linus (thường được gọi là BitVM1) đã sử dụng nhiều vòng bằng chứng gian lận. Giả sử rằng thời gian thử thách của mỗi vòng là một tuần và phương pháp tìm kiếm nhị phân được sử dụng để xác định đoạn tính toán vấn đề, thì thời gian phản hồi thử thách trên chuỗi đối với Trình xác minh Groth16 sẽ lên tới 30 tuần, cực kỳ kém về tính kịp thời. Mặc dù hiện tại có các nhóm đang nghiên cứu phương pháp tìm kiếm n-ary hiệu quả hơn phương pháp nhị phân nhưng tính kịp thời của nó vẫn thấp hơn nhiều so với chu kỳ 2 tuần trong một vòng chứng minh gian lận.
Hiện tại, nhiều vòng bằng chứng gian lận theo mô hình Bitcoin đều sử dụng các thử thách được cấp phép, trong khi một vòng bằng chứng gian lận thực hiện phương pháp thử thách không cần cấp phép, giúp giảm nguy cơ thông đồng giữa những người tham gia và mang lại tính bảo mật cao hơn. Để đạt được mục tiêu này, Robin Linus đã tận dụng tối đa lợi thế của taproot để tối ưu hóa BitVM1. Nó không chỉ giảm số vòng tương tác xuống còn một mà còn mở rộng phương thức thử thách thành phương thức không được phép, nhưng phải trả giá bằng việc tăng số lượng tính toán trọng tài trên chuỗi.
3.2 Một loạt bằng chứng gian lận về Bitcoin
Bằng chứng gian lận xác minh có thể được hoàn thành chỉ với một tương tác giữa người chứng minh và người xác minh. Trong mô hình này, người xác minh chỉ cần bắt đầu thử thách một lần và người chứng minh chỉ cần phản hồi một lần. Trong câu trả lời này, người chứng minh cần cung cấp một bằng chứng khẳng định rằng phép tính là đúng. Nếu người xác minh có thể tìm thấy sự không nhất quán từ bằng chứng này thì thử thách sẽ thành công, nếu không thì thử thách sẽ thất bại. Các đặc điểm của một vòng bằng chứng gian lận tương tác được thể hiện trong Bảng 3.
Hình 3: Một vòng chứng minh gian lận
Robin Linus đã phát hành sách trắng kỹ thuật BitVM2: Kết nối Bitcoin với Lớp thứ hai vào ngày 15 tháng 8 năm 2024, sử dụng phương pháp tương tự như Hình 3 để triển khai cầu nối chuỗi chéo BitVM2 với một vòng bằng chứng gian lận.
3.3 Bitcoin +OP_CAT thực hiện bằng chứng hợp lệ
OP_CAT là một phần của ngôn ngữ kịch bản khi Bitcoin được phát hành lần đầu tiên và 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 nó trong vài năm. Hiện tại OP_CAT đã được gán số 347 và được kích hoạ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 ngăn xếp và đẩy kết quả tổng hợp trở lại ngăn xếp. Tính năng này cho phép các hợp đồng và Trình xác minh STARK trên Bitcoin:
Hợp đồng: Andrew Poelstra đã trình bày Thủ thuật CAT và Schnorr I, sử dụng thủ thuật OP_CAT và Schnorr để thực hiện hợp đồng trên Bitcoin. Trong số đó, thuật toán Schnorr là chữ ký số của 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 ECDSA tương tự, xem Giao ước với CAT và ECDSA. Với hợp đồng OP_CAT, thuật toán Trình xác minh STARK có thể được chia thành nhiều giao dịch để dần dần xác minh toàn bộ bằng chứng STARK.
Trình xác minh STARK: Trình xác minh STARK về cơ bản nối dữ liệu lại 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 phép toán tập lệnh Bitcoin gốc giúp tiết kiệm rất nhiều chi phí. Lấy OP_SHA256 làm ví dụ, chế độ gốc chỉ yêu cầu một opcode, trong khi chế độ mô phỏng yêu cầu hàng trăm K. Hoạt động băm chính trong STARK là xác minh đường dẫn Merkle và phép biến đổi Fiat-Shamir. Do đó, OP_CAT rất thân thiện với thuật toán STARK Verifier.
3.4 Công nghệ phân chia tập lệnh Bitcoin
Mặc dù sau khi được SNARK/STARK chứng minh, lượng tính toán cần thiết để chạy thuật toán xác minh tương ứng nhằm xác minh bằng chứng ít hơn nhiều so với lượng tính toán cần thiết để chạy trực tiếp phép tính ban đầu f. Tuy nhiên, khi chuyển đổi điều này sang triển khai thuật toán xác minh trong tập lệnh Bitcoin, số lượng tập lệnh cần thiết vẫn rất lớn. Hiện tại, dựa trên opcode Bitcoin hiện có, sau khi tối ưu hóa, kích thước tập lệnh trình xác minh Groth16 và kích thước tập lệnh trình xác minh Fflonk được triển khai vẫn lớn hơn 2GB. Tuy nhiên, kích thước khối đơn của Bitcoin chỉ là 4MB và không thể chạy toàn bộ tập lệnh xác minh trong một khối duy nhất. Tuy nhiên, kể từ khi nâng cấp taproot, Bitcoin hỗ trợ thực thi các tập lệnh bằng tapleaf. Tập lệnh xác minh có thể được chia thành nhiều phần và sau đó mỗi phần được sử dụng làm một phần tapleaf để xây dựng một cây taproot. Giữa mỗi chunk, cam kết bit được sử dụng để đảm bảo tính nhất quán của các giá trị giữa các chunk.
Với 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, để có thể hoàn thành việc xác minh toàn bộ bằng chứng hiệu lực của STARK mà không cần phải hợp tác với các thợ mỏ.
Trong phần này, chúng tôi tập trung vào kỹ thuật Phân chia có liên quan cho các tập lệnh Bitcoin mà không giới thiệu bất kỳ opcode mới nào để kích hoạt các tình huống hiện có.
Khi phân đoạn tập lệnh, thông tin chiều sau cần được cân bằng:
Kích thước của một tập lệnh chunk không vượt quá 4MB và phải bao gồm không gian cho các tập lệnh cam kết bit đầu vào, chữ ký giao dịch, v.v.
Kích thước tối đa của một ngăn xếp đơn không vượt quá 1000. Do đó, chỉ nên giữ lại các phần tử bắt buộc trên mỗi ngăn xếp đoạn, từ đó dành đủ không gian ngăn xếp để phục vụ tối ưu hóa kích thước tập lệnh. Bởi 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.
Các cam kết về bit trên Bitcoin rất tốn kém. Do đó, hiện tại 1 bit tương ứng với 26 byte và số lượng bit đầu vào và đầu ra giữa hai khối liền kề phải được giảm thiểu.
Để tạo điều kiện thuận lợi cho việc kiểm tra, chức năng của từng phần phải càng rõ ràng càng tốt.
Hiện nay, các phương pháp phân đoạn chữ viết chủ yếu được chia thành ba loại sau:
Phân đoạn tự động: Dựa trên kích thước ngăn xếp và kích thước tập lệnh, hãy tìm phương pháp phân tách có kích thước tập lệnh khoảng 3 MB và kích thước ngăn xếp tối thiểu. Ưu điểm của phương pháp này là nó không liên quan gì đến thuật toán xác minh cụ thể và có thể được mở rộng cho bất kỳ phân đoạn tập lệnh được tính toán nào. Nhược điểm là: (1) Toàn bộ đoạn logic cần được đánh dấu riêng. Ví dụ: không thể phân tách khối mã OP_IF, nếu không kết quả thực thi tập lệnh phân tách sẽ không chính xác (2) Kết quả thực thi đoạn mã có thể tương ứng với nhiều đoạn; các 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 mà cam kết bit cần được áp dụng dựa trên logic tính toán thực tế; (3) Hàm logic được thực hiện bởi mỗi tập lệnh chunk khó đọc và không có lợi cho việc kiểm tra (4); ) Ngăn xếp có thể chứa các phần tử không được sử dụng trong đoạn tiếp theo, gây lãng phí không gian ngăn xếp.
Phân đoạn chức năng: Phân chia theo từng chức năng phụ trong phép tính. Các giá trị đầu vào và đầu ra của chức năng phụ rõ ràng. Trong khi tập lệnh được phân đoạn, tập lệnh cam kết bit cần thiết cho từng đoạn cũng được triển khai. tập lệnh tổng khối cuối cùng là Kích thước nhỏ hơn 4 MB và kích thước ngăn xếp nhỏ hơn 1000. Ưu điểm là: chức năng rõ ràng, logic rõ ràng của từng đoạn, khả năng đọc tốt và kiểm tra dễ dàng. Điểm bất lợi là biểu thức của logic tính toán ban đầu không khớp với biểu thức của logic cấp tập lệnh. Hàm phụ tính toán ban đầu có thể tối ưu nhưng không có nghĩa là nó tối ưu ở cấp tập lệnh.
Phân đoạn thủ công: Điểm phân đoạn tập lệnh không nằm ở các chức năng phụ mà được đặt thủ công. Đặc biệt thích hợp cho các tình huống có kích thước của một chức năng phụ lớn hơn 4MB. Ưu điểm là các hàm phụ có kích thước tập lệnh nặng, chẳng hạn như các hàm phụ tính toán liên quan đến Fq12, có thể được chia theo cách thủ công; một đoạn duy nhất có logic rõ ràng, dễ đọc và dễ kiểm tra. Nhược điểm là: bị hạn chế bởi khả năng điều chỉnh thủ công, khi tập lệnh tổng thể được tối ưu hóa, các điểm phân đoạn thủ công đã đặ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, trình xác minh Groth16 đã giảm kích thước tập lệnh 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 đoạn cũng có thể được tối ưu hóa riêng lẻ để tận dụng tối đa không gian ngăn xếp. Ví dụ: bằng cách giới thiệu thuật toán dựa trên bảng tra cứu tốt hơn và tải và dỡ tải động bảng tra cứu, kích thước tập lệnh của mỗi đoạn có thể được giảm thêm.
Chi phí tính toán và môi trường chạy của ngôn ngữ lập trình web2 hoàn toàn khác với chi phí và môi trường chạy tập lệnh Bitcoin, do đó, đối với việc triển khai tập lệnh Bitcoin của các thuật toán khác nhau, chỉ dịch các triển khai hiện có sẽ không hoạt động. Do đó, các tối ưu hóa sau đây cần được xem xét cho kịch bản Bitcoin:
Việc tìm kiếm một thuật toán có vị trí bộ nhớ tối ưu, ngay cả khi một phần của phép tính bị hy sinh, có thể giảm số lượng bit đầu vào và đầu ra giữa các khối, do đó giảm lượng dữ liệu được cam kết bởi giao dịch khẳng địnhTx trong thiết kế BitVM2.
Tận dụng tính giao hoán của các phép toán liên quan (chẳng hạn như phép toán logic), x&y = y&x, tiết kiệm gần một nửa bảng tra cứu.
Hiện tại, số lượng tập lệnh tương ứng với hoạt động Fq12 rất lớn. Hãy cân nhắc sử dụng các sơ đồ cam kết Fiat-Shamir, Schwartz-Zipple và đa thức để giảm đáng kể độ phức tạp tính toán của hoạt động miền mở rộng Fq12.
4 Tóm tắt
Bài viết này lần đầu tiên giới thiệu các hạn chế của tập lệnh Bitcoin và giới thiệu việc sử dụng Bitcoin hứa hẹn sẽ vượt qua các giới hạn không trạng thái của UTXO, việc sử dụng Taproot để vượt qua các giới hạn về không gian tập lệnh, việc 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 để vượt qua các hạn chế trước khi ký kết. Sau đó, các đặc điểm của bằng chứng gian lận và bằng chứng hợp lệ, các đặc điểm của bằng chứng gian lận được cấp phép và bằng chứng gian lận không được phép, các đặc điểm của một vòng bằng chứng gian lận và nhiều vòng bằng chứng gian lận cũng như công nghệ phân đoạn tập lệnh Bitcoin đã được sắp xếp và tóm tắt một cách toàn diện.
Tài liệu tham khảo
OP_IF, OP_CAT, OP_SHA256
Chữ ký một lần của Lamport
Chữ ký một lần của Winternitz
BitVM: Tính toán mọi thứ trên Bitcoin
BitVM2: Kết nối Bitcoin với Lớp thứ hai
CAT và Schnorr Tricks I
Các giao ước với CAT và ECDSA
Tổng hợp tính hợp lệ trên Bitcoin
StarkWare, Bằng chứng hợp lệ so với Bằng chứng gian lận, 2019.01.23
StarkWare, Bằng chứng hợp lệ so với Bằng chứng gian lận, 2024.05.09
StarkWare, Con đường đến với tính toán chung trên Bitcoin, 2024.07.24
BitVMX, Tối ưu hóa thuật toán cho Bitcoin Script, 2024.06.27
Alchemy, Optimistic Rollup hoạt động như thế nào (Hướng dẫn đầy đủ), 2023.08.09
Ethereum, Optimistic Rollups gian lận chứng minh, 2024.07.17
ZeroSync: Giới thiệu Bằng chứng hợp lệ cho Bitcoin
Robin Linus trên BitVM, 2024.01.16
Trình xác minh SNARK trong Bitcoin Script
