Назад

      BLOCKCHAIN PAPEL BLANCO

      • 1. Introducción
      • 2. Transacciones
      • 3. Servidor de marca temporal
      • 4. Bloques
      • 5. Consagración de marcas temporales
      • 6. Implementación de Nimses
      • 7. Conclusión
      • 8. Referencias
      Nimses Blockchain: el sistema de los activos digitales.

      Anotación. Un sistema económico que proporciona a los participantes un ingreso básico incondicional por cada minuto que viven no puede basarse únicamente en la confianza de los usuarios y, al mismo tiempo, tener un rendimiento capacidad de las transacciones suficientes. Las soluciones frecuentes basadas solo en la confianza o en la criptografía no cumplen con los requisitos. Este artículo describe un sistema híbrido que resuelve este problema.
      El servidor centralizado pone las marcas del tiempo en las transacciones, al conectarlas en una cadena, los hashes de bloques de la cadena se guardan en un registro público, constante y generalmente aceptado. El modelo de las transacciones permite el procesamiento paralelo e independiente, y el rendimiento está limitado únicamente por la velocidad a la que se alcanza un consenso interno con respecto al pedido de las transacciones.

      1. Introducción

      Los modernos sistemas centralizados de activos digitales que resuelven el problema del doble desperdicio con la ayuda de un intermediario confiable, básicamente contienen la confianza de los usuarios del sistema. En la actualidad, dichos sistemas no pueden competir, en el contexto de la confianza, con análogos basados ​​en la criptografía y, por regla general, tener el mismo dispositivo [1]. Dichos sistemas generalmente contienen un mecanismo de recompensa que motiva a los usuarios a mantener la viabilidad del sistema, pero requiere enormes recursos computacionales, y elementos como un intermediario confiable y un emisor central se eliminan por completo. Otra desventaja importante de tales sistemas es la velocidad baja de procesamiento de transacciones, lo que los hace inadecuados para el uso global.

      Se necesita un nuevo sistema basado en la criptografía, pero no de la confianza. Dicho sistema debe proporcionar un rendimiento suficiente para el uso diario a gran escala.

      Este artículo propone una solución de la problema anterior. La solución se basa en un servidor de marca del tiempo centralizado y la presentación de un activo electrónico como una cadena de firmas digitales. El servidor actúa como un intermediario confiable para proteger contra el doble gasto, confirmando el orden cronológico de las transacciones. La confianza está garantizada al asegurar todo el historial de operaciones en un registro público inmutable.

      2. Transacciones

      Definimos un activo electrónico como una cadena pública de firmas digitales, y una cuenta como un par ordenado: un identificador único, en lo sucesivo, una dirección, y algunos activos.

      Al realizar la próxima transferencia, el propietario de la cuenta crea y firma una transacción; El hash1 de la transacción anterior se adjunta al siguiente. Esta información se adjunta al activo. El beneficiario puede verificar cada firma digital para garantizar que toda la cadena sea correcta.

      1 Aquí y más adelante, por hash, nos referimos al resultado de una función unidireccional.

      Considere el problema de la incapacidad del destinatario para determinar cuántas veces el activo actual fue gastado por el propietario anterior. Los dos enfoques más comunes para su solución. El primero es trasladar estas inquietudes al administrador central, lo que hace que todo el sistema monetario dependa de él. El segundo es crear una red peer-to-peer, en la que los participantes deban publicar abiertamente las transacciones, así como poder llegar a un acuerdo en un solo orden de su secuencia, lo que implica un bajo ancho de banda de la red y enormes costos computacionales.

      Para eliminar las desventajas anteriores de ambos enfoques, utilizamos una solución híbrida basada en un servidor de marca temporal centralizado que garantiza la corrección y el orden cronológico de las transacciones. La solución es similar a la variante con el representante central autorizado, pero está equipada con un mecanismo para arreglar periódicamente el historial completo de operaciones en el registro público inmutable.

      3. Servidor de marca temporal

      Las reglas del sistema se definen como un conjunto de declaraciones generalmente aceptadas, establecidas dentro de él. Por ejemplo, comisiones de transacción, impuestos, etc.

      Al recibir una transacción, el servidor le agrega a la cola de procesamiento. El procesamiento es el siguiente: primero, el servidor verifica la transacción para verificar la consistencia con el estado actual del sistema. En un resultado exitoso, le asigna los últimos enlaces de activos, llamados entrada y pertenencia a los participantes de la transacción, así como algunos resultados, llamados enlaces de salida y generados de acuerdo con las reglas del sistema. Los enlaces de salida están vinculados a la entrada por medio de una transacción y son los últimos para las siguientes transacciones inmediatas, lo que garantiza el orden cronológico de ejecución. Luego de un procesamiento exitoso, el servidor publica abiertamente la transacción, adjuntando previamente una marca temporal. La marca temporal indica que los datos específicos existían en el momento y, por lo tanto, cayeron en una cadena.

      El problema, por supuesto, es que la preservación de la verdadera cadena por parte del servidor se basa en la confianza. El usuario debe que tener en cuenta que los enlaces anteriores de los activos de otra persona no se han eliminado. Para hacer esto, el servidor arregla periódicamente el estado de la cadena en un registro público inmutable. Así se construye la cadena, donde el siguiente eslabón fortalece a todos los anteriores.

      4. Bloques

      Para simplificar el proceso de asignación de historial de los datos, las transacciones se organizan en bloques que consisten en árboles Merkle de hashes de transacción y un encabezado del bloque. Los árboles se construyen sobre la base de una selección ordenada de transacciones en una cadena durante un período predeterminado. Encabezado del bloque es un par ordenado, que consiste en el hash del encabezado del bloque anterior y la raíz del árbol Merkle actual. Por lo tanto, los bloques se conectan en una cadena ordenada, donde un intento de cambiar la información de un cierto bloque requiere el recálculo de todos los subsiguientes, lo que, a su vez, asegura la suficiencia de corregir sólo el hash del encabezado en lugar de toda la cadena de transacciones.

      El uso de una cadena de bloques facilita no solamente la publicación del historial, sino también la verificación de la existencia de una transacción. Para verificar si la transacción está incluida en el bloque, el usuario no necesita descargar todo el historial de transacciones, lo cual es inaceptable debido al tamaño y la tasa de crecimiento del historial. Puede solicitar una referencia al bloque en el que se encuentra la transacción, y la ruta de Merkle al mismo para asegurarse de que está contenida en el bloque, y todas las posteriores son recibidas y confirmadas por el servidor.

      5. Consagración de marcas temporales

      La consolidación de la historia se entiende como una publicación abierta, como en un periódico o publicaciones de Usenet, de algunos datos que garantizan la singularidad de su origen en un registro inmutable. Bajo las condiciones de 2019, se considera razonable usar sistemas descentralizados de igual a igual con un nivel suficiente de confiabilidad, como Bitcoin y Ethereum, como un registro para asegurar.

      6. Implementación de Nimses

      6.0 Requisitos técnicos

      • Audiencia potencial: 3x109 usuarios
      • Velocidad de confirmación de la transacción: ~1 segundo
      • Rendimiento: hasta 106 transacciones por segundo

      6.1 Cuentas

      En nuestro sistema, solo un tipo de activo corresponde a una cuenta, aunque el sistema en sí es compatible con muchos tipos de activos. La dirección única de la cuenta consta de 20 bytes de datos, donde los últimos 4 bytes indican el tipo de activo.

      La cuenta se describe a continuación: tipo de cuenta, tipo de activo, saldo actual, número de transacciones en la cadena de firmas digitales, un conjunto de claves públicas activas asociadas, verificación de los titulares de cuentas, tipo de emisión y otros datos de respaldo.

      El estado de la cuenta, a su vez, está determinado por la marca temporal, el número de transacción en la cadena de firma digital correspondiente y el saldo final del último enlace, calculado para esta marca temporal o en relación con el anterior, teniendo en cuenta todas las reglas del sistema, por ejemplo, la emisión.

      Las cuentas son entidades separadas en el sistema, que reflejan el estado actual de los activos. Se crean mediante una transacción especial que asocia una dirección única, el estado inicial de un activo y un conjunto de claves públicas. Después de eso, la dirección registrada puede ser operada.

      En este momento hay más de 20 tipos de cuentas en el sistema: de usuarios regulares, impuestos, comerciales y otros.

          Address	= {16 byte} + {asset_id: 4 byte}
      
          Account	= (Address, Asset, Type, Emission,
              {Public Key}, State)
      
          State = (Time Point, Balance, Nonce, ...)
      
          Account Type = {
              COMMON,
              HUMAN,
              GENESIS,
              TAX,
              REMOVED,
              ...
          }

      6.2 Transacciones

      Una transacción típica consiste de tres partes: el encabezado, el cuerpo y los testigos remitentes.

      Transaction = (Header, Body, Witnesses)

      El encabezado de la transacción es una tupla de: versión de protocolo, tipo de transacción y ventana temporal durante la cual la transacción se puede registrar en una cadena.

        Transaction Types = {
            CREATE_ACCOUNT,
            SPEND,
            TAX_SPEND,
            GENESIS_SPEND,
            REG_KEY,
            REVOKE_KEY,
            ...
        }
      
        Transaction Header = (Version, Type, Time Window)

      La dirección de la cuenta y la cantidad del activo recibido o enviado se definen como una referencia al nombramiento.

      Value Reference = (Account Address, Value)

      Un cuerpo de transacción es un par ordenado de conjuntos que contienen referencias a los valores de remitente y destinatario, respectivamente.

      Transaction Body = (From: {Value Reference}, To: {Value Reference})

      Los testigos remitentes son un conjunto ordenado de todos los testigos remitentes. El certificado del remitente es un par ordenado: la firma del remitente y el hash de la clave pública del par que firma. La función hash es SHA3-256 [4] (FIPS-202).

        Witnesses = ({Witness})
      
        Witness	= (Signature, Public Key Hash)

      Una firma digital obtenida al firmar el encabezado y el cuerpo de la transacción con cualquier par de claves del conjunto adjunto a la cuenta del remitente es la firma del remitente. ECDSA [2] (NIST.FIPS.186-4) en la curva SECP256R1 [3] (RFC 5480) se utiliza como un mecanismo de firma digital.

      Signature	= ECDSA(Public Key, Transaction Header + Transaction Body, Private Key)

      Cuando una transacción se registra en una cadena, se complementa con hashes de enlaces de entrada y enlaces de salida. Los enlaces se identifican mediante una función hash de 256 bits. El sistema garantiza su singularidad y se verifica cuando una transacción se registra en una cadena. La singularidad de las transacciones en sí también está garantizada.

      Algunos tipos de transacciones se firman con claves no asociadas con la cuenta, pero con claves de servicio especiales. Por ejemplo, una institución tributaria tiene la capacidad de cancelar ciertos montos de deducciones fiscales de las cuentas de usuarios.

      Estas claves de servicio están autorizadas en el sistema mediante una transacción especial, que se firma con una de las claves raíz. Las claves de servicio se utilizan para proporcionar algunas características necesarias del sistema económico de Nimses. Los retiros de impuestos o penalidades por violar las reglas son ejemplos de estas características. Estas claves de servicio se pueden utilizar en lugar de las de usuario. Sus partes secretas se almacenan en dispositivos especiales conocidos como módulos de seguridad de hardware en redes seguras y no se pueden extraer de allí.

        Key Types = {
            KEY_USER,
            KEY_ROOT,
            KEY_MASTER,
            KEY_IDENTITY,
            KEY_TAX,
            KEY_FAMILYPAYMENT,
            ...
        }

      Las reglas de validación de transacciones están determinadas por su tipo y los tipos de cuentas involucradas.

      6.3 Activos

      Como se mencionó antes, el tipo de activo está determinado por 4 bytes, lo que le permite agregar nuevos tipos a medida que el sistema evoluciona.

      Por el momento, el sistema utiliza dos tipos de activos: nim y dominim.

      6.3.1 Nim

      Nim es el activo básico del sistema económico de Nimses. Actúa como la principal herramienta para interactuar con Nimses y entre los usuarios del sistema.

      El nims surgen del sistema de emisión interno, que es una función del tiempo astronómico. Al momento de registrarse en el sistema, cada usuario crea automáticamente una cuenta2 de él regular, sujeta a la emisión de él. Cada cuenta ordinaria de él se emite por un nim por minuto. No hay otras formas de emitirlos.

      Para determinar el número de NIM emitidos cuando se realizan transacciones, el servidor de marca del tiempo adicionalmente marca las transacciones registradas en la cadena con marcas de tiempo astronómicas y calcula las unidades de salida de la transacción, teniendo en cuenta la emisión de Nims.

      2 Por lo general, se usa aquí como un tipo de cuenta.

      6.3.2 Dominim

      Dominim es un activo concebido como la herramienta principal para capturar y mantener territorios fijos (ver Nimonomía, Temples). Un dominim es equivalente a 525960 Nims (1440 * 365.25). En el momento del registro, el usuario también crea automáticamente una cuenta de dominims para sí mismo.

      El mecanismo de emisión de dominims es el siguiente. Como se sabe por Nimonomía, Nimses tiene sus propias cuentas especiales, que se reponen con los impuestos de los usuarios, después de lo cual parte de estas reposiciones se distribuyen a las cuentas de ahorro. También hay una cuenta de ahorro, que está destinada a la cuestión de los dominims. La transición de nims a dominims se implementa utilizando un servicio separado y un tipo especial de transacción. El servicio verifica periódicamente el estado de la cuenta de ahorros, y tan pronto como haya un número suficiente de NIM en la cuenta, el servicio envía la transacción al sistema. La transacción deduce el número requerido de Nims de la cuenta de ahorros y genera un dominim en la cuenta de emisión. Los dominims obtenidos de esta manera forman un banco de dominims en Nimses.

      También se implementó un mecanismo para la emisión forzada de dominim a petición del usuario. El usuario envía una solicitud de transacción al sistema con una solicitud para el dominim. En esta transacción, el costo del depósito se cancela de la cuenta, que irá a la cuenta de ahorros, y el cargo por impuesto de conversión que se pagará a la tesorería de Nimses. Un servicio especial supervisa transacciones de este tipo y, después de completarse con éxito, envía dominims de usuario desde el banco de Nimses.

      No hay otras formas de emitir dominims.

      La compra de dominims por dinero fiduciario también se implementó mediante un servicio de monitoreo que demuestra los pagos en efectivo y, luego de realizarlos con éxito, envía los dominims de usuario desde el banco. En este escenario, no se emite ningún dominim, por lo que la compra se puede cancelar si no hay un dominim en el banco.

      6.4 Bloques

      Los bloques combinan transacciones en conjuntos ordenados y sirven como herramientas que simplifican la provisión de apertura, inmutabilidad y orden cronológico.

      Un bloque consiste en un conjunto de transacciones y un encabezado de bloque. El encabezado del bloque incluye el hash del encabezado del bloque anterior y las raíces de dos árboles Merkle. La numeración de la altura de los bloques comienza desde cero. El primer bloque con una altura igual a cero no tiene uno anterior, y en lugar del hash del encabezado del bloque anterior, se utiliza el hash de la palabra "nimses".

        Block Header = (Version, Height, CommitAt, Gen, Prev Block Hash, Transaction Root, Receipt Root, Witness)
      
        SHA3-256(nimses)=“b6d1672a4ef816d08bfb6c491c946b4eb4f991e6783a0b337b89b1ac94a2b472”

      En Nimses Blockchain, los bloques no están limitados en tamaño. Cada unidad es responsable por un cierto período del tiempo, ahora son 10 minutos. Todas las transacciones que ocurrieron durante el período de tiempo, caerán en el bloque apropiado.

      El bloque terminado se descarga en el almacenamiento distribuido compartido, y la posibilidad de obtener evidencia simplificada de la inclusión de la transacción en el bloque se proporciona inmediatamente después de que se registra.

      El cálculo del árbol Merkle para los identificadores de transacciones es similar al algoritmo descrito en la sección 2.1.2 de RFC6962[5] Se utiliza la función de hash SHA3-256[4] (FIPS-202). En los niveles con un número impar de vértices, el último vértice se duplica.

      6.4.1 Consolidación de la história

      Después de la generación y el registro, los hashes de bloque se escriben en un registro externo de confianza. Además, se pueden agregar bloques al sistema con firmas de validadores adicionales que confirman la validez de la cadena y las transformaciones.

      La red de Bitcoin cumple con los requisitos de publicidad e inmunidad, por lo que hemos optado por consolidar el historial de transacciones de Nimses. A partir de mayo de 2019, un costo de ataque del 51% es de más de nueve mil millones de dólares. La asignación se produce al realizar una transacción con la salida OP_RETURN[6], en la que se registra el hash del encabezado del bloque.

      Nimses publica abiertamente los encabezados de cada bloque en su sitio web y asigna periódicamente encabezados de hash de la manera descrita anteriormente. Tan pronto como la transacción que asegura la altura de bloque h, recibió un número seguro de confirmaciones en la red de Bitcoin, es recomendable considerar todos los bloques con altura h como inmutables.

      6.5 Escala horizontal (consenso interno)

      En las redes peer-to-peer, los participantes deben acordar una única versión del historial de transacciones para protegerse contra el doble gasto, utilizando algoritmos como "prueba del trabajo realizado", "prueba de autoridad", "prueba del tamaño de la acción" y otros similares que aseguran la singularidad de la versión de la historia. Los sistemas centralizados que carecen de este inconveniente pueden utilizar métodos más eficientes para negociar el orden de las transacciones.

      La ausencia de la necesidad de una replicación completa de todo el historial entre un gran número de participantes para la toma de decisiones permite el procesamiento paralelo de transacciones y garantizar un alto rendimiento.

      El servidor de marca de tiempo es una red distribuida cerrada que consta de nodos independientes que utilizan el almacenamiento distribuido globalmente de la clase NewSQL. Este dispositivo proporciona una escalabilidad lineal del espacio y el rendimiento del procesamiento de transacciones. El consenso entre los nodos internos se logra a través del algoritmo de Paxos.

      En la implementación actual, el procesamiento de transacciones tarda aproximadamente un segundo, y el rendimiento es directamente proporcional a la velocidad a la que se alcanza un consenso interno.

      7. Conclusión

      El sistema híbrido presentado cumple con las especificaciones especificadas. La credibilidad del lado del usuario se debe a la inaceptable labor de los cambios en los datos fijados en el registro externo. Un modelo de transacción especial que permite el procesamiento paralelo, un tamaño de bloque dinámico, todo esto le permite alcanzar el ancho de banda requerido para un sistema de intercambio de activos planetarios.

      8. Referencias