🌐 EOS.IO, техническая белая бумага (часть 1)

blockchained (68)in #ru • 7 years ago (edited)

Черновик: 5 июня 2017

Аннотация: EOS.IO представляет собой программный комплекс, реализованный в новой блокчейн-архитектуре и позволяющий осуществлять вертикальное и горизонтальное масштабирование децентрализованных приложений. Возможность масштабирования достигается путем создания схемы, аналогичной операционной системе, поверх которой предполагается разработка самих приложений. Разрабатываемый программный комплекс включает в себя управление аккаунтами и аутентификацией, базы данных, асинхронный обмен данными, а также управление очередями выполнения для приложений с возможностью распределения задач между сотнями процессорных ядер или целыми [серверными] кластерами. Результатом является технология, представляющая собой блокчейн-архитектуру, масштабируемую до миллионов транзакций в секунду, не требующую от пользователей комиссионных платежей за использование, а также позволяющую развертывать децентрализованные приложения легко и быстро.

Копирайт (с) 2017 block.one

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

Отказ от ответственности: Настоящий черновик технической бумаги EOS.IO публикуется исключительно в информационных целях. block.one не гарантирует точность заключений, сделанных в этой бумаге, выпускает ее "как есть", без гарантий полноты покрытия и явного или неявного гарантирования перечисленных (но не ограниченных ими) условий: (i) коммерческая пригодность, возможность конкретного применения, именования или несоблюдения (прав); (ii) отсутствие ошибок в тексте, возможность использования по конкретному назначению; а также (iii) ненарушение содержимым данной бумаги прав третьих лиц. Выражается явный отказ от любых гарантий. block.one и любые аффилированные структуры отказываются от любых обязательств и возможного ущерба, причиной которых может стать использование, упоминание или полагание на информацию, содержащуюся в данной бумаге, а также любые рекомендации относительно возможности наступления таких последствий. Block.one и любые аффилированные структуры ни в коем случае не несут ответственность перед каким-либо физическим или юридическим лицом за любой прямой, косвенный, намеренный или иной ущерб, полученный в результате использования, упоминания или обоснования действий на информации, содержащейся в данной бумаге.

Вступление

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

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

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

Требования к приложениям на блокчейне

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

Поддержка миллионов пользователей

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

Возможность бесплатного использования

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

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

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

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

Скорость отклика

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

Последовательная производительность

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

Параллельная производительность

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

Алгоритм консенсуса (DPOS)

EOS.IO использует единственный децентрализованный алгоритм консенсуса, способный удовлетворить потребности в производительности приложений на блокчейне: Делегированное Доказательство Владения Долей (Delegated Proof of Stake, DPOS). Согласно этому алгоритму, держатели токенов могут избирать производителей блоков посредством процесса непрерывного утверждения и голосования. Решение о производстве блоков может принять любой желающий, и такая возможность будет ему предоставлена. При этом количество блоков, разрешенное к производству, будет пропорционально количеству голосов, полученному им в сравнении с другими производителями. Держатели токенов внутренних корпоративных блокчейнов (например, руководство компании) будут использовать токены для подбора и найма IT-специалистов.

В EOS.IO блоки будут создаваться каждые 3 секунды, при этом в каждый момент времени правом создать блок будет обладать только один производитель. Если блок не был создан согласно расписанию, соответствующий отрезок времени пропускается. Если пропущен один или несколько блоков, то в блокчейне остается разрыв в 6 или более секунд.

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

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

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

Подтверждение транзакций

В типичных DPOS блокчейнах в работе участвуют все производители блоков. Транзакция может считаться подтвержденной с вероятностью 99.9% в течение 1.5 секунд с момента её отправки.

Есть вероятность возникновения некоторых экстраординарных ситуаций, вызванных сбоем в ПО, отключением от интернета или намеренным вредительством со стороны производителя блоков - в таком случае возникает ответвление (форк). Для абсолютной уверенности в необратимости транзакции узлу сети может потребоваться дождаться подтверждения от 15 из 21 производителей блоков. Для стандартной конфигурации EOS.IO в нормальных условиях на это потребуется 45 секунд. По умолчанию все узлы будут считать блок необратимым после получения подтверждения от 15 из 21 производителей и не станут переключаться на ветку, в которой нет этого блока, независимо от длины ветки.

Узел сети имеет возможность предупреждать пользователей о высокой вероятности нахождения на ветке меньшинства уже в течение первых 9 секунд с момента перехода на такую ветку. После 2-х последовательно пропущенных блоков вероятность нахождения узла на ветке меньшинства равна 95%. После 3-х вероятность достигает 99%. Существует возможность создания надежной модели прогнозирования, которая на основе информации об отключенных узлах, недавних рейтингах участия и других факторов могла бы быстро предупреждать пользователей о проблемах.

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

Транзакции как Доказательство Владения Долей (TaPoS)

EOS.IO требует включения в каждую транзакцию хеша от заголовка предыдущего блока. Этот хеш выполняет две функции:

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

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

Аккаунты

EOS.IO позволяет использовать в качестве идентификатора аккаунта уникальные, доступные для человеческого восприятия имена длиной от 2 до 32 символов. Имя выбирается создателем аккаунта. Для обеспечения возможности хранения данных счет аккаунта должен быть пополнен минимальной суммой в момент создания. Кроме того, имена аккаунтов могут содержать указатель на пространство имен (namespace), при этом только владелец аккаунта @domain может создавать аккаунты вида @user.domain.

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

Сообщения и обработчики

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

Управление правами доступа на основе ролей

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

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

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

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

Именованные Уровни прав доступа

Аккаунты EOS.IO имеют возможность задавать именованные уровни прав доступа с возможностью наследования разрешений от более высокого уровня (иерархия прав доступа). Каждый именованный уровень доступа определяет единицу администрирования; такая единица при этом представляет собой процедуру проверки мульти-подписи с указанием порогов действия, ключей и/или именованных уровней доступа других аккаунтов. Например, уровень доступа "Друг" может быть установлен для аккаунта, который может контролироваться в равной степени аккаунтами всех друзей пользователя.

Другим примером может служить блокчейн Steem, имеющий три зафиксированных в коде именованных уровня прав доступа: владелец, активное право, и право на публикацию. Право на публикацию дает возможность осуществлять только социальные действия, такие как голосование и публикация записей, в то время как активное право позволяют делать всё, кроме смены владельца. Право владельца имеет смысл хранить на холодном носителе (не подключенном к сети), т. к. оно дает возможность осуществления с аккаунтом любых действий. EOS.IO обобщает такой подход, давая возможность каждому владельцу аккаунта задавать свою собственную иерархию прав доступа, а также группировать действия.

Именованные группы обработчиков сообщений

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

Обработчики сообщений верхнего уровня именуются по имени аккаунта, а нижнего - по индивидуальным типам сообщений, которые получает аккаунт. Такие группы могут быть вызваны как @accountname.groupa.subgroupb.MessageType.

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

Привязка прав доступа

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

Применение прав доступа

В процессе доставки сообщения типа Action от @Алисы к @Бобу EOS.IO первым делом проверит, обладает ли @Алиса соответствующими правами доступа для @bob.groupa.subgroup.Action. В случае, если соответствие не найдено, будут последовательно проверены права на @bob.groupa.subgroup, затем @bob.groupa, и в конечном итоге, на @bob. Если не найдено никаких соответствий, предполагается применение именованной группы разрешений @alice.active.

Как только соответствие найдено, право подписи проверяется с учетом порога мульти-подписи и права именованного разрешения. Если проверка заканчивается неудачно, проверяются родительские разрешения вплоть до прав доступа владельца, @alice.owner.

Исходные группы прав доступа

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

Параллельный разбор прав доступа

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

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

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

Сообщения с отложенной доставкой

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

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

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