StarkWare

Introduction

Introduction

Both StarkEx and StarkNet are projects developed by the StarkWare team. The former is similar to Iaas, analogous to the application chain. StarkWare helps large-scale projects develop proprietary application Rollup; the latter is Rollup that can deploy general-purpose applications.

StarkEx: Proprietary ZKR Engine

Introduction

Introduction

In the last year and the first half of this year, StarkWare created a scaling as a service (scaling as a service) business model by providing the scaling technology solution StarkEx, established an application-specific network, and served leading customers in the industry dYdX, Sorare, ImmutableX, DeversiFi, etc.

Overall structure

• The workflow includes the following four links

• Packaged transactions: Off-chain servers process client requests and combine multiple transactions into a "batch" for StarkEx to process.

• Confirm transaction and update status: The off-chain server confirms that the transaction is legal and updates the system status in compressed hash form.

• Generate a proof for the transaction: After completing the above process, SHARP will generate a STARK proof for the transaction to confirm the validity of the transaction. Proofs and updates are then sent to the on-chain Verifier smart contract to ensure transaction integrity.

On-Chain Verified Proofs: Once STARK proofs are verified, state updates are committed and settled 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 simultaneously provides proof generation services for multiple StarkEx clients/applications - generating proofs of computational integrity claims.

StarkWare Applications

Verifier is a smart contract deployed on Ethereum to verify the correctness of transactions from StarkEx.

The StarkEx application (Exchange in the picture) is a series of applications that support scalable and self-custodial trading, distinguishing between spot trading and leveraged trading. An application consists of two components, a smart contract and a backend.

• Standard procedure

• Users initiate transactions, transactions can directly interact with smart contracts

• Each transaction has a unique id, which together form a transaction flow, and the StarkEx application transmits the transaction flow to the backend

• The backend submits state transitions to SHARP, and SHARP generates proofs for state transitions

• SHARP submits the proof to the verifier contract and after the verifier completes the verification, the verifier records it in the Verifier Fact Registry, and then the backend will execute the state transition on the StarkEx smart contract.

The StarkEx smart contract checks whether the state transition conforms to the predefined rules to ensure the validity of the state transition (through the validator contract).

Reference link: Introduction :: StarkEx Documentation

high level overview

• As shown in the diagram below, the StarkEx system is designed to accept user transactions from partner backends. These transactions are then batched and processed by the StarkEx system. Combined with the introduction of smart contracts and backends above, the entire StarkEx transaction processing process and division of responsibilities are summarized as follows.

• On the front end, StarkEx clients support two types of operations, on-chain and off-chain. The former is a standard Ethereum transaction, and users directly deposit and withdraw through the StarkEx contract, while the latter is an operation performed through the StarkEx engine, such as dydx.

• Order validation, set up and validated by the StarkEx client's backend.

• Business logic, customize StarkEx contracts (sub-contracts) to support customer business logic

• Transaction flow, all transactions transmitted to StarkEx are verified and indexed using continuous identifiers called tx_ids, similar to nonces,

• The transaction sender, once the StarkEx gateway confirms that the transaction is correct, will guarantee to execute it (not really immediately), and will display it to the user in advance on the front end instead of waiting for the finalization 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 be executed, such as an empty list.

• Batch review. Any batch can be reviewed by the client before it is transmitted on the chain. If the transition is inconsistent with the expected state, the client can not approve or roll back.

Anti-censorship, if the customer reviews the user request, StarkEx allows the user to perform operations directly through the StarkEx contract, and the customer must provide it to the user within the specified time, otherwise the StarkEx contract will be frozen.

StarkNet: Universal ZKR

Introduction

Introduction

Unlike StarkEx, which customizes ZK Rollup for different applications, StarkNet is a general-purpose ZK Rollup, and developers can deploy applications on StarkNet.

basic introduction

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

On Ethereum, every time a transaction is submitted, all nodes need to check, verify and execute the transaction to ensure the correctness of the calculation, and broadcast the calculated state change in the network.

StarkNet only performs calculations off the chain and generates a ZK proof, then verifies the correctness of the proof on the chain, and finally packages multiple L2 transactions into one transaction on Ethereum. Therefore, the transaction costs incurred on StarkNet can be shared by other exchanges in the same packaging batch, just like carpooling (Pinduoduo), the more transactions, the lower the cost.

In addition, compared to Ethereum's method of allowing each node to fully execute transactions, StarkNet's method of generating ZK proofs for transactions can greatly improve network operation speed, reduce on-chain communication traffic, and increase network throughput. With higher TPS and lower Gas.

In short, the comparison of verifying the correctness of calculations is that the teacher needs to check whether the students have mastered the knowledge. The method of Ethereum is to check whether each classmate can recite the entire textbook, while the method of StarkNet is to let the students do the papers. The latter is more efficient and less expensive, but still guarantees safety.

EVM compatible

The StarkNet network itself is not compatible with EVM, and another set of ZK-friendly Cairo VM is designed.

StarkNet did not make ZK circuits for Ethereum opcodes like Hermez and Scroll, but made a set of more ZK-friendly assembly language, AIR (Algebraic Intermediate Representation) and high-level language Cairo.

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

StarkNet belongs to the type 4 level defined by Vitalik - language-compatible zkEVM (StarkNet strictly belongs to zkVM because of the customized virtual machine).

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

1. Warp: A translator that translates Solidity into Cairo language

Warp is a Solidity-Cairo translator that has been developed by the well-known Ethereum infrastructure team Nethermind. Warp can translate Solidity code to Cairo, but the translated Cairo program often needs to be modified and added with 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, which is currently deployed on Starknet (goerli testnet), and its bytecode is equivalent to EVM. Currently in beta. Ethereum applications can be ported to StarkNet by deploying to Kakarot.

• Kakarot can: (a) execute arbitrary EVM bytecode, (b) deploy EVM smart contracts as-is, (c) call functions (view and write methods) of EVM smart contracts deployed by Kakarot

Currently all opcodes of EVM are supported.

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

working principle

working principle

component

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

• StarkNet has five components. They are Prover (certifier), Sequencer (sorter) and full node on StarkNet; and verifier (Verifier) ​​and core state contract (StarkNet Core) deployed on Ethereum.

• When we initiate a transaction on StarkNet, an off-chain server—the sorter—will receive, sort, verify, and package them into blocks. Execute the transaction, and then send the state transition to the StarkNet Core contract;

• The prover will generate a proof for the transaction and send it to the verifier contract of Ethereum;

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. State transactions are sent as "calldata" (Blob after EIP-4844) to save L1 transaction gas. These "metadata" can be decrypted by StarkNet full nodes.

The full node basically performs the storage function. Full nodes store state changes, metadata, proofs, and records in StarkNet of all transactions that have been executed, and track the current global state of the system. When necessary, full nodes will decrypt "metadata" to reconstruct the history of StarkNet.

See StarkNet's Architecture Review by StarkNet development advocate @barretodavid. 【 1 】

Browser https://testnet.starkscan.co/, L2 dynamic block generation, Ethereum one-hour settlement

Account abstraction and transaction model

Different from the dual-account design of Ethereum EOA+CA, StarkNet realizes the abstraction of native accounts, and only one account design, drawing on the spirit of EIP 4337,

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

The following figure shows the transaction model,

• The native account abstraction opens the door for account programmability. StarkNet development advocate @barretodavid mentioned the idea of ​​implementing a mobile phone hard wallet on StarkNet.

• EOA on Ethereum only supports the signature scheme ECDSA on the Secp 256 k 1 elliptic curve

• Most smartphones do not support Ethereum's elliptic curves.

• Therefore, mobile wallets need to rely on software to sign transactions, and mobile wallets are therefore hot wallets.

StarkNet's native account abstraction supports multiple elliptic curves, and signature verification is highly programmable, so mobile wallets based on StarkNet/Cairo can be completely turned into hard wallets.

https://github.com/spartucus/nistp 256-cairo

Cairo already has an implementation of nistp 256 (for Smartphone Secure Enlave)

STARK

To put it simply, it is to directly call the encryption module of the mobile phone to "hard sign" the transaction.

There are currently many different proof systems (generating and verifying proofs), such as Halo, PLONK, Groth 16, Groth 09, Marlin, Plonky 2, etc., which all belong to the SNARK proof system. The proof system has a prover who generates proofs and a verifier who verifies the proofs. Different ZK projects almost all use different proof systems, and the STARK used by StarkNet belongs to a special SNARK in a sense.

STARK has more innovations than SNARK. It does not need to rely on "trusted settings" like SNARKs. It also comes with simpler cryptography assumptions, avoids the need for elliptic curve, pairing, and exponential knowledge assumptions, relies purely on hashing and information theory, and is therefore resistant to quantum attacks. Generally speaking, STARK is more secure than SNARK.

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

In terms of scalability, STARK is more scalable. Proof generation speed is linearly scalable, and verification time and proof size are logarithmically scalable. But the disadvantage is that the generated proof size is larger. But as the size of the proof increases, the cost of verification will decrease marginally - meaning that the larger the proof, the lower the total cost.

To sum up, compared with SNARK, STARK is more secure, and the average verification time and proof size will decrease as the verification scale increases. The disadvantage is that the initial proof size is larger, so it is more suitable for large-scale applications.

Detailed Expansion

Proof time scales linearly: The time spent by a prover scales approximately linearly with the number of hash calls.

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

At the security level of 80 bits, the execution time of the prover for every 12288 hash calls of STARK is 1 second, which is 12288 times/S; and every 98304 hash calls need 10 seconds, which is 9830 times/S. Therefore, we can It is known that the proof time of STARK and the hash call are basically approximately linear. As shown below

**Verification and Proof Size Logarithmic Scale: Verification time (and proof size) scales logarithmically with hashing calls. **As shown below:

As can be seen from the left figure, when the hash calls increase from 3072 to 49152, the verification time increases from 40 milliseconds to 60 milliseconds. And when the hash calls increased from 49152 to 786432, the verification time only increased from 60 ms to 80 ms. Proof of the same size. Therefore, we can know that the more hash calls, the shorter the average verification time, and the smaller the average proof size (calling hash to generate hash value/proof).

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

Recursive STARKs".

https://medium.com/starkware/recursive-starks-78 f 8 dd 401025 

In other words, a recursive STARK prover can generate a proof for a statement that the state of the system can be moved from a to a+1. Because the prover has verified a (recursive) proof of the computational integrity of a, and faithfully performed the computation of state a, the new state a+1 is reached. In short, you can understand that the process combines the two proofs a and a+1 into one proof**. As shown below:**

Cairo VM: verify calculation correctness

Cairo VM overview

Sometimes it also appears in the form of StarkNet OS/Cairo OS. It is a thing. Unlike EVM to perform calculations, Cairo VM itself only generates proofs for calculations and verifies correctness.

Cairo VM is a CPU VM using von Neumann architecture. Its programming language is also called Cairo. The Cairo language is based on Cairo assembly, so the compilation efficiency is very high. Cairo is an acronym for CPU Algebraic Intermediate Representation. The Cairo VM includes a single AIR to verify the instruction set of this "CPU".

Regarding how it works, it updates the L2 state of the system based on incoming transactions received. Facilitates the execution of (Cairo-based) StarkNet contracts. The operating system is based on Cairo and is essentially a program that uses the STARK proof system to prove and verify its output. Specific system operations and functions available to StarkNet contracts are available as calls to the operating system.

Cairo language overview

Cairo is StarkNet's smart contract language, based on STARK design, the Cairo program can generate STARK proofs.

A Cairo program is a collection of assembly codes, 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 will compile the Cairo code into Cairo assembly, and the Cairo assembler will use the assembly code to generate Cairo bytecode (which runs on the Cairo CPU) for execution on the Cairo VM. When it finally runs to It also needs to be compiled to opcodes and machine code (and instructions) on the real machine.

non-deterministic computation

The goal of the Cairo program is to verify that certain calculations are correct, so it is possible to take shortcuts compared to those deterministic calculations. It means that in order to prove a computation, the verifier can do some extra work that is not part of the computation.

For example, prove that the square root y of x = 961 is in the range 0, 1,…, 100. The straightforward approach is to write a complex code that starts at 961, computes its root, and verifies that this root is within the required range.

The pseudocode is as follows: guess the value of y (this is the non-deterministic part). Computes y 2 and ensures that its result is equal to x. Verify that y is in range. And, if we take the following calculation method. Y = SQRT(X) we can instead calculate as follows (non-deterministic calculation). Y*Y=X

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

This means that some Cairo programs (like the above) cannot be executed efficiently without some additional information. This information is provided by what we call hints. Hints are special instructions for Cairo Runner; used to solve non-deterministic problems where values ​​cannot be easily derived. In theory, hints can be written in any programming language. In the current Cairo implementation, hints are written in Python.

About deterministic and non-deterministic virtual machines, witness

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

Cairo here will actually involve the deterministic Cairo VM and the non-deterministic Cairo VM. The former is serious zkVM, proof and verification; the latter is used for non-deterministic computing.

An acceptable input of the Cairo deterministic VM constitutes the witness of the non-deterministic VM, and ZKP needs to use the witness as the input and output proof. (A witness for an NP statement is a piece of information that allows you to efficiently verify that the statement is true. For example, if it is stated that a Hamiltonian cycle exists in some graph, a witness is such a cycle. Given a cycle, one can efficiently check that Is it a valid Hamiltonian ring, but finding such a ring is difficult)

is a parallel state machine.

Memory model: read-only non-deterministic

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

And it is continuous, if empty it will be filled with any value.

ROM advantages include

Low cost, simpler circuit than RAM

permanent storage,

Cannot be tampered with, data cannot be modified and deleted

Built-in functions: reduce code compilation

https://medium.com/@pban/demystifying-cairo-white-paper-part-i-b 71976 ad 0108 

Developers can directly call built-in functions to reduce computing overhead and optimize the development experience without code conversion. Adding built-in functions does not affect CPU constraints. It just means that the same memory is shared between the CPU and the built-in functions as shown.

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

It is more flexible and can be infinitely close to the performance of AISC through software programming (so Cairo will do CPU?). Fork other virtual machines with Cairo.

boot load: load program from hash

• A program can write another program's bytecode into memory, point the Program Counter to that memory segment, and then run that program. A use case for bootloading from a hash is when a program called a bootloader computes and outputs the bytecode of another program, 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 advantages:

• Scalability, verification time, and program size show a logarithmic relationship, as mentioned in the STARK section.

Privacy, the verifier can verify that the program is executed correctly without knowing the computation.

Continuous memory: consecutive access to memory addresses

Cairo has a technical requirement that the memory addresses accessed by the program must be continuous. For example, if addresses 7 and 9 are accessed, then 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 these addresses with arbitrary values. In general, it is inefficient to have gaps like this because it means memory is being consumed when it is not being used. Introducing too many holes can make proof generation too expensive for an honest prover to perform. However, this still does not violate the soundness guarantee - no false proofs can be produced anyway.

Inventory of StarkNet ecology:

https://h 0 m 83 hhc 6 r.feishu.cn/docx/doxcnS 3 GGdXXc 1 PzKh 9 uTgTR 73 c

Full chain game

Full chain game

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/game 2 

Full-chain games—production efficiency + consumer experience transformation, basically, thinking (articles from various organizations and teams), practice (game projects on the chain and hackathons), funding (financing and grants), and most importantly There is a vibrant developer community.

Highly recommend the Topology team, Lootreamls.

Contract Wallet

• There are two ways to realize that the contract wallet becomes a hard wallet.

• The consensus layer supports mobile phone hardware. On the L2 of the original account abstraction such as StarkNet (programming language Cairo), it supports a variety of elliptic curves, instead of only supporting ECDSA (Secp 256 k 1 ) like Ethereum, so that the encryption chip/module of the mobile phone can directly sign the transaction (Most mobile phones do not support ECDSA). Therefore, on the L2 where the native account is abstracted, the contract wallet can sign transactions directly through hardware just like the hard wallet.

The wallet layer performs signature transcription. On a non-native account abstraction network like Ethereum, contract wallets can sign and transcribe. Like EIP-4337, you can customize the verification logic, and the user signs with the algorithm supported by the mobile phone hardware and then converts it to ECDSA supported by Ethereum.

• @barretodavid, the development advocate of StarkNet, mentioned the idea of ​​implementing a mobile phone hard wallet on StarkNet.

• EOA on Ethereum only supports the signature scheme ECDSA on the Secp 256 k 1 elliptic curve

• Most smartphones do not support Ethereum's elliptic curves.

• Therefore, mobile wallets need to rely on software to sign transactions, and mobile wallets are therefore hot wallets.

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

StarkNet's native account abstraction supports multiple elliptic curves, and signature verification is highly programmable, so mobile wallets based on StarkNet/Cairo can be completely turned into hard wallets.

Cairo already has a [nistp 256](

) (for Smartphone Secure Enlave) implementation.

The coupling of contract wallet + full-chain game opens up new scenarios other than wallet + DeFi. Argent, Cartridge.gg are doing it.

On-chain AI

Modulus Labs：https://www.moduluslabs.xyz/

Giza - Machine Learning in the Blockchain：

https://gizatech.xyz/

StarkNet decentralization : Kicking off the discussion

mirror.xyz：https://community.starknet.io/t/starknet-decentralization-kicking-off-the-discussion/711 

There are currently 2 machine learning projects, the ML platform Giza and the on-chain trading robot (Rockybot by ModulusLabs) StarkNet Chinese group has another one.

Applications include: games, oracles, transactions (automatic income), anti-witches, KYC, data privacy; AI model computing power mining.

thank you

thank you

This article was funded and authored by HackerDojo. Hacker Dōjo is an encryption and Web3 frontier technology open source knowledge community co-built by Hacker.

Thanks to creators Maxlion and HackerDojo.