Smart contract sanctuary for Starknet

đź“ś Development Proposals
1

(Initially suggested by @frangio)

What

This is a proposal to build a smart contract sanctuary: an index of verified smart contracts written in Cairo.

Why

An archive of Cairo smart contract code would be a major aid for the design, development, and decision making of a variety of ecosystem actors such as: app developers, SNIP designers, infrastructure developers, RPC-endpoint developers, node/sequencer developers, wallet developers, security researchers, and the list goes on and on.

Just to give two recent examples I stumbled upon this very week myself:

  1. Discussing the Standard Account Interface with account implementers such as Argent and Braavos, we started considering changing the return value of is_valid_signature from bool to felt252. Although I’m not going to reproduce the discussion in here, the point is that we had no information on whether such a change would break existing, deployed smart contracts or if it was safe to make such change. A smart contract sanctuary wouldn’t have been final, but it would have greatly informed our discussion.

  2. Similarly, while working on the ERC165 → SRC5 migration we started wondering whether it was required for us to release a backwards compatible implementation of ERC721 that worked with both introspection mechanisms or if it would have been a worthless effort and it was safe to drop ERC165 altogether gaining development speed, simplicity in the codebase, and reduced execution costs. A smart contract sanctuary would have suggested whether there was any or several ERC721Receiver contracts deployed on the network.

These are just two examples, but the real world use cases are infinite. Just to give one more:

  1. Several times at OpenZeppelin, after finding or being notified about a critical vulnerability in a contract or module, we’ve found ourselves in the difficult yet critical task of identifying vulnerable contracts to estimate the potential impact and lay out a mitigation plan for each affected contract. Then we faced another challenge which is to notify developers, but that’s out of this proposal’s scope.

How

The best case scenario would be for RPC endpoint providers, node runners, and block explorers to cooperate to collect as much verified source code (maybe also Sierra code?) as possible into a single, well structured, repository. We should draw inspiration (if not directly contribute to) @tintinweb’s repository, or create a new dedicated one.

The sooner we build this, the better for the sake of completeness and convenience.

Conclusion

Having a smart contract code database provides tremendous value to developers, researchers, companies, individuals, and ultimately the entire ecosystem. Let’s buidl one.

2

As part of Scarb we are planning to eventually create an official Cairo/Starknet package registry. It looks like such a sanctuary could naturally be part of this registry. Do I understand correctly?

3

I understand your idea. It could indeed be useful to analyze what has already been deployed on the network, especially in a development phase where there are many things happening regarding contract development. However, I wonder what you have in mind for managing updates and the “replace_class” syscall.

4

I think the Voyager team would be super keen to dump the contracts they’ve collected so far

5

Not sure much needs to be done. Contract code is associated with class hashes and that’s all we need to map. Then block explorers already offer a mapping between class hashes and deployed contracts (see: 1, 2).

6

An approach could be to structure the sanctuary files around class hashes, and to have a file in the sanctuary that maps contract addresses to class hash. One downside to this structure is that it will be harder to query how many contracts are using a particular Cairo pattern. Not impossible, just more work.