Architecture
Platform's Architecture
Last updated
Platform's Architecture
Last updated
The following diagram shows a high-level overview of the platform.
At the heart of the platform lies a set of Layer-1 smart contracts that rule every single process of the system, and store all assets and their history. Any Layer-1 that is EVM-compatible can be used straightforwardly.
In cases where the deployment happens in EVM-compatible beasts such as Polygon, which can be considered a Layer-2, then the Living Assets instance can be considered a Layer-3.
The Living Assets Layer-2 is a set of nodes, relayers, and data-availability services, focused on scaling only the computations required to enable Living Assets, at massive scale, and with properties (present and historical) that can be certified on the Layer-1.
The Layer-2 synchronizes every 15 minutes (a lapse of time that we call one verse), following a fraud-proof pattern, and in a way that allows asynchronous update of assets in different Universes. The gas expenditure is constant and fully absorbed by the Living Assets platform.
The security pattern leveraged from the Layer-1 smart contracts is 1-of-N, meaning that one single honest node is required, in the entire Layer-2, to guarantee its integrity.
The Layer-2 exposes a simple WebAPI to the entire ecosystem. The API exposes:
Read queries for everyone, such as: Living Assets owned by owner, properties of assets at present or at any verse in the past, on-going trades...
Create & Evolve queries that require the signature of the corresponding Universe Owners.
Market / Trading queries that require signatures of the corresponding sellers and buyers.
It shall be stressed again that no gas is spent directly in any of these queries; e.g. 10K assets can be minted in one single atomic API query, which are almost instantaneously seen by all applications.
Most usage of the platform is based on external applications that connect via Web API.
Video games are examples of applications that use the full API potential. Typically, they send all queries from their backends, and these typically include both create & evolve queries depending on what users do in their games, and read queries to show the assets owned by each user (which could have been traded in different markets). Also, those that implement their own market inside the game relay user-signed petitions for trading: put for sale, bid, etc.
On the other end of the spectrum, we find applications that only require read queries, such as Metaverses that just want to allow users to bring their Living Assets, and block explorers that only want to provide info & insights about the marketplaces and other aspects of Living Assets platform.
In between, we find a plethora of options in the ecosystem, from fully branded Marketplaces for trading assets of one specific Universe, to creators Dashboards that facilitate the creation and evolution of Living Assets in beautiful UI/UX codeless workflows.
Finally, users and Dapp developers can permissionlessly access various functionalities of the Layer-1 smart contracts.
Owners can permissionlessly export their assets from the platform. In doing so, assets get frozen to their latest state, and become standard ERC721 in the Layer-1: they can be operated by any marketplace compatible with that Layer-1 (e.g. Opensea if Layer-1 is Polygon or Ethereum), and users pay gas fees (and congest the Layer-1) as usual.
dApp developers can build applications that use smart contract logic based on asset attributes. Simple examples: a Prize Contract that allows anyone to add funds that can only be claimed by, say, anyone who shows up with an asset of video game X, with level 75. Or a Futures Contract where anyone can place bets that certain assets will reach charisma > 30 within the next 2 months.
