Cosmos: сеть распределенных реестров

Introducción

El éxito combinado del ecosistema de código abierto, El intercambio de archivos descentralizado y las criptomonedas públicas han inspiró la comprensión de que los protocolos descentralizados de Internet puede utilizarse para mejorar radicalmente la infraestructura socioeconómica. Hemos visto aplicaciones especializadas blockchain como Bitcoin [1] (una criptomoneda), Zerocash [2] (una criptomoneda para la privacidad), y plataformas smart contract generalizadas como Ethereum [3], con innumerables aplicaciones distribuidas para Etherium Virtual Máquina (EVM) como Augur (un mercado de predicción) y TheDAO [4] (un club de inversiones). Sin embargo, hasta la fecha, estos blockchain han sufrido una serie de de desventajas, entre ellas su grave ineficiencia energética, su mala o mala calidad desempeño limitado y mecanismos de gobernanza inmaduros. Propuestas para escalar el rendimiento de transacciones de Bitcoin, como Testigo segregado [5] y BitcoinNG [6], son escalamiento vertical Soluciones que siguen limitadas por la capacidad de un único espacio físico. máquina, con el fin de garantizar la propiedad de completa auditabilidad. Lightning Network [7] puede ayudar a escalar la transacción Bitcoin

volumen dejando algunas transacciones fuera del libro mayor por completo, y es muy adecuado para micropagos y preservación de la privacidad carriles de pago, pero puede no ser adecuado para más generalizados necesidades de escalamiento. Una solución ideal es aquella que permite que múltiples blockchains paralelos interoperar conservando sus propiedades de seguridad. esto tiene resultó difícil, si no imposible, con proof-of-work. Fusionado la minería, por ejemplo, permite que el trabajo realizado para asegurar una matriz cadena para ser reutilizada en una cadena secundaria, pero las transacciones aún deben ser validado, en orden, por cada nodo, y un blockchain extraído por fusión es vulnerable a un ataque si la mayoría del hashing poder en el El padre no está fusionando activamente al niño. Una reseña académica de arquitecturas de red alternativas blockchain se proporciona para contexto adicional y proporcionamos resúmenes de otras propuestas y sus inconvenientes en el Trabajo Relacionado. Aquí presentamos Cosmos, una novedosa arquitectura de red blockchain que aborda todos estos problemas. Cosmos es una red de muchos blockchains independientes, llamados zonas. Las zonas están alimentadas por Tendermint Core [8], que proporciona un alto rendimiento, motor de consenso consistente y seguro similar a PBFT, donde la estricta responsabilidad de forka garantiza el control del comportamiento de malware actores. El algoritmo de consenso BFT de Tendermint Core es muy adecuado para escalar proof-of-stake blockchains públicos. La primera zona en Cosmos se llama Cosmos Hub. El Cosmos Hub es una criptomoneda proof-of-stake multiactivo con un simple mecanismo de gobernanza que permite a la red adaptarse y actualizar. Además, el concentrador Cosmos se puede ampliar mediante conectando otras zonas. El hub y las zonas de la red Cosmos se comunican con entre sí a través de un protocolo de comunicación inter-blockchain (IBC), una especie de UDP o TCP virtual para blockchains. Las fichas pueden ser transferido de una zona a otra de forma segura y rápidasin necesidad de liquidez cambiaria entre zonas. En cambio, todas las transferencias entre zonas token pasan por el concentrador Cosmos, que realiza un seguimiento de la cantidad total de tokens en poder de cada zona. el hub aísla cada zona del fallo de otras zonas. porque cualquiera puede conectar una nueva zona al Cosmos Hub, las zonas lo permiten para compatibilidad futura con las nuevas innovaciones blockchain. En esta sección describimos el protocolo de consenso de Tendermint. y la interfaz utilizada para crear aplicaciones con él. Para más detalles, consulte el apéndice. En los algoritmos bizantinos clásicos tolerantes a fallos (BFT), cada nodo tiene el mismo peso. En Tendermint, los nodos tienen un valor no negativo. cantidad de poder de voto y nodos que tienen voto positivo potencia se llaman validators. Los validadores participan en el protocolo de consenso mediante la difusión de firmas criptográficas, o votos, para acordar el siguiente bloque. Los poderes de voto de los validadores se determinan en la génesis o se cambiado de manera determinista por el blockchain, dependiendo del aplicación. Por ejemplo, en una aplicación proof-of-stake como el Centro Cosmos, el poder de voto puede ser determinado por el monto de staking tokens garantizados como garantía. NOTA: Fracciones como ⅔ y ⅓ se refieren a fracciones del total de la votación. potencia, nunca el número total de validators, a menos que todos los validators tienen igual peso. >⅔ significa “más de ⅔”, ≥⅓ significa “al menos ⅓”. Tendermint es un protocolo de consenso BFT parcialmente sincrónico derivado del algoritmo de consenso DLS [20]. La menta tierna es

destaca por su simplicidad, rendimiento y responsabilidad de bifurcación. El protocolo requiere un conjunto conocido yxed de validators, donde cada validator se identifica por su clave pública. Los validadores intentan llegar a un consenso sobre un bloque a la vez, donde un bloque es una lista de transacciones. La votación por el consenso sobre un bloque se lleva a cabo en rondas. Cada ronda tiene un líder de ronda, o proponente, que propone un bloque. Los validators luego votan, por etapas, sobre si aceptar el bloque propuesto o pasar a la siguiente ronda. el El proponente de una ronda se elige de forma determinista entre los ordenados. lista de validators, en proporción a su poder de voto. Los detalles completos del protocolo se describen aquí. La seguridad de Tendermint se deriva de su uso de bizantino óptimo Tolerancia a fallos mediante votación supermayoría (>⅔) y bloqueo. mecanismo. Juntos, aseguran que: ≥⅓ del poder de voto debe ser bizantino para causar una violación de seguridad, donde se comprometen más de dos valores. si algún conjunto de validator alguna vez logra violar la seguridad, o incluso Si intenta hacerlo, podrá identificarlo mediante el protocolo. esto Incluye tanto la votación de los bloques conflictivos como la retransmisión. Votos injustificados. A pesar de sus sólidas garantías, Tendermint ofrece servicios excepcionales. rendimiento. En benchmarks de 64 nodos distribuidos en 7 centros de datos en 5 continentes, en instancias de nube de productos básicos, El consenso de Tendermint puede procesar miles de transacciones por segundo, con latencias de confirmación del orden de uno o dos segundos. En particular, el desempeño de más de mil transacciones por segundo se mantiene incluso en duras condiciones adversas, con validators fallan o transmiten votos elaborados con fines malintencionados. Ver Consulte la siguiente figura para obtener más detalles.

Un beneficio importante del algoritmo de consenso de Tendermint es la simplificación. seguridad ligera para el cliente, lo que lo convierte en un candidato ideal para dispositivos móviles y Casos de uso de Internet de las cosas. Mientras que un cliente ligero Bitcoin debe sincronizarse cadenas de encabezados de bloque y encuentre el que tenga la mayor prueba de funcionan, los clientes ligeros de Tendermint sólo necesitan mantenerse al día con los cambios al conjunto validator y luego verifique >⅔ PreCommits en el último bloque para determinar el último estado. Las pruebas de cliente ligeras y sucintas también permiten inter-blockchain comunicación. Tendermint tiene medidas de protección para prevenir ciertos ataques notables, como gastos dobles de largo alcance sin nada en juego y censura. Estos se analizan con más detalle en el apéndice.El algoritmo de consenso Tendermint se implementa en un programa llamado Tendermint Core. Tendermint Core es un “motor de consenso” independiente de la aplicación que puede convertir cualquier aplicación determinista de caja negra en una replicación distribuida blockchain. Tendermint Core se conecta a blockchain aplicaciones a través de la interfaz Blockchain de aplicaciones (ABCI) [17]. Por lo tanto, ABCI permite programar aplicaciones blockchain en cualquier lenguaje, no sólo el lenguaje de programación que el consenso motor está escrito. Además, ABCI hace posible fácilmente cambie la capa de consenso de cualquier pila blockchain existente. Hacemos una analogía con la conocida criptomoneda Bitcoin. Bitcoin es una criptomoneda blockchain donde cada nodo mantiene una base de datos de resultados de transacciones no gastadas (UTXO) totalmente auditada. si uno quería crear un sistema similar a Bitcoin encima de ABCI, Tendermint Core sería responsable de Compartir bloques y transacciones entre nodos Establecer un orden canónico/inmutable de transacciones (el blockchain) Mientras tanto, la aplicación ABCI sería responsable de Mantenimiento de la base de datos UTXO Validar firmas criptográficas de transacciones. Evitar que las transacciones gasten fondos inexistentes Permitir a los clientes consultar la base de datos UTXO Tendermint es capaz de descomponer el diseño blockchain mediante ofreciendo una API muy simple entre el proceso de solicitud y proceso de consenso.

Cosmos Arquitectura

Cosmos es una red de blockchain paralelos independientes que están cada uno impulsado por algoritmos de consenso clásicos BFT como Menta tierna 1. El primer blockchain en esta red será el Cosmos Hub. el Cosmos El concentrador se conecta a muchos otros blockchains (o zonas) a través de un Nuevo protocolo de comunicación inter-blockchain. El centro Cosmos rastrea numerosos tipos token y mantiene un registro del total número de tokens en cada zona conectada. Las fichas pueden ser transferido de una zona a otra de forma segura y rápida sin necesidad de un intercambio líquido entre zonas, porque todos Las transferencias de monedas entre zonas pasan por el centro Cosmos. Esta arquitectura resuelve muchos problemas que el espacio blockchain enfrenta hoy en día, como la interoperabilidad de aplicaciones, la escalabilidad y capacidad de actualización perfecta. Por ejemplo, zonas derivadas de Bitcoind, Go-Ethereum, CryptoNote, ZCash o cualquier sistema blockchain pueden debe conectarse al concentrador Cosmos. Estas zonas permiten que Cosmos escalar infinitamente para satisfacer la demanda de transacciones globales. Las zonas también son un gran yt para un intercambio distribuido, que será compatible como bueno. Cosmos no es solo un libro mayor distribuido, y el Cosmos Hub no es un jardín amurallado ni el centro de su universo. somos Diseño de un protocolo para una red abierta de libros de contabilidad distribuidos. que puede servir como una nueva base para futuros sistemas financieros, basado en principios de criptografía, economía sólida, consenso teoría, transparencia y rendición de cuentas. El Cosmos Hub es el primer blockchain público en Cosmos Red, impulsada por el algoritmo de consenso BFT de Tendermint. el El proyecto de código abierto Tendermint nació en 2014 para abordar la velocidad, escalabilidad y problemas ambientales del algoritmo de consenso de prueba de trabajo de Bitcoin. Utilizando y mejorando productos probados

BFT algoritmos desarrollados en el MIT en 1988 [20], el Tendermint El equipo fue el primero en demostrar conceptualmente un proof-of-stake criptomoneda que aborda el problema de nada en juego sufrido por las criptomonedas proof-of-stake de primera generación, como como NXT y BitShares1.0. Hoy en día, prácticamente todas las billeteras móviles Bitcoin utilizan servidores confiables para proporcionarles verificación de transacciones. Esto se debe a que la prueba de trabajo requiere esperar muchas confirmaciones antes de La transacción puede considerarse irreversiblemente comprometida. Los ataques de doble gasto ya se han demostrado en servicios como CoinBase. A diferencia de otros sistemas de consenso blockchain, Tendermint ofrece Verificación de pagos de clientes móviles instantánea y demostrablemente segura. Dado que Tendermint está diseñado para no bifurcarse nunca, el móvil Las billeteras pueden recibir confirmación instantánea de la transacción, lo que hace que Los pagos prácticos y sin confianza son una realidad en los teléfonos inteligentes. esto tiene ramificaciones significativas para las aplicaciones de Internet de las cosas como bueno. Los validadores en Cosmos tienen una función similar a la de los mineros Bitcoin, pero en su lugar, utilice firmas criptográficas para votar. Los validadores son máquinas seguras y dedicadas que son responsables de cometer bloques. Los que no son validators pueden delegar sus staking tokens (llamados “átomos”) a cualquier validator para ganar una parte de las tarifas de bloque y átomo recompensas, pero corren el riesgo de ser castigados (recortados) si el delegado validator es pirateado o viola el protocolo. lo probado garantías de seguridad del consenso de Tendermint BFT, y la garantía depósito de partes interesadas–validators y delegados–proporcionar Seguridad demostrable y cuantificable para nodos y clientes ligeros. Los libros públicos distribuidos deben tener una constitución y un sistema de gobernanza. Bitcoin depende de la Fundación Bitcoin yminería para coordinar las actualizaciones, pero este es un proceso lento. Ethereum se dividió en ETH y ETC después de realizar una bifurcación para abordar El hack DAO, en gran parte porque no existía un contrato social previo ni mecanismo para tomar tales decisiones. Los validadores y delegados en el Cosmos Hub pueden votar en Propuestas que pueden cambiar parámetros preestablecidos del sistema. automáticamente (como el límite de gas de bloque), coordinar actualizaciones, como así como votar sobre enmiendas a la constitución legible por humanos que rigen las políticas del Cosmos Hub. la constitucion permite la cohesión entre las partes interesadas en temas como robos y errores (como el incidente TheDAO), lo que permite una solución más rápida y resolución más limpia. Cada zona también puede tener su propia constitución y gobernanza. mecanismo también. Por ejemplo, el concentrador Cosmos podría tener un constitución que impone la inmutabilidad en el Hub (sin retrocesos, salvo errores de la implementación del nodo Hub Cosmos), mientras que Cada zona puede establecer sus propias políticas con respecto a las reversiones. Al permitir la interoperabilidad entre diferentes zonas políticas, el La red Cosmos ofrece a sus usuarios la máxima libertad y potencial para experimentación sin permiso. Aquí describimos un modelo novedoso de descentralización y escalabilidad. Cosmos es una red de muchos blockchains impulsados por Menta tierna. Si bien las propuestas existentes apuntan a crear una “zona única blockchain” con pedido de transacciones globales totales, Cosmos permite que muchos blockchains se ejecuten simultáneamente entre sí manteniendo la interoperabilidad. En la base, el Cosmos Hub gestiona muchos blockchains llamadas “zonas” (a veces denominadas “fragmentos”, en referencia a la técnica de escalado de bases de datos conocida como “sharding”).

Un flujo constante de confirmaciones de bloques recientes de zonas publicadas en el Hub le permite mantenerse al día con el estado de cada zona. Asimismo, cada zona se mantiene al día con el estado del Hub (pero las zonas No se mantienen al día entre sí excepto indirectamente a través del Centro). Luego se comunican paquetes de información desde uno zona a otra publicando pruebas de Merkle como evidencia de que el Se envió y recibió información. Este mecanismo se llama comunicación inter-blockchain, o IBC para abreviar. Cualquiera de las zonas puede ser en sí misma centros para formar un gráfico acíclico, pero en aras de la claridad sólo describiremos los simples configuración donde solo hay un centro y muchos no centros zonas. El Cosmos Hub es un blockchain que aloja un multiactivo libro mayor distribuido, donde tokens pueden ser mantenidos por usuarios individuales o por zonas propias. Estos tokens se pueden mover de una zona a otro en un paquete especial IBC llamado "paquete de monedas". El centro es responsable de preservar la invariancia global del total cantidad de cada token en todas las zonas. IBC paquete de monedas las transacciones deben ser confirmadas por el remitente, el centro y el receptor blockchains.Dado que el Cosmos Hub actúa como el libro mayor central para todo sistema, la seguridad del Hub es de suma importancia. mientras cada zona puede ser un Tendermint blockchain que está asegurado por tan solo 4 (o incluso menos si no se necesita el consenso BFT), el Hub debe estar protegido por un conjunto globalmente descentralizado de validators que puede resistir los escenarios de ataque más severos, como un partición de la red continental o un ataque patrocinado por un estado-nación. Una zona Cosmos es una blockchain independiente que intercambia IBC mensajes con el Hub. Desde la perspectiva del Hub, una zona es un cuenta multi-activos, membresía dinámica y múltiples firmas que Puede enviar y recibir tokens usando IBC paquetes. como un cuenta de criptomonedas, una zona no puede transferir más tokens que lo tiene, pero puede recibir tokens de otras personas que los tengan. una zona puede ser designado como una "fuente" de uno o más tipos token, otorgándole el poder de inzate ese suministro token. Los átomos del concentrador Cosmos pueden ser apostados por validators de una zona conectado al concentrador. Mientras que los ataques de doble gasto en estas zonas resultaría en la reducción de átomos con la responsabilidad de Tendermint, una zona donde >⅔ del poder de voto están Los bizantinos pueden cometer un estado inválido. El concentrador Cosmos no verificar o ejecutar transacciones comprometidas en otras zonas, por lo que es Es responsabilidad de los usuarios enviar tokens a zonas en las que confían. En el futuro, el sistema de gobernanza del Cosmos Hub puede aprobar el Hub propuestas de mejora que den cuenta de las fallas de la zona. Para Por ejemplo, las transferencias salientes token desde algunas (o todas) zonas pueden estrangulado para permitir el corte de circuito de emergencia de zonas (una interrupción temporal de las token transferencias) cuando se detecta un ataque. Ahora veremos cómo el Hub y las zonas se comunican entre sí. otro. Por ejemplo, si hay tres blockchains, “Zona1”, “Zona2”,

y "Hub", y deseamos que "Zone1" produzca un paquete destinado para “Zone2” pasando por “Hub”. Para mover un paquete de uno blockchain a otro, se publica una prueba en la cadena de recepción. La prueba afirma que la cadena de envío publicó un paquete para el supuesto destino. Para que la cadena receptora pueda comprobar esta prueba, debe poder mantenerse al día con los encabezados de bloque del remitente. esto El mecanismo es similar al utilizado por las cadenas laterales, que requiere dos cadenas que interactúan para ser conscientes una de la otra a través de un flujo bidireccional de datagramas de prueba de existencia (transacciones). El protocolo IBC se puede definir naturalmente utilizando dos tipos de transacciones: una transacción  IBCBlockCommitTx , que permite una blockchain para demostrarle a cualquier observador de su bloque más reciente-hash, y una transacción IBCPacketTx , que permite que un blockchain demostrar a cualquier observador que el paquete dado fue efectivamente publicado por la aplicación del remitente, a través de una prueba de Merkle a la reciente bloque-hash. Al dividir la mecánica IBC en dos transacciones separadas, podemos permitir que el mecanismo de mercado de tarifas nativo de la cadena receptora determinar qué paquetes se confirman (es decir, se reconocen), mientras permitiendo total libertad en la cadena de envío en cuanto a cómo Se permiten muchos paquetes salientes. En el ejemplo anterior, para actualizar el bloque-hash de "Zona1" en "Hub" (o de "Hub" en "Zone2"), un  IBCBlockCommitTxLa transacción debe publicarse en "Hub" con el bloque-hash de “Zona1” (o en “Zona2” con el bloque-hash de “Hub”). Consulte IBCBlockCommitTx y IBCPacketTx para obtener más información. en los dos tipos de transacciones IBC. De la misma manera que Bitcoin es más seguro al ser distribuido, libro mayor replicado masivamente, podemos hacer que los intercambios sean menos vulnerables a hacks externos e internos ejecutándolo en el blockchain. nosotros Llame a esto un intercambio distribuido. Lo que la comunidad de criptomonedas llama descentralizado El intercambio actual se basa en algo llamado transacciones de "cadena cruzada atómica" (AXC). Con una transacción AXC, dos usuarios en dos cadenas diferentes pueden realizar dos transacciones de transferencia que son comprometidos juntos en ambos libros mayores, o ninguno en absoluto (es decir, atómicamente). Por ejemplo, dos usuarios pueden intercambiar bitcoins por ether (o dos tokens cualesquiera en dos libros de contabilidad diferentes) utilizando transacciones AXC, aunque Bitcoin y Ethereum no están conectados entre sí otro. El beneficio de ejecutar un intercambio en transacciones AXC es que ninguno de los usuarios necesita confiar entre sí ni en el intercambio comercial servicio. La desventaja es que ambas partes deben estar en línea para que se produzca el comercio. Otro tipo de intercambio descentralizado es el replicado masivamente. intercambio distribuido que se ejecuta por sí solo blockchain. Usuarios en este tipo de intercambio puede enviar una orden limitada y convertir su computadora apagada y la operación se puede ejecutar sin que el usuario sea en línea. El blockchain coincide y completa la operación en nombre del comerciante.

Aplicaciones

Un intercambio centralizado puede crear una cartera de pedidos profunda y limitada pedidos y así atraer a más comerciantes. La liquidez engendra más liquidez en el mundo cambiario, por lo que existe una fuerte red efecto (o al menos un efecto de que el ganador se lleva la mayor parte) en el intercambio negocio. El líder actual en intercambios de criptomonedas en la actualidad. es Poloniex con un volumen de 24 horas de $20M, y en segundo lugar está Bitynex con un volumen de 5 millones de dólares en 24 horas. Dada una red tan fuerte efectos, es poco probable que los intercambios descentralizados basados ​​en AXC ganar volumen sobre los intercambios centralizados. Por una descentralización intercambio para competir con un intercambio centralizado, necesitaría para soportar carteras de pedidos profundas con órdenes limitadas. Sólo un distribuido El intercambio en un blockchain puede proporcionar eso. Tendermint proporciona beneficios adicionales para transacciones más rápidas se compromete. Priorizando la finalización rápida sin sacrificar coherencia, las zonas en Cosmos pueden analizar transacciones rápidamente, por tanto transacciones de orden de cambio como IBC token transferencias a y de otras zonas. Dado el estado actual de los intercambios de criptomonedas, una gran La aplicación para Cosmos es el intercambio distribuido (también conocido como el CosmosDEX). La capacidad de rendimiento de transacciones, así como La latencia de confirmación puede ser comparable a la de la centralizada. intercambios. Los comerciantes pueden enviar órdenes limitadas que se pueden ejecutar sin que ambas partes tengan que estar en línea. Y con Tendermint, el centro Cosmos y IBC, los operadores pueden mover fondos dentro y fuera de el intercambio hacia y desde otras zonas con rapidez. Una zona privilegiada puede actuar como fuente de un token puenteado de Otra criptomoneda. Un puente es similar a la relación. entre un centro y una zona Cosmos; ambos deben mantenerse al día con el últimos bloques del otro para verificar las pruebas de que tokens tienen pasó de uno a otro. Una "zona puente" en la Cosmos La red se mantiene al día con el Hub y con los demás.

criptomoneda. La dirección indirecta a través de la zona del puente permite La lógica del Hub es permanecer simple y agnóstica con respecto a otros. blockchain estrategias de consenso como Bitcoin proof-of-work minería. Cada zona puente validator ejecutaría un sistema impulsado por Tendermint blockchain con una aplicación puente especial ABCI, pero también un nodo completo de el “origen” blockchain. Cuando se extraen nuevos bloques en el origen, la zona del puente validators llegarán a un acuerdo sobre los bloques comprometidos firmando y compartir su respectiva visión local del blockchain del origen. propina. Cuando una zona puente recibe el pago en el origen (y Se acordó haber visto suficientes confirmaciones en el caso. de una cadena PoW como Ethereum o Bitcoin), un correspondiente Se crea una cuenta en la zona puente con ese saldo. En el caso de Ethereum, la zona puente puede compartir la misma validator: establecido como el concentrador Cosmos. En el lado Ethereum (el origen), un contrato puente permitiría a los titulares de ether enviar ether a la zona puente enviándolo al contrato puente en Ethereum. Una vez que el contrato puente recibe el éter, el El éter no se puede retirar a menos que se envíe un paquete IBC apropiado. recibido por el contrato puente de la zona puente. el El contrato-puente rastrea el conjunto validator de la zona-puente, que puede ser idéntico al conjunto validator del Cosmos Hub. En el caso de Bitcoin, el concepto es similar excepto que en lugar de un único contrato puente, cada UTXO estaría controlado por un umbral de pubscript P2SH multifirma. Debido a las limitaciones de En el sistema P2SH, los firmantes no pueden ser idénticos al Cosmos. Buje validator-conjunto.El éter en la zona del puente (“éter puenteado”) se puede transferir a y desde el Hub, y luego ser destruido con una transacción que lo envía a una dirección de retiro particular en Ethereum. Un IBC paquete que prueba que la transacción ocurrió en la zona puente se puede publicar en el contrato puente Ethereum para permitir que el éter para ser retirado. En el caso de Bitcoin, el sistema de secuencias de comandos restringido hace que sea Es difícil reflejar el mecanismo de transferencia de monedas IBC. Cada UTXO tiene su propio pubscript independiente, por lo que cada UTXO debe ser migrado a un nuevo UTXO cuando hay un cambio en el conjunto de Bitcoin firmantes del depósito de garantía. Una solución es comprimir y descomprima el conjunto UTXO según sea necesario para mantener el número total de UTXOs caídos. El riesgo de un contrato puente de este tipo es un conjunto validator deshonesto. ≥⅓ El poder de voto bizantino podría provocar una bifurcación y retirar el éter del contrato de puente en Ethereum mientras se mantiene el puente en la zona del puente. Peor aún, >⅔ del poder de voto bizantino puede robar éter directamente de quienes lo enviaron al contrato puente desviándose de la lógica de puenteo original de la zona del puente. Es posible abordar estos problemas diseñando el puente para que sea totalmente responsable. Por ejemplo, todos los paquetes IBC, desde el concentrador y el origen, podría requerir el reconocimiento por parte de la zona del puente en de tal manera que todas las transiciones de estado de la zona del puente puedan ser desafiado y verificado eficientemente por el centro o por el origen contrato-puente. El Hub y el origen deben permitir que la zona puente validators publique garantías y token transferencias fuera de la El contrato puente debe retrasarse (y la desvinculación de la garantía período lo suficientemente largo) para permitir que cualquier impugnación sea realizada por auditores independientes. Dejamos el diseño de la especificación y Implementación de este sistema abierto como futuro Cosmos

propuesta de mejora, que será aprobada por el Cosmos Hub sistema de gobernanza. Resolver el problema de escala es un tema abierto para Ethereum. Actualmente, los nodos Ethereum procesan cada transacción y También almacena todos los estados. enlace. Dado que Tendermint puede confirmar bloques mucho más rápido que los de Ethereum Zonas proof-of-work, EVM impulsadas por el consenso de Tendermint y operar con éter puenteado puede proporcionar un mayor rendimiento a Ethereum blockchains. Además, aunque el Cosmos Hub y IBC la mecánica de paquetes no permite una lógica de contrato arbitraria ejecución per se, se puede utilizar para coordinar token movimientos entre Ethereum contratos que se ejecutan en diferentes zonas, proporcionando una base para el escalamiento centrado en token Ethereum a través de fragmentación. Las zonas Cosmos ejecutan una lógica de aplicación arbitraria, que se define en el comienzo de la vida de la zona y potencialmente puede actualizarse a lo largo del tiempo por la gobernanza. Esta flexibilidad permite que Cosmos zonas actuar como puentes hacia otras criptomonedas como Ethereum o Bitcoin, y también permite derivados de esos blockchains, utilizando la misma base de código pero con un conjunto validator diferente y distribución inicial. Esto permite que muchas criptomonedas existentes frameworks, como los de Ethereum, Zerocash, Bitcoin, CryptoNote, etc., para usar con Tendermint Core, que es un motor de consenso de mayor rendimiento, en una red común, abriendo una tremenda oportunidad para la interoperabilidad entre plataformas. Además, como multiactivo blockchain, un único La transacción puede contener múltiples entradas y salidas, donde cada una La entrada puede ser de cualquier tipo token, lo que permite que Cosmos sirva directamente como una plataforma para el intercambio descentralizado, aunque se asumen pedidospara ser emparejado a través de otras plataformas. Alternativamente, una zona puede servir como un intercambio distribuido tolerante a fallas (con libros de pedidos), que Puede ser una mejora estricta con respecto a la centralizada existente. intercambios de criptomonedas que tienden a ser pirateados con el tiempo. Las zonas también pueden servir como versiones empresariales respaldadas por blockchain y sistemas gubernamentales, donde partes de un servicio particular que tradicionalmente están dirigidos por una organización o grupo de organizaciones en su lugar, se ejecutan como una aplicación ABCI en una zona determinada, que le permite heredar la seguridad y la interoperabilidad del público Cosmos red sin sacrificar el control sobre la red subyacente servicio. Por lo tanto, Cosmos puede ofrecer lo mejor de ambos mundos para organizaciones que buscan utilizar la tecnología blockchain pero que están desconfiado de ceder completamente el control a un tercero distribuido fiesta. Algunos afirman que un problema importante con las políticas que favorecen la coherencia algoritmos de consenso como Tendermint es que cualquier red partición que hace que no haya una sola partición con >⅔ el poder de voto (por ejemplo, ≥⅓ salir de una revista) detendrá el consenso por completo. La arquitectura Cosmos puede ayudar a mitigar este problema mediante el uso un centro global con zonas autónomas regionales, donde el poder de voto para cada zona se distribuyen en base a una zona geográfica común región. Por ejemplo, un paradigma común puede ser el de individuos ciudades o regiones para operar sus propias zonas mientras comparten una eje común (por ejemplo, el Cosmos Hub), que permite que la actividad municipal persistir en caso de que el concentrador se detenga debido a una red temporal partición. Tenga en cuenta que esto permite una verdadera geología, política y Características topológicas de la red que se deben considerar al diseñar sistemas robustos. Sistemas federados tolerantes a fallos.

NameCoin fue uno de los primeros blockchains en intentar resolver el problema de resolución de nombres adaptando el Bitcoin blockchain. Lamentablemente, ha habido varios problemas con este enfoque. Con Namecoin podemos comprobar que, por ejemplo, @satoshi fue registrado con una clave pública particular en algún momento en el pasado, pero no sabríamos si la clave pública había sido desde entonces actualizado recientemente a menos que descarguemos todos los bloques desde el último actualización de ese nombre. Esto se debe a la limitación de Bitcoin UTXO transacción Modelo de merkle-ización, donde solo el las transacciones (pero no el estado de la aplicación mutable) están adaptadas a Merkle en el bloque-hash. Esto nos permite probar la existencia, pero no la inexistencia de actualizaciones posteriores de un nombre. Por lo tanto, no podemos saber por seguro el valor más reciente de un nombre sin confiar en un completo nodo, o incurrir en costos significativos en ancho de banda al descargar todo el blockchain. Incluso si se implementara un árbol de búsqueda tipo Merkle en NameCoin, su dependencia de proof-of-work facilita la verificación del cliente problemático. Los clientes Light deben descargar una copia completa del encabezados para todos los bloques en todo el blockchain (o al menos todos los encabezados desde la última actualización de un nombre). Esto significa que el Los requisitos de ancho de banda aumentan linealmente con la cantidad de tiempo. [21]. Además, cambios de nombre en un proof-of-work blockchain requiere esperar proof-of-work bloques de confirmación adicionales, lo que puede tardar hasta una hora el Bitcoin. Con Tendermint, todo lo que necesitamos es el bloque más reciente: hash firmado por un quórum de validators (por poder de voto) y un Merkle prueba del valor actual asociado con el nombre. Esto lo hace Es posible tener un cliente ligero conciso, rápido y seguro. verificación de valores de nombres. En Cosmos, podemos tomar este concepto y ampliarlo más. cada uno La zona de registro de nombres en Cosmos puede tener un nombre de dominio de nivel superior (TLD) asociado, como “.com” o “.org”, y cada nombre-

La zona de registro puede tener su propia gobernanza y registro. reglas.

Gobernanza y economía

Si bien el Cosmos Hub es un libro mayor distribuido de activos múltiples, existe un token nativo especial llamado átomo. Los átomos son los únicos staking token del concentrador Cosmos. Los átomos son una licencia para que su poseedor pueda votar, validar o delegar en otros validators. Me gusta Ethereum éter, los átomos también se pueden utilizar para pagar las tarifas de transacción para mitigar el spam. Átomos inzacionarios adicionales y transacción en bloque. las tarifas se recompensan a validators y a los delegados que delegan en validators. La transacción  BurnAtomTx  se puede utilizar para recuperar cualquier cantidad proporcional de tokens del fondo de reserva. La distribución inicial del átomo tokens y validators en Génesis se destinará a los donantes de la recaudación de fondos Cosmos (75%), donantes principales (5%), Cosmos Network Foundation (10%) y ALL IN BITS, Inc. (10%). Desde la génesis en adelante, 1/3 de la cantidad total de átomos Se recompensará a los validators vinculados y a los delegados cada año. Consulte el Plan Cosmos para obtener detalles adicionales. A diferencia de Bitcoin u otros proof-of-work blockchains, un Tendermint blockchain se vuelve más lento con más validator debido al aumento Complejidad de la comunicación. Afortunadamente, podemos apoyar lo suficiente validators para crear un blockchain robusto distribuido globalmente con tiempos de confirmación de transacciones muy rápidos y, como ancho de banda,

almacenamiento y capacidad de computación paralela, podremos para admitir más validators en el futuro. El día de la génesis, el número máximo de validators se establecerá en 100, y este número aumentará a una tasa del 13% durante 10 años, y liquidarse en 300 validators. Los poseedores de átomos que aún no lo son pueden convertirse en validators al firmar y enviar una transacción  BondTx . la cantidad de Los átomos proporcionados como garantía deben ser distintos de cero. Cualquiera puede convertirse a validator en cualquier momento, excepto cuando el tamaño del actual El conjunto validator es mayor que el número máximo de validators permitido. En ese caso, la transacción sólo es válida si el monto de átomos es mayor que la cantidad de átomos efectivos que contiene el más pequeño validator, donde los átomos efectivos incluyen átomos delegados. Cuando un nuevo validator reemplaza un validator existente de tal manera, el validator existente se vuelve inactivo y todos los átomos y Los átomos delegados entran en el estado desligado. Debe imponerse alguna sanción a los validators por cualquier Desviación intencional o no intencional de lo sancionado. protocolo. Algunas pruebas son inmediatamente admisibles, como una doble señal a la misma altura y vuelta, o una violación de Año 0: 100  Año 1: 113  Año 2: 127  Año 3: 144  Año 4: 163  Año 5: 184  Año 6: 208  Año 7: 235  Año 8: 265  Año 9: 300  Año 10: 300  ...

“prevote-the-lock” (una regla del protocolo de consenso de Tendermint). Dicha evidencia resultará en que el validator pierda su buena reputación. y sus átomos enlazados, así como su participación proporcional de tokens en el fondo de reserva –llamado colectivamente su “participación”– se reducirá drásticamente. A veces, los validators no estarán disponibles, ya sea debido a cuestiones regionales interrupciones de la red, cortes de energía u otras razones. Si, en cualquier punto en los últimos bloques  ValidatorTimeoutWindow , un validator El voto de confirmación no está incluido en el blockchain más de  ValidatorTimeoutMaxAbsent veces, ese validator se convertirá en inactivo y perderá  ValidatorTimeoutPenalty  (POR PREDETERMINADO 1%) de su estaca. Algunos comportamientos “maliciosos” no producen resultados evidentemente discernibles. evidencia sobre el blockchain. En estos casos, los validators pueden coordinar fuera de banda para forzar el tiempo de espera de estos maliciosos validators, si hay un consenso de supermayoría. En situaciones en las que el Centro Cosmos se detiene debido a una coalición ≥⅓ de el poder de voto sale de la revista, o en situaciones en las que una coalición ≥⅓ del poder de voto censurar evidencia de comportamiento malicioso por parte de ingresando al blockchain, el hub debe recuperarse con un hard-fork propuesta de reorganización. (Enlace a “Bifurcaciones y ataques de censura”). Cosmos Hub validators puede aceptar cualquier token tipo o combinación de tipos como tarifas por procesar una transacción. Cada validator puede establecer subjetivamente el tipo de cambio que desee y elegir cualquier transacción que desee, siempre y cuando el  BlockGasLimit  sea no superado. Las tarifas cobradas, menos los impuestos que se especifican a continuación, se redistribuyen entre los accionistas vinculados en proporción a sus átomos enlazados, cada  ValidatorPayoutPeriod  (POR PREDETERMINADO 1 hora).De las tarifas de transacción cobradas, se aplicará el impuesto de reserva (2 % POR DEFECTO). ir hacia el grupo de reserva para aumentar el grupo de reserva y aumentar la seguridad y el valor de la red Cosmos. estos Los fondos también se pueden distribuir de acuerdo con las decisiones. realizadas por el sistema de gobierno. Poseedores de átomos que delegan su poder de voto a otros validators pagar una comisión al delegado validator. La comisión puede ser establecido por cada validator. La seguridad del Cosmos Hub es una función de la seguridad del validators subyacentes y la elección de delegación por parte de los delegados. Para fomentar el descubrimiento y la notificación temprana de los hallazgos vulnerabilidades, el Cosmos Hub alienta a los piratas informáticos a publicar exploits exitosos a través de una transacción  ReportHackTx  que dice: "Este validator fue pirateado. Por favor envíe la recompensa a esta dirección”. sobre tal exploit, el validator y los delegados quedarán inactivos,  HackPunishmentRatio (predeterminado 5%) de los átomos de todos obtendrán cortado y  HackRewardRatio  (5 %) de los átomos de todos será recompensado en la dirección de recompensa del hacker. El validator debe recuperar los átomos restantes utilizando su clave de respaldo. Para evitar que se abuse de esta característica para transferir átomos no adquiridos, la porción de átomos adquiridos frente a los no adquiridos de validators y delegados antes y después del  ReportHackTx  siguen siendo los mismos, y la recompensa por hackers incluirá algunos átomos no adquiridos, si los hay. El Cosmos Hub es operado por una organización distribuida que requiere un mecanismo de gobernanza bien definido para coordinar varios cambios en el blockchain, como la variable

parámetros del sistema, así como actualizaciones de software y enmiendas constitucionales. Todos los validator son responsables de votar todas las propuestas. No poder votar una propuesta de manera oportuna resultará en el validator siendo desactivado automáticamente durante un período de tiempo llamado  Período de penalización por ausentismo (POR PREDETERMINADO, 1 semana). Los delegados heredan automáticamente el voto del delegado. validator. Esta votación puede anularse manualmente. Átomos no enlazados no obtener ningún voto. Cada propuesta requiere un depósito de  MinimumProposalDeposit  tokens, que puede ser una combinación de uno o más tokens incluyendo los átomos. Para cada propuesta, los votantes pueden votar para tomar el depósito. Si más de la mitad de los votantes optan por tomar la depósito (por ejemplo, porque la propuesta era spam), el depósito va a reserva, excepto los átomos que se queman. Para cada propuesta, los votantes podrán votar con las siguientes opciones: si Sí con fuerza No No con fuerza abstenerse Una mayoría estricta de votos Sí o SíConFuerza (o No o votos NayWithForce) es necesario para que la propuesta se decida como aprobado (o decidido como fallido), pero 1/3+ puede vetar la mayoría decisión votando “con fuerza”. Cuando se veta por mayoría estricta, todos son castigados con la pérdida de VetoPenaltyFeeBlocks  (POR DEFECTO el valor de 1 día de bloques) valor de tarifas (excepto impuestos que no se verá afectado), y el partido que vetó la mayoría

La decisión será castigada adicionalmente con la pérdida de VetoPenaltyAtoms.  (POR DEFECTO 0,1%) de sus átomos. Cualquiera de los parámetros definidos aquí se puede cambiar con el paso de una  ParameterChangeProposal . Los átomos pueden ser inzatados y los fondos del fondo de reserva gastados con el aprobación de una  BountyProposal . Todas las demás propuestas, como la propuesta para mejorar el protocolo, se coordinará a través de la  TextProposal  genérica. Ver el plano. Ha habido muchas innovaciones en el consenso blockchain y escalabilidad en los últimos años. Esta sección proporciona una breve encuesta de un número selecto de importantes. El consenso en presencia de participantes malintencionados es un problema que se remonta a principios de la década de 1980, cuando Leslie Lamport acuñó el frase “falla bizantina” para referirse al comportamiento arbitrario del proceso que se desvía del comportamiento previsto, a diferencia de un "fallo de accidente", donde un proceso simplemente falla. Se descubrieron las primeras soluciones para redes síncronas donde hay un límite superior enlatencia del mensaje, aunque el uso práctico se limitó a niveles altamente entornos controlados, como controladores de aviones y Centros de datos sincronizados mediante relojes atómicos. No fue hasta el A finales de los 90 se creó la Tolerancia práctica a fallos bizantinos (PBFT) [11]. presentado como un consenso eficiente parcialmente sincrónico algoritmo capaz de tolerar hasta ⅓ de los procesos que se comportan arbitrariamente. PBFT se convirtió en el algoritmo estándar, generando muchos variaciones, incluida la más reciente creada por IBM como parte de su contribución a Hyperledger. El principal beneficio del consenso de Tendermint sobre PBFT es que Tendermint tiene una estructura subyacente mejorada y simplificada, algo de lo cual es el resultado de adoptar el paradigma blockchain. Los bloques de Tendermint deben comprometerse en orden, lo que evita la complejidad y sobrecarga de comunicación asociados con PBFT cambios de vista. En Cosmos y muchas criptomonedas, no existe Es necesario permitir que el bloque N+i donde i >= 1 se confirme, cuando el bloque N en sí aún no se ha comprometido. Si el ancho de banda es la razón por la cual bloquear N no se ha comprometido en una zona Cosmos, entonces no ayuda usar Votos para compartir ancho de banda por los bloques N+i. Si una partición de red o Los nodos de ofzine son la razón por la cual el bloque N no se ha comprometido, entonces N+i no me comprometeré de todos modos. Además, la agrupación de transacciones en bloques permite Merkle-hashing regular del estado de la aplicación, en lugar de resúmenes periódicos como con el esquema de puntos de control de PBFT. Esto permite para compromisos de transacciones demostrables más rápidos para clientes ligeros y más rápidos comunicación inter-blockchain. Tendermint Core también incluye muchas optimizaciones y características que van más allá de lo especificado en PBFT. Por ejemplo, los bloques propuestos por validators están divididos en partes, Merkle-izados, y chismear de tal manera que mejore la difusión rendimiento (consulte LibSwift [19] para inspirarse). Además, menta Core no hace ninguna suposición sobre el punto a punto

conectividad y funciones mientras la red P2P esté débilmente conectado. Si bien no es el primero en implementar proof-of-stake (PoS), BitShares1.0 [12] contribuyó considerablemente a la investigación y adopción de PoS blockchains, particularmente aquellos conocidos como PoS “delegados”. en BitShares, las partes interesadas eligen "testigos", responsables de realizar pedidos y realizar transacciones, y "delegados", responsables de Coordinar actualizaciones de software y cambios de parámetros. BitShares2.0 tiene como objetivo lograr un alto rendimiento (100k tx/s, 1s latencia) en condiciones ideales, con cada bloque firmado por un único firmante y la duración de la transacción tardan bastante más que el intervalo de bloque. Aún se está desarrollando una especificación canónica. Las partes interesadas pueden eliminar o reemplazar a los testigos que se portan mal en un diariamente, pero no hay ninguna garantía significativa de testigos o delegados a semejanza de Tendermint PoS que son cortados el caso de un ataque de doble gasto exitoso. Basándose en un enfoque iniciado por Ripple, Stellar [13] creó un modelo de Acuerdo Bizantino Federado en el que los procesos participar en el consenso no constituye un acuerdo fijo y global. conjunto conocido. Más bien, cada nodo de proceso selecciona uno o más “porciones de quórum”, cada una de las cuales constituye un conjunto de procesos confiables. un “quórum” en Stellar se define como un conjunto de nodos que contienen al menos al menos un segmento de quórum para cada nodo del conjunto, de modo que se puede llegar a un acuerdo. La seguridad del mecanismo Stellar se basa en la suposición que la intersección de dos quórums cualesquiera no esté vacía, mientras que la La disponibilidad de un nodo requiere que al menos uno de sus sectores de quórum constan enteramente de nodos correctos, creando un equilibrio entre Usar porciones de quórum grandes o pequeñas que pueden ser difíciles de equilibrar. sin imponer supuestos significativos sobre la confianza. Al final,los nodos deben de alguna manera elegir porciones de quórum adecuadas para que ser suficiente tolerancia a fallas (o cualquier "nodo intacto", de los cuales dependen gran parte de los resultados del artículo), y el único La estrategia proporcionada para garantizar que dicha configuración sea jerárquica. y similar al Border Gateway Protocol (BGP), utilizado por los principales ISP de Internet para establecer tablas de enrutamiento globales, y por el utilizado por los navegadores para gestionar certificados TLS; ambos notorios por su inseguridad. La crítica en el artículo Stellar a los sistemas de prueba de participación basados en Tendermint se ve mitigada por la estrategia token descrita. aquí, donde se emite un nuevo tipo de token llamado átomo que representan reclamaciones sobre porciones futuras de honorarios y recompensas. el La ventaja de proof-of-stake basado en Tendermint, entonces, es su relativo simplicidad, sin dejar de proporcionar seguridad suficiente y demostrable garantías. BitcoinNG es una mejora propuesta para Bitcoin que permitiría para formas de escalabilidad vertical, como aumentar el tamaño del bloque, sin las consecuencias económicas negativas típicamente asociadas con tal cambio, como el impacto desproporcionadamente grande sobre los pequeños mineros. Esta mejora se consigue separando elección de líder a partir de la transmisión de transacciones: los líderes son los primeros elegido por proof-of-work en “microbloques”, y luego capaz de transmitir transacciones que se confirmarán hasta un nuevo microbloque se encuentra. Esto reduce los requisitos de ancho de banda necesarios para ganar la carrera de PoW, permitiendo a los pequeños mineros competir de manera más justa, y permitir que las transacciones se realicen con mayor regularidad por parte del último minero en encontrar un microbloque. Casper [16] es un algoritmo de consenso propuesto proof-of-stake para Ethereum. Su modo principal de operación es el “consenso por apuesta”. Por dejar que validators apuesten iterativamente sobre qué bloque creen que será

comprometerse con el blockchain según las otras apuestas que han visto hasta ahora, eventualmente se podrá lograr la ynalidad. enlace. Esta es un área activa de investigación por parte del equipo de Casper. el El desafío está en construir un mecanismo de apuestas que pueda ser ha demostrado ser una estrategia evolutivamente estable. El principal beneficio de Casper, en comparación con Tendermint, puede ofrecer "disponibilidad exceso de coherencia” – el consenso no requiere > 2/3 de quórum de poder de voto, tal vez a costa de la velocidad de compromiso o complejidad de implementación. El protocolo Interledger [14] no es estrictamente una solución de escalabilidad. eso Proporciona una interoperación ad hoc entre diferentes libros de contabilidad. sistemas a través de una red de relaciones bilaterales poco acopladas. Al igual que Lightning Network, el propósito de ILP es facilitar pagos, pero se centra específicamente en pagos en diferentes tipos de libro mayor y extiende el mecanismo de transacciones atómicas a incluir no sólo hash-candados, sino también un quórum de notarios (llamado el Protocolo de Transporte Atómico). Este último mecanismo para hacer cumplir la atomicidad en las transacciones entre libros mayores es similar a El mecanismo SPV de cliente ligero de Tendermint, por lo que una ilustración del se justifica la distinción entre ILP y Cosmos/IBC, y proporcionado a continuación. 1. Los notarios de un conector en ILP no admiten membresía cambios y no permiten ponderaciones flexibles entre notarios. Por otro lado, IBC está diseñado específicamente para blockchains, donde validators pueden tener diferentes pesos, y donde la membresía puede cambiar en el transcurso del blockchain. 2. Al igual que en Lightning Network, el receptor del pago en ILP debe estar en línea para enviar una confirmación al remitente. en untoken transferencia sobre IBC, el conjunto validator del receptor blockchain es responsable de proporcionar confirmación, no el usuario receptor. 3. La diferencia más sorprendente es que los conectores del ILP no son responsable o mantener un estado autoritario sobre los pagos, mientras que en Cosmos, los validators de un hub son la autoridad de el estado de las transferencias IBC token así como la autoridad del cantidad de tokens retenidos por cada zona (pero no la cantidad de tokens mantenidos por cada cuenta dentro de una zona). Este es el innovación fundamental que permite una seguridad asimétrica transferencia de tokens de zona a zona; el análogo de ILP El conector en Cosmos es persistente y de máxima seguridad. blockchain libro mayor, el Cosmos Hub. 4. Los pagos entre libros contables en ILP deben estar respaldados por un libro de órdenes de intercambio, ya que no hay transferencia asimétrica de monedas de un libro mayor a otro, sólo la transferencia de valor o equivalentes de mercado. Las cadenas laterales [15] son un mecanismo propuesto para escalar el Bitcoin red a través de blockchains alternativos que están "vinculados en dos direcciones" a el Bitcoin blockchain. (La vinculación bidireccional equivale a puente. En Cosmos decimos "puente" para distinguirlo de la vinculación al mercado). Las cadenas laterales permiten que los bitcoins se muevan efectivamente desde el Bitcoin blockchain a la cadena lateral y viceversa, y permita Experimentación de nuevas funciones en la cadena lateral. Como en el Cosmos Hub, la cadena lateral y Bitcoin sirven como clientes ligeros de entre sí, utilizando pruebas SPV para determinar cuándo se deben transferido a la cadena lateral y viceversa. Por supuesto, desde Bitcoin usa proof-of-work, las cadenas laterales centradas alrededor de Bitcoin sufren de los muchos problemas y riesgos de proof-of-work como mecanismo de consenso. Además, este es un Bitcoin-maximalista solución que no admite de forma nativa una variedad de token y

topología de red entre zonas como lo hace Cosmos. Dicho esto, el núcleo El mecanismo de la clavija de dos vías es en principio el mismo que el empleado por la red Cosmos. Ethereum actualmente está investigando varias estrategias diferentes. para fragmentar el estado de Ethereum blockchain para abordar necesidades de escalabilidad. Estos esfuerzos tienen como objetivo mantener la capa de abstracción que ofrece la máquina virtual Ethereum actual a través del espacio estatal compartido. Múltiples esfuerzos de investigación son en marcha en este momento. [18][22] Cosmos y Ethereum 2.0 Mauve [22] tienen diferentes objetivos de diseño. Cosmos se trata específicamente de tokens. Mauve se trata de escalar cálculo general. Cosmos no está vinculado a EVM, por lo que incluso diferentes VM pueden interoperar. Cosmos permite al creador de la zona determinar quién valida la zona. Cualquiera puede iniciar una nueva zona en Cosmos (a menos que la gobernanza decide lo contrario). El concentrador aísla las fallas de zona para que las invariantes token globales sean conservado. Lightning Network es una red de transferencia propuesta token operando en una capa por encima del Bitcoin blockchain (y otros blockchains), permitiendo mejoras de muchos órdenes de magnitud en el rendimiento de las transacciones al mover la mayoría de las transacciones fuera del libro de consenso hacia los llamados "canales de pago".Esto es posible gracias a los scripts de criptomonedas en cadena, que permitir a las partes celebrar contratos estatales bilaterales donde el El estado se puede actualizar compartiendo firmas digitales y contratos. se puede cerrar publicando finalmente evidencia en el blockchain, un Mecanismo popularizado por primera vez mediante intercambios atómicos entre cadenas. Por abriendo canales de pago con muchas partes, participantes en el Lightning Network puede convertirse en puntos focales para enrutar el pagos de otros, lo que lleva a un canal de pago totalmente conectado red, a costa de que el capital quede inmovilizado en los canales de pago. Si bien Lightning Network también puede extenderse fácilmente a través de Múltiples blockchains independientes para permitir la transferencia de valor. a través de un mercado de cambios, no se puede utilizar para negociar asimétricamente transferir tokens de un blockchain a otro. El principal beneficio de la red Cosmos descrita aquí es para permitir dicha conexión directa token transferencias. Dicho esto, esperamos que los canales de pago y la Lightning Network será ampliamente adoptada junto con nuestra token mecanismo de transferencia, por motivos de ahorro de costes y privacidad. Testigo Segregado es un enlace de propuesta de mejora Bitcoin que tiene como objetivo aumentar el rendimiento de las transacciones por bloque 2X o 3X, y al mismo tiempo acelera la sincronización de bloques para nuevos nodos. La brillantez de esta solución está en cómo funciona dentro del limitaciones del protocolo actual de Bitcoin y permite una bifurcación suave actualización (es decir, los clientes con versiones anteriores del software seguirá funcionando después de la actualización). Tendermint, al ser nuevo protocolo, no tiene restricciones de diseño, por lo que tiene un escalado diferente prioridades. Principalmente, Tendermint utiliza un algoritmo de operación por turnos BFT basado en firmas criptográficas en lugar de minería, lo que trivialmente permite el escalado horizontal a través de múltiples paralelos blockchains, mientras que las confirmaciones de bloque regulares y más frecuentes permiten escala vertical también.

Consenso y detalles técnicos

Un protocolo de consenso bien diseñado debería proporcionar algunas Garantías en caso de que se supere la capacidad de tolerancia. y el consenso falla. Esto es especialmente necesario en el ámbito económico. sistemas, donde el comportamiento bizantino puede tener importantes consecuencias financieras. recompensa. La garantía más importante de este tipo es una forma de rendición de cuentas, en la que los procesos que provocaron que se alcanzara el consenso fallar (es decir, provocó que los clientes del protocolo aceptaran valores diferentes; tenedor) puede ser identificado y castigado de acuerdo con las reglas de la protocolo o, posiblemente, el sistema jurídico. Cuando el sistema legal es poco confiable o excesivamente costoso invocar, los validators pueden ser obligados a realizar depósitos de seguridad para poder participar, y aquellos Los depósitos pueden ser revocados o recortados cuando se detecta un comportamiento malicioso. detectado [10]. Tenga en cuenta que esto es diferente a Bitcoin, donde la bifurcación es algo habitual debido a la asincronía de la red y la naturaleza probabilística de ynding colisiones parciales hash. Dado que en muchos casos se produce una bifurcación maliciosa indistinguible de una bifurcación debido a la asincronía, Bitcoin no puede implementar de manera confiable la responsabilidad fork, aparte de la implícita Costo de oportunidad pagado por los mineros por extraer un bloque huérfano. A las etapas de votación las llamamos PreVote y PreCommit. Un voto puede ser a favor un bloque en particular o para Nil. Llamamos a una colección de >⅔ PreVotes para un solo bloque en la misma ronda, una polca y una colección de >⅔ PreCommits para un solo bloque en la misma ronda un Commit. Si >⅔ PreCommit for Nil en la misma ronda, pasan a la siguiente redondo. Tenga en cuenta que el determinismo estricto en el protocolo incurre en una débil Se debe detectar el supuesto de sincronía como líderes defectuosos y

saltado. Por lo tanto, validators esperan un tiempo, TimeoutPropose, antes de que Prevote Nil, y el valor de TimeoutPropose aumenta con cada ronda. Progresión a través de el resto de una ronda es completamente asincrónica, en el sentido de que el progreso es sólo realizado una vez que un validator escucha desde >⅔ de la red. En la práctica, Se necesitaría un adversario extremadamente fuerte para frustrar indefinidamente el supuesto de sincronía débil (lo que hace que el consenso no logre alguna vez comete un bloqueo), y hacerlo puede ser aún más difícil mediante el uso de valores aleatorios de TimeoutPropose en cada validator. Un conjunto adicional de restricciones, o reglas de bloqueo, garantiza que el La red eventualmente comprometerá solo un bloque en cada altura. Cualquiera Intento malicioso de provocar que se cometa más de un bloque. a una altura determinada se puede identificar. Primero, un PreCommit para un bloque. debe venir con justificación, en forma de polca para ese bloque. Si validator ya ha confirmado previamente un bloque en la ronda R_1, dicen que están encerrados en ese bloque, y la Polka solía justificar el El nuevo PreCommit en la ronda R_2 debe realizarse en una ronda R_polka donde R_1 < R_polka <= R_2. En segundo lugar, validators deben proponer y/o PreVote el bloque en el que están bloqueados. Juntos, estos condiciones garantizan que un validator no realice una confirmación previa sin evidencia suficiente como justificación, y que validators que tienen PreCommit ya no puede contribuir con evidencia al PreCommit algo más. Esto garantiza tanto la seguridad como la vitalidad del algoritmo de consenso. Los detalles completos del protocolo se describen aquí. La necesidad de sincronizar todos los encabezados de los bloques se elimina en TendermintPoS ya que la existencia de una cadena alternativa (una bifurcación) significa ≥⅓ de la participación en condiciones de servidumbre puede reducirse drásticamente. Por supuesto, dado que cortar requiere que alguien comparta evidencia de una bifurcación, los clientes ligeros deben almacenar cualquier bloque-hash confirma que ve. Además, los clientes ligerospodría permanecer sincronizado periódicamente con los cambios en el conjunto validator, en para evitar ataques de largo alcance (pero otras soluciones son posible). En espíritu similar a Ethereum, Tendermint permite que las aplicaciones incrustar una raíz global de Merkle hash en cada bloque, lo que permite consultas de estado verificables para cosas como saldos de cuentas, el valor almacenado en un contrato, o la existencia de una transacción no gastada salida, dependiendo de la naturaleza de la aplicación. Suponiendo un conjunto de redes de difusión suficientemente resiliente y un conjunto estático validator, cualquier bifurcación en el blockchain puede ser detectado y los depósitos de los validators infractores cortados. esto La innovación, sugerida por primera vez por Vitalik Buterin a principios de 2014, resuelve el problema de nada en juego de otros proof-of-stake criptomonedas (ver Trabajo Relacionado). Sin embargo, dado que validator establece debe poder cambiar, durante un largo período de tiempo, el original validators pueden desvincularse y, por lo tanto, serían libres de crear una nueva cadena a partir del bloque de génesis, sin incurrir en ningún coste ya que ya no tienen depósitos bloqueados. Este ataque llegó a ser conocido como ataque de largo alcance (LRA), en contraste con un ataque de corto alcance. Range Attack, donde los validators que actualmente están vinculados causan un fork y, por lo tanto, son punibles (suponiendo que un BFT responsable de fork algoritmo como el consenso de Tendermint). Los ataques de largo alcance son A menudo se piensa que es un golpe crítico para proof-of-stake. Afortunadamente, el LRA se puede mitigar de la siguiente manera. Primero, por un validator para desvincularse (recuperando así su depósito de garantía) y ya no gana honorarios por participar en el consenso), el El depósito debe hacerse intransferible por un período de tiempo. conocido como “período de desvinculación”, que puede ser del orden de semanas o meses. En segundo lugar, para que un cliente ligero esté seguro, el primer vez que se conecta a la red debe verificar un bloque reciente-hash contra una fuente confiable, o preferiblemente múltiples fuentes. esto

Esta condición a veces se denomina “subjetividad débil”. Finalmente, Para permanecer seguro, debe sincronizarse con la última versión validator configurada en menos con tanta frecuencia como la duración del período de desvinculación. esto garantiza que el cliente ligero conozca los cambios en validator establecido antes de que un validator tenga su capital no vinculado y, por lo tanto, ya no en juego, lo que le permitiría engañar al cliente realizando un ataque de largo alcance creando nuevos bloques comenzando en un altura donde fue adherido (suponiendo que tenga control de suficiente muchas de las primeras claves privadas). Tenga en cuenta que superar al LRA de esta manera requiere una revisión de el modelo de seguridad original de proof-of-work. En PoW, es Se supone que un cliente ligero puede sincronizarse con la altura actual desde el bloque de génesis confiable en cualquier momento simplemente procesando la prueba de trabajo en cada encabezado de bloque. Sin embargo, para superar al LRA debemos requieren que un cliente ligero se conecte con cierta regularidad para realizar un seguimiento de los cambios en el conjunto validator y que la primera vez que se conectan, deben tener especial cuidado al autenticarse lo que escuchan de la red contra fuentes confiables. de Por supuesto, este último requisito es similar al de Bitcoin, donde El protocolo y el software también deben obtenerse de un proveedor de confianza. fuente. El método anterior para prevenir LRA es muy adecuado para validators y nodos completos de un blockchain impulsado por Tendermint porque estos Los nodos están destinados a permanecer conectados a la red. el El método también es adecuado para clientes ligeros de los que se puede esperar que sincronizar con la red con frecuencia. Sin embargo, para clientes ligeros que No se espera que tengan acceso frecuente a Internet o a la red. blockchain red, se puede utilizar otra solución para superar el ERS. Los titulares que no sean validator token pueden publicar sus token como garantía con un período de desvinculación muy largo (por ejemplo, mucho más largo que el período de desvinculación para validators) y atender a clientes ligeros con un método secundario para dar fe de la validez de la información actual y pasado bloque-hashes. Si bien estos tokens no cuentan para el seguridad del consenso de blockchain, no obstante puedenProporcionar fuertes garantías para clientes ligeros. Si bloque histórico-hash Las consultas fueron admitidas en Ethereum, cualquiera podría vincular sus tokens en un smart contract especialmente diseñado y proporcionar servicios de certificación de pago, creando efectivamente un mercado para la seguridad LRA de clientes ligeros. Debido a la definición de compromiso en bloque, cualquier ≥⅓ coalición de El poder de voto puede detener el blockchain si sale de la revista o no. difundir sus votos. Una coalición así también puede censurar transacciones particulares rechazando bloques que incluyen estos transacciones, aunque esto resultaría en una proporción significativa de propuestas en bloque que serán rechazadas, lo que ralentizaría el ritmo de confirmaciones de bloque del blockchain, reduciendo su utilidad y valor. La maliciosa coalición también podría difundir los votos a cuentagotas, de modo que en cuanto a moler el bloque blockchain se compromete a detenerse casi por completo o participar en cualquier combinación de estos ataques. Finalmente, puede provocar la blockchain a bifurcar, mediante doble firma o violando el bloqueo reglas. Si también estuviera involucrado un adversario globalmente activo, podría dividirse la red de tal manera que pueda parecer que el error El subconjunto de validators fue responsable de la desaceleración. esto no es solo una limitación de Tendermint, sino más bien una limitación de todos protocolos de consenso cuya red está potencialmente controlada por un adversario activo. Para este tipo de ataques, un subconjunto de validators debería coordinar a través de medios externos para firmar una propuesta de reorganización que elige una bifurcación (y cualquier evidencia de la misma) y el subconjunto inicial de validators con sus firmas. Los validadores que firman dicha propuesta de reorganización renuncian a su garantía en todas las demás bifurcaciones. Los clientes deben verificar las firmas en la propuesta de reorganización, verificar cualquier evidencia, y emitir un juicio o solicitar una decisión al usuario final. Para Por ejemplo, una aplicación de billetera telefónica puede solicitar al usuario una información de seguridad.

advertencia, mientras que un refrigerador puede aceptar cualquier propuesta de reorganización firmado por +½ de los validators originales por poder de voto. No puede surgir ningún algoritmo bizantino tolerante a fallas no síncrono al consenso cuando ≥⅓ del poder de voto es deshonesto, pero un tenedor supone que ≥⅓ del poder de voto ya ha sido deshonesto al doble firma o cambio de cerradura sin justificación. Entonces, firmando La propuesta de reorganización es un problema de coordinación que no puede solucionarse. resuelto por cualquier protocolo no síncrono (es decir, automáticamente, y sin hacer suposiciones sobre la confiabilidad de la red subyacente). Por ahora, dejamos el problema de la coordinación de propuestas de reorganización a la coordinación humana a través del consenso social. en los medios de internet. Los validadores deben tener cuidado de garantizar que haya No quedan particiones de red restantes antes de firmar una propuesta de reorganización, para evitar situaciones en las que se firmen dos propuestas de reorganización contradictorias. Suponiendo que el medio y protocolo de coordinación externa sea robusto, se deduce que las bifurcaciones son menos preocupantes que la censura ataques. Además de las bifurcaciones y la censura, que requieren ≥⅓ bizantinos poder de voto, una coalición de >⅔ de poder de voto puede comprometerse Estado arbitrario e inválido. Esto es característico de cualquier (BFT) sistema de consenso. A diferencia de la doble firma, que crea bifurcaciones con evidencia fácilmente verificable, detectando la comisión de un el estado no válido requiere pares no validadores para verificar bloques completos, lo que implica que guardan una copia local del estado y ejecutan cada transacción, calculando la raíz del estado de forma independiente para ellos mismos. Una vez detectado, la única manera de manejar tal falla es a través del consenso social. Por ejemplo, en situaciones donde Bitcoin ha fallado, ya sea que se haya bifurcado debido a errores de software (como en marzo 2013), o cometer un estado inválido debido al comportamiento bizantino de mineros (como en julio de 2015), la comunidad bien conectada de empresas, desarrolladores, mineros y otras organizaciones estableció un consenso social sobre qué acciones manuales eranrequerido por los participantes para sanar la red. Además, desde Se puede esperar que validators de un Tendermint blockchain sean identificable, el compromiso de un estado inválido puede incluso ser punible por la ley o alguna jurisprudencia externa, si así se desea. ABCI consta de 3 tipos de mensajes principales que se entregan desde el núcleo de la aplicación. La aplicación responde con mensajes de respuesta correspondientes. El mensaje  AppendTx  es el caballo de batalla de la aplicación. cada uno La transacción en el blockchain se entrega con este mensaje. el La aplicación necesita validar cada transacción recibida con el Mensaje AppendTx contra el estado actual, protocolo de aplicación, y las credenciales criptográficas de la transacción. Un validado La transacción luego necesita actualizar el estado de la aplicación, mediante vinculando un valor en un almacén de valores clave o actualizando el UTXO base de datos. El mensaje  CheckTx  es similar a AppendTx, pero es solo para validar transacciones. Primeros controles de mempool de Tendermint Core la validez de una transacción con CheckTx, y solo los relés son válidos transacciones con sus pares. Las aplicaciones pueden comprobar un incremento nonce en la transacción y devolver un error en CheckTx si el nonce es viejo. El mensaje  Commit  se utiliza para calcular una criptografía compromiso con el estado actual de la aplicación, que se colocará en el encabezado del siguiente bloque. Esto tiene algunas propiedades útiles. Las inconsistencias en la actualización de ese estado ahora aparecerán como blockchain bifurcaciones que captan toda una clase de programación errores. Esto también simplifica el desarrollo de sistemas ligeros y seguros. clientes, ya que las pruebas de Merkle-hash se pueden verificar cotejándolas el bloque-hash, y el bloque-hash está firmado por un quórum de validators (por poder de voto).

Los mensajes ABCI adicionales permiten que la aplicación realice un seguimiento de y cambiar el conjunto validator, y para que la aplicación reciba el información del bloque, como la altura y los votos de confirmación. ABCI solicitudes/respuestas son mensajes simples de Protobuf. comprobar fuera del esquema yle. Argumentos: Datos ([]byte): los bytes de la transacción de solicitud. Devoluciones: Código (uint32): código de respuesta Datos ([]byte): bytes de resultado, si los hay Registro (cadena): mensaje de error o depuración Uso:

Adjunte y ejecute una transacción. Si la transacción es válida, devuelve CodeType.OK Argumentos: Datos ([]byte): los bytes de la transacción de solicitud. Devoluciones: Código (uint32): código de respuesta Datos ([]byte): bytes de resultado, si los hay Registro (cadena): mensaje de error o depuración Uso:

Validar una transacción. Este mensaje no debe mutar el estado. Las transacciones se ejecutan por primera vez a través de CheckTx antes transmitir a pares en la capa de mempool. puedes hacer CheckTx semi-estado y borre el estado al confirmar o BeginBlock, para permitir secuencias dependientes de transacciones en el mismo bloque.

Devoluciones: Datos ([]byte): La raíz de Merkle hash Registro (cadena): mensaje de error o depuración Uso:

Devuelve una raíz de Merkle hash del estado de la aplicación. Argumentos: Datos ([]byte): los bytes de solicitud de consulta. Devoluciones: Código (uint32): código de respuesta Datos ([]byte): los bytes de respuesta a la consulta. Registro (cadena): mensaje de error o depuración Uso:

Vacíe la cola de respuestas. Aplicaciones que implementan tipos. La aplicación no necesita implementar este mensaje: es manejado por el proyecto. Devoluciones: Datos ([]byte): los bytes de información Uso:

Devuelve información sobre el estado de la aplicación. Solicitud específico. Argumentos: Clave (cadena): clave para configurar

Valor (cadena): valor que se establecerá para la clave Devoluciones: Registro (cadena): mensaje de error o depuración Uso:

Establecer opciones de aplicación. P.ej. Clave = “modo”, Valor = “mempool” para una conexión de mempool, o Clave=“modo”, Valor=“consenso” para una conexión de consenso. Otras opciones son específicas de la aplicación. Argumentos: Validadores ([]Validador): Génesis inicial-validators Uso:

Llamado una vez sobre la génesis Argumentos: Altura (uint64): la altura del bloque que comienza Uso:

Señala el comienzo de un nuevo bloque. Llamado antes de cualquier AnexarTxs. Argumentos: Altura (uint64): la altura del bloque que finalizó Devoluciones: Validadores ([]Validador): validators modificados con nuevos poderes de voto (0 para eliminar) Uso:

Señala el final de un bloque. Después de todo, se llama antes de cada compromiso. transacciones Consulte el repositorio ABCI para obtener más detalles.Hay varias razones por las que un remitente puede querer el acuse de recibo de la entrega de un paquete por parte de la cadena receptora. Por ejemplo, es posible que el remitente no conozca el estado del cadena de destino, si se espera que esté defectuosa. O bien, el remitente puede desea imponer un tiempo de espera al paquete (con el parámetro  MaxHeight  rendimiento del paquete), mientras que cualquier cadena de destino puede sufrir un ataque de denegación de servicio con un aumento repentino en el número de mensajes entrantes. paquetes. En estos casos, el remitente puede exigir acuse de entrega configurando el estado del paquete inicial en  AckPending . Entonces, es el responsabilidad de la cadena receptora de confirmar la entrega incluyendo un abreviado IBCPacket  en la aplicación Merkle hash. Primero, se publican  IBCBlockCommit  y  IBCPacketTx  en "Hub". que prueba la existencia de un IBCPaquete  en “Zona1”. di eso  IBCPacketTx  tiene el siguiente valor: DeChainID: "Zona1" FromBlockHeight: 100 (digamos) Paquete: un IBCPaquete:

Encabezado: un IBCPacketHeader: SrcChainID: “Zona1” DstChainID: “Zona2” Número: 200 (digamos) Estado: Confirmación pendiente Tipo: “moneda” MaxHeight: 350 (digamos que "Hub" está actualmente a una altura de 300) Carga útil: A continuación, se publican  IBCBlockCommit  y  IBCPacketTx  en "Zone2". que prueba la existencia de un IBCPaquete  en "Hub". di eso  IBCPacketTx  tiene el siguiente valor: FromChainID: "Centro" DesdeBlockHeight: 300 Paquete: un IBCPaquete: Encabezado: un IBCPacketHeader: SrcChainID: “Zona1” DstChainID: “Zona2” Número : 200 Estado: Confirmación pendiente Tipo: “moneda” Altura máxima: 350 Carga útil: A continuación, “Zone2” debe incluir en su aplicación-hash un paquete abreviado que muestra el nuevo estado de  AckSent . Un IBCBlockCommit  y  IBCPacketTx  se publican nuevamente en "Hub" que demuestra la existencia de un  IBCPaquete  abreviado en "Zone2". Di que IBCPacketTx  tiene el siguiente valor: DeChainID: "Zona2"

FromBlockHeight: 400 (digamos) Paquete: un IBCPaquete: Encabezado: un IBCPacketHeader: SrcChainID: “Zona1” DstChainID: “Zona2” Número : 200 Estado: Acuse de recibo Tipo: “moneda” Altura máxima: 350 PayloadHash: Finalmente, “Hub” debe actualizar el estado del paquete desde  Acuse de recibo pendiente a Acuse de recibo. Evidencias de este nuevo estatus analizado debería volver a "Zona2". Digamos que IBCPacketTx  tiene lo siguiente valor: FromChainID: "Centro" DesdeBlockHeight: 301 Paquete: un IBCPaquete: Encabezado: un IBCPacketHeader: SrcChainID: “Zona1” DstChainID: “Zona2” Número : 200 Estado: Acuse de recibo Tipo: “moneda” Altura máxima: 350 PayloadHash: Mientras tanto, “Zone1” puede asumir con optimismo una entrega exitosa de un paquete de "monedas" a menos que se demuestre lo contrario en “Centro”. En el ejemplo anterior, si "Hub" no hubiera recibido un  AckSent

estado de “Zona2” por el bloque 350, habría establecido el estado automáticamente al  Tiempo de espera . Esta evidencia de un tiempo de espera puede obtener se vuelve a publicar en "Zona1" y se puede devolver cualquier token. Hay dos tipos de Merkle trees admitidos en el Ecosistema Tendermint/Cosmos: El árbol simple y el IAVL+ Árbol. El árbol simple es un Merkle tree para una lista estática de elementos. si el número de elementos no es una potencia de dos, algunas hojas estarán en diferentes niveles. Simple Tree intenta mantener ambos lados del árbol misma altura, pero la izquierda puede ser una mayor. Este Merkle tree es utilizado para Merkle-izar las transacciones de un bloque, y el nivel superior elementos de la raíz del estado de la aplicación.El propósito de la estructura de datos IAVL+ es proporcionar información persistente almacenamiento para pares clave-valor en el estado de la aplicación, de modo que La raíz determinista de Merkle hash se puede calcular de manera eficiente. el El árbol se equilibra utilizando una variante del algoritmo AVL, y todos las operaciones son O (log (n)). En un árbol AVL, las alturas de los dos subárboles secundarios de cualquier nodo difieren como máximo en uno. Siempre que se viole esta condición por una actualización, el árbol se reequilibra creando O(log(n)) nuevos nodos que señalar los nodos no modificados del árbol viejo. En el AVL original algoritmo, los nodos internos también pueden contener pares clave-valor. El AVL+ algoritmo (tenga en cuenta el signo más) modifica el algoritmo AVL para mantener todos valores en los nodos hoja, mientras que solo se utilizan nodos de rama para almacenar claves. Esto simplifica el algoritmo manteniendo el rastro merkle hash corto. El árbol AVL+ es análogo a los intentos de Patricia de Ethereum. hay compensaciones. No es necesario hashed las claves antes de insertarlas en Árboles IAVL+, por lo que esto proporciona una iteración ordenada más rápida en la clave espacio que puede beneficiar algunas aplicaciones. La lógica es más sencilla implementar, requiriendo sólo dos tipos de nodos: nodos internos y nodos de las hojas. La prueba de Merkle es en promedio más corta, siendo una                 *                 / \               /     \             /         \           /             \          *               *         / \             / \        /   \           /   \       /     \         /     \      *       *       *       h6     / \     / \     / \    h0  h1  h2  h3  h4  h5    Un SimpleTree con 7 elementos

árbol binario equilibrado. Por otro lado, la raíz Merkle de un El árbol IAVL+ depende del orden de las actualizaciones. Admitiremos Merkle trees eficientes adicionales, como Patricia Trie de Ethereum cuando la variante binaria se convierte en disponible. En la implementación canónica, las transacciones se transmiten al Cosmos aplicación central a través de la interfaz ABCI. El Cosmos Hub aceptará una cantidad de transacciones principales tipos, incluidos  SendTx ,  BondTx ,  UnbondTx ,  ReportHackTx ,  SlashTx ,  BurnAtomTx ,  ProposalCreateTx  y  ProposalVoteTx , que se explican por sí solos y se documentarán en un revisión futura de este documento. Aquí documentamos los dos principales tipos de transacciones para IBC:  IBCBlockCommitTx  y  IBCPacketTx . Una transacción  IBCBlockCommitTx  se compone de: ChainID (cadena): el ID del blockchain BlockHash ([]byte): el bloque-hash bytes, la raíz de Merkle que incluye la aplicación-hash BlockPartsHeader (PartSetHeader): el encabezado del conjunto de piezas del bloque bytes, sólo necesarios para verificar las firmas de los votos BlockHeight (int): la altura de la confirmación BlockRound (int): la ronda de confirmación Comprometerse ([]Vote): El >⅔ Precommit de Tendermint vota que Comprende un compromiso de bloque. ValidatorsHash ([]byte): una raíz del árbol Merkle hash del nuevo validator conjunto

ValidatorsHashProof (SimpleProof): un SimpleTree Merkleproof para probar ValidatorsHash contra BlockHash AppHash ([]byte): una raíz del árbol IAVLTree Merkle hash del estado de la aplicación AppHashProof (SimpleProof): un SimpleTree Merkle a prueba de probando AppHash contra BlockHash Un  IBCPaquete  se compone de: Encabezado (IBCPacketHeader): el encabezado del paquete. Carga útil ([]byte): los bytes de la carga útil del paquete. Opcional PayloadHash ([]byte): el hash para los bytes del paquete. Opcional Debe estar presente uno de los tipos  Payload  o  PayloadHash . El hash de un IBCPaquete  es una raíz Merkle simple de los dos elementos,  Encabezado  y  carga útil . Un  IBCPacket  sin la carga útil completa se denomina paquete abreviado. Un  IBCPacketHeader  se compone de: SrcChainID (cadena): la fuente blockchain ID DstChainID (cadena): el ID de destino blockchain Número (int): un número único para todos los paquetes Estado (enum): puede ser uno de AckPending, AckSent, Confirmación recibida, No confirmación o tiempo de espera Tipo (cadena): los tipos dependen de la aplicación. Cosmos reserva el tipo de paquete "moneda" MaxHeight (int): si el estado no es NoAckWanted o AckReceived a esta altura, el estado pasa a ser Timeout. Opcional Una transacción  IBCPacketTx  se compone de:FromChainID (cadena): el ID del blockchain que es proporcionar este paquete; no necesariamente la fuente FromBlockHeight (int): la altura blockchain en la que se El siguiente paquete está incluido (Merkle-izado) en el bloque-hash de la cadena de origen Paquete (IBCPaquete): un paquete de datos, cuyo estado puede ser uno de AckPending, AckSent, AckReceived, NoAck o Timeout PacketProof (IAVLProof): un IAVLTree Merkle a prueba de pruebas el hash del paquete contra el AppHash de la cadena de origen en altura dada La secuencia para enviar un paquete de “Zona1” a “Zona2” a través del "Hub" se muestra en la {Figura X}. Primero, un  IBCPacketTx  demuestra al "Hub" que el paquete está incluido en el estado de la aplicación de “Zona1”. Luego, otro IBCPacketTx  le demuestra a "Zone2" que el El paquete está incluido en el estado de la aplicación de "Hub". Durante este procedimiento, los rendimientos del  IBCPacket  son idénticos: el  SrcChainID  es siempre "Zona1" y  DstChainID  siempre es "Zona2". El  PacketProof  debe tener la ruta correcta a prueba de Merkle, como sigue: Cuando “Zone1” quiere enviar un paquete a “Zone2” a través de “Hub”, los datos del IBCPacket son idénticos ya sea que el paquete esté Merkleizado en "Zone1", el "Hub" o "Zone2". El único yeld mutable es  Estado para el seguimiento de la entrega. Agradecemos a nuestros amigos y pares por su ayuda en la conceptualización, Revisar y brindar apoyo para nuestro trabajo con Tendermint. y Cosmos. IBC///

Zaki Manian de SkuChain brindó mucha ayuda para formatear y redacción, especialmente en la sección ABCI Jehan Tremback de Althea y Dustin Byington por ayudar con iteraciones iniciales Andrew Miller de Honey Badger por sus comentarios sobre el consenso Greg Slepak por sus comentarios sobre el consenso y la redacción También gracias a Bill Gleim y Seunghwan Han por varios contribuciones. Su nombre y organización aquí por su contribución. 1 Bitcoin: https://bitcoin.org/bitcoin.pdf 2CeroCash: http://zerocash-project.org/paper 3 Ethereum: https://github.com/ethereum/wiki/wiki/WhitePaper 4 ElDAO: https://download.slock.it/public/DAO/WhitePaper.pdf 5 Testigo Segregado: https://github.com/bitcoin/bips/blob/master/bip0141.mediawiki 6 BitcoinNG: https://arxiv.org/pdf/1510.02037v2.pdf 7 Red Lightning: https://lightning.network/lightningnetwork-paper-DRAFT-0.5.pdf 8 menta tierna: https://github.com/tendermint/tendermint/wiki 9 FLP Imposibilidad: https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf 10 Asesino: https://blog.ethereum.org/2014/01/15/slasher-apunitive-proof-of-stake-algorithm/ 11 PBFT: http://pmg.csail.mit.edu/papers/osdi99.pdf 12 bits compartidos: https://bitshares.org/technology/delegatedproof-of-stake-consensus/

13 Stellar: https://www.stellar.org/papers/stellar-consensusprotocol.pdf 14 Libro interior: https://interledger.org/rfcs/0001-interledgerarchitecture/ 15 cadenas laterales: https://blockstream.com/sidechains.pdf 16 Casper: https://blog.ethereum.org/2015/08/01/introducing-casperfriendly-ghost/ 17 ABCI: https://github.com/tendermint/abci 18 Ethereum Fragmentación: https://github.com/ethereum/EIPs/issues/53 19LibSwift: http://www.ds.ewi.tudelft.nl/yleadmin/pds/papers/Performa nceAnalysisOfLibswift.pdf 20 DLS: http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf 21 Seguridad del cliente ligero: https://en.bitcoin.it/wiki/Thin_Client_Security 22 Ethereum 2.0 Papel Malva: http://vitalik.ca/yles/mauve_paper.html https://www.docdroid.net/ec7xGzs/314477721-ethereumplatform-review-opportunities-and-challenges-for-privateand-consortium-blockchains.pdf.html

½ è