La tabla `new` entra en consideración
Acabamos de hablar acerca de la tabla probada, argumentando que si las direcciones se seleccionan de las probadas y las nuevas al azar, el único efecto que tendría sería aumentar el número de grupos (por lo tanto, se requieren más direcciones del atacante). Lo primero es cierto siempre que la nueva tabla se comporte de manera similar a la tabla probada. La verdad es que podemos restringir aún más a un atacante con dos contramedidas adicionales en la nueva tabla:
Las conexiones entrantes no pueden enviar direcciones para insertarse en la nueva tabla (Mensajes ADDR). Es decir, es el mismo interlocutor el que puede solicitar estos mensajes (cuando se da cuenta de que la nueva tabla está lo suficientemente vacía) y solo a las conexiones salientes. Esto evita la contaminación de la mesa probada siempre y cuando las conexiones salientes sean honestas. conexión del sensor se encarga de establecer conexiones de corta duración con direcciones en la nueva tabla. Si tienen éxito, se insertan en el intento (si la prueba antes de desalojar lo permite).
Mientras que la primera contramedida evita que una conexión maliciosa entrante contamine la nueva tabla con sus propias direcciones, la segunda valida la integridad de las conexiones alojadas en la nueva. Estas dos contramedidas tienen un impacto en el enfoque seleccionado por el atacante. Tenga en cuenta que, bajo el supuesto de que las direcciones en las nuevas son legítimas, un atacante no solo tiene que contaminar la tabla probada, sino que también debe tener la suerte de que al menos el c por ciento de las conexiones salientes se seleccionen de las probadas, siendo c el porcentaje de consenso necesario para sincronizar. Al modelar la selección de las tablas como un binomio Z con probabilidad 0.5, la probabilidad de éxito para un atacante es:
Número de conexiones seleccionadas de probadaProbabilidad de eclipsar cuando las direcciones se seleccionan de probadas y nuevas al azar y las direcciones en las nuevas son honestas
Como antes, trazamos la probabilidad acotada para el atacante en tal escenario para un número diferente de pares salientes, c = 0.8 y 20% adicional de conexiones de anclaje.
Probabilidad limitada por atacante para un número diferente de pares salientes que requieren al menos un 80% de consenso con un 20% de conexiones de anclaje y direcciones seleccionadas al azar de probadas y nuevas
Observamos aquí una probabilidad mucho más agradable. De hecho, con 10 conexiones salientes (más 2 anclas), observamos que un atacante puede estar limitado a un 0.1% de probabilidad con tan solo un 3% de la tabla llena de direcciones honestas.
El análisis mencionado anteriormente se realizó asumiendo que las direcciones provenientes de nuevas son honestas. Argumentamos que es probable que esto sea cierto por las siguientes razones:
Las direcciones en Nuevo solo se insertan cuando se solicita, y esta solicitud solo se realiza a las conexiones salientes. Por lo tanto, es probable que aunque la tabla probada pueda ser fácilmente contaminada, la nueva tabla contenga una cantidad significativa de direcciones legítimas. Si un atacante desea ejecutar una ronda múltiple (varios ataques de reinicio) enfrentará dos desafíos principales. Primero, la nueva tabla debe estar lo suficientemente vacía para que el nodo solicite a las conexiones salientes que se inserten las direcciones. El primero ya requiere que un atacante monopolice una gran parte de las conexiones salientes, incluso en el caso de que sus compañeros honestos informen direcciones repetidas, como La selección del grupo en la nueva también tiene en cuenta las direcciones IP de origen. Segundo, Si la nueva tabla está lo suficientemente vacía, es porque la conexión del detector ha logrado insertar suficientes direcciones honestas de respuesta en la tabla probada. Por lo tanto, las direcciones honestas monopolizan ahora la tabla probada. ¡El costo, el tiempo y las direcciones IP para llenar la mayoría de ambas tablas con direcciones de atacantes ya deberían desalentar al atacante de intentarlo!
Para Sistema que requiere 80% de consenso con 20% de conexiones de anclaje. (Suponiendo que estos sean honestos), un atacante tendría que monopolizar cada conexión saliente.
La Tabla 1 muestra la probabilidad de ataque acotada con solo 0.01 direcciones (p * h / tablesize) para diferentes parámetros de porcentaje de consenso.
Se requiere un consenso frente a la probabilidad de que un atacante pueda hacer una bifurcación de nodo eclipsada
Como el consenso es paramétrico, recomendamos un porcentaje mínimo de consenso del 60%.
Para llevar – Parámetros de Witnet bucketing
Teniendo en cuenta las discusiones anteriores, en Witnet estamos considerando adoptar el sistema de distribución de la siguiente manera:
Tres mesas Se implementan, nuevas, probadas y ancladas. Las La nueva tabla contiene direcciones que no se han probado (o que hayan sido desalojados previamente de los juzgados). El intento contiene direcciones a las que el par ha establecido recientemente una conexión. La tabla de anclaje contiene referencias a las conexiones de salida establecidas. La nueva tabla solo se puede rellenar a petición del par a sus conexiones salientes, que solo sucederán si la nueva tabla está lo suficientemente vacía. El número de direcciones que se envían se especifica en (1).64 cubos serán presentados en probados, mientras 256 cubos serán presentados en nuevos. Cada una contendrá 64 ranuras, y la asignación de IP-bucket se hará como en (1). La tabla de anclaje solo contendrá las direcciones salientes.12 conexiones salientes Se presentarán, 2 de los cuales provienen de la tabla de anclaje.Desalojo y selección de direcciones., tanto de mesas como de cubos, son elegidos al azar.Antes de desalojar una dirección de un intento, se comprueban las direcciones potencialmente desalojadas. Si tiene éxito, la dirección no es desalojada.Una única conexión de sensores establecerá conexiones de corta duración con direcciones en nuevos. En caso de éxito, estos se insertarán en el intento. El número de conexiones entrantes permanecerá como en Bitcoin.
