Raketen, Quantenbedrohungen, Nullen und Einsen: Dean Little über das Schmieden von Solanas Wahrheit

Einleitung

Blockchains bauen auf Lügen auf. Genauer gesagt auf höflichen Lügen, die sich als Abstraktionsebenen zeigen. Entwickler sehen eine Welt voller SDKs, APIs und Frameworks, die Geschwindigkeit und Sicherheit versprechen. Die Realität ist deutlich nuancierter und voller Register, Syscalls und Bytecode – eine Realität, in die sich nur die Besessensten wagen. Tatsächlich verursacht jede Abstraktion Overhead und jeder Compiler verbirgt die Wahrheit.

Dean Little hat seine Karriere damit verbracht, sich durch diese Lügen zu bewegen und durch das Löten von Schaltkreisen und Flashen von EEPROMS nach der Wahrheit zu suchen. Für Bitcoin entwickelte er Mining-Pools, GPU-Kernel und SPV-Tools. Er blieb dabei so nah wie möglich an der Maschine und erkannte das Potenzial verteilter Systeme, das sie damals nie ganz ausschöpfen konnten. Dann entdeckte er Solana, wo er für seine Ketzerei bekannt ist: Er schreibt Assembly von Hand, missachtet Compiler und missbraucht Syscalls – nicht weil es Spaß macht, sondern weil Geschwindigkeit Wahrheit ist.

Als Chief Scientist bei Zeus Network implementierte er das gesamte Bitcoin-Protokoll von Grund auf auf Solana und ermöglichte so einen nahtlosen Fluss von BTC-Liquidität. Als trotzige Antwort auf Quanten-FUD entwickelte er außerdem einen Tresor mit Winternitz One-Time Signatures. Damit lassen sich Zehntausende Assets pro Sekunde migrieren, während andere gerade einmal von sechs träumen. 

Doch Dean ist auch Lehrer. Von Turbin3 über Blueshift bis zu seiner jüngsten Arbeit als DevRel für das Team für mandarin- und kantonesischsprachige Märkte bei der Solana Foundation führt er Entwickler in eine Welt, die die meisten nie sehen werden. Er hat Hunderten Entwicklern beigebracht, On-Chain-Anwendungen zu veröffentlichen – oft in ihrer eigenen Sprache und von Grund auf. Dabei lebt er in einem ständigen Spannungsfeld: Menschen mit Abstraktionen abholen und sie dann hinunter zur Maschine führen. 

Ich wollte verstehen, was es bedeutet, in diesem Spannungsfeld zu leben – zwischen Bildung und Experimenten, Abstraktion und Assembly, Code für Menschen und Anweisungen für Maschinen. In diesem Interview geht es um diesen Dialog und darum, was es bedeutet, direkt mit der Maschine zu sprechen, während alle anderen an ihr vorbeireden.

Dieses Gespräch wurde aus Gründen der Kürze bearbeitet und gekürzt. 

Interview

Ursprünge und Weltbild

Ichigo: Lange vor Solana hast du Hardware repariert, EEPROMs geflasht und eingebettete Steuerungssysteme für Raketen geschrieben. Wie hat die Arbeit so nah an der Hardware – buchstäblich mit Lötkolben und Firmware – dein Weltbild als Entwickler geprägt?

Dean Little: Ich habe mit etwa zehn Jahren löten gelernt. Ich bin mit Mikroprozessoren und Mikrocontrollern aufgewachsen, wechselte dann in die Web- und Mobile-Entwicklung und stieß schließlich zu einem Raketen-Startup in Norwegen.

Bei der Arbeit an geschäftskritischen eingebetteten Systemen lernst du einige sehr wichtige Dinge. Erstens: Liebe zum Detail – denn wenn etwas ausfällt, kann es sehr schnell sehr schiefgehen. Zweitens: Einfachheit. Einfache, schnelle und leicht verständliche Systeme sind meist besser als übermäßig komplizierte. Und drittens lernst du, wie ein Angreifer zu denken. 

Bei der Arbeit an Ballaststeuerungen für Hochseeraketen frage ich mich ständig: Was passiert, wenn diese Steuerung ausfällt? Wie erkennen wir den Ausfall? Welche Backups haben wir? Was, wenn unsere Lageregelung falsch ist und wir glauben, nach oben zu zeigen, obwohl wir tatsächlich nach unten zeigen? Das zwingt dich, Systeme für den Fehlerfall zu entwickeln, statt anzunehmen, dass immer alles funktioniert.

Außerdem lernst du, der Arbeit anderer nicht blind zu vertrauen. Das gilt für Software und Hardware. Hardwarehersteller ändern Spezifikationen, der Einkauf bestellt versehentlich das falsche Teil, und plötzlich funktioniert nichts mehr. Es kann so vieles schiefgehen, und ein kleiner Fehler reicht aus, damit das gesamte System ausfällt. Diese Denkweise begleitet mich seitdem. 

Von dort führte dich deine Karriere schnell zu Bitcoin. Du hast an Mining-Pools, GPU-Kerneln, SPV-Tools und später an Twetch gearbeitet. Was haben dich diese Jahre an der Bitcoin-Infrastruktur über den Aufbau verteilter Systeme im großen Maßstab und über die damaligen Grenzen von Blockchains gelehrt?

Etwa 2017 begann ich, Vollzeit an Bitcoin zu arbeiten. Ich entwickelte für mehrere Blockchains – Bitcoin, EOS und einige andere, die damals beliebt waren. Anfangs nutzte ich Bitcoin nur. Als die Gebühren jedoch extrem stiegen, wurde es praktisch unbrauchbar. Das war der erste große Ansturm von Privatanlegern auf Krypto. Damals wurde mir klar: Sobald die Gebühren steigen, wird die Blockchain nutzlos.

Diese Erfahrung brachte mich dazu, das sogenannte „Skalierbarkeitstrilemma“ zu hinterfragen. Ehrlich gesagt ist es ein frei erfundenes Bullshit-Problem. Schon 2017 konnten wir 4-MB-Fotos in weniger als einer Sekunde um die Welt schicken. Die Vorstellung, Blockchains könnten nicht über 1-MB-Blöcke hinaus skalieren, wirkte lächerlich. Nicht die Physik war die Grenze, sondern das Design. 

Weil die Basisschicht von Bitcoin so stark eingeschränkt ist, musst du auf andere Weise innovativ werden. Ich vertiefte mich schließlich in Secp256k1 und entwickelte Lösungen, um Ausführungsergebnisse in Signaturen zu verbergen. Es war eine Art primitive verifizierbare Berechnung, lange bevor ZK wirklich Fahrt aufnahm.

Diese Jahre haben mich gelehrt, dass ein Bitcoin-Unternehmen in Wahrheit ein Infrastrukturunternehmen ist. Das Bitcoin-Protokoll kann viel, doch die Node-Software ist begrenzt. Das UTXO-Modell eignet sich hervorragend zur Parallelisierung, weil der Zustand getrennt ist – ähnlich wie bei Solana-Accounts. Für gemeinsamen Zustand und Indizierung ist es jedoch schrecklich. Das Account-Modell von Ethereum eignet sich dagegen gut für gemeinsamen Zustand, aber schlecht zur Parallelisierung. Bei Solana überzeugte mich das getrennte Account-Modell: Es verbindet die Parallelisierung von UTXO mit der Benutzerfreundlichkeit des globalen Zustandsmodells von Ethereum.

Meine wichtigste Erkenntnis aus diesen Jahren war, dass Systeme häufig ausfallen. Deshalb sollten sie so konzipiert sein, dass sie kontrolliert statt katastrophal versagen. Du solltest Einschränkungen nie einfach hinnehmen. Du solltest ihnen auf kreative Weise begegnen, an die andere noch nicht gedacht haben. Diese Philosophie prägt meine Arbeit an Solana.

Viele in der Solana-Community kennen dich inzwischen als den Typen, der Assembly schreibt und Compiler missachtet. Warum bleibst du so nah an der Maschine? Warum konzentrierst du dich nicht stärker auf bessere High-Level-Abstraktionen, wenn doch die meisten Entwickler damit arbeiten werden?

Entgegen der landläufigen Meinung arbeite ich an Anchor, Pinocchio, Agave, Alpenglow – im Grunde an allem – mit. Ich habe im gesamten Stack an Kryptografie, SIMDs und Low-Level-Programmen gearbeitet. 

Das größte Problem bei der Solana-Entwicklung ist, dass alles außerhalb von On-Chain-Programmen und Infrastruktur vollständig zugangsbeschränkt ist. Es ist fast unmöglich, meine PRs in ein offizielles Repository zu bekommen. Aber On-Chain-Programme? Ich kann alles tun, was das System versehentlich zulässt. Dort hält mich nichts zurück. Es ist erlaubnisfrei. Ich kann es einfach immer weiter verbessern und richtig abliefern.

Wenn du dir also meine Arbeit ansiehst, wie gut sie ist und was ich für On-Chain-Programme geleistet habe, und du das auch in anderen Schichten des Stacks willst, dann fang an, meine PRs zu mergen, haha.

Was Assembly betrifft: Offen gesagt leistet der Compiler schreckliche Arbeit, und die Leute, die daran arbeiten, machen es kaum besser. Sie haben sich nie die Zeit genommen, ihren tatsächlichen Endkunden zuzuhören – den Entwicklern. Deshalb mussten wir unsere eigene unabhängige Toolchain entwickeln, um uns das Leben zu erleichtern.

Leider sind die meisten Entwickler eher mittelmäßig. Nicht im negativen Sinn, aber sie sind nicht wie Cavey, ich oder die Ellipsis-DeFi-Chads, die wirklich wissen, wie man extrem performante Dinge schreibt. Wir sind diese seltsame kleine Untergruppe von Entwicklern, die wissen, wie man das System auf der niedrigsten Ebene an seine Grenzen bringt und es für alle anderen verbessert. 

Unser Feedback könnte äußerst wertvoll sein, wird aber meistens nicht ernst genommen. Deshalb entwickeln wir letztlich bei den Dingen weiter, an denen uns niemand hindern kann – und das ist die VM. Darum bleibe ich in dieser Hinsicht nah an der Maschine. 

Technische Innovationen und Beiträge

Du arbeitest an verschiedenen Teilen des Stacks – bei Zeus, Jupiter und in deiner Freizeit – und hast einige fortschrittliche kryptografische Primitive entwickelt und integriert. On-Chain-Kryptografie auf Solana gilt als notorisch schwierig. Wie sieht die Zukunft der Kryptografie auf Solana aus? Und wie erleichtern wir anderen die Entwicklung fortschrittlicherer Primitive – abgesehen davon, Leute anzuschreien, sie sollen PRs mergen, haha?

Meine Einschätzung ist, dass vor einigen Jahren eine ganze Reihe von ZK-Teams auf Solana entwickeln wollten. Im Grunde sagten wir ihnen: „Ja, das kommt.“ Dann tauchte Firedancer auf und sagte: „Nein, das mergen wir nicht“, und alles wurde aufgeschoben. Einige dieser Teams hatten Kapital aufgenommen und konnten ihre Unternehmen buchstäblich nicht betreiben, weil ihnen die nötigen kryptografischen On-Chain-Primitive fehlten. Sie mussten deshalb woanders hingehen. Das war wirklich hart. Entwickler so zu behandeln, ist falsch. Die ersten Kunden des Protokolls sind Entwickler. Wenn du dich nicht um sie kümmerst, wird nichts gebaut, und Privatanleger haben nichts zu nutzen. 

Also sagte ich einfach: Gut, dann finde ich es selbst heraus. Ich hackte den Secp256k1-recover-Syscall und befreite damit praktisch die gesamte Kurve. Jetzt kannst du Schnorr-Signaturen, Pedersen-Commitments, Bulletproofs, beliebige Multiplikationen elliptischer Kurven und sogar modifizierte Taproot-Adressen nutzen – ohne eine einzige Protokolländerung und für nur rund 25.000 CUs. Das schafft ein einzelner Typ in seiner Freizeit. Ich habe mehr kryptografische Protokolle ausgeliefert als Anza, oder? Stell dir vor, was möglich wäre, wenn das tatsächlich gefördert würde. Stell dir vor, die Entwicklung wäre offener. 

Das Lustige ist, dass die meisten gar nicht erkennen, wie groß dieser Durchbruch ist. Ich gehe auf eine Konferenz und erzähle einigen Leuten von Arcium, was ich gebaut habe. Sie sagen dann: „Das ist verdammt stark.“ Aber abgesehen von vielleicht zehn Leuten unter uns, die Krypto(grafie) auf Solana wirklich auf diesem Niveau verstehen, bemerkt es niemand. 

Und was Anza angeht: Das sind gute Leute, aber sie haben nur einen Kryptografen, Sam Kim. Er ist ziemlich gut, doch ich halte es für ein sehr schlechtes Zeichen, dass sonst niemand bei Anza etwas über Kryptografie weiß. Für das Alpenglow-Upgrade haben sie mich als Reviewer hinzugezogen. Ich prüfe Sams Code, und größtenteils ist er gut und seine Ideen sind sinnvoll. Es ist wohl positiv, dass sie die Fähigkeiten anderer anerkennen und nutzen. Letztlich wird Anza darin aber wahrscheinlich nie wirklich gut werden. Du brauchst mehrere konkurrierende Unternehmen, die gewisse Überschneidungen, aber jeweils eigene Spezialgebiete haben. Es ergibt keinen Sinn, dass Anza versucht, alles zu machen. Was wir wirklich brauchen, ist eine diversifizierte Core-Entwicklung.

Glaubst du, es ist eher ein kulturelles Problem? Ethereum hat zum Beispiel ganze L2s, die ZK gewidmet sind, etwa ZKsync oder StarkWare. Hat Solana ZK einfach als vages Skalierungskonzept abgetan? Nach dem Motto: Wir reizen lieber die Hardware maximal aus, darauf liegt unser Fokus – so skalieren wir die Chain. ZK muss auf Solana zwar nicht ausschließlich zur Skalierung dienen, wurde aber darauf reduziert und befindet sich jetzt in einer seltsamen Lage?

Ich glaube, die Tools sind nicht gut. Es gibt keine Tutorials zu ihrer Verwendung. Blueshift wird welche hinzufügen – wir versuchen gerade, die Little-Endian-SIMD-Sachen zu mergen. Sobald das erledigt ist, veröffentlichen wir ein einfach zu verwendendes, äußerst performantes ZK-Template und einige Tutorials. Wir wollen es Menschen erleichtern, Dinge zu entwickeln und ihre Funktionsweise zu verstehen.

Das aktuelle Problem ist, dass der Weg von null bis Hallo, Welt! auf Solana völlig absurd ist. Sieh dir Sui an: Folge fünf Minuten lang der Dokumentation, und du hast ein funktionierendes Hallo, Welt! Solana hat das nicht. Das ist also der Unterschied zwischen Mysten Labs, das etwa zehn Leute mit Kryptografiekenntnissen einstellt, und Anza, das einen einstellt, oder?

Meiner Ansicht nach geht man davon aus, dass es der Solana Foundation an technischem Verständnis für praktisch alles fehlt. Ihr Technologieverständnis reicht nur bis zur Kommerzialisierung, oder? Alles darüber hinaus lagern sie gedanklich an Anza aus. Die Vorstellung lautet: Wenn Anzas Antwort besagt, dass etwas gut ist, muss es gut sein. In Wirklichkeit ist die Antwort meist hinsichtlich der Performance gut, aber bei allem anderen nicht besonders.

Die Foundation geht davon aus, dass alles sehr gut läuft. Entwickler erleben dagegen: „Es ist schwer zu benutzen.“ Für Menschen, die besser sind als diejenigen, die Dinge auf Protokollebene implementieren, und ihre Arbeit unbezahlt leisten, ist es verdammt schmerzhaft, nicht ernst genommen zu werden. Es heißt dann: „Keine Ahnung, sie haben nicht das magische Anza-Abzeichen. Ignorieren wir sie lieber und vermeiden das Reputationsrisiko oder das Mergen eines Community-PRs.“ Deshalb fällt dir vielleicht auf, dass ich so hart kämpfe und mich stark für Open-Source-Entwickler einsetze. Wir müssen das loswerden, denn in der Community gibt es viele Leute, die wirklich gute PRs liefern. Klar, es gibt viel KI-Müll und viel Mist, aber auch viele wirklich gute Leute, die Aufmerksamkeit verdienen. Es ist eine Blockchain, ein verteiltes Netzwerk – wir sollten kein Anza-Abzeichen brauchen, um etwas beizutragen. Sie sollten einfach die Verantwortung übernehmen, sich um guten Code zu kümmern, unabhängig davon, wer ihn geschrieben hat.

Trotz alledem hast du mit Blick auf Innovation und Kryptografie auch einen quantenresistenten Tresor auf Solana entwickelt, der Winternitz One-Time Signatures verwendet. Was hat dich zu diesem Projekt inspiriert, und wie könnte es sich künftig weiterentwickeln, wenn Quantenbedrohungen glaubwürdiger werden?

Ehrlich gesagt begann es mit einem Tweet, haha. Ein Bitcoin-Maxi schrieb Ende letzten Jahres: „Solana wird das erste Opfer von Quantencomputern sein.“ Ich las das und dachte: „Okay, Bruder. Wenn wir Menschen jemals von quantenunsicherer zu quantensicherer Kryptografie migrieren müssen, kann unsere Chain mehr als 50.000 Migrationen pro Sekunde bewältigen. Eure schafft vielleicht sechs. Wen wird es wohl zuerst erwischen?“

Also sagte ich einfach: Scheiß drauf, ich setze es um. 

Zehn Tage später veröffentlichte ich den Winternitz-Tresor und zitierte seinen Tweet mit: GG. 

Das war der Antrieb – jemand sagte, es sei unmöglich. Ich hatte schon länger über Post-Quantum-Signaturverfahren nachgedacht, aber das gab den letzten Anstoß.

Und es funktionierte. Du kannst Guthaben in einer PDA außerhalb der Kurve speichern und den Winternitz-Tresor verwenden. Egal, was passiert – ob das Ledger zurückgesetzt wird oder Quantenangriffe die Leader-Signaturen beeinträchtigen – zumindest in der Version, auf die wir zurückrollen, ist dein Guthaben sicher. Es ist keine endgültige Lösung, aber ein perfektes Rettungsfloß. 

Wenn du als Fondsmanager Millionen oder Milliarden in LSTs oder gestaktem SOL hältst und Quantensicherheit plötzlich regulatorisch vorgeschrieben wird, blockiert das die Akzeptanz nicht mehr. Du brauchst kein Protokoll-Upgrade. Es funktioniert einfach.

Aktuell habe ich Ledger-Firmware entwickelt, die diese Signaturen erstellt, außerdem ein Wallet und eine Web-App. Blueshift wird wahrscheinlich später in diesem Jahr daran arbeiten, das Ganze benutzerfreundlicher zu machen. Natürlich ist es noch nicht dringend. Entscheidend ist aber: Die Option existiert schon heute. Das ist der Durchbruch.

Eigentlich ist es ziemlich lustig. Toly schrieb mir am nächsten Tag eine Direktnachricht. Im Scherz meinte er: „Bruder, ich dachte, ich müsste mich still und leise zurückziehen, sobald Quantencomputer verfügbar sind.“ Ich sagte: „Haha, nein, Bruder, geh nicht in Rente. Wir kümmern uns darum.“

Apropos Bitcoin: Du bist Chief Scientist bei Zeus Network und hast dort im Grunde das gesamte Bitcoin-Protokoll von Grund auf auf Solana implementiert. Was waren dabei die größten Herausforderungen? Und siehst du eine Zukunft, in der andere Chains auf Solana neu implementiert werden?

Das ist eine äußerst interessante Frage. Die Winternitz-Signaturen waren rechnerisch extrem aufwendig, aber gerade noch innerhalb einer einzelnen Transaktion machbar. Bitcoin befindet sich in einem ähnlichen Idealbereich. Es ist fortschrittlich genug für Dinge wie SPV-Proofs, aber immer noch primitiv genug, damit Solana als fortschrittlichere und performantere Plattform dieses Ding nehmen und in dieses Ding packen kann.

Bei Blockchains der zweiten Generation wie Ethereum ist es schwieriger. Sie sind deutlich weniger primitiv und viel komplexer. Die Frage lautet also: Kann Solana immer schneller werden und gleichzeitig einzelnen Transaktionen immer mehr Ressourcen zuweisen? 

Momentan ist das noch schwierig, aber nicht unmöglich. Für EVM-Kompatibilität fehlt heute vor allem der BigModExp-Syscall. Wenn wir ihn aktivieren, könnten wir meiner Meinung nach auf VM-Ebene beinahe vollständige Parität mit Ethereum erreichen. Das ist ziemlich verrückt, wenn man darüber nachdenkt. 

Die größere Frage lautet jedoch: Warum sollte man sich die Mühe machen? 

Bei Bitcoin liegt die Antwort auf der Hand: Es repräsentiert Billionen an Wert, ist der Goldstandard für Geld und primitiv genug, damit Solana es sauber nachbilden kann. 

Ethereum? Eher nicht. 

„Ultrasound Money“ ist ein Meme. Für einen kurzen Moment übertraf Solanas Sicherheitsbudget tatsächlich das von Ethereum. Macht das Solana zu Ultrasound Money? ETH auf Solana zu wrappen schafft bei Weitem nicht so viel Mehrwert wie BTC zu wrappen.

Daher denke ich, dass Bitcoin das richtige erste Ziel war. Es war technisch machbar und wirtschaftlich sinnvoll. Während Solana sich weiter verbessert, sehen wir vielleicht irgendwann auch andere Chains, die darauf neu implementiert werden. Aber ehrlich gesagt: Je performanter Solana wird, desto weniger Gründe gibt es, sich überhaupt mit anderen Chains zu beschäftigen.

Die Möglichkeit, all diese Funktionen in eine einzelne Transaktion zu packen, ist wirklich interessant. Kürzlich haben dich hocheffiziente Oracle-Updates mit Doppler und seinen Updates für 21 CU gepackt. Wie zeigen diese Leistungen mit niedrigem CU-Verbrauch Solanas Vorteil gegenüber anderen Chains? Auf anderen Chains gab es mit Gas Golfing ähnliche Entwicklungen. Doch welche einzigartigen Möglichkeiten eröffnet Solana?

Oracles sind eine wirklich interessante Fallstudie, weil sie im Grunde jeder als „gelöst“ betrachtet. 

Wenn du etwa einen Monat zurückblickst, hat Cavey mein noop-Programm genommen und 100.000 Transaktionen pro Sekunde im Mainnet erreicht. Das war cool. Jetzt wollen wir sehen, ob wir noch weitergehen können. Genauer gesagt: 100.000 Oracle-Updates pro Sekunde im Mainnet. 

Wenn das möglich ist, zerstört es das gesamte Narrativ: „Wir brauchen schnellere Blockzeiten, um mit Binance zu konkurrieren.“ Wenn du ein Oracle hunderttausendmal pro Sekunde aktualisieren kannst, wen interessieren dann Binance-Updates im Abstand von 20 Millisekunden?

Genau darum geht es bei Hyperoptimierung. Prop-AMMs nutzen bereits eine ähnliche Art von Update – nicht genau das, was ich veröffentliche, aber wer es weiß, weiß es. Momentan betten sie diese Logik tief in ihre Handelsstrategien ein. 

Mit Doppler gibt es kaum einen Grund, diese Komplexität in ihren Programmen zu belassen. Das Oracle-Update lässt sich vollständig herauslösen und eigenständig ausführen.

Auch der Footprint ist winzig. Das Doppler-Oracle umfasst nur etwa 480 Byte. Ich entwickle sogar ein TypeScript SDK, damit Entwickler ihre eigene angepasste Version direkt aus TypeScript bereitstellen können, ohne Rust anfassen zu müssen. Du definierst einfach ein Borsh-Schema, veröffentlichst es und kannst Oracle-Updates mit voller Geschwindigkeit raushauen. Natürlich können Rust-Entwickler dasselbe tun. Ich finde es jedoch interessant, dass jetzt sogar TypeScript-Entwickler diese Performance erreichen können, während im Hintergrund hyperoptimiertes Assembly arbeitet.

Zu den Anwendungsfällen gehören Zufalls-Oracles, Perps, Oracle-AMMs und Prop-AMMs – sie alle profitieren. Aber auch Dinge wie Zahlungskanäle oder L2-Skalierung. Wenn du Kanäle praktisch kostenlos öffnen und schließen kannst, ist das enorm. Im Grunde brauchst du kein riesiges, überladenes Anchor-Programm mehr, nur um ein Oracle zu aktualisieren. 

Abstraktion, Assembly und IBRL

Du bist dafür bekannt, Assembly zu schreiben. Sollten die meisten Entwickler deiner Meinung nach überhaupt damit arbeiten? Oder gehört es zu den Dingen, bei denen einige wenige die Grenzen verschieben, damit der Rest sicher weiter oben im Stack entwickeln kann?

Ich denke, jeder sollte zumindest ein wenig davon lernen. George Hotz, wahrscheinlich der beste lebende Programmierer, sagt: Jeder sollte Python, C und Assembly lernen. 

Wenn du Assembly nicht verstehst, verstehst du nicht, was der Compiler wirklich tut. Wenn du C nicht verstehst, weißt du all die Annehmlichkeiten von Python nicht zu schätzen. Ich halte Python nicht für besonders großartig. Rust ist beispielsweise eine sehr ausdrucksstarke Sprache, die sich sowohl auf hoher als auch auf niedriger Ebene einsetzen lässt. Sie ist eine hervorragende Wahl.

Also ja, ich würde sagen: Lern etwas Assembly und Rust. Irgendwann musst du auch TypeScript lernen, wenn du Frontends schreiben willst. Letztlich entwickelst du Produkte für Menschen. Sind deine Nutzer Entwickler, landet TypeScript früher oder später auf deinem Radar – ob es dir gefällt oder nicht.

Als ich anfing, Assembly auf Solana zu schreiben, tat das buchstäblich niemand. Ich entwickelte die Tools, veröffentlichte Beispiele, und inzwischen haben es einige Hundert Menschen ausprobiert. Vielleicht zehn davon sind wirklich gut. Manche haben sogar beeindruckendere Programme geschrieben als ich. Es geht hauptsächlich darum, die nötige Zeit zu investieren.

Meistens entwickle ich kleine, elegante, hyperperformante Dinge für einen einzigen Zweck – überall dort, wo ich bei der Ausführung eine potenzielle Kostenverbesserung um den Faktor 100 sehe. Meine Rolle besteht eher darin, zu erkunden, zu inspirieren und andere die Arbeit weiterführen zu lassen. Inzwischen bringt es mir nicht mehr viel, alles selbst zu bewerben, was ich entwickle. Daher hebe ich lieber andere hervor, retweete sie und helfe ihnen, sich einen Namen zu machen.

Ja, ich denke also, dass jeder zumindest Assembly lernen sollte. Es ist eine großartige Übung. Gleichzeitig stimmt es aber auch, dass eine Handvoll Menschen, die auf der niedrigsten Ebene hart an die Grenzen gehen, Verbesserungen schaffen können, von denen alle anderen profitieren. 

Sieh dir die große Mehrheit der Verbesserungen an Pinocchio in den letzten sechs Monaten an: Sie basierten alle auf Assembly-Optimierungen. Febo hat jeden einzelnen PR wie ein absoluter Chad geprüft und einige wirklich gute Sachen gemergt. Sieh dir etwa p-token an – dasselbe Konzept. 

Siehst du Low-Level-Programmierung nicht nur als technische Entscheidung, sondern vielleicht auch als etwas Ideologisches?

Ja, ich denke, es ist beides. Warum wollen Menschen zum Beispiel ein JPEG auf Bitcoin speichern? Es hat etwas Ursprüngliches und inhärent Interessantes, dieses stark eingeschränkte System für etwas zu nutzen, wofür es nie entwickelt wurde. Es ist irgendwie urkomisch und zugleich wunderschön. 

Neugier endet, wenn du aufhörst, Fragen zu stellen. 

Wenn du neugierig bist, lautet der logische Endpunkt deiner Neugier vermutlich ungefähr so: „Ich habe etwas in TypeScript geschrieben, das ein Anchor-Programm verwendet. Wie funktioniert Anchor? Wie funktionieren Makros? Wie funktioniert Rust? Wie funktioniert Assembly?“ 

Vielleicht steigst du dann tief in den Rust-Compiler ein, anschließend in MIR, LLVM IR und die Kompilierung zu eBPF. Dann fragst du dich, was eBPF ist, und liest über dessen Assembly. Schließlich blickst du auf den rohen Bytecode und erkennst, dass du einige Byte einsparen kannst, weil der Compiler etwas nicht automatisch optimiert hat. Das ist der logische Endpunkt dieser Nachforschung. Darin steckt definitiv ein ideologischer Aspekt.

Du arbeitest auch mit der Solana Foundation zusammen und hilfst mandarin- und kantonesischsprachigen Teams beim Einstieg, Debugging und Entwickeln. Du arbeitest mit all diesen Teams und hilfst ihnen, indem du Dinge einfacher und zugänglicher machst. Gleichzeitig bist du dafür bekannt, Assembly zu fördern und Syscalls zu missbrauchen. Wie bringst du dieses Spannungsfeld in Einklang? Wie balancierst du das Ziel, Entwickler näher an die Hardware zu bringen, mit der praktischen Notwendigkeit, ihnen den Einstieg über High-Level-Abstraktionen zu ermöglichen?

Wenn du dir Blueshift ansiehst, haben wir im Grunde ein durchgängiges Spektrum vom Anfänger bis zum Experten geschaffen. Meine Ansicht ist einfach: Du bekommst die Art von Entwicklern, für die du ausbildest. Wenn du ausschließlich Anchor oder TypeScript lehrst, ziehst du nur Entwickler an, die das für ausreichend halten. Sprichst du dagegen darüber, einzelne Compute Units mit handgeschriebenem Assembly einzusparen, ziehst du Entwickler eines anderen Kalibers an – Menschen, die tatsächlich verstehen, was diese Worte bedeuten.

Unsere Strategie bei Blueshift besteht darin, zunächst auf die Mitte der Kurve zu zielen. Dort sind die meisten Menschen, und dort erzielst du den besten ROI. Dann bewegen wir sie nach rechts, helfen ihnen, das nächste Niveau zu erreichen, und haben schließlich eine Armee starker Entwickler. Diese können sich umdrehen und die linke Seite der Kurve unterstützen – die absoluten Anfänger.

So lässt es sich einfach besser skalieren. Ich könnte jeden Tag Stunden damit verbringen, Anfängern beizubringen, wie man per CPI das Token Program aufruft, das 90 % aller Solana-Programme ausmacht. Oder ich kann hundert Menschen darin schulen, und jeder von ihnen kann hundert weitere einarbeiten. So skalierst du. 

Wir wollen Menschen auf ihrem jeweiligen Niveau abholen und sie immer weiter nach rechts bewegen. Blueshift, Solana Foundation – das Ziel ist dasselbe.

Bildung, Wissenstransfer und Community

Apropos Blueshift: Du hast es gemeinsam mit Turbin3 mitgegründet. Beide verfolgen einen starken Bildungsauftrag. Wie werden sich diese Initiativen deiner Meinung nach künftig entwickeln? 

Als ich zu Turbin3 kam, gab es dort nicht viel. Ich stieg ein, schrieb alle Programme für den Lehrplan und begann, die Abläufe zu leiten. Ich glaube, ich betreute drei oder vier Kohorten und bildete all diejenigen aus, die heute unterrichten. Innerhalb von neun Monaten hatte ich aus dem Nichts eine gute Ausbildung aufgebaut, die mich selbst ersetzen konnte. Danach blieb für mich nicht mehr viel zu tun. Menschen mit einer guten Ausbildung auszubilden zeigt, dass hier ein skalierbarer Schwungradeffekt entsteht.

Das Problem: Sie erhalten jedes Quartal tausend Bewerbungen und lehnen vielleicht 800 bis 900 Menschen ab. Wer aufgenommen wird, absolviert einen sechswöchigen Kurs und muss dreimal pro Woche zum Unterricht erscheinen. Am Ende gibt es weder ein Zertifikat noch einen anderen Nachweis über den Abschluss – vielleicht bürgen sie für dich, vielleicht auch nicht. Doch sechs Wochen sind eine lange Zeit, in der im Leben nichts schiefgehen darf. Dein Hund könnte krank werden, du musst mit ihm zum Tierarzt und verpasst einige Kurse. Plötzlich hängst du zurück und fliegst raus. Traditionelle Bootcamps kosten viel Zeit und Geld und optimieren nicht wirklich für die besten Entwickler. Entweder hilfst du Menschen, die das Bootcamp ohnehin nicht gebraucht hätten und nur einen Ausgangspunkt für ihre Karriere benötigen. Oder du führst wahrscheinlich Menschen an der Hand, die es ohne diese ständige Unterstützung nicht geschafft hätten. Keiner dieser Wege skaliert den Einstieg von Entwicklern so, wie Solana es heute braucht.

Die bessere Frage lautet also: Wie gibst du von den 800 bis 900 Menschen, die von Bootcamps abgelehnt werden, jenen eine Chance, die tatsächlich das nötige Potenzial haben? 

Blueshifts Antwort darauf ist hochwertiges, selbstgesteuertes Lernen. Wenn du dem Material folgen kannst, kannst du es in deinem eigenen Tempo abschließen und erhältst als Nachweis ein NFT. Alles ist Open Source, und wir fördern aktiv Pull Requests aus der Community. Wir erwähnen die Leute auf Twitter, um sie bekannt zu machen und ihnen beim Karrierestart zu helfen. Menschen reichen Verbesserungen ein, wir mergen sie, und dadurch wird die gesamte Plattform besser.

Statt zu sagen: „Tut uns leid, du wurdest nicht aufgenommen. Mehr Glück beim nächsten Mal“, sagen wir: „Hier ist der Lehrplan. Arbeite ihn in deinem eigenen Tempo durch und liefere ab.“ Unsere Lektionen sind bereits in acht Sprachen übersetzt. So können Menschen überall auf der Welt Meetups oder Bootcamps veranstalten. Superteam kann sie nutzen. Forma kann sie nutzen. Am Ende hast du einen objektiven Standard: Alle verdienen dasselbe NFT, du kennst ihr Niveau und kannst sie entsprechend einstellen oder herausfordern.

Blueshift löst all diese Probleme, indem es sich auf Entwickler konzentriert, die motiviert sind und hochwertigem, selbstgesteuertem Lernen folgen können. Wir akzeptieren, dass Menschen kritischer sind, wenn alles Open Source ist, und dadurch die kollektive Kompetenz der Community sichtbar wird. Wir mergen also ihre PRs und erhalten so die beste verfügbare Bildungsplattform mit den besten Inhalten.

Du hast es im Grunde bereits indirekt beantwortet, aber um es ausdrücklich zu fragen: Siehst du Entwicklerbildung eher als Übersetzungsproblem – komplexe Ideen zugänglicher zu machen – oder als Bootcamp-Problem – viele Menschen schnell auf ein Grundniveau zu bringen? Oder ist es etwas völlig anderes?

Ja, das Hauptproblem bei der Entwicklerbildung besteht derzeit darin, dass die kostenlos veröffentlichten Ressourcen Mist sind. Vieles ist veraltet. Praktisch jeder schreibt in Anchor oder Pinocchio. Niemand verwendet solana_program. Alles veraltet sehr schnell. Wenn alles Open Source ist, können wir gute Inhalte schnell und sorgfältig erstellen und pflegen. Offenbar will das sonst niemand wirklich tun. Deshalb machen wir es, weil es sonst niemand machen will. 

Selbst Mert erkannte das vor sechs Monaten, als wir darüber sprachen. Aus seiner Sicht war er froh, dass sich endlich jemand um dieses Problem kümmerte. Und wer wäre dafür besser geeignet als wir? Ich habe das Privileg, zu den einflussreicheren Entwicklern in diesem Bereich zu gehören. Alles ist Open Source. Wir haben keinen Burggraben, haha. Wir haben keinen riesigen Zuschuss der Foundation – wir finanzieren uns selbst. Wir haben alles selbst gemacht, und unser einziger Burggraben ist unsere Umsetzungskraft. 

Bildung ist ein Kontinuum. Du musst Menschen dort abholen, wo sie stehen. Die Aufgaben müssen anspruchsvoll genug sein, damit sie etwas lernen, aber verständlich und zugänglich genug, damit sie wiederkommen. Dann lockst du sie Stück für Stück nach rechts. Ich glaube, das kann ich gut. Deshalb ist Blueshift die ultimative Plattform, um Nerds anzufixen. Plötzlich denkst du: „Was zum Teufel? Warum schreibe ich jetzt Assembly?“ 

Der Blueshift Discord bietet außerdem DevRel-Services an, die Menschen bei ihren Projekten unterstützen, wenn sie nicht weiterkommen. Das Wichtigste ist, dass ich die meisten Fragen dort gar nicht selbst beantworte – das übernimmt die Community. Und das funktioniert viel besser als StackOverflow oder Ähnliches, weil die Community stark und engagiert ist.

Wie sieht die Zukunft von Blueshift aus?

Die Zukunft von Blueshift besteht im Grunde aus zwei Produkten: Coursera und LeetCode. Wir haben bereits eine akzeptable – nun ja, mehr als akzeptable, aber nicht ideale – Version dieser beiden Produkte. Sie muss jedoch besser werden. Wir arbeiten an einer V3, die vieles deutlich verbessern wird. 

Wir wollen Entwickler, die selbstgesteuert lernen können, äußerst effektiv unterstützen. Und ehrlich gesagt sind das die Entwickler, die ich lieber im Ökosystem hätte. 

Ich will Menschen, die einfach die Ärmel hochkrempeln und loslegen. Wir wollen ihnen das mit guten Ressourcen so leicht wie möglich machen. Verschwenden wir ihre Zeit also nicht mit veraltetem Mist, kaputten Abhängigkeiten und Ähnlichem. 

Das Endziel ist eine Plattform, auf der Menschen ohne Schubladendenken lernen können, was sie interessiert, und ihre Fähigkeiten anschließend durch verschiedene Challenges nachweisen können. 

Schnellfragerunde

Welche Musik hast du in letzter Zeit beim Schreiben von Assembly gehört?

Haha, normalerweise Death Metal.

Welchen Syscall kann man auf Solana am besten missbrauchen?

secp256k1_recover

Würdest du für den Rest deines Lebens lieber C# oder Java schreiben?

Nein.

Was ist besser: ein UTXO- oder ein Account-basiertes Modell?

Ein UTXO ist mehr wert.

Wenn du unbegrenzte Ressourcen hättest, welche Bildungsinitiative würdest du am liebsten schon morgen starten?

Blueshift plus IRL. 

Was ist dein wichtigster Tipp, um neuen Entwicklern Low-Level-Konzepte von Solana beizubringen, ohne sie abzuschrecken?

Selbstironischer Humor.

Fazit

In einer Welt der High-Level-Abstraktionen, die als „Realität“ akzeptiert werden, um die Massen anzulocken, ist Dean Little eine seltene Brücke – ein Low-Level-Alchemist, der aus den grundlegendsten Elementen Werkzeuge schmiedet, um andere auf seine Schultern zu heben. Sein Weg von Raketen bis zur Verbreitung hyperoptimierter Oracle-Updates offenbart das Ethos eines Entwicklers. Ein Ethos, das bei seiner Suche nach Wahrheit keine Kompromisse macht: Plane für Fehler, innoviere gegen Grenzen und vertraue niemals blind.

Ob er Quantentresore ins Leben ruft oder Blueshift skaliert, um die nächste Generation außergewöhnlicher Solana-Entwickler anzufixen – die hoffentlich auf den Schultern von Giganten stehen und nicht so viel Glas kauen müssen wie der Rest von uns –, Dean verkörpert das Feuer eines Puristen, gemildert durch die Wärme der Community. Es erinnert uns daran, dass echter Fortschritt nicht einfach bedeutet, mehr Holz ins Feuer zu werfen und Schicht auf Schicht zu stapeln. Es geht darum, diese Schichten abzutragen, das Summen der Maschinen freizulegen und anderen beizubringen, dazu zu tanzen.

Während Solana seinem nächsten Sprung entgegenrast – ob vollständige EVM-Parität, Alpenglow oder 100.000 Oracle-Updates pro Sekunde –, flüstert Deans Arbeit uns allen eine Herausforderung zu: Warum sich mit höflichen Lügen zufriedengeben, wenn du deine eigene Realität löten kannst? Wenn Neugier der Funke ist, sind Menschen wie Dean der Brandbeschleuniger.

Tauch ein, missbrauche einen Syscall, überlade eine Transaktion mit komplexen Funktionen – und wer weiß: Vielleicht tauchst du mit deinem eigenen Quantenrettungsfloß wieder auf.