You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RGB contract global state, as it is currently implemented, suffers from a data availability issue, which might have significant impact on some use cases. This discussion aims to collect community requirements and constraints to better identify what could be the protocol-level solutions or mitigations
What if data is missing
Visibility over the latest updates of some global state in a RGB contract is subject to the ability to retrieve the associated data. Let's take the circulating supply of an inflatable asset as an example: every inflation operation impacts the global state, but as a user I don't necessarily have access to the operation details.
Consider the following scenario:
Alice issues an inflatable asset (IFA) with inflation right assigned to UTXO1
Bob receives some amount of the asset
Bob can independently validate the circulating supply: since UTXO1 is still
unspent, he knows that the global state has not changed
Alice inflates the asset, updating its circulating supply
Bob can now see that UTXO1 is spent, so probably an inflation operation happened, but he doesn't know the details of such operation so he ignores the circulating supply of the asset
Bob receives some assets that come from the secondary issuance. Now he can independently validate the circulating supply again
This happens because the only way a wallet can get to know the details of an operation is by accepting a consignment file that includes them.
To complicate things further, global state updates may be performed by entities other than the issuer: in the scenario above, Alice could delegate Charlie to perform inflation operations. It's thus not enough in general to put contract issuers in charge of exposing global state details, as they themselves may not know them.
Filling the void
The issue described above can easily be solved if Alice constructs a consignment file containing the inflation transition and creates a web server that exposes that file to whomever is interested. However, later on Alice may disappear, the URL may expire or data may become unavailable for any other reason.
We should therefore identify more reliable ways to make global-related data available to contract participants. Different entities may choose to adopt the strategies they prefer, since this is currently not covered by consensus, but we should try to avoid excessive fragmentation to maximize a wallet's ability to retrieve data.
What follows is a non-exhaustive list of strategies acting as starting point for the discussion:
Peer to Peer: global information is shared between sender and receiver in a RGB transition
This can happen in 2 ways: either data is always included in consignments or the receiver signals in the invoice the interest in receiving it
Since the sender may not have access to the data, this cannot be enforced by the receiver and we should instead rely on their good faith
Public API: issuer exposes consignments related to global updates on a URL accessible to the public
Distributed data sharing services: any entity having access to the data can expose it through data sharing protocols
E.g.: bittorrent, IPFS/filecoin, arweave, ...
DA chains: any entity having access to the data can upload it to a data-availability blockchain
E.g.: Celestia, Avail, EigenDA, NEAR DA, ...
Bitcoin: important global state can be encoded in an OP_RETURN output to be available for everybody
May be viable for small-size state that does not change often and is vital for the contract
The above solutions differ in terms of:
cost: onchain space is expensive, sharing p2p is free
reliability: onchain space is forever, distributed services are less so
data availability: p2p alone does not solve much until the issuer sends data to at least one user, from there it slowly spreads out
complexity: integrating access to an external blockchain involves quite a bit of additional logic, especially if it's meant to be trust-minimized
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
RGB contract global state, as it is currently implemented, suffers from a data availability issue, which might have significant impact on some use cases. This discussion aims to collect community requirements and constraints to better identify what could be the protocol-level solutions or mitigations
What if data is missing
Visibility over the latest updates of some global state in a RGB contract is subject to the ability to retrieve the associated data. Let's take the circulating supply of an inflatable asset as an example: every inflation operation impacts the global state, but as a user I don't necessarily have access to the operation details.
Consider the following scenario:
UTXO1UTXO1is stillunspent, he knows that the global state has not changed
UTXO1is spent, so probably an inflation operation happened, but he doesn't know the details of such operation so he ignores the circulating supply of the assetThis happens because the only way a wallet can get to know the details of an operation is by accepting a consignment file that includes them.
To complicate things further, global state updates may be performed by entities other than the issuer: in the scenario above, Alice could delegate Charlie to perform inflation operations. It's thus not enough in general to put contract issuers in charge of exposing global state details, as they themselves may not know them.
Filling the void
The issue described above can easily be solved if Alice constructs a consignment file containing the inflation transition and creates a web server that exposes that file to whomever is interested. However, later on Alice may disappear, the URL may expire or data may become unavailable for any other reason.
We should therefore identify more reliable ways to make global-related data available to contract participants. Different entities may choose to adopt the strategies they prefer, since this is currently not covered by consensus, but we should try to avoid excessive fragmentation to maximize a wallet's ability to retrieve data.
What follows is a non-exhaustive list of strategies acting as starting point for the discussion:
The above solutions differ in terms of:
Beta Was this translation helpful? Give feedback.
All reactions