HAMA 블로그

현대 프로그래밍에서 가장 중요한 오류들인 동기화 문제( 레이스컨디션이나 데드락등 )는 C++같은 언어로 개발한 제품들에서 굉장히 많은 문제를 발생시키곤 한다. 윈도우즈 오류의 대부분이 동기화문제, 메모리관리 문제라니까.. 그중 동시성에서 레이스컨디션 문제는 1. 가변변수인데 게다가 동시접근가능 할 때 발생된다. 즉 2. 가변변수가 없거나 ㅡ 순수함수형 3. 동시접근예방 ㅡ Actor패턴 , CSP (예방이지 불가는 아님) 둘 중 하나만 충실 하면 근본적으로 없앨수 있다는 얘기이다. 1번 경우는 뮤텍스등을 통해 직접 보호 장치를 해야 하는데 , C++,Java, Go 같은 착한 (방종 or 자유로운) 부모하에서 인간의 실수는 비일비재 하다. 배움이 모자르고 막나가는 아이들도 생겨남. 근데 러스트는 엄한부모..

1. 메모리에서의 안전요소 https://medium.com/a-journey-with-go/go-memory-safety-with-bounds-check-1397bef748b5 Go: Memory Safety with Bounds Check ℹ️ This article is based on Go 1.13. medium.com https://insanitybit.github.io/2016/12/28/golang-and-rustlang-memory-safety Golang and Rustlang Memory Safety - InsanityBit I recently read an excellent blog post by Scott Piper about a tool he has released called S..

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

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

기사) https://www.samsungsds.com/global/ko/about/news/nexledger-accelerator.html 삼성SDS, 블록체인 가속 기술 발표삼성SDS(대표 홍원표)는 14일 미국 샌프란시스코에서 열리고 있는 IBM의 연례 기술 컨퍼런스인 ‘IBM Think 2019’에서 블록체인 가속 기술을 발표한다.www.samsungsds.comGithub) https://github.com/nexledger/accelerator핵심아이디어는 개별 트랜잭션들을 묶어서 처리하는 것인데, 이로 인해서 개별 트랜잭션 부하를 배치로 묶어서 하나로 줄일 수 있게 되면서 네트워킹 부하 뿐 만 아니라 서명확인에 따른 부하까지도 줄일 수 있습니다. 하지만                      ..

이번 포스트에서는 하이퍼레저 패브릭에 관련된 기술중에 가장 알려지지 않은 주제인 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) 또한 비잔틴이 될 수 있으며 그땐 새로운 대표노드를 선출 하게 ..