🌐 EOS — Введение (Ян Григг) (часть 2)
IV. АРХИТЕКТУРА
Философия.
В практическом смысле подход программного обеспечения, лежащего в основе EOS, призван расширить опыт, полученный в масштабных высокопроизводительных блокчейнах Bitshares и Steem, и использовать его для обеспечения поддержки бизнеса конечных пользователей. Почти все элементы были ранее опробованы и в большей или меньшей степени доказали свою эффективность, и данная архитектура пересобирает их вместе с новой целью - построение распределенных приложений.
Этот раздел описывает некоторые важные архитектурные отличия ПО EOS от предыдущей практики. За техническими подробностями рекомендуется обращаться к документу EOS.IO Technical White Paper (Larimer, 2017)
Сообщение является Носителем.
Подход, заложенный в ПО EOS.IO, переходит от более популярного консенсуса о состоянии к менее известному консенсусу о событиях (Grigg, 2017-1). Этот подход объединяет шаблон источника события (Fowler, 2005) с блокчейном, создаваемым больше из событий, чем из состояния.
В информатике машина в предопределенном состоянии строится как машина, состоящая из программы, состояния (памяти) и входящих и исходящих событий. Каждый раз, когда происходит нечто, приводящее к изменениям, реальная машина запоминает промежуточные данные и после перезапуска восстанавливает себя путем восстановления этих промежуточных данных. При построении реальной машины состояний мы выбираем между сохранением событий или сохранением состояния, и выбор определяется главным образом тем, что конкретно мы пытаемся оптимизировать.
Рис. 2. Вендинговый автомат в терминах машины состояний
Исходя из изображенного на рисунке 2, следует ли сохранять красное сообщение или синее состояние? Машина, сохраняющая состояние, вероятнее всего будет использоваться в контексте, где фокус делается на том, в каком она сейчас состоянии, например, в случае с базой данных. Машина, сохраняющая сообщения, больше годится для ответов на вопросы о том, как мы пришли к текущему состоянию, например, она используется в протоколах или юридически значимых логах, таких, как тройная запись в бухучете (Grigg, 2005). Перезапуск происходит быстрее, если есть сохраненное состояние; производительность улучшается, если сохранены сообщения.
Поскольку пользователям необходима производительность, подход ориентирован на сохранение сообщений. Перезапуск потока сообщений, или машины, основанной на событиях, схож с восстановлением с самого начала, и потому происходит невероятно медленно, а оптимизация, сводящаяся к сохранению контрольных точек, возвращает нас обратно к сохранению состояния.
Но что критически важно, при сохранении состояния исполнитель остается ограничен сохраненными сообщениями, а не состоянием, и потому мы можем произвести серьезную оптимизацию и даже пересчитать контрольные точки, если это будет необходимо.
Более точное описание подхода к оптимизации является слишком объемной темой для этого введения, достаточно будет прогноза о том, что комбинирование технологий в теории может дать блокчейну прирост с 3-х транзакций в секунду до 3-х миллионов.
Консенсус.
Для достижения консенсуса о сообщениях архитектура EOS.IO использует Делегированное Доказательство Владения Долей (DPOS) – двухуровневую структуру управления, уже проверенную в Steem и Bitshares (Larimer, 2014).
На первом уровне выбирается круг из 21 производителя, каждый из которых производит один блок на круг и вознаграждается за проверку входящих сообщений и производство блока из этих сообщений. Блок выпускается одним производителем и проверяется следующим за ним, и следующим, и так далее; если проверка завершается неудачей, блок не фиксируется в качестве основания для следующего. Далее следует схожая с Bitcoin механика, очень быстро приводящая всех производителей к соглашению о самой длинной цепи. Блок, утвержденный кворумом производителей, объявляется необратимым, и цепь необратимых блоков в результате становится контрольной точкой.
Как и в доказательстве выполненной работы, производители могут цензурировать (игнорировать) сообщения или забегать вперед, рассылая собственные, делая прогнозы на будущее. Для обеспечения легкости управления плохим поведением производителей каждый круг производителей непрерывно избирается сообществом, использующим доказательство владения долей (PoS). Поскольку этот второй круг выборов, регулируемый блокчейном, затрагивает производителей, а не блоки, так называемая уязвимость “отсутствия доли” здесь неприменима.
В результате для кампании выбран набор Генералов, и каждый получает один ход. По окончании кампании гражданское общество выносит решение о замене любого неподходящего Генерала.
Рис. 3. Делегирование позволяет заменять Генералов после провальной кампании
DPOS избегает налога на майнинг, возвращая этот значительный ресурс обратно держателям долей. Изначально вся сумма вознаграждения за блок передается производителям. Тем не менее, поскольку они избираются сообществом, они мотивированы на разделение награды согласно такой схеме, с которой соглашаются между собой производители и которая поддержана сообществом.
Согласно конституции, вознаграждение за производство блоков в долгосрочном периоде может быть ограничено, скажем, 5% в год (Larimer, 2017-2). В качестве варианта мы предлагаем возвращать сообществу основную часть суммы на общее благо - улучшение программного обеспечения, разрешение споров и тому подобные цели. В духе выражения “своё всегда лучше” проектируемый подход предполагает голосование сообществом за публичные контракты, действующие подобно “фондам” на нужды сообщества. Механизм, известный как Контракты Общего Дохода, подчеркивает важность DPOS как алгоритма, обеспечивающего сообществу прямое управление посредством блокчейна (далее).
Контракт.
Архитектура по своей сути больше приближена к организации отношений через рассмотрение контрактов в качестве динамического выражения согласования, подтверждения и событий, нежели к более статичной интерпретации “четырех углов листа” или выполнению кода машиной.
Мы предлагаем использовать сообщения в качестве естественного элемента достижения договоренностей, поскольку они лучше подходят ко всем фазам успешного соглашения: обсуждение, намерение, действие и нарушение обязательств – все события больше похожи на сообщения, чем, скажем, на состояния.
Пользователь записывает контракт как виртуальную конструкцию, закрепляющую обработчиков сообщений. Пользователь может преобразовать свой аккаунт в агента соглашения, добавив обработчик сообщений и используя встроенное в аккаунт хранилище, подобное базе данных, для хранения внутреннего состояния своих контрактов. Несколько обработчиков сообщений, работающих совместно, способны управлять потоком сообщений таким образом, чтобы в процессе своего жизненного цикла выполнить весь контракт или юридически значимое соглашение.
Рис. 4. Связи между сторонами, заинтересованными в блокчейне
С точки зрения контракта получение, подтверждение и обработка сообщения выглядят проще, чем концепция состояния. Рассмотрим книгу обработки ордеров, как она выглядит в биржевом рынке: книга принимает позиции на покупку и предлагает к продаже. Когда приходит время, она должна рассчитать цену пересечения, которая фиксируется в подтвержденных ордерах, рассылаемых обеим сторонам сделки.
Книга ордеров в системе, основанной на сообщениях, регистрирует их в списках входящих и исходящих сообщений, и эта регистрация является относительно простой задачей. Напротив, в системе, полностью основанной на состоянии, все торговцы вынуждены договариваться о приемлемом для множества сторон состоянии, включая количества и цены, до момента заключения соглашения, открывая двери разнообразным заигрываниям.
На практике единственный путь к решению этой проблемы заключается в добавлении в систему агентов и сообщений. Активный агент получает подтвержденные сообщения, принимает решение о значении на выходе и рассылает сообщения, подтверждающие эти значения.
Удобство использования.
Непосредственным пользователем блокчейна является разработчик, создающий веб-приложения для конечных пользователей. В целях поддержки конечных пользователей, программное обеспечение должно в первую и важнейшую очередь поддерживать разработчика и делать это таким образом, чтобы помогать разработчику поддерживать своих пользователей.
Большое значение в этом процессе имеют (а) инструментарий, (б) язык и (в) экосистема (окружение).
В целом разработчик EOS.IO будет обеспечен набором веб-инструментов, предлагающим полноценный фреймворк для разработки распределенных веб-приложений, координирующих свою работу через блокчейн.
Аккаунты, политики именования и разграничения доступа, восстановление после сбоев, хранение баз данных, выполнение по расписанию, аутентификация и асинхронный обмен данными между приложениями – всё это будет встроено в фреймворк.
Целью архитектуры является получение полностью контролируемой (с точки зрения безопасности и проверки подлинности) операционной системы для разработчиков приложений, сфокусированной на веб-разработке, как на наиболее востребованной со стороны пользователей.
Язык.
В рассматриваемом контексте распределенных приложений промышленного масштаба язык для разработки контрактов находится в начале списка важнейших факторов. Большинство других архитектурных особенностей EOS.IO имеет под собой серьезный фундамент, подтвержденный опытом Bitshares и Steem, и добавление к ним смарт-контрактов является пока неизведанной территорией.
Это диктует нам необходимость тщательного анализа потребностей, предъявляемых к языку. С точки зрения выбора технологии для автоматизированного, или умного, заключения соглашений, можно выделить три стороны, для которых достижение успеха в выборе технологии является критичным: стороны, разработчики и операторы.
Рис. 5. Концепции автоматизации кода и текста контрактов продолжат развиваться (Clack1, диагр. 5)
- Сторонам нужен контракт в первую очередь являющийся настоящим контрактом. Стороны также хотят, чтобы контракт был обсуждаемым, читаемым, понятным и однозначным – им важно, чтобы их человеческие намерения были отражены честно. Предпочтительно также наличие возможностей урегулирования споров и принуждения к исполнению.
- Разработчику нужен язык и даже более широкая система, которой можно было бы легко обучиться и также легко разрабатывать с ее помощью, и которая была бы выразительна и надежна – преимущества, часто игнорируемые в угоду семантическим или логическим предпочтениям.
- В то же время операторы блокчейна – производители блоков и предприятия-владельцы полных узлов сети – нуждаются в масштабируемых контрактах, обеспечивающих основу для получения прибыли, которые нуждались бы в минимальном присутствии человека или разработчика.
Отводя потребностям сторон первое место, такой подход заставляет нас двигаться в направлении неразрывного соединения текстов юридического назначения с компьютерным кодом, склеиваемых с определенными параметрами, “управляющими сделкой” и использующими текст и код повторно с множеством контрактов (Grigg, 2015). Усилия многих исследований были направлены на объединение представлений текста и кода контракта в форме параметров более высокого порядка или же специфичного для юриспруденции подхода к организации языка программирования (Clack1, нач. 2016 см. диаг. 5), однако никому пока не удалось найти этот священный грааль. Область все еще открыта для исследований, и даже сам набор подходов к проектированию пока не устоялся (Clack2, нач. 2016).
Согласно следующим строчкам кода, в выборе направления мы изначально склонялись в сторону поддержки разработчика: интерпретируемый исходный код скриптового языка, основанного на Wren, с дополнениями для управления обработчиком сообщений, поддерживаемых контрактом. Пример кода (Larimer, 2017-1):
apply:
// исходя из того, что все предшествующие шаги успешно завершены,
// переходим к состоянию
// обновлению балансов и/или
// созданию нового аккаунта для получателя
var from = Balance[message.from]
var to = Balance.find( action.to )
from.bal = from.bal - action.amount
to.bal = to.bal + action.amount
Этот гибрид Wren достаточно доступен и прост в изучении и чтении, что делает его идеальным для автоматизации контрактов. Тем не менее он оказался медленным: тесты с тривиальными транзакциями показали потолок в 1000 TPS, что указало нам на конфликт с потребностями операторов, наших производителей блоков и приложений для бизнеса.
Рис. 6. Участники и Конституция при объединении создают Сообщество
Так как наша цель в 100 раз выше указанного уровня, команда переключилась на WebAssembly (WASM), являющийся новым языком промежуточного уровня, спроектированным для выполнения задач, в настоящее время возлагаемых в браузерах на Javascript. Первый неоптимизированный тест, проведенный фреймворком EOS с использованием WASM, показал более 50,000TPS на валютном контракте.
Итак, WASM перевел поиски с операторов на стороны контракта – теперь есть 3 материальных представления каждого контракта: юридически значимый текст, исходный код на C и промежуточный код на WASM.
Поэтому разумным становится вопрос: где, или в чем хранится контракт, по которому стороны достигли соглашения? Я бы хотел ответить на этот вопрос прямо. В течение двух десятков лет или около того я вижу контракты, выпускаемые в сети, в Рикардианской форме и не только, и они порождают сотни проблем. Но я до сих пор вижу споры и даже путаницу, которые сводятся к вопросу, о чем именно контракт говорит или что имеет ввиду.
Даже урок The DAO, приведший к потерям в $150 миллионов и показавший как не надо выпускать контракты, сводился в основном к проблемам с безопасностью. И независимо от того, с какой стороны рассматривать степень подверженности контракта взлому, ответ заключался в принудительном изменении всего, что нужно было изменить, чтобы получить деньги обратно. Решение проблемы никак не было организовано ни с точки зрения формальностей, ни с точки зрения анализа фактов, значения и прав, с целью избежать подобной ситуации в будущем.
Все еще остается открытым вопрос: сколько споров в суде происходит из-за толкований и путаницы, и сколько решается силовым путем, но я настроен скептически.
Пример The DAO и другие наблюдения заставляют меня предположить, что наделение властью лишь контракта (Grigg, 2004) делает подход догматическим и слишком ограничивающим. Вместо этого, по крайней мере в сфере публичных реестров (DLT), существует возможность освободить компоненты контракта для достижения лучшей работоспособности, даже несмотря на потери от незначительного ослабления регулирования.
В то же время мы должны сконцентрироваться на управлении и сделать разрешение споров не только возможным, но и удобным для всех сторон сделки.
По состоянию на момент написания документа работа над набором языков, доступных для разработчика контрактов, всё еще не закончена. WASM, Wren или любой другой – все языки одинаково нуждаются в структурировании для повышения производительности и удобства использования.
Каждому именованному обработчику сообщений понадобится определить разделы кода, куда помещать методы класса, методы только для чтения и методы чтения и записи, и у всех вариантов есть резерв для оптимизации [т.е. они все еще не оптимальны]. Чтобы избавиться от повторяющихся проблем, исходящие сообщения будут накапливаться до завершения или отбрасываться в случае ошибки. Мы намерены добавить таблицы, напоминающие по структуре SQL, чтобы упростить переход тем, кто знаком с базами данных. Криптография останется за сценой и практически не будет заметна.
Рис. 7. Сообщество может назначать управляющих, контролирующих исполнение.
Как и во всем сегменте DLT, в проекте продолжается конкуренция. Wren компактный и краткий. WASM только закончил стандартизацию. Ранние инструменты WASM нацелены на C и C++, которые, при своей популярности, довольно дороги для написания кода в сравнении с языками высокого уровня поздних поколений, такими как Wren.
Эти вызовы не являются критичными в долгосрочной перспективе, т.к. проект WASM намерен поддерживать большинство языков, а большая часть кода любого распределенного приложения вынесено из обработчиков в код веб-сайтов. Способность поддерживать множество популярных языков выглядит заманчивой, но это преимущество пока доступно только JVM от Corda и не достигается простым путем в Bitcoin или Ethereum, которым не хватает целостного подхода к циклу разработки.
Наконец, выбор языка и инструментария для разработки сопряжен со значительными компромиссами, которые выходят далеко за рамки удобства написания кода. Мы бы хотели получить легкий для чтения и понимания скриптовый язык, оперирующий полным набором терминов контракта и при этом остающийся безопасным и масштабируемым. Но на текущий момент без компромиссов обойтись не удается.
Управление.
Вернемся к экосистеме. Ко всеобщему огорчению, сбои в автоматической обработке контрактов являются суровой реальностью. Мы надеемся снизить как частоту, так и издержки, связанные с подобными ошибками, но полностью от них избавиться невозможно, а потому наш подход заключается в создании способов восстановления после сбоев.
Блокчейн, построенный на ПО EOS.IO, предполагает, что все пользователи блокчейна приняли краткую Конституцию (Larimer, 2017-2; Grigg, 2017-3), и это согласие объединяет их в сообщество, подчиняющееся Конституции.
Конституция закрепляет ряд базовых правил, действующих во благо сообщества. Конституция наделяет властью три ветви управления: арбитраж при разрешении споров, выбор блоков производителями, и принятие решений путем голосования. Объединенные во взаимосвязанном треугольнике управления, эти три ветви власти поддерживают баланс интересов друг друга.
Референдум используется сообществом для голосования за производителей и арбитров, а также за изменения в коде и конституции. Арбитры могут обеспечить юридически связные решения в спорных ситуациях, а также в случае необходимости экстраординарных изменений, подобных хардфоркам. Производители блоков свободны технически цензурировать некорректные транзакции или выпускать корректирующие – но при этом они должны принимать во внимание возможные последствия со стороны сообщества.
Арбитры публикуют решения, которые должны быть подкреплены производителями, либо же пользователи могут найти внешние рычаги воздействия.
Это взаимно сбалансированное соглашение позволяет удостовериться в том, что ни одна группа не получит полную власть. Даже основатели и разработчики имеют только ограниченные возможности влияния на права участников сообщества. Хардфорки и другие обновления должны проходить через определенные процедуры, частные споры разрешаются в специально отведенном месте, после чего мы возвращаемся обратно к своим делам. Еще большая выгода заключается в том, что большая часть описанного выше процесса управления может осуществляться прозрачно, путем написания для контрактов обработчиков, поддерживающих разрешение споров, проведения референдумов и т.п.
Для обеспечения работоспособности этих учреждений пользователи должны принять Конституцию, наделяющую производителей властью выбирать блоки и закрепляющую за форумом арбитров обязанность разрешения споров.
Конституция также создает юридические права, выраженные в блокчейне, путем закрепления за каждым членом сообщества гарантий соблюдения его прав, и соответственно, требования от каждого члена сообщества соблюдения прав других.
Эта сделка, выраженная в правах одних и других, становится краеугольным камнем сообщества, при этом членство в сообществе определяется как использованием платформы, так и принятием Конституции.
И поэтому мы оставили открытую запись даже несмотря на то, что сообщество управляется внутренними механизмами. Даже когда пользователь создает транзакции, с первой и до последней записи - все ссылаются на Конституцию посредством хеширования, подобно Рикардианскому контракту (Grigg, 2004).
Являясь явным механизмом управления, конституция скорее выполняет роль ограждения, нежели глухих стен, а функции сторожа либо автоматизированы, либо сводятся к контролю за росписью в журнале посетителей.
V. СРАВНЕНИЯ
Bitcoin.
Как платформа, запустившая первую и самую успешную криптовалюту, Bitcoin принимается за основу сравнения. Однако, как это часто бывает с “первыми”, ее недостатки не менее значительны, чем ее успех: модель проверки UTXO означает необходимость кодирования смарт-бизнеса где-то вне платформы.
Состояние прекрасно зафиксировано в цепи, однако тяжелая работа по его согласованию производится в приложениях. Платформа не имеет хорошего фреймворка для активов, и это особенно проявляется в том, что каждая транзакция включает в себя BTC, и потому вступает в силу предупреждение Грешема о недостоверности передачи актива: «Худшие деньги вытесняют из обращения лучшие».
Фреймворку недостает продуманного уровня управления, что приводит к чрезвычайному усложнению апгрейда, а сообщество очень разобщено. Например, искусственное ограничение в 3 TPS, убивающее масштабируемость, является прямым следствием отсутствия управляемости.
Ethereum.
Для избавления от слабостей Bitcoin, Ethereum предлагает возможности Тьюринг-полной виртуальной машины на глобальном компьютере. Это имеет несколько значительных недостатков. Во-первых, серьезные ограничения налагает требование к нахождению консенсуса о состоянии путем тысяч выполнений программы, ведущее к перебоям в работе уже при 15 TPS. Во-вторых, решение о единственном языке, VM, наборе инструментов и т.п. привело к зависимости от возможностей разработчиков. В-третьих, платформа страдает от спонтанности (адхократии в противовес бюрократии) Основателей, не желающих обращать внимание на призывы акционеров к необходимости в управлении.
Будучи новым видом бизнеса сам по себе, Ethereum в основном служит для привлечения средств в проекты, нацеленные главным образом против самого Ethereum, либо собирающиеся конкурировать с ним. Незначительное количество новых сценариев использования заставляет считать, что Ethereum предстоит немало поработать над концепцией смарт-контрактов, прежде чем она начнет приносить плоды.
Corda.
Основным отличительным фактором Corda является то, что это не блокчейн, а фреймворк для исключения посредников из взаимодействия сторон. Вместо отправки действий и контрактов в блокчейн, стороны обмениваются сообщениями и приходят к консенсусу через нотариат. Тем самым достигается конфиденциальность, высокая производительность, не ограниченная координацией цепи, и возможность контроля сторонами успешности выполнения контрактов.
И хотя взаимодействие между небольшим количеством сторон работает отлично, с увеличением числа участников выпуск активов, особенно наличных, и проведение безналичных торговых сделок дается платформе с трудом. Другая слабость заключается в изолированности в целях регулирования бизнеса, что снижает привлекательность платформы для массового рынка мелких игроков.
VI. ВЫВОДЫ
Ощущение от использования.
Непосредственными пользователями блокчейна, подобного EOS, являются предприниматели и разработчики, пишущие контракты для создания распределенных приложений, или DApp. Пользователи таких приложений – это обычные покупатели в магазинах, финансах, логистике, медиа. Им не нужно знать о том, что такое блокчейн. Целью является дать разработчикам платформу, позволяющую реализовать расширенную бизнес-логику, но скрыть при этом механизм коммуникации.
Разработчик DApp получает платформу, обладающую полностью дееспособными аккаунтами, управлением правами доступа и возможностью обмена сообщениями – теми средствами, которыми можно наделять разрабатываемую систему.
Пользовательский интерфейс является привычным – webkit для разработки сайтов и, конечно, доступа к блокчейну. Этот подход можно охарактеризовать как “операционная система для блокчейна”.
Факт того, что блокчейн может быть скрыт от пользователя, продемонстрирован на примере Steem, который является просто еще одной платформой для блоггинга, оказавшейся распределенной в блокчейне.
Сценарии использования.
Назначение блокчейна EOS заключается в обеспечении высокопроизводительного обмена сообщениями с бизнес-логикой. Популярными сценариями будут цепочки поставок, управление ресурсами, пользовательские сообщения, например, социальные сети, выпуск и торговля активами, учет денежных переводов и игры.
Типичным сценарием может быть Uber. Совместные поездки основаны на установлении стандартов поведения для водителя и пассажира. Если водители и пассажиры являются членами одного сообщества, то они получают непосредственную выгоду – основа обязательств и стандартов поведения будет заложена в конституции сообщества и в разрешении споров, и их контракты будут скорее двусторонними, чем включающими посредников, тем самым сложности регулирования будут минимизированы.
Далее, поскольку контракты могут быть двусторонними, прохождение сделки может быть разделено: отслеживание пассажиров на рынке, отслеживание доступности машин, поиск совпадения, переговоры и контракт, выполнение, расчет, установление цены и отслеживание социальной активности – всё может быть построено в виде отдельных DApp, взаимодействующих между собой.
Сообщество.
Для поддержки бизнеса мы должны решать проблемы. Развивать подходы к решению проблем сообщество должно самостоятельно, что означает необходимость закладывания такой возможности в архитектуре. Для развития сообщества мы должны сохранить открытый вход, но при этом обеспечить инструменты, которые будут удобны для организации управления. Пользователи хотят знать свои риски и обязательства перед контрагентами.
Рис. 8. Цель - Умный бизнес
Пользователи, объединенные в сообщество Конституцией, будут знать, что права, обязательства и ответственность их контрагентов как минимум не ниже базовых стандартов, определенных конституцией, и что они обеспечены системой разрешения споров. В дополнение к этому, надежные имена и сеть доверия могут снизить анонимность Интернета и дать пользователям ощущение принадлежности к чему-то важному.
ПЕРВАЯ ЧАСТЬ
Свежие новости в Телеграм: t.me/EOS_RU
Оригинал поста: ЗДЕСЬ
Поддержите делегата blockchained на Голосе
