Red de Respuestas Legales - Directorio de abogados - Una breve revisión de tres algoritmos de reconocimiento * * * basados ​​en VRF

Una breve revisión de tres algoritmos de reconocimiento * * * basados ​​en VRF

¿Compañía de tecnología de la Bolsa de Valores de Shanghai? Zhu Li

Algorand, Dfinity, Ouroboros Praos (aunque Dfinity es el nombre del proyecto, no está mal llamarlo el algoritmo * * * aquí) han atraído más atención recientemente, y todos se basan en diseño VRF (función aleatoria verificable) Sí, se puede comparar y estudiar. Hay muchas versiones de Algorand. ¿A cuál de las siguientes se refiere? 1607.05438+0341V9, llamado temporalmente algrand' (el autor tiene la última versión de algrand, que soluciona varios problemas que se mencionan a continuación; consulte este artículo).

1. VRF * * *

El significado de VRF es fácil de entender: se utiliza para completar la selección aleatoria de personas (grupos). Por lo tanto, el valor de retorno de VRF debería ser lo más impredecible posible. Primero echemos un vistazo a cómo funcionan las rutinas de Algorand y Dfinity: en términos generales, el número aleatorio anterior (el número aleatorio inicial lo proporciona el protocolo) se combina con una variable que representa la altura y el giro, utilizando una determinada clave privada Signo (o signo primero y luego combinar), y finalmente hash para obtener el último número aleatorio. Otros pueden verificar fácilmente que los números aleatorios generados de esta manera cumplan con el algoritmo, obteniendo así "V" y el valor de retorno hash se distribuye aleatoriamente, por lo que se garantiza "r". En este proceso, para reducir la posibilidad de manipulación de los resultados, hay dos puntos a tener en cuenta: a) El algoritmo de firma debe ser único Incluso si se utiliza la misma clave privada para firmar el mismo mensaje, sólo una firma legítima. se puede verificar: los algoritmos de cifrado y descifrado asimétricos ordinarios generalmente no tienen esta propiedad, como SM2. Si el algoritmo de firma utilizado no tiene esta propiedad de unicidad, al generar nuevos números aleatorios, hay espacio para probar firmas repetidamente para elegir la más ventajosa, lo que reducirá la seguridad. b) Evite utilizar los datos del bloque actual como una de las fuentes de aleatoriedad al generar nuevos números aleatorios, como hacer referencia al valor raíz de merkle de la lista de transacciones de este bloque. , porque esto le dará al bloque maestro espacio para intentar cambiar el orden de empaquetar las transacciones, empaquetar diferentes transacciones y generar los nuevos números aleatorios más ventajosos. Al diseñar y probar nuevos algoritmos de reconocimiento de sexo, se debe prestar especial atención a los dos puntos anteriores.

Compruebe cómo se deben utilizar los resultados de retorno de VRF. En el uso actual, los resultados devueltos por VRF se pueden utilizar para completar la selección de nodos o grupos de nodos públicos o privados. Tomemos como ejemplo Dfinity, que utiliza la operación mod para determinar de forma única y pública un grupo. "Algorand" y "Ouroboros Praos" son ejemplos de selecciones privadas. La rutina general es utilizar variables como rondas para firmar y aplicar hash al último valor de retorno del VRF. Si el valor hash es inferior a un cierto umbral, el nodo puede saber que fue elegido de forma privada. Es probable que este método sea más estable cuando la cantidad de nodos de red es grande; de ​​lo contrario, la cantidad de afortunados fluctuará mucho, lo que afectará el rendimiento del protocolo, incluidos los bloques vacíos y las bifurcaciones.

En segundo lugar, comente brevemente la versión de Algorand de la hipótesis de la sincronización fuerte.

La selección privada proporciona una fuerte resistencia a los ataques de punto fijo, pero para cualquier persona afortunada, el número total de la persona afortunada es impredecible, lo que trae dificultades para el diseño de algoritmos de identificación posteriores y la optimización de la cadena de bloques. Algorand '' adopta el supuesto de red de sincronización fuerte (el algoritmo de identificación * * * bajo el supuesto de red de sincronización es, por supuesto, más fácil de realizar) y requiere conocer el límite superior del tiempo de propagación de mensajes de red de antemano: completar la propagación de red en una proporción fija de usuarios en un tiempo determinado. Por ejemplo, necesita saber que un mensaje de 1 KB se puede propagar al 95 % de toda la red en 1 segundo, mientras que un mensaje de 1 MB necesita 1,5 minutos para propagarse al 95 % de toda la red. ¿Pero cómo elegir este límite de transmisión? ¿Multiplicar los resultados estadísticos durante un período de tiempo por un coeficiente mediante estadísticas empíricas? Solo puedo decir que "se siente bien", pero para que sea riguroso y seguro, el algoritmo Algorand '' necesita demostrar adicionalmente que en el caso de DDOS o congestión de Internet, incluso si la propagación del mensaje excede seriamente el límite, el algoritmo aún puede garantizar la seguridad; sin embargo, falta esta prueba. Por el contrario, Ouroboros Praos admitió públicamente que el protocolo Ouroboros diseñado bajo el supuesto de redes síncronas fallaría en condiciones de red asíncronas, por lo que volvimos a crear Ouroboros Praos.

La nueva versión de Algorand admite que * * * el conocimiento se alcanzará en diferentes bloques cuando la red esté débilmente sincronizada (las bifurcaciones se pueden resolver más adelante cuando la red esté fuertemente sincronizada), lo que puede usarse como referencia.

Incluso si aceptamos temporalmente que el algoritmo de Algorand puede resolver los problemas anteriores estableciendo un límite superior de tiempo de propagación mayor, se puede ver que este algoritmo carece de una característica muy buena: la capacidad de respuesta. Esta propiedad significa que si un protocolo está diseñado para funcionar con un delta de tiempo de propagación superior grande, pero si el tiempo de propagación real es un delta más pequeño, entonces el progreso real del protocolo solo estará relacionado con el delta, y el protocolo se llama reactivo. Sería ideal combinar el algoritmo de identificación * * * con la suposición de red síncrona: por seguridad, el límite superior se puede establecer muy grande, pero la velocidad de ejecución del protocolo solo está relacionada con las condiciones de la red en ese momento. "Algrande" no tiene esta característica. En promedio, Algorand 'requiere 11 rondas de transmisión de mensajes para completar ** el conocimiento. Si es necesario garantizar la seguridad en cada ronda, entonces * * * el conocimiento tardará mucho en completarse y el rendimiento de una sola partición no será demasiado alto. Por supuesto, el diseño arquitectónico implica muchas compensaciones. Al final, para evaluar si un algoritmo es bueno o no, todavía tenemos que volver a la intención original: cuál es el objetivo a alcanzar. El análisis anterior es solo un intento de señalar objetivamente varias características inherentes poco conocidas del algoritmo Algorand para que los lectores puedan evaluarse a sí mismos.

En tercer lugar, un breve repaso a la escalabilidad de Dfinity

La práctica de seleccionar de forma privada y asumir el cargo de forma inmediata también trae grandes desafíos a la segmentación institucional. Dfinity debe fragmentarse, por lo que debemos afrontar el desafío de frente. La cuestión de la escalabilidad es compleja. Para resolver completamente este problema, debemos considerar la escalabilidad de la red, el almacenamiento y la informática. En la actualidad, la mayoría de los proyectos blockchain 3.0 solo se centran en la fragmentación y escalabilidad informática, ignorando los otros dos, por lo que no pueden lograr una expansión ideal. Debido a la limitación del ancho de banda de la red de nodos de la cadena pública, generalmente es difícil copiar rápidamente los datos necesarios para calcular el contrato de un nodo a otro, por lo que incluso si se usa VRF para seleccionar nodos que van y vienen de vez en cuando, el nodo de almacenamiento no puede ser tan elegante como el viento. Hay algunas opciones obvias: todos los nodos almacenan todos los datos y diferentes nodos se asignan estáticamente para almacenar diferentes particiones. El primero tiene poca escalabilidad. Para este último, si el nodo saliente flota, el nodo saliente debe completar la operación del contrato, lo que significa que el rendimiento del acceso de ida y vuelta al almacenamiento remoto basado en la red P2P disminuirá drásticamente. Los nodos de fragmentos determinados dinámicamente que solo realizan clasificación, potencia informática y agrupación de almacenamiento, proporcionando escalabilidad a través de particiones estáticas, pueden ser una respuesta razonable. Sin embargo, lo más odioso es la palabra "sin embargo"; aun así, todavía hay presión sobre el almacenamiento y la red en el sistema: las transacciones enviadas por los usuarios finales deben empaquetarse. El ancho de banda de las cadenas públicas ordinarias (sin considerar EOS) es limitado. Si las transacciones enviadas por los usuarios para empaquetar deben distribuirse ampliamente en toda la red, ¿cuántos TPS puede proporcionar el ancho de banda de la red existente? Si los nodos de salida están particionados estáticamente o al menos son conocidos por el público con cierta antelación, todavía hay margen de maniobra si los nodos de salida son tan erráticos y sólo estos nodos no son conocidos hasta el último momento, ni el usuario ni el usuario; Candidatos para el nodo saliente, parece que la reacción más directa es inundar toda la red y guardar todas las transacciones para empaquetarlas, de modo que el ancho de banda y el almacenamiento sigan convirtiéndose en el cuello de botella del sistema.

Entonces, lo que encontramos aquí es esencialmente una trinidad imposible de seguridad, escalabilidad y descentralización.

En cuarto lugar, un breve comentario sobre Praos, la gran serpiente venenosa.

Las obras de BMŭ·The Great Poisonous Snake han tenido una amplia circulación. Por supuesto, lo que dijo BM es obviamente incorrecto. Por ejemplo, el DPOS de Bushmaster se refiere a "POS dinámico [distribución de pila]" en lugar del POS delegado de BM, pero vale la pena reflexionar sobre sus comentarios sobre la distribución de Pareto. Si miramos más de cerca a Ouroboros Praos, podemos encontrar que los supuestos de seguridad y los certificados de seguridad del protocolo no tienen en cuenta los factores económicos del juego, por lo que es probable que la prueba plausible pierda la dirección que realmente necesita ser protegida. - después de todo, la sangre que corre por las venas del protocolo POS/DPOS siempre se ha basado en juegos económicos y en la naturaleza humana. El ejemplo más obvio es la implementación de firmas de seguridad directas. El diseño actual del protocolo requiere que cada nodo bueno elimine de forma voluntaria y segura las claves privadas utilizadas, sin considerar cómo el costo casi nulo de almacenamiento de claves privadas enfrenta la tentación de ataques de soborno. Sin embargo, vale la pena considerarlo.

Aparte de las pruebas formales, Ouroboros Praos no tiene muchas características protocolarias destacables. En general, utiliza la lotería VRF combinada con el algoritmo POS para probar formalmente algunos supuestos de seguridad, y su actitud es muy encomiable.

Resumen de verbo (abreviatura de verbo)

Estos algoritmos son muy creativos y vale la pena aprenderlos. Al mismo tiempo, después de leer la tecnología de partición revelada por CASPER de Ethereum, la experiencia del autor es que la competencia por blockchain 3.0 acaba de comenzar. A juzgar por la ruta técnica del equipo de Ethereum, sus consideraciones y opciones técnicas son más profundas y completas que las de muchos equipos que afirman superar a Ethereum. Si realmente queremos ir más allá de Ethereum, primero debemos entender Ethereum.

Por cierto, ¡me gustaría agradecer al Dr. Qiu Weiwei por su contribución a este artículo!