-
Notifications
You must be signed in to change notification settings - Fork 795
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, remove EEI: cleanup statemanager #2702
Conversation
Codecov Report
Additional details and impacted files
Flags with carried forward coverage won't be shown. Click here to find out more. |
Will use this comment as a scratchpad otherwise I will lose my line of thinking, so ignore this comment. For Maybe for the access list just change the behavior: keep track of a set, each time a new slot is touched (whether it is reverted or not) just put it on the access list, this simplifies it a lot. |
st.deepEqual(origRes, value) | ||
|
||
st.end() | ||
}) | ||
|
||
t.test("getOriginalContractStorage should validate the key's length", async (st) => { | ||
try { | ||
await (<any>stateManager).getOriginalContractStorage(address, new Uint8Array(12)) | ||
await (<any>stateManager).originalStorageCache.getOriginalContractStorage( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same
packages/vm/src/runTx.ts
Outdated
state.addWarmedStorage(address, toBytes(storageKey)) | ||
this.evm.evmJournal.addPreWarmedSlot(accessListItem.address, storageKey, true) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't fully grasp the accessListItem logic of this code section, but is it intentional that we're refactoring addWarmedStorage
to addPreWarmedSlot
(since we have a addWarmedStorage
method on the evmJournal)?
EDIT: nevermind, seems fine based on other comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will explain at the call tomorrow, but the pre-warmed addresses and "normal" warmed addresses behave differently, in the sense that pre-warmed addresses can never be marked cold again, but "normal" warmed addresses can (if a call frame reverts).
@@ -474,7 +474,7 @@ tape('runTx() -> runtime behavior', async (t) => { | |||
await vm.runTx({ tx }) // this tx will fail, but we have to ensure that the cache is cleared | |||
|
|||
t.equal( | |||
(<any>vm.stateManager)._originalStorageCache.size, | |||
(<any>vm.stateManager).originalStorageCache.map.size, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the ` necessary?
packages/vm/test/util.ts
Outdated
;(<any>state).touchedJournal.clear() | ||
//;(<any>state).touchedJournal.clear() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Intentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes, in this method the state is setup via StateManager, not EVM (so there are no touched accounts). Therefore this cleanup action is not necessary. Should remove anyways.
clearOriginalStorageCache(): void { | ||
this.map = new Map() | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would have a tendency to drastically shorten the names here, so just use get
, put
and clear
. 😋
Think that makes the API more elegant and readable and what this does can be taken very much from the context, so e.g. this._stateManager.originalStorageCache.get(...)
(still long enough 🙂).
packages/evm/src/evmJournal.ts
Outdated
//AddressString | Map<AddressString, SlotString> | ||
type JournalHeight = number | ||
|
||
export class EvmJournal { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here as well, I would suggest to just name Journal
and also simplify the file name evmJournal.ts
-> journal.ts
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should I rename evm.evmJournal
to evm.journal
as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would vote yes! 🙂
…eumjs-monorepo into cleanup-statemanager-v2
Ok, I should have resolved most review items except if I should rename Furthermore, I have removed I have also cleaned up the method names of |
And possibly |
Was very much a quick-shot 😋, I think I still find it substantially easier to grasp though, also on second thought (preWarmed can lead thoughts somewhat in a wrong direction). |
Yup, have addressed! |
Short in-between note: I now synced with this branch > block 1Mio with the client, no anomalies to detect. 🙂 |
@@ -10,6 +10,7 @@ import { trap } from './opcodes' | |||
import { Stack } from './stack' | |||
|
|||
import type { EVM, EVMResult } from './evm' | |||
import type { Journal } from './journal' | |||
import type { AsyncOpHandler, OpHandler, Opcode } from './opcodes' | |||
import type { Block, Blockchain, Log } from './types' | |||
import type { Common, EVMStateManagerInterface } from '@ethereumjs/common' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Debug logger from below, currently evm:eei:gas
(so annying this untouched-lines-comment-deactivation), should be renamed.
Simply evm:gas
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, evm:gas
is perfect. I will do a quick check to see if there are any other eei leftovers.
Cool! I also wonder slightly about performance, did you notice anything? We could also do a quick test with disk reads before/after this PR. It should decrease (and hopefully a lot! :) ) |
Performance is always hard to grasp, so I am getting more and more cautious to do any early statements here. Doing catch-up-execution right now (by deactivating block sync), at ~1.2 Mio (Homestead) atm, everything still running smoothly atm, though block execution has gotten a bit slower, but that's also always dependent of the respective usage of the respective block parts. I wanted to sync into the "problematic ranges" again, that start in the ~ 1.6 Mio or so block numbers. These are always easier to compare, since base execution numbers for a single block are already pretty high. Also not totally meaningful then (since single blocks/txs are often targeting very specfic EVM functionality). So at the end best is always to do 2-4 different ranges. |
Nice, I really like the API simplifications! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great with the additional edits!
Follow-up of #2649
This PR intends to remove all EVM-related logic from state manager, in particular:
This PR will also:
getOriginalContractStorage
common
EthersStateManager
is compatible withEVMStateManagerInterface
and is thus able to also run VM (@holgerd77 could you check this?)Super WIP