Mein vorheriger Beitrag Einführung Ethereum -Skript 2.0 wurde mit einer Reihe von Antworten getroffen, einige sehr unterstützend, andere schlugen vor, dass wir zu ihrem eigenen bevorzugten Stack-basierten / montagebasierten / funktionalen Paradigma wechseln und verschiedene spezifische Kritikpunkte anbieten, die wir uns hart nachsehen. Vielleicht kam die stärkste Kritik, die diesmal kam Sergio Damian LernerBitcoin -Sicherheitsforscher, Entwickler von Qixcoin und für den wir dankbar für seine sind Analyse des Daggers. Sergio kritisiert insbesondere zwei Aspekte der Änderung: das Gebührensystem, das von einem einfachen Ein-Variablen-Design geändert wird, bei dem alles ein festes Vielfaches der Basisfeiern und den Verlust der Krypto-Opcodes ist.
Die Krypto -Opcodes sind der wichtigere Teil von Sergios Argument, und ich werde dieses Problem zuerst behandeln. In Ethereum Script 1.0 hatte der Opcode -Set eine Sammlung von Opcodes, die sich auf bestimmte kryptografische Funktionen spezialisiert haben – zum Beispiel gab es einen Opcode sha3, der eine Länge und einen Startspeicherindex vom Stapel vom Stapel abzog und dann den SHA3 der von den gewünschten Blöcken im Speicher begonnenen Blöcken aus dem Startindex startete. Es gab ähnliche Opcodes für SHA256 und RIPEMD160, und es gab auch Krypto -Opcodes, die sich um SecP256K1 -elliptische Kurvenoperationen auswirken. In ES2 sind diese Opcodes verschwunden. Stattdessen werden sie durch ein flüssiges System ersetzt, in dem die Leute Sha256 manuell in ES schreiben müssen (in der Praxis würden wir eine Kommision oder Präsenz dafür anbieten), und später können intelligente Dolmetscher die SHA256-ES-Skript, die Sie verwenden, nahtlos die SHA256 ES-Skript ersetzen, wenn Sie Sha256 in C ++ nennen. Von außen sind die SHA256- und der Maschinencode SHA256 nicht zu unterscheiden; Beide berechnen die gleiche Funktion und machen daher die gleichen Transformationen in den Stapel. Der einzige Unterschied besteht darin, dass letzteres hundertmal schneller ist, was uns die gleiche Effizienz gibt, als wäre Sha256 ein Opcode. Anschließend kann auch ein flexibles Gebührensystem implementiert werden, um SHA256 billiger zu machen, um seine verkürzte Berechnungszeit zu berücksichtigen, und es idealerweise billig wie ein Opcode ist.
Sergio bevorzugt jedoch einen anderen Ansatz: Es kommt jedoch mit vielen Krypto-Opcodes aus dem Box und verwendete hartnäckige Protokolländerungen, um falls erforderlich, wenn nötig weiter unten auf der ganzen Linie hinzuzufügen. Er schreibt:
Erstens habe ich nach 3 Jahren, in denen Bitcoin genau gesehen wurde, das verstanden Eine Kryptowährung ist weder ein Protokoll noch ein Vertrag, noch ein Computernetzwerk. Eine Kryptowährung ist eine Gemeinschaft. Mit Ausnahme einiger weniger Satz von Konstanten wie der Geldversorgungsfunktion und der globalen Balance kann in Zukunft alles geändert werden, solange die Änderung im Voraus angekündigt wird. Das Bitcoin -Protokoll hat bis jetzt gut funktioniert, aber wir wissen, dass es langfristig mit Skalierbarkeitsproblemen konfrontiert ist und sich entsprechend ändern muss. Kurzfristige Vorteile wie die Einfachheit des Protokolls und der Codebasis halfen dem Bitcoin, weltweit Akzeptanz und Netzwerkeffekte zu erhalten. Ist der Referenzcode der Bitcoin -Version 0.8 so einfach wie die 0,3 -Version? gar nicht. Jetzt gibt es überall Caches und Optimierungen, um maximale Leistung und höhere DOS -Sicherheit zu erzielen, aber niemand kümmert sich darum (und niemand sollte). Eine Kryptowährung wird mit einem einfachen Wertversprechen, der kurz/mittel/mittelfristig funktioniert, mit einem einfachen Wertversprechen ausgestattet.
Dies ist ein Punkt, der oft in Bezug auf Bitcoin erzogen wird. Je mehr ich mir anschaue, was tatsächlich in der Bitcoin-Entwicklung vor sich geht, desto mehr werde ich fest in meiner Position festgelegt, dass das Argument absolut falsch ist. Derzeit gibt es viele Fehler in Bitcoin, die geändert werden können, wenn wir nur den kollektiven Willen hätten. Ein paar Beispiele nehmen:
- Die 1 MB -Blockgrößengrößenbeschränkung. Derzeit gibt es eine harte Begrenzung, dass ein Bitcoin -Block nicht mehr als 1 MB Transaktionen enthalten kann – eine Kappe von ungefähr sieben Transaktionen pro Sekunde. Wir beginnen bereits mit etwa 250 KB in jedem Block gegen diese Grenze zu bürsten, und es wird bereits Druck auf die Transaktionsgebühren ausgeübt. In den meisten Bitcoin-Geschichte lag die Gebühren bei rund 0,01 USD, und jedes Mal, wenn der Preis die aus BTC-denominierte Gebühr erhöhte, die Bergarbeiter akzeptierten, wurde angepasst. Jetzt steckt die Gebühr jedoch bei 0,08 USD, und die Entwickler stellen sie nicht wohl, da die Anpassung der Gebühr auf 0,01 USD zurückzuführen wäre, dass die Anzahl der Transaktionen gegen die 1 -MB -Grenze bürsten kann. Das Entfernen dieser Grenze oder zumindest auf einen angemesseneren Wert wie 32 MB ist eine triviale Änderung. Es ist nur eine einzelne Zahl im Quellcode, und es würde eindeutig viel Gutes tun, um sicherzustellen, dass Bitcoin mittelfristig weiterhin verwendet wird. Und doch haben Bitcoin -Entwickler dies völlig versäumt.
- Der op_checkmultisig -Fehler. Der OP_Checkmultisig-Operator gibt einen bekannten Fehler, der zur Implementierung von MultiG-Transaktionen in Bitcoin verwendet wird, wobei ein zusätzliches Dummy-Zero als Argument erforderlich ist, das einfach vom Stapel und nicht verwendet wird. Dies ist sehr nicht intuitiv und verwirrend; Als ich persönlich daran arbeitete, Multisig für implementieren PybitCointoolsIch bin tagelang festgefahren, um herauszufinden, ob der Dummy-Zero vorne sein sollte oder in einem 2-von-3-Multisig den Platz des fehlenden öffentlichen Schlüssels einnehmen sollte und ob es zwei Dummy-Nullen in einem 1-von-3-Multisig geben soll. Schließlich habe ich es herausgefunden, aber ich hätte es viel schneller herausgefunden, dass der Betrieb des OP_Checkmultisig -Operators intuitiver gewesen wäre. Und doch wurde der Fehler nicht behoben.
- Der Bitcoind -Kunde. Der Bitcoind-Kunde ist bekannt dafür, dass er eine sehr unhandliche und nicht moduläre Apparat ist. Tatsächlich ist das Problem so ernst, dass jeder, der eine bitcoind-Alternative erstellen möchte, die skalierbarer und unternehmungsfreundlicher ist, Bitcoind überhaupt nicht verwendet, sondern von vorne anfangen. Dies ist kein Kernprotokollproblem, und die Änderung des Bitcoind-Kunden muss theoretisch überhaupt keine Veränderungen für hartnäckige Veränderungen beinhalten, aber die erforderlichen Reformen werden immer noch nicht durchgeführt.
All diese Probleme sind nicht vorhanden, da die Bitcoin -Entwickler inkompetent sind. Sie sind nicht; Tatsächlich sind sie sehr qualifizierte Programmierer mit tiefem Wissen über die Kryptographie und die Datenbank- und Networking -Probleme, die dem Client -Design der Kryptowährung verbunden sind. Die Probleme sind da, weil die Bitcoin-Entwickler sehr gut erkennen, dass Bitcoin ein 10-Milliarden-Dollar-Zug ist, der mit 400 Kilometern pro Stunde rast, und wenn sie versuchen, den Motor auf halbem Weg zu wechseln, und sogar der kleinste Bolzen sich löst, könnte das Ganze zum Stillstand kommen. Eine Änderung, die so einfach wie die Datenbank im März 2011 ausgetauscht wird Fast tat. Aus diesem Grund ist es meiner Meinung nach unverantwortlich, ein schlecht konzipiertes, nicht gekotzbares Protokoll zu hinterlassen und einfach zu sagen, dass das Protokoll zu gegebener Zeit aktualisiert werden kann. Im Gegenteil, das Protokoll muss von Anfang an ein angemessenes Maß an Flexibilität aufweisen, sodass Änderungen durch den Konsens automatisch vorgenommen werden können, ohne dass eine Software aktualisiert werden muss.
Um Sergios zweites Problem zu beheben, ist seine Hauptqualität mit modifizierbaren Gebühren: Wenn Gebühren steigen und abfallen, wird es für Verträge sehr schwierig, ihre eigenen Gebühren festzulegen, und wenn eine Gebühr unerwartet steigt, kann dies eine Verwundbarkeit eröffnen, durch die ein Angreifer sogar einen Vertrag erzwingen kann, bankrott zu werden. Ich muss Sergio dafür danken, dass er diesen Punkt gemacht hat. Es ist etwas, das ich noch nicht ausreichend in Betracht gezogen hatte, und wir müssen uns bei der Erstellung unseres Designs sorgfältig überlegen. Seine Lösung, manuelle Protokollaktualisierungen, ist jedoch wohl nicht besser; Protokollaktualisierungen, dass Änderungsgebührenstrukturen auch neue wirtschaftliche Schwachstellen in Verträgen aufdecken können, und sie sind wohl noch schwieriger zu kompensieren, da es absolut keine Einschränkungen gibt, welche Content Manual Protocol -Updates enthalten können.
Was können wir also tun? Zunächst gibt es viele Zwischenlösungen zwischen Sergios Ansatz-mit einem begrenzten festen Satz von Opcodes, die nur mit einem hart günstigen Protokolländerung hinzugefügt werden können-und die Idee, die ich im ES2-Blogpost zur Verfügung gestellt habe, um Bergarbeiter über die flüssigen Änderung der Gebühren für jedes Skript abzustimmen. Ein Ansatz könnte darin bestehen, das Abstimmungssystem diskreter zu gestalten, so dass es eine harte Grenze zwischen einem Skript gibt, das 100% Gebühren zahlen muss, und einem Skript, das „befördert“ wird, um ein Opcode zu sein, der nur ein 20 -facher Cryptofee bezahlen muss. Dies könnte durch eine Kombination aus Nutzungszählungen, Bergmann -Abstimmungen, Ätherinhaber oder anderen Mechanismen geschehen. Dies ist im Wesentlichen ein integrierter Mechanismus für Hardfirs, für die technisch keine Quellcode-Updates angewendet werden müssen, wodurch es viel flüssiger und nicht disruptiver ist als ein manueller Hardgabel-Ansatz. Zweitens ist es wichtig, noch einmal darauf hinzuweisen, dass die Fähigkeit, starke Krypto effizient zu machen, nicht verschwunden ist, auch nicht aus dem Genesis -Block. Wenn wir Ethereum starten, werden wir einen SHA256-Vertrag, einen SHA3-Vertrag usw. erstellen und sie von Anfang an in den Status des Pseudo-Opcode-Status „auslösen“. So wird Ethereum mit eingeschlossenen Batterien kommen; Der Unterschied besteht darin, dass die Batterien so einbezogen werden, dass es in Zukunft nahtlos mehr Batterien aufgenommen werden.
Es ist jedoch wichtig zu beachten, dass ich diese Fähigkeit betrachte, in Zukunft effiziente optimierte Krypto -OPs hinzuzufügen, um obligatorisch zu sein. Theoretisch ist es möglich, einen „Zerocoin“ -Vertrag innerhalb von Ethereum oder einen Vertrag unter Verwendung kryptografischer Berechnungsnachweise (SCIP) und vollständig homomorpher Verschlüsselung abzuschließen, damit Sie tatsächlich Ethereum als „dezentrale Amazonas -EC2 -Instanz“ für Cloud -Computer verwenden können, die viele Menschen jetzt fälschlicherweise glauben. Sobald das Quantum Computing herauskommt, müssen wir möglicherweise Verträge wechseln, die auf NTRU angewiesen sind. One SHA4 oder SHA5 kommen heraus, wir müssen möglicherweise Verträge wechseln, die auf sie angewiesen sind. Einmal Verschleierungstechnologie Reife, Verträge möchten sich darauf verlassen, um private Daten zu speichern. Damit all dies mit weniger als einer Gebühr von 30 USD pro Transaktion möglich ist, müsste die zugrunde liegende Kryptographie in C ++ oder Maschinencode implementiert werden, und es müsste eine Gebührenstruktur geben, die die Gebühr für die Operationen angemessen verringert, sobald die Optimierungen vorgenommen wurden. Dies ist eine Herausforderung, auf die ich keine einfachen Antworten sehe, und Kommentare und Vorschläge sind sehr willkommen.
