What is Tendermint Core? The Most Comprehensive Guide Ever

Ultimate Guide to Tendermint

¿Qué es Tendermint Core?...

Tiempo de lectura: 17 minutos

Cosmos es uno de los proyectos más prometedores. Con gente como Jae Kwon y Ethan Buchman en su equipo, tiene mucho potencial. En su corazón y alma se encuentra Tendermint Core.

Ultimate Guide to Tendermint

Tendermint Core combina el algoritmo de consenso de Tendermint junto con un protocolo de chismes p2p. Entonces, cuando lo pones todo junto en la pila de software, obtienes el Tendermint Core junto con la capa de aplicación Cosmos-SDK.

De todos modos, así que antes de ir más allá, veamos por qué Tendermint es una necesidad.

Bitcoin y Blockchain

Cuando Satoshi Nakamoto creó Bitcoin, hizo el primer sistema criptográfico descentralizado de la historia. La parte realmente notable de este descubrimiento fue que fue capaz de resolver el problema del general bizantino que ayudó a una red de área amplia (WAN) a llegar a un consenso en un entorno sin confianza. Bitcoin utilizó el algoritmo de prueba de trabajo para cuidar de su consenso.

Dicho esto, la principal contribución de Bitcoin puede muy bien ser el hecho de que introdujo todo el mundo a la tecnología blockchain.

Una cadena de bloques es, en el más simple de los términos, una serie de registro inmutable de datos que es administrada por un clúster de computadoras que no son propiedad de ninguna entidad. Cada uno de estos bloques de datos (es decir, bloque) están protegidos y enlazados entre sí mediante principios criptográficos (es decir, cadena).

En otras palabras, una cadena de bloques es una máquina de estado determinista replicada en nodos que no necesariamente confían entre sí.

Por determinista queremos decir que si se toman los mismos pasos específicos, entonces siempre conducirá al mismo resultado.

Por ejemplo. 1 + 2 siempre será 3.

Entonces, ¿qué significa estado? Echemos un vistazo a Bitcoin y Ethereum.

En Bitcoin, el estado es una lista de saldos para cada cuenta, que es una lista de salida de transacciones no gastadas (UTXO). Este estado se modifica a través de transacciones que cambian el saldo.

Por otro lado, en Ethereum, la aplicación es una máquina virtual que ejecuta contratos inteligentes. Cada transacción pasa a través de la máquina virtual de Ethereum y modifica el estado de acuerdo con el contrato inteligente específico que se llama dentro de ella.

Si nos fijamos en la arquitectura de la tecnología blockchain, entonces usted tendrá tres capas específicas:

Redes: La propagación de la transacción/información a través de los nodos

Consenso: Permite que los nodos lleguen a una decisión siempre que 2/3rd de los nodos no sean maliciosos

Aplicación: Responsable de actualizar el estado dado un conjunto de transacciones, es decir, procesar transacciones. Dada una transacción y un estado, la aplicación devolverá un nuevo estado.

Para señales visuales:

Problemas con la arquitectura actual de Blockchain

Resulta que construir una cadena de bloques desde cero con todas estas 3 capas es un trabajo realmente duro. Por lo tanto, muchos proyectos prefirieron construir bifurcando la base de código Bitcoin. Ahora bien, aunque esto ahorra mucho tiempo, el hecho es que todavía están esposados por las limitaciones del protocolo Bitcoin. Obviamente, no se pueden ejecutar proyectos complejos cuando se utiliza un protocolo que es conocido por sus problemas de rendimiento.

Las cosas se pusieron mucho mejor cuando Ethereum entró en juego. Ethereum realmente dio a los desarrolladores una plataforma que podrían usar para crear su propio código personalizado también conocido como contratos inteligentes y proyectos. Sin embargo, al igual que con Bitcoin, Ethereum también sufre el mismo problema. Ambos tienen arquitectura monolítica en lugar de modular.

Arquitectura monolítica vs Arquitectura modular

La arquitectura monolítica significa que todo está compuesto en una sola pieza. Cuando el software se considera “monolítico” los componentes están interconectados e interdependientes entre sí y el diseño es más autónomo. En este caso, la arquitectura está más estrechamente acoplada y los componentes asociados deben estar todos presentes para que el código sea ejecutado o compilado.

Aunque esto hace que el sistema para el que fue creado sea más robusto, realmente no se puede derivar de él y crear códigos personalizados. No es el más flexible de los sistemas. Además, hay otro problema con este sistema. Si algún componente del programa necesita ser actualizado, toda la aplicación tendrá que ser reelaborada. Esta no es realmente la más ideal de las situaciones ahora, ¿verdad?

Por otro lado, tenemos arquitectura modular. A diferencia de Monolítico, las capas no están vinculadas entre sí. Por lo tanto, aunque puede no ser tan robusto, es bastante fácil actualizar toda la aplicación trabajando con los diferentes módulos separados.

Dado que los módulos son tan independientes, la arquitectura modular le permite actualizar realmente una sección en particular sin causar cambios imprevistos en el resto del sistema. Los procesos iterativos también son mucho más simples en programas modulares, en lugar de monolíticos.

Arquitectura y objetivos de Tendermint

Tendermint utiliza la arquitectura modular. Sus objetivos son los siguientes:

Proporcionar las capas de redes y consenso de una cadena de bloques como una plataforma donde se pueden construir diferentes aplicaciones descentralizadas

Los desarrolladores solo necesitan preocuparse por la capa de aplicación de la cadena de bloques, ahorrando todas las horas que habrían desperdiciado trabajando en el consenso y en la capa de redes también.

Tendermint también incluye el protocolo de consenso Tendermint que es el algoritmo bizantino de consenso tolerante a fallos utilizado en el motor Tendermint Core

Veamos cómo se verá la arquitectura de Tendermint:

Ultimate Guide to Tendermint

Como puede ver, la aplicación está conectada a Tendermint Core a través de un protocolo de socket llamado APCI o Application Blockchain Interface. Dado que Tendermint Core y la aplicación que se ejecuta en él se ejecutan en procesos UNIX separados, necesitan tener un método para hablar entre sí. ABCI ayuda a estos dos en su comunicación.

Entonces, ¿cómo es el diseño de ABCI? ABCI tendrá algunos componentes de diseño distintos:

Protocolo de mensajes #1

Pares de mensajes de solicitud y respuesta

Las solicitudes se hacen por consenso, mientras que la aplicación se encarga de la respuesta

Se define usando protobuf

#2 Servidor/cliente

El motor de consenso ejecuta el cliente

La aplicación ejecuta el servidor

Hay dos implementaciones adecuadas: bytes sin procesar asincrónicos y grpc

#3 Protocolo Blockchain

ABCI está muy orientado a la conexión. Las tres conexiones para Tendermint Core son las siguientes:

Conexión de Mempool: Esto comprueba si las transacciones deben ser retransmitidas antes de que se comprometan. Solo puede usar CheckTX

Conexión de consenso: Esta conexión ayuda en la ejecución de transacciones que se han comprometido. La secuencia de mensajes es, para cada bloque, BeginBlock, [DelivertX,...], EndBlock, Commit

Conexión de consulta: Ayuda a consultar el estado de la aplicación. Esta parte solo usa Consulta e Información

En definitiva, el objetivo principal de Tendermint es proporcionar a los desarrolladores una herramienta que no solo sea práctica, sino que también tenga un alto rendimiento. Aquí están las propiedades de Tendermint que lo hace tan atractivo:

#1 Compatible con Blockchain público o privado

Diferentes proyectos tienen necesidades diferentes. Algunos proyectos necesitan tener un sistema abierto donde cualquiera pueda unirse y contribuir, como Ethereum. Por otro lado, tenemos organizaciones como la Industria Médica, que no pueden exponer sus datos a casi todos. Para ellos, requieren algo como la cadena de bloques permisible.

Ok, entonces, ¿cómo puede Tendermint ayudar a satisfacer ambas necesidades? Recuerde que Tendermint solo maneja la red y el consenso para la cadena de bloques. Por lo tanto, ayuda en el:

Propagación de la transacción entre los nodos a través del protocolo de chismes

Ayuda a los validadores a ponerse de acuerdo en el conjunto de transacciones que se agrega a la cadena de bloques.

Lo que esto significa es que la capa de aplicación es libre de definirse de cualquier manera que los desarrolladores quieran que se defina. Los desarrolladores deben definir cómo se define el conjunto de validadores dentro del ecosistema.

Los desarrolladores pueden permitir que la aplicación tenga un sistema electoral que elija validadores en función de cuántos tokens nativos estos validadores han apostado dentro del ecosistema.. aka Prueba de estaca y crear una cadena de bloques pública

Además, los desarrolladores también pueden crear una aplicación que defina un conjunto restringido de validadores pre-aprobados que se ocupan del consenso y de los nuevos nodos que llegan a entrar en el ecosistema. Esto se llama prueba de autoridad y es el sello distintivo de una cadena de bloques permisionada o privada.

#2 Alto Rendimiento

Las aplicaciones realizadas a través de Tendermint Core pueden esperar un rendimiento excepcional. Tendermint Core tiene un tiempo de bloqueo de solo 1 segundo. También puede manejar un volumen de transacción de 10.000 transacciones por segundo para transacciones de 250 bytes, siempre y cuando la aplicación le permita hacerlo.

#3 Finalidad

¿Qué es la finalidad?

En términos simples, significa que una vez que una determinada acción ha sido ejecutada, no puede ser retomada. Por lo tanto, tomemos el ejemplo de una simple transacción financiera. Supongamos que usted compra algunas acciones en una empresa, sólo porque un fallo en su sistema, no debe perder la propiedad de sus acciones. Como se puede imaginar, la finalidad es súper crítica para un sistema financiero. Imagine hacer una transacción de un millón de dólares y luego al día siguiente, esa transacción ya no es válida debido a un fallo.

Como hemos mencionado antes, Bitcoin y Ethereum (hasta la implementación completa de Casper FFG) realmente no tienen finalidad de liquidación. Con motivo de un hardfork o un 51% de ataque, las transacciones tienen la posibilidad de ser revertidas.

La menta, por otro lado, da una finalidad instantánea dentro de 1 segundo después de la finalización de la transacción. Las horquillas nunca se crean en el sistema, siempre y cuando menos de 2/3rd de los validadores sean maliciosos. Tan pronto como se crea un bloque (que está dentro de un segundo) los usuarios pueden estar seguros de que su transacción está finalizada.

#4 Seguridad

Tendermint es seguro y obliga a sus participantes a ser responsables de sus acciones también. Como hemos dicho antes, la hierbabuena nunca se puede bifurcar siempre que menos de 2/3rd de los validadores sean maliciosos. Si en algún caso, la cadena de bloques hace tenedor, hay una manera de determinar la responsabilidad. Además, el consenso de Tendermint no solo es tolerante a fallas, sino que es óptimamente bizantino tolerante a fallas

#5 Fácil de usar

Otra gran cosa de Tendermint es su facilidad de uso. Como hemos mencionado anteriormente, tienen una arquitectura modular donde la capa de aplicación se puede personalizar adecuadamente. Esto hace posible que las bases de código de blockchain existentes se vinculen sin esfuerzo a Tendermint a través de ABCIs. El ejemplo perfecto de esto es Etheremint que es básicamente el enchufe de base de código de máquina virtual Ethereum en la parte superior de Tendermint.

Ethermint funciona exactamente como Ethereum, pero también se beneficia de todas las características positivas que hemos enumerado anteriormente. Todas las herramientas de Ethereum como Metamask y Truffle son compatibles con Ethermint.

#6 Escalabilidad

La implementación de prueba de participación de Tendermint es mucho más escalable que un algoritmo de consenso de prueba de trabajo tradicional. La razón principal es que los sistemas basados en polvo no pueden hacer fragmentación.

El particionar básicamente particiona horizontalmente una base de datos y crea bases de datos o fragmentos más pequeños que luego son ejecutados paralelamente por los nodos. La razón es que un grupo minero fuerte puede hacerse cargo fácilmente de un fragmento.

Tendermint permitirá la implementación de la fragmentación que aumentará en gran medida la escalabilidad.

Protocolo de consenso sobre la menta

Bien, veamos cómo funciona el protocolo de consenso Tendermint. ¿Qué es exactamente un protocolo de consenso?

Así es como Wikipedia define la toma de decisiones consensuadas:

“La toma de decisiones por consenso es un proceso de toma de decisiones grupales en el que los miembros del grupo se desarrollan y acuerdan apoyar una decisión en el interés superior del conjunto. El consenso puede definirse profesionalmente como una resolución aceptable, que puede ser apoyada, aunque no sea la “favorita” de cada individuo. “Consenso” es definido por Merriam-Webster como, primero, acuerdo general, y segundo, solidaridad de grupo de creencias o sentimientos.”

En términos más simples, el consenso es una forma dinámica de llegar a un acuerdo en un grupo. Si bien votar sólo se establece para un gobierno mayoritario sin pensar en los sentimientos y el bienestar de la minoría, un consenso, por otro lado, asegura que se llegue a un acuerdo que beneficie a todo el grupo en su conjunto.

Desde un punto de vista más idealista, el Consenso puede ser utilizado por un grupo de personas dispersas por todo el mundo para crear una sociedad más equitativa y justa.

Un método mediante el cual se logra la adopción de decisiones por consenso se denomina “mecanismo de consenso”.

Así que ahora lo que hemos definido lo que es un consenso, veamos cuáles son los objetivos de un mecanismo de consenso (datos tomados de Wikipedia).

Búsqueda de acuerdos: Un mecanismo de consenso debería lograr el mayor acuerdo posible por parte del grupo.

Colaborativo: Todos los participantes deben tratar de trabajar juntos para lograr un resultado que ponga el mejor interés del grupo en primer lugar.

Cooperativa: Todos los participantes no deben poner sus propios intereses en primer lugar y trabajar en equipo más que en individuos.

Participativa: El mecanismo de consenso debe ser tal que todos participen activamente en el proceso general.

Inclusive: El mayor número posible de personas debería participar en el proceso de consenso. No debería ser como un voto normal donde la gente realmente no tiene ganas de votar porque creen que su voto no tendrá ningún peso a largo plazo.

Igualitario: Un grupo que trate de lograr el consenso debe ser lo más igualitario posible. Lo que esto significa básicamente que todos y cada uno de los votos tienen el mismo peso. El voto de una persona no puede ser más importante que el de otra.

Ahora que hemos definido qué mecanismos de consenso son y a qué deben aspirar, tenemos que pensar en el otro elefante de la sala.

Qué mecanismos de consenso se deben usar para una entidad como blockchain.

Antes de Bitcoin, había un montón de iteraciones de sistemas de moneda descentralizados peer-to-peer que fallaron porque no pudieron responder al mayor problema a la hora de llegar a un consenso. Este problema se llama “Problema de Generales Bizantinos”.

Problema del general bizantino

Para hacer cualquier cosa en una red peer-to-peer, todos los nodos deben ser capaces de llegar a un consenso. La cosa es, sin embargo, para que este sistema funcione, pone mucho énfasis en que las personas actúen en el mejor interés de la red general. Sin embargo, como ya sabemos, la gente no es realmente confiable cuando se trata de actuar de manera ética. Aquí es donde entra en juego el problema del general bizantino.

Ultimate Guide to Tendermint

Imagina esta situación.

Hay un ejército alrededor de un castillo bien fortificado. La única manera de ganar es si atacan el castillo juntos como una unidad. Sin embargo, se enfrentan a un gran problema. El ejército está muy separado el uno del otro y los generales no pueden comunicarse directamente y coordinar el ataque y algunos de los generales están corruptos.

Lo único que pueden hacer es enviar un mensajero de general a general. Sin embargo, muchas cosas podrían pasarle al mensajero. Los generales corruptos pueden interceptar al mensajero y cambiar el mensaje. Entonces, ¿qué pueden hacer los generales para asegurarse de que lancen un ataque coordinado sin depender de la ética de cada general individual? ¿Cómo pueden llegar a un consenso sin confianza para hacer lo que hay que hacer?

Ese es el problema del general bizantino y Satoshi Nakamoto resolvió este problema utilizando el mecanismo de consenso de prueba de trabajo (POW).

¿Qué es la prueba de trabajo?

Vamos a comprobar cómo POW funciona con el contexto de nuestro ejemplo dado anteriormente. Supongamos que un general quiere comunicarse con otro general. ¿Cómo crees que va a caer?

Se añade un “nonce” al mensaje original. El nonce es un valor hexadecimal aleatorio.

Este nuevo mensaje es entonces hash. Supongamos que los generales acuerdan de antemano que solo enviarán mensajes, que cuando se hash comienza con 4 “0 's.

Si el hash no da el número deseado de 0s, el nonce se cambia y el mensaje se hash de nuevo. Este proceso sigue repitiendo hasta que se recibe el hash deseado.

Todo el proceso consume mucho tiempo y consume mucha potencia computacional.

Ahora, cuando finalmente obtienen el valor hash, al mensajero se le da el mensaje original y el nonce y se le dice que se comunique con los otros generales. Entonces, ¿qué pasa si alguien intenta interceptar el mensaje? Bueno, ¿recuerdas el efecto avalancha de las funciones hash? El mensaje cambiará drásticamente y ya que ya no comenzará con el número requerido de “0's”, la gente se dará cuenta de que el mensaje ha sido manipulado.

Entonces, para poner POW en el contexto de la minería criptográfica:

Los mineros intentan resolver puzzles criptográficos para agregar un bloque a la cadena de bloques.

El proceso requiere mucho esfuerzo y poder computacional.

Los mineros presentan su bloque a la red bitcoin.

La red luego verifica la autenticidad del bloque simplemente verificando el hash, si es correcto, entonces se agrega a la cadena de bloques.

Por lo tanto, descubrir el nonce y el hash requeridos debería ser difícil, sin embargo, verificar si es válido o no debería ser simple. Esa es la esencia de la prueba de trabajo.

Ahora, probablemente se esté preguntando, ¿por qué deberían los mineros sacrificar su tiempo y recursos para extraer bitcoins? Bueno, resulta que tienen un incentivo económico bastante saludable:

Cuando descubres un bloque, recibes una recompensa de 12,5 bitcoins. La recompensa se reduce a la mitad cada 210.000 bloques.

Una vez que has extraído un bloque, te conviertes en el dictador temporal del bloque. Usted es el responsable de poner las transacciones dentro del bloque y, por lo tanto, tiene derecho a las comisiones de transacción.

Solo hay un número limitado de bitcoins por ahí, 21 millones para ser exactos. Entonces, ¿qué impide a estos mineros extraer todos los bitcoins a la vez?

Resulta que la minería de bitcoin se vuelve progresivamente más difícil con el tiempo. Esta característica se llama “dificultad”, y la dificultad de la minería sigue aumentando a medida que continúa en la minería.

Esta es la razón por la que hoy en día es casi imposible que los mineros en solitario minen bitcoins usando solo sus computadoras. Los mineros han unido sus fuerzas y creado “piscinas mineras” para aunar su poder computacional y explotar como un grupo. Estos grupos utilizan ASIC (Application-Specific Integrated Circuits) creados específicamente para la minería para extraer bitcoins.

Problemas con POW

Hay tres problemas principales con los algoritmos de prueba de trabajo. Ya hemos hablado de esto en detalle antes, así que vamos a hacer una visión general.

Despilfarro de energía: Bitcoin consume más energía que Irlanda y la República Eslovaca. Este enorme desperdicio de energía es uno de los principios de Bitcoin. Es un desperdicio por el bien del desperdicio.

Centralización: Como ya le hemos dicho, Bitcoin utiliza ASIC para la minería. El problema con eso es que los ASIC son caros, y los grupos con más dinero tienden a tener más ASIC y, en consecuencia, más energía minera. Como tal, Bitcoin no está tan descentralizado como quiere ser.

Escalabilidad: La arquitectura misma de POW impide la escalabilidad. Bitcoin gestiona solo 7 transacciones por segundo. Para un sistema financiero moderno, simplemente no es lo suficientemente adecuado.

Introducir Tendermint

Así, para contrarrestar los muchos problemas con el sistema de consenso de prueba de trabajo, Jae Kwon, graduada en informática e ingeniería de sistemas, creó Tendermint. Tendermint es un protocolo puramente basado en BFT, construido en un entorno sin permisos con el Proof-of-of-Stake (PO) como el mecanismo de seguridad subyacente.

Debido a la complejidad, Tendermint ha tardado casi 4 años en completarse.

Jae Kwon y el director técnico de Tendermint Ethan Buchman se inspiraron en Raft y PBFT para crear un sistema de consenso que satisfizo el problema del general bizantino. Lo es.

“modelado como un protocolo determinista, viven bajo sincronía parcial, que logra el rendimiento dentro de los límites de la latencia de la red y de los propios procesos individuales.”

Muy bien, sabemos que es un montón de palabras complicadas para lanzar una tras otra, pero para entender qué es el consenso de Tendermint y por qué fue diseñado de la manera en que fue diseñado, es necesario entender lo que significan algunos de esos términos complicados. Verás cómo todos se unen entre sí como un intrincado rompecabezas.

#1 Imposibilidad FLP

La imposibilidad de FLP (Fischer Lynch Paterson) establece que un algoritmo de consenso sólo puede tener 2 de las siguientes 3 propiedades:

Seguridad

Rescisión o vida garantizada

Tolerancia a fallas

Ultimate Guide to Tendermint

Crédito de la imagen: Medio

En otras palabras, la imposibilidad del FLP establece que

“tanto la terminación como el acuerdo (vida y seguridad) no se pueden satisfacer de manera temporal en un sistema distribuido asíncrono, si se quiere ser resistente a al menos una falla (prueban su resultado para la tolerancia a fallas general, que es más débil que la tolerancia a fallas bizantina, ya que solo requiere una nodo fail-stop, por lo que BFT se incluye dentro de las reclamaciones de imposibilidad FLP).”

Por lo tanto, básicamente, es bastante imposible que una WAN asincrónica llegue a un consenso, ya que no hay cantidad específica de tiempo que los nodos tardarán en recibir, procesar y responder a los mensajes. Esto es obviamente un gran problema porque es extremadamente poco práctico que una gran red de nodos como Bitcoin asuma que se van a sincronizar.

Ok, entonces la sincronicidad iba a ser un problema. Sin embargo, los investigadores Dwork, Lynch y Stockmeyers lanzaron una línea de vida aquí con su artículo llamado “Consenso en la Presencia de la Sincronía Parcial”. Esto se llamó consenso DLS.

#2 Consenso DLS y sincronocidad parcial

El documento DLS establece que entre un sistema síncrono y un sistema asíncrono, existe un sistema especial que es “parcialmente sincrónico”. Dado que este sistema parcialmente sincrónico puede tener un tiempo límite superior dado, será capaz de diseñar un protocolo BFT viable.

Según DLS, el verdadero desafío en el diseño de protocolos es tener uno que funcione correctamente en un sistema parcialmente sincrónico.

Entonces, veamos cómo funcionan los protocolos descentralizados populares como Bitcoin y Ethereum en ese sentido.

Bitcoin tiene un límite superior conocido que es de alrededor de 10 minutos. Por lo tanto, se produce un bloque de transacciones cada 10 minutos. Esta suposición de tiempo se impone en la red para que los nodos tengan 10 minutos enteros para recopilar la información y transmitirla a través de chismes.

What is the State machine?

Por otro lado, tenemos Ethereum que hace suposiciones de sincronía para sus bloques y red manteniendo un tiempo de bloque superior en 15 segundos. Con un tiempo de bloque tan bajo, son más escalables que Bitcoin, sin embargo, no son realmente tan eficientes. Los mineros de Ethereum producen muchos bloques huérfanos.

#3 La vida y la terminación

La terminación es una propiedad que establece que cada procesador correcto eventualmente debe tomar una decisión. La mayoría de los algoritmos de consenso, que tenemos ahora, dependen de modelos sincrónicos para su seguridad y terminación. Tienen límites fijos y reglas que se conocen, por lo que, en el caso de que no se sostengan, la cadena se bifurca en múltiples protocolos

Seguro que hay protocolos de consenso que funcionan en redes asincrónicas, sin embargo, pasando por el teorema de imposibilidad FLP, no pueden ser deterministas. Lo que nos lleva a....

#4 Protocolos deterministas vs. no deterministas

Por lo general, los protocolos de consenso puramente asíncrono dependen de miembros no deterministas tales como los oráculos que implican un alto grado de incertidumbre y complejidad.

Entonces, ¿cómo lidia la menta con todos estos factores?

Tendermint es un consenso BFT en su mayoría asíncrono, determinista, donde los validadores tienen una participación que denota su poder de voto. En el triángulo de imposibilidad FLP, prefiere la tolerancia a fallas y la seguridad (consistencia) sobre la vida.

Tendermint oscila constantemente entre períodos de sincronía y asincronía. Esto significa que, si bien se basa en supuestos de temporización para avanzar, la velocidad de dicho progreso no depende de los parámetros del sistema, sino que depende de la velocidad real de la red.

Además, Tendermint nunca se bifurca en presencia de asincronía si menos de 1/3 de los validadores son corruptos/descuidados. Esta es la misma razón por la que Tendermint es tolerante a fallas bizantinas. Como hemos dicho antes, Tendermint se centra en la seguridad por encima de la vida. Por lo tanto, si más de un tercio de los validadores son maliciosos, en lugar de la bifurcación de la red, la cadena de bloques Tendermint simplemente se detendrá temporalmente hasta que más 2/3rd validadores lleguen a un consenso.

La menta también es completamente determinista y no hay aleatoriedad en el protocolo. Los líderes en el sistema son elegidos en una versión determinista, a través de una función matemática definida. Por lo tanto, podemos demostrar matemáticamente que el sistema se comporta de la manera en que se supone que debe comportarse.

Tendermint - El sistema de prueba de estaca

En un sistema de prueba de estaca (POS), tenemos ciertas personas llamadas “validadores”. Estos validadores encierran una estaca dentro del sistema. Después de eso, tienen la responsabilidad de apostar en el bloque que sienten que se va a agregar junto a la cadena de bloques. Cuando se agrega el bloque, obtienen una recompensa proporcional a su apuesta.

Muy bien, así es como funciona un punto de venta genérico. Ahora, veamos cómo funciona la menta.

Primero vamos a familiarizarnos con algunos de los términos que vamos a utilizar:

Una red se compone de muchos nodos. Los nodos que están conectados a un nodo determinado se llaman sus pares.

El proceso de consenso tiene lugar a una altura de bloque particular H. El proceso para determinar el siguiente bloque consiste en múltiples rondas.

La ronda consta de muchos estados que son: NewHeight, Proponer, Prevotar, Precomprometer y Commit. Cada estado se llama un Roundstep o simplemente “paso”.

Se dice que un nodo está a una altura, redondeo y paso dados, o en (H, R, S), o en (H, R) en resumen para omitir el paso.

Prevotar o precomprometer algo significa emitir un voto previo a la votación o precomprometer un voto por algo.

Cuando un bloque obtiene 2/3 de los votos previos en (H, R), entonces se llama prueba de bloqueo de cambio o polC.

¿Qué es la máquina estatal?

La máquina estatal es el motor del protocolo Tendermint, por así decirlo. El siguiente diagrama le da una buena idea de cómo se verá:

What is the State machine?

Ok, entonces, ¿qué está pasando aquí?

¿Recuerdas los estados por los que pasa cada ronda? NewHeight, Proponer, Prevotar, Precomprometer y Comprometer.

De ellos, “Proponer, Prevotar, Precomprometer” consisten en una ronda, mientras que las otras dos son rondas especiales. En un escenario ideal, la transición estatal actuaría así:

newHeight - (Proponer - Prevotar - Precomprometer) + - Comprometer - NewHeight -...

Sin embargo, no es así como siempre puede funcionar. Es posible que se requieran varias rondas antes de confirmar el bloque. Las siguientes son las razones por las que pueden ser necesarias varias rondas:

El proponente designado puede estar ausente.

El bloque propuesto tal vez no válido.

El bloque no se propagó a tiempo.

2/3 de los votos previos no fueron recibidos a tiempo por los nodos del validador.

Aunque + 2/3 de los votos previos son necesarios para avanzar al siguiente paso, al menos un validador puede haber votado cero o haber votado maliciosamente por otra cosa.

2/3 de las confirmaciones previas para el bloque no se recibieron aunque se hayan recibido prevotos.

¿Qué sucede durante cada estado?

Muy bien... así que ahora vamos a mirar en todos y cada uno de los estados y ver cómo todo se junta.

Proponérselo

En esta etapa, el proponente designado, es decir, el nodo seleccionado, propone un bloque que se añadirá en (H, R). Esta etapa termina de una de dos maneras:

El bloque se propone y eso entra en la fase previa a la votación.

El tiempo del proponente para elegir el bloque expira en el que entra en la fase previa a la votación de todos modos.

Prevota

Ahora llegamos a la fase previa a la votación. En esta etapa, cada validador necesita tomar una decisión.

Si de alguna manera, el validador está bloqueado en un bloque propuesto de alguna ronda anterior, automáticamente firman y transmiten ese bloque.

Si el validador había recibido una propuesta aceptable para la ronda actual, entonces firman y emitieron un prevoto para el bloque propuesto.

Sin embargo, si encuentran algo sospechoso con la propuesta o no han recibido ninguna propuesta en absoluto (por ejemplo, si el tiempo del proponente se agota), entonces firman con un prevoto nulo.

Durante esta etapa no se produce ningún bloqueo de bloques.

Durante este período, todos los nodos propagan los votos previos por todo el sistema a través del protocolo de chismes.

Preenvío

Ahora entramos en el paso final de la “ronda” llamada “precommit”. Al entrar en esta etapa, los validadores se comprometen previamente a su decisión emitiendo sus votos previos. Puede ocurrir uno de los tres escenarios siguientes:

Si el validador recibe 2/3 de los votos previos para un determinado bloque aceptable, el validador firma la sesión y transmite su preconfirmación al bloque. También están encerrados en ese bloque. Un validador puede bloquear solo un bloque a la vez.

Sin embargo, si el validador recibe más de 2/3rd de los prevotaciones NUL, entonces se desbloquean y los precommits se convierten en “NIL”.

Finalmente, si no han recibido una supermayoría de 2/3er en absoluto, entonces no firman o bloquean nada.

A lo largo de esta etapa, los nodos siguen chismeando continuamente sobre las confirmaciones previas en toda la red.

Al final, si el bloque propuesto obtiene más de 2/3rd precommits, entonces nos movemos hacia el paso “Commit”. Sin embargo, si no llegan a esa etapa, entran en la etapa “Proponer” de la siguiente ronda.

Cometer

El estado Commit no forma parte de la “ronda”. Junto con NewHeight, es una de las dos rondas especiales. Durante el estado de confirmación, se comprueban dos condiciones paralelas para ver si se cumplen o no.

En primer lugar, los validadores deben recibir el bloque previamente comprometido por la red. Una vez hecho esto, firman y transmiten su compromiso.

En segundo lugar, deben esperar hasta que hayan recibido al menos 2/3ª preconfirmaciones para el bloque.

Una vez hecho esto, el bloque se compromete a la red.

Newheight

Simplemente incrementa la altura del bloque en 1 para mostrar que se ha añadido el bloque.

Elección de los validadores

Como ya habrán entendido, elegir el conjunto inicial de validadores es fundamental para que el Cosmos funcione. Entonces, ¿cómo exactamente van a ser elegidos?

A diferencia de Bitcoin, donde cualquiera puede convertirse en minero en cualquier momento, sólo hay tantos validadores que el sistema Tendermint puede aceptar. Dado que los validadores necesitarán realizar una gran cantidad de funciones individualmente, aumentar el número de validadores solo dará lugar a retrasos.

Esta es la razón por la que Cosmos decidió elegir 100 validadores durante el día del Génesis (es decir, el día de la recaudación de fondos). El número de validadores aumentará en un 13% cada año hasta 10 años, cuando se asentará en 300.

Ultimate Guide to Tendermint

Entonces, ¿qué pasa con los resultados?

Como dice el documento técnico del cosmos:

“Tendermint ofrece un rendimiento excepcional. En los puntos de referencia de 64 nodos distribuidos en 7 centros de datos en 5 continentes, en instancias de nube de materias primas, el consenso de Tendermint puede procesar miles de transacciones por segundo, con latencias de compromiso en el orden de uno a dos segundos. Cabe destacar que el desempeño de más de mil transacciones por segundo se mantiene incluso en duras condiciones adversarias, con validadores chocando o emitiendo votos malintencionados.”

El gráfico que figura a continuación apoya la reclamación formulada anteriormente:

Casper vs Tendermint

Junto con Tendermint, Casper es otra implementación popular del protocolo POS.

Mientras Tendermint se centra en la seguridad, Casper se centra en la vida, por la imposibilidad del FLP. Entonces, ¿qué pasa en Casper durante un tenedor?

Casper FFG permitirá que una cadena de bloques continúe siendo construida, mientras que también tiene la propiedad de que todos los nodos serán conscientes de que esta cadena no está finalizada. Por lo tanto, la cadena de bloques puede permanecer disponible sin ninguna finalidad. Los validadores de la cadena tienen la opción de moverse a la cadena bifurcada. Si más de 2/3rd de los validadores votan, entonces cambian de cadena.

Además, Casper tiene un famoso mecanismo de corte. Cualquier tipo de ataque malicioso conducirá a que los validadores tengan su apuesta al instante.

Conclusión

Así que, ahí lo tienes. Esperamos que le hayamos dado tanta información valiosa como sea posible. ¿Qué opinas de Tendermint y su potencial? ¡Desactive el sonido en la sección de comentarios a continuación!

Tiempo de lectura: 17 minutos Cosmos es uno de los proyectos más prometedores que hay. Con gente como Jae Kwon y Ethan Buchman en su equipo, tiene mucho potencial. En su corazón y alma se encuentra Tendermint Core. Tendermint Core combina el algoritmo de consenso de Tendermint junto con un protocolo de chismes p2p. Entonces, cuando lo pones todo junto en la pila de software, obtienes el Tendermint Core junto con la capa de aplicación Cosmos-SDK. De todos modos, así que antes de ir más allá, veamos por qué Tendermint es una necesidad. Bitcoin y Blockchain Cuando Satoshi Nakamoto creó Bitcoin, hizo el primer sistema criptográfico descentralizado. La parte realmente notable de este descubrimiento fue que fue capaz de resolver el problema del general bizantino que ayudó a una red de área amplia (WAN) a llegar a un consenso en un entorno sin confianza. Bitcoin utilizó el algoritmo de prueba de trabajo para cuidar de su consenso. Dicho esto, la principal contribución de Bitcoin puede muy bien ser el hecho de que introdujo todo el mundo a la tecnología blockchain. Una cadena de bloques es, en el más simple de los términos, una serie de registro inmutable de datos que es administrada por un clúster de computadoras que no son propiedad de ninguna entidad. Cada uno de estos bloques de datos (es decir, bloque) están protegidos y enlazados entre sí mediante principios criptográficos (es decir, cadena). En otras palabras, una cadena de bloques es una máquina de estado determinista replicada en nodos que no necesariamente confían entre sí. Por determinista queremos decir que si se toman los mismos pasos específicos, entonces siempre conducirá al mismo resultado. Por ejemplo. 1 + 2 siempre será 3. Entonces, ¿qué significa estado? Echemos un vistazo a Bitcoin y Ethereum. En Bitcoin, el estado es una lista de saldos para cada cuenta, que es una lista de salida de transacciones no gastadas (UTXO). Este estado se modifica a través de transacciones que cambian el saldo. Por otro lado, en Ethereum, la aplicación es una máquina virtual que ejecuta contratos inteligentes. Cada transacción pasa a través de la máquina virtual de Ethereum y modifica el estado de acuerdo con el contrato inteligente específico que se llama dentro de ella. Si nos fijamos en la arquitectura de la tecnología blockchain, entonces usted tres capas específicas: Networking: La propagación de la transacción/información a través de los nodos Consenso: Permite que los nodos lleguen a una decisión proporcionada 2/3rd de los nodos son no maliciosos Aplicación: Responsable de la actualización el estado dado un conjunto de transacciones, es decir, transacciones de procesamiento. Dada una transacción y un estado, la aplicación devolverá un nuevo estado. Para señales visuales: Problemas con la arquitectura actual de Blockchain resulta que construir una cadena de bloques desde cero con todas estas 3 capas es un trabajo realmente duro. Por lo tanto, muchos proyectos prefirieron construir bifurcando la base de código Bitcoin. Ahora bien, aunque esto ahorra mucho tiempo, el hecho es que todavía están esposados por las limitaciones del protocolo Bitcoin. Obviamente, no se pueden ejecutar proyectos complejos cuando se utiliza un protocolo que es conocido por sus problemas de rendimiento. Las cosas se pusieron mucho mejor cuando Ethereum entró en juego. Ethereum realmente dio a los desarrolladores una plataforma que podrían usar para crear su propio código personalizado también conocido como contratos inteligentes y proyectos. Sin embargo, al igual que con Bitcoin, Ethereum también sufre el mismo problema. Ambos tienen arquitectura monolítica en lugar de modular. Arquitectura monolítica vs Arquitectura modular Arquitectura monolítica significa que todo está compuesto en una sola pieza. Cuando el software se considera “monolítico” los componentes están interconectados e interdependientes entre sí y el diseño es más autónomo. En este caso, la arquitectura está más estrechamente acoplada y los componentes asociados deben estar todos presentes para que el código sea ejecutado o compilado. Aunque esto hace que el sistema para el que fue creado sea más robusto, realmente no se puede derivar de él y crear códigos personalizados. No es el más flexible de los sistemas. Además, hay otro problema con este sistema. Si algún componente del programa necesita ser actualizado, toda la aplicación tendrá que ser reelaborada. Esta no es realmente la más ideal de las situaciones ahora, ¿verdad? Por otra parte, tenemos arquitectura modular. A diferencia de Monolítico, las capas no están vinculadas entre sí. Por lo tanto, aunque puede no ser tan robusto, es bastante fácil actualizar toda la aplicación trabajando con los diferentes módulos separados. Dado que los módulos son tan independientes, la arquitectura modular le permite actualizar realmente una sección en particular sin causar cambios imprevistos en el resto del sistema. Los procesos iterativos también son mucho más simples en programas modulares, en lugar de monolíticos. Tendermint's Architecture and Goals Tendermint utiliza la arquitectura modular. Sus objetivos son los siguientes: Proporcionar las capas de red y consenso de una cadena de bloques como una plataforma donde se pueden construir diferentes aplicaciones descentralizadas Los desarrolladores solo necesitan preocuparse por la capa de aplicación de la cadena de bloques, ahorrando todas las horas que habrían desperdiciado trabajando en el consenso y la capa de red también. Tendermint también incluye el protocolo de consenso Tendermint que es el algoritmo bizantino de consenso tolerante a fallos utilizado en el motor Tendermint Core Veamos cómo se verá la arquitectura de Tendermint: Como puede ver, la aplicación está conectada a Tendermint Core a través de un protocolo socket llamado APCI o Application Blockchain Interface. Dado que Tendermint Core y la aplicación que se ejecuta en él se ejecutan en procesos UNIX separados, necesitan tener un método para hablar entre sí. ABCI ayuda a estos dos en su comunicación. Entonces, ¿cómo es el diseño de ABCI? ABCI tendrá algunos componentes de diseño distintos: #1 Message Protocol Los pares de mensajes de solicitud y respuesta Las solicitudes se realizan por consenso mientras la aplicación se encarga de la respuesta Se define usando protobuf #2 Server/Client El motor de consenso ejecuta el cliente La aplicación ejecuta el servidor Hay dos implementaciones adecuadas: bytes sin procesar asíncros y grpc #3 Blockchain Protocol ABCI está muy orientado a la conexión. Las tres conexiones para Tendermint Core son las siguientes: Conexión Mempool: Esto comprueba si las transacciones deben ser retransmitidas antes de que se comprometan. Sólo puede utilizar la conexión CheckTX Consensus: Esta conexión ayuda en la ejecución de transacciones que se han confirmado. La secuencia de mensajes es, para cada bloque, BeginBlock, [DelivertX,...], EndBlock, Commit Query Connection: Ayuda en consultar el estado de la aplicación. Esta parte sólo utiliza Query e Info All en general, el objetivo principal de Tendermint es proporcionar a los desarrolladores una herramienta que no sólo es práctica, sino que también tiene un alto rendimiento. Estas son las propiedades de Tendermint que lo hace tan atractivo: #1 Public o Private Blockchain Compatible Diferentes proyectos tienen diferentes necesidades. Algunos proyectos necesitan tener un sistema abierto donde cualquiera pueda unirse y contribuir, como Ethereum. Por otro lado, tenemos organizaciones como la Industria Médica, que no pueden exponer sus datos a casi todos. Para ellos, requieren algo como la cadena de bloques permisible. Ok, entonces, ¿cómo puede Tendermint ayudar a satisfacer ambas necesidades? Recuerde que Tendermint solo maneja la red y el consenso para la cadena de bloques. Por lo tanto, ayuda en la: Propagación de la transacción entre los nodos a través del protocolo de chismes Ayuda a los validadores a ponerse de acuerdo sobre el conjunto de transacciones que se agrega a la cadena de bloques. Lo que esto significa es que la capa de aplicación es libre de definirse de cualquier manera que los desarrolladores quieran que se defina. Los desarrolladores deben definir cómo se define el conjunto de validadores dentro del ecosistema. Los desarrolladores pueden permitir que la aplicación tenga un sistema electoral que elija validadores en función de cuántos tokens nativos han apostado estos validadores dentro del ecosistema.. aka Prueba de estaca y crear una cadena de bloques pública Plus, los desarrolladores también pueden crear una aplicación que defina un conjunto restringido de validadores preaprobados que se ocupan del consenso y de los nuevos nodos que llegan a entrar en el ecosistema. Esto se llama prueba de autoridad y es el sello distintivo de una cadena de bloques permisionada o privada. #2 Las aplicaciones de alto rendimiento hechas a través de Tendermint Core pueden esperar un rendimiento excepcional. Tendermint Core tiene un tiempo de bloqueo de solo 1 segundo. También puede manejar un volumen de transacción de 10.000 transacciones por segundo para transacciones de 250 bytes, siempre y cuando la aplicación le permita hacerlo. #3 Finality ¿Qué es finality? En términos simples, significa que una vez que una determinada acción ha sido ejecutada, no puede ser retomada. Por lo tanto, tomemos el ejemplo de una simple transacción financiera. Supongamos que usted compra algunas acciones en una empresa, sólo porque un fallo en su sistema, no debe perder la propiedad de sus acciones. Como se puede imaginar, la finalidad es súper crítica para un sistema financiero. Imagine hacer una transacción de un millón de dólares y luego al día siguiente, esa transacción ya no es válida debido a un fallo. Como hemos mencionado antes, Bitcoin y Ethereum (hasta la implementación completa de Casper FFG) realmente no tienen finalidad de liquidación. Con motivo de un hardfork o un 51% de ataque, las transacciones tienen la posibilidad de ser revertidas. La menta, por otro lado, da una finalidad instantánea dentro de 1 segundo después de la finalización de la transacción. Las horquillas nunca se crean en el sistema, siempre y cuando menos de 2/3rd de los validadores sean maliciosos. Tan pronto como se crea un bloque (que está en un segundo) los usuarios pueden estar seguros de que su transacción está finalizada. #4 Security Tendermint es seguro y obliga a sus participantes a ser responsables de sus acciones también. Como hemos dicho antes, la hierbabuena nunca se puede bifurcar siempre que menos de 2/3rd de los validadores sean maliciosos. Si en algún caso, la cadena de bloques hace tenedor, hay una manera de determinar la responsabilidad. Además, el consenso de Tendermint no solo es tolerante a fallas, sino que es óptimamente bizantino tolerante a fallas #5 Fácil de usar Otra gran cosa sobre Tendermint es su facilidad de uso. Como hemos mencionado anteriormente, tienen una arquitectura modular donde la capa de aplicación se puede personalizar adecuadamente. Esto hace posible que las bases de código de blockchain existentes se vinculen sin esfuerzo a Tendermint a través de ABCIs. El ejemplo perfecto de esto es Etheremint que es básicamente el enchufe de base de código de máquina virtual Ethereum en la parte superior de Tendermint. Ethermint funciona exactamente como Ethereum, pero también se beneficia de todas las características positivas que hemos enumerado anteriormente. Todas las herramientas de Ethereum como Metamask y Truffle son compatibles con Ethermint. La implementación de prueba de participación de #6 Escalabilidad Tendermint es mucho más escalable que un algoritmo de consenso de prueba de trabajo tradicional. La razón principal es que los sistemas basados en polvo no pueden hacer fragmentación. El particionar básicamente particiona horizontalmente una base de datos y crea bases de datos o fragmentos más pequeños que luego son ejecutados paralelamente por los nodos. La razón es que un grupo minero fuerte puede hacerse cargo fácilmente de un fragmento. Tendermint permitirá la implementación de la fragmentación que aumentará en gran medida la escalabilidad. Protocolo de Consenso de Tendermint Ok, así que vamos a ver cómo funciona el protocolo de consenso Tendermint. ¿Qué es exactamente un protocolo de consenso? Así es como Wikipedia define la toma de decisiones por consenso: “La toma de decisiones por consenso es un proceso de toma de decisiones grupales en el que los miembros del grupo se desarrollan, y acuerdan apoyar una decisión en el mejor interés del conjunto. El consenso puede definirse profesionalmente como una resolución aceptable, que puede ser apoyada, aunque no sea la “favorita” de cada individuo. “Consenso” es definido por Merriam-Webster como, primero, acuerdo general, y segundo, solidaridad de grupo de creencias o sentimientos.” En términos más simples, el consenso es una forma dinámica de llegar a un acuerdo en un grupo. Si bien votar sólo se establece para un gobierno mayoritario sin pensar en los sentimientos y el bienestar de la minoría, un consenso, por otro lado, asegura que se llegue a un acuerdo que beneficie a todo el grupo en su conjunto. Desde un punto de vista más idealista, el Consenso puede ser utilizado por un grupo de personas dispersas por todo el mundo para crear una sociedad más equitativa y justa. Un método mediante el cual se logra la adopción de decisiones por consenso se denomina “mecanismo de consenso”. Así que ahora lo que hemos definido lo que es un consenso, veamos cuáles son los objetivos de un mecanismo de consenso (datos tomados de Wikipedia). Búsqueda de acuerdos: Un mecanismo de consenso debería lograr el mayor acuerdo posible por parte del grupo. Colaborativo: Todos los participantes debe tratar de trabajar juntos para lograr un resultado que ponga en primer lugar el interés superior del grupo. Cooperativa: Todos los participantes no deben poner sus propios intereses en primer lugar y trabajar en equipo más que en individuos. Participativa: El mecanismo de consenso debe ser tal que todos participen activamente en el proceso general. Inclusive: El mayor número posible de personas debería participar en el proceso de consenso. No debería ser como un voto normal donde la gente realmente no tiene ganas de votar porque creen que su voto no tendrá ningún peso a largo plazo. Igualitario: Un grupo que trate de lograr el consenso debe ser lo más igualitario posible. Lo que esto significa básicamente que todos y cada uno de los votos tienen el mismo peso. El voto de una persona no puede ser más importante que el de otra. Ahora que hemos definido qué mecanismos de consenso son y qué deben apuntar, tenemos que pensar en el otro elefante en la sala. Qué mecanismos de consenso se deben usar para una entidad como blockchain. Antes de Bitcoin, había un montón de iteraciones de sistemas de moneda descentralizados peer-to-peer que fallaron porque no pudieron responder al mayor problema a la hora de llegar a un consenso. Este problema se llama “Problema de Generales Bizantinos”. Problema del general bizantino Con el fin de hacer cualquier cosa en una red peer-to-peer, todos los nodos deberían ser capaces de llegar a un consenso. La cosa es, sin embargo, para que este sistema funcione, pone mucho énfasis en que las personas actúen en el mejor interés de la red general. Sin embargo, como ya sabemos, la gente no es realmente confiable cuando se trata de actuar de manera ética. Aquí es donde entra en juego el problema del general bizantino. Imagina esta situación. Hay un ejército alrededor de un castillo bien fortificado. La única manera de ganar es si atacan el castillo juntos como una unidad. Sin embargo, se enfrentan a un gran problema. El ejército está muy separado el uno del otro y los generales no pueden comunicarse directamente y coordinar el ataque y algunos de los generales están corruptos. Lo único que pueden hacer es enviar un mensajero de general a general. Sin embargo, muchas cosas podrían pasarle al mensajero. Los generales corruptos pueden interceptar al mensajero y cambiar el mensaje. Entonces, ¿qué pueden hacer los generales para asegurarse de que lancen un ataque coordinado sin depender de la ética de cada general individual? ¿Cómo pueden llegar a un consenso sin confianza para hacer lo que hay que hacer? Ese es el problema del general bizantino y Satoshi Nakamoto resolvió este problema utilizando el mecanismo de consenso de prueba de trabajo (POW). ¿Qué es la prueba de trabajo? Vamos a comprobar cómo POW funciona con el contexto de nuestro ejemplo dado anteriormente. Supongamos que un general quiere comunicarse con otro general. ¿Cómo crees que va a caer? Se añade un “nonce” al mensaje original. El nonce es un valor hexadecimal aleatorio. Este nuevo mensaje es entonces hash. Supongamos que los generales acuerdan de antemano que solo enviarán mensajes, que cuando hash comienza con 4 “0"s. Si el hash no da el número deseado de 0s, el nonce se cambia y el mensaje se vuelve a hash. Este proceso sigue repitiendo hasta que se recibe el hash deseado. Todo el proceso consume mucho tiempo y consume mucha potencia computacional. Ahora, cuando finalmente obtienen el valor hash, al mensajero se le da el mensaje original y el nonce y se le dice que se comunique con los otros generales. Entonces, ¿qué pasa si alguien intenta interceptar el mensaje? Bueno, ¿recuerdas el efecto avalancha de las funciones hash? El mensaje cambiará drásticamente y ya que ya no comenzará con el número requerido de “0's”, la gente se dará cuenta de que el mensaje ha sido manipulado. Entonces, para poner POW en el contexto de la minería criptográfica: los mineros intentan resolver puzzles criptográficos para agregar un bloque a la cadena de bloques. El proceso requiere mucho esfuerzo y poder computacional. Los mineros presentan su bloque a la red bitcoin. La red luego verifica la autenticidad del bloque simplemente verificando el hash, si es correcto, entonces se agrega a la cadena de bloques. Por lo tanto, descubrir el nonce y el hash requeridos debería ser difícil, sin embargo, verificar si es válido o no debe ser simple. Esa es la esencia de la prueba de trabajo. Ahora, probablemente se esté preguntando, ¿por qué deberían los mineros sacrificar su tiempo y recursos para extraer bitcoins? Bueno, resulta que tienen un incentivo económico bastante saludable: Cuando descubres un bloque, recibes una recompensa de bloque de 12.5 bitcoins. La recompensa se reduce a la mitad cada 210.000 bloques. Una vez que has extraído un bloque, te conviertes en el dictador temporal del bloque. Usted es el responsable de poner las transacciones dentro del bloque y, por lo tanto, tiene derecho a las comisiones de transacción. Solo hay un número limitado de bitcoins por ahí, 21 millones para ser exactos. Entonces, ¿qué impide a estos mineros extraer todos los bitcoins a la vez? Resulta que la minería de bitcoin se vuelve progresivamente más difícil con el tiempo. Esta característica se llama “dificultad”, y la dificultad de la minería sigue aumentando a medida que continúa en la minería. Esta es la razón por la que hoy en día es casi imposible que los mineros en solitario minen bitcoins usando solo sus computadoras. Los mineros han unido sus fuerzas y creado “piscinas mineras” para aunar su poder computacional y explotar como un grupo. Estos grupos utilizan ASIC (Application-Specific Integrated Circuits) creados específicamente para la minería para extraer bitcoins. Problemas con POW Hay tres problemas principales con los algoritmos de prueba de trabajo. Ya hemos hablado de esto en detalle antes, así que vamos a hacer una visión general. Despilfarro de energía: Bitcoin consume más energía que Irlanda y la República Eslovaca. Este enorme desperdicio de energía es uno de los principios de Bitcoin. Es un desperdicio por el bien del desperdicio. Centralización: Como ya le hemos dicho, Bitcoin utiliza ASIC para la minería. El problema con eso es que los ASIC son caros, y los grupos con más dinero tienden a tener más ASIC y, en consecuencia, más energía minera. Como tal, Bitcoin no está tan descentralizado como quiere ser. Escalabilidad: La arquitectura misma de POW impide la escalabilidad. Bitcoin gestiona solo 7 transacciones por segundo. Para un sistema financiero moderno, simplemente no es lo suficientemente adecuado. Ingrese Tendermint Así, para contrarrestar los muchos problemas con el sistema de consenso de prueba de trabajo, Jae Kwon, un graduado en ciencias de la computación e ingeniería de sistemas, creó Tendermint. Tendermint es un protocolo puramente basado en BFT, construido en un entorno sin permisos con el Proof-of-of-Stake (PO) como el mecanismo de seguridad subyacente. Debido a la complejidad, Tendermint ha tardado casi 4 años en completarse. Jae Kwon y el director técnico de Tendermint Ethan Buchman se inspiraron en Raft y PBFT para crear un sistema de consenso que satisfizo el problema del general bizantino. Es “modelado como un protocolo determinista, vivo bajo sincronía parcial, que logra el rendimiento dentro de los límites de la latencia de la red y de los propios procesos individuales”. Muy bien, sabemos que es un montón de palabras complicadas para lanzar una tras otra, pero para entender qué es el consenso de Tendermint y por qué fue diseñado de la manera en que fue diseñado, es necesario entender lo que significan algunos de esos términos complicados. Verá cómo todos ellos se unen entre sí como un intrincado rompecabezas. #1 FLP Impossibilidad La imposibilidad FLP (Fischer Lynch Paterson) establece que un algoritmo de consenso sólo puede tener 2 de las siguientes 3 propiedades: Seguridad Terminación garantizada o vida Falla Tolerancia Imagen Crédito: Medium In otras palabras, la imposibilidad de FLP establece que “tanto la terminación como el acuerdo (vida y seguridad) no se pueden satisfacer de manera temporal en un sistema asíncrono distribuido, si se quiere ser resistente a al menos una falla (prueban su resultado para la tolerancia general a fallas, que es más débil que la bizantina tolerancia a errores, ya que solo requiere un nodo de parada de fallos, por lo que BFT se incluye dentro de las reivindicaciones de imposibilidad FLP).” Por lo tanto, básicamente, es bastante imposible que una WAN asincrónica llegue a un consenso, ya que no hay cantidad específica de tiempo que los nodos tardarán en recibir, procesar y responder a los mensajes. Esto es obviamente un gran problema porque es extremadamente poco práctico que una gran red de nodos como Bitcoin asuma que se van a sincronizar. Ok, entonces la sincronicidad iba a ser un problema. Sin embargo, los investigadores Dwork, Lynch y Stockmeyers lanzaron una línea de vida aquí con su artículo llamado “Consenso en presencia de sincronía parcial”. Esto fue llamado consenso DLS. #2 Consenso DLS y sincronocidad Parcial El documento DLS afirma que entre un sistema síncrono y un sistema asíncrono, existe un sistema especial que es “parcialmente sincrónico”. Dado que este sistema parcialmente sincrónico puede tener un tiempo límite superior dado, será capaz de diseñar un protocolo BFT viable. Según DLS, el verdadero desafío en el diseño de protocolos es tener uno que funcione correctamente en un sistema parcialmente sincrónico. Entonces, veamos cómo funcionan los protocolos descentralizados populares como Bitcoin y Ethereum en ese sentido. Bitcoin tiene un límite superior conocido que es de alrededor de 10 minutos. Por lo tanto, se produce un bloque de transacciones cada 10 minutos. Esta suposición de tiempo se impone en la red para que los nodos tengan 10 minutos enteros para recopilar la información y transmitirla a través de chismes. Por otro lado, tenemos Ethereum que hace suposiciones de sincronía para sus bloques y red manteniendo un tiempo de bloque superior en 15 segundos. Con un tiempo de bloque tan bajo, son más escalables que Bitcoin, sin embargo, no son realmente tan eficientes. Los mineros de Ethereum producen muchos bloques huérfanos. #3 Liveness y Terminación de Terminación es una propiedad que establece que cada procesador correcto eventualmente debe tomar una decisión. La mayoría de los algoritmos de consenso, que tenemos ahora, dependen de modelos sincrónicos para su seguridad y terminación. Tienen límites fijos y reglas que se conocen por lo que, en el caso de que no se sostengan, la cadena se bifurca en múltiples protocolos. Seguro que hay protocolos de consenso que funcionan en redes asincrónicas, sin embargo, yendo por el teorema de imposibilidad FLP, no pueden ser deterministas. Lo que nos lleva a.... #4 Deterministic vs No Deterministic Protocolos Usualmente, los protocolos de consenso puramente asíncrono dependen de miembros no deterministas tales como oráculos que implican un alto grado de incertidumbre y complejidad. Entonces, ¿cómo lidia la menta con todos estos factores? Tendermint es un consenso BFT en su mayoría asíncrono, determinista, donde los validadores tienen una participación que denota su poder de voto. En el triángulo de imposibilidad FLP, prefiere la tolerancia a fallas y la seguridad (consistencia) sobre la vida. Tendermint oscila constantemente entre períodos de sincronía y asincronía. Esto significa que, si bien se basa en supuestos de temporización para avanzar, la velocidad de dicho progreso no depende de los parámetros del sistema, sino que depende de la velocidad real de la red. Además, Tendermint nunca se bifurca en presencia de asincronía si menos de 1/3 de los validadores son corruptos/descuidados. Esta es la misma razón por la que Tendermint es tolerante a fallas bizantinas. Como hemos dicho antes, Tendermint se centra en la seguridad por encima de la vida. Por lo tanto, si más de un tercio de los validadores son maliciosos, en lugar de la bifurcación de la red, la cadena de bloques Tendermint simplemente se detendrá temporalmente hasta que más 2/3rd validadores lleguen a un consenso. La menta también es completamente determinista y no hay aleatoriedad en el protocolo. Los líderes en el sistema son elegidos en una versión determinista, a través de una función matemática definida. Por lo tanto, podemos demostrar matemáticamente que el sistema se comporta de la manera en que se supone que debe comportarse. Tendermint - El sistema de prueba de estaca En un sistema de prueba de estaca (POS), tenemos ciertas personas llamadas “validadores”. Estos validadores encierran una estaca dentro del sistema. Después de eso, tienen la responsabilidad de apostar en el bloque que sienten que se va a agregar junto a la cadena de bloques. Cuando se agrega el bloque, obtienen una recompensa proporcional a su apuesta. Muy bien, así es como funciona un punto de venta genérico. Ahora, veamos cómo funciona la menta. Primero vamos a familiarizarnos con algunos de los términos que vamos a utilizar: Una red compuesta de muchos nodos. Los nodos que están conectados a un nodo determinado se llaman sus pares. El proceso de consenso tiene lugar a una altura de bloque particular H. El proceso para determinar el siguiente bloque consiste en múltiples rondas. La ronda consta de muchos Estados que son: NEWHeight, Proponer, Prevotar, Precomier, y Commit. Cada estado se llama un Roundstep o simplemente “paso”. Se dice que un nodo está a una altura, redondeo y paso dados, o en (H, R, S), o en (H, R) en resumen para omitir el paso. Prevotar o precomprometer algo significa emitir un voto previo a la votación o precomprometer un voto por algo. Cuando un bloque obtiene 2/3 de los votos previos en (H, R), entonces se llama prueba de bloqueo de cambio o polC. ¿Qué es la máquina estatal? La máquina estatal es el motor del protocolo Tendermint, por así decirlo. El siguiente diagrama le da una buena idea de cómo se verá: Ok, entonces, ¿qué está pasando aquí? ¿Recuerdas los estados por los que pasa cada ronda? NewHeight, Proponer, Prevotar, Precomprometer y Comprometer. De ellos, “Proponer, Prevotar, Precomprometer” consisten en una ronda, mientras que las otras dos son rondas especiales. En un escenario ideal, la transición estatal actuaría así: newHeight - (Proponer - Prevotar - Precomprometer) + - Commit - NewHeight -... Sin embargo, no es así como siempre puede funcionar. Es posible que se requieran varias rondas antes de confirmar el bloque. Las siguientes son las razones por las que pueden ser necesarias múltiples rondas: El proponente designado puede estar ausente. El bloque propuesto tal vez no válido. El bloque no se propagó a tiempo. 2/3 de los votos previos no fueron recibidos a tiempo por los nodos del validador. Aunque + 2/3 de los votos previos son necesarios para avanzar al siguiente paso, al menos un validador puede haber votado o votado maliciosamente por otra cosa. 2/3 de los precommits para el bloque no se recibieron aunque se hayan recibido prevotos. ¿Qué sucede durante cada estado? Muy bien... así que ahora vamos a mirar en todos y cada uno de los estados y ver cómo todo se junta. Proponer En esta etapa, el proponente designado, es decir, el nodo seleccionado propone un bloque para ser añadido en (H, R). Esta etapa termina de una de dos maneras: El bloque se propone y entra en la fase previa a la votación. El tiempo del proponente para elegir el bloque expira en el que entra en la fase previa a la votación de todos modos. Prevota Ahora llegamos a la fase previa a la votación. En esta etapa, cada validador necesita tomar una decisión. Si de alguna manera, el validador está bloqueado en un bloque propuesto de alguna ronda anterior, automáticamente firman y transmiten ese bloque. Si el validador había recibido una propuesta aceptable para la ronda actual, entonces firman y emitieron un prevoto para el bloque propuesto. Sin embargo, si encuentran algo sospechoso con la propuesta o no han recibido ninguna propuesta en absoluto (por ejemplo, si el tiempo del proponente se agota), entonces firman con un prevoto nulo. Durante esta etapa no se produce ningún bloqueo de bloques. Durante este período, todos los nodos propagan los votos previos por todo el sistema a través del protocolo de chismes. Precommit Ahora entramos en el paso final de la “ronda” llamada “precommit”. Al entrar en esta etapa, los validadores se comprometen previamente a su decisión emitiendo sus votos previos. Uno de los tres escenarios siguientes puede ocurrir: Si el validador recibe 2/3 de los votos previos para un bloque aceptable en particular, entonces el validador firma la sesión y transmite su precommit al bloque. También están encerrados en ese bloque. Un validador puede bloquear solo un bloque a la vez. Sin embargo, si el validador recibe más de 2/3rd de los prevotaciones NUL, entonces se desbloquean y los precommits se convierten en “NIL”. Finalmente, si no han recibido una supermayoría de 2/3er en absoluto, entonces no firman o bloquean nada. A lo largo de esta etapa, los nodos siguen chismeando continuamente sobre las confirmaciones previas en toda la red. Al final, si el bloque propuesto obtiene más de 2/3rd precommits, entonces nos movemos hacia el paso “Commit”. Sin embargo, si no llegan a esa etapa, entran en la etapa “Proponer” de la siguiente ronda. Confirmar El estado de confirmación no forma parte de la “ronda”. Junto con NewHeight, es una de las dos rondas especiales. Durante el estado de confirmación, se comprueban dos condiciones paralelas para ver si se cumplen o no. En primer lugar, los validadores deben recibir el bloque previamente comprometido por la red. Una vez hecho esto, firman y transmiten su compromiso. En segundo lugar, deben esperar hasta que hayan recibido al menos 2/3ª preconfirmaciones para el bloque. Una vez hecho esto, el bloque obtiene comprometido con la red. NewHeight Simplemente incrementa la altura del bloque en 1 para mostrar que se ha añadido el bloque. Elegir a los Validadores Como ya habrás entendido, elegir el conjunto inicial de validadores es fundamental para que Cosmos funcione. Entonces, ¿cómo exactamente van a ser elegidos? A diferencia de Bitcoin, donde cualquiera puede convertirse en minero en cualquier momento, sólo hay tantos validadores que el sistema Tendermint puede aceptar. Dado que los validadores necesitarán realizar una gran cantidad de funciones individualmente, aumentar el número de validadores solo dará lugar a retrasos. Esta es la razón por la que Cosmos decidió elegir 100 validadores durante el día del Génesis (es decir, el día de la recaudación de fondos). El número de validadores aumentará en un 13% cada año hasta 10 años, cuando se asentará en 300. Entonces, ¿qué pasa con los resultados? Como afirma el documento técnico del cosmos: “Tendermint ofrece un rendimiento excepcional. En los puntos de referencia de 64 nodos distribuidos en 7 centros de datos en 5 continentes, en instancias de nube de materias primas, el consenso de Tendermint puede procesar miles de transacciones por segundo, con latencias de compromiso en el orden de uno a dos segundos. Cabe destacar que el desempeño de más de mil transacciones por segundo se mantiene incluso en duras condiciones adversarias, con validadores chocando o emitiendo votos malintencionados.” El siguiente gráfico apoya la afirmación hecha anteriormente: Casper vs Tendermint Junto con Tendermint, Casper es otra implementación popular del protocolo POS. Mientras Tendermint se centra en la seguridad, Casper se centra en la vida, por la imposibilidad del FLP. Entonces, ¿qué pasa en Casper durante un tenedor? Casper FFG permitirá que una cadena de bloques continúe siendo construida, mientras que también tiene la propiedad de que todos los nodos serán conscientes de que esta cadena no está finalizada. Por lo tanto, la cadena de bloques puede permanecer disponible sin ninguna finalidad. Los validadores de la cadena tienen la opción de moverse a la cadena bifurcada. Si más de 2/3rd de los validadores votan, entonces cambian de cadena. Además, Casper tiene un famoso mecanismo de corte. Cualquier tipo de ataque malicioso conducirá a que los validadores tengan su apuesta al instante. Conclusión Así que, ahí lo tienes. Esperamos que le hayamos dado tanta información valiosa como sea posible. ¿Qué opinas de Tendermint y su potencial? ¡Desactive el sonido en la sección de comentarios a continuación!

Like what you read? Give us one like or share it to your friends and get +16

42
Hungry for knowledge?
New guides and courses each week
Looking to invest?
Market data, analysis, and reports
Just curious?
A community of blockchain experts to help

Get started today

Already have an account? Sign In