블록체인 세미나 4일차 : 패브릭의 구조

블록체인 세미나 4일차 : 패브릭의 구조

 

Public vs Private 

->암호화폐의 요소만으로는 두 가지를 나눌 순 없음. 프라이빗 BFT 계열의 합의 알고리즘이 아닌 것도 있음. 속도도 어떤 알고리즘을 사용하냐에 따라서 다름 

 

가상화폐 

-> 암호화폐로 바꾸기

 

->패브릭 인디, 얼사, 아발론, 캘리퍼, 익스프로어

 

-> Fab Token : 사이드 이팩트가 너무 많이 뜨고 오류도 많이 나서 close 해 버림. 즉 자체 토큰은 없다고 생각하면 됨.

 

-> 오더러는 체인코드를 보증하는 역할도 겸함

 

트랜잭션은 논리적 구성 요소 

-> 어떤 의미에서 논리적 구성 요소인지, 채널과 조직은 어떠한 규칙에서 논리적으로 말을 할 수 있고 트랜잭션은 데이터 덩어리니깐 물리적으로 보아야 할 거 같다. 

 

채널 MSP 

-> 채널이 논리적 구성 요소라고 했는데 로컬 MSP는 노드들에 있고 채널 MSP는 어디에 저장되어 있을까?

configtx 나 yaml 에 있는건가. 여기에 올라가는 건 아님. 

configtx, yaml 파일에서 채널을 정의하고 트랜잭션을 오더러에게 제안을 함. 리턴으로 블록이 날라감. Genesis 블록. 그 채널에 참가하는 사람은 이 제네시스 블록을 가지고 있고 이 곳에 MSP가 있어서 채널의 참여 권한을 확인할 수 있음. 

패브릭에서 잘 모르지만 시스템 채널이 있는데 이는 오더러들 끼리의 별도의 채널임. 이는 트랜잭션을 생성하지 않고 블록을 생성함. 이는 오더러에게 들어가 있음. 정리를 하자면 채널은 피어 안에 블록에 권한을 통해서 물리적으로 저장되어 있는 거임 

 

 

피어의 종류 

커미터, 앵터, 리터, 

-> Endorser 가 있어야 함. 모든 피어는 커미터가 맞지만 원장을 가지는 게 아니라 원장을 가질 수 있는 것고 쿼리는 가능하지만 보증,Endorsing 과정 을 실행할 수 없음. 앵커 피어는 커미터와 엔돌서와는 독립적으로 동작함. 앵커는 하나의 역할(role)임. 커미터 피어가 앵커 피어가 될 수 있음. 앵커와 피어와 리더 피어는 사실 똑같은 역할을 하고 있음. 또 트릭적인 건 모든 피어를 앵커 피어로 하면 TPS 가 빨라짐. 또 리더 피어가 정적 선언으로 부여하면 더 빨라짐. 네트워크 트래픽은 늘지만 TPS 자체는 빨라짐. 

 

채널 

특정 맴버들(피어,유저,조직)끼리만 블록체인 및 체인코드 공유 

-> 채널은 피어 단위, 유저 단위로 나눠지지 않고 조직 단위로 운영이 됨. 채널은 조직과 조직 간의 연계. 해당 조직 내에는 피어나 유저(Client, 어휘는 하나만) 가 포함 된 거를 조직

MSP에 의해 식별된다는 말이 와닿지 않음. 제네시스 블록 안에 있는 권한으로 식별 

채널 별로 별도의 원장을 가진다는 말이 중요. 

패브릭은 원장의 개념이 확대되어 있음. 기본 원장의 단점은 시간에 의해 시퀀스하게 설정되어 있음. 허나 데이터 정리를 할 수 없음. 비선형적으로 구성되어 있기 때문에. 바이너리 탐색이 안됨. log n 으로 해결할 수 없음. n x n 인데 이는 말이 안되는 시간. 즉 시간을 줄여야 하는데 indexing 밖에 방법이 없음. 키 값으로. 근데 모두 index 할 수 없는데 이를 최대한 맵핑 시켜서 이를 index 시켜 버림 .그래서 패브릭은 state db가 있음 key value db임. 그래서 최신 데이터는 따로 가지고 있음. 필요한 데이터를 빨리 챙기 위해. 

똑같은 원장을 가지고 있다면 state db 는 달라지나? 블록체인 뿐만 아니라 state db를 추가하여 원장이라고 설명할 수 있음. key index db나 history db도 있음 

 

가십프로토콜(Gossip Protocol)

-> 많이 쓰는거 RPC, 가십 프로토콜(분산 환경, 클라우드에서 네트워크를 어떻게 공유 할 것이냐), Raft (다 여기로 다 넘어가고 있음). 꼭 공부하기. 

 

-> 체인코드는 피어 내에서 수행되는 게 아니라 새로운 가상환경에서 동작. 체인코는 피어를 통해 ledger 데이터에 참여. ledger 에 데이터를 체인코드를 write 할 수 없음. 그냥 ledger에서 데이터를 확인하고 시뮬레이션함. 

(TK)

블록생성 프로세스 

-> 여러개의 피어가 동일한 원장을 가지기 때문에 간단한 네트워크 구성이 안됨. 오더러가 필요함. 

피어만 생각해보기

피어는 트랜잭션 프로퍼절 날라오면 엔돌싱함. 

피어는 블록이 날라오면 그 블록을 write 함. 

피어는 주변의 순서, sequence 를 고려할 필요가 없음. 

피어는 피어끼리 통신을 하지 않음(가십 프로토콜만 함) 

원장 공유만 백그라운드로 돌아감. 

피어 자체가 마이크로 서비스되어 있음

 

오더러만 생각해보기

오더러는 트랜잭션을 받고 정렬하고 블록을 패키지하고 원장에 던짐.

 

굉장히 단순함. 클라이언트는 겁나 바쁨.

이를 클라이언트가 감당하고 있음.

모든 동기화에 대한 건 클라이언트가 하고 있음

왜 그럴까?

블록체인 네트워크의 부하를 줄이기 위해. 

어플리케이션 레벨에서 다 수행. 

왜 네트워크 과정이 단순화 됐는지 알아야함. 

 

Read-Write Set

한 번 쓰기한 값에 대해서는 읽기를 하면 실패함.

->어떤 트랜잭션이 Write 하고 있는 곳에는 Read 는 가능한 Write 가 안 됨. 

하나의 트랜잭션이 거절 당하면 뒤에 있는 애들을 다 반려시켜야하는데 그럴 수 없음. 

  

트랜잭션 플로우 

-> 클라이언트와 sdk 를 동일하게 보고 Proposal는 GRPG 로 전송 

피어가 이를 받고 서명을 한 다음에 던짐(Endoring) 어떤 피어가 던졌는지 확인가능

어플리에키션은 이를 받고 확인을 함. 

Endorsement policy는 체인코드를 네트워크에 커밋할 때 같이 작성을 해서 전송을 해야함.

 

---

두번째 발표 

 

->SBFT 는 패브릭 1.6, 지금은 사라짐. 

->체인코드는 Go, Java / SDK 에서는 Go와 Node.js 를 추천

-> MSP 는 메소드를 가지거나 하나의 피어처럼 보는 게 아님. 파일 덩어리임. 이 MSP가 여러 MSP 로 나눠짐. 채널에 대한 MSP 는 제너시스 블록에 들어가고 피어 MSP는 피어에 들어감. CA에서 발급한 여러 키들을 피어 MSP 라고 함. 피어 MSP 설정이 잘못됐다고 하면 피어 안에 crypto-config를 확인해 보아야함. 

-> shim libarary 는 패브릭에서 개발한 거. 요새는 이걸로 체인코드 구현을 안 함. fabric chaincode go 등에서 제공해줌

->원장은 크게 블록체인과 stateDB로 구성된거. key index db 등 더 구성이 되어 있음.

->Endorsing : Endorsement Policy는 Client 가 검증하고 던짐. order가 다시 이를 peer 들에게 던질 때 다시 검증함.