Серия PoCo #3 — Обновление протокола

Что такое PoCo и зачем он нужен?

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

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

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

Каково место PoCo на платформе iExec?

Для работы платформы iExec требуются две сущности:

• Рынок, где агенты предлагают свои ресурсы и где сделки совершаются с использованием токена RLC.
• Распределенная вычислительная инфраструктура на основе промежуточного программного обеспечения XtremWeb-HEP.

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

Как указывалось ранее, разные агенты имеют разные роли и разные стимулы. Перед описанием самого протокола сначала перечислим этих агентов:

• Работники: Это частные лица или компании, которые владеют вычислительными ресурсами и готовы предоставить их для расчета задач взамен на платежи в RLC. Подобно блокчейн-майнерам, они хотят простое решение, которое сделает их компьютер частью большой инфраструктуры, которая позаботится об остальных деталях за них.
• Рабочие Пулы: Они организуют вклады работников. Их возглавляет планировщик, который организует распределение работы. Они могут быть общественными и объединять ресурсы от кого угодно или приватными и оптимизировать управление конкретным оборудованием. Не производя фактических расчетов, рабочие пулы получают плату за управление инфраструктурой. Они конкурируют за привлечение рабочих, путем достижения эффективного управления, которое гарантирует доход работникам.
• Поставщики приложений: Они развертывают приложения на платформе iExec. Это могут быть децентрализованные приложения (DApps), использующие полный потенциал децентрализованного облака или традиционные приложения на основе блокчейн, которые могут извлечь выгоду из децентрализованного облака iExec. Они могут бесплатно предоставлять свои приложения или запрашивать фиксированную плату за каждое использование своего приложения.
• Поставщики наборов данных: Они владеют ценными наборами данных и готовы сделать их доступными в безопасной парадигме, которая защищает их собственность взамен на платежи в RLC.
• Пользователи: Это отдельные лица или смарт-контракты, оплачивающие выполнение задач, с определенными наборами данных или без них, используя вычислительные ресурсы работников. Они хотят убедиться, что результаты, которые они получают, являются правильными.
• iExec Hub и рынок: Это смарт-контракт, развернутый iExec, без привилегированного доступа. Он действует как депонирование для ставок различных агентов и обеспечивает безопасность и прозрачность всех операций в экосистеме iExec.

Децентрализация, безопасность и доверие к iExec Hub и рынку обеспечиваются технологией Блокчейн. Все остальные агенты считаются потенциально вредоносными. Конструкция контроля PoCo за всеми сделками между агентами осуществляется таким образом, что он создает сильные экономические стимулы для правильного поведения. Это делает iExec гораздо большим, чем другие традиционные поставщики облачных услуг, предоставляя ему возможность организации надежной вычислительной платформы поверх инфраструктуры ненадежных агентов. Не только этот процесс построения доверия имеет интересную особенность, это важно для обеспечения любого результата для блокчейн пользователей и смарт-контрактов.

Как выглядит «номинальное» исполнение?

Создание окружающей среды

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

I. Первый этап — развертывание iExec Hub и рынка. Это смарт-контракт, на блокчейн, который связан со смарт-контрактом RLC. Это будет точка входа для последующих транзакций.

Зачем нам это нужно: iExec Hub и рынок являются сердцем сети. Они будут управлять ставками и следить за историей участников деятельности. Этот (проверяемый) смарт-контракт, без привилегированного пользователя, обеспечивает стабильность и непрерывность сети iExec.

II. На этом этапе все участники могут поместить RLC в iExec Hub. Средства, внесенные в iExec Hub могут быть заблокированы для стекинга. Это к тому же, куда получаются все награды для хранения. Средства, которые не заблокированы, могут быть выведены в любое время.

Зачем нам это нужно: стейкинг-ключевая часть PoCo. iExec Hub действует как публичный депозитарий, который обеспечивает прозрачность и безопасность ставок.

III. Рабочий пул создается и принадлежит планировщику путем вызова метода createWorkerPool на iExec Hub. Этот метод создаст экземпляр смарт-контракта рабочего пула, принадлежащего планировщику, в котором планировщик сможет задавать соответствующие параметры, а также управлять своими работниками.

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

IV. Работники, желающие присоединиться к рабочему пулу, могут вызвать метод subscribeetopool в смарт-контракте рабочего пула. Это позволит убедиться, что работник следует требованиям, установленным планировщиком (минимальная ставка и репутация).

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

V. Поставщики приложений регистрируют свое приложение, вызвав метод createApp на iExec Hub. Этот метод создаст экземпляр смарт-контракта приложения, принадлежащий поставщику приложения, который содержит некоторые параметры приложения. Среди этих параметров стоимость приложения не может быть изменена. Эта стоимость представляет собой фиксированную сумму, которая будет присуждаться владельцу приложения за каждое выполнение приложения.

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

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

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

Создание сделки на рынке

1Когда у рабочего пула есть достаточное количество рабочих, готовых выполнить некоторые вычисления, он создаст рыночные ордера на рынке, используя метод createMarketOrder. Эти рыночные ордера описывают категорию ресурсов, которые они предлагают, а также уровень доверия, используемый PoCo для сертификации результатов (который влияет на репликацию и, следовательно, стоимость). Рыночные ордера будут действительны для определенного количества пользовательских запросов (называемых рабочими заказами).

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

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

Зачем нам это нужно: Сделка-это обязательство обеих сторон (планировщика и пользователя). Ставки фиксируются на iExec Hub и экземпляр записи продвижения работы создается для обеспечения прослеживаемости.

На этом этапе PoCo блокирует ставки и инициализирует экземпляр консенсуса, специфичный для этого рабочего задания.

Результаты расчетов и консенсус

3Теперь, когда был создан рабочий заказ, рабочий пул отвечает за предоставление действительного результата пользователю. Первым шагом к достижению действительного результата является назначение работников. Планировщик должен будет вызвать метод allowWorkersToContribute со ссылкой на рабочее задание и списком работников, уполномоченных вносить вклад в соответствующий консенсус.
(Примечание: при использовании задач Intel SGX для дополнительной безопасности — это момент, когда криптографический вызов инициализируется).
Если в какой-либо момент в этом разделе планировщик считает, что для достижения консенсуса требуется больше вкладов, он может вызвать метод allowWorkersToContribute, чтобы вызвать больше работников.

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

4Работники, отобранные планировщиком, имеют доказательство своего участия он-чейн. Это предоставляет им доступ к любому из соответствующих наборов данных. После запуска приложения с параметрами, требуемыми рабочим заказом, они имеют архив результатов (RA), содержащий полученные данные (stdout, stderr, выходные файлы …). Этот архив результатов не будет отправлен на блокчейн в любой момент, но будет представлен его хэшем R=sha3(RA).
Чтобы представить свой вклад в консенсус, работник представит “подпись” вычисленного результата с использованием метода contribute. Эта “подпись” состоит из двух значений:
- H = sha3(R),
- S = sha3(R ^ sha3(WorkerAddress))
H является представление результата R, которое одинаково для всех работников, которые вычислили один и тот же RA. S используется в качестве подписи. Это не позволяет работникам просто публиковать значения H, которые они видят в представлении других работников. Как только R будет раскрыт (позже), он просто поможет проверить, что работник знал значение R внесенное до того, как оно было раскрыто. S не может быть скопирован у другого работника, поскольку он соответствовал бы идентичности (адреса) этого работника.
(Примечание: при использовании вызовов Intel SGX для дополнительной безопасности пользователь также должен будет предоставить криптографические доказательства того, что значения H и S, представленные здесь, были произведены анклавом рабочего iExec)

Зачем нам это нужно: Мы должны обеспечить, чтобы работники действительно выполняли работу при представлении результатов. Этот механизм гарантирует, что для получения прибыли работники должны знать R на момент их подачи. Поэтому он не позволяет им просто копировать вклад другого работника. Начиная с первого эпизода этой серии, мы поняли, что использование хэша рабочего адреса — безопасно, а также легко проверяемо, избегая при этом необходимости случайной генерации seed и проблем, возникающих в результате возможных столкновений.

5После того, как были сделаны достаточные взносы, и что бы консенсус среди них был достигнут в соответствии с формулой Сарменты, планировщик блокирует дальнейшие взносы и показывает консенсусное значение (H), используя метод revealConsensus.

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

6Теперь работники вызваны предоставить, используя метод reveal, значение R, которое соответствовало как значению H, которое достигло консенсуса, так и значению S, которое они предоставили при внесении вклада. Невыполнение этого требования не позволит им получить какую-либо награду за свою работу.

Зачем нам это нужно: Это вторая часть 2-х шагов contribute/reveal. Этот шаг подтверждает обоснованность взносов работников на этапе 4.

Завершение

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

О детерминированных приложениях

Для достижения консенсуса значение R, представленное разными работниками после правильного выполнения одного и того же рабочего задания, должно быть идентичным. Это просто при работе с детерминированными приложениями, для которых RA согласован между запусками. С другой стороны, недетерминированные приложения, для которых RA может законно отличаться между запусками, вызовут всевозможные проблемы. Такие приложения не будут поддерживаться в iExec версии 2 и будут рассматриваться позже. Существует много подходов к решению этой проблемы и обеспечению совместимости PoCo с этими приложениями. Это будет обсуждаться в другой статье этой серии.

Как PoCo обрабатывает нестандартные случаи?

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

• Защита от вредоносных исполнителей обеспечивается атрибутом allowWorkersToContribute (который запрещает любому работнику присоединяться) и процессом 2 шагов contribution/reveal, которые обсуждались ранее.
• Таймер устанавливает ограничение времени для того, чтобы работники могли вызвать метод reveal. Это обеспечивает справедливость (планировщик не может завершить консенсус слишком быстро, наказывая работников), не позволяя любому работнику блокировать консенсус.
• Если хотя бы один из работников, внесших вклад в достижение консенсуса, опубликовал соответствующий результат, этот результат записывается и блокируется при завершении рабочего задания, независимо от других работников, вызывающих метод reveal. Хотя можно сказать, что другие работники, не доказавшие свой первоначальный вклад, негативно влияют на консенсус, есть два аргумента в пользу нашего подхода:
  → Использование allowWorkersToContribute предотвращает скоординированные атаки. Даже если атаке на консенсус удастся пройти через атрибут allowWorkersToContribute (в случае атаки 51%), злоумышленники получат больше прибыли, раскрывая один и тот же результат, вместо того, чтобы позволить планировщику взять процент от всех захваченных ставок. Поэтому нераскрытый вклад не считается формой атаки. Поскольку существует сильный экономический стимул против такого вклада, мы можем предположить, что они вызваны нестабильными работниками. Мы твердо убеждены в том, что до тех пор, пока работники, ответственные за эти взносы, не будут вознаграждены и видят, что они захватили долю (например, за плохой вклад) они могут оставаться в силе при вычислении формулы Сарменты
  → Результат уже опубликован, и возобновление консенсуса в отношении нового вклада невозможно, так как гипотеза о 2 шагах contribute/reveal больше не выполняется.
• Если ни один из работников не показал действительного результата в течение периода раскрытия, все работники, которые внесли свой вклад в этот консенсус (и должны были раскрыть), видят, что их взносы признаны недействительными, а их доли конфискованы. Затем планировщик может снова открыть консенсус. На этом этапе планировщик может либо вызвать новых работников, либо инициировать выявление другого результата в зависимости от анализа Сармента оставшихся действительных взносов.
• Когда сделка была закрыта на рынке, планировщик взял на себя обязательство предоставить проверенный результат в заданный период времени. Если планировщику не удается достичь консенсуса к концу этого периода времени, пользователь может погасить неудачный консенсус. Он и все работники, которые уже внесли свой вклад, получают свои ставки обратно, и планировщик наказывается.
• Если работник считает, что планировщик неправильно управляет своим пулом, он должен уйти и пойти работать на другого, что он может сделать, не теряя репутацию, которую он получил, работая на него. Поскольку репутация хранится в iExec Hub и связана с кошельком, а не с физической машиной, работник может перемещаться по сети, сохраняя при этом репутацию, полученную ранее.
• Если планировщик считает, что работник является вредоносным, он может заблокировать его в пуле. Тем не менее, запрещенные работники сохраняют все свои права на консенсус, к которому они уже были призваны.

Почему блокчейн необходим для реализации PoCo?

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

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

Конечно, такое использование блокчейн-транзакций и смарт-контрактов имеет свою стоимость, которую мы сейчас тестируем и оптимизируем. В конечном счете (после выпуска версии 2) было бы целесообразно перейти к более масштабируемым и дешевым вариантам, таким как боковая цепочка (сайдчейн) или приватный блокчейн.

PoCo и управление на платформе iExec

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

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

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

Автор: Hadrien Croubois
Опубликовано: 11 апреля 2018
Первоисточник на английском языке:

PoCo Series #3 — Protocol update

Присоединяйтесь к нам:

iExec 🇷🇺

Веб-Сайт • Telegram • VKontakte • Instagram • Twitter • Facebook • Youtube • Medium • Golos •

iExec 🇺🇸

Website • Medium • Slack • Telegram • Reddit • Twitter • Facebook • LinkedIn• Youtube • Github • Kakao • Instagram • Steemit • Katacoda• Docs

___________________________________________________________________