El principio de irreversibilidad de la cadena de bloques
¿Qué es un bloque irreversible? En VIZ, este parámetro afecta a cómo el nodo confirma la versión irreversible de la cadena de bloques. Si un fork llega al nodo a través del sistema p2p (cuyos bloques se refieren al bloque last_irreversible_block_num), simplemente no los tomara en cuenta. El principio de calcular un bloque irreversible es bastante simple: — three quarters (tres cuartos o 75%), pero ¿por qué? ¿Cómo sucede eso?
Este principio fue heredado junto con el código base. No está incluido en el protocolo y no afecta a ningún consenso dentro del sistema blockchain. Este es el comportamiento privado de cada nodo individual. A pesar de que la irreversibilidad de los bloques es un acto de confianza en los datos, el principio de los three quarters basado en la falta de voluntad para confiar en alguien. Por lo tanto, muchos se equivocan al entender el bloqueo irreversible ' irreversible block': — imponen a la variable las obligaciones del garante de que los bloques cuando en este límite no pueden modificarse. Pero este no es el caso: en caso de fallo de un nodo o aislamiento de Internet, es posible que algunos delegados continúen con sus interacciones y vayan a su propia bifurcación de la cadena (donde otros delegados queden fuera del aislamiento y los movimientos irreversibles independientemente). Al regresar a la red anterior, es probable que se vuelvan a sincronizar, abandonando los bloques en su propia bifurcación aislada.
El acto de confianza de la irreversibilidad de los bloques en sí viene siendo la confianza de que el nodo en particular considera que la cadena es irreversible. El principio de las tres cuartas partes se puede traducir básicamente en que un nodo no quiere confiar en alguien, pero se ve obligado a confiar, por lo que "condicionalmente" confía en el bloque si 3/4 (75%) delegados de la cola confían en él. Permítame recordarle que hay 21 lugares en la cola de delegados de VIZ, respectivamente, el nodo "condicionalmente" confía en la unidad si hay 15 delegados en la cadena con su participación.
Mi propuesta es finalmente consolidar la comprensión del irreversible block, no una garantía del sistema blockchain para la irreversibilidad de la cadena, sino un acto de confianza para la irreversibilidad de la cadena a un nodo en particular.
Por eso me propongo cambiar la comprensión del concepto: confiar no "por necesidad", sino que los propios participantes asuman la responsabilidad en la forma de esta confianza del nodo público o de los bloques de delegados. También vale la pena ofrecer opciones con diferentes principios de confianza:
- Circular trust — Confianza circular basada en la confianza consciente de los principales delegados. Si un delegado superior confirmó el bloque de otro delegado superior, esto es suficiente para confiar también en este bloque.
- Code is law — El código es la ley, el código de confianza. Es gracioso: todos decimos que el código es una ley, pero nadie trató de generar confianza sobre esta base. La experiencia de reemplazar la cadena en consenso Proof of Work ha socavado la credibilidad del código, cuando cualquiera podía declarar y mostrar un bloque válido. En los sistemas de blockchain con Fair DPoS consenso, hay un algoritmo para calcular la cola de delegados, hay reglas para contabilizar el peso transferido al votar por los delegados. ¿Por qué, entonces, generamos confianza en una mayoría calificada cuando tenemos una oportunidad concreta de confiar en el código? La validación de las operaciones en un bloque es una condición suficiente para descartar instancias no válidas del bloque. En este principio de cálculo de una unidad irreversible, una condición suficiente es verificar la validez, la correspondencia del delegado con su lugar en la cola.
Pareciera que estuviésemos atrapados en la Edad de Piedra. Mientras que los sistemas DLT se basan en un acto de confianza (sincronización de los contenidos de una unidad común), los sistemas de cadena de bloques utilizan el principio lento. ¿Cuántos delegados actuarían sobre el bloque? Si tenemos 15, entonces creemos, y si no lo tenemos, no lo hacemos.
Como resultado, los sistemas DLT llevaran ventaja tecnológica si no aprendemos a mostrar un acto de confianza y tomar la responsabilidad consciente de ello. Para pasar por alto el abismo del estancamiento conceptual, mi sugerencia:
- Incluir en VIZ la posibilidad de elegir el principio de contabilidad irreversible. Agregue nodos de principios irreversible-principle, que pueden configurarse en tree-quarters, en circural-trust y en el code-is-law.
- Complemente la operación get_dynamic_global_properties en la API de la base de datos expandiendo la matriz con la indicación del irreversible_principle utilizado por el nodo.
- Establezca el principio de confianza circular-trust para el archivo de configuración de nodo público recomendado.
Necesitamos aprender a confiar. Comencemos con la confianza de los principales delegados que ejecutan un código idéntico y proporcionan infraestructura para todos los participantes de la red. Solo una buena comprensión de esto permitirá a VIZ evolucionar y aumentar la capacidad de respuesta de la interacción del usuario.
PD un ejemplo sorprendente del uso ilógico de un estado irreversible: cientos de juegos en EOS y TRON, que funcionan con el estado actual de la cadena de bloques, ignorando completamente el número del último bloque irreversible. La gente confía en los proyectos, los nodos públicos y su estado, pero los nodos no quieren asumir responsabilidades y mostrar confianza en los delegados.
Actualizaciones:
Para aclarar, code-is-law se moverá de forma irreversible al bloque válido anterior. El bloque válido actual del delegado que toma su tiempo confirma el bloque válido anterior.
En el chat se nos pidió que aclaráramos no sobre ejemplos de juegos, sino sobre ejemplos financieros. Y ¿cuál es la diferencia? Si tiene un nodo sincronizado con lla red principal y lo "confía" en términos de validación del código, entonces puede decidir por sí mismo qué confirmación será "irreversible" para usted. Alguien puede contar 400 confirmaciones de bloque (el número de bloques después del requerido), alguien puede basarse en el número de delegados de la cola, alguien en una lista específica de delegados de confianza. En cualquier caso, debe resolver diferentes casos y diseñar el sistema, teniendo en cuenta varios escenarios en este caso la caída de Internet y la sincronización que se ha caído.
También vale la pena señalar que los sistemas de blockchain actuales están diseñados teniendo en cuenta la posible desconexión del servidor de Internet (Internet desapareció en un centro de datos en particular). Y qué pasará si hay aislamiento, por ejemplo, en Rusia, 6 nodos delegados están ubicados geográficamente en Rusia. Se conectaran, pero en los otros delegados comenzarán la falta de bloques para ellos. Como resultado, de acuerdo con la mecánica del código, su cadena expulsará a los delegados que hayan perdido muchos bloques. Y en la Internet aislada habrá un mini-fork del sistema blockchain. Convencionalmente, puede representarse como una rama de VIZ Russia y VIZ Worldwide en un bloque específico. Fuera de VIZ Rusia no estará disponible. Los servicios también serán compartidos. Aquellos servicios y aplicaciones que se encuentren geográficamente en un entorno aislado decidirán qué hacer. Mover o desarrollar un espacio aislado. Creo que este es un estado normal de cosas. Una especie de separación automática de la cadena en segmentos aislados. Simplemente entonces, los delegados tendrán que elegir en qué entorno realizar la actividad.