Versteckte Eigentümerprivilegien: Gefährliche Admin-Funktionen in 'verifizierten' Verträgen

Versteckte Eigentümerprivilegien in einem Smart Contract sind nur für Administratoren zugängliche Funktionen, die es einem Token-Deployer ermöglichen, die Regeln zu ändern, nachdem Sie bereits gekauft haben, und sie überleben routinemäßig in Verträgen, die auf einem Block-Explorer perfekt sauber aussehen. Der gefährliche Teil ist, dass die Quellcode-Verifizierung nur beweist, dass der veröffentlichte Code mit dem On-Chain-Bytecode übereinstimmt. Sie sagt nichts darüber aus, was dieser Code tun darf. Ein Vertrag kann verifiziert, geprüft und sogar teilweise aufgegeben werden, während er immer noch eine Funktion enthält, die es dem Eigentümer ermöglicht, Ihre Wallet einzufrieren, Ihre Verkäufe zu drosseln oder neues Angebot aus dem Nichts zu prägen. Dieser Leitfaden ist eine praktische Prüfung, kein Glossar. Sie erfahren genau, welche Funktionen Sie suchen müssen, wie Sie sie auf dem Explorer lesen und wie Sie routinemäßige Admin-Tools von einer Falle trennen können.

Warum ein verifizierter oder teilweise aufgegebener Vertrag immer noch gefährlich sein kann

Die Verifizierung ist ein Transparenzmerkmal, kein Sicherheitssiegel. Wenn ein Projekt seinen Vertrag verifiziert, kompiliert der Explorer den eingereichten Quellcode und bestätigt, dass er genau den bereits bereitgestellten Bytecode erzeugt. Das ist wirklich nützlich, weil es Ihnen ermöglicht, zu lesen, was der Vertrag tut, anstatt auf Hexadezimalzahlen zu starren. Aber ein bösartiger Entwickler möchte auch eine Verifizierung, denn ein sauberer, lesbarer Vertrag schafft schneller Vertrauen als ein unverifizierter. Viele Betrügereien liefern absichtlich verifizierten Code. Wenn Sie den Unterschied nicht klar erkennen, erklärt unser Leitfaden zu was ein verifizierter Vertrag tatsächlich bedeutet die Grenzen im Detail.

Das Aufgeben des Eigentums hat eine ähnliche Lücke. Ein Entwickler kann die Standard-Eigentümerrolle aufgeben und trotzdem eine zweite privilegierte Adresse fest in der Logik verankert halten oder erst aufgeben, nachdem die gefährlichen Setter ihren Schaden bereits angerichtet haben. Das Aufgeben nützt auch nichts, wenn die riskante Funktion so geschrieben wurde, dass sie von jedem aufgerufen werden kann, oder wenn sie überhaupt nie hinter dem Eigentum verborgen war. Lesen Sie unsere Analyse von was ein aufgegebener Vertrag wirklich beweist, bevor Sie das Aufgeben als grünes Licht betrachten. Die ehrliche Zusammenfassung: verifiziert plus aufgegeben ist ein Ausgangspunkt, kein Urteil.

Versteckte Eigentümerprivilegien, auf die Sie in einem Smart Contract achten sollten

Die meiste Macht, die Inhaber in die Falle lockt, liegt in einer Handvoll Funktionen, die nur dem Eigentümer vorbehalten sind. Lernen Sie diese Namen, und Sie können einen Vertrag in ein oder zwei Minuten scannen. Beachten Sie, dass Entwickler sie oft umbenennen, also beurteilen Sie nach dem Verhalten, nicht nur nach der Bezeichnung.

• blacklist() / setBlacklist() / addBot() markiert bestimmte Wallets, sodass sie weder übertragen noch verkaufen können. Ein Entwickler kann Käufer direkt nach dem Kauf auf die Blacklist setzen, sodass sie Token halten, die sie niemals abstoßen können.
• setMaxTx() / setMaxWallet() begrenzt, wie viel Sie in einer Transaktion bewegen können. Auf einen winzigen Wert eingestellt, macht es sinnvolle Verkäufe unmöglich, während Käufe weiterhin fließen.
• enableTrading() / setTradingEnabled() schaltet um, ob Übertragungen überhaupt funktionieren. Wenn der Handel nach dem Start ausgeschaltet werden kann, kann Ihr Ausstieg nach Belieben geschlossen werden.
• mint() oder jede Funktion, die das Angebot erhöht, ist eine Backdoor, um jeden Inhaber zu verwässern. So kann ein Entwickler Wert abziehen, ohne jemals die Liquiditätspool zu berühren.
• pause() / unpause() stoppt alle Token-Aktivitäten. Eine echte Sicherheitspause ist theoretisch in Ordnung, aber in den falschen Händen ist sie ein Einfrier-Button für den gesamten Markt.
• setFee() / setTaxes() ändert die Kauf- oder Verkaufssteuer. Suchen Sie im Code nach einer harten Obergrenze. Wenn der Eigentümer eine Verkaufssteuer von 99 Prozent festlegen kann, wird jeder Verkauf effektiv konfisziert.

Wie man die Write-Funktionsliste auf einem Block-Explorer liest

Öffnen Sie den Token auf einem Block-Explorer, gehen Sie zum Tab "Contract" und wählen Sie "Write Contract" (oder "Write as Proxy", wenn der Token ein Proxy-Muster verwendet). Diese Liste ist das vollständige Menü der zustandsändernden Aktionen, die der Vertrag offenlegt. Lesen Sie jeden Eintrag nach Namen und stellen Sie drei Fragen: Was ändert er, wer darf ihn aufrufen und gibt es eine Grenze für den Wert, auf den er gesetzt werden kann.

Um zu überprüfen, wer eine Funktion aufrufen kann, wechseln Sie zum Tab "Read Contract" und suchen Sie owner(), um die aktuelle Eigentümeradresse zu sehen. Wenn sie die Nulladresse (0x000...000) zurückgibt, ist das Eigentum aufgegeben. Suchen Sie dann in den Funktionsdefinitionen auf dem Tab "Code" nach einem onlyOwner-Modifikator oder einer require-Anweisung, die den Aufrufer einschränkt. Eine Funktion ohne Zugriffskontrolle, die Salden oder Gebühren ändert, ist ein ernstes Warnsignal. Wenn das Lesen von Solidity nicht Ihre Stärke ist, übernehmen automatisierte Scanner diese Triage für Sie, und unsere Zusammenstellung der besten kostenlosen Tools zur Analyse von Smart Contracts deckt diejenigen ab, die privilegierte Funktionen automatisch kennzeichnen.

Was jedes Privileg einem Entwickler ermöglicht, einschließlich Rugging ohne Liquiditätsberührung

Der klassische Rug Pull entleert den Liquiditätspool, und Sie können ihn oft kommen sehen, wenn der LP entsperrt ist. Versteckte Eigentümerprivilegien ermöglichen eine leisere Version, die die Liquidität überhaupt nicht berührt. Mit einer funktionierenden blacklist() lässt ein Entwickler jeden kaufen, beobachtet den Preisanstieg und setzt dann die Inhaber auf die Blacklist, sodass nur das Team in die Nachfrage auf der Kaufseite verkaufen kann. Der Pool bleibt voll und das Diagramm sieht gesund aus, bis zu dem Moment, in dem Ihr Verkauf rückgängig gemacht wird. Ein setFee() ohne Obergrenze erzielt das gleiche Ergebnis, indem fast der gesamte Erlös eines Verkaufs an die Team-Wallet geleitet wird. Eine mint()-Backdoor ist die langsamste und am leichtesten zu leugnende: Der Eigentümer prägt stillschweigend eine riesige neue Zuteilung und verkauft sie schrittweise, wodurch die Inhaber verwässert werden, während der Vertrag immer noch eine beiläufige Liquiditätsprüfung besteht. Da keines dieser Szenarien das Abziehen des LP erfordert, übersehen sie oft Tools, die nur die Entfernung von Liquidität überwachen, weshalb eine Überprüfung auf Funktionsebene neben unserer umfassenderen Rug-Pull-Checkliste wichtig ist.

Harmlose Admin-Funktionen von Inhaber-Fallen unterscheiden

Nicht jede Eigentümer-exklusive Funktion ist eine Bedrohung. Viele legitime Token behalten Admin-Tools aus guten Gründen bei, und das Ziel ist Kalibrierung, nicht Paranoia. Drei Tests trennen routinemäßige Funktionen von Fallen. Erstens, ist der gefährliche Zustand bereits in die sichere Richtung gesperrt? Ein Handels-Toggle ist in Ordnung, sobald der Handel dauerhaft aktiviert ist und die Funktion ihn nicht mehr deaktivieren kann. Zweitens, gibt es eine fest codierte Obergrenze? Ein setFee(), das niemals beispielsweise 10 Prozent überschreiten kann, ist vertretbar, während eines ohne Obergrenze es nicht ist. Drittens, wurde das Eigentum aufgegeben oder an eine Timelock oder Multisig übertragen? Ein Privileg, das keine einzelne Person sofort auslösen kann, ist weitaus weniger gefährlich als eines, das von einer anonymen EOA kontrolliert wird. Wirklich gutartige Beispiele sind ein einmaliges enableTrading(), das beim Start aktiviert wird und nicht wieder ausgeschaltet werden kann, ein excludeFromFee() für Router und den Vertrag selbst, und eine Abhebungsfunktion, die auf die Gebühren-Wallet und nicht auf den Liquiditätspool beschränkt ist. Kombinieren Sie dieses Urteil mit unserem umfassenderen Leitfaden zu wie man überprüft, ob ein Token vor dem Kauf sicher ist, sodass die Vertragslesung eine von mehreren Eingaben ist.

Eine schnelle Checkliste zur Prüfung von Eigentümerprivilegien

Führen Sie diese Abfolge aus, bevor Sie einen Token kaufen. Es dauert nur wenige Minuten und fängt die häufigsten Fallen ab:

• Bestätigen Sie, dass der Vertrag verifiziert ist, damit Sie den Quellcode tatsächlich lesen können.
• Öffnen Sie den Tab "Write Contract" und listen Sie jede zustandsändernde Funktion auf.
• Kennzeichnen Sie blacklist, pause, mint, trading toggle, max-tx und fee setters.
• Überprüfen Sie für jede Kennzeichnung die Zugriffskontrolle: Wer kann sie aufrufen und ist das Eigentum aufgegeben, zeitgesperrt oder multisig.
• Überprüfen Sie, ob Steuer-Setter eine fest codierte Obergrenze haben und wie hoch diese ist.
• Bestätigen Sie, dass ein Handels-Toggle nach dem Start nicht wieder ausgeschaltet werden kann.
• Führen Sie einen Quervergleich mit einem automatisierten Scanner durch, um alles zu finden, was Sie übersehen haben.
• Wenn eine einzelne anonyme Wallet Verkäufe einfrieren, Steuern unbegrenzt erhöhen oder das Angebot prägen kann, behandeln Sie den Token als hohes Risiko, unabhängig davon, wie sauber er aussieht.

Die Disziplin, die Sie schützt, ist einfach: Beurteilen Sie einen Vertrag danach, was seinem Eigentümer erlaubt ist, nicht nach den Abzeichen, die er trägt. Verifiziert und aufgegeben sind Eingaben, niemals Schlussfolgerungen. Sobald das Lesen des Write-Tabs zur Gewohnheit wird, sind die versteckten Hebel nicht mehr versteckt.

Dieser Artikel dient nur zu Bildungszwecken und stellt keine Finanzberatung dar.