Oracle

The primary role of the oracle is to ensure that the provider carries through on their commitments.

The oracle consists of two parts:

• A smart contract component here.
• A microservice here.

The oracle automates the verification of provider commitments and queries the L1 data source for transaction hashes and block extra data. It then cross-references these with commitments logged in the commitments contract, and then verifies adherence using the oracle contract. If a commitment is satisfied, the oracle contract triggers a reward to the provider using the bidder contract; if not, it slashes the provider by interacting with the provider contract.

Prior to Oracle Engagement

Before the oracle can be engaged according to the protocol’s intended sequence of events, several preliminary actions must be taken:

1a. A bidder sends their raw transaction to a provider, such as a block builder, or to the public mempool.

1b. Simultaneously, the bidder issues a bid via the mev-commit peer-to-peer network.

After the bidder’s actions, the provider proceeds to:

2a. Retrieve the bid from the mev-commit network.

2b. Issue a commitment for the transaction mentioned in the bid.

Oracle Happy Path Flow

When a bid for a transaction (txnj) is circulated through the mev-commit p2p network and the provider has made a commitment, the oracle is activated to verify whether the provider has honored this commitment.

The process is as follows:

1. The provider assembles the complete L1 block, incorporating txnj, to which it previously committed. Note: If the provider doesn’t get selected to construct the L1 block, the oracle flow does not get triggered.
2. The oracle microservice fetches the block from the L1 chain and verifies the presence of txnj.
3. Upon confirmation that txnj is included, the microservice notifies the oracle smart contract of the commitment’s fulfillment.
4. The oracle smart contract then initiates the transfer of funds from the bidder’s prepaid balance to the provider’s account.

Oracle Slashing Path

In the event that a provider fails to include a committed transaction (txnj) in the L1 block, the oracle slashing path is initiated to penalize the provider for the breach of commitment. This process is outlined below:

1. The provider is expected to produce an L1 block that includes the committed transaction (txnj). However, if the provider does not include txnj, the protocol moves to the slashing phase.
2. The oracle microservice retrieves the block from the L1 chain and searches for txnj. If the transaction is not found, it triggers the next step.
3. The oracle communicates that txnj was not seen in the oracle contract.
4. The oracle contract, upon receiving this information, initiates the slashing procedure. This involves penalizing the provider by triggering a slash event, which results in the forfeiture of the stake held by the provider contract as a guarantee of honest behavior.
5. The confiscated stake is subsequently allocated to the bidder as compensation for the provider’s failure to include the committed transaction, thereby ensuring that the bidder is recompensed for the provider’s breach of trust.