ERC20 function naming

[martriay]

The problem: camelCase vs snake_case

According to EIP-20 token functions are written in camel case (balanceOf) whereas Cairo, coming from Python, suggests snake casing (balance_of).

for camelCase:

• consistent naming across chains/layers
• less code/mental burden for projects integrating StarkNet-based ERC20s and other chains with camelcase tokens (e.g. wallets or web dapps like exchanges)
• conversely could be easier for client interfaces/adapters like ethers.js to work with multiple chains dealing with selector encoding (*) so users as the above have to think even less about their differences

for snake_case:

• code consistency
• you may argue above points are not that relevant

Any thoughts?

(*) In solidity, selector encoding is the first four bytes of the keccak signature of the function, e.g. keccak256("transfer(uint, uint)") whereas in StarkNet selectors are much larger, 250-bit hashes of the function name, this is applying a 250-bit mask to keccak256("transfer").

[spapinistarkware]

snake case. This is the Cairo convention. camelCase will only lead to more camelCase, and mangling, IMO.

[pscott]

👍 for snake case :) we are writing Cairo, we want to make it clear to anyone reading it that it's Cairo. Using different name conventions in the same language would be very weird I believe! :D

[martriay]

well I was thinking maybe a wallet or frontend developer dealing with tokens from different networks (BSC, Polygon, StarkNet, Mainnet, Solana, xDAI) would be happy to avoid thinking about what language a token is implemented in: be it Solidity, Vyper, Yul or Cairo

[martriay]

That's why I'm interested in wallet/frontend/client implementator's opinion.
Although completely agree about consistency across codebases is very important, I can barely manage the OCD I get just by proposing this 😅

[pscott]

Of cousre! Always great to bring up discussions :D

[fracek]

If you asked me a week ago I would have also said snake case (in fact, my smart contracts use snake case), but I changed my mind recently when thinking how to integrate StarkNet with a multi-chain frontend.

For example, I have the following code (kinda):

const { address, chainId } = useEthers()
const contractAddress = useTokenAddress(chainId)
const balance = useContractCall(
    address && contractAddress && { method: 'balanceOf', args: [address] })

Now, if the contracts used the same capitalization I would have to deal with StarkNet only at the lowest level (when I make the web3 call), but with snake case I would need to add a case for StarkNet for every contract call.

const { address, chainId } = useEthers()
const contractAddress = useTokenAddress(chainId)
const contractMethod = useTokenBalanceOfMethod(chainId)
const balance = useContractCall(
    address && contractAddress && contractMethod && { method: contractMethod, args: [address] })

For a moment, please ignore we're months away from writing code like the one above :)

In my contracts I'm thinking of renaming all external and view functions to camel case and leave internal/private functions as snake case (it also makes it obvious if you're calling a private or external function). I don't like it, but it saves frontend developers a lot of complexity IMHO.

EDIT: I think what I propose is technically consistent with the Cairo standard library, since they don't include any external function.

[spalladino]

I think that's a conversion we can avoid, otherwise we're opening a pandora box of possible exceptions.

It's not that uncommon to translate casing for going from one convention to another (see here for an example). And for what it's worth, the EIP is an Ethereum proposal, and here we're not in Ethereum land.

I'd vote for consistency with the rest of Cairo - ideally changing Cairo to camelCase.

Besides, Cairo, desert, camels, it all lines up, right?
🇪🇬 🏜️ 🐫

[fracek]

Besides, Cairo, desert, camels, it all lines up, right?

If people are not convinced after this argument I don't know what will move them.

[martriay]

And for what it's worth, the EIP is an Ethereum proposal, and here we're not in Ethereum land.

I think if we're implementing ERC20.cairo we should keep the standard naming. Otherwise, it wouldn't be compliant! Let's not surprise anybody :)

[remiroyc]

I have very little knowledge of JS, but couldn't one call a method like contractMethod.toCamelCase()? It would be a little bit more verbose, but this would work well (provided devs in Cairo correctly translate from camel to snake :))

Trust me, as frontend developer, you don't want to do this kind of thing. It raises an interoperability problem.

[fracek]

I think that in addition to what @remiroyc said, when the automatic conversion fail it's going to be very painful for developers to debug and fix.

[spalladino]

What do we know about how Vyper deals with this issue? Apparently they follow camelCase, even if their tooling is on python, right?

Does it make sense to push for changing Cairo itself to follow camelCase, following Vyper's example, for consistency with existing ERCs?

[remiroyc]

It makes sense. I don't know if it's possible but it could be the best solution imo.

[maciejka]

My intuition is that chains will differ along many different aspects. Think data structures, transaction filecycle, finality, etc. It will be a substantial effort to build a compatibility layer that will hide all those differences under a single abstraction if ever possible.
So by following Solidity conventions we won't gain much (adapters will be complex any way) but we will loose consistency on the Cairo side.

[janek26]

@martriay I agree with this, hopefully not many developers will make calls to the network directly, but use some kind of abstraction, and then it's up to the abstraction. In JS I'm pretty sure we'll support camelCase in the future, and make the calls to the underlying snake_case method, just because snake_case isn't very common is JS.

With this in mind the question only gets relevant for contract to contract interactions, and as your contracts will be written in Cairo, snake_case will feel more natural.

It'd also be nice to know how Solidity -> Cairo compiler want to handle that, like https://github.com/NethermindEth/warp

my 2 thoughts

[martriay]

Interesting, but I imagine abstraction won't be ERC20 specific, but for general method calls. @fracek provided a very good example of what I mean.

[maciejka]

How Solana solves that problem? There should be a similar problem. Rust uses snake case for method names.

[martriay]

as @spalladino said, Vyper chose camelCase for that reason

[bbrandtom]

vyper uses ethereum, it's not the same comparison.
As far as I can tell, Solana token uses rust convention.

[martriay]

@bbrandtom exactly, because solana decided not to go after interoperability. camelCase is not native to ethereum, is a style convention from Solidity that got into the EIPs. Cairo is facing the same situation Vyper faced.

[martriay]

After having discussed and thought about this for a while now, this is how I see this:

Interfaces

Given that we're discussing the implementation of a standard and standards are all about interoperability, I think the focus of the discussion should be on interfaces only (not coding style). We should consider several kinds of interoperability:

• cairo <> cairo
• cairo <> EVM (ethereum, optimism)
• cairo <> web2 (e.g. frontend, or backend app)
• cairo <> ???

ERC20 compatibility

If we want to implement ERC20 there's more than just function names blocking us. The ERC20 standard assumes a given ABI encoding (Ethereum's) which Cairo doesn't have and it would also requiere a similar uint256 interface and a common JSON RPC API.

But it's doable. For uint256, the Cairo implementation could be changed such that it plays nicely. JSON RPC API interoperability I think it's being considered by the StarkWare team already and the ABI part can be solved through an adapter.

Conclusion

• If we decide to go for the EVM interoperability path (and I think we should), then I think we should go for full ERC20 compliance which means using camelCase and also pushing for a better uint256 interface, JSON API and ABI encoders. snake_case would only be an additional problem to deal with.
• If we decide not to chase the EVM and instead rely on external projects to handle interop themselves, then we should be super clear in that this is NOT ERC20 and move away from it, starting with the name (SNET20? idk). Then snake_case is a good option.

[maciejka]

I think that it is rather an interpretation than implementation. StarkNet is a significantly different execution environment with its own set of design choices that can't be hidden by just an interface.

Input from StarkWare would be helpful. They have enormous power to establish practicies in this ecosystem.

Just for information, here is our (Maker) interpretation of erc20 for DAI: https://github.com/makerdao/starknet-dai-bridge/blob/mk/draft/contracts/l2/dai.cairo

[spapinistarkware]

I already said I'd rather snake_case:)

[martriay]

So you would agree on not calling it ERC20 then?

[frangio]

StarkNet is a significantly different execution environment with its own set of design choices that can't be hidden by just an interface.

The point we want to make is that it is a worthwhile pursuit to offer an Ethereum-compatible interface to StarkNet, which coupled with an exact ERC20 interface could make integration into the existing ecosystem significantly easier. If this is technically impossible I would love to see the explanation and we can move on with a custom fungible token standard using snake case.

But if it is technically possible, and there is a project to build a compatible JSON RPC interface, and there is a feasible path to abstracting away the different ABI encoding, then I don't think we should put more obstacles in the way of that pursuit by using different function names than ERC20.

[maciejka]

Good argument for camelCase is: if StarkNet is ever going to have EVM compatibility, then I would like to be able to use contracts that interact with erc20 like tokens (let's say Uniswap v2 contracts) without any modifications. It means this hypotetical Uniswap contract on StarkNet should recognize native StarkNet tokens and its liquidity tokens as first class tokens on StarkNet.

[taureau75]

I think as far as possible we should attempt to be compatible with existing standards and stick to camelCase for ERC-20.

If we're going to go down the route of incompatibility, then I say we got all out and drop the 256-bit uint in favor of 251-bit (?) felts.

[spapinistarkware]

I would even say 128bit numbers in a felt, since that is a single range check. Do we need more than 128bit?

[taureau75]

Let's say we're bridging in ERC-20s. What's the most digits we've seen a token use? I haven't seen more than 1 quadrillion with 18 decimals, which is 33 digits. That's under 128 bits.

I will say that it makes me a little nervous to be that far off the ERC-20 standard. But if tokens aren't using those bits, then I see the argument.