Mer än $100,000 låsta: Vikten av trustless-förvaring i ljuset av Unibtc-frysningsepisoden

Originalkälla: DeepSafe Research

Den 23 april 2025 bad en nätanvändare vid namn Brain om hjälp via Twitter genom en vän. Han sade att över $100,000 av unibtc-tillgångar var låsta av Bedrock-tjänstemän och inte kunde dras tillbaka. Enligt en rapport från en part W, upptäckte han den 17 april att priset på unibtc, som utfärdats av Bedrock på en viss Bitcoin Layer 2-kedja, var onormalt och avvek från BTC-priset. W trodde initialt att avvikelsen var tillfällig och snart skulle återgå till sitt ankare. Han ansåg att det fanns en bra arbitragemöjlighet och överförde en del BTC till Bitcoin Layer 2, bytte den mot unibtc och sålde sin tillgång efter att den återgått till ankaret.

Inom 24 timmar efter avvikelsen återvände unibtc till sitt ankare, men när W försökte sälja sin unibtc märkte han att unibtc-BTC likviditetspoolen på kedjan hade tagits bort av Bedrock-tjänstemän, vilket gjorde denna token till den enda sekundära marknadsutgångskanalen för unibtc på kedjan. W kunde inte sälja sin unibtc, så han försökte överföra den till andra kedjor. När han hittade den enda gränsöverskridande bron, som heter Free, fick han en uppmaning: ”Transaktionen kräver signaturbehörighet från projektparten.” W kontaktade kundtjänsten för Free Bridge, som förklarade: ”Multi-signaturnyckeln för unibtc cross-chain hanteras av Bedrock. Utan deras tillstånd kan användare inte överföra unibtc till andra kedjor.” W hade inget val än att leta efter en Bedrock-anställd för att fråga om situationen. Den anställdas första svar var: ”Vi kan tillåta dig att ta ut din huvudinsats, men om du kan ta ut vinsten från arbitrage är fortfarande under utvärdering.” Vid denna tidpunkt insåg W att utgångsvägen för unibtc på denna kedja var helt blockerat, och unibtc, värd cirka 200,000 U, var ”tillfälligt frusen” – det fanns ingen möjlighet att sälja den på denna kedja eller att överföra den till andra kedjor.

W kände sig mycket hjälplös och ville bara dra tillbaka sitt kapital smidigt. Men attityden hos Bedrock-personalen var vag; de angav varken tydligt när W skulle kunna ta ut sitt kapital eller gav något skriftligt åtagande. Processen fördröjdes av skäl som ”riskgranskning” och ”teknisk utredning”. Efter en tid hävdade Bedrock att unibtc-avvikelsen orsakats av någon på LayerBank-plattformen som lånat en stor mängd unibtc-tillgångar och dumpat marknaden, och föreslog W att ”hålla LayerBank ansvarigt”. Efter att W kontaktade LayerBank fick han inget svar under en längre tid. I desperation bad W om hjälp från sina vänner på Twitter. Efter mer än två veckors förhandlingar fick han äntligen ett positivt svar från LayerBank och Bedrock-tjänstemännen och lyckades återfå sina tillgångar.

Ws erfarenhet är inte ett isolerat fall. Enligt återkoppling från andra drabbade använde Bedrock också liknande metoder för att blockera användarnas unibtc-utgångsvägar förra året, vilket resulterade i att dessa unibtc blev ”substantielt frusna”. Denna artikel ämnar inte att spekulera i orsakerna bakom dessa händelser, utan förklarar bara ur ett tekniskt perspektiv hur man undviker och eliminerar liknande centraliserade mönster av beteende.

Bedrocks Centraliserade Makt

Genom att granska ovanstående händelser kan vi se att Bedrock, som utfärdare av unibtc och den initiala likviditetstillhandahållaren för den sekundära marknadens likviditetspool, uppenbarligen hade makt att stänga av den sekundära marknaden för unibtc. Om dess makt ska begränsas bör det göras genom styrning snarare än tekniska medel. Samtidigt avslöjade kollusionen mellan Free Cross-Chain Bridge och Bedrock vid avvisningen av användarförfrågningar som nämnts ovan uppenbara tekniska brister hos unibtc i kedjan av ”utfärdande – enskikts cirkulation – multichain cirkulation.” Free Cross-Chain Bridge, som en partner till Bedrock, är uppenbarligen mycket centraliserad. En verkligt trustless bro bör säkerställa att bromyndigheterna inte kan hindra användarna från att lämna. Men i fallet med unibtc-frysningen har både Bedrock och Free Cross-Chain Bridge stark centraliserad auktoritet och erbjuder inte censurresistenta utgångskanaler.

Några av dessa fall, liknande det som hände med unibtc, är tyvärr inte ovanliga. Att stänga av användarens utgångsvägar är vanligt förekommande på större börser. För gränsöverskridande broar eller andra typer av projektparter finns det också talrika fall av centraliserad auktoritetsutnyttjande. I juni 2022 stoppade Harmony Horizon Bridge uttag för 57 tillgångar på grund av en hackattack. Även om detta beteende kan ha ”legitima skäl,” väcker det fortfarande oro hos användarna. Vi ser även exempel på StableMagnet-incidenten 2021, där projektägaren stal $24 miljoner genom en programmerad läcka. Hongkong och Storbritannien kunde återhämta 91% av de stulna pengarna med hjälp av samhället. Dessa exempel illustrerar tydligt att om tillgångsförvaltningsplattformen inte kan erbjuda trustless-tjänster, leder det oundvikligen till negativa konsekvenser.

Utmaningar med Trustlessness

Men konceptet trustless är inte lätt att uppnå. Från betalningskanaler och DLC till BitVM och ZK Rollup har det gjorts många försök att hitta lösningar. Detta kan i stor utsträckning garantera användarsjälvständighet och möjliggöra pålitliga tillgångsuttag, men fortfarande finns det oundvikliga brister. Betalningskanaler kräver till exempel att parterna övervakar potentiellt illvilligt beteende från motparten, och DLC är beroende av orakler. BitVM kan vara kostsamt att använda, och det finns andra tillitsantaganden inblandade i praktiken. ZK Rollups utrymningslucka kan endast aktiveras efter en lång period och kräver att rollupen först stängs, vilket också medför betydande kostnader.

Sett till nuvarande implementeringar av större tekniska lösningar kan vi konstatera att det inte finns någon perfekt tillgångsförvaring eller utgångslösning, och marknaden behöver fortfarande innovation. DeepSafe Research kommer i det följande att ta den officiellt lanserade tillgångsförvaringslösningen från DeepSafe som exempel för att förklara en trustless meddelandeverifieringslösning som kombinerar TEE, ZK och MPC. Denna lösning balanserar de oförenliga indikatorerna av kostnader, säkerhet och användarupplevelse och kan tillhandahålla pålitliga grundläggande tjänster för handelsplattformar, gränsöverskridande broar, eller alla scenarier för tillgångsförvaring.

CRVA: Kryptografiskt Slumptals-Veriferingsnätverk

För närvarande använder de mest utbredda tillgångsförvaltningslösningarna på marknaden mestadels multi-signatur eller MPC/TSS för att fastställa om en tillgångsöverföringsbegäran är giltig. Fördelarna med dessa lösningar är enkel implementation, låg kostnad och snabb meddelandeverifiering, men nackdelarna är uppenbara – det är inte tillräckligt säkert och tenderar att bli centraliserat. I Multichain-fallet 2023 kontrollerades alla 21 noder som deltog i MPC-beräkningen av en person, vilket är en typ av trollanfall. Detta visar tydligt att ett fåtal noder, även om de uppvisar decentralisering, inte erbjuder tillräcklig säkerhet. Med det i åtanke har DeepSafe’s CRVA-lösning gjort flera förbättringar.

Först och främst, knutpunkterna i nötnätverket antar en accessform för tillgångspantsättning och huvudnätverket kommer inte att startas officiellt förrän cirka 500 noder har uppnåtts. Beräkningar tyder på att de tillgångar som pantsätts av dessa noder kommer att uppgå till tiotals miljoner dollar eller mer under en längre tid. För det andra, CRVA kommer att slumpa ut noder genom en lotterialgoritm, såsom 10 noder var halvtimme, som kommer att fungera som verifierare för att kontrollera om användarbegäran bör godkännas – dessa kommer att generera motsvarande tröskelsignatur för att släppa begäran. För att förhindra intern kollusion eller externa hackattacker, använder CRVAs lotterialgoritm en unik ring VRF, tillsammans med ZK för att dölja identiteten på den valda, vilket förhindrar att omvärlden kan observera den valda direkt.

Självklart är detta dock inte tillräckligt. Även om omvärlden inte vet vem som har valts, har den valda personen denna information, vilket öppnar upp för kollusionsrisk. För att ytterligare förhindra kollusion måste alla noder i CRVA köra kärnkoden i TEE-hårdvarumiljön, vilket innebär att de centrala arbetsmomenten hålls i en svart låda. På så sätt kan ingen veta om de har valts, om de inte kan bryta TEE:s betrodda hårdvara. Att uppnå detta är dock extremt svårt under dagens tekniska förhållanden. Föreliggande slutsatser utgör grunden för DeepSafes CRVA-lösning. I det faktiska arbetsflödet krävs en omfattande sändningskommunikation och informationsutbyte mellan noder i CRVA-nätverket. Processen är följande:

1. Innan en nod går med i CRVA-nätverket måste den först pantsätta tillgångar på kedjan och lämna en offentlig nyckel som registreringsinformation. Denna offentliga nyckel kallas också ”permanent offentlig nyckel.”
2. Varje timme kommer CRVA-nätverket slumpmässigt att välja flera noder. För att detta ska ske måste alla kandidater lokalt generera en engångs ”tillfällig offentlig nyckel” och producera en ZKP för att bevisa att den ”tillfälliga offentliga nyckeln” är kopplad till den ”permanenta offentliga nyckeln” som registrerats på kedjan. Med detta avses att alla måste använda ZK för att bevisa att de finns i kandidatlistan, utan att avslöja sin identitet.
3. Den ”tillfälliga offentliga nyckeln” skyddar integriteten. Om alla drar direkt från uppsättningen av ”permanenta offentliga nycklar” kommer alla att veta vem som har valts när resultaten tillkännages. Genom att låta alla endast exponera en engångs ”tillfällig offentlig nyckel” och därefter välja ett par personer från uppsättningen ”tillfälliga offentliga nycklar” kommer det att vara otydligt för alla vem som har valts, endast att någon har fått ”lotto”.
4. För att ytterligare förhindra identitetsläckage kommer CRVA att sträva efter att få deltagarna att inte veta vad deras ”tillfälliga offentliga nyckel” är. Genereringsprocessen för den tillfälliga offentliga nyckeln kommer att genomföras i TEE-miljön för noden, och den som kör TEE kommer inte att se vad som händer inuti.
5. Den tillfälliga offentliga nyckeln krypteras i klartext till ”garbled code” i TEE och skickas till omvärlden, där endast en specifik Relay-nod kan återställa den. Återställningsprocessen genomförs också inom TEE-miljön för Relayer-noden, som inte vet vilka kandidater dessa tillfälliga offentliga nycklar motsvarar.
6. När Relayer har återställt alla ”tillfälliga offentliga nycklar” sammanställer den dem och skickar dem till VRF-funktionen på kedjan, där vinnarna väljs. Dessa verifierar transaktionsbegäran från användarens front-end och genererar därefter en tröskelsignatur baserat på verifieringsresultatet, som ska skickas tillbaka till kedjan (observera att Relayer också är dold och väljs regelbundet).

Vissa kan ställa frågan, hur kan arbetet utföras om varje nod inte vet om de är valda? Faktum är att, som tidigare nämnts, kommer alla att generera en ”tillfällig offentlig nyckel” i den lokala TEE-miljön. När resultatet av valet tillkännages, kommer vi att skicka ut en lista på vald. Alla behöver bara utföra kontroll av listan i TEE och se om de är valda. Kärnan i DeepSafe är att nästan alla viktiga aktiviteter utförs i TEE-hårdvaran, vilket förhindrar observation utanför. Varje nod vet inte vem som är den valda verifieraren, vilket förhindrar kollusion och ökar kostnaderna för externa attacker. För att angripa CRVA-kommittén baserat på DeepSafe skulle det krävas att hela CRVA-nätverket teoretiskt angrips. Dessutom skyddas varje nod av TEE, vilket försvårar attacken avsevärt.

När det kommer till CRVAs self-custody-lösning, har vi introducerat de allmänna principerna för CRVA och förklarat hur CRVA kan uppnå decentralisering och trustlessness. Nu kommer vi att använda den algoritmiska stablecoin, HelloBTU, som exempel för att ytterligare förtydliga tillämpningen av CRVA i lösningar för tillgångar. Som vi alla vet kan vi inte direkt implementera komplex smart kontraktslogik som Defi på Bitcoin-kedjan eftersom den inte har en Turing-komplett miljö. Den rådande BTCFi-strategin innebär att brygga Bitcoin till andra kedjor för att interagera med smarta kontrakt. Den smarta kontraktsdelen av HelloBTU är implementerad på Ethereum. Användare kan deponera BTC på den betalningsadress som anges av HelloBTU, varefter den officiella bron kommer att överföra BTC till Ethereum-kedjan och interagera med HelloBTUs stabila smarta kontrakt.

Anta att en användare vill pantsätta 10 BTC till HelloBTU-plattformen. Den specifika operationen innebär att först överföra de 10 BTC till en Taproot-adress på Bitcoin-kedjan. För att låsa upp dem krävs 2/2 multi-signatur, där den ena signaturen genereras av användaren och den andra av CRVA. Det finns flera scenarier involverade här: Om användaren, efter att ha överfört de 10 BTC till Taproot-adressen, vill mynta stablecoins av dessa 10 BTC och därefter har avsikt att lösa in BTC, måste både användaren och CRVA generera en signatur för att låsa upp de 10 BTC och föra dem tillbaka till användarens adress. Om CRVA inte samarbetar under en lång tid kan användaren, efter att tidslåset löpt ut, unilateralt ta tillbaka de 10 BTC. Denna funktion kallas ”användarinitierad inlösen.”

En annan situation kan vara att användarens BTC, som används som säkerhet, har likviderats. Nu behöver han samarbeta med CRVA för att överföra dessa BTC och överlämna dem till CRVA:s en-vägs-kanal. Men användaren kan vägra att samarbeta, och då blir dessa BTC tillfälligt låsta, ingen kan ta dem. När tidslåset löpt ut kan CRVA överföra dessa medel till en Taproot-adress som kontrolleras av CRVA (CRVA en-vägs-kanal). Här är det enda att notera att tidslåset för BTC att gå in i CRVA en-vägs-kanal är relativt kort, medan tidslåset för användaren att lösa in dem på egen hand är längre. Med andra ord, om CRVA och användaren inte kan samarbeta, kommer dessa BTC i slutändan att gå in i CRVA en-vägs-kanalen först. Detta förhindrar effektivt användarbeteende som undviker skulder och missbruk av systemet.

Vid illvilligt beteende från CRVA, eftersom CRVA är ett automatiskt driftat nodnätverk, så länge koden vid initieringen inte innehåller illvilliga funktioner, kommer CRVA i stort sett inte att vägra samarbeta med användarna. Sådana farhågor kan därför ignoreras. Om däremot CRVA-noder tystas på grund av force majeure, som strömavbrott eller översvämningar, kan användare fortfarande dra tillbaka sina tillgångar på ett säkert sätt enligt den proces som beskrivits tidigare. Tillitshypotesen här grundar sig på att vi litar på att CRVA är tillräckligt decentraliserad och inte kommer att agera illvilligt (vilket har förklarats fullt ut ovan). Om BTC överförs till CRVA en-vägs-kanalen, indikerar detta i många fall att den motsvarande on-chain stabila positionen har likviderats, och den faktiska äganderätten till BTC tillhör likvidatorn. Likvidatorn kan initiera en uttagsbegäran, som kommer att granskas av CRVA. Om godkänd kommer CRVA att generera en signatur och överföra motsvarande belopp av BTC till likvidatorn. I den här situationen, om CRVA dröjer med svar, kommer dessa BTC, efter att tidslåset löpt ut, att överföras till en adress som kontrolleras av en DAO. Denna operation utlöses av multi-signatur och den efterföljande handläggningen styrs av DAO, vilket består av välrenommerade projektparter, säkerhetsbolag och investeringsinstitutioner, och som inrättas för att förhindra illdåd från enskilda enheter.

Sammanfattningsvis har vi grovt förklarat DeepSafes själv-förvaltningslösning för Bitcoin-tillgångar. För ERC-20-tillgångar är principen liknande och kommer inte att tas upp här.