Somnia 백서 전문

re an identical history of the data that was compressed and decompressed, and it uses this assumption to build a large amount of internal implicit information which never needs to be sent over the wire. It can say, "Use the address from 3.456 megabytes ago". For this reason, it achieves much better compression ratios than block compression. The downside, though, is that the sender and receiver must share an identical stream of data, and the 'implicit' data cannot be moved across machines or processes without using a lot of bandwidth, meaning the same process must compress the full stream of data (there are ways around this depending on the compression algorithm but it often requires a large amount of CPU time). This poses a problem for a blockchain, which typically has each block proposed by a different machine. It forces blockchains to use block-based compression, if anything, significantly impacting the compression ratios they can achieve. Somnia has a consensus and data availability algorithm designed to support streaming-based compression. Each validator is responsible for publishing their own stream of data to their own blockchain. These are the data chains introduced earlier in this section. The fact that data chains use the same process for publishing this stream unlocks the ability for streaming compression. ## **Hashes and Signatures** A lot of data in Ethereum transactions have a tight power law distribution, making them very compressible. There are, however two important exceptions: hashes and signatures. By definition, these completely change with a uniform distribution if any bit in the transaction is different, making them completely uncompressable (no two executed Ethereum transactions are identical due to nonces, which avoid replay attacks). Transaction hashes are easy: they are, again by definition, reproducible based on the transaction data itself, so they can simply not be sent (a receiving client is required to recalculate them anyway). Signatures are more challenging. They are required to be sent alongside each transaction. Due to them being uncompressable, this would heavily limit the compression ratios we are able to achieve on transaction data. However, we can aggregate signatures if we use the BLS signature scheme. BLS signatures can aggregate any number of BLS signatures into a single signature, effectively achieving a constant size for any number of transaction signatures. Somnia uses BLS signature aggregation for signature verification speed and, crucially, because it enables a far better compression ratio. <figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXfEjCRky-SOm2RJWhdrOKh0Z1cqWrOFAfSLFNSdGn7oDsKHWrPpPIMjcyOmzQXycGwKgiPO7dXESdwDO6eYh7q1zh-0CSFsoLCQsZgHV8IJJ5B-HBDW70_brLGApwNJsHFTZwGBf1n0qnK6YHCwQ9VKbpvv?key=Pd6FhcOWiUEbzWyN_-YJmg" alt=""><figcaption>Image explaining BLS signature scheme</figcaption></figure> This aggregate cryptography is an optional mechanism to submit batches of transactions, where the cost to verify the signatures of all transactions in the batch is similar to the cost of verifying just one transaction. Using large batches this reduces the cost of signature verification by many orders of magnitude. ## **Bandwidth Symmetry** In a typical blockchain, one validator is responsible for proposing each block and therefore, publishing the transaction data for that 'slot' of time to all of its peers. If the blockchain throughput is X bytes per second, and there are B blocks per second and N peers, the leader must send N \* X / B bytes in 1 / B seconds, requiring an upload speed of N \* X bytes per second (some blockchains will fan out in a tree architecture, which still requires the branching factor multiplied by X ). In comparison, due to Somnia having all peers publish their own shard of data, each peer is responsible for publishing X / (N \* B) bytes in 1 / B seconds, requiring an upload speed of X bytes per second. They also need to download everybody else's data for each block, requiring a download of N \* (X / N) bytes per second, which is just X. Note that no less data is being sent overall, but the bandwidth profile has been amortised to be symmetrical across all peers at all times. No peer ever needs to upload at a faster rate than the bandwidth of the blockchain itself, but they need to do this constantly instead of only when they propose a block. This enables the overall blockchain throughput to reach much closer to the bandwidth of the peers themselves. # Security ## **Decentralisation** Somnia philosophically believes in having sufficiently decentralised services, not maximally decentralised. What this means is that you have enough decentralisation of infrastructure to enable the good properties of decentralisation (increased security, censorship resistance, no single owner/counterparty) whilst not trading off to degrade performance significantly (all decentralisation will inherently decrease performance [see blockchain trilema](https://ieeexplore.ieee.org/abstract/document/10549891)). For Somnia, the main validators of the network will be targeting hardware specs between a Solana and Aptos node. This will allow a large group of participants to join the network but not have sub-par hardware and connectivity. This will ensure the high level of performance needed for real-time mass-consumer applications. There will initially be 100 globally distributed validator nodes. We expect this to grow as the network matures. We also incentivize decentralisation and global footprint for the chain through our tokenomics. ## Cuthbert Cuthbert is a separate implementation of Somnia's execution and database, using third party libraries wherever possible, and without any optimisations. Somnia validators automatically run every transaction through both Somnia and Cuthbert, and they will stop voting or executing if they ever detect a divergence between the two. This means that if the Somnia client has a bug or an issue in its execution or database, that bug would also have to be present in the separate Cuthbert implementation if this bug were to go undetected. Cuthbert will eventually be phased out of Somnia as the system becomes more mature. ## **Securing The Network** As stated in the introduction the network is secured by validators staking tokens to participate in the network. This is a PoS network similar to other major blockchain networks (e.g. ETH). Node providers are subject to slashing if they act maliciously against the network. This will be further explored in our tokenomics. # Use Cases ## **AI Agents - Deterministic AI, Natively On-Chain** Somnia enables AI agents that run as part of the network itself, letting smart contracts call language models, fetch external data, and execute decisions without depending on centralized providers. Because inference runs deterministically across validators, AI outputs reach consensus and become verifiable on-chain state. Making autonomous, trustworthy agents a native primitive rather than an off-chain dependency. ## **Gaming - Fully On-Chain, Forever Evolving Games** Somnia enables fully on-chain games where creators can easily build, modify, and extend games. Developers can create games that live forever on-chain, allowing players to own their in-game assets, modding systems, and worlds that grow continuously without centralized control. ## **SocialFi - True Ownership for Social Media Accounts** Somnia powers full on-chain social media platforms where users own their accounts and data. Creators aren’t locked into one platform and can freely port their content and followers between ecosystems, ensuring freedom and control. ## **Metaverse - Building Interoperable Virtual Socieities** Somnia is the backbone for metaverse applications where entire economies and ecosystems are built with on-chain ownership and logic. Developers can create worlds with seamless interoperability, allowing assets, avatars, and experiences to cross over between multiple virtual environments. ## **DeFi - Fully On-Chain Limit Order Books (LOBs)** Somnia’s performance enables fully on-chain limit order books (LOBs), offering price discovery and order matching similar to centralized exchanges but with full transparency and self-custody. This innovation brings more efficiency and fairness to decentralized finance (DeFi). ## **Real-Time Applications - Powering Real-Time, Large-Scale Applications** Somnia’s ultra-fast processing and sub-second finality are designed for real-time, mass-consumer applications. This goes beyond the categories above to places we have not imagined, Ultimately any web2 style application can now be built on web3 rails, offering the best of both worlds. We don’t even know all the possibilities yet and would love for builders to help us discover what is now possible when limits are removed. # On-Chain Reactivity ## The Missing Link Blockchains have historically had a major limitation: they are passive. They are excellent ledgers, but they are deaf and mute until a user kicks them into action with a transaction. A smart contract cannot "wake up" when a price changes, specific data shows up or when a specific event occurs. ## The Usability Imagine the world where you can instantly react to events happening on blockchain: * **DeFi**: Automated responses to price changes, liquidations, or interest accruals. For instance, a lending protocol might need to adjust collateral requirements instantly based on market volatility. * **Gaming**: Real-time updates for player achievements, in-game economies, or multiplayer interactions. Imagine a blockchain game where earning an NFT trophy automatically triggers rewards or level-ups without off-chain servers. * **Business Logic**: Supply chain tracking where an item's arrival (logged as an event) auto-initiates payments or audits. Or in insurance, a smart contract that pays out claims upon verified on-chain data like weather reports. ## The Setup The blockchain is ledger of transaction modifying the common state. Some of these transaction might emit a log, which is defined as an observable event: ```mermaid sequenceDiagram participant User participant Blockchain participant EventLog User->>Blockchain: Submit Transaction Blockchain->>EventLog: Event Emitted Note over EventLog: Observable Event ``` Traditionally the developer would need to create an infrastructure that constantly monitors the blockchain state and event through RPC calls. Then based on the logic the custom app would create a transaction and post it for the inclusion at the next available block: ```mermaid sequenceDiagram participant User participant Blockchain participant EventLog participant Monitor as Off-Chain Monitor participant Logic as Custom App Logic User->>Blockchain: Transaction Blockchain->>EventLog: Event Emitted loop Constant Polling Monitor->>Blockchain: RPC Call Blockchain-->>Monitor: Current State end Monitor->>Logic: Event Detected Logic->>Logic: Process Logic Logic->>Blockchain: Submit Reaction Tx Note over Monitor: ⚠️ Custom Infrastructure Note over Blockchain: Included in NEXT available block ``` As expected this created a large overhead for a typical development team. Additionally it did not meet the requirements of decentralisation, trustlessness, immediate reaction and reliable event handling. This is why we saw a plethora of services known as indexers or Web3 hooks: ```mermaid sequenceDiagram participant User participant Blockchain participant EventLog participant Indexer as Indexer Service participant Config as Custom Config/Logic User->>Blockchain: Transaction Blockchain->>EventLog: Event Emitted Indexer->>Blockchain: Monitor Events Blockchain-->>Indexer: Event Data Indexer->>Config: Trigger Hook Config->>Config: Execute Logic Config->>Blockchain: Submit Reaction Tx Note over Indexer: ⚠️ Centralized & Trusted Note over Blockchain: Included in NEXT available block ``` They alleviate a lot of issues related to the infrastructure, at the same time they add new issues related to the domain-specific configuration or language. Still the key requirements are still not met: * indexers are centralised and trustfull * the event handling trasaction can only be included in the next available block * it is not MEV-resistant * it's only as reliable as the indexer provider ## The Solution Enter **Somnia Native On-Chain Reactivity**. This isn't just an incremental improvement; it's a paradigm shift that enables real-time, trustless and decentralised reactions without relying on external systems: ```mermaid sequenceDiagram participant User participant Blockchain as Somnia Blockchain participant EventLog participant Handler as Event Handler User->>Blockchain: Transaction Blockchain->>EventLog: Event Emitted EventLog->>Handler: Trigger Handler Handler->>Handler: Execute Reaction Logic Note over Blockchain: ✅ Same block execution Note over Handler: ✅ Decentralized & trustless Note over Handler: ✅ MEV-resistant ``` ## The Benefits Once an event is defined, it's handling is happening automatically by blockchain nodes: * **Real-Time**: Reaction included in the same block. * **Decentralised**: As decentralised as the blockchain itself. * **Trustlessness**: No trusted party required. * **MEV**: Fully MEV-resistant due to deterministic inclusion of event handlers * **Developer-Friendly**: Familiar paradigms (e.g., subscriptions akin to event listeners in traditional programming) and interface reduce complexity. * **Cost Efficiency**: Optimized gas usage minimize expenses compared to infrastucture required for constant off-chain monitoring. * **Security and Resilience**: Backed by the blockchain itself. Reduces attack surfaces by eliminating external dependencies; nested events allow complex chains without intermediaries. * **Scalability**: Supports high-throughput apps, as seen in Somnia's 1M+ TPS capability, making it ideal for mass-adoption scenarios. *** ### Comparison Table | Aspect | Traditional RPC | Indexer/Hooks | Somnia Reactivity | | -------------------- | --------------- | ------------------- | ------------------- | | **Timing** | Next block | Next block | Same block | | **Decentralization** | Developer infra | Centralized service | Fully decentralized | | **Trust Model** | Self-hosted | Trusted third party | Trustless | | **MEV Resistance** | ❌ | ❌ | ✅ | | **Infrastructure** | High complexity | Medium complexity | Zero external infra | | **Reliability** | Self-managed | Service-dependent | Blockchain-native | # Overview The Somnia token (SOMI) is the Native token of the Somnia blockchain, with a fixed supply of 1,000,000,000 tokens. ## Token Utility SOMI is a delegated proof of stake token (dPoS) it is intended for: * Staking functions * Validator staking - To provide validator nodes for the Somnia blockchain, Tokens must be staked. * Delegated staking - Tokens can be delegated to Node Providers to cover their staking costs. * Payment methods * Gas Fees - To use the blockchain, gas fees will be paid in the SOMI token. * Governance: The Token will eventually be used to inform how decisions regarding the Network and its components are made. The details of this are to be determined. # Token Staking and Delegation There are four main entities that play a part in the tokenomics of the Network: Application Owners, Validators, Content Creators and Token Holders. Validators are required to time-lock a fixed amount of Tokens at a designated blockchain address in order to secure their place on the Somnia Network/provide validator nodes as described in the Staking section below. Token Holders can choose to participate in staking, in order to receive rewards from the Fees and/or from the Treasury. These rewards are only available to “staked” Tokens and not to Tokens generally held by Token Holders. This section explores the staking and delegation options under discussion with the Network. ## Staking: Validators * In the Somnia Blockchain, validators must stake Tokens to provide nodes for computation to the network. * Validators must provide a certain level of hardware in order to participate in the network. * The amount of Tokens required to provide a validation node is 5,000,000 SOMI Tokens. * They will be rewarded from gas fees and treasury-based incentives. When Validators cover their staking requirement fully, they earn 100% of the rewards that their service generates. However, Validators can also choose to only partially cover their locking requirements. In this scenario, Validators can delegate the provision of the remaining Token requirement to third-party Token Holders. These third-party Token Holders will be given a percentage of the validator's rewards. This is set by the validator (the delegation rate). Validators can choose to delegate part of the Tokens they are required to fulfill their locking requirements into either the General Validator Pool, or into a Validator-Specific Pool. ### **Delegated Staking Specific Pool: Validators** * Validators can choose to enable the Tokens required to provide a specific Validator’s node to other Token Holders. * Token holders can choose to provide their Tokens to Validators in exchange for a percentage share of the validator's rewards. * The validator sets this percentage called the delegation rate. * When providing their Tokens to Validators, Token Holders must wait 28 days before unstaking, essentially locking their Tokens. * They can choose to emergency unstake at the cost of 50% of their staked Tokens. The forfeited Tokens will then flow back to the Treasury. ### **Delegated Staking General Pool: Validators** * Token Holders can choose to delegate to the general Validator pool. * This will allocate their Tokens to all validators currently offering delegated staking. * The Token Holders will receive a percentage of rewards across all Validators. * This spreads the risk of delegation at the cost of potentially less yield. * When staking in the general pool there is no locking period. * The general pool will cover understaked validators first. **What if a validator can’t meet the minimum staking requirements?** In the event that a validator fails to meet the minimum staking requirements, a cooldown period will be provided to the validator to fulfil the staking obligations, typically lasting for one month. **What if a validator has more tokens staked than needed?** Through the general pool and the delegation mechanism, it is possible for a validator to overstake. This means that more Tokens are staked than are required to operate the validator being supplied to the network. In this case, it means there is no time lock to unlock such additional Tokens for that validator. Any user can instantly unlock until the required level of Tokens is reached. As a result of this, the reward split will be further diluted but at the benefit of increased liquidity. ## **Staking rewards** * Gas fees that are not burned are distributed to validators as rewards. The burn share is currently 5% on mainnet (50% on testnet), so validators receive 95% of all mainnet gas fees. See [Fee distribution](/concepts/tokenomics/gas-fees#fee-distribution). * Validators can offer to share these rewards with delegated stakers. * They do this by setting a delegation rate percentage * Example * Validator has a delegation rate of 80% * The validator gets 100 SOMI in rewards for the Epoch * You are delegating 1M out of the 5M tokens delegated to the validator. This means you have a staking ratio of 0.2 (20%) * The formula to calulate your rewards for the epoch is: $$ epoch rewards \* delegation rate \* staking ratio $$ so in this case: $$ 100 (epoch rewards) \* 0.8 (delegation rate) \* 0.2 (staking ratio) = 16 tokens $$ # Gas Fees Every transaction on Somnia pays a fee in SOMI (STT on testnet). Fees price the resources a trans