Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  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 composition of ISIs (AddDomain, RegisterAccount, AddBridge)?
    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 should will be added to the corresponding domain and be named 'bridge')?

Bridge client registration

...

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 source of a transaction in a foreign blockchain (probably by storing some transactions in Bridge or making the additional field in Transaction).

ISI arguments (ExternalAssetTransfer):

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

Permissions:

  • Only external bridge validator accounts can use this function.

Within Iroha

Like regular transfer in Iroha (AssetTransfer)

Unresolved questions

From Iroha

  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

There will be TransferAssetToBridge ISI.TODO

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

...