Модель безопасности

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

Границы доверия

Существуют четыре границы, через которые недоверенные данные попадают в систему:

Пользователь → RPC: кошельки отправляют подписанные транзакции через eth_sendRawTransaction или /wallet/broadcasttransaction. На входе — недоверенные hex-данные. Для Ethereum raw-транзакций размер ограничивается еще до декодирования, а protobuf-данные Tron декодируются и проходят структурную валидацию перед добавлением в очередь.
RPC → executor: провалидированные транзакции находятся в пуле pending_transactions, пока производитель блоков не заберет их. Executor повторно проверяет личность (identity) отправителя по подписи.
Producer → верификатор: верификатор получает блоки через Erlang distribution. Он не доверяет никаким данным: повторно исполняет каждую транзакцию и пересчитывает каждый хеш.
Пользователь → precompile: данные вызова (calldata) к precompile-контрактам (HTLC, bridge refill/mint) парсятся и валидируются внутри каждого контракта.

Валидация на уровне RPC

Каждая транзакция проходит несколько проверок до попадания в пул ожидания:

Проверка	Что предотвращает
Hex decode	Некорректный ввод, наличие не-hex символов
Лимит Ethereum raw (4 КБ)	DoS-атаки через огромные payload в `eth_sendRawTransaction`. Проверяется до декодирования.
RLP / protobuf decode	Структурно невалидные транзакции
Chain ID	Cross-chain replay (транзакция подписана для Ethereum mainnet, но отправлена в 2D)
Восстановление подписи	Невалидные подписи, пластичные (malleable) подписи (EIP-2 s-value)
Валидация nonce	Устаревшие транзакции (nonce < текущего nonce аккаунта) отклоняются. Будущие nonce (future nonce) ограничены значением +100.

Некорректные адреса и топики (topics) в eth_getLogs возвращают ошибку, а не приводят к падению обработчика (handler).

Защита от replay-атак и управление nonce

Каждый аккаунт имеет последовательный nonce. Executor проверяет, что nonce транзакции точно совпадает с текущим nonce аккаунта. Транзакция не может быть выполнена дважды, так как nonce увеличивается после каждого выполнения.

Cross-chain replay блокируется как на уровне RPC, так и в executor: транзакции должны содержать корректный chain ID (77 для 2D). Транзакции формата pre-EIP-155 (без chain ID) отклоняются.

Дублирование хешей транзакций обрабатывается с помощью ON CONFLICT DO NOTHING при вставке в базу данных. Повторная отправка той же подписанной транзакции не дает никакого эффекта.

Отдельный аккаунт для POA

Создайте новый ключ и seed для production-сети POA. Не импортируйте приватный ключ, seed или keystore, ранее использовавшийся в другой сети или развёртывании. В частности, архивную транзакцию, подписанную этим ключом для chain ID 77, может отправить в production POA кто угодно, когда совпадёт nonce и на аккаунте будет достаточно средств: новая подпись и ваше участие не нужны. Проверка chain ID не различает развёртывания с одинаковым ID; проверка nonce не делает повторное использование ключа безопасным. Храните старые ключи отдельно и не пополняйте их адреса в POA. Explorer и RPC никогда не требуют seed-фразу.

Антиспам-троттлинг

Все транзакции бесплатны (комиссия = 0). Спам предотвращается за счет экспоненциальной задержки на уровне производителя блоков. Подробности описаны в разделе Бесплатные транзакции.

Троттлинг — это индивидуальная задержка (cooldown) для каждого отправителя, а не жесткая блокировка. Когда количество транзакций отправителя в скользящем окне превышает порог, из обработки временно исключаются только ожидающие (pending) транзакции этого конкретного отправителя на время действия задержки. Как только индивидуальная задержка истекает, его следующая транзакция снова становится доступной для включения в блок. Остальные отправители при этом не затрагиваются (защита от head-of-line blocking), а очередь ограниченного отправителя постепенно разгружается, а не блокируется до сдвига скользящего окна.

Tron-транзакции содержат установленный кошельком параметр expiration (обычно 30-60 секунд). Если ожидающая Tron-транзакция задерживается дольше своего срока действия, производитель удаляет ее из пула до исполнения блока, вместо того чтобы записывать в блок статус status=error. Сообщение “throttled дольше validity window” не несет полезной информации, кроме внутренней механики планирования сети.

Устаревшие транзакции в пуле (старше 10 минут) очищаются автоматически.

Верификация подписей

Личность отправителя проверяется криптографически и никогда не берется из пользовательского ввода:

Ethereum-транзакции: отправитель восстанавливается из ECDSA-подписи с помощью secp256k1 recovery. Восстановленный адрес используется для всех операций с балансом и nonce.
Tron-транзакции: подпись хранится вместе с сырыми protobuf-данными. При исполнении адрес отправителя заново вычисляется из sha256(raw_data) + signature и сравнивается с сохраненным. Любые расхождения приводят к отклонению транзакции.

Компоненты подписи (r, s), длина которых превышает 32 байта, отклоняются до выполнения padding. Подписи с высоким s-значением (high-s, уязвимость EIP-2 malleability) отклоняются как на уровне RPC, так и в executor.

Независимость верификатора

Верификатор не доверяет никаким данным от производителя блоков. Для каждого блока он независимо:

Вычисляет хеши транзакций из сырых байтов (не доверяя хешам, заявленным производителем).
Пересчитывает корень состояния (state root) по своей локальной базе данных.
Проверяет корень транзакций (transactions root), state root и хеш блока.
Для генезис-блока: фиксирует канонические timestamp и transactions root на основе известных констант.

Расхождение в любом из этих значений приводит к остановке верификатора. Подробности описаны в разделе Запуск верификатора.

Ограничения на уровне базы данных

История, работающая в режиме «только добавление» (append-only), защищена правилами PostgreSQL, которые блокируют операции UPDATE и DELETE для таблиц blocks и transactions. Схема состояния использует уровень изоляции SERIALIZABLE для всех блоков, что предотвращает состояние гонки (race conditions) между конкурентными транзакциями.

Текущие границы

Приватность: балансы и суммы переводов видны любому, кто запустит верификатор. Приватный слой находится в разработке.
Подпись блоков: producer подписывает хеши блоков через 2d-hsm; verifier независимо проверяет подпись и содержимое блока. См. Подпись в TEE.