De Ethereum Core Developers en de Ethereum Security Community zijn op de hoogte gebracht van een mogelijk probleem rondom de Constantinople upgrade die gepland staat. Of beter gezegd: stond. Dat is in een officieel bericht, als reactie op een blogpost van ChainSecurity, naar buiten gebracht. Op dit moment worden alle mogelijke kwetsbaarheden en problemen in kaart gebracht. Binnenkort kunnen we dus een uitgebreidere update verwachten op de social mediakanalen van Ethereum
Ethereum fork uitgesteld
Het gevolg van deze ‘ontdekking’ is ook de reden achter het uitstellen van de geplande Constantinople fork. Deze zou officieel plaats gaan vinden op 16 januari op het block 7.080.000. Dit uitstel zorgt er ook voor dat iedereen die een Ethereum node heeft, deze moet updaten naar de meest recente versie van de Parity of Geth software VÓÓR het 7.080.000 block. Deze beslissing treft dus node operators, exchanges, miners, wallet services, etc. Deze beslissing zorgt ervoor dat iedereen binnen 32 uur (!) van het bekend maken van het originele bericht, deze update moet hebben doorgevoerd. Op moment dat jij dit leest, zijn daar alweer enkele uren vanaf.
Ben jij die persoon die zich nu aangesproken voelt? Lees dan in het artikel van Ethereum verder wat je moet doen.
Problemen van Constantinople
De eerder genoemde blogpost van ChainSecurity duikt in de mogelijke kwetsbaarheden en hoe deze in een Smart Contract zouden kunnen worden gecontroleerd en opgelost. Kort samengevat: het zou mis kunnen gaan bij de volgende EIP (Ethereum Improvement Proposal): EIP-1283 introduces cheaper gas cost for SSTORE operations
Dit zegt je waarschijnlijk helemaal niets. Maar het houdt in dat enkele Smart Contracts (die al op de chain aanwezig zijn) gebruik kunnen gaan maken voor een bepaald code pattern dat ervoor zou kunnen zorgen dat ze last kunnen krijgen van een zogenoemde re-entrancy attack. Dit zou bij de doorvoering van Constantinople upgrade kunnen gebeuren. Voordat deze update er was (met dus de huidige ‘versie’ van Ethereum), zou dit geen enkel gevaar zijn geweest. Contracten met een grotere kans op dit probleem, zijn contracten die gebruikmaken van een functie transfer () of send (), met daarop een state-changing operation. Een voorbeeld van een dergelijk contract is een contract waarbij twee partijen gezamenlijk geld ontvangen, en vervolgens samen beslissen hoe de fondsen worden gesplitst en hoe de uitbetaling van die fondsen in goede banen geleid kan worden. Het was dus bijna zo geweest dat beide personen niets van dit geld zouden zien…
