Distributed Ledger erklärt – aus Alpinistensicht

Bergsteigen und Blockchain gehen (wider Erwarten) gut zusammen.Luke Helgeson



In modernen Unternehmen greifen wir oft standardmäßig auf zentralisierte Befehls- und Kontrollstrukturen zurück. In Umgebungen, in denen viel auf dem Spiel steht – sei es ein Andengipfel, der von einem Whiteout heimgesucht wird oder eine volatile, weltumspannende Supply Chain –, stellt diese Zentralisierung einen „Single Point of Failure“ dar.



Um Komplexität und Risiken zu managen, gilt es in beiden Fällen, sich an der Architektur dezentraler Netzwerke zu orientieren. Das habe ich auf dem dritthöchsten Berg Ecuadors – dem Vulkan Cayambe – selbst erlebt.



Der Sturm im Hochlager



Die Steinmauern der Schutzhütte konnten unseren Herzschlag angesichts des draußen tobenden Sturms kaum besänftigen. Der Wind pfiff durch die Ritzen im Mauerwerk, während gefrorener Regen wie eine Handvoll Murmeln gegen die Fenster prasselte. Ich lag auf dem Rücken, eingepackt in einen Schlafsack, und starrte auf die Unterseite des Etagenbetts über mir. Mein Rucksack stand aufrecht neben mir, Stiefel und Ausrüstung waren bereits mit fast schon zwanghafter Ordentlichkeit gestapelt, um im entscheidenden Moment des Aufbruchs maximale Effizienz zu gewährleisten. Mein Tagebuch, angefüllt mit den Erlebnissen der Woche, lag oben auf dem Rucksack neben meiner Stirnlampe.



Ich konzentrierte mich darauf, meine Atmung zu regulieren, um mich zu akklimatisieren. Ich atmete tief ein und aus, um jeden Hauch Sauerstoff in der dünnen Luft optimal zu nutzen. Um 1:30 Uhr morgens betrat unser Haupt-Guide den Raum und verkündete, dass die Wetterlage schwierig sei, weswegen wir abwarten müssten. Es wurde 2:00 Uhr, 2:30 Uhr, 2:45 Uhr, 2:46 Uhr – wenn es eine Besteigung gab, die ich nur zu gerne auslassen wollte, dann diese. Um 2:48 Uhr beschloss der Guide allerdings, dass wir den Aufstieg trotz des ungünstigen Wetters versuchen würden. Also machten wir uns in einer Gruppe von acht Menschen auf den Weg. Wir versammelten uns draußen, bildeten vier Seilschaften („Rope Teams“), sprachen die Route nochmals ab und nahmen den Gipfel des Cayambe ins Visier.



Auf der folgenden Tour bestimmten unsere Guides nicht jeden Schritt wie in einer traditionellen hierarchischen Struktur, in der Informationen nach oben geleitet werden müssen, damit eine Entscheidung getroffen wird (und dann wieder nach unten geleitet, um ausgeführt zu werden). Stattdessen funktionierte die Expedition als eine Reihe von Nodes, beziehungsweise Knotenpunkten (Rope Teams). Jeder Bergführer war in seinem spezifischen Kontext autoritativ und verfügte über die Autonomie, Entscheidungen in Echtzeit auf der Grundlage des unmittelbar vor uns liegenden Terrains zu treffen.



Auf einem Berg wäre eine Verzögerung (Latenz) wie in der hierarchischen Struktur tödlich. Indem Autorität verteilt wird, entsteht eine Expedition, die „composable“ ist. Jedes Team agiert unabhängig, bleibt aber durch den „Shared State“ des Berges synchronisiert.



Der unerbittliche Aufstieg



Unser erster Abschnitt erforderte einen schwierigen Aufstieg über 450 Meter freiliegenden Fels – während uns die Elemente unerbittlich um die Ohren schlugen. Unsere Stirnlampen waren gegen den Whiteout fast nutzlos. Gefrorener Regen bildete eine Kruste auf meinem Gesicht, Eiskristalle nahmen meine Schutzbrille in Beschlag. Um mein Gesicht zu schützen, hielt ich den Kopf gesenkt – meine Lampe schaffte es ohnehin kaum, mehr als ein paar wenige Meter Vulkanasche und Eis auszuleuchten.



Langsam stiegen wir weiter auf. Jeden meiner Schritte beendete ich mit einem bewussten Strecken des hinteren Beins – dem sogenannten „Rastschritt“ –, um einen Moment der Erholung zu gewinnen. Ich verlor zwei Teams bereits aus den Augen – die Lichter des dritten flackerten noch wie erlöschende Funken etliche Meter entfernt. Das Heulen des Windes wurde nur von kurzen „Pieptönen“ aus dem Funkgerät unterbrochen. Durch das Rauschen hörte ich die gedämpften Stimmen der Bergführer, die Standorte, Gefahren und Routen diskutierten. Selbst in der Isolation dieses Sturms wusste ich, dass wir miteinander verbunden waren.



Wir erreichten den Gletscher unabhängig voneinander. Ich schlüpfte in meinen Klettergurt, schnallte meine Steigeisen an und sicherte mich mit einem Seil. Sobald ein Team doppelt sicherheitstechnisch überprüft worden war, verschwand es in der Dunkelheit. Innerhalb kurzer Zeit wuchs der Abstand zwischen uns erneut, bis ich die anderen nicht mehr sehen konnte. Mein Guide und ich fanden jedoch einen eigenen Rhythmus, das Seil blieb straff zwischen uns gespannt.



In solchen Momenten – wenn niemand sonst auf dem Berg zu sehen ist – verlangsamt sich die Zeit. Die Herausforderung wird innerlich, und man beginnt, jede Lebensentscheidung zu hinterfragen, die einen auf einen gefrorenen Grat in 5.800 Metern Höhe geführt hat. Die Funkpieptöne setzten sich fort – der Grund dafür war ich. Bei unserer letzten Gipfelbesteigung des Antisana hatte ich mit einer hartnäckigen Bronchitis zu kämpfen, die sich nun zurückmeldete. Mein Blutsauerstoffgehalt sank unter 85 Prozent – leider versagte jedoch mein Notfallinhalator in dieser Höhe. Auf zwei Dritteln des Weges zum Gipfel setzte schließlich der Husten ein. Ich kämpfte, bis ich einfach nicht mehr konnte.



Ich hustete heftig, meine Lungen brannten und keuchten. Plötzlich vibrierte meine Apple Watch und wollte einen Notruf absetzen. Ich schaltete die Smartwatch also aus, richtete mich auf, aß und trank etwas. Als wir weitergingen, setzten sich die „Signale“ aber fort und häuften sich – bis mich schließlich die Realität in Form eines schweren Hustenanfalls einholte. Letztlich kehrten wir deshalb um, beziehungsweise machten uns an einen alles andere als eleganten Abstieg.



Das verteilte Tagebuch



Am selben Tag trafen wir uns alle zum Essen und jedes Teammitglied schilderte seinen Weg und seine Erfahrungen. Die Erzählungen wurden miteinander abgeglichen, wodurch sich ein vollständiges Bild des Berges abzeichnete. Die Entscheidung, umzukehren, wurde dabei nicht nur in meinem Kopf “festgehalten”, sondern im kollektiven Gedächtnis des Teams. Das ist der Kern der Unveränderlichkeit (Immutability). In einem Distributed Ledger kann ein Ereignis, sobald es verifiziert und dem „Block“ (oder der Tagesetappe) hinzugefügt wurde, nicht mehr verändert oder gelöscht werden. Es wird Teil einer permanenten, überprüfbaren Ereigniskette, die eine „Single Source of Truth“ für die gesamte Organisation darstellt.



Bis heute bin ich immer noch beeindruckt von der Architektur professioneller Berg-Expeditionen. Jeder Bergführer hat Autorität über seine Seilschaft und arbeitet autonom – ist aber dennoch vernetzt. Der Chef-Guide trifft nicht jede kleine Entscheidung selbst: Er delegiert sie an die Knotenpunkte (die jeweiligen Bergführer), damit sie das tun, was in ihrem spezifischen Kontext am besten ist. Zusammengenommen wird jede einzelne Team-Erfahrung zur „Truth“ der Tour.



Genau so funktioniert ein Distributed Ledger: Am Arbeitsplatz kann ein Journal oder eine „Composable Authoritative Source“ auf verschiedene Systeme und Datenbanken aufgeteilt werden. Ähnlich wie bei unseren Seilschaften tragen verschiedene Organisationen oder Abteilungen die Verantwortung für ihren Teil eines Datensatzes. Sie arbeiten unabhängig voneinander, bilden jedoch gemeinsam einen singulären, autoritativen „Ledger“.



Konsensmechanismen in High-Entropy-Umgebungen



Die größte Herausforderung in verteilten Systemen – unabhängig davon, ob sie digital oder menschlich sind – ist der Konsens. Auch in Unternehmen ist es eine Kernfunktion, dass sich mehrere unabhängige Akteure auf eine Version von „Truth“ einigen – und sämtliche „Transaktionen“ aufzeichnen. Ein Protokoll bietet die Möglichkeit, die Transaktionen zwischen mehreren Systemen über interne Funktionen hinweg oder extern mit Geschäftspartnern zu synchronisieren und gewährt so einen ganzheitlichen Überblick über Wertströme.



In einem Distributed Ledger wird die „Truth“ im Wesentlichen durch zwei Methoden ermittelt – die ich beide auf dem Cayambe beobachten konnte:




Synchroner Konsens: Über Funkgeräte lieferten unsere Guides Status-Updates, um sicherzustellen, dass alle „Rope Teams“ über dieselben, aktuellen Informationen verfügen. Die Abstimmung dieser Perspektiven über den Tag hinweg gewährleistet „Proof of Work“ – die Bestätigung, dass der festgehaltene Fortschritt tatsächlich stattgefunden hat.



Gossip-Protokoll: Bei dieser alternativen Kommunikationsmethode besprechen die Guides Routen und Risiken mit anderen Teams, wenn sie sich begegnen. Die Informationen „springen“ sozusagen von Team zu Team. Auch im Fall eines Distributed Ledger werden Informationen dabei jedoch nicht im Stil eines „Stille-Post“-Spiels verfälscht. Vielmehr handelt es sich um eine schnelle Peer-to-Peer-Synchronisation, die letztendlich sicherstellt, dass jedes System die exakt selben Daten enthält.




Im Jahr 2026 sehen wir eine Entwicklung, die über Konsens hinausgeht, und „Proof of Work“ auch für widerstandsfähigere, asynchrone Modelle bietet. Um bei unserer Cayambe-Storyline zu bleiben: Der synchrone Konsens kann Fehlertoleranz beinhalten, die es dem Netzwerk ermöglicht, eine Einigung zu erzielen, selbst wenn einige „Nodes“ (Bergsteiger) offline sind oder widersprüchliche Signale senden.



Darüber hinaus kann das Gossip-Protokoll erweitert werden, um die Historie darüber, wer was wann gesagt hat, als “Directed Acyclic Graph“ (DAG) weiterzugeben. Im Gegensatz zu einer linearen Kette ermöglicht ein DAG, dass mehrere „Events“ gleichzeitig stattfinden. Übertragen auf das Alpinisten-Szenario: Team A kann einen Steinschlag umgehen, während Team B einen Gletscher überquert. Beide Realitäten werden in den Master-Datensatz synchronisiert – wobei keine Seite darauf warten muss, dass die andere fertig wird.



Blockchain-Konzepte im Bergsteiger-Kontext



Unsere Reiseberichte und Tagebücher „sichern“ die Informationen des jeweiligen Tages. Die Bewegungen zwischen den verschiedenen Lagern und dem Gipfel werden als Informationsblöcke kodiert. Diese werden wiederum zu einer Abfolge von Ereignissen zusammengefügt. Würde jemand versuchen, die Historie des zweiten Tages zu verändern, stünde das nicht mehr in Einklang mit der Realität.



In einer digitalen Blockchain werden diese Daten verschlüsselt und in eine Sequenz gebracht. Dadurch ist die Transaktionshistorie dauerhaft und für jeden Teilnehmer überprüfbar. Transaktionen können nicht mehr gelöscht oder verändert werden. Allerdings gibt es einen pragmatischen Ansatz, falls regulatorische Bestimmungen ein „Recht auf Vergessenwerden“ vorsehen: Eine Hyperledger Fabric bietet die Möglichkeit, Informationen zu verändern oder zu löschen.



Die nachfolgende Tabelle veranschaulicht Blockchain-Konzepte im Alpinisten-Kontext:



Objekt“Berg”-BeispielDistributed LedgerNodeein einzelner Kletterer oder eine Seilschaftein Computer oder SystemTransaktionein Ereignis oder Faktum während des Aufstiegseine DatenaufzeichnungKonsensper Funkkommunikation, Storytelling oder Peer-to-Peer-Gossipüber die Validierung des „Work State“Blockein abgeschlossenes und verifiziertes Segment der Expeditionein Bündel verifizierter TransaktionenChaindie fortlaufende Route vom Basiscamp über die einzelnen Segmente bis zum Abschlussdie chronologische Anordnung von verlinkten Blöcken



Strategische Auswirkungen für Unternehmen



Wenn Sie sich nun Fragen, warum das für C-Level-Manager von Bedeutung ist: Indem sie sich ein Distributed-Ledger-Mindset aneignen, können Unternehmen einen verteilten Wertstrom erzeugen, bei dem Ledger über externe Geschäftspartner, Kunden und Lieferanten hinweg geführt werden. Das kann das Business enorm beschleunigen.



Konkret heißt das:




Flexibilität und Agilität: Mithilfe von Distributed Ledgers können Unternehmen von monolithischen zu modularen Systemen auf Basis von Microservices übergehen, die gemeinsam orchestriert werden.



Radikale Transparenz: Jeder Stakeholder hat Zugriff auf eine identische, in Echtzeit aktualisierte Aufzeichnung der „Truth“. Diese kann auch grenzüberschreitende Informationen mit externen Geschäftspartnern, Kunden oder Lieferanten umfassen. So entsteht ein vollständig integrierter Wertstrom, der „composable“ ist.



Operative Ausfallsicherheit: Wenn eine „Node“ (ein Lieferant oder eine regionale Niederlassung) ausfällt, gewährleistet das übrige Netzwerk die Integrität der Daten.



Geringere Reibungsverluste: Statt sich auf manuelle Audits oder Dritte zu verlassen, ist Trust Bestandteil der Systemarchitektur.




Letztendlich geht es bei einem Distributed Ledger weniger um den zugrundeliegenden Code und mehr um die Philosophie des kollektiven Vertrauens. Ob man nun durch die „Todeszone“ eines Berges oder die Komplexität eines globalen Marktes navigiert – die Wahrheit ist am resilientesten, wenn sie nicht „im Besitz“ eines einzelnen Guides ist. Sondern von allen getragen wird, die mutig genug sind, diese Reise anzutreten. (fm)



Dieser Beitrag wurde im Rahmen des englischsprachigen Expert Contributor Network von Foundry veröffentlicht. Alle Infos zum deutschen Experten-Netzwerk finden Sie hier.