Remove ABI from contract deployment request and `get_code` response?

First off, I totally understand the convenience of having ABI readily available from API, and am aware of existing blockchains (e.g. EOS) that do exactly just this.

However, despite things working well under the happy case (everyone using the standard toolchain to build and deploy contracts), the abi returned by get_code cannot be relied upon:

  • The abi under contract_definition is optional anyways when deploying contract
  • There’s no way for sequencers to verify correctness of ABI submitted on deployment

To demonstrate the idea, I’ve deployed a contract with fake ABI here, and it’s picked up by the block explorer:

which is quite misleading.

IMO if shouldn’t even be there if it cannot be relied upon. I think the responsibility of providing ABI should be outsourced to a source verification service like Sourcify or Etherscan, which can deterministically derive ABI from source code.

What do you guys think?

10 Likes

Hi @xJonathanLEI , you are correct.

The rational initially was to allow showing something in Voyager, before contracts verification was possible. It was done as a way to make development easier at the early stages of StarkNet Alpha.

I think you are making a good point and we should consider either removing it, and/or making Voyager only shows verified contracts’ ABI.

4 Likes

Standardization is driving us into a box. Centralized ABI validation can affect creativity, or am I wrong?

2 Likes

I don’t think this has anything to do with centralization though.

Yes I mentioned Etherscan as an example, which is indeed a centralized platform, but such a source code verification service doesn’t have to be centralized. Take Sourcify for example.

The most important point I’m trying to make is here is the sequencer is not even validating the ABI anways. It just hosts whatever the deployer claims to be the ABI.

2 Likes