Die erste Version des leichten Ethereum -Subprotokolls (LES/1) und seine Implementierung in Geth sind noch in ein Versuchsstadium, aber es wird erwartet, dass sie ein mehr erreichen reifen Staat in wenigen Monaten, in denen die Grundfunktionen zuverlässig funktionieren. Der leichte Client wurde so konzipiert, dass er mehr oder weniger gleich funktioniert wie ein Vollkunden, aber die „Leichtigkeit“ hat einige inhärente Einschränkungen, die Dapp -Entwickler entwickeln sollen verstehen und Überlegen Sie, ob sie ihre Anwendungen entwerfen.
In den meisten Fällen kann eine ordnungsgemäß gestaltete Anwendung auch funktionieren, ohne zu wissen, mit welcher Art von Client sie verbunden ist. Wir suchen jedoch nach Hinzufügen einer API -Erweiterung zur Kommunikation verschiedener Kundenfunktionen, um eine zukünftige Beweisschnittstelle bereitzustellen. Während kleinere Details von LES immer noch ausgearbeitet werden, ist es meiner Meinung nach Zeit, die wichtigsten Unterschiede zwischen vollständigen und leichten Kunden aus der Sicht des Anwendungsentwicklers zu klären.
Aktuelle Einschränkungen
Ausstehende Transaktionen
Leichte Clients erhalten keine anhängigen Transaktionen vom Hauptnetzwerk von Ethereum. Die einzigen anstehenden Transaktionen, von denen ein leichter Kunde weiß, sind diejenigen, die von diesem Kunden erstellt und gesendet wurden. Wenn ein leichter Client eine Transaktion sendet, lädt er ganze Blöcke herunter, bis er die gesendete Transaktion in einem der Blöcke findet, und entfernt sie dann aus dem ausstehenden Transaktionssatz.
Eine Transaktion durch Hash finden
Derzeit finden Sie nur lokal erstellte Transaktionen nach Hash. Diese Transaktionen und ihre Einschlussblöcke werden in der Datenbank gespeichert und können später von Hash gefunden werden. Es ist etwas schwieriger, andere Transaktionen zu finden. Es ist möglich (wenn auch noch nicht implementiert), sie von einem Server herunterzuladen und zu überprüfen, ob die Transaktion tatsächlich im Block enthalten ist, wenn der Server ihn gefunden hat. Wenn der Server sagt, dass die Transaktion nicht vorhanden ist, ist es für den Client leider nicht möglich, die Gültigkeit dieser Antwort zu überprüfen. Es ist möglich, mehrere Server zu fragen, falls der erste nichts davon wusste, aber der Kunde kann sich nie absolut sicher sein, dass eine bestimmte Transaktion nicht existiert. Für die meisten Anwendungen ist dies möglicherweise kein Problem, aber es ist etwas, das man beachten sollte, wenn etwas Wichtiges von der Existenz einer Transaktion abhängt. Ein koordinierter Angriff, um einen leichten Kunden zu täuschen, zu glauben, dass keine Transaktion mit einem bestimmten Hash existiert, wäre wahrscheinlich schwierig auszuführen, aber nicht völlig unmöglich.
Leistungsüberlegungen
Latenz anfordern
Das einzige, was ein leichter Client in seiner Datenbank immer hat, sind die letzten Tausend Block -Header. Dies bedeutet, dass das Abrufen von anderen anderen erfordert, dass der Client Anfragen sendet und Antworten von Lichtservern erhält. Der leichte Client versucht die Anfrage zu optimieren Verteilung und sammelt statistische Daten der üblichen Antwortzeiten jedes Servers, um die Latenz zu verringern. Latenz ist der wichtigste Parameter der Leistung eines leichten Clients. Es befindet sich in der Regel in der Größenordnung von 100 bis 200 ms und gilt für jeden Abruf von Les-, Block- und Quittungsset für die Les-, Block- und Quittung. Wenn viele Anfragen nacheinander gestellt werden, um einen Vorgang auszuführen, kann dies zu einer langsamen Reaktionszeit für den Benutzer führen. Das parallele Ausführen von API -Funktionen, wann immer möglich, kann die Leistung erheblich verbessern.
Suche nach Ereignissen in einer langen Geschichte von Blöcken
Vollständige Kunden verwenden einen sogenannten “MIP-kartierten” Bloom-Filter, um Ereignisse in einer langen Liste von Blöcken schnell zu finden, damit es einigermaßen billig ist, nach bestimmten Ereignissen im gesamten Blockgeschichte zu suchen. Leider ist die Verwendung eines MIP-ampassenden Filters nicht einfach mit einem leichten Client zu tun, da die Suche nur in einzelnen Headern durchgeführt wird, was viel langsamer ist. Durch die Suche nach ein paar Tagen Blockgeschichte kehrt normalerweise nach einer akzeptablen Zeit zurück, aber aber Im Moment sollten Sie in der gesamten Geschichte nicht nach etwas suchen, da es eine extrem lange Zeit dauern wird.
Speicher-, Festplatten- und Bandbreitenanforderungen
Hier ist die gute Nachricht: Ein leichter Client benötigt keine große Datenbank, da er alles auf Bedarf abrufen kann. Mit aktivierter Müllsammlung (die implementiert werden sollen), Die Datenbank funktioniert eher wie a Cache, und ein leichter Client kann mit laufen lassen bis zu 10 MB Speicherplatz. Beachten Sie, dass die aktuelle GETH -Implementierung umsetzt 200 MB Speicherwas wahrscheinlich weiter reduziert werden kann. Die Bandbreitenanforderungen sind ebenfalls niedriger, wenn der Kunde nicht stark verwendet wird. Die verwendete Bandbreite ist normalerweise gut unter 1 MB/Stunde beim Leerlauf mit zusätzlich 2-3 KB für eine durchschnittliche Status-/Speicheranforderung.
Zukünftige Verbesserungen
Reduzierung der Gesamtlatenz durch Remoteausführung
Manchmal ist es unnötig, Daten zwischen dem Client und dem Server mehrmals hin und her zu übergeben, um eine Funktion zu bewerten. Es wäre möglich, Funktionen auf der Serverseite auszuführen und dann alle Merkle-Proofs zu sammeln, die alle Statusdaten beweisen, auf die die Funktion zugegriffen zu haben, und alle Beweise gleichzeitig zurückgeben, damit der Client den Code erneut ausführen und die Beweise überprüfen kann. Diese Methode kann sowohl für die schreibgeschützten Funktionen der Verträge als auch für jeden anwendungsspezifischen Code verwendet werden, der als Eingabe auf der Blockchain/des Status arbeitet.
Überprüfen Sie die komplexen Berechnungen indirekt
Eine der Hauptbeschränkungen, an denen wir arbeiten, um sich zu verbessern ist die langsame Suchgeschwindigkeit von Protokollgeschichten. Viele der oben genannten Einschränkungen, einschließlich der Schwierigkeit, mit MIP-abgebildete Bloom-Filter zu erhalten, folgen demselben Muster: Der Server (der ein vollständiger Knoten ist) kann leicht eine bestimmte Information berechnen, die mit den leichten Clients gemeinsam genutzt werden kann. Die leichten Kunden haben derzeit keinen praktischen Weg, um die Gültigkeit dieser Informationen zu überprüfen, da die gesamte Berechnung der Ergebnisse direkt so viel Verarbeitungsleistung und Bandbreite erfordern würde, was die Verwendung eines leichten Clients sinnlos machen würde.
Glücklicherweise gibt es eine sichere und vertrauenslose Lösung für den General Aufgabe indirekt validierende Remote -Berechnungen basierend auf einem Eingabedatensatz, von dem beide Parteien angenommen werden, dass sie verfügbar sind, auch wenn die empfangende Partei nicht über die tatsächlichen Daten verfügt, nur der Hash. Dies ist genau der Fall In unserem Szenario, in dem die Ethereum -Blockchain selbst als Eingabe für eine solche verifizierte Berechnung verwendet werden kann. Dies bedeutet, dass leichte Clients die Funktionen in der Nähe des vollständigen Knotens haben, da sie einen Light -Server bitten können, eine Operation für sie aus der Ferne zu bewerten, die sie sonst nicht selbst ausführen könnten. Die Details dieser Funktion werden immer noch ausgearbeitet und liegen außerhalb des Rahmens dieses Dokuments, aber die allgemeine Idee der Verifizierungsmethode wird von Dr. Christian Reitwiesner in diesem erläutert Devcon 2 Talk.
Komplexe Anwendungen, die auf enorme Aufbewahrungsspeicher zugreifen, können auch von diesem Ansatz profitieren, indem Accessor-Funktionen vollständig auf der Serverseite bewertet werden und keine Beweise herunterladen und die Funktionen neu bewerten müssen. Theoretisch wäre es auch möglich, die indirekte Überprüfung zur Filterungsereignisse zu verwenden, auf die leichte Clients nicht achten konnten. In den meisten Fällen ist es jedoch immer noch einfacher und effizienter, ordnungsgemäße Protokolle zu generieren.
