Follow StarkNet Astro ✨
Chinese Channel；English Channel
The content of the sharing session is too long, and this AMA summary has been significantly shortened. If you want to learn more about StarkNet, you can visit the StarkNet Astro knowledge base page.
StarkWare#
StarkWare is the development team behind StarkEx and StarkNet, primarily composed of cryptographic engineers. The inventors of STARKs and SNARKs are among its founders, showcasing top-notch technical strength; in terms of financing, it has raised a total of $270 million, with a valuation reaching $8 billion, making it the highest in L2.
StarkEx#
Introduction#
StarkEx is a corporate service created by StarkWare, customizing ZK Rollups for project parties. It helps projects customize proprietary ZK Rollups. Current clients using StarkEx include dYdX, Sorare, ImmutableX, DeversiFi, and others.
Unlike general ZK Rollups, in the customized ZK Rollups through StarkEx, project parties often have super administrator privileges, allowing them to decide whether transactions go through and their order. External developers cannot deploy applications without permission, making the network relatively centralized, but the advantage is extremely high performance.
How It Works#
The workflow of StarkEx is as follows:
-
Packing Transactions: An off-chain server (often centralized by the project party) processes customer requests, combining multiple transactions into a "batch" for StarkEx to handle.
-
Confirming Transactions and Updating Status: The off-chain server confirms the legality of the transactions and updates the system status in a compressed hash form.
-
Generating Proofs for Transactions: SHARP generates STARK proofs for the transactions to confirm their validity, then sends the proofs and updates to the on-chain Verifier smart contract to ensure the integrity of the transactions.
-
On-Chain Verification of Proofs: Once the STARK proofs are verified, the status updates are submitted and settled back to the Ethereum mainnet. All transactions are processed and verified off-chain, while their integrity proofs are verified on-chain.
SHARP is a shared prover that provides proof generation services for multiple StarkEx clients/applications—generating proofs of computational integrity statements. The Verifier is a smart contract deployed on Ethereum used to verify the correctness of STARK proofs generated by StarkEx transactions.
StarkNet#
Introduction#
StarkNet is a general-purpose ZK Rollup, theoretically capable of increasing TPS to over 2000 and reducing Gas to below 0.002.
Why does StarkNet have higher performance compared to Ethereum? First, let's review how Ethereum works. On Ethereum, every submitted transaction requires all nodes to check, verify, and execute the transaction to ensure computational correctness, broadcasting the computed state changes across the network.
In contrast, StarkNet only executes computations off-chain and generates a ZK proof, then verifies the correctness of that proof on-chain, ultimately packing multiple L2 transactions into a single transaction on Ethereum. Therefore, the transaction costs occurring on StarkNet can be shared among other transactions in the same batch, similar to carpooling (🚌拼多多); the more transactions there are, the lower the cost. The method StarkNet uses to generate ZK proofs for transactions can significantly enhance network speed, reduce on-chain communication, and increase network throughput, resulting in higher TPS and lower Gas compared to Ethereum.
In short, comparing the verification of computational correctness to a teacher needing to check whether students have mastered the knowledge: Ethereum's method is to check if each student can recite the entire textbook, while StarkNet's method is to have students take a test. The latter is more efficient, costs less, but still ensures security.
EVM Compatibility#
The StarkNet network itself is not EVM (Ethereum Virtual Machine) compatible and has designed a separate ZK-friendly Cairo VM, which is what Vitalik referred to as the fourth type of zkEVM, but it belongs to a strictly defined zkVM.
In terms of zkVM architecture, StarkNet has implemented a more ZK-friendly instruction set, assembly language, bytecode, AIR (Algebraic Intermediate Representation), and the high-level language Cairo.
Although StarkNet itself is not EVM compatible, it can still be compatible with Ethereum through other means.
- Warp: A translator that converts Solidity to Cairo language.
Warp is a Solidity-Cairo translator, currently developed by the well-known Ethereum infrastructure team Nethermind. Warp can translate Solidity code into Cairo, but the translated Cairo program often requires modifications and the addition of Cairo features (such as calling built-in functions, optimizing memory, etc.) to maximize execution efficiency.
- Kakarot: A zkEVM written in Cairo language.
Kakarot is a smart contract written in Cairo, currently deployed on StarkNet (Goerli testnet), 100% bytecode equivalent to EVM. It is currently in the testing phase. Ethereum applications can be ported to StarkNet by deploying to Kakarot.
-
✅ Kakarot can: (a) execute any EVM bytecode, (b) deploy EVM smart contracts as-is, (c) call functions of EVM smart contracts deployed on Kakarot (view and write methods).
-
✅ Kakarot is an EVM bytecode interpreter.
Currently, it supports all EVM opcodes.
How It Works#
StarkNet consists of five components: the Prover (prover), Sequencer (sorter), and full nodes on StarkNet; as well as the Verifier and core state contract (StarkNet Core) deployed on Ethereum.
The workflow is as follows:
-
When we initiate a transaction on StarkNet, an off-chain server—the sorter—will receive, sort, verify, and package them into blocks. It executes the transactions, and then the state changes are sent to the StarkNet Core contract;
-
The prover will generate proofs for the transactions and send them to the Ethereum verifier contract;
-
The verifier will send the verification results to the StarkNet Core contract on Ethereum and trigger a set of new Ethereum transactions from the StarkNet Core contract to update the global state on-chain for record-keeping. The state transactions are sent as "calldata" (Blob after EIP-4844) to save L1 transaction gas. These "metadata" can be decrypted by StarkNet full nodes.
Full nodes primarily serve storage functions. Full nodes store state changes, metadata, proofs, and all transactions executed in StarkNet, tracking the current global state of the system. When necessary, full nodes will decrypt the "metadata" to reconstruct StarkNet's history.
Refer to StarkNet development advocate @barretodavid for the “StarkNet's Architecture Review”.
Account Abstraction#
Unlike Ethereum's dual account design of EOA + CA, StarkNet implements native account abstraction, with only one account design, drawing on the spirit of EIP 4337. The following diagram illustrates the transaction model:
STARK Proof System#
Currently, there are many different proof systems (for generating and verifying proofs), such as Halo, PLONK, Groth16, Groth09, Marlin, Plonky2, etc., all of which belong to the SNARK proof system. A proof system consists of a prover generating proofs and a verifier verifying those proofs. Different ZK projects almost always use different proof systems, while StarkNet uses STARK, which in some sense belongs to a special type of SNARK.
STARK has more innovations compared to SNARK. It does not require a "trusted setup" like SNARK. It also has simpler cryptographic assumptions, avoiding the need for elliptic curves, pairings, and knowledge assumptions, relying purely on hashes and information theory, thus being resistant to quantum attacks. Overall, STARK is more secure than SNARK.
In terms of scalability, STARK has stronger scalability. The proof generation speed has linear scalability, while verification time and proof size have logarithmic scalability. However, the downside is that the generated proof size is larger. But as the proof scale increases, the verification cost will decrease marginally—this means that the larger the proof, the lower the total cost.
In summary, compared to SNARK, STARK is more secure, and the average verification time and proof size will decrease as the verification scale increases, with the downside being that the initial proof size is larger, making it more suitable for large-scale applications.
Here, we introduce an important feature of STARK: recursive proofs.
Any general, succinct proof/argument system (especially STARKs) can be used to incrementally verify computations. This means that a computation can produce a proof to demonstrate the correctness of a previous instance of that computation, a concept informally referred to as "recursive proof composition" or "recursive STARKs."
In other words, a recursive STARK prover can generate a proof for a statement, indicating that the system's state can transition from a to a+1. Because the prover has already verified a (recursive) proof of the computational integrity of a, and has faithfully executed the computation of state a, reaching the new state a+1. In short, you can understand this process as merging the proofs of a and a+1 into one proof, theoretically allowing for the merging of nearly infinite proofs into one proof, significantly reducing proof size and verification time. As shown in the diagram below:
Cairo VM and Cairo Language#
Overview of Cairo VM#
Cairo VM is a CPU VM based on the von Neumann architecture, and its programming language is also called Cairo. The Cairo language is based on Cairo assembly, thus offering very high compilation efficiency. Cairo stands for CPU Algebraic Intermediate Representation (Algebraic Intermediate Representation). Cairo VM includes a single AIR to verify the instruction set of this "CPU."
It is sometimes referred to as StarkNet OS/Cairo OS. Unlike EVM, Cairo VM does not execute computations; it only generates proofs for computations and verifies their correctness.
Regarding how it works, it updates the system's L2 state based on the transactions received as input. It facilitates the execution of Cairo contracts. Cairo VM is based on Cairo, and the specific system operations and functions available for contracts can be called as operating system calls.
Features of Cairo VM#
Flexible CPU Architecture
Cairo VM adopts a Turing-complete von Neumann CPU architecture, which can approach AISC performance through software programming, with a corresponding instruction set, so Cairo can theoretically replicate other virtual machines.
Read-only Non-deterministic Memory Model
Cairo VM uses read-only non-deterministic memory, meaning that the value of each memory unit is chosen by the prover and cannot change over time (during the execution of the Cairo program); it is immutable. The instruction can only read from it. We can think of it as a one-time writable storage: a value can be written to a unit once, but cannot be changed afterward. Moreover, it is contiguous, and if there is space, it will be filled with arbitrary values.
The advantages of ROM include: low cost, simpler circuits than ROM; permanent storage, memory values will be guaranteed to be permanently stored; tamper-proof, data cannot be modified or deleted.
Overview of Cairo Language#
Cairo is the smart contract language of StarkNet, based on STARK design, and Cairo programs can generate STARK proofs.
Cairo programs are collections of assembly code, and Cairo developers will write smart contracts in the high-level language Cairo instead of Cairo assembly. When we write a Cairo program, the Cairo compiler compiles the Cairo code into Cairo assembly, and the Cairo assembler generates Cairo bytecode (which runs on the Cairo CPU) for execution in Cairo VM. When it finally runs on a real machine, it still needs to be compiled into opcodes and machine code (as well as instructions).
Features of Cairo Language#
Bootstrapping: Loading Programs from Hashes
Programs can write the bytecode of another program into memory and then run that program. This has two benefits:
-
Scalability, verification time and program size exhibit a logarithmic relationship, as mentioned in the STARK section.
-
Privacy, verifiers can verify whether the program executed correctly without knowing the computation.
Built-in Functions: Reducing Code Compilation
Developers can directly call built-in functions to reduce computational overhead and optimize the development experience without needing code transformation. Adding built-in functions does not affect CPU constraints. This simply means that the same memory is shared between the CPU and built-in functions, as illustrated.
The Cairo architecture does not specify a set of particular built-in functions. Built-in functions can be added or removed in AIR (Algebraic Intermediate Representation) as needed.
Featured Ecosystem#
Unlike other ecosystems, StarkNet has some native innovative applications, including on-chain games, contract wallets, and on-chain AI.
Regarding on-chain games, they differ from GameFi. The fundamental difference between on-chain games and GameFi is that the former is decentralized, permissionless, composable, and interoperable, while the latter merely mints key items in the game as tokens.
GameFi only puts game assets on-chain, while the computation and storage parts are on centralized off-chain servers. For example, well-known games like StepN and Axie Infinity, despite achieving great success, have limited gameplay and content, and are influenced by centralized project operations, allowing project parties to change game rules. GameFi also does not support UCG—players and developers cannot create in-game content and assets without permission, and other on-chain applications find it difficult to interoperate with it.
On-chain games are not just about putting game assets on-chain; the entire game also exists on the network in the form of contracts, with game state storage and logic execution fully on-chain, aligning with the fundamental attributes of decentralization, permissionlessness, and composability of blockchain. This means no entity can unilaterally change the game rules, putting the power of the game in the hands of players, and the concept of an "official" game will gradually disappear.
More importantly, players and developers can customize the front end based on open-source code, recreating in-game facilities and assets under basic rule constraints, unlocking the possibility of UCG—user-generated content. Moreover, any DApp that complies with the on-chain game contract rules can interoperate with it permissionlessly, expanding the composability of on-chain games to a larger ecological range. Not only can various chain games interoperate with each other, but chain games can also interoperate with DeFi, NFTs, and any DApp that may emerge in the future. This will break the business model of monopoly in Web2, providing developers and users with a better application experience and more imaginative creative opportunities.
Recommended projects Topology, Cartridge.gg, Briq, Lootrealms
Regarding contract wallets, they possess powerful programmable and composable features, enabling adaptation to new scenarios beyond DeFi, such as on-chain games and social applications. Recommended StarkNet contract wallets include Braavos and Argent; the former can turn a mobile phone into a hardware wallet, while the latter supports social recovery and will continue to update its features.
Regarding on-chain AI, StarkNet allows AI models to perform computations off-chain, generating proofs that can be verified by others to ensure computational integrity. Additionally, the STARK proof system has network effects, which can reduce the costs of AI models that require large-scale proof generation.
The application scope of on-chain AI includes: games, oracles, trading (automated yield), anti-witch hunting, KYC, data privacy, and AI model computing power mining, etc.
Q&A#
Q: What is the logic behind StarkNet transaction sorting? Will there also be MEV on Ethereum? Does the official sorter have MEV needs? Can it be done?
A: 1) StarkNet sorters sort based on gas priority; decentralized sorters will perform parallel execution afterward. Currently, more details about decentralized sorters have not been determined, and the sorting design is also not finalized; L2 transactions have order, but this order is not reflected in L1 as batch processing; 2) There will be MEV, but the consensus on the decentralization of sorters has not been determined yet. It may borrow mechanisms like Flashbots, PBS, etc.; 3) Currently, the centralized operation of the StarkNet sorter does not involve MEV, but theoretically, Rollups can do it.
Q: Where can I see L2 gas fees and speeds? Where can I see their final performance metrics?
A: Gas can be viewed at https://l2beat.com/scaling/tvl, and TPS can be viewed here https://ethtps.info/. Currently, the engineering progress of ZKR is slow, and large-scale adoption may not occur until mid-year. The current performance significance is not great, and the implementation of L3 may hinder TPS calculations.
Q: Why are many Ethereum projects deployed on Arbitrum?
A: Because it is OPR, development is faster; it was deployed two years ago, allowing for a longer development period.
Q: When will ZKR see an application explosion?
A: The application explosion can be divided into two categories: application migration and application innovation. The migration progress depends on the engineering cycles of different ZKRs, which may occur in Q3-Q4; in terms of application innovation, which high TPS, low unit yield applications can be realized on ZKR may explode at the end of the year, depending on various factors.
Q: What is the difference between OPR and ZKR?
A: OPR uses fraudulent proofs, while ZKR uses validity proofs, the latter being faster and cheaper. Vitalik has written articles explaining this.
https://vitalik.eth.limo/general/2021/01/05/rollup.html
Q: What contract wallets are immediately usable on StarkNet?
A: Braavos, Argent.
Q: What is the future of account abstraction?
A: Contract wallets based on account abstraction can be programmable; for example, they allow users to customize settings so that gas below a certain price will be automatically paid within a certain time; compared to EOA wallets, they are more adaptable to new scenarios beyond DeFi, such as on-chain games and social applications. It treats wallets as contracts, allowing wallets to achieve functionalities that contracts can implement.
Q: What projects on StarkNet are worth interacting with?
A: You can pay attention to the on-chain game MuMu developed by the Topology team, which will soon launch a new on-chain AI fighting game; for NFT projects, Briq is recommended, as the project team previously airdropped Christmas tree NFTs to users who purchased NFTs; also recommended is the Loot series game Lootrealms, which has issued tokens.
Q: Is StarkNet more suitable for on-chain AI and on-chain games?
A: Yes, because StarkNet uses the STARK proof system, its average verification time and proof size decrease as the proof scale increases, thus possessing network effects, a feature that SNARK does not have. This helps reduce costs and improve performance for on-chain AI and games. On the other hand, StarkNet's ecosystem has many infrastructures for financing and developing on-chain games, such as MatchBoxDAO, Volt Capital, Cartridge.gg, etc. The official team is also vigorously supporting the development of on-chain games, making StarkNet suitable for on-chain AI and on-chain games in terms of technology and resource support.
Q: Can StarkNet interface with other public chains?
A: The official claim is that it will not, only using Ethereum as the settlement layer; technically, it is possible.
Q: What are the drawbacks of account abstraction?
A: It is still relatively early, and the related tools and code are not mature enough, but as time progresses, account abstraction will become more mature. The advantage of account abstraction is that it makes transactions more programmable.
Q: What is the circuit of ZKR? Why is there a circuit?
A: It can be understood as the code of ZK; ZKR needs to generate proofs for the computation of the code. High-level language code needs to be compiled into bytecode and then transformed into ZK circuits to be used for generating ZK proofs.