EIP-8425 beperkt wie kan herstellen na schrappen van `ecRecover` door Ethereum
Het Ethereum-voorstel EIP-8425, op 24 oktober bijgewerkt, beperkt welke accounts in aanmerking komen voor herstel na ECDSA en verwijdert de `ecRecover`-precompile op het moment van de quantum freeze.
Twee commits voor EIP-8425 verschenen op 24 oktober en brachten de hersteilcriteria van het voorstel verder aan. Welke accounts in aanmerking komen voor herstel na ECDSA, welke niet, en waarom dat onderscheid belangrijk is voor iedereen die walletsoftware bouwt.
Het voorstel dateert van 27 september en vereist nog altijd een toekomstige hard fork voordat hier iets van in werking treedt. Het definieert twee hersteiroutes, op basis van commitment en op basis van eigendomsbewijs, en geen van beide werkt voor iedereen. Accounts moeten ofwel geen code bevatten, ofwel een EIP-7702-delegatie-indicator hebben om in aanmerking te komen. Alles met reguliere gedeployde code — inclusief accounts die via EIP-8298 zijn binnengekomen — is expliciet uitgesloten. Voldoet een account aan die vereisten, dan eindigt het oorspronkelijke adres met een quantumbestendige wallet.
Accounts met reguliere gedeployde code zijn uitgesloten van de hersteiroutes die in de EIP worden beschreven. Voor die categorie bestaat er geen hersteiroute.
De fork fungeert als het omslagpunt. De formulering van EIP-8425 laat geen ruimte voor twijfel: voor elk blok waarbijblock.timestamp >= QUANTUM_FREEZE_TIME, zijn transacties die zijn geauthenticeerd met een secp256k1 ECDSA-afzenderhandtekening ongeldig. Bestaande ECDSA-ondertekende transacties werken dan niet meer. Hetzelfde geldt voor op precompiles gebaseerde handtekeningautorisaties.
De tweede commit bepaalt dat de precompile op0x0000000000000000000000000000000000000001 wordt verwijderd op hetzelfde moment dat de ECDSA-freeze ingaat. Volgens de EIP zou het in stand houden van de precompile na de freeze contracten dieecRecover gebruiken voor autorisatie, blootstellen aan vervalste handtekeningen, en weegt het voorkomen van ongeautoriseerde overdrachten van bezit via die route zwaarder dan het behoud van functionaliteit waarvan de authenticatieaannames niet langer opgaan.
Na de fork kunnen handtekeningcontroles op contractniveau die op deze precompile leunen, via die route geen oproepen meer autoriseren.
Geen vastgestelde connectie met de EIP.