Dữ liệu nội tuyến (CIP32)
Đề 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 31, 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
Chúng tôi đề xuất đính kèm Dữ kiện (datums) gốc với Kết quả đầu ra thay vì chỉ lưu thông tin mã hóa băm (hash) của dữ liệu. Điều này cho phép việc giao tiếp giữa Người dùng với nhau đơn giản và dễ dàng hơn. Đề xuất này được đặt tên là Dữ liệu nội tuyến (Inline datums)
Nội dung
Tóm lược
Chúng ta đề xuất cho phép bản thân datum được gắn vào đầu ra thay vì hàm băm datum. Điều này sẽ cho phép giao tiếp đơn giản hơn nhiều về các giá trị datum giữa những người dùng.
Mục tiêu
Về mặt khái niệm, datum là các mẩu dữ liệu được đính kèm với đầu ra. Tuy nhiên, trên thực tế, datum được triển khai bằng cách gắn băm của datum vào đầu ra và yêu cầu giao dịch chi tiêu cung cấp datum thực tế.
Điều này khá bất tiện cho người dùng. Dữ liệu có xu hướng đại diện cho kết quả tính toán do bên tạo ra đầu ra thực hiện và do đó hầu như không có khả năng bên chi tiêu sẽ biết dữ liệu mà không liên lạc với bên tạo. Điều đó có nghĩa là datum phải được truyền đạt giữa các bên off-chain hoặc được truyền đạt on-chain bằng cách đưa nó vào bản đồ nhân chứng của giao dịch tạo ra đầu ra ("datums bổ sung"). Điều này cũng gây bất tiện cho bên chi tiêu, những người phải theo dõi toàn bộ chuỗi để phát hiện ra nó.
Sẽ thuận tiện hơn nhiều nếu chỉ đặt datum chính nó vào một đầu ra, đó là những gì chúng ta đề xuất.
Trường hợp sử dụng
Chúng ta hy vọng rằng, miễn là chúng ta có thể mang lại chi phí đủ thấp, một tỷ lệ lớn các nhà phát triển dapp sẽ sử dụng tính năng này, vì nó sẽ đơn giản hóa đáng kể hệ thống của họ.
Sự chỉ rõ
Đầu ra giao dịch được thay đổi để trường datum có thể chứa hàm băm hoặc datum ("datum nội tuyến").
Giá trị UTXO tối thiểu cho đầu ra có datum nội tuyến tùy thuộc vào kích thước của datum, tuân theo tham số giao thức coinsPerUTxOWord .
Khi một đầu ra có datum nội tuyến được chi tiêu, giao dịch chi tiêu không cần cung cấp chính datum đó.
Script context
Tập lệnh được truyền thông tin về giao dịch thông qua Script context. Do đó, Script context cần được tăng cường để chứa thông tin về datum nội tuyến.
Việc thay đổi Script context sẽ yêu cầu phiên bản ngôn ngữ Plutu mới trong sổ cái để hỗ trợ giao diện mới.
Có hai thay đổi trong phiên bản mới của giao diện:
- Trường datum trên đầu ra giao dịch có thể là hàm băm hoặc datum thực tế.
- Trường datum trên đầu vào giao dịch có thể là hàm băm hoặc datum thực tế.
Giao diện cho các phiên bản cũ của ngôn ngữ sẽ không được thay đổi. Không thể sử dụng các tập lệnh có phiên bản cũ trong các giao dịch bao gồm datum nội tuyến, cố gắng làm như vậy sẽ là lỗi xác thực giao dịch giai đoạn 1.
CDDL
CDDL cho đầu ra giao dịch sẽ thay đổi như sau để phản ánh giải pháp thay thế mới.
giao dịch_đầu ra =
[ Địa chỉ
, số lượng : giá trị
, ? datum : $hash32 / plutus_data
]
VIỆC CẦN LÀM: có nên sản xuất riêng cho datum-hash-or-datum không? Có cần phải được gắn thẻ?
Cơ sở lý luận
Ý tưởng chính của đề xuất này chỉ đơn giản là khôi phục tình huống đơn giản về mặt khái niệm trong đó datum được gắn vào đầu ra. Trước đây, đây là cách mà mô hình EUTXO được thiết kế và việc chuyển sang hàm băm datum trên đầu ra được thực hiện để tránh các mục nhập UTXO đầy hơi, mà tại thời điểm đó (tiền đa tài sản) có kích thước không đổi (xem [1] trang 7).
Bây giờ chúng ta có các mục nhập UTXO có kích thước thay đổi và kế toán để hỗ trợ chúng, chúng ta có thể khôi phục datum nội tuyến.
Vì datum nội tuyến thay đổi rất ít về mô hình ngoài nơi lưu trữ dữ liệu, nên chúng ta không cần lo lắng về việc vi phạm bất kỳ yêu cầu nào khác của sổ cái, nhưng chúng ta cần lo lắng về ảnh hưởng đến kích thước của bộ UTXO.
Kích thước thiết lập UTXO
Đề xuất này cung cấp cho người dùng một cách để đưa lượng dữ liệu lớn hơn nhiều vào bộ UTXO. Điều này có dẫn đến tình trạng phình to bộ UTXO tồi tệ hơn nhiều không?
Câu trả lời là chúng ta đã có một cơ chế để ngăn chặn điều này, cụ thể là giá trị UTXO tối thiểu. Nếu datum nội tuyến hóa ra làm tăng đáng kể mức sử dụng dung lượng, thì chúng ta có thể cần phải tăng coinsPerUTxOWord để giảm kích thước UTXO. Điều đó sẽ tốn kém và bất tiện cho người dùng, nhưng sẽ vẫn cho phép họ sử dụng datum nội tuyến ở nơi chúng hữu ích nhất và chi phí có thể chịu được. Hơn nữa, chúng ta hy vọng rằng trên thực tế, chúng ta sẽ có thể giảm coinsPerUTxOWord khi công việc sắp tới về việc chuyển phần lớn UTXO sang bộ nhớ trên đĩa hoàn tất.
Một đường ray bảo vệ khác sẽ là thực thi các giới hạn trên đối với kích thước của datum nội tuyến. Cuối cùng, chúng ta có thể liên kết chúng với kích thước của một hàm băm, điều này sẽ đảm bảo không sử dụng nhiều dung lượng hơn hiện nay. Tuy nhiên, điều này còn tồi tệ hơn nhiều đối với người dùng, vì nó gây ra sự gián đoạn rõ rệt trong đó datum nội tuyến hoàn toàn có thể chấp nhận được, cho đến khi nó vượt qua ngưỡng kích thước mà tại đó không thể chấp nhận được và không có cách nào để tránh điều này. Nói chung, chúng ta muốn tránh sự gián đoạn như vậy để tăng dần chi phí.
Trên thực tế, những gì được triển khai ở đây có thể phụ thuộc vào việc công việc UTXO trên đĩa có được hoàn thành vào thời điểm triển khai đề xuất này hay không.
Các chế độ chỉ định datum khác
Chúng ta có thể không dùng các phương pháp khác để chỉ định datum (băm datum hoặc băm datum + datum bổ sung). Tuy nhiên, các phương pháp khác cũng có một số lợi thế.
- Chi phí truyền tải: người sáng tạo trả tiền so với người tiêu dùng trả tiền
- datum nội tuyến: người sáng tạo trả tiền
- Hàm băm Datum: người tiêu dùng trả tiền
- Băm Datum+băm datum bổ sung: cả hai đều trả tiền
- Chi phí giá trị UTXO tối thiểu
- Inline datums: phụ thuộc vào kích thước dữ liệu
- Hàm băm Datum: chi phí cố định
- Giá trị băm datum + thêm datum: chi phí cố định
- Sự riêng tư
- Inline datums: datum ngay lập tức được công khai
- Băm Datum: datum không công khai cho đến khi được sử dụng
- Băm Datum+băm datum bổ sung: datum ngay lập tức được công khai, nhưng chỉ với những người theo dõi chuỗi
- Giao tiếp của datum
- Inline datums: giao tiếp on-chain dễ dàng
- Băm Datum: giao tiếp off-chain cần thiết
- Băm Datum + datum bổ sung: giao tiếp on-chain phức tạp
Bất kỳ yếu tố nào trong số này đều có thể quan trọng đối với các trường hợp sử dụng cụ thể, vì vậy tốt nhất là giữ lại các tùy chọn khác.
Script context
Bao gồm thông tin về datum nội tuyến
Về nguyên tắc, chúng ta không cần để các tập lệnh xem liệu datum có nội tuyến hay không. Chúng ta có thể giả vờ rằng datum nội tuyến không phải là nội tuyến và chèn chúng vào bản đồ nhân chứng datum.
Câu hỏi cơ bản là: chúng ta có muốn các tập lệnh có thể đưa ra xác nhận về việc datum có nội tuyến hay không? Có nhiều lý do để muốn làm điều này: không việc sử dụng datum nội tuyến gây ra sự cố giao tiếp cho người dùng và do đó, hoàn toàn hợp lý khi nhà phát triển ứng dụng có thể muốn thực thi việc sử dụng của họ.
Hơn nữa, theo nguyên tắc chung, chúng ta cố gắng giữ Script context trung thực với các giao dịch thực tế nhất có thể. Ngay cả khi việc sử dụng thông tin không rõ ràng ngay lập tức, chúng ta vẫn cố gắng cung cấp thông tin đó và để người dùng quyết định.
Do đó, chúng ta làm bao gồm thông tin về datum nội tuyến trong Script context.
Biểu diễn và tương thích ngược
Có một số tùy chọn về cách thay đổi cách thể hiện Script Contexts để bao gồm thông tin mới và liệu có thực hiện nỗ lực tương thích ngược cho các phiên bản ngôn ngữ cũ hay không.
Đối với Script context mới:
- Khớp với biểu diễn sổ cái càng nhiều càng tốt: thay đổi các trường trên đầu vào và đầu ra thành hàm băm datum hoặc datum.
- Cố gắng chỉ có một cách để tra cứu datum: đặt datum nội tuyến vào bản đồ nhân chứng datum và chèn các giá trị băm của chúng vào đầu vào và đầu ra tương ứng; tùy biến thêm một boolean vào đầu vào và đầu ra để cho biết liệu datum ban đầu có phải là nội tuyến hay không.
Đối với khả năng tương thích ngược:
- Đừng cố biểu diễn datum nội tuyến cho các tập lệnh sử dụng các phiên bản ngôn ngữ cũ: đơn giản là các tập lệnh cũ không thể chạy được trong các giao dịch sử dụng datum nội tuyến (vì chúng ta không thể biểu thị thông tin).
- Viết lại datum nội tuyến thành datum không nội tuyến: đặt datum nội tuyến vào bản đồ nhân chứng datum và chèn hàm băm của chúng vào đầu vào và đầu ra tương ứng.
Đối với Script context mới, tùy chọn 1 có lợi thế đáng kể là khớp với biểu diễn sổ cái của các giao dịch. Điều này giúp triển khai dễ dàng hơn và cũng tránh được chi phí khái niệm cho người dùng, những người sẽ phải phân biệt hai cách biểu diễn giao dịch. Mặc dù khoảng cách khái niệm ở đây có thể nhỏ, nhưng nếu chúng ta để nó lớn dần theo thời gian thì nó có thể trở nên khá khó hiểu.
Sau đó, chúng ta có quyền lựa chọn phải làm gì về khả năng tương thích ngược. Tùy chọn 2 sẽ hoạt động, nhưng phức tạp hơn đối với sổ cái và không nhất quán trong việc thể hiện với lựa chọn của chúng ta cho Script context mới (`dữ liệu' nội tuyến đôi khi được trình bày trung thực và đôi khi được đưa vào bản đồ nhân chứng). Tùy chọn 1 đơn giản, nhưng không cho phép các tập lệnh cũ hoạt động với datum nội tuyến. Điều này sẽ không quá tệ nếu nó chỉ có nghĩa là không thể sử dụng các tập lệnh cũ trong các giao dịch bao gồm datum nội tuyến, nhưng nó cũng giới thiệu một cách mới để tạo ra một đầu ra không thể sử dụng được. Nếu người dùng tạo một đầu ra với một tập lệnh cũ và một datum nội tuyến, thì bất kỳ chi tiêu giao dịch nào cho đầu ra đó sẽ bao gồm một datum nội tuyến, mà chúng ta sẽ không cho phép.
Thật không may, chúng ta không thể ngăn người dùng tạo các đầu ra như vậy nói chung, vì địa chỉ tập lệnh không bao gồm ngôn ngữ tập lệnh, do đó, sổ cái không thể biết liệu datum nội tuyến có được phép hay không. Mã máy khách thường sẽ có thể thực hiện việc này vì mã này thường sẽ biết tập lệnh.
Yếu tố giảm thiểu là chúng ta cho rằng điều này sẽ không phổ biến trong thực tế, đặc biệt vì chúng ta cho rằng hầu hết người dùng sẽ chuyển sang phiên bản mới tương đối nhanh chóng, vì chúng ta mong muốn hỗ trợ datum nội tuyến và được phát hành cùng với các tính năng mong muốn khác.
Do đó, chúng ta chọn cả hai tùy chọn 1 và không cung cấp khả năng tương thích ngược cho các phiên bản ngôn ngữ cũ.
Người đề xuất
[1]: Chakravarty, Manuel MT, et al. "Mô hình UTXO mở rộng".
Nguồn bài viết tại đây
