Inspiration

  1. In order to provide services on-chain, DApps often utilize data markets(such as Sports API). The process of moving data from off to on chain requires a relayer. This part of the process is always exposed to the risk of manipulation and distortion.

  2. Traditionally, Dapp data is not compatible with different chains, meaning that the data held on one chain will not be able to be used in a different chain. For example, in the case of a web3 game, an EOA (User) will not be able to save his data on one chain and keep using it on a different chain. If a new chain is made, the EOA will have to restart his progress on the game.

To solve the above two problems in a decentralized way, we decided to develop Debounce, a database-specific sidechain, which also serves as a data marketplace.

What it does

We developed a demo DApp to express the main idea of the debounce network: a database-specific feature(context store) and a data marketplace (crypto news feed).

The context store scenario is as follows.

  1. The demo contract currently exists on the service-chains (Aurora, Aurora testnet, Polygon network).
  2. User connects to their desired chain and signs a message.
  3. Demo contract does not store any data on service-chains and only triggers events.
  4. The event catcher detects the event, parses, and stores the messages in the data contract of the debounce network.
  5. Since the DApp on the service chain refers to the data in debounce’s data contract, users are able to maintain their data even when they switch chains.

The marketplace scenario is as follows.

  1. Suppose there is a data provider(seller) that wants to provide a crypto news feed on-chain.
  2. The Provider stores the news data on the debounce network
  3. DApps (buyers) who want to use this data can use it for their own services according to the provider's pricing policy (free or paid).

How we built it

architecture

This demo consists of three parts.

1. Debounce Network

  • Context Store & Data MarketPlace
  • Ethereum-compatible sidechain
  • IBFT(Istanbul Byzantine Fault Tolerant) consensus mechanism
  • PoA (Proof of Authority)
  • Supports communication with multiple blockchain networks (starting with Aurora)

2. OpenZeppelin Defender (used for this demo and depends on the DApp)

  • Event Catcher from contracts on the service chains. (using Defender Sentinel)
  • Message Parser and Data Provider (using Defender Autotask)

3. Demo Contract

  • Service Chain(Aurora, Aurora Testnet, Polygon) Side: Triggers only events containing messages from users and does not store any data.
  • Debounce Network Side: Stores the event data generated from the service chain.

Challenges we ran into

During the hackathon preparation period, we analyzed several mainnet source codes, and it was a big challenge to learn new development frameworks and programming languages in a short amount of time. We worked hard to implement the alpha version of debounce to express our ideas. Debounce is still in the development stage, and we will continue to improve it.

Accomplishments that we're proud of

  • Built the prototype of the Debounce Network
  • Developed a Demo DApp

What we learned

  • Learned about the composition of the mainnet chains and the role of modules.(And applied them to Debounce)
  • Learned that there is definitely a demand for an on-chain data marketplace and that there are no suitable alternatives yet.

What's next for Debounce Network

  • Tokenomics: We will design tokenomics that can motivate data consumers and providers so that all of our ideas work well.

  • Testnet: We will work on improving Debounce’s performance, especially on the data storage side. We will also release the testnet in the near future.

  • Partnership: As a marketplace, we will strive to establish partnerships with various data providers.

Built With

Share this project:

Updates