Layer 1 в криптовалюте — это базовый уровень блокчейн-системы, на котором определяются собственные правила консенсуса, состояние сети, формат транзакций, порядок создания блоков, финальность, базовый актив для комиссий и правила независимой проверки. Когда говорят, что Bitcoin, Ethereum или Solana являются сетями первого уровня, имеют в виду не размер капитализации и не «главность» монеты, а то, что эти сети сами поддерживают собственный реестр и собственную безопасность, а не рассчитываются внутри другого блокчейна как обычные токены или приложения.
Самая частая ошибка — считать Layer 1 просто «основной сетью, а Layer 2 — более быстрой сетью». Такое объяснение слишком грубое. L1 — это прежде всего trust layer: набор правил, по которым независимые узлы решают, какие транзакции действительны, какое состояние является каноническим и какие данные нужно хранить или публиковать для проверки. L2, rollup, sidechain и appchain могут переносить часть исполнения в другой слой, но их связь с L1 и степень наследования безопасности различаются.
Вторая ошибка — считать любой coin Layer 1. Нативная монета действительно часто является экономическим активом L1, но сама монета и сеть — разные сущности. ETH существует как native asset Ethereum, однако Ethereum L1 включает гораздо больше: execution clients, consensus clients, EVM, state, peer-to-peer networking, validators, gas, data availability и правила обновления протокола. Аналогично SOL — нативный asset Solana, но Layer 1 — это вся система accounts, programs, transactions, validators и consensus.
Третья ошибка — сравнивать L1 только по transactions per second. Высокий throughput важен, но он достигается через конкретные trade-offs: требования к validator hardware, размер состояния, пропускную способность сети, способ исполнения, параллелизм, finality, data availability и степень распределения. Два L1 с одинаковым рекламным TPS могут давать совершенно разные гарантии и по-разному вести себя при congestion или сбоях.
Эта статья построена как технический, но прикладной разбор. Сначала определим, что именно делает сеть Layer 1. Затем разложим L1 на consensus, execution, state, networking, fees и native asset. После этого сравним Bitcoin, Ethereum и Solana как разные архитектурные подходы, отделим L1 от L2, rollup и sidechain и соберём практический чек-лист оценки новой L1-сети без маркетинговых обещаний.
Если базовые понятия ещё не закреплены, сначала полезно открыть материалы OneMagic о том, что такое блокчейн и что такое криптовалюта. Здесь мы будем использовать эти понятия уже как элементы архитектуры.
Layer 1 — не «первая монета» и не «самая крупная сеть». Это базовый протокол, который сам определяет валидность состояния, порядок блоков и экономические правила безопасности. Всё остальное нужно оценивать относительно того, какие гарантии этот базовый слой действительно даёт.
Что такое Layer 1 в криптовалюте простыми словами
Layer 1 — это базовый blockchain protocol
У L1 есть собственный ledger и собственные правила, по которым сеть принимает или отклоняет блоки и транзакции. Участники не обязаны спрашивать другой blockchain, считается ли их состояние действительным.
Именно эта самостоятельность отличает базовую сеть от token contract, rollup или приложения, которые опираются на чужой settlement или execution environment.
Сеть первого уровня имеет собственное каноническое состояние
State отвечает на вопрос, кому принадлежат активы, какие данные хранят contracts или accounts и какие изменения уже подтверждены. Nodes воспроизводят или проверяют переходы состояния по protocol rules.
Если независимые узлы не могут определить canonical state без доверия одному оператору, архитектура ближе к централизованной базе, чем к полноценному permissionless L1.
Consensus отвечает на вопрос, какую историю считать правильной
Узлы могут получать данные в разном порядке, а злоумышленник способен предлагать конфликтующие версии. Consensus определяет, как сеть выбирает допустимую последовательность блоков и достигает agreement.
Proof of Work и Proof of Stake — разные семейства решений этой задачи, а внутри каждого семейства существуют дополнительные fork-choice и finality-механизмы.
Execution отвечает на вопрос, что делает транзакция
Bitcoin проверяет UTXO и script-условия, Ethereum исполняет EVM bytecode, Solana выполняет instructions в programs над явно указанными accounts. Все три сети — L1, хотя execution model у них различается.
Следовательно, термин Layer 1 не подразумевает одну виртуальную машину или одну модель smart contracts.
Native coin связывает экономику с протоколом
Базовая монета обычно используется для transaction fees, validator/miner incentives, staking или других protocol-level функций. Она существует на уровне сети, а не как обычный token contract.
Но наличие native coin само по себе не делает систему Layer 1: важен собственный consensus и canonical ledger.
Nodes дают возможность независимой проверки
Полный node получает данные сети и проверяет их по правилам протокола. На актуальном Ethereum execution client исполняет транзакции и хранит state, а consensus client следит за PoS consensus и chain head.
Именно способность независимой проверки превращает блокчейн из доверия к интерфейсу в доверие к воспроизводимым правилам.
Layer 1 может поддерживать smart contracts, а может не быть универсальным
Ethereum и Solana проектировались как программируемые платформы общего назначения. Bitcoin сознательно использует более ограниченную модель scripting и UTXO.
Поэтому «есть ли EVM» нельзя использовать как критерий L1. L1 определяется базовым settlement/consensus layer, а не набором языков программирования.
Layer 1 может быть монолитным или более модульным
В классическом monolithic design consensus, execution и data availability тесно связаны в одном protocol. Современные roadmaps могут разделять функции сильнее, сохраняя L1 как базовый settlement/security layer.
Поэтому термин «монолитный» и термин «Layer 1» пересекаются, но не являются синонимами.
Mainnet и Layer 1 тоже не полные синонимы
Mainnet — рабочая основная сеть конкретного проекта в отличие от testnet. Если проект является L2, его production mainnet всё равно остаётся Layer 2 относительно базовой сети.
Следовательно, слово mainnet говорит о статусе окружения, а Layer 1 — об архитектурной роли.
Токен поверх L1 наследует инфраструктуру, но не становится L1
ERC-20 token использует Ethereum для ordering, execution и settlement contract operations. Сам token не имеет собственного validator set и canonical blockchain.
Это одно из главных различий между coin и token, которое полезно проверять перед покупкой нового актива.
| Компонент L1 | На какой вопрос отвечает | Пример функции |
|---|---|---|
| Consensus | Какая история каноническая? | PoW/PoS, fork choice, finality |
| Execution | Что делает транзакция? | UTXO scripts, EVM, programs |
| State | Каково текущее состояние? | Balances, UTXO, contract/account data |
| Networking | Как узлы обмениваются данными? | P2P gossip |
| Fees | Кто платит за ресурсы? | Gas/transaction fee |
| Native asset | Чем оплачивается базовая экономика? | BTC, ETH, SOL |
| Data availability | Есть ли данные для проверки? | Block data / blobs / ledger data |
Из чего состоит Layer 1: consensus, execution, state, data и сеть узлов
Consensus layer не исполняет бизнес-логику сам по себе
Consensus решает ordering и agreement, но конкретная архитектура может отделять его от execution. В Ethereum после The Merge node работает с execution client и consensus client как двумя связанными компонентами.
Это полезный пример: один L1 может внутренне состоять из нескольких программных слоёв и всё равно быть одним базовым blockchain.
Execution layer превращает транзакцию в изменение state
Transaction содержит подпись, параметры и instructions/data. Execution environment проверяет права, gas/resources и вычисляет новый state.
Если execution nondeterministic, разные nodes получили бы разные результаты. Поэтому детерминированная или строго определённая обработка критична.
State model влияет на параллелизм и UX
Ethereum account model хранит world state и contract storage. Solana явно передаёт accounts, которые program читает или изменяет, что помогает планировать параллельное исполнение непересекающихся операций.
Bitcoin UTXO model вместо общего account balance работает с отдельными outputs, которые могут быть потрачены при выполнении условий.
Data availability нужна для независимой проверки
Если участник получает только claim «состояние стало таким», но не имеет данных, необходимых для проверки перехода, trust assumption растёт. Ethereum.org отдельно подчёркивает data availability как возможность получить данные, необходимые для самостоятельной проверки.
На L1 full nodes обычно получают block data напрямую, тогда как rollups используют отдельные механизмы публикации compressed data или proofs.
Peer-to-peer networking распространяет транзакции и блоки
Node должен обнаруживать peers, принимать messages, отбрасывать invalid data и распространять полезную информацию дальше. Это сетевой слой, который часто незаметен пользователю.
Высокий throughput без достаточной network bandwidth может создать centralization pressure на validators/nodes.
Mempool не обязателен в одинаковой форме для всех L1
Многие сети имеют очередь неподтверждённых транзакций, но правила forwarding, scheduling и block production отличаются. Ethereum execution clients gossip pending transactions по execution P2P network.
В Solana transaction отправляется RPC/forwarding path к текущему или будущему block producer и использует recent blockhash; архитектура не идентична EVM-mempool.
Block producer и verifier — разные роли
Участник, предложивший block, выбирает или упорядочивает transactions в рамках protocol constraints. Остальные nodes/validators должны проверить, что block не нарушает правила.
Децентрализация состоит не только в количестве producers, но и в возможности independent verification.
Finality отвечает, когда история становится достаточно устойчивой
В некоторых designs блоки имеют probabilistic finality: вероятность reorganization уменьшается с confirmations. В других применяется explicit finality через validator votes.
Пользовательский термин «подтверждено» поэтому имеет разный технический смысл в разных L1.
Fork choice решает, что делать при конкурирующих ветках
Если сеть видит несколько допустимых candidates, protocol должен определить head. Bitcoin использует накопленную proof-of-work логику, PoS systems — stake-weighted voting/finality variants.
Fork-choice rule — одна из центральных частей security model.
Client diversity снижает зависимость от одной реализации
Если protocol имеет несколько независимых client implementations, одна software bug реже превращается в единый отказ всей сети. Ethereum прямо рассматривает client diversity как фактор resilience.
Но diversity усложняет testing: все клиенты должны одинаково интерпретировать consensus specification.
RPC не является самим blockchain
Wallet обычно общается с L1 через RPC provider. Provider может ошибаться, ограничивать requests или иметь outage, но это не обязательно означает остановку сети.
Для критических систем собственный node или несколько независимых providers уменьшают dependency.
Explorer тоже является интерфейсом к данным
Block explorer удобен для чтения transactions и contracts, но не создаёт canonical truth. Источник истины — protocol state, который explorer индексирует.
Это важно при сбоях: отсутствие transaction в одном интерфейсе ещё не доказывает, что сеть её не видит.
Storage/state growth создаёт долгосрочную стоимость
Чем больше permanent state и historical data, тем выше требования к инфраструктуре nodes. Protocols используют pruning, state rent, archival separation и другие подходы.
Scaling therefore involves not only TPS but also long-term verification cost.
Data throughput и execution throughput — разные ограничения
Сеть может быстро исполнять вычисления, но испытывать ограничение по network data, либо наоборот. Rollup-centric designs особенно подчёркивают data availability capacity.
Одно число TPS скрывает, какой именно ресурс является bottleneck.
L1 security зависит от economics и software одновременно
Consensus incentives защищают от экономических атак, cryptography — от подделки подписей, client code — от программных ошибок, P2P — от сетевых проблем.
Нельзя оценивать L1 только по market cap native coin или только по количеству validators.
| Слой | Риск при слабой реализации | Что смотреть |
|---|---|---|
| Consensus | Reorg / capture | Stake/hash distribution, finality |
| Execution | Invalid state / bugs | VM/spec/client diversity |
| Networking | Censorship / partitions | Peer distribution, bandwidth |
| State | Высокие требования к nodes | State growth, pruning |
| Data availability | Невозможность проверить состояние | On-chain data guarantees |
| RPC layer | Centralized access outages | Provider diversity |
| Governance/upgrades | Protocol capture | Process, timelocks, client adoption |
Bitcoin, Ethereum и Solana как три разных подхода к Layer 1
Bitcoin: денежный L1 с UTXO и Proof of Work
Bitcoin строит базовый ledger вокруг UTXO, digital signatures и Proof of Work. Основная задача — устойчивое peer-to-peer владение и transfer BTC при минимизации trust.
Execution deliberately limited compared with general-purpose smart-contract platforms, что уменьшает surface сложной on-chain logic, но ограничивает универсальные приложения.
Bitcoin finality в основном вероятностная
По мере добавления новых блоков поверх transaction стоимость реорганизации истории растёт. Пользователь выбирает число confirmations в зависимости от риска и стоимости операции.
Нет отдельного PoS-finality vote, который делает блок математически окончательным в том же смысле, что некоторые BFT-like systems.
Bitcoin block space — дефицитный базовый ресурс
Transactions конкурируют за ограниченное пространство блока через fee market. Это сохраняет простую economic модель base layer, но throughput ограничен.
Scaling поэтому включает дополнительные layers и payment-channel approaches, а не только увеличение L1 computation.
Ethereum: programmable L1 с EVM
Ethereum поддерживает general-purpose smart contracts. Execution client принимает и исполняет transactions в EVM, хранит state и предоставляет RPC interface.
Это делает L1 платформой для токенов, DeFi, NFT и других applications, но увеличивает сложность execution/state.
Ethereum после The Merge разделяет execution и consensus clients
Актуальная документация ethereum.org описывает node как связку execution client и consensus client. Validator добавляется к consensus side для block proposals и attestations.
Архитектурное разделение не означает, что Ethereum стал L2: обе части совместно образуют Ethereum L1 protocol.
Ethereum gas является рынком вычислительных ресурсов
Каждая operation имеет gas cost, а user задаёт fee parameters. Gas ограничивает resource usage и защищает сеть от бесконечных вычислений.
Нативный ETH выполняет protocol-level функцию оплаты ресурсов и staking economics.
Ethereum L1 всё сильнее работает как settlement и data layer для rollups
Rollups исполняют transactions вне L1, а затем публикуют data/proofs или commitments обратно. Ethereum L1 предоставляет settlement, consensus и data availability guarantees в соответствии с конкретной rollup design.
Это пример эволюции L1: базовый слой может масштабировать ecosystem через L2, не пытаясь исполнить каждую user action напрямую.
Solana: account/program architecture и высокий параллелизм
Solana хранит state в accounts, а programs работают над accounts, переданными instruction. Transactions могут содержать несколько instructions.
Явное объявление account dependencies помогает runtime планировать параллельную обработку операций, которые не конфликтуют по state.
Solana использует Proof of Stake consensus и Proof of History как clock/order mechanism
Официальные материалы Solana описывают stake-weighted validator votes как основу consensus. Proof of History создаёт криптографически проверяемую последовательность времени и порядка; сама PoH не является отдельным anti-Sybil consensus.
Это важное уточнение: формула «Solana работает на Proof of History вместо PoS» слишком упрощённая.
Solana transaction lifecycle отличается от Ethereum
Transaction содержит recent blockhash и list accounts/instructions; RPC forwards её к block producer, а validators process ledger and vote.
Поэтому привычные термины nonce, mempool и gas нельзя переносить между L1 без адаптации к protocol.
Три L1 решают похожие базовые задачи разными способами
Все три должны определить valid transaction, canonical history, state ownership и economic security. Но data model, execution, consensus and finality differ.
Именно trade-offs, а не тикер native coin, формируют пользовательские свойства сети.
Нельзя выбрать «лучший L1» одной метрикой
Bitcoin optimizes monetary robustness and conservative protocol change, Ethereum — programmable settlement ecosystem, Solana — high-performance programmable execution with different hardware/network assumptions.
Сравнение должно начинаться с use case: платежи, smart contracts, settlement, high-frequency applications или security requirements.
| Параметр | Bitcoin | Ethereum | Solana |
|---|---|---|---|
| State model | UTXO | Account/world state | Accounts + programs |
| Consensus | Proof of Work | Proof of Stake | Stake-weighted PoS + PoH clock |
| General smart contracts | Ограниченно | EVM | Programs/SVM |
| Native asset | BTC | ETH | SOL |
| Primary fee resource | Block-space fee | Gas | Transaction/compute fees |
| Scaling emphasis | Additional layers/channels | Rollup-centric L2 | High L1 execution + ecosystem layers |
Native coin, gas и экономика безопасности Layer 1
Native coin существует внутри protocol, а не token contract
BTC, ETH и SOL являются базовыми assets своих networks. Их ownership и transfer обрабатываются protocol-level rules.
Token поверх L1 может копировать symbol или экономическую функцию, но он не становится native asset.
Fees защищают scarce resources
Block space, compute, storage writes и bandwidth конечны. Fee market помогает распределять доступ к этим ресурсам и уменьшать spam.
Слишком низкие fees улучшают UX, но protocol должен иметь другой механизм защиты от resource abuse.
PoW security budget включает subsidy и fees
Miner получает newly issued block subsidy и transaction fees. По мере изменения subsidy роль fees в long-term security economics становится важнее.
Price native coin affects miner revenue in external currency, но consensus rules не зависят от одного exchange quote.
PoS security budget связан с staked capital
Validators lock/stake native asset или получают delegated stake; misbehavior может наказываться в зависимости от protocol. Rewards compensate participation and capital risk.
Но номинальное число validators менее важно, чем distribution of effective stake and operational independence.
Inflation может финансировать security
Many PoS L1 issue new native coins to validators/stakers. Это dilution для non-participants, если issuance не offset by demand/burn.
Поэтому staking yield нужно сравнивать с monetary issuance, а не воспринимать как бесплатный доход.
Burn может компенсировать issuance
Ethereum показывает модель, где validator issuance увеличивает supply, а base-fee burn уменьшает. Net supply зависит от активности сети.
Но deflationary period не гарантирует growth price: supply и demand остаются разными сторонами.
Fee token utility создаёт базовый demand, но не floor
Если native asset нужен для transactions, users должны иметь некоторое количество coin. Однако высокая utility не гарантирует определённую рыночную цену.
Market valuation depends on demand, supply, expectations and liquidity.
Validator economics влияет на decentralization
Высокие hardware requirements, bandwidth and stake capital могут ограничивать число независимых operators. Низкие требования расширяют доступ, но могут ограничивать performance.
Сравнивайте cost of participation, а не только headline validator count.
Delegation меняет распределение voting power
Тысячи stakers могут делегировать нескольким крупнейшим validators, поэтому operator count и stake concentration дают разные картины.
Для PoS L1 important metric — stake-weighted distribution.
Fee predictability важна для applications
Сильные spikes делают network expensive for users and dapps. Protocol designs пытаются стабилизировать fee markets через base fees, priority fees, local fee markets or capacity changes.
Средняя fee без tail distribution не показывает worst-case UX.
Low fees могут быть субсидированы inflation
Если validator rewards mostly come from new issuance, user pays little directly, but holders collectively finance security via dilution.
Total economic cost should combine fees and monetary policy.
Native asset collateral use adds reflexivity
Если native coin widely used as collateral, падение price может создавать liquidations and pressure, while same asset secures network through stake.
Это не обязательно weakness, но требует stress analysis.
Economic security is not equal to market cap
Attack cost depends on hash/stake distribution, liquidity, borrowability, slashing and protocol response. Market cap only provides scale context.
Security claims should avoid simplistic ‘market cap = security budget’.
Fork/social layer remains part of extreme recovery
Even deterministic rules are executed by software and communities choose client versions/upgrades. Extreme incidents can trigger coordinated recovery decisions.
Therefore L1 governance includes both formal code and social coordination.
| Экономический поток | Кому/куда | Влияние |
|---|---|---|
| Transaction fee | Block producer / protocol / burn | Оплата resources |
| PoW subsidy | Miner | Issuance + security |
| PoS issuance | Validator/staker | Issuance + security |
| Base-fee burn | Уничтожение units | Снижение supply |
| Slashing | Protocol-dependent | Наказание misbehavior |
| Delegation commission | Validator/operator | Оплата operations |
Layer 1 и Layer 2: settlement, rollup, sidechain и appchain — не одно и то же
Layer 2 использует L1 как часть своей модели доверия
Настоящий L2 обычно не пытается полностью заменить базовую сеть. Он переносит часть execution или aggregation в отдельный слой, а затем опирается на L1 для settlement, data availability, proofs или dispute resolution — в зависимости от архитектуры.
Поэтому вопрос «какой L2 быстрее» вторичен. Сначала нужно понять, какие именно гарантии он наследует от L1 и какие остаются у sequencer, bridge, prover или governance.
Rollup агрегирует много операций в меньший L1 footprint
Rollup исполняет пользовательские транзакции вне базового execution path и публикует compressed data, state commitments и/или proofs на L1. Это уменьшает стоимость одной пользовательской операции относительно direct L1 execution.
Однако rollup не существует в вакууме: final settlement, data publication and escape mechanisms связывают его с base layer.
Optimistic rollup и ZK rollup проверяют состояние по-разному
Optimistic design предполагает корректность state transition и даёт окно challenge/fraud proof. ZK rollup публикует validity proof, подтверждающий вычисление по заданным правилам.
Оба подхода могут использовать Ethereum L1 как settlement/data layer, но latency, proof cost, withdrawal mechanics and operational assumptions differ.
Sidechain имеет собственную security model
Sidechain может быть связана bridge-ом с Ethereum или другой L1, но её consensus не обязан наследовать безопасность базовой сети. Если sidechain validator set скомпрометирован, L1 не обязательно способен отменить её состояние.
Поэтому sidechain нельзя автоматически называть Layer 2 только потому, что она совместима с EVM или использует bridge.
Validium переносит data availability вне L1
Validity proofs могут подтверждать корректность state transitions, но если data хранится вне L1, user recovery depends on external availability assumptions.
Это пример того, почему security analysis должен разделять validity и data availability.
Appchain — специализированная цепочка для одного приложения или экосистемы
Appchain может иметь собственный validator set и native economic model либо использовать shared security framework. Архитектурно она не обязана быть L2.
Преимущество — контроль над execution environment и resource allocation; цена — необходимость отдельно решать security, liquidity and interoperability.
Rollup sequencer не равен L1 validator
Sequencer упорядочивает L2 transactions, но final authority зависит от rollup design. L1 validators/nodes проверяют L1 rules and published commitments/proofs.
Если sequencer временно недоступен, зрелая rollup architecture должна иметь путь forced inclusion, escape or recovery — конкретные механизмы нужно проверять.
Bridge — самая важная граница между слоями для пользователя
Перемещение asset между L1 и L2 обычно означает lock/mint, burn/mint или escrow-accounting. Ошибка bridge или неправильная сеть создаёт risk независимо от качества underlying L1.
Поэтому user safety требует понимать, где находится canonical asset и какой contract контролирует representation.
L2 token не обязательно нужен для безопасности L2
Некоторые L2 имеют governance or utility token, но settlement/security могут опираться на native asset базовой сети. Token economics и technical security model — отдельные вопросы.
Не путайте наличие собственного ticker с превращением L2 в самостоятельный L1.
L1 gas и L2 fee — разные компоненты стоимости
Rollup user fee может включать local execution, data posting to L1, proving/settlement overhead and sequencer margin. В периоды высокой L1 data cost итоговая L2 fee тоже меняется.
Поэтому дешёвая L2 transaction не означает, что базовая сеть перестала быть экономически значимой.
L1 congestion способен влиять на L2 finality/cost
Если rollup публикует data/proofs на Ethereum, высокая стоимость или congestion L1 может задерживать batching и увеличивать fees.
Scaling layers therefore remain connected through settlement and data markets.
L2 failure не всегда означает потерю funds
Сильная rollup design предполагает, что users могут восстановить state или вывести assets через L1 even if operator disappears, при выполнении specific assumptions.
Но наличие такого escape hatch нужно проверять по contracts and governance, а не по marketing phrase ‘inherits Ethereum security’.
L1 upgrade может влиять на весь L2 ecosystem
Изменение data format, gas rules or protocol limits меняет economics connected rollups. EIP-4844 показал, что L1 upgrade can reduce rollup data cost through blob space.
Это демонстрирует системную роль Layer 1: базовый protocol defines capabilities higher layers use.
Не всякая быстрая сеть — L2
Если chain имеет independent consensus, own validator set and final settlement not enforced by another blockchain, она closer to L1/sidechain/appchain despite marketing name.
Classify by trust and settlement, not by brand or interface.
| Архитектура | Собственный consensus | Где settlement | Data availability | Ключевой риск |
|---|---|---|---|---|
| L1 | Да | На своей сети | На своей сети/по protocol | Consensus/state security |
| Rollup L2 | Sequencer может быть отдельным, но settlement наследуется | На L1 | Часто L1/blobs | Sequencer/proof/bridge/governance |
| Sidechain | Да | На sidechain | На sidechain | Validator-set security |
| Validium | L2-like execution/proof | Часто L1 proof | Вне L1 | Data availability |
| Appchain | Зависит от framework | На своей/shared security | Зависит | Bootstrap security/liquidity |
Масштабирование Layer 1: TPS, latency, finality и цена децентрализации
TPS — только одна координата производительности
Transactions per second полезны, если методика одинакова: что считается transaction, какой тип операции, какой размер payload, sustained или burst load. Без этого TPS легко становится маркетинговой цифрой.
Сравнивайте real application workload, block fullness and fee behaviour, а не лабораторный максимум.
Latency — время до первого наблюдаемого включения
Пользователь ощущает UX через время от отправки до включения/confirmation. Быстрая block production улучшает responsiveness, но сама по себе не означает сильную finality.
Нужно разделять inclusion latency и economic finality.
Finality — время до приемлемого риска reorg
Одна сеть может показывать transaction через секунду, но считать её окончательной позже. Другая имеет explicit BFT-like finality after votes.
Wallet UX должен объяснять level commitment rather than показывать одно слово ‘confirmed’.
Block size/capacity увеличивает throughput и hardware pressure
Если block содержит больше data/compute, validators/nodes должны быстрее принимать, хранить и проверять её. Это повышает bandwidth, disk and CPU requirements.
Слишком aggressive capacity может сократить число участников, способных independently verify chain.
Parallel execution повышает utilisation hardware
Если transactions затрагивают независимое state, runtime может исполнять их параллельно. Solana account model explicitly exposes account access, helping scheduler avoid conflicts.
Но high parallelism не помогает, если популярные transactions все изменяют один hot account or contract.
State contention создаёт локальные bottlenecks
Даже high-throughput L1 может замедляться around popular application, если операции конкурируют за один resource or account.
Average TPS hides local congestion experienced by specific dapp.
Local fee markets уменьшают contagion congestion
Некоторые designs позволяют перегруженному resource платить больше, не повышая fee для всей сети одинаково.
Это улучшает isolation, но делает fee model сложнее for users.
Data compression не отменяет verification cost
Можно уменьшать transaction representation, signatures or state proofs, но nodes всё равно должны доверенно reconstruct/verify state according to protocol.
Optimization must preserve deterministic validation.
Hardware acceleration is a trade-off, not automatically centralization
Высокие hardware requirements могут быть приемлемы, если sufficient independent operators economically participate. Но cost and specialist infrastructure raise barriers to entry.
Сравнение требует реальных validator economics, not ideological labels.
Decentralization has multiple dimensions
Node count, stake/hash distribution, geographic distribution, client diversity, hosting concentration and governance all matter.
Один показатель cannot capture censorship resistance.
Throughput per validator is not throughput per user
Network may process high raw operations, but application-level success depends on fees, failure rates, priority competition and state conflicts.
User metrics should include success probability and time-to-finality.
Benchmark tests can ignore adversarial conditions
Lab throughput often assumes healthy peers, ideal packet delivery and predefined workload. Mainnet faces spam, forks, outages and skewed demand.
Operational history is as important as architecture paper.
Fee spikes reveal scarce resource under stress
When demand exceeds capacity, fee market exposes bottleneck. Analyse which resource: compute, bytes, state writes or data availability.
Different bottlenecks require different scaling solutions.
Sharding is one family of scaling approaches
Network can partition data, execution or validator responsibilities across shards while preserving some shared security/communication.
Implementation complexity is high; modern Ethereum roadmap emphasizes data sharding-like capacity for rollups rather than classical independent execution shards.
Rollup-centric scaling changes what L1 optimises
Instead of maximizing direct user transactions on L1, base layer can prioritise secure settlement and cheap data availability for many L2s.
This is architectural choice, not admission that L1 ‘failed’.
Vertical versus horizontal scaling
Faster hardware raises capacity per node; more parallel lanes/shards/layers distribute work. Both have coordination and verification trade-offs.
Strong roadmap often combines multiple approaches.
State expiry/pruning attacks long-term cost
Historical data and world state grow indefinitely unless protocol/client provides pruning, expiry or archival separation.
Scalability must be sustainable over years, not only one benchmark day.
MEV affects effective user throughput
Ordering competition can cause failed transactions, duplicated bids or priority fees even when nominal block capacity exists.
Performance analysis should include execution quality, not just count successful block entries.
Network outages reveal hidden coupling
High-performance systems depend on networking, leader scheduling, client software and resource limits. Incident history shows which assumptions fail under stress.
Resilience metrics belong next to TPS.
The trilemma is a heuristic, not a physical law
Blockchain trilemma frames tension among decentralization, security and scalability, but real designs operate on a continuum with many dimensions.
Use it as question generator, not as proof that any project must sacrifice exactly one property.
| Метрика | Что измеряет | Чего не показывает |
|---|---|---|
| TPS | Количество операций/с | Finality, decentralization |
| Block time | Частоту блоков | Economic finality |
| Time to finality | Стабильность history | Throughput |
| Average fee | Среднюю стоимость | Tail spikes |
| Node requirements | Cost verification | Stake concentration |
| Validator count | Число operators | Independence/stake weights |
| State size | Накопленное состояние | Bandwidth at peak |
| Uptime | Operational reliability | Security against capture |
Безопасность Layer 1: validators, nodes, client diversity и governance
Validator count without weights can mislead
In PoS one validator can control large stake or one operator can run many validators. Number of validator keys is not number of independent decision makers.
Measure effective stake by entity/operator, concentration and delegation.
Hashrate also needs distribution context
Bitcoin security depends on total computational work and pool distribution. Mining pools coordinate block construction but miners can theoretically switch pools, so pool share and ownership are not identical.
Security analysis should distinguish hash coordination from hardware ownership.
Client diversity reduces correlated software failure
If most validators/nodes use one client, a bug in that implementation can affect a large share of network simultaneously.
Ethereum explicitly encourages multiple execution and consensus clients to reduce single-codebase risk.
Consensus specification is more important than one implementation
Multiple clients must agree on the same rules. Ambiguous specification can create chain splits if implementations interpret edge case differently.
Formal test suites and cross-client testing are core L1 infrastructure.
Slashing changes validator incentives
PoS protocol can penalize provably dangerous behaviour such as conflicting attestations, depending on specific rules.
Slashing is not universal cure: censorship, downtime and governance capture require separate analysis.
Economic finality depends on cost of violating rules
If attack requires sacrificing large staked value, rational attacker faces high economic cost. But borrowed stake, derivatives, correlated custody and social response complicate simple calculation.
Quoted ‘billions securing network’ is only starting point.
Full nodes constrain validators
Even if validators propose blocks, full nodes verify protocol validity. Invalid block should be rejected by honest clients.
This separation limits producer power: block producer chooses among valid possibilities, not arbitrary state.
Censorship resistance differs from validity
Validator may include only selected valid transactions without creating invalid state. Network can remain consensus-correct yet censor users.
Measure proposer concentration, inclusion lists/alternate paths and ability to switch providers.
Geographic and hosting concentration create correlated outage risk
Validators spread across many keys but hosted in one cloud region are not operationally independent.
Resilience analysis should consider ASNs, cloud providers and jurisdiction.
Governance may be off-chain, on-chain or hybrid
Bitcoin changes via software adoption and social coordination. Some PoS networks use formal governance votes. Ethereum changes through EIP process, client implementation and community coordination.
No model is automatically decentralized; ask who can propose, veto, implement and refuse upgrade.
Upgrade keys create hidden centralization
Some young L1 or bridges have emergency multisig capable of changing protocol or pausing functions. This may improve incident response but expands trust assumptions.
Document key holders, threshold and timelock.
Hard fork is not necessarily a failure
Protocol upgrade can intentionally change consensus rules when community adopts new software. Accidental incompatible fork is different.
Understand social coordination behind network identity.
Bug bounty and audit do not replace adversarial history
Code review reduces known risk, but long-running public network has been tested under load and economic attacks in ways audit cannot replicate.
Operational maturity is one factor among many.
Validator profitability affects long-term security
If rewards do not cover hardware, bandwidth, capital opportunity cost and operational overhead, independent validators may exit.
Security economics must be sustainable across market cycles.
Native coin concentration can feed consensus concentration
In PoS, large token holders can delegate or operate substantial voting stake. Distribution matters more directly than in PoW.
Check staking concentration separately from circulating token holders.
Liquid staking introduces additional concentration channels
Users can delegate through liquid-staking protocols, concentrating stake under a few operators or governance systems while economic ownership remains broad.
Monitor protocol-level stake shares and operator distribution.
Restaking/shared security can create correlated risk
If same economic stake secures multiple systems, failure or slashing event can propagate. Shared security improves capital efficiency but increases dependency graph.
Analyse base L1 and external security services separately.
Social recovery is ultimate layer in extreme PoS attacks
Ethereum documentation notes social coordination by full nodes as potential response to attacks overwhelming crypto-economic defenses.
This shows blockchains combine automated consensus with human choice in extraordinary cases.
Security is weakest at the boundary users actually touch
Even if L1 consensus is strong, wallet, RPC, bridge or smart contract can fail. User risk often sits above base layer.
Do not claim ‘secure L1’ means every asset/application on it is secure.
| Security dimension | Проверка | Красный флаг |
|---|---|---|
| Consensus concentration | Stake/hash by entity | Few dominant operators |
| Client diversity | Share by implementation | Single-client dominance |
| Hosting diversity | Cloud/ASN/geography | One provider/region |
| Governance | Upgrade process | Single admin key |
| Finality | Reorg/finality rules | Unclear guarantees |
| Node accessibility | Hardware/bandwidth | Extreme barriers |
| Economic sustainability | Fees/rewards/costs | Persistent validator losses |
Как оценивать новую Layer 1 сеть перед использованием или покупкой native coin
Шаг 1. Докажите, что это действительно L1
Найдите mainnet, genesis, validator/node documentation and independent state verification. Если project лишь token on Ethereum, это не L1.
Marketing words ‘ecosystem’ or ‘chain’ insufficient.
Шаг 2. Опишите consensus одним абзацем
Кто proposes blocks, кто votes/verifies, что определяет fork choice, когда finality считается достигнутой?
Если ответ невозможно получить из официальной документации, transparency слабая.
Шаг 3. Проверьте node and validator requirements
Сколько hardware, bandwidth, stake and operational knowledge нужно для independent participation?
Сравните advertised decentralization with practical entry barrier.
Шаг 4. Определите execution model
UTXO, EVM, SVM, WASM or custom runtime — не просто бренды. Они определяют state access, smart-contract model, tooling and security assumptions.
Compatibility can simplify development but inherit common attack surface.
Шаг 5. Разберите fee model
Что платит user: base fee, priority fee, compute units, bytes, storage? Что происходит при congestion?
Средняя low fee без stress history малоинформативна.
Шаг 6. Поймите monetary policy native coin
Genesis allocation, current supply, issuance, staking/mining rewards, burn, treasury and unlocks.
Native coin utility as gas/security does not remove dilution risk.
Шаг 7. Оцените stake/hash concentration
Raw number validators insufficient. Use stake-weighted or hash-weighted distribution and entity labels where possible.
One operator with many validator keys remains concentrated.
Шаг 8. Проверьте client diversity
Есть ли несколько independent implementations? Как распределена доля network? Кто поддерживает codebase?
Single implementation creates correlated bug risk.
Шаг 9. Посмотрите incident history
Outages, reorgs, consensus bugs, emergency restarts and network halts reveal actual resilience.
Strong response process matters, but repeated identical failure pattern is concern.
Шаг 10. Разберите governance and upgrade path
Who can change protocol, emergency parameters or validators? Is there timelock? How are client releases adopted?
Hidden multisig can dominate nominally decentralized system.
Шаг 11. Проверяйте data availability
Can independent nodes obtain all data required to verify state? If architecture uses external DA, who stores and guarantees it?
Unavailable data can make valid proof insufficient for user recovery.
Шаг 12. Оцените state growth
Fast chain may generate enormous data. Can typical node keep up over years? Are pruning/archive modes documented?
Unsustainable history growth centralizes verification.
Шаг 13. Проверьте ecosystem bridges
Where do users acquire wrapped assets? Which bridge is canonical? Who controls mint/lock? What happens if bridge pauses?
Strong L1 cannot protect a badly designed bridge representation.
Шаг 14. Сравните actual dapp demand
Are blocks used by independent applications or mostly incentives/test activity? Organic fee-paying demand matters for economic sustainability.
High TPS with artificially generated traffic says little.
Шаг 15. Separate network value from native coin valuation
A technically excellent L1 can have overpriced coin; mediocre valuation can coexist with strong protocol.
Investment decision requires supply, liquidity and demand beyond architecture.
Шаг 16. Stress-test congestion
What happens when popular app saturates resource? Do fees spike globally, locally, or do transactions fail?
Stress behaviour reveals practical scaling model.
Шаг 17. Stress-test validator exit
If native coin price falls 70%, can operators cover costs? Does stake/hash centralize toward subsidized players?
Bear-market economics tests decentralization.
Шаг 18. Stress-test governance conflict
If controversial upgrade splits community, what determines canonical chain? Are applications/bridges prepared for fork?
Social coordination is part of real protocol risk.
Шаг 19. Verify rather than trust dashboards
Node count, TPS and validator stats from explorers are useful but may use different definitions.
Cross-check methodology and time window.
Шаг 20. Keep a decision log
Write why this L1 is suitable for your use case, which metrics would invalidate thesis and what dependencies exist.
Without kill criteria technical research easily becomes narrative.
- Подтвердить статус L1 и наличие собственного consensus.
- Записать consensus, finality и fork-choice model.
- Проверить execution/state architecture.
- Проверить node/validator hardware and stake requirements.
- Оценить validator/hash and client concentration.
- Разобрать fees under normal and congested conditions.
- Проверить native coin issuance, burn, treasury and unlock.
- Оценить data availability and state-growth strategy.
- Проверить governance, emergency keys and upgrade process.
- Посмотреть incident history and recovery procedure.
- Отделить bridge/application risk от base-layer risk.
- Сравнить technical quality с valuation native coin отдельно.
Практические сценарии Layer 1: как читать сеть без маркетинговых ярлыков
Сценарий 1. L1 обещает 100 000 TPS
Сначала выясните workload, hardware, block size, success rate and whether figure is sustained mainnet throughput. Затем проверьте state growth и validator requirements.
Если benchmark требует datacenter hardware and ideal load, сравнение с consumer-node network некорректно.
Сценарий 2. Сеть имеет 3000 validators
Посмотрите stake concentration and operators. Если top 5 entities control majority effective stake, raw count overstated decentralization.
Validator keys and independent governance entities are not same.
Сценарий 3. Сеть дешёвая, но inflation высокая
Low user fees могут финансироваться через native coin issuance. Holders indirectly subsidize security via dilution.
Compare total economic cost: fees + inflation minus burn.
Сценарий 4. Сеть дорогая, но fees high because demand
High fees can indicate scarce blockspace and strong usage, not necessarily broken design. But UX may force users to L2.
Evaluate whether roadmap expands capacity without sacrificing verification.
Сценарий 5. L1 compatible with EVM
EVM compatibility lowers developer migration cost, but does not mean same consensus/security as Ethereum.
Separate execution compatibility from settlement security.
Сценарий 6. New chain calls itself Ethereum L2 but has own validators
If Ethereum only bridges assets and cannot enforce state validity, architecture may be sidechain rather than true rollup.
Check settlement contracts and proof mechanism.
Сценарий 7. Rollup has centralized sequencer
Central sequencer can create censorship/outage risk while state validity still anchored to L1.
Check forced inclusion and escape hatch before saying security is fully inherited.
Сценарий 8. L1 stopped producing blocks for one hour
Classify cause: consensus failure, network partition, client bug, resource exhaustion or operator coordination. Then inspect recovery: automatic or social/manual restart.
Incident type matters more than uptime percentage alone.
Сценарий 9. One client bug affects 60% validators
Even decentralized stake is exposed to correlated software risk if implementation concentration high.
Client diversity is real security metric.
Сценарий 10. Native coin price falls sharply
Validator economics weaken, but network may remain secure if rewards, costs and stake distribution still support participation.
Price drawdown alone does not equal protocol failure.
Сценарий 11. Native coin supply inflates 8% annually
Ask who receives issuance, what percentage is staked, how burn works and whether demand grows.
Inflation percentage alone does not determine price.
Сценарий 12. Burn exceeds issuance
Net supply falls, but network can still have weak demand. Deflationary tokenomics is not technical security or valuation guarantee.
Keep supply and usage separate.
Сценарий 13. RPC provider outage
Wallet cannot load balances, but independent nodes continue producing blocks. User-facing outage is infrastructure issue.
Distinguish RPC availability from consensus availability.
Сценарий 14. Explorer shows missing transaction
Check another explorer or direct RPC/node. Indexer lag can differ from chain state.
Explorer is representation, not consensus source.
Сценарий 15. Bridge hacked, L1 keeps running
Base consensus may be secure while wrapped assets become undercollateralized.
Do not call whole L1 hacked if compromise is bridge-level.
Сценарий 16. Smart contract exploit drains dapp
L1 executed valid contract logic according to deployed code. Application security failed.
Base-layer and application-layer blame must be separated.
Сценарий 17. Hot NFT mint congests one resource
Global or local fee response reveals architecture. In account-based parallel systems, shared account contention can still bottleneck.
Real usage tests scheduler assumptions.
Сценарий 18. Governance changes fee rules
Token economics can change without consensus failure. Analyse who approved and how clients adopted change.
Protocol governance is ongoing risk.
Сценарий 19. Emergency multisig pauses bridge
Funds may be protected, but trust in key holders rises. Emergency control is trade-off.
Check threshold and transparency.
Сценарий 20. Validator set geographically concentrated
Network appears decentralized by count but exposed to jurisdiction/power/network events.
Geographic and infrastructure independence matters.
Сценарий 21. High-performance L1 requires 256 GB RAM
High hardware cost may still support hundreds/thousands professional validators, but home verification barrier higher.
Judge trade-off against use case and operator diversity.
Сценарий 22. Low-resource L1 processes fewer transactions
Lower throughput can be deliberate choice to maximize accessibility and conservative verification.
Performance goals differ across systems.
Сценарий 23. L2 fee cheaper than L1
Difference may come from batching and data compression, not weaker transaction semantics necessarily.
Check proof and DA model.
Сценарий 24. Sidechain calls itself scaling solution
It can improve throughput but carries own validator security. Scaling category and L2 security inheritance are separate.
Use technical definition.
Сценарий 25. Data availability moves off-chain
Proof can guarantee state transition validity, but users may not reconstruct balances if data withheld.
DA assumption must be explicit.
Сценарий 26. L1 uses shared security framework
Appchain may rent stake/security from base ecosystem rather than bootstrap own validators.
Determine which layer slashes/settles and where canonical state lives.
Сценарий 27. Chain has fast finality but validators concentrated
Fast BFT-like voting improves UX while censorship/capture risk may be higher.
Finality speed and decentralization are independent dimensions.
Сценарий 28. Chain has slow finality but broad verification
Longer confirmation can be acceptable for high-value settlement if security assumptions stronger.
Use case defines acceptable latency.
Сценарий 29. Native asset not required for user fees
Some designs abstract fees or accept multiple tokens while underlying protocol still uses native asset for security.
Fee UX and security asset can differ.
Сценарий 30. Account abstraction hides native gas
Application sponsor pays gas, so user sees ‘free transaction’. Resource cost still exists and someone funds it.
UX abstraction does not remove L1 economics.
Сценарий 31. L1 launches token before mainnet
Token may exist on another chain as placeholder. Until native mainnet and migration, asset is not proof that functioning L1 exists.
Verify genesis/mainnet and bridge plan.
Сценарий 32. Mainnet exists but validators permissioned
Technically it can be L1, but trust model is more centralized/permissioned.
Layer number does not guarantee decentralization.
Сценарий 33. Protocol claims ‘no downtime’
Check incident definitions, partial outages, RPC failures and failed transaction rates. Marketing uptime can exclude degraded service.
Use independent operational history.
Сценарий 34. Chain reorgs several blocks
Probabilistic-finality systems can reorganize within expected range. Deep/frequent reorgs beyond design assumptions are more concerning.
Know normal confirmation policy.
Сценарий 35. One validator misses blocks
Network can remain healthy if others continue. Resilience depends on redundancy and quorum rules.
Single operator failure is not network failure.
Сценарий 36. More validators join but top stake concentration rises
Raw decentralization count improves, economic voting distribution worsens.
Track both metrics.
Сценарий 37. Client diversity rises but one hosting provider dominates
Software risk improves, infrastructure correlation remains.
Decentralization is multidimensional.
Сценарий 38. Network usage grows but native coin price falls
Protocol adoption and valuation can diverge due supply, expectations or value capture.
Do not infer technical failure from price alone.
Сценарий 39. Native coin rallies while usage falls
Speculative demand can outrun fundamentals temporarily.
Investment thesis and network health require separate dashboards.
Сценарий 40. L1 ecosystem grows mainly through L2
Direct L1 transactions may plateau while settlement/data demand increases.
Measure base-layer role rather than only direct user count.
Итог: что на самом деле означает сильный Layer 1
Сильный Layer 1 — это не сеть с максимальным TPS и не монета с самой высокой ценой. Это базовый protocol, который позволяет независимым участникам проверять состояние, устойчиво достигает consensus, имеет понятную finality, управляет scarce resources через прозрачную fee model и сохраняет приемлемые требования к nodes/validators. Performance имеет смысл только вместе с security и verification cost.
Bitcoin, Ethereum и Solana показывают, что L1 может решать одну и ту же базовую задачу разными архитектурными путями. Bitcoin делает акцент на UTXO, Proof of Work и conservative monetary settlement. Ethereum сочетает EVM execution с PoS consensus и всё активнее служит settlement/data layer для rollups. Solana строит высокопроизводительную account/program architecture со stake-weighted consensus и Proof of History как cryptographic clock. Различия — это design choices, а не шкала от «старого» к «новому».
Для пользователя важнее всего правильно определить границу доверия. Если актив является token на Ethereum, его безопасность включает contract risk поверх Ethereum L1. Если asset перемещён в rollup, добавляются sequencer, bridge and proof assumptions. Если он находится в sidechain, security может зависеть от отдельного validator set. Слово Layer 1 полезно только тогда, когда вы понимаете, какую именно часть системы оно описывает.
Перед использованием новой сети или покупкой её native coin отделяйте protocol quality от investment valuation. Хороший L1 способен иметь переоценённый token, а низкая цена coin не делает architecture слабой или сильной. Проверяйте consensus, client diversity, validator economics, fees, data availability, governance, incident history, token issuance и liquidity отдельно.
Для продолжения используйте OneMagic о блокчейне, о стейкинге и валидаторах, о ликвидности и об устройстве крипторынка. Эти материалы позволяют перейти от архитектуры сети к экономике конкретного asset и оценить риск уже не по ярлыку L1, а по проверяемым параметрам.
Практикум: как читать TPS без маркетинга
Предположим, L1 заявляет 50 000 TPS. Сначала найдите, что именно считается транзакцией: простые transfers, vote transactions, failed operations, внутренние instructions или user-facing state transitions. Затем выясните, это теоретический peak, short benchmark или sustained mainnet load.
После этого сравните success rate, median fee, p95 latency и hardware requirements. Только связка этих показателей показывает, получил ли пользователь реальную производительность или лишь высокий laboratory counter.
Практикум: как читать validator count
Сеть показывает 5000 validator keys. Это выглядит децентрализованно, но stake распределён неравномерно: крупные operators контролируют большую долю effective voting power. Поэтому raw count нужно дополнять Nakamoto-like concentration, top-entity share и delegation structure.
Если одна organisation запускает сотни validator instances, технически ключей много, а operational independence низкая. Считать keys и считать independent entities — разные задачи.
Практикум: как читать node count
Node crawler видит несколько тысяч узлов, но не способен гарантированно обнаружить каждый peer. Разные сервисы дают разные значения из-за methodology, NAT, network topology и временной доступности.
Используйте node count как приблизительный health indicator, а не как точную перепись. Важнее, насколько легко обычный оператор может запустить validating node и насколько разнообразны clients и hosting.
Практикум: как оценить client diversity
Соберите доли execution/consensus client implementations. Если один client доминирует, bug в его consensus-critical logic может затронуть значительную часть network одновременно.
Высокая diversity полезна только при действительно независимых codebases и teams. Fork одного codebase с минимальными изменениями даёт меньше resilience, чем отдельные реализации specification.
Практикум: как оценить hardware barrier
Запишите CPU, RAM, storage, bandwidth и стоимость стабильной инфраструктуры для full node и validator. Затем сравните эти требования с reward economics и typical operator resources.
Высокие требования не автоматически означают централизацию, но повышают входной барьер. Если participation экономически доступна только datacenter operators, social and geographic diversity может снижаться.
Практикум: как проверять finality
Найдите официальный definition finalized/confirmed block и количество времени/голосов, необходимых для него. Затем отдельно посмотрите historical reorgs or finality incidents.
Wallet label ‘final’ должен соответствовать protocol-level guarantee, а не удобному UI термину. Для high-value transfer используйте уровень подтверждения, соответствующий actual security model.
Практикум: как анализировать congestion
Возьмите период максимальной нагрузки и сравните success rate, fee distribution, inclusion latency and block fullness с обычным периодом. Это показывает настоящий bottleneck.
Если сеть сохраняет low fees, но failed transactions резко растут, congestion просто проявляется другой метрикой. Дешёвая неуспешная transaction не является хорошим UX.
Практикум: как анализировать fee model
Разложите user fee на base component, priority component, compute/data component и возможный storage cost. Затем определите, кому направляется каждый поток: validator, treasury, burn.
Так становится видно, как сеть распределяет scarce resources и кто финансирует security. Average fee без destination и congestion behaviour малоинформативна.
Практикум: как оценить inflation native coin
Сравните annual issuance, burn, staking participation и treasury emissions. Затем посчитайте net supply change и отдельно circulating dilution.
Если stakers получают 7%, а network issuance 6%, headline yield не означает 7% реального прироста доли. Экономика зависит от участия и распределения новых units.
Практикум: как оценить validator profitability
Соберите reward, commission, hardware, bandwidth and capital opportunity cost. При падении native coin price revenue в фиатной базе снижается, тогда как часть расходов фиксирована.
Если сеть security зависит от operators, которые устойчиво работают в минус, decentralization может ухудшаться: остаются субсидируемые или самые крупные участники.
Практикум: как оценить data availability
Спросите, где хранится информация, необходимая для воспроизведения state transition. Full L1 node должен иметь достаточно данных для independent verification согласно protocol.
Если higher layer публикует только commitment, но data лежит у committee or external storage, security model включает новый trust assumption. Validity proof и availability данных нельзя смешивать.
Практикум: как отличить L2 от sidechain
Найдите контракт на base layer и определите, может ли L1 enforce correctness state transitions или хотя бы verify proof/dispute. Затем проверьте, где хранятся transaction data и какой механизм выхода существует при отказе operator.
Если собственный validator set решает финальное состояние, а L1 лишь принимает bridge deposits/withdrawals, архитектура ближе к sidechain.
Практикум: как читать слово shared security
Проект может утверждать, что наследует security крупной сети. Уточните, какие именно validators/stake отвечают за misbehavior, где происходит slashing and settlement и кто способен восстановить state.
Shared security бывает разной глубины. Маркетинговая формула без enforcement path не является техническим доказательством.
Практикум: как оценить sequencer risk
У rollup посмотрите, кто упорядочивает transactions, есть ли fallback, forced inclusion и возможность users выйти через L1. Central sequencer может обеспечить speed, но создаёт censorship and outage risk.
Важно отделять временную недоступность sequencing от возможности украсть funds. Эти риски зависят от rollup contracts и upgrade keys.
Практикум: как оценить bridge к новой L1
Проверьте canonical bridge, custody/mint model, validator/oracle set, limits and emergency pause. Большая часть external assets в новой сети может зависеть от одного bridge.
Если bridge compromised, native consensus L1 способен продолжить работу, а wrapped assets потерять backing. Поэтому ecosystem TVL не равно base-layer security.
Практикум: как анализировать native stablecoin liquidity
Новая L1 может иметь много dapps, но слабую stablecoin depth. Пользователям трудно входить/выходить без bridge и slippage.
Liquidity infrastructure влияет на usability и economic activity, хотя не является consensus property. Хороший технический L1 может оставаться экономически изолированным.
Практикум: как проверять ecosystem usage
Разделите activity на fee-paying users, incentive-driven transactions, validator votes, bots and internal program calls. Raw transaction count может быть огромным при небольшом числе independent users.
Устойчивый спрос проявляется в повторном использовании после окончания rewards и в разнообразии applications.
Практикум: как читать TVL на L1
TVL зависит от token prices, bridged assets and protocol accounting. Рост native coin price автоматически увеличивает dollar TVL без нового deposit.
Для base-layer evaluation полезнее decomposition: native locked units, stable assets, bridge exposure and independent protocol distribution.
Практикум: как проверять outage history
Для каждого incident запишите cause, affected services, duration, block production status, transaction success and recovery procedure. Это намного информативнее одного uptime percentage.
Сеть, которая открыто публикует post-mortem и исправляет root cause, отличается от системы, где failures повторяются без технического объяснения.
Практикум: как читать governance decentralization
Определите кто может предложить upgrade, кто принимает specification, кто выпускает client software и кто фактически обновляет validators/nodes. Formal vote — только один слой.
Если protocol theoretically community-governed, но один foundation controls repository, releases and emergency keys, effective governance более концентрирована.
Практикум: как проверять upgradeability base layer
У классического L1 protocol не существует одного proxy-admin address, но governance can ship new consensus rules through client releases. В некоторых newer systems могут быть explicit on-chain upgrade authorities.
Пользователь должен понимать, насколько быстро rules can change и способен ли он продолжить старую chain, если не согласен.
Практикум: как отделить technology from valuation
Допустим, L1 показывает excellent uptime, diverse clients и strong usage, но native coin имеет massive unlock and high FDV. Technical thesis positive, investment thesis может быть negative.
И наоборот, undervalued coin не исправляет weak consensus. Всегда ведите две независимые карточки: network quality и token economics.
Практикум: как анализировать L1 в bear market
Падение price проверяет validator/miner economics, treasury runway and real user demand. Incentive-driven activity может исчезнуть, а subsidy-dependent applications — закрыться.
Bear market therefore полезен как stress test architecture and economics: какая часть ecosystem работает без постоянного роста native asset.
Практикум: как анализировать L1 в bull market
Высокий спрос создаёт другой stress: congestion, fee spikes, state growth, MEV and validator load. Сеть, комфортная при низкой activity, может показать bottlenecks на пике.
Лучший L1 analysis включает оба режима — shortage of demand and excess of demand.
Практикум: как сравнивать два Layer 1
Создайте одинаковые строки: consensus, finality, node cost, validator concentration, client diversity, fee model, throughput under load, data availability, governance, incident history, issuance and ecosystem liquidity.
Не начинайте с price performance. Это позволяет сравнить architecture before market narrative.
Практикум: как выбрать сеть для конкретного приложения
High-frequency game может предпочесть низкую latency and cheap execution; high-value settlement — conservative security and strong finality; enterprise application — predictable governance and privacy tooling.
Нет abstract ‘лучшего L1’. Есть matching technical guarantees to workload.
Практикум: как выбрать L1 для хранения native asset
Пользователь должен проверить wallet support, self-custody model, transaction finality, recovery process, hardware-wallet compatibility and fee reserve.
Protocol architecture matters only together with operational ability safely hold keys.
Практикум: как выбрать L1 для smart contracts
Разработчик оценивает VM, languages, tooling, audits, client/RPC availability, state model, debugging and upgrade patterns. High TPS without mature developer tooling can increase implementation risk.
Ecosystem quality includes docs and security practices, not only chain benchmark.
Практикум: как реагировать на заявление ‘убийца Ethereum’
Игнорируйте comparison slogan и разложите network на metrics. Часто новая L1 optimizes different bottleneck at cost of different assumptions.
Полезный вопрос: что сеть делает принципиально иначе, какие ресурсы требует и какие guarantees ослабляет или усиливает.
Практикум: как реагировать на заявление ‘самый децентрализованный L1’
Попросите definition: node count, stake distribution, client diversity, governance or hosting? Без dimension слово децентрализация пустое.
Сильная сеть обычно открыто показывает несколько dimensions rather than один flattering metric.
Практикум: как реагировать на ‘нулевые комиссии’
Если users ничего не платят, выясните кто финансирует block production: inflation, foundation subsidy, application sponsor or limited free quota.
Resource consumption всегда имеет economic cost, даже если он скрыт от пользователя.
Практикум: как реагировать на ‘instant finality’
Уточните exact definition finality, quorum assumptions and behaviour during network partitions. Быстрый certificate может быть сильным, если validator set robust, или fragile при высокой concentration.
Latency and security must be read together.
Практикум: как реагировать на ‘миллионы TPS’
Проверьте whether number includes parallel shards, off-chain batching, theoretical hardware limit or simple transfers. Then compare mainnet sustained workload.
Large number without methodology should not enter investment decision.
Практикум: как реагировать на ‘Ethereum security’
Если claim делает L2 or sidechain, найдите enforcement contract and proof/data mechanism. ‘Built on Ethereum’ can mean token, bridge, data posting or actual rollup settlement.
Only technical relationship tells what is inherited.
Практикум: как реагировать на падение native coin
Не называйте protocol failed только по цене. Проверьте block production, stake/hash, validators, users, fees and development.
Market can reprice asset while network operates normally.
Практикум: как реагировать на рост native coin
Не делайте обратную ошибку: price rally can precede usage or be speculation. Network health needs independent metrics.
Technical due diligence should remain unchanged during hype.
Практикум: итоговая карточка L1
Сохраните snapshot с датой: chain ID, mainnet status, consensus, execution model, finality, validators, clients, node requirements, fee model, issuance, incidents, governance, L2/bridge dependencies.
Через квартал обновите карточку и сравните changes. Longitudinal view показывает развитие лучше marketing launch presentation.
