Tác giả: Janusz
Nguồn: https://insider.btcpp.dev/p/bitvm-based-bridges-and-emergency
Bài báo gốc được xuất bản vào tháng 8 năm 2025.
Khi các hợp đồng cầu nối dựa trên BitVM sắp hoàn cảnh trong môi trường sản xuất, tôi bắt đầu xem xét chủ đề về cái gọi là các đường dẫn "cập nhật khẩn cấp". Với sự trợ giúp của đội ngũ Citrea, tôi đã có thể hiểu được các cách khác nhau để xác minh các đường dẫn chi phí của các hợp đồng cầu nối BitVM, từ đó xác định xem chúng có chứa cơ chế cập nhật khẩn cấp hay không. Bài viết này cố gắng thảo luận về cách các dự án trong tương lai có thể triển khai các đường dẫn chi phí này. Lưu ý rằng các đường dẫn cập nhật khẩn cấp và các cơ chế đa chữ ký cho các hợp đồng chi phí không phải là "các tính năng đặc thù của BitVM"; chúng là các cơ chế được sử dụng rộng rãi trong các hợp đồng cầu nối được bảo vệ bởi các hệ thống bằng chứng, và tôi cho rằng chúng cũng sẽ được sử dụng trong việc xây dựng các hợp đồng cầu nối dựa trên BitVM. Bài viết này mang tính giải thích và hy vọng sẽ khơi gợi cuộc thảo luận về cách chúng ta nên công khai các loại đường dẫn chi phí này.
Bạn đã bao giờ gặp phải tình huống cần rút tiền từ ngân hàng ngay lập tức chưa? Ví dụ, xe của bạn bị hỏng và bạn cần trả tiền cho thợ sửa ngay lập tức. Hoặc, bạn của bạn uống quá chén ở quán bar và bạn cần trả một khoản tiền để giúp anh ấy ra khỏi đó.
Hợp đồng cầu nối BitVM có lẽ cũng muốn những đảm bảo tương tự. Chúng ta muốn các nhà điều hành hợp đồng cầu nối phải tuân thủ các quy tắc cụ thể do BitVM thiết lập ban đầu. Nhưng nếu có sự cố xảy ra thì sao? Nếu có lỗ hổng trong hệ thống cho phép kẻ tấn công lấy trong đó tiền một cách bất ngờ, hoặc khiến trong đó bị đóng băng vĩnh viễn thì sao?
Ngay cả khi một người thân thiện phát hiện ra lỗi, họ cũng có thể muốn tìm cách chuyển toàn bộ tiền ra khỏi hợp đồng trung gian trước để ngăn chặn việc hợp đồng bị vi phạm.
Sự đảm bảo này đạt được thông qua một thiết bị đa chữ ký khẩn cấp — một lộ trình chi tiêu bổ sung có thể được triển khai trong hợp đồng bắc cầu BitVM, cho phép một nhóm (hoặc một người) ký hoàn toàn bỏ qua trò chơi thách thức và cơ chế hoàn trả lạc quan và chuyển tiền ra khỏi hợp đồng bắc cầu.
BitVM là một công nghệ mới, và các cơ chế bắc cầu tương ứng của nó cũng mới. Một số đội ngũ ngần ngại phát hành các cấu trúc hợp đồng bắc cầu mới này mà không có bất kỳ cơ chế bảo hiểm nào. Những người tiên phong sử dụng hợp đồng bắc cầu và các nhà cung cấp thanh khoản cũng có thể muốn có một cơ chế chuyển đổi khẩn cấp để đảm bảo tiền của họ có thể được rút ra nếu phát hiện ra lỗi. Tính bất biến không phải lúc nào cũng hoàn toàn phù hợp với khích lệ thương mại.
Một số triển khai hợp đồng cầu nối BitVM ra mắt có có thể đã bao gồm các thiết bị đa chữ ký để cập nhật khẩn cấp. Nhiều cấu trúc hợp đồng cầu nối khác sẽ sớm ra mắt, và chúng có thể được triển khai cùng với một hội đồng bảo mật—một nhóm người ký được cấp phép vận hành thiết bị đa chữ ký khẩn cấp. Nếu mô hình bảo mật của các hệ thống này cuối cùng quay trở lại sử dụng thiết bị đa chữ ký M-of-N được cấp phép (ngay cả khi đó là thiết bị sử dụng một lần), người dùng có quyền được biết.
Tôi đã dành hai tuần để nghiên cứu phương pháp thành lập một hội đồng an ninh như vậy và liên tục suy nghĩ về phương pháp xác minh sự tồn tại của chúng (tất nhiên là với sự giúp đỡ của một số thành viên trong nhóm BitVM).
Những bài tập này đặt ra một "vấn đề" thú vị. Chúng ta không thể xác minh các đường dẫn chi tiêu này (trong blockchain) cho đến khi chúng thực sự được sử dụng. Nghĩa là, nếu những người nội bộ không tiết lộ chúng, một số người dùng thậm chí có thể không bao giờ biết rằng một thiết bị đa chữ ký M-of-N được cấp phép dựa trên giả định về độ tin cậy tối cao của một hợp đồng cầu nối dựa trên BitVM.
Đánh giá hợp đồng BitVM Bridge
" BitVM ," do Robin Linux đề xuất, là một phương pháp cho phép thực hiện các phép tính tùy ý trong blockchain Bitcoin . Nó đã khơi mào một làn sóng phát triển Bitcoin mới, với nhiều đội ngũ sử dụng công nghệ này để phát triển các hợp đồng cầu nối Layer 2. Các hợp đồng này hỗ trợ cấu trúc Layer 2 , nơi nhiều nhà điều hành có thể nắm giữ Bitcoin , đóng vai trò là người bảo lãnh cho tài sản Bitcoin được đóng gói trên Layer 2. Quan trọng hơn, nó cũng cho phép một cơ chế phát hiện lạc quan bổ sung có thể được sử dụng để thách thức trong đó từ các nhà điều hành.
Trong giai đoạn khởi tạo, một nhóm người ký kết tạo thành một thiết bị đa chữ ký N-trên-N để ký trước biểu đồ giao dịch cho một hợp đồng bắc cầu. Nếu bất kỳ ai trong đó họ đốt private key được sử dụng trong nghi thức ký trước này, thì các UTXO bị khóa trong hợp đồng bắc cầu chỉ có thể được sử dụng bởi một kịch bản chi tiêu được xác định trước.
Trong một số trường hợp, nhà điều hành phải ứng trước tiền (dưới dạng thanh khoản) và sau đó yêu cầu hoàn trả từ hợp đồng trung gian. Nhà điều hành chỉ có thể tự hoàn trả sau một khoảng thời gian nhất định. Một thiết kế khác cho phép người dùng làm việc với các nhà điều hành trung thực, những người sẽ cung cấp private key cần thiết để chuyển tiền ra khỏi hợp đồng trung gian.
Bất kể thiết kế như thế nào, ít nhất phải có một người vận hành trung thực để xử lý các giao dịch rút tiền. Nếu người vận hành không trung thực—ví dụ, nếu họ chứng kiến một giao dịch rút tiền trái với trạng thái ban đầu của hệ thống—một người quan sát (dịch vụ tháp canh) có thể khiếu nại họ.
"Tháp canh" được đề cập ở đây là một thực thể (hoặc một cá nhân) vận hành phần mềm xác thực BitVM và có thể thách thức rồi chặn các yêu cầu rút tiền từ các nhà điều hành hợp đồng cầu nối BitVM.
Ví dụ, liên quan đến việc rút tiền không đúng quy định, một nhà điều hành có thể cố gắng rút số dư tiền hơn mức cho phép từ phiên bản BitVM của họ. Đó là lý do tại sao các khoản chi từ hợp đồng cầu nối bao gồm một khóa thời gian . Nó cho phép tháp canh có thời gian để gửi yêu cầu xác nhận. Khoảng thời gian từ khi hợp đồng rút tiền được phát đi đến khi khóa thời gian được mở khóa được gọi là " cửa sổ yêu cầu xác nhận ".
Chỉ sau khi cửa sổ thử thách đóng lại và các trinh sát được cảnh báo, người điều hành (hoặc người dùng) mới có thể rút tiền từ hợp đồng cầu nối. Trong hợp đồng cầu nối dựa trên BitVM, hành vi trộm cắp đòi hỏi sự thông đồng giữa tất cả người điều hành và các tháp giám sát (điều này có thể cướp sạch toàn bộ hợp đồng cầu nối). Tiền sẽ không bị đánh cắp miễn là một trong đó trung thực, định kì kiểm tra blockchain, trình xác thực của họ đang trực tuyến và sẵn sàng gửi thử thách. Giả định về độ tin cậy 1 trên N này là tốt vì nó có nghĩa là chúng ta cần tin tưởng ít người hơn so với một liên minh tiêu chuẩn, nơi mà đa số các cá nhân không trung thực là đủ để đánh cắp tiền.
Cơ chế nói trên tạo ra một cơ chế kết nối với mức độ tin cậy thậm chí còn thấp hơn cả những cơ chế hiện đang được sử dụng trên mạng Bitcoin. Tuy nhiên, trên thực tế, giả định cốt lõi về sự tin cậy này cuối cùng có thể quay trở lại cơ chế đa chữ ký có quyền truy cập (mặc dù chỉ tạm thời). (Ghi chú của người dịch: Tình hình sau khi quay trở lại này cũng giống như các cơ chế hiện đang được triển khai (liên minh đa chữ ký cho sidechain).)
Giới thiệu tính năng chữ ký đa dạng khẩn cấp
Như đã đề cập trong phần giới thiệu, đội ngũ phát triển có thể (và sẽ) thêm một đường dẫn chi tiêu khẩn cấp vào các phiên bản BitVM của họ. Việc họ có nên làm vậy hay không không quan trọng. Điều quan trọng hơn là hầu hết các hợp đồng bắc cầu dựa trên BitVM được đưa vào hoàn cảnh đều bao gồm cơ chế chi tiêu khẩn cấp trước khi chúng hoàn thiện. Điều chúng ta nên kỳ vọng là đội ngũ phát triển này sẽ công khai rõ ràng bản chất của các đường dẫn chi tiêu khẩn cấp này.
Cơ chế đa chữ ký khẩn cấp không phải là tính năng của BitVM. Đây là cơ chế được sử dụng rộng rãi trong các hợp đồng cầu nối được bảo vệ bởi hệ thống bằng chứng để cập nhật hệ thống khi phát hiện lỗi. Các trường hợp Rollup trong các hệ sinh thái khác đã thiết lập tiền lệ về vấn đề này.
Hợp đồng cầu nối BitVM sử dụng tập lệnh Segregated Witness v1 (Taproot) để tạo đường dẫn chi tiêu cho hợp đồng cầu nối đã được ký trước. Tập lệnh Taproot sử dụng MAST, cho phép lượng lớn điều kiện chi tiêu tồn tại trong một UTXO duy nhất. Khi một tập lệnh lá được sử dụng để chi tiêu UTXO này, chỉ tập lệnh lá đó được hiển thị (các tập lệnh lá khác tồn tại đồng thời không cần phải được hiển thị).
Bài báo về BitVM2 đã chỉ ra một cách chính xác rằng các giao dịch được ký trước có thể hạn chế người vận hành chỉ sử dụng các phương thức có thể bị kiểm chứng khi rút tiền. Tuy nhiên, không có gì ngăn cản các nhà phát triển của một phiên bản BitVM cụ thể đưa thêm các đường dẫn chi tiêu vào cây kịch bản Taproot cho phép rút tiền từ hợp đồng cầu nối.
Trong cây kịch bản Taproot, mỗi đường dẫn chi tiêu được gọi là một kịch bản "lá". Để mở khóa và chi tiêu một UTXO bị khóa bởi cây kịch bản này, bạn chỉ cần tiết lộ một trong đó lá hợp lệ (và cung cấp dữ liệu chứng thực đáp ứng kịch bản lá đó).
Hãy xem một ví dụ: Lộ trình đầu tiên (hay tờ rơi đầu tiên) là lộ trình rút tiền tiêu chuẩn, có cửa sổ xác nhận. Lộ trình còn lại là lộ trình chi tiêu khẩn cấp, bỏ qua cửa sổ xác nhận.
Lá A: Điều kiện chi tiêu được bảo vệ bởi bằng chứng gian lận 1-trong-N
OP_PUSHBYTES_2 <SomeDelay>OP_CSVOP_DROPOP_PUSHBYTES_32 <OperatorPubKey>OP_CHECKSIGTrang B: Điều kiện chi phí tháo neo khẩn cấp (2/3)
OP_PUSHBYTES_32 <pubkey1>OP_CHECKSIGOP_PUSHBYTES_32 <pubkey2>OP_CHECKSIGADDOP_PUSHBYTES_32 <pubkey3>OP_CHECKSIGADDOP_PUSHNUM_2OP_NUMEQUAL "Lá A" là điều kiện hoàn trả rút tiền tiêu chuẩn trong một phiên bản BitVM. Sau một khoảng thời gian thử thách ( <SomeDelay> ), một nhà điều hành được chỉ định trước có thể rút tiền từ hợp đồng cầu nối. Nếu một nhà điều hành sử dụng UTXO bị khóa trong hợp đồng cầu nối một cách không trung thực, một trạm giám sát có thể thách thức họ trong khoảng thời gian thử thách (tức là khoảng thời gian giữa việc sử dụng hợp đồng BitVM và thời điểm hết hạn của khóa thời gian <SomeDelay> ) để ngăn chặn các yêu cầu rút tiền không trung thực.
Lá A có thể là chi phí của một giao dịch đã được ký trước do một ủy ban N-of-N ký trước thực hiện.
Mặt khác, "Lá B" là một phương thức chi tiêu hiệu quả tức thì; một thiết bị đa chữ ký 2/3 có thể chuyển ngay lập tức toàn bộ số tiền trong hợp đồng BitVM. Điều này có thể được thực hiện nếu đội ngũ phát triển phát hiện ra một lỗi có thể khai thác trong hợp đồng, hoặc nếu họ quyết định bỏ trốn với số tiền đó.
Khi tôi nói "hợp đồng", tôi luôn muốn nói đến hợp đồng BitVM kiểm soát các điều kiện chi tiêu của một UTXO Bitcoin.
Hai điều kiện chi phí này có thể cùng tồn tại trên cây kịch bản gốc của hợp đồng cầu nối. Mặc dù việc thêm một điều kiện chi phí có thể bỏ qua trò chơi Thử thách-Phản hồi của BitVM không phải lúc nào cũng hợp lý, nhưng về mặt khách quan, không có gì ngăn cản các nhà phát triển triển khai điều kiện chi phí như vậy.
Hơn nữa, các điều kiện chi tiêu trên cây kịch bản có thể rất linh hoạt. Trong các ví dụ trên, chúng ta chỉ minh họa hai điều kiện chi tiêu. Tuy nhiên, đội ngũ phát triển có thể tạo ra cây kịch bản chứa nhiều điều kiện chi tiêu khác nhau. Lá B ở trên là một ví dụ: cơ chế cập nhật khẩn cấp này không có độ trễ và có thể được chi tiêu bởi một nhóm người ký 2/3, dẫn đến việc đánh cắp tiền của người dùng. Nâng cấp giao thức mở rộng hơn có thể được khởi xướng bởi một hội đồng bảo mật 9/12 và bao gồm cả khóa thời gian.
Thiết kế cụ thể có thể khác nhau giữa các triển khai; điều quan trọng là chúng ta phải có khả năng xác minh các điều kiện chi tiêu này. Một "vấn đề" với các script Bitcoin hiện đại là bạn không thể công khai xác minh một script cho đến khi nó được chi tiêu. Điều này liên quan chặt chẽ đến các hợp đồng cầu nối dựa trên BitVM, có nghĩa là chúng ta không thể xác minh tất cả các đường dẫn chi tiêu cho đến khi một script lá cụ thể được sử dụng để chi tiêu một UTXO. Hãy nhớ rằng, khi một lá được chi tiêu, chỉ các điều kiện chi tiêu được thể hiện bởi lá đó mới được tiết lộ. Do đó, nếu chỉ có một giao dịch rút tiền thông thường được thực hiện trong trường hợp của chúng ta, chúng ta không thể xác minh sự tồn tại của một đường dẫn chi tiêu khẩn cấp; và ngược lại.
Điều này có thể gây ra vấn đề. Nếu đội ngũ phát triển chèn một cơ chế chi tiêu khẩn cấp vào cây mã nguồn nhưng không bao giờ công khai nó, người dùng có thể không bao giờ chắc chắn rằng không có thiết bị đa chữ ký được cấp phép (hoặc cá nhân được cấp phép) nào có thể chi tiêu tất cả số tiền bị khóa trong hợp đồng trung gian.
Sau một tuần suy nghĩ, tôi đã nghĩ ra một số phương pháp để đội ngũ phát triển dự án có thể tiết lộ lộ trình chi phí của hợp đồng xây cầu.
Phương pháp công bố thông tin
Hãy trình bày rõ ràng đường dẫn chi tiêu trong sách hướng dẫn.
Đối với đội ngũ phát triển, cách tiếp cận đơn giản nhất là công khai nhân vật đặc quyền trong sách hướng dẫn . Đội ngũ phát triển có thể trực tiếp công khai ai vận hành hợp đồng bắc cầu, ai tham gia vào buổi lễ ký kết trước đó, ai điều hành ứng dụng khách nhẹ và ai là người giám sát.
Việc công khai một số thông tin còn hơn là không có gì, nhưng chúng ta vẫn không thể xác minh được đường đi của chi phí hợp đồng bắc cầu chỉ dựa trên sách hướng dẫn trên trang web. Sẽ tốt hơn nữa nếu chúng ta có thể trực tiếp xác minh mã nguồn.
Kiểm tra trước khi nạp tiền.
Đội ngũ phát triển có thể gửi các giao dịch thử nghiệm cho các lộ trình chi tiêu khác nhau. Họ có thể chi tiêu một số tiền từ một tài khoản nhất định để cuối cùng tiết lộ tất cả các lộ trình chi tiêu, và người dùng cũng có thể tự mình xác minh các lộ trình chi tiêu đó.
Điều này đòi hỏi đội ngũ phát triển phải sử dụng hết mọi nút lá trong cây kịch bản. Ngay cả như vậy, chúng ta vẫn không thể chắc chắn rằng họ sẽ không chèn thêm các điều kiện chi tiêu chưa từng được tiết lộ. Đội ngũ phát triển luôn có thể chọn lọc không sử dụng một nút lá cụ thể hoặc không tiết lộ các điều kiện chi tiêu. Điều này thường được coi là một tính năng của Taproot MAST, nhưng trong bối cảnh các hợp đồng bắc cầu, nó làm giảm sự tin tưởng của người dùng rằng đội ngũ phát triển thực sự đã tiết lộ tất cả các kịch bản chi tiêu.
Đáng tiếc là giao dịch thử nghiệm không mang lại sự minh bạch như chúng tôi mong đợi.
Sử dụng các điều khoản hạn chế quy mô lớn để mô phỏng các ủy ban.
Một cách tiếp cận khác là đội ngũ phát triển sử dụng một ràng buộc đủ lớn để mô phỏng một ủy ban và cho phép các thành viên độc lập có cơ hội tham gia vào tất cả các giao dịch trong biểu đồ giao dịch hợp đồng bắc cầu đã ký trước. Điều này sẽ cho phép các thành viên độc lập xác minh sự tồn tại của nhiều chữ ký khẩn cấp và số lượng người ký trong đó.
Tuy nhiên, điều này vẫn đòi hỏi người dùng phải tin tưởng các thành viên của ủy ban điều khoản hạn chế, thay vì để họ trực tiếp xác minh kịch bản. Tôi cho rằng hướng đi đúng đắn là chúng ta có thể cho bất kỳ người dùng nào cơ hội xác minh đường dẫn chi phí của hợp đồng bắc cầu.
Xây dựng phương pháp công bố thông tin tiêu chuẩn hóa
Theo quan điểm cá nhân của tôi, chúng ta nên kỳ vọng đội ngũ phát triển sẽ công bố toàn bộ cây mã nguồn mà họ đã tạo cho các phiên bản BitVM của mình.
Nếu đội ngũ phát triển cung cấp khóa nội bộ để tạo tapscript, bộ đầy đủ các leaf script và địa chỉ hợp đồng cầu nối tương ứng, chúng ta có thể tự làm được.
Sử dụng thông tin này—khóa công khai nội bộ được dùng để tạo đường dẫn chi phí và gốc Merkle được suy ra từ cây kịch bản taproot—chúng ta có thể cộng chúng lại với nhau để có được khóa công khai đã điều chỉnh. Nếu khóa công khai đã điều chỉnh này khớp với địa chỉ trong hợp đồng cầu nối BitVM, chúng ta đã xác minh rằng địa chỉ đó thực sự chỉ chứa các kịch bản chi phí này.
Hãy xem! Chúng ta có một phương pháp tiết lộ có thể kiểm chứng được. Nếu một đội ngũ phát triển để lộ cây kịch bản taproot không chính xác, khóa công khai đã điều chỉnh sẽ không khớp với địa chỉ trong hợp đồng cầu nối.
Phương pháp công khai này cho phép chúng ta thực sự xác minh các giả định tin cậy chính liên quan đến một phiên bản hợp đồng cầu nối BitVM. Tuy nhiên, nó yêu cầu đội ngũ phát triển phải công khai toàn bộ cây mã nguồn và khóa công khai nội bộ liên quan.
Tầm quan trọng của tính minh bạch
Ngay cả khi không tiết lộ danh tính người ký, chúng ta vẫn cần kịch bản để hiểu được giả định về sự tin tưởng thực sự. Các hệ thống này được thiết kế dựa trên giả định về sự tin tưởng của người tham gia trung thực (1/N). Nhưng nếu giả định về sự tin tưởng cuối cùng chuyển sang cơ chế đa chữ ký có sự cho phép, thì người dùng gửi tiền vào các hợp đồng này có quyền được biết.
Tôi dự đoán rằng phần lớn các hợp đồng bắc cầu dựa trên BitVM sẽ chứa các đường dẫn chi phí cập nhật khẩn cấp như vậy. Tôi hy vọng các hợp đồng bắc cầu này sẽ không phải lúc nào cũng có các đường dẫn chi phí này, và chúng ta có thể nâng cấp lên một thiết kế giảm thiểu sự phụ thuộc vào lòng tin hơn. Tuy nhiên, chúng ta không thể bỏ qua chúng hoặc lấy lý do rằng chúng không phải là mô hình phụ thuộc vào lòng tin duy nhất.
Chừng nào còn tồn tại phương án chi tiêu khẩn cấp, thì không thể phủ nhận rằng đó chính là một mô hình xây dựng lòng tin.
(qua)
