반응형

출처: https://webnautes.tistory.com/783



아두이노에 연결된 온도센서의 값을 읽어서 ESP8266과 PHP를 이용하여 MySQL에 저장하는 예제입니다.



2016.  5. 21. 최초작성

2018. 10. 17. 마지막 업데이트




1. 다음 포스팅에 Arduino Uno와 ESP8266 연결하는 방법과 필요한 라이브러리를 설치하는 방법이 소개되어있습니다.

먼저 진행을 해야 합니다.



Arduino Uno에 ESP8266 WiFi 모듈을 연결하여 사용하는 방법

http://webnautes.tistory.com/755





2. 다음 포스팅에 Arduino Uno와 DB18B20 연결 방법과 필요한 라이브러리를 설치하는 방법이 소개되어 있습니다.

먼저 진행을 해야 합니다.



Arduino Uno에서 DS18B20 1-Wire 온도 센서 사용하기

http://webnautes.tistory.com/631





2.  윈도우 또는 리눅스에 아파치 웹서버, MySQL, PHP를 설치합니다.



Ubuntu 16.04에 LAMP ( Apache2, MySQL , PHP7) 설치하는 방법

http://webnautes.tistory.com/1028


Ubuntu 18.04에 LAMP ( Apache2, MySQL , PHP 7) 설치하는 방법

http://webnautes.tistory.com/1185


윈도우 기반 웹 개발 환경 만들기 ( Apache2, PHP, MySQL, PhpMyAdmin )

http://webnautes.tistory.com/1206


Raspberry Pi 3에 LAMP (Linux, Apache, MySQL, PHP) 설치하는 방법

http://webnautes.tistory.com/842





3. 데이터를 저장할 테이블을 생성합니다.


mysql> create database db;
Query OK, 1 row affected (0.00 sec)

mysql> use db;
Database changed
mysql> create table data(num int(10));
Query OK, 0 rows affected (0.01 sec)




4. 데이터베이스에 값을 넣을때 사용할 PHP 파일을 생성하여 다음 내용을 복사하여 붙여넣기 해줍니다.


리눅스

sudo nano /var/www/html/insert_data.php


윈도우

C:\wamp64\www 위치에 insert_data.php 파일 생성



<?php
$con = mysqli_connect("localhost", "MySQL 계정 아이디", "MySQL 계정 패스워드", "사용할 데이터베이스 이름");

if (mysqli_connect_errno())
{
echo "Failed to connect to MySQL: " . mysqli_connect_error();
}

  $num = $_GET["num"];

  $sql = "insert into db.data(num) values($num)";
  mysqli_query($con, $sql);

  mysqli_close($con);
?>




5. 다음 아두이노 코드를 업로드 합니다.


#include <OneWire.h>    
#include <DallasTemperature.h>    
#include <string.h>  

#include "ESP8266.h"
#include <SoftwareSerial.h>  
   

#define SSID        "공유기의 SSID"

#define PASSWORD    "공유기의 비밀번호"

#define SERVERIP   "서버 아이피"

 

SoftwareSerial mySerial(11, 10); /* RX:D11, TX:D10 */

   
     
//DS18B20 온도 센서의 데이터선인 가운데 핀을 아두이노 3번에 연결합니다.     
#define ONE_WIRE_BUS 3  
     
//1-wire 디바이스와 통신하기 위한 준비    
OneWire oneWire(ONE_WIRE_BUS);    
     
// oneWire선언한 것을 sensors 선언시 참조함.    
DallasTemperature sensors(&oneWire);    
     
//다비아스 주소를 저장할 배열 선언    
DeviceAddress insideThermometer;    
     
     
     
char * floatToString(char * outstr, double val, byte precision, byte widthp){  
char temp[16]; //increase this if you need more digits than 15  
byte i;  
 
temp[0]='\0';  
outstr[0]='\0';  
 
if(val < 0.0){  
  strcpy(outstr,"-\0");  //print "-" sign  
  val *= -1;  
}  
 
if( precision == 0) {  
  strcat(outstr, ltoa(round(val),temp,10));  //prints the int part  
}  
else {  
  unsigned long frac, mult = 1;  
  byte padding = precision-1;  
    
  while (precision--)  
    mult *= 10;  
 
  val += 0.5/(float)mult;      // compute rounding factor  
    
  strcat(outstr, ltoa(floor(val),temp,10));  //prints the integer part without rounding  
  strcat(outstr, ".\0"); // print the decimal point  
 
  frac = (val - floor(val)) * mult;  
 
  unsigned long frac1 = frac;  
 
  while(frac1 /= 10)   
    padding--;  
 
  while(padding--)   
    strcat(outstr,"0\0");    // print padding zeros  
 
  strcat(outstr,ltoa(frac,temp,10));  // print fraction part  
}  
 
// generate width space padding   
if ((widthp != 0)&&(widthp >= strlen(outstr))){  
  byte J=0;  
  J = widthp - strlen(outstr);  
 
  for (i=0; i< J; i++) {  
    temp[i] = ' ';  
  }
 
  temp[i++] = '\0';  
  strcat(temp,outstr);  
  strcpy(outstr,temp);  
}  
 
return outstr;  
}  
 
 
     
void setup(void)    
{    
   
 //시리얼 포트 초기화    
 Serial.begin(9600);    
 
  
/////////////////////////////////////////////////////////////////////////  
 Serial.setTimeout(5000);  
 mySerial.begin(9600);   
 Serial.println("ESP8266 connect");  
 
   
  boolean connected=false;  
  for(int i=0;i<10;i++)  
  {
      if(connectWiFi())  
      {
        connected = true;  
        break;  
      }
  }
    
  if (!connected){while(1);}  
  delay(5000);  
   
  mySerial.println("AT+CIPMUX=0");  
 ///////////////////////////////////////////////////////////////////////////     
      
        
 //1-wire 버스 초기화    
 sensors.begin();    
       
 //발견한 디바이스 갯수    
 Serial.print("Found ");    
 Serial.print(sensors.getDeviceCount(), DEC);    
 Serial.println(" devices.");    
     
 // parasite power 모드일 때에는  2핀(GND와 DQ 핀)만 연결하면 됨.
 Serial.print("Parasite power is: ");     
 if (sensors.isParasitePowerMode()) Serial.println("ON");    
 else Serial.println("OFF");    
       
      
 //버스에서 첫번째 장치의 주소를 가져온다.    
 if (!sensors.getAddress(insideThermometer, 0)) Serial.println("Unable to find address for Device 0");     
       
 //버스에서 발견한 첫번째 장치의 주소 출력    
 Serial.print("Device 0 Address: ");    
 printAddress(insideThermometer);    
 Serial.println();    
     
 //데이터시트에서 확인결과 9~12비트까지 설정 가능    
 sensors.setResolution(insideThermometer, 10);    
      
 Serial.print("Device 0 Resolution: ");    
 Serial.print(sensors.getResolution(insideThermometer), DEC);     
 Serial.println();    
}    
     
     
// 온도를 출력하는 함수    
void printTemperature(DeviceAddress deviceAddress)    
{    
 //섭씨 온도를 가져옴    
 float  tempC = sensors.getTempC(deviceAddress);    
       
 Serial.print("Temp C: ");    
 Serial.print(tempC);    
 Serial.print(" Temp F: ");    
       
 //화씨 온도로 변환    
 Serial.println(DallasTemperature::toFahrenheit(tempC));  
 
 
 
    String cmd = "AT+CIPSTART=\"TCP\",\"";  
    cmd += SERVERIP;  
    cmd += "\",80";  
    Serial.println(cmd);  
    mySerial.println(cmd);  
    if(mySerial.find("Error"))  
   {
     Serial.println( "TCP connect error" );  
     return;  
   }
    
 
   char test[20];  
   String temp(floatToString(test,tempC, 2, 0));  
     
    cmd = "GET /insert_data.php?num="+temp+"\r\n";  
    mySerial.print("AT+CIPSEND=");  
    mySerial.println(cmd.length());  
         
      
    Serial.println(cmd);  
      
      
    if(mySerial.find(">"))  
    {
      Serial.print(">");  
      }else  
      {
        mySerial.println("AT+CIPCLOSE");  
        Serial.println("connect timeout");  
        delay(1000);  
        return;  
      }
        
      mySerial.print(cmd);  
      delay(2000);  
      //Serial.find("+IPD");  
      while (Serial.available())  
      {
        char c = Serial.read();  
        mySerial.write(c);  
        if(c=='\r') mySerial.print('\n');  
      }
      Serial.println("====");  
      delay(1000);  
}    
     
//디바이스 주소를 출력하는 함수    
void printAddress(DeviceAddress deviceAddress)    
{    
 for (uint8_t i = 0; i < 8; i++)    
 {   
   if (deviceAddress[i] < 16) Serial.print("0");    
       Serial.print(deviceAddress[i], HEX);    
 }   
}    
     
     
void loop(void)    
{     
 Serial.print("Requesting temperatures...");    
 //sensors.requestTemperatures();   //연결되어 있는 전체 센서의 온도 값을 읽어옴
 sensors.requestTemperaturesByIndex(0); //첫번째 센서의 온도값 읽어옴    
 Serial.println("DONE");    
      
 //센서에서 읽어온 온도를 출력    
 printTemperature(insideThermometer);    
}    
 
 
boolean connectWiFi()  
{  
  //mySerial.println("AT+CWMODE=1");  
    
  String cmd="AT+CWJAP=\"";  
  cmd+=SSID;  
  cmd+="\",\"";  
  cmd+=PASSWORD;  
  cmd+="\"";  
  mySerial.println(cmd);  
  Serial.println(cmd);  
  delay(3000);  
   
  if(mySerial.find("OK"))  
  {
    Serial.println("OK, Connected to WiFi.");  
    return true;  
  }
  else  
  {
    Serial.println("Can not connect to the WiFi.");  
    return false;  
  }
}  





6. 아두이노 IDE에서 툴 > 시리얼모니터를 선택합니다.


공유기에 접속 성공하면 “OK, Connected to WiFi” 메시지가 보입니다.

아두이노에 연결된 DB18B20를 찾았다면 “Found 1 devices”라는 메시지가 보입니다.


이후 온도를 가져오고(Requesting temperatures...Done)

웹서버에 온도를 저장하는 것(GET /insert_data.php?num=온도)을 반복합니다.





7. MySQL을 확인해보면 데이터가 입력되는 것을 볼 수 있습니다.



반응형
반응형

Writer : Jung Sungdong

Reviewed by : 김종호(Jason Kim), 문건기(Geon-gi Mun), 오영택(Youngtaek (Robbie) OH), 오세진(Se Jin OH), 김동한(김동한), 맹윤호

서울대학교 블록체인 학회 ‘디사이퍼(Decipher)’의 Hyperledger Fabric에 대한 글입니다.

Disclaimer: 본 아티클에 대한 리뷰는 전적으로 개인의 차원에서 진행된 것으로 리뷰어의 소속과는 무관합니다.


하이퍼레저는 리눅스 재단(Linux Foundation)이 주도하는 엔터프라이즈용 블록체인 기술 개발을 위한 오픈소스 프로젝트이다. 현재 5개의 프레임워크와 5개의 툴을 만들고 있는 중이며, 이 중에 하이퍼레저 패브릭(이하 패브릭)은 가장 활발하게 개발되고 있다.

패브릭은 모듈화된 프라이빗 블록체인 프로젝트로, 초기 IBM이 제공한 코드를 기반으로 현재 35개 이상의 조직들과 200명이 넘는 개발자가 참여하고 있다. 이렇게 대규모로 개발되고 있는 패브릭은 여러 기업들(구글, 아마존, 오라클 등)이 활용하고 있는 인기 있는 블록체인 프로젝트이다.

패브릭의 네트워크 구조는 비트코인이나 이더리움과 같은 기존에 많이 알려진 퍼블릭 블록체인(Public blockchain)과 비교했을 때 상당히 복잡하다. 이는 패브릭이 프라이빗 블록체인으로서 퍼블릭 블록체인은 가지지 않는(또는 필요 없는) 합의 알고리즘의 선택적 사용, 네트워크 참여 권한 통제, 채널 및 멀티 장부 사용 등의 추가적인 여러 기능들을 가지기 때문이다.

하이퍼레저 패브릭과 다른 블록체인 프로젝트들과의 비교 (2019년 1월 기준)

하이퍼레져 패브릭은 퍼블릭 블록체인들과 비교했을 때, 구조적 차이로 인해 기능상 여러 차이점들이 발생한다. 상세한 구조적 차이를 설명하기 전에 패브릭의 기능적 특징을 우선 간략히 설명하려고 한다. 하이퍼레져 패브릭은 다음과 같은 특징을 가진다.

하이퍼레져 패브릭의 특징

  1. 허가형 블록체인으로서 허가 받은 참여자만 네트워크에 참여할 수 있다.
  2. 스마트 컨트랙트에 일반 프로그래밍 언어 사용이 가능하다. (현재는 go, Node.js 지원)
  3. 스마트 컨트랙트를 일부 노드만 실행하므로 다수의 거래를 병렬적으로 빠르게 처리할 수 있다.
  4. 채널을 이용해 허가 받은 사람들에게만 장부(ledger)를 공개할 수 있다.
  5. 교체 가능한 합의 프로토콜을 사용할 수 있다. (SOLO, Kafka 방식, PBFT등)
  6. 허가형 블록체인으로써 네트워크 참여자의 신원을 확인할 수 있기 때문에 문제 발생시 책임소재를 분명히 할 수 있다.

이 글에서는 하이퍼레저 네트워크를 구성하는 순서대로 차근차근 따라가며 복잡한 패브릭의 구성 요소를 살펴보려고 한다. 이 글을 읽고 독자는 패브릭의 네트워크 구조를 개념적으로 이해하고, 패브릭이 기존의 퍼블릭 블록체인들과 기능적 차이를 가지게 되는 원리를 이해할 수 있게 되기를 바란다.

프라이빗/퍼블릭 블록체인의 개념, 비트코인/이더리움 네트워크 구조에 대해 대략 이해하고 있어야 이어지는 내용을 읽기가 수월할 것으로 예상된다. 패브릭은 현재도 계속 발전되고 있으며, 버전마다 구조가 달라지고 있으므로 최신 자료는 매우 제한적이다. 따라서, 공식 패브릭 홈페이지의 문서를 많이 참조했으며 특히, 블록체인 네트워크 파트의 ‘네트워크 구성 순서’를 안내서로 삼아 이 글을 썼다.

하이퍼레저 패브릭 네트워크 만들기

패브릭 네트워크를 만들기 위해서 가장 먼저 해야할 일은 오더링 서비스(Ordering service)를 구동하는 것이다. 오더링 서비스는 블록 안의 트랜잭션 순서를 정하고 연결된 노드들에게 전달하는 기능을 한다. 트랜잭션의 순서는 FCFS (first-come first-serve) 방식에 의해 결정된다.

오더링 서비스 노드들은 오더링 서비스를 호스팅하는 주체이다. 오더링 서비스 노드들은 한 그룹이 운영하는 중앙화된 방식에서 여러 그룹의 노드들이 참여하는 분산화된 모델까지 여러 합의 방식을 이용할 수 있다. 하이퍼레져 패브릭(Hyperledger Fabric)은 기본적으로 SOLO(Single Ordering Service Node)라는 싱글 노드 방식과 Kafka 방식이라는 CFT(Crash fault tolerance) 기반 합의 프로토콜을 제공한다. 추후 PBFT(Practical Byzantine Fault Tolerance)도 지원할 예정이다. Kafka 방식이 가지는 성질인 CFT(Crash fault tolerance)란 일부 시스템 구성 요소들이 작동하지 않더라도 올바른 합의에 도달할 수 있는 성질을 말한다. 기존 퍼블릭 블록체인에서 주로 사용되는 BFT(Byzantine fault tolerance) 시스템은 시스템 구성요소의 기능적 문제뿐 아니라 악의적인 공격(Malicious attack)까지 고려하므로 CFT 시스템과 비교했을 때 더욱 복잡하며 느리다.

네트워크에 참여하기 위해 특정 주체의 승인(Permission)이 필요하지 않은 퍼블릭 블록체인들과는 달리 프라이빗 블록체인에는 비교적 신뢰할 수 있는 참여자만 관리자의 승인을 받고 네트워크에 참여하게 되므로 악의적인 주체(Malicious actors)의 공격 확률이 매우 작을 것으로 간주한다. 따라서, 프라이빗 블록체인에서는 BFT 기반 합의 프로토콜보다 더 빠르고 간단한 합의 프로토콜 또한 허용 가능한 범위로 간주된다.

패브릭을 사용하는 조직은 지원하는 합의 방식을 사용하거나 직접 구현할 수 있는데, 이렇게 합의 방식을 선택할 수 있는 특성을 패브릭에서는 ‘교체 가능한 합의 프로토콜(Pluggable consensus)을 지원한다’고 한다.

프라이빗 블록체인에서는 어떤 네트워크 참여자가 어떤 권한을 가지는지 관리하는 것이 매우 중요한데, 그룹 별로 네트워크의 자원에 접근할 수 있는 권한은 관리자에 의해 정해져 Network Configuration에 저장된다. 또한, 이를 위해 참여자의 ID와 권한을 관리할 주체가 필요하므로, Certificate Authority(이하 CA)가 필요하다. 간단히 말해 CA는 디지털 증명서(Digital certificate)를 발급하는 기관이다. 패브릭 네트워크에 참여하는 그룹들은 모두 개별 CA를 이용하게 된다.

처음 네트워크를 구성하는 ‘그룹1’이 패브릭 네트워크를 구성한다고 하자. 해야할 일은 다음 순이다.

  1. Ordering service 구동 (Default)
  2. Network Configuration 설정
  3. Certificate Authority 설정

패브릭 네트워크에 다른 조직도 참여하고 네트워크 설정(Network configuration)을 변경할 수 있는 관리자 권한을 받을 수 있다. ‘그룹2’가 네트워크에 참여하고, 네트워크를 설정하는 관리 권한을 ‘그룹1’에게 받고 난 후의 네트워크 구조를 그림으로 나타내면 다음과 같다.

< 그림 1 >

<그림1>의 네트워크에서는 ‘그룹1’과 ‘그룹2’가 네트워크 설정을 변경할 수 있는 같은 권한을 가지며, Kafka 기반 오더링 서비스가 이용된다. Kafka 기반 오더링 서비스는 최소 4개의 노드를 가져야 Crash fault tolerance를 가지므로 4개의 노드를 표시했다. ‘그룹1’은 총 4개의 오더링 서비스 노드들을 운영한다. 현재 오더링 서비스 노드들은 단일 그룹에 속해야 한다. 추후에는 다른 그룹에 속한 노드들끼리도 오더링 서비스를 운영할 수 있도록 업데이트 할 예정이라고 한다.

(실제 Sample network를 구동하는 코드가 궁금하다면, 여기를 참조하기 바란다.)

컨소시엄(Consortium) 구성하기

이 다음으로 패브릭 네트워크를 구성하기 위해 할 일은 컨소시엄(Consortium)을 형성하는 일이다. 컨소시엄의 사전적 정의는 ‘함께 협력하기로 동의한 사람 또는 회사의 집단’이다. 하이퍼레져 패브릭에서는 조직들이 하나의 컨소시엄을 구성하면 그 조직들은 트랜잭션 내역을 공유할 수 있다. 따라서, 하이퍼레져 패브릭안의 컨소시엄은 ‘공동의 목표를 가지고 트랜잭션 내역을 공유하며 협력하는 집단’이라고 볼 수 있겠다. 하나의 네트워크에는 여러 컨소시엄이 존재할 수 있으며 어떤 그룹들이 어떤 컨소시엄을 이루는지는 네트워크 설정 안에 정의된다.

‘그룹3’이 이 네트워크에 참여하고, ‘그룹1’과 ‘그룹3’가 ‘컨소시엄1’을 구성했다고 하자.

이 네트워크를 그림으로 나타내면 다음과 같다.

< 그림 2 >

컨소시엄이 이용하는 채널 만들기

채널(Channel)은 하이퍼레져 패브릭에서 매우 중요한 컨소시엄 내 그룹간 커뮤니케이션 메커니즘이다. 채널은 데이터 분리(data isolation)와 기밀화를 가능케 하며, 채널용 장부(channel-specific ledger)는 채널 사용 허가를 받은 컨소시엄 멤버들만이 접근 가능하다.

네트워크 설정(Network Configuration)과 별개로 채널 설정(Channel configuration)이 존재하여, 채널 설정 정보에는 채널(Channel)에 접근할 수 있는 피어(peer)의 권한 정보등 채널 운영에 필요한 모든 정보를 담고있다. 채널 설정 정보는 블록에 담겨 장부에 기록된다. 채널(Channel)은 네트워크 안에 존재하지만 네트워크 설정(Network configuration)과 채널 설정 사이 중복되는 설정이 없으므로, 네트워크 설정이 변경되어도 채널 설정에 직접적인 영향은 없다. 프라이버시(Privacy)를 유지하며 효율적인 데이터 공유(data sharing)가 가능하게 만들기 때문에 채널은 퍼블릭 블록체인(Public blockchain)은 가지지 못하는 장점을 제공하는 중요한 기능이다. 한 네트워크 안에는 여러 컨소시엄들이 사용하는 채널들이 존재할 수 있다.

  • 장부(Ledger)

블록체인에서 장부란 ‘변경 불가능한 상태 데이터 베이스(immutable state database)’이다. 하이퍼레져 패브릭에서는 한 채널이 한 장부를 가진다. 이 장부를 물리적으로 호스팅 하는 노드들은 피어(Peer)라고 불리며, 한 채널 안의 여러 피어들이 한 장부의 복사본을 가진다. 장부의 업데이트는 여러 피어들의 합의(Consensus)를 통해 이루어지기 때문에 일관성을 유지할 수 있다.

  • 피어(Peer)

피어는 장부(Ledger)를 물리적으로 호스팅하고 Chaincode(하이퍼레져 패브릭의 smart contract)를 저장하고 있는 독립체(entity)이다. 피어는 CA로부터 Identity를 배정 받고 채널에 참여할 수 있다.

다음 순서로 네트워크를 발전시켜 보자.

  1. ‘그룹1’과 ‘그룹3’이 ‘채널1’을 만든다.
  2. ‘채널1’에는 장부도 없고, 이를 호스팅할 피어도 없으므로, ‘그룹1’의 ‘피어1’을 추가하자. 이를 위해서 ‘피어1’은 오더링 서비스에 참여 요청(join request)을 보내야한다. 그러면 오더링 서비스는 ‘채널1’의 설정을 확인하고 ‘피어1’에게 접근 권한을 준다. ‘피어1’이 접근 권한을 받고 나면 ‘피어1’은 ‘채널1’의 ‘장부1’을 호스팅한다.
  3. 같은 방식으로 ‘그룹3’의 ‘피어2’도 참여한다.

이제 이 네트워크를 그림으로 나타내면 다음과 같다.

< 그림 3 >
  • Smart Contract (Chaincode)

스마트 컨트랙트(Smart contract)는 장부에 저장된 상태(state)를 업데이트 하는 코드(code)이다. 하이퍼레져 패브릭에서는 체인코드(Chaincode)라고도 불리며, 패브릭은 체인코드 언어로 현재 Go와 node.js를 지원한다.

하이퍼레져 패브릭에서 체인코드를 사용하려면, 우선 피어 노드에 체인코드가 설치(install)되어야 한다. 피어에 체인코드를 설치하고 나면, 해당 피어는 그 체인코드의 구현 로직(implementation logic)을 담게 된다. 특정 채널을 호스팅 하는 모든 피어들에 같은 체인코드를 설치할 필요는 없으며, 몇 개의 피어들만 선택하여 체인코드를 설치할 수 있다.

하지만, 체인코드가 어떤 피어에 설치했다고 해서 바로 사용할 수 있는 것은 아니다. 그 피어가 호스팅 하는 채널에 연결된 다른 구성 요소들은 어떤 체인코드가 설치됐다는 사실을 알 수 없다. 그러므로 체인코드를 사용하려면 구현 로직이 아닌 해당 체인코드의 인터페이스(코드의 기능에 대한 규약. 코드 구현체는 이 인터페이스에 따라 구현된다.)를 다른 피어들에게 알리는 인스턴트화(Instantiated)가 필요하다. 인스턴트화는 ‘instantiate’ 명령어를 이용하여 이루어질 수 있으며, 샘플 코드는 여기를 참조하기 바란다.

이렇게 체인코드가 피어에 설치되고, 인스턴트화까지 이루어지고 나면 클라이언트 어플리케이션(Client application)에 의해서 체인코드가 호출(invoke)될 수 있다. 클라이언트 어플리케이션은 네트워크 외부에서 체인코드를 호출하고, 결과값을 전송 받을 수 있는 프로그램을 말한다.

일부 노드에만 체인코드의 구현 로직을 설치한다는 점은 기존의 퍼블릭 블록체인(여기서는 주로 이더리움)과 구분되는 차이점이다. 퍼블릭 블록체인에서는 모든 노드가 같은 스마트 컨트랙트(Smart contract)를 실행하고, 상호 검증하게 되므로 사용되는 시스템 구조는 결정적(Deterministic)이어야 했다. 여기서 ‘결정적’의 의미는 데이터베이스가 같을 때는 알고리즘에 어떤 특정 입력 값을 대입하면 항상 같은 출력 값을 출력하는 특성을 말한다. 만약 기존의 퍼블릭 블록체인의 시스템이 결정적이지 않고, 시스템 의존적인 요소를 사용한다면 상호 노드의 출력값이 달라 합의에 이를 수 없다.

또한, 기존의 퍼블릭 블록체인의 시스템에서는 보안을 위해 여러 기능(Network access,I/O stream, File W/R등)이 제한되어야 했다. 따라서, 이더리움이 개발될 때도 이미 여러 훌륭한 프로그래밍 언어가 시중에 존재함에도 굳이 솔리디티(Solidity)라는 스마트 컨트랙트(Smart contract)용 제한적인 언어를 개빈 우드(Gavin wood)가 제안한 것이다. 하지만, 하이퍼레져 패브릭에서는 일부 노드만 체인코드를 실행하고 결과값을 네트워크에 전파하기 때문에 프로그래밍 언어가 꼭 결정적일 필요는 없다. 또, 무한루프등의 문제가 발생해도 영향은 일부 노드로 제한되며, 그 노드는 실행을 종료할 수 있기 때문에 프로그래밍 언어 선택시 퍼블릭 블록체인만큼 엄격할 필요가 없다.

패브릭은 일부 노드에서만 체인코드를 실행하므로 병렬적으로 트랜잭션을 처리할 수 있다는 장점도 있다. 이는 기존의 퍼블릭 블록체인보다 트랜잭션 처리 속도면에서 훨씬 좋은 성능을 낼 수 있게 만든다. 그렇다고 어떤 노드에서 실행한 체인코드의 결과값을 다른 노드가 전혀 검증하지 않는 것은 아니다. 이 결과값은 여러 노드에 의해 검증될 수 있으며, 그 방법은 해당 체인코드의 보증 정책(Endorsing policies)에 따라 결정이 된다. 보증 정책이란 어떤 체인코드가 장부를 업데이트하기 위해 몇 개의 서명(sign)이 필요한지를 명시해 놓은 조건이다. 예를 들어, 체인코드A는 멤버1과 멤버2 둘의 서명이 모두 필요하다고 할 때, 체인코드A를 실행하면 멤버1과 멤버2에게 모두 요청이 간다. 그러면 요청이 문제가 없는지 멤버1,2는 확인하고 체인코드를 실행한 후, 두 값이 같은 때만 장부(ledger)를 업데이트한다.

< 그림 4 > (출처 링크)

다음 순서로 초기 네트워크를 완성하자.

  1. ‘피어1’에 ‘체인코드1’을 설치한다.
  2. ‘피어2’에 ‘체인코드1’를 설치한다. (피어1의 체인코드에 사용된 언어와 다른 프로그래밍 언어를 써도 된다. 결과값만 똑같이 출력하면 된다.)
  3. ‘체인코드1’을 인스턴트화(instantiate)한다.

초기 네트워크 구성 완료

구성이 완료된 간단한 네트워크의 모습을 그림으로 나타내면 다음과 같다.

< 그림 5 >

이 네트워크를 구성하는 요소를 정리해보면 다음과 같다.

  • 그룹 또는 조직(Group or organization)
  • 오더링 서비스 노드들 (Ordering service nodes)
  • CA(Certificate Authority)
  • 컨소시엄(Consortium)
  • 채널(Channel)
  • 채널 설정(Channel configuration)
  • 장부(Ledger)
  • 피어(Peer)
  • 클라이언트 어플리케이션(Client application)

위의 요소들은 모두 하나 또는 여러 개가 네트워크에 존재할 수 있으며, 각 요소들은 추가되어 네트워크를 확장할 수 있다. 이렇게 구성된 네트워크에서 트랜잭션을 처리해보면서, 패브릭 네트워크가 어떻게 동작되는지 살펴보자.

트랜잭션 처리 과정

하이퍼레져 패브릭에서는 아래와 같은 순으로 트랜잭션이 일어난다.

  1. 클라이언트 어플리케이션에서 SDK를 통해 트랜잭션 제안(transaction proposal)을 발생시킨다.
  2. 체인코드의 보증 정책(endorsing policy)에 명시된 노드들(endorsing peers)은 체인코드를 실행한다.
  3. 각 결과값은 클라이언트 어플리케이션에 전달된다.
  4. 결과값이 보증 정책을 만족시키면, 결과값은 오더링 서비스(ordering service)에 전달된다.
  5. 오더링 서비스는 먼저 도착한 순으로 블록을 만들어 채널의 모든 피어들에게 전달한다.
  6. 모든 피어는 도착한 블록이 보증 정책을 만족시키는지, 장부 상태(ledger state)가 트랜잭션이 일어나는 동안 바뀌지 않았는지 확인한다.
  7. 각 피어들은 블록을 채널의 체인에 덧붙이며, 장부의 상태를 업데이트 한다.

여기까지 하이퍼레져 패브릭의 초기 네트워크를 간단히 구성하고, 트랜잭션이 어떻게 발생하는지 알아보았다. 이 글을 통해 패브릭 네트워크 구조에 대한 기본 개념을 이해하고, 패브릭은 어떤 특징들을 가지는지 이해할 수 있었기를 바란다. 이 글에서 퍼블릭 블록체인과 프라이빗 블록체인인 패브릭을 비교하며 서술을 많이 했지만, 어느 쪽이 더 낫다고 말하기 위해 쓴 글은 아니다. 두 블록체인은 쓰임새가 다르며, 장단점이 다르기 때문이다. 앞으로 각 분야에서 필요한 곳에 퍼블릭 블록체인과 프라이빗 블록체인이 적절히 사용되길 기대한다.

작성자 이메일 : universale0723@gmail.com



반응형
반응형

출처: 안상욱님 페이스북


이 글은 '비트코인 코어' 개발자 Mike Hearn이 2016년 1월14일 미디움에 올린 The resolution of the Bitcoin experiment를 번역한 겁니다. 읽기 쉽게 의역한 부분 많습니다. 문맥을 고려해도 틀린 부분이 있으면 댓글 달아주세요. 
나는 5년 넘게 비트코인 개발자로 일했다. 내가 작성한 비트코인이라는 소프트웨어는 수백 만 명에 달하는 사용자와 수백 명의 개발자가 사용했다. 내 말 한마디가 몇몇 스타트업의 탄생으로 직결되기도 했다. 나는 Sky TV와 BBC 뉴스에서 비트코인을 주제로 이야기했다. 나는 <이코노미스트>지에 종종 비트코인 전문가이자 주요 개발자로 인용됐다. 나는 SEC(미국 증권거래위원회)와 은행가, 카페에서 만난 일반인에게 비트코인을 설명했다.
처음부터 나는 언제나 같은 말을 했다. 비트코인은 일개 실험이고, 다른 모든 실험이 그렇듯, 비트코인 역시 실패할 수 있다. 그러니 손실을 입어선 안 되는 자산을 함부로 투자하지 말라고 말이다. 인터뷰에서도, 콘퍼런스 발표에서도, 이메일에서도 이 말을 반복했다. Gavin Andresen과 Jeff Garzik 같은 다른 유명 개발자도 같았다.
그러나 비트코인이 실패할 수 있다는 가능성을 알고 있었다고 할지라도, 지금 당장 비트코인이 망해가고 있다는 불가피한 결론이 나를 큰 슬픔으로 몰아넣는다. 비트코인의 기초가 무너졌다. 단기적으로 가격이 어떻게 변할지 몰라도, 장기적으로는 내리막길을 걸을 거다. 내가 가진 비트코인을 모두 처분하고 나는 비트코인 개발에서 손 떼려 한다.
왜 비트코인이 실패했는가? 비트코인 커뮤니티가 실패했기 때문이다. 비트코인이라는 새로운 분산된 화폐가 지닌 두 가지 특성, 구조적으로 몇몇 주요 기관에 의존하지 않고 ‘대마불사’ 논리에서 벗어났다는 점이 오히려 더 심각한 문제를 낳았다. 비트코인 시스템은 한 손에 꼽을 만큼 적은 사람에게 장악 당했다. 더 나쁜 점은 비트코인 네트워크가 기술적으로 붕괴하기 일보 직전이라는 점이다. 이런 결과를 예방해야 할 매커니즘은 망가져버렸다. 그 결과, 비트코인이 기존 금융 시스템보다 낫다고 여길 이유가 사라졌다.
생각해보자. 비트코인을 전혀 들어본 적 없다면, 아래와 같은 결제 네트워크를 생각해보라. 이런 결제 시스템을 믿을 수 있겠는가?
  • 지금 가진 돈을 옮길 수 없다
  • 높은 수수료를 물어야하는데, 수수료율을 예측할 수 없으며 심지어 빠르게 증가한다
  • 구매자가 물건을 들고 가게 문을 나선 뒤에 단추 한 번만 누르면 결제를 취소할 수 있다(당신이 이 ‘기능'을 모른다고 해도 상관 없다. 비트코인이 이를 허용하도록 바꾸기만 하면 그만이다)
  • 거대한 백로그(backlogs)와 신뢰할 수 없는 결제에 시달린다
  • 중국이 통제한다
  • 이를 개발 중인 회사와 사람들이 내전을 벌인다
내가 감히 예측컨데 답은 ‘아니오'다.

교착상태가 코 앞에 닥쳤다

비트코인 생태계가 어떻게 변해왔는지 잘 모르는 분들을 위해 2016년 1월 비트코인 네트워크가 어떤 모습인지 잠깐 살펴보자.
비트코인 블록체인은 가득찼다. 여러 파일의 묶음인 블록체인이 어떻게 ‘가득 차'는지 궁금하겠지. 답은 간단하다. 순전히 임의로 만든 블록당 1MB라는 저장공간이 가득찼다는 얘기다. 먼 옛날에 거칠게 만들어둔 용량 제한이 지금껏 제거되지 않았다. 그 결과 지금 비트코인 블록체인 네트워크의 용량은 거의 고갈됐다.
여기 블록 크기 그래프를 살펴봐라.
지난 6월 누군가 비트코인 네트워크를 공격하기 위해 거래를 폭증시켰던 분산서비스거부(DDoS) 공격 와중에 비트코인 블록체인은 한계점을 찍었다. 이런 걸 ‘스트레스 테스트'라고 부른다. 당시 약 700KB 정도의 거래 (또는 초당 3회 이하 결제)가 이뤄졌다. 이를 비트코인이 실제로 처리할 수 있는 거래량의 한계라고 봐도 무방하겠다.
주의: 어디선가 초당 7회 거래가 비트코인의 한계라고 읽었을지도 모르겠다. 초당 7회라는 숫자는 2011년께 나온 오래된 수치다. 비트코인 거래는 그때보다 훨씬 더 복잡해졌다. 그래서 실제 수치는 훨씬 낮다.
실제 한계가 이론적 한계인 1000KB가 아니라 700KB인 까닭은 승인 대기 중인 거래가 쌓여 있음에도 불구하고 채굴자가 종종 허용된 것보다 작은, 심지어 빈 블록을 만들어내기 때문이다. 이런 문제는 중국의 ‘만리장성' 방화벽의 검열 시스템이 데이터 전송을 방해하기 때문으로 보인다. 게다가 1초 안에 처리해야 하지 않나
자세히 들여다보면 트래픽이 2015년 여름 끝자락부터 계속 증가하는 모습이 보일 거다. 이건 예견된 바다. 지난해 3월에 나는 비트코인의 계절적 성장 패턴에 관한 글을 썼다.
주간 평균 블록 사이즈를 보자:
평균 블록 크기가 거의 한계에 다달았다. 당연히도 블록 크기가 한계에 달했기 때문에 비트코인이 거래 요청을 처리하지 못하는 구간이 빈번하게 나타났다. 심지어 승인을 기다리는 거래 내역이 줄지어 설 때도 있었다. 이런 상황은 아래 블록 크기 표에서 잘 드러난다. (채굴자가 제시한 750KB 크기 블록들은 그들의 소프트웨어에서 제대로 조정되지 않은 것이다):
처리 용량이 바닥난 네트워크는 신뢰할 수 없게 된다. 수많은 온라인 공격이 그저 대상 컴퓨터에 트래픽을 쏟아붇는 단순한 수법을 택하는 이유다. 비트코인 네트워크는 크리스마스부터 거래량이 늘어나 불안해지기 시작했다. 피크 타임에 거래 승인이 밀리는 일은 이제 일상이 됐다.
비트코인 기반 사업을 벌이는 ProHashing의 뉴스 한 건을 인용한다:
몇몇 고객이 오늘 아침 Chris에게 비트코인 결제가 실행되지 않는 이유를 물었다...
이 문제는 이런 뜻이다. 이제 공식적으로 비트코인 네트워크를 신뢰하는 게 불가능해졌다. 통해 거래가 제대로 처리될지, 언제쯤 처리될지 알 수 없기 때문이다. 네트워크가 너무 혼잡하기 때문에 거래량이 조금만 치솟아도 네트워크 상태에 지대한 영향을 미칠 지경이다. 60분에서 14시간 사이 무작위로 거래가 승인될테니 기다리라는 말을 받아들일 수 있는 사람이 있을까?
레딧에 사람들이 ‘위기는 없다’는 게시물을 올리는 사실이 우스꽝스럽다. 사람들은 내가 어떤 연유에서든 사태의 심각성을 과장했다며 내가 어제 올린 포스트를 비판한다. 그런 사람들이 과연 매일 같이 돈을 보내려고 비트코인 네트워크를 쓰기는 할까?
ProHashing은 크리스마스와 새해 사이에 거래 내역을 잃어버릴 뻔했다. 이번에는 비트코인 거래소에서 자사 전자지갑으로 송금이 지연됐다.
비트코인은 이런 상황이 생길 경우 자동으로 우선 순위를 조정하도록 설계돼 있다. 송금 수수료를 올려 수수료를 안 내는 사용자보다 우선해 거래를 처리하도록 하는 거다.하지만 이런 문제가 계속 발생하는 사실을 보면 이런 매커니즘이 효과가 없는 것으로 보인다. 그러면 비트코인 네트워크의 거래 비용만 급속도로 증가할 거다. 한 때 비트코인은 낮은 수수료, 심지어 수수료를 물지 않는 거래를 큰 장점으로 여겼다. 하지만 채굴자에게 내는 수수료가 신용카드 수수료를 초과하는 일이 점점 빈번해진다.
왜 블록 용량을 키우지 않았을까? 중국 채굴자가비트코인 블록체인을 장악했기 때문이다. 이들 중 두 명이 50%가 넘는 해시 파워를 좌지우지한다. 최근 한 콘퍼런스에서 동시에 무대 위에 오른 몇몇 사람이 전체의 95%가 넘는 해시 파워를 갖고 있었다. 이들이 블록체인의 성장을 허용하지 않는다.
왜 이들은 블록 용량을 키우는 데 반대하는가? 몇 가지 이유가 있다. 첫 번째는 ‘비트코인 코어' 소프트웨어를 만드는 개발자들이 필수적인 변화를 도입하기를 거부해왔기 때문이다. 또 다른 이유는 채굴자가 변화를 거부하기 때문이다. 그들의 관점에서는 기존과 다른 블록체인을 도입하는 일이 ‘반역'이다. 이들은 새로운 블록체인이 형성돼 ‘쪼개져' 나가면 투자자가 겁에 질릴까 두려워 한다. 이들은 현재 문제를 무시하고 지금 이대로 현상을 유지하는 쪽을 택했다.
마지막 이유는 중국 인터넷이다. 중국 인터넷은 정부의 검열망 때문에 사실상 인터넷에서 분리돼 있다. 따라서 국제 인터넷망과 데이터를 교환하는 일이 제대로 실행되지 않는다. 인터넷 속도가 모바일 인터넷보다 느려지는 일이 다반사다. 전국의 인터넷망이 싸구려 호텔 와이파이보다 느려진 와중에 사진을 전송받는다고 상상해보라. 바로 지금, 중국 채굴자가 매 블록을 만들때 마다 보상으로 주어지는 1만1000달러어치 비트코인 25개를 차지하려고 자기 네트워크를 국제 인터넷망과 맞물려 놓으려 안간힘을 쓰고 있다. 이들은 비트코인 네트워크가 더 인기를 얻을 경우 채굴 난이도가 높아져 소득원을 잃어버릴까봐 두려워 한다. 이런 경제적 인센티브가 중국 채굴자가 비트코인이 더 대중적으로 되는 것을 가로막는 이유다.
많은 비트코인 사용자와 구경꾼이 이 지경에 이르기 직전까지도 이런 문제가 어떻게든 해결되리라 짐작했다. 블록체인 용량 제한도 당연히 증가됐으리라 여겼다. 결국, 한때 블록체인을 금융의 미래상으로 부각시켰던 비트코인 커뮤니티가 블록체인을 유아기에 옭아매려 의도적으로 자살하는 길을 택한 걸까? 믿기 어렵겠지만 바로 이것이 지금 벌어지는 일이다.
내전이 벌어진 결과, 미국에서 가장 크고 잘 알려진 비트코인 스타트업 코인베이스는 비트코인 공식 웹사이트에서 삭제됐다. 줄을 잘못 섰기 때문이다. 비트코인 커뮤니티 포럼에서도 추방당했다. 커뮤니티의 일부가 수백 만 명에게 비트코인이라는 화폐를 소개했던 사람들을 무자비하게 기습할 때 무슨 일이 일어날 지는 불 보듯 뻔하다. 만사가 미쳐 돌아가겠지.

무슨 일이 일어나는지 아무도 모른다

당신이 어린 일을 들어보지 못했다고 자책하지는 마라. 당신 만이 아니다. 2015년부터 지금껏 벌어진 일 가운데 가장 신경쓰이는 일은 투자자와 사용자에게 전달되던 정보가 매말랐다는 것이다.
8개월도 안 되는 기간에 비트코인은 투명하고 개방적인 커뮤니티에서 검열이 난무하고 비트코이너끼리 서로 공격하는 무간지옥으로 전락했다. 이런 변화는 내가 지금껏 경험한 어떤 일보다도 끔찍하다. 그래서 나는 비트코인 커뮤니티와 연관된 일을 하는 것이 불편해졌다.
비트코인은 투자수단으로 만들어지지 않았다. 손실을 감내할 수 없을 정도로 투자해선 안 될 실험적인 화폐였다. 이 점은 언제나 명확하게 설명돼 왔다. 나는 비트코인의 복잡성을 걱정하지는 않았다. 투자자에게 필요한 정보가 충분하기 때문이다. 가내 수공업으로 만든 책을 비롯해 콘퍼런스, 동영상, 웹사이트가 사람들이 비트코인을 깊이 이해할 만큼 충분하다.
하지만 이제 상황이 달라졌다.
비트코인 소지자 대다수는 주류 미디어에서 정보를 얻는다. 비트코인 가격이 치솟을 때마다 언론은 가격 상승 소식을 전했다. 그러면 거품이 생겼다.
비트코인 뉴스가 신문과 잡지까지 도달하는 과정은 단순하다: 커뮤니티 포럼에서 뉴스가 태어난다. 그럼 이 뉴스가 더 전문화된 커뮤니티나 기술 뉴스 웹사이트로 전파된다. 이때 종합지 기자가 이 뉴스를 포착하고 자기 버전으로 가공한다. 나는 이런 일이 계속 일어나는 걸 목격했다. 종종 기자와 뉴스를 두고 토론을 벌임으로써 내가 뉴스의 일부가 되기도 했다.
2015년 8월 심각한 경영상 문제 때문에 비트코인 P2P 네트워크를 작동시키는 프로그램을 유지보수하는 ‘Bitcoin Core' 프로젝트가 블록 크기를 늘리는 버전을 배포하지 않으리라는 사실이 확실해졌다. 그 이유는 복잡하니 아래 따로 논의하자. 하지만 분명한 점은 커뮤니티가 새로운 사용자를 계속 확보할 능력이 필요했다는 점이다. 그래서 (나를 포함해) 오랫동안 비트코인을 만져온 개발자는 한데 모여 블록 크기를 키우는데 필요한 코드를 작성했다. BIP101다. 우리는 이 수정안을 비트코인 기본 지갑(Bitcoin XT)에 반영해 배포했다. 우리가 판올림한 비트코인 기본 지갑을 채택함으로써 채굴자는 블록 크기를 늘리는데 동의할 수 있었다. 채굴자 가운데 75%가 블록 크기를 늘리는 데 동의하면 이것이 정론으로 채택될 수 있었다.
어떤 이유에서인지 Bitcoin XT 배포는 몇몇 사람의 심기를 매우 불편하게 만들었다. 그 중 한 사람은 bitcoin.org와 가장 큰 비트코인 포럼의 관리자였다. 그는 표현의 자유라는 미명하에 종종 그가 관리하는 포럼에서 불법 활동을 논의하도록 묵인하곤 했다. 그러나 XT가 나왔을 때, 그는 놀라운 결정을 내렸다. 그는 XT가 ‘개발자의 합의'를 대표하지 않는다며 진짜 비트코인이 아니라고 주장했다. 그는 투표가 기형적인 일이라고 말했다. 아래 같은 이유를 들면서 말이다.
“민주주의의 부재야말로 비트코인의 가장 위대한 속성 중 하나다”
그래서 그는 XT를 완전히 죽이기 위해 어떤 일이든 불사하겠다고 마음 먹었다. 비트코인 주요 커뮤니케이션 채널을 검열하는데서 시작했다. 그가 관리하는 토론 포럼에서 ‘Bitcoin XT’를 거론하는 글은 모두 삭제됐다. XT는 공식 bitcoin.org 웹사이트 어디에도 언급되거나 링크될 수 없었다. 이런 검열이 일어나지 않는 다른 포럼을 일러주려던 사용자는 당연히도 차단당했다. 수많은 사용자가 포럼에서 추방당해 자신의 견해를 표현할 권리를 빼앗겼다.
결국 몇몇 사용자는 검열당하지 않는 새 포럼을 찾아 나섰다. 이 포럼을 읽어 내려가면 서글퍼진다. 지난 몇 달 동안 나는 매일 같이 이들이 물리쳤을 검열과 복종에 분개하는 게시물을 봤다.
하지만 XT나 검열에 관한 소식을 접할 수 없다는 사실 자체가 사용자에게 문제를 야기했다.
사상 처음으로 투자자는 지금 무슨 일이 일어나는지 확실히 알아낼 길을 잃어버렸다. 다른 의견은 체계적으로 묵살당했다. Bitcoin Core가 무슨 역할을 하는지 기술적으로 논의하는 일마저 금지당했다. 그 자리는 괴상한 논리가 차지했다. 그리고 비트코인 붐에 휩쓸려 가볍게 뛰어든 많은 사람들은 비트코인 시스템이 한계에 치닫는다는 사실을 모름이 분명했다.
이 때문에 나는 상당히 걱정했다. 수 년 동안 정부는 채권과 투자 시장 주변에 수많은 법을 만들었다. 비트코인은 채권이 아니다. 나는 비트코인이 그런 법에 구애받으리라 믿지 않는다. 정부 당국의 정신은 간단 명료하다: 반드시 투자자에게 충분한 정보를 전달하라는 것이다. 만일 제대로 설명받지 못한 투자자가 투자액을 잃으면, 곧바로 정부의 눈총이 뒤따른다.

왜 비트코인 코어에 한계를 만드는가

(주: 박태민 (TaeMin Park)님이 이 부분 번역에 도움 주셨습니다)
사람이 문제다.
Satoshi가 비트코인에서 손을 뗄 때, 그는 지금 Bitcoin Core라 불리는 프로그램의 관리 권한을 초기 기여자인 Gavin Andresen한테 넘겼다. Gavin은 큰 그림을 볼 줄 아는 단호하고, 경험 많은 리더다. 그의 기술적 판단력을 믿었기에 나는 거의 8년 동안 일했던 구글에서 나올 용기를 얻었다. 단 하나의 문제가 있었다. 그리 큰 문제는 아니었다. Satoshi는 Gavin한테 그 일을 하고 싶냐고 묻지 않았다. 사실 Gavin은 원치 않았다. 그래서 Gavin은 첫 번째 개발자 4명에게 코드 접근 권한을 나눠줬다. 이 개발자 명단은 순식간에 추려졌다. Gavin에게 어떤 일들이 생기더라도 비트코인 개발 프로젝트가 무난히 계속 진행될 수 있도록 하기 위한 조치였다. 근본적으로 이들이 선택된 이유는 당시 주변에 있던 쓸모 있는 사람이었기 때문이다.
그들 중 한 명인 Gregory Maxwell은 별난 시각을 지녔다. 그는 비트코인이 수학적으로 불가능하다고 주장했다. 더 문제는 따로 있다. 그는 Satoshi가 제시한 이상을 믿지 않았다.
비트코인 프로젝트를 처음 발표했을 때 Satoshi는 블록체인이 어떻게 대량 결제를 버티도록 확장될 수 있는지 질문 받았다. 당연히 비트코인이라는 아이디어가 먹혀들기 시작하면 내려받아야 하는 데이터 양이 넘칠 수도 있잖나. 이건 비트코인 초창기의 유명한 비판이었다. Satoshi는 이 질문에 완전히 준비된 답을 내놓았다. 그는 이렇게 말했다:
대역폭이 당신이 생각하는것 만큼 제한되어 있지 않을 수도 있다. 만약 네트워크가 [VISA만큼 커진다면] 몇 년 걸릴지도 모른다. 그리고 그 때 인터넷으로 HD 영화 두 편을 전송하는 것과 맞먹는 일은 별로 큰 일이 아닐 것으로 보인다.
이건 간단한 논쟁이다. 현존하는 결제 네트워크가 거래를 어떻게 처리하는지 보고 비트코인이 이런 일을 따라하려면 무엇이 필요한지 보라는 거다. 그리고 네트워크의 성장은 하룻밤 사이에 일어나지 않는다는 사실을 꼬집는 지적이다. 미래의 네트워크와 컴퓨터는 지금보다 발전돼 있겠지. 사실 봉투의 뒷면 계산법(back-of-envelope calculation)이 이런 점을 암시했다. 그는 대역폭 뿐 아니라 다른 많은 요소를 종합해 봐도 “절대 한계점에 부딪히지 않을 거야”라고 나에게 말했다.
Maxwell은 이런 생각에 동의하지 않았다. 2014년 12월 한 인터뷰에서 발췌했다:
Maxsell은 비트코인이 성장해도 분산에 관한 문제는 줄어들지 않을 것이라고 지적했다. “네트워크의 거래량을 논할 때 확장성과 분산성은 내재적으로 상충합니다.”
그는 "문제는 비트코인의 거래량이 증가할수록, 고유 비용 때문에 더 큰 회사들이 비트코인 노드를 운영하는 유일한 업체들이 될 것이다”라고 지적했다.
이런 생각에 따르면, 비트코인이라는 아이디어는 망할 운명을 타고 태어났다. 사용자가 많아진다는 것은 곧 분산도가 떨어진다는 의미다. 이건 네트워크에 위험한 일이다. 이 문제는 실용적 사용의 비율이 낮고 성장이 느리지만 기술이 시간이 지남에 따라 발전한다는 사실을 무시한다. 이 주장을 반박하는데 나와 Gavin은 시간을 많이 쏟아부었다. 이로서 당연하지만 미친 결론이 나온다: 만약 분산이 비트코인을 이롭게 만드는 요소이고 성장이 분산을 위협한다면, 비트코인은 성장하면 안 된다.
대신 Maxwell이 결론지었듯 비트코인은 지금 같이 블록체인 기반 시스템이 아니라 모호하게 정의된 정산 레이어 같은 것이 돼야 한다.

개미지옥에 빠져들다

일개 회사라면 조직의 목표에 동의하지 않는 사람은 간단히 처리된다. 해고하면 그만이다.
하지만 비트코인 코어는 회사가 아니라 오픈 소스 프로젝트다. Gavin이 개발자 5명에게 코드를 수정할 권한을 내주고 리더가 되지 않겠다고 결심한 뒤로 이들 중 누구를 내치려는 조치가 발현된 적은 없었다. 비트코인 코어 개발진을 꾸릴 때 이들이 프로젝트의 목표에 동의하는지 확인하는 면접 같은 조치도 없었다.
비트코인이 인기를 얻어 트래픽이 1MB 한계에 육박함에 따라 개발자 사이에선 블록 크기 제한을 키워야 한다는 논의가 종종 벌어졌다. 하지만 이런 논쟁은 금방 감정적으로 변질됐다. 블록 크기를 늘리면 분산화라는 가치를 거스르기 때문에 위험하다는 지적이 잇따랐다. 다른 조그마한 집단과 마찬가지로 사람들은 충돌을 피하는 쪽을 택했다. 깡통을 길 밖으로 내던졌다.
Maxwell이 다른 개발자 몇 명을 고용해 자기 회사를 세우자 복잡한 일은 날이 한층 더 꼬였다. 당연히도 이들의 견해는 새 사장과 궤를 같이 했다.
공동으로 관리하는 소프트웨어를 판올림하는 일은 시간이 걸린다. 그래서 Gavin은 아직 8개월이 남은 시점인 지난 2015년 5월, 이 문제를 단박에 정면돌파해야 한다고 결심했다. 그는 블록 용량 확대에 반대하는 의견에 일일히 반박하는 글을 작성하기 시작했다.
하지만 이 문제가 불거짐에 따라 Bitcoin Core 개발진은 속절 없이 구설수에 올랐다. Maxwell과 휘하 개발자는 블록 용량 확대를 생각하는 일조차 무차별적으로 반대했다. 이 주제를 애초에 입 밖으로 낼 생각도 없었다. 이들은 ‘합의' 없이는 어떤 일도 결정해선 안 된다고 고집을 피웠다. 블록 용량을 키운 비트코인 코인 새 버전을 만들어야 할 개발자들은 승자와 패자가 갈릴 수 밖에 없는 갈등에 연관되기를 두려워했다.
이런 연유로, 거래소와 사용자와 지갑 개발자와 채굴자 등 모든 업계 관계자가 블록 용량이 늘어나리라 짐작하는 와중에도 코어 개발자 5명 가운데 3명은 블록 용량에 손대길 거부했다.
교착상태다.
이런 상황에도 시간은 성실하게 흘러갔다.

XT 사용자를 노린 대규모 DDoS 공격

정보망이 차단됐지만 Bitcoin XT는 발표된 뒤 며칠새 전체 네트워크 노드 가운데 15%에게 채택됐다. 마이닝풀 가운데 최소한 한 곳은 BIP101에 동의하는지 채굴자 사이에 투표를 부쳤다.
바로 이 때 분산서비스거부(DDoS) 공격이 시작됐다. 이 공격은 일대 인터넷을 마비시킬 정도로 강력했다.
“나는 DDoS 공격을 당했어요. 이 대규모 DDoS 공격은 내가 속한 (지역) ISP 전체를 무너뜨렸습니다. 이 범죄자들 때문에 지난 여름 다섯 마을 주민들이 몇 시간 동안 인터넷을 쓰지 못했어요. 이것이 내가 비트코인 노드 호스팅을 중단한 결정적인 이유입니다.”
데이터센터가 통째로 차단당한 사례도 있다. 그 데이터센터 안에서 작동하던 XT 노드 한 곳이 작동을 중단하기 전까지 공격이 계속됐다. 대략 3분의 1 정도 되는 노드가 이런 방식으로 공격당해 인터넷에서 제거 당했다.
심하게는 BIP101 수정안을 채택한 한 마이닝풀이 공격당해 운영을 멈추기도 했다. 메시지는 분명하다. 블록 용량 확대안을 지지하거나, 사용자에게 동의 여부를 묻기만 해도 공격당하리라는 것이다.
가해자들은 여전히 바깥을 활보한다. XT가 발표된 뒤 몇 달 뒤 코인베이스가 비트코인 코어 개발진을 기다리다 지쳤다며 XT를 가동할 것이라고 발표했다. 코인베이스 역시 한동안 DDoS 공격에 시달려 인터넷에서 격리당했다.

짝퉁 콘퍼런스

DDoS 공격과 검열이 공공연하게 벌어지고 있는데도 XT는 추진력을 얻어갔다. 이런 움직임은 Bitcoin Core에 위협을 가할 지도 모를 일이었다. 그래서 몇몇 개발자는 ‘비트코인 확대(Scaling Bitcoin)’라는 이름으로 콘퍼런스를 잇따라 개최하기로 결정했다. 8월과 12월이었다. 이들은 필수불가결한 ‘합의'에 도달하는 것이 콘퍼런스의 목표라고 주장했다. 전문가 사이에서 나온 합의를 싫어할 사람은 없을 거다. 안 그런가?
나는 이들을 보자마자 방해공작에 불과하다고 확신했다. 지금껏 블록 용량 확대를 언급하기조차 꺼리던 사람들이 콘퍼런스에 참가한다고 마음을 바꿀 리는 없기 때문이다. 더군다나 이 콘퍼런스는 네트워크 업그레이드에 쓸 시간도 몇 달도 안 남은 겨울 초입에 시작됐다. 마냥 콘퍼런스가 열리길 기다리며 소중한 몇 개월을 흘려버리는 일은 전체 비트코인 네트워크의 안정성을 위협하는 짓이었다. 사실 첫 번째 콘퍼런스는 쓸데없었다. 구체적인 제안을 논의하는 게 금지당했기 때문이다.
그래서 나는 안 갔다.
불행히도 이 전술은 굉장한 효과를 거뒀다. 비트코인 커뮤니티가 완전히 이들 손아귀에 놀아났다. 채굴자나 스타트업과 얘기하면 XT를 가동하지 않는 이유로 보통 “Core 개발진이 12월에 용량을 확대하기를 기다리기 때문"이라고 답했다. 이들은 커뮤니티가 분열됐다는 뉴스를 접할 때마다 비트코인 시세가 떨어질까봐 전전긍긍했다. 비트코인 가격이 결국 이들의 밥줄이잖나.
마지막 콘퍼런스가 용량 제한을 확대할 어떤 계획도 제시하지 않고 왔다 갔다. 코인베이스나 BTCC 같은 몇몇 회사가 자신들이 놀아났다는 사실을 깨달았다. 그러나 너무 늦은 뒤였다. 커뮤니티가 기다리는 동안 일일 거래량은 자연스레 25만 건이 늘어났다.

무계획

블록 크기 증가에 찬성하는 두 Bitcoin Core 개발자 Jeff Garzik과 Gavin Andresen은 커뮤니티 안에서 대단한 영향력을 행사했다. 이들은 가장 오랫동안 Bitcoin Core 개발에 기여해온 사람이기도 하다. 두 사람은 얼마 전 함께 “비트코인은 합의를 향한 급행열차에 올랐다(Bitcoin is Being Hot-Wired for Settlement)"라는 게시물을 작성했다.
Jeff와 Gavin은 보통 나보다 부드럽게 의견을 개진한다. 나는 내가 본 대로 말하는 성격이지만 Gavin은 섬세하고 우직한 편이다. 그래서 이들이 함께 쓴 게시물에서 보이는 강한 어조는 이례적이다. 두 사람은 누구를 향해 주먹을 내지르지는 않았다.
지금 비트코인 커뮤니티에서 갑론을박하는 로드맵에도 일리는 있다. 더 많은 거래량을 처리할 계획도 들어 있다. 하지만 이건 중대한 단점을 충분히 설명하고 인정하지 못한다.
Bitcoin Core 블록 크기는 변하지 않는다; 이 지점에는 전혀 논란의 여지가 없다.
이상적이고 투명한 오픈 소스 환경이라면 BIP가 세상에 나왔겠지만, 이런 일은 일어나지 않았다.
Scaling Bitcoin 워크숍의 대외명분 중 하나는 혼란스러운 코어 블록 크기 논란을 질서정연한 의사 결정 과정으로 정리해내는 것이다. 이런 일은 벌어지지 않았다. 뒤돌아보니 ‘Scaling Bitcoin은 블록 크기 결정을 지연시키기만 했다. 그 와중에 거래 수수료는 계속 치솟고, 블록 용량은 고갈됐다.
이들이 지적한 대로 논점을 흐리는 일은 점점 더 보편화됐다. 예를 들어 Gavin과 Jeff가 언급한 계획은 Scaling Bitcoin 콘퍼런스에서 발표됐다. 하지만 더 효율성을 끌어올리지는 못했다. 겨우 (각 거래에서 몇 바이트를 세지 않는 식으로) 회계적 꼼수를 동원해 60% 용량을 확보하는 게 다였다. 이것도 한참 모자라지만. 게다가 이 제안을 따르려면 엄청난 변화가 뒤따라야 한다. 비트코인 관련 소프트웨어를 한올한올 뜯어 고쳐야만 하기 때문이다. 용량 한계를 끌어올리는 단순한 작업 대신 대규모 협력이 뒤따라야 하는 엄청나게 복잡한 일을 하는 쪽을 택한 거다. 기껏해야 몇 달밖에 버티지 못할 미봉책인데도 말이지.

수수료를 대체하다

수수료로 트래픽을 통제하는 방식의 한 가지 문제가 있다. 거래 당시 수수료와 결제가 끝나는 시점에 수수료가 달라질 수 있다는 점이다. Bitcoin Core에는 이 문제를 풀어낼 기막힌 해법이 있다. 블록체인에 각인되기 전까지는 사용자가 결제건을 수정할 수 있도록 하는 것이다. 대외적 의도는 사용자가 이미 지불한 수수료를 조정할 수 있도록 하는 것이지만, 이런 기능은 사용자가 결제 자체를 무를 수 있도록 한다.
한눈에 봐도 이러면 비트코인은 물건을 사는데 쓸 수가 없어진다. 결제 내역이 블록체인에 나타나기 전까지 기다려야만 한다. 지금 과다한 트래픽 때문에 몇 분이 아니라 몇 시간도 걸리는 바로 이 일을 말이다.
Bitcoin Core 개발팀은 이 기능을 이렇게 정당화한다. 이건 큰 문제가 아니야. 여지껏 블록 한 개가 형성되기 전까지 기다릴 수 없었다면, 이미 이론적으로 결제 사기 위험을 감수했다는 얘기고, 이는 곧 네가 비트코인을 제대로 활용하지 않았다는 얘기거든. 따라서 이런 위험성을 100% 확실한 위험으로 만드는 일도 그리 큰 변화는 아니지.
달리 말하면 그들은 리스크 관리가 존재한다는 사실을 무시하기 때문에 이런 변화를 수수료 ‘0’라고 인식하는 것이다.
이런 프로토콜 수정안은 Bitcoin Core 다음 버전인 0.12에 포함될 거다. 채굴자가 Bitcoin Core를 판올림하면 이 기능이 활성화된다. 전체 비트코인 커뮤니티가 이를 전격적으로 비판했지만 남은 Bitcoin Core 개발자는 다른 이가 어찌 생각하는지는 아랑곳 않는 듯하다. 그러니 이런 변화는 곳 실현될 거다.
이 정도로 설명했는데도 비트코인이 심각한 문제를 품고 있다는 사실을 확신할 수 없다면, 당신은 영영 깨닫지 못할 거다. 비트코인을 실제 상점에서 사용할 수 없게 됐을 때 얼마나 많은 사람이 비트코인이 수백 달러짜리라고 생각할까?

결론

비트코인은 이례적으로 위험한 상황에 빠졌다. 마운트곡스 파산 같은 지난 위기는 생태계 주변에 싹튼 일개 서비스나 회사의 잘못이었다. 이번에는 다르다. 이건 핵심 시스템, 블록체인 자체의 위기다.
더 근본적으로 이번 위기는 서로 다른 세계관을 지닌 집단 사이에 철학적 견해가 깊다는 사실을 보여준다. 한쪽은 세계가 ‘전문가의 합의'에 따라 다스려져야 한다고 생각하는 반면 다른 쪽은 평범한 사람들이 스스로 납득할 수 있는 정책을 채택해야 한다고 여긴다.
Bitcore Core를 대체할 새로운 팀이 꾸려진다 할지라도, 마이닝 파워가 만리장성 건너편에 집중돼 있다는 문제는 사라지지 않는다. 10명도 안 되는 사람 손아귀에 놀아나는 이상 비트코인에는 미래가 없다. 그리고 이 문제는 해결할 방법도 없다. 어느 누구 제안조차 제시하지 않는다. 커뮤니티는 늘 블록체인이 억압적인 정부에 의해 전복될까 우려했다. 이 얼마나 모순적인 일인가.
아직 모든 것을 잃은 건 아니다. 지금껏 일어난 모든 일에도 불구하고, 지난 몇 주 동안 점점 더 많은 커뮤니티 회원이 내가 버려두고 온 것을 주워들기 시작했다. Bitcoin Core의 대체제를 만드는 일이 언뜻 배신으로 보일지 몰라도, 이미 세간의 관심을 두고 싸우는 두 무리가 있다. Bitcoin Classic과 Bitcoin Unlimited다. 지금까지는 두 부류도 XT가 겪었던 똑같은 문제를 겪고 있다. 그러나 새 사람이 모인다면 탈출구를 찾을 수도 있을 테다.
비트코인계에는 유능하고 정력 넘치는 사람이 많다. 지난 5년 동안 이런 사람을 많이 알게 돼 기뻤다. 이들의 창업가 정신과 돈과 경제와 정치를 보는 새로운 관점을 배우는 것은 황홀한 경험이었다. 내가 매진했던 프로젝트가 이렇게 수포로 돌아간다고 해도 나는 비트코인계에서 보낸 시간이 아깝지 않다. 나는 오늘 아침 검열당하지 않는 포럼에서 인사 나눌 사람을 찾으려고 일어났다. 이들은 내게 떠나지 말라고 부탁했지만 나는 다른 일로 옮겨 가야 한다. 이들에게 이 자리를 빌어 인사를 전한다. 행운을 빈다. 잘 지내라. 늘 좋은 일만 가득하길 바란다.
<끝>


반응형
반응형

출처:https://medium.com/@NipolNIpol/blockchain%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC-%EA%B3%BC%EA%B1%B0%EC%97%90%EC%84%9C-%EB%AF%B8%EB%9E%98%EA%B9%8C%EC%A7%80-a4917534327c


대다수가 Bitcoin이라는 것은 들어보았지만, 이 Bitcoin Network를 안정적으로 유지하는 Blockchain이라는 기술은 많이 알려지지 못했습니다. 아주 많은 장점을 가지고 있고, 다양한 수단으로도 사용될 수 있는 미래가 있기 때문에, 자처해서 전도사 역할을 하여봅니다.

Blockchain을 구성하는 “안정적인 합의과정을 구성하는 것들”은 고유의 기술적 위치가 확실하고, 서로 맞물려 Blockchain을 이루고 있기 때문에, 기술 요소를 하나씩 설명하는 것은 문맥상으로도 맞지않고. 그것들을 하나씩 맞춰가는 과정 또한 필요하기 때문에, 이는 옳지 않다고 판단했습니다. 이러한 이유로 며칠을 고민했는지 모르겠네요.

다음과 같이 개요를 설명하는 것이 제일 나으리라 판단하였고, 이 글이 Blockchain의 이해를 돕고 다양한 프로젝트로 기준화 되고, 기존 산업을 대체하는 수단으로 많은 활용이 되었으면합니다.


Peer to Peer의 세계

Blockchain은 Peer to Peer 클라이언트들로 이루어진 하나의 Network 그룹입니다. 혹시 이 글을 읽는 독자분들은, 파일공유 프로토콜인 Torrent를 사용해 본 적이 있나요? 특정한 파일을 가지고 싶다고 네트워크에 참여해 외치면, 파일을 가지고 있는 다른 사람들이 자발적으로 전송해주는 아주 고마운 프로토콜입니다.

나 또한 네트워크에 참여한 일원이기 때문에 전송받은 파일을 가지게 되면, 다른 사람이 네트워크에서 파일이 필요하다고 외칠 때도 나는 자진해서 전송해줍니다. Torrent란 자발적으로 파일을 유지하기 위한 합의된 클라이언트의 집합인 것입니다.

이러한 서비스의 특징은 무엇이냐면, 서버를 중심으로 모여있는 클라이언트들의 집합이 아니라는 것입니다. 모든 네트워크에 접속된 사용자들은 파일을 전송해주는 서버이자, 파일을 요청하는 클라이언트입니다.

또 다른 특징은, 굳이 내가 파일을 가지고 있지 않더라도, 네트워크에 요청하면 누군가 파일을 전송해 주기 때문에, 실질적으로 파일을 가지고 있는 것과 다름이 없다는 것이죠!

전 세계에 나를 제외한 모든 사람이 "Cinema Paradiso"라는 영화를 가지고 있다고 가정해봅시다. 내가 그 영화를 가지고 있지 않더라도, "사회"라는 사람들이 모여있는곳에 영화를 전송해 줄 것을 요청하면 "누군가, 한 명 쯤"은 전송해주지 않을까요.

Network

이런 분산된(Distributed) 서비스는 Server — Client과 같은 중앙화된(Centralized) 서비스와 많이 다르다는 것을 알 수 있지요.

이처럼, Peer to Peer(이하 P2P) 서비스에 참여한 사용자들은 Node라고 부르는데, 이는 하나의 Node가 서버와 클라이언트를 분간하지 않고, 두가지 역할을 모두 수행하고 있기 때문입니다. 그럼 Torrent를 추상적인 관점으로 바라본다면, 무제한 파일 저장소나 다름없다고 볼 수 있겠네요! 이런 무한한 데이터 저장소에 모든 내용을 저장한다면 어떨까요? Blockchain은 바로 이 물음에서 부터 시작합니다.


세상에서 가장 커다란 저장소

Blockchain은 거대한 분산 장부(Ledger)입니다. 장부에는 무언가를 사고 팔았던 거래내역들이 모두 나타납니다. 이런 모든 거래 내역은 네트워크에 참여한 노드들이 보증을 하고, 필요하다면 나에게, 또는 나의 친구에게 전송해 주어 아무나 확인할 수 있도록 해 주는 것입니다.

Torrent는 딱 네트워크에 전파하고자 하는 파일들만 공유할 수 있었습니다. 새롭게 업데이트된 파일을 공유하고 싶다면, 새로운 Torrent 네트워크를 생성하여야 했죠. 하지만 Blockchain은 새롭게 생성되는 파일들을 추가하여, 네트워크에 참여한 모든 사람이 같은 파일을 가질 수 있게 할 수 있습니다.

이해를 돕기 위해 세 사람, A, B, C를 등장 시켜보겠습니다. 이 세 사람의 모임의 구성원은 각각 10만원씩 가지고 있으며 서로가 하는 거래를 보장하기 위해서 Blockchain을 사용하려고 합니다. 각각 10만원씩 모아 30만원을 만든 다음, 은행에 공동명의 통장을 개설 합니다. 이제 금액을 보장하는 주체는 은행이 되었고, 이제 모든 거래는 Blockchain을 통해서 이루어질 예정입니다. 이제 세 사람의 금액은 은행이 아닌, Blockchain에 의해 보장받게 됩니다. 그렇다면 이제 Blockchain이 얼마나 신뢰성이 높은지 알아 보아야 할 차례입니다.

Blockchain에 참여한 세 사람은 서로간의 거래를 할 때 모임의 과반수 이상이 참여했을 때 거래를 할 수 있도록 합의를 하였습니다. 점심. A는 B가 대신 지불한 도시락 가격 2,500을 준 것으로, 장부를 작성하였습니다. 그날 저녁 A는 C와 함께 술을 마셨고, A는 C가 대신 지불한 비용의 반인 10,500원을 준 것으로, 장부를 작성하였습니다.

이 모든 장부 내역은 세 사람이 가지고 있으며, 서로가 얼마를 가지고 있는지 확인 할 수 있고. 각자 돈을 어떻게 얻게 되었는지, 어떻게 잃게 되었는지 복기를 할 수 있게 되었습니다.

돈이 점점 없어지는 A는 돈이 아까웠습니다. 그래서 새로운 장부를 하나 작성하고, B와 C가 돈을 5만원씩 준 것으로 장부를 작성하였습니다.

하지만 이 장부는 B와 C에게 받아들여지지 않습니다. 과반수가 모여있지 않은 상태에서 작성한 장부를 인정할 수 없는 것이지요.

A가 만들어온 장부는 받아들여지지 않았고, B와 C는 A가 너무 괴씸하다는 생각을 했습니다. 그래서 A의 잔고를 각각 나누어 가지기로 하고, 새로운 장부를 합의하에 작성하였습니다.

A는 과반수에 의해 생성된 장부를 인정할 수 밖에 없으며, B와 C는 은행의 모임통장을 해지하고 돈을 찾아 나누어 가졌다는 행복한 이야기랍니다.

행복한 이야기 잘 보셨나요? 여기서는 모든 장부는 Block으로 표현되었고, 거래내역을 포함하고, 이전의 거래내역을 기반으로 새로운 Block을 생성하기 때문에 Chaining이 기본이 됩니다. 또한 모든 노드들의 잔고내역이 남기 때문에, "거래 가능한 잔고증명"도 가능하죠.

하지만 위의 이야기를 읽으시면서 어떤 부당함이 있지 않았나요? 우선 세 사람은 자신의 잔고가 다른 사람에 의해 사용될 수 있었습니다. 또 과반수에 의한 Block 생성이 가능했습니다.

하지만 실제 Blockchain들은 위의 취약점을 가지고 있지 않습니다. 하지만 어떻게 위의 취약점을 해결했는지 알아 둘 필요는 있지요.


Blockchain의 검증

해시 함수(Hash Function)는 임의 길이데이터를 고정된 길이의 문자열로 변환하는 함수인데, 이는 ‘같은 입력 값’에 한해서 같은 해시 문자열을 보장하며, 입력 값이 다르면, 다른 결과 값을 내줍니다.

해시 함수는 수학 공식의 결과물로 해시 문자열이 충돌되는 일이 없어야 합니다. 해시 함수의 효과중에 하나로 눈사태 효과(Avalanche Effect)라는 것이 있는데, 이는 기존의 데이터에서 아주 작은 데이터값이 바뀌더라도, 전체 해시 문자열이 바뀌어 원래 데이터의 유추가 불가능하게 됩니다.

점 하나만 추가 되어도 해시 문자열 전체가 바뀌어 내용의 유추를 할 수 없다.

이렇듯, 해시 함수는 짧은 문자열을 사용하여 패스워드의 일치 파일의 위변조 방지에 사용되고 있으며. 특히나 네트워크의 위변조를 방지하는데 사용되고 있습니다. 이러한 것을 Blockchain과 장부(Ledger)에 사용한다면?

장부의 찍혀있는 숫자 하나만 바뀌어도 눈사태 효과로 인해서 해시 문자열의 결과가 많이 달라지게 될 것입니다. Blockchain에서는 해시 함수를 이용하여 다음과 같은 합의된 방법으로 Block을 검증합니다.

해시함수( “블럭 양식 버전” + “이전 블럭의 해시” + “이전 블럭 작성시간” + “새로운 블럭에 포함될 거래 갯수” + “블럭 생성자” +”난이도 계수” )
= “새로운 블럭의 해시”

이런식으로 Block의 해시를 이룰 수 있는 정보들도 함께 기술되기 때문에, 블럭의 무결성을 확인할 수 있게 되었습니다. 이전 Block의 해시또한 다음 블럭의 해시를 생성하기 위한 수단으로 사용하기 때문에, 이는 충분히 검증된 수단으로 사용할 수 있습니다.

Block을 생성하는 구성요소들을 확인해보면 “블럭 생성자”와 “난이도 계수” 라는 것들도 Block을 증명하는데 쓰이게 됩니다. 그렇다면 이 두개의 값은 무엇을 위해서 추가되는 것일까요?

Blockchain에서 Block이 생성되지 않는다면, 화폐의 거래는 증명될 수 없습니다. 거래들은 Block에 포함되어야, 잔고증명이 성공적으로 이루어졌다라는 사실에 기초하기 때문이죠.

예시로 Bitcoin 블럭 해시를 한 번 볼까요?

#100,000–000000000003ba27aa200b1cecaad478d2b00432346c3f1f3986da1afd33e506

#390,001–0000000000000000055265fb53f189394aaa2c88ca37548c693c17965c9a45e2

무언가 특이하지 않나요?

100,000번 째 블럭은 11개의 0으로 시작하는 해시로 이루어져 있고, 390,001번째 블럭은 17개의 0으로 시작하는 해시로 이루어져 있습니다. Bitcoin의 “블럭 생성 난이도”는 해시의 시작을 0으로 하되, 0의 길이를 점점 증가시키는 것을 난이도를 상승시킨다고 합니다. 이런 해시형태를 만족하기 위한 Count 값이 "난이도 계수"인 것이지요.

100,000번 째 블럭과 390,001번 째 블럭들 사이에는 난이도가 무척 많이 상승했음을 알 수 있습니다. 지금 Bitcoin Network의 연산 성능은 전세계 500위 안에 있는 슈퍼컴퓨터의 연산 성능을 합한 것 보다 더욱 높다고 합니다. 이와같은 연산능력을 사용하여 블럭을 증명하는 방식을 Proof of Work(PoW)라고 합니다.

Blockchain에도 DDoS (Distributed Deniel of Service) 공격은 존재합니다. 잘못된 거래를 포함한 블럭들을 많이 생성해서 네트워크에 전파시킨다면, 네트워크는 이를 검증하는 작업으로 시간을 뺏기게 될 것이며, 올바른 블럭의 생성은 이루어지지 않을 것입니다. 그렇기 때문에 Network의 연산 성능 또한 DDoS Attack을 막기 위해 필요한 것이며, 실제로 Bitcoin Network는 잘못된 블럭들을 아주 빠른 시간 안에 거부할 수 있습니다.

해시함수의 특성상 이런 특이한 형태의 해시값을 만족하는 데이터들을 구성하는 것은 시간과 컴퓨터의 연산 성능을 정말 많이 사용합니다. “난이도 계수”를 1씩 증가시켜서 0000000…. 으로 시작하는 해시 문자열을 만드는 것이죠. 눈사태 효과를 뚫고 이러한 해시를 생성하는 일은 엄청난 컴퓨팅 파워를 요구하게 됩니다. 네트워크를 유지하는데 사용되는 연산능력이 점점 증가하면 아무나 블럭을 생성할 수 없기 때문에 Block에 포함되는 거래는 점점 신뢰도가 높아지겠지요.

Blockchain의 노드들은 이런 특이한 형태를 만족하는 해시값들만 올바르다고 판단합니다. Block을 생성하는 것은 어렵지만, Block을 구성하는 데이터가 공개되어 있으니, 해시함수를 이용하여 검증을 하는 일은 무척 쉽지요!


Trustlessness

Blockchain은 기본적으로 모든 블럭들을 똑같이 가지기 때문에, 모든 거래내역 그리고 잔고들을 모든 노드들이 가지게 됩니다. 모든 정보들이 공개되어 있으니, 태생적으로 Blockchain은 신뢰 불가능(Trustless)한 플렛폼이 될 수 밖에 없었습니다.

하지만 Blockchain의 모든 요소들은 익명성(Anonymous)을 가지기 때문에 모든 정보가 공개되어도 상관이 없습니다. 오히려 안정성은 확보할 수 있게 되었고, 거래의 주체도 특정인을 지징할 수 없으니 더욱 나은 시스템이라고 할 수 있습니다. Blockchain에서 지갑 주소라고 알려진 이것 또한, 사용자로 부터 입력받은 문자열을 기반해서 생성된 해시 문자열로 이루어져 있습니다.

암호화 함수(“지갑 비밀번호”, “비밀번호 암호화 방식”, “Salt”)
= “암호화된 패스워드”
해시 함수( “암호화된 패스워드” + “지갑 생성 시간” + “지갑 생성 난수” )
= “지갑 해시 문자열”

이런식으로 해시 문자열이 생성되게 되며, 절대 일치하는 값이 생성되지 않습니다. 지갑이 새로 발행되었다고, 네트워크에 전파되는 것도 아닙니다. 이는 네트워크에 참여한 순간부터, 사용자를 구분하고, 거래할 하나의 고유한 ID가 됩니다.

사실 위의 내용보다 지갑의 해시를 구성하는 데이터는 외울 수 없는 것들로 더욱 복잡하지만, 간단히 설명해 보았고, 아주 작은 디지털 파일로써 백업을 할 수 있는 대상이기도 합니다.

이런 지갑의 소유권을 증명하기 위해서는 이체를 할 때, 지갑을 만들때 사용한 패스워드를 입력하여, 같은 지갑주소가 생성되면 그때서야 소유권을 인정받고 이체를 할 수 있습니다.

이로써 블럭을 들여다 보면, 온통 해시만 가득한 거래내역과 블럭 해시 밖에 보이지 않습니다. 신뢰할 수 없는 플렛폼에서 거래의 익명성을 보장받게 된 것입니다.


Reward

앞서서 Torrent 네트워크를 무제한 파일 저장소나 다름 없다고 하였지만, 이제는 이 말을 취소해야 할 때인 것 같습니다. 사실 Torrent 같은 Peer to Peer 프로토콜의 가장 커다란 문제는 참여의 결여가 가장 커다란 문제입니다.

공유자가 없는 파일은 더이상 네트워크에 존재하지 않는 파일입니다. 또는 어떤 파일은 요구하는 사람이 너무 많아서 내 컴퓨터의 자원과 네트워크 속도를 갉아 먹을 것입니다. 내 컴퓨터의 자원을 사용하며 파일을 공유하지만, 이것은 순수한 자원 봉사를 통한 선행이지, 절대 득이되는 일은 아닙니다. 참여하고 있는 Node들은 언젠가 자연스럽게 소멸하겠지요.

Peer to Peer 통신을 기반으로 하는 Blockchain 또한 이런 위협에 안전하지 않습니다. 네트워크를 탄탄하게 유지하기 위해서는 참여자들에게 충분한 보상이 되어야 합니다. 그렇습니다. Blockchain은 이 문제를 해결했습니다.

컴퓨터 자원을 사용해 Block을 생성하는 일은 네트워크를 안정적으로 유지하는데 기여를 하는 일입니다. 이런 기여에 감사의 목적으로 보상을 제공하게 되었습니다. 그것이 바로 Crypto Currency(암호 화폐)인 Bitcoin이었습니다. 이것이 블럭을 구성하는 요소 중, "블럭 생성자"라는 요소가 존재하는 이유입니다.

사실 이 글에서는 Blockchain이 먼저 등장한 개념이고, Bitcoin이 뒤에 따라온 개념처럼 설명이 되었는데, 사실은 그렇지 않습니다. 중앙 서버가 없는 디지털 화폐를 유지하기 위한 목적으로 개발된 것이었기 때문입니다. Bitcoin을 유지하기 위한 목적으로 Blockchain이 개발된 것입니다. 하지만 우리는 이 Blockchain이라는 기술에 집중해 보겠습니다.


Block Difficult

Bitcoin은 지속적으로 블럭을 생성하는 난이도를 증가시키며, 컴퓨팅 파워를 많이 사용하는 Proof of Work 방식을 통해 Block을 생성하고, 거래를 승인합니다. 이로써 얻는 장점은 무엇일까요.

비트코인의 난이도 증가 테이블. 비트코인의 난이도는 블럭이 10분에 하나씩 생성될 수 있도록 자동으로 조절된다.
  • 블럭 생성자에게 보상이 지급됨에 따라, 네트워크에 컴퓨팅 파워가 집중되면 블럭이 빠르게 생성됩니다. 이는 화폐가 많이 발행되는 인플레이션 현상을 불러올 수 있기 때문에, 화폐의 과다한 유통을 막는 역할을 합니다.
  • 연산능력을 최대로 동원하기 때문에 충돌할 수 없는 유일한 해시값을 생성합니다.
  • 특이한 형태의 해시값을 이용하기 때문에 블럭의 위변조가 어렵습니다.
  • 중앙에서 관리받지 않는 네트워크의 신뢰성을 더합니다.

하지만, 장점이 있다면 단점 또한 존재합니다.

  • 블럭 생성이 느려지자 거래 승인이 느려졌습니다.
  • 혼자서 블럭을 생성할 수 있는 노드가 줄어들어, 채굴 노드의 다양성이 떨어졌습니다.

이런 블럭을 생성하는 작업을 Mining, 즉 채굴이라고 하며, 채굴에 성공하면 보상이 지급되는 광산업의 영향을 많이 받았다고 할 수 있습니다.

보상을 목적으로 네트워크에 많은 연산능력이 도입되면서, Block 난이도는 점점 증가하기 시작했습니다. 그러면서 ASIC(Application Specific Integrated Circuit) 즉, 주문형 반도체가 등장하면서 반도체 제조사 주도로, 네트워크가 기업화 되기 시작했습니다. 이는 일반적인 컴퓨터 한 대가 낼 수 있는 연산능력의 몇 백/몇 천 배를 훨씬 뛰어넘었습니다.


51% Threat

Block의 채굴은 점점 어려워지고, Node들은 자기가 가진 연산능력을 모아 Block을 채굴하고, 얻은 보상을 나누어 가지기 시작했습니다.

Bitcoin Hashrate Market Share (last 24h)

이렇듯, 많은 노드들이 모여 해시 파워가 집중되는 특정 노드들이 등장하기 시작했습니다. 이렇게 하나로 모여진 노드들은 부모노드의 결과를 그대로 수용하게 됩니다. 그렇다면 부모노드가 거래내역을 조작한다면 어떻게 될까요?

해시파워를 모아주는 자식 노드들은 부모노드의 결과를 그대로 수용할 것이며, 이런 노드들이 전체 네트워크의 51%. 즉 과반수를 넘어버리게된다면 네트워크의 신뢰성에 문제가 발생합니다. 이것이 "51% 위협"입니다.

이는 Blockchain에서 가장 위험한 것이며, 시스템이 붕괴될 수 있는 요소입니다. 우리는 이제 올바른 Block을 검증하는 수단을 가지고 있고, 다른사람이 인정할 수 있는 Block을 생성하는 방법또한 알고있지만, 다른 사람이 생성한 Block을 나의 블럭에 추가하는 과정은 나보다 긴 Block을 가진 과반수 이상의 노드들이 Block을 가지고 있다면 나의 Blockchain에 추가합니다.

이미 과반수를 점유하고 있는 네트워크의 노드들이 해당 블럭은 검증을 통과했으니 다른 노드들에게 블럭을 추가하라고 할 것입니다. 네트워크는 이미 스틱스 강을 건너버리고 난 뒤입니다.

이런 사태가 일어나게 된 가장 커다란 이유는 블럭 검증을 위한 PoW방식 알고리즘 때문입니다. 거래를 인증하기 위해서 많은 에너지, 많은 자원이 필요하기 때문이고, 사이드이펙트로 이런 채굴 노드의 집중화를 불러 옵니다. 이러한 문제때문에 Proof of Waste라고 부르기도 합니다.

전 Bitcoin Core Developer, Mike Hearn이 Bitcoin Foundation과 Bitcoin Core Developer Team에 대한 글, The resolution of the Bitcoin experiment(번역) 올렸는데, 이는 다양한 이유들로 Bitcoin 네트워크가 위험하다고 경고하고 있다.
현재 Coinbase의 CEO인 Brian Armstrong 또한 What Happened At The Satoshi Roundtable라는 글을 작성하며, Bitcoin Community가 좋은 커뮤니티가 아니라고 언급.

Proof of Stake

그렇다면 이런 중앙으로 집중화될 수 있는 PoW를 대체할 다른 수단은 없는 걸까요?

이러한 Bitcoin의 한계를 알게된 Scott Nadal과 Sunny King은 오로지 “합의”에 의한 블럭생성 방식을 만들어 내었고, 이는 Peercoin이라는 Altcoin에 의해서 증명되었습니다.

Peercoin은 기존의 PoW 방식의 블럭 증명은 비효율적이며, 자신들의 블럭 생성 알고리즘은 Proof of Stake (PoS)를 기반으로 작동한다고 합니다.

네트워크에 포함된 어떤 노드가 거래를 시작하면, 인접한 다른 노드가 기존의 블럭에 있는 거래를 참고하여 잔고를 증명하고, 거래를 해시함수로 검증해줍니다. 그리고 이는 검증된 블럭으로써 다른 사용자들에게 배포됩니다.

이런 증명은 네트워크의 노드들 사이 이해관계를 기반하고 있기 때문에 Proof of Stake라고 합니다. 이러한 블럭 증명 방식이 PoW와 비교하여 어떤 잇점이 생기는지 확인해 볼까요.

  • 블럭의 생성을 위해 특별한 해시결과물을 요구하지 않습니다.
  • 블럭 생성 속도가 아주 빠릅니다.
  • 이해관계를 통한 증명을 하기 때문에 해시 파워가 집중될 수 없습니다.
  • 해시 파워가 집중되지 않기 때문에 에너지 효율적입니다.
  • 완전한 분산 환경과 자율권을 가지며, 51% 위협에 안전합니다.

Before Blockchain

모든 정보들을 한 번 종합해 보겠습니다. 기존의 Blockchain은 CryptoCurrency에 의한, CryptoCurrency를 위한 플렛폼이었습니다. 모든 거래는 디지털 화폐로 이루어지고, Blockchain으로 보장되는 내용들도 디지털 화폐에 대한 내용이었습니다.

Satoshi Nakamoto가 처음 작성한 White Paper의 제목 또한 Bitcoin: A Peer-to-Peer Electronic Cash System 이었습니다. 위에 작성한 내용을 바탕으로 Blockchain을 잠시 정리해 보면,

  1. Blockchain에 적혀있는 거래내역을 바탕으로 잔고를 증명한다.
  2. Block의 생성과 검증은 해시 함수로 이루어져 안전하다.
  3. Blockchain은 모두에게 공개되어 있어서 신뢰불가능한 플렛폼이다.
  4. 거래주체자들은 모두 해시화 되어 있어, 완전한 익명성을 가진다.
  5. 모든 통제권은 네트워크에 참여한 노드들이 각자 가지고 있다.
  6. 모든 Blockchain은 모든 노드가 가지게된다.

이렇듯 Blockchain기술을 기반한 것들은 중앙화 될 수 없습니다. 과반수의 위협에 대응하기 위해 전 세계에 분산된 노드들이 있어야 하며, 이들 노드들은 합의된 내용에 따라 연이어진 블럭을 생성하고 검증하기 때문에 자연스럽게 비가역적(非可逆的)인 특성을 지니게 됩니다. 중복 지출을 막을 수 있으며, 한번 시행된 거래는 최종적이며, 다시 취소할 수 없습니다.

이런 Blockchain의 특성을 이용한 기술들은 무엇이 있는지 알아보겠습니다.

  • Namecoin — https://namecoin.info : Blockchain 기술을 이용한 DDNS시스템입니다. 기존의 DDNS는 도메인의 변경점이 있다면 전세계 라우터에 적용되기 까지 무척이나 오래걸렸지만, Namecoin은 도메인 정보들을 블럭에 담아 chain을 구성하였고, Block들이 네트워크 상에서 빠르게 전송된다는 잇점을 이용하여 라우팅 시스템을 구성하였습니다. 또한 가까이에 있는 Namecoin 노드를 참조해서 빠르게 DDNS의 주인과 도착지를 조회할 수 있다는 것도 장점입니다. `.bit` domain을 지원합니다.
  • Open Assets — http://www.openassets.org : 기존의 Bitcoin Blockchain을 이용한 다양한 코인 발행 플렛폼입니다. 이는 bitcoin과 다르게, 코인을 한 사람이 발행하고, 코인의 전송과 보장에는에는 Bitcoin네트워크를 이용한 시스템입니다. 이 프로토콜을 이용하여 사업을 하고 있는 회사는 ColoredCoin, CoinPrizm, BPSI 외 다양하게 있으며 이며 특히나 BSPI는 실물 자산을 보장하는 수단으로 사용하고 있습니다. Open Assets의 자산들이 가치가 더해진다면, Bitcoin의 네트워크 가치도 덩달아 상승하게 됩니다.
  • Dnschain — https://okturtles.com : Blockchain 기술을 이용한 DNS시스템입니다. 이 DNS는 블록체인에 분산된 공개키 기반의 암호화를 이용하여 Man in The Middle 공격을 원천적으로 차단할 수 있고, 노드들이 분산된 CA의 역할을 하기 때문에 SSL/TLS 기반의 인증서가 필요없게됩니다. 외부로 드러나는 프로토콜은 DNS기능을 하기 때문에, 기존 시스템에도 아주 잘 어울린다는 특징이 있습니다. 자체적으로 `.dns` domain을 지원합니다.
  • Storj — http://storj.io : Chunk 기반 파일을 전세계에 저장하고 리워드로 암호화 화폐를 받을 수 있는 Driveshare. 파일의 위치를 Blockchain에 저장하고, 파일을 찾을때 Blockchain에 기록된 파일의 위치를 참조하여 파일을 찾는 Metadisk를 운영하고 있는 회사입니다. 사실상 전세계에 깔린 AWS S3을 쓰는 것과 같으며, 파일을 요청하는 지역적 위치에 따라 빠르게 파일을 찾고 전송받을 수 있는 것이 특징입니다.
  • OpenLedger — https://www.openledger.info : 공공장부를 지양하는 프로젝트이며, 네트워크를 발전 가능한 하나의 기업 또는 커뮤니티로 보고, Bitshare라는 코인을 이용하여 주식에 따른 투표권을 가집니다. 이 투표권으로 제안과 변경을 주도할 수 있습니다. 또한 Bitshare를 이용하여, OpenAsset같은 다양한 자산들을 만들고 관리할 수 있는 플렛폼이기도 합니다.
  • IPFS — https://ipfs.io : 파일을 블럭체인에 업로드하고, 어느 노드에서든지 확인할 수 있는 플렛폼입니다. 모든 노드들은 서로 연결되어 있고, 업로드된 파일들을 나누어 가집니다. 노드를 유지하지 않더라도 외부에서 파일에 접근할 수 있습니다. 하지만 파일을 유지하여도 코인을 보상으로 지급하지 않습니다.

외에도 Filecoin, NextCoin, Peercoin 등등 이 모든 것들이 Blockchain플렛폼들입니다. 기존의 산업 형태를 바꾸는 많은 시도들이 Blockchain이라는 공통적인 특성 위에서 구현되고 있습니다.

하지만 구현된 Blockchain들은 호환성을 가지지 않고 각자 별개의 프로토콜을 가지고 있습니다. 이러한 사용자들의 참여는 네트워크간의 단편화를 불러오고, 있습니다. 참여가 저조한 네트워크가 있다면 해당 네트워크의 몰락은 더욱 빠르게 다가올 것입니다.


Smart Contract

컴퓨터 과학자인 Nick Szabo는 1993년 Smart Contract라는 컴퓨터 프로토콜의 한 형태를 발표하였습니다. 이 Smart Contract는 컴퓨터간의 자원의 사용에 대해서 불필요한 계약 과정을 생략할 수 있는 합의 프로토콜이었습니다.

이런 특성들로 본다면, Smart Contract는 자가 실행이 가능하여야 하고, 부분적, 또는 전체적으로 실행될 수 있어야 합니다. 이는 인터페이스를 통하여 어떤 사용자든지 사용할 수 있는 객체, 또는 서비스 데몬으로 볼 수도 있겠지만, 신뢰불가능한 인터넷 환경에서 높은 추상화로 개발된 프로토콜을 합의하는 개념이었습니다.

Contract라는 단어에서 계약서라는 단어를 떠올릴 수도 있겠으나, 이를 컴퓨터 사이의 계약이라고 본다면, 프로그래밍된 그대로 작동을 보장하는 하나의 객체로 볼 수 있습니다. 예를 들면... 컴퓨터 바이러스가 있겠네요! 제 3자의 개입없이 혼자서 작동하고, 지정된 일만 한다고 생각하면 되겠습니다.

하지만 Blockchain의 설명에 왜 Smart Contract라는 추상화된 개념이 등장했을까요? 이 추상화된 개념이 Blockchain을 만나 구현체를 가지게 되면서, 기존의 산업 전반의 형태가 바뀌게 됩니다.


Next Generation Blockchain

이미 앞서서 보았듯 다양한 기능을 가진 Blockchain들이 시장에 하나씩 등장하게 됩니다. 이 글을 읽는 분들이 눈치를 챘는지 모르겠지만, 이미 이들은 다양한 형태의 Smart Contract를 구현하고 있는셈입니다.

우리는 Blockchain이 신뢰하지 않는 컴퓨터 네트워크에서 서로를 신뢰하기 위해서 해시 함수를 사용하고 있고, 모든 정보들은 모든 노드들이 가지고 있다고 하였죠, 그리고 Blockchain의 고유 기능들은 노드들 간의 합의에 의해서 자율적으로 작동하고 있습니다! 이런 형태 모두가 Smart Contract이죠!

하지만 이들 모두가 서로의 Blockchain과 호환되지 않는다는 사실을 우리는 잘 알고 있습니다. 그리고 대다수의 Blockchain은 자기 자신을 보장하기에는 너무 작은 노드들을 가지고 있게 되겠지요. 종국에는 해당 Blockchain의 몰락을 가져오게 될 것입니다.

이러한 한계를 미리 예견하고 있던, 한 개발자가 있습니다. Vitalik Buterin은 Smart Contract 프로그래밍이 가능하며, 많은 참여자를 기반으로 보안성을 가질수 있는 공개된 Blockchain을 개발하고자 하였습니다. 이것이 바로 Ethereum입니다.


Ethereum

Ethereum은 분산된 어플리케이션의 개발 환경을 제공하는데에 초점이 맞추어져 있습니다. 여기에는 EVM(Ethereum Virtual Machine) 이라는 것이 내장되어 있고, 이는 Smart Contract를 실행할 수 있는 vm의 한 종류입니다.

Smart Contract는 EVM위에서 자율적으로 작동하게 되며, 인터페이스를 통한 접근이나 메시지의 작동에 일정부분 코드를 실행하고 결과를 저장 또는 반환하여 주며, 모든 내용은 Block에 기록되며, 모든 참여자들에 의해 보장받게 됩니다.

Ethereum 또한 Block 생성의 리워드로 Ether라는 코인을 제공하고 있습니다. 하지만 Ether는 단순히 코인이 아닌 EVM위에서 Smart Contract를 작동시키기 위한 연료로써 사용됩니다!

높은 수준 프로그래밍 언어로 구현된 Smart Contract는 Assembly로 변환되어, 특정 부분, 또는 전체를 실행할 수 있으며, Assembly 명령어의 길이와 수준에 따라 Ether를 지출하게 됩니다. Bitcoin처럼 단순히 코인으로써 끝나는 것이 아니라, 획득과 사용에 선순환을 이루게 되는 것이 특징입니다. Ethereum Foundation에서는 Ether를 Crypto-Fuel이라고 부르고 있기도 합니다.

위에서 설명한 대부분의 Blockchain 프로젝트는 Ethereum에서 코드 몇 줄로 구현할 수 있습니다.

또한 Ethereum Foundation은 ÐΞVp2p라는 것을 구현하고 있기도 합니다. Common Blockchain Platform의 입지를 확실히 다지고, 많은 사용자의 참여를 유도하게 하는 하나의 방법이며, 전세계의 네트워크를 좀 더 안전하게 이용할 수 있도록 도와줍니다.

다수의 노드가 100% 가용성으로 작동되고 있어서 이로 인한 네트워크의 이익은 무궁무진합니다. 모든 메시지를 암호화하여 머신과 머신 사이에 멀티플랙스 방식으로 전송하고 수신할 수도 있고, 인접한 노드를 찾아 다양한 이유로 사용할 수도 있습니다.

그렇다고 기존 네트워크 프로토콜을 무시하지는 않습니다. Web3.0 이라는 구현체가 대표적인데, 이는 기존 HTTP기반 프로토콜에서 작동하여 Ethereum 네트워크와 긴밀하게 통신하며 Smart Contract를 실행할 수도 있습니다.

  • Whisper — 1:N, N:N 종단간 암호화를 지원하는 메시지 프로토콜
  • Swarm — chunk 분산 파일 저장 프로토콜
  • Name Registry — “.eth” 도메인 등록 프로토콜
  • Contract Registry — 공공 Contract 등록 프로토콜

위의 구현체들이 대표적인 Web 3.0 기반의 프로토콜이며, 특히나 Whisper 같은 경우에는 노드들이 분산되면서, 미리 합의된 채널과 키로 수신과 발신이 가능하게 되면서, 네트워크 자체가 암호화를 지원하게 되었고 이는 N:N 종단간 암호화를 가능하게 하였습니다.


Realistic Problem

이제 실질적인 문제를 맞이할 때인 것 같습니다. 제가 장황하게 설명을 하긴 하였지만 모두 이론적인 설명들일 뿐입니다. 우리가 실질적으로 겪는 문제와 거리가 있죠. 그래서 이번 장에서는 최대한 기존 산업에서 발생하는 문제를 Blockchain으로 해결하는 과정을 글로 설명해 보려고 합니다.

혹시 이런 적 없으셨나요?

  • 즐겨하던 게임이 서버에 이상이 생겨, 3일 전으로 백-서버를 당했다.
  • 온라인 쇼핑몰에서 결제 클릭을 2번 눌렀는데 결제가 2번 되어, 나머지 하나에 대한 환불처리가 무척 늦었다.
  • 중고 제품을 거래할 때 에스크로 서비스가 너무 비싸 사용한 적이 없다.

모든 상황들이 암울하지만, 하나씩 짚어보며 넘어가겠습니다.

대표적으로 모든 게임은 사용자간의 거래가 가능합니다. 모든 플레이어들의 인벤토리를 블럭체인에 저장하고, 교환이 발생하면 Smart Contract를 이용하여 교환에 참여한 플레이어들의 인벤토리 변경점을 기록하기만 하면 됩니다. 그러면 모든 내용에 대해서 가용성 100%의 Blockchain이 보증하게 되죠. 서버 프로그램만 다시 살린다면, 서비스는 잃어버리거나, 이전으로 돌아가는 내용없이 플레이어들에게 신뢰도를 줄 수 있습니다.

요즘이야 그런 일이 잘 없지만, 예전에는 결제 버튼을 누르고, 결제 완료 창으로 넘어가기 전에 버튼을 한 번 더 누르면 결제가 한 번 더 일어나는 일이 빈번했고, 같은 주문서 코드에 두 개의 결제가 이루어져, 이런 이중지불을 찾아내는 일도 어렵습니다.

제가 Blockchain은 비가역성을 띤다고 이야기 한 것이 기억 나시나요? Blockchain에서의 거래는 하나의 거래가 오픈되면 단 한번의 결제만 인정됩니다. 같은 거래에 두 번의 지출이 되는 이중지불은 비가역성이라는 특성에 의하여 올바르지 않은 거래로 아예 성립 자체가 불가능하며, 이중지불 자체가 성립 불가능하게 되어, 올바르지 않은 거래로 처리됩니다. 안심하세요!

Smart Contract가 제 3자의 개입없이 작동한다고 말했던가요? Escrow 서비스를 Smart Contract 형태로 구현하고, 작동의 보장을 타인으로 받는다면 어떨까요? 수수료는 Smart Contract작동비만 사용될 것이고, 제품에 대한 보증기간과, 지불에 대한 문제를 완전히 해결할 수 있겠지요!


Ethereum Additional

현재 Ethereum은 PoW 방식의 블럭생성을 하고 있지만, Bitcoin 네트워크의 ASIC은 작동하지 않습니다. Ethereum은 컴퓨터의 일반적인 실행방식을 공유하는 것이 목적이기 때문에, 이러한 블럭만을 생성하는 알고리즘 방식을 개선한 Ethash-Dagger 으로 블럭을 생성하고 검증합니다. 때마다 달라지는 1GB의 Dagger 테이블을 참조하기 때문에 저항성을 가지게 되지요.

이 글을 쓰는 시점에서 전체 네트워크 평균 해시레이트는 1.4 Terahash/sec 이며 블럭 생성에는 17.41Terahash가 평균적으로 필요합니다. Nvidia 970 시리즈에서 10 Megahash/sec. AMD 280X가 20 Megahash/sec정도 속도를 내는데, 이는 어마어마한 컴퓨팅 자원이 Ethereum에 사용되고 있다는 것을 알 수 있습니다.

Ethereum Network Dashboard — https://ethstats.net

현재 4단계의 런칭 프로세스 중에서 두 번째 프로덕션 네트워크로 사용할 수 있는 Homestead가 런칭되었으며, 올해 말 또는 내년 초에 Metropolis 네트워크의 오픈을 예정하고 있습니다. 최종 런칭단계인 Serenity는 블럭 생성 방식인 PoW를 PoS로 변경할 예정이며, 블럭 보상에 관한 내용도 바뀔 예정입니다. 현재 블럭 보상은 5 Ether이며, 최종적으로 이 블럭 보상은 줄어들 것으로 보입니다.

  • Frontier
  • Homestead
  • Metropolis
  • Serenity

이 글에서는 Blockchain에 대한 내용을 비-개발자들도 이해할 수 있는 예시와 표현을 사용하였으나, 좀 더 전문성 있는 글을 원하신다면 White Paper를 참고하시면 되겠습니다. White Paper는 현재도 지속적으로 업데이트 되고 있으며 앞으로의 발전방향과 Blockchain에 대한 상세한 설명이 되어 있습니다. 추가적으로 Homestead에서 필요한 내용들을 모은 가이드 문서 또한 첨부해 두었습니다.


Not Enough?

Smart Contract를 구현하는 Blockchain 플렛폼은 Ethereum만 있는 것이 아닙니다. Linux Foundation과 30개의 다국적 기업이 참여한 HyperLedger 또한 Smart Contract 구현체입니다. 현제 참여한 회사들이 구현체를 각각 만들고 있으며, 아직 어느것하나 컨셉증명을 넘어서진 않았습니다.

또한 R3 Cev라는 곳을 소개하지 않을 수가 없습니다. 미국의 은행들과 전세계 은행들이 연합하여 만든 컨소시움인데, Blockchain을 통하여 통화의 변혁을 일으키기 위한 컨소시움이며, 이 R3에서는 Ethereum을 사용할 예정입니다. (아직 한국의 은행은 컨소시움에 포함되지 않았습니다.)


Blockchain과 Ethereum에 대한 이야기는 이쯤에서 정리를 하면 될 것 같습니다. 개인적으로는 Ethereum이 미래의 플렛폼들 중 하나라고 생각되며 빠른 시일내로 Blockchain 기반 기술들이 심화된 내용으로 여러 입에 오르내리는 때를 기대하고 있습니다.

충분히 많은 이야기를 글에 담았으며, 이해와 기술에 대한 설명이 중간중간 들어갔다고 생각합니다. 의견은 Note나 Response를 활용하여 남겨주세요~ 많은 이야기가 오갈 수 있는 계기가 되었으면 합니다.

읽어주셔서 감사합니다.


반응형

+ Recent posts