일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 31 |
- 스칼라 동시성
- 엔터프라이즈 블록체인
- play 강좌
- 스칼라
- 파이썬 강좌
- Actor
- 파이썬
- 그라파나
- 하이브리드앱
- 스칼라 강좌
- Akka
- akka 강좌
- 주키퍼
- Play2
- 파이썬 머신러닝
- Adapter 패턴
- 이더리움
- play2 강좌
- 스위프트
- 안드로이드 웹뷰
- 하이퍼레저 패브릭
- 블록체인
- Hyperledger fabric gossip protocol
- Play2 로 웹 개발
- 파이썬 데이터분석
- hyperledger fabric
- CORDA
- 플레이프레임워크
- Golang
- 파이썬 동시성
- Today
- Total
HAMA 블로그
[하이퍼레저 패브릭] nonce 본문
Hyperledger fabric 에서 reply attact 을 막기위한 nonce는 랜덤으로 생성되는데, 해당 nonce 를 가지고 TXID 도 만듭니다. 따라서 nonce 는 트랜잭션마다 가지고 있게 되며, Ledger에 그대로 저장되어 - nonce를 검증하기 위해서는 해당 트랜잭션에 대해 Ledger에 이미 동일한 TxID를 가진 트랜잭션이 있는지에 대한 중복 검사를 통해 검증됩니다.
반면 이더리움이나 쿼롬등은 nonce는 Address마다 하나씩 가지고 있으며, 하나씩 증가합니다. 따라서 Address에 있는 nonce 값과 비교해서 검증을 하게 되죠.
결국 패브릭은 엄청난 공간의 낭비, 검증의 낭비를 초래하게 되는데요.( block index 를 통해 완화하긴 합니다. 근데 용량증가시와 MVCC 작업 까지 생각하면...) 왜 이렇게 해야 할 까요?
이것은 패브릭엔 Ledger에 Address 라는 상태 개념이 없으며, StateDB에는 체인코드와 연관된 key만 존재하기 때문입니다. 이더리움에서는 보낸 사람이 누구인지를 블록체인상에 존재하는 Address로 특정하지만, 패브릭에서는 그냥 CA 로부터 인증받은 user면 되며, 그 user는 체인코드를 호출하는데 있어서 인증서 검사 및 ACL에만 사용되지, 그 user의 정보가 Unique 한 key로 Ledger상에 존재하진 않기 때문입니다.
따라서 이런 낭비를 없애기 위해서는 해당 작업을 위한 별도의 서비스가 있으면 되겠지만, 그 서비스 자체에 대한 신뢰성이 블록체인(Ledger) 그 자체만 하지 않기 때문에 문제가 발생할 여지가 있습니다. 고민할 여지가 많은데 결국 근원을 바꾸는 수가 젤 좋겠죠.
추가)
txid(nonce)에 대한 중복검사 자체를 굳이 해야 할 필요가 있을까요? multi version check로 퉁치면 안될까?
'블록체인' 카테고리의 다른 글
[하이퍼레저 패브릭] FastFabric - 20,000tps (0) | 2019.08.30 |
---|---|
[하이퍼레저 패브릭] CA,MSP,Identity Mixer 정리 (1) | 2019.08.28 |
[하이퍼레저 패브릭] Fabtoken의 UTXO 와 계정 (0) | 2019.07.11 |
블록체인 R/D 부분 면접 오픈북 (2) | 2019.04.25 |
슈노 시그니쳐 (Schnorr Signatures) (0) | 2019.04.19 |