Как слое-2 туннели и мета-транзакции блокируют блокчейны
17 июня 2025 г.Таблица ссылок
Аннотация и 1. Введение
2. Контекст
2.1. Квантовые вычисления как угроза для криптографии
2.2. Текущие подходы к квантовой криптографии
2.3. Блокчейн и сеть блокчейна LACCHAIN
3. Уязвимости технологии блокчейна с появлением квантовых вычислений
4. Предложение о квантовой безопасной сети блокчейнов
5. Реализация и 5,1 генерации и распределение квантовой энтропии
5.2. Создание сертификатов пост-кванта
5.3. Инкапсуляция связи между узлами с использованием квантовобезопасной криптографии
5.4. Подпись транзакций с использованием ключей после квонта
5.5. Проверка подписей после цепь
6. Выводы и следующие шаги, подтверждения и ссылки
5.3 Инкапсуляция связи между узлами с использованием квантовобезопасной криптографии
Связь между узлами проводится с помощью протокола, установленного технологией блокчейна и варьируется в зависимости от используемой сети. В случае сети Lacchain BESU, используемой для этого пилота, узлы общаются через TCP и используют RLPX для шифрования данных (это то же самое для Ethereum Mainnet, так как Hyperledger BESU является клиентом Ethereum.) Этот протокол запечатывает сообщения с подписью ECDSA на Curve SECP251K1, чтобы связать сетевое сообщение с адресом PEER. Мы решили не изменять этот протокол, потому что это потребует поддержания новой технологии блокчейна. Вместо этого наша цель состояла в том, чтобы продолжать использовать технологию Hyperledger BESU и разработать уровень сверху, чтобы сделать ее квантовой устойчивой.
С целью разработки решения Layer-2, которое может использоваться любым блокчейном с любым протоколом связи и не было бы инвазивным для протокола (то есть не требует модификаций слоя1), наше решение состояло из добавления туннеля с точки зрения на точку, модифицированные для поддержки после квантовых клавиш, где пост-квадратный X.509, описанные в подбоне 5.2.
Для пилота мы использовали асимметричные клавиши Falcon-512. Поскольку это построено на подключении TLS, которое не чувствительно к длине ключа, в отличие от транзакций блокчейна, можно использовать другие алгоритмы постквантюма. Однако для того, чтобы соответствовать использованию одного алгоритма после квонта на разных этапах пилота, мы использовали Falcon-512.
Как только этот туннель установлен, каждый узел должен направить трафик, направленный на его аналог через туннель TLS, что делает его невозможным для квантового компьютера перехватывать трафик и выдавать себя за узел. Это защищает сеть блокчейнов от разных типов атак. Например, поскольку мы не изменяем протокол блокчейна в нашей сети без разрешений, производители узлов, которые голосуют за генерацию новых блоков, все еще материализуют это голосование в подписи ECDSA (протокол консенсуса не требует 2/3+1 сигнатуры производителя узлов для блока, который считается действительным), который не заменяется не соответствующим сигнатурам пост-квантуме. Однако, если хакер должен был обнаружить все частные клавиши ECDSA узлов валидатора и попытаться вмешиваться в производство блока, изменив действительные транзакции и использовать подписи узлов валидатора, чтобы подписать их, он не может достичь ее, потому что не может перехватить связь между узлами, где они могут спровоцировать этот тип атаки человека в среднем. Хакер должен будет взломать и получить доступ к каждому из серверов узел валидатора, для которых квантовые компьютеры не дают преимуществ.
В любом случае, несмотря на то, что мы считаем, что эта угроза удалена с нашим решением, было бы проще и удобнее изменять протокол Ethereum, чтобы криптографические алгоритмы отличались от ECDSA, таких как Falcon-512, распознаются и могут использоваться узлами валидатора для подписи блоков.
5.4 Подпись транзакций с использованием ключей после кванта
В отличие от первых трех этапов, реализация четвертого этапа требует, чтобы мы были особыми в каждой конкретной сети блокчейнов. Существуют протоколы блокчейна, которые распознают различные алгоритмы шифрования и/или уже гибки в включении новых. В настоящий момент это не тот случай Ethereum и Ethereum-Client, Hyperledger Besu, поверх которой строится сеть Lacchain, используемая в пилоте [65]. В этом контексте наш путь к внедрению механизма для добавления квантовой подписи к транзакциям, передаваемым в сеть без модификации протокола блокчейна, была разработка реле-подписавшего и мета-транзакционной схемы.
Мета-транзакция-это механизм, с помощью которого можно обернуть регулярную транзакцию в другую транзакцию, рассматриваемую методу интеллектуального контракта (a.k.a. Relay Hub), который разворачивает и выполняет исходную транзакцию. Поскольку мета-транзакция является регулярным вызовом к умному контракту, мы можем добавить новые параметры вместе с исходной транзакцией. В этом случае наш дизайн позволяет нам добавить URI узела писателя (A DID [81]) и подпись после квонта в оригинальную транзакцию.
Мы разработали подписавшего реле, который предоставляется узлам писателя-единственные узлы, которые разрешены транслировать транзакции в соответствии с топологией Lacchain [82]-которые могут управлять ключами после квонта. Этот компонент обнаруживает стандартный интерфейс JSON-RPC, методы инструмента, чтобы сделать всю операцию прозрачной для пользователя. Каждый узел писателя отвечает за обеспечение безопасности своего частного ключа FALCON512 и подписавшего для генерации мета-транзакции. Рисунок 6 суммирует эти концепции. Кроме того, полное взаимодействие между компонентами представлено на рис. 7.
После EIP-155 [83] подписи в Ethereum принимают девять кодируемых RLP-кодируемых элементов: Nonce, Gasprice, Startgas, To, значение, данные, цепь, 0, 0. Для согласованности мы взяли тот же поток данных для создания сигнатур Falcon-512. Это гарантирует целостность исходной транзакции-узел писателя не может ее модифицировать-и его квантовое сопротивление, добавив подпись после квонта в мета-транзакции. Писательские узлы используют общественные ключи после квантам, сертифицированные CA в пост-квантуме X.509.
Стоит упомянуть, что мы добавляем только подписи после квонта в мета-транзакцию, которая создается узлом писателя, но оригинальные отправители (то есть адреса блокчейна) все еще используют только подписи ECDSA, чтобы подписать свои транзакции. Адреса Ethereum представляют собой 20 байт общедоступного ключа Hashed eCDSA SHA3, поэтому открытый ключ не подвергается напрямую. Однако, когда адрес отправляет транзакцию, для подписи его используется закрытый ключ, и поэтому необходимо раскрыть открытый ключ, чтобы транзакция была проверена.
Таким образом, если адрес блокчейна обладает определенными токенами или имеет особенно важную роль в сети (например, разрешение на интеллектуальный контакт, который может выпускать цифровые облигации), квантовый компьютер может использоваться для взлома закрытого ключа, связанного с этим адресом и отправки транзакций в блокчейн, который выдает истинного владельца. Это позволило бы хакеру украсть средства жертвы или взять на себя их особенно актуальную роль в сети соответственно.
Наше решение позволяет удалить эту угрозу, позволяя каждому интеллектуальному контракту требовать аутентификации послеквантюма и использования для нее одного из наших механизмов проверки в цепочке, представленных в разделе 5.5. Только перенос эфира не будет защищена, но LACCHAIN не обладает эфиром.
Как и в случае подписей с помощью валидаторных узлов, описанных в разделе 5.3, было бы намного проще, идеально и удобно иметь технологию Ethereum, позволяющую использовать квантовые криптографические алгоритмы, которые можно использовать на уровне протокола для подписи и проверки транзакций. Мы считаем, что предложения по улучшению Ethereum (EIPS), такие как EIP-2938 [84], движутся в правильном направлении и очень выровнены с работой, описанной в этой статье.
Авторы:
(1) М. Алленд, IDB - Межамериканский банк развития, 1300 Нью -Йорк, Вашингтон, округ Колумбия, США и Лакчейн - Глобальный альянс для развития экосистемы блокчейна в LAC;
(2) Д. Лопес Леон, IDB - Межамериканский банк развития, 1300 Нью -Йорк, Вашингтон, округ Колумбия, США и Лакчейн - Глобальный альянс для развития экосистемы блокчейна в LAC;
(3) S. Ceron, IDB - Intermerican Bank Development Bank, 1300 New York Ave, Вашингтон, округ Колумбия, США и Lacchain - Глобальный альянс для развития экосистемы блокчейна в LAC;
(4) A. Leal, IDB - Межамериканский банк развития, 1300 New York Ave, Вашингтон, округ Колумбия, США и Lacchain - Глобальный альянс для развития экосистемы блокчейна в LAC;
(5) A. Pareja, IDB - Межамериканский банк развития, 1300 New York Ave, Вашингтон, округ Колумбия, США и Lacchain - Глобальный альянс для развития экосистемы блокчейна в LAC;
(6) М. Да Силва, IDB - Межамериканский банк развития, 1300 New York Ave, Вашингтон, округ Колумбия, США и Lacchain - Глобальный альянс для развития экосистемы блокчейна в LAC;
(7) A. Pardo, IDB - Межамериканский банк развития, 1300 New York Ave, Вашингтон, округ Колумбия, США и Lacchain - Глобальный альянс для развития экосистемы блокчейна в LAC;
(8) Д. Джонс, Квантовые вычисления Кембриджа - Кембридж, Великобритания;
(9) Д.Дж. Уорралл, Квантовые вычисления Кембриджа - Кембридж, Великобритания;
(10) Б. Мерриман, Квант -Квант -Компьютер - Кембридж, Великобритания;
(11) J. Gilmore, Квант -вычисления Кембриджа - Кембридж, Великобритания;
(12) Н. Китченер, Квант -Компьютер Кембридж - Кембридж, Великобритания;
(13) S.E. Венегас-Андрака, Tecnologico de Monterrey, Escuela de Ingenieria y Ciencias. Монтеррей, NL Мексика.
Эта статья естьДоступно на ArxivПод CC BY-NC-ND 4.0 Лицензия.
Оригинал