By Bitcoin Magasin - 3 måneder siden - Lesetid: 11 minutter
Miner Extractable Value (MEV) og programmerbare penger: The Good, The Bad, and The Ugly
Kjernen til BitcoinSikkerhetsmodellen er avhengig av denne grunnleggende spillteorien – gruvearbeidere, bevæpnet med sine digitale hakker, er i en nådeløs jakt etter profitt. Og det er denne jakten som holder nettverket sikkert. Grunnleggende vaniljeutvinning innebærer å produsere blokker for å tjene blokkbelønninger og transaksjonsgebyrer, men har du noen gang tenkt på at gruvearbeidere kan ha andre måter å hente ut verdi fra blockchain utover denne standard gruveprosessen? Er det andre muligheter for profitt på blokkjeden der gruvearbeidere kan utnytte sin unike posisjon som validatorer?
Hva er MEV?
I bevis-på-arbeid-systemer, "Miner utvinnbar verdi"(MEV) er et begrep som beskriver fortjenesten gruvearbeidere kan tjene ved å manipulere hvordan transaksjoner blir prioritert, ekskludert, omorganisert eller endret i blokkene de utvinner. Siden Ethereums oppgradering til Ethereum 2.0, som flyttet nettverket til proof-of-stake, har konseptet MEV fått et nytt navn og blir nå referert til som "Maximal Extractable Value" i proof-of-stake-systemer. I denne sammenhengen er det blokkforslagsstillerne i stedet for gruvearbeidere – som er validatorene – som har muligheten til å trekke ut denne verdien.
Gruvearbeidere (eller validatorer i Ethereum) har en spesiell rolle i disse nettverkene som bekrefter transaksjoner i blokker. Posisjonen deres plasserer dem et skritt foran andre brukere og lar dem bestemme endelig rekkefølge av transaksjoner i kjeden. Inne i en blokk bestilles transaksjoner vanligvis med de høyeste gebyrene øverst, men av og til åpner det seg muligheter som vil tillate gruvearbeidere å ta en ekstra fortjeneste ved å strategisk endre rekkefølgen på transaksjoner til egen fordel.
Du tenker kanskje, hva er skaden ved å la gruvearbeidere ta litt ekstra fortjeneste fra toppen? Bekymringene begynner først å dukke opp når noen av disse gruvearbeiderne, de som er utstyrt med mer avanserte analytiske evner og kraftigere databehandling, kan identifisere og utnytte MEV-profittmuligheter mer effektivt enn andre.
Disse mulighetene er kanskje ikke alltid lette å få øye på, men jo mer verdi som kan hentes ut gjennom å analysere kjeden, desto sterkere blir insentivet for forskningsteam utstyrt med roboter til å gjøre dette arbeidet. Over tid skaper denne ulikheten i gruvearbeiderens evne til å tjene penger en trend mot sentralisering i nettverket. Til syvende og sist undergraver kjerneprinsippet i blokkjeden: desentralisering.
Dette er akkurat scenariet Bitcoin utviklerfellesskapet har som mål å forebygge når de vurderer hvordan man best kan administrere mer uttrykksevne på Bitcoin.
Hvorfor vil vi ha programmerbare penger?
historisk Bitcoin har operert med relativt enkle smarte kontrakter. Imidlertid sliter denne modellen med selv moderat komplekse transaksjoner. Bitcoin Skriptet kan bare validere autentiseringsdata, det har ikke muligheten til å pålegge fartsgrenser på transaksjoner eller definere myntdestinasjoner fordi Bitcoin Skriptet har ikke tilgang til transaksjonsdata.
Som en litt egen sak, jobbe med og skrive Bitcoin smarte kontrakter kan være utfordrende for brukere som ikke fullt ut forstår sikkerhetskravene. En foreslått funksjon, kjent som "hvelv", tar sikte på å løse noen av disse smertepunktene ved å introdusere tidslåste betingelser for transaksjoner. I hovedsak kan hvelv fungere som en nød "fluktluke", slik at brukere kan få tilbake pengene sine i tilfelle kompromitterte private nøkler. Men funksjoner som dette er bare mulig med mer ekspressivitet.
Ethereum er anerkjent for sine svært uttrykksfulle skriptegenskaper, men det sliter også spesielt med problemet med MEV. De fleste brukere antar generelt det Bitcoin har ingen MEV, i sterk kontrast til Ethereum, som blir sett på som en vill grense for det. Men er dette hele historien?
Motiverer mer uttrykksfulle smarte kontrakter automatisk flere MEV-scenarier?
Det er flere faktorer som bidrar til MEV: (1) mempool-transparens, (2) smart kontrakt-transparens og (3) smart kontrakt-ekspressivitet. Hver av disse faktorene åpner for nye kanaler for MEV, vi vil vurdere hver enkelt her.
The Bad: (1) Mempool Transparency
I likhet med Bitcoin's mempool er mempoolene til de fleste blokkkjeder helt gjennomsiktige, åpne og synlige, slik at alle kan se hvilke transaksjoner som venter før de valideres og bekreftes i en blokk. Bitcoin blokker tar vanligvis omtrent 10 minutter å finne, noe som teoretisk sett gir gruvearbeidere like lang tid til å dra nytte av og gå foran.
I praksis på Bitcoin, dette er ikke en kilde til MEV av flere grunner: (1) Bitcoin transaksjoner er enkle nok til at ingen gruvearbeidere har en betydelig analytisk fordel fremfor andre gruvearbeidere, og (2) Bitcoin transaksjoner utfører vanligvis ikke transaksjoner med flere eiendeler som bytteavtaler eller åpne handler som kan være front-run.
Sammenlign dette med Ethereum, som har noen av de mest komplekse transaksjonene med flere aktiva som foregår på offentlige desentraliserte børser (DEX). Offisielt er blokkeringstiden på Ethereum 15 sekunder, men i perioder med høy mempooltrafikk kan de nødvendige gassavgiftene for umiddelbar blokkinkludering lett overstige hundre dollar. Som et resultat ender transaksjoner med lavere gebyrer opp med å vente minutter eller til og med timer før de blir inkludert i en blokk. Dette kan forlenge vinduet for disse uhyggelige front-run-mulighetene, som allerede er mer utbredt på Ethereum på grunn av den betydelige verdien pakket inn i lag-2-tokens.
Det dårlige: (2) Smart kontrakttransparens
In Bitcoin "smarte kontrakter" er den enkle låse- og opplåsingsmekanismen som er iboende Bitcoin Script. Transaksjonsverdiene, avsender- og mottakerdetaljene er alle offentlig synlige på blokkjeden. Selv om denne fullstendige og nakne åpenheten ikke er ideell fra et personvernperspektiv, er det en del av hvordan Bitcoin lar alle deltakere i nettverket verifisere den fullstendige tilstanden til blokkjeden. Enhver observatør kan analysere disse kontraktsdetaljene, og potensielt åpne døren til visse MEV-relaterte strategier.
Men Bitcoin skriptspråk er, ved design, ganske begrenset, og fokuserer først og fremst på de grunnleggende funksjonene for å sende og motta midler, og validere transaksjoner med signaturer eller hashlocks. Denne enkelheten begrenser iboende omfanget for MEV-strategier på Bitcoin, noe som gjør slike muligheter relativt knappe sammenlignet med andre kjeder.
Plattformer som Ethereum, Solana og Cardano har også helt gjennomsiktige smarte kontrakter, men de avviker fra Bitcoin ved også å ha svært komplekse og uttrykksfulle skriptspråk. Deres Turing-komplette systemer gjør det mulig å teoretisk utføre praktisk talt alle beregningsoppgaver som har kommet til å inkludere: selvutførende kontrakter, integrasjon av data fra den virkelige verden gjennom orakler, desentraliserte applikasjoner (dApps), lag-2-tokens, bytte mellom DEX-er, og automatiserte markedsmakere (AMM). Disse kommer sammen for å skape et rikt miljø for MEV-muligheter. Null kunnskapssikre ordninger, som f.eks STARKex, kunne teoretisk unngå noen av disse problemene, men denne avveiningen ville komme med andre kompleksiteter.
The Ugly: (3) Smart kontraktsekspressivitet
MEV-mulighetene er så lukrative på noen kjeder at det er "MEV-handelsfirmaer" som bringer inn "høy femsifret, midt seks sifre” i overskudd i måneden. Denne trenden har blitt så fremtredende at det er offentlige dashbord dedikert til å skanne etter lønnsomme muligheter på Ethereum og Solana. Deres lønnsomhet genereres ved å utføre hele kurven med MEV-strategier: front-running, sandwich trading, token arbitrage, back-running og likvideringer for å nevne noen. Hver utnytter en annen smart kontraktsdynamikk for profitt.
Noen av disse MEV-strategiene gjelder både lag-1 og lag-2.
Generalisert frontkjøring: Bots skanner mempoolen for lønnsomme transaksjoner, og frontkjører deretter den opprinnelige transaksjonen for profitt.Sandwich-handel: Angriperen legger inn ordre både før og etter en stor transaksjon for å manipulere eiendelsprisene for profitt. Denne strategien utnytter den forutsigbare prisbevegelsen forårsaket av den store transaksjonen.Da er visse strategier unike for lag-2-tokens og smarte kontrakter.
Arbitrage på tvers av forskjellige DEX-er: Bots utnytter prisforskjeller for samme eiendel på forskjellige DEX-er ved å kjøpe lavt på en og selge høyt på en annen. Tilbakeløp i DeFi Bonding Curves: MEV-roboter utnytter forutsigbare prisstigninger i DeFi-bindingskurver ved å plassere transaksjoner umiddelbart etter store, kjøp under opptrender og salg for profitt. DeFi-likvidasjoner: MEV-roboter oppdager muligheter i DeFi-utlån der sikkerheter faller under fastsatte terskler, slik at validatorer kan prioritere sine transaksjoner for å kjøpe den likviderte sikkerheten til lavere priser.Kompleksiteten i kontrakter bidrar vesentlig til utfordringene knyttet til MEV.
Re-entrancy-angrep: Disse angrepene utnytter smarte kontraktslogiske feil, og lar angripere gjentatte ganger ringe en funksjon før den første utførelsen fullføres, og trekke ut midler flere ganger. I MEV-sammenheng kan dyktige enkeltpersoner tjene betydelig på dette, spesielt i kontrakter med betydelige midler. Sammenkoblede kontrakter og Global State: På plattformer som Ethereum kan smarte kontrakter samhandle, noe som fører til kjedereaksjoner på tvers av flere kontrakter fra en enkelt transaksjon. Denne sammenkoblingen muliggjør komplekse MEV-strategier, der en transaksjon i en kontrakt kan påvirke en annen, og tilbyr en kjedereaksjon av profittmuligheter.En del av problemet her er at den totale verdien som skapes av tokens og dApps bygget på lag-2 ofte overstiger verdien av blokkjedens opprinnelige eiendel på lag-1, noe som undergraver validatorenes insentiv til å velge og bekrefte transaksjoner utelukkende basert på gebyrer.
For å gjøre vondt verre, er mange av disse mulighetene ikke strengt begrenset til nettverksvalidatorer. Andre nettverksdeltakere med MEV-skanningsroboter kan konkurrere om de samme mulighetene, noe som forårsaker overbelastning av nettverket, øker gassavgiftene og øker transaksjonskostnadene. Dette scenariet skaper en negativ eksternalitet for nettverket og dets brukere, som alle påvirkes av prisen på høyere transaksjonsgebyrer, ettersom kjeden blir mindre effektiv og dyrere i drift. MEV i DeFi er så vanlig at brukerne nesten har akseptert det som en usynlig skatt på alle i nettverket.
Fremstår disse MEV-mulighetene naturlig som et biprodukt av de svært uttrykksfulle smarte kontraktene, eller finnes det en alternativ vei til drømmen om fullt programmerbare penger?
Foruten å unngå protokoller med svært uttrykksfulle smarte kontrakter og lag-2-tokens, kan brukere unngå noen av disse risikoene ved å bruke protokoller som støtter Konfidensielle transaksjoner, som Liquid, som skjuler transaksjonsdetaljer. Men i motsetning til disse plattformene med mer uttrykksfulle skriptspråk, Bitcoin mangler evnen til å gjøre ting du forventer å kunne gjøre med programmerbare penger.
Det gode: Avveininger til programmerbare penger
Når man vurderer utviklingen av smarte kontrakter på Bitcoin alternativene vi får er å (1) skyve kompleksiteten ut av kjeden, (2) forsiktig integrere smale eller begrensede paktfunksjoner, eller (3) omfavne veien til full ekspressivitet. La oss utforske noen av forslagene fra hvert av disse alternativene.
(1) En ny struktur for kontrakter utenfor kjeden: ALLE FORHÅNDEN
Løsninger utenfor kjeden, som Lightning Network, har som mål å forbedre Bitcoinskalerbarhet og funksjonalitet uten å belaste hovedkjeden, holde transaksjoner raske og lave avgifter. Alt dette høres bra ut så langt.
SIGHASH_ANYPREVOUT (APO) er et forslag til en ny type offentlig nøkkel som tillater visse justeringer av en transaksjon selv etter at den er signert. Det forenkler hvordan transaksjoner oppdateres, slik at transaksjoner lettere kan referere til tidligere (UTXOer), noe som gjør Lightning Network-kanaler raskere, billigere, tryggere og enklere, spesielt når det gjelder å løse tvister.
Under panseret er APO en ny foreslått type sukkflagg. Hver Bitcoin transaksjonen må ha en signatur for å bevise at den er legitim. Når du oppretter denne signaturen, bruker du et "sighash-flagg" for å bestemme hvilke deler av transaksjonen du signerer. Med APO vil en avsender signere alle utdataene og ingen av inngangene, for å forplikte utgangene av transaksjonen, men ikke spesifikt hvilken transaksjon midlene skal komme fra.
APO muliggjør Eltoo, slik at brukere kan utveksle forhåndssignerte transaksjoner utenfor kjeden. APO kan imidlertid utilsiktet introdusere MEV ved å gjøre transaksjoner ombestillingsbare. Så snart du tillater en signatur som binder transaksjonsgrafen, har du muligheten til å bytte ut transaksjoner. Innganger kan byttes, så lenge de nye inngangene fortsatt er kompatible med signaturen.
(2) Pakter: CAT + CSFS og CTV
Pakter vil tillate brukere å kontrollere hvor mynter kan bevege seg, ved å pålegge fartsgrenser eller angi spesifikke destinasjoner for mynter i en transaksjon. Det er to forskjellige kategorier av pakter: rekursive og ikke-rekursive.
Rekursive avtaler lar mynter kontinuerlig gå tilbake til pakter av samme type. Ikke-rekursive avtaler begrenser denne kontrollen til neste transaksjon, og krever at hele den fremtidige banen til myntene defineres på forhånd.CAT + CSFS er et paktforslag som lar skript konstruere eller definere visse deler av en fremtidig transaksjon. CHECKSIGFROMSTACK (CSFS) verifiserer en signatur mot dataene som OP_CAT konstruerte. Ved å bruke CSFS til å kreve at signaturen samsvarer med et dynamisk konstruert format fra OP_CAT, kan vi definere hvordan disse UTXO-ene kan brukes i fremtiden og skape en rekursiv pakt, om enn klønete.
OP_CHECKTEMPLATEVERIFY (CTV) er en måte å lage ikke-rekursive avtaler på. I stedet for å definere og verifisere mot spesifikke deler av en transaksjon, begrenser CTV hvordan midler kan brukes, uten å spesifisere nøyaktig neste adresse de må gå til. Den definerer en "mal" som neste transaksjon må bekrefte.
En risiko med rekursive pakter kan være mulig å skape et scenario der mynter må følge et sett med regler som gjentas om og om igjen, som blir fanget i en løkke uten en måte å komme seg ut av. En annen er at fordi pakter er gjennomsiktige og selvutførende kan de åpnes Bitcoin opp til noen av MEV-strategiene vi ser på andre kjeder.
Hva er de gode nyhetene her?
Den gode nyheten er at alle disse forslagene introduserer ny uttrykksevne!
Nå hva er den maksimale mengden ekspressivitet vi kan få?
(3) Full ekspressivitet: Enkelhet
Enkelhet er et blokkjedebasert programmeringsspråk som skiller seg fra andre skriptspråk ved at det er svært lavt nivå. Det er ikke et språk på toppen av Bitcoin Skript eller en ny opcode i det, det er et alternativ til det. Teoretisk sett er det mulig å implementere alle avtaleforslag innen Simplicity, og implementere mange av de andre kontraktene cypherpunks ønsker fra programmerbare penger, men med mindre av de negative eksternalitetene til Ethereum.
Enkelheten opprettholdes Bitcoinsitt designprinsipp for selvstendige transaksjoner der programmer ikke har tilgang til informasjon utenfor transaksjonen. Simplicity er designet for både maksimal uttrykksevne og sikkerhet, og støtter formell verifisering og statisk analyse, noe som gir brukerne mer pålitelige smarte kontrakter.
Sammenlign Enkelhet med: (1) bitcoin paktforslag og (2) skriptspråk på andre blokkjeder:
Paktforslagene vedr Bitcoin Script, selv om det er mye enklere enn Simplicity, mangler uttrykksevnen til å håndtere gebyrestimering i Script, på grunn av Bitcoinsin mangel på aritmetiske funksjoner. Det er ingen måte å multiplisere eller dividere, ingen betingede eller stable manipulasjoner opkoder; det er også svært vanskelig å anslå et rimelig gebyr knyttet til en gitt kontrakt eller avtale. Brukere ender opp med spaghettikode, der 80 % av kontraktslogikken deres er dedikert til å prøve å bestemme hva gebyrsatsen deres skal være. Å gjøre disse paktskontraktene super kompliserte og vanskelige å resonnere rundt.
EVM har looping-konstruksjoner som gjør statisk analyse av gassbruk svært vanskelig. Mens med Script eller Simplicity, kan du bare telle hver opcode, eller rekursivt legge sammen kostnadene for hver funksjon. Fordi Simplicity har en formell modell, kan du formelt resonnere om programatferd. Du kan ikke gjøre dette med Script selv om du kan gjøre statisk analyse av ressursbruk.
Enkelhet vil gi brukerne den høyeste grad av uttrykksevne, sammen med andre verdifulle funksjoner som statisk analyse og formell verifisering. Brukere motiveres, men ikke begrenset, til å bygge smarte kontrakter som er motstandsdyktige mot MEV. I tillegg kan en kombinasjon av ulike kontrakter sammen gi opphav til MEV, selv når de ikke gjør det hver for seg. Dette representerer en grunnleggende avveining.
Ideen om å komme videre Bitcoinsin smarte kontraktsfunksjonalitet er unektelig lovende og spennende. Men det er viktig å erkjenne at alle disse forslagene har en viss grad av MEV-risiko – om enn sannsynligvis ikke i den grad vi ser på andre kjeder. Som vi tenker på å bringe mer programmerbare penger til Bitcoin, det er spørsmål vi må stille:
Kan vi bygge en protokoll med null MEV-risiko, eller er dette et uoppnåelig ideal? Gitt de iboende risikoene ved MEV i mange forslag, hvilket nivå av MEV-risiko er akseptabelt? Og til slutt, hva representerer det enkleste forslaget som gir størst grad av uttrykksevne ?Hvert forslag har sitt eget sett med fordeler og ulemper. Men uansett hvilken retning vi tar, bør vi alltid ha som mål å prioritere sikkerhet og opprettholde prinsippet om desentralisering.
For detaljerte oppdateringer og mer informasjon, hold øye med Blockstream Research 𝕏 feed.
Dette er et gjesteinnlegg av Kiara Bickers. Uttrykte meninger er helt deres egne og reflekterer ikke nødvendigvis meningene til BTC Inc Bitcoin Blad.
Opprinnelig kilde: Bitcoin magazine