--- title: "Nicht initialisierter upgradebarer Proxy: Risiko der Initializer-Übernahme" description: "Upgradefähige Proxys initialisieren ihren eigenen Speicher über einen Initializer-Aufruf statt über den Konstruktor der Implementierung. Dieser Artikel erklärt Front-Running, Implementierungssperren und Bereitstellungsprüfungen." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Nicht initialisierter upgradebarer Proxy: Risiko der Initializer-Übernahme > Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen. ## Direkte Antwort Aktualisierbare Verträge verwenden keinen Konstruktor zum Festlegen des Agentenstatus, sondern verlassen sich auf den Initialisierer. In diesem Artikel werden nicht initialisierte Agents, Implementierungssperren und Bereitstellungsprüfungen erläutert. Wenn die neue Proxy-Adresse bereitgestellt wird, die Initialisierungstransaktion jedoch noch nicht bestätigt wurde, kann jeder versuchen, zuerst den öffentlichen Initialisierer aufzurufen und Eigentümer zu werden. Wenn der Agent bereitgestellt wird, führt der Konstruktor die Initialisierungslogik des Vertrags im Agentenspeicher nicht aus. Daher verwenden aktualisierbare Systeme häufig einen Initialisierer, der nur einmal aufgerufen werden kann, um den Eigentümer, Token-Parameter und Module festzulegen. Wenn die Funktion nicht ordnungsgemäß geschützt ist oder Bereitstellung und Initialisierung auf zwei Transaktionen aufgeteilt sind, kann ein Angreifer sie zuerst aufrufen. ## Wie es funktioniert Der Sicherheitsprozess platziert Bereitstellungs- und Initialisierungsaufrufdaten in derselben atomaren Transaktion und deaktiviert die Initialisierung bei der Implementierung der Vertragskonstruktion, um zu verhindern, dass die Implementierung selbst übernommen wird. Der Neuinitialisierer wird verwendet, um der neuen Version einen neuen Status hinzuzufügen, und muss außerdem die Version und die Aufrufberechtigungen einschränken. Nur die Überprüfung des Agenteneigentümers ohne Überprüfung des Implementierungsinitialisierungsstatus kann dennoch zu Risiken führen. Der On-Chain-Betrieb ist in vier Schichten unterteilt: Das Wallet ist für die Anzeige und Signatur verantwortlich, RPC ist für das Lesen und Senden verantwortlich, der Vertragscode bestimmt die Statusänderung und der Blockkonsens bestimmt, ob die Transaktion endgültig bestätigt wird. Die Anzeige von „Erfolg“ auf einer beliebigen Ebene kann die Überprüfung auf anderen Ebenen nicht ersetzen. ## Beispiel Das Projekt stellt zuerst den Agenten bereit und plant, als nächstes initialize(team) aufzurufen. Der Angreifer überwacht den Speicherpool und ruft zunächst initialize(Angreifer) mit einer höheren Gebühr auf, wird zum Administrator, führt dann ein Upgrade auf eine böswillige Implementierung durch und überweist Geld. Die eigene Initialisierungstransaktion des Teams wird zurückgesetzt, aber zu diesem Zeitpunkt geht die Kontrolle verloren. Gas, Schlupf und Blockzeit im Gehäuse werden zur Demonstration der Berechnungsmethode verwendet. Vor dem eigentlichen Betrieb sollten Preis, Liquidität, Berechtigungen und Vertragsstatus der aktuellen Kette und des aktuellen Blocks gelesen werden. Der Betrag erfasst gleichzeitig die Anzahl der Token, den Dollarwert und die rohe Ganzzahl in der Kette. ## Risiken Die Rendite muss auf Basis des tatsächlichen Exit-Werts berechnet werden: Nettoausstiegswert = Marktwert des Vermögenswerts – Preisschock – Protokollgebühr – Übertragungssteuer – Gas – Warterisikoabschlag Erstellen Sie drei Stressszenarien: Netzwerküberlastung, Oracle-Ausnahme und Administrator-Upgrade. Gehen Sie davon aus, dass sich Gas um das Fünffache ausdehnt, die Pooltiefe um 50 % sinkt, der Stablecoin um 5 % reduziert wird und Sie einen Tag lang nicht aussteigen können. Wenn ein Monatseinkommen die Druckreibung nicht decken kann, bietet ein hohes Einkommen keinen ausreichenden Ausgleich. Ein einzelnes Protokoll, eine einzelne Kette, eine einzelne Brücke und eine einzelne stabile Währung legen jeweils Obergrenzen fest. Alle Positionen, bei denen Administratoren, Oracles, Bridges, Frontends und ein einzelner RPC zum Beenden gleichzeitig normal sein müssen, sollten weiter eingegrenzt werden, und mehrere verwandte Abhängigkeiten dürfen nicht mit Streuung verwechselt werden. ## Häufige Irrtümer - Mythos 1: Die Front-End-Balance ist die Tatsache in der Kette. Das Front-End ist möglicherweise zwischengespeichert, spät indiziert oder mit dem falschen Netzwerk verbunden und muss mit Vertragslesevorgängen kreuzvalidiert werden. - Mythos 2: Zunehmendes Gas oder Schlupf kann jeden Fehler beheben. Gas wirkt sich nur auf die Sortierung aus, und Slippage senkt nur den Preis; Berechtigungs-, Nonce- und Vertragsbedingungsfehler werden nicht automatisch repariert. - Mythos 3: Erfolgreiche Tests in kleinen Mengen bedeuten dauerhafte Sicherheit. Administrator-Upgrades, dynamische Parameter und Liquiditätsänderungen verändern die Ergebnisse und sollten vor jeder Positionserweiterung überprüft werden. ## Verwandte Themen - [ERC-4626-Angriff auf die Inflation der ersten Einzahlung: Warum Vault-Aktien gerundet werden können](/de/crypto/erc4626-inflation-attack/) - [Agenturvertrag](/de/crypto/proxy-contract/) - [intelligenter Vertrag](/de/crypto/smart-contract/) - [Aktualisierbarer Vertrag](/de/crypto/upgradeable-contract/) - [Gültigkeitsnachweis](/de/crypto/validity-proof/) ## Quellen - [Proxy and Initializable API](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin (abgerufen: 2026-08-20) - [Writing Upgradeable Contracts](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin (abgerufen: 2026-08-20) - [Upgradebare Smart Contracts](https://ethereum.org/developers/docs/smart-contracts/upgrading/) - Ethereum.org (abgerufen: 2026-08-20) Source: https://wiki.fcontext.com/de/crypto/initializer-takeover/index.mdx