Core Concepts and Architecture
1. Data Access and Permissions
Q. How are permissions and roles managed between the Data Index, Data Object, and Data Point Registry contracts? Is there a specific hierarchy or flow of authorization I need to follow?
On the top of the access hierarchy, we have Data Points, which are used to identify the data being accessed. With our proposed implementation of the Data Point Registry, each Data Point has its owner (initial creator or someone to whom ownership is transferred) and admins. Data Point admins are allowed to approve Data Managers to access the Data Point (this is ensured by the Data Index) and, additionally, can switch Data Objects between Data Index implementations.
2. Initialization and Setup
Q. During initialization, which parameters are critical to ensure proper linkage between Data Points, Data Objects, and Data Index?
Data Points are used to link Data Managers, Data Objects, and Data Index together. During initialization, the Data Manager should be approved to use a specific Data Point within a Data Index implementation. The address of that implementation should be stored in the Data Manager so that it knows which contract to call to access the data. Also, the Data Object should be configured to use this Data Index implementation for the Data Point.
Q. What's the expected sequence of deploying these contracts? Should Data Points be allocated first, or can Data Managers be set up before Data Points exist?
The first step is always the Data Point allocation. After that, the Data Object should be deployed (if it does not yet exist) and configured to use the selected Data Index implementation for the Data Point. Then the Data Manager can be deployed, and the Data Index implementation should be configured to allow this Data Manager to access the Data Point.
3. Data Point Management
Q. What are the best practices for creating, allocating, and transferring ownership of Data Points? Is there a risk of a Data Point becoming orphaned or unmanageable if not handled correctly?
The best practices depend on the use case. For most cases, the allocation of Data Points can be performed through a public and generic Data Point Registry: public because you may want to simplify your architecture by reusing someone else's Data Point Registry, and generic because of the recommended internal structure of the Data Point. For advanced use cases or ecosystems, it may be justified to build a custom Data Point internal structure and deploy a Data Point Registry specifically for the use case.
Q. How does the Data Point Registry handle counter overflows or potential reentrancy attacks when managing multiple Data Points?
Our implementation of the Data Point Registry has a limit of about 4M (uint32.max) Data Points. However, our architecture allows us to have as many registries as needed, and they will all work together. So when we approach the limit, we can deploy a new registry. Also, if a project needs multiple Data Points, we encourage them to deploy their own Data Point Registry instance.