Разработчик Фонда Эфириума резко критикует IOTA

На начальных этапах разработки криптовалюты IOTA, команда проекта была, в основном, сфокусирована на применении платформы в области Интернета Вещей. Однако, после листинга IOTA на нескольких криптовалютных биржах в июне 2017 года, ее все чаще стали рассматривать в качестве еще одной инновационной криптовалюты общего назначения. Дебют на биржах оказался успешным: на момент написания статьи IOTA занимает 9-е место по капитализации криптовалют, опережая такие платформы, как Monero и Ethereum Classic.

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

26 сентября Ник Джонсон (Nick Johnson), разработчик Фонда Эфириума, в своем посте обозначил критические, по его мнению, недостатки IOTA. Конечно, читая его материал нужно учитывать, что Фонд Эфириума совершенно не заинтересован в успехе проекта IOTA, и к тому же, в экосистеме Эфириума разрабатывается µRaiden – конкурирующий протокол для IoT. Тем не менее, проблемы IOTA, описанные ниже, существуют и о них нужно знать.

Неубедительное обоснование использования троичного кода в IOTA

Базовым элементом архитектуры IOTA является использование симметричного троичного кода (место битовой структуры занимают наборы трех символов: -1; 0; 1). Создатели IOTA приводят целый ряд аргументов в пользу такого выбора, однако, все они сводятся к двум основным:

  • Теоретически, троичные процессоры эффективнее двоичных
  • Некоторые математические конструкты могут быть лучше представлены симметричными тритами. (симметричный: -1; 0; 1, несимметричный: 0;1 ; 2)

К сожалению, эти аргументы явно недостаточны. IOTA построена на существующем оборудовании, а оно использует исключительно двоичный код, так же, как и сети передачи данных. В результате, все внутренние троичные значения (триты) должны будут перекодироваться в двоичный код, требуя дополнительных мощностей для хранения данных и вычислений.

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

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

IOTA пренебрегает основными постулатами криптографии

Этот пункт во многом следует из предыдущего: выбор троичного кода потребовал «переизобрести» базовые операции, такие как криптографическое хэширование, что нарушает правило №1 криптографии – не создавать без нужды новые криптографические алгоритмы.

Предсказуемым результатом такого подхода стало обнаружение группой исследователей ряда серьезных уязвимостей в Curl — хэш-функции, применяемой в IOTA. В ответе авторов IOTA говорится, что все эти уязвимости (сопротивление коллизиям) не важны в той роли, которую выполняет функция Curl, ее задача – обеспечить только сопротивление прообразу.

Джонсон с эти не согласен: по его мнению, следующая криптографическая атака всегда более продвинутая, чем предыдущая. Первые же атаки коллизий на алгоритмы MD5 и SHA1 заставили криптографическое сообщество отказаться от этих функций, хотя для приложений, так же как и в IOTA, играло роль только сопротивление прообразу.

IOTA не следует сложившейся практике проектов open-source

Сооснователь IOTA Сергей Иванчегло заявляет, что уязвимости в хэш-функции Curl были оставлены умышленно, и стали своего рода «защитой от копирования»: при появлении клонов IOTA, команда могла бы опубликовать эти уязвимости.

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

Если IOTA так не любит создателей клонов, они могли бы лицензировать свой код и запретить копирование, или вовсе не публиковать исходный код, как они и поступили со своим «мастер-нодом» – централизованным Координатором. Конечно, они потеряли бы поддержку сообщества проектов с открытым кодом, но лучше уж так, чем публиковать «заминированный» код.

Гарантии целостности IOTA недостаточны

Вместо блокчейна, IOTA использует Tangle – направленный ациклический граф транзакций, без единого для всех заголовка.

Каждая транзакция подтверждается с помощью консенсуса PoW, однако этот алгоритм имеет постоянную сложность. Поскольку IOTA должна работать на маломощных узлах, сложность алгоритма невелика, так что для специализированного оборудования не составит труда подавить всю процессорную мощность графа Tangle. К тому же, в отличие от блокчейн-систем, таких как Биткойн или Эфириум, его сложность не адаптивна. Это означает, что безопасность Tangle напрямую зависит от числа обрабатываемых транзакций, а возможность адаптировать уровень безопасности к условиям реального мира отсутствует. Надежность блокчейна обеспечивается наличием основанных на решениях теории игр финансовых вознаграждениях майнерам, и гарантий того, что атакующий должен иметь больше хеш-мощностей, чем все добросовестные участники вместе взятые. В системе IOTA доказательства таких гарантий отсутствуют.

И напоследок: отсутствуют доказательства того, что:

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

По всем этим пунктам команда IOTA дает неформальные объяснения, почему это не представляет опасности, но уровень этих объяснений на порядки ниже обоснований для систем, основанных на блокчейне, и применяющих механизмы PoW и PoS.

Источник

Leave a Reply

Your email address will not be published. Required fields are marked *