Checkout our latest Litepaper here:

https://mirror.xyz/hyperoracleblog.eth/FKvpIGI7fiuNr5rnTlFWAdxk4QCNFIR9rmqDPxWLc2w

• A recent hack worth $25M reveals a significant mismatch between the revenue that can be captured through MEV at the application level and the cost of PoS slashing.

• The difference between the benefits and comparably low costs of an attack can impact the security of the network system itself.

• In an oracle network, PoS is directly related to the security of the application, as oracle network provides a data service instead of hosting a neutral computing platform like Ethereum.

• Hyper Oracle is an oracle network that replaces PoS with ZK and safeguards applications with the base layer blockchain's security.

In our recently published whitepaper, we discussed issues with traditional oracle networks. One of these issues is "Low Cost and High Profit of Attack." Attacking these protocols by attacking the oracle network can result in a high potential profit, while the cost of attacking the oracle network is low if its token price or staking requirement is too low.

The root cause of this security flaw is the staking and slashing mechanism of the oracle network (also known as middleware network).

To ensure consistency, we will use "PoS" (Proof of Stake) to refer to the staking and slashing mechanism of the oracle network. However, there are some minor differences between PoS in a traditional blockchain network and the staking and slashing mechanism of an oracle network.

We discussed how PoS works in traditional oracle networks in our documentation. The security of these networks is based on the PoS mechanism.

PoS has two main components:

• Staking: Nodes must lock tokens in order to join the network.

• Slashing: Bad nodes forfeit their locked tokens.

  • Challenge: Report bad nodes and provide evidence.

  • Arbitration: Judgment on challenges.

While staking is similar, the mechanisms associated with slashing differ.

In output oracles such as The Graph, the challenge mechanism in PoS is called a fisherman mechanism (docs, code). This mechanism is similar to Optimistic Rollups' fault/fraud proof, but it lacks verifiability and decentralization. Here's how it works: during a week-long dispute period, someone can stake their token to challenge the computation (indexing or querying) and result of a node operator (indexer). Then, an arbitrator council decides if the challenge is accepted to slash the challenger or the node operator.

I/O oracles such as Gelato Network and Keep3r Network use governance-based slashing for security. However, some of them are currently not permissionless and require legal bindings to operate a node. For the networks that have governance and PoS as a security mechanism, someone must challenge a node operator (executor) on their governance platform (usually a forum), and members will manually examine the challenge. To me, this feels like the meme below.

To start, let’s define some terms related to the hack:

• MEV: Miner/Maximal Extractable Value. This is the extra income that a user or node on a network can gain from the actions of other users.

• Flashbots: A software that allows people to extract MEV without disrupting others’ normal usage. MEV bots use Flashbots to gain MEV, while nodes process transactions sent by MEV bots through Flashbots to receive a certain "bribe" from the MEV bots’ share.

• Sandwich Attack: A “harmful” MEV practice that targets users who trade on AMMs like Uniswap or Sushi. It aims to extract profits from user transactions by sandwiching them with multiple transactions.

• Ethereum PoS: Staking your ETH to become a node on the network allows you to receive staking revenue and earn MEV revenue through Flashbots. However, bad behavior on the network can result in a node's stake being slashed.

In summary, a hacker made over $20 million from MEV bots by exploiting a Flashbots vulnerability and taking advantage of Ethereum’s PoS.

If you want a very detailed and technical review of the hack, check out samczsun's tweet. But here's the story in simple terms.

The hacker set up an Ethereum node (or maybe more) two weeks ago by staking. Then, they deployed liquidity on an AMM. The hacker posed as a trader and used this liquidity to lure other MEV bots into performing sandwich attacks.

Flashbots follow a basic principle that requires a node to trust that it will receive the most profitable blocks from Flashbots. To ensure that malicious nodes do not generate malicious blocks, Flashbots has two restrictions in place.

1. The contents of the block, such as the MEV bot's arbitrage transactions, can only be unbundled and viewed after the node verifies and confirms the block by signing. If the double signing occurs, Ethereum will slash the node. Currently, this restriction is changed and fixed.

2. Additionally, blocks submitted by nodes themselves are unlikely to reach the entire network as quickly as those submitted by Flashbots.

The hacker waits for its node's turn to act as a proposer for a block while tempting these MEV bots. The hacker tests and waits until the opportunity arises. To bypass the above two restrictions, the Hacker forms a chain of two countermeasures:

1. The hacker chooses to get slashed since it will be slashed anyway. That's only a loss of about $2000.

2. By exploiting a vulnerability in Flashbots, the hacker proposes an invalid block. Therefore, Flashbots cannot submit the block to the network, and the hacker wins the contest.

In the end, the hacker snoops on the MEV bot's operations and extracts a large amount of MEV revenue while others explicitly show their moves. The hacker sandwich attacks the sandwich attacker (great illustration by 100y_kor).

It's important to note that the Flashbots bug is the fuse of the entire hack. Without the bug, the hack wouldn't exist.

But what else causes this hack? It's because MEV is much more profitable than receiving a penalty in Ethereum (25,000,000 profit for 1,800 penalty? Sure, i'll take that trade). Ethereum isn't really at fault here; PoS is working safely as expected, and the hacker's node was indeed slashed (even though this is not effectively preventing this kind of behavior).

In the next chapter, we'll delve into why Ethereum isn't facing major issues, but in oracle networks, a similar PoS mechanism can lead to extremely dangerous insecurity. Thus, the "Low Cost (of slashing in network) and High Profit (by hacking apps in network)" scenario can become problematic.

The main difference is that Ethereum and oracle networks have different business models.

• Ethereum provides the network platform for running applications.

• Oracle networks provide data-related services for supporting applications.

As a neutral network and platform, Ethereum is not responsible for the applications (such as Flashbots and AMMs) that run on top of it. The protocol design only needs to ensure error-free consensus and computation, without taking these applications into account.

On the other hand, the oracle network is a service provider and is responsible for ensuring the accuracy and verifiability of its own data, as well as the applications that use it. Its protocol design and consensus are also closely tied to the application as a whole. Also, the LUNA-Venus-Chainlink exploit came as a result of Chainlink turning off support for LUNA price oracle proves why oracle networks need to secure its application’s data as a service provider.

The reason I believe there is no issue with Ethereum in the above hack is because its consensus layer is functioning properly, and the profit is being generated solely from the application layer. The incident occurred due to the following reasons:

1. MEV bots and nodes have a profit-seeking nature (High Profit).

2. All of them use Flashbots.

3. Flashbots has bugs that partially affect Ethereum's entire system.

4. Malicious actors are willing to ignore slashing (Low Cost) to carry out attacks.

Considering the differences in business models, it is clear that Ethereum's options are limited and can only perform minor slashing.

In an oracle network, the problem of high profit and low cost can result in a large number of attack points. If it is more profitable to hack applications that use the oracle network than it is costly to hack into the oracle network, then there will be attacks that ignore these costs.

• High Profit: The value of application layers in Layer 1 blockchains and the one based on oracle networks is very close. This means that high profits exist in application layers of oracle networks.

• Low Cost: Staking requirements in permissionless oracle networks are usually much lower than in Ethereum. Slashing punishments are also less costly.

In the oracle network example, even if the oracle networks are running as expected, if the applications that rely on them as data sources or middleware are hacked due to the services they provided, then the security of the oracle network itself is compromised. It was only a matter of time before applications based on traditional oracle networks were hacked for this reason.

In PoS of Ethereum, slashing is only related to the consensus layer, while in PoS of oracle networks, slashing is directly related to the data and service they provide to the applications based on their node's computation.

The oracle network is responsible for the data and services it provides. PoS in them only makes the network itself "secure," but does not provide the essential validity to the data and services.

Overall, oracle networks and applications based on them are more affected by PoS with:

• service provider business model

• direct correlation of data correctness and PoS mechanisms

• same high potential profit of being hacked

• lower staking requirement and lower cost of being slashed

We are building Hyper Oracle, the programmable zkOracle protocol.

Current oracle networks have difficulties with creating an effective punishment mechanism (slashing) that considers out-of-network applications. Therefore, we need to replace the presumption of innocence (PoS) with the presumption of guilt (zk).

We cannot replace PoS in Layer 1 blockchains with ZK to create a new consensus algorithm due to ZK's nature of only proving computation validity. However, we can replace all the PoS in oracle networks. This would raise the security of oracle networks to the same level as that of Layer 1's.

We replace the security and incentive mechanisms of traditional oracle and middleware infrastructure from PoS (staking and slashing) to ZKP. Our trustless meta apps ensure the verifiability and security of on-chain data and off-chain computation.

MEV bots are highly advanced predators in Ethereum's dark forest, but they are vulnerable to more advanced creatures.

The ethical nature of a hacker's actions cannot be easily defined as good or bad. Extracting revenue from "bad" MEV bots may be seen as a way to punish the "bad" guys, but it's important to remember that MEV bots are still users of the network and contribute to stability of on-chain asset prices and trading activity. While the hacker may be following the rules of Ethereum, they are breaking the rules of Flashbots.

The more you think about it, the scarier it gets.

MEV has contributed to centralization.

On the Ethereum network, validator staking returns are much smaller than MEV returns, which may lead to centralization. Larger validators will be favored. However, Endgame's in-protocol MEV design may solve these issues.

Flashbots and other services are also facing centralization issues. “The MEV ecosystem today relies on non-robust social consensus and reputational staking”. Although there may be new systems like SUAVE in the future to help decentralize, for now, the whole MEV space is very centralized.

Economic systems can be challenging to analyze due to factors such as MEV. With oracle networks, it may be difficult to determine the amount of slashing required to fully secure data and computation with PoS.

A cryptography-based zkp for oracle or rollup networks may be a better option to verify the derived data correctness from the base layer PoS blockchain network. This approach can help simplify the system and increase trust, since it is based on code rather than other factors.