Skip to content
This repository has been archived by the owner on May 13, 2022. It is now read-only.

Globalise contract metadata #1494

Open
silasdavis opened this issue Jun 1, 2021 · 0 comments
Open

Globalise contract metadata #1494

silasdavis opened this issue Jun 1, 2021 · 0 comments

Comments

@silasdavis
Copy link
Contributor

Currently contract metadata consists of the ABI, it is stored within a JSON blob that isn't explicitly represented in any GRPC schema. This is probably mistake and provides less certainty to clients and confusion about what the format should be (currently a JSON blob).

ramble
Another problem is that it is hard for clients to provide the correct ABIs when deploying a contract that creates other contracts because the Solidity compiler provides no way of listing all contracts that a contract may create. We already use CodeHash as the hash of deployed code but we store all metadata on a per-account level. If we stored code metadata against the code hash then that would be sufficient to look up any metadata (e.g. ABI) when creating a contract. Clients could just upload all the metadata in one go never mind which contract to associate it with. The major problem with this is that we have no way to verify metadata and so providing metadata for a contract you do not control is a bad thing (I think this was the reason when went contract-local in the first place). We could make metadata input-account global, or we could make sure we de-duplicate metadata so re-uploading all possible contracts on the import path is not too wasteful (I think we do do this with the metadata hash storage we have). To make the metadata feature useful I think we need a way to back-fill contracts without metadata in a trustable way and probably separate the provision of metadata from the creation of a contract.

A more extreme solution here is to compile server-side, then we know we can trust the metadata generated.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

1 participant