Die Argumentation für einen Qubic Stablecoin - Teil 4: Schnell, Schneller, Qubic

Wir erklären den Unterschied zwischen Transfers und Transaktionen und führen die Leser durch verschiedene Transferszenarien, um Qubics beeindruckenden Durchsatz zu demonstrieren. Durch die Hervorhebung von Geschwindigkeitstests aus der Praxis zeigen wir, was Qubic von anderen Blockchains unterscheidet.

Qsilver, 22. Aug. 2024.

Rückblick

In den ersten drei Teilen dieser Serie haben wir die Grundlage für unsere Vision eines Qubic-basierten Stablecoins gelegt. Wir haben den aktuellen Mangel an einer überzeugenden Antwort auf die wesentliche Frage "Warum auf Qubic aufbauen?"hervorgehoben, wie SteCos aktuelle Marketingbemühungen falsch ausgerichtet sind, und eine strategische Verschiebung hin zur Positionierung von Qubic um "ultra-hohe Leistung"als Katalysator für Ökosystemwachstum und langfristigen Erfolg vorgeschlagen.

Einführung

Jetzt wenden wir uns einer entscheidenden technischen Frage zu: Wie schnell ist Qubic? Diese Frage ist nicht einfach zu beantworten. Um Qubics Leistung und deren Auswirkungen auf unsere Stablecoin-Vision vollständig zu verstehen, müssen wir zunächst einige Schlüsselkonzepte klären. Bleiben Sie bei uns, während wir die Unterschiede zwischen Transaktionen und Transfers, Transferszenarien und Transfergenerierungsmethoden erklären. Am Ende dieses Beitrags sollten Sie ein solides Verständnis davon haben, wie sich Qubics Geschwindigkeit im Vergleich zur Konkurrenz verhält und wie wir planen, Qubic zu nutzen, um den schnellsten Stablecoin zu bauen, den die Welt je gesehen hat.

Bevor wir beginnen

Schlüsselkonzepte

Die Protokollschicht bezieht sich auf die Kernschicht des Blockchain-Systems, die dessen Regeln und Mechanismen definiert. Hier:

• Eine Transaktion ist eine einzelne Operation, die eine Zustandsänderung im Ledger beinhaltet.
• Ein Transfer ist eine Unteroperation innerhalb einer Transaktion, die Vermögenswerte von einer Adresse zu einer anderen bewegt.

Die Anwendungsschicht bezieht sich auf die Schicht, in der Benutzer über Anwendungen (Benutzeroberflächen, dApps und Smart Contracts) mit der Blockchain interagieren. Hier:

• Ein Kryptowährungstransfer ist der häufigste Transaktionstyp, bei dem ein Benutzer einen Betrag einer Kryptowährung an einen anderen Benutzer überweist.
• Andere Transaktionstypen umfassen Smart-Contract-Ausführungen, Oracle-Datenanfragen, State-Channel-Abrechnungen, Token-Transfers, Token-Prägung/Verbrennung, Erstellung/Übertragung von Non-Fungible Tokens (NFT), Staking, Ausleihen/Verleihen, Börsenaufträge, Abstimmungs-/Governance-Aktionen, Kettengovernance-Updates, Belohnungs-/Dividendenausschüttungen, Identitätsüberprüfungen, Datenspeicherung/-modifikation, Chain-übergreifende Operationen... eine offene Liste, die nur durch die Vorstellungskraft der Entwickler begrenzt ist und daher je nach Blockchain variiert.

"Transfer" kann verwirrend sein, weil seine Bedeutung je nach Kontext variiert:

• Auf Protokollebene ist ein Transfer eine Unteroperation innerhalb einer Transaktion.
• Auf Anwendungsebene ist ein Transfer ein Transaktionstyp von vielen.

Um die Verwirrung zu verstärken, kann eine einzelne Transaktion, wie z.B. eine Smart-Contract-Ausführung, mehrere Transfers auslösen. Beispielsweise beinhaltet ein Gehaltsabrechnungs-Smart-Contract, der 1 QU an jeweils 100 Mitarbeiter verteilt, 100 Transfers, die alle durch eine einzige Transaktion initiiert werden.

Designunterschiede zwischen Blockchains tragen ebenfalls zu dieser Verwirrung bei. Zum Beispiel erfordert das Ausleihen auf Ethereum einen Smart Contract, aber auf Celo ist es ein nativer Transaktionstyp auf Protokollebene.

Diese Komplexität überfordert Endnutzer. Da Kryptowährungstransfers der häufigste Transaktionstyp sind, setzen sie am Ende beides gleich (wie in "eine Transaktion dient dazu, Krypto zu übertragen!"). Dabei spielt es keine Rolle, dass Transaktionen zu viel mehr in der Lage sind. Benutzer verwenden einen Begriff der Protokollebene, um einen Nutzen auf Anwendungsebene zu beschreiben.

Transferszenarien

Lassen Sie uns die folgenden Transferszenarien unterscheiden:

• Eins-zu-Eins (1-zu-1): Eine einzelne Transaktion sendet einen Vermögenswert von einer Adresse zu einer anderen Adresse. Z.B. eine Überweisung zwischen Konten, eine E-Commerce-Zahlung.
• Eins-zu-Viele (1-zu-Viele): Eine einzelne Transaktion sendet einen Vermögenswert von einer Adresse zu mehreren Adressen. Z.B. Leistungsauszahlung, Lohnabrechnung.
• Eins-zu-Alle (1-zu-Alle): Eine einzelne Transaktion sendet einen Vermögenswert von einer Adresse an alle Adressen in einer Kette. Z.B. Bedingungsloses Grundeinkommen (UBI), Airdrops.

Transfergenerierung

Angesichts ihrer Auswirkungen auf die Leistung unterscheiden wir, wie Transfers generiert werden:

• Transaktionsgeneriert: Ein Transfer, der aus einer Transaktion (Tx) generiert wird.
• Smart-Contract-generiert: Ein Transfer, der aus einem Smart Contract (SC) generiert wird. Die Anzahl der generierten Transfers hängt vom Typ des Smart Contracts ab.

Netzwerkparameter

Abschließend definieren wir wichtige Netzwerkparameter, die die Leistung beeinflussen:

• Tick-Dauer (tDur): Eine Zeiteinheit, während der ein Satz von Transaktionen verarbeitet und abgeschlossen wird. Die aktuelle Tick-Dauer beträgt etwa 2,5 Sekunden.
• Transaktionen pro Tick (TxPT): Die maximale Anzahl von Transaktionen, die während eines einzelnen Ticks verarbeitet werden können. Die aktuellen Transaktionen pro Tick betragen 1.024.

Entscheidung, was zu messen ist

In der Kryptowelt wird die Blockchain-Leistung typischerweise auf Protokollebene mit der Metrik Transaktionen pro Sekunde (TPS oder TxPS) gemessen. Dies misst die Anzahl der Transaktionen - eine Zustandsänderung im Hauptbuch -, die eine Blockchain in einer Sekunde verarbeiten kann. Zum Beispiel hat TON 104.715 TxPS durch den Einsatz von Sharding erreicht, während Ethereum anstrebt, 100.000 TxPS mit Rollups zu übertreffen.

Qubic glänzt nicht bei TxPS, aber das ist in Ordnung. Aus Marketingsicht ist TxPS eine nach innen gerichtete Metrik - relevanter für Krypto-Teams und Investoren, die gerne mit den Fähigkeiten ihrer Blockchain in Krypto-Fehden prahlen. Was für Endnutzer wirklich zählt, ist jedoch, ob sie eine Zahlung sofort abschließen können, selbst wenn Tausende andere zur gleichen Zeit dasselbe versuchen. Mit anderen Worten, sie interessieren sich nicht für Transaktionen pro Sekunde (TxPS), sondern für Transfers pro Sekunde (TfPS). Und hier, für nahtlose Zahlungserfahrungen - Krypto-Transfers auf Anwendungsebene -, wo es wirklich zählt, trägt Qubic die Krone. Oder etwa nicht?

Leistung heute

Mit einem Verständnis der Schlüsselkonzepte (Transaktionen vs. Transfers), Metriken (TxPS vs. TfPS), Transferszenarien (1-zu-1, 1-zu-Viele, 1-zu-Alle), Transfergenerierungsmethoden (Tx-generiert vs. SC-generiert) und Netzwerkparametern (Tick-Dauer und Transaktionen pro Tick) können wir nun untersuchen, wie schnell Qubic auf Anwendungsebene arbeitet. Während wir die verschiedenen Kombinationen untersuchen, ermutigen wir Sie, Qubic als Motor zu betrachten, der durch verschiedene Gänge schaltet.

Diese Tabelle fasst unsere Leistungstestergebnisse zusammen. Der Klarheit halber präsentieren wir die Tabelle mit konstanten Netzwerkparametern, obwohl in der Praxis tDur von Test zu Test variierte:

Erster Gang

Im ersten Gang, ohne Beteiligung von Smart Contracts, generiert jede Transaktion direkt einen Transfer. Um die Anzahl der Transfers zu maximieren, müssen wir die Anzahl der Transaktionen maximieren. Unter den aktuellen Netzwerkparametern kann Qubic 410 TxPS (1.024 TxPT / 2,5 tDur) verarbeiten. Diese Leistung ist deutlich höher als Bitcoin (3-7) und Ethereum (15-30), aber immer noch bescheiden im Vergleich zu Algorand (1.200), Avalanche (4.500) oder Solana (65.000).

Zweiter Gang

Im zweiten Gang verwenden wir den QUTIL SC (früher Sendmany SC), der es ermöglicht, 25 1-zu-Viele-Transfers innerhalb einer einzigen Transaktion zu bündeln. Dies erhöht die TfPS auf 10.250 (410 TfPS * 25) und bringt Qubic auf Augenhöhe mit den meisten anderen Chains, aber nur im 1-zu-Viele-Transferszenario.

Eine Variation des zweiten Gangs (siehe QUTIL-2 in der obigen Tabelle) beinhaltet die Verkettung von QUTIL SC-Ausführungen. Die erste Transaktion löst einen QUTIL SC-Aufruf für 25 Zahlungen aus, was 25 Transfers generiert. Jeder Transfer löst wiederum 25 weitere QUTIL-Ausführungen aus, was einen Kaskadeneffekt erzeugt. Nach drei Iterationen (25 x 25 x 25) führt dieser Prozess zu 15.625 Transfers. Da jedoch jeder Transfer innerhalb einer Transaktion verarbeitet werden muss, sind wir immer noch durch das Limit von 1024 TxPT eingeschränkt. Folglich dauert es 16 voll ausgelastete Ticks (15.625 Txs / 1.024 TxPS) oder 40 Sekunden (16 Ticks * 2,5 tDur), um den gesamten Prozess unter optimalen Bedingungen abzuschließen. Zusammengefasst erhöht dieser Ansatz nicht den Gesamtdurchsatz und bleibt nur für das 1-zu-Viele-Transferszenario anwendbar.

Dritter Gang

Im dritten Gang verwenden wir den AIRDROP SC, der es ermöglicht, den gleichen Betrag an jede Adresse im Spektrum zu senden - eine Liste aller Qubic-Adressen, die im RAM der Computor-Knoten gespeichert sind. Da nur sehr wenige Anwendungsfälle (wenn überhaupt) erfordern, den gleichen Betrag an alle Qubic-Adressen (~450k) zu senden, hat das 1-zu-Alle-Transferszenario eine begrenzte praktische Anwendbarkeit. Es ist jedoch immer noch nützlich, um die Qubic-Engine unter realen Bedingungen zu testen, da wir die Gesamtverarbeitungszeit messen (Tick-Verarbeitung + SC-Verarbeitung).

In unserem ersten Test im Testnetz (AIRDROP-1 in der obigen Tabelle) haben wir 1.024 Airdrops (an jeweils ~450k Adressen) pro Tick erstellt und damit die 1.024 erlaubten Tx pro Tick voll ausgenutzt. Das theoretische Ziel von 460,8M TfPS (1.024 TxPT * 450k Adressen) führte zu "nur" 150k TfPS. Während dieses Ergebnis enttäuschend erscheinen mag, zeigt es, dass wir entweder einen Fehler gefunden haben oder Qubic nicht für die gleichzeitige Verarbeitung zahlreicher Instanzen desselben Smart Contracts optimiert ist, insbesondere im Testnetz. Diese Ergebnisse sind jedoch wertvoll, da sie die Leistungsauswirkungen unter solchen Bedingungen aufzeigen.

Für einen richtigen Test des dritten Gangs (AIRDROP-2) haben wir den AIRDROP SC so geändert, dass er 1 QU anstelle eines Tokens überträgt. Dies führte zu "nur" 1M TfPS, wiederum aufgrund der Verwendung von Testnetz-Virtuellen-Maschinen (anstelle von Bare-Metal) und zu viel SC-Overhead.

Auf dieser Seite

• Die Argumentation für einen Qubic Stablecoin - Teil 4: Schnell, Schneller, Qubic
• Rückblick
• Einführung
• Bevor wir beginnen
• Schlüsselkonzepte
• Transferszenarien
• Transfergenerierung
• Netzwerkparameter
• Entscheidung, was zu messen ist
• Leistung heute
• Erster Gang
• Zweiter Gang
• Dritter Gang

Verwandte Beiträge