Giải thích chi tiết các điều khoản hạn chế: Thực hiện khả năng lập trình của Bitcoin
Gần đây, cộng đồng Bitcoin đã dấy lên một đợt thảo luận về việc tái kích hoạt các opcode như OP_CAT. Taproot Wizard đã thu hút sự chú ý của nhiều người qua việc ra mắt Quantum Cats NFT và tuyên bố đã nhận được số hiệu BIP-420. Những người ủng hộ tuyên bố rằng việc kích hoạt OP_CAT có thể thực hiện "các điều kiện hạn chế", từ đó đạt được hợp đồng thông minh hoặc khả năng lập trình của Bitcoin.
Nếu bạn chú ý đến từ "điều khoản hạn chế" và tìm kiếm một chút, bạn sẽ phát hiện ra rằng đây là một hố thỏ lớn khác. Các nhà phát triển đã thảo luận trong nhiều năm về các công nghệ thực hiện điều khoản hạn chế, ngoài OP_CAT, còn có OP_CTV, APO, OP_VAULT, v.v.
Vậy, rốt cuộc điều gì là "điều khoản hạn chế" của Bitcoin? Tại sao nó có thể thu hút được nhiều nhà phát triển quan tâm và thảo luận trong suốt nhiều năm như vậy? Điều gì trong khả năng lập trình của Bitcoin có thể được thực hiện? Nguyên lý thiết kế đứng sau nó là gì? Bài viết này sẽ cố gắng đưa ra một cái nhìn tổng quan và thảo luận.
Điều khoản "giới hạn" là gì
Giới hạn điều khoản (Covenants) là một cơ chế có khả năng lập trình để thiết lập điều kiện cho các giao dịch Bitcoin trong tương lai.
Hiện tại, kịch bản Bitcoin cũng bao gồm các điều kiện hạn chế, chẳng hạn như khi chi tiêu phải nhập chữ ký hợp lệ, đưa vào kịch bản phù hợp, 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 mà họ mong muốn.
Và các điều khoản hạn chế là, dựa trên cách mở khóa này, đưa ra nhiều hạn chế hơn, chẳng hạn như hạn chế chi tiêu sau UTXO, tức là đạt được hiệu ứng giống như "dành riêng cho mục đích cụ thể"; hoặc các điều kiện đầu vào khác được gửi vào trong một giao dịch.
Nói một cách chặt chẽ hơn, hiện tại kịch bản Bitcoin cũng có một số điều khoản hạn chế nhất định, chẳng hạn như khóa thời gian dựa trên mã thao tác, được thực hiện thông qua các trường nLock hoặc nSequence của giao dịch nội bộ để thiết lập giới hạn thời gian trước khi chi tiêu giao dịch, nhưng cũng chủ yếu chỉ giới hạn ở khía cạnh thời gian.
Vậy, tại sao các nhà phát triển và nghiên cứu lại thiết kế những kiểm tra hạn chế này? Bởi vì các điều khoản hạn chế không chỉ để giới hạn mà còn để thiết lập các quy tắc thực hiện giao dịch. Như vậy, 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 dự kiến.
Vì vậy, điều này có vẻ ngược lại với trực giác, nhưng nó 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ụ rõ ràng về các điều khoản hạn chế là giao dịch slash trong quy trình staking Bitcoin của Babylon.
Quá trình staking Bitcoin của Babylon là người dùng gửi tài sản BTC của mình vào một kịch bản đặc biệt trên chuỗi chính, điều kiện chi tiêu bao gồm hai loại:
Trong trường hợp bình thường: Sau một thời gian nhất định, người dùng có thể mở khóa bằng chữ ký của chính mình, tức là hoàn thành quá trình unstake.
Tình huống bất thường: Nếu người dùng có hành vi xấu như ký kép trên một chuỗi PoS bị Babylon cho thuê an toàn, thì thông qua EOTS(chữ ký một lần có thể lấy lại, chữ ký một lần có thể lấy lại), có thể mở khóa phần tài sản này, và một phần tài sản sẽ bị gửi cưỡng chế đến địa chỉ đốt(slash).
Lưu ý rằng "gửi cưỡng chế" ở đây có nghĩa là ngay cả khi có thể mở khóa UTXO này, nhưng tài sản này không thể gửi đến bất kỳ nơi nào tùy ý, chỉ có thể bị đốt đi. Điều này nhằm đảm bảo rằng người dùng xấu không thể nhanh chóng sử dụng chữ ký đã biết của mình để chuyển tài sản trở lại cho chính mình, nhằm tránh bị trừng phạt.
Chức năng này, nếu được thực hiện sau các điều khoản giới hạn như OP_CTV, có thể thêm các opcode như OP_CTV vào nhánh "tình huống bất thường" của kịch bản staking để thực hiện giới hạn.
Và trước khi OP_CTV được kích hoạt, Babylon cần phải sử dụng các phương pháp linh hoạt, được thực hiện bởi người dùng + ủy ban để mô phỏng hiệu quả thực thi các điều khoản hạn chế.
Kiểm soát tắc nghẽn
Nói chung, tắc nghẽn đề cập đến khi tỷ lệ phí giao dịch trên mạng Bitcoin rất cao, và có nhiều giao dịch tích lũy trong bể giao dịch chờ được đóng gói, vì vậy nếu người dùng muốn xác nhận giao dịch nhanh chóng, họ cần tăng phí giao dịch.
Và lúc này, nếu một người dùng phải gửi nhiều giao dịch cho nhiều người nhận, họ sẽ phải tăng phí giao dịch, chịu chi phí cao hơn. Đồng thời, điều này cũng sẽ làm tăng tỷ lệ phí giao dịch toàn mạng.
Nếu có điều khoản hạn chế, một giải pháp là người gửi có thể cam kết trước với một giao dịch gửi hàng loạt. Cam kết này có thể khiến tất cả người nhận tin tưởng rằng giao dịch cuối cùng sẽ được thực hiện, và có thể đợi đến khi phí giao dịch thấp hơn để gửi giao dịch cụ thể.
Khi nhu cầu về không gian khối rất cao, việc thực hiện giao dịch trở nên rất tốn kém. Bằng cách 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 của mình vào một giao dịch O(1) duy nhất để xác nhận. Sau đó, sau một thời gian, khi nhu cầu về không gian khối giảm, các khoản thanh toán có thể được mở rộng từ UTXO đó.
Cảnh này là một ví dụ điển hình cho trường hợp ứng dụng của điều khoản hạn chế OP_CTV.
Kho lưu trữ
Kho giữ ( vault ) là một loại ứng dụng đượ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ế. Bởi vì các hoạt động hàng ngày không thể tránh khỏi việc phải cân bằng giữa việc bảo quản vốn và nhu cầu sử dụng vốn, nên mọi người mong muốn có một loại ứng dụng kho giữ: có thể đảm bảo an toàn cho vốn, thậm chí ngay cả khi tài khoản bị hack ( lộ 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ệ của các điều khoản hạn chế thực hiện, các ứng dụng loại kho lưu trữ có thể được xây dựng khá dễ dàng.
Lấy thiết kế của OP_VAULT làm ví dụ: Khi tiêu tiền trong kho bảo quản, cần phải gửi một giao dịch lên chuỗi trước. Giao dịch này thể hiện ý định muốn tiêu tiền từ kho bảo quản, tức là "trigger", và thiết lập các điều kiện trong đó:
Nếu mọi thứ đều ổn, thì 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 này ở bất kỳ đâu.
Nếu phát hiện giao dịch này bị đánh cắp ( hoặc bị đe dọa "tấn công cờ lê" ), có thể ngay lập tức chuyển đến một địa chỉ an toàn khác ( trước khi gửi giao dịch rút tiền trong N khối, để người dùng bảo quản ) an toàn hơn.
Cần lưu ý rằng, trong trường hợp không có điều khoản hạn chế, cũng có thể xây dựng một ứng dụng lưu trữ, một cách khả thi là chuẩn bị chữ ký cho chi tiêu trong tương lai bằng cách sử dụng khóa riêng, sau đó tiêu hủy khóa riêng này. Nhưng vẫn có nhiều hạn chế, chẳng hạn như cần đảm bảo khóa riêng đã bị tiêu hủy ( tương tự như quy trình thiết lập đáng tin cậy trong bằng chứng không kiến thức ), số tiền và phí giao dịch được xác định trước ( vì phải ký trước ) do đó thiếu tính linh hoạt v.v.
Trạng thái kênh mạnh mẽ và linh hoạt hơn
Thông thường, có thể coi các kênh trạng thái, bao gồm cả mạng Lightning, có độ an toàn gần như tương đương với chuỗi chính ( trong điều kiện đảm bảo rằng các nút có thể quan sát trạng thái mới nhất và có khả năng phát hành trạng thái mới nhất lên chuỗi ). Tuy nhiên, sau khi có các điều khoản hạn chế, một số ý 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 trên mạng Lightning. Trong số đó, một số cái tên nổi bật bao gồm Eltoo, Ark.
Eltoo ( còn được gọi là LN-Symmetry) là một trong những ví dụ điển hình. Giải pháp công nghệ này lấy âm của "L2", đề 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ế xử phạt, do đó cũng có thể đồng thời tránh tình trạng các nút mạng Lightning phải lưu giữ nhiều trạng thái trước đó để ngăn chặn hành vi xấu từ đối thủ. Để đạt được hiệu ứng như trên, Eltoo đã đề xuất phương thức ký SIGHASH_NOINPUT, tức là APO(BIP-118).
Ark nhằm giảm bớt độ khó trong việc quản lý tính thanh khoản vào và kênh của mạng Lightning. Nó là một giao thức dạng joinpool, nhiều người dùng có thể chấp nhận một nhà cung cấp dịch vụ như là đối tác giao dịch trong một khoảng thời gian nhất định, thực hiện giao dịch ảo 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 thực hiện trên mạng Bitcoin hiện tại; nhưng sau khi đưa ra 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 một chiều ít tin cậy hơn.
Tổng quan kỹ thuật về các điều khoản hạn chế
Từ các ứng dụng trên, có thể thấy rằng điều khoản hạn chế giống như một hiệu ứng hơn là một công nghệ nào đó, vì vậy có nhiều cách kỹ thuật khác nhau để thực hiện. Nếu phân loại, có thể bao gồm:
Loại: Loại chung, Loại chuyên dụng
Cách thực hiện: Dựa trên Opcode, Dựa trên chữ ký
Đệ quy: Đệ quy, phi đệ quy
Trong đó, đệ quy có nghĩa là: có một số điều khoản hạn chế được thực hiện, cũng có thể thông qua việc 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, có thể thực hiện các hạn chế bổ sung vượt qua một giao dịch, đạt được độ sâu giao dịch cao hơn.
Một số thiết kế điều khoản hạn chế phổ biến bao gồm:
OP_CTV: Kiểu chung, dựa trên Opcode, không đệ quy
OP_VAULT: loại chuyên dụng, dựa trên Opcode, không đệ quy
APO: Loại chung, dựa trên chữ ký, không đệ quy
OP_CAT: Loại chung, dựa trên Opcode, đệ quy*
OP_CSFS: Loại chung, dựa trên chữ ký, đệ quy
*Nếu kết hợp OP_CAT
Thiết kế điều khoản hạn chế
Từ những giới thiệu trước đây, có thể thấy rằng, kịch bản Bitcoin hiện tại chủ yếu hạn chế các điều kiện mở khóa, không hạn chế cách mà UTXO này có thể được chi tiêu tiếp theo. Để thực hiện các điều khoản hạn chế, chúng ta cần suy nghĩ theo cách ngược lại: Tại sao kịch bản Bitcoin hiện tại không thể thực hiện các điều khoản hạn chế?
Nguyên nhân chủ yếu 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 suy" (introspection).
Nếu chúng ta có thể đạt được sự tự soi xét của 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ì chúng ta có thể thực hiện các điều khoản hạn chế.
Do đó, ý tưởng thiết kế của các điều khoản hạn chế chủ yếu xoay quanh việc làm thế nào để thực hiện sự nội tâm.
Dựa trên mã lệnh vs Dựa trên chữ ký
Ý tưởng đơn giản nhất là thêm một hoặc nhiều mã thao tác (, tức là một mã thao tác + nhiều tham số, hoặc nhiều mã thao tác khác nhau ), để trực tiếp đọc nội dung giao dịch. Điều này cũng dựa trên tư duy mã thao tác.
Một cách suy nghĩ khác là không cần phải đọc và kiểm tra nội dung của giao dịch trực tiếp trong tập lệnh, mà có thể sử dụng băm của nội dung giao dịch — nếu băm này đã được ký, thì chỉ cần sửa đổi trong tập lệnh, chẳng hạn như OP_CHECKSIG, để thực hiện việc kiểm tra chữ ký này, từ đó gián tiếp thực hiện việc tự kiểm tra giao dịch và các điều khoản hạn chế. Cách suy nghĩ này dựa trên 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 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 chọn lọc đối với một hoặc nhiều đầu vào hoặc đầu ra trong một giao dịch.
và SIGHASH của APO chỉ ký tên vào đầu ra, mà không ký tên vào phần đầu vào. Điều này có nghĩa là, sau khi giao dịch được ký theo cách APO, có thể trong
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Giải thích các điều khoản hạn chế của Bitcoin: Khai mở kỷ nguyên mới của khả năng lập trình
Giải thích chi tiết các điều khoản hạn chế: Thực hiện khả năng lập trình của Bitcoin
Gần đây, cộng đồng Bitcoin đã dấy lên một đợt thảo luận về việc tái kích hoạt các opcode như OP_CAT. Taproot Wizard đã thu hút sự chú ý của nhiều người qua việc ra mắt Quantum Cats NFT và tuyên bố đã nhận được số hiệu BIP-420. Những người ủng hộ tuyên bố rằng việc kích hoạt OP_CAT có thể thực hiện "các điều kiện hạn chế", từ đó đạt được hợp đồng thông minh hoặc khả năng lập trình của Bitcoin.
Nếu bạn chú ý đến từ "điều khoản hạn chế" và tìm kiếm một chút, bạn sẽ phát hiện ra rằng đây là một hố thỏ lớn khác. Các nhà phát triển đã thảo luận trong nhiều năm về các công nghệ thực hiện điều khoản hạn chế, ngoài OP_CAT, còn có OP_CTV, APO, OP_VAULT, v.v.
Vậy, rốt cuộc điều gì là "điều khoản hạn chế" của Bitcoin? Tại sao nó có thể thu hút được nhiều nhà phát triển quan tâm và thảo luận trong suốt nhiều năm như vậy? Điều gì trong khả năng lập trình của Bitcoin có thể được thực hiện? Nguyên lý thiết kế đứng sau nó là gì? Bài viết này sẽ cố gắng đưa ra một cái nhìn tổng quan và thảo luận.
Điều khoản "giới hạn" là gì
Giới hạn điều khoản (Covenants) là một cơ chế có khả năng lập trình để thiết lập điều kiện cho các giao dịch Bitcoin trong tương lai.
Hiện tại, kịch bản Bitcoin cũng bao gồm các điều kiện hạn chế, chẳng hạn như khi chi tiêu phải nhập chữ ký hợp lệ, đưa vào kịch bản phù hợp, 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 mà họ mong muốn.
Và các điều khoản hạn chế là, dựa trên cách mở khóa này, đưa ra nhiều hạn chế hơn, chẳng hạn như hạn chế chi tiêu sau UTXO, tức là đạt được hiệu ứng giống như "dành riêng cho mục đích cụ thể"; hoặc các điều kiện đầu vào khác được gửi vào trong một giao dịch.
Nói một cách chặt chẽ hơn, hiện tại kịch bản Bitcoin cũng có một số điều khoản hạn chế nhất định, chẳng hạn như khóa thời gian dựa trên mã thao tác, được thực hiện thông qua các trường nLock hoặc nSequence của giao dịch nội bộ để thiết lập giới hạn thời gian trước khi chi tiêu giao dịch, nhưng cũng chủ yếu chỉ giới hạn ở khía cạnh thời gian.
Vậy, tại sao các nhà phát triển và nghiên cứu lại thiết kế những kiểm tra hạn chế này? Bởi vì các điều khoản hạn chế không chỉ để giới hạn mà còn để thiết lập các quy tắc thực hiện giao dịch. Như vậy, 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 dự kiến.
Vì vậy, điều này có vẻ ngược lại với trực giác, nhưng nó 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ụ rõ ràng về các điều khoản hạn chế là giao dịch slash trong quy trình staking Bitcoin của Babylon.
Quá trình staking Bitcoin của Babylon là người dùng gửi tài sản BTC của mình vào một kịch bản đặc biệt trên chuỗi chính, điều kiện chi tiêu bao gồm hai loại:
Lưu ý rằng "gửi cưỡng chế" ở đây có nghĩa là ngay cả khi có thể mở khóa UTXO này, nhưng tài sản này không thể gửi đến bất kỳ nơi nào tùy ý, chỉ có thể bị đốt đi. Điều này nhằm đảm bảo rằng người dùng xấu không thể nhanh chóng sử dụng chữ ký đã biết của mình để chuyển tài sản trở lại cho chính mình, nhằm tránh bị trừng phạt.
Chức năng này, nếu được thực hiện sau các điều khoản giới hạn như OP_CTV, có thể thêm các opcode như OP_CTV vào nhánh "tình huống bất thường" của kịch bản staking để thực hiện giới hạn.
Và trước khi OP_CTV được kích hoạt, Babylon cần phải sử dụng các phương pháp linh hoạt, được thực hiện bởi người dùng + ủy ban để mô phỏng hiệu quả thực thi các điều khoản hạn chế.
Kiểm soát tắc nghẽn
Nói chung, tắc nghẽn đề cập đến khi tỷ lệ phí giao dịch trên mạng Bitcoin rất cao, và có nhiều giao dịch tích lũy trong bể giao dịch chờ được đóng gói, vì vậy nếu người dùng muốn xác nhận giao dịch nhanh chóng, họ cần tăng phí giao dịch.
Và lúc này, nếu một người dùng phải gửi nhiều giao dịch cho nhiều người nhận, họ sẽ phải tăng phí giao dịch, chịu chi phí cao hơn. Đồng thời, điều này cũng sẽ làm tăng tỷ lệ phí giao dịch toàn mạng.
Nếu có điều khoản hạn chế, một giải pháp là người gửi có thể cam kết trước với một giao dịch gửi hàng loạt. Cam kết này có thể khiến tất cả người nhận tin tưởng rằng giao dịch cuối cùng sẽ được thực hiện, và có thể đợi đến khi phí giao dịch thấp hơn để gửi giao dịch cụ thể.
Khi nhu cầu về không gian khối rất cao, việc thực hiện giao dịch trở nên rất tốn kém. Bằng cách 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 của mình vào một giao dịch O(1) duy nhất để xác nhận. Sau đó, sau một thời gian, khi nhu cầu về không gian khối giảm, các khoản thanh toán có thể được mở rộng từ UTXO đó.
Cảnh này là một ví dụ điển hình cho trường hợp ứng dụng của điều khoản hạn chế OP_CTV.
Kho lưu trữ
Kho giữ ( vault ) là một loại ứng dụng đượ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ế. Bởi vì các hoạt động hàng ngày không thể tránh khỏi việc phải cân bằng giữa việc bảo quản vốn và nhu cầu sử dụng vốn, nên mọi người mong muốn có một loại ứng dụng kho giữ: có thể đảm bảo an toàn cho vốn, thậm chí ngay cả khi tài khoản bị hack ( lộ 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ệ của các điều khoản hạn chế thực hiện, các ứng dụng loại kho lưu trữ có thể được xây dựng khá dễ dàng.
Lấy thiết kế của OP_VAULT làm ví dụ: Khi tiêu tiền trong kho bảo quản, cần phải gửi một giao dịch lên chuỗi trước. Giao dịch này thể hiện ý định muốn tiêu tiền từ kho bảo quản, tức là "trigger", và thiết lập các điều kiện trong đó:
Cần lưu ý rằng, trong trường hợp không có điều khoản hạn chế, cũng có thể xây dựng một ứng dụng lưu trữ, một cách khả thi là chuẩn bị chữ ký cho chi tiêu trong tương lai bằng cách sử dụng khóa riêng, sau đó tiêu hủy khóa riêng này. Nhưng vẫn có nhiều hạn chế, chẳng hạn như cần đảm bảo khóa riêng đã bị tiêu hủy ( tương tự như quy trình thiết lập đáng tin cậy trong bằng chứng không kiến thức ), số tiền và phí giao dịch được xác định trước ( vì phải ký trước ) do đó thiếu tính linh hoạt v.v.
Trạng thái kênh mạnh mẽ và linh hoạt hơn
Thông thường, có thể coi các kênh trạng thái, bao gồm cả mạng Lightning, có độ an toàn gần như tương đương với chuỗi chính ( trong điều kiện đảm bảo rằng các nút có thể quan sát trạng thái mới nhất và có khả năng phát hành trạng thái mới nhất lên chuỗi ). Tuy nhiên, sau khi có các điều khoản hạn chế, một số ý 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 trên mạng Lightning. Trong số đó, một số cái tên nổi bật bao gồm Eltoo, Ark.
Eltoo ( còn được gọi là LN-Symmetry) là một trong những ví dụ điển hình. Giải pháp công nghệ này lấy âm của "L2", đề 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ế xử phạt, do đó cũng có thể đồng thời tránh tình trạng các nút mạng Lightning phải lưu giữ nhiều trạng thái trước đó để ngăn chặn hành vi xấu từ đối thủ. Để đạt được hiệu ứng như trên, Eltoo đã đề xuất phương thức ký SIGHASH_NOINPUT, tức là APO(BIP-118).
Ark nhằm giảm bớt độ khó trong việc quản lý tính thanh khoản vào và kênh của mạng Lightning. Nó là một giao thức dạng joinpool, nhiều người dùng có thể chấp nhận một nhà cung cấp dịch vụ như là đối tác giao dịch trong một khoảng thời gian nhất định, thực hiện giao dịch ảo 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 thực hiện trên mạng Bitcoin hiện tại; nhưng sau khi đưa ra 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 một chiều ít tin cậy hơn.
Tổng quan kỹ thuật về các điều khoản hạn chế
Từ các ứng dụng trên, có thể thấy rằng điều khoản hạn chế giống như một hiệu ứng hơn là một công nghệ nào đó, vì vậy có nhiều cách kỹ thuật khác nhau để thực hiện. Nếu phân loại, có thể bao gồm:
Trong đó, đệ quy có nghĩa là: có một số điều khoản hạn chế được thực hiện, cũng có thể thông qua việc 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, có thể thực hiện các hạn chế bổ sung vượt qua một giao dịch, đạt được độ sâu giao dịch cao hơn.
Một số thiết kế điều khoản hạn chế phổ biến bao gồm:
*Nếu kết hợp OP_CAT
Thiết kế điều khoản hạn chế
Từ những giới thiệu trước đây, có thể thấy rằng, kịch bản Bitcoin hiện tại chủ yếu hạn chế các điều kiện mở khóa, không hạn chế cách mà UTXO này có thể được chi tiêu tiếp theo. Để thực hiện các điều khoản hạn chế, chúng ta cần suy nghĩ theo cách ngược lại: Tại sao kịch bản Bitcoin hiện tại không thể thực hiện các điều khoản hạn chế?
Nguyên nhân chủ yếu 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 suy" (introspection).
Nếu chúng ta có thể đạt được sự tự soi xét của 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ì chúng ta có thể thực hiện các điều khoản hạn chế.
Do đó, ý tưởng thiết kế của các điều khoản hạn chế chủ yếu xoay quanh việc làm thế nào để thực hiện sự nội tâm.
Dựa trên mã lệnh vs Dựa trên chữ ký
Ý tưởng đơn giản nhất là thêm một hoặc nhiều mã thao tác (, tức là một mã thao tác + nhiều tham số, hoặc nhiều mã thao tác khác nhau ), để trực tiếp đọc nội dung giao dịch. Điều này cũng dựa trên tư duy mã thao tác.
Một cách suy nghĩ khác là không cần phải đọc và kiểm tra nội dung của giao dịch trực tiếp trong tập lệnh, mà có thể sử dụng băm của nội dung giao dịch — nếu băm này đã được ký, thì chỉ cần sửa đổi trong tập lệnh, chẳng hạn như OP_CHECKSIG, để thực hiện việc kiểm tra chữ ký này, từ đó gián tiếp thực hiện việc tự kiểm tra giao dịch và các điều khoản hạn chế. Cách suy nghĩ này dựa trên 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 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 chọn lọc đối với một hoặc nhiều đầu vào hoặc đầu ra trong một giao dịch.
và SIGHASH của APO chỉ ký tên vào đầu ra, mà không ký tên vào phần đầu vào. Điều này có nghĩa là, sau khi giao dịch được ký theo cách APO, có thể trong