블록체인 네트워크망이 고장날 가능성은 없나요?
완벽한 네트워크망은 없듯이 블록체인 네트워크망이 고장날일이 생길수도 있을것 같습니다.
그런일이 생기면 암호화폐의 전송이나 거래가 되지않는 현상이 발생해서 큰 혼란이 올것 같은데 그런 사례 또는 가능성이 있나요?
질문자께서 해킹이라는 용어 대신 '고장'이라는 용어를 쓰신 것이 일시적으로, 전체가 아닌 일부이지만 다수인 유저들에게 블록체인 네트워크의 서비스 제공이 원활하지 못한 상태를 말씀하신 것이라고 생각하고 답변을 드리도록 하겠습니다.
자주 일어나는 일이 아니라 특수한 사례라는 점을 말씀드리면서, 이오스 블록체인의 사례를 들어 설명을 드리도록 하겠습니다. 이오스의 경우 계정을 만들어서 이오스 코인을 스테이킹 함으로써 한정된 컴퓨팅 자원(CPU, RAM)과 네트워크 자원(NETWORK)을 자신의 몫으로 할당받아 사용하는 방식으로 운영됩니다. 따라서 자신의 몫으로 할당된 자원 대역폭 내에서는 수수료가 없이 블록체인을 이용하는 것이 가능합니다.
그런데 수수료가 없다보니 스팸 트랜젝션을 일으켜서 네트워크에 과부하를 일으킬 가능성이 존재합니다. 실제로 작년에 이오스 블록체인에서 5만 이오스를 스테이킹하고 있는 blocktwitter라는 계정이 이오스 네트워크의 트랜젝션 수가 적은 시간에 자신의 CPU자원 보다 훨씬 많은 자원을 한꺼번에 사용하며(블록체인의 유휴 자원의 사용을 허용하고 있음) 엄청난 스팸 트랜젝션(We Love BM)을 일으킴으로서 이오스 코인을 많이 스테이킹 하지 않은 다른 사용자들의 CPU자원 사용을 방해하여 일시적으로 트랜젝션의 처리가 원활하지 않았던 적이 있습니다.
앞서도 말씀드렸다시피 한정된 컴퓨팅 자원과 네트워크 자원을 나눠서 사용하게 되는데 한 계정이 자신에게 할당된 몫보다 더 많은 CPU 자원을 순간적으로 동원하여 무의미한 스팸 트랜젝션을 보내는데 사용함으로써 상대적으로 적은 이오스를 스테이킹 하고 있던 사용자들의 CPU 자원 이용이 어렵게 되었고 따라서 이오스 블록체인 이용에 불편을 주게 된 것이라고 할 수 있습니다.
끝으로 이러한 문제는 BP들의 투표와 합의를 통해 이런 스팸 계정을 블락시키는 방법과 BP들이 그레이리스트를 만들고 이런 스팸 계정들을 등록하여 이 계정들의 경우 자신의 이오스 스테이킹으로 할당된 자원 이상의 유휴 자원들을 활용하지 못하도록 하는 방법들이 있을 수 있습니다.
답변이 도움이 되길 바랍니다.
안녕하세요. 블록체인 네트워크망이 고장날 가능성은 없나요?라고 문의 하셨는데요.
flymoon님께서 문의 하신것처럼 블록체인 네트웍망에도 문제가 생길수 있을듯 합니다.
최근 KT아현지사에서 인터넷망에 화재가 발생을 하여 통신이 마비가 되는 사태가 있었는데 블록체인에서도 충분히 문제점이 있을거라 생각을 합니다. 그래서 자료를 찾아봤더니 상태복제(state replication))라는 용어와 시리얼 라이저(serialize)라는 용어를 오늘 알게 되었습니다.
아래 내용을 읽어보시면 flymoon님께서 문의 하신 내용이 이해가 되실듯 합니다.
출처 : https://m.blog.naver.com/kiseop91/221485220202
메세지 교환
노드들은 거래장부를 동일하게 관리하기위해 메세지를 교환해야만 하는데 어떻게 주고받는지에대해 생각해보자
메세지를 교환 하는 방법에는 크게 두가지가 있다. 동기식 메세지 교환, 비동기식 메세지 교환
동기식의 경우 보내야하는 메세지가 100개라면 하나씩 순차로 보내며 보내고난뒤 잘받았는지 확인하는 작업을
진행한다 때문에 A와 B는 끝나는 시점이 동일하다.
비동기식의 경우 한번에 100개의 메세지를 보내고 B의상태가 완료 될때까지 다른작업을 할 수있다.
동기식과 달리 각각의 메세지의 수신을 확인 하는 작업이 없기 때문에 비동기식에서는 100개중에 어떤손실이 있고
그것을 처리하는 작업이 필요하게된다.
두개의 노드의 메세지를 주고받는 과정은 TCP를 생각하면 이해하기 쉽다.
다중노드 사이에서 메세지 교환하기
송신노드 (client) 와 수신노드 (server) 가 각각 두개있다고 가정해보자. ( C1, C2 , S1, S2 )
각 서버는 동일한 장부를 계속 기록할 수 있을까?
가정 : C1의 거래기록을 TC1 , C2의 거래기록을 TC2 라한다.
S1은 TC1을 먼저수신 받고, TC2를 수신받아 기록했다.
S2는 TC2를 먼저수신 받고 ,TC1을 수신받아 기록했다.
네트워크의 연결상태에 따라, 혹은 모든 거래가 동시에 이루지지 않기 때문에 각 서버가 받는 거래의 순서가 뒤죽박죽 섞이게 된다.
따라서 모든 노드가 동일한 장부를 가지기위해 중간에서 거래기록을 정렬해주는 노드가 필요하게 된다.
이를 serializer라 한다. 이 시리얼라이저는 C1과 C2에게 받은 거래기록을 받은 순서대로 기록하고 S1 과 S2에게
전송한다.
상태복제란?(state replication)
모든 노드가 순차적인 명령을 같은 순서로 수행
서버가 같은 내용의 장부를 가지도록 만드는 것을 상태복제라 한다.
상태 복제 중 일부 서버에 문제가 생기면?
시리얼라이저가 수신받은 명령을 순차적으로 정리해서 각 서버에게 상태복제를 수행하는데 이때 어떤 서버는 제대로 수신받았지만 어떤 서버는 문제가 생겨 제대로 수신받지 못할 수 있다. 이때 시스템은 그 서버가 복구될때까지
기다리지않고 시스템에서 배제시킨다.
serialize(또는 coordinator)에 문제가 생기면?
시리얼라이저에도 문제가 생길 수 있는데, 이 때는 문제가 생긴 시리얼라이저를 배제시키고 새로운 시리얼라이저를 선정하여 문제를 해결한다.
Two-Phase- protocol
1단계 - 클라이언트가 모든 서버에게 lock 요청
2단계 - 경우 1. 클라이언트가 모든 서버로부터 lock 접수
클라이언트는 모든 서버에게 명령(command)을 보내고 lock을 돌려줌. (커멘드:장부를 기록하라는 명령)
경우 2. 클라이언트가 서버로부터 lock 미접수
클라이언트는 수신한 lock을 돌려주고, 대기후 단계1을 다시 수행함.