[WIP] Add additional test scenarios #14

Closed
elizabethengelman wants to merge 4 commits from add-additional-test-scenarios into statediffing
elizabethengelman commented 2019-09-16 15:17:28 +00:00 (Migrated from github.com)

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 account sends account 1 10000 ether
Block 2:
test bank account sends account 1 1000 ether
account 1 sends account 2 1000 ether
account 1 creates a test contract account
Block 3:
test bank account changes the storage variable data's value at index 2 to 3
account 2 mines the block, so gets the mining reward

  • The changes that were made to the contract included changing the name from test to TestContract and then compiling it with pragma solidity ^0.5.0 - I'm not sure what the previous contract was compiled with.
  • After the previous changes to the contract, the following things changed:
    • contract byte code
    • block 2 hash
    • block 3 hash
    • the contract account's code hash
    • block 2:
      - 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)
    • block 3:
      - 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.

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 account` sends `account 1` 10000 ether **Block 2:** `test bank account` sends `account 1` 1000 ether `account 1` sends `account 2` 1000 ether `account 1` creates a `test contract account` **Block 3:** `test bank account` changes the storage variable `data`'s value at index 2 to 3 `account 2` mines the block, so gets the mining reward - The changes that were made to the contract included changing the name from `test` to `TestContract` and then compiling it with `pragma solidity ^0.5.0` - I'm not sure what the previous contract was compiled with. - After the previous changes to the contract, the following things changed: - contract byte code - block 2 hash - block 3 hash - the contract account's code hash - block 2: - 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) - block 3: - 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.
aaizuss (Migrated from github.com) reviewed 2019-09-16 15:17:28 +00:00
Gslaughl (Migrated from github.com) reviewed 2019-09-16 15:17:28 +00:00
m0ar (Migrated from github.com) reviewed 2019-09-16 15:17:28 +00:00
rmulhol (Migrated from github.com) reviewed 2019-09-16 15:17:28 +00:00
i-norden reviewed 2019-09-16 19:27:57 +00:00
i-norden left a comment
Member

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!

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!
elizabethengelman commented 2019-09-16 20:10:51 +00:00 (Migrated from github.com)

@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!

@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!
elizabethengelman commented 2019-09-18 17:20:04 +00:00 (Migrated from github.com)
closing this in favor of https://github.com/vulcanize/go-ethereum/pull/15

Pull request closed

Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: cerc-io/go-ethereum#14
No description provided.