Aptos – proof-of-stake блокчейн первого уровня на MoveVM, который ускоряет обработку за счёт конвейера и оптимистичного параллельного исполнения Block-STM. Валидаторы сначала согласуют порядок блока, а затем одновременно исполняют независимые части. Если предварительные вычисления конфликтуют, система проверяет зависимости и повторяет только затронутые операции в правильном порядке.
Это отличается от сетей, где разработчик обязан заранее объявить все аккаунты для записи. Block-STM пытается извлечь параллелизм автоматически. Преимущество – привычная для пользователя account-модель. Цена – сложный движок, которому нужно детерминированно обнаруживать конфликты и воспроизводить один результат на разных узлах.
MoveVM и ресурсы
Move создавался для цифровых активов. Значение с семантикой resource нельзя произвольно скопировать или уничтожить. Модуль определяет допустимые функции, а bytecode verifier проверяет набор инвариантов до публикации кода. В Aptos данные ресурса обычно хранятся под адресом аккаунта и типом.
Безопасность типов не гарантирует безопасность продукта. Контракт способен иметь ошибочную формулу цены, чрезмерное право администратора или ненадёжный оракул. Move уменьшает риск случайного дублирования актива, но не заменяет аудит бизнес-логики.
Пакеты можно обновлять в рамках заданной политики совместимости. Пользователь должен проверять не только адрес модуля, но и возможность его изменения. Неизменяемый код, совместимое обновление и административно контролируемый прокси создают разные риски.
Как работает Block-STM
Транзакции блока получают фиксированный порядок, но сначала исполняются оптимистично на нескольких потоках. Многоверсионная структура данных сохраняет чтения и записи по версиям. После исполнения система проверяет, не прочитала ли операция значение, которое должна была получить от более ранней транзакции.
Если зависимость нарушена, результат отменяется и транзакция запускается повторно с актуальным состоянием. При низкой конкуренции большая часть работы проходит параллельно. При высокой конкуренции повторов становится больше, но итог остаётся эквивалентен последовательному исполнению в согласованном порядке.
Delta writes описывают изменение, например прибавление числа, а не только конечное значение. Это позволяет подготовить часть конфликтующих операций параллельно и применить изменения детерминированно. Пропускная способность поэтому зависит от состава нагрузки, числа ядер, базы данных и сетевого этапа, а не от одного лабораторного TPS.
Консенсус и конвейер
Aptos использует stake-weighted BFT-консенсус, выросший из DiemBFT и HotStuff. Распространение партий транзакций, упорядочивание метаданных, исполнение и сохранение в базе разделены на перекрывающиеся стадии. Пока один блок исполняется, следующий может согласовываться, а предыдущий – записываться.
Доступность данных подтверждается кворумом валидаторов, поэтому узел может получить содержимое согласованной партии у участников, которые его сохранили. Финальный результат становится частью последовательной версии реестра. Каждая успешная пользовательская транзакция получает уникальную ledger version.
Aptos Labs продолжает исследовать новые протоколы, включая Raptr, и регулярно меняет внутренние компоненты через обновления сети. Название исследовательского консенсуса не следует автоматически принимать за активную версию mainnet. Для операционной проверки важны текущий релиз узла и on-chain protocol config.
Аккаунты, sequence number и orderless transactions
Обычная транзакция содержит адрес отправителя и sequence number. Сеть принимает номера по очереди, что защищает от повторного исполнения. Если операция с ранним номером не проходит, более поздние могут ждать. Это похоже на nonce в EVM, хотя структура состояния и правила газа отличаются.
Orderless transactions используют отдельный replay-protection nonce и срок действия, чтобы высоконагруженное приложение не координировало одну строгую очередь. Это полезно для параллельных отправителей, но требует корректного управления случайными nonce и временем истечения.
Aptos также поддерживает ротацию ключей, multi-agent transactions, sponsored transactions и keyless accounts. Эти возможности отделяют адрес от одного неизменного ключа. Но потеря контроля над механизмом восстановления или неправильно настроенная делегация остаются риском.
История
Aptos Labs была создана в 2021 году Мо Шейхом и Эйвери Чингом после прекращения проекта Diem в Meta. Вместе с ними перешла группа инженеров, работавших над Move, Move Prover, консенсусом и распределённым хранением. Компания официально начала публичную работу и привлекла финансирование в 2022 году.
Mainnet стартовала в октябре 2022 года. Ранние обновления развивали токеновые стандарты, delegated staking и параллельный движок. Позднее сеть добавила keyless accounts, sponsored transactions, on-chain randomness, агрегаторы подписи и orderless transactions.
В декабре 2024 года Мо Шейх покинул пост генерального директора Aptos Labs, и компанию возглавил Эйвери Чинг. В 2025–2026 годах дорожная карта сосредоточилась на торговой инфраструктуре, Block-STM следующего поколения, приватности mempool и дальнейшем уменьшении задержки консенсуса.
Команда
Эйвери Чинг – сооснователь и генеральный директор Aptos Labs, ранее руководивший блокчейн-платформой Meta. В founding team входят создатели Move, Block-STM, Narwhal и Bullshark, а также специалисты по криптографии и распределённым системам.
Aptos Foundation координирует гранты, управление и экосистемные программы отдельно от Aptos Labs, которая создаёт значительную часть программного обеспечения и продуктов. Валидаторы независимы, но концентрацию стейка, клиентского кода и голосов управления нужно оценивать фактически.
Токен APT
Начальное предложение составляло один миллиард APT. На Community приходилось 51,02%, Core Contributors – 19%, Foundation – 16,5%, Investors – 13,48%. Название Community не означает мгновенную раздачу пользователям: большая часть этого пула находилась под управлением Foundation и Labs для грантов и развития.
Для инвесторов и основных участников был установлен четырёхлетний график с первым годом блокировки и ежемесячными разблокировками после него. Пулы Community и Foundation распределяются дольше. Текущие циркулирующее предложение и будущие разблокировки нужно смотреть отдельно от начальных процентов.
APT оплачивает gas, участвует в стейкинге и управлении. Изначальная максимальная ставка эмиссионного вознаграждения начиналась с 7% и должна была ежегодно снижаться на 1,5% от текущего уровня до нижней границы 3,25%. Параметры изменяемы on-chain governance, а комиссии сжигаются, поэтому фактическое изменение предложения определяется текущей конфигурацией.
Главные риски
- Сложность исполнения. Ошибка в Block-STM, кэше или повторном исполнении может затронуть весь валидаторский набор.
- Высокая конкуренция. Популярное состояние создаёт конфликты и уменьшает пользу параллелизма.
- Частые обновления. Быстрая эволюция улучшает сеть, но увеличивает объём доверенного кода и операционный риск.
- Токеновые разблокировки. Начальное распределение и график предложения влияют на рынок и вес управления.
- Стейкинг. Делегатор зависит от эффективности валидатора и параметров сети, а ликвидный стейкинг добавляет контракт.
- Мосты и активы. Перенесённый токен может зависеть от отдельного эмитента, моста или набора подписантов.
Как проверять Aptos-приложение
Нужно установить полный адрес модуля и функцию entry, тип передаваемого актива, список подписантов, maximum gas amount и expiration timestamp. При последовательной операции проверить актуальный sequence number. В спорной ситуации сравнить ledger version, VM status и события, а не только уведомление кошелька.
Принцип очереди удобно сопоставить с инструкцией о том, как nonce упорядочивает транзакции, не считая две модели идентичными. Для анализа валидатора полезен материал о рисках стейкинга, а для предложения APT – руководство о том, как читать токеномику и разблокировки.
Итог: Aptos сочетает ресурсно-ориентированный Move с привычной account-моделью и автоматическим оптимистичным параллелизмом. Сильная сторона – разработчику не нужно вручную объявлять все конфликты для Block-STM. Главный компромисс – сложность конвейера и частых обновлений, поэтому качество сети определяется не пиковым тестом, а стабильностью клиентов, реальной нагрузкой и прозрачностью on-chain параметров.
