Introducción

La hoja de ruta de Ethereum incorpora una tecnología de escalamiento llamada muestreo de disponibilidad de datos (DAS) 6. DAS presenta nuevos<a href="https://notes.ethereum.org/ @djrtwo /das-requirements">requisitos 4 a la pila de redes de Ethereum, lo que requiere la implementación de protocolos de redes especializados 7 . Un <a href="https://notes.ethereum.org/@dankrad /S-Kademlia-DAS"> protocolo destacado La propuesta 4 utiliza una tabla hash distribuida (DHT) basada en Kademlia 2 para almacenar y recuperar las muestras de los datos.

Sin embargo, los DHT 4 son susceptibles a los ataques Sybil: un atacante que controla una gran cantidad de nodos DHT puede hacer que las muestras DAS no estén disponibles. Para contrarrestar esta amenaza, se puede establecer una capa de red de alta confianza, compuesta únicamente por validadores de cadenas de balizas. Esta medida de seguridad eleva significativamente la barrera para los atacantes, ya que ahora deben apostar su propio ETH para atacar el DHT.

En esta publicación, presentamos un protocolo de prueba de validador, que permite a los participantes de DHT demostrar, sin conocimiento, que son un validador de Ethereum.

Motivación: Ataque de “ocultación de muestras” al DAS

En esta sección, motivamos aún más la prueba del protocolo de validación al describir un ataque Sybil contra el muestreo de disponibilidad de datos.

El protocolo DAS gira en torno al generador de bloques, lo que garantiza que los datos del bloque estén disponibles para que los clientes puedan recuperarlos. Los enfoques actuales implican dividir los datos en muestras, y los participantes de la red solo obtienen muestras que corresponden a sus intereses.

)

Considere un escenario en el que un atacante de Sybil quiere evitar que los participantes de la red obtengan muestras de un nodo víctima, que es responsable de proporcionar la muestra. Como se muestra en la figura anterior, el atacante genera muchos ID de nodo que están cerca del ID de nodo de la víctima. Al rodear el nodo de la víctima con sus propios nodos, el atacante impide que los clientes descubran el nodo de la víctima, ya que los nodos malignos retendrán deliberadamente información sobre la existencia de la víctima.

Para obtener más información sobre dichos ataques Sybil, consulte este reciente artículo de investigación 2 sobre ataques DHT Eclipse. Además, <a href="https://notes.ethereum.org/ @dankrad /S-Kademlia-DAS#SKademlia-modifications">Dankrad La propuesta 8 del protocolo de red DAS describe cómo el protocolo DHT de S/Kademlia sufre tales ataques y muestra la necesidad de un protocolo de prueba de validación.

Prueba de validador

El ataque anterior motiva la necesidad de un protocolo de prueba de validador: si solo los validadores pueden unirse al DHT, entonces un atacante que quiera lanzar un ataque Sybil también debe apostar una gran cantidad de ETH.

Al utilizar nuestro protocolo de prueba de validador, nos aseguramos de que solo los validadores de la cadena de balizas puedan unirse al DHT y que cada validador obtenga una identidad DHT única.

Además, para la resistencia DoS del validador, también pretendemos ocultar la identidad de los validadores en la capa de red. Es decir, no queremos que los atacantes puedan saber qué nodo DHT corresponde a qué validador.

Para cumplir con estos objetivos, la prueba del protocolo del validador debe cumplir con los siguientes requisitos:

• Unicidad: cada validador de cadena de balizas debe poder derivar un par de claves único y único. Esta propiedad no solo restringe la cantidad de nodos que un atacante Sybil puede generar, sino que también permite a los participantes de la red castigar localmente los nodos que se comportan mal al incluir en una lista bloqueada su par de claves derivado.
• Privacidad: los adversarios no deben poder saber qué validador corresponde a una clave pública derivada en particular.
• Tiempo de verificación: el proceso de verificación del protocolo debe ser eficiente y tomar menos de 200 ms por nodo, lo que permite que cada nodo aprenda al menos cinco nodos nuevos por segundo.

Bob utilizaría dicha prueba de protocolo de validación durante el establecimiento de la conexión en la capa DHT, para que Alice sepa que está hablando con un validador.

Protocolo de prueba del validador

Nuestro protocolo de prueba de validador es efectivamente un simple esquema de credenciales anónimas. Su objetivo es permitir a Alice generar una clave derivada única, denominada D, si y sólo si es una validadora. Posteriormente, Alice utiliza esta clave derivada D dentro de la capa de red.

Al diseñar este protocolo, nuestro objetivo era crear una solución que fuera sencilla de implementar y analizar, garantizando que cumpliera con los requisitos descritos de manera eficiente.

Descripción general del protocolo

El protocolo emplea un subprotocolo de prueba de membresía, en el que Alice demuestra que es una validadora demostrando conocimiento de una preimagen hash secreta utilizando pruebas ZK. Luego, Alice construye un par de claves único derivado de esa preimagen hash secreta.

Se puede crear una instancia del subprotocolo de prueba de membresía mediante diferentes métodos. En esta publicación, mostramos un protocolo que usa árboles Merkle y un segundo protocolo que usa búsquedas.

Si bien ambos enfoques demuestran una eficiencia aceptable, presentan distintas compensaciones. Los árboles Merkle se basan en funciones hash compatibles con SNARK como Poseidon (que puede considerarse experimental). Por otro lado, los protocolos de búsqueda eficientes se basan en una configuración confiable de poderes de tau de tamaño igual al tamaño del conjunto de validadores (actualmente 700.000 validadores, pero en aumento).

Ahora profundicemos en los protocolos:

° 1: árboles Merkle

Los árboles Merkle han tenido un uso generalizado como prueba de membresía (p. ej. ver Semáforo 3). Aquí está el espacio de compensación al diseñar una prueba de membresía utilizando árboles Merkle:

• Positivo: no es necesaria una configuración confiable
• Positivo: Fácil de entender
• Negativo: se basa en funciones hash compatibles con SNARK como Poseidon
• Negativo: creación de pruebas más lenta

A continuación describimos la prueba del protocolo de validación basado en árboles Merkle:

Protocolo de prueba de validador utilizando árboles Merkle

)

Al final del protocolo, Alice puede usar D en DHT para firmar mensajes y derivar su identidad única de nodo DHT.

Ahora veamos una solución un poco más complicada, pero mucho más eficiente, que utiliza búsquedas.

° 2: búsquedas

Aquí está el espacio de compensación de usar protocolos de búsqueda 2 como Caulk 2:

• Positivo: creación de pruebas extremadamente eficiente (mediante una fase de preprocesamiento)
• Positivo: el protocolo se puede adaptar para utilizar una función hash normal en lugar de Poseidón
• Negativo: Requiere una configuración confiable de gran tamaño (idealmente igual al tamaño de los validadores)

A continuación describimos una prueba concreta del protocolo de validación:

Prueba del protocolo del validador mediante búsquedas

Exactamente como en el enfoque Merkle, cada validador i registra un nuevo valor pi en la cadena de bloques tal que:

Eficiencia

Comparamos el tiempo de ejecución de nuestro protocolo de prueba de membresía (enlace 6 al código de referencia 5) en términos de creación y verificación de pruebas. Tenga en cuenta que, si bien la prueba de membresía es solo una parte de nuestro protocolo de prueba de validación, esperamos que domine el tiempo de ejecución general.

A continuación proporcionamos resultados de referencia para una prueba de membresía del árbol Merkle utilizando el sistema de prueba Halo2 con IPA como esquema de compromiso polinomial. IPA es un esquema más lento que KZG pero no requiere una configuración confiable que maximice las ventajas del enfoque del árbol merkle.

Observamos que tanto los tiempos del probador como del verificador se alinean bien con nuestros requisitos de eficiencia. Por este motivo, decidimos no realizar una evaluación comparativa del enfoque basado en Caulk, ya que se espera que su rendimiento sea significativamente mejor en todas las categorías (especialmente el tiempo de prueba y el tamaño de la prueba).

Los puntos de referencia se recopilaron en una computadora portátil con una CPU Intel i7-8550U (CPU de cinco años).

Discusión

Identidades rotativas

La propiedad de unicidad del protocolo de prueba de validación garantiza que cada participante de la red posea un par de claves derivado distinto. Sin embargo, para ciertos protocolos de red, podría resultar ventajoso permitir que los validadores tengan identidades rotativas, donde sus claves derivadas cambien periódicamente, tal vez diariamente.

En tal escenario, si Eve se porta mal en un día en particular, Alice puede incluirla en la lista de bloqueo para ese día. Sin embargo, al día siguiente, Eve puede generar una nueva clave derivada, que no está en la lista bloqueada. Si quisiéramos poder bloquear permanentemente a los validadores en función de su identidad rotativa, necesitaríamos un esquema de credenciales anónimas más avanzado como SNARKBlock 1.

¿Por qué no utilizar la clave pública de identidad BLS12-381?

Un enfoque alternativo (quizás más simple) sería crear un compromiso a partir de todas las claves de identidad del validador BLS12-381 y realizar una prueba de membresía de ese compromiso.

Sin embargo, este enfoque requeriría que los validadores insertaran su clave privada de identidad en el sistema de prueba ZK para crear una prueba de membresía válida y calcular la clave derivada única.

Decidimos no adoptar este enfoque porque no es una buena práctica insertar claves de identidad confidenciales en un protocolo criptográfico complicado y también haría más difícil para los validadores mantener su clave de identidad principal fuera de línea.

Direcciones de investigación futuras

• ¿Podemos evitar por completo los circuitos SNARK y realizar la prueba de membresía y la derivación de claves de una manera puramente algebraica?
• Relacionado: ¿Podemos tener un protocolo de prueba de membresía eficiente sin una configuración confiable y sin depender de funciones hash compatibles con SNARK?

Agradecimientos

Gracias a Enrico Bottazzi, Cedoor, Vivian Plasencia y Wanseob por la ayuda para navegar por la web de bases de códigos de prueba de membresía.

Descargo de responsabilidad:

1. Este artículo está reimpreso de [ethresear]. Todos los derechos de autor pertenecen al autor original [George Kadianakis, Mary Maller, Andrija Novakovic, Suphanat Chunhapanya]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: Th
   Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas están a cargo del equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.