tBTC: Navigera i kedjekedjan

tBTC: Navigera i kedjekedjan

i8v8i#3955

Vi genomförde nyligen en säkerhetsanalys av avhandlingens tBTC: en förtroendeminimerad, inlösbar, Bitcoin-stödd ERC20-token. Projektet, som använder Keep Network för att spänna över Bitcoin och Ethereum, syftar till att möjliggöra en ny kedjekonomi genom att tillåta användare att göra transaktioner på Ethereum med hjälp av Bitcoin-backad ERC20. Vår rapport finns offentligt tillgänglig här.


Det är inte ofta vi får granska ett projekt som tBTC. När allt kommer omkring spänner tBTC över flera system: Bitcoin, Ethereum och Keep Network. De smarta kontrakten som underlättar all denna interoperabilitet är ganska komplexa och kräver förståelse för alla tre protokollen. Även om vårt tidigare arbete med Liquality and Atomic Loans har liknande karaktär, sätter tBTC: s massiva kodbas det på en annan nivå.


Under vår granskning lärde vi oss mycket om utvecklingen av tvärkedjessystem. I synnerhet avslöjade vår forskning om Bitcoin-transaktioner en särskilt intressant begränsning av Bitcoin-transaktionsverifiering på Ethereum. Vi utvidgar denna upptäckt här.

Vad är ett SPV-bevis?

I samband med Bitcoin används ett SPV-bevis för att bevisa förekomsten av en transaktion inom ett visst block. Enkelt uttryckt kopplar beviset ett Merkle-bevis med ett Bitcoin-block hashMerkleRoot för att visa att det finns en transaktion inom blocket:

Låt oss säga att vi vill bevisa att det finns någon transaktion på Bitcoin. För detta SPV-bevis behöver vi några ingångar:

1 Blockhuvudet för det block som innehåller transaktionen

2 Själva råtransaktionen

3 Transaktionens index (dess position i blocket)

4 Ett märksäkert (en lista över noder som bildar en "sökväg" från transaktionen till Bitcoin-blockhuvudet)

Med hjälp av dessa ingångar är det möjligt att bevisa att det finns en transaktion i blocket, allt utan att behöva ansluta till en Bitcoin-nod. Förutsatt att man accepterar att den tillhandahållna Bitcoin-blockhuvudet härstammar från den längsta proof-of-work-kedjan, kan Simple Payment Verification (SPV) äga rum var som helst, på vilken enhet som helst.

Den tvärgående kedjan

Under undersökningen av Bitcoin-transaktioner kom vi över en grundläggande begränsning av SPV-bevis som utförts på Ethereum: Bitcoin-transaktionsstorlek.

Bitcoin-transaktioner begränsas främst av den maximala Bitcoin-blockstorleken på 4 MB. Eftersom SPV-bevis kan utesluta vittnesdata kan vi dessutom minska den teoretiska maximala Bitcoin-transaktionsstorleken till 1 MB. För våra ändamål bestäms dock inte den exakta övre gränsen av Bitcoin-blockstorleken, eftersom det faktiskt visar sig vara begränsat av Ethereum-blockkedjan.

Varför? Till skillnad från Bitcoin begränsas Ethereums transaktioner av mängden beräkningsresurser deras körning förbrukar. Varje operation som utförs kräver en viss mängd gas och transaktioner kan inte konsumera mer gas än det som finns i ett enda block. Detta kallas gasgränsen, som i skrivande stund är cirka 10 miljoner gaser.

För att förstå hur detta ungefär motsvarar Bitcoin-transaktionsstorlek kan vi använda en definition från Ethereums gula papper, Gtxdatanonzero, vilket är den gaskostnad som krävs för varje byte av data i en transaktion. Gtxdatanonzero är 16 gas per byte.

Detta innebär att varje byte i en Bitcoin-transaktion som levereras som en del av ett SPV-bevis förbrukar minst 16 gaser. Observera att det är extra kostnader för att utföra ett SPV-bevis, men jag ignorerar dem för denna grova uppskattning.

Så hur stor kan en Bitcoin-transaktion bli innan det blir omöjligt att utföra ett SPV-bevis på Ethereum? Svaret är Ethereums blockgasgräns dividerat med Gtxdatanonzero:

(10.000.000 gas) / (16 gas per byte) = 625.000 byte, eller cirka 63% av den maximala Bitcoin-transaktionsstorleken på 1 MB.

Vad betyder detta för tBTC?

I tBTC tjänade SPV-bevis ursprungligen två syften:


1 Insättningsbevis: tillät användare att bevisa att de hade gjort en BTC-insättning korrekt, vilket utlöste tBTC-kontrakten för att släppa motsvarande Bitcoin-stödda ERC20.

2 Bedrägeribevis: tillät användare att bevisa att en BTC-insättning hade spenderats utan tillstånd av insättnings depåbevakningsgrupp, vilket utlöste underskridande och tilldelade en obligation till insättningsägaren.

Bedrägeribevis

SPV-bedrägeribevis tillät användare att skydda mot skadliga undertecknare. Om en signerergrupp samarbetar kan de spendera deponerad BTC utan uttryckligt tillstånd från användaren. Genom att leverera denna obehöriga transaktion till tBTC: s kontrakt, kunde användarna bevisa att utgifterna inträffade, straffa de skadliga undertecknarna och se till att de fick rättvis kompensation för förlusten av sin insättning.

Men med hjälp av Bitcoin-transaktionsstorleksbegränsningen som beskrivs ovan kan undertecknare undvika detta påföljd genom att spendera insättningen i en tillräckligt stor transaktion.

Lyckligtvis var SPV-bedrägeribevis en av två bedrägerisäkra mekanismer som implementerades i tBTC. Den alternativa metoden, ECDSA-bedrägeribevis, gav ett mycket mer robust alternativ till SPV-bedrägeribevis. Som ett resultat avlägsnades SPV-bedrägeribevis från tBTC: s kontrakt.

Sätt in bevis

Insättningsbevis används fortfarande i tBTC när varje användare går in i systemet. För att släppa Bitcoin-backad ERC20 på Ethereum måste användare tillhandahålla ett SPV-bevis på framgångsrik insättning. Även om problemet med Bitcoin-transaktionsstorlek inte ger en tydlig metod för att missbruka insättningssystemet är det möjligt att en användare kan finansiera en insättning med en giltig BTC-transaktion, bara för att finna att deras transaktion är för stor och inte kan valideras inom tBTC-kontrakten .

Det finns ingen tydlig väg för att ta bort detta beroende. SPV-bevis måste tillhandahållas för att validera en insättning. Lyckligtvis är begränsningen av Bitcoin-transaktionsstorlek inte så allvarlig att den förhindrar att tBTC fungerar helt. en enkel spendering med en enda ingång och utgång ligger inom gränserna för Ethereums nuvarande blockgasgräns. Så länge försök görs för att säkerställa att användare är tillräckligt medvetna om denna begränsning, bör Bitcoin-transaktionsstorlek inte utgöra en betydande fråga vid finansiering av insättningar.

Vad kan tBTC (och andra kedjeprojekt) göra för att säkerställa att deras system fungerar korrekt?

Förstå de båda kedjornas primitiva. När du använder Ethereum, förstå var EVM brister när det gäller att replikera primitiverna för andra kedjor. Kedjeapplikationer överbryggar två världar, var och en med sitt eget tidssystem, regler och subtila gotchas.


  • Prestanda benchmarking ger en viss baslinje mot vilken systemet kan mätas. Till exempel, efter vår diskussion om Bitcoin-transaktionsstorleksfrågan, utförde Thesis några grundläggande benchmarking för att komma med mer exakta begränsningar för sina SPV-bevis.

Enhetstester räcker aldrig. Cross-chain dapps har av naturen rörliga delar i alla ändar av systemet. För att säkerställa att dessa delar fungerar tillsammans måste utvecklare gå längre än enkla enhetstester.


  • Integrationstestning hjälper till att avslöja inkonsekvenser i interaktionen mellan isolerade komponenter och kommer att ge en modell av systemet under närmaste förhållanden.

Förbered dig på det värsta. Med stor komplexitet kommer stort ansvar. Det är inte realistiskt att identifiera alla möjliga problem innan de släpps.


  • Beredskapsplan: Att ha en plan på plats för att snabbt reagera på problem kan stumma effekterna av allvarliga problem. Att skapa en beredskapsplan före lanseringen kan kräva arbete, men det är oändligt bättre än att vara oförberedd.

Slutligen utbilda dina användare. Att förstå var saker kan gå fel är en del av striden; nästa steg är att se till att dina användare delar din förståelse. För detta ändamål publicerade Matt Luongo från Thesis nyligen en lång tråd som beskriver tBTC: s säkerhetsmodell och styrning.


Uppdatering 16 maj 2020: Den här artikeln gav ursprungligen ett bensinpris på 68 per byte, som sedan har uppdaterats och nämnde inte att vittnesdata kan uteslutas från SPV-beviset. Tack till James Prestwich och Paul Vienhage för rättelserna.



Report Page