[ICO] IOST 분석글 - Scalability

[ICO] IOST 분석글 - Scalability

1. Token Information

토큰 정보

ERC20, 메인 넷 출시 이후 1:1 교환 예정
토큰 이름IOS
토큰 발행량210억개
토큰 가격현재 0.00005336 ETH
홈페이지https://iost.io/
백서

https://github.com/iost-official/Documents

2. IOST에 대한 간략한 소개

블록체인의 근간을 이루는 기술은 아직 많은 수의 사용자들이 참여하기에는 한계가 있습니다. Scalability(사이즈 확장)에서 고질적인 문제를 안고 있는 것입니다. 많은 양의 거래를 빠른 시간내에 처리하는 기술적인 진보 없이, 페이스북이나 아마존과 같은 대형 서비스들을 블록체인 상에 적용하기는 불가능에 가깝습니다.

IOST Scalability에서의 확장성과 높은 거래 처리량을 보장합니다. Sharding(추후 설명이 있습니다.)과 합의 매커니즘을 통해 초당 100,000건의 거래를 처리할 수 있습니다. 이는 비트코인이 초당 7건, 이더리움이 초당 25건을 처리하는 것과는 질적으로 다른 성능입니다.


3. IOST가 해결하고자 하는 문제

기존 블록체인 기술들은 사이즈 확장을 하기엔 두가지의 기술적 제약을 안고 있습니다. 블록체인 네트워크에 참여하기 위해서 모든 노드는 거래 내역 전부를 저장해야 한다는 점과, 모든 거래를 검증하는 절차에 참여해야만 한다는 것입니다. 모든 참여 노드들이 똑같은 절차를 진행하기 때문에, 전체 시스템이 처리 가능한 거래량은 하나의 노드가 처리할 수 있는 거래량을 넘어서기 어렵습니다. 아울러 블록체인 사이즈가 커짐에 따라 네트워크 대역폭, 컴퓨팅 파워, 저장 공간에 대한 부담이 커집니다. 채굴 비용이 늘어날수록 블록체인에 참여하는 것은 소수만을 위한 특권이 될 가능성이 있으며, 이는 다시 중앙 집중화의 문제를 낳을 것입니다. 

IOST 플랫폼은 유저들에게는 온라인 서비스와 디지털 상품을 거래하기 위해 필요한 완전히 탈중앙화 된 방법을 제공합니다. 개발자들에게는 많은 수의 유저를 감당할 수 있는 dApp을 시장에 내 놓을 수 있도록 돕습니다. 이를 위해 Sharding이라는 기술을 사용합니다. 샤딩은 분산화 시스템에서 자주 사용하는 기술인데요, 전체 IOS 네트워크를 여러 개의 작은 공간인 shard들로 나누는 것입니다. 각각의 shard는 해당 shard의 합의 프로토콜로 작동되는 작은 네트워크라고 생각하시면 됩니다. 같은 거래들을 전체 네트워크가 검증하는 것이 아닌, 여러 개의 그룹이 전체 거래 중 일부를 각각 도맡아서 동시에 처리하는 메커니즘입니다. 이 때문에 유저의 수가 폭증하더라도 전체 시스템의 거래 처리량은 획기적으로 늘어납니다.


4. IOST의 Architecture

샤딩 기술을 곧바로 적용하기전에, 문제가 될 법한 다음의 사항들을 먼저 고려해야 합니다.

• 하나의 시스템을 어떤 방법으로 여러 개의 샤드들로 나눌 것인지

• 각각의 샤드들에서 어떻게 합의를 이끌어 낼 것인지

• 샤드와 샤드간 거래는 어떻게 수행할 것인지


해당 문제들을 해결하는 IOST의 요소들을 하나씩 순차적으로 설명해드리도록 하겠습니다.

1) Distributed Randomness Protocol

하나의 네트워크를 여러 개의 Shard들로 문제없이 나누려면 각각의 노드들에게 random한 배정이 이루어져야 합니다. 그래야 악의적인 노드들이 있다고 하더라도 여러 군데에 분산시킬 수 있어 네트워크에 대한 공격력을 약화시킬 수 있습니다.

각 노드에게 shard를 배정해주고 각 shard의 리더를 선출하는(리더가 필요한 이유는 추후에 설명해드리겠습니다.) random 생성 알고리즘은 여러 개가 있습니다. 그중 IOST에 가장 잘 맞는 알고리즘인 Distributed Randomness Protocol (DRP)는 다음의 조건들을 만족합니다.

 

1. 악의적인 노드들의 숫자가 임계점 아래일 때 시스템은 정상적으로 작동해야 합니다.

2. 완성된 최종 random number는 일부 숫자에 쏠린 것이 아닌 고르게 분포해야만 하며, 조작 불가능해야 합니다.

3. 악의적인 노드는 자신에게 유리한 random number를 얻기 위한 시도를 여러 번 할 수 없어야 합니다.

4. 참여 노드들은 결과값이 위 1,2,3의 절차를 거치고 생성된 것인지 검증할 수 있어야 합니다.

 

2) Efficient Distributed Sharding 

Distributed randomness protocol (DRP)을 사용하면 고르게 sharding을 하는 것 자체는 어렵지 않습니다. 하지만 이 프로토콜은 악의적 노드가 없다는 전제 하에 제대로 작동합니다. 따라서, 악의적 노드들의 공격에 대비하여 백업 프로토콜에 대한 설계도 필요합니다. 이것이 앞서 말씀드렸던 리더를 선출하는 이유인데요, 리더 선출 알고리즘에 대해 설명드리겠습니다.


[Algorithm - Leader Election with Back-up Protocol]

1. 하나의 블록이 생성되는 한 텀마다 각각의 검증 노드는 자신의 private key를 바탕으로 lottery를 만듭니다. Lottery는 랜덤으로 만들어낸 숫자라고 생각하시면 되겠습니다.

2. 서로 동기화를 진행하는 시간동안, 검증 노드들은 이 lottery들을 서로에게 뿌립니다. 각각의 검증 노드는 가장 낮은 값이 나온 3개의 lottery를 뽑습니다.

3. 동기화를 진행하는 시간이 끝나면, 검증 노드들은 가장 낮은 값이 나온 lottery를 확정합니다.

4. 가장 낮은 값의 복권에 해당하는 검증 노드는 리더로 선출됩니다. 두번째, 세번째로 낮은 값의 복권에 해당되는 검증 노드는 백업 리더로 배정됩니다.

5. 리더로 선출된 검증 노드가 성공적으로 DRP를 수행한다면, 다른 모든 검증 노드들에게 그 결과값을 퍼트립니다.

6. 각각의 검증 노드는 전달받은 DRP 결과값으로 전체 node들을 m개로 나눕니다. 이것이 Sharding이 되는 것이지요.

7. 동기화를 진행하는 시간이 끝난 후, 선출된 리더가 DRP를 제대로 수행하지 못하면검증 노드들은 현재 텀을 실패했다고 표시하고 리더를 해당 텀에서 방출합니다. 이 경우, 아까 뽑아두었던 백업 리더가 DRP를 수행합니다. 두 백업 리더 마저도 실패한다면, 롤백을 진행하여 step 1으로 되돌아가 다시 전체 과정을 처음부터 진행합니다.

 

각각의 검증 노드는 한 텀당 하나의 lottery밖에 만들지 못합니다. Private key가 외부에 유출되지 않는다면 어떤 lottery값이 나올지 알 수도 없습니다. 악의적인 노드들이 lottery를 얻어서 리더가 된다고 하더라도, 어떤 작당도 할 수가 없습니다. 할 수 있는 선택은 DRP protocol에 협조하거나, 실패하여 해당 텀을 포기하는 것뿐이기 때문입니다. DRP를 악의적으로 조작하려고 했다면 해당 노드들은 그 텀에서 배제됩니다.

 

3) Operability During Epoch Transitions

IOS dynamical rolling scheme을 사용합니다. 하나의 블록을 생성하는 텀마다 각 shard에 속한 일부 노드들을 서로 맞바꾸는 것을 말합니다. 악의적인 노드가 한 shard에 모이지 못하도록 주기적으로 멤버를 교체하여 청소를 해주는 것이라고 생각하시면 되겠습니다. 이 절차가 진행되는 동안에는 네트워크가 잠시 휴식기간을 가지고, 거래가 완전히 검증된 이후에 다시 동작합니다. Shard들의 노드들을 서로 맞바꾸는 동안 IOST가 최대한의 성능을 보장하도록 하기 위해 새롭게 참여한 멤버들과 기존 노드들을 맞바꾸는 매커니즘을 고안하였습니다. 검증 작업을 하는 남아있는 노드들은 계속 서비스를 제공하도록 하면서, 새롭게 참여한 노드들은 그동안의 거래 내역을 다운로드 받고 참여할 준비를 합니다.

여기서 가장 중요한 것은맞바뀌는 노드들의 개수(batch size)’입니다. 시스템의 안전성과 직결된 문제이기 때문이지요. 맞바뀌는 노드들의 개수가 커지면 남아있는 정직한 노드들의 숫자가 부족해져 올바른 합의에 도달하지 못할 위험이 커집니다. 뿐만 아니라 맞바꾸는 작업을 진행할 때마다 네트워크의 부담도 커집니다. 이 때문에 IOST에서는 악의적인 노드들이 전체 노드들 중 최대 3분의 1에 해당된다고 가정합니다. (필자도 정확히 어떠한 과정을 통해서 3분의 1이라는 숫자가 도출된 것인지는 알지 못하겠습니다.)

이 방법을 통해 Byzantine Fault Tolerance (BFT) 합의를 보장할 수 있습니다. (BFT는 분산 환경에서 비정상 노드가 있더라도 정상 작동하도록 하는 매커니즘이라고 보시면 됩니다.) 맞바뀌는 그룹의 사이즈를 정했두었으므로 최소 3분의 2 검증 노드들은 올바르게 합의를 진행하기 때문입니다

 

4) Inter-Shard Transactions

샤드들 간 거래 역시 샤딩 메커니즘에서 아주 중요한 문제입니다. Byzantine Shard Atomic Commit (Atomix) 프로토콜은 샤드 간 거래에서 이중 지불의 문제를 해결합니다.

1. Shard A에서 거래를 만들고 다른 모든 노드들이 그 거래를 검증하게 합니다.

2. Shard A에서 모든 노드들에 의해 거래가 검증되면, 거래는 A의 블록체인 상에 남습니다. 거래를 요청한 노드는 계좌를 잠근 후, 거래 내용을 Shard B 로 전송합니다.

3. A의 블록체인은 거래를 B의 블록체인으로 전송합니다.

4. 거래가 B의 모든 노드들에 의해 승인되면, 해당 금액은 B로 전송됩니다.


5) Consensus Mechanism

합의 매커니즘을 이루는 요소들에 대해 살펴보도록 하겠습니다.


[Tokens and Motivations]

IOS 토큰은 다음 3개의 역할을 수행합니다.

 지불

• 수수료: 스마트 계약, 거래 등을 검증을 수행한 노드에게 수수료를 지불합니다. 이 수수료는 검증 작업을 수행한 노드들에게 보상을 제공하고 악의적인 노드들이 일부러 스마트 계약을 여러 번 수행해 시스템에 해를 가하지 못하도록 합니다.

• 신뢰 점수: IOS 토큰은 유저의 신뢰 점수(believability score)를 계산하는데 중요한 역할을 합니다. (추후에 자세히 설명하겠습니다.)

 

PoS는 토큰을 얼마나 보유했는지에 따라 검증을 할 수 있는지 없는지를 판가름하기 때문에, 다시금 중앙 집중화 될 우려가 있습니다. 이런 현상을 방지하기 위해 커뮤니티에 대한 유저의 기여도를 측정하고 멤버들이 지속적으로 공헌하도록 이끄는 시스템인 Servi를 고안했습니다. 이는 다음의 3가지 특징을 가집니다.

 

• 거래 불가능: Servi는 교환이나 거래가 불가능합니다.

 일회성 : 하나의 블록을 검증한 후에, 검증한 노드가 가지고 있는 Servi 계좌는 자동적으로 비워집니다. 이렇게 함으로써 높은 신뢰 점수를 가진 노드들이 서로 번갈아 가면서 블록을 검증할 수 있도록 합니다. 검증 절차가 중앙 집중화 되지 않는 것입니다.

• 스스로 발급 : Servi는 커뮤니티에 기여하면 자동적으로 다시 채워집니다.

 

[Proof of Believability]

기존의 블록체인 시스템은 보안과 거래 처리량 사이에서 shard의 크기에 따른 trade-off 관계를 보였습니다. 여러 개의 작은 샤드를 가지는 시스템에서는 거래 처리 성능은 우수하나 악의적인 노드에는 상대적으로 취약합니다. 적은 수의 큰 샤드를 가지는 경우에는 그 반대의 trade-off 관계를 보입니다.  trade-off 관계를 깨면서 보안과 처리량, 양 쪽에서 우수한 성능을 보장하기 위해 Proof-of-Believability (PoB) 합의 프로토콜을 고안하였습니다.

Proof-of-Believability 합의 프로토콜은 believable-first approach, 즉 "믿을 만한 사람에게 먼저 접근하는 방법"을 통해 하나의 샤드를 두개의 그룹, 믿을 수 있는 그룹과 일반 그룹으로 나눕니다. 믿을 수 있는 그룹의 검증자들이 거래를 제일 먼저 처리합니다. 그 다음에 일반 그룹의 검증자들이 샘플로 일부 거래를 추출하여 검증하고, 최종적으로 해당 거래를 승인합니다. 믿을 수 있는 그룹으로 선출되려면 신뢰 점수가 높아야 하는데요, 신뢰 점수는 토큰의 양, 커뮤니티에 대한 기여도, 유저들의 리뷰 등을 통해 종합적으로 매겨집니다. 믿을만한 그룹은 다시 더 작은 그룹을 만듭니다. 그룹 당 한 명의 검증 노드를 선출하는 것입니다. 거래는 이 검증 노드들에게 무작위로 주어지는데요, 때문에 아주 낮은 latency로 블록들을 검증합니다.

하나의 노드만이 검증을 수행하면 보안 문제가 다시금 생길 수 있습니다. 때문에 샘플링을 할 확률 p를 정하여 이 확률에 따라 일반 그룹의 검증자들이 거래를 샘플링하고 검증 절차를 진행합니다. 이전에 믿을 만한 그룹에서 선출된 검증자가 악의적이거나 불성실한 검증을 수행했다는 것이 적발되면, 모든 토큰과 평판을 잃습니다. believable-first approach, 믿을 만한 사람들에게 우선적으로 빠른 검증을 맡기고 이후에 추가적으로 검증을 수행하는 매커니즘을 통해 거래 처리 속도를 비약적으로 빠르게 하고 검증 노드들이 다른 악의적인 행동을 하지 못하도록 합니다.


5. 의견

1) 테스트 넷(프로토타입)이 6월에 배포 되었습니다. 백서에 기술 아키텍쳐에 대한 설명이 부실하거나 아직 코드 레벨에서 구현되지 않은 ICO들이 많은데, IOST는 그런 면에서 탄탄한 행보를 보이고 있습니다. 

2) 7월 3일에 국내 거래소 코인제스트에 상장하였습니다.

Leave a Comment

    0 Comments