Versions Compared

Old Version 1

changes.mady.by.user Nikita Puzankov

Saved on

compared with

New Version Current

changes.mady.by.user Ivan Rybin

Saved on

Key

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

...

  • Public and Private keys of Iroha Peer
  • Kura configuration:
    • Kura Mode (strict or fast)
    • Block Store Path
  • Sumeragi configuration:
    • Peer Id
    • Block Time
    • List of Trusted Peers
    • Maximum Amount of Faulty Peers
    • Commit Time
    • Transaction Receipt Time
  • Torii configuration
    • Client-side URL
    • Peer-side URL
    • Maintenance URL
  • Block synchronization configuration:
    • Gossip Period
    • Batch Size
  • Queue configuration:
    • Maximum transactions in block
    • Transactions time to live
  • Logger configuration:
    • Maximum Logging Level
    • Terminal Color Enabled
    • Date Time Format
  • Initial configuration is out-of-scope because will be solved in Genesis Block and Network Setup

Documentation for configuration can be found here.

Now we can analyze each parameter with several criterias:

ParameterPossible ValuesDefault ValueShould it be synchronized between PeersShould it pass consensusCan it be applied without restartWill it affect clients
Key PairValid Key HashNo

block_sync.batch_size

unsigned 32 bit integer4Yes?
No
YesYes
Kura Modestrict/fastNo
No

block_sync.gossip_period

unsigned 128 bit integer10_000YesYes
No
YesNo
Block Store Path

kura.block_store_path

Valid Unix path
"./blocks"
NoNoWith additional developmentNo
Peer IdValid URL + Key Hash

kura.init_mode

strict/fast
strict
No
Yes (Other Peers should update old Id to the new one)
NoWith additional developmentNo

logger.max_log_level

TRACE/INFO/DEBUG/WARN/ERROR
DEBUG
NoNoYes
List of Trusted Peers
No

key_pair

Valid
URL +
Key Hash
NoNoYesYes

queue.maximum_transactions_in_block

unsigned 32 bit integer
8192
YesYesYesNo
Block Time

queue.maximum_transactions_in_queue

unsigned 32 bit integer65536

Yes

queue.transaction_time_to_live

unsigned 128 bit integer
86400000(ms)
YesYesYesNo
Maximum amount of Faulty Peers

sumeragi.block_time

unsigned
32
128 bit integer
1000(ms)
YesYesYesNo
Commit Time

sumeragi.commit_time

unsigned 128 bit integer
1000(ms)
YesYesYesNo
Transaction Receipt Time

sumeragi.max_faulty_peers

unsigned
128
32 bit integer0YesYesYesNo
Client-side URLValid URLNo

sumeragi.max_instruction_number_per_tx

unsigned 32 bit integer4096Yes
Yes

sumeragi.n_topology_shifts_before_reshuffle

unsigned 32 bit integer1
No
Yes
Yes
Peer-side URL

sumeragi.peer_id

Valid URL + Key Hash
Yes (Other Peers should update old Id to the new one)NoWith additional developmentYes
NoMaintenance URL

sumeragi.trusted_peers

Valid URL + Key Hash
No
[]
No
YesYesYes
Gossip Period
No

sumeragi.tx_receipt_time

unsigned 128 bit integer
200(ms)
YesYesYesNo
Batch Size

torii.api_url

Valid URL
"127.0.0.1:8080"
NoNo
Yes

torii.max_instruction_number

unsigned 32 bit integer
Yes?
4096


Yes
YesNoMaximum Transactions Block

torii.max_sumeragi_message_size

unsigned 32 bit integer
Yes?
16384000


Yes
YesNoTransaction Time to Live

torii.max_transaction_size

unsigned 32
unsigned 128
bit integer
Yes?
32768

Yes

torii.p2p_url

Valid URL
"127.0.0.1:1337"
Yes
Yes
No
No
Maximum Logging Level

torii.Maintenance URL

Valid URL
TRACE/INFO/DEBUG/WARN/ERROR

NoNo
Yes
NoTerminal Color Enabledtrue/falseNoNoYesNoDate Time FormatStringNoNoYesNo

Solution

Decisions

Alternatives

Concerns

Assumptions

Risks

...

wsv.account_metadata_limits

Byte size and UTF length4096, 1048576

Yes

wsv.asset_metadata_limits

Byte size and UTF length4096, 1048576

Yes

wsv.length_limits

Range[1; 128]

Yes

Solution

So solution may be to use Iroha Special Instructions for management consensus dependent parameters like "Gossip Period", storing set of parameters under a Peer entity in World State View and propagating these parameters and their updates into subsystems via Iroha channels.

Parameters that can be managed without consensus can avoid usage of Iroha Special Instructions and implemented separately as API for system administrators.

Decisions

  • Split parameters into consensus dependent and maintenance related
    • Use Iroha Special Instructions for consensus related
    • Put management of other parameters under Maintenance Endpoint
  • Implement "hot reload" mechanisms in Iroha subsystems

Alternatives

  • Use Iroha Special Instructions for all parameters - brings additional set of instructions to maintain, increases load on blocks store and blocks synchronization, won't guarantee non-functional requirements from system administrators perspective (each update will take time needed to finalize block)
  • Use Maintenance Endpoint for all parameters - brings additional complexity in terms of parameters synchronization and open security related issues (who can change "Batch Size" on all Peers?)
  • Do not synchronize any parameters between Peers - may be a good option

Concerns

Lack of real use cases and strong opinions on topic from potential users gave no ability to make a really welcoming decision.

Assumptions

Maintenance Endpoint will be "unstable" during 2.0 release.

Risks

  • Solution will not cover all needs `[4;6]`
  • Requirements will be simpler than expected `[3;3]`
  • "Hot reload" mechanisms will require a lot of work `[6;7]`

Additional Information

Image Added