Conversation
This is an API which returns the currently implemented version of the Otterscan API (`ots_*`). The frontend checks this number is high enough before trying to do anything else. The current minimum version in the frontend is `8`, so we return `8`.
To do this, we add a new `contractCreators` database which stores a map of contract addresses to the transaction hash in which that contract was created. This allows us to look up the creator of the contract in most cases by using the `from` address of the creation transaction. Note that this doesn't work for contracts which have been deployed by other contracts. The API documentation specifically mentions we should support this, so I've left a `FIXME` for now. To do this, we'll probably want to extend the data stored when we create a contract to also track the immediate caller (and thus the contract creator).
| } | ||
| } | ||
|
|
||
| fn get_create_address( |
There was a problem hiding this comment.
now a requirement of handler via the evm PR
There was a problem hiding this comment.
Is get_create_address actually used anywhere in this PR? I can't find any usages.
There was a problem hiding this comment.
In the other PR that adds evm functionality it adds it as a handler fn and is used there impl<'a> Handler for CpsExecutor<'a>
|
|
||
| match exit_reason { | ||
| evm::ExitReason::Succeed(_) => {} | ||
| evm::ExitReason::Revert(_) => { |
There was a problem hiding this comment.
when tx fails, capture error blob
| struct LoggingEventListener { | ||
| call_tracer: Vec<CallContext>, | ||
| raw_tracer: StructLogTopLevel, | ||
| otter_internal_tracer: Vec<InternalOperationOtter>, |
There was a problem hiding this comment.
reuse transaction trace struct
|
|
||
| cd tests/EvmAcceptanceTests/ | ||
| npm install | ||
| DEBUG=true MOCHA_TIMEOUT=20000 npx hardhat test |
There was a problem hiding this comment.
this has effect of not interleaving the hardhat output with the iso server output, it just dumps it after
JamesHinshelwood
left a comment
There was a problem hiding this comment.
Overall, LGTM.
Probably makes sense for someone more qualified in C++/ZQ1 to have a review too. @Steve-White-UK ?
| } | ||
| } | ||
|
|
||
| fn get_create_address( |
There was a problem hiding this comment.
Is get_create_address actually used anywhere in this PR? I can't find any usages.
|
Will test this branch manually too |
Steve-White-UK
left a comment
There was a problem hiding this comment.
I so no reason not to merge to master if James is happy with that.
|
|
||
| Json::Value parsed; | ||
|
|
||
| auto const item = trace_json["otter_addresses_called"]; |
There was a problem hiding this comment.
Could it be just auto const parsed = ...?
Add the missing apis that allow otter to search for transactions that have touched a certain address etc.
Needs Zilliqa/evm#5
This will only work if you point otterscan at a node/iso server that has ARCHIVAL_LOOKUP_WITH_TX_TRACES enabled. In this special case, it will start to collect otter logs from evm and tx execution and write them to disk.
It piggybacks off the tx_traceTransaction functionality which was already there. The tx trace stuff actually keeps a rolling cache on disk so for full permanence the otter stuff had to be split into its own storage.
There are some performance considerations: the disk space for the otter search before/after could become very large over time, and queries of an address with a lot of traffic could also take a very long time to parse (or even crash the seedpub due to OOM error).
Also, the evm is now returning more text per IPC call, which makes it slower. This can cause evm tests to time out and could be an issue if the seedpub 'falls behind'.
Fortunately all of this stuff in prod is essentially only on a dedicated seedpub.