Starkware community call #2 summary
Community call video link: https://www.youtube.com/watch?v=LyvNiQd3oLY
Below is a summary of the second community call of Starkware. I have captured the key highlights and summarised them in an easy to understand way.
Participants
Thiago and Fabian from Shard Labs
Henri and Liron from Starkware
StarkNet tooling development
StarkNet Hardhat Plugin
In this section, Fabian from ShardLabs explains how the plugin they have developed for HardHat can be used by smart contract developers to compile and deploy contracts on the StarkNet devnet.
This HardHat plugin offers few advantages for developers by saving them time from typing long commands on StarkNet CLI to compile and deploy contracts.
To speed up the process of testing, ShardLabs developed starknet-devnet which is a local version of the testnet. This helps in quickly deploying and interacting with the smart contracts on the devnet. It can also be used to reuse the deployed smart contracts.
Q&A with Starkware
A quick introduction of Liron who is the ecosystem manager at Starkware.
After the intro, they get into the Q&A to discuss important topics related to Starkware ecosystem.
Data availability
The first question is about data availability and what it means in the context of L2 scaling solutions such as Starkware ecosystem.
StarkNet generates the mathematical STARK proof using zero-knowledge cryptography which is sent to the layer-1 Ethereum.
The problem is if we would just send these proofs to Ethereum layer-1, then ETH would only know that the state transition which happened on StarkNet was valid (i.e, moving from state A to state B) however, ETH would not know about the new state B.
So, there are two things we need to tell layer-1 Ethereum.
- Validity proof which the generated STARK proof gives us
- Data availability telling us about the new state.
Now, the problem is that the data availability is expensive on layer-1. Storing data on ETH is an expensive operation.
To tackle this, there are 3 basic approaches
Validium (Immutable and Sorare use this)
In this data availability mode, the data is kept off-chain.
The key advantage of this approach is a tremendous gas saving
On the other hand, a disadvantage is centralised authority.
Everytime we submit a proof in Validium mode, we also submit an approval from DAC (Data Availability Committee) that the root of this tree which summarises all these states is indeed valid.
ZK-rollup — Store all data on-chain (DyDx)
ZK rollup is the second type of data availability mode in which data is stored on-chain.
There are two important things to note here:
- There is no data sent for accounts which had no state change in the duration between submission of two proofs by L2 to L1
- If an account did a number transactions on StarkNet, you only need to make a state update on L1 about its final state and not the intermediate states.
Volition [ETA : Jan 2022]
This is the third type of data availability approach.
In this case, each user at the transaction level can decide whether they want to store the data on-chain vs off-chain.
off-chain = cost is 0 but more centralised. In some cases such as DyDx, users would want to store data off-chain to keep their trading strategies secret.
on-chain = the main advantage is the security and decentralisation of Ethereum layer-1 blockchain.
The estimated availability for Volition data availability mode is Jan 2022.
Roadmap of Starkware / Plan for decentralisation
The road to StarkNet can be summarised in following 3 stages:
Planet = Single-app rollups, apps with which you can interact in zero-knowledge mode, be it Validium or be it zk-rollup. Examples: Immutable X, DyDx.
Constellation = StarkNet network where you can write smart contracts that can interact with other Dapps. This is the Alpha rollout on mainnet. This introduces composability.
Universe = StarkNet network where anyone can become a validator, a prover or a sequencer. Fully decentralised and permissionless.
The team is currently researching on decentralisation and evaluating/researching various designs/consensus algorithms wondering how to separate different roles in the network.
The sequencer is an entity which chooses the transactions which goes into the prover.
The prover is responsible for gathering the transaction payload, executing them and generating the STARK proof
Challenges of decentralisation
The task of decentralising sequencers is not trivial. Its very different from decentralising miners on L1
When you have a sequencer feeding transactions into a prover, it gets more complicated because there are checks that you need to do before you a generate a proof.
What does it mean to be a StarkNet full node?
Let’s say StarkNet runs for 2 years and then after 2 years, you want to join the network as a full node, you can take all the state differences and you can verify all the proofs of execution and then catch up with the network quickly.
How do you catch up with states that have not been proven yet?
Releasing alpha to mainnet is about testing the pipeline before implementing decentralisation
Ecosystem will be built together with this mainnet release
The plan is full decentralisation.
Question about Polaris prover license
Polaris prover license aims at protecting the community from copycats, basically from someone taking the prover code, deploying it somewhere else stealing the intellectual property the community has built.
Objective of license is not to extract value but to ensure that the value accrues to the community.
Code will be available but you won’t be able to use it anywhere else than the actual endpoint on L1 that will have a deploy for that.
Who will be able to run the prover?
You’ll be able to run a prover, anyone will be able to run a prover without KYC. Prover role will be decentralised.
You won’t be able to run it on another chain without the StarkNet community being involved and accepting this.
ZigZag DEX founder talks about their project
ZigZag is a decentralised exchange being built using layer-2 scaling solutions such as StarkNet
