2022-08-09 공부

오전 이론

Byzantine Empire

• 비잔틴 장군 문제 : 장군이 악의적인 행동을 할 수 있따는 점을 가정

PBFT

• 단순 고장난 노드 뿐만 아니라 악의적인 노드가 있음에도 불고하고 전체 시스템이 안정적으로 동작하도록 하는
  프로토콜
• BFT 계열 프로토콜 중 실용적으로 쓰일 수 있는 가장 대표적인 프로토콜
• 여러곳에서 똑같은 알고리즘이 분산되어서 작동
• 1/3이상이 악의적인 노드이면 잘 작동 하지 않음
• 리플리카 중 의사결정의 리더 역할 을 하는 primary 노드가 있으며, primary 노드 주도하에 순차적으로 명령이 실행됨
• primary 노드가 고장 나거나 악의적인 행동을 하게 될 경우 'view change'라는 절차를 통해 primary 노드를 바꿈
• 확인 하려면 데이터를 다 뿌려보는 시스템 
• 트래픽이 많이 생기고, 확정성이 떨어짐, 노드가 많은 경우에는 사용하기 힘듬
• n = 3f + 1 - 악의적인 노드를 걸러내기 위한 노드의 개수, f = 악의적인 노드

출처:https://www.researchgate.net/figure/PBFT-normal-operation_fig1_330295202

Raft 합의 알고리즘

 

 

합의 알고리즘 비교

출처:https://www.semanticscholar.org/paper/A-review-on-consensus-algorithm-of-blockchain-Mingxiao-Xiaofeng/0bf2cb4ae68275f4fd71a30f191dc95793a0d49e/figure/3

 

Excute-order-commit

• 3단계로 이루어진 동기화 과정
• 기본적으로 peer는 commit도 될 수 있지만 Endorser도 될 수 있다

Execute-order-commit 순차 과정

1. Transaction Proposal
2. Execute Chaincode
3. Proposal Response
4. Submit Transaction
5. Order Transaction
6. Validate Transaction
7. Ledger Commit

 

RBFT Overview

 

RBFT Protocol Steps

대표 퍼블릭 블록체인 서비스

• 암호회폐(코인 vs 토큰) - ERC20, 암호화폐표준
• 클라우드 펀딩 - the DAO
• 민주주의 - 투표

스마트 컨트랙트

• 서면으로 이루어지던 계약을 코드로 구현하고 특정조건이 충족되었을때 해당 계약이 이행되도록 하는 개념
• 블록체인에서 동작하는 응용프로그램의 단위로 스마트 컨트랙트의 개발 흐름은 웹 응용프로그램 개발과 유사함

 

트랜잭션 라이프사이클

1. Interact
2. Wallet Check
3. Get Permission(서명)
4. Send Tx
5. Run Smart Contract
6. Respond

 

 

 

 

 

그외 정보

Race condition - 동기화 과정중에 동시에 업데이트를 해서 하나가 누락되면 문제가 발생

Endorser는 체인넷 개발자가 정함
dAPP - Decentralized APP

dAPP의 핵심은 서버에 있다 블록체인을 기반으로만 서버시스템
dAPP은 투명하고 신뢰할 수 있는 데이터만 저장

클라우드 - 개인을 위해, dAPP-모두를 위해

질문한것 - dAPP 이 발전하면 플렛폼의 중개 수수료를 소비자나 개발자가 받을 수 있게 된다

퍼블릭 체인에서 서명은 필수

블록체인은 플렛폼

EOS.IO - 스마트컨트랙트 + 현실성, DPoS 방식

클래이튼의 암호화페  - 클레이(사실상 이더리움이랑 같이 동작이 가능)

직렬화 - 객체화

JSON - 현재 사용이유 : 하드웨어 성능 높아짐, 생산성 높아짐, 간단함