HAMA 블로그

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..

엔터프라이즈향 블록체인 비교 * fabric과 corda에만 기대를 하고 있는데, fabric과 corda를 어딘가에 사용했다라는 기사는 많은데, 어떻게 거버넌스를 이루어서 어떻게 사용했다라는 구체적인 기술 정보가 부족해서 아쉽다. 언제 실전기술이 될런지.... (사용 결과에 대한 효율 증가 분석표같은건 기대도 안함) 체크1) Hyperledger Fabric에서는 기본적으로 네트워크에 트랜잭션을 보내는 user 또한 허가받은 사람만 가능하며, 그들의 실체는 X.509로 규정되어진다. 하지만 Qourum , Besu는 그냥 user 는 이더리움과 같은 공개키로 만들어지는 anonymous 이다. 허가된 peer에 붙을 수 있는 user에 대한 필터링은 peer 주인이 알아서 할 일 (스마트컨트랙트도) 체..

Hyperledger Indy에 대해서 정리해봤습니다. Indy는 변화,발전되고 있으며, 인사이드에 대한 정밀한 조사,검증을 하진 않았기 때문에 참고용으로만 읽어 주십시요. 개요 Hyperledger Fabric과 Ethereum의 경우 Smart Contract/ChainCode 를 통해서 DID/SSI를 실현 할 수 있는 범용 플랫폼인 반면에 Indy는 오직 DID를 구축하고자 하는 상황에 맞춤으로 만들어진 public permissioned 블록체인 플랫폼이며 다음과 같은 특징이 있습니다. @ Sovrin Foundation (개발조직: Evernym) 에서 제공된 코드 기반의 프로젝트 @ 사용자는 Public 이고 (아무나 사용가능) @ 노드 관리는 Permissioned ( 선출된 대표노드: S..