Was ist ein Smart Contract?

Ethereum hat zwei häufige Arten von Konten: Extern verwaltete Konten (EOA) und Smart-Contract-Konten (SCA).

EOAs ähneln sehr den elektronischen Finanzkonten, die wir üblicherweise zur Aufbewahrung von Geldmitteln und zur Interaktion mit Anwendungen verwenden. Beispielsweise zahlen Benutzer Fiatgeld über PayPal ein und interagieren mit verschiedenen Websites, Geschäften und Apps für Zahlungen. DeFi-Miner bewahren Kryptowährungen normalerweise in ihren EOAs auf, interagieren mit DeFi-dApps und hinterlegen Gelder in dApps, um Gewinne zu erzielen. EOAs haben jedoch eine Besonderheit, die elektronische Finanzkonten nicht besitzen: Die Kontrolle der Benutzer über EOAs muss durch den Besitz privater Schlüssel verifiziert werden - nicht deine Schlüssel, nicht deine Münzen.

SCAs sind ebenfalls eine Art Konto, das im Wesentlichen mit einem ausführbaren Bytecode-Segment (auch als Smart Contract bekannt) verbunden ist. Der Smart Contract beschreibt verschiedene Geschäftslogiken und dient als Backend für dApps. Trotz größerer Einschränkungen im Vergleich zu traditionellen Turing-vollständigen Entwicklungssprachen waren quasi-Turing-vollständige Smart Contracts dennoch anfällig für zahlreiche Angriffe, die der Blockchain-Branche unzählige Schläge versetzt haben.

Häufige Angriffe auf Smart Contracts

1. Reentrancy-Angriff

Der häufigste und berüchtigtste Angriff ist der Reentrancy-Angriff, der für die Ethereum-Abspaltung verantwortlich war, die zur Entstehung 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 damaligen Wert von über 150 Millionen Dollar. Dieser Angriff, der in den frühen Stadien von Ethereum stattfand, verwüstete das Ökosystem und erschütterte das Vertrauen der Investoren, was schließlich zu einer Abspaltung führte.

Spezifische Logik

Hier ein Beispiel, um das Prinzip des Reentrancy-Angriffs besser zu verstehen. Bank B hat Bank A zuvor Geld geliehen. Eines Tages initiiert Bank B eine Überweisung an Bank A und fordert die Rücküberweisung des gesamten Geldes an Bank B. Der normale Ablauf ist wie folgt:

Schritt 1: Bank B fordert die Auszahlung der Gelder an

Schritt 2: Bank A überweist die Gelder an Bank B

Schritt 3: Bank A bestätigt die erfolgreiche Überweisung an Bank B

Schritt 4: Bank A aktualisiert den Kontostand von Bank B.

Wenn Bank B jedoch nach Schritt 2 eine Lücke schafft und weiterhin ohne Bestätigung in Schritt 3 das gesamte Geld von Bank A anfordert, bleibt der Kontostand von Bank A bei Bank B unverändert. Dieser rekursive Aufruf wird alle Vermögenswerte von Bank A aufbrauchen.

Zugehörige Smart Contracts

Der Vertrag von Bank A umfasst zwei Funktionen:

deposit(): Eine Einzahlungsfunktion, die Geld in Bank A einzahlt und den Kontostand des Benutzers aktualisiert;
withdraw(): Eine Auszahlungsfunktion, die es Benutzern ermöglicht, alle ihre Gelder von Bank A abzuheben.

Der Angriffsvertrag von Bank B beinhaltet hauptsächlich eine Schleife, die die receive() Callback-Funktion auslöst, welche wiederum die withdraw() Funktion des Bank-Vertrags aufruft, um die Vermögenswerte von Bank A durch eine Abfolge von 1 Einzahlung, 1 Auszahlung und receive() Callback-Funktionsaufrufen zu entleeren und schließlich den Kontostand von B in A zu aktualisieren. Er umfasst zwei Funktionen:receive(): Eine Callback-Funktion, die beim Empfang von ETH ausgelöst wird und rekursiv die withdraw() Funktion des Bank-Vertrags aufruft, um Auszahlungen vorzunehmen.
attack(): Diese Funktion ruft zuerst die deposit() Funktion des Bank-Vertrags auf, um den Kontostand zu aktualisieren, und dann die withdraw() Funktion, um die erste Auszahlung zu initiieren. Dadurch wird die receive() Callback-Funktion ausgelöst, die rekursiv withdraw() aufruft, um die Vermögenswerte des Bank-Vertrags zu entleeren.

Lösung

Implementierung einer Wiedereintrittssperre

Eine Wiedereintrittssperre ist ein Modifikator, der verwendet wird, um Wiedereintritte zu verhindern und sicherzustellen, dass ein Aufruf seine Ausführung abschließen muss, bevor er erneut aufgerufen werden kann. Zum Beispiel wird der Angriff durch Bank B, der mehrfache Aufrufe der withdraw()-Funktion des Bank-Vertrags erfordert, mit der Implementierung einer Wiedereintrittssperre fehlschlagen.

Anwendung

2. Missbrauch von tx.origin

Die Hauptfunktion von tx.origin in einem Smart Contract besteht darin, das ursprüngliche Konto abzurufen, das die Transaktion initiiert hat. Hier besprechen wir zwei gängige Variablen in Smart Contracts: msg.sender und tx.origin . msg.sender ruft das Konto ab, das den Smart Contract direkt aufruft, während in der Blockchain-Welt aufgrund der verschachtelten und gegenseitigen 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 im Code nur die Sicherheit von tx.origin überprüfen und dabei die Sicherheitsüberprüfung von Angreifern vernachlässigen, die Zwischenverträge einsetzen, um tx.origin zu umgehen und Angriffe zu starten.

Spezifische Logik

Hier ist ein Beispiel, um Sie tief in das gängige Angriffsszenario einzuführen. Bill hat eine Smart Wallet, die überprüft, ob Bill der Initiator einer Überweisung ist. Einmal prägte Bill ein NFT auf einer Phishing-Website. Dadurch konnte die Website Bills Identität erlangen und unter Verwendung seiner Identität eine Überweisung von seiner Smart Wallet initiieren, was zu Vermögensverlusten führte. Unter normalen Umständen ist es weniger wahrscheinlich, dass Benutzer auf diese Falle hereinfallen, aber bei der Interaktion mit dApps über eine Wallet vergessen sie oft, die Interaktionsaufforderungen zu überprüfen. Wenn beispielsweise beide die Mint()-Funktion beinhalten, können unvorsichtige Benutzer leicht in eine Phishing-Falle tappen. Die Geschäftslogik innerhalb der Phishing-Website ist voller Fallen, daher ist es wichtig, während regulärer Interaktionen die Interaktionsaufforderungen auf Fehler zu überprüfen.

Smart Wallet Contract

Der Smart Wallet Contract umfasst eine Funktion:

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

Phishing-Angriffsvertrag

In einem Phishing-Angriff-Vertrag verleitet Mint() Benutzer dazu, Gelder an die Adresse eines Hackers zu überweisen. Es enthält eine Funktion:

Mint(): Sobald aufgerufen, führt die Phishing-Funktion intern transfer() des Wallet-Vertrags aus. Da der ursprüngliche Initiator der Benutzer selbst ist (in diesem Beispiel Bill), wird die Überprüfung require(tx.origin == owner, "Not owner") kein Problem darstellen. Allerdings wurde die Zieladresse für die Überweisung bereits zur Adresse des Hackers manipuliert, was zum Diebstahl von Geldern führt.

Lösungen

1. Verwendung von msg.sender anstelle von tx.origin

Unabhängig davon, wie viele Vertragsaufrufe beteiligt sind (Vertrag A → Vertrag B →...→ Zielvertrag), wird nur msg.sender, also der direkte Aufrufer, verifiziert, um Angriffe durch bösartige Zwischenverträge zu vermeiden.

2. Verifizierung von tx.origin == msg.sender

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

3. Angriff auf den Zufallszahlengenerator (RNG)

Dies geht auf den Trend der Glücksspiel- oder Wett-dApps um 2018 und 2019 zurück. Typischerweise verwenden Entwickler bestimmte Seeds in Smart Contracts, um Zufallszahlen zu generieren und bei Ziehungen Gewinner auszuwählen. Übliche Seeds sind block.number, block.timestamp, blockhash und keccak256. Miner können diese Seeds jedoch vollständig kontrollieren, sodass in einigen Fällen böswillige Miner die Variablen manipulieren können, um davon zu profitieren.

Gängige Würfel-Verträge

Der Würfel-Vertrag enthält eine Funktion:

Bet(): Eine Wettfunktion, bei der Benutzer eine Wettnummer eingeben und ein ETH bezahlen. Mit mehreren Seeds wird eine Zufallszahl generiert, und wenn die Wettnummer mit der Zufallszahl übereinstimmt, gewinnt der Benutzer den gesamten Preispool.

Angriffs-Vertrag des Miners

Miner können gewinnen, solange sie die gewinnende Zufallszahl vorausberechnen und im selben Block ausführen. Dies umfasst eine Funktion:

attack(): Eine Wettangriffsfunktion, bei der der Miner die gewinnende Zufallszahl vorausberechnet. Da sie im selben Block ausgeführt wird, sind blockhash(block.number - 1) und block.timestamp im selben Block identisch. Dann ruft der Miner Bet() des Würfel-Vertrags auf, um den Angriff abzuschließen.

Lösung

Verwendung von Off-Chain-Zufallszahlen, die von Oracle-Projekten bereitgestellt werden

Durch Dienste, die von Oracle-Projekten wie Chainlink bereitgestellt werden, werden On-Chain-Zufallszahlen in On-Chain-Verträge injiziert, um Zufälligkeit und Sicherheit zu gewährleisten. Oracle-Projekte bergen jedoch auch Zentralisierungsrisiken, was reifere Oracle-Dienste erforderlich macht.

4. Replay-Angriff

Ein Replay-Angriff beinhaltet die erneute Initiierung einer Transaktion unter Verwendung einer zuvor verwendeten Signatur, um Gelder zu stehlen. Einer der bekanntesten Replay-Angriffe der letzten Jahre war der Diebstahl von 20 Millionen $OP-Token vom Market Maker Wintermute auf Optimism, was ein kettenübergreifender Replay-Angriff war. Da Wintermutes Multi-Signatur-Wallet-Konto vorübergehend nur im Ethereum-Mainnet bereitgestellt wurde, nutzte der Hacker die Signatur der Transaktion für Wintermutes Bereitstellung einer Multi-Signatur-Adresse 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-Signatur-Wallet-Konto ist im Wesentlichen ein Smart-Contract-Konto, was auch einen signifikanten Unterschied zwischen SCA und EOA zeigt. Bei einem EOA benötigt ein normaler Benutzer nur einen privaten Schlüssel, um alle Adressen auf Ethereum und EVM-kompatiblen Ketten zu kontrollieren (die Adresszeichenfolgen sind exakt gleich), während ein SCA nach der Bereitstellung nur auf einer Kette wirksam ist.

Spezifische Logik

Hier stellen wir ein Beispiel für einen typischen Replay-Angriff (Replay-Angriff auf derselben Kette) vor. Bill hat ein Smart Wallet, das von ihm verlangt, vor jeder Transaktion seine elektronische Signatur einzugeben, bevor sie ausgeführt werden kann. Jetzt, da die Hackerin Lucy Bills elektronische Signatur gestohlen hat, kann sie eine unbegrenzte Anzahl von Transaktionen initiieren, um Bills Smart Wallet zu leeren.

Beispiel

Ein Vertrag mit Schwachstellen besteht aus drei Funktionen:

checkSig(): ECDSA-Verifizierungsfunktion, die sicherstellt, dass das Verifizierungsergebnis der ursprünglich festgelegte Unterzeichner ist.
getMsgHash(): Funktion zur Generierung eines Hash, die to und amount zu einem Hash kombiniert.
transfer(): Überweisungsfunktion, die es Benutzern ermöglicht, Gelder aus dem Liquiditätspool abzuheben. Aufgrund fehlender Einschränkungen für die Signatur kann dieselbe Signatur wiederverwendet werden, was es Hackern ermöglicht, kontinuierlich Gelder zu stehlen.

Lösung

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

Nonce: Sie beschreibt die Variable der Anzahl der Transaktionen eines EOA im Blockchain-Netzwerk. Sie hat Reihenfolge und Einzigartigkeit. Mit jeder zusätzlichen Transaktion erhöht sich der Nonce-Wert um 1. Das Blockchain-Netzwerk überprüft, ob die Nonce der Transaktion mit der aktuellen Nonce des Kontos übereinstimmt. Daher würde ein Hacker scheitern, wenn er eine bereits verwendete Signatur benutzt, da der Nonce-Wert in der Signaturkombination kleiner ist als der aktuelle Nonce-Wert des EOA.

5. Denial-of-Service-Angriff (DoS)

Der Denial-of-Service-Angriff (DoS) ist in der traditionellen Web2-Welt nichts Neues. Er bezieht sich auf jede Störung eines Servers, wie das Senden einer großen Menge an Junk- oder störenden Informationen, die die Verfügbarkeit beeinträchtigen oder vollständig zerstören. Ähnlich sind Smart Contracts von solchen Angriffen betroffen, die im Wesentlichen darauf abzielen, die Funktionsweise des Smart Contracts zu stören.

Spezifische Logik

Betrachten wir ein Beispiel. Projekt A führt ein öffentliches Angebot für das Protokoll-Token durch, bei dem alle Benutzer Gelder in den Liquiditätspool (Smart Contract) einzahlen können, um Quoten nach dem Prinzip "Wer zuerst kommt, mahlt zuerst" zu erwerben, und überschüssige Gelder werden an die Teilnehmer zurückgegeben. Hacker Alice nutzt den Angriffsvertrag, um am öffentlichen Angebot teilzunehmen. Sobald der Liquiditätspool versucht, Gelder an Alices Angriffsvertrag zurückzugeben, wird ein DoS-Angriff ausgelöst, der verhindert, dass die Rückgabeaktion jemals realisiert wird. Infolgedessen wird eine große Menge an Geldern im Smart Contract gesperrt.

Beispiel für einen öffentlichen Angebotsvertrag

Beispiel

Der öffentliche Angebotsvertrag umfasst zwei Funktionen:

deposit(): Einzahlungsfunktion, die die Adresse des Einzahlers und den eingezahlten Betrag erfasst.
refund(): Rückerstattungsfunktion, mit der das Projektteam Gelder an die Investoren zurückgibt.

DoS-Angriffsvertrag

Der DoS-Angriffsvertrag enthält eine Funktion:

attack(): Obwohl es sich um eine Angriffsfunktion handelt, weist sie keine Probleme auf. Das Hauptproblem liegt in der receive() Zahlungs-Callback-Funktion, die in den Hacker-Vertrag eingebaut ist und eine Ausnahmebeurteilung enthält. Jeder externe Vertrag, der Gelder an den Hacker-Vertrag überweist, löst durch revert() eine Ausnahme aus und verhindert so den Abschluss des Vorgangs.

Lösungen

1. Vermeiden Sie, dass kritische Funktionalität beim Aufrufen externer Verträge blockiert wird

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

2. Entkopplung

In der oben genannten refund()-Funktion des PublicSale-Vertrags ermöglichen Sie den Benutzern, Rückerstattungen selbst anzufordern, anstatt die Rückerstattungen zu verteilen, wodurch unnötige Interaktionen mit externen Verträgen minimiert werden.

6. permit-Angriff

Bei einem Permit-Angriff stellt Konto A die Signatur für eine bestimmte Partei im Voraus zur Verfügung, und Konto B kann dann, sobald es die Signatur erhalten hat, autorisierte Token-Überweisungen durchführen, um eine bestimmte Menge an Token zu stehlen. Hier besprechen wir hauptsächlich zwei gängige Funktionen für die Token-Autorisierung in Smart Contracts: approve() und permit().

Im üblichen ERC20-Vertrag kann Konto A approve() aufrufen, um eine bestimmte Menge an Token für Konto B zu autorisieren, wodurch Letzteres diese Token vom Ersteren übertragen kann. Zusätzlich wurde permit() in EIP-2612 in ERC20-Verträge eingeführt, und Uniswap hat im November 2022 einen neuen Token-Autorisierungsstandard, Permit2, veröffentlicht.

Spezifische Logik

Hier ist ein Beispiel. Eines Tages surfte Bill auf einer Blockchain-Nachrichtenwebsite, als plötzlich ein Metamask-Signatur-Popup erschien. Da viele Blockchain-Websites oder -Anwendungen Signaturen zur Verifizierung von Benutzeranmeldungen verwenden, dachte Bill nicht weiter darüber nach und führte die Signatur direkt aus. Fünf Minuten später waren seine Metamask-Vermögenswerte verschwunden. Bill entdeckte dann im Blockchain-Explorer, dass eine unbekannte Adresse eine permit()-Transaktion initiiert hatte, gefolgt von einer transferFrom()-Transaktion, die sein Wallet leerte.

Beispiel

Die beiden Funktionen sind wie folgt:

approve(): Eine Standard-Autorisierungsfunktion, bei der Konto A einen bestimmten Betrag für Konto B autorisiert.
permit(): Eine Signatur-Autorisierungsfunktion, bei der Konto B die Signaturverifizierung einreicht und abschließt, um den autorisierten Betrag von Konto A zu erhalten. Die Parameter umfassen den Eigentümer, der die Autorisierung erteilt, den autorisierten Empfänger, den autorisierten Betrag, die Signatur-Deadline und die Signatur-Daten v, r und s des Eigentümers.

Lösungen

1. Achten Sie auf jede Signatur bei On-Chain-Interaktionen

Trotz der Maßnahmen, die einige Wallets ergreifen, um Informationen zur approve()-Autorisierungssignatur zu entschlüsseln und anzuzeigen, bieten sie fast keine Warnung vor permit()-Signatur-Phishing, was das Risiko von Angriffen erhöht. Daher wird dringend empfohlen, jede unbekannte Signatur gründlich zu überprüfen, um festzustellen, ob sie auf die permit()-Funktion abzielt.

2. Trennen Sie die Wallet für regelmäßige Interaktionen von der Wallet zur Aufbewahrung von Vermögenswerten

Dies ist äußerst wichtig für Krypto-Nutzer, insbesondere für Airdrop-Jäger, da sie täglich mit unzähligen dApps oder Websites interagieren und anfällig für Fallen sind. Wenn Sie nur einen kleinen Betrag in einer Wallet für regelmäßige Interaktionen aufbewahren, können Sie Verluste in einem überschaubaren Rahmen halten.

7. Honeypot-Angriff

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

Spezifische Logik

Hier ist ein Beispiel. In einer Ankündigung auf Telegram informiert Projekt A die Benutzer darüber, dass der Token im Mainnet bereitgestellt wurde und zum Handel verfügbar ist. Da der Token nur gekauft und nicht verkauft werden kann, stieg der Preis zunächst weiter an, und Benutzer, die Angst haben, etwas zu verpassen, kaufen weiterhin. Nach einiger Zeit, wenn die Benutzer feststellen, dass sie nicht verkaufen können, nutzt das Projektteam die Gelegenheit und verkauft die Token, was zu einem Preissturz führt.

Beispiel

Kernfunktion:

_beforeTokenTransfer(): Eine interne Funktion, die während Token-Transfers aufgerufen wird und nur erfolgreich sein kann, wenn sie vom Eigentümer aufgerufen wird; Aufrufe von anderen Konten schlagen fehl.

Lösung

Verwendung von Sicherheits-Scan-Tools

a. Token Sniffer für Ethereum-Token

b. Ave Check für Token auf anderen Blockchains

c. Marktwebseiten mit integrierten Erkennungstools wie Dextools

Vermeiden Sie den Handel mit Token, die niedrige Bewertungen aufweisen.

8. Front-Running-Angriff

Front-Running entstand ursprünglich in traditionellen Finanzmärkten, wo Informationsasymmetrie es Finanzintermediären ermöglichte, durch schnelles Handeln basierend auf spezifischen Brancheninformationen Gewinne zu erzielen. In der Blockchain-Branche resultiert Front-Running hauptsächlich aus On-Chain-Front-Running, bei dem Miner manipuliert werden, um die eigenen Transaktionen vorrangig in die Blockchain aufzunehmen und damit Gewinne zu erzielen.

Im Blockchain-Bereich können Miner Gewinne erzielen, indem sie die Transaktionen, die sie in Blöcke packen, manipulieren, z.B. durch Ausschluss bestimmter Transaktionen und Neuordnung von Transaktionen. Solche Gewinne können mit dem Miner Extractable Value (MEV) gemessen werden. Bevor die Transaktion eines Benutzers zum Ethereum-Mainnet hinzugefügt wird, werden die meisten Transaktionen im Mempool gesammelt. Miner suchen in diesem Mempool nach Transaktionen mit höheren Gaspreisen und priorisieren deren Aufnahme, um ihre Gewinne zu maximieren. Generell werden Transaktionen mit höheren Gaspreisen von Minern leichter aufgenommen. Gleichzeitig durchsuchen auch einige MEV-Bots den Mempool nach profitablen Transaktionen.

Spezifische Logik

Hier ein Beispiel: Bill entdeckt einen neuen, gefragten Token mit erheblichen Preisschwankungen. Um den Erfolg von Token-Transaktionen auf Uniswap sicherzustellen, setzt Bill einen außergewöhnlich weiten Slippage-Bereich. Unglücklicherweise erkennt Alices MEV-Bot diese Transaktion im Mempool und erhöht umgehend die Gasgebühr, initiiert eine Kauftransaktion vor Bills und fügt eine Verkaufstransaktion nach Bills innerhalb desselben Blocks ein. Nach der Blockbestätigung führt dies zu erheblichen Slippage-Verlusten für Bill, während Alice von einer Arbitrage-Operation des Niedrig-Kaufens und Hoch-Verkaufens profitiert.

Beispiel

Die Funktion ist wie folgt:

solve(): Eine Ratefunktion, bei der jeder eine Antwort einreichen kann, und wenn die eingereichte Antwort mit der Zielantwort übereinstimmt, kann der Einreicher 10 Ether erhalten.

Ablauf: Bill findet die richtige Antwort.
Alice überwacht den Mempool und wartet darauf, dass jemand die richtige Antwort einreicht.
Bill ruft solve() auf, um die Antwort einzureichen, und setzt den Gaspreis auf 100 Gwei.
Alice sieht die von Bill gesendete Transaktion und entdeckt die Antwort. Sie setzt einen höheren Gaspreis als Bill, nämlich 200 Gwei, und ruft solve() auf.
Alice's Transaktion wird vom Miner vor Bills Transaktion verpackt.
Alice gewinnt eine Belohnung von 10 Ether.

Lösung

Die drei Hauptfunktionen sind wie folgt:

commitSolution(): Eine Funktion zum Einreichen von Ergebnissen, die den vom Benutzer eingereichten Antwort-Hash solutionHash, die Einreichungszeit commitTime und den Status revealed in der Commit-Struktur platziert.
getMySolution(): Eine Funktion zum Abrufen von Ergebnissen, die es Benutzern ermöglicht, ihre eingereichten Antworten und zugehörige Informationen einzusehen, einschließlich des vom Benutzer eingereichten Antwort-Hashes solutionHash, der Einreichungszeit commitTime und des Status revealed.
revealSolution(): Eine Funktion zum Beanspruchen von Belohnungen für das Erraten des Rätsels, die es Benutzern ermöglicht, Belohnungen zu beanspruchen, nachdem sie die Antwort und das von ihnen festgelegte Passwort angegeben haben.

Prozess:

Bill findet die richtige Antwort.
Bill ruft commitSolution() auf, um die richtige Antwort einzureichen.
Im nächsten Block ruft Bill revealSolution() auf und gibt die Antwort und das von ihm festgelegte Passwort an, um die Belohnung zu beanspruchen.

In commitSolution() reicht Bill eine verschlüsselte Zeichenfolge ein und behält die unverschlüsselten Daten nur für sich. In diesem Schritt wird auch die Einreichungsblockzeit commitTime aufgezeichnet. Als Nächstes wird in revealSolution() die Blockzeit überprüft, um Front-Running innerhalb desselben Blocks zu verhindern. Da der Aufruf von revealSolution() die Einreichung der unverschlüsselten Antwort erfordert, zielt dieser Schritt darauf ab, andere daran zu hindern, commitSolution() zu umgehen und direkt revealSolution() aufzurufen. Nach erfolgreicher Überprüfung wird die Belohnung ausgezahlt, wenn die Antwort als korrekt bestätigt wird.

Fazit

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

Trotz so vieler Vorteile sind Smart Contracts auch dem Risiko von Angriffen ausgesetzt, die den Nutzern finanzielle Verluste zufügen können. Daher sind einige Gewohnheiten für On-Chain-Nutzer unerlässlich. Erstens sollten Nutzer immer sorgfältig die dApps auswählen, mit denen sie interagieren, und den Vertragscode sowie die damit verbundenen Regeln gründlich überprüfen. Darüber hinaus sollten sie regelmäßig sichere Wallets und Vertragsinteraktionstools aktualisieren und verwenden, um das Risiko von Hackerangriffen zu mindern. Außerdem ist es ratsam, ihre Gelder in mehreren Adressen zu speichern, um potenzielle Verluste durch Vertragsangriffe zu minimieren.

Für Branchenakteure ist die Gewährleistung der Sicherheit und Stabilität von Smart Contracts ebenso wichtig. Die oberste Priorität sollte die Stärkung der Prüfung von Smart Contracts sein, um potenzielle Schwachstellen und Sicherheitsrisiken zu identifizieren und zu beheben. Zweitens sollten Branchenakteure sich über die neuesten Blockchain-Entwicklungen im Zusammenhang mit Vertragsangriffen informieren und entsprechende Sicherheitsmaßnahmen ergreifen. Nicht zuletzt sollten sie auch die Aufklärung der Nutzer und das Sicherheitsbewusstsein hinsichtlich der korrekten Nutzung von Smart Contracts verbessern.

Zusammenfassend lässt sich sagen, dass durch die gemeinsamen Bemühungen von Nutzern und Branchenakteuren die Sicherheitsrisiken von Smart Contracts erheblich gemindert werden können. Nutzer sollten stets sorgfältig Verträge auswählen und persönliche Vermögenswerte schützen, während Branchenakteure die Vertragsprüfung intensivieren, mit technologischen Fortschritten Schritt halten und die Aufklärung der Nutzer sowie das Sicherheitsbewusstsein verbessern sollten. Gemeinsam werden wir die sichere und zuverlässige Entwicklung von Smart Contracts vorantreiben.

Referenzen:

Solidity by Example：https://solidity-by-example.org/

Blockchain Know-how von SlowMist：https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzU4ODQ3NTM2OA==&action=getalbum&album_id=1378673890158936067&scene=173&from_msgid=2247498135&from_itemidx=1&count=3&nolastread=1#wechat_redirect

Chainlink - Top 10 DeFi Security Best Practices：https://blog.chain.link/defi-security-best-practices/#post-title

WTF - Solidity 104 Vertragssicherheit：https://www.wtf.academy/solidity-104/

Schwachstellen in DeFi Smart Contracts in 4 Kategorien mit 38 Szenarien：https://www.weiyangx.com/381670.html

OpenZeppelin：https://github.com/OpenZeppelin/

Eine Einführung in häufige Schwachstellen und Angriffe bei Smart Contracts