HAMA 블로그

이더리움의 P2P에서 리모트 피어와 메세지를 읽고/쓸때에는 위의 그림처럼 peer ( 이더리움에서 peer객체는p2p 와 eth에 각각있으며, eth의 peer 는 위 그림의 peer 와 protoRW를 포함한다) 를 통하는데, peer객체는 읽고/쓰기를 rlpxFrameRW를 통해서 한다. 이 글에서는 rlpx의 transport부분은 빼고 rlpxFrameRW를 살펴 볼 것이다.func (pm *ProtocolManager) handleMsg(p *peer) error { msg, err := p.rw.ReadMsg() switch { case msg.Code == GetBlockHeadersMsg: ... case msg.Code == BlockHeadersMsg: ... case msg.Code ..

이더리움에서 TCP기반의 스트리밍을 위해 peer끼리 커넥션을 맺을때 아래와 같은 순서를 갖는데 1. 암호화키를 교환하여 앞으로는 이 키 기반으로 통신하게 함 2. 프로토콜 정보(버전등)를 교환하여 서로 동업자인지 확인하고 3. rlp 로 엔코딩하고 서로 약속된 frame에 맞춰서 메세지를 주고 받는다.이 글에서는 1번에 대해서 코드와 함께 알아 볼 것이다. 접속을 하는 peer를 initiator 라고 하고 접속을 받는 peer를 receiver 라고 한다. 한번 접속했던 경우 known peer라고 하고, 처음 접속하는 peer를 new peer라고 한다. 한번 접속했던 경우에는 session token을 보관하는데, 그렇더라도 항상 접속할때마다 그 기반으로 새로운 키를 만들어 사용한다.(참고: 스트..

얼마전에 블록체인사 CTO분들하고 대화중에 하이퍼레저 패브릭의 합의 알고리즘에 대해서 얘기하다가 "뇌정지"가 온적이 있다. 비트코인 POW부터 POS,DPOS,PBFT,텐더민트식,캐스퍼등에 대한 이해를 거친후에 더 이상은 컨센서스 알고리즘에 대한 공부는 그만 뒀고, (분산네트워킹만이라도 잘하자 싶어서..) 하이퍼레저 패브릭은 그냥 실행-오더링-커밋이지 뭐...라고 평소에 생각했었는데 이번 기회를 통해 정리를 좀 해보려 한다. 알고리즘 자체에 대한 내용이라기 보다는 전체조망이랄까? 주저리주저리 해 볼 생각이다. 거의 유일한 하이퍼레저 패브릭 서적이라고 볼 수 있는데, 이 책을 완독한 후에도 합의 관련된 이해는 할 수 는 없다. 관련 내용이 (구체적으로) 없으니까~ 즉 모든 원흉은 이 책이다. 농담이다.. ..

예전에 강연때 PPT로 만든것인데 블로그로 옮김. 3줄 정리 - 자신과 연계된 UTXO 를 소비 하려면 그때 자신의 서명을 생성해서 트랜잭션 내부의 INPUT에 넣어 보낸다. - 검증노드들은 해당 서명을 이전 트랜잭션의 OUTPUT과 매칭이 되면 ㅇㅋ 해줌 - 즉 현재 트랜잭션 내부의 INPUT은 이전 트랜잭션의 OUTPUT과 매칭용이고, 현재 트랜잭션의 OUTPUT은 받는 사람의 계정과 연결되되, 나중에 받는 사람이 이 UTXO를 사용하는 트랜잭션을 만들 때 그 INPUT과 매칭될 것이다. - 최종적으로 TxID를 만드는 과정은 : https://steemit.com/kr/@niipoong/id-create-bitcoin-txid 를 참고한다. 받는 사람 : ScriptPubKey(잠금스크립트)에서 O..

윤대근님의 하이퍼레저 패브릭으로 배우는 블록체인의 내용을 참조하여 구성되었습니다.간단정리: Fabric-CA를 통한 보안메터리얼들 생성 가. Fabric-CA 를 이용해서 각 조직의 admin msp 를 생성한다. 나. 각 조직의 admin은 조직이 가지고 있는 각 Peer의 msp 를 생성한다. ---- 여기까지가 8번 ----- 인프라 (채널등) 구성하고 시작하기 다. genesis.block 을 각 조직의 공개키를 가지고 생성하여 오더러를 구동한다. 라. 각 peer 들을 구동한다. 마. 채널을 생성한다. 바. 채널에 peer들을 참여시킨다. 사. 앵커피어 업데이트 ------ 여기까지가 15번 ----체인코드 설치 및 읽고,쓰기 아. 각 Peer에 체인코드 설치 자. 하나의 peer 에서 체인코드..

퍼블릭 블록체인 (이더리움) 철학은 화폐의 이동에 대한 "신뢰 비용"을 줄이기 위해서라면 콘소시엄 블록체인 (하이퍼레저 패브릭) 철학은 조직간의 "신뢰 비용" 을 줄이기 위해서이다.(코인이 없으며 굳이 넣을 수도있겠지만 그게 의미 있는지에 대해 매우 회의적입니다. 퍼블릭체인과의 인터체이닝도 마찬가지 개념에 대한 변화가 심하며 앞으로도 계속 변화 할 것이기 때문에 쉽사리 규정짓기 힘들기도 합니다만..)즉 하이퍼레저 패브릭을 공부하거나 먼가를 만드는 목적이 일반인들을 위해서 DApp을 만들려고 한다면 이상한거다. 또한 무슨 보안을 위해서라든지 위변조 방지를 위해서라든지 이런 구실을 만들어서 장부에 저장되는 어떤 기록에 대한 주체가 하나인 경우임에도 하이퍼레저패브릭로 해야 한다고 주장하지 말자. 보안,위변조방..

초반에 IBM Cloud 계정가입에 문제가 생겨서 차질이 있었지만, 한달동안 하이퍼레저 프로젝트를 잘(?) 완료 하였다. 해당 프로젝트는 웹서비스단(React,Express,Mongo)와 블록체인단(Composer Rest Server, IBM Blockchain) 으로 이루어졌는데, 중간에서 Mongodb가 캐싱역할을 하며, 웹서비스단에서 블록체인에 대한 호출 즉 Composr API 호출을 위임하고 있는 형태. 따라서 Composer Rest 서버를 멀티유저(혹은 싱글서버를 카드별로 여러개) 가 아닌 단일유저가 사용하므로 신뢰의 분산에는 적합치 않은 모습..차후에 이걸 어떻게 분산시킬지.. 분산을 꼭 시켜야할지에 대한 고민과 동시에 하이퍼레저를 다루는 방식이 굉장히 다양할수 있으며, 버전에 따라서 예..

사족 하이퍼레저 컴포저는 분명히 하이퍼레저 패브릭 네트워크/어플리케이션을 만들기 쉽게 해주지만, 패브릭을 추상화 하는데 있어서 어려움도 많습니다. (패브릭에서 추가된 기술을 따라 잡지 못한다던가, 모습이 전혀 달라서 처음 진입하는 사람들에게 큰 혼동을 초래. 예를들어 컴포저의 Participant 가 fabirc의 무엇과 매칭되는가? 컴포저의 Card 개념은 fabric의 무엇인가? 컴포저로 멀티유져/조직을 다루는 방법등~) 현재 몇몇 문제 때문에 IBM에서 컴포저에 대한 지원을 줄였지만, 업데이트는 계속 될 것이라고 하네요. 개인적으로는 컴포저의 역할이 매우 중요하리라 생각합니다. 이쪽이 훨씬 더 키워드들이 실세계와 매칭되며 간단하니까요~사람들이 사용하지 않는 기술,어려운 기술은 사장되기 마련입니다. ..

레퍼런스: https://www.hyperledger.org/projects/sawtooth https://stackoverflow.com/questions/47023945/whats-the-difference-between-hyperledger-fabric-and-sawtooth https://hackernoon.com/know-hyperledger-fabric-then-moving-to-sawtooth-is-easy-15445f902493 https://www.oodlestechnologies.com/blogs/Hyperledger-Sawtooth-Vs-Hyperledger-Fabric https://www.quora.com/Can-Hyperledger-sawtooth-work-without-Hype..

1. Gossip 프로토콜 일반 이더리움의 DEVp2p 네트워킹보다는 비교적으로 간단한 편인 하이퍼레저 패브릭에서의 네트워킹구조 를 살펴보자. 참고로 이더리움의 DEVp2p 에 관련되어 이전에 작성한 글이 있으니 Public 체인에서는 어떻게 하는지 참고 하자. -> [Ethereum] Node Discovery with Kademlia -> [이더리움 코어] DevP2P 소스코드 분석 (feat. golang) 암튼 둘다 Goosip 을 이용하는데, Gossip 즉 소문이란 무엇인가? 내가 주변 몇사람한테 연예인에 대한 잘못된 소문을 내는 순간에 그들이 또 각자 소문을 내고 이런식으로 내가 전체에게 알리지 않아도 전체가 알게 되는 것을 말하며 특징은 이런것이 있을 수 있겠다..- 전체에 말하지 않아도 ..