Ethereum Foundation utforsker transaksjonsassertjoner som lar brukere knytte håndhevbare vilkår til det endelige utfallet av en transaksjon, i stedet for bare å basere seg på godkjenning av den forespurte handlingen. Forskningen, som er en del av initiativet Trillion Dollar Security, retter seg mot et sikkerhetsgap i transaksjoner: En gyldig signatur garanterer ikke at de resulterende saldoene, tillatelsene eller kontokontrollene samsvarer med det signataren hadde til hensikt.

Viktige punkter

  • De foreslåtte kontrollene vil vurdere transaksjonsresultater under kjøringen og reversere handlinger som bryter en signert regel.
  • Beskyttelsen avhenger av regler som er godkjent uavhengig av en eventuell kompromittert transaksjonsbygger.
  • Forskningen kan støtte sikkerhetspolicyer for lommebøker, delegerte agenter og arbeidsflyter for løsnere, men det er ikke varslet noen utrulling.

Innholdsfortegnelse

Hvorfor godkjenning av en transaksjon likevel kan føre til tap

Ethereum utfører forespørselen en bruker autoriserer, mot koden og tilstanden som er tilgjengelig når den kjøres. Disse forholdene kan være annerledes enn det brukeren undersøkte. Implementasjonen av en proxy kan for eksempel endres før utføringen, mens transaksjonsrekkefølgen kan påvirke prisen en swap får.

Foundation skiller mellom villedende forespørsler og uønskede resultater. I angrepene mot Bybit og BadgerDAO viste kompromitterte grensesnitt brukerne signeringsforespørsler som avvek fra det de trodde de godkjente. Derimot kan en forespørsel som vises korrekt, likevel tillate et økonomisk skadelig utfall.

Eksempelet deres er en sikkerhetsswap i Aave og CoW som omfatter rundt 50,4 millioner dollar i aEthUSDT. Begrenset likviditet i AAVE og CoWs gassgrense førte til at et bekreftet pristilbud var på omtrent 329 aEthAAVE. Til tross for en synlig advarsel om en prisvirkning på 99,9 prosent og bekreftelse på at hele verdien kunne gå tapt, signerte brukeren og mottok tokens verdt rundt 36 000 dollar.

Dette skillet forklarer hvorfor bedre beskrivelser av transaksjoner ikke er hele løsningen. Clear Signing hjelper brukerne med å forstå den forespurte handlingen. Simulering anslår virkninger ut fra en valgt tilstand på kjeden. Ingen av delene håndhever alene et uavhengig vilkår for det faktiske utfallet.

ElementDetaljer
TXTRACERegistrerer transaksjonens nettoendringer i tilstanden og genererte hendelser.
TXDIFFHenter start- og sluttverdier for angitte adresser og lagringsplasser.
EVENTDATACOPYKopierer dataene fra en hendelse til minnet for inspeksjon.
ImplementeringsinformasjonDe foreslåtte dataene om tilstandsendringer omfatter nylig utrullede kontrakter og hasher av koden deres.

Hvordan transaksjonsassertjoner skal kontrollere resultatet

En assertjon vil sammenligne transaksjonens start- og sluttilstand ved hjelp av skrivebeskyttet logikk etter at handlingene er utført. Vilkåret vil inngå i transaksjonen og signeres sammen med handlingene. Hvis vilkåret ikke oppfylles, vil handlingene bli rullet tilbake.

Mulige regler omfatter et minste mottatt beløp, en øvre grense for pengebruk, begrensninger på nye token-godkjenninger eller bevaring av en kontos kontrollogikk. Den foreslåtte inspeksjonsfunksjonen går lenger enn saldoer og omfatter lagring, kode, nylig utrullede kontrakter og genererte hendelser.

Eksisterende kontroller i kontrakter beskytter allerede utvalgte utfall. Uniswap kan avvise swaps med et resultat under et angitt minimum, og en Safe-guard kan inspisere kontotilstanden etter utføring. Begrensningen er innsyn: Slike kontroller må forutse hva de skal undersøke, og er som regel avhengige av grensesnittene andre kontrakter tilbyr. En proxy trenger for eksempel ikke å ha en funksjon som viser implementeringsadressen.

Innebygde assertjoner vil gjøre transaksjonens samlede nettoeffekter tilgjengelige for kontroll, også endringer en vanlig guard kanskje ikke vet at den bør se etter. Men større innsyn er bare nyttig hvis regelen er pålitelig. Et ondsinnet grensesnitt kan levere et vilkår som tillater sitt eget angrep, så policyen må komme fra en uavhengig godkjent intensjon, kontopolicy eller beskyttet protokollogikk.

Hva den foreslåtte implementeringen vil gjøre tilgjengelig

Ethereum Foundations kunngjøring om innebygde transaksjonsassertjoner beskriver EIP-7906 som en mulig implementering, ikke som et fastlagt design. Den bygger på rammetransaksjonene i EIP-8141, som organiserer validerings- og handlingstrinn i en bestemt rekkefølge. EIP-8141 er planlagt for Hegotá; EIP-7906 har fått statusen Considered for Inclusion, men er ikke bekreftet for denne oppgraderingen.

Med denne tilnærmingen vil en skrivebeskyttet POST_TX-ramme inspisere resultatene ved slutten av utføringen. De foreslåtte instruksjonene for datatilgang vil bare fungere i denne rammen, ikke i hele EVM.

Informasjonen vil beskrive nettoeffekter, ikke en historikk over hver mellomliggende skriving. En lagringsplass som endres flere ganger, vil vises med start- og sluttverdiene; en plass som gjenopprettes til den opprinnelige verdien, vil ikke vises. Derfor er skillet mellom håndheving av slutt-tilstand og overvåking av hvert utføringstrinn viktig.

Hvis en kontroll mislykkes, vil utføringsdelen bli rullet tilbake, men transaksjonen vil fortsatt inngå i blokken som mislykket. Den som betaler for gassen, må fortsatt betale for gassen som er brukt. Det hindrer at bevisst mislykkede transaksjoner påfører byggere gratis utføringsarbeid.

Hvor lommebøker og protokoller må endres

Forslaget tilbyr en kontrollmekanisme, ikke et automatisk krav om å bruke den. For en brukers transaksjoner må lommeboken gjøre sikkerhetspolicyen til en del av transaksjonsbyggingen, i stedet for å la byggeren utelate den. Policyen kan bygge på lommebokens egen simulering eller gjelde som en fast kontoregel.

For protokoller må beskyttelsen bygges inn i vilkårene for tilgang til en beskyttet funksjon. Det er ikke nok å sende en transaksjon som kan bruke assertjoner: Kallet må inneholde den konkrete kontrollen protokollen krever. Dette vil endre integrasjonskravene for kallere, mens uforanderlige kontrakter som allerede er utrullet, ikke kan få denne adgangskontrollen lagt til i ettertid.

Disse avhengighetene skiller en potensielt kraftig EVM-funksjon fra en garanti for brukeren. Effektiv beskyttelse krever både et godt utformet vilkår og programvare som konsekvent gjør vilkåret umulig å omgå.

Hva agenter og arbeidsflyter for løsner kan få ut av dette

Delegerte agenter kan begrenses ut fra resultater så vel som tillatelser. Begrensninger på hvilke kontrakter en agent kan bruke, eller hvor mye den kan bruke, kan suppleres med krav til hva hver transaksjon etterlater.

Ved utføring basert på løsner kan en protokoll angi et akseptabelt utfall og samtidig la løseren velge ruten. Garantien vil være begrenset til én transaksjon på ett nettverk, ikke en rute som går på tvers av flere kjeder.

Assertjoner kan også kontrollere at arbeidsflyten ryddes opp, for eksempel ved å returnere ubrukte tokens og trekke tilbake gjenværende godkjenninger. Foundation ber om innspill fra team som arbeider med lommebøker og protokoller mens designet videreutvikles, noe som gjør dette til mulige forskningsretninger snarere enn varslede produktfunksjoner.

Konklusjon

Innebygde transaksjonsassertjoner vil flytte deler av sikkerheten ved Ethereum-transaksjoner fra tolkning av en forespørsel til håndheving av resultatet. Den praktiske verdien vil avhenge av pålitelige policyer og at lommebøkene og protokollene som skal anvende dem, tar dem i bruk.

Les flere nyheter

Flere nyheter fra FinanceVelix

Ansvarsfraskrivelse

Denne FinanceVelix-artikkelen gir generell informasjon, ikke personlig tilpasset finansiell, investeringsmessig, juridisk eller skattemessig rådgivning. Kryptopriser kan endre seg raskt, og du kan tape alle investerte midler. Opplysningene gjenspeiler materialet som var tilgjengelig på publiseringstidspunktet, og kan endres. Kontroller viktig informasjon uavhengig, og rådfør deg med en kvalifisert fagperson ved behov. Omtale av en eiendel, et selskap eller en tjeneste er ingen anbefaling.