Discussion: Approach to implement verifiable ABIs

Announcements
1

I want to start a discussion about a way to implement verifiable ABIs. We have been discussing it internally for the past couple of days and want to open the discussion to the ecosystem to put out your opinions here. There are different approaches that we have been discussing lately:

  1. One way is to consolidate all of this around our sway package registry (i.e. npm or crates.io for publishing sway artifacts and libraries). Our tooling team already has a skeleton of the service in place. This could be a one-stop shop for publishing debug symbols, abis, source code and auto-generated docs.

  2. Storing ABIs directly on-chain could potentially eliminate the need for an “etherscan” equivalent solution. However, this might not be as verifiable as expected and could significantly increase deployment costs.

  3. We may build or offer something like Microsoft’s symbol server. This would be great for DevEx and can also possibly a used for a purpose-built L3 that we can run/maintain.

We’re looking to gauge the demand for such a feature so projects can strongly push for this. Your insights will greatly influence our direction. I would like to open the discussion with the ecosystem members and would love to know your thought

3 Likes
2

My sense of it is that it should be as easy as publishing a package that contains an ABI file (or other metadata) signed with the same key that published the contract on chain.

We should standardize the process so it’s easy to query, but it doesn’t make sense to publish the metadata on chain and the sort of centralized to decentralized path we’re envisioning for the package manager is similar to what we’d want for this.

Once it’s somewhere on the web and easy to query the explorer should be able to populate that information no problem.

And I even think the LSP should be able to get the info and warn you if you are making some calls that break the ABI of the address you are targetting, which is something I haven’t seen anywhere else and can easily be enabled by the close integration we have.

3 Likes
3

In addition to what was discussed here, what would be immensely useful is the ability to introspect and understand contracts without the need for full ABI.

This would allow someone on the outside to detect the nature of a contract aka which standards it implements and then using partial Abi to call the functions as defined by the standard.

The EVM equivalent is ERC165: What is supportsInterface? Understanding ERC165 | by TechJD | Medium

Sample Use Case:

  • A platform that acts as NFT aggregator marketplace that wants to automatically list NFTs from other providers

  • A game that wants to allow users to use interchangeably perform actions from other contract game protocols

1 Like
4

First I support any imporvement to the readability of Fuel.

Fuel is especially difficult to read because state is referenced by ordinal not addressable like with Ethereum. Although etherscan is incredible for holding the majority of verified smart contracts it is not essential because it can be reversed engineered later.

For Fuel, in combination with the ordinals and complex data types, without the ABIs the data is unreadable and in future near impossible to integrate with.

Without the ABIs that was compiled with the deployed bytecode it may have different ordinality, etc.

Solutions

  1. sway package registry is a good start. Even easier to host a github repo with everyones forc/abis.
  2. Given the ordinality this is essential. I understand state concerns but these can be minimised with xpluscals suggestion of erc165. The cost is minimal as aptos do this where you can opt out if you care to save over readability.
  3. no comment

Conclusion. 1 you can do right now. 2 i see as essential for partity with chains like aptos.

1 Like