RGB data containers

[dr-orlovsky]

A proposal to extend client-side-validated data, representing "always validate" portion of RGB contracts, and which have a strict restriction on the size, clear typing etc with a generic-purpose BLOB data containers.

BLOB data containers (or simply "data containers" or "containers") must serve the purpose of delivering large-size data which do not require validation - like media resources for NFT-based content, legal contract texts/documents for all forms of RGB contracts, asset meta-information by the asset issuers (icons, signatures etc), proofs of burn for replaceable RGB20 tokens, actual data stored by Storm-based RGB contracts, models and data by Prometheus computing contracts etc.

Data containers:

• contain multiple pieces of MIME-typed data
• are not validated with client-side-validation
• delivered only upon request, but as a part of Conignments (like "witness" part of bitcoin blocks after SegWit)
• stored and distributed the same way as normal RGB (since they are parts of consignments) - with Bifrost protocol over LN and, possibly, later kept with Storm in decentralized fashion
• may utilize different backup strategy from RGB stash (since they may be much larger)
• represent a key-indexed structure, where key is stored in RGB state or metadata, such that multiple data pieces from different state transitions may be present at the same time
• encrypted with AES encryption; the encryption key must be a part of RGB metadata or state and must be able to be concealed, such that RGB users having this data in their history record (but not owning them) will never be able to access them. AES key will work also as an additional salt to the data key, so even the fact of which data were owned by historical owners will be confidential
• MIME type of the data is kept in RGB client-validated state

[dr-orlovsky]

Already implemented as a part of RGB Core. Discussion is closed.