CoinEx Research: Eine Einführung zu den häufigsten Schwachstellen und Angriffen bei Smart Contracts

Was ist ein Smart Contract?

Bei Ethereum gibt es zwei gängige Arten von Konten: Externally Owned Accounts (EOA) und Smart Contract Accounts (SCA).

EOA sind den elektronischen Finanzkonten sehr ähnlich, die wir normalerweise verwenden, um Geld zu speichern und mit Anwendungen zu interagieren. Nutzer zahlen etwa Fiat-Währung über PayPal ein und interagieren mit verschiedenen Websites, Geschäften und Anwendungen, um Zahlungen zu tätigen. DeFi-Miner speichern in der Regel Kryptowährungen in ihren EOAs, interagieren mit DeFi dApps und zahlen Geld in dApps ein, um Gewinne zu erzielen. EOA haben jedoch eine Eigenschaft, die elektronische Finanzkonten nicht haben: Nutzer müssen ihre Kontrolle über EOA durch den Besitz privater Schlüssel verifizieren – Not Your Keys – Not Your Coins.

SCA sind ebenfalls eine Art Konto, das im Wesentlichen mit einem Segment von ausführbarem Bytecode (auch bekannt als Smart Contract) verbunden ist. Der Smart Contract beschreibt verschiedene Geschäftslogiken und dient als Backend für dApps. Obwohl Quasi-Turing-komplette Smart-Contracts im Vergleich zu herkömmlichen Turing-kompletten Entwicklungssprachen mehr Einschränkungen aufweisen, sind sie immer noch anfällig für zahlreiche Angriffe, die der Blockchain-Industrie zahlreiche Schläge versetzt haben.

Gängige Smart Contract Angriffe

1. Reentrancy-Angriff

Der häufigste und bekannteste Angriff ist der Reentrancy-Angriff, der für den Ethereum-Fork verantwortlich war, der zur Gründung von Ethereum Classic führte. Im Jahr 2016 führten Hacker einen Reentrancy-Angriff auf den DAO-Vertrag durch und stahlen 3.600.000 ETH im Wert von über 150 Millionen US-Dollar. Dieser Angriff, der sich in der Anfangsphase von Ethereum ereignete, zerstörte das Ökosystem und erschütterte das Vertrauen der Investoren, was schließlich zur Abspaltung führte.

Zum besseren Verständnis

Um das Prinzip des Reentrancy-Angriffs besser zu verstehen, folgt ein Beispiel. Bank B hat Bank A Geld geliehen. Eines Tages veranlasst Bank B eine Überweisung an Bank A, mit der Bitte, das gesamte Geld an Bank B zurückzuüberweisen:

• Schritt 1: Bank B fordert das Geld an
• Schritt 2: Bank A überweist den Betrag an Bank B
• Schritt 3: Bank A bestätigt Bank B die erfolgreiche Überweisung
• Schritt 4: Bank A aktualisiert den Kontostand von Bank B.

Wenn Bank B jedoch nach Schritt 2 ein Schlupfloch schafft und weiterhin das gesamte Geld von Bank A anfordert, ohne dies in Schritt 3 zu bestätigen, bleibt der Kontostand von Bank A bei Bank B unverändert. Durch diese wiederholten Anforderungen wird das gesamte Guthaben von Bank A aufgezehrt.

Ähnliche Smart Contracts

Der Vertrag von Bank A umfasst zwei Funktionen:

• deposit(): Eine Einzahlungsfunktion, die Geld auf Bank A einzahlt und den Kontostand des Benutzers aktualisiert;
• withdraw(): Eine Auszahlungsfunktion, die es den Nutzern ermöglicht, ihr gesamtes Geld von Bank A abzuheben.

Der Angriffskontrakt von Bank B besteht im Wesentlichen aus einer Schleife, die die Callback-Funktion receive() auslöst, die ihrerseits die Funktion withdraw() des Bankkontrakts aufruft, um das Guthaben von Bank A durch eine Abfolge von 1 Einzahlung, 1 Auszahlung und 1 Aufruf der Callback-Funktion receive() abzuheben und schließlich den Saldo von B in A zu aktualisieren:

• Receive(): Eine Callback-Funktion, die ausgelöst wird, wenn ETH empfangen wird, und die wiederholt die withdraw()-Funktion des Bankkontrakts aufruft, um Auszahlungen vorzunehmen.
• Attack(): Sie ruft zunächst die Funktion deposit() des Bankkontrakts auf, um den Kontostand zu aktualisieren, dann die Funktion withdraw(), um die erste Auszahlung zu veranlassen, und löst schließlich die Callback-Funktion receive() aus, die wiederum die Funktion withdraw() aufruft, um den Kontostand des Bankkontrakts zu verringern.

Lösung

Einrichtung einer Wiedereintrittssperre

Eine Wiedereintrittssperre ist ein Modifikator, der den Wiedereintritt verhindert und sicherstellt, dass ein Aufruf abgeschlossen sein muss, bevor er erneut aufgerufen werden kann. Da beispielsweise der Angriff der Bank B einen mehrfachen Aufruf der Funktion withdraw() des Bankvertrags erfordert, wird er mit einer Wiedereintrittssperre (Reentrancy Lock) scheitern.

Anleitung

2. Fehlanwendung von tx.origin

Die Hauptfunktion von tx.origin in einem Smart Contract ist das Abrufen des ursprünglichen Kontos, das die Transaktion initiiert hat. Im Folgenden werden wir zwei gängige Variablen in Smart Contracts diskutieren: msg.sender und tx.origin. msg.sender ruft das Konto direkt beim Aufruf des Smart Contracts ab, während in der Blockchain-Welt aufgrund der verschachtelten und wechselseitigen Aufrufe verschiedener Smart Contracts (wie DeFi Lego) tx.origin benötigt wird, um das ursprüngliche Konto zu erhalten, das die Transaktion initiiert hat. Eine Schwachstelle entsteht, wenn dApp-Entwickler nur die Sicherheit von tx.origin im Code überprüfen und die Überprüfung der Sicherheit von Angreifern vernachlässigen, die Zwischenverträge verwenden, um tx.origin zu umgehen und Angriffe zu starten.

Zum besseren Verständnis

Hier ein Beispiel, das ein gängiges Angriffsszenario veranschaulicht. Bill hat eine Smart Wallet, das überprüft, ob Bill der Initiator einer Überweisung ist. Einmal hat Bill eine NFT auf einer Phishing-Website geprägt. Dadurch konnte die Website die Identität von Bill herausfinden und eine Überweisung von seiner Smart Wallet mit seiner Identität veranlassen, was zu einem Vermögensverlust führte.

Unter normalen Umständen tappen Benutzer seltener in diese Falle, aber wenn sie mit dApps über ein Wallet interagieren, vergessen sie oft, die Interaktionsaufforderungen zu überprüfen. Wenn etwa beide die Funktion Mint() enthalten, können unvorsichtige Nutzer leicht in eine Phishing-Falle tappen. Die Logik von Phishing-Websites ist voller Fallen, daher ist es wichtig, die Interaktionsaufforderungen bei regelmäßigen Interaktionen auf Fehler zu überprüfen.

Smart Wallet Contract

Der Smart Wallet Contract beinhaltet eine Funktion:

• transfer(): Eine Auszahlungsfunktion, die nur vom Wallet-Inhaber, in diesem Fall Bill, initiiert werden kann.

Phishing Attack Contract

In einem Phishing Attack Contract bringt Mint() den Benutzer dazu, Geld an die Adresse eines Hackers zu überweisen. Sie enthält eine Funktion:

• Mint(): Nach dem Aufruf führt die Phishing-Funktion intern transfer() des Wallet Contracts aus. Da der ursprüngliche Initiator der Nutzer (in diesem Beispiel Bill) selbst ist, stellt die Überprüfung require(tx.origin == owner, „Not owner“); kein Problem dar. Allerdings wurde die Zieladresse für die Überweisung bereits auf die Adresse des Hackers geändert, was zu einem Diebstahl des Geldes führt.

Lösungen

1. Verwende msg.sender anstelle tx.origin

Unabhängig davon, wie viele Vertragsaufrufe involviert sind (Vertrag A → Vertrag B → …→ Zielvertrag), verifiziere nur msg.sender, d. h. den direkten Aufrufer, um Angriffe durch böswillige Zwischenverträge zu vermeiden.

2. Verifiziere tx.origin == msg.sender

Diese Methode kann bösartige Verträge fernhalten, aber die Entwickler müssen ihre eigenen Geschäftspraktiken berücksichtigen, da sie effektiv alle anderen externen Vertragsaufrufe isoliert.

3. Zufallszahlengeneratorangriff (RNG Attack)

Dies geht zurück auf den dApp-Trend für Glücksspiele und Wetten in den Jahren 2018 und 2019. In der Regel verwenden Entwickler/innen bestimmte Seeds in Smart Contracts, um Zufallszahlen für die Auswahl der Gewinner/innen bei Ziehungen zu generieren. Gängige Seeds sind block.number, block.timestamp, blockhash und keccak256. Miner haben jedoch die volle Kontrolle über diese Seeds, so dass böswillige Miner in einigen Fällen die Variablen manipulieren können, um sich einen Vorteil zu verschaffen.

Allgemeine Dice Contracts

Ein Dice Contract beinhaltet 1 Funktion:

• Bet(): Eine Wettfunktion, bei der die Nutzer eine Wettnummer eingeben und einen ETH einzahlen. Wenn die Wettnummer mit der Zufallszahl übereinstimmt, gewinnt der Nutzer den gesamten Preispool.

Miner Attack Contract

Miner können gewinnen, solange sie die gewinnende Zufallszahl vorberechnen und im selben Block ausführen. Dazu gehört eine Funktion:

• attack(): Eine Betting-Attack-Funktion, bei der der Miner die gewinnende Zufallszahl vorhersagt. Da sie im selben Block ausgeführt wird, sind blockhash(block.number – 1) und block.timestamp im selben Block identisch. Anschließend ruft der Miner Bet() im Dice Contract auf, um den Angriff abzuschließen.

Lösung

Verwendung von Off-Chain-Zufallszahlen, die von Oracle-Projekten zur Verfügung gestellt werden.

Oracle-Projekte wie Chainlink ermöglichen die Einspeisung von Zufallszahlen in On-Chain-Verträge, um Zufälligkeit und Sicherheit zu gewährleisten. Oracle-Projekte bergen jedoch auch Zentralisierungsrisiken, weshalb ausgereiftere Oracle-Dienste erforderlich sind.

4. Replay-Angriff

Bei einem Replay-Angriff wird eine Transaktion mit einer zuvor verwendeten Signatur erneut initiiert, um Geld zu stehlen. Einer der bekanntesten Replay-Angriffe der letzten Jahre war der Diebstahl von 20 Millionen $OP-Token des Market Makers Wintermute auf Optimism, bei dem es sich um einen kettenübergreifenden Replay-Angriff handelte.

Da das Multi-Signatur-Wallet-Konto von Wintermute nur vorübergehend im Ethereum-Mainnet verwendet wurde, nutzte der Hacker die Signatur der Transaktion für die Verwendung der Multi-Signatur-Adresse von Wintermute auf Ethereum, um dieselbe Transaktion auf der Optimism-Kette erneut auszuführen und so die Kontrolle über das Multi-Signatur-Wallet-Konto auf Optimism zu erlangen.

Ein Multi-Signature-Wallet-Konto ist im Wesentlichen ein Smart-Contract-Konto, was auch einen wesentlichen Unterschied zwischen SCA und EOA aufzeigt. Für ein EOA benötigt ein normaler Nutzer nur einen privaten Schlüssel, um alle Adressen auf Ethereum- und EVM-kompatiblen Blockchains zu kontrollieren (die Adressstrings sind genau gleich), während ein SCA nach der Bereitstellung nur auf einer Blockchain gültig ist.

Zum besseren Verständnis

Hier ein Beispiel für einen typischen Replay-Angriff (Same Chain Replay Attack). Bill hat eine Smart Wallet, in die er vor jeder Transaktion seine elektronische Signatur eingeben muss. Nachdem die Hackerin Lucy Bills elektronische Signatur gestohlen hat, kann sie eine unbegrenzte Anzahl von Transaktionen durchführen, um Bills Smart Wallet zu leeren.

Beispiel

Ein Vertrag mit Schwachstellen besteht aus drei Funktionen:

• checkSig(): ECDSA Verifikationsfunktion, die sicherstellt, dass das Verifikationsergebnis mit dem ursprünglich eingestellten Unterzeichner übereinstimmt.
• getMsgHash(): Funktion zur Erzeugung eines Hash durch Kombination von „to“ und „amount“ zu einem Hash.
• transfer(): Transferfunktion, die es den Nutzern ermöglicht, Geld aus dem Liquiditätspool abzuheben. Da es keine Beschränkungen für die Signatur gibt, kann dieselbe Signatur wiederverwendet werden, was es Hackern ermöglicht, kontinuierlich Geld zu stehlen.

Lösung

Fügt eine nonce in die Signaturkombination ein, um Replay-Angriffe zu verhindern. Das Prinzip des Parameters ist wie folgt:

• nonce: Sie beschreibt die Variable für die Anzahl der Transaktionen eines EOA im Blockchain-Netzwerk. Sie ist geordnet und eindeutig. Mit jeder zusätzlichen Transaktion erhöht sich der nonce-Wert um 1. Das Blockchain-Netzwerk prüft, ob die nonce der Transaktion mit der aktuellen nonce des Kontos übereinstimmt. Ein Hacker würde also scheitern, wenn er eine verwendete Signatur verwendet, weil der nonce-Wert der Signaturkombination kleiner ist als der aktuelle nonce-Wert des EOA.

5. Denial of Service (DoS) Angriff

Denial of Service (DoS)-Angriffe sind in der traditionellen Web2.0-Welt nichts Neues. Er bezieht sich auf jede Störung eines Servers, z. B. durch das Versenden einer großen Menge von Junk- oder Störinformationen, die die Verfügbarkeit beeinträchtigen oder vollständig zerstören. Auch Smart Contracts sind solchen Angriffen ausgesetzt, die im Wesentlichen darauf abzielen, den Smart Contract funktionsunfähig zu machen.

Zum besseren Verständnis

Betrachten wir ein Beispiel. Projekt A führt ein Public Offering für das Protokoll-Token durch, bei dem alle Nutzer Geld in den Liquiditätspool (Smart Contract) einzahlen können, um Kontingente nach dem Prinzip „Wer zuerst kommt, mahlt zuerst“ zu erwerben. Überschüssige Mittel werden an die Teilnehmer zurückgegeben.

Hacker Alice nutzt den Angriffsvertrag aus, um am öffentlichen Angebot teilzunehmen. Sobald der Liquiditätspool versucht, Gelder an Alices Angriffskontrakt zurückzugeben, wird ein DoS-Angriff gestartet, der verhindert, dass die Rückgabeaktion überhaupt durchgeführt werden kann. Infolgedessen ist eine große Menge an Geldern im Smart Contract blockiert.

Beispiel

Der Public Offering Contract enthält zwei Funktionen:

• deposit(): Einzahlungsfunktion, die die Adresse des Einzahlers und den eingezahlten Betrag speichert.
• refund(): Rückzahlungsfunktion, mit der das Projektteam Gelder an die Investoren zurückzahlt.

DoS-Angriffskontrakt

Der DoS-Angriffskontrakt enthält eine Funktion:

• attack(): Obwohl es sich um eine Angriffsfunktion handelt, ist sie nicht problematisch. Das Hauptproblem liegt in der im Hacker-Kontrakt eingebauten Funktion receive(), die eine Reihe von Ausnahmen enthält. Jeder externe Vertrag, der Geld an den Hacker-Kontrakt überweist, löst über revert() eine Ausnahme aus und verhindert so den Abschluss der Transaktion.

Lösungen

1. Vermeidung der Blockierung kritischer Funktionen beim Abruf externer Verträge

Entferne require(success, „Refund Fail!“); aus der obigen refund()-Funktion des PublicSale-Vertrags, um sicherzustellen, dass die Rückerstattung auch dann fortgesetzt werden kann, wenn die Rückerstattung an eine einzelne Adresse fehlschlägt.

2. Abkopplung

In der obigen refund()-Funktion des PublicSale-Vertrags kann den Benutzern erlaubt werden, die Rückerstattung selbst zu beantragen, anstatt sie zu verteilen, um unnötige Interaktionen mit externen Verträgen zu vermeiden.

6. Permit-Angriff

Bei einem Permit-Angriff stellt Konto A die Signatur für eine bestimmte Partei im Voraus zur Verfügung. Nachdem Konto B die Signatur erhalten hat, kann es autorisierte Token-Transfers durchführen, um eine bestimmte Menge an Token zu stehlen. Im Folgenden werden insbesondere zwei gängige Funktionen zur Token-Autorisierung in Smart Contracts behandelt: approve() und permit().

In einem herkömmlichen ERC20-Vertrag kann Konto A approve() aufrufen, um eine bestimmte Menge an Token für Konto B zu autorisieren, sodass Konto B diese Token von Konto A übertragen kann. Zusätzlich wurde permit() in EIP-2612 in ERC20 Verträge aufgenommen und Uniswap hat im November 2022 einen neuen Token-Autorisierungsstandard, Permit2, veröffentlicht.

Zum besseren Verständnis

Hier ist ein Beispiel. Eines Tages surfte Bill auf einer Blockchain-Nachrichtenwebsite, als plötzlich ein Pop-up-Fenster mit einer Metamask-Signatur erschien. Da viele Blockchain-Websites oder -Anwendungen Signaturen verwenden, um Benutzeranmeldungen zu verifizieren, dachte sich Bill nicht viel dabei und signierte direkt. Fünf Minuten später war sein Metamask-Guthaben verschwunden.

Bill entdeckte dann im Blockchain Explorer, dass eine unbekannte Adresse eine permit()-Transaktion initiiert hatte, gefolgt von einer transferFrom()-Transaktion, die seine Wallet leerte.

Beispiel

Die zwei Funktionen sind wie folgt:

• approve(): Eine Standard-Autorisierungsfunktion, bei der Konto A einen bestimmten Geldbetrag für Konto B autorisiert.
• permit(): Eine Signatur-Autorisierungsfunktion, bei der Konto B die Signaturprüfung einreicht und abschließt, um den autorisierten Betrag von Konto A zu erhalten. Zu den Parametern gehören der autorisierende Eigentümer, der zu autorisierende Spender, der autorisierte Betrag, die Signaturfrist und die Signaturdaten v, r und s des Eigentümers.

Lösungen

1. Achte bei On-Chain-Interaktionen auf jede Signatur

Trotz der Maßnahmen, die einige Wallets ergreifen, um die Informationen der Genehmigungssignatur approve() zu entschlüsseln und anzuzeigen, bieten sie praktisch keine Warnung vor Phishing von permit()-Signaturen, was das Risiko von Angriffen erhöht. Es wird daher dringend empfohlen, jede unbekannte Signatur sorgfältig zu prüfen, um sicherzustellen, dass sie auf die Funktion permit() abzielt.

2. Trenne die Wallet für regelmäßige Interaktionen von der Wallet, in der die Vermögenswerte gespeichert sind

Dies ist essenziell für Krypto-Benutzer, insbesondere für Airdrop-Jäger, da sie täglich mit unzähligen dApps oder Websites interagieren und anfällig für Betrugsversuche sind. Wenn man nur einen kleinen Betrag für regelmäßige Interaktionen in einer Wallet speichert, kann man die Verluste begrenzen.

7. Honeypot Angriff

In der Blockchain-Branche bezieht sich ein Honeypot-Angriff auf eine Art von bösartigen Token-Verträgen, die von Projektteams verwendet werden. Der Vertrag erlaubt nur dem Projektteam zu verkaufen, während normale Nutzer nur kaufen, aber nicht verkaufen können und somit Verluste erleiden.

Zum besseren Verständnis

Hier ist ein Beispiel. In einer Ankündigung auf Telegram informiert Projekt A die Nutzer, dass der Token im Mainnet bereitgestellt wurde und zum Handel zur Verfügung steht. Da der Token nur gekauft und nicht verkauft werden kann, schießt der Preis zunächst in die Höhe und die Nutzer, die befürchten, etwas zu verpassen, kaufen weiter. Nach einiger Zeit, als die Nutzer den Token nicht mehr verkaufen können, nutzt das Projektteam die Gelegenheit und verkauft die Token, wodurch der Preis in den Keller geht.

Beispiel

Hauptfunktion:

• _beforeTokenTransfer(): Eine interne Funktion, die bei Token-Transfers aufgerufen wird. Sie kann nur erfolgreich sein, wenn sie vom Besitzer aufgerufen wird; Aufrufe von anderen Konten schlagen fehl.

Lösung

Security Scanning Tools verwenden

1. Token Sniffer für Ethereum Token
2. Ave Check für Token anderer Blockchains
3. Websites mit eingebauten Erkennungstools wie Dextools

Vermeide den Handel mit Token, die einen niedrigen Score haben

8. Front-Running-Angriff

Frontrunning entstand ursprünglich auf traditionellen Finanzmärkten, wo Informationsasymmetrien es Finanzintermediären ermöglichten, durch schnelles Handeln auf der Grundlage spezifischer Brancheninformationen Gewinne zu erzielen.

In der Blockchain-Branche ist Frontrunning vor allem auf das On-Chain-Frontrunning zurückzuführen, bei dem Miner manipuliert werden, um ihre eigenen Transaktionen in der Blockchain zu priorisieren und so Gewinne zu erzielen.

In der Blockchain können Miner einen Gewinn erzielen, indem sie die Transaktionen, die sie in Blöcke packen, manipulieren, z. B. indem sie bestimmte Transaktionen ausschließen oder neu anordnen. Dieser Gewinn kann mit dem Miner Extractable Value (MEV) gemessen werden. Bevor die Transaktion eines Nutzers zum Ethereum-Mainnet hinzugefügt wird, wird die Mehrheit der Transaktionen im Mempool gesammelt.

Miner suchen in diesem Mempool nach Transaktionen mit höheren Gaspreisen und fügen diese vorrangig in Blöcke ein, um ihren Gewinn zu maximieren. Im Allgemeinen werden Transaktionen mit höheren Gaspreisen von den Minern leichter in Blöcke gepackt. Auch einige MEV-Bots durchsuchen den Mempool nach Transaktionen mit hoher Rentabilität.

Zum besseren Verständnis

Hier ist ein Beispiel. Bill entdeckt einen neuen heißen Token mit starken Preisschwankungen. Um sicherzustellen, dass die Token-Transaktionen auf Uniswap erfolgreich sind, legt Bill eine außergewöhnlich große Slippage-Marge fest.

Unglücklicherweise entdeckt Alices MEV-Bot diese Transaktion im Mempool und erhöht sofort den Gaspreis, indem er eine Kauftransaktion vor Bills Transaktion und eine Verkaufstransaktion nach Bills Transaktion innerhalb desselben Blocks einfügt.

Nach der Blockbestätigung führt dies zu erheblichen Slippage-Verlusten für Bill, während Alice von einem Arbitragegeschäft profitiert, bei dem sie zu einem niedrigen Preis kauft und zu einem hohen Preis verkauft.

Beispiel

Die Funktion ist wie folgt:

• solve(): Eine Ratingfunktion, bei der jeder eine Antwort einreichen kann. Wenn die abgegebene Antwort mit der Zielantwort übereinstimmt, kann der Einsender 10 Ether erhalten.

Vorgang:

1. Bill findet die richtige Antwort.
2. Alice überwacht den Mempool und wartet darauf, dass jemand die richtige Antwort gibt.
3. Bill ruft solve() auf, um die Antwort zu senden, und setzt den Gaspreis auf 100 Gwei.
4. Alice sieht die von Bill gesendete Transaktion und findet die Antwort heraus. Sie setzt den Gaspreis höher als Bills 200 Gwei und ruft solve() auf.
5. Alice ihre Transaktion wird vom Miner vor der von Bill gepackt.
6. Alice erhält eine Belohnung von 10 Ether.

Lösung

Die drei wichtigsten Funktionen sind wie folgt:

• commitSolution(): Eine Funktion zum Übertragen der Ergebnisse, die die vom Nutzer übermittelte Antwort solutionHash, die Übermittlungszeit commitTime und den Status in die Commit-Struktur überträgt.
• getMySolution(): Eine Funktion zum Abrufen von Ergebnissen, die es den Nutzern ermöglicht, ihre eingereichten Antworten und die zugehörigen Informationen, einschließlich der eingereichten Antwort solutionHash, der Einreichungszeit commitTime und des Status, einzusehen.
• revealSolution(): Eine Funktion zum Einfordern von Belohnungen für das Erraten des Rätsels, nachdem die Nutzer ihre Antwort und das von ihnen festgelegte Passwort eingegeben haben.

Vorgang:

1. Bill findet die richtige Lösung.
2. Bill ruft commitSolution() auf, um die richtige Antwort zu übermitteln.
3. Im nächsten Block ruft Bill revealSolution() auf und übermittelt die Antwort und das Passwort, das er festgelegt hat, um die Belohnung zu erhalten.

In commitSolution() übermittelt Bill einen verschlüsselten String und behält die Klartextdaten, die er übermittelt hat, für sich. In diesem Schritt wird auch die Übertragungsblockzeit commitTime aufgezeichnet. Als Nächstes wird die Blockzeit in revealSolution() überprüft, um Frontrunning innerhalb desselben Blocks zu verhindern.

Da der Aufruf von revealSolution() die Übermittlung der Klartextantwort erfordert, soll dieser Schritt verhindern, dass andere commitSolution() umgehen und direkt revealSolution() aufrufen. Nach erfolgreicher Verifikation wird die Belohnung ausgezahlt, wenn die Antwort als korrekt befunden wurde.

Fazit

Smart Contracts spielen eine zentrale Rolle in der Blockchain-Technologie und bieten zahlreiche Vorteile. Erstens ermöglichen sie eine dezentralisierte und automatisierte Ausführung, die die Sicherheit und Zuverlässigkeit von Transaktionen ohne eine dritte Partei gewährleistet. Zweitens reduzieren Smart Contracts Zwischenschritte und Kosten und erhöhen so die Effizienz von Transaktionen.

Trotz dieser vielen Vorteile bergen Smart Contracts auch das Risiko von Angriffen, die zu finanziellen Verlusten der Nutzer führen können. Daher ist es wichtig, dass die Nutzer von On-Chain-Technologien bestimmte Gewohnheiten einhalten.

Erstens sollten Nutzer die dApps, mit denen sie interagieren möchten, immer sorgfältig auswählen und den Vertragscode und die damit verbundenen Regeln genau prüfen. Überdies sollten sie sichere Wallets und Tools zur Vertragsinteraktion regelmäßig aktualisieren und verwenden, um das Risiko von Hackerangriffen zu verringern.

Zudem ist es ratsam, Geld an mehreren Adressen zu speichern, um mögliche Verluste durch Vertragsangriffe zu minimieren.

Für die Akteure der Branche ist es ebenso wichtig, die Sicherheit und Stabilität von Smart Contracts zu gewährleisten. Die erste Priorität sollte darin bestehen, die Prüfung von Smart Contracts zu intensivieren, um potenzielle Schwachstellen und Sicherheitsrisiken zu identifizieren und zu beheben.

Zweitens sollten sich die Akteure der Branche über die neuesten Blockchain-Entwicklungen im Zusammenhang mit Vertragsangriffen auf dem Laufenden halten und entsprechende Sicherheitsmaßnahmen ergreifen.

Nicht zuletzt sollten sie auch die Aufklärung und das Sicherheitsbewusstsein der Nutzer im Hinblick auf die korrekte Verwendung von Smart Contracts verbessern.

Zusammenfassend lässt sich sagen, dass die Sicherheitsrisiken von Smart Contracts durch gemeinsame Anstrengungen der Nutzer und der Industrie erheblich reduziert werden können.

Die Nutzer sollten Smart Contracts stets mit Bedacht auswählen und ihr persönliches Eigentum schützen, während die Akteure der Branche die Prüfung von Verträgen intensivieren, sich über technologische Fortschritte auf dem Laufenden halten und die Aufklärung und das Sicherheitsbewusstsein der Nutzer verbessern sollten. Gemeinsam werden wir die sichere und zuverlässige Entwicklung von Smart Contracts vorantreiben.

Zuletzt aktualisiert am 6. Dezember 2023