배경
비트코인이 나오기까지 해결해야 했던 문제들은 많을 것이다. 그리고 결론적으로 비트코인 등의 블록체인 기술은 타인들이 수긍하는 합의점을 제시했기에 지금의 모습으로 나타날 수 있었다.
나는 블록체인과 블록체인이 있기 전까지의 기술들이 어떤 문제들을 풀어왔는지를 다뤄보려고 한다. 그리고 밑에서 제시될 문제들을 정리하고 보면, 블록체인 개발 중 당면한 문제에 대해서 체계적인 분석이 가능하게 될 것이다.
특히 아래에 참고한 블로그 글이 특히 도움이 되었기에 이 글을 보는 것보다 링크된 글을 참고하는게 더 낫다는 말을 먼저 밝혀두겠다
분산 시스템
생각보다 분산 시스템은 우리의 일상에서 금방 관찰할 수 있다. 분산 시스템의 적용을 끝까지 밀어붙이면 나와 타자의 존재까지도 분산 시스템으로 바라볼 수도 있을 것이다. 하지만 이는 우리의 논지에서는 많이 벗어나게 된다. 지금은 우선 컴퓨터 환경에서만 생각해보기로 하자.
분산 시스템은 서로 분할되어 작동하는 노드들이 공동의 목표를 위해 작업을 하여 성공적으로 시스템을 이끌어 나가는 것을 말한다. 그래서 분산 시스템을 구현하는데 중요한 것은 노드들끼리 연결된 네트워크를 어떻게 지속적으로 운영을 해나갈 수 있는지에 대한 방법이다.
Failure Model
노드들의 네트워크를 만들기 위해서는 노드들끼리 메시지를 주고 받아야 한다. 그리고 주고 받는 메시지들은 각각의 노드들의 상태에 영향을 미친다. 하지만 메시지가 전달되는 모든 경우가 성공적으로 이루어지지는 않는다. 예를 들면, 내부 에러로 다운된 노드는 메시지를 응답할 수 없고, 이는 회신을 불가능하게 한다. 해당 노드가 갖는 정보를 필요로 하는 타 노드는 작업에 지장이 생기게 될 것이다.
이렇다보니 분산 시스템은 단일 노드에서 작업하는 것과는 차원이 다른 에러와 문제를 발생시킨다. 현실적으로 이러한 문제들을 모두 처리할 수 있는 분산 시스템을 만드는 것은 힘들기 때문에, 분산 시스템은 자신이 감당할 수 있는 에러를 정의한다고 한다. 이 때, 분산 시스템이 정의할 수 있는 에러의 종류를 정리한 것을 Failure Model 이라고 말한다.
Failure Model은 위처럼 보통은 6개의 계층 구조로 나열할 수 있다. 가장 안쪽의 Failure 비교적 처리하기 쉬운 에러이고, 원의 바깥에 있는 Failure일 수록 처리하기가 어려운 문제이다. 분산 시스템은 목표 Failure Model을 설정하고, 그 이외 발생하는 에러의 처리는 포기한다.
웹개발 서버 작업 중, 응답으로 status를 설정해주는 것도 이 Failure Model의 한 목표를 달성하기 위해서 하는 행위라고 생각해도 좋을 것 같다. "웹도 분산시스템이다!"
Failure Model 종류
- 메시지를 무조건 신뢰하는 경우
⌞ Fail-stop Failure Model
문제가 발생한 노드를 더 이상 상태가 변하지 않는다. 응답이 필요하다면 문제 발생 전 상태를 반환하게 된다. 이 모델의 가정은 "항상 요청한 메시지는 도착을 하고, 도착한 메시지는 정상이다"라고 한다. 하지만 현실적으로 메시지가 훼손될 경우는 언제나 존재하기에 잘 사용되지 않는 모델이라고 한다.
⌞ Crash Failure Model
요청에 대해 응답을 주지 않은 노드는 언제나 충돌이 일어났다고 가정한다. 이 같은 경우 해결은, 문제가 발생한 노드를 대체할 수 있는 노드가 꼭 존재해야하고, 그 노드에게 요청을 해주면 된다. 하지만 요청 메시지에 대한 응답이 돌아오지 못하는 경우는 현실적으로 여러가지가 존재한다. 이 모델 같은 경우는 프로세서 간 통신, 데이터 센터 내 분산 시스템에서 많이 사용된다.
⌞ Omission Failure Model
일정 시간 T 시간을 정한 뒤에 T 시간 이내 메시지가 꼭 도착해야함을 임의로 정하고, 시간 내 메시지가 도착하지 않으면 메시지는 영원히 오지 않을 것이라고 가정한다. 오거나 못 오거나로 상황의 설정을 최대한 단순화 시켰다.
⌞ Performance Failure Model
하지만 위의 Omission 모델 같은 경우 T를 예측한다는 것이 쉬운 일이 아니다. 또한 애써 T를 정했지만 T 이후에 문제의 메시지가 도착하는 경우도 생긴다. Performance Failure Model 같은 경우는 응답이 늦어질 경우도 대비하는 모델이다.
- 메시지를 불신하는 경우
사실 위의 모델들은 공통점으로 도착한 메시지는 무조건 신뢰한다는 가정이 깔려 있다. 하지만 우여곡절로 도착한 메시지조차도 신뢰 여부를 판단할 요소로 포함시킬 수 있다. 간단히 말하자면 메시지도 검증이 필요한 것이다. 메시지가 전송되는 과정에서 누가 개입하여 위조된 메시지로 대체해버리면, 그리고 위의 같은 모델을 사용하는 네트워크의 노드가 해당 메시지를 받는다면 어떻게 될까(Man in the Middle 공격)? 메시지를 맹신해버리고 몰락의 길로 들어설지도 모른다.
⌞ Authenticaiton-dectable Byzantine Failure Model
검증 가능한 Failure만을 처리하겠다는 모델이 바로 이 모델이다. Error Dection Scheme, 혹은 비대칭 암호화를 사용하여 상대방과 상대방이 보낸 메시지들을 검증하는 것이다. 이로써 상호 노드간에 최소한의 보안이 지켜질 수 있게 된다. 이 모델은 현재의 인터넷 규모의 분산 시스템이 자주 채택하는 모델이다.
⌞ Byzantine Failure Model
위의 모델은 결국 필터링의 작업이다. 메시지 중에서도 검증이 필요한 부분만 거르고, 그 이외의 내용은 취사 선택에 달려 있다. 어떻게 하면 아무런 보장 없이도 상대 노드가 보내는 메시지를 신뢰하고 사용할 수 있을까? 이 문제의 해결에서 블록체인이 등장한다. 블록체인의 여러 합의 알고리즘이 이 모델을 상정하고 만들어지기 때문이다.
Byzantine Failure Model은 위에서 던졌던 질문에 대한 답을 찾는 모델이다. 그리고 가장 현실에 가까운 문제를 해결하는 모델이다.
참고
