Artículo del Blog

Finalidad Impuesta por el Emisor Explicada

Autor

Jason Chlipala

Fecha de publicación

Finalidad impuesta por el emisor

Una mirada a una de las características más poderosas y a menudo menos entendidas de Stellar

La misión de Stellar Development Foundation es crear un acceso equitativo al sistema financiero global, y creemos que las nuevas representaciones digitales del dinero son parte de alcanzar ese objetivo. Esto requerirá el trabajo de muchas personas y proyectos diferentes, todos avanzando juntos. Por eso seguimos el trabajo de proyectos como Libra, y nos interesó verlos anunciar los próximos pasos para su trabajo. Basados en conversaciones con reguladores, ahora planean ofrecer stablecoins de una sola moneda y modelos de cumplimiento y seguridad mejorados. También están renunciando a su plan anterior de transicionar a una red sin permisos.

Esta cuestión de “con permiso vs sin permiso” resalta una característica clave de la red Stellar. Desde el principio, Stellar fue diseñada para permitir a las entidades (de manera segura) emitir representaciones digitales de monedas con la certeza de una red con permiso, pero la interoperabilidad de una red sin permiso. Esto es posible gracias a una de las características más poderosas, pero menos entendidas, de Stellar: Finalidad Impuesta por el Emisor.

Pero, ¿qué significa realmente “Finalidad Impuesta por el Emisor”? Y, ¿por qué te da la certeza de una “red con permiso”? Esto se responde mejor comparando dos ejemplos.

Ejemplo 1: Emitiendo un stablecoin en Ethereum‍

Primero consideremos una entidad que emite un stablecoin de dólar en Ethereum (llamémoslo “e-USD”). Debido a que Ethereum utiliza prueba de trabajo para lograr consenso, durante su operación normal emergen ramas diferentes (y potencialmente conflictivas) a medida que los mineros verifican diferentes bloques. Estas suelen ser de corta duración, porque tan pronto como una rama se alarga más que la otra por la adición de nuevos bloques, la mayoría de los nodos en la red cambian a trabajar en esa rama (que es lo que se supone que deben hacer).

Un “ataque de doble gasto” ocurre cuando alguien mantiene una de estas ramas viva a propósito y en secreto, para gastar los mismos tokens dos veces. Una explicación detallada de los ataques de doble gasto se puede encontrar aquí, pero aquí hay una versión rápida: Supongamos que un estafador gasta algunos tokens (transfiriéndolos fuera de su cuenta), y luego crea una rama secreta de la cadena en la que esos tokens todavía están en su cuenta. Si tienen el 51% del poder total de hash de la red, pueden añadir nuevos bloques en la rama secreta lo suficientemente rápido para mantener el ritmo con el resto de la red, y eventualmente llegar a una cadena más larga que la rama pública. En ese punto, el estafador transmite su rama, y la red cambia a esa cadena porque es más larga que la rama pública. El estafador entonces sería capaz de gastar los tokens por segunda vez.

La posibilidad de ataques de doble gasto crea un dilema para los emisores de stablecoin. Siempre que una cuenta quiera canjear e-USD por USD fíat, tienen que preguntarse si podría haber un ataque de doble gasto en progreso. Después de enviar USD fíat al propietario de la cuenta que redime, una nueva cadena podría ser revelada que no incluye la transacción de redención, y en la cual la cuenta que acaba de redimir ya no tiene ningún e-USD.

Una situación donde un solo actor malicioso podría socavar el sistema es comprensiblemente preocupante para los reguladores. Incluso si ahora mismo no podría tener sentido para una entidad tratar de amasar el poder computacional necesario (porque los costos de hacerlo superarían el beneficio potencial), eso podría no ser siempre el caso.

El Protocolo de Consenso de Stellar‍

Para ver cómo la emisión de un stablecoin en Stellar se compara, primero necesitamos una visión general rápida del Protocolo de Consenso de Stellar (o “SCP”). Entender las complejidades de SCP está fuera del alcance de este post, pero aquí está cómo funciona a un alto nivel:

Cada validador (ver nota al pie 1) en Stellar especifica algo llamado su conjunto de quórum, que es el conjunto de n otros validadores que elige confiar, y un umbral k (donde k ≤ n), que es el número de esos otros validadores que requiere para cada voto. Cuando ese validador está decidiendo si añadir un nuevo bloque a la historia del libro mayor, en lugar de confirmar que un minero ha resuelto un problema computacional (como en prueba de trabajo), el validador verifica si al menos k de los nodos en su conjunto de quórum están de acuerdo con añadirlo. El hecho de que cada validador pueda elegir a quién confiar es uno de los aspectos más únicos de Stellar.

Mientras los conjuntos de quórum para dos validadores se intersecten “suficiente”, siempre llegarán a un acuerdo entre ellos. Si los conjuntos de quórum para todos los validadores se superponen “suficiente” entonces toda la red alcanzará consenso.

Con estos conjuntos de quórum y umbrales, los nodos A y B siempre estarán de acuerdo.

Por simplicidad, hemos omitido dos piezas importantes para entender SCP. Primero, para implementar este esquema en una red real, el proceso de votación necesita involucrar múltiples rondas de votación para lidiar con la latencia de la red, el hecho de que nuevas transacciones están llegando constantemente, y otros casos límite. Segundo, hablamos arriba sobre conjuntos de quórum intersectándose “suficiente” para que la red alcance consenso. Definir precisamente qué significa “suficiente” se vuelve extremadamente técnico. Si estás interesado en profundizar más en esto, te animamos a leer nuestro post en el blog sobre Por Qué los Quórums Importan.

Aunque estamos simplificando ciertos detalles de SCP, la visión general anterior es suficiente para ver la característica clave de Stellar para entender la Finalidad Impuesta por el Emisor: no hay ramificación en SCP. Un validador en Ethereum se ve afectado por cualquier minero en la red, sin importar quiénes sean. Si el libro mayor de un validador actualmente contiene una historia dada del libro mayor, pero llega una nueva (con la prueba apropiada por un minero) con una cadena más larga, entonces el validador se supone que debe cambiar inmediatamente a esa nueva historia. En Stellar, los validadores no tienen que actualizar su libro mayor basándose en mineros, solo tienen que escuchar a los nodos en su conjunto de quórum (que ellos mismos eligen en primer lugar). A medida que añaden nuevos bloques a su historia del libro mayor, nunca volverán atrás y los cambiarán. Esto hace que los ataques de doble gasto (como se describió arriba) sean imposibles, y abre la puerta a la Finalidad Impuesta por el Emisor.

Ejemplo 2: Emitiendo un stablecoin en Stellar‍

Ahora estamos listos para considerar la emisión de un stablecoin de dólar en Stellar (llamémoslo “s-USD”, y al emisor “Emisor”). Debido a cómo funciona SCP, obviamente no tenemos que preocuparnos por una rama secreta como en el Ejemplo 1. Pero podrías preguntar: ¿Podrían los nodos en el conjunto de quórum del Emisor coludirse contra ellos de alguna otra manera? Podrían intentarlo, pero veamos por qué el Emisor sigue estando seguro.

Primero, esta es una posibilidad mucho menos preocupante que el Ejemplo 1. En lugar de un solo minero anónimo siendo capaz de socavar la integridad de los activos del Emisor, esto requeriría coordinación entre múltiples actores, todos conocidos por el Emisor. Presumiblemente elegirán nodos para su conjunto de quórum gestionados por entidades en las que confían. Y si esas otras entidades se comportan mal, el Emisor sabría a quién perseguir en los tribunales.

Segundo, un conjunto de quórum coludido todavía no amenazaría al Emisor como en el Ejemplo 1. Supongamos que han emitido 100 s-USD a Alice, y los nodos del conjunto de quórum deciden que van a ayudar a Alice permitiéndole gastar esos 100 s-USD para comprar un coche de Bob, y luego también canjear esos mismos 100 s-USD por USD fíat con el Emisor. Llevar a cabo este esquema en Stellar involucraría cuatro pasos:

  1. Alice transfiere 100 s-USD a Bob, a cambio de un coche.
  2. El conjunto de quórum del Emisor omite intencionalmente esa transacción de un nuevo bloque, que el Emisor acepta porque los nodos en su conjunto de quórum lo han aceptado.
  3. Alice luego transfiere 100 s-USD (que todavía parece que tiene) al Emisor para el canje.
  4. El Emisor da a Alice $100.

A primera vista, parece que el Emisor está en problemas porque Bob va a estar muy enojado cuando se dé cuenta de que el Emisor no cree que tiene 100 s-USD y por lo tanto no puede canjear. Pero hay una solución simple: el Emisor deja claro al mundo que nadie debe creer que tiene s-USD a menos que el validador del Emisor diga que sí los tiene. Mientras el Emisor lo deje claro, Bob no le dará el coche a Alice hasta que vea 100 s-USD en su cuenta en el validador del Emisor.

Si el conjunto de quórum lleva a cabo el esquema anterior, cuando Bob intente verificar que ha recibido los 100 s-USD, no lo verá en el validador del Emisor (debido al paso 2 anterior). Así como alguien esperaría la confirmación de una transferencia bancaria exitosa o una transacción de tarjeta de crédito antes de entregar las llaves de un coche, Bob no le daría el coche a Alice hasta que pudiera confirmar los 100 s-USD en su cuenta (que, por cierto, debería ser casi inmediato porque Stellar cierra un nuevo libro mayor aproximadamente cada 5 segundos).

Incluso si hay validadores en la red que muestran que Alice le ha dado a Bob 100 s-USD, él no debería entregar las llaves del coche hasta que lo vea en el validador del Emisor


Finalidad Impuesta por el Emisor, y Por Qué Importa

Eso es lo que es la Finalidad Impuesta por el Emisor. Es el hecho de que al final del día, el Emisor tiene la autoridad para hacer cumplir la fuente de verdad gobernante sobre quién posee o no su activo. Nunca hay ambigüedad sobre quién posee ese activo, porque todos saben qué copia del libro mayor consultará el Emisor cuando llegue el momento de redimir.

Los emisores de stablecoin en Stellar deberían establecer (y dejar muy claro a los tenedores) dos cosas: (1) cómo funciona el activo fuera de Stellar, que incluye cómo está respaldado (por ejemplo, respaldado 1:1 por reservas bancarias de USD) y los procedimientos para la emisión y redención (por ejemplo, proceso KYC y detalles de pago), y (2) el validador en Stellar que sirve como el registro autoritativo de propiedad. De esta manera, aunque Stellar es una red sin permisos, cualquiera que reciba la stablecoin tiene completa confianza de que su propiedad será respetada por el emisor, y que podrán redimirla (ver nota al pie 2).

La Finalidad Impuesta por el Emisor es solo una de las características que hace a Stellar una gran opción para los emisores de stablecoin (y otros activos). Para más información, visita www.stellar.org/learn/the-power-of-stellar o envía un correo a [email protected].

1. Dado que Stellar no tiene minería, nos referimos a “validadores” en lugar de mineros. Los validadores son simplemente nodos que participan en el protocolo de consenso. Más información sobre los diferentes tipos de nodos de Stellar se puede encontrar aquí.

2. Si el emisor está operando su propio validador, presumiblemente elegirá su propio nodo como el registro autoritativo. Pero no tiene que ser así. Una entidad no tiene que operar un validador para emitir un activo, y podría especificar el nodo de alguien más como el nodo autoritativo.