* feat: api: improve the correctness of Eth's trace_block (#11609)
* Improve the correctness of Eth's trace_block
- Improve encoding/decoding of parameters and return values:
- Encode "native" parameters and return values with Solidity ABI.
- Correctly decode parameters to "create" calls.
- Use the correct (ish) output for "create" calls.
- Handle all forms of "create".
- Make robust with respect to reverts:
- Use the actor ID/address from the trace instead of looking it up in
the state-tree (may not exist in the state-tree due to a revert).
- Gracefully handle failed actor/contract creation.
- Improve performance:
- We avoid looking anything up in the state-tree when translating the
trace, which should significantly improve performance.
- Improve code readability:
- Remove all "backtracking" logic.
- Use an "environment" struct to store temporary state instead of
attaching it to the trace.
- Fix random bugs:
- Fix an allocation bug in the "address" logic (need to set the
capacity before modifying the slice).
- Improved error checking/handling.
- Use correct types for `trace_block` action/results (create, call, etc.).
- And use the correct types for Result/Action structs instead of reusing the same "Call" action every time.
- Improve error messages.
* Make gen
Make gen
---------
Co-authored-by: Steven Allen <steven@stebalien.com>
* new verireg methods
* update changelog and add itest
* update itest and cli
* update new method's support till v9
* remove gateway APIs
* fix cli internal var names
Correctly handle "unresolvable" to/from addresses in top-level messages in the Ethereum API. Specifically:
1. Fail if we can't resolve the from address. As far as I can tell, this should be impossible (the message statically couldn't have been included in the block if the sender didn't exist).
2. If we can't resolve the "to" address to an ID, use "max uint64" as the ID (`0xff0000000000000000000000ffffffffffffffff`). This will only happen if the transaction was reverted. It'll be a little confusing, but the alternative is to (a) use an empty address (will look like a contract creation, which is definitely wrong) or (b) use a random/hashed address which will likely be more confusing as it won't be "obviously weird".
