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.
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).
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
[]<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 aCALL(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 areapply_computationcalls (does this mean__init__is called twice for some subclasses ofBaseComputation?
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 patchComputationwith a customapply_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.
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)_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.
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
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 :).
https://github.com/ethereum/py-evm/blob/086e0704a8d2da5f8f0a64d708d8830d1015895d/eth/vm/computation.py#L372-L376
ethereum/py-evm#1921
Note that
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
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 body2) a test that after a
persist_block(), it's possible to load a receipt body3) implement something like these lines in
persist_block() https://github.com/ethereum/py-evm/blob/6fef9c25eff570471d147a4f4a6d4eba00262f57/eth/vm/base.py#L321-L3254) 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
