ethereum/py-evm

Eth-Gitter-Bridge

@Eth-Gitter-Bridge

<carver> (asked and answered on the trinity channel)

Peteris Erins

@Pet3ris

Hi There, is there a way to get the current executing computation/transaction from a State object? In particular I'd love to access the current stack contents, memory contents that seem to be embedded in the computation.

Eth-Gitter-Bridge

@Eth-Gitter-Bridge

<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.

Peteris Erins

@Pet3ris

Hi @Eth-Gitter-Bridge, thanks for your comment. I'm already using the debugger unfortunately and digging into the code. I just wasn't able to find a way to access the ongoing computation. I've found a way to access the Execution Environment, simply 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

Jason Carver

@carver

@Pet3ris do you mean in between transactions or mid-transaction? There's no concept of a "current transaction", the VM is not stateful in that way. But if you're curious in between transactions, there are more options besides breakpoints. If you can share an example showing what you are trying to inspect, I can help more.

Peteris Erins

@Pet3ris

@carver yep - what I'm trying to do is to monkey patch the debug2 function to inspect intermediate EVM state

for example, I can get anything from the ExecutionContext like so:

        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)

Jason Carver

@carver

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.

Peteris Erins

@Pet3ris

@carver it's for debugging transactions

I'm trying to generate a full trace of EVM state changes

I like the idea of patching Executors/Computation classes

what would be the dangers? are there multiple computations potentially occuring within one transaction?

2 isn't necessarily fixed though - key thing is to be able to get the state at each opcode

because the logger outputs at each opcode, I thought that was an obvious location to patch in

Jason Carver

@carver

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.

Peteris Erins

@Pet3ris

oh that's right - so basically each message will have an associated computation, i.e., multiple per transaction?

Jason Carver

@carver

yup :+1:

Jason Carver

@carver

Yeah, I can see how the logger would be an appealing place to hook into apply_computation, because the opcodes are dispersed, there's not a common path to inject in a single place. So yeah, I guess my next approach would be to patch Computationwith a custom apply_computation.

Peteris Erins

@Pet3ris

that makes sense, thanks!

Jason Carver

@carver

you bet! :+1:

lzhou1110

@lzhou1110

Hi, I'm a research student currently doing some work on Fuzzing. I would like to understand if it is possible to, and how to: 1) get detailed trace info of a transaction I execute in py-evm, so I can determine how it read and write to the storage. 2) if I can fork a particular state from the main net blockchain, given a block number. Searched a bit but couldn't find where shall I start. Any suggestions? Thanks!

Eth-Gitter-Bridge

@Eth-Gitter-Bridge

<carver> Right now, the best tool for tracing transactions is to enable debug2 logs, and filter the lines you care about from the logs.

<carver> If you want a particular historical state, the only way to get it right now is to full sync from genesis. Note that this will take a long time, and a lot of disk space. If you want state at the tip of the chain, use Beam Sync, and as soon as the first block is imported, you can access all the state that is written or read during that block's execution.

Eth-Gitter-Bridge

@Eth-Gitter-Bridge

<Christoph> @lzhou1110 if you write a script you can put something like this at the top

import logging
import sys
logging.basicConfig(stream=sys.stdout, level=0)

If you are running tests you can run pytest with --log-cli-level 0

Peteris Erins

@Pet3ris

is there a flag to see if the current transaction/computation is part of gas estimation or the "real" transaction in py-evm?

Eth-Gitter-Bridge

@Eth-Gitter-Bridge

<carver> No, during execution they are indistinguishable AFAIK. You can only tell higher up the call stack that executing the transaction was invoked by the gas estimator.

<carver> @Pet3ris

Peteris Erins

@Pet3ris

gotcha - no problem, good to know

Anirudha Bose

@onyb

Hello folks. I want to help out with improving the secp256k1 implementation here: https://github.com/ethereum/py_ecc/blob/master/py_ecc/secp256k1/secp256k1.py, and also add some (badly needed) tests + docs. If someone has ideas, let's discuss!

Anirudha Bose

@onyb

Or perhaps the aforementioned module is deprecated in favour of https://github.com/libp2p/py-libp2p/blob/master/libp2p/crypto/secp256k1.py ?

Eth-Gitter-Bridge

@Eth-Gitter-Bridge

<Brian (lithp)> @Piper , @carver , if either of you are around wonder if I could ask about CodeStream, I wonder what the is_valid_opcode method is doing: https://github.com/ethereum/py-evm/blob/master/eth/vm/code_stream.py#L75

<Brian (lithp)> Figured that I can try to puzzle it out or it might be faster to ask you directly

<Brian (lithp)> I'm trying to figue out if I should also track these reads when deciding how much code needs to be put into a witness

<carver> It makes sure that the target opcode is actually an opcode, and not a byte of data from a PUSH instruction

<carver> Oh, and I have a guess why you're asking: trying to figure out which bytes of the bytecode are being used during a call, right?

<Brian (lithp)> Yeah 🙂

<carver> Yeah, that will be an interesting component of it

<carver> Because not everyone implements this check the same way right now

<Brian (lithp)> Okay, so if I seek to a location I'll be given data which might look like an opcode, but if it's actually part of a data being passed to a PUSH instruction then it's not a valid jump destination?

<carver> right

<Brian (lithp)> That sounds like something which does need to be included in the witness 🤔

<carver> yup

<Brian (lithp)> Do you remember how different the Geth check is?

<carver> They might even do the "naive" thing?

<carver> Just roll forward from the start

<Brian (lithp)> That works because there's some kind of terminator we could look for?

Eth-Gitter-Bridge

@Eth-Gitter-Bridge

<carver> By "roll forward from the start" I mean something like:

advance a cursor to the first byte
mark byte under the cursor as valid
is the byte under the cursor the byte that you want to jump to?
- yes? then the destination is valid, exit.
- no? continue to step 4
load the opcode for at the cursor
is the loaded opcode a pushN?
- no: advance the cursor by one, continue on at step 2
- yes: mark the next N bytes as invalid, advance the cursor by N+1, continue at step 2

<Brian (lithp)> Oh no. Geth does it by reading the entire contract and precomputing the valid code segments

<Brian (lithp)> Hah, beat me to it by a little bit 😅

<carver> lol

Where communities thrive

People

Repo info

Activity