🤶🏼 🥥 🤰🏿 Marco: análisis de sistemas DLT 🧑🏿‍🤝‍🧑🏼 🤰 👩🏻‍🤝‍👨🏼

Este trabajo tiene como objetivo determinar si el objeto analizado es un sistema DLT. Los resultados obtenidos son adecuados para el análisis comparativo de varios proyectos, que van desde la estructura de gestión hasta la definición de enlaces a los que se refieren las transacciones.

La tecnología de contabilidad distribuida es una tecnología para almacenar información, cuyas características clave son el intercambio y la sincronización de datos digitales de acuerdo con el algoritmo de consenso, la distribución geográfica de copias equivalentes en diferentes puntos del mundo, la ausencia de un administrador central.

Análisis técnico

Nivel de protocolo

Génesis

El nivel de protocolo se refiere a los procesos que deben desarrollarse y ejecutarse antes de que comience la red.

Dependencia de otras redes.

La dependencia de otros protocolos depende de los límites del proyecto analizado. Esto determina si el sistema puede funcionar como un sistema independiente (para ser autosuficiente) o si depende de otra red.

Tabla 1. Dependencia de otros sistemas.

Código del programa

El código puede estar basado en un marco existente o escrito desde cero. Los marcos más populares son las bases de código de sistemas de código abierto (Bitcoin / Ethereum). También hay bases de datos de código cerrado para plataformas cerradas proporcionadas por proyectos como Digital Asset / Clearmatics y SETL.

Tabla 2. Código de programa

Definiendo Reglas

La introducción de reglas se refiere a la definición de un conjunto de reglas sobre las cuales debe operar un sistema DLT. Este proceso puede ser realizado por diferentes participantes y es individual para un sistema DLT particular.

Actualización de protocolo

Las actualizaciones de protocolo se aplican a los procesos existentes que le permiten modificar las reglas del sistema. La actualización del protocolo puede incluir la eliminación de errores técnicos (errores), mejorar la seguridad y la funcionalidad del sistema, así como expandir o limitar las reglas de protocolo existentes.

Gestión de protocolos

La administración de protocolos se refiere a un conjunto de procesos de toma de decisiones que le permiten cambiar un protocolo de manera ordenada y legal. Este es un subconjunto de gestión de proyectos más amplia, que cubre un conjunto completo de procesos y normas que describen y definen la coordinación y las acciones, pero que no pueden integrarse formalmente en el sistema DLT.

Un elemento importante de cualquier cambio propuesto al protocolo es la forma en que se adopta y ratifica, o, en otras palabras, cómo se proporciona legitimidad a sugerencia de los participantes de la red. Dado que la legitimidad en este contexto es un concepto social, parece razonable identificar algunas de las posibles relaciones "sociopolíticas" que se encuentran en los sistemas DLT.

Tabla 3. Gestión de protocolos

La gestión del protocolo toma muchas formas y a menudo no está clara. Inicialmente, los sistemas DLT se caracterizan por el poder anarquista (gratuito), no hay empresas o grupos de personas responsables de tomar decisiones. Sobre todo, son similares a los procesos de gestión de tráfico de código abierto. Un ejemplo de discusión sobre cambios de protocolo puede ser la comunicación de los desarrolladores en un chat / GitHub / conferencia. Bajo condiciones dictatoriales, el proceso de discutir los cambios puede ser exactamente el mismo, pero la decisión final será tomada por una persona. En algunos casos, un formulario de gestión de protocolo puede ser definido por más de un tipo de placa. Por ejemplo, la cadena de bloques EOS actúa como una federación de fabricantes de bloques que son seleccionados por los usuarios que poseen un activo EOS. El peso del voto está determinado por la cantidad de tokens en la dirección. Este tipo de gobierno divide el protocolo en dos partidos: los usuarios "de élite" y "ordinarios", que adoptan las características de un sistema jerárquico: federación, democracia y plutocracia.

La gestión en cadena implica la inclusión de funciones de gestión a nivel de datos. El objetivo es formalizar la gobernanza, aumentando así la legitimidad y evitando la fragmentación de la red debido a disputas o actualizaciones de protocolos inconsistentes. Se ha desarrollado un conjunto diverso de esquemas de votación en cadena para los sistemas DLT, que van desde un barómetro de ánimo comunitario hasta referéndums. Sin embargo, las funciones de gestión en cadena, por regla general, son solo una adición a otras formas de gestión.

Cambio de protocolo

El proceso real de actualización del protocolo implica:

actualizar el código en GitHub si es un proyecto de código abierto;
actualización del cliente si es un protocolo de código cerrado;
Los clientes que trabajan en el antiguo código del programa pueden considerarse irrelevantes y estar en la lista negra;
Los clientes que se ejecutan en el antiguo código del programa forman una bifurcación, lo que conduce a la creación de una versión alternativa del protocolo.

Tabla 4. Formulario de modificación de protocolo

Los diferentes sistemas DLT utilizan diferentes métodos para actualizar la red. Por ejemplo, Ethereum acepta donaciones para financiar el desarrollo y también actualiza la red utilizando software de desarrolladores financiados por subvenciones.

Nivel de red

La red de protocolo DLT es un resultado directo de la implementación de reglas de protocolo. La red consiste en el trabajo coordinado de los participantes y los procesos que se adhieren a un estándar tecnológico (protocolo) y participan activamente en el intercambio de datos e información a través de canales de comunicación específicos.

Proceso de comunicación

El proceso de transferencia de datos entre participantes en un sistema DLT.

Acceso a la red

El acceso a la red implica la posibilidad de conectarse al protocolo, puede ser limitado o ilimitado.

Acceso ilimitado : cualquier usuario puede conectarse / desconectarse libremente en cualquier momento;
Acceso limitado : solo ciertos usuarios pueden conectarse a la red, generalmente esto es controlado por la entidad designada.

Como regla general, los sistemas con acceso ilimitado no tienen restricciones en el número de participantes, mientras que las redes cerradas pueden establecer un número limitado de participantes.

Por lo general, los participantes obtienen acceso directo a la red mediante el lanzamiento de nodos completos: se les considera una "élite" con un amplio conjunto de derechos, ya que pueden enviar / verificar y transferir datos de registros. Los participantes de la red también pueden obtener acceso indirecto a la red ejecutando "clientes ligeros" que solicitan datos de nodos completos mediante la conexión a través de un servicio especial (API).

Tabla 5. Formulario de acceso a la red

Como regla general, cuanto más abierto es el sistema, más susceptible es a los ataques. En particular, estos sistemas son vulnerables al ataque Sibyl, cuando el atacante crea muchas identidades falsas para aumentar la influencia en la red.

El ataque Sibyl es un tipo de ataque cuando un atacante obtiene acceso u oculta un cambio en el protocolo, creando muchas identidades falsas.

Dado que la identificación es una propiedad exógena (es decir, "real"), el sistema DLT no puede evitar estos ataques, debe confiar en participantes externos (sistema de certificación) o mecanismos que reducen la probabilidad de un ataque (PoW / PoS).

Enviando datos

La transferencia de datos es el proceso de distribución de datos a los nodos conectados. Los datos pueden ser sin formato / sin formato o estandarizados a un formato específico (por ejemplo, en forma de una transacción o registro). Los datos se pueden transmitir a cada nodo (difusión universal), o solo a un subconjunto específico de nodos (difusión multicanal). En este último caso, la difusión de datos generalmente se limita a los participantes en la transacción. Esto le permite crear un "canal" para la transferencia de datos, por lo general se entiende fragmentación / Lightning Network.

Los primeros sistemas DLT (por ejemplo, Bitcoin, Litecoin) usan un modelo de distribución de datos universal, que sigue siendo el método de distribución de datos más popular.

Para mantener el anonimato y la privacidad de las empresas, los sistemas posteriores tienen un modelo de difusión multicanal (por ejemplo, Hyperledger Fabric, Corda). Otros sistemas, como Cosmos, están diseñados para actuar como "centros", de modo que los sistemas DLT independientes pueden interconectarse mediante fragmentación.

Tabla 6. Formulario de envío de datos

Un ejemplo de difusión de datos multicanal es que no todos los participantes de la red deben participar en un consenso sobre el estado del canal: solo los participantes del canal deben lograr la coherencia sobre los datos almacenados en este canal (consenso "local"). Esto es significativamente diferente de los sistemas con difusión de datos global, ya que cada nodo individual debe llegar a un consenso sobre el estado global del sistema (consenso "global"); La incapacidad para llegar a un consenso de algunos nodos puede conducir a su desconexión o la creación de una bifurcación.

Creación de transacciones

El proceso de creación de transacciones contiene un conjunto de instrucciones que se ejecutarán después de agregar una transacción a la red. La creación de transacciones puede ser ilimitada (es decir, accesible para todos) o limitada a algunos participantes. Las transacciones son creadas por los usuarios que firman el mensaje con su clave privada. Hay varias interfaces disponibles para que los usuarios creen y envíen transacciones a la red (por ejemplo, PC y billeteras móviles).

Procesamiento de transacciones

El procesamiento de transacciones describe el conjunto de acciones requeridas para agregar una transacción no confirmada a la lista de confirmadas. Una transacción se considera (preliminar) válida después de agregar ("confirmada") a la lista, lo que lleva a la ejecución de instrucciones integradas en la transacción. Sin embargo, la confirmación por sí sola no es suficiente para que esta transacción se convierta en la base de operaciones posteriores; antes de que el sistema pueda utilizar las salidas de transacción.

Figura 1. Procesamiento de transacciones en un sistema DLT

Los registros obedecen a un algoritmo de consenso específico utilizado en el sistema DLT. Esto incluye el proceso de determinar si el registro propuesto es válido, así como rechazar entradas no válidas (por ejemplo, entradas que son defectuosas o incompatibles) y elegir entre entradas diferentes pero igualmente válidas.

Grabar candidato

Los creadores de los bloques envían las entradas que se pueden mover a la lista de transacciones confirmadas en el futuro, quienes las seleccionan de la lista de transacciones no confirmadas y las combinan para formar candidatos para escribir en la lista de registros confirmados. Hay dos propiedades que determinan el derecho a enviar un registro y su futura inclusión en la lista de registros confirmados.

Tabla 7. Formularios de registro

Debido a que los registros están sujetos a consenso, deben cumplir con las reglas del protocolo. Primero, deben formatearse correctamente y no contener transacciones inválidas o inválidas. Además, cada entrada debe incluir un enlace / puntero a la entrada anterior y, si es necesario, utilizar PoW o cualquier otro método que dificulte la realización de un ataque Sibyl.

El algoritmo de consenso se puede clasificar de acuerdo con su nivel de complejidad (costos eléctricos / monetarios). Los algoritmos con una complejidad ilimitada se miden en los recursos necesarios para llegar a un consenso. Por ejemplo, en el caso de calcular PoW Bitcoin, la dificultad de encontrar la solución correcta aumenta a medida que aumenta la complejidad de los datos de hash. Por el contrario, otros algoritmos funcionan (por ejemplo, la tarea Bizantine Generals / BFT) no requieren costos computacionales significativos y tienen una complejidad limitada.

En sistemas abiertos, se debe proporcionar un algoritmo que reduzca la posibilidad de un ataque de Sybil. Los sistemas privados (cerrados) verifican a cada participante antes de permitirles el acceso a la conexión de red, lo que evita la posibilidad de un ataque. En sistemas cerrados, un grupo de nodos tiende a elegir un nodo que creará bloques.

Resolución de conflictos

Un conflicto puede ser causado por varias razones:

los participantes no están de acuerdo sobre qué versión del protocolo es relevante;
Los participantes no están de acuerdo con las transacciones verificadas.

En el caso de una situación del primer punto en la red de Bitcoin, la red selecciona la cadena de bloques más larga como válida e ignora la más corta. En Tezos, la validez de un bloque se determina con un "peso de bloque" diferente, el peso aquí es el número de "aprobaciones" de los validadores que recibe aleatoriamente de los stakers.

Cualquier algoritmo de consenso conlleva una serie de compensaciones

Tabla 7. Formas de motivación para el procesamiento de transacciones

Validación

La validación se refiere al conjunto de procesos necesarios para garantizar que los sujetos lleguen independientemente a la misma conclusión con respecto a un conjunto aprobado de registros. Esto incluye: verificar las transacciones enviadas / verificar los datos grabados / verificar el estado general de la red. Esta es una distinción importante de los sistemas que no son DLT, ya que brinda a los participantes la oportunidad de realizar una auditoría independiente del sistema.

Verificación de transacciones

Verificar una transacción es asegurarse de que un registro individual cumpla con las reglas del protocolo antes de transferirlo a otras entidades. Esto incluye: la exactitud del formato de la transacción, la presencia de una firma apropiada y el cumplimiento de la condición de que la transacción no entre en conflicto con ninguna otra. Algunos sistemas pueden operar un sistema que prohíbe las transacciones hasta un momento específico u otra razón. Por lo general, estas condiciones se cumplen mediante contratos inteligentes.

Un ataque del 51% es el caso cuando un participante o varios participantes combinan su poder de cómputo (voces) y procesan transacciones en la red más rápido que el resto del protocolo. Dichos ataques le permiten realizar transacciones no válidas y registrarlas como válidas. Especialmente vulnerable es un sistema que utiliza PoW

Verificar registros

Verificar el registro que se envía le permite asegurarse de que el registro cumpla con las reglas del protocolo. Si la entrada propuesta se reconoce como válida, se agrega a la lista de entradas confirmadas y se transmite a todos los nodos conectados en la red. Aunque este proceso es diferente en cada sistema, pero, por regla general, por principios generales, es similar en todas partes, por ejemplo, verificando que el trabajo de PoW se haya realizado en una transacción. La combinación de la verificación de las transacciones enviadas y su posterior registro por parte de los validadores proporciona una auditoría independiente de todo el sistema.

Registro de la transacción

Una transacción / registro confirmado no es necesariamente irreversible. La irreversibilidad de escritura puede ser probabilística (por ejemplo, un sistema basado en PoW en el que no es práctico recalcular todas las transacciones registradas) o sistemas que incluyen "puntos de control" que deben asignarse a cada transacción. Los registros confirmados pueden llamarse inmutables, pero los que han sido "preconfirmados" pueden cancelarse. Los registros preconfirmados no cambian después de superar el estado de transición de "preconfirmado" a "confirmado".

Figura 2. Procesamiento de transacciones en sistemas DLT

La Figura 2 describe una descripción esquemática del proceso que ocurre durante el procesamiento de la transacción. Primero, el usuario crea una transacción y la envía a la red. Cada nodo verifica si la transacción cumple con las reglas del protocolo. Si se considera correcto, el nodo agrega la transacción a su lista (mempool), donde se almacenan todas las transacciones no confirmadas, esperando ser agregadas a la lista de transacciones confirmadas.

En la etapa de procesamiento de transacciones, los nodos seleccionan aleatoriamente transacciones no confirmadas de su mempool y luego las combinan en una lista de transacciones "preaprobadas". A continuación, las transacciones se verificarán de acuerdo con el algoritmo de consenso para ofrecer estas transacciones a todos los demás participantes de la red. Los nodos verán las transacciones recibidas y su contenido; si la transacción pasa la verificación, la transacción se agrega a la lista del nodo. Las listas con transacciones de cada nodo se envían finalmente a una lista única y más importante de transacciones confirmadas y se considerarán completadas.

Sin embargo, las transacciones confirmadas pueden "cancelarse" debido a una transacción alternativa, lo que significa que en la etapa de liquidación, las transacciones pueden cancelarse; en este caso, regresan a los nodos como transacciones no confirmadas, esperando crear una nueva lista de transacciones. El tiempo de procesamiento de la transacción en la etapa de "Liquidación" depende de la configuración de un solo sistema. Algunos sistemas implementan el registro instantáneo de transacciones y su irrevocabilidad, pero algunos protocolos tienen una finalización "probabilística", en el sentido de que las transacciones pueden cancelarse teóricamente. En la práctica, sin embargo, la probabilidad de esta acción disminuye con cada nueva transacción agregada, ya que los costos de los nodos asociados con PoW pueden llegar a ser altos. Si bien las transacciones se encuentran en la etapa de "liquidación", no pueden considerarse "completadas".El proceso de liquidación de transacciones mejora la garantía de que las transacciones se enumeran con precisión en todos los nodos participantes, y no se almacenan solo en nodos locales, esto ayuda a prevenir ataques de doble gasto.

Algunos sistemas implementan un sistema de "punto de control" para limitar la posibilidad de ataques de largo alcance. En el caso de este ataque, el nodo crea una cadena alternativa con sus transacciones personales (que solo son almacenadas por él), estas transacciones no aparecen en la red, sino que se envían inmediatamente a los nodos en la etapa de "liquidación" para obligar a otros nodos a reemplazarlos con sus transacciones locales. Los "puntos de control" son bloques que nunca se deshacerán ni reemplazarán. Como resultado de los puntos de control, se reduce el "alcance" del ataque. Sin embargo, los hitos aumentan el riesgo de una bifurcación.

Tabla 8. Propiedades de transacción confirmada

Nivel de datos

El nivel de protocolo determina cómo funcionará el sistema y qué reglas seguir. La capa de red implementa los principios subyacentes del protocolo. Juntos, la capa de protocolo y la red forman la base de la capa de datos, que se acumula con el tiempo a medida que las transacciones se escriben en la lista de registros confirmados.

Operaciones

El componente de operaciones incluye todos los procesos por los cuales los participantes interactúan con el sistema.

Fuentes de datos

El proceso de entrada se refiere a una fuente o método de obtención de datos para un protocolo. Las fuentes de datos pueden ser internas o externas, lo que puede reflejar la interacción activa de los usuarios con el sistema, un cambio en el estado del protocolo causado por un proceso interno del sistema o recibido desde el exterior (por ejemplo, una transacción enviada desde otro protocolo) o un contrato inteligente.

Definimos las fuentes de entrada internas como cualquier registro o transacción creada por el usuario o debido al resultado de la interacción del usuario con el protocolo. Las fuentes de entrada externas, por otro lado, son el resultado de la entrada de otros sistemas que interactúan con el protocolo, pero que, en principio, están separados de la plataforma subyacente (es decir, dependen o interactúan). Los protocolos híbridos permiten a los usuarios transferir transacciones utilizando los canales de pago del "canal estatal" en cualquier momento, sin embargo, el desarrollo de estos métodos aún se encuentra en la etapa inicial.

Tabla 9. Formularios de entrada de datos

Transacciones ejecutables por software

No todos los cambios en el nivel de datos son el resultado directo de una entrada interna o externa. Algunos cambios en el sistema ocurren debido a la ejecución de las instrucciones del código. Un ejemplo sorprendente son los contratos inteligentes. Al ejecutar el código del programa incrustado, el estado de la red cambia en el protocolo, por ejemplo, se produce una transacción, que se registra en la lista de confirmados. Algunos sistemas DLT solo admiten lenguaje de script (script). Por ejemplo, Bitcoin Script, funciona en un lenguaje de script simple que le permite crear programas simples y limitados. Tales sistemas se llaman: sin estado. Ethereum (Solidity), Tezos (Michelson) y EOS (WebAssembly): estos sistemas admiten lenguajes de programación completos de Turing para desarrollar contratos inteligentes complejos, mientras que Bitcoin y Monero usan un lenguaje de secuencias de comandos,lo que permite operaciones limitadas.

Tabla 10. Propiedades de las transacciones ejecutadas por software La

ejecución real de los cálculos El

lugar donde se ejecuta el programa determina dónde se realizan los cálculos. Como regla general, el lugar de ejecución puede estar dentro de la red: dentro o fuera de la cadena (fuera de la red). Los cálculos en cadena se realizan en cada nodo. Este entorno puede variar desde una máquina virtual simple, como un lenguaje de script o ser complejo (EVM - máquina virtual Ethereum), lo que garantiza la ejecución de programas completos de Turing. Los contratos inteligentes en la cadena son lanzados por cada nodo en la red y, por lo tanto, a menudo se denominan "autoejecutables".

La computación fuera de la cadena se realiza en un entorno externo al protocolo. El evento que ejecuta el código del programa ocurre en la cadena y los cálculos tienen lugar en otro sistema, sin cargar la red principal. Además, hay un sistema híbrido (híbrido) para iniciar aplicaciones, por ejemplo, Plasma in Ethereum. O, por ejemplo, Cosmos, donde la red principal sirve como el "centro", pero los cálculos en sí ocurren en redes subsidiarias.

Tabla 11. Propiedades de ejecución de transacciones de software

Componente de registro

Referencias

Desde el momento en que los usuarios comienzan a interactuar con el sistema DLT, el registro se actualiza con el tiempo. Sin embargo, una revista es una abstracción. Todos los procesos que ocurren en el sistema DLT están relacionados con un protocolo específico. Por ejemplo, un protocolo centrado en pagos electrónicos debe contener información sobre los activos propiedad de usuarios específicos. Por otro lado, un sistema DLT, que incluye contratos inteligentes, debe tener su propia máquina virtual que implemente la ejecución del código del programa. Por lo tanto, el concepto de revista es una abstracción.

Tipos de enlaces

Existen cuatro tipos diferentes de datos de origen: datos endógenos, exógenos, híbridos y auto-referenciados.

Los enlaces endógenos (internos) se relacionan con datos que rastrean información sobre variables que son "nativas" del sistema. Por ejemplo, en Bitcoin, una variable de referencia endógena se usa para rastrear la cantidad de bitcoins que los usuarios tienen en un momento dado. Esta variable interna se actualiza a medida que el usuario envía y recibe bitcoins a otras direcciones. Un enlace exógeno (externo) se refiere a datos que rastrean información sobre variables que existen fuera del sistema. La referencia híbrida se refiere a datos que tienen características endógenas y exógenas. Todavía hay un cuarto tipo, que no es ni endógeno ni exógeno, ni híbrido: es un tipo de datos neutro o vacío; es un enlace autorreferenciado. Por ejemplo, un contrato inteligente es solo una pieza de código,que se puede realizar bajo ciertas condiciones. Aunque un contrato inteligente puede requerir información sobre variables externas o internas del sistema, el código en sí no tiene un enlace interno a nada fuera de sí mismo (un "enlace en blanco").

Tabla 12. Tipos de enlaces y su significado

Marco: análisis de sistemas DLT