identity.rs icon indicating copy to clipboard operation
identity.rs copied to clipboard

[Task] DID document alias output serialization

Open PhilippGackstatter opened this issue 2 years ago • 0 comments

Description

Design and implement how DID documents are stored in the state metadata of an alias output. Effects on performance and gas cost should be investigated, as well as ease of integration into the framework and by others implementing support for DIDs in alias outputs. Moreover, consider whether the state metadata document needs to contain the DID.

Motivation

DID documents are serialized with JSON according to the W3C spec. However, in the interest of easing interoperability from smart contracts, which are expected to build on top of the various output types, a simpler serialization format might be justified. (De)serializing JSON in a smart contract might incur higher gas cost and reduce performance compared to a simpler byte layout serialization.

Since the identifier of an alias output is unknown until the output is published to the ledger, there is a need for a placeholder DID in the document. For consistency, we can consider to never store the AliasId (which is effectively the DID), in the state metadata, even after it is known, so we don't have the situation where the document in the state metadata sometimes contains the correct did, and sometimes the placeholder. This would also save a few bytes and therefore reduce the required storage deposit.

Resources

Part of #908.

To-do list

Create a task-specific to-do list. Please link PRs that match the TODO list item behind the item after it has been submitted.

  • [ ] Investigate smart contract interoperability.
  • [ ] Implement the serialization format, if any.
  • [x] Consider a mechanism to remove the DID from the state metadata document #947

Change checklist

Add an x to the boxes that are relevant to your changes, and delete any items that are not.

  • [ ] The feature or fix is implemented in Rust and across all bindings whereas possible.
  • [ ] The feature or fix has sufficient testing coverage
  • [ ] All tests and examples build and run locally as expected
  • [ ] Every piece of code has been document according to the documentation guidelines.
  • [ ] If conceptual documentation (mdbook) and examples highlighting the feature exist, they are properly updated.
  • [ ] If the feature is not currently documented, a documentation task Issue has been opened to address this.

PhilippGackstatter avatar Jul 12 '22 11:07 PhilippGackstatter