블체인으 변화될 미래의습 - krnet.or.krb9%da%bc%bc%bf%ad_blo… · 트랜잭션n...

1Page© 2017 IBM Corporation

© 2017 IBM Corporation

V4.0 June 27

블록체인으로 변화될미래의 모습

블록체인 기술의 이해와 응용

KRnet 2017

J1 : Blockchain 세미나


산업별 블록체인 활용 전망

대중 수용자

51%추종자

34%

선구자

15%

2018 20202017

대중 수용자56%

추종자30%

선구자14%

2018 20202017

은행 산업 자본시장 산업

Source: IBM Institute for Business Value analysis

2017년에 대규모로 상용솔루션 구축을 예상하는 선구자 그룹이 블록체인 적용을선도할 것으로 예상됨


산업별 블록체인 활용 전망

대중 수용자58%

추종자28%

선구자14%

2018 20202017

헬쓰 산업 전자 산업

Source: IBM Institute for Business Value analysis

2017년에 대규모로 상용솔루션 구축을 예상하는 선구자 그룹이 블록체인 적용을선도할 것으로 예상됨

대중 수용자

56%추종자

29%

선구자

16%

2018 20202017


정부기관의 블록체인 활용 전망

대중수용자

48%추종자

38%

선구자

14%

2018 20202017Source: IBM Institute for Business Value analysis

대규모로 상용솔루션 구축을 예상하는 선구자 그룹은 올해 14%, 3년내 62%가블록체인 적용을 선도할 것으로 예상됨


은행산업의 선구자그룹 비즈니스 모델

선구자 그룹은 참조데이터, 소비 지급, 소비자 대출의 3가지 사업분야가 가장 큰혜택을 받을 것으로 조사됨

Source: IBM Institute for Business Value analysis,

83% | 59% 80% | 60% 79% | 64% 77% | 70% 77% | 63% 74% | 60% 73% | 67% 71% | 58%

소비 지급 기업대출 담보대출참조 데이터 소비자 대출 기타 현금관리

무역금융 예금

69% | 67%

국제 지급

시간, 비용, 리스크에 미치는 블록체인 영향(통합 점수)

선구자그룹 기타은행


자본시장의 선구자그룹 비즈니스 모델

선구자 그룹은 청산 및 결제, 도매 지급(wholesale payment), 주식 및 채권 발행의3가지 사업분야가 가장 큰 혜택을 받을 것으로 조사됨

Source: IBM Institute for Business Value analysis, 선구자그룹 기타

비용, 투명성 및 불변성에 미치는 블록체인 영향(통합 점수)

79% | 59% 79% | 59% 75% | 64% 75% | 63% 71% | 65% 69% | 69% 69% | 63% 67% | 67%

도매 지급 담보관리 기업활동청산 및 결제 주식 및채권 발행

참조 데이터 인증 및KYC

신디케이트론


전자산업의 선구자그룹 비즈니스 모델

선구자 그룹은 자산 및 재고관리, 부품 출처추적, 엣지 컴퓨팅의 3가지사업분야가 가장 큰 혜택을 받을 것으로 조사됨


보증 및서비스 관리

자산 및 재고관리

90% | 65% 89% | 61% 89% | 56% 87% | 61% 82% | 60% 82% | 59% 81% | 57% 79% | 58%

운영데이터

부품 출처추적

디지털마켓플레이스

엣지컴퓨팅

공급망 관리규제준수



헬스산업의 선구자그룹 비즈니스 모델

선구자 그룹은 임상시험 레코드, 규제준수, 의료/헬쓰 데이터의 3가지사업분야가 가장 큰 혜택을 받을 것으로 조사됨

Source: IBM Institute for Business Value analysis,

청구 및클레임

임상시험레코드

76% | 63% 74% | 62% 72% | 56% 69% | 61% 69% | 56% 67% | 59% 63% | 57% 62% | 58%

약물/치료규제준수 의료기기데이터

의료/헬쓰레코드

자산 관리부작용

58% | 56%

계약 관리


선구자그룹 기타


정부기관의 선구자그룹 비즈니스 모델

자산 관리규제 준수

100% | 88% 100% | 90% 100% | 82% 100% | 92% 97% | 86% 97% | 91% 97% | 86% 93% | 85%

인증 관리계약 관리 금융트랜잭션

투표시스템

Citizen services

Borderlessservices

선구자 그룹은 규제 준수, 계약 관리, 투표시스템의 3가지 사업분야가 가장 큰혜택을 받을 것으로 조사됨



Contents is Blockchain?

is it relevant

for our business?

can IBM help

us apply Blockchain?


First Projects

Use cases


비즈니스 네트워크(Business Network)의 모든 참여자들이 원장(Ledger)을 볼 수 있도록해주는 공유 원장 기술 (shared ledger technology)

블록체인이란 …

노드

1. 제조사

2. 딜러

3. 리스 회사4. 리스 사용자

5. 폐차장

감독기관

공유 원장 스마트 계약

노드

노드노드

노드 노드

자산이전을위한 조건

자산 이전에대한 기록들


블록체인 종류

블록체인 종류

e.g. Bitcoin ..for business

현재 시스템

source : https://www.weforum.org/agenda/2015/11/how-will-blockchain-technology-transform-financial-services/


블록체인 요약

Time

Less secure More secure

Hash

Transaction Log

시간순서상으로기록된 암호화된

원장

Central Network Distribute NetworkPBFT 솔루션

합의 알고리즘(consensus)

PBFT, PoW, PoS


비즈니스네트워크내에 모든

거래가 기록되고공유됨

비즈니스 규칙 및로직은 계약에함축되어 트랜잭션수행시 실행됨

검증된 트랜잭션에대한 네트워크에참여한 참여자의동의가 필요함

원장은 공유되지만,

참여자의 개인정보는암호화 기술을 통해서

보호되어야 함Privacy

(프라이버시)

Shared

ledger

(공유원장)

… 참여확대, 비용절감, 효율성 증대

Smart

Contract

(스마트 계약)

Consensus

(합의)

비즈니스를 위한 블록체인…


is it relevant

for our business?

can IBM help


15Page

First Projects

Use cases© 2017 IBM Corporation


시간 절약 비용 절감 위험 감소 신뢰 확산

거래처리 시간이일(days)단위에서 준

실시간 처리

중개자의 오버헤드및 비용 감소

조작, 사기 및 사이버범죄 감소

공유 프로세스 및기록을 통해 신뢰

확보

블록체인 장점


비즈니스를 위한 블록체인 특징

Privacy

(프라이버시)

Shared

ledger

(공유원장)

Smart

Contract

(스마트 계약)

Consensus

(합의)

구성요소

합의 (Consensus)

자산추적성 (Provenance)

불변성 (Immutability)

최종성 (Finality)

특징


is it relevant

for our business?

can IBM help


18Page

First Projects



리눅스 재단의 하이퍼레저 프로젝트

www.hyperledger.org

Brian Behlendorf

Executive Director

Blythe Masters

Board Chair

Chris Ferris

TSC Chair

– 리눅스 재단의 Hyperleder 프로젝트는 2015년 12월17일에 17개 회원사로 시작되었으며, 현재 130개회원사가 참여하고 있음

– Hyperledger 프로젝트는 전세계적으로 비즈니스 거래가수행되는 방식을 변혁할 수 있는 분산 원장에 대한 산업표준에 중요한 기능들을 확인하고 적용하여 블록체인을발전시키기 위한 협력 프로젝트임

– 오픈 소스, 오픈 표준, 오픈 거버넌스 기반

– 1개의 Active 프레임워크(“Fabric”)과 4개의 인큐베이터

Enable adoption of shared ledger technology at

a pace and depth not achievable by any one

company or industry

http://www.hyperledger.org/


하이퍼레저 프로젝트 > 회원사

QUICK FACTS

Chairman Blythe Masters/DAH

Executive Director

Brian Behlendorf

Technical Chair Chris Ferris/IBM

Contribution44,000 lines of code in February 2016

Sprint to one codebase with

unified thinkingStaged releases

Chairman Blythe Masters/DAH

Executive Director

Brian Behlendorf

Technical Chair Chris Ferris/IBM

Contribution44,000 lines of code in February 2016

Sprint to one codebase with

unified thinkingStaged releases

준회원

프리미어 회원(18) 일반회원

Source: https://www.hyperledger.org/about/members

Updated April 2017

https://www.hyperledger.org/about/members


분산공유원장








(프라이버시)

Shared

ledger

(공유원장)


Smart

Contract

(스마트 계약)

Consensus

(합의)


분산원장의 구조

블록 1000

이전블록 해쉬값

블록생성시간

트랜잭션 해쉬값

트랜잭션

차량등록증생성

블록 1001


블록생성시간


트랜잭션

차량등록증이전감독기관->제조사

블록 1002


블록생성시간


트랜잭션

차량등록증갱신

블록 1003


블록생성시간


트랜잭션

차량등록증이전제조사 -> 딜러

블록 1004


블록생성시간


트랜잭션

차량등록증이전딜러 -> 리스회사

블록 1005


블록생성시간


트랜잭션

차량등록증이전리스회사 ->사용자

블록 1006


블록생성시간


트랜잭션

차량등록증이전사용자 ->폐차업체

블록 1007


블록생성시간


트랜잭션

차량등록증폐기


블록 및 트랜잭션

{

"transactions": [

{

“type”: 3,

“chaincodeID”: “EoABNmU5MGVkNjQzZTg4OGM3OTFlZT・・・”,

“payload”: “CqsBCAESgwESgAE2ZTkwZWQ2NDNlODg4Yzc5MWVlMGE1MjgzND・・・",

"uuid": "5edbcc1c-41f1-47bd-a21f-fa0b6912c668",

"timestamp": {

"seconds": 1457340858,

"nanos": 829120056

},

“cert”: “MIIB/zCCAYSgAwIBAgIBATAKBggqhkjOPQQDAzApMQswC・・・”,

“signature”: “MGUCMDOaV0uvwNO0xZM+・・・”

}

],

“stateHash”: “FXFL5whKH8tsJlXffybWYn2enDmcCeP2OMWBywwlKn5・・・”,

“previousBlockHash”: “cb5TSoINEAGiRJpxAvYXFlQ0O2MBAD8hl9zlV3・・・”,

"nonHashData": {

"localLedgerCommitTimestamp": {

"seconds": 1457340858,

"nanos": 936184231

}

}

}

차량등록증 생성

트랜잭션

트랜잭션 해쉬값이전블록 해쉬값

블록생성시간

블록1000

블록 1000


블록생성시간


트랜잭션

차량등록증생성


원장 스토리지

트랜잭션 1000

트랜잭션 1001

트랜잭션 1002분산원장KVS

트랜잭션 데이터의 및Key-Value 저장소의해쉬값을 이력을 보관

해시가 되지않은트랜잭션인 프로그램데이터는 분산원장과는별도로 보관

체인코드에서 API를사용하여 데이터를읽거나 실행결과(원장스냅샷)을 저장

모든 VP(Validating Peer) 노드는 LevelDB 또는CouchDB를 기반으로

동일한 데이터가 저장됨

검증노드(Validating Peer) 노드는 NoSQL 데이터베이스인 LevelDB나 CouchDB로 key-value 형식의데이터베이스가 설치되어 있으며, “분산 원장”, “트랜잭션”, “체인 코드(옵션)” 데이터가 저장됨

분산원장 트랜잭션 Key-Value 스토어

LevelDB CouchDB


스마트 계약








(프라이버시)

Shared

ledger

(공유원장)


Smart

Contract

(스마트 계약)

Consensus

(합의)


스마트계약(Smart Contract)/체인코드(Chaincode)

A smart contract is an event driven program, with state, which

runs on a replicated, shared ledger and which can take custody

over assets on that ledger. [Swanson2015]

현대화된 암호화 원장(Ethereum, Hyperledger)들은스마트계약이나 체인코드를 지원하는 것으로 목표로 하고 있음

“Smart contract” (replicated) state machine


블록체인 참여자 합의에 의해 업데이트됨

합의(Consensus)라는 시스템 기반의 합의 형성 구조는 블록체인을 적절히 사용하여 운용하는 데 매우중요한 개념임

b(n) b(n+1) b(n+2) b(n+3) b(n+4)

n번째 블록 n+1번째 블록 n+2번째 블록 n+3번째 블록 n+4번째 블록

승인된트랜잭션



합의(Consensus)

미승인된트랜잭션

블록체인 네트워크

참여자(노드)

참여자(노드)

참여자(노드)

참여자(노드)

승인된 트랜잭션


하이퍼레저 패브릭의 블록 구조

블록 n

이전블록(n-1) 해쉬값(512 bits)

블록생성시간(타임스탬프)


트랜잭션

트랜잭션0

버전번호

KVS(Key-Value Store) 해쉬값

합의 메타데이터(선택)

블록 메타데이터

트랜잭션1

트랜잭션 n∙∙∙∙∙

블록 n+1

이전블록(n) 해쉬값(512 bits)

블록생성시간(타임스탬프)


트랜잭션

트랜잭션0

버전번호

KVS(Key-Value Store) 해쉬값

합의 메타데이터(선택)

블록 메타데이터

트랜잭션1


암호화 해쉬함수를 사용하여 블록구조를 저장함으로써 과거의 트랜잭션 정보가 훼손되지 않도록 보호함. 블록구조는Bitcoin의 경우와 거의 동일하지만, Key-Value Store(KVS)의 해쉬값도 기록되는 점이 특징임

✓ 이전블록의 해시 값은512 bits(64 bytes)에서SHA3 SHAKE256

계산됨✓ 블록의 메타데이터는

각 노드에서 자유로운값을 넣는다(해시계산에서 제외됨)


체인코드(스마트계약 실행기반)

체인코드 예

처리(프로그램) :작성 { }

소유권이전 { }

속성변경 { }


참여자(검증노드)




분산원장

분산원장

분산원장

분산원장

CC KVSCC KVS

CC KVSCC KVS

✓체인코드(프로그램)는 모든 검증노드에 배포됨✓검증노드는 체인코드를 Docker 컨테이너에 배포하고 실행함✓하이퍼레저 패브릭은 『트랜잭션』=『체인코드 (스마트 계약)의 실행』✓자산의 최신 상태는 Key-value 저장소에 저장함✓계약 조건이나 규칙을 비즈니스 로직으로 스마트 계약에 구현함으로써 항상 합의 된 규칙에 따라 처리가

수행됨


검증노드의 구성

분산원장✓ 블록체인 자체✓ 트랜잭션 (스마트 계약의 처리 호출)가 로그처럼 기록됨

체인코드(스마트계약)✓ 트랜잭션을 계기로 실행되는 프로그램✓ 똑같은 체인코드가 모든 검증노드에 배포되어 샌드박스(Docker 컨테이너)에서

실행됨✓ 사용 목적별로 여러 체인코드가 만들어짐

Key-Value Store✓ 트랜잭션을 실행 한 결과 얻어지는 "최신 상태"를 기록함

• Key = chaincode ID + cKey• Value = 임의의 데이터

✓ 모든 검증노드에서 동일한 내용을 갖고, 그 해쉬값이 블록 체인에 기록됨✓ 변경 상태(자산의 이전등)가 관리됨

분산원장

블록체인

CC CC CC∙∙∙∙∙

체인코드(스마트 계약)

KVS

Key-Value Store

("chaincode state", "world state“

이라고도 명명됨)

참여기관(검증노드의 구성)


트랜잭션에 의해 스마트계약에 정의된 작업이 수행됨






분산원장

분산원장

분산원장

분산원장

SC1 KVSSC1 KVS

SC1 KVSSC1 KVS

홍길동(클라이언트)

“홍길동”에서 “김길동”

으로 자산 “XYZ” 이전

트랜잭션 =

소유권 이전 처리의 호출

김길동(클라이언트)

트랜잭션 실행전

SC1 / 자산 ID : xyz123소유자 : 홍길동자산유형 : 자동차등록 정보 : xxxxxx

처리(프로그램) :작성 { }

소유권이전 { }

속성변경 { }

SC1 / 자산 ID : xyz123소유자 : 김길동자산유형 : 자동차등록 정보 : xxxxxx

트랜잭션 실행후


Key-Value Store의 해쉬 계산방법

ROOThash(A,B)

Ahash(C,D)

Bhash(E,F)

Chash(000)

Dhash(001)

Ehash(002)

Fhash(003)

Data Block000

Data Block001

Data Block002

Data Block003

블록체인에 기록되는 값

개별 Key-Value 데이터 쌍

트리구조에서 해쉬값을 계산하고 있기때문에 KVS의 데이터가 변경된 경우에도최소한의 해쉬계산에 전체의 해쉬값을계산함✓ 머클 해쉬 트리(Merkle Hash Tree)

함수 사용

“Data Block 003”이 변경된 경우에해쉬값을 다시 계산 이루어지는 점


비트코인(Bitcoin) 트랜잭션 비교(1/3)

비트코인(Bitcoin)을 가지고 A가 B에게 송금하는 경우

✓ A는 "B에게 몇 비트 코인을 보냅니다"라는 트랜잭션에 서명을 함으로써 성립✓ 이때 A는 자신이 가지고있는 비트코인을 받은 트랜잭션에 대한 참조와 수령자인 B의 공개키를 붙인 후에

자신의 개인키로 서명

서명

사용자 Z

사용자 Z -> 사용자 A

송금 트랜잭션


거래금액

Z의 서명

A의 공개키

서명

사용자 A

사용자 A -> 사용자 B

송금 트랜잭션


거래금액

A의 서명

B의 공개키

서명

사용자 B

사용자 B -> 사용자 C

송금 트랜잭션


거래금액

B의 서명

C의 공개키



비트코인(Bitcoin)은 Unspent Transaction Output (UTXO) 방식을 사용

✓ 하나의 주소 (지갑)에 들어있는 여러 트랜잭션의 입금을 모아 여러 사람 주소로 전송하는 것이 가능

입금

출금A에게 1 BTC송금

사용자 X

입금

출금A에게 2 BTC송금

사용자 Y

입금

출금 A에게 0.5 BTC 송금

사용자 Z

입금

출금

사용자 A

1 BTC 입금 기록

2 BTC입금 기록

0.5 BTC 입금기록

B에게 1.5 BTC 송금

C에게 1.8 BTC 송금

A에게 0.2 BTC 송금

잔돈은 본인에게 송금

3.5 BTC



분류 Smart Contract형 UTXO형

구조

요약

처리에 대한 요청 메시지를 트랜잭션으로 표현하고 처리결과를 유지하기 위해 현재의 상태 (잔액 및 보유 자산등)를 확인하기 위해 과거의 트랜잭션을 추적 할 필요가없음

트랜잭션 데이터의 입력, 출력 형태로 표현하고, 현재 상태(잔액 및 보유 자산 등)를 확인하기 위해서는 과거의트랜잭션을 추적 할 필요가 있음

용도Smart Contract로 트랜잭션 처리를 기술 및 실행함으로써, 다양한 종류의 트랜잭션을 처리 할 수 있음

디지털 화폐의 이전 등 특정 유형의 트랜잭션에 제한됨

잘못 사용된 트랜잭션 검증Smart Contract에 원칙적으로 잘못 사용된 트랜잭션에대한 확인을 기술하고 Smart Contract실행시 오류로 처리함

합의를 수행할 때 트랜잭션 내용의 정당성(예 :이중 사용) 에 대해서도 각 노드가 검증

대표적인 구현 예 하이퍼레저(Hyperledger), 이더리움(Ethereum) 비트코인(Bitcoin), DAH, chain.com

블록


블록생성시간


트랜잭션트랜잭션0

버전번호

트랜잭션1


처리결과데이터


체인코드 관련처리

배포(Deploy)✓ 소스코드에 따라 체인코드를 등록✓ 원장에 기록됨(새로 배치했다는 정보가 기록됨)

호출(Invoke)✓ 체인코드를 실행함✓ KVS에 데이터를 읽고 저장함✓ 원장에 기록됨

조회(Query)✓ 체인코드에 데이터 조회함✓ KVS에서 데이터 읽기만 수행함✓ 원장에 기록하지 않음

CC1

분산원장

CC1 분산원장

KVS

CC1 KVS

주요 체인코드 관련 처리 (가상머신에서 수행)


이벤트 허브

검증노드(Validating Peer)와 체인코드는 응용 프로그램이 완료를 기다렸다가 동작을수행하기 위해 네트워크에 이벤트를 실행할 수 있음. 미리 정의 된 이벤트도 있지만, 체인코드 자체의 이벤트를 정의하고 발행 할 수 있음

검증노드(Validating Peer)웹 어플리케이션

처리1

(이벤트대기)

처리2

트랜잭션

체인코드

이벤트


체인코드의 상태를 저장하는 데이터베이스

Hyperledger의 체인코드는 데이터베이스로 키(Key)와 값(Value)의 쌍으로 데이터를 등록하는 KVS 방식의LevelDB또는 CouchDB를 채용하고 있으며, RocksDB은 오픈소스 데이터베이스로 ORACLE, MySQL 과같은 관계형 데이터베이스와 비교하여 데이터베이스 스키마를 유연하게 변경할 수 있는것이 특징임.

KVS

전체 검증노드(Validating

Peer)에 존재하고 동일한데이터가 저장됨

키(Key) 값(Value)

CC1:Asset-1-Manufacturer Hyundai

CC1:Asset-1-Holder Manufacturer

CC1:Asset-1-Price 60,000,000 Won

CC1:Asset-2-Manufacturer Toyota

CC1:Asset-2-Holder Lease

CC1:Asset-2-Price 45,000,000 Won

∙∙∙∙∙ ∙∙∙∙∙

CC

PutState (“Asset-1-Holder”,

“Manufacturer” )

CC

GetState (“Asset-2-Holder”)

“Lease”

가상머신에서체인코드

실행

키의 체인코드의 ID가 접두어로 지정되기때문에 다른 체인코드의 데이터끼리충돌하는 것은 아님

LevelDB CouchDB


체인코드 구현

✓ 체인코드 개발자는 Chaincode 인터페이스를 구현하는 형태로 비즈니스 로직을 구현함✓ 체인코드는 ChaincodeStub 클래스의 인스턴스를 호출하는 형태로 데이터베이스에 접근함

Chaincode <interface>

// 상태를 기록하는 처리+ Run(stub: ChaincodeStub, function: string,

args []string): ([]byte, error)

// 상태를 조회하는 처리+ Query(stub *ChaincodeStub, function string,

args []string) ([]byte, error)

BusinessLogicChainCode

+ Run(stub: ChaincodeStub, function: string,

args []string): ([]byte, error)

+ Query(stub *ChaincodeStub, function string,

args []string) ([]byte, error)

개발자가 직접 구현

ChaincodeStub

+ UUID: string //체인코드 ID

// KVS 처리+GetState(key: string)

+ PutState(key: string, value: []byte)

+ DelState(key: string)

+ RangeQueryState(startKey, endKey string)

(*StateRangeQueryIterator, error

// KVS 테이블처리+ CreateTable(name string, columnDefinitions []*

ColumnDefinition)

+ InsertRow(tableName string, row Row) (bool, error)

+ DeleteTable(tableName string) error

+ GetRows(tableName string, key []Column) (<-chan

Row, error)

체인코드 사양 설명 KVS와 통신 담당

<<use>>

1 1


체인코드 구현 예제(단순 송금시스템 : 호출)

Go

함수이름에 따라처리 배분

지불을 “payment” 함수로 구현

(다음페이지에서 설명)


구현 예제(payment 함수)

변수 선언과 전처리

1. KVS에서 사용자 A의 잔액 조회

2. KVS에서 사용자 B의 잔액 조회

3. A에서 B로 송금

4. 잔액을 KVS에 저장

Go


체인코드 구현 예제(단순 송금시스템 : 조회)

1. KVS에서 A의 잔액조회

2. 값을 노드에 반환

변수 선언과 전처리

Go


분산 합의








(프라이버시)

Shared

ledger

(공유원장)


Smart

Contract

(스마트 계약)

Consensus

(합의)


합의(Consensus)란…

• 거래 및 거래 실행 순서에 대한 동의

• 동일한 원장을 유지하기 위하여 검증 참여자들의 상태를 동기화

• 거래원장이 일치하지 않는 참여자 노드의 상태 수정

• 악의적인 참여자 노드들은 격리

AB

C

AB

C

AB

CJKL

AB

CD

AB

CD

AB

CD

CONSENSUS

before after

peer/node

AB

CD

LedgerState

합의는 블록체인 네트워크에있는 모든 참여자의 원장(블록 및 상태)이 일관성이 있는지 확인하는 메커니즘


합의(Consensus) 관리자

합의(Consensus)라는 시스템 기반의 합의 형성 구조는 블록체인을 적절히 사용하여 운용하는 데 매우중요한 개념임

1) 블록체인은 참가자 합의에 의해 업데이트 됨2) 합의 알고리즘은 여러가지 존재 : 작업증명(PoW), 지분증명(PoS), PBFT

3) 분산 환경에서의 멀티 파티 컨센서스 (합의) 형성 알고리즘4) 작업증명 (Proof-of Work) 알고리즘의 문제 (1) : 최종성(Finality)의 부족5) 작업증명 (Proof-of Work) 알고리즘의 문제 (2) : 51 % 공격 문제6) 플러그인 구조


합의 알고리즘 종류

관리주체 관리자가 없음 여러조직 단일조직

네트워크 형태 퍼블릭(Public) 형 컨소시움(Consortium) 형 프라이빗(Private) 형

참여자

자율적 허가적(Permissioned)

불특정 사용자가 참여할 수 있기 때문에, 악의를 가진 사용자가 참여할 수 있음

참여자의 신원이 확인되고, 신뢰할 수 있음

분산합의 알고리즘(Consensus)

작업증명(Proof of work) 및지분증명(Proof of shake) 알고리즘

(마이닝)

특정 노드(검증자)에 의한 검증(분산합의 알고리즘)

✓ 전력소비가 많음✓ 최종성이 없음✓ 51% 공격 문제

✓ 전력소비를 최소화✓ 최종성이 있음✓ 경량화 되어 있으며, 빠르게 처리됨

트랜잭션 처리시간상대적으로 오래걸림

(비트코인:10분, 이더리움:10초)빠르게 트랜잭션 처리 (수초에서 실시간)

유즈 케이스 디지털 화폐 은행 송금, 증권 거래 등 비즈니스 네트워크에서 사용

구현 예 비트코인(Bitcoin), 이더리움(Ethereum) 리플(Ripple), 하이퍼레저(Hyperledger)

업무사용의 중요성 : 비즈니스 유스케이스에 따라 분산합의 알고리즘을 목적에 맞게 사용할 수 있음


하이퍼레저 패브릭 합의 알고리즘

PBFT(Single)✓하나의 거래당 합의과정을 통해서 블록이 생성됨

PBFT(Batch)✓여러 트랜잭션을 정리하고 합의 과정을 거쳐 블록이 생성됨

Sieve (PBFT 알고리즘 개선)✓체인코드 실행결과에 대한 합의정보를 얻은후에✓각 노드의 체인코드 실행결과가 다른경우, 동기화 처리되지 않는 문제를 해결

* PBFT : Practical Byzantine Fault Tolerant


PBFT 처리흐름 구조

트랜잭션을 생성함

트랜잭션을 비검증노드로 전송함

트랜잭션 내용을 검증리더에게 전송함

검증 리더노드만 요청을 포착하여 트랜잭션에 순서를부여하고 모든 노드에 전송함.다른 노드는 요청사항을 무시함.

『트랜잭션이 리더노드에 의해 위변조 된지 않았음』을확인함(전자서명 확인)

정의된 노드로부터 동일한 트랜잭션을 받았는지 확인하고『트랜잭션이 올바르게 배포되었음』을 확인함

정의된 노드로부터 『확약(Confirm) 메시지』를 확인하고체인코드에서 트랜잭션 수행함

트랜잭션을 원장에 기록함

정의된 노드로부터 『응답(Reply) 메시지』를 받은후거래완료 확인함

클라이언트

어플리케이션

비검증노드

검증 노드리더

×××

PBFT처리 체인코드실행 원장기록

트랜잭션 합의 처리

체인코드실행결과

요청 m

사전준비 m

준비 hash(m)

확약 hash(m)

통신대기통신m : 트랜잭션 메시지hash(m) : 메시지 해쉬값

트랜잭션

처리흐름


Sieve 처리흐름 구조

트랜잭션을 생성함

트랜잭션을 비검증노드로 전송함

트랜잭션 내용을 검증리더에게 전송함

검증 리더노드만 요청을 포착하여 트랜잭션에 순서를 부여하고모든 노드에 전송함.다른 노드는 요청사항을 무시함.

전체 검증노드가 체인코드에서 트랜잭션을 실행하고 결과를리더로 전송함

정의된 노드로부터 실행결과를 받은후, 실행결과에 대한검증요청을 전송함

『검증 요청이 리더노드에 의해 조작되지 않음』을 승인함

정의된 노드로부터 똑같은 검증요청 결과를 받았는지 확인하고, 『검증 실행』을 승인함

트랜잭션을 원장에 기록함

정의된 노드로부터 『응답(Reply) 메시지』를 받은후 거래완료확인함

클라이언트

어플리케이션

비검증노드

검증 노드리더

×××

PBFT처리 체인코드실행 원장기록

실행결과(미리보기)

에 따른합의를PBFT사용

체인코드실행결과

요청 m

사전실행 m

준비 hash(r)

확약 hash(r)

통신대기통신

m : 트랜잭션 메시지r : 실행결과hash(r) : 실행결과 해쉬값

트랜잭션

처리흐름

미리보기 r

사전준비 r


PoW(Proof of Work)의 문제점(1) > 최종성 부족

b(n) b(n+1)

시점에 따라 여러 채굴(마이닝)이 거의 동시에 성공하여 블록이 분기하는 경우가 있음

b(n+2)

b(n+2')

채굴

채굴

b(n) b(n+1)

길게 만들어진 블록이 정당하다고 인정됨

b(n+2)

b(n+2')

b(n+3) b(n+4)

소수가 블록을 추가하는 속도로는 이길수 없음

다수가 채굴을 통하여 블록 생성

기각된 블록의 트랜잭션은 무효가 될 가능성이 있으며, 합의 알고리즘은 이러한 문제가없어야 함


PoW(Proof of Work)의 문제점(2) > 51% 공격문제

✓ 하나의 마이닝 풀(또는 개인의부)이 51%이상의 컴퓨팅파워를 가진경우 블록체인변조가 가능함

✓ 2014년 6월경 Ghash.io의 채굴속도(hash rate)가 51%에접근했다고 화제가 되었음▪ Bitcoin 가격이 폭락함


플러그인 구조

하이퍼레저 패브릭(Hyperledger Fabric)은 다양한 업무에 적용될수 있도록 PBFT 합의알고리즘에 한정하지 않고, 임의의 합의 알고리즘을 실현할 수있는 플러그인 구조를채용하고 있음. 하이퍼레저를 이용하는 기술자는 업무 이용에 따른 합의 알고리즘을실현하는 추가 플러그인을 개발하고 하이퍼레저에 통합 할 수 있음.

Hyperledger Fabric

합의(Consensus) 관리자시스템 설정에 따라 설정된 합의 알고리즘이 실행

합의∙플러그인인터페이스

합의형성의 조건, 통신 프로토콜, 원장 저장형태트랜잭션의 수행방법에 대한 사양을 설명

PBFT알고리즘

Sieve 알고리즘(PBFT 개선)

추가 플러그인(PoW, 기존방식)

인터페이스를 구현하는형태로 개발

소스코드다운로드

합의∙플러그인


보안 및 프라이버시







보호되어야 함

Security &

Privacy(보안&프라이버시)

Shared

ledger

(공유원장)


Smart

Contract

(스마트 계약)

Consensus

(합의)


기업용 블록체인을 위한 보안 요구사항

신원 관리(Identity)

• 업무 사용을 위해서는 참가자의 신원 확인이필요

✓ 책임 스푸핑(Spoofing) 방지• 참가자의 신원인증 (참가자의 정체성과 특성의

확인)

개인정보 보호

• 트랜잭션의 발행자의 익명화• 동일한 사용자가 발행한 여러 트랜잭션들은

연관성이 없도록 함

트랜잭션의 기밀성(Confidentiality)

• 트랜잭션이 암호화되어 일반 사용자에게 보이지않도록 함

액세스 제어

• 스마트계약을 실행할 수있는 사람을 제한(초기화, 함수 실행, 데이터 참조 등)

IBM의 연구보고에 따르면, 기업용 블록체인은 허가형 블록체인 (Permissioned Blockchain)이 유일한 방법이라는 결론

재생(Replay) 공격 대책

• 과거의 트랜잭션을 복사하여 재전송하는 공격을방지함

PKI 인증서와 전자서명

• 사용자의 신원을 확인함• 개별 트랜잭션은 익명의 인증서를 통해 신원을

숨긴 채 인증 할 수 있음


인증서

인증서(certificate)는 사용자 non-validating peer, validating peer 등 모든 엔터티에발행됨

Ecert(Enrollment Certificate)✓사용자의 신원을 확인하기 위해서 장기적으로 사용되는 인증서✓사용자, 검증노드 및 비검증 노드에 발행됨

Tcert(Transaction Certificate)✓트랜잭션마다 발행되는 단기적으로 사용되는 인증서✓사용자, 검증노드 및 비검증 노드에게 발행됨✓트랜잭션마다 다른 Tcert를 사용하면 여러 트랜잭션이 동일한 사용자에 속하는 것을 숨길수 있음

TLS 인증서(Certificate) : 통신 채널을에 암호화하는 데 사용되는 인증서


공개키(Public key) 암호화 방식

공개키(Public Key)와 개인키(Private Key) 쌍✓공개키는 비밀이 아니며 모두에게 공유되어도 문제가 없음✓개인키는 키 소유자만 보유함

개인키

홍길동

인증서

홍길동의 공개키

인터넷개인키로 암호화 -> 공개키로 복호화✓개인키의 소유자가 보낸 메시지임을 확인 할수 있음 (예:서명)

공개키로 암호화 -> 개인키로만 복호화 가능✓개인키의 소유자만이 읽을 수있는 개인메시지를 보낼 수 있음

평문 평문복호문

홍길동 김철수

평문 평문복호문

김철수 홍길동


하이퍼레저의 PKI 계층구조


인증서 사용 모델

Enrollment ID

서명키(공개키)

ECert

ECert 인증기관(Enrollment CA)

사용자

① 등록② ECert 발급

분산원장

참가자(검증노드)


⑤ Tcert를 사용하여 트랜잭션에 서명⑥ TCert를 이용하여 암호화키 교환

❖ 익명의 사용자를 인증하는 경우

암호화된 Enrollment ID

암호화키

서명키(공개키)

TCert

TCert 인증기관(Transaction CA)

③ ECert를 이용하여 TCert 발급요청

④ TCert 발행

◈ 매번 다른 Tcert을 사용하면 각각의트랜잭션은 다른 사용자로부터 발행된것으로 보임


하이퍼레저 패브릭 V1.0 아키텍처

분산원장 기술(DTL) 서비스

APIs, Events, SDKs

스마트 계약(Smart Contract)

비즈니스 로직

서비스AP

멤버쉽 서비스

등록

(Enrollment)

트랜잭션

(Transaction)

합의(Consensus) 서비스

분산 원장오더링 서비스

(ordering)

네트워크

프로토콜

Endorsement

Validation

보안

컨테이너

보안

레지스트리

거래(Transaction)

원장(Ledger)

신원확인(Identity)

보안 및 암호화 서비스


하이퍼레저 패브릭 V0.6과 V1.0 비교

keys

합의(Consensus)분산원장(Ledger)이벤트 처리(Events)체인코드(Chaincode)

state

peer

SDK

멤버쉽 서비스

ECA, TCA, TLS-CA

보증

커미터

체인코드

이벤트처리

분산원장

peer

SDK

Keys

어플리케이션

No SPoF

No SPoT

1: 트랜잭션 제안서 제출 2: 체인코드실행

3: 보증결과 리턴

트랜잭션 제출

6:배치 전송

7: 트랜잭션 검증 및 확약5: 합의알고리즘에따라 배치로트랜잭션오더링

o-service

멤버쉽

4:

패브릭 V0.6 패브릭 V1.0


트랜잭션 실행 예제 > ①거래 제안

E0

Client

Application E1

E2

S

D

K

Endorser Ledger

Committer Application

Orderer

Smart Contract

(Chain code)

Endorsement

Policy

Key:

Fabric

Ordering-Service

O

O O

OAp

클라이언트의 거래 제안

보증 정책:

• “E0, E1 및 E2 는 반드시 전자서명”• (P3, P4 노드는 정책의 대상이 아님 )

클라이언트 어플리케이션은체인코드A

실행을 위한 거래 제안을 하게되며,

반드시 {E0, E1, E2} 노드들이 대상이 됨

P4P3A

B

AB

AB

AD


트랜잭션 실행 예제 > ②거래제안 실행

보증 노드의 거래제안 실행

E0, E1 및 E2 는 각각 제안된 거래를실행하지만 원장에 실행결과를업데이트하지 않음

각 실행을 통해서 “RW 세트”인읽기(read), 쓰기(write) 데이터를캡처하여 패브릭내에서 전송됨.

E0

Client

Application E1

E2

S

D

K

Fabric

Ordering-Service

O

O O

OAp

Endorser Ledger


Orderer

Smart Contract

(Chain code)

Endorsement

Policy

Key:

P4P3A

B

AB

AB

AD


트랜잭션 실행 예제 > ③거래제안 응답

클라이언트는 응답 수신

각 보증 노드로부터 서명된 RW 세트를서명후에 클라이언트에게 결과값을송신함

E0

Client

Application E1

E2

S

D

K

Fabric

Ordering-Service

O

O O

OAp

Endorser Ledger


Orderer

Smart Contract

(Chain code)

Endorsement

Policy

Key:

P4P3A

B

AB

AB

AD


트랜잭션 실행 예제 > ④ 거래 오더링

클라이언트는 오더링 서비스에 보증노드로부터 받은 결과 제출

클라이언트는 보증 피어로부터 받은응답을 오더링할 거래로 제출함

오더링은 다른 클라이언트어플리케이션에서 제출된 거래들이동시에 패브릭내에서 처리됨

Fabric

E0

E1

E2O

O O

OAp

Client

Application

S

D

K

Endorser Ledger


Orderer

Smart Contract

(Chain code)

Endorsement

Policy

Key:

(other applications)

Ordering-Service

P4P3A

B

AB

AB

AD


트랜잭션 실행 예제 > ⑤ 거래 전달

오더러는 모든 커미터 피어에 전달

오더링 서비스는 거래를 수집하여블록을 생성하여 커미터 피어들에전달함. 피어들은 가쉽(gossip)

프로토콜을 사용하여 다른 피어들에게전달함(P4가 해당)

다른종류의 오더링 알고리즘 제공:

• SOLO (single node, 개발용)

• Kafka (블록을 토픽으로 매핑)

• SBFT (PBFT와 유사)

Fabric

E0

E1

E2O

O O

OAp

Client

Application

S

D

K

Endorser Ledger


Orderer

Smart Contract

(Chain code)

Endorsement

Policy

Key:

Ordering-Service

P4P3A

B

AB

AB

AD


트랜잭션 실행 예제 > ⑥ 거래 검증

커미터 피어들은 거래를 검증모든 커미터 피어들은 보증 정책에 따라거래를 검증하며, 현재 상태에서 RW

세트가 유효한지 점검함

거래는 원장에 기록되고, 검증된 거래로캐슁 DB가 변경됨

Fabric

E0

E1

E2O

O O

OAp

Client

Application

S

D

K

Endorser Ledger


Orderer

Smart Contract

(Chain code)

Endorsement

Policy

Key:

Ordering-Service

P4P3A

B

AB

AB

AD


트랜잭션 실행 예제 > ⑦거래 결과통보

커미터 피어들은 클라이언트에게 결과 통보

거래가 성공 또는 실패되었을 때, 블록이원장에 추가되었을때, 클라이언트는통보를 받도록 등록될 수 있음

클라이언트와 연결된 각 피어들을 통해결과 통보를 받을수 있음

Fabric

E0A

B

E1A

B

E2A

B

O

O O

OAp

Client

Application

S

D

K

Endorser Ledger


Orderer

Smart Contract

(Chain code)

Endorsement

Policy

Key:

Ordering-Service

P3A

D

P4

!

!

!

!

! !


하이퍼레저 패브릭 V1.0

네트워크 도구

IBM은 모니터링, 로깅 및컴플라이언스를 위한 백업/복원도구를 제공

허가형 멤버쉽

알려진 참여자 및 규제감독을기반으로 신뢰된 블록체인 네트워크운영

멀티 채널

규제대상 산업에 필요한 개인정보보호 및 기밀 유지기능등을 통해서다자간 거래에 필요한 멀티 서비스제공

거래 내역

효율적인 감사 및 분쟁해결을 위한검색 가능한 거래내역 조회

분할 실행

체인코드 실행과 트랜잭션 오더링을분리함으로써 네트워크 성능을최적화 시킴

모듈러 아키텍처

비즈니스 네트워크를 동적으로 확장용이한 노드 수, 합의 알고리즘, ID

관리, 암호화에 대한 환경 설정

기밀성 운영 워크로드


패브릭 컴포저(Fabric Composer)

비즈니스 어플리케이션

패브릭 컴포저

블록체인 (Hyperledger Fabric)

– 블록체인 비즈니스 네트워크를 위한 하이-레벨 어플리케이션 추상화스위트(suite)

– 신속하게 솔루션 생성을 위한 비즈니스 중심의 용어 집중

– 리스크를 줄이고, 이해와 유연성을 높임

– 기능

– 비즈니스 네트워크를 모델링하고, 테스트 및 APIs를 공개

– 응용 어플리케이션은 비즈니스 네트워크와 통신하기 위해 APIs

트랜잭션을 호출

– Loopback/REST를 이용하여 기존시스템과 통합

– 오픈 소스로 http://fabric-composer.org 사이트에서 활용 가능

블록체인 비즈니스 네트워크 모델링 도구

http://fabric-composer.org/


is it relevant

for our business?

can IBM help


70Page

First Projects



하이퍼레저 패브릭 기반의 First 프로젝트(1/2)

Bike blockchain Reward points

management

Food Safety Contract

Management

FX Netting Settlements through

digital currency

Diamond Provenance Identity management

Credit Defaults Swaps Trade Finance Channel Financing Low liquidity securities

trading and settlement

Global Trade

Digitization

Trade Logistics Health Data Exchange 환율고시 및 외화송금


하이퍼레저 패브릭 기반의 First 프로젝트(2/2)

Corporation identity

management

Cotton trading

consortium

Property portfolio

revaluation

Logistics / Supply

chain

Private Equity Supply chain finance Bond Trading Asset custody system

Finance, real estate

and asset custody

Managing customer's

digital identities

Commodity trade finance for US crude oil transactions

Supply chain financial services

for pharmaceutical procurement

Digital trade finance

instrument

Know Your Customer Blockchain experiment Loyalty and Rewards

Platform


블록체인을 활용한 식품안전망

제조사사육사(농장)

물류 창고 판매점 소비자 감사

✓ 원자재, 기계류(NSF 인증) 및가공처리(HACCP 인증),

물류(검역소독 인증)에 관한주요정보의 안전한 문서화

✓ 규제기관 및 소비자를 위한 전자바코드나 QR 코드를 통한 정보라벨링이 부착된 제품패키지생성

✓ 제품을 패키지로 수집

✓ 제품패키지의 분해 및 판매점을위한 재포장 작업

✓ 부정한 대체물이나 위조품의유출을 막기 위한 패키지검증작업

✓ 운송라인 전반의 제품패키지의가시성 확보

✓ 모바일 앱을 통한 정보추적검색(사육사부터 소비자까지의유통과정을 추적)

✓ 계산대에서 만료된 제품(또는알람 발생)에 대한 거래 확인

✓ 제품 출처와 관련하여 고객의평가 및 선호도

✓ 공급망 전반의 각제품 유통과정에대한 엔드-투-엔드가시성

✓ 기계류, 만료 날짜,

제품 수량 등과관련된 규제준수점검

✓ 공급망 관리 인증및 감사 레코드생성

블록체인기반의

자산 추적(Provenance)

기능

블록체인데이터와

라벨링과의연관성

제품 데이터수집 및 분해

엔드-투-엔트허가형 가시성

불변성을기반으로한 진품

추적성

간단한방법으로의정보검색

감사 기능 : 스마트계약을 통한

규제변화에 대한 대응

요구사항


EHR을 위한 블록체인 네트워크

검증노드

병원 일반노드

응급의료

분산원장

KVS 분산원장

KVS

검증노드

개인클리닉

일반노드

약국

인증기관

의료보험공단

일반노드

환자

일반노드

가정의(GP)

분산원장

KVS

분산원장

KVS

분산원장

KVS

분산원장

KVS

분산원장

KVS

EHR 허가형블록체인 네트워크

스마트계약 스마트계약

스마트계약

Provenance

Control

Security

Streamline processing Accessibility

Accountability

Transparency

Privacy


블록체인 적용이 적합한 사례

✓ 분산 원장 및 처리에 의해 공동시스템 사용이 불필요 함으로, 비용 절감 효과가 기대됨✓ 일부 노드가 정지하고 있어도 처리가 계속 있기 때문에 안정한 시스템을 구축 할 수

있음✓ 각 노드 (각 참가자) 사이에서 동일한 비즈니스 로직, 데이터 공유, 위변조할 수 없는

상태에서 거래 기록이 유지되기 때문에 가능 감사 기능을 향상됨

✓ 분산 원장의 합의를 수행하면서 갱신되기 때문에 현재 고성능 (높은 응답)이 요구되는시스템

✓ 조직 및 회사를 포함하지 않고 한나의 조직만 참여하는 경우 (일반적으로 시스템에대응 가능)

✓ 간단한 DB / 트랜잭션 처리의 대체


미래의 블록체인 네트워크 형태

O

O O

Ordering Service

E

E

E

O

O O

Ordering Service

E

E

E

P

Financial Market

Network

Global Trade

Network

O

O O

Ordering

Service

EEE

P

Banking consortium

Network

Peer

Endorser

Orderer

✓ 피어들이 서로다른 블록체인네트워크의 오더링서비스에연결되어 있음


블록체인의 미래

서로 다른 비즈니스 목적을 가진 블록체인 네트워크가 생길 것으로 예상


Why Hyperledger Fabric

비영리 단체인 리눅스 재단에서 운영하고 있는 블록체인 오픈소스 프로젝트로 130여개의 회원사가 가입하여 운영되고 있음

1

기업들의 다양한 비즈니스 영역에 사용될 수 있는 허가형 (permissioned) 블록체인 플랫폼

2산업용 표준블록체인 기술

차별화된블록체인

아키첵처 설계

블록체인 기술의빠른변화 및업무연속성

확보를 위한지원 체계

표준화기술

뛰어난아키텍처

거버넌스

하이퍼레저 프로젝트 회원인 R3CEV*도 Corda를 하이퍼레저 프로젝트에오픈 소스로 2016년 11월 30일 기부

3

산업 표준에 따른 오픈소스 기반으로 사용자 정의 스마트 컨트랙 (Smart Contract), 강력한 암호화 지원 및 인증(Identity) 기능 제공

4

플러거블(pluggable) 분산형 합의(consensus)을 지원하는 모듈러(modular) 아키텍처로 설계되었으며, 20년이상 검증된 PBFT (Practical Byzantine Fault Tolerance) 알고리즘 제공등 V1.0에서는 합의 알고리즘의 재정의를 통해 1000 tps 이상의 성능이 지원받는 아키텍처 제공

5

하이퍼레저 프로젝트의 거버넌스를 기반으로 개방적이고 투명한 개발 프로세스를 통하여 향후 로드맵을 지원하고 가속화

6

IBM은 OBC(Open BlockChain)를 하이퍼레저 프로젝트에 기부하였으며, 하이퍼레저를 기반으로 100개 이상의 글로벌 기관들과 First 프로젝트 수행경험이 많음

7


© 2017 IBM Corporation

경청해 주셔서 감사합니다!

IBM KoreaThree IFC, 10 Gukjegeumyung-ro, Yeongdeungpo-gu, Seoul, Korea

Mobile: +82-10-4995-7163 Phone: +82-2-3781-7163

E-mail: [email protected]

박 세열블록체인 기술리더/금융총괄 아키텍트

Blockchain Technical Leader/Client Technical LeaderS&D Architect TeamTechnical Sales Banking & Financial Markets

블체인으 변화될 미래의습 - krnet.or.krb9%da%bc%bc%bf%ad_blo… · 트랜잭션n...

Documents