etc/BlockChain

블록체인의 구조와 이론_ 이론편 (합의 알고리즘, 전자서명과 해시)

코딩무민 2020. 10. 14. 21:47
반응형

3. 합의 알고리즘 

(1) 합의 알고리즘

  • 정의 : P2P 네트워크와 같이 정보 도달에 시간차가 있는 네트워크에서 참가자가 하나ㅡ이 결과에 대한 합의를 얻기 위한 알고리즘  
    ex) 비트코인 : PoW / 이더리움 : PoS / Hyperledger Fabric : PBFT

(2) PoW(Power of Work) 의 문제점

  • 51% 문제 : 특정 마이너가 전체 네트워크의 과반수 이상을 점유하는 경우 결과 조작이 가능
  • 파이널리티 불확실성 : 블록체인 분기 시 긴 체인을 올바른 것으로 판단하는데, 짧은 체인 사용 노드에서 긴 체인이 채택된다면 다양한 문제 발생 가능
  • 성능한계: 네트워크에 확산되는 시간을 업생는 것이 불가능. 합의에 걸리는 시간도 필요
  • 블록체인의 용량 : 블록체인 참가자 전원이 트랜잭션 실행 결과를 검토해 신뢰성을 확보 > 모든 블록 정보를 각각의 노드가 보유

(3) 분산 시스템의 장애 모델

1- FAIL-STOP 모델 : 어떤 오류로 인해 중지된 서버는 깨끗이 퇴출하는 모델

2- FAIL RECOVER 모델 : 한 번 정지한 서버가 부활하는 모델 

  • 1, 2고려 : Paxos, Raft

3- BYZANTINE FAULT 모델 : 임의 노드가 악의적으로 실수를 일으키는 모델

  • 3고려 : PoW, PoS, PBFT, Seive

(4) 합의 알고리즘의 종류 및 특징

1) Proof of Work (PoW)

  • 비트코인, 이더리움 등
  • 장점 : 참가자 수의 영향을 받지 않고 참가자를 늘릴수 있따
  • 단점 : 네트워크 상태에 따라 일부분에 불일치가 생긴 경우 파이널리티가 불확실하게 된다.
  • 처리 절차
    1. Wallet이 트랜잭션 발행 후 참가자 전원에게 브로드캐스트
    2. 받은 승인자가 해시를 계산함 (여기서는 Node0)
    3. wallet이 다른 트랜잭션을 발행하고 이를 참가자 전원에게 브로드캐스트
    4. 받은 승인자가 해시를 계산 (여기서는 Node 1, 2가 동시에 발견 > 블록체인 분기)
    5. wallet이 다른 트랜잭션을 발행하고 참가자 전원에게 브로드 캐스트
    6. 받은 승인자가 해시를 계산함 ( 여기서는 Node 3 : Node2 블록 뒤에 추가)

블록체인 기본 구조 

2) Proof of Stake

  • 기본구조는 PoW와 동일하나 계산의 난이도가 낮아져 자원 소비가 작아지는 장점.

3) PBFT

  • Hyperledger Fabric
  • PoW, PoS의 단점인 파이널리티의 불화길성과 성능 문제를 해결
  • 네트워크의 모든 참가자를 미리 알고 있다.
  • 처리 절차
    1. 클라이언트가 모든 노드에 요청을 브로드캐스트
    2. Replica0이 primary(리더)가 되고 순차적으로 명령을 다른 노드에 전달
    3. 각 노드는 2)의 명령을 받으면 primary를 포함한 모든 노드에 회신
    4. 각 노드는 3)에서 전달된 명령을 일정 수 이상(2f) 수신하면, primary를 포함한 모든 노드에 수신한 신호를 전송
    5. 각 노드는 4)에서 보낸 명령을 일정수 이상(2f) 수신하면 명령을 실행하고 블록을 등록해 클라이언트에 reply 반환

PBFT 구조

 

4) Sieve

  • Hyperledger Fabric
  • PBFT 확장 알고리즘
  • 처리 과정
    1. 각 노드 중 하나가 client 가 되고 리더의 명령 송신
    2. 리더가 각 노드에 실행의뢰 전송
    3. 각 노드는 의뢰를 실행 후 결과를 리더에게 전달. 결과가 일정 수에 도달하지 못하면 중단되고 요청은 무시됨
    4. 수신한 결과가 중지가 아니라면 그 증거로 결과를 집계(PBFT 사용 하는 경우가 많음)

Sieve 구조 

5) Paxos

  • Google Chubby
  • 데이터베이스 복제 시 동일한 서버를 하나 더 만들어 복제하는 것이 일반적
  • 특징 : 과반수의 동의를 얻으면 동의 내용이 나중에 변경되지 않음

6) Raft

  • RAM cloud
  • Paxos에 비해 상세하고 간결함.
  • 리더 선출 구조 때문에 과반수에 달하지 못하는 커뮤니티는 로그가 쌓이기만 할 뿐 완료되지는 않음.

전자서명과 해시

전자서명

  • 전자서명: 전자 데이터의 타당성을 증명
  • 전자 서명의 생성 및 검증의 흐름
    1. 보내는 사람은 비밀키와 공개키로 구성된 키쌍을 생성한다. (비밀키 : 서명 생성, 공개키 : 서명 검증)
    2. 보내는 사람은 1)에서 만든 공개키를 미리 받는 사람에게 전달
    3. 보내는 사람은 1)에서 만든 비밀키를 이용해 전자 데이터 암호화 (암호화한 암호문 :전자서명)
    4. 보내는 사람은 3)에서 생성한 전자 서명을 전자 데이터에 붙여 전달
    5. 받는 사람은 2)에서 받은 공개 키를 이용해 4)에서 받은 전자 서명을 복호화 (복호화 하면 원본 전자 데이터 생성)
    6.. 받는 사람은 4)에서 받은 전자데이터와 5)에서 복호화한 결과를 비교해 내용이 같은지 확인. 비교 결과가 같으면 데이터의 위조, 변조가 없는 것.

전자서명 예시 

해시

  • 해시는 전자서명과 비슷하나 생성된 해시를 다시 원 데이터로 변환할 수 없음.

해시 생성과 비교

  • 블록체인의 한 블록에서 위조나 변조가 일어나면 그 블록의 해시값 뿐만 아니라 다른 블록들의 해시값들도 변하기 때문에 위조, 변조가 불가능함.
반응형