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
-
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.
-
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.
-
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