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

EVM: simplify and fix evm storage #831

Merged
merged 2 commits into from
Nov 11, 2022
Merged

EVM: simplify and fix evm storage #831

merged 2 commits into from
Nov 11, 2022

Conversation

Stebalien
Copy link
Member

  1. The EVM doesn't distinguish between "exists" and "doesn't exist".
  2. There was some interesting dead code.
  3. Only mark the state-tree dirty if something has changed.

fixes the second half of filecoin-project/ref-fvm#912

Copy link
Contributor

@mriise mriise left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There isn't really a good reason to be tracking storage status of an item unless you are doing analysis of the values, though at that point you could view the blockstore changes directly and build tooling to analyze at that layer (like we currently do with our memory analysis graphs). 👍

1. The EVM doesn't distinguish between "exists" and "doesn't exist".
2. There was some interesting dead code.
3. Only mark the state-tree dirty if something has changed.
Copy link
Contributor

@vyzo vyzo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uh oh problems here?

let opt_value = if value == U256::zero() { None } else { Some(value) };

system.set_storage(location, opt_value)?;
system.set_storage(state.stack.pop(), state.stack.pop())?;
Copy link
Contributor

@vyzo vyzo Nov 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, this is potential undefined behavior with the pops.
Does rust mandate left to right evaluation order for args?
In any othe language you've shot yourself in the foot here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

left -> right, in -> out. Yes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uhm ok, interesting.
Can we still either pop first to named or add a comment regardless?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, we can pop first. I agree that it does make the pop order clearer.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@vyzo vyzo Nov 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have to say, it is highly unusual of high perf languages to do that.

The compiler is allowed to go bersek here, ocaml does right to left, some C compilers do whatever works faster situationally, and in scheme you are expelled if you assume evaluation order :)

None => U256::zero(),
};
state.stack.push(value);
state.stack.push(system.get_storage(location)?);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

error? Doesnt evm zero for everything?
Ot is it internal now?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a fatal "something is really broken" error (same as before).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, do we have a test for this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No? This is a "the HAMT is corrupted" error. I.e., there's a bug.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, no need to bother then.

Ok(self
.slots
.get(&key)
.map_err(|e| StatusCode::InternalError(e.to_string()))?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

get of something not existing is just zero.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. In the EVM, all storage "exists", it's just all zeros.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same re test.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the fixed test below.

Copy link
Contributor

@vyzo vyzo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you.

Lets make sure we got a test or two about boundary behaviour.

@Stebalien
Copy link
Member Author

Lets make sure we got a test or two about boundary behaviour.

Well, there was a test. It was just wrong.

@codecov-commenter
Copy link

Codecov Report

Merging #831 (914514a) into next (a56108c) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

❗ Current head 914514a differs from pull request most recent head f8b75bc. Consider uploading reports for the commit f8b75bc to get more accurate results

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             next     #831      +/-   ##
==========================================
- Coverage   87.50%   87.49%   -0.01%     
==========================================
  Files         125      125              
  Lines       22649    22634      -15     
==========================================
- Hits        19818    19803      -15     
  Misses       2831     2831              
Impacted Files Coverage Δ
actors/evm/src/interpreter/instructions/storage.rs 100.00% <100.00%> (ø)
actors/evm/src/interpreter/system.rs 90.30% <100.00%> (+0.01%) ⬆️
actors/evm/src/lib.rs 78.02% <100.00%> (-1.22%) ⬇️
actors/reward/src/lib.rs 82.92% <0.00%> (-0.82%) ⬇️
actors/power/src/lib.rs 83.62% <0.00%> (-0.22%) ⬇️
test_vm/src/lib.rs 84.24% <0.00%> (+0.10%) ⬆️
actors/eam/src/lib.rs 85.13% <0.00%> (+0.67%) ⬆️
actors/cron/src/lib.rs 93.10% <0.00%> (+3.44%) ⬆️

@Stebalien Stebalien merged commit 137c447 into next Nov 11, 2022
@Stebalien Stebalien deleted the steb/fix-evm-storage branch November 11, 2022 01:48
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

Successfully merging this pull request may close these issues.

4 participants