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.

After some initial work on this task it appears that this part may could not be moved to genesis block and in general there could should not be any genesis block based logic in core Iroha.

...

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 Iroha Special Instructions, as we need some account that this Iroha Special Instructions would relate to with `DoAynthing` `DoAnything` permission. Genesis block can't solve this problem without modification of basic Iroha mechanisms Permissions + Instructions.

...

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.:

1. 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.
2. 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.