SOM1

By integrating concepts from blockchain technology and game design architecture, the SOM1 Protocol allows for the creation of composable and interoperable virtual worlds.

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

It 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 these 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.

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:

   

   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
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.

Diagram showing Entity made up of components

Example code of IComponent interface which all components would implement

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

An example component definition that adds a counter to any entity that anybody can increment. Note the ‘_entity’ arguments

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 a wearable / equipable gadget which is quite different to something spawned on the ground. We’d likely define some base semantic categories that Entities can be, which will aid in game environments understanding in what context to use them, and how to spawn them in the world.

Practical Applications

The SOM1 Protocol can support a wide range of applications, from entertainment and gaming to education and virtual workspaces. Here are a few examples:

1. Moderation and Classification: The protocol can apply moderation and classification to each entity within the virtual world. Different providers using various methods like AI or peer-to-peer human classification can enforce moderation. Virtual experiences can then mandate the existence of a moderation component for any entity loaded into their world.

2. Autonomous Objects: Objects within SOM1 can have their addresses, making them "autonomous objects". These objects can interact in the virtual world just like any other user, opening the way for new interactive possibilities.

3. Dynamic NFTs: By extending existing NFTs the SOM1 protocol could enable them to have dynamically updatable metadata. This would allow the NFT to change over time giving in new characteristics and rarity. Imagine a tradable creature that evolves as a player uses it in an experience.

The SOM1 Protocol brings the principles of blockchain and game design architecture together, enabling the creation of highly composable, interactive, and moddable virtual worlds.