Covenants: Khả năng lập trình của Bitcoin
Tuyển chọn TechFlowTuyển chọn TechFlow
Covenants: Khả năng lập trình của Bitcoin
Cuối cùng thì "điều khoản giới hạn" của Bitcoin là gì?
Chuyên sâu báo cáo Web3Tác giả: Jeffrey HU, Trưởng nhóm Nghiên cứu Đầu tư tại HashKey Capital; Harper LI, Quản lý Đầu tư tại HashKey Capital
Gần đây, cộng đồng Bitcoin đã dậy sóng với cuộc tranh luận về việc kích hoạt lại các opcode như OP_CAT. Taproot Wizard cũng thu hút sự chú ý lớn bằng cách ra mắt bộ sưu tập NFT Quantum Cats và tuyên bố đã nhận được số hiệu BIP-420. Những người ủng hộ cho rằng việc kích hoạt OP_CAT sẽ mở đường cho "điều khoản ràng buộc" (covenants), từ đó hiện thực hóa hợp đồng thông minh hoặc tính lập trình trên Bitcoin.
Nếu bạn để ý cụm từ “điều khoản ràng buộc” và tìm hiểu sơ qua, bạn sẽ nhận ra đây là một chủ đề sâu rộng. Các nhà phát triển đã thảo luận nhiều năm trời, bên cạnh OP_CAT còn có các giải pháp kỹ thuật khác như OP_CTV, APO, OP_VAULT nhằm hiện thực hóa điều khoản ràng buộc.
Vậy rốt cuộc “điều khoản ràng buộc” của Bitcoin là gì? Vì sao nó lại thu hút sự quan tâm bền bỉ của đông đảo lập trình viên suốt nhiều năm? Nó có thể mở rộng những khả năng lập trình nào cho Bitcoin? Cơ chế thiết kế đằng sau ra sao? Bài viết này sẽ cung cấp cái nhìn tổng quan và phần nào làm rõ các vấn đề trên.
Điều khoản ràng buộc là gì?
Covenants – dịch sang tiếng Việt là “điều khoản ràng buộc”, đôi khi gọi là “giao ước”, là một cơ chế cho phép đặt điều kiện đối với các giao dịch Bitcoin trong tương lai.
Hiện tại, kịch bản Bitcoin cũng chứa các điều kiện giới hạn, ví dụ như yêu cầu chữ ký hợp lệ hoặc kịch bản phù hợp khi chi tiêu. Tuy nhiên, chỉ cần người dùng mở khóa được, họ có thể chuyển UTXO đến bất kỳ đâu theo ý muốn.
Điều khoản ràng buộc bổ sung thêm các giới hạn này – không chỉ dừng ở việc kiểm soát cách mở khóa, mà còn kiểm soát cả cách UTXO được chi tiêu về sau, tức là đạt được hiệu ứng “chuyên款 chuyên dụng”; hoặc áp đặt điều kiện lên các đầu vào khác trong cùng một giao dịch.
Chính xác hơn, hiện tại kịch bản Bitcoin cũng có một số dạng điều khoản ràng buộc nhất định. Ví dụ, khóa thời gian dựa trên opcode sử dụng nội soi (introspection) trường nLocktime hoặc nSequence của giao dịch để giới hạn thời điểm chi tiêu. Nhưng phạm vi này gần như chỉ giới hạn ở yếu tố thời gian.
Vậy tại sao các nhà phát triển và nghiên cứu lại muốn thiết kế các kiểm tra ràng buộc này? Bởi vì điều khoản ràng buộc không đơn thuần là giới hạn, mà còn là thiết lập quy tắc thực thi giao dịch. Điều này buộc người dùng phải tuân theo các quy tắc đã định trước, từ đó hoàn tất các quy trình nghiệp vụ như mong đợi.
Do đó, một cách nghịch lý, chính những giới hạn này lại giúp mở khóa nhiều trường hợp sử dụng hơn.
Ứng dụng thực tiễn
Đảm bảo hình phạt trong Staking
Một ví dụ trực quan nhất của điều khoản ràng buộc là giao dịch "slash" trong quy trình Bitcoin staking do Babylon đề xuất.
Trong quá trình staking BTC của Babylon, người dùng gửi tài sản BTC của mình trên chuỗi chính vào một kịch bản đặc biệt, với hai điều kiện chi tiêu:
-
Kết thúc tốt đẹp (Happy ending): Sau một khoảng thời gian nhất định, người dùng có thể tự mở khóa bằng chữ ký của mình – tức là hoàn tất quá trình unstake
-
Kết thúc xấu (Bad ending): Nếu người dùng có hành vi ác ý như ký kép (double-signing) trên một chuỗi PoS thuê bảo mật từ Babylon, thì thông qua EOTS (extractable one-time signatures - chữ ký một lần có thể trích xuất), phần tài sản này có thể bị mở khóa và một vai trò thực thi trong mạng sẽ buộc chuyển một phần tài sản vào địa chỉ đốt (burn address)
Nguồn: Bitcoin Staking: Unlocking 21M Bitcoins to Secure the Proof-of-Stake Economy
Lưu ý cụm “buộc chuyển” ở đây – nghĩa là ngay cả khi có thể mở khóa UTXO này, tài sản cũng không thể tùy ý gửi đi nơi khác, mà chỉ có thể bị đốt. Điều này đảm bảo người dùng ác ý không thể抢先 dùng chữ ký đã biết để chuyển tài sản về ví mình trước, nhằm trốn tránh hình phạt.
Tính năng này, nếu được hỗ trợ bởi OP_CTV hoặc các điều khoản ràng buộc khác, có thể được hiện thực bằng cách thêm opcode OP_CTV vào nhánh “kết thúc xấu” của kịch bản staking.
Trước khi OP_CTV được kích hoạt, Babylon buộc phải dùng biện pháp thay thế, kết hợp giữa người dùng và hội đồng để mô phỏng hiệu ứng thực thi điều khoản ràng buộc.
Kiểm soát tắc nghẽn mạng
Thông thường, tắc nghẽn xảy ra khi mức phí giao dịch trên mạng Bitcoin rất cao và hàng đợi giao dịch chờ xử lý trong mempool khá dài. Do đó, nếu người dùng muốn xác nhận nhanh giao dịch, họ phải trả mức phí cao hơn.
Khi ấy, nếu một người dùng phải gửi nhiều giao dịch đến nhiều người nhận, họ sẽ buộc phải tăng phí, dẫn đến chi phí cao. Đồng thời, điều này cũng góp phần đẩy cao mức phí toàn mạng.
Nếu có điều khoản ràng buộc, một giải pháp là người gửi có thể cam kết trước một giao dịch gửi hàng loạt. Cam kết này khiến mọi người nhận tin tưởng rằng giao dịch cuối cùng sẽ được thực hiện, và họ có thể đợi đến khi mức phí thấp rồi mới gửi giao dịch cụ thể.
Như hình dưới đây, khi nhu cầu về không gian khối cao, việc thực hiện giao dịch trở nên rất tốn kém. Nhờ OP_CHECKTEMPLATEVERIFY, các nhà xử lý thanh toán hàng loạt có thể gom tất cả khoản thanh toán của họ vào một giao dịch O(1) duy nhất để xác nhận. Một thời gian sau, khi nhu cầu về không gian khối giảm, các khoản thanh toán có thể được rút ra từ UTXO đó.
Nguồn: https://utxos.org/uses/scaling/
Tình huống này là một ví dụ điển hình cho ứng dụng của OP_CTV – một trong những điều khoản ràng buộc nổi bật. Có thể tìm thêm nhiều ví dụ khác tại https://utxos.org/uses/, bao gồm Soft Fork Bets, Quyền chọn phi tập trung, Drivechains, Kênh gộp, Kênh không tương tác, Hợp tác khai thác không cần tin cậy, Vaults, Hợp đồng khóa thời gian băm an toàn hơn (HTLC).
Kho lưu trữ (Vault)
Kho lưu trữ (vault) là một chủ đề ứng dụng được thảo luận rộng rãi trong hệ sinh thái Bitcoin, đặc biệt trong lĩnh vực điều khoản ràng buộc. Vì trong thực tế luôn tồn tại sự đánh đổi giữa việc bảo quản tiền và nhu cầu sử dụng tiền, người ta mong muốn có một loại ứng dụng két sắt: vừa đảm bảo an toàn tài sản, thậm chí ngay cả khi tài khoản bị xâm nhập (rò rỉ khóa riêng), vẫn có thể hạn chế việc sử dụng tiền.
Dựa trên các công nghệ hiện thực điều khoản ràng buộc, các ứng dụng kho lưu trữ có thể được xây dựng tương đối dễ dàng.
Lấy thiết kế OP_VAULT làm ví dụ: Khi chi tiêu tài sản trong kho, trước tiên cần gửi một giao dịch lên chuỗi. Giao dịch này bày tỏ ý định chi tiêu, gọi là “trigger”, và đặt ra các điều kiện:
-
Nếu mọi chuyện bình thường, giao dịch thứ hai sẽ là giao dịch rút tiền cuối cùng. Sau N khối, tiền có thể được chi tiêu tùy ý
-
Nếu phát hiện giao dịch bị đánh cắp (hoặc bị ép buộc do “tấn công bằng chiếc cờ lê”), trước khi giao dịch rút tiền được gửi đi, có thể lập tức chuyển tiền tới một địa chỉ an toàn khác (nơi người dùng bảo quản an toàn hơn)
Quy trình OP_VAULT, nguồn: BIP-345
Cần lưu ý rằng, ngay cả khi không có điều khoản ràng buộc, vẫn có thể xây dựng một ứng dụng kho lưu trữ. Một phương án khả thi là chuẩn bị sẵn chữ ký cho các giao dịch chi tiêu tương lai, sau đó hủy bỏ khóa riêng đó. Tuy nhiên, cách này vẫn có nhiều hạn chế, ví dụ như phải đảm bảo khóa riêng đã bị hủy (tương tự quá trình trusted setup trong chứng minh không kiến thức), số tiền và phí giao dịch phải được xác định trước (do phải ký trước) nên thiếu linh hoạt.
So sánh quy trình OP_VAULT và kho lưu trữ dựa trên chữ ký trước, nguồn: BIP-345
Kênh trạng thái mạnh mẽ và linh hoạt hơn
Thông thường, các kênh trạng thái như Lightning Network được coi là có độ an toàn gần tương đương với chuỗi chính (miễn là các nút có thể quan sát trạng thái mới nhất và có thể đăng trạng thái đó lên chuỗi). Tuy nhiên, với điều khoản ràng buộc, các ý tưởng thiết kế kênh trạng thái mới có thể trở nên mạnh mẽ hoặc linh hoạt hơn so với Lightning Network. Trong số này có những cái tên nổi bật như Eltoo và Ark.
Eltoo (còn gọi là LN-Symmetry) là một ví dụ điển hình. Giải pháp kỹ thuật này chơi chữ từ “L2”, đề xuất một lớp thực thi cho Lightning Network, cho phép bất kỳ trạng thái kênh mới nào thay thế trạng thái trước đó mà không cần cơ chế trừng phạt, nhờ đó cũng tránh được việc các nút Lightning phải lưu trữ nhiều trạng thái cũ để phòng đối thủ gian lận. Để đạt được điều này, Eltoo đề xuất phương thức chữ ký SIGHASH_NOINPUT, còn gọi là APO (BIP-118).
Ark hướng đến việc giảm độ khó liên quan đến thanh khoản đầu vào và quản lý kênh của Lightning Network. Đây là một giao thức dạng joinpool, nơi nhiều người dùng có thể chấp nhận một nhà cung cấp dịch vụ làm đối tác giao dịch trong một khoảng thời gian, thực hiện giao dịch trên vUTXO (UTXO ảo) ngoài chuỗi, nhưng chia sẻ một UTXO trên chuỗi để giảm chi phí. Tương tự kho lưu trữ, Ark có thể được hiện thực trên mạng Bitcoin hiện tại; tuy nhiên, khi có điều khoản ràng buộc, Ark có thể giảm lượng tương tác cần thiết nhờ mẫu giao dịch, và đạt được khả năng rút lui một chiều (unilateral exit) phi tin cậy hơn.
Tổng quan về công nghệ điều khoản ràng buộc
Từ các ứng dụng trên có thể thấy, điều khoản ràng buộc giống như một hiệu ứng hơn là một công nghệ cụ thể, do đó có nhiều cách hiện thực khác nhau. Nếu phân loại, có thể chia thành:
-
Loại: Chung, chuyên dụng
-
Phương pháp hiện thực: Dựa trên Opcode, dựa trên chữ ký
-
Đệ quy: Có đệ quy, không đệ quy
Trong đó, đệ quy nghĩa là: một số hiện thực điều khoản ràng buộc có thể giới hạn đầu ra tiếp theo thông qua việc giới hạn đầu ra ngay sau đó, từ đó áp đặt giới hạn vượt qua một giao dịch, đạt đến độ sâu giao dịch cao hơn.
Một số thiết kế điều khoản ràng buộc phổ biến bao gồm:
* Đệ quy: Nếu kết hợp với OP_CAT
Thiết kế điều khoản ràng buộc
Từ phần giới thiệu phía trên, ta thấy rằng kịch bản Bitcoin hiện tại chủ yếu giới hạn điều kiện mở khóa, chứ chưa giới hạn cách UTXO được chi tiêu tiếp theo. Để hiện thực điều khoản ràng buộc, ta cần suy nghĩ ngược lại: Tại sao kịch bản Bitcoin hiện tại không thể hiện thực điều khoản ràng buộc?
Nguyên nhân chính là do kịch bản Bitcoin hiện tại không thể đọc nội dung của chính giao dịch – hay còn gọi là “nội soi” (introspection).
Nếu chúng ta có thể nội soi giao dịch – kiểm tra bất kỳ nội dung nào của giao dịch (bao gồm cả đầu ra), thì điều khoản ràng buộc có thể được hiện thực.
Do đó, thiết kế điều khoản ràng buộc chủ yếu xoay quanh cách hiện thực chức năng nội soi.
Dựa trên Opcode vs Dựa trên chữ ký
Ý tưởng đơn giản và thô ráp nhất là thêm một hoặc nhiều opcode (một opcode với nhiều tham số, hoặc nhiều opcode với chức năng khác nhau) để trực tiếp đọc nội dung giao dịch. Đây là cách tiếp cận dựa trên opcode.
Một cách tiếp cận khác là không đọc và kiểm tra trực tiếp nội dung giao dịch trong kịch bản, mà tận dụng hàm băm của nội dung giao dịch – nếu đã ký lên hàm băm này, thì chỉ cần sửa đổi các opcode như OP_CHECKSIG trong kịch bản để kiểm tra chữ ký, từ đó gián tiếp hiện thực nội soi giao dịch và điều khoản ràng buộc. Cách tiếp cận này gọi là dựa trên chữ ký, bao gồm APO và OP_CSFS.
APO
SIGHASH_ANYPREVOUT (APO) là một phương thức ký giao dịch Bitcoin được đề xuất. Cách ký đơn giản nhất là cam kết toàn bộ đầu vào và đầu ra của giao dịch, nhưng Bitcoin còn có cách linh hoạt hơn – SIGHASH, cho phép cam kết chọn lọc một phần đầu vào hoặc đầu ra trong giao dịch.
Phạm vi ký của SIGHASH và các kết hợp hiện tại đối với đầu vào/ra giao dịch (Nguồn: Mastering Bitcoin, 2nd)
Như hình trên, ngoài ALL áp dụng cho toàn bộ dữ liệu, kiểu NONE chỉ cam kết đầu vào mà không cam kết đầu ra; SINGLE thì cam kết đầu ra có cùng chỉ số với đầu vào. Ngoài ra, SIGHASH còn có thể kết hợp, khi thêm mô tả ANYONECANPAY thì chỉ áp dụng cho một đầu vào.
Còn SIGHASH của APO thì chỉ cam kết đầu ra, không cam kết phần đầu vào. Điều này có nghĩa là, giao dịch đã ký bằng APO có thể sau đó gắn vào bất kỳ UTXO nào thỏa mãn điều kiện.
Sự linh hoạt này là nền tảng lý thuyết để APO hiện thực điều khoản ràng buộc:
-
Có thể tạo trước một hoặc nhiều giao dịch
-
Dùng thông tin các giao dịch này để xây dựng một khóa công khai chỉ có duy nhất một chữ ký
-
Như vậy, bất kỳ tài sản nào gửi đến địa chỉ khóa công khai này đều chỉ có thể được chi tiêu theo các giao dịch đã tạo trước
Lưu ý rằng, vì khóa công khai này không có khóa riêng tương ứng, nên có thể đảm bảo tài sản chỉ có thể được chi tiêu theo các giao dịch đã tạo trước. Như vậy, ta có thể quy định đích đến của tài sản trong các giao dịch đã tạo trước, từ đó hiện thực điều khoản ràng buộc.
Ta có thể hiểu rõ hơn bằng cách so sánh với hợp đồng thông minh Ethereum: Hợp đồng thông minh cho phép rút tiền từ địa chỉ hợp đồng chỉ khi đáp ứng điều kiện nhất định, chứ không thể tùy ý chi tiêu bằng chữ ký EOA. Về mặt này, Bitcoin có thể đạt được hiệu ứng tương tự chỉ bằng cải tiến cơ chế chữ ký.
Tuy nhiên, vấn đề trong quá trình trên là sự phụ thuộc vòng lặp, vì cần biết nội dung đầu vào để ký trước và tạo giao dịch.
Ý nghĩa của APO và SIGHASH_NOINPUT là giải quyết vấn đề phụ thuộc vòng lặp này – trong quá trình tính toán, chỉ cần biết (hoặc chỉ định) toàn bộ đầu ra của giao dịch.
OP_CTV
OP_CHECKTEMPLATEVERIFY (CTV), hay còn gọi là BIP-119, sử dụng cách tiếp cận cải tiến opcode. Nó lấy một giá trị băm cam kết (commitment hash) làm tham số, và yêu cầu mọi giao dịch thực thi opcode này phải chứa một tập hợp đầu ra khớp với cam kết đó. Nhờ CTV, người dùng Bitcoin có thể giới hạn cách họ sử dụng Bitcoin.
Đề xuất này ban đầu mang tên OP_CHECKOUTPUTSHASHVERIFY (COSHV), tập trung vào khả năng tạo giao dịch kiểm soát tắc nghẽn, do đó bị chỉ trích là không đủ linh hoạt, quá cụ thể cho trường hợp tắc nghẽn.
Trong ví dụ tắc nghẽn ở trên, người gửi Alice có thể tạo 10 đầu ra, băm chúng, dùng bản băm tạo một script tapleaf chứa COSHV. Alice cũng có thể dùng khóa công khai người nhận để tạo khóa nội bộ Taproot, cho phép họ cùng chi tiêu mà không tiết lộ đường dẫn script Taproot.
Sau đó, Alice gửi bản sao của 10 đầu ra cho mỗi người nhận để họ kiểm tra giao dịch thiết lập của Alice. Khi muốn chi tiêu khoản thanh toán này về sau, bất kỳ ai cũng có thể tạo một giao dịch chứa các đầu ra đã cam kết.
Toàn bộ quá trình, khi Alice tạo và gửi giao dịch thiết lập, cô có thể dùng các phương tiện truyền thông bất đồng bộ hiện có (email, đám mây) để gửi bản sao 10 đầu ra. Nghĩa là người nhận không cần trực tuyến, cũng không cần tương tác lẫn nhau.
Nguồn:
https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments
Tương tự APO, địa chỉ có thể được xây dựng dựa trên điều kiện chi tiêu, tạo “khóa” theo nhiều cách: thêm khóa khác, khóa thời gian, logic kết hợp.
Nguồn:
https://twitter.com/OwenKemeys/status/1741575353716326835
CTV mở rộng bằng cách kiểm tra xem giao dịch chi tiêu đã băm có khớp với định nghĩa hay không – tức là dùng dữ liệu giao dịch làm “chìa khóa” mở “khóa”.
Ta có thể mở rộng ví dụ 10 người nhận ở trên: Người nhận có thể tiếp tục thiết lập khóa địa chỉ của họ thành một giao dịch đã ký nhưng chưa phát tán, gửi cho nhóm người nhận tiếp theo, và cứ thế tạo thành cấu trúc cây như hình dưới. Alice chỉ cần 1 UTXO trên chuỗi để xây dựng một hệ thống thay đổi số dư tài khoản cho nhiều người dùng.
Nguồn:
https://twitter.com/OwenKemeys/status/1741575353716326835
Và nếu một trong các lá cây là kênh Lightning, là cold storage, hay là đường dẫn thanh toán khác thì sao? Khi ấy, cây này sẽ mở rộng từ cây chi tiêu một chiều đa tầng thành cây chi tiêu đa chiều đa tầng, hỗ trợ các trường hợp sử dụng phong phú và linh hoạt hơn.
Nguồn:
https://twitter.com/OwenKemeys/status/1744181234417140076
Kể từ khi ra đời, CTV đã trải qua đổi tên từ COSHV vào 2019, được gán số hiệu BIP-119 vào 2020, xuất hiện ngôn ngữ lập trình Sapio dành cho hợp đồng CTV, và nhận được nhiều thảo luận, cập nhật cũng như tranh luận về phương án kích hoạt vào các năm 2022-2023. Hiện tại, đây vẫn là một trong những đề xuất nâng cấp mềm (soft fork) được bàn luận sôi nổi nhất trong cộng đồng.
OP_CAT
Như đã giới thiệu ở phần mở đầu, OP_CAT cũng là một đề xuất nâng cấp đang rất được quan tâm, có chức năng nối (concatenate) hai phần tử trong ngăn xếp. Dù trông đơn giản, OP_CAT có thể linh hoạt hiện thực nhiều chức năng trong kịch bản.
Ví dụ trực tiếp nhất là các thao tác liên quan đến cây Merkle. Cây Merkle có thể hiểu là nối hai phần tử rồi băm. Hiện tại kịch bản Bitcoin đã có opcode OP_SHA256, nên nếu dùng OP_CAT để nối hai phần tử, ta có thể hiện thực chức năng xác minh cây Merkle trong kịch bản, từ đó có phần nào khả năng xác minh nhẹ (light client verification).
Một cơ sở hiện thực khác là tăng cường chữ ký Schnorr: có thể đặt điều kiện chi tiêu kịch bản là nối khóa công khai người dùng và nonce công khai; sau đó nếu người ký muốn ký giao dịch khác để chuyển tiền đi nơi khác, họ buộc phải dùng lại nonce, dẫn đến rò rỉ khóa riêng. Như vậy, OP_CAT giúp cam kết nonce, đảm bảo tính hiệu lực của giao dịch đã ký.
Các ứng dụng khác của OP_CAT bao gồm: Bistream, chữ ký cây, chữ ký Lamport chống lượng tử, kho lưu trữ, v.v.
OP_CAT không phải là chức năng mới; nó từng tồn tại trong phiên bản Bitcoin đầu tiên, nhưng bị vô hiệu hóa từ năm 2010 do lo ngại bị lợi dụng tấn công. Ví dụ, dùng lặp OP_DUP và OP_CAT có thể dễ dàng khiến nút đầy đủ bị tràn ngăn xếp khi xử lý kịch bản này, xem demo.
Tuy nhiên, việc kích hoạt lại OP_CAT hiện nay có gây ra vấn đề tràn ngăn xếp như trước không? Câu trả lời là không, vì đề xuất OP_CAT hiện tại chỉ áp dụng trong tapscript, và tapscript giới hạn mỗi phần tử ngăn xếp không quá 520 byte, do đó không xảy ra tràn ngăn xếp như xưa. Một số nhà phát triển cho rằng Satoshi cấm OP_CAT có thể quá nghiêm khắc. Tuy nhiên, do tính linh hoạt của OP_CAT, có thể vẫn tồn tại những trường hợp tiềm ẩn lỗi mà hiện chưa lường hết.
Do đó, cân nhắc giữa ứng dụng và rủi ro tiềm tàng, OP_CAT gần đây nhận được nhiều sự chú ý, đã trải qua đánh giá PR, và là một trong những đề xuất nâng cấp nóng nhất hiện nay.
Kết luận
“Kỷ luật mang lại tự do”. Từ phần giới thiệu trên, ta thấy điều khoản ràng buộc có thể trực tiếp giới hạn cách chi tiêu tiếp theo của giao dịch trong kịch bản Bitcoin, từ đó hiện thực các quy tắc giao dịch kiểu hợp đồng thông minh. So với các phương pháp ngoài chuỗi như BitVM, cách lập trình này có thể được xác minh gốc trên Bitcoin, đồng thời cải thiện các ứng dụng trên chuỗi (kiểm soát tắc nghẽn), ngoài chuỗi (kênh trạng thái) và các hướng ứng dụng mới (hình phạt staking, v.v.).
Nếu kết hợp điều khoản ràng buộc với một số nâng cấp底层, tiềm năng lập trình sẽ được giải phóng mạnh mẽ hơn. Ví dụ, đề xuất toán tử 64 bit gần đây đang trong quá trình review có thể kết hợp với OP_TLUV hoặc các điều khoản ràng buộc khác để lập trình dựa trên số satoshi trong đầu ra giao dịch.
Tuy nhiên, điều khoản ràng buộc cũng có thể dẫn đến lạm dụng hoặc lỗi ngoài dự kiến, do đó cộng đồng vẫn thận trọng. Hơn nữa, nâng cấp điều khoản ràng buộc đòi hỏi thay đổi quy tắc đồng thuận qua soft fork. Xét tình hình nâng cấp Taproot, có lẽ các nâng cấp liên quan đến điều khoản ràng buộc cũng cần thêm thời gian để hoàn tất.
Cảm ơn đặc biệt
Cảm ơn A Kiếm, Fisher, Ben đã đọc và góp ý cho bài viết này!
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
