Consumers require a validated repository to browse the entire universe of time data given the highly distributed nature of consumable time data (timed auctions, timed events, timed rides, etc.). The time data marketplace is a decentralized storefront for time data.
Unlike the hub (centralized) model, where a centralized party organizes the time data and defines interaction rules, the Analog’s time data marketplace is completely decentralized. Sovereign companies (data providers and consumers) can interact and transact with the marketplace via decentralized consensus rules (PoT) and continuum smart contracts.
This prevents monopolistic behaviors that are inherent in centralized data marketplaces, allowing community members to access accurate and verifiable time data in a democratic manner.
Our infrastructure for the marketplace relies on a technology stack that incentivizes users to submit accurate time data and communicate with global nodes in a P2P fashion. The Analog network provides a robust, low-latency, and secure time data delivery and persistence, and at scale, powering the next generation of DApps.
The marketplace has three main stakeholders:
1. Broadcasters (data providers). These are individuals or companies that supply time data to Analog’s time data marketplace. The network employs the trust index score— which measures the consumers’ trust in the broadcaster—to ensure that broadcasters submit valid time data. The network also uses incentivization mechanisms where broadcasters receive ANLOG tokens when consumers buy validated time data.
2. Consumers. These are individuals or organizations that are interested in buying the time data for their off-chain and on-chain DApps. Consumers log into the marketplace and browse time data streams that the network has offered for sale, as one would browse for items on an online storefront. They can then use the validated time data to trigger continuum smart contracts in the Analog ecosystem. For example, Marriott Hotels can use Uber’s validated time data to trigger a continuum contract that automatically checks in its guests, as shown below:
Figure 8: How Marriott can buy and use Uber’s time data from the marketplace.
Consumers must have sufficient ANLOG tokens in their wallets to purchase validated time data from the marketplace.
3. Time nodes (validators). These are entities that validate time data via the PoT consensus protocol to the marketplace. The network rewards time nodes with ANLOG tokens for their efforts.
Design of the Time Data Marketplace
Fair exchange of time data, even between two parties, is impossible without a trusted third party. In our case, the trusted third party is the Analog network which enforces engagement rules between broadcasters and consumers.
As a public, trustless entity, the Analog network consists of immutable, validated transactions that ascertain the source and ownership of the time data being exchanged. However, privacy is a major concern in public chains like Bitcoin and Ethereum because anyone can link random-looking addresses to their real owners.
Even though the Analog network is a public chain, we want to ensure that the time data being traded on the platform does not leak to any other party except the broadcaster and the consumer. In this regard, the Analog network leverages zk-SNARKs to secure the following:
- Privacy of the specification. The source code of the continuum smart contract should not be made public during the deployment and subsequent processes of execution and synchronization.
- Privacy of the state. The internal state of the continuum smart contract can contain sensitive users’ secrets that need to be protected.
- Privacy of the execution process. Once the network invokes the continuum smart contract, the client’s executing process, including the call arguments and return values, should remain hidden from the public view.
We also believe that interoperability is crucial if the Analog network is to fulfill Blockchain’s initial value propositions and attain mass adoption. As a layer-0 protocol, the Analog network facilitates cross-chain and off-chain flow of transactions between the marketplace and other networks seamlessly.
Timegraph API
Businesses are increasingly providing various services over web application programming interfaces (APIs), ranging from offering asset price data to executing traditional transactions. We are also witnessing the same phenomenon with DApps that interact with off-chain data.
The most notable example of this phenomenon is the exponential surge in the value of decentralized finance (DeFi) that has a market capitalization of nearly US$ 100 billion as of December 2021. But DeFi is only the tip of the iceberg, as many DApps require meaningful interactions with real-world data.
Yet, existing APIs are not natively compatible with DApps. They are centralized, costly, and insecure due to their reliance on intermediaries. In the recent past, we have seen decentralized oracle network (DON) solutions emerging to facilitate interaction between DApps and off-chain data.
However, these networks still employ third-party oracles because they cannot operate their own oracle nodes. As such, DONs are still costly and create an additional attack surface. Timegraph API eliminates third parties to meet the strict decentralization and security requirements of web 3.0 APIs.
It is a secure and cost-efficient solution that provides a conventional API service to continuum smart contracts in a fully decentralized manner.
Oracle Problem
Web 3.0 applications (DApps) usually distribute computations and settle outcomes through pre-determined, decentralized consensus rules. The business logic of such applications relies on smart contracts that run on a Blockchain backend, allowing participants to cooperate without the need for mutual trust or trust intermediary.
To enforce the smart contract rules, nodes can only operate on readily available data to the Blockchain and not off-chain data. This phenomenon—also called the “oracle problem”—refers to an idealized agent that can deliver verified off-chain or cross-chain data to the Blockchain. As the name suggests, the oracle problem is an almost impossible solution with various proposed solutions.
The first generation of solutions attempted to solve this problem by posing the question and crowd-sourcing its answer. These solutions involved many steps that could take days and were costly because of the sheer number of transactions that were required to be made. This disqualified them as ideal solutions for real-time transactions such as prediction markets or DeFi.
The second-generation solutions for the oracle problem narrowed their scope to only include factual data that Blockchains could access programmatically. Under these solutions, an oracle node gets integrated between the Blockchain and off-chain data to serve as an automated intermediary between the two.
These solutions are faster, less costly, and have more use cases than crowd-sourced oracles. However, they do not solve the interoperability problem. There are three parties at the core of any interoperability solution: data providers, consumers, and oracles. But the second-generation solutions only define data consumers and oracles without specifying where the data originates from.
Data source-agnostic interoperable solutions have resulted in the following consequences:
- An intermediate layer of opaque, costly, and insecure third-party oracles. This layer could have been superseded by businesses (data providers) operating as oracles themselves.
- An ecosystem with numerous intermediaries that excludes the actual data sources.
Timegraph API Architecture
The Timegraph API is the third-generation-based, Blockchain-native solution that allows businesses and developers to build, monetize, and manage multiple DApps from different chains at scale. The Timegraph API has the following elements:
- It is a cross-chain interface. Multiple off-chain DApps can seamlessly interact with the Analog’s validated time data in a decentralized way.
- It is a decentralized network of first-party oracles. It allows businesses to serve as first-party oracles and access verified time data in a decentralized manner.
- It is a privacy-preserving mechanism for sharing verified time data. The Timegraph API enforces zk-SNARKs within its continuum smart contracts to allow multiple DApps to access verified time data privately.
To achieve the aforementioned elements, the Analog network provides incentivization mechanisms where parties, i.e., broadcasters, consumers, and time nodes, are reconciled through the governance and security structures of $ANLOG token as shown below:
Figure 8: Timegraph API
We have conceived the Analog Timegraph API as a decentralized network of first-party oracles to allow individuals and businesses (broadcasters) to submit time data to the platform in a fully decentralized and Blockchain-native manner. The decentralized governance structure inherent within the API’s infrastructure allows stakeholders to build, manage, and monetize time-based DApps at scale.
The time-dependent DApps use the $ANLOG tokens to gain access to the Timegraph API. $ANLOG token holders (broadcasters and consumers) can stake their coins and participate in governance in a decentralized manner.
To facilitate cross-chain transfer of validated time data from the time data marketplace to off-chain DApps and vice versa, Analog network uses Tesseracts. A Tesseract is essentially a node that connects the Analog network and off-chain DApps, allowing for cross-chain transfer of verified time data, as explained in section 4.0.
With businesses operating their own oracles on the Analog network, it means they would be signing their time data submissions with their private keys. This guarantees that the time data has not been tampered with. Moreover, first-party oracles are private by default, which, when combined with zk-SNARKs, prevents third parties from observing raw data that the network is processing.
