blockchain

사토시 나카모토의 Bitcoin 논문

이번 포스트에서는 현대의 블록체인 기술의 근간이 된 사토시 나카모토의 bitcoin 논문을 설명하고, 블록체인의 핵심 개념에 대해 적어보고자 합니다.

우리가 흔하게 오프라인상에서의 금전을 거래할때와는 다르게 인터넷상에서의 거래에는 기술적으로 해결할 수 없는 문제가 존재하는데 그것은 바로 특정 거래가 두번 일어나게 되어 존재하지 않던 재화가 전산상에 생겨나게 되는 것입니다. 이것이 어떻게 가능하냐고 할 수 있지만, 인터넷에서의 거래란 사실 데이터베이스라는 정보의 창고에 새로운 기록을 작성하고 있던 수치를 줄이거나 올리는 단순한 작업이기 때문에 전산상의 오류나 혹은 해커의 공격에 의해 내가 하지 않은 거래가 두번 기록이 될 수 있게됩니다. 이러한 문제를 double spending problem 이라고 하며, 궁극적으로 사토시는 이 double spending problem 을 해결하기 위한 연구를 시작합니다.

사토시는 이를 해결하기 위해 매 시간의 timestamp를 기반으로 하는 p2p네트워크를 기반으로 모든 거래 정보는 블록화 되어 체인 구조로 연결되고 동기화되는 일종의 온라인 체인 시스템을 고안하게 됩니다. 즉, 온라인 상에서 일어나는 모든 거래에 그 시간을 ms 단위의 정밀도로 기록을 한 뒤에 온라인 상에서 모든 사람들이 합의를 하여 각 거래의 신뢰성을 판단하고 그 거래기록을 한데 모아 블록으로 만들어 이어붙인다면 모두가 인정할 수 있는 분산 원장을 만들 수 있지 않을까 라는 생각을 하게 된 것입니다.

이렇게 체인을 연결해 가는 과정에는 많은 컴퓨팅 파워가 필요하게 되었고, 가장 많은 CPU 파워를 가진 컴퓨터 집단이 가장 긴 체인을 생성할 수 있을 것이며 이를 신회하는 네트워크 구조가 바로 블록체인 네트워크 입니다.

즉, 사토시 나카모토가 제안한 bitcoin의 궁극적이고 본질적인 목표는 제 3 기관의 개입 없이 화폐를 주고 받는 것이었습니다.

블록체인 내에서의 거래 기록

비트코인에에서 거래는 UTXO(Unspent Transaction Output) state model 에 따라 기록됩니다. 이는 이름 그대로 하나의 거래 내역에서 사용되지 않은 양을 통해서 자금의 상태를 기록함을 의미합니다.

즉, 비트코인에서 Transaction 이란 사용되고 남은 Bitcoint 의 양을 가지는 일종의 화폐 자체로 이해할 수 있습니다. 가령 5BTC 짜리 Transaction, 1BTC 짜리 트랜잭션처럼 각 Transaction 은 누군가에게 소유된 화폐로 이해할 수 있고, 그 화폐가 이미 소진되었다면 해당 화폐를 소진한 주체가 output 에 기록되고 아직 소진되지 않았다면 그 화폐를 소진할 수 있는 사용자의 주소가 명시되어 있다고 보면 됩니다.

다음은 실제 비트코인에서 Transaction Model 의 일부입니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
class CTransaction
{
public:
const std::vector<CTxIn> vin;
const std::vector<CTxOut> vout;

...

private:
const uint256 hash;

...
}

위에서 알 수 있듯이 비트코인에서 하나의 Transaction 에는 Vin 과 Vout 이라는 값이 존재하며, 각 model 의 구조는 다음과 같습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class CTxIn
{
public:
COutPoint prevout;
CScript scriptSig;
}

class CTxOut
{
public:
CAmount nValue;
CScript scriptPubKey;
}

각 속성을 하나씩 살펴보면, 거래를 이루는 것은 CTxIn 과 CTxOut 두가지로 구성되고, CTxIn 에는 해당 Transaction 이 어떤 Transaction 의 몇번째 output 을 기준으로 거래가 시작되는지를 나타내며 COutPoint 는 실제로 특정 Transaction 의 hash 값과 output 의 index 값을 통해 생성된 값입니다. ScriptSig 는 해당 화폐를 사용한 사용자의 서명으로 어떤 사용자가 해당 화폐를 사용하였는지를 나타내며, 이는 이전 Transaction CTxOut 의 scriptPubKey 의 소유자가 서명한 서명입니다.

CTxOut 의 nValue 속성은 실제 BTC 의 양이 명시되며 1억 분의 1 BTC 인 Satoshi 를 기준화폐로 사용합니다. scriptPubKey 는 해당 화폐를 사용할 수 있는 사용자의 address 이며, 해당 사용자가 이 Transaction 에 서명하여 다음 Transaction 에 기록함으로써 화폐를 사용할 수 있습니다.

여기서 중요한 사실을 알 수 있는데, 그것은 바로 블록체인 내에서 거래(transaction) 는 이전 거래의 정보(이전 transaction’has value) 를 포함하기 때문에 모든 거래는 시간 순으로 동기화 될 수 있다는 것입니다.

이렇게 모든 거래의 내역들을 한데 모아 블록으로 저장하며, 특정 시간을 주기로 그 시간동안 일어난 모든 거래를 한데 모아 새롭게 블록을 생성하는 작업을 거치는데, 이는 각 거래를 일종의 트리 형태로 나열하고 이를 해쉬라고 불리는 암호화 과정을 거쳐 해시를 만들어 내는 것입니다. 그리고 새로운 블록을 생성함이란 이렇게 복잡하게 암호화된 해쉬값을 먼저 풀어낸 컴퓨터가 그 보상을 가지는 방식으로 기여를 하게 됩니다.

여기서 컴퓨터가 해쉬값을 풀어내는 것은 아주 단순하게 생각하면 무수히 많은 숫자와 문자열(nonce)을 계속해서 대입하면서 맞는 값이 나올때까지 대입해 보는 것이라 볼 수 있습니다.각 블록의 해쉬값을 먼저 풀어낸 노드가 새롭게 블록을 생성합니다.

이를 위해서는 엄청난 컴퓨팅 파워가 필요하며, 이를 통해 상대적으로 더 많은 컴퓨팅 파워를 가지는 믿을 수 있는 노드들의 컴퓨팅 파워를 통해 올바른 블록을 생성하게 됩니다.

네트워크의 동작

블록체인 네트워크는 다음과 같은 순서에 따라 이루어 집니다.

  1. 모든 transactions 는 모든 노드에 전파된다.
  2. 모든 노드는 각 트랜잭션을 모아서 블럭을 구성한다.
  3. 각 노드는 만든 블럭의 해시를 풀어낼 nonce 값을 찾기 위해 연산을 시작한다.
  4. 어떤 노드가 nonce를 찾아냈다면 다른 모든 노드에게 자신이 가진 블록을 전파한다.
  5. 블록을 받은 노드들은 받은 블록 안의 모든 트랜잭션들이 유효하고 이미 지불된 것이 아닐 때에만 블록을 받는다.
  6. 블록을 받은 노드들은 받은 블록의 해쉬값을 previous hash로 하는 새로운 블록은 만드는 것에 착수함으로써 다른 노드들에게 해당 블록을 승인하였음을 알린다.
  7. 만약 노드가 동시에 두개의 블록을 받는다면 처음 받은 블록을 기준으로 작업을 시작하지만 이후로 받은 블록들도 저장해 둔다. 이렇게 여러 블록들은 개별적인 브랜치를 형성하고 특정 브랜치가 길어지면 가장 긴 브랜치의 블록들을 승인하여 체인을 이어간다.

만약 노드가 다음 블록을 받지 못했다 하더라도 문제가 되지 않는데, 이는 그 다음 블록을 받게 되면 노드 자체가 자신이 받지 못한 블록을 인지하고 다른 노드들에게 이를 요청하기 때문이다. 또한 모든 트랜잭션들을 매우 많아서 빠트리면 트랜잭션이 있더라도 블록들은 계속 생성되기 때문에 빠트린 transaction들은 무시되고 넘어간다.

보상의 원리

블록체인 시스템의 참여자들을 컴퓨팅 파워를 통해 그 신뢰가 유지되는 시스템이므로, 모든 참여자들이 계속해서 컴퓨팅 파워를 제공하도록 동기 부여 하기 위해 인센티브를 부여하며, 이는 바로 블록을 생성한 노드에게 최초의 트랜잭션을 발행하도록 하는 것으로 이것이 우리가 일반적으로 알고있는 코인의 채굴하는 과정이 됩니다.

화폐가치의 분할

위 내용에서와 같이 우리는 모든 코인은 그 전의 소유자들의 정보를 가진다고 알아보았으며, 이는 현실 세계에서 특정 1달러 지폐에 이제까지의 소유자들이 적혀있는 것에 비유될 수 있다고 하였습니다. 하지만 좀 더 작은 단위 혹은 더 큰 단위의 돈을 송금하는 경우를 생각해 보면, 1달러 지폐 하나를 다른 누군가 혹은 수십명의 다른 사람들과 공유하는 것을 생각할 수 있습니다.

이것은 하나의 transaction이 여러 개의 input 및 output value를 가짐으로써 해결 될 수 있는데, 하나의 transaction은 다른 여러 사람들에게 지불될 수 있으며 모든 내용이 하나의 transaction에 작성되어 있도록 하는 것입니다. 쉽게 말하면 1달러 지폐를 현재 가지고 있는 사람이 복수 명이 되어도 괜찮다는 것으로 생각될 수 있습니다.

이번 포스트에서는 사토시 나카모토의 논물을 쉽게 요약하여 블록체인의 핵심 원리에 대해 알아보았습니다.

가상화폐 시장의 열기가 죽어가는 현 시점이지만, 블록체인의 효용과 사토시 나카모토가 만들고자 했던 새로운 화폐경제 시스템의 가치는 보존되었으면 하는 바람으로 글을 마칩니다.

LNH

두나무의 블록체인 개발 플랫폼, 루니버스

이번 포스트에서는 두나무의 블록체인 개발 플랫폼 루니버스에 대해 알아보고자 합니다.

루니버스란?

블록체인 기술에 대한 관심은 계속해서 증가하고 있지만, 블록체인의 특성상 메인넷을 구성하고 자체 코인을 발행하는 것은 상당한 기술력을 필요로 하고, 네트워크를 구축했다 하더라도 다른 블록체인 네트워크와 접점을 만들고 블록체인 플랫폼의 참여자를 만들어 나가는 것 또한 매우 어려운 일이기에, 국내에서 성공적으로 운영되고 있는 블록체인 서비스는 사실상 전무하다고 볼 수 있습니다.

두나무의 루니버스란 이처럼 개발의 진입장벽이 높은 블록체인 기술의 장벽을 낮추고 개발자라면 누구나 쉽게 Decentralized Application을 만들 수 있도록 하겠다는 목표로 블록체인 서비스 개발 플랫폼인 ‘루니버스’ 의 출시를 준비하고 있습니다.

루니버스는 마치 아마존의 클라우드 서버처럼 클릭 몇번으로 네트워크 상에 자체적인 블록체인 네트워크를 구축하도록 도와주며, 해당 블록체인 네트워크에 토큰을 발행하고 Dapp 을 올리는 등의 일련의 작업을 매우 쉽게 만들어주어 개발자들에게 인종의 블록체인 네트워크에 대한 쉽고 간편한 인터페이스를 제공해 줍니다.

루니버스 플랫폼을 통해서 개발자는 간편한 REST API를 통해 블록체인 상의 대부분의 기능을 수행할 수 있게 되기에 오직 비즈니스 로직에만 집중하여 블록체인 서비스를 만들 수 있는 환경을 제공받습니다. 즉, 루니버스를 이용하면 블록체인 개발에 대한 전문 지식이 없어도 쉽게 컨소시엄 블록체인 네트워크를 구축하고 토큰을 발행, 운영할 수 있습니다.

루니버스 체인

루니버스 체인은 파트너들 모여 분산화된 네트워크 구성합니다. 각 개발사들은 루니버스를 통해 간편하게 자신의 체인을 만들고 루니버스 체인 내의 다른 체인들에 쉽게 deploy 및 transaction 발행할 수 있습니다.

루니버스 체인을 이해하기 전에 3가지 종류의 체인에 대해 이해할 필요가 있으며, 루니버스 체인, 컨소시엄 블록체인, 프로턱트 체인이 바로 그것입니다.

먼저, 루니버스 체인은 전체 블록체인 네트워크를 포함하는 개념이며, 루니버스의 블록체인 위에서 여러 개발사들의 블록체인 네트워크가 운영되며, 여러 블록체인 사이의 인터페이스를 만들어 주어 여러 블록체인 네트워크 사이에서 통신이 가능하게 해줍니다.

다음은 컨소시엄 블록체인인데, 루니버스를 통해 블록체인을 개발하는 개발사들은 루니버스 체인 위에 자신만의 별도의 컨소시엄 블록체인을 구축할 수 있습니다. 루니버스 체인은 이러한 여러개의 컨소시엄 블록체인들을 이어주는 역할을 수행합니다.

마지막으로 프로덕트 체인 이 있는데, 이러한 프로덕트 체인 위에서 실제적인 Dapp 과 Token이 운영되게 됩니다. 각 개발사들은 자신들의 컨소시엄 블록체인 위에 다수의 프로덕트 체인을 구축하여 운영하거나 혹은 루니버스 체인 위에 바로 자신만의 프로덕트 체인을 구축하는 방식으로 서비스를 운영할 수 있습니다.

루니버스에서 프로덕트 체인은 아이콘과 협력하여 만들어지고 있으며, 12월에 정식으로 루니버스 체인의 메인넷이 가동될 예정입니다.

뿐만 아니라 루니버스 네트워크는 이더리움, 이오스 등 다른 대형 블록체인 네트워크 와의 인터페이스를 구축할 예정으로 루니버스 내의 블록체인을 다른 거대 메인넷과 손쉽게 연동할 수 있는 다리 역할을 해줄 것으로 기대됩니다.

종합하자면, 루니버스는 일종의 sass 로 볼 수 있으며, 블록체인 기술을 추상화 시켜 개발자들이 비즈니스 로직에만 집중하여 블록체인 서비스를 만들수 있게 해줍니다.

블록체인과 루니버스의 활용

현시점에서 블록체인 기술은 블록체인 인프라에 그 관심이 집중되었습니다. 이더리움, 이오스 등 계속해서 새로운 블록체인 메인넷들이 출시되었으며, 해당 메인넷 위에서 다양한 서비스가 운영되기 보다는 우수한 메인넷 자체를 개발하는 것에 전 세계의 관심이 집중되었습니다.

즉, 이제까지의 블록체인산업은 블록체인 인프라에 집중되었다고 볼 수 있습니다.

하지만, 과거 산업의 발전 행태를 볼 때 현 시점에서 가장 중요한 것은 바로 블록체인을 활용한 킬러앱의 출시가 블록체인 인프라의 발전방향을 결정짓는 다고 볼 수 있습니다. 가령 인터넷이 처음 나왔을때 인터넷 상의 전자 상거래 서비스 혹은 각종 게임의 발전이 인터넷 산업과 인프라의 발전을 가속화한 것처럼 블록체인 기술을 활용한 상용적인 서비스가 계속 생겨나야 블록체인 인프라도 그에 발맞추어 발전할 전망입니다.

블록체인에서의 게임 산업

루니버스는 블록체인의 여러 산업방면에서도 게임 산업 에 상당한 관심을 가지고 있습니다. 현재 블록체인 기반의 게임산업의 규모는 빠르게 성장하고 있으며, 크게 다음과 같은 3가지 활용처가 존재합니다.

게임의 블록체인화

  1. 인게임 재화 ⇒ fungible token
  2. 아이템 경재 ⇒ non fungible token
  3. 게임의 규칙 ⇒ smart contract

이미 블록체인 기반의 다양한 게임들을 성공리에 운영되고 있는데, 게임회사 뿐 아니라 게임 스트리밍, 게임 마켓 등 다양한 게임 관련 산업분야가 성장하고 있습니다.

블록체인 게임 사례

  • eos 기반의 한 방치형 rpg 게임
    인게임 상에서 재화를 획들할 수 있고 이를 게임 내에서 다시 소비하는 방식으로 토큰 이코노미가 만들어짐
  • 이더몬
    각 사이트를 10명의 유저가 호스트가 되어 공동 소유할 수 있고 일반 유저는 입장료를 내고 탐험하는 방식의 새로운 비즈니스 모델을 선보였으며, 입장료 중 90%는 호스트에게 돌아가고 나머지는 개발자에게 돌아가는 방식으로 운영
  • 게임 스킨
    사용자와 디자이너가 각종 게임 스킨을 만들고 이를 여러 게임에서 사용 가능 => 게임 스킨은 조단위 시장을 형성
  • 토너먼트 형 게임
    좋은 아이템을 구매해서 경기에서 승리하여 상금을 얻는다 => 게임을 통한 수익창출을 위한 기회 비용으로 아이템을 구매한다.

루니버스는 무엇을 해결하는가?

크립토 키티의 경우 메타마스크를 통해 로그인하면서 이탈되는 유저가 전체의 99%에 달할만큼 편리한 유저 인터페이스의 필요성이 대두되고 있습니다. 루니버스는 간편한 사용자 경험을 제공하여 손쉽게 블록체인 서비스를 이용할 수 있도록 할 것입니다.

또한, 기존의 메인넷에서 게임을 하기 위해 필요한 막대한 거래 비용을 게임산업 발전을 저해하고 있으며, 루니버스는 0에 가까운 트랜잭션 fee를 지향하여 서비스를 만들고 있으며, 거래 비용을 줄여 게임에 진입장벽을 낮추어 줍니다.

또 무엇을 제공하나요?

기업 운영

  1. 투자자 네트워크 연계
  2. 올비트 상장 패스트 트랙
  3. 글로벌 마케팅
  4. 공동 PR 진행 및 지원

편리한 개발 프로세스

루니버스 이전의 개발 프로세스에서는 프라이빗 체인 구축 및 디앱개발 및 웹3 작성 및 배포등 일련의 과정에 몇달의 기간이 소요되지만 루니버스를 통한 개발 프로세스에서는 30분 내에 체인을 만들고 토큰을 발행할 수 있습니다. 체인 생성 및 토큰을 버튼 몇번으로 생성하고, 이를 rest api 를 호출함으로써 편리하게 개발이 가능합니다.

개발 프로세스

  1. 메인 체인 만들고 메인 토큰 발행
  2. 프로덕 체인 구축
  3. 메인 토큰과 매칭 되는 프로덕 토큰 발행
  4. 트랜잭션 정의
  5. REST api 를 call 함으로써 서비스 구현

가상화폐 지갑

비트베리와 협업하여 안전하고 편리한 가상화폐 지갑을 제공합니다.

편리한 암호화폐 상장

Allbit Alliance Program ⇒ 루니버스를 이용하기 전의 플로우

  1. 토큰 경제 설계, 백서 검토
  2. 파운데이션 컨설팅
  3. 리갈 펀드 매칭

현재 암호화폐 거래소의 문제였던 과도한 리스팅 비용, 복잡한 절차, 리스팅 네트워킹, 리스팅 사후 관리(가격 방어, 거래량 확보) 를 해결해주고, 루니버스 이용하여 서비스를 개발하여 탈중앙화 거래소인 올비트와 협력하여 간편하게 리스팅이 가능합니다.

또한 올비트가 제공하는 머미넷, 비트 고수, cmt group, Dr. Node&mainblock 등을 통해 리스팅 후의 마케팅 까지 지원합니다.

[ Opensource Blockchain Engine, IT-CHAIN] 04. Authentication

Open Source Blockchain Engine인 It-chain 의 네번째 포스트입니다.

이번 포스트에서는 IT-CHAIN에서 블록의 인증과정에 대해 알아보겠습니다.

어떻게 노드들의 신분을 인증하는가?

모든 노드는 각자 고유의 private key와 public key를 발행하며 이는 it-chain의 자체 라이브러리인 heimdal을 통해 이루어 집니다. heimdal를 통해 키를 생성하면 private key 와 public key 두 쌍의 키가 생기게 되는데, 여기서 public key를 활용하여 각 노드들의 id를 만들어 노드들의 신분을 보장하며, 각 노드는 트랜잭션을 발행하는 시점에 해당 트랜잭션을 자신의 private key로 sign한 signature를 함께 동봉합니다.

트랜잭션의 Signing

트랜잭션을 발행할 때 TX와 함께 signatature를 동봉하게 되는데 이는 보내는 사람의 private key로 sign한 정보이다.

It-chain: https://github.com/it-chain/engine

Opensource Blockchain Engine It-chain 시리즈

LNH

[ Opensource Blockchain Engine, IT-CHAIN] 03. IVM Component

Open Source Blockchain Engine인 It-chain 의 세번째 포스트입니다.

이번 포스트에서는 IT-CHAIN에서 Smart Contract 의 배포와 실행을 담당하는 IVM COMPONENT에 대해 알아보겠습니다.

It-chain의 IVM Component

It-chain 에서는 icode라 불리는 smart contract을 배포할 수 있으며, It-chain 위에서 일어나는 Transaction 이 내포하는 의미는 바로 어떤 노드에서 어떤 smart contract의 어떤 함수를 실행시켰는가에 관한 정보이며 그 구조 중 일부는 다음과 같습니다.

1
2
3
4
5
{
icodeId: _icodeid,
type: invoke | query
function: _functionName
}

여기서 트랜잭션을 실행시킨다는 것은 해당하는 icode 에게 특정 요청을 전달하는 것입니다.

transaction의 종류에는 invoke와 query가 있는데, 여기서 invoke는 데이터를 쓰는 작업이고 query는 데이터를 읽는 작업이라고 볼 수 있습니다. 각 아이코드는 특정 함수에 대한 handler를 가지고 있으며 특정 함수를 실행하면 그에 매칭되는 핸들러가 동작하여 아이코드 내에서 일련의 작업이 일어나게 됩니다.

Icode 들은 어디에 저장되나요?

각 노드에서 배포된 Smart contract인 icode 들은 자신의 고유값을 기준으로 한 git repository에 자장되며, 어떤 노드에서 특정 icode를 실행하기 위해서는 git repository에서 해당 icode 를 받아와서 자신의 노드에 docker container를 구축하여 그 내부에서 icode를 실행시킵니다.

즉, 새로운 스마트 컨트랙이 생성되면 이는 특정 git repository 로 업로드되고 사용되기 전까지 해당 git repository에 저장되어 있습니다.

Docker Container 관리를 위한 Tesseract Library

블록체인 노드에서 여러개의 icode 가 하나의 노드에서 실행되어야 하며, 각 icode는 서로에게 독립적으로 작동하기 위해서 각 icode가 실행되는 환경을 가상화하여 독립시킬 필요성이 생기게 되었으며, 이를 해결하기 위해 it-chain 에서는 리눅스 컨테이너 기술인 Docker 를 사용하게 됩니다.

Docker 란 하나의 노드에서 여러개의 독립 실행 환경을 구성해 줄 수 있으며, 각 실행환경을 Container라는 단위로 부릅니다.

IVM에서 각 icode는 각각 저마다의 독립된 실행공간인 Container 를 가지며 it-chain에서는 각 컨테이너를 생성하고 관리하는 별도의 라이브러리인 Tesseract 라는 독자적인 라이브러리를 사용하고 있으며, Tesseract 라이브러리는 각 컨테이너의 DB에 데이터를 저장하고 출력하는 작업을 수행합니다.

Smart Contract 작성을 위한 SDK Library

Smart Contract 이란 사용자가 특정 함수나 요청을 전달하였을 때 항상 동일한 결과를 내놓는 일종의 블랙박스라고 볼 수 있습니다. icode는 docker위에서 동작하며 위의 invoke 등을 처리함에 있어 sdk의 함수들을 사용하는데 여기서 sdk는 ivm의 tesseract에게 grpc 통신을 통해 데이터를 쓰고 읽는 작업을 처리합니다.

Icode 는 언제 실행되나요?

먼저, icode 의 각 함수는 transaction을 만들어내고 이 tx는 리더에게 전달됩니다.

리더는 tx를 받아 블록을 만들고 해당 블록을 받아 내부에 있는 tx를 실행시킴으로서 실제 icode 가 실행이 됩니다.

현재 잇체인 팀은 계속해서 icode의 실행의 유효성을 보장하기 위한 다양한 시도들을 하고 있습니다.

가령, 현재 it-chain은 transaction 내의 임의 함수로 인해 각 노드에서 다른 결과가 나오는 등 노드 별로 같은 결과값을 가지고 공유하기 위한 연구와 시도등이 있으며, it-chain 팀은 이를 해결하기 위해 각 노드에서 생성된 블록의 transaction 들을 바로 실행시키고 반영하기 전에 미리 한번 각 transaction을 실행시킨 뒤 상대방이 실행시킨 결과값과 나의 결과값이 일치할 때에만 icode 를 실행시키는 등의 장치를 구현중에 있습니다.

스마트 컨트랙의 실행과 World State Database

실행된 스마트 컨트랙트는 각 노드의 상태를 변경시키고 변경된 상태들에 각 컨테이너가 접근할 수 있어야 하기에 공용으로 사용할 상태값 저장 공간이 필요하게 되었으며 이를 World State Database 라고 부릅니다.

it-chain에서 world state database 는 키밸류 DB 인 Level DB를 사용하여 구현되었습니다.

이번 포스트에서는 It-chain 내에서 Smart Contract을 배포 및 실행, 관리하는 IVM Component에 대해 알아보았습니다.

다음 포스트에서는 it-chain에서 노드의 인증을 담당하는 Authentication에 대해 알아보겠습니다.

It-chain: https://github.com/it-chain/engine

Opensource Blockchain Engine It-chain 시리즈

LNH

[ Opensource Blockchain Engine, IT-CHAIN] 02. Blockchain Component

Open Source Blockchain Engine인 It-chain 의 두번째 포스트입니다.

이번 포스트에서는 IT-CHAIN에서 블록의 합의를 담당하는 Blockchain component에 대해 알아보겠습니다.

It-chain의 Blockchain Component

블록체인에서 일어나는 모든 거래는 Transaction이라고 불리며, 하나의 블록은 여러 Transaction들의 집합으로 구성됩니다.

때문에 블록체인에서는 생성된 블록이 올바른 블록인지 확인하고 체인에 추가하는 과정이 필요하며, 이 과정은 It-chain의 Blockchain Component에서 이루어 집니다.

또한, It-chain에서는 블록의 저장 및 조회를 위한 별도의 라이브러리를 구현하였으며, Blockchain Component는 yggdrasill에서 정의한 interface에 맞게 구조체를 구현한다면 yggdrasill에 block을 저장, 조회할 수 있습니다.

yggdraill에 연속적으로 저장된 block들을 우리는 blockchain이라고 부릅니다.

Block 의 상태

Blockchain Component에서 Block은 다음과 같은 상태로 존재합니다.

Block State Description
Created 합의되지 않았고, blockchain에 저장되지 않았다.
Staged 합의되었지만, blockchain에 저장되지 않았다.
Committed 합의되었고, blockchain에 저장되었다.

위에서 언급한 바와 같이 블록체인 네트워크를 구성하는 노드들은 계속해서 새로운 블록들을 합의하는 과정중에 있고 합의가 완료되며 오직 리더 노드 에서 블록을 생성하여 다른 노드들에게 전파하고 블록을 받은 노드는 자신이 생성한 블록과 비교하여 검증여부를 판단합니다.

즉, 각 노드에서 막 생성된 블록은 Created 상태에 있으며, 이 블록을 Consensus 알고리즘을 통해 합의를 이루고 합의가 완료되며 Staged 상태로 바뀌게 됩니다.

Staged 상태의 블록이 실제 yggdrasill 내의 데이터베이스에 저장된다면, 블록은 Commited 상태로 변경됩니다.

노드 사이에서 블록의 동기화

동기화(Synchronize)는 특정 노드의 블록 체인을 네트워크 내 임의의 노드의 블록 체인과 동일하게 만드는 과정을 의미합니다.

동기화(Synchronize) 과정의 목적은 모든 블록에 대하여 대표값(Seal), 이전 블록의 대표값(PrevSeal), 트랜잭션 모음(TxList), 트랜잭션 대표값(TxSeal), 블록 생성 시각(TimeStamp), 생성자(Creator), 블록 체인의 길이(Height) 등의 블록 체인과 관련된 모든 정보들을 다른 노드의 것과 같게 만드는 것에 있으며, 이를 통해 블록체인에 참여하는 모든 노드가 같은 블록의 모음을 가지게 될 수 있습니다.

동기화(Synchronize)는 다음과 같이 확인(Check), 구축(Construct), 재구축(PostConstruct) 의 과정을 거칩니다.

확인(Check)

특정 노드의 블록 체인이 동기화가 필요한 상태인지를 점검합니다. 이 과정은 임의의 노드에게 Blockchain 길이와 lastSeal을 받아와서 자신의 블록 체인 정보가 같은 지 비교하여, 동기화가 필요한 상태인지 점검하는 것으로, 이미 동기화가 완료된 상태라면, 동기화(Synchronize) 과정을 중단하고, 그렇지 않을 경우, 구축(Construct) 을 수행합니다.

구축(Construct)

구축에소는 임의의 노드에게 블록 정보를 요청하여, 응답받고, 응답받은 블록을 블록 체인에 저장하는 과정을 반복합니다.

블록 요청은 특정 노드의 블록 체인 길이(Height)를 활용해, 임의의 노드에 블록을 요청함으로써 수행되며, 특정 노드가 새로 참여하는 노드일 경우 임의의 노드의 블록 체인 내 최초 블록부터 마지막 블록까지 요청하고, 기존에 참여중이던 노드일 경우 보유 중인 블록 체인 내 마지막 블록의 다음 블록부터 임의의 노드의 블록 체인 내 마지막 블록까지 요청합니다.

임의의 노드의 모든 블록이 특정 노드의 블록체인에 저장되면 구축(Constrcut)이 완료됩니다.

특정 노드는 구축(Construct) 의 진행 중에 새롭게 합의되는 블록을 블록 임시 저장소(BlockPool)에 보관하며, 구축(Construct) 이 완료되고 나면, 블록 임시 저장소에 블록이 보관되어 있는 지 확인합니다. 보관중인 블록이 있다면, 재구축(PostConstruct)을 수행합니다.

재구축(PostConstruct)

이미 구축(Construct) 된 블록 체인에 블록 임시 저장소(BlockFool)에 보관중인 블록들을 부수적으로 추가하는 것을 의미하며, 재구축(PostConstrcut) 을 수행하고 나면, 동기화(Synchronize) 과정이 모두 완료됩니다.

이번 포스트에서는 It-chain 내에서 블록의 검증과 저장을 수행하는 Blockchain 컴포넌트에 대해 알아보았습니다.

다음 포스트에서는 it-chain에서 dApp을 발행하고 실행하는 ivm 컴포넌트에 대해 알아보겠습니다.

It-chain: https://github.com/it-chain/engine

Opensource Blockchain Engine It-chain 시리즈

LNH

[ Opensource Blockchain Engine, IT-CHAIN] 01. Peer To Peer Network

현재 블록체인 기술은 가장 빠르게 확산되고 있는 유망한 기술 중 하나이며, Bitcoin, Ethereum, EOS 등 수많은 외산 블록체인 엔진들이 입지를 굳혀가는 가운데 국내에서도 블록체인 코어 기술을 위한 많은 연구가 진행이 되고 있습니다.

이번 글에서는 수많은 블록체인 엔진들 중에서도 Lightweight Customizable Chain을 목표로 활발하게 개발이 진행중인 국내 오픈소스 블록체인 엔진인 IT-CHAIN에 대해 살펴보고자 합니다.

본 포스트는 연재 형식으로 IT-CHAIN의 핵심적인 component인 p2p, consensus, blockchain, authentication, txpool, iCode 를 다루는 총 4~6편의 포스트로 이루어 질 예정이며, 오늘은 it-chain의 전체적인 구조와 더불어 그 첫번째 component 인 p2p component에 대한 소개를 하고자 합니다.

What is it-chain?

많은 블록체인 엔진들 중에서 it-chain을 소개하게 된 계기는 무엇보다 구조적으로 매우 직관적이고 이해하기 쉽게 설계되어 있기 때문입니다. 가령, ethereum과 hyperledger처럼 당장 상용화를 목적으로 개발이 진행중인 엔진들은 실용적 문제들에 봉착하여 다양한 기법과 최신 기술을 도입하여 코드를 당장 이해하기 어려움이 있기에 블록체인을 처음 접하는 사람들의 경우 전체 코드를 한눈에 이해하는 것은 매우 어려운 일이 아닐 수 없습니다. 하지만, it-chain은 전체 설계 및 핵심적인 컴포넌트들이 비교적 상세하게 문서화가 되어 있고, 블록체인의 핵심이 되는 기본적인 기능만을 구현하였기 때문에, 블록체인 엔진이 움직이는 큰 그림을 보다 직관적이고 쉽게 이해할 수 있는 장점이 있습니다. 만약 블록체인 엔진 개발에 관심이 있는 엔지니어라면 그 시작으로 it-chain 의 구현을 살펴보는 것을 추천합니다. (it-chain의 github 주소, https://github.com/it-chain/engine)

it-chain이 지향하는 바는 블록체인을 개발하는 누구든지 쉽고 가볍게 커스터마이징이 가능한 엔진을 만드는 것 입니다. 만약 누군가가 ethereum의 코드를 가져다가 자신만의 블록체인 엔진을 만든다고 한다면 그것은 매우 어려운 일일 것 입니다. 합의 알고리즘 하나를 변경하더도 관련된 모든 코드에 대한 이해가 필요하며 얼기설기 얽혀있는 수많은 코드들을 재정리 해야 합니다. 하지만, it-chain 은 event-sourcing을 기반으로 모든 동작이 event를 기반으로 이루어 지기에 다른 구성요소들의 동작에 구애받지 않고 원하는 파트만 손쉽게 변형하여 자신만의 engine을 만들 수 있습니다.

it-chain의 전체 구조

it-chain은 6개의 독립적으로 동작하는 핵심 컴포넌트들로 구현되며, 각각은 AMQP(Asynchronous Message Queue Protocol) 를 통해 커뮤니케이션을 합니다. AMQP는 이벤트 버스로서 각 컴포넌트들에서 일어난 모든 일들은 이벤트 형태로 전파되어 다른 컴포넌트들이 해당 이벤트에 맞는 동작을 수행함으로써 전체 기능이 동작하는 방식입니다.

다음은 it-chain의 각 컴포넌트의 간단한 역할을 보여줍니다.

  • TxPool 컴포넌트: 트랜잭션을 임시로 저장하고 관리하는 컴포넌트로, 합의되어 블록에 저장되지 않은 트랜잭션들을 모아둡니다.
  • Consensus 컴포넌트: 합의를 담당하는 컴포넌트이며, 현재는 PBFT(Practical Byzantine Fault Tolerance) 알고리즘을 따릅니다.
  • BlockChain 컴포넌트: 블록을 생성하고 관리하는 컴포넌트입니다.
  • P2P 컴포넌트: 네트워크의 참여하는 Peer들을 찾고, 유지하는 컴포넌트입니다.
  • Auth 컴포넌트: 각종 인증을 담당합니다.
  • iCode 컴포넌트: it-chain의 스마트 컨트랙트인 iCode 관련 기능을 담당합니다.

It-chain의 Peer to Peer 네트워크

이번 포스트에서는 it-chain에서 여러 노드들 사이의 네트워크 정보를 동기화하고 커넥션을 관리하는 p2p component와 노드 사이의 합의를 이루는 consensus 컴포넌트에 대해 알아보고자 합니다.

먼저, P2p 컴포넌트가 하는 일은 다음과 같습니다.

  • 블록체인 네트워크 내의 다른 노드들의 존재를 인지하고 저장합니다.
  • 네트워크 내의 노드들 사이의 connection정보와 ip 주소 정보를 Peer 라는 이름으로 저장하고 여러 Peer 들의 집합인 PeerTable 을 형성합니다.
  • 모든 노드들이 네트워크 내의 모든 노드들에 대한 정보인 PeerTable 을 공유하고 동기화 합니다.

예를 들어 현재 블록체인 네트워크가 A, B, C 노드로 이루어져있다고 가정해 봅시다.

여기서 D라는 새로운 노드가 A라는 노드에게 접속을 요청을 하게 된다면 D 노드는 A 노드의 정보만을 알고 있게 될 것이며, 마찬가지로 B, C 노드도 D노드에 대한 정보를 알지 못할 것입니다.

하지만 private 블록체인에서는 모든 노드들이 계속해서 서로 통신을 위해 연결되어 있어야 하기 때문에 새롭게 연결된 노드의 정보를 다른 노드들에게 전파해 주어야 하며 각 노드들은 전체 네트워크에 대한 일관된 정보를 공유해야 합니다.

네트워크 정보는 어떻게 저장되나요?

p2p 컴포넌트 내의 연결 정보는 Peer 라는 이름으로 저장이 되며, 그 안에는 특정 노드와의 연결에 대한 고유값인 connectionId와 상대 노드의 ip 주소 를 저장합니다.

가령 A, B, C 노드로 구성된 네트워크가 있다면 A 노드는 B, C 노드와 연결됨에 따른 고유한 connection과 B, C 노드의 ip 주소를 Peer A, Peer B 라는 이름으로 저장하며 모든 노드는 이러한 peer들의 정보를 peer 들의 정보의 집합인 PeerTable 에 저장합니다.

네트워크 정보는 어떻게 공유되나요?

블록체인 네트워크에 새로운 노드가 접속하는 것은 네트워크 내의 특정 노드에게 연결을 요청하는 것에서 시작됩니다.

노드 A, B, C 로 구성된 네트워크에서 D라는 노드가 접속되는 상황을 가정해 봅시다.

노드 D는 A, B, C 노드 중 임의의 노드인 A 노드에게 연결을 요청하고 만약 연결이 이루어 진다면 노드 D의 정보는 노드 A의 PeerTable 에 저장되고, 노드 A 는 새롭게 바뀐 PeerTable 을 노드 D에게 전달해 줍니다.

노드 D는 A에게 받은 PeerTable을 살펴보고 아직 자신이 연결하지 않은 노드인 B와 C 노드에 대해 알게되고 해당 노드의 ip 주소로 연결을 요청하게 됩니다.

B, C 노드가 새로 접근한 노드인 D 노드에게 연결을 요청받고 승인하는 것으로 네트워크 내의 모든 노드는 새로 접근한 노드인 D 노드와 연결이 이루어지게 됩니다.

It-chain의 Consensus 컴포넌트

블록체인에서 핵심은 바로 consensus 입니다.

consensus 컴포넌트는 특정 블록을 생성하기 위해 다른 노드들에게 해당 블록을 생성해도 되는지 검증을 요구하고 네트워크 구성원들의 합의가 이루어지면 새로운 블록을 생성합니다.

It-chain 에서 이러한 합의 알고리즘은 설정을 통해 간편하게 교체할 수 있으며 기본적으로 pbft 알고리즘에 따라 합의가 이루어 지게 됩니다.

pbft 합의 알고리즘

consensus-PBFT

기본적인 PBFT 알고리즘은 다음과 같은 순서로 이루어지게 됩니다.

  1. 클라이언트가 네트워크 구성원에게 어떤 합의문에 대해 합의할 것을 요청합니다.
  2. 합의 요청을 받은 노드들 중 리더 노드는 네트워크 내의 모든 구성원에게 특정 합의에 대한 합의를 시작할 것을 알리는 preprepare message 를 전달합니다.
  3. preprepare message 를 전달받은 모든 노드는 다시 모든 노드에게 prepare message 를 전달합니다.
  4. 전체 네트워크 구성원들 중 정족수(2/3) 이상의 노드에게 받은 preparemessagecommit message 를 모든 노드들에게 전달합니다.
  5. 위 과정이 끝나면 모든 노드들은 정족수이상이 합의한 결과를 가지게 됩니다.

하지만 It-chain 에서는 오직 리더만이 새롭게 생성될 블록을 제안하고 실제로 생성할 수 있으므로 위 과정에서 클라이언트 및 요청 응답이 존재하지 않습니다.

It-chain에서 pbft 알고리즘의 구현

It-chain에서는 위와 같은 pfft 알고리즘 구현을 위해 다음과 같은 몇가지 개념을 도입합니다.

  • Parliament: 의회, 즉, 합의에 참여할 노드들의 집합을 의미합니다.
  • Representative: 대표자, 즉 합의에 참여할 실제 노드 구성원을 의미합니다.
  • Leader: 의장, 즉 의회 구성원의 대표인 리더를 의미합니다.

pbft의 목적은 어디까지나 합의하고자 하는 블록에 대한 합의이기에 다음과 같은 과정에 따라 pbft 기반의 합의 알고리즘이 동작됩니다.

  1. 리더 노드의 consensus 컴포넌트가 블록 생성을 담당하는 blockchain 컴포넌트로 부터 합의하고자 하는 블록을 제안받습니다.
  2. 리더 노드는 해당 블록에 대한 합의를 진행하기 위해 현재 네트워크를 구성하고 있는 정보를 담고 있는 PeerTable 에서 전부 혹은 부분적인 노드를 선출하여 Parliament 를 구성합니다.
  3. 리더 노드가 Parliament 에 속한 모든 Representative 들에게 preprepare message 를 전달합니다.
  4. preprepare message 를 받은 모든 representative 들은 받은 정보를 통해 각자의 Parliament 를 구축하고 다른 Representative 들에게 prepare message 를 전달합니다.
  5. Representative 들은 정족수 이상의 prepare 메세지를 받기 까지 받은 모든 prepare messageprepare message pool 에 저장하고 정족수 이상이 넘으면 commit message 를 전파합니다.
  6. 전체 의회 구성원의 1/3 이상에게 commit message를 받은 각 Representative 들은 Commit message 내의 Proposed Block 에 대한 승인을 하는 이벤트를 발생시키고 블록체인 컴포넌트는 해당 블록에 대한 검증을 시작합니다.
    Proposed Block 이 confirm 되기 까지 Commit message 들은 Commit message pool 에 저장됩니다.

It-chain에서 리더의 선출

it-chain 에서의 리더 선출은 RAFT 라는 알고리즘을 통해 진행되며 consensus 컴포넌트에 구현되어 있습니다.

다음은 RAFT 알고리즘의 간단한 프로세스입니다.

  1. 리더가 사라지면 노드는 의회를 구성합니다.
  2. 150ms ~ 300ms 사이의 랜덤 값으로 모든 노드가 타이머를 동작시킵니다.
  3. 노드의 타이머가 다 되면 그 노드는 자신의 상태를 Candidate 으로 바꾸고 RequestVoteProtocol을 통해 의회 내의 다른 노드에게 투표 요청 message 를 전달합니다.
  4. RequestVoteProtocol 로 메세지를 받은 노드는 아직 타이머가 다 되지 않은 경우 타이머를 리셋하고, 송신한 노드에게 VoteLeaderProtocol을 통해 메세지를 전달하여 리더로 투표합니다.
  5. 만약 상태가 CANDIDATE 인 노드가VoteLeaderProtocol를 통해 다른 모든 노드에게 투표 메세지를 받는다면 그 노드는 스스로 리더가 되고 다른 모든 노드들에게 리더가 됨을 선포합니다.

위와 같은 과정을 통해 물리적으로 떨어져 있는 여러 개의 노드들이 서로 합의를 이루고 리더를 선출 할 수 있게 됩니다.

이번 포스트에서는 국내 블록체인 엔진인 it-chain 의 p2p network 와 consensus 알고리즘, 그리고 리더 선출에 대해 알아보았습니다.

다음 포스트에서는 it-chain에서 블록을 합의하는 컴포넌트인 Blockchain 컴포넌트에 대해 알아보겠습니다.

  • LNH

Blockchain technology for enterprise service

건강 보험 등 이력에 대한 불변의 상태기록을 원하는 비즈니스에서는 상당히 유용하게 사용될 수 있다.

인센티브의 경우 네트워크 망을 유지하고 서비스에서 인센티브를 제공하는 기능을 어떻게 활용 가능한가?

Case1 분산 원장으로써의 블록체인

롯데카드 -> 블록체인 기반 생체 인증

삼성페이에서 로그인 정보를 다른 쪽에도 유지하기 위해 사용 =>

Case2 스마트 컨트랙트로써의 블록체인

현대카드 포인트 페이먼트를 스마트 컨트랙트로 구성

제일 큰 문제는 성능문제. => 추가로 컨센서스를 만드는 작업 등

신한금융 => 인증서 발급 로직을 스마트 컨트랙트로 구성

금융보안원, 금융 결제원 => 폰뱅킹 및 은행 송금 시스템

은행 송금 시스템을 블록체인화, 기존에는 중앙 시스템이 모든 은행의 거래 내역을 다 처리하고 매일 한번씩 정산하여 데이터베이스를 맞추는 식으로 햇었음

이 경우 스마트 컨트랙을 통해 했는데 역시 성능문제가 생겼음

여기서 가장 중요한 점은 고객 데이터는 데이터베이스에 올라갈 수 없음

때문에 블록체인과 외부 디비가 어떤 식으로 연동하는 것이 매우 중요한 포인트임

고객의 주요 쟁점

  1. 퍼포먼스 컨트랙트 내부 병렬화에 대한 요구가 나온다. 보통 컨트랙트 내에서 락을 걸어서 처리를 하는데 이 경우 처리가 빠르게 일어나지 못함
  2. privacy개인정보를 올리려면 어떻게? => 난스 만들어라
  3. Multi chain
  4. 익명 기술
  5. 파이널리티 가령 블록이 생성되어 트랜잭션이 만들어 지더라도 블럭이 폐기되면 다시 뒤로 돌아가기 때문에 고객의 지갑이 변동되는 문제가 생기며 이는 매우 큰 이슈이다,

블록체인 비즈니스 활용 Tip

사이드 체인을 유지하고 퍼블릭 네트워크와 연동하는 형태로 많이 서비스를 하게 된다.

이렇게 하면 기존 서비스의 품질을 해치지 않으면서도 블록체인을 적용할 수 있다.

가령 포인트를 적립시킨다고 하면 별도 사이드 체인을 만들어서 포인트를 등록하고 해당 체인을 다른 퍼블릭체인과 연동하여 포인트를 유통시킬 수 있다.

즉 이더 송금 수수료를 한번만 이용하지만 여러 거래를 별도 사이드체인에서 동작시키고 퍼블릭체인과 연동함으로써 해결이 가능하다.

Ex) aergo => 블록체인 sass 서비스

업그레이드 가능한 스마트 컨트랙트

투명성, 위변조 불가성

왜 업그레이드 가능한 스마트 컨트랙트가 필요한가?

  1. 배포 후 취약점이 발견되면 수정이 가능하다.
  2. 비즈니스 로직이 수정 불가하기 때문에 겪게 되는 불편함이 있다.

Delegate call 특정 컨트랙트를 통해 다른 컨트랙트를 실행시킴

조건

업그레이드로 스마트 컨트랙트 주소 안변함데이터 마이그레이션 없이 데이터보존여러 스마트 컨트랙을 한번에 배포

Proxy contract 를 만들어 버전관리를 하고 유저는 proxy contract 로 전달하고 proxy contract는 최신버전의 contract로 명령을 전달한다.

Registry contract upgrade Earl => 업그레이드하고자 하는 proxy contract의 주소를 받아온다. registry contract 모두를 업그레이드 하기 위해 registry contract를 실행시킨다.

스마트 컨트랙트 버전관리 툴

  1. deploy
  2. Registry contract 가 없으면 registry contract 배포

업그레이 가능한 스마트 컨트랙트의 이점

유저 입장에서는 스마트 컨트랙트 주소가 고정됨, 버전 정볼르 생각하지 않고 특정 호출만 계속 함개발자 입장에서는 모든 데이터가 그대로 유지되고 재사용 되게 됨업그레이드가 매우 편리함.

Token Model Design Process

토큰 모델이랑 탈중앙화 네트워크의 보이지 않는 손이다.

토큰이라는 인센티브를 가지고 경제가 어떻게 굴러가는지를 설계한다.

게임 이론

주어진 게임의 규칙에서 최선의 전략을 찾는 이론

메커니즘 디자인

모든 플레이어가 게임에 충실하게 참여를 했을 때 이를 원하는 방향으로 굴러가게 하기 위한 메커니즘에 대한 디자인

어떻게 기존의 경제 시장에서 토큰 모델을 적용시킬 것인가?

메커니즘 디자인의 기초

Agent 행동 주체

Type agent의 사적인 정보

Decision 가능한 사회적 결과의 집합

Utility function 에이전트가 특정 결과에 대해 얻는 효용

Decision function agent의 각 행동을 종합한 결정 규칙

Transfer function agent의 행동에 따라서 받거나 내야하는 돈

Social choice function

가령 마을에 쓰레기 처리장을 짓는 문제를 생각해 보자.

제일 쉬운 방법은 누군가가 모든 사람들에게 의견을 물어보는 것이다.

여기서 transfer function 은 agent의 type 에따라서 받거나 내야하는 돈의 규칙이다.

메커니즘의 특성

Efficiency

최대 다수의 최대 행복

trustfulness

모든 에이전트의 균형 전략이 자신의 type을 솔직하게 보고하는 것일때

Budget balanced

agent의 type이 바뀌더라도 메커니즘이 transfer function으로 얻는 수입이 일정할 때

메커니즘을 최적화 문제로 정의할 수 있다!!

메커니즘 최적화 적용

가령 서울의 평균 기온을 블록체인에 기록하는 메커니즘을 만든다고 해보자

  1. 오라클 선출 => 신뢰할 수 있는 외부 데이터를 선정한다.
  2. Shelling coin 많은 사람들이 준 값들의 중간값을 실제값으로 정한다.

계속해서 decision function 과 transfer function 을 바꾸어 보면서 실 데이터를 분석하여 효율적인 메커니즘을 도출해 내야 한다.

토큰 모델 디자인 프로세스

agents와 목표 행동 정의최적화 문제 설정반복메커니즘 규칙 설정규칙 변경결과 추론제약조건 변경

예시 - steemit

Object => 좋은 글의 공급을 극대화

Constraint => 초보 작가들이 글을 쓰기가 쉬워야 함, 독자들은 글을 쓸 때 돈을 내지 않아야 함 등

Decision => 추천수에 스팀 파워 가중치를 계산해 퀄리티로 인정함

Transfer =>

더 나은 설계를 위해 필요한 것들

좋은 규칙의 집합, 패턴실제 돌아가는 프로젝트에서 나오는 실증 데이터복잡한 메커니즘의 정량적 추론을 위한 시뮬레이션 툴

토큰 디자인 패턴

Incentive, curation , judgement, governance

메커니즘 디자인의 한계

닫힌 시스템을 가정한 설계이기 때문에 경쟁 프로토콜, 암호화폐 시장 등 외부 요소는 고려하지 못하기에

블록체인과 같은 완벽하게 공개된 플랫폼 내에서 어떤 사이드 이펙트가 나올지 알 수 없다.

토큰 디자이너를 위한 팁

  1. 플레이어가 아니라 디자이너처럼 생각하라.
  2. 목적과 제약조건 정의만 잘해도 반은 먹고 들어간다. => 토큰 가치 상승이 목적인가 이중 지불 방지가 목적인가, 목적과 제약조건만 확실하다면 솔루션은 얼마든지 바꿀 수 있음
  3. 솔루션을 decision function 과 transfer function 으로 바꾼다.
  4. 알고 있는 패턴이 풍부해야 문제를 잘 풀어나갈 수 있다.

화폐가치와 메커니즘 디자인은 어떻게 결합될 것인가

IOT에서의 블록체인

오프라인 데이터의 위변조를 막기 위해 가량 씨씨티비의 경우 해당 영상의 해시값을 저장하여 블록체인에 저장하고 추후 검증이 필요한 경우 해당 해시와 비교를 통해 할 수 있따.

Digital forensic => 영상 데이터의 법정에서 신뢰를 얻을 수 있음

가령 자율주행차의 경우 수동으로 운전을 했는가 혹은 자동으로 운동을 했는가가 과실에 매우 중요하다. 이를 블록체인에 실시간으로 저장하면 이를 막을 수 있다.

DAICO 모델 - 블록체인 위에서 ico 플랫폼

메커니즘

하스켈

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×