HAMA 블로그

예) 블록체인에서 블록을 받아서 처리하기 - 명령적 0. 서버에 클라이언트들을 등록하고 초기화 한다. 서버는 현재 running 상태이다. 1. 입,출력 채널을 초기화하고 시작시킨다. 현재 connected 상태이다. 2. Recv 이벤트를 event 쓰레드풀의 쓰레드 하나를 얻어서 등록한다. 3. Recv 이벤트를 기다린다. 4. Recv 이벤트가 오면 읽을 수 있을 만큼 읽어서 버퍼에 저장해 두고, 채널은 다시 이벤트를 기다린다. 5. Recv 한 데이터가 너무 많으면 버퍼는 자동으로 증가 하고 적으면, 이미 읽은 버퍼의 앞쪽으로 이동해서 채워진다. 6. 채워진 버퍼는 유저 Handler에 세션정보와 함께 보내진다. 7. 유저는 어떤 세션에서 데이터가 왔는지 확인하고 버퍼에서 데이터를 4바이트 읽어서..

1. 시작하면서 언어에 대한 벤치마크에 있어서 보편적, 절대적이란것은 없으며, 팀의 숙련도, 제품의 특징등에 따라서 성능/개발속도는 천차만별 일 것이다. 이 포스트는 그 동안 블록체인 연구만 하느라 잊어버린 코더라는 나의 정체성을 일 깨우고, 각 언어에 대해서 일단 빠른 시간내에 손가는 대로 만들면 어떻게 되는지 재미로 만든 것이며, 옵티마이징에 대한 부분은 전혀 신경 쓰지 않았기 때문에 객관적 지표로 삼을 수는 없을 것이다. 특히 CPU점유율 같은건 신경도 안썼다. 락을 안걸고 CPU 펌핑시키면 성능은 엄청 올라 간다. (참고로 코드 품질은 안드로메다) 이 벤치마크는 주로 생산자-소비자 패턴에 대한 테스트이며, 쓰레드끼리 데이터를 주고 받는 과정을 시뮬레이션 하였다. 현재 Future등을 통한 비동기 ..

보호되어 있는 글입니다.

이번 포스트에서는 하이퍼레저 패브릭에 관련된 기술중에 가장 알려지지 않은 주제인 Recovery에 대해서 다룬다. (그냥 링크로 무임승차지만;;;; 쏘오뤼~) 오랜시간 동안 네트워크가 작동하다보면 분산 노드들 간에 일관성에 관하여 문제가 생길 수 밖에 없기 때문에, (디스크 오류등 각종 예기치 못한 상황으로) 이를 회복시켜주는 기술이 패브릭에도 필요한데.. 보통 일관성이 깨지는 곳은 스토리지에 무엇인가를 쓸 때이고 보통 하이퍼레저 패브릭에서는 committer 노드에서 일어난다. 좀 더 자세히 설명해 보면 orderer로 부터 받아온 블록을 가지고 해당 블록안에 있는 트랜잭션들을 VSCC, MVCC등의 다양한 방식으로 검증 한후에, 이상이 없으면, A) 블록체인을 업데이트하고 B) 상태DB도 업데이트 하..

메인 Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains : 1.0 아키텍쳐 컴포넌트들 디자인 https://wiki.hyperledger.org/display/fabric/Design+Documents 개별 컴포넌트들에 대한 디자인 설명 성능 Hyperledger Blockchain Performance Metrics , http://www.mscs.mu.edu/~mascots/Papers/blockchain.pdf 성능측정방식 Performance Benchmarking and Optimizing Hyperledger Fabric Blockchain Platform 성능측정결과 FastFabric: Scalin..

어차피,마침, 혹시, 굳이,김에 ,~바연, 차라리,이왕,애초에, 반면, 커녕, 구태여, 딱히, 하긴 .. 외국인 직원들과 토론할 때 머리속에 애꿋게도 먼저 떠오르는 단어들...영어로 치환 마져 바로 안되서 대락 난감...ㅜㅜ 이번기회에 정리 해보기로 했다. Let's go 어차피 : anyway 어차피 지워질 데이터이기 때문에 여기서 처리 할 필요가 없다. There is no need to process it here because it is data that will be erased anyway. 마침 : No english, happend to , just , exactly 마침 가진 돈이 없어요. I happen to have no money with me 마침 새 서버가 도착했습니다. A ne..

사실 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) 또한 비잔틴이 될 수 있으며 그땐 새로운 대표노드를 선출 하게 됩니..

소프트웨어 아키텍트는 무엇인가? (개나 소나 다 자기 생각이 있는데 대충 끄젹꺼려 봄...) 보통 아키텍트 - 디자인 - 개발로 구성되는데 하이퍼레저 패브릭으로 설명 해 보면 (분야 및 조직규모등에 따라서 달라 질 순 있다) 소프트웨어 아키텍트는 "정체성" 을 확립하고 "균일성" 을 보장하는 롤을 갖는다. 즉 이 소프트웨어는 도대체 뭘 하는 것인가? 각 기업들이 서로 간의 신뢰성을 갖는데 최소의 비용으로 그것을 처리하게 하는게 목적이다. 성능 및 컨트랙트 활용성에 중점을 두고, 보안은 xxx 이상의 수준 이상으로 올리고..유저신원이 discolose 되야하고 플러그인 방식으로 컴포넌트 유연성을 갖추고..등등 이 솔루션이 커져가는데 있어서, 지켜야할 선과 확장되는데 있어서 중구난방하지 않게 사용자들이 혼동..

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 Orderer, but in case there's m..