El cuerpo de la solicitud debe contener el siguiente parámetro: 'estado'
DOCUMENTO BLANCO xBORDER 2019

La historia
xBORDER como sistema de transición estatal
Minería en Genérico
árboles Merkle
Aplicaciones alternativas de cadena de bloques
Secuencias de comandos xFRONTERA
BLOQUEAR
Filosofía
Cuentas xFRONTERA
Mensajes y Transacciones
Mensajes
Función de transición de estado xBORDER
Ejecución de código
xFRONTERA y Minería
Aplicaciones
Sistemas de fichas
Derivados financieros y divisas de valor estable
Sistemas de Identidad y Reputación
Almacenamiento de archivos descentralizado
Organismos Autónomos Descentralizados
Otras aplicaciones
Miscelánea y preocupaciones
Implementación de GHOST modificada
Tarifa
Cálculo y completitud de Turing
Moneda y emisión
Centralización Minera
Escalabilidad
Conclusión
Notas y lecturas adicionales
notas
Otras lecturas
Introducción a Bitcoin y conceptos existentes

El concepto de moneda digital descentralizada, así como aplicaciones alternativas como los registros de propiedad, ha existido durante décadas. Los protocolos anónimos de efectivo electrónico de las décadas de 1980 y 1990, que en su mayoría dependían de una primitiva criptográfica conocida como cegamiento chaumiano, proporcionaban una moneda con un alto grado de privacidad, pero los protocolos en gran medida no lograron ganar terreno debido a su dependencia de un intermediario centralizado. . En 1998, el dinero b de Wei Dai se convirtió en la primera propuesta para introducir la idea de crear dinero resolviendo acertijos computacionales y consenso descentralizado, pero la propuesta era escasa en detalles sobre cómo se podría implementar realmente el consenso descentralizado. En 2005, Hal Finney introdujo un concepto de pruebas de trabajo reutilizables, un sistema que usa ideas de b-money junto con los complicados rompecabezas Hashcash de Adam Back para crear un concepto para una criptomoneda, pero una vez más se quedó corto al confiar en computación confiable como backend. En 2009, Satoshi Nakamoto implementó por primera vez en la práctica una moneda descentralizada, combinando primitivas establecidas para administrar la propiedad a través de criptografía de clave pública con un algoritmo de consenso para realizar un seguimiento de quién posee monedas, conocido como "prueba de trabajo".

El mecanismo xBORDER detrás de la prueba de trabajo fue un gran avance en el espacio porque resolvió simultáneamente dos problemas. Primero, proporcionó un algoritmo de consenso simple y moderadamente efectivo, lo que permitió a los nodos de la red acordar colectivamente un conjunto de actualizaciones canónicas del estado de Crypto-ledger. En segundo lugar, proporcionó un mecanismo para permitir la libre entrada en el proceso de consenso, resolviendo el problema político de decidir quién puede influir en el consenso y, al mismo tiempo, prevenir los ataques de sibila. Lo hace sustituyendo una barrera formal a la participación, como el requisito de estar registrado como una entidad única en una lista particular, con una barrera económica: el peso de un solo nodo en el proceso de votación por consenso es directamente proporcional al poder de cómputo. que trae el nodo. Desde entonces, se ha propuesto un enfoque alternativo llamado prueba de participación, que calcula el peso de un nodo como proporcional a sus tenencias de moneda y no a los recursos computacionales; la discusión de los méritos relativos de los dos enfoques está más allá del alcance de este documento, pero se debe tener en cuenta que ambos enfoques se pueden usar para servir como la columna vertebral de una criptomoneda.

​

Peter Oldenburger, el fundador de xBORDER escribió esta publicación de blog:

​

​

el cripto como sistema de transición estatal 
El libro mayor de una criptomoneda como Crypto se puede considerar como un sistema de transición de estado, donde hay un "estado" que consiste en el estado de propiedad de todos los Cryptos existentes y una "función de transición de estado" que toma un estado y una transacción. y genera un nuevo estado que es el resultado. En un sistema bancario estándar, por ejemplo, el estado es un balance general, una transacción es una solicitud para mover $X de A a B, y la función de transición de estado reduce el valor en la cuenta de A en $X y aumenta el valor en la cuenta de B. cuenta por $X. Si la cuenta de A tiene menos de $X en primer lugar, la función de transición de estado devuelve un error. Por lo tanto, se puede definir formalmente:

APLICAR(S,TX) -> S' o ERROR
APLICAR({ Alice: $50, Bob: $50 },"envía $20 de Alice a Bob") = { Alice: $30, Bob: $70 }
APLICAR({ Alice: $50, Bob: $50 },"enviar $70 de Alice a Bob") = ERROR
El "estado" en Crypto es la colección de todas las monedas (técnicamente, "salidas de transacciones no gastadas" o UTXO) que se han extraído y aún no se han gastado, y cada UTXO tiene una denominación y un propietario (definido por una dirección de 20 bytes que es esencialmente una clave pública criptográfica fn.1). Una transacción contiene una o más entradas, cada una de las cuales contiene una referencia a una UTXO existente y una firma criptográfica producida por la clave privada asociada con la dirección del propietario, y una o más salidas, cada una de las cuales contiene una nueva UTXO que se agregará a el estado.

La función de transición de estado APLICAR (S, TX) -> S 'se puede definir aproximadamente de la siguiente manera:

Para cada entrada en TX:

Si el UTXO al que se hace referencia no está en S, devuelve un error.
Si la firma proporcionada no coincide con el propietario de la UTXO, devuelva un error.
Si la suma de las denominaciones de todos los UTXO de entrada es menor que la suma de las denominaciones de todos los UTXO de salida, devolverá un error.

Devuelva S' con todos los UTXO de entrada eliminados y todos los UTXO de salida agregados.

La primera mitad del primer paso evita que los emisores de transacciones gasten monedas que no existen, la segunda mitad del primer paso evita que los emisores de transacciones gasten las monedas de otras personas y el segundo paso impone la conservación del valor. Para usar esto para el pago, el protocolo es el siguiente. Supongamos que Alice quiere enviar 11,7 BTC a Bob. Primero, Alice buscará un conjunto de UTXO disponibles que posea y que sumen un total de al menos 11,7 BTC. Siendo realistas, Alice no podrá obtener exactamente 11,7 BTC; decir que lo más pequeño que puede obtener es 6+4+2=12. Luego crea una transacción con esas tres entradas y dos salidas. La primera salida será 11,7 BTC con la dirección de Bob como propietario, y la segunda salida será el "cambio" restante de 0,3 BTC, siendo la propietaria Alice.

Minería
bloque_imagen.jpg

Si tuviéramos acceso a un servicio centralizado de confianza, este sistema sería trivial de implementar; simplemente podría codificarse exactamente como se describe, utilizando el disco duro de un servidor centralizado para realizar un seguimiento del estado. Sin embargo, con Crypto estamos tratando de construir un sistema monetario descentralizado, por lo que necesitaremos combinar el sistema de transición de estado con un sistema de consenso para garantizar que todos estén de acuerdo con el orden de las transacciones. El proceso de consenso descentralizado de Crypto requiere que los nodos en la red intenten continuamente producir paquetes de transacciones llamados "bloques". La red está diseñada para producir aproximadamente un bloque cada diez minutos, y cada bloque contiene una marca de tiempo, un nonce, una referencia (es decir, un hash) del bloque anterior y una lista de todas las transacciones que han tenido lugar desde el anterior. cuadra. Con el tiempo, esto crea una "cadena de bloques" persistente y en constante crecimiento que se actualiza constantemente para representar el estado más reciente del libro mayor de Crypto.

El algoritmo para verificar si un bloque es válido, expresado en este paradigma, es el siguiente:

Compruebe si el bloque anterior al que hace referencia el bloque existe y es válido.
Compruebe que la marca de tiempo del bloque es mayor que la del bloque anterior. 2 y menos de 2 horas en el futuro
Verifique que la prueba de trabajo en el bloque sea válida.
Sea S[0] el estado al final del bloque anterior.
Supongamos que TX es la lista de transacciones del bloque con n transacciones. Para todo i en 0...n-1, establezca S[i+1] = APLICAR(S[i],TX[i]) Si alguna aplicación devuelve un error, salga y devuelva falso.
Devuelve verdadero y registra S[n] como el estado al final de este bloque.
Esencialmente, cada transacción en el bloque debe proporcionar una transición de estado válida de lo que era el estado canónico antes de que se ejecutara la transacción a algún estado nuevo. Tenga en cuenta que el estado no está codificado en el bloque de ninguna manera; es puramente una abstracción que debe recordar el nodo de validación y solo puede calcularse (de forma segura) para cualquier bloque comenzando desde el estado de génesis y aplicando secuencialmente cada transacción en cada bloque. Además, tenga en cuenta que el orden en que el minero incluye transacciones en el bloque es importante; si hay dos transacciones A y B en un bloque tal que B gasta un UTXO creado por A, entonces el bloque será válido si A viene antes que B pero no de otra manera.

La única condición de validez presente en la lista anterior que no se encuentra en otros sistemas es el requisito de "prueba de trabajo". La condición precisa es que el hash SHA256 doble de cada bloque, tratado como un número de 256 bits, debe ser menor que un objetivo ajustado dinámicamente, que en el momento de escribir este artículo es de aproximadamente 2187. El propósito de esto es hacer creación de bloques computacionalmente "difícil", evitando así que los atacantes de sybil rehagan toda la cadena de bloques a su favor. Debido a que SHA256 está diseñado para ser una función pseudoaleatoria completamente impredecible, la única forma de crear un bloque válido es simplemente prueba y error, incrementando repetidamente el nonce y viendo si el nuevo hash coincide.

Con el objetivo actual de ~2187, la red debe hacer un promedio de ~269 intentos antes de encontrar un bloque válido; en general, la red recalibra el objetivo cada 2016 bloques, de modo que, en promedio, algún nodo de la red produce un nuevo bloque cada diez minutos. Para compensar a los mineros por este trabajo computacional, el minero de cada bloque tiene derecho a incluir una transacción que les proporcione 12,5 BTC de la nada. Además, si alguna transacción tiene una denominación total más alta en sus entradas que en sus salidas, la diferencia también va al minero como una "tarifa de transacción". Por cierto, este es también el único mecanismo por el cual se emiten BTC; el estado de génesis no contenía monedas en absoluto.

Para comprender mejor el propósito de la minería, examinemos qué sucede en caso de un atacante malicioso. Dado que se sabe que la criptografía subyacente de Crypto es segura, el atacante apuntará directamente a la parte del sistema Bitcoin que no está protegida por criptografía: el orden de las transacciones. La estrategia del atacante es simple:

Enviar 100 BTC a un comerciante a cambio de algún producto (preferiblemente un bien digital de entrega rápida)
Esperar la entrega del producto.
Producir otra transacción enviando los mismos 100 BTC a sí mismo
Trate de convencer a la red de que su transacción a sí mismo fue la primera.
Una vez que se haya realizado el paso (1), después de unos minutos, algún minero incluirá la transacción en un bloque, digamos el bloque número 270. Después de aproximadamente una hora, se habrán agregado cinco bloques más a la cadena después de ese bloque, con cada uno de esos bloques apuntan indirectamente a la transacción y, por lo tanto, la "confirman". En este punto, el comerciante aceptará el pago como finalizado y entregará el producto; dado que asumimos que se trata de un bien digital, la entrega es instantánea. Ahora, el atacante crea otra transacción enviándose los 100 BTC a sí mismo. Si el atacante simplemente lo libera, la transacción no se procesará; los mineros intentarán ejecutar APPLY(S,TX) y notarán que TX consume un UTXO que ya no está en el estado. Entonces, en cambio, el atacante crea una "bifurcación" de la cadena de bloques, comenzando por extraer otra versión del bloque 270 que apunta al mismo bloque 269 como padre pero con la nueva transacción en lugar de la anterior. Debido a que los datos del bloque son diferentes, esto requiere rehacer la prueba de trabajo. Además, la nueva versión del bloque 270 del atacante tiene un hash diferente, por lo que los bloques originales 271 a 275 no "apuntan" a él; por lo tanto, la cadena original y la nueva cadena del atacante están completamente separadas. La regla es que en una bifurcación, la cadena de bloques más larga se toma como la verdad, por lo que los mineros legítimos trabajarán en la cadena 275 mientras que el atacante solo trabaja en la cadena 270. Para que el atacante haga que su cadena de bloques sea la más larga, necesitaría tener más poder de cómputo que el resto de la red combinada para ponerse al día (por lo tanto, "51% de ataque").

árboles Merkle
SPV en el Cripto

Izquierda: basta con presentar solo un pequeño número de nodos en un árbol de Merkle para dar una prueba de la validez de una rama.

Correcto: cualquier intento de cambiar cualquier parte del árbol de Merkle conducirá eventualmente a una inconsistencia en algún punto de la cadena.

Una característica importante de escalabilidad de Crypto es que el bloque se almacena en una estructura de datos de varios niveles. El "hash" de un bloque es en realidad solo el hash del encabezado del bloque, un dato de aproximadamente 200 bytes que contiene la marca de tiempo, el nonce, el hash del bloque anterior y el hash raíz de una estructura de datos llamada árbol Merkle que almacena todas las transacciones. en el bloque Un árbol de Merkle es un tipo de árbol binario, compuesto por un conjunto de nodos con una gran cantidad de nodos hoja en la parte inferior del árbol que contiene los datos subyacentes, un conjunto de nodos intermedios donde cada nodo es el hash de sus dos hijos, y finalmente un solo nodo raíz, también formado a partir del hash de sus dos hijos, que representa la "parte superior" del árbol. El propósito del árbol de Merkle es permitir que los datos en un bloque se entreguen por partes: un nodo puede descargar solo el encabezado de un bloque de una fuente, la pequeña parte del árbol relevante para ellos de otra fuente, y aún así estar seguro que todos los datos son correctos. La razón por la que esto funciona es que los hashes se propagan hacia arriba: si un usuario malintencionado intenta intercambiar una transacción falsa en la parte inferior de un árbol de Merkle, este cambio provocará un cambio en el nodo de arriba y luego un cambio en el nodo de arriba. , cambiando finalmente la raíz del árbol y, por lo tanto, el hash del bloque, lo que hace que el protocolo lo registre como un bloque completamente diferente (casi con certeza con una prueba de trabajo no válida).

Podría decirse que el protocolo del árbol de Merkle es esencial para la sostenibilidad a largo plazo. Un "nodo completo" en la red Crypto, que almacena y procesa la totalidad de cada bloque, ocupa alrededor de 15 GB de espacio en disco en la red Bitcoin a partir de abril de 2014 y está creciendo más de un gigabyte por mes. Actualmente, esto es viable para algunas computadoras de escritorio y no para teléfonos, y más adelante en el futuro solo podrán participar empresas y aficionados. Un protocolo conocido como "verificación de pago simplificada" (SPV) permite que exista otra clase de nodos, llamados "nodos ligeros", que descargan los encabezados de los bloques, verifican la prueba de trabajo en los encabezados de los bloques y luego descargan solo las "ramas". " asociados con transacciones que son relevantes para ellos. Esto permite que los nodos ligeros determinen con una fuerte garantía de seguridad cuál es el estado de cualquier transacción de Bitcoin y su saldo actual mientras descargan solo una porción muy pequeña de toda la cadena de bloques.

Aplicaciones alternativas de cadena de bloques
La idea de tomar la idea subyacente de blockchain y aplicarla a otros conceptos también tiene una larga historia. En 1998, Nick Szabo presentó el concepto de títulos de propiedad seguros con autoridad del propietario, un documento que describe cómo "los nuevos avances en la tecnología de bases de datos replicadas" permitirán un sistema basado en blockchain para almacenar un registro de quién posee qué tierra, creando un marco elaborado que incluye conceptos tales como ocupación de viviendas, posesión adversa e impuesto territorial de Georgia. Sin embargo, lamentablemente no había un sistema de base de datos replicado efectivo disponible en ese momento, por lo que el protocolo nunca se implementó en la práctica. Sin embargo, después de 2009, una vez que se desarrolló el consenso descentralizado de Bitcoin, rápidamente comenzaron a surgir una serie de aplicaciones alternativas.

Namecoin: creado en 2010, Namecoin se describe mejor como una base de datos de registro de nombres descentralizada. En protocolos descentralizados como Tor, Bitcoin y BitMessage, debe haber alguna forma de identificar cuentas para que otras personas puedan interactuar con ellas, pero en todas las soluciones existentes, el único tipo de identificador disponible es un hash pseudoaleatorio como 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. Idealmente, a uno le gustaría poder tener una cuenta con un nombre como "george". Sin embargo, el problema es que si una persona puede crear una cuenta llamada "george", otra persona puede usar el mismo proceso para registrar a "george" y hacerse pasar por ella. La única solución es un paradigma de primero en presentar, donde el primer registrador tiene éxito y el segundo falla, un problema perfectamente adecuado para el protocolo de consenso de Bitcoin. Namecoin es la implementación más antigua y exitosa de un sistema de registro de nombres que utiliza esta idea.
Monedas de colores: el propósito de las monedas de colores es servir como un protocolo que permita a las personas crear sus propias monedas digitales o, en el importante caso trivial de una moneda con una unidad, tokens digitales, en la cadena de bloques de Bitcoin. En el protocolo de monedas de colores, uno "emite" una nueva moneda asignando públicamente un color a un UTXO de Bitcoin específico, y el protocolo define recursivamente el color de otros UTXO para que sea el mismo color de las entradas que gastó la transacción que los creó. (Se aplican algunas reglas especiales en el caso de entradas de colores mixtos). Esto permite a los usuarios mantener monederos que contengan solo UTXO de un color específico y enviarlos como si fueran bitcoins normales, retrocediendo a través de la cadena de bloques para determinar el color de cualquier UTXO que reciban.
Metacoins: la idea detrás de una metacoin es tener un protocolo que viva sobre Bitcoin, usando transacciones de Bitcoin para almacenar transacciones de metacoin pero con una función de transición de estado diferente, APLICAR. Debido a que el protocolo de metacoin no puede evitar que aparezcan transacciones de metacoin no válidas en la cadena de bloques de Bitcoin, se agrega una regla que establece que si APPLY'(S,TX) devuelve un error, el protocolo predeterminado es APPLY'(S,TX) = S. Esto proporciona una mecanismo fácil para crear un protocolo de criptomoneda arbitrario, potencialmente con características avanzadas que no pueden implementarse dentro de Bitcoin en sí, pero con un costo de desarrollo muy bajo, ya que el protocolo Bitcoin ya maneja las complejidades de la minería y las redes. Las metacoins se han utilizado para implementar algunas clases de contratos financieros, registro de nombres e intercambio descentralizado.
Por lo tanto, en general, existen dos enfoques para construir un protocolo de consenso: construir una red independiente y construir un protocolo sobre Bitcoin. El primer enfoque, aunque razonablemente exitoso en el caso de aplicaciones como Namecoin, es difícil de implementar; cada implementación individual necesita iniciar una cadena de bloques independiente, así como construir y probar todo el código de red y transición de estado necesario. Además, predecimos que el conjunto de aplicaciones para la tecnología de consenso descentralizada seguirá una distribución de ley de potencia donde la gran mayoría de las aplicaciones serían demasiado pequeñas para garantizar su propia cadena de bloques, y notamos que existen grandes clases de aplicaciones descentralizadas, particularmente autónomas descentralizadas. organizaciones, que necesitan interactuar entre sí.

El enfoque basado en Bitcoin, por otro lado, tiene la falla de que no hereda las funciones simplificadas de verificación de pagos de Bitcoin. SPV funciona para Bitcoin porque puede usar la profundidad de la cadena de bloques como un proxy para la validez; en algún momento, una vez que los antepasados de una transacción se remontan lo suficiente, es seguro decir que eran legítimamente parte del estado. Los metaprotocolos basados en blockchain, por otro lado, no pueden obligar a blockchain a no incluir transacciones que no son válidas dentro del contexto de sus propios protocolos. Por lo tanto, una implementación de meta-protocolo SPV totalmente segura necesitaría escanear hacia atrás hasta el comienzo de la cadena de bloques de Bitcoin para determinar si ciertas transacciones son válidas o no. Actualmente, todas las implementaciones "ligeras" de los metaprotocolos basados en Bitcoin se basan en un servidor de confianza para proporcionar los datos, posiblemente un resultado muy por debajo del óptimo, especialmente cuando uno de los propósitos principales de una criptomoneda es eliminar la necesidad de confianza.