가상화폐를 지원하는 혁신적인 기술인 블록체인(Blockchain) 아이디어는 비트코인 디자인 페이지에서 나왔지만, 그 내용에는 블록체인이란 단어가 나오지 않았습니다. 블록체인에 해당하는 개념은 “타임 스탬프 서버”라는 부분에 설명되어 있습니다. 이로 인해 블록체인과 타임스탬프는 상당히 큰 연관성이 있어 보인다는 것을 알 수 있습니다.
그렇다면, “타임 스탬프” 개념에 대해서 다시 생각해 봅시다. 일반적인 타임스탬프(Timestamp)라고 하면 “2018-04-05 13:00:00”등의 형식으로 표현되는 날짜와 시간이 적힌 문자열이라고 생각하게 됩니다. 실제 생활에서는 독자가 여행을 가기 위해 KTX 티켓을 예매하기 위해 시간을 선택하면 그것을 누가 언제 몇시 몇분에 탑승을 위한 계약 내용에 날짜와 같이 저장되는 것이 타임스탬프의 한 종류라고 봐도 됩니다.
이런 타임스탬프의 역할은 어떤 이슈가 일어난 날짜와 시간을 기록하여 사실 존재를 증명하는 전후 관계를 보장하는 것입니다.
현실세계의 타임스탬프
현실세계의 타임스탬프는 모든 사람이 같은 시간축을 공유하는 것과 시간은 돌이킬 수 없는 것이라는 두가지 전제로 하고 있습니다. 정확하게 이야기하면, 현대 물리학에서는 시간의 흐름이 일정하지 않고 각 사람마다 시간축이 미묘하게 어긋나 있다고 생각하지만, 일상 생활에서는 그 오차를 생각할 필요는 없습니다.
또한, 전세계적으로 보면, 지역별 시차가 존재하지만, 표준 시간과 현지 시간등의 표준화를 통해 모든 시간축을 공유하려고 합니다. 또한, 시간을 되돌릴 가능성도 생각할 필요가 없습니다. 물론, 영화나 드라마에서 보던, 타임머신이 개발된다면 과거로 돌아가 변경할 수 있게 된다면, 현대 사회 시스템 대부분을 재검토해야 합니다.
실제 현실세계에서 현금을 사용하여 지불하는 경우를 생각해 봅시다. 실제 현금을 전달하는 행위가 발생하지만, 그 행위가 발생하는 시간은 단 한번뿐 입니다. 그러나 현금을 받은 사실을 부정할 수 있어, 발생한 내역을 어딘가에 기록해 둘 필요가 있습니다. 따라서, 영수증이나 계약서 발행이 현실세계에서 타임스탬프 역할을 하고 있습니다.
컴퓨터의 타임스탬프
컴퓨터 세계에서 현실세계의 시간과 컴퓨터의 시간이 반드시 동기회되는 것은 아니기 때문에, 여러 환경에 따라 다른 시각을 보일 수 있습니다. 각각의 환경이 참조하는 시간이 다르기 때문입니다. 여기서 지불한 사실이 언제 일어났는지에 대한 합의를 하지 못하면, 사실 증명이 어렵게 됩니다.
이런 경우, 타임스탬프는 악의적으로 쉽게 변경할 수 있어, 다양한 어려움이 생기게 됩니다. 예로 독자들이 스마트폰에서 게임을 하는 경우가 많을 것입니다. 게임에서 이벤트를 할 경우, 특정 시간에 한정 아이템을 받을 수 있는 조건이 발생하거나 특정 시간대에서만 얻을 수 있는 혜택이 제공됩니다.
이벤트 시간이지만, 이전부터 스마트폰 기기의 로컬시간을 확인하여 이벤트가 있는지 체크하는 앱도 있었습니다. 이런 경우, 사용자가 기기의 시간대를 변경해서 미리 이벤트 정보를 확인하고 부정 플레이를 할 수 있게 됩니다.
이런 경우를 예방하기 위해 기기의 로컬시간을 변경하는 것을 막기 위해 최근 앱이나 시스템에서는 대부분의 서비스를 제공하는 서버측 시간을 확인해서 이벤트 유무를 판별하고 있습니다.
중앙집권적 타임스탬프
인터넷 서비스는 불특정 다수의 사람들에게 서비스하는데 있어서 어느 한 곳에 중심을 두고 그 중심점의 시간을 기준으로 서비스 무결성을 유지하고 있습니다. 예로 홍길동이 이순신에게 돈을 송금할 때 실제로는 은행에 홍길동과 이순신의 계좌를 개설하여 그 계좌의 잔고를 통해 처리하는 것뿐입니다. 이 경우 중심이 되는 시간은 은행 서비스 시간입니다.
그렇지만, 중앙집권적 시스템에는 몇가지 문제점이 있습니다. 첫번째, 중심부에 부하가 집중되기 쉽고, 중심부가 정지되면 서비스 전체를 이용할 수 없게 되어 버립니다. 예로 앞에서 이야기했던 모바일 게임에서도 이벤트가 시작될 때 사용자가 몰리면, 중앙 서버 부하가 걸려 시스템이 다운되어 버리는 경우가 있습니다. 이를 예방하기 위해 중심부 서버를 이중화하고 성능을 향상시키기 위한 대책을 세우기도 하지만, 그 대책에 따라 큰 비용이 발생합니다.
인터넷이 시작된 이래 인터넷 자체가 다운된 사례는 없지만, 인터넷 서비스가 다운되는 경우가 있는데 이런 중심부 서버에 의존하는 구조이기 때문입니다. 또한, 중앙집권적 시스템은 중심부 서비스 제공자가 의도적으로 서비스를 중지하거나 어떤 악의적인 일을 할 경우, 막을 방법이 없습니다. 비트코인은 “아무도 간섭없이 사용할 수 있는 송금 구조를 만들자”것과 “누구도 마음대로 중지시킬 수 없다”라는 구조를 실현하기 위해서는 중앙집권적 구조는 힘들고 중심부가 없는 P2P형태의 구조를 생각하게 된 것입니다.
비중앙집권적 타임스템프
P2P 시스템에서 중심부 시간에 의존하지 않은 상태로 송금등 타임스탬프를 필요로 하는 데이터를 처리하는 새로운 타임스탬프 방법이 필요해졌습니다. 물론, 비트코인이 나오기 전에도 P2P기술을 이용하는 서비스들이 존재했습니다. 대표적인 서비스로는 BitTorrent, Skype등이 유명했습니다. 이 서비스는 반드시 타임스탬프를 필요로 하지 않았지만, 타임스탬프가 필요한 서비스를 P2P로 실현하기 위해 중심부 시간에 동기하는 방법으로는 한계가 있었습니다. 그래서 새롭게 개발된 것이 블록체인이라는 새로운 타임스탬프 개념이 나왔습니다.
블록체인이 획기적으로 보이는 이유는 시간을 되돌릴 수 없다는 것과 1개으 ㅣ시간축을 모두가 공유하고 그 시간축에서 전화 관계를 정의할 수 있는 물리적인 시간 특징을 암호화학에 기초한 데이터구조를 사용하여 다시 구현한 것입니다.
해시체인 타임스탬프
물리적 시간의 동기화가 확인하기 어려운 분산시스템에서 모든 참가자가 하나의 시간축을 공유하려면 어떻게 해야할까요?
어떤 사건이 일어난 절대적인 시간을 엄격하게 요구하는 것이 아니라, 전후 관계가 존재하는 2개의 사건에 대해 그 순서를 특정할 수 있는 상대적 시간으로 시간축을 정의하는 방법이 있습니다. 이 말은 사건1과 사건2가 발생했을 때 사건1과 사건2가 일어난 정확한 시간을 몰라도, 사건1이 사건2 다음에 일어났다라는 상대적인 전후 관계만을 취급한다는 것입니다. 이 개념은 분산시스템의 논리적 타임스탬프라고 말합니다.
블록체인은 암호화 해시함수를 사용하여 데이터가 존재하기 전에 다른 데이터가 존재했다는 전후 관계를 논리적으로 부정할 수 없는 형태로 정의하고 있습니다. 여기에서 말하는 암호화 해시 함수는 임의의 데이터를 입력하고 입력 데이터를 대표하는 비교적 작은 값(해시값 또는 다이제스트)을 리턴해주는 해시함수에서 사전에 그 해시값 예측 및 해시값에서 원래 데이터 추정이 어려운 함수를 말합니다. (대표적인 암호화 해시함수: SHA-256, 비트코인에 이용)
위 그림에서 A데이터에 대해 암호화 해시함수를 이용하여 얻어진 해시값 h(A)이라고 합니다. 이때, h(A)에서 A를 요구하는 것은 힘들기 때문에, h(A)값이 존재하는 것은 이전 A데이터가 있는 것이 논리적으로 옮다고 봅니다. 또한, B = h(A)로 h(B)를 계산하면 h(B)가 존재하기 전에 h(A)가 존재하고 있었다고 볼 수 있습니다. 이처럼 동일한 데이터에 대해 재귀적으로 암호화 해시함수를 적용하는 기술이 해시체인입니다. 이 해시체인은 일회성 비밀번호 인증 시스템 구현에 주로 사용됩니다.
위 그림에서 심플한 해시체인을 확장해서 해시 함수에 대한 입력으로 모든 데이터를 포함시키는 방법을 구현해 보면, 아래 그림처럼 x0 ~x3은 모든 데이터를 표시하는 h0 ~h3과 암호화 해시함수의 해시값을 나타냅니다.
심플한 해시체인은 x0데이터에 대해서 재귀적으로 암호화 해시함수를 적용한 해시값 h0, h1, h2~을 생각하지만 원래 데이터는 x0뿐입니다. 이에 대해 확장된 해시체인은 재귀적으로 해시값을 구할 때 입력으로 모든 데이터 x0, x1, x2등을 더하고 있습니다.
이 확장을 통해 h3를 계산하기 위해서는 앞에서 h2, x3가 존재해야 하며 h2를 계산하기 위해서는 h1과 x2가 있어야 재귀관계가 성립됩니다. 그러면 x0 < x1 < x2 ~등과 데이터가 존재하는 전후관계를 임의의 데이터에 대한 논리적인 정의가 가능해 집니다.
그런데, 여기서 해시값 h1, h2, h3 등으로 하면 1, 2, 3, ~ 숫자를 타임스탬프 형태로 간주하고 해시체인 타임스탬프라고 합니다. 연속된 정수를 타임스탬프라고 말하는 것이 약간은 애매하지만, 컴퓨터에서 시간을 처리할 때 자주 사용하는 UNIX타임스탬프도 1970년 1월 1일 0시 0분 0초에서 지난 시간을 계산하는 것이기 때문에 같은 발상으로 생각하면 쉽습니다. 단, UNIX타임스템프와 해시체인 타임스탬프가 거의 동일해 보이지만, UNIX타임스탬프가 실제 시간기준에 따라 1초마다 카운트되는 반면에 해시체인 타임스탬프는 새 데이터가 추가될 때마다 추가되는 형태입니다.
해시체인에서 블록체인 만들기
앞에서 설명한 해시체인을 사용하여 모든 데이터의 존재증명과 전후 관계를 증명할 수 있습니다. 하지만, 실무적인 P2P시스템에서 사용하기 위해서는 몇가지 이슈를 해결해야 합니다.
주요 이슈는 아래와 같습니다.
- 여러개의 노드가 참여하는 P2P 네트워크에서 모든 노드가 항상 최신 타임스탬프를 볼 수 있는가?
- 노드가 과거 데이터를 변조한 경우, 변주 탐지 및 변조 데이터를 거부할 수 있는가?
머클트리는 1979년 랄프 머클에 의해 발명된 것으로 트리 구조의 해시체인을 해시트리라고 부르기도 합니다. 머클트리 구조는 일반적으로 데이터 조각 2개를 쌍으로 나누어 2개의 단편데이터를 결합한 해시값을 계산합니다. 이때 조각 수가 홀수이면 남은 한개의 조각은 자신과 동일한 데이터를 복제하여 2개의 데이터쌍을 만들어 해시값을 계산합니다. 계산된 해시값을 두개쌍으로 나누어 해시값을 계산합니다. 이 작업은 최종적으로 해시값이 하나가 될 때까지 반복됩니다. 마지막으로 하나가 된 해시값을 머클루트 또는 최상위 해시라고 말합니다.
머클트리가 고안될 당시 하나의 키에서 여러개의 원타임 패스워드를 생성하기 위한 데이터 구조로 사용되었습니다. 이후, P2P네트워크등에서 큰 파일을 수신시 데이터 손상이나 변조 유무를 확인하고 손상된 데이터를 다시 수신하도록 되어 있습니다. 만약 데이터가 손상되거나 변조검증뿐이라면 데이터 원본 계산을 한 데이터의 해시값과 수신데이터 해시값을 비교하면 가능합니다. 그러나, 데이터 크기가 커지면 중간에 디에터 손상이 발생할 활률이 높아지고, 데이터가 손상되면 다시 큰 데이터를 처음부터 다시 받아야 합니다. 머클 트리를 활용하면 큰 데이터를 작은 조각 데이터로 분할하여 조각당 해시값을 확인하는 것이 가능합니다.
머클트리를 사용하여 데이터를 확인시, 우선 데이터에서 머클루트를 계산하고 원래 머클루트와 비교합니다. 만약, 머클루트값이 다른 경우, 머클루트르를 계산하기 위해 사용하는 두개의 해시값을 원래 해시값과 비교합니다. 이 작업을 반복하여 해시값이 다른 데이터 조각을 효율적으로 파악할 수 있도록 데이터를 다시 받아도 손상 데이터만 다시 수신하면 됩니다.
그렇다면 이번에는 머클트리를 기반으로 블록 만들어 봅시다.
머클트리 구조를 활용하여 해시체인 타임스탬프를 블록단위로 카운트할 수 있습니다. 하나의 데이터 조각으로 분할하여 조각당 해시값을 계산하지만, 이번에는 모든 데이터 목록에서 머클트리를 생성합니다.
아래 그림에서 모든 데이터를 그대로 해시체인을 포함하는 경우와 머클트리를 이용한 블록단위로 데이터를 포함한 경우를 보여줍니다. 새로운 데이터가 생성될 때마다 해시체인 횟수는 증가되지만, 나중에는 여러개의 데이터를 블록으로 그룹화하여 블록단위로 횟수가 증가하는 것을 알 수 있습니다.
블록단위로 증가된 해시값 계산을 다시 타임스탬프로 생각해 봅시다. 해시체인에 그대로 데이터를 포함하는 경우, 데이터마다 타임스탬프가 증가하지만, 같은 타임스탬프에 여러개의 데이터를 참조합니다. 아 타임스탬프는 타임스탬프가 0이 되고 있는데 x0과 x1데이터는 동시에 생성된 데이터로 분석됩니다. 또한 타임스탬프가 2가되는 데이터가 존재하지 않지만, 이는 데이터를 생성하거나 타임스탬프 증가가 블록을 도입하여 독립했기 때문입니다. 데이터가 생성되자 않아도 타임스탬프가 생성되기 때문에 일반적인 시간 표시에 가까운 표현이 가능하게 됩니다.
물론 위 내용의 기준대로 블록개념만 도입한다고 해서 여러 개의 노드가 참여하는 P2P네트워크에서 모든 노드가 항상 최신 타임스탬프로 볼 수 있을지에 대해서 완벽하게 대응하기 어렵습니다. 이 문제를 해결하기 위해 최신 블록 정보가 모든 노드에 적용될때까지 다음 블록이 생성되지 않도록 해야 합니다. 이에 대한 현실적인 해결방법으로 PoW(Proof of Work)가 있는데 이것에 대해서는 다음에 정리해 보겠습니다.