Auch wenn Warteschlangen im Supermarkt oder an den Verkaufsstellen, in denen Sie Ihre Stromrechnungen bezahlen, der Vergangenheit angehören, wissen einige von uns, wie es sich anfühlt, wenn sich jemand anstellt.  Das heißt, ganz vorne in der Warteschlange. Vor allem, weil ihre Rechnung weitaus wertvoller ist als die der anderen, die in der Schlange stehen. Dies sollte natürlich kein Kriterium sein, wenn es um die Pünktlichkeit des Service geht.  Dieses Geschäft, in den Vordergrund gerückt zu werden, kommt nun auch bei Ethereum-Smart-Verträgen vor. Smart-Contract-Transaktionen, die höhere Gasgebühren zahlen, werden tendenziell stärker bevorzugt als solche, bei denen dies nicht der Fall ist.  Aufschlüsselung der vorherrschenden Schwachstelle  Auf den ersten Blick entsteht diese Schwachstelle nicht durch fehlerhafte Programmierung, sondern macht sich die Art und Weise zunutze, wie Transaktionen geordnet und einem Block aus dem „Mempool“ hinzugefügt werden.   Abgesehen von regulären Benutzern, die schnell Geld verdienen möchten, profitieren Miner in der Regel von einer solchen Transaktion und sind daher diejenigen, die am ehesten auf solche Transaktionen achten, bevor sie einem Block hinzugefügt werden. Sobald sie dies tun, senden sie tatsächlich eine eigene Transaktion gegen eine unfaire finanzielle Belohnung, die schließlich einem Block hinzugefügt wird und nicht dem, der zuerst gesendet wurde.  Dabei ist zu beachten, dass Transaktionen, die mit einem höheren Gaspreis vereinbart wurden, im Vergleich zu anderen tendenziell zuerst abgewickelt werden. Unter Berücksichtigung dieser Präferenz kann der Angreifer den Ausgang von Ereignissen wie Auktionen, Handel oder Initial Coin Offerings zu seinen Gunsten verändern, indem er einfach höhere Gasgebühren zahlt.  Schauen wir uns dieses häufige Beispiel an, um zu verstehen, wie die Frontrunning-Sicherheitslücke funktioniert:   In diesem Beispiel haben wir drei Schauspieler: Naman, Kaavya und Aishwarya. Naman setzt die Hashing-Herausforderung zunächst als intelligenten Vertrag ein, den die anderen beiden lösen müssen. Wer dieses Hashing-Rätsel löst, erhält als Belohnung 10 Ether.   Jetzt findet Kaavya zuerst die Hashing-Lösung und sendet sie mit 10 Gwei als Gasgebühren aus ihrem eigenen Smart-Vertrag:   Aishwarya hingegen findet die Antwort wenig später und übergibt die richtige Antwort an ihren Smart-Vertrag mit 100 Gwei als Gasgebühren.   Da Kaavya höhere Benzingebühren zahlt, erhält Aishwarya die Belohnung von 10 Ether, wie unten gezeigt:   Einfach ausgedrückt handelt es sich hierbei um den Frontrunning- oder Transaktionsreihenfolgefehler, da Transaktionen auf der Grundlage des Werts der Gasgebühr verarbeitet werden.  Mit anderen Worten: Auch wenn Kaavya ihre Antwort vor Aishwarya einreicht, erhält sie für ihre Bemühungen nichts, wie unten gezeigt:   Da dieser „Reihensprung“ von Aishwarya weder bei Kaavya noch bei irgendjemandem anderen gut ankommt, müssen einige vorbeugende Maßnahmen für unseren Smart-Contract-Code in Betracht gezogen werden.  3 Möglichkeiten, mit der Frontrunning-Schwachstelle umzugehen  Jetzt gibt es Lösungen, die einen solchen Verlust verhindern können. Mit anderen Worten: Wir sollten in der Lage sein, eine Transaktion als diejenige festzulegen, die die 10 Ether erhalten soll.   Methode 1: Transaktionszähler  Die Verwendung eines Transaktionszählers ist eine der einfachsten Möglichkeiten, andere davon abzuhalten, die Belohnung auf andere Weise zu erhalten.  Wie Sie dem unten hinzugefügten Code entnehmen können, wurde ein Transaktionszähler hinzugefügt, der die Transaktion sperrt, die von der Person ausgeführt wurde, die die Hashing-Herausforderung zuerst abgeschlossen hat. Da nur der Erste, der dies tut, die Belohnung erhalten muss, weisen wir alle Teilnehmer darauf hin, bei ihrer Lösung den Wert 0 hinzuzufügen.   Da der aktuelle Wert von txCounter für die erste präsentierte Lösung Null ist, wird er gesperrt. Mit anderen Worten, und wie im obigen Beispiel gibt Kaavya ihre Lösung sowie den Wert Null ein, um ihre Belohnung von 10 Ether zu erhalten .   Sollte dies jemand anderes tun, wird die Lösung nicht akzeptiert, da der Transaktionszähler auf einen Wert größer als eins erhöht wurde. Zu diesem Zeitpunkt wird die gesamte Belohnung von 10 Ether, die an Kaavya gehen sollte, ordnungsgemäß an sie überwiesen.   Methode 2: Gasgrenzwerte festlegen  Bei dieser Methode liegt der Fokus nun auf der Festlegung eines Gaslimits für alle Transaktionen. Sowohl eine untere als auch eine obere Grenze, falls erforderlich.  Wie Sie sich vielleicht erinnern, werden Transaktionen auf der Grundlage der für diese Transaktion gezahlten Gasgebühren geordnet. Auch wenn diese Reihenfolge dadurch möglicherweise nicht vollständig beseitigt wird, wird sie dadurch sicherlich erheblich reduziert.  Wenn Sie sich den folgenden Code ansehen, werden alle Transaktionen, die Benzin in Höhe von 1 oder weniger bezahlen, durchgeführt, aber diejenigen, die versuchen, die Grenze zu überschreiten, indem sie mehr Benzin zahlen, werden dies dank des gasThrottle-Modifikators nicht tun. In diesem Fall könnten 1 Wei oder Gwei die Standardkosten für die Abwicklung einer solchen Transaktion sein, und das ist alles, was zulässig ist.   Wenn sich also aufgrund dieser Drosselung nicht alle Transaktionen im Gasbereich stark unterscheiden, stellt sich die Frage, ob bestimmten Transaktionen der Vorzug gegeben wird, nicht. Obwohl ein solcher Ansatz Vorteile bietet, wird sich die gezahlte Gasgebühr in Zukunft zwangsläufig ändern.  Was heute hoch ist, wird in ein paar Jahren niedrig sein, also muss Naman jederzeit darauf achten. Oder Aish könnte diese sich ändernden Werte möglicherweise ausnutzen, indem sie einfach eine Weile wartet.   Methode 3: Der U-Boot-Send-Ansatz  Während die beiden vorherigen Ansätze möglicherweise für einfachere Situationen funktionieren, gehen sie nie wirklich auf die eigentliche Ursache der größten Schwachstelle ein: die vollständige Offenlegung von Transaktionsinformationen sowohl für Miner als auch für andere böswillige Benutzer.  Es sollte offensichtlich sein, dass die Chance, das System auszutricksen, bestehen bleibt, solange diese beiden Parteien Zugriff auf die Informationen jeder Transaktion haben. Offensichtlich ist eine Methode erforderlich, mit der diese zeitkritischen Informationen ausgeblendet werden müssen und die uns zum U-Boot-Send-Ansatz bringt, der als Teil der   Smart-Contract-Bibliothek implementiert wird.  LibSubmarine-  Wenn man diesen Ansatz verwendet, werden die Transaktionsinformationen so ausgeblendet, dass Miner oder normale Benutzer keinen wirklichen Vorteil daraus ziehen können. Die Verschlüsselung spielt eine große Rolle beim Schutz dieser Informationen, die nach dem Ermessen des Eigentümers offengelegt werden können, sobald sie einem Block hinzugefügt werden.  Auch wenn dieser Ansatz nicht perfekt ist, ist das Schutzniveau, das er bietet, im Vergleich zu den anderen Methoden weitaus besser, da er bereit ist, den wahren Grund für Front-Running anzugehen – sowohl in der realen Welt als auch auf der Blockchain.  Andere Strategien zur Umgehung der vordergründigen Sicherheitslücke  Natürlich sind die im vorherigen Abschnitt besprochenen Strategien nicht die einzigen, die Smart Contracts vor der „Front-Running“-Schwachstelle schützen.  Bei Seitenketten erfolgt die Bestellung außerhalb der Kette, während die Abwicklung dort erfolgt. Da diese beiden Schritte auf unterschiedlichen Plattformen stattfinden, hat dies nicht nur Vorteile für einen höheren Durchsatz, sondern wird auch Miner oder normale Benutzer davon abhalten, an die Informationen zu gelangen, die zum Ausnutzen der vordergründigen Schwachstelle erforderlich sind.   Eine andere Strategie, auch wenn sie theoretischer Natur ist, besteht darin, die Reihenfolge der Transaktionen für eine bestimmte Runde, die in einem Commit-Reveal-Schema festgeschrieben wurde, zufällig festzulegen. Dies wird mithilfe einer intelligenten Vertragslogik durchgesetzt. Spitzenreiter kommen mit diesem Ansatz nicht an die Spitze, da die Reihenfolge durch den oben genannten Smart Contract bestimmt wird.  Ein weiterer Ansatz schließlich beinhaltet die Implementierung des   , bei dem Benutzer überprüfbare Verzögerungsfunktionen für den wichtigen T-Wert lösen, der bestimmt, wer die Bestellung erhält. Dadurch, dass man sich von dem zufälligen Reihenfolgesystem, das die meisten Blockchains verwenden, entfernen kann, wird auch die Möglichkeit von Frontrunning-Angriffen verringert. Injective Protocol

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

The writer is smart, but don't just like, take their word for it. #DoYourOwnResearch

So beheben Sie die vordergründige Sicherheitslücke in Smart Contracts

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon Decoded 2024: Celebrating Our Life Hacking Community!

HackerNoon's DeFi Writing Contest with SORA Network: XSTUSD Use Cases

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

HackerNoon Decoded 2024: Celebrating Our Programming Community!

HackerNoon Decoded 2024: Celebrating Our Life Hacking Community!

HackerNoon's DeFi Writing Contest with SORA Network: XSTUSD Use Cases

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

HackerNoon Decoded 2024: Celebrating Our Programming Community!

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps