Photo by Clint Adair on Unsplash

Intro. The need for accounts metadata

“Metadata” sounds quite mysterious and certainly obscure. Why do we need it at all? Stellar works quite well as-is, so why should we try to invent this strange conceptual something something?

Well, Stellar is more than just a network of connected nodes with ledger history, and accounts are not just some entries on the ledger, they may represent user wallets, trading accounts, multisig agreements, smart contracts, utility tokens, even property/business ownership. So an account is actually an abstraction of some real-life entity or process (in case of smart contracts).

Applications need the ability to add custom records to the account containing the application-specific metadata. Things like delegated signing and multi-signature notifications protocol require attaching custom information to the account. Moreover, interoperability between different Stellar-based applications lacks a uniform standard for data storage.

This post sums up a few community proposals for defining a unified standard of dealing with account metadata.

What about Data Entries?

Stellar has a built-in Data Entries feature that allows attaching arbitrary data to the account. Developers can use it to store any amount of data, so why just not build things on top of it?

To tell the truth, there are more than a few problems. Of course, at this point you probably suspect that something is not right with the existing solution, otherwise this post would be MUCH shorter. So why Data Entry approach is a no go?

Data chunks are limited to 128 bytes per chunk: 64 bytes for a key and 64 more for a binary value.

It’s expensive for end-users to add the data to the account as each data entry requires locking base reserve (currently 0.5 XLM).

Only one data entry can be added per operation, resulting in huge transactions for multi-property updates. Custom serialization format is required if the value doesn’t fit in 128 bytes.

Finally, it’s very expensive for validators. Every data manipulation is stored on-chain forever. Even if the data entry removed, it’s still there.

You may think that ~128 bytes per operation don’t seem so much to bother. But let’s imagine, say, a game app with 1000 users that updates data entries every minute. It will generate more than 5GB of data on the blockchain during a month. The transactions wrapping those data manipulation will result in another 5GB. And from now and forever every single validator ingesting the whole ledger will process those gigabytes of temporary and long gone data.

Personally, I believe that Data Entries should be deprecated. Jeremy Rubin composed a nice explanation on “data entries vs off-chain data” here.

Requirements

Ok, let’s try to gather requirements for a service that could replace Data Entries.