You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're getting a lot of evm: transaction reverted error when running multiple validators on the testnets. It's a real problem because we have no idea what's failing, or where the errors are coming from.
There is a EVM tracer setup (see the Ethereum Tracing wiki and the code) which runs when the client is started with --vmdebug. It's possible to extract the opcodes for contract execution transactions... in a really hard to use way.
There is an interface for creating a custom tracer, and at least one example implementation. Implementations need to be registered at runtime, usually through a flag.
Since we know the addresses of the major contracts (kcoin addresses) and we have all the core contracts named in the KNS, we should be able to do something more useful that the default: we should be able to tracelog, by name, all contract call opcodes, right down to the point where they fail.
For bonus points, it seems like we could also produce a stacktrace to the original contract code.
The text was updated successfully, but these errors were encountered:
We're getting a lot of
evm: transaction reverted
error when running multiple validators on the testnets. It's a real problem because we have no idea what's failing, or where the errors are coming from.There is a EVM tracer setup (see the Ethereum Tracing wiki and the code) which runs when the client is started with
--vmdebug
. It's possible to extract the opcodes for contract execution transactions... in a really hard to use way.There is an interface for creating a custom tracer, and at least one example implementation. Implementations need to be registered at runtime, usually through a flag.
Since we know the addresses of the major contracts (
kcoin addresses
) and we have all the core contracts named in the KNS, we should be able to do something more useful that the default: we should be able to tracelog, by name, all contract call opcodes, right down to the point where they fail.For bonus points, it seems like we could also produce a stacktrace to the original contract code.
The text was updated successfully, but these errors were encountered: