사토시 나카모토의 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

Queries and Mutations

GraphQL 서버에 어떻게 query 할 것인가?

example query

1
2
3
4
5

{
    hero{
        name
    }
}

arguments

1
2
3
4
5
6

{
    human(id: "1000"){
        name
        height
    }
}

alias

1
2
3
4
5
6
7
8

{
    empireHero: hero(episode: EMPIRE){
        name
    }
    jediHero:hero(eposode:JEDI){
        name
    }
}

fragments

reusable units called fragments

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

query HeroComparison($first: Int = 3){
    leftComparison: hero(episode: EMPIRE){
        ...comparisonFields
    }
    rightComparison: hero(episode: JEDI){
        ...comparisonFields
    }
}

fragment comparisonFields on Character{
    name
    friendConnection(first: $first){
        totalCount
        edges{
            node{
                name
            }
        }
    }
}

varables

1
2
3
4
5
6
7
8

query HeroNameAndFriends($episode: Episode){
    hero(eposide: $episode){
        name
        friends{
            name
        }
    }
}

now, in our client code we can simply pass a different variable rather than needing to constructor an entirely new query.

directives

1
2
3
4
5
6
7
8

query Hero($episode: Episode, $withFriends: hero(episode: $episode){
    hero(episode: $episode){
        name
        friends @include(if:$withFriends){
            name
        }
    }
})

Schemas and Types

Validation

Execution

Introspection

임베디드 시스템 개발 환경

임베디드 시스템을 개발하기 위해서는 기본적으로 임베디드 스템 개발을 위한 컴퓨터인 호스트 PC와 실제 임베디드 시스템이 설치된 개발하고자 하는 하드웨어인 Target PC가 있어야 한다.

타깃에는 호스트에서 만들어져서 설치된 여러 컴포넌트와 타깃을 부팅하기 위한 부트로더와 커널 그리고 임베디드 응용 프로그램이 존재하게 된다.

호스트에 설치된 개발 툴에는 타깃에서 수행될 수 있는 바이너리를 생성하는 크로스 컴파일러가 존재한다.

임베디드 시스템 개발 과정

1. 부트로더 개발
2. 커널 및 파일 시스템 개발
3. 응용 프로그램 개발

부트 로드 개발

타깃 보드에 전원이 인가되면 부트 롬으로부터 가장 먼저 수행되는 프로그램이다.

OS 의 커널을 로드한다.

커널 및 디바이스 드라이버 및 파일 시스템 개발

호스트 피씨에서 개발되며 하나의 이미지 파일 형태로 부트 롬에 저장되거나 별도의 저장 장치에 파일 시스템을 통한 파일 형태로 구현된다.

임베디드 응용 프로그램

호스트에서 개발하며 호스트의 크로스 컴파일러에 의해 타깃 보드에 맞는 바이너리가 생성된다.

주식을 함에 있어 가장 기본적인 차트 분석 방법에 대해 알아본다.

주식 차트는 그 모양이 촛볼 모양이라 하여 캔들차트라는 이름으로 불리는데, 캔들차트는 직사각형의 박대를 수직으로 관통하는 선이 있는 촛불모양의 막대로 구성된 차트이다.

이 차트에서 막대를 관통하는 선은 그날 주식의 상한가 와 하한가 를 나타내며 그날 하루 주식의 최고 가격과 최저 가격을 나타낸다. 여기서 막대의 위와 아래는 시가와 종가로 그날 시작한 가격과 장이 마감한 시점에서의 가격을 나타낸다.

여기서 시가가 종가보다 낮다면, 가격이 올랐으므로 양봉 이라고 하며, 시가가 종가보다 높으면, 가격이 내렸으므로 음봉 이라고 한다.

여기서 매우 중요한 지표가 하나 있는데 그것은 바로 주가 상승시의 거래량이다.

만약 주가가 주가가 상승하고 있는데 거래량이 많다면 그것은 사람들이 물건을 잘 팔려고 하지 않는다는 것으로 즉 매도세가 약하다 라고 볼 수 있다. 주가가 상승하는데 이를 팔려고 하는 사람이 적기 때문에 주가는 계속 올라가는 것으로 해석하면 된다. 만약, 주가가 상승하고 있는데 거래량이 적다면 그것은 사람들이 계속해서 주식을 사려고만 하여 거래량은 없는데 주식이 상승한다고 볼 수 있으며 이 경우 사려고 하는 사람의 세력이 강하다는 뜻으로 매수세가 강하다 라고 볼 수 있다.

만약 반대의 경우는 어떨까?

가령 주가가 하락하고 있는데 거래량이 많다 면 이것은 파는 사람이 매우 많은것에 비해 사려고 하는 사람들이 적기에 가격이 계속 내려가는 것으로 해석 할 수 있으며, 매수세가 약하다 라고 해석할 수 있다.

또 주가가 하락하고 있는데 거래량이 적다면 사람들이 주식을 팔려고 하는데 사는 사람은 많이 없는 것으로 매도세가 강하다 라고 해석할 수 있다.

언제 주식이 오를 것인가?

가장 대표적인 주식 상승의 조짐은 바로 장대 양봉 이다. 이러한 장대양봉이란, 그날의 종가가 상한가로 마감하는 경우를 말하는데, 이는 즉 장이 마감하는 시점끝까지 사람들이 계속해서 주식을 사들였다는 의미이며 이는 상당히 좋은 조짐이다.

여기서 그 날의 종가보다 다음날의 시가가 높은 경우를 상승갭이 있다 라고 하는데 이는 전날 마지막으로 팔린 가격보다 높은 가격에 주식이 거래되기 시작하는 것으로 사람들이 주식이 오를 것을 전망하고 있기에 상당히 좋은 매수신호이다.

언제 주식이 내릴 것인가?

direnv(Directory Environment) 란?

direnv는 이름 그대로 폴더별로 환경을 관리해주는 도구이다.

direnv로 설정을 해 놓으면 폴더 이동을 할 때마다 자동으로 설정해놓은 환경변수나 원하는 런타임 버전 지정 등을 알아서 할 수 있다. 그래서 한번 설정해 놓으면 해당 프로젝트에서 다른 설정에 대해서는 잊어버리고 쉽게 작업을 할 수 있고 어떤 환경 설정을 해놨는지가 궁금해지면 설정 파일을 열어보면 그만이다.

direnv는 Go로 작성되었는데 홈페이지에 나온대로 각 OS의 패키지 매니저를 이용해서 설치하거나(macOS라면 brew install direnv) 릴리스 페이지에서 OS에 맞는 바이너리를 받아서 설치해서 사용하면 된다.

direnv 를 cli 에 적용하기

설치 후에는 쉘에서 direnv가 실행되도록 해야 하므로 bash를 쓰고 있다면 ~/.bashrc파일에 eval "$(direnv hook bash)"를 추가하면 폴더 이동을 할 때마다 자동으로 실행되게 된다. bash 외에 다른 쉘을 쓰고 있다면 zsh, fish, tcsh를 다 지원하므로 홈페이지를 참고해서 설정하면 된다.

위 명령어를 통해 cli 에서 디렉토리를 이동하는 경우에 훅을 걸어 특정 설정을 적용시킬 수 있다.

.direnv 파일의 예

direnv 참고 블로그

경제학은 무엇이며 왜 필요한가?

필자는 현대 사회의 큰 축을 이루는 정치, 경제, 사회 모두의 측면에서 가장 근본이 되는 것은 바로 경제라고 생각한다.

현대 사회의 대부분의 문제들 가령, 전세난, 노조의 파업, 가계 부채, 글로벌 금융 위기와 취업난, FTA 문제들은 각 개인들 혹은 국가간 경제력을 거머쥐기 위한 치열한 전쟁의 현장이며, 이를 해결하는 것이 각국 정부의 주요 관심사가 되어가고 있다.

이토록 많은 사회적 문제를 해결하기 위한 학문이 바로 경제학 이며, 이는 그 이름이 주는 낯선 느낌과는 달리 삶의 모든 순간순간 우리가 고민하는 문제들의 집합체이기도 하다.

이러한 경제학을 간단히 정의하자면, 희소성 안에서 선택을 탐구하는 학문 이라고 할 수 있겠다.

인간의 욕망은 무한하고 인간이 가진 자원은 유한하기에 모든 개인과 국가는 더 많은 자원을 소유하기 위해 경쟁하고, 또 주어진 자원을 효율적으로 사용하기 위해 노력하며, 그 모든 행위를 위한 학문적 토대를 경제학이 제공한다.

먼저, 자원 에 대한 정의부터 생각해보자. 우리는 앞서 자원을 가지기 위해 경쟁한다고 했기 때문에, 자원이란 반드시 가치가 있어야 하고 또 그 양이 무한해야 할 것이다. 마치 공기처럼 수없이 많이 있기 때문에 다른 사람들과 경쟁할 필요가 없다면 그것은 더 이상 경쟁의 대상이 되지 못한다. 이러한 자원은 재화 와 서비스 로 분류될 수 있는데, 여기서 재화 란 쌀, 가전제품 처럼 형태가 존재하는 유형의 상품을 말하며, 서비스 란 트레이너의 PT 처럼 무형의 상품을 말한다.

또 재화 는 자유재 와 경제재 로 구분될 수 있는데, 자유재 란 앞에서 말한 것처럼 무한히 존재하여 다른 사람과 경쟁이 필요없는 재화를 말하며, 경제재 란 그 양이 한정적이기 때문에 모든 사람이 원하는 만큼 소유할 수 없기에 경쟁의 대상 이 될 수 있는 재화를 말한다.

이처럼 경제학이란 전체 사회원 혹은 국가의 입장에서는 무한하지 못한 재화를 효과적으로 사용하기 위한 학문이며, 효율성 과 형평성 을 추구하는데 즉, 최소의 비용으로 최대의 효과를 얻고, 사회 구성원간에 보다 공평하게 재화를 나눌 수 있도록 하는 것을 목적으로 한다. 이처럼 효율성과 형평성을 극대화 하기 위해서는 비용과 수익의 분석을 통해 어느 선택이 다른 대안에 비해서 효율적인가를 판단하고 각 대안에 소요되는 비용과 수익을 정확하게 계산할 수 있어야 한다.

비용이란 무엇이며 어떻게 산출되는가?

경제학의 목적인 효율성과 형평성을 추구하기 위해서는 비용과 수익의 분석을 통해 어느 선택이 다른 대안에 비해서 효율적인가를 판단하고 각 대안에 소요되는 비용과 수익을 정확하게 계산할 수 있어야 한다고 하였다. 그렇다면 여기서 비용이란 무엇인가?

비용은 기회 비용(경제적 비용) 과 명시적 비용 으로 나누어 생각할 수 있는데, 먼저 기회 비용 이란 내가 얻고자 하는 것을 얻기위해 내가 지불해야하는 경제적 가치로 내가 가진 모든 선택지를 고려하여 하나의 선택지를 선택하였을때 지불해야 할 비용 뿐 아니라 다른 선택지를 선택함으로써 얻을 수 있는 이익까지 포기하는 것이 되므로 그 두 가치를 합산한 것으로, 흔히 생각하는 시장의 가격과는 차이가 있다. 반면, 명시적 비용 이란, 단순히 장부상에 기록되는 비용으로 흔히 우리가 인식하는 비용이라 생각할 수 있다.

한 예를 들면 만약 필자가 10년 할부로 페라리를 구입한다고 하면, 매달 내가 지불하는 할부금액의 합이 명시적 비용 이라고 볼 수 있다. 하지만 필자가 경제적으로 지불하는 만약 필자가 저축이라는 다른 선택을 선택하였다면 얻을 수 있는 복리에 대한 이자율 또한 포기한 셈이 되므로 10년 동안 은행에 할부금을 저축한 금액에 대한 10년간의 복리 이자액을 묵시적 비용 이라 부르고 이 둘을 합한 것이 필자가 지불한 경제적 비용 즉, 기회 비용 이 되는 것이다.

경제적 비용 = 명시적 비용 + 묵시적 비용

이처럼 매 결정에서 내가 지불하는 기회 비용 을 정확히 따져보고 선택을 내리는 것은 매우 힘든 일이다. 내가 처한 경제적 상황과 선택지를 면밀히 따져보고 경제 현상을 이해해야만 옳은 경제적 선택을 내릴 수 있으며, 이때 필요한 것이 경제적 사고 이다.

무엇을 선택할 것인가?

우리는 경제학의 주요 요소인 재화 와 비용 에 대해 알아보았다.

경제학은 이러한 한정된 재화를 효율적으로 사용하기 위한 여러가지 선택을 내리는 것이라 배웠고, 각 선택을 함에 있어 정확한 경제적 비용을 측량하는 방법 또한 배웠다.

그렇다면 우리는 무엇에 관한 선택을 할 것인가?

경제학에서 우리는 크게 3가지에 관한 경제적 선택에 대해 알아볼 것인데, 그것은 바로 무엇을, 어떻게, 누구를 위하여 생산할 것인가에 대한 문제 이다.

먼저, 무엇을 생산할 것인가의 선택 은 제한된 자원을 사용하여 사회 안에서 어떠한 상품들이 생산되느냐를 선택하는 문제인데, 가령 한 국가에서 전쟁을 위한 무기를 생산하여 국력을 증강시킬 지 혹은 식량을 생산하여 국민들의 삶의 질을 높일 것인지를 선택하는 문제는 매우 중요하다.

두번째 선택은 어떻게 생산할 것인가 에 대한 문제이다.

무엇을 생산할지가 결정되었다면 그 재화를 가장 효율적으로 생산하기위한 다양한 프로세스를 고민해야 한다. 어떠한 생산 방식을 채택 하여 효율을 높일지, 노동을 주로 사용하여 생산할 것인지 혹은 자본투자를 통하여 생산을 극대화 할 것인지 등을 고민한다.

두번째 선택지에 관한 문제는 현대 과학과 공학의 주요한 발전의 목적이 되는데, 독보적인 기술의 진보를 통해 생산성 증진을 혁신적으로 끌어올릴 수 있기에 많은 국가는 막대한 자본을 투자하여 생산 기술의 진보에 열을 올리곤 한다.

선번째 경제적 선택은 바로 누구를 위해 생산할 것인가 에 대한 것이다.

이것은 분배에 관한 문제이며, 효율적으로 축적한 경제적 이윤을 어떤방식으로 형평성을 맞추어 분배할지에 대한 문제이다.

이러한 문제에 대한 다양한 선택지가 존재하는데, 극단적으로는 자본주의와 공산주의의 대립처럼 부의 효율적이고 공정한 분배에 관한 문제를 고려한다.

경제학의 종류

주류 경제학과 정치 경제학

경제이론에 대한 의견은 경제학사에서도 첨예하게 대립하고 있으며 흔히 아담 스미스 이후의 고전학파와 이를 이어받은 신고전학파 경제학과 1930년대 세계 대공황 이후 정부의 역할을 강조하는 케인즈 학파 로 이루어 지는 주류 경제학 과 정치 경제학 이라 부르는 마르크스 주의 경제학 이 있다.

여기서 주류 경제학 은 자유방임의 시장경제가 자원배분을 가장 효율적으로 이룰 수 있다고 믿는 경제학파 이며, 흔히 우리가 아는 보이지 않는 손 을 신봉하는 경제학파라고 볼 수 있다. 반면 정치 경제학 이란 생산 수단의 공동 소유를 기초로 하는 사회주의적 경제체제를 추구하여 국가의 이상적인 통치와 질서를 통해 경제의 효율성과 형평성을 이룩할 수 있다고 주장하는 학파이다.

규범적 경제학과 실증적 경제학

규범적 이란 주관적 가치관이 개입된 경우를 말하며, 실증적 이란 가치관이 들어가지 않고 현상을 있는 그대로 묘사하는 것을 말한다. 즉, 실증적 경제학 이란 주관적 가치관의 개입 없이 경제현상을 있는 그대로 설명하는 것을 의미하며, 규범적 경제학 이란 가치관이 개입되는 경제학을 말한다.

가령 수요의 법칙 을 생각해 보자. 수요의 법칙 이란 가격이 오르면 소비가 줄고 가격이 내리면 소비가 늘어난다는 경제 법칙으로 이는 실험과 경험을 통해 측정된 사실을 바탕으로 얻어낸 실증적 경제학의 예를 보여준다.

반면, 농산물을 수입하는 정책을 세운다고 해 보자. 값싼 농산물을 수입하면, 국내의 가난한 농민들에게는 큰 타격이 되겠지만, 많은 사람들이 보다 저렴하게 식품을 구매할 수 있고, 수입하지 않으면, 국민들이 비교적 비싼 가격으로 식품을 구매해야 하지만 가난한 농민들에게는 큰 보탬이 된다. 즉, 이와 같은 경정을 할 때에는 어떤 집단의 이익을 우선시 하는가에 따라 서로 다른 선택을 해야하며 여기에는 반드시 주관적인 가치판단이 들어가야 한다. 이를 기반으로 하는 경제학을 규범적 경제학 이라 일컷는다.

미시 경제학과 거시 경제학

미시 경제학 이란 개별 시장의 관점에서 경제를 보는 것이고, 거시 경제학 이란 경제 전체의 관점에서 경제를 바라보는 경제학으로, 가령 특정 개인이나 집단 혹은 기업의 입장에서 시장을 바라보는 것을 미시 경제학 에서 다루며 국가 경제 전체를 대상으로 하는 환율, 물가, 이자율 등에 대한 고민을 하는 것이 거시 경제학 이다.

즉, 미시 경제학 이란 가계와 기업의 의사결정과정을 분석하고 이들이 시장에서 어떻게 상호작용하는가를 연구하는 분야이고, 거시 경제학 은 경제 전체에 미치는 변수와 추세에 관하여 연구하는 분야이다.

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

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

루니버스란?

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

두나무의 루니버스란 이처럼 개발의 진입장벽이 높은 블록체인 기술의 장벽을 낮추고 개발자라면 누구나 쉽게 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 등을 통해 리스팅 후의 마케팅 까지 지원합니다.

쿠버네티스 시작하기

최근에는 컨테이너 기술인 도커 등을 이용하여 어플리케이션을 컨테이너 형태로 배포하는 추세이다.

kubernetes는 이렇게 많은 컨테이너들의 배포 프로세스를 관리하고 컨테이너 들을 클러스터링 하여 체계적이로 관리, 배포할 수 있게 해주는 툴이다.

클러스터를 생성하고 각 어플리케이션을 노드 단위가 아니라 클러스터 단위로 배포함으로써 특정 컨테이너에 문제가 생기면 kubernetes가 컨테이너를 재시작 하는 등 다양한 기능을 제공하여 보다 안정적으로 서비스를 운영할 수 있게 해준다.

또한 여러 컨테이너들 사이에서 Load Balancing 등을 활용한 라우팅 기능을 사용하여 분산처리도 가능하게 해주는 장점이 있다.

Kind of Objects in kubernetes

Kubernetes에는 다음과 같이 크게 4가지 종류의 Object 가 존재한다.

1. Cluster
2. Service
3. Pod

Create kubernetes cluster

먼저 쿠버네티스를 시작하기 위해서는 클러스터를 생성하여 그 위에 컨테이너화된 어플리케이션을 배포할 수 있다.

쿠버네티스 디플로이먼트 설정을 만들어야 한다. 디플로이먼트는 쿠버네티스가 애플리케이션의 인스턴스를 어떻게 생성하고 업데이트해야 하는지를 지시한다.

디플로이먼트가 만들어지면, 쿠버네티스 마스터가 해당 애플리케이션 인스턴스를 클러스터의 개별 노드에 스케줄한다.

디플로이먼트는 애플리케이션 인스턴스를 생성하고 업데이트하는 역할을 담당한다.

미니쿠베를 통해 로컬에서 간단하게 쿠버네티스를 실행시킬 수 있다.

1
2

minikube start
minikube stop

새로운 deployment를 실행한다.

아래 명령어에서 deployment의 이름과 app의 이미지 주소를 입력해 준다.

We want to run the app on a specific port so we add the –port parameter:

1
2
3

kubectl run kubernetes-bootcamp --image=[gcr.io/google-samples/kubernetes-bootcamp:v1](<http://gcr.io/google-samples/kubernetes-bootcamp:v1>) --port=8080

kubectl get deployments

기본적으로 쿠버네티스의 팟들은 해당 클러스터 내에서 서로 ip를 알고 있지만 클러스터 밖은 클러스터 내의 팟의 아이피를 알지 못한다.

The kubectl command can create a proxy that will forward communications into the cluster-wide, private network.

이러한 클러스터에 접근하기 위해 proxy 서버를 돌릴 수 있는데, 다음과 같다.

위처럼 환경변수를 설정하면 다음과 같이 접근이 가능하다.

1

curl [<http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME/proxy/>](<http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME/proxy/>)

파드는 쿠버네티스 플랫폼 상에서 최소 단위가 된다. 우리가 쿠버네티스에서 배포를 생성할 때, 그 배포는 컨테이너 내부에서 컨테이너와 함께 파드를 생성한다

파드는 하나 또는 그 이상의 애플리케이션 컨테이너 (도커 또는 rkt와 같은)들의 그룹이고 공유 스토리지 (볼륨), IP 주소 그리고 그것을 동작시키는 방식에 대한 정보를 포함하고 있다.

• kubectl get - 자원을 나열한다
• kubectl describe - 자원에 대해 상세한 정보를 보여준다.
• kubectl logs - 파드 내 컨테이너의 로그들을 출력한다
• kubectl exec - 파드 내 컨테이너에 대한 명령을 실행한다.

노드는 쿠버네티스에 있어서 워커 머신이며 클러스터에 따라 VM 또는 물리 머신이 될 수 있다. 여러개의 파드는 하나의 노드 위에서 동작할 수 있다.

We can execute commands directly on the container once the Pod is up and running. For this, we use the exec command and use the name of the Pod as a parameter. Let’s list the environment variables:

특정 팟에서 명령어를 실행할 수 있따.

가령 kubectl exec -it \$POD_NAME bash

cat server.js

Service

쿠버네티스에서 서비스는 하나의 논리적인 파드 셋과 그 파드들에 접근할 수 있는 정책을 정의하는 추상적 개념이다

서비스는 종속적인 파드들 사이를 느슨하게 결합되도록 해준다. 서비스는 모든 쿠버네티스 오브젝트들과 같이 YAML 또는 JSON을 이용하여 정의된다.

쿠버네티스 클러스터 내 각 파드는 유일한 IP 주소를 가지며, 여러분의 애플리케이션들이 지속적으로 기능할 수 있도록 파드들 속에서 발생하는 변화에 대해 자동으로 조정해 줄 방법이 있어야 한다.

비록 각 파드들이 고유의 IP를 갖고 있기는 하지만, 그 IP들은 서비스의 도움없이 클러스터 외부로 노출되어질 수 없다. 서비스들은 여러분의 애플리케이션들에게 트래픽이 실릴 수 있도록 허용해준다. 서비스들은 ServiceSpec에서 type을 지정함으로써 다양한 방식들로 노출시킬 수 있다:

서비스는 쿠버네티스의 객체들에 대해 논리 연산을 허용해주는 기본 그룹핑 단위인, 레이블과 셀렉터를 이용하여 파드 셋과 매치시킨다. 레이블은 오브젝트들에 붙여진 키/밸류 쌍으로 다양한 방식으로 이용 가능하다:

• 개발, 테스트, 그리고 상용환경에 대한 객체들의 지정
• 임베디드된 버전 태그들
• 태그들을 이용하는 객체들에 대한 분류

여러분은 kubectl 명령에--expose 옵션을 사용함으로써 디플로이먼트 생성과 동일 시점에 서비스를 생성할 수 있다.

how to expose Kubernetes applications outside the cluster using the kubectl expose command

1
2

노드 포트 타입으로 클러스터를 외부로 노출시킴
kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080

열린 포트를 확인하기 위해 다음 명령어를 실행시킴

kubectl describe services/kubernetes-bootcamp

curl $(minikube ip):$NODE_PORT

라벨 사용하기

1
2

아래 커맨드의 -l 은 라벨을 의미한다.
kubectl get pods -l run=kubernetes-bootcamp

다음과 같이 라벨링을 한다.

kubectl label pod \$POD_NAME app=v1

kubectl describe pods \$POD_NAME

를 실행시켜 보면 라벨링이 바뀐 것을 볼 수 있다.

다음과 같이 새로운 라벨로 쿼링을 할 수 있다

kubectl get pods -l app=v1

다음과 같이 서비스를 삭제하면 요청이 오지 않는데 그것은 외부로 열려있지 않기 때문이다.

kubectl delete service -l run=kubernetes-bootcamp

드플로이먼트의 복제수를 변경하면 스케일링이 수행된다.

스케일링 명령어

1

kubectl scale deployments/kubernetes-bootcamp --replicas=4

다음 명령어로 확인하면 서로 다른 ip를 가진 여러 개의 팟이 생긴것을 볼 수 있다.

1

kubectl describe deployments/kubernetes-bootcamp

앱 업데이트 하기

1

kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=jocatalin/kubernetes-bootcamp:v2

위 명령어는 특정 deployment의 팟의 이미지를 교체해준다.

kubectl get pods

를 통해 확인해 본다.

롤아웃

kubectl rollout status deployments/kubernetes-bootcamp

롤백

kubectl rollout undo deployments/kubernetes-bootcamp

클러스터 밖에서 팟을 바라보기

The hostNetwork setting applies to the Kubernetes pods. When a pod is configured with hostNetwork: true, the applications running in such a pod can directly see the network interfaces of the host machine where the pod was started.

1
2
3
4
5
6
7
8
9

apiVersion: v1
kind: Pod
metadata:
  name: influxdb
spec:
  hostNetwork: true
  containers:
    - name: influxdb
      image: influxdb

컨테이너에 hostPort 옵션

The hostPort feature allows to expose a single container port on the host IP.

1
2
3
4
5
6
7
8
9
10
11

apiVersion: v1
kind: Pod
metadata:
  name: influxdb
spec:
  containers:
    - name: influxdb
      image: influxdb
      ports:
        - containerPort: 8086
          hostPort: 8086

To make the service accessible from outside of the cluster a user can create a service of type NodePort.

each Kubernetes node will proxy that port to the pods selected by the service.

1
2
3
4
5
6
7
8
9
10
11

kind: Service
apiVersion: v1
metadata:
  name: influxdb
spec:
  type: NodePort
  ports:
    - port: 8086
      nodePort: 30000
  selector:
    name: influxdb

kubernetes DNS

Services

A records

“Normal” (not headless) Services are assigned a DNS A record for a name of the form my-svc.my-namespace.svc.cluster.local. This resolves to the cluster IP of the Service.

“Headless” (without a cluster IP) Services are also assigned a DNS A record for a name of the form my-svc.my-namespace.svc.cluster.local. Unlike normal Services, this resolves to the set of IPs of the pods selected by the Service. Clients are expected to consume the set or else use standard round-robin selection from the set.

SRV records

SRV Records are created for named ports that are part of normal or Headless Services. For each named port, the SRV record would have the form _my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster.local. For a regular service, this resolves to the port number and the domain name: my-svc.my-namespace.svc.cluster.local. For a headless service, this resolves to multiple answers, one for each pod that is backing the service, and contains the port number and the domain name of the pod of the form auto-generated-name.my-svc.my-namespace.svc.cluster.local.

Kube dns

https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

minikube start

kubectl cluster-info

kubectl get nodes

[ 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 시리즈

• 01. P2P 네트워크와 합의 알고리즘
• 02. 블록의 생성과 동기화

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 시리즈

• 01. P2P 네트워크와 합의 알고리즘
• 02. 블록의 생성과 동기화

LNH