Zilliqa: двухнедельный отчет #25 — подготовка к запуску Mainnet

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

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

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

Мы также рады сообщить нашему сообществу разработчиков, что мы подготовились, к тому чтобы у них были все необходимые SDK для разработки приложений на Zilliqa. С помощью сообщества у нас очень скоро будут SDK на таких языках, как C #, Python, Java и Go, для удовлетворения общих требований в отрасли.

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

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

Конец января 2019 года — запуск Mainnet

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

Q1-Q2 2019 — окно обмена токенами

Подробности будут опубликованы ПОСЛЕ запуска сети в конце первого квартала. Будет включен список бирж / хранителей, поддерживающих swap(обмен)
У нас будет окно обмена токенами, открытое на несколько месяцев, чтобы было достаточно времени для swap(обмена)

Предстоящие события

19–20 января — Сингапур — Binance Blockchain Week

22 января — Сингапур— LongHash Incubator Event

23–24  января — Лондон, Великобритания — Security Tokens Realised

Технические обновления

Наша команда продолжает внедрять обновления функций и исправления ошибок, поскольку периодически запускаемый Testnetv3 (кодовое имя Mao Shan Wang) приближает нас к окончательной конфигурации для основной сети.

Обновления для начальных узлов

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

Обновления PoW Mining

Как вы, возможно, уже знаете, майнинг Proof-of-Work (PoW) в Zilliqa выполняется на двух уровнях сложности, в результате чего узел назначается шарду или комитету DS. Мы исправили две проблемы с майнингом PoW, которые наблюдались во время тестирования.

Во-первых, мы заметили, что при майнинге для уровня DS использовалось одноразовое значение, которое делало сложность излишне более высокой, чем должна была быть. Это произошло потому, что временная метка, используемая для определения сложности, была установлена на время после завершения майнинга на уровне шарда. Используя ту же временную метку, что и при начале майнинга на уровне сегмента, майнинг на уровне DS может быть выполнен с тем же одноразовым номером и, таким образом, завершается быстрее.

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

Обновления для обработки транзакций

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

Кроме того, нулевой адрес (т. е. 20-байтовый нулевой адрес) теперь зарезервирован для получения наших вознаграждений на основе монет. Сумма, удерживаемая адресом, фиксируется на этапе начальной загрузки, и запрещается совершать какие-либо транзакции с этим адресом.

Обновления P2P Communication

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

Интерпретатор Scilla

Задумывались ли вы, возможно ли совершить транзакцию в сети Ethereum и проверить ее действительность в Zilliqa?

Хорошие новости! С недавним добавлением схемы подписи ECDSA в Scilla мы приблизились на шаг к этой цели. Возможность проверки подписей ECDSA в контракте Scilla будет иметь важные последствия с точки зрения построения ретрансляционных сетей. Обратите внимание, что схема подписи Schnorr (та, которая используется в Zilliqa для подписания транзакций) уже поддерживается в Scilla.

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

С этой целью мы написали новый анализатор JSON без проверок и с акцентом на скорость. Этот парсер для контракта, подобного ERC20, работает в два раза лучше (для больших входных состояний), чем старый парсер. Сейчас мы сохраняем оба парсера с возможностью переключения на основе флага командной строки. Причиной сохранения является обработка ситуаций, когда интерпретатор запускается как часть IDE, при этом злоумышленник может предоставить недопустимое состояние.

Мы также завершили первый этап пользовательских ADT. Пользовательские ADT позволят разработчикам умных контрактов создавать объединение структур. Например, в следующем объявлении определяется пользовательский тип MyType с тремя возможными конструкторами: Nothing (без параметров), Name (с параметром типа String) и AddrAmount (с двумя параметрами типа ByStr20 и Uint128).

type MyType =
 | Nothing
 | Name of String
 | AddrAmount of ByStr20 Uint128

Для тех, кто знаком с C перечислениями: enum sign {Positive | Zero | Negative};, соответствующий код в Scilla может быть записан как: type sign = Positive | Zero | Negative.

На первом этапе не допускается полиморфизм или индукция (следовательно, нет рекурсивной структуры данных, такой как деревья). Следующий шаг — разрешить индуктивные АDT. С точки зрения проверки типов это довольно просто, но мы еще не определились с индуктивным принципом для таких ADT. Нам также необходимо оценить стоимость газа при использовании рекурсии по индуктивным ADT.

Инструменты разработки и библиотеки

Не за горами новый год и запуск основной сети, мы стабилизировали основные API-интерфейсы библиотеки JavaScript и сделали несколько настроек безопасности при подготовке к замене токенов:

Изменено использование определения секретного хранилища Web 3. Zilliqa теперь использует hmac-sha256 для генерации mac вместо простого sha256. Кроме того, мы дополнительно включаем IV и идентификатор шифра в вычисления Mac, в отличие от DK определения [16..31] ++ <ciphertext>.
Изменена контрольная сумма адреса, которая использует 6 * i-й бит для ветвления вместо 4 * i-го Эфириума. Это прежде всего для предотвращения путаницы / случайных ошибок пользователей приложений кошелька.

Также мы начали процесс переноса библиотеки JavaScript на другие популярные языки, включая Java, C # и Python. Это должно обеспечить лучшую поддержку биржам и другим разработчикам dApp, которым может не понравиться JavaScript API. Кроме того, мы намерены разработать простой демон, способный локально управлять закрытыми ключами и подписывать полезные нагрузки через RPC (сокет или HTTP).