Replace the previous Rounds module with the new Dpos module

yatki commented 5 years ago

Expected behavior

After developing the round module we should update the usage of the following methods:

rounds.generateDelegateList => dpos.getRoundDelegates
rounds.validateBlockSlot =? dpos.verifyBlockForger
rounds.validateBlockSlotAgainstPreviousRound => dpos.verifyBlockForger
rounds.tick => dpos.apply
rounds.backwardTick => dpos.undo

Actual behavior

We are still using old round module implementation at the moment.

Steps to reproduce

Which version(s) does this affect? (Environment, OS, etc...)

List of Task

[x] Replace rounds.generateDelegateList by dpos.getRoundDelegates https://github.com/LiskHQ/lisk-sdk/issues/4152
[x] Replace rounds.validateBlockSlot by dpos.verifyBlockForger https://github.com/LiskHQ/lisk-sdk/issues/4155
[x] Replace rounds.validateBlockSlotAgainstPreviousRound by dpos.verifyBlockForger https://github.com/LiskHQ/lisk-sdk/issues/4156
[x] Replace rounds.tick by dpos.apply https://github.com/LiskHQ/lisk-sdk/issues/4157
[x] Replace rounds.backwardTick by dpos.undo https://github.com/LiskHQ/lisk-sdk/issues/4158
[x] Refactor the round intergration tests comply with new Dpos module https://github.com/LiskHQ/lisk-sdk/issues/4192
[x] Remove old rounds related logic https://github.com/LiskHQ/lisk-sdk/issues/3685
[ ] ~Sync with testnet~ (not possible due to https://github.com/LiskHQ/lisk-sdk/issues/4194)
[x] Sync with mainnet

lsilvs commented 5 years ago

Syncing on mainnet is too slow. The issue will be investigated on https://github.com/LiskHQ/lisk-sdk/issues/4340

shuse2 commented 4 years ago

Closing since syncing is completed with the mainnet

lsilvs commented 4 years ago

I compared the mem_accounts state of databases populated before and after the new Dpos module implementation and here are the results:

BEFORE

lisk_main=# SELECT MAX(height) FROM blocks;
   max
----------
 10007585
(1 row)

lisk_main=# SELECT COUNT(*) FROM mem_accounts;
 count
--------
 238563
(1 row)

lisk_main=# SELECT SUM("balance") balance, SUM("fees") fees, SUM("rewards") rewards, SUM("vote") voteWeight, SUM("missedBlocks") missedBlocks, SUM("producedBlocks") producedBlocks, SUM("rank") rank FROM mem_accounts;
     balance      |      fees      |     rewards      |     voteweight     | missedblocks | producedblocks |  rank
------------------+----------------+------------------+--------------------+--------------+----------------+---------
 3466870560000000 | 41654830000000 | 3466870300000000 | 552105894049929619 |       176634 |       10007585 | 1624503
(1 row)

AFTER

lisk_main_dpos=# SELECT MAX(height) FROM blocks;
   max
----------
 10007585
(1 row)

lisk_main_dpos=# SELECT COUNT(*) FROM mem_accounts;
 count
--------
 238563
(1 row)

lisk_main_dpos=# SELECT SUM("balance") balance, SUM("fees") fees, SUM("rewards") rewards, SUM("voteWeight") voteWeight, SUM("missedBlocks") missedBlocks, SUM("producedBlocks") producedBlocks, SUM("rank") rank FROM mem_accounts;
     balance      |      fees      |     rewards      |     voteweight     | missedblocks | producedblocks | rank
------------------+----------------+------------------+--------------------+--------------+----------------+------
 3466870560000000 | 41654830000000 | 3466870300000000 | 552105894049929619 |       176634 |       10007584 |
(1 row)

I also compared each column to make sure they have the same data across the accounts. This was done by hashing the result of the aggregation of the rows like follow:

SELECT md5(CAST((array_agg(a."columnName" ORDER BY a.address))AS text)) FROM mem_accounts a;

The result was as follow:

COLUMN            BEFORE                             AFTER                           
----------------+----------------------------------+---------------------------------
username        | 53d037df656121db653fee5dd01f1a56 | 53d037df656121db653fee5dd01f1a56
isDelegate      | a39e4e5a66e11bbd11d4110b81812817 | a39e4e5a66e11bbd11d4110b81812817
secondSignature | 3547ae2376f8ca3b9552cbf6ed0452ed | 3547ae2376f8ca3b9552cbf6ed0452ed
address         | 9df81b5af966b12086b078b7d039609c | 9df81b5af966b12086b078b7d039609c
publicKey       | f8914ef12ef18be6f85d902ef2acb79d | f8914ef12ef18be6f85d902ef2acb79d
secondPublicKey | d372e54606da91231cff6074b699b9e8 | d372e54606da91231cff6074b699b9e8
balance         | 1341757c60831da45ae1105dc818c4d5 | 1341757c60831da45ae1105dc818c4d5
vote/voteWeight | c6f24ec734d9e6e4e022fd6eb993b905 | c6f24ec734d9e6e4e022fd6eb993b905
delegates       | cba054cd3807bcc7d226035d05b8662f | cba054cd3807bcc7d226035d05b8662f
multisignatures | cba054cd3807bcc7d226035d05b8662f | cba054cd3807bcc7d226035d05b8662f
multimin        | cd3b5c39687941e7626924248aceab49 | cd3b5c39687941e7626924248aceab49
multilifetime   | 0c72535fc210f97129c62556ccdd2c04 | 0c72535fc210f97129c62556ccdd2c04
nameexist       | 2d1e71f0390f3e905cdceef3fbbe05f8 | 2d1e71f0390f3e905cdceef3fbbe05f8
missedBlocks    | 60bbf8a4238a8ede4b28e1035d1b00ca | 60bbf8a4238a8ede4b28e1035d1b00ca
fees            | ccd2db0a46575af3c703d4bccddc85b8 | ccd2db0a46575af3c703d4bccddc85b8
rewards         | f9b0e792c023c9b13b6d11893177c4a6 | f9b0e792c023c9b13b6d11893177c4a6
rank            | 6a34fc79671590004495ea5fd120279c | cba054cd3807bcc7d226035d05b8662f
producedBlocks  | ae56c6f48f95129edbbcaee808b3765b | 174cd100cafe2557041de9b7717ff7a0

PS: Note that rank and producedBlocks hashes doesn't match BEFORE and AFTER the new Dpos module implementation. For rank the reason is that the column is not used after Dpos module implementation due to misleading information after BFT - See: https://github.com/LiskHQ/lisk-sdk/issues/4006#issuecomment-541553157 For producedBlocks the reason is because the genesis block forger is not updated in the new Dpos module implementation. An issue was created to tackle that (https://github.com/LiskHQ/lisk-sdk/issues/4429).

PS 2: Note that the vote column changed the name to voteWeight after Dpos module implementation

LiskArchive / lisk-sdk