Feature request: implement debug_accountAt (as implemented by turbo-geth)

[haltman-at]

Requested feature

Add the debug_accountAt debugging RPC method recently added by Turbo-Geth. This new debugging RPC method allows for getting account info, other than storage, at a transaction boundary.

Rationale

Why should this feature exist?

It's useful for debugging, basically. You already support debug_storageRangeAt and this is pretty similar (in idea if not in detail).

Basically, we at Truffle are trying to get this to be a more widely-supported thing; we've talked to Besu about it too, and we're planning on adding it to Ganache as well. We want this to be a general thing available to debugging. You can see here the original issue where we suggested the idea to Turbo-Geth.

So, we hope you agree that this would be a useful thing to have! :)

What are the use-cases?

So, we at Truffle are hoping to make use of this feature in Truffle Debugger once it's more widely implemented. I have three primary use cases in mind:

1. Getting correct code for a contract being debugged -- currently the debugger has to get the code at a nearby block boundary, which may not be correct. Maybe the contract was only created during that block, or maybe it self-destructed later in the block. It would be best if we could simply get the correct code at a transaction boundary.
2. Getting nonces for contracts being debugged in order to compute addresses for failed CREATEs -- currently the debugger has a problem reporting certain globally-available variables when inside a failed CREATE. Because the CREATE failed, it can't get the address off of the stack, and because the debugger doesn't know the nonce (block boundaries won't be good enough here!) it can't compute the address ourselves. If we could get the nonces, we could compute the address ourselves and correctly report this and msg.sender.
3. Balance tracking -- this isn't properly planned out yet or anything, but in the future we may want to add a system for tracking balances to the debugger; this would be a necessary component of it, since, again, getting the balance at block boundaries wouldn't be sufficient.

That said, there could really be any number of other uses; other people have commented that they want this feature too (see comments on the turbo-geth issue), and they presumably have other use cases in mind. So it's not just us at Truffle that want this! :)

Implementation

Do you have ideas regarding the implementation of this feature?

Other than the specification, no.

Are you willing to implement this feature?

No, I have no familiarity with Go, sorry.

[holiman]

Discussed on triage: Yes, seems like a reasonable feature. This might be possible via just adding a new tracer, without modifying any of the existing go-code.

[s1na]

After #22333 is merged you can use something like the following tracer to get an account at a transaction boundary:

{
  addr: toAddress("0xaaaa"),
  fault: function() {},
  step: function() {},
  result: function(ctx, db) {
    const code = toHex(db.getCode(this.addr));
    return { balance: db.getBalance(this.addr), nonce: db.getNonce(this.addr), code: code }
  }
}

[s1na]

Closing this issue. Please re-open if the solution above doesn't meet your needs.