Mina Protocol – L1-блокчейн, в котором актуальное состояние подтверждается рекурсивным zero-knowledge proof постоянного небольшого размера. Узлу не нужно заново исполнять всю историю, чтобы проверить такой сертификат. Но фраза «блокчейн весом 22 КБ» описывает криптографическое доказательство состояния, а не всю базу транзакций, архивные данные и рабочий размер node.
Действующий mainnet работает на версии Berkeley: в ней доступны zkApps, Kimchi и o1js, а временные supercharged rewards уже отменены. Mesa – следующий крупный hard fork. На 25 августа 2026 года он прошёл публичные тестовые этапы и готовится к mainnet, но ещё не должен описываться как активная конфигурация основной сети.
История
Разработка началась в 2017 году в компании O(1) Labs, позже переименованной в o1Labs. Первое название протокола – Coda. После спора о торговой марке проект стал Mina. Сооснователи Evan Shapiro и Izaak Meckler поставили задачу создать проверяемый блокчейн, размер доказательства которого не растёт вместе с историей.
Mainnet запустили 23 марта 2021 года. На старте Mina уже применяла recursive zk-SNARKs и Proof of Stake, но полноценная программируемость zkApps оставалась в разработке. Поэтому ранние описания Mina как готовой платформы приватных приложений смешивали работающий consensus и будущий application layer.
Berkeley upgrade завершился в июне 2024 года. Он включил Kimchi, выполнение zkApp-транзакций и o1js, а также отменил supercharged rewards. В 2025 году o1Labs приняла основную часть инженерных, продуктовых и ecosystem-функций, тогда как Mina Foundation сосредоточилась прежде всего на децентрализованной treasury и долгосрочной структуре финансирования.
Следующий пакет изменений получил имя Mesa. В тестах проверялись сокращённый slot, расширенные лимиты zkApps и автоматизированный hard fork. Devnet-этап был назначен на август 2026 года, а отдельная mainnet-подготовка продолжалась. До фактической активации Berkeley остаётся корректной основой для описания production.
Команда
Evan Shapiro и Izaak Meckler основали o1Labs и спроектировали ранний протокол. В текущей структуре o1Labs – основной инженерный contributor, развивающий daemon, proof systems, o1js и Mesa. Mina Foundation не управляет блоками и не может единолично переписать ledger, но влияет через treasury, гранты, делегации и координацию governance.
После реорганизации 2025 года руководителем o1Labs является Brandon Kase, а Mina Foundation возглавляет Josh Cincinnati. Разработка также распределена между node operators, zkApp-командами, аудиторами и участниками Mina Improvement Proposal. Наличие отдельных юридических организаций снижает путаницу ролей, но зависимость от небольшой группы core-разработчиков остаётся важным риском.
Succinct blockchain без магии
Каждый новый block меняет ledger state и одновременно обновляет доказательство корректности всей цепочки. Рекурсия позволяет новому proof подтвердить предыдущий proof и текущий transition. В итоге verifier проверяет один компактный сертификат вместо последовательного воспроизведения всех blocks от genesis.
Это не удаляет историю. Archive node хранит blocks, transactions, accounts и данные, нужные explorers и аналитике. Block producer тоже выполняет заметную работу и держит актуальное состояние. Компактность относится к проверке текущего консенсусного state, а не к бесплатному хранению произвольного объёма данных.
Подход Mina отличается от modular data availability в Celestia. Celestia помогает rollups публиковать данные, а Mina сжимает достоверность собственной L1-истории в recursive proof. Для полноценного восстановления приложения всё равно могут потребоваться off-chain данные и indexers.
Consensus Ouroboros Samisika
Mina использует Proof of Stake семейства Ouroboros. В каждом slot право предложить block определяется stake и verifiable random function. Чем больше делегировано MINA, тем выше ожидаемая доля blocks, но результат отдельного slot остаётся вероятностным.
Samisika адаптирует Ouroboros к succinct chain и обеспечивает bootstrapping по компактному proof. Consensus выбирает наиболее тяжёлую допустимую chain с учётом density и protocol rules. Финальность не мгновенная BFT: уверенность растёт с последующими blocks, поэтому сервисы выбирают собственное число confirmations.
Delegator назначает stake block producer, не передавая ему private key. Producer может удерживать заявленную комиссию и распределяет rewards по своим правилам. Protocol не гарантирует срок или способ выплаты клиенту пула, поэтому репутация и прозрачность оператора имеют значение. Это похоже на делегирование в Cardano, но параметры и реализация consensus различаются.
Block producers и SNARK workers
Block producer выбирает transactions, покупает готовые proofs из SNARK work marketplace и собирает block. SNARK worker доказывает корректность ранее не доказанных transaction transitions и объявляет цену за работу. Producer экономически выбирает подходящие предложения.
Так разделяются consensus и proof generation. Один участник может выполнять обе роли, но это не обязательно. Если доказательства слишком дороги или их мало, producer способен сам генерировать work, однако hardware requirements и задержки повышаются.
Archive nodes не голосуют за chain сами по себе. Они принимают canonical data и складывают подробную историю в базу. Explorers и приложения, зависящие только от одного archive provider, получают отдельную точку отказа даже при корректной L1.
Kimchi, Pickles и рекурсия
Kimchi – proof system на базе PLONK-подобной arithmetization с polynomial commitments. Pickles – рекурсивный слой, позволяющий proofs подтверждать другие proofs. Эти компоненты используются и protocol-level proof, и разработчиками через более высокоуровневые инструменты.
Криптографическая корректность не означает, что доказанное утверждение полезно. Circuit может безошибочно доказать неверно сформулированное business rule. Ошибка в constraints, witness generation или внешних данных переносится в application result.
zkApps и o1js
zkApp состоит из smart contract account и off-chain prover logic. Пользователь или сервис вычисляет результат и создаёт proof, а chain проверяет proof и разрешённые account updates. Тяжёлое вычисление не повторяется каждым validator, но prover несёт локальные затраты времени и памяти.
o1js позволяет описывать программы на TypeScript-подобном языке. Доступны state, permissions, events, custom tokens и composable proofs. Код приложения должен явно ограничить все значения, влияющие на результат: обычная JavaScript-переменная вне circuit не становится автоматически доказанной.
Приватность также не включается сама. Proof может скрыть witness, однако публичные account updates, адреса и token transfers остаются видимыми по выбранной модели. Для credential-приложений Mina конкурирует с системами доказательства личности вроде World, но не требует единой биометрической инфраструктуры на уровне protocol.
Accounts, tokens и комиссии
Ledger хранит accounts с balance, nonce, permissions, zkApp state и verification key. Создание нового account требует account creation fee, которая компенсирует постоянное расширение state. Обычная transaction платит fee, назначенную отправителем, а block producer выбирает операции из mempool.
Custom token в Mina создаётся через zkApp authority. Token owner определяет правила mint, burn и transfer approval. Это не делает каждый актив permissionless: upgrade authority, admin keys и contract logic нужно проверять отдельно.
zkApp proof может быть дорогим для клиента даже при небольшой on-chain fee. Также существуют transaction limits на account updates, events и actions. Обещание «неограниченных off-chain вычислений» означает, что chain проверяет компактный proof, но входы, выходы и обновления state всё равно ограничены protocol.
Токен MINA и токеномика
MINA используется для fees, staking, delegation, rewards и голосования. Genesis initial distribution составлял 1 млрд MINA. В него вошли community sale, Mina Foundation, o1Labs endowment, core contributors, backers и community allocations с разными unlock schedules.
У MINA нет жёсткого maximum supply. Изначальная monetary policy начиналась с повышенной инфляции и предполагала снижение к 7% годовых по умолчанию. Supercharged rewards временно удваивали rewards для части unlocked stake, чтобы стимулировать раннее участие, но Berkeley отменил этот механизм. Старые калькуляторы с двойной наградой больше не описывают mainnet.
Nominal reward не равен реальной доходности: учитываются комиссия producer, доля активного stake, missed blocks, разбавление и рыночная цена. Нестейкающий holder теряет относительную долю при эмиссии. Protocol fees поступают producer и не образуют автоматический buyback.
Управление
Технические изменения проходят через MIP, обсуждение, release development, testing и on-chain vote. Stake-weighted голосование показывает поддержку, но безопасный hard fork требует обновления достаточной доли block producers, exchanges и инфраструктуры.
Berkeley доказал, что governance способно активировать большой пакет, но потребовал согласованной остановки и ручной координации. Mesa добавляет automated upgrade mechanism именно для снижения операционного риска будущих forks. Пока Mesa не активирована на mainnet, её новые 90-секундные slots и расширенные limits являются утверждённым обновлением, а не действующей характеристикой.
Mesa: что планируется
Mesa должна сократить slot с 180 до 90 секунд, расширить on-chain state, events, actions и число account updates, а также автоматизировать переход node на новую версию. После stress tests лимит zkApp-транзакций на block был выбран консервативно, чтобы избежать memory spikes.
Публичный Mesa Trail проверял переход Berkeley-to-Mesa, emergency forks, archive schema, Rosetta и zkApps. Devnet – финальная репетиция перед mainnet. До завершения production fork нельзя считать подтверждёнными ни точную дату, ни реальное поведение под долгой нагрузкой.
Применение
Mina подходит для приватных credentials, доказательства происхождения web data, verifiable games, compliance без раскрытия исходных данных и proof settlement. Protokit развивает framework для privacy-enabled appchains, но это отдельный слой и набор инструментов, а не автоматическая масштабируемость каждого zkApp.
Компактный state proof может быть полезен мобильным и browser clients. При этом UI обычно обращается к RPC, indexer и prover service. Пользователь получает trust minimization только тогда, когда действительно проверяет proof и не доверяет ответу централизованного backend без проверки.
Основные риски
- Криптография и реализация. Ошибка в Kimchi, recursion, circuit или verifier способна нарушить корректность всей системы.
- Низкая пропускная способность. Длинные slots и protocol limits сдерживают массовые приложения до проверенных upgrades.
- Централизация stake. Крупные pools и foundation delegation получают влияние на blocks и governance.
- Prover-зависимость. Сложные zkApps могут требовать мощного hardware или централизованных proving services.
- Доступность данных. Compact proof не заменяет archive data, indexers и данные приложения.
- Upgrade risk. Mesa меняет timing, limits и операционный процесс, а mainnet-результат ещё не подтверждён длительной эксплуатацией.
- Token dilution. Постоянная эмиссия размывает пассивных holders, а rewards не гарантируют прибыль в фиатном выражении.
Итог
Mina предлагает редкую модель: L1-state можно проверять по постоянному компактному recursive proof, а zkApps переносят вычисление к prover и оставляют chain проверку. Это сильная архитектурная идея, но не «бесплатный бесконечный блокчейн».
При оценке Mina важно разделять работающий Berkeley mainnet, внешние archive и prover services, а также ещё не активированный Mesa. MINA объединяет security, fees и governance, но его ценность зависит от реального спроса на proof settlement и zkApps, устойчивости core cryptography и распределения stake.
