Axiom: Децентрализованный и устойчивый к цензуре протокол связи
🚀 Детали развертывания в реальном времени
- Сеть: Arbitrum One (Mainnet L2)
- ID сети:
42161
- RPC-адрес:
https://arb1.arbitrum.io/rpc (или любой кастомный Alchemy/Infura endpoint)
- Адрес прокси-контракта Axiom:
0xc11CFf8111e8b1F055eba095Efb679a38Abe6b63
(Примечание: Axiom использует UUPS Upgradeable Proxy архитектуру. Все взаимодействия клиентов должны всегда направляться на этот адрес прокси, а не на нижележащий контракт реализации).
📖 Как читать данные (Индексатор / Клиенты)
Клиентам никогда не следует пытаться читать посты протокола напрямую из переменных состояния смарт-контракта (поскольку сохранение газа является приоритетом, содержимое не хранится в состоянии). Вместо этого клиенты должны индексировать события блокчейна.
✍️ Как публиковать данные (Отправка транзакций клиентом)
Чтобы опубликовать данные в протоколе, клиенты должны отправить транзакцию, вызывающую функцию publishAxiom на прокси-контракте.
Цель Axiom — предоставить полностью анонимную, децентрализованную и устойчивую к цензуре платформу социальных сетей.
Чтобы сделать это возможным, архитектура строго разделена: основа (протокол) и клиенты (программное обеспечение). Этот репозиторий определяет эту основу — смарт-контракт и стандартизированную структуру данных на сети Ethereum Layer 2.
Объем проекта
Протокол закладывает основу платформы:
- Стандартное соглашение об именовании: Чёткая структура, определяющая, как полезная нагрузка отправляется в смарт-контракт и как клиенты её читают.
- Неизменность: Блокчейн служит отказоустойчивой и защищённой от взлома базой данных.
- Фокус на микроблогинг: Протокол не предназначен для больших объёмов ончейн-данных, а следует традиционной концепции микроблогинга (короткие посты). Медиафайлы не хранятся напрямую в цепочке; вместо этого они встраиваются через внешние ссылки при необходимости.
- Защита от спама: Комиссии за транзакции и одноразовый низкий вступительный взнос для первого поста кошелька предотвращают атаки на раздувание состояния со стороны ботнетов.
- Маршрутизация безопасности: Протокол обеспечивает разделение сообщений в соответствии с требованиями OPSEC на основе конкретных требований безопасности.
Уровни безопасности протокола
Axiom спроектирован для обеспечения истинной свободы слова для пользователей в странах, где коммуникация ограничена. Протокол различает три уровня безопасности. Предполагается, что пользователи знают, какой уровень безопасности подходит для их конкретной ситуации.
- Уровень 1: Открытый
Коммуникация происходит открыто в виде обычного текста в блокчейне. Все клиенты могут читать и обрабатывать весь трафик. Встраивание ссылок (например, для изображений через сторонних провайдеров) разрешено на этом уровне. Ожидается, что здесь будет происходить стандартное общение в социальных сетях — включая смешные картинки с котиками. Это создаёт важный шум в сети. Уровень менее безопасен с точки зрения чистого отслеживания IP, но посты остаются абсолютно не подлежащими цензуре.
- Уровень 2: Закрытый
Этот уровень предназначен для строгой безопасности. Он поддерживает исключительно сообщения в виде обычного текста. Протокол запрещает здесь медиа-ссылки, чтобы технически исключить любые утечки IP при загрузке клиентами внешнего контента. Пользователи должны самостоятельно обеспечивать анонимное приобретение криптовалюты для оплаты газа.
- Уровень 3: Зашифрованный
Создан для максимальной приватности. Сами сообщения перед отправкой шифруются с помощью AES-256-GCM. В блокчейне сохраняются только метаданные, вектор инициализации (IV) и шифротекст. Только клиенты пользователей, обладающих правильным криптографическим ключом, могут расшифровать и прочитать эти сообщения.
Сетевая безопасность и отслеживание IP (Жесткое правило)
Для всех уровней использование луковой маршрутизации (например, Tor) строго обязательно. Взаимодействие с коммерческими RPC-провайдерами (такими как Infura или Alchemy) раскрывает IP-адрес отправителя в открытом виде. Чтобы закрыть потенциально опасные для жизни уязвимости OPSEC для диссидентов, клиенты обязаны направлять транзакции к RPC-узлам исключительно через сеть Tor.
Стандарты криптографии (Для Уровня 3)
Для сообщений на Уровне 3 все клиенты должны строго соблюдать следующие криптографические стандарты для обеспечения совместимости и предотвращения компрометации безопасности.
- Алгоритм шифрования: AES-256-GCM
Все полезные нагрузки Уровня 3 должны быть симметрично зашифрованы с использованием AES в режиме GCM с длиной ключа 256 бит. Вектор инициализации (IV/Nonce) должен быть случайным образом перегенерирован для каждого отдельного сообщения и записываться в блокчейн в виде метаданных в открытом виде. Это предотвращает распознавание шаблонов внешними наблюдателями.
- Вывод ключа: Argon2id
Пользователи вводят читаемые пароли в свои клиенты. Они никогда не должны использоваться напрямую в качестве ключей AES. Клиенты строго обязаны использовать алгоритм хеширования Argon2id. (Примечание: Разработчики должны определить фиксированные параметры для количества итераций и использования памяти внутри клиента, чтобы все генерировали одинаковый ключ).
- Обмен ключами: Внеполосный
Axiom не занимается обменом ключами в цепочке. Протокол не хранит открытые ключи. Обмен паролем (общим секретом) для конкретного канала является обязанностью пользователей и должен происходить вне сети (например, лично).
- Целостность данных
AES-GCM генерирует тег аутентификации. Клиенты должны проверять этот тег. Если проверка не удалась, клиент должен молча отбросить сообщение (отбросить).
Структура данных, доставка полезной нагрузки и индексация
Axiom использует гибридную доставку полезной нагрузки (ABI Split). Чтобы смарт-контракту не приходилось распаковывать дорогостоящие форматы данных, данные разделяются перед передачей:
- Логические переменные: Уровень (
uint8 _level) и вектор инициализации (bytes _iv) передаются как прямые параметры в смарт-контракт, так как они необходимы ему для выполнения правил безопасности.
- Непрозрачные данные: Фактическое содержимое сообщения внутренне конструируется клиентом как JSON и сжимается в CBOR (Concise Binary Object Representation). Контракт обрабатывает этот CBOR-пакет "вслепую" и перенаправляет его непосредственно в журнал событий.
Ключи полезной нагрузки (Структура CBOR)
Axiom использует для ключей отдельные буквы, чтобы сэкономить байты. Автор (msg.sender) и временная метка (block.timestamp) опущены, так как смарт-контракт извлекает эти значения защищённым от взлома способом.
t (Тип): Целое число. Тип действия.c (Содержимое): Строка/Байты. Текст, имя или шифротекст.h (Хэштеги/Теги): Массив. Опционально. Используется для категоризации (подканалы).m (Подсказка сообщения): Байты (длина 2). Только Уровень 3. 2-байтовый HMAC-хеш, используемый для нечёткой группировки.r (Ответ на): Байты. Опционально. Хеш транзакции ссылающегося поста.
Типы действий (поле t)
0 = Обновление профиля (Связывает адрес кошелька с читаемым именем в поле c)1 = Пост (Стандартное сообщение)2 = Ответ (r требует хеш исходного поста)3 = Лайк (r требует хеш поста)4 = Отмена лайка (Отменяет Тип 3)5 = Репост/Ретвит (r требует хеш поста)6 = Отмена репоста (Отменяет Тип 5)
Подканалы и тёмная маршрутизация (поле h)
- Уровень 1 и 2: Теги передаются в открытом виде.
- Уровень 3 (Зашифрованный): Передача тегов в открытом виде строго запрещена на уровне протокола, так как это раскрывает метаданные. Теги должны быть зашифрованы точно так же, как содержимое (
c). Для внешних наблюдателей теги поэтому полностью невидимы (Тёмная маршрутизация).
Уровень 3: Нечёткая группировка (поле m)
