Sui отличается от account-centric chains не только скоростью consensus. Его state организован вокруг **objects с уникальными ID, version и digest**, а transaction заранее называет объекты, которые читает или изменяет. Это делает dependencies явными: две transactions, работающие с независимыми objects, не обязаны конфликтовать на execution layer. Shared objects требуют общего sequencing, owned objects имеют единственного authority path, а Move задаёт resource semantics и lifecycle объектов. Важно также не повторять устаревшую формулу «owned-object transactions обходят consensus»: текущая документация Sui 2026 года прямо говорит, что **все transactions sequenced by Mysticeti DAG consensus**, после чего deterministic execution может использовать объектные dependencies для concurrency.
Sui хранит state как адресуемые objects, а не как один account key-value space
В account-centric smart-contract model developer часто мыслит адресом contract и набором storage slots. Sui делает объект первичной единицей onchain state.
Каждый object имеет stable ID
Object ID — глобально уникальный 32-byte identifier. Он остаётся тем же на протяжении жизни объекта, даже когда contents меняются.
Version меняется при mutation
Current object metadata содержит 8-byte unsigned version. После transaction, которая mutates object, создаётся новая version того же ID.
Digest аутентифицирует конкретное состояние
Object reference — это **(ID, version, digest)**. Transaction использует exact reference, чтобы sender и validator говорили об одном и том же state, а не просто об абстрактном ID.
Last transaction digest связывает object history
Object metadata указывает transaction, которая создала текущую version. Из этого naturally получается transaction-object DAG: transaction consumes object versions и produces новые versions или новые objects.
ID и version решают разные задачи
ID отвечает «что это за object», version — «какое его состояние», digest — «какие exact contents мы аутентифицируем». Explorer/debugger должен смотреть все три.
Ownership model определяет, кто и как может использовать object
Sui ownership — часть consensus-visible metadata, а не convention application code.
Address-owned object контролируется одним address
Такой object может использовать transaction, авторизованная его owner. Coins и многие user assets естественно моделируются address-owned objects.
Object-owned object принадлежит другому object
Owner field может быть object ID. Это позволяет compositional ownership: например, игровая сущность содержит child assets, которые нельзя свободно достать без logic parent object.
Immutable object доступен всем, но не может mutate
После превращения в immutable object никто не может его transfer, delete или mutate. Он становится read-only shared state.
Shared object доступен всем и требует общей coordination
Move function может вызвать share_object. После этого competing transactions могут обращаться к одному state, поэтому network должна определить deterministic ordering.
Party / consensus-address-owned object имеет одного логического owner, но sequencing через consensus
Current Sui object model отдельно описывает ConsensusAddressOwner/party ownership. Это полезно, когда доступ ограничен address, но state transition всё равно должен входить в consensus ordering path.
Wrapped object физически вложен в другой Move object
Пока child wrapped, он не существует как independently addressable top-level object для обычного transaction input. Move code parent type контролирует его lifecycle.
Ownership category — это concurrency hint
Если transaction касается одного owned object, conflict set очевидно локален. Если тысячи users одновременно mutate один shared object, этот object становится hot synchronization point независимо от theoretical throughput сети.
Move превращает assets в resources с контролируемым lifecycle
Sui использует Move language, но адаптирует его к object-centric storage.
Onchain Move object должен иметь key ability и UID
Sui Move struct, который хранится как object, имеет ability key и first field id: UID. UID связывает Move-level type с platform object identity.
Resource нельзя случайно copy или drop
Move abilities ограничивают, какие values можно копировать, уничтожать, хранить и использовать как key. Asset conservation поэтому частично выражается type system, а не только runtime require statements.
Creation происходит через object::new
Function создаёт новый UID, уникальный внутри transaction context. После этого code должен определить ownership: transfer address-у, share, freeze как immutable или wrap в другой object.
Transfer меняет owner, а не «balance slot» внутри account
NFT-like object при transfer остаётся тем же ID, но его owner metadata и version изменяются.
Package object после publish immutable
Published Move package object нельзя просто переписать in place. Upgrade mechanics публикуют новую package version через предусмотренную upgrade capability/linkage model, сохраняя auditability deployed code.
Dynamic fields расширяют object без giant fixed struct
Sui supports dynamic fields/dynamic object fields, позволяя parent object владеть expandable keyed collections без глобального account storage table.
Move resource safety не делает contract автоматически безопасным. Access control, oracle assumptions, arithmetic economics и shared-object logic всё равно могут содержать application bugs.
Transaction-object DAG делает dependencies явными и помогает parallel execution
Sui transaction перечисляет object inputs. Поэтому scheduler может определить значительную часть conflicts по references, а не только после speculative execution.
Независимые objects создают независимые branches
Если transaction A mutates Coin/Object X, а B mutates unrelated Y, их state dependencies не пересекаются. Deterministic executor может обрабатывать их параллельно при сохранении единого consensus sequence/effects semantics.
Same object version нельзя законно consume дважды
Две competing transactions, обе ожидающие exact (ID, version, digest), конфликтуют. После первой mutation старая version больше не current input для второй.
Shared object формирует explicit contention domain
DEX pool, game world или marketplace registry как shared object может стать hotspot. Throughput application определяется тем, насколько state разбит на independently mutable objects.
Programmable Transaction Block сокращает лишние round trips
Одна transaction может содержать последовательность commands: split coins, Move calls, transfers и другие действия. Outputs ранней command могут стать inputs следующей внутри atomic transaction.
Parallelism не равен «все transactions одновременно»
Scheduler обязан учитывать read/write dependencies, shared-object ordering, gas object conflicts и deterministic result. Hot object способен сериализовать большой объём traffic.
Historical fast-path wording сегодня требует оговорки
Ранние описания Sui часто говорили, что simple owned-object transactions могут обходить full consensus. **Current Sui Docs lifecycle говорит иначе: all transactions are sequenced by Mysticeti DAG consensus.** Object independence теперь корректнее объяснять как execution/congestion advantage, а не как blanket consensus bypass.
Mysticeti DAG consensus задаёт current global sequence
Current Sui network использует Mysticeti — low-latency DAG-based Byzantine consensus.
Validator включает transaction в proposed consensus block
Full node Transaction Driver выбирает validator; validator проверяет validity/safety и предлагает transaction в своём Mysticeti block.
Later DAG blocks подтверждают proposal references
Validators строят directed graph blocks, referencing previous blocks peers. Protocol выводит commit/order из DAG structure вместо отдельной классической chain leader на каждый transaction.
Accepted transaction исполняется deterministically после commit
Current lifecycle: Mysticeti sequences transaction, validators execute committed/accepted transactions и получают одинаковые effects при одинаковом state.
Quorum acknowledgement или certified checkpoint даёт settlement proof
Full node собирает evidence effects. После достаточного validator acknowledgement либо включения в certified checkpoint user получает settlement finality proof.
Consensus sequence и execution concurrency не противоречат друг другу
Единый order нужен для deterministic shared state, но executor не обязан физически serially выполнять каждую independent transaction, если dependencies допускают parallel work.
Shared-object congestion control защищает hot state
Current protocol configs содержат per-object accumulated execution-cost controls и deferral rules. Это показывает важный practical limit: network capacity может быть высокой, а один popular shared object всё равно получить очередь.
Checkpoints превращают consensus commits в permanent state-sync record
Consensus отвечает за ordering, но explorers и new nodes нуждаются в compact certified history.
Validators формируют checkpoints из consensus commits
Checkpoint summary включает ordered transactions/effects references и связан с предыдущими checkpoints.
Certified checkpoint подписан quorum validators
После quorum signature checkpoint становится trust anchor для state sync и historical verification.
Indexers потребляют checkpoint stream
Current lifecycle docs прямо описывают, что indexers сохраняют transaction, effects, events, created/updated objects в queryable indexes после certified checkpoint.
Explorer должен показывать effects, а не только «from → to»
Sui transaction может создать, mutate, transfer, wrap, delete несколько objects и emit events. Простая account-chain метафора скрывает основную часть результата.
Полезный explorer checklist
- Transaction digest и checkpoint.
- Sender и gas owner/payment object.
- Input objects: ID, version, ownership type.
- Commands / Move calls.
- Created, mutated, transferred, deleted/wrapped objects.
- Shared objects и их initial/current versions.
- Events.
- Gas computation/storage/rebate fields.
Checkpoint finality и UI indexing latency — разные вещи
Transaction может быть settled, но конкретный explorer отобразит её позже из-за indexer lag. Debugging должен отделять consensus proof от frontend availability.
Delegated PoS связывает validator voting power со stake SUI
Sui uses delegated proof-of-stake. Token holders stake SUI к validator pools, а voting power validator зависит от delegated stake с protocol caps.
Новый stake становится voting power со следующего epoch
Current validator docs: stake deposit request pending immediately, а contribution к voting power начинается **в epoch после создания stake**.
Mainnet epochs для staking accounting — 24 часа
Validator rewards page прямо указывает 24-hour epochs. Epoch boundary обновляет validator set-related economics и reference gas price.
Individual validator voting power capped at 10%
Network total voting-power scale использует 10,000 units; quorum threshold 6,667. Один validator capped at **1,000 voting power = 10%**, даже если его staking pool аккумулирует больше 10% stake; remaining voting power redistributed across validator set.
Rewards зависят от performance и commission
At epoch end collected gas fees и stake subsidies распределяются validators/stakers. Validator commission удерживает определённую долю reward его staking pool.
Underperforming validator может потерять reward за epoch
Sui tallying rule позволяет validators отмечать poor operations. Документация называет это slashing staking rewards за epoch; это нужно отличать от автоматического burn всего delegated principal.
Withdrawal stake обрабатывается сразу по previous-epoch exchange rate
Current docs говорят, что withdrawal не обязан ждать текущего epoch close. Пользователь получает principal + accumulated rewards до previous epoch и не получает ещё не определённую reward текущего epoch.
StakedSUI — object, а не невидимая account flag
Deposit оборачивается в StakedSUI object. Его creation epoch/timestamp и staking-pool exchange-rate series используются для расчёта withdrawal value.
SUI оплачивает computation, storage и участвует в storage-fund economics
Sui gas model разделяет computational work и long-lived storage effects.
Gas payment — тоже object input
SUI coin used for gas имеет object identity/version. Поэтому попытка параллельно потратить один и тот же gas coin создаёт dependency даже для otherwise unrelated transactions.
Reference gas price обновляется per epoch
Validators публикуют quotes; current docs описывают stake-weighted **2/3 percentile** как reference gas price следующего epoch. Внутри epoch reference price остаётся постоянным.
Storage cost учитывает долгую жизнь state
Создание/увеличение onchain data несёт storage charge. Удаление state может возвращать storage rebate согласно protocol accounting.
Storage fund отделяет immediate validator revenue от long-term burden
Часть economics направлена на компенсацию будущих validators за хранение исторически созданного state, а не полностью раздаётся текущему producer set.
Object-centric design делает state cost видимым developer-у
Большая коллекция objects, dynamic fields и shared state имеет не только CPU cost, но storage footprint. Хорошая architecture минимизирует unnecessary persistent state.
Дешёвый single transaction не означает бесплатное приложение. Нужно считать contention hot objects, storage growth, gas-object management, indexer load и validator execution cost вместе.
Sui и Aptos используют Move, но parallelism устроен по-разному
Обе сети происходят из Move ecosystem, однако state/execution architecture различается заметно.
Sui делает object identity частью storage/execution model
Transactions явно ссылаются на object references. Ownership categories и versioned objects заранее описывают многие conflicts.
Aptos сохраняет account/global-storage model
Aptos Move resources размещаются в global storage под accounts/addresses. Developer чаще мыслит resources и modules, привязанными к account namespace, а не independently owned Sui objects как первичной state unit.
Aptos Block-STM использует optimistic dynamic parallelism
Current Aptos docs описывают ordered block execution, где Block-STM speculative parallel execution обнаруживает conflicts и re-executes transactions при необходимости, сохраняя preset deterministic order.
Sui parallelism сильнее опирается на explicit object dependencies
Sui transaction inputs заранее раскрывают ID/version/digest и ownership. Это делает dependency graph более explicit до execution; shared objects всё равно требуют consensus sequencing и congestion management.
| Характеристика | Sui | Aptos |
|---|---|---|
| Move heritage | Да | Да |
| Primary state mental model | Objects с ID/version/owner | Account/global storage resources |
| Conflict signal | Explicit object references/ownership | Runtime read/write conflict detection + execution metadata |
| Parallel execution | Dependency-aware objects | Block-STM speculative parallelism |
| Shared mutable state | Shared/party objects | Resources/global state paths |
| Consensus | Mysticeti DAG | Aptos BFT family |
Одинаковый Move syntax не означает одинаковый dApp architecture
Porting contract между Aptos и Sui требует переосмыслить ownership, storage and transaction composition. Это не просто rename SDK methods.
Object-centric model особенно естественен для assets
NFT, game item, position, ticket или credential может быть standalone object с explicit ownership. Account-centric resources могут моделировать то же, но через другую storage topology.
Главный вывод и FAQ
Главный вывод
Sui performance architecture начинается не с headline TPS, а с **явных state dependencies**. Object имеет ID, version, digest и ownership mode. Move контролирует creation/transfer/share/wrap semantics. Transaction перечисляет exact objects, поэтому независимые branches могут исполняться параллельно, а shared hot state становится видимым contention domain.
Current 2026 architecture также требует обновить старую mental model: все transactions sequenced by **Mysticeti DAG consensus**, затем validators deterministically execute committed work, certify effects и включают results в checkpoints. Object independence остаётся важной для concurrency и congestion, но не означает blanket bypass consensus.
DPoS layer связывает validator voting power с stake SUI, ограничивает одного validator 10% voting power, работает 24-hour epochs и распределяет gas fees/stake subsidies через staking pools. Explorer после этого должен читать не «from/to», а object effects.
Инженерный вопрос про Sui звучит так: **какие exact objects читает и mutates transaction, какие из них shared, где появляются dependency conflicts, что sequence-ит Mysticeti, какие effects подтверждены checkpoint и насколько stake/validator distribution поддерживает consensus assumptions.**
Что такое Sui object reference?
Это triple **(object ID, version, digest)**. ID идентифицирует object, version — конкретное состояние, digest аутентифицирует contents/metadata этой версии.
Чем owned object отличается от shared object?
Address-owned object имеет конкретного owner и локализованный authority path. Shared object доступен нескольким участникам и требует общего consensus ordering для competing mutations.
Sui всё ещё имеет fast path без consensus для owned objects?
Current 2026 transaction-lifecycle docs говорят, что **all transactions are sequenced by Mysticeti DAG consensus**. Поэтому старое blanket-описание bypass consensus устарело; object independence сейчас корректнее связывать с execution parallelism и reduced contention.
Почему Sui может исполнять transactions параллельно?
Object references делают dependencies явными. Transactions над disjoint objects не конфликтуют по state и могут выполняться concurrent, сохраняя deterministic effects. Shared hot objects могут сериализовать workload.
Когда начинает работать delegated stake?
Current validator docs указывают, что новый stake начинает участвовать в voting power со следующего epoch. Mainnet staking accounting использует 24-hour epochs.
Можно ли сразу вывести stake?
Current Sui docs описывают immediate withdrawal using previous epoch exchange rate: principal и начисленные до предыдущего epoch rewards возвращаются без ожидания current epoch close; reward текущего незавершённого epoch не включается.
Чем Sui parallel execution отличается от Aptos Block-STM?
Sui строит concurrency вокруг explicit object references and ownership. Aptos Block-STM выполняет ordered transactions speculatively in parallel, detects runtime conflicts and re-executes when needed.
Материал носит образовательный характер и не является финансовой рекомендацией или обещанием staking доходности.