Nach weiteren zwei Monaten nach der Veröffentlichung des ersten Python Proof of Concept -Veröffentlichung von Serenity freue ich mich, Ihnen mitteilen zu können, dass Serenity POC2 ist jetzt verfügbar. Obwohl die Veröffentlichung weiterhin weit von einem Test-fertigen Kunden entfernt ist, viel weniger als produktionsbereit, bringt POC2 eine Reihe wichtiger Verbesserungen mit sich. In erster Linie war es das Ziel von POC2, das vollständige Protokoll zu implementieren, einschließlich der grundlegenden Eckfälle (Slashing -Wetten und -ablagerungen), um sicherzustellen, dass wir jedes Detail des Protokolls im Einsatz haben und es in Aktion betrachten, auch wenn wir in einer stark eingeschränkten Testumgebung. Dieses Ziel wurde erreicht. Während POC1 nur die minimale Funktionalität enthielt, die für die Herstellung von Casper und EIP 101 erforderlich ist, enthält POC2 im Wesentlichen das vollständige Casper/Serenity -Protokoll, EIP 101 und 105.
Die spezifischen Merkmale, die in POC2 zu finden sind, die in POC1 nicht verfügbar waren, sind wie folgt:
- EIP 105 Implementierung – EIP 105 ist das “Sharding -Gerüst” EIP, mit dem die Verarbeitung von Ethereum -Transaktionen etwas parallelisiert werden und die Bühne für ein späteres Sharding -Schema (das noch nicht bestimmt werden muss). Es verwendet den beschriebenen Binärbaum -Sharding -Mechanismus Hier Damit Transaktionen einen “Aktivitätsbereich” angeben können, der die Adressen einschränkt, die die Transaktionsausführung berühren kann, können Sie sicherstellen, dass Transaktionen mit disjunkten Aktivitätsbereichen parallel verarbeitet werden können. Es führt auch ein Sstoreext Und Sloadext Opcodes, um Verträge zu ermöglichen, den Zugriff auf die gleiche Adresse derselben Adresse in anderen Scherben zuzugreifen (vorausgesetzt, der Ziel -Shard liegt im Aktivitätsbereich); Dieser Mechanismus bedeutet im Wesentlichen, dass der binäre Scherbenbaum gleichzeitig als Supervertrags-Sharding-Mechanismus und Subkontraktions-Sharding-Mechanismus dient.
- Gasprüfung – Der Algorithmus, der eine Transaktion anpasst, um sicherzustellen, dass er korrekt Gas bezahlt. Derzeit wird dies erreicht, indem nur Transaktionen akzeptiert werden, die auf Konten gehen, die ein bestimmtes Stück von “haben”Obligatorischer Kontocode“, die dem Kontoinhaber die Freiheit gibt, zwei Code-Teile anzugeben: den Checkercode und den Läufercode. Der Checkercode soll schnelle Überprüfungen wie Signatur und Nicht-CEC-Überprüfung durchführen; der Musteranpassungsalgorithmus bietet maximal 250.000 Gas, um den Check-Code zu leiten. Der Läufer-Code kann ein weiteres Vertrag über die Übertragung des Transaktionens zum Ausdruck bringen. Benutzer können Gas direkt aus Verträgen (z. B. Multisig -Geldbörsen, Ring -Signaturmischern usw.) bezahlen und müssen nicht immer eine kleine Menge ETH auf ihrem Hauptkonto haben, um Gas zu bezahlen – solange die Gaszahlung aus dem Vertrag innerhalb von 250.000 Gas erfolgt.
- Ring Signature Mixer – Teil des Tests.PY -Skripts beinhaltet jetzt das Erstellen einer Instanz von a Überprüfungsvertrag für Ringunterschrift Dies ist als Mixer konzipiert: Fünf Benutzer senden ihre öffentlichen Schlüssel neben einer Einzahlung von 0,1 ETH und ziehen dann die 0,1 -ETH ab, die die Adresse mit einer verknüpfbaren Ringsignatur angibt, und garantiert gleichzeitig, dass (i) jeder, der 0,1 ETH einladet, genau einmal 0.1 ETH zurückziehen kann, und (ii) es ist unmöglich, die Einzahlung zu entsprechen, die der Einzahlung entspricht. Dies wird so implementiert, dass der Gassprüfer entspricht und den wichtigsten Vorteil bietet, dass die Transaktion, die die ETH 0,1 zurückzieht, nicht von einem zusätzlichen Konto gesendet werden muss, das Gas bezahlt (etwas, das eine Ringsignatur -Implementierung neben dem derzeitigen Ethereum tun müsste, und das zu dem Zeitpunkt zu dem Zeitpunkt zu dem Zeitpunkt, als Sie die ETH -ETH -Übertragung übertragen müssen, um das Gas zu bezahlen). Stattdessen kann die Abhebungs -Transaktion einfach von selbst gesendet werden, und der Gasüberprüfungsalgorithmus kann überprüfen, ob die Signatur korrekt ist und dass der Mixer dem Bergmann eine Gebühr zahlt, wenn die Abhebungstransaktion in einen Block aufgenommen wird.
- Genauere Zahlen für Zinssätze und Bewertungsregelparameter – Die Bewertungsregel (dh der Mechanismus, der bestimmt, wie viel Validatoren auf der Grundlage ihrer Wette bezahlt werden) ist jetzt eine lineare Kombination einer logarithmischen Bewertungsregel und einer quadratischen Bewertungsregel. Block oder 50,58% Basis -Jahresrendite, (ii) Es gibt eine Strafe von 74 Teilen pro Milliarde pro Block oder ~ 36,98% jährlich, dass jeder zahlt, daher beträgt die erwartete Nettorendite von Wetten perfekt ~ 22 Teile pro Milliarden pro Block oder ~ 10% jährlich. Wetten absolut falsch (dh mit maximaler Gewissheit und Unrecht) auf einen einzelnen Block oder Zustandswurzel zerstören> 90% Ihrer Kaution, und etwas fälschlicherweise führt zu einer viel weniger extremen, aber immer noch negativen Rendite. Diese Parameter werden weiterhin angepasst, um sicherzustellen, dass realistische Validatoren einigermaßen profitabel sein können.
- Genauere Regeln für Validator -Induktionsregeln – Maximal 250 Validatoren, der Mindestbetrag von Ether beginnt bei 1250 ETH und steigt hyperbolisch mit der Formel auf min = 1250 * 250 / (250 – V) Wo v Ist die aktuelle aktive Anzahl von Validatoren (dh wenn es 125 Aktivatoren aktiv sind, wird das Minimum zu 2500 ETH. Wenn es 225 Aktivatoren aktiv sind, wird es zu 12500 ETH, wenn 248 Validatoren aktiv sind, wird es 156250 ETH). Wenn Sie aufgenommen werden, können Sie Wetten erzielen und Gewinne für bis zu 30 Millionen Sekunden (~ 1 Jahr) erzielen, und danach wird eine besondere Strafe von 100 Teilen pro Milliarde pro Block angezogen, was eine weitere Bestätigung unruhig macht. Dies zwingt Validator Churn.
- Neue Vorkompilien einschließlich ECADD und ECMUL (kritisch für Ringsignaturen), Modexp, RLP -Dekodierung und “Gaseinzahlungsvertrag” (ein Mechanismus, der im obligatorischen Kontocode zur Bezahlung von Gas verwendet wird; theoretisch könnte er bei Bedarf in EVM -Code geschrieben werden, aber es kann zu Effizienzbedenken bestehen.)
- Wiederherstellung von Protokoll und Erstellen als Vorkompilien – Die Opcodes existieren immer noch zu Abwärtskompatibilitätszwecken, nennen jedoch einfach die Vorkompilieradressen. Dies ist eine weitere Bewegung in Richtung “Abstraktion”.
- Neuer Mechanismus zum direkten Wetten auf staatliche Wurzeln
- Logik zum Erkennen und Abbau von Doppelwetten und Doppelblöcken
- Logik für den Konsens auf einer Höhe, auch wenn ein Validator in dieser Höhe mehrere Blöcke erzeugt hat
Die hier getroffenen Protokollentscheidungen sind keineswegs endgültig; Viele von ihnen werden immer noch aktiv innerhalb der Forschungskanäle diskutiert. Die nächsten wenigen Runden von POC -Releases werden somit zusammen mit einer geeigneten P2P -Netzwerkschicht, die einer Serenity -Knoten -Implementierung ähnelt, mit dem späteren Ziel, ein Serenity -TestNet zwischen mehreren Computern durchzuführen, zu erstellen. Gleichzeitig wird unser Forschungsteam weiterhin nach den feineren Details des Protokolls hämmern und sicherstellen, dass jede einzelne Protokollentscheidung korrekt und gut gerechtfertigt ist.
Darüber hinaus werden wir in den nächsten Wochen mit der Casper-Protokollspezifikation und der Designrationale zugänglicheren Materialien auftreten, die sowohl das breite Konsens-für-Bet-Konzept als auch spezifische Entwurfsentscheidungen abdecken, die von den Regeln für Wetten und Blockantriebsauswahl reichen.
