ODC Architecture

The new On-chain Data Containers architecture proposes the development of modular smart contracts where asset data is separated from the functionality that manages the data. This opens the door to a set of important features:

  • Smart contracts containing the functionality can be upgraded separately through redeployment while retaining the integrity of the data on another smart contract.
  • The data storage of the smart contract can store any data, promoting data portability. This data can be modified/read by another smart contract which acts as a data manager.
  • ERC-7208 enables the dynamic adaptation of tokens. For instance, an ERC-1155 token can be used as an ERC-20 token.

For simplification purposes, all infographics presented below will follow a gradual approach in the presentation of architecture and components.

Below you can find the simplified representation of the ODC architecture, where Data Object acts as a data storage, and Data Manager represents the business logic that interacts with the data stored in the Data Object. In this context, the user must send a transaction and call a specific function of the Data Manager to read or write data to the Data Object:

image

Data Object, Data Index and Data Manager

Besides the direct implementation of two smart contracts, the ODCs provide an access-control layer between the Data Object and the Data Manager. This layer is called Data Index and it controls what Data Managers(addresses) have permissions to read or write data to a Data Object smart contract.

image

There are four entities in the diagram provided above:

  • Data Object – A smart contract that stores the data separately from the business logic.
  • Data Manager – A smart contract that modifies/reads the data stored in the Data Object contract. This contract is responsible for storing the business logic.
  • Data Index – A smart contract that determines what data manager has permissions to modify/read the Data Object smart contract. This is the access-control layer.
  • User – An entity that talks to the Data Manager to modify/read the data from the Data Object contract.

Data Point and Data Registry

The Data Object smart contract has a very useful feature from the standpoint of data storage. Considering that the Data Object can store the asset data, it can be challenging to locate a specific piece of data when a read/write request is made.

ODCs implement a mechanism that allows for the quick location of the desired data in the *Data Object contract - this mechanism is called a Data Point. It represents a unique identifier that is attached to a piece of data, serving as a reference for other smart contracts to retrieve or modify the correct data. In other words, it is simply a pointer to data. Usually, only one data point is used per decentralized application to store data.

The diagram below illustrates the structure of the Data Object smart contract containing Data Points. As you can see, for each piece of data stored in the smart contract, the corresponding reference in the form of a Data Point is attached.

image

The generation and management of data points are conducted by the owner of the dapp via a separate smart contract called the Data Point Registry. When a new data point is generated, the unique identifier must be fed to the Data Manager, so that the business logic would use the correct identifier to save data to the Data Object smart contract.

But in order for the Data Manager to use the newly generated data point to save data to the Data Object a developer must approve the address of the Data Manager in the Data Index smart contract. Also, the data point must be added to the business logic of the Data Manager so that data will be saved correctly:

Below, you can find a diagram highlighting the complete interaction of all elements presented in the architecture:

image

The diagram presented above highlights the following process:

  1. A new Data Point must be generated for the Data Manager. Once generated, a developer must add the Data Point to the Data Manager
  2. Then a developer must approve the Data Manager address in the Data Index, so that the access-control layer would allow read/write operations to the Data Object.
  3. A user interacts with the front-end of the Data Manager smart contract and submits a transaction to call a specific function in the Data Manager.
  4. The Data Manager calls a specific function and forwards the data along with the Data Point to the Data Index.
  5. The Data Index verifies if the Data Manager is allowed to write to the Data Object. If yes, then the Data Index calls the write function in the Data Object.
  6. The Data Object saves the mapping between the data and its corresponding Data Point. Then it returns the result of the operation back to the Data Index.
  7. The Data Index also returns the result of the operation back to the Data Manager.
  8. Based on the updated state of the smart contracts, the corresponding front-end gets updated for the user.

On this page