Override of block number in eth_call and tracing

[t-anyu]

Hey,

Are there any methods to modify protected global variables such as block.number on debug calls? Or can this be done with EVM tool? For example I'd like to increment block.number during my solidity function call (debug call, not sending).

Or alternatively can I do joined debug_traceCalls, so that the EVM/geth remembers the state of my last call? Or perhaps if I could implement a special opcode to increment global variables on the contract call?

Thanks

[karalabe]

Or perhaps if I could implement a special opcode to increment global variables on the contract call?

Definitely not, it would break way too many thing and be too dangerous to keep around.

I'd like to increment block.number during my solidity function call (debug call, not sending).

What would be the purpose of that? Do you have an example?

can I do joined debug_traceCalls, so that the EVM/geth remembers the state of my last call?

There's no current functionality for it, but it did occur to me a few times that users might want trace a call on top of a intermediate state and it might be a good idea to allow it. Perhaps we could extend traceCall with an initial set of "prep" calls that mutates the state before the actual tracing?

[t-anyu]

Hey Karalabe,

The current purpose is to debugTrace my code which has protection (lock) mechanism based on block.number. Other purpose that I'm thinking about is for example detecting if a public live contract is malicious.

The prep calls would be very useful for my use case. And I think it would be the most flexible method.

The special opcode I was referring to would just be for my own usage but just wondered if there were better approaches.

Thanks

[fjl]

I think the request here is to have a way of overriding the block number seen by the EVM during eth_call and in tracing. This is a reasonable idea since we already allow other state overrides.

Question is mostly how we could encode it into the override parameter. At the moment, the override parameter is an object with account addresses as keys. There is no way to fit the block number in there. We would have to add another parameter with EVM overrides. It might also be useful to allow overriding the block timestamp and hash, for example.

[t-anyu]

Hey,

I'm not familiar with geth's code, but I would suggest using state override set used in eth_call.

[t-anyu]

Or perhaps if I could implement a special opcode to increment global variables on the contract call?

Definitely not, it would break way too many thing and be too dangerous to keep around.

I'd like to increment block.number during my solidity function call (debug call, not sending).

What would be the purpose of that? Do you have an example?

can I do joined debug_traceCalls, so that the EVM/geth remembers the state of my last call?

There's no current functionality for it, but it did occur to me a few times that users might want trace a call on top of a intermediate state and it might be a good idea to allow it. Perhaps we could extend traceCall with an initial set of "prep" calls that mutates the state before the actual tracing?

Hey karalabe,

I think the prep calls or ability to join multiple calls together will be quite useful here. I tried to examine a bit of geth's code: would prep calls or ability to execute multiple eth_calls with remembered state be realized for example by keeping statedb the same, but applying core.ApplyMessage(vmenv, message, ...) multiple times on the same vmenv instance? (api.go, line 898)

Thanks

[fjl]

I have created a new issue for your second request. Let's keep this issue about the first request, overriding the block number.

[DiveInto]

I think the request here is to have a way of overriding the block number seen by the EVM during eth_call and in tracing. This is a reasonable idea since we already allow other state overrides.

Question is mostly how we could encode it into the override parameter. At the moment, the override parameter is an object with account addresses as keys. There is no way to fit the block number in there. We would have to add another parameter with EVM overrides. It might also be useful to allow overriding the block timestamp and hash, for example.

"overriding the block timestamp" can be useful.

for orders with startTime & expirationTime constraints, if an order has a startTime > curBlock.timestamp, overriding the current block's timestamp will be helpful to test the match result at current block, instead of waiting for the order become valid.