Traducción al español de Jormungandr User Guide
Publicado en el Portal de Soporte de IOHK por Carl.
Bienvenido a la Guía de usuario de Jormungandr.
Jormungandr es una implementación del nodo de Cardano, escrita en Rust, con el objetivo inicial de dar soporte al protocolo de consenso Ouroboros.
Un nodo es un participante de una red de cadena de bloques, que continuamente elabora, envía, recibe y valida bloques. Cada nodo es responsable de asegurarse de que se cumplan todas las reglas del protocolo.
Mitología
Jormungandr se refiere a la serpiente Midgard de la mitología nórdica. Es una referencia a Ouroboros, la antigua serpiente egipcia, que se come su propia cola, así como el paper de IOHK sobre la prueba de participación.
1. Conceptos generales
Este artículo cubre los conceptos generales de la cadena de bloques, y su aplicación con el nodo, seguido por la organización del nodo y la interacción del usuario con él.
1.1. Conceptos de cadenas de bloques
Tiempo
Los intervalos (slots) representan la unidad básica de tiempo en la cadena de bloques, y en cada intervalo puede haber un bloque.
Los intervalos consecutivos se agrupan en ciclos (epochs), que tienen un tamaño ajustable definido por el protocolo.
Fragmentos
Los fragmentos forman parte de los datos de la cadena de bloques que representan todos los posibles eventos relacionados con la salud de la cadena de bloques (por ejemplo, la actualización del protocolo), pero también y principalmente el registro general de información como transacciones y certificados.
Bloques
Los bloques representan la espina dorsal de la cadena de bloques, enlazando de forma segura los bloques en la cadena, a la vez que agrupan los fragmentos válidos.
Los bloques se componen de 2 partes:
- Cabecera.
- Contenido.
La cabecera enlaza el contenido con los bloques de forma segura, mientras que el contenido es en realidad una secuencia de fragmentos.
Cadena de bloques
La cadena de bloques se compone de un conjunto general de reglas y de bloques que se crean periódicamente. Algunas de las reglas y configuraciones, pueden ser cambiadas dinámicamente en el sistema mediante actualizaciones, mientras que otras están definidas en el bloque génesis (primer bloque de la cadena).
Consenso
El nodo actualmente soporta el siguiente protocolo de consenso:
- Ouroboros BFT (OBFT).
- Ouroboros Genesis-Praos.
Ouroboros BFT es un sencillo protocolo Byzantine Fault Tolerant (BFT) donde los creadores de bloques se componen de una lista conocida de líderes que sucesivamente crean un bloque y lo transmiten a la red.
Ouroboros Genesis-Praos es un protocolo de prueba de participación (PoS) donde el creador de bloques (stake pool) se elige a partir de un sorteo, donde cada parte tiene una oportunidad proporcional a su stake (cantidad de ADA delegadas en él) de ser elegido para crear un bloque. Cada sorteo es privado para cada stake pool, de modo que la red global no sabe de antemano quién puede o no puede crear bloques.
En Genesis-Praos la duración del intervalo (slot) es constante, sin embargo la frecuencia de creación de bloques no es fija, ya que la creación de bloques es una probabilidad que está ligada al staking y al coeficiente del intervalo activo del consenso de Genesis-Praos.
Nota: En Genesis-Praos, si no hay participación en el sistema, no se crearán más bloques a partir del siguiente ciclo (epoch).
Liderazgo
El liderazgo representa, en términos abstractos, a los líderes globales del sistema, y permite que cada nodo individual verifique qué bloques específicos se crean legalmente en el sistema.
El liderazgo es replanteado en cada nuevo ciclo (epoch), y permanece constante durante la duración de un ciclo.
Líder
En el modo OBFT, el líder sólo es el propietario de una llave criptográfica, mientras que en el modo Genesis-Praos, el líder es un stake pool.
Transacción
La transacción es la piedra angular de la cadena de bloques, y es un tipo de fragmento, el más frecuente.
La transacción se compone de entradas y salidas; por un lado, las entradas representan las monedas que se están gastando, y por otro lado, las salidas representan las monedas que se están recibiendo.
Las transacciones tienen tarifas que se definen por la configuración de la cadena de bloques, y la siguiente relación estática:
∑Ingresos = ∑Egresos + Comisiones
La transacción debe ser autorizada por cada uno de los ingresos en la transacción por su respectivo validador. En el caso más básico, un validador es una firma criptográfica, pero dependiendo del tipo de entrada puede variar el tipo de validador.
Contabilidad
La cadena de bloques tiene dos métodos de contabilidad que son interoperables:
- Salida de transacción no gastada (UTxO).
- Cuentas.
UTxO se comporta como el efectivo, y funciona como un billete de denominación fija que se acumula. Este es el modelo de contabilidad que se encuentra en Bitcoin. Un UTxO es identificada únicamente por su ID de transacción y su índice.
Las cuentas se comportan como una cuenta bancaria, y son más fáciles de usar ya que se puede utilizar el importe exacto. Este es el modelo de contabilidad que se encuentra en Ethereum. Una cuenta se identifica de manera única por su clave pública.
Cada entrada puede referirse arbitrariamente a una cuenta o a un UTxO, y de forma similar cada salida puede referirse a una cuenta o representar un nuevo UTxO.
1.2. Participación
En una prueba de participación, los participantes obtienen una participación equivalente a los fondos que poseen (stake). El stake se utiliza entonces para permitir la participación en el protocolo, simplemente explicado como:
Cuanto más stake tenga uno, más probabilidades habrá de participar en mantener la red saludable.
Cuando se utiliza el consenso OBFT, el stake no influye en la forma en que funciona el sistema, pero todavía puede ser adaptado para una transición posterior de la cadena a otro modo de consenso.
Participación en el modelo de cuentas
Las cuentas están representadas por un tipo de dirección, y están compuestas únicamente de una llave pública. La cuenta acumula fondos y su poder de participación está directamente representado por la cantidad que contiene.
Por ejemplo:
Cuenta A posee $30 => Cuenta A tiene una participación de 30.
Cuenta B posee $0 => Cuenta B no tiene participación.
Una cuenta podría tener una participación mayor de la que realmente contiene, ya que también podría tener UTxOs asociados. Este caso se trata en la siguiente sección.
Stake en el modelo UTxO
Los UTxO están representados por dos tipos de direcciones:
- Dirección única: Estas direcciones no tienen ningún interés asociado.
- Dirección grupal: Estas direcciones tienen una cuenta asociada que recibe el poder de participación relativo al valor del UTxO.
Por ejemplo, con los siguientes UTxOs:
UTXO 1: $60 (dirección única) => tiene un stake de 0.
UTXO 2: $50 (dirección grupal A)
→ Cuenta A con $10 => Posee un stake de 100.
UTXO 3: $40 (dirección grupal A) /UTXO 4: $20 (dirección grupal B) → Cuenta B con $5 => Posee un stake de 25.
Grupos de participación (stake pools)
Los stake pools son los creadores confiables de bloques en el sistema Genesis-Praos. Un pool es registrado en la red explícitamente por sus propietarios, y contiene metadatos y material criptográfico.
Los stake pools no tienen poder de stake por sí mismos, pero los participantes en la red delegan su participación en un pool para llevar a cabo la operatoria en la cadena.
Delegación de la participación (stake)
El stake puede (y para la salud de la red necesita) ser delegada a los stake pools del sistema. La delegación puede modificarse con el tiempo mediante el registro de un nuevo certificado de delegación.
Los certificados de delegación son una simple declaración en forma de:
Cuenta “A” delega en el stake pool “Z”.
Efectivamente, se asigna la participación de la cuenta A, y el stake del UTxO, al pool Z, en el que se delega hasta que se registre otro certificado de delegación.
1.3. Organización del nodo
Enclave seguro
El enclave seguro es el componente que contiene el material criptográfico secreto, el cual ofrece interfaces seguras y secretas de alto nivel al resto del nodo.
Red
La red del nodo posee 3 componentes:
- API de intercomunicación (gRPC).
- API del cliente público (REST).
- Controlador de la API del cliente (REST).
Léase también el punto 1.4. Sinopsis de la red.
API de intercomunicación (gRPC)
Esta interfaz es una interfaz binaria y eficiente que utiliza el formato protobuf y el estándar GRPC. Los archivos protobuf de tipos e interfaces están disponibles en el código fuente.
La interfaz es responsable de comunicarse con otros nodos de la red:
- Envío y recepción de bloques.
- Emisión de fragmentos (transacciones, certificados).
- Comunicación peer-to-peer.
API REST Pública
Esta interfaz es para consultas simples para clientes como:
- Billeteras y software de terceros.
- Herramientas de análisis y depuración.
- Explorador.
Se recomienda que esta interfaz no esté abierta al público.
API REST de control
Esta interfase no está terminada, pero es una interfase restringida con ACL, para poder realizar tareas de mantenimiento en el proceso de:
- Apagado.
- Cargar/Retirar material criptográfico.
1.4. Descripción general de la red
Las capacidades de la red están divididas en:
- La API REST, utilizada para consultas informativas y para el control del nodo.
- La API gRPC para el intercambio y la participación en protocolos de cadenas de bloques.
Aquí sólo revisaremos la API gRPC ya que la API REST se describe en otro capítulo 2.3. API REST.
El protocolo
El protocolo está basado en gRPC, que combina protocolos de uso común como HTTP/2 y RPC. Más precisamente, lo utiliza Jormungandr.
Esta elección se hizo porque gRPC ya está ampliamente soportado en todo el mundo, debido a su utilización de protocolos estándar HTTP/2, lo que hace que sea mucho más fácil para los proxys y firewalls reconocer el protocolo y permitir el tráfico.
Tipos de consultas
El protocolo permite enviar múltiples tipos de mensajes entre nodos:
- Sincronizar el bloque con el último bloque del par remoto (tip).
- Proponer nuevos fragmentos (nuevas transacciones, certificados,…), para la propagación de fragmentos.
- Proponer nuevos bloques, para la propagación de bloques.
Existen otros comandos que optimizan la comunicación y la sincronización entre nodos, que se documentarán aquí en el futuro.
Otro tipo de mensajes es el mensaje Gossip. Estos mensajes de comunicación permiten a los Nodos intercambiar información sobre otros nodos de la red, lo que permite la detección de pares.
Peer-to-peer
Las conexiones perr-to-peer se establecen utilizando múltiples componentes:
- Una topología multicapa (por ejemplo, Poldercast).
- Cotilleo entre pares para descubrir nodos.
- Mecanismo de suscripción para la propagación de eventos.
- Seguridad y contramedidas (como la Política de Topología para los nodos de scoring y/o black-listing).
Topología multicapa
Como se describe en el documento Poldercast, nuestra topología de red está construida sobre múltiples capas que permiten un control granular de su comportamiento. En la práctica, esto significa que un nodo tendrá diferentes grupos de nodos a los que se conecta, basándose en diferentes algoritmos, cada uno de estos grupos son un subconjunto de toda la lista conocida de nodos.
En resumen, lo que hemos hecho:
- La capa de anillos selecciona un predecesor(es) y un sucesor(es) para cada tema (Fragmentos o Bloques).
- La capa de vecindad seleccionará nodos que tengan intereses similares.
- La capa Cyclon, seleccionará los nodos al azar.
Sin embargo, mantenemos abierta la opción de eliminar algunas de estas capas o añadir otras nuevas, como por ejemplo:
- Una capa para permitir conexiones de privilegio entre stake pools.
- Una capa para la white-list del usuario, una lista de nodos que los usuarios consideran fiables y que podemos utilizar para comprobar el estado actual de la red, y verificar que el nodo del usuario no está dentro de una bifurcación (fork) de larga duración.
Cotilleos
El chismorreo (gossiping) es el proceso utilizado para descubrir a los compañeros. Permite dos cosas:
- Que cualquier nodo se anuncie como localizable.
- Descubrir nuevos nodos intercambiando una lista de nodos (chismes).
Los chismes son seleccionados por las diferentes capas de la topología multicapa. Para los módulos Poldercast, los chismes se seleccionan como se indica en el paper. Los módulos adicionales pueden seleccionar nuevos nodos en la lista de chismes, o pueden decidir no agregar nueva información.
Mecanismo de suscripción
Basado en la topología multicapa, el nodo abrirá conexiones multiplexadas y bidireccionales (gracias al estándar gRPC, esto es gratuito). Estas conexiones bidireccionales se utilizan para propagar eventos como:
- Eventos de chismes: Cuando 2 nodos intercambian chismes para descubrimiento de pares.
- Eventos de fragmentos: Cuando un nodo quiere propagar un nuevo fragmento a otros nodos.
- Eventos de bloque: Cuando un nodo desea propagar un nuevo evento de creación de bloque.
Seguridad y contramedidas
Para facilitar el manejo de nodos no accesibles o que tienen un mal comportamiento, hemos construido herramientas de políticas de nodos. Esto se construye a través de dos mecanismos:
- La recopilación de los estados de conectividad.
- El estado de la cadena de bloques para cada nodo.
La política se puede ajustar utilizando los datos recopilados, para aplicar algunos parámetros al conectarse a un nodo determinado, así como para prohibir los nodos de nuestra topología.
Para cada nodo, se recopilan los siguientes datos:
Estado de las conexiones:
- Los intentos fallidos de conexión y el momento en que se produjo.
- Latencia.
- Último mensaje utilizado por tópico (última vez que se ha recibido un fragmento de ese nodo, última vez que se ha recibido un bloque de ese nodo…).
Información sobre el nivel de la cadena de bloques:
- Fallos (por ejemplo, intentar enviar un bloque inválido).
- Contribuciones en la red.
- El estado de la cadena de bloques (por ejemplo, tips).
Política
La política P2P proporciona un control más preciso sobre cómo manejar los nodos marcados como no confiables, no se comportan según lo esperado (ver la lista de datos recopilados).
Actualmente actúa en 3 niveles:
- Posible contacto.
- Cuarentena.
- Olvidado.
Cada nuevo chisme creará una nueva entrada en la lista de posibles contactos. A continuación, la política, basada en los datos registrados asociados a este nodo, puede decidir poner este nodo en cuarentena durante cierto tiempo. Al final de ese tiempo el nodo puede decidir una de las siguientes opciones:
- Permanecer en cuarentena.
- Hacer que sea de nuevo un contacto accesible.
- Olvidarse de él.
Los cambios de un nivel a otro son sólo hacia el mejor esfuerzo. La aplicación de la política puede ser costosa, por lo que el nodo ejecuta la política sólo en el nodo que le interesa (una actualización de chismes, o cuando informa de un problema contra un nodo). Esto garantiza que el nodo no pierda demasiado tiempo vigilando su base de datos. Y también asegura de que sólo los nodos que generan interés permanezcan actualizados. Sin embargo, es posible que el nodo elija, en un momento conveniente, la política de toda la base de datos P2P. Esto no se hace cumplir por el protocolo.
Estados del nodo:
- Disponible: El nodo está disponible en la topología P2P para ser elegido y ser objeto de chismes.
- En cuarentena: El nodo no está disponible en la topología P2P para ser elegido o ser objeto de chismes. Si luego de cierto tiempo el nodo sigue siendo objeto de chismes (los demás nodos lo encuentran como accesible), cambiará su estado a disponible.
- Olvidado: Un nodo olvidado simplemente se elimina de toda la base de datos P2P. Sin embargo, si el nodo sigue siendo objeto de chismes, se añadirá de nuevo como disponible y el proceso comenzará de nuevo.