Mit der Constantinople-Hardfork wird Ethereum den Übergang in die Metropolis-Phase vollenden. Wir schauen uns an, welche Feature es in das Upgrade geschafft haben.
Mitte Januar, bei Block 7.080.000, wird Ethereum die Constantinople Hardfork aktivieren. Diese Hardfork ist der zweite und letzte Teil des Metropolis-Upgrades. Der erste lief unter dem Titel „Byzantine“ und wurde am 17. Oktober 2017 aktiviert. Mit Contantinople wird Ethereum endgültig in die „Metropolis“-Phase wechseln. Diese ist der letzte Übergang zu Serenity, dem anvisierten finalen Zustand von Ethereum.
Wie bei allen Hardforks gilt, dass User und Unternehmen ihren Client rechtzeitig upgraden sollten, um nicht versehentlich auf der falschen Chain zu landen. Also: Schaut Anfang Januar nach einem Upgrade von Geth oder Parity, falls ihr einen Ethereum-Node betreibt.
Wir kommen hier nun dazu, was die Hardfork fǘr Änderungen aktivieren wird. Ursprünglich wurde geplant, mit Metropolis den Übergang zu Proof of Stake zu meistern. Dieses Ziel wurde aber (einmal mehr) verschoben. Stattdessen implementiert Metropolis einige eher kleine Features, die im Großen und Ganzen fast nur für Techniker interessant sind. Die Upgrade gehen auf eine monate-, wenn nicht jahrelange Diskussion unter den Entwicklern hervor und adressieren verschiedene kleinere Probleme, die im Umgang mit der Skriptsprache von Ethereum entdeckt wurden.
Mit Constantinople werden die folgenden Upgrades aktiviert:
EIP 145: Bitwise shifting instructions in EVM
„Bitweise Verschiebungen“ ist eine informationstechnische Operation, bei der die Bits – also Einsen oder Nullen – einzeln anstatt als Teil eines Bytes aus acht Bits genommen und um eine oder mehrere Stellen nach rechts oder links verschoben werden. Aus 00111100 wird beispielsweise 01111000.
Bisher hat die virtuelle Maschine von Ethereum ein solches Bitwise-Shifting lediglich als komplexe – und damit teure – Kombination anderer Operationen ermöglicht. Mit EIP145 soll es nun zu einem nativen Befehl werden, der dieselben Gas-Kosten verursacht wie andere native arithmetische Operationen.
Wofür ist das gut? Zum einen vervollständigt das Bitwise-Shifting das Spektrum an Operationen eines Smart Contracts. Zum anderen kommt ein Bitwise-Shifting in manchen kryptographischen Algorithmen vor, die auf diese Weise einfacher in die Ethereum-Smart-Contracts implementiert werden können.
EIP 1014: Skinny CREATE2
Dieses EIP schlägt einen neuen, ergänzenden Code für die CREATE-Funktion vor, durch die Smart Contracts erschaffen werden. Anstatt wie bisher nur drei Argumente aus dem Stack zu nehmen, benutzt CREATE2 vier Argumente. Anstelle einer konkreten Adresse verwendet CREATE2 eine Hash, was die Änderung vergleichbar mit P2SH-Transaktionen bei Bitcoin macht, die an eine Hash eines Skripts anstelle einer Adresse gesendet werden.
CREATE2 erlaubt es, mit Adressen zu interagieren, die noch nicht auf der Ethereum-Blockchain existieren, und hebt damit eine Beschränkung der bisherigen CREATE-Funktion auf. Insbesondere für State Channels – die Offchain-Lösung von Ethereum, vergleichbar mit Lightning – kann dies extrem hilfreich sein. In der Diskussion unter den Entwicklern erfreut sich EIP 1014 dementsprechend einer großen Zustimmung.
EIP 1052: EXTCODEHASH opcode
Dieses EIP führt einen neuen Code ein, der den Keccak256 Hash des Codes eines Smart Contracts wiedergibt. Dies hilft anderen Contracts, dessen Code zu prüfen, ohne diesen selbst zu laden. Dies kann für mehrere Anwendungen nützlich sein, etwa für Smart Contracts, die nur Zahlungen von bestimmten anderen Contracts akzeptieren, oder für Smart Contracts, die eine Art Whitelist von als gültig verifizierten anderen Contracts führen.
Bisher ist es möglich, diese Operation durch einen anderen opcode durchzuführen, doch dies ist teuer, vor allem wenn es um größere Smart Contracts geht. Damit vervollständigt auch EIP 1052 das Spektrum an opcodes.
EIP 1283: Net gas metering for SSTORE without dirty maps
EIP 1283 führt eine neue Methode zur Messung des Gasverbrauchs für den SSTORE opcode ein. Dies ersetzt bereits existierende Methoden, indem es Informationen benutzt, die besser verfügbar sind und den Prozess flüssiger machen. Um ehrlich zu sein, konnte ich aber nicht herausfinden, was der opcode SSTORE wirklich bedeutet.
EIP 1234: Constantinople Difficulty Bomb Delay and Block Reward Adjustment
Wie bei jeder Ethereum-Hardfork enthält auch diese ein EIP, das die Difficulty Bomb entschärft, und verhindert, dass es zu einer Eiszeit der immer länger werdenden Blockinterwalle kommt. Dies ist mehr oder weniger ein Mechanismus, der die Ethereum-Community antreibt, sich innerhalb eines gewissen Zeitfensters auf eine Harfork zu einigen.
Gleichzeitig reduziert dieses EIP aber auch den Block-Reward für die Miner. Anstatt bisher fünf werden sie in Zukunft nur noch zwei ETH je Block erhalten.