Серия PoCo #2 — Об использовании стекинга для предотвращения атак
В серии статей PoCo рассматривается протокол Proof-of-Contribution, разработанный iExec. Последняя статья дает широкое представление о протоколе. Во втором эпизоде мы обсудим стекинг (staking) , как он поможет предотвратить атаки и как он станет частью экономики токенов.
Я не совсем понял ваш последний пост об агентских стимулах, вы можете объясни так, как будто мне пять лет?
Платформа iExec использует технологию блокчейн для создания рынка, где люди могут арендовать вычислительную мощность для запуска децентрализованных приложений (DApps). В этой платформе существует 4 типа агентов:
- Разработчики приложений разрабатывают приложения, работающие на платформе Ethereum / iExec
- Пользователи хотят запускать приложения и поэтому покупают вычислительные мощности для их выполнения
- Работники выполняют приложения, необходимые пользователю, и поэтому продают вычислительные мощности
- Планировщики организуют работников в рабочие пулы и управляют выполнением задач: обработка распределения работы, назначение задач работникам, передача данных и обработка сбоев.
В предыдущей статье мы представили протокол Proof-of-Contribution (PoCo), который гарантирует, что результаты, вычисленные работниками, являются действительными и могут быть доверены пользователю, который их требовал. Протокол PoCo управляет тем, как несколько работников достигают консенсуса по результату вычислений, используя несколько механизмов: настраиваемый пользователю порог доверия, репликация задач и голосование по результатам, репутация работника на основе истории вычислений и депозит безопасности работника (стекинг). Вот основные шаги протокола, но вы можете обратиться к первой статье, чтобы прочитать более подробное описание:
- Каждое выполнение приложения имеет порог доверия, который определяет минимальный уровень уверенности, необходимый для проверки результатов.
- Перед выполнением каких-либо вычислений работники должны внести гарантийный депозит (долю).
- Рабочие (случайно назначенные планировщиком) выполняют вычисление и предоставляют (подписанный) хэш результата, который они вычисляют.
- Вклад каждого работника имеет уровень доверия, который зависит от репутации и доли работника.
- Когда несколько работников предоставляют один и тот же результат, их доверенность агрегируется для вычисления уверенности в результатах.
- Задача дублируется до тех пор, пока один из предложенных результатов не превысит доверительный порог. На данном этапе мы достигли консенсуса по результатам применения:
- Работники, которые вычислили ошибочный результат, потеряют свою долю
- Работники, рассчитавшие проверенный результат, будут совместно использовать вознаграждение, состоящее из платежей приложения (от пользователя) и доли, потерянной работниками, опубликовавшими ошибочный результат. - Репутация работников корректируется.
“Вы используете механизм репутации, это делает вас уязвимыми для атак Сивиллы”
Позвольте мне объяснить вам, почему это не так. Атака Сивиллы (Sybil attack) — это атаки, использующие множество личностей для подрыва механизма репутации. Для их предотвращения требуется способ контроля за созданием новых личностей. На первый взгляд, наш механизм PoCo может быть атакован многими работниками, пытающимися преодолеть консенсус.
Стекинг это часть PoCo, который не позволяет таким атакам быть жизнеспособными.
PoCo контролирует количество личностей, которые может использовать любой пользователь, требуя от них хранения токенов RLC, чтобы считаться допустимым рабочим. Координация работников, пытающихся взять на себя консенсус, ограничивается планировщиком, случайным образом выбирая какие работники работают над данной задачей. Для того, чтобы выполнить атаку Сивиллы, злоумышленник должен был бы создать много личностей, а так же внести достаточные доли для этих личностей, чтобы фактически была предоставлена работа планировщиком.
Таким образом, чтобы захватить x% платформы, злоумышленнику придется удерживать x% доли в рабочем пуле.
Почему я должен сделать ставку для участия в качестве работника?
Первый вопрос, который может прийти на ум: “как работник, сколько я получаю за работу, которую я делаю?”. Простым ответом будет «ваша доля зависит от того, на сколько вы внесли свой вклад в достижение консенсуса». Существуют различные способы расчета того, что такое «справедливая доля», а выбор формулы производится планировщиком и может варьироваться между рабочими пулами. Эта «справедливая доля» является результатом распределения оплаты, оплачиваемой пользователем, среди работников. Поэтому, чем больше работников требуется для достижения консенсуса, тем больше вознаграждение делится, что приводит к тому, что каждый работник получает меньше.
Использование стекинга позволяет избежать этого негативного эффекта.
Принимая токены от плохих участников, мы не только даем стимулы против выполнения неправильных вычислений, но и гарантируем, что работники, вносящие вклад в спорный консенсус, могут сделать столько же, сколько они сделают при выполнении любого другого приложения.
В этой статье мы будем оценивать стэкинг механизм в условиях различных нападений. Описанные здесь атаки выполняются скоординированными злоумышленниками. Они не хотят делать какие-либо вычисления, чтобы обеспечить «хороший» результат (в противном случае они были бы просто честными пользователями) и соглашаются с ложным результатом. Отправляя один и тот же поддельный результат, они атакуют консенсус, надеясь на свой результат, чтобы достичь порога доверия требуемого приложением, и получить вознаграждение.
Нам нужно бороться только с скоординированными атаками, когда нападающие работают вместе. Действительно, с такой же долей несогласованных нападавших угроза консенсусу будет меньше.
Мы также можем заметить, что если нападавшие должны были плохо себя вести по какой-то причине, чтобы попытаться притвориться честными пользователями, это приведет к уменьшению очевидной доли атакующих, следовательно, уменьшается количество плохих вкладов, нападающих на консенсус, и снижается эффективность атак.
Применяя безопасность посредством репликации к несвязанной части выполняемых задач, PoCo не оставляет места для злоумышленников, чтобы избежать обнаружения, как в подходах, которые полагаются на случайную проверку места.
Применяя безопасность через репликацию к несвязанной доле выполняемых задач, PoCo не оставляет места для злоумышленников, чтобы избежать обнаружения, как в методах, которые полагаются на случайные выборочные проверки.
Вы можете показать нам, что произошло бы без стекинга?
Как обсуждалось ранее, не делая ставку, мы ожидаем, что работники получат меньшую награду, способствуя спорному консенсусу, тем самым делая атаки эффективными, раздражая честных работников. В то же время, рабочие ничего не потеряют и могут даже получить прибыль, если им удастся достичь консенсуса.
На следующем графике показана средняя прибыль за вклад как для злоумышленников (красный), так и для честных работников (зеленый), для различных значений обязательств (следует рассматривать как отношение вознаграждения, данного пользователем). По горизонтальной оси расположены различные соотношения атакующих в платформе в диапазоне от 0,05% до 50%. Для каждого значения мы моделировали выполнение 100 000 заявок (100 000 независимых консенсусов). Затем мы показали среднюю награду за вклад в эту платформу.
В этих симуляциях всем работникам была дана идентичная репутация 90%. Плата за приложение была установлена на значение 1.
Есть несколько вещей, которые мы можем увидеть здесь:
- Если мы увеличим порог доверия, необходимый для достижения консенсуса, каждый вклад получит меньшее вознаграждение. Это связано с тем, что даже без нападавших требуется больше вкладов для достижения консенсуса, и поэтому вознаграждения распределяются среди большего количества работников. Это является ожидаемым и может быть решено путем настройки стоимости, основанной на требуемом уровне доверия.
- Средняя прибыль для злоумышленников не отрицательная. В то время как злоумышленники едва получают какую-либо награду, выполнение атаки все еще может быть прибыльным и, безусловно, будет эффективным, если единственная цель состоит в том, чтобы быть подлым с честными работниками.
- .Средняя прибыль для честных работников уменьшается, когда нападающих становится больше. Вместе с плохими вкладами, нападающими на консенсус, требуются больше честных работников, и вознаграждение распространяется среди большего числа пользователей.
Можете ли вы показать нам, что меняется, когда мы добавляем стекинг?
Используя тот же симулятор, мы можем взглянуть на эффективность влияния ставки на прибыльность работника. Прибыль, показанная на следующих графиках, сочетает в себе прибыль, полученную при положительном вкладе в консенсус, и потере ставок при отрицательном вкладе в консенсус. С теми же параметрами, что и для предыдущего графика, мы постепенно увеличиваем ставку, совершаемую разными работниками при отправке результата приложению. Вклады, внесенный в победившую сторону консенсуса, сохранили свою ставку и были вознаграждены. С другой стороны, вклады, внесенные в проигрышную сторону, не вознаграждены и теряют совершенную ставку.
Как и ранее, стоимость запуска приложение установлена 1. В предыдущем разделе было показано, что происходит без ставки (сумма ставки равна 0). В этом разделе мы рассмотрели ставки от 10% до 200% от текущей стоимости заявки.
При увеличении ставки работника, мы видим изменение формы кривой. Когда ставка высока, средства, конфискованные у плохих вкладчиков, настолько высоки, что за каждый плохой вклад злоумышленника количество дополнительных работников, необходимых для достижения консенсуса, ниже, чем увеличение вознаграждения. В таких случаях высокий коэффициент атакующих приводит к всплеску, который нарушает равновесие между вкладами. Этот всплеск указывает на то, что более выгодно вносить свой вклад в спорный консенсус, когда вы можете получать средства, совершенные плохими работниками, чем вносить вклад в новые консенсусы, когда единственная награда исходит из базовой стоимости заявки.
Различные графики, видимые выше, показывают, что для того, чтобы все вклады честных работников были вознаграждены одинаково, не будучи затронутыми присутствием злоумышленников, ставка, совершаемая с каждым вкладом в консенсус, должна составлять от 20% до 50% от стоимости заявки. Эта сумма составляет от 1 до 3 раз больше ожидаемой выгоды, что, по нашему мнению, достаточно низко, чтобы не пугать работников, обеспечивая при этом хорошую экономику протокола.
Насколько вы защищены от скоординированных атак?
В этом разделе мы оцениваем, насколько вероятна успешная атака. Мы считаем, что атака удалась, если у злоумышленников были поддельные результаты, принятые PoCo. В этом случае пользователь получает ошибочный результат, а честные работники, внесшие свой вклад в выполнение задания, не получают оплаты и их ставка похищается злоумышленниками.
Подобно предыдущим экспериментам, мы измерили долю консенсуса, выигранного злоумышленниками. Как ранее мы анализируем выполнение 100 000 заявок для каждой рассматриваемой среды.
Как и ожидалось, способность PoCo предотвращать атаки зависит от порога доверия. Более высокий порог доверия означает более низкую восприимчивость к атакам за счет большего объема взносов, необходимых для достижения консенсуса.
Для порогов доверия 99% (соотвественно 99.9%, 99.99%, 99.999%), наименьший коэффициент нападавших, по которым мы наблюдали плохой консенсус (1 из 100000) составил 1,238% (соответственно 1.811%, 5.376%, 11.513%).
Хотя достижение консенсуса с ошибочным результатом технически не невозможно (и не может быть гарантировано, что этого не произойдет), это крайне маловероятно. В тоже время, злоумышленники потеряют много денег из своих фондов обязательств, перераспределенных на честных работников. Рисунки в предыдущем разделе показывают, что для того, чтобы не потерять деньги (красная кривая выше 0), атакующий должен будет контролировать ⅓ рабочих в пуле. Даже если бы они когда-либо это сделали, они могли бы выиграть гораздо больше, используя всех этих агентов (и фонды ставок) для реальной работы на платформе.
Хотя повышение порога доверия может обеспечить защиту от крупных атак, у него также есть своя цена. В наших симуляциях, требующих доверительного балла 99,999% для достижения согласия, удваивается число работников, необходимых для достижения консенсуса (на платформе без любого злоумышленника) по сравнению с целевой оценкой в 99%. Это означает, что для того, чтобы работник получил такое же вознаграждение, пользователям придется заплатить вдвое больше за дополнительную уверенность.
В дополнение к безопасности изменение порога доверия также влияет на шаблон выполнения. Использование порога доверия 90% или меньше, вероятно, позволит работнику достичь консенсуса без посторонней помощи, возвращая результат с минимальной задержкой. Это обеспечит QoS (качество обслуживания), аналогичное обычным облачным провайдерам. С другой стороны, использование доверительного порога выше 99,99% помешало бы любому работнику достичь консенсуса самостоятельно и привело бы к систематической репликации, повышению уверености в результате, а также затратам на запуск приложения и задержке в достижении консенсуса, прежде чем результат может быть отправлен обратно пользователю.
Как насчет ошибочных выполнений DApps (багов)?
В предыдущем разделе все плохие вклады исходили от нападавших, а честные работники получали одинаковый результат. Однако сложность программного обеспечения, его время выполнения и аппаратное обеспечение, на котором они выполняются, может привести к ошибкам или повреждению данных, которые не приводят к сбою программы, но могут повлиять на полученные результаты. Мы обозначим эти потенциальные события как “ошибочные выполнения” приложения. В худшем случае, когда эти ошибочные выполнения систематически производят одинаковые (плохие) результаты, мы столкнулись бы с чем-то похожим на скоординированную атаку, описанную ранее. Мы показали, что если плохие результаты предоставляются менее чем в 1% случаев, то мы можем быть уверены, что консенсусный механизм будет работать правильно.
С экономической точки зрения, ошибочные выполнения лишь незначительно перераспределят часть средств между удачливыми и невезучими работниками. В среднем, работники все равно будут вознаграждены на ту же сумму. Тем не менее, хотя эти ошибочные выполнения не влияют на долгосрочную прибыльность работника, они также не должны негативно влиять на репутацию. Они не должны мешать честному работнику расти на платформе. Поэтому, вместо того, чтобы сбрасывать доверие к 0, когда плохой ответ представлен, мы должны рассмотреть возможность потери только части истории, либо через соотношение (например, потерять 50% вашего бонуса), либо через фиксированную ставку (например, потерять 50 очков). При условии, что они все еще имеют достаточную ставку, работники смогут быстро восстановить утраченную репутацию. Для старых работников, которые уже собрали RLC через свою работу, такие события были бы практически невидимыми. Единственные обстоятельства, при которых ошибочное выполнение оказало бы реальное воздействие на работника, заключались бы в том, чтобы напасть на молодого работника с низкой начальной ставкой, прежде чем он успеет вырасти и набрать достаточный импульс (средства и репутацию).
Тем не менее, от разработчиков DApp ожидаются усилия по написанию надежного кода. Рабочие пулы также могут использовать механизм белого/черного списка для ограничения того, какие DApps выполняются их работниками. Хотя аудит кода каждого приложения нереалистичен, можно использовать репликацию для проверки правильности приложения. Подробнее об этом ниже
Как насчет координации атаки приложением (DApp)?
Более сложная схема атаки, обсуждаемая u/mreima на Slack и Reddit, которая может быть развернута злоумышленниками, — это использовать конкретное приложение, чтобы попытаться украсть ставки других работников. Идея заключается в том, что, если приложению удастся обнаружить, работает ли оно на одном из работников злоумышленника или нет, оно может использовать эти знания для выполнения атаки. Если оно выполняется на одном из рабочих-злоумышленников, приложение будет предоставлять правильный результат все время, но если он работает на другого работника, он может давать неправильный результат с некоторой вероятностью.
Несмотря на то, что приложения не должны получать доступ к информации, идентифицирующей исполнителей, злоумышленники могут намеренно делать утечку информации в приложения. Тем не менее, если среда выполнения приложения одинакова во время проверки приложения и позже, во время выполнения на честном работнике, приложение не должно быть в состоянии уклониться от процесса проверки, и мы должны быть в состоянии обнаружить высокую вероятность ошибочных выполнений (сигнализация, что приложение не ведет себя правильно).
Но является ли такая атака более сложной, чем описанный ранее сценарий? Мы обсудили, что ошибки в приложениях вызывают разницу в прибыли работников, но средняя прибыль остается очень похожей и это не будет препятствовать рабочим. Однако это верно только в том случае, если все работники идентичны. Если некоторые работники (принадлежащие атакующему) гарантированно никогда не будут проигрывать, они получат «несправедливое преимущество» и украдут деньги других работников.
Однако такое приложение, предназначенное для проведения атаки, потребует от пользователей оплаты за его выполнение. Моделирование показывает, что если злоумышленник должен заплатить за это, затраты на это значительно превысят выгоду от атаки для средств обязательств, обсуждавшихся ранее (x0.2 ~ x0.5). В конце концов, честные работники выиграют от затрат, уплаченных злоумышленником для выполнения мошеннического приложения, больше, чем злоумышленник украдет ставок с помощью мошеннического приложения.
Таким образом, это нападение не является жизнеспособным, если приложение предназначено специально для атаки. Оно может быть жизнеспособным в контексте полезного приложения, используемого многими пользователями.
Однако такое приложение уже получает часть вознаграждения, и его репутация среди пользователей платформы будет разрушена, если такое поведение будет доказано. Приложения с открытым исходным кодом были бы плюсом для предотвращения таких типов атак. Опять же, планировщик может решать, какое приложение может быть запущено в управляемом им рабочем пуле.
Как показано на приведенном выше графике, потенциальный злоумышленник, владеющий 25% платформы, в среднем выиграл бы 25% средств, обмениваемых через платформу, независимо от наличия ошибок в приложении (сценарии хороших DApp и плохих DApp). С другой стороны, сделать атаку на хорошее приложение и совершить атаку через специально разработанное плохое приложение не будет выгодно в долгосрочной перспективе.
Как вы можете проверить DApp?
Простой способ статистически определить плохое поведение приложения-запустить приложение n раз в контролируемой среде. В нашем случае мы сосредоточены на плохом поведении, приводящем к тому, что приложение возвращает ошибочный результат. Если среди N реплицированных запусков (с одним и тем же входом) у нас есть 2 или более результатов, это означает, что что-то пошло не так, и приложение явно не без ошибок.
Однако что произойдет, если все реплицированные запуски дадут одинаковый результат? Что это скажет о приложении? Если мы заметим p вероятность того, что приложение предоставит этот результат (работа корректная), а x=1-p вероятность получения другого результата, то вероятность достижения n раз «хорошего» результата равна p^n. Это означает, что вероятность y обнаружения недетерминизма при выполнении n запусков приложения равна:
Мы также можем вывести количество требуемых повторений для достижения заданного уровня достоверности:
Эти уравнения дают хорошее представление о количестве повторений, необходимых для проверки приложения (и его среды выполнения). Например, если мы хотим 99,9% уверенности в том, что приложение завершится с ошибкой менее чем в 1% случаев, мы должны сделать по крайней мере:
Рейтинг и репутация Dapp
Как и все другие агенты, участвующие в платформе iExec, доверие к приложениям имеет первостепенное значение. Пользователи хотят, чтобы они последовательно предоставляли правильный результат, чтобы можно было достичь консенсуса и вернуть результат как можно скорее. Работники также хотят, чтобы они предоставляли согласованные результаты, чтобы избежать потерь, которые они понесут, если они приведут к ошибочному результату. Они также хотят убедиться, что их система не пострадает от неправильного поведения приложения.
Это означает, что приложения должны быть сопоставлены, чтобы их время выполнения можно было предсказать по входным данным, которые они предоставляют. Это необходимо для определения цены запуска приложения. Это также будет полезно для защиты работников от бесконечных циклов. Приложения должны быть разработаны для обнаружения недопустимых входных данных, которые могут привести к бесконечному циклу. Тем не менее, проблема остановки требует, чтобы мы контролировали время выполнения приложения и потенциально останавливали его, чтобы защитить рабочих.
Для определения репутации приложения можно использовать историю поведения в прошлом и результаты проверки с помощью репликации, рассмотренные ранее. Мы даже можем представить себе репутацию, показанную в магазине Ðapp, используя значки, такие как золото/серебро/бронза. Добившись высокой репутации, приложения могли бы стать более заметными и приниматься большим количеством рабочих пулов, которые использовали бы их в качестве механизма белого списка.
Автор: Hadrien Croubois
Опубликовано: 8 декабря 2017
Первоисточник на английском языке:
Присоединяйтесь к нам:
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
___________________________________________________________________
