Engineering-Geschwindigkeit: Einblick in Anzas Performance-Team mit Alessandro Decina

Einführung

Techno-Optimismus ist zweifellos der kulturelle Zeitgeist von Solana. Der unerschütterliche Glaube an grenzenlose Geschwindigkeit, Fortschritt und Innovation prägt jeden Pull Request, der im Mainnet landet. Das Mantra lautet IBRL: Bandbreite erhöhen, Latenz reduzieren. Es ist zu gleichen Teilen technisches Diktat, kulturelles Erkennungszeichen und säkulares Gebet. Wenn Bitcoin eine Kathedrale der Beständigkeit und Ethereum eine Agora der Neutralität ist, dann ist Solana eine Rennstrecke: ein Reich messbarer, mechanischer Geschwindigkeit.

Doch diese Geschwindigkeit fällt nie in Form eines sauber kommentierten Diffs vom Himmel. Sie wird von Menschen geschaffen, geschliffen und perfektioniert, die es wagen, den ganzen Tag auf Code zu starren. Kaum jemand tut das intensiver als Alessandro Decina, ursprünglich ein GStreamer-Genie, das ruckelnde Videopuffer als persönliche Beleidigung empfand. Heute leitet er Anzas vierköpfiges Performance-Team, dessen Vorstellung von „Selbstfürsorge“ darin besteht, um 3 Uhr morgens gelbe Balken aus einem Validator-Trace zu löschen. Ihr Alltag besteht darin, Flame Graphs anzustarren, komplette Workflows herauszureißen und praxiserprobten Produktionscode neu zu schreiben. Denn alles, was sich optimieren lässt, wird irgendwann optimiert.

Ich wollte verstehen, was es bedeutet, mit dieser Geschwindigkeit zu leben. Also setzte ich mich mit Alessandro Decina zusammen, um herauszufinden, wie er die schnellste Blockchain der Welt noch schneller macht. Das folgende Interview ist eine Autopsie der Geschwindigkeit. Wir sprachen über seine Zeit mit Multimedia-Pipelines und die kulturellen Leitplanken, durch die vier Engineers mehr ausliefern können als ganze Organisationen. 

Das Gespräch wurde für mehr Klarheit und Kürze bearbeitet und gekürzt.

Interview

Ursprünge und Weltbild

Ichigo: Werfen wir einen Blick zurück: Deine erste Liebe waren GStreamer und Multimedia-Pipelines. Was waren die wichtigsten Lektionen über Latenz aus dieser Zeit? Was hast du bei der Jagd nach Audio und Video in Echtzeit darüber gelernt, Agave um Millisekunden zu beschleunigen? 

Decina: Zunächst einmal: gute Arbeit beim Stalken, haha. Ich habe ungefähr 15 Jahre lang an GStreamer gearbeitet – vielleicht etwas länger. Dort habe ich wirklich alles gelernt, was ich weiß. Ich begann, zu dem Projekt beizutragen, als es Open Source war und gerade erst anfing. Und ich hatte großes Glück, denn ich kam dem damaligen Gründer näher. Der Typ war, keine Ahnung, 15 Jahre älter als ich und wirklich gut. Der Typ hat einen Wikipedia-Eintrag – wahrscheinlich ist er schlau. Nicht wie ich – ich tue nur so. Er entschied einfach: Ja, egal, ich bringe dir kostenlos alles bei, was ich weiß. Und so fing ich an, daran zu arbeiten.

Es ist schon lustig, dass wir bei Solana über niedrige Latenz sprechen, denn das hier ist überhaupt keine niedrige Latenz. Wenn du über Audioverarbeitung, DPSs und Multimedia-Hardware sprichst, haben die Dinge, die wir bei Solana machen, extrem hohe Latenzen. Hätten Audio oder Video eine Reaktionszeit von 400 Millisekunden, wären sie praktisch kaputt. Das funktioniert nicht.

Irgendwann begann ich, mit Linux-Treibern und Hardware für die Kodierung und Dekodierung von Video und Audio zu arbeiten. Vieles von dem, was ich heute mache, ist im Grunde dasselbe wie damals. Wenn du mit Hardware arbeitest, bedeutet Latenz, dass irgendwo eine Queue existiert. Du findest diese Queue. Du versuchst, sie zu minimieren und so klein wie möglich zu machen. Und du stellst sicher, dass sie niemals leerläuft.

Die XDP-Arbeit, die ich gerade mache, ähnelt zum Beispiel stark der Funktionsweise von Audio-Ringpuffern. Selbst bei unserem aktuellen Gespräch treffen viele Pakete in der falschen Reihenfolge ein. Irgendwo gibt es einen Ringpuffer, der alle Pakete neu sortiert. Und du willst unbedingt verhindern, dass er leerläuft.

Es fühlt sich an, als würde ich seit 20 Jahren dieselbe Arbeit machen.

Gleicher Kram, anderer Tag, könnte man sagen. Mir ist auch aufgefallen, dass du bei Spotify gearbeitet hast, und da war ein bisschen Firefox –

Ahh, nein, das Firefox-Zeug waren nur Integrationsarbeiten für einen Hackathon. Haha, ich bin so alt, dass ich das ursprüngliche Video-Tag für Firefox geschrieben habe, das GStreamer verwendete.

Verdammt, haha. Führen also alle Wege zurück zu GStreamer? 

GStreamer hat mir wirklich die Multithread-Programmierung beigebracht. Deshalb bin ich in diesem Ökosystem. Manche Leute schreiben Assembly und machen alle möglichen Low-Level-Hacks. Und ich denke mir: Ja, das mache ich schon lange. Dabei habe ich gelernt, dass du dir am Ende selbst ins Knie schießt, wenn du keine Sprache mit einem starken Typsystem und einem guten Compiler hast. Mit Assembly kannst du sicher etwas geringfügig schneller machen, aber ich will wirklich Rust. 

Ich will, dass der Rust-Compiler mir sagt: Du Idiot – das wird nicht funktionieren, weil du hier einen Bug hast. Vor Rust fühlte ich mich zu 10 % wie ein Software Engineer und zu 90 % wie ein menschlicher Debugger. Ich habe einfach nur Dinge debuggt. Deshalb glaube ich, dass GStreamer und meine Liebe zu Rust die Gründe dafür waren, dass ich bei Solana angefangen habe. Rust wurde immer populärer, es gab nicht viele Jobs, in denen man Vollzeit damit arbeiten konnte, und ich hatte beschlossen, nur noch mit Rust zu arbeiten. 

Ich bin zu alt, um C zu schreiben. Ich will keine speicherunsichere Sprache. Ich will meine Zeit nicht verschwenden. Also ja, hier bin ich.

Sehr schön. Hattest du vor deiner Arbeit am Validator-Code irgendwelche falschen Vorstellungen über dezentrale Systeme? Was hat dich davon überzeugt, dass die Architektur von Solana tatsächlich skalieren kann? 

Letztlich kam ich fast zwei Jahre zu spät zu Solana, weil ich mit der Arbeit am Rust-Compiler beschäftigt war. Jemand bei Solana, der gerade mit der Arbeit an der virtuellen Maschine begann, schickte mir eine E-Mail: „Oh, ich mache dasselbe. Es sieht so aus, als wärst du etwas weiter. Komm zu uns.“ Ich antwortete nicht, weil ich mir Bitcoin und dann Ethereum angesehen und festgestellt hatte, dass man zwar Dinge ausführen konnte, aber nur 10 TPS hatte. Das ist doch kein ernst zu nehmendes Projekt, oder? Mit 10 TPS kannst du nichts Reales umsetzen. 

Als ich diese E-Mail bekam, antwortete ich also nicht. Ich dachte einfach: Okay, diese Krypto-Leute meinen es noch nicht ernst.

Zwei Jahre später meldete sich Toly bei mir, und ich prüfte den Preis von SOL. Da dachte ich: Okay, ich hätte diese E-Mail öffnen sollen, haha. Dieses Mal sprach ich tatsächlich mit ihm. Vor dem Gespräch zeigte er mir etwas Code. Ich sah ihn mir an, und ehrlich gesagt war er schrecklich. Das war wirklich schlechter Rust-Code.

Dann sprach ich mit Toly, ohne ihn vorher zu googeln. Ich hatte also keine Ahnung, wer er war. Er war klug und sagte genau die richtigen Dinge. Er sagte: Wir bauen dieses Ding. Aktuell machen wir es so. Es ist offensichtlich nicht auf dem neuesten Stand, aber unser Ziel ist, mit der Hardware zu skalieren. Wir bauen die leistungsfähigste Blockchain, bis die Hardware zum Engpass wird. Die Idee ist: Je mehr Hardware du auf dieses Ding wirfst, desto stärker skaliert es.

Das überzeugte mich. Es fühlte sich nicht so an, als wären das nur ein paar Blockchain-Verrückte, die sich auf den Dritten Weltkrieg einen runterholen … Mich interessiert die Technologie. Ich gehöre zu den wenigen Krypto-Leuten, die wirklich wegen der Technologie dabei sind.

Solana hat diese Engineering-Kultur, in der die Technologie stark vom Techno-Optimismus geprägt ist – diese ganze Kultur von Bandbreite erhöhen, Latenz reduzieren. Wie stehst du persönlich dazu? Wie beeinflusst das den Alltag bei Anza? 

Für mich hat Ethereum grundsätzlich eine Knappheitsmentalität. Sie sagen: Okay, wir sind an einige Grenzen gestoßen und werden Umgehungslösungen dafür finden. Wir erfinden all diese Infrastruktur für Dinge, die im Grunde Wissenslücken sind, von denen wir glauben, dass wir sie unmöglich schließen können, richtig?

Ich habe dagegen das Gefühl, dass wir genau das Gegenteil sind. Wir sagen: Okay, da ist ein Problem. Es gibt keine unlösbaren Probleme – abgesehen von Dingen, die gegen die Gesetze der Physik verstoßen. Das ist einfach ein gewaltiger kultureller Unterschied.

Wenn etwas kaputt ist, sagen wir einfach: Okay, setzen wir uns hin. Erstellen wir ein paar Profile und sehen uns die Probleme an. Sprechen wir mit den Tradern und Market Makern. Finden wir heraus, welche Probleme sie haben. In letzter Zeit haben wir einige sehr konkrete Probleme gefunden. Die meisten davon haben wir behoben. Und ganz ehrlich: In zwei bis drei Monaten können wir sie alle beheben. 

Heute funktionieren viele Dinge in Solana nicht. Wir wissen davon, und wir haben uns nie hingesetzt und gesagt: „Wir haben die perfekte Lösung! Und um jetzt weiterzukommen, müssen wir etwas Neues erfinden oder forschen und etwas anderes tun.“ Nein – das sind konkrete Probleme. Die meisten davon sind wirklich dumme Probleme. 

Außerdem hatten wir in letzter Zeit keine Ausfälle. Ich persönlich halte das für ein schlechtes Zeichen, richtig? Denn ich glaube, einige Leute werden langsam etwas konservativ. Wir wissen, dass wir viel schneller werden können. Wir wissen, dass wir morgen Blöcke mit 100 Millionen CU schaffen können, richtig? Wir müssen einige Dinge einfach im Schnelldurchlauf erledigen. Und ich bin dafür, alles im Schnelldurchlauf zu erledigen.

Im Grunde wissen wir, dass wir keine Roadmap brauchen, um zu erkennen, dass wir die aktuelle Performance verzehnfachen können. Wir sehen, wie es geht. Wir wissen, wie es geht. Entweder haben wir den Code geschrieben und er ist noch nicht ganz fertig, oder wir haben ihn geschrieben und können ihn nicht bereitstellen, weil noch einige Edge Cases behoben werden müssen. Aber wir wissen genau, was zu tun ist.

Wir wissen, wie wir dieses Ding skalieren.

Performance Engineering

Apropos Performance-Arbeit: Ich glaube, viele wissen gar nicht, dass Anza ein eigenes Performance-Team hat. Es fliegt etwas unter dem Radar. Erzähl mir ein wenig über die Struktur des Teams. Wie unterscheidet es sich von anderen Engineering-Teams bei Anza? 

Genau, wir haben bei Anza verschiedene Teams. Aktuell haben wir die Consensus-Leute, die sich auf Alpenglow konzentrieren. Wir haben die Networking-Leute, die hauptsächlich an Gossip arbeiten. Dann gibt es die AccountsDB-Leute, die im Wesentlichen nur an der Account-Datenbank arbeiten. Das Blockproduktionsteam arbeitet am Scheduler. Und natürlich all die anderen Teams, die ich gerade vergesse.

Der Unterschied beim Performance-Team ist, dass wir an allem arbeiten. Wir erstellen Profile, finden einen Engpass und fragen die zuständigen Teams, ob sie Zeit und Fachwissen haben. Denn manchmal finden wir Probleme, die nicht jeder beheben kann. Wenn du zum Beispiel im Consensus-Bereich arbeitest, bist du nicht unbedingt besonders gut in Low-Level-Programmierung, weil dein Fachwissen woanders liegt. In solchen Fällen gehen wir normalerweise einfach rein und reparieren den Code für sie.

Wir arbeiten also nicht nur an einer Sache. Wir suchen einfach den nächsten Engpass. Ungefähr alle zwei Wochen stimmen wir uns ab und entscheiden, wo wir stehen, was als Nächstes zu tun ist und wie wir das nächste Release schneller machen.

Ein weiterer großer Unterschied ist, dass Anza tendenziell kluge Leute einstellt. Wenn du Rust nicht kennst, ist das okay. Wenn du keine Low-Level-Programmierung beherrschst, ist das auch okay. Wir gehen davon aus, dass wir dir die meisten dieser Fähigkeiten bei der Arbeit beibringen können, wenn du klug bist. Für das Performance-Team stelle ich normalerweise Leute ein, die tatsächlich Erfahrung mit dem Kernel oder anderen Low-Level-Themen haben. Das liegt an den Engpässen, auf die wir derzeit stoßen.

Bei der Account-Datenbank gibt es zum Beispiel einige algorithmische Probleme, die wir beheben müssen. Aber*,* der Grund, warum die Account-Datenbank im Release 2.3 etwa zehnmal schneller ist als noch vor zwei Monaten, liegt darin, dass wir ihre I/O-Verarbeitung korrigiert haben. Du musst wissen, wie das funktioniert, um es schneller zu machen. Wenn du Datenbanken nur auf einer höheren Ebene verstehst, weißt du nicht wirklich, wie Festplatten funktionieren. Und du musst nicht wissen, wie der Kernel I/O-Anfragen plant.

Deshalb stelle ich für das Performance-Team persönlich eher Low-Level-Leute ein. Auch hier ist es mir egal, ob sie Rust kennen. Aber ich möchte, dass sie mit C oder C++ an anderen Low-Level-Themen gearbeitet haben.

Dass kaum jemand vom Performance-Team weiß, liegt daran, dass wir im Grunde erst im Dezember angefangen haben. Ursprünglich wurde ich für die Arbeit am Compiler eingestellt. Rund um den Ausfall im März 2024 wechselte ich jedoch zu Performance und begann, Dinge zu optimieren. Die Leute waren nicht besonders glücklich, weil ich ihnen eines Tages einfach gesagt hatte, dass ich ab jetzt an dem arbeiten würde, worauf ich Lust habe. Also ja, haha, sie waren nicht glücklich. Aber dann erzielten wir wirklich gute Ergebnisse. Daraufhin kamen Leute zu mir und fragten: „Okay, willst du eigentlich noch mehr Leute dafür einstellen?“ Im Dezember machten wir die Performance-Initiative dann offiziell und gründeten das Team.

Ehrlich gesagt bin ich voreingenommen, aber das Performance-Team ist ohne jeden Zweifel das beste Team bei Anza.

Das bezweifle ich nicht, haha. Wie viele Leute sind im Team? 

Wir sind zu viert in Vollzeit. Aber ich habe auf Twitter Witze darüber gemacht, dass Brooks und einige andere dazukommen, weil ich begonnen habe, meinen Profiler breiter verfügbar zu machen. Bis vor etwa zwei Monaten hatten nur die Performance-Leute Zugriff auf den Profiler. Jetzt hat ihn jeder. Seit ich Brooks den Profiler gegeben habe, macht er zum Beispiel mehr Performance-Arbeit als ich, haha. Er ist völlig süchtig danach. Jetzt macht er einfach alles schneller.

Inoffiziell gehören jetzt also Brooks und ein paar andere dazu, die ebenfalls viel Performance-Zeug machen. Aber vier von uns arbeiten in Vollzeit an Performance. 

Wenn du an Performance arbeitest: Nach welchem Warnsignal suchst du beim Profiling, das die meisten Engineers übersehen würden? Wie entscheidest du, was optimiert werden muss? 

Einige Dinge sind wirklich offensichtlich. Als ich zum ersten Mal Profile von Agave erstellte, verbrachten wir viel mehr Zeit im Kernel als mit der Ausführung von Userspace-Code. Das ist lächerlich. Wir sind keine Low-Level-Anwendung. Bei einem Multimedia-Framework wäre es sinnvoll, dass der Großteil der Arbeit im Kernel stattfindet, weil du die Samples letztlich an die Hardware senden musst. Aber die einzige wirklich Low-Level-artige Arbeit, die wir machen, ist Turbine.

Das größte Warnsignal beim Profiling ist daher normalerweise viel Gelb in meinen Flame Graphs. Das bedeutet, dass wir zu viel Zeit im Kernel verbringen. Wahrscheinlich verwendet jemand eine High-Level-API, die harmlos aussieht, unter der Haube aber eine katastrophale Performance hat.

Im letzten Jahr haben wir den Speicherverbrauch von Agave um etwa den Faktor zehn reduziert, weil wir immer wieder auf dasselbe Problem stoßen. Wenn du zu viele Speicherallokationen durchführst, musst du irgendwann mit dem Kernel interagieren. Diese Interaktion siehst du im Profiler. Du fragst dich: Okay, woher kommt das? Du siehst, dass diese Kette den Speicher ständig belastet. Du verfolgst sie bis zu der Stelle zurück, an der du zu viel Speicher umwälzt und allokierst, und behebst das Problem.

Manche Dinge sind schwieriger. Zum Beispiel haben wir ein grundlegendes Designproblem gefunden, das ich gerade behebe. Solana verwendet bekanntlich eine Pipeline mit verschiedenen Stufen. Alles soll parallelisiert sein, damit die Dinge parallel laufen und so weiter.

In der Praxis haben wir aufgrund der Architektur zwar ein Pipeline-Design, aber auch sehr viele Unterbrechungen in dieser Pipeline. Wir haben verschiedene Stufen, maximieren jedoch nicht den Durchsatz aller Stufen. Der Grund sind dumme Designfehler, die an verschiedenen Stellen Latenz erzeugen. Über diese Latenz beschweren sich die Leute normalerweise, wenn sie keine Transaktionen senden können oder von Jitter im System sprechen. Dieser Jitter entsteht nicht durch etwas Grundlegendes oder durch die Hardware – wir machen die Dinge einfach nicht optimal. 

Aber ganz offen gesagt: Die Dinge, an denen wir arbeiten, sind dumm. Es gibt einige extrem offensichtliche Bugs, und wir beheben einfach diese offensichtlichen Bugs.

Wie entscheidest du, ob diese Bugs Micro-Benchmarks rechtfertigen oder ob der Mainnet-Traffic vollständig wiedergegeben werden muss? 

Ich glaube, die meisten unserer Performance-Probleme entstanden dadurch, dass Leute Micro-Benchmarks geschrieben haben. Sie haben die Micro-Benchmarks schneller gemacht. Sie haben sie isoliert getestet. Und wenn du dann alles in Agave zusammensetzt, funktioniert nichts wie in den Micro-Benchmarks.

Deshalb sage ich den Leuten persönlich: Verwendet Micro-Benchmarks für absolut gar nichts. Selbst Transaktionen wiederzugeben, habe ich im letzten Jahr vielleicht dreimal gemacht. Denn selbst wenn du Mainnet-Traffic wiedergibst, geschieht das nicht mit exakt derselben Geschwindigkeit wie bei der tatsächlichen Ausführung von Mainnet-Traffic. Dadurch ändern sich viele Dinge. 

Das ist auch ein Grund, warum wir den Start so viel schneller machen. Sonst ist es nervig, jedes Mal eine halbe Stunde warten zu müssen, wenn du prüfen willst, ob deine Korrektur funktioniert.

Wenn du mit Agave den aktuellen Stand erreicht hast, kannst du dich nicht mehr für nur eine Komponente tief in einem Kaninchenbau verlieren. Das mag intellektuell interessant sein, ist aber völlig nutzlos, wenn du nicht das gesamte System berücksichtigst. Es bringt tatsächlich nichts voran. 

Warum ist es mit Blick auf das gesamte System so wichtig, Turbine für XDP neu zu schreiben? 

Direkt vor Solana arbeitete ich im Networking-Bereich. Ich war bei einem Startup, das Deep Packet Inspection betreibt. Es fängt im Wesentlichen den gesamten Traffic ab, der bei einer NIC eingeht, analysiert ihn in Echtzeit, um schädliche Flows zu stoppen, und speist ihn anschließend wieder in den Kernel ein. Wir hatten im Grunde einen vollständigen TCP- und UDP-Stack im Userspace geschrieben – natürlich mit Rust, Tokio und XDP.

Als ich zu Anza kam, war offensichtlich, dass wir irgendwann XDP verwenden mussten. Als Firedancer startete, sagten sie: „Wir beginnen mit einer XDP-Implementierung von Turbine.“ Ich sagte ihnen, das sei dumm. Es ergab keinen Sinn. Das dauert sehr viel länger, weil XDP objektiv eine schreckliche API ist. Du willst sie daher so lange wie möglich vermeiden – bis dir buchstäblich die Räder abfallen.

Dann denkst du: Oh [zensiert], jetzt muss ich XDP verwenden. Genau das ist uns passiert. Wir hatten daran gearbeitet, alle anderen Engpässe in der Pipeline zu beseitigen. Dann begannen wir eines Tages mit Lasttests und sahen, dass Turbine komplett aufhörte zu funktionieren.

Also sagten wir: Okay, das ist eindeutig nicht mehr praktikabel. Ich habe wirklich, wirklich hart versucht, XDP nicht zu verwenden, weil ich es schon früher genutzt hatte und wusste, wie schrecklich es ist. Ich versuchte, eine auf io_uring basierende Implementierung von Turbine zu bauen. Dann fand ich einige Bugs in io_uring. Ich begann, diese Bugs zu beheben. Ich habe noch einige Kernel-Patches, die ich einsenden möchte. Aber irgendwann erkannte ich: Okay, ich kann nicht allen unseren Validator-Betreibern sagen, dass sie meinen eigenen Kernel verwenden müssen, um Solana auszuführen.

Ich musste XDP verwenden, und das haben wir getan. Jetzt funktioniert es.

Die Antwort lautet: Du findest den nächsten Engpass und behebst ihn. Dann behebst du weiter jeden Engpass, den du findest. Über die Probleme von morgen kannst du morgen nachdenken. Das ist mein Motto. Du könntest dir nur um morgen Sorgen machen, aber dann wäre heute beschissen. Heute ist Solana beschissen. Blöcke sind zu klein, Turbine verursacht zu viel Latenz und der Scheduler hat noch immer Probleme. Wir müssen die Dinge heute beheben. Sonst gibt es kein Morgen, an dem wir so schnell sein können.

Wie schützt ihr euch vor Performance-Regressionen? Wie koordiniert ihr euch mit Firedancer? 

Performance-Regressionen sind ein ständiger Kampf. Ich persönlich erstelle jeden Tag Profile von etwas in Agave, mindestens ein paar Mal täglich. Trotzdem haben wir oft Regressionen, denn performanten Code zu schreiben ist eine eigene Aufgabe. Du musst wissen, wie das geht. Wenn du Rust-Code schreibst, ist er im Durchschnitt performanter als Node.js-, Python- oder anderer Code. Wenn du aber beispielsweise an AccountsDB arbeitest und Collections mit Millionen von Elementen verarbeitest, kannst du nicht einfach nur Code schreiben. Es ist schwierig, effiziente Algorithmen zu entwickeln und mit großen Datensätzen zu arbeiten. 

Gelegentlich haben wir also Regressionen. Bis vor ungefähr einem Monat habe ich im Grunde nur alle angeschrien, haha. Bei Brooks und AccountsDB glaube ich, dass er mich irgendwann gehasst hat. Wir haben eine großartige Beziehung, aber bis vor einem Monat bestand ungefähr die Hälfte unserer Interaktionen daraus, dass ich ihn anschrie, weil etwas in AccountsDB langsamer geworden war.

Beim Protokoll hat die Zusammenarbeit mit Firedancer die Situation verbessert. Ich habe das Gefühl, dass viele Teile des Protokolls organisch als Reaktion auf unterschiedliche Herausforderungen gewachsen sind. Die Protokollentwicklung begann mit einer Idee. Man brachte sie in Produktion, und wie die meisten Ideen funktionierte sie beim ersten Mal nicht. Dann wurden weitere Dinge daraufgesetzt. Viele davon waren aus Performance-Sicht wirklich schlechte Ideen.

In Gossip gab es zum Beispiel etwas namens Epoch Slots. Dabei teilte der Cluster im Grunde allen mit, welche Validatoren welche Slots gesehen hatten. Vor sechs Monaten bemerkte ich ganz nebenbei beim Profiling einer anderen Sache, dass dieses Epoch-Slots-Ding mehr CPU-Zeit beanspruchte als die eigentliche Ausführung von Transaktionen. Bei der Bandbreite verbrauchte es viermal so viel wie Turbine. Es war einfach irgendein zufälliger Patch, der irgendwann auf das Protokoll gesetzt wurde, um ein Problem abzumildern.

Das passiert jetzt nicht mehr. Zum Teil ist das Firedancer zu verdanken. Wenn heute jemand einen Vorschlag macht, müssen wir mit Firedancer zusammenarbeiten. Sie entwickeln offensichtlich einen weiteren Client, haha, und müssen die Arbeit daher einplanen. Sie müssen entscheiden, wie lange die Umsetzung dieses Vorschlags dauern würde. Welche Priorität hat er? Deshalb leisten sie im Guten wie im Schlechten Widerstand. Sie hinterfragen viele oder fast alle Änderungen, die wir vornehmen. Und sie sind sehr gut darin, wirklich schlechte Änderungen abzuwehren. 

Wenn Turbine mit XDP ausgeliefert wird und du einen Monat ohne Meetings und Konflikte hättest – mit völliger Freiheit, an beliebigen Dingen zu arbeiten: Welchen Teil von Agave würdest du zuerst optimieren oder neu gestalten? 

Ich will wirklich – ich träume buchstäblich davon – AccountsDB seit etwa zwei Jahren neu schreiben. Ich weiß nur, dass es mich buchstäblich ein oder zwei Monate meines Lebens kosten wird, sobald ich damit anfange. Momentan wäre das nicht die beste Nutzung meiner Zeit. Aber ich werde es tun. Ich versuche ständig, Brooks dazu zu drängen. Wenn er es nicht macht, werde ich es irgendwann selbst tun.

Künftige Entwicklungen

Mit Blick auf geplante Funktionen wie asynchrone Ausführung oder mehrere gleichzeitige Leader: Was würde dem Performance-Team die größten Kopfschmerzen bereiten? 

Aus dem Bauch heraus hasse ich asynchrone Ausführung. Das aktuelle Modell ist sehr einfach. Du erhältst einige Transaktionen, spielst sie sehr schnell wieder ab und stimmst dann ab. Konzeptionell ist das extrem einfach. Asynchrone Ausführung macht das Design schwieriger, verbessert aber auch die tatsächliche Nutzung der Chain erheblich.

Ich hasse auch das Design für mehrere gleichzeitige Leader, haha. Ich verstehe, dass du mehrere Leader brauchst, insbesondere für High-Speed-Trading. Es gibt keine Alternative. Aber persönlich glaube ich, dass das frühestens in 12 Monaten passieren wird. Deshalb will ich mich davon nicht zu sehr ablenken lassen.

Es ist wichtig, dass wir in einem Jahr Alpenglow haben. Aber ebenso wichtig ist, dass wir im nächsten Monat hundert Millionen CUs schaffen. Wir müssen uns darauf konzentrieren, das, was wir jetzt haben, schnell zu machen. Denn Alpenglow ist neuer Code, und mehrere gleichzeitige Leader sind ebenfalls neuer Code. Es gibt unbekannte Unbekannte. Nehmen wir an, Alpenglow gerät aus irgendeinem Grund wie Firedancer in Verzug. Was dann? Behalten wir dann die beschissene, langsame Chain, die wir heute haben? Nein, wir müssen uns darauf konzentrieren, heute schnell zu werden.

Ratschläge zum Performance Engineering

Welche Ressourcen würdest du jemandem mit Rust-Erfahrung empfehlen, der in Performance-Programmierung und Profiling einsteigen möchte?

Zunächst empfehle ich einen guten Profiler, den es heute nicht gibt, haha. Aber hoffentlich veröffentliche ich meinen bald. Außerdem glaube ich, dass du Dinge am besten lernst, indem du sie auf etwas anwendest, das dir wirklich wichtig ist.

Mein Rat an Leute, die Performance-Arbeit lernen wollen, lautet daher: Sucht euch Software, die ihr täglich verwendet und liebt. Erstellt Profile davon und macht sie schneller, denn sehr viel Software ist sehr langsam. Auch viele schnelle Programme könnten noch viel schneller sein. Computer sind wirklich schnell. Und weil sie so schnell sind, kannst du sehr leicht etwas Langsames entwickeln, ohne es überhaupt zu bemerken.

Viele Leute werden süchtig danach, wenn sie etwas auswählen, das sie selbst verwenden, Profile davon erstellen und es schneller machen. Sende Pull Requests, und ich garantiere dir, dass sie akzeptiert werden. Du wirst völlig davon abhängig werden.

Der Kernel ist nur eine weitere Abhängigkeit. Wenn du an etwas arbeitest und eine Library verwendest, musst du früher oder später wahrscheinlich in diese Library schauen, wenn etwas nicht funktioniert, langsam ist oder was auch immer. Der Kernel ist einfach eine weitere Library. Also*,* lies Kernel-Code. Kernel-Code gehört zu dem einfachsten Code, den ich je gesehen habe. Wenn du dir den Scheduler im Kernel ansiehst, ist er konzeptionell einfacher als der Scheduler, den wir bei Solana haben. 

Lies einfach den Linux-Code. Er ist in C geschrieben, was nicht ideal ist, und alles, was Hardware berührt, ist normalerweise verflucht, haha. Aber der Großteil von Solana arbeitet nicht direkt mit der Hardware. Du kannst dir allgemeine Dinge ansehen, die du täglich nutzt, etwa einen Syscall, Tokio oder Dateisystemcode. Das ist sehr einfach. Lies es einfach. Wenn du eine Woche damit verbringst, lernst du es wie jeden anderen Code. Und du wirst dich wie ein verdammtes Genie fühlen. Du wirst denken: Ahh, jetzt kann ich Kernel-Arbeit machen, weißt du?

Wie kann man heute am besten mit Beiträgen beginnen?

Ich bevorzuge es, Discord beizutreten und in den Entwicklungskanal des Solana Tech Discord zu gehen. Da gibt es zum Beispiel einen Typen, der an einigen Networking-Themen arbeitet und neulich einfach ein Gespräch über den TPU-Code begann. Ehrlich gesagt versteht er besser als die meisten Leute bei Anza, wie dieser Code funktioniert. Du kannst also beitragen. Und wenn du so gut bist wie dieser Typ und mir Patches schickst, werde ich sie mergen.

Wir machen intern nicht viel Entwicklung, die nicht offen ist. Wenn du also in einem Codebereich, den du für langsam hältst und gut kennst, keinen Pull Request siehst*,* und ihn verbessern willst, sag mir auf Discord Bescheid. Wir erstellen ein Issue, weisen es dir zu, und du behebst es.

Ich möchte, dass Leute mir Patches schicken. Ich will unsere Community tatsächlich durch das Einsenden von Patches vergrößern.

Schnellfragerunde

Was war der schwierigste Bug, den du dieses Jahr beseitigt hast?

Eine Fehlkompilierung von Fließkommacode, die noch vor ein paar Monaten das Release 2.2 blockierte. Es war nicht das schwierigste Problem, aber das mühsamste, weil ich tagelang nur Assembly-Code lesen musste.

Welche Musik hörst du in Dauerschleife, wenn du Flame Graphs anstarrst? 

Normalerweise House oder Minimal Techno. Stephan Bodzin läuft meist in Dauerschleife.

Was ist deine Lieblings-Linux-Distribution? 

Definitiv Debian. Es ist die einzige, die nicht extrem nervt, haha.

Was ist die beste Optimierung, die mit Alpenglow kommt? 

Dass wir Votes nicht mehr ausführen. Vote-Transaktionen sind [zensiert]. Und es ist so gut, dass dieser ganze Abstimmungskram keine Transaktionen mehr verwendet.

Was hältst du von ZK? 

Es ist eine großartige Technologie. Für die Skalierung von Blockchains befindet sie sich meiner Meinung nach aber noch stark in der Forschungsphase. Deshalb interessiert sie mich nicht besonders. 

Juli 2026, also in einem Jahr: Welche Slot-Zeit erwartest du?

Persönlich will ich Slots von 200 Millisekunden – hoffentlich schon früher. Ich sage Toly ständig, dass er daraus ein Meme machen muss, bis es Realität wird. Hoffentlich ist es bis dahin passiert. Ich glaube, wir könnten es sogar heute schaffen. Das wäre für mich das Minimum, denn alles darüber wäre ein Fehlschlag. Aber wir können noch tiefer gehen.

Wann wird Agave die schicksalhafte Marke von 1 Million TPS erreichen? 

Haha, darauf gebe ich keine schnelle Antwort. Ich frage die Leute ständig: „Woher sollen die eine Million Transaktionen kommen?“

Wir schaffen eine Million TPS, wenn die Leute eine Million TPS zu senden haben. Leider glaube ich aber nicht, dass das in naher Zukunft passieren wird. Ich habe gesagt, dass ich meinen Job kündige, wenn Agave bis Oktober keine Million TPS schafft. Vielleicht muss ich also irgendeine Demo vortäuschen, haha. 

Fazit

Alessandro Decina verkörpert das schlagende Herz der Performance-Kultur von Solana: ein unermüdliches Streben nach Geschwindigkeit, das auf pragmatischem Engineering statt theoretischer Perfektion beruht. Sein Performance-Team leistet weit mehr, als seine Größe vermuten lässt. Es findet und behebt die „dummen Bugs“, die sich gemeinsam zu systemweiten Verlangsamungen summieren.

In einer Welt, in der sich viele Teams in großen Architekturvisionen verlieren, konzentriert sich Anzas Performance-Team konsequent auf die Engpässe direkt vor ihnen. Profil erstellen, Problem identifizieren, beheben, wiederholen. Es ist unspektakuläre Arbeit mit spektakulären Ergebnissen: eine Blockchain, die tatsächlich mit der Hardware skaliert, statt um deren Grenzen herum.

Das Gespräch zeigt eine grundlegende Wahrheit über den Bau von Hochleistungssystemen: Bei Geschwindigkeit geht es nicht nur um clevere Algorithmen oder modernste Hardware. Es geht um die kulturelle Verpflichtung, sich nie mit „gut genug“ zufriedenzugeben, wenn „großartig“ technisch erreichbar ist. Für Solana bedeutet das, dass Slots von 200 Millisekunden, asynchrone Ausführung, mehrere gleichzeitige Leader und dauerhaft mehr als eine Million TPS nicht nur technische Meilensteine sind – sie sind unausweichlich.