ERC-7208: On-chain Data Container

ERCs
, , , ,
1

UPDATE July 2024:

  • Moving to “In Review”

The latest version of the ERC can be found here: ERC-7208: On-Chain Data Container

/******************* About This ERC ********************************/
Hello Magicians,
Today we are excited to introduce ERC-7208, a set of interfaces that we call the On-Chain Adapters:

  • DataIndex (DI) → indexes information and approvals of DataManagers to DataPoints through DataObjects
  • DataManager (DM) → interfaces with user, implements business logic or “high-level” data management
  • DataObject (DO) → logic implementing "low-level data management
  • DataPoint (DP) → indexed low-level data storage (bytes32)
  • DataPoint Registry (DPR) → defines a space of data point compatibility/access management

Abstract

“On-chain Data Containers” (ODCs) are a series of interfaces used for indexing and managing data in Smart Contracts called “Data Object” (DO). Information stored in Data Objects can be accessed and modified by implementing smart contracts called “Data Manager” (DM). This ERC defines a series of interfaces for the separation of the storage of data from the implementation of the logic functions that govern such data. We introduce the interfaces for access management through “Data Index” (DI) implementations, the structures associated with “Data Points” (DP) for abstracting storage, the Data Managers to access or modify the data, and finally the “Data Point Registries” (DPR) interfaces for compatibility that enable data portability (horizontal mobility) between different implementations of this ERC.

Motivation

As the Ethereum ecosystem grows, so does the demand for on-chain functionalities. The market encourages a desire for broader adoption through more complex systems and there is a constant need for improved efficiency. We have seen times where the market hype has driven an explosion of new standard token proposals. While each standard serves its purpose, most often requires more flexibility to manage interoperability with other standards.

While the diversity of standards spurs innovation, different projects will implement their bespoke solutions for interoperability, resulting in a highly fragmented landscape. The lack of a unified mechanism for adapting interaction between assets issued through different ERC standards is accentuating interoperability issues that lead to fragmentation.

We recognize there is no “one size fits all” solution to solve the standardization and interoperability challenges. Most assets - Fungible, Non-Fungible, Digital Twins, Real-world Assets, DePin, etc - have multiple mechanisms for representing them as on-chain tokens, using different standard interfaces. However, for those assets to be exchanged, traded, or interacted with, protocols must implement compatibility with those standards before accessing and modifying the on-chain data. Moreover, the immutability of smart contracts plays a role in future-proofing their implementations by supporting new tokenization standards. A collaborative effort must enable interaction between assets tokenized under different standards. The current ERC provides the tools for developing such on-chain adapters.

We aim to abstract the on-chain data handling from both the logical implementation and the ERC interfaces exposing the underlying data. This ERC proposes a series of interfaces for storing and accessing data on-chain, codifying the underlying assets as generic “Data Points” that may be associated with multiple interoperable and even concurrent ERC interfaces. This proposal is designed to work by coexisting with previous and future token standards, providing a flexible, efficient, and coherent mechanism to manage asset interoperability.

  • Data Abstraction: We propose a standardized interface for enabling developers to separate the data storage code from the underlying token utility logic, reducing the need for supporting and implementing multiple inherited -and often clashing- interfaces to achieve asset compatibility. The data (and therefore the assets) can be stored independently of the logic that governs such data.

  • Standard Neutrality: A neutral approach must enable the underlying data of any tokenized asset to transition seamlessly between different token standards. This will significantly improve interoperability among different standards, reducing fragmentation in the landscape. Our proposal aims to separate the storage of data representing an underlying asset from the standard interface used for representing the token.

  • Consistent Interface: A uniform interface of primitive functions abstracts the data storage from the use case, irrespective of the underlying token’s standard or the interface used for exposing such data. Both data as well as metadata can be stored on-chain, and exposed through the same functions.

  • Data Portability: We provide a mechanism for the Horizontal Mobility of data between implementations of this standard, incentivizing the implementation of interoperable solutions and standard adapters.

While we are working on a few reference implementations, this standard is moving to “IN REVIEW” and will likely be amended with the community’s input. We’re eager to hear your thoughts and feedback on this technology. Your insights will be invaluable in refining this standard!

We are looking forward to a lively and insightful discussion!

39 Likes
7

BOSS moves. Confidence in this team only growing. No mercy.

3 Likes
9

Great breakdown and technical overview of the overall vision of the AllianceBlock project, very exciting to see it at this stage :pray:

7 Likes
10

Amazing work the #NXRA team is doing!

5 Likes
11

Man! this provides a comprehensive and insightful overview of ERC-7208 , particularly highlighting the innovative approach of On-Chain Data Containers (ODC) in enhancing data management and interoperability across various token standards. I think tht its impressive how this delves into the technicalities while also considering practical use cases like the tokenization of real-world assets. RWA needs this in my opinion.

I’m curious about the potential impact of ERC-7208 on the broader Ethereum ecosystem. how might the introduction of ERC-7208 and its On-Chain Data Containers influence the development and deployment of decentralized applications (DApps), particularly in terms of scalability and user experience?

14 Likes
12

…a comprehensive and well-thought-out proposal! The concept of On-Chain Data Containers (ODCs) and ERC-7208’s focus on standardization and interoperability make a lot of sense, especially in a rapidly evolving Ethereum ecosystem with a constant influx of ERC proposals.

I appreciate the attention to detail, especially the abstraction of logic from storage, the versatility of Properties, and the role of Property Managers. The use case examples, like the luxury car rental scenario, add practical context to how ERC-7208 can streamline complex interactions.

The approach to expose Properties as procedurally generated Metadata JSON on-chain is a smart move, addressing the limitation of off-chain metadata storage. The variety of Property Managers, such as Identity and Rules Engine, showcase the flexibility and extensibility of the proposed standard.

…examples of real-world asset tokenisation using ODCs and the default implementation with added features demonstrate a thoughtful consideration for efficiency, scalability, and compliance. Overall, ERC-7208 seems like a promising step towards a more cohesive and adaptable on-chain data management solution. Kudos to the team!

12 Likes
13

Love how projects keep innovating, the RWAs sector is critical to DeFi.

7 Likes
14

Very informative read on ODC’s. Thanks for giving insight on the topic. Love to see this as the new standard!

8 Likes
15

Unlocking seamless interoperability, abstraction of logic from storage, and empowering dynamic tokenization scenarios. Innovation in the Ethereum ecosystem always exciting :raised_hands:

7 Likes
16

A great read, thanks for the informative information.

3 Likes
17

I too think that this is not necessarily restricted to real-world asset tokenization. it could enable some wider-reaching applications.

A good example would be digital asset tokenization in on-chain gaming applications. Think of a character or avatar as an ODC with the PMs managing all the various abilities, powers, or assets of that avatar. I also wonder if the generated JSON metadata could be harnessed to render certain assets in digital space and thus removing the need to store assets in centralized cloud storage.

10 Likes
18

This is very smart. No mercy!

2 Likes
19

ODC can replace a wallets of all sorts eventually, can it?

3 Likes
20

As someone who talks with a lot of companies that are looking into RWA tokenization, I can safely say that ODCs are much needed and will open op a wide range of new business opportunities to the Ethereum community and beyond. From a professional and business perspective, I see this as the next much needed evolution of NFTs. I have explored ODCs with businesses from different industries, from creative businesses looking into creative NFT use cases, all the way to dynamic licensing companies, real-estate and carbon credit projects.

All these businesses have one thing in common, they want this!

As I am personally very biased, in favour of this proposal. I would also like to hear from the community what potential ‘drawbacks’ could be. In what scenario would you prefer a different standard instead of this one? And when would you use ERC-7208?

8 Likes
21

How does ERC-7208 ensure compatibility and interoperability with existing ERC standards, particularly those that are widely adopted in the Ethereum ecosystem? Can you provide examples of how ERC-7208 would enhance or integrate with popular standards like ERC-20 or ERC-721?

5 Likes
22

Could you elaborate on specific real-world use cases where ERC-7208 would be particularly advantageous? How does this standard address the challenges faced in these scenarios more effectively than existing solutions?

5 Likes
23

Exactly like Jaws says: the concept of the Metadata being a composition of on-chain Properties provides not just backwards compatibility with previous NFT use cases where you would just store the uri as a string Property, but also for new use cases that require the Metadata to be updated “in real time”, like in videogames

7 Likes
24

I have some Scalability Concerns… How does ERC-7208 plan to manage scalability challenges associated with storing large volumes of mutable data on-chain, especially in light of Ethereum’s current limitations in terms of block size and gas fees?

6 Likes
25

How does in ERC-7208 propose the efficient on-chain data retrieval, especially when dealing with complex data structures and large data sets?

4 Likes
26

Hey Andy! Thanks for the question… Most tokens that follow a standard like the ones you mention have the storage integrated within the same interface as the functions that govern the logic for how to manage that storage. We see this as a limitation, where the logic and storage are bound to one another by the standard itself.

This ERC standardizes the interfaces that abstract the implementation from the storage. To give you a clear example:
Let’s say you have 100 DAI on your account. This value is stored on a mapping within the ERC-20 contract, and you modify or access it by using the other functions listed on the standard (transfer(), balanceOf(), etc)

Now, in this scenario the assets are represented by a uint number, associated with your account. Your account has 100 DAI, whenever this storage says you do.

What we propose, is that the functions that modify this storage can be abstracted away from the data. For instance, you keep the storage on one contract and apply the logic on a different contract.

Back to the question: how does this work in ERC-7208? You can have Properties with storage values within the ODC contract, and you can have Property Manager contracts that implement the logic. Why is this a desired thing? Because by separating the logic, you get more versatility, at the cost of a delegate or delegateCall. Example of this would be: we can store a Property with value uint= 100 for your address, and then this Property is managed by two different Property Managers contracts, each of them implemented with a different interface. i.e. ERC-1155 and ERC-20. This is a theoretical scenario, of course… but it would mean that you both simultaneously own an NFT (1155) and 100 of an ERC20 token. Each Property Manager works as its own token contract, it just delegates the storage to the ODC.

Hope this makes things clear(er)

9 Likes