1. 블록체인 등장 및 탈중앙거버넌스
1-1. 블록체인과 행정학
1-1-1. 알고리즘에 숨은 철학
1-1-2. 합의 알고리즘 철학
현대 민주주의의 행정학과 유사
-> 공공이해 극대
1-1-3. 의사 결정 비교(합의 알고리즘과 행정학)
1-1-4. 합의 알고리즘 반대
= 경영학
1-1-5. 공무원 vs 직장인
MPA(Master of Public Administration): 공공관리
MBA(Master of Business Administration): 기업관리
1-1-6. 행정학 vs 경영학
행정학 = 민주적인 공공경영학?
1-1-7. 블록체인 vs 클라우드
1-2. 블록체인과 온라인 투표
1-2-1. 합의 알고리즘과 온라인 투표 동작
온라인 투표 합의 방식 = 합의 알고리즘 동작 방식?
1-2-2. 블록체인 기반 온라인 투표의 성공 BM
블록체인이 스마트 컨트랙트의 무결성 보증
-> 온라인 투표의 무결성 보증 활용할 수 있는가?
정책참여 편리 + 투표 무결성 -> 직접 민주주의 실현?
1-2-3. 합의 알고리즘과 온라인 투표 비교
1-2-4. 온라인 투표 사례
블록체인 기반 온라인 투표 도입
-> 기업: 중앙 -> 탈중앙?
-> 포데모스 정당의 혁신, 플럭스 정당, 호주 연방 선거 과정, 따복, 자유한국당 선포식
1-3. 블록체인 비즈니스 가치
1-3-1. 합의 알고리즘으로 인한 블록체인 비즈니스 가치
합의 알고리즘: 블록체인 노드로 감독 -> 정보조작 어려움
신뢰성 -> 블록체인
1-3-2. 블록체인 비즈니스 방법론
2. 합의 알고리즘
2-1. 필요성
2-1-1. 블록체인 전반적인 이해
2-1-2. 비유
2-2. 합의 알고리즘 개론
2-2-1. 등장배경
가장 빠르게 생성된 블록을 인정
-> 해당 블록 내 거래 신뢰성 인정
-> 이중 지불 방지 + 안정적인 블록 운영?
탈중앙 + 데이터처리 어케하나
-> 합의 알고리즘 개발!
2-2-2. 합의 알고리즘 정의
합의 방식으로 시스템 운영을 공정하게 해결
2-2-3. 합의 알고리즘 비유
2-2-4. 합의 알고리즘 중요성
블록체인 = 분산형 원장 + 합의 알고리즘
합의 알고리즘으로 트릴레마 해결?
트릴레마 = 블록체인 최적성을 위한 3가지 조건 + 최대 2가지 조건만 만족
Scalability(확장성): 사용자 증대에 유연히 대응
Decentralized(탈중앙성): 중앙에서 벗어나 자체적으로 운영
Security(보안성): 블록체인 내 데이터 신뢰성 및 무결성
2-3. 합의 알고리즘 구분 방법
2-3-1. FLP 불가능성 이론
FLP 3요인
Safety(완전성): 노드 간 공유가치는 일치 및 유효, termination 보장
Liveness(생동성): 블록을 끊임없이 원활하게 생성, termination 비보장
Fault Tolerance(동기성): 노드에 장애가 있어도 정상적으로 시스템 작동 -> 비잔티움 장군 문제 해결
Safety <-(trade-off)-> Liveness
2-3-2. Liveness 취약점
이클립스 공격(넷스플리트): 특정 노드가 중앙 시스템으로부터 단절
-> 악의로 신규 블록생성 내용 전달을 지연
-> 포크(양갈래 길처럼 블록이 생성) 유발
포크(fork) 발생?
-> six conformation rule(포크 발생 시, 블록길이가 6인 걸 인정) Ex) 비트코인
-> GHOST(Greedy Heaviest Object Sub-Tree) Protocol?
블록을 트리형태로 생성하여 조상 및 자손 블록의 가중치를 계산하여 길이 설정
Liveness 우선?
-> 포크를 악용하여 이중 지불공격 유발
Selfish Mining Strategy
블록체인 보상과정을 속임
채굴블록을 비공개하고 특정시점에 블록을 공개
Double Spending
거래를 이중으로 발생시켜 노드에 피해를 줌
2-3-3. 합의 알고리즘 유형 구분
3. 암호학
3-1. 비트코인과 블록체인
3-1-1. 비트코인 대두
비트코인이 블록체인을 탄생시킴
비트코인 떡상 -> 블록체인 떡상
3-1-2. 비트코인 추구가치
비트코인 = 탈중앙 화폐
암호화폐(Cryptocurrency)?
3-2. 비대칭 암호화와 알고리즘 이해
3-2-1. 개요
A -(암호화 or 서명)-> B
공개키 암호: 누구나 암호문 생성, B만 복호 -> 특정인 전달
전자서명: A만 서명, 누구나 확인 -> 본인 인증
3-2-2. 응용사례
공개키 암호
대칭 암호화 알고리즘
비대칭 암호화 알고리즘
RCA: 최종 인증서 발급 기관
ICA: 중간 인증서 발급 기관
전자서명
RA: 등록대행기관
CA: 인증기관
3-2-3. 해시함수
특정 길이를 갖는 데이터에 대해 고정길이 데이터로 매핑하는 암호화 함수
-> 고정된 값에는 항상 동일한 해시값을 만듦
해시(Hash): 해시 함수에서 산출된 고유값
해시충돌: 같은 해시값이 중복으로 발생해서 생가는 문제
생일 패러독스: 고정된 길이 이전에도 해시충돌 발생가능
3-3. 블록체인과 비대칭 알고리즘
3-3-1. 비트코인 거래
Private Key: Bitcoin 소유주 입증 + Bitcoin address로 암호화된 거래내역 풀 때 활용
Public Key, Bitcoin address: 거래내역 암호화, 계좌번호화
암호화 2번 -> 개인키에 매우 높은 안전성
비트코인거래
1. 거래블록 해시화
2. 전송자 개인키를 이용해 암호화
3. 전송자 공개키를 이용해 복호화
Segwit
전자서명을 분리하여 블록의 거래크기 증가
거래 가변성 문제 및 부인 방지 효과
3-3-2. 해시 알고리즘
비트코인 블록
Prev_Hash: 이전 블록헤더의 해시
Timestamp: 블록의 생성시간, 채굴자에 의해 지정
Tx_Root: 블록에 포함된 모든 트랙젝션의 해시
Nonce:
Tx_Root를 모으고 Nonce를 해결하면 블록을 체인으로 연결
Nonce를 변경하여 새로운 블록을 생성
난이도 설정
제시되는 난이도 값을 낮추면 마이닝 난이도도 낮아짐
3-3-3. 논의사항
비대칭암호알고리즘 보안취약점
1. 개인키 해킹: 공개키를 역순으로 해킹?
2. 해시충돌: 기존블록 깨지 않고 해시총돌을 만들 가능성?
3. 탈중앙 무효: 중앙독점으로 회귀?
해시충돌
블록체인은 이전 블록이 서로 연결 -> 거래정보 조작 = 블록 조작 -> 연쇄적으로 이후 블록의 해시값 변화 -> 해시충돌할 논스를 찾아야 함
양자컴퓨팅: 양자역학적인 현상을 이용해 컴퓨팅 병렬처리 능력 극대화
큐비트: 양자 컴퓨팅에서 사용되는 비트단위
그로버 알고리즘: 무작위 대위법을 지능화
쇼어 알고리즘: 소인수분해의 알고리즘 공격에 특화
4. 스마트 컨트랙트 및 기타기술
4-1. 스마트 컨트랙트
4-1-1. 스마트 컨트랙트
자연어의 모호성 -> 프로그래밍 언어로 해결?
4-1-2. 스마트 컨트랙트와 블록체인
스마트컨트랙트(확장성) + 블록체인(보안성)
-> 프로그래머블 머니 등장
4-1-3. 스마트 컨트랙트 개념
- 이더리움 지급
- 물건 배송
- 출금권한 승인
4-2. 영지식 증명 알고리즘
4-2-1. 개념 설명
증명에 필요한 정보를 직접 제공하지 않고 진위여부 입증
4-2-2. 적용 사례 - 비밀번호
4-2-3. 블록체인 적용 내용
상호작용형 -> 상호적으로 교환하여 증명
비상호작용형 -> 일방적으로 전달하여 증명
commitment: 트랜젝션을 암호화
nullifier: spending key를 hash로 암호화
4-3. 블록체인 확장성
4-3-1. 트릴레마 관점에서의 블록체인 한계
비트코인의 ‘확장성(Scalability, 낮은 TPS)’에 한계가 제기 됨 ➔ 이를 해소하기 위한 연구 진행
4-3-2. Segwit
Segwit은 디지털 전자 서명 부분을 별도로 분리해 블록에 담을 수 있는 거래 크기를 증가시킨 방식
거래 가변성 문제 해결(부인 방지 효과)
전자 서명 데이터가 전체 데이터의 75%(?) ➔ 최대 4MB로 키우는 효과를 가져옴
4-3-3.
Off-Chain solution (State Channel Blockchain)
Lightening Network
비트코인 기반의 또 다른 레이어를 만들어 소위 그룹간에 비트코인 결제를 가능케 하는 네트워크
소액 결제를 빠르게 처리하는 오프체인 솔루션(2015년에 처음으로 제안됨)
멀티 시그널: 거래 안정성을 위해 거래 참여자가 양방향으로 동의해야 함
4-3-4. Raiden Network
별도의 체인을 만들어 모두의 합의를 거치지 않아도 되는 거래 기술 (이더리움 전용)
⚫ 잔액증명
- 거래 당사자간의 거래가 잔액을 초과하지 않게 제한하는 기술 - 잔액 최종 금액으로 이더리움으로 이더로 전환 가능
⚫ A-D 거래의 경우, 채널간 직접 연결 없이 간접적으로 거래가 가능함
(1) 채널을 형성하고 해당 채널에 사용할 코인을 스마트 컨트랙트에 예치함
(2) 잔액증명(받아야 할 돈)을 제공하면서 거래 내역을 기록함
(3) 한 노드가 Exit을 선언할 때, 두 노드 잔액 증명을 제출해 야 함. 만일 상대 노드가 잔액 증명을 하지 않을 시에 받을 금액이 없다고 간주함
(1) A-D 거래를 원할 시에 별도의 채널을 만들지 않아도 됨. B, C, D 등의 순서로 채널을 열어서 거 래할 수 있게 하기 때문임. 이 때, B, C, D 등은 특 정 거래수수료를요구할수있음
(2) A-D까지 잔액증명을 그대로 전달하면, 중간에 탈취 당할 위험이 있음. 그래서 이를 열어볼 수 없게 암호화 해서 보냄. 이를 Hashed-lock이라고 부름. D가 해당 내 용을 받았다고 알리면, A는 D에게 복호화 키 값을 보 냄. 그리고 D가 거래 종료를 원하지 않을 시에 D, C, B 등 순으로 키 값을 전달해 잔액 증명을 만듦.
여기서 문제. D는 왜 C에게 복호화 키를 넘길까요??
D는 C로부터 암호화된 잔액증명을 받았기 때문에, D 는 C로부터 잔액증명을 받아야 함. 유사하게 C도 B에 게 암호화된 잔액증명을 받아야 함. 정리하면, D는 C 로부터 받아야 할 돈이 있음. 이는 복호화키를 넘기는 동기로 작용케 함
⚫ 거래 내역을 복잡하게 만들어서, (1) 익명성을 강화함
- Channel balances are hidden from the public until participants settle and withdraw their funds and the net channel balance is revealed. When they do however, channel balances may have already been obfuscated by other intermediary transfers that passed through this and other channels connected to the same nodes, making it extremely difficult to trace back on-chain transactions to off-chain Raiden transfers.
⚫ (2) 블록생성 시간이 없음(빠른 처리 속도), (3) Fee가 요구되지 않음(다채널은 예외) - Channel balances are hidden from the public until participants settle and withdraw their funds and the net channel balance is revealed. When they do however, channel balances may have already been obfuscated by other intermediary transfers that passed through this and other channels connected to the same nodes, making it extremely difficult to trace back on-chain transactions to off-chain Raiden transfers.
⚫ (4) 유연한 확장성(채널간 거래이기 때문에 노드수에 따른 처리량 비례 증가) - Next to fees, blockchains also have another inherent problem that Raiden helps to solve: scalability. Capacity of most of the current blockchains is capped at a fixed or semi-fixed limit, regardless of the size of the userbase. In stark contrast, capacity of the Raiden Network scales linearly with the number of users, leading to an efficient and future-proof, decentralized transfer network
4-3-5. Plasma
오프체인 방식 (헤더의 묶음별로 다차원적으로 형성하는 블록체인)
⚫ 루트체인: 이더리움의 메인 체인
⚫ 차일드 체인은 페런트 체인에게 거래 헤더를 주기적으로 제공함.
➔라이트닝, 라이덴 등 보다 더 높은 무결성 제공
가장 최신 블록으로 루트체인으로 회가 할 수 있도록 함
4-3-6. 샤딩
샤딩으로 블록체인의 확장성 문제를 해결할 수 있음
⚫ 샤딩은 데이터베이스에 사용된 개념으로, 대용량 처리를 위해 데이터를 분할하는 개념 ⚫ 샤딩은 온체인 솔루션인 반면, 스테이트 채널은 오프체인 솔루션
⚫ 샤딩은 블록체인에서 트랜잭션을 영역별로 나눠서 병렬 처리 기술을 말함
⚫ 샤드는 샤딩에 의해서 분할된 네트워크 영역을 말함
Collation : Collation은 샤드 체인에서 메인 체인의 블록과 같은 역할을 한다.Collation은 크게 collation header 와 트랜잭션 목록으로 구성된다. Collation header는 해당 collation을 구성하는 정보를 담고있으며, proposer의 sign을 거쳐 메인 체인에 제출된다. 트랜잭션 목록은 collation에 담긴 트랜잭션들의 목록이다
Proposer : 본래 proposer는 제안자라는 뜻으로 트랜잭션들을 모아 proposal을 만들고 collator에게 제출한다. Proposal은 검증되지 않은 collation이다.
Collator : Proposer가 제출한 proposal을 검증한다. 특정 period 마다 한 샤드에는 여러 collator들이 배정되는데 이들은 해당 period에 진입하기 일정 기간 이전에 무작위로 선정 된다.
Executor : Collation header를 메인체인의 SMC (Sharding Manager Contract) 에 전달한다. 이 결과 샤드 체인의 실제 state가 변경된다. (Executor는 샤딩 phase 3에 등장한다)
Period : 메인 체인에서 샤드 체인의 collation header를 제출 받는 주기를 말한다. 단위는 메인 체인에서의 블록의 개수다. 예를 들어, PERIOD_LENGTH = 5 라면 5개의 블록이 생성되는 것이 1 period이다.
Lookahead period : Collator는 샤드체인에서 collation을 검증하기 이전에 SMC에 의해 의해 pseudo-random하 게 배정된다. 이때, “lookahead period”는 collator가 몇 period에 앞서서 어떤 샤드 체인에 배정되는지를 나타낸다. 예를 들어, LOOKAHEAD_PERIODS = 4이면 4 period 이전에 collator는 샤드 체인에 배정된다. Collator는 사전에 자신이 배정된 샤드 체인의 state 정보를 다운받는 시간을 확보할 수 있다.
• Collator가 되려면 일정량의 예치금을 내야 하는데, 이 예치금은 Collator가 악 의적인 행동을 하는 것을 방지하게 합니다.(악의적은 행동을 하면 예치금이 사 라지기 때문입니다.) 여기서 이 예치금을 받고 관리하는 곳이 바로 SMC입니다.
• 앞에서 Collator를 무작위로 샤드에 배치한다고 하였는데, 이것을 하는 곳이 SMC입니다. 무작위로 배치하는 이유는 Collator의 악의적인 행동을 방지하기 위해서입니다.
• Executor가 제출한 Collation 헤더를 검증하는 역할을 합니다. SMC가 검증하고 인정해야만 Collation이 유효해집니다.
• 샤드 간 트랜잭션을 전송하기 위해서는 receipt라는 것이 필요한데, 이것을 관 리하는 것도 SMC입니다.
• 추후에 설명하겠지만, 블록을 생성하기 위해서는 Collator들의 투표가 필요한데, 이 투표를 SMC위에서 진행하게 됩니다.
• Proposer와 Collator가 SMC를 통해 자산을 예치하고 샤드 네트워크에 참여합니다.
• Collator가 SMC를 통해 각 샤드에 무작위적으로 배치됩니다. 배치되고 실제 Collator의
역할을 수행하기까지 일정 시간이 준비기간으로 주어지는데(lookahead period), 이 때
각 Collator들은 배치된 샤드의 예전 기록을 다운받게 됩니다.
• Collator의 역할이 수행되고, 이들은 Proposer들이 보내는 Proposal을 받게 됩니다.
• Collator들은 Proposal 내에 있는 트랜잭션들이 유효한 지를 검증하는 투표를 진행합
니다. 이 투표에서 트랜잭션이 유효하다는 것에 대한 찬성표가 2/3이상이 나올 경우
이 proposal은 유효한 것으로 간주됩니다.
• Collator들이 맡은 기간이 종료되면, 이 때 새롭게 생성된 collation header를 SMC로
보냅니다.
• 이 collation header를 SMC에서 검증하고, 유효한 데이터라는 검증이 완료되면 메인체
인에 이것이 기록됩니다.
• 샤드1에 있는 거래 기록 내역의 receipt를 만듭니다.
• 이 트랜잭션이 Collation에 포함되고 Collator가 이를 SMC로 보내 검증합니다.
• 검증이 완료되고, 이것이 메인체인에 포함되면 SMC가 다른 샤드와 비교해 중복
Collation 처리에 관해 검증합니다.
• Collation에 관한 순서가 정해면 정해진 방식대로 기록됩니다.
