#Sui创4060万TPS纪录 Als Erstes habe ich geprüft: „Was genau wird hier gezählt?“ In einer offiziellen Mitteilung vom 7. Oktober gab Sui 40,614,180 TPS an. Der Test fand beim Basecamp in Singapur statt. Dieser Durchsatz stammt jedoch aus Off-Chain-Aktivitäten in Sui Tunnels; die Ergebnisse werden auf dem Mainnet abgerechnet. Würde man ihn direkt als Anzahl der Transaktionen verstehen, die pro Sekunde auf der Konsensebene des Mainnets einzeln bestätigt werden, würde das die Einschätzung der Leser zur Leistung verändern.
Nach dem Stand vom 8. Oktober, 12:38 Uhr Pekinger Zeit, sieht die ursprüngliche, bislang verifizierbare Chronologie dieser Testrunde so aus: Am 4. Juli erreichte das Experiment 6,086,766 TPS; am 17. Juli wurde es vorgestellt; am 7. Oktober wurde dann das Ergebnis von 40,61 Millionen veröffentlicht. Da beide Messungen innerhalb von Tunneln stattfanden, lässt sich damit die Verbesserung innerhalb dieses Testsystems beschreiben. Sie eignen sich jedoch nicht dazu, die Zahl der Mainnet-Transaktionen direkt mit der einer anderen Blockchain zu vergleichen.
I. Interaktion, Ausführung und Abrechnung getrennt betrachten
Der offiziell beschriebene Ablauf ist folgender: Zunächst wird ein Kanal auf der Blockchain geöffnet. Innerhalb des Kanals finden mehrere Status- oder Zahlungsinteraktionen statt. Beim Schließen wird die Abrechnung eingereicht. Das Mainnet verankert den endgültigen Status und den Nachweis; nicht jede einzelne Aktion innerhalb des Kanals muss separat in den globalen Konsens geschrieben werden. Das ist ähnlich, als würde man das endgültige Kontobuch einer Reihe von Transaktionen an die Abrechnungsebene übergeben: Die Zahl der Vorgänge und die Zahl der endgültigen Einreichungen sind naturgemäß zwei unterschiedliche Kennzahlen.
Ein solches Design ist sinnvoll: Häufige Maschineninteraktionen müssen nicht für jeden einzelnen Schritt dieselben Kosten für On-Chain-Schreibvorgänge tragen. Doch sowohl „findet off-chain statt“ als auch „lässt sich letztlich on-chain verifizieren“ sollte klar gesagt werden; man darf nicht nur den Teil mit der größten Zahl herausgreifen. Ein Spitzenwert beantwortet außerdem nicht automatisch Fragen zur Dauer, zur Fehlerrate oder zu möglichen Engpässen beim Schließen eines Kanals.
II. Fortschritte bei der Verifizierung nicht mit dem endgültigen Ergebnis vermischen
In der Mitteilung vom 7. Oktober wurde CertiK als unabhängige Prüfstelle genannt. Zugleich hieß es, dass Nachweise, Ausführungsprotokolle und weitere Unterlagen geprüft und der Bericht in den kommenden Tagen veröffentlicht werden sollten. Bislang konnte ich keinen vollständigen, öffentlich zugänglichen Bericht zu diesem Test finden. Ich beziehe mich hier daher auf die vom Projekt veröffentlichten Ergebnisse. Die Beteiligung an einer Prüfung vor Ort stelle ich nicht so dar, als hätte ich die Berechnungen unabhängig nachvollzogen; ebenso wenig behandle ich die Ankündigung eines Berichts so, als wäre dieser bereits fertiggestellt.
Besonders wichtig werden die Angaben zum Messzeitraum und zur Zählweise sein, dazu, wie erfolgreiche und fehlgeschlagene Vorgänge behandelt werden, sowie zu den Abrechnungsnachweisen nach dem Schließen eines Kanals. Ändern sich diese Rahmenbedingungen, kann dieselbe TPS-Zahl eine ganz andere Bedeutung haben.
III. Wie wird aus Leistungspotenzial echte Nachfrage?
In einem Artikel von Sui zu Maschinenzahlungen vom 2. September wurden außerdem die atomare Abrechnung und begrenzte Berechtigungen hervorgehoben: Ein mehrstufiger Vorgang soll entweder vollständig abgeschlossen oder gar nicht erst eingereicht werden. Auch Betrag, Zeitraum und Empfänger einer Autorisierung müssen klar begrenzt sein. Das erklärt meiner Ansicht nach, warum reale Anwendungen nicht einfach nur möglichst viele Aktionen anstreben können. Wenn es bei einer großen Zahl automatisierter Interaktionen an kontrollierbaren Berechtigungen und überprüfbarer Abrechnung fehlt, ist mehr Geschwindigkeit nicht unbedingt nützlicher.
Bei einem SUI-Asset lässt sich der demonstrierte Durchsatz nicht proportional in Einnahmen, Token-Käufe oder Kursziele umrechnen. Als Nächstes werde ich beobachten, ob langfristige Nutzung, tatsächliche Zahlungen und Abrechnungsbedarf damit Schritt halten, und dann beurteilen, ob das technische Ergebnis auch einen wirtschaftlichen Mehrwert schafft. Mein heutiges Fazit: Der Messumfang wurde erläutert; die kommerzielle Umsetzung und der vollständige Testbericht müssen jedoch noch weiter überprüft werden.
Nach dem Stand vom 8. Oktober, 12:38 Uhr Pekinger Zeit, sieht die ursprüngliche, bislang verifizierbare Chronologie dieser Testrunde so aus: Am 4. Juli erreichte das Experiment 6,086,766 TPS; am 17. Juli wurde es vorgestellt; am 7. Oktober wurde dann das Ergebnis von 40,61 Millionen veröffentlicht. Da beide Messungen innerhalb von Tunneln stattfanden, lässt sich damit die Verbesserung innerhalb dieses Testsystems beschreiben. Sie eignen sich jedoch nicht dazu, die Zahl der Mainnet-Transaktionen direkt mit der einer anderen Blockchain zu vergleichen.
I. Interaktion, Ausführung und Abrechnung getrennt betrachten
Der offiziell beschriebene Ablauf ist folgender: Zunächst wird ein Kanal auf der Blockchain geöffnet. Innerhalb des Kanals finden mehrere Status- oder Zahlungsinteraktionen statt. Beim Schließen wird die Abrechnung eingereicht. Das Mainnet verankert den endgültigen Status und den Nachweis; nicht jede einzelne Aktion innerhalb des Kanals muss separat in den globalen Konsens geschrieben werden. Das ist ähnlich, als würde man das endgültige Kontobuch einer Reihe von Transaktionen an die Abrechnungsebene übergeben: Die Zahl der Vorgänge und die Zahl der endgültigen Einreichungen sind naturgemäß zwei unterschiedliche Kennzahlen.
Ein solches Design ist sinnvoll: Häufige Maschineninteraktionen müssen nicht für jeden einzelnen Schritt dieselben Kosten für On-Chain-Schreibvorgänge tragen. Doch sowohl „findet off-chain statt“ als auch „lässt sich letztlich on-chain verifizieren“ sollte klar gesagt werden; man darf nicht nur den Teil mit der größten Zahl herausgreifen. Ein Spitzenwert beantwortet außerdem nicht automatisch Fragen zur Dauer, zur Fehlerrate oder zu möglichen Engpässen beim Schließen eines Kanals.
II. Fortschritte bei der Verifizierung nicht mit dem endgültigen Ergebnis vermischen
In der Mitteilung vom 7. Oktober wurde CertiK als unabhängige Prüfstelle genannt. Zugleich hieß es, dass Nachweise, Ausführungsprotokolle und weitere Unterlagen geprüft und der Bericht in den kommenden Tagen veröffentlicht werden sollten. Bislang konnte ich keinen vollständigen, öffentlich zugänglichen Bericht zu diesem Test finden. Ich beziehe mich hier daher auf die vom Projekt veröffentlichten Ergebnisse. Die Beteiligung an einer Prüfung vor Ort stelle ich nicht so dar, als hätte ich die Berechnungen unabhängig nachvollzogen; ebenso wenig behandle ich die Ankündigung eines Berichts so, als wäre dieser bereits fertiggestellt.
Besonders wichtig werden die Angaben zum Messzeitraum und zur Zählweise sein, dazu, wie erfolgreiche und fehlgeschlagene Vorgänge behandelt werden, sowie zu den Abrechnungsnachweisen nach dem Schließen eines Kanals. Ändern sich diese Rahmenbedingungen, kann dieselbe TPS-Zahl eine ganz andere Bedeutung haben.
III. Wie wird aus Leistungspotenzial echte Nachfrage?
In einem Artikel von Sui zu Maschinenzahlungen vom 2. September wurden außerdem die atomare Abrechnung und begrenzte Berechtigungen hervorgehoben: Ein mehrstufiger Vorgang soll entweder vollständig abgeschlossen oder gar nicht erst eingereicht werden. Auch Betrag, Zeitraum und Empfänger einer Autorisierung müssen klar begrenzt sein. Das erklärt meiner Ansicht nach, warum reale Anwendungen nicht einfach nur möglichst viele Aktionen anstreben können. Wenn es bei einer großen Zahl automatisierter Interaktionen an kontrollierbaren Berechtigungen und überprüfbarer Abrechnung fehlt, ist mehr Geschwindigkeit nicht unbedingt nützlicher.
Bei einem SUI-Asset lässt sich der demonstrierte Durchsatz nicht proportional in Einnahmen, Token-Käufe oder Kursziele umrechnen. Als Nächstes werde ich beobachten, ob langfristige Nutzung, tatsächliche Zahlungen und Abrechnungsbedarf damit Schritt halten, und dann beurteilen, ob das technische Ergebnis auch einen wirtschaftlichen Mehrwert schafft. Mein heutiges Fazit: Der Messumfang wurde erläutert; die kommerzielle Umsetzung und der vollständige Testbericht müssen jedoch noch weiter überprüft werden.