by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 13:07
    cburgdorf review_requested #1932
  • 13:05
    cburgdorf edited #1932
  • 13:04
    cburgdorf edited #1932
  • 12:59
    cburgdorf synchronize #1932
  • 12:57
    cburgdorf synchronize #1932
  • 12:49
    cburgdorf synchronize #1932
  • 12:46
    cburgdorf synchronize #1932
  • 12:22
    cburgdorf synchronize #1932
  • 12:19
    cburgdorf synchronize #1932
  • 12:14
    cburgdorf synchronize #1932
  • 07:16
    cburgdorf closed #1881
  • 07:16
    cburgdorf commented #1881
  • 07:06

    cburgdorf on master

    Enable PoW consensus for fully … (compare)

  • 07:06
    cburgdorf closed #1931
  • 00:05
    Peppece commented #1881
  • May 22 00:42
    carver synchronize #1930
  • May 21 02:46
    pipermerriam commented #1930
  • May 21 00:24
    carver commented #1930
  • May 21 00:24
    carver commented #1930
  • May 21 00:24
    carver commented #1930
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Brian (lithp)> An idea Piper mentioned is that if we're going to merkelize code into chunks we can prepend each chunk with a byte, "the offset to the first byte in this chunk which is a valid jumpdest"
ArtObr
@ArtObr
Hi there, does anyone know if there some tests in py-evm on contract uploading and executing it's code?
All I was able to find is:
tests/core/vm/test_vm.py #test_apply_transaction, but there is no case with some transaction data
and
tests/core/transaction-utils/test_transaction_signature_validation.py #test_unsigned_to_signed_transaction, there is txn with data, but it does not applying.
I spent some time trying to execute simple set/get contract, but I failed. (tried with solc, remix compiling)
Can anyone give me a tip on a workable way to execute contract with py-evm or show test cases?
Much appreciated.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<carver> If you're interested in deploying and using contracts, then web3.py might be the best level of abstraction. If you use EthereumTester as the chain "provider" in web3.py, then it does end up using py-evm under the hood (in case you're interested in hacking on the evm beyond simple contract deployment/interaction).
ArtObr
@ArtObr
Thank you for answer, I will try to look deeper in that.
I've tried to deploy contract without EthereumTester and web3.py. Is this possible (with only py-evm)?
Peteris Erins
@Pet3ris
Hi There! I'm noticing that when a contract CALL is issued by py-evm (internal CALL), two new computations are created immediately. Anyone know why is that the case?
49
Op: GAS
[384, 2, 672, 33, 33, 768, 33, 672, 0, 4]
49
Op: CALL
[384, 2, 672, 33, 33, 768, 33, 672, 0, 4, 113796]
New computation started
<eth.vm.forks.constantinople.computation.ConstantinopleComputation object at 0x10d237bd0>
New computation started
<eth.vm.forks.constantinople.computation.ConstantinopleComputation object at 0x10d32c2d0>
50
Op: PUSH2
[]
Peteris Erins
@Pet3ris
moreover they both seem to be using the same message computation.msg
Peteris Erins
@Pet3ris
one of the computations terminates immediately which suggests to me that it's calling a pre-compiled contract, but the other one is not terminated. By termination I mean that it's apply_computation function returns
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<carver> > I've tried to deploy contract without EthereumTester and web3.py. Is this possible (with only py-evm)?

It's easy to add a transaction in py-evm, but it's not easy to build that transaction to invoke a contract. Those transaction-building tools are mostly in web3.py. They help you build the data that goes into a transaction and then sign it. @ArtObr

<carver> @Pet3ris Hm, the double-computation thing doesn't sound familiar. Calling into a precompile doesn't sound right, I don't think computations are created at all for them: https://github.com/ethereum/py-evm/blob/086e0704a8d2da5f8f0a64d708d8830d1015895d/eth/vm/computation.py#L531-L534
Peteris Erins
@Pet3ris

@Eth-Gitter-Bridge that's very helfpul re: precomputed contracts. Maybe this is just an internal call. Effectively what I'm trying to do is to keep track of the current computation by maintaining a stack of computations. When BaseComputation.__init__ is called, I add to the stack and when a BaseComputation.apply_computation is finished, I remove the top computation from the stack.

But I'm observing the following:

  • BaseComputation.__init__ called twice if the current Opcode is a CALL (and both times with the same message), only one of those computations then has a state that updates (_stack, etc.)
  • over time, there are more __init__ calls than there are apply_computation calls (does this mean __init__ is called twice for some subclasses of BaseComputation?

Any thoughts why that could be happening? Am I still monkey patching the right functions to track computations?

Peteris Erins
@Pet3ris

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.

Just for context - I'm following your suggestion in terms of managing computations (and it is working well in general) but I couldn't use apply_computation for adds because it kicked in too early so needed to go exactly to the point where computation is constructed.

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<carver> Hm, not sure why. It's plausible the double-init is some kind of bug (in the form of extra useless work that's happening). My next step would probably be a breakpoint, or a logger with the calling stack's info, like a self.logger.debug("BaseComputation.__init__ was called", stack_info=True)
Peteris Erins
@Pet3ris
gotcha - will try that!
Peteris Erins
@Pet3ris
interestingly both originate from the CALL opcode
the stack traces look absolutely identical
File "/Users/p/.local/share/virtualenvs/api-QuiCHkzb/lib/python3.7/site-packages/eth/chains/base.py", line 899, in apply_transaction
    receipt, computation = vm.apply_transaction(base_block.header, transaction)
  File "/Users/p/.local/share/virtualenvs/api-QuiCHkzb/lib/python3.7/site-packages/eth/vm/base.py", line 468, in apply_transaction
    computation = self.state.apply_transaction(transaction)
  File "/Users/p/.local/share/virtualenvs/api-QuiCHkzb/lib/python3.7/site-packages/eth/vm/state.py", line 323, in apply_transaction
    return self.execute_transaction(transaction)
  File "/Users/p/.local/share/virtualenvs/api-QuiCHkzb/lib/python3.7/site-packages/eth/vm/forks/frontier/state.py", line 200, in execute_transaction
    return executor(transaction)
  File "/Users/p/.local/share/virtualenvs/api-QuiCHkzb/lib/python3.7/site-packages/eth/vm/state.py", line 372, in __call__
    computation = self.build_computation(message, valid_transaction)
  File "/Users/p/.local/share/virtualenvs/api-QuiCHkzb/lib/python3.7/site-packages/eth/vm/forks/frontier/state.py", line 138, in build_computation
    transaction_context).apply_message()
  File "/Users/p/.local/share/virtualenvs/api-QuiCHkzb/lib/python3.7/site-packages/eth/vm/forks/frontier/computation.py", line 76, in apply_message
    self.transaction_context,
  File "/Users/p/Dev/auditless/auditless-debugger/api/src/endpoints.py", line 399, in apply_computation
    computation = old_apply_computation(cls, state, message, transaction_context)
  File "/Users/p/.local/share/virtualenvs/api-QuiCHkzb/lib/python3.7/site-packages/eth/vm/computation.py", line 703, in apply_computation
    opcode_fn(computation=computation)
  File "/Users/p/.local/share/virtualenvs/api-QuiCHkzb/lib/python3.7/site-packages/eth/vm/logic/call.py", line 137, in __call__
    child_computation = computation.apply_child_computation(child_msg)
  File "/Users/p/.local/share/virtualenvs/api-QuiCHkzb/lib/python3.7/site-packages/eth/vm/computation.py", line 505, in apply_child_computation
    child_computation = self.generate_child_computation(child_msg)
  File "/Users/p/.local/share/virtualenvs/api-QuiCHkzb/lib/python3.7/site-packages/eth/vm/computation.py", line 520, in generate_child_computation
    self.transaction_context,
  File "/Users/p/Dev/auditless/auditless-debugger/api/src/endpoints.py", line 418, in new__init__
    logging.warning("Base Computation init was called.", stack_info=True)
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<carver> Huh, interesting. So that maybe/probably means it's not a "extra useless work" bug. Any more information about the types of computations that are never updating their _stack and other variables that you're expecting? Is it the first of two sub-calls made by contracts? Is it contract creation calls? I guess I would move forward assuming that these are real calls, unless it becomes more obvious that something is broken.
Peteris Erins
@Pet3ris
weirdly there is only one CALL
statement after which 2 computations are created, nearly identical, and only one of them goes on to update their state
the reason I suspect something is broken is that the computations don't end up being "closed", e.g., I have more computations open than closed even for terminated transactions so clearly the number of BaseComputation.init statements exceeds the number of apply_computation statements
Peteris Erins
@Pet3ris

I've done some in-depth debugging and I think I know why there are 2 computations originating during the CALL:

1) one is the child computation that is immediately triggered by the call and generate_child_computation

https://github.com/ethereum/py-evm/blob/bc476b21928b5f732ce980da9cc8fb9e4fbd9f3a/eth/vm/computation.py#L366

2) this child computation then calls apply_message on itself

3) apply_message calls apply_computation

4) apply_computation then creates another new computation with the same parameters.

This bit is probably the confusing bit for me. We create a computation only to call apply_computation on it which then recreates the computation and runs it again? It does seem like this is not a bug, but intentional and I can definitely work around it :).

Peteris Erins
@Pet3ris
managed to make a workaround and it's all good :)
thanks for the debugging tips!
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<carver> FWIW, I just got a chance to poke around and I think you're right: it would be cleaner to not create the computation here, which ends up getting thrown away:
https://github.com/ethereum/py-evm/blob/086e0704a8d2da5f8f0a64d708d8830d1015895d/eth/vm/computation.py#L372-L376
<carver> I just opened up a PR to try out a change that would prevent the extra Computation creation:
ethereum/py-evm#1921
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<carver> Oh, and I was wrong about the precompiles, a Computation object is created for them (as it should be, I think)
Peteris Erins
@Pet3ris
awesome 👍
Jason Carver
@carver
@/all v0.3.0-alpha.15 is out https://py-evm.readthedocs.io/en/latest/release_notes.html#py-evm-0-3-0-alpha-15-2020-04-14
Note that Chain.import_block() return values changed (to include metadata about the state witness)
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<carver> @keri you mentioned waiting on the py-evm release for an eth-keys version fix in web3. It's in this ^
<keri> Yahoo! Thank you!
Bryant Eisenbach
@fubuloubu
will py-evm ever go beta?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<carver> Yeah, it's probably not too far, really.
Bryant Eisenbach
@fubuloubu
it's been like, 2.5 years? lol
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<carver> haha
Noel Maersk
@veox
[META] The activity sidebar in gitter shows last entry on Jan 31 2019; in this channel and web3.py's, but not in trinity. :/
Obviously, it's nothing critical (I only just noticed :D), still, "strange".
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Christoph> I took a dive into Py-EVM and wanted to figure something out regarding back filling of blocks. It seems to me that our current Py-EVM APIs aren't fully capable of backfilling blocks without executing them but maybe I'm wrong about that.

In particular, what I'm looking at is how transactions are currently stored. It seems to me that set_block_transactions is the place where we deal with RLP encoding transactions and storing them in the db.

https://github.com/ethereum/py-evm/blob/6fef9c25eff570471d147a4f4a6d4eba00262f57/eth/vm/base.py#L315-L322

But this is only being done on the VM level during the execution of blocks. If all I want is to backfill ancient blocks (because we are beam syncing) then just calling something like persist_block wouldn't do the trick when it comes to storing the actual transactions in the db. Is my assumption correct here or am I missing something? @carver

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<carver> > just calling something like persist_block wouldn't do the trick when it comes to storing the actual transactions in the db.
Hm, yes, but that sounds like a bug in persist_block() to me. So I think that means we need:
1) a test that after a persist_block(), it's possible to load a transaction body
2) a test that after a persist_block(), it's possible to load a receipt body
3) implement something like these lines in persist_block() https://github.com/ethereum/py-evm/blob/6fef9c25eff570471d147a4f4a6d4eba00262f57/eth/vm/base.py#L321-L325
4) make sure the transaction root and receipt root in the built tries here ^ match the claimed roots in the header (before persisting them to disk)
This is definitely a place where I'd want to see the red tests from 1 and 2 before implementing 3 and 4
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph> Cool! That makes sense. I opened an issue about it ethereum/py-evm#1925
solutionzzz
@solutionzzz
greetings yall.
i just need a simle way to convert a private key to an address, kinda new any help is appreciated
*simple
Nick Gheorghita
@njgheorghita
@solutionzzz eth-account has a feature that makes this pretty easy. https://eth-account.readthedocs.io/en/stable/eth_account.html#eth_account.account.Account.from_key
Peppece
@Peppece
Hey! How would a complete beginner go about understanding source code in order to start helping with issues?
I know python but I don't know what files to read in order to understand how the EVM works
arjuna sky kok
@arjunaskykok_gitlab
@Peppece There are many ways to tackle this problem. One of the easiest ways is to start by reading the tests so you can understand the API. Once you become familiar, you can read the core: https://github.com/ethereum/py-evm/tree/master/eth. Skim it. Then choose one of the categories you are most interested to. Say, you choose consensus. Then you can focus there. Finally, read the commits like you read news, so you can get sense where the wind blows in py-evm development.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph> @Peppece Python 3.6 is the lowest supported Python version but you can also use Python 3.7
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<carver> @peppece another option to consider is to go kind of outside-in. Getting familiar with the web3.py API, then the json-rpc API, then the chain API, so on until you are digging into evm internals to understand how it works. Also look for "good first issue" tags across the projects, which can help you get familiar with the tangential (but necessary!) parts of the process of contributing to the projects, like how we use testing and linting tools, etc.