Hyperledger chaincode «register» vs «deploy»

Я вижу следующее сообщение ref для «what -used-exact-on-chaincode-deploy-and-invoke-query-in-hyperledger».Hyperledger chaincode «register» vs «deploy»

Для кода цепи «register», то, что автор цепи должен зарегистрировать цепочку кодов на ValidationPeer, прежде чем другие узлы смогут найти цепочку в сети и загрузить источник в локальное и построенное изображение докеров? Что произойдет, если один и тот же цепочный код будет развернут несколько раз после этого, будет ли он перезаписывать предыдущее состояние?

Ссылка: What happened exactly on chaincode deploy and invoke , query, in Hyperledger?

Во время «Развертывание» код цепи представлен в книге в виде сделки и распространяется на все узлы в сети. Каждый узел создает новый контейнер Docker с этим встроенным кодеком. После этого контейнер будет запущен и будет запущен метод Init.

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

Во время «Invoke» - цепной код может изменять состояние переменных в регистре. Каждая транзакция «Invoke» будет добавлена в «блок» в регистре.

источник

2016-09-09 E Ma

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

«Регистратор» используется автором сетевого кода для входа в сеть с помощью валидации или неаудификации. Чтобы войти в систему, автор должен подтвердить свою личность, предоставив EnrolmentID и EnrolmentPassword. Если идентификатор и пароль верны, для этого конкретного автора будут созданы новые сертификаты регистрации и транзакции.

С этого момента автор может развернуть цепочку кодов в сети. Запрос «Развертывание» будет отправлен одному из сверстников. Этот одноранговый узел создаст «транзакцию» с информацией о «пути к цепочке», «аргументы инициализации», «исходный код цепочки». Затем всмотреться рассчитает код HASH для этой операции, которая выглядит следующим образом:

a13c53fe822da398aaca7af59f064ae6f85c1d048fcb2ed77c3cacc137964a424deba679390df8d156e49c5fff7cdfc9fecec373a3cddd17e46ca9404096a52d

Этот хэш будет использоваться в дальнейшем в качестве имени chaincode.

VP сохраняет открытое соединение со всеми другими VP в сети и может транслировать транзакцию для всех из них (подробнее см. Описание консенсуса).
Каждый одноранговый узел будет использовать информацию из транзакции для создания изображения локального докера, необходимого для развернутого сетевого кода. Запустите новый контейнер докеров и выполните метод Init.

Если вы попытаетесь снова установить тот же код цепи, Fabric обнаружит, что цепочный код с таким именем уже развернут и пропустит инициализацию.

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

источник

2016-09-10 22:20:11

Спасибо Вам, Сергей, Для регистра, я на самом деле имея в виду следующее в hyperledger документ: .......... http://hyperledger-fabric.readthedocs.io/ ный/последняя/Setup/chaincode-установка/ запуска и регистрация chaincode Выполните следующую команду chaincode, чтобы начать и зарегистрировать chaincode с проверяющим пэром: CORE_CHAINCODE_ID_NAME = mycc CORE_PEER_ADDRESS = 0.0.0.0: 7051 ./chaincode_example02 Консоль сетевого кода отобразит сообщение «Received REGISTERED, ready for invocations», которое указывает, что цепочный код готов к отправке запросов. –

В этом примере описано, как запустить Fabric в режиме разработки (-peer-chaincodedev). В этом режиме вы можете запустить свой цепочный код с помощью произвольного имени. Chaincode будет запускаться как процесс в локальной среде (без контейнеров докеров). Разработчики могут использовать этот режим для целей отладки, потому что он работает быстрее и дает доступ к отладочным сообщениям из цепочного кода. –

Технически РЕГИСТР является частью сделки Развертывание

Chaincode обеспечивает развертывание Invoke, методы Query/API, чтобы взаимодействовать с ним. Когда вы говорите о развертывании chiancode, вы на самом деле говорите об конечном пользователе (или приложении), вызывающем метод Deploy на цепочном коде.

Перенастройка транзакции Deploy, запускает цепочный код в контейнере Docker, но обработка транзакций Deploy на этом не заканчивается. Существует слой прокладки на контейнере chaincode, который в действительности сообщает об этом со своим партнером. Это сообщение между слоем прокладки и равноправным пользователем определяется ChaincodeMessage. Существуют различные типы ChaincodeMessage (ов), как это определено с помощью этой декларации:

enum Type { 
    UNDEFINED = 0; 
    REGISTER = 1; 
    REGISTERED = 2; 
    INIT = 3; 
    READY = 4; 
    TRANSACTION = 5; 
    COMPLETED = 6; 
    ERROR = 7; 
    GET_STATE = 8; 
    PUT_STATE = 9; 
    DEL_STATE = 10; 
    INVOKE_CHAINCODE = 11; 
    INVOKE_QUERY = 12; 
    RESPONSE = 13; 
    QUERY = 14; 
    QUERY_COMPLETED = 15; 
    QUERY_ERROR = 16; 
    RANGE_QUERY_STATE = 17; 
}

Теперь цитировал из источника http://hyperledger-fabric.readthedocs.io/en/latest/protocol-spec/#33-chaincode:

Upon deploy (chaincode container is started), the shim layer sends a one 
time REGISTER message to the validating peer with the payload containing the 
ChaincodeID. The validating peer responds with REGISTERED or ERROR on 
success or failure respectively. The shim closes the connection and exits if 
it receives an ERROR.

Таким образом, вы получаете

10:08:38.450 [shim] DEBU : Registering.. sending REGISTER 
10:08:39.901 [shim] DEBU : []Received message REGISTERED from shim 
10:08:39.965 [shim] DEBU : []Handling ChaincodeMessage of type: REGISTERED(state:created) 
10:08:40.037 [shim] DEBU : Received REGISTERED, ready for invocations

, после чего ваш chaincode на самом деле готов для получения запроса и вызова.

источник

2016-10-09 08:06:44

Hyperledger chaincode «register» vs «deploy»

ответ

Смежные вопросы