Автор — Серхио Демиан Лернер, главный разработчик инноваций в RSK

Соединение блокчейнов с помощью полностью децентрализованного и надежного канала является своеобразным Святым Граалем для исследователей блокчейна. Еще в 2016 году в IOV Labs мы создали первый надежный интегрированный мост, который поддерживал привязку 1:1 между RSK и Биткойн в течение 3 лет. Сейчас мы работаем над полностью децентрализованным мостом между RSK и Ethereum. В данном сообщении мы представляем техническое описание нового моста и базового децентрализованного протокола, который его поддерживает.

Введение

Чтобы разобраться в перемещении токенов между блокчейнами, давайте для начала рассмотрим определенные часто используемые термины и историю их создания. Термин двусторонняя привязка (или 1:1) относится к системе, которая старается сделать два токена из двух разных блокчейнов экономически эквивалентными. Когда спрос на одной стороне увеличивается, двухсторонняя привязка должна давать возможность токенам поступать с другой стороны, чтобы поддерживать единообразие цены. В 2013 году, еще до разработки такой системы, была разработана концепция, при которой Биткойн мог иметь несколько спутниковых сайдчейнов, соединенных с основной цепочкой с помощью двусторонней привязки. Сайдчейн создавался как отдельный блокчейн, имеющий собственные иностранные активы, поэтому комиссионные за транзакции выплачивались с помощью такого иностранного актива. При отсутствии внутреннего выпуска монет выплаты майнерам сайдчейна не проводятся. Однако из-за отсутствия проверенной структуры двухсторонней привязки термин сайдчейн оставался неопределенным. В 2014 году в Blockstream попробовали разработать решение на основе UTXO без сохранения состояния. Проект был реализован с помощью исходной кодовой базы сайдчейна Elements, но позже этот подход не использовался из-за проблем безопасности и наличия цензуры, и Elements перешел на федеративную привязку и стал сайдчейном Liquid. Таким образом, термин «сайдчейн» не определяет фактическую систему связи, которая выполняет передачу активов с поддержкой привязки 1:1. С появлением многокомпонентных блокчейнов система взаимодействия, используемая для управления двусторонней привязки, стала токен-мостом. Токен-мост может соединять два произвольных блокчейна, где ни один из них не является сайдчейном другого. Существуют определенные криптоэкономические различия между токен-мостом, который соединяет независимые блокчейны, и мостом для сайдчейна, поддерживающим доступность независимой монеты, которую можно использовать в качестве залога и обрабатывать при неправильном поведении, но мы не будем рассматривать такие различия в этой статье.

Первый готовый к работе токен-мост был развернут в сайдчейне RSK, запущенном в 2017 году. Мост RSK является гибридным: направление Биткойн — RSK полностью опирается на SPV, что означает обеспечение нужной степени устойчивости к децентрализации и цензуре, а направление RSK — Биткойн является федеративным. Поскольку Биткойн не может проверить консенсус RSK, невозможно использовать децентрализованное и устойчивое к цензуре решение для передачи биткойнов из RSK в Биткойн, поскольку невозможна полнодуплексная реализация. Однако текущая привязка между RSK и Биткойн, показанная на следующей диаграмме, является одним из лучших возможных решений.

Двухсторонняя гибридная федеративная привязка RSK с поддержкой SPV

Мост RSK — Биткойн еще ни разу не был взломан и имеет рекордное время работы 100%. Он использует автономные аппаратные модули системы безопасности (HSM) для защиты закрытых ключей крупной системы с мультиподписью. Модули HSM постепенно развивались, и новое поколение HSM в RSK синхронизировалось с лучшей цепочкой, проверяя доказательства выполнения работы. В результате даже большинство должностных лиц Федерации не имеют возможности подменить или подвергнуть цензуре привязанные транзакции. Однако федеративный мост имеет свои недостатки: он по-прежнему опирается на небольшой набор объектов, которым необходимо поддерживать нужное состояние и подключение HSM к сети, и при этом он полагается на честность компаний, поддерживающих HSM, чтобы не вводить тайные каналы, смещенные генераторы случайных чисел или программные закладки. В новом мире децентрализованных протоколов федеративные мосты должны существовать только до тех пор, пока не будут созданы более эффективные децентрализованные системы для их замены. По-настоящему безопасный децентрализованный мост между двумя блокчейнами должен опираться на оба блокчейна, в краткой форме проверяя консенсус каждого из них. 

Построение токен-моста с помощью клиентов SPV

Клиент SPV — это упрощенная система, которая принимает краткие подтверждения совокупного доказательства выполнения работы, чтобы выяснить, какой из блокчейнов обладает высокой криптоэкономической безопасностью и является лучшим из множества возможных кандидатов. Клиенты SPV идеально подходят для построения моста на основе смарт-контрактов между двумя блокчейнами, основанными на доказательстве выполнения работы. Однако в работе стандартных клиентов SPV присутствует множество ограничений, особенно для блокчейнов с высокой скоростью блоков. RSK поддерживает высокую скорость блоков (примерно один блок раз в 30 секунд), но в этом случае полная проверка только по заголовкам между блокчейнами становится достаточно дорогой, как с точки зрения необходимых ресурсов, так и времени проверки. В этом отношении ситуация в Ethereum еще хуже из-за более высокой скорости блоков и более сложной проверки доказательства выполнения работы. На следующей диаграмме показан гипотетический децентрализованный мост, основанный на согласованной проверке только заголовков блокчейнов. Каждый блокчейн поддерживает представление лучшей цепочки другого блокчейна в режиме SPV.

Гипотетический мост SPV с отслеживанием состояния

Еще в 2015 году было широко известно, как создавать короткие доказательства упрощенного подтверждения платежей (SPV) на основе интерактивных «запросов-ответов» в заголовке блока. Эту операцию можно превратить в неинтерактивную, используя преобразование Фиата-Шамира (то, что в последнее время называют неинтерактивными доказательствами выполнения работы или NiPoPoWs). Идея состоит в том, что проверяющий принимает решения для блокчейна, а претендент запрашивает у него раскрываемое количество заголовков блоков и информацию о том, что обнаруженный блок принадлежит тому же подключенному блокчейну. Однако до 2017 года не было известно, как создавать доказательства для блокчейна с переменной сложностью. В 2017 году появился протокол FlyClient, который наконец решил эту проблему. FlyClient позволяет настроить функцию выбора индекса блока с учетом изменения сложности. Кроме того, протокол FlyClient можно настроить на разные размеры доказательств, создавая разные границы вероятности мошенничества в зависимости от потребности клиента в безопасности.

Неинтерактивный протокол FlyClient (упрощенный)

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

В 2019 году мы начали поиски вариантов соединения RSK и Ethereum. Мы исследовали варианты включения FlyClient в Ethereum без каких-либо изменений в его консенсусе и обнаружили метод, который расширяет возможности FlyClient, но при этом использует краткие доказательства. Со временем это открытие переросло в протокол HawkClient, относящийся к новой категории протоколов, которые мы называем криптоэкономическим интерактивным доказательством для доказательства выполнения работы (CIPoPoW). Протокол HawkClient работает для всех платформ смарт-контрактов на основе EVM, таких как RSK, Ethereum и Ethereum-Classic. Конечно, если блокчейн действительно реализует обязательства дерева MMR, это сильно упрощает протокол. 

Описание HawkClient

Проще говоря, HawkClient — это интерактивная децентрализованная система смарт-контрактов для поддержки в одном «главном» блокчейне их синхронизации с чужим «удаленным» блокчейном, что позволяет передавать информацию, имеющую явную денежную ценность. Две системы HawkClient, реализованные зеркальным образом между двумя блокчейнами, создают основу для децентрализованного токен-моста, позволяющего передавать токены из одного блокчейна в другой.

Токен-мост на основе двух зеркальных систем HawkClient

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

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

Верификатор — это смарт-контракт, реализованный в блокчейне хоста, который проверяет доказательства HawkClient и использует их для расширения и поддержки представления удаленного блокчейна. Верификатор похож на SPV-узел блокчейна, но работает на основе консенсуса. По сути, именно этим занимается RSK и модель btcrelay. Верификатор позволит другим проверяющим оспорить доказательство или представить альтернативные доказательства в течение контрольного периода, а затем он принимает доказательство с наивысшим совокупным доказательством выполнения работы. Однако, отклоняясь от модели btcrelay, верификатор самостоятельно выполняет протокол запрос-ответ вместе с проверяющим, что сдерживает стандартные атаки на основе цензуры транзакций. Пользователи взаимодействуют как с хостом, так и с удаленными блокчейнами, и такое взаимодействие генерирует события в удаленном блокчейне, которые записываются в отчете. Позже проверяющий сообщает об этих событиях блокчейну хоста. Смарт-контракты на блокчейне хоста могут проверять информированные события и взаимодействовать с ними. 

Мост RSK — Ethereum

Мост RSK-ETH соединяет RSK с Ethereum и позволяет передавать между двумя блокчейнами любые токены ERC-20. Развитием этого моста занимается IOV Labs. Мост основан на протоколе HawkClients. Кроме того, этот мост обладает уникальным набором функций. Например, он позволяет проверяющему выбрать денежную сумму сертификата обеспечения, который он готов предложить в обмен на разрешение предоставить подтверждение определенного размера. Это гарантирует, что мошенничество всегда будет являться проигрышной стратегией. Например, проверяющий может предложить ответить на большее количество запросов, выполняемых верификатором, что уменьшает сертификат обеспечения, но увеличивает размер доказательства. Если плата за транзакцию высока, проверяющий может увеличить сертификат обеспечения, чтобы уменьшить размер доказательства и комиссию за транзакцию. Поскольку при обнаружении мошенничества связь обрывается, мошенничество никогда не станет рациональной стратегией, что гарантирует криптоэкономическую безопасность. Кроме того, HawkClient заставляет выполнять обязательства внутри блокчейна, а запросы — на основе следующих хэшей блоков, поэтому злоумышленник не может выполнить миллионы различных обязательств в автономном режиме. Предполагая, что злоумышленник контролирует менее 50% скорости хэширования в любом из задействованных блокчейнов, он сможет выполнить только одно обязательство. Другими словами, поскольку система является интерактивной, злоумышленник не может перевести обязательство в автономный режим, чтобы получить благоприятный запрос. Например, если мы устанавливаем ограничение вероятности обмана на уровне 1 из миллиона, мы создаем сложнейшее препятствие для любой попытки мошенничества. То есть, вероятность мошенничества, которая обычно отрицательно сказывается на криптографической безопасности, в результате дает чрезвычайно высокую криптоэкономическую безопасность. Наконец, мост использует специальный упрощенный рынок токенов, который служит оракулом для определения верхней границы текущих цен на токены, связанные с собственной монетой. Этот рынок действует с большими задержками (порядка нескольких недель) как для покупки, так и для продажи, и мы не ожидаем, что он будет использоваться для какой-либо реальной сделки, если только одна из сторон не попытается обмануть цены токенов. Используя такую систему взаимодействия, мы можем создавать сертификаты обеспечения в национальной валюте вместо токенов, и мы можем включить несколько проверяющих, не требуя, чтобы каждый из них вносил все возможные токены.

Система HawkClient для передачи информации из Ethereum в RSK

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

Ключевые характеристики доказательства HawkClient

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

Интерактивные доказательства

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

Криптоэкономические доказательства

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

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

Блокчейн	Стоимость (USD)
Биткойн	12M
Ethereum	1.1M
RSK	6M

Поскольку цены на криптовалюту часто меняются, параметры работы моста должны обеспечивать достаточно большой запас безопасности. Например, стоимость, которую мост RSK-ETH может передавать в сутки из Ethereum в RSK, будет ограничена на уровне 600 тыс. USD, а в обратном направлении — 3 млн. USD. 

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

Ступенчатые доказательства

В протоколах смарт-контрактов существуют две крайние ситуации, при которых проверяются внешние входы данных. С одной стороны, существуют «ленивые» или «оптимистичные» протоколы, безопасность которых полностью зависит от доступности и защиты от цензуры на уровне внутри блокчейна. В оптимистичных протоколах проверяющий подтверждает утверждение, а уровень смарт-контракта ожидает проверки этого утверждения с помощью защиты от мошенничества. Они работают в соответствии с шаблоном «подтверждение-запрос». Если утверждение не оспаривается в течение определенного фиксированного периода, то оно считается верным. Такая система считается «ленивой», потому что смарт-контракт сам не выполняет никакой проверки. Эта модель была принята в TrueBit, а позднее в Arbitrum. С другой стороны, некоторые «сильные» протоколы проверяют каждое внешнее утверждение, и у них нет необходимости в запросах, хотя в некоторых случаях они используют строгие доказательства целостности вычислений, такие как zk-SNARK. Обратной стороной «ленивых» протоколов является стимулирование цензуры транзакций и сговоров майнеров. «Ленивые» протоколы могут обеспечивать криптоэкономическую безопасность, если есть возможность оценить стоимость атаки на основе цензуры транзакций. Но это непростая задача, поскольку цензура обходится дешево, но ее трудно доказать и невозможно отнести к конкретному майнеру. Хотя майнеры ставят под угрозу свою репутацию, это трудно оценить внешнему наблюдателю. 

Единственный недостаток «сильных» протоколов состоит в том, что они дороги с точки зрения использования ресурсов (газа), и эту стоимость необходимо каким-то образом распределить между пользователями протокола. Посередине между ними стоят ступенчатые протоколы. Ступенчатые протоколы начинаются с утверждения, после которого проверяемый контракт выполняет определенную форму вероятностной проверки, чтобы получить начальную степень уверенности. После этого другие пользователи могут либо оспорить доказательство, попросить верификатора запросить более высокую достоверность, предоставить другое конкурирующее доказательство или подождать, пока доказательство не будет принято. Когда первое доказательство оспаривается с помощью второго конкурирующего доказательства, первый проверяющий имеет возможность использовать большее совокупное доказательство работы, чтобы выиграть и стать лучшей цепочкой. Дополнительные доказательства могут выставляться до тех пор, пока один из проверяющих не сдастся, не имея возможности продемонстрировать большее совокупное доказательство работы. Последнее неоспоримое доказательство выбирается в качестве лучшей цепочки.

Оптимистичный, сильный и ступенчатый подходы в FlyClient

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

Постоянные спорадические обязательства MMR

Если удаленный блокчейн изначально не поддерживает FlyClient, HawkClient может искать обязательства MMR в хранилище фиксированного смарт-контракта, так называемого средства обновления AMMR. Этот контракт использует код операции BLOCKHASH для сбора прошлых хэшей блоков и построения актуального дерева. AMMR расшифровывается как приблизительный пиковый диапазон Меркла. Это дерево содержит границы реальных значений совокупной сложности и времени. Обязательства AMMR не требуется обновлять в каждом блоке. Мы предполагаем, что они обновляются в среднем через каждые N блоков с помощью внешних запросов к контракту средства обновления AMMR. Если через каждые N блоков время блока останется точным (время блока можно получить с помощью кода операции BLOCKTIME), то время для промежуточных блоков остается неизвестным в рамках контракта. В контракте Ethereum, где не используется точная совокупная сложность, такого кода операции нет. Поэтому при вызове средства обновления AMMR необходимо вычислить границу совокупной сложности. Протокол гарантирует, что совокупная сложность всегда будет находиться в пределах окна процентных ошибок. Наличие границы ошибки оправдано, поскольку сложность блока не может слишком сильно различаться от одного обновления AMMR к другому. Давайте рассмотрим сеть Ethereum, где сложность блоков может меняться в пределах +-1/2048. Принятие обновлений AMMR на максимальном расстоянии в 256 блоков подразумевает, что сложность блока может увеличиваться или уменьшаться на уровне до 6,65% (в точке максимума/минимума, возле блока 128). Однако в последнем блоке необходимо достичь реальной сложности блока, потому что средство обновления AMMR проверяет этот параметр, используя код операции DIFFICULTY. Поэтому средство обновления AMMR может вычислять границы совокупной сложности для текущего блока. В худшем случае, если в предыдущих 256 блоках не было обновлений и сложность блоков не изменилась по сравнению с последним обновлением, эта граница представляет собой увеличение или уменьшение до 3,2% от реальной совокупной сложности блокчейна. Поэтому даже если реальная сложность скрыта смарт-контрактом, он практически следует за реальной сложностью. Кроме того, чтобы незаметно изменить сложность на 3,2%, злоумышленник должен добыть 256 блоков или избежать получения запросов на заголовки 256 блоков.

Поскольку дерево AMMR не хранит точные значения совокупной сложности при представлении доказательств, содержащих много обновлений AMMR, границы совокупной сложности для последовательных блоков будут перекрываться. Это означает, что если злоумышленнику будет предложен запрос на индексирование блока с определенной совокупной сложностью x, он может использовать эту неоднозначность, чтобы выбрать один из нескольких смежных блоков, границы сложности которых включают x. Поэтому злоумышленник может добывать только один блок на каждый непересекающийся интервал, уменьшая необходимый ему объем работы. Чтобы предотвратить эту атаку, проверяющий также должен зафиксировать второе дерево Меркла, точный пиковый диапазон Меркла (EMMR), содержащий точные данные о совокупной сложности и времени для каждого блока. На каждом промежуточном узле это дерево дополняется данными о совокупной сложности и совокупном времени. Исходная функция и проверки, выполняемые на узлах AMMR, теперь разделены между этими двумя деревьями. Для каждого запроса проверяющий должен продемонстрировать ветвь AMMR и ветвь EMMR. Для определения местоположения номера блока с определенными совокупными обязательствами используется ветвь EMMR, а затем просматривается дерево AMMR в поисках этого номера блока. При этом все границы совокупной сложности и сложности по времени перепроверяются. На следующей схеме показан гипотетический блокчейн, начинающийся с совокупной сложности 0, где сложность каждого блока является постоянной и равна 10. По общему мнению, сложность может увеличиваться или уменьшаться на 10% в каждом блоке. После 8 блоков реальная совокупная сложность (80) отклоняется от минимального и максимального уровней, которые могли бы быть достигнуты без знания фактической сложности каждого промежуточного блока. При этом известна только сложность последнего блока. Каждое зеленое поле показывает минимальную и максимальную совокупную сложность. Во время проверки доказательства для определения местоположения блоков используется дерево EMMR, а затем проводится поиск по номеру блока в дереве AMMR. На каждом шаге проводится проверка того, содержится ли точный диапазон в ограниченном диапазоне.

Точный и приблизительный пиковый диапазон Меркла

Все системы, которые взаимодействуют с HawkClient, должны знать адрес контракта для средства обновления AMMR. Любой может проверить развернутый код, проверив транзакцию, которая создает контракт для средства обновления AMMR. Однако остаются неявные атаки. Создатели средства обновления AMMR могут создать аналогичный контракт с тем же адресом в другом блокчейне, использующий ту же структуру заголовка блока и то же доказательство работы, но который ранее был разветвлен. В этом блокчейне контракт может быть развернут с другим байт-кодом ВМ. Чтобы предотвратить такую атаку, контракт средства обновления MMR должен быть развернут с помощью CREATE2 и использовать код операции CHAINID (EIP-1344), чтобы убедиться, что он работает на целевой платформе и прервать создание блока, если это не так. Такой код операции используется в Ethereum со времен хард-форка Стамбул.

Краткие выводы

В IOV Labs мы занимаемся созданием децентрализованного моста, который может соединять основные блокчейны с доказательством выполнения работы. Ядром этого моста стал протокол HawkClient, который является расширением FlyClient. Но в работе FlyClient и HawkClient существует несколько отличий. В HawkClient 

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

Две зеркальные системы HawkClient между двумя блокчейнами являются основой для создания моста RSK-ETH. В настоящее время мост находится в стадии разработки, и вскоре мы объявим дату его развертывания в тестовой сети RSK, а также выпустим исходный код и предоставим всю информацию о том, как его использовать для кошельков и смарт-контрактов. Мы очень рады работать над первым по-настоящему децентрализованным криптоэкономическим мостом, и надеемся, что мост RSK-ETH станет первым шагом в создании магистральной линии связи для всех блокчейнов, сделав все EVM-совместимые токены блокчейнов доступными для приложений DeFi на основе Биткойн с помощью RSK.