CCIP implementation for ENS on StarkNet

Nethermind proposes to build a CCIP implementation for ENS on StarkNet allowing StarkNet to be used as a resolution mechanism. The project also proposes to delegate the entire .starknet.reverse lookup space to StarkNet through CCIP allowing StarkNet users to trustlessly configure the reverse lookup for their addresses on StarkNet itself.

This will

  • allow users to effortlessly link their StarkNet addresses to their ENS domain permissionlessly and trustlessly.
  • let StarkNet applications integrate with ENS. e.g. StarkNet block explorers can display linked ENS names for accounts
  • provide some of the the infrastructure for generalised CCIP-read for StarkNet thereby growing ethereum’s CCIP’s power and capabilities
  • in the future provide a cheap and trustless storage layer for registries. StarkNet will provide a ‘validium’ storage system further reducing storage costs

We’re very excited about the recent development of CCIP and want to see this adopted by as many chains as possible.

Pending a pedersen hash

The CCIP works by evaluating state proofs of StarkNet state, this requires a Pedersen hash to be available on StarkNet. Currently there are only a few implementations of this, none deployed on mainnet, audited or standardised. Creating a performant solidity based Pedersen hash is still an open problem. While a PoC implementation does exist, we would like some help from the Ethereum community to set a high standard for this. Solving this requirement will open a number of other StarkNet applications on Ethereum as well. This is non-blocking and the we propose to build the system with the expectation that there will be a performant implementation of the hash in the near future.

About Nethermind

Nethermind originated as an Ethereum client implementation written in .NET. From there we have grown to an organisation of over 250 people who work in application layer development, core infrastructure for a number of chains and fundamental research in Blockchain tech and ZK. We are heavily involved in the StarkNet ecosystem and wish to see it progress in every respect.

We’ve recently bridged AAVE tokens to StarkNet, built the Warp transpiler and transpiled Uniswap to Cairo.

Deliverables and timeline

  • 4 weeks - StarkNet state proof contract on solidity using Pederson hashes and testing - requires some novel work, the Pederson hash exists but the storage proofs from Ethereum can’t be used
  • 3 weeks - Develop a StarkNet resolver contract on l1 for the Gateway and testing
  • 2 weeks - CCIP Gateway configuration for StarkNet (currently just needs to ping the only StarkNet gateway, will need to be updated with a dedicated RPC for StarkNet when StarkNet decentralises next year)
  • 2 weeks - Client implementation and updates s.t. StarkNet is supported and the client uses and correctly displays results from the CCIP
  • 1 week - Deployment scripts and testing

Total: 12 weeks

Financing

We are looking for an allocation of $60,000 to cover the development work of 12 weeks. We will work in close contact with members of ENS labs and the ENS DAO to make sure the work is on spec during the development. The delivery will consist of a repo containing all the contracts required to perform the StarkNet CCIP and a working testnet deployment. The production readiness, auditing and final deployment of the system will be left to further discussions with ENS labs and the ENS DAO with the expectation of further proposals pending the success of the implementation.

5 Likes

Thank you for the proposal. Please see my comments below

There is already a prototype implementation at starknet-storage-proof-solidity/StorageProof.sol at main · Kelvyne/starknet-storage-proof-solidity · GitHub do you require 4 weeks in addition to the work already done, or do you take completely different approach so that you have to build from scratch (if so please clarify the difference).

Starknet.id · GitHub already has functioning resolvers. is it something we can work with the team to use their solution or make it reusable using some of their component?

Is this to make feat: add plumbing for `pathfinder_getProof` by Mirko-von-Leipzig · Pull Request #787 · eqlabs/pathfinder · GitHub endpoint available under your hosted node?

Can you specify this in a bit more detail? The whole point of ccip read is that the gateway service absorbs the different chain calls so that end users and dapps can retrieve data using normal ethereum client libraries like ethers.js and web3.py

Additionally, which part includes implementing the reverse lookup? (I am guessing that your 3 weeks work to build a resolver is for forward lookup) reverse registrar (under .addr.reverse) is currently hosted on Ethereum l1. Moving the reverse lookup of only starkeware addresses requires some architectural changes which we haven’t discussed yet.

This is a good starting proposal. I would encourage working with other projects (starknet.id, argent, etc) so that the deliverables are with reusable/sharable service by the whole starknet community. This may result in splitting up the responsibilities among different teams rather than giving grants to a single team.

Again thank you for taking the initiative

2 Likes

3 weeks - Develop a StarkNet resolver contract on l1 for the Gateway and testing

*Starknet.id · GitHub 2 already has functioning resolvers. is it something we can work with the team to use their solution or make it reusable using some of their component?*

Apologies, that should have said “Develop a Starknet resolver contract on L2 for the Gateway and the testing”.

The first thing to note is that there are three different deliverables here

  1. Delegating to StarkNet using CCIP for individual ENS domain resolutions
    This could be done for any domain and can technically resolve to any supported address format.

    StarkNet.id’s resolution mechanism can be used successfully here however the configuration of addresses needs to be altered from starknet.id’s because they use different domain formats: ENS uses variable length strings to represent subdomains while starknet.id uses fixed length strings. This can be treated as a special case just for this (small change to starknet.id’s contracts) or we can push for variable length strings to be support in general by starknet.id (much bigger change to starknet.id contracts)

    If we tightly integrate with starknet.id, starknet.id would also need to accept .eth domains rather than solely .stark domains in their registry.

    We presume that the registration of a .eth domain would not be done on StarkNet, or through starknet.id, however a form of ‘registration’ will still need to occur in order to prove L1 ownership of a .eth domain name on StarkNet. A CCIP-write potentially, or just a L1 → L2 message. I imagine this can be relatively easily implemented.

  2. Delegating to StarkNet for the entire reverse lookup space of StarkNet addresses

    This has open questions: should the reverse lookup resolve in .eth addresses or .id addresses by default? Should it do either or both? I don’t know what consideration ENS has done for multiple TLDs and how to handle them before.

    Once again the difference in subdomain encoding mean that the resolution mechanism by starknet.id may need altering in order to support .eth domains.

  3. Integrating starknet.id and ENS by bridging

    This is not what what we were looking to resolve but we presume that the previous two deliverables would have a heavy influence on the result.

    Again the proof of ownership of a domain on L1 is a factor here.

We’re very keen to work with the starknet.id team and see how much of their solution we can integrate with or leverage. Development time may be reduced here if we decide to leverage the existing starknet.id solution, though there will also be the usual coordination overhead involved.


The subsequent responses are mostly written by @FawadHa1der

4 weeks - StarkNet storage proof contract on solidity using Pederson hashes and testing - requires some novel work, the Pederson hash exists but the storage proofs from Ethereum can’t be used

There is already a prototype implementation at starknet-storage-proof-solidity/StorageProof.sol at main · Kelvyne/starknet-storage-proof-solidity · GitHub do you require 4 weeks in addition to the work already done, or do you take completely different approach so that you have to build from scratch (if so please clarify the difference).

The prototype implementation only verifies one storage var proof, as in, the path and the value of storage var which belongs to the storage root of the contract.

Our proposed final implementation will use the same or a derivative Pedersen hash implementation but will use a verifier written by Nethermind. This verifier needs to not only verify that the pedersons are correct but that the data returned is of the correct format e.g. the data Is a correct ENS domain which matches the hash used as the key for the storage variable in StarkNet.

This contract will need to handle additional logic to be set as an ENS resolver on L1 by the user per EIP-3668. Which includes handling [OffchainLookup](<https://eips.ethereum.org/EIPS/eip-3668#use-of-ccip-read-for-transactions>) in case of CCIP Read addresses.

Some additional thought/time needs to be given on format for the storage/contract proofs. Currently the pathfinder_getProof endpoint exports its proofs as json. Some time is required to decide on which optimised format to use on-chain, perhaps RLP for example. So whether we copy the verification of this implementation or alter it significantly remains to be seen.

Even though we are not limited by gas, we need to take performance of the Pedersen implementation into account. My latest tests show that the solidity Pedersen Hash of two uint256 takes about 200 ms (on 2.9 GHz Quad-Core Intel Core i7) and take about 1075020 Gas. Considering the depth of the tree this probably needs to be optimised for a good UX - we don’t want users waiting seconds for domain resolution. This link might give you an idea of a storage proof and account proof and give an idea of the number Pedersen hashes required here. That response is from the pathfinder_getProof api.

There may also be some bugs lurking in the Pedersen implementation. It seems good but it hasn’t been formally audited or verified nor has it actually been used in the wild.

In addition to storage var proof, the contract proof itself needs to be verified to be part of the StarkNet state root which has been committed to by the StarknetCoreContract.

We will likely need to handle proofs for multiple storage vars, especially if the stored value is a struct or an Array type of some sort or has a Ethereum datatype like uint256 which overflows the native felt type of StarkNet. In that case we will have to generate proofs for every 251bit felt which comprises the data, and reconstruct and verify the type of the data on the L1 side.

Identifying issues and coordination around state proofs likely will take some of the developer resources, we expect this because the state proof feature only landed in pathfinder last week and hasn’t been battle tested. We would also like the StarkNet gateway to support this method. The 4 weeks also includes deployment and extensive tests for the hash and the verifier. (no easy feet, the verifier is likely expensive to deploy). We are currently working on a small UI App to help with testing of any storage var on Goerli against the verifier that we have developed internally.

We are being very conservative with our time estimates since the stack is still very much in flux. If there are development time overruns, it will likely be caused by performance issues and bugs in exporting and verifying of the proofs and we don’t want this to add unexpected costs.

Considering all of these issues I think 4 weeks is reasonable. It’s really not an instance of ‘use this verifier’.

2 weeks - CCIP Gateway configuration for StarkNet (currently just needs to ping the only StarkNet gateway, will need to be updated with a dedicated RPC for StarkNet when StarkNet decentralises next year)

Is this to make feat: add plumbing for pathfinder_getProof by Mirko-von-Leipzig · Pull Request #787 · eqlabs/pathfinder · GitHub 1 endpoint available under your hosted node?

Correct, this involves hosting/configuring the node and development of a minimal service to accept the request from the client which will include the address of the contract, the ens name for the query and return the proof for the query in a format that the contract(resolver/verifier) on L1 expects.

The current pathfinder_getProof API is only implemented by pathfinder - one of the StarkNet fullnode implementations. The node will need a dedicated fully synced pathfinder node to be configured and run. Who runs the gateway service and pays for the running and maintaining the gateway service and the pathfinder node behind it still needs to be discussed. For this deliverable we will provide the code and demonstrate-able infrastructure to go along with it.

2 weeks - Client implementation and updates s.t. StarkNet is supported and the client uses and correctly displays results from the CCIP

Can you specify this in a bit more detail? The whole point of ccip read is that the gateway service absorbs the different chain calls so that end users and dapps can retrieve data using normal ethereum client libraries like ethers.js and web3.py

Yes, we should have been more explicit about this. Testing the whole integrated system basically and hopefully ethers.js and web3.js handle the revert correctly for CCIP-read. This includes any debugging that comes when integrating all the parts. We are making a small UI tool to help with proof generation-verification issues, only meant for testers/maintainers. We’ve already started a small PoC for this which we will share in the upcoming days.

And yes, while this should be completely transparent to the UI I propose we consider adding a small badge to mark that it was resolved off-chain via CCIP to raise awareness about the efficacy of the method.

Additionally, which part includes implementing the reverse lookup? (I am guessing that your 3 weeks work to build a resolver is for forward lookup) reverse registrar (under .addr.reverse) is currently hosted on Ethereum l1. Moving the reverse lookup of only starkeware addresses requires some architectural changes which we haven’t discussed yet.

Yes our proposal did not adequately explain the reverse lookup process. Our assumption is that .starknet.reverse lookups will be resolved the same way via CCIP-read. We presume the ENS team will add some additional logic to resolve .starknet.reverse addresses using the CCIP-read process or that we would design this part and write the proposal for it as part of this effort. Configuring the entire reverse lookup space for StarkNet address to use CCIP on StarkNet was suggested by Nick. We did factor in working on the ENS changes and making a proposal for them into the timeline.



In light of the conversation with Makoto and starknet.id the proposal is being reworked with slobo.eth

Thank you @matoken.eth, @mempoolsurfer, and @FawadHa1der for contributing to this post.

Looking over the discussion so far a few things became clear.

First, this project requires conversations and coordination with starknet and other groups in their ecosystem. @matoken.eth is in active discussions with several of the key participants.

Second, we could pull out the CCIP Gateway configuration for StarkNet deliverable and have nethermind start making progress on that. Often times working on a part of the puzzle provides insight to the bigger picture.

I’ve had conversations with both Makoto & Nethermind and we believe there is value in delivering the gateway, while a broader discussion takes place in January with the relevant parties. The ecosystem working group will fund 20,000 USDC to nethermind for this and related work.

It is likely that the full scope of this project will likely require multiple grants to several parties, along with support from the starknet ecosystem.

I suggest that this thread continues to focus on the technical discussion.

5 Likes

Sneak preview of some of the work here by @FawadHa1der: https://twitter.com/mempoolsurfer/status/1617577471511232512?s=20

A detailed update to follow next week!

ENS post quick update

The team at Nethermind has been working hard with the starknet.id team to get ENS names to resolve from StarkNet.

To do this we’ve implemented

  • A basic CCIP-read ens resolver which you can delegate your ENS entry to. This resolver also verifies the storage proofs returned by the gateway service.
  • A gateway (currently hosted on google cloud) which fetches proofs from our hosted fully synced pathfinder node.
  • A modified starknet.id resolver which supports us in creating StarkNet state proofs (done by the starknet.id team)

We will be open-sourcing this implementation next week so the community can discuss the design. The implementation still needs some minor modification, cleanup, performance improvements and some more testing.

Some questions and opinions for the next steps are:

  • How do we structure the custom resolver on the Ethereum side so that we only need to deploy it once? We can do a very similar structure to the ENS contracts here.
  • We suspect the implementation and/or interface of the starknet.id resolver on StarkNet might change and that this change will likely have an impact on the our Ethereum-side resolver implementation. We will be in touch with the starknet.id team for this. It might be the case that the resolver needs to be upgradable or that we wait until starknet.id is happy to commit to a standard.
  • Do we create a user-friendly UI for people to configure this nicely, and should it be on the ENS site or elsewhere (e.g., voyager.online or starknet.id)?
  • Who has the responsibility of maintaining the gateway and the associated fully synced pathfinder node implementation? I believe some subset of ENS labs, StarkWare, Nethermind, starknet.id and other third parties should host a few instances of this.
  • Who has the right to change the gateway URLs?
  • We need some discussion about auditing and deploying the pedersen hash and verification contracts. The Audit and mainnet deployment need their own post explaining the options available and associated costs.

Here is a working example on Goerli: https://strk-cointype.ens-app.pages.dev/name/princeisagreatdeveloper.eth/details.

You can also play a little more with https://ccip-helper.nethermind.io/!

Major props to @FawadHa1der for doing the bulk of the work, @matoken.eth, the starknet.id team and Prince @ Nethermind for all their help.

1 Like

If you have a single registry on the starknet side, this can be a single contract instance with no configuration required beyond the user setting it as their resolver. That leaves you with the issue of determining who is authorised to update records on the starknet side, however.

If you have multiple registries on the starknet side, you will need either per-user resolvers on the Ethereum side, or a way to configure the resolver for each user to point to their registry on starknet.

Indeed - and you might consider delegating the ability to upgrade implementations to the DAO, for safety.

It would be good if there was something - preferably integrated with the ENS app.

Ideally the DAO would give a grant to one or more organisations to run gateways.

This should be under DAO control too.