-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Instruction to store data #48
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,67 @@ | ||
--- | ||
Title: Publish arbitrary data instruction | ||
Number: 0 | ||
Status: Draft | ||
Version: 4 | ||
Authors: | ||
- Francisco Aguirre | ||
Created: 2023-11-16 | ||
Impact: Low | ||
Requires: | ||
Replaces: | ||
--- | ||
|
||
## Summary | ||
|
||
This RFC proposes a new instruction, `Publish`, to publish some data to another location. | ||
|
||
## Motivation | ||
|
||
XCM itself is not a good means of storing and retrieving arbitrary data. | ||
This fixes the storage part, leaving the retrieval to another mechanism. | ||
|
||
## Specification | ||
|
||
The new instruction looks like this: | ||
|
||
```rust | ||
Publish { data: BoundedVec<Key, Value, Bound> } | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could different chains have different values set for |
||
``` | ||
|
||
`Key` and `Value` are arrays of bits, they could be anything. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe clearly specify that Key and Value are both |
||
|
||
The `Bound` value should be configurable. | ||
|
||
### Examples | ||
|
||
A program like the following might be sent to another location for publishing some data: | ||
|
||
```rust | ||
WithdrawAsset(/* ... */), | ||
BuyExecution { /* ... */ } | ||
Publish { data: [(b"My key", b"My value")] } | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What is the origin of this data? Can that be stored along with the data itself? Or is this operation by default restricted to a specific origin? E.g., I am a parachain interested in this data but only if it comes from another parachain, not from users within it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If there's some additional logic as to who can send/execute this instruction, it should be added here. |
||
RefundSurplus, // <- In case we overpay | ||
DepositAsset { /* ... */ } | ||
``` | ||
|
||
The other location stores this key value pair in any manner appropriate to it, which might allow different types of retrieval afterwards, or none at all. | ||
|
||
## Security considerations | ||
|
||
Programs that publish data would need to pay a certain amount of funds proportionate to the size of the data. | ||
|
||
## Impact | ||
|
||
This proposal adds a new instruction, so the impact is low. | ||
|
||
## Alternatives | ||
|
||
The other alternative to this is to use `Transact`, since it allows sending an encoded blob of bytes. | ||
This, however, falls short, as it's expected that the blob decodes to a function call on the receiver. | ||
This new instruction makes it clear that it's talking about data and not a function call, while at the same time allowing for multiple key value pairs to be sent. | ||
|
||
## Questions and open Discussions (optional) | ||
|
||
- Should we account for the published data's size via Weight? | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I believe it should be up to the implementation on the receiving chain, don't you think? Basically, it would depend on what that chain does with that data and its size. For example, if this instruction triggers an extrinsic whose execution time depends on the size of the data, you should There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Which leads me to... would chains be able to configure an |
||
- Should we introduce a new instruction for storage deposits or add another operand to the `Publish` instruction specifying the assets used? | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If chains are able to configure the way this instruction is processed, I think this could be used for storage deposits. For example in storage chains, it could express the intention of storing a file identified by a hash (and some other metadata needed). |
||
- Should there be a way to delete the published data via XCM? | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is an implementation detail, but we could use the approach of updating a value by using the same key with a new value, and deleting a value by using the same key with as value an empty Vec. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.