14. Januar tl; DC (zu lange, nicht angerufen)
Haftungsausschluss: Dies ist eine Verdauung der Themen, die im wiederkehrenden ETH1.x -Forschungsaufruf diskutiert werden und keine endgültigen Pläne oder Verpflichtungen für Netzwerk -Upgrades darstellen.
Die Hauptthemen dieses Anrufs waren
- Grobe Daten, die die Vorteile des Umschaltens auf eine binäre Triestruktur quantifizieren
- Übergangsstrategien und mögliche Herausforderungen für einen Wechsel zu binären Versuchen
- “Merklizing” -Kontraktcode für Zeugen und Auswirkungen auf die Gasplanung/Messung
- Kettenbeschneidung und historische Ketten-/Zustandsdaten – Auswirkungen auf die Netzwerke und Ansätze zur Verteilung.
Logistik
Das Wochenende nach ETHCC (7. bis 8. März) wird es einen kleinen 1.x-Forschungsgipfel geben, der die Absicht hat, ein paar Tage fester Diskussion zu haben und an den anstehenden Themen zu arbeiten. Die Sitzung wird bei 40 Teilnehmern (durch Einschränkungen des Veranstaltungsortes) begrenzt, was für die erwarteten Teilnehmer mehr als genug sein sollte.
Es wird wahrscheinlich auch eine informelle, ad-hoc-Versammlung in der Stanford Blockchain Week und in Ethdenver geben, aber nichts, was ausdrücklich geplant ist.
Der nächste Anruf ist vorläufig für die erste oder zweite Woche im Februar geplant-auf halbem Weg zwischen jetzt und dem Gipfel in Paris.
Technische Diskussion
EIP #2465
Obwohl dieser EIP nicht direkt mit dem staatenlosen Ethereum zusammenhängt, verbessert es das Netzwerkprotokoll für die Transaktionsausbreitung und ist daher eine ziemlich einfache Verbesserung, die die Dinge in die richtige Richtung für die Forschung bewegt. Unterstützung!
Binäre Einsparungen der Triesgröße
Übergang zu einer binären Triestruktur (anstelle der aktuellen Hexary -Trie -Struktur) sollte theoretisch die Größe der Zeugen um so etwas wie 3,75x verringern, In der Praxis ist diese Reduzierung jedoch nur etwa die Hälfte, je nachdem, wie Sie sie betrachten..
Zeugen sind etwa 30% Code und 70% Hashes. Hashes innerhalb des Tries werden um 3x reduziert, aber der Code wird mit einem binären Trie nicht verbessert, da er immer in den Zeugen einbezogen werden muss. Wenn Sie also auf ein binäres Trie-Format wechseln, werden Zeugengrößen auf ~ 300-1400 KB von ~ 800-3.400 KB im Hexary-Trie gesenkt.
Schalter machen
Der tatsächliche Übergang zu einem binären Trie ist eine andere Angelegenheit mit einigen Fragen, die ausgearbeitet werden müssen. Es gibt im Wesentlichen zwei verschiedene mögliche Strategien, die befolgt werden könnten:
Progressiver Übergang -Dies ist ein “Schiff des Theseus” -Stransitionsmodells, bei dem der gesamte staatliche Trie in ein Binärformat-Account-by-Account- und Storageslot-für-StoragesLot migriert wird, da jeder Teil des Staates von der EVM-Ausführung berührt wird. Dies impliziert, dass für Forevermore Ethereums Staat ein hexarischer/binärer Hybrid sein würde und Konten “gestoßen” werden müssten, um auf das neue Trie -Format zu aktualisieren (vielleicht mit einem Poke -Opcode;). Die Vorteile besteht darin, dass dies die normale Funktion der Kette nicht unterbricht und keine große Koordination zur Verbesserung erfordert. Der Nachteil ist die Komplexität: Sowohl Hexary- als auch binäre Trie -Formate müssen bei Kunden berücksichtigt werden, und der Prozess würde niemals tatsächlich “beenden”, da einige Teile des Staates nicht extern zugreifen können und von ihren Besitzern ausdrücklich gestoßen werden müssten, auf die wahrscheinlich nicht für den gesamten Staat stattfinden. Bei der progressiven Strategie müsste Clients auch ihre Datenbank als eine Art “virtualisierter” binärer Trie innerhalb eines hexarischen Datenbanklayouts ändern, um eine plötzliche dramatische Erhöhung der Speicheranforderungen für alle Clients zu vermeiden (Hinweis: Diese Datenbankverbesserung kann unabhängig vom vollständigen “progressiven” Übergang erfolgen und wäre immer noch von Vorteil).
Berechnen und sauber schneiden -Dies wäre ein “gleichzeitig” Übergang, der über einen oder mehrere Hardgros-Verfahren durchgeführt wird, wobei ein Datum in der Zukunft für den Switch ausgewählt würde, und dann müssten alle Teilnehmer des Netzwerks den Zustand als binäre Trie neu berechnen und dann gemeinsam zum neuen Format wechseln. Diese Strategie wäre in gewissem Sinne „einfacher“ zu implementieren, da sie auf der technischen Seite unkompliziert ist. Aus Sicht der Koordination ist es jedoch komplexer: Der neue binäre Trie-Staat muss vor der Gabel vorbereitet werden, die eine Stunde (oder so an diesem Fenster) dauern kann-während dieses Fensters ist nicht klar, wie Transaktionen und neue Blöcke behandelt werden würden (weil sie in den noch nicht kompetierten Binärzusatz und/oder/oder-/oder-/oder-/oder-/oder-/oder-/oder-/oder-/oder-oder Legacy-Trie) einbezogen werden müssen). Dieser Prozess wird durch die Tatsache erschwert, dass viele Bergarbeiter und Austausch es vorziehen, Kunden im letzten Moment zu aktualisieren. Alternativ könnten wir uns vorstellen, die gesamte Kette für kurze Zeit zu stoppen, um den neuen Zustand erneut zu berechnen-ein Prozess, der noch schwieriger und potenziell kontrovers sein könnte, um zu koordinieren.
Beide Optionen sind immer noch “auf der Tabelle” und erfordern weitere Berücksichtigung und Diskussion, bevor Entscheidungen in Bezug auf die nächsten Schritte getroffen werden. Insbesondere das Abwägen der Kompromisse zwischen der Komplexität der Implementierung einerseits und der Koordinationsprobleme andererseits.
Code “Chunking”
In Bezug auf den Code -Teil der Zeugen wurden einige Prototyping -Arbeiten in Code ‘Merklization’ durchgeführt, wodurch der Vertragscode im Wesentlichen in Brocken aufgeteilt werden kann, bevor er in einen Zeugen aufgenommen wird. Die Grundidee ist, dass der Zeuge, wenn eine Methode in einem intelligenten Vertrag genannt wird, nur die Teile des Vertragscode einbeziehen muss, die tatsächlich genannt wurden, und nicht den gesamten Vertrag. Dies ist immer noch sehr frühe Forschungen, deutet jedoch auf eine zusätzliche Reduzierung des Codenteils eines Zeugen auf ~ 50% auf. Nebendärerisch könnte die Praxis des Code -Chunking erweitert werden, um einen einzelnen globalen ‘Code -Trie’ zu erstellen, aber dies ist keine gut entwickelte Idee und hat wahrscheinlich eigene Herausforderungen, die weitere Untersuchungen rechtfertigen.
Es gibt verschiedene Methoden, mit denen Code in Stücke unterteilt werden kann und dann verwendet werden kann, um Zeugen zu generieren. Das erste ist “dynamisch”, da es sich auf die Suche nach springsten Anweisungen und das Spalten in der Nähe dieser Punkte stützt, was je nach Aufschlüsselung des Codes zu variablen Stückgrößen führt. Die zweite ist “statisch”, die den Code in feste Größen zerlegt und einige notwendige Metadaten hinzufügen würde, die angeben, wo die richtigen Sprungziele im Chunk liegen. Es scheint, als wäre einer dieser beiden Ansätze gültig, und beide könnten kompatibel sein und den Benutzern überlassen werden, zu entscheiden, welche sie beschäftigen sollen. In beiden Fällen ermöglicht das Chunking ein weiteres Schrumpfen der Zeugengrößen.
(UN) Gas
Eine offene Frage ist, welche Änderungen bei der Einführung von Blockzeugen erforderlich oder wünschenswert wären. Zeugengenerierung muss in Gas bezahlt werden. Wenn der Code untergebracht ist, würde es innerhalb eines Blocks eine Überschneidung geben, wenn mehrere Transaktionen denselben Code abdecken, und somit würden Teile eines Blockzeugen mehr als einmal von allen eingeschlossenen Transaktionen im Block mehr als einmal bezahlt. Es scheint eine sichere Idee (und eine, die für Bergleute gut wäre) darin, sie dem Plakat einer Transaktion zu überlassen, um die vollen Kosten für das Zeuge seiner eigenen Transaktion zu zahlen und dann den Bergmann die Überzahlung zu halten. Dies minimiert die Notwendigkeit von Änderungen der Gaskosten und treibt Bergleute an, Zeugen zu produzieren. Wie diese Änderung des Sicherheitsmodells behandelt wird, muss vollständig und gründlich berücksichtigt werden. Am Ende des Tages ist es das Ziel, jede Transaktion die Kosten für die Erzeugung eines eigenen Zeugen zu berechnen, proportional zu dem Code, den es berührt.
Wei Tangs Ungas -Vorschlag Kann Änderungen an der EVM erleichtert werden. Es ist nicht ausschließlich für das staatenlose Ethereum notwendig, aber es ist eine Idee, wie zukünftige Veränderungen der Gaspläne erleichtert werden können. Die Frage zu stellen: “Wie sehen die Änderungen sowohl ohne als auch mit Ungas aus – und diese Dinge, die sich in Betracht ziehen, macht Ungas tatsächlich die Implementierung von diesem Zeug wirklich einfacher?”. Um dies zu beantworten, brauchen wir Experimente, die Dinge mit Merklized Code und neuen Gasregeln ausführen, und dann sehen, was sich in Bezug auf Kosten und Ausführung im EVM ändern soll.
Beschneidung und Datenbereitstellung
In einem staatenlosen Modell benötigen Knoten, die nicht oder alle Staaten haben, eine Möglichkeit, dem Rest des Netzwerks zu signalisieren, welche Daten sie haben und welche Daten ihnen fehlen. Dies hat Auswirkungen auf die Netzwerk-Topologie-staatenlose Clients, bei denen keine Daten fehlen, müssen in der Lage sein, die Daten, die sie irgendwo im Netzwerk benötigen, zuverlässig zu finden und schnell zu finden, sowie über die Daten zu übertragen, welche Daten sie nicht haben (und möglicherweise benötigen). Das Hinzufügen eines solchen Merkmals zu einem der Kettenbetriebs-EIPs ist eine Networking-Protokolländerung (aber nicht Konsens), und es kann jetzt auch durchgeführt werden.
Die zweite Seite dieses Problems besteht darin, die historischen Daten zu speichern, und die bisher beste Lösung ist ein ethspezifisches verteiltes Speichernetzwerk, das angeforderte Daten bereitstellen kann. Dies könnte in vielen Geschmacksrichtungen kommen; Der vollständige Staat könnte für “Chunking” zugänglich sein, ähnlich wie der Vertragscode. Partialdatenknoten konnten über (zufällig zugewiesene) Zustandsbrocken nachdenken und sie durch Anfrage an den Kanten des Netzwerks dienen. Kunden verwenden möglicherweise zusätzlichen Datenrouting -Mechanismus, damit ein staatenloser Knoten weiterhin über einen Vermittler fehlende Daten erhalten kann (die nicht die von ihm benötigten Daten enthält, aber mit einem anderen Knoten verbunden ist). Das allgemeine Ziel ist jedoch, dass Clients in der Lage sein sollten, sich dem Netzwerk anzuschließen und alle Daten zuverlässig, zuverlässig und ohne Jockying für Position zu erhalten, die sich mit einem vollständigen Knoten verbinden, was jetzt effektiv mit LES-Knoten passiert. Die Arbeiten um diese Ideen sind noch in einem frühen Stadium, aber das Geth-Team hat einige vielversprechende Ergebnisse, die mit “State Tiling” (Chunking) experimentieren, und Turbo-Geth arbeitet am Datenrouting für Klatsch von Teilen des Staates.
Wie immer, wenn Sie Fragen zu ETH1X -Bemühungen, Themenanfragen haben oder einen Beitrag leisten, an einer Veranstaltung teilnehmen, sich auf ethresear.ch vorstellen oder an @gichiba und/oder @jhancock auf Twitter erreichen möchten.
