Nota: Esta página no está actualizada. Vea la hoja de ruta para conocer los planes actuales.

Más abajo hay una discusión detallada (aunque aún no completa) de las áreas más importantes del futuro desarrollo del núcleo de I2P, que abarca los posibles planes de desarrollo. Esto no incluye transporte oculto, portarlo a dispositivos Wireless o herramientas para asegurar la máquina local, tampoco incluye otras aplicaciones cliente que serían esenciales para el éxito de I2P. Probablemente aparecerán otros temas, especialmente si I2P recibe mas atención, pero estas son ls 'cosas importantes'. Vea también la hoja de ruta. ¿Quiere ayudar? ¡Únete!

Funcionamiento del núcleo.

• Base de datos de la red, NetworkDB, y ajustes del perfil y política de expulsión para grandes redes.

  Nos hemos tomado la libertad de usar unos atajos prácticos dentro de la base de datos de la red y la implementación de la gestión del perfil. Por ejemplo, no tenemos el código para sacar los perfiles de los pares de K-buckets, al igual que no tenemos suficientes pares para llenar ninguno de ellos, en lugar de eso mantenemos los pares en cualquier cubo que pueda ser apropiado. Otro ejemplo tiene que ver con los perfiles de los pares - la memoria requerida para mantener cada perfil del par es suficientemente pequeña como para poder tener todos los perfiles en la memoria sin problemas (con lo que podemos mantener cientos de miles en la memoria), no tenemos ningún código para lidiar con el problema de mover un perfil de un "perfil mínimo" a un "perfil completo", de un "perfil completo" a un "perfil mínimo", o simplemente desechar un perfil completo. Simplemente no sería práctico escribir el código ya que no lo vamos a necesitar por un tiempo.

  Como ya hemos dicho, según siga creciendo la red volveremos a retomar estas consideraciones. Tendremos algún trabajo por hacer, pero se puede dejar para mas tarde.

Seguridad / anonimato

• Mejor personalización de los ruters y un mejor control de los ruters usados.

  La funcionalidad restringida del ruter descrita antes era simplemente un problema funcional - cómo hacer que dos pares que de otra forma no estrían comunicados se comuniquen. Sin embargo, el concepto de permitir ruters restringidos incluye capacidades adicionales. Por ejemplo, si un ruter no puede arriesgarse de ninguna forma a una comunicación directa con un par sin confianza, pueden configurar enlaces seguros a través de esos pares, usándolos para enviar y recibir todos sus mensajes. Esos pares ocultos que desean estar totalmente aislados pueden también negarse a conectar con pares que intenten alcanzarles (como se demuestra en la técnica de ruteado 'garlic' esbozada anteriormente)

• Añadir Hashcash a la identidad del ruter, destinación y solicitud de respuesta.

  Dentro de la red necesitaremos una forma de disuadir al a gente de consumir demasiados recursos o de crear demasiados pares como para montar un ataque Sybil. Las técnicas tradicionales como dejar que un par vea quien solicita un recurso o quien ejecuta cierto par, no son apropiadas para I2P, ya que eso comprometería el anonimato del sistema. En su lugar queremos hacer que ciertas peticiones sean muy "caras".

  Hashcash es una técnica que podemos usar anónimamente para incrementar el "costo" de hacer ciertas acciones., como crear una nueva identidad de ruter (se hace sólo cuando se instala por primera vez), crear una nueva destinación (se hace sólo cuando se crea un nuevo servicio), o solicitar que un par participe en un túnel (se hace a menudo, quizás 2-300 veces a la hora). No conocemos todavía el coste "correcto" de cada tipo de certificado, pero con algo de investigación y estudio, podemos crear un nivel básico que sea lo suficientemente caro pero no tan caro como para que agobie a la gente con pocos recursos.

  Hay varios algoritmos que podemos explorar para hacer que esas peticiones de recursos "tengan un costo", sería conveniente seguir investigando sobre este tema.

• Control avanzado del funcionamiento del ruter (procesamiento por lotes/mezclado/control de velocidad)

  El rutado estándar de túneles es vulnerable al análisis de tráfico para los observadores externos pasivos con muchos medios y para un gran número de observadores internos si están confabulados, simplemente observando el tamaño y la frecuencia de los mensajes que pasan a través de los ruters. Para defendernos de esto, queremos simplemente convertir algunos túneles en su propia mezcla de cascada - retrasando los mensajes recibidos en la puerta de salida y pasándolos en lotes, reordenándolas como sea necesario, e inyectando mensajes de relleno (indistinguibles de los túneles "reales" para los pares). Ha habido un gran número de estudios sobre estos algoritmos que podríamos utilizar para implementar varias estrategias de mezclado de túneles.

  Además de los aspectos del anonimato en las operaciones de los túneles, hay una dimensión funcional extra. Cada par sólo tiene cierto número de datos que pueden rutar por la red, y para evitar que un túnel en particular consuma una gran parte del ancho de banda, necesitarán añadir algunas regulaciones en el túnel. Por ejemplo, un túnel puede estar configurado para pararse a sí mismo después de pasar 600 mensajes (1 par por segundo), 2.4MB (4KBps), o tras haber excedido algún promedio variable (8KBps en el último minuto). Los mensajes sobrantes pueden ser retardados o desechados. Con este tipo de control, los pares pueden ofrecer un soporte parecido al QoS en sus túneles, negándose a asignar más ancho de banda de la que el par tiene disponible.

  Además, queremos implementar el código para re-rutar los túneles dinámicamente, y así evitar que los pares fallidos añadan saltos adicionales en el camino. Esto lo puede hacer la red garlic rutando un mensaje a un par en particular con las instrucciones para redefinir el siguiente salto del túnel.

• Configuración avanzada del enrutamiento de los túneles y opciones para crear túneles de usar y tirar para su uso a corto plazo.

  Además de las estrategias de mezclado y de procesado por lotes de cada túnel, hay más formas de protegernos contra atacantes poderosos, como permitir crear un retraso en cada paso dentro de un camino de rutado garlic. Esto crearía protecciones contra un ataque largo de intersección, ya que un par podría enviar mensajes que parecen normales a la mayoría de los pares, excepto a cualquier par donde se hayan dado instrucciones de retardo.

Rendimiento

Las mejoras en el rendimiento se listan en la página de rendimiento .