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

Misleading storage after a contract suicides #40

Open
ankitchiplunkar opened this issue Jun 21, 2018 · 0 comments
Open

Misleading storage after a contract suicides #40

ankitchiplunkar opened this issue Jun 21, 2018 · 0 comments

Comments

@ankitchiplunkar
Copy link
Contributor

Describe the bug
After a contract suicides the storage_diff table should verify that the positions associated to the contract have been removed. Due to the way trace_replayTransactions returns contract suicide openethereum/parity-ethereum#8937, these storage positions are not wiped out.

To Reproduce
Steps to reproduce the behavior:

  1. Fill the required blocks in the database.
$ # Block that creates the contract
$ ether_sql scrape_block --block_number=54300
$ # Block that suicides the contract
$ ether_sql scrape_block --block_number=54316
  1. Check the storage_diff table in the database:
ether_sql=# select * from storage_diff where address = '0x506F4b138E30f4ed0b9511d4D676EAaECa466983';

 id  | block_number |      timestamp      |                          transaction_hash                          | transaction_index | state_diff_id |                  address                   |                              position                              | storage_from |                             storage_to                             
-----+--------------+---------------------+--------------------------------------------------------------------+-------------------+---------------+--------------------------------------------+--------------------------------------------------------------------+--------------+--------------------------------------------------------------------
 574 |        54300 | 2015-08-08 16:38:54 | 0x12945faff5df252934cfbc25353dbecf2175b5017a3990bb764b44b7cc763547 |                 0 |         70360 | 0x506F4b138E30f4ed0b9511d4D676EAaECa466983 | 0x0000000000000000000000000000000000000000000000000000000000000000 |              | 0x0000000000000000000000002d11763b4999fb3b61ca8d19c8c77a743079f7bd
 575 |        54300 | 2015-08-08 16:38:54 | 0x12945faff5df252934cfbc25353dbecf2175b5017a3990bb764b44b7cc763547 |                 0 |         70360 | 0x506F4b138E30f4ed0b9511d4D676EAaECa466983 | 0x0000000000000000000000000000000000000000000000000000000000000001 |              | 0x000000000000000000000000000000000000000000000000000000000000000c
 576 |        54300 | 2015-08-08 16:38:54 | 0x12945faff5df252934cfbc25353dbecf2175b5017a3990bb764b44b7cc763547 |                 0 |         70360 | 0x506F4b138E30f4ed0b9511d4D676EAaECa466983 | 0xb10e2d527612073b26eecdfd717e6a320cf44b4afac2b0732d9fcbe2b7fa0cf6 |              | 0x48656c6c6f20576f726c64210000000000000000000000000000000000000000
(3 rows)

The storage_diff rows that demonstrate deleting the positions in the contract address are missing.

Expected behavior
The storage_diff table should have extra rows to show the clean_up after the contract suicides.

Options to resolve the issue

  1. The best option would be to resolve the issue in parity Misleading storage from trace_replayTransactions upon executing suicide on contract openethereum/parity-ethereum#8937 itself.
  2. If code_to goes to Null during filling the state_diff table, we should ask the database for currently existing storage positions associated to the address and clean them as well. This would require finding existing positions in the database, which is a costly operation. (Note: till block 5,826,976 there were contracts 6,829,008 and 2,767,4816 suicides ~ 1:2)
  3. Ignore the storage of accounts with no code, this is a hack, not advisable but easiest to implement until option 1 becomes a possibility.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant