HTX Venture: Khám phá thế giới BTCFI từ góc độ khả năng lập trình của Bitcoin
Tuyển chọn TechFlowTuyển chọn TechFlow
HTX Venture: Khám phá thế giới BTCFI từ góc độ khả năng lập trình của Bitcoin
Với sự xuất hiện của các ứng dụng mới như giao thức stake Babylon và các phương pháp mở rộng native dựa trên UTXO như Fractal Bitcoin, tiềm năng thị trường của BTCFI đang dần được lộ rõ.
Chuyên sâu báo cáo Web3
Tóm tắt
Bài viết này bắt đầu từ tính khả thi và lộ trình phát triển của lập trình Bitcoin, hệ thống hóa việc khám phá tiềm năng và thách thức của Bitcoin trong lĩnh vực tài chính phi tập trung (BTCFI). Về kiến trúc, Bitcoin sử dụng mô hình UTXO và thông qua ngôn ngữ kịch bản cùng các mã vận hành riêng biệt để hình thành hệ thống hợp đồng dựa trên xác minh. So với hợp đồng thông minh Ethereum, đặc điểm của hợp đồng Bitcoin là "không trạng thái" và "không thể tính toán", khiến chức năng bị giới hạn nhưng đồng thời cũng sở hữu mức độ an toàn cao hơn và đặc tính phi tập trung mạnh mẽ.
Với việc nâng cấp Taproot được triển khai, khả năng hợp đồng của Bitcoin đã được tăng cường đáng kể. Việc giới thiệu Taproot, đặc biệt là ứng dụng MAST và chữ ký Schnorr, cho phép Bitcoin hỗ trợ logic hợp đồng phức tạp hơn, đồng thời cải thiện rõ rệt tính riêng tư và hiệu quả giao dịch. Những đổi mới công nghệ này mở đường cho sự phát triển sâu rộng hơn của BTCFI, giúp Bitcoin có thể khám phá nhiều trường hợp ứng dụng tài chính hơn nữa mà vẫn duy trì được lợi thế phi tập trung vốn có.
Dựa trên nền tảng đó, bài viết đi sâu phân tích cách lập trình Bitcoin hỗ trợ nhiều ứng dụng BTCFI khác nhau. Thông qua giải thích về cơ chế đa chữ ký, khóa thời gian, khóa băm, cũng như thảo luận về ứng dụng các công cụ như DLC, PSBT, MuSig2, bài viết cho thấy khả năng thực hiện thanh toán phi tập trung và các hợp đồng tài chính phức tạp mà không cần tin tưởng bên thứ ba. Hệ thống tài chính phi tập trung gốc trên mạng Bitcoin này không chỉ khắc phục được rủi ro tập trung trong mô hình cầu nối chéo chuỗi thời WBTC, mà còn mang lại nền tảng tin cậy vững chắc hơn cho người nắm giữ Bitcoin.
Cuối cùng, bài viết nhấn mạnh rằng sự phát triển của tài chính phi tập trung Bitcoin không chỉ đơn thuần là tiến bộ công nghệ, mà còn là sự biến đổi sâu sắc về cấu trúc hệ sinh thái. Khi xuất hiện các ứng dụng mới như giao thức đặt cược Babylon hay các phương pháp mở rộng nội tại theo kiểu native scaling dựa trên UTXO như Fractal Bitcoin, tiềm năng thị trường của BTCFI đang dần được bộc lộ. Trong tương lai, khi giá Bitcoin tăng lên, BTCFI sẽ thu hút thêm nhiều người dùng chính thống tham gia, tạo thành một hệ sinh thái tài chính mới lấy Bitcoin làm trung tâm. Sự hình thành hệ sinh thái này sẽ thúc đẩy Bitcoin tiến xa hơn khỏi câu chuyện “vàng kỹ thuật số”, trở thành cơ sở hạ tầng tài chính phi tập trung thiết yếu trong hệ thống kinh tế toàn cầu.
Mở đầu
Kể từ khi giao thức Ordinals ra mắt vào tháng 12 năm 2022, thị trường đã chứng kiến sự xuất hiện của hàng chục giao thức phát hành tài sản như BRC-20, Atomicals, Pipe, Runes, cùng với hàng trăm mạng lớp 2 Bitcoin, cộng đồng cũng tích cực thảo luận về tính khả thi của tài chính phi tập trung Bitcoin (BTCFI).
Trong chu kỳ tiền mã hóa trước, nhằm thu hút người nắm giữ Bitcoin tham gia DeFi, WBTC đã ra đời. WBTC khóa Bitcoin thông qua tổ chức lưu ký tập trung rồi đúc thành WBTC để sử dụng trong các giao thức DeFi trên Ethereum. Người dùng mục tiêu của WBTC là những ai sẵn sàng chấp nhận rủi ro cầu nối chéo chuỗi tập trung để tham gia vào DeFi bằng Bitcoin. Là đại diện điển hình cho việc nối cầu Bitcoin sang hệ sinh thái EVM, WBTC đã mở ra một con đường cho BTCFI. Các mạng lớp 2 Bitcoin thuộc hệ EVM và các dự án DeFi trong hệ sinh thái của chúng trong chu kỳ này cũng tiếp tục mô hình này. Dù mô hình này giúp WBTC đạt được vốn hóa thị trường hơn 9 tỷ USD trong hệ sinh thái Ethereum, nhưng so với vốn hóa thị trường tổng thể của Bitcoin thì tỷ lệ này chưa đến 1%, phản ánh rõ ràng hạn chế của mô hình này.
Ngược lại, nếu người nắm giữ Bitcoin có thể trực tiếp dùng Bitcoin tham gia BTCFI mà không cần đúc chéo chuỗi, đồng thời đảm bảo tiền được lưu ký một cách phi tập trung, điều này sẽ thu hút được nhiều người dùng Bitcoin hơn, tạo ra một thị trường rộng lớn hơn. Điều này đòi hỏi phải thực hiện lập trình Bitcoin trên cấu trúc UTXO. Cũng giống như việc nắm vững Solidity là chìa khóa để bước vào DeFi Ethereum, việc nắm vững lập trình Bitcoin là kỹ năng thiết yếu để tham gia thị trường BTCFI.
Khác với hợp đồng Ethereum, hợp đồng Bitcoin không có khả năng tính toán, mà giống như một chương trình xác minh được kết nối bởi từng chữ ký. Mặc dù ban đầu phạm vi ứng dụng rất hạn chế, nhưng nhờ liên tục nâng cấp mạng lưới Bitcoin và sáng tạo từ cộng đồng OG, tiềm năng của lập trình Bitcoin ngày càng bộc lộ rõ nét, nhiều nghiên cứu đã được chuyển hóa thành các sản phẩm BTCFI sắp ra mắt.
Bài viết này sẽ khám phá sâu vào con đường phát triển BTCFI từ góc độ khả năng lập trình của Bitcoin, làm rõ dòng chảy lịch sử và logic của lập trình Bitcoin, giúp độc giả hiểu được các tình huống ứng dụng thực tế hiện nay của BTCFI, cũng như cách những tình huống này sẽ ảnh hưởng đến người nắm giữ Bitcoin và toàn bộ hệ sinh thái Bitcoin.
Nền tảng của hợp đồng Bitcoin
Suy nghĩ của Satoshi: UTXO, ngôn ngữ kịch bản và mã vận hành
Năm 2010, satoshi (tức Satoshi Nakamoto) đã viết trên diễn đàn bitcoin talk:
-
Thiết kế cốt lõi của Bitcoin sẽ được cố định sau phiên bản 0.1, do đó tôi hy vọng nó có thể hỗ trợ nhiều loại giao dịch nhất có thể, nhưng mỗi loại giao dịch đều cần đoạn mã hỗ trợ và trường dữ liệu đặc biệt, mỗi lần chỉ xử lý một trường hợp đặc biệt, điều này dẫn đến quá nhiều trường hợp đặc biệt.
-
Giải pháp cho vấn đề này là kịch bản. Bên gửi và bên nhận giao dịch có thể biên dịch giao dịch thành một khẳng định (ngôn ngữ kịch bản) để mạng nút kiểm tra, các nút xác minh khẳng định (ngôn ngữ kịch bản) để đánh giá xem điều kiện của người gửi đã thỏa mãn hay chưa.
-
“Kịch bản” chỉ đơn giản là một “khẳng định (predicate)”. Thực tế đây chỉ là một phương trình có kết quả đúng hoặc sai. Nhưng “predicate” là một từ dài và hiếm gặp, nên tôi gọi nó là “kịch bản”.
-
Bên nhận tiền sẽ thực hiện khớp mẫu với kịch bản. Hiện tại, bên nhận chỉ chấp nhận hai mẫu: thanh toán trực tiếp và địa chỉ Bitcoin. Các phiên bản trong tương lai có thể thêm nhiều mẫu loại giao dịch hơn, các nút chạy phiên bản này hoặc cao hơn sẽ có thể nhận chúng. Tất cả các nút trong mạng đều có thể xác minh, xử lý mọi giao dịch mới và đưa vào khối, ngay cả khi họ có thể không biết cách đọc giao dịch đó.
-
Thiết kế này hỗ trợ nhiều loại giao dịch khác nhau mà tôi đã thiết kế từ nhiều năm trước. Bao gồm giao dịch ủy thác, hợp đồng bảo lãnh, trọng tài bên thứ ba, đa chữ ký, v.v. Nếu Bitcoin trở nên phổ biến, đây là những lĩnh vực chúng ta có thể muốn khám phá trong tương lai, nhưng chúng phải được thiết kế ngay từ đầu để đảm bảo khả năng thực hiện trong tương lai.
Thiết kế của Satoshi cách đây mười bốn năm đã đặt nền móng cho lập trình Bitcoin. Mạng Bitcoin không có khái niệm “tài khoản”, chỉ có “đầu ra” (output), tên đầy đủ là “giao dịch đầu ra (TXO)”, đại diện cho từng khoản tiền Bitcoin, là đơn vị cơ bản của trạng thái hệ thống Bitcoin.
Khi chi tiêu một đầu ra, tức là biến đầu ra đó thành đầu vào của một giao dịch, hay nói cách khác là cung cấp tiền cho giao dịch đó. Đó là lý do vì sao chúng ta nói hệ thống Bitcoin dựa trên mô hình “UTXO (Unspent Transaction Output)”, vì chỉ có “UTXO (đầu ra giao dịch chưa chi tiêu)” mới là những khối kim loại mà chúng ta có thể sử dụng trong quá trình giao dịch; khối kim loại đi vào một lò luyện, sau khi nấu chảy sẽ tạo thành các khối kim loại mới (UTXO mới), và khối kim loại cũ “giao dịch đầu ra (TXO)” sẽ không còn tồn tại.
Mỗi khoản tiền đều có kịch bản khóa (còn gọi là khóa công khai kịch bản) và mệnh giá riêng. Theo quy tắc đồng thuận Bitcoin, khóa công khai kịch bản có thể tạo thành một chương trình xác minh —— tức là khóa công khai cộng với lệnh thực hiện thao tác cụ thể trong kịch bản (mã vận hành OP-Codes). Để mở khóa, phải cung cấp một tập dữ liệu cụ thể gọi là kịch bản mở khóa, còn gọi là chữ ký kịch bản (scriptSig). Nếu kịch bản hoàn chỉnh (kịch bản mở khóa + kịch bản khóa + OP-Codes) hợp lệ, đầu ra tương ứng sẽ “được mở khóa” và có thể chi tiêu.
Do đó, lập trình kịch bản Bitcoin là lập trình cho tiền bạc, khiến một khoản tiền cụ thể có thể phản hồi với dữ liệu đầu vào cụ thể. Bằng cách thiết kế khóa công khai kịch bản, mã vận hành OP-Codes và quy trình tương tác giữa người dùng, chúng ta có thể cung cấp đảm bảo mật mã học cho các chuyển đổi trạng thái then chốt của hợp đồng Bitcoin, đảm bảo thực hiện đúng hợp đồng.
Dưới đây là sơ đồ đơn giản về một kịch bản P2PKH (thanh toán tới hàm băm khóa công khai) chuẩn của Bitcoin
Giả sử tôi muốn trả 1 BTC cho Tiểu Minh, cần sử dụng UTXO có thể sử dụng trong ví của mình để tạo ra một UTXO trị giá 100 triệu satoshi, và đặt khóa công khai của Tiểu Minh (cùng với toán tử kiểm tra chữ ký) vào kịch bản khóa của UTXO đó, như vậy chỉ có chữ ký tương ứng với khóa công khai của Tiểu Minh từ khóa riêng mới có thể mở khóa khoản tiền này.
Tóm lại, Script (kịch bản) là một ngôn ngữ lập trình rất cơ bản. Nó gồm hai loại đối tượng: dữ liệu (Data) như khóa công khai và chữ ký + mã vận hành —— các hàm đơn giản xử lý dữ liệu (danh sách mã vận hành như sau: liên kết liên quan).
Kho vũ khí lập trình Bitcoin
Ở phần trên đã đề cập đến các loại giao dịch mà Satoshi ban đầu mong muốn mạng Bitcoin hỗ trợ như giao dịch ủy thác, hợp đồng bảo lãnh, trọng tài bên thứ ba, đa chữ ký, v.v., vậy những công cụ nào để thực hiện những điều này, và chúng được dùng ra sao trong BTCFI?
Đa chữ ký (MULTISIG)
- Dạng kịch bản khóa là M <PUB-1> <PUB-2> ... <PUB-N> N OP_CHECKMULTISIG, nghĩa là nó ghi lại n khóa công khai, cần cung cấp chữ ký từ m khóa công khai trong số đó để mở khóa UTXO này.
- Ví dụ, chỉ cần chữ ký của hai người trong ba người Alice, Bob và Chloe (hay ba khóa công khai), có thể chi tiêu kịch bản này, mã Script của nó là: 2 <Alice> <Bob> <Chloe> 3 OP_CHECKMULTISIG, OP_CHECKMULTISIG là mã vận hành xác minh chữ ký có khớp với khóa công khai cung cấp hay không.
- Các ứng dụng bao gồm:
- Quản lý tài chính cá nhân và doanh nghiệp: Sau khi thiết lập ví đa chữ ký 2-trên-3, chỉ cần hai người dùng là có thể sử dụng tiền, đồng thời ngăn chặn nhà sản xuất ví hành động xấu, phải có ít nhất m nhà sản xuất thông đồng mới rút được tiền.
- Trọng tài giao dịch:
- Giả định Alice và Bob muốn thực hiện một giao dịch, ví dụ như mua NFT ordinals, nhưng không thể trao tiền - giao hàng cùng lúc, họ thỏa thuận khóa tiền vào một đầu ra đa chữ ký, khi Bob nhận được NFT ordinals từ Alice thì mới thanh toán toàn bộ tiền cho Alice. Để tránh trường hợp nhận hàng nhưng không trả tiền, có thể mời bên thứ ba làm trọng tài, tạo thành đầu ra đa chữ ký 2-trên-3; khi xảy ra tranh chấp, có thể yêu cầu bên thứ ba phán xử. Nếu bên trọng tài cho rằng Alice đã giao hàng, có thể phối hợp với Alice để chuyển tiền đi.
- Chỉ cần bên trọng tài công bố khóa công khai của mình (ví dụ như một oracle), hai bên giao dịch có thể sử dụng khóa công khai đó trong kịch bản đa chữ ký 2-trên-3, như vậy đã đưa trọng tài vào, vì trên chuỗi ghi lại là hàm băm của kịch bản, nên có thể thực hiện mà trọng tài không biết. Tuy nhiên vấn đề ở đây là oracle bên thứ ba có thể quyết định kết quả cụ thể của hợp đồng, gây ra rủi ro nhất định. DLC (hợp đồng nhật ký thận trọng) được đề cập ở phần sau đã tối ưu điểm này, giúp ứng dụng thực sự vào cho vay Bitcoin và các ứng dụng BTCFI khác.
Khóa thời gian
Khóa thời gian dùng để kiểm soát hiệu lực giao dịch và thời điểm một đầu ra có thể được chi tiêu, đây là vũ khí lập trình kịch bản Bitcoin thường dùng trong các tình huống chất phát lại, đặt cược, cho vay thế chấp BTCFI. Nhà phát triển cần chọn giữa khóa thời gian tương đối (nSequence) hoặc tuyệt đối (nLocktime):
- Khóa thời gian tuyệt đối (nLocktime): Giao dịch chỉ được coi là hợp lệ và có thể đóng gói vào khối sau một thời điểm nhất định. Mã vận hành OP_CLTV ở cấp độ kịch bản xác minh rằng UTXO này chỉ có thể mở khóa sau một thời điểm nhất định, ví dụ như khoản tiền này chỉ có thể chi tiêu sau chiều cao khối 400000.
- Khóa thời gian tương đối (nSequence) nghĩa là giao dịch chỉ hợp lệ và có thể mở khóa UTXO này sau một khoảng thời gian kể từ khi giao dịch tạo ra UTXO đầu vào (giao dịch tiền nhiệm) được xác nhận vào khối. Mã vận hành OP_CSV ở cấp độ kịch bản, ví dụ như “khoản tiền này chỉ có thể chi tiêu sau 3 khối kể từ khi được xác nhận”.
Khóa băm (xác minh hình ảnh gốc băm)
Ngoài ra còn có hợp đồng khóa băm thời gian (HTLC) kết hợp khóa băm (xác minh hình ảnh gốc băm), thường dùng trong việc đặt cược và tái đặt cược Bitcoin:
- Dạng kịch bản khóa của khóa băm là OP_HASH160 <hash> OP_EQUAL, xác minh xem dữ liệu trong kịch bản mở khóa có phải là hình ảnh gốc của giá trị băm trong kịch bản khóa hay không.
- Hợp đồng khóa băm thời gian (HTLC): Bên nhận tiền nếu không cung cấp hình ảnh gốc của giá trị băm trong thời gian nhất định, khoản tiền này có thể được bên gửi lấy lại.
Điều khiển luồng (các điều kiện mở khóa song song)
Mã vận hành OP_IF có thể sắp xếp nhiều đường dẫn mở khóa trong kịch bản khóa, chỉ cần một trong các điều kiện được đáp ứng, UTXO này có thể được mở khóa. HTLC được đề cập ở trên cũng sử dụng mã vận hành điều khiển luồng này.
Sau nâng cấp taproot, tính năng MAST (Cây cú pháp trừu tượng Merklized) cho phép chúng ta đặt các đường dẫn mở khóa khác nhau vào các lá cây Merkle khác nhau. Giao dịch đặt cược BTC của Babylon cũng sử dụng MAST, nâng cao hiệu quả và tính riêng tư của giao dịch, chúng tôi sẽ mô tả ở phần sau.
Chữ ký kèm thông tin SIGHASH
Giao dịch Bitcoin cho phép sử dụng nhãn SIGHASH khi ký, các nhãn này bổ sung điều kiện cho tính hợp lệ của chữ ký, cho phép sửa đổi một phần giao dịch mà không làm mất hiệu lực chữ ký, biểu thị kỳ vọng hoặc ủy quyền của người ký về mục đích sử dụng chữ ký đó. Ví dụ:
- SIGHASH_SINGLE | ANYONECANPAY ký đầu vào và đầu ra có cùng chỉ số, các đầu vào và đầu ra khác có thể thay đổi mà chữ ký không mất hiệu lực. Andy có thể ký đầu vào trị giá 1 BTC và đầu ra 100 token Runes, bất kỳ ai muốn đổi 100 token Runes lấy 1 BTC đều có thể hoàn thiện giao dịch và đưa lên chuỗi.
Các ví dụ khác như chữ ký Schnorr sau nâng cấp taproot, có thể dùng cho hợp đồng nhật ký thận trọng DLC.
Hạn chế của khả năng lập trình Bitcoin
Mô hình cơ bản của lập trình Bitcoin là kịch bản khóa UTXO nêu rõ điều kiện xác minh, kịch bản mở khóa cung cấp dữ liệu, mã vận hành trong kịch bản khóa chỉ định chương trình xác minh dữ liệu (xác minh chữ ký, xác minh hình ảnh gốc băm, v.v.), qua chương trình xác minh, tiền có thể được chi tiêu. Điểm hạn chế cốt lõi là:
- Các chương trình xác minh có sẵn chỉ có vài loại hạn chế: Triển khai chứng minh không kiến thức hoặc các chương trình xác minh khác cần phải fork. Do đó, giải pháp mở rộng BTCFI của Unisat là Fractal, mặc dù giữ nguyên 100% so với Bitcoin, nhưng để triển khai các mã vận hành gây tranh cãi như OP_CAT, OPCode xác minh ZK gốc, đã phải tách rời một phần về tính thanh khoản và an toàn so với mạng chính Bitcoin.
- Kịch bản Bitcoin không có khả năng tính toán: Chỉ cần mở khóa được tiền, có thể dùng toàn bộ tiền theo bất kỳ đường nào, cách chi tiêu tiền không thể bị giới hạn sau khi mở khóa, điều này có nghĩa là trong các dự án cho vay BTCFI rất khó áp dụng lãi suất thả nổi, chỉ có thể dùng lãi suất cố định. Để giải quyết vấn đề này, cộng đồng Bitcoin đang thảo luận về việc triển khai “điều khoản ràng buộc” (covenants), có thể mở rộng nhiều tình huống ứng dụng BTCFI hơn thông qua việc hạn chế việc chi tiêu giao dịch thêm. BIP-420, OP_CAT, OP_CTV, APO, OP_VAULT mà Taproot Wizard nói đến đều liên quan đến điều này.
- Điều kiện mở khóa UTXO hoàn toàn độc lập: Một UTXO không thể quyết định việc mở khóa của mình dựa trên việc UTXO khác có tồn tại hay điều kiện khóa của nó, vấn đề này thường xảy ra trong cho vay thế chấp và đặt cược BTCFI, phần sau sẽ nói rõ về giao dịch Bitcoin ký một phần (PSBT) dùng để giải quyết vấn đề này.
Điều chỉnh và tiến hóa của hợp đồng Bitcoin
So với hợp đồng Ethereum dựa trên tính toán, hợp đồng Bitcoin dựa trên xác minh, loại hợp đồng vô trạng thái này gây ra nhiều khó khăn trong việc phát triển sản phẩm BTCFI. Trong hơn một thập kỷ phát triển hợp đồng Bitcoin, các thuật toán mật mã học và việc sử dụng khéo léo chữ ký đã nâng cao đáng kể tính riêng tư, hiệu quả và mức độ phi tập trung, khiến các ứng dụng sản phẩm hóa BTCFI trở nên khả thi.
Hợp đồng nhật ký thận trọng (DLC): Giải quyết vấn đề thanh toán phi tập trung trong các tình huống BTCFI
Khi các giao thức cho vay, quyền chọn, tương lai cần thực hiện thanh lý vị thế người dùng dựa trên giá oracle, không thể tránh khỏi việc phải giữ quyền thao tác tài sản người dùng, điều này vô hình trung làm tăng chi phí tin tưởng rằng giao thức sẽ không hành động xấu.
Hợp đồng nhật ký thận trọng (DLC) được giới thiệu để giải quyết vấn đề này, sử dụng một kỹ thuật mật mã gọi là chữ ký bộ điều hợp (adaptor signature), cho phép kịch bản Bitcoin lập trình các hợp đồng tài chính phụ thuộc vào sự kiện bên ngoài và đảm bảo tối đa tính riêng tư.
Nó được đề xuất bởi Tadge Dryja (nhà nghiên cứu khoa học) và Gert-Jaap Glasbergen (nhà phát triển phần mềm) thuộc Sáng kiến Tiền tệ Kỹ thuật số (Digital Currency Initiative) của Viện Công nghệ Massachusetts (MIT) vào năm 2017, và được trình diễn công khai vào ngày 19 tháng 3 năm 2018.
Chữ ký bộ điều hợp cho phép một chữ ký chỉ trở thành chữ ký hợp lệ sau khi thêm một khóa riêng. Chữ ký Schnorr được giới thiệu trong nâng cấp taproot là một ví dụ về chữ ký bộ điều hợp.
Nói một cách đơn giản, dạng chuẩn của chữ ký Schnorr là (R, s), cho (R, s'), chỉ cần biết x (giá trị bí mật), có thể đặt s = s' + x, tạo ra (R, s).
Ở đây dùng một ví dụ đơn giản để giải thích cách ứng dụng:
- Alice và Bob đặt cược vào hai kết quả ngược nhau của một trận đấu thể thao (giả sử không hòa), mỗi người đặt cược 1 $BTC, người đoán đúng sẽ giành toàn bộ 2 $BTC. Họ sẽ khóa tiền cược vào một ví đa chữ ký, cần chữ ký đa phương mới giải phóng tiền.
- Chọn một oracle, sẽ công bố kết quả trận đấu (thường nguồn thông tin này nằm ngoài chuỗi, như sàn giao dịch hoặc website trận đấu).
- Oracle không cần biết bất kỳ chi tiết nào về cược, thậm chí không cần biết ai tham gia DLC. Nhiệm vụ của nó chỉ giới hạn ở việc cung cấp kết quả, khi sự kiện xảy ra, oracle sẽ phát hành một bằng chứng mã hóa gọi là cam kết, cho biết đã xác định kết quả sự kiện.
- Để nhận tiền bị khóa trong ví đa chữ ký, người thắng cuộc Alice sử dụng giá trị bí mật do oracle cung cấp để tạo khóa riêng hợp lệ, cho phép ký giao dịch chi tiêu tiền trong ví.
- Giao dịch này được thêm vào blockchain Bitcoin để thanh toán, lúc này vì chữ ký là chữ ký thông thường, không thể nhìn ra đây là DLC. Điều này hoàn toàn khác với các mô hình đa chữ ký phổ biến khác —— nội dung hợp đồng hoàn toàn công khai, oracle tham gia quyết định ——.
Cơ chế thanh lý giao thức cho vay
Giả định Alice thế chấp tài sản $ORDI để vay 0,15 $BTC, chỉ khi oracle báo giá $ORDI dưới 225.000 sat/ordi, vị thế cho vay này sẽ chuyển sang trạng thái chờ thanh lý. DLC cho phép người thanh lý có thể thanh lý vị thế này một cách không cần cấp phép khi ở trạng thái chờ thanh lý, đồng thời đảm bảo họ không thể thao tác tài sản thế chấp của người dùng khi giá chưa đạt mức thanh lý. Trong tình huống trên, Alice giống như đã đặt cược với giao thức cho vay về giá $ORDI:
- Nếu giá dưới 225.000 sat/ordi, giao thức sẽ nhận được toàn bộ tài sản thế chấp của Alice và chịu trách nhiệm nợ BTC tương ứng.
- Nếu giá lớn hơn hoặc bằng 225.000 sat/ordi, không có gì xảy ra, mối quan hệ sở hữu tài sản giữ nguyên.
Vì vậy, chúng ta cần oracle cam kết rằng khi giá dưới 225.000 sat/ordi, sẽ phát hành chữ ký kết quả s_c_1 bằng nonce R_c:
- Alice và giao thức chỉ cần tạo một giao dịch cam kết cho kết quả này, tạo chữ ký bộ điều hợp (R, s'), thay vì chữ ký (R, s), có nghĩa là chữ ký trao đổi cho nhau đều không thể trực tiếp dùng để mở khóa hợp đồng, mà phải tiết lộ một giá trị bí mật mới được. Giá trị bí mật này chính là hình ảnh gốc của s_c_1.G, tức chữ ký của oracle. Vì nonce chữ ký oracle đã xác định, nên s_c_1.G có thể được xây dựng.
- Khi giá dưới 225.000 sat/ordi, oracle sẽ phát hành chữ ký (R_c, s_c_1), giao thức có thể hoàn thiện chữ ký bộ điều hợp của đối phương, cộng thêm chữ ký của mình, biến giao dịch trên thành giao dịch hợp lệ, phát sóng lên mạng, kích hoạt hiệu ứng thanh toán.
- Ngược lại, nếu giá không dưới 225.000 sat/ordi, oracle sẽ không phát hành s_c_1, giao dịch cam kết này không thể trở thành giao dịch hợp lệ.
Về bản chất, DLC cho phép người dùng và giao thức tham gia thỏa thuận trên blockchain Bitcoin, cả hai bên khóa tiền vào địa chỉ đa chữ ký để xây dựng kịch bản DLC. Số tiền này chỉ có thể được sử dụng và phân phối lại theo một quy tắc nhất định khi oracle phát hành thông tin cụ thể tại thời điểm chỉ định.
Như vậy, giao thức cho vay có thể tận dụng DLC để thực hiện một cơ chế thanh lý không cần người dùng tin tưởng bất kỳ thực thể nào, có sự tham gia của oracle giá bên ngoài.
Các giao thức cho vay như liquidium và shell finance mà chúng tôi sẽ đề cập sau này đều sử dụng công nghệ này để thực hiện thanh lý phi tập trung không cần cấp phép.
Vai trò của oracle
Oracle trong DLC dùng để cung cấp dịch vụ giá định kỳ, đồng thời tham gia vào quá trình tạo và công bố giá trị bí mật (secret) trong cơ chế DLC.
Hiện tại chưa có sản phẩm oracle DLC chuẩn hóa, chủ yếu các giao thức cho vay tự phát triển module DLC, các oracle chuẩn hóa như chainlink đảm nhận chức năng cung cấp dữ liệu bên ngoài chuỗi, nhưng khi các giao thức cho vay dựa trên DLC ra mắt và phát triển liên tục, cũng có nhiều dự án oracle hiện tại đang tích cực khám phá cách phát triển oracle DLC.
Giao dịch Bitcoin ký một phần (PSBT): Đạt được việc không cần lưu ký tiền trong giao dịch nhiều bên của giao thức BTCFI
PSBT đến từ tiêu chuẩn Bitcoin BIP-174, tiêu chuẩn này cho phép nhiều bên ký cùng một giao dịch song song, sau đó hợp nhất PSBT tương ứng để tạo thành giao dịch ký đầy đủ. Các bên ở đây có thể là giao thức và người dùng, người mua và người bán, người đặt cược và giao thức đặt cược, v.v., do đó bất kỳ ứng dụng BTCFI nào liên quan đến trao đổi tiền giữa nhiều bên đều có thể tận dụng PSBT, hầu hết các dự án BTCFI hiện tại đều sử dụng công nghệ này.
Alice, Bob và Charlie có một khoản tiền trong ví đa chữ ký 2/3, họ muốn rút tiền này và chia đều làm 3 phần, cả ba người phải ký cùng một giao dịch để chi tiêu UTXO này. Giả sử họ không tin tưởng lẫn nhau, họ cần làm gì để đảm bảo an toàn tiền?
- Đầu tiên, Alice với tư cách người khởi tạo tạo một giao dịch PSBT, UTXO đa chữ ký làm đầu vào, đầu ra là địa chỉ ví của ba người. Vì PSBT đảm bảo rằng không giao dịch nào khác ngoài giao dịch này có thể sử dụng chữ ký của bất kỳ người nào, nên Alice có thể ký xong gửi cho Bob.
- Tương tự, Bob kiểm tra PSBT, nếu thấy ổn thì ký; ký xong gửi cho Charlie để ký và phát hành giao dịch. Charlie cũng thực hiện thao tác tương tự.
Do đó, “ký một phần” Partially signed nghĩa là mỗi người chỉ cần kiểm tra phần giao dịch liên quan đến mình, miễn là phần liên quan đến mình ổn thì có thể đảm bảo giao dịch lên chuỗi sẽ không có vấn đề.
Vào ngày 7 tháng 3 năm 2023, cuộc đấu giá NFT Ordinals của Yuga Labs đã sử dụng mô hình đấu giá lưu ký tập trung cực kỳ. Trong quá trình đấu giá, tất cả tiền đấu giá được yêu cầu chuyển vào địa chỉ lưu ký của Yuga, điều này đe dọa nghiêm trọng đến an toàn tiền.
Người dùng hệ sinh thái Ethereum chỉ ra rằng sự kiện đấu giá của Yuga minh họa rõ tầm quan trọng của hợp đồng thông minh ETH, nhưng các nhà phát triển Ordinals cũng phản hồi: Giao dịch báo giá không cần tin tưởng dựa trên PSBT rất tiện dụng, có thể thực hiện giao dịch tiền không cần lưu ký giữa người mua NFT và Yuga Labs.
Giả sử hiện có một cặp giao dịch NFT Bitcoin, và khóa công khai của người bán NFT là thông tin cả hai bên đều biết. Khi khởi tạo một giao dịch NFT, người mua trước tiên viết đầu vào UTXO của mình và một đầu ra nhận NFT vào giao dịch. Người mua ký sau khi xây dựng giao dịch, chuyển thành PSBT gửi cho người bán, người bán nhận được tin nhắn
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
@Ventures_HTX
