P-Token: Solanas nächster großer Effizienzsprung

Einführung

Einer der weniger beachteten Gründe für die schnelle Verbreitung von Solana ist der sichere, einfache und standardisierte Umgang mit Token. Anders als bei vielen anderen Blockchains musst du zum Erstellen eines Tokens auf Solana keinen eigenen Contract bereitstellen. Stattdessen läuft alles über das umfassend auditierte und praxiserprobte SPL-Token-Programm (auch Tokenkeg genannt), das ursprünglich von Solana Labs bereitgestellt wurde. Dadurch werden gängige Aktionen wie das Prägen, Verbrennen und Übertragen von Token trivial. Einen Solana-Token kannst du beispielsweise mit einem einzigen CLI-Befehl bereitstellen.

Das SPL-Token-Programm ist das meistgenutzte Programm auf Solana – abgesehen vom System-Programm. In den vergangenen sechs Monaten wurden über das SPL-Token-Programm wöchentlich durchschnittlich zwischen 200.000 und 300.000 neue fungible Token erstellt. Das entspricht einer Steigerung um das 20-Fache gegenüber September 2023, als regelmäßig weniger als 10.000 neue SPL-Token pro Woche erstellt wurden. Mit Ausnahme von 2023 stieg die Zahl der neu ausgegebenen Token seit dem Start von Solana jedes Jahr deutlich, wie das folgende Diagramm zeigt.

Noch deutlicher ist die Zahl der SPL-Token-Übertragungen gestiegen. In den vergangenen drei Monaten lag sie durchgehend über 650 Millionen pro Woche und erreichte Ende Juli mit 867,8 Millionen ihren Höchststand. Das entspricht einer Steigerung um das 17,5-Fache gegenüber dem Tiefstand von 49,4 Millionen wöchentlichen Übertragungen Anfang August 2023.

P-Token kommt ins Spiel

P-token ist ein für Compute optimierter, direkt einsetzbarer Ersatz für das aktuelle SPL-Token-Programm. Das Anza-Team schlug ihn erstmals im März mit SIMD-0266: Effizientes Token-Programm vor. Er reduziert die Nutzung von Compute Units (CUs) erheblich und bleibt zugleich vollständig abwärtskompatibel mit bestehenden SPL-Token. 

Da p-token exakt denselben Befehlssatz und dieselben Account-Layouts wie das SPL-Token-Programm verwendet, lässt es sich direkt austauschen. Das bedeutet: p-token ist kein neuer Token-Standard. Der Client-Code funktioniert unverändert weiter. So bringt der Wechsel deutliche Effizienzgewinne, ohne dass Anwendungen oder Nutzer Anpassungen vornehmen müssen.

Die geplante Einführung von p-token passt zu Solanas umfassenderem Vorstoß für effizientere Programme und Frameworks. Dieser ergänzt die Arbeiten zur Erhöhung der Netzwerkkapazität, insbesondere das Ziel für 2025, den verfügbaren Blockspace zu verdoppeln.

Der jüngste Erfolg proprietärer AMMs auf Solana zeigt, welche Wirkung niedrigere Compute-Kosten und hocheffiziente Programme haben. Oracle-Updates auf Plattformen wie HumidiFi wurden beispielsweise auf nur 143 CUs hyperoptimiert. Doppler, ein neues Open-Source-Oracle-Programm von BlueShift, senkt die Kosten sogar noch weiter auf nur 21 CUs.

Pinocchio

Das „p“ in p-token steht für Pinocchio, eine von Anza entwickelte, optimierte, leistungsfähige Bibliothek ohne Abhängigkeiten zum Schreiben von Solana-Programmen. Pinocchio ersetzt die standardmäßige solana-program-Crate, die für die Verarbeitung von Befehls- und Account-Daten intensiv Zero-Copy-Typen nutzt. Bei Zero-Copy werden Daten beim Lesen oder Schreiben nicht an neue Speicherorte kopiert. Stattdessen greift das Programm über Zeiger direkt auf den Zustand zu. Dieses Design spart erheblich Compute, weil es unnötige Speicheroperationen vermeidet. Zugleich reduziert es den Laufzeit-Overhead.

Pinocchio ist außerdem no_std. Es benötigt also weder Rusts Standardbibliothek noch Heap-Allokationen, da die Solana Virtual Machine (SVM) bereits die Laufzeitumgebung bereitstellt. Das verschlankt die Ausführung weiter, reduziert Abhängigkeiten und ermöglicht schlankere, schnellere Programme.

Effizienzgewinne

CUs messen die Ausführungskosten in Solanas Laufzeitumgebung. Die kleinste Operation, etwa das Addieren zweier Ganzzahlen oder eine bitweise Operation, verbraucht 1 CU. Programme sind auf 200.000 CUs pro Befehl und 1,4 Millionen CUs pro Transaktion begrenzt.

P-Token steigert die Effizienz drastisch und reduziert den CU-Verbrauch standardmäßiger SPL-Token-Transaktionen um rund 95 % – eine 19-fache Effizienzsteigerung. Die schnellere Ausführung sorgt für eine reibungslosere Nutzererfahrung. Gleichzeitig schafft der frei werdende Compute-Spielraum Platz für mehr Transaktionen pro Block und erhöht direkt den Netzwerkdurchsatz.

Heute entfallen auf Befehle des Token-Programms rund 10 % der CU-Nutzung eines gesamten Blocks. Senkt p-token ihre Kosten auf nur 5 % des aktuellen Niveaus, fällt dieser Anteil von 10 % auf 0,5 %. Dadurch werden zusätzliche 9,5 % der Blockkapazität für andere Transaktionen frei. P-token kommt auch nachgelagerten Programmen zugute: Es verbessert die Komponierbarkeit, indem es die gesamte CU-Nutzung und die Kosten programmübergreifender Aufrufe (CPI) reduziert.

Die folgenden Daten zeigen in einem Diagramm und einer Tabelle, welche CU-Effizienzgewinne die Befehle von p-token gegenüber dem aktuellen SPL-Token-Programm erzielen.

Eine weitere wichtige Optimierung, die größtenteils durch `no_std` ermöglicht wird, reduziert die Größe des Programm-Binarys von 131 KB auf 95 KB.

Zusätzliche Befehle

P-token soll dem Token-Programm drei neue Befehle hinzufügen (`withdraw_excess_lamports`, `batch` und `unwrap_lamports`), die im ursprünglichen SPL-Token-Programm nicht vorhanden sind.

Überschüssige Lamports abheben

Ähnlich wie bei der aktuellen Implementierung von SPL Token-2022 ermöglicht `withdraw_excess_lamports` die Wiederherstellung überschüssiger SOL, die im Mint-Account „feststecken“. Das passiert meist, wenn ein Nutzer versehentlich Lamports an den Token-Mint-Account sendet.

Für die Abhebung ist eine Autorisierung durch die Mint Authority erforderlich: entweder durch den vorgesehenen Signer bei Standard-Mint-Accounts oder durch den Multisig bei Multisig-Accounts. Da bei den meisten SPL-Token die Mint Authority widerrufen wurde, kann stattdessen der Mint-Account selbst als Signatur-Autorität dienen. Dafür muss der Befehl mit dem privaten Schlüssel des Mints signiert werden.

Von allen SPL-Token-Mint-Accounts halten etwa 869.000 mehr SOL als den Mindestbetrag für die Mietbefreiung von 0,0014616 SOL. Insgesamt sind damit 176.961,5 SOL in Token-Mint-Accounts gebunden, die beim heutigen Kurs 36 Millionen USD wert sind. Die größten in Token-Mint-Accounts gebundenen SOL-Beträge gehören meist zu Memecoins, älteren Token und bedeutenden Blue-Chip-Assets. Der größte einzelne SOL-Betrag in einem Token-Mint-Account entfällt auf BOOK OF MEME ($BOME), einen Memecoin, mit 6.328 SOL. Die Einführung von p-token könnte diese Guthaben freigeben und den Teams hinter den Token unerwartete Einnahmen bescheren.

Batch

Der zweite neue Befehl ist `batch`. Er vereinfacht CPI-Interaktionen mit dem p-token-Programm. Statt das Token-Programm mehrmals aufzurufen, ermöglicht `batch` die Ausführung einer variablen Anzahl von Token-Befehlen in einem einzigen Aufruf. Dadurch fallen die grundlegenden CPI-Kosten von 1.000 Einheiten nur einmal an und nicht für jeden einzelnen Befehl.

Dadurch sinkt der Compute-Verbrauch von Protokollen erheblich, die innerhalb eines einzelnen Befehls mehrere Token-CPIs verwenden – ein verbreitetes Muster in Solana DeFi. Ein AMM könnte beispielsweise bei einem Swap zwei Übertragungen ausführen. Eine Einzahlung in einen Liquiditätspool könnte sowohl Übertragungen als auch Mints umfassen. Mit `batch` können Programme in diesen Szenarien deutlich CUs sparen.

Lamports entpacken

Der Befehl `unwrap_lamports` (kürzlich in einem separaten PR hinzugefügt) ermöglicht direkte Übertragungen von Lamports an einen Ziel-Account. Temporäre native Token-Accounts sind dadurch nicht mehr erforderlich.

Zuvor musste zum Entpacken von Lamports aus einem Wrapped-SOL-Account ein Associated Token Account (ATA) für den Empfänger erstellt und anschließend wieder geschlossen werden. Mit diesem Update lassen sich Lamports direkt aus nativen SOL-Accounts übertragen, was den Prozess vereinfacht.

Fast Path für Übertragungsbefehle

Eine Analyse der Nutzung des Token-Programms im Mainnet zeigt eine starke Konzentration auf Übertragungsbefehle. Zusammen machen sie fast die Hälfte der gesamten Aktivität aus. Die fünf am häufigsten verwendeten Befehle sind:

• transfer_checked (36.33%)
• transfer (13.22%)
• close_account (12.23%)
• initialize_account3 (9.98%)
• initialize_immutable_owner (9.78%)

Dieses Nutzungsmuster bietet die Chance, p-token für Übertragungen weiter zu optimieren und den CU-Verbrauch zu senken. Ein großer Teil dieser Optimierungsarbeit stammt von Cavey von Temporal. Weitere Einzelheiten zum Ansatz findest du in seinem X-Livestream.

Um diese Verbesserungen zu erreichen, führt p-token einen benutzerdefinierten Einstiegspunkt mit Fast Path für Übertragungsbefehle ein. Außerdem priorisiert der aktualisierte Prozessor `sync_native` und `initialize_immutable_owner`. Zusammen steigern diese Änderungen die CU-Effizienz deutlich und entsprechen den beobachteten Nutzungsmustern.

Logging

Mit der Einführung von p-token stellt sich die offene Frage, ob das aktuelle Logging-Verhalten beibehalten werden soll. Die neueste Version des Vorschlags empfiehlt, Logs zu entfernen. Auf Solana sind Logs der wichtigste Mechanismus, um Debugging-, Monitoring- und Ereignisdaten aus Programmen zu extrahieren. Im bestehenden Token-Programm sind die Logs minimal und geben nur den Namen des ausgeführten Befehls aus. Zum Beispiel:

Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA invoke [1],
Program log: Instruction: TransferChecked,
Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA consumed 6281 of 7738 compute units,
Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA success

Diese scheinbar kleine Log-Zeile `Instruction: <name>` kostet jedoch etwa 103 Compute Units. In der Praxis kann dieser Overhead fast so viel Compute verbrauchen wie der Befehl selbst. Bei einer einfachen Übertragung entfallen beispielsweise rund 40 % des gesamten Compute-Bedarfs auf das Logging.

Abgesehen von ihren Kosten sind diese Logs nicht immer zuverlässig. Sie können durch Log-Injection abgeschnitten oder manipuliert werden, wodurch nachgelagerte Parser irreführende Daten erhalten können. Wenn sie vollständig entfernt werden, könnten jedoch Workflows von Entwicklern und Anwendungen nicht mehr funktionieren, die derzeit auf diese Logs angewiesen sind.

Ohne Logs wäre es noch wichtiger, dass Teams IDLs veröffentlichen, um Einblick in das Programmverhalten zu geben. Anchor erzwingt dies beispielsweise inzwischen, indem es standardmäßig IDLs für alle neuen Programme veröffentlicht, sofern diese Funktion nicht ausdrücklich deaktiviert wird.

Auditierung

Die Auditierung des p-token-Programms läuft bereits, um vollständige Abwärtskompatibilität und Sicherheit zu gewährleisten. Damit p-token eingeführt werden kann, muss es exakt dieselben Befehle und Account-Layouts wie das aktuelle Token-Programm verwenden und dessen Verhalten präzise nachbilden. Jede Abweichung wäre ein Risiko. Um dieses Risiko zu minimieren, finden umfassende Tests und unabhängige Audits statt.

Die Auditoren von Neodyme führten Äquivalenztests durch, indem sie jede Mainnet-Transaktion der letzten Monate zweimal wiedergaben: einmal mit dem ursprünglichen Token-Programm und einmal mit p-token. Die Ergebnisse bestätigten identische Ausgaben und zeigten zugleich erhebliche CU-Einsparungen.

Laut ihrer Analyse hätte p-token zwischen dem 3. und 11. August 2025 den Overhead bei aktiviertem Logging um 8,9 Billionen CUs und bei deaktiviertem Logging um 9,14 Billionen CUs reduziert. Das entspricht Einsparungen von 12,0 % beziehungsweise 12,3 % der gesamten Blockspace-Nutzung.

P-token wird derzeit einem zweiten Audit durch Zellic und einer formalen Verifizierung durch Runtime Verification unterzogen.

Einführung

Die geplante Einführung von p-token erfolgt schrittweise. Sie beginnt mit dem Abschluss des Audits, des Fuzzings und der formalen Verifizierung. Danach stimmen die Validatoren im Rahmen der Governance über die Einführung von p-token und die formelle Annahme von SIMD 266 ab. Anschließend wird das p-token-Feature im Cluster bereitgestellt und hinter einem Feature Gate aktiviert.

Das Programm wird zunächst in einem festgelegten Account (ptokN…UkkZ2) bereitgestellt. Sobald das Feature Gate an der Epochengrenze aktiviert wird, ersetzt die Laufzeitumgebung auf allen Validatoren das bestehende Token-Programm (Tokenkeg…VQ5DA) durch die neue Implementierung. Dafür kommt der Upgradable Loader v3 zum Einsatz.

Alternativ könnte das p-token-Programm unter einer neuen Adresse bereitgestellt werden. Nutzer und Anwendungen müssten dann manuell migrieren. Dieser Weg wird jedoch nicht bevorzugt, da er die Verbreitung wahrscheinlich bremsen und den Gesamtnutzen schmälern würde. Viele Nutzer würden nur zögerlich oder langsam wechseln.

Wirtschaftliche Auswirkungen

Die Einführung von p-token ist Teil einer Reihe von Verbesserungen, die Solanas Gesamtkapazität drastisch erhöhen und mehr Transaktionen pro Block ermöglichen sollen. Zu den weiteren wichtigen Upgrades gehören die Verdopplung des Blockspace auf 100 Millionen CUs und die Anhebung des CU-Limits pro Account von festen 12 Millionen auf 40 % des Blocks.

Derzeit ist ein einzelner Account auf 12 Millionen CUs pro Block begrenzt. Wie das folgende Diagramm von Anza zeigt, erreicht der am stärksten umkämpfte Account in jedem Block häufig dieses Limit. Allein p-token erschwert es Accounts, diese Grenze zu erreichen. Dadurch treten Engpässe bei stark nachgefragtem Zustand seltener auf.

Fast alle Transaktionen enthalten heute entweder eine Priority Fee oder ein Jito-Trinkgeld, um Validatoren einen Anreiz zur Aufnahme in einen Block zu geben. Da sich die Priorität nach der Gebühr pro CU richtet, sollte eine p-token-Transaktion mit geringerem CU-Verbrauch bei ansonsten gleichen Bedingungen für dieselbe Gebühr oder dasselbe Trinkgeld eine höhere Priorität erhalten. Da jedoch alle SPL-Token-Transaktionen vom p-token-Upgrade profitieren, bleibt abzuwarten, wie es sich insgesamt auf die Priorisierung von Transaktionen auswirkt.

Fazit

Die Einführung von p-token wäre – sofern die Governance zustimmt – ein großer Schritt hin zu mehr Effizienz und Skalierbarkeit für Solana. Durch die drastische Senkung des Compute-Verbrauchs und die Vereinfachung von CPI-Interaktionen stärkt es die Grundlage des meistgenutzten Programms im Netzwerk und erhöht zugleich die gesamte Blockkapazität. Bei Erfolg könnte p-token als Blaupause für Pinocchio-optimierte Versionen anderer häufig genutzter Programme dienen, etwa des Associated Token Account (ATA)-Programms oder sogar des System-Programms. Das würde den Weg für eine schnellere und effizientere Laufzeitumgebung ebnen.

Weitere Ressourcen

• p-token-Repository - GitHub
• Pinocchio-Repository - GitHub
• Solana Program Library (SPL) - GitHub
• Rechner für SOL-Einsparungen mit p-Token - SendAI