Optimism

Optimism umfasst ein öffentliches Netzwerk, Entwicklungswerkzeuge und ein Modell zur Koordination zwischen Chains. Für das Deployment einer dApp ist das konkrete Ziel OP Mainnet. Für den Betrieb einer eigenen Chain ist OP Stack die relevante Komponente, mit einer deutlich größeren Infrastrukturverantwortung.

Diese Unterscheidung verhindert, dass eine Integration von Smart Contracts mit dem Start eines Netzwerks verwechselt wird. In einem Projekt legen wir zuerst fest, wo Nutzer und Vermögenswerte angesiedelt sind, welche Vorgänge sie ausführen müssen und wer die Komponenten betreibt, von denen die Anwendung abhängen wird.

OP Mainnet führt Transaktionen außerhalb der Basisschicht aus und veröffentlicht Informationen, mit denen sich sein Zustand von Ethereum aus rekonstruieren lässt. Das Optimistic-Modell enthält Mechanismen, um fehlerhafte Ergebnisse anzufechten. Seine Smart Contracts und Werkzeuge bieten die gewohnte EVM-Entwicklungserfahrung.

Das Frontend erhält Bestätigungen vom Layer 2, doch ein Vorgang zwischen Netzwerken durchläuft mehr Stufen. Deshalb sollten Einzahlungen, Nachrichten und Auszahlungen als Prozesse mit eigener Nachverfolgung abgebildet werden. Das Backend muss den in beiden Netzwerken beobachteten Zustand abgleichen, bevor es eine Bewegung als abgeschlossen behandelt.

Im Backend kann eine Bestätigung des Sequencers ausreichen, um die Oberfläche zu aktualisieren, während ein endgültiger Buchungsvorgang erfordern kann, abzuwarten, bis seine Daten und sein Zustand das auf Ethereum vorgesehene Sicherheitsniveau erreicht haben. Das Produkt muss diese Richtlinie je Aktion festlegen: Für das Anzeigen einer Bestellung, das Erbringen einer Leistung und die Freigabe einer Auszahlung gilt nicht zwangsläufig dieselbe Schwelle.

OP Mainnet kann passen, wenn ein Produkt Smart Contracts in Solidity und häufige Operationen benötigt, ohne jede Interaktion direkt auf Ethereum auszuführen. Es erlaubt, Tokenisierung, Zahlungen und Anwendungen zu bewerten, die Vermögenswerte und programmierbare Logik innerhalb seines Ökosystems kombinieren.

Unser Kriterium ist, die tatsächlichen Abhängigkeiten des Produkts zu prüfen: die Smart Contracts der Vermögenswerte, die Verfügbarkeit von Oracles, den RPC-Zugang sowie die Ein- und Ausstiegspfade. Außerdem werden die Gesamtkosten einer Transaktion gemessen, die Komponenten für die Datenveröffentlichung enthalten, statt nur das Ausführungs-Gas zu vergleichen.

Ein Integrationsbeispiel ist ein Programm für wiederkehrende Zahlungen: Der Smart Contract legt Empfänger und Berechtigungen fest, ein Dienst bereitet die Operationen vor, und das Team überwacht Gas-Guthaben, ausstehende Transaktionen und mögliche Unterbrechungen. Die Tests müssen unzureichendes Guthaben und den Ersatz einer Transaktion abdecken, zusätzlich zum Ein- und Ausstiegspfad der Vermögenswerte. Die Verbindung zu anderen OP-Stack-Chains macht aus diesen Bewegungen keine sofortige interne Übertragung.

Ein Layer 2 bringt zusätzliche Komponenten mit sich: Sequenzierung, Bridge-Contracts, Proofs und Upgrade-Berechtigungen. Sicherheit und Verfügbarkeit des Produkts hängen davon ab, wie sich jede davon verhält. Das Team muss das Wiederherstellungsverfahren kennen, wenn eine Abhängigkeit ausfällt.

Mit Arbitrum, Base und anderen Netzwerken lassen sich ähnliche Anforderungen umsetzen, allerdings mit operativen Unterschieden. Gemeinsame Entwicklungswerkzeuge oder eine gemeinsame Softwarebasis machen ihre Vermögenswerte nicht automatisch austauschbar. Die Wahl zwischen ihnen erfordert eine Prüfung des Ökosystems und des konkreten Ablaufs, der in Produktion gehen soll.