API/RSS

Social

Starkware technology architecture and ecological application review

23-02-21 22:00

Read this article in 47 Minutes

AI summary

View the summary

原文标题：《 DAOrayaki ｜Starkware 技术架构与生态应用梳理》

Source: DoraFactory

StarkWare Introduction

StarkEx and StarkNet are both projects developed by the StarkWare team, the former is similar to Iaas, analog application chain, StarkWare helps large projects develop proprietary application Rollup; The latter is a Rollup for deployable generic applications.

To date, StarkWare (the team behind StarkNet) has raised $273 million in six rounds of funding. In particular, a recent funding round of $100 million quadrupled its valuation to $8 billion. As The most highly valued project in the L2 project, this Venter explores Starkware's technical architecture and ecological applications.

StarkEx: Proprietary ZKR engine

introduction

Last year and in the first half of this year, StarkWare created the scaling as a service business model with StarkEx, a scaling technology solution, building proprietary networks of applications, Service industry head customers dYdX, Sorare, ImmutableX, DeversiFi, etc.

Overall architecture

The workflow consists of the following four steps

Packaged transactions: The server down the chain processes customer requests, combining multiple transactions into a "batch" for StarkEx to process.

Confirm transaction and update status: The server down the chain confirms that the transaction is valid and updates the system status in the form of a compressed hash.

Generate Proof for Transaction: Upon completion of the above process, SHARP will generate STARK proof for the transaction to confirm the validity of the transaction. Proofs and updates are then sent to the Verifier smart contract on the chain to ensure the integrity of the transaction.

On-chain verification proof: Once STARK proof is verified, status updates are submitted and cleared back to the Ethereum mainnet. All transactions are processed and verified off-chain, while proof of their integrity is verified on-chain.

SHARP is a shared prover that provides proof-generation services -- proof-generation of computational integrity claims -- for multiple StarkEx clients/applications simultaneously.

Verifier is a smart contract deployed on Ethereum that verifies the correctness of transactions from StarkEx.

StarkWare Applications

The StarkEx application (Exchange pictured) is a family of applications that support extensible and self-managed trading, distinguishing between spot and leveraged trading. The application consists of two components, the smart contract and the back end.

Standard process

The user initiates the transaction, which can interact directly with the smart contract

Each transaction has a unique id that together makes up a transaction flow, which the StarkEx application transmits to the back end

The back end submits the state transitions to SHARP, which generates proofs for the state transitions

SHARP submits the certificate to the Verifier contract and after the verifier completes the verification, the verifier records it in the Verifier Fact Registry, and the back end performs the state transition on the StarkEx smart contract.

The StarkEx smart contract checks that the state transitions conform to predefined rules to ensure that the state transitions are valid (through the validator contract).

Reference link: Introduction :: StarkEx Documentation

Advanced overview

As shown in the figure below, the StarkEx system is designed to accept user transactions from the partner's back end. These transactions are then batched and processed by the StarkEx system. Combined with the previous smart contracts and backend, the entire StarkEx transaction process and division of responsibilities is outlined below.

On the front end, StarkEx customers support two types of operations, on-chain and off-chain. The former is a standard Ethereum transaction where users make deposits and withdrawals directly through StaarkEx contracts, while the latter is an operation performed through the StarkEx engine, such as dydx.

Order validation, which is set up and verified by the StarkEx customer's back end.

Business logic, customizing StarkEx contracts (subcontracts) to support customer business logic

Transaction flows, all transactions transmitted to StarkEx are validated and indexed using sequential identifiers called tx_ids, similar to nonce,

The transaction sender, once the StarkEx gateway confirms that the transaction is correct, promises to execute it (not really execute it immediately), and will be shown to the user in advance on the front end, rather than waiting for it to be finalized on the chain.

Error handling, if an invalid transaction is detected, the StarkEx system will report the error to the customer's professional endpoint, and the customer will replace the invalid transaction with another list of transactions to execute, such as an empty list, etc.

Batch audit, any batch can be reviewed by the customer before being transferred on the chain, and the customer can disapprove or roll back if the state transition is inconsistent with the expected.

Anti censorship, StarkEx allows users to perform actions directly through the StarkEx contract if the customer reviews the user request, the customer must provide it to the user within a specified time, or the StarkEx contract will be frozen.

StarkEx Partner Integration :: StarkEx Documentation

StarkNet: Universal ZKR

introduction

Unlike StarkEx, which customizes ZK Rollup for different applications, StarkNet is a universal ZK Rollup that developers can deploy applications on.

Basic introduction

On Ethereum, every transaction submitted requires all nodes to check, verify, and execute the transaction to ensure that the calculation is correct, and the calculated state changes are broadcast over the network.

https://ethereum.org/zh/developers/docs/evm/

StarkNet simply performs the calculation off-chain and generates a ZK proof, then verifies the proof on the chain, and finally bundles multiple L2 transactions into one transaction on Ethereum. Thus, transaction costs incurred on StarkNet can be shared equally among other transaction platforms in the same package batch, just like carpooling (Pinduoduo), where the more transactions, the lower the cost.

In addition, StarkNet's method of generating ZK proofs for transactions can greatly improve network speed, reduce on-chain traffic, and increase network throughput, so StarkNet has higher TPS and lower Gas compared to Ethereum's method of letting each node execute the transaction completely.

In short, the analogy of verifying the correctness of a calculation is that the teacher needs to check that the students have mastered the knowledge. While Ethereum's approach is to check if each student can recite the entire textbook, StarkNet's approach is to have students do the paper. The latter is more efficient and less costly, but still ensures safety.

EVM compatibility

The StarkNet network itself is not EVM-compatible, and a separate set of ZK-friendly Cairo VMS was designed.

Instead of building ZK circuits for Ethereum opcodes like Hermez and Scroll, StarkNet built its own, more ZK-friendly assembly language, AIR (algebraic intermediate representation), and a high-level language called Cairo.

StarkNet belongs to the type 4 level defined by Vitalik, which is language compatible with zkEVM (strictly speaking, StarkNet belongs to zkVM because VMS are customized).

https://vitalik.eth.limo/general/2022/08/04/zkevm.html

Although StarkNet itself is not compatible with EVM, StarkNet can still be compatible with Ethereum in other ways.

1. Warp: Translate Solidity into a translator for the Cairo language

Warp is a Solidity-Cairo translator that has been developed by Nethermind, a well-known Ethereum infrastructure team. Warp could translate Solidity code into Cairo, but the translated Cairo program often needed to modify and add Cairo features (such as calling built-in functions, optimizing memory, etc.) to maximize execution efficiency.

2. Kakarot: a zkEVM written in Cairo language

Kakarot is a smart contract written in Cairo that is currently deployed on Starknet (the goerli test network), with a 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, and (c) invoke functions (views and write methods) of EVM smart contracts deployed by Kakarot.

Kakarot is an EVM bytecode interpreter.

Currently, all EVM operation codes are supported.

https://github.com/sayajin-labs/kakarot

Working principle

component

StarkNet has five components. They are Prover (prover), Sequencer (sequencer) and full node on StarkNet. As well as verifiers and StarkNet Core contracts deployed on Ethereum.

https://david-barreto.com/starknets-architecture-review/#more-4602

When we initiate a transaction on StarkNet, an off-chain server -- the collator will receive, sort, validate, and package them into blocks. Execute the trade and send the state transition to the StarkNet Core contract;

The prover will generate proof for the transaction and send it to Ethereum's prover contract;

The verifier sends the verification result to the StarkNet Core contract on Ethereum and triggers a new set of Ethereum transactions from the StarkNet Core contract to update the global state on the chain for record keeping. Status transactions are sent as "calldata" (Blob after IP-4844) to save L1 transaction gas. This metadata can be decrypted by all StarkNet nodes.

All nodes provide basic storage functions. The full node stores state changes, metadata, proofs, and all transactions that have been executed recorded in StarkNet, and tracks the current global state of the system. When necessary, the full node will decrypt the "metadata" to reconstruct StarkNet's history.

Refer to StarkNet Developer Advocate StarkNet "s Architecture Review by @barretodavid.

Browser https://testnet.starkscan.co/, L2 & have spent Dynamic block, Ethereum one hour settlement

Account abstraction and transaction model

Unlike Ethereum EOA+CA's dual account design, StarkNet implements a native account abstraction with a single account design that draws on the spirit of EIP 4337,

Below is the trading model.

https://community.starknet.io/t/starknet-account-abstraction-model-part-1/781

Native account abstraction opens the door to account programmability. StarkNet developer @barretodavid mentioned the idea of implementing a hard wallet for mobile phones on StarkNet.

EOA on Ethereum only supports the signature scheme ECDSA on Secp256k1 elliptic curves

Most smartphones don't support Ethereum's elliptic curve.

So mobile wallet needs to rely on software to sign the transaction, mobile wallet is therefore hot wallet.

StarkNet's native account abstraction, support for a variety of elliptic curves, and highly programmable signature verification make StarkNet/Cairo based mobile wallets fully usable as hard wallets.

Cairo already has an implementation of nistp256 (Secure Enlave for smartphones)

https://github.com/spartucus/nistp256-cairo

In short, it calls the encryption module of the phone directly to "hard sign" the transaction.

STARK

There are many different proof systems (generating and verifying proofs), such as Halo, PLONK, Groth16, Groth09, Marlin, Plonky2, etc., which all belong to the SNARK proof system. The proof system has one prover generating proof and one verifier verifying proof. While different ZK projects almost always use different proof systems, the STARK used by StarkNet is in a sense a special kind of SNARK.

STARK has many more innovations than SNARK. It does not rely on "trusted Settings" as SNARK does. It also comes with simpler cryptographic assumptions, avoids the need for elliptic curves, pairing, and exponential knowledge assumptions, relies purely on hashing and information theory, and is therefore resistant to quantum attacks. STARK is generally safer than SNARK.

In terms of scalability, STARK is much more scalable. It is proved that the generation speed has linear scalability, and the verification time and proof size have logarithmic scalability. However, the disadvantage is that the size of the generated proof is larger. However, as the scale of proof increases, the cost of verification will decrease at a marginal rate -- meaning that the larger the proof, the lower the total cost.

https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/

In summary, STARK is more secure than SNARK. The average validation time and proof size will decrease as the scale of the validation increases. The downside is that the initial proof size is larger, making it more suitable for large-scale applications.

Expandability detail

Linear expansion of proof time: The time spent by the profier is approximately linear to the number of hash calls.

At the 80-bit security level, the prover execution time of STARK is 1 second per 12288 hash calls, which is 12288 hash calls per second. It takes 10 seconds per 98,304 hash calls, which is 9,830 hash calls per second. Therefore, we can see that STARK's proof time and hash calls are roughly linear. As shown in the picture below

https://eprint.iacr.org/2021/582.pdf

Verification and proof size Logarithmic scaling: The verification time (and proof size) presents a logarithmic relationship with the hash call. As shown in the picture below:

As you can see from the left figure, the validation time increases from 40 milliseconds to 60 milliseconds as the hash call increases from 3072 to 49152. When the hash call increased from 49152 to 786432, the validation time only increased from 60 milliseconds to 80 milliseconds. Prove the same thing for size. Therefore, we know that the more hash calls, the shorter the average validation time and the smaller the average proof size (calling the hash generates the hash value/proof).

Recursive proof

Any general, concise proof/argument of the knowledge system (STARKs in particular) can be used to verify the computation incrementally. This means that a calculation can produce a proof that proves the correctness of a previous instance of the calculation, a concept informally known as a "recursive proof combination" or "recursive STARKs".

In other words, a recursive STARK prover can generate a proof for a statement that the state of the system can move from A to a+1. Because the prover has already verified a (recursive) proof that confirms the computational integrity of a, and has faithfully performed the computation of state a, reaching the new state a+1. In short, you can understand that the procedure combines two proofs a and a+1 into one proof. As shown in the picture below:

https://medium.com/starkware/recursive-starks-78f8dd401025

Cairo VM: Verify that the calculations are correct

Overview of Cairo VM

Sometimes also seen in the StarkNet OS/Cairo OS fashion, is a thing that, unlike EVM, performs calculations, Cairo VM itself only generates proofs and verifies correctness for the calculations.

Cairo VM is a von Neumann CPU VM whose programming language is also called Cairo. Cairo language is based on Cairo assembly, so it is very efficient to compile. Cairo is an acronym for CPU Algebraic Intermediate Representation. Cairo VM contains a single AIR to validate this "CPU" instruction set.

In terms of how it works, it updates the L2 state of the system based on the transaction of the input received. Facilitate the execution of the (Cairo-based) StarkNet contract. The operating system is Cairo-based, essentially a program for proving and validating its output using the STARK Proof System. The specific system operations and functions available to the StarkNet contract are available as calls to the operating system.

Overview of Cairo language

Cairo is StarkNet's smart contract language. Based on a STARK design, Cairo programs 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 an Cairo program, the Cairo compiler compiles the Cairo code into an Cairo assembly, and the Cairo assembler takes the assembly code to generate the Cairo bytecode (which runs on the Cairo CPU) for execution on the Cairo VM. When it finally runs on a real machine, it needs to be compiled into opcodes and machine code (and instructions).

Nondeterministic computation

The goal of Cairo programs is to verify that certain calculations are correct, and thus take a shortcut over deterministic ones. It means that in order to prove a calculation, the verifier can do some additional work that is not part of the calculation.

For example, prove that the square root y of x=961 is 0,1... In the range of 100. The direct approach is to write complex code that starts with 961, calculates its root, and verifies that the root is within the required range.

The pseudo-code is as follows:

Guess the value of y (this is the uncertain part). Compute y2 and make sure it's equal to x. Verify that y is in the range.

And, if we take the following calculation method.

Y = SQRT(X)

We can instead calculate as follows (nondeterministic calculation).

Y*Y=X

As we can see, there are two possible solutions. +Y and -Y, and it's possible that only one of them will satisfy the rest of the instructions.

This means that some Cairo programs (like the one above) cannot be executed effectively without some additional information. This information is provided by what we call prompts. The prompt is a special instruction for the Cairo Runner; It is used to solve the nondeterministic problems whose values cannot be easily derived. In theory, prompts can be written in any programming language. In current Cairo implementations, the prompt is written in Python.

On Deterministic and nondeterministic virtual machines, witness

Cairo here also refers to deterministic and nondeterministic Cairo VMS. The former is the serious zkVM, proof and verification; The latter is used for nondeterministic computation.

an accepting input to the Cairo deterministic machine, that constitutes the witness to the nondeterministic machine.

An acceptable input to Cairo's deterministic VM forms the witness of the nondeterministic VM, which ZKP requires as input/output proof. The witness witness for an NP statement is a piece of information that allows you to effectively verify that the statement is true. For example, if it is declared that a Hamiltonian ring exists in a graph, the witness is such a ring. Given a ring, it is usefully possible to check whether it is a valid Hamiltonian ring, but finding such a ring is difficult)

Is a parallel state machine.

Memory model: read-only nondeterministic

Read-only nondeterministic memory, meaning that the value of each memory cell is selected by the prover, it cannot change over time (during Cairo program execution), and it is immutable. This instruction can only read from it. We can think of it as a write-once memory: you can write a value to a cell once, but you can't change it afterwards.

And it's continuous, and it's going to be filled in with arbitrary values if it's free.

ROM benefits include

Low cost, simpler circuit than RAM

Store forever,

Cannot be tampered with, data cannot be modified or deleted

Built-in functions: Reduce code compilation

Developers can reduce computing overhead and optimize the development experience by calling built-in functions directly, without the need for transcoding. Adding built-in functions does not affect CPU constraints. This simply means that the same memory is shared between the CPU and the built-in functions, as shown in the figure.

https://medium.com/@pban/demystifying-cairo-white-paper-part-i-b71976ad0108

The Cairo architecture does not specify a specific set of built-in functions. Built-in functions can be added or removed from AIR (algebraic intermediate representation) as needed.

CPU architecture: Flexible

More flexible, with unlimited access to AISC performance through software programming (so Cairo does CPU?) . Copy the other virtual machines in Cairo.

Boot load: Load the program from the hash

A Program can write another program bytecode to memory, have Program Counter point to that memory segment, and then run the program. One use case for loading from a hash boot is when a program called a boot loader computes and outputs the bytecode of another program, and then starts executing it as before. This way the verifier only needs to know the hash of the program and not the full bytecode. This has two benefits:

Scalability, verification time and application size are logarithmic, as mentioned in the STARK section.

Privacy, where the verifier can verify that the program is performing correctly without knowing the calculation.

Continuous memory: Access memory addresses continuously

Cairo has a technical requirement that the memory addresses the program accesses must be contiguous. For example, if addresses 7 and 9 are accessed, 8 must also be accessed before the program ends (the order of access does not matter). If there are small gaps in the address range, the prover will automatically fill in those addresses with arbitrary values. Usually, it is inefficient to have such gaps because it means memory is consumed when it is not being used. Introducing too many bugs may make the generation of proofs too expensive for honest proffers to perform. However, this still does not violate the warranty of reliability - it does not in any way result in a false proof.

StarkNet Ecology

StarkNet Ecology:

https://h0m83hhc6r.feishu.cn/docx/doxcnS3GGdXXc1PzKh9uTgTR73c

Full chain game

Full chain gaming -- productivity + consumer experience revolution, basically, there's thinking (articles from various organizations and teams), there's practice (on-chain game projects and hackathons), there's funding (funding and grants), and most importantly, there's a vibrant developer community.

Matchbox DAO: https://mirror.xyz/matchboxdao.eth

The Future of On-Chain Gaming:

https://volt.capital/blog/the-future-of-on-chain-gaming

Game 2.0:

https://www.guiltygyoza.xyz/2022/07/game2

The Topology team, Lootreamls, is recommended.

Contract wallet

There are two ways a contract wallet can become a hard wallet.

The consensus layer supports mobile hardware. On L2, a native account abstraction like StarkNet (the programming language Cairo), multiple elliptic curves are supported, rather than ECDSA (Secp256k1) as is supported on Ethereum, thus allowing the phone's encryption chip/module to sign the transaction directly (most phones do not support ECDSA). Thus, on L2, the native account abstraction, contract wallets can sign transactions directly through hardware just like hard wallets.

The wallet layer performs signature transcription. On networks like Ethereum that are not native account abstractions, contract wallets can be signed and transcribed. Like the IP-4337, you can customize the authentication logic, which the user signs with the algorithm supported by the phone hardware and then converts it to the ECDSA supported by Ethereum.

StarkNet developer advocate @barretodavid mentioned the idea of implementing a hard wallet for mobile phones on StarkNet.

EOA on Ethereum only supports the signature scheme ECDSA on Secp256k1 elliptic curves

Most smartphones don't support Ethereum's elliptic curve.

So mobile wallet needs to rely on software to sign the transaction, mobile wallet is therefore hot wallet.

StarkNet's native account abstraction, support for a variety of elliptic curves, and highly programmable signature verification make StarkNet/Cairo based mobile wallets fully usable as hard wallets.

https://twitter.com/barretodavid/status/1563584823884935168

Cairo already has a [nistp256]((Secure Enlave for smart phones).