...

1. An Iroha administrator should create a "bridge" domain and separate domain domains 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 register and transfer new assets (those will represent external assets or tokens) and accounts (external accounts or wallets) based on bridge-clients quorum.

...

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

    // else do nothing...


    Fail("Account not found.")

)

Notice, that 2 3 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, 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.

...

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