Inter-chain Architecture

Within this post I’d like to share a perspective I have on the world of web3, and hopefully make a point of how all of us can optimally share information and utility on-chain.

Why On-chain?

When information is stored publicly on-chain, it becomes interoperable by default, transparent, composable, and easily ingested into other systems.

For example, if game-play data is stored on-chain, and you use that same wallet in another game, your in-game data can be read by other games, resulting in the opportunity to enrich gaming experiences for the user. We already see this implemented in closed ecosystems such as Steam and EA Play but for each game you need to figure out how to integrate with them, or abide by their ecosystem rules.

In the world of web3, this data is yours and you can choose to share this data with whoever you like. Interoperability is enabled by default.

The Single Chain Perspective

Since the web3 industry is relatively new, there are still many high level patterns absent. When I speak to game developers, they have often adopted a single chain mentality and I hear from them “Chain X has been great to us, so we must use Chain X for everything”.

To challenge this way of thinking, I suggest that data can be divided into two types - Assets and Records, and I encourage us to explore different paths for different types of data.

Some data is very valuable, for example your USDT balance, or your CryptoPunk NFT. This data should be stored on the most decentralised and well established chains, ones that are the most secure such as Ethereum. The idea is simple: store Assets where they are the most prevalent, the most secure, and have been around the longest.

Most applications require more than assets, they also generate important records. Such as "I played 20 hours of this game, have a score of 21000, and currently on level 3". That information is valuable to the gamer directly, but not as valuable to external parties - let’s call these Records. I have met countless developers struggle to deal with this data when stored on-chain, they normally go through the following decision making process:

Option 1 - Storage on the same chain as the Assets This leads to a very expensive, unsustainable future. To create an NFT recording game-play information with 3 values it will cost around $10 to mint on Ethereum. Imagine attempting to do this for hundreds of thousands of users. This can be done in a proof of concept, with 100 users, but it is simply not scalable in a production environment where you have hundreds of thousands of users, each performing many actions which warrant an update to these records.

Option 2 - Storage in a database As databases that maintain in-game records are often private, data becomes opaque and closed off. If we are locking away this data from being publicly accessible then we are remove the ability to advantage of web3 innovations such as composability.

Solution - Interchain Architecture

Once we have classified our data into these two broad categories, it becomes easier to make decisions on what to do with them.

• Assets-related data should be stored on the chain which offers the best mix of security, decentralisation and where value is established.
• Records can be stored on a cost effective chain and in cases where they are frequently updated, a chain without the hindrance of a linear pricing model.

Linear Scaling

Most public chains have a linear scaling model: if you pay $0.10 for a transaction, you will incur that same fee 100 times if you did it 100 times.

Layer 2s

Ethereum based layer 2's are a great solution for scalability, where individual transaction costs are fairly low. Since they are EVM compatible this grants access to the largest blockchain developer base in the world. By building on the foundation of Ethereum, we benefit from it’s decentralised and highly secured nature and provide access to the most active marketplaces.

Non Linear Scaling

There are chains that offer a non-linear pricing structure. These are commonly private solutions which are closed-off and therefore non-interoperable. Having lost the composable aspect that blockchain technology can offer, one might ask how solutions like these differ from a traditional database?

LightLink

This is the reason why we built LightLink, to solve problems such as these. We offer an interoperable EVM compatible chain with non-linear pricing models. Storing records on an expensive layer 1 chain is too costly. However, by surfacing these records on-chain in a cost-effective manner, we believe the network effects will pay dividends in our interoperable future.

Summary

• Transactions and assets can be considered as one of either Assets or Records
• Store assets where they are most secure and are recognised for their worth.
• Store records in a cost-efficient environment, such as a layer 2 chain.
• If possible, it's suitable to store records on a non-linearly cost-based chain, like LightLink, where the economic model has a fixed cost, allowing for predictable pricing.