1_Do you “Really” need a Blockchain?

당신은 블록체인이 정말 필요한가요?

시리즈 연재 시작

과연 블록체인이라는 분야가 많은 일반 소비자들에게 큰 호응을 받지 못하고, 신뢰를 주지 못하는 그 원인은 무엇일까? 블록체인 프로젝트의 낮은 성공률 , 블록체인 사업 종사자의 도덕적 해이, 그리고 일반 대중들의 블록체인에 대한 낮은 이해도가 가장 큰 이유라고 생각한다.

블록체인 씬에 입문한지 6개월이 넘어가는 이 시점에서 필자도 내가 왜 블록체인을 공부하는지, 어떻게 하면 잘 활용할 수 있고 가치 확산을 할 수 있을지에 대해서 고민을 하고 있었다.

그래서 나 자신에게도 해답을 주고 씬에 있는 많은 사람들과도 의견을 나눌 수 있음과 동시에 씬에 갓 입문한 사람들이 읽으면 좋을 만한 그리고 고민하면 좋을 만한 주제를 10개를 가지고 있는 논문 및 아티클 선정해서 그에 대한 분석하는 글을 시리즈 형식으로 연재 하려고 한다.

0 — Abstract

블록체인 코어 ,dapp 기획 및 개발을 진행하다보면 다양한 종류의 난관에 부딪히게 된다. 그 중 많은 입문자들 그리고 개발자들이 곤욕을 치루는 질문은 바로 “why blockchain, 블록체인이 정말 그 곳에 필요한가 이다.” 이 질문에 대한 적절한 답을 제시하지 못하면 그 프로젝트는 블록체인을 굳이 쓸 필요가 없는 프로젝트인 것이다.

혹자는 비즈니스 분야에서는 더 이상 why blockchain 이라는 질문은 던지지 않는다고 한다. 실제 BM 이 작동하는지 그것이 파괴력 있게 작동할 것인지에 대해 더 집중한다고 한다.

하지만 특정 프로젝트에서 블록체인이 아닌 다른 기술을 사용하는 것이 훨씬 더 효과적인데, 블록체인을 왜 사용하는가 라는 질문에 대한 답을 명확하게 제시하지 못한다면, 그 당위성은 현저하게 떨어질 것이다.

그래서 첫번째 주제는 Do you “Really” need a blockchain? 로 선정했다. 제목부터 메세지를 던지는 이 글에서는 크게 5가지에 대해서 논의해보려고 한다.

  1. 블록체인에서 사용되는 용어에 대한 간단한 설명
  2. 용어들과 조건에 따른 블록체인의 종류 구분
  3. 시스템에서 중시 여겨지는 6가지의 요소들을 제시
  4. 조건에 따라 구별된 각 시스템에서 요소들이 어떻게 활용되고 어떤 의미를 가지고 있는지 설명
  5. 6요소와 5가지 질문을 통해서 정말 블록체인이 필요한가, 필요하면 어떤 종류의 블록체인을 사용해야하는가에 대한 해답을 플로우 차트로써 제시

본 글에서 제시된 방법론은 어디까지나 제안사항일 뿐, 정답은 아니다.

1 — Introduction

비트코인 및 이더리움과 같은 permissionless blockchain 에 참여하는 주체들은 상호 미신뢰관계(mutually mistrusting)를 유지하면서 TTP (trusted third party) 즉, 중앙화 된 제 3의 세력에 의지하지 않는다. 이러한 특성들 때문에 블록체인은 많은 주목을 받았다. 또한 IoT, 금융거래, SCM 등 다양한 분야로의 진출에도 가능성을 보여왔다.

이러한 permissionless blockchain 과는 다르게 permissioned blockchain 도 존재한다. 이러한 블록체인 시스템에는 오직, 허가된(permissioned) 주체만이 정보를 읽고 쓸 수 있는 권한이 주어진다.

그러나 permissioned blockchain에는 과연 현재 사용되고 있는 중앙화된 데이터베이스 시스템과 어떤 점이 다르고 더 뛰어난가라는 근본적인 질문을 던질 수 있을 것이다.

본 글에서는 시스템에서 제공하는 주요 요소들에 대해서 설명하고 시스템을 permissioned, permissionless blockchain 그리고 centrally managed database 로 나누어서 각 시스템에서 요소가 어떻게 작용하는지와 각 시스템의 특징에 대해서 구분하고 설명하려고 한다.

2 — Background on blockchain

블록은 자료를 저장하는 자료구조이고, 블록체인은 그 블록들을 연결해 놓은 체인이자 분산원장 형태의 데이터 베이스이다.

블록에는 다양한 종류의 정보가 들어 있다. 보통 블록은 블록의 헤더와 바디로 이루어져 있다.

보통 블록의 바디에는 여러가지의 트랜잭션들이 들어 있고, 블록 헤더는 해당 블록의 메타 데이터를 포함하고 있다.

블록의 구조는 다음과 같이 되어 있다.

<그림 — 1>

그림 — 1 에서 볼 수 있는 것과 같이 블록의 헤더에는 주로 블록 헤더 해쉬, 버전, 머클루트, 이전 블록 헤더 해쉬, 타임스탬프, 논스 값 등이 들어 있고, 블록의 바디에는 주로 거래 정보들이 있다.

블록 해쉬 (블록 헤더 해쉬)는 블록 헤더의 각 정보가 모여서 만들어지는 해쉬 값이고 머클해쉬는 바디에 있는 거래 내역들의 모든 정보를 모아 놓은 해쉬 값이다. 즉, 블록 헤더의 정보 중 하나라도 변하게 된다면, 블록 헤더 해쉬가 변하게 된다. 이런 상황이 오면, 블록체인에 문제가 생기게 되는 것이다. 또, 블록체인이 유지가 되는 이유이기도 하다. 정확히 해쉬 값이 어떻게 생성되는지 그리고 블록체인이 유지되는 이유를 확률적으로 계산하는 내용은 시리즈의 다음 글에서 소개될 것이다.

이번에는 블록체인의 구조를 살펴보도록 하겠다. 블록 체인의 구조는 다음과 같이 되어 있다.

<그림 — 2>
<그림 — 3>

그림 — 2 에서 볼 수 있는 것과 같이 이전 블록에 대한 정보(Previous Hash)로 블록들은 독립적으로 존재하지 않고 하나의 체인으로서 존재하게 된다. 만약에, 특정 부분이 임의로 변하게 된다면 그에 따라 블록 헤더 해시가 변하게 된다. 이런 상황에서는, 결국 그림 — 3 처럼 블록들의 체인이 깨지게 되는 것이다.

블록의 헤더 해시가 완성되는 과정 및 정보의 무결성이 지켜지는 것을 확률로서 증명하는 내용은 시리즈의 다음 글에서 더 정확하게 설명 될 것이다.

본격적으로 주제에 들어가기 전에 글에서 지속적으로 사용될 단어인 writer 와 reader 의 의미부터 한번 명확하게 짚고 넘어갈 필요가 있을 것 같다.

writer는 데이터베이스에 state(상태)를 작성하는 모든 주체를 의미한다. 블록체인에서 writer(POW) 는 consensus protocol 에 직접적인 참여를 하고 블록체인 확장(성장)에 도움을 주는 주체이다. 블록에 거래 내역을 담고 채굴을 하여 체인에 연결하는 주체이다. writer 는 POW 에서는 Miner, POS 에서는 Validator 라고 불리운다.

Writer는 블록체인에 정보를 기록하는 사람 (Miner)

reader 는 블록체인 확장(extending)에는 역할을 맡고 있지 않지만, 거래 생성 프로세스에 참여만 하거나 단순히 정보를 읽는 주체를 의미한다.

Reader는 블록체인의 정보를 읽는 사람 (거래 참여자 or 단순 internet user)

비트코인을 예로 들면 writer 는 채굴자 , reader 는 단순 사용자를 의미한다고 보면 된다.(regulator 와 software maintainer 는 이 글의 범위에서 벗어나기에 언급하지 않겠다.)

그렇다면 이제부터는 blockchain 을 종류에 따라 구분해보도록 하겠다.

3 — Types of Blockchain

블록체인이라고 모두 다 같은 블록체인은 아니다. 설립자 혹은 설립 집단이 추구하는 목표와 담으려는 그 특징에 따라 블록체인은 조금씩 다른 형태로 구현된다. 그리고 그 형태에 따라 구분되어진다.

필자도 그렇고 독자들 역시, 추후에 특정 아이디어를 가지고 블록체인 프로젝트를 시작하고 싶을 때 어떤 형태의 블록체인이 본인의 아이디어에 어울리는지에 대한 선택을 잘 하는 것이 중요하다.

블록체인을 분류하자면 다양한 기준에 따라 분류될 수 있지만, 가장 많이 쓰이는 것은 Permissioned & Permissionless 그리고 Public & Private 이다. 이 구분이 어떤 기준에 의해서 나누어지는지에 대해서 정확히 알아보겠다.

Permissionless & Permissioned Blockchain

먼저, permissionless blockchains, permissioned blockchains 으로 나눌 수 있을 것이다. permissionless 의 예시로는 비트코인, 이더리움이 있고 permissioned 의 예시로는 R3 corda 와 Hyperledger Fabric가 있다.

그렇다면 permissioned & permissionless blockchain 기준이 무엇일까?

permissionless 한 블록체인은 모든 peer가 언제든 reader 나 writer로서 허가 없이 (permissionless) 네트워크에 참여하고 떠날 수 있는(join & leave) 블록체인이다. 그리고 체인에 등록된 모든 정보를 누구나 읽을 수 있다.

permissioned 한 블록체인에서는 오직 허가받은 제한된 reader 와 writer 만이 정보를 읽고 쓸 수 있다.

Reader , Writer 둘 중 하나라도 허가없이 될 수 없다면 그것은 Permissioned 라고 구분된다.

즉, permissioned , permissionless blockchain 의 가장 큰 차이점은 누구나 reader 그리고 writer 가 될 수 있는가이다. permissionless blockchain 에는 누가 reader 그리고 writer 될 지를 결정하는 중앙화된 주체가 없는 것이고 permissioned 에는 권한을 부여하는 주체가 있다.
(peer 들을 관리하는 주체 및 규칙의 존재 여부)

permissionless 는 누구나 reader, writer 로서 생태계에 참여할 수 있다는 장점이 있는 반면, 동시에 시스템의 안정성과 보안성을 갖추기 위해 거래 내역에 대한 유효성을 작업 증명 방식으로 보증한다. 즉, permissioned 시스템에 비해서 finality의 속도가 늦어진다는 단점이 있다.

<표 — 1>

Public & Private Blockchain

이번엔 permissioned , permissionelss blockchain 만큼 많이 쓰이는 public & private blockchain 을 구분하는 기준에 대해서 알아보겠다.

permissionless, permissioned 블록체인을 구분하는 기준은 reader 그리고 writer 가 될 권리를 결정하는 주체 혹은 그룹의 존재여부였다. public , private 블록체인을 구분하는 기준은 조금 다르다.

public 블록체인과 permissionless 블록체인의 종류 그리고 private 블록체인과 permissioned 블록체인의 종류가 상당 부분 겹쳐서 사실상 public 과 permissionless blockchain 이 거의 동의어로 사용되고 있다. 하지만 그 차이는 분명히 존재한다.

public 과 private blockchain의 구분 기준은 reader 가 될 수 있는 권리가 모든 사람들에게 주어 지느냐의 여부이다. reader 의 권리가 주어지지 않는 자에게는 당연히 write 할 권리 역시 주어지지 않는다.

public 과 private 이라는 단어에서 보면 알 수 있듯이, blockchain 의 정보가 public 하느냐 private 하느냐에 따라서 구분이 된다. public 하다면 누구나(관계자 및 참가자가 아니더라도) blockchain 의 정보를 읽을 수 있는 것이고 private 하다면, 모든 사람이 blockchain의 정보를 읽을 수 있는 것은 아니다.

즉, public & private blockchain 의 차이를 한문장으로 정리하자면, 특정 blockchain 의 이해 관계자가 아닌 일반인도 blockchain 의 정보를 읽을 수 있느냐 이다.

Public Permissionless / Public Permissioned Blockchain

Public Permissionless Blockchain 은 누구나 blockchain 의 정보를 읽을 수 있고, reader 혹은 writer 가 되는데 있어서 특정 주체 혹은 그룹의 허가 혹은 규칙을 만족 시킬 필요가 없는 블록체인이다.

그리고 그 대표적인 예시로는 Bitcoin 등이 있다.

Public Permissioned Blockchain 은 EOS 가 대표적 일 것이다. EOS(혹자는 EOS는 블록체인이 아니다 라고 하기도 하지만, 여기서는 그렇게 깊이 들어가지는 않겠다)는 21개의 BP 집단이 있다. BP 의 역할은 블록을 만들어서 블록체인을 형성시키는 것이다. 즉, 오직 그들만이 Writer 가 될 수 있는 것이다. 하지만, 누구나 EOS 의 블록구조 및 내부의 내용은 들여다 볼 수 있다. 전형적인, 특정 주체들만 Writer 가 될 수 있고 그런 권한을 부여하는 주체가 존재하는 Public Permissioned Blockchain 인 것이다.

<표 — 2>

표- 2에서 볼 수 있듯이 EOS, Bitcoin 모두 Public 블록체인 이기에 모두가 Reader 가 될 수 있지만, EOS 는 Permissioned 이기 때문에 Writer 는 오직 21개의 BP 만이 될 수 있다. 그리고 그 BP 는 투표를 통해서 선출된다. (Writer가 될 수 있는 상위 21개를 선정하기 위해 투표하는 집단이 존재) 하지만, Bitcoin 은 Public 이면서 Permissionless 한 블록체인 이기에 누구나 Reader 그리고 Writer 가 될 수 있다.

Permissionless & Permissioned / Public & Private Blockchain

앞서 언급하였듯이, public permissioned 는 누구나 reader 는 될 수 있지만, writer 가 될 권리는 특정 주체에게만 주어지는 체인을 의미한다. private permissioned 블록체인은 reader 될 권리도 모두에게 주어지지 않고 writer 도 reader 가 된 특정 주체 안에서도 조건을 맞춘 자들만 될 수 있는 체인을 의미한다.

그렇다면, 모순처럼 보일 수 있겠지만 private permissionless blockchain 은 어떠한 모습일까?

private 하지만, 즉 체인과 관련된 이해관계자들만 reader 가 될 수 있고 모든 reader 가 writer 될 수 있는 형태의 blockchain 이다. 비유를 해보자면, 단체 톡방이라고 볼 수 있을 것 같다. 그 톡방에 있지 않은 사람들은 그 내용을 볼 수 없지만, 그 톡방에 초대가 된 모두는 읽을 수 있고 채팅을 할 수 있는 것이다.

public, private, permissionless, permissioned 블록체인을 표로써 정리해보면 표-3같다.

<표-3>

표 — 3은 일반인이 reader, writer 가 특정체인에서 될 수 있는가에 따른 분류를 해 놓은 것이다.

그리고 위의 4가지 blockchain 종류에서 내가 모두 reader 와 writer 가 될 수 있느냐는 2가지 질문으로 정리 될 수 있을 것이다.

특정 chain 의 이해 관계자입니까? , 
Writer 가 되기 위한 특정 조건을 만족 하였습니까?

Public — Permissionless 에서는 2가지 질문 모두 아니오 라고 답해도 reader, writer 가 될 수 있다.

Public — Permissioned 에서는 특정 이해관계자가 아니어도 Reader 가 될 수 있고 Writer 가 되기 위해서는 특정 조건을 만족 하였습니까 라는 질문에 예라고 대답할 수 있어야 가능하다.

Private — Permissionless 에서는 특정 chain 의 이해 관계자이어야만 reader 로 될 수 있고 reader 가 된 상태에서는 특정 조건을 만족하지 않아도 writer 가 될 수 있다.

Private — Permissioned 에서는 특정의 chain 의 이해관계자이어야만 reader 가 될 수 있고, reader 가 되었더라도 특정 조건까지 만족해야만 writer 가 될 수 있는 것이다.

Permissionless & Permissioned Blockchain & Central Database

<표 — 4_1>
<표 — 4_2>

표 — 4_1에 permissionless, permissioned blockchain 그리고 central database 이 각 특성에서 어떤 성능을 보이는지 분리해놓았고 표 — 4_2에는 각 특성들의 정의에 대해서 정리해놓았다.

centralized system 에서는 latency 와 throughput 이 전반적으로 blockchain system 보다는 나은 편이다. (블록체인 시스템은 그들의 합의 알고리즘에 그 복잡성이 더해지기 때문임).

예를 들어, 비트코인은 현재 오직 매초 대략 7개의 거래를 유지해 낼 수 있다. 중앙화된 비자는 15,000 개 이상의 거래를 1초에 처리할 수 있다. 탈중앙의 정도와 throughput 에는 tradeoff 가 존재한다. (how well a system scales to a large number of writers without mutual trust, and throughput, how many state updates a system can handle in a given amount of time) 그래서 블록체인을 사용할지 말지, 어떤 종류의 블록체인을 사용할 지 의사결정을 내릴 때, 이 tradeoff 역시 고려 대상 중 하나로 넣어야 한다.

6 Properties of System

이제부터는 시스템이 제공하는 6개의 요소에 대해서 각각의 정의를 설명하고 시스템별로 그 요소들이 어떻게 적용되는지 비교해보려고 한다.

A. properties

public verifiability(공개 검증) :

공개검증은 시스템의 상태가 올바른지(correctness of the state) 누구든 판단 가능한가에 대한 요인이다. 분산원장 시스템에서는 verifier 에 의해 시스템의 상태가 확인 된다. 모든 관찰자가 원장이 프로토콜에 의해 정확하게 바뀌었는지 확인할 수 있고 결국 모든 사람이 같은 원장을 보게 된다.

중앙화된 시스템에서는 사람에 따라서 다른 상태(state)를 보이게 할 수 있다. 그렇기에 모든 상태 변환이 적절하게 이루어지고 있는지에 대한 판단을 할 수가 없다. 중앙화된 권력을 믿어야만 하기 때문이다.

transparency(투명성) :

public verifiability 를 위해서는 데이터의 투명성은 필수이다. 그러나 observer 에게 보이는 투명한 정보의 양은 다를 수 있고 모든 참여자들이 정보의 접근 권한을 가질 필요는 없다.

privacy(프라이버시) :

privacy 역시 모든 시스템에서 중요한 요인 중 하나이다. 그런데, privacy 와 transparency은 상호 반비례 관계에 있다. 프라이버시 요인에 집중하게 되면 투명성을 놓치게 되고 투명성에 집중하게 되면 프라이버시를 놓치게 된다. 그렇기에, 중앙화된 시스템에서는 privacy 를 가지기 쉽다. transparency 와 public verifiability 를 가질 필요가 없기 때문이다.

integrity(무결성) :

정보의 integrity 는 검증되지 않은 집단이 정보를 변경시키는것으로부터 안전한가 이다. 정보의 integrity 역시 public verifiability 와 긴밀한 관계가 있다. 시스템이 public verifiability를 제공하면 데이터의 integrity 를 보장할 수 있다.

시스템에서 데이터의 공개 검증을 제공한다면, 시스템의 참여자 모두가 시스템의 상태를 확인할 수 있게 된다. 즉, 검증되지 않은 집단이 특정 정보를 임의대로 변경한다면 시스템의 상태를 지켜본 모든 참여자가 알게될 것이기에 함부로 변경을 할 수 없게 된다. 자연스럽게 정보의 무결성 역시 지킬 수 있게 된다. 중앙화된 시스템에서도 시스템이 손상되지만 않았다면 무결성을 제공할 수 있다.

redundancy(중복성)

redundancy 즉, 데이터의 중복성 역시 많은 사례들에서 중요한 요인으로 꼽힌다.

블록체인에서는 redundancy 는 선천적으로 제공된다. 분산원장을 기본으로 하고 있기에, peer 들간 같은 원장을 공유 즉, writer(full node) 간 replication 을 통해서 이루어진다.

중앙화된 시스템에서도 데이터의 중복성은 보장된다. 물리적으로 다른 서버간 replication 과 백업을 통해서 이루어진다.

/** 사실 redundancy 는 학문별로 다른 의미를 가지고 있다. 신뢰성 공학에서는 시스템의 일부가 오작동을 일으켜도 전체 시스템에는 영향이 가지 않는 긍정적인 의미를 가지고 있으나 행정학에서는 가외성이라고 불리운다. 가외성은 조직의 비효율의 원인이고 정리의 대상으로 여겨지고 있었다. 최근에는, 오히려 전체적으로 조직의 신뢰도와 안정성을 높여주는 순기능을 한다는 의견도 있다. **/

trust anchor(대표자)

Trust anchor 는 시스템에서 누가 가장 높은 권위를 가지고 있느냐를 의미한다. 즉, peer 중 누가 reader 혹은 writer 가 될 지 결정하는 권위를 누가 가지고 있는가이다.

permissioned blockchain 에서는 특정 세력을 지칭하는 것이고 permissionless 에서는 존재하지 않는 요인이라고 볼 수 있다.

B. Tensions between transparency and privacy

Transparency 와 privacy 이 둘 사이에는 내재된 tradeoff 가 있다. 완벽하게 투명한 시스템은 프라이버시를 제공할 수 없고 완벽하게 프라이버시한 시스템은 투명성을 제공하지 않는다.

하지만, cryptographic 한 방법을 이용한다면, privacy 와 transparency 를 동시에 충족시킬 수 있다. 물론 가격적인 측면에서 효율성이 낮기는 하지만, public system 에서도 완벽에 가까운 privacy를 제공하는 블록체인 프로젝트 중 대표적인 것은 바로 ZeroCash 이다.

‘영지식 증명’이라는 방법을 사용하여 privacy 를 제공한다. 영지식 증명은 추후에 다시 설명하겠지만, 여기서 간단히만 설명하고 가자면, 특정 사실을 증명하는데 있어서 prover(증명하려는 자) 의 정보가 전혀 유출되지 않은 상태에서 verifier(검증하는 자) 에게 인정받을 수 있는 방법을 의미한다.

4 — Where does a blockchain make sense?

<표 — 5 ; 인용 : Do you need a blockchain?>

그래서 블록체인은 언제 필요하고 효과적일까?

블록체인 프로젝트를 구상하는 모든 사람이 정확하게 여기에 블록체인이 사용될 만한지, 혹은 어떤 종류의 블록체인이 어울리는지에 대해서 판단하기 쉽지 않다. 그래서 본 글(논문에서 인용 : Do you need a blockchain?)에서는 독자들에게 플로우 차트(< 표— 5>)를 제공하여 의사결정을 도와준다.

public 블록체인은 모든 이가 블록체인의 정보를 볼 수 있다 (모두 reader가 될 수 있다.) 그리고 규칙여부에 따라 permissioned 혹은 permissionless 가 될 수 있다. 모두 reader 가 될 수 있다는 것은 대중이 이 블록체인의 정보를 보고 감시할 수 있다는 것이다.

그리고 규칙이 없어 permissionless 한 형태라면 누구나 writer 가 될 수 있는것이다. 누구나 writer 가 될 수 있다는 것은 동시에 그 writer 집단에 대한 낮은 신뢰도와 정보를 의미한다.

반대로 내가 설계하고자 하는 블록체인 시스템에서 writer 의 정보를 모든 사람이 알 필요없다면 혹은 그것을 추구한다면 public permissionless blockchain 을 선택하면 된다.

하지만, 누구나 reader 가 될 수는 있지만, 속도와 효율성 등의 이유로 일정한 풀의 writer 만 허가한다면 public permissioned blockchain 을 선택하면 된다.

그런데 여기서 blockchain 의 정보가 공개적 검증(public verifiability)을 필요로 하지 않는다면 즉, 일반 대중에게는 공개할 의무 혹은 필요가 없게 된다면 public 이 아닌 private blockchain 이 되는 것이다.

Public blockchain 은 누구나 reader 가 될 수 있는 블록체인이자 공개 검증이 보장된다. 그렇다면, Public blockchain 은 언제 쓰일까? 보통 public blockchain은 다수의 주체가 상호 비신뢰적인 관계이지만 서로 interact 하고 시스템의 state 를 change 하고 싶으나 online trusted third party 에게 의존하고 싶지는 않을 때만 사용된다.

이제부터 질문을 한가지씩 던져보려고 한다.

i) 데이터 저장을 해야하는가?

만약 데이터가 저장될 필요가 없다면 데이터베이스가 필요없을 것이고 그렇다면 블록체인은 필요하지 않다.

ii) Writer 의 숫자가 몇인가?

Writer 의 숫자에 따라서도 블록체인의 필요성 여부가 결정된다. 만약 오직, 1명 혹은 1개 주체의 Writer 만 필요로 한다면, 오히려 기존의 중앙화된 시스템이 더 효율적이기에 블록체인이 필요하지 않다.

iii) TTP (Trusted Third Party)

TTP 를 도입하려고 한다면 2가지 상황이 있을 것이다. TTP 가 항상 online 인가 아니면 주로 offline인가 이다.

iii — 1) TTP가 항상 online 인 경우인가?

TTP 가 항상 online 이라면 write operation 은 그 주체에게 전가될 수 있고 동시에, state transition 을 검증하는 verifier 로써 작동할 수 있다. 믿을 만한 주체가 항상 online 이고 write operation 을 수행할 수 있기에, 블록체인은 이 상황에서는 필요하지 않다.

iii — 2) TTP가 offline 인 경우인가?

TTP 가 주로 offline 인 경우이라면 특정 중앙화된 주체가 writer 가 될 수 없는 상황이다. 즉, 다수의 writer 가 블록을 생성하고 블록체인을 형성하는 상황이다. 본격적으로, blockchain 의 필요성이 대두되는 단계인 것이다.

iv) Writer 의 정보 공개 및 상호관계

writer 의 정보를 모두 알고 있는 상황 그렇지 않은 상황과 또, writer 간의 관계에 따라서 요구되는 blockchain 의 형태는 각각 다르다.

iv — 1) Writer 가 모두 알려져 있는가?

모든 writer 의 정보가 알려져 있지 않다면, Public Permissionless Blockchain 이 적합할 것이다. Permissionless 이기에 누구나 Reader 그리고 Writer 가 될 수 있고 Public 이기에 Writer 의 범위는 이해관계자가 아닌 모든 Internet User 까지로 확장된다.

즉, 모든 Writer 의 정보를 알리지 않아도 되는 혹은 알려지지 않은 경우에는 누구나 블록을 형성할 수 있고 블록체인의 정보를 읽을 수 있는 Public Permissionless Blockchain 이 가장 적합한 해답이 될 것이다.

iv — 2) 모든 Writer 를 신뢰할 수 있는가?

그러나 만약 모든 writer 의 정보를 다 아는 상황이라면, 즉, 일정 풀의 writer 만 존재하고 그 존재를 시스템의 참여자 모두가 아는 형태라면 Permissioned Blockchain 이 적합할 것이다.

모든 writer 들의 정보가 다 알려져 있고 그들 서로가 상호신뢰 관계에 있다면 (그 어느 writer도 악의를 가지고 있지 않음) 블록체인 대신, shared write access 를 가진 데이터 베이스가 가장 좋은 솔루션일 것이다.

그러나 만약 writer 간의 관계가 상호신뢰 관계가 아니라면(어느 writer 가 악의를 가지고 있을지도 모르는 상황이라면), permissioned blockchain 이 가장 좋은 솔루션일 것이다.

v) 공개 검증이 필요한가?

permissioned blockchain 에서도 public verifiability 가 제공되어야 한다면 누구나 reading 할 수 있는 public permissioned blockchain 그렇지 않다면, 특정 이해관계자들만 reading 할 수 있는 private permissioned blockchain 이 어울릴 것이다.

5 — Conclusion

이번 글에서는 블록 및 Blockchain 의 간단한 정의부터 Public / Private / Permissioned / Permissionless 로 그 종류를 나누어 보았고 시스템에서 제공하는 6요소로 Permissioned / Permissionless / Central Database 의 각각의 특징에 대해서 논의해 보았다.

특히, Public / Permissionless Blockchain , Private / Permissioned Blockchain 간의 미묘한 차이에 대해서 알아보았고 정의 내려 보았다.

또한, 설계하려는 시스템의 특징상 blockchain 이 필요한가, 또 어떤 종류의 블록체인이 필요한가에 대한 해답을 5가지 질문으로 구성된 플로우 차트로써 제시해 보았다.

블록체인에 대한 개괄적인 정보와 프로젝트의 조건에 따라서 요구되는 블록체인의 종류를 제시함으로써, 블록체인 씬에 입문하려는 초심자와 프로젝트를 구성하고 있는 집단 그리고 진행 중인 집단에게 도움이 될 것으로 사료된다.

Reference

[1] Karl Wust , Arthur Gervais , Do you need a Blockchain? , 2017.

[2] Satoshi Nakamoto , Bitcoin : A peer-to-peer electronic cash system , 2009.

[3] Joseph Poon and Thaddeus Dryja , The bitcoin lightning network: Scalable off-chain instant payments, 2015.

[4] Eli Ben Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza , Zerocash: Decentralized anonymous payments from bitcoin , 2014.

[5] Vitalik Buterin , Virgil Griffith , Casper the Friendly Finality Gadget , 2017.

[6]https://medium.com/datadriveninvestor/do-i-really-need-blockchain-4-important-factors-to-consider-57b06e4ffbb6

[7]https://devopedia.org/types-of-blockchains#Wagenaarm-2018

[8]https://medium.com/@lkolisko/in-depth-on-differences-between-public-private-and-permissioned-blockchains-aff762f0ca24

[9]https://medium.com/@pavelkravchenko/ok-i-need-a-blockchain-but-which-one-ca75c1e2100

[10]https://www.coindesk.com/information/what-is-the-difference-between-open-and-permissioned-blockchains

[11]https://medium.com/datadriveninvestor/do-i-really-need-blockchain-4-important-factors-to-consider-57b06e4ffbb6