HAMA 블로그

사실 Leader election 은 가장 단순하게는 주변 노드들의 이름을 리스트로 가지고 있다가, 이름 순으로 그 다음 노드가 그냥 리더가 되는 느낌으로 구현하면 매우 단순하긴 한데, (Distributed Systems 책들에 소개되는 수준의 Bully algorithm, Ring algorithm 등은 실용적으로 사용하기에는 다소 심플하다.) Split brain 때문에 Term(epoch) 단위 동안에 가장 다수의 투표를 받은 노드가 선출되는등의 기술(?) 이 들어가며 복잡해지곤 하며...문제를 완벽히 해결하기가 쉽지는 않다. 아래 글에서는 하이퍼레저 패브릭상에서 발생되는 2가지 주요 분산합의 상황에서의 리더 선출에 관해 대략적으로 끄젹 꺼려 보겠다. * 이 문서는 앞으로 실제 패브릭 구현 상에서..

PBFT (Practical Byzantine Fault Tolerance) BFT는 분산된 노드들간에 동일한 상태를 유지하기 위한 방식으로, 악의적인 노드가 있는 것을 전제로 합니다. 여기서 악의적인 노드의 최대수는 N = 3f+1입니다. N : 전체노드 개수 f : 악의적인 노드 개수 따라서 4개의 노드에서는 1개는 악의적인 노드라도 생관없다는 의미입니다. 7개노드에서는 최대 2개.아래 이미지에서는 4개의 노드에서 최대1개의 비잔틴(악의적노드)가 있다고 치고 합의 단계에 대해 설명해보면 Request 단계 클라이언트는 상태변경을 위한 요청 (REQUEST, o, t, c)sc 을 대표 노드에 보냅니다. 참고로 이 대표노드(Primary) 또한 비잔틴이 될 수 있으며 그땐 새로운 대표노드를 선출 하게 ..

FastFabric: Scaling Hyperledger Fabric to 20,000 Transactions per Second 위 논문에 대한 저자와의 질문/답변을 공개합니다. Question to U.Waterloo Improvement 1: Orderer - Seperate transaction header from payload\ - You stated that we should reduce the amount of data sent from Orderer to Kafka by keeping the RWSet at the Orderer and send only the transaction's header to Kafka - This works well when there's only one Or..

엔터프라이즈향 블록체인 비교 * fabric과 Goquorum등 모든 컨소시엄 블렉체인의 사용예에서 어떻게 거버넌스를 이루어서 어떻게 사용했다라는 구체적인 기술 정보 및 비용감소에 대한 결과 정보가 부족해서 아쉽다. (사용 결과에 대한 효율 증가 분석표같은건 기대도 안함) * 컨소시엄 블록체인을 진짜 컨소시엄을 해서 제대로 합의하고 견제하면서 하려면 Fabric을 사용해야 하는게 좋으며 (기능셋이 많다.) 좀 간략히 사용하려면 quorum이나 Besu중 아무것이나 선택해도 된다. Corda는 최근 거의 사용되지 않는 듯하며, CDBC쪽에서나 소식이 들리는 듯 하다. * 성능의 경우 체감상 예상외로 Fabric이 빠른데.. (Fabric > GoQuorum > Besu) 전체 구조상으로는 동일 RAFT컨센..

Hyperledger Indy에 대해서 정리해봤습니다. Indy는 변화,발전되고 있으며, 인사이드에 대한 정밀한 조사,검증을 하진 않았기 때문에 참고용으로만 읽어 주십시요. 4년전 처음 이글을 적을 때에는 Indy-SDK가 모든 것(블록체인과 인터페이스, DID,VC를 다루는 공통 함수들, 지갑역할, P2P역할, 익명성 역할) 을 다 담고 있었으나 2023년 3월 현재 Indy-SDK는 다양한 모듈별로 나누어진 버전들이 있습니다. (Aries, Indy-vdr,AnonCreds 등) 개요 Hyperledger Fabric과 Ethereum의 경우 Smart Contract/ChainCode 를 통해서 DID/SSI를 (저장역할을) 실현 할 수 있는 범용 플랫폼인 반면에 Indy는 오직 DID를 구축하고자..

FastFabric: Scaling Hyperledger Fabric to 20,000 Transactions per Second 패브릭 기술에 관심있는 사람이라면 한번은 보지 않았을 까 하는 논문인데.. 과연 어떤식으로 커스터마이징을 하면 20,000 TPS를 달성 할 수 있을까? 이 논문에서는 Hyperledger Fabric 1.2 기반 (1.4에도 적용 가능)으로 아키텍쳐를 변경하여 성능을 3,000 TPS에서 20,000 TPS로 높였다고 하는데 과연 어떤 부분을 고쳐서 일까? 말이 되는 소릴 하는 걸까? 이것에 관해 각각의 토픽에 대해 배경지식/논문의 해결방식/개인적인소견(문제점)으로 정리하고자 한다. 1. Orderer - Seperate transaction header from paylo..

이 글은 버전을 구분하지 않고 있으며 , 스스로가 공부하면서 메모식으로 두서 없이 정리/수정 하는 내용인지라 글 읽기가 힘들 수 있으며, 암호학 전문가가 아니기에 일부 오류룰 담고 있을 수 있음을 참고 하십시요. 이더리움을 위시한 퍼블릭 블록체인에서는 굳이 네트워크에 붙는 노드들에 대한 신뢰가 필요 없기 때문에, 이 글에서 설명 할 하이퍼레저 패브릭이나 코다에서 신뢰,허가 작업을 하기 위한 복잡한 CA 관련 기술이 필요 없습니다. 대신 이더리움은 아무나 참여하는 네트워크에 대한 신뢰를 다른 방식으로 추가 하기 위한 더 어려운 일에 도전하고 있는 상황입니다. 이 글에서는 하이퍼레저 패브릭과 코다에서 네트워크에 참여하는 노드들의 신뢰,허가작업들이 어떤게 있는지 살펴보겠습니다. 실제 메뉴얼들은 이 글 보다 훨..

Hyperledger fabric 에서 reply attact 을 막기위한 nonce는 랜덤으로 생성되는데, 해당 nonce 를 가지고 TXID 도 만듭니다. 따라서 nonce 는 트랜잭션마다 가지고 있게 되며, Ledger에 그대로 저장되어 - nonce를 검증하기 위해서는 해당 트랜잭션에 대해 Ledger에 이미 동일한 TxID를 가진 트랜잭션이 있는지에 대한 중복 검사를 통해 검증됩니다. 반면 이더리움이나 쿼롬등은 nonce는 Address마다 하나씩 가지고 있으며, 하나씩 증가합니다. 따라서 Address에 있는 nonce 값과 비교해서 검증을 하게 되죠. 결국 패브릭은 엄청난 공간의 낭비, 검증의 낭비를 초래하게 되는데요.( block index 를 통해 완화하긴 합니다. 근데 용량증가시와 MV..