Het benutten van gedeelde beveiliging voor veilige interoperabiliteit tussen ketens

Met aanvallen op blockchain-bruggen die leiden tot miljarden dollars aan verliezen, is het niet verrassend dat discussies over cross-chain security vaak intense debatten genereren. Maar wij geloven in een meer pragmatische aanpak, een aanpak die het analyseren van het probleem van veilige interoperabiliteit vanuit de eerste principes omvat en het ontwerpen van mechanismen om veiligheidsgaranties voor cross-chain applicaties en hun gebruikers te vergroten.

In dit artikel verkennen we het concept van gedeelde beveiliging en leggen we uit hoe gedeelde beveiligingsontwerpen (zoals Lagrange State Committees) de kosten van het bootstrappen van zinvolle veiligheidseigenschappen voor interoperabiliteitsprotocollen kunnen verlagen. Hoewel we ons richten op gedeelde beveiliging voor cross-chain communicatieprotocollen, kan elke gedecentraliseerde applicatie, ongeacht het gebruiksscenario, deze opkomende technologie benutten om voldoende decentralisatie en vertrouwensminimalisatie te bereiken zonder buitensporige operationele overhead te veroorzaken.

Een informele introductie tot gedeelde beveiliging

"Gedeelde beveiliging" verwijst naar beveiliging die een protocol ontleent aan een externe bron. In een gedeeld beveiligingsschema worden bronnen die door deelnemers in één protocol worden gebundeld (bijvoorbeeld kapitaal of rekenkracht) gebruikt om economische beveiliging voor een ander protocol te creëren. Gedeelde beveiliging verschilt van het standaardmodel, waarbij elk netwerk verantwoordelijk is voor zijn eigen beveiliging.

Publieke blockchains zoals Bitcoin en Ethereum combineren bijvoorbeeld consensusalgoritmen met Sybil-resistentiemechanismen, zoals Proof of Work of Proof of Stake, om de levendigheid te garanderen en tegelijkertijd de kosten van vijandige aanvallen te verhogen (bijvoorbeeld Sybil-aanvallen , aanvallen op lange afstand , eclipsaanvallen , time-bandit-aanvallen en omkopingsaanvallen ).

Hoewel gedeelde beveiligingsschema's op verschillende manieren werken, draaien de doelen meestal om twee doelstellingen:

• Verhogen van de kapitaalefficiëntie in blockchainnetwerken zonder dat er extra risico's ontstaan (risicostapeling) of dat er extra beveiligingsveronderstellingen worden geïntroduceerd.
• Verbetering van de capaciteit van blockchainnetwerken (met name opkomende protocollen) om zich te verdedigen tegen ongeldige statusovergangen, reorganisaties, censuurresistentie en andere aanvallen op de levendigheid en veiligheid van een protocol.

Gedeelde beveiliging is niet bepaald een nieuw concept; merge-mining werd bijvoorbeeld in 2011 geïntroduceerd, waardoor miners dezelfde cryptografische Proof-of-Work (PoW) konden gebruiken om blokken te creëren op twee (of meer) verschillende PoW-ketens die de Nakamoto-consensus implementeerden. Hierdoor konden nieuwere PoW-gebaseerde protocollen (zoals Namecoin en Rootstock), waarvan de native tokens niet genoeg waarde hadden verworven om significante interesse van miners te wekken, beveiliging delen door computationele bronnen die zijn toegewezen aan het beveiligen van het Bitcoin-netwerk opnieuw te gebruiken om de moeilijkheidsgraad van blokken op het nieuwe protocol te vergroten.

Dat gezegd hebbende, wordt merge mining gezien als een zwakke vorm van economische zekerheid voor gedecentraliseerde netwerken vanwege het gebrek aan verantwoorde veiligheid. In de academische literatuur weerspiegelt verantwoorde veiligheid het vermogen van een protocol om knooppunten te detecteren die (aantoonbaar) protocolregels overtreden en kwaadaardig gedrag te bestraffen. Bijvoorbeeld, Proof of Stake-gebaseerde protocollen vereisen dat knooppunten collateral vergrendelen (door het native token van het protocol te staken) voordat ze deelnemen aan consensus, en kunnen deze collateral vernietigen/bevriezen ("slash") als er bewijs is van wangedrag van een validator.

In het geval van merge mining kunnen nodes die opzettelijk ongeldige blokken accepteren op de merge-mined chain niet betrouwbaar worden gedetecteerd. Bovendien is het onmogelijk om genoemde nodes te straffen (zelfs als het mogelijk zou zijn om ze te identificeren), omdat dat een drastische maatregel zou vereisen zoals het verbranden of vernietigen van mininghardware. Hoewel de dreiging dat de token van de merge-mined chain waarde verliest door aanvallen op de beveiliging ervan voldoende lijkt om Byzantijns gedrag te ontmoedigen, hebben kwaadwillende miners minder te verliezen, omdat de waarde van de oorspronkelijke chain (bijv. Bitcoin) waarschijnlijk niet wordt beïnvloed.

Moderne ideeën over gedeelde beveiliging zijn niet alleen geëvolueerd om verantwoorde veiligheid te incorporeren, maar zijn ook overgegaan op het gebruik van een andere investeringseenheid, kapitaal, als basis voor gedeelde beveiliging. In dit ontwerp is er een basisprotocol dat beveiliging biedt voor andere PoS-protocollen die erop zijn gebouwd; knooppunten sluiten zich eerst aan bij het primaire netwerk (door het native token van het netwerk als stake te vergrendelen) voordat ze deelnemen aan het beveiligen van het secundaire netwerk.

Dit ontwerp kan verschillende vormen aannemen:

• Validators nemen tegelijkertijd deel aan het primaire netwerk en het secundaire netwerk
• Een subset van validatoren (uit het primaire netwerk) wordt willekeurig geselecteerd om het secundaire netwerk te valideren en te beveiligen
• Het secundaire netwerk wordt beveiligd door een onafhankelijke set validators die op het primaire netwerk zijn aangesloten
• Validators van het primaire netwerk delegeren het ingezette kapitaal opnieuw aan validators op het secundaire netwerk

Ongeacht de implementatiedetails is het cruciale detail voor de hierboven beschreven gedeelde beveiligingsschema's dat het basisprotocol de middelen moet hebben om validators te straffen die kwaadaardig handelen op het secundaire netwerk. Aangezien er minder kapitaal is dat het secundaire netwerk beveiligt, is de mogelijkheid dat een kwaadaardige supermeerderheid het protocol kapt een reële zorg.

De oplossing is om ervoor te zorgen dat een of meer eerlijke deelnemers (die de minderheid vormen) de meerderheid verantwoordelijk kunnen houden door een geschil te starten en bewijs van protocol-schendend gedrag te publiceren op de basislaag. Als het basisprotocol (dat optreedt als een "rechter") dat bewijs accepteert, kunnen de oneerlijke partijen worden gestraft door het onderpand (als een obligatie) op het primaire netwerk te schrappen. Belangrijk is dat de basislaag alleen het verstrekte bewijs hoeft te verifiëren en geen aanvullende consensus hoeft uit te voeren voordat geschillen worden opgelost, wat de coördinatie-overhead vermindert.

Het subtielere punt is dat wangedrag aan een partij moet worden toegeschreven om slashing-mechanismen effectief te laten zijn. In PoS-gebaseerde netwerken moeten validators een publiek-private sleutelpaar genereren dat dient als een unieke cryptografische identiteit binnen het consensusprotocol. Tijdens routinematige taken, zoals het voorstellen van blokken of het bevestigen van (de geldigheid van) blokken, ondertekent een validator de blokgegevens met zijn privésleutel, waardoor deze effectief aan die keuze worden gebonden.

Hierdoor is het mogelijk om een validator te testen op verschillende acties die zouden worden opgevat als een aanval op de veiligheid of de levendigheid van het protocol (of beide in sommige gevallen):

• Het ondertekenen van twee conflicterende blokken in dezelfde periode (formeel bekend als “equivocatie”)
• Het ondertekenen van een ongeldig blok (tijdens een voorstel of attestatie)
• Censureren van één of meer transacties
• Verbergen van een deel of alle delen van de gegevens van een blok

Terwijl de eerste twee overtredingen op dezelfde manier kunnen worden gedetecteerd (door de openbare sleutel van een validator uit zijn handtekening te halen), vereisen de laatste twee andere mechanismen zoals inclusielijsten en uitwiscodes . In alle gevallen maakt het gebruik van cryptografie betrouwbare detectie en bestraffing van kwaadaardig gedrag mogelijk dat bepaalde gewenste beveiligingseigenschappen in een protocol zou kunnen aantasten, zoals weerstand tegen censuur en geldigheid van transacties. Dit biedt enige context over de betekenis van "crypto-economische beveiliging", wat het combineren van cryptografische mechanismen met economische prikkels inhoudt om gedecentraliseerde netwerken te beveiligen.

We kunnen dit idee illustreren - en vergelijken met merge-mining - met het voorbeeld van een nieuwe PoS-blockchain die de beveiliging van Ethereum deelt. Ons toyprotocol heeft de volgende eigenschappen (let op, dit is een te simplistisch voorbeeld dat ter illustratie wordt gebruikt):

• Node-operators moeten een bepaald bedrag aan ETH-tokens als onderpand storten in een Ethereum smart contract voordat ze zich als validatoren in het PoS-netwerk kunnen aanmelden
• Tijdens tijdperken sturen blokvoorstellers op het PoS-protocol hashes van blokheaders (die handtekeningen van validators bevatten) naar Ethereum door deze op te slaan in een slim contract
• De beveiliging is gebaseerd op fraudebewijzen : de bovenliggende keten (Ethereum) verifieert geen staatsovergangen, maar kan wel een tegenvoorbeeld verifiëren dat aantoont dat een bepaalde staatsovergang ongeldig is.
• Een on-chain slashing-mechanisme wordt geactiveerd als een bepaalde statusovergang door een of meer partijen wordt betwist

Stel nu dat een kwaadaardige meerderheid van nodes op het secundaire netwerk samenspant om een ongeldig blok te finaliseren om fondsen te stelen die in het bridgecontract zijn gestort. In dit scenario zou een eerlijke validator het on-chain slashing-mechanisme op Ethereum activeren door een fraudebewijs te publiceren en protocol-schendende validators te identificeren. Als protocolregels toestaan om de volledige stake van een validator te slashen, dan zijn de kosten van het corrumperen van de PoS-chain evenredig met het bedrag dat door de meerderheid van de validators is gestaked.

Dit voorbeeld laat zien hoe verantwoorde veiligheid gedeelde beveiligingsontwerpen ondersteunt en effectief kleinere netwerken in staat stelt om beveiligd te worden door grotere protocollen die aanzienlijke economische veiligheid hebben gecreëerd en hogere niveaus van decentralisatie en vertrouwenloosheid bieden. We kunnen ook zien dat Proof-of-Stake-mechanismen leiden tot gedeelde beveiligingsontwerpen met sterkere noties van veiligheid vergeleken met merge-mining (dat rekenkracht gebruikt als basis voor economische veiligheid).

Bovendien introduceert het het idee van een nieuw protocol dat de token van een ander netwerk gebruikt voor staking om het "bootstrapping-probleem" te verzachten (waarbij een nieuw blockchainprotocol een lage economische veiligheid heeft omdat zijn token niet genoeg waarde heeft verworven). Hoewel het bootstrapping-probleem kan worden opgelost met benaderingen, zoals merge-mining, die hardware-investeringen gebruiken als een eenheid van economische veiligheid, is dit type gedeelde veiligheid om bepaalde redenen suboptimaal (waarvan we er eerder een aantal hebben geïdentificeerd):

• Kapitaalinvesteringen, die verondersteld worden aanzienlijke kosten op te leggen aan kwaadaardig gedrag voor het valideren van nodes, zijn impliciet en moeilijk te benutten voor economische zekerheid. Het expliciet maken van kapitaalinvesteringen in het geval van PoW merge-mining zou een drastische maatregel vereisen, zoals het vernietigen van mininghardware in het geval van waarschijnlijk kwaadaardig gedrag, wat onrealistisch is in echte situaties en moeilijk te benutten.
• Merge-mining (of een gedeeld beveiligingsontwerp waarbij deelname aan consensus is gekoppeld aan de actieve infrastructuur) is moeilijk te schalen. Er is bijvoorbeeld een bovengrens aan het aantal PoW-ketens dat men gelijktijdig kan merge-minen voordat de ROI van een miner begint af te nemen.

Daarentegen hebben PoS-gebaseerde gedeelde beveiligingsschema's, waarbij kapitaalinvesteringen als investeringseenheid worden gebruikt, bepaalde eigenschappen die nuttig zijn voor het efficiënt en effectief oplossen van het probleem van het opstarten van nieuwe netwerken:

• Kapitaalinvestering is expliciet (stakers investeren kapitaal in het kopen van tokens om te voldoen aan de vereisten voor onderpand) en kan worden ingezet voor sterke en concrete garanties van economische zekerheid. Het is bijvoorbeeld gemakkelijk te visualiseren dat een protocol waarschijnlijk veiliger is wanneer het 1 ETH aan stake heeft die 0,9 ETH aan transacties veiligstelt dan wanneer 0,9 ETH aan stake 1 ETH aan transacties veiligstelt.
• Omdat deelname aan consensus gekoppeld is aan ‘zuivere’ kapitaalinvesteringen, is het gemakkelijker om de economische veiligheid op te schalen en validators meerdere protocollen te laten beveiligen zonder dat er sprake is van buitensporige coördinatie-overhead (vooral wanneer de hardwarevereisten laag zijn).

Niettemin zal elke aanpak nadelen hebben en shared-security-via-staking is geen uitzondering; bijvoorbeeld, het bepalen van hoeveel collateral validators in een PoS-protocol moeten stoppen is een moeilijk op te lossen probleem. We zullen dit in context plaatsen door deze uitspraak uit de voorgaande paragraaf te overwegen: " Het is gemakkelijk te visualiseren dat een protocol waarschijnlijk veiliger is wanneer het 1 ETH aan stake heeft die 0,9 ETH aan transacties veiligstelt dan wanneer 0,9 ETH aan stake 1 ETH aan transacties veiligstelt. "

Hoewel deze bewering redelijk klinkt, blijkt uit een nadere analyse hoe moeilijk het is om een optimale obligatievereiste te kiezen:

• Als er 1 ETH van validators wordt gevraagd om activa ter waarde van 0,9 ETH veilig te stellen, vermindert dit de kapitaalefficiëntie en leidt dit tot overcollateralisatie.
• Het beveiligen van transacties ter waarde van 2 ETH met een belang ter waarde van 1 ETH vermindert de economische bandbreedte (of 'hefboomwerking') in een PoS-blockchain en resulteert in ondercollateralisatie.

In een ideaal scenario zou een protocolontwerper de voorkeur geven aan 1 ETH aan stake om 1 ETH aan transacties veilig te stellen. Maar dergelijke evenwichten zijn moeilijk te bereiken in real-world omstandigheden om verschillende redenen; bijvoorbeeld, de hoeveelheid kapitaal die per tijdseenheid moet worden veiliggesteld (een functie van de marginale waarde van transacties per blok/tijdperk) is dynamisch. Dit maakt het instellen van de ideale obligatie in een PoS-systeem een zeer moeilijk mechanismeprobleem en een belangrijke overweging voor op stake gebaseerde gedeelde beveiligingsschema's, zoals restasting (die we in de volgende sectie bespreken).

Gedeelde beveiliging tegen herinzetten en controles

Opnieuw inzetten

Retaking is geworteld in rehypothecation — een praktijk in traditionele financiën waarbij een kredietverstrekker activa (eerder verpand als onderpand door een kredietnemer) gebruikt als onderpand om een nieuwe lening veilig te stellen. Hierbij neemt de nieuwe wederpartij rechten op het oorspronkelijke onderpand aan, zodat als de entiteit die de nieuwe lening heeft afgesloten in gebreke blijft met de terugbetaling, deze de activa kan veilen om fondsen terug te vorderen.

Als het correct wordt geïmplementeerd, kan herhypothekering nuttig zijn. Om te beginnen zorgt het voor een hogere kapitaalefficiëntie en liquiditeit door activa te hergebruiken, die anders ongebruikt zouden blijven, om kortetermijnfinanciering veilig te stellen voor winstgevende activiteiten. Als de winst van het aangaan van een lening de waarde van het herhypothekeerde onderpand overtreft, profiteren alle betrokken partijen (de oorspronkelijke lener, de kredietverstrekker en de kredietverstrekker van de kredietverstrekker).

Herhypothekering brengt veel risico met zich mee (een van de redenen waarom de praktijk grotendeels uit de gratie is geraakt bij TradFi-instellingen), met name voor de oorspronkelijke lener die rechten op zijn activa kan verliezen wanneer er een liquidatie plaatsvindt. De kredietverstrekker die onderpand hergebruikt, loopt ook risico, vooral als hij leners moet terugbetalen nadat een nieuwe wederpartij gedeponeerd onderpand in beslag heeft genomen vanwege wanbetaling van leningen.

Het andere risico is er een die we eerder kort hebben beschreven en draait om de afweging tussen overcollateralisatie en ondercollateralisatie. In het eerder benadrukte voorbeeld, als Bank B (de bank van John) een overmatig gehevelde positie aangaat - waarbij het meer leent dan de waarde van Johns onderpand - en verlies lijdt, wordt het moeilijk om de lening van Bank B terug te betalen (of Johns activa terug te geven). Bank B kan zich tegen dit randgeval beschermen door Bank A (de bank van John) te vragen minder te lenen dan de waarde van Johns onderpand; dat vergroot echter de kapitaalinefficiëntie voor Bank A en vermindert de winsten van het herhypothekeren van Johns onderpand in de eerste plaats.

Dezelfde voor- en nadelen gelden ook voor resttaking. Voordat we verder gaan, is het belangrijk om een belangrijk detail te verduidelijken: de stake van een restaker gaat altijd eerst door het basisprotocol. Een restaker op Ethereum moet bijvoorbeeld 32 ETH storten in het Beacon Chain-contract of ETH delegeren aan een validator die wordt beheerd door een stakingservice, afhankelijk van of er native resttaking of liquid resttaking wordt gebruikt.

Op hoofdlijnen omvat restaking in het geval van Ethereum het volgende:

#1: Het geven van eigendomsrechten (of een claim) op gestakete ETH aan het resttakingprotocol

Bij native resttaking moet een validator zijn/haar opnameadres wijzigen in een smart contract dat wordt beheerd door het resttaking-protocol. In plaats van dat fondsen direct naar de validator gaan nadat ze de Beacon Chain hebben verlaten, gaat de stake eerst door het resttaking-protocol voordat deze bij de validator terechtkomt (we zullen snel genoeg zien waarom dit het geval is).

Het is ook mogelijk om fungibele representaties (derivaten) van gestakete ETH te deponeren in de smart contracts van het resttaking protocol (liquid resttaking). Dergelijke tokens, ook wel "liquid staked tokens" genoemd, worden uitgegeven door staking-as-service operators (bijv. RocketPool, Lido, Coinbase, etc.) en vertegenwoordigen een claim op een deel van de ETH die door een validator is gestaket (inclusief opbrengst van beloningen) en kunnen worden ingewisseld in een verhouding van 1:1 voor native ETH tokens.

#2: Instemmen met extra slashing-voorwaarden die worden afgedwongen door het restasting-protocol

Een resttakingprotocol functioneert doorgaans als een "middleware" waar verschillende gedecentraliseerde netwerken en applicaties op kunnen aansluiten voor economische veiligheid. Dit omvat doorgaans protocollen die een vorm van validatie door een groep partijen vereisen, bijvoorbeeld een oraclenetwerk, maar waarvan de native token niet genoeg waarde heeft verzameld om te worden gebruikt in een Proof of Stake-setting.

In plaats van een nieuwe validatorset vanaf nul te bouwen, kunnen dergelijke applicaties de services van bestaande validators inschakelen via een resttakingprotocol. Services kunnen unieke slashingvoorwaarden specificeren voor de herhypothekeerde onderpanden van een validator, die het resttakingprotocol kan afdwingen omdat het nu de opname van de validator controleert, waardoor de drempel voor economische zekerheid wordt verlaagd.

Een belangrijke opmerking: AVS-slashingvoorwaarden zijn onafhankelijk van slashingvoorwaarden die worden afgedwongen door de Beacon Chain-consensus van Ethereum, dus de ETH-stake van een validator kan worden geslasht, zelfs als ze geen slashable-overtreding op Ethereum zelf hebben begaan. Dit kan leiden tot wat we omschrijven als 'risicostapeling': in ruil voor een hogere kapitaalefficiëntie erft het primaire netwerk extra risico dan het anders zou doen. (Risicostapeling heeft ook gevolgen voor het kern-EigenLayer-protocol zelf, zoals we later zullen zien.)

#3: Extra beloningen ontvangen

Voor het opnieuw staken moet u een aanzienlijk risico nemen (een opnieuw stakende validator kan bijvoorbeeld per ongeluk worden geslasht vanwege een bug in het on-chain slashing-mechanisme). Maar net zoals herhypothekering liquiditeit ontsluit in TradFi, kan opnieuw staken de kapitaalefficiëntie in PoS-ecosystemen verbeteren en een hoger dan gemiddeld rendement genereren voor stakers.

Dit is gebaseerd op het feit dat services die restacked capital voor beveiliging hebben gebruikt, validators moeten belonen voor hun services. Ter illustratie: een restacked validator die deelneemt aan een oracle-netwerk ontvangt vergoedingen voor het valideren van oracle-updates, waarbij de betaling afkomstig is van andere externe applicaties die afhankelijk zijn van de services van de oracle. Omdat validators nog steeds beloningen ontvangen van de Beacon Chain, maakt restacking het mogelijk om inkomsten te verdienen uit meerdere PoS-protocollen zonder dat er nieuw kapitaal opnieuw hoeft te worden ingezet in een nieuw ecosysteem.

Hoewel we ons in dit voorbeeld richten op Ethereum resttaking, hebben andere Proof of Stake-protocollen ook varianten van resttaking geïmplementeerd om soortgelijke doelen te bereiken (de kosten van het lanceren van nieuwe protocollen/applicaties verlagen, de kapitaalefficiëntie verbeteren en de economische veiligheid opschalen). In feite bespreekt de volgende sectie EigenLayer, het belangrijkste resttaking-protocol van Ethereum, voordat we verdergaan met het benadrukken van resttaking in andere ecosystemen:

EigenLayer

EigenLayer is een resttakingprotocol dat is gemaakt om de economische veiligheid van Ethereum uit te breiden om nieuwe gedistribueerde applicaties, netwerken en protocollen te beveiligen (die het collectief beschrijft als "Actively Validated Services" of kortweg AVS's). Als u de vorige sectie hebt gelezen waarin het voorbeeld van resttaking op Ethereum wordt beschreven, dan begrijpt u de activiteiten van EigenLayer op hoog niveau al; we zullen echter wat meer details opnemen voor de context.

Na het opnieuw innemen van ETH (door opnamegegevens die gekoppeld zijn aan een validator te verwijzen naar smart contracts die worden aangestuurd door EigenLayer), moet een validator taken uitvoeren die zijn gespecificeerd door de AVS die hij wil bedienen. Als een AVS bijvoorbeeld een sidechain is, moet de opnieuw ingenomen validator clientsoftware voor de sidechain uitvoeren om transacties uit te voeren en blokken te verifiëren, terwijl hij beloningen verdient voor het correct uitvoeren van deze taken. In bredere zin kunnen taken variëren, afhankelijk van de aard van de AVS:

• Gegevens opslaan in een gegevensbeschikbaarheidsnetwerk

• Goedkeuren van stortings- en opnametransacties voor een cross-chain-brug of goedkeuren van berichten voor een cross-chain-berichtenprotocol

• Genereren en verifiëren van zero-knowledge-bewijzen voor een privacygerichte applicatie of afgeschermd betalingsnetwerk

• Opslaan en verifiëren van blokheaders en uitvoeren van relayers/oracles voor interoperabiliteitsprotocollen tussen ketens

  
  

Oplettende lezers zullen twee dingen opmerken: (a) taken die door een AVS worden gespecificeerd, kunnen behoorlijk willekeurig zijn (b) verschillende AVS-gespecificeerde taken vereisen verschillende niveaus van investering en inspanning. Om het laatste punt te illustreren, is het mogelijk om je voor te stellen dat het opslaan van blokheaders in een cross-chain protocol minder schijf-/geheugenruimte vereist vergeleken met het opslaan en provisioneren van gegevens in een data availability network (zelfs waar technieken zoals data availability sampling de opslaglasten op individuele knooppunten verminderen).

Dit is een van de redenen waarom EigenLayer het mogelijk maakt dat restaked validators de uitvoering van AVS-gespecificeerde taken delegeren aan een andere partij (een operator) die de beloningen die zijn verdiend met de AVS deelt met de validator. Deze aanpak kent verschillende risiconiveaus voor restaked validators, afhankelijk van de mate waarin de last van slashing (wat kan gebeuren als de operator AVS-taken niet correct uitvoert) wordt gedeeld tussen de restaked validator en de operator van derden.

Elke AVS specificeert een set voorwaarden waaronder de inzet van een EigenLayer restaker kan worden geslasht. Bijvoorbeeld, een data availability network dat Proof of Space/Storage-mechanismen implementeert, kan operators slashen die er niet in slagen om data op te slaan voor de overeengekomen duur. Slashing veroorzaakt bevriezing van de operator binnen EigenLayer, wat verdere deelname aan een of meer actief gevalideerde services voorkomt, en uiteindelijk vermindering van het ETH-saldo van de validator.

Om slashing te laten plaatsvinden, moet de overtreding bewijsbaar zijn - wat het basisprotocol (in dit geval Ethereum) in staat stelt om geschillen te beslechten en de oneerlijke partij te straffen. Het huidige ontwerp van Ethereum staat toe om tot 50% van de inzet van een validator (16 ETH) te slashen, wat EigenLayer het recht geeft om de resterende 50% (16 ETH) te slashen in het geval dat een operator de regels van de AVS overtreedt tijdens het uitvoeren van taken.

De slashing-mechanismen van EigenLayer wijzen ook op een subtiel risico van resttaking: als je door één service wordt geslasht, wordt het algehele saldo van een validator in EigenLayer smart contracts en Ethereum's Beacon Chain verlaagd. Belangrijk is dat er echter een edge-case-scenario ontstaat wanneer slashing optreedt vanwege een bug in de slashing-logica van een bepaalde AVS en niet als gevolg van een aantoonbare overtreding. In dit geval zou het verlies van beloningen van het valideren van de belangrijkste Ethereum-keten (waarvan wordt aangenomen dat deze hoger is dan de beloningen van het valideren van de AVS) de ROI van resttaking suboptimaal maken vanuit het perspectief van een validator.

Een ander risico met EigenLayer-stijl resttaking betreft het risico van validator overcollateralization en undercollateralaztion en het concept van risk stacking. Uit het vorige voorbeeld van rehypothecation zien we dat de partij die het onderpand herhypothekeert, tegelijkertijd schulden kan hebben bij de eerste lener (wiens onderpand wordt gebruikt om een nieuwe lening af te sluiten) en de laatste kredietverstrekker in de keten (die een claim heeft op het onderpand dat door de oorspronkelijke lener is verpand).

Een vergelijkbare dynamiek kan zich afspelen in restastingconstructies zoals EigenLayer als een restastingvalidator (opzettelijk of opzettelijk) tegelijkertijd slashable-delicten begaat op Ethereum's Beacon Chain en een of meer AVS'en. Afhankelijk van waar de eerste slashing plaatsvindt, hebben andere AVS'en mogelijk geen stake meer om te slashen, wat effectief een risicoloze aanval op applicaties mogelijk maakt die zijn beveiligd door EigenLayer.

Het EigenLayer-team heeft deze aanvalsvector erkend (zie Bijlage B: Crypto-economische risicoanalyse van de EigenLayer whitepaper ) en heeft verschillende stappen ondernomen om dit risico aan te pakken. Dit omvat het verstrekken van een formele heuristiek voor het beoordelen van staker undercollateralization en overcollateralization in AVS's, en het aangeven van plannen om adviesinformatie te verstrekken aan AVS-ontwikkelaars via een risicomanagementdashboard bij de lancering.

Polkadot Parachains

Hoewel Polkadot vooral bekend staat om het mogelijk maken van interoperabiliteit tussen heterogene blockchains, vertrouwt het zwaar op gedeelde beveiliging. Gedeelde beveiliging is in feite de reden dat verschillende ketens in Polkadots ecosysteem berichten kunnen uitwisselen zonder vertrouwensaannames te introduceren of beveiligingsrisico's te lopen.

Op Polkadot worden subsets van validators (die DOT-tokens op de Relay Chain hebben ingezet) willekeurig toegewezen aan parachains (denk aan "child chains") om blokken te verifiëren - en het bijbehorende bewijs van geldigheid (PoV) - geproduceerd door de collator van elke parachain. Een collator is de node die verantwoordelijk is voor het uitvoeren van de transacties van een parachain en creëert een "para-block" dat naar de validatorgroep van de parachain wordt gestuurd voor verificatie.

Omdat het verifiëren van de PoV van een blok rekenintensief is, ontvangen para-validators (de naam voor validators die zijn toegewezen aan een parachain) extra beloningen voor deze taak. Blokken die zijn goedgekeurd door para-validators, of nauwkeuriger gezegd, cryptografische toezeggingen aan die blokken, worden verzonden voor opname in de Relay Chain (denk aan de "ouderketen"). Een parachain-blok wordt definitief als een blok dat ernaar verwijst, is goedgekeurd door een meerderheid van de resterende set validators op de Relay Chain.

Het laatste punt is vrij belangrijk: aangezien het aantal validators op elke parachain laag is (ongeveer vijf validators per shard), zijn de kosten van het corrumperen van individuele shards laag. Om zich te verdedigen tegen dergelijke aanvallen, vereist het Polkadot-protocol dat para-blocks een secundaire controle ondergaan door een andere groep willekeurig geselecteerde nodes.

Als een blok ongeldig of niet beschikbaar blijkt te zijn (d.w.z. een deel van de gegevens ontbreekt), kunnen eerlijke nodes een geschil starten op de hoofd-Relay Chain waarin alle Relay Chain-validators het betwiste blok opnieuw moeten uitvoeren. Een geschil eindigt nadat een ⅔ supermeerderheid van validators voor een van beide kanten van het geschil stemt, waarbij de beledigende validators on-chain worden geschrapt als heruitvoering de slashing-claim ondersteunt.

Dit mechanisme zorgt ervoor dat alle parachains in het Polkadot-protocol hetzelfde beveiligingsniveau delen, ongeacht de grootte van de validatorset op elke shard. Bovendien halen parachains beveiliging uit dezelfde bron (alle para-blokken worden goedgekeurd door de Relay Chain), ze kunnen vertrouwen op de geldigheid van berichten die afkomstig zijn van een externe shard (zonder noodzakelijkerwijs details te kennen van de consensus of status van de laatste).

Interchain-beveiliging

Interchain security is beschreven als Cosmos' antwoord op resttaking en vertoont overeenkomsten met Polkadot's gedeelde beveiligingsmodel. Vergelijkbaar met de relatie tussen de Relay Chain en parachains op Polkadot, hanteert Cosmos een hub-and-spoke-model waarbij meerdere chains ("Cosmos Zones") verbinding maken met een hoofdketen (de "Cosmos Hub") en daar beveiliging uit halen. De redenatie is ook vergelijkbaar met die van Polkadot: nieuwe chains in staat stellen om veilig te blijven zonder dat ze een betrouwbare validatorset vanaf nul hoeven te bootstrappen (een vrij moeilijke taak) en in plaats daarvan economische beveiliging delen - gebundeld op één laag - met andere chains.

In de huidige iteratie vereist interchain security een validator (die ATOM-tokens heeft ingezet) om zowel de Cosmos Hub als alle consumentenketens die ermee verbonden zijn te valideren. Een validator die kwaadwillig handelt op een consumentenketen loopt het risico zijn belang in de providerketen (in dit geval de Cosmos Hub) te verliezen aan slashing.

Het slashen van een aanstootgevende validator vereist doorgaans het doorgeven van een pakket met bewijs van slashbaar gedrag via het IBC-kanaal (Inter-Blockchain Communication) tussen de providerketen en de consumentenketen. Interchainbeveiliging kan dus worden gezien als een vorm van resttaking; bovendien bereikt het een cruciaal doel: het gemakkelijker maken om applicatiespecifieke blockchains te lanceren in het Cosmos-ecosysteem.

Voorheen moesten projecten die soevereine blockchains probeerden te creëren een native token voor staking creëren en een voldoende aantal validators aantrekken om nieuwe gebruikers minimale garanties op veiligheid te bieden. Interchain-beveiliging zorgt er echter voor dat de beveiliging van de Cosmos Hub (beveiligd met ~$2,5 miljard aan stake op het moment van schrijven) kan worden geschaald om nieuwere, low-value chains te beveiligen zonder de omvang van Cosmo's bestaande validatorset te hoeven uitbreiden.

Opmerking : De huidige versie van Cosmos's Interchain Security schakelt slashing uitsluitend uit op basis van pakketten die worden doorgestuurd door consumentenketens vanwege het risico dat schadelijke code op een consumentenketen de transmissie van nep-slash-pakketten activeert en eerlijke validators slasht. In plaats daarvan zijn overtredingen zoals dubbel stemmen (het ondertekenen van twee blokken op dezelfde hoogte) onderhevig aan social slashing via governance. Social slashing brengt echter zijn eigen risico's met zich mee, zoals te zien is in het recente debat over het slashen van validators voor dubbel ondertekenen op een consumentenketen (wat ook wijst op enkele van de complexiteiten van het bouwen van gedeelde beveiligingsprotocollen) .

Mesh security is een alternatief voor interchain security en probeert een aantal van de tekortkomingen van de laatste te verbeteren. In plaats van software te draaien voor zowel provider- als consumentenketens, kan een validator die op de providerketen is ingezet, de inzet delegeren aan een validator op de consumentenketen. Dit verlicht de last van het gelijktijdig valideren van twee ketens (deelname aan governance en consensus) en vermindert de overhead voor opnieuw ingezet validators (bijv. het verminderen van hardwarevereisten).

Net als EigenLayer (waar een Ethereum validator een operator een of meer secundaire protocollen (AVS'en) namens hem kan laten valideren), hoeft een delegate validator geen stake in te zetten om de consumer chain te valideren. Als de delegate validator zijn taken niet correct uitvoert (bijvoorbeeld downtime of ongeldige blokken maken/stemmen), wordt de delegator op de consumer chain geschrapt volgens de regels van het protocol.

Mesh-beveiliging verschilt ook van interchain-beveiliging, omdat het consumentenketens toestaat om beveiliging te leasen van meerdere providerketens (in plaats van beperkt te zijn tot de Cosmos Hub) en validators toestaat om te kiezen aan welke ketens ze stake willen delegeren. Hoewel de laatste functie is gepland als onderdeel van de ICS v2-uitrol, is het onwaarschijnlijk dat de eerste wordt geïmplementeerd (hoewel deze naar verluidt aantrekkelijker is).

Ethereum's Sync-commissie

Ethereum's Sync Committee is een groep van 512 validators die verantwoordelijk zijn voor het ondertekenen van definitieve Beacon block headers. Een nieuwe Sync Committee wordt elke 256 epochs (ongeveer 27 uur) opnieuw samengesteld, met leden die zijn geselecteerd uit de bestaande validator set van de Beacon Chain. Let op dat van leden wordt verwacht dat ze hun reguliere validator taken (inclusief attestatie en block voorstellen) blijven uitvoeren terwijl ze deelnemen aan de Sync Committee.

Het Sync Committee werd voor het eerst geïmplementeerd tijdens de Altair-fork van de Beacon Chain om light clients in staat te stellen nieuwe blokken te verifiëren (zonder de volledige validatorset te kennen) en wijzigingen in de status van Ethereum bij te houden. Omdat deelname aan het Sync Committee meer moeite kost dan alleen deelnemen aan de Beacon Chain-consensus, ontvangen leden een kleine beloning (naast de reguliere beloningen voor het voltooien van Beacon chain-taken).

Leden die ongeldige block headers ondertekenen, zijn echter niet onderhevig aan slashing, in tegenstelling tot de Beacon Chain. De kernontwikkelaars van Ethereum hebben dit ontwerp verdedigd door te zeggen dat het slashen van kwaadaardige Sync Committee-leden meer complexiteit zou introduceren, terwijl anderen hebben gezinspeeld op de moeilijkheid van collusion tussen de ⅔ supermeerderheid van Sync Committee-leden (wat er nodig zou zijn om light clients te misleiden om een slechte block header te accepteren).

Maar met hoogwaardige applicaties, zoals cross-chain communicatieprotocollen, die vertrouwen op lichte clients om de status van Ethereum bij te houden, heeft het onderwerp van het slashen van Sync Committees voor het ondertekenen van ongeldige block headers hernieuwde interesse gewekt (vergelijk een lopend voorstel van het Nimbus client team ). Als het wordt geïmplementeerd, zou slashing deelname aan het Sync Committee veranderen in een vorm van resttaking waarbij validators zich aanmelden voor extra slashing-voorwaarden en extra beloningen ontvangen voor de secundaire service van het ondertekenen van block headers.

Ter illustratie: een validator kan worden gekort tot aan zijn/haar maximale saldo als hij/zij de protocolregels schendt terwijl hij/zij in het Sync Committee zit, zelfs als hij/zij eerlijk handelt terwijl hij/zij deelneemt aan de consensus van de Beacon Chain. We kunnen het Sync Committee ook vergelijken met Polkadots parachain-systeem en andere vormen van gedeelde beveiliging die willekeurig een subset van knooppunten bemonsteren om een subprotocol binnen het grotere blockchainnetwerk te valideren (bijvoorbeeld Lagrange State Committees, Avalanche's Subnets en Algorands State Proofs-protocol).

Controlepunten

Gedeelde beveiligingsschema's op basis van checkpointing omvatten vaak een beveiligingsconsumerende keten die cryptografische commitments naar de laatste status post naar de beveiligingsleverende keten met tussenpozen. Een block proposaler kan bijvoorbeeld verplicht zijn om de hash van de nieuwste block header te posten naar de parent chain voordat deze wordt afgerond.

Deze commitments worden beschreven als "checkpoints" omdat de parent chain de onomkeerbaarheid van de geschiedenis van de child chain tot dat punt garandeert. Met andere woorden, de parent chain garandeert en handhaaft een (canonieke) tijdsvolgorde van de child chain, en beschermt deze tegen pogingen om blokken te reorganiseren en een conflicterende fork te creëren (bijvoorbeeld om oude transacties terug te draaien en een double-spend uit te voeren).

De parent chain kan ook de geldigheid van de child chain garanderen, met name wanneer block headers informatie bevatten over wie een bepaald block heeft geattesteerd/geproduceerd. Als een block ongeldig blijkt te zijn, kan een eerlijke node een challenge starten op de parent chain (waarbij de parent chain het geschil bemiddelt) en een rollback van de status van de child chain activeren.

Als er bovendien een mechanisme voor het beheren van validator stakes (zoals een smart contract) wordt geïmplementeerd op de parent chain, wordt het mogelijk om accountable safety af te dwingen door protocol-schendende validators te schrappen nadat een geldig bewijs van fraude on-chain is geaccepteerd. Dat de parent chain de canonieke geschiedenis van de child chain garandeert, is hier belangrijk, omdat het voorkomt dat nodes de geschiedenis herschrijven (door blokken te verwijderen) om bewijs van kwaadaardig gedrag te verbergen.

Commit sidechains (Polygon PoS), optimiums (Arbitrum Nova/Metis), rollups en chains geïntegreerd met checkpointing-protocollen zoals Babylon implementeren deze vorm van gedeelde beveiliging. In alle gevallen ontleent een protocol zijn economische beveiliging aan een externe blockchain-chain door deze te gebruiken als settlement-laag (verantwoordelijk voor het finaliseren van blokken). Voor de context: Polygon PoS en Arbitrum Nova/Metis slaan headers op in een on-chain contract op Ethereum, terwijl Babylon headers streamt van verbonden Cosmos Zones naar Bitcoin.

Rollups van laag 2 (L2) gebruiken een vergelijkbaar mechanisme (het posten van blokroots naar de blockchain van laag 1), met een cruciaal verschil: de gegevens die nodig zijn om de blokken van een rollup opnieuw te maken, worden ook gepubliceerd op de settlement-laag. Dit betekent dat de settlement-laag de beveiliging van de rollup volledig garandeert (uiteindelijk). Daarentegen zijn de gegevens die nodig zijn om de status van een commit-sidechain of optimistische chain te reconstrueren mogelijk niet beschikbaar, met name in het geval van een kwaadaardige sequencer of validatorset die aanvallen uitvoert om gegevens achter te houden.

Gedeelde beveiliging voor interoperabiliteitsprotocollen tussen ketens

Nu we uitgebreide achtergrondinformatie hebben gegeven over de betekenis en evolutie van gedeelde beveiliging, kunnen we ons nu verdiepen in nieuwe grenzen in gedeelde beveiligingsontwerpen. Een dergelijk onderzoeksgebied is gedeelde beveiliging voor cross-chain-protocollen , dat de huidige benaderingen van berichten en overbrugging tussen blockchains wil verbeteren door de voordelen van gepoolde (economische) beveiliging te benutten.

Deze definitie kan bij de lezer vragen oproepen, zoals:

• Waarom de expliciete focus op interoperabiliteitsprotocollen?

• Welke voordelen levert een interoperabiliteitsprotocol op als het wordt geïntegreerd met gedeelde beveiligingstechnologie?

  
  

Lagrange Labs bouwt Lagrange State Committees : een gedeelde beveiligingsoplossing voor protocollen die toegang nodig hebben tot trust-minimized proofs van cross-chain states. (State Committees combineren Lagrange's ZK Big Data proof system en EigenLayer's resttaking-infrastructuur om een gedeelde beveiligingszone te creëren voor cross-chain interoperabiliteitsprotocollen.) Daarom voelen we ons genoodzaakt om elk van de voorgaande vragen te ontleden en in het proces te pleiten voor het integreren van bridging-, indexerings- en berichtentoepassingen met de infrastructuur van de State Committee.

Een korte inleiding tot interoperabiliteitsprotocollen

In Interoperability For Modular Blockchains: The Lagrange Thesis hebben we uitgelegd dat interoperabiliteitsprotocollen cruciaal zijn voor het verbinden van silo-blockchains en het verminderen van problemen rondom fragmentatie van liquiditeit en status voor blockchain-applicaties (en hun gebruikers). Enkele belangrijke voorbeelden die in dat artikel worden genoemd, zijn:

• Bruggen die lock-and-mint- of burn-and-mint-mechanismen implementeren en het mogelijk maken om een asset over te dragen van een native blockchain (waar het is uitgegeven) voor gebruik op een niet-native blockchain

• Berichtenprotocollen waarmee gebruikers op een veilige manier informatie kunnen uitwisselen (via datapakketten) tussen blockchains die geen enkele bron van waarheid delen en elkaars status niet kunnen verifiëren

  
  

We hebben ook de waarde van verschillende soorten blockchain-interoperabiliteitsoplossingen benadrukt. Zo stellen bruggen gebruikers in staat om naadloos te bewegen tussen verschillende ecosystemen, meer toepassingen te bekijken en de efficiëntie van activa te verhogen (door te profiteren van mogelijkheden voor het genereren van opbrengsten die bestaan op andere blockchains). Berichtenprotocollen ontgrendelen ook geavanceerdere use cases zoals cross-chain lending, cross-chain arbitrage en cross-chain en cross-chain margining die afhankelijk zijn van het overdragen van informatie (bijvoorbeeld posities en schuldprofielen) tussen verschillende domeinen.

Hoewel ze voor verschillende doeleinden zijn ontworpen, delen alle verschillende interoperabiliteitsoplossingen enkele basiseigenschappen. Het belangrijkste is een mechanisme om te verifiëren dat bepaalde informatie over de blockchain(s) die betrokken zijn bij een cross-chain transactie/operatie (verstrekt door de gebruiker of een applicatie) waar is. Dit is doorgaans een bewering dat een bepaalde staat (bijv. waarden opgeslagen in de opslag van een smart contract, het saldo van een account of het meest recent afgeronde blok) bestaat, of dat een transactie heeft plaatsgevonden op een andere keten.

Neem het voorbeeld van een brug tussen Ethereum en NEAR. De operator van de brug moet de volgende informatie over de status van elke keten valideren wanneer een gebruiker een asset (bijvoorbeeld DAI) overbrugt:

• Voordat nearDAI-tokens op het NEAR-adres van de gebruiker worden gestort, moet de bridge-operator bewijzen dat de gebruiker DAI op het contract van de bridge op Ethereum heeft gestort
• Voordat de oorspronkelijke DAI-storting wordt vrijgegeven (bij een overbrugging van NEAR naar Ethereum), moet de brugbeheerder bewijzen dat de betreffende gebruiker nearDAI-tokens op NEAR heeft verbrand en het vereiste bewijs van 'proof-of-burn' naar het contract van de brug op NEAR heeft gestuurd.

Een berichtenprotocol tussen de eerder genoemde ketens zal vergelijkbare, maar enigszins verschillende, vereisten hebben. Als een Ethereum-gebruiker de uitvoering van een cross-chain-transactie aanvraagt ("call X contract on NEAR"), moet het protocol verifiëren dat het berichtverzoek oorspronkelijk op Ethereum is geplaatst (meestal door een on-chain contract aan te roepen).

Een eenvoudige manier om claims over cross-chain transacties te valideren is om een volledige node voor de betreffende chain te runnen. Volledige nodes die transacties van elk blok downloaden en opnieuw uitvoeren voordat de laatste status van de chain wordt gesynchroniseerd, zijn doorgaans de meest betrouwbare manier om statusovergangen op een blockchain te verifiëren. Het runnen van een volledige node is echter zowel lastig als onnodig; lastig omdat volledige nodes hoge hardwarevereisten vereisen, en onnodig omdat een cross-chain protocol alleen informatie nodig heeft die relevant is voor enkele sets van transacties en contracten.

Gelukkig bieden light clients een eenvoudige/effectieve manier om gebeurtenissen en statuswijzigingen bij te houden zonder dat er een volledige node hoeft te worden uitgevoerd. Mits we het ontwerp van de light client vertrouwen, kunnen we eenvoudigweg block headers downloaden om specifieke informatie te verifiëren, zoals het voorkomen van stortingen/opnames in een bridge en de status van berichtverzoeken/-uitvoering in een berichtenprotocol.

Om communicatie tussen twee ketens mogelijk te maken, die we keten A en keten B noemen, zou een interoperabiliteitsprotocol een light client van keten A op keten B draaien die blokheaders van keten B opslaat (en vice versa). Dit stelt het in staat om verschillende bewijzen van status/opslag (blokheaders, Merkle-bewijzen, enz.) te verifiëren die door gebruikers (of een derde partij) van een applicatie op de bronketen naar een andere applicatie op de bestemmingsketen worden doorgegeven. De light client fungeert als een bron van informatie (een "oracle") over de statussen van de twee blockchains, zoals geïllustreerd in de onderstaande afbeelding:

Deze aanpak om de geldigheid van cross-chain-staten te verifiëren, stuit echter op het probleem van vertrouwen. Vitalik Buterin's artikel Trust Models geeft een beknopte definitie van vertrouwen: " Vertrouwen is het gebruik van aannames over het gedrag van andere mensen. " Het artikel definieert ook het concept van vertrouwenloosheid (met een kanttekening):

Een van de meest waardevolle eigenschappen van veel blockchain-applicaties is trustlessness: het vermogen van de applicatie om op een verwachte manier te blijven werken zonder afhankelijk te zijn van een specifieke actor om zich op een specifieke manier te gedragen, zelfs wanneer hun interesses kunnen veranderen en hen ertoe kunnen aanzetten om in de toekomst op een andere onverwachte manier te handelen. Blockchain-applicaties zijn nooit volledig trustless, maar sommige applicaties zijn veel dichter bij trustless dan andere. — Vitalik Buterin

In onze context (blockchain-interoperabiliteit) wordt vertrouwen onvermijdelijk wanneer de status van twee of meer ketens onafhankelijk van elkaar worden gevalideerd. Denk aan een scenario waarin Bobs applicatie op keten A een bewijs ontvangt dat Alice een bericht heeft geïnitieerd ("lock 5 ETH op keten B en mint 5 Wrapped ETH (WETH) op keten A"). Het berichtbewijs is een Merkle-bewijs dat de opname van Alices transactie in een blok laat zien, wat Bob—omdat hij een on-chain light client voor keten B runt—kan verifiëren door het bewijs te vergelijken met de Merkle-root van transacties afgeleid van de header van een geldig keten B-blok.

Echter, “geldig” in de context van een blok kan verschillende dingen betekenen: (a) “De blokheader behoort tot een blok dat is goedgekeurd door een meerderheid van de validatoren van de bronketen.” (b) “De blokheader behoort tot een blok waarvan de transacties geldig zijn volgens de transactiegeldigheidsregels van de bronketen.”

Bob kan #1 beschouwen als een concreet bewijs van de geldigheid van een blok, maar dit is gebaseerd op aannames over de validatoren in de bronketen:

• “ De meerderheid van de validators op keten A zijn eerlijk en zouden een blok met één of meer ongeldige transacties niet goedkeuren. ”
• “ De meerderheid van de validatoren op keten A zijn economisch rationele actoren en hebben weinig prikkels om een blok met ongeldige transacties goed te keuren. ”

Hier is het gemakkelijk te zien waar een (of beide) van deze aannames kan mislukken. Als bijvoorbeeld het bedrag van de inzet < de waarde van de transacties op keten A (bijvoorbeeld het bedrag dat via frauduleuze transacties van een brug kan worden gestolen), hebben validators een prikkel om een ongeldig blok te finaliseren, zelfs als dit betekent dat ze worden gekortwiekt. De winst van een aanval weegt immers op tegen de kosten.

Over het algemeen is elk mechanisme voor het verifiëren van cross-chain-statussen onderhevig aan vertrouwensveronderstellingen (we zullen enkele van deze vertrouwensveronderstellingen in detail bespreken). Het belangrijkste doel, en dit is een thema dat in dit artikel steeds terugkomt, is dat we vertrouwen in cross-chain-communicatie willen minimaliseren tot een niveau waarop verschillende vertrouwensveronderstellingen geen groot beveiligingsrisico vormen voor op interoperabiliteit gerichte toepassingen.

Dit is een belangrijk doel, want als je een interoperabiliteitsprotocol bouwt om verschillende blockchains te koppelen en een applicatie die aan de ene kant van de kloof draait een valse claim accepteert dat er aan de andere kant een willekeurige gebeurtenis heeft plaatsgevonden, kunnen er slechte dingen gebeuren - echt slechte dingen. Ter illustratie: bridge-exploits zijn gebeurd omdat een bug het voor slimme hackers mogelijk maakte om (nep)bewijzen van niet-bestaande berichtverzoeken succesvol door te sturen en tokens te minten op een bestemmingsketen zonder onderpand te storten op de bronketen.

Analyse van bestaande cross-chain beveiligingsmechanismen

Protocolontwerpers hebben sindsdien oplossingen bedacht voor het probleem van het valideren van informatie in cross-chain communicatie; de meest voorkomende is het gebruik van een derde partij om het bestaan/de geldigheid van een cross-chain transactie te verifiëren. De redenatie is simpel: een applicatie op chain A kan de status van chain B misschien niet verifiëren, maar we kunnen het wel laten verifiëren dat een groep mensen (die we vertrouwen of waarvan we verwachten dat ze eerlijk zijn via een mechanisme) een stukje informatie (of claim) hebben gevalideerd dat verwijst naar de status van chain B.

Dit wordt "externe verificatie" genoemd, omdat een andere partij buiten de blockchain fungeert als een bron van waarheid voor on-chain events en (meestal) een of meer verificatoren omvat die handtekeningen uitvoeren op blockheaders van de bronketen. Zodra de applicatie op de bestemmingsketen deze ondertekende header ontvangt, kan deze vervolgens verschillende door een gebruiker verstrekte statusbewijzen (saldi, events, stortingen/opnames, etc.) verifiëren.

Om een bepaald niveau van fouttolerantie te creëren, gebruiken sommige interoperabiliteitsprotocollen een drempelondertekeningsschema dat een minimum aantal privésleutels vereist om een handtekening uit te voeren voor geldigheid (multisignature en multiparty (MPC) wallets zijn veelvoorkomende voorbeelden). Maar het hebben van een pluraliteit ( k van n ) of van verifiers die getuigen van cross-chain states is niet bepaald een wondermiddel voor beveiliging, vooral niet voor kleine sets van verifiers.

Bijvoorbeeld, iemand zou net genoeg ondertekenaars in een multisig-schema kunnen compromitteren en vervolgens frauduleuze opnames uit een cross-chain bridge autoriseren. Een MPC-opstelling is iets veiliger (de goedkeuringsdrempel kan worden gewijzigd en keyshares kunnen vaker worden geroteerd), maar is nog steeds vatbaar voor aanvallen (vooral in gevallen waarin één partij de meerderheid van de keyshares beheert).

Uitzetten

Een manier om vertrouwensveronderstellingen voor interoperabiliteitsprotocollen te verminderen en de veiligheid van cross-chain communicatie te verbeteren, is om externe verificateurs collateral als een borg te laten inzetten voordat ze verificatietaken op zich nemen. Staking creëert beveiliging voor extern geverifieerde systemen, met name omdat gebonden collateral kan worden doorgesneden als een verificateurknooppunt een handtekening uitvoert op een ongeldige blokheader of een ongeldige cross-chain transactie goedkeurt).

Maar zelfs deze aanpak kent problemen, afhankelijk van of staking toestemming vereist of niet. Een systeem met toestemming (waar validators op de whitelist moeten staan) is vaak beperkt tot een paar vooraf goedgekeurde entiteiten en is gemakkelijker te ontwikkelen: er hoeft niet te worden geïnvesteerd in uitgebreid incentive-ontwerp, vooral niet als validators publiekelijk bekend zijn en een prikkel hebben om eerlijk te handelen om hun reputatie te behouden. Het is ook efficiënt omdat communicatie, noodzakelijk om consensus te bereiken, plaatsvindt tussen een paar partijen die zichzelf al kennen.

Natuurlijk opent een systeem met toestemming en identificeerbare deelnemers de deur voor vijandige aanvallen; bijvoorbeeld, een aanvaller kan zich met succes voordoen als of omkopen van een aantal van deze validators en zo de meerderheidscontrole overnemen. Erger nog, een Proof of Authority (PoA)-systeem waarin validators niet daadwerkelijk worden ingezet (en simpelweg worden aangesteld) reduceert de kosten van een aanval op het systeem tot nul (aanvallers kunnen bijvoorbeeld eenvoudigweg PoA-validators compromitteren via social engineering-schema's en het systeem kapen).

Een permissionless staking-systeem verhoogt de kosten van het corrumperen van een systeem door elke geïnteresseerde partij (met de juiste hoeveelheid kapitaal) toe te staan om cross-chain-bewerkingen te valideren. Als dit gecombineerd wordt met een consensusprotocol dat ≥ ⅔ meerderheid vereist om te bevestigen dat block headers worden geblokkeerd, zouden de kosten van het corrumperen van het systeem effectief gelijk zijn aan het minimale bedrag dat nodig is om de meerderheid van de verifiers in het systeem te corrumperen. Bovendien hebben gebruikers minder vertrouwensveronderstellingen (validators kunnen worden verlaagd) en een dynamische set verifiers verhoogt de moeilijkheid om specifieke nodes te compromitteren via technieken als social engineering.

Wat kan er misgaan? Heel veel, eigenlijk. Om te beginnen moet de hoeveelheid inzet om het systeem te beveiligen gelijk zijn aan of hoger zijn dan de totale waarde van de activa die in gevaar zijn als er een beveiligingsincident plaatsvindt (waardoor de veiligheid of levendigheid van het interoperabiliteitsprotocol wordt aangetast). Als het omgekeerde waar is ( totale inzet om het systeem te beveiligen < totale waarde die in gevaar is ), dan wordt zelfs de dreiging van slashing ineffectief om de beveiliging te garanderen, aangezien de winst van het corrumperen van het systeem opweegt tegen de kosten van het corrumperen ervan.

Bovendien zou het proberen te implementeren van de eerder genoemde beveiligingseigenschap waarschijnlijk vereisen dat er hogere inzetvereisten worden gesteld aan potentiële validators. Dit introduceert op zijn beurt het probleem van kapitaalinefficiëntie, aangezien beveiliging afhankelijk is van validatornodes die twee dingen doen:

• Een groot bedrag vooraf storten (als inzet) voordat je deelneemt aan validatietaken

• Het geld voor een lange periode ongebruikt laten (om veiligheidsredenen leggen PoS-protocollen lange vertragingen op bij opnames, soms wel weken of maanden, om randgevallen te voorkomen waarin een validator een overtreding begaat die de opnames ongedaan kan maken en onmiddellijk probeert op te nemen om te voorkomen dat er geld verloren gaat door slashing)

  
  

Iets anders dat we niet hebben genoemd, is de last voor ontwikkelaars die nu moeten redeneren over crypto-economische prikkels om oneerlijk gedrag te ontmoedigen en complexe stakingfunctionaliteit voor het token van het protocol te ontwerpen. Naast het wegnemen van de aandacht van belangrijkere activiteiten, zoals productontwikkeling en community-betrokkenheid, draagt het ook bij aan de complexiteit en cognitieve overhead van de ontwikkelingscyclus voor teams die interoperabiliteitsinfrastructuur bouwen.

Optimistische verificatie

"Optimistische verificatie" is een andere kijk op het probleem van cross-chain beveiliging: in plaats van een vertrouwde partij of groep te vragen om een cross-chain status te bevestigen, laten we iedereen dat doen. Cruciaal is dat de partij die claims maakt over cross-chain statussen aan een client interoperabiliteitsapplicatie (meestal een "relayer" genoemd) niet verplicht is om bewijs te leveren dat de bevestigde status geldig is. Dit komt voort uit de "optimistische" aanname dat relayers eerlijk zullen handelen en alleen geldige claims zullen maken over cross-chain statussen.

Maar natuurlijk verwachten we dat een of twee (of meer) relayers rogue worden, wat de reden is dat optimistisch geverifieerde systemen vereisen dat relayers een kleine borgsom storten voordat ze staatsbewijzen indienen. De uitvoering van transacties (die verwijzen naar cross-chain-staten die door een relayer zijn gerapporteerd) wordt ook vertraagd om iedereen die het systeem bekijkt voldoende tijd te geven om ongeldige claims binnen de challenge- periode te betwisten. Als de claim van een relayer ongeldig blijkt te zijn, wordt de geposte borgsom verlaagd, waarbij een deel ervan naar de challenger gaat.

Optimistische verificatie verandert het probleem van het moeten vertrouwen op een pluraliteit ( k van n ) of meerderheid ( m van n ) verificateurs in het probleem van het vertrouwen op één verificateur ( 1 van n ) om eerlijk te handelen. Om optimistisch geverifieerde protocollen veilig te houden, is het voldoende om één actor te hebben die voldoende statusgegevens heeft om transacties opnieuw uit te voeren en fraudebewijzen te creëren om frauduleuze transacties binnen de vertragingsperiode aan te vechten (vandaar de 1 of n beveiligingsveronderstelling).

Dit vermindert de overhead omdat het systeem correct kan werken met één relais (hoewel we er misschien twee of meer nodig hebben om de levendigheid te garanderen). Het vermindert ook de hoeveelheid inzet die nodig is voor beveiliging en moedigt aan om een snellere inzet-ontkoppelingstijd in te stellen (geborgde zekerheden kunnen worden ingetrokken zodra de vertragingsperiode is verstreken).

Bovendien worden interoperabiliteitsprotocollen gebaseerd op optimistische verificatie beschreven als "het erven van de beveiliging van de onderliggende blockchain"; dit is gebaseerd op het idee dat als de onderliggende blockchain live is en geen fraudebewijzen censureert, een kwaadwillende relayer niet weg kan komen met oneerlijk gedrag. Bovendien zou het aanvallen van het protocol vereisen dat de blockchain zelf wordt aangevallen, aangezien het censureren van transacties gedurende een langere periode vereist dat een meerderheid van de nodes wordt gecontroleerd - en bij uitbreiding, stake/mining power - in het netwerk.

Maar zelfs optimistische verificatie heeft unieke nadelen. Bijvoorbeeld, het opleggen van een vertraging bij het afronden en uitvoeren van bridging-transacties of berichtverzoeken verhoogt de latentie en verslechtert de algehele gebruikerservaring. Dit type cross-chain-beveiliging heeft ook verschillende subtiele 'valkuilen' met implicaties voor de beveiliging, zoals de mogelijkheid dat een kwaadwillende partij geldige transacties in twijfel trekt om eerlijke relayers te 'grieven' en een type DDoS-aanval uit te voeren.

Omdat fraudebewijzen (meestal) interactief van aard zijn, zou een ongeldige uitdaging ervoor zorgen dat eerlijke relayers middelen verspillen, waaronder fondsen die worden uitgegeven aan gaskosten voor on-chain transacties. Bijgevolg kunnen eerlijke relayers de prikkel verliezen om cross-chain informatie door te geven, wat mogelijk een kans biedt voor oneerlijke relayers om cross-chain informatie door te geven. Het vereisen van challengers om een minimale storting te doen, zou griefing kunnen ontmoedigen, maar een hoge minimale storting zou eerlijke watchers (die geen kapitaal hebben) kunnen ontmoedigen om ongeldige statusupdates aan te vechten.

Sommige protocollen omzeilen dit probleem door uitdagingen te beperken tot een toegestane set watchers, maar dat brengt ons terug bij het oorspronkelijke probleem van het hebben van een kleine set (vertrouwde) deelnemers om een systeem te beveiligen. Deze aanpak kan ook verschillende onbedoelde gevolgen hebben, zoals het verlagen van de barrière voor collusion tussen watcher-nodes en het verbeteren van de kans van een aanvaller om de meerderheid van de nodes die het systeem in de gaten houden, te corrumperen.

Cryptografische verificatie

De laatste benadering om cross-chain interoperabiliteitsprotocollen te beveiligen die we zullen overwegen, komt uit het rijk van cryptografische bewijzen. Het idee is simpel: in plaats van mensen te vertrouwen om cross-chain-statussen te verifiëren (wat in eerdere secties in bepaalde gevallen gevaarlijk is gebleken), kunnen we in plaats daarvan cryptografische verificatiemechanismen gebruiken, waardoor vertrouwensveronderstellingen tot een minimum worden beperkt.

Hier genereren een of meer actoren SNARK (Succinct Non-Interactive Argument of Knowledge) bewijzen van de (geldige) status van een keten voor gebruik binnen een interoperabiliteitstoepassing. Deze bewijzen zijn verifieerbaar : we kunnen een cryptografisch bewijs van een cross-chain status nemen, zoals een die is afgeleid van een blokheader, en de geldigheid ervan bevestigen. Ze zijn ook niet-interactief : een bewijs dat door een enkele partij is gegenereerd, kan door n verschillende partijen worden geverifieerd zonder dat iemand hoeft te communiceren (in tegenstelling tot interactieve fraudebewijzen). Interoperabiliteitsprotocollen die op deze manier zijn ontworpen, hebben vaak de laagste vertrouwensaannames, voor zover het onderliggende bewijssysteem gezond is (d.w.z. een tegenstander kan geen geldige bewijzen voor ongeldige claims creëren, behalve voor een verwaarloosbare waarschijnlijkheid).

Dergelijke protocollen verschillen ook van extern geverifieerde systemen, met name waar cryptografische bewijzen verifiëren dat elk blok correct is volgens het consensusprotocol van een keten. Als zodanig zou een tegenstander een supermeerderheid van de validatorset van de bronketen moeten controleren (vereist om ongeldige blokken te finaliseren) om een interoperabiliteitsprotocol te corrumperen met behulp van cryptografische bewijzen van cross-chain-status.

Het is ook gemakkelijk te zien hoe deze aanpak een aantal nadelen wegneemt die gepaard gaan met enkele eerder besproken cross-chain beveiligingsmechanismen:

1. Zero capital inefficiency : Het gebruik van zkSNARKs om cross-chain states te verifiëren elimineert de noodzaak van een staking/bonding mechanisme en de bijbehorende inefficiëntie van het onderwerpen van tokens aan een lockup periode. Evenzo hoeven relayers geen bond te plaatsen (in tegenstelling tot optimistische verificatie) voordat ze claims maken over cross-chain transacties, aangezien het bijbehorende bewijs de claim bondig verifieert.
2. Lage latentie : Zonder de noodzaak om een vertragingsperiode te implementeren—om tijdige fraudebewijzen mogelijk te maken—kan een interoperabiliteitsprotocol een cross-chain bericht of bridging-bewerking uitvoeren zodra een SNARK-bewijs dat het beveiligt, is geverifieerd. Dat gezegd hebbende, is het genereren van bewijs doorgaans rekenintensief, dus een extern geverifieerd systeem kan efficiënter zijn in vergelijking met een SNARK-gebaseerd interoperabiliteitsprotocol.

Bij het beoordelen van de beveiliging van een "cryptografisch geverifieerde" interoperabiliteitsoplossing is het belangrijk om goed te kijken naar welke informatie over cross-chain-statussen daadwerkelijk wordt bewezen en geverifieerd. Zero-knowledge proofs zijn een modewoord geworden waar veel protocollen zich aan vastklampen om de werkelijke vertrouwensveronderstellingen die ten grondslag liggen aan hun protocollen te verdoezelen.

Omdat het verifiëren van alle handtekeningen in de Ethereum validator set ( meer dan 925.000 validators volgens huidige cijfers ) in een zkSNARK circuit bijvoorbeeld duur kan zijn, hebben sommige protocollen historisch gezien andere middelen aangenomen om bewijzen van de status van Ethereum af te leiden. Een voorbeeld is een " Ethereum to X " brug (waarbij X elke blockchain kan zijn) die een bewijs genereert dat de block headers zijn ondertekend door een meerderheid van Ethereum's Sync Committee (dat we eerder hebben geïntroduceerd).

Dit is een meer haalbare aanpak (vergeleken met het verifiëren van openbare sleutels van duizenden validators die een blok hebben bevestigd). Maar zoals eerder uitgelegd, worden validators in het Sync Committee niet afgestraft voor het ondertekenen van onjuiste blokheaders, wat een niet te verwaarlozen kans laat dat een meerderheid van de leden van het Sync Committee kan samenspannen of kan worden omgekocht om light clients te misleiden en effectief de beveiliging van bridges/berichtenprotocollen in gevaar brengt die afhankelijk zijn van het Sync Committee voor informatie.

Bovendien, zoals uitgelegd in het originele artikel over de introductie van Lagrange State Committees , hebben we uitgelegd dat in een ideale wereld waarin kwaadaardige Sync Committees vatbaar zijn voor slashing, de economische veiligheid beperkt zou worden tot het maximaal slashable bedrag. Hier zijn enkele fragmenten uit dat bericht voor context:

De beveiliging van light client bridges, ZK bridges en sync committee proofs zijn allemaal gebaseerd op verificatie van handtekeningen van de Ethereum light client sync committee. Omdat de grootte van de sync committee vastligt, wordt de economische beveiliging die hieraan ten grondslag ligt ook beperkt tot een periode van 27 uur. Zodra slashing uiteindelijk wordt geïmplementeerd voor Ethereum sync committees, wordt de economische beveiliging als volgt begrensd:

• Economische zekerheid van Sync Committee = 512 knooppunten * 32 Eth * $1650 USD/ETH = $27.033.600
• Drempel voor compromis Sync Committee = $27.033.600 * 2/3 = $18.022.400

Hoewel light client bridges en ZK light client bridges worden gezien als een gouden standaard voor cross-chain interoperabiliteit, is de hoeveelheid activa die ze kunnen beveiligen met gerandomiseerde sync committees ernstig beperkt. Zoals eerder getoond, is de hoeveelheid colluding nodes die zouden moeten verbranden om gelijktijdig alle Ethereum light client en ZK light client bridges te compromitteren, gemaximeerd op $18m.

Beschouw een situatie waarin de som van de waarde van alle activa die door alle light client- en ZK light client-bruggen zijn beveiligd, een bedrag k bedraagt. Wanneer k < $18m zijn alle activa die via de bruggen zijn beveiligd veilig, omdat een aanval economisch niet haalbaar is. Naarmate k groeit, zodat k > $27m wordt het winstgevend voor een groep kwaadwillenden in het synchronisatiecomité om kwaadaardige blokkades te bevestigen om de beveiligde activa te compromitteren.

We raden u aan het hele artikel te lezen, met name het gedeelte over de beperkingen van Ethereum's light client bridges , voor meer context over de problemen rond het vertrouwen op gerandomiseerde sync committees om bewijzen van cross-chain states af te leiden. We raden u ook aan de inspanningen van Polyhedra Network te volgen om de volledige Ethereum PoS consensus in een ZK circuit te bewijzen .

Lagrange State Committees: gedeelde beveiliging als een service voor communicatieprotocollen over meerdere ketens heen

Omdat een groot deel van de inleiding van dit artikel over gedeelde beveiliging gaat, is het passend dat we een gedeelde beveiligingsoplossing introduceren waar we bij Lagrange Labs aan hebben gewerkt: Lagrange State Committees . In dit gedeelte verkennen we de interne werking van het Lagrange State Committee-netwerk en begrijpen we de verbinding met Lagrange's ZK Big Data-stack en het doel om tools te bouwen om veilige en expressieve toegang tot de status op ketens en tussen ketens mogelijk te maken.

Wat zijn Lagrange-staatscomités?

Het Lagrange State Committee (LSC)-netwerk is een eenvoudig en efficiënt ZK light client-protocol voor optimistische rollups (ORU's) die zich vestigen op Ethereum (bijv. Optimism, Arbitrum, Base en Mantle). LSC's zijn conceptueel vergelijkbaar met Ethereum's Sync Committee en ondersteunen light client-gebaseerde applicaties, zoals bridges en interchain-berichtlagen, die de status van een optimistische rollup willen gebruiken zonder buitensporige vertrouwensveronderstellingen aan te gaan.

Een Lagrange State Committee is een groep client nodes die 32 ETH aan collateral op Ethereum opnieuw hebben ingezet via EigenLayer. Met andere woorden, een Lagrange State Committee-netwerk is een AVS of Actively Validated Service . Elk Lagrange State Committee bevestigt de finaliteit van blokken voor een bepaalde optimistische rollup zodra de bijbehorende transactiebatches zijn afgerond op een data-availability (DA)-laag. Deze attestaties worden vervolgens gebruikt om statusbewijzen te genereren, die applicaties kunnen behandelen als een bron van waarheid voor de status van die specifieke optimistische rollup.

Terwijl Ethereum's Sync Committee is gemaximeerd op 512 nodes, ondersteunt elk Lagrange State Committee-netwerk een onbeperkte set nodes. Dit zorgt ervoor dat de economische veiligheid niet kunstmatig wordt beperkt en dat het aantal nodes dat de status van een optimistische roll-up bevestigt, kan schalen, waardoor de economische veiligheid achter Lagrange state proofs dynamisch wordt vergroot.

Hoe werkt het netwerk van het Lagrange State Committee?

Twee belangrijke componenten van het Lagrange State Committee-protocol zijn de sequencer en client nodes ("client nodes" is een andere naam voor validators die geregistreerd zijn bij een Lagrange State Committee). De sequencer is een centrale entiteit die verantwoordelijk is voor het coördineren van attestaties in een Lagrange State Committee-netwerk en het leveren van attestaties aan de provers die state proofs produceren. De sequencer node is in feite een combinatie van drie modules met verschillende functies: Sequencer , Consensus en Governance .

Op specifieke intervallen vraagt de Sequencer-module attestaties van clientknooppunten aan rollup-blokken die het resultaat zijn van de uitvoering van een batch transacties die naar een DA-laag zijn geschreven. In plaats van deze routine voor elk optimistisch rollup-blok uit te voeren, volgt hieronder een korte analyse van elk element in het blokbericht:

(1). Block_header : Een header van een gefinaliseerd optimistisch rollup (ORU) blok. "Finaliteit" betekent hier een blok afgeleid door rollup nodes van transactiegegevens die gefinaliseerd zijn op een bepaalde DA-laag. Finaliteit wordt bijvoorbeeld gedefinieerd door de veilige L2-head voor Optimism/OP stack rollups en een L2-blok met Ethereum-equivalente finaliteit voor Arbitrum en Arbitrum Orbit-ketens. (Lees meer over rollup finaliteit in dit artikel .)

(2). current_committee : Een cryptografische commitment aan de set publieke sleutels die geassocieerd zijn met client nodes die toestemming hebben om een blok b te ondertekenen. Van een client node wordt verwacht dat hij een Merkle tree bouwt, met bladeren die de publieke sleutels van alle actieve committee leden vertegenwoordigen, en de root van de Merkle tree ondertekent met zijn BLS12–381 sleutel.

(3). next_committee : Een cryptografische verbintenis met de set openbare sleutels die is gekoppeld aan nodes die het volgende blok (b+1) mogen ondertekenen. Nodes die een staatscomité willen verlaten, moeten aan het einde van de attestatieperiode een transactie indienen bij het Lagrange Service contract op Ethereum dat de registratie en deregistratie van operators in de AVS van het Staatscomité afhandelt.

Aan het einde van elke attestatieperiode kan de set van committee nodes worden gewijzigd als operators verzoeken om te vertrekken of toe te treden voordat de volgende attestatieperiode begint. Van client nodes wordt verwacht dat ze een Merkle-tree van de next_committee bouwen door de huidige set van nodes die bij elke committee zijn geregistreerd op te halen uit het Lagrange Service Contract.

ELI5: Wat zijn staatsbewijzen?

Een state proof is een cryptografisch bewijs van de status van een blockchain: een bewijs van een block header van een bronketen (keten A), dat kan worden gebruikt om aan de bestemmingsketen het bestaan van een status op de bronketen te bewijzen, zoals een bepaalde transactie. Met andere woorden, een state proof vertegenwoordigt een bewijs van de status van de bronketen op een bepaalde blokhoogte.

Om dit te illustreren met een eerder voorbeeld: de block header van de bronketen (keten A), die Bob's applicatie op de bestemmingsketen (keten B) gebruikt om het bestaan van Alice's bridging-transactie te verifiëren, is een state proof. Het vertegenwoordigt een samenvatting van wijzigingen in de status van de bronketen tussen het vorige blok en het huidige blok. Als Alice's Merkle proof verifieert tegen de transactie-tree root die is opgeslagen in de block header van keten A, kan Bob de bridging-transactie op keten B (de bestemmingsketen) met vertrouwen goedkeuren, aangezien het state proof getuigt van de uitvoering van Alice's berichtverzoek op de oorspronkelijke keten.

Het Lagrange State Committee-netwerk is ontworpen om state proofs te genereren voor optimistische rollups die beveiligd zijn door Ethereum. State proofs worden gegenereerd door BL12–381 signatures te aggregeren op de eerder beschreven tuple ( block_header , prev_committee en next_committee ) van ten minste twee derde van de nodes in het state committee. Het state proof wordt vervolgens gegenereerd door een SNARK-circuit op basis van het collectieve gewicht van signatures die getuigen van een gegeven block header.

De aanpak om attestors te verplichten zich te committeren aan de huidige en volgende state committees is vergelijkbaar met het Ethereum Sync Committee protocol en bereikt een soortgelijk doel: light clients in staat stellen de geldigheid van een optimistische rollup block header efficiënt en veilig te verifiëren. Elk state proof is cryptografisch gekoppeld door een reeks next_committee commitments die aangeven welke nodes het volgende block moeten ondertekenen. Het is dus voldoende om een SNARK proof te verifiëren die de volgende recursieve eigenschappen bewijst in het block object dat is ondertekend door attesting nodes:

• Ten minste ⅔ van de n knooppunten in het staatscomité ondertekenden de blokheader b.

• Het current_committee van blok b is gelijk aan de next_committee comitéboom van blok b-1.

• Blok b-1 is óf het genesisblok, óf is geldig met betrekking tot deze drie voorwaarden.

  
  

Interoperabiliteitsprotocollen en andere toepassingen die veilige optimistische rollup-status met snelle finaliteit vereisen (bijv. cross-chain-bruggen en berichtenprotocollen) kunnen statusbewijzen van Lagrange State Committees gebruiken met minimale vertrouwensaannames. Belangrijk is dat het Lagrange State Committee-netwerk de veiligheid van statusbewijzen kan garanderen door deterministische slashing van kwaadaardige attestors en inductieve validiteitsbewijzen te implementeren.

Hoe werkt het Lagrange State Committee-netwerk samen met de ZK Big Data Stack?

In de eerste post van de serie over Lagrange's product suite, hebben we de relatie tussen verschillende onderdelen van de ZK Big Data Stack benadrukt: Lagrange State Committees, Recproofs, zkMapReduce en de Lagrange Coprocessor. Elk van deze componenten, wanneer gecombineerd, biedt collectief veilige, efficiënte toegang tot state en expressieve, dynamische berekeningen op state data:

#1. Het Lagrange State Committee-netwerk integreert met de andere componenten van de ZK Big Data Stack voor betere prestaties

We gebruiken Recproofs en zkMapReduce om bijwerkbare APK-bewijzen (aggregated public key) te maken voor staatscommissies. Zo vermijden we het kostbare en tijdrovende proces van het deaggregeren en opnieuw aggregeren van openbare sleutels van niet-ondertekenaars wanneer een nieuwe geaggregeerde handtekening moet worden gemaakt.

Efficiënte aggregatie van BLS-openbare sleutels van operators in de Lagrange State Committees AVS faciliteert hogere deelnamepercentages in de AVS zonder de rekenkosten van het verifiëren van attestaties van state committee nodes te verhogen. Dit is de reden waarom Lagrange State Committees een potentieel onbegrensde set nodes kunnen ondersteunen en superlineaire beveiliging kunnen vertonen naarmate er meer kapitaal in state committees wordt gebundeld. U kunt meer over deze eigenschap leren in ons bericht over het schalen van programmeerbaar vertrouwen op EigenLayer met ZK Big Data .

Het integreren van Lagrange State Committees met de ZK Big Data stack heeft ook meer directe voordelen voor clienttoepassingen die gebruikmaken van Lagrange state proofs. We kunnen bijvoorbeeld de zkMapReduce-functie van de Lagrange Coprocessor gebruiken om meerdere state proofs van n optimistische rollup chains te combineren in één multi-chain state proof . Dit maakt 'nested verification' mogelijk, waarbij één enkele on-chain transactie gelijktijdig de status van meerdere optimistische rollups verifieert en de verificatiekosten voor clientservices verlaagt.

#2: De Lagrange Coprocessor integreert met het Lagrange State Committee-netwerk om betrouwbare off-chain berekeningen mogelijk te maken

De Lagrange Coprocessor, die we in een volgend bericht uitgebreid zullen analyseren, ondersteunt goedkope en schaalbare berekeningen op on-chain data door berekeningen off-chain uit te voeren. Cross-chain interoperabiliteitsprotocollen die integreren met de Lagrange State Committees kunnen ook integreren met de Lagrange Coprocessor, om het uitbreiden van hun cross-chain aanbod met verifieerbare berekeningen te vergemakkelijken.

Bijvoorbeeld, een ontwikkelaar die een multi-chain lending applicatie bouwt, wil misschien de som van het onderpand berekenen dat door een gebruiker is gestort over n verschillende rollups. Onze vriendelijke ontwikkelaar kan de Lagrange Coprocessor gebruiken om deze waarde te berekenen, met behulp van welke block header source het cross-chain protocol al op vertrouwt.

Waarom het netwerk van staatscomités van Lagrange een game-changer is voor interoperabiliteit in optimistische rollups

Gedeelde, superlineaire beveiliging voor optimistische rollup light-klanten

Momenteel zijn interoperabiliteitsprotocollen die bridging tussen optimistische rollup-ketens ondersteunen onafhankelijk verantwoordelijk voor het verifiëren van de status van bronketens. De beveiliging van deze interoperabiliteitsprotocollen is afhankelijk van het mechanisme voor het verifiëren of een blokheader correct is.

Sommige cross-chain communicatieprotocollen proberen vertrouwensveronderstellingen te verminderen door native staking te implementeren en een set verifiers te vragen om collateral te binden voordat ze attesteren op block headers van source chains. Dit fragmenteert echter de economische veiligheid over verschillende cross-chain protocollen, omdat de kosten van het corrumperen van een subset ( k van n ) van de validatorset van elk protocol lager zijn.

Daarentegen staan Lagrange State Committees meerdere cross-chain protocollen toe om beveiliging af te leiden van een enkele , dynamische set validators die kunnen schalen naar een onbeperkte grootte. Dit verandert de status quo, waarbij elk interoperabiliteitsprotocol onafhankelijk verantwoordelijk is voor het verifiëren van de nauwkeurigheid van cross-chain states, naar een status waarin meerdere applicaties cross-chain state van een enkele bron kunnen consumeren.

In tegenstelling tot andere light client-protocollen ondersteunt het State Committee-netwerk van Lagrange een dynamische, onbegrensde set van attesterende knooppunten. Het economische gewicht van handtekeningen die elke attestatie beveiligen, kan daarom dynamisch schalen naarmate er meer belang wordt gebundeld in de state committees, wat een superlineaire toename van de beveiliging mogelijk maakt en de moeilijkheid van het aanvallen van geïntegreerde cross-chain-protocollen in isolatie vergroot.

Dit maakt het Lagrange State Committee effectief een "gedeelde beveiligingszone" waar elk cross-chain protocol (ongeacht de grootte) in kan pluggen voor maximale beveiliging, vergelijkbaar met hoe de Relay Chain op Polkadot en Cosmos Hub op Cosmos secundaire netwerken in het multichain ecosysteem beveiligen. Bovendien stelt integratie met EigenLayer's resttaking middleware het Lagrange State Committee netwerk in staat om de economische beveiliging van Ethereum uit te breiden om een willekeurig aantal downstream cross-chain communicatieprotocollen te beveiligen.

Minder overhead voor cross-chain productontwikkelingsteams

Een ontwikkelaar die vandaag de dag een cross-chain interoperabiliteitsprotocol bouwt, moet infrastructuur ontwikkelen om onafhankelijk watchers te laten draaien om de status van elke optimistische rollup die ze ondersteunen te verifiëren. Naarmate het aantal geïntegreerde optimistische rollups groeit, neemt de infrastructuuroverhead van het beheer van beveiliging in elke origin chain toe.

Integratie met het Lagrange State Committee stelt de ontwikkelaar in staat om hun beveiliging uit te besteden en in plaats daarvan hun middelen te richten op het optimaliseren van hun productfuncties. Om dit in context te plaatsen: elk Lagrange-statusbewijs is licht genoeg om efficiënt te worden geverifieerd op elke EVM-compatibele keten.

Extra beveiliging voor bestaande interoperabiliteitsprotocollen

Lagrange-statusbewijzen zijn agnostisch voor de transportlaag die wordt gebruikt om ze naar een of meer bestemmingsketens te transporteren, waardoor interoperabiliteitstoepassingen naadloos Lagrange-statusbewijzen kunnen stapelen met bestaande beveiligingsmechanismen. Een cross-chain oracle of cross-chain messaging protocol met een onafhankelijke verifierset kan bijvoorbeeld een Lagrange-statusbewijs verifiëren als een extra beveiligingsmaatregel voordat cross-chain berichtverzoeken van optimistische rollups worden doorgestuurd.

Bovendien kan een bestaand interoperabiliteitsprotocol, eenmaal geïntegreerd met het Lagrange State Committee-netwerk, ondersteuning toevoegen voor optimistische rollups zonder dat validators het aantal ketens dat ze monitoren hoeven te verhogen. Door gebruik te maken van state proofs van het Lagrange State Committee-netwerk, hoeven validators alleen berichtverzoeken door te sturen tussen rollups. Een gateway-contract op de bestemmingsketen kan vervolgens het bestaan van berichten valideren die door relayers zijn doorgegeven door een Lagrange state proof te verifiëren.

Hoe verhoudt het Lagrange State Committee-netwerk zich tot andere cross-chain beveiligingsmechanismen?

Lagrange State Committees zijn gunstig te vergelijken met bestaande interoperabiliteitsinfrastructuur die gebruikmaakt van bonded staking/slashing, permissioned validation en optimistische verificatiemechanismen (onder andere) om de beveiliging van cross-chain state proofs te verbeteren. Hieronder staan enkele vergelijkingen:

Externe verificatie door toestemmingsloze validators

Lagrange's resttaking model verzacht een belangrijk probleem in cross-chain beveiligingsmechanismen die pure PoS staking voor beveiliging implementeren: risk stacking . Neem bijvoorbeeld een cross-chain protocol dat vereist dat validators de native token van een protocol kopen en vergrendelen voor de bondingperiode. Naarmate de populariteit van de native token van het cross-chain protocol verandert, beïnvloedt de volatiliteit van de prijs van het activum de totale economische beveiliging van het netwerk.

Prijsvolatiliteit is minder een probleem voor het Lagrange State Committee-netwerk, aangezien de beveiliging van committee-nodes is gebaseerd op opnieuw gezette collateral via EigenLayer. Bovendien heeft opnieuw gezette collateral de opportuniteitskosten voor potentiële validators verlaagd, wat betekent dat er meer deelname is aan state committees en een hoger niveau van economische beveiliging voor interoperabiliteitsprotocollen. Voor gebruikers betekent dit lagere kosten en meer beveiliging vergeleken met interoperabiliteitsprotocollen die hun beveiliging onafhankelijk opstarten.

We merken ook op dat consensusprotocollen die worden gebruikt in traditionele Proof-of-Stake beperkingen opleggen aan het aantal validators (bijvoorbeeld Tendermint BFT beperkt deelname tot 100-200 validators) en voorkomen dat traditionele PoS-protocollen de economische beveiliging zo vaak als nodig schalen. Omgekeerd gebruikt het Lagrange State Committee-netwerk een attestatiemechanisme dat een potentieel onbegrensde set knooppunten ondersteunt die deelnemen aan consensus. Dit zorgt ervoor dat het netwerk het aantal attestors dynamisch kan verhogen en bij uitbreiding robuustere garanties kan bieden voor economische beveiliging voor clienttoepassingen.

Externe verificatie door gemachtigde validatoren

Proof-of-Authority (PoA)-gebaseerde cross-chain protocollen vertrouwen op attestaties om headers van een kleine set van gemachtigde nodes te blokkeren. Deze benaderingen hebben zich historisch onveilig bewezen met opvallende incidenten, waaronder de Ronin-hack (5 van de 7 validators gecompromitteerd) en Harmony One bridge-hack (2 van de 5 validators gecompromitteerd).

Het gebruik van een permissionless gevalideerd systeem zoals het Lagrange State Committee-netwerk vermindert de efficiëntie enigszins vergeleken met een gecentraliseerde operator of validatorset met ondertekeningsheaders. Maar gezien de hoeveelheid die op het spel staat, beschouwen we dit als een verstandige afweging. Permissionless gevalideerde systemen verkleinen ook het aanvalsoppervlak voor bedrijven die, vaker wel dan niet, uiteindelijk de meerderheid van de validators in een permissioned systeem laten draaien.

Canonieke overbrugging

Het Lagrange State Committee-netwerk elimineert de latentie van het verzenden van cross-chain-berichten van optimistische rollups. Elke LSC fungeert als een "snelle modus" voor bruggen en berichtenprotocollen waarvan de gebruikers willen overbruggen van een optimistische rollup zonder het challenge window af te wachten. Optimistische rollups profiteren ook direct van de fast-finality-eigenschap van de LSC, omdat het een belangrijk UX-pijnpunt voor L2-gebruikers oplost.

Deze garantie is afgeleid van de observatie dat: (a) het slashing-mechanisme is ontworpen om de kosten van vijandige acties te verhogen, en (b) slashing van colluding nodes in een LSC on-chain kan gebeuren in slow mode omdat er een variabele tijdvertraging is bij het intrekken van stake. Samenvattend, deelnemers aan een LSC hebben altijd de prikkel om te bevestigen om cross-chain states te corrigeren, wat cross-chain applicaties in staat stelt om state proofs van een LSC onmiddellijk en met minimale vertrouwensveronderstellingen te gebruiken die worden ondersteund door de canonieke bridge van de rollup.

Conclusie

Dit artikel heeft behoorlijk wat terrein bestreken en we hopen dat het lezen ervan leerzaam is geweest - zo niet waardevol - voor bouwers, investeerders, liefhebbers en gebruikers in de interoperabiliteitsruimte. In de loop van dit artikel hebben we de definitie van gedeelde beveiliging onderzocht, wat het betekent voor het ontwerpen van veilige protocollen en hoe cross-chain interoperabiliteit kan profiteren van integratie met gedeelde beveiligingsinfrastructuur.

We hebben ook Lagrange State Committees verkend: onze gedeelde security-as-a-service-oplossing die is ontworpen met cross-chain communicatieprotocollen in gedachten. Lagrange State Committees is onderdeel van onze visie om veilige, trust-minimalized en efficiënte interoperabiliteit mogelijk te maken en zal deel uitmaken van een grotere stack waarmee ontwikkelaars krachtige cross-chain-applicaties voor gebruikers kunnen bouwen.

De multichain-toekomst is onvermijdelijk en het is belangrijk dat gebruikers van één chain naar 10.000-en chains kunnen gaan zonder significant verlies van beveiliging. Oplossingen zoals Lagrange State Committees (samen met andere ontwikkelingen in cross-chain security) zijn cruciaal voor dit doel. Nu interoperabiliteit meer aandacht krijgt dan ooit, is een wereld waarin bewegen tussen chains veilig en efficiënt is, zeer goed binnen bereik van cryptogebruikers over de hele wereld.

Dankbetuigingen

Emmanuel Awosika ( 2077 Research ), Omar Yehia ( Lagrange Labs ), Ismael Hishon-Rezaizadeh ( Lagrange Labs ) en Amir Rezaizadeh ( Lagrange Labs ) hebben bijgedragen aan dit artikel. Emmanuel werd door Lagrange Labs gecontracteerd om het schrijven van dit artikel te ondersteunen.

Een versie van dit artikel werd eerder hier gepubliceerd.