Sky Money Oracle Migration to the new Oracle Architecture by Chronicle Labs
Introduction
TechOps Services has a long history of managing former MakerDAO's Oracle infrastructure in-house. Over time, the Oracle ecosystem evolved and the creators of the Oracle protocol became an independent entity, becoming known as Chronicle Labs. As a result, we transitioned from directly managing the entire Oracle stack to utilizing Chronicle’s services. This shift has brought changes in how the Oracle infrastructure gets administered, affecting the roles and responsibilities within the system.
In this post, we will walk through the modern Oracle infrastructure, detailing how TechOps Services integrates the SKY Protocol with Chronicle and the new workflow for updating Oracle price feeds.
Chronicle Oracle Infrastructure
Chronicle provides a robust Oracle system that enables decentralized price updates through a multi-signature validation process. The system has evolved from simple validator-based price signing to a more complex model that incorporates Schnorr signatures, optimistic updates, and challenge mechanisms to ensure data integrity.
To better understand the structure and flow of Chronicle, the following diagram illustrates its key components and how they interact within the Oracle ecosystem.
At the core of this infrastructure is the process of data collection and validation. It all begins with Validators, which play a crucial role in sourcing, signing, and transmitting accurate price data.
Data Collection by Validators
- Data Acquisition: Validators gather price data for various assets from multiple sources, including both off-chain platforms like Binance and Kraken, and on-chain platforms such as Uniswap and Curve.
- Signing Price Messages: Each Validator signs the collected price data with a timestamp, creating an individual attestation that specifies the asset, its price, and the time of data retrieval.
Multi-Signature Session
- Initiation: Once a sufficient number of Validators have submitted their signed price messages, a Multi-Signature Session is initiated.
- Consensus Building: During the session, Validators share their attestations and collectively determine the median price for the asset.
- Schnorr Signature Generation: Validators collaboratively generate an aggregated Schnorr signature that represents the agreed-upon median price and its corresponding timestamp.
ECDSA Attestation and Optimistic Update
- Attestation: A single Validator creates an attestation using Elliptic Curve Digital Signature Algorithm (ECDSA), affirming the validity of the aggregated Schnorr signature and the associated price data.
- Submission by Relayers: Relayers, which are permissionless entities within the network, obtain the ECDSA attestation along with the Schnorr signature, price, and timestamp. They then submit this information to the Scribe smart contract on the blockchain.
Scribe Smart Contract Processing
- Verification: Upon receiving the submission, the Scribe smart contract verifies the ECDSA attestation to ensure it was signed by a legitimate Validator and that the timestamp is valid.
- Optimistic Update: If the verification is successful, the Scribe contract temporarily accepts the price data as an optimistic update and starts a predefined challenge period of 20 minutes.
Challenge Mechanism
- Monitoring: Challenger Bots continuously monitor the optimistic updates for any discrepancies or inaccuracies.
- Initiating a Challenge: If a Challenger Bot identifies an incorrect or fraudulent optimistic update, it can initiate a challenge by submitting a dispute to the Scribe contract.
- Resolution: The Scribe contract then verifies the underlying Schnorr signature:
- If Invalid: The optimistic update is discarded, the Oracle's state remains unchanged, and the Validator responsible for the invalid attestation will be banned.
- If Valid: The optimistic update is immediately finalized, and the new price data becomes part of the Oracle's official record.
Finalization of Oracle Update
- Challenge Period: If no challenges are raised during the challenge period, the optimistic update is automatically finalized after the 20-minute challenge period expires, and the Oracle's state is updated with the new price data.
- Data Availability: The updated price information is then available for decentralized applications (dApps) and other Smart Contracts to query and utilize within the blockchain ecosystem.
Sky Additional Components
- OSM and MegaPoker: While MegaPoker and OSM (Oracle Security Module) Smart Contracts are not part of Chronicle, TechOps Services still looks after them for Sky. The key change is that OSMs now source their price updates from the Scribe contract instead of the older Medianizer contract.
- Delayed Oracle Updates: The OSM serves as a delay mechanism, meaning that when a new Oracle value is queued up, it does not take effect immediately. Instead, it becomes active only upon the next Oracle update.
This structured process ensures that Chronicle provides decentralized, verifiable, and efficient Oracle services, maintaining data integrity and trustworthiness across blockchain networks.
