middle block
왜 필요한지 먼저 알아보자.
블록체인으로 사업을 하려고 하는 회사는 처음에 이런 문제점들을 갖게 될 것이다.
- 추가 인력 고용(인권비 상승)
- 블록체인 전문가 찾기 (전문가가 별로 없을 뿐만 아니라 돈도 많이 주어야 한다.)
- 개발 장기간 개발 기간 (개발이 장기화 될 수록 비용은 늘어날 것이다.)
이런 문제들을 해결하기 위해 middle block 을 만들었다.
middle block 은 API롤 간단하게 블록체인을 구축 할 수 있어서
간단하기 때문에 개발 시간도 단축되며 블록체인에 대한 이해도가
낮더라도 충분히 개발 할 수 있다.
mibble block 의 did (decentralized identifier) 기술은 자신이 주최가 되어
자신의 신원 증명을 하는 것이다.
현재는 중앙화 되어있는 신원증명 시스템인데
중앙화 되어 잇을 경우 해커는 목표정하기가 쉬워진다.
중앙화 되어있는 그 기관 하나만 해킹하면 거기에 모든 정보를 갖을 수 있기때문이다.
실제로 뉴스를 보면 해킹된 기업이나 기관 얘기를 심심치 않게 들을 수 있을 것이다.
또한 기업은 개인 신원 정보를 이용하여 막대한 이익을 챙기는 경우가 많다.
이런 문제점을 해결하기 위해서 자신이 주체가 되는 신원 인증이 필요한 것이다.
Hyperledger indy 의 관한 내용
네트워크 구성
Vaildate node ( 노드 검증)
vaildato(검증자) 노드는 RBFT 구현인 Plenum 프로토콜에 의해 작동하며 주로 장부에 기록이 이루어짐
observer node (관찰자 노드)
원장읽기 전용 사본이며 아래 3가지 역할을 한다.
read requests : validate node의 성능에 영향을 주지 않고 id 레코드에 대한 수요가 확장될수있도록 함.
hot standbys(항시대기) : 기존 validate node 에서 기술적 문제가 발생할 경우 active validate node 로 서비스 전환 될 수 있음.
push subscriptions (구독): 이벤트 알림을 배포하는 수단을 제공함 .
p2p란?
(peer to peer network)
망구성에 참여하는 기계들의 계산과 대역폭 성능에 의존 하여 구성되는 통신망
여러대의 컴퓨터가 동등한 개념으로 망을 이룬다.
https://oriyong.tistory.com/92
agent (대리인)
에이전트는 p2p 메시징 엔드 포인트을 제공하여 일반적으로 자체 메시지이 엔드포인트를 제공하지 않는 인디 클라이언트의 통신을 용이
하게 합니다. sovrin 에이전트는 다양한 장치에서 작동하는 여러 sovrin 클라이언트 간에 메세지와 상태를 조정하며 agent 는 indy 키체인들의 암호화된 백업을 유지할 수 있고, ID 소유자를 위해 데이터를 단순하게 저저아하고 공유할 수 있습니다. indy 애소 아부분은
hyperledger aries 로 이전 됨.
sdk 란?
(software development kit)
프로그래머들을 위해서 제공하는 개발 도구들이다. 예를 들면 ios 응용프로그램을 개발하려면 ios sdk를 이용한다.
https://velog.io/@doomchit_3/%EC%9A%A9%EC%96%B4%EC%A0%95%EB%A6%AC-API-SDK-%EB%9E%80
app (client)
신원 소유자 들은 그들의 신원 정보를 indy 클라이언트를 통해 통제하고 관리하는데,
client의 가장 중요한 기능은 owner 의 키체인을 관리하고 보호하는 것으로 볼수있다.
indy sdk 클라이언트에 지갑기능이 있고 그지갑에 did관련 키가 저장되어 있다는 말.
did
사용자는 자신의 id 에 대해 기억할만한 이름을 만들어서 원장에 did 형식으로 변환하여 저장합니다.
did 는 탈중앙형 식별자로 pure DID는 암호학적 속성을 가지고 있지 않으며 version4 UUID를 사용하여 유니크하며 원장에 저장되고
원장에서 읽을 수 있습니다.
각 DID는 주어진 네트워크에서 특정한 method 사양과 연관되어 있으며, DID method 는 해당 네트워크에서 DID가 등록 , 확인,업데이트 및 해지 되는 방법에 대한 규칙을 지정 합니다.
DID Document
DID Document 에는 주로 해당 did 를 어떻게 검증 할수 있는지 에 대해서 나와있다. did 가 진짜 그사람의 소유인지를 확인하려면 DID의
쌍인 Private ket 를 가지고 있는지 확인하면 된다. Document 에 있는 did 소유자의 끝점을 통해 테스팅 할 수 있다. 또한 did 의 소유를 확인하기 위해서는 단일 소유주 뿐만 아니라 다양한 방식으로 테스트 할 수있는데 예를 들어 소유자가 회사의 구성원이라면 회사가 대신해서 검증 해 줄수 도 있을 것이다.
Verifiable credential (검증 가능한 자격증명)
정체성과 관련된 단일 속성을 Claim 이라고 하는데 claim 은 한명의 신분 소유자(사람 또는 조직)가 자신이나 다른 신분 소유자에 대해제공 하는 속성 정보를 말한다. 예를 들어 claim은 주민등록증 상의 나이를 나타낸다고 생각하면 된다.
2018년 Evernym 백서상에서 claim 들의 묶음인 claims라는 용어를 credential 로 바꿧다고 한다.
주민등록상 (혹은 주민등록증)의 모든 정보를 berifiable credential 이라고 하고, 해당 정보중 에 편의점에서 필요한 최소한의 노출정보를
verifiable presentation 이라고 한다.
claim(단일속성) -> credential(단일속성들의 전체합) -> presentation (노출시키고자 하는 속성만의 합)
interoperability of digital certificates (디지털 인증서의 상호 운용성)
디지털 인증서는 상호운용성을 보장하는 필수적인 형식인데. X.509는 식별자와 필요한 메타 데이터로 암호키를 바인딩하여 공개키 인증서를 정의하는 표준입니다. 이 X.509 인증서는 일반적으로 계충적 PKI 모델에서 작동하는 CA에 의해 배포되는 반면 DID 와 DDO는 디지털 아이덴티티가 피어로서 상호 운용될 수 있도록 합니다.검증 가능한 credential 을 상호작용, 연결 및 공유 할 때 peers는 필요에 따라 복수의 겹치는 "신뢰의 거미줄"을 형성하는데 X.509인증서를 생성하는 데 DID 및 DDO 핵심자료와 메타데이터를 사용할 수 있으며 ,X.509 인증서는 DID/DDO 모델과 함께 검증 가능한 Credential 으로 사용할 수있습니다. 이런식으로 두 모델 모두 서로와 상호작용을 될 수 있습니다.
'citylabs-study' 카테고리의 다른 글
6일차 study(용어 및 스터디 내용 점검) (0) | 2022.01.17 |
---|---|
5일차 study(hyperledger fabric - identity) (0) | 2022.01.14 |
4일차 study (hyperledger fabric) (0) | 2022.01.13 |
4일차 (신입 OJT) (0) | 2022.01.13 |
2일차 study(did API 실습) (0) | 2022.01.11 |