https://hamait.tistory.com/1063
DID / SSI 를 위한 블록체인 플랫폼 - Hyperledger Indy
Hyperledger Indy에 대해서 정리해봤습니다. Indy는 변화,발전되고 있으며, 인사이드에 대한 정밀한 조사,검증을 하진 않았기 때문에 참고용으로만 읽어 주십시요. * 최근에 자기주권 신원증명구조 분
hamait.tistory.com
블록그 글 분석을 중점으로
✔️ Hyper ledger Indy
- 공식문서
[개념]
Hyperledger Fabric과 Ethereum의 경우 Smart Contract/ChainCode 를 통해서 DID/SSI를 실현 할 수 있는 범용 플랫폼인 반면
Indy는
오직 DID를 구축하고자 하는 상황에 맞춤으로 만들어진 public(사용자) - permissioned (네트워크) 블록체인 플랫폼
* indy-sdk : 블록체인과 클라이언트간의 통신을 위한 API 개발 프로젝트
* Aries 프로젝트
did ,vc,vp 등 사용자가 직접 사용하는 상위 데이터 프로토콜을 개발하기 위한 프로젝트 .
목표 - 어떠한 블록체인, 분산저장소를 사용하든지 상관없이 독립적으로 동작할 수 있는 클라이언트 간의 SSI 통신 표준과 프레임워크 개발
* did / ssi
did는 탈중앙 신원증명이고 , ssi는 자기주권 신원증명. (decentralized ID / self sovereign identity)
✅ identifier (식별자) : 디지털 세상에서 내가 나임을 증명하기위한 식별자
✅ identity data : 나라는 개체가 어떤 정보, 속성을 가지고 있는지를 제시하고 증명하는 정보
식별자 - DID (분산아이디 ,탈중앙 신원증명)
identity data - 증명가능한 자격증명 (VC) , 증명가능한 제공 개인정보 집합 (VP) ... 등등
✅ identity Hub - 위와 관련된 데이터들이 저장되는 저장소 (스토리지)
@ Sovrin Foundation (개발조직: Evernym) 에서 제공된 코드 기반의 프로젝트
@ 사용자는 Public 이고 (아무나 사용가능)
@ 노드 관리는 Permissioned (선출된 대표노드: 일명 Steward가 Validation / Write 역할을 함)
-
1. A trust anchor is the highest ranking of reputation within the network. A trust anchor is initially vetted by the foundation and then maintains its ranking through observable activities and subsequent claims put forth by network members.
트러스트 앵커는 네트워크 내에서 평판의 가장 높은 순위입니다. 트러스트 앵커는 처음에 재단에서 심사한 다음 관찰 가능한 활동과
네트워크 구성원이 제기한 후속 claim을 통해 순위를 유지합니다. ???
2. Validator nodes can write to the ledger, observer nodes can only read from the ledger.
검증자 노드는 원장에 쓸 수 있고 관찰자 노드는 원장에서 읽을 수만 있습니다.
@ ZKP에 기반한 비 노출적 신원 증명 암호학 처리
@ ZKP에 기반한 비 연결적 Identity
- Indy의 Credential / ZKP기반은 Fabric의 Identity Mixer와 같으며 Camenisch-Lysyanskaya (CL) signature scheme or BBS+ 으로
어떤 속성에 대해서 올바른 서명을 알고있다는 것을 실제 서명 자체를 노출하지 않고도 증명 할 수 있는 방식
(Indy의 암호학적 근거에 대해서 더 자세하게 이해 하려면 https://www.evernym.com/white-papers/ : Evernym 백서인 핵심적인 레퍼런스를 읽어야 합니다.)
@ 자체적인 합의 시스템이 있다-> RBFT (PBFT에서 View Change 부분을 개선한 버전)
- 아래에 설명
@ 자신의 지갑에 개인정보 보관 및 관리 (지갑의 개념이 이더리움,비트코인의 그것보다 넓다. 즉 키 이외의 것도 저장)
@ 자체 장부를 가지고 있으며, 신뢰성있게 선출된 분산 장부에 Public 정보들을 저장 / 읽기 한다.
@ 보통 Agent라고 부르는 연관 End-Point 간에 암호화 된 연결 후 필요 정보 요청/검증 프로세스
@ 스마트 컨트랙트 기능은 없다.
[ 네트워크 구성 ]
Validate Node
- Write request를 처리하며, Plenum 프로토콜(RBFT 프로토콜 기반에서 조금 수정한 버전)에 의해 작동.
- RBFT 알고리즘이란 ?
PBFT 알고리즘에서 발생하는 view-change 실행시 성능 저하문제를 해결하기 위해 개발된 합의 알고리즘
✔️ PBFT 알고리즘 (비쟌틴 장애 허옹 - 네트워크 내에 배신자가 있더라도 합의 내용에 문제가 없도록 )
Safety 특징이 강조된 알고리즘.
장애 혹은 악의적인 노드 수가 f일 때 , 최소한 3f + 1 대의 노드가 존재하면 정상적인 합의가 가능하다는 것이
수학적으로 증명된 알고리즘
* safty 란?
합의 알고리즘의 특성(liveness 실시간 성 - 비트코인, 이더리움 등 , safety 안정성 - indy-node)중 하나로,
‘노드 간 합의가 발생했다면, 어느 노드가 접근하든 그 값은 동일해야 한다' 는 의미.
(블록체인의 finality와 동일한 개념)
* 왜 3f+1 이 최소한??
1. 장애 노드 f개가 존재할 시 N-f 대의 올바른 노드간 합의 알고리즘을 수행해야 함.
2. 악의적인 노드 f개가 존재할 시 , (N-f)-f대의 올바른 노드간 합의 과정을 수행해야 함
3. 합의를 수행하는 노드가 악의적인 노드 수보다 많아야 하므로, N - 2f > f__를 만족하는 최소값 __N = N - 3f+1 이 된다.
* 전제 조건
1. 메시지 전달이 지연, 실패, 혹은 무작위 순서인 비동기 네트워크 환경 을 허용
2. 악의적인 노드가 있다고 가정 (Byzantine Node 라고 명명)
3. 메시지는 언젠가는 전달
4. 메시지에는 비대칭키를 이용한 암호화 및 서명, 해시 등이 사용되며 암호 및 해시 함수는 안전하다고 가정
* 동작 과정
- client는 primary 노드에게 request 메시지를 전송
- primary 노드는 수신한 request 메시지를 모든 backup 노드에 전송
- backup 노드는 pre-prepare, prepare, commit 이라 불리는 3-phase 과정을 수행 후, 각자 도출한 결괏값을 client에 보냄
- client 노드는 f + 1 개의 동일한 응답을 받으면 정상적인 결괏값이 수신됐다고 판단 (악의 노드가 f개라 가정하기 때문)
Observer Node
사용자의 Read request를 처리하며 , Validator에 장애발생시 언제든 Validator가 될 수 있도록 대기상태를 유지한다.
validator node 의 3가지 역할
1. Read request : Validator Node의 성능에 영향을 주지 않고 ID레코드에 대한 수요가 확장될 수 있도록 함
(-> 무슨 말인지 정확히 모르겠으나 원장을 읽을 수 있다는 것 같음. 원장에 쓰는 것은 validator node만 가능)
2. Hot standbyes : 기존 Validate Node에서 기술적 문제가 발생할 경우 active validate Node로 서비스 전환될 수 있음
3. Push subscriptions : 이벤트 알림을 배포하는 수단을 제공함
Agent
에이전트는 P2P 메시징 엔드포인트를 제공하여 일반적으로 자체 메시징 엔드포인트를 제공하지 않는 인디 클라이언트의 통신을 용이하게 합니다.
Sovrin 에이전트는 다양한 장치에서 작동하는 여러 Sovrin 클라이언트 간에 메시지와 상태를 조정하며
Agent 는 Indy 키체인들의 암호화된 백업을 유지할 수 있고, ID 소유자를 위해 데이터를 단순하게 저장하고 공유할 수 있습니다.
Indy에서 이 부분은 Hyperledger aries로 이전되었다. (Aries를 이용해 P2P 통신)
* 요기서 '엔드 포인트'가 무엇인가?
- end point
커뮤니케이션 채널의 한 쪽 끝.
한마디로 서비스를 이용할 때 사용하는 커뮤니케이션 채널의 한쪽 끝에 해당하는 URI.
엔드포인트는 서비스를 사용가능하도록 하는 서비스에서 제공하는 커뮤니케이션 채널의 한쪽 끝.
즉 요청을 받아 응답을 제공하는 서비스를 사용할 수 있는 지점을 의미
예를 들어 지하철 최단 거리 경로를 제공하는 웹 서비스가 있다고 하자.
이 서비스를 이용하는 사용자는 출발역과 도착역을 설정하고 최단 경로를 찾는 버튼을 누른다.
이 때 최단 거리 경로를 구하는 서비스를 이용하기 위한 요청이 향하는 URI가, 엔드포인트이다.
이 웹 서비스는 유효한 형태로 엔드포인트에 요청이 전달되었을 경우 사용자가 알 필요 없는 서비스 내부 로직을 실행하고 응답을 반환한다.
App (Client)
신원 소유자들 (identity holder)들은 그들의 신원 정보를 Indy 클라이언트를 통해 통제하고 관리함.
여기서의 가장 중요한 기능은 Owner의 키체인을 관리하고 보호하는 것.
-> 쉽게 말해, indy sdk 클라이언트에 지갑기능이 있고, 그 지갑에 DID관련 키가 저장되어 있다는 말
--------------------------
DID document
- DID Docuement에는 주로 해당 DID를 어떻게 검증 할 수 있는지에 대해서 나와있다.
DID가 진짜 그 사람의 소유인지를 확인하려면 DID의 쌍인 Private key를 가지고있는지 확인하면 된다
-----------------
블록체인 원장
✔️ 순서대로 정렬된 트랜잭션 , 머클 패트리샤 트리 두가지 데이처를 블록체인 원장을 통해 관리함.
✔️ type 항목을 통해 어떤 트랜잭션인지 알수 있다 ( ex. type에 1이 적혀있으면 = NYM트랜잭션 )
✔️ 4가지 종류의 원장을 통해 데이터를 저장
1. Domain ledger
2. Config ledger
3. Pool ledger
4. Audit ledger
1. Domain ledger
DID와 같은 사용자의 신원인증과 관련된 데이터를 저장
Schema : 신원 증명 양식 중 사용자 속성에 대한 항목을 정의한 데이터
Credential definition : issuer가 Schema가 포함된 Credential definition에
사용자 속성값을 채운 뒤 추가적인 필드와 함께 가용자에게 신원증명을 발행한다.- NYM 트랜잭션
사용자의 DID document 관련 정보와 사용자를 어떤 권한을 가진 그룹으로 분류하는지에 대한 정보가 담겨 있다.
dest 항목의 DID가 이미 저장되어 있는 경우는 업데이트, 저장되어 있지 않은 경우는 신규 사용자 등록으로 간주
- SCHEMA 트랜잭션
사용자 속성에 대한 항목이 정의
VC를 발급하고자 할 경우, SCHEMA를 가져와서 양식에 맞게 채운 후 발급해줄 수 있다.
이 외에도 ATTRIBN, CLAIM_DEF, REVOC_REG_DEF 등의 트랜잭션 존재
2. Config ledger
사용자 권한 정보 저장 (public-permissioned 구조이므로)
블록체인 네트워크에 대한 다양한 설정 정보 저장
3. Pool ledger
블록체인 노드의 IP/port 등의 정보 저장
최초 블록체인 구동 시 사용하는 Genesis Transaction 에 최초의 블록체인 노드정보가 포함되어 있다.
NODE 트랜잭션
- 해당 트랜잭션을 전송하여 노드 CRUD 작업 수행이 가능
- dest 항목의 DID가 존재하는 경우 기존 노드 정보를 수정하며, 저장되어있지 않은 경우
새로운 노드를 추가
4. Audit ledger
앞의 3가지 원장에서 발생하는 트랜잭션을 모두 순서대로 취합하여 저장 (각 트랜잭션은 서로에세 의존성이 있기 때문)
서로 다른 원장간의 동기화 & 추가되거나 장애로부터 복구된 노드 업데이트를 위해 사용
사용자 그룹 별 권한
- 사용자를 5가지 그룹으로 분류해 관리
- 권한은 Trustee > Steward > Endorser > Network_Monitor > User 순
- None: common User
- 블록체인에 직접적으로 참여하지 않는 일반 사용자로서 블록체인 데이터를 읽어 오는 권한만 갖고 있는 그룹
- 0: Trustee
- indy-node 블록체인을 구동한 최초의 구성원들로 구성되며, 블록체인 운영에 관한 모든 권한을 갖는다.
- 2: Steward
- Trustee 그룹의 허가하에 블록체인 노드 운영 권한을 갖게된 그룹
- 101: Endorser
- 블록체인에 트랜잭션을 쓸 수 있는 권한을 갖는 그룹
- 201: Network Monitor
- 블록체인 노드의 장애 여부나 성능을 모니터링하는 그룹
✅ 기타 용어 정리
* w3c
- World Wide Web Consortium의 약자
웹기술의 표준을 정의하는 공식기관