Обратная связь по версии Dawn 4.0, размещение RAM (оперативной памяти)
Некоторые члены сообщества выразили обеспокоенность тем, что кому-то могут достаться неоправданные прибыли за счет скупки дешевой оперативной памяти (RAM) до того, как кто-то еще сможет попасть в цепочку.
Чтобы смягчить ситуацию, рекомендуем тем, кто запускает цепочку, начинать с весьма ограниченного объема RAM (ОП), а затем постепенно увеличивать объем оперативной памяти в течение первых двух месяцев. Ежели объем обеспечения ОП начинается с 32 ГБ, а затем увеличивается до 1 ТБ в течение нескольких месяцев, тогда цена ОП может быстро со временем снижаться до 3% от первоначальной цены.
Только те, кто действительно нуждается в оперативной памяти, или же те, кто в будущем повлияет на обеспечение ОП во время торгов, приобретут изначальную ОП.
В любом случае, «дешевой» оперативной памяти или «халявной прибыли» не получит никто.
Состояние тестовой сети
Внутренняя тестовая сеть с узлами в Европе, Азии и США работает без существенных проблем.
Возвращение субъективного использования ресурсов ЦП
В течение последних нескольких месяцев мы экспериментировали с объективным расчетом (биллингом) ЦП. Объективный биллинг пытается определить количество указаний ЦП, используемых транзакцией детерминированным образом. Здесь есть одно приятное свойство –гарантировать то, что имеется полный, однозначный консенсус относительно того, какие ресурсы потребляются в ходе транзакции. Также это представляет собой метод, используемый многими прочими смарт-контрактными платформами.
Об EOSIO рассказывалось год назад; тогда предлагалось использовать планирование субъективно лучшего усилия. В соответствии с данной моделью каждый производитель блоков измеряет физическое время, уходящее на выполнение транзакции, и взимает с пользователя соответственным образом. Для того чтобы поддерживать консенсус в отношении использования, производитель будет сообщать о количестве микросекунд, по которым выставляются счета за транзакции.
Несмотря на то, что объективный биллинг хорош в связи с его способностью устранять споры о выставлении счетов и упрощать консенсус, у него есть несколько недостатков, которые заставили нас, наконец, принять решение о субъективном выставлении счетов:
● Объективные измерения ЦП снижают производительность по причине появления дополнительной бухгалтерии.
● Объективные измерения ЦП впускают атаки и отрицание сервиса векторов в любое время, когда существует несоответствие между реальной стоимостью действия и объективным приближенным значением.
● Объективные измерения ЦП трудно поддерживать, обновлять, а также внедрять оптимизацию.
Субъективное выставление счетов имеет свои собственные проблемы, особенно касательно системы консенсуса. К счастью, были найдены инновационные решения, делающие его практичным.
Некоторые из проблем включают в себя следующее:
● Доверие к производителям касательно точного доклада об использовании.
● Устранение разногласий между производителями (вызванного «железом» / ПО / нагрузкой).
● Работа с вредоносным производителем.
С уполномоченным доказательством доли владения ожидается, что производители блоков будут государственными организациями с договорными обязательствами и юридическими последствиями в случае злонамеренного поведения. Кроме того, ожидается, что весь «комплект» из 21 активного производителя будет высоко одобрен сообществом, которое их избирало.
Исходя из этого, можем довериться им в том, чтобы те выступили в качестве «оракулов времени ЦП», и не вводили в заблуждение относительно того, сколько времени уходит на транзакцию. То есть, при нормальных условиях работы можем доверять тому, что заявленное время выполнения находится в пределах допустимых границ погрешности среднего времени выполнения для всех производителей.
Критики с данным подходом могут поспорить, указав на то, что один-единственный «злодей» может построить блок с бесконечным циклом, а затем сообщить, что тот не занимает времени.
Чтобы это предотвратить, все узлы делают «колпак» пары секунд времени исполнения для всех блоков; однако даже с «колпаком» может ожидаться сбой в работе сети. Подкованный и хитроумный производитель-злоумышленник может создать такой блок, чтобы 50% узлов его принимали, а 50% – нет. И, таким образом, расколоть сеть.
Данные векторы атак были проанализированы, из чего был сделан вывод, что блок с очень длительным временем исполнения не отличается от очень длительной задержки сети или вовсе ее отключения. Любой консенсусный алгоритм, устойчивый перед лицом сетевых разделений, должен быть также крепким перед прочими субъективными моментами. Поскольку DPOS с BFT может противостоять сетевым разделениям (как если США и Китай временно отключатся от более широкого интернета), он может выжить даже в ситуации, когда злонамеренный производитель создает такие условия.
Существует несколько способов, которыми блок-производители могут уменьшить потенциал сетевых разделений, и они одинаковы, будь ли причиной сокращение оптико-волоконного кабеля в Атлантике либо же производитель-злоумышленник.
Поддерживать множественные соединения
При таком подходе, если соединение через Атлантику будет отрезано, производитель будет маршрутизировать пакеты через Тихий океан. Когда речь идет о проверке блоков, производитель должен держать несколько проверяющих узлов и никогда не допускать попытку двух узлов осуществлять проверку того же блока.
В крайнем случае, каждый производитель мог бы иметь выделенные узлы для обработки входящих блоков от каждого производителя-пира. Если один производитель блокирует канал проверки с бесконечным циклом, тогда блоки от других производителей могут по-прежнему проходить через свои независимые, дублированные каналы.
Как только номер необратимого блока проходит мимо номера «плохого блока» (того, что с бесконечным циклом), узел может заставить обработку блока завершить работу и выйти. Потребовалось ⅔ и более производителей-злоумышленников, чтобы консенсус не развивался.
Восстановление или способ обхождения повреждения
Не всегда получается иметь множественные оптоволоконные кабели, готовые преодолеть тот момент, когда один из них окажется поврежденным. В этом случае команда отправляется на ремонт поврежденного кабеля, чтобы восстановить соединение. Это может занять больше времени, но в конечном итоге связь возвращается, и сеть возобновляет консенсус. Ничего более страшного, чем небольшой простой по времени, не происходит.
Когда речь идет о вредоносном производителе, другие производители могут просто обновить свою конфигурацию, дабы внести злодея в черный список. Затем сеть возобновит свою нормальную работу.
Процесс внесения плохого производителя в черный список может даже быть автоматизирован в любое время, когда производители наблюдают блок, требующий необоснованного количества времени исполнения. В худшем случае, злоумышленник создает блок прямо на краю порога запрета, что приводит к тому, что только половина производителей помещает его в блэклист. В такой ситуации последний необратимый блок перестанет продвигаться, пока производители решают, какому из ожидающих форков следовать.
Во всех вышеперечисленных случаях пользователи, которые полагаются на последний необратимый блок для детерминирующего завершения, находятся в безопасности касательно атак, связанных с двойными тратами. А «время простоя», испытываемое сетью, вероятно, будет меньше, чем обычное «время простоя», с которым люди сталкиваются в ходе работы со своими электроэнергетическими компаниями или ISP.
Полагается, что процессы управления и стимулы DPOS делают вероятность того, что вредоносное поведение, ведущее к кратковременному простою, является меньшим по отношению к вероятности проблем с подключением к Интернету, ведущих к простою вообще всех блокчейн-платформ.
По крайней мере, с DPOS пользователи в безопасности от бессознательного присутствия в цепочке адресных передач, которая раскатывается после повторного подключения. При сетях с Доказательством работы разделение сети может привести к атакам двойной траты для тех, кто полагается только лишь на фиксированное количество подтверждений.
Обновления системного контракта
Контракт «eosio.system» – это то, что обеспечивает реализацию регистрации производителей, голосования, доли, а также размещения ресурсов. Команда работает над обеспечением внедрения отсылки, которую сообщество может выбрать к принятию при создании цепи.
Системный контракт был обновлен в данном выпуске. Теперь он включает в себя следующее:
● Никто не может «разобрать долю», пока 150 000 000,0000 токенов не проголосовали, по крайней мере, за одного производителя или прокси.
● Если цепочка хочет выделить 10% токенов для Block.one, она будет выделять ограниченный разбор доли до 1% в год.
Восстановление атакованного аккаунта и восстановление забытого пароля
Команда создала новый подход к восстановлению взломанной учетной записи и восстановлению потерянного пароля, что позволяет практически всему быть выполненным в Web Assembly.
Добавлен новый внутренний API, который возвращает последнюю ситуацию, когда уровень полномочий был авторизован учетной записью. С данной информацией смарт-контракт теперь может реализовать «логический блок», необходимый для обеспечения 30-дневного бездействия, за которыми следует семидневное извещение, прежде потерянный пароль будет полностью сброшен в Web Assembly.
Были удалены три обработчика действий с жесткой кодировкой, для устранения потенциальных «багов» и упрощения улучшения с программными обновлениями позже. Одна или несколько реализаций восстановления потерянного пароля могут быть обеспечены в виде отдельного смарт-контракта после выпуска версии 1.0.
Теперь доступно на Github
Версия EOSIO Dawn 4.0 теперь доступна на GitHub, разработчики могут начать тестирование приложений.
Скоро выйдет EOSIO 1.0
Команда работает круглосуточно, чтобы привнести стабильную версию EOSIO 1.0 на рынок в первую неделю июня. В первоначальном выпуске будет все, что необходимо любому для создания собственного блокчейна на основе EOSIO. Внедрено «замораживание функций». А следующие несколько недель будут посвящены работе и тестированию внутренних тестовых сетей и устранению обнаруженных ошибок.
Цель – убедиться в том, что наиболее важные характеристики являются солидными и надежными. После версии EOSIO 1.0 продолжится улучшение программного обеспечения EOSIO с изменениями, не поддерживающими форкинг, что позволит добавить качества применения и инфраструктуры.
Ссылка на оригинал статьи: https://rucrypto.com/ico/reliz-versii-eosio-dawn-4.0.html