Skip to main content

Đầu vào tham chiếu (CIP31)

tip

Đề xuất này đã được chấp thuận và được triển khai trong bản nâng cấp Hardfork Vasil cùng với 3 đề xuất khác là CIP 32, 33, 40. Đây là các đề xuất rất quan trọng giúp nâng cao hiệu suất của mạng lưới Cardano trong kỷ nguyên Basho.

Tóm tắt​

Đề xuất này giới thiệu một loại Đầu vào mới, Đầu vào Tham chiếu (Reference inputs), cho phép đọc dữ liệu Đầu ra mà không cần sử dụng/tiêu dùng chúng. Điều này sẽ tạo điều kiện thuận lợi cho việc truy cập thông tin lưu trữ trên blockchain mà không cần phải sử dụng giao dịch và tạo ra UTXO mới.

Vấn đề​

Các Giao dịch Đầu ra có chứa thông tin dữ liệu (Datums). Đây là một cách để lưu trữ và dùng để truy cập thông tin trên blockchain. Tuy nhiên, chúng khá hạn chế trong nhiều trường hợp. Đáng chú ý nhất là để truy cập thông tin chứa trong giao dịch, bạn phải sử dụng / chi tiêu Đầu ra nếu giao dịch có chứa dữ liệu (datum) đính kèm.

Điều này tạo ra một số vấn đề không mong muốn:

  1. Khi một Đầu ra được sử dụng để truy cập thông tin, nó lại tạo ra một Đầu ra mới. Nếu một người dùng khác muốn xem dữ liệu , họ không thể sử dụng lại Đầu ra cũ (đã mất), mà phải sử dụng Đầu ra mới (và họ chi biết về Đầu ra mới ở khối (block) tiếp theo). Điều này sẽ khiến các ứng dụng chỉ có thể thực hiện được một "hoạt động" trên mỗi khối.
  2. Muồn truy cập thông tin dữ liệu, bạn phải sử dụng Đầu ra. Điều này có nghĩa là vừa phải liên quan đến tiền và còn có thể có các điều kiện khác phải được đáp ứng nếu muốn sử dụng giao dịch (nếu giao dịch đó có chứa script). Điều này là quá khó khăn, bất tiện và rát tốn kém chi phí.

Chúng tôi muốn đề xuất một cơ chế để truy cập thông tin Datums mà không gặp phải những vấn đề đã nêu.

Các trường hợp ứng dụng​

Dưới đây là một số trường hợp mà chúng tôi hy vọng điều này sẽ hữu ích.

  1. Kiểm tra trạng thái (dữ liệu hoặc giá trị bị khóa) của một ứng dụng trên chuỗi mà không cần phải sử dụng Đầu ra, ví dụ: kiểm tra trạng thái hiện tại của trạng thái stablecoin.
  2. Các nhà cung cấp dữ liệu trên chuỗi lưu trữ dữ liệu trong Đầu ra, và chúng có thể được tham chiếu bởi nhiều tập lệnh khác.
  3. Cùng với đề xuất Dữ liệu nội tuyến (Inline Datums - CIP32), sẽ tạo một UTXO duy nhất với dữ liệu cso thể được sử dụng trong nhiều giao dịch tiếp theo, nhưng chỉ phải trả chi phí cho việc gửi dữ liệu đó một lần.

Cho phép cải tiến hơn nữa​

Đề xuất này được thiết kế song song với hai đề xuất khác sử dụng các tập lệnh tham chiếu, CIP-32 (Dữ liệu nội tuyến) và CIP-33 (Tập lệnh tham chiếu). Đánh giá đầy đủ về giá trị của đề xuất này cần tính đến thực tế rằng đây là đề xuất hỗ trợ cho các đề xuất khác.

Làm rõ giải pháp​

Đầu vào tham chiếu​

Chúng tôi giới thiệu một loại Đầu vào giao dịch mới, một loại Đầu vào tham chiếu. Người tạo ra giao dịch có thể chỉ định Đầu vào là Đầu vào bình thường (để sử dụng) hoặc Đầu vào tham chiếu.

Đầu vào tham chiếu (reference input) là một Đầu vào giao dịch (transaction input), được liên kết với Giao dịch Đầu ra (transaction output) cụ thể như bình thường, nhưng nó tham chiếu đến Đầu ra thay vì sử dụng Đầu ra. Đó là:

  • Đầu ra được tham chiếu đến phải còn tồn tại trong bộ UTXO.
  • Bất kỳ giá trị nào trên Đầu ra được tham chiếu đến sẽ không được xem xét khi cân bằng giá trị giao dịch.
  • Các điều kiện sử dụng cho các Đầu ra được tham chiếu không được kiểm tra, cũng như không yêu cầu trình diện bằng chứng. Tức là trình xác thực sẽ không bắt buộc phải vượt qua (cũng không phải bản thân các tập lệnh hoặc trình xác nhận lại bắt buộc phải trình diện) và chữ ký không bắt buộc đối với Đầu ra pubkey.
  • Đầu ra được tham chiếu không bị xóa khỏi bộ UTXO nếu giao dịch xác thực.
  • Các Đầu vào tham chiếu được hiển thị cho tất cả các tập lệnh (scripts).

Để rõ ràng, hai hành vi sau đây sẽ không thay đổi theo đề xuất này:

  1. Các giao dịch phải sử dụng ít nhất một Đầu ra. [Xem thêm ^1]
  2. Việc sử dụng một Đầu ra yêu cầu phải kiểm tra các điều kiện sử dụng. [Xem thêm ^2]

[^ 1]: Hạn chế này đã tồn tại và rất quan trọng. Có vẻ như không cần thiết, vì các giao dịch luôn phải trả phí và phí phải đến từ một nơi nào đó, nhưng về nguyên tắc, phí có thể được thanh toán thông qua rút tiền thưởng, vì vậy yêu cầu sử dụng UTXO là có liên quan. 

[^ 2]: Nghĩa là, đề xuất này không thay đổi Đầu ra hoặc sử dụng cho các Đầu ra, thay vào đó nó bổ sung một cách mới để tham chiếu đến Đầu ra.

Script context (Ngữ cảnh tệp lệnh)​

Tập lệnh (Script) được truyền thông tin về các giao dịch thông qua Ngữ cảnh tập lệnh. Do đó, Ngữ cảnh tập lệnh cần được tăng cường để chứa thông tin về các Đầu vào tham chiếu.

Việc thay đổi Ngữ cảnh tập lệnh sẽ yêu cầu phiên bản ngôn ngữ Plutus mới trong sổ cái để hỗ trợ giao diện mới. Thay đổi trong giao diện mới là: một trường mới được thêm vào cấu trúc chứa danh sách các Đầu vào tham chiếu.

Giao diện cho các phiên bản cũ của ngôn ngữ sẽ không bị thay đổi. Các tập lệnh có phiên bản cũ không thể được sử dụng trong các giao dịch bao gồm Đầu vào tham chiếu, việc cố gắng làm như vậy sẽ không thành công trong quá trình xác thực giao dịch ở giai đoạn 1.

Dữ liệu bổ xung​

Ngày nay, các giao dịch có thể chứa các dữ liệu bổ sung không cần thiết để xác thực. Hiện tại, tất cả các dữ liệu bổ sung phải là hình ảnh trước của các băm (hash) dữ liệu xuất hiện trong Đầu ra. Chúng tôi thay đổi điều này để các dữ liệu bổ sung cũng có thể là hình ảnh trước của các băm (hash) dữ liệu xuất hiện trong Đầu vào tham chiếu. [Xem thêm ^ 3]

Lưu ý rằng cơ chế hiện có bao gồm hàm băm (hash) của cấu trúc dữ liệu bổ sung trong nội dung giao dịch, do đó kẻ tấn công không thể tước bỏ các dữ liệu bổ sung mà không làm mất hiệu lực chữ ký giao dịch.

[^ 3]: Tất nhiên bắt buộc phải có hình ảnh trước của các băm (hash) dữ liệu xuất hiện trong các Đầu vào đã sử dụng.

CDDL​

CDDL cho phần chính của giao dịch sẽ thay đổi thành như sau để phản ánh trường mới.

transaction\_body =
    { 0 : set<transaction\_input>    ; inputs
    ...      
    , ? 16 : set<transaction\_input> ; reference inputs
    }

Cơ sở lý luận​

Ý tưởng chính của đề xuất này là sử dụng các UTXO để truyền tải thông tin. Nhưng UTXO hiện không phù hợp để phân phối thông tin. Do tính cục bộ (locality), chúng ta phải bao gồm các Đầu ra mà chúng ta sử dụng trong giao dịch và cách duy nhất chúng ta phải làm là sử dụng chúng - và Đầu ra đã sử dụng sau đó không thể được tham chiếu bởi bất kỳ thứ gì khác. Nói một cách khác: Đầu ra giống như tài nguyên, nhưng thông tin không giống như tài nguyên.

Giải pháp là thêm một cách để kiểm tra ("tham chiếu") Đầu ra mà không cần sử dụng chúng. Điều này cho phép các Đầu ra thực hiện nhiệm vụ kép như các thùng chứa tài nguyên (đối với giá trị mà chúng mang theo) và thùng chứa thông tin (đối với dữ liệu mà chúng mang theo).

Yêu cầu​

Có một số giả định về yêu cầu cần được đáp ứng

  • Thuyết quyết định
    • Phải có thể dự đoán chính xác việc thực thi các tập lệnh, với giao dịch.
  • Tính cục bộ
    • Tất cả dữ liệu liên quan đến xác thực giao dịch phải được bao gồm trong giao dịch hoặc Đầu ra mà nó sử dụng (hoặc tham chiếu).
  • Không can thiệp
    • Trong chừng mực có thể, các giao dịch không nên can thiệp vào giao dịch khác. Ngoại lệ chính là khi các giao dịch sử dụng tài nguyên mà các giao dịch khác muốn (thường bằng cách sử dụng các mục nhập UTXO).
  • Bảo vệ Relay
    • Hệ thống không thể bị tấn công (ví dụ cho phép đọc dữ liệu không mong muốn) bằng cách truyền lại lưu lượng cũ.
  • Các biện pháp khuyến khích kiểm soát lưu trữ và thu gom rác
    • Dung lượng lưu trữ mà hệ thống yêu cầu phải có các biện pháp kiểm soát để ngăn nó làm quá tải các node và lý tưởng nhất là nên có các biện pháp khuyến khích để thu nhỏ dung lượng lưu trữ được sử dụng theo thời gian.
  • Bộ nhớ được tối ưu hóa
    • Hệ thống phải phù hợp với các giải pháp lưu trữ tối ưu hóa.
  • Truyền dữ liệu thành các tập lệnh
    • Các tập lệnh phải có một cách để quan sát dữ liệu.
  • Hỗ trợ công cụ và thư viện
    • Không quá khó để các công cụ và thư viện làm việc với hệ thống mới.
  • Hydra
    • Hệ thống phải có thể sử dụng được mà không ảnh hưởng đến nhu cầu của Hydra, chẳng hạn như xử lý song song các phần độc lập của biểu đồ giao dịch.

Đầu vào tham chiếu đáp ứng các yêu cầu này, chủ yếu bằng cách kế thừa chúng từ các thuộc tính tương ứng của UTXO.

  • Việc tham chiếu Đầu ra vẫn yêu cầu Đầu ra phải được trình bày như một phần của giao dịch và không được sử dụng, vì vậy tính xác định được bảo toàn.
  • Đầu ra tham chiếu xuất hiện dưới dạng Đầu vào giao dịch, do đó, tính cục bộ được giữ nguyên.
  • Đầu ra có thể được tham chiếu nhiều lần. Vì vậy, chúng không bị can thiệp ngay cả khi sử dụng nhiều tham chiếu. Xung đột chỉ có thể xảy ra nếu Đầu ra thực sự được sử dụng.
  • Tính năng bảo vệ truyền lại được kế thừa vì một giao dịch luôn phải sử dụng ít nhất một UTXO và các UTXO chỉ có thể được sử dụng một lần.
  • Kiểm soát lưu trữ được kế thừa từ kiểm soát bộ UTXO, thông qua các ưu đãi giá trị UTXO tối thiểu. Dữ liệu có thể được "gỡ bỏ" bằng cách sử dụng dữ liệu Đầu vào (thay vì tham chiếu nó), lấy lại giá trị UTXO tối thiểu.
  • Bộ nhớ được tối ưu hóa được kế thừa trực tiếp từ công việc cải thiện bộ nhớ UTXO.
  • Truyền dữ liệu thành các tập lệnh hoạt động tự động vì các tập lệnh có thể nhìn thấy các Đầu vào giao dịch.
  • Các công cụ và thư viện sẽ chỉ phải xử lý một loại Đầu vào giao dịch mới và trừ khi họ quan tâm đến các tập lệnh, họ có thể hoàn toàn bỏ qua chúng.
  • Hydra có thể làm việc với các Đầu vào tham chiếu (xem bên dưới).

Tại sao UTXOs?​

Có nhiều cách tiếp cận khác nhau để tăng cường cho Cardano khả năng lưu trữ và truy xuất dữ liệu dễ dàng hơn. Tất cả những thứ này đều yêu cầu một số loại hệ thống giống như tài nguyên để lưu trữ được sử dụng cho dữ liệu. Lập luận chính ủng hộ cách tiếp cận Đầu vào tham chiếu là nó sử dụng lại hệ thống giống như tài nguyên hiện có của chúng ta: UTXOs.

Như chúng ta đã thấy ở trên, hầu hết các yêu cầu được đáp ứng miễn phí. Bất kỳ cách tiếp cận nào khác sẽ cần các giải pháp mới cho những vấn đề này.

Như một ví dụ ngắn gọn, giả sử chúng ta muốn triển khai lưu trữ dữ liệu dưới dạng kho lưu trữ dữ liệu được băm (hash), lập chỉ mục theo chuỗi (một đề xuất mà chúng ta đã xem xét).

Sau đó, chúng ta sẽ cần trả lời rất nhiều câu hỏi:

  • Dữ liệu được truy cập và lấy ra như thế nào? Đây có phải là các hoạt động trạng thái không? Điều này có làm cho thứ tự giao dịch trở nên quan trọng hơn, đe dọa tính xác định không?
  • Việc sử dụng bộ nhớ được kiểm soát như thế nào? Mọi người có trả tiền để lưu trữ dữ liệu không? Họ trả tiền trong một khoảng thời gian cố định hay vĩnh viễn? Làm thế nào là dữ liệu được gỡ bỏ?
  • Việc lưu trữ sẽ được triển khai như thế nào? Điều này sẽ ảnh hưởng đến việc sử dụng bộ nhớ nút như thế nào?
  • Các tập lệnh sẽ truy cập dữ liệu trong cửa hàng như thế nào?
  • Các công cụ sẽ tương tác và trực quan hóa cửa hàng và những thay đổi đối với cửa hàng đó như thế nào?

Chúng ta nên trình bày thông tin vào script như thế nào?​

Tập lệnh chắc chắn cần phải xem Đầu vào tham chiếu. Nhưng chúng ta có ít nhất hai tùy chọn về cách chúng ta thể hiện điều này trong Ngữ cảnh tập lệnh: đặt các Đầu vào tham chiếu vào trường riêng của chúng; hoặc bao gồm chúng với các Đầu vào khác, nhưng gắn thẻ chúng một cách thích hợp.

Giữ chúng tách biệt có vẻ khôn ngoan vì có khả năng gây nhầm lẫn Đầu vào tham chiếu cho Đầu vào bình thường. Đó sẽ là một lỗi lập trình khá nguy hiểm, vì nó có thể khiến tập lệnh tin rằng ví dụ như Đầu ra đã được sử dụng trong khi thực tế nó chỉ được tham chiếu.

Chúng ta cũng có câu hỏi là phải làm gì với các tập lệnh cũ. Chúng ta thực sự không thể trình bày thông tin về Đầu vào tham chiếu cho họ một cách trung thực: việc trình bày chúng dưới dạng Đầu vào sử dụng sẽ rất sai lệch và không có nơi nào khác để đưa chúng vào. Chúng ta có thể bỏ qua thông tin hoàn toàn, nhưng điều này nguy hiểm theo một cách khác. Việc bỏ sót thông tin có thể khiến các kịch bản đưa ra các giả định về giao dịch là không đúng sự thật; vì lý do này, chúng ta không muốn âm thầm bỏ qua thông tin như một nguyên tắc chung. Điều đó khiến chúng ta chỉ có một lựa chọn: từ chối các giao dịch trong đó chúng tôi sẽ phải trình bày thông tin về Đầu vào tham chiếu cho các tập lệnh cũ.

Truy cập dữ liệu của Đầu vào tham chiếu​

Hiện tại, đề xuất này có một chút tiện ích hạn chế, vì dữ liệu trong Đầu ra chỉ là hàm băm (hash) và bên sử dụng được yêu cầu tự tìm và cung cấp hình ảnh trước. Do đó, đề xuất CIP-32 cho các Dữ liệu nội tuyến là bổ sung, vì nó cho phép các UTXO tự mang dữ liệu thực thay vì một hàm băm (hash).

Trước mắt (hoặc nếu CIP-32 không được triển khai), chúng ta vẫn muốn người dùng có thể cung cấp các dữ liệu tương ứng với các băm (hash) dữ liệu trong các Đầu ra tham chiếu, để ít nhất có thể tham chiếu dữ liệu, mặc dù một cách vụng về. Giải pháp đơn giản nhất ở đây là sử dụng lại cơ chế hiện có để cung cấp hình ảnh trước của hàm băm (hash) dữ liệu xuất hiện trong Đầu ra.

Việc cung cấp hình ảnh trước băm (hash) dữ liệu vẫn là tùy chọn, vì có những lý do để sử dụng Đầu vào tham chiếu ngay cả khi không nhìn vào dữ liệu, ví dụ: để xem giá trị trong Đầu ra.

Truy cập giá trị bị khóa trong Đầu ra​

Động lực của đề xuất này chủ yếu yêu cầu xem xét các dữ liệu Đầu ra. Nhưng Đầu vào tham chiếu cho phép chúng ta làm được nhiều việc hơn: chúng cho phép chúng ta xem xét giá trị bị khóa trong Đầu ra (tức là nó chứa bao nhiêu Ada hoặc các token khác).

Đây thực sự là một tính năng rất quan trọng. Vì bất kỳ ai cũng có thể khóa Đầu ra bằng bất kỳ địa chỉ nào, nên các địa chỉ không hữu ích cho việc xác định các Đầu ra cụ thể trên chuỗi và thay vào đó, chúng tôi thường dựa vào việc tìm kiếm các token cụ thể trong giá trị bị khóa bởi Đầu ra. Do đó, nếu một tập lệnh quan tâm đến việc tham chiếu đến dữ liệu được gắn với một Đầu ra cụ thể , nó có thể sẽ muốn xem xét giá trị bị khóa trong Đầu ra.

Ví dụ, một nhà cung cấp tiên tri sẽ cần phải phân biệt Đầu ra mà họ tạo (với dữ liệu tốt) với Đầu ra do đối thủ tạo ra (với dữ liệu xấu). Họ có thể làm điều này với token, miễn là sau đó các tập lệnh có thể nhìn thấy token!

Hydra​

Chúng ta muốn các Đầu vào tham chiếu có thể sử dụng được bên trong các đầu Hydra. Điều này làm dấy lên lo lắng: vì Hydra xử lý song song các phần độc lập của đồ thị giao dịch, điều gì sẽ xảy ra nếu nó chấp nhận một giao dịch tham chiếu đến đầu ra và một giao dịch sử dụng đầu ra, nhưng sau đó giao dịch đầu tiên được đưa vào trạm kiểm soát trước giao dịch thứ hai?

May mắn thay, Hydra đã phải đối mặt với các xung đột chi tiêu gấp đôi kiểu này (mặc dù trong giao thức gốc, điều này dẫn đến một từ-bỏ-cam-kết). Đề xuất này chỉ đơn giản đưa ra một loại xung đột mới, xung đột tham chiếu-chi tiêu. Xung đột chi tiêu tham chiếu phải được xử lý theo cùng một cơ chế được sử dụng để xử lý xung đột chi tiêu gấp đôi.

Kiểm soát tham chiếu​

Một điều mà người dùng có thể muốn làm là kiểm soát ai có thể tham chiếu Đầu ra. Ví dụ: một nhà cung cấp oracle có thể muốn chỉ cho phép một giao dịch tham chiếu đến một Đầu ra cụ thể nếu giao dịch đó cũng trả cho họ một số tiền.

Các Đầu vào tham chiếu đơn thuần sẽ không cung cấp bất kỳ cách nào để thực hiện việc này. Một cơ chế khác sẽ được yêu cầu, nhưng không có sự thống nhất về thiết kế nên là gì, vì vậy nó hiện nằm ngoài phạm vi của đề xuất này. Dưới đây là tóm tắt ngắn gọn về một số lựa chọn và lý do tại sao chúng không phải là lựa chọn rõ ràng.

Một vấn đề quan trọng là sự lựa chọn để kiểm soát việc tham chiếu phải nằm ở người tạo ra Đầu ra, chứ không phải người sử dụng . Do đó, chúng ta phải bao gồm một số loại thay đổi đối với Đầu ra để người tạo có thể ghi lại các yêu cầu của họ.

Kiểm tra Đầu vào​

"Kiểm tra Đầu vào" giống như một Đầu vào tham chiếu ngoại trừ việc các điều kiện sử dụng được kiểm tra. Đó là, nó hoạt động như một bằng chứng rằng bạn có thể sử dụng Đầu vào, nhưng trên thực tế không sử dụng nó.

Vì Đầu vào kiểm tra khiến các tập lệnh trình xác thực được chạy, có vẻ như chúng có thể cho phép chúng tôi kiểm soát việc tham chiếu. Có hai nếp nhăn:

  • Cùng một tập lệnh sẽ được sử dụng cho cả tham chiếu và sử dụng, làm quá tải ý nghĩa của tập lệnh trình xác nhận. Tuy nhiên, điều này vẫn có thể sử dụng được vì Redeemer có thể được sử dụng để cho biết hành động nào đang được thực hiện.
  • Chúng ta sẽ cần gắn cờ trên Đầu ra để nói rằng "Đầu ra này không thể được tham chiếu, mà chỉ được kiểm tra". Chính xác điều này sẽ trông như thế nào là một câu hỏi mở, có lẽ nó phải đủ lớn để kiểm soát tất cả các cách có thể có trong đó một Đầu ra có thể được sử dụng (trong đó sẽ có ba).

Điều kiện tham chiếu​

"Điều kiện tham chiếu" có nghĩa là thêm một trường mới vào Đầu ra để cho biết Đầu ra có thể được tham chiếu trong những điều kiện nào. Đây có thể là toàn bộ địa chỉ bổ sung, vì các điều kiện có thể là bất kỳ điều kiện sử dụng thông thường nào (khóa công khai hoặc chứng kiến ​​tập lệnh).

Tuy nhiên, điều này sẽ làm cho Đầu ra về cơ bản lớn hơn và phức tạp hơn.

Công việc liên quan​

"Đầu vào tham chiếu" rất giống với "Đầu vào dữ liệu" của Ergo. Chúng tôi đã chọn đặt tên khác cho chúng vì "dữ liệu" đã là một thuật ngữ được sử dụng rộng rãi và có nguy cơ nhầm lẫn. Chúng tôi cũng có thể sẽ giới thiệu một thuật ngữ Đầu vào khác trong tương lai.

Nguồn bài viết tại đây

Picture