EOS.IO: Обновление разработки

Katya_CryptoLionsKatya_CryptoLions Posts: 29 Brand New

Оригинал: https://steemit.com/eosio/@dan/eos-io-development-update
Дата перевода: 07/05/2018

Мы очень усердно работали над тем, чтобы сделать EOS.IO лучшей смарт-контракт платформой на рынке. Наша команда достигла новых вершин в блокчейн дизайне, обеспечивая наилучший баланс между простотой разработки и эффективностью.

В нашем последнем обновлении мы изложили некоторые изменения, над которыми мы работали, в том числе:

  • Поддержка Apple Touch ID / Secure Enclave
  • Исправление ошибок в отложенных (асинхронных) транзакциях
  • Параллельное внедрение

С времени прошлого обновления мы выполнили многое из того, что обсуждали. Большую часть этой работы мы отобразили в ветке eos-noon на github, для того чтобы предоставлять услуги мастера тем, кто использует тестовую сеть. Вот некоторые детали о том, над чем мы работали.

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

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

Эта функциональность теперь завершена в нашем коде и будет доступна после релиза тестовой сети EOS Dawn 3.0, которую мы надеемся запустить к концу первого квартала 2018 года.

Задержки авторизации
Время - это самый главный аспект безопасности. На данный момент, мы находимся в процессе обновления структуры разрешений EOS.IO, которые позволят пользователям настраивать обязательные задержки для каждого уровня доступа. Например, публикация материала в социальных сетях может быть мгновенной, но для перевода средств может потребоваться 24 часа или больше. Когда пользователь пытается выполнить действие в условиях установленной задержки, транзакция будет “упакована” и отложена на период задержки. Эту транзакцию также можно отменить в любое время до конца истечения задержки. Это позволит пользователю использовать функцию восстановления взломанной учетной записи, чтобы восстановить контроль над своей учетной записью до того как любой вред может быть нанесен.

Восстановление взломанного аккаунта
Для каждого аккаунта будут применяться три специальных разрешения: владелец, активный и восстановление. Разрешение владельца должно быть сконфигурировано через мультиподпись, которая требует N ключей из группы M членов (2 из 2) и может мгновенно изменять все другие разрешения. Чтобы изменить разрешение владельца, необходимо настроить задержку на 30 дней. В идеале владельцу потребуется активное разрешение партнера по восстановлению. Таким образом, чтобы взломать разрешение владельца, потребуется одновременно скомпрометировать как пользователя, так и его партнера по восстановлению. Если активный ключ партнера по восстановлению был взломан, то партнер по восстановлению может использовать разрешение владельца чтобы восстановить аккаунт. На практике это создает сеть доверия между всеми пользователями, которая требует, так как для того чтобы скомпрометировать учетные записи нужно сломать всех сразу.

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

Восстановление утерянного пароля
Люди забывают пароли, компьютеры ломаются, может произойти все что угодно. По закону Мерфи, все, что может пойти не так, пойдет не так, и это касается даже самых продуманных планов mice- и крипто-экспертов. С EOS.IO, удача на вашей стороне. Для каждого аккаунта можно указать несколько партнеров по восстановлению, которые смогут обновлять активное разрешение (с задержкой 7 дней), но только если ваш аккаунт неактивен в течение 30 дней. Если доверить право возвращения доступа к аккаунту людям, которым вы доверяете, вашим друзьям или родственникам, вам не нужно будет беспокоиться о том, что ваш аккаунт может быть навсегда заблокирован.

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

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

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

Раздельное владение долями
Самое существенное изменение, которое мы внесли - это создание различных пулов владения долями для разных прав. Главная цель - определение конкретной экономической ценности различных цен спроса и предложения на полосу пропускания, память и контроль. Например, мы не хотим, чтобы люди выделяли память, которую они не намерены использовать, только для того чтобы иметь возможность требовать право голоса ли полосу пропускания. Мы также хотим наложить 3-дневную задержку на отмену владения долей полосы пропускания, отсутствие задержки на отмену владения долей неиспользуемого хранилища, а также 6-месячную задержку в случаи отказа от голосования. Пропускная способность и голосование могут быть делегированы, но хранение не может. Как вы видите, существует еще много различных вопросов, которые необходимо решить.

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

Голосование
Теперь, когда мы разделили пулы владения долей для полосы пропускания и памяти, мы можем обеспечить лучшее регулирование интересов тех, кто хочет контролировать процессы на платформе. Чтобы получить возможность влиять на выбор производителей блоков и обновление протоколов, пользователи должны поддерживать токены в контракте с 6-месячным периодом линейного отозвания. Это будет подвергать их капитальным потерям, если их действия окажут негативное влияние на платформу.

Память
Оперативная память (ОП) стоит дорого и ограничена способностями компьютера предоставлять только определенное количество памяти на потребительском оборудовании. Если мы распределим целый терабайт ОП пропорционально рыночной капитализации в $100 биллионов, тогда стоимость будет больше $10 за байт памяти. При таких условиях, платформа является непригодной для использования если 99,99% владельцев токенов фактически не нуждаются в ОП.

Чтобы решить эту проблему, мы можем использовать принцип Банкора, рассматривая память как смарт токен с резервом в 1%. В этом случае резерв составляет 1 ТБ реальной ОП, а алгоритм Банкор продает эту реальную ЗУПВ по динамической цене, так что резервы ОП никогда не заканчивается. Когда кто-то хочет зарезервировать ОП, он отправляет токены в контракт на память и получают зарезервированные байты на основе функции ликвидных токенов и доступной ОП.

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

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

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

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

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

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

Введение этого изменения находится в процессе и должно быть доступно в EOS Dawn 3.0.

Скрытая блокировка транзакций
Мы переименовали «области чтения/написания» в «блокировки чтения/написания», чтобы передать логику поведения, а также увеличили детализацию блокировок, чтобы максимизировать возможности для параллельного выполнения.
Разработчики, тестирующие EOS Dawn 2.0, знакомы с необходимостью обозначать «области» для каждой транзакции. Этот процесс усложнял запуск транзакции, а также делал их уязвимыми в определенных динамических ситуациях. Мы исследовали ситуацию и пришли к решению, что производители блоков могут определять, какие блокировки чтения/написания требуются. Это устранило необходимость указания необходимых блокировок в каждой транзакции, что приводит к существенной экономии и упрощает задачу для разработчиков.

Это изменение было реализовано в ветке eos-noon.

Динамические обновления основных функций
Как правило, обновление блокчейна требует применения хардфорка. Речь идет о любых изменениях, которые реализуются в случае разработки новых функций, обновления существующих функций, или исправления ошибок. Хардфорк является разрушительным для всей сети; поэтому желательно, чтобы процессы на блокчейне определялись динамически через WASM.
Мы начали процесс переноса основных функций с нативных C ++ на контракты WASM. Эти функции включают в себя следующие:

Основной токен (например, EOS)
- Владение долей полосы пропускания, памяти и голосования
- Производительское голосование
- Многоуровневые контракты
- Контракт на пользу сообществу / распределение трудовых ресурсов

Единственными транзакциями, которые не будут реализованы непосредственно в WASM, будут:
- Создание аккаунта
- Показатели использования пролосы пропускания/ОП
- Обновления разрешений

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

Новый токен стандарт
Чтобы поддерживать взаимодействие между контрактами, мы разрабатываем стандарт токенов. Идея этого стандарта очень близка идее токенов ERC-20, что позволит настроить взаимодействие между контрактами.

Наш токен стандарт будет иметь много преимуществ по сравнению с традиционными токенами ERC-2:
- Транзакции могут содержать памятки для данных приложения
- Отправитель и получатель могут выполнять код и отклонять транзакцию
- Выгодное использование системы разрешений EOS.IO
- Нативные токены реализованы с использованием того же кода
- Один контракт может создавать и управлять несколькими токенами

Мы реализуем стандартную библиотеку C ++, которая упростит создание токенов - процесс должен быть настолько же простой, как и параметризация некоторых шаблонных переменных и развертывание контракта.

Стабильность
Мы стремимся к тому, чтобы наш однопоточный код поддерживал 5000 TPS с блочным интервалом в 0,5 секунды и с конечным результатом, полученным за 2 секунды. Этот показатель - лучший в индустрии; поэтому мы полагаем, что это решение даст рынку намного больше, чем просто хорошую производительность, включая улучшения стабильности, функций и архитектуры. Следовательно, мы фокусируемся на улучшении качества транзакций, прежде чем стремиться максимизировать число транзакций в секунду.

В нашем последнем обновлении для Dawn 2.0, мы указывали свое намерение начать работу над параллельным выполнением раньше, чем предполагалось. Из-за добавления большого количества новых полезных функций для разработчиков, мы пересмотрели приоритизацию, таргетируясь на стабильность, вместо производительности для июньского релиза EOS.IO. Мы считаем, что лучше максимально усовершенствовать архитектуру, а не стремиться показать сырую эффективность, которую рынок не сможет сразу использовать.

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

Устойчивость к византийским сбоям (BFT) DPOS
Существуют две основных системы подтверждения владения: DPOS (делегирование права на владение) и тендерные системы BFT. Каждая из этих систем имеет свои преимущества. DPOS поддерживает более быстрое время блокировки (0,5 секунды) и будет продолжать функционировать и возобновляться, даже если работает только один производитель блока. Недостатком традиционного DPOS является временная неэффективность - процесс проведения операции может занять 45 секунд. На практике, такие системы как STEEM и BitShares завершают 99,9% процесса за 2 секунды. При этом, чтобы обеспечить низколатентную коммуникацию внутри блокчейна, мы стремимся достичь полного завершения меньше чем за 2 секунды.

Системы BFT достигают абсолютной окончательности на каждом блоке, но их алгоритм характеризуется потреблением высокой пропускной способности, процесс может занимать 2-3 секунды, а также в этой системе нету промежуточных состояний с окончанием 99,9%. Кроме того, работа в этих системах полностью останавливается, если 33% узлов не работают.
BFT-DPOS дает нам самый лучший результат. Блоки производятся с окончанием 99,9% каждые 0,5 секунды и подтверждаются с абсолютной окончательностью не больше чем за 2 секунды. Такого результата можно достичь, если производители блоков производят подтверждение блока каждый раз, расширяется локальная цепочка. Византийский сбой происходит, если производитель блока отправляет два подтверждения для одной и той же высоты блока или временной отметки блока. Производители также указывают порядковый номер в каждым подтверждении, которое они отправляют. Производитель, который отправляет два подтверждения с тем же порядковым номером, также считается византийским.

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

Компенсация для производителей блоков занявших второе место

Мы разрабатываем алгоритм, который разделит систему оплаты для производителей блоков на два типа:
- Оплата за блок
- Оплата за голос

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

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

Растущая команда

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

Вывод

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

Следуйте за мной в https://twitter.com/bytemaster7 и следите за нашими специальными онлайн анонсами из Сеула!


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

Sign In or Register to comment.