Краткий обзор архитектуры Elixir и ответы от команды на некоторые вопросы. Занимательное решением о присвоении каждому токену уникального приватного ключа и анонимизации транзакций. Прочитав техническую бумагу осталось множество вопросов к команде, данный пост можно рассматривать исключительно как ознакомление с проектом, так как провести более детальный разбор не представляется возможным в связи с недостаточной информацией о технической части.
Введение
В отличии от традиционных протоколов с передачей токенов, где секретный ключ от кошелька является доказательством владения, Elixir предлагает архитектуру где каждый токен обладает собственным секретным ключом, который меняется при смене владельца, токены же при этом остаются статичными. К особенностям протокола относятся: ноды как команды, hash-based ownership, протокол mixnet, precomputation, анонимность и быстрота транзакций
Транзакции
Вводится новый и более быстрый концепт: Hash-Based Ownership - Хеш основанное владение. Поскольку хеш-функции считаются недопустимыми для инвертирования, пользователи могут использовать прообразы (адреса) как доказательство владения конкретными объектами. Хеши являются защищёнными перед квантовыми компьютерами, хотя и с небольшими оговорками. К свойствам протокола относятся:
- Конфиденциальность. Защищена ограниченностью информации
Внешний обозреватель не сможет связать воедино как участников транзакции, так и количество отправленного
- Безопасность. Увеличивается посредством защиты токена, при исключительно редких успешных случаях брутфорс-атак пострадает только один токен.
Блоки содержат только неупорядоченный лист с предыдущими и новыми адресами, а каждый токен обладает собственным ключом
- Скорость. Более быстрая обработка транзакций.
Благодаря hash-based ownership(владение на основе хеша), который исполняется намного быстрее чем при использовании цифровой подписи.
Ноды
Консенсус Elixir требует чтобы ноды работали в командах, которым последовательно назначают задачи по генерации блоков, в противоположности к требованию каждой ноде конкурировать индивидуально.
Чтобы участвовать в проведении транзакций и сообщений узлу необходимо быть выбранным в Elixir network посредством голосования, проходящем по принципу псевдорандома. Для участия необходим стейк, а также пройти процедуру верификации, и в случае успеха нода занимает место в одной из команд Elixir.
В случае неисправности или вредоносного действия определяется конкретная нода и честные узлы отказывают в дальнейшем контакте, с последующей передачей доказательства для оставшейся сети. Если нода уличена во вредоносных действиях она теряет стейк токенов, которые сжигаются, и выбрасывается из сети
Внутри команд даже единственный честный узел защищает общекомандный консенсус. Ноды достигают завершения посредством оценки коротких доказательств, которые распространяются внутри команд. Таким образом Эликсир не восприимчив к атаке 51%
Предварительные требования к нодам такие же как к современному компьютеру: 100 МБ - 1 ГБ соединение с интеренотом, 8-16 ядер, 8-64 RAM, 500 МБ - 2 ТБ дискового пространства
Архитектура
В протоколе Elixir используются ускоренные mix сети для обеспечения конфиденциальности. Mix network это протокол маршрутизации, который использует криптографию для диссоциации источника, содержимого и адресата сообщения.
Внутри как блока, так и ноды, информация хранится в виде binary radix tree совместно с Merkle tree. Такая структура подходит для быстрого поиска и выполнения rehashing внутри нод, а также для генерирования доказательств подтверждающих существование токена внутри блока.
Каждая команда на платформе Elixxir запускает один экземпляр mixnet (mixing network) основанный на cMix protocol. Mixnet анонимизирует группы сообщений и транзакций, одновременно защищая конфиденциальность и целостность каждого сообщения. Среди особенностей cMix протокола — низкий уровень latency.
Precomputation. Создание уникального шаблона, определяющего способ обработки информации или сообщений, позволяющего избежать дорогостоящих операций с публичными ключами. Соответственно меньше задержка и ниже стоимость для клиентов. Всё это весьма подходит для легковесных приложений, включая месенджеры на смартфонах.
Mixnet включает 3 операции: Приём, Преобразование и Доставка. Во время Приёма сообщение маркируется шифрованием, пока не будет диссоциировано от личности отправителя. В Преобразовании порядок сообщений перетасовывается, исключая способность наблюдателя сопоставлять порядок, в котором сообщения были получены с идентификаторами отправителей. При Доставке каждая нода независимо убирает маркирующие шифрования и посылает end-to-end зашифрованное сообщение получателю
- Обратный путь. Позволяет получателю отправлять немедленный ответ через mixnet; это позволяет реципиенту получать квитанции о транзакции, без необходимости платформы знать информацию об адресации, тем самым скрывая личность отправителя.
- Обязательства. Это протокол, который создает данные, которые часто производятся посредством хэширования, что позволяет провести аудит вычислений выполняемых узлом, даже на более позднем этапе. Ноды также дают комиты к группам зашифрованных сообщений, до осуществления дешифровки. Комиты действуют как эффективный механизм для верификации корректной работы узла.
- Открывание групп. Во время операции Доставки, до того как каждый узел в команде расшифрует пакет сообщений которые они получили, создаётся фиксация партии подтверждаемая каждым членом команды, что все фиксации идентичны, а затем дешифровка происходит независимо. Это гарантирует, что все честные узлы в команде имеют право защищать целостность команды и предоставляемые ими свойства, а именно конфиденциальность и анонимность.
При составлении обзора на архитектуру возникло множество вопросов к команде, некоторые приводятся ниже
Что означает публично верифицированная нода?
Узлы посылают вызовы друг другу для верификации публичных метрик, некоторые из которых производятся при формировании команд. Это делается для того, чтобы удостовериться что у команды есть вся необходимая спецификация для вступления в команду.
Есть ли какое-то минимальное и максимальное количество нод в системе?
Нет, таких параметров в системе нет, но после достижения ~5000 нод добавление новых становится менее выгодно.
Если количество членов в команде уменьшается (при некоторых условиях протокола), что происходит с такой командой, если ли критерии по которому определяется выбывающий узел?
Таких критерий пока нет, выбывшие ноды в свою очередь сформируют новые команды
Устойчивость к атаке 51%. Можете подробно описать механизм противодействия?
Если при добавлении комита честная нода обнаружит злоумышленников, тогда узел может отказаться от участия в открытии блока и "уничтожить" его. После такого действия другие ноды могут завершить блок.
Когда команда целиком состоит из злоумышленников, как именно происходит противодействия такой ситуации?
Идея заключается в том, что они делают обрабатывание, прежде чем узнают, что они будут обрабатывать. Протокол частично, до того как клиент отправит достаточно данных для дешифрования, соглашается обрабатывать содержимое отправляемого сообщения. Если команда решает сделать что-то не так, клиент сможет это доказать.
Дополнительная информация от команды:
В планах написание более детальной технической версии документа. Одна из версий будет основана на обратной связи от комьюнити, в котором мы представим команду злоумышленников, объясним как протокол работает с таким состоянием и докажем правдоподобность заявлений.
Обсудить проект можно в официальном чате, а также в группе сообщества