This piece concludes our three-part exploration of Ethereum oracle contracts.

• The initial article provided a foundation by guiding you through code setup, execution, and testing using the Truffle framework.
• The second installment delved into the code, sparking discussions on Solidity’s code structure and design principles.

This final part aims to address the questions of purpose and significance. We’ll navigate the complex relationship between oracles and trustlessness, and how the concept of “trustlessness” translates to real-world blockchain applications. As we bridge the gap between theory and practice, grappling with these questions becomes essential. So, let’s begin.

Recap: Why Use an Ethereum Oracle?

This question lies at the core of executing code on the blockchain. To maintain immutability and determinism, and due to how nodes execute code, smart contracts can’t directly interact with anything outside the blockchain.

This presents an unusual constraint for most programmers. Typically, we’d connect directly to a source to retrieve data. Imagine a smart contract needing weather data; we’d naturally connect to a weather feed. However, blockchain smart contracts can’t function this way. If data isn’t already on the blockchain, the contract can’t access it during execution. The solution? Ensure the necessary data is on the blockchain before execution. This necessitates external mechanisms that push data onto the blockchain specifically for use by other contracts. These mechanisms are oracles. Data is pushed into oracle contracts, designed to share it with other contracts. We built and examined this setup in the previous two articles.

Glaring Security Holes

The crux of public blockchains is trust. These systems strive to guarantee (absolute certainty is impossible) that blind trust in any party is unnecessary. The astute reader may have already questioned some of the glaring security holes in the Boxing Bets example. Let’s focus on those relevant to our discussion on trustlessness and its connection to oracles in smart contracts.

1. Potential for Corrupt Betting Contract Owner/Maintainer

Line 58 of BoxingBets.sol presents the following function:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

    /// @notice sets the address of the boxing oracle contract to use 

    /// @dev setting a wrong address may result in false return value, or error 

    /// @param _oracleAddress the address of the boxing oracle 

    /// @return true if connection to the new oracle address was successful

    function setOracleAddress(address _oracleAddress) external onlyOwner returns (bool) {

        boxingOracleAddr = _oracleAddress;

        boxingOracle = OracleInterface(boxingOracleAddr); 

        return boxingOracle.testConnection();

    }

The implication is clear: the contract owner has unrestricted power to change the oracle used for boxing matches and winner determination. The problem? This allows the contract owner to manipulate the contract for personal gain.

Example: Imagine the upcoming Soda Popinski vs. Glass Joe match. Soda is the overwhelming favorite, attracting significant bets. As the contract owner, I decide to exploit the system. Before the match ends, I switch to my malicious oracle. This oracle, identical to the official one, is rigged to declare Glass Joe the winner. The rigged outcome makes me rich, and I’m unstoppable. While this might erode trust in my contract, it might not matter if my goal was a one-time heist.

Exploring Alternatives

1. Disabling Oracle Changes

The problem stems from allowing oracle changes by the contract owner. Could we hardcode the oracle address? It’s possible but raises concerns. What if the oracle becomes inactive or loses trust? We’d need a new one. With a hardcoded oracle, the only option is releasing a new contract with a different oracle. While feasible, remember that smart contract updates aren’t as simple as, say, website updates. Unlike patching software, smart contract deployments resemble shrink-wrapped software; once deployed, changes require user upgrades.

However, this isn’t insurmountable. Many models and ideas exist for modifiable smart contracts. This deserves its own article, but for now, explore this Hackernoon article and this piece on smart contract strategies.

From a user’s perspective, imagine considering a bet on the Don Flamenco match. The contract straightforwardly uses a trusted oracle (at least trusted enough for a bet of a certain size), simplifying the process. If the contract owner releases a new version with a different oracle, users (ideally) retain the option to use the old contract, unless it’s disabled or destroyed during the upgrade.

2. Locking the Oracle for the Bet Duration

We can introduce complexity to mitigate risks (not ideal for a simple example, but valuable for real-world solutions) by “locking in” the oracle for the bet duration. The contract could guarantee that the oracle at the time of bet placement remains the same for determining the winner, even if it changes for other matches. Transparency about the oracle is crucial.

Example: As a user considering a bet on the Little Mac fight, I can inspect the oracle that will determine the winner. I verify it’s the well-known Nintendo Sports oracle, giving me confidence (the contract could even allow users to choose from multiple oracles). Inspecting the oracle’s code, I see a guarantee that the same oracle will determine the outcome. While not eliminating the risk of a corrupt oracle, it assures me it won’t be changed.

A risk is the oracle becoming inactive before the match, potentially locking funds. We could add a time-based clause where undecided matches by a specific time are considered “dead,” returning funds to bettors.

3. User-Defined Oracles

A more complex (and intriguing) solution is leaving the oracle address “blank,” allowing users to specify their own and form betting pools around them. This empowers users to choose and share trusted oracles. While fragmenting the betting community, it shifts oracle responsibility from the contract owner, who merely provides the platform. Users can switch from untrustworthy oracles without blaming the contract owner.

This strategy’s complexity lies in organically growing a pool of compatible oracles. Broadcasting the required interface and hoping for enough oracles to provide choice is key. We could even seed the pool. If it fails, the betting DApp fails. But if it succeeds, the idea of user-selected, organically-grown oracles is compelling.

2. Potential for Corrupt Oracle Owner/Maintainer

“Corrupt” meaning untrustworthy; the oracle’s owner/maintainer might manipulate match outcomes for personal gain.

Example: Imagine I run the oracle feeding boxing data to the betting contract. My oracle’s sole purpose is data provision. However, I might anonymously place bets using the contract that relies on my oracle. This creates a conflict of interest. The accuracy of my oracle’s data could be compromised by my betting activities.

Let’s say I bet heavily on the underdog, von Kaiser, in the Sandman/von Kaiser match. When von Kaiser predictably loses, I use my oracle to falsely declare him the winner! The betting contract executes, I profit immensely, and there’s no recourse. While people might stop using my oracle, I might not care.

Preventing Oracle Manipulation

This is a bigger issue, central to the concept of trustlessness and oracles. Oracles are assumed to be neutral third parties. The problem? Humans run them. Additionally, oracles wield significant control over the client contract’s operations due to their data provision. How can we guarantee oracle trustworthiness?

Trusting Oracles

If blockchain smart contracts aim to eliminate trust, doesn’t trusting an oracle contradict this? The truth? Absolute trustlessness is a myth. Blockchains are layers facilitating human interactions, which inherently involve trust.

Link: The Oracle Problem

The Evolution of Trust

Throughout history, trust has been paramount. In primitive times, how could I trust someone to share the spoils of a hunt? Back then, the threat of violence often underpinned socio-economic trust. The risk of retaliation for cheating served as a deterrent. Even with confidence in winning a fight, the risk of injury made it less appealing. Essentially, cheating wasn’t beneficial in the long run; cooperation yielded better outcomes.

If this wasn’t the case, or perceived as such, participation might cease. For example, facing a formidable opponent, I’d likely avoid any deal due to the power imbalance. However, when parties are relatively equal, cooperation becomes mutually beneficial, leading to a rational choice to cooperate.

As societies evolved, so did human interactions, becoming less violent while retaining an implicit threat of force. Cultural norms encouraged cooperation and introduced alternative deterrents to cheating.

In early civilizations, contracts emerged. Imagine paying upfront for grain to be delivered later. Why trust the merchant? Several factors were at play. Firstly, the merchant’s livelihood relied on a reputation for honesty. Cheating would lead to reputational damage, outweighing the short-term gains. Secondly, there was still a fear of repercussions. Cheated parties might resort to violence, potentially escalating into conflicts.

Decentralized Trust Today

What about today? Have the disincentives for breaching contracts changed significantly?

Consider mail-in rebates. Trust in companies to honor them stems from similar factors as before. Reputational damage outweighs petty gains. Furthermore, legal systems, backed by the government’s threat of force, can impose fines or lawsuits for breaches.

Traditional Systems

Government-backed contract enforcement has served humanity for millennia. The absence of government often leads to the formation of new ones. It seems almost inevitable.

How do blockchain smart contracts and their model ensure trust and deter cheating, without simply relying on the idea of “trustlessness”? Let’s explore this further.

Blockchain Systems: Bitcoin

To simplify, let’s begin with Bitcoin. How does it discourage cheating? I’m free to run custom Bitcoin nodes as long as they adhere to network protocols. Could this be exploited for illicit gains?

While I could create transactions sending all your Bitcoin to me and broadcast them, they wouldn’t be approved without your private key, thanks to encryption. This protection stems from the requirement of transaction signing. The network would reject any attempt to bypass this, as it undermines Bitcoin’s integrity and, consequently, the value held by its participants. It’s not in their interest to facilitate cheating. Even if a rogue actor approves an invalid transaction, the majority network would reject it, rendering it powerless.

What if I control a significant portion of the mining power? While this grants influence over transaction order, it doesn’t allow minting or stealing coins. Even controlling over 50% of the network (assuming you’re familiar with the well-known 51% attack in proof-of-work systems like Bitcoin) primarily allows for double-spending. However, this undermines Bitcoin’s integrity, making it a questionable choice. Utilizing control to mine coins honestly would be more lucrative while preserving the system’s foundation. Hence, while not completely powerless, the incentive to cheat is mitigated by a built-in disincentive. This disincentive is rooted in the strength of consensus among the vast majority of Bitcoin network participants.

Blockchain Smart Contracts and Oracle Contracts

Smart contracts, while powerful, can also be misused. Deploying deceptive contracts or exploiting vulnerabilities in betting contracts might yield short-term gains. However, the defense lies in participants diligently scrutinizing contracts, understanding potential vulnerabilities, and considering the reputation of those behind them. Dishonest contracts would likely be flagged by the network, leading to their avoidance.

However, trust in humans remains essential. Oracle data is provided and maintained by humans. No matter how many layers we add to ensure honesty, it always traces back to a human. So, what kind of oracle would you trust in our betting example? A trustworthy oracle would have more to lose than gain by cheating. Imagine a renowned network like ESPN sponsoring the oracle. Their reputation for honest data would be paramount, making illicitly winning a petty bet a negligible gain compared to the potential reputational damage. This mirrors our trust in the honest grain merchant – a long-standing model of trust.

What then is the advantage of smart contracts, and how do they differ from traditional governance or contract enforcement?

Wrapping Up

Instead of definitive conclusions, I’ll present observations to stimulate thought and discussion, as this complex topic resists oversimplification.

• Trust based on the assumption of mutual benefit, where cooperation outweighs cheating, is a longstanding and effective system. It persists in specific blockchain scenarios, including our oracle example.
• Trust based on the threat of force or violence, while historically prevalent, is remarkably absent from our smart contract model. It’s replaced by enforcement through a combination of encryption and large-scale consensus.

I challenge fellow Ethereum developers to ponder:

1. Can you identify any instance within public blockchains (like Bitcoin or Ethereum) where enforcement relies on the threat of force, whether implicit or explicit?
2. Can you think of any significant rule system in modern contract or financial law that doesn’t rely on the threat of force for enforcement, either directly or indirectly?

Something Old, Something New

Here lies the core distinction and the reason blockchain systems are considered revolutionary. It’s not about eliminating trust entirely, but establishing a more stable platform for trust. Most notably, this platform doesn’t depend on the threat of force or violence.

On one hand, we have the age-old assurance of mutual benefit when cheating is disincentivized. On the other hand, the novelty lies in introducing encryption-assisted consensus to discourage cheating and maintain system integrity. The synthesis of these elements creates something remarkable: a system for large, anonymous groups that operates without the threat of force as a deterrent or punishment. That, I believe, is truly groundbreaking.

Overlooking this aspect reduces blockchain to a fascinating technology (which it undoubtedly is). But recognizing it reveals that we’ve entered a new era of governance.