Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace the previous Rounds module with the new Dpos module #3686

Closed
yatki opened this issue May 21, 2019 · 3 comments
Assignees
Milestone

Comments

@yatki
Copy link
Member

@yatki yatki commented May 21, 2019

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

  • Replace rounds.generateDelegateList by dpos.getRoundDelegates #4152
  • Replace rounds.validateBlockSlot by dpos.verifyBlockForger #4155
  • Replace rounds.validateBlockSlotAgainstPreviousRound by dpos.verifyBlockForger #4156
  • Replace rounds.tick by dpos.apply #4157
  • Replace rounds.backwardTick by dpos.undo #4158
  • Refactor the round intergration tests comply with new Dpos module #4192
  • Remove old rounds related logic #3685
  • Sync with testnet (not possible due to #4194)
  • Sync with mainnet
@yatki yatki added this to To Do in Version 3.0.0 via automation May 21, 2019
@sridharmeganathan sridharmeganathan added this to the Sprint 5 milestone Aug 14, 2019
@lsilvs lsilvs changed the title Replace new Round module with the old one Replace the previous Rounds module with the new Dpos module Aug 21, 2019
@lsilvs lsilvs assigned lsilvs and unassigned SargeKhan Aug 21, 2019
@lsilvs

This comment has been minimized.

Copy link
Member

@lsilvs lsilvs commented Oct 1, 2019

Syncing on mainnet is too slow. The issue will be investigated on #4340

@shuse2

This comment has been minimized.

Copy link
Contributor

@shuse2 shuse2 commented Oct 24, 2019

Closing since syncing is completed with the mainnet

@shuse2 shuse2 closed this Oct 24, 2019
Version 3.0.0 automation moved this from To Do to Done Oct 24, 2019
@lsilvs

This comment has been minimized.

Copy link
Member

@lsilvs lsilvs commented Oct 24, 2019

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: #4006 (comment)
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 (#4429).

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Version 3.0.0
  
Closed Issues
5 participants
You can’t perform that action at this time.