Page History

...

To implement these functions, a few new Iroha instructions and a bridge module need to be added, those will be accessible behind the "bridge" feature.

Implementation 

The purpose is to not bring any new bridge-specific entities into the Iroha. In this case, asset stores can be used to save some specific information about bridges.

1. An Iroha administrator should create a separate domain for each bridge, which will consist of all information about the bridge and its external entities.
2. This account (and only it) should be able to add multi-signature accounts of concrete bridges, which will be administered by the bridge clients.
3. Only bridge accounts should be able to add new assets (those will represent external assets or tokens) and accounts (external accounts or wallets) based on bridge-clients quorum.

All the restrictions should be implemented using permissions.

Bridge registration

A bridge can be constructed from 3 parameters (BridgeDefinition):

• Bridge type (kind). An enumeration of supported communication protocols (for now it's only IClaim).
• Bridge name. A string. It should be unique. OR Bridge domain. This domain will store domain name that stores all bridge accounts.
• Creator account (maybe should be eliminated in the future)Bridge owner account ID. A common Iroha account that owns administrates the bridge.
• Maybe: Bridge account.

This operation can be represented as a composition of ISIs:

If(

    ExecuteQuery(GetAccount(owner_account_id)),
    // then
    Sequence([
        AddDomain(bridge_name),

        RegisterAccount(bridge_account, bridge_name),

        Mint(("bridge_definition", bridge_definition_bytes), bridge_asset_definition_id())
    ])

    // else do nothing...


)

Notice, that 2 new ISIs were added. A Sequence for sequential execution of an arbitrary number of ISIs (an extended version of Compose) and ExecuteQuery for sending Iroha queries.

First, ISI checks if the given owner account exists, then We assume, that every bridge will be a part of the Peer state. It means that for bridge registration, a new variant of the `PeerInstruction` should be added (RegisterBridge(BridgeDefinition, PeerId) with a corresponding generic Register<Peer, BridgeDefinition> instruction). This instruction should be called only with minimal required bridge parameters (definition). This ISI creates a domain with a bridge account named 'bridge' and sets the with related permissions and without a public key for this account, and finally it creates a new bridge entity based on these parameters. The public key for the bridge account is generated from a hash of the bridge definition (seed). To generate determined public keys for bridge accounts, a new crypto function for generating keypairs from a given seed should added: generate_key_pair_from_seed(Hash) → Result<(PublicKey, PrivateKey), String>. 

So, the final bridge should contain the following (Bridge):

• All data from the bridge the definition.
• Bridge account.

Permissions:

• CanRegisterBridge. By default allowed to the network admin.

Also, there will be added a 'bridges' map (String → Bridge) in the Peer and three new helper-methods to the WorldStateView:

...

, it mints an asset that stores bridge-related information (like bridge owner ID and kind). The signatories for the bridge account can be added later by the bridge owner.

This ISI can be executed multiple times for one bridge type and different bridge domains. So one bridge type can be used to create a bridge with multiple third-party networks.

Unresolved questions

1. Should we generate this public key from the seed or let the user choose one?
2. How can we implement this ISI as a Instruction::Composition(AddDomain, RegisterAccount, AddBridge)? (also think about a regular composition of ISIs)
   1. How can we prevent accounts with multisignature and assets if RegisterAccount will be used?
   2. How we will know that all the data will be consistent (e.g. new account will be added to the corresponding domain and be named 'bridge')?

Bridge client registration

Command to register an external bridge component account. From here, a new set of Iroha instructions should be added (BridgeInstruction).

For example, we have Polkadot parachain as a connector to the Iroha bridge module for Polkadot. Then we have to register a parachain node as an external validator for this bridge. So it can start using Bridge API with its own signature. This instruction should create an external bridge client component account in a bridge domain and let the bridge know that this account should sign MST token transfer commands from the external blockchainadd a signatory (a public key) to the bridge account. So for every transfer, this bridge should collect quorum of 2/3(make it configurable in future versions) client bridge components to process further actions in Iroha.

ISI parametersOperation parameters:

• Bridge ID. A title . Identifies of the bridge to which this external component belongs and the domain in which this account will be created.
• (not sure) Account name. A name for this external bridge component.
• Public key. A public key for the external account.

Permissions:

CanRegisterClientBridge. By default allowed to bridge owner
• .

External asset registration

When a bridge is registered, external tokens may be added to it. For example, one may add a new ERC-20 token from Ethereum. The corresponding Bridge ISI (RegisterExternalAsset) should create a mapping between an external token ID (which can be used in ExternalTokenTransfer instructionexternal transfers) and a mirror token in Iroha. The asset should be created in the bridge's domain with the specified name. Also, a mapping between this asset and the name of the external token should be created using the "external_asset" asset.

ISI argumentsOperation arguments:

• Bridge nameID.
• Token title. It should be unique.
• External token ID. A token identifier in an external network. Used by client bridge functionality when it will send transfer information from the external network.

Permissions:

...

• Only external bridge validator accounts can use this function.

External asset transfers

To Iroha

This instruction used to send a token from foreign blockchain or external bridge to Iroha. Also, we should offer a possibility to double-check the source of a transaction in a foreign blockchain (probably by storing some transactions in Bridge or making the additional field in Transaction).

ISI Operation arguments (ExternalAssetTransfer):

• External asset Asset ID - identification of an asset from an external blockchain.
• External transaction ID - some identifier of a transaction from an external blockchain
• Amount - amount number of tokens transferred to Iroha2

...

• Only external bridge validator accounts can use this function.

Within Iroha

Like regular transfer in Iroha (AssetTransfer)

Unresolved questions

1. How can we prevent spending from the bridge account? One solution is to make checks in TransferAsset ISI (source acc can't be a bridge acc) and the other is to generate a random public key without a secret key (not from seed).
2. Can implement it as a composition of (RegisterAsset, AddExternalAsset)?

From Iroha

From Iroha

A regular asset transfer to a bridge accountThere will be TransferAssetToBridge ISI.

Bridge protocol

As the first protocol for interoperability between blockchains, there will be a slightly modified version of XClaim, that we call IClaim (Iroha Claim). 

...