Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR serves to prototype the ability to publish and interpret atomic metadata via the Omni Layer.
The purpose is to remove duplication of metadata in future transaction types that may permit attaching metadata. For example the string "This transaction means X, find out more at Y.com" could be included with transactions relating to X but this is incredibly inefficient. Instead the string could be published just once and then referenced.
"Atomic metadata" in this context is metadata which is independent of any transaction and even independent of the Omni state. To put it another way, it is not consensus-affecting. Publishing metadata on-chain is a contentious issue, and the methodology used is intended to provide the functionality as an extension outside of the consensus state all clients must share.
The outline is fairly straight forward. Any arbitrary string (assume max length of
datacarrier
) can be hashed (SHA256) and the first and last bytes of the hash used to form an identifier. This is a deterministic outcome and has no relation to the Omni state. Should that same string be published as metadata via the Omni Layer, this two byte identifier could then be used in future transactions to reference the published string.Since this process is isolated from the state, any future transaction can reference metadata but it cannot require it. References to non-existent metadata will simply return an empty string. Clients can choose to offer users the choice on whether to use and display metadata, and clients can even ignore metadata completely during processing without affecting the Omni state.
Example usage:
We can get the
metadataid
for a given string at any point (again independent so no synced chain required):We see the
metadataid
for this string isad0d
. If we modify the string slightly, the hash will change and we will receive a differentmetadataid
:Let's say we wish to publish this string on-chain so we can reference it in future transactions. We would do that with
omni_sendpublishmetadata
:The metadata is now available to be referenced by a future transaction. We can retrieve the metadata by passing the address and the
metadataid
toomni_getmetadata
:If we inspect the transaction we will see it is of a new type (
80
-Publish Metadata
):It may also prove useful to obtain all the metadata a given address has published, and this can be done with the
omni_getaddressmetadata
call, for example:Notes
metadataid
metadataid
. Publishing the same metadata, or new metadata with a collidingmetadataid
will replace the existing metadata.metadataid
is intentionally short for a number of reasons:metadataid
can be published to update old metadata