cburgdorf on master
Enable PoW consensus for fully … (compare)
EthereumTesteras 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).
CALLis 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 
<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
@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 (
__init__calls than there are
apply_computationcalls (does this mean
__init__is called twice for some subclasses of
Any thoughts why that could be happening? Am I still monkey patching the right functions to track computations?
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
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.
self.logger.debug("BaseComputation.__init__ was called", stack_info=True)
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)
_stackand 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.
I've done some in-depth debugging and I think I know why there are 2 computations originating during the
1) one is the child computation that is immediately triggered by the call and
2) this child computation then calls
apply_message on itself
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 :).
Chain.import_block()return values changed (to include metadata about the state witness)
<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.
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
persist_block()to me. So I think that means we need:
persist_block(), it's possible to load a transaction body
persist_block(), it's possible to load a receipt body