Заявка на роль Мечтателя Montana

Модель: Gemini 3 Pro Компания: Google Дата: 09.01.2026

Полученная проблема

Проблема 1: AddrMan Poisoning (MEDIUM) КРИТИК НАШЁЛ: Атакующий может отправить addr сообщения с timestamp в будущем. AddrMan сохранит их. При перезапуске ноды выберет "свежие" адреса атакующего.

Моё переосмысление

Класс проблем

Это не просто "атака через timestamp". Это класс проблем доверия к невалидированным метаданным. Любое поле (время, сервисы, версия), которое узел не может криптографически проверить, является вектором атаки. Timestamp в Addr — это claim, а не proof.

Связь с Montana

Montana уже решает проблему доверия ко времени через:

L-1.2 Координаты наблюдаемы: Время определяется медианой peers + NTS.
L-0.2.2 Подписи только для текущего τ₂: Валидация времени через присутствие.
Presence Proofs: Криптографическое доказательство существования узла во времени.

Ключевой вопрос

"А что если адрес может быть добавлен в AddrMan только если он предоставил Proof of Presence?"

Вместо того чтобы фильтровать "плохие" timestamp, мы можем требовать доказательство "хорошего" timestamp.

Три решения

Решение 1: Костыль

Что: Добавить проверку if addr.timestamp > now + 10_min { return; } в addrman.rs. Решает: Конкретную атаку с будущим временем. Проблема: Не решает атаку с "прошлым" временем (replay старых адресов), не решает атаку с поддельными сервисами. Это "черный список" подходов.

Решение 2: Архитектурное

Что: Ввести систему репутации для отправителей Addr сообщений. Если пир шлет адреса из будущего — банить пира. Решает: Класс атак "Poisoning от плохих пиров". Проблема: Сложно. Требует хранения истории, скоринга, защиты от Sybil-атак на репутацию. Добавляет состояние.

Решение 3: Элегантное

Что: Интегрировать AddrMan с PresenceProof. Принимать Addr сообщение, только если оно подписано ключом, который имеет валидный PresenceProof в недавнем прошлом (например, в текущем τ₃). Использовать timestamp из PresenceProof (который проверен консенсусом) вместо timestamp из Addr сообщения.

Решает: Класс атак "Fake Metadata" + "Sybil Addr Flooding". Почему элегантно:

Использует существующее: PresenceProof уже есть, он уже проверяется.
Закрывает: Poisoning, Sybil flooding, Stale addresses.
Код становится проще: Не нужны эвристики "terrible", не нужны бакеты (или их роль снижается). Доверие криптографическое, а не вероятностное.

Почему Элегантное — лучшее

Костыль (if future) — это игра в кошки-мышки. Атакующий поставит now + 9 min. Архитектурное (репутация) — это сложная надстройка, которую тоже можно атаковать.

Элегантное решение (Addr via Presence) меняет парадигму:

Адрес — это не "данные", это "свойство участника".
Участник — это тот, кто доказал присутствие (PresenceProof).
Нет присутствия → нет права объявлять адрес.

Это превращает AddrMan из "свалки IP" в "реестр активных участников". Sybil-атака на AddrMan становится экономически невозможной (требует прохождения Cooldown и генерации Proofs).

Применение к другим проблемам

Этот паттерн "Proof over Claim" применим к:

Service Flags: Узел заявляет NODE_FULL? Пусть докажет (ответит на challenge по старому блоку).
Version: Узел заявляет v2? Пусть подпишет сообщение в формате v2.

Вместо фильтрации лжи, мы требуем доказательство правды.

Клятва

Я, Gemini 3 Pro, клянусь:

Искать элегантное, не костыльное
Использовать существующее, не изобретать
Упрощать, не усложнять
Переосмысливать, не латать

5.7 KiB Raw Permalink Blame History Unescape Escape