Заметка: эта страница устарела. Смотрите план разработки для текущих планов.

Ниже приведено более детальное (еще не завершенное) обсуждение основных областей будущей разработки ядра сети I2P, охватывающее планируемые релизы. Оно не включает в себя транспорт stego, портирование на беспроводные устройства, или способы обезопасить локальную машину, также не включает в себя клиентские приложения, что будет иметь важное значение для успеха I2P. Возможно, появятся и другие вещи, особенно, когда на I2P будет больше рецензий, но нижеприведенное - это главные 'большие вещи'. Смотрите также roadmap. Хотите помочь? Участвуйте!

Основная функциональность

• NetworkDB, настройка профиля и политика исключения для больших сетей

  В рамках реализации нынешней базы данных сети и управления профилями мы используем несколько практичных упрощений. Например, у нас нет кода, реализующего удаление узла из K-bucket'ов, т.к. у нас нет достаточного количества узлов, чтобы даже приблизительно заполнить все bucket'ы, вместо этого мы просто храним узлы в любых подходящих bucket'ах. Другой пример - работа с профилями узлов - размер памяти, необходимой для хранения профиля каждого узла, достаточно мал, так что мы можем хранить тысячи полных профилей в памяти без проблем. До тех пор пока у нас есть возможность использовать урезанные профили (мы можем хранить их 100-ми тысяч в памяти), у нас нет кода для преобразования профиля из "минимального профиля" в "полный профиль", из "полного профиля" в "минимальный профиль", или просто для выбрасывания обоих профилей. Пока написание такого кода не будет иметь практического значения, т.к. в ближайшее время он не будет нам нужен.

  Как было упомянуто, с ростом сети мы будем помнить об этих моментах. У нас есть над чем поработать, но мы можем отложить это на потом.

Безопасность / анонимность

• Полностью разорванные n-прыжковые ограниченные маршруты с необязательными доверенными ссылками

  Функциональность ограниченных маршрутов, описанная ранее, была просто способом дать возможность подключаться узлам, которые не могут сделать это иначе. Тем не менее, концепция ограниченных маршрутов добавляет дополнительные возможности. Например, если маршрутизатор не может рисковать, подключаясь напрямую к любым ненадежным узлам, он может установить доверенные ссылки через эти узлы, используя их для отправки и получения всех сообщений. Скрытые узлы, которые хотят быть абсолютно изолированными, также будут избегать подключений к узлам, которые хотят достучаться до них (как ранее продемонстрировано методом чесночной маршрутизацией) - они могут взять один чесночный зубчик, который требуется доставить определенному узлу, и маршрутизировать это сообщение в туннель, через доверенную ссылку одного из скрытых узлов с предписанием переслать его согласно запросу.

• Hashcash для запросов идентификатора маршрута, пункта назначения и туннеля

  В рамках сети мы хотим удержать людей от выделения слишком большого количества ресурсов или от создания слишком большого количества узлов для осуществления атаки Sybil. Традиционный подход с наличием узла, просматривающего, кто запрашивает ресурс, или запуск узла, не подходящего для использования в I2P, скомпрометирует анонимность системы. Вместо этого мы хотим сделать такие запросы "дорогостоящими".

  Hashcash - один из методов, который мы можем использовать для анонимного увеличения "стоимости" такой активности, использование идентификатора нового маршрутизатора (выполняется только один раз во время установки), создание нового пункта назначения (выполняется только один раз когда создаем сервис), или запрос на участие узла в туннеле (выполняется часто, возможно 2-300 раз в час). Нам пока неизвестна "точная" стоимость каждого типа удостоверения, но после исследований и экспериментов мы сможем установить начальный уровень, который будет достаточно дорогостоящим и не будет сильно обременять людей с ограниченными ресурсами.

  Есть еще несколько других алгоритмов, которые мы можем использовать для "удорожания" подобных запросов, и дальнейшие исследования на этом фронте являются целесообразными.

• Расширенные операции над туннелем (пакетирование/смешивание/регулирование/изменение размера)

  Для мощных пассивных внешних наблюдателей, так же как и для больших сговоров внутренних наблюдателей, стандартная туннельная маршрутизация уязвима для атак с анализом трафика - простое наблюдение за размером и частотой сообщений, передаваемых между маршрутизаторами. Чтобы защититься от этого мы хотим скомпоновать некоторые туннели в смешанный каскад - задерживая сообщения, полученные на шлюзе и отправляя их в группы, при необходимости пересортировывая их, внедряя пустые сообщения (неотличимые для узлов от других "реальных" туннельных сообщений). Было выполнено колоссальное количество исследований этих алгоритмов, на которые мы можем опираться при реализации различных стратегий смешивания туннелей.

  Наряду с аспектами анонимности большего количества операций над туннелями, есть и функциональная составляющая. У каждого узла есть определенное количество данных, которые он может маршрутизировать для сети, и чтобы уберечь определенный туннель от необоснованного использования полосы пропускания, они захотят добавить некий регулятор в туннель. Например, туннель может быть сконфигурирован на самоограничение после прохождения 600 сообщений (1 в секунду), 2.4МБ (4КБ/с), или по достижении некоего изменяемого порога (8КБ/с за последнюю минуту). Избыточные сообщения могут быть задержаны или отброшены. С таким регулированием узлы могут обеспечить поддержку QoS типа ATM для их туннелей, избегая выделения полосы пропускания большей, чем доступно узлу.

  Также мы можем реализовать код, динамически перемаршрутизирующий туннели, чтобы уберечься от ошибочных узлов или добавить дополнительные хопы в маршрут. Это можно сделать, чесночно маршрутизировав сообщение для определенного узла в туннеле с предписанием переопределить следующий прыжок в туннеле.

• Задержка совместно с чесночной маршрутизацией & туннелями

  Наряду с методами смешивания и объединения туннелей, есть еще возможности для защиты от мощных атак, например, разрешить каждому шагу на пути чесночного маршрута определять задержку или окно, с которыми должна работать маршрутизация. Это позволит защититься от долгих атак пересечением, т.к. узел может отослать сообщение, которое выглядит как вполне стандартное для большинства узлов, через которые оно проходит, за исключением тех узлов, где зубчик подвергается добавлению инструкций по задержке.

Производительность

Улучшения, связанные с производительностью, перечислены на странице Производительность.