Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(arbiter-core): EVM stack tracing #710

Open
0xJepsen opened this issue Nov 15, 2023 · 4 comments
Open

feat(arbiter-core): EVM stack tracing #710

0xJepsen opened this issue Nov 15, 2023 · 4 comments
Labels
✨ enhancement new feature, upgrade, or change in modularity 📝 needs more information issue is not well-defined enough to be solved

Comments

@0xJepsen
Copy link
Collaborator

No description provided.

@Autoparallel Autoparallel changed the title Arbiter stack tracing feat(arbiter-core): EVM stack tracing Jan 23, 2024
@Autoparallel
Copy link
Collaborator

Can you expand on this please?

@Autoparallel Autoparallel added ✨ enhancement new feature, upgrade, or change in modularity 📝 needs more information issue is not well-defined enough to be solved labels Jan 23, 2024
@0xJepsen
Copy link
Collaborator Author

Yeah there are i guess two types of stack traces that could be nice for debugging calls when a call fails.

  • One in solidity: Saw we have a call to the dfmm contracts fail. For example consider that the entry point was called from the atomic arb contract. Meaning we aren't sure which frame the call fails in. Is there a way to to deliver the user the solidity stack trace looking something like
Error: Transaction reverted: {Revert Reason}
  at MyContract.someFunction (contracts/MyContract.sol:25)
  at MyContract.anotherFunction (contracts/MyContract.sol:50)
  at some_eoa_call (test/MyContractWrapper.rs:30) (would it be possible to log the eoa file? would be sick)
  • The other type of stack trace that could be useful would be the opcode stack trace which is much more low lever but for a function like
function add(uint x, uint y) public pure returns (uint) {
    return x + y;
}

could look like this (not confident this matches the above function perfectly but gets the point across)

1. PUSH1 0x20        // Push 32 bytes (size of one uint256) to the stack
2. PUSH1 0x04        // Push 4 bytes (offset for the first argument) to the stack
3. CALLDATALOAD      // Load first argument (x) from call data
4. PUSH1 0x24        // Push 36 bytes (offset for the second argument) to the stack
5. CALLDATALOAD      // Load second argument (y) from call data
6. ADD               // Add x and y
7. PUSH1 0x00        // Push 0 (offset for return data) to the stack
8. MSTORE            // Store the result at memory location 0
9. PUSH1 0x20        // Push 32 bytes (size of return data) to the stack
10. PUSH1 0x00       // Push 0 (offset for return data) to the stack
11. RETURN           // Return the result

@Autoparallel
Copy link
Collaborator

How would you want to go about implementing this in arbiter?

@0xJepsen
Copy link
Collaborator Author

0xJepsen commented Feb 9, 2024

I was thinking at a high level that an inspector might work for the opcode level stack trace.
But for solidity stack traces i don't know thats needs some more thought

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨ enhancement new feature, upgrade, or change in modularity 📝 needs more information issue is not well-defined enough to be solved
Projects
None yet
Development

No branches or pull requests

2 participants