Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Table of Contents | ||||||
---|---|---|---|---|---|---|
|
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 • Rules are enforced by a public program (public source code) ➔ transparency: no single trusted 3rd party • The APP program is executed by parties who create new blocks ➔ public verifiability: anyone can verify state transitions |
Consensus Layer | Iroha Sumeragi | A public data structure (ledger) that provides:
|
...
Image Added
Expand | |||||
---|---|---|---|---|---|
| |||||
|
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.
...
Physical View
This section describes the mapping of software onto hardware and reflects its distributed aspect.
Image Added
Expand | |||||
---|---|---|---|---|---|
| |||||
|
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:
Image Added
Expand | |||||
---|---|---|---|---|---|
| |||||
|
Sending Iroha Queries
Image Added
Expand | |||||
---|---|---|---|---|---|
| |||||
|
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.
Image Added
Expand | |||||
---|---|---|---|---|---|
| |||||
|
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:
Image Added
Expand | |||||
---|---|---|---|---|---|
| |||||
|
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.
Image Added
Expand | |||||
---|---|---|---|---|---|
| |||||
|
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:
Image Added
Expand | |||||
---|---|---|---|---|---|
| |||||
|
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.
Image Added
Expand | |||||
---|---|---|---|---|---|
| |||||
|
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
Image Added
Expand | |||||
---|---|---|---|---|---|
| |||||
|
Development View
This section describes the static organization or structure of the software in its development of environment.
No Format | ||
---|---|---|
| ||
.
├── 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.
Image Added
Expand | |||||
---|---|---|---|---|---|
| |||||
|
As you can see - Peers Deployment is Cloud Native. Peers deployment via `docker-compose` can be used as an example:
Expand | |||||
---|---|---|---|---|---|
| |||||
|
Scenarios
Table of Contents | ||||||
---|---|---|---|---|---|---|
|
Contributors | ||||
---|---|---|---|---|
|
Change History | ||
---|---|---|
|