Одноранговые узлы

Блокчейн-сеть состоит в основном из множества одноранговых узлов. Одноранговые узлы являются фундаментальным элементом сети, они содержат копии реестра и умные контракты. Напомним, что реестр хранит все генерируемые умными контрактами транзакции без возможности внесения изменений (умные контракты в свою очередь содержатся в чейнкоде Hyperledger Fabric, подробнее об этом позже). Умные контракты и реестры используются, соответственно, для инкапсуляции совместно используемых процессов и информации в сети. Эти особенности одноранговых узлов делают их хорошей отправной точкой для понимания принципа работы сети Fabric.

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

Peer1

Блокчейн-сеть состоит из одноранговых узлов, каждый из которых может содержать копии реестра и умные контракты. В этом примере сеть N состоит из одноранговых узлов P1, P2 и P3, каждый из которых содержит собственный экземпляр распределенного реестра L1. Узлы P1, P2 и P3 используют один и тот же чейнкод S1 для доступа к своей копии распределенного реестра.

Одноранговые узлы можно создавать, запускать, останавливать, перенастраивать и даже удалять. В узлах предусмотрен набор API, которые позволяют администраторам и приложениям взаимодействовать со службами, предоставляемыми этими узлами. Подробнее об этих службах будет рассказано далее в этом разделе.

Несколько слов о терминологии

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

Реестры и чейнкод

Рассмотрим одноранговые узлы более подробно. Именно на одноранговых узлах размещаются реестр и чейнкод. Точнее, одноранговый узел фактически хранит экземпляры реестра и экземпляры чейнкода. Следует отметить, что благодаря такому механизму обеспечивается преднамеренная избыточность в сети Fabric, что позволяет устранить единые точки отказа. Больше о распределенной и децентрализованной природе блокчейн-сети будет рассказано далее в этом разделе.

Peer2

На одноранговом узле размещаются экземпляры реестра и экземпляры чейнкода. В этом примере узел P1 содержит экземпляр реестра L1 и экземпляр чейнкода S1. Один одноранговый узел может хранить несколько реестров и чейнкодов.

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

Использование нескольких реестров

Одноранговый узел может содержать более одного реестра. Таким образом повышается гибкость организации системы. В самой простой конфигурации одноранговый узел используется для управления одним реестром, однако он может содержать два или более реестров при необходимости.

Peer3

Одноранговый узел, на котором размещено несколько реестров. Одноранговые узлы содержат один или несколько реестров, при этом в каждом реестре может быть несколько чейнкодов или не быть их вовсе. В этом примере одноранговый узел P1 содержит реестры L1 и L2. Доступ к реестру L1 осуществляется с помощью чейнкода S1. В то же время, доступ к реестру L2 можно получить с помощью чейнкодов S1 и S2.

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

Использование нескольких чейнкодов

Не существует четкой связи между количеством реестров в одноранговом узле и количеством чейнкодов, которые могут получать доступ к этим реестрам. Одноранговый узел может содержать много чейнкодов и много доступных реестров.

Peer4

Пример однорангового узла, на котором размещено несколько чейнкодов. К каждому реестру может обращаться любое количество чейнкодов. В этом примере одноранговый узел P1 содержит реестры L1 и L2, причем доступ к реестру L1 осуществляется с помощью чейнкодов S1 и S2, а к L2 — с помощью S1 и S3. Как видно, чейнкод S1 может обращаться к реестрам L1 и L2.

Немного позже мы расскажем о важности каналов Fabric при использовании нескольких реестров или чейнкодов на одном одноранговом узле.

Приложения и одноранговые узлы

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

Приложения всегда подключаются к одноранговым узлам для доступа к реестрам и чейнкодам. Комплект разработчика (SDK) Fabric упрощает эту задачу для программистов. Его API позволяют приложениям подключаться к одноранговым узлам, вызывать чейнкоды для создания и отправки транзакций в сеть, которые будут упорядочены, проверены и записаны в распределенный реестр, а также получать уведомления по завершении этого процесса.

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

Peer6

Одноранговые узлы вместе с узлами службы упорядочения поддерживают реестр в актуальном состоянии на каждом одноранговом узле. В этом примере приложение A подключается к узлу P1 и вызывает чейнкод S1, чтобы отправить запрос или обновить реестр L1. Узел P1 вызывает чейнкод S1 для генерации ответа на запрос, который содержит результат запроса или предлагаемое обновление реестра. Приложение A получает ответ и на этом процессы, для запросов реестра, завершается. Для обновления реестра приложение A создает транзакцию из всех ответов и отправляет ее в узел службы упорядочения O1. Узел O1 собирает транзакции со всей сети в блоки и распределяет их по всем одноранговым узлам, включая узел P1. Узел P1 проверяет транзакцию перед записью в реестр L1. После обновления реестра L1 узел P1 генерирует событие и отправляет в приложение A, чтобы подтвердить завершение процесса.

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

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

Далее в этом разделе будет более подробно рассказано о процессе упорядочивания. Этот вопрос рассматривается более углубленно в разделе о выполнении транзакции.

Одноранговые узлы и каналы

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

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

Peer5

Каналы позволяют определенному набору одноранговых узлов и приложений взаимодействовать друг с другом в блокчейн-сети. В этом примере приложение A может напрямую связываться с одноранговыми узлами P1 и P2 через канал C. Канал можно воспринимать как способ взаимодействия между конкретными приложениями и одноранговыми узлами (для упрощения схемы узлы службы упорядочения не показаны, однако такие узлы обязательно присутствуют в реальной сети).

Как мы видим, каналы устроены не так же, как одноранговые узлы. Более уместно воспринимать канал как логическую структуру, образованную набором физических одноранговых узлов. Очень важно понимать, что одноранговые узлы — это точка для доступа к каналам и управления ими.

Одноранговые узлы и организации

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

Блокчейн-сеть управляется группой организаций, а не одной организацией. Одноранговые узлы играют центральную роль в построении такой распределенной сети, так как они принадлежат организациям и являются точками подключения к сети для них.

Peer8

Одноранговые узлы в блокчейн-сети с несколькими организациями. Блокчейн-сеть строится из одноранговых узлов, принадлежащих и предоставляемых различными организациями. В этом примере четыре организации предоставляют восемь одноранговых узлов для формирования сети. Канал C объединяет пять одноранговых узлов P1, P3, P5, P7 и P8 в сети N. Другие одноранговые узлы этих организаций не подключены к этому каналу, но обычно входят в состав как минимум одного другого канала. Приложения, разработанные определенной организацией, могут подключаться к одноранговым узлам своей организации, а также к узлам других организаций. Здесь также для упрощения схемы узел службы упорядочения не показан.

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

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

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

Приложения подключаются либо к одноранговым узлам своей организации, либо к одноранговым узлам другой организации, в зависимости от требуемого характера взаимодействия с реестром. Приложения обычно подключаются к одноранговым узлам своей организации для взаимодействия с реестром при запросах. Далее будет показано, почему приложениям нужно подключаться к одноранговым узлам всех организаций, требуемых для одобрения внесения обновлений в реестр.

Одноранговые узлы и идентификация

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

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

Peer9

При подключении однорангового узла к каналу, цифровой сертификат идентифицирует организацию-владельца узла с помощью провайдера службы членства (MSP). В этом примере узлы P1 и P2 имеют идентификаторы, выданные удостоверяющим центром CA1. Согласно установленным правилам своей конфигурации канал C определяет, что согласно провайдеру службы членства ORG1.MSP идентификаторы, выданные удостоверяющим центром CA1, принадлежат организации Org1. Аналогично, одноранговые узлы P3 и P4 идентифицируются ORG2.MSP как часть организации Org2.

При каждом подключении однорангового узла к блокчейн-сети с использованием канала, права однорангового узла определяются согласно его идентификатору и политикам в конфигурации канала. Связывание идентификаторов и организаций осуществляется компонентом под названием провайдер службы членства (MSP). Этот компонент определяет, каким образом одноранговому узлу назначается роль в организации и, соответственно, какой доступ он будет иметь к ресурсам блокчейна. Кроме того, одноранговый узел может принадлежать только одной организации и, следовательно, быть связанным только с одним MSP. Более подробно об управлении доступом к одноранговым узлам будет рассказано далее в этой статье. Также в руководстве есть целый раздел, посвященный MSP и правилам управления доступом. В рамках этого раздела представьте, что MSP обеспечивает связь между отдельным идентификатором и определенной организационной ролью в блокчейн-сети.

Стоит также отметить, что одноранговые узлы, а также все взаимодействующие с блокчейн-сетью компоненты, получают свои идентификаторы, связанные с организациями, с помощью цифровых сертификатов и MSP. Одноранговые узлы, приложения, конечные пользователи, администраторы и узлы службы упорядочения должны иметь идентификатор и связанный с ним MSP для возможности взаимодействия с блокчейн-сетью. Каждую сущность, взаимодействующую с блокчейн-сетью с помощью идентификатора будем называть субьектом. Более подробно о субъектах и организациях рассказано в других разделах этого руководства, однако приведенной в этой статье информации более чем достаточно, чтобы углубить понимание работы одноранговых узлов.

Наконец, следует отметить, что физическое расположение однорангового узла не имеет большого значения — он может находиться в облаке, или в центре обработки данных одной из организаций, или на локальном компьютере. Принадлежность узла к организации определяет его цифровой сертификат. В примере выше узел P3 может размещаться в центре обработки данных организации Org1, однако если цифровой сертификат узла выдается удостоверяющим центром CA2, то узел принадлежит организации Org2.

Одноранговые узлы и узлы службы упорядочения

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

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

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

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

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

Шаг 1: предложение транзакции

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

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

Peer10

Предложение транзакции независимо обрабатывается одобряющими узлами, которые возвращают одобренные ответы предложению. В этом примере приложение A1 создает предложение P одобрения транзакции T1, которое отправляется одноранговым узлам P1 и P2 канала C. Узел P1 выполняет чейнкод S1 в рамках предложения P на одобрение транзакции T1, генерирует результат выполнения R1 c одобрением E1. В то же время узел P2 выполняет чейнкод S1, в рамках того же предложения P, генерирует ответ R2 и c одобрением E2. Приложение A1 получает два ответа с одобрением транзакции T1, а именно E1 и E2.

Изначально множество одноранговых узлов определяется приложением для создания множества предлагаемых обновлений реестра. Выбор одноранговых узлов приложением зависит от политики одобрения (определенной для чейнкода). Эта политика определяет набор организаций, которым необходимо одобрить предлагаемое изменение реестра, прежде чем оно будет принято сетью. Буквально это и означает достижение консенсуса — каждая задействованная организация должна одобрить предлагаемое изменение реестра до того, как оно будет записано в копии реестра на одноранговых узлах.

Одноранговый узел одобряет ответ на запрос, подписывая все данные пакета, используя свой закрытый ключ. Это одобрение впоследствии может использоваться для подтверждения того, что одноранговый узел этой организации дал определенный ответ. В указанном примере, если одноранговый узел P1 принадлежит организации Org1, одобрение E1 соответствует цифровому подтверждению того, что «ответ R1 на транзакцию T1 обновления реестра L1 был предоставлен узлом P1 организации Org1!».

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

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

Шаг 2: упорядочение и упаковка транзакций в блоки

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

Шаг 3: проверка и запись

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

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

Peer12

Дополнительная роль узла службы упорядочения заключается в распределении блоков между узлами. В этом примере узел службы упорядочения O1 отправляет блок B2 на одноранговые узлы P1 и P2. Одноранговый узел P1 обрабатывает блок B2, в результате чего новый блок добавляется в копию реестра L1 узла P1. Параллельно, одноранговый узел P2 обрабатывает блок B2 и добавляет его в свою копию реестра L1. В ходе этого процесса реестр L1 согласованно обновляется на одноранговых узлах P1 и P2. Оба узла могут уведомить подключенные приложения о том, что транзакция была обработана.

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

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

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

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

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

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

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

Узлы службы упорядочения и консенсус

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

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