Kernpunkte
- Celo arbeitet als Layer 2 auf Ethereum; die historische Beschreibung als L1 definiert die aktuelle Architektur nicht mehr.
- OP Stack, EVM und EigenDA decken unterschiedliche Funktionen innerhalb des Systems ab.
- Gas mit einer anderen Währung zu bezahlen hängt von der Unterstützung durch das Protokoll und die verwendete Wallet ab.
Was ist Celo?
Celo richtet seine Infrastruktur auf Zahlungsanwendungen und mobil zugängliche Nutzungserlebnisse aus. Die aktuelle Architektur ist ein Layer 2 auf Ethereum auf Basis des OP Stack. Bei der Spezifikation einer Integration ist diese Architektur zugrunde zu legen; Annahmen aus der Layer-1-Phase dürfen nicht ungeprüft übernommen werden.
Der Wert für ein Produkt liegt darin, wie es EVM-Smart-Contracts, verfügbare Vermögenswerte und Nutzerabläufe kombiniert. Die Auswahl muss den Erwerb des Vermögenswerts für die Zahlung, die Gebührenkosten und den Übergang in das System einbeziehen, das der Empfänger benötigt.
So funktioniert es
Celo trennt EVM-kompatible Ausführung, Datenverfügbarkeit über EigenDA und Settlement auf Ethereum. Die Smart Contracts des Protokolls ergänzen spezifische Funktionen, darunter die Verwaltung der für Gebühren zugelassenen Währungen.
Eine Wallet und der Client der Anwendung müssen Transaktionen erstellen, die mit diesen Funktionen kompatibel sind. Ein angezeigtes Stablecoin-Guthaben reicht nicht aus, um anzunehmen, dass es als Gas genutzt werden kann. Die Tests prüfen die akzeptierte Währung, ihre Konfiguration und das Verhalten, wenn der Nutzer nicht über genügend Guthaben verfügt oder das Netzwerk wechselt.
Die Gebührenwährung wird als Teil der Transaktion konfiguriert; ihre Verfügbarkeit hängt von den im Netzwerk zugelassenen Optionen ab. Die Integration muss die Kosten in diesem Modus schätzen und die Unterstützung durch RPC-Anbieter und Wallet prüfen. Ein Gas-Sponsoring, sofern genutzt, bringt zudem ein eigenes Budget und eigene Autorisierungsregeln mit sich.
Was Celo bietet
Celo kann sich für Zahlungsanwendungen eignen, die das Nutzungserlebnis priorisieren und Smart Contracts in Solidity benötigen. Die Gebührenoptionen sind besonders dann zu bewerten, wenn der Nutzer mit einem Hauptvermögenswert arbeiten soll, ohne regelmäßig mehrere Guthaben zu verwalten.
Bei Metlabs prüfen wir den Ablauf von Zahlungseingang, Überweisung und Abstimmung mit der konkreten Wallet des Produkts. Ebenso prüfen wir die für die Zielgruppe verfügbaren Ein- und Auszahlungsdienste. Die Verbesserung des Nutzungserlebnisses wird an diesem Ablauf validiert und nicht allein aus der mobilen Ausrichtung des Netzwerks abgeleitet.
In einer Anwendung für Auslandsüberweisungen (Remittances) oder Zahlungseingänge wird getestet, was geschieht, wenn der Empfänger den Vermögenswert erhält, den nächsten Schritt des Ablaufs aber nicht abschließen kann. Außerdem werden Rückerstattungen und ausstehende Zahlungen abgestimmt, wobei das Ergebnis des Smart Contracts vom Ergebnis des Ein- oder Auszahlungsanbieters unterschieden wird. Das mobile Nutzungserlebnis wird bei zeitweise unterbrochener Verbindung und bei Sitzungswiederherstellung bewertet: Eine Überweisung, die verzögert angezeigt wird, darf nicht zu einem zweiten Vorgang verleiten.
Grenzen und Auswahlkriterien
Die Zahlung von Gebühren in verschiedenen Währungen schafft Kompatibilitätsanforderungen, die je Wallet und Tool geprüft werden müssen. Die L2-Architektur bringt zudem Abhängigkeiten von Sequencing, Datenverfügbarkeit und Bridges mit sich. Das sind andere Aspekte als die Sicherheit der Smart Contracts der Anwendung.
Stellar kann eine Alternative für Zahlungsflüsse auf Basis nativer Operationen sein; andere Layer-2-Netzwerke passen möglicherweise besser zu bestimmten EVM-Abhängigkeiten. Der Vergleich muss den Zugang zu Vermögenswerten und Diensten berücksichtigen, nicht nur die Gebühren. Die Wahl von Celo löst den Ein- und Auszahlungsweg über Banken nicht automatisch.
