...
- We need to define networking format
- We need to define Iroha Peer entry-points
- We need to support communication with:
- Clients (Web, Android, iOS)
- Bridges (Polkadot)
- Peers (Iroha)
Current status
...
Let's start from the entry-points:
| Entry-point | URI | Implementation | Comments |
|---|
| Client → Peer | |||
| Maintenance | |||
Web API for checking Iroha Peer health, metrics and manage configurations
It can be used for Peer To Peer communications (instead of Ping/Pong) and administrative purposes
| Look Maintenance RFC | ||
| Transactions | /transaction | |
| Torii + Queue | Web API for incoming Transactions with Instructions to execute on the ledger Transactions can be send from Clients, Bridges or other Peers | |
| Query | / |
| query | Torii + WSV | Web API for Queries which will work with World State View of the Peer | |
| Peer ↔ Peer | |||
| Block synchronization | / | ||
| block | Torii + Kura | Web API for data synchronization and propagation between Peers |
| Consensus | / |
| vote | Torii + Sumeragi | Web API for consensus voting via Sumeragi logic |
Protocol and Formats
Right now we do not have application layer protocol and use TCP. All protocol related logic is placed inside `Iroha_Network` crate.
...
- changes in `Iroha` instances like new `ChangeBlockBuildStepTime`
- `AddPeer` instruction will add new peer to WSV:Peer:Peers
- `ShareNewBlock` event can trigger new block propagation to peers from WSV:Peer:Peers
- `Vote` can be implemented as Instruction
Open Questions
- When Peers send accepted transactions
...
- ? Right after acceptance
...
- or each tick of Block Build Step
...
- What is the difference between Block commit message handling and Block synchronization
...
- How to update configuration which requires instance reloading (new address, etc)