![블록헤더
❑ 블록 헤더
▪ 비트코인 블록 헤더 (총 80bytes)
▪ 헤더 구성
• version(int32_t) : 소프트웨어/프로토콜 버전
• previousblockhash(char[32]) : 앞에 블록의 암호학적 해쉬
• merklehash(char[32]) : Merkle 트리의 루트 해쉬
• Time(uint32_t) : 블록 생성시간(채굴 시작 기준)
• nBits(uint32_t) : 난이도 조절용 수치
• Nonce(uint32_t) : 계산회수 또는 난이도 조건 만족을 위한 수치](https://image.slidesharecdn.com/random-180130033132/85/-12-320.jpg)
블록체인 개요
- 1. 블록체인 및 암호화폐 기술 최종석 2018-01-11 부산대학교
- 2. 1. 블록체인 전망 2. 블록체인과 암호화폐 3. 블록체인구조 4 5 6 1. 블록 구성 2. 블록 헤더 3. Smart contract 10 12 19 1. 합의알고리즘 개요 2. 블록 충돌 22 29 1. 블록체인 구현 39 I. 블록체인 개요 II. 블록체인 구조 및 원리 III. 합의알고리즘 IV. Naive chain 구현 블록체인 및 암호화폐 기술 1. 결론 45 V. 결론 전체 목차 전체 목차
- 3. I. 블록체인 개요 1.블록체인 전망 2.블록체인과 암호화폐 3.블록체인 구조 3
- 4. 블록체인 전망 ❑ Gartner 2017 hype cycle & 2018 Technology Trends ▪ Hype cycle에서 블록체인은 5~10년 사이에 안정기로 들어갈 것으로 기대하고 있음 ▪ 2018 Top 10 Trends에서도 Mesh 부분에서 가장 높은 기대를 받고 있음 4
- 5. 블록체인과 암호화폐 ❑ 블록체인과 암호화폐의 차이점 ▪ 블록체인 • 분산 데이터베이스의 한 형태로, 지속적으로 성장하는 데이터 기록 리스트로서 분산 노드의 운영자 에 의한 임의 조작이 불가능하도록 고안 ▪ 암호화폐 • 암호를 사용하여 새로운 코인을 생성하거나 거래를 안전하게 진행할 수 있도록 매개하는 화폐로 디 지털 화폐 또는 가상화폐의 일종 ❑ 암호화폐 구성요소 ▪ 블록체인 ▪ 거래 ▪ 스마트 계약서 5 블록체인 스마트 계약서 거래 암호 화폐 + + =
- 6. 블록체인 ❑ 블록체인 ▪ 거래 장부를 공공화 함으로써 분산된 원장을 관리하는 기술 ▪ 개방적이고, 투명하며 검증 가능한 시스템으로, 신뢰 경계를 넘어서(Trustless) 자산의 소 유권을 디지털 방식으로 추적할 수 있는 시스템. 6
- 7. 블록체인 구조 ❑ 블록체인 ▪ 분산 데이터베이스의 한 형태로, 지속적으로 성장하는 데이터 기록 리스트. ▪ 분산 노드의 운영자에 의한 임의 조작이 불가능하도록 고안. ▪ 새로운 작업 증명을 다시 실행하지 않고는 변경할 수 없는 레코드를 만듬. 7
- 8. 블록체인 구조 ❑ 이더리움 플랫폼 구조 8 Dapp : contract+whisper+swarm 응용 계층 Smart Contract :decentralized logic Whisper :decentralized storage Swarm :decentralized messaging 동의 계층 실행 계층 데이터 계층 합의 엔진 채굴 가스 이더 EVM Smart Contract 블록 블록체인 머클트리 계정 트랜잭션 메세지 공통 계층 P2P 네트워크 DBMS 전자 서명 인코딩 암호 해쉬
- 9. II. 블록체인 구조 및 원리 1.블록 구성 2.블록 헤더 3.Smart contract 9
- 10. 블록 구성 ❑ 블록 구성 ▪ 블록헤더 • Prev Hash : 이전 블록의 암호학적 Hash 값 • Nonce : 채굴(Mining)을 위한 의사난수 • Root Hash : Merkle 트리 또는 Merkle Patricia Trie의 Root Hash 값 ▪ 트랜잭션 • 데이터베이스에서의 작업 단위, 성공과 실패가 분명함 • 비트코인의 트랜잭션? 거래 • 이더리움의 트랜잭션? Contract • 트랜잭션은 지갑이 관리한다. 10 Tx0 Tx1 transactions Tx2 Tx3 Header =
- 11. 블록 구성 ❑ 트랜잭션 생성과정 ▪ 모든 트랜잭션은 Validation 과정을 거쳐서 통과하면 Candidate Block에 추 가됨 11 peer (wallet) Validation? transaction create No Disposal Candidate Block #1 Node A block hash block header transaction information etc. information Add a transaction to block # Yes Propagate to other nodes Yes D CB #2 Node B D CB #3 Node C D CB #4 Node D Other Nodes
- 12. 블록헤더 ❑ 블록 헤더 ▪ 비트코인 블록 헤더 (총 80bytes) ▪ 헤더 구성 • version(int32_t) : 소프트웨어/프로토콜 버전 • previousblockhash(char[32]) : 앞에 블록의 암호학적 해쉬 • merklehash(char[32]) : Merkle 트리의 루트 해쉬 • Time(uint32_t) : 블록 생성시간(채굴 시작 기준) • nBits(uint32_t) : 난이도 조절용 수치 • Nonce(uint32_t) : 계산회수 또는 난이도 조건 만족을 위한 수치
- 13. 블록헤더 ❑ Version (Bitcoin 예) ▪ Version 1 • Genesis block 추가 ▪ Version 2 • Block height parameter 파라미터 추가 • 227,930 번째 블록부터 Version1 블록 차단 ▪ Version 3 • 새로운 블록의 ECDSA 서명에 대한 DER 인코딩 강제 ▪ Version 4 • OP_CHECKLOCKTIMEVERIFY 추가 13 V1 : Genesis block V2 : BIP34 V3 : BIP66 V4 : BIP65
- 14. 블록헤더 ❑ Previous block hash ▪ SHA 256을 암호학적 Hash 함수로 사용 • 이전 블록을 바꾸기 위해서는 현재 블록의 Previous Block Hash를 바꾸 어야 함. • 각 블록은 서로 체인으로 엮여 있기 때문에 하나의 블록을 수정하기 위해서 는 모든 블록을 수정해야 함. 14
- 15. 블록헤더 ❑ Root hash ▪ Merkle hash 트리를 이용하여 각 트랜잭션들의 Root hash를 저장 ▪ 트랜잭션이 달라진 경우에는 Root hash가 변경되기 때문에, 무결성을 보장할 수 있음 15
- 16. 블록헤더 ❑ 타임스탬프 ▪ Unix 기반 타임스탬프 사용 ▪ 비트코인 정책 • 이전 11블록의 중간값보다 커야함 • 두시간 이상 차이는 블록은 허용하지 않음 16
- 17. 블록헤더 ❑ nBits ▪ 난이도 조절을 위한 파라미터 • 블록생성 시간에 영향을 줄 수 있음. • 총 4바이트를 사용하며, 상위 1바이트는 지수로 사용하고, 하위 3바이트는 Threshold의 지표로 사용함. 17
- 18. 블록헤더 ❑ Nonce ▪ Block hash가 난이도를 통과하지 못할 경우에 Re-hash을 위해서 조절되는 요 소 ▪ 의사난수 또는 0에서 시작하여 통과할때까지 증가시키는 방법을 사용 18 0x9e0f8bacee… 블록 헤더 Nonce 0 Nonce 1 Nonce 78,415 0xec83d7f73… 0x0000007a6… 블록 해쉬값 연산 1 연산 2 연산 78,415 Nonce++; Nonce++; Nonce++;
- 19. Smart contract ❑ Smart contract 정의 ▪ 1996년에 Nick Szabo에 제안된 개념 ▪ 디지털 형식으로 일련의 약속들을 기록하고, 그것들을 수행하기 위한 프로토콜을 포함 • AI와는 전혀 관계가 없음 19 http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart_contracts_2.html
- 20. Smart contract ❑ Smart contract ▪ Block에 등록된 Contract 주소를 이용하여 해당 Contract의 API를 호출하여 코드를 실행하고, 이벤트를 보내는 방식 • 해당 API에 의해서 트랜잭션이 발생하게됨 20
- 22. 합의 알고리즘 개요 ❑ 블록체인 ▪ 분산 데이터베이스의 한 형태로, 지속적으로 성장하는 데이터 기록 리스트. 22
- 23. 합의알고리즘 개요 ❑ 분산 시스템의 이슈 ▪ Peer 들간의 데이터 동기화 문제 • 블록체인에서 블록체인을 모든 Peer가 동기화 되는데 시간이 걸릴 수 있으 며, 이에 따라서 Miner가 조금씩 다른 블록체인의 Branch를 가질 수 있음 ▪ 여러개의 블록체인 Branch가 있을 때, 어떤 Branch를 선택해야 하는가?? • Consensus Problem ▪ 악의적인 노드가 네트워크에 참여하고 있다면?? • Byzantine General Problem 23
- 24. 합의알고리즘 개요 ❑ PoW (Proof of Work) ▪ 많은 Hash power를 가진 사람이 블록을 증명하는 방법 • 서비스 환경에서는 DoS와 같은 수많은 공격이 가해지는데, 이 때문에 가장 높은 성능을 가진 사람이 채굴을 하게 함으로써 가용성을 높이려고하는 전략 ❑ PoS (Proof of Stake) ▪ 보유한 코인의 양을 이용하여 투표를 하여 블록을 증명하는 방법 • Hash power 독점으로 인한 보안상 문제를 해결하기 위해서 제안 ❑ PoI (Proof of Importance) ▪ 코인을 많이 가진사람과 거래량, 거래대상을 고려하여 채굴자를 채택하는 방법 • PoI는 모든 사람에게 비슷한 기회를 주려고 하는 시스템 • NEM에서 사용되고 있음 24
- 25. 합의알고리즘 - PoW ❑ PoW ▪ 계산량에 따른 작업 증명 ▪ (블록 해쉬값 < 난이도 값)? block_attach () : Nonce++; 25 0x9e0f8bacee… 블록 헤더 Nonce 0 Nonce 1 Nonce 78,415 0xec83d7f73… 0x0000007a6… 블록 해쉬값 0x000000800… < ? 연산 1 연산 2 연산 78,415 Blockchain Network block_attach() & broadcast Nonce++; Nonce++; Nonce++;
- 26. 합의알고리즘 - PoS ❑ PoS ▪ 지분에 따른 작업 증명 ▪ (자신의 지분 / 전체 지분) 확률 계산 -> block_attach() 투표 권한 획득 ▪ 난이도, nonce, 채굴 필요 없음 ▪ 블록 interval이 명확히 정해짐 ▪ Validator(투표자) 선정을 위한 프로토콜이 필요함 ▪ 세계적으로 전력 에너지 소모 절감 26
- 27. 합의알고리즘 - PoS ❑ PoS 예제 ▪ 1. Virtual Miner는 “Validator” Smart Contract로 이더리움 코인을 전송함 ▪ 2. Block Interval 동안 Smart Contract로 전송된 이더리움 코인은 잠김 ▪ 3. Smart Contract는 이더리움 코인의 지분(Stake)에 따른 확률로 Validator 를 선정함. ▪ 4. Validator는 새로운 블록을 정규 체인에 추가할지 여부를 투표 가능 • 4-1) 잘못된 블록에 투표한다면, 불이익 • 4-2) 투표를 안해도 불이익 27 “Validator” Smart Contract Virtual Miner#1 3.0 eth Virtual Miner#2 1.5 eth 4.5 eth ① ② 2/3 1/3 ③ ① ③
- 28. 합의알고리즘 요약 28 Validation?Peer Candidate Block #1 Block hash Block header Transacton information etc. information Transaction create No Yes Disposal Add a transaction to block # CB #1 D Peer Candidate Block #1 Block hash Block header Transacton information etc. information Transaction create No Yes Disposal Add a transaction to block # CB #1 D CB #1 D Node 1 Node 2 Node 3 H(BH) < 난이도 Block header No : Nonce++ Yes : Attach CB #1 D Others “Validator” Smart Contract Voting Validator 1 Validator 2 Validator … ==Epoch block &Votes > 2/3 Yes : Finalize No : Disposal Validation? PoW PoS
- 29. 블록 충돌 ❑ 블록 충돌 ▪ 해쉬값을 찾은 블록이 동시에 네트워크에 등록된다면? ▪ Priority에 따라 하나의 체인이 선택됨. ▪ 대부분의 블록체인은 longest blockchain 29 N-1 N N+1 N+1 N+2 N+3 N+4 ? ? ? Block #P Block #A Block #B Block #C Block #D Block #E
- 30. 블록 충돌 30 ▪ 블록 충돌 – 1) 충돌이 일어나기 전, 정상적으로 블록 P가 네트워크에 연결됨. N-1 N
- 31. N+1 N+1 블록 충돌 31 ▪ 블록 충돌 – 2) 블록 A와 블록 B가 동시에 해쉬값을 찾음. N-1 N P A B
- 32. 블록 충돌 32 ▪ 블록 충돌 – 3) 블록 A와 블록 B가 동일한 길이로 충돌 N-1 N N+1 N+1 P A B
- 33. 블록 충돌 33 ▪ 블록 충돌 – 4) 블록 X가 생김 N+2N-1 N N+1 N+1 P A B
- 34. 블록 충돌 34 ▪ 블록 충돌 – 5) 블록 X가 블록 B에 체인을 붙이고, 전파됨. – 6) 블록 A 체인을 발견 -> 더 짧은 블록 A쪽 체인은 폐기(고아 블록)됨. N+2 N+2 N-1 N N+1 N+1 A B P AC BC
- 35. 블록 충돌 35 ▪ 블록 충돌 N+3 N+3 N+4 N-1 N N+1 N+2 N+3 N+4 N+3 N+4 N+2 N+2 N-1 N N+1 N+1 A B P AC BC ACD BCD P BCDE D E N+3 N+3N+2 N+2 N-1 N N+1 N+1 A B P AC BC ACD BCD
- 36. 블록 충돌 36 ▪ 블록 충돌 – Finality Problem – 블록 A가 담고 있던 트랜잭션은 폐기 – 1번 검증된 트랜잭션은 이동이 불가능하다! – 비트코인은 6번, 이더리움은 12번의 트랜잭션 검증이 이루어지면, 완전히 블록체인에 기록 – 완전히 블록체인에 기록이 되어야 이동이 가능. – Finality Problem의 가능성은 남아 있음. – 거래소, 비트코인 ATM기....? – Zero confirm, Side-channel(off-chain), Multi-signature 등의 방법이 있음. N+4 BCDE N+3 N+3N+2 N+2 N-1 N N+1 N+1 A B P AC BC ACD BCD
- 37. 블록 충돌 37 ▪ 블록 충돌(비트코인) – 역대 최장 블록 충돌의 길이는 5
- 38. IV. Naive chain 구현 1. 블록체인 구현 38
- 39. Naive chain 구현 39 ▪ Naive chain (1/5) – 자바스크립트 기반의 약 200줄 정도의 블록 체인. – 가장 심플한 블록체인 코드 구현을 위해 만듬. – HTTP 인터페이스 – 웹 소켓을 기반의 노드 간 통신 – 매우 단순한 프로토콜 – 트랜잭션, Version, 난이도, Nonce, 합의 알고리즘 없음. – https://github.com/lhartikk/naivechain
- 40. Naive chain 구현 40 ▪ Naive chain (2/5) – 블록 및 SHA256 해쉬값 계산
- 41. Naive chain 구현 41 ▪ Naive chain (3/5) – 블록 생성 및 저장
- 42. Naive chain 구현 42 ▪ Naive chain (4/5) – 블록 유효성 검사
- 43. Naive chain 구현 43 ▪ Naive chain (5/5) – 체인 선택(가장 긴 체인)
- 44. V. 결론 44
- 45. 결론 ❑ 블록체인 유형 ▪ Public/Private/Consortium 블록체인으로 나눔 ▪ Ethereum/Hyperledger/R3 Corda 가 있음 ❑ 블록체인 ▪ 중앙 집중형 DBMS -> 분산된 공유 원장 ▪ 만능이 아니다. 처리 성능과 용량은 기존의 DBMS보다 더욱 떨어진다. • 샤딩, off-chain channel, lighting, sub-chain … 여러 기술과 연구가 진행중. ❑ 블록체인 도입시 주의 사항 ▪ 1) 데이터가 시간 순으로 정렬되고, 감사(audit)가 필요한가? ▪ 2) 중앙에서 데이터에 대한 관리가 필요한가? ▪ 3) 트랜잭션 속도가 중요한가? ▪ 4) 운영 수단(코인, 토큰)이 필요한가? ▪ 5) 안정적인 기술지원을 받을 수 있는가? ▪ 6) 기술 타당성이 충분한가? 45
- 46. 감사합니다감사합니다 Q & AQ & A