EOSIO Dawn 4.0

Katya_CryptoLionsKatya_CryptoLions Posts: 29 Brand New

Оригинал: https://medium.com/eosio/introducing-eosio-dawn-4-0-f738c552879
Дата перевода: 12/05/2018

Прошло около месяца с тех пор, как block.one представил EOSIO Dawn 3.0. На протяжении этого месяца, наша команда была сосредоточена на чистке и обеспечении стабильности программного обеспечения EOSIO. Большая часть этой работы заключалась в реализации доказательства концепции в межблочной коммуникации.

За исключением слияний, 43 автора сделали 818 коммитов на github. Это вывело EOSIO в топ-8 самых активных c ++ проектов на github за последний месяц. Соответственно, было внесено не мало изменений.

  1. Новое временное обозначение
  2. Новая рыночная модель распределения ОП
  3. Улучшение коммуникации внутри блокчейна
  4. Обновление последнего необратимого блок-алгоритма DPOS
  5. Сквоттинг имени
  6. Валидация по заголовку
  7. Доказательства замены легко заряжаемого производителя
  8. Усовершенствованная модель оплаты производителя
  9. Деактивация голоса производителя
  10. Поддержка обменной интеграции

Новый концепт “сейчас”
Одним из самых главных изменений в EOSIO Dawn 4.0 является изменение определения текущего времени с «времени головного блока» на «время текущего блока». Благодаря этому можно решить много проблем, возникающих при превышении нормальных параметров с временными операциями, при наличии пропущенных блоков. Также новый временной концепт помогает гораздо более точно измерять прошедшее время в рамках интеллектуальных контрактов.

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

Согласно нашим вычислениям, если 1 терабайт ОП распределить пропорционально между владельцами токенов, стоимость за байт должна составлять $0,018, при условии, что 1 токен = $20. На практике, большинство владельцев токенов фактически не нуждаются в той оперативной памяти, которую они имеют право использовать; поэтому мы первоначально оцениваем ОП на уровне $ 0,000018 за байт, при условии, что 1 токен = $20. Для новых аккаунтов требуется около 4 КБ ОП, что позволяет оценивать их на уровне $ 0,10. Как только ОП зарезервирована, цена начинает автоматически увеличиваться. Таким образом, цена приближается к бесконечности вместе с исчерпанием ОП.

В соответствии с системным контрактом Dawn 3.0, ОП можно было продавать только по той цене, которую заплатили за нее вы. Этот подход помогал предотвращать накопление и спекуляции. Недостатком такой модели является то, что пользователи, которые дешево покупают ОП, не имеют никакого финансового стимула освобождать ОП для других пользователей в случае перегрузки. В Dawn 4.0 системный контракт теперь покупает и продает ОП по рыночной цене. Это может привести к тому, что трейдеры будут покупать ОП сегодня в ожидании потенциальной нехватки завтра. Со временем, использование такой модели должно привести к тому, что спрос и предложение на ОП будет сбалансировано.

Закон Мура позволит производителям блоков обновиться до 4 тб или даже 16 тб ОП, что снизит рынковые цены на EOSIO ОП.

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

Минимизация спекуляций
С появлением рынка ОП появились возможности для спекуляций. Так, можно торговать волатильностью и получать прибыли. Системный контракт EOSIO делает ОП непередаваемой и взимает комиссию в размере 1% за любой акт трейдинга. Как результат, можно компенсировать естественную инфляцию токенов, выведя их из рынка. Если годовой объем торгов ОП равен стоимости всего объема токенов, то 100% всех вознаграждений производителей блоков будут покрываться за счет рыночной оплаты ОП.

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

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

Цена ОП будет разной на всех цепочках, а разработчики DAPP будут получать информацию о том, где ее можно использовать по самой доступной цене.

Программа параллелизма
Коммуникация внутри блокчейна, Inter Blockchain Communication (IBC), включает в себя обе цепочки, проверяющие доказательства Меркла размером 1 кб и больше, а также множество десятков криптографических хеш-функций и/или более 15 подписей. Иными словами, стоимость валидации сообщения из другой цепочки примерно на 15 - 30 раз выше, чем стоимость валидации обычных транзакций.

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

Мы считаем, что масштабирование через IBS имеет огромный потенциал. Этот подход позволяет одновременно масштабировать оперативную память, сеть и процессор. Учитывая, что проверка подписи, валидация внеконтекстных действий и доказательства IBC будут достаточной нагрузкой для большинства процессоров с высокой однопоточной пропускной способностью, оптимизация для многопоточного WASM исполнения, скорее всего, будет усложняться другими ограничениями ресурсов.

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

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

Благодаря этой модели параллелизма, мы можем упростить EOSIO 1.0 и оптимизировать ее для максимальной однопоточной производительности и простоты разработки. Мы ожидаем, что однопоточная версия EOSIO сможет когда-то достичь 5000-10 000 TPS. Мы также ожидаем, что многие приложения перейдут на многоцепный подход к масштабированию, поскольку это приведет к снижению общих затрат и увеличению потенциала масштабирования.

Обновление последнего необратимого блок-алгоритма DPOS
Те из вас, кто следили за дебатами по алгоритму консенсуса, возможно, слышали, что DPOS с алгоритмом последнего необратимого блока (LIB) (как он существует в Steem & BitShares) может выходить из консенсуса в случае некоторых экстремальных сетевых сбоев. В прошлом я не брал во внимание этот режим потенциальных собое из-за его чисто теоретического характера, а также относительно минимальных затрат и простоев. Алгоритм LIB был всего лишь метрикой, точно также как правило 6 блоков для биткойна. Чистый DPOS всегда основывался на правиле самой длинной цепи, что обеспечивало безусловное достижение консенсуса. Алгоритм LIB стал упрощенной версией, которая помогает оптимизировать историю действій и дать уверенную оценку обменам.

Чтобы достичь полной исполняемости, алгоритм IBC EOSIO должен зависеть от DPOS LIB. С добавлением IBC, затраты, связанные со сбоями LIB и трудностями восстановления, существенно увеличиваются. Наша команда, в частности Барт и Архаг, придумала прекрасный способ усовершенствования алгоритма LIB, которое гарантирует, что два узла не смогут достичь разных LIB, если больше ⅓ из них не являющихся византийскими. Кроме того, этот алгоритм позволяет обнаружить византийское поведение даже на одном одноранговом узле. Подробнее об этом можно прочитать здесь.

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

Сквоттинг имени
Некоторые пользователи проявили беспокойство из-за ограничения в 12 символов, действующего на аккаунтах EOSIO. Эти 12-символьные имена получены из base-32 кодирования 64-битного целого числа. 64-битное целое - это нативный размер машинного слова и, следовательно, очень эффективен. В наших транзакциях мы неоднократно ссылаемся на имена аккаунтов (код, область действия, разрешения и т. д.), и наши индексы базы данных также основаны на этих 64-битных целых числах. Увеличение длины имени учетной записи может иметь большие последствия для производительности и архитектуры.

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

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

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

В связи с ограниченным временем на разработку перед выпуском версии 1.0 EOSIO, мы должны рекомендовать использовать не более 12 символов в нейминге, без таких символов как «.». Как только будет внедрена новая политика ценообразования и анти-именного сквоттинга, сообщество сможет обновить системный контракт (без хардфорка). Скорее всего, мы предоставим модель, похожую на BitShares, где имена аккаунтов оцениваются в зависимости от длины и количества символов.

Валидация по заголовку
На Steem, BitShares, EOS Dawn 3.0, как и более ранних версиях, было невозможно проверить заголовок блока без применения целого блока. В EOS Dawn 4.0 проводится валидация исключительно по заголовкам. Эта функция является основой для легких клиентов и IBC, а также предотвращает ряд векторных атак, позволяя блокам распространяться по сети, не дожидаясь полной проверки от каждого узла.

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

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

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

В EOSIO Dawn 4.0 теперь можно проверять изменения в расписании производителей, без необходимости проверять заголовки блоков. Когда производитель подписывает блок, он также подписывают новое расписание. Соответственно, исключается возможность существования двух конкурирующих и достоверно подписанных расписаний, если только больше ⅔ производителей не находятся в сговоре или больше ⅓ производителей не попадут под неправильное разделение сети.

Новая парадигма оплаты для производителя
В сообществе было много обсуждений касательно оплаты для производителей, а также о том, как распределить максимум 5% инфляции. С помощью реферальной системы, которую block.one предоставит в EOSIO 1.0, можно будет распределять инфляцию следующим образом:

Есть 21 производитель активных блоков и любое количество резервных производителей. Топ-21 разделяет 0,25% вознаграждения за каждый блок пропорционально количеству блоков, которые каждый из них производит. Все кандидаты в производителей (включая топ-21) также делят бюджет на вознаграждение в размере 0,75% за каждый голос, пропорционально общему количеству голосов, которое они получают. Они могут требовать свою долю вознаграждений за голосование не чаще одного раза в день. Чтобы претендовать на свою долю, они должны иметь право на участие не менее 100 токенов в день. Кандидаты-производители, которые не могут претендовать на 100 токенов в день на основе голосования, не получат ничего.

Идея этого алгоритма заключается в том, чтобы обеспечить всем кандидатам-производителям достаточную оплату для предоставления услуг полного узла сообществу, предотвращая ситуации в которых полученная оплата не может покрыть всех расходов. Если предположить, что топ-200 кандидатов-производителей получают одинаковое количество голосов, этого было бы достаточно чтобы поддержать 21 активных производителей и 179 резервных производителей. На практике, у некоторых производителей всегда есть значительно больше голосов, чем у других, что уменьшает количество оплачиваемых резервных производителей.

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

Деактивация голоса производителя
Улучшение системного контракта является важной частью работы, которую мы проделываем с времени запуска Dawn 3.0. Одним из таких улучшения является реализация распада голоса. Чтобы держать процесс голосования под контролем, каждый избиратель должен будет повторно подтверждать свой голос каждую неделю. Влияние на голосование распадается с периодом полураспада 1 года для тех, кто не обновляет свои голоса.

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

Поддержка обменной интеграции
По мере нашего приближения к выпуску EOSIO 1.0, многие люди спрашивают нас о том, как обмены будут мониторить EOSIO блокчейн в соотношении входящих депозитов и/или подтверждать, что их выходные отозвания принимаются и необратимо подтверждаются. Чтобы ответить на подобные вопросы, мы создали учебное пособие по использованию cleos (наш интерфейс командной строки eosio) для отслеживания цепочки входящих депозитов. Мы также создали демонстрационный скрипт python, который контролирует депозиты и отозвания. С этим пособием и примерами скриптовых обменов, у вас есть все необходимое чтобы начать интеграцию с EOSIO блокчейнами.

Доступность EOSIO Dawn 4.0
Разработка кода EOSIO Dawn 4.0 продолжается в «тонкой» ветке на github. Мы планируем усовершенствовать его и официально выпускать 11 мая 2018 года. В это время мы будем двигаться по ветке, осваивая и связывая новый релиз. Разработчики, которые хотят получать нужную информацию, могут следить за нашим прогрессом в тонкой отрасли.

Вывод
Мы уверенно двигаемся к релизу программного обеспечения EOSIO 1.0 в июне этого года. При разработке Dawn 4.0 мы хорошо почистили код, и сейчас мы более уверены, чем когда-либо.


Перевод: CryptoLions
Website
Telegram
Steemit
Twitter
GitHub
Meetup

Sign In or Register to comment.