[WIP] Add additional test scenarios #14
Closed
elizabethengelman wants to merge 4 commits from
add-additional-test-scenarios into statediffing
pull from: add-additional-test-scenarios
merge into: :statediffing
:v1.11.6-statediff-v5
:v1.10.26-statediff-4.2.2-alpha
:jenkins_reborn
:v1.10.25-statediff-v4
:v1.10.25-statediff-v4-wip
:cerc_refactor
:release-v1.10.23-statediff-4.2.0-alpha
:v1.10.23-statediff-v4
:v1.10.23-statediff-v4-wip
:v1.10.22-statediff-v4-wip
:v1.10.22-statediff-v4
:v1.10.21-statediff-v4
:linter_updates_wip
:release-v1.10-21-statediff-4.1.2-alpha
:release-v1.10.21-statediff-4.1.2-alpha
:v1.10.20-statediff-v4
:v1.10.19-statediff-v4
:statediff
Dismiss Review
Are you sure you want to dismiss this review?
Labels
Clear labels
bug
critical
duplicate
enhancement
epic
help wanted
in progress
invalid
low priority
question
rebase
v1
v5
wontfix
Copied from Github
Kind/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
An issue or PR manually copied from GitHub.
Breaking change that won't be backward compatible
Something is not working
Documentation changes
Improve existing functionality
New functionality
This is security issue
Issue or pull request related to testing
Priority
Critical
The priority is critical
Priority
High
The priority is high
Priority
Low
The priority is low
Priority
Medium
The priority is medium
Reviewed
Confirmed
Issue has been confirmed
Reviewed
Duplicate
This issue or pull request already exists
Reviewed
Invalid
Invalid issue
Reviewed
Won't Fix
This issue won't be fixed
Status
Abandoned
Somebody has started to work on this but abandoned work
Status
Blocked
Something is blocking this issue or pull request
Status
Need More Info
Feedback is required to reproduce issue or to continue work
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: cerc-io/go-ethereum#14
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
I'm not sure how helpful this PR is in illustrating the questions/ideas that I was talking about during standup today. But basically what is happening is we have a test chain that is being created in https://github.com/vulcanize/go-ethereum/blob/statediffing/statediff/testhelpers/helpers.go. Three blocks, and the transactions on each block are:
Block 1:
test bank accountsendsaccount 110000 etherBlock 2:
test bank accountsendsaccount 11000 etheraccount 1sendsaccount 21000 etheraccount 1creates atest contract accountBlock 3:
test bank accountchanges the storage variabledata's value at index 2 to 3account 2mines the block, so gets the mining rewardtesttoTestContractand then compiling it withpragma solidity ^0.5.0- I'm not sure what the previous contract was compiled with.- contract account's state diff proof (the root hash and the leaf node hash)
- account 2's state diff proof (just the root hash)
- bank account's state diff proof ( just the root hash)
- burn account's state diff proof ( just the root hash)
- account 1's state diff proof (just the root hash)
- bank account state diff proof (just the root hash)
- contract account state diff proof (root hash and leaf node hash)
- account 2's state diff proof (just the root hash)
I guess my question is do these changes, specifically to the state diff proofs, make sense? I want to make sure that the I understand the changes I'm making the the tests before adding in some bigger changes to the test contract.
Hey @elizabethengelman thanks for the detailed breakdown!
Changing the contract name changes the byte code which changes the contract account's code hash, this is a change in a state trie node so that means that node hash is updated and the root for the entire state trie is updated. Differences in the the state trie roots will cause differences in the block hashes since the block hashes are the rlp encoding of the block headers which themselves include the state trie root. Since the state trie root has been changed every state proof- not just the contract account's proof- will be updated as well since the first byte array in each of the proof sets is the root hash itself. So for the contract account proof it makes sense to see a different root hash and a different leaf node hash and for the others to just see the different root hash- looks good to me!
@i-norden 🙏 thanks for taking a look & for that explanation - I was having trouble thinking it through at that level, so that is super helpful!
closing this in favor of https://github.com/vulcanize/go-ethereum/pull/15
Pull request closed