| Status |
| ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Stakeholders | |||||||||
| Outcome | |||||||||
| Due date | 14 Aug | ||||||||
| Owner |
Background
Below there is a part of code with initial configuration of the World State View, which each pear peer executes on startup. Initially there was a plan to move this logic into the genesis block functionality and transform it into several Iroha Special Instruction.
...
The solution which I propose to this question is not to define any genesis block related logic in Iroha. The 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 initial setup 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
Provide instructions or instruction mode that can be executed only at genesis - an equivalent of DoAnything permission but without root. May prove to be a lot of work, with a rather small outcome.
Concerns
We should be careful to design the solution so that it can be used in both public and private blockchains. It is addressed in the Solution section.
Assumptions
Assumption is made that we do not want to change much the current data model of domains, accounts, assets and permissions.
Risks
We do not want to change the data model much, as some other projects already depend on it.
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.
Final Decision
It was decided to disable permission checks specifically for genesis block validation.