Приватный блокчейн: сеть, куда пускают по пропуску
- Зачем это нужно
- Два разных вопроса
- Кто в сети кто
- Что такое канал
- Ставим Fabric
- Поднимаем сеть одной командой
- Создаём канал и смотрим на пустую цепочку
- Кто такой я: сертификат вместо кошелька
- Проверка: личность решает, а не адрес
- Типичные ошибки
- Шпаргалка по главе
- Словарь главы
- Что должен уметь после главы
- Проверка по главе
- Куда дальше: проверенные ресурсы
Зачем это нужно
До этой главы весь трек был про открытые сети. Там любой может завести кошелёк, любой может прочитать чужой баланс, и любой платит газ за каждую запись. Правила придуманы так, чтобы система работала между незнакомцами, которые друг другу не доверяют вообще.
Но есть другая задача, и она встречается чаще. Колледж, министерство и работодатель хотят вести общий журнал — скажем, выданных дипломов. Они знают друг друга по названию, у них есть договор, и в суд они пойдут не к алгоритму, а к юристу. Им не нужно доверие между незнакомцами. Им нужно, чтобы никто из троих не смог задним числом подправить свою запись, а остальные двое этого не заметили.
Открытая сеть эту задачу решает плохо: дипломы станут видны всему миру, за каждую запись придётся покупать монету, а скорость будет чужая. Для таких случаев существует другой класс систем — закрытые, или, как чаще говорят, приватные блокчейны. Самый распространённый из них — Hyperledger Fabric.
Эта глава — про то, чем он принципиально отличается, кто в нём кто, и как за одну команду поднять настоящую сеть из трёх узлов у себя на машине.
Два разных вопроса
Разница не в том, что одна «настоящая», а другая «ненастоящая». Разница в исходном вопросе.
Открытая сеть отвечает на вопрос: как договориться о едином списке событий, если участники неизвестны и часть из них — мошенники? Ответ дорогой: механизм согласия, за который платят газом, полная публичность и неизвестные машины в роли подтверждающих.
Закрытая сеть отвечает на другой вопрос: как вести общий журнал организациям, которые друг друга знают, но друг другу не подчиняются? Здесь не нужно защищаться от анонимного злоумышленника — каждый участник назван и подписан сертификатом. Зато нужно, чтобы ни один участник не мог единолично переписать историю.
Приватный блокчейн — это не «блокчейн-лайт». Это ответ на другую задачу. Вопрос «что лучше» примерно так же осмыслен, как «что лучше: грузовик или автобус».
Что остаётся от блокчейна при переходе в закрытую сеть:
- цепочка блоков, каждый ссылается на хеш предыдущего;
- история только дописывается, переписать прошлое нельзя;
- один и тот же код исполняется на нескольких независимых узлах, и результаты сверяются.
Что исчезает:
- анонимность — вместо кошелька выдают сертификат, и по нему видно организацию;
- газ и монета — сеть своя, платить некому;
- публичность — читать может только участник канала;
- майнинг и конкуренция за блок — блоки собирает назначенная служба.
Кто в сети кто
В открытой сети роль ровно одна: узел. Он и хранит, и проверяет, и участвует в согласии. В Fabric обязанности разведены по четырём ролям, и это главное, что нужно уложить в голове до первой команды.
Организация — участник сети целиком: колледж, банк, поставщик. У неё есть короткое имя вроде Org1MSP. Всё, что происходит в сети, происходит от имени какой-то организации.
Пир (peer) — рабочая лошадь. Он хранит копию реестра, исполняет код смарт-контракта и подписывает результат. Пиров у организации может быть сколько угодно.
Упорядочиватель (orderer) — служба, которая принимает подписанные сделки, ставит их в единую очередь и режет на блоки. Обратите внимание: он не исполняет код и обычно даже не хранит состояние. Его работа — решить, что за чем идёт.
Удостоверяющий центр (CA) — выдаёт сертификаты. В Fabric личность — это не пара ключей, которую вы сгенерировали сами, а выданный документ, подписанный центром организации.
И над всем этим — канал. Канал — это отдельный реестр внутри одной и той же сети: свой список организаций, своя история блоков, свои смарт-контракты. Две организации могут вести дела в канале, о котором третья не знает ничего.
Разделение «пир исполняет, упорядочиватель выстраивает очередь» — самое неочевидное решение Fabric. В Ethereum узел делает и то и другое. Зачем это разведено, разберём в главе про путь транзакции — там это объясняет всё остальное.
Что такое канал
Слово «канал» сбивает с толку, потому что в обычной речи это труба для передачи. Здесь это отдельный журнал.
Представьте колледж, который ведёт дела с двумя работодателями. С первым — практика, со вторым — трудоустройство. Обе истории надо вести честно, но второму работодателю нечего делать в записях первого.
Два канала решают это буквально: praktika и rabota. В первом состоят колледж и первый работодатель, во втором — колледж и второй. У каждого канала своя цепочка блоков, свои смарт-контракты и свой список участников. Колледж видит оба, работодатели — только свой.
Одна сеть — много каналов. Именно поэтому Fabric попадает в задания чемпионата: «разграничить доступ между организациями» здесь решается настройкой, а не выдумыванием шифрования поверх открытой сети.
Ставим Fabric
Fabric — это набор программ на Go, которые работают в контейнерах Docker, плюс несколько утилит командной строки. Ставится одним скриптом.
curl -sSLO https://raw.githubusercontent.com/hyperledger/fabric/main/scripts/install-fabric.sh
chmod +x install-fabric.sh
./install-fabric.sh docker samples binary
Скачивание занимает несколько минут: образов около десяти, суммарно под гигабайт. После установки проверяем, что утилиты на месте:
./fabric-samples/bin/peer version
peer:
Version: v2.5.16
Commit SHA: f871cf9
Go version: go1.26.4
OS/Arch: darwin/arm64
Chaincode:
Base Docker Label: org.hyperledger.fabric
Docker Namespace: hyperledger
Версия 2.5 — долгоподдерживаемая ветка, и именно она стоит в заданиях. Версия 3.x существует, но в ней сменился механизм согласия упорядочивателей, и половина команд из руководств по 2.5 там работает иначе. Ставьте то, что ставится по умолчанию.
Поднимаем сеть одной командой
В fabric-samples лежит папка test-network — учебная сеть из двух организаций и одного упорядочивателя. Она собрана ровно для того, чтобы не тратить первый день на генерацию сертификатов.
cd fabric-samples/test-network
./network.sh up
Через полминуты команда заканчивается списком контейнеров:
CONTAINER ID IMAGE COMMAND STATUS PORTS
830fd840f0d1 hyperledger/fabric-orderer:latest "orderer" Up 0.0.0.0:7050->7050/tcp
802bd4618884 hyperledger/fabric-peer:latest "peer node start" Up 0.0.0.0:9051->9051/tcp
337e6ea302ed hyperledger/fabric-peer:latest "peer node start" Up 0.0.0.0:7051->7051/tcp
Три контейнера: упорядочиватель на порту 7050 и два пира — первой организации на 7051, второй на 9051. Номера портов придётся запомнить, они будут в каждой команде дальше.
Порты 7051 и 9051 выбраны не случайным образом, а чтобы два пира на одной машине не столкнулись. В настоящей сети каждая организация держит пир у себя, и все они слушают 7051.
А вот чего нет после этой команды: реестра. Контейнеры подняты, но общего журнала между ними не существует — потому что не создан канал. Это и есть первое, что отличает Fabric от привычного «запустил узел — он подключился к сети».
Создаём канал и смотрим на пустую цепочку
./network.sh createChannel -c pgk
Channel 'pgk' created
Anchor peer set for org 'Org1MSP' on channel 'pgk'
Anchor peer set for org 'Org2MSP' on channel 'pgk'
Channel 'pgk' joined
Теперь у сети есть реестр. Посмотрим на него:
peer channel getinfo -c pgk
Blockchain info: {"height":1,"currentBlockHash":"...","previousBlockHash":""}
Высота 1. В цепочке ровно один блок — и это не сделка, а настройки канала: список организаций, их политики и правила нарезки блоков. У предыдущего блока пустой хеш, потому что предыдущего нет.
Первый блок канала называется генезис-блоком, как и в открытых сетях. Но здесь в нём лежит не «раздача монет», а конфигурация: кто участвует и по каким правилам. Настройки канала хранятся в самом канале — и меняются такой же транзакцией, как любая другая.
Кто такой я: сертификат вместо кошелька
Утилита peer не знает, от чьего имени она работает. Это задаётся переменными окружения — и это первое, обо что спотыкаются все.
export CORE_PEER_LOCALMSPID=Org1MSP
export CORE_PEER_MSPCONFIGPATH=.../users/Admin@org1.example.com/msp
export CORE_PEER_ADDRESS=localhost:7051
export CORE_PEER_TLS_ENABLED=true
Заглянем в папку личности:
signcerts/Admin@org1.example.com-cert.pem
keystore/priv_sk
cacerts/ca.org1.example.com-cert.pem
tlscacerts/tlsca.org1.example.com-cert.pem
config.yaml
Здесь сертификат (кто вы), закрытый ключ (чем подписываете), корневой сертификат организации (кем вы заверены) и сертификат для шифрования соединения. Посмотрим, что в самом сертификате:
openssl x509 -in signcerts/Admin@org1.example.com-cert.pem -noout -subject -issuer -dates
subject=C=US, ST=California, L=San Francisco, OU=admin, CN=Admin@org1.example.com
issuer=C=US, ST=California, L=San Francisco, O=org1.example.com, CN=ca.org1.example.com
notBefore=Sep 12 10:38:00 2026 GMT
notAfter=Sep 9 10:38:00 2036 GMT
Три вещи, которых не бывает в открытой сети. Во-первых, у личности есть роль — OU=admin; у пира в том же месте стоит OU=peer. Во-вторых, есть кем выдан: удостоверяющий центр организации. В-третьих, есть срок действия — сертификат протухает.
Это и есть главное практическое отличие. В Ethereum адрес — производная от ключа, который вы придумали сами, и отнять его невозможно. Здесь личность выдана организацией, у неё есть срок, и её можно отозвать. Для корпоративной системы это плюс, а не минус.
Проверка: личность решает, а не адрес
Легко подумать, что права определяются тем, к какому пиру вы подключились. Проверим.
Возьмём личность администратора первой организации и обратимся к пиру второй:
CORE_PEER_ADDRESS=localhost:9051 peer chaincode query -C pgk -n basic -c '{"Args":["GetAllAssets"]}'
Ответ приходит нормально. Адрес пира — просто «к кому постучались»; читать канал имеет право любой его участник.
Теперь наоборот: адрес оставим родной, а личность подставим из организации упорядочивателя — она в сети есть, но в прикладной части канала не состоит.
Error: error endorsing query: rpc error: code = Unknown desc = Failed evaluating policy
on signed data during check policy on channel [pgk] with policy [/Channel/Application/Writers]:
[implicit policy evaluation failed - 0 sub-policies were satisfied,
but this policy requires 1 of the 'Writers' sub-policies to be satisfied]
Отказ. Разберём формулировку, она будет встречаться постоянно:
check policy on channel [pgk] with policy [/Channel/Application/Writers]— сеть проверяла политику «кто имеет право писать в прикладную часть канала»;0 sub-policies were satisfied— ни одна организация канала не признала эту подпись своей;requires 1 of the 'Writers' sub-policies— а требовалась хотя бы одна.
Вывод для практики: права даёт сертификат, а не адрес узла. Перепутанный CORE_PEER_ADDRESS даст ошибку связи, перепутанный CORE_PEER_MSPCONFIGPATH — ошибку политики. Тексты у них разные, и это экономит время.
Типичные ошибки
Ошибка 1. Забыли -c и получили жалобу на канал.
Error: The required parameter 'channelID' is empty. Rerun the command with -C flag
Флаг канала обязателен почти у каждой команды peer. Заметьте: он заглавный — -C, в отличие от строчного -c, которым передают аргументы вызова. Две соседние клавиши, две разные вещи.
Ошибка 2. Кавычки вокруг набора флагов.
Если собрать флаги в переменную и подставить её в кавычках, оболочка передаст всё одной строкой:
Error: unknown flag: --peerAddresses localhost:7051 --tlsRootCertFiles /path/to/cert.pem
Лечится либо массивом, либо подстановкой без кавычек, либо просто написанием команды целиком. Последнее для учебных целей честнее: команду видно.
Ошибка 3. Сеть поднята, канала нет.
Error: endorsement failure during query. response: status:500
message:"make sure the chaincode basic has been successfully defined on channel pgk and try again"
Сообщение говорит про смарт-контракт, но частая причина проще: канал не создан или пир к нему не подключён. Проверяется одной командой — peer channel list.
Ошибка 4. Забыли, что личность берётся из окружения.
Команда выполняется в новой вкладке терминала, переменные там не заданы — и peer идёт в сеть с настройками по умолчанию, то есть ни с чем. Лечится файлом env.sh, который подключают в начале работы:
. ./env.sh 1 # работаем от первой организации
. ./env.sh 2 # от второй
Шпаргалка по главе
| Что нужно | Команда |
|---|---|
| Поднять учебную сеть | ./network.sh up |
| Создать канал | ./network.sh createChannel -c pgk |
| Погасить сеть и стереть данные | ./network.sh down |
| Узнать высоту цепочки | peer channel getinfo -c pgk |
| Список каналов пира | peer channel list |
| Версия утилиты | peer version |
| Посмотреть сертификат | openssl x509 -in cert.pem -noout -subject -issuer |
Словарь главы
| Термин | Что это |
|---|---|
| Приватный блокчейн | Сеть, куда пускают по выданному сертификату; история видна только участникам |
| Организация | Участник сети целиком, с коротким именем вроде Org1MSP |
| Пир (peer) | Узел: хранит реестр, исполняет смарт-контракт, подписывает результат |
| Упорядочиватель (orderer) | Служба, которая строит сделки в единую очередь и режет её на блоки |
| Удостоверяющий центр (CA) | Выдаёт сертификаты участникам организации |
| MSP | Описание организации: чьи сертификаты она признаёт своими |
| Канал | Отдельный реестр внутри сети со своим списком участников |
| Политика | Правило вида «кто имеет право это делать», записанное в настройках канала |
Цель: скорость ≥ 90 зн/мин, точность ≥ 88%
./install-fabric.sh docker samples binary
Что должен уметь после главы
- объяснить, на какой вопрос отвечает закрытая сеть и чем он отличается от вопроса открытой;
- назвать четыре роли — организация, пир, упорядочиватель, удостоверяющий центр — и сказать, кто из них что делает;
- поднять учебную сеть и создать в ней канал;
- прочитать высоту цепочки и понять, почему сразу после создания канала она равна единице;
- задать личность через переменные окружения и отличить ошибку связи от ошибки политики.
Проверка по главе
Сводная проверка по всей главе: 10 вопросов, 5:00 на всё, без подсказок по ходу. Вопросы показываются по одному, ответ изменить нельзя. Если время выйдет — экзамен завершится с тем, что успел ответить. Пересдавать можно сколько угодно раз.
Куда дальше: проверенные ресурсы
- Hyperledger Fabric: документация 2.5 — основной источник, всё остальное вторично.
- Fabric samples — та самая учебная сеть и примеры смарт-контрактов.
- Ключевые понятия — раздел про организации, каналы и политики.
- Hyperledger Foundation — что ещё есть в семействе кроме Fabric.
Комментарии
Обсуждение живёт в GitHub Discussions и грузится с чужого домена — поэтому только по нажатию.