🔮Oracle

Oracles play a crucial role in blockchain environments by providing external data to smart contracts, enabling these contracts to interact with real-world information. This document provides guidelines on integrating oracles into the BounceBit Layer 1 blockchain, ensuring that external data feeds are secure, reliable, and timely. We will also use Bracle Network as a specific example to illustrate the integration process.

Types of Oracles

Oracles can be broadly categorized based on their data sources, data flow direction, and degree of centralization:

1. Data Source

  • Software Oracles: Manage online data such as temperatures, flight statuses, and financial market prices.

  • Hardware Oracles: Interface with real-world physical devices like IoT sensors.

2. Direction of Data Flow

  • Inbound Oracles: Deliver external data into smart contracts.

  • Outbound Oracles: Send data from smart contracts to the external world.

3. Centralization

  • Centralized Oracles: Rely on a single data source, presenting a potential point of failure.

  • Decentralized Oracles: Use multiple independent sources to validate data, enhancing reliability and security.

Bracle Network on BounceBit

Bracle Network is a decentralized oracle network designed to provide frequently updated, reliable data feeds to DApps and smart contracts within blockchain ecosystems like BounceBit. It features permissionless access and aggregates data from over 20 sources including both centralized and decentralized exchanges.

For a detailed documentation please refer to Bracle's documentation itself https://docs.bracle.network/

Data Format

At a top level, transferring data to a Blockchain VM environment requires packing an extra payload to a user's transaction and processing the message on-chain.

Data packing (off-chain data encoding)

  1. Relevant data needs to be fetched from the decentralized cache layer, powered by Bracle Network light cache nodes

  2. Data is packed into a message according to the following structure

  1. The package is appended to the original transaction message, signed and submitted to the network

All of the steps are executed automatically by ContractProxy and transparent to the end-user

Data unpacking (on-chain data verification)

  1. The appended data packages are extracted from the msg.data

  2. For each data package we:

    1. Verify if the signature was created by a trusted provider

    2. Validate the timestamp, checking if the information is not obsolete

  3. Then, for each requested data feed we:

    1. Calculate the number of received unique signers

    2. Extract value for each unique signer

    3. Calculate the aggregated value (median by default)

This logic is executed in the on-chain environment and we optimised the execution using a low-level assembly code to reduce gas consumption to the absolute minimum

For details

Last updated