블랙체인 전문가와 일문일답 정리

- 블록체인과 RDBMS의 결합 > 원장 상태 정보를 postgres에 저장하려는 연구가 있음.

- Hyperledger 같은 경우 내부 원장정보가 파일형태로 하나, 그리고 최신상태정보는 NoSQL로 저장됨. NoSQL로 graphDB로 저장해서 분석 용도로도 쓰임.

- 개인정보를 RDB에 저장하기도 함

- 블록체인에는 개인정보를 저장할 수 없음. 삭제가 안되기 때문. 이런걸 off-chain이라고 함.

- 개인정보는 RDB에 담고 키값이나 해시값을 가지고 운영하는 형태.

- 원장에 정보가 너무 많고 스키마 만들기도 힘들어서 기존 RDB는 사용하기 어려움.

- 원장 A가 가지고 있는 값이 계속 바뀌는데 이 바뀐 모든 정보를 다 가지고 있어야 함.

- 원장은 파일 형태로 계속 저장

- A 값을 모두 다 조회하려면 시간이 오래 걸려서 최종값을 가지고 있는 상태DB가 있음. 

- 블록체인 데이터가 저장되는 공간 자체를 원장이라고 함

- 블럭은 시간단위로 연결할지 아니면 트랜잭션 단위로 연결할지 설정 가능

-이런 상태 DB는 블록체인 플랫폼(예: IBM Hyperledger Fabric)에 위치함

- 상태DB는 levelDB나 couchDB를 사용함.

- 모든 피어에 상태 DB는 다 들어간다. peer = (블록체인엔진+원장파일+상태DB+합의엔진+인증서버) 통합 느낌.

- 기본 4개 피어로 한 세트 구성, 한 두개 peer가 죽어도 가용

- 하지만 재기동이 불편함. 그래서 쿠버네티스를 활용하기도 함.

- 블록체인 트랜잭션 = 데이터 insert, update 조회, 사용자 등록 ... 모든 트랜젝션 정보는 원장에 기록. delete 연산은 없음.

- 이런 트랜젝션 산정해서 인프라 설계함. 크지 않으면 클라우드로...

- 주 사용분야: 데이터에 대한 블랙박스, 타 기관간의 데이터 연계 혹은 공유, 이력정보 서비스, 안전 정보 자산 공유, 인증(DID)

- insert 예: A:10-->A:15->A:8 insert 3회 발생하면 이 이력이 기존 블록에 추가 됨

- REST api 형태로 insert/update/select 제공

- 사용자는 api 서버쪽으로 유도하고 api 서버가 블록체인 peer 서버와 통신

- 데이터거래소(user, POST, GET)  <-REST-> HLF API server(Helper.js, invoke-transaction.js, query.js) <-HLF SDK-> HLF blockchain(CA, Chaincode-channel)-block & stateDB)

- blockchain이 peer이고, 모든 peer는 같은 구성으로 되어 있음