Mijnwerkers extraheerbare waarde (MEV) en programmeerbaar geld: het goede, het slechte en het lelijke

By Bitcoin Tijdschrift - 3 maanden geleden - Leestijd: 11 minuten

Mijnwerkers extraheerbare waarde (MEV) en programmeerbaar geld: het goede, het slechte en het lelijke

De kern van BitcoinHet beveiligingsmodel van het bedrijf is gebaseerd op deze fundamentele speltheorie: mijnwerkers, gewapend met hun digitale pikhouwelen, zijn in een meedogenloze jacht op winst. En het is dit streven dat het netwerk veilig houdt. Bij fundamentele vanillemijnbouw gaat het om het produceren van blokken om de blokbeloningen en transactiekosten te verdienen, maar heb je er ooit bij stilgestaan ​​dat mijnwerkers misschien andere manieren hebben om waarde uit de blokken te halen? blockchain voorbij dit standaard mijnbouwproces? Zijn er andere manieren om winst te maken op de blockchain, waar mijnwerkers hun unieke positie als validators kunnen benutten?

Wat is MEV?

In proof-of-work-systemen “Mijnwerker extraheerbare waarde'(MEV) is een term die de winst beschrijft die miners kunnen verdienen door te manipuleren hoe transacties worden geprioriteerd, uitgesloten, herschikt of gewijzigd in de blokken die ze minen. Sinds de upgrade van Ethereum naar Ethereum 2.0, waardoor het netwerk naar proof-of-stake is verhuisd, heeft het concept van MEV echter een nieuwe naam gekregen en wordt het nu in proof-of-stake-systemen ‘Maximal Extractable Value’ genoemd. In deze context zijn het de blokvoorstellen in plaats van de miners – die de validators zijn – die de mogelijkheid hebben om deze waarde te extraheren.

Miners (of validators in Ethereum) spelen een speciale rol in deze netwerken die transacties in blokken bevestigen. Hun positie plaatst hen een stap voor op andere gebruikers en stelt hen in staat de definitieve volgorde van transacties in de keten. Binnen een blok worden transacties doorgaans besteld met de hoogste kosten bovenaan, maar zo nu en dan doen zich mogelijkheden voor waardoor miners een kans kunnen maken. extra winst door de volgorde van transacties strategisch te veranderen in hun eigen voordeel.

Je zou kunnen denken: wat is het kwaad als mijnwerkers een beetje extra winst van de top laten halen? De zorgen beginnen pas de kop op te steken wanneer sommige van deze mijnwerkers, die zijn uitgerust met meer geavanceerde analytische capaciteiten en krachtiger computergebruik, MEV-winstkansen effectiever kunnen identificeren en exploiteren dan anderen.

Deze kansen zijn misschien niet altijd gemakkelijk te herkennen, maar hoe meer waarde er kan worden gehaald uit het analyseren van de keten, hoe sterker de prikkel wordt voor onderzoeksteams die zijn uitgerust met bots om dit werk te doen. In de loop van de tijd creëert deze ongelijkheid in het winstvermogen van mijnwerkers een trend naar centralisatie binnen het netwerk. Uiteindelijk wordt het kernprincipe van de blockchain ondermijnd: decentralisatie.

Dit is precies het scenario Bitcoin De ontwikkelaarsgemeenschap streeft ernaar dit te voorkomen bij het overwegen van de beste manier om meer expressiviteit te beheren Bitcoin.

Waarom willen we programmeerbaar geld?

Historisch Bitcoin heeft gewerkt met relatief eenvoudige slimme contracten. Dit model heeft echter moeite met zelfs redelijk complexe transacties. Bitcoin Script kan alleen authenticatiegegevens valideren, het heeft niet de mogelijkheid om snelheidslimieten op te leggen aan transacties of muntbestemmingen te definiëren Bitcoin Script heeft geen toegang tot transactiegegevens.

Even een wat apart onderwerp, werken met en schrijven Bitcoin Slimme contracten kunnen een uitdaging zijn voor gebruikers die de beveiligingsvereisten niet volledig begrijpen. Een voorgestelde functie, bekend als ‘kluizen’, heeft tot doel een aantal van deze pijnpunten op te lossen door tijdgebonden voorwaarden voor transacties in te voeren. In wezen zouden kluizen kunnen dienen als een ‘ontsnappingsluik’ voor noodgevallen, waardoor gebruikers hun geld kunnen terugkrijgen in het geval van gecompromitteerde privésleutels. Maar dit soort functies zijn alleen mogelijk met meer expressiviteit.

Ethereum wordt algemeen erkend vanwege zijn zeer expressieve scriptmogelijkheden, maar worstelt ook met name met de kwestie van MEV. De meeste gebruikers gaan er over het algemeen van uit dat Bitcoin heeft geen MEV, in schril contrast met Ethereum, dat daarvoor als een wilde grens wordt beschouwd. Maar is dit het volledige verhaal?

Stimuleren expressievere slimme contracten automatisch meer MEV-scenario's?

Er zijn verschillende factoren die bijdragen aan MEV: (1) transparantie van de mempool, (2) transparantie van slimme contracten en (3) expressiviteit van slimme contracten. Elk van deze factoren opent nieuwe kanalen voor MEV, we zullen ze hier allemaal bespreken.

Het slechte: (1) Mempool-transparantie

Like Bitcoin's mempool zijn de mempools van de meeste blockchains volledig transparant, open en zichtbaar, zodat iedereen kan zien welke transacties in behandeling zijn voordat ze in een blok worden gevalideerd en bevestigd. Bitcoin Het duurt doorgaans ongeveer 10 minuten om blokken te vinden, wat mijnwerkers theoretisch dezelfde hoeveelheid tijd geeft om te profiteren en voorop te lopen.

In de praktijk, op Bitcoin, dit is om een ​​paar redenen geen bron van MEV: (1) Bitcoin transacties zijn zo eenvoudig dat geen enkele mijnwerker een significant analytisch voordeel heeft ten opzichte van andere mijnwerkers, en (2) Bitcoin Transacties voeren over het algemeen geen transacties met meerdere activa uit, zoals swaps of open transacties die front-run zouden kunnen zijn.

Vergelijk dit eens met Ethereum, waar enkele van de meest complexe transacties met meerdere activa plaatsvinden op openbare gedecentraliseerde beurzen (DEX's). Officieel is de bloktijd op Ethereum 15 seconden, maar tijdens perioden met veel mempool-verkeer kunnen de vereiste gaskosten voor onmiddellijke blokopname gemakkelijk de honderd dollar overschrijden. Als gevolg hiervan moeten transacties met lagere kosten minuten of zelfs uren wachten voordat ze in een blok worden opgenomen. Dit kan de periode vergroten voor deze snode front-running-mogelijkheden, die nu al vaker voorkomen op Ethereum vanwege de substantiële waarde die is verpakt in laag-2-tokens.

Het slechte: (2) Transparantie van slimme contracten

In Bitcoin ‘slimme contracten’ zijn het eenvoudige vergrendelings- en ontgrendelingsmechanisme dat inherent is aan Bitcoin Script. De transactiewaarden, afzender- en ontvangergegevens zijn allemaal openbaar zichtbaar op de blockchain. Hoewel deze volledige en naakte transparantie vanuit privacyperspectief niet ideaal is, maakt het wel deel uit van hoe Bitcoin Hiermee kunnen alle deelnemers in het netwerk de volledige status van de blockchain verifiëren. Elke waarnemer kan deze contractdetails analyseren, waardoor mogelijk de deur wordt geopend voor bepaalde MEV-gerelateerde strategieën.

De Bitcoin De scripttaal is van nature vrij beperkt en richt zich primair op de basisfuncties van het verzenden en ontvangen van geld, en het valideren van transacties met handtekeningen of hashlocks. Deze eenvoud beperkt inherent de mogelijkheden voor MEV-strategieën Bitcoin, waardoor dergelijke mogelijkheden relatief schaars zijn vergeleken met andere ketens.

Platforms als Ethereum, Solana en Cardano hebben ook volledig transparante slimme contracten, maar daar wijken ze van af Bitcoin door ook over zeer complexe en expressieve scripttalen te beschikken. Hun Turing-complete systemen maken het mogelijk om theoretisch vrijwel elke computertaak uit te voeren, waaronder: zelfuitvoerende contracten, integratie van gegevens uit de echte wereld via orakels, gedecentraliseerde applicaties (dApps), laag-2-tokens, swaps binnen DEX's, en geautomatiseerde marktmakers (AMM's). Deze komen samen om een ​​rijke omgeving voor MEV-mogelijkheden te creëren. Op nul-kennis-proof gebaseerde regelingen, zoals STARKex, zou theoretisch een aantal van deze problemen kunnen vermijden, maar deze afweging zou met andere complexiteiten gepaard gaan.

The Ugly: (3) Smart Contract-expressiviteit

De MEV-mogelijkheden zijn bij sommige ketens zo lucratief dat er “MEV-handelsbedrijven” zijn die “hoge vijf cijfers, midden zes cijfers”in winst per maand. Deze trend is zo prominent geworden dat er openbare dashboards zijn gewijd aan het zoeken naar winstgevende kansen op Ethereum en solarium. Hun winstgevendheid wordt gegenereerd door het uitvoeren van het volledige pakket MEV-strategieën: front-running, sandwich-handel, token-arbitrage, back-running en liquidaties om er maar een paar te noemen. Elk exploiteert een andere slimme contractdynamiek voor winst.

Sommige van deze MEV-strategieën zijn van toepassing op zowel laag 1 als laag 2.

Gegeneraliseerde front-running: Bots scannen de mempool op winstgevende transacties en voeren vervolgens de oorspronkelijke transactie uit om winst te maken. Sandwichhandel: de aanvaller plaatst orders zowel voor als na een grote transactie om de prijzen van activa te manipuleren voor winst. Deze strategie maakt gebruik van de voorspelbare prijsbeweging die wordt veroorzaakt door de grote transactie.

Dan zijn bepaalde strategieën uniek voor laag-2-tokens en slimme contracten.

Arbitrage tussen verschillende DEX's: Bots maken gebruik van prijsverschillen voor hetzelfde activum op verschillende DEX's door op de ene laag te kopen en op een andere hoog te verkopen. Back-running in DeFi Bonding Curves: MEV-bots profiteren van voorspelbare prijsstijgingen in DeFi-obligatiecurves door transacties onmiddellijk te plaatsen na grote, kopen tijdens opwaartse trends en verkopen voor winst. DeFi-liquidaties: MEV-bots ontdekken kansen in DeFi-leningen waarbij de waarde van onderpand onder de vastgestelde drempels valt, waardoor validatoren prioriteit kunnen geven aan hun transacties om het geliquideerde onderpand tegen lagere prijzen te kopen.

De complexiteit van contracten draagt ​​aanzienlijk bij aan de uitdagingen die met MEV gepaard gaan.

Re-entrancy-aanvallen: deze aanvallen maken gebruik van slimme contractlogica-fouten, waardoor aanvallers herhaaldelijk een functie kunnen aanroepen voordat de eerste uitvoering is voltooid, waardoor meerdere keren geld kan worden onttrokken. In de context van MEV kunnen ervaren individuen hier aanzienlijk van profiteren, vooral bij contracten met substantiële fondsen. Onderling verbonden contracten en mondiale staat: op platforms als Ethereum kunnen slimme contracten op elkaar inwerken, wat leidt tot kettingreacties tussen verschillende contracten uit één enkele transactie. Deze interconnectiviteit maakt complexe MEV-strategieën mogelijk, waarbij een transactie in het ene contract een ander contract kan beïnvloeden, wat een kettingreactie van winstmogelijkheden oplevert.

Een deel van het probleem hier is dat de totale waarde die wordt gecreëerd door tokens en dApps die op laag 2 zijn gebouwd vaak groter is dan de waarde van de native asset van de blockchain op laag 1, waardoor de prikkel van de validator wordt ondermijnd om transacties puur op basis van vergoedingen te selecteren en te bevestigen.

Tot overmaat van ramp zijn veel van deze mogelijkheden niet strikt beperkt tot netwerkvalidators. Andere netwerkdeelnemers met MEV-scanbots kunnen strijden om dezelfde kansen, waardoor netwerkcongestie ontstaat, de gastarieven stijgen en de transactiekosten stijgen. Dit scenario creëert een negatief extern effect voor het netwerk en zijn gebruikers, die allemaal worden beïnvloed door de prijs van hogere transactiekosten, omdat de keten minder efficiënt en duurder wordt om te exploiteren. MEV in DeFi is zo gebruikelijk dat gebruikers het bijna hebben geaccepteerd als een onzichtbare belasting voor iedereen in het netwerk.

Komen deze MEV-mogelijkheden op natuurlijke wijze naar voren als een bijproduct van de zeer expressieve slimme contracten, of is er een alternatieve route naar de droom van volledig programmeerbaar geld?

In plaats van protocollen met zeer expressieve slimme contracten en laag-2-tokens te vermijden, kunnen gebruikers een aantal van deze risico’s vermijden door protocollen te gebruiken die ondersteuning bieden Vertrouwelijke transacties, zoals Liquid, die transactiedetails verbergen. Maar in tegenstelling tot deze platforms met expressievere scripttalen, Bitcoin mist het vermogen om dingen te doen die je zou verwachten met programmeerbaar geld.

Het goede: compromissen met programmeerbaar geld

Als we kijken naar de evolutie van slimme contracten Bitcoin de opties die ons worden gegeven zijn (1) de complexiteit buiten de keten te duwen, (2) voorzichtig smalle of beperkte convenantfunctionaliteiten te integreren, of (3) het pad van volledige expressiviteit te omarmen. Laten we enkele voorstellen van elk van deze opties onderzoeken.

(1) Een nieuwe structuur voor off-chain contracten: ANYPREVOUT

Off-chain oplossingen, zoals het Lightning Network, zijn gericht op verbetering Bitcoin's schaalbaarheid en functionaliteit zonder de mainchain te belasten, waardoor transacties snel en de kosten laag blijven. Dit klinkt allemaal goed tot nu toe.

SIGHASH_ANYPREVOUT (APO) is een voorstel voor een nieuw type openbare sleutel waarmee bepaalde aanpassingen aan een transactie mogelijk zijn, zelfs nadat deze is ondertekend. Het vereenvoudigt de manier waarop transacties worden bijgewerkt, waardoor transacties gemakkelijker naar eerdere (UTXO's) kunnen verwijzen, waardoor Lightning Network-kanalen sneller, goedkoper, veiliger en eenvoudiger worden, vooral bij het oplossen van geschillen.

Onder de motorkap bevindt zich APO een nieuw voorgesteld type sighash-vlag. Elk Bitcoin transactie moet een handtekening hebben om te bewijzen dat deze legitiem is. Bij het maken van deze handtekening gebruikt u een ‘sighash-vlag’ om te bepalen welke delen van de transactie u ondertekent. Met APO zou een afzender alle outputs en geen van de inputs ondertekenen om de outputs van de transactie vast te leggen, maar niet specifiek van welke transactie het geld afkomstig zal zijn.

APO maakt het mogelijk Eltoo, waardoor gebruikers vooraf ondertekende transacties buiten de keten kunnen uitwisselen. APO kan echter onbedoeld MEV introduceren door transacties herschikbaar te maken. Zodra u een handtekening toestaat die de transactiegrafiek bindt, heeft u de mogelijkheid om transacties uit te wisselen. Ingangen kunnen worden verwisseld, zolang de nieuwe ingangen nog steeds compatibel zijn met de handtekening.

(2) Convenanten: CAT + CSFS en CTV

Convenanten zouden gebruikers in staat stellen te bepalen waar munten naartoe kunnen worden verplaatst, door snelheidslimieten op te leggen of specifieke bestemmingen voor munten in een transactie in te stellen. Er zijn twee verschillende categorieën convenanten: recursief en niet-recursief.

Recursieve convenanten zorgen ervoor dat munten voortdurend terugkeren naar convenanten van hetzelfde type. Niet-recursieve convenanten beperken deze controle tot de volgende transactie, waardoor het volledige toekomstige pad van de munten vooraf moet worden gedefinieerd.

KAT + CSFS is een convenantvoorstel dat staat scripts toe om bepaalde delen van een toekomstige transactie te construeren of te definiëren. CHECKSIGFROMSTACK (CSFS) verifieert een handtekening aan de hand van de gegevens die OP_CAT heeft geconstrueerd. Door CSFS te gebruiken om te eisen dat de handtekening overeenkomt met een dynamisch geconstrueerd formaat van OP_CAT, kunnen we definiëren hoe deze UTXO's in de toekomst kunnen worden uitgegeven en een recursief convenant creëren, zij het onhandig.

OP_CHECKTEMPLATEVERIFY (CTV) is een manier om niet-recursieve convenanten te creëren. In plaats van specifieke delen van een transactie te definiëren en te verifiëren, beperkt CTV de manier waarop geld kan worden uitgegeven, zonder het exacte volgende adres op te geven waar het naartoe moet gaan. Het definieert een “sjabloon” dat de volgende transactie moet bevestigen.

Eén risico met recursieve convenanten zou mogelijk kunnen zijn om een ​​scenario te creëren waarin munten een reeks regels moeten volgen die zich keer op keer herhalen, die verstrikt raken in een lus zonder een manier om eruit te komen. Een andere is dat, omdat convenanten transparant en zelfuitvoerend zijn, ze zouden kunnen worden geopend Bitcoin tot enkele van de MEV-strategieën die we in andere ketens zien.

Wat is hier het goede nieuws?

Het goede nieuws is dat deze voorstellen allemaal nieuwe expressiviteit introduceren!

Wat is nu de maximale hoeveelheid expressiviteit die we kunnen bereiken?

(3) Volledige expressiviteit: eenvoud

Eenvoud is een op blockchain gebaseerde programmeertaal die verschilt van andere scripttalen doordat deze van zeer laag niveau is. Het is geen taal bovenop Bitcoin Script of een nieuwe opcode erin, het is een alternatief ervoor. Theoretisch is het mogelijk om alle convenantvoorstellen binnen Simplicity te implementeren, en veel van de andere contracten te implementeren die cypherpunks willen met programmeerbaar geld, maar met minder van de negatieve externe effecten van Ethereum.

Eenvoud blijft behouden BitcoinHet ontwerpprincipe van op zichzelf staande transacties waarbij programma’s geen toegang hebben tot informatie buiten de transactie. Simplicity is ontworpen voor maximale expressiviteit en veiligheid en ondersteunt formele verificatie en statische analyse, waardoor gebruikers betrouwbaardere slimme contracten krijgen.

Vergelijk Eenvoud met: (1) bitcoin convenantvoorstellen en (2) scripttalen op andere blockchains:

De convenantvoorstellen over Bitcoin Script, hoewel veel eenvoudiger dan Simplicity, mist de expressiviteit om de schatting van vergoedingen in Script af te handelen, vanwege Bitcoin's gebrek aan rekenkundige functies. Er is geen manier om te vermenigvuldigen of te delen, geen voorwaardelijke opcodes of stapelmanipulaties; het is ook erg moeilijk om een ​​redelijke vergoeding in te schatten die aan een bepaald contract of convenant verbonden is. Gebruikers eindigen met spaghetticode, waarbij 80% van hun contractlogica is bedoeld om te proberen te bepalen wat hun tarief zou moeten zijn. Dit maakt deze convenantcontracten super ingewikkeld en moeilijk om over te redeneren.

De EVM heeft lusconstructies die statische analyse van het gasverbruik erg moeilijk maken. Terwijl je met Script of Simplicity gewoon elke opcode kunt tellen, of de kosten van elke functie recursief kunt optellen. Omdat Simplicity een formeel model heeft, kun je formeel redeneren over programmagedrag. U kunt dit niet doen met Script, ook al kunt u een statische analyse van het bronnengebruik uitvoeren.

Eenvoud zou gebruikers de hoogste mate van expressiviteit bieden, samen met andere waardevolle functies zoals statische analyse en formele verificatie. Gebruikers worden gestimuleerd, maar niet beperkt, om slimme contracten op te stellen die resistent zijn tegen MEV. Bovendien kan een combinatie van verschillende contracten aanleiding geven tot MEV, ook al is dat individueel niet het geval. Dit vertegenwoordigt een fundamentele afweging.

Het idee van vooruitgang BitcoinDe slimme contractfunctionaliteit van het bedrijf is onmiskenbaar veelbelovend en opwindend. Maar het is belangrijk om te erkennen dat al deze voorstellen een zekere mate van MEV-risico met zich meebrengen – zij het waarschijnlijk niet in de mate die we bij andere ketens zien. Terwijl we nadenken over het toevoegen van meer programmeerbaar geld Bitcoin, er zijn vragen die we moeten stellen:

Kunnen we een protocol bouwen zonder MEV-risico, of is dit een onhaalbaar ideaal? Welk niveau van MEV-risico is, gezien de inherente risico's van MEV in veel voorstellen, acceptabel? En ten slotte, wat is het eenvoudigste voorstel dat de grootste mate van expressiviteit biedt? ?

Elk voorstel heeft zijn eigen voor- en nadelen. Ongeacht de richting die we inslaan, moeten we er echter altijd naar streven prioriteit te geven aan veiligheid en het beginsel van decentralisatie hoog te houden.

Houd voor gedetailleerde updates en meer informatie de website in de gaten Blockstream-onderzoek 𝕏voer.

Dit is een gastpost van Kiara Bickers. De geuite meningen zijn volledig die van henzelf en weerspiegelen niet noodzakelijkerwijs die van BTC Inc Bitcoin Tijdschrift.

Originele bron: Bitcoin Magazine