Darrerament, els rollups s’han convertit en el focus narratiu de l’escalada de Bitcoin, convertint-se en el primer que realment “robar el protagonisme” de la xarxa Lightning en termes d’una ment més àmplia. Els rollups pretenen ser una capa dos fora de la cadena que no estigui lligada ni limitada per les limitacions de liquiditat que són fonamentals per a la xarxa Lightning, és a dir, els usuaris finals requereixen que algú els assigni (o “presti”) fons per endavant per poder per rebre diners, o nodes d’encaminament intermediaris que requereixen saldos de canal que poden facilitar el moviment de l’import del pagament des del remitent al receptor.
Aquests sistemes es van desenvolupar originalment per funcionar a Ethereum i altres sistemes complets de Turing, però darrerament l’atenció s’ha canviat a portar-los a cadenes de blocs basades en UTXO com Bitcoin. Aquest article no parlarà de l’estat actual de les coses que s’està implementant a Bitcoin actualment, sinó que parlarà de la funció d’un conjunt idealitzat que la gent pretén a llarg termini en funció de les característiques que Bitcoin actualment no admet, és a dir, la capacitat de verificar les proves de coneixement zero (ZKP) a Bitcoin directament.
L’arquitectura bàsica d’un rotllo és la següent: un sol compte (o en el cas de Bitcoin UTXO), conté els saldos de tots els usuaris del rollup. Aquest UTXO conté un compromís en forma d’arrel de merkle d’un arbre de merkle que es compromet amb tots els saldos actuals dels comptes existents a la acumulació. Tots aquests comptes estan autoritzats mitjançant parells de claus públiques/privades, de manera que per proposar una despesa fora de la cadena, un usuari ha de signar alguna cosa amb una clau. Aquesta part de l’estructura permet als usuaris sortir sense permís quan vulguin, simplement amb la creació d’una transacció que demostri que el seu compte forma part de l’arbre de merkle, poden sortir unilateralment del conjunt sense el permís de l’operador.
L’operador del rollup ha d’incloure un ZKP en les transaccions que actualitzen l’arrel merkle dels saldos del compte a la cadena en el procés de finalització de transaccions fora de la cadena, sense aquest ZKP la transacció no serà vàlida i, per tant, no s’inclourà a la cadena de blocs. Aquesta prova permet a la gent verificar que tots els canvis als comptes fora de la cadena van ser autoritzats correctament pel titular del compte i que l’operador no ha dut a terme una actualització maliciosa dels saldos per robar diners als usuaris o reassignar-los a altres usuaris de manera deshonesta.
El problema és que si només l’arrel de l’arbre merkle es publica a la cadena on els usuaris hi poden veure i accedir, com aconsegueixen la seva branca a l’arbre per poder sortir sense permís quan volen?
Rollups adequats
En un conjunt correcte, la informació es posa directament a la cadena de blocs cada vegada que es confirmen noves transaccions fora de la cadena i l’estat dels comptes acumulats canvia. No tot l’arbre, això seria absurd, sinó la informació necessària per reconstruir l’arbre. En una implementació ingènua, el resum de tots els comptes existents a l’acumulació tindria saldos i comptes simplement afegits a la transacció d’actualització de l’acumulació.
En implementacions més avançades, s’utilitza una diferència d’equilibri. Es tracta bàsicament d’un resum dels comptes que s’han afegit o restat diners durant el transcurs d’una actualització. Això permet que cada actualització acumulativa només inclogui el canvis per comptabilitzar els saldos que es produeixin. Aleshores, els usuaris només poden escanejar la cadena i “fer les matemàtiques” des del principi de l’acumulació per arribar a l’estat actual dels saldos del compte, que els permet reconstruir l’arbre merkle dels saldos actuals.
Això estalvia molta sobrecàrrega i espai de blocs (i, per tant, diners) alhora que permet als usuaris garantir l’accés a la informació necessària perquè puguin sortir unilateralment. La inclusió d’aquestes dades en un conjunt formal que utilitza la cadena de blocs per posar-la a disposició dels usuaris està obligada per les regles del conjunt, és a dir, una transacció que no inclogui el resum del compte o la diferència del compte es considera una transacció no vàlida.
Validiums
L’altra manera de gestionar el problema de la disponibilitat de dades perquè els usuaris puguin retirar-les és posar les dades en un altre lloc a part de la cadena de blocs. Això introdueix problemes subtils, el conjunt encara ha de fer complir que les dades estiguin disponibles en un altre lloc. Tradicionalment, s’utilitzen altres blockchains per a aquest propòsit, dissenyats específicament per funcionar com a capes de disponibilitat de dades per a sistemes com ara rollups.
Això crea el dilema que les garanties de seguretat siguin tan fortes. Quan les dades es publiquen directament a la cadena de blocs de Bitcoin, les regles de consens poden garantir que siguin correctes amb absoluta seguretat. Tanmateix, quan es publica a un sistema extern, el millor que pot fer és verificar una prova SPV que les dades s’han publicat a un altre sistema.
Això implica verificar una certificació que les dades existeixen en altres cadenes, que en última instància és un problema d’oracle. La cadena de blocs de Bitcoin no pot verificar res completament, excepte el que passa a la seva pròpia cadena de blocs, el millor el que pot fer és verificar un ZKP. Tanmateix, un ZKP no pot verificar que un bloc que conté dades acumulades s’hagi emès públicament després de ser produït. No pot verificar que la informació externa estigui realment disponible públicament per a tothom.
Això obre la porta als atacs de retenció de dades, on es crea un compromís amb les dades que es publiquen i s’utilitzen per avançar en l’acumulació, però les dades no estan disponibles. Això fa que els usuaris tinguin fons més enllà de la seva capacitat de retirar-se. L’única solució real a això és dependre completament del valor i l’estructura d’incentius dels sistemes completament externs a Bitcoin.
The Rock and Hard Place
Això crea un dilema en termes de acumulacions. Quan es tracta del problema de disponibilitat de dades, hi ha essencialment una opció binària entre publicar les dades a la cadena de blocs de Bitcoin o en un altre lloc. Aquesta elecció té implicacions massives tant per a la seguretat com per a la sobirania del rollup, així com per a la seva escalabilitat.
D’una banda, l’ús de la cadena de blocs de Bitcoin per a la capa de disponibilitat de dades introdueix un sostre dur sobre la quantitat de acumulacions que poden escalar. Només hi ha tant d’espai de bloqueig, i això posa un límit superior a quants acumulacions poden existir alhora i quantes transaccions poden processar totes les acumulacions en conjunt. fora de cadena. Cada actualització acumulada requereix un espai de bloc proporcional a la quantitat de comptes que han tingut canvis de saldo des de l’última actualització. La teoria de la informació només permet comprimir tant les dades i, en aquest moment, no hi ha més possibilitats d’escalar els guanys.
D’altra banda, l’ús d’una capa diferent per a la disponibilitat de dades elimina el sostre dur dels guanys d’escalabilitat, però també introdueix nous problemes de seguretat i sobirania. En una acumulació que utilitza Bitcoin per a la disponibilitat de dades, literalment no és possible que l’estat de l’acumulació canviï sense que les dades necessàries pels usuaris per retirar es publiquin atòmicament a la cadena de blocs. Amb Validiums, aquesta garantia depèn completament de la capacitat de qualsevol sistema extern que s’utilitzi per resistir els jocs i la retenció de dades.
Qualsevol productor de blocs del sistema de disponibilitat de dades extern ara és capaç de mantenir els fons dels usuaris acumulats de Bitcoin com a ostatges mitjançant la producció d’un bloc i no emetre-lo realment perquè les dades estiguin disponibles.
Llavors, quin serà, si mai arribem a una implementació acumulada ideal a Bitcoin que permeti la retirada unilateral dels usuaris? La roca o el lloc dur?
