Follow StarkNet Astro ✨
Chinese Channel；English Channel
The content of the sharing session is too long, and this AMA summary has been heavily edited. 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-tier 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 customized ZKR enterprise service established by StarkWare for project parties. It can help projects customize proprietary ZKRs. Current clients using StarkEx include dYdX, Sorare, ImmutableX, DeversiFi, and others.
Unlike general ZKRs, in the customized ZKRs 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.
Working Principle#
The workflow of StarkEx is as follows:
-
Transaction Packaging: An off-chain server (often centralized by the project party) processes customer requests, combining multiple transactions into a "batch" for StarkEx to handle.
-
Transaction Confirmation and Status Update: The off-chain server confirms the legality of the transactions and updates the system status in a compressed hash form.
-
Generating Proof 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 that theoretically can increase TPS to over 2000 and reduce Gas to below 0.002.
Why does StarkNet have higher performance compared to Ethereum? First, let's review how Ethereum works. On Ethereum, every transaction submission requires all nodes to check, verify, and execute the transaction to ensure computational correctness and broadcast the computed state changes across the network.
In contrast, StarkNet 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 increase network operating speed, reduce on-chain communication volume, and increase network throughput, thus StarkNet has higher TPS and lower Gas compared to Ethereum.
In short, comparing the verification of computational correctness to a teacher checking 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, cheaper, and 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 the fourth type of zkEVM as mentioned by Vitalik, but is strictly a 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), and is 100% bytecode equivalent to EVM. It is currently in the testing phase. Ethereum applications can be ported to StarkNet by deploying them 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.
Working Principle#
StarkNet has five components: the Prover (prover), Sequencer (sorter), and full nodes on StarkNet; and 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 article “StarkNet's Architecture Review”.
Account Abstraction#
Unlike the dual account design of Ethereum 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, and the STARK used by StarkNet is, in a sense, a special kind 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 knowledge system's proof/argument (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, namely that the system's state can move 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, which will significantly reduce 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, making compilation very efficient. Cairo is an acronym for CPU Algebraic Intermediate Representation. Cairo VM includes a single AIR to verify this "CPU" instruction set.
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 its operation, it updates the system's L2 state based on the transactions received as input, facilitating the execution of Cairo contracts. Cairo VM is based on Cairo, and the specific system operations and functions available to 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 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. Instructions can only read from it. We can think of it as a one-time writable memory: 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 rather than 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) to execute in the Cairo VM. When it finally runs on a real machine, it still needs to be compiled into opcodes and machine code (and instructions).
Features of Cairo Language#
Startup Loading: Load Programs from Hash
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 that a program has executed correctly without knowing the computation.
Built-in Functions: Reduce Code Compilation
Developers can directly call built-in functions to reduce computational overhead and optimize the development experience without needing code conversion. 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 specific 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 not only put game assets on-chain; the entire game also exists on the network in the form of contracts. The storage of game state and execution of logic are entirely on-chain, aligning with the fundamental attributes of decentralization, permissionlessness, and composability of blockchain. This means no entity can unilaterally change game rules, and the initiative of the game lies in the hands of the players, gradually diminishing the concept of an "official" game.
More valuably, players and developers can customize the front end based on open-source code, recreating facilities and assets in the game 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 without permission, which will extend the composability of on-chain games to a larger ecosystem. This means that not only can various chain games interoperate with each other, but chain games can also interoperate with DeFi, NFTs, and any DApps that may emerge in the future, breaking the business model of monopoly in Web2 and 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, allowing them to adapt to new scenarios beyond DeFi, such as on-chain games and social interactions. Recommended StarkNet contract wallets include Braavos and Argent, with the former turning a mobile phone into a hardware wallet, and the latter supporting social recovery and continuously updating features.
As for on-chain AI, StarkNet allows AI models to execute computations off-chain, generating proofs that can be verified by others to ensure computational integrity. The STARK proof system has network effects, thus reducing 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, 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 demands? Can it do it?
A: 1) StarkNet sorters prioritize gas, and decentralized sorters will perform parallel execution; more details about decentralized sorters have not yet been determined, and sorting design is still undecided; L2 transactions have order, but this order does not manifest as batch processing on L1; 2) There will be MEV, but the consensus on decentralized sorters has not yet been determined; it may refer to mechanisms like Flashbots, PBS, etc.; 3) Currently, the centralized operation of sorters in StarkNet does not involve MEV, but theoretically, Rollups can do it.
Q: Where can I see L2 gas fees and speed? Where can I find their final performance metrics?
A: Gas can be viewed at https://l2beat.com/scaling/tvl, and TPS can be checked here https://ethtps.info/. Currently, the engineering progress of ZKR is relatively slow, and large-scale adoption may not occur until mid-year; thus, performance significance is limited, 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; regarding application innovation, those high TPS, low unit yield applications are more likely to be realized on ZKR, which may explode by 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 are 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 suitable for new scenarios beyond DeFi, such as on-chain games and social interactions. It treats wallets as contracts, enabling wallets to perform functions that contracts can achieve.
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, which 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 foundational infrastructures for financing and developing on-chain games, such as MatchBoxDAO, Volt Capital, Cartridge.gg, etc. The official support for the development of on-chain games is also strong, making StarkNet suitable for on-chain AI and on-chain games in terms of technology and resource support.
Q: Can StarkNet connect 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 computations of the code, and high-level language code needs to be compiled into bytecode and then transformed into ZK circuits to be used for generating ZK proofs.