Sandwich-aanvallen kosten Ethereum-gebruikers naar schatting jaarlijks $60 miljoen. Dit fenomeen ontstaat doordat transacties die naar de publieke mempool (de verzamelplaats voor ongebehandelde transacties) worden verzonden, zichtbaar zijn voordat ze worden opgenomen. Hierdoor kunnen MEV-bots (Maximal Extractable Value-bots) de volgorde van transacties beïnvloeden en hun eigen transacties voorrang geven om winst te maken. Ondanks jaren van discussie en diverse pogingen om deze problemen buiten het protocol aan te pakken, blijft het een hardnekkig issue.
Encryptie van mempool-transacties vormt een veelbelovende oplossing om MEV (Maximal Extractable Value) te voorkomen. Hoewel dit idee al geruime tijd actief wordt besproken, is het tot nu toe nog niet op protocolniveau geïmplementeerd. In eerder onderzoek hebben we verschillende voorstellen op basis van drempelencryptie onderzocht, zoals Shutter, Batched Threshold Encryption en Flash Freezing Flash Boys. In dit artikel richten we ons op een meta-voorstel met de naam “Universal Enshrined Encrypted Mempool (EIP-8105)”.
Universal Enshrined Encrypted Mempool, oftewel EIP-8105, is een schema-onafhankelijk ontwerp voor een versleutelde mempool. Dit betekent dat het diverse encryptiemethoden ondersteunt, waaronder drempelencryptie, MPC-commissies (Multi-Party Computation), TEEs (Trusted Execution Environments), vertragingencryptie en volledig homomorfe encryptie. Een nieuwe systeemspecifieke smart contract op de uitvoeringslaag, bekend als de key provider registry, is gepland om dit flexibele ontwerp te faciliteren. Dit zal elke account in staat stellen zich te registreren als een sleutelprovider die decoderingen beheert en onthult op basis van hun eigen voorkeuren voor encryptietechnologie.
EIP-8105 introduceert twee nieuwe transactietypen binnen het EIP-2718-kader: 0x05 voor versleutelde transacties en 0x06 voor ontsleutelde transacties. Een versleutelde transactie is in wezen een envelop met een versleutelde payload en een openbare payload. De openbare payload bevat onder meer de nonce van de envelop, het gasbedrag, gasprijsparameters, het ID van de sleutelprovider, het sleutel-ID en een handtekening. Deze structuur is essentieel om de transactie te koppelen aan de gekozen sleutelprovider, een nonce toe te wijzen en te zorgen dat de gaskosten voor de blokruimte gedekt zijn.
EIP-8105 volgt een uitvoeringsflow in twee stappen. In de eerste stap wordt de versleutelde transactie-inhoud opgenomen in een blok, terwijl de payload zelf verborgen blijft. Sleutelproviders monitoren transacties met versleutelde payloads, verzamelen de relevante sleutel-ID’s en publiceren ofwel de bijbehorende decryptiesleutels of een achterhouddocument zodra de blokbouwer de gegevens publiceert. Zodra de blokbouwer de uitvoeringspayload heeft gepubliceerd, onthult de betreffende sleutelprovider de decryptiesleutel of een achterhouddocument. Een Payload Timeliness Committee (PTC) houdt toezicht op de tijdige publicatie van de decryptiesleutels en valideert deze, met een attestatie of een geldige sleutel beschikbaar was of ontbrak. Als de sleutel beschikbaar is en de decryptie slaagt, wordt de resulterende ontsleutelde transactie in het volgende blok uitgevoerd. Is de sleutel afwezig, ingehouden of mislukt de decryptie, dan wordt de ontsleutelde payload overgeslagen, blijft de envelop echter intact en wordt de transactiekost nog steeds betaald.
Het EIP handhaaft ook een blokstructuur die voorkomt dat MEV-extractietransacties worden ingevoegd tussen decryptie en uitvoering. Ontsleutelde transacties moeten aan het begin van een blok verschijnen, openbare transacties blijven in het midden en versleutelde transacties worden aan het einde geplaatst. Deze volgorde zorgt ervoor dat versleutelde payloads pas na opname kunnen worden onthuld en uitgevoerd, terwijl secundaire MEV wordt voorkomen.
Hoewel EIP-8105 de blootstelling aan MEV aanzienlijk beperkt, behouden eerdere aanbieders in het blok een beperkte mogelijkheid om MEV uit latere transacties te extraheren door selectief hun decryptiesleutels te onthullen of in te houden. Het voorstel probeert dit te mitigeren door sleutelproviders in staat te stellen andere vertrouwde providers aan te wijzen en transacties te ordenen volgens de resulterende vertrouwensstructuur van sleutelproviders.
Versleutelde mempools vormen een steeds belangrijker onderdeel van de routekaart van Ethereum, terwijl het ecosysteem protocollaire manieren zoekt om schadelijke MEV te reduceren. Hoewel EIP-8105 niet langer wordt gepositioneerd als een van de speerpunten voor de eerste hard fork in 2027, blijft het een open concept en blijven de ideeën uit dit voorstel bijdragen aan de bredere inspanningen om een toonaangevend voorstel voor een versleutelde mempool voor de upgrade voor te bereiden.
Hoe beïnvloeden sandwich-aanvallen de Ethereum-netwerkgebruikers?
Sandwich-aanvallen leiden tot aanzienlijke verliezen voor gebruikers door transacties strategisch te manipuleren. MEV-bots plaatsen hun transacties rondom die van andere gebruikers, waardoor de oorspronkelijke transacties op een nadelige manier worden beïnvloed, wat resulteert in financiële schade voor de betrokken leden van de gemeenschap.
Wat is de rol van sleutelproviders in het EIP-8105-protocol?
Sleutelproviders zijn cruciaal binnen het EIP-8105-protocol; zij beheren en onthullen de decryptiesleutels die noodzakelijk zijn voor het ontgrendelen van versleutelde transacties. Hun verantwoordelijkheid is om ervoor te zorgen dat deze sleutels tijdig worden gepubliceerd, zodat de transacties effectief kunnen worden uitgevoerd.
Hoe kan EIP-8105 bijdragen aan de vermindering van MEV?
EIP-8105 biedt een gestructureerde aanpak waarmee versleutelde transacties worden verwerkt zonder dat MEV-extractors zich kunnen mengen tussen decryptie en uitvoering. Dit houdt in dat de kans op manipulatie van transactionele volgorde wordt geminimaliseerd, wat uiteindelijk leidt tot een eerlijker netwerk voor alle gebruikers.
