BitVM is onlangs onder de loep genomen nadat de Taproot Wizards, Tyler en Rijndael, hun kritiek hadden geuit op de liquiditeitsvereisten die werden opgelegd aan de exploitant van een op BitVM gebaseerde tweerichtingskoppeling. In alle recente discussies rond op BitVM gebaseerde laag twee-oplossingen ging ik ervan uit dat mensen die deze bespraken en geïnteresseerd waren in de ontwerpruimte, de onderpand-/liquiditeitsvereisten begrepen die door de architectuur aan de operator(s) werden opgelegd. De recente discussie rond de kwestie van de ‘liquiditeitscrisis’ laat zien dat ik ongelijk had over deze veronderstelling, en dat veel mensen buiten degenen die actief betrokken zijn bij de ontwikkeling van BitVM zich niet bewust waren van deze kwestie.
Voordat ik inga op de kwestie van de liquiditeitscrisis, denk ik dat het belangrijk is om een van de unieke eigenschappen van een BitVM-peg (door altcoin-ontwikkelaars bridges genoemd) te verduidelijken. Bij bruggen die op andere netwerken zijn gebouwd, worden de gelden in het eigenlijke overbruggingscontract dat de geldbeweging tussen netwerken regelt, gebruikt om opnames daadwerkelijk te verwerken. In het geval van een BitVM-koppeling zijn deze fondsen niet toegankelijk om opnames uit te voeren. De exploitant van het systeem (rollup, sidechain, etc.) moet daadwerkelijk over zijn eigen liquiditeit beschikken om opnameverzoeken van gebruikers te kunnen verwerken.
Wanneer er opnameverzoeken van gebruikers binnenkomen, bekijkt de operator feitelijk elk verzoek en verwerkt deze opnames met behulp van zijn eigen persoonlijke geld. Na een bepaalde periode controleert het systeem vervolgens zijn status in een cutoff, waarbij alle lopende opnames worden uitgevoerd. Na de exploitant heeft alle lopende opnames uit de laatste staat vervuld ze kunnen vervolgens een claimproces starten vanuit de door BitVM beveiligde fondsen om zichzelf gezond te maken voor al het kapitaal dat ze hebben ontvangen. Het BitVM-contract is opgesteld zodat operators de mogelijkheid hebben om deze fondsen te laten intrekken als ze niet alle lopende opnames uit de laatste staat hebben gehonoreerd.
De algemene gebruikersstroom is dus dat een aanbetaling in een contract gaat dat is beveiligd door BitVM, dat de operator zijn eigen kapitaal gebruikt om opnames te verwerken, en vervolgens compenseert de operator zichzelf periodiek voor het geld dat hij uit eigen zak heeft uitgegeven uit het BitVM-contract. Hierdoor onderscheidt een BitVM-peg zich van elk ander type tweerichtingspeg, waardoor een liquiditeitsvereiste wordt geïntroduceerd die vergelijkbaar is met het Lightning Network.
De liquiditeitscrisis
Het probleem dat Taproot Wizards in hun artikel hebben geïdentificeerd, is een gevolg van de combinatie van de liquiditeitsvereisten die vooraf aan de exploitant worden opgelegd en het fraudebestendige systeem dat de verificateurs van de BitVM in staat stelt de toegang van de exploitant tot fondsen in te trekken als zij dat niet hebben gedaan. alle opnames in een bepaald rollup-tijdperk vervuld. Dit creëert een groot potentieel probleem voor het systeem, en vooral voor de operator.
Laten we voorlopig het mogelijke scenario negeren waarin een operator opzettelijk weigert een opname te verwerken vanwege kwaadwillige censuur. Dat is op dit moment geen punt van zorg als we naar de potentiële problemen kijken, alsof een operator zoiets zou doen zou moeten hun toegang wordt ingetrokken en ze lopen het verlies op van het geld dat ze al hebben uitgegeven aan het verwerken van opnames.
Het is absoluut mogelijk dat een eerlijke exploitant in een situatie terechtkomt waarin hij, zonder kwade bedoelingen van zijn kant, geen toegang heeft tot voldoende liquiditeit om de opnames die in één keer worden verwerkt, te verwerken. Als dit zou gebeuren, kan een anderszins eerlijke operator zichzelf nu niet compenseren uit het BitVM-contract voor wat hij heeft gedaan hebben verwerkt zonder zich open te stellen voor één enkele verificateur die hen uitdaagt, waardoor zij permanent de toegang tot de fondsen verliezen. Alles wat ze in die periode hebben besteed aan het verwerken van opnames zou verloren geld zijn dat ze niet konden terugkrijgen.
Dit brengt een groot risico met zich mee voor een peg-operator. Door helemaal geen kwaadwillige actie te ondernemen, eenvoudigweg door beperkingen van hun eigen middelen, stijgende rentetarieven op het lenen van geld, slechts factoren van de tijd die nodig zijn om toegang te krijgen tot fondsen, kunnen ze een enorme hoeveelheid geld verliezen. Dit introduceert een grote potentiële instabiliteit in de koppeling, en het roept ook de vraag op waar het geld van de gebruikers naartoe gaat in het geval dat een operator wordt getroffen door een fraudebewijs?
De opties
Het belangrijkste om op te merken is dat waar de uiteindelijke bestemming van fondsen zich bevindt, afhangt van bepaalde ontwerpkeuzes die zijn gemaakt door de uitvoerders van een bepaalde koppeling. Er is een goede mate van vrijheid beschikbaar in ontwerpkeuzes, de eindbestemming van fondsen nadat een uitdaging is uitgeworpen, een operator heeft meerdere opties, de periode na het einde van een tijdperk waarin een operator alle opnames moet vervullen, is configureerbaar, geen van deze dingen is ingesteld in steen als enige mogelijke manier om ze te configureren.
Nu we het probleem begrijpen, gaan we eens kijken naar enkele mogelijke oplossingen.
Versnelling
U kunt dit probleem oplossen door opnames te beperken. Dit zou met zich meebrengen dat er een maximale limiet wordt gecreëerd voor de financiële middelen die een exploitant volgens het contract moet nakomen in een bepaald samenvoegtijdperk. Hierdoor zou de exploitant ervoor kunnen zorgen dat hij over voldoende kapitaal beschikt om het maximale bedrag te kunnen verwerken dat hij nodig heeft. Elke periode kon de exploitant zoveel opnames verwerken, het claimproces doorlopen om zichzelf te compenseren uit het BitVM-contract, en vervolgens in het volgende tijdperk dat bedrag recyclen om aan de volgende golf van opnames te voldoen.
Het probleem hiermee is dat je niet weet wanneer er een grote stijging zal plaatsvinden in de fondsen die aan het systeem zijn gekoppeld, en je weet ook niet wanneer de marktactiviteit zich zal aanpassen om een enorme hoeveelheid geld te stimuleren om zich uit het systeem te willen vastpinnen. . Naarmate er meer fondsen worden gekoppeld, neemt de mogelijkheid van een grote toename van het volume dat we in één keer willen afkoppelen toe. Deze dynamiek leidt in wezen tot een steeds groter wordende wachtrij om uit het systeem te komen, tenzij u het maximale epoch-opnamebedrag verhoogt, wat ook de liquiditeitsvereisten voor de exploitant verhoogt.
Dit verergert de liquiditeitsbehoefte die deze pinnen hebben, en creëert in wezen een enorme wrijving bij opnames. Swap-outs lossen het probleem niet op, omdat hierdoor uiteindelijk de liquiditeit van de tegenpartijen in deze steeds groeiende wachtrij terechtkomt, in tegenstelling tot andere tweerichtingskoppelingen waar ze vrijwel onmiddellijk na het faciliteren van de swap zouden kunnen uitstappen.
Meerdere operators
Zowel BitVM 1 als BitVM 2 ondersteunen het hebben van meerdere verificateurs op verschillende manieren, waardoor er meer dan één kan deelnemen en de toegang van een operator tot fondsen kan worden ingetrokken. Het is ook mogelijk in BitVM 2 (en sommige op BitVM gebaseerde pegs zoals de Citrea-combinatie) om meerdere operators parallel te laten werken. Er kan meer dan één entiteit zijn die opnames uit de koppeling helpt verwerken, zodat er meerdere liquiditeitspools beschikbaar zijn om de koppeling te vergemakkelijken.
Dit zou in principe de gehele liquiditeitsdynamiek veel schaalbaarder maken, omdat deze niet langer beperkt zou blijven tot één enkele entiteit die de liquiditeit moet verzorgen om tijdige terugtrekkingen uit het systeem mogelijk te maken, maar het introduceert vragen van complexiteit. Voor elke UTXO die in de BitVM-peg wordt gedeponeerd en aan het contract is gebonden, moeten de claimvoorwaarden zijn gedefinieerd. Dat contract moet nu onderscheid kunnen maken tussen meerdere exploitanten, en een manier bieden om te onderscheiden welke opnames aan welke exploitant zijn gekoppeld, en ervoor zorgen dat zij alleen aanspraak kunnen maken op wat zij hebben gefaciliteerd, in plaats van geld dat voor een andere exploitant bedoeld is.
Er moet ook rekening mee worden gehouden hoe moet worden omgegaan met de mondiale vraag naar opnames, waarvoor alle exploitanten bestaan. Wat als elke exploitant al zijn kapitaal heeft gebruikt, maar er nog steeds een onvervulde vraag is? Hebben ze allemaal toegang tot BitVM-fondsen die zijn ingetrokken? Geen van hen? Is er een respijtperiode voor het omrollen, vergelijkbaar met het gebruik van een wachtrij-throttle? Als dat zo is, wie is er dan verantwoordelijk als deze opnames de volgende periode nog steeds niet worden gefaciliteerd? Dit zijn allemaal zaken die concreet uitgewerkt moeten worden.
Meerdere lineaire operators
Naast meerdere parallelle operatoren kunt u ook een keten van lineaire operatoren hebben. Eén enkele operator zou tegelijkertijd kunnen functioneren, waardoor opnames mogelijk worden gemaakt, en als ze ooit een liquiditeitsprobleem zouden tegenkomen en hun toegang tot de BitVM-fondsen zou worden ingetrokken, zouden de fondsen na een uitdagings-/intrekkingsproces onmiddellijk naar een nieuwe BitVM kunnen worden gestuurd met een nieuwe exploitant. Dit zou helemaal geen oplossing bieden voor het risico dat een enkele exploitant in een liquiditeitscrisis zou terechtkomen, en dat hij zich het verlies zou realiseren van de opnames die hij al had gestort, maar het zou ervoor zorgen dat iemand anders zou kunnen ingrijpen en de kans zou krijgen om opnames te blijven faciliteren met de mogelijkheid om schadevergoeding te eisen van de BitVM.
Dit voegt echter veel kosten toe aan het peg-in-proces. Het genereren van een BitVM-instantie is niet goedkoop in termen van data en interactiviteit, wat betekent dat om lineaire BitVM-operators op deze manier aan elkaar te koppelen, u voor peg-ins dat aantal BitVM’s moet genereren.
De achterstop
In alle gevallen waarbij een koppeling met BitVM wordt gebruikt, is er één ultieme vraag: waar gaat het geld uiteindelijk naartoe als het in het ergste geval mislukt? Er zijn uiteindelijk twee opties. Of je verbrandt het geld daadwerkelijk, of je plaatst het onder controle van een verificateur. De eerste betekent dat het geld van gebruikers nu wordt vernietigd en dat iedereen die geld in de koppeling heeft nu ruig is. Het tweede betekent dat het vertrouwensmodel regelrecht is verschoven naar het vertrouwen van een individuele verificateur of een groep verificateurs in een federatie die eenzijdig de controle heeft over de fondsen.
Het verbranden van het geld is een non-starter in een model zonder opnamebeperking, omdat dat de zorgen van Taproot Wizards in het ergste geval zou bevestigen. Een consistent geval van falen van exploitanten, ongeacht parallel of lineair, zou ertoe leiden dat de fondsen van gebruikers daadwerkelijk worden vernietigd. Het enige model waarin dit ook maar enigszins veilig zou zijn, zou een terugtrekgasklep zijn; maar zelfs dan zou het risico van permanent verlies van middelen nog steeds bestaan als de in het contract gedefinieerde exploitant(en) zouden verdwijnen of hun toegang zou worden ingetrokken.
Dat betekent dus dat de fondsen weer onder de controle van één enkele verificateur of een groep daarvan moeten komen te staan. In het geval van een totale mislukking van alle exploitanten zou dit de bij het systeem betrokken verificateur(s) in staat stellen de gelden van de gebruikers terug te vorderen en deze te herstellen. Ik denk niet dat dit zo erg is.
Elke BitVM-instantie is opgezet met een n-of-n multisig die de ondertekening van alle vooraf ondertekende transacties in het BitVM-contract afhandelt. Het ultieme beveiligingsmodel van het hele systeem is dat één van die sleutelhouders eerlijk moet blijven en moet weigeren een oneerlijke verdeling van fondsen te ondertekenen, zodat het systeem veilig kan zijn.
Datzelfde beveiligingsmodel kan worden toegepast op waar het geld naartoe gaat (minus de exploitant(en)) in het geval van een totale mislukking van de exploitant. Dat brengt echter het risico met zich mee dat een enkele sleutel verloren gaat of niet meewerkt aan het verbranden van geld, dus je kunt er ook gewoon een conventionele m-of-n-multisig van maken.
Ik zie helemaal geen probleem in dit soort opzet; het bereikt het doel om ervoor te zorgen dat het geld van gebruikers niet onherroepelijk wordt verbrand zonder een wilde verandering in het vertrouwensmodel te creëren. Als u geen directe deelnemer bent aan het BitVM-contract, dat wil zeggen dat u zelf een van die n-van-n sleutels bezit, vertrouwt u uiteindelijk nog steeds een of andere federatie. Slechts één lid hoeven te vertrouwen om eerlijk te zijn om de zaken veilig te houden, is uiteraard superieur aan het moeten vertrouwen van drie mensen in een 5-van-7-multisig, maar het is nog steeds een vorm van gedelegeerd vertrouwen.
Afsluiten
Uiteindelijk denk ik dat het door Taproot Wizards geïdentificeerde probleem van de liquiditeitscrisis een zeer legitieme kwestie is. Afhankelijk van de specifieke architectuur van de koppeling in kwestie kan dit problemen opleveren, van het volledig verbranden van het geld van gebruikers, tot het verliezen van geld van operators, zelfs zonder kwaadwillige actie, tot het eenvoudigweg creëren van een steeds groeiende wachtrij om uit te stappen zonder de stortingen stop te zetten of terug te vallen op de n-van-n groep om de wachtrij te omzeilen.
Het is echter naar mijn mening niet iets dat betekent dat het idee om BitVM te gebruiken om een tweerichtingskoppeling te beveiligen een fundamenteel gebroken idee is. Ik denk dat ik een groot aantal manieren heb uiteengezet waarop specifieke implementaties het probleem kunnen tegenhouden of verzachten, en uiteindelijk de realiteit van de bestaande n-of-n-groep en het potentieel om fondsen in geval van mislukking naar een gedelegeerde groep te sturen om het omgaan met opnames kan het risico van permanent verlies van geld aanpakken.
Als laatste opmerking: het tempo van de ontwikkeling op dit gebied heeft het afgelopen jaar een tempo bereikt dat ik in mijn tijd hier nog nooit heb gezien. Ik denk dat het belangrijk is om bij het bespreken van deze ontwikkelingen een stap terug te doen en kalm te blijven terwijl kijkend naar de discussies die plaatsvinden over afwegingen en risico’s. Ja, de publieke perceptie is een aspect van deze gesprekken die in het openbaar plaatsvinden, maar deze discussies moeten geworteld zijn in het doel om tot een accuraat begrip van de kwesties te komen. Dat mag niet op de achtergrond komen door eerst een bepaalde publieke perceptie illegaal te maken of te verdedigen.