|Type of change request|
This feature attempts to democratise the asset type creation aspects of the Iroha distributed ledger to enable every user to create any arbitrary tokens of their own choosing. Initially, this was motivated by the idea of recording personal IOUs on the ledger and making such informal ‘debts’ tradable in the system. However, considerations of how to do the implementation led to a more generallzed set of enhancements enhancement that can accomplish the same end.
This proposal extends the existing behaviour of Iroha in two waysaccording to the following:
- Modify the relationship between domains and users to allow users to exist in more than one domain.
- Extend the new account creation functionality to also create a new domain associated with the account and giving the user full administrative permissions on their 'personal domain'.
Personal domains extend the domain concept to add a domain that is associated with every user account. The user is then given all of the domain and asset administrator permissions normally associated with the domain (except perhaps for adding other users into their personal domain). Ideally, it would be possible for users to create additional personal domains to seperate assets, but at this stage I cannot think of any motivating use cases for this. All personal domain assets are tradable just like normal domain assets.
Derivative assets are a type of asset that has a relationship with another pre-existing asset in the ledger. For example, an IOU dollar would be a token that derives from the underlying asset type of dollar, but maintains its separate identity as an IOU. Derivative assets need not be created in the same domain as the underlying linked asset. Most types of derivative assets will need additional properties attached to them. To continue with the IOU dollar example, it would need fields for specifying an owed by relationship to the user responsible for repayment.
In a more serious application, a bank might record actual loan information as a debt asset with other metadata such as the loan repayment terms or an options asset might record the maturity date and the strike price.
This change will involve updating the relational schema to extend the domain - user relationship from a 1 to many to a many to many mapping and to update the permissions checks throughout the code base to ensure that user actions are verified against permissions for the appropriate domain.
|#||Change description||Affected component||Change motivation||Dependency (optional)|
|1||What is changed||Where it is changed|
Why it is done
|#||Research activity||Details||Acceptance criteria||Responsible (accepter)|
|#||Target reader||Documentation description|
|#||Validation activity||Intention||Actions||Expected result|
|1||Testing||Test component X and check if …|