HYPERLEDGER FABRIC - Developing Applications - Application design elements - Wallet
독자 : Architects, application and smart contract developers
wallet은 일련의 사용자 ID를 포함합니다.
사용자가 실행하는 application은 채널에 연결될 때 이러한 ID 중 하나를 선택합니다.
원장 같은 채널 리소스에 접근 권한은 MSP와 함께 조합안에서 ID를 사용하여 결정됩니다.
이번 주제에서는 아래의 항목을 다룰 것입니다.
Scenario (Why wallets are important)
application이 PaperNet과 같은 네트워크 채널에 연결할 때, ID1같은 사용자 ID를 선택합니다.
MSP 채널은 특정 조직안의 역할인 ID1과 연결되며, 이 역할은 궁극적으로 채널 리스소에 대한 application의 권한을 결정해야합니다.
예를 들어, ID1은 원장을 읽고 쓸 수 있는 MagnetoCorp 조직의 구성원으로서 사용자를 인식하는 반면, ID2는 컨소시엄에 새 조직을 추가하는 MagnetoCorp의 관리자를 식별할 수 있습니다.
두 명의 사용자인 Isabella와 Balaji는 서로 다른 네트워크 채널인 PaperNet과 BondNet에 연결하는데 사용할 수 있는 각각의 ID가 포함된 wallet을 가지고 있습니다.
MagnetoCorp의 Isabella와 DigiBank의 Balaji 두 사용자의 예를 고려해봅시다.
Isabella는 App1을 사용하여 PaperNet의 smart contract를 호출하고 BondNet에서 다른 smart contract를 호출합니다.
비슷하게, Balaji는 App2를 사용하여 smart contract를 호출하지만 오직 PaperNet에서만 사용할 수 있습니다. (application이 여러 네트워크와 여러 smart contract에 액세스하는 것은 매우 쉽습니다.(Developint Application - Applicatioon - Contruct request))
방법 보기 :
- MagnetoCorp는 ID발급을 위해 CA1을 사용하고, DigiBank는 CA2를 사용하여 ID를 발급합니다. 이러한 ID는 사용자 wallet에 저장됩니다.
- Balaji의 wallet은 CA2에 의해 발급된 ID4 단일 ID를 보유하고 있습니다. Isabella의 wallet은 CA1에 의해 발급된 ID1, ID2, ID3인 많은 ID를 보유하고 있습니다. wallet은 한 사용자의 여러 ID를 보유할 수 있으며, ID는 각각 다른 CA에서 발급될 수 있습니다.
- Isabella와 Balaji 둘 다 PaperNet에 연결하며, MSP는 그들의 ID를 발급한 CA에 의해 Isabella가 MagnetoCorp의 구성원이고, Balaji는 DigiBank의 구성원이라는 것을 결정합니다. (여러 CA를 사용하는 조직과 여러 조직을 지원하기 위한 단일 CA는 가능합니다.(Key Concepts - Membership Service Provider(MSP))
- Isabella는 PaperNet과 BondNet에 연결하기 위해 ID1을 사용합니다. 두 경우 모두 Isabella가 이 ID를 사용할 때, 그녀는 MagnetoCorp의 구성원이라고 인식됩니다.
- Isabella는 BondNet에 연결하기 위해 ID2를 사용합니다. 이 경우 그녀는 MagnetoCorp의 관리자로 인식됩니다. 이것은 Isabella에게 두가지 다른 권한이 주어지는 것입니다. ID1은 그녀를 BondNet 원장을 읽고 쓸 수 있는 MagnetoCorp의 단순한 구성원으로 식별하는 반면에 ID2는 BondNet에 새 조직을 추가할 수 있는 MagnetoCorp의 관리자로 식별됩니다.
- Balaji는 ID4를 사용해 BondNet에 연결하지 않습니다. 그가 연결을 시도하면, ID4는 CA2가 BondNet의 MSP에 알려지지 않았기 때문에 DigiBank에 속한 것으로 인식되지 않습니다.
Types (How wallets are organized)
ID를 저장하는 위치에 따라 다양한 유형의 wallet이 있습니다.
네 가지 유형의 wallet : File system, In-memory, Hardware Security Module (HSM), CouchDB
- FileSystem : wallet을 저장하는 가장 일반적인 장소입니다. file system은 널리 퍼져있고, 이해하기 쉬우며, 네트워크에 마운트될 수 있습니다. wallet의 좋은 기본 선택입니다.
FileSystemWallet 클래스를 사용하여 file system wallet을 관리합니다. - In-memory : application storage내의 wallet. 당신의 application이 file system에 액세스하지 않고 제한된 환경에서 실행될 때 이 유형의 wallet을 사용하세요. 일반적으로 웹 브라우저입니다. 이 유형의 wallet은 휘발성이라는 것을 잊지마세요. ID는 application이 정상적으로 종료되거나 충돌하면 손실됩니다.
InMemoryWallet 클래스를 사용하여 in-memory wallet을 관리합니다. - Hardware Security Module : wallet은 HSM에 저장됩니다. 매우 안전한 변조 방지 장치는 디지털 ID 정보 특히 개인키를 저장합니다. HSM은 컴퓨터에 로컬로 연결하거나 네트워크에 액세스할 수 있습니다. 대부분의 HSM은 개인키가 HSM을 절대 벗어나지 않도록 개인 키를 사용하여 온보드 암호화를 수행하는 기능을 제공합니다.
현재 HSMWalletMixin 클래스와 함께 FileSystemWallet를 사용하여 HSM wallet을 관리합니다.
HMS (en.wikipedia.org/wiki/Hardware_security_module) - CouchDB : wallet은 CouchDB에 저장됩니다. 이는 가장 드문 형태의 wallet storage이지만, 데이터베이스 백업 및 복원 메커니즘을 사용하려는 사용자에게 CouchDB wallet은 recovery를 단순화하는 유용한 옵션을 제공할 수 있습니다.
CouchDBWallet 클래스를 사용해서 CouchDB wallet을 관리합니다.
Structure (Different types of wallet)
단일 wallet은 특정 인증 기관에서 발급 한 여러 ID를 보유할 수 있습니다.
각 ID에는 설명 레이블, 공개키가 포함된 X.509 인증서, 개인키, 일부 Fabric 관련 메타 데이터로 구성된 표준 구조가 있습니다.
다른 wallet 유형은 이 구조를 그들의 저장 매커니즘에 적절하게 매핑합니다.
Fabric wallet은 다른 인증 기관으로부터 발급한 인증서의 여러 ID를 보유할 수 있습니다. ID는 인증서, 개인키, Fabric 메타데이터로 이루어져있습니다.
wallet과 ID를 쉽게 관리할 수 있는 몇가지 주요 클래스 메서드가 있습니다.
const identity = X509WalletMixin.createIdentity('Org1MSP', certificate, key);
await wallet.import(identityLabel, identity);X509WalletMixin.createIdentity() 메서드가 메타데이터 Org1MSP, certificate, private key를 가진 ID를 어떻게 생성하는지 살펴보세요.
wallet.import() 는 특정 identityLabel의 wallet에 이 ID를 add합니다.
Gateway 클래스는 ID를 설정하기 위해 mspid 메타데이터만 요구합니다. (위 예의 Org1MSP)
예를 들어, 특정 알람 전략(hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/connectoptions.html)이 요구 될 때, 그것은 현재 이 값을 connection profile(Developing Applications » Application design elements » Connection Profile)로부터 특정 peer를 식별하기 위해 사용합니다.
DigiBank gateway file networkConnection.yaml에서, Org1MSP 알림이 peer0.org1.example.com와어떻게연결되는지확인하세요.
organizations:
Org1:
mspid: Org1MSP
peers:
- peer0.org1.example.com
다른 wallet 유형의 내부 구조에 대해서는 걱정할 필요 없지만, 관심이 있다면 기업 어음 예제의 사용자 ID 폴더로 이동하세요.
magnetocorp/identity/user/isabella/
wallet/
User1@org1.example.com/
User1@org.example.com
c75bd6911aca8089...-priv
c75bd6911aca8089...-pub
이러한 파일을 볼 수 있지만, 설명한대로 SDK를 사용하여 이런 데이터를 조작하는 것이 더 쉽습니다.
Operations (Wallet operations)
다른 wallet 클래스는 ID를 관리하기 위한 표준 API들을 제공하는 일반적인 Wallet(fabric-sdk-node.github.io/master/module-fabric-network.Wallet.html) base 클래스로부터 파생됩니다.
application이 wallet 저장 메커니즘 아래에 독립적으로 만들어질 수 있음을 의미합니다.
예를 들어, File system과 HSM wallet은 매우 유사한 방식으로 처리됩니다.
wallet은 수명주기를 따릅니다. create되고 open되고, identity가 read되고, add되며, delete되고 export됩니다.
application은 간단한 라이프사이클에 따라 wallet을 사용할 수 있습니다.
wallet은 open되고 create되고 이후에 ID를 add, read, update, delete, export할 수 있습니다.
JSDOC(fabric-sdk-node.github.io/master/module-fabric-network.Wallet.html)의 다른 wallet 메서드의 작동방식도 확인해보세요.
기업 어음 튜토리얼은 addToWallet.js의 좋은 예를 제공합니다.
const wallet = new FileSystemWallet('../identity/user/isabella/wallet');
const cert = fs.readFileSync(path.join(credPath, '.../User1@org1.example.com-cert.pem')).toString();
const key = fs.readFileSync(path.join(credPath, '.../_sk')).toString();
const identityLabel = 'User1@org1.example.com';
const identity = X509WalletMixin.createIdentity('Org1MSP', cert, key);
await wallet.import(identityLabel, identity);
방법을 확인하세요.
- 프로그램이 처음 실행되면, wallet은 로컬 파일 시스템 .../isabella/wallet에서 생성됩니다.
- 인증서 cert와 개인 key는 파일 시스템에서 로드됩니다.
- 새로운 ID는 X509WalletMixin.createIdentity()를 사용해서 cert와 key 그리고 Org1MSP로 만들어집니다.
- 새로운 ID는 라벨 User1@org1.example.com과 wallet.import()으로 wallet에 import됩니다.
wallet에 대해 알아야 할 모든 것입니다.
Fabric 네트워크 리소스에 액세스하기 위해 사용자를 대신하여 application에서 사용하는 ID를 보유하는 방법을 확인했습니다.
application 및 보안 요구사항에 따라 다양한 유형의 wallet을 사용할 수 있으며, application이 wallet과 그 안의 ID를 관리하는데 도움이 되는 간단한 API가 있습니다.
출처 ]
hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/wallet.html