Solanas Dezentralisierung messen: Fakten und Zahlen

Praktische Erkenntnisse

• Das Solana-Netzwerk verteilt sich auf 4.514 Nodes, darunter 1.414 Validatoren und 3.100 RPCs (Epoche 685). Kein einzelner Validator kontrolliert mehr als 3,2 % des gesamten Stakes.
• Der Nakamoto-Koeffizient (NC) bezeichnet die kleinste Zahl unabhängiger Einheiten, die sich böswillig verschwören können, um einen Ausfall der Verfügbarkeit herbeizuführen und den für die Produktion neuer Blöcke nötigen Konsens zu verhindern. Solanas Nakamoto-Koeffizient wird häufig mit 19 angegeben. Der tatsächliche Wert liegt wahrscheinlich niedriger, da einzelne Einheiten ohne Genehmigung mehrere Validatoren anonym betreiben können.
• Solanas Validatoren verteilen sich auf 37 Länder und Gebiete. Die größte Konzentration befindet sich mit 508 Validatoren in den USA. In vier Rechtsordnungen liegen jeweils mehr als 10 % des Stakes: in den USA 18,3 %, in den Niederlanden und im Vereinigten Königreich jeweils 13,7 % und in Deutschland 13,2 %.
• 68 % des Stakes sind an europäische Validatoren delegiert, 20 % an nordamerikanische. 50,5 % des Stakes sind an Validatoren innerhalb der Europäischen Union delegiert (europäischer Stake ohne Norwegen, die Ukraine und das Vereinigte Königreich).
• Die Validatoren verteilen sich auf 135 verschiedene Hosting-Anbieter. Die beiden führenden Anbieter sind Teraswitch, ein US-amerikanisches Privatunternehmen, das Validatoren mit zusammen 24 % des Stakes hostet, und Latitude.sh (ehemals Maxihost), ein brasilianischer Anbieter günstiger Bare-Metal-Server, die von Validatoren mit zusammen 19 % des Stakes genutzt werden.
• An der Codebasis des Agave-Clients haben 357 Personen mitgewirkt. Der Firedancer-Client, den ein kleines Team unter der Leitung von Forschungschef Kevin Bowers entwickelt, hat derzeit 57 Mitwirkende.
• Der Jito-Client, ein Fork der ursprünglichen Agave-Codebasis mit einer Blockspace-Auktion außerhalb des Protokolls, hält derzeit einen dominanten Anteil von 88 % am Stake des Netzwerks. Das dürfte sich in den kommenden zwölf Monaten jedoch deutlich ändern, wenn der neue Firedancer-Client schrittweise eingeführt und in das Ökosystem integriert wird. Solana und Ethereum sind derzeit die einzigen Layer-1-Blockchains mit mehreren Client-Implementierungen.
• Wesentliche Änderungen an den Kernkomponenten von Solana durchlaufen einen formellen und öffentlichen Vorschlagsprozess für Solana Improvement and Development (SIMD). Über die wichtigsten protokollverändernden Änderungen, insbesondere solche an wirtschaftlichen Parametern, wird in Governance-Abstimmungen entschieden. Bisher fanden drei solcher Abstimmungen statt.
• Die im Juni 2019 gegründete Solana Foundation ist eine in der Schweiz registrierte gemeinnützige Organisation, die das Solana-Ökosystem ausbaut und unterstützt. Das relativ kleine Team der SF mit 60 bis 65 Vollzeitbeschäftigten verwaltet die Finanzierung von Förderprogrammen, Staking-Programmen und Entwicklertools.
• Auch für die geografische Vielfalt der Solana-Entwickler-Community gibt es deutliche Belege. Am jüngsten halbjährlichen Hackathon Radar nahmen 13.672 Personen aus 156 Ländern teil, darunter besonders viele aus Indien, Nigeria, den USA und Vietnam. SuperTeam, ein Netzwerk für Kreative, Entwickler und Betreiber im Solana-Ökosystem, ist auf 1.300 Mitglieder in 16 Ländern gewachsen.

Was ist Dezentralisierung?

Dezentralisierung lässt sich als das Fehlen eines einzelnen Ausfallpunkts in einem System zusammenfassen. Dieses vielschichtige Konzept umfasst zahlreiche Dimensionen, darunter die Token-Verteilung, den Einfluss wichtiger Personen, die erlaubnisfreie Teilnahme am Netzwerk, die Kontrolle über die Entwicklung sowie die Vielfalt von Software und Hardware. Abgesehen von Balajis Nakamoto-Koeffizienten gibt es nur wenige allgemein anerkannte Standards, um den Dezentralisierungsgrad einer Blockchain zu messen. Viele Kennzahlen sind unvollkommen. Zudem führen Debatten über die Dezentralisierung von Blockchains, die oft in der politischen Philosophie verwurzelt sind, zu stark ideologischen und bisweilen fast religiösen Auseinandersetzungen.‍

Solana wurde von einem lautstarken Teil der Blockchain-Community erheblich kritisiert und mit Fehlinformationen konfrontiert, weil es angeblich an Dezentralisierung und Zensurresistenz mangele. Ein aktuelles Beispiel ist der ehemalige US-Geheimdienstmitarbeiter und Whistleblower Edward Snowden, der während einer Keynote auf der Konferenz Token2049 Bedenken äußerte.

Wie viele Kritiker von Solana legte Snowden keine Daten vor, die seine Aussagen belegen, obwohl er öffentlich dazu aufgefordert wurde. In den folgenden Abschnitten analysieren wir die Dezentralisierung des Solana-Netzwerks anhand von Daten. Dabei zeigen wir Bereiche auf, in denen das Netzwerk vergleichsweise stark dezentralisiert ist, und benennen Bereiche, in denen weitere Fortschritte nötig sind.

Dimensionen der Dezentralisierung

In diesem Bericht analysieren wir Solanas Dezentralisierung quantitativ und aus mehreren Perspektiven. Unsere Analyse basiert auf Fakten und öffentlich überprüfbaren Informationen. 

Wir untersuchen folgende Bereiche:

• Verteilung des Stakes
• Geografische Verteilung der Nodes
• Vielfalt der Hosting-Anbieter
• Vielfalt der Client-Software
• Vielfalt der Entwickler
• Governance-Prozesse und -Organisationen

Wo es sinnvoll ist, vergleichen wir die Kennzahlen des Solana-Netzwerks mit denen anderer Proof-of-Stake-L1-Blockchains der Branche. Vergleichbare Netzwerke dienen nur als Referenz. Sie geben Solanas Entwicklung hin zu mehr Dezentralisierung einen breiteren Kontext und zeigen, wo das Netzwerk hinter den Erwartungen zurückbleibt oder sie übertrifft.

Diese Vergleiche dürfen nicht als Versuch missverstanden werden, die Überlegenheit eines Netzwerks gegenüber einem anderen zu behaupten.

Ethereum ist in vielen Fällen die hilfreichste Referenz, da es weithin als die am stärksten dezentralisierte Layer-1-Proof-of-Stake-Blockchain gilt. Dabei ist zu beachten, dass Ethereum mehr als doppelt so alt ist wie Solana: Sein Genesis-Block entstand im Juli 2015, Solanas im März 2020. Dezentralisierung ist dynamisch und Blockchains werden mit der Zeit üblicherweise dezentraler. Unter ähnlichen Bedingungen ist daher zu erwarten, dass ältere Netzwerke einen höheren Dezentralisierungsgrad erreichen.

Verteilung des Stakes

Die Stake-Verteilung in einem Blockchain-Netzwerk beschreibt, wie die gestakten Token des Netzwerks auf seine Validatoren verteilt sind. In einem gut verteilten System hält weder ein einzelner Validator noch eine kleine Gruppe einen unverhältnismäßig großen Stake. Das verringert das Risiko, dass eine Einheit unangemessenen Einfluss auf den Netzwerkkonsens oder die Kontrolle darüber erlangt. 

Eine ausgewogene Stake-Verteilung fördert die Dezentralisierung, weil sie für vielfältige Validatoren sorgt und es böswilligen Akteuren erschwert, die Integrität des Netzwerks zu gefährden. Sie erhöht außerdem die Fehlertoleranz, da das Netzwerk widerstandsfähiger gegen den Ausfall einzelner Validatoren wird.

Eine Node im Solana-Netzwerk zu betreiben ist vollständig erlaubnisfrei. Für den Betrieb als Validator ist nur ein sehr geringer obligatorischer Mindest-Stake von 1 SOL erforderlich. Das Netzwerk unterstützt nativ Delegated Proof-of-Stake (dPoS) und besteht aus 4.514 Nodes, darunter 1.414 Validatoren und 3.100 RPC-Nodes. 

Die gemessen am Stake zwei größten Validatoren werden von Helius und Galaxy betrieben und halten jeweils rund 3,2 %. Der delegierte Mindest-Stake, der nötig ist, um zur obersten Drittel-Superminorität beziehungsweise zur obersten Zweidrittel-Supermajorität zu gehören, beträgt 4,4 Millionen beziehungsweise 1,23 Millionen SOL.

‍Zur besseren Übersicht gruppiert das folgende Diagramm die Validatoren nach delegiertem Stake. Am oberen Ende halten 82 Validatoren (5,87 % aller Validatoren) jeweils mehr als eine Million delegierte SOL. Am unteren Ende verfügen dagegen 825 Validatoren (59,1 % aller Validatoren) über weniger als 50.000 delegierte SOL. Die meisten nehmen am Solana Foundation Delegation Program (SFDP) teil, das kleineren Validatoren schneller zu einem nachhaltigen Betrieb verhelfen soll. Rund 72 % der Solana-Validatoren profitieren von der Unterstützung des SFDP und repräsentieren zusammen 19 % des gesamten Stakes. Eine ausführliche Analyse des SFDP findest du in unserem früheren Helius-Bericht: SFDP und die Herausforderungen für Long-Tail-Validatoren.

So wie Blockchain-Adressen nicht mit Nutzern gleichzusetzen sind, entspricht die Zahl der Validatoren nicht der tatsächlichen Zahl verschiedener Einheiten, die Validatoren betreiben. Die tatsächliche Zahl ist niedriger, weil größere Einheiten ihren Stake auf mehrere Validatoren verteilen können. Jito (1, 2), Coinbase (1, 2) und Mrgn (1, 2) betreiben beispielsweise mehrere Validatoren. 

Dass eine einzelne Einheit mehrere Validatoren betreibt, ist nicht grundsätzlich problematisch. Sind die Validatoren verteilt und nicht am selben Standort untergebracht, kann dies das Netzwerk sogar stärken, weil es die geografische Vielfalt und die Vielfalt der Hosting-Anbieter erhöht. Risiken können jedoch entstehen, wenn diese Validatoren identisch und mit nicht standardmäßigen Einstellungen oder Firewall-Regeln konfiguriert sind. Weitere Bedenken hinsichtlich der Dezentralisierung ergeben sich möglicherweise, wenn eine einzelne Einheit im Rahmen eines „Validator-as-a-Service“-Modells zahlreiche Validatoren für große Unternehmen oder Projekte verwaltet.

Nakamoto-Koeffizient

In Proof-of-Stake-Netzwerken bezeichnet der Nakamoto-Koeffizient die Mindestzahl an Nodes, die nötig ist, um mindestens ein Drittel des gesamten Stakes zu kontrollieren, also die Superminorität. Ein höherer Nakamoto-Koeffizient weist auf eine breitere Verteilung des Stakes und damit auf einen höheren Dezentralisierungsgrad hin. Er kann auch als kleinste Zahl unabhängiger Einheiten verstanden werden, die sich böswillig verschwören können, um einen Ausfall der Verfügbarkeit herbeizuführen und den für die Produktion neuer Blöcke nötigen Konsens zu verhindern. PoS-Blockchains und Blockchains auf Basis byzantinischer Fehlertoleranz benötigen die Zustimmung von mehr als zwei Dritteln des Stakes zum Netzwerkzustand, damit sie Transaktionen weiter verarbeiten können.

Um den Nakamoto-Koeffizienten des Solana-Netzwerks zu ermitteln, ordnen wir die Validatoren anhand ihres Stake-Anteils vom höchsten zum niedrigsten Wert und zählen, wie viele nötig sind, um ein Drittel des gesamten Stakes zu kontrollieren. Solanas Nakamoto-Koeffizient bewegte sich historisch zwischen einem Höchstwert von 34 am 13. August 2023 und dem aktuellen Tiefstwert von 19. Im vergangenen Jahr blieb der Koeffizient relativ stabil.

Im Vergleich zu ähnlichen Netzwerken der Branche liegt der Nakamoto-Koeffizient des Solana-Netzwerks im Mittelfeld. Diese Zahlen berücksichtigen nicht, dass einzelne Einheiten ohne Genehmigung mehrere Validatoren anonym betreiben können. Die tatsächlichen Nakamoto-Koeffizienten liegen daher wahrscheinlich niedriger.

Geografische Verteilung von Validatoren und Stake

Die geografische Vielfalt der Netzwerk-Nodes ist wichtig, um Risiken zu verringern und die Antifragilität des Netzwerks zu fördern. Konzentrieren sich zu viele Validatoren auf eine einzelne Region, hängt die Widerstandsfähigkeit des Netzwerks von den regulatorischen Rahmenbedingungen dieser Rechtsordnungen ab.

Auch Naturkatastrophen wie Erdbeben, Überschwemmungen, Hurrikane und Tsunamis stellen ein Risiko dar. Solche Ereignisse belasten nationale Stromnetze und können den Betrieb von Rechenzentren erheblich beeinträchtigen, was zu plötzlichen Ausfällen führt. Von Menschen verursachte Gefahren wie Krieg, Cyberangriffe und Schäden an kritischer Internetinfrastruktur, darunter Unterseekabel, schaffen weitere Risiken für die Stabilität des Netzwerks.

Die Solana-Daten für die Analyse dieses Abschnitts stammen für Epoche 685 von validators.app. Der Rohdatensatz ist hier als Tabelle verfügbar. Diese Zahlen umfassen nur Validator-Nodes mit Stake und keine RPC-Nodes ohne Stake.

Solana-Validatoren und Stake nach Kontinent

Nach Kontinent gruppiert zeigen die Daten, dass 632 Solana-Validatoren (46 %) in Europa und 550 (40 %) in Nordamerika ansässig sind. 68 % des Stakes sind an Validatoren in Europa und 20 % an Validatoren in Nordamerika delegiert. 50,5 % des gesamten Stakes sind an Validatoren innerhalb der Europäischen Union delegiert, also der europäische Stake ohne Norwegen, die Ukraine und das Vereinigte Königreich.

Zum Vergleich: Ethereum weist eine ähnliche Stake-Verteilung auf, wobei Nordamerika mit 34,4 % stärker gewichtet ist.

Solana-Validatoren nach Land

Die Validatoren des Solana-Netzwerks verteilen sich auf 37 verschiedene Länder und Gebiete. Die größte Konzentration befindet sich in den USA: 508 Validatoren (37 %) werden in US-Rechenzentren betrieben. Es folgen 112 Validatoren (8 %) in den Niederlanden und 111 Validatoren (8 %) in Russland.

Geografische Verteilung von Solana nach Stake

Gewichtet man die Validatoren nach Stake, ist die Verteilung ausgewogener. In vier wichtigen Rechtsordnungen liegen jeweils mehr als 10 % des Stakes: in den USA 18,3 %, in den Niederlanden und im Vereinigten Königreich jeweils 13,7 % und in Deutschland 13,2 %.

Zum Vergleich: Ethereum-Nodes verteilen sich auf 83 verschiedene Länder und Gebiete. Fast die Hälfte befindet sich in den USA oder Deutschland.

Top-10-Städte nach Zahl der Solana-Nodes und Stake

Eine detailliertere Analyse der Verteilung von Validatoren und delegiertem Stake nach Stadt zeigt, dass sich Solana-Validatoren weltweit auf 121 Städte verteilen. 

In den USA verteilen sich Validatoren über alle wichtigen Regionen und insgesamt 35 Städte. Am beliebtesten sind Chicago (124 Validatoren, 2,3 % des Stakes), Los Angeles (57 Validatoren, 2,3 % des Stakes) und New York (32 Validatoren, 3,5 % des Stakes).

‍Anfang dieses Jahres schlug der Anza-Mitarbeiter Rex St.John Strategien vor, um die geografische Vielfalt der Solana-Validatoren zu verbessern. Insbesondere solle die Präsenz von Betreibern im Globalen Süden ausgebaut werden.

Dabei wurden mehrere zentrale Herausforderungen identifiziert:

• Höhere Latenz: Nodes in abgelegenen Regionen können nur schwer mit dem Netzwerk synchron bleiben.
• Bandbreitenkosten: In einigen Regionen ist Bandbreite besonders teuer.
• Regulatorische Einschränkungen: Verschiedene Rechtsordnungen erlassen Gesetze, die den Betrieb von Blockchain-Infrastruktur erschweren.
• Unterentwickelte Infrastruktur: Die Netzwerk- und Rechenzentrumsinfrastruktur ist unzureichend.
• Ungünstige Steuern und Zölle: Hardware ist mit hohen Kosten belastet.
• Fachkräftemangel: Es fehlt an lokalem Solana-Fachwissen und am Zugang zu dem für das Staking erforderlichen Kapital.

Hosting-Anbieter

Idealerweise werden die Validatoren bei vielen unabhängigen Anbietern gehostet, statt stark von einigen wenigen zentralisierten Anbietern abzuhängen. Diese Diversifizierung ist entscheidend, um das Risiko von Netzwerkstörungen oder Zensur durch einen einzelnen Anbieter zu verringern.

Ein bemerkenswerter Vorfall im Jahr 2022 betraf den deutschen Hosting-Anbieter Hetzner. Er entfernte unerwartet Solana-Validatoren aus seinen Diensten und nahm damit innerhalb weniger Stunden mehr als 20 % des aktiven Stakes – rund 1.000 Validatoren – offline. Trotzdem blieb Solana ohne Probleme mit der Verfügbarkeit vollständig betriebsbereit. Die meisten betroffenen Validatoren wechselten innerhalb weniger Tage erfolgreich in neue Rechenzentren. Fast der gesamte ausgefallene Stake war innerhalb weniger Wochen wieder online.

Hosting-Anbieter von Solana-Validatoren nach Stake

Die Solana-Validatoren verteilen sich auf 135 verschiedene Hosting-Anbieter. Die beiden führenden Anbieter sind Teraswitch, ein US-amerikanisches Privatunternehmen, das 24 % der Validatoren hostet, und Latitude.sh (ehemals Maxihost), ein brasilianischer Anbieter günstiger Bare-Metal-Server, die von 19 % der Validatoren genutzt werden. Zusammen entfallen 43,4 % des Stakes auf diese beiden Anbieter. 

Weitere beliebte Hoster sind das französische Cloud-Computing-Unternehmen OVHcloud mit einem Anteil von 8,65 % und das litauische Unternehmen Cherry Servers, das 8,45 % der Validatoren hostet.

Hardwareanforderungen für Solana-Validatoren

Da Solana eine Hochleistungs-Blockchain mit hohem Durchsatz ist, stellt sie höhere Anforderungen an Nodes als die meisten vergleichbaren Netzwerke der Branche. Die Hardwareempfehlungen für Solana-Validatoren umfassen folgende Kernkomponenten:

• CPU: 24 Kerne/48 Threads oder mehr, Basistakt von 4,2 GHz oder höher 
• Arbeitsspeicher: 512 GB
• Festplatte: PCIe Gen3 x4 NVME SSD oder besser, insgesamt mindestens 2 TB, hoher TBW-Wert
• Keine GPU erforderlich

In der Praxis machen Solanas Bandbreitenanforderungen den Betrieb zu Hause unpraktikabel. Validatoren werden daher überwiegend auf Bare-Metal-Servern in dedizierten Rechenzentren betrieben. 

Vielfalt der Solana-Clients

Solana startete ursprünglich mit einem einzigen Validator-Client, der von Solana Labs entwickelt und in Rust geschrieben wurde. Der Solana-Labs-Client wird nicht mehr aktiv aktualisiert, doch ein Fork namens Agave ist derzeit aktiv im Einsatz. Die vollständige Abhängigkeit von einer einzelnen Client-Implementierung stellt einen bedeutenden Zentralisierungsvektor dar. Ein kritischer Softwarefehler könnte die Verfügbarkeit des gesamten Netzwerks beeinträchtigen. 

Die Client-Vielfalt zu erhöhen, hatte für die Solana-Community höchste Priorität. Mit der Einführung von Firedancer wird dieses Ziel nun endlich verwirklicht.

Solana-Client-Implementierungen

Heute sind mehrere Solana-Client-Implementierungen in Betrieb oder in Entwicklung:

• Agave: ein in Rust geschriebener Fork des ursprünglichen Solana-Labs-Clients, der vom Solana-Softwareentwicklungsunternehmen Anza gepflegt wird.
• Firedancer: eine vollständige Neuentwicklung des ursprünglichen Clients in der Programmiersprache C, die von Jump Crypto gepflegt wird.
• Frankendancer: ein hybrider Validator, der den Netzwerk-Stack und die Komponenten zur Blockproduktion von Firedancer mit der Ausführung und dem Konsens von Agave kombiniert.
• Jito: ein von Jito Labs entwickelter Fork des Agave-Clients. Er führt eine Blockspace-Auktion außerhalb des Protokolls ein und bietet Validatoren über Trinkgelder zusätzliche wirtschaftliche Anreize.
• Sig: ein von Syndica in Zig geschriebener und für Lesevorgänge optimierter Solana-Validator-Client.

Zusätzlich entwickelt Overclock mit Mithril einen in Golang geschriebenen Client, der als verifizierende Full Node mit geringeren Hardwareanforderungen dienen soll.

Wenn mehrere hauptberufliche Kernentwicklungsteams gegenseitig ihre Codebasen prüfen, steigt die Wahrscheinlichkeit deutlich, Fehler zu entdecken. Zugleich fördert dies den Wissensaustausch und die Zusammenarbeit.

„Wir haben viel vom Firedancer-Client-Team gelernt. Einige seiner Ideen waren wirklich clevere Lösungen“, erklärte der Anza-Entwickler Joe Caulfield in einem aktuellen Interview.

Sowohl Agave als auch Firedancer verfügen über umfangreiche Bug-Bounty-Programme.

Vielfalt der Solana-Clients im Vergleich zu Ethereum

Solana und Ethereum sind die einzigen Layer-1-Netzwerke mit mehreren Client-Implementierungen. Ethereum hat mindestens fünf bedeutende Software-Clients. Am weitesten verbreitet sind Nethermind, das in C# geschrieben ist und einen Nutzungsanteil von 45 % hat, sowie Geth, das in Go geschrieben ist und auf 39 % kommt. 

Auf Solana hält der Jito-Client derzeit 88 % des Netzwerk-Stakes. Diese Verteilung dürfte sich in den kommenden zwölf Monaten jedoch deutlich ändern, wenn die neuen Clients Frankendancer und Firedancer schrittweise eingeführt und in das Ökosystem integriert werden.‍

Dezentralisierung der Entwickler

In Quantifying Decentralization nennt Balaji die Dezentralisierung der Entwickler als entscheidenden Faktor für Blockchain-Ökosysteme. Er betont, wie wichtig es ist, die Abhängigkeit von einzelnen Mitwirkenden und das „Schlüsselpersonenrisiko“ zu verringern.

Die gesamte zentrale Client-Software von Solana wird öffentlich auf GitHub unter Open-Source-Lizenzen gehostet. Dadurch ist sie frei zugänglich und die Community kann dazu beitragen. ‍

Der von Anza gepflegte Agave-Validator spielt in diesem Umfeld eine bedeutende Rolle. Anza ist ein Anfang 2024 gegründetes Softwareentwicklungsunternehmen. Es startete mit rund 45 Beschäftigten, von denen etwa die Hälfte zuvor bei Solana Labs gearbeitet hatte. 

Neben der Verwaltung von Agave trägt das Anza-Team mit Initiativen wie Token-Erweiterungen, grenzüberschreitender Zahlungsinfrastruktur und Solana Permissioned Environments zum breiteren Solana-Ökosystem bei.

Zahl der Mitwirkenden an der Agave-Client-Codebasis

Die Codebasis des Agave-Clients hat 357 Mitwirkende und 26.408 Commits. Die reine Zahl der Commits ist jedoch unvollkommen und bildet die Tiefe der einzelnen Beiträge nicht vollständig ab. Eine relativ kleine Gruppe von Entwicklern – vor allem leitende Entwickler und Mitgründer von Solana – hat den Großteil der Commits erstellt. Daneben gibt es einen langen Ausläufer kleinerer Mitwirkender.‍

Zum Vergleich zeigen die beliebten Ethereum-Clients Geth und Nethermind ein ähnliches Muster: Die Beiträge konzentrieren sich innerhalb einer größeren Community auf wenige Personen. Geth hat 1.098 Mitwirkende, Nethermind 142. Mehr als die Hälfte aller Commits zu Geth stammt von drei Kernentwicklern. Bei Nethermind entfallen ebenfalls mehr als 50 % aller Commits auf zwei Entwickler.

Zahl der Mitwirkenden an der Firedancer-Client-Codebasis

Der Firedancer-Client wird von einem kleinen Team unter der Leitung von Kevin Bowers beim bekannten US-Hochfrequenzhandelsunternehmen Jump entwickelt. Derzeit hat er 57 Mitwirkende und 3.722 Commits. Da Firedancer ein relativ neues Projekt ist, bleibt die Vielfalt der Mitwirkenden begrenzt: Der erste Commit stammt aus dem August 2022 und der Client ging erst kürzlich im Mainnet live.

Entwickler im Solana-Ökosystem

Im breiteren Solana-Ökosystem gibt es deutliche Belege für die geografische Vielfalt der Entwickler-Community. Gemessen an der Teilnehmerzahl gehören Solanas halbjährliche Online-Hackathons zu den größten der Welt. Sie fördern viele der heute erfolgreichsten Solana-Protokolle und Anwendungsteams, darunter Tensor, Drift, Jito und Kamino. 

Am jüngsten Radar-Hackathon nahmen 13.672 Personen aus 156 Ländern teil. Besonders stark vertreten waren Indien, Nigeria, die USA und Vietnam.

Superteam, ein Netzwerk für Kreative, Entwickler und Betreiber im Solana-Ökosystem, ist auf 1.300 Mitglieder in 16 Ländern gewachsen. Seine lokalen Ableger fördern die Zusammenarbeit durch Veranstaltungen und gemeinsam genutzte Arbeitsbereiche. Solana Allstars, ein von Step Finance betriebenes Botschafterprogramm, ist in Nigeria sehr erfolgreich und hat in vielen Regionen mehr als 120 gut besuchte Meetups veranstaltet.

Governance

Governance ist ein wichtiger Faktor für die Dezentralisierung, da sie bestimmt, wie Entscheidungen im Netzwerk getroffen werden. Das betrifft alles von Protokoll-Upgrades bis hin zu Wirtschaftspolitik und Community-Regeln. Dezentrale Governance stärkt Transparenz, Fairness und Vertrauen in das Netzwerk.

Governance-Abstimmungen und SIMDs

Vorschläge für Solana Improvement and Development (SIMD) sind die formelle Dokumentation, die für jede wesentliche Änderung an den Kernkomponenten von Solana erforderlich ist. Als „wesentlich“ gelten Änderungen, die üblicherweise das Netzwerkprotokoll, die Gültigkeit von Transaktionen oder die Interoperabilität verändern. 

Für nicht wesentliche Änderungen wie kleinere Code-Refactorings oder objektive Leistungsverbesserungen sind keine Vorschläge nötig. Vorschläge sollten die Gründe für die Funktion erläutern und genügend Dokumentation enthalten, um die Implementierung nachvollziehen zu können. 

SIMDs können von allen Entwicklern und Forschern ohne Genehmigung eingereicht werden. Die meisten stammen jedoch von Entwicklern der Client-Teams, die hauptberuflich an Verbesserungen des Kernprotokolls arbeiten.

Es gibt zwei Arten von Vorschlägen: 

• Standardvorschläge: betreffen zentrale Solana-Funktionen wie Konsens, Netzwerk und API-Schnittstellen
• Metavorschläge: betreffen Prozesse oder Richtlinien außerhalb der Codebasis

SIMD-Prozess

SIMDs durchlaufen üblicherweise die Phasen Ideenprüfung, Entwurf, Überprüfung und Annahme. Eine formelle Prüfung findet öffentlich auf GitHub statt. Der Autor des Vorschlags ist dafür verantwortlich, Feedback von den relevanten Kernentwicklern einzuholen. Diese entscheiden, ob der Vorschlag angenommen, überarbeitet oder zurückgezogen wird. 

Autoren sind nicht verpflichtet, ihre Vorschläge zu implementieren. Üblicherweise wird ihnen jedoch dazu geraten, da dies die beste Möglichkeit ist, einen erfolgreichen Abschluss sicherzustellen.

Angenommene Vorschläge enthalten häufig ein zugehöriges Tracking-Issue für die Implementierung der Funktion und müssen möglicherweise über Solanas Feature-Gate-Mechanismus aktiviert werden. Feature-Gates werden an Epochengrenzen zuerst im Testnet, dann im Devnet und schließlich im Mainnet aktiviert.

Verbesserungen werden an folgenden Orten diskutiert:

• GitHub-Repository für SIMD (Solana Improvement Document)
• sRFC-Bereich (Solana Request for Comments) in den offiziellen Solana-Foren
• Solana Tech Discord
• Verschiedene soziale Kanäle, darunter X (ehemals Twitter) und Telegram

Governance-Abstimmungsprozess von Solana

Über bedeutende protokollverändernde SIMDs, insbesondere solche, die wirtschaftliche Parameter betreffen, wird in Governance-Abstimmungen entschieden. Der Governance-Abstimmungsprozess von Solana ist eine relativ neue Initiative langjähriger Mitglieder der Validator-Community. Er konzentriert sich ausschließlich auf kritische Fragen, um die Beteiligung aufrechtzuerhalten und Governance-Müdigkeit zu vermeiden. 

Bisher fanden drei solcher Abstimmungen statt:

• Erste beratende Abstimmung im Oktober 2023 (14,3 % Stake-Beteiligung)
• SIMD33 Zeitnahe Vote Credits im April 2024 (53 % Stake-Beteiligung)
• SIMD96 Volle Priority Fee für Validatoren im Mai 2024 (51 % Stake-Beteiligung)

Die Abstimmung erfolgt über Token, die in das Identity-Konto jedes Validators eingezahlt werden. Jedes Konto erhält proportional zu seinem aktiven Stake in Lamports Token. 

Um abzustimmen, übertragen Validatoren diese Token an einen von mehreren vorgesehenen Public Keys, die den verfügbaren Abstimmungsoptionen entsprechen. Dazu gehört auch die Möglichkeit, sich zu enthalten. Eine abgegebene Stimme kann nicht mehr geändert werden. 

In dieser Struktur beteiligen sich SOL-Token-Inhaber nur indirekt. Sie delegieren ihre gestakten SOL an Validatoren, deren Abstimmungsverhalten ihren Werten oder Präferenzen entspricht.

Governance-Benchmarking

Laut einem Anfang dieses Jahres veröffentlichten Benchmarking-Bericht von CCData gehört Solana zu nur vier mit AA bewerteten Assets unter den 40 führenden digitalen Assets, die nach Umwelt-, Sozial- und Governance-Standards (ESG) untersucht wurden. Die Governance-Bewertungen des Berichts, in denen Solana unter den L1-Blockchains den vierten Platz belegte, berücksichtigen unter anderem die Beteiligung der Stakeholder, die Transparenz und den Dezentralisierungsgrad.

Die Solana Foundation

Die im Juni 2019 gegründete Solana Foundation (SF) ist eine in der Schweiz registrierte gemeinnützige Organisation, die sich der Dezentralisierung, Akzeptanz und Sicherheit des Solana-Ökosystems widmet. Mit einem anfänglichen Bestand von 167 Millionen SOL-Token verwaltet die SF die Finanzierung von Förderprogrammen, ihr Delegation Program und Entwicklertools. Sie kontrolliert offizielle Markeninhalte, Social-Media-Konten, Websites und Markenrechte.

Die Foundation arbeitet mit einem relativ kleinen Team von 60 bis 65 Vollzeitbeschäftigten unter der Leitung von Executive Director Daniel Albert und President Lily Liu. Beaufsichtigt wird es vom Vorstand der Foundation.

Die Mission der SF besteht darin, ein skalierbares und selbsttragendes Solana-Netzwerk aufzubauen. Der Schwerpunkt liegt auf Bildung, Forschung und Initiativen zur Entwicklung des Ökosystems. Die SF organisiert große Solana-Veranstaltungen, darunter Hacker Houses und die jährliche Breakpoint-Konferenz, um Entwickler einzubinden und die Community zu stärken. ‍

Das Developer-Relations-Team der SF pflegt die offizielle Dokumentation, soziale Kanäle und Schulungsangebote für Entwickler. Im Januar 2024 übergab die SF die Verwaltung ihrer wichtigsten Hackathons an Colosseum, einen neuen unabhängigen Accelerator, den der frühere SF Head of Growth Matty Taylor mitgegründet hat.

„Unsere Aufgabe besteht darin, uns selbst überflüssig zu machen. Wir müssen skalierbare Wege finden, das Netzwerk und das Ökosystem zu unterstützen, und ihnen dann nicht mehr im Weg stehen“, erklärte Dan Albert bei einer kürzlich geführten Debatte. Damit deutete er das langfristige Ziel der SF an, ein Netzwerk zu schaffen, das sich ohne Aufsicht selbst tragen kann. 

Fazit

Wie diese Analyse zeigt, ist das Solana-Netzwerk bei zahlreichen zentralen Kennzahlen ähnlich stark oder stärker dezentralisiert als vergleichbare Netzwerke der Branche. Dazu gehören der Nakamoto-Koeffizient, die geografische Verteilung von Validatoren und Stake, die Dezentralisierung der Entwickler sowie Governance-Benchmarks. Eine wichtige Ausnahme bleibt die Client-Vielfalt, die der neue Firedancer-Client verbessern soll.

Es gibt mehrere Möglichkeiten, Solanas Dezentralisierung zu verbessern:

• Möglichkeiten prüfen, die Aufgaben der SF auf mehrere Organisationen zu verteilen
• Die Transparenz bei Ausgaben der Foundation und der Vergabe von Fördermitteln erhöhen
• Initiativen wie „Solana Nations“ entwickeln, um die geografische Vielfalt zu erhöhen
• Abstimmungskosten senken, die den größten Kostenfaktor für Validator-Betreiber darstellen
• Strategien prüfen, um die Anforderungen an den ausgehenden Datenverkehr von Validatoren zu senken; diese Kosten sind für Betreiber außerhalb der EU und der USA besonders hoch
• Eine aktivere Beteiligung an Governance-Abstimmungen fördern
• Solanas Community aus Kernentwicklern und Forschern erweitern, um die Entwicklung des Netzwerks zu stärken‍

Die Validatoren konzentrieren sich weiterhin teilweise auf die USA und die EU und sind von einer begrenzten Zahl von Hosting-Anbietern abhängig. Diese Herausforderung betrifft nicht nur Solana. Sie zeigt jedoch, wie Solana seine Position als eine der auf Validator-Ebene weniger zentralisierten Blockchains weiter verbessern kann.

Vielen Dank an Overclock, Amira Valliani, Matt Sorg, Yelena Cavanaugh, Dan Albert, Tim Garcia, 0xIchigo, Anatoly Yakovenko und Brady Werkheiser für die Prüfung früherer Versionen dieser Analyse.

Weitere Ressourcen

• Das Solana Foundation Delegation Program – Helius
• Die Solana Foundation sollte aufgelöst werden – Debatte auf der Breakpoint 2024
• Repository der Solana Improvement Documents (SIMDs) – GitHub
• Warum Solana dezentraler ist, als du denkst (2022) – Max Sherwood

‍