Abstract

Decentralized exchange (DEX) functionality on Iroha v2 requires a mechanism for communication between third-party blockchains. This proposal introduces Bridges as such mechanism - entities, that can interact with other blockchain networks by a specific set of protocols built on top of already existing ISIs.

Glossary

Host blockchain - Blockchain where the current bridge module is deployed.
Client blockchain - any other blockchain network connected to Iroha2 via Bridge module.
Bridge contract - part of the bridge module responsible for interaction with client bridge component or module and third-party blockchain.
Client Bridge component - It is a component whose purpose is to perform communication between Iroha2 and other blockchain networks according to the protocol in bridge contract.

Introduction

The main goal is to have the following functionality:

Register a bridge that will be associated with a specific network (e.g. Ethereum network);
Register external asset (token) on an existing bridge (e.g. ERC20 token);
Be able to transfer all of 3rd-party and Iroha blockchain tokens;
Lock/demint funds for sending external tokens;
Mint/unlock funds for receiving external tokens.

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.

An Iroha administrator should create a "bridge" domain and separate domains for each bridge, which will consist of all information about the bridge and its external entities.
This account (and only it) should be able to add multi-signature accounts of concrete bridges, which will be administered by the bridge clients.
Only bridge accounts should be able to register and transfer 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 domain name that stores all bridge accounts.
Bridge owner account ID. A common Iroha account that administrates the bridge.

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

Fail("Account not found.")

)

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

First, ISI checks if the given owner account exists, then creates a domain with a bridge account named 'bridge' with related permissions and without a public key, and finally, 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.

Bridge client registration

Command to register an external bridge component account.

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 signature. This instruction should add 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.

Operation parameters:

Bridge ID. A title of the bridge domain.
(not sure) Account name. A name for this external bridge component.
Public key. A public key for the external account.

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 ISI should create a mapping between an external token ID (which can be used in external 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.

Operation arguments:

Bridge ID.
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).

Operation arguments:

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

Permissions:

Only external bridge validator accounts can use this function.

Within Iroha

Like regular transfer in Iroha (AssetTransfer)

From Iroha

A regular asset transfer to a bridge account.

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

The flow of the protocol is the following (vault = client bridge, TOK = some 3rd-party token):

Transfer from third-party blockchain to Iroha.
1. Alice sends TOK to vault
2. Alice sends proof of transaction inclusion in block to a bridge client
3. Bridge contract unlocks & transfers tokens to Alice on Iroha
Transfer from Iroha to third-party blockchain
1. Alice sends TOK-asset to bridge contract
2. Bridge contract signals to vault
3. Vault observes the command, releases and transfers TOKs to Alice
4. Vault finishes the process by proofing the transfer to bridge contract, then bridge contract releases the collateral to the vault in Iroha
5. Otherwise, the locker receives his tokens back

Making bridges trustless

In order to make the functionality described above trustless, we need to have the following on Iroha:

1. Asset-store data structurization/verification

Description

Bridge-related data is encoded and placed in the asset KV-store. Currently, there is no way to restrict the format of data being saved. Therefore, anyone who has permission to mint asset parameters for the bridge domain is also able to store incorrect information about the bridge. Another example can be swapping assets on DEX: to make a deal one needs to be sure that the exchange rate placed in a store is correct. Thus, we need the ability to validate such data.

Possible solution

Using permissions. Make permissions for minting special asset parameters (value types) by defining the format type either in the asset definition or in the permission ISI itself.

2. Persistence of the algorithms

Description

The bridge registration process consists of many steps like register a domain, register bridge account, make a record in an asset-store, etc. These steps form an algorithm, that needs to be persistent for everyone who tries to register a bridge. Currently, it's hard or inconvenient to do in Iroha.

Possible solutions

1. Use separate ISI. It's the easiest solution, but it requires Iroha to depend on external entities.
2. Store predefined compositions of ISIs as procedures (or functions) on the Iroha's state. A procedure can be stored as an asset within a separate account with its own rights (permissions) or in an account directly. The main question here is how to prevent the user with a procedure executing other instructions (not saved as the procedure) to be sure that the contract (procedure) won't be violated.

These features should help in making bridges more safe and trustless.