bitpro가 원문에서 글자만 모은 내용이에요. 표·그림·수식은 빠지거나 깨질 수 있어요. 전체 54쪽 중 43쪽
DPS | Max DPS | Finality |
| ----------- | ----------- | ------- | -------- |
| ETH | 9.19 | 18.38 | 66s |
| Polygon | 47.67 | 95.33 | Variable |
| AVAX | 31.65 | 175.68 | 3.7s |
| BNB | 194.6 | 194.6 | 75s |
These are somewhat similar to real world observed numbers ([taken from Chaininspect](https://chainspect.app/dashboard)). Note that Uniswaps are a more complex user interaction and are composed of many transactions. Thus these numbers will be higher than above.
| Name | Max Recorded TPS | Block Time | Time to finality |
| --------- | ---------------- | ---------- | ---------------- |
| Base | 293 | 2s | 16m |
| BNB Chain | 1731 | 3s | 7.5s |
| Polygon | 429 | 2.22s | 4m 16s |
| Arbitrum | 944 | 0.25s | 16m |
| Ethereum | 62.34 | 12.08 | 16m |
| Optimism | 67.41 | 2s | 16m |
| Avalanche | 92.74 | 2.03s | 0s |
More recent benchmarks look as gas per second.
<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXd4aIfcAxT5HfbxKL_DV2lm3p87K61jbnnU3WY1H47J0h1yyj8aUKiS-zDmk78hR-Z9KuqNAT4ziqTUa9Dybf3LXhTqVBl-J7pF_TPzWhBMGcEGUhoU86S1gsHWEatmoJemJCQjiJAamRlmcgo865Ubwruv?key=Pd6FhcOWiUEbzWyN_-YJmg" alt=""><figcaption></figcaption></figure>
These numbers are taken from [this article](https://www.paradigm.xyz/2024/04/reth-perf). To translate this into DPS, it’s about 6.5 DPS for every 1mg/s. So even the fastest chain on this list has a theoretical limit of 650 DPS (about 3700 TPS).
If you go outside of the EVM ecosystem, you can do a lot better. Note that this TPS is not the same as above, as the tests differ.
| <p><br></p> | TPS | Finality |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- |
| Aptos | 30,000 ([cite](https://aptoslabs.medium.com/previewnet-ensuring-scalability-and-reliability-of-the-aptos-network-48f0d210e8fe)) | 0.9s ([cite](https://twitter.com/Aptos/status/1632801717937922052)) |
| SUI | 11,000 – 297,000 ([cite](https://blog.sui.io/sui-performance-update/)) | 480m/s ([cite](https://blog.sui.io/sui-performance-update/)) |
| Solana | 1608 ([cite](https://chainspect.app/dashboard)) | 12.8s ([cite](https://chainspect.app/dashboard)) |
Aptos and SUI's real-world live tests have not hit these levels yet. These numbers are based on their benchmarks. The Solana numbers differ from those on the Solana webpage as we are using the real-world observed numbers. Using the same methodology as the article above, Solana’s numbers are significantly worse at 273.34 swaps per second.
Despite this performance increase, we believe the EVM is important. There is already a rich ecosystem of developers and content around the EVM. Not being able to access that ecosystem seems like a missed opportunity. These chains had to make that tradeoff to create the needed performance. But what if we could have similar performance on the EVM?
The bottlenecks we see today with approaches on blockchain implemented with the EVM today are:
* **Execution speed** – The rate at which smart contract code can be executed, and block creation can occur.
* **Storage** — Retrieval of storing historical data of a chain. Ethereum [EIP-4844](https://www.eip4844.com/) was a recent upgrade that significantly improved the cost of storage for ETH and other L2s. However, we still need improvements in reading and writing data to blockchains.
* **Bandwidth** — The amount of bandwidth needed to send data between nodes on the network when running at high transaction levels.\ <br>
# Protocols
The Somnia protocols aim to address three key challenges: enabling the free movement of users and assets, facilitating unrestricted commerce, and accelerating the composability of experiences and objects. With this we hope to increase the value of digital assets, increase their commercial viability and enable accelerated development and experimentation for metaverse applications. Collectively, these protocols establish the foundational layer for a collaborative and open content ecosystem.
We currently have 2 major protocols that will be released:
* SOM0 - Enabling interoperability of assets and their commercialization
* SOM1 - Enabling composable virtual assets and experiences
# SOM0
SOM0 is the initial set of protocols Somnia will launch with. These are designed to enable interoperability of people, places and objects and allow for commerce to flow across the Somnia network.
* Object protocol - This protocol enables: (i) Users to create virtual objects that can exist and move between applications that are part of the Network (and to store metadata about these objects); and (ii) where permitted under relevant licensing terms, also allows Users to adapt existing objects, like NFTs, from outside of the Network to enable them to exist and move between applications on the Network, while storing metadata about such objects.
* Attestation protocol - This protocol enables attestations about places, objects, and people made by network participants.
* Marketplace protocol - This protocol provides a global liquidity layer which allows dApp owners and creators to sell objects such as NFTs in any virtual experience that is part of the Network.
SOM0 has adopted a blockchain-agnostic approach. This means that all of the Protocols are compatible with multiple blockchain networks, which we refer to as "omni-chain".
### **Object Protocol**
The Object Protocol enables content creators to both: (i) create new, virtual objects that are compatible with all applications within the Network; and, (ii) subject to underlying licensing arrangements, import existing virtual objects from outside of the Network and adapt them so that they can be used within applications on the Network. Content creators will also be able to store and access metadata about such objects through the Attestation Protocol.
Once originated or adapted for the Object Protocol, the virtual object (for example, an NFT) is capable of being a tradable asset within Virtual Societies on the Network. This is accomplished by creating a record within an on-chain registry contract that is connected to the applicable virtual object. The registry includes a metadata structure that provides crucial information, enabling the experiences within the Network to understand the data assigned to the associated object. It allows for either linking to an existing object or minting a new one, both of which can represent the ownership of the object.
<figure><img src="https://lh7-us.googleusercontent.com/3rvTQX4huLL4q_XtxOuIqQlKweHeeJ9fPvVa6OZPkIhyv1gllU1agFZ2UbML4_NK7NIXdr5hcAG7Pp1IXddS8swCFIhsN0HFJT7Q-rjxT5BkmrEloRoNr5LiQZ5nQUP6U50AjOQUVrZmXDFutdnf_M8" alt=""><figcaption><p>Diagram of linked and manufactured NFT</p></figcaption></figure>
#### **Making the Object Protocol “Omni-chain”**
The Object Protocol handles the registration and management of virtual objects in the Network, allowing application owners to create virtual experiences on various blockchain networks. It ensures that virtual objects from any application in the network can move smoothly between different worlds and applications, no matter where the blockchain originated. This is achieved by indexing the registry across multiple chains through services from ecosystem members, enabling universal access to object details and interoperability across all applications in the Network.
### **Attestation protocol**
Attestations allow network participants to attest to the authenticity of a virtual object by assigning particular properties to identities, places, and objects on the Network. These attestations can then be used by other network participants for any purpose. Examples of attestations and their value include:
* A major brand attesting that a virtual object is an official virtual object (e.g., Nike attesting to say this object is an official Nike virtual shoe). This could then be used by application owners to ensure no counterfeit objects are in their applications.
* A KYC provider attesting that the owner of an identity is over 18 years of age. This could then be used by application owner to ensure that no minors are in their applications.
* Application owners can use the Attestation Protocol to engage a third-party moderation service to moderate all virtual objects that Network Participants wish to bring into that application. The object moderator could attest that an object complies with the application owner’s moderation guidelines to determine whether or not such an object is permitted within the applications. For example, an application owner of a family-focused application could engage a third-party moderator to review virtual objects and confirm that they contain no violent material. The moderator’s attestation could then be used as a filter by the application owner to ensure no violent content in its application.
<figure><img src="https://2122549367-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkYErT9t3BJtpPfejLO6I%2Fuploads%2FtJxkU8ToTbAj8hWNQq2A%2Fimage.png?alt=media&token=70311401-8972-4d41-ac16-0b74b2d6d31f" alt=""><figcaption><p>Diagram of how attestation protocol works</p></figcaption></figure>
#### **Making the Attestation Protocol Omni-chain**
The Attestation Protocol is vital for proving the authenticity and ownership of virtual objects. This registry is also global in nature, using a cross-chain approach to verify and record attestations across all open blockchain networks integrated with the Network. This will ensure that all digital assets, identities, and places on the Network are verifiable, regardless of the blockchain on which they were originated.
### **Marketplace Protocol**
* Each application owner that participates in the Network will be able to sell items within their application, and each content creator within that application will be able to sell their items in the application Owner’s store. Each application owner will be responsible for deploying, operating and maintaining these marketplaces. This includes making a front end (either web-based on in engine), processing payments and other user-facing flows.
* The Marketplace Protocol enables all application owners/content creators to upload their items to an intra-application marketplace, one where digital items from any application can be uploaded and sold in the same place. This will be a “one-stop marketplace” for all items available for sale across all applications that are part of the Network.
* The Marketplace Protocol will be “omni-chain” to allow for global liquidity and NFTs to be sold between two parties on any two supported open blockchain networks.
* Technically, any NFT can be listed for sale in the Marketplace Protocol. However in reality, we expect mostly manufactured virtual objects (i.e., objects created using the Object Protocol) to use it.
It is important to understand that the Marketplace Protocol just provides a platform for this commerce. Applications built on top of this Protocol will determine a ruleset for what can and can’t be sold and the fee structures associated with permitted sales. The Marketplace Protocol only mandates protocol fees and original creator fee’s be upheld.
* In very permissive application, all listed objects on the Marketplace Protocol may be sold in all experiences. With no additional fees.
* In other applications, it may be necessary for the application owner to accept a listing, creating a curated set of items for sale. With a 2% sales fee for the application owner.
* In another application, it may be necessary for the content creator to create a deal directly with the application owner in order to list their object. With a 2% sales fee for the application owner and a further fee for where the virtual object was sold (e.g. a content creator owning an experience selling virtual objects would get 5% of the item’s sale proceeds).
#### **Marketplace Front End Example**
<figure><img src="https://lh7-us.googleusercontent.com/LXu3hcRftztFaG1oHMDQbOPs5cjXyYw_9aST-QzAvV9LJA5dkkw8vW2XklNxgrxLUFlHUwfEPSx6nwN-9AWiCkn9q9oYcDmGyKo7hsod1gvSALLYVWRuHPlxpkBKcOsHg1fUTG0Jwxv5Nz5hJmyqIds" alt=""><figcaption><p>Example marketplace frontend</p></figcaption></figure>
To help application owners create their own marketplace front ends, we have developed a template marketplace front end. This is web-based and allows for all core functionality of a marketplace (listing objects, bidding, buying, etc.). It integrates directly with Web3 wallets for payment and is backed by the Marketplace Protocol.
**Making the Marketplace Protocol Omni-chain**
The suggested approach is to use a LayerZero protocol, which provides a foundational layer for interoperability between different blockchains. This will ensure that all transactions on the marketplace are secure and that all digital assets retain their value and functionality, regardless of the chain they are moved to.
# SOM1
The SOM1 Protocol allows for the creation of composable and interoperable virtual worlds by integrating concepts from blockchain technology and game design architecture.
### **Overview**
Blockchains are a substrate that allow untrusted parties to interact with one another based upon a series of composable rules called “Smart Contracts”. Smart Contracts almost always refer to addresses (either Smart Contracts or external users) and define various rules around how they relate to one another.
\
If you look abstractly, this architecture is in fact quite similar to an Entity-Component-System architecture in-game engine architecture - used for making very composable game worlds.
* Entities → Addresses
* Systems → Smart Contracts
* Components → Data implicit inside Smart Contracts
In order to ensure that what you are doing can truly grow and be extended, we believe the following must be true:
* Anybody can introduce any new “subject” into the world through adding a new address
* Anybody can introduce any new “ruleset” into the world through adding a new smart contract
* Any system is free to introduce any data about any subject
We call this vertical and horizontal composability:
* **Vertical composability** - anybody is able to add new “things” to the world at will, in the form of new addresses
* **Horizontal composability** - anybody is able to add new “systems” to the world, in the form of smart contracts
#### How to stop spam if anybody can do anything?
It’s all about who you listen to. In blockchains you are free to ignore whatever Smart Contract you like - most wallets have dozens of random coins and NFTs airdropped into them that wallet apps automatically ignore for you.
### **SOM1 Foundations**
This section outlines the core concepts of the SOM1 protocol.
1. **Everything is an Entity:** Every participant, whether it's a user or an object, is an Entity represented by an address. This approach gives objects the same degree of importance as users, enabling a more dynamic and interactive virtual world.<br>
2. **Every entity is an address:** Normally users and smart contracts are addresses. In SOM1 to put entities on an equal footing they are all considered an address. To extend an existing NFT to be an object in SOM1 a mapping would need to be created between the NFT and object:<br>
<figure><img src="https://lh7-us.googleusercontent.com/nTmBJKVtQ6CTtooIMrkwFKlfuB2pCo2mdxpFYfXiY_Z6JZBcWTPM-OiM4Y0o47V95_F3dhwp8uYfv1SOb59JRAiEpXSDJcNdtIBUiiexjTSw0frCqVEyopEAvyTst22Q4Dbt1w-BVGH769PXlBuUSQ8" alt=""><figcaption><p>To refer to things that aren’t addresses, like an NFT, you could create an address by deterministically hashing the chain/token address/token id</p></figcaption></figure>
3. **Entities are a set of components:** An Entity is defined by its Components, which are features or functionalities added by different parties. These Components are defined in smart contracts, providing transparency and security.
<figure><img src="https://lh7-us.googleusercontent.com/qgSSBGJndvpSYtdfzyXF_CdwuCUkXv7BuddyBacznbxOG_o8N2nUZal9lOiauYbIiZbAxNGc0kbr5b11eNhI8bG304q2onKjguacUYhUlHodsDydU2TX1f4C-RVOs2BankoZhdgrM3MuZshy1w20bzc" alt=""><figcaption><p>Diagram showing Entity made up of components</p></figcaption></figure>
<figure><img src="https://lh7-us.googleusercontent.com/OB_Lrv4hfgVlGEXmflq-8WCnQYrAp5emIGFNx5phS_4dOnN_PCCFRjCkaS64qx6BrhY6AEhFPUpBAEsPGnOmacoGhrPBHPPZ_ZtiMtto1lj-9M6XNMazzN6KE8d3pfFfYiWMGqoxmDOtqg0b4IAP3Ws" alt=""><figcaption><p>Example code of IComponent interface which all components would implement</p></figcaption></figure>
You may wonder why it is implemented this way, rather than a smart contract for each component instance. Implementing it as one contract per type, rather than one contract per instance drastically reduces the trust surface area - you only need to trust a single contract to trust a whole ruleset, rather than potentially thousands of sub-contracts. This also will considerably save on gas costs, as contracts are O(component types) vs. O(entity count)
4. Component state and actions are defined by \_entity prefix methods
<figure><img src="https://lh7-us.googleusercontent.com/0MNEd_OMXBiRI3C12x5V3wj6poiAx9icKxasWq0ku5lCy11PT2qEkhvDPuRfnwZYpf6RQCtlW-WOtbompmi3FGz_ncP08u1Fb8j6UV6rIWvtXvFTWHNvqwvKzGt7ror5SeEmHFgULWz1Vr5A1wQnPJA" alt=""><figcaption><p>An example component definition that adds a counter to any entity that anybody can increment. Note the ‘_entity’ arguments</p></figcaption></figure>
This pattern will be familiar to anybody who has coded golang, rust, python, C - the \_entity argument to methods functions as a self/this pointer.
By looking at the generated Solidity ABI (a JSON file of the public schema of a smart contract) it’s possible to enumerate:
* All single-argument view methods, which constitute the State of an Entity
* All \_entity prefixed write methods, which constitute the Actions you can take on an Entity via this Component
It’s worth noting that Actions are typical Solidity methods, so could guard their action on being payable, debiting various tokens, etc - this creates the foundation for economic systems, like having to pay a Jukebox to play a track.
### **SOM1 Key Components**
The foundations above are very abstract. In this section we outline some of the potential implementations on top of the protocol. We will be releasing an initial set of these for others to build on.
* **Ownership and Permissions:** SOM1 introduces an Ownership Component that abstracts the different modes of ownership, providing utilities for querying the owner. It can also be extended to a Permissions Component handling different roles fulfilled by an Entity.
* **Name**: Referring to Entities as addresses is cumbersome from a UX perspective, and it’s useful to be able to define unique names for addresses across the network. This could be achieved via respecting existing systems like ENS - and this is certainly doable. However it would be useful for SOM1 to have a very cheap naming system that can be used to name any Entity - be it a user, an object, a component definition, etc
* **NFT metadata:** One of the biggest challenges of composing existing NFTs is that the vast majority of them have their metadata off-chain. The Nft Metadata Component would allow Entities associated with an NFT to have their off-chain metadata written back onto the SOM1 protocol via oracles. This would then let other components compose functionality back on top of this.
* **Component Registries:** The SOM1 Protocol allows the creation of Component Registries. These registries help define a set of Component types relevant to a specific context. This would allow creators to define permissions of who can add to registries and experiences to specify which component sets they understand.
* **Category component:** While Entities can be totally arbitrary, in practice game engines are quite opinionated around what core types of things can be spawned in them. a player is very different to 프로젝트로 돌아가기
