블록체인의 탄생 : How to Time-Stamp a Digital Document

박창우
CURG

--

By. 박창우| researcher of C.U.R.G

블록체인의 시작을 되돌아보는 것은 앞으로의 흐름을 이해하는데 도움이 될 것이다

블록체인의 시작은 무엇일까? 일반적으로 비트코인을 최초의 블록체인으로 오해하는 경우가 많다. 우선, 블록체인이 뭔지 정의를 내려보자. 현 SEC 의장 게리 젠슬런가 MIT에서 강의한 “Blockchain and Money”라는 강의에 따르면 블록체인이란, 추가만 가능한 타임스탬프가 된 로그다. 비트코인이 블록체인의 혁신을 불러온 것은 사실이나, 타임스탬프가 된 추가 기능만 있는 로그(append only log)는 비트코인이 최초가 아니다.

블록체인은 1991년 bell labs에서 Stuart Haber와 Scott Stornetta가 낸 ‘How to Time-Stamp a Digital Document’라는 논문에서 처음 소개되는데, 본 글은 이 논문의 내용을 소개하고자 한다

1. Intro

블록체인이 왜 필요한지 이야기하기 전, 잠시 논문의 저자들이 일하던 Bell Labs에 대해 알아보자. 당시 Bell Labs는 AT&T 소속의 연구소로, 수없이 많은 혁신적인 기술을 개발해 내고 있었다. 다음은 Bell Labs가 개발해 낸 기술들이다. 트랜지스터, 레이저, 정보 이론(information theory), UNIX, C언어, 태양광판 등 수없이 많은 기술들이 Bell Labs에서 태어났다. 당연히 그 기술들에 대한 특허권 또한 Bell Labs가 취득했는데, 문제는 기술을 최초로 개발한 시점을 증명하는 데 있었다.

bell labs의 모습

1991년의 시대상을 고려해 보자, 당시에는 아직 디지털 방식의 정보처리가 지금처럼 대중화되지 않았고, 직접 손글씨로 매일 연구 일지를 남긴 것을 증거로 자신이 기술을 개발한 시점을 증명하였다.

매일 한 페이지씩 채워가며 연구 일지를 남기다 보면, 페이지를 중간에 찢거나 채워 넣었을 때, 티가 나기 때문에 위조나 변조를 찾아내는 것이 어렵지 않다. 그러나 디지털로 남긴 연구 일지의 경우에는 얘기가 다르다. 디지털 연구 일지의 경우, 언제든 내용을 바꿔 자신이 실제 개발한 것보다 이른 시간에 개발한 것처럼 꾸밀 수 있었다.

디지털 자료가 위변조 되지 않았음을 증명할 수 있는 방법이 있을까? 블록체인은 이 질문에 대한 해답에서 시작한다.

2. 솔루션의 개요

디지털 자료를 타임 스탬핑 하기 위해서는 몇 가지 세팅이 필요하다.
우선, 유저들(clients)의 분산 네트워크가 존재하며, 각 클라이언트는 고유 식별 번호를 지니고 있다.

솔루션은 세 파트로 나뉘는데, 각각 클라이언트가 타임스탬프를 요청했을 때 타임 스탬핑(time-stamping)이 즉각적으로 실행되는 파트, 타임스탬프 절차가 제대로 실행됐음을 검증(verify) 하는 파트, 그리고 서드 파티의 타임스탬프 절차의 타당성(validity)에 대한 공격을 방어하는 파트이다.

솔루션이 좋은 솔루션이라고 함은, 유저의 계산 능력, 문제의 복잡도, 유저의 신뢰도 등에 대한 합리적인 가정하에 가짜 타임스탬프를 생산하는 것이 매우 어렵거나 불가능에 가까움을 의미한다.

3. 디지털 보증함

제대로 된 설루션을 살펴보기 전, 나이브 한 설루션을 먼저 살펴보도록 하자. “디지털 보증함” 설루션은 다음과 같이 작동한다.

클라이언트가 타임스탬프를 원하는 자료가 있을 시, time-stamping service(TSS)에 자료를 전송한다. TSS는 자료를 받은 시점을 기록하고(time-stamping) 자료의 사본을 저장한다. 클라이언트의 자료의 진위성이 의심받게 되면 TSS에 있는 사본과 비교하여 진위성을 판별한다.

이러한 솔루션도 타임 스탬핑에 필요한 필수적인 요소들은 갖추고 있지만 4가지 문제점을 안고 있다.

Privacy: TSS로 전송하는 도중 데이터 스니핑이나 스푸핑 등의 위험이 있다. 따라서 클라이언트는 자신이 소유한 데이터의 노출에 대한 걱정뿐 아니라, TSS가 소유한 데이터 사본에 대한 노출도 걱정해야 한다.

Bandwidth and Storage: 데이터 사본 전체를 저장해야 하기 때문에, TSS가 저장해야 하는 데이터의 양이 어마어마하다.

Incompetence: TSS가 데이터를 검증하거나, 타임 스탬핑을 했음을 클라이언트가 확인할 방법이 존재하지 않는다.

Trust: TSS가 클라이언트와 합작하여 고의로 잘못된 시간을 타임 스탬핑 할 위험을 배제할 수 없다.

4.신뢰할 수 있는 TSS

TSS를 신뢰할 수 있다는 가정하에 위의 솔루션에서 발전을 시킬 수 있다.

4.1 Hash

첫 번째 발전은 해쉬 함수를 사용하는 것이다. 해쉬 함수는 임의 길이의 비트 스트링을 l 길이의 비트 스트링에 압축하는 함수 집합족으로, 다음과 같은 두 가지 특징을 갖는다.

  1. 함수 h는 간단하게 계산할 수 있으며, 집합족의 원소를 랜덤으로 고르는 것이 어렵지 않다.
  2. h가 주어졌을 때, h(x)=h(x’)인 x’을 찾는 것이 불가능하다.

TSS에 디지털 자료 x를 보내는 대신 h(x)=y를 보내 타임 스탬핑을 한다고 해도, 이는 x를 타임 스탬핑 하는 것과 같은 효과를 가진다(one way function이기 때문). 이는 저장 공간 문제와 프라이버시 문제를 해결한다.

4.2 전자 서명

두 번째 발전은 디지털 서명을 사용하는 것이다. J.Rompel의 “One-way functions are necessary and sufficient for secure signatures”에서 one-way function을 이용할 시 안정적인 전자 서명 시스템을 개발할 수 있음이 증명되었기 때문에 해쉬 함수를 이용한 전자 서명 시스템의 보안성은 입증된다.

안정적인 서명 시스템이 적용된 TSS는, 해쉬 값을 받을 시, 시간을 기록한 후, 자료에 서명을 하여 클라이언트에게 certificate을 다시 발송한다. 이 서명을 확인하여 클라이언트는 TSS가 제대로 작동했음을 확인할 수 있다. 이는 상기한 incompetence 문제를 해결한다.

5. 두 가지 현실적인 솔루션

해쉬함수와 전자 서명만으로는 TSS가 가짜 타임스탬프를 발행하는 것을 막을 수 없다. TSS가 항상 정당한 타임스탬프만을 발행하도록 하기 위해서는 상호 간의 신뢰가 최소한인 상황에서도 타임스탬프가 정당하게 발행되도록 하는 시스템이 필요하다.

5.1 Linking

클라이언트가 요청하는 타임스탬프와 그들이 제출하는 해쉬값을 미리 알 수 있는 방법은 없다. 따라서 이전 요청에서 받은 비트들을 TSS가 반환하는 certificate에 포함해 준다면 타임 스탬핑의 시점이 해당 비트의 요청 이후에 이루어졌음을 증명할 수 있다.

이런 식으로 이전 요청에서 받은 비트를 certificate에 포함하여 요청의 순서를 증명하는 것이다.

5.2 Distributed Trust

Distributed Trust 모델이 작동하기 위해서는 각 유저가 서명을 할 수 있고, pseudorandom generator G가 모두에게 접근 가능하도록 하는 안정적인 전자 서명 시스템이 선행되어야 한다. Pseudorandom generator 란, 입력으로 받는 seed를 string으로 늘려주며, string으로부터 seed를 유추하는 것은 불가능하다.

Distributed Trust 모델의 작동 방식은 다음과 같다.

  1. 클라이언트 Alice가 해쉬값 y를 seed로 하여 pseudorandom generator를 이용하여 다음과 같은 값을 생성한다

G(y)=(ID1,ID2,….,IDk)

여기에서 ID는 각 클라이언트들의 식별 번호이다.

2. Alice는 (y,ID)의 request를 각 식별 번호의 클라이언트들에게 발송한다.

3. Alice의 요청을 받은 각 클라이언트들은 시간과 y,ID가 포함된 전자 서명이 된 메시지 s를 Alice에게 발송한다.

4. Alice의 time stamp는 다음과 같이 구성된다. [(y,ID),(s1,s2,…,sk)]

Distributed Trust model의 작동 방법

저자는 Linking의 경우 중앙화된 솔루션이라고 말하며 Distributed Trust의 경우 탈 중앙화된 솔루션이라고 한다. 그러나 추후 나오는 비트코인의 경우 알 수 있듯, 이 두 가지 솔루션을 합칠 수 있으며 Linking을 탈중앙화 할 수 있다.

6. 고려할 부분들

6.1 Tradeoffs

저자는 두 가지 모델들이 각각 tradeoff가 있다고 밝히면서 다음과 같은 단점들을 밝힌다. Distributed Trust 모델의 경우 request와 동시에 바로 모든 프로세스가 시작된다는 장점이 있지만 클라이언트들이 각각 빠른 시간 내에 전자 서명을 할 수 있어야 한다는 기술적인 요구사항이 있다. Linking의 경우 request와 프로세스의 시작 사이의 짧은 딜레이가 있으며 정확한 시간을 기록하는 것이 아닌 자료 간의 시간 순서만을 기록할 뿐이기 때문에 요청이 많아 각 자료 간의 시간 순서를 통해 대강의 시간을 유추할 수 있을 때에만 의미가 있다.

6.2 Time constraints

두 솔루션 모두 append only이기 때문에 과거의 시간에 대한 time stamping 조작은 불가능하다. 즉, back-dated 되지 않았음은 증명할 수 있다. 그러나, 실제 자료가 생성된 시간 이후에 time-stamping을 요청하여 이후에 시간을 기록하는 방식으로 기록되는 시간을 실제 자료의 생성보다 늦게 하는 것은 막을 수 없다.

이를 방지하기 위한 방법으로는 자료의 생성과 동시에 타임스탬프가 찍히게 하여 양방향으로 기록이 유의미하도록 할 수 있다.

7. 결론

현대의 블록체인이 작동하는 방식과는 다른 부분들이 분명 있지만, 이 논문에서 제시한 시스템이 분명 블록체인의 기틀을 잡았음을 확인할 수 있다. 그러나 이 논문에서 제시한 수준에서 머물렀다면 블록체인 기술은 지금의 효용을 지니지 못했을 것이다. 우선, Distributed Trust 모델의 경우 비잔틴 장군의 문제를 고려하지 못했다. 그렇기 때문에 일정 수 이상의 클라이언트들이 동조하여 가짜 time-stamp를 반송할 경우 이를 바로잡을 방법이 존재하지 않는다. 또한, 동시에 request를 넣은 클라이언트가 둘 이상 있을 경우 처리할 방법이 제시되지 않는다. 이 두 가지 문제에 대한 솔루션은 추후 비트코인이 제시하게 된다.

완벽한 시스템을 제시하지는 못했지만 이 논문은 분명히 주목할 점들이 있다. 가장 주목할 점은 탈 중앙성이 필수적인 요소가 아니었다는 것이라고 생각한다. 분명 탈중앙성을 통해 기록된 시간에 대한 신뢰를 높힐 수는 있지만 탈 중앙성을 배제한 Linking이라는 솔루션을 통해서도 신뢰할 수 있는 time-stamp를 생성할 수 있다고 논문은 주장하고 있다.

비트코인을 최초의 블록체인으로 본다면 블록체인에서 탈 중앙성을 빼는 것이 어색하게 느껴질 수 있다. 필자도 처음 블록체인을 접했을 때, 블록체인에 대한 설명은 탈 중앙화된 임의 수정이 불가능한 분산 원장이라는 것이 가장 대중적이었다. 그러나 블록체인이 해결하고자 하는 문제가 디지털 자료가 위변조 되지 않았음을 증명할 수 있는 방법이 있을까?라는 것을 다시 생각해 보자. 위변조가 불가능하고 그 과정을 증명하는 데 있어 신뢰성이 보장된다면 탈 중앙성은 필수적이지 않다.

최근 나오는 니어, 솔라나와 같은 체인들이 탈 중앙성을 일부 포기하는 것을 보며 탈 중앙성을 포기한 블록체인은 가치가 없다는 듯 이야기하는 글들을 가끔 볼 수 있는데, 블록체인이 어디에서 시작했는지, 왜 만들어졌는지를 다시 한번 짚어본다면 최근의 트렌드를 이해하는 데에도 도움이 될 것이라고 생각한다.

--

--