Уважаемые пользователи Голос!
Сайт доступен в режиме «чтение» до сентября 2020 года. Операции с токенами Golos, Cyber можно проводить, используя альтернативные клиенты или через эксплорер Cyberway. Подробности здесь: https://golos.io/@goloscore/operacii-s-tokenami-golos-cyber-1594822432061
С уважением, команда “Голос”
GOLOS
RU
EN
UA
blockchained
6 лет назад

🌐 Отчет о разработке EOS.IO (Daniel Larimer)

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

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

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

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

Отложенные транзакции

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

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

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

Задержки авторизации

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

Восстановление взломанного аккаунта

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

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

Восстановление утерянного пароля

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

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

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

Обновление алгоритмов использования ресурсов

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

Раздельные доли

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

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

Делегирование пропускной способности

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

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

Голосование

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

Память

Оперативная память является дорогим и ограниченным ресурсом, поскольку есть четкие пределы того, что компьютер может обеспечивать за счет недорогого стандартного оборудования. Если мы пропорционально распределим 1 ТБ ОЗУ в соответствии с рыночной капитализацией в $100B, то цена за один байт памяти составит более $10. В мире, где 99,99% держателей токенов фактически не нуждаются в оперативной памяти, это сделает платформу непригодной для использования.

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

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

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

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

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

Выставление счета за использование памяти

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

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

Данное изменение дорабатывается и, вероятнее всего, будет включено в 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 сможет без труда поддерживать бесконечное масштабирование. Эта функция в основной своей части уже готова, и мы надеемся, что демонстрация proof-of-concept межчейнового взаимодействия с двусторонней привязкой состоится в конце 2 квартала.

Устойчивость к Византийским ошибкам

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

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

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

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

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

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

  • Вознаграждение за каждый блок
  • Вознаграждение за каждый голос

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

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

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

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

Заключение

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

Следите за мной в Twitter и смотрите видео нашего специального объявления, сделанного на митапе в Сеуле!


Дисклеймер

block.one является компанией-разработчиком ПО и выпускает программное обеспечение EOS.IO в качестве бесплатного программного обеспечения с открытым исходным кодом. Это программное обеспечение может позволить тем, кто его устанавливает, запустить блокчейн или децентрализованное приложение с функциями, описанными выше. block.one не будет запускать публичный блокчейн на основе программного обеспечения EOS.IO. За реализацию функций и/или предоставление услуг, описанных выше, по своему усмотрению, будут нести ответственность исключительно третьи стороны и сообщество, а также те, кто захочет стать производителями блоков. block.one не гарантирует, что кто-либо будет реализовывать эти функции или предоставлять такие услуги, или что программное обеспечение EOS.IO будет принято и применено каким-либо определенным образом.
Все заявления в этом документе, за исключением заявлений об исторических фактах, включая любые заявления о бизнес-стратегии block.one, ее планах, перспективах, разработках и целях, являются лишь прогнозными заявлениями. Эти утверждения носят сугубо предсказательный характер и отражают текущие убеждения и ожидания block.one относительно будущих событий, которые основаны на предположениях и подвержены рискам, неопределенностям и изменениям в любое время. Мы работаем в быстро меняющейся среде. Время от времени появляются новые риски. Учитывая эти риски и неопределенности, мы предостерегаем вас от всецелого полагания на эти прогнозные заявления. Фактические результаты, производительность или события могут существенно отличаться от тех, которые содержатся в прогнозных заявлениях.
Некоторые из факторов, которые могут привести к существенным отличиям фактических результатов, производительности или событий от прогнозных заявлений, содержащихся в настоящем документе, включают в себя, без ограничений: волатильность рынка; постоянную доступность капитала, финансирования и персонала; принятие продукта; коммерческий успех любых новых продуктов или технологий; конкуренцию; государственное регулирование и законы; а также общие экономические, рыночные или деловые условия. Любое прогнозное заявление, сделанное block.one, актуально только в дату его публикации, и block.one не несет никакой ответственности и прямо отказывается от каких-либо обязательств по обновлению или изменению своих прогнозных заявлений, будь то в результате появления новой информации, последующих событий или иных факторов.

Переведено @blockchained

Оригинал поста: ЗДЕСЬ


Если вам нравится то, что мы делаем - поддержите делегата blockchained на Голосе!

2
4.078 GOLOS
На Golos с January 2017
Комментарии (2)
Сортировать по:
Сначала старые