Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: optimize blog images #63

Merged
merged 8 commits into from
Nov 22, 2023
Merged

feat: optimize blog images #63

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
64445c1
feat: add liveness blog and update styling (#57)
0xArdy Nov 20, 2023
db09b64
feat: optimize images for liveness blog post (#58)
0xArdy Nov 20, 2023
c405066
Merge branch 'main' into dev
0xGorilla Nov 20, 2023
eb781e3
feat: add enti to the squad (#60)
eenti Nov 21, 2023
03e0b24
feat: optimize blog images (#62)
0xArdy Nov 21, 2023
73758d1
chore: resolve conflicts (#64)
0xArdy Nov 22, 2023
31d7820
chore: resolve image conflicts (#65)
0xArdy Nov 22, 2023
f8c045d
fix: conflicts
0xArdy Nov 22, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions public/blog-posts/a-mev-racing-story.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ His vehicle is now a mangled wreck, and he is trapped inside, immobile. The spec

You feel the crushing weight of your mortality bearing down on you. He was a racer, just like you. An individual who existed solely for the thrill of the competition. Yet, that very thrill has brought about his demise.

![https://images.unsplash.com/photo-1534307965816-94396c7de0d2?ixlib=rb-4.0.3&q=85&fm=jpg&crop=entropy&cs=srgb](https://images.unsplash.com/photo-1534307965816-94396c7de0d2?ixlib=rb-4.0.3&q=85&fm=jpg&crop=entropy&cs=srgb)
![](img/blog-posts/a-mev-racing-story/route.jpg)

The Merge event in Ethereum has unleashed a host of dangers in the [Ethereum Dark Forest](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest). These beasts now roam the woods, waiting for unsuspecting victims to fall into their trap. The [recent attack](https://twitter.com/samczsun/status/1642848556590723075) on MEV bots was likely just the first of many such events, and we can expect more to come.

Expand All @@ -32,7 +32,7 @@ To understand what led to the current situation, it is essential to comprehend t

In summary, PBS distinguishes the two roles responsible for generating new blocks in the blockchain network: the Proposer and the Builder. One noteworthy aspect of this separation is the ability of validators to use Blind blocks. This technique enables validators to sign a block's header without viewing its contents, making the signature valid for the entire block once it is revealed. The [Flashbots MEV-Boost](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177?u=benjaminion) design leverages this technique to provide a fair and efficient way for miners to extract value from the mempool.

![https://i.imgur.com/t7l5heX.png](https://i.imgur.com/t7l5heX.png)
![](img/blog-posts/a-mev-racing-story/graph-1.jpg)

_How was the proposer able to view the content of the block if Flashbots relay uses Blind blocks?_

Expand Down Expand Up @@ -72,7 +72,7 @@ Although the recent patches have reduced the risk of attacks, it has not entirel
4. If attester majority is reached for the first block from the proposer, all transactions from the Flashbots block will be vulnerable for replaying, since they are not part of the chain.
5. The proposer modifies the Flashbots block, extracts value, and proposes the modified block on his consecutive slot.

![https://defi-wonderland.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fce431091-9995-4cab-8d93-0afcb83c3ec8%2FUntitled.png?id=640e3afd-ed74-4d77-90c5-c5a9ebf3e4c3&table=block&spaceId=7683bccd-1174-4689-a817-b27fd9d7ef00&width=1000&userId=&cache=v2](https://defi-wonderland.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fce431091-9995-4cab-8d93-0afcb83c3ec8%2FUntitled.png?id=640e3afd-ed74-4d77-90c5-c5a9ebf3e4c3&table=block&spaceId=7683bccd-1174-4689-a817-b27fd9d7ef00&width=1000&userId=&cache=v2)
![](img/blog-posts/a-mev-racing-story/meme.jpg)

The chances of a malicious validator winning a race in the same block are “““low”””. However, multiblock attacks are a **very real and serious concern**. Validators from large validator pools, such as Coinbase, Binance, Lido, and Rocketpool, hold a significant portion of the validator power. There is a [high probability](https://alrevuelta.github.io/posts/ethereum-mev-multiblock) that stakers will propose multiple blocks in a row, and coordination among validators is also possible if the potential reward is significant. This was also one of the main reasons we built [PRICE](https://oracles.rip), an oracle that is able to detect and correct [TWAP multiblock manipulations](https://www.notion.so/Oracle-Manipulation-101-cbcea67b7796496995437907d3b1b4ba?pvs=21).

Expand Down Expand Up @@ -102,7 +102,7 @@ Suppose the attacker paid an average price of **`pi`** (price of STG/WETH) for t

[Amount in and out (bot) and reserves post swap (bot)](https://etherscan.io/tx/0xd2edf726fd3a7f179c1a93343e5c0c6ed13417837deb6fc61601d1ce9380e8dc#eventlog):

![https://defi-wonderland.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2F9ed3a5b3-4cbd-489a-96f2-cf5486128f3d%2FUntitled.png?id=b15aecbd-3a63-4086-a240-551a4b8bd62d&table=block&spaceId=7683bccd-1174-4689-a817-b27fd9d7ef00&width=1150&userId=&cache=v2](https://defi-wonderland.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2F9ed3a5b3-4cbd-489a-96f2-cf5486128f3d%2FUntitled.png?id=b15aecbd-3a63-4086-a240-551a4b8bd62d&table=block&spaceId=7683bccd-1174-4689-a817-b27fd9d7ef00&width=1150&userId=&cache=v2)
![](img/blog-posts/a-mev-racing-story/amount.jpg)

We assume the pool was initially on equilibrium. If not, the attacker can profit even further. This means `pi=p0`. Notice `p0=ypre/xpre` (where `xpre` are the `reserve0` before the victim’s swap and `ypre` are the `reserve1` before the victim’s swap). We want to know now how much must the attacker input in order to bring the pool back to the initial price `pi`. The attacker will input STG (x) and output WETH (y) in the back-run transaction. Let’s use the constant product formula and find how much should the attacker input to bring the pool back to the initial price `pi`:

Expand Down Expand Up @@ -136,7 +136,7 @@ def attack(x,y,xpre,ypre):

The ideal parameters for the STG/WETH pool attack would have been to input approximately 4.53 STG and output around 2454.10 WETH, resulting in a profit of around 2454.09 WETH or around 4.7M USD at the current value. However, the attacker's actual input was larger and their return was slightly smaller due to fees. It is possible that the attacker had prepared this attack beforehand, as the difference between the ideal and actual parameters is small.

![https://defi-wonderland.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2F34441066-c231-4d9b-94ed-f540a8dd1835%2FUntitled.png?id=1d7184c1-11af-4093-877d-1ae9a74601ec&table=block&spaceId=7683bccd-1174-4689-a817-b27fd9d7ef00&width=1600&userId=&cache=v2](https://defi-wonderland.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2F34441066-c231-4d9b-94ed-f540a8dd1835%2FUntitled.png?id=1d7184c1-11af-4093-877d-1ae9a74601ec&table=block&spaceId=7683bccd-1174-4689-a817-b27fd9d7ef00&width=1600&userId=&cache=v2)
![](img/blog-posts/a-mev-racing-story/amount-2.jpg)

You can play around and change the variables in the following colab file:

Expand Down
4 changes: 2 additions & 2 deletions public/blog-posts/liveness-2-and-beyond.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -129,7 +129,7 @@ In [this blog post](https://vitalik.eth.limo/general/2023/06/20/deeperdive.html)

Both zkSNARKs and KZG allow for proof aggregation, further reducing user costs.

![Untitled](img/blog-posts/liveness-2-and-beyond/graph-1.png)
![Untitled](img/blog-posts/liveness-2-and-beyond/graph-1.jpg)

In what follows, we will focus on the existing approaches to tackle this verification step. Even though storage proofs (with or without zk) are the most secure method, we will also consider other options in our analysis. For each, we will analyze the tradeoffs, possibilities, costs and state of development.

Expand Down Expand Up @@ -171,7 +171,7 @@ At the time of writing, they have deployed their contracts on mainnet only. A po

Also, note that the current implementation consumes above [500k gas per query answer](https://etherscan.io/address/0xd617ab7f787adf64c2b5b920c251ea10cd35a952), even more than the current MPT implementations. Axiom has, of course, a lot of additional benefits, such as allowing queries to go back in time.

![Gas comparison for different proofs. Image taken from [Relic’s documentation](https://docs.relicprotocol.com/overview/comparison).](img/blog-posts/liveness-2-and-beyond/table-1.png)
![Gas comparison for different proofs. Image taken from [Relic’s documentation](https://docs.relicprotocol.com/overview/comparison).](img/blog-posts/liveness-2-and-beyond/table-1.jpg)

Gas comparison for different proofs. Image taken from [Relic’s documentation](https://docs.relicprotocol.com/overview/comparison).

Expand Down
24 changes: 12 additions & 12 deletions public/blog-posts/oracle-manipulation-101-math-edition.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ $x*y=L^2 \hspace{1cm}(1)$

where $L$ is called Liquidity. This $L$ is modified only when someone adds or removes the token balance and is constant otherwise.

![https://i.imgur.com/zdwwOgV.png](https://i.imgur.com/zdwwOgV.png)
![img/blog-posts/oracle-manipulation-101-math/1.png](img/blog-posts/oracle-manipulation-101-math/1.png)

Anyone can swap token A for token B or vice versa on this pool, modifying the balances $x$ and $y$ in the pool according to $(1)$. You can visualize this behaviour in the Figure ([source](https://medium.com/block-journal/uniswap-understanding-the-decentralised-ethereum-exchange-5ee5d7878996)).

Expand Down Expand Up @@ -119,7 +119,7 @@ L_N,\quad p_N<price

the terms $x_{offset}$ and $y_{offset}$ are only centring the equation in the corresponding range, as you can see in the Figure from the whitepaper:

![https://i.imgur.com/HH1C8mS.png](https://i.imgur.com/HH1C8mS.png)
![img/blog-posts/oracle-manipulation-101-math/2.png](img/blog-posts/oracle-manipulation-101-math/2.png)

### Understanding Liquidity

Expand All @@ -143,7 +143,7 @@ Liquidity is not straightforward to compute now, as its formula depends on the p

You can find the full code implementation in [this link](https://github.com/Uniswap/v3-periphery/blob/main/contracts/libraries/LiquidityAmounts.sol#L120). You can play around with different values [here](https://colab.research.google.com/drive/1RwpF-lKq968mvsyL0jgyw9rO_cTqYxPl?usp=sharing). Also, you can find examples [here](https://github.com/atiselsts/uniswap-v3-liquidity-math) and [here](http://atiselsts.github.io/pdfs/uniswap-v3-liquidity-math.pdf).

![https://i.imgur.com/v1jiDeG.png](https://i.imgur.com/v1jiDeG.png)
![img/blog-posts/oracle-manipulation-101-math/3.jpg](img/blog-posts/oracle-manipulation-101-math/3.jpg)

### Price Manipulation

Expand Down Expand Up @@ -208,7 +208,7 @@ Uniswap knows its role as a decentralized on-chain price source and has built it

$TWAP$ stands for time-weighted average price. It's a geometric average price for a pool over a fixed interval of time and is what we query from the current implementation of the Uniswap v3 Oracle library. It's also a standard trading tool, as seen in the red line in the Figure.

![https://i.imgur.com/cuVdOPL.png](https://i.imgur.com/cuVdOPL.png)
![img/blog-posts/oracle-manipulation-101-math/4.png](img/blog-posts/oracle-manipulation-101-math/4.png)

> ℹ️ Given 2 numbers, $a_1$ and $a_2$:
> Arithmetic mean: $\frac{a_1+a_2}{2}$
Expand Down Expand Up @@ -244,7 +244,7 @@ You can gain more by playing around at [this link](https://colab.research.google
- Using longer TWAPs will make movements exponentially harder.
- Moving the price over several blocks reduces the costs exponentially.

![https://i.imgur.com/sTVbO3c.png](https://i.imgur.com/sTVbO3c.png)
![img/blog-posts/oracle-manipulation-101-math/5.png](img/blog-posts/oracle-manipulation-101-math/5.png)

> ℹ️ To manipulate a $TWAP$ to the desired price, an attacker needs to move the spot much more so that the average falls on target. The longer the $TWAP$ length $N$ is relative to the attack's $M$, the harder it is to manipulate. That is why longer $TWAPs$ are suggested for a safer query.
>
Expand All @@ -262,7 +262,7 @@ We will exclude trading fees for simplicity of reading, but you can trivially ad

## Math for Attack Scheme pre PoS

![https://i.imgur.com/D9UKvny.png](https://i.imgur.com/D9UKvny.png)
![img/blog-posts/oracle-manipulation-101-math/6.png](img/blog-posts/oracle-manipulation-101-math/6.png)

The regular scheme for attacking a lending market is the following:

Expand Down Expand Up @@ -306,7 +306,7 @@ $Profit = \Delta x_{out} - \Delta x_{in} = min[fP_fy(\frac{L\sqrt{P_f}-x}{L\sqrt

You can play around simulating the arbitrage scenario in [this link](https://colab.research.google.com/drive/1RwpF-lKq968mvsyL0jgyw9rO_cTqYxPl?usp=sharing). You can see in the Figure below that the optimal attack in this scenario will correspond to using all capital from the manipulation to borrow up to the available reserves (no $\Delta y_{sell}$ left). It's possible to find this optimal price analytically as a function of the reserves, which LPs can use to define safe semi Full-Range positions. Notice this graph does not take TWAP into account and is only valid for markets which query the spot price.

![https://i.imgur.com/MepFPt3.png](https://i.imgur.com/MepFPt3.png)
![img/blog-posts/oracle-manipulation-101-math/7.png](img/blog-posts/oracle-manipulation-101-math/7.png)

To include the $TWAP$ parameters in the analysis, we should compute the Cost of Manipulation $C_{manipulation}^*$ with the spot price added using Eq. $(3)$ while keeping the $TWAP$ price to obtain the stolen amount. We can also simulate this and check that manipulation cost increase radically to the point where single-block attacks are never profitable. Notice that the $TWAP$ is not an on-off switch and has different levels, which we can measure with the ratio $\frac{Length_{attack}}{Length_{TWAP}}\simeq \frac{M}{N}$, with $N$ the approximate number of blocks in the $TWAP$ and $M$ the number of blocks the manipulation lasted.

Expand All @@ -322,21 +322,21 @@ Two main factors can endanger $TWAP$-based oracle liquidity:

1. Bad liquidity positions in Uniswap v3: as we mentioned, a pool is, in most cases, easier to manipulate when liquidity is concentrated rather than over the Full Range. Price manipulation costs zero over regions with no liquidity.

![https://i.imgur.com/g33Ssp5.png](https://i.imgur.com/g33Ssp5.png)
![img/blog-posts/oracle-manipulation-101-math/8.png](img/blog-posts/oracle-manipulation-101-math/8.png)

1. No liquidity in secondary markets: there is no way for arbitrage to close the trade effectively. As we mentioned, the absence of arbitrage makes manipulation back to the initial price possible (the attacker recovers capital used for price manipulation). It also unlocks multi-block attacks (requires less upfront capital).

Both issues are typical for small projects. This is, for instance, what happened to the stablecoin FLOAT in Rari (see the FLOAT incident in Rari [here](https://etherscan.io/address/0xa2ce300cc17601fc660bac4eeb79bdd9ae61a0e5) and [here](https://www.defilatam.com/rekt/us-1-4-m-ataque-al-pool-90-de-rari-y-una-leccion-de-oracles-en-lending-para-aprendices)): liquidity was deployed only over the 1.16-1.74 USDC per FLOAT in Uniswap, which meant that manipulation cost was zero outside this range. As there was no liquidity in secondary markets, the attacker could wait for a few blocks and significantly impact the registered $TWAP$. Then, they proceeded to empty over $1M USD from the Pool 90 Fuse for only 10k FLOAT.

![https://i.imgur.com/0ggvoYl.jpg](https://i.imgur.com/0ggvoYl.jpg)
![img/blog-posts/oracle-manipulation-101-math/9.jpg](img/blog-posts/oracle-manipulation-101-math/9.jpg)

> ⚠️ These attacks are the most common for small projects. Attacks in these contexts are hard to distinguish from rug pulls. A lending market can protect itself by reverting the borrowing if the difference between $TWAP$ and spot price is large, but as time passes, the $TWAP$ will get close, and basic checks will pass. Both users and lending markets should be aware of these risks when using or listing low-liquidity tokens. PRICE will include additional methods to mitigate this risk.

## Math for Attack Scheme post-PoS

After the Merge, big stakers have a [high chance](https://alrevuelta.github.io/posts/ethereum-mev-multiblock) of proposing multiple blocks in a row, which makes manipulation back to the initial price possible and significantly lowers the attack cost. It also makes TWAPs cheaper to move, as the attacker can maintain the manipulated price for longer.

![https://i.imgur.com/fqvGvDd.png](https://i.imgur.com/fqvGvDd.png)
![img/blog-posts/oracle-manipulation-101-math/10.jpg](img/blog-posts/oracle-manipulation-101-math/10.jpg)

Suppose the validator has $n>2$ consecutive blocks. In that case, the attacker can manipulate over $n-1$ blocks to reduce the initial capital required. In the final block $n$, they can exercise partial manipulation back to the initial price (or near it). As we have shown in Eq. (1), the final spot price to manipulate a $TWAP$ becomes closer to the initial price as the number of proposed blocks increases ($M$ in the equation). It's straightforward to show that the attack cost decreases enormously with this parameter. When protecting an oracle, we must be ready for the worst-case scenario, i.e. the post-PoS multi-block attack.

Expand Down Expand Up @@ -364,9 +364,9 @@ You can play around with a simulation for this attack [here](https://colab.resea

The equilibrium price is a function of $a_{colateral}$. The higher this capital, the lower the target $TWAP$ (but also, the less profit). For significant enough price manipulations, $a_{left}$ is sufficient to be profitable, and $a_{colateral}$ might be unnecessary. This dependence with $a_{colateral}$ complicates the use of almost Full Range positions as a more efficient alternative to Full Range positions.

![https://i.imgur.com/gJmgVKc.png](https://i.imgur.com/gJmgVKc.png)
![img/blog-posts/oracle-manipulation-101-math/11.png](img/blog-posts/oracle-manipulation-101-math/11.png)

![https://i.imgur.com/pnmBvFS.png](https://i.imgur.com/pnmBvFS.png)
![img/blog-posts/oracle-manipulation-101-math/12.png](img/blog-posts/oracle-manipulation-101-math/12.png)

This scheme requires an additional up-front capital $a_{back}$ , which is trivially recovered by manipulating back, but it's also the heaviest capital. The up-front cost falls exponentially with the attack length (number of consecutive blocks to propose). The longer the $Lenght_{TWAP}$ the market uses relative to the attack length $Length_{attack}$, the more serious this capital becomes.

Expand Down
Loading