Сравнение проверки подписи в ходе цепь для ethereum

Таблица ссылок

Аннотация и 1. Введение

2. Контекст

2.1. Квантовые вычисления как угроза для криптографии

2.2. Текущие подходы к квантовой криптографии

2.3. Блокчейн и сеть блокчейна LACCHAIN

3. Уязвимости технологии блокчейна с появлением квантовых вычислений

4. Предложение о квантовой безопасной сети блокчейнов

5. Реализация и 5,1 генерации и распределение квантовой энтропии

5.2. Создание сертификатов пост-кванта

5.3. Инкапсуляция связи между узлами с использованием квантовобезопасной криптографии

5.4. Подпись транзакций с использованием ключей после квонта

5.5. Проверка подписей после цепь

6. Выводы и следующие шаги, подтверждения и ссылки

5.5 Проверка подписи после цепь

Когда узел писателя добавляет квантовую подпись в мета-транзакцию и транслирует ее в сеть, должен быть механизм для проверки подписи. В обычном протоколе Ethereum нет явной проверки для какой -либо подписи. В протоколе Ethereum, для данной подписи ECDSA, адрес получен и используется в качестве личности лица, желающего выполнить и оплатить операцию блокчейна. Для сети Lacchain BESU мы решили реализовать протокол проверки на основе функции разрешений Onchain, которая основана на интеллектуальных контрактах. Эта функция позволяет каждому узлу перехватывать каждую транзакцию и запускать различные валидации, прежде чем включать их в свой пул транзакций и воспроизвести их на своих сверстников.

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

Как обсуждалось ранее (см. Раздел 5.4), мы используем модель мета-транзакции для выполнения запросов пользователей. Это означает, что для нашей сети есть точка с одним входом, которая является адресом контракта на реле, где направлена ​​мета-транзакция. Следовательно, первая проверка разрешений состоит в том, что целевым адресом является контракт на реле. В противном случае узлы отклонят транзакцию.

После того, как смарт-контракт Relay Hub был проверен как цель транзакции, каждый узел извлекает исходную транзакцию полезной нагрузки, узел писателя сделал, и подпись Falcon-512 из исходной транзакции, чтобы проверить подпись. Кроме того, призыв к реестру DID позволяет извлечь связанные с ним общественные ключи, включая открытый ключ после QUANTUM, который должен соответствовать подписи после квонта. С помощью этой информации каждый узел, получающий транзакцию от сверстника, принимает исходную транзакцию, открытый ключ и подпись и проверяет их последовательность. Если это не последовательно, они отвергают транзакцию (то есть они не добавляют ее в свой пул транзакций и не распространяют ее другим сверстникам).

Подводя итог, протокол, который мы разработали, состоит из трех шагов:

1. Каждый узел, который получает мета-транзакцию-от узла, который создал его, или от другого узла, который повторяет его-проверяет отправителя. Это включает в себя получение DID от мета-транзакции и местного запроса реестра DID, чтобы разрешить (то есть получить) его ключи Ethereum (ECDSA). Затем они подтверждают, что открытый ключ, полученный из подписи ECDSA мета-транзакции, контролирует девело узел, которые его сгенерировали.

2. Если шаг 1 успешен, узел снова вызывает реестр DID и теперь разрешает публичный ключ Postquantum, связанный с DID, а также общедоступным ключом Ethereum, подтвержденным на шаге 1.

3. С помощью публичного ключа после Quantum, разрешенного из реестра DID на шаге 2, подписи после квонта и исходной транзакции, каждый узел затем проверяет алгоритм после квонта.

Если три предыдущих шага успешно выполнены, узлы добавляют мета-транзакцию в свой пул транзакций и повторяют их на другие узлы, чтобы валидаторы получали их и добавляли в следующий блок.

Как указывалось ранее, мы выбрали Falcon-512 в качестве нашего алгоритма после квонта. Пока нет идеального способа реализации проверки FALCON-512, необходимой для выполнения шага 3 этого процесса проверки или любого другого алгоритма после квонта, в сети на основе Ethereum. Мы разработали три альтернативных механизма и проанализировали их плюсы и минусы, которые подробно представлены в подразделе 5.5.4.

Эти три механизмы:

• Реализация кода проверки в солидности (см. Подраздел 5.5.1).

• Реализация инструкции по солидности в компиляторе SOLC и соответствующем EVM OpCode, написанном на Java (BESU написан на Java), который выполняет вызов через JNI с NIST-совместимой и высокоэффективной библиотекой Liboqs за пределами виртуализированной среды EVM (см. Подраздел 5.5.2).

• Рефакторирование EVM Opcode Java из виртуальной машины EVM в предварительно скомпилированный контракт (Native Smart Contract EVM-код кода), который выполняет призыв через JNI с соответствующей высокопроизводительной библиотекой Liboqs за пределами виртуализированной среды EVM (см. Подраздел 5.5.3).

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

5.5.1. Код проверки в солидности

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

Реализация выделенных части рис. После завершения процесса разработки мы столкнулись с двумя основными проблемами. Первой проблемой был размер кода. Он превысил предел 24 КБ, который налагает Ethereum Mainnet. Этот предел мог быть превышен в Lacchain, потому что Lacchain имеет разные границы, но такие большие размеры кода не являются идеальными. Второй и более серьезной проблемой была стоимость выполнения. На рис. 9 мы представляем диаграмму с стоимостью выполнения проверки известных тестов ответа, предоставленных реализацией Falcon. Если мы сравним в среднем 500 миллионов газовых единиц для одной проверки подписи Falcon, с текущим ограничением блока 12 миллионов газовых единиц в Mainnet Ethereum, мы можем сделать вывод, что этот подход на данный момент является совершенно нецелесообразным.

5.5.2 ЭВМ

Подход, основанный на EVM, требует модификации как компилятора Solidity (SOLC), так и виртуальной машины Ethereum (EVM), которая лежит в основе технологии BESU Hyperledger, используемой LACCHAIN.

Эти изменения применимы во всех сетях на основе Ethereum, но требуют всех участвующих узлов в блокчейне, чтобы использовать обновленный компилятор Solidity и EVM. Инативный интерфейс Java (JNI) также необходим в дополнение к обеспечению того, чтобы библиотеки LiboQs были установлены совместимых Liboqs Libraries Safe (предприятие с открытым исходным кодом. Поэтому производительность ограничена только местной библиотекой Liboqs и мощностью обработки нативного узла.

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

В подходе используется только один Opcode из вызова ограниченного вызова 6000 Opcodes в стандартной конфигурации Ethereum. Реальная производительность проверки подписи настолько быстрая, как и аппаратное обеспечение - соответствовать производительности, наблюдаемой безопасными командами OpenQuantum.

Использование библиотеки Liboqs OpenQuantum обеспечивает минимальную эксплуатационную задержку или риск поддержания обновленных квантовых алгоритмов в соответствии с NIST и стандартами безопасного текущего открытия. Класс Java, реализованный для EVM, также может быть расширен за пределы Falcon-512 и позволить Falcon-1024 или другие подписи.

Ширина слов стека EVM составляет 256 бит, что, естественно, соответствует существующим 256-битным хэши, используемым в классическом шифровании. Тем не менее, подписи после квонта с более крупными требованиями к памяти станут менее оптимальными, если ширина слов стека не увеличивается за счет совместимости с ранее рабочими блокчейнами. Наконец, внедрение POC EVM использует Falcon-512, что сводит к минимуму это влияние, а также обеспечивает уровень безопасности, который соответствует классическому AES-256. Рис. 10 суммирует взаимодействия, описанные в этом подразделе.

5.5.3.

Предварительно скомпилированный подход трансплантат EVM Falcon проверяет операцию Java Class в предварительно скоптированный смарт-контракт EVM (нативный смарт-контракт с нативным Java). Этот подход имеет два преимущества, которые снижают оперативное воздействие:

• Нет изменений в компиляторе Solidity.

• Нет изменений в основной виртуальной машине EVM.

Это облегчает распределение проверки квантовой подписи отдельно от выпусков компилятора и EVM. Таким образом, этот подход приносит все преимущества реализации EVM OpCode, но с меньшей работой. Библиотеки JNI и Liboqs используются одинаково, предлагая скорость и простоту обслуживания. Стоит также упомянуть, что, учитывая эту проверку, которая должна быть выполнена до того, как узел присоединится к блокчейну, ее можно легко заменить в будущем, не влияя на консенсус. Будет необходимо только изменять сценарии развертывания.

Реализация этого решения в сети Lacchain Hyperledger BESU потребует изменений в протоколе в отношении других сети Ethereum, включая MainNet. Это было бы против нашей цели сохранить совместимость с сообществом Ethereum. Таким образом, идеальный способ приступить к этому третьему подходу для проверки подписей Falcon-это отправление EIP для сообщества для оценки включения предварительно скомпилированного интеллектуального контракта в протокол Ethereum, являясь этим либо полным алгоритмом проверки Falcon, либо той же обнаруживаемым узким местом с точки зрения потребления газа.

На рис. 11 показаны некоторые преимущества и недостатки чистой прочности, EVM Opcode и предварительно скомпилированного контракта.

5.5.4 Сравнение между различными решениями для проверки подписей после квонта

Три альтернативы, которые были разработаны и протестированы для проверки подписей после квонта, являются успешными для проверки, но не идеальны для продуктивной реализации, если внедряющая их сеть, основанная на Ethereum, предназначена для того, чтобы оставаться полностью совместимой с Ethereum Mainnet. Нативная реализация Solidity, представленная в подразделе 5.5.1, не является масштабируемой из -за количества газа, необходимого для выполнения кода, хотя она не требует модификации BESU или Ethereum. Модификация компилятора Solidity и EVM, а также предварительно скомпилированный смарт-контракт (представленные в подразделах 5.5.2 и 5.5.3 соответственно), являются вычислительно масштабируемыми. Тем не менее, они требуют нежелательных модификаций, если иное не согласовано всем сообществом Ethereum, что является целью, к которой мы стремимся выполнять на следующем этапе этого пилота.

Кроме того, решения, описанные в подразделах 5.5.2 и 5.5.3, используют виртуальную машину Java. Однако, в отличие от нативной реализации Solidity, на эти два метода не влияют математические вычислительные задачи EVM или Javavm, поддержающие достоверность и безопасность между выпусками. Вместо этого, чистый нативный метод Liboqs реализует свои собственные математические тесты достоверности как часть системы сборки C. Результатом является то, что независимо от выпуска Java или EVM, проверка библиотеки Liboqs остается математически достоверной (при условии, что нет оптимизации или изменений, которые признают тесты). Этот подход позволяет организациям разделять требования безопасности, предлагая более точное обслуживание и управление. Тем не менее, этот подход потребует дополнительных протоколов безопасности с дополнительными накладными расходами.