내멋대로 블록체인 #2 (Peer, Node 설계)

주의!!

해당 포스팅은 자바로 블록체인을 구현하며, 장기간의 프로젝트로 초반에는 매우 많은 삽질을 할 수 있다는 점 양해 바랍니다. 자바 자체가 블록체인에 적합하지 않는 언어(속도가 C, C++보다 느리며, 디컴파일에 취약)이기 때문에 이렇게도 구현 되지 않을까 정도내지 프라이빗 블록체인(퍼블릭은 무리)을 포커스를 삼고 있습니다.

영상은 이미 2주전쯤에 찍어서 올렸는데, 포스팅을 올리는걸 깜빡하여 뒤늦게 포스팅을 합니다. 첫번째는 플랜을 전체적으로 짜보았고, 두번째는 본격적으로 노드를 어떤식으로 구성을 하는 것이 좋을까에 대한 내용입니다. 일반적으로 소켓(Socket) 통신을 통해서 브로드캐스팅(Broadcasting)하는 방식을 사용할테지만, 저는 그런거 안하고 구현할 겁니다 (web api 방식)

Type 1, Master가 모든 것을 제어

중앙에 있는 매우 강력한 마스터 노드(Master Node)가 모든 것을 관리하는 방식입니다. 노드를 새로 실행할 경우 최초로 마스터 노드에 연결하게 되고, 마스터 노드는 신규 노드에게 기존의 노드 리스트 정보를 전송하게 됩니다. 

이렇게 만들 경우에는 private이 아닐 때 노드의 부하가 심할 거라 생각할 수 있지만 마스터 역시 여러대를 만든 후 분산(로드 밸런싱)을 할 수 있기 때문에 큰 무리는 없을 것 같고 어차피 프라이빗으로 돌 예정이라 마스터에서 관리를 하는 것이 어찌보면 가장 안정적이다 생각할 수 있을 것 같습니다.

만약에 퍼블릭 모드로 구현을 하고 싶을 경우, 특정 노드에서 마스터 노드를 공격할 수 있기 때문에 요청이 있을 때마다 즉시 주는 것보다 한번에 몰아서(ex: 5초마다 전송) 주게 될 경우, 노드의 관리도 쉽고 이상 공격을 감지하기도 쉬울 것 같습니다. 

Type 2, Master가 다른 노드에게 명령

제가 생각하는 두번째 방식은, 마스터로 연결은 하되 마스터와 리스트가 동일한 노드에게 리스트를 전송하라고 명령을 내리는 겁니다. 이렇게 될 경우 마스터는 정말 관리만 하고 행동은 노드들이 하게 되는 것이죠.

마스터에게 생기는 부하는 이로서 줄어들 것이지만, 문제는 명령을 받은 노드가 느릴 경우 입니다. 이는 마스터가 커넥션을 맺은 후, response time이 얼마냐인지를 체크하여 특정 시간(timeout)을 넘기지 않는 노드에게만 명령을 수행하면 될 것 같습니다.

노드가 새로 등장 될 경우

클라이언트를 실행할 경우, Master Node의 ADD url에 접속하게 됩니다. 이 ADD를 수행할 때, 마스터는 요청하는 클라이언트의 상태값을 체크하며(버전, 장부, 해시값) 버전과 해시값이 이상이 없을 경우 동기화를 수행하게 됩니다. 

버전이 낮을 경우, 신규 클라이언트를 다운 받으라고 하며 해시값이 이상할 경우, 장부를 새로 받아서 올바른 해시값을 받게 됩니다. ( 이 부분은 나중에 구현 )

API 실행

구조는 매우 간단하게 Java의 HashMap에 정보를 담고 있습니다. 현재는 키(어드레스)만 담고 있으나, 나중에는 Value에 여러가지 정보들이 담겨져 있어야 하겠지요. 

일단 ADD를 수행해봅니다.

현재, 172.20.38.73 아이피가 붙어 있으나 제 아이피는 아니고, 

68이 제 아이피(서버, 클라이언트 동일)입니다

제 아이피를 지우겠습니다.

지워진 것을 확인

이 방식을 통해서, 매우 간단하게 IP를 관리할 수 있습니다. 

유튜브 영상

포스팅보다 영상이 약간 더 자세합니다 :)