When you interact with a DApp through the Status DApp browser, in the moment you invoke any functionality that sends a transaction, a confirmation form appears that informs you of the recipient, amount and gas limit (in the Advanced section), however, there’s no information about the data being sent to the destination contract: We could solve that displaying the “data” parameter of the transaction, but this is just a hexadecimal string. How is an average user able to know what information is being sent to a contract?. (this difficult even for a developer to know).
I believe we can improve this scenario. We can build a new functionality to make the user aware of what information is being sent and what functions are being executed when they interact with a DApp on Status. I propose this:
Let’s offer the DApp developers a place where they can upload their contract source code or ABI definition of the contracts used on their DApps (similar to the contract verification on etherscan), as well as the contract addresses. Then, if during the normal use of their DApp, a contract function invocation is done, using these files, we will be able to decode the data that is going to be send as a transaction, for example:
Assume we are sending this transaction with this information:
to: 0x119abc89e113b4da91F19051cB2427D02C42CB0D
value: 0
data: 0xbbec12c1000000000000000000000000000000000000000000000000000000000000000a
gasLimit: 100000
gasPrice: 10
If we ask the user to confirm whether he wants that transaction to be executed or not, he wouldn’t know what the hexadecimal parameters mean
However, if we have a registry where we can see the ABI for a contract, we can know what the previous values represent and display them to the users:
to: TestContract
value: 0
data:
sendSTT(uint _amount):
- _amount: 10
gasPrice: 10000
gasLimit: 10
This functionality could be improved further using natspec. If the contract is well documented, we can display the natspec information that contains the description of all the elements involved in the transaction. For example if we have this contract:
// @title Description of test contract
contract TestContract {
// @notice Sends an amount of STT to the contract
// @param _amount Number of STT to send
public function sendSTT(uint _amount) public {
}
}
We are able to extract the @title, @notice, and @param information and display them if the user taps in the contract name, the function or any of the parameters.
This way we can educate the user on what are they signing for when they call a contract function.
The functionality previously described is something specially important for the upcoming Status DAO and Topic Democracy, since the voted proposals are stored as a hexadecimal string and if we want our users to vote on them, they need to be able to see what will the transaction execute, and be able to discuss it. Also this can be part of the criteria used to determine if a DApp is Optimized for Status.
