aboutsummaryrefslogtreecommitdiffstats
path: root/Mainnet-Spec.md
blob: a1044ce73d7cce0e71544fac4ce310bd137247ed (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
DEXON TODO

[SYSTEM CONTRACTS]

[ON-CHAIN UNBIASED RANDOMNESS WITHOUT DKG]
Use RANDAO to replace our DKG+TSIG based CRS rotation

the SALT is generated using a RANDAO
https://github.com/randao/randao
GitHub
randao/randao
RANDAO: A DAO working as RNG of Ethereum. Contribute to randao/randao development by creating an account on GitHub.
any participant that wants to join the validator pool (salt is now not generated at the time a user joins the network, like account creation, but a salt which is rotated when a validator declares to enter the validator pool on validator membership governance contract), at the time it submit deposit to enter the pool, it requests a random salt from the RANDAO system defualt contracts (please define a list of system contracts, where RANDAO is one of them), and submit rewards for calculating RANDAO randomness, and only after RANDAO randomness is generated by a threshold of participants "t+1" (now this randomness is unbiased), then the node actually starts participating in the next config change of validator node set.

[Smart Contract Execution Optimizations]

Contract Data Max Size for Dict / Array and All Data:
Max length for array / dict
Per account / per contract, 1MB data.

Contract Data and KV-store states should be separated

Memory Cached execution for smart contracts
Software Transactional Memory Method for conflict detection (with journal + MVCC)
With in memory multi-value concurrency control
computation dependency graph also in memory cachced
Journal log of kv-changes to fast detect conflicts, memory cached

Smart Contract Optimistic Parallel Execution

[Smart Contract Platform Features]
Contract code validation service on-chain handled.

Dexon extensible instruction set

[Features]
Non-Fungible Token native support

Recoverable Account
like EOS

Deferred TX Execution (cancelable) => contract
a deployed TX is invokable by a block miner after a time-lock

Recurrent TX Execution (cancelable) => contract
params: period, TX payload, max times, timeout

Default Safe math
special unsafe math operator

TX and Gas Rate Limit on each contract / account

Expirable TX, client specify the TX expiration and TX timestamp

[DEXON Tech WP]

1. Account System: Multi-Assets, Batch Token Transfer, Multi-Sig TX signing pool + RBAC
5. Sharding Mechanism
Assets Issuance Standard (something kind of enhanced ERC20 thing, but make balance native in account system)
7. Assets Trading Mechanism
8. Assets Bridging Mechanism
9. RBAC
10. Blocklattice Random Oracle
11. [Governance Council Mechanism]
12. OTA design: auto fetch new upgraded binary executable by governance provided binary hash and download link
13. Contract Upgradability
14. two kinds: only logic and data migration, so lock some time to complete migration, the predefined lock time

Recurring TX (Periodic, realized with smart contract)

Deferred TX (Time-Locked, realized with smart contract)

DEXON Account Spec
DEXON Block Gossip Algorithm Spec
DEXON RPoP Mining Spec (TX Fee, Storage Fee, Mining Rewards, Slash Conditions, Fisherman Protocols and Rewards)
DEXON Compaction Chain Signed State Spec (Compaction Chain Block Time)
DEXON Sharding Spec
DEXON Merkel Tree Spec
DEXON Light Client Protocol Spec
DEXON Governance Spec
DEXON VM Spec
DEXON Blocklattice Random Oracle Spec
DEXON Name System Spec
DEXON Assets Trading Protocol Spec
DEXON Assets Issuance Spec (native protocol like ERC20)
DEXON Randomized BA+Total order+consensus timestamp Spec

KYC proxy of token transfer support

To become resilient to nothing-at-stake or long-range attack, the validator set configuration changes must committed by prev. super majority set of of validators, like every day the set of validators will change and co-sign a validator view change milestone, and stake deposit lock-up will be at least period of length T (T = 1 day or 1 week)

[DEXON Consensus Algorithm]

Governance Parameters:
Totally N nodes, M shards, each shard has k chains
Initial launch: N=101, M=1, k=35
Min Block Time T_block (Block producing period) = 0.5s
Max Block Size 50kB
Max Ack frequency = 5 ack / sec (in terms of a chain to a another chain)

Each chain is identified by shard_id (uint32) and chain_id (uint32)

Avg signed tx size: 100B
Block size: 50kB (500 TXs per block, one node contribute to 1k TPS)
1k TPS per chain => 35k TPS for 35 chains

Block header overhead analysis:
Block size: 50kB
Block header size: 132 bytes (~0.2%)

Ack header overhead analysis:
Block size: 50kB
Ack header size: 35 * 100 bytes (~7%, note that as block size is increased, the acking overhead becomes negligible)

Gossip Method:
Push + Pull Model
When a new TX or Block or Block Hash or Voting in BA (any kind of data) received, fanout to N_push random nodes with TTL set to ttl.
Each node periodically pull new data from randomly sampled N_pull nodes, with period of pull T_pull.
Initially, N_push = 13, N_pull = 13, T_pull = 0.5s, ttl=3.

Expected latency of node-to-node (end-to-end) for any data transmission: RTT
Expected Latency of Data Propagation to 95% nodes in gossip model: ~ 3 RTT
Expected Latency of Data Propagation to 95% nodes in push all model: ~ 1 RTT
In later text, we use notation lambda for the expected data propagation latency for data to reach 95% notes (we assume small variance), ~2RTT

Bandwidth analysis:
Each node inbound / outbound: N * 50 (kB/block) * 2 (bps) = N * 100kBps = N * 0.8Mbps = 28 Mbps

CRS = HASH("IN_DEXON_WE_TRUST" || shard_id || chain_id)

Block payload:
shard_id: 4 bytes (uint32)
chain_id: 4 bytes (uint32)
block_producer_id: 20 bytes (ETH address format)
block_height: 8 bytes (uint64)
block_time: 8 bytes (uint64)
prev_block_hash: 32 bytes
transactions
acks
block_hash = HASH(shard_id||chain_id||block_height||block_time||prev_block_hash||transactions||acks), 32 bytes
signature = SIG(HASH(shard_id||chain_id||block_height||block_hash||acks)), 32 bytes
rand = HASH(SIG(CRS || h))

Acks payload:
shard_id: 4 bytes (uint32)
chain_id: 4 bytes (uint32)
block_producer_id: 20 bytes (ETH address format)
block_height: 8 bytes (uint64)
block_hash: 32 bytes
signature: 32 bytes
ack_time: 8 bytes (uint64)

Notarization payload (for compaction chain):
block_height: 8 bytes (uint64)
prev_block_hash: 8 bytes (uint64)
block_hash: 32 bytes
state_root_hash: 32 bytes
timestamp: 8 bytes (uint64)
signature: 32 bytes = SIG(HASH(block_height || prev_block_hash || block_hash || state_root_hash || timestamp))
--------------------------------------------------------------------------------
Compaction Chain Notarization
In each "validator_set_change_period", the validator set is fixed.
Over 1/3 validator notarized on a compaction chain history block, means that this block is finalized with merkle root state change final.
--------------------------------------------------------------------------------
Transaction Load Balancer
Each TX is load balanced according its TX hash with its timestamp t.
According to timestamp t, we have a view on the number of shards and number of chains in each shard.
TX hash is the seed for deterministic shuffle on shards, then chains, so any TX can be assigned to a
specific shard's specific chain.
--------------------------------------------------------------------------------
Transaction Timeout Design
Each signed TX has timestamp t and can only be included into the chain within t+T_tx_timeout.
--------------------------------------------------------------------------------
Rate Limits
Gas Limit per TX
Max TPS per Contract / Account: 500 TPS
--------------------------------------------------------------------------------
Dual Token Governance
Governance voting takes place
Governance contract token.
Token holder with veto rights.
A parameter change or adding of new params or adding of new DEXON native instruction set can be proposed.
The proposal takes "proposal_voting_period" of time to vote on the proposal.
If over 50% of nodes to pass any governance params changes.
--------------------------------------------------------------------------------
Governance Contract Params
min_supported_version (string, "0.0.1")
min_block_time (ms, uint32, 500ms)
block_proposal_waiting_period (ms, uint 32, 250ms)
transaction_timeout (ms, uint32, 5000ms)
min_validator_stake_self_deposit (DEX, uint32, 5000)
min_validator_stake_total_deposit (DEX, uint32, 25000)
validator_stake_deposit_lock_up_period  (s, uint32, 86400s)
validator_stake_withdrawal_lock_up_period (s, uint32, 86400s)
validator_set_change_period (s, uint32, 3600s)
snapshot_period (s, uint32, 3600s)
reward_per_block (DEX token, uint64)
tx_fee (DEX token, uint64)
account_creation_fee (DEX token, uint64)
governance_council_change_period (s, uint32, 30 days)

max_call_stack (uint32, 1024)
max_tx_gas_consumption (DEX, uint32, ?)
tx_rate_limit (uint32, 1024, per contract / per account TX rate limit)

gas consumption of each opcode
--------------------------------------------------------------------------------
PoP Mining Staking
Minimum staking per node: self-stake minimum registration as node candidate: 50k DEX (around 100k USD).
To become a validator node: total stake>250k DEX (500k USD)
Stake lock-up for deposit to take effect and withdrawal cool-down period: T_lock = 1 day.
--------------------------------------------------------------------------------
PoP Mining Rewarding
Initially 100M DEX
1st year, 25M
2nd year, 20M
3rd year, 20M
4th year, 20M
5th year, 15M (100% inflation)
6th year, 15M
7th year, 15M
8th year, 10M
9th year, 10M
9th year, 10M
10th year, 5M
...

--------------------------------------------------------------------------------
Receiver Pays Model

A white list of accounts that can use the contract execution for free
(Gas paid by contract owner, not sender).

A white listed accounts can have a specific rate limit set
on each account for free usage.
--------------------------------------------------------------------------------
Slash Conditions

Any condition that violates the algorithm will cause all stake slashing.

Violation of causality => slash all stakes.
Fork => slash all stakes.
Forming a ring => slash all stakes on block proposers in ring.
Violate the period of min block time => slash all stakes.
TXs wrong, not compatible with block hash and signature. => slash all stakes.
--------------------------------------------------------------------------------
Fisherman Protocol
Submit block hash proofs to prove violation of slash conditions to on-chain smart contract.
Once a slash condition is validated and confirmed by a submitted proof of a fisherman, the stakes are vaporized and rewards are given to the fisherman account that submit the proof first.
--------------------------------------------------------------------------------
Fast Bootstrap (Fast Sync) for New nodes
Sync node set from snapshot.
Concurrent sync merkle tree kv-stores from a specific snapshot.
Also syncing the journal change on merkle tree kv-store.
Finalize syncing using merkle proof + notarization signatures.
Start validating new TXs.
--------------------------------------------------------------------------------
Light Client Protocol
Sync node set from snapshot.
Validate TX inclusion and states using merkle proof + notarization signatures.
--------------------------------------------------------------------------------
Storage Fees, Account creation fees
To avoid spamming
--------------------------------------------------------------------------------
[Token Economy]
Programmable Rewarding Model for staking users.

1. What is the mining schedule for tokens - what will be the total supply and inflation rate?
Initial supply: 100M DEX
Inflation: Governance controlled (may be subject to changes)
current plan as follows (confidential, please don't reveal)
1st year, 25M
2nd year, 20M
3rd year, 20M
4th year, 20M
5th year, 15M
6th year, 15M
7th year, 15M
8th year, 10M
9th year, 10M
9th year, 10M
10th year, 5M

2. Is it correct that the longer the validator node will be engaged the bigger it’s mining reward will be?
The PoP mining reward is distributed in coinbase in each block.
Since in PoP random sampling of nodes as each chain's block's block proposer,
the probability that each node become a highest ranked block proposer is uniformly random among all nodes.
On the DEXON compaction chain, the actual coinbase is generated and block mining reward is distributed.
That's why we call it DEXON proof-of-participation, since if a node with highest rank is sleeping (not active at its block proposing period),
then its reward will be received by other nodes that mined the block in that time period.

3. The whitepaper says the network will have a predefined number of nodes - has that number been determined yet?
Initially, starts with 101 nodes, and governance control number of shards, per shard number of chains, and total number of nodes.

4. Who will be on the Dexon Governance Council?
Initially, DEXON foundation and IDG and Banyan capital (top VCs that have invested in DEXON).
DEXON aims to fully control the direction of network evolution in the first 2-3 years.
After DEXON has built up community and gains lots of industrial company uses,
it will fully decentralize the DEXON governance council to world-famous businesses in different sectors and in different countries.

5. Can you give an example of how randomized PoP will work?
Governance will control max number of nodes and minimum staking required.
Among all staking nodes, highest ranked nodes will be given right to become a block proposer
via VRF-based crypto sortition mechanism.
When a block proposer successfully proposes a block and the block later gets BA (Byzantine agreement) verified.
On the compaction chain the block proposer will receive mining rewards in coinbase.

6. The whitepaper describes a process for supporting validator candidates with tokens, what will be the incentive for the supporters?
DEXON designed the rewarding model to supporters of validator nodes to be completely "PROGRAMMABLE".
All mining rewards are received by the block proposer in block's coinbase.
And the mining reward distribution can be configured to be sent to a miner configured smart contract to programmably distributed rewards to its supporters.
For example, a node can distribute 99% of its mining rewards to its supporters if it wants to attract more staking from its supporters.
This not only makes DEXON token mining process completely not a security (since only the node that performs the validation earns reward).
How the node received reward is distributed is completely determined by the node itself, making the system more decentralized.

DEXON charges account creation fee, smart contract execution gas fee, and a flat TX processing fee, all fees will be distributed in the coinbase of a block to the block proposer.

--------------------------------------------------------------------------------
DEXON Consensus Algorithm

In each shard on each chain, we select a leader to propose a block in each period of a block time, nodes cannot propose blocks in shorter time frames than the 'min block time' to avoid DDoS attack.

Leader Election: Crypto Sortition
Genesis, each chain has seed Q_0 (or Q_genesis) as HASH("IN_DEXON_WE_TRUST"||shard_id||chain_id)
Each node's proposed block at height h is ranked by a shuffle among all nodes using the seed H􏰂(Q_h-1). (initial ranks are sorted are by node_id bits).
The node list can be looked up in governance staking contract that controls membership of validator nodes (effectively a membership protocol).

Actual block height starts with 1. The ranks of block height h block is determined by the node's rank by crypto sortition algorithm, if a node proposes multiple conflicting blocks at a same height, then the one with bigger block_hash value is considered as having higher rank.

After Byzantine agreement is reached on the block at height h, Q_h+1 is calculates as HASH(SIG(Q_h)||h) as a new random seed, which is stored inside the proposed block.

Blockchain Byzantine Agreement (Chain Growth):
Now we want to reach BA on the blocks proposed by nodes at height h.

For each block at height h, each BA voting round r committee is determined by crypto sortition, using H􏰂(Q_h-1 || r) as shuffle seeds on all nodes, and we only sample s nodes from n nodes in each round to be the committee. For initial launch, s=n, since the number of nodes initially are small, and does not need to run crypto sortition to reduce the overhead of BA. When n becomes large, say 10000, we must assume now the whole population has less than 1/3 Byzantine nodes, say 1/4. And we uniformly sample s nodes from n nodes to make the prob. that no. of Byzantine nodes<1/3. This is a hypergeometric sample, whose CDF can be easily calculated. The s nodes now runs the BA algorithm as stated below.

[Acking Criteria]
To ensure causality is preserved on the blocklattice data structure, a node can only ack to another node's block until it has received all informations related to the blocks all acking histories (all ancestor/parent block acking patterns) to avoid cyclic acking and reversed acking to a lower block height (same as a cyclic).

Time vector of a block B:
Each block's time vector has k entries (k is the number of chains in each shard), initialized every entry to 0.
Assume that block B is located on chain_id j in its shard.
Assume that block B's height is H on its shard's compaction chain, delivered by Total Ordering.

The time vector of block B's i-th entry is B's block_time.
Traverse on the compaction chain from height H-1 to 0 (genesis).
If at height h, we see a block b from chain_id i, we fill the time vector's i-th entry to be block b's block_time.
The time vector filling progress continues until we completed filling all k entries, or we have reached genesis.

[The acking of other blockchain's blocks] => Optimistic Acking
Within each shard, each chain acks to other chain's blocks periodically.
For an honest node to include ack to another blockchain's block, it only needs to include the highest ranked block which may not yet be confirmed on its chain.
The only rule is that, the confirmed ackings on each chain, must follow causality rules, no acking on same height of another chain, no acking on previously acked lower or equal height blocks (we consider here only the confirmed blocks that have acked).

Consensus Timestamp of a block B:
The medium of the time vector, excluding all 0 entries.

Smart Contract Random Seed of block B:
The hash of the concatenated random seeds Q from the N blocks that contribute to time vector of block B, excluding all 0 entries.

Keep Alive system: a validator node must periodically send keep alive as validator node msg.
Slash condition: if a validator node sends keep alive message, but is not actively participating in the protocol (like, if in 10 mins timespan, it is not actively participate in acking, voting, block proposing, then it is automatically removed, banned for a period of time, like a day, and punished on its deposit stake vaporization)

Fast Recovery After Partition:
DEXON consensus algorithm favors consistency over availability.
If network is temporarily partitioned, then nodes won't take progress in consensus (system halts).
Once network is recovered, in around 1 lambda, system is back to normal operation.
--------------------------------------------------------------------------------
BA Algorithm

# of nodes: 3t+1
# of Byzantine nodes: t

After each block's BA has been done, we enter an "initial proposal" period, we wait for 2 lambda to receive blocks from peers.

In each round, every node does "precommit" according to the follow rules:
Round: r=1, 2, ...

In each round, if a node has received over 2t+1 messages in a round, it proceeds to the next round.
All nodes keeps observing all messages of "precommit" and "commit" in an event-driven like fasion.

In round r,

IF (node has received any 2t+1 previous PRECOMMIT message on a block B,
  it sends (PRECOMMIT, NODE_ID, SIG, B, r)
ELSE IF (node has received any candidate blocks)
  a node send message (PRECOMMIT, NODE_ID, SIG, HIEGHT, HIGHEST_RANKED_BLOCK, r)
ELSE
  a node send message (PRECOMMIT, NODE_ID, SIG, HIEGHT, EMPTY, r)

[Event Driven]
Once a node receives 2t+1 precommit on a block B of round r messages.
it sends (COMMIT, NODE_ID, SIG, B, r)

[Finalization]
Once a node receives 2t+1 commit on a block B of round r messages.
it finalized BA to output B.

Every nodes continuously receives messages in all rounds and all steps.
Once a node receives any 2t+1 COMMIT message in a specific round on a block, it decides the block B and finalize it as BA result and proceeds to next block height. (the BA block may be an empty block)
--------------------------------------------------------------------------------
Optimistic block proposing

When a node has received a height h commit message on block B, it can start proposing next block at height h+1 if it is high ranked block proposer in that round.
--------------------------------------------------------------------------------
DEXON Infinite Sharding