SNIP-3668: Verify Starknet state/storage proofs in Solidity through a CCIP-Read implementation #106
Conversation
|
|
||
| ## Simple Summary | ||
|
|
||
| Implementation of the CCIP-Read standard ([ERC-3668](https://eips.ethereum.org/EIPS/eip-3668)) specifically for the Starknet state, making it possible for L1 contracts (and later any L2 contracts) to fetch contract state data from Starknet. |
There was a problem hiding this comment.
what do you mean by "later any L2 contracts"?
There was a problem hiding this comment.
like a Solidity contract on Arbitrum should be able to read the state of Starknet by:
- doing a L1SLOAD call to get the current state root of Starknet core contract
- verifying a merkle inclusion proof of a slot against that state root
| How does one query trustlessly a storage slot from Starknet at the time of writing (August 2024)? | ||
|
|
||
| 1. Run a full node and query the `starknet_getStorageAt` RPC endpoint. | ||
| 1. Query the `starknet_getStorageAt` RPC endpoint of an external provider and along with a merkle inclusion proof of that specific storage slot (`pathfinder_getProof` is the only way to achieve this at time of writing). Note that without the inclusion proof, your request is trusted and thus not trust-minimized. |
|
|
||
| - The deployment of an official Solidity contract able to verify a Merkle inclusion proof for the Starknet state against the Starknet core contract's state root, on Ethereum L1. | ||
| - An off-chain service, so-called "gateway", able to provide inclusion proofs for a specific storage slot. | ||
| - (Optional): The inclusion of a view entrypoint in the Starknet core contract on L1 to verify a Merkle path (This was proposed in Rollcall - the governance body of rollups - by Vitalik Buterin). |
There was a problem hiding this comment.
In what way is the optional entrypoint for verifying Merkle paths in SN core contract different than the analogue entrypoint in the new solidity contract?
There was a problem hiding this comment.
You're correct, it's exactly the same! The only difference is the strong link to Starknet core if it's directly an entrypoint there. It's more "official" in a way and centralized.
| ## Implementation | ||
|
|
||
| The implementation must be thoroughly planned and specified with stakeholders. | ||
| For one, we must be reasonably certain that the Starknet storage layout is stable for the next quarter to implement the Solidity contracts that verifiying the Starknet state. |
There was a problem hiding this comment.
verifying -> verify
|
|
||
| Implementation of the CCIP-Read standard ([ERC-3668](https://eips.ethereum.org/EIPS/eip-3668)) specifically for the Starknet state, making it possible for L1 contracts (and later any L2 contracts) to fetch contract state data from Starknet. | ||
|
|
||
| The intended use is for contracts on L1 to be able to verify data from contracts on Starknet in a read context via a Solidity contract able to verify Starknet inclusion proofs against the Starknet Core Contract's state root. |
There was a problem hiding this comment.
- Could you add some words about the fact that the root on L1 is "stale" (can be 100s of blocks old) and that any usecase should be fine with proving something about an old snapshot of state (the root or predecessors).
- The current updateState schedule is such that after a train is proven, several updateState are sent on L1, for several consecutive blocks. There is a bad scenario where you need to recalculate your inclusion proof against the latest root during several blocks because your tx ends up after an updateState tx everytime you send it. Maybe worth adding this nitpick, up to you
|
|
||
| The main repositories to check as references are: | ||
|
|
||
| - The ENS EVMGateway repository, that lists all the L1 and L2s verifier contracts and their code: <https://github.com/ensdomains/evmgateway> |
There was a problem hiding this comment.
Do the L1 contracts of different chains obey the same interface (say, up to function signatures)?
There was a problem hiding this comment.
Do the L1 contracts of different chains obey the same interface (say, up to function signatures)?
I'll have to check this in implementations of EIP-3668. I don't know. I hope so otherwise it ruins the purpose of making it an EIP in the first place.
|
There hasn't been any activity on this pull request recently, and in order to prioritize active work, it has been marked as stale. |
|
@Eikix ping on the above comments, to avoid github bot closing the PR for inactivity |
Thanks! I pinged @nconsigny on this specific SNIP. We might convert it into a new kind of RIP, solely focus on being able to read the Starknet state from any EVM chain (L1 and L2) using the state root of Starknet on L1 as well as merkle paths. |
Hi,
Creating this draft SNIP to get feedback from the community and finish what was started by Nethermind earlier: https://github.com/NethermindEth/starknet-state-verifier
The challenge is to be able to verify an inclusion proof from Starknet in EVM runtime. This will enable reading Starknet from L1 in contracts as well as later, in any EVM-compatible L2. This will greatly increase the interop abilities of Starknet as well as Starknet appchains in the future (keystore rollups and namespace rollups).