Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 17:08
    carver edited #1980
  • Mar 03 23:24
    carver edited #1980
  • Mar 03 23:03
    carver synchronize #1980
  • Mar 03 22:53
    carver synchronize #1980
  • Mar 03 20:41
    carver synchronize #1980
  • Mar 03 20:36
    carver opened #1980
  • Mar 02 19:26
    carver commented #1975
  • Mar 02 18:37
    carver edited #1978
  • Mar 02 18:37
    carver assigned #1975
  • Mar 01 17:38
    carver assigned #1974
  • Mar 01 17:38
    carver edited #1970
  • Mar 01 17:37
    carver commented #1926
  • Mar 01 17:36
    carver commented #1976
  • Mar 01 17:35
    kclowes added as member
  • Mar 01 17:34
    carver commented #1976
  • Mar 01 17:34

    carver on master

    EIP-2565 calculation of modexp … Add newsfragment EIP 2565 Merge pull request #1976 from k… (compare)

  • Mar 01 17:34
    carver closed #1976
  • Mar 01 17:34
    carver closed #1972
  • Mar 01 17:34
    kclowes commented #1976
  • Feb 26 22:02
    kclowes synchronize #1976
Alan Justino da Silva
@alanjds

It's in alpha, so it's not production-ready. @alanjds
Also, if you want to run a node, check out trinity which uses py-evm under the hood, but also handles all the peering, json-rpc, etc (also in alpha, of course)

Tkx, @carver. I will take a look.

Jason Carver
@carver
@/all posted a new release, for the last known Istanbul bug
https://py-evm.readthedocs.io/en/latest/release_notes.html#py-evm-0-3-0-alpha-11-2019-12-12
Just some guy
@fubuloubu
famous last words lol
Jason Carver
@carver
heh
Voith Mascarenhas
@voith
:tada:
Christoph Burgdorf
@cburgdorf
@KjetilVaa What is your question regarding Clique?
Christoph Burgdorf
@cburgdorf
Related: We've just released a new Py-EVM version that refactors consensus handling to make it more flexible and sound.
https://py-evm.readthedocs.io/en/latest/release_notes.html#py-evm-0-3-0-alpha-13-2020-01-13
Suraj Singla
@surajsingla333
Hi all, I am creating a python script that will list all the peer nodes connected to the bootnode which I will provide. Can anyone help me with how I can list all the peer nodes using trinity?
Thanks
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:

  1. (some need?)
  2. Plan to patch the logger so that it outputs a bunch of information at each step (including stack and memory)
  3. 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 🤔