Data structure for the REVERT instruction

[axic]

Depends on #206.

[vbuterin]

No proliferation of many different encoding standards please. We have RLP and ABI, those two are enough. And given the use of ABI everywhere else in-EVM, I am strongly inclined to favor ABI.

[miohtama]

Does the architecture allow more than two error arguments?

If possible I'd suggest a third return argument

• The first argument defines the type of the error and that may map to different Exception classes in high level languages

• The second argument is human readable message, akin Exception.message in Python

• The third argument would give a machine readable data that gives more run-time error details in the form of root cause of the revert. This could be e.g. a nested error in the case the error happened in an inter contract calls. This way one would be able chain different errors together. This is similar to how Java and Python do nested exception handling. The ability to trace errors to their root cause becomes very important in the complex systems with interdependencies, especially if some of those dependencies are smart contract that the developers themselves cannot control.

[axic]

No proliferation of many different encoding standards please.

I agree that we should try to limit the number of competing standards being used. I wonder what was the need to invent RLP over competing formats (including CBOR, which was accepted as an RFC in 2013).

Note that CBOR already infiltrated Ethereum, Swarm is (going to?) use it for the manifests as well as Solidity uses it for the metadata hash.

My main reason for CBOR is it's flexibility to represent multiple return types:

• simple string
• array with two members (as in the EIP now, number + strings)
• array with three members (as proposed by @miohtama)

RLP can be used to determine the length of arrays, but it won't support different data types within. The ABI encoding is very rigid, we'd need to define a fixed field for type or length.

[Arachnid]

I really think that it makes the most sense for REVERT data to take the same conventional form as return data from a CALL: ABI-encoded, and defined as part of the signature of the function.

[axic]

Does the architecture allow more than two error arguments?

This is really above the level of the EVM; the EVM only cares about returning a blob of memory. Compilers can decide on whatever standard and ABI specification they all agree on.

That is the scope of this proposal.

[Arachnid]

That is the scope of this proposal.

Yes, I thought I was commenting on another issue. I deleted my comment when I realised I was mistaken.

[Arachnid]

Do you still want to pursue this? AFAIK we had decided on leaving REVERT opcode to the HLL, and defaulting to the same format as regular return data?

[Arachnid]

This is a courtesy notice to let you know that the format for EIPs has been modified slightly. If you want your draft merged, you will need to make some small changes to how your EIP is formatted:

• Frontmatter is now contained between lines with only a triple dash ('---')
• Headers in the frontmatter are now lowercase.

If your PR is editing an existing EIP rather than creating a new one, this has already been done for you, and you need only rebase your PR.

In addition, a continuous build has been setup, which will check your PR against the rules for EIP formatting automatically once you update your PR. This build ensures all required headers are present, as well as performing a number of other checks.

Please rebase your PR against the latest master, and edit your PR to use the above format for frontmatter. For convenience, here's a sample header you can copy and adapt:

---
eip: <num>
title: <title>
author: <author>
type: [Standards Track|Informational|Meta]
category: [Core|Networking|Interface|ERC] (for type: Standards Track only)
status: Draft
created: <date>
---

[nicksavers]

@axic I get the idea that this proposal fall in the category: Interface

Includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names and contract ABIs.

What is your current position on this now that #206 has been merged?

[github-actions]

There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.