StarkNet Airdrop Review: 9% of The Total Supply

About StarkNet Airdrop

StarkNet Airdrop is a permissionless decentralized Validity-Rollup (also known as a “ZK-Rollup”). It operates as an L2 network over Ethereum, enabling any dApp to achieve unlimited scale for its computation – without compromising Ethereum’s composability and security, thanks to StarkNet’s reliance on the safest and most scalable cryptographic proof system – STARK.

StarkNet has confirmed to launch an own token and 9% of the total supply has been allocated to end users and developers who’ve built dApps using StarkNet. StarkNet end users are those who used dApps built on StarkNet. StarkNet dApps include dydx, Immutable, Celer, DeversiFi, Argent and many more. So early users who’ve StarkNet Dapps by the snapshot date are likely to be eligible for the airdrop.

The pending block​

Today, StarkNet supports querying the new block before its construction is complete. This feature improves the responsiveness of the system prior to the decentralization phase, but will probably become obsolete once the system is decentralized, as full nodes will only propagate finalized blocks through the network.

During the construction of the block, as it is accumulating new transactions, the block’s status is PENDING. While PENDING, new transactions are dynamically added to the block. Once the sequencer decides to “close” the block, it becomes ACCEPTED_ON_L2 and its hash is computed.

Transaction structure

StarkNet, in its Alpha version, supports two types of transactions: a Deploy transaction and an Invoke Function transaction. They describe the available fields for both of these transaction types and how the transaction hash is calculated in both cases.

Fee Mechanism

In this section, we will review StarkNet Alpha 0.8.0 fee mechanism. If you want to skip the motivation and deep dive into the mechanism, you can skip directly to the final formula.

The only limitation on the sequencer (enforced by the StarkNet OS) is that the actual fee charged is bounded by max_fee, but for now, StarkWare’s sequencer will only charge the fee required to cover the proof cost (potentially less than the max fee).

Presently, the sequencer only takes into account L1 costs involving proof submission. There are two components affecting the L1 footprint of a transaction:

• computational complexity: the heavier the transaction, the larger its portion in the proof verification cost.
• on chain data: L1 calldata cost originating from data availability and L2→L1 messages.

Fee Units​

The fee is denominated in ETH (this may change in future versions). Each transaction is associated with a gas estimate (explained below), and combining this with the gas price yields the estimated fee.

How much fee is charged? High-level overview​

Computation​

Let’s analyze the correct metric for measuring transaction complexity. For simplicity, we will ignore Cairo’s builtins for the sake of the explanation, then see later how to refer to them.

Without builtins​

Recall that a Cairo program execution yields an execution trace. When proving a StarkNet block, they aggregate all the transactions appearing in that block to the execution trace.

StarkNet’s prover generates proofs for execution traces, up to some maximal length LL (Derived from the specs of the proving machine and the desired proof latency). Tracking the execution trace length associated with each transaction is simple.

Each assertion over field elements (such as verifying addition/multiplication over the field) requires the same, constant number of trace cells (this is where our “no-builtins” assumption kicks in!