Khám phá các Giao ước: Cách mang khả năng lập trình gốc vào Bitcoin

Đệ quy:Đệ quy, không đệ quy

Trong số đó, đệ quy có nghĩa là: có một số hạn chế trong việc triển khai và nó cũng có thể được thực hiện thông qua các hạn chế. Bằng cách sử dụng một đầu ra để giới hạn đầu ra tiếp theo, giới hạn được thêm vào có thể vượt quá một giao dịch và đạt đến độ sâu giao dịch cao hơn.

Một số thiết kế mệnh đề hạn chế phổ biến bao gồm:

Việc thiết kế các điều khoản hạn chế trong Giao ước

Có thể thấy từ phần trước giới thiệu, tập lệnh Bitcoin hiện tại chủ yếu giới hạn các điều kiện để mở khóa và không giới hạn cách chi tiêu thêm UTXO. Để thực hiện các hạn chế, chúng ta phải nghĩ ngược lại:Tại sao tập lệnh Bitcoin hiện tại không thể thực hiện các hạn chế của Giao ước?

Lý do chính là do tập lệnh Bitcoin hiện tại không thể đọc được nội dung của giao dịch, tức là "sự xem xét nội tâm" của sự giao dịch .

Nếu chúng tôi có thể triển khai nội quan 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 tôi có thể triển khai các điều khoản hạn chế.

Do đó, ý tưởng thiết kế các mệnh đề hạn chế chủ yếu tập trung vào cách đạt được sự xem xét nội tâm.

Dựa trên mã và chữ ký

Ý tưởng đơn giản và thô sơ nhất là thêm một hoặc nhiều opcode (tức là một opcode + nhiều tham số hoặc nhiều opcode với các chức năng khác nhau) để đọc trực tiếp nội dung của giao dịch. Đây là ý tưởng dựa trên mã hoạt động.

Một cách suy nghĩ khác là thay vì trực tiếp đọc và kiểm tra nội dung của giao dịch trong tập lệnh, bạn có thể sử dụng hàm băm của nội dung giao dịch - nếu Hàm băm đã được ký, do đó, miễn là OP_CHECKSIG được sửa đổi trong tập lệnh để kiểm tra chữ ký, việc xem xét nội tâm và hạn chế giao dịch có thể được thực hiện gián tiếp. Ý tưởng này dựa trên thiết kế chữ ký. Chủ yếu bao gồm APO và OP_CSFS, v.v.

APO

SIGHASH_ANYPREVOUT (APO) là Một phương pháp chữ ký được đề xuất cho Bitcoin. Cách ký đơn giản nhất là cam kết cả đầu vào và đầu ra của giao dịch, nhưng Bitcoin cũng có một cách linh hoạt hơn, đó là SIGHASH, cam kết có chọn lọc về đầu vào hoặc đầu ra của giao dịch.

Phạm vi chữ ký hiện tại của SIGHASH và các kết hợp của nó cho đầu vào và đầu ra giao dịch (nguồn "Làm chủ Bitcoin, thứ 2"

Như minh họa trong hình trên, ngoại trừ rằng nó áp dụng cho tất cả dữ liệu Ngoài TẤT CẢ, phương thức chữ ký NONE chỉ áp dụng cho tất cả đầu vào chứ không áp dụng cho đầu ra; SINGLE dựa trên điều này và chỉ áp dụng cho đầu ra có cùng số thứ tự đầu vào. được kết hợp và xếp chồng với công cụ sửa đổi ANYONECANPAY. Cuối cùng, nó chỉ áp dụng cho một đầu vào

SIGHASH của APO chỉ ký vào phần đầu ra, không phải phần đầu vào. Các giao dịch được ký ở chế độ APO có thể được đính kèm vào bất kỳ UTXO nào đáp ứng các điều kiện. png">

Tính linh hoạt này là cơ sở lý thuyết để APO triển khai các mệnh đề hạn chế:

Có thể tạo trước một hoặc nhiều giao dịch

Chỉ có thể lấy được một chữ ký bằng cách xây dựng chữ ký từ thông tin của những giao dịch này giao dịch khóa công khai

Vì vậy, mọi tài sản được gửi đến địa chỉ khóa công khai đó chỉ có thể được sử dụng thông qua các giao dịch được tạo trước

Điều đáng lưu ý là vì khóa chung này không có khóa riêng tương ứng nên có thể đảm bảo rằng những tài sản này chỉ có thể được sử dụng thông qua các giao dịch được tạo trước. Sau đó, chúng ta có thể sử dụng các giao dịch được tạo trước này để Chỉ định nơi ở của tài sản để thực hiện các hạn chế

Chúng ta có thể hiểu rõ hơn bằng cách so sánh các hợp đồng thông minh của Ethereum: Thông qua hợp đồng thông minh, chúng ta có thể làm gì. đạt được là chỉ khi vượt qua một số điều kiện nhất định, chúng tôi mới có thể rút tiền từ địa chỉ hợp đồng, thay vì chi tiêu tùy tiện bằng chữ ký EOA. Từ quan điểm này, Bitcoin có thể đạt được hiệu quả này thông qua việc cải tiến cơ chế chữ ký.

Nhưng vấn đề với quy trình trên là có sự phụ thuộc vòng tròn trong tính toán, vì nội dung đầu vào cần phải được biết trước để ký trước và tạo giao dịch .

APO và SIGHASH_NOINPUT  Ý nghĩa của việc triển khai phương pháp chữ ký này là nó có thể giải quyết được vấn đề phụ thuộc vòng tròn này. Khi tính toán, bạn chỉ cần biết (nêu rõ) tất cả các giao dịch Chỉ cần xuất ra.

OP_CTV

OP_CHECKTEMPLATEVERIFY (CTV), Đó là BIP-119, áp dụng phương pháp cải tiến Opcode. Nó lấy hàm băm cam kết làm tham số và yêu cầu mọi giao dịch thực thi mã opcode đều chứa một tập hợp đầu ra khớp với cam kết đó. Thông qua CTV, người dùng Bitcoin sẽ được phép giới hạn cách họ sử dụng Bitcoin.

Đề xuất ban đầu được đưa ra dưới tên OP_CHECKOUTPUTSHASHVERIFY (COSHV) và trọng tâm ban đầu của nó là khả năng tạo các giao dịch kiểm soát tắc nghẽn, do đó, rất có sự quan tâm đến những lời chỉ trích về đề xuất cũng tập trung vào thực tế là nó không đủ chung chung và quá cụ thể đối với các trường hợp sử dụng kiểm soát tắc nghẽn.

Trong trường hợp sử dụng kiểm soát tắc nghẽn được đề cập ở trên, người gửi Alice có thể tạo 10 kết quả đầu ra và băm 10 kết quả đầu ra này, đồng thời sử dụng Tóm tắt được tạo để tạo tập lệnh tapleaf chứa COSHV. Alice cũng có thể sử dụng khóa chung của người tham gia để tạo khóa nội bộ Taproot, cho phép họ cộng tác chi tiêu mà không tiết lộ đường dẫn tập lệnh Taproot.

Sau đó, Alice đưa cho mỗi người nhận một bản sao của tất cả 10 kết quả đầu ra để mỗi người có thể xác minh giao dịch thiết lập của Alice. Sau này, khi họ muốn chi tiêu khoản thanh toán, một trong hai người có thể tạo một giao dịch chứa kết quả đầu ra đã hứa.

Trong suốt quá trình, khi Alice tạo và gửi giao dịch thiết lập, Alice có thể gửi giao dịch đó qua các phương thức liên lạc không đồng bộ hiện có, chẳng hạn như email hoặc ổ đĩa đám mây. đầu ra. Điều này có nghĩa là người nhận không cần phải trực tuyến hoặc tương tác với nhau.

(Nguồn: https://bitcoinops.org/en/newsletters/2019/05/29/#proposes-transaction-output-commitments)

Tương tự như APO, địa chỉ cũng có thể được xây dựng dựa trên điều kiện chi tiêu và "khóa" có thể được thực hiện theo nhiều cách khác nhau, bao gồm thêm các khóa khác, khóa thời gian và logic có thể kết hợp.

(Nguồn: https://twitter .com/OwenKemeys/status/1741575353716326835)

CTV đề xuất trên cơ sở này rằng nó có thể kiểm tra xem giao dịch chi tiêu sau khi băm có nhất quán hay không với Đối sánh được xác định sử dụng dữ liệu giao dịch làm chìa khóa để mở khóa "khóa".

Chúng ta có thể mở rộng ví dụ trên với 10 người nhận và người nhận có thể đặt thêm khóa địa chỉ của nó thành đã ký nhưng không phát sóng tx được gửi tới lô địa chỉ người nhận tiếp theo, v.v., tạo thành cấu trúc cây như trong hình bên dưới. Alice có thể thực hiện thay đổi số dư tài khoản liên quan đến nhiều người dùng chỉ bằng cách sử dụng 1 không gian khối utxo trên chuỗi.

Nguồn: https://twitter.com/OwenKemeys/status/1741575353716326835

Và nếu một trong các lá là kênh sét, đó là kho lạnh hay là phương thức thanh toán khác? Khi đó, cây này sẽ mở rộng từ cây chi tiêu một chiều, đa cấp thành cây chi tiêu đa chiều, đa cấp, các kịch bản mà nó có thể hỗ trợ sẽ phong phú và linh hoạt hơn.

Nguồn: https://twitter.com/OwenKemeys/status/1741575353716326835

CTV đã trải qua năm 2019 kể từ khi được đề xuất Nó được đổi tên từ COSHV vào năm 2020, được gán BIP-119 vào năm 2020 và nổi lên như một ngôn ngữ lập trình Sapio để tạo hỗ trợ cho các hợp đồng CTV vào năm 2022 và 23, nó đã nhận được rất nhiều cuộc thảo luận, cập nhật và tranh luận về kế hoạch kích hoạt của mình. từ cộng đồng. Hiện tại, đây vẫn là một trong những đề xuất nâng cấp soft fork được thảo luận rất nhiều trong cộng đồng.

OP_CAT

OP_CAT Như đã giới thiệu ở phần đầu, nó cũng là một đề xuất nâng cấp hiện đang thu hút nhiều sự chú ý thực hiện chức năng nối (concatenante) hai phần tử trong ngăn xếp. Mặc dù có vẻ đơn giản nhưng OP_CAT có thể rất linh hoạt để triển khai nhiều chức năng trong tập lệnh.

Ví dụ trực tiếp nhất là các phép toán liên quan đến cây merkle. Cây Merkle có thể hiểu là hai phần tử đầu tiên được ghép nối rồi sau đó được băm. Hiện tại, có các mã hoạt động băm như OP_SHA256 trong tập lệnh Bitcoin, vì vậy nếu OP_CAT có thể được sử dụng để ghép hai phần tử, thì chức năng xác minh của cây merkle có thể được triển khai trong tập lệnh và ở một mức độ nhất định, xác minh ứng dụng khách nhẹ được cung cấp . khả năng.

Cơ sở triển khai khác cũng bao gồm các cải tiến đối với chữ ký Schnorr: các điều kiện chữ ký chi tiêu của tập lệnh có thể được đặt thành việc ghép khóa chung của người dùng và số không công khai; người ký muốn ký một giao dịch khác để tiêu tiền ở nơi khác, anh ta phải sử dụng cùng một số nonce và rò rỉ khóa riêng. Nghĩa là, cam kết về nonce được thực hiện thông qua OP_CAT, qua đó đảm bảo tính hợp lệ của giao dịch đã ký.

Các kịch bản ứng dụng khác của OP_CAT bao gồm: Bistream, chữ ký cây, chữ ký Lamport kháng lượng tử, vault, v.v.

Bản thân OP_CAT không phải là một tính năng mới. Nó tồn tại trong phiên bản đầu tiên của Bitcoin, nhưng nó có thể bị khai thác bởi các cuộc tấn công. Nó đã bị cấm trong. 2010. Ví dụ: việc sử dụng lại OP_DUP và OP_CAT có thể dễ dàng làm cho ngăn xếp nút đầy đủ phát nổ khi xử lý các tập lệnh như vậy, hãy xem bản demo này.

Nhưng liệu vấn đề nổ ngăn xếp được đề cập ở trên có xảy ra nếu OP_CAT được bật lại ngay bây giờ không? Vì đề xuất OP_CAT hiện tại chỉ liên quan đến việc kích hoạt nó trong tapscript, giới hạn mỗi phần tử ngăn xếp không quá 520 byte nên vấn đề bùng nổ ngăn xếp trước đó sẽ không phát sinh. Cũng có một số nhà phát triển cho rằng lệnh cấm trực tiếp của Satoshi đối với OP_CAT có thể quá khắc nghiệt. Tuy nhiên, do tính linh hoạt của OP_CAT, hiện tại một số tình huống ứng dụng có thể dẫn đến lỗ hổng vẫn chưa thể được khắc phục.

Vì vậy, xét đến các kịch bản ứng dụng và rủi ro tiềm ẩn, OP_CAT gần đây đã nhận được rất nhiều sự chú ý và cũng đã có những đánh giá PR. Đây là một trong những bản nâng cấp phổ biến nhất. đề xuất hiện nay.

Kết luận

"Kỷ luật tự giác mang lại tự do", từ Như có thể thấy từ phần giới thiệu ở trên,các điều khoản hạn chế có thể được triển khai trực tiếp trong tập lệnh Bitcoin để hạn chế việc chi tiêu thêm cho các giao dịch, từ đó đạt được các quy tắc giao dịch tương tự như hiệu ứng hợp đồng thông minh. So với các phương pháp ngoài chuỗi như BitVM, phương pháp lập trình này có thể được xác minh nguyên bản hơn trên Bitcoin và cũng có thể cải thiện các ứng dụng trên chuỗi chính (kiểm soát tắc nghẽn), các ứng dụng ngoài chuỗi (kênh trạng thái) và các ứng dụng mới khác hướng dẫn ứng dụng (đặt cược hình phạt, v.v.).

Nếu công nghệ triển khai các điều khoản hạn chế có thể được kết hợp với một số nâng cấp cơ bản, nó sẽ giải phóng thêm tiềm năng của khả năng lập trình. Ví dụ: đề xuất nhà điều hành 64 bit đang được xem xét gần đây có thể được kết hợp thêm với OP_TLUV được đề xuất hoặc các ràng buộc khác có thể được lập trình dựa trên số lượng satoshi đầu ra của giao dịch.

Tuy nhiên, các điều khoản hạn chế cũng có thể dẫn đến một số hành vi lạm dụng hoặc lỗ hổng ngoài ý muốn, vì vậy cộng đồng cũng thận trọng hơn về điều này. Ngoài ra, việc nâng cấp các điều khoản hạn chế cũng yêu cầu nâng cấp phần mềm các quy tắc đồng thuận. Do tình trạng này xảy ra trong quá trình nâng cấp taproot, các nâng cấp liên quan đến các hạn chế cũng có thể mất thời gian để hoàn thành.