Plugin

Bitxor cuenta con una mejor extensibilidad a trav茅s de su arquitectura basada en plugins.

Un plugin es un grupo aut贸nomo de funciones que se pueden agregar al protocolo de Bitxor para ampliar sus capacidades. El enfoque de plugins permite a los desarrolladores introducir diferentes formas de modificar el estado de la cadena a trav茅s de transacciones sin modificar el motor principal o interrumpir otras caracter铆sticas.

Cada tipo de transacci贸n base disponible en Bitxor se define como un plugin separado. Esta separaci贸n permite cargar solo un subconjunto m铆nimo de caracter铆sticas para adaptarse a los requisitos de la red.

Arquitectura

La forma m谩s sencilla de un plugin de Bitxor es un archivo escrito en C++ que registra un PluginManager y expone un 煤nico punto de entrada. El archivo debe tener el siguiente formato para que bitxorcore-client pueda vincular din谩micamente el plugin.

#pragma once
#include "bitxorcore/plugins.h"

namespace bitxorcore { namespace plugins { class PluginManager; } }

namespace bitxorcore { namespace plugins {

    /// Registra el soporte de transferencia con \a manager.
    PLUGIN_API
    void RegisterTransferSubsystem(PluginManager& manager);
}}

Todos los archivos relacionados con el plugin se almacenan en la misma carpeta bajo el directorio plugins para mantener organizado el c贸digo. La carpeta tambi茅n incluye el archivo CMakeLists.txt, que indica al compilador c贸mo construir el plugin.

cmake_minimum_required(VERSION 3.14)

set(PLUGIN_BASE_NAME bitxorcore.plugins.token)

bitxorcore_tx_plugin_src(${PLUGIN_BASE_NAME})

El plugin puede definir los siguientes subm贸dulos internamente para mantener organizado el c贸digo:

Subm贸dulo

Descripci贸n

cache

Tipos de cach茅 y reglas para serializar y deserializar tipos de modelos en binario.

config

Par谩metros configurables definidos como un conjunto de pares clave-valor. El valor de cada par谩metro se define en el archivo de configuraci贸n de red config-network.properties.

model

Tipos de transacciones y la asignaci贸n de esos tipos a reglas de an谩lisis. Espec铆ficamente, el plugin define reglas para traducir una transacci贸n en notificaciones de componentes que se utilizan en el procesamiento posterior.

observers

Los observadores procesan las notificaciones generadas por el procesamiento de bloques y transacciones. Los observadores registrados pueden suscribirse a notificaciones generales o definidas por el plugin y actualizar el estado de la cadena de bloques en funci贸n de sus valores. Los observadores no requieren ninguna l贸gica de validaci贸n porque solo se llaman despu茅s de que todos los validadores aplicables tienen 茅xito.

plugins

Instrucciones para que el motor principal cargue el plugin. Este subm贸dulo contiene el archivo PluginManager.

validators

Validadores sin estado y con estado procesan las notificaciones generadas por el procesamiento de bloques y transacciones. Los validadores registrados pueden suscribirse a notificaciones generales o definidas por el plugin y rechazar valores o cambios de estado no permitidos.

Seguridad

El c贸digo definido en un plugin se ejecuta continuamente a menos que la red se detenga o todas las nodos de la red decidan utilizar una nueva configuraci贸n que deshabilite el plugin. Si un subconjunto de nodos no adopta los cambios de configuraci贸n, la cadena se dividir谩 en dos.

Antes de escribir l贸gica personalizada, los desarrolladores deben intentar resolver el caso de uso utilizando el conjunto de transacciones proporcionadas en Bitxor de forma predeterminada. Ten en cuenta que los plugins base de Bitxor han sido auditados. La plataforma est谩 ejecutando un extenso per铆odo de prueba en una red de prueba antes del lanzamiento p煤blico, y su c贸digo ha sido de c贸digo abierto desde abril de 2018.

Si decides crear un nuevo plugin, se recomienda probar el c贸digo exhaustivamente, contar con auditores externos y ejecutar un per铆odo de prueba en una red de prueba antes de lanzar la red en producci贸n para minimizar las vulnerabilidades en el c贸digo personalizado.