2019년 01월 10일 21:36다른 분야 공부/블록체인

EOS, DPOS 핥아보기

본문

이 글은 Hexo 기반의 블로그에서 옮겨온 글이며, 원본 글은 2018년 10월 7일에 작성되었다.

EOS는 수많은 DPOS 기반의 블록체인을 만들어 온 댄 라리머(Dan Larimer)가 주도하여 만든 블록체인이다. 왜 굳이 EOS인가에 대해, 댄 라리머가 한글을 배워 자신의 이름 댄을 영어로 입력하여 EOS라고 이름을 지은 것으로 나는 추측하고 있다.

~~EOS를 한글로 치면 댄이다~~

이름이야 뭐 어쨌든 이 글에서는 EOS 프로젝트의 목적과 특징을 알아보고, EOS 빌드, 테스트넷 가동, 간단한 스마트 컨트랙트 실행을 직접 해 본다.

추가적으로 DPOS의 장단점과 공격 가능 포인트들도 짚어 보았다.

EOS가 무엇일까

먼저, EOS가 무엇인지, EOS 측에서 주장하는 EOS의 특징과 장점이 무엇인지 알아보자.

왼쪽이 EOS의 로고이고, 오른쪽이 EOS를 만든 block.one의 로고이다. 이더리움의 ERC20 토큰을 기반으로 교환이 이루어지다 현재는 독자적인 메인넷을 런칭한 블록체인인 EOS는 Blocktivity에 따르면 현재 가장 활동량이 많은 블록체인이 되었다^[각주:1]. 오른쪽 CoinMetrics의 자료를 보면 EOS의 트랜잭션 수는 폭발적으로 증가했음을 볼 수 있다.

EOS는 일부로부터 "3세대 블록체인^[각주:2]"이라고 불리고 있는데, 이는 기존의 이더리움 체계에서 나타난 여러가지 문제들(대표적으로 Scalability)을 해결하면서 나타난 것이다.

	BTC	ETH	EOS
채굴 (합의 알고리즘)	PoW	PoS	DPOS
스마트 컨트랙트 지원	✕	○	○
통치(Governance) 형태^[각주:3]	Off-chain	Off-chain	On-chain
지연 (블록 포함 시간)	5 ~ 40분	5 ~ 40초	1.5초
트랜잭션 수^[각주:4]	0.22M	0.77M	7.71M
TPS	7 내외	20 내외	수천 TPS^[각주:5]
트랜잭션 비용	사용자 부담 (BTC)	사용자 부담 (Gas)	개발자 부담 (EOS)

위는 다른 블록체인과의 차이를 비교해 둔 것이다. EOS가 채택한 DPOS 합의 알고리즘으로 인해 트랜잭션 수에서 다른 블록체인과 크게 차이가 난다. 특이한 점으로는 EOS에서의 지연 시간에는 범위 표시(~)가 없다는 것인데, 비트코인이나 이더리움은 트랜잭션 비용에 따라 블록 포함 속도가 달라지기 때문에 지연 시간에 차이가 날 수 있지만, EOS는 그런 건 없기에, 트랜잭션이 생성된 이후 가장 최근 블록이 생성될 때 같이 포함된다. 나머지 부분들에 대해서는 아래에서 자세히 설명한다.

EOS의 겉보기 특징

이전 세대 블록체인과는 다른, EOS의 특징을 간단히 알아보자.

1. Scalable

첫 번째는 확장가능하다는 것이다. EOS에서는 EOS.IO가 수많은 사용자들이 동시에 EOS 애플리케이션을 구동할 수 있는 OS라고 홍보하는데, 이를 위해서는 트래픽이 커져도 빠른 속도를 유지하며 작업을 처리하는 것이 중요하다. 이더리움의 스마트 컨트랙트는 이 문제를 해결하지 못해 자주 병목 현상이 발생하곤 한데, EOS에서는 DPOS라는 무지하게 빠른 합의 알고리즘으로 빠른 블록 생성 속도를 구현한다. 또한 DPOS의 빠른 블록 생성 속도를 뒷받침하기 위해 애플리케이션의 병렬 실행을 지원한다. 멀티 체인도 지원한다. 비교를 해보자면, 비자(VISA)가 초당 약 일만 개의 트랜잭션을 처리할 수 있을 때, EOS는 이론 상 약 백만 개의 트랜잭션을 처리할 수 있다. 이를 보았을 때, 아마 EOS의 가장 큰 특징은 이러한 Scalability일 것이다.

2. Governance

두 번째는 통치 방식이다. EOS는 21개의 대표 노드(Block Producer; BP)가 전체 네트워크를 통솔하고 움직이는데, 이들은 투표를 통해 엄청 다양한 일들을 처리할 수 있다. 블록체인을 특정 블록으로 되돌릴 수 있고, 계정 동결, 프로토콜 및 약관의 개정 등 정말 다양한 일을 할 수 있다.

EOS에는 "EOS 헌법"이라는 것이 존재하는데, 아직은 임시 헌법이지만 곧 BP들 사이의 투표를 통해 제대로 된 헌법으로 확정하고 EOS 전체 네트워크의 방향과 활동을 규정하게 된다.

3. Flexible

세 번째는 유연함이다. EOS는 위에서 말한 통치 방식으로, 하드포크하지 않고도 블록체인의 문제점을 손볼 수 있고, 문제되는 DApp이 있으면 해당 DApp만을 정지하고 손볼 수 있다.

또한, Role-Based Access Control 방식을 채택하여, 유저가 불필요한 권한을 가지게 되는 상황을 방지하고 있다. 무슨 말이냐면, 사람에게 권한을 주는 기존의 방법이 아니라, 특정 "역할"에 권한을 미리 다 부여한 다음, 해당 사람의 역할만 바꾸어주어 필요한 권한만 부여될 수 있도록 권한을 관리한다.

EOS는 다양한 VM을 유연하게 지원하여, 이더리움의 스마트 컨트랙트도, 웹 어셈블리로 만들어진 스마트 컨트랙트 등 다양한 컨트랙트 종류를 EOS 네트워크에서 실행시킬 수 있다.

EOS의 세부 특징

이제는 EOS의 특징에 대해 조금 더 자세히 살펴보자.

1. 트랜잭션 비용 없음 (수익 모델)

EOS에는 트랜잭션 비용이 없다. 이더리움은 DApp의 사용자들이 트랜잭션을 보낼 때마다 사용료로 일정량의 Gas를 지불한다. 예를 들어 사용자가 DApp에서 댓글을 작성하려 하거나, 메시지를 보내는 비금융 활동을 하면 그것에 대해서도 사용료를 내야 한다. 하지만 이런 방식은 사용자들이 DApp을 쓰는 데 불편함을 주게 된다. EOS는 더 많은 사람들을 네트워크로 끌어들이고자 DApp 사용자가 아니라 개발자로부터 사용료를 청구한다. 정확히는, 개발자가 가지고 있는 EOS 양에 비례하여 개발자에게 네트워크 대역폭과 연산 처리 능력(CPU)을 할당한다 (개발자로부터 EOS를 가져가는 것이 아니다). 전체 구조적으로 생각해보자면, 사용자는 트랜잭션 비용을 지불하지 않으면서도 블록체인 네트워크 기반 서비스를 사용할 수 있고, 그러면 사용자가 많으면서 DApp의 개발 및 유지비용이 적게 드는^[각주:6] EOS로 개발자들이 모이게 된다. 이렇게 모인 사용자와 개발자로 EOS는 점차 점유율을 높일 수 있고, EOS 화폐 자체의 가치도 높아지면서 EOS 네트워크와 EOS 화폐를 다량 소유한 BP들이 수익을 얻게 되는 것이다.

2. DPOS (Delegated Proof-Of-Stake)

PoW와 PoS

DPOS를 이해하려면 먼저 PoW(Proof-of-Work)와 PoS(Proof-of-Stake)를 알고있는 것이 좋다. EOS를 공부하는 사람이라면 아마 PoW에 대해서는 알고있을 것이므로 PoW에 대해서는 설명하지 않겠다. PoW와 양대 산맥을 이루는 합의 알고리즘으로 PoS(지분 증명)가 있는데, 이는 암호화폐 지분을 많이 가진 사람에게 더 큰 힘을 주고자 하는 것이다. 즉, 동시에 많은 블록이 만들어진다면 지분을 많이 가진 사람의 블록을 채택하는 것이다.

DPOS

DPOS는 PoS와 원리는 같다. 이 둘의 차이는 직접 민주주의와 간접 민주주의로 이해하면 아주 쉬워진다. 둘 다 투표를 통해 무언가를 결정하지만, 직접 민주주의는 구성원 모두가 권리를 직접 행사하고, 간접 민주주의는 대리인을 내세워 그들로 하여금 권리를 행사하게 한다. PoS는 직접 민주주의로, 많은 사람들의 동의를 얻어 블록을 형성하기에 블록 형성에 시간이 오래 걸린다. 이를 해결하기 위해 등장한 DPOS는 지분을 가지고 있는 사람들이 뽑은 소수의 대표들만 투표를 진행하기 때문에 블록이 빠르게 형성될 수 있다. 이러한 DPOS 방식을 채택하는 블록체인에는 스팀, EOS 등이 있다.

EOS에서의 DPOS

그래서, EOS가 DPOS를 어떻게 적용했는지 알아보자. 앞서 말했듯이, DPOS 방식이 PoW와 PoS에 비해 월등히 빠르기에 EOS는 DPOS를 채택할 수 밖에 없었다. EOS는 매 "라운드"마다 126개의 블록을 생성하는데, 이 라운드가 시작될 때 투표를 옽해 21명의 BP(Block Producers)를 선출한다. 이 BP들은 모든 노드를 대표하여 블록을 생산하는 노드가 된다. EOS를 보유한 사람은 1 EOS당 30개의 노드에 투표할 수 있으며, 선출된 대표들은 매 라운드마다 각자 6개의 블록을 만들게 된다. 즉, 21×6=126 인 것이다. 새로운 블록은 21개의 BP 중 15개 이상이 동의하면 체인에 포함된다. 매 초마다 두 개의 블록이 체인에 포함되므로 결국 한 라운드에 1분, 즉 약 1분 동안 126개의 블록이 생성되는데, 이는 10분에 한 블록을 생성하는 비트코인과 비교하면 무척이나 빠른 속도라고 할 수 있다.

이외에 DPOS 공격 가능성과 DPOS Tradeoffs 등 부가적인 내용은 아래에 적어놓았다.

3. TaPoS (Transaction as Proof of Stake)

EOS는 네트워크의 보안을 높이는 기술인 TaPoS를 채택하고 있다. 기존의 PoS/DPOS 방식에서는 일부 노드만이 PoS 계산에 참여했는데, TaPoS는 모든 트랜잭션이 가장 최근 생성된 블록 헤더의 해시값을 포함하도록 하여 트랜잭션을 만드는 모든 노드들이 전체 네트워크의 보안에 참여하도록 한다.

4. Smart Contract Development Using C++

EOS는 이더리움이 Solidity를 사용하듯이, 스마트 컨트랙트 언어로 C++를 사용하고 있다. C++로 작성된 스마트 컨트랙트는 추후 웹 어셈블리로 컴파일되어 WASM 위에서 돌아가게 된다.

EOS 프로그램, 네트워크 구조

EOS 프로그램 구조

EOS는 nodeos, keosd, cleos의 세 가지 프로그램으로 구성되어있다. nodeos는 node와 eos가 결합한 말로, EOS의 블록을 생성하는 가장 주요한 기능을 담당한다. 사용자가 보낸 트랜잭션이 유효한지, 블록이 유효한지 등을 결정하는 하나의 노드 프로그램이다. keosd는 key와 eos가 결합한 말로, 지갑 단위로 키를 관리하는 구성요소이다. 마지막으로 cleos는 CLI와 eos가 결합한 말로, 사용자가 다른 EOS 구성요소에 접근할 수 있는 인터페이스를 제공한다. 즉, 사용자는 이를 이용하여, keosd 및 nodeos에 접근할 수 있다.

간단한 예시를 들어보자면, 사용자는 트랜잭션을 만들기 위해 일단 자신의 지갑에 접근해야 하는데, 이 때 keosd를 거쳐 올바른 키를 사용하여 지갑을 잠금 해제하게 된다. 그 다음 트랜잭션을 만들고, nodeos에 접근하여 트랜잭션 검증을 받은 후, nodeos가 블록체인 네트워크로 해당 트랜잭션을 브로드캐스트하여 블록체인에 트랜잭션이 포함되게 된다.

EOS 네트워크 구조

EOS의 메인넷에는 21개의 Block Producer 노드와 79개의 Backup Producer 노드가 있다. 만일 DDoS 공격 등으로 인해 어떤 Block Producer에게 문제가 생기면, Backup Producer가 그 일을 대신하게 된다. 각각의 노드는 자신이 소유한 EOS 만큼의 투표권을 활용하여 최대 30개의 노드에게 자신의 권한을 위임할 수 있다. 결과적으로, 이를 통해 매 라운드마다 21개의 Block Producer 노드가 투표에 의해 선출된다. 선출된 Block Producer는 각각 블록을 만들어 다른 Block Producer에게 검증을 받고, 블록체인을 잇는다.

각 노드가 EOS를 얼마나 가지고 있는지는 EOS 네트워크에서 DApp을 구현하는 데 영향을 미친다. DApp 개발자는 자신이 가지고 있는 EOS의 양에 비례하여 투표권 뿐 아니라 CPU 할당, 네트워크 대역폭을 보장받을 수 있다.

EOS 설치

이제 본격적으로 EOS를 만나보자. EOS는 자동 빌드 스크립트는 현재 아래와 같은 환경을 지원한다.

Amazon 2017.09 이상
CentOS 7
Fedora 25 이상 (27 추천)
Mint 18
Ubuntu 16.04 이상 (16.10 추천)
MacOS Darwin 10.12 이상 (10.13.x 추천)
Docker 17.05 이상

공식적으로 언급하지는 않았지만, 아래의 OS도 추가로 지원하도록 짜여져 있다.

elementary OS
Debian

이는 데비안이나 엘리멘트리 OS나 둘 다 우분투와 같은 설치 로직을 쓸 수 있기에 같이 지원하는 듯하다. 위 목록에 없는 리눅스 배포판을 사용한다면, 이 링크를 참고하여 직접 빌드해야 한다.

여기서는 도커 환경을 제외한 나머지 리눅스 환경을 기준으로 설명하겠다. 도커 환경에서의 설치 방법은 이 링크를 참조하면 된다. 참고로 위 리눅스 배포판 목록에 있는 리눅스라면, WSL 환경에서라도 잘 돌아간다.

아래의 코드에서, 작업 디렉토리는 홈 디렉토리(~)이다.

1. EOS 소스 코드 다운로드하고 빌드하기

git clone https://github.com/EOSIO/eos --recursive
cd eos; ./eosio_build.sh -s EOS

이 작업은 오래 걸린다. 환경에 따라 다르겠지만, 내 개인 서버 기준으로 약 한 시간이 걸렸다.

2. 빌드 테스트하고 바이너리 설치하기

빌드 테스트

export PATH=${HOME}/opt/mongodb/bin:$PATH
~/opt/mongodb/bin/mongod -f ~/opt/mongodb/mongod.conf &
cd ~/eos/build; make test

몇 개의 테스트는 실패하기도 하지만, 실제 이후 EOS의 동작에는 아무런 문제가 없었다.
이 과정도 아주 오래 걸렸는데, 약 한 시간 반이 소모되었다. 시간이 없는 사람은 그냥 넘어가도 좋을 듯하다.

바이너리 설치

cd build
sudo make install
export PATH=$PATH:/usr/local/eosio/bin

3. 테스트넷 구동

아래 명령어로 테스트넷을 구동해보자.

nodeos -e -p eosio --plugin eosio::chain_api_plugin --plugin eosio::history_api_plugin

여기서 각 파라미터를 설명하면 아래와 같다.

-e : 체인이 정상 체인이 아니더라도 블록을 생성하게 한다.
-p eosio : 이 노드가 통제하는 프로듀서의 ID
--plugin : 활성화 할 플러그인을 지정할 수 있으며, 여러 개를 지정할 수 있다.

만일 EOS 노드를 성공적으로 구동했으면 계속해서 블록을 만드는 로그가 콘솔에 뜰 것이다. 약 0.5초에 한 블록이 생성될 것이다.

4. CLI 실행해보기

이전의 nodeos를 닫지 말고, 다른 터미널에서 아래의 명령어를 입력하여 cleos를 이용해보자.

export PATH=$PATH:/usr/local/eosio/bin
cleos get info

이 커맨드는 현재 블록체인의 상태, 정보를 nodeos로부터 받아와 위와 같이 출력해준다. 위와 같이 출력된다면, 정상적으로 EOS가 설치된 것이다.

EOS Hello-World App 빌드해보기

테스트넷 위에 Hello World 애플리케이션을 설치해보자.

1. 애플리케이션 빌드

EOS 애플리케이션을 빌드하기 위해서는 EOSIO Contract Development Toolkit이 필요하다. 이 링크의 설명을 따라 먼저 툴킷을 설치하자.
이후 미리 작성된 컨트랙트 코드를 git으로 받아 make하여 간단하게 Hello World 컨트랙트를 빌드할 수 있다.

$ git clone https://github.com/yuoa/eos-hello-world
$ cd eos-hello-world; make
Compiling hello.cpp to web assembly files... Finished.

이후 ls 명령어로 결과를 확인해보면 hello.abi, hello.wasm 파일이 생겼을 것이다.

아래는 수동으로 방금 만든 컨트랙트 코드를 테스트하는 방법을 적어놓았는데, 시간이 없으면서도 내 EOS가 작동하는지 확인하고 싶은 사람들은 make test 명령어로 자동 테스트를 해볼 수 있다.

2. 지갑과 개인 키 만들기

방금 만든 애플리케이션을 런칭할 계정이 필요하므로, 만들어주자. 아까 실행시켜둔 nodeos는 계속 켜 두고, 다른 터미널에서 계속 진행한다.

$ cleos wallet create --to-console
Creating wallet: default
Save password to use in the future to unlock this wallet.
Without password imported keys will not be retrievable.
"PW5JXSUH1uTaQarXgSDZgdWzGeWupPFmwd2RtFkzrivudMtu2Xxs2"

이 명령줄의 마지막이 지갑의 비밀번호이므로, 따로 메모해두자.

$ cleos create-key --to-console
Private key: 5KeHEF9xm5E32DMth2K8tFwvcwT9DJohNmycLegwAnCCe3WBejT
Public key: EOS7zgbYJFXRMhcW8MtRyCKv4LS94xVQh7DHGif5ruVmHHYrmqu7d

위 명령줄로 개인/공개 키 쌍을 만들 수 있다. 이제 이 개인 키를 지갑에 추가하자.

$ cleos wallet import -n default --private-key 5KeHEF9xm5E32DMth2K8tFwvcwT9DJohNmycLegwAnCCe3WBejT
imported private key for: EOS7zgbYJFXRMhcW8MtRyCKv4LS94xVQh7DHGif5ruVmHHYrmqu7d

3. BIOS 컨트랙트 구동

이제 EOS 테스트넷에 BIOS 컨트랙트를 구동시킬 차례이다. BIOS 컨트랙트는 개발의 목적으로, 다른 계정의 리소스 할당이나 권한이 필요한 내부 API 호출 등을 직접적으로 가능하게 해 주는 컨트랙트이다. 아래의 명령으로 바이오스 컨트랙트를 로드할 수 있다.

$ cleos wallet unlock --password PW5JXSUH1uTaQarXgSDZgdWzGeWupPFmwd2RtFkzrivudMtu2Xxs2
Unlocked: default
$ cleos wallet import --private-key 5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3
imported private key for: EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV
$ cleos set contract eosio ~/eos/build/contracts/eosio.bios -p eosio
Reading WASM from ~/eos/build/contracts/eosio.bios/eosio.bios.wasm...
Publishing contract...
(the rest omitted)

여기서 난데없이 5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3이라는 개인 키를 추가하는데, 이는 EOS 테스트넷을 만들 때 내부적으로 쓰인 키로, 바이오스 컨트랙트를 로드 및 구동하는 데 필수적이다.

참고로, EOS 메인넷에서 바이오스 컨트랙트는 EOS 보유량에 따른 CPU 및 네트워크 대역폭 할당을 담당하고 있다.

4. 테스트용 계정 만들기

아까 빌드한 스마트 컨트랙트를 테스트하기 위해 계정 두 개(user, test)를 만들어주자.

cleos create account eosio user EOS7zgbYJFXRMhcW8MtRyCKv4LS94xVQh7DHGif5ruVmHHYrmqu7d EOS7zgbYJFXRMhcW8MtRyCKv4LS94xVQh7DHGif5ruVmHHYrmqu7d
cleos create account eosio test EOS7zgbYJFXRMhcW8MtRyCKv4LS94xVQh7DHGif5ruVmHHYrmqu7d EOS7zgbYJFXRMhcW8MtRyCKv4LS94xVQh7DHGif5ruVmHHYrmqu7d

아까 생성한 개인 키/공개 키 쌍을 사용해 두 개의 계정을 만들고 나면, 아래와 같이 두 개의 계정이 성공적으로 등록되었음을 볼 수 있다.

$ cleos get accounts EOS7zgbYJFXRMhcW8MtRyCKv4LS94xVQh7DHGif5ruVmHHYrmqu7d
{
  "account_names": [
    "test",
    "user"
  ]
}

5. `nodeos` 설정 바꾸기

마지막으로, Hello World 메시지가 콘솔에 직접 표시되도록 nodeos의 설정을 바꿔 주어야 한다. 최신 EOS에서는 기본적으로 표준 출력이 표시되지 않게 설정되어 있어, config.ini 파일에서 contracts-console 항목을 바꿔 준다.

cd ~/.local/share/eosio/nodeos/config/

이 디렉토리에서 config.ini를 열고, 중간의 contracts-console = false를 contracts-console = true로 바꾸어 준다. 이후 nodeos를 재시작하자.

nodeos -e -p eosio --plugin eosio::chain_api_plugin --plugin eosio::history_api_plugin

6. 스마트 컨트랙트 구동하기

드디어 스마트 컨트랙트를 구동할 차례이다! 아까 전, 스마트 컨트랙트를 빌드했던 디렉토리로 돌아가서 아래 작업을 진행하자.

$ cleos set contract test . hello.wasm hello.abi -p test
$ cleos push action test greet '["Belli Dura Despicio"]' -p user
executed transaction: 54ad914ea76831ac248fd1930461aff03089cf01e6cfa87e08fc44cec6831969  104 bytes  725 us
#    test <= test::greet               {"user":"user"}
>> Hello world, hello Belli Dura Despicio!

이는 nodeos이 실행되고 있는 터미널에서도 확인할 수 있다. 아래의 로그를 보면 트랜잭션 하나가 블록에 포함되었음을 알 수 있다.

…
2018-09-06T20:53:41.069 thread-0   apply_context.cpp:28          print_debug          ]
[(test,greet)->test]: CONSOLE OUTPUT BEGIN =====================
Hello world, hello Belli Dura Despicio!
[(test,greet)->test]: CONSOLE OUTPUT END   =====================
2018-09-06T20:53:41.500 thread-0   producer_plugin.cpp:1302      produce_block        ] Produced block 000147bc376605d3... #83900 @ 2018-09-06T20:53:41.500 signed by eosio [trxs: 1, lib: 83899, confirmed: 0]
…

DPOS: Tradeoffs and Attacks

이 부분은 부록같은 느낌으로 작성하였다. 여기서는 DPOS의 장단점과 공격 가능한 요소들을 살펴본다.

DPOS Tradeoffs

A. 블록 프로듀서와 탈중앙화

Delegated Proof of Stake is too centralized: True 50%, False 50%

DPOS는 지분을 가진 사람이 일부 사람에게 자신의 결정권을 위임하기에, 'Controlled Semi-Centralization'이라고 할 수 있다. 여기서 우리는 기존의 PoW나 PoS에서 항상 문제가 되어 온 '의사 결정의 효율성과 속도'라는, 중앙화의 장점을 잡을 수 있게 되고, 또 지분을 가진 사람으로부터의 선출이라는 점에서 탈중앙화의 장점 또한 잡게 된다. 하지만 그래도 기존의 방식과 비교해보았을 때, "중앙화 된다"는 점에서 일부 사람들은 DPOS를 지지하지 않는다. 또한 '중앙화의 정도'가 결정되는 중요한 요소인 "몇 명의 후보를 블록 생산자로 선출해야 적당히 효율과 탈중앙화를 모두 잡을 수 있는가" 또한 중요한 문제가 된다.

B. 체인 내부 통치 (On-Chain Governance)^[각주:7]

On-Chain Governance는 블록체인의 정책을 결정하는 권위체가 블록체인 내부에 있다는 것을 의미한다. EOS에서는 선출된 21명의 BP가 EOS의 정책과 방향성에 대해 토의하고 결정한다. 이는 비트코인 개발자들이 비트코인 블록체인 외부에서 활동하며 메일링 리스트를 두고 비트코인 체계를 관리하는 Off-Chain Governance와는 다른 방식이다. DPOS는 모든 블록체인 네트워크가 정치적이고, 정치 과정을 공식화하려고 한다는 것을 인정하는 방식이다. On-Chain Governance는 일부 사람들이 문제를 제기하기도 하지만, 이는 DPOS의 핵심 특징이다. DPOS는 공개적이고 분산된 구조이며, 결과적으로 중앙화된 권력이 아닌, 커뮤니티의 소유이다.

결론적으로, On-Chain Governance가 다른 블록체인 운영 방식과 비교했을 때 더 나은지, 더 나쁜지는 아직 분명하지 않으며, 앞으로 계속해서 테스트되어야 한다.

Possibility of Attacks

이제 DPOS 네트워크가 어떻게 공격받을 수 있을지 생각해보고, DPOS가 그 공격 방법으로부터 안전한지도 생각해보자.

A. Nothing at Stake

여기서 'At stake'라는 말은 "위험에 처하다" 라는 뜻이다. 즉, "Nothing at Stake"는 "아무것도 위험하지 않다"는 뜻이다. 이는 노드의 입장에서 말한 것인데, 어떠한 악의적인 개입으로, 유효해 보이는 블록체인이 두 개 이상 존재하게 되었을 때, 그 두 개 블록체인에 모두 블록을 생성해도 손해가 없으므로, 보상 확률을 높이기 위해 두 블록체인에 모두 블록을 생성하는 행위를 하게 된다는 것이다. 이는 본디 PoS 방식의 문제이기도 하다.

하지만 DPOS는 이런 공격에 취약하지 않다. 일정 수의 대표가 매 라운드마다 선출되어, 순서대로 블록을 생성하기 때문에 가장 긴 블록을 형성함으로써 체인에 공격을 가하기는 힘들다. 또한 다수의 대표들이 악의적으로 몰래 체인을 형성하고 있더라도, 정직한 소수의 대표들이 있다면 체인의 길이에 의한 공격은 실패가 된다.

~~물론 모든 노드가 악의적이라면...~~

B. Exploit Low Voter Turnout

PoS에서는 자신의 가진 지분에 비례하여 투표에서의 힘을 가진다. 매우 적은 지분을 가진 사람들은 투표를 하는 방법에 대해 찾아보는 그 노력에 비해 상응하는 보상을 받기는 어렵게 된다. 이런 현상으로, 10%의 지분의 블록이 투표에 참여했다고 한다면 5%의 지분을 가진 "고래"가 이를 악용하여 자신이 원하는 대로 정책을 결정할 수 있는 문제가 생긴다.

하지만 DPOS에서는 자신의 지분에서 나오는 투표권을 위임할 수 있으므로, 간접적으로 전체 투표율에 기여하게 된다. 이로써, 단순히 5%의 소유로 블록 형성에 관여할 수 있었던 '중앙화'의 위험에서 벗어나게 된다.

C. Bribing Attacks

DPOS에서는 블록 생성 권한을 토큰 소유자로부터 위임받기 때문에, 많은 사용자로부터 권한을 위임받을수록 자신이 블록 생성 노드가 될 확률이 높아지고, 더불어 채굴로 인한 보상을 받을 가능성도 커진다. 이를 이용해, 일부 노드가 "나에게 투표하면 내 채굴 보상의 일부를 나눠주겠다"며 접근했고, 일곽에서는 가장 많은 보상을 주는 노드를 알려주는 사이트까지 등장했다. 하지만 이는 DPOS 네트워크의 발전을 저해하며, 보안상 큰 문제를 야기할 수 있다. 악의적인 의도로 사용자로부터 권한을 위임받아 블록을 생성할 수 있는 것이다. 이는 실제로 스팀잇이나 리스트 등의 DPOS 기반 블록체인에서 일어났던 일이다.

하지만 우리의 EOS는 이 문제로부터 안전하다. EOS 블록체인에 참가하는 모두가 동의해야 하는 EOS 헌법에는 "투표권을 사서는 안된다^[각주:8]"라는 내용이 명시가 되어 있어, Bribing Attack을 시도하는 노드는 바로 네트워크에서 퇴출될 것이다. 또한 각 BP는 유일한 수입원인 블록 채굴 보상만으로 BP의 공약 중 하나인 "안정적인 네트워크와 유효한 블록체인을 유지한다^[각주:9]"를 이행해야 하므로, 퇴출당하지 않으려면 꽤 많은 양의 돈을 인프라 유지에 사용해야 할 것이다. 이로써 Bribing Attack은 조금 더 힘들어진다.

D. Attacks at Scale

기본적으로 블록 생산자들은 DPOS 네트워크에 자신의 CPU나 네트워크 등의 리소스를 제공한다. 여기서 문제가 발생할 수 있는 부분은 "거대한 리소스를 제공하는 BP가 블록 생산에서의 실수에 의해 쫓겨났을 때" 이다. 거대한 리소스가 한 번에 사라지면 네트워크의 능력은 현저히 떨어진다. 블록 생산 수, 제공되는 리소스 자원이 큰 폭으로 줄어들고, 전체 DPOS 네트워크는 운영에 힘이 부치게 된다. 쫓겨난 BP 대신 새로 선출된 BP가 기존의 BP와 같은 리소스 능력을 가지고 있으리라는 보장도 없다. 아직 실제 사례는 없지만, 전체 네트워크를 손상시킬 수 있는 한 가지 방법은 이와 같이 거대한 리소스를 가진 BP를 퇴출시키는 것이다.

E. Block Producers Collude

DPOS에서는 블록을 형성하는 대표자의 수가 적기 때문에 단합이 가능하다. 단합으로 저지를 수 있는 수많은 가능성 중 하나는 Censorship이다. 이들은 단합하여 마음에 들지 않지만 유효한 트랜잭션을 거부할 수 있다. 또 다른 가능성 중 하나는 프로토콜 변경이다. 악의적인 블록 제작자는 프로토콜을 변경하여 블록 생성 보상 변경, 특정 지분 소유자 추방 등 여러 일을 벌일 수 있다. EOS에서는 이를 막기 위해 21명 중 17명 이상의 동의가 있어야 프로토콜을 개정할 수 있도록 하고 있다. 또 다른 가능성 중 하나는 이중 지불 공격이다.

여러 노드들이 협의한다면 정말 못 할 일이 없게 되는 것이 DPOS의 단점이다. 소수의 블록 프로듀서가 자신의 차례에 이런 일을 벌인다면 블록은 거절 당할 것이고, 단순히 다음 블록이 몇 초 늦게 만들어지는 정도의 타격이 될 것이다. 그 소수 블록 프로듀서는 물론 자신의 명성과 미래의 수입 등 많은 부분에서 큰 타격을 입게 될 것이다. 하지만, 대다수의 BP들이 악의를 가지고 협동한다면 못할 일은 전혀 없을 것이다.

F. Distributed Denial-of-Seretvice Attack (DDoS)

DPOS의 경우, 블록을 형성하는 대표들은 IP 주소와 각 라운드마다 무작위로 결정된 블록 생성 순서가 공개되어 있기 때문에 충분히 DDoS 공격의 대상이 될 수 있다. 하지만 DPOS에는 예비 블록 프로듀서(백업 프로듀서)가 항상 대기하고 있기 때문에, DDoS 공격은 효율성이 떨어진다. 매 라운드마다 계속 BP가 바뀌므로, DDoS를 대다수의 블록 프로듀서에게 공격한다고 해도 일시적인 타격에 불과할 것이다. 참고로, EOS에서는 21명의 BP 중 한 BP가 제 기능을 못하게 되면 그 다음으로 투표를 많이 한 22번쨰 백업 프로듀서가 진짜배기 BP가 된다.

참고한 문서

EOS를 공부하면서 정말 수많은 문서를 보았다. 대부분 나보다 글을 잘 썼고, 내 글의 일부 부분은 그들 문서의 단순한 번역이 되기도 한다. 좋은 문서를 만들어 주신 모든 분들께 진심으로 감사의 말을 전하고 싶다.

이미지 출처

아래 적힌 출처 이외의 이미지는 내가 만든 이미지이다.

EOS, 블록원 로고 ー eos.io, block.one
EOS 프로그램 구조도 ー developers.eos.io
On-Chain-Governance (왼쪽 EOS DApp 도표) ー abdulqadir01@steemit
Off-Chain-Governance (오른쪽 꼭두각시 조종 손 일러스트) ー John Edward Hind
Off-Chain-Governance (오른쪽 비트코인 네트워크 도표) ー altcointoday.com
Nothing at Stake 설명 도표 (공격) ー franceos.fr
Nothing at Stake 설명 도표 (방어) ー multicoin.capital

이렇게 EOS와 DPOS에 대해서 간단히 수박겉핥기식으로 알아보았다. 다음에는 무엇을 공부해볼까...

2018년 10월 기준으로, BitShares가 1위를 가져갔다. [본문으로]
1세대는 "화폐"로서의 블록체인으로, 비트코인 등이 해당하고, 2세대는 "스마트 컨트랙트"를 등장시킨 것으로, 이더리움이 대표적이다. [본문으로]
후술하겠지만 Off-chain이란 블록체인의 정책과 방향을 결정하는 권위체가 블록체인 외부에 있음(블록체인에 참가하지 않음)을 뜻하고, On-chain은 그 반대의 개념이다. [본문으로]
출처: 2018년 8월 15일 기준이며, ~~EOS 설명 글이니 EOS를 띄워 주기 위해 좋을 때를 찍은 것이다~~ coinmetrics.io [본문으로]
2018년 10월 기준으로, 메인넷이 겪은 최대 TPS는 약 4000 TPS이다. [본문으로]
실제로 들어가는 돈이 이더리움보다 훨씬 적다고 한다. [본문으로]
On-Chain Governance는 무조건적인 DPOS의 특징은 아니지만, DPOS를 따르는 블록체인들은 DPOS를 채택하는 이유인 성능상의 문제를 살리고 DPOS의 권한 위임이라는 특징을 살리기 위해 대부분 On-Chain Governance를 채택하는 것으로 보인다. [본문으로]
이 페이지에서 EOS 헌법을 볼 수 있다. [본문으로]
이 페이지에서 EOS 메인넷의 BP가 되기 위한 BP의 약속문을 볼 수 있다. [본문으로]

저작자표시 동일조건