18 days later, ACD is noisy because of the difficulty bomb. :/
TL;DR: There might be an out-of-schedule call on Friday.
py-evm... I want to do essentially what is done in this exercise: https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/ -- but using py-evm instead of pythereum, and using the nice boilerplate project template that you have in the cookbooks. My question is where in the py-evm API or source would I find the logic that does the same thing trie.py does in pyethereum? Or, perhaps I'm totally going about this the wrong way, in which case my question is even more general: What's a good starting place for simple DB/State/Trie understanding of the evm?
I just noticed an "early release" warning on the README of py-trie. That could be removed now. It is the library that py-evm uses, and has gone through a solid amount of testing at this point. It could be optimized a lot more, but I'm not generally concerned about correctness, at least for evm-specific configurations (like always using 32-byte keys).
Istanbul (and a couple other things) is released:https://py-evm.readthedocs.io/en/latest/release_notes.html#py-evm-0-3-0-alpha-9-2019-12-02
I have a feeling someone'll have to take over PR #1885 from me, or provide a lot of guidance.
The current lint failures are all for improper definitions/returns in low-level API classes: AccountDatabaseAPI, OpcodeAPI, VirtualMachineAPI; and some related abstract classes.
Take a look at this CI job most errors are an either-or choice, and I don't know which one is "correct".
There's also
eth/chains/base.py:250: error: Unexpected keyword argument "chain_context" for "VirtualMachineAPI"
eth/abc.py:2270: note: "VirtualMachineAPI" defined herewhich means something unexpected may be happening.
Trinity release coming shortly
https://py-evm.readthedocs.io/en/latest/release_notes.html#py-evm-0-3-0-alpha-11-2019-12-12
@/all Muir Glacier support is here:
Docs:
https://py-evm.readthedocs.io/en/latest/release_notes.html#py-evm-0-3-0-alpha-12-2019-12-19
Tweet:
https://twitter.com/ETHSnakeCharmer/status/1207686373282594817
https://py-evm.readthedocs.io/en/latest/release_notes.html#py-evm-0-3-0-alpha-13-2020-01-13
<Christoph> @Pet3ris I'm afraid I can not answer this without diving into the code myself. One thing I suggest is to run py-evm with log level 0 to get full tracing output. Then you'll see output such as: https://gist.github.com/cburgdorf/41ce3a9c9502d2f194c9e54454e6a689
You can search for the output in Py-EVM and sprinkle the code paths with breakpoint() statements and then use the debugger to examine from there. That's how I'd approach it.
vm.state.coinbase etc., but I'd like to find something like vm.current_transaction.computation.stack and vm.current_transaction.computation.memory to get other elements
def debug2(self, message: str, *args: Any, **kwargs: Any) -> None:
if self.debug:
if "COMPUTATION STARTING" in message:
ExtendedDebugLoggerWithBytecode.collected = []
print(len(ExtendedDebugLoggerWithBytecode.collected))
ExtendedDebugLoggerWithBytecode.collected.append((message, args, kwargs))
print(self.evm)
print(self.evm.chain)
print(self.evm.chain.get_vm().state)
print(self.evm.chain.get_vm().state.block_number)
ExtendedDebugLoggerWithBytecode.block_number = (
self.evm.chain.get_vm().state.block_number
)
print(self.evm.chain.get_vm().state.coinbase)Okay, so the part I'm still missing a bit is "why". Are you trying to answer a single question about the stack or memory? Or is there some other kind of motivation?
Right now, I've got:
- (some need?)
- Plan to patch the logger so that it outputs a bunch of information at each step (including stack and memory)
- Desire to access the computation of a "currently running transaction" from a logging context
So I'm wondering if there might be a different approach than 2. In general, the architecture is going to fight arbitrary inspection of some arbitrary thing that's currently happening. You'll usually need a reference to the object you want to know about. So 3 is going to be a pain. Assuming 2 is fixed, you might consider patching into the Computation object to generate logs from there instead. Or patching into the Executor to save a reference to the most recent generated computation somewhere. Both of these will have subtleties.
If 2 isn't fixed, then it depends a lot on what 1 is. Maybe if you're trying to answer a single question, then it could make sense to drop a conditional breakpoint in somewhere, or craft a transaction that generates the final state you want, etc, etc.
what would be the dangers? are there multiple computations potentially occuring within one transaction?
Yeah, not a danger, just something that might give confusing results without understanding carefully, since there are new computations created recursively, for example during CALL style opcodes.
