Voucher content decoding

[brunomenezes]

📄 Context

Given that a voucher has a destination (Address) and the payload (Encoded arguments), we can recover the ABI of this destination address and use it to try to parse the encoded payload (i.e. the input for the destination) for this type of output.

Ref Rollups Contracts: CartesiDApp#executeVoucher

✔️ Solution

We can leverage two tools here. We could experiment with WhatsAbi to retrieve the ABI from an Address (Check the documentation for more details on usage), and then use Viem to decode the payload and display it in the Input-details box.

• Add WhatsAbi as a new Dependency
• Add logic to retrieve the ABI from a contract. Handle any possible failures gracefully, The Application should continue to work in case it fails to retrieve information.
• If the ABI information is valid, try to decode using Viem. Handle any possible errors during the decoding process.
• If the ABI retrieval or decoding fails, send down to the input details the usual encoded payload.
• Failures in any of the steps above should be silent i.e. No notifications/feedback. That is an enhancement of visibility, and if it is not available, we just move on (no fuss about it).
• For decoding success, there are two options (pick one)
  • Get the decoded content, transform it into a Hex value, pass it down and let the Content.tsx do what it is doing.
  • The other option is to adjust the code/types all the way to the Content.tsx to recognise what it is receiving and apply the correct transformation functions. For that option, everything else should still work as expected.

PS: The first option is more sensible in the decoding success section above. Given the number of unrelated changes and checks required by the second option. It can be a separate refactor issue if necessary.

📈 Subtasks

• Implement logic to retrieve the ABI from a destination address.
• Implement logic to decode the payload.
• Make the adjustments to display the payload.
• Add test cases.

🎯 Definition of Done

• When voucher information is valid, I can see the payload in a human-readable form when using the current decodes (Text, JSON)
• When voucher information is invalid, it continues to work as it did previously.
• CI checks are passing.

[brunomenezes]

Hey @tuler, am I missing anything from our conversation? For that first version, I don't think we need to include the Loaders for Sourcify and/or EtherScan, maybe later? but we need to check how WhatsAbi would work when the Provider added in the setup is fetching data on a dev-net setup.

[tuler]

AFAIK WhatsABI can fetch from etherscan and sourceify automatically.
For devnet it won't work. That's ok.

One possible enhancement, that can be left for another issue, is to allow the user to input the ABI in a Textarea manually, and let the decoding works. That could be used in the devnet scenario.

[brunomenezes]

AFAIK WhatsABI can fetch from etherscan and sourceify automatically. For devnet it won't work. That's ok.

One possible enhancement, that can be left for another issue, is to allow the user to input the ABI in a Textarea manually, and let the decoding works. That could be used in the devnet scenario.

When using the autoload() it will use both even though the EtherScan loader needs an API key, so it will actually rely only on sourcify in that case. I don't see it as a problem for now, but I think defining them for EtherScan sake is better so the baseUrl can also be changed based on chain-id Etherscan endpoints

lines: L268 and then L65