Nodo

La plataforma de blockchain de Bitxor se construye a partir de una red de nodos. Estos nodos proporcionan una plataforma potente, estable y segura donde se realizan transacciones de Smart Assets, se realizan b煤squedas y se registran de forma inmutable en el libro mayor de la blockchain.

../_images/four-layer-architecture.png

Ventaja de rendimiento de Bitxor: Una arquitectura de cuatro capas

La arquitectura de cuatro capas permite a los desarrolladores actualizar cualquiera de estas capas sin interrumpir las dem谩s, lo que mejora la seguridad.

Nodo par

Repositorio: Cliente BitxorCore

../_images/peer-detail.png

Comunicaci贸n entre nodos pares

Los nodos pares forman la columna vertebral de la blockchain, lo que hace que la red sea robusta ya que no puede ser cerrada eliminando una 煤nica entidad. El papel del nodo es verificar transacciones y bloques, ejecutar el algoritmo de consenso, crear nuevos bloques y propagar los cambios a trav茅s de la red.

Los nodos de la API env铆an nuevas transacciones a la red P2P, donde son incluidas en un bloque o descartadas. Despu茅s de que se procesa el bloque, el nodo guarda:

  • El binario de cada bloque como un archivo plano en el disco.

  • El estado de la cadena actualizado en la memoria o en RocksDB (configurable).

RocksDB

Los nodos pares almacenan el estado de la cadena en RocksDB. Las estructuras de datos en cach茅 se serializan y almacenan como valores en las claves correspondientes. Por ejemplo, una columna en esta base de datos mapea las claves p煤blicas a las direcciones. Otra columna, las entradas del estado de la cuenta, son los valores correspondientes a las claves de direcci贸n.

Almacenar el estado en la memoria es m谩s r谩pido que usar RocksDB. Sin embargo, almacenar la informaci贸n del estado en RocksDB requiere menos memoria de los nodos de la red.

Note

Persistir el estado en RocksDB es conveniente en redes con un gran n煤mero de cuentas.

Reputaci贸n del nodo

Las redes p煤blicas permiten que cualquiera ejecute un nodo. Algunos de estos nodos podr铆an compartir informaci贸n inv谩lida o intentar perturbar la red.

Para reducir los intentos de comunicaci贸n err贸nea, los nodos llevan un registro de los resultados de las comunicaciones anteriores. Cada nodo con capacidades P2P lleva un contador de 茅xito y un contador de fallos para cada otro nodo par con el que ha interactuado.

Los nodos actualizan los contadores en consecuencia despu茅s de procesar los datos solicitados. Si un nodo se conecta correctamente a un nodo par remoto, incrementa primero el contador de 茅xito hacia el nodo par remoto. Si el intento de comunicaci贸n falla, el nodo incrementa el contador de fallos del nodo par remoto. De manera similar, el nodo actualiza los contadores de los pares despu茅s de procesar los datos compartidos.

Extrapolando a partir de estas puntuaciones, el nodo asigna un peso entre 500 y 10000 a cada par alcanzado.

La probabilidad de seleccionar un nodo remoto para leer datos depende linealmente de su peso. Cada cuatro rondas de selecci贸n de nodos, los criterios cambian para evitar ataques Sybil.

Nodo de API

Repositorio: Cliente BitxorCore

../_images/api-detail.png

Comunicaci贸n entre nodos pares y nodos de API (dual)

La responsabilidad principal de un nodo de API es almacenar los datos en una forma legible en MongoDB. El software bitxorcore-client permite configurar nodos de API independientes o con capacidades de nodos pares (dual).

En lugar de escribir los datos directamente en MongoDB, los nodos los escriben en una cola basada en archivos llamada spool. Un servicio de intermediario consume los datos de la cola y actualiza MongoDB en consecuencia. Una vez que se procesa un bloque, el servicio de intermediario notifica los cambios a las instancias de bitxorcore-rest utilizando ZMQ.

Los nodos de la API tambi茅n son responsables de recopilar las cosignaturas de transacciones de enlace agregadas, que solo se procesan una vez que est谩n completas.

MongoDB

MongoDB almacena bloques, transacciones y estados de la cadena para un alto rendimiento de consultas.

El servicio de intermediario actualiza la instancia de MongoDB vinculada cuando:

  • Se completa un nuevo bloque o un conjunto de bloques.

  • Se completa el procesamiento de nuevas transacciones no confirmadas.

Note

No se debe acceder a MongoDB externamente.

ZMQ

ZeroMQ es una biblioteca de mensajer铆a as铆ncrona que permite suscripciones en tiempo real. Transporta notificaciones desde el nodo de API hasta el punto final de ZMQ, donde BitxorCore REST escucha. Es una alternativa a los WebSockets REST, dise帽ada para ser utilizada cuando el rendimiento es cr铆tico.

Pasarela REST

Repositorio: BitxorCore REST

../_images/rest-detail.png

Comunicaci贸n de la pasarela REST

Las pasarelas REST manejan las solicitudes de clientes de la API JSON. La pasarela lee desde MongoDB, formatea la respuesta y la devuelve al cliente. Este componente tambi茅n es responsable de devolver eventos al cliente utilizando WebSockets.

Cada pasarela REST se conecta a una instancia de API para enviar solicitudes de nuevas transacciones desencadenadas desde el lado del cliente y recibir actualizaciones en tiempo real utilizando sockets.

Gu铆as relacionadas