Starknet называют ZK-rollup, но эта короткая формула скрывает почти всю интересную инженерию. Пользователь подписывает транзакцию аккаунт-контрактом, sequencer принимает её в mempool, Cairo-код исполняется в специальной VM, Starknet OS превращает изменение состояния в проверяемое вычисление, SHARP агрегирует STARK proofs, а Ethereum проверяет компактное доказательство и принимает новый proven state. STRK при этом уже оплачивает комиссии и участвует в staking, но децентрализация block production ещё проходит поэтапный rollout.
Starknet — validity rollup: Ethereum проверяет доказательство, а не переисполняет весь L2
Starknet — Layer 2 поверх Ethereum, использующий validity proofs. Смысл модели в том, что тысячи L2 операций можно выполнить вне Ethereum execution layer, а затем доказать корректность итогового state transition компактным криптографическим proof.
Ethereum не должен повторно исполнять каждую Cairo transaction. L1 verifier проверяет доказательство того, что вычисление было выполнено согласно правилам Starknet, после чего core contracts могут принять новый proven state.
Validity proof и optimistic dispute — разные модели
Optimistic rollup предполагает correctness и даёт challenge window для оспаривания. Starknet строится вокруг противоположной идеи: state update на L1 должен быть подтверждён validity proof. Поэтому canonical L1 settlement зависит от proof pipeline, а не от ожидания, что никто не предъявит fraud proof.
STARK не означает автоматическую приватность
STARK — криптографическая proof system. Она позволяет доказать корректность computation без повторного выполнения на Ethereum. Но сам факт использования STARK не делает публичные Starknet transfers невидимыми. Privacy требует отдельной design layer; validity и confidentiality — разные свойства.
Где именно находится экономия
Самая дорогая часть general-purpose execution переносится с Ethereum на L2. Ethereum получает агрегированный proof и data, необходимые для восстановления state, вместо полного набора вычислительных шагов каждого пользователя.
Cairo — язык и вычислительная модель, спроектированные вокруг provability
Starknet отличается от EVM-rollups не только proof system. Smart contracts пишутся на Cairo — языке, чья compilation/execution pipeline строилась с учётом того, что computation затем нужно эффективно доказать.
Для Cairo 1 типичный путь выглядит так: high-level Cairo source компилируется в Sierra, Sierra — в CASM, а CASM исполняется Cairo VM. Эта execution trace затем становится материалом для proof system.
Sierra — безопасный intermediate representation
Sierra расшифровывается как Safe Intermediate Representation. Она расположена между high-level Cairo и низкоуровневым Cairo Assembly. Один из её важных смыслов — сделать submitted program provable и дать protocol возможность корректно учитывать execution даже в случаях failure.
CASM — уровень, который реально исполняется
Sequencer компилирует Sierra class в CASM. CASM содержит инструкции Cairo VM, а execution меняет Starknet state через contracts, storage и syscalls.
Провал транзакции тоже должен быть воспроизводим
В proof-oriented VM недостаточно доказать только успешные happy paths. Protocol должен однозначно описывать validation, execution, revert и fee charging, иначе sequencer мог бы интерпретировать один и тот же input по-разному.
Sequencer: mempool, ordering и ранний L2 result
Пользовательская transaction сначала поступает full node, затем sequencer. Начиная с Starknet v0.14.0 sequencer использует mempool, а порядок arrival уже не обязан совпадать с order внутри block.
Sequencer выполняет preliminary validation, выбирает transactions, последовательно применяет их к state и формирует block. Transaction, которая прошла validation, но reverted во время execution, может быть включена в block как REVERTED.
CANDIDATE и PRE_CONFIRMED — ещё не L1 settlement
Современные Starknet statuses различают несколько стадий. RECEIVED означает, что sequencer получил transaction. CANDIDATE — она записана sequencer-ом как кандидат. PRE_CONFIRMED означает успешное execution sequencer-ом. ACCEPTED_ON_L2 означает inclusion в block, finalized текущим consensus protocol. ACCEPTED_ON_L1 появляется, когда Starknet state на Ethereum продвинулся минимум до соответствующей высоты.
Mempool позволяет fee escalation
Transaction с тем же nonce может заменить ожидающую, если tip и max L2 gas price увеличены согласно protocol rules. Это привычная для современного blockchain UX идея, но теперь она встроена в Starknet mempool вместо старого FIFO ordering.
Зелёный интерфейс после PRE_CONFIRMED и Ethereum-accepted state — разные уровни уверенности. Для обычного UX ранняя стадия удобна, для bridge/accounting критичен следующий уровень.
SNOS превращает Starknet block в вычисление, которое можно доказать
SNOS — Starknet Operating System — один из центральных компонентов архитектуры. Его задача не в том, чтобы быть обычной node OS. SNOS — Cairo program, который получает initial state и transactions, применяет protocol rules и выдаёт resulting state.
Это важная формализация: proof system умеет доказывать statement вида «конкретная Cairo program с конкретными inputs дала конкретные outputs». Поэтому утверждение «этот Starknet block корректен» нужно выразить именно как такое computation.
SNOS ограничивает свободу malicious sequencer
Sequencer технически может попытаться выполнить transaction не по правилам — например, пропустить обязательный validation step. Но тогда получившийся block не соответствует SNOS computation, и корректный proof для такого state transition не должен пройти Ethereum verifier.
Proof проверяет protocol semantics, а не намерения оператора
Это сильная сторона validity model: корректность закрепляется не репутацией sequencer, а доказуемым execution. Однако availability и censorship остаются отдельными вопросами — proof не заставляет operator своевременно включить вашу transaction.
SNOS является частью trusted software surface
Если specification или implementation proof program имеет bug, криптография честно докажет именно то statement, которое ей задали. Поэтому audits и открытая проверка SNOS важны не меньше prover mathematics.
SHARP и S-two: как множество blocks превращаются в один STARK proof
SHARP — shared proof aggregator StarkWare. Он принимает Cairo computations, валидирует jobs, группирует их, запускает prover и строит recursive proof tree. Для Starknet результат — возможность доказать несколько blocks и затем отправить на Ethereum только агрегированный proof.
Recursion снижает стоимость L1 verification
Вместо отдельной Ethereum verification transaction для каждого маленького computation SHARP может доказать proofs другими Cairo programs, затем агрегировать результаты снова. В корне proof tree остаётся statement, покрывающий множество исходных executions.
S-two заменяет Stone постепенно
С Starknet v0.14.0 SHARP использует S-two для большинства proofs, сохраняя Stone на recursive tree roots, чтобы не менять существующие Ethereum verifier contracts одномоментно. Это хороший пример production migration: новый prover внедряется без одновременной замены всего verification boundary.
STARK proof — это не compression алгоритм транзакций
Proof сжимает **доказательство корректности computation**, а не саму информацию о новом state. Чтобы любой участник мог восстановить L2 state, отдельно требуется data availability.
Data availability и Ethereum settlement: proof без state diff недостаточен
Starknet публикует на Ethereum compressed state diffs — изменения между старым и новым L2 state. Получая последовательность таких diffs, независимый observer может реконструировать актуальное состояние Starknet.
Начиная с v0.13.1 state diffs могут отправляться через EIP-4844 blobs; при экстремальной relative price sequencer способен переключиться на calldata. Более поздние версии добавили stateless и stateful compression.
Blob и proof решают разные задачи
Proof отвечает: **правильно ли вычислен новый state?** State diff отвечает: **какие данные нужны, чтобы этот state восстановить?** Без этого разделения легко ошибочно считать, что маленький STARK proof каким-то образом содержит весь balance/storage ledger.
ACCEPTED_ON_L1 означает продвижение Starknet state на Ethereum
После proof generation и verification L1 core contract принимает соответствующий state transition. Это более сильная finality boundary, чем ранняя sequencer confirmation.
Fee Starknet неизбежно содержит L1 component
Даже если Cairo execution очень дешёвое, публикация state diff и L2→L1 messages потребляет Ethereum blockspace/data gas. Поэтому стоимость Starknet transaction состоит из L2 computation/data и L1 data/message components.
| Слой | Что проверяется или оплачивается | Почему он нужен |
|---|---|---|
| Sequencer | Validation, ordering, execution | Быстрый L2 UX |
| SNOS | Правила state transition | Формализовать provable computation |
| SHARP/S-two | STARK proof | Сжать verification work |
| Ethereum verifier | Proof correctness | L1 settlement trust anchor |
| State diff/blob | Data availability | Восстановить L2 state |
STRK: fees, governance и staking — но utility менялась вместе с protocol
STRK — native token Starknet. Один из наиболее важных current-state нюансов: с релиза v0.14.0, активированного 1 сентября 2025 года, transaction fees в Starknet оплачиваются **только STRK**. Ранее сеть поддерживала ETH и STRK.
Sequencer получает fee в STRK; часть полученной суммы может быть конвертирована в ETH для покрытия L1 gas/data expenses, потому что Ethereum costs оплачиваются в ETH.
Fee состоит из трёх resource buckets
Current fee model учитывает L2 gas, L1 data gas и L1 gas. L2 gas покрывает computation/data внутри Starknet; L1 data gas — публикацию state diff; L1 gas — например L2→L1 messaging.
Fee burn сейчас отсутствует
Starknet Docs прямо указывает, что charged fees не сжигаются: их получает sequencer. Поэтому нельзя автоматически переносить EIP-1559 burn intuition из Ethereum на STRK.
Governance — отдельная utility STRK
STRK используется для protocol governance, включая approvals значимых upgrades. Это не означает, что каждый технический parameter ежедневно решается referendum, но token voting является частью официальной governance model.
Supply не фиксирован на 10 млрд навсегда
Initial/planned distribution начинается с 10 млрд STRK, но protocol предусматривает minting staking rewards. Поэтому max-supply intuition «ровно 10B навсегда» неверна; inflation parameters управляются protocol/governance rules.
Staking phase 2: validators уже attest blocks, но ещё не производят их
Самая важная оговорка для статьи 2026 года: Starknet staking live, но network decentralization rollout ещё не завершён. Официальная документация говорит, что protocol сейчас находится **во второй из четырёх фаз** и Starknet пока остаётся централизован в части core block-production responsibilities.
Validators уже обязаны запускать full node и attest назначенный block. Block proposing запланирован как следующая фаза responsibilities, а полный transfer sequencing/proving duties происходит дальше по roadmap.
Validator minimum сейчас 20 000 STRK
Current Mainnet staking parameters требуют минимум 20K STRK для direct validator participation. Delegators могут передавать STRK validator-у без выполнения operational responsibilities. Withdrawal security lockup сейчас составляет 7 дней.
Phase 2 проверяет operational reliability
Validator получает назначенный block и в attestation window отправляет transaction, содержащую его block hash. Это публично доказывает, что validator действительно отслеживает chain через full node.
BTC staking не превращает Starknet в Bitcoin consensus
С 2025 protocol допускает curated tokenized BTC wrappers в staking power. BTC имеет отдельный вес в формуле validator power. Это economic participation layer Starknet, а не перенос Bitcoin Proof-of-Work consensus внутрь L2.
STRK staking уже real protocol, но фраза «STRK validators полностью производят Starknet blocks» в 2026 году преждевременна. Нужно отделять сегодняшнюю phase 2 от roadmap phase 3/4.
StarkGate, messaging и explorer: как увидеть L1↔L2 lifecycle
StarkGate — официальный bridge suite StarkWare для ETH и ERC-20 между Ethereum и Starknet. Deposit начинается на L1: funds переводятся в bridge contract, emitted event создаёт message для L2, sequencer видит request и затем L2 handler mint-ит соответствующее representation.
Deposit становится сильнее по мере proof lifecycle
После L2 handler deposit может иметь ACCEPTED_ON_L2. Затем block должен быть proven, state update отправлен на Ethereum, и только после соответствующего L1 state transition появляется более сильная finality.
Withdrawal идёт в обратном направлении
L2 contract инициирует message to L1. После proof/settlement Ethereum-side bridge может подтвердить message и разблокировать funds согласно bridge rules. Поэтому withdrawal latency нельзя сравнивать только с Starknet block time.
Что смотреть в explorer
Для обычной transaction важно разделять execution status и finality status. Для bridge — ещё и L1 message/bridge transaction. Debug checklist выглядит так:
- Transaction hash и execution status на Starknet.
- PRE_CONFIRMED / ACCEPTED_ON_L2 / ACCEPTED_ON_L1.
- State update/proof progression.
- Для bridge — L1 deposit/withdraw event и message status.
- Exact token bridge contract: одинаковый ticker не заменяет contract identity.
Five-day deposit cancellation — аварийный path, а не обычная latency
StarkGate позволяет запросить отмену L1 deposit, если L2 funds долго не появились. Reclaim становится доступен примерно через пять дней после cancellation request. Это self-custody safety mechanism, а не ожидание обычного deposit.
Главный вывод
Starknet интересен тем, что scaling architecture начинается не с «ускорить EVM», а с provable computation. Cairo code проходит Sierra/CASM pipeline, sequencer формирует L2 blocks, SNOS превращает protocol rules в Cairo computation, SHARP и S-two строят recursive STARK proofs, Ethereum проверяет proof, а compressed state diffs обеспечивают data availability для реконструкции state.
STRK стал операционным token сети: с v0.14.0 им оплачиваются transaction fees, он участвует в governance и staking. Но staking нужно описывать по текущей фазе, а не по конечному roadmap: phase 2 validators attest blocks, тогда как полный decentralized block production ещё впереди.
Поэтому лучший способ анализировать Starknet — не спрашивать только «сколько TPS у ZK-rollup». Полезнее пройти цепочку: **какой code исполнился, какой state получил sequencer, что именно проверил SNOS, какой proof агрегировал SHARP, какие data попали в Ethereum и на какой стадии текущие staking validators реально влияют на network security.**
FAQ
Starknet — это ZK-rollup или validity rollup?
Оба термина часто используются, но технически validity rollup точнее подчёркивает ключевое свойство: Ethereum принимает L2 state на основании validity proof. Использование STARK не означает, что обычные transaction data автоматически приватны.
Что такое Cairo в Starknet?
Это язык и вычислительная экосистема для provable programs. Cairo 1 code компилируется в Sierra, затем в CASM, исполняется Cairo VM/Starknet OS и становится частью proof computation.
Кто сейчас создаёт Starknet blocks?
Core sequencing всё ещё находится в переходном централизованном состоянии. Staking protocol находится во второй фазе: validators attest blocks; block proposing относится к следующей фазе rollout.
Чем SNOS отличается от SHARP?
SNOS определяет и исполняет provable rules Starknet state transition. SHARP — proof aggregation infrastructure, которая строит и рекурсивно объединяет STARK proofs и отправляет итог на Ethereum verifier.
Чем сейчас оплачивается gas в Starknet?
С Starknet v0.14.0 transaction fees оплачиваются только в STRK. Sequencer при необходимости может конвертировать часть fee в ETH для L1 расходов.
Что означает ACCEPTED_ON_L1?
Это означает, что Starknet state, зарегистрированный на Ethereum, продвинулся до высоты, включающей transaction. Это более сильная settlement boundary, чем ранняя sequencer confirmation.
Материал носит образовательный характер и не является финансовой рекомендацией или торговым сигналом.