Bitcoin hạn chế điều khoản: hướng đi mới để đạt được Khả năng lập trình
Cộng đồng Bitcoin gần đây đã có những cuộc thảo luận sôi nổi về việc tái kích hoạt các mã lệnh như OP_CAT. Taproot Wizard đã thu hút được nhiều sự chú ý bằng cách phát hành Quantum Cats NFT và tuyên bố nhận được mã BIP-420. Những người ủng hộ cho rằng việc kích hoạt OP_CAT có thể thực hiện "các điều khoản hạn chế", từ đó mang lại hợp đồng thông minh và khả năng lập trình cho Bitcoin.
"Hạn chế điều khoản"(covenants) khái niệm này đã gây ra nhiều cuộc thảo luận giữa các nhà phát triển trong nhiều năm. Ngoài OP_CAT, còn có nhiều giải pháp kỹ thuật khác để thực hiện các điều khoản hạn chế như OP_CTV, APO, OP_VAULT, v.v. Vậy, điều gì là "hạn chế điều khoản" của Bitcoin? Tại sao nó lại thu hút sự quan tâm rộng rãi và lâu dài như vậy? Nó có thể mang lại khả năng lập trình nào cho Bitcoin? Nguyên lý thiết kế đằng sau là gì? Bài viết này sẽ cung cấp cái nhìn tổng quan và thảo luận về những vấn đề này.
Điều khoản "giới hạn"
"Điều khoản hạn chế"(covenants) là một cơ chế có thể đặt điều kiện cho các giao dịch Bitcoin trong tương lai. Kịch bản Bitcoin hiện tại đã chứa một số điều kiện hạn chế, chẳng hạn như cần nhập chữ ký hợp lệ, cung cấp kịch bản đáp ứng yêu cầu, v.v. Nhưng chỉ cần người dùng có thể mở khóa, họ có thể chi tiêu UTXO đến bất kỳ đâu.
Và các điều khoản hạn chế đã thêm nhiều hạn chế hơn trên cơ sở này, chẳng hạn như hạn chế hướng chi tiêu tiếp theo của UTXO, nhằm đạt được hiệu ứng "dành riêng cho mục đích cụ thể"; hoặc hạn chế các điều kiện của các đầu vào khác trong một giao dịch.
Nói chính xác hơn, hiện tại kịch bản Bitcoin cũng có một số chức năng hạn chế, chẳng hạn như khóa thời gian dựa trên mã thao tác. Bằng cách kiểm tra các trường nLock hoặc nSequence của giao dịch, có thể thực hiện giới hạn thời gian trước khi chi tiêu giao dịch. Nhưng hiện tại chủ yếu giới hạn ở khía cạnh thời gian.
Mục đích của việc các nhà phát triển thiết kế các kiểm tra hạn chế này không chỉ là để hạn chế, mà còn để thiết lập các quy tắc thực hiện giao dịch. Người dùng chỉ có thể thực hiện giao dịch theo các quy tắc đã được thiết lập trước, từ đó hoàn thành quy trình kinh doanh đã định.
Do đó, các điều khoản hạn chế một cách ngược lại có thể mở khóa nhiều trường hợp ứng dụng hơn.
Ứng dụng
Đảm bảo hình phạt Staking
Một ví dụ trực quan về điều khoản hạn chế là giao dịch slash trong Bitcoin staking của Babylon.
Quá trình staking Bitcoin của Babylon là người dùng gửi tài sản BTC vào một script đặc biệt trên chuỗi chính, điều kiện chi tiêu bao gồm hai loại:
Kết thúc bình thường: Sau một khoảng thời gian nhất định, người dùng có thể mở khóa bằng chữ ký của mình, hoàn thành quá trình unstake.
Kết thúc hình phạt: Nếu người dùng có hành vi xấu như ký hai lần trên chuỗi PoS của Babylon, thì thông qua EOTS( có thể rút một chữ ký một lần ) để mở khóa tài sản, một phần tài sản sẽ bị buộc gửi đến địa chỉ đốt (slash) bởi các vai trò thực thi trong mạng.
"Gửi cưỡng chế" ở đây có nghĩa là ngay cả khi có thể mở khóa UTXO, tài sản đó cũng không thể được gửi đến nơi khác một cách tùy ý, chỉ có thể bị thiêu. Điều này đảm bảo rằng người dùng xấu không thể nhanh chóng sử dụng chữ ký đã biết để chuyển tài sản trở lại cho chính mình, thoát khỏi hình phạt.
Sau khi các điều khoản hạn chế như OP_CTV được thực hiện, có thể thêm mã thao tác liên quan vào nhánh "kết thúc hình phạt" của kịch bản staking để thực hiện hạn chế.
Và trước khi OP_CTV được kích hoạt, Babylon cần phải mô phỏng hiệu quả thi hành các điều khoản hạn chế thông qua phương pháp linh hoạt được thực hiện bởi người dùng và ủy ban.
Kiểm soát tắc nghẽn
Khi mạng bị tắc nghẽn, trong pool giao dịch tích lũy một lượng lớn giao dịch chờ được đóng gói, người dùng cần nâng cao phí giao dịch để có được xác nhận nhanh chóng. Nếu người dùng phải gửi nhiều giao dịch cho nhiều bên nhận, họ sẽ phải chịu chi phí cao hơn, đồng thời làm tăng thêm tỷ lệ phí giao dịch toàn mạng.
Có các điều khoản hạn chế, bên gửi có thể cam kết một giao dịch gửi hàng loạt trước. Cam kết này khiến tất cả các bên nhận tin tưởng rằng giao dịch cuối cùng sẽ được thực hiện, có thể đợi đến khi tỷ lệ phí giao dịch giảm rồi mới gửi giao dịch cụ thể.
Khi nhu cầu về không gian khối rất cao, giao dịch trở nên đắt đỏ. Sử dụng OP_CHECKTEMPLATEVERIFY, các nhà xử lý thanh toán số lượng lớn có thể gộp tất cả các khoản thanh toán vào một giao dịch O(1) duy nhất để xác nhận. Sau đó, khi nhu cầu về không gian khối giảm, có thể mở rộng các khoản thanh toán từ UTXO đó.
Đây là một trong những ứng dụng điển hình được đề xuất bởi điều khoản hạn chế OP_CTV.
Kho lưu trữ
Kho lưu trữ ( vault ) là một kịch bản được bàn luận rộng rãi trong ứng dụng Bitcoin, đặc biệt trong lĩnh vực các điều khoản hạn chế. Các hoạt động hàng ngày cần phải cân bằng giữa việc bảo quản vốn và nhu cầu sử dụng, mọi người mong muốn có một loại ứng dụng kho lưu trữ: vừa có thể đảm bảo an toàn cho vốn, ngay cả khi tài khoản bị hack (, việc rò rỉ ) khóa riêng cũng có thể hạn chế việc sử dụng vốn.
Dựa trên công nghệ điều khoản hạn chế, có thể dễ dàng xây dựng các ứng dụng kho lưu trữ.
Lấy kế hoạch OP_VAULT làm ví dụ: Khi chi tiêu quỹ kho lưu trữ, cần gửi một giao dịch lên chuỗi để thể hiện ý định ( "trigger" ), và đặt điều kiện:
Trường hợp bình thường: Giao dịch thứ hai là giao dịch rút tiền cuối cùng. Sau khi chờ N khối, có thể chi tiêu số tiền vào bất kỳ địa chỉ nào.
Tình huống bất thường: Nếu phát hiện là giao dịch bị đánh cắp ( hoặc bị ép buộc ), trước khi gửi giao dịch rút tiền trong N khối, có thể ngay lập tức chuyển tiền đến một địa chỉ an toàn hơn.
Cần lưu ý, ngay cả khi không có điều khoản hạn chế, vẫn có thể xây dựng ứng dụng lưu ký. Một phương pháp là chuẩn bị chữ ký cho việc chi tiêu trong tương lai bằng khóa riêng, sau đó phá hủy khóa riêng. Tuy nhiên, phương pháp này vẫn có những hạn chế, như cần đảm bảo khóa riêng đã bị phá hủy, số tiền và phí giao dịch cần được xác định trước, v.v., thiếu tính linh hoạt.
Trạng thái kênh mạnh mẽ và linh hoạt hơn
Kênh trạng thái ( bao gồm mạng lưới ánh sáng ) trong trường hợp các nút có thể quan sát trạng thái mới nhất, có thể công bố trạng thái mới nhất lên chuỗi, có thể coi là có độ an toàn gần như tương đương với chuỗi chính. Với các điều khoản hạn chế, một số 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 trên nền tảng mạng lưới ánh sáng, trong đó nổi bật có Eltoo, Ark.
Eltoo( còn được gọi là LN-Symmetry) là một ví dụ điển hình. Nó đề xuất một lớp thực thi cho mạng Lightning, cho phép bất kỳ trạng thái kênh nào sau này thay thế trạng thái trước đó mà không cần cơ chế trừng phạt, do đó có thể tránh việc các nút mạng Lightning phải lưu trữ nhiều trạng thái trước đó để phòng ngừa đối thủ gian lận. Eltoo đã đề xuất phương thức ký SIGHASH_NOINPUT, tức là APO(BIP-118) để đạt được hiệu ứng này.
Ark nhằm mục đích giảm bớt độ khó trong việc quản lý tính thanh khoản đầu vào của mạng lưới Lightning và các kênh. Đây là một giao thức dưới dạng joinpool, cho phép nhiều người dùng 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 nhất định, thực hiện giao dịch UTXO ( vUTXO ) ngoài chuỗi, nhưng chia sẻ một UTXO trên chuỗi để giảm chi phí. Tương tự như kho lưu trữ, Ark cũng có thể được triển khai trên mạng Bitcoin hiện tại; nhưng sau khi đưa vào các điều khoản hạn chế, Ark có thể giảm lượng tương tác cần thiết dựa trên mẫu giao dịch, đạt được sự rút lui đơn phương ít tin cậy hơn.
Tổng quan về các điều khoản hạn chế
Từ các ứng dụng trên, có thể thấy rằng các điều khoản hạn chế giống như một hiệu ứng hơn là một công nghệ cụ thể nào đó, vì vậy có nhiều cách thực hiện khác nhau. Có thể phân loại từ một số khía cạnh sau:
Loại: Loại tổng quát, loại chuyên dụng
Phương thức thực hiện: Dựa trên mã lệnh, Dựa trên chữ ký
Tính đệ quy: đệ quy, phi đệ quy
Trong đó, đệ quy đề cập đến việc một số điều khoản hạn chế có thể được thực hiện bằng cách hạn chế đầu ra của giao dịch tiếp theo để hạn chế đầu ra của giao dịch tiếp theo nữa, thực hiện các hạn chế xuyên suốt nhiều giao dịch.
Các điều khoản hạn chế chính bao gồm:
OP_CTV: Loại chung, dựa trên mã thao tác, không đệ quy
APO: loại chung, dựa trên chữ ký, phi đệ quy
OP_VAULT: loại chuyên dụng, dựa trên mã thao tác, không đệ quy
OP_CAT: Loại tổng quát, dựa trên mã thao tác, đệ quy ( nếu kết hợp với OP_CAT )
Thiết kế điều khoản hạn chế
Hiện tại, script Bitcoin chủ yếu giới hạn điều kiện mở khóa, không giới hạn UTXO như thế nào để được chi tiêu thêm. Để thực hiện các điều khoản hạn chế, cần phải suy ngẫm về lý do tại sao script hiện tại không thể thực hiện chức năng này.
Nguyên nhân chính là do hiện tại script Bitcoin không thể đọc nội dung của giao dịch, tức là "nội tâm" (introspection).
Nếu có thể thực hiện việc kiểm tra 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ì có thể thực hiện các điều khoản hạn chế.
Do đó, thiết kế các điều khoản hạn chế chủ yếu xoay quanh cách thực hiện sự tự xem xét.
Dựa trên mã lệnh vs Dựa trên chữ ký
Ý tưởng trực tiếp nhất là thêm một hoặc nhiều mã lệnh ( một mã lệnh + nhiều tham số, hoặc nhiều mã lệnh chức năng khác nhau ), đọc trực tiếp nội dung giao dịch. Đây là ý tưởng dựa trên mã lệnh.
Một cách tiếp cận khác là không đọc và kiểm tra nội dung giao dịch trực tiếp trong script, mà là tận dụng hash của nội dung giao dịch - nếu hash này đã được ký, thì chỉ cần cải tiến trong script như OP_CHECKSIG để kiểm tra chữ ký này, có thể gián tiếp thực hiện việc nội soi giao dịch và hạn chế điều khoản. Đây là cách thiết kế dựa trên chữ ký, chủ yếu bao gồm APO và OP_CSFS.
APO
SIGHASH_ANYPREVOUT(APO) là một phương thức ký Bitcoin được đề xuất. Cách đơn giản nhất để ký là cam kết cho cả đầu vào và đầu ra của giao dịch, nhưng Bitcoin còn có cách linh hoạt hơn, đó là SIGHASH, cho phép cam kết một cách chọn lọc cho các đầu vào hoặc đầu ra trong giao dịch.
SIGHASH của APO chỉ ký vào đầu ra, không ký vào phần đầu vào. Điều này có nghĩa là giao dịch đã ký theo cách APO có thể được đính kèm vào bất kỳ UTXO nào đáp ứng điều kiện.
Sự linh hoạt này là cơ sở lý thuyết cho việc thực hiện các điều khoản giới hạn của APO:
Có thể tạo trước một hoặc nhiều giao dịch
Xây dựng một khóa công khai chỉ có thể tạo ra một chữ ký từ những thông tin giao dịch này
Bằng cách này, bất kỳ tài sản nào được gửi đến địa chỉ khóa công khai đó chỉ có thể được chi tiêu thông qua giao dịch đã được tạo trước.
Cần 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 rằng các tài sản này chỉ có thể được chi tiêu thông qua các giao dịch đã được tạo sẵn. Chúng ta có thể quy định hướng đi của tài sản trong các giao dịch đã được tạo sẵn này, từ đó thực hiện các điều khoản hạn chế.
Chúng ta có thể hiểu thông qua việc so sánh hợp đồng thông minh của Ethereum: thông qua hợp đồng thông minh, những gì chúng ta có thể thực hiện cũng chỉ là chỉ có thể rút tiền từ địa chỉ hợp đồng khi có điều kiện nhất định, chứ không phải chỉ dựa vào một chữ ký EOA để chi tiêu tùy ý. Từ điểm này mà nhìn, Bitcoin có thể đạt được hiệu ứng này thông qua việc cải tiến cơ chế chữ ký.
Nhưng vấn đề trong quá trình trên là có sự phụ thuộc vòng trong tính toán, vì cần biết nội dung đầu vào để ký trước và tạo giao dịch.
Ý nghĩa của việc thực hiện phương pháp ký này bằng APO và SIGHASH_NOINPUT là có thể 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 tất cả đầu ra của giao dịch được chỉ định bởi (.
![Giải thích về Covenants: Làm thế nào để đạt được khả năng lập trình của Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-302ac02874352e52cf0e80c7ddb193ec.webp(
) OP_CTV
OP_CHECKTEMPLATEVERIFY###CTV(, tức là BIP-119, đã áp dụng mã opcode được cải tiến
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Điều khoản hạn chế Bitcoin: Mở khóa khả năng lập trình thế hệ mới của BTC
Bitcoin hạn chế điều khoản: hướng đi mới để đạt được Khả năng lập trình
Cộng đồng Bitcoin gần đây đã có những cuộc thảo luận sôi nổi về việc tái kích hoạt các mã lệnh như OP_CAT. Taproot Wizard đã thu hút được nhiều sự chú ý bằng cách phát hành Quantum Cats NFT và tuyên bố nhận được mã BIP-420. Những người ủng hộ cho rằng việc kích hoạt OP_CAT có thể thực hiện "các điều khoản hạn chế", từ đó mang lại hợp đồng thông minh và khả năng lập trình cho Bitcoin.
"Hạn chế điều khoản"(covenants) khái niệm này đã gây ra nhiều cuộc thảo luận giữa các nhà phát triển trong nhiều năm. Ngoài OP_CAT, còn có nhiều giải pháp kỹ thuật khác để thực hiện các điều khoản hạn chế như OP_CTV, APO, OP_VAULT, v.v. Vậy, điều gì là "hạn chế điều khoản" của Bitcoin? Tại sao nó lại thu hút sự quan tâm rộng rãi và lâu dài như vậy? Nó có thể mang lại khả năng lập trình nào cho Bitcoin? Nguyên lý thiết kế đằng sau là gì? Bài viết này sẽ cung cấp cái nhìn tổng quan và thảo luận về những vấn đề này.
Điều khoản "giới hạn"
"Điều khoản hạn chế"(covenants) là một cơ chế có thể đặt điều kiện cho các giao dịch Bitcoin trong tương lai. Kịch bản Bitcoin hiện tại đã chứa một số điều kiện hạn chế, chẳng hạn như cần nhập chữ ký hợp lệ, cung cấp kịch bản đáp ứng yêu cầu, v.v. Nhưng chỉ cần người dùng có thể mở khóa, họ có thể chi tiêu UTXO đến bất kỳ đâu.
Và các điều khoản hạn chế đã thêm nhiều hạn chế hơn trên cơ sở này, chẳng hạn như hạn chế hướng chi tiêu tiếp theo của UTXO, nhằm đạt được hiệu ứng "dành riêng cho mục đích cụ thể"; hoặc hạn chế các điều kiện của các đầu vào khác trong một giao dịch.
Nói chính xác hơn, hiện tại kịch bản Bitcoin cũng có một số chức năng hạn chế, chẳng hạn như khóa thời gian dựa trên mã thao tác. Bằng cách kiểm tra các trường nLock hoặc nSequence của giao dịch, có thể thực hiện giới hạn thời gian trước khi chi tiêu giao dịch. Nhưng hiện tại chủ yếu giới hạn ở khía cạnh thời gian.
Mục đích của việc các nhà phát triển thiết kế các kiểm tra hạn chế này không chỉ là để hạn chế, mà còn để thiết lập các quy tắc thực hiện giao dịch. Người dùng chỉ có thể thực hiện giao dịch theo các quy tắc đã được thiết lập trước, từ đó hoàn thành quy trình kinh doanh đã định.
Do đó, các điều khoản hạn chế một cách ngược lại có thể mở khóa nhiều trường hợp ứng dụng hơn.
Ứng dụng
Đảm bảo hình phạt Staking
Một ví dụ trực quan về điều khoản hạn chế là giao dịch slash trong Bitcoin staking của Babylon.
Quá trình staking Bitcoin của Babylon là người dùng gửi tài sản BTC vào một script đặc biệt trên chuỗi chính, điều kiện chi tiêu bao gồm hai loại:
Kết thúc bình thường: Sau một khoảng thời gian nhất định, người dùng có thể mở khóa bằng chữ ký của mình, hoàn thành quá trình unstake.
Kết thúc hình phạt: Nếu người dùng có hành vi xấu như ký hai lần trên chuỗi PoS của Babylon, thì thông qua EOTS( có thể rút một chữ ký một lần ) để mở khóa tài sản, một phần tài sản sẽ bị buộc gửi đến địa chỉ đốt (slash) bởi các vai trò thực thi trong mạng.
"Gửi cưỡng chế" ở đây có nghĩa là ngay cả khi có thể mở khóa UTXO, tài sản đó cũng không thể được gửi đến nơi khác một cách tùy ý, chỉ có thể bị thiêu. Điều này đảm bảo rằng người dùng xấu không thể nhanh chóng sử dụng chữ ký đã biết để chuyển tài sản trở lại cho chính mình, thoát khỏi hình phạt.
Sau khi các điều khoản hạn chế như OP_CTV được thực hiện, có thể thêm mã thao tác liên quan vào nhánh "kết thúc hình phạt" của kịch bản staking để thực hiện hạn chế.
Và trước khi OP_CTV được kích hoạt, Babylon cần phải mô phỏng hiệu quả thi hành các điều khoản hạn chế thông qua phương pháp linh hoạt được thực hiện bởi người dùng và ủy ban.
Kiểm soát tắc nghẽn
Khi mạng bị tắc nghẽn, trong pool giao dịch tích lũy một lượng lớn giao dịch chờ được đóng gói, người dùng cần nâng cao phí giao dịch để có được xác nhận nhanh chóng. Nếu người dùng phải gửi nhiều giao dịch cho nhiều bên nhận, họ sẽ phải chịu chi phí cao hơn, đồng thời làm tăng thêm tỷ lệ phí giao dịch toàn mạng.
Có các điều khoản hạn chế, bên gửi có thể cam kết một giao dịch gửi hàng loạt trước. Cam kết này khiến tất cả các bên nhận tin tưởng rằng giao dịch cuối cùng sẽ được thực hiện, có thể đợi đến khi tỷ lệ phí giao dịch giảm rồi mới gửi giao dịch cụ thể.
Khi nhu cầu về không gian khối rất cao, giao dịch trở nên đắt đỏ. Sử dụng OP_CHECKTEMPLATEVERIFY, các nhà xử lý thanh toán số lượng lớn có thể gộp tất cả các khoản thanh toán vào một giao dịch O(1) duy nhất để xác nhận. Sau đó, khi nhu cầu về không gian khối giảm, có thể mở rộng các khoản thanh toán từ UTXO đó.
Đây là một trong những ứng dụng điển hình được đề xuất bởi điều khoản hạn chế OP_CTV.
Kho lưu trữ
Kho lưu trữ ( vault ) là một kịch bản được bàn luận rộng rãi trong ứng dụng Bitcoin, đặc biệt trong lĩnh vực các điều khoản hạn chế. Các hoạt động hàng ngày cần phải cân bằng giữa việc bảo quản vốn và nhu cầu sử dụng, mọi người mong muốn có một loại ứng dụng kho lưu trữ: vừa có thể đảm bảo an toàn cho vốn, ngay cả khi tài khoản bị hack (, việc rò rỉ ) khóa riêng cũng có thể hạn chế việc sử dụng vốn.
Dựa trên công nghệ điều khoản hạn chế, có thể dễ dàng xây dựng các ứng dụng kho lưu trữ.
Lấy kế hoạch OP_VAULT làm ví dụ: Khi chi tiêu quỹ kho lưu trữ, cần gửi một giao dịch lên chuỗi để thể hiện ý định ( "trigger" ), và đặt điều kiện:
Trường hợp bình thường: Giao dịch thứ hai là giao dịch rút tiền cuối cùng. Sau khi chờ N khối, có thể chi tiêu số tiền vào bất kỳ địa chỉ nào.
Tình huống bất thường: Nếu phát hiện là giao dịch bị đánh cắp ( hoặc bị ép buộc ), trước khi gửi giao dịch rút tiền trong N khối, có thể ngay lập tức chuyển tiền đến một địa chỉ an toàn hơn.
Cần lưu ý, ngay cả khi không có điều khoản hạn chế, vẫn có thể xây dựng ứng dụng lưu ký. Một phương pháp là chuẩn bị chữ ký cho việc chi tiêu trong tương lai bằng khóa riêng, sau đó phá hủy khóa riêng. Tuy nhiên, phương pháp này vẫn có những hạn chế, như cần đảm bảo khóa riêng đã bị phá hủy, số tiền và phí giao dịch cần được xác định trước, v.v., thiếu tính linh hoạt.
Trạng thái kênh mạnh mẽ và linh hoạt hơn
Kênh trạng thái ( bao gồm mạng lưới ánh sáng ) trong trường hợp các nút có thể quan sát trạng thái mới nhất, có thể công bố trạng thái mới nhất lên chuỗi, có thể coi là có độ an toàn gần như tương đương với chuỗi chính. Với các điều khoản hạn chế, một số 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 trên nền tảng mạng lưới ánh sáng, trong đó nổi bật có Eltoo, Ark.
Eltoo( còn được gọi là LN-Symmetry) là một ví dụ điển hình. Nó đề xuất một lớp thực thi cho mạng Lightning, cho phép bất kỳ trạng thái kênh nào sau này thay thế trạng thái trước đó mà không cần cơ chế trừng phạt, do đó có thể tránh việc các nút mạng Lightning phải lưu trữ nhiều trạng thái trước đó để phòng ngừa đối thủ gian lận. Eltoo đã đề xuất phương thức ký SIGHASH_NOINPUT, tức là APO(BIP-118) để đạt được hiệu ứng này.
Ark nhằm mục đích giảm bớt độ khó trong việc quản lý tính thanh khoản đầu vào của mạng lưới Lightning và các kênh. Đây là một giao thức dưới dạng joinpool, cho phép nhiều người dùng 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 nhất định, thực hiện giao dịch UTXO ( vUTXO ) ngoài chuỗi, nhưng chia sẻ một UTXO trên chuỗi để giảm chi phí. Tương tự như kho lưu trữ, Ark cũng có thể được triển khai trên mạng Bitcoin hiện tại; nhưng sau khi đưa vào các điều khoản hạn chế, Ark có thể giảm lượng tương tác cần thiết dựa trên mẫu giao dịch, đạt được sự rút lui đơn phương ít tin cậy hơn.
Tổng quan về các điều khoản hạn chế
Từ các ứng dụng trên, có thể thấy rằng các điều khoản hạn chế giống như một hiệu ứng hơn là một công nghệ cụ thể nào đó, vì vậy có nhiều cách thực hiện khác nhau. Có thể phân loại từ một số khía cạnh sau:
Trong đó, đệ quy đề cập đến việc một số điều khoản hạn chế có thể được thực hiện bằng cách hạn chế đầu ra của giao dịch tiếp theo để hạn chế đầu ra của giao dịch tiếp theo nữa, thực hiện các hạn chế xuyên suốt nhiều giao dịch.
Các điều khoản hạn chế chính bao gồm:
Thiết kế điều khoản hạn chế
Hiện tại, script Bitcoin chủ yếu giới hạn điều kiện mở khóa, không giới hạn UTXO như thế nào để được chi tiêu thêm. Để thực hiện các điều khoản hạn chế, cần phải suy ngẫm về lý do tại sao script hiện tại không thể thực hiện chức năng này.
Nguyên nhân chính là do hiện tại script Bitcoin không thể đọc nội dung của giao dịch, tức là "nội tâm" (introspection).
Nếu có thể thực hiện việc kiểm tra 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ì có thể thực hiện các điều khoản hạn chế.
Do đó, thiết kế các điều khoản hạn chế chủ yếu xoay quanh cách thực hiện sự tự xem xét.
Dựa trên mã lệnh vs Dựa trên chữ ký
Ý tưởng trực tiếp nhất là thêm một hoặc nhiều mã lệnh ( một mã lệnh + nhiều tham số, hoặc nhiều mã lệnh chức năng khác nhau ), đọc trực tiếp nội dung giao dịch. Đây là ý tưởng dựa trên mã lệnh.
Một cách tiếp cận khác là không đọc và kiểm tra nội dung giao dịch trực tiếp trong script, mà là tận dụng hash của nội dung giao dịch - nếu hash này đã được ký, thì chỉ cần cải tiến trong script như OP_CHECKSIG để kiểm tra chữ ký này, có thể gián tiếp thực hiện việc nội soi giao dịch và hạn chế điều khoản. Đây là cách thiết kế dựa trên chữ ký, chủ yếu bao gồm APO và OP_CSFS.
APO
SIGHASH_ANYPREVOUT(APO) là một phương thức ký Bitcoin được đề xuất. Cách đơn giản nhất để ký là cam kết cho cả đầu vào và đầu ra của giao dịch, nhưng Bitcoin còn có cách linh hoạt hơn, đó là SIGHASH, cho phép cam kết một cách chọn lọc cho các đầu vào hoặc đầu ra trong giao dịch.
SIGHASH của APO chỉ ký vào đầu ra, không ký vào phần đầu vào. Điều này có nghĩa là giao dịch đã ký theo cách APO có thể được đính kèm vào bất kỳ UTXO nào đáp ứng điều kiện.
Sự linh hoạt này là cơ sở lý thuyết cho việc thực hiện các điều khoản giới hạn của APO:
Cần 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 rằng các tài sản này chỉ có thể được chi tiêu thông qua các giao dịch đã được tạo sẵn. Chúng ta có thể quy định hướng đi của tài sản trong các giao dịch đã được tạo sẵn này, từ đó thực hiện các điều khoản hạn chế.
Chúng ta có thể hiểu thông qua việc so sánh hợp đồng thông minh của Ethereum: thông qua hợp đồng thông minh, những gì chúng ta có thể thực hiện cũng chỉ là chỉ có thể rút tiền từ địa chỉ hợp đồng khi có điều kiện nhất định, chứ không phải chỉ dựa vào một chữ ký EOA để chi tiêu tùy ý. Từ điểm này mà nhìn, Bitcoin có thể đạt được hiệu ứng này thông qua việc cải tiến cơ chế chữ ký.
Nhưng vấn đề trong quá trình trên là có sự phụ thuộc vòng trong tính toán, vì cần biết nội dung đầu vào để ký trước và tạo giao dịch.
Ý nghĩa của việc thực hiện phương pháp ký này bằng APO và SIGHASH_NOINPUT là có thể 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 tất cả đầu ra của giao dịch được chỉ định bởi (.
![Giải thích về Covenants: Làm thế nào để đạt được khả năng lập trình của Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-302ac02874352e52cf0e80c7ddb193ec.webp(
) OP_CTV
OP_CHECKTEMPLATEVERIFY###CTV(, tức là BIP-119, đã áp dụng mã opcode được cải tiến