search

athenavm / athena

Athena monorepo
https://www.athenavm.org/
Apache License 2.0
21 stars 2 forks source link

`fallback` template method #203

Open lrettig opened 3 weeks ago

lrettig commented 3 weeks ago

As in EVM, we want to allow a template to optionally implement a fallback() method. If a template without a fallback method receives an inbound tx or a CALL to nonexistent method, it should immediately fail. If it does have a fallback method, that method should receive the tx or CALL.

IIRC, right now, we route a tx or a CALL without a method selector to the default ELF entrypoint -- which in the case of a template compiled with the noentrypoint feature and #![no_main] would result in a panic. We should change this behavior.

It should be able to receive encoded args as a single input bytearray. It would need to manually decode those args if it chooses to do so.

The fallback method, if declared payable, should also be called when coins are received and a payable receive() method doesn't exist, or if coins are received and there is calldata (since receive cannot take calldata).

We may need a new macro for this, or else we may be able to update the existing #[template] and #[callable] proc macros to do the additional work here (if they notice that the method name is fallback).

See also: https://docs.soliditylang.org/en/latest/contracts.html#fallback-function

poszu commented 3 weeks ago

What's the motivation to have a fallback() method? I mean, why not just fail a transaction if the template doesn't have a receive()?

lrettig commented 2 weeks ago

Same reason you can set up a fallback email address for a domain. It's just useful to have a "catch all" in case you receive something inbound you weren't expecting: a call to a nonexistent method/if there's no matching method signature (including, potentially, the wrong args), or if no data is supplied.

To be clear I consider this nice to have but quite low priority. We can wait and see if developers ask for it.

poszu commented 2 weeks ago

It's just useful to have a "catch all" in case you receive something inbound you weren't expecting: a call to a nonexistent method/if there's no matching method signature (including, potentially, the wrong args), or if no data is supplied.

I understand when it would be called. I wonder about the benefit of calling the fallback instead of immediately failing the TX.

lrettig commented 4 hours ago

We should do some homework to better understand how and why this is used in solidity and EVM, and whether other execution environments have something similar.