Seleccionar página

En el modelo de consenso MNPoS introducido por Crown, tanto Masternodes (MN) como Systemnodes (SN) hacen función de nodos completos. Es otras palabras, ambos tipos de nodos especiales son los encargados de crear nuevos bloques de transacciones y añadirlos a la cadena de bloques. A su vez cumplen el rol de servidores con una copia de toda la cadena, sincronizada 24/7. Por tanto, en Crown solo MNs y SNs podrán realizar la Prueba de Participación(PoS). Los Masternodes tienen la función adicional de participar en la gobernanza (Crown Decentralised Governance Proposal System), donde 1MN efectúa 1 voto; también se encargan de procesar las transacciones intantáneas.

Entendiendo esto es fácil deducir la importancia de ambos tipos de nodos especiales para el buen funcionamiento de la red, y evidentemente el consenso: mientras más MN y SN estén activos, más segura será la red.

Para ejecutar un MN o SN en Crown es necesario “bloquear” un monto colateral (10K CRW para los MN y 500 CRW para los SN), mediante una UTXO única. Es decir, para ser considerado un nodo activo es necesario asociar una dirección CRW que tenga un fondo colateral de 10K o 500 CRW. 

En el momento de creación del MN o SN se apunta a la entrada que contiene el fondo colateral, de esta manera se especifica la dirección que activará el nodo, cuya llave privada permite mover el colateral. El conocedor de esta llave privada será, por tanto, el “owner” del nodo. A la par, se crea una segunda llave privada (mn/sn-key) que se utilizará para firmar los mensajes a distribuir por la red P2P. Sin embargo, quien conozca esta segunda llave no podrá gastar ni desbloquear el fondo colateral. 

Este sistema permite que haya dos roles de cliente en dos máquinas distintas, el “hot” quien firmará la entrada, y conocería ambas llaves, y el cliente “cold” quien solo conocería la segunda llave y ejecutaría el nodo. De esta manera el fondo colateral no se vería comprometido, y el cliente “hot” podría mantenerse desconectado de la red. En la práctica el cliente “hot” es conocido como mn-sn owner, y el cliente “cold” como mn-sn operator. 

En este momento de configuración inicial, el cliente “hot” deberá modificar el archivo local (masternode/systemnode).conf e iniciar el nodo mediante el comando masternode start alias. De esta manera se envía un mensaje a la red P2P, que incluye la UTXO del colateral firmado, la llave publica, la llave pública de la segunda llave, una dirección IP, entre otros campos. Periódicamente se envía un mensaje de tipo Ping para verificar si el nodo está activo (todos los MN/SN deben tener sus puertos abiertos). Este mensaje incluye la UTXO del colateral, y una firma usando la segunda llave (mn/sn-key).  De esta manera se puede conocer los nodos activos en la red. 

En el caso que sea movido o gastado el colateral asociado, o el MN/SN interrumpe su función de validador en la red, el nodo dejará de ser considerado un MN o un SN activo por el resto de los integrantes.  

Cada cliente de la red Crown almacena un objeto caché con los MN y SN activos que conoce y su estado. Cada nuevo cliente que se incorpora a la red, envía un comando a los pares de la red P2P que esté directamente conectado preguntando por la lista de MNs y la lista de SNs que conoce dicho par. Por lo que la conformación de esta lista depende de los pares conectados y los mensajes que intercambien dichos pares, y no siempre ocurre que todos los clientes de la red tienen la misma lista de MN o SN, dicho de otra manera, la lista de MN y la lista de SN activos es no determinista (no existe una lista única conocida por todos). El momento de sincronización de ambas listas ocurre luego de que el cliente esté completamente sincronizado con la blockchain. 

A manera de resumen:

  • En Crown los Masternodes y Systemnodes ocupan un rol fundamental como aseguradores de la red. 
  • Los MN/SN tienen un owner, que posee el colateral asociado al nodo, y un operator, quien ejecuta el nodo, pero sin acceder a los fondos del owner.
  • La red conoce los MN/SN activos mediante un sistema de mensajes P2P, firmados por quien ejecuta el nodo. 
  • La lista de todos los MN/SN activos de la red no es única y dependerá de los pares conectados entre sí. 

Share This