Skip to content
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

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
67 changes: 67 additions & 0 deletions proposals/0000-publish-arbitrary-data.md
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> }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Publish { data: BoundedVec<Key, Value, Bound> }
Publish { data: BoundedVec<(Key, Value), Bound> }

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could different chains have different values set for Bound? And if so, the sending chain should be aware of the Bound of the receiving chain, right?

```

`Key` and `Value` are arrays of bits, they could be anything.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe clearly specify that Key and Value are both Vec<U8>


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")] }
Copy link

Choose a reason for hiding this comment

The 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.

Copy link

Choose a reason for hiding this comment

The 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?
Copy link

Choose a reason for hiding this comment

The 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 BuyExecution that is enough for that size of data.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which leads me to... would chains be able to configure an Executor or Dispatcher to handle this kind of instruction?

- Should we introduce a new instruction for storage deposits or add another operand to the `Publish` instruction specifying the assets used?
Copy link

Choose a reason for hiding this comment

The 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?
Copy link
Contributor

Choose a reason for hiding this comment

The 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.