USC Architecture Overview

Highest level description of the inner workings of the Creditcoin Oracle and Universal Smart Contracts

Overview

A decentralized oracle is an oracle which at no point relies on a centralized trusted entity for its security. Instead, each step in the oracle’s data provisioning process is executed by a group of independent actors, none of which have the power to unilaterally interfere with data provisioning outcomes. By adding decentralized data provisioning to Creditcoin, we enable it to trustlessly support smart contracts which can access the state of any blockchain. These smart contracts, known as Universal Smart Contracts (USCs), enable the seamless merging of isolated pools of liquidity as well as novel cross chain logic.

Key Terms

• Source chain: A foreign chain for which Creditcoin supports bridging. We begin by supporting EVM chains such as Ethereum, with the goal to enable data provisioning from any chain.

• Execution chain: A Creditcoin blockchain with oracle infrastructure and Universal Smart Contract support.

• Attestation: A consensus report on the progression of the finalized state on a source chain.

• Proof: A STARK proof certifying that parts of a given transaction occurred on a source chain.

We only prove parts of a transaction as transactions can be quite large, involving many smart contract calls and emitted events. STARK proving can get quite expensive for large transactions, so we only prove the parts absolutely necessary to inform execution chain state transitions.

• Query: A request to prove certain fields of a transaction. Each query specifies which source chain, block number, and transaction hash it wants to be proven.

Architecture

The Creditcoin Decentralized Oracle relies on 3 decentralized groups of actors:

Attestors

These make assertions about the latest finalized state of a foreign blockchain (known as source chains) such as Ethereum. We don’t trust any one attestor’s report about changes to the state of a foreign chain: instead, a decentralized group of attestors must come to consensus about what state changes, if any, have occurred.

For more information on attestors, check out the Attestation section of the docs.

Provers

These generate zero knowledge proofs as a response to user submitted queries. Each query request information on parts of a transaction (EX: to, from, value) on a foreign source chain. The prover then processes that query to make those parts of the transaction available on Creditcoin. The prover conducts its work in three steps:

1. First, it uses attestations to prove that the block containing our query transaction is a part of the foreign chain’s state.

2. Second, it uses merkle proofs to show that the block does in fact contain the query transaction.

3. Finally a STARK proof is generated which verifies both of these properties.

For more information on proving, check out the Proving section of the docs.

Validators

These are the authority set of the Creditcoin blockchain. They act as gatekeepers ensuring that the attestors and provers have done their work properly. Validators check attestor signatures on attestations to verify that a sufficient quorum voted before committing those attestations to on-chain storage. Later, validators run STARK proof verification logic to ensure that the proofs submitted by provers are valid. Only after validators finalize a block containing a proof can the fields provided by that proof (EX: to, from, value) be used to inform smart contract logic.

Interoperability

The net effect of all this work is that 3rd party builders can create contracts on Creditcoin which have secure, seamless access to data on other chains. Such contracts could for instance securely burn ETH on Ethereum and then trustlessly mint ETH on Creditcoin, without having to rely on any centralized party.

Builders can leverage these properties to create universal smart contracts which support their own custom cross-chain DApp business logic.

For more information on how to set up your DApp's logic to leverage Creditcoin USC, check out the DApp Builder Infrastructure section of the docs.

Data Provisioning Flow

The diagram below shows the flow of data from source chains to universal smart contracts on Creditcoin.

Reading the diagram above, we can see how groups of attestors begin by following new source chain blocks. Then, whenever a DApp submits a query to the Creditcoin Decentralized Oracle, the attestations previously stored on Creditcoin are used to prove that query’s target transaction took place on its source chain. The proving results from this query are then stored on-chain in the oracle’s prover smart contract. Finally, universal smart contracts on Creditcoin can read the resulting oracle data, interpret, validate, and finally use it to trigger business logic across any number of custom DApps.

Creditcoin Oracle Example Use Case

The following diagram demonstrates the use of Creditcoin USC to power a cross-chain loan infrastructure:

Dark green arrows represent actions that take place as part of the attestation process, creating attestations which can later be used to verify whether any given block is part of the finalized source chain. Light green arrows represent actions taken as part of the proving process, which generates a STARK proof for parts of a specific requested transaction.