Parity-ethereum: Getting revert reason from transaction trace

[uluhonolulu]

• Parity Ethereum version: v1.11.4-beta-f26a7fe6f-20180612/x86_64-windows-msvc/rustc1.26.1
• Operating system: Windows
• Installation: one-line installer
• Fully synchronized: yes
• Network: private
• Restarted: yes

When I execute trace_replayTransaction for a failed transaction, I get, among others, the output field that looks like this: 0x08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000384e6f7420656e6f756768206d6f6e6579206f6e2062616c616e636520746f2077697468647261772073706563696669656420616d6f756e740000000000000000.

If I take the chars starting with 38... (after a long row of zeroes) and convert it to ASCII, I get the revert reason which matches the revert instruction in my smart code. I've been doing it manually, but I would like to automate it. Is there a spec for this field?

Note that I can't just take everything after "many zeroes", because the first two characters ("38", which becomes "8" after conversion) are not a part of the revert reason. The string that I need starts at position 137.

My question is: how do I get the revert reason from the output field?

[joshua-mir]

All of the data from an evm based blockchain (including the blocks themselves, transactions, etc) is RLP encoded. There are quite a few tools that can parse rlp and give you a json object (or whatever you want for your environment). That should get you a more friendly format to work with.

[uluhonolulu]

@joshua-mir would be cool but doesn't work here.

For a single byte whose value is in the [0x00, 0x7f] range, that byte is its own RLP encoding.
The first byte is 0x08 in my case, so it should be, theoretically, the only byte in the encoded value. Indeed, a deoding tool throws an exception.

What I have noticed so far is that 1) I always have 0x08c379a0 at the beginning; 2) the string that I need always starts at position 137.

Could you tell me where to look in the source for the code that produces this output?

[joshua-mir]

You're right. The first item is the offset of the return data, followed by it's length, as defined here https://eips.ethereum.org/EIPS/eip-140

Actual implementation looks like it's here