human readable operations

[joticajulian]

As a front-end developer, I would like to interpret the operations without reading the ABI (for block explorer and extensions for browsers).

In the current implementation, an operation to transfer tokens looks like this:

  {
    "type": "koinos::protocol::call_contract_operation",
    "value": {
      "contract_id": "Mkw96mR+Hh71IWwJoT/2lJXBDl5Q=",
      "entry_point": 1659871890,
      "args": "MIjFLcnM3djFydHBnUnlmd0VabmN1S01RUW5ZNUpocVhWU3giMTM3Sld2ZzRVZUQ0djg3VzFVTWJ0U2NKWGlVUjRXV3JDcgAAAAJUC+QA",
      "extensions": {}
    }
  }

It would be good to have:

1. entry_point as string.
2. args as json.

  {
    "type": "koinos::protocol::call_contract_operation",
    "value": {
      "contract_id": "Mkw96mR+Hh71IWwJoT/2lJXBDl5Q=",
      "entry_point": "transfer",
      "args": {
        "from": "1Krs7v1rtpgRyfwEZncuKMQQnY5JhqXVSx",
        "to": "137JWvg4UeD4v87W1UMbtScJXiUR4WWrCr",
        "value": "10000000000"
      },
      "extensions": {}
    }
  }

In this sense, it would be easy to present this information to the user (for instance, a request for signing a transaction using an extension in the browser) without having to get the ABI of each smart contract.

[mvandeberg]

There are a few challenges with this issue.

The ABIs need to registered somewhere. I am assuming "I would like to interpret the operations without reading the ABI" means the client does not need to read the ABI. This makes some sense for read_contract so long as you are comfortable working with whatever JSON library the client language provides.

The ABI could be registered behind the JSON RPC microservice and used to translate the requests/responses. This is an interesting feature for an API endpoint to implement.

The idea does not work, however, once a transaction needs to be signed as the JSON does not always have the required type information needed to serialize the object correctly. A parser could probably be written that gets the general case working, but the only way to ensure it works 100% of the time is to read from the ABI to operate on the Protobuf types directly. I don't think this is that unreasonable as it is exactly what Web3 does to interact with contracts "natively" in javascript. Providing those facilities will be a core component of good client libraries.

[joticajulian]

I've done more research on this topic.
How is this solved in Metamask? there is a contract on Ethereum called signature registry, which is used to store a map between "function names" and 4 bytes identifiers. When metamask receives a request for signing it takes the 4 bytes from the data and calls that contract to get that small part of the ABI. And with this information it can parse the data and show human readable content in the pop-up. More info in this issue MetaMask/metamask-extension#2847.

We could have a similar contract in koinos to register all ABIs.

As you said, the ABI could be registered in the JSON RPC microservice. So, each dev should make sure to register the ABI in the different nodes.

Another option is to store the ABI in each smart contract, for instance, by calling the entry point 0.

[joticajulian]

The website that triggers the request for signing can provide the ABI as well, but there is a risk of fraud if we consider that the websites cannot be trusted (this is the simplest solution at the moment though).

[joticajulian]

Related to koinos/koinos-cli#77

[koinos-ci]

This issue is stale because it has been open for 30 days with no activity.