Page History

...

Background

Iroha Special Instructions and Iroha Queries processing requires a permissions based security model.

...

As you can see permissions were a first-level entities in Iroha 1 and had a strict hardcoded verification logic. Iroha1 was mainly planned to be used as a private blockchain and this system would work there. Yet Iroha2 is planned to be used in both private and public blockchains and therefore needs some degree of customization on how permissions are checked to implement some more complex cases.

Solution

Decisions

...

As the Iroha project progresses towards being able to be used in different types of blockchains. It would be good to give more powers to developers. Therefore this RFC introduces a minimal Permission framework, which let's the developers of each blockchain have the power to set up their permission checks accordingly. Of course there will be an out of box implementations provided which can be used for simple blockchains, for more complex logic the developers will be able to define their completely own Permission checks implementation that would suit their needs.

TL;DR

• Introduce Permission Checker trait
• Make Iroha generic over `PermissionChecker` and `Permission` types
• Implement out of box `IrohaPermissionChecker` with minimal checks and the ability to tweak it through the `IrohaPermissionCheckerBuilder`

Code Example

trait PermissionChecker<Permission> {
    pub fn check_permissions(instruction: ISI, authority: Id) -> Result<(), String>
}

Register<Permission, Account>: ISI

#[derive(Encode, Decode, Serialize, Deserialize)]
struct Account<Permission> {
    permissions: Vec<Permission>,
    account_data: 
    // .. other fields
}

struct Iroha<Permission, PC: PermissionChecker<Permission>> {
    pub checker: PC,
    // .. other fields
}

Iroha<Iroha1Permission, Iroha1PermissionChecker>

enum Iroha1Permission {

}

Pros

1. Customizable permissions check logic
2. Customizable permission type
3. Permission check logic is written in pure rust - which is a turing complete and convenient language while ISIs are not yet there.
4. Faster than WASM
5. Does not introduce additional complexity as WASM does.

Cons

1. Can be customized only at compile time, can not be stored in genesis

...

Alternatives

1. Use Iroha 1 approach with roles and grantable permissions and do hardcoded permissions checks inside instructions
   1. Pros:
      
      1. Tested in already running blockchains like bakong Bakong and byaccoByacco
   2. Cons:
      
      1. Hardcoded permission model - not possible to suit to different types of blockchains
2. Use Iroha Special Instructions as scripting for checking permissions + Assets mechanisms to store. With two options: implement permission checks as triggers, or simply another part of validation pipeline.
   1. Pros:
      
      1. Customizable permissions check logic
      2. Can be changed at runtime and stored in file
      `+` customizable
   2. Cons:
      1. ISIs and Queries are not mature enough to write complex logic that might be needed for permission checks
      2. Triggers design is not finalized and they are not implemented.
3. Use WASM permission check functions
   1. Pros:
      1. Customizable permissions check logic
      `+` can
      1. Can be changed at runtime and stored in file
   2. `-` no ability to clean genesis block  processing and configuration
   Use WASM permission check functions so that they can be fully customized and
   1. 1. Can be written in any
   programming
   1. 1. language
   (at runtime
   1. 1. that can be
   swapped)

Concerns

• Additional requirements to Iroha Special Instructions, Queries and Triggers will slow down development
• Additional high-level functionality would be needed to simulate "Roles"

Assumptions

• Iroha Triggers support pre-instruction hooks because it will be more effective to check permissions before instructions execution

Risks

• This solution will impact Iroha Triggers design `[9;6]`

1. 1. 1. compiled to WASM
   2. Cons:
      1. WASM execution is in general slower
      2. Types through all the codebase will need to be adapted to be compatible with WASM
      3. More research about the WASM libraries and execution is needed

Additional Information

• This solution impacts the Genesis Block design
• This makes Iroha closer to a framework

...