...
- Bridge type (kind). An enumeration of supported communication protocols (for now it's only IClaim).
Bridge name. A string. It should be unique.Bridge domain. This domain will store all bridge accounts.- Creator account (maybe should be eliminated in the future). A common Iroha account that owns the bridge.
- Maybe: Bridge account.
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 public key for this account, 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>.
...