Оригинал:
entethalliance.github.io/crosschain-interoperability/crosschainsecurityguidelines.html
1. Вступление
ЭТОТ РАЗДЕЛ НЕ СОДЕРЖИТ ОБЯЗАТЕЛЬНЫХ НОРМ.
Безопасность всегда является наиболее важной частью программируемых систем и платформ. Это ещё более актуально для блокчейна по следующим причинам:
- Децентрализованная природа блокчейна: любой код, написанный и развернутый в блокчейне, будет выполняться на многих узлах. Любой (при определённых условиях) может получить доступ и запустить код.
- Ограниченность патчей и возможности обновления: из-за неизменяемости блокчейна смарт-контракты, развёрнутые на блокчейне, не могут быть изменены. Это повышает сложность обновления децентрализованных приложений. Когда в блокчейн-приложениях обнаруживаются недостатки безопасности, стоимость исправления приложений оказывается высокой. Плохо разработанные контракты может быть невозможно обновить.
- Недоверие и отсутствие разрешений: в публичных блокчейнах как клиентские узлы блокчейна, так и децентрализованные приложения открыты для глобальных участников. Нет централизованного органа, который бы проверял квалификацию участников. Нет периметра безопасности, который бы блокировал участие недобросовестных участников.
- Конфиденциальность и анонимность блокчейна: пользователи блокчейна могут оставаться псевдо-анонимными. Функции смарт-контрактов не имеют возможности проверить профиль пользователей. Хакеры могут совершить атаку, украсть активы и остаться неопознанными.
- Большое влияние на бизнес: смарт-контракты обычно небольшие. Крупные проекты могут иметь порядка тысяч строк кода, в то время как другие проекты могут иметь только сотни строк кода. Эти небольшие фрагменты кода управляют криптовалютными активами высокой стоимости. Одна атака может привести к катастрофическим последствиям для децентрализованного приложения. Некоторые децентрализованные приложения понесли огромные убытки из-за простых ошибок в смарт-контрактах.
В последнее время наблюдается огромный рост атак на кроссчейн мосты. Хакеры используют уязвимости в смарт-контрактах, удалённых вызовах процедур (RPC), кошельках, менеджерах закрытых ключей и хранилищах исходного кода. Поскольку кроссчейн-мост — целостная система, соединяющая исходную и целевую цепочки, атаки могут быть направлены на исходную цепочку, целевую цепочку или соединяющий их мост. Хотя существует множество руководств по безопасности и лучших практик для защиты блокчейн и децентрализованных приложений в одной блокчейн-системе, безопасность кроссчейн не так хорошо освещена. Данное руководство восполняет этот пробел, описывая области и факторы, которые необходимо учитывать при создании кросс-цепочечных мостов.
2. Соображения по безопасности кроссчейна
ЭТОТ РАЗДЕЛ НЕ СОДЕРЖИТ ОБЯЗАТЕЛЬНЫХ НОРМ.
Чтобы лучше объяснить факторы безопасности кроссчейна, мы используем диаграмму архитектуры Ethereum, разработанную Enterprise Ethereum Alliance, как показано на рисунке №01:
Рисунок №01: Архитектура Ethereum с компонентами кроссчейн совместимости
2.1. Уровень блокчейна
Кроссчейн-операция должна правильно обнаружить и идентифицировать исходный и целевой блокчейны. Сегодняшняя идентификация блокчейна с помощью ChainID не является адекватной, поскольку любой блокчейн может присвоить себе идентификатор блокчейна, чтобы имитировать другой блокчейн. Должен существовать механизм аутентификации блокчейна через блокчейн или данные блокчейна, которые невозможно изменить. Один из способов сделать это — использовать genesis blockchain hash в качестве идентификатора блокчейна. Как только пользователь указывает в транзакции исходный блокчейн и целевой блокчейн, ретрансляторы и dapps могут проверить идентификатор блокчейна по хэшу genesis blockchain. В случае форка блокчейна, основной чейн и его форк должны быть проверены, и форк может взять хэш блокчейна блока, когда произошёл форк.
Чтобы обеспечить безопасность уровня блокчейна для кроссчейн-операции, должен быть определён уникальный идентификатор блокчейна. Идентификатор блокчейна должен быть проверяемым внутри блокчейна, идентификатор блокчейна также может быть зарегистрирован в доверенном источнике для включения дополнительных метаданных, связанных с блокчейном [Menaskop: на мой взгляд это нарушает саму природу блокчейна, который, как отмечено выше, работает в строго НЕдоверенной среде].
Помимо использования собственного блокчейна для идентификации блокчейна, идентификатор блокчейна может быть расширен и включать контрольную сумму и другие важные метаданные для описания блокчейна. Другие дополнительные метаданные могут быть зарегистрированы в службе имён, например, в регистрационном органе Ethereum. Такие организации, как Enterprise Ethereum Alliance, могут взять на себя роль помощника в обеспечении того, чтобы идентификация, описание, обнаружение и регистрация блокчейна соответствовали спецификации для кроссчейн операций [Menaskop: что опять же нарушает всю суть блокчейна].
Сегодня существуют блокчейны, такие как Ethereum, которые имеют открытый процесс разработки протокола, в котором участвуют многочисленные заинтересованные стороны, проводящие консультации и достигающие консенсуса относительно предстоящих изменений протокола. В отличие от них, другие протоколы блокчейна могут контролироваться одной организацией, что даёт этой стороне большой контроль над средствами пользователей, их токенами и смарт-контрактами, которые они могут развёртывать и выполнять. Это создаёт единую точку отказа и повышает риск неблагоприятных исходов в операциях с перекрёстными чейнами.
Кроме того, необходимо обратить внимание на программное обеспечение узла, на котором работает сеть блокчейн. Если существует несколько реализаций узлового клиента блокчейна, которые разрабатываются и выпускаются разными группами программистов, с использованием различных языков программирования и системных библиотек, и их использование равномерно распределено между майнерами и/или валидаторами по всему миру, то сбой в работе любого одного узлового клиента с меньшей вероятностью повлияет на другие клиенты. В результате вся сеть становится более устойчивой к атакам и серьёзным сбоям в работе одного клиента. Кроссчейн-мосты могут использовать несколько клиентов, чтобы гарантировать, что операции не будут прерваны в случае проблем с программным обеспечением узла.
2.2 Уровень консенсуса
Когда строится кроссчейн-мост для исходной и целевой цепей, необходимо учитывать безопасность консенсуса в соответствующей родной цепи. К факторам безопасности относятся: кто работает майнерами в родных цепях, какой алгоритм консенсуса используется для блокчейн, какую окончательность обеспечивает алгоритм консенсуса, учитывая конфигурацию, и каковы риски откатов и развилок блокчейна.
В некоторых блокчейнах, частные или консорциумных [Menaskop: как не раз писал — это уже не блокчейны], узлы-валидаторы, добывающие блоки, проходят проверку и пользуются доверием, поэтому вероятность злонамеренных действий со стороны валидаторов меньше. В публичных блокчейнах майнерские узлы не имеют прав доступа, а безопасность гарантируется посредством доказательства работы (PoW) или доказательства доли (PoS). Важно отметить, что при консенсусе PoW вредоносные узлы, обладающие большой мощностью хэширования, могут добывать блоки быстрее, чем честные узлы, и, следовательно, могут обогнать блокчейн. Это крайне маловероятно для Ethereum Mainnet, но может произойти для блокчейнов PoW, которые имеют более низкий хэшрейт. Это создаёт риск для кроссчейн операций, поскольку актив, заблокированный в исходной цепи, может оказаться на неправильном форке и его придётся откатить. А при откате транзакции — соответствующий актив, который был переведен на целевой блокчейн, может быть уже потрачен. Разумно предположить, что как только в исходной или целевой цепочке будет обнаружена проблема безопасности, кросс-транзакции, скорее всего, не будут восстановлены, и потребуется запустить процедуру компенсации потерь.
Ещё одним фактором риска является окончательность исходного блокчейна.
Транзакция является окончательной, когда блок, содержащий транзакцию, не может быть изменён. Во многих кроссчейн-протоколах при выполнении транзакции в исходном блокчейне регистрируется событие, которое используется для запуска соответствующей транзакции в целевой цепи. Для ретранслятора, который передаёт событие на цепочку источника, важно, чтобы транзакция на цепочке источника была завершена. Для большинства публичных блокчейнов окончательность блокчейна носит вероятностный характер. То есть, это не фиксированное количество блоков. Важно определить разумное количество подтверждений блоков, чтобы обеспечить баланс безопасности и производительности. В идеале алгоритм консенсуса должен поддерживать окончательность одного блока (финализация). Это наилучшая характеристика для поддержки кросс-работы. Однако существующие блокчейны, такие как Ethereum и Bitcoin, требуют нескольких подтвержденных блоков для завершения транзакции. Это фактор, который необходимо учитывать при анализе безопасности кроссчейна.
2.3 Кроссчейн-релейщики
Кроссчейн-ретрансляторы переносят активы, сообщения, события и команды от исходного блокчейна к целевому блокчейну. Это offchain операция, поэтому обеспечить безопасность очень сложно. Ретрансляторы могут быть разрешёнными или неразрешёнными. Для ретрансляторов, имеющих разрешение, существует смарт-контракт управления для администрирования регистрации ретрансляторов. Смарт-контракты регистрации ретрансляторов управляются несколькими администраторами с механизмом голосования для одобрения или отклонения ретрансляторов. Для ретрансляторов без разрешения (также известных как открытые ретрансляторы) любой узел кроссчейна может быть зарегистрирован в качестве ретранслятора смарт-контрактом открытой регистрации при условии соблюдения определённых критериев, таких как минимальные системные требования и критерии размещения активов. Релейщикам, не имеющим разрешения, необходимо внести активы в управляющий смарт-контракт в качестве гарантийного депозита для предотвращения неправомерных действий. В смарт-контрактах реализован механизм ресайклинга (базовой очистки) для наказания ретрансляторов, манипулирующих межцепочечными транзакциями и доказательствами.
Безопасность авторизованных ретрансляторов регулируется честностью и правдивостью администраторов ретрансляторов. При первом развёртывании смарт-контракта регистрации ретранслятора существует один владелец смарт-контракта. Затем владелец добавляет дополнительных администраторов на основе политики управления кросс-операциями, превращаясь из одного владельца в группу владельцев. Затем администраторы группы могут использовать механизм голосования, закодированный в смарт-контракте, для добавления ретрансляторов и дополнительных администраторов. Такая модель ретранслятора лучше всего подходит для консорциума, где управление кросс-операциями осуществляется коллективно, группа администраторов выступает в качестве совета директоров, а ретрансляторы проверяются и утверждаются для передачи кросс-транзакций, событий и команд.
Безопасность ретрансляторов, не имеющих разрешения, обеспечивается за счёт стейкинга активов, случайности и специальных вычислений. Стейкинг позволяет узлу ретранслятора без права доступа нести ответственность за любой ущерб, нанесённый в результате злонамеренного манипулирования транзакциями кросс-цепи. Узлы-ретрансляторы также могут быть выбраны случайным образом из пула кандидатов в ретрансляторы для формирования группы многосторонних вычислений (MPC), которая не полагается на один видимый закрытый ключ. Вместо этого она может потребовать, чтобы пороговое число ретрансляторов подписало сообщение вместе для авторизации кросс-транзакции. Чем выше порог группы MPC, тем меньше вероятность сговора группы ретрансляторов. Следует отметить, что хотя более высокие пороги подписания усиливают безопасность, существует побочный эффект — больше ограничений для членов MPC, и, следовательно, это снижает доступность системы [Menaskop: опять же — это одно из следствий трилеммы блокчейна].
2.4 Уровень смарт-контрактов
Как и при децентрализации, для обеспечения безопасности смарт-контракта кроссчейн владельцу смарт-контракта необходимо сохранить его закрытый ключ с помощью аппаратного модуля безопасности (HSM), системы управления ключами (KMS), аппаратного кошелька, автономного кошелька или технологии безопасного хранилища. В качестве альтернативы, совместное владение может быть установлено, если контракт принадлежит кошельку с несколькими подписями. Владелец смарт-контракта может также денонсировать право собственности на смарт-контракт, чтобы смарт-контракт не мог быть изменён. Однако эта модель имеет тот недостаток, что без дополнительных механизмов и гарантий система не может справиться с чрезвычайными ситуациями, такими как ошибки кода или внешние нарушения безопасности, и её необходимо (вновь) разворачивать для восстановления после таких проблем.
2.5 Безопасность уровня Oracle
Уровень Oracle является внешним по отношению к исходной цепочке, целевой цепочке и ретрансляторам, и не управляется операционной группой кросс-цепочки. Важно выбрать надёжную службу оракула. В настоящее время спецификация функциональной совместимости crosschain не охватывает службу Oracle, и мы рекомендуем следовать лучшим практикам и процедурам безопасности в отношении использования сторонних служб.
2.6 Веб-сервисы
Хотя блокчейн имеет более высокую степень децентрализации и безопасности по сравнению с традиционными ИТ-системами, большинство dapps имеют слой веб-сервисов, которые агрегируют действия пользователей и преобразуют их в исходные данные транзакций блокчейна. Этот веб-сервис является централизованным, поэтому следует соблюдать все соображения безопасности для него. Было бы хорошо выделить хранение закрытых ключей и подписание транзакций от любых веб-сервисов.
2.7 Учётная запись администратора
При развёртывании смарт-контракта необходим администратор, который отправляет транзакцию развёртывания в блокчейн. Чтобы подписать транзакцию, администратору необходимо разблокировать учётную запись с помощью закрытого ключа. Если аккаунт разблокирован на узле блокчейна, его закрытый ключ открыт и может быть украден злоумышленником. Подобные взломы неоднократно происходили в криптовалютном мире. Существуют более безопасные способы развёртывания смарт-контрактов. Например, администраторы могут использовать аппаратный кошелек или использовать автономный кошелек для развертывания. В обоих случаях закрытые ключи хранятся на отдельных устройствах, и только подписанные транзакции копируются в онлайн-систему для отправки в блокчейн. В этом случае закрытый ключ защищен от сетевых атак, поскольку он никогда не покидает специального устройства. Однако физические атаки и взлом устройств всё же следует учитывать.
2.8 Защита учётных записей управления с помощью MPC
Существует два вида учётных записей, которые можно использовать для управления смарт-контрактами, токенами и мостами:
- Учётная запись внешнего владельца;
- Учётная запись контракта.
Учётная запись владельца смарт-контракта является наиболее важной учётной записью, поскольку именно эта сторона разворачивает смарт-контракты и имеет право обновлять, останавливать, передавать или отключать смарт-контракт. Учётная запись владельца также может отказаться от права собственности и, следовательно, сделать смарт-контракт самостоятельным.
Использование выделенных административных учётных записей может обеспечить дополнительную учётную запись для управления операциями смарт-контракта.
Учётная запись администратора может устанавливать параметры смарт-контракта, а также изменять состояние смарт-контракта. Для повышения безопасности административных аккаунтов было бы неплохо использовать MPC (многосторонние вычисления) для защиты закрытого ключа такого совместного аккаунта. Принцип работы MPC заключается в разделении закрытого ключа на несколько сегментов, и у каждого человека есть своя часть закрытого ключа. При подписании транзакции определённая часть узлов MPC должна подписать транзакции индивидуально и отправить подпись группе MPC. Метод MPC обеспечивает возможность коллективного подписания транзакций и, следовательно — повышает безопасность кроссчейн обмена.
2.9 Закрепление и разрубание
Для мостов, которые действительно децентрализованы и не имеют (доверенных) разрешений, безопасность криптоактивов должна быть обеспечена активами, размещёнными узлами моста, чтобы гарантировать отсутствие сговора между ними, а любые неправомерные действия операторов моста — пресекаются с помощью размещённой ликвидности (ставок). Подобно модели консенсуса блокчейна PoS (proof of stake) такой подход может помочь службе регистрации кроссчейна ранжировать и отбирать операторов для осуществления кроссчейн-транзакций.
Стейкинг (моста) также может помочь обеспечить безопасность сети кроссчейн, чтобы предотвратить неправомерные действия в операциях кроссчейн-сервиса. Как правило, сокращениеактивов может происходить по двум сценариям: первый — в случае бездействия, второй — при подписании мошеннических транзакций. В случае бездействия узел моста может находиться в нерабочем состоянии, или неправильно настроен, или просто выключен. В случае подписания мошеннических транзакций, мостовые группы и смарт-контракт имеют возможность проверять транзакции от разных мостовых узлов и сообщать о неправильно подписанных транзакциях административному смарт-контракту для слешинга.
Кроссчейн-стейкинг может быть осуществлён путём реализации смарт-контрактов на блокчейне с функцией стейкинга (stake_deposit()), принимающей на вход функции: blockchain_id, account_address, amount, bridge_id, duration и подписи для финансирования моста:
- blockchain_id представляет блокчейн;
- account_address — адрес счёта EOA (Externally Owned Account), с которого будут сняты или заблокированы средства для поддержки моста для обработки кросс-транзакций;
- amount указывает сумму актива, которая будет внесена;
- bridge_id представляет мост, для которого будет внесён обеспечительный фонд;
- duration — период времени, в течение которого актив будет заблокирован на счёте;
- signature — подписанное сообщение от владельца счёта для повышения подлинности запроса на ставку.
Чтобы гарантировать, что обеспечительный актив может быть использован для компенсации потерь в результате кроссчейн сговора, должно существовать ограничение, т.е. мощность моста, на максимальное количество активов, которые могут быть переданы через блокчейн. Ёмкость моста может представлять собой сумму всех обеспечительных активов, внесённых на мост. Если общая стоимость кросс-активов превышает ёмкость моста, мост перестаёт быть полностью защищённым, поскольку у узлов моста возрастает стимул к получению прибыли от сговора.