Aufbau der "Nicht-Böse-sein" Infrastruktur

Vor Jahren, als ich damit begann, an Projekten zu arbeiten, die Milliarden von Benutzern dienten, sah ich, wie Infrastrukturentscheidungen, die in den Anfangstagen getroffen wurden, das Schicksal einer ganzen Branche umgestalten können.

Auch Plattformen, die mit den besten Absichten gestartet wurden, um offen, neutral und frei von Kontrolle zu sein, können in Formen der Zentralisierung abrutschen.

Es liegt nicht daran, dass jemand darauf aus ist, “böse” zu sein; es ist einfach die natürliche Anziehungskraft von Technologie und Märkten, wenn bestimmte Designentscheidungen von Anfang an festgelegt sind.

Infrastrukturdesignentscheidungen sind von Anfang an wichtig.

Diese Kern-Designentscheidungen müssen sicherstellen, dass die Technologie selbst Fairness durchsetzt und verhindert, dass Macht sich zunächst consildiert.

Wir haben diesen Film schon einmal gesehen

„Die Macht neigt dazu, sich zu konzentrieren, auch wenn niemand es plant“

Es ist eine subtile, aber tiefgreifende Wahrheit, die ich aus erster Hand gelernt habe, während ich an großen Internetprodukten gearbeitet habe.

Als die ‘dezentralisierte Industrie’ geboren wurde, schien es wie eine zweite Chance. Wir betrachteten Bitcoin, Ethereum und andere als Möglichkeiten, alte Machtstrukturen zu entkommen.

Die Erzählung war einfach: Kontrolle zurückgewinnen, Zwischenhändler ausschalten und den Code für Fairness sorgen lassen.

Aber wir müssen ehrlich sein, im Laufe der Zeit begannen dieselben Drucke, die das Internet zentralisierten, auch auf diese ‘dezentralisierten’ Systeme zu wirken.

Aber wie wurde das Internet zentralisiert?

Wurde das Internet nicht als dezentrales P2P-Netzwerk gestartet, das sogar einem Atomkrieg standhalten könnte?

Um zu verstehen, warum diese dezentralisierten Systeme den zentralisierenden Druck nachgeben, müssen Sie verstehen, was mit dem Internet passiert ist.

Sie müssen sich ansehen, wie es sich von seinen idealistischen Anfängen in ein stark zentralisiertes Ökosystem entwickelt hat.

Das frühe Internet: Als Peer-to-Peer die Norm war

“Am Anfang hatte niemand alle Schlüssel, und kein einzelner Spieler hat alle Entscheidungen getroffen”

Die früheste Version dessen, was wir heute als Internet bezeichnen, begann im Wesentlichen unter dem US-Verteidigungsministerium, mit Dingen wie ARPANET Ende der 60er Jahre.

Quelle: @DailySwig

Die gesamte Idee von Anfang an bestand darin, diesen einzigen Fehlerpunkt zu vermeiden und sicherzustellen, dass kein einziger Ausfallpunkt alles andere mit sich reißen konnte.

Dieses Netzwerk wurde bewusst so konzipiert, dass es dezentralisiert ist.

Die Begründung war strategisch: Ein verteiltes System könnte das Versagen eines einzelnen Knotens überstehen und die Kommunikation inmitten von Störungen wie Geräteausfällen oder sogar Kriegsbedingungen widerstandsfähiger machen.

Ein zuverlässiges und dezentrales Kommunikationsnetzwerk, das sogar einem Atomangriff standhalten könnte.

Jeder Knoten war ein “Peer”, der in der Lage war, Daten zu senden und zu empfangen, ohne sich auf eine einzige zentrale Autorität zu verlassen. Jede Maschine, unabhängig von Hardware oder Betriebssystem, konnte “TCP/IP sprechen” und Daten austauschen.

In den 70er und 80er Jahren waren Universitäten und Forschungslabore über NSFNET und ARPANET verbunden, und plötzlich hatten Sie diese Umgebung, in der niemand alle Schlüssel hatte und kein Einzelner alle Entscheidungen traf.

Es zeigte sich in den Grundlagen:

TCP/IP, FTP, Telnet, Usenet Newsgroups und DNS ging es nicht darum, jemanden an einen bestimmten Ort zu binden. Es gab wenig Anreiz, strenge Kontrollen oder Hierarchien aufzuerlegen.

Usenet zum Beispiel verbreitet Nachrichten auf vollständig dezentralisierte Peer-to-Peer-Weise. DNS delegierte Namensautorität in einer verteilten Hierarchie, aber jeder Bestandteil fungierte dennoch in gewisser Weise sowohl als Client als auch als Server.

Es hat alles dieses ursprüngliche Prinzip verstärkt:

Ein Netzwerk, das nicht nur von einem großen Akteur bestimmt wird, der die Regeln festlegt, sondern vielmehr ein System, in dem jeder einsteigen und teilnehmen kann.

Aber in den frühen 90er Jahren änderten das World Wide Web und Browser das ganze Spiel.

Die nachgebildete Seite der ersten Website (Bild: CERN)

Der Aufstieg des Client/Server-Modells

Tim Berners-Lee: Der Visionär hinter dem World Wide Web

„Mit dem Anstieg der Nutzerbasis des Internets zeigten sich Risse in den ursprünglichen Annahmen des Designs über offene Teilnahme und gegenseitiges Vertrauen.“

Das World Wide Web, das von 1989 bis 1991 eingeführt wurde, wurde auf offenen Standards (HTTP, HTML) aufgebaut und absichtlich in die öffentliche Domäne gestellt. In seiner frühesten Form war es einfach für Einzelpersonen, kleine Organisationen oder jeden mit einem Modem und Hosting, eine Website zu erstellen.

Die Infrastruktur war weitgehend „flach“ und dezentralisiert, mit unzähligen unabhängigen Webseiten, die in einer lockeren Föderation miteinander verbunden sind.

Aber in den frühen 90er Jahren wurde etwas wirklich populär.

Dies geschah, als ‘Web-Browsing’ zur ‘Killer-App’ wurde.

Websites wurden zu Schaufenstern, Nachrichtenportalen und Unterhaltungszentren. Der Durchschnittsbürger betrieb keinen eigenen Server oder hostete seine eigenen Seiten.

Die Startseite von Netscape im Jahr 1994 mit ihrem Maskottchen Mozilla, wie es in NCSA Mosaic 3.0 zu sehen ist.

[Screenshot: Alex Pasternack /OldWeb.heute]

Sie verwendeten Webbrowser (Clients), zuerst mit diesen langsamen Modems, dann mit Breitband, um Inhalte von großen, bekannten Webservern abzurufen. Plötzlich wurden das Hosting großer Datenmengen und die Einrichtung von E-Commerce-Websites oder Suchmaschinen zu einer großen Sache.

Frühe Suchmaschinen wie AltaVista, Yahoo! und später Google entstanden, um den Menschen zu helfen, sich in der sich schnell ausbreitenden Online-Welt zurechtzufinden.

Der Netzwerkeffekt wurde deutlich: Je mehr Menschen eine Suchmaschine nutzten, desto besser konnte sie ihre Indexierung und Werbemodelle verfeinern und ihre Dominanz verstärken.

Googles PageRank-Algorithmus machte es zu einem einzigen Gateway zur Weite des Webs.

Das trieb Geld und Aufmerksamkeit in große Rechenzentren, und diejenigen, die in der Lage waren, sich zu vergrößern und diese massiven Lasten zu bewältigen, kamen an die Spitze.

Mit dem Aufkommen von Internetdienstanbietern, die Millionen neuer Benutzer bedienen, wurde die Infrastruktur natürlich auf eine optimale Bereitstellung nach unten hin optimiert.

Schnellere Download-Geschwindigkeiten als Upload-Geschwindigkeiten (asymmetrische Breitbandverbindungen wie ADSL oder Kabel) ergaben wirtschaftlich Sinn, weil die meisten Benutzer mehr verbrauchten als sie produzierten. Das Netzwerk „lernte“, dass die meisten Endpunkte nur Clients waren.

Und als die Nutzerbasis des Internets explodierte, begannen die Annahmen des ursprünglichen Designs über offene Teilnahme und gegenseitiges Vertrauen Risse zu zeigen.

Sicherheit, Firewalls und geschlossene Tore

“Freiheit und Offenheit ohne Schutzmaßnahmen können Missbrauch provozieren, der uns dazu zwingt, höhere Mauern zu bauen.”

Die ursprünglichen Protokolle waren nicht darauf ausgelegt, eine massive, vielfältige Menge zu bewältigen, viele davon mit geschäftlichen Interessen oder Motivationen, die die Offenheit des Systems testeten.

Ohne wirkliche Sicherheitsvorkehrungen wurde Spam zu einem großen Problem, das diese offene Umgebung ausnutzte.

Das ursprüngliche offene Design ermöglichte es, dass jeder Host von jedem anderen Host aus erreichbar war, was in Ordnung war, als das Internet eine kleine, vertrauenswürdige Gemeinschaft war.

Aber als es wuchs, nahmen Angriffe, Hacking-Versuche und bösartige Aktivitäten enorm zu.

Quelle:emailtray.com

Ebenso haben einige Anwendungen gelernt, die Grenzen zu überschreiten und sich auf Kosten anderer einen Vorteil zu verschaffen, ohne dass es eine Möglichkeit gibt, die Bandbreitennutzung fair zu halten.

Diese Designlücken haben das Internet in Richtung mehr Regulierung und Kontrolle gedrängt.

Um interne Netzwerke zu schützen, setzen Organisationen Firewalls ein, um eingehende Verbindungen zu blockieren. Die Network Address Translation (NAT) isoliert interne Maschinen zusätzlich hinter einer einzigen gemeinsam genutzten IP-Adresse.

Dies hat die peer-to-peer Natur der Kommunikation eingeschränkt.

Hosts hinter NATs und Firewalls wurden effektiv in eine reine Clientrolle gedrängt und waren nicht mehr direkt aus der Außenwelt adressierbar.

Im Laufe der Zeit haben diese Infrastrukturentscheidungen sich gegenseitig verstärkt.

Das Aufkommen der gatekeepers

„Eine Handvoll Unternehmen erkannte, dass die Kontrolle über Rechenzentren und der Besitz von massiven Serverinfrastrukturen ihnen enorme Wettbewerbsvorteile verschaffte.“

Die Komplexität und die Kosten für den Betrieb eines eigenen Servers zu Hause, gepaart mit technischen Barrieren wie NAT und Firewalls, führten dazu, dass weniger Personen als echte Peers teilnahmen.

Mit anderen Worten, die Umgebung hat das Netzwerk praktisch in Richtung einer Handvoll zentralisierter Giganten gedrängt.

Bis Anfang der 2000er Jahre erkannte eine Handvoll Unternehmen, dass die Kontrolle über Rechenzentren und der Besitz massiver Serverinfrastrukturen ihnen enorme Wettbewerbsvorteile verschaffte.

Sie könnten schnellere, zuverlässigere und bequemere Dienste als ein zufälliger Peer im Netzwerk bereitstellen.

Dieser Trend war in den späten 2000er Jahren auf Steroiden.

Quelle:datareportal.com

Suchmaschinen wie Google, große Plattformen wie Amazon, Social-Media-Riesen wie Facebook und Content-Distribution-Netzwerke haben riesige Infrastrukturen aufgebaut, die Inhalte und Anwendungen in beispielloser Geschwindigkeit und Größe bereitgestellt haben.

Diese großen Unternehmen haben auch in den „Teufelskreis“ von Daten und Algorithmen eingegriffen.

Je mehr Benutzer sie anziehen, desto mehr Daten sammeln sie, was es ihnen ermöglicht, ihre Produkte zu optimieren, Erlebnisse zu personalisieren und Werbung genauer zu zielen. Dadurch werden ihre Dienste noch attraktiver und ziehen mehr Benutzer und mehr Umsatz an.

Dann verlagerte sich das Umsatzmodell des Internets stark hin zur zielgerichteten Werbung.

Im Laufe der Zeit verstärkte sich diese Rückkopplungsschleife, da kleinere Wettbewerber Schwierigkeiten hatten, mit den Investitionen in die Infrastruktur und den Daten-Vorteilen der großen Spieler Schritt zu halten.

Infrastruktur, die früher von einem persönlichen Server oder einem lokalen Rechenzentrum ausgeführt werden konnte, wird zunehmend in die Cloud verlagert.

Riesen wie Amazon (AWS), Microsoft (Azure) und Google Cloud hosten jetzt das Rückgrat eines Großteils des Internets. Dieser Wandel erfolgte, weil der Betrieb einer umfangreichen, sicheren und zuverlässigen Infrastruktur so komplex und kapitalintensiv wurde, dass nur wenige Unternehmen dies effizient tun konnten.

Startups und sogar etablierte Unternehmen fanden es billiger und einfacher, sich auf diese großen Cloud-Anbieter zu verlassen.

Dienste wie CDNs (wie Cloudflare oder Akamai) und DNS-Resolver zogen es ebenfalls zu einigen wenigen großen Playern hingezogen.

Die Komplexität und die Kostenvorteile dieser verwalteten Lösungen bedeuteten weniger Gründe für Unternehmen, ihre eigene Infrastruktur zu entwickeln.

Nach und nach wich das dezentrale Fundament wie kleine ISPs, unabhängiges Hosting und lokale Routing einem Modell, bei dem der Großteil des Datenverkehrs und der Dienste von einer kleinen Anzahl großer Vermittler abhängt.

Die Folgen: Macht konzentriert in wenigen Händen

„Die großen Spieler haben nicht böse angefangen; sie haben sich einfach auf Bequemlichkeit, Leistung und Gewinn optimiert.“

Es war das natürliche Ergebnis früher architektonischer Gestaltungsentscheidungen im zugrunde liegenden Netzwerk.

Mit Skalierung und Zentralisierung kam mehr Macht und Kontrolle.

Große Plattformen legen ihre eigenen Nutzungsbedingungen fest und bestimmen, welche Inhalte Benutzer sehen oder posten können und wie ihre Daten gesammelt oder verkauft werden. Benutzer hatten weniger Alternativen, wenn ihnen diese Richtlinien nicht gefielen.

Im Laufe der Zeit wurden die Empfehlungsalgorithmen und Inhaltsrichtlinien dieser Plattformen zu de facto Schiedsrichtern des öffentlichen Diskurses.

Paradoxerweise wird das, was als offenes, dezentrales Netzwerk begann, das den freien Austausch von Ideen und Inhalten ermöglichte, jetzt oft Informationen durch wenige Unternehmensgateways leitete.

Nun haben diese Unternehmen in gewisser Hinsicht eine Macht, die mit der von Regierungen vergleichbar ist: Sie können die öffentliche Diskussion prägen, den Handel beeinflussen und ganze Ökosysteme von Drittanbieter-Entwicklern kontrollieren.

Ein Netzwerk, das ursprünglich für eine freie, peer-level Verbindung konzipiert wurde, kreist nun um leistungsstarke Unternehmenszentren, die einen großen Teil des Online-Erlebnisses formen und kontrollieren können.

Dies war keine große Verschwörung, um Macht zu konzentrieren. Noch stammt diese Situation von einer einzigen “falschen Abzweigung” ab.

Die großen Spieler haben nicht böse angefangen; sie haben sich nur auf Bequemlichkeit, Leistung und Profit optimiert. Es war das natürliche Ergebnis früher architektonischer Designentscheidungen im zugrunde liegenden Netzwerk.

Diese Entscheidungen haben nicht antizipiert, wie ein viel breiteres und kommerziell orientiertes Publikum das System nutzen würde und es über seine ursprünglichen Designparameter hinaus treibt.

Im Laufe der Zeit haben sich diese Entscheidungen zu einem System entwickelt, in dem eine Handvoll Unternehmen dominieren.

Das Gleiche passiert vor unseren Augen in der dezentralen Industrie.

Der Weg zur Zentralisierung ist mit „vorübergehenden“ Lösungen gepflastert

“Die Neigung zur Zentralisierung ist nicht immer das Ergebnis von böswilliger Absicht; oft ist es ein Versuch, Probleme eines Systems zu lösen, das nie darauf ausgelegt war, in großem Maßstab dezentralisiert zu bleiben.”

Genau wie das frühe Internet von seinen Peer-to-Peer-Idealen abrückte und in die Hände weniger großer Player geriet, riskieren die heutigen Blockchain- und „dezentralen“ Technologien, denselben Weg einzuschlagen.

Am einfachsten lässt sich dies an Ethereums Versuchen zur Skalierung erkennen.

Hohe Gebühren und geringe Durchsatzraten zwangen Entwickler dazu, Layer-2 (L2)-Lösungen zu übernehmen: Rollups, die Transaktionen außerhalb der Kette bündeln und sie dann auf Ethereum abwickeln. In der Theorie sollten diese L2s die vertrauenswürdige Natur von Ethereum beibehalten.

In der Praxis hängen viele von einem einzigen “Sequenzer” ab (ein zentraler Server, der Transaktionen anordnet), der von einem Unternehmen betrieben wird.

Derzeit hat eine bestimmte L2-Lösung die meisten Aktivitäten und den höchsten Gesamtwert gesperrt, ist jedoch auch die zentralisierteste.

Das Argument ist, dass die Dezentralisierung irgendwann kommen wird, aber das haben wir schon einmal gehört.

Im Laufe der Zeit haben diese „temporären“ Lösungen die Tendenz, dauerhaft zu werden. Das gleiche Muster könnte sich bei zukünftigen Schichtansätzen abzeichnen; einige könnten sich nicht einmal die Mühe machen, einen Weg zur Dezentralisierung zu versprechen.

„Soziale Anmeldungen“ mögen hilfreich erscheinen: Sie erleichtern es den Menschen, einen Dienst zu nutzen, ohne private Schlüssel oder komplizierte Benutzeroberflächen jonglieren zu müssen. Aber wenn diese Anmeldungen von einem zentralen Bestandteil abhängen, vertrauen Sie wiederum einem Unternehmen, das das Richtige tut.

Das ist der Grund, warum wir bei der Entwicklung von zkLogin darauf geachtet haben, es vertrauenswürdig zu gestalten und zu integrieren. Es war schwierig, aber wir können keine Kompromisse eingehen und Zentralisierung aus Bequemlichkeit einführen.

Ein ähnliches Muster zeigte sich im NFT-Ökosystem.

Ein dominanter Einzelhandelsmarkt wurde zum Hauptumschlagsplatz für Sekundärverkäufe, erfasste den größten Teil des Handelsvolumens und wurde effektiv zur de facto Plattform.

Vor nicht allzu langer Zeit beschloss dieser Marktplatz, die Durchsetzung von Lizenzgebühren für Sekundärverkäufe einzustellen.

Ja, es erhöhte den Handelsvolumen, aber es betrügt die Schöpfer, die sich auf diese Lizenzgebühren als eine wichtige Einnahmequelle verließen.

Dies ist ein klares Beispiel für die Konsequenzen, wenn zentralisierte Plattformen die Regeln jederzeit ändern können.

Ihre Dominanz erstreckte sich auch über den Handel hinaus, da sich viele Projekte auch auf ihre APIs und Infrastruktur verließen.

Als diese zentralisierte Plattform Ausfälle hatte, spürte das gesamte Ökosystem die Auswirkungen und offenbarte die tiefe Abhängigkeit, die sich gebildet hatte.

Aber warum passiert das immer wieder?

Weil Benutzer schnelle, günstige und einfache Erlebnisse wollen. Entwickler greifen unter Druck oft zu vertrauten und zuverlässigen Lösungen. Diese Entscheidungen sind einfacher und schneller, können aber Kontrollpunkte einführen, die die Dezentralisierung untergraben.

Keiner dieser Schritte beginnt als großartige Pläne zur Monopolisierung. Es sind einfach praktische Reaktionen auf schwierige technische und marktbezogene Herausforderungen.

Aber im Laufe der Zeit werden diese “Pflaster” in das DNA des Systems eingebettet, was eine Struktur schafft, in der einige Akteure die Schlüssel halten.

Deshalb müssen diese Systeme von Grund auf für Entwickler konzipiert werden, nicht nur für Verbraucher.

Bauen für Erbauer, nicht nur Verbraucher

„Wenn ich die Leute gefragt hätte, was sie wollten, hätten sie schnellere Pferde gesagt.“ - Henry Ford

Die meisten Verbraucher wollen einfach eine bessere Version von dem, was sie bereits haben.

Aber wenn wir nur diese kurzfristigen Verbesserungen verfolgen, riskieren wir, Systeme zu haben, die auf der Oberfläche dezentralisiert aussehen, aber immer noch ein paar Schlüsselspieler haben, die die Fäden ziehen.

Wenn wir wirklich vermeiden wollen, die Fehler zu wiederholen, die zu den heutigen digitalen Gatekeepern geführt haben, müssen wir uns auf die Schöpfer der Zukunft, die Erbauer, nicht nur auf die Verbraucher konzentrieren.

Das ist der Grund, warum ich meinem Team immer sage, dass Verbraucher immer nach einem schnelleren Pferd fragen werden; es sind die Ingenieure, die sich das Auto vorstellen.

0:00 / 0:38

Mit den richtigen Bausteinen können Entwickler Plattformen starten, die nicht aus Bequemlichkeit zur Zentralisierung gezwungen sind. Sie können Systeme erstellen, in denen keine einzelne Entität dominieren oder Benutzer einschränken kann, um sicherzustellen, dass die Vorteile gleichmäßiger auf alle Teilnehmer verteilt werden.

Deshalb müssen diese Systeme von Grund auf so konzipiert sein, dass sie Dezentralisierung unterstützen, auch wenn sie auf Internet-Ebene skalieren müssen.

Tech Debt vs Design Debt

“Technische Schulden können durch Refactoring behoben werden; Design-Schulden erfordern oft einen vollständigen Neustart.”

Aus meinen frühen Jahren, in denen ich an Systemen gearbeitet habe, die sich auf Milliarden von Benutzern skaliert haben, hat mich eine Lektion geprägt: Sobald ein System missionkritisch wird, können Sie es nicht einfach komplett abreißen und neu aufbauen, ohne massive Störungen zu verursachen.

Wenn Millionen von Benutzern auf die etablierten Verhaltens- und Annahmemuster Ihres Systems angewiesen sind, wird selbst die Vorschläge radikaler architektonischer Veränderungen zu einem Non-Starter.

Es würde Anwendungen, Geschäftsmodelle und das Vertrauen ganzer Gemeinschaften, die darauf aufgebaut sind, zerstören.

Dies ist das Konzept der „Designschulden“ in ihrer schwersten Form.

Es geht hier nicht nur um die Sauberkeit des Codes; es geht um grundlegende architektonische Entscheidungen, die bestimmen, wie Vertrauen, Macht und Wert durch das Netzwerk fließen.

In den Anfangstagen dieser Branche wurde das sogenannte „Blockchain- oder Skalierbarkeitsdilemma“, die Idee, dass man nicht gleichzeitig Dezentralisierung, Sicherheit und Skalierbarkeit haben kann, wie ein Naturgesetz behandelt.

Die Menschen haben auf dieser Annahme aufgebaut und geglaubt, dass sie so unveränderlich sei wie die Schwerkraft. Aber das war sie nicht.

Es stammte aus fehlerhaften anfänglichen Architekturen: massiven globalen gemeinsamen Zuständen, die parallele Verarbeitung und modulares Skalieren unmöglich machten.

Der einzige Weg nach vorne besteht darin, alle Transaktionen zusammenzufassen und jeden Teilnehmer dazu zu zwingen, um die gleichen begrenzten Ressourcen zu kämpfen, unabhängig davon, was sie tun. Das Ergebnis? Ineffiziente Auktionen für Blockplatz, die die Kosten während Spitzenzeiten der Nachfrage in die Höhe treiben und es versäumen, Engpässe dort zu isolieren, wo sie tatsächlich auftreten.

Unter diesen Bedingungen werden durch das Hinzufügen von Schichten (wie L2s, die auf zentralisierten Sequenzern oder komprimierten Assets, die von zentralisiertem Speicher abhängen, beruhen) nur die Risse überdeckt.

Jeder Patch, der darauf abzielt, kurzfristige Probleme zu beheben, fügt oft mehr Komplexität und mehr Punkte zentralisierter Kontrolle hinzu und entfernt sich weiter von der ursprünglichen Vision.

So entsteht Designschulden, die sich zu einer Form von “technischer Gravitation” ansammeln, die alles in Richtung Zentralisierung zieht.

Auch Systeme, die nie beabsichtigt waren, Torwächter zu sein, enden damit, hierarchische Strukturen zu verstärken, weil ihre grundlegende Architektur es verlangt. Sobald das passiert, wird der Weg zurück zu einem wirklich dezentralen, vertrauenslosen Zustand von etablierten Interessen und infrastruktureller Trägheit blockiert.

Die Lektion ist klar: Sie müssen von Anfang an die Architektur richtig machen.

Das bedeutet, Datenmodelle auszuwählen, die nicht alles in einen einzigen globalen Zustand packen, Speicherlösungen zu verwenden, die ohne Vertrauen in einen Vermittler überprüfbar sind, und eine Netzwerkschicht zu wählen, die nicht von einer Handvoll mächtiger Vermittler abhängt.

Es geht darum, den gesamten Technologie-Stack von Anfang an neu zu erfinden.

Die Grundlagen von Anfang an richtig machen

„Die einzige wirkliche Heilung für Designschulden besteht darin, sie erst gar nicht anzuhäufen.“

Wenn wir darüber sprechen, Infrastruktur aufzubauen, die nicht böse sein kann, sprechen wir wirklich darüber, von Anfang an die richtigen architektonischen Entscheidungen zu treffen.

Deshalb haben wir bei der Gestaltung von Sui darauf geachtet, diese grundlegenden Prinzipien von Anfang an zu integrieren.

Dies ermöglicht Entwicklern, skalierbare, sichere und benutzerfreundliche Anwendungen ohne großen Aufwand oder Abhängigkeit von zentralen Stützen zu erstellen.

Betrachten Sie das Programmiermodell selbst:

Suis objektorientierter Ansatz ist ein bewusster Abkehr von den konto-basierten Paradigmen, die viele Blockchains dominiert haben.

Objektorientiertes Programmiermodell

Im Mittelpunkt von Suis Designphilosophie steht das objektorientierte Programmiermodell.

In einer Welt, in der Web2-Entwickler natürlich in Begriffen von Objekten wie Dateien, Datensätzen und Vermögenswerten denken, macht es keinen Sinn, alles auf ein monolithisches Kontomodell zu reduzieren.

Dadurch zwingt es Entwickler in unnatürliche Denkmuster. Es führt zu Komplexität, die anfällig für Fehler ist.

Das objektorientierte Programmiermodell passt natürlich zur Art und Weise, wie Web2-Ingenieure bereits über Software nachdenken.

Objekte dienen als Bürger erster Klasse, was es einfach macht, Vermögenswerte darzustellen, Regeln zu definieren und gängige Fallstricke wie Reentrancy-Bugs zu vermeiden, ohne komplizierten Boilerplate-Code.

Dieses vertraute Modell reduziert die konzeptionelle Belastung und häufig auftretende Probleme wie Reentrancy drastisch. Anstatt Boilerplate-Checks oder komplexe Sicherheitsvorkehrungen zum Schutz vor Angriffen zu schreiben, verlassen sich Entwickler auf die Move VM, um Sicherheit auf der Laufzeitebene zu gewährleisten.

Infolgedessen ist der Code lesbarer, sicherer und einfacher zu verstehen.

Es handelt sich um eine direkte Brücke von der objektorientierten Denkweise von Web2 zur vertrauenslosen Umgebung von Web3, die durch den richtigen Ansatz von Anfang an ermöglicht wird.

Skalierung durch Design, nicht durch Klebeband

Aber ein großartiges Programmiermodell bedeutet nichts, wenn es unter Last zusammenbricht.

Von Anfang an wurde Sui entwickelt, um reale Belastungen zu bewältigen. Es wurde so konzipiert, dass es horizontal skalierbar ist und gleichzeitig synchrone atomare Komponierbarkeit aufrechterhält.

Das Objektmodell des Systems gibt Sui ein feinkörniges Verständnis dafür, welche Teile des Zustands von jeder Transaktion berührt werden, was parallele Ausführung im großen Maßstab ermöglicht. Dies steht im starken Kontrast zu EVM-basierten Systemen, die den gesamten globalen Zustand sperren müssen. Dies verlangsamt alles und fördert zentralisierte Lösungen, um das Transaktionsvolumen auszulagern.

Mit Sui ist jedes Objekt effektiv sein eigener Shard. Benötigen Sie mehr Kapazität? Fügen Sie mehr Rechenleistung hinzu, um die Last zu bewältigen.

Der Pilotfisch-Prototyp :https://blog.sui.io/pilotfish-execution-scalability-blockchain/

Entwickler müssen sich keine Sorgen um das Sharding-Logik, die Verbindung mehrerer Domänen oder das Zusammenhacken der Infrastruktur machen, um Skalierbarkeit zu erreichen.

So kann das System mehr Traffic verarbeiten, während das Netzwerk wächst, aber wie stellen Sie eine faire Ressourcenzuweisung sicher?

Wenn ein beliebtes Vermögenswert oder eine dApp den Markt für Statusaktualisierungen dominiert, kann dies die Kosten erhöhen und die Erfahrung für alle anderen beeinträchtigen.

Anstatt sich auf eine einzige globale Auktion für Blockraum zu verlassen, bei der eine beliebte Anwendung die Preise für alle erhöhen kann, ermöglichen lokale Gebührenmärkte, dass das System Ressourcen auf einer feineren Granularitätsebene bewertet.

Jedes „Objekt“ oder Scherbe kann seinen eigenen Gebührenmarkt haben, um sicherzustellen, dass Staus in einem Bereich nicht überlaufen und keine Auswirkungen auf nicht verwandte Teile des Netzwerks haben.

Es ist alles in das grundlegende Design der Plattform eingebettet, um sicherzustellen, dass selbst bei wachsender Nachfrage das System nicht zu den müden alten Mustern von gatekeepers und abgeschotteten Gärten zurückfällt.

Bei der Gestaltung für Dezentralisierung bedeutet dies auch, die Überprüfbarkeit direkt in Speicher- und Kommunikationsschichten zu integrieren.

Wenn die Datenspeicherung auf einer einzigen vertrauenswürdigen Partei beruht, sind Sie wieder am Anfang. Sie benötigen Speicherlösungen, die es jedem ermöglichen, die Integrität der Daten zu überprüfen, ohne von einem Mittelsmann abhängig zu sein.

Verifizierbarer Speicher ohne zentrale Hosts

Eine wirklich dezentralisierte Anwendung kann sich nicht auf einen einzelnen Cloud-Anbieter oder eine zentralisierte Datenbank verlassen.

Walrus bietet eine dezentralisierte, überprüfbare Speicherebene, die in Bezug auf Leistung und Skalierbarkeit mit zentralisierten Angeboten wie AWS oder Google Cloud vergleichbar ist.

Mit Walrus ist die Überprüfbarkeit von Daten keine nachträgliche Überlegung, sondern eine intrinsische Eigenschaft.

Durch die Integration einer Speicherschicht, die von Natur aus überprüfbar und manipulationssicher ist, stellt Walrus sicher, dass Entwickler Websites betreiben, Daten hosten und vollständig dezentralisierte Anwendungen erstellen können, ohne in die zentralisierten Muster zurückzufallen, die wir zu vermeiden versucht haben.

Mit anderen Worten, Walrus erweitert die “korrekt durch Konstruktion” Philosophie von der Ausführung bis zur Speicherung und gewährleistet die Integrität Ihrer Anwendung auf jeder Ebene.

Jetzt bedeutet das Entwerfen für Dezentralisierung auch, dass es nicht bei der Konsens- oder Ausführungsebene enden sollte; es sollte sich in das Netzwerk selbst erstrecken.

Netzwerkschichten sollten nicht von einer Handvoll mächtiger ISPs oder Routing-Dienste abhängen. Das ist auch Zentralisierung.

Eine für Dezentralisierung aufgebaute Netzwerkschicht

Networking ist ein weiteres oft übersehenes Puzzlestück in Web3.

Die herkömmliche Internet-Routing wird von einigen wenigen ISPs kontrolliert, was potenzielle Engpässe und Schwachstellen mit sich bringt.

SCION ist ein Netzwerkprotokoll der nächsten Generation, das diesen Status quo in Frage stellt und das Routing sicherer, zuverlässiger und resistenter gegen zentrale Kontrolle macht.

Es ist eine sichere, Multi-Path-, Inter-Domain-Routing-Architektur, die parallel zum heutigen Internet betrieben werden kann. Es ist eine vollständige Neugestaltung, wie Daten über Netzwerke hinweg bewegt werden, die mit Sicherheit, Kontrolle und Leistung direkt in ihrem Kern integriert ist.

Durch die Integration von SCION in Sui stellen wir sicher, dass das zugrunde liegende Netzwerk kein einzelner Fehler- oder Kontrollpunkt ist.

Keine einzelne Entität bestimmt den Datenfluss, und die Benutzer können darauf vertrauen, dass die zugrunde liegenden Routen nicht manipuliert oder monopolisiert werden.

Durch die Integration von Nachweisbarkeit und Freiheit in jede Ebene, einschließlich des Datenmodells, der Speicherung und der Vernetzung, wird die Angriffsfläche reduziert, auf der zentrale Kontrollpunkte entstehen können.

Sie fügen Dezentralisierung nicht als nachträgliche Überlegung hinzu; Sie binden sie in die Grundlage ein.

Diese Einfachheit reduziert Komplexität und hält die Tür für „bequeme“, aber zentralisierende Workarounds geschlossen. Am wichtigsten ist, dass das richtige Verständnis der Grundlagen bedeutet, niemals auf eine „wir werden es später reparieren“-Mentalität zu setzen.

Alle Wege führen zurück zum Sound Design

„Dezentralisierung ist nicht eine Validator-Zählung. Wahre Dezentralisierung handelt von der Architektur, die verhindert, dass sich die Macht an einem Ort ansammelt.“

Der Punkt von allem, was wir erkundet haben, ist einfach: Wenn Sie ein System wollen, das nicht böse sein kann, müssen Sie mit der richtigen Architektur beginnen.

Wenn Sie mit falschen Annahmen beginnen, wird Ihnen kein zusätzlicher Code oder clevere Tricks helfen.

Eine Architektur, die Gatekeeper belohnt. Ein Datenmodell, das jeden Akteur zwingt, um die gleiche knappe Ressource zu konkurrieren. Eine Netzwerkschicht, die um zentralisierte Hubs herum konzipiert ist. Schließlich werden Sie in die gleichen alten Kontroll- und Hierarchiemuster fallen.

Das ist der Grund, warum die architektonische Grundlage so wichtig ist.

Dezentralisierung bedeutet nicht nur, wie viele Knotenpunkte Sie haben, zu zählen. Wahre Dezentralisierung bedeutet, auf der Grundebene so zu gestalten, dass Vertrauen, Fairness und Überprüfbarkeit unmöglich umgangen werden können.

Es geht darum, Systeme aufzubauen, bei denen weder eine Handvoll Wale noch ein gut ausgestattetes Unternehmen das Spielfeld leise kippen können. Es geht darum sicherzustellen, dass jeder Teilnehmer eine faire Chance hat und dass kein Engpass, keine subtile Designentscheidung zu einer unkontrollierten Zentralisierung führen kann.

Sui ist ein Beispiel dafür, was passiert, wenn Sie von Anfang an mit diesen Prinzipien im Sinn entwerfen, anstatt zu versuchen, sie nachträglich anzupassen.

Wenn der gesamte Stack, vom Programmiermodell bis zur Konsensschicht, und von der Benutzeranbindung über die Datenverfügbarkeit und Netzwerkschicht, Offenheit und Neutralität stärkt, schaffen Sie eine Umgebung, in der Entwickler und Benutzer unter gleichen Bedingungen gedeihen.

Indem Sie von Grundprinzipien ausgehen und Dezentralisierung auf jeder Ebene durchsetzen, können Sie eine Infrastruktur schaffen, die ihrer Ethik treu bleibt, egal wie groß sie wird.

Wenn Sie es von Anfang an richtig aufbauen, müssen Sie keine zukünftigen Fixes oder halbe Maßnahmen versprechen.

Sie werden ein Netzwerk haben, das von Natur aus gerecht, widerstandsfähig und bereit ist, als Grundlage für die nächste Generation digitaler Erlebnisse zu dienen.

Haftungsausschluss:

1. Dieser Artikel wurde aus [ wiedergegebenX]. Alle Urheberrechte gehören dem Originalautor [ @EvanWeb3]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an die Gate LearnTeam und sie werden es schnell bearbeiten.
2. Haftungsausschluss: Die Ansichten und Meinungen, die in diesem Artikel zum Ausdruck gebracht werden, sind allein die des Autors und stellen keine Anlageberatung dar.
3. Das Gate Learn Team übersetzt den Artikel in andere Sprachen. Sofern nicht anders angegeben, ist das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel untersagt.