Glossar

Singleton-Architektur

Aktualisiert 12. Juni 2026

Singleton-Architektur ist ein Smart-Contract-Designmuster, bei dem die gesamte Logik einer dezentralen Anwendung – etwa alle Liquiditätspools eines Protokolls – in einem einzigen, zentralen Vertrag gebündelt ist, anstatt für jede Instanz einen separaten Contract zu erzeugen.

Herkunft aus der klassischen Softwareentwicklung

Das zugrundeliegende Singleton-Entwurfsmuster ist ein etabliertes Konzept aus der objektorientierten Programmierung. Es stellt sicher, dass von einer Klasse genau eine Instanz existiert, die global zugänglich ist – vergleichbar mit einem Datenbankverbindungs-Manager, den sich alle Anwendungsteile teilen, statt jeweils eine eigene Verbindung aufzubauen. In der Blockchain-Entwicklung überträgt sich dieses Prinzip auf Smart Contracts: Statt viele gleichartige Verträge zu deployen, übernimmt ein einzelner Contract alle Aufgaben zentral.

Umsetzung in Uniswap v4

Das bekannteste Praxisbeispiel ist Uniswap v4. Die Vorgängerversionen v2 und v3 nutzten ein Factory-Modell: Jeder neue Liquiditätspool erhielt beim Deployment einen eigenen Smart Contract. Das verursachte hohe Gaskosten, weil jede Pool-Erstellung eine vollständige Contract-Initialisierung auf der Blockchain bedeutete.

Uniswap v4 ersetzt dieses Modell durch einen zentralen Vertrag namens PoolManager. Er verwaltet sämtliche Pools intern als Einträge in einer gemeinsamen Datenstruktur. Die praktischen Konsequenzen sind erheblich:

Geringere Deployment-Kosten: Ein neuer Pool entsteht durch einen einfachen Speichereintrag im PoolManager, nicht durch das Erzeugen eines vollständigen Contracts.
Flash Accounting: Salden werden nicht nach jeder Einzeloperation abgeglichen, sondern erst am Ende einer Transaktion. Wer mehrere Pools innerhalb einer Transaktion durchläuft, spart die zwischenzeitlichen Token-Transfers auf der Chain – nur das Nettoresultat wird tatsächlich abgerechnet.
Internalisierte Token-Bewegungen: Da alle Pools unter einem Dach liegen, können Gelder zwischen Pools innerhalb derselben Transaktion ohne externe Transfers umgebucht werden, was Gas spart.

Abgrenzung und Risiken

Die Singleton-Architektur bündelt Effizienz, schafft aber auch Konzentrationsrisiken: Ein kritischer Bug im zentralen Contract betrifft alle darin verwalteten Pools gleichzeitig, während im Factory-Modell ein fehlerhafter Pool-Contract isoliert bliebe. Protokollentwickler müssen diesen Trade-off zwischen Gaseffizienz und Angriffsfläche bewusst abwägen. Formale Audits und Verifikation des Singleton-Contracts gewinnen damit überproportional an Bedeutung.