Como se mencionó en “Qué es una cadena de bloques” en el último artículo, en un sistema distribuido, siempre se necesita tiempo para que una transacción o un bloque se transmita a cada nodo cuando hay una gran cantidad de nodos involucrados. Sabemos que en el sistema Bitcoin, solo los nodos de minería son responsables de producir nuevos bloques, entonces, ¿por qué no reducir la cantidad de nodos de minería tanto como sea posible? Como resultado, surgió el mecanismo de consenso de Prueba de participación de delegados (DPoS). Proof of Stake es una variedad de algoritmos de consenso que usan algo (por ejemplo, la cantidad del token) como participación para empaquetar nuevos bloques, cuanto mayor sea la participación, más probable es que se confirme este nuevo bloque. En DPoS, no hay tantos nodos de minería (estrictamente hablando, no hay un concepto de minería en PoS, sino que se denominan nodos de validación), porque simplemente delegamos muy pocos nodos de validación para producir bloques y transmitirlos a otros delegados. nodos. Claramente, DPoS resolvió el problema del largo tiempo de transmisión en el sistema distribuido . Sin embargo, dado que solo hay unos pocos nodos de validación en juego, ¿cómo podemos evitar que estos nodos se tracen entre sí para manipular toda la cadena y socavar el principio descentralizado? Es por eso que todos los tipos de DPoS tienen un mecanismo de votación estricto para garantizar que estos delegados electos actúen de manera justa y transparente.
De hecho, DPoS proviene del proyecto EOS . En el diseño de DPoS, hay al menos tres tipos de nodos: productor de bloques (BP, o menos estrictamente, nodo de minería), nodo candidato y nodo común. El nodo candidato es un candidato de productor de bloques (BP) que solicita el puesto a través de un contrato inteligente. En teoría, cualquier nodo común con suficiente potencia informática (en sí mismo, recomendamos una computadora con al menos una CPU de 8 núcleos, 8 GB de RAM y 500 GB de SSD) puede ser un nodo candidato. En la práctica, solo una pequeña fracción de ellos puede ser BP real mediante la votación de otros nodos comunes. En el aspecto financiero, un proyecto típico de que eligió DPoS como mecanismo de consenso siempre recompensa a los nodos con algunos tokens si votan por los candidatos, lo que fomenta la participación. El mecanismo de votación es esencialmente un contrato inteligente con métodos de votación que solicitan la dirección del nodo de votación, por quién vota y cuántos tokens quieren apostar (cuanto mayor sea la participación, mayor será el peso del voto). En sí mismo, no sabemos cuántos nodos comunes pueden convertirse en nodos candidatos, pero solo los 17 nodos candidatos con la mayor cantidad de votos pueden convertirse en un BP.
Con algunas técnicas especiales, aelf ha actualizado DPoS al exclusivo AEDPoS (aelf DPoS). Los creadores han elaborado un conjunto específico de mecanismos de producción de bloques basados en rondas. Si busca esto en el documento técnico, verá muchas expresiones matemáticas, pero no se preocupe, el concepto central detrás de esto es bastante simple y directo.
Antes de explicar, permítame recordarle dos cosas: Primero, el método de generación de números aleatorios reales (hablaremos de esto en detalle en los próximos artículos). Este método no solo puede generar un número aleatorio, sino también mezclar una colección (por ejemplo, una lista), lo que hace que el proceso sea imposible de predecir, manipular y trazar. En segundo lugar, el problema general bizantino. Hagamos un resumen rápido de este problema: propuesto formalmente por Lamport et. En 1982, el Problema General Bizantino imagina un escenario de tres generales, como se mencionó en el último artículo, si alguno de los tres es un traidor que quiere alterar el mensaje, es imposible para los tres (todo el sistema ) para llegar a un consenso. Con base en esta observación, Lamport dedujo que en el caso de 3n nodos (n es un número contable) en el sistema, si hay al menos n nodos que son traidores, todo el sistema nunca puede llegar a un consenso. Entonces, en muchos otros artículos, siempre puede ver la siguiente declaración:
Si hay f nodos malvados, debe haber al menos 3 f + 1 nodos para que el sistema distribuido sea útil.
En el DPoS de aelf, si se lanza la red principal / de prueba de aelf, la configuración predeterminada es 2N + 1 BP, en el primer año N = 8, y N aumenta en 1 cada año. Hay 17 BP al principio. Si 13 (no más de 5 BP corrompen la red) se comportan normalmente, todos los BP finalmente llegarán a un consenso. Bajo esta condición, aelf define una ronda en la que cada paquete de BP se bloquea secuencialmente, y después de eso, aelf selecciona aleatoriamente un BP para empaquetar bloques. Después de esta ronda, barajamos la lista de BP y repetimos este proceso. La clave es que la secuencia de producción de bloques es lo suficientemente aleatoria como para evitar que los BP se tracen entre sí. Por supuesto, hay otros diseños involucrados, pero no necesitamos conocerlos para comprender cómo funciona AEDPoS.
Al igual que los DPoS comunes, la lista de BP siempre cambia en función de sus votos. Un nodo común puede votar por BP y candidatos en cualquier momento (la cadena de bloques aelf ahora admite esta función), y el sistema aelf verificará la clasificación todos los meses, los que están en la parte inferior serán reemplazados por nodos candidatos con clasificaciones más altas.