(written by António Pedro Silva)

Intro

As mentioned, we will talk Proof-of-Stake in the context of the LUKSO blockchain, which uses the LYX token to fuel the protocol. However, it’s important to keep in mind that LUKSO is an EVM-compatible blockchain. For that reason, everything in this article also applies to Ethereum.

Like its predecessor Proof-of-Work, Proof-of-Stake is a consensus protocol. It helps a group of people act together and agree on making the same decisions, without previously trusting each other or any central authority. Practically, the goal is to establish one single, acknowledged version of the Blockchain and make sure nobody is cheating on it.

The only trust assumption in Proof-of-Stake is that participants value their LYX and don’t want to lose it.

Validators

Think of one validator as the right to one chair in the consensus parliament (image above). It’s not an entity, and it’s not a computer. You gain the right to this chair by lending 32 LYX to the protocol, and if you behave against the protocol rules, you lose your chair and your money. If you don’t, your chair is yours until you want to quit the political life.

In order to participate (vote) as member of parliament, you need a computer program. The same program can handle many votes at the same time; each vote corresponds to one validator. In other words, one program can manage many chairs in the parliament. This program is called the client, and the machine where it runs is called the node.

By now you might be wondering: what’s in it for me, to make me want to acquire validator chairs? Well, you get paid for your duties in parliament.

When you stake through entities like exchanges & staking pools, you are delegating your stake, and subsequently your vote, to a third party provider who takes care of voting for you. You trust it will always vote in time and according to the rules, so you split the reward with them. Akin to how politics work IRL, right? Most of us are simply too busy with our daily duties and lack the time to be active participants within the political sphere, so we choose the person who (we believe) best reflects our point of view and delegate our voting power as citizens.

The alternative to staking pools is to have a machine running 24/7, and install client software on it to manage your validators. In doing so you would become a node in the LUKSO network!🥇

That can be more profitable in the long run, and it is definitely better for decentralization, but there are risks involved. Keep reading, and you’ll find out.

Apparently, the consensus parliament would work the same way just by having free chairs for everyone and inviting users to freely participate. So why do we need 32 LYX for each validator chair? Because there needs to be something at stake. Otherwise, participants might get lazy or, even worse, maliciously vote for incorrect blocks that would spend or mint money out of thin air.

At this point, remember what the consensus parliament is for: globally deciding the content of the next page of the notebook. In other words, the next block in the blockchain. This includes validating the transactions that go in and accepting that some are postponed to the next block.

Penalties and Slashing

The whole idea behind human-participant networks is that humans will rationally choose whatever option is more profitable to them. For this reason, Proof-of-Stake relies on the fact that it is more profitable to collect rewards (from being a good actor) than to try and cheat the network for a potential “bounty”. If it ever stops being like that, actors will switch to acting maliciously and corrupt the network. All in all, there are no good guys, just strong enough incentives.

In the case of Proof-of-Stake, incentives go both ways: members of parliament get paid for doing their job, and get penalized when they don’t. For example, if a validator you control misses a vote, it gets penalized. The same happens if the vote is not valid. Penalties are small fines that can be easily recovered. They are applied to mistakes that can happen by accident, for example, in the presence of high network latency.

Slashing is a more severe type of penalty, applied when there’s a high likelihood the validator deviated from the rules on purpose.

One such event is called a double attestation, or double vote. It happens when a validator votes twice for different blocks in the same voting round. This behavior is not only extremely dangerous to the protocol, but it can be highly profitable to the offenders if done by a large enough number of validators. That’s why punishment must at least match the potential profit of acting maliciously.

Liquid Staking

Keeping participants’ funds locked inside a ‘safe’ in order to be able to punish them works pretty well, but is economically inefficient. This collateralized approach to consensus creates the threat of a loss, but prevents honest participants from utilizing their money to fuel automated market makers, lending protocols, and other economic activities, that would generate interest.

Liquid staking was created to tackle this issue. A new middleman entered the scene to collect your locked funds and give you a receipt (proof of debt) in return. The idea is that you could redeem this receipt at any time and get your money back. The middleman’s role was taken up by “staking pools”, using smart contracts to seal the pact in a trustless way. In exchange for this service, staking pools keep a small portion of your staking rewards.

Instead of depositing their ETH directly in the Proof-of-Stake protocol, users deposit their ETH with Staking Providers, who then proceed to deposit it within the Proof-of-Stake protocol. Source.

Proofs-of-debt became known as Liquid Staking Derivatives and were represented by tokens, with each Staking Pool issuing its own. For example, LIDO issued stETH in Ethereum. It looks like magic, but in fact, there are risks to it. Liquid Staking might seem like the 7th wonder of Crypto Finance, but the underlying value of the Staking Derivative token can fall apart if the Validators managed by the Staking Pool get slashed.

Summing up

In this article, we presented an overview of the Proof of Stake protocol, and slightly touched on some of its intricacies. Staking can be a very profitable and safe investment and a way to contribute to a decentralized network. If its risks are understood, they can be mitigated, and participants can choose what’s best for them: either staking through a third party provider or setting up their own infrastructure.

Here at DROPPS we’re working hard on developing technological infrastructure for the LUKSO blockchain, so feel free to reach out via Twitter or Discord and let us know how we can help!

Enter LUKSO: mainnet and staking was originally published in DROPPS on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post is part of a series where DROPPS breaks down the meaning of the keywords in the LUKSO website section about Universal Profiles, NFTs and Cultural Currencies.

(written by António Pedro Silva)

This time, we will analyze what’s behind the “Visual” keyword

Intro

Identity in the virtual world evolved from simple username/password pairs to multimedia, interconnected profiles filled with rich context about the human being or entity behind. Most users are not willing to give up this kind of interaction in this new digital era we’re stepping into. That’s why Web3 accounts must preserve the Web2 look and feel, enabling a smoother and less overwhelming transition for non-technical users.

A big part of this look and feel is related to the visual part of one’s identity. It makes us more memorable and more easily recognized. It can be used to make a statement, describe yourself, follow trends, or affirm one’s belonging to a certain tribe (like displaying an NFT you own as your profile picture on social media).

How “Visual” is accomplished on Universal Profiles

Pictures are part of what’s called the metadata of a Universal Profile (UP). They do not belong to the code that gives the UP its functionality and they are not meant to be interpreted by machines. Instead, they describe the UP to the eyes of other human beings.

You might be wandering if pictures are stored on the LUKSO blockchain. They are not. Only a simple reference to them is saved on your UP’s storage. The image itself is stored somewhere on the internet. It can even be saved on a cloud provider like Google Drive because, under normal circumstances, there’s no need for decentralization, as it’s a personal piece of data about yourself.

In order for applications to properly read your profile and be able to present it in an appealing way, it’s important to standardize how data will be saved in the Smart Contract that represents your UP. Imagine every single user had a different way of storing their metadata onto their UP. It would be a nightmare for dApp developers to build a program to navigate all the profiles and extract their respective metadata. For this reason, LUKSO developed standards. Most profiles possess different content, but it should be structured and named the same. It’s like a box of chocolates, where all the chocolates fit into the spaces in the box, but they can have different flavours. The standard that defines the data keys and the structure for Universal Profile metadata is the LSP3 — Universal Profile Metadata.

The way these apps present profiles is just slightly different. Under the hood they all follow the LSP3 standard to fetch information.

Exercise: Retrieving a profile picture manually

Let’s use the Lukso Inspect Tool to retrieve a profile picture manually and, in the process, get a better understanding of the Universal Profile standard. In this example we will stick to the MiauMiau profile above, with address 0x35DdB594d69bF97f5DC66D9112f2D638A0f6a6c7.

1. First of all, let’s go to the standard’s page and look for the data key which corresponds to the Universal Profile Metadata file:

“The value attached to this data key is a JSONURL-encoded value. It represents a reference to a JSON file that describes the Universal Profile MetaData. The file can be stored on a centralized or decentralized storage.”

2. Now we use the Inspect Tool to retrieve the encoded value of the URL where all the juicy information about the profile is written.

The value on the bottom is the encoded URL

3. We can now decode the result and obtain a URL to the file containing the metadata. Select the “LSP2 Coder” tab from the Inspect Tool menu:

Select value type JSON URL and enter the value obtained on step 2:

4. This profile’s metadata file is stored on the IPFS network. We know this because we got an IPFS identifier after decoding. We need to use an IPFS gateway to access the content. In this case, we used LUKSO’s own gateway.

The resulting URL is: https://2eff.lukso.dev/ipfs/QmYFpqkvprFEcHDkpgWSL3NUtvV8JBBFGcm7FjomoVWhgG.

This URL opens window with the text in the file. Some browsers won’t display it in a pretty way so let’s copy that content over to a JSON formatter to make it more readable:

5. Great! You can see all the metadata components here. They are structured nicely according to the LSP3 standard: name, description, tags, and, of course, the profile image. If you look carefully, you will notice there are several. This is because they are stored in different sizes. The responsability to make sure the picture is up-to-date and coherent across sizes lies with the applications with permissions to change the profile’s metadata.

Finally, we repeat the process in step 4 to follow an IPFS identifier and retrieve its content. Let’s choose the image with 340px width, identified by QmYQxnphG8PqJm5N558neVsSvddK2yKtpDqpGHy8FRtn43. The whole URL with the prepended gateway becomes: https://2eff.lukso.dev/ipfs/QmYQxnphG8PqJm5N558neVsSvddK2yKtpDqpGHy8FRtn43

And the result:

A world of possibilities

The idea behind the ERC75 Generic Data Key/Value Store is “standardizing a mapping of data keys to data values to store data dynamically and to have the ability to add or remove data across time without the need to redeploy the contract”.

LSP3 is one of the standards that creates pairs of Data Keys and Values to organize the Profile Metadata part of the Universal Profile’s storage.

Virtually, if it can be put into a file, it can be displayed in your Universal Profile. For example, if, in the near future, profile pictures become obsolote and are replaced by animations, 3D Avatars, or even something more vanguardist, Universal Profiles will continue to provide a solid ground to host your digital self. All that’s needed is to update the standards and add the new data to the profile. No corporations involved, just external protocols acting through the code deployed into the blockchain. Granting the protocol permission to act on your profile is akin to handing over control of a small part of your digital identity. Every change that happens is forever recorded and publicly available on blockchain explorers.

On our next article, we will dive into what makes your Universal Profile ‘smart’. There are mind blowing possibilities for using smart contracts as accounts in the Web3 world and we’ll go through some of them in detail.

Stay tuned and see you on Universal Profiles — Smart!

UNIVERSAL PROFILES — “Visual” was originally published in DROPPS on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post is part of a series where DROPPS breaks down the meaning of the keywords in the LUKSO website section about Universal Profiles, NFTs and Cultural Currencies.

(written by António Pedro Silva)

Intro

Right now you might be thinking: Token Icons? That’s no big deal, I’ve always seen Token Icons on Etherscan or Uniswap. Yet, this is but another centralized magic trick. Web3 platforms conveniently store icons on their servers (like Etherscan does) or get them from someone else’s centralized server (i.e. Uniswap with Trust Wallet’s Asset Repository).

This means that, for the vast majority of projects, there’s no on-chain link between a token contract and the corresponding Metadata, i.e. when it’s represented on platforms such as Etherscan, Uniswap etc. It is ultimately up to a human being to establish this connection.

Deconstructing LUKSO’s technology

The Digital Asset standards on LUKSO include an ERC725Y storage contract, which is a very flexible, extensible and controllable way of storing information in a smart contract.

Notice that the Metadata of the Digital Asset (same as Token) is not set in the contract code and thus its structure is not rigid. Instead, the metadata is added upon deployment, by calling a function named setData() on the ERC725Y storage of the Token contract. The key names and values should follow LUKSO’s standards in order to be correctly displayed on LUKSO-compatible platforms.

Every Token you deploy adhering to LUKSO’s standards will have a Key/Value pair of the following type:

In the example above, the key “LSP4Metadata” has a JSONURL type of value, which means that it links to a JSON file stored somewhere on the web (hopefully a decentralized service).

Walk-through/example:

For those of you who are developers or simply more tech savvy, follow along as we go step-by-step, retrieving the metadata of a Token deployed on LUKSO.

Step 1: Choose the token

Let’s pick the RenaiXance Sneaker. Notice that the platform displays many images and also a short description text.

Step 2: Extract the metadata URL from the Token contract

In order to do this, we’ll use a tool provided by LUKSO that allows us to read ERC725Y storages.

As parameters, we input the Sneakers contract address and select the key we want to retrieve from storage. In this case, the key is the LSP4Metadata key. Notice that the Sneakers asset was distributed in the L14 network, which requires us to change to the L14 settings in the Inspect Tool.

Now that we have our complete JSON URL value, let’s get rid of the hash part and isolate the actual URL we need to fetch the file:

Step 3: Fetch the Metadata file from the extracted URL

The URL we get is prefixed with IPFS which tells us that, in this case, the Token’s metadata file was uploaded to the IPFS network. All we need to do is to access (and submit a request) to an IPFS node to get it to “hand over” the file.

For now, we can use LUKSO’s development node. In the browser’s address bar we type in the node’s address + slash + the URL we just got from the contract: https://2eff.lukso.dev/ipfs/QmVoKAaE3Zmt8XvwGyUydFgDczLrAeYNKMm7QjVqhkiBPX

Which leads us to the above result. Not pretty? To turn this document into a more readable format we use a simple JSON formatter tool:

As you can see, the metadata includes a description, a video (under the “assets” attribute), and a set of images including different sizes for the same image. Naturally, the smaller size can be used for the Token Icon while the bigger size might be used to display the asset on digital galleries!

Conclusion

Having such a degree of flexibility in updating the metadata of a Token might go against the immutability principles of Blockchain purists, but it’s important to keep in mind that this is merely a possibility. Access control will ultimately determine if the metadata is open to change or not. If nothing/nobody has the permissions to change it, then it’s locked forever.

Some might interpret the reliance on external storage networks as a disadvantage. This is mainly for gas-saving purposes, as typical EVM blockchains are not designed to store media, but instead to save sensitive information that requires a consensus to be retrieved.

All in all, LUKSO has clearly come up with the most flexible approach for storing Token metadata within the new creative economy, one where the power of choice is placed in the hands of dApp developers and even users.

Stay with us for our next piece where we’ll delve into the “Visual” aspect of Universal Profile and the ramifications this entails!

LUKSO WEBSITE TAGS — Token icons was originally published in DROPPS on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post is part of a series where DROPPS breaks down the meaning of the keywords in the LUKSO website section about Universal Profiles, NFTs and Cultural Currencies.

(written by António Pedro Silva)

Intro

Bear with us on this unusual approach to an article about LUKSO standards, where we make a parallel between programmable blockchains like LUKSO and the Supercomputers of the 60's.

Before the banalization of the Personal Computer, in the late 1980's, computers were very expensive and only big corporations or universities had access to them. Programmers would share access to the computer, many times by renting the computer room for just enough time to run their programs. These programs were written on punched paper cards, which the programmer would then insert into the machine.

Just like the old super computers of the 60’s, a blockchain like LUKSO or Ethereum can be seen as a super computer: reliable and indestructible but slow, and requested by many people at the same time. This happens because, even though technology is now way faster than in the 60’s, computations in a blockchain network like LUKSO need to be repeated and validated by thousands of nodes in order to achieve so-called “decentralization”. Furthermore, the nodes need tobe in continuous synchronization between themselves, using up bandwidth resources. A blockchain is like a super computer, shattered in pieces and distributed all over the world.

The amount of resources you rent from this super computer is measured in Gas and the price you pay for them is the Gas price. In the past, users paid an hourly rate to the department head at the University. On the blockchain, you enter a free market of people who, just like you, want to use the distributed machine. The fees are paid directly to the network participants (nodes) in the network’s native currency. In the case of LUKSO, the LYX.

The Relay Service

Once you had your punched cards done, anyone could go to the machine room on your behalf and insert them in the machine. Thus, you would be relaying the execution of your programs to another entity, like a friend, a colleague or even a paid service. In the 1960’s there could have been many reasons for that: maybe you didn’t want to stay awake until 2am, when the machine was finally available. Maybe someone found a way to optimize the use of the machine and offered you a better price than the official one. Relay services basically do it for you and charge a fee.

In the blockchain world, think of transactions like punched cards and inserting the cards into the machine like submitting the transactions to the network. There are many reasons why you would want to have someone submitting a transaction for you:

• Gas price optimization: the relayer might be able to get a better gas price than you.
• Schedule the submission of the transaction.
• You might not have the blockchain’s native currency in your account.

We will focus on this last use case, where a user wants to interact with the blockchain but has no Ether (or LYX in the case of LUKSO) to pay for gas fees. This situation is a major brick wall many users hit when they are using a web3 app for the first time, an unexpected issue for most.

The key takeaway here is: the concept of Gas is specific to the underlying technology and should be hidden from the user experience.

A relay service can offer to pay for the gas expenses of the user in return for a payment in fiat currency, or an ERC-20 token, watching adds, whatever. Just plug any business model you would like here.

The gotcha in relay services

Although it all sounds very simple, in practice it is not that simple. In order for many blockchain services to run, their smart contracts need to know the address of the user interacting with them, which they get by checking the sender of the transaction. If the transaction was sent by a relay service, a naive smart contract will mistake the relayer for the original sender and, for example, send the tokens to the relay address instead of the original sender’s one.

To avoid this, smart contracts must be aware that a transaction might come from a relay service. This is exactly what the Key Manager in the set of LUKSO’s Universal Profile contracts does.

Universal Profile’s support for relay services

One of the fundamental pieces of a Universal Profile (UP) smart contract account is the Key Manager. This is a smart contract that is deployed together with the UP and gets bound to it through a very special link: ownership. The Key Manager contract is set as the owner of the Universal Profile upon deployment and thus becomes the only address capable of tapping into the Universal Profile’s core: its key value store and its capability to call a function in another contract.

From this point onwards, every interaction with the UP has to go through the Key Manager, as illustrated in the below diagram, taken from LUKSO’s documentation on the Key Manager standard.

This detour to explain the role of the Key Manager serves to better understand what’s coming next: the Key Manager is the smart contract that is aware of transaction relay services. And since every interaction with the UP has to go through its Key Manager, UPs’ support relay services by extension.

Now that we have all the pieces of the puzzle, let’s put them together. If my Universal Profile is my blockchain account and I can interact with it through a middleman that pays my gas in LYX, then I don’t need to own any LYX to start using dApps on LUKSO.

This is a major breakthrough in the UX of web3 applications.

Even though this problem has been around since the beginning of programmable blockchains, no approach ever set to solve the issue in such a generalized way. By handling relayer logic at the account level, dApps are freed from this burden, which means they have now acquired support for relayed transactions, without changing a single line in their smart contracts.

At DROPPS we are firm believers that smart contract accounts will very soon transform the way we interact with the blockchain. As a suggestion, try them out by installing the LUKSO Browser Extension and head over to lookso.io to see those accounts in action.

Stay tuned for the next article on these series, looking deeper into LUKSO’s core building blocks!

LUKSO WEBSITE TAGS — “Gas-less” transactions was originally published in DROPPS on Medium, where people are continuing the conversation by highlighting and responding to this story.

(written by António Pedro Silva)

This article is part 2 of 2 on NFT 2.0 updatability. You can read part 1 here.

Part 1 recap

The dream

We started part 1 by exposing some of the potential use cases of mutable NFTs, dreaming of what happens to an NFT after you mint it. In many collections, the premise is: holders will get perks, access to cool things, private events, airdrops, a place in the community (aside from token appreciation, of course). However, all of this is happening off-chain. Regardless of how much history there is around the NFT, none gets saved within its on-chain record. An NFT is dead at mint and that’s just sad.

Besides, we might be missing out on a ton of value that could come from each NFT having a unique history, intertwined with the history of all its holders since minting. NFTs could evolve by being taken to conferences, age with time, have a lore that is being written as things are happening to them in the real world. Be promoted, have ranks, have badges, relate to NFTs in the same collection or even different ones, react to blockchain events, and so on. The possiblities are endless.

Part 2

Novel ways are being thought of for chasing this dream of storing and updating metadata, arising as an answer to the requirement of mutability. However, these approaches have two downsides: they rely on storing metadata off-chain and they further increase the complexity of NFTs by making metadata more elaborate. This is natural because they have been designed with a very clear constraint in mind: deployment on Ethereum mainnet, where gas usage is still a major concern.

The likely approach for LUKSO

Another possibility is to store most of the metadata on-chain and keep the big stuff like visual assets off-chain.

LUKSO gives us a great degree of control over who can update metadata in an NFT by having a Key Manager contract as the owner of an LSP8 asset. This means we use the same permissioned system as the one for writing in the Key/Value store of Universal Profiles.

This allows creators to develop interesting updatability models like:

• NFTs that can be updated by other smart contracts (permissions on certain addresses)
• NFTs that can have certain attributes updated while others remain immutable (permissions on specific keys)
• NFTs that can be updated by a specific Universal Profile or EOA (permissions on certain addresses)
• NFTs that can have their metadata expanded or NFTs which are bound to remain the same forever (permission to create new key/value pairs)

There really are no limits to how this technology can be used to control NFT updatability. On-chain metadata is particularly tempting because it becomes available for smart contracts to interact with. We can code the rules that govern the metadata updates on these smart contracts and launch truly fair and decentralized NFTs which evolve with time, but in predictable and well thought out ways.

Smart contracts can’t interact with off-chain metadata because the external world is not accessible from the blockchain, a critical factor to keep in mind when choosing an approach for implementing dynamic metadata.

The control we have over the updatability of metadata when it’s saved off-chain is very limited. “Code is law”, there, does not prevail. What in fact happens when most NFTs have their metadata “updated” is some external entity uploads a new metadata file to decentralized storage and saves the new reference to the file in the NFT contract.

In the end, it always comes down to fees. Updating metadata on-chain can become a nightmare if this operation is continuously happening like it would, for example, in a game. Even storing it the first time can be expensive should the network become widely used.

Leveraging scaling solutions

Lately, scaling solutions like Polygon and Optimism are inviting developers to experiment with saving metadata on-chain. Since moving to off-chain storage was a makeshift solution to deal with prohibitive gas costs, we must now go down a different path for metadata storage - one where we do not incur the risk of creating ever more complex systems. In some cases, it might be better to embrace Layer 2 rollups combined with a key/value store to harvest all the power of a programmable blockchain and bring NFTs into a new kind of blockchain life.

Storing the attributes of an NFT inside its contract makes them:

• Permissionable: using a permission standard like LUKSO’s LSP6 to implement access control for each individual metadata key.
• Programmable: making metadata updatable exclusively through a smart contract and writing the code that governs the updates to said metadata.
• Flexible and Updatable: maintaining a collection’s metadata keys compliant with the latest standards.

The importance of choosing the right tech for your project

Although some projects don’t really need a degree of updatability, they still need reliability and security. That’s the case for static artworks, where the main metadata component (a high resolution image) needs to be deployed to off-chain storage due to its sheer size. In that scenario, it just makes sense to bundle the rest of the metadada with it, such as name, description, and so on.

On the opposite side of the spectrum, games benefit from highly dynamic metadata, updated by the smart contracts that run the game. For this use case, it makes sense to leverage a layer 2 solution to handle the game logic, including metadata updates, while keeping the records of ownership on layer 1.

Example: in a game where you can equip NFT items to boost your character’s stats (imagine World of Warcraft on the blockchain) and these items are upgradeable (you level items to increase the stats they provide), it would make sense to do an item’s upgrades on a layer 2 solution, while using the layer 1 blockchain to maintain the item’s ownership record.

Also, the reason you don’t want to store everything on a layer 2 is exactly the same reason why they are so fast: layer 2 solutions compromise on security and decentralization to achieve increased speeds, so ideally you leave the ownership registry for the main chain.

Conclusion

We do not yet know for sure what NFT 2.0 has in store for us and what new paradigms will emerge from the standards created by LUKSO. One thing is certain: the bigger the part of the metadata that is saved on-chain, the more control and granularity we have over its properties.

For now, the field is open to new ideas and the technology is in place, but few have actually started experimenting with it. If there’s some out-of-the-box idea regarding NFTs you would like to try or share your views on, DM us at DROPPS. We’re here to build the next generation of web3 applications.

LUKSO —“Updatable” metadata (Part 2) was originally published in DROPPS on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post is part of a series where DROPPS breaks down the meaning of the keywords in the LUKSO website section about Universal Profiles, NFTs and Cultural Currencies.

(written by António Pedro Silva)

This time, we will analyze what’s behind “Updatable” metadata, under the NFT 2.0 section.

Intro

In the beginning, NFTs demanded immutable metadata. That’s because their value was in the metadata itself, bound to attributes such as the rarity of a character or the image of an art piece. Thus, IPFS became the standard to store such metadata, as it allowed for tamper-proof NFTs using a technique called content addressing.

However, in order to increase the use cases for digital assets, we should endow some of them with the possibility to evolve, to change. That’s the case for assets that have physical world counterparts, known as phygitals, or characters in a game, or even records that represent physical world entities, such as houses or cars. If we snatch the opportunity, we might want our digital sneakers signed by a famous NBA player. Or our character in a role-playing game might level up. Or we might want to paint our car a different color in real life and keep a matching image in its digital counterpart.

InvenGlobal puts out a great example of mutable NFTS:

“Imagine an old-fashioned baseball trading card. The details on that card are entirely static, representing the player’s stats for the particular season it was issued for. In other words, that baseball trading card is immutable. A hypothetical mutable trading card on the other hand would be able to update its stats on the fly, from one game to the next, tracking the player’s entire career.”

However, a small problem lies in how to do it. Currently, metadata updates are all or nothing: you replace the whole metadata file by a new one. There is no granularity or control in what parts of the metadata are subject to change and what rules govern this change, if any.

Another problem lies in the “who can do it”. Usually, there is a designated owner of an NFT collection, which has the rights to change the metadata, by replacing the link to IPFS. Of course this owner can be a smart contract, representing a DAO or any type of collective, but still, there’s no granularity here either. Only one address is entitled to update the metadata, and the change is done by fully replacing the old file URI with a new one.

New paradigms for storing and displaying NFT metadata

Because the market demands more utility from NFTs, the traditional ERC-721 and ERC-1155 standards are falling short. Modern scalability solutions and blockchains encourage storing more info about the NFT on-chain. On the other hand, the traditional approach of bundling all metadata in a static file and storing it in some decentralized network, like IPFS or Arweave, is becoming obsolete.

Some solutions aim to extend existing standards, others are completely disruptive. The common trait is making the attributes that define an NFT more dynamic and more programmable.

Tableland

Tableland is a decentralized protocol for relational data. It’s not great for storing images or videos off-chain, but it’s much better than IPFS or Arweave to store information that would fit a database table. This is because it works like a database and not like a file storage system. Inserting, reading and modifying data in Tableland works just like regular SQL databases.

The twist that Tableland brings to NFT metadata is making it a database and not a set of files anymore.

Now instead of saving a link to IPFS on the collection contract, you save the link to Tableland and the corresponding query to select all the metadata:

When a platform calls your NFT contract to fetch a link to the metadata, instead of getting a static object in the end of the link with all the metadata written on it, it triggers a database query! This database query will generate the object in real time and finally deliver the file with the metadata.

Tableland has launched its own NFT collection called The Rigs, where they use this technology.

EIP-5185

Another approach to tackle this problem is described on EIP-5185.

The thread was created on June, 2022, to start a discussion on updatable metadata and it sets out with an interesting goal:

“Define a standard way to allow controlled NFT metadata updates, along predefined formulas.”

Basically, it suggests to add a new section to an NFT’s metadata describing what attributes can be updated and what values can they take:

Then, the update is made permanent by registering a link to the update file in the NFT collection contract. The update file could look like this:

By using the rules defined in the updatable section of the metadata, a platform can determine if token 1 from this collection is allowed to “levelUp” and have its description updated. If the update is valid, the new traits are displayed, if not, the platform sticks to the original metadata.

Balancing security and updatability

As we’ve covered in the Intro, different use cases require different degrees of mutability. In order to remove the need for trust, it is necessary to establish rules on how metadata can change or, alternatively, frame these changes through smart contract code, which results in predictable updates.

Regardless of the approach, static metadata is simple and intuitive: a file stored off-chain. Developers in the ecosystem need to be wise and focus on solving the problem without further increasing the complexity. There’s a reason why ERC-20 and ERC-721 are still in use today and that’s because they’re simple and they just work.

Maybe it’s time to say goodbye to our ancestral roots and sacrifice backwards compatibility in order to keep the same pragmatic and simple approach in the new standards we adopt in our ecosystem. That’s why we, at DROPPS, love LUKSO.

Don’t miss part 2 of this article where we’ll dive deeper on how the new standards developed by the LUKSO team may combine with the ones in this article and tackle the problem of NFT updatability.

LUKSO WEBSITE TAGS — “Updatable” metadata (Part 1) was originally published in DROPPS on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post is part of a series where DROPPS breaks down the meaning of the keywords in the LUKSO website section about Universal Profiles, NFTs and Cultural Currencies.

This time, we will analyze what’s behind “Unlimited Metadata”, under the NFT 2.0 section.

The Key/Value store

The concept behind this feature is that asset contracts adhering to LSP7 or LSP8 possess a Key/Value store just like the one in a UP.

Notice that the solidity declaration of the LSP7 & LSP8 interfaces starts precisely by stating that an LSP7 asset incorporates the ERC725Y standard (which means the contract contains a Key/Value store).

Just like in a UP, we can add arbitrary keys and attach them to the store of an NFT. We’re no longer restricted by the metadata written in the code before deployment of the smart contract, like in the ERC721 standard:

Instead, we save all the metadata in the Key/Value store. This variable here called store:

We can, at any time, erase or add new forms of metadata such as a “description”, “tags”, a list of “creators”, whatever comes to mind. However, in order for this metadata to be meaningful across the whole ecosystem, people need to agree on a set of metadata keys that fundamentally describe a digital asset and prepare all dApps to handle and display these keys.

That’s exactly what the LSP4 Digital Asset Metadata standard is set to do.

The beauty of having the keys defined in the standard and not the smart contract code itself is that even if the community comes up with new attributes they deem essential for upcoming NFT collections, already deployed NFTs can simply add to or modify the existing metadata keys in their storage and stay just as relevant and up to date! In other words, staying compliant with the Asset Metadata standard.

On-chain vs Off-chain Storage

A combination of both. Storing data on-chain means that other smart contracts can read and interpret it, leaving room for automation to happen to NFTs, for example, smart contracts that read an NFT’s list of creators and distribute royalties. However, most blockchains are not tailored to store large amounts of data, an act which becomes way too expensive.

Following this rationale, another very important role of the LSP4 standard is to define the format of the metadata that is going to be stored under each key. For example, it makes sense to store the name of an asset as text, directly on-chain, because it is just a very small piece of text. It might also make sense to store the list of creators directly on-chain because it is just a list of addresses, and each address is a fairly small sequence of characters.

However, a 3D model, for example, is far too big to store on-chain and for that reason it needs to be stored somewhere else (somewhere cheaper). What gets stored on the blockchain is a reference (a link to IPFS, for example) to where the 3D model is saved. This is what is meant by “metadata that is always hash referenced wherever it is stored”, when you hover the button on the LUKSO webpage. Usually, the link is saved in the smart contract, together with a proof of what it contains. This is to prevent someone from going unnoticed after sneakily changing the link’s content, pretending an NFT is something that it is not.

In summary, dynamic storage provided by the Key/Value store of the ERC725Y contract and hash referencing metadata stored off-chain are the two key technological features that make NFTs 2.0 metadata “unlimited”.

We hope you’ve this article insightful. On our next piece we’ll be going through “Updatable” metadata and its ramifications.

LUKSO WEBSITE TAGS — Unlimited Metadata was originally published in DROPPS on Medium, where people are continuing the conversation by highlighting and responding to this story.