Algunos de ustedes recordarán un artículo que publiqué hace años, Comprender la red Lightning usando un ábaco, que escribí después de que me quedó claro que muchas personas no entendían completamente cómo funciona Lightning. En ese momento, mi objetivo no era explicar la criptografía de Lightning o los detalles de implementación, sino desmitificar la idea central detrás de los canales de pago. Utilicé la analogía del ábaco para centrarme en el concepto más que en la mecánica. Funcionó extremadamente bien y más tarde la gente adoptó la analogía del ábaco para explicar Lightning a los novatos.
Últimamente he tenido una fuerte sensación de déjà vu.
Cuando hablo de Spark, noto un patrón similar. Algunos saben decir “cadena de estados”, pero para la mayoría, ahí es donde termina la comprensión. Y al igual que con Lightning en aquel entonces, el problema no es la falta de inteligencia o esfuerzo, es simplemente que el modelo mental subyacente no está claro. Así que intentaré el mismo enfoque nuevamente: explicar cómo funciona Spark conceptualmente, sin entrar en terminología criptográfica.
Básicamente, Spark permite a los usuarios enviar y recibir bitcoins sin transmitir transacciones en cadena. El bitcoin no se mueve en la cadena cuando cambia de propietario. En cambio, lo que cambia es quién puede autorizar conjuntamente su gasto. Esta autorización conjunta se comparte entre el usuario y un grupo de operadores llamado Spark Entity (SE).
Para explicar cómo funciona esto, imagine que gastar un conjunto determinado de bitcoins en Spark requiere completar un simple rompecabezas de dos piezas:
- Una pieza del rompecabezas la tiene el usuario.
- La otra pieza la tiene la SE.
Sólo cuando ambas piezas coincidentes se juntan se puede gastar el bitcoin. Un conjunto diferente de bitcoins requerirá completar un rompecabezas diferente.
Ahora veamos lo que sucede cuando cambia de propietario.
Inicialmente, Alice sostiene una pieza del rompecabezas que coincide con la pieza que sostiene el SE. Puede gastar sus bitcoins combinando las piezas y completando el rompecabezas. Cuando Alice quiere enviarle sus bitcoins a Bob, le permite a Bob crear un nuevo rompecabezas junto con el SE. Es importante destacar que el rompecabezas en sí no cambia: el viejo y el nuevo tienen la misma forma, pero las piezas que lo componen cambian. El nuevo rompecabezas está diseñado para Bob: un lado está asociado con Bob y el otro con el SE. A partir de ese momento, sólo la pieza de Bob coincide con la pieza del SE. Es posible que Alice aún conserve su antigua pieza del rompecabezas, pero ahora es inútil. Dado que el SE destruyó su pieza correspondiente, la pieza de Alice ya no encaja en ninguna otra pieza y no puede usarse para gastar el bitcoin. La propiedad efectivamente pasó a Bob, a pesar de que el bitcoin en cuestión nunca se movió en la cadena.
Posteriormente, Bob puede repetir el mismo proceso para enviar el mismo conjunto de bitcoins a Carol y así sucesivamente. Cada transferencia funciona reemplazando las piezas del rompecabezas, no moviendo los fondos en la cadena.
En este punto, surge naturalmente una pregunta: ¿qué pasa si el SE simplemente no descarta su vieja pieza del rompecabezas? En ese caso, la SE podría confabularse con la propietaria anterior, Alice, y gastar los bitcoins de Bob. Necesitamos confiar en la SE que, cuando la propiedad pasó de Alice a Bob, también destruyó su pieza del rompecabezas. Sin embargo, es importante entender que una SE no es un partido único. Consiste en un grupo de operadores, y el lado del rompecabezas del SE nunca está a cargo de un solo operador. Reemplazar el rompecabezas requiere la cooperación entre múltiples operadores. Ninguna de las partes puede mantener activo en secreto un viejo rompecabezas o recrearlo más tarde. Es suficiente que un operador actúe honestamente durante una transferencia para evitar que un viejo rompecabezas vuelva a reactivarse.
La idea clave es simple: Spark no mueve bitcoins en cadena entre usuarios. Reemplaza a quien posee la autorización válida para gastarlos. El bitcoin en cadena no se mueve. Lo que cambia es qué dos piezas del rompecabezas encajan.
Para mantener esta explicación enfocada, intencionalmente no entré en el mecanismo de salida unilateral de Spark. Es una parte importante del modelo de seguridad de Spark, pero distraería la atención de la idea central que quiero transmitir aquí. Lo que importa es que Spark no es un sistema en el que los usuarios dependan permanentemente del SE. Si bien las transferencias diarias dependen de una autorización conjunta, Spark también brinda a los usuarios una forma de gastar sus fondos en la cadena sin requerir la cooperación de la SE. Esa trampilla de escape existe por diseño, está fuera del alcance de esta explicación.
Esta publicación Spark explicada como si tuvieras cinco apareció por primera vez en la revista Bitcoin y está escrita por Roy Sheinfeld.