Tổng quan về mã lệnh OP_CHECKSIGFROMSTACK

Tác giả: Bitcoin Optech

Nguồn: https://bitcoinops.org/en/topics/op_checksigfromstack/

OP_CHECKSIGFROMSTACK (OP_CSFS) là một mã lệnh được sử dụng trên sidechain của ELEmentsProject.org và đôi khi được đề xuất để triển khai trên Bitcoin. Mã lệnh này có thể kiểm tra chữ ký cho bất kỳ thông điệp nào. Nó sẽ nhận ba tham số: một chữ ký, một thông điệp và một khóa công khai.

Các mã lệnh kiểm tra chữ ký hiện có trong Bitcoin, như OP_CHECKSIG, không cho phép chỉ định bất kỳ thông điệp nào; chúng xác minh chữ ký dựa trên dữ liệu được phát sinh từ giao dịch đang chạy mã lệnh kiểm tra chữ ký, cho phép họ xác minh chữ ký khớp với một khóa công khai và dữ liệu (khóa công khai và chữ ký) được tạo bởi private key đằng sau khóa công khai đó để ủy quyền cho khoản chi tiêu. Cơ chế này đủ mạnh để bảo vệ UTXO của Bitcoin, nhưng lại ngăn cản việc sử dụng chữ ký điện tử để xác minh các loại dữ liệu khác trong hệ thống Bitcoin. Bằng cách sử dụng OP_CSFS, chúng ta có thể xác minh chữ ký cho bất kỳ thông điệp nào, mang lại nhiều tính năng mới cho người dùng Bitcoin:

• Thanh toán cho chữ ký: Nếu Alice kiểm soát một private key có thể ký một giao dịch thanh toán cho Bob, thì Bob có thể sử dụng OP_CSFS để cam kết sẽ thanh toán cho chữ ký của Alice một cách không cần tin tưởng.

Tuy nhiên, gần đây, các giao thức liên quan đến thanh toán cho chữ ký thường giả định sử dụng "chữ ký thích ứng", điều này sẽ riêng tư hơn và chỉ cần sử dụng ít không gian block hơn.

• Ủy quyền: Alice có thể muốn ủy quyền cho Bob chi tiêu số tiền của cô ấy, nhưng không muốn tạo một giao dịch trên chuỗi để chuyển số tiền đó đến một địa chỉ đa chữ ký 1-of-2 của họ. Nếu Alice thiết kế kịch bản của mình để bao gồm loại ủy quyền này, cô ấy có thể đặt khóa công khai của Bob trong một thông điệp và sử dụng OP_CSFS để chứng minh rằng cô ấy đã ủy quyền cho khóa công khai đó được chi tiêu.

  Một giải pháp thay thế khác để đạt được cùng hiệu quả là graftroot, điều này sẽ riêng tư hơn, linh hoạt hơn và tiết kiệm không gian block hơn, nhưng yêu cầu một soft fork và cho đến nay chưa được quan tâm nhiều.

• Trọng tài: Trọng tài là những người đồng ý ký một thông điệp để chứng nhận kết quả của một sự kiện (như một trận thể thao). Sau đó, hai hoặc nhiều người dùng có thể gửi tiền vào một kịch bản sử dụng OP_CSFS, kịch bản này sẽ kích hoạt thanh toán dựa trên kết quả được trọng tài chứng nhận.

  Các nỗ lực gần đây để tổ chức hợp đồng trọng tài bao gồm "Hợp đồng nhật ký cẩn thận (DLCs)", những cái này sẽ riêng tư hơn và hiệu quả về không gian block hơn.

• Tiền ký quỹ để ngăn chặn giao dịch trùng lặp: Một nhà cung cấp dịch vụ có thể cam kết không bao giờ chi tiêu một UTXO nhất định của họ, để khuyến khích những người nhận thanh toán của họ chấp nhận các giao dịch chưa được xác nhận là thanh toán đáng tin cậy. Để chứng minh thiện chí của mình, nhà cung cấp dịch vụ này có thể sử dụng OP_CSFS để cam kết sẽ thanh toán một khoản tiền ký quỹ cho bất kỳ ai có thể chứng minh rằng họ đã tạo ra hai chữ ký khác nhau bằng cùng một khóa để chi tiêu cùng một UTXO.

  Cách sử dụng này có thể so sánh với "chữ ký chỉ hiển thị một lần", cho phép bất kỳ ai thấy hai chữ ký từ cùng một khóa có thể suy ra private key được sử dụng để tạo ra chúng, do đó có thể chi tiêu các tài sản khác được bảo vệ bởi khóa đó.

• Nội quán giao dịch: Nếu cùng một cặp khóa công khai và chữ ký hợp lệ với cả OP_CSFS và OP_CHECKSIG, điều này có nghĩa là thông điệp được truyền cho OP_CSFS giống hệt với chuỗi giao dịch được sử dụng ngầm định bởi OP_CHECKSIG (và các dữ liệu khác). Do đó, chúng ta có thể tận dụng điều này bằng cách đặt một bản sao của giao dịch chi tiêu đã được xác minh vào ngăn xếp kịch bản và sử dụng các mã lệnh khác để thực hiện một số kiểm tra trên giao dịch chi tiêu thực tế.

  Ví dụ, nếu OP_CSFS đã được triển khai vào năm 2015 và 2016, chúng ta chỉ cần viết một kịch bản xác minh để thực hiện các tính năng BIP65 OP_CHECKLOCKTIMEVERIFY (khóa thời gian tuyệt đối CLTV) và BIP112 OP_CHECKSEQUENCEVERIFY (khóa thời gian tương đối CSV), mà không cần thay đổi đồng thuận cụ thể.

  Trong tương lai, OP_CSFS cũng có thể được sử dụng để viết các kịch bản có thể triển khai các tính năng được đề xuất như SIGHASH_ANYPREVOUT và các mã lệnh khác được đề xuất (như OP_CHECKTEMPLATEVERIFY). Ngoài ra, OP_CSFS cũng có thể được sử dụng để tạo ra "điều khoản ràng buộc" - những điều khoản để hạn chế cách một nhóm Bitcoin được chi tiêu, chẳng hạn như "hợp đồng két sắt" có thể hạn chế các kịch bản công khai của đầu ra giao dịch, từ đó hạn chế rủi ro bị đánh cắp.

  Điểm mạnh của OP_CSFS là nó cung cấp nội quán hoàn toàn đối với giao dịch đang chạy kịch bản, và nó là một tính năng hoàn toàn phổ dụng. Nhược điểm của nó là nó yêu cầu thêm một bản sao đầy đủ của giao dịch vào ngăn xếp, có thể làm tăng đáng kể kích thước giao dịch. Ngược lại, một số mã lệnh nội quán chỉ dành cho một mục đích cụ thể như CLTV và CSV chỉ có chi phí rất nhỏ, nhưng mỗi khi thêm một mã lệnh nội quán mới lại cần một thay đổi đồng thuận, và vô hiệu hóa nó sẽ luôn có nguy cơ khiến một số người dùng mất tiền (ngay cả khi nó dường như không còn phổ biến nữa).