Integration test for the blockchain

[yangl1996]

Write an integration test for the blockchain module, like the blockchain_growing test we had for the previous version. It should

• NOT use any private API, or directly access the database. We need this test to survive if we change the underlying implementation of blockchain (say, add caching).
• NOT require adding new API to the blockchain.
• ONLY test the final states: proposer leader, ordered proposer blocks, utxo set, unreferred proposer blocks, unreferred transaction blocks, unvoted proposer blocks, etc. (let's discuss before adding checks)
• NOT use any kind of print statements. If the test fails, the traceback will provide enough information to debug.
• live in /tests.
• cover at least the same scenarios as the test for the previous blockchain module.

Here’s the overall flow:

1. Initialize blockdb, blockchain, wallet, and utxodb.
2. Construct blocks and call insert on blockdb and blockchain. It may be a good idea to write some macros/functions to help construct those blocks, but let’s discuss how they should look like and where should they live, before actually coding any. blockchain.insert will return a diff of proposer block sequence. Call functions in handlers to update the UTXO set.
3. Check whether the states (UTXO set, unvoted proposer blocks, etc.) are correct.

[wgr523]

So:

1. no wallet.
2. no mining.
3. no validation. ?

[yangl1996]

Correct! Construct blocks by hand, but use existing functions for all other tasks, so no mining and no validation. I just updated the description to include wallet.

It is intended to test the confirmation logic. Wallet, UTXO set, etc. are just used to check the results.

[yangl1996]

Btw, please branch off master instead of reusing existing local branch. Thanks!

[wgr523]

No problem!

[wgr523]

this looks good?

assert_eq!(config::NUM_VOTER_CHAINS, 3, "please set NUM_VOTER_CHAINS to 3 to run this test.");

[yangl1996]

let's try to make the test independent of the number of chains

[wgr523]

we want to test for those scenarios (to be added more):

1. transaction block comes
2. proposer comes, refer tx and prop
3. voter comes with different votes, e.g. vote for 0,1,2...levels.
4. voter comes with enough/not enough votes to elect a leader
5. voter chains have longer forks, need rolling back
6. invalid transaction which should be sanitized
7. some level don't have leader but next level does

[wgr523]

we need a block creator, whose input are parent and content. also it can increment the timestamp automatically. function or macro or?

[yangl1996]

Either function or macro is fine. Note that we need to randomize the extra_content field of the block, or it's very easy to create two blocks with the same hash.

• proposer_block!(parent_hash, proposer_refs, transaction_refs)
• voter_block!(parent_hash, voter_parent_hash, votes)
• transaction_block!(parent_hash, transactions)

It'd great if we could put those macros under the corresponding block modules, i.e. put proposer_block! (or its function version) at block::proposer::tests and make this macro (or function) public, and then use this function anywhere in the test where we need to generate a block. Since tests only gets compiled when running the test, we don't add overhead for compilation.

[wgr523]

Either function or macro is fine. Note that we need to randomize the extra_content field of the block, or it's very easy to create two blocks with the same hash.

• proposer_block!(parent_hash, proposer_refs, transaction_refs)
• voter_block!(parent_hash, voter_parent_hash, votes)
• transaction_block!(parent_hash, transactions)

It'd great if we could put those macros under the corresponding block modules, i.e. put proposer_block! (or its function version) at block::proposer::tests and make this macro (or function) public, and then use this function anywhere in the test where we need to generate a block. Since tests only gets compiled when running the test, we don't add overhead for compilation.

if we have a random nonce, then we don't need a random extra content?

[yangl1996]

Yeah, setting the nonce to be random will also work.

On May 20, 2019, at 6:54 PM, wgr523 notifications@github.com wrote:

Either function or macro is fine. Note that we need to randomize the extra_content field of the block, or it's very easy to create two blocks with the same hash.

proposer_block!(parent_hash, proposer_refs, transaction_refs) voter_block!(parent_hash, voter_parent_hash, votes) transaction_block!(parent_hash, transactions) It'd great if we could put those macros under the corresponding block modules, i.e. put proposer_block! (or its function version) at block::proposer::tests and make this macro (or function) public, and then use this function anywhere in the test where we need to generate a block. Since tests only gets compiled when running the test, we don't add overhead for compilation.

if we have a random nonce, then we don't need a random extra content?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/yangl1996/prism-rust/issues/22?email_source=notifications&email_token=AAOSIYMP5IVV5NJC44V7DETPWMT4BA5CNFSM4HM3TD32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV2JAKI#issuecomment-494178345, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOSIYLO2ZNTDVQ43KQZYSLPWMT4BANCNFSM4HM3TD3Q.

[yangl1996]

Closed in #44