KLYNTAR Virtual Machines. Part 3: Storage Abstraction

5 min readApr 3, 2024

Intro

Hello dear readers of our blog — researchers, users and everyone interested in Web3.

We continue our series of articles and this time the article is again devoted to virtual machines. We will talk about an improvement called storage abstraction.

We will discuss what it is, why we need it and much more. Enjoy reading!

What is storage abstraction?

Storage abstraction is a new concept in Web3 to improve the decentralized storage of account and smart contract data on the blockchain

The storage abstraction is derived from the account abstraction 2.0, which we talked about in the last article of the series.

This new concept focuses on several points. We will talk about them today:

XVM storage architecture
Low level control of storage
Flexible payment schemes for storage-by-subscription
Blobs control from VM and access to KLY Storage

XVM storage architecture

As you know, KLYNTAR has XVM — a Frankenstein’s monster that includes EVM and WASM — two dominant virtual machines in the crypto industry.

When working with storage, we needed to consider several factors:

1. EVM has its own storage structure
2. WASM allows us to manage data more flexibly because it receives data from the main environment where it is stored (for example, JavaScript, Golang, Rust environment)

In KLYNTAR, within the framework of storage abstraction, it is possible to perform all types of operations on data (RWX — read, write, execute) from any of the virtual machines. For example, you can:

Read data of EVM contract from WASM and vice versa
Change data of smart contracts and simple EOA accounts in EVM from WASM VM and vice versa
Pay for the usage of storage by EVM smart contract, for example, with stablecoins, the contract of which is deployed in WASM. Or vice versa — pay for the storage of a smart contract in WASM, using EVM contract of WBTC, Tether or another asset. More on this later.

Low level control of storage

Low-level data management can be useful in the following areas:

Pre-deployment of the state of the smart contract — instead of bringing the smart contract to the desired state by wasting gas, simply take and send the initial desired state along with the bytecode during deployment
Manual storage modification — XVM will allow you to manually change the state of the smart contract storage. This can be much more efficient than running complex logic
Upgradeable smart contracts — change the code of your smart contracts without complex low-level games, proxy contracts, and so on. We will talk about it in the next articles

Storage by subscription model

To put it simply, this model is designed to allow smart contracts to pay a small amount for using global decentralized storage. This stimulates the economic interest of validators, and also prevents unnecessary and old smart contracts from being stored on the network.

As part of the storage abstraction, we offer these flexible enhancements to the subscription storage model:

Find out details about your storage consumption

Thanks to the API, you can find out exactly who is occupying/consuming the largest share of your contract storage. This will be useful for blockchain explorers, as well as for programmable payment(more on that in next point):

Program custom payment schemes for your contract storage

This is a very useful feature that will allow you to independently determine how exactly the network will charge you for the part of the global storage you use. Here are some use cases possible thanks to it:

1. For smart contract A, payment for storage is withdrawn from the account of another contract B

2. Each user of your smart contract pays own share independently (see previous paragraph)

3. Part of your contract storage will be paid for with native KLY coins, and the other part — for example, with stablecoins or by liquidating a frozen NFT

4. Separate payment for mappings, logs, custom payment policies for smart contracts of different levels. For example, free storage for DEX or some useful marketplaces that already bring validators enough profit in the form of fees

Blobs control from XVM and access to KLY Storage

We’re finally moving on to something BIG.

As you know, decentralized networks (other crypto projects) usually suffer from the fact that storing large data on the blockchain is impossible or very expensive.

In addition, such data is often difficult to manage due to limitations within virtual machines.

Thanks to the storage abstraction, you can manage large data that will be stored off-chain using the KLY Storage service. This is somewhat reminiscent of Filecoin’s FVM implementation

Here are some use cases:

1. You can tell the network to download some large piece of data and store it on X nodes in the form of Y copies for Z days

2. RW(read/write) actions with big data directly from smart-contracts

Summing up

We at the KLY Foundation try to create new and useful innovations for the crypto industry. We hope that storage abstraction will be a frequently used functionality among DApps developers, and we also hope that ordinary users will appreciate it.

We are happy to work for you! Continue to follow us on Twitter, read our blog on Medium, discover new developments on GitHub, and subscribe to our other resources. See you soon!