Introduction

Routescan aims to promote collaboration and open-source development, supporting the blockchain ecosystem with advanced tools and an ideal environment for developers. We believe that providing a dedicated explorer for each blockchain can empower developers by giving them access to a comprehensive set of tools to develop more efficiently on the network itself.

In this spirit, Routescan is committed to contributing to open-source projects that offer significant value to the community, such as the Open Source Observer (OSS). Open-source initiatives are the backbone of innovation and transparency in the blockchain space. By fostering community participation and encouraging contributions, we can maintain an up-to-date, accurate, and comprehensive database of DeFi projects, supporting the broader DeFi community in accessing reliable information.

This article compares the database structure of the Open Source Observer (OSS) with that of Routescan, highlighting how both approaches, despite their differences, provide valuable benefits for blockchain data management. You can find more detailed information about the Routescan database structure here.

1. Open Source Observer: A Database Centered on dApps

The Open Source Observer is a GitHub repository with the ambitious goal of creating an open-source database for all DeFi projects. This initiative invites developers and enthusiasts to contribute by adding missing data, fostering a comprehensive and up-to-date repository for the DeFi ecosystem.

Database Structure

To effectively identify and catalog DeFi projects, OSS has developed a database structure where the key components are the Collections, Projects, and Blockchain Addresses tables.

• Collection: Groups together all projects developed by a single decentralized application (dApp), making it easier to track and manage related projects collectively.

• Project: Represents the core entities within the database, each project reflecting an individual DeFi initiative with specific details and characteristics.

• Blockchain Address: Identifies the unique address and the blockchain on which it resides, crucial for pinpointing the exact location and accessibility of the project within the blockchain network.

Relationships

• Collections and Projects: Each Collection encompasses multiple Projects, allowing for a hierarchical organization where projects related to a specific dApp are grouped together.

• Projects and Blockchain Addresses: Projects have a direct relationship with Blockchain Addresses, specifying which blockchain a project operates on and providing essential details about the addresses involved.

2. Routescan: A Database Centered on Blockchain Entities

Routescan employs a primary database structure built around three key tables. Unlike the approach taken by the Open Source Observer (OSS), Routescan’s database is designed around the concept of entities. This is because, as a block explorer, Routescan prioritizes address and blockchain-specific queries, subsequently linking back to the corresponding decentralized application (dApp) information.

Database Structure

Routescan’s database is centered on the following three tables: Entities, Blockchains, and dApps. This structure enables efficient address-based searches and provides comprehensive information about each entity.

• Entities: The cornerstone of Routescan’s database, tracking individual entities typically identified by their EVM (Ethereum Virtual Machine) address. This table has direct relationships with the Blockchains and dApps tables.

• Blockchains: Contains information about various blockchain networks, essential for identifying which blockchain an entity belongs to.

• dApps: Documents decentralized applications associated with entities, linking entities to their respective dApps and providing additional layers of information.

Relationships and Functionality

• Entities and Blockchains: Each entity has a relationship with a specific blockchain, allowing users to identify the blockchain network to which the entity (address) belongs.

• Entities and dApps: Entities are also linked to dApps, ensuring that any given address can be traced back to its associated decentralized application.

For a detailed understanding of how we structured our database, please read our comprehensive article on Routescan's database setup and its role in managing off-chain data for blockchain activities. Check it out here: Off-Chain Data Management: Insights from Routescan's Database Structure for Labeling.

3. Key Differences from OSS

While the Open Source Observer organizes data around dApps, Routescan takes a fundamentally different approach by focusing on entities. This entity-centric design aligns with Routescan’s function as a block explorer, where the primary objective is to search for and retrieve information based on blockchain addresses.

By structuring the database this way, Routescan facilitates efficient and accurate address-based searches, providing users with detailed information about the blockchain and associated dApps for each entity. This design not only enhances the usability of the block explorer but also ensures that users can quickly access relevant data, improving the overall experience.

Collaborative Synergies between Routescan and Open Source Observer

Although Routescan and the Open Source Observer (OSS) take fundamentally different approaches in their database designs, there are significant areas of collaboration and mutual benefit. A prime example of this synergy is highlighted in the recent pull request, PR 291, which shows how insights from both projects can lead to enhanced data structures and improved functionalities.

PR 291: Introduction of a Dedicated Social Profile Collection in OSS

Before this pull request, the OSS database managed social profiles within the websites field of the project collection. However, this approach presented challenges in terms of clarity, organization, and maintainability.

Key Benefits of the New Social Profile Collection

The knowledge gained from Routescan's experience in structuring data has been instrumental in shaping this new approach. Here are the primary advantages of introducing a dedicated social profile collection:

• Enhanced Clarity and Organization: Moving social profile information into a distinct collection makes the database structure more organized and easier to navigate.

• Standardized Approach: Provides a consistent way to store and access social media links associated with projects.

• Simplified Data Management: Managing and retrieving social media information becomes simpler, enhancing the maintainability and extensibility of the project schema.

4. DB Entities-Centric vs. Dapps-Centric

The OSS structure is optimal for dapp-centric searches but may be suboptimal for detailed entity exploration, future transformations, and how entities are treated by an explorer.

Computational Cost and Lag

Routescan’s entity-centric schema aims to maximize the efficiency of blockchain analysis and exploration. A dapp-centric approach would significantly increase computational costs. For example, a transaction from one entity to another would create a loop in searching for entity information, requiring scanning the "Dapps" table until the entities are found.

Similar Entities

In some contexts, grouping similar entities, such as all stablecoins, can be useful. This is achievable with the OSS structure by adding a "stablecoin" tab for each address. However, more complex cases, like grouping entities representing the same token (e.g., "BTC.b" and "WBTC.e"), would require entity-to-entity relationships, which are difficult to implement in the OSS DB.

Bridge Entities

For bridged entities, such as tokens moving from Chain A to Chain B, adding a tag for a bridged address in OSS is straightforward. However, adding detailed information, such as the source and destination chains, would complicate the structure.

Circulation Supply

Consider a dapp that creates a token with detailed tokenomics, including entities that lock the supply, such as vesting wallets or burn addresses. Associating the token with the vesting address in a dapp-centric model could be challenging.

Example Comparison of DB Structures

Below is a comparison between the OSS and Routescan databases. Since OSS uses YAML files, we approximated the Routescan schema to fit into a YAML format.

From the representation, it's clear that OSS has a more nested structure where dapps encompass addresses. In contrast, Routescan presents three distinct blocks: blockchain, dapps, and entities.

Focusing on entities, they are represented as key-value pairs in Routescan, making address searches highly efficient. In OSS, finding a specific address within a dapp requires iterating through entries.

For similar entities, Routescan allows direct relationships between entities, ensuring efficient searches. Implementing this in OSS might look like this:

oss:
 - name: dapp1
   blockchain:
     - address: "0x1"
       networks:
         - avalanche
       tags:
         - erc20
         - bridge
       name: WBTC
       similar_address:
         - "0x3-dapp1"

While theoretically functional, this approach requires iteration over the dapp to find the specified similar address, leading to inefficiencies.

Handling Complex Features

As more complex features are introduced, practical issues arise. For instance, highlighting a bridged entity in Routescan involves a simple relationship. In OSS, it could be represented as:

oss:
 - name: dapp1
   blockchain:
     - address: "0x1"
       networks:
         - avalanche
       tags:
         - erc20
         - bridge
       name: WBTC
       bridge_to:
         - "0x2-dapp1-ethereum"

This necessitates a concatenated relationship between address-dapp-network, increasing complexity non-linearly with each additional feature.

Conclusion

In this detailed comparison between the database structures of the Open Source Observer (OSS) and Routescan, we have highlighted how each approach caters to different needs within the blockchain ecosystem. Routescan is dedicated to promoting open-source projects that provide significant value to the community, like OSS. We firmly believe that open-source initiatives are the backbone of innovation and transparency in the blockchain space.

Routescan's entity-centric design is particularly effective for blockchain explorers, facilitating efficient and accurate address-based searches. This structure allows for a more detailed and flexible exploration of blockchain data, accommodating various future transformations and use cases such as similar entities grouping, bridge entities, and circulation supply management.

On the other hand, OSS's dapp-centric approach is optimal for projects needing to search and organize data by decentralized applications. This method fosters comprehensive project repositories, ensuring easy access and management of related data within a unified framework.

While there isn't a single best way to manage data labeling, both the Routescan and OSS approaches offer unique strengths. Each method provides valuable benefits, making them excellent options for different aspects of blockchain data management. By leveraging the strengths of both systems, the blockchain community can foster greater innovation, transparency, and efficiency in managing DeFi projects.

Contributing to these open-source repositories not only enhances the quality and accuracy of the data but also supports the broader DeFi community in accessing reliable information. As we continue to refine and expand our capabilities, we are committed to supporting developers, investors, and blockchain enthusiasts in achieving their goals, ultimately driving forward the future of blockchain technology.

For a detailed understanding of how we structured our database, please read our comprehensive article on Routescan's database setup and its role in managing off-chain data for blockchain activities. Check it our here:

OSS GitHub: