| Status | IN PROGRESS |
|---|---|
| Stakeholders | |
| Outcome | |
| Due date | |
| Owner |
Background
Below there is a part of code with initial configuration of the World State View, which each pear executes on startup. Initially there was a plan to move this logic into the genesis block functionality and transform it into several ISI. But after Iroha Special Instruction.
After some initial work on this task it appears to me that this part should may not be moved to genesis block and in general there should could not be any genesis block based logic in core Iroha.
...
The data model of Iroha is build around domains, accounts, assets and corresponding permissions. Based on this model it is essential that at the point of initialization of the peer network there is peers network initialization system should have a sudo/root user with `DoAnything` permission to do anything. This type of user is essential as only having this user we .
Only "root" user can create accounts with lesser privileges, domains of different types and different assets.
Right now this type of user is created by direct manipulation of the World State View when the peer is started as you can see in the code listing. And consequently it is impossible to create this user by ISIIroha Special Instructions, as we need some account that this ISI Iroha Special Instructions would relate to with root previleges and there is none. Therefore this logic can not be included into genesis block`DoAynthing` permission. Genesis block can't solve this problem without modification of basic Iroha mechanisms Permissions + Instructions.
Permission Representation
Currently permissions are represented as assets in the defined predefined permissions domain. They are then given to different accounts. Consequently the logic of permission domain initialization also can not be moved to ISI in genesis block.
...
Solution
The solution which I propose to this question is not to define any genesis block related logic in the core Iroha. The WSV World State View will be initialized with the "root" user on peer startup and then depending on the type of blockchain application that is built on top of Iroha, the app will proceed with its own initialization transactions:. If this solution is accepted we should proceed to remove the initial Kura code related to the genesis block issue.
- For public blockchains it would be reasonable to the execute a transaction for the root user to remove itself , after all the initial setup will be is done.
- For private blockchains the user may remain for some system administration related work.
If this solution is accepted we should proceed to remove the initial Kura code related to the genesis block issue.
...
Decisions
- Every Iroha Peer starts with "root@global" Account with `DoAnything` permission
Alternatives
Concerns
Assumptions
Risks
Additional Information
Every other setup related work apart from root account initialization and permissions domain initialization can be done by ordinary transactions submitted by clients and therefore does not require genesis block related functionality.