La absurda tasa de innovación que tiene lugar en criptografía es un caldo de cultivo para nuevas ideas. Estas nuevas ideas requieren formas nuevas, aunque familiares, de ser comunicadas. Una de las formas de comunicación más utilizadas en exceso es a través de la formulación de la terminología como "PRUEBA-DE- xyz ".
Todo el mundo siempre está tratando de probar algo y esto es por una buena razón, después de todo, la esencia misma de blockchain es "No confíes, verifica".
Ok, no realmente, pero analizaremos uno de los aspectos técnicos más importantes sobre los que se construye toda la industria: los mecanismos de consenso .
Complejidad computacional
La cantidad de recursos y pasos que son necesarios para llegar al resultado deseado (cuanto más rápido/corto, mejor)
Tolerancia a fallos
En el centro del consenso de cualquier red computacional se encuentra la capacidad de mantener las operaciones en caso de que los participantes de la red se desconecten o dejen de funcionar (lo que puede suceder esporádicamente). Cuanto mayor sea la tolerancia a fallas, más fácil será engañar al sistema; cuanto menor sea la tolerancia, más resistente será el sistema. Entonces, si la tolerancia a fallas de un sistema es del 51 %, eso significa que el sistema puede seguir funcionando siempre que el 49 % esté comprometido. Si la tolerancia es del 67 %, eso significa que el sistema solo puede manejar el 33 % de los nodos comprometidos.
Resiliencia
La capacidad de continuar brindando resultados adecuados en caso de actividad maliciosa (que puede ocurrir durante períodos prolongados)
Vivacidad
Las garantías de que aún después de que suceda algún imprevisto, la red seguirá operando con veracidad.
Si bien hay cientos, si no miles de mecanismos diferentes en el mercado hoy en día; hay dos tipos generales de mecanismos de Consenso basados en su lógica operativa, prueba de trabajo y prueba de participación . Cualquier otra variación será solo un ajuste modular o una combinación de estos dos.
Descentralización: Muy Alta
Tolerancia a fallas: 51%
Caso de uso: asegurar el historial de blockchain
Descripción: Proceso intensivo en recursos de extrema complejidad matemática que exige hardware dedicado. El consenso de POW se alcanza a través de la contribución de recursos computacionales para resolver problemas matemáticos de monstruosa complejidad. Aquí, los nodos se denominan mineros y obtienen sus recompensas mediante la emisión de nuevos tokens de red. Los líderes de las propuestas de bloque se eligen por orden de llegada según quien sea capaz de resolver el problema matemático.
Ejemplos de POW : Bitcoin (BTC) , Dogecoin (DOGE) , Litecoin (LTC) ,
Descentralización: moderada-alta
Tolerancia a fallas: 67%
Caso de uso: asegurar el historial de blockchain
Descripción: El modelo más popular para el consenso. El concepto detrás de este es sencillo, los usuarios bloquean/garantizan sus tokens para poder participar. En los modelos POS, hay suministros circulantes fijos, lo que significa que no se emiten nuevos tokens como recompensas en bloque, las recompensas se obtienen mediante la acumulación de tarifas de transacción. Además, a diferencia de POW, los modelos POS emplean la reducción de apuestas por cualquier mala conducta; en el caso de que se encuentre un comportamiento malicioso/subversivo, el nodo infractor perderá ~50% de su participación en la red para su redistribución entre los nodos justos. Comúnmente considerado menos seguro y más centralizado que POW en el sentido de que los incentivos de los nodos de red son similares a los sistemas financieros heredados; los jugadores con más dinero tienen una mejor oportunidad de poseer los nodos de la red.
Ejemplos de POS: Ethereum (ETH) , Cardano (ADA) , , CELO (CELO) , Polkadot (DOT) , Avalanche (AVAX) ,
Descentralización: Baja
Tolerancia a fallas : ** 67%
Caso de uso: asegurar el historial de blockchain
Descripción: La adaptación más popular de POS regulares; La prueba de participación delegada es un intento de democratizar el acceso a la participación en las operaciones y recompensas de la red. Solo los más grandes pueden participar en el proceso de seguridad, mientras que los poseedores de tokens de menor tamaño "delegan" sus tokens a los nodos operativos; básicamente, votan con sus tokens, nunca entregándolos al nodo real. Los modelos de consenso de dPOS generalmente tendrán en el rango de 21 a 101 nodos que manejan operaciones de red. Estos operadores de red se seleccionan en función de la cantidad de tokens que tienen en juego. El mayor beneficio de la variante dPOS es que limita la cantidad de nodos; Si bien esto conduce a la centralización, también brinda el beneficio adicional de tiempos de procesamiento más rápidos.
Ejemplos de dPOS: Polygon (MATIC) , Tron (TRX) , EOS (EOS) , , ,
Descentralización: Baja - Moderada
Tolerancia a fallas: 67%
Caso de uso: asegurar el historial de blockchain
Descripción: Esta es una variación avanzada de POS. Muy similar al modelo de prueba de participación delegada, la prueba de participación arrendada proporciona la diferencia técnica en; que en dPOS los nodos de la red acumulan las recompensas y luego las distribuyen a sus delegadores; pero en LPOS, los usuarios en realidad prestan sus tokens a los nodos, por lo que poseen una parte del peso de los nodos y acumulan las recompensas directamente, en lugar de hacerlo a través del delegado. La compensación aquí es que para ejecutar el nodo físico, se necesita un nivel muy alto de conocimiento técnico y equipo. Hasta ahora, esta implementación solo se ha utilizado en un proyecto.
Ejemplos de LPOS — Ondas (WAVES)
Descentralización: Moderada
Tolerancia a fallas: 51%
Caso de uso: asegurar el historial de blockchain
Descripción: como su nombre podría haber insinuado, HPOS es una arquitectura creativa que aprovecha ambos modelos de consenso base (POW + POS). En este modelo, hay dos niveles de procesos que tienen lugar. En el nivel básico, los mineros (al igual que en POW) verifican y empaquetan las transacciones en bloques. Luego, estos bloques previamente examinados se envían al mempool del segundo nivel, donde los nodos POS ejecutan una ronda adicional de controles en los bloques y los validan.
Ejemplos de HPOS: DASH (DASH) ,
Descentralización: Muy Alta* (no realmente)
Tolerancia a fallas: 67%
Caso de uso: asegurar el historial de blockchain
Descripción: Otra variación de POS. Novedoso en diseño en comparación con otras variaciones porque podría decirse que es más descentralizado (no). Esta variante no tiene mecanismo de castigo; así que, técnicamente, los malos actores pueden actuar mal y no sufrir. Sin embargo, este diseño es extremadamente bajo en su barrera de entrada, solo se requiere 1 token para unirse como nodo. En teoría, esto es fácil de jugar porque un solo actor puede realizar un ataque silencioso de Sybil distribuyendo 1,000 tokens en 1,000 billeteras diferentes.
Ejemplos de PPOS: Algorand (ALGO)
Descentralización: baja-moderada
Tolerancia a fallas: 67%
Caso de uso: asegurar el historial de blockchain
Descripción: modelo basado en la reputación que es otra implementación más de POS. Difícil de ser aceptado como un nodo válido, fácil de ser expulsado. Debo admitir que este es un poco más creativo en su enfoque. La prueba de importancia utiliza dos factores además de la apuesta; éstas incluyen:
Ejemplos de puntos de interés:
Descentralización: Ninguna - muy baja'
Tolerancia a fallas: 51%
Caso de uso: asegurar el historial de blockchain
Descripción: La centralización es el nombre del juego aquí. POA utiliza una valiosa primitiva no financiera para operar, la identidad. Al usar la identidad, todos los participantes de la red operativa arriesgan su reputación para ser parte del círculo de consenso. Dondequiera que haya identidad hay centralización. Sin embargo, al tener pequeñas cantidades restringidas de operadores conocidos, las redes que usan POA tienen un potencial de rendimiento extremadamente alto. Definitivamente, este no es un mecanismo que desee respaldar las cadenas de bloques de bienes públicos, pero eso no ha impedido que los proyectos lo aprovechen.
Ejemplos de POA: VeChain (VET)
Descentralización: Baja
Tolerancia a fallas: 67%
Caso de uso: desarrollo de la robustez de un mecanismo
Descripción: Un componente de composición clave para construir otros mecanismos de consenso. Por lo general, se encuentra en redes autorizadas, pBFT funciona aprovechando la replicación de datos en todos los nodos. No es el modelo más eficiente debido a las restricciones de comunicación inherentes, pero es muy resistente (obviamente, la tolerancia es alta en los sistemas centralizados, los jugadores solo tienen la culpa de sí mismos y de sus amigos).
Ejemplos de pBFT: {usa una mezcla de POW + pBFT}
Descentralización: Baja
Tolerancia a fallas: 51%
Caso de uso: desarrollo de la robustez de un mecanismo
Descripción: como es el caso de su primo anterior (pBFT), la tolerancia a fallas bizantina delegada es un elemento de composición para la creación de sistemas de cadena de bloques más robustos. Por sí solo, el mecanismo se puede utilizar para admitir comunicaciones distribuidas; sin embargo, están limitados por las restricciones de comunicación que hacen que los sistemas dBFT sean centralizados de forma predeterminada.
Ejemplos de dBFT: NEO (NEO)
Descentralización: Baja
Tolerancia a fallas: 51%
Caso de uso: asegurar el historial de blockchain
Descripción: Giro único en los mecanismos de consenso POW; en lugar de utilizar unidades de procesamiento para resolver problemas constantemente; la prueba de capacidad aprovecha el espacio en disco/memoria. POC traza soluciones potenciales para problemas futuros y las almacena en el espacio vacío del disco de los mineros. No debe confundirse con una falta total de minería, porque la minería todavía se realiza; simplemente sucede de forma preventiva (lo que podría generar posibles riesgos de seguridad). No es muy efectivo a gran escala debido a la alta sensibilidad en el caso de que un nodo se caiga, lo que requiere volver a trazar toda la red y se vuelve menos eficiente a medida que se unen más nodos de minería (requieren un trazado adicional que luego crea enormes retrasos en el computadoras que asignan espacio en disco).
Ejemplos de POC: , ,
Descentralización: N/A
Tolerancia a fallas: N/A
Caso de uso: Sellado de tiempo y organización
Descripción: Este no es un protocolo independiente para construir una cadena de bloques. POH se usa con, lo adivinó, POS, como una técnica utilizada para marcar el tiempo de las transacciones utilizando un método de hashing VRF (función aleatoria verificable) que permite que los bloques en una cadena de bloques se procesen y envíen a un mempool. Esto permite que una red continúe operando a su máxima capacidad independientemente de lo que pueda estar sucediendo con cualquier nodo individual en un momento dado. Si un nodo no envió un bloque a tiempo, eso no impedirá la producción del siguiente bloque porque el bloque retrasado se organizará en su posición correcta lo antes posible.
Ejemplos de POS — Solana (SOL)
Descentralización: No
Tolerancia a fallas: 51%
Caso de uso: asegurar el historial de blockchain
Descripción: este es un modelo extremadamente centralizado para construir una red, principalmente porque es propiedad intelectual (IP) que está protegida por patentes y nadie quiere ir a la guerra con Intel. Sin embargo, el diseño en sí es brillante. POET es otro modelo más que aprovecha la lógica POS con una mezcla del principio de consenso de Nakamoto de la cadena más larga/pesada, junto con sus propios conceptos agregados de un temporizador interno y "descanso". Los nodos mineros se seleccionan al azar y el mismo nodo no se puede seleccionar de forma consecutiva. Una vez que un nodo confirma un bloque, se coloca un temporizador aleatorio en el nodo y se queda "dormido". Mientras está dormido, no utiliza ningún recurso computacional; lo que hace que este modelo sea más ecológico en términos de consumo eléctrico que otras variantes de POS.
Ejemplo de POET:
Descentralización: Baja
Tolerancia a fallas: 51%
Caso de uso: Protección de almacenamiento y datos
Descripción: una versión aumentada de POW, Prueba de acceso es un algoritmo creado por el proyecto Arweave que utiliza una técnica inteligente para verificar los bloques entrantes. En lugar de confiar únicamente en el bloque anterior, los mineros usan algo llamado "bloque de recuperación" junto con un bloque anterior elegido al azar. Los bloques de recuperación se pueden considerar como puntos confiables en la historia de la cadena que no requieren el almacenamiento de todos los datos de la cadena. Esto crea un modelo liviano para probar datos, lo que resulta en capacidades de almacenamiento más eficientes, menos desperdicio de recursos computacionales y mayor rendimiento. Una desventaja potencial de este modelo es que prefiere los nodos más antiguos debido a sus archivos históricos; los nodos más nuevos no tienen acceso a los mismos datos archivados y solo descargarán los bloques de recuperación. Lo que en teoría crea una jerarquía por edades.
Ejemplos de POA — Arweave (AR)
Descentralización: N/A
Tolerancia a fallas: 51%
Caso de uso: Protección de almacenamiento y datos + Computación en la nube
Descripción: esta belleza de modelo es en realidad una expansión de un modelo predecesor en almacenamiento de datos (Prueba de espacio) con una integración de POW que prioriza la capacidad de espacio de almacenamiento en la red/en el espacio de disco del nodo operativo . Hay elementos del mecanismo de consenso de pBFT en el sentido de que los datos que se agregan a la red se replican a través de los mineros de la red. El ingenio de POREP se define por su capacidad para combatir el vector de ataque más tortuoso de la industria de computación en la nube descentralizada conocido como "ataque de generación", mediante el cual un nodo minero paga para cargar un documento y luego lo solicita infinitamente, cobrando tarifas por proporcionar el almacenamiento. de eso
Ejemplos de POREP — Filecoin (FIL)