The Great Interface Migration

📜 Development Proposals
1

The problem

image
image2000×1006 140 KB

The Cairo community has been experiencing a huge lack of consistency across projects, interfaces, and coding styles (1, 2, 3, 4, 5, …?).

A solution

The consensus was to follow snake_case since that was the final choice made by Cairo 1.0. Now, the hard part:

This is the migration plan for OpenZeppelin Contracts for Cairo. Users of the library are encouraged to follow along a two-step process consisting of three stages:

  • Stage 0: current situation
  • Stage 1: support both interfaces
  • Stage 2: phase out camelCase, snakes all over

Although this migration plan is for OpenZeppelin Contracts, we strongly encourage the wider StarkNet ecosystem to follow along with non-OpenZeppelin interfaces as well.

Stage 0: snaMel or penguin_Case

image
image1920×1920 139 KB

This is were we’re at today. Most contracts are Cairo 0.x and they will have to keep up with regenesis, either by upgrading or through alternative migration paths.

These forced updates are the perfect wave for this migration to ride.

Stage 1: dual interfaces

image
image2000×1848 375 KB

Leveraging the forced migration, OpenZeppelin Contracts for Cairo will provide a library that:

  • exposes both snake_case and camelCase interfaces
  • calls both snake_case and camelCase functions on other contracts

The latter would be done by attempting the snake_case function first (incentivizing optimizoors to favor the preferred casing), and try with camelCase before finally reverting. Such fallback mechanism should also be available as a module for other contracts to call (e.g. call ERC20::transfer_from() and let the dispatcher resolve the right casing, similar to Solidity’s SafeERC20).

This way, contracts will be compatible with old and new interfaces. Users are encouraged to deploy Stage 1 contracts before regenesis in preparation for Stage 2.

Stage 2: snakes all over

image
image1920×1080 414 KB

After a TBD period of time, most probably after regenesis, the library will drop camelCase:

  • exposing only snake_case interfaces
  • calling only snake_case functions on other contracts

Since Stage 1 provided full compatibility with both interfaces, there’s no need or rush to upgrade or migrate existing contracts to this version. It’s up to users to evaluate case by case whether it’s safe to do so.

We expect the community to eventually phase out of using camelCase at its own pace.

Opening up the discussion

This is a forum topic and not a blog post because we’re interested in your thoughts and ideas. Does this work for you? how can we make this as seamless and easy as possible?

2

I think we should just move to stage 2 directly, SithSwap will use snake_case only in the Cairo1 deployment

3

I don’t think that’s possible, projects won’t upgrade at the same time, not even if they somehow do it in the same block. We need to maximize stability and interoperability.

4

Would be a good moment to initiate the phase 2, ecosystem, wise. Should we open a new thread or revive this one?

It becomes more and more crucial as starknet is expanding and more contracts are being deployed.

5

let move to phase 2 already

6

This is the perfect time to move to phase 2!

7

One question I’d pose is how long Stage 1 will be maintained. Setting clear timelines might help developers plan for the switch and avoid extending the dual-support indefinitely, which could become a maintenance burden. Overall, it’s a strong approach that respects both legacy code and future standards.

8

i feel using both interfaces will be confusing sometimes, so its better to phase out camelCase, and move to snakes all over

9

+1, let’s initiate Phase 2 and enforce snake case. :snake:

Do you want to start a thread? :eyes:

10

I agree with you, let’s initiate Phase 2 and enforce snake case

11

Should we do a SNIP actually? To have something well defined and in the standards that have to be implemented by starknet contracts?

12

Starknet already has SNIP, for the standards

13

Oh yeah yeah, I was referring to the idea of creating a SNIP just for naming standards. :slight_smile:

14

Oh…okay. i understand you perfectly. It will be a great one , if implimented

15

hahah the nomenclature is very good

16

Not entirely sure I see the value in writing a full SNIP since the migration spec is already defined above for anyone who needs it. But I can draft it out if there’s consensus on the need for formalization or even visibility.

17

yes , it very good indeed

18

Let’s do that then. :+1: The idea is having something that can transition to mass adoption. Then this will also I guess impact interfaces ids for SNIP5 due to the removal of dual casing?

19

Isn’t that a cool name?

20

yes , it is very cool