Авторы:
(1) Дэниел Рейсберген, Наньянский технологический университет, Сингапур, Сингапур;
(2) Аунг Мау, Сингапурский университет технологий и дизайна, Сингапур, Сингапур;
(3) Цзинчи Чжан, Наньянский технологический университет, Сингапур, Сингапур;
(4) Тьен Туан Ань Динь, Университет Дикина, Мельбурн, Австралия;
(5) Анвитаман Датта, Наньянский технологический университет, Сингапур, Сингапур.
Аннотация и введение
Обзор PIEchain
Внедрение PIEchain
Демонстрационный план
Расширения
Рекомендации
В последние годы появилось множество различных блокчейн-платформ, но многие из них работают изолированно. Таким образом, существует потребность в надежной межцепочной связи для обеспечения совместимости блокчейнов. Функциональная совместимость блокчейна является сложной задачей, поскольку транзакции, как правило, не могут быть отменены — поэтому, если одна транзакция зафиксирована, протокол должен гарантировать, что все связанные транзакции также будут зафиксированы. Существующие подходы к взаимодействию, например Cosmos и Polkadot, ограничены в том смысле, что они поддерживают взаимодействие только между своими собственными подцепями или требуют вторжения в существующие блокчейны. Чтобы преодолеть это ограничение, мы предлагаем PIECHAIN, общую структуру межсетевых коммуникаций на основе Kafka. Мы используем PIECHAIN для практического исследования: межсетевой аукцион, на котором пользователи, владеющие токенами в нескольких цепочках, делают ставки на билет, проданный в другой цепочке. PIECHAIN — это первая общедоступная практическая реализация общей структуры межсетевого взаимодействия.
Блокчейн — это реплицируемая, защищенная от несанкционированного доступа база данных, предназначенная для работы в агрессивных средах. Он состоит из ряда узлов, некоторые из которых могут быть вредоносными, которые поддерживают реестр, предназначенный только для добавления. В реестре хранятся транзакции, которые изменяют некоторые глобальные состояния. В каноническом примере, то есть криптовалютах [7], глобальными состояниями являются учетные записи пользователей и собственные (взаимозаменяемые) токены, а реестр содержит транзакции, передающие токены с одной учетной записи на другую. В другом новом приложении блокчейны хранят невзаимозаменяемые токены (NFT), уникально представляющие активы, например, произведения цифрового искусства или билеты на концерты. Многие блокчейны также поддерживают смарт-контракты, позволяющие пользователям определять свои собственные состояния и коды, которые изменяют состояния. Смарт-контракты хранятся в реестре, тиражируются и поддерживаются согласованными всеми узлами блокчейна. В последние годы появилось множество независимых блокчейн-платформ, в результате чего образовалась экосистема с длинным хвостом. С одной стороны, существует небольшое количество чрезвычайно популярных платформ блокчейна общего назначения, таких как Ethereum и Hyperledger. С другой стороны, существуют тысячи более мелких блокчейнов, предназначенных для конкретных приложений, большинство из которых находятся только на ранних стадиях разработки. Сюда входят более 10 000 криптовалют [3] по состоянию на начало 2023 года, а также блокчейны для здравоохранения, управления идентификацией и Интернета вещей. В общем, эти блокчейны не взаимодействуют друг с другом, то есть существуют изолированно. Таким образом, совместимость блокчейнов, то есть возможность пользователей обмениваться информацией или активами в разных блокчейнах, является предметом, вызывающим растущий интерес со стороны исследовательского сообщества [6], [10], [4], [1], [ 11].
Одна из основных задач при разработке безопасной структуры взаимодействия блокчейнов — гарантировать атомарность, то есть то, что либо все этапы согласованного набора транзакций завершаются успешно, либо ни один из них не завершается успешно. В блокчейнах это сложнее, чем в традиционных базах данных, поскольку транзакции блокчейна (в принципе) необратимы. Например, если платеж по NFT в цепочке A уже был произведен в цепочке B, то атомарность требует, чтобы транзакция в цепочке A была продолжена, поскольку транзакция в цепочке B не может быть отменена. Один из распространенных подходов к обеспечению атомарности — депонировать все токены, участвующие в сделке, в смарт-контрактах и выпускать их только через сообщение о фиксации, подписанное всеми сторонами [6]. Еще одна важная задача совместимости блокчейнов — гарантировать жизнеспособность, чтобы депонированные токены не могли быть заморожены навсегда. Чтобы обеспечить жизнеспособность, узлы должны иметь возможность отправлять сообщение об отмене, которое позволяет всем сторонам вывести свои активы из условного депонирования.
Чтобы гарантировать как атомарность, так и жизнеспособность, структура взаимодействия должна быть способна выдерживать состязательные узлы, которые отправляют сообщение фиксации в один блокчейн и сообщение об отмене в другой. Для асинхронных сетей (т. е. где нет ограничений на задержки сообщений) известно, что этого невозможно достичь без доверенной третьей стороны (TTP) [10]. Существует два основных подхода к решению этой проблемы [6]. Первый подход заключается в объединении предположения о синхронизации с периодом восстановления для прерываний, т. е. в предположении, что голосование за фиксацию, однажды сгенерированное, может быть добавлено ко всем задействованным блокчейнам до окончания любого периода восстановления для прерываний. Этот подход используется, например, в хешированных контрактах с временной блокировкой [5]. Второй подход заключается в замене TTP другим блокчейном, чтобы гарантировать возможность создания либо действительного сообщения фиксации, либо сообщения об отмене, но не обоих одновременно [6], [9].
Хотя подходы обоих типов были предложены в научной литературе, они либо не имеют общедоступной реализации [5], [6], [9], либо ограничены в сфере применения, например, создание резервных активов на другом блокчейне. [11] или обмен токенами [8]. В рамках отдельной разработки появилось несколько платформ блокчейнов, которые по умолчанию обеспечивают совместимость, например Cosmos и Polkadot. Однако эти платформы поддерживают только взаимодействие между своими собственными подцепями или требуют навязчивых изменений в существующих блокчейнах. Это мотивирует необходимость создания общей и практичной структуры взаимодействия, которую можно было бы взаимодействовать с существующими платформами блокчейна без их модификации. Наша цель – предоставить такую основу.
Вклад и новинки : Мы представляем PIECHAIN для достижения этой цели. Поскольку синхронизацию на практике трудно обеспечить, PIECHAIN использует межсетевые сервисы для замены TTP. Межсетевые сервисы взаимодействуют с помощью журнала событий, который для повышения эффективности использует протокол Apache Kafka. Чтобы продемонстрировать практическую значимость PIECHAIN, мы внедрили кросс-чейн сервис для реалистичного тематического исследования: кросс-чейн аукцион. Мы связали PIECHAIN с некоторыми из самых популярных блокчейн-платформ, поддерживающих смарт-контракты: Ethereum, Hyperledger Fabric и Quorum. Наконец, мы разработали графический интерфейс для нашего тематического исследования. Пример аукциона — один из трех примеров (два аукциона и мгновенный кредит [6]), код которого можно найти в репозитории кода PIEChain на GitHub.
Основными объектами PIECHAIN являются следующие (см. также рисунок 1):
Блокчейны, в которых хранятся активы (например, токены, ключи), принадлежащие пользователям. Пользователь может хранить активы в нескольких блокчейнах. Каждый блокчейн имеет свой собственный протокол для определения того, кто имеет доступ для чтения и записи. Блокчейны обычно либо разрешены, т. е. фиксированный набор узлов имеет доступ для чтения и записи, либо не имеют разрешений, т. е. каждый имеет доступ для чтения и может создавать транзакции, а узлы при достаточной мощности (например, скорости обработки) можно добавлять транзакции в блокчейн. Межсетевые сервисы (CC-SVC), которые позволяют пользователям обмениваться активами в разных блокчейнах. Каждый CC-SVC состоит из сервера, который взаимодействует с пользовательскими клиентами для облегчения межсетевой связи. На практике CC-SVC взимает с пользователей плату за участие и может взаимодействовать с любым количеством блокчейнов. Далее каждый CC-SVC соответствует набору событий, участвующих в атомарном обмене активами, которые отправляются сервером в реестр Kafka. На практике один сервер может управлять множеством CC-SVC.
Сеть Kafka, которая служит журналом событий, генерируемых CC-SVC, только для добавления. События соответствуют транзакциям, совершаемым в базовых блокчейнах. Сеть Kafka управляется фиксированным набором узлов, которые взимают плату CCSVC за загрузку событий.
В PIECHAIN мы предполагаем, что CC-SVC являются полудоверенными и что они мотивированы вести себя честно, имея репутацию, которую нужно поддерживать, подобно коммерческим поставщикам аутсорсинговых услуг. Операторам сети Kafka не доверяют, но у них нет стимула плохо себя вести, поскольку они не взаимодействуют с базовыми блокчейнами. Это позволяет нам запускать протокол (Kafka), в котором эффективность важнее безопасности. Альтернативный вариант — сделать CC-SVC недоверенными, а сеть Kafka — доверенной. В этом случае каждый узел Kafka запускает (легкий) клиент для каждой из базовых цепочек блоков для проверки включения транзакций в эти цепочки. В этом случае журнал событий должен будет использовать более безопасный протокол, такой как PBFT [2]. Такой дизайн оставляем на будущее.
Учитывая сущности раздела II-A, процесс в PIECHAIN имеет ту же структуру, что и сделки между цепочками, как это было предложено Herlihy et al. [6]. Межсетевые сделки — это соглашения нескольких пользователей об обмене активами в разных блокчейнах, которые состоят из пяти этапов (см. также рисунок 2):
Фаза клиринга: CC-SVC создает смарт-контракты на различных блокчейнах, которые используются для депонирования и передачи активов, участвующих в сделке.
Фаза условного депонирования: пользователи депонируют свои исходящие активы, передавая их в смарт-контракты.
Фаза передачи: активы предварительно обмениваются, т.е. уточняется логика выполнения смарт-контрактов.
Фаза проверки: каждый пользователь проверяет, удовлетворит ли его результат логики выполнения.
Фаза принятия решения: сделка заключается посредством обязательства, если все стороны удовлетворены, или путем прерывания в противном случае. Обязательство означает, что логика исполнения в смарт-контрактах выполняется и активы обмениваются в соответствии с условиями сделки. Аборт означает, что активы в каждом смарт-контракте возвращаются их первоначальным владельцам.
Для фиксации пользователи в интерактивном режиме создают голосование за фиксацию, которое CC-SVC отправляет в реестр Kafka. Для прерывания один пользователь отправляет сообщение об отказе в CC-SVC. Для каждого CC-SVC в реестр Kafka можно добавить либо сообщение о фиксации, либо сообщение об отмене, но не то и другое. Доказательство включения голосования за фиксацию в реестре Kafka принимается всеми смарт-контрактами в различных блокчейнах — это гарантирует, что после создания голосования за фиксацию либо все передачи активов могут быть выполнены, либо нет.
Чтобы проиллюстрировать практическую применимость PIECHAIN, мы подключили его к нескольким широко используемым платформам блокчейнов и использовали для реализации приложения из научной литературы [6]: межцепочного аукциона для цифрового актива. Поддержка блокчейна распространяется и на другие тематические исследования, о которых мы поговорим в разделе V.
Чтобы связать базовый блокчейн с PIECHAIN, CC-SVC должны иметь возможность проверять транзакции в этих цепочках. Наша реализация поддерживает следующие блокчейн-платформы: Ethereum (как версии частного Ethereum с доказательством работы, так и с доказательством авторизации), Hyperledger Fabric и Quorum. Последние два поддерживают разрешенные блокчейны, тогда как Ethereum имеет не требующую разрешений основную цепочку, но также поддерживает частные цепочки с той же функциональностью.
В нашем примере аукционист продает актив в одном блокчейне и получает оплату в виде активов в другом блокчейне. Как и в [6], мы используем пример продавца билетов. Билет представляет собой NFT в выделенном блокчейне, тогда как другой блокчейн поддерживает более часто используемые взаимозаменяемые токены (например, Ether). Первый блокчейн называется блокчейном билетов, а второй — блокчейном монет. Это легко обобщить на настройки с более чем одним блокчейном монет. Далее мы рассматриваем аукцион первой цены (т. е. участник, предложивший самую высокую цену, платит свою ставку и получает актив). Пять этапов протокола выглядят следующим образом:
Аукционист привлекает CC-SVC, который создает смарт-контракты в блокчейне билетов и блокчейнах монет.
Аукционист передает свой актив (NFT билета) в контракт на билеты, а участники торгов передают свои ставки в контракт на блокчейне своих монет.
Определяется логика исполнения: аукционист обновляет каждый контракт на билеты и монеты, указывая, какая сторона получает билет и какая ставка передается аукционисту. (Обратите внимание, что эта логика не может быть указана в контракте билета априори, поскольку контракт в цепочке билетов не может считывать данные из блокчейнов монет.)
Каждый пользователь (т. е. аукционист и участники торгов) определяет, устраивает ли его результат протокола передачи, т. е. действительно ли билет передан правильной стороне.
Все пользователи создают голосование за принятие — как только оно создано, оно отправляется в каждый контракт для выполнения передач, указанных на этапе передачи.
В PIECHAIN аукцион требует двух (логических) типов CC-SVC: ретранслятора и подписывающего лица. Ретранслятор прослушивает события (предложения) в цепочках монет и передает их в блокчейн билетов. Подписывающая сторона помогает создать голосование за фиксацию.
Для нашей демонстрации мы разработали графический пользовательский интерфейс (GUI) с использованием платформы React, чтобы проиллюстрировать межсетевой аукцион. Графический интерфейс состоит из трех основных страниц: страницы информационной панели, на которой отображается список известных аукционов, как показано на рисунке 3, подробное представление отдельных аукционов, как показано на рисунке 5, и страница создания новых аукционов (не отображается). Для аукциониста это одно и то же, что и для участников торгов. На панели управления потенциальные аукционисты могут нажать кнопку «Создать новый аукцион», чтобы начать аукцион — аукционист выбирает CC-SVC, актив, который будет выставлен на аукцион, от каких других блокчейнов принимать ставки, курс обмена токенов между различными блокчейны (которые должны быть зафиксированы заранее) и время завершения аукциона. Затем ретранслятор CC-SVC создает соответствующие контракты и отправляет адрес контракта в цепочке активов аукционисту. Затем аукционист может добавить аукцион на свою панель управления, добавив адрес контракта и нажав кнопку «Добавить существующий аукцион». Тем временем он рекламирует адрес контракта потенциальным участникам торгов.
Когда участники торгов узнают адрес контракта на актив, они также могут добавить его на свои информационные панели. После того, как участник торгов добавил аукцион, он может просмотреть его более подробно, нажав кнопку «Просмотр» на панели аукциона, которая перенаправит его на страницу подробного просмотра. На этой странице участник торгов может просмотреть важную информацию об аукционе, такую как время его создания и завершения, а также список ставок. Самая высокая ставка отмечена звездочкой. Если аукцион еще продолжается, участник торгов может добавить ставку, указав блокчейн.
на котором сделана ставка и количество жетонов для ставки. Затем выполняется транзакция с соответствующим контрактом монеты, и информация отправляется на реле CC-SVC. Пользователь также может отменить любые ставки, сделанные через CC-SVC.
После завершения аукциона реле CC-SVC информирует всех участников и указывает предварительную передачу товаров в смарт-контрактах. Затем CC-SVC просит клиентов всех участников принять участие в голосовании за принятие решения. (Отказ от участия должен повлечь за собой штраф [4].) Когда голосование за принятие создано, оно отправляется всем контрактам, чтобы инициировать окончательную передачу активов. На этом этапе графический интерфейс покажет, что аукцион завершен.
Точный ход демо-версии будет следующим:
Один пользователь – аукционист – открывает графический интерфейс на базе веб-браузера и использует его для инициирования аукциона по выбранному активу. В этом процессе демонстрируются все функции страницы создания аукциона. Актив существует в специальной цепочке заявок, работающей в Hyperledger Fabric. Контракты создаются на всех задействованных блокчейнах (шаг 1 на рисунке 2.
По крайней мере два других пользователя, которые используют окна браузера на разных машинах, переходят на страницу сведений о вновь созданном аукционе и отправляют свои индивидуальные ставки за актив (шаг 2 на рис. 2). По крайней мере один участник торгов использует (частный) Ethereum, а другой — Quorum.
Через некоторое время аукцион завершается и определяется победившая ставка (шаг 3 на рис. 2). Это приведет к тому, что аукционист отправит событие «завершение аукциона» на ретранслятор CCSVC. Подписанты, которые прослушивают события этого типа, заметят это событие и создадут голосование за принятие (шаг 4 на рис. 2). Голосование за принятие затем отправляется в Kafka и пересылается узлом ретрансляции в контракт аукциона и контракты цепочки монет. На этом этапе актив передается победителю торгов, а выигравшая ставка аукционисту (шаг 5 на рис. 2).
На протяжении демонстрации мы будем использовать окно терминала для запроса состояний базовых блокчейнов после каждого шага, как показано на рисунке 4. Это позволит аудитории наблюдать изменения, происходящие в фоновом режиме, и взаимодействовать с потоком данных. демонстрация: например, запросив новые действия, чтобы увидеть, как изменяются фоновые состояния.
Чтобы проиллюстрировать ход демонстрации, в Интернете можно найти видео 2, на котором показаны слайды предварительной демонстрации и экран, на котором аукционист и участники торгов должны были выполнять свои действия, используя один компьютер. (Это не ограничение PIECHAIN, но упрощает запись видео.)
Платформу CC-SVC и интерфейс для поддерживаемых блокчейнов можно использовать для легкого расширения PIECHAIN для других вариантов использования. Одним из них является межсетевой флэш-кредит, как описано в [6]. Графический интерфейс для срочных кредитов будет иметь ограниченное практическое значение, поскольку арбитражные возможности обычно решаются быстро, поэтому взаимодействие с CC-SVC обычно осуществляется торговыми ботами. Однако, если позволяет время, мы покажем визуализацию влияния этапов срочного кредита на состояния различных задействованных контрактов.
[1] Рафаэль Бельхиор, Андре Васконселос, Серхио Геррейро и Мигель Коррейя. Исследование совместимости блокчейнов: прошлые, настоящие и будущие тенденции. Обзоры вычислительных систем ACM (CSUR), 2021 г.
[2] Мигель Кастро и Барбара Лисков. Практическая византийская отказоустойчивость. В ОсДИ, том 99, страницы 173–186, 1999 г.
[3] CoinLore. https://www.coinlore.com/all монеты, 2023 год.
[4] Дэниел Энгель, Морис Херлихи и Инцзе Сюэ. Неудача — это (буквально) вариант: атомарное обязательство против опциональности в децентрализованных финансах. В ССС 2021, 2021.
[5] Морис Херлихи. Атомные межцепочные свопы. В ACM PODC, страницы 245–254, 2018 г.
[6] Морис Херлихи, Барбара Лисков и Люба Шрира. Межсетевые сделки и состязательная коммерция. Журнал ВЛДБ, 2021.
[7] Сатоши Накамото. Биткойн: одноранговая электронная денежная система, 2008 г.
[8] Шри АравиндаКришнан Тьягараджан, Джулио Малаволта и Педро Морено-Санчес. Универсальные атомные свопы: безопасный обмен монетами во всех блокчейнах. В IEEE S&P, 2022 г.
[9] Виктор Захари, Дивьякант Агравал и Амр Эль-Аббади. Атомное обязательство в блокчейнах. Труды Фонда VLDB, 13 (9), 2021 г.
[10] Алексей Замятин, Мустафа Аль-Бассам, Дионис Зиндрос, Элефтериос Кокорис-Когиас, Педро Морено-Санчес, Аггелос Киайяс и Уильям Дж. Ноттенбелт. SoK: Связь между распределенными реестрами. В финансовой криптовалюте, 2021.
[11] Алексей Замятин, Доминик Харц, Джошуа Линд, Панайотис Панайоту, Артур Жерве и Уильям Ноттенбелт. Xclaim: не требующие доверия, совместимые активы, обеспеченные криптовалютой. В IEEE S&P, 2019 г.
Этот документ доступен на arxiv под лицензией CC 4.0.