Create anonymousSpend fallback when spendTx to contract

[mradkov]

Value proposition

The general idea is users to be able to interact with a contract with just a plain wallet, without prior knowledge of the interface of the contract.

User stories

• As a user, I want to be able to send tokens (similar to spendTx) to a contract without knowing the interface or interacting via complicated UI.
• As an aepp developer, I do not want to develop nor integrate aeternity SDK in order to interact with user's wallet just to be able to compile the calldata needed for a contractCallTx (for simple use-cases e.g. betting, tipping, contribution campaigns, etc.)

Status quo

• Currently its technically possible to make a spendTx to a contract address for a value transfer.
• Currently, specified base fees in the aeternity protocol are 15000 (15k) gas for spendTx and 180000 (180k) gas for contractCallTx (the latter being higher as it requires a VM to be started).
• Sophia does not allow a fallback function to be defined and used (a function that is executed on all other cases when a function which is being called is not defined or not provided) as in Solidity for example. For what it's worth - its a good security precaution but a UX limitation as well.

Proposed implementation

In order to achieve the above functionality without changes in the protocol or complex changes in the wallet we can do the following:

Wallet

1. A user wants to spend AE on a contract.
2. The wallet fallbacks to generate a contractCallTx instead of regular spendTx.
3. As the contractCallTx requires a function name in order to be called we can call a _fallback() entrypoint without any arguments.
4. If there is no such function implemented by the contract (make an automated check here) - continue the execution of regular spendTx.

Contract

1. Every contract that wants to be able to support such behavior can implement the _fallback() entrypoint which captures the anonymous spend-like-contractCall transaction in order for the users to be able to call it via the flow above.

Example anonymous spend entrypoint _fallback()

  payable stateful entrypoint _fallback() =
    "do whatever here" 

Known limitations

• this flow is not backward compatible for wallet versions prior the one which would implement this
• this is an implicit functionallity which can lead to errors - it is possible that the user wants to make a de facto spendTx to the contract. We should think of how to address this case - possible configurable in the wallet settings (off by default).

[thepiwo]

What is the concrete use-case here?

I don't think it's a good practice to have implicit functionality as this as it will lead to errors, especially the reason why a fallback is not implemented in the first place.

If an aepp developer wishes to integrate this functionality, it is no extra work to do it explicitly, as he will have to implement the function in any case.

What if the user wishes to do a spendtx without using the proposed fallback? What if this gets misused to author actions towards the contract that were not intended?

[mradkov]

I don't think it's a good practice to have implicit functionality as this as it will lead to errors, especially the reason why a fallback is not implemented in the first place.

What if the user wishes to do a spendtx without using the proposed fallback? What if this gets misused to author actions towards the contract that were not intended?

Could be user-configurable in the wallet settings.

[nikita-fuchs]

It's a two-sided sword. I like the mentioned pro and contra arguments here, but what really tips my scale in the direction of contra is the fact that AE can get trapped in contracts very easily that way. There are countless people on the internet who - for some reason - still manage to transfer funds to wrong addresses all the time, the classic variant is sending tokens from a token contract to the contract itself. With no explicit way to get the funds out, allowing funds to be implicitly transfered to a contract is dangerous. Bad enough I had to find out today that this is possible by prefixing its address with ak_ instead of ct_. This fully defies the purpose behind the idea of the payable modifier :/

From a dev standpoint I like this idea, but I fear the trouble this can cause is not worth the benefits 🤷‍♂️
(of course funds can also get locked in contracts the way things are right now, but the fact that letting funds slide into your contract is a thing to be explicitly taken of raises the likelihood that the outflow is being taken care of, too)

[thepiwo]

@nikita-fuchs can you provide an example how funds can easily get trapped?

[nikita-fuchs]

how funds can easily get trapped?

Just forget withdraw logic I guess

[thepiwo]

well I hope devs test their contracts basic functionality before production deployment, so it won't happen "easily"

[marc0olo]

just discovered this and IMO this should always be handled using a regular SpendTx to the accounts of contracts defined with payable. my question here would be if there is currently an easy way to check if a contract actually is payable without knowing the sourcecode 😅 (if not we should aim to get this functionality). I guess this can be checked with a dry-run transaction

for everything that requires additional logic we need custom contract calls anyway