Этимология Zilliqa: стабильность, Sharding в контрактах, безопасность. Часть 1.

Оригинал статьи взят с https://medium.com/on-the-origin-of-smart-contract-platforms/on-the-origin-of-zilliqa-1b1afc344aa7. Материал подготовлен пользователем Medium Ed Posnak.
Перевел: @hvoinui

Предисловие от автора Ed Posnak.

Эта статья является частью серии «On the Origin», целью которой ставится отслеживание появления и эволюцию проектов в эко-системе умных контрактов на основе блокчейна. Сегодня мы рассмотрим Zilliqa и ее амбиции относительно прямого вызова к доминирующей на сегодняшний день платформе Ethereum.

Общая информация

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

Название проекта, по-видимому, происходит от слова «silica», что может означать «Silicon for the high-throughput consensus computer». Проект основан группой исследователей из Национального университета Сингапура, включая Xinshu Dong (CEO), Yaoqi Jia (глава технологии), Amrit Kumar (руководитель исследования) и Prateek Saxena (главный научный советник). Prateek Saxena работала с Loi Luu (основоположником и генеральным директором Kyber Networkr и советником Zilliqa) и другими исследователями NUS по протоколу ELASTICO. Paper ELASTICO послужила основой для общего очертания технологии Zilliqa.

Zilliqa зарегистрирована в Сингапуре 1 июня 2017 года. 1 сентября команда запустила свою первую тестовую сеть (v 0.1), а 12 октября объявила, что тестовая сеть (v 0.5) достигла максимальной пропускной способности в 2488 транзакций в секунду. 1 декабря тестовая версия (v 1.0) открыта для публичного доступа, а в январе 2018 года код сети опубликован в открытом доступе. Осенью 2017 года Zilliqa привлекла около 20 миллионов долларов США, а затем за неделю (27 декабря 2017 года по 4 января 2018 года) привлекла еще 2 миллиона долларов США в ходе пресейла токена ZIL.

Zilliqa направила часть своего финансирования на создание #BuildonZIL, целью которого является поддержка команды и разработчиков. 14 августа 2018 года проект объявил о поддержке сторонних разработчиков грантами, что подразумевает финансирование широкого спектра субпроектов по разработке кошельков, исполняемых библиотек, инструментов для разработчиков и приложений. Zilliqa также является платформой, используемой в Project Proton, совместной инициативе по оценке жизнеспособности технологии blockchain для обеспечения прозрачности и отчетности . Недавно был анонсирован первый этап проекта Project Proton. Предположительно, ряд проектов #BuildonZIL будет запущен с выпуском главной версии Zilliqa, который должен произойти где-то в 4 квартале 2018 года — начале 2018 года.

Создаст ли Zilliqa в 2019 ажиотаж? Или этот год сыграет на руку Ethereum, что увеличит его доминирующее положение? В этой статье автор подробно рассмотрит возможности масштабируемости и основы безопасности таких проектов, как Ethereum и Zilliqa.

Масштабируемость

Последние тесты, проведенные в тестовой сети Zilliqa (v 1.0), продемонстрировали пропускную способность в 2000–3000 TPS. В сравнении с Ethereum молодой проект Zilliqa добивается увеличения количества обрабатываемых транзакций в секунду посредством внедрения архитектуры Sharding в базовые уровни работы как с обычными транзакциями, так и их умными версиями. Увеличение пропускной способности в данном случае будет основываться на разделении транзакций на несколько категорий и, соответственно, их обработкой будут заниматься различные друг от друга шарды, т.е. весь этот процесс будет иметь параллельную структуру. Не имея такой архитектуры в процесс обработки транзакций включаются все узлы цепочки, что создает эффект двойного расходования сил, что в свою очередь ограничивает пропускную способность сети. В решении Zilliqa технология Sharding позволяет группировать множество узлов сети на т.н. “шарды”, и присваивать каждой такой из групп определенные виды транзакций.

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

Как известно, Etherium также работает в данном направлении, в этой связи известна их общая начальная цель — внедрить архитектуру Sharding в базовые транзакции, т.е. в простые переводы средств между счетами. Только затем обе платформы будут решать более сложную задачу — внедрить Sharding в транзакции с изменяемыми переменными, т.е. в умные контракты.

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

Обработка транзакций в архитектуре Sharding

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

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

Чтобы достичь консенсуса по блокам Zilliqa использует оптимизированную версию протокола Practical Byzantine Fault Tolerance (PBFT), который обеспечивает около 415 TPS в каждом шарде. Первичная оптимизация заключается в замене кодов аутентификации сообщений на агрегированные подписи Schnorr. Это значительно сокращает количество сообщений, необходимых для достижения консенсуса (от квадратичного до линейного по числу узлов) и делает практичным применение шардов сотни майнеров.

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

Для безопасности и жизнеспособности протокола PBFT требуется более 2/3 проверенных узлов в каждом шарде и некоторые ограничения на время доставки сообщения (т. е. частичная синхронизация сети). Для достижение результата в открытой и общедоступной сети, в которой любой пользователь может участвовать в консенсусе, требуется защита от атак класса Sybil, в котором злоумышленник может нарушить консенсус, создав большое количество узлов.

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

Алгоритмом PoW, используемый Zilliqa, является алгоритмом PoW Etash, Ethereum. Ethash предназначен для ASIC. Bitmain в настоящее время запускает майнер Ethash ASIC, который можно использовать для добычи Zilliqa. В то время как майнеры первого поколения были незначительно более эффективны, чем установки GPU,
следующее поколение, скорее всего, обеспечит значительный рост энергоэффективности, что может привести к централизации майнинга. У Zilliqa есть возможность избежать этой проблемы (по крайней мере, на время), выбрав другой алгоритм, для которого ASIC не существует.

Etherium медленно эволюционирует в сторону sharding версии своего блокчейна. Последняя спецификация Ethereum 2.0 описывает двухуровневую систему, которая имеет архитектурное сходство с Zilliqa (см. рисунок ниже).

Как и у Zilliqa, у Ethereum есть несколько шардов, на которых блоки транзакций производятся параллельно с помощью комитетов-валидаторов, случайным образом распределенных в шарде. Подписанные хеши блоков шардов отправляются в блок Beacon с консенсусом Proof of Stake (PoS).
Beacon Chain функционирует так же, как DS-комитет Zilliqa и Main Chain, объединяющая микроблоки шардов, а также управление назначением, ротацией и финансовыми стимулами валидаторов. Очень важная роль принадлежит основной цепи Ethereum — Legacy Chain, которая принимает депозитарии валидатора и передает их в сеть Beacon. Таким образом, Ethereum следует за предложением Виталия о переходе на полный PoS, в котором цепочка Beacon Chain в конечном счете заменит цепочку Legacy PoW в качестве основной цепи Ethereum.

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

Достижение консенсуса по блокам достигается с использованием модифицированной версии Casper FFG (описано здесь и здесь).
Если злоумышленник контролирует от 1/3 до 1/2 доли валидатора, то безопасность зависит от предположения частичной синхронизации, при этом если такое предложение будет выше 1/2, то злоумышленник может вернуть последние обработанные им блоки. Ethereum 2.0 требует, чтобы часы каждого валидатора синхронизировались со всеми остальными, чтобы обрабатывать блоки в фиксированных 8 или 16 секундах.

Пропускная способность Ethereum 2.0 с 1024 шардами оценивалась в 13 410 TPS. Это теоретическое число, которое не учитывает, что пропускная способность замедляется, когда транзакции должны синхронизироваться по шардам, а количество транзакций, требующих синхронизации, увеличивается с количеством шардов. В следующем разделе рассматривается, почему эта синхронизация является необходимым и сложным аспектом реализации интеллектуальных контрактов на sharding архитектурах.

Шардинг

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

Рассмотрим простой контракт, который позволяет пользователям зарезервировать место в поезде, отправив платеж по контракту. Если адрес учетной записи Алисы и адрес учетной записи Боба совпадают с разными шардами, и каждый из них выдает транзакцию для резервирования места, две транзакции не могут работать независимо параллельно на разных шардах, поскольку состояние контракта,
то есть количество зарезервированных / доступных мест, создает зависимость между транзакциями. Если осталось только одно место, и транзакция Алисы удастся зарезервировать, то контракт Боба исполниться не сможет. Можно подумать о назначении таких транзакций одному шарду на основе адреса контракта, но эта стратегия не имеет перспективы на реализацию, когда задействованы два или более контракта, адреса которых не совпадают с одним и тем же шардом.

В широком спектре транзакций совершается несколько сделок с несколькими контрактами и / или несколькими учетными записями пользователя. Например, простой обмен токенами ERC20 будет включать обновление состояния по двум отдельным контрактам ERC20 как для покупателя, так и для продавца. Балансы, подлежащие обновлению, сопоставляются со счетами покупателя и продавца, чьи адреса указывались в контракте.

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

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

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

Продолжение ожидайте в следующей части.

Спасибо.