일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- akka 강좌
- play 강좌
- 주키퍼
- CORDA
- Golang
- Adapter 패턴
- 하이퍼레저 패브릭
- 스위프트
- Actor
- 스칼라
- 파이썬
- 그라파나
- 스칼라 동시성
- 파이썬 머신러닝
- Play2
- 파이썬 동시성
- play2 강좌
- 스칼라 강좌
- Hyperledger fabric gossip protocol
- 안드로이드 웹뷰
- 하이브리드앱
- 파이썬 데이터분석
- 플레이프레임워크
- 엔터프라이즈 블록체인
- Akka
- hyperledger fabric
- 이더리움
- 블록체인
- Play2 로 웹 개발
- 파이썬 강좌
- Today
- Total
HAMA 블로그
[하이퍼레저 패브릭] Recovery 본문
이번 포스트에서는 하이퍼레저 패브릭에 관련된 기술중에 가장 알려지지 않은 주제인 Recovery에 대해서 다룬다. (그냥 링크로 무임승차지만;;;; 쏘오뤼~) 오랜시간 동안 네트워크가 작동하다보면 분산 노드들 간에 일관성에 관하여 문제가 생길 수 밖에 없기 때문에, (디스크 오류등 각종 예기치 못한 상황으로) 이를 회복시켜주는 기술이 패브릭에도 필요한데..
보통 일관성이 깨지는 곳은 스토리지에 무엇인가를 쓸 때이고 보통 하이퍼레저 패브릭에서는 committer 노드에서 일어난다. 좀 더 자세히 설명해 보면 orderer로 부터 받아온 블록을 가지고 해당 블록안에 있는 트랜잭션들을 VSCC, MVCC등의 다양한 방식으로 검증 한후에, 이상이 없으면, A) 블록체인을 업데이트하고 B) 상태DB도 업데이트 하고 C) 히스토리DB도 업데이트 한다. 이렇게 모두 잘 마무리 되면 모든 노드의 저장 상태는 동일하게 되는데 ( 물론 채널과 Private Data에 따라서 달라지는 부분 제외하고)
이때, VSCC, MVCC 중에 문제가 생겼을 경우에는 저장 과정에 돌입하지 않고 그냥 리턴해 버리기 때문에, 특별한 Recovery 과정이 필요 없지만, (그냥 가쉽을 통해 블록을 가져와서 다시 VSCC 부터 시작하면 되니까), A) 블록체인을 업데이트하고 B) 상태DB를 업데이트 하는 도중에 문제가 생겼을 경우에는 특별한 조치를 취해야 한다. 또한 과연 내가 가지고 있는 상태DB가 옳은것인지 체크하는 것과 최신 상태DB의 옳음을 합의 하는 방식 그리고 어떤 체크포인트까지 상태DB가 옳은 것으로 판명됬을 경우, 그 때 까지의 블록체인을 삭제하여 공간 활용성을 높히는 것에 대해서 알아야 할 필요가 있다.
아래 링크는 그런 내용에 관해 좀 더 친절히 설명하며, 고민도 공유하고 있으니, 관심 있는 분들은 참고 하길 바란다.
http://www.bchainledger.com/2018/05/failure-and-recovery-of-statedb-in.html
http://www.bchainledger.com/2019/12/fork-detection-and-rollback-in.html
페이스북 : 엔터프라이즈 블록체인 그룹
'블록체인' 카테고리의 다른 글
콘소시엄 블록체인에서의 거버넌스 (0) | 2020.11.13 |
---|---|
[하이퍼레저 패브릭] SDS 의 accelerator 분석 (0) | 2020.02.26 |
[하이퍼레저 패브릭] 관련 페이퍼 모음 (0) | 2020.02.09 |
[Hyperleder Fabric ] Leader election in RAFT, Gossip (0) | 2020.01.15 |
PBFT와 자손들 Tendermint, NCCU BFT, SEIVE, IBFT, MinBFT, RBFT, Mir-BFT, aBFT (0) | 2020.01.03 |