Provide a way for a contract developer to explain the performing call in a natural language

[davidyuk]

Aepp may ask Wallet to sign a contract call transaction. Wallet needs to show transaction details to the user. Currently, it can use calldata to decode call arguments with some losses. Alternatively, contract source code can be registered somewhere to generate aci based on it and to do complete decoding. Meanwhile, decoding contract call arguments don't ensure that the user would understand the performing action.

Inspired by https://eips.ethereum.org/EIPS/eip-6384, I propose implementing API to allow the contract to provide a text explanation to a performing contract call. Each contract method should be duplicated with a static method accepting the same arguments with a slightly different name, returning an explanation string. Additionally, the contract needs to implement a method returning a mapping of method name ids to ids of the explaining methods.

After that on SDK side, I can implement a function that would

• accept the contract call transaction;
• extract the contract's method id;
• get methods mapping;
• call the corresponding contract's explaining method with the same arguments;
• return the explanation as a string.

The good thing about explaining methods is that they can lookup ids, for example, if I'm going to perform an operation with NFT#123, it can be replaced with its name. This is not available for a common contract using aci, though lookups need to be used with caution.

cc: @marc0olo @thepiwo

[marc0olo]

we definitely have a long way to go in that area IMO. I am not sure how much this helps right now as it also requires logic to be added to new contracts, right? this wouldn't work for existing contracts, correct?

ideally we have some full example flow showcasing this. as this is not the only topic we face in aepp <-> wallet communication, I would love to see every known "issue" being tackled at once with one example as we have discussed last year at the castle (we still have a document for this (cc @thepiwo @kenodressel)

here some aspects to consider:

• any platform to any wallet
• protocol (error-handling, payloads/messages/requests in any direction, wallet actions to change node/network/..., ...)
• privatekey-less signatures (allow to sign via transaction, e.g. for contract multisig or generalized accounts)
• æternity specifics:
  • generalized accounts
  • meta transactions (PayingForTx)
  • state channels

I would really love to see that problem solved once for all, but it definitely requires some effort 😅

[davidyuk]

this wouldn't work for existing contracts, correct?

Yep. This is more related to showing transaction details on wallet side than to aepp-wallet connection.

[marc0olo]

I know. just trying to push the other topic again 😁

also, if decided and implemented we need to advertise this heavily and make sure future contracts consider the standard.

[thepiwo]

I think this can be a good approach, one thing that is not directly clear to me is:

• How are those information secured, so the user can't be cheated by third parties in being shown some other information than intended? Does that imply some clear text of this is stored on-chain or is there some hashing or other verification mechanism if this information is only part of the ACI?

[davidyuk]

How are those information secured, so the user can't be cheated by third parties in being shown some other information than intended?

Wallets need to get an explanation from a contract, whose address is specified in a contract call tx. There should be no way for a thigh party to get involved unless the user communicates with a wrong contract from the beginning.

Correspondence between explanations and what the contract is actually doing should be checked on a step of contract code reviewing.

Wallets should explicitly say that the showed explanation is provided by a contract, not by the wallet.

Does that imply some clear text of this is stored on-chain

Yep. This would make contract deployment more expensive but won't add an extra fee to a contract caller. This shouldn't depend on ACI because in general case wallet doesn't know the contract aci.

[thepiwo]

Sounds like something we should explore, do you already have a proposal on how that might look like in sophia and how that will be stored on-chain?

[loxs]

Does this mean that it would only require access to the bytecode from the chain, no ACI and no source will be needed?

If I understand it correctly, the problem I see is that it does feel like an over-complication with a questionable gain. As far as I understand, this still does not guarantee anything, we rely to the contract author not being malicious? Even worse, it can even provide scammers with the best vehicle to scam users? "This call lets you stake your AE coins with our bank", when in fact it does something completely different?

[davidyuk]

the bytecode from the chain, no ACI and no source will be needed?

to show messages, yes

an over-complication

This can be really complicated to implement now, but it can be significantly simplified on the compiler side, making it a kind of specially-crafted comment about an entrypoint.

questionable gain

There is a problem showing contract call details without aci in a clear way on the wallet side. I don't see a better way to solve it.

we rely to the contract author not being malicious?

anyway, a contract needs to be reviewed, even now

it can even provide scammers with the best vehicle to scam users? when in fact it does something completely different?

A wallet needs to highlight that the message is provided by the smart contract, so it should be trusted the same as a contract.

This would work better in the opposite case, a malicious aepp may claim a magic operation with a contract, actually asking the user to transfer all contract-controlled tokens somewhere. But the user would see a proper explanation of a performing action in a wallet popup. Currently he would see an entrypoint name (or hash?) and a list of arguments decoded without aci.