Status | DECIDED |
---|---|
Stakeholders | |
Outcome | |
Due date | |
Owner |
Background
Below there is a part of code with initial configuration of the World State View, which each 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 could not be moved to genesis block and in general there should not be any genesis block based logic in core Iroha.
let domain_name = "global".to_string(); let mut asset_definitions = BTreeMap::new(); let asset_definition_id = permission::permission_asset_definition_id(); asset_definitions.insert( asset_definition_id.clone(), AssetDefinition::new(asset_definition_id.clone()), ); let account_id = AccountId::new("root", &domain_name); let asset_id = AssetId { definition_id: asset_definition_id, account_id: account_id.clone(), }; let asset = Asset::with_permission(asset_id.clone(), Permission::Anything); let mut account = Account::with_signatory( &account_id.name, &account_id.domain_name, config.public_key.clone(), ); account.assets.insert(asset_id, asset); let mut accounts = BTreeMap::new(); accounts.insert(account_id, account); let domain = Domain { name: domain_name.clone(), accounts, asset_definitions, }; let mut domains = BTreeMap::new(); domains.insert(domain_name, domain); let world_state_view = Arc::new(RwLock::new(WorldStateView::new(Peer::with_domains( PeerId::new(&config.torii_configuration.torii_url, &config.public_key), &config.sumeragi_configuration.trusted_peers, domains, ))));
Problem
Root account
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 peers network initialization system should have a sudo/root user with `DoAnything` permission.
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 Iroha Special Instructions, as we need some account that this Iroha Special Instructions would relate to with `DoAnything` 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 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 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:
- For public blockchains it would be reasonable to 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.
10 Comments
Egor Ivkov
Moved from inline comments in section `Decisions`, about `DoAnything` permission.
Makoto Takemiya : This is potentially dangerous as many people trying to set up networks may not read the docs and understand the implications of this. There should be some action that users take to enable this account or the account should be automatically deleted by default and users should take actions to keep it. Safe defaults are very important in the blockchain space.
Egor Ivkov
I think we can add a default event trigger at initialization that after a configurable amount of blocks will remove "root@global" account.
By default this trigger will be added, but the users may explicitly specify in configuration that they do not need this trigger.
Nikita Puzankov
Ok, let's play with initial configuration.
Salakhiev Kamil
The way it is done in Iroha1 is that we just execute genesis block without any stateful validation. This is the only exception where it is allowed. That way we can avoid creating any root accounts or root permissions. We can do the same for Iroha2
Makoto Takemiya
This could potentially break applications that do transfers in the genesis block and have a bug or bad math.
Nikita Puzankov
I think new approach to permissions can help: Permissions
Salakhiev Kamil Makoto Takemiya Egor Ivkov what do you think?
Salakhiev Kamil
Can you please elaborate a bit how proposed approach to permissions can help?
Egor Ivkov
I think Nikita can add more information here. But basically the new permissions proposal suggests to check permissions with triggers and therefore before these triggers are added no permissions are checked. It would mean that we can add these triggers in the genesis block.
Nikita Puzankov
Quote from Permissions:
In other words, if we extract permissions as Iroha Module, we don't need to worry about them if we have to perform some initial actions without them, we will install them after these actions.
Egor Ivkov
If we implement this approach with permissions I think we can safely configure everything in the genesis block. I don't see any problems with this at the moment.