Zilliqa (ZIL) — сравнительный анализ с другими проектами

В этой статье мы сравним ZILLIQA с другими проектами. Цель состоит в том, чтобы позиционировать ZILLIQA относительно других блокчейн-проектов. Мы хотели бы подчеркнуть, что мы ценим идеи, выдвигаемые каждым из этих проектов, и не стараемся подорвать никакие научные доводы в них. Напротив, некоторые концепции, используемые в ZILLIQA, были вдохновлены этими проектами.

ZIL


Website


Roadmap


Twitter


Telegram


Reddit


Bitcointalk


Source code


White Paper

ZILLIQA vs Ethereum 1.0

  1. Скорость транзакции. Протокол блокчейна Ethereum имеет скорость транзакций около 10 tx/s. У ZILLIQA скорость транзакций в настоящее время в 250 раз выше.
  2. Консенсус. Ethereum использует PoW для достижения консенсуса, ZILLIQA использует pBFT для достижения консенсуса. PoW в ZILLIQA используется только для идентификации личности, для предотвращения атаки Sybil. После идентификации личности сеть может достигнуть консенсуса по нескольким блокам подряд. Это делает PoW более эффективным, поскольку новый PoW не требуется на каждый блок, как в Ethereum.
  3. Смарт-контракты: ZILLIQA также будет отличаться от Ethereum с точки зрения смарт-контрактов. Основное различие связано с тем, что базовый язык смарт-контрактов в ZILLIQA не будет полным по Тьюрингу.
  4. Законченность. Консенсусный протокол ZILLIQA дает окончательный результат. Это означает, что подтверждение не требуется. Это отличается от консенсуса на основе PoW в Ethereum, где могут возникать временные вилки и поэтому требуется определенное количество подтверждений, чтобы исключить «двойную трату».
  5. Масштабируемость. Ethereum исследует, как сделать PoS безопасным и эффективным в своих будущих версиях. ZILLIQA использует другой подход с осколками (shards) для достижения масштабируемости. Мы стараемся быть совместимыми с Ethereum, везде где это возможно, в майнинге, языке смартконтрактов и т. д.
  6. Миссия. Миссия ZILLIQA заключается в поддержке высокопроизводительных приложений (dApps), которые используют свойства блокчейна: открытость, отчетность, прозрачность и т. д. ZILLIQA будет сосредоточена на поддержке тех dApps, которые требуют высокой пропускной способности или большого объема. Некоторые из существующих dApps на Ethereum могут извлечь выгоду из использования ZILLIQA, но мы не думаем, что таких будет большинство.

ZILLIQA vs Ethereum 2.0

ZILLIQA делает то, что называется шардингом сети или транзакций. Представьте примерную сеть из 1000 узлов. ZILLIQA автоматически разделит сеть на 10 блоков со 100 узлами. Каждый осколок теперь может обрабатывать транзакции параллельно. Если каждый осколок способен обрабатывать 100 транзакций в секунду, то все вместе они смогут обрабатывать 1000 транзакций в секунду. Способность обрабатывать транзакции параллельно из-за сегментированной (осколочной) архитектуры гарантирует, что пропускная способность в ZILLIQA увеличивается (примерно) линейно с размером сети. Ethereum в настоящее время исследует то, что называется state sharding, то есть возможность разделения сети блокчейна, чтобы хранилище не стало проблемой в долгосрочной перспективе. У ZILLIQA на текущий момент state sharding также отсутствует. Запуск смарт-контрактов в распараллеленной сети без использования state sharding само по себе является большой проблемой. Однако, переход на state sharding в наших планах на будущее.

Ethereum 2.0 — исследовательский проект и некоторые детали еще не выяснены. Фаза 1 Ethereum 2.0 (в разработке) представляет собой слабосвязанный сайдчейн (боковая цепь), присоединенный к основной цепи Ethereum через контракт менеджера валидатора (VMC). VMC находится на главной цепочке Ethereum и поддерживает систему осколков. Другими словами, он отвечает за ключевые задачи, такие как добавление нового валидатора, назначение нового валидатора для осколка и т. д. Фаза 1 Ethereum 2.0 — это простое решение, которое не решает все проблемы, связанные с осколками. Мы ожидаем, что решение Фазы 1 будет иметь следующие проблемы:

  1. Единая точка отказа. Вероятно VMC может стать узким местом и единой точкой отказа, поскольку ключевые этапы протокола должны проходить через него. Любая ошибка в VMC может привести к сбою всей системы. ZILLIQA не имеет какого-либо центрального подразделения или контракта, на который полагается вся система.
  2. Законченность. Каждый осколок будет выполнять PoS с правилом самой длинной цепи в качестве механизма исключения форка. В результате Ethereum 2.0 (фаза 1) не обеспечивает законченности состояния системы. ZILLIQA, с другой стороны, обеспечит завершенность состояния благодаря протоколу pBFT.
  3. Пропускная способность. Заявлено, что фаза 1 увеличит пропускную способность Ethereum 2.0 примерно в 100 раз. Пропускная способность ZILLIQA со скромным размером сети 3600 узлов показала пропускную способность в 250 раз превышающую пропускную способность Ethereum 1.0.
  4. Связь между осколками. Как представляется, первая фаза проекта по шардингу не позволит обеспечить связь между осколками (или она будет минимальна). Это означает, что смарт-контракт, находящийся в одном осколке и требующий вызова другого смарт-контракта, расположенного в другом осколке, может не работать. На самом деле, кросс-осколочная связь является одной из самых больших проблем, когда нужно запустить полный по Тьюрингу язык на осколочной архитектуре. У проекта есть планы использовать модель типа UTXO (через расписки) для обработки кросс-осколочных коммуникаций, но это похоже не входит в сферу первой фазы Ethereum 2.0.

ZILLIQA vs Plasma/Raiden

Плазма — это сайдчейн решение (с боковой цепью), а Raiden — это оффчейн решение проблемы масштабируемости. Это означает, что не все данные привязаны к основной цепочке Ethereum. Благодаря этому достигается масштабируемость.

Тем не менее, сайдчейн или офчейн решения не могут обеспечить те же гарантии безопасности, устойчивости и децентрализации, что и полностью масштабируемое решение на основной цепи. Более того, эти решения не позволяют сделать масштабируемой основную цепь.

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

ZILLIQA vs IOTA

Консенсус в IOTA достигается с помощью Directed Acyclic Graph (DAG), известного как Tangle. Подтверждение в IOTA происходит, когда два новых узла создаются поверх предыдущего узла. Это означает, что IOTA может масштабироваться экспоненциально, но безопасность зависит от веса узлов. На данный момент IOTA компенсирует недостаток веса «координатором», что является спорным решением, поскольку оно приводит к централизации сети.

Кроме того, поскольку график не является линейным, временная метка является не определяющей, а гипотетической и следовательно может ограничивать интеллектуальные возможности контракта IOTA, так как невозможно установить временную шкалу должным образом. Также трудно гарантировать, что Directed Acyclic Graph (DAG) будет ответвляться в правильном направлении и может быть достигнута конвергенция. С другой стороны, ZILLIQA дает завершенность транзакциям.

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

ZILLIQA vs EOS

Ключевой особенностью EOS является его масштабируемость, поэтому мы сравниваем ZILLIQA и EOS именно по данному аспекту.

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

Каждый из 21 узла предлагает один блок с временем блока 3 сек. Как вы представляете этот механизм безусловно будет иметь очень высокую пропускную способность. Однако, это также приводит к некоторым рискам. Количество узлов 21 недостаточно велико и следовательно все (или по крайней мере большинство из них) могут быть легко атакованы. Очевидным решением здесь было бы увеличение числа узлов с 21 до, скажем, 1000 или даже большего количества. Однако, вследствие этого увеличится задержка и снизится пропускная способность сети. Это связано с тем, что каждый узел должен передать информацию о блоке в большую сеть, а трансляция всегда является узким местом в любой распределенной системе.

Добавим еще один момент, доверие только 21 узла также приводит к некоторым рискам централизации. Кроме того, dPoS не гарантирует завершенность. Это означает, что вредоносный узел может создать

конкурирующий блок. В результате требуются подтверждения транзакций (как в Биткойне), чтобы иметь защиту от «двойной траты».

ZILLIQA использует другой протокол консенсуса под названием pBFT.

Преимущество pBFT заключается в том, что он дает завершенность.

Следовательно, подтверждения транзакций не требуются. Консенсус в ZILLIQA выполняется параллельно в осколках из не менее чем 600 узлов. Размер осколков более чем достаточен, чтобы обеспечить низкий риск централизации.

ZILLIQA vs Bitshares

Bitshares очень похож на EOS, следовательно сравнение будет таким-же как в пункте 5.

ZILLIQA vs NEO

NEO использует делегированный BFT (dBFT) для консенсуса. Это означает, что назначенное подмножество узлов, называемых бухгалтерскими узлами, отвечает за выполнение протокола консенсуса от имени сети NEO. Бухгалтерские узлы должны внести денежную сумму в качестве залога и эта сумма должна быть достаточно большой. Проблема с идеей обеспечения заключается в следующем: если количество бухгалтерских узлов велико, то их залог снижает ликвидность на рынке. Если число не велико, то есть риск того, что злоумышленники смогут взять сеть под свой контроль.

В ZILLIQA мы используем стандартный (практический) протокол BFT (pBFT) и по соображениям безопасности требуется, чтобы протокол выполнялся с достаточно большим количеством узлов. Узлы не обязаны устанавливать залоговое обеспечение и следовательно рыночная ликвидность не затрагивается. Кроме того, отсутствие обеспечения делает сеть более открытой. ZILLIQA также реализует осколки, которые позволяют увеличить пропускную способность транзакций по мере роста сети.

Другим отличием является подход к достижению высокой пропускной способности или масштабируемости. Классический BFT не масштабируется при превышении ста узлов. Тем не менее, протоколы BFT имеют преимущество в свойстве законченности. Существует два способа использования BFT, не затрагивая основные проблемы узких мест (бутылочных горлышек). Один из них — запустить BFT среди подмножества делегированных узлов в сети, как это делает NEO. Другой способ заключается в том, чтобы разделить сеть на несколько подсетей, где BFT может выполняться параллельно. ZILLIQA использует последний подход. Он имеет два преимущества: 1) безопасность и децентрализация поддерживаются на высоком уровне. ZILLIQA также использует и другие базовые элементы, такие как мультиподписи Schnorr, чтобы обойти некоторые проблемы. Это означает, что: 2) пропускная способность может линейно увеличиваться с количеством узлов. Второе преимущество явно отсутствует в первом подходе. Как правило, более крупная сеть означает лучшую децентрализацию, но в незащищенной сети это, к сожалению, приводит к узким местам (бутылочным горлышкам). Однако распараллеленная сеть, такая как

ZILLIQA, может максимально использовать большую сеть, избегая узких мест.

ZILLIQA vs RChain

У RChain и ZILLIQA есть три различия:

  1. Протокол консенсуса: ZILLIQA использует pBFT для консенсуса, в то время как RChain использует Casper POS для консенсуса. Преимущество pBFT заключается в том, что он предполагает Византийскую состязательную модель, в то время как PoS принимает криптоэкономическую состязательную модель, в соответствии с которой злоумышленник является рациональным, т. е. для любого, кто имеет долю в сети, нет стимула атаковать систему из-за собственных интересов. С этой точки зрения, pBFT является безопасным в гораздо более враждебной модели. Кроме того, pBFT имеет свойство завершенности, в отличие от PoS, где завершенность является лишь потенциальной и следовательно PoS требует подтверждений.
  2. Параллельность: RChain использует многопоточную виртуальную машину для выполнения контрактов и следовательно параллельность находится на уровне узла. Параллельность в ZILLIQA находится на сетевом уровне, а не на уровне VM. Другими словами RChain использует параллельность на уровне языка, в то время как ZILLIQA использует параллельность на уровне сети. Однако у RChain есть понятие имен, которые потенциально могут использоваться для распараллеливания на уровне сети.
  3. Язык смарт-контрактов: Язык смарт-контрактов в ZILLIQA основан на сообщающихся автоматах. Rholang (язык смарт-контрактов в RChain) основан на асинхронном полиадическом π-исчислении, которое лучше всего подходит для работы в настройке conncurrent. Rholang является полным по Тьюрингу и следовательно допускает неограниченную рекурсию, в то время как язык смартконтрактов в ZILLIQA не полный по Тьюрингу, поэтому он допускает только ограниченную рекурсию. Другое отличие заключается в том, что язык смартконтрактов в ZILLIQA требует, чтобы все внешние вызовы к другим контрактам были сделаны в конце перехода. В результате не возникает сложного чередования внешних вызовов и локальных инструкций. Таким образом, анализ и доказательство свойств безопасности с помощью формальных методов выполняются гораздо проще в ZILLIQA, чем в Rholang.

ZILLIQA vs Radix

Примечание: Это сравнение основано на техническом документе (whitepaper) Tempo, в котором отсутствуют некоторые важные детали, включая модель угрозы, под которой система может быть названа безопасной. Это очень затрудняет сравнение с ZILLIQA на более глубоком уровне.

Шардинг: Игнорируя отсутствие четко определенной модели угроз, Radix делает то, что называется stateharding. Глобальное состояние системы разделено на осколки. Обратите внимание, что термин осколок не используется так же, как в ZILLIQA. Осколок в ZILLIQA означает подмножество узлов. В Radix осколок означает часть глобального состояния. В ZILLIQA мы не выполняем statesharding, вместо этого мы сосредоточены на шардинге транзакций, то есть увеличении пропускной способности путем параллельной обработки.

В Radix каждый узел в сети может свободно выбирать осколок который он хочет сохранить. Каждый осколок содержит так называемый атом, который составляет и изменяет глобальное состояние системы. Всякий раз, когда пользователь создает транзакцию (также называемую транзакцией Atom), она сначала отправляется на узел, к которому подключен клиент. Затем узел выбирает случайный узел, связанный с транзакцией. Мы вызываем узел, который должен быть связан с транзакцией, если он содержит осколок, который содержит состояние либо отправителя, либо адресата. Затем второй узел выбирает другой и так далее. Каждый узел на этом пути проверяет, является ли транзакция действительной и является ли она попыткой «двойной траты». Это делается путем поддержания локального счетчика. Длина пути определяется клиентом. Поскольку узлы могут иметь разные представления, существует механизм разрешения конфликтов.

Есть несколько моментов, которые не достаточно ясны из отчета. Например, в техническом документе не обсуждается модель угрозы, в соответствии с которой система является безопасной. На сайте также сказано, что Radix не основан ни на PoW, ни на PoS. Это означает, что любой узел может свободно присоединиться к сети и следовательно увеличить долю вредоносных узлов в сети. Не ясно, как система будет обрабатывать приток вредоносных узлов.

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

Более того, в документе говорится, что клиент, отправляющий транзакцию, выбирает узел к которому он подключен. Что произойдет если этот узел вредоносен? Или следующий узел, случайно выбранный этим узлом, является вредоносным? Тогда требуемая длина пути никогда не будет достигнута и транзакция никогда не пройдет. Короче говоря, трудно оценить решение, предложенное в Radix без четко определенной модели угрозы.

ZILLIQA vs Cardano

Есть три аспекта по которым можно сравнить Cardano и ZILLIQA:

Подход к масштабируемости: Нынешний подход, который Cardano предпринимает для масштабируемости это PoS. Подход ZILLIQA к масштабируемости это pBFT как базовый консенсусный протокол, а PoW — как механизм исключения атаки Sybil. Только PoS не дает линейной масштабируемости, как это делает шардинг. Cardano в своей философии дизайна утверждает, шардинг легко реализуем с помощью PoS. Мы не согласны с этим утверждением, так как известно, что шардинг содержит в себе множество проблем, включая следующие (но не ограничиваясь ими): Как объединить транзакции, обработанные разными осколками, как безопасно и эффективно передавать транзакции, обработанные одним осколком в другие осколки без создания бутылочного горлышка и т. д.

При использовании смарт-контрактов шардинг создает дополнительные проблемы. Чтобы понять это рассмотрим смарт-контракт, который запускает ICO, т. е. он продает конечное количество токенов типа ERC-20 в обмен на некоторые собственные токены Cardano. Каждый участник отправляет транзакцию с указанием необходимого количества токенов Cardano и в ответ получает некоторое количество токенов типа ERC-20 в зависимости от цены токена.

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

Протокол консенсуса: Консенсусным протоколом в Cardano является PoS, а ZILLIQA использует pBFT. Два согласованных протокола работают под разными моделями угроз. PoS предполагает криптоэкономическую модель, где противник не желает потерять залог, чтобы воплотить свои злонамеренные интересы. С другой стороны, pBFT предполагает более суровую модель угрозы, где майнеры являются византийскими и могут злонамеренно отклоняться от выполнения протокола. Другим преимуществом, которое pBFT имеет перед PoS, является завершенность — это означает, что транзакции в ZILLIQA не нуждаются в подтверждениях.

Принцип разработки: самый последний выпуск Cardano Byron (сентябрь 2017) — это реализация с централизованными узлами. Cardano стремится в конечном итоге перейти к децентрализованной архитектуре. Философия развития ZILLIQA отличается. Мы считаем, что такие переходы подвержены проблемам и могут потребовать огромных изменений в кодовой базе, которые могут занять значительное время. В ZILLIQA мы построили децентрализованную инфраструктуру с нуля и следовательно потенциально можем обеспечить ускоренный путь к масштабируемому решению.

ZILLIQA vs Stratis

ZILLIQA и Stratis можно сравнить в их подходе к проблеме масштабируемости. ZILLIQA решает ее, реализуя идею шардинга, в то время как Stratis решает проблему, путем реализации нескольких частных боковых сетей (сайдченов), которые присоединены к основной цепи Stratis. Подход ZILLIQA имеет следующие преимущества по сравнению с решением проблемы масштабирования на сайдчейне:

  1. Масштабирование основной цепи: ZILLIQA масштабирует пропускную способность основной цепи, в то время как сайдчейн решение по-прежнему является косвенным решением, и его производительность привязана к масштабируемости основной цепи.
  2. Безопасность: Безопасность сайдчейн решения зависит от безопасности каждого сайдчейна. Если на сайдчейне не хватает шахтеров, система не очень безопасна и децентрализована.

Протокол консенсуса: ZILLIQA использует стандартный практический византийский протокол pBFT для достижения консенсуса в каждом осколке. В то время как Stratis использует PoS для достижения консенсуса по основной цепочке. PoS предполагает криптоэкономическую модель угрозы, когда блок-валидатор не желает терять свой залог или долю с целью навредить системе.

pBFT предполагает более враждебного противника, способного сделать все что угодно, чтобы подорвать систему.

Законченность: Протокол pBFT в ZILLIQA придает законченность транзакциям, чего нет в PoS. Другими словами, в ZILLIQA подтверждения транзакций не требуется.

ZILLIQA vs 0Chain

0Chain — это протокол, который использует несколько параметризованных цепей для обработки различных аспектов блокчейна, таких как данные, смартконтракт, майнеры и т. д. Такая модульная архитектура упрощает разветвление и изменение параметров протокола в ускоренном виде. Основной точкой сравнения между ZILLIQA и 0Chain является их подход к масштабируемости. В то время как ZILLIQA использует идею шардинга с pBFT в качестве базового консенсусного протокола, 0Chain использует dPoS для достижения консенсуса. Существует несколько преимуществ подхода ZILLIQA:

Завершенность транзакций: Протокол pBFT в ZILLIQA дает завершенность транзакциям, которую не дает dPoS в 0Chain. Это означает, что ZILLIQA не требует подтверждений транзакций.

Модель угрозы: dPoS предполагает криптоэкономическую модель противника, в которой майнеры не желают терять свой залог, чтобы навредить системе. В то время как pBFT предполагает гораздо более жесткую византийскую модель. В византийской модели у противника нет экономических препятствий для подрыва системы.

Децентрализация: dPoS в 0Chain (в соответствии с начальными параметрами, указанными в техническом документе) работает с набором только из 3 блоков производителей и 6 блоков верификаторов. Мы считаем, что такое небольшое количество блоков производителей и шахтеров может серьезно повлиять на аспекты децентрализации протокола. С другой стороны, pBFT в ZILLIQA работает с осколками из не менее чем 600 узлов и следовательно мы не жертвуем децентрализацией.

Однако в документе 0Chain упоминается, что количество блоков производителей может изменяться, их может быть 21, 100, 2048 и т. д. Но выбор трех в качестве исходного параметра, безусловно небезопасен, так как становится легкой атака блоков производителей и вывод их из строя. Кроме того, очевидно, что увеличение числа блоков производителей с 3 до 2048, несомненно увеличит задержку и снизит пропускную способность сети.

Линейная масштабируемость: Шардинг в ZILLIQA делает возможной линейную масштабируемость, которая отсутствует у dPoS в 0Chain.

ZILLIQA vs ORBS

ORBS, по-видимому, использует протокол SPECTRE для достижения высокой пропускной способности и низкой задержки. SPECTRE это протокол, который использует основанную на DAG книгу для записи блоков, добытых поверх предыдущих блоков. Затем протокол использует механизм виртуального голосования для получения частичного порядка на блоках. Однако, как обсуждается в документе SPECTRE, протокол не дает полного порядка на блоках и следовательно не подходит для выполнения смарт-контрактов. Ниже приводится выдержка из статьи:

«Ключом к достижениям SPECTRE является его готовность отложить принятие решения относительно транзакций с явной «двойной тратой». Таким образом, он решает более легкую проблему, чем традиционные консенсусные протоколы. Этот факт также делает его менее подходящим для таких систем, как Ethereum, где требуется полный порядок транзакций.”

ZILLIQA, с другой стороны, опирается на стандартный византийский отказоустойчивый консенсусный протокол pBFT, который гарантирует завершенность транзакций. Кроме того, поскольку ZILLIQA использует линейную цепочку блоков, она также гарантирует абсолютный порядок добытым блокам, что позволяет запускать смарт-контракты.

ZILLIQA vs OmniLedger

ZILLIQA была вдохновлена Omniledger и его предшественниками ByzCoin и CoSi. Omniledger — это научная статья и теория, которая на практике потребовала от ZILLIQA изменения некоторых базовых блоков, например изменение протокола CoSi, используемого в Omniledger, который уязвим для некоторых типов атак.

CoSi реализует мульти-подписи Schnorr. Он предполагает честного лидера, который объединяет взносы от разных подписчиков и в конце протокола, генерирует мульти-подпись. ZILLIQA не считает лидера честным. Фактически, протокол CoSi уязвим для следующих двух атак, которые мы предотвращаем в ZILLIQA:

Первая атака предполагает, что лидер злонамерен. В начале протокола CoSi лидер может объявить, что он хочет сгенерировать мульти-подпись в конкретном сообщении “эта транзакция-двойная трата”. Однако протокол не обязывает лидера придерживаться этого сообщения в следующих шагах. Он может фактически изменить его на любое сообщение по своему выбору, например: ”эта транзакция не двойная трата». Нет никакого способа для подписывающих, чтобы обнаружить подмену. В результате, подписывающие могут слепо подписывать ложные сообщения.

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

Мы предотвращаем эти атаки, добавляя дополнительные шаги и раунды сообщений в протокол CoSi как на стороне лидера, так и на стороне подписавшего. Шаги гарантируют, что вредоносное поведение будет обнаружено намного раньше.

Есть и другие отличия. Например, Omniledger также предлагает сделать state sharding, который ZILLIQA не делает. Мы считаем, что state sharding имеет очень много пока не решенных проблем. ZILLIQA также будет иметь не полный по Тьюрингу язык смарт-контрактов, которого нет у OmniLedger.

ZILLIQA vs Waves NG

Waves NG реализует протокол, основанный на Bitcoin NG с использованием PoS для исключения атаки Sybil. ZILLIQA использует PoW для этого. Поскольку ZILLIQA была вдохновлена ByzCoin, который в свою очередь был вдохновлен Bitcoin NG, есть некоторые сходства в дизайне между Waves NG и ZILLIQA. Однако, основное различие между двумя протоколами заключается в том, что у Waves NG отсутствует шардинг.

ZILLIQA vs Cypherium

Cypherium реализует протокол, основанный на ByzCoin с использованием

PoW для исключения атаки Sybil. Поскольку ZILLIQA также была вдохновлена ByzCoin, оба протокола имеют общий дизайн. Разница между ZILLIQA и Cypherium заключается в том, что у последнего отсутствует шардинг.

Следовательно, если размер консенсусной группы в Cypherium станет большим, базовый консенсус-протокол будет иметь бутылочное горлышко. Это означает, что Cypherium не может масштабироваться линейно, как ZILLIQA.

ZILLIQA vs IOS

Проект IOS предлагает масштабируемую блокчейн-платформу, которая использует идею шардинга для масштабирования. IOS объединяет основы из нескольких научных статей, предполагающих коллективные подписи, таких как ByzCoin, RandHound-RandHerd и OmniLedger. Точнее IOS принимает идею агрегации подписи из коллективной подписи, идею запуска pBFT в качестве консенсусного протокола с агрегацией подписи от ByzCoin, концепции транзакций и state sharding от OmniLedger и использует генератор случайных чисел, устойчивый к смещению от RandHound , фактически, OmniLedger сам объединяет другие работы и следовательно IOS очень близок к OmniLedger.

Дизайнеры IOS также упомянули об этом в техническом документе

ZILLIQA также использует некоторые идеи из коллективных подписей и ByzCoin и следовательно имеет некоторые сходства с IOS. Однако два проекта отличаются следующими аспектами:

Сопротивление Sybil: В техническом документе IOS явно не обсуждается, как он предотвращает атаки Sybil. Похоже, что атаки Sybil предотвращаются посредством механизма на основе ставок. ZILLIQA использует PoW для сопротивления атакам Sybil.

Протокол консенсуса: IOS использует комбинацию pBFT и протокол доказательства правдоподобия (PoB). PoB очень похож на протокол dPoS, где валидатор предлагает блок. Консенсус в IOS происходит в два этапа. На первом этапе протокол PoB запускается среди небольшого набора узлов, называемых достоверными валидаторами, в результате чего они предлагают небольшой набор транзакций. Позже на втором этапе предлагаемые транзакции проверяются большим набором узлов, называемых обычными валидаторами. Обычные валидаторы не проверяют каждую транзакцию, предложенную достоверными валидаторами. Вместо этого они сначала решают, какие транзакции проверять, а затем они запускают протокол консенсуса pBFT для согласования транзакций.

Однако технический документ не дает анализа безопасности предлагаемого протокола PoB, в результате сложно оценить его свойства безопасности. С другой стороны, ZILLIQA использует стандартный протокол pBFT для достижения консенсуса. Безопасность и жизнеспособность pBFT были хорошо описаны в научной литературе.

Размер группы консенсуса: Осколок в IOS будет иметь несколько групп достоверных валидаторов. Каждая группа предлагает различный набор транзакций. Однако в каждой группе только один достоверный валидатор. Это означает, что достаточно легко выделить всех достоверных валидаторов в осколке и атаковать их. Более того, поскольку достоверные валидаторы назначаются с использованием всем известных показателей, таких как обзоры, репутация и т. д., Становится еще проще определить достоверных валидаторов используя доступную публичную информацию.

Модель угрозы: ZILLIQA предполагает четко определенную византийскую состязательную модель, где менее 1/3 общей сети является византийской (злонамеренной). С другой стороны, модель угрозы в IOS не так хорошо определена. IOS использует два разных консенсусных протокола: pBFT и PoB. PBFT предполагает византийскую модель противника, в то время как PoB предполагает, что разумный противник не хочет терять крупные вклады, чтобы подорвать консенсусный протокол. Следовательно, неясно, как узел в сети IOS адаптивно переключается с одной модели на другую и может ли такая гибридная модель угрозы быть оправдана.

Модель UTXO: Поскольку IOS внимательно следит за протоколом OmniLedger, в ней используется модель транзакций на основе UTXO для обработки сообщений между осколками. Грубо говоря, пользователь создает транзакцию с некоторыми входами и выходами. Осколки, обрабатывающие входы, затем блокируют эти входы и выдают квитанцию, подтверждающую, что входы заблокированы и могут использоваться в качестве выходов. После получения квитанции выходы могут быть подтверждены осколками, передающими выходы. Поскольку IOS заявляет, что является блокчейнплатформой со смарт-контрактами, не совсем ясно, как модель UTXO может эффективно их обрабатывать, поскольку смарт-контракты подразумевают управление глобальными переменными состояния, в отличие от модели UTXO, которая обрабатывает лишь определенные входы.

ZILLIQA использует основанную на учетной записи модель и следовательно устраняет любые ограничения при выполнении смарт-контрактов.

Завершенность транзакций: Поскольку обычные валидаторы не проверяют каждую транзакцию, возможно, что злоумышленный достоверный валидатор предлагает не действительную транзакцию (двойную трату), которая обнаруживается только по факту. В результате совершенная транзакция не является законченной и нужно ждать ее подтверждений. Поскольку ZILLIQA использует pBFT среди большой группы узлов (минимум 600) и проверяет каждую транзакцию, гарантируется завершенность транзакции и отпадает необходимость ее подтверждений.

Атаки на коллективные подписи: И ZILLIQA и IOS используют коллективную подпись (CoSi) для агрегации подписи. Однако протокол, описанный в документе CoSi, уязвим для двух конкретных атак.

CoSi реализует мульти-подпись Schnorr. Он предполагает честного лидера, который объединяет взносы от разных подписчиков и в конце протокола, генерирует мульти-подпись. ZILLIQA не считает лидера честным. Фактически, протокол CoSi уязвим для следующих двух атак, которые мы предотвращаем в ZILLIQA:

  • Первая атака предполагает, что лидер злонамерен. В начале протокола CoSi лидер может объявить, он хочет сгенерировать мульти-подпись в конкретном сообщении “эта транзакция-двойная трата”. Однако протокол не обязывает лидера придерживаться этого сообщения в следующих шагах. Он может фактически изменить его на любое сообщение по своему выбору, например: ”эта транзакция не двойная трата». Нет никакого способа для подписывающих, чтобы обнаружить подмену. В результате, подписывающие могут слепо подписывать ложные сообщения.
  • Вторая атака предполагает, что подписывающие являются злонамеренными. Здесь цель — установить DoS атаку. Лидер в CoSi не проводит проверку на достоверность взносов, отправленных каждым подписывающим. В результате становится возможным, чтобы подписавший отправил недействительный взнос, который не может быть обнаружен до конца протокола, когда проверка подписи завершена. Эта атака срабатывает, даже когда один подписавший злонамерен.

Мы предотвращаем эти атаки, добавляя дополнительные шаги и раунды сообщений в протокол CoSi как на стороне лидера, так и на стороне подписавшего. Шаги гарантируют, что вредоносное поведение будет обнаружено намного раньше.

ZILLIQA vs Cosmos Tendermint

Cosmos Tendermint — это консенсусный протокол, представляющий собой сочетание PoS и настраиваемого протокола BFT, а ZILLIQA — это сочетание PoW и pBFT. PoW в ZILLIQA и PoS в Cosmos Tendermint используются в основном для исключения атаки Sybil. Однако классические протоколы BFT, в том числе используемые в Tendermint, ограничены с точки зрения масштабируемости. В общем, эти протоколы не масштабируются с количеством узлов выше 100.

Следовательно, если сеть станет больше, например несколько сотен узлов, применение классического консенсусного протокола BFT приведет к созданию узкого места (бутылочного горлышка).

Tendermint обходит эту проблему следующим образом: он выбирает небольшой набор валидаторов из всей сети. Пользовательский протокол BFT затем запускается только среди набора валидаторов. Если набор валидаторов составляет около 100 узлов, то узкие места не отображаются. В настоящее время Tendermint использует набор валидаторов из 100 узлов, но планирует расширить его до 300 узлов.

Поскольку консенсус выполняется только среди подмножества узлов из сети, высокая пропускная способность не вызывает удивления. Однако использование набора валидаторов в количестве 100 узлов приводит к рискам централизации. Узлы валидатора выбираются по количеству залога, которое они вносят в систему.

ZILLIQA использует другой подход. Вместо того, чтобы делегировать консенсус подмножеству узлов, она делит сеть на более мелкие осколки, достаточные для обеспечения безопасности и децентрализации. Затем каждый осколок может обрабатывать транзакции параллельно. ZILLIQA также использует основы, такие как мульти-подпись Schnorr, чтобы гарантировать, что pBFT внутри осколка не станет узким местом, несмотря на то, что размер осколка составляет не менее 600 узлов. Другим преимуществом, которое дает шардинг (разделение на осколки), является линейная масштабируемость. Пропускная способность в ZILLIQA линейно увеличивается с количеством осколков (или узлов).

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

ZILLIQA vs Hashgraph

Hashgraph — это консенсусный протокол, который в настоящее время реализуется в разрешенной настройке. Он не практикует открытое членство, это означает, его недоступность для любого произвольного узла. Чтобы стать доступным для всех (публичным), в проекте обсуждаются такие механизмы, как использование PoS для выбора консорциума, а затем использование консенсусного алгоритма Hashgraph в консорциуме. ZILLIQA, с другой стороны, представляет собой публичную блокчейн-платформу, которая использует pBFT для достижения консенсуса и PoW для исключения атаки Sybil.

Также неясно, насколько хорошо Hashgraph будет масштабироваться, так как количество сообщений между узлами линейно пропорционально количеству узлов. Для небольшой группы узлов, например в сто узлов в разрешенной настройке, масштабирование все же достижимо. Однако в настройке без ограничения, с тысячами узлов, протокол будет сильно зависеть от перегрузки сети сообщениями. Заинтересованным читателям предлагается прочитать следующую расширенную критику, сделанную одним из членов команды ZILLIQA: http://bit.ly/2jNOM5c

ZILLIQA vs RedBelly

У Red Belly есть целевой вариант использования, где они фокусируются только на модели блокчейн-консорциума, тогда как ZILLIQA является публичной блокчейн-платформой. В модели блокчейн-консорциума участники консенсуса ограничиваются членами консорциума и все участники консорциума известны остальным участникам. Эти идентичности обеспечивают естественную защиту консенсусному протоколу против атак Sybil. Кроме того, экспериментальные результаты Red Belly похоже основаны на небольшом размере сети, ориентировочно до 260 узлов.

ZILLIQA vs Universa

Universa — это закрытый блокчейн, а ZILLIQA — публичная блокчейнплатформа, следовательно, их сравнение идентично пункту 20.

ZILLIQA vs Raiblocks

Ниже приводится отрывок из их технического документа (whitepaper):

RaiBlocks может использовать фиксированное количество узлов, которые он контролирует — сумма генеза, чтобы определить нормальное участие, например кворум и ограничить участие непосредственно пользователям, которые заинтересованы в поддержании системы.

Это означает, что Raiblocks в какой-то мере является закрытым блокчейном с частично доверенными узлами.

ZILLIQA vs OMG

OMG представляет собой децентрализованную платформу для обмена, что требует базового протокола блокчейн для работы. OMG использует Ethereum. С другой стороны, ZILLIQA — это блокчейн-платформа. Проще говоря, OMG -это приложение, в то время как ZILLIQA-это система, на которой можно запускать OMG. OMG не решает проблему масштабируемости самостоятельно. Вам все равно нужно будет иметь базовый блокчейн с высокой пропускной способностью.

ZILLIQA vs Golem

Инфраструктура Golem предназначена для работы на Ethereum в виде смарт-контрактов. Это означает, что пропускная способность приложения Golem будет ограничена пропускной способностью Ethereum. Другими словами, если Приложение Golem становится действительно популярным и приводит к большим объемам транзакций, базовая сеть не сможет обработать этот объем.

С другой стороны, вычислительная платформа ZILLIQA опирается на свою собственную базовую архитектуру и следовательно может использовать ее высокую пропускную способность. Другое различие касается языка смартконтрактов. Golem основан на Ethereum, который имеет полный по Тьюрингу язык. В случае с ZILLIQA команда считает, что полный по Тьюрингу язык не является необходимым для многих интересных приложений. Другим преимуществом не полного по Тьюрингу языка является то, что он поддается формальным методам проверки из-за его простоты. Если конкретней, становится возможным доказать интересные свойства безопасности и жизнеспособности программ.

ZILLIQA vs SONM

SONM придерживается пути аналогичного Golem и полагается на Ethereum для достижения консенсуса. Следовательно, сравнение аналогично пункту 24.

ZILLIQA vs Tezos

Tezos, по сути, дает возможность обработки обновлений в блокчейнепротоколе, например как между Bitcoin и Bitcoin Cash. Он будет работать следующим образом: Tezos будет сначала создан для запуска в Bitcoin, а затем заинтересованным сторонам будет предложено изменить протокол на Bitcoin Cash. Затем они проголосуют за изменения. Если изменения будут приняты «сверхбольшинством» Bitcoin будет заменен на Bitcoin Cash.

Tezos можно рассматривать как средство управления. Код Tezos будет записан в OCaml и следовательно устранит известные проблемы на таких языках, как C ++. Tezos будет использовать PoS для достижения консенсуса относительно обновлений основного блокчейна (Bitcoin в примере выше).

Тем не менее Tezos сам по себе не изобретает новое изменение в базовом блокчейне, т. е. идея замены Bitcoin на Bitcoin Cash (или скажем ZILLIQA) должна исходить от сообщества исследователей/разработчиков. Таким образом, ZILLIQA и Tezos являются полностью ортогональными проектами. На самом деле, сообщество должно сначала придумать и реализовать ZILLIQA, а затем предложить его в качестве обновления для Bitcoin.

Единственным общим моментом, который можно сравнить между ZILLIQA и Tezos, является базовый протокол консенсуса. Здесь Tezos использует PoS, в то время как ZILLIQA использует pBFT. Протокол pBFT придает завершенность транзакциям, в PoS это не достижимо, следовательно, требуется подтверждение транзакций.

Ссылка на основную публикацию