[RU]

Предложена универсальная операционная система для координации действий устройства, влияния на них или управления ими. Настоящее изобретение реализуют с использованием платформы блокчейна, для взаимодействия с которой сконфигурирована предложенная операционная система. Блокчейн может быть блокчейном биткойн. В одном из предпочтительных вариантов осуществления изобретения упомянутое устройство является устройством интернета вещей (IOT). В настоящем изобретении предложены реализуемая при помощи компьютера система управления и соответствующий способ управления устройством, при этом система включает устройство, сконфигурированное для беспроводной связи с сетью и имеющее ассоциированные с ним IP-адрес, а также пару из публичного и приватного криптографических ключей; программно-реализованный управляющий компонент, сконфигурированный для мониторинга состояния сети блокчейна и/или для передачи блокчейн-транзакций в сеть блокчейна; набор инструкций, сконфигурированных для исполнения упомянутого управляющего компонента с целью управления функциональностью устройства. Управляющий компонент сконфигурирован для доступа к набору инструкций в месте хранения данных, которое является отдельным от устройства. Набор инструкций может храниться в распределенной хэш-таблице (DHT), при этом к нему может осуществлять доступ управляющий компонент для его загрузки и установки, по необходимости и в любой требуемый момент. Местоположение DHT-таблицы и/или инструкций может быть указано или предоставлено с использованием метаданных, размещенных в блокчейн-транзакции. Управляющий компонент может осуществлять доступ к набору инструкций с использованием ключа поиска, который связан с парой криптографических ключей. Управляющий компонент размещен в устройстве, или в других вариантах осуществления изобретения он может размещаться вне устройства и может быть сконфигурирован для беспроводной связи с устройством.

(57) Реферат / Формула:

Предложена универсальная операционная система для координации действий устройства, влияния на них или управления ими. Настоящее изобретение реализуют с использованием платформы блокчейна, для взаимодействия с которой сконфигурирована предложенная операционная система. Блокчейн может быть блокчейном биткойн. В одном из предпочтительных вариантов осуществления изобретения упомянутое устройство является устройством интернета вещей (IOT). В настоящем изобретении предложены реализуемая при помощи компьютера система управления и соответствующий способ управления устройством, при этом система включает устройство, сконфигурированное для беспроводной связи с сетью и имеющее ассоциированные с ним IP-адрес, а также пару из публичного и приватного криптографических ключей; программно-реализованный управляющий компонент, сконфигурированный для мониторинга состояния сети блокчейна и/или для передачи блокчейн-транзакций в сеть блокчейна; набор инструкций, сконфигурированных для исполнения упомянутого управляющего компонента с целью управления функциональностью устройства. Управляющий компонент сконфигурирован для доступа к набору инструкций в месте хранения данных, которое является отдельным от устройства. Набор инструкций может храниться в распределенной хэш-таблице (DHT), при этом к нему может осуществлять доступ управляющий компонент для его загрузки и установки, по необходимости и в любой требуемый момент. Местоположение DHT-таблицы и/или инструкций может быть указано или предоставлено с использованием метаданных, размещенных в блокчейн-транзакции. Управляющий компонент может осуществлять доступ к набору инструкций с использованием ключа поиска, который связан с парой криптографических ключей. Управляющий компонент размещен в устройстве, или в других вариантах осуществления изобретения он может размещаться вне устройства и может быть сконфигурирован для беспроводной связи с устройством.

---

Евразийское (21) 201892133 (13) A1
патентное
ведомство
(12) ОПИСАНИЕ ИЗОБРЕТЕНИЯ К ЕВРАЗИЙСКОЙ ЗАЯВКЕ
(43) Дата публикации заявки 2019.04.30
(22) Дата подачи заявки 2017.04.28
(51) Int. Cl.
G06Q 20/36 (2012.01) G06F21/30 (2013.01) G06Q10/06 (2012.01) H04W4/00 (2009.01)
(54) ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
(31) 1607476.7
(32) 2016.04.29
(33) GB
(86) PCT/IB2017/052465
(87) WO 2017/187397 2017.11.02
(71) Заявитель:
НЧЕЙН ХОЛДИНГС ЛИМИТЕД (AG)
(72) Изобретатель:
Райт Крейг Стивен, Савана Стефани
(GB)
(74) Представитель:
Поликарпов А.В., Соколова М.В., Путинцев А.И., Черкас Д.А., Игнатьев А.В. (RU)
(57) Предложена универсальная операционная система для координации действий устройства, влияния на них или управления ими. Настоящее изобретение реализуют с использованием платформы блокчейна, для взаимодействия с которой сконфигурирована предложенная операционная система. Блокчейн может быть блокчейном биткойн. В одном из предпочтительных вариантов осуществления изобретения упомянутое устройство является устройством интернета вещей (IOT). В настоящем изобретении предложены реализуемая при помощи компьютера система управления и соответствующий способ управления устройством, при этом система включает устройство, сконфигурированное для беспроводной связи с сетью и имеющее ассоциированные с ним IP-адрес, а также пару из публичного и приватного криптографических ключей; программно-реализованный управляющий компонент, сконфигурированный для мониторинга состояния сети блокчейна и/или для передачи блокчейн-транзакций в сеть блокчейна; набор инструкций, сконфигурированных для исполнения упомянутого управляющего компонента с целью управления функциональностью устройства. Управляющий компонент сконфигурирован для доступа к набору инструкций в месте хранения данных, которое является отдельным от устройства. Набор инструкций может храниться в распределенной хэш-таблице (DHT), при этом к нему может осуществлять доступ управляющий компонент для его загрузки и установки, по необходимости и в любой требуемый момент. Местоположение DHT-таблицы и/или инструкций может быть указано или предоставлено с использованием метаданных, размещенных в блокчейн-транзак-ции. Управляющий компонент может осуществлять доступ к набору инструкций с использовани- I ем ключа поиска, который связан с парой криптографических ключей. Управляющий компонент размещен в устройстве, или в других вариантах осуществления изобретения он может размещаться вне устройства и может быть сконфигурирован для беспроводной связи с устройством.
РСТ/Ю2017/052465
WO/2017187397
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В
БЛОКЧЕЙНЕ
Настоящее изобретение относится, в общем, к технологии распределенных реестров (блокчейна). Оно может относиться к любым технологиям, связанным с блокчейном, включая (без ограничения этим) блокчейн Биткойн. Некоторые из аспектов настоящего изобретения также относятся к Интернету вещей (Internet of Things, IoT). Настоящее изобретение может применяться для управления 1оТ-устройствами.
В данном документе термин "блокчейн" включает любые формы электронных, компьютерных, распределенных реестров. Они включают консенсусный блокчейн и технологии цепи транзакций, реестры с разрешениями и без разрешений, разделяемые реестры, "сайдчейны" и "альтчейны", а также их вариации. Наиболее известным применением технологии блокчейна является реестр Биткойн, однако были предложены и разработаны и другие реализации блокчейна. Для удобства и иллюстрации в данном документе может упоминаться Биткойн, однако следует отметить, что настоящее изобретение не ограничено применением с блокчейном Биткойн, и что другие реализации и протоколы блокчейна также входят в объем настоящего изобретения. Под термином "пользователь" в настоящем документе может пониматься человек или ресурс на базе процессора.
Блокчейн представляет собой одноранговый электронный реестр, который реализован в виде компьютерной, децентрализованной и распределенной системы, составленной из блоков, которые, в свою очередь, состоят из транзакций. Каждая из транзакций представляет собой структуру данных, в которой закодирована передача управления цифровым активом между участниками системы блокчейна, при этом она имеет по меньшей мере один вход и по меньшей мере один выход. Каждый блок содержит хэш-значение предыдущего блока, благодаря чему блоки сцеплены друг с другом и образуют устойчивую, неизменяемую запись всех транзакций, записанных в блокчейн с момента его создания. Транзакции содержат небольшие программы, которые называют скриптами, и которые встроены в их входы и выходы. Они определяют, кто и каким образом сможет получить доступ к выходам транзакции. В платформе Биткойн такие скрипты пишут на стековом скриптовом языке.
Чтобы транзакция была записана в блокчейн, она должна пройти "валидацию". Сетевые узлы (майнеры) выполняют действия, которые позволяют убедиться, что
транзакция является правомерной, а неправомерные транзакции отбрасываются сетью. Программные клиенты, установленные на таких узлах, выполняют операции по валидации непотраченных транзакций (UTXO) при помощи выполнения их блокирующих и разблокирующих скриптов. Если исполнение блокирующего и разблокирующего скриптов дает в результате истинное значение (TRUE), транзакция правомерна. Многие из команд (например, OP-EQUAL) языка написания скриптов возвращают логические (Boolean) значения, что дает возможность внедрять условные конструкции в блокчейн-транзакции.
Технология блокчейна известна как применяемая в основном для реализации криптовалют. Однако в последнее время "цифровые предприниматели" все чаще рассматривают возможность применения, при реализации новых систем, как криптографической системы безопасности, лежащей в основе Биткойн, так и возможности хранения данных в блокчейне. Настоящее изобретение относится к одному из подобных новых и оригинальных применений технологий блокчейна.
А именно, оно относится к использованию блокчейна для реализации простых, но в то же время эффективных и мощных механизмов создания широкого и разнообразного ряда компьютерных систем. Подобные системы могут включать блоки и системы управления для автоматизации и контроля процессов и/или управления поведением устройств.
Упомянутые устройства могут включать ЮТ-устройства. ЮТ-устройства имеют в своем составе электронные схемы, программное обеспечение, датчики, сетевые функции и другие элементы, которые позволяют им осуществлять связь с другими устройствами и системами, зачастую при помощи средств беспроводной связи, а также выполнять требуемые задачи. В некоторых случаях они могут быть очень миниатюрными и обладать лишь ограниченной вычислительной мощностью и объемом памяти. Это может проводить к затруднениям, если программное обеспечение для решения задач, поставленных перед устройством, является сложным и объемным. При этом, если программное и аппаратное обеспечение для обеспечения IoT-взаимодействия и интеллектуальных функций размещено непосредственно в устройствах, их установка, техническое обслуживание, обновление и другие операции, становятся более сложными и дорогими. Также в последние годы интерес к потенциальным возможностям ЮТ несколько остыл из-за возможных рисков безопасности.
Описание существующего уровня техники
В документе "ADEPT: An IoT Practitioner Perspective" (перспективы применения IoT), опубликованном в январе 2015 года, описан подход к интеграции блокчейн-технологий в IoT-устройства. На момент подачи заявки документ был доступен по следующей ссылке: https://ia902601.us. archive. org/4/items/pdfy-esMcC00dKmdo53-/roM%20ADEPT%20Practictioneiyo20Perspective%20-%20Pre%20Publication%20Draft%20-%207%20Jan%202015.pdf. В этом документе (далее: "ADEPT") описана стиральная машина, управляемая по контракту и осуществляющая связь с поставщиком по блокчейну для приобретения расходных материалов, когда выполнено условие "малый уровень стирального порошка".
В документе ADEPT описано, каким образом IoT-система может осуществлять операции при помощи блокчейна, однако при этом не освещена проблема, как подобная система может быть выполнена, конфигурирована или каким образом на нее может оказываться техническое воздействие с использованием блокчейна. Другими словами, документ ADEPT показывает, каким образом программное обеспечение IoT может автономно взаимодействовать с блокчейном, однако в нем не рассмотрено и не описано, как программное обеспечение может быть первоначально помещено на устройство, а также, каким образом может быть изменено поведение устройства в процессе эксплуатации, использования и/или развертывания.
Таким образом, представляется желательным предложить операционную систему, являющуюся универсальной (т.е. независимой от типа устройства), и одновременно достаточно компактной для загрузки на любое устройство, однако при этом обладающей также высокой степенью кибербезопасности. Предпочтительно, подобная операционная система должна обеспечивать динамическую функциональность устройства, а не только статическую функциональность. Другими словами, значительным техническим преимуществом стала бы возможность простого, эффективного и динамического изменения конфигурации, регулировки и функциональности устройства (или устройств). Такого технического решения на существующем уровне техники предложено не было (в том числе, в документе ADEPT). Еще одним преимуществом по сравнению с существующим уровнем техником была бы возможность обеспечения простой, безопасной и устойчивой функциональности управления, включая возможность обработки платежей за услуги, предоставляемые устройством. Настоящее изобретение
позволяет решить эти, а также другие задачи, путем обеспечения интерфейса между ЮТ-устройством и протоколом блокчейна, например, блокчейна Биткойн.
Итак, в соответствии с настоящим изобретением предложены система и способ, которые определены в приложенной формуле изобретения.
Настоящее изобретение позволяет получить способ и систему, реализуемые при помощи компьютера. Настоящее изобретение может быть описано как способ управления, поскольку обеспечивает контроль, управление и/или влияние на действия одного или более устройств. Настоящее изобретение может быть также описано как операционная система. Оно может быть реализовано программно.
Оно может включать операционную систему для координации, управления и/или влияния на действия по меньшей мере одного устройства. Операционная система может быть универсальной, в том смысле, что она не зависит от устройства, которым она управляет.
Настоящее изобретение может быть реализовано с использованием платформы блокчейна, для взаимодействия с которой сконфигурирована операционная система ("управляющий компонент"). Блокчейн может быть блокчейном Биткойн. В одном из предпочтительных вариантов осуществления настоящего изобретения упомянутое устройство является устройством Интернета вещей (ЮТ).
Настоящее изобретение позволяет получить реализуемую при помощи компьютера систему управления для управления устройством. Система может включать:
устройство, сконфигурированное для беспроводной связи с сетью и имеющее ГР-адрес, а также пару из публичного и приватного криптографических ключей, ассоциированных с этим устройством;
реализованный при помощи компьютера управляющий компонент, сконфигурированный для мониторинга состояния сети блокчейна и/или для передачи блокчейн-транзакций в сеть блокчейна; и/или
набор инструкций, сконфигурированных для исполнения упомянутым управляющим компонентом с целью управления функциональностью устройства.
Управляющий компонент может быть сконфигурирован для доступа к набору инструкций в месте хранения, которое является отдельным от устройства, т.е. расположено "вне устройства".
Управляющий компонент может быть сконфигурирован для приема входного сигнала от источника входных сигналов. Источником входных сигналов может быть:
другое устройство; и/или
компьютерный ресурс или агент. Компьютерный агент или ресурс по существу могут соответствовать приведенному ниже описанию.
Упомянутый набор инструкций может храниться в распределенной хэш-таблице (Distributed Hash Table, DHT), при этом к нему может осуществлять доступ управляющий компонент для его загрузки и установки. Одно из преимуществ такого подхода заключается в том, что он позволяет менять инструкции (и следовательно, функциональность устройства).
Местоположение DHT-таблицы может быть указано, или предоставлено, с использованием метаданных, размещенных в блокчейн-транзакции. Преимущество такого подхода заключается в том, что местоположение инструкций записано неизменяемым образом в блокчейне. Соответственно, обеспечивается устойчивая к взлому долговременная запись, и местоположение может быть верифицировано любой стороной, имеющей доступ к блокчейну. Соответственно, повышается уровень безопасности и достоверности.
Управляющий компонент может осуществлять доступ к управляющему компоненту с использованием ключа поиска, который связан с парой криптографических ключей.
Управляющей компонент может быть размещен в (или на) устройстве. Он может быть также размещен в некотором местоположении вне устройства и сконфигурирован для беспроводной связи с устройством.
Управляющий компонент может быть сконфигурирован:
для выполнения криптографических вычислений;
для доступа к ассоциированной с ним паре из приватного и публичного ключей; для обладания соответствующим адресом Биткойн или иным адресом, относящимся к блокчейну;
для управления устройством по API-интерфейсу;
для выполнения операций протокола разделения секрета. Он может по существу соответствовать описанному ниже протоколу разделения секрета.
Управляющий компонент может быть сконфигурирован для влияния на действия устройства (или устройств) или для управления такими действиями, на основании обнаружения действительной блокчейн-транзакции.
Настоящее изобретение позволяет получить систему и/или способ, которые соответствуют по существу приведенному ниже описанию.
Настоящее изобретение позволяет получить реализуемый при помощи компьютера способ управления устройством или множеством устройств. Способ может включать следующие шаги:
предоставление устройства, сконфигурированного для (беспроводной) связи с сетью и имеющего ГР-адрес, а также пару из публичного и приватного криптографических ключей, ассоциированных с этим устройством;
предоставление программно-реализованного управляющего компонента, сконфигурированного для мониторинга состояния сети блокчейна и/или для передачи блокчейн-транзакций в сеть блокчейна;
предоставление набора инструкций, сконфигурированных для исполнения упомянутым управляющим компонентом с целью управления функциональностью устройства.
Управляющий компонент может быть сконфигурирован для доступа к набору инструкций в месте хранения данных, которое является отдельным от устройства. Управляющий компонент может быть сконфигурирован для приема входного сигнала от источника входных сигналов, при этом источником входных сигналов может быть:
другое устройство;
и/или компьютерный ресурс или агент.
Упомянутый набор инструкций может храниться в распределенной хэш-таблице (Distributed Hash Table, DHT), при этом к нему может осуществлять доступ управляющий компонент для его загрузки и установки.
Местоположение DHT-таблицы может быть указано, или предоставлено, с использованием метаданных, размещенных в блокчейн-транзакции. Управляющий компонент может осуществлять доступ к набору инструкций с использованием ключа поиска, который связан с парой криптографических ключей.
Управляющей компонент может быть размещен в устройстве. Он может быть также размещен в некотором местоположении вне устройства и сконфигурирован для беспроводной связи с устройством.
Управляющий компонент может быть сконфигурирован:
для выполнения криптографических вычислений;
для доступа к ассоциированной с ним паре из приватного и публичного ключей;
для обладания соответствующим адресом Биткойн или иным адресом, относящимся к блокчейну;
для управления устройством по API-интерфейсу;
для выполнения операций протокола разделения секрета.
Управляющий компонент может быть сконфигурирован для влияния на действия устройства или для управления такими действиями на основании обнаружения действительной блокчейн-транзакции.
Любые отличительные признаки, описанные в отношении одного из вариантов или аспектов настоящего изобретения, могут также быть применимы для любых других аспектов или вариантов осуществления настоящего изобретения. К примеру, любые отличительные признаки, упомянутые в отношении системы, могут быть также применимы для способа и наоборот.
Для более глубокого понимания этих и других аспектов настоящего изобретения следует обратиться к рассмотренному ниже конкретному варианту его осуществления. Далее, исключительно в качестве примера, будет описан один из вариантов осуществления настоящего изобретения, с помощью примеров и со ссылками на приложенные чертежи.
На фиг. 1 показана система, сконфигурированная в соответствии с одним из вариантов осуществления настоящего изобретения, в связи с одним из примеров сценария применения;
на фиг. 2 показана таблица истинности для системы управления по фиг. 1; на фиг. 3 показаны шаги обработки данных для разблокировки транзакции в примере фиг. 1; и
на фиг. 4-8 показан способ, который может применяться для разделения секрета и формирования публичного или приватного ключа.
На фиг. 9-11 проиллюстрированы аспекты реализации, в которых блокирующий скрипт блокчейн-транзакции используют для реализации функциональности логического вентиля.
На фиг. 9 в общем виде проиллюстрирован способ, в котором два логических входа А и В оценивают в блокирующем скрипте первой транзакции и получают логический выход X.
На фиг. 10 в общем виде показан способ реализации логического вентиля с использованием первой и второй блокчейн-транзакций.
На фиг. 11 проиллюстрирована процедура, в которой для реализации функциональности логического вентиля применяют блокирующий скрипт блокчейн-транзакции.
Настоящее изобретение, помимо прочих, позволяет получить следующие, преимущества:
• он позволяет получить операционную систему, намеренно "тонкую" (компактную в отношении требований к памяти и/или вычислительной мощности), которая, таким образом, может быть реализована в любом ЮТ-устройстве;
• ее обновление не представляет затруднений, поскольку функциональность каждого конкретного устройства не жестко запрограммирована в устройстве, а загружается из защищенного хранилища, например, распределенной хэш-таблицы (DHT); это является значительным техническим усовершенствованием по сравнению с текущим уровнем техники, где динамическое конфигурирование не обеспечивается;
• управление и администрирование могут осуществляться автономными вычислительными агентами (а не программным обеспечением, размещенным на ЮТ-устройстве или вне его);
• за счет интерфейса с блокчейном, например, платформой Биткойн, обеспечивается интеграция функций обработки платежей;
• обеспечивается высокая степень безопасности на базе криптографии блокчейна, например, ЕСС-криптографии Биткойн.
ЮТ-устройство с функциями блокчейна (Blockchain ЮТ Device, BID) представляет собой вычислительный агент, который сконфигурирован для исполнения заранее заданных инструкций, защищенно хранимых вне ВШ-устройства, доступ к которым осуществляется через криптографические ключи. Под хранением "вне ВШ-устройства" понимается то, что инструкции не размещены в самом ВШ-устройстве, а хранятся в другом месте, к которому при необходимости может осуществляться доступ. Инструкции выбирают и конфигурируют для выполнения требуемой задачи или множества задач. При исполнении эти инструкции могут управлять ЮТ-устройством или влиять на его поведение. В одном из предпочтительных вариантов осуществления настоящего изобретения ВШ-устройство размещают непосредственно в ЮТ-устройстве, и это означает, что ВШ-устройство устанавливают в память, находящуюся в (или на) ЮТ-устройстве. Однако в других вариантах осуществления настоящего изобретения ВШ
устройство может располагаться вне устройства и быть связано с устройством через Интернет.
ЮТ-устройство имеет собственный криптографический ключ (а также ГР-адрес), поэтому оно может осуществлять защищенную связь и взаимодействие с другими устройствами или DHT-таблицами и т.п. Его "операционная система" представляет собой простую универсальную систему, по меньшей мере со следующими встроенными функциями (без ограничения перечисленным):
• криптографические вычисления;
• получение инструкций из внешнего источника (например, DHT-таблицы);
• выполнение простых действий, например, переключение выключателей (на физическом ЮТ-устройстве).
Таким образом, ни ЮТ-устройство, ни относящееся к нему ВШ-устройство, не содержат собственных встроенных инструкций и "не знают", что именно они выполняют и каким образом. ВШ-устройство содержит только механизм для безопасного получения инструкций извне. ВШ-устройство может выполнять только набор простых действий (которые, без ограничения, приведены ниже исключительно для примера):
• доступ к собственной паре из публичного и приватного мастер-ключей; наличие собственного (вычисляемого) адреса ВТС;
• способность передавать данные на ГР-адреса или принимать данные с ГР-адресов;
• вычисления, связанные с протоколом разделения секрета (описанного ниже), в одном из предпочтительных вариантов осуществления настоящего изобретения они могут быть встроены в машинный код;
• поиск и интерпретация событий в блокчейне;
• управление и контроль над физическим устройством, к которому оно подключено (по стандартному API-интерфейсу, представляющего собой, по сути, просто набор переключателей).
Входящие и исходящие сообщения связи для ВШ-устройства шифруют с использованием описанного ниже механизма безопасности, который позволяет формировать ключи с помощью разделяемых секретов. Это дает возможность:
(i) повысить уровень защиты от "взлома";
(ii) использовать простые и универсальные протоколы обновления программного обеспечения;
(iii) обеспечить независимость от типа устройства.
(i)
Настоящее изобретение, таким образом, позволяет получить универсальную операционную систему, которая может применяться в любых ЮТ-устройствах. Само устройство при этом не программируют - все программы хранят отдельно и загружают на устройство в момент конфигурирования (или, в некоторых из вариантов осуществления настоящего изобретения, в момент исполнения).
Пример использования настоящего изобретения
Рассмотренный ниже пример относится к использованию одного из вариантов осуществления настоящего изобретения для управления ЮТ-устройством, представляющим собой автоматическую кормушку. Он приведен исключительно для иллюстрации, в качестве одного из примеров того, как может применяться одна из возможных реализаций настоящего изобретения.
Рассмотрим фиг. 1, система 100 включает первое и второе клиентские устройства, обозначенные, соответственно, 102а и 102Ь, а также систему 104 управления ВШ, которая выполнена с возможностью приема входных сигналов от первого и второго клиентских устройств 102а, 102Ь, а также передачи информации в первое и второе клиентские устройства 102а, 102Ь. В данном примере использования настоящего изобретения первое и второе клиентские устройства 102а, 102Ь представляют собой устройства радиочастотной идентификации (radio frequency identification devices, RFID), обнаруживаемые системой 104 управления ВШ. Система 104 управления выполнена с возможностью использования блокчейна и передачи выходных данных в блокчейн.
Работа системы 104 управления будет рассмотрена на примере двух собак, принадлежащих Кэрол, по кличке Архимед (А) и Бертран (В), которых оставляют одних во дворе частного дома на целый день, при этом они ведут себя дружелюбно по отношению друг к другу, только если их не кормить одновременно, что, по каким-то причинам, вызывает у них взаимную агрессию и приводит к стычкам. У обоих собак, А и В, имеются ошейники с RFID-идентификаторами, а именно, первый ЯБШ-ошейник 102а и второй ЯБШ-ошейник 102Ь, которые могут обнаруживаться устройством 101 с функциями Интернета вещей (ЮТ). Это ЮТ-устройство представляет собой автоматическую кормушку, которая выдает заданное количество корма для одной из собак, т.е. система 104 управления ВШ управляет работой устройством ЮТ-кормушки.
В данном примере ВШ-устройство 104 представляет собой программный ресурс или компонент, размещенный на автоматической ЮТ-кормушке и имеющий интерфейс с кормушкой для управления ее функциями.
Исходно работа ВШ-устройства начинается с загрузки и установки его инструкций из DHT-таблицы. Эта операция не требует повторения до тех пор, пока инструкции не будут модифицированы. Это может иметь место, например, когда необходимо обновление ВШ-устройства, или когда поведение ВШ-устройства должно быть коренным образом изменено, например, может потребоваться изменение набора инструкций для обнаружения трех или более RFID-сигналов.
Управляющий агент использует значения, передаваемые ВШ-устройством, для создания блокчейн-транзакции, а также разделяет новые секреты с ВШ-устройством после каждой итерации, в соответствии с последующим описанием.
Функциональность системы 104 управления ВШ реализуют с помощью блокчейн-транзакции, которую блокируют при помощи следующего блокирующего скрипта:
OPHASH160 <хэш-значение блокирующего скрипта> OPEQUAL
Транзакции создают для обеспечения (при помощи метаданных, ссылающихся на распределенную хэш-таблицу, DHT) набора инструкций для управления ЮТ-устройством, т.е. автоматической кормушки, который может включать инструкции для вычислительного ресурса, сформированного в соответствии с приведенным ниже описанием. Вместо хранения инструкций непосредственно в транзакции, метаданные могут включать указатель или ссылку на местоположение, из которого может быть получен доступ к инструкциям. То есть, инструкции могут храниться вне блокчейна.
Блокчейн не только предоставляет механизм для управления действиями, но также обеспечивает запись информации о произошедших события, например, дает возможность подсчитать количество кормлений, записать моменты времени кормления, какая из собак получила пищу, была ли выдана максимальная порция корма и т.п. Он также обеспечивает криптографическую защиту.
Важной функцией упомянутой транзакции является гарантия того, что корм выдается, только если у кормушки одновременно находится только одна из собак. Соответственно, в скрипт этой транзакции должна быть встроена условная конструкция. Это реализуют при помощи функции XOR (исключающего или), соответствующей показанной на фиг. 2 таблице истинности, со ссылками на фиг. 9-11: • если ни А ни В не находятся у кормушки, не выдавать корм;
• если А у кормушки, а В - нет, выдать корм;
• если В у кормушки, а А - нет, выдать корм;
• если и А, и В у кормушки, не выдавать корм.
Когда А или В находятся у кормушки RFID-сигнал передается в систему 104 управления автоматической кормушкой из соответствующего клиентского устройства, т.е. первого RFID-ошейника 102а или второго RFID-ошейника 102Ь, и решение текущего защитного "паззла" этой собаки разблокируется (оно безопасным образом заменяется на новое решение паззла после каждой итерации). Если А или В не находятся у кормушки, вместо этого от соответствующего RFID-ошейника в кормушку передается случайное число. Другими словами, нахождение собаки "у кормушки" означает, что RFID-ошейник находится в зоне обнаружения кормушки. Если это так, соответствующий паззл разблокируют для передачи. Если нет, значением по умолчанию является случайное число.
В соответствии с существующим уровнем техники, решением паззла являются данные, которые, при хэшировании, дают в результате значение, обеспечивающее совпадение при сравнении с хранимым в (Bitocoin-) скрипте значением. То есть, процедура имеет следующий вид: секретное значение ("решение") хэшируют и сохраняют в блокирующем скрипте для последующего сравнения. Для разблокировки блокирующего скрипта секрет передают в него через разблокирующий скрипт (скрипт погашения). Передаваемое значение хэшируют и затем сравнивают с хранимым хэш-значением. Если сравнение показывает, что они равны, то результатом сравнения будет истина ('TRUE'). На практике хранимым значением является двойной хэш секрета, а передаваемым значением является одинарный хэш секрета. Это позволяет свести секрет любой длины до стандартного удобного размера для ввода в скрипт (т.е. всегда длиной 160 бит).
ВШ-устройство автокормушки исполняет свои инструкции, которое оно получает из DHT-таблицы с использованием ключа поиска, относящегося к паре ключей ВШ-устройства. Управляющий агент администрирует поток данных из ВШ-устройства и в него (т.е. данных, относящихся к RFID-сигналам, а не к набору инструкций ВШ-устройства). То есть, ВШ-устройство автокормушки осуществляет мониторинг собственного состояния. Оно хранит два секретных значения (S1 и S2), принятых от другого управляющего агента 103. Управляющим агентом 103 может быть соответствующим образом запрограммированный вычислительный ресурс, сконфигурированный для надзора за процедурой кормления. Секретные значения S1 и S2
используют на основании обнаружения RFID-ошейников собак в пределах рабочей дальности. На основе инструкций, полученных из соответствующей DHT-таблицы, при обнаружении RFID-идентификатора в пределах рабочей дальности (и в зависимости также от других условий, связанных с временем суток; количеством предыдущих кормлений, другими ограничениями и т.п.) устройство передает сигнал универсальному агенту, выступающему в роли управляющего агента (см. ниже). Такой сигнал включает:
• S1 (= решение паззла А, ), если обнаружен RFID-идентификатор Архимеда, в противном случае - случайное число;
• S2 (= решение паззла В, ), если обнаружен RFID-идентификатор Бертрана, в противном случае - случайное число.
Затем ВШ-устройство автокормушки выполняет следующее:
• автокормушка проверяет наличие действительной транзакции в сети (которая не обязательно должна быть опубликована в блокчейне, однако должна быть действительной); эту транзакцию формирует и рассылает управляющий агент; она является действительный, если пройдена встроенная проверка XOR; если такая проверка не пройдена, то она будет недействительной и не будет распространена далее первого интервала передачи сети ("хопа"); то есть, она не будет обнаружена ВШ-устройством; или, если ВШ-устройство находится в первом хопе, и значит, транзакция будет обнаружена, одной из функций ВШ-устройства (как и любого другого узла) является валидация транзакции; поэтому оно будет способно установить действительность транзакции до того, как предпринимать дальнейшие действия; наличие действительной транзакции гарантирует также, что вся требуемая информация, например, относящаяся к событию кормления, записана и сохранена в блокчейне;
• если результатом валидации является TRUE (истина), то ВШ-устройство выполняет соответствующую инструкцию, в противном случае - выдает порцию корма;
• принимает сообщение от управляющего агента 103, что позволяет ему обменяться двумя секретными значениями (S1 и S2, в соответствии с приведенным ниже описанием), и обновляет внутри себя эти секретные значения, готовясь к следующей итерации.
Блокирующий скрипт Биткойн-транзакции определен следующим образом:
OPHASH160 OPEQUAL OP SWAP
OP HASH160 OP EQUAL
OP NUMEQUAL OP NOT OP VERIFY
OP1 metadatal PubK-Carol OP 2 OP CHECKMULTSIG
где:
Puzzle-A - эквивалентный результат OP_HASH160(Puzzle-A-Solution); Puzzle-B - эквивалентный результат OP_HASH160(Puzzle-B-Solution) Metadatal содержат ссылку на зашифрованные инструкции, хранимые в DHT-таблице.
PubK-Carol - публичный ключ Кэрол.
Следует отметить, что программа агента может быть неизменяемой (жестко запрограммированной), или агент может также получать собственные инструкции из DHT-таблицы.
Хранение зашифрованных инструкций и доступ к ним может выполняться в соответствии с рассмотренной ниже процедурой ссылки на контракт из блокчейн-транзакции с использованием метаданных.
Публичный ключ Кэрол может удерживаться в секрете или восстанавливаться с помощью описанной ниже процедуры.
Для разблокирования блокчейн-транзакции, пример которой был рассмотрен выше, потребуется следующий скрипт:
Sig-Carol Puzzle-B-solution Puzzle-A-Solution разблокирующий скрипт>
Описанные ниже шаги проиллюстрированы на фиг. 3.
Система 104 управления выполнена с возможностью хэширования предоставленного решения puzzle-A и сравнения его с хранимым вариантом puzzle-A (здесь этот вариант является хэш-значением решения), который извлекают из хранилища на шаге S300. Хранимый вариант puzzle-A может содержаться в локальном хранилище системы 104 управления или на любом другом подходящем носителе данных. Если они равны, то вершина стека = 1, а если они отличаются, вершина стека = 0.
Вершину стека затем, на шаге S302, меняют местами со вторым элементом в стеке, который представляет собой решение puzzle-B. Его хэшируют и сравнивают с хранимым
вариантом puzzle-B, который извлекают из хранилища, снова помещая 1 или 0 на вершину стека, аналогично шагу S300. Хранимый вариант puzzle-B может содержаться в локальном хранилище системы 104 управления или на любом другом подходящем носителе данных.
В этот момент два верхних элемента стека равны 0 или 1 каждый. На шаге S304 OP_NUMEQUAL возвращает 1, если эти числа равны, и 0 в противном случае, что является полной инверсией таблицы истинности XOR.
На шаге S306 функция OPNOT инвертирует верхний элемент стека, в результате чего получается требуемый результат XOR.
На шаге S308 функция OPVERIFY проверяет, равен ли верхний элемент стека 1, и если это не так, то есть, если операция XOR дала ложный результат, транзакцию немедленно помечают как недействительную, поскольку на более чем один вход от первого и второго клиентских устройств поступило правильное решение паззла. В результате корм не выдается из ЮТ-кормушки, поскольку у нее находится более одной собаки. То есть, выходной сигнал системы 104 управления управляется исполнением соответствующей Биткойн-транзакции.
Если OP VERIFY возвращает 1, то обработка данных в системе 104 управления возвращается к сегменту multi-sig скрипта, где на шаге S310 проверяют наличие подписи Кэрол.
Операции со стеком, выполняемые системой 104 управления при анализе разблокирующего скрипта, описаны ниже. Сначала система 104 хэширует разблокирующий скрипт, чтобы сравнить хэш-значение с хэш-значением разблокирующего скрипта с помощью OP EQUAL. Затем разблокирующий скрипт исполняют.
Стек
Скрипт
Описание
Пусто
Sig-Carol Puzzle-B-solution
Puzzle-A-Solution
OP_HASH160
OP_EQUAL OP_SWAP
OP_HASH160
OP_EQUAL
OP NUMEQUAL OP_NOT
OP_VERIFY
OP_l metadatal PubK-Carol OP_2
OP_CHECKMULTSIG
Sig-Carol Puzzle-B-solution
OP_HASH160
Данные добавляют в стек
Puzzle-A-Solution
OP_EQUAL OP_SWAP OP_HASH160 OP_EQUAL
OPNUMEQUAL OP NOT OP_VERIFY
OP_l metadatal PubK-Carol OP_2 OP_CHECKMULTSIG
Sig-Carol Puzzle-B-solution Puzzle-A-Solution-hashed

OP_EQUAL OP_SWAP OP_HASH160 OP_EQUAL
OP NUMEQUAL OP_NOT OP_VERIFY
OP_l metadatal PubK-Carol OP_2 OP_CHECKMULTSIG
Хэшируют элемент на вершине стека
Sig-Carol Puzzle-B-solution
Puzzle-A-Solution-hashed

OP_EQUAL OP_SWAP OP_HASH160 OP_EQUAL
OP NUMEQUAL OP_NOT OP_VERIFY
OP_l metadatal PubK-Carol OP_2 OP_CHECKMULTSIG
Заданное хэш-значение (puzzle-A) помещают на вершину стека
Sig-Carol Puzzle-B-solution FALSE
OP_SWAP
OP_HASH160 OP_EQUAL
OP NUMEQUAL OP_NOT OP_VERIFY
OP_l metadatal PubK-Carol OP_2 OP_CHECKMULTSIG
Сравнивают два верхних элемента и результат (FALSE) помещают на вершину стека
Sig-Carol FALSE Puzzle-B-solution
OP_HASH160 OP_EQUAL
OP NUMEQUAL OP_NOT OP_VERIFY
OP_l metadatal PubK-Carol OP_2 OP_CHECKMULTSIG
Два верхних элемента стека меняют местами
Sig-Carol FALSE Puzzle-B-solution-hashed
OP_EQUAL
OP NUMEQUAL OP_NOT OP_VERIFY
Хэшируют элемент на вершине стека
OP_l metadatal PubK-Carol OP_2 OP_CHECKMULTSIG
Sig-Carol FALSE
Puzzle-B-solution-hashed

OP_EQUAL
OP NUMEQUAL OP NOT OP_VERIFY
OP_l metadatal PubK-Carol OP_2 OP_CHECKMULTSIG
Заданное хэш-значение (puzzle-B) помещают на вершину стека
Sig-Carol FALSE TRUE
OP NUMEQUAL OP_NOT OP_VERIFY
OP_l metadatal PubK-Carol OP_2 OP_CHECKMULTSIG
Сравнивают два верхних элемента и результат (TRUE) помещают на вершину стека
Sig-Carol FALSE
OP_NOT OP_VERIFY
OP_l metadatal PubK-Carol OP_2
OP_CHECKMULTSIG
Сравнивают два верхних числа (0 или 1) и результат (FALSE) помещают на вершину стека
Sig-Carol TRUE
OP_VERIFY
OP_l metadatal PubK-Carol OP_2 OP_CHECKMULTSIG
Верхний элемент стека инвертируют (превращают из FALSE=0 в TRUE=1)
Sig-Carol
OP_l metadatal PubK-Carol OP_2 OP_CHECKMULTSIG
Проверяют верхний элемент стека Поскольку он равен TRUE, транзакцию (пока) не помечают как не действительную, и продолжают выполнение скрипта
TRUE
Пусто
Проверка Multi-sig прошла успешно
Создание ключа с использованием разделяемого секрета
Ключ может удерживаться в секрете или воссоздаваться. В частности, в случае приватного ключа, который используют для вычисления публичного ключа, приватный ключ может храниться по частям.
Пользователь, т.е. Алиса или Боб, могут хранить одну из частей своего приватного ключа, поставщик услуг может хранить вторую часть, а третья часть может храниться в удаленном защищенном хранилище. Приватный ключ может быть восстановлен с использованием любых двух из этих трех частей, или, в общем случае, приватный ключ, может быть восстановлен с использованием любых m из п частей.
Если приватный ключ может быть восстановлен, он может использоваться для воссоздания публичного ключа в момент использования, и затем приватный ключ и публичный ключ могут снова отбрасываться после применения.
Разбиение приватных ключей может выполняться с использованием схемы разделения секрета Шамира. Пары из приватного и публичного ключей могут вычисляться детерминированно на основе мастер-ключа с помощью описанного ниже способа. Этот способ позволяет участникам получить общие секретные значения без их передачи.
Система позволяет формировать публичный ключ для участника с помощью описанного ниже способа формирования подключей.
На фиг. 4 показана система 1, которая включает первый узел 3, осуществляющий связь со вторым узлом 7 по сети 5 связи. Первый узел 3 имеет ассоциированное с ним первое процессорное устройство 23 обработки данных, а второй узел 5 имеет ассоциированное с ним второе процессорное устройство 27. Первый и второй узлы 3, 7 могут включать электронное устройство, например, компьютер, телефон, планшетный компьютер, устройство мобильной связи, компьютерный сервер и т.п. В одном из примеров первый узел 3 может быть клиентским (пользовательским) устройством, а второй узел 7 может быть сервером. Сервер может принадлежать поставщику услуг цифрового кошелька.
Первый узел 3 ассоциирован с первой асимметричной криптографической парой, включающей приватный мастер-ключ (Vic) первого узла и публичный мастер-ключ (Pic) первого узла. Второй узел (7) ассоциирован со второй асимметричной криптографической парой, включающей приватный мастер-ключ (Vis) второго узла и публичный мастер-ключ (Pis) второго узла. Другими словами, и первый, и второй узел, имеют соответствующие пары из публичного и приватного ключей.
Первая и вторая асимметричные криптографические пары, соответственно, для первого и второго узлов 3, 7 могут быть сформированы в ходе процедуры регистрации, например, регистрации цифрового кошелька. Публичный ключ для каждого узла может находиться в публичном доступе, например, быть доступен по сети 5 связи.
Для определения общего секрета (CS) и в первом узле 3, и во втором узле 7, узлы 3,7 выполняют шаги соответствующих способов 300, 400, не подразумевающих передачу приватных ключей по сети связи 5.
Способ 300, выполняемый первым узлом 3, включает определение 330 второго приватного ключа (Угс) первого узла на основе по меньшей мере приватного мастер-ключа (Vic) первого узла и значения генератора (GV). Значение генератора может быть основано на сообщении (М), которым обмениваются первый и второй узел, что может
включать обмен сообщением по сети 5 связи, в соответствии с последующим более подробным описанием. Способ 300 включает также определение 370 второго публичного ключа (P2s) второго узла на основе по меньшей мере публичного мастер-ключа (Pis) второго узла и значения генератора (GV). Способ 300 включает определение (шаг 380) общего секрета (CS) на основе второго приватного ключа (Угс) первого узла и второго публичного ключа (P2s) второго узла,
Важно отметить, что при помощи способа 400 во втором узле 7 может быть сформирован идентичный общий секрет (CS). Способ 400 включает определение 430 второго публичного ключа (Ргс) первого узла на основе по меньшей мере публичного мастер-ключа (Pic) первого узла и значения генератора (GV). Способ 400 включает также определение 470 второго приватного ключа (V2s) второго узла на основе по меньшей мере приватного мастер-ключа (Vis) второго узла и значения генератора (GV). Способ 400 включает определение (шаг 480) общего секрета (CS) на основе второго приватного ключа (V2s) второго узла и второго публичного ключа (Ргс) первого узла.
Сеть 5 связи может включать локальную сеть, глобальную сеть, сотовые сети, сеть радиосвязи, Интернет и т.п. Такие сети, где данные передают по таким средам связи как электрические провода, оптоволокно или беспроводным способом, уязвимы к прослушиванию которое, например, может вести перехватчик 11. Способ 300, 400 позволяют первому узлу 3 и второму узлу 7 независимо определять общий секрет без передачи общего секрета по сети 5 связи. Таким образом, одно из преимуществ заключается в том, что общий секрет (CS) может быть определен безопасно и независимо каждым узлом, без необходимости передачи приватных ключей по потенциально небезопасной сети 5 связи. В свою очередь, общий секрет может использоваться в качестве секретного ключа (или в качестве основы для секретного ключа).
Способ 300, 400 может включать и другие дополнительные шаги. Рассмотрим фиг. 8. Способ 300 может включать, в первом узле 3, формирование первого подписанного сообщения (SM1) на основе сообщения (М) и второго приватного ключа (V2C) первого узла. Способ 300 также включает передачу (шаг 360) первого подписанного сообщения (SM1) по сети связи во второй узел 7. В свою очередь, второй узел 7 может выполнять шаги приема (шаг 440) первого подписанного сообщения (SM1). Способ 400 включает также шаг валидации (шаг 450) первого подписанного сообщения (SM2) с использованием второго публичного ключа (Р2С) первого узла и аутентификации (шаг 460) первого узла 3 в зависимости от результата валидации первого подписанного сообщения (SM1). Это дает
возможность второму узлу 7 точно убедиться, что предполагаемый первый узел (где было сформировано первое подписанное сообщение) действительно является первым узлом 3. Это основано на допущении, что только первый узел 3 имеет доступ к приватному мастер-ключу (Vic) первого узла, и соответственно, только первый узел 3 может определить второй приватный ключ (Угс) первого узла для формирования первого подписанного сообщения (SM1). Нужно понимать, что, аналогично, второе подписанное сообщение (SM2) может формироваться во втором узле 7 и передаваться в первый узел 3, так что первый узел 3 может аутентифицировать второй узел 7, например, в сценарии связи точка-точка.
Обмен сообщением (М) между первым и вторым узлами может выполняться множеством различных способов. В одном из примеров это сообщение может формироваться в первом узле 3 и затем передаваться по сети 5 связи во второй узел 7. Альтернативно, сообщение может формироваться во втором узле 7 и затем передаваться, по сети 5 связи во второй узел 7. В некоторых примерах сообщение (М) может быть публичным, и соответственно, может передаваться по небезопасной сети 5. Одно или более сообщений (М) могут храниться в хранилище 13, 17, 19 данных. Специалисты в данной области техники должны понимать, что обмен сообщения может выполняться множеством различных способов.
Преимуществом является то, что запись, обеспечивающая восстановление общего секрета (CS), может храниться таким образом, что она сама не требует секретного хранения или безопасной передачи.
Способ 100, 200 регистрации
Далее со ссылками на фиг. 6 будет рассмотрен один из примеров способа 100, 200 регистрации, причем способ 100 выполняется первым узлом 3, а способ 200 выполняется вторым узлом 7. Способ включает создание первой и второй асимметричных криптографических пар, соответственно, для первого и второго узла 3, 7.
Эти асимметричные криптографические пары содержат связанные друг с другом приватные и публичные ключи, например, применяемые в криптографии с открытым ключом. В данном примере асимметричные криптографические пары создают с помощью криптографии на базе эллиптических кривых (ЕСС) и свойств операций над эллиптическими кривыми.
В способе 100, 200 это включает: соглашение (шаг 110, 210) между первым и вторым узлом об общей ЕСС-криптосистеме и об использовании базовой точки (G). (Примечание: базовая точка может также называться общим генератором, однако чтобы исключить смешение со значением генератора (GV), будет использоваться термин "базовая точка"). В одном из примеров упомянутая общая система ЕСС-криптографии может быть основана на криптосистеме ЕСС secp256Kl, применяемой для криптовалюты Биткойн. Базовая точка (G) может выбираться, формироваться случайно или назначаться.
Рассмотрим первый узел 3: способ 100 включает соглашение (шаг 110) об общей ЕСС-криптосистеме и базовой точке (G). Это может включать прием общей ЕСС-криптосистемы и базовой точки от второго узла 7 или третьего узла 9. Альтернативно, с первым узлом 3 может быть связан пользовательский интерфейс 15, при помощи которого пользователь может, с возможностью выбора, задавать общую систему ЕСС-криптографии и/или базовую точку (G). В еще одном альтернативном примере система ЕСС-криптографии и/или базовая точка могут выбираться в первом узле 3 случайным образом. Первый узел 3 может передавать, по сети связи 5, уведомление, указывающее на использование общей ЕСС-криптосистемы с базовой точкой (G), во второй узел 7. В свою очередь второй узел 7 может подтвердить (шаг 210) соглашение, передав уведомление о согласии на использование общей ЕСС-криптосистемы и базовой точки (G).
Способ 100 включает также формирование (шаг 120), первым узлом 3, первой асимметричной криптографической пары, которая включает приватный мастер-ключ (Vic) первого узла и публичный мастер-ключ (Pic) первого узла. Это включает формирование приватного мастер-ключа (Vic) первого узла на основе случайного целого числа в разрешенном диапазоне, заданном в общей ЕСС-криптосистеме. Это также включает определение публичного мастер-ключа (Pic) первого узла на основе умножения точек на эллиптической кривой для приватного мастер-ключа (Vic) первого узла и базовой точки (G) согласно следующей формуле:
Pic = Vic х G (Уравнение 1)
Таким образом, первая асимметричная криптографическая пара включает:
Vic: приватный мастер-ключ первого узла, который удерживается первым узлом в секрете.
Pic: публичный мастер-ключ первого узла, который предоставляется в общий доступ.
Первый узел может хранить приватный мастер-ключ (Vic) первого узла и публичный мастер-ключ (Pic) первого узла в первом хранилище 13 данных, связанным с первым узлом 3. В целях безопасности приватный мастер-ключ (Vic) первого узла может храниться в защищенной области первого хранилища 13 данных, чтобы гарантировать его приватность.
Способ 100 включает также передачу (шаг 130) публичного мастер-ключа (Pic) первого узла по сети связи 5 во второй узел 7, в соответствии с иллюстрацией фиг. 6. Второй узел 7 может, после приема (шаг 220) публичного мастер-ключа (Pic) первого узла, сохранять (шаг 230) публичный мастер-ключ (Pic) первого узла во втором хранилище 17 данных, связанном со вторым узлом 7.
Аналогично первому узлу 3, способ 200 для второго узла 7 включает формирование (шаг 240) второй асимметричной криптографической пары, которая включает приватный мастер-ключ (Vis) второго узла и публичный мастер-ключ (Pis) второго узла. Приватный мастер-ключ (Vis) второго узла также является случайным целым числом в разрешенном диапазоне. В свою очередь, публичный мастер-ключ (Pis) второго узла определяют при помощи следующей формулы:
Pis = Vis х G (Уравнение 2)
Таким образом, вторая асимметричная криптографическая пара включает:
Vis : приватный мастер-ключ второго узла, который удерживается вторым узлом в секрете.
Pis: публичный мастер-ключ второго узла, который предоставляется в общий доступ.
Второй узел 7 может сохранять вторую асимметричную криптографическую пару во втором хранилище 17 данных. Способ 200 включает также передачу (шаг 250) публичного мастер-ключа (Pis) второго узла в первый узел 3. В свою очередь, первый узел 3 может принимать (шаг 140) и сохранять (шаг 150) публичный мастер-ключ (Pis) второго узла.
Нужно понимать, что в альтернативных примерах соответствующие публичные мастер-ключи могут приниматься и сохраняться в третьем хранилище 19 данных, связанном с третьим узлом 9 (например, принадлежащем доверенному третьему лицу). Это подразумевает наличие третьей стороны, выступающей в роли публичного реестра, например, центра сертификации. Таким образом, в некоторых из примеров, публичный
мастер-ключ (Pic) первого узла может запрашиваться и приниматься вторым узлом 7, только когда требуется определить общий секрет (CS) (и наоборот).
Шаги регистрации могут выполняться лишь единожды, например, при первоначальной настройке цифрового кошелька.
Установление сеанса и определение общего секрета первым узлом 3 Далее со ссылками на фиг. 7 будет рассмотрен один из примеров определения общего секрета (CS). Общий секрет (CS) может использоваться для конкретного сеанса, времени, транзакции между первым узлом 3 и вторым узлом 7, или для других целей, при этом использование всегда одного и того же общего секрета (CS) может быть нежелательным или небезопасным. То есть, общий секрет (CS) может быть различным в различных сеансах, в различные моменты времени для различных транзакций и т.п.
Ниже рассмотрена иллюстрация способа безопасной передачи, описанного выше.
Формирование сообщения (М) (шаг 310)
В данном примере способ 300, выполняемый первым узлом 3, включает формирование (шаг 310) сообщения (М). Сообщение (М) может быть случайным, псевдослучайным или задаваемым пользователем. В одном из примеров сообщение (М) основано на времени UNIX и текущем времени (а также произвольно задаваемом значении). К примеру, сообщение (М) может быть получено в следующем виде: Сообщение (М) = Время1МГХ + ТекущееВремя (Уравнение 3)
В некоторых из примеров сообщение (М) задают произвольным образом. Однако нужно понимать, что сообщение (М) может также иметь выбираемые значения (например, время UNIX и т.п.), что может быть удобным в некоторых применениях.
Способ 300 включает передачу (шаг 315) сообщения (М) по сети 5 связи во второй узел 7. Сообщение (М) может передаваться по небезопасной сети, поскольку оно не содержит никакой информации о приватных ключах.
Определение значения генератора (GV) (шаг 320)
Способ 300 включает также шаг 320 определения значения генератора (GV) на основе сообщения (М). В данном примере это включает определение криптографического хэш-значения для сообщения. Одним из примеров алгоритмов криптографического
хэширования является SHA-256, позволяющий получить 256-битное значение генератора (GV). То есть:
GV = SHA-256(M) (Уравнение 4)
Нужно понимать, что могут применяться и другие алгоритмы хэширования. Они могут включать другие алгоритмы хэширования из семейства безопасных алгоритмов хэширования (Secure Hash Algorithm, SHA). Конкретные примеры включают члены подмножества алгоритмов SHA-3, например, SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256. Могут применяться и другие алгоритмы, например, из семейства алгоритмов дайджестов сообщений оценки примитивов целостности RACE (RACE Integrity Primitives Evaluation Message Digest, RIPEMD). Конкретным примером может быть алгоритм RIPEMD-160. Другими хэш-функциями могут быть семейства на базе хэш-функции Земора-Тиллиха и "ранцевых" (Меркла-Хеллмана) хэш-функций.
Определение второго приватного ключа первого узла (шаг 330) Способ 300 включает шаг 330 определения второго приватного ключа (Угс) первого узла на основе по меньшей мере приватного мастер-ключа (Vic) первого узла и значения генератора (GV). Это может быть основано на скалярном сложении приватного мастер-ключа (Vic) первого узла и значения генератора (GV) согласно следующей формуле:
V2C = Vic + GV (Уравнение 5)
То есть, второй приватный ключ (Угс) первого узла не является случайным значением, а напротив, детерминированно вычисляемым на основе приватного мастер-ключа первого узла. Соответствующей публичный ключ в криптографической паре, а именно, второй публичный ключ (Ргс) первого узла соответствует следующему выражению:
Р2С = V2C х G (Уравнение 6)
Подстановкой V2C из уравнения 5 в уравнение 6 получаем:
Р2с = (Vic + GV) х G (Уравнение 7)
Где, оператор '+' представляет собой сложение точек на эллиптических кривых.
Следует отметить, что алгебра в криптографии на базе электрических кривых
дистрибутивна, и значит, уравнение 7 может быть выражено следующим образом:
Ргс = Vic х G + GV х G (Уравнение 8)
Наконец, уравнение 1 может быть подставлено в уравнение 7, что дает:
Pic = Pic + GV x G (Уравнение 9.1)
P2c = Pic + SHA-256(M) x G (Уравнение 9.2)
Соответственно, соответствующий второй публичный ключ (Ргс) первого узла может быть вычислен при знании публичного мастер-ключа (Pic) первого узла и сообщения (М). Второй узел 7 может иметь эту информацию и независимо определять второй публичный ключ (Ргс) первого узла, в соответствии с дальнейшим подробным описанием в отношении способа 400.
Формирование (шаг 350) первого подписанного сообщения (SM1) на основе сообщения (М) и второго приватного ключа первого узла;
Способ 300 может включать формирование (шаг 350) первого подписанного сообщения (SM1) на основе сообщения (М) и вычисленного второго приватного ключа (V2C) первого узла. Формирование подписанного сообщения включает применение алгоритма цифровой подписи для цифровой подписи сообщения (М). В одном из примеров это включает применение второго приватного ключа (Угс) первого узла к сообщению в алгоритме цифровой подписи на основе эллиптических кривых (Elliptic Curve Digital Signature Algorithm, ECDSA) с целью получения первого подписанного сообщения (SM1). Примеры ECDSA-алгоритмов включают алгоритмы, основанные на системах ЕСС-криптографии, такие как secp256kl, secp256rl, secp384rl, se3cp521rl.
Первое подписанное сообщение (SMI) может быть верифицировано при помощи соответствующего второго публичного ключа (Ргс) первого узла во втором узле 7. Верификация первого подписанного сообщения (SM1) может использоваться во втором узле 7 для аутентификации первого узла 3, что будет рассмотрено в способе 400 ниже.
Определение второго публичного ключа второго узла (шаг 370') Первый узел 3 может затем определять (шаг 370) второй публичный ключ (P2s) второго узла. Как отмечалось выше, второй публичный ключ (P2s) может быть основан по меньшей мере на публичном мастер-ключе (Pis) второго узла и значении генератора (GV). В данном примере, поскольку публичный ключ определяют (шаг 370') как произведение точек на эллиптической кривой для приватного ключа и базовой точки (G), второй публичный ключ (P2S) второго узла может быть выражен, аналогично уравнению 6, следующим образом:
P2S = V2s х G (Уравнение 10.1)
Pis = Pis + GV x G (Уравнение 10.2)
Математический вывод для уравнения 10.2 аналогичен описанному выше для получения уравнения 9.1 в случае второго публичного ключа (Р2С) первого узла. Нужно понимать, что первый узел 3 может определять (шаг 370) второй публичный ключ второго узла независимо от второго узла 7.
Определение общего секрета (шаг 380) в первом узле 3
Первый узел 3 может затем определять (шаг 380) общий секрет (CS) на основе найденного второго приватного ключа (Угс) первого узла и найденного второго публичного ключа (P2s) второго узла. Общий секрет (CS) может быть определен первым узлом 3 при помощи следующей формулы:
S = V2c х P2s (Уравнение 11)
Выполнение способа 400 во втором узле 7
Далее будет рассмотрен соответствующий способ 400, выполняемый во втором узле 7. Нужно понимать, что некоторые из его шагов аналогичны рассмотренным выше шагам, выполняемым первым узлом 3.
Способ 400 включает прием (шаг 410) сообщения (М) по сети 5 связи от первого узла 3. Оно может представлять собой сообщение (М), переданное первым узлом 3 на шаге 315. Затем второй узел 7 определяет (шаг 420) значение генератора (GV) на основе сообщения (М). Шаг определения (шаг 420) значения генератора (GV) вторым узлом 7 аналогичен описанному выше шагу 320, выполняемому первым узлом. В данном примере второй узел выполняет этот шаг 420 определения независимо от первого узла 3.
Следующий шаг включает определение (шаг 430) второго публичного ключа (Ргс) первого узла на основе по меньшей мере публичного мастер-ключа (Pic) первого узла и значения генератора (GV). В данном примере, поскольку публичный ключ определяют (шаг 430') как произведение точек на эллиптической кривой для приватного ключа и базовой точки (G), второй публичный ключ (Ргс) первого узла может быть выражен, аналогично уравнению 9, следующим образом:
Ргс = V2C х G (Уравнение 12.1)
Р2С = PlC + GV х G (Уравнение 12.2)
Математический вывод уравнений 12.1 и 12.2 аналогичен выводу уравнений 10.1 и 10.2., рассмотренному выше.
Аутентификация первого узла 3 вторым узлом 7
Способ 400 может включать шаги, выполняемые вторым узлом 7 с целью подтверждения того, что предполагаемый узел 3 на самом деле им является. Как излагалось выше, это включает прием (шаг 440) первого подписанного сообщения (SM1) от первого узла 3. Второй узел 7 может затем выполнить валидацию (шаг 450) подписи под первым подписанным сообщением (SM1) с использованием второго публичного ключа (Р2С) первого узла, который был найден на шаге 430.
Валидация цифровой подписи может быть проведена согласно упоминавшемуся ранее алгоритму цифровой подписи на основе эллиптических кривых (ECDSA). Следует отметить, что первое подписанное сообщение (SM1), которое было подписано вторым приватным ключом (Угс) первого узла, может успешно пройти валидацию только при наличии соответствующего второго публичного ключа (Ргс) первого узла, поскольку ключи V2C и Ргс являются криптографической парой. Поскольку эти ключи определяются однозначно приватным мастер-ключом первого узла (Vic) и публичным мастер-ключом (Pic) первого узла, который был сформирован при регистрации первого узла 3, верификация первого подписанного сообщения (SM1) может использоваться как основное подтверждение того, что предполагаемый первый узел, передавший первое подписанное сообщение (SM1), является тем же самым, что и первый узел 3 в ходе регистрации. Поэтому второй узел 7 может затем выполнять шаг аутентификации (шаг 460) первого узла на основе результата валидации (шаг 450) первого подписанного сообщения.
Определение общего секрета вторым узлом 7
Способ 400 может также включать определение (шаг 470) второго приватного ключа (V2s) второго узла на основе по меньшей мере приватного мастер-ключа (Vis) второго узла и значения генератора (GV). Аналогично шагу 330, выполняемому первым узлом 3, второй приватный ключ (V2s) второго узла может быть получен скалярным сложением приватного мастер-ключа (Vis) второго узла и значения генератора (GV) согласно следующим формулам:
V2S = Vis + GV (Уравнение 13.1)
V2S = Vis + SHA-256(M) (Уравнение 13.2)
Затем второй узел 7 может, независимо от первого узла 3, определять (шаг 480) общий секрет (CS) на основе второго приватного ключа (V2s) второго узла и второго публичного ключа (Р2с) первого узла согласно следующей формуле:
S = V2c х P2s (Уравнение 14)
Доказательство идентичности общих секретов (CS), определяемых первым узлом 3 и вторым узлом 7
Общий секрет (CS), определяемый первым узлом 3, идентичен общему секрету (CS), определяемому во втором узле 7. Ниже будет приведено математическое доказательство того, что уравнение 11 и уравнение 14 дают один и тот же общий секрет (CS).
Рассмотрим общий секрет (CS), определяемый первым узлом 3. Уравнение 10.1 может быть подставлено в уравнение 11 следующим образом:
S = V2c х P2s (Уравнение 11)
S = V2Cx(V2SxG)
S = (V2c x V2s) x G (Уравнение 15)
Рассмотрим общий секрет (CS), определяемый вторым узлом 7. Уравнение 12.1 может быть подставлено в уравнение 14 следующим образом:
S = V2c х P2s (Уравнение 14)
S = V2Cx(V2SxG)
S = (V2c x V2s) x G (Уравнение 16)
Алгебра ЕСС-криптографии коммутативна, и поэтому уравнения 15 и 16 эквивалентны, поэтому:
S = (V2C х V2S) х G = (V2S x V2C) x G (Уравнение 17)
Общий секрет (CS) и секретный ключ
Общий секрет (CS) затем может использоваться в качестве секретного ключа или в качестве основы секретного ключа в алгоритме с симметричным ключом для безопасной связи между первым узлом 3 и вторым узлом 7.
Общий секрет (CS) может иметь вид точки (xs, ys) на эллиптической кривой. Он может быть преобразован в стандартный формат ключа с использованием стандартных и общеизвестных операций, по которым узлы 3, 7 достигли соглашения. К примеру, значение х$ может быть 256-битным целым числом, которое может использоваться как
ключ шифрования AES256- Он может также быть преобразован в 160-битное целое число при помощи алгоритма RIPEMD160 для любых операций, в которых требуется ключ такой длины.
Общий секрет (CS) может определяться по необходимости. Важно отметить, что первый узел 3 не должен хранить общий секрет (CS), поскольку он всегда может быть снова определен на основе сообщения (М). В некоторых примерах используемое сообщение (или сообщения) (М) может храниться в хранилище 13, 17, 19 данных (или в ином хранилище данных), не обладающем уровнем безопасности, достаточном для хранения приватных мастер-ключей. В некоторых примерах сообщение (М) может быть публично доступным. Однако, в зависимости от приложения, общий секрет (CS) может храниться в первом хранилище (X) данных, относящемся к первому узлу, при условии, что общий секрет (CS) защищен так же, как приватный мастер-ключ (Vic) первого узла.
Данный способ может использоваться для определения множества общих секретов, которые могут соответствовать множеству секретных криптографических ключей, основанных на одной криптографической паре мастер-ключей.
Иерархия значений генератора (ключей)
К примеру, может быть вычислена цепь последовательных значений генератора (GV), в которой каждое последующее значение генератора может определяться на основе предшествующего значения генератора (GV). К примеру, вместо повторения шагов 310-370 и 410-470 для формирования последовательных одноцелевых ключей, по предварительному соглашению между узлами ранее используемое значение генератора (GV) может многократно повторно хэшироваться обеими сторонами связи, в результате чего получают иерархию значений генератора. Фактически, значение генератора, основанное на хэш-значении сообщения (М), может быть сообщением (М') следующего поколения для значения генератора (GV) следующего поколения. Это позволяет последовательно вычислять последовательные "поколения" общих секретов, без необходимости передачи дополнительных данных, связанных с установлением соединения по протоколу, в частности, без передачи множества сообщении при формировании каждого нового общего секрета. Ниже будет рассмотрено вычисление общего секрета (CS') следующего поколения.
Для начала, и первый узел 3, и второй узел 7 независимо определяют следующее поколение значения генератора (GV). Это выполняется аналогично шагам 320 и 420, однако адаптировано согласно следующим формулам:
М' = SHA-256(M) (Уравнение 18)
GV = SHA-256(M') (Уравнение 19.1)
GV = SHA-256(SHA-256(M)) (Уравнение 19.2)
Первый узел 3 может затем определить следующее поколение второго публичного ключа (P2s') второго узла и второго приватного ключа (V2c') первого узла аналогично описанным выше шагам 370 и 330, которые адаптированы согласно следующим формулам:
Pis' = Pis + GV х G (Уравнение 20.1)
V2C' = Vic + GV (Уравнение 20.2)
Второй узел 7 может затем определить следующее поколение второго публичного ключа (Р2с') второго узла и второго приватного ключа (Vs') второго узла аналогично описанным выше шагам 430 и 470, которые адаптированы согласно следующим формулам:
Р2с = Pic + GV х G (Уравнение 21.1)
V2S' = Vis + GV (Уравнение 21.2)
Затем каждый из узлов, первый узел 3 и второй узел 7, может определять общий секрет (CS') следующего поколения. А именно, первый узел 3 определяет общий секрет (CS') следующего поколения с помощью следующей формулы:
CS' = V2C' х P2S' (Уравнение 22)
Второй узел 7 определяет общий секрет (CS') следующего поколения с помощью следующей формулы:
CS' = V2C' х P2S' (Уравнение 23)
Дальнейшие поколения (CS", CS'" и т.д.) могут вычисляться аналогично, в результате чего получают их цепочечную иерархию. Такой способ подразумевает, что и первый узел 3, и второй узел 7 должны сохранять информацию об исходном сообщении (М) или исходно вычисленном значении генератора (GV), а также о том, какому узлу они соответствуют. Эта информация является публичной, и поэтому ее хранение не несет рисков, связанных с безопасностью. Соответственно, такая информация может храниться в "хэш-таблицах" (связывающих хэш-значения с публичными ключами) и свободно распространяться по сети 5 (например, с использованием сети Torrent). При этом если
любой отдельный общий секрет (CS) в иерархии будет раскрыт, это не повлияет на степень безопасности всех других общих секретов в иерархии, если приватные ключи Vic, Vis останутся в секрете.
Структура ключей
Помимо цепочечной (линейной) иерархии, описанной выше, может создаваться также древообразная иерархическая структура. В древообразной структуре могут быть определено множество различных ключей, служащих различным целям, например, ключи аутентификации, ключи шифрования, ключи подписи, ключи платежей, при этом все эти ключи связаны с единым мастер-ключом, удерживаемым в секрете. Лучшим образом это проиллюстрировано на фиг. 12, где показано древообразная структура 901 с множеством различных ключей. Каждый из них может использоваться для формирования общего секрета с другой стороной связи. Ветвление может обеспечиваться несколькими различными способами, три из которых будут рассмотрены ниже.
(i) Размножение мастер-ключа
В цепочечной иерархии каждое новое "звено" (пару из публичного и приватного ключа) формируют, суммируя многократно повторно хэшированное сообщение (М) с исходным мастер-ключом. К примеру, (для ясности проиллюстрируем только приватный ключ первого узла 3):
V2S = Vis + SHA-256(M) (Уравнение 24)
V2C' = Vic + SHA-256(SHA-256(M)) (Уравнение 25) V2C" = Vic + SHA-256(SHA-256(SHA-256(M))) (Уравнение 26) ... и т.д.
Чтобы сформировать ответвление, любой из ключей может использоваться в качестве суб-мастер-ключа. К примеру, V2c' может использоваться в качестве суб-мастер-ключа (Узе) в результате добавления к нему хэш-значения, как это делается в случае обычного мастер-ключа.
V3C = V2C' + SHA-256(M) (Уравнение 27)
Суб-мастер-ключ (Узе) может, в свою очередь, также иметь ключ (Узс'Х следующего поколения, например:
Узе' = V2C' + SHA-256(SHA-256(M)) (Уравнение 28)
В результате получают древообразную структуру 903, используя способ размножения подписанного сообщения, проиллюстрированный на фиг. 13.
(и) Логическое связывание
В данном способе все узлы дерева (пары публичный/приватный ключ) формируют в виде цепочек (или другим образом), а все логические соотношения между узлами дерева хранят в таблице, где каждый узел дерева напрямую связан со своим родительским узлом в дереве при помощи указателя. То есть, указатель может использоваться для определения соответствующих пар из публичного и приватного ключа при определении общего секрета (CS) для сеанса связи.
(Ш) Множественность сообщений
Новые пары из публичного и приватного ключей могут формироваться за счет введения нового сообщения в любой точке цепочечной или древообразной структуры. Само сообщение может быть произвольным, или может нести некоторое значение, или функцию (например, может относиться к "реальному" номеру банковского счета и т.п.) Может быть желательным, чтобы такие новые сообщения для формирования новых пар из публичного и приватного ключей хранились защищенно.
Схема кодификации
Метаданные транзакции могут использоваться для доступа к инструкциям, хранящимся в некотором документе вне блока. Такой документ может называться "контрактом". Метаданные, используемые в связи с контрактом, могут иметь множество различных форматов. В данном документе проиллюстрирована лишь одна из возможных схем кодификации.
Контракт является переуступаемым, если права, определяемые им, передаются держателю или владельцу договора. Одним из примеров непереуступаемого контракта является контракт, в котором приведены имена сторон, то есть права отданы конкретно именованному лицу, а не держателю контракта. В данной схеме кодификации рассматриваются только переуступаемые контракты.
Токен - это специальный контракт, который описывает, или определяет, права, предоставляемые этим контрактом. В соответствии с настоящим изобретением токен является представлением контракта в форме Биткойн-транзакции.
В таком способе кодификации применяют метаданные, включающие три параметра или объекта данных. Данные могут указывать на следующее:
i) количество долей (акций), доступных по контракту
(может быть обозначено 'NumShares');
ii) количество единиц, передаваемых отправителем по меньшей мере одному
получателю (может быть обозначено 'ShareVal'); и
iii) коэффициент для вычисления стоимости упомянутого количества
передаваемых единиц (может называться "фиксированным курсом" (pegging rate)).
Одно из преимуществ подобной схемы кодификации заключается в том, что она может использоваться для инкапсуляции, или представления, контрактов в виде токенов в блокчейне с использованием только трех описанных выше параметров. Фактически, контракт может быть определен с использованием, как минимум, только трех этих элементов данных. Поскольку такая схема кодификации может применяться для переуступаемых контрактов любого типа, можно разработать и применять общие для них всех алгоритмы. Ниже приведена дополнительная информация об этих элементах метаданных.
Делимый токен - это токен, в котором сумма на выходе транзакции может быть разбита на меньшие суммы, распределенные по нескольким токенам (т.е. распределенные по нескольким транзакциям). Примером этого является токенизированная бумажная валюта. Делимые контракты - это контракты, для которых указано ненулевое значение PeggingRate. В случае делимых контрактов токенизированная сумма, передаваемая на выходе транзакции, связана с базовым значением в биткоинах (ВТС) через PeggingRate. То есть, контракт определяет права держателя, выраженные в фиксированном курсе. В случае неделимых токенов PeggingRate отсутствует, и контракт определяет права его держателя в виде фиксированной ценности (например, предъявительской облигации: "данный контракт дает право на получение в точности 1000$", или купона: "данный контракт дает право на одну стрижку"). В случае неделимых контрактов, заложенная в контракт сумма ВТС не связана с ценностью контракта.
Выражение "заложенная в контракт сумма ВТС" относится к количеству биткоинов (ВТС), привязанных к выходу транзакции. В протоколе Биткойн каждый выход транзакции, чтобы она считалась действительной, должен иметь ненулевую сумму ВТС. Фактически, эта сумма ВТС должна быть больше некоторого заданного минимума (называемого "пылью"), которое, на момент написание настоящей заявки, составляет 546
сатоши. 1 биткойн определен как равный 100 ООО ООО сатоши. Поскольку Биткойн-транзакции в данном случае используют лишь в качестве средства для обмена правом собственности, фактическая сумма ВТС, лежащая в основе транзакции, может быть любой: истинная ценность контракта определена в его описании. Теоретически, все токены могут иметь ценность "пыли".
В соответствии с предложенной схемой кодификации, если токен делим, то заложенная сумма ВТС, напротив, имеет значение: она связана с ценностью контракта через PeggingRate. PeggingRate же, в свою очередь, может быть произвольной, при этом ее выбирают таким образом, чтобы сохранять заложенную сумму ВТС небольшой. Причина применения PeggingRate вместо закладывания во все транзакции токенов лишь "пыли" заключается в том, что протокол, предложенный в настоящем изобретении, обеспечивает возможность разделения: когда токен разбивают на несколько выходов транзакции с меньшими суммами, не обязательно корректировать исходный контракт. Вместо этого просто вычисляют ценность контракта для каждого полученного в результате разбиения токена, на основе PeggingRate и дробной части заложенной суммы ВТС.
Ограниченный токен - это токен, в котором общая размещенная ценность фиксирована (или "ограничена") фиксированным ненулевым количеством долей, которое определено параметром NumShares. Соответственно, для ограниченного контракта не могут выпускаться новые доли. К примеру, контракт на частичное владение скаковой лошадью ограничен 100% скаковой лошади (например, 100 долей по 1% каждая или 10 долей по 10% каждая и т.п.) Если контракт неограничен, это означает, что его автор может выполнять дополнительное размещение долей, например, добавляя необходимую сумму бумажной валюты на свой резервный счет. Значение NumShares должно быть явно задано во всех контрактах. Ограниченные контракты должны иметь NumShares > 0; неограниченные контракты обозначают, присваивая NumShares = 0.
Типовым примером этому может служить валютный резерв (аналогичный золотому резерву), для которого общая сумма, содержащаяся на резервном банковском счету, должна совпадать с общей ценностью существующих долговых обязательств (т.е. непотраченных токенов). Этот принцип может быть расширен, помимо валютных резервов, на резервы различных видов продукции. К примеру, издатель токенов на лицензированные футболки с принтами может начинать с резервом из 10000 футболок в наличии, и может выпускать делимый токен, представляющий эти 10000 футболок (при этом, например, каждая доля может быть равна одной футболке). Исходный токен может
быть разбит, и каждый полученный в результате деления токен может быть потрачен на футболки, количество которых соответствует сумме ВТС, заложенному в выход транзакции, согласно PeggingRate. Однако, если спрос увеличивается, издатель может принять решение о выпуске дополнительных долей (т.е. увеличить количество долей в обороте, например, еще на 10000). В подобных случаях издатель обязан поместить дополнительные 10000 футболок на свой резервный счет (т.е. на склад), чтобы гарантировать новые выпущенные доли. Таким образом, общее количество футболок на складе (где склад играет роль "резервного счета") в любой момент времени должно быть равно общему количеству непотраченных долей.
PeggingRates применим только для делимых контрактов, где ценность доли (представленная параметром ShareVal) связана с заложенной в контракт суммой ВТС. К примеру, в контракте может быть определено, что издатель обещает обменять токен по курсу $10,000 за каждый заложенный ВТС Это может означать (например), что токен-транзакция с заложенным в выход значением 15400 сатоши может быть потрачена с получением 1,54$. Значение PeggingRate, равное 0, указывает на то, что контракт неделим (т.е. может быть передан только в целом, как предъявительская облигация). Когда PeggingRate равно 0 (что указывает на неделимый токен), заложенная в контракт сумма ВТС не связана с ценностью контракта и может быть любой. Как правило, в этом случае желательно удерживать заложенную сумму ВТС как можно меньшей (т.е. ее назначают равной "пыли"), чтобы минимизировать операционные издержки.
NumShares - это общее (фиксированное) количество долей, доступных по (ограниченному) контракту. В случае ограниченных контрактов NumShares должно быть целым положительным числом. В случае неограниченных контактов NumShares не фиксировано, и в любой момент могут быть выпущены дополнительные доли (при условии, что они гарантированы), на что указывают, присваивая этому параметру значение 0.
Доля - это элементарная единица перевода, при этом ShareVal - ценность такой единицы. К примеру, в случае бумажной валюты, элементарная единица перевода может быть выбрана равной 1 центу. Или, например, она может быть назначена равной 50 центам, и в этом случае переводы могут выполняться только "партиями" по 50 центов. ShareVal может быть также выражена в процентных долях: к примеру, если коннозаводчик хочет продать скаковую лошадь в 10 равных долях, то ShareVal = 10%. ShareVal должна быть больше нуля и должна быть определена в контракте.
Totallssuance определяет общую ценность выпущенных долей. Это значение может быть связано только с ограниченными контрактами, поскольку в случае неограниченных контрактов выпуск не ограничен, и могут выпускаться новые доли. Если доли выражены в процентных долях, то Totallssuance = 100% по определению.
Для ограниченных контрактов NumShares, ShareVal и Totallssuance связаны следующим образом:
NumShares х ShareVal = Totallssuance.
Значение Totallssuance, равное 0, указывает на неограниченный контракт. Одним из примеров неограниченного контракта является бумажная валюта (следовательно, Totallssuance назначают равным 0); примерами ограниченных контрактов являются: (i) памятные монеты ограниченного тиража (1000 отчеканенных, где 1 доля = 1 монета): Totallssuance = 1000 х 1 = 1000 монет; и (ii) сидячие места на концертной площадке с допуском по билетам, при этом Totallssuance будет равном общему количеству имеющихся мест.
Оборот -это общая ценность непотраченных токенов (т.е. определяемая транзакциями с UTXO - непотраченными выходами транзакций). Полный набор всех непотраченных транзакций содержится в списке, который доступен для всех узлов Биткойн. К примеру, если издатель исходно выпускает 10,000$ в виде валютных токенов, и с течением времени будут потрачены токены стоимостью 5500$, оборот будет равен $4500 (соответствует ценности непотраченных токенов). Это значение должно удовлетворять остатку на соответствующем резервном счету.
Иллюстративный пример вычислительного ресурса ("агента"), подходящего для применения совместно с вариантами осуществления изобретения
В настоящем изобретении для исполнения автоматизированных аспектов требуемой обработки может использоваться соответствующим образом сконфигурированный вычислительный ресурс (далее "агент"). Ниже рассмотрен один из примеров подходящего агента, являющийся предпочтительным, хотя могут применяться и другие реализации.
Агент может функционировать в связи с блокчейном, используя его в качестве нестираемой ленты в реализации машины Тьюринга. Агент функционирует параллельно блокчейн-сети, осуществляя надзор и управление исполнением (циклической) процедуры. Циклическая процедура предназначена для выполнения определенной задачи, например,
автоматизации технологического процесса или управления устройством или системой. Подобный параллельный ресурс осуществляет мониторинг состояния блокчейна и может обеспечивать запись транзакций в блокчейн. В некотором смысле, он использует блокчейн как нестираемую ленту машины Тьюринга, согласно следующим определениям и признакам:
1. Блокчейн выступает в роли ленты машины Тьюринга. Каждая транзакция в блокчейне представляет собой ячейку на ленте. Такая ячейка может содержать символы конечного алфавита.
2. Головка может считывать информацию из блоков, которые уже были записаны в блокчейн.
3. Головка может записывать новые блоки, содержащие множество транзакций, в конец блокчейна. Однако она не может выполнять запись в уже существующие блоки. По своей природе лента блокчейна нестираема.
4. Метаданные каждой транзакции могут храниться в составе многоподписной P2SH-транзакции (pay-to-script-hash).
Важной функцией агента является исполнение роли автоматического объекта, который выполняет мониторинг текущего состояния блокчейна. Он также может принимать сигнал или входные данные из любых источников вне блокчейна. В зависимости от состояния блокчейна и/или принятых входных данных, агент может выполнять определенные действия. Агент принимает решения о том, какие действия необходимо выполнить. Они могут включать действия в "реальном мире" (то есть, вне блокчейна) и/или действия в блокчейне (например, создание и публикация новых транзакций), однако это не является обязательным. Действия, предпринимаемые агентом, могут инициироваться состоянием блокчейна. Агент может также принимать решение о публикации следующего набора транзакций в сети Биткойн и об их последующей записи в блокчейн.
Действия агента выполняются параллельно и одновременно с сетью блокчейна (например, Биткойн). В некотором смысле, это является расширением функциональности блокчейн-скриптов (например, скриптов Биткойн). Такой непрерывный мониторинг позволяет реализовать циклические структуры операций, что делает систему, состоящую из агента и блокчейна, полной по Тьюрингу.
Машина Тьюринга имеет два стека: • Стек данных: Как отмечалось выше, он представлен блокчейном.
• Стек управления: он представлен функциональностью агента. В нем хранят информацию, относящуюся к циклическим функциям управления операциями. Разнесение стека управления и стека данных имеет то преимущество, что
позволяет исключить возникновение бесконечных циклов в ядре Биткойн и снижая действенность атак типа "отказ в обслуживании".
Агент обеспечивает управление и исполнение подпрограмм, способных выполняться в цикле при помощи любых структур организации цикла (например, FOR-NEXT, REPEAT UNTIL и т.п.). Один из примеров осуществления настоящего изобретения, рассмотренный в данном документе, включает процедуру, в которой применяют один из примеров структуры типа 'REPEAT'. Пользователь может задавать счетчик (/') и предел (J). Они представляют собой, соответственно, номер текущей итерации (как правило, отсчитываемый от 0) и общее количество итераций цикла 'REPEAT'.
Для каждой итерации:
1. Счетчик увеличивают на 1. Условие выхода при этом: итерации прекратятся, когда счетчик достигнет заданного предела.
2. Выполняют кодовый блок, содержащий выражение типа 'if условие then действие' (if condition then action, ICTA); действие может быть любым действием, в блокчейне или вне его;
3. Вычисляют криптографическое хэш-значение этой подпрограммы. Оно может быть сохранено в блокчейне как часть транзакции. Поскольку любой код будет иметь уникальное хэш-значение, это позволяет верифицировать применяемый код. Тело цикла включает кодовый блок. Каждый кодовый блок содержит выражение
типа 'if условие then действие' (ЮТА); При помощи этого отслеживают текущее состояние блокчейна на предмет транзакций, соответствующих:
• пусковому или инициирующему условию (например, когда наступила конкретная дата);
• условию повтора (т.е. метаданные или хэш-значение, относящиеся к предыдущей итерации);
• условию останова (т.е. последней итерации цикла).
Выражение ЮТА позволяет агенту принять решение о создании следующей транзакции в зависимости от текущего состояния блокчейна. Создание следующей транзакции включает публикацию транзакции в сети Биткойн и запись новой транзакции в
блокчейн. Она выступает в качестве записи о выполнении данной итерации. После записи транзакции в блокчейн управляющий агент определит, что предыдущая транзакция была выполнена и записана в блокчейн, и выполнит следующую итерацию. Это продолжается до тех пор, пока не будет выполнен выход из цикла, когда счетчик (г) достигнет предела (J), заданного в кодовом блоке.
Каждую транзакцию сохраняют в блокчейне таким образом, что она может быть использована повторно. При реализации в сети Биткойн к каждой подписи в транзакции добавляют флаг SIGHASH. Этот флаг может принимать различные значения, каждое из которых указывает, могут ли другие части транзакции быть изменены без вмешательства владельца данной подписи. Повторно используемая транзакция имеет флаг SIGHASH, 'SigHash AnyoneCanPay', в одном из входов транзакции. Это позволяет любому осуществлять платеж на входы данной транзакции. Этот параметр обеспечивает возможность выполнения функции ЮТА агента и повторять ее множество раз с различными входными данными. Использование этой функции может быть разрешено только авторизованным лицам, например, при помощи авторских прав на повторно используемую транзакцию.
Часть кодового блока ЮТА, "if условие", позволяет отслеживать условия любого типа. Она аналогична другим языкам программирования (например, С, С++, Java) и не ограничена информацией, хранимой в блокчейне. К пример, она может отслеживать дату и время (т.е. момент, когда наступает определенная дата и время) или отслеживать погоду (например, когда температура ниже 10°С и идет дождь), отслеживать условия контракта или траста (например, когда компания А покупает компанию В).
Часть "Then действие" кодового блока ЮТА позволяет выполнять ряд действий. Настоящее изобретение не ограничено в отношении количества и типа предпринимаемых действий. Действия не ограничены транзакциями в блокчейне, хотя транзакции, содержащие метаданные, связанные с действием, могут заноситься в блокчейн.
Метаданные могут иметь любую форму. Однако в одном из вариантов осуществления настоящего изобретения в метаданных может храниться гиперссылка на файл, содержащий дополнительные данные или инструкции, относящиеся к действию. В метаданных может храниться как гиперссылка на хэш-таблицу, содержащую дополнительные данные или инструкции, относящиеся к действию, так и хэш-значение действия, которое выступает в роли ключа поиска по хэш-таблице.
Стек управления агента может быть реализован множеством различных путей, в зависимости от потребностей каждого пользователя. К примеру, цикл 'Repeat' в управляющем стеке может быть основан на любом языке, являющемся полным по Тьюрингу. Одним из возможных языков, который может быть выбран для этой цели, является стековый язык Forth. Одно из преимуществ применения этого языка заключается в том, что он обеспечивает соответствие стека управления стилю программирования скриптов Биткойн, которые широко известны и повсеместно применяются.
Использование альтернативного стека скрипта Биткойн в качестве области хранения данных
Скрипты Биткойн содержат команды, также называемые операционными кодами, или опкодами (opcodes), которые дают пользователю возможность помещать данные в альтернативный стек, называемый также альтстеком ('alt stack').
Имеются следующие опкоды:
• OPTOALTSTACK - перемещает данные с вершины основного стека на вершину альтернативного стека;
• OPFROMALT STACK- перемещает данные с вершины альтернативного стека на вершину основного стека;
Это позволяет сохранять данные промежуточных шагов вычисления в альтернативном стеке, аналогично функции "памяти", позволяющей сохранять данные в калькуляторах. В одном из вариантов осуществления настоящего изобретения альтернативный стек используют в целях конфигурирования скриптов Биткойн для решения простых вычислительных задач и возвращения результатов вычисления.
Использование кодового реестра для управления агентом
Агент также ведет реестр всех кодов, которыми он владеет и которые он исполняет. Этот реестр структурирован как таблица поиска или словарь, ставящий в соответствие ключи и конкретные значения. Пара "ключ-значение" представлена хэш-значением кодового блока (Hi) и ГРуб-адресом, по которому хранят код. Для извлечения кодового блока при помощи ключа Hi используют таблицу поиска и извлекают соответствующее значение (то есть местоположение, по которому хранят код), в результате чего, соответственно, получают исходный код. Реализации кодового реестра могут быть различными.
Метаданные транзакций, соответствующие коду агента, и повторное возобновление цикла
Информацию, необходимую для возобновления цикла агента на каждой отдельной итерации, хранят в метаданных транзакции, записанной в блокчейн.
Таким образом, транзакция в блокчейне хранит, или предоставляет доступ, к информации о каждой отдельной итерации цикла, исполняемого агентом. Эта информация может включать значения любых переменных, связанных с циклом, например, счетчик i, а также любую другую необходимую информацию, например, значения параметров, используемых в кодовом блоке, или данные о местоположении, определяющие, где может быть получена дополнительная необходимая информация.
Сами метаданные хранят в транзакции в составе многоподписного Р28Н-скрипта (pay-to-script-hash). Метаданные, записанные в транзакции, дают также возможность вести историю исполнения кода в прошлом.
Существует несколько способов, которыми агент может возобновлять выполнение кодового блока цикла на каждой итерации. Кодовый блок может быть жестко запрограммирован непосредственно в агенте или может храниться в конфиденциальном или публично доступном файле, или храниться в виде записи в конфиденциальном или публичном файле хэш-таблицы, или же может применяться некоторая комбинация перечисленного. Кодовый блок может быть статичным с жестко запрограммированными переменными, или может быть статичным, но при этом включать параметры, допускающие заполнение. Такие параметры могут быть отдельными значениями данных любого формата, или могут быть небольшими фрагментами кода, или комбинацией перечисленного. Параметры могут заполняться путем их извлечения непосредственно из метаданных транзакции (например, Биткойн-транзакции) или из внешнего источника, например, внутренней базы данных или конфиденциального/публичного файла, или хэш-таблицы, или некоторой комбинации перечисленного. Указатели на внешний источник значений параметров могут храниться в метаданных транзакции.
Описанные ниже шаги являются одним из примеров того, как агент может возобновлять выполнение кодового блока цикла на i-ой итерации. В данном примере кодовым реестром является хэш-таблица, при этом хэш-значения являются ключами поиска по таблице и хранятся в метаданных транзакций.
1. Агент анализирует блокчейн на предмет транзакций, которые содержат хэш-значения кодового блока, совпадающего с записями в кодовом реестре.
2. Агент находит транзакцию, которая содержит соответствующее хэш-значение (Hi).
3. Агент считывает 'Metadata-CodeHash', извлекает поле CodeHash для получения Hi и использует его для извлечения кода (Ci). Если RTPEMD-160(SHA256(C1)) равно HI, код не претерпел изменений, и переход к следующему шагу является безопасным.
4. Агент считывает значение 'Metadata-CodeHash', в котором хранится счетчик i, и возобновляет выполнение кода на i-ой итерации. Другими словами, цикл "перезагружают" на соответствующей итерации.
5. В Р28Н-команде включена подпись пользователя, что позволяет верифицировать происхождение метаданных.
6. Агент считывает значения 'Metadata-OutputHash' и 'Metadata-OutputPointer', чтобы извлечь выходные данные предыдущих шагов, если эти данные необходимы на текущей итерации цикла.
Следует отметить, что упомянутые выше варианты осуществления лишь иллюстрируют изобретение, не ограничивая его. Специалисты в данной области техники, в пределах объема изобретения, который задан формулой изобретения, могут предложить множество альтернативных вариантов его осуществления. В формуле изобретения все числовые обозначения, указанные в скобках, не следует рассматривать как ограничения. Выражения "включающий" и "включают", а также аналогичные им, не исключают наличия дополнительных элементов или шагов, не перечисленных в каком-либо пункте формулы изобретения или в настоящем документе в целом. В настоящем документе термин "включает" означает "содержит или состоит из", а "включающий", означает "содержащий или состоящий из". Упоминание какого-либо элемента в единственном числе не исключает множественности таких элементов и наоборот. Изобретение может быть реализовано при помощи аппаратного обеспечения, включающего несколько независимых элементов, а также при помощи соответствующим образом запрограммированного компьютера. В пунктах формулы изобретения, описывающих устройство и включающих перечисление нескольких средств, некоторые из этих средств могут быть реализованы при помощи одного аппаратного элемента. То, что несколько средств перечислены в разных зависимых пунктах формулы изобретения, не исключает того, что какая-либо комбинация этих средств может также эффективно применяться.
ФОРМУЛА ИЗОБРЕТЕНИЯ
1. Реализованная при помощи компьютера система для управления устройством, включающая:
устройство, сконфигурированное для связи с сетью и имеющее IP-адрес, а также пару из публичного и приватного криптографических ключей, ассоциированных с этим устройством;
программно-реализованный управляющий компонент, сконфигурированный для мониторинга состояния сети блокчейна и/или для передачи блокчейн-транзакций в сеть блокчейна; при этом управляющий компонент сконфигурирован для доступа к набору инструкций, хранимых в месте хранения данных, которое является отдельным от устройства; и
набор инструкций, сконфигурированных для исполнения упомянутым управляющим компонентом для управления функциональностью устройства, при этом упомянутый набор инструкций хранится в распределенной хэш-таблице (DHT), и доступен управляющему компоненту для загрузки и установки из DHT-таблицы, при этом местоположение DHT-таблицы указано или предоставлено с использованием метаданных, размещенных в блокчейн-транзакции.
2. Система по п. 1, в которой управляющий компонент сконфигурирован для приема входного сигнала от источника входных сигналов, при этом источником входных сигналов является:
другое устройство; и/или компьютерный ресурс или агент.
3. Система по п. 1 или 2, в которой управляющий компонент получает доступ к набору инструкций с использованием ключа поиска, который связан с парой криптографических ключей.
4. Система по любому из предшествующих пунктов, в которой управляющий
компонент размещен в упомянутом устройстве.
5. Система по любому из предшествующих пунктов, в которой управляющий компонент размещен вне устройства и сконфигурирован для беспроводной связи с устройством.
6. Система по любому из предшествующих пунктов, в которой управляющий компонент сконфигурирован:
для выполнения криптографических вычислений;
для доступа к ассоциированной с ним паре из приватного и публичного ключей; для обладания соответствующим адресом Биткойн или иным адресом, относящимся к блокчейну;
для управления устройством по API-интерфейсу;
для выполнения операций протокола разделения секрета.
7. Система по любому из предшествующих пунктов, в которой управляющий компонент сконфигурирован для влияния на действия устройства или для управления такими действиями на основании обнаружения действительной блокчейн-транзакции.
8. Реализованный при помощи компьютера способ управления устройством,
включающий следующие шаги:
предоставление устройства, сконфигурированного для беспроводной связи с сетью и имеющего IP-адрес, а также пару из публичного и приватного криптографических ключей, ассоциированных с этим устройством;
предоставление программно-реализованного управляющего компонента, сконфигурированного для мониторинга состояния сети блокчейна и/или для передачи блокчейн-транзакций в сеть блокчейна;
предоставление набора инструкций, сконфигурированных для исполнения упомянутым управляющим компонентом для управления функциональностью устройства; при этом:
i) управляющий компонент сконфигурирован для доступа к набору инструкций в месте хранения данных, которое является отдельным от устройства;
ii) упомянутый набор инструкций хранится в распределенной хэш-таблице (DHT) и доступен управляющему компоненту для загрузки и установки из DHT-таблицы; и
i)
iii) местоположение DHT-таблицы указано или предоставлено с использованием метаданных, размещенных в блокчейн-транзакции.
9. Способ по п. 8, в котором управляющий компонент сконфигурирован для приема входного сигнала от источника входных сигналов, при этом источником входных сигналов является:
другое устройство; и/или компьютерный ресурс или агент.
10. Способ по п. 9, в котором управляющий компонент осуществляет доступ к набору инструкций с использованием ключа поиска, который связан с парой криптографических ключей.
11. Способ по любому из п.п. 8-10, в котором управляющий компонент размещен в упомянутом устройстве.
12. Способ по любому из п.п. 8-11, в котором управляющий компонент размещен вне устройства и сконфигурирован для беспроводной связи с устройством.
13. Способ по любому из п.п. 8-12, в котором управляющий компонент сконфигурирован:
для выполнения криптографических вычислений;
для доступа к ассоциированной с ним паре из приватного и публичного ключей; для обладания соответствующим адресом Биткойн или иным адресом, относящимся к блокчейну;
для управления устройством по API-интерфейсу;
для выполнения операций протокола разделения секрета.
14. Способ по любому из п.п. 8-13, в котором управляющий компонент сконфигурирован для влияния на действия устройства или для управления такими действиями на основании обнаружения действительной блокчейн-транзакции.
14.
Фиг. 1
инструкции
Ш О
m S
1= Q
Фиг. 2
го >
о аз
5 <
m Q
m О
о -I го
S300
Предоставленное решение puzzle-A хэшируют и сравнивают с хранимым вариантом puzzle-A
\ Обрабатывают сегмент \ Multi-sig скрипта
S310
S302
Предоставленное решение puzzle-B хэшируют и сравнивают с хранимым вариантом puzzle-B
Функция OP_VERIFY проверяет, равен ли верхний элемент стека 1
S308
S304-
Исполняют функцию OP_NUMEQUAL
Функция OP_NOT инвертирует верхний элемент стека
S306
Фиг. 3
Третий узел
Первый узел
Сеть
Второй узел
••••••!••••••
•Ч:
Перехватчик
* k \
!1Р
Первый узел
V* 3
Сеть "А *
Второй узел
Обмен сообщением (М) между первым и вторым узлом
Определение второго приватного ключа
(V2C) первого узла на основе по меньшей мере приватного мастер-ключа (V1C) первого узла и значения генератора (GV)
1 ..
Формирование первого подписанного сообщения (SM1) на основе сообщения (М) и второго приватного ключа (V2C) первого узла
Определение второго публичного ключа
(Р2С) первого узла на основе по меньшей мере публичного мастер-ключа (Р1С) первого узла и значения генератора (GV)
' V
Передача первого подписанного сообщения (SM1) во второй узел
Прием первого подписанного сообщения (SM1)
|
Валйдацйя первого подписанного сообщения (SM2) с использованием второго публичного ключа (Р2С) первого узла
410 'Ч.
i Аутентификация первого узла в зависимости от результата валидации первого подписанного сообщения (SM1)
Определение второго публичного ключа (P2S) второго узла на основе по меньшей
мере публичного мастер-ключа (P1S) второго узла и значения генератора (GV)
Определение второго приватного ключа (V2S) второго узла на основе по меньшей мере приватного
мастер-ключа (V1S) второго узла и
шачениягеневатора(еу),
Определение 380 общего секрета (CS) на основе второго приватного ключа (V2C) первого узла и второго публичного ключа (P2S) второго узла
480
Определение (шаг 480) общего секрета (CS) на основе второго приватного ключа (V2S) второго узла и второго публичного ключа (Р2С) первого узла
Фиг. 5
Сеть
^ Первый узел г1(r)
-¦^..1
Второй узел
Установка системы ЕСС с использованием G
Установка системы ЕСС с использованием G .,
Формирование первой асимметричной
криптографической пары, которая включает приватный мастер-ключ (V1C) первого узла и публичный мастер-ключ (Р1С) первого узла на основе приватного мастер-ключа (V1C) первого узла и G
Передача публичного мастер-ключа (Р1С) клиента во второй узел
Прием публичного мастер-клк)ча
! (Р1С) первого узла
Прием публичного мастер-ключ^ {PJS),|BTOporo)ana
Сохранение публичного мастер-ключа (P1S) второго узла
<*ш Jfb Сохранение публичного ?Ж s..--> ; магар^ю^на (И^
Формирование второй асимметричной криптографической пары, которая включает приватный мастер-ключ (V1S) второго узла и
публичный мастер-ключ (P1S)
второго узла на основе приватного
мастер-ключа (V1S) второго узла и
.. базово! о значения (G)
Г Передача публичного мастер-ключа ; (Р1S) второго узла в первый узел
Сеть
Первый узел 31(r) Формирование сообщения (М)
Второй узел
Передача сообщения (М) во
второй узел
Прием сообщения (М) от первого узла
Определение значения генератора ^ (GV) на основе сообщения (М)
Определение значения генератора (GV) на основе сообщения (М)
Определение второго приватного ключа V2C) первого узла на основе приватного мастер-ключа (V1C) первого узла и значения генератора (GV)
Определение второго публичного ключа (Р2С) первого узла на основе публичного мастер-ключа (Р1С) первого узла, значения генератора (GV) и базовой точки (G)
Формирование первого подписанного сообщения (SM1) на основе сообщения (М) и второго приватного ключа (V2C)
перчпгп узпя
Передача первого подписанного сообщения (SM1) во второй,.узел v Прием первого подписанного сообщения (SM1) от первого узла
Валидация первого подписанного сообщения! ,¦ (SM2) с использованием второго [ публичного ключа (Р2С) первого узла [
Аутентификация первого узла на основании результата валидации первого подписанного сообщения (SM11
Определение второго публичного ключа (P2S) [ второго узла на основе публичного мастер-ключа (P1S) второго узла, значения генератора (GV) и базовой точки (G)
Определение второго приватного ключа (V2S) второго узла на основе приватного мастер-ключа (V1S) второго узла и значения генератора (GV]
Определение общего секрета (CS) на основе второго приватного ключа (V2C) первого узла и второго публичного ключа (P2S) второго узла
Hi- ;
Определение общего секрета (CS) на основе второго приватного ключа (V2S)
второго узла и второго публичного
^ ключа (Р2С)
sL.JIfi ^
Первый узел'
Сеть
lip ^
Второй узел
Формирование первого подписанного сообщения (SM1) на основе сообщения (М) и второго приватного ключа (V2C) первого узла
Передача первого подписанного сообщения (SM1) во второй узел
Приём первого подписанного сообщения (SM1) от первого узла
Валидация первого подписанного сообщение (SM2) с использованием второго публичного ключа (Р2С) первого узла
Аутентификация первого узла на основании результата валидации первого подписанного сообщения (SM1)
Формирование второго подписанного
сообщения (SM2) на основе сообщения (М) и второго приватного ключа (V2S) второго узла
11рием второго подписанного сообщения (SM2) от второго узла
Передача второго подписанного сообщения (SM2) в первый узел
Валидация подписи под вторым подписанным сообщением (SM2) с использованием второго публичного ключа (P2S) второго узла
IV Ш
Аутентификация второго узла на основании результата валидации 1v второго подписанного сообщения (SM2,
Прием первого подписанного сообщения. (SM1) от первого узла
Транзакция блокчейна (например, Rui-гкпйня)
Фиг. 9
го о m 5
1= о
го >
о аз
5 <
m Q
mg о -I го
Фиг. 10
Транзакция 1 JXQ
Разблокирующи ТПЯНЧЯК! 1ИЯ ? и скрипт 1 pan^аКЦИИ L
Блокирующий скрипт
Блокирующий скрипт на Разблокирующий скрипт
выходе ТхО включает оценивает выходное
инструкции для логическое значение с
реализации требуемой использованием сигналов А и В
логики
Фиг. 11
Создание первой транзакции с блокирующим скриптом, который содержит инструкции для реализации логики, соответствующей таблице истинности
Создание второй транзакции с разблокирующим скриптом, который имеет более одного входа (А, В)
Оценка входных сигналов А, В и получение логических значений (может выполняться непосредственно скриптом или другой процедурой, исполняемой в некотором вычислительном
агенте, перед подачей на вход скрипта)
Использование второй транзакции для траты выхода ТхО первой транзакции при помощи исполнения соответствующих блокирующего и разблокирующего скрипта: использование логических значений как входных для вентильной логики в блокирующем скрипте, что дает логическое выходное значение
*
Передача второй транзакции в сеть блокчейна (Биткойна) для валидации майнерами
t
Контроль блокчейна или сети для определения наличия второй транзакции
4
Если в блокчейне или в сети обнаружена вторая транзакция, она должна быть проверена, то есть скрипт должен давать результат TRUE: этот результат обнаружения используют для управления устройством, системой или процессом
(19)
(19)
(19)
4/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
5/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 4
4/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
5/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 4
4/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
5/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 4
4/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
5/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 4
4/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
5/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 4
4/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
5/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 4
4/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
5/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 4
4/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
5/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 4
4/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
5/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 4
4/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
5/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 4
4/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
5/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 4
6/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
5/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 6
6/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
5/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 6
6/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
5/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 6
6/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
5/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 6
7/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
7/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 7
Фиг. 7
7/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
7/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 7
Фиг. 7
7/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
7/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 7
Фиг. 7
7/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
7/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 7
Фиг. 7
7/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
7/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 7
Фиг. 7
7/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
7/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 7
Фиг. 7
8/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
8/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 8
Фиг. 8
8/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
8/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 8
Фиг. 8
8/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
8/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 8
Фиг. 8
8/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
8/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 8
Фиг. 8
8/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
8/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 8
Фиг. 8
8/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
8/11
ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ УСТРОЙСТВ ИНТЕРНЕТА ВЕЩЕЙ В БЛОКЧЕЙНЕ
Фиг. 8
Фиг. 8