Ich lese andere Fragen/Antworten wie Warum laden Ethereum-Clients die gesamte Blockchain herunter? , aber niemand geht auf die Frage ein, warum die Brieftasche nicht einfach eine webbasierte API verwenden kann, um die Blockchain bei Bedarf zu lesen/aktualisieren, anstatt die gesamte riesige Blockchain herunterzuladen und zu synchronisieren.
Jahrelang habe ich mit der alten Client/Server-Mentalität gearbeitet, dass der Client einfach mit einem Server kommuniziert, auf dem sich die Daten befinden; Obwohl es sich um ein Peer-to-Peer-Netzwerk handelt, warum funktioniert dieses Modell hier nicht? Könnte es sich nicht zufällig mit einem Knoten eines Miners verbinden?
Es sieht so aus, als würden sogar die Light-Clients auch einen bestimmten Teil der Blockchain herunterladen?
Werden dann per Definition alle Wallets als „Kunden“ betrachtet?
(Ich habe Parity auf meinem C-Laufwerk installiert und es füllte das Laufwerk. Scheint, als sollten sie Sie zumindest vor dem für die Installation erforderlichen Speicherplatz warnen, dann hätte ich ein anderes Laufwerk gewählt.)
Wie bereits von anderen erwähnt, besteht das Problem bei APIs darin, dass es sich um zentralisierte Informationsquellen handelt. Dadurch wird im Grunde das wichtigste Wertversprechen der Blockchain eliminiert. Dies ist wohl problematischer als ein vollständig zentralisierter Dienst. Die meisten vollständig zentralisierten Dienste verfügen über Methoden, um böswillige Zustandsänderungen rückgängig zu machen, wenn sie entdeckt werden (z. B. wenn jemand Ihr Bankkonto hackt, haftet die Bank selbst und muss das verlorene Geld zurückerstatten). Die Leute von Infura haben freudig erklärt, dass sie ihren Service nicht als langfristige Lösung sehen. Es soll eine Besser-als-Nichts-Maßnahme sein, um dazu beizutragen, die Eintrittsbarriere in den Blockchain-Raum zu verringern.
Light-Clients sollen die Größenprobleme lösen und gleichzeitig die Sicherheit der Blockchain aufrechterhalten, und werden letztendlich die meisten Desktop-Blockchain-Anwendungen (z. B. den Mist-Browser) unterstützen. Obwohl sie nach den Standards einer klassischen Client-Server-Interaktion möglicherweise nicht „leicht“ sind, sind sie wesentlich leichter als das Ausführen eines echten Knotens. Sobald wir Light-Clients stabilisiert und gut getestet haben, werden sie viel vernünftigere Anwendungsgrößen ermöglichen.
In Bezug auf Nicht-Client-Lösungen habe ich kürzlich ein Whitepaper mitverfasst, in dem eine Lösung vorgeschlagen wird. Ich bin vielleicht voreingenommen, aber ich denke, es ist ziemlich ordentlich :) Es ermöglicht stark erhöhte Sicherheitsgarantien und Dezentralisierung, aber mit einem Overhead, der mit einer zentralisierten API vergleichbar ist. Ich werde ein tl; dr und einen Link unten hinzufügen, falls jemand mehr wissen möchte.
TL;DR: Verwenden Sie ein Proof-of-Stake -System, um vertrauenswürdige Kanäle zu erstellen, die es Gruppen von Personen mit Knoten ermöglichen, dafür belohnt zu werden, als API-Endpunkte zu fungieren, und für böswillige Aktivitäten bestraft werden. Wir zeigen, dass wir das System so konstruieren können, dass:
Benutzer können ihre Verluste aus dem Einsatz von böswilligen Parteien wieder hereinholen.
Die Belohnung, die Wahrheit zu sagen, ist immer größer als die Belohnung, zu lügen.
Die dezentrale Infrastruktur skaliert proportional zur Nachfrage (dank des bergbauähnlichen Belohnungssystems).
Leicht genug, um in regulärem Website-JavaScript zu funktionieren, genau wie eine zentralisierte API.
Keine Seitenkette (yay!).
Sie könnten, aber es ist ein Sicherheitsproblem. Wenn sich alle auf dieselben APIs (wie infura) verlassen, ist das gesamte Netzwerk tatsächlich zentralisiert. Um eine echte Dezentralisierung zu erreichen, muss jeder eine Kopie der gesamten Kette haben. Die Spieltheorie spielt ein wenig mit, und es ist wahrscheinlich, dass je größer die Kette wird, desto mehr Leute werden dies tun; aber kein anständiger Brieftaschenhersteller würde seine Brieftasche im Moment als sicher bezeichnen, wenn er eine API verwendet.
NealWalters
fspmarshall