You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey, is sumeragi.trusted_peers actually required to be set in the config?
10
-
11
-
I guess that's the only way to specify the relevant topology and let the nodes know what addresses to communicate with as well as what public keys to use to verify respective node signatures
12
-
13
-
> Other peers might specify it as a trusted one
14
-
15
-
it should be bi-directional to support the consensus I guess
16
-
17
-
> or clients might commit transactions which will register a new peer
18
-
19
-
right.. actually Iroha v1 relies on that more, such a transaction was defined in the genesis (instead of the config), though it might be tricky if all of these peers are not relevant (unregistered in the post-genesis state) anymore and that's why there was an alternative needed (e.g. config) to contain a set of at least one peer (to sync from), once the WSV is relevant, the topology can be recovered from the blockstore/wsv
20
-
21
-
I guess it is, at least for a private chain, excluding a scenario of the only node in a network. Otherwise how would a node understand whom to trust (where to get the public key from)
@@ -103,17 +58,18 @@ The block creation is configured with [`sumeragi.block_time`](#sumeragi-block-ti
103
58
commit_time = "4s"
104
59
```
105
60
106
-
## `sumeragi.gossip_period`
61
+
## `sumeragi.max_blocks_per_gossip`
107
62
108
-
-**Type:**String or Number, [Duration](glossary#type-duration)
109
-
-**Default:**1 second
63
+
-**Type:** Number
64
+
-**Default:**$4$
110
65
111
-
Period in milliseconds for pending transaction gossiping between peers. More frequent gossiping shortens the time to
112
-
sync, but can overload the network.
66
+
The amount of blocks that can be sent in a single synchronization message.
67
+
68
+
**Example:**
113
69
114
70
```toml
115
71
[sumeragi]
116
-
gossip_period = "1s"
72
+
max_blocks_per_gossip = 4
117
73
```
118
74
119
75
## `sumeragi.max_transactions_per_gossip`
@@ -131,7 +87,27 @@ you have high packet loss.
131
87
max_transactions_per_gossip = 500
132
88
```
133
89
134
-
## `sumeragi.max_transactions_in_block`
90
+
## `sumeragi.transaction_gossip_period`
91
+
92
+
-**Type:** String or Number, [Duration](glossary#type-duration)
93
+
-**Default:** 1 second
94
+
95
+
Period for pending transaction gossiping between peers.
96
+
97
+
**Example:**
98
+
99
+
```toml
100
+
[sumeragi]
101
+
transaction_gossip_period = "1s"
102
+
```
103
+
104
+
::: warning
105
+
106
+
More frequent gossiping shortens the time to sync, but can overload the network.
107
+
108
+
:::
109
+
110
+
## `sumeragi.transactions_in_block`
135
111
136
112
-**Type:** u32
137
113
-**Default:** $2^9 = 512$
@@ -144,7 +120,72 @@ elapsed since the round start[^1].
144
120
145
121
```toml
146
122
[sumeragi]
147
-
max_transactions_in_block = 512
123
+
transactions_in_block = 512
124
+
```
125
+
126
+
## `sumeragi.trusted_peers`
127
+
128
+
<!--
129
+
130
+
Hey, is sumeragi.trusted_peers actually required to be set in the config?
131
+
132
+
I guess that's the only way to specify the relevant topology and let the nodes know what addresses to communicate with as well as what public keys to use to verify respective node signatures
133
+
134
+
> Other peers might specify it as a trusted one
135
+
136
+
it should be bi-directional to support the consensus I guess
137
+
138
+
> or clients might commit transactions which will register a new peer
139
+
140
+
right.. actually Iroha v1 relies on that more, such a transaction was defined in the genesis (instead of the config), though it might be tricky if all of these peers are not relevant (unregistered in the post-genesis state) anymore and that's why there was an alternative needed (e.g. config) to contain a set of at least one peer (to sync from), once the WSV is relevant, the topology can be recovered from the blockstore/wsv
141
+
142
+
I guess it is, at least for a private chain, excluding a scenario of the only node in a network. Otherwise how would a node understand whom to trust (where to get the public key from)
0 commit comments