En esta sección se describe cómo los nodos de la plataforma de blockchain IBAX interactúan entre sí desde un punto de vista técnico.
Debe ejecutarse en cada nodo de la red. El demonio del servidor ejecuta las diversas funciones del servidor y admite el protocolo de cadena de bloques de la plataforma de cadena de bloques IBAX.
El demonio distribuye bloques y transacciones en la red de la cadena de bloques, genera nuevos bloques y verifica los bloques y transacciones recibidos. El demonio puede prevenir problemas de bifurcación de la cadena de bloques.
El nodo de honor ejecuta los siguientes demonios de servidor:
Genera nuevos bloques.
Descarga nuevos bloques de otros nodos.
Confirma que los bloques existentes en el nodo también existen en la mayoría de los demás nodos.
Demonio Disseminator
Distribuye transacciones y bloques a otros nodos principales.
Demonio QueueParserBlocks
Procesa los bloques en la cola de bloques, que contiene bloques de otros nodos.
La lógica de procesamiento de bloques es la misma que la del demonio BlockCollection.
Demonio QueueParserTx
Verifica las transacciones en la cola de transacciones.
Demonio Scheduler
Ejecuta contratos según lo programado.
Guardian Node ejecuta los siguientes procesos de servidor de demonio:
- Demonio BlockCollection.
- Demonio Confirmations
- Demonio Disseminator
- QueueParserTx
- Scheduler
El proceso de demonio de BlocksCollection es responsable de descargar bloques y sincronizar la cadena de bloques con otros nodos de la red.
El proceso de BlocksCollection Daemon sincroniza la cadena de bloques mediante la determinación de la altura máxima de bloque en la red de la cadena de bloques, solicitando nuevos bloques y resolviendo bifurcaciones en la cadena de bloques.
El proceso de vigilancia de BlocksCollection envía solicitudes del ID de bloque actual a todos los nodos honorables.
Si el ID de bloque actual del nodo de este proceso es menor que el ID de bloque actual de cualquier nodo honorable, entonces se considera que el nodo de la red de la cadena de bloques está desactualizado.
El nodo que devuelve la altura máxima del bloque actual se considera el nodo más reciente.
El demonio descarga todos los bloques que aún no conoce.
Si se detecta una bifurcación en la cadena de bloques, el proceso de vigilancia avanzará hacia atrás la bifurcación descargando todos los bloques hasta llegar al bloque padre común.
Una vez encontrado el bloque padre común, se realizará un rollback en la cadena de bloques del nodo del proceso de vigilancia y se agregarán los bloques correctos a la cadena de bloques hasta llegar al bloque más reciente.
El proceso de BlocksCollection utiliza las siguientes tablas de datos:
- block_chain
- transactions
- transactions_status
- info_block
El programa BlockCollection envía la siguiente solicitud a otros programas de guardia:
El proceso de BlockGenerator genera nuevos bloques en segundo plano.
El proceso de BlockGenerator Daemon planifica la generación de nuevos bloques analizando el último bloque de la cadena de bloques.
Se pueden generar nuevos bloques si se cumplen las siguientes condiciones:
- El nodo que genera el último bloque se encuentra en la lista de nodos de Honor del nodo del proceso de BlockGenerator.
- El tiempo más corto transcurrido desde la generación del último bloque no validado.
Después de que el proceso de protección genere un nuevo bloque, el nuevo bloque contendrá todas las nuevas transacciones. Estas transacciones pueden ser recibidas desde otros nodos del Demonio Disseminator, o pueden ser generadas por el nodo de este proceso de protección. Los bloques generados se guardan en la base de datos del nodo de este proceso.
El programa BlockGenerator utiliza la siguiente tabla:
- block_chain (saves new blocks)
- transactions
- transactions_status
- info_block
El proceso de BlockGenerator no envía ninguna solicitud a otros procesos de demonio.
El proceso de Disseminator envía transacciones y bloques a todos los nodos Honor.
Cuando se trabaja en un nodo guardián, el daemon envía las transacciones generadas por su nodo a todos los nodos de honor.
Cuando se trabaja en un nodo de honor, el proceso de guardián envía el hash de los bloques y transacciones generados a todos los nodos de honor.
Luego, los nodos de honor responden a las solicitudes de transacciones desconocidas de su nodo. El proceso de guardián envía los datos completos de la transacción como respuesta.
El proceso de guardián Disseminator utiliza las siguientes tablas:
- transactions
El proceso de guardián Disseminator envía la siguiente solicitud a otros procesos de guardián:
Confirmations es un proceso de vigilancia que verifica si todos los bloques de su nodo están presentes en la mayoría de los otros nodos.
Cuando varios nodos en la red han confirmado un bloque, se considera confirmado.
El daemon comienza a confirmar todos los bloques uno por uno, comenzando desde el primer bloque no confirmado en la base de datos.
Cada bloque se confirma de la siguiente manera:
- Se envía una solicitud a todos los nodos honorables que contienen el ID del bloque que se está confirmando.
- Todos los nodos honorables responden con el hash del bloque.
- Si el valor hash de la respuesta coincide con el valor hash del bloque en el nodo del daemon, se incrementa el contador de confirmación. Si el hash no coincide, se incrementa el contador de no confirmación.
El proceso de confirmaciones del guardián utiliza la siguiente tabla de datos:
- confirmation
- info_block
El demonio de Confirmaciones envía las siguientes solicitudes a otros demonios:
- Type 4 Solicitar el hash del bloque al nodo de honor.
El protocolo de servicio TCP funciona en nodos de honor y nodos completos. Utiliza un protocolo binario sobre TCP para manejar solicitudes de los procesos de BlocksCollection, Disseminator y Confirmation.
Cada solicitud tiene un tipo definido por los primeros dos bytes de la solicitud.
El Demonio de Disseminator envió esta solicitud.
Hash de transacciones y bloques.
El hash del bloque se agrega a la cola de bloques.
Se verifica y analiza el hash de la transacción y se selecciona una transacción que aún no ha aparecido en el nodo.
No hay respuesta. Después de procesar esta solicitud, se enviará una solicitud Tipo 2.
El Demonio de Disseminator envía esta solicitud.
Datos de transacción, incluyendo el tamaño de los datos:
data_size (4 bytes)
El tamaño de los datos de la transacción, en bytes.
data (data_size bytes)
Los datos de la transacción.
Verifica la transacción y la agrega a la cola de transacciones.
Ninguna.
El Demonio de confirmaciones envía esta solicitud.
ID del bloque.
Hash del bloque.
Si no existe un bloque con ese ID, se devuelve 0.
El Demonio de BlockCollection envía esta solicitud.
ID del bloque.
- block_id (4 bytes)
Datos del bloque, incluido el tamaño de los datos.
data_size (4 bytes)
Tamaño de los datos del bloque, en bytes.
data (data_size bytes)
Datos del bloque.
Si no existe el bloque con ese ID, se cierra la conexión.
La solicitud la envía el Demonio de BlockCollection.
ninguno
ID de bloque.
- block_id (4 bytes)