You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MEV suck, Sandwiches sucks, use OpenMEVs.~\cite{openmev}.
80
+
\text{}
81
+
\newline
82
+
\newline
83
+
\textbf{MEV is sucks. }\newline
84
+
MEV suck, \textbf{Sandwiches sucks}, \newline
85
+
\newline
86
+
use OpenMEVs.\footnote{Bacha, Sam "MEV is essentially looking for the reachable state where their balance is maximized. Given any arbitrary re-ordering, insertion or censorship of pending or existing transactions, this can suck, suck real hard."}
67
87
\end{abstract}
68
88
69
-
\subsection{Design}
70
-
The Original design for the router was to use flashloans only to arbitrage then immediately distribute profits to hard coded addresses. Apart from the issue of hard coded addresses, this setup was inefficient because of small amounts frequently being split and transferring to multiple addresses being expensive. This opened the possibility of leaving profits to accumulate on the router. Furthermore it provides a way to arbitrage without a flashloan, saving gas and the loan fee (i.e. more profit, less gas). Additionally, the harvesting profits means ownership control of the router. A more robust 2 step process was chosen to control and transfer router ownership and harvest control. Ideal setup would be multisig consensus ownership.
89
+
\section{Motivation}
90
+
\text{see} \textbf{\emph{Abstract}}.
71
91
72
-
\footnote{Ownership control of the router is not an issue, as a new router can be used or fallback to the legacy router contract.}
92
+
\subsection{Design}
93
+
\paragrah{The Original design for the router was to use flashloans only to arbitrage then immediately distribute profits to hard coded addresses. Apart from the issue of hard coded addresses, this setup was inefficient because of small amounts frequently being split and transferring to multiple addresses being expensive. This opened the possibility of leaving profits to accumulate on the router. Furthermore it provides a way to arbitrage without a flashloan, saving gas and the loan fee (i.e. more profit, less gas). Additionally, the harvesting profits means ownership control of the router. A more robust 2 step process was chosen to control and transfer router ownership and harvest control. Ideal setup would be multisig consensus ownership.}\footnote{Ownership control of the router is not an issue, as a new router can be used or fallback to the legacy router contract.}
Conformance requirements phrased as algorithms or specific steps that can be implemented in any manner, so long as the end result are equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not necessarily intended to be performant. Implementer's are encouraged to either: switch to an L2, optimize, or use Vyper\footnote{Vyperlang: https://vyper.readthedocs.io/en/stable/}.
121
+
Conformance requirements phrased as algorithms or specific steps that can be implemented in any manner, so long as the end result are equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not necessarily intended to be performant. Implementers are encouraged to either: switch to an L2, optimize, or use Vyper\footnote{Vyperlang: https://vyper.readthedocs.io/en/stable/}.
By definition, backruns must occur after user to user swap. From a design point of view the simplest place to insert the backrun function would be in the internal $_swap$ function which is called by the other swaps. However, some of the swap variants eg $swapTokensForExactETH$ perform user actions after $_swap$ is called. This is not ideal, as we do not want to interfere with the user swap. Moreover, other swap variants such as $swapExactTokensForTokensSupportingFeeOnTransferTokens$ do not use $_swap$. Backrun functions were therefore placed at the end of each external swap variant. E.g.
Multiple factories (at least 2) are required for the backrun arbitrage. The adoption of multiple factories within the router, lead to some internal function changes. In particular $pairFor$.
Since the extra factory is required for the arbitrage, we can use it, for the user, to check for an available swap on the alternate factory if it would otherwise fail on the default factory through slippage.
ABDKMath \footnote{$https://github.com/abdk-consulting/abdk-libraries-solidity$} library was used for a time, as it avoided overflow by dropping to floats.
456
-
457
-
ABDKMath Example
497
+
\subsubsection{ABDKMath}
498
+
\text{ABDKMath library was used for a time, as it avoided overflow by dropping to floats.}\footnote{$https://github.com/abdk-consulting/abdk-libraries-solidity$}
458
499
\begin{minted}{lexer.py:SolidityLexer -x}
459
500
bytes16 _Cg = ABDKMathQuad.fromUInt(Cg);
460
501
bytes16 _a = ABDKMathQuad.mul(_Cg, _Cg);
461
502
\end{minted}
462
503
463
-
However we found this lost precision and failed echidna tests.
464
-
\label{Uint256overflow:5}
465
-
\begin{lstlisting}
504
+
\text{However we found this lost precision and failed echidna tests.}
505
+
466
506
467
-
# echidna test
468
-
echidna_mulUint: failed!
507
+
\label{Uint256 overflow:5}
508
+
\begin{figure}
509
+
\centering
510
+
\caption{Uint256 overflow:5}
511
+
\label{fig:Echidna Uint56 Overflow Tests}
512
+
\begin{lstlisting}[style=Bash]
513
+
echidna_mulUint:
514
+
failed!
469
515
Call sequence:
470
516
setX1(1106235220955)
471
517
setX(9390953368914254812617)
472
518
473
-
474
-
echidna_Uint_convertion: failed!
519
+
echidna_Uint_conversion:
520
+
failed!
475
521
Call sequence:
476
522
setX(10518526264810785485368401065708505)
477
523
478
-
479
-
echidna_divUint: failed!
524
+
echidna_divUint:
525
+
failed!
480
526
Call sequence:
481
527
setX(10417774989007224423389698535018119)
482
528
setX1(1)
483
529
\end{lstlisting}
530
+
\end{figure}
484
531
532
+
\newpage
533
+
\subsubsection{PRBMath}
485
534
486
-
We also tried PRBMath\footnote{https://github.com/paulrberg/prb-math/} library. These faired better in echidna tests but still suffered overflow issues.
535
+
We also tried PRBMath\footnote{https://github.com/paulrberg/prb-math/} library. These performed better in echidna tests but still suffered overflow issues.
\text{Ultimately we settled on Uint512 which both passed echidna and overflow issue.}\footnote{see $github.com/SimonSuckut/Solidity_Uint512/blob/main/contracts/Uint512.sol$}
504
565
505
566
506
-
Ultimately we settled on Uint512 \footnote{see $github.com/SimonSuckut/Solidity_Uint512/blob/main/contracts/Uint512.sol$} which both passed echidna and overflow issue.
567
+
\begin{figure}
568
+
\centering
569
+
\caption{Uint512 }
570
+
\label{fig:Echidna Uint512 Tests}
507
571
\begin{lstlisting}
508
-
echidna_mulUint: passed!
509
-
echidna_divUint: passed!
572
+
echidna_mulUint: ~ passed!
573
+
echidna_divUint: ~ passed!
510
574
\end{lstlisting}
575
+
\end{figure}
511
576
512
577
513
-
514
-
\chapter{Conclusions and Future Work}
578
+
\section{Conclusions and Future Work}
515
579
516
580
\newpage
517
581
%
@@ -524,52 +588,53 @@ \chapter{Conclusions and Future Work}
0 commit comments