Architecture
Conceptual View
This section describes the object model of the design.
Layers
According to Dan Boneh Blockchain applications may be divided into four layers:
3 | User Interface |
2 | Applications |
1.5 | Compute Layer |
1 | Consensus Layer |
We will use this classifications to group Iroha components and 3rd party components that can be integrated with Iroha components.
Components
Layer | Components | Description |
User Interface | Iroha Clients + 3rd Party Clients Web/Mobile/CLI | User Facing Services |
Applications | Iroha Modules + Custom Iroha Special Instructions | Run on blockchain computer |
Compute Layer | Iroha + Iroha Modules + Iroha Special Instructions | Application logic is encoded in a program that runs on blockchain |
Consensus Layer | Iroha Sumeragi | A public data structure (ledger) that provides:
|
Application Programming Interface
Functionality | Provider | Description |
|---|---|---|
Submission of Iroha Special Instructions | Clients | Clients receive declaration of desired actions from users in form of Iroha Special Instructions. They build a Transaction from them, use User's cryptographics keys to Sign it (optionally?) and send them to Iroha. |
Sending of Iroha Queries | Clients | Clients receive declaration of desired search results from users in form of Iroha Queries. They build a Request from them, use User's cryptographics keys to Sign it (optionally) and send them to Iroha. |
Execution of Iroha Special Instructions | Iroha | Iroha receives Transactions from Clients and process them in cooperation with Applications and Consensus. More on that in Process View Section. |
Execution of Iroha Queris | Iroha | Iroha receives Queries from Clients and execute them. More on that in Process View Section. |
Process View
This section describes the activities of the system, captures the concurrency and synchronization aspects of the design.
Clients ↔ Peers Communications
Let's start with Iroha Peers - as described in WhitePaper, Iroha as a system is build on top of a Peer to Peer Network.
So by Peer we will assume every Iroha instance up and running.
So basically we have two main interaction scenarios:
Submission of Iroha Special Instructions
Every User Interface will use `iroha-client` under the hood, so we will look at the sequence with it:
Sending Iroha Queries
Peer ↔ Peer Communications
In this section we will look at Peer to Peer communications in different aspects:
Iroha Qeuries Processing
Let's start from the quite simple Iroha Queries Processing.
Iroha Transactions Processing
In this section we will cover only Transactions related part of the whole End to End process of Iroha Special Instructions execution.
Let's start from sequence:
You already see this as a part of Submission of Iroha Special Instructions. Now we introduce Torii - which is Iroha Entity responsible for Network requests and Connections handling.
Queue is like a portal between Torii and another and the most important part of Iroha - Consensus.
Blocks Processing
Consensus works with group of Transactions called Blocks. The whole set of actions that it does with them too big so let's describe each item one by one.
Validation
We will briefly discuss roles that Peer can have, for more information read the White Paper.
In this case we will mainly consider Peer in a `Leader` role. We also will use `Sumeragi` as the only supported by the moment implementation of Consensus in Iroha.
As you can see, validation triggers next Consensus step.
Voting
The science behind Consensus (and Sumeragi) is fully described in the White Paper.
We will look at the high level and simple case of voting here:
As we can see - in simple cases we just sign valid Blocks by Voting Peers and then move to the next stage.
Commitment
This stage involves new Iroha entity - Kura in cooperation with already familiar to you World State View.
Synchronization
Some Peers may be "out of work" because of network or other issues. New Peers may be added. All of them need a mechanism to receive already committed blocks and stay in sync with Ledger.
More on details in the White Paper and Block Synchronization RFC
Development View
This section describes the static organization or structure of the software in its development of environment.
.
├── Cargo.lock
├── Cargo.toml
├── CHANGELOG.md
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── docker-compose-single.yml
├── docker-compose.yml
├── Dockerfile
├── Dockerfile.debug
├── iroha
├── iroha_2_whitepaper.md
├── iroha_client
├── iroha_client_cli
├── iroha_client_no_std
├── iroha_macro
├── iroha_network
├── iroha_substrate
├── LICENSE
├── MAINTAINERS.md
├── README.md
├── scripts
└── target
Iroha repository consist of one Iroha cargo workspace.
This workspace compose different crates:
Crate | Type | Description |
|---|---|---|
iroha | bin | Main Iroha Application for Peers instantiations. |
iroha_network | lib | Iroha Networking library for encapsulation of protocols. |
iroha_macro | lib | Library with Iroha related macroses (attribute and derive). |
iroha_client | lib | Library with Clients Facing (for User Interfaces, Applications and Peers) API. |
iroha_client_cli | bin | Command Line Interface wrapper on top of iroha_client. |
Physical View
This section describes the mapping of software onto hardware and reflects its distributed aspect.
As you can see - Peers Deployment is Cloud Native. Peers deployment via `docker-compose` can be used as an example:
Scenarios
- 1 Conceptual View
- 2 Process View
- 2.1 Clients ↔ Peers Communications
- 2.2 Peer ↔ Peer Communications
- 2.2.1 Iroha Qeuries Processing
- 2.2.2 Iroha Transactions Processing
- 2.2.3 Blocks Processing
- 2.2.3.1 Validation
- 2.2.3.2 Voting
- 2.2.3.3 Commitment
- 2.2.3.4 Synchronization
- 3 Development View
- 4 Physical View
- 5 Scenarios
| Version | Date | Comment |
|---|---|---|
| Current Version (v. 26) | Aug 24, 2020 06:55 | Vadim Reutskiy |
| v. 25 | Aug 24, 2020 06:53 | Vadim Reutskiy |
| v. 24 | Aug 24, 2020 06:53 | Vadim Reutskiy |
| v. 23 | Aug 24, 2020 06:52 | Vadim Reutskiy |
| v. 22 | Aug 24, 2020 06:51 | Vadim Reutskiy |
| v. 21 | Aug 24, 2020 06:44 | Vadim Reutskiy |
| v. 20 | Aug 24, 2020 06:37 | Nikita Puzankov |
| v. 19 | Aug 23, 2020 23:27 | Vadim Reutskiy |
| v. 18 | Jul 13, 2020 04:19 | Nikita Puzankov |
| v. 17 | Jul 09, 2020 03:11 | Nikita Puzankov |
| v. 16 | Jul 09, 2020 03:10 | Nikita Puzankov |
| v. 15 | Jul 09, 2020 02:42 |
Nikita Puzankov
Project Structure |
| v. 14 | Jul 09, 2020 02:33 |
Nikita Puzankov
Blocks Synchronization |
| v. 13 | Jul 09, 2020 02:20 |
Nikita Puzankov
Transactions and Blocks processing |
| v. 12 | Jul 09, 2020 01:22 |
Nikita Puzankov
Iroha Query Processing |
| v. 11 | Jul 09, 2020 01:13 |
Nikita Puzankov
Sending Iroha Queries |
| v. 10 | Jul 09, 2020 01:05 |
Nikita Puzankov
Submission of Iroha Special Instructions |
| v. 9 | Jul 09, 2020 00:25 |
Nikita Puzankov
Plant UML source for components diagram added. |
| v. 8 | Jul 09, 2020 00:12 | Nikita Puzankov |
| v. 7 | Jul 09, 2020 00:10 | Nikita Puzankov |
| v. 6 | Jul 09, 2020 00:06 | Nikita Puzankov |
| v. 5 | Jul 08, 2020 23:45 | Nikita Puzankov |
| v. 4 | Jul 08, 2020 23:31 | Nikita Puzankov |
| v. 3 | Jul 08, 2020 23:31 | Nikita Puzankov |
| v. 2 | Jul 08, 2020 23:30 | Nikita Puzankov |
| v. 1 | Jul 08, 2020 22:27 | Nikita Puzankov |