Я использую Hyperledger Fabric 1.4.1 и последние версии fabric-contract-api для интеллектуальных контрактов, fabric-client для низкоуровневых API-интерфейсов для управления созданием каналов и цепных кодов и fabric-network для взаимодействия с коллегами.,Я сослался на этот пример для настройки моей сети.
Я написал базовый пакет с цепочечным кодом в nodejs и настроил простую сеть 1 org, 1 peer, 1 orderer.Первым шагом является подключение к равноправному узлу и использование fabric-ca-client для создания удостоверения администратора.В соответствии с примерами использовались идентификатор регистрации и секрет admin, adminpw.Это зависит от конфигурации , используемой здесь .
Код, который я использую для создания и присоединения к каналу с последующей установкой и созданием цепного кода:
const CAClient = require('fabric-ca-client');
const client = require('fabric-client');
const User = client.User;
const fs = require('fs');
const path = require('path');
const basePath = path.resolve(__dirname, '../certs');
const readCryptoFile = filename => fs.readFileSync(path.resolve(basePath, filename)).toString();
const ccPath = path.resolve(__dirname, '../chaincode/src/ax-chaincode');
const url = require('url');
const http = require('http');
let myClient = new client();
const ordererConfig = {
hostname: 'orderer0',
url: 'grpc://localhost:7050',
pem: readCryptoFile('ordererOrg.pem')
};
const orderer = myClient.newOrderer(ordererConfig.url, {
pem: ordererConfig.pem,
'ssl-target-name-override': ordererConfig.hostname
});
let peerConfig = {
hostname: 'ax-peer',
url: 'grpc://localhost:7051', // change to grpcs://ax-peer:7051 in some condition (no idea?)
eventHubUrl: 'grpc://localhost:7053',
pem: readCryptoFile('axOrg.pem')
};
const defaultPeer = myClient.newPeer(peerConfig.url, {
pem: peerConfig.pem,
'ssl-target-name-override': peerConfig.hostname
});
// console.log(defaultPeer);
myClient.setStateStore(await client.newDefaultKeyValueStore({
path: './ax-peer'
}))
let url = 'http://localhost:7054'
const ca = new CAClient(url, {
verify: false
});
let enrollmentID = 'admin';
let enrollmentSecret = 'adminpw';
const enrollment = await ca.enroll({
enrollmentID: 'admin',
enrollmentSecret: 'adminpw'
});
user = new User(enrollmentID, myClient);
// console.log(enrollment);
await user.setEnrollment(enrollment.key, enrollment.certificate, 'AxOrgMSP');
Выше будет проверено, доступен ли пользователь admin в хранилище состояний.Некоторые запросы, относящиеся к описанному выше процессу
- Сгенерированный здесь пользователь-администратор может использоваться для взаимодействия с любыми и всеми одноранговыми узлами одной и той же организации при условии, что используется только один ЦС?
- практическое использование этого идентификатора, поскольку для остальных функций используется идентификатор администратора, сгенерированный
cryptogen для каждого узла (код ниже) - При регистрации администратора никакие
attrs не передаютсяв ca.enroll(), поэтому, естественно, при запросе тождества поле roles возвращает ноль.Общая ссылка ca-server четко назначает ей роли client, user, peer, validator, auditor.Разве это не должно отражаться здесь, поскольку он использует admin и adminpw для регистрации идентификатора и секрета?
Продолжение кода
// crypto material got from cryptogen and shifted to new folder
let adminUser = await myClient.createUser({
username: `Admin@ax-peer`,
mspid: 'AxOrgMSP',
cryptoContent: {
privateKeyPEM: readCryptoFile('Admin@ax-org-key.pem'),
signedCertPEM: readCryptoFile('Admin@ax-org-cert.pem')
}
});
let txId = myClient.newTransactionID();
let envelope_bytes = fs.readFileSync('./channel.tx');
let channelConfig = myClient.extractChannelConfig(envelope_bytes);
let signature = myClient.signChannelConfig(channelConfig);
const request = {
name: 'default',
orderer: orderer,
config: channelConfig,
signatures: [signature],
txId: txId
};
const response = await myClient.createChannel(request); // should be 200
// rest of code joins channel, installs and instantiates chaincode
// docker logs show init function being called in new cc container
У stateStore есть два файлав нем (как и ожидалось), вызывается admin и Admin@ax-peer.Они выглядят как
"name": "Admin@ax-peer",
"mspid": "AxOrgMSP",
"roles": null,
"affiliation": "",
"enrollmentSecret": "",
enrollment: {
"signingIdentity": "554a5f5cfc5a59231a04b7b051bcbcb4f79c4226ff336a4aa48b551de4a8428f",
"certificate": "-----BEGIN CERTIFICATE----- xyz -----END CERTIFICATE-----"
}
Когда этот пользователь используется из хранилища состояний await myClient.getUserContext('admin', true);, как клиент подписывает транзакции?Я не могу найти закрытый ключ / сертификат для любого пользователя, созданного с помощью fabric-client SDK.
Теперь Если я использую fabric-network API, реализуется функция FileSystemWallet(), которая хранит закрытый и открытый сертификатдля каждого созданного им пользователя.
const enrollment = await ca.enroll({ enrollmentID: `admin`, enrollmentSecret: `adminpw` });
const identity = X509WalletMixin.createIdentity('AxOrgMSP', enrollment.certificate, enrollment.key.toBytes());
wallet.import('admin', identity);
Эта функция служит той же цели, что и ca.enroll(), но хранит частный сертификат видимым образом.Если я хочу использовать пользователей, созданных с помощью fabric-client в fabric-network SDK, мне нужно будет сдвинуть сертификаты, как мне этого добиться?
TLDR - Зарегистрируйте пользователя с помощью fabric-client и затем используйтеGateway() класс из fabric-network для отправки транзакций с одним и тем же пользователем.
Любые советы, рекомендации приветствуются.Спасибо!