EOSIO Dawn 4.0을 소개합니다.(주석 첨부)

Morgan Lim

Published in

EOSYS

22 min readMay 7, 2018

Translated Contents

원문 : https://medium.com/@bytemaster/introducing-eosio-dawn-4-0-f738c552879

*독자분들을 위하여 : 제 개인적인 이해를 바탕으로 번역을 할 때 접속사를 대입하거나 의역을 한 부분이 있습니다. 해당 부분을 참고하셔서 읽어주시기 바랍니다.

EOSIO Dawn 4.0을 소개합니다.

블록원이 EOSIO 3.0 Dawn을 소개한 지 한 달의 시간이 흘렀습니다. 지난 달동안 저희 팀은 EOSIO 소프트웨어의 안정화와 정리를 하는 것에 초점을 맞추어 왔습니다. 이 작업의 대부분을 블록체인간 통신을 위한 개념증명(Proof of Concept : PoC)으로 옮겨가는 것에 힘써왔습니다.

merge를 제외하면, 개발자 43명은 깃헙에 커밋 818개의 푸시를 하였습니다. 이로 인하여, EOSIO는 지난 달에 가장 활발히 작업한 8개의 C++프로젝트 중 하나로 꼽혔습니다. 보시다시피, 많은 변화가 일어났습니다.

Now가 이제 현재 시각을 가르키게 되었습니다.
시장 기반의 새로운 RAM 할당 모델
블록체인간 통신의 도입
DPOS의 마지막 비가역 블록 알고리즘을 업그레이드 했습니다.
고유 계정 명 도입
블록헤더만 검증
경량 블록프로듀서 일정 변경 증명
블록 프로듀서에 대한 새로운 보상 방식
프로듀서 투표 영향력 상실
거래소 통합 지원

Now는 이제 현재 시각을 가르키게 되었습니다.

EOSIO Dawn 4.0의 가장 큰 변화중 한가지로 우리는 현재 시각의 정의를 “헤드(head) 블록의 시간”에서 “현재(current)블록의 시간”으로 변경하였습니다. 이런 변화로 인하여, 블록생성을 놓치게 하는 시간 기반의 많은 코너케이스(cornor case) 문제를 해결하고, 스마트 컨트랙트 내에서 소요 시간을 훨씬 정확하게 측정 할 수 있게 되었습니다.

(역자 주 : 코너케이스는 프로그래밍 용어로서, 여러 가지 변수와 환경의 복합적인 상호작용으로 발생하는 문제를 말합니다. 예를 들어 fixnum이라는 변수의 값으로 128이 입력되었을 때, A라는 기계에서 테스트는 문제가 없는 반면 B 기계에서 오류가 발생한다면 코너 케이스라고 말합니다.
대부분의 블록체인 시스템이 그러하듯이 EOSIO의 경우도 싱글코어(Single Core)가 아니라, 분산원장 기반의 멀티 코어(Multi Core)이므로 이런 오류가 잘 발생합니다. 특히, 기존의 헤드 블록기반 시간 설정은 BP 및 블록 별로 설정되는 시간이 달라서, 코너 케이스 오류를 자주 발생시킬 가능성이 존재했습니다.허나, EOSIO Dawn 4.0에서는 시간을 현재 생성되는 블록의 시간으로 통일시켜 시간과 관련된 코너 케이스 오류의 발생가능성을 낮추었다는 것이 핵심입니다.)

RAM 분배 모델

테스트 과정속에, 우리는 EOSIO 시스템의 컨트랙트가 토큰으로 지분 참여한 사용자들에게 RAM(데이터베이스 공간)을 할당하는 것이 향후 RAM에 대한 결핍을 발생시킬 수 있다는 사실을 알아냈습니다. 따라서, 저희 팀은 Bancor 알고리즘을 사용한 시장 기반의 할당방식으로 전환하였습니다.

계산 결과에 따르면 1TB이 토큰 보유자들에게 보유 토큰량에 비례하여 할당할 경우 바이트당 비용은 $0.018(토큰 당 가격을 $20로 가정)입니다. 그러나 현실에서는 대부분의 토큰 보유자들이 할당받은 RAM을 적극적으로 사용할 필요가 없습니다. 그러므로, 우리는 초기 RAM의 가격 정책을 바이트당 $0.000018(토큰당 $20로 가정로 책정했습니다. 새 계정의 경우 약 4KB의 RAM이 필요하므로 약 $0.10의 비용이 필요합니다. RAM이 예약되는 양에 따라 시스템의 RAM이 부족해지기 전에 가격이 무한대로 상승하도록 증가됩니다.

Dawn 3.0의 시스템 컨트랙트에서는 RAM을 구입한 가격에 대해서만 RAM을 판매할 수 있습니다. 즉, 투기와 사재기에 대하여 억제하는 것이 주 목적이였습니다. 이런 접근법의 단점은 초기에 RAM을 저렴하게 구매한 사용자들이 RAM의 수요가 많아져서 정체될 때, 자신의 RAM을 다른 사용자들을 위해 제공할 경제적인 동기가 없는 것입니다. Dawn 4.0의 시스템 컨트랙트에서는 현행 시점의 시장 가격으로 RAM 할당액을 매입하고 판매합니다. 이런 방식은 트레이더로 하여금 미래에 발생할 잠재적인 부족분을 예상하게 하여 RAM을 매입하게 만들 수도 있습니다. 전반적으로 시장이 시간이 흐름에 따라서 RAM에 대한 수요와 공급의 균형을 맞출 것입니다.

시간이 지남에 따라 무어의 법칙은 블록 생산자들이 4TB 또는 16TB의 램으로도 업그레이드를 할 수 있게 만들며, 이러한 RAM의 증가분은 EOSIO RAM시장의 가격을 인하시킬 것입니다.

(역자 주 : 기존 EOSIO에서는 토큰을 홀딩하는 사용자들에게 보유 토큰에 비례하여 RAM을 할당하였으나, 이러한 정책이 향후 증가할 사용자의 수요 대비 공급 부족으로 이어질 수 있습니다. 따라서 4.0에서는 RAM에 대한 가격정책 변화와, RAM 시장의 형성을 통하여서 시장이 RAM에 대한 수요-공급문제를 해결하도록 도와줍니다.)

스마트 컨트랙트 개발자에게 주는 영향

스마트 컨트랙트 개발자에게 있어서, RAM은 데이터 베이스 기록을 저장할 때마다 소모되는 귀중한 자원입니다. RAM의 비용을 고려하면, 인메모리(in-memory) 데이터베이스에 저장하는 데이터의 양을 최소화하고, 사용자가 어플리케이션 사용을 종료한 후에 RAM을 비울 수 있도록 어플리케이션을 설계하는 것이 중요합니다. 예를 들어, Steem은 1주 분량의 컨텐츠만 RAM에 저장하므로, 시간이 지나도 RAM의 전체 크기가 증가하지 않습니다.

투기최소화

RAM 시장이 생겨났으므로, 투기꾼들은 RAM의 가격 변동성을 이용하여 이익을 보기위해 거래할 수도 있습니다. EOSIO 시스템 컨트랙트는 RAM은 양도할 수 없게 만들고 거래에 대해서는 1 %의 수수료를 부과합니다. 이런 수수료로 토큰을 시장에서 꺼내어 자연적인 토큰의 물가상승률을 상쇄하게 합니다. RAM의 연간 거래량이 토큰 공급량과 같으면, 모든 블록 프로듀서들에 대한 보상이 RAM 시장 수수료로 100% 충당됩니다.

(역자 주 : EOSIO 4.0은 EOS 토큰외에도 RAM시장이 존재합니다. RAM 시장에서 거래를 위해서는 이더리움과 같이 거래에 대한 수수료(1%)를 지불해야 합니다. 대역폭을 사용하므로, 거래 시 수수료를 내지 않는 EOS 토큰과 달리 RAM거래는 수수료를 부과하고 이런 수수료들이 모여 블록 생산자(BP)에 대한 보상을 충당할 수 있는 정책적인 변화입니다. 또한, 물가상승률 이상으로 시장에서 토큰 수요를 발생시키므로, 물가상승률로 인한 토큰의 가치 하락을 막아줍니다.)

블록체인간 통신의 도입

고성능 블록 체인은 디스크 접근에 소요되는 시간이 트랜잭션 처리량을 초당 수백회 수준으로 감소시키므로, 모든 데이터를 RAM에 저장해야 합니다. RAM 사용량을 확장시키기 위하여, 독립적인 하드웨어에서 동작하는 개별 메모리 리젼(region)으로 구성된 다중체인(multiple)이 필요합니다.

EOSIO 블록 프로듀서들은 여러 체인을 이용하여 RAM구매와 대역폭 할당을 위해 사용하는 동일한 토큰을 이용할 수 있습니다. 프로듀서 선출은 메인체인에서 이루어질 예정이며, 관련된 모든 사이드 체인은 동일한 프로듀서군에 의하여 운영될 것입니다. 체인들은 각각 고유한 1TB이상의 RAM을 가질 수 있으며, 분산 응용프로그램들은 몇 초만 지연하면 체인 간 메시지를 전송할 수 있습니다.

RAM의 가격은 체인 별로 다를 수 있고, DAPP 개발자들에게 어느 체인의 운영비용이 저렴한 지 알려줄 것입니다.

병렬처리를 위한 로드맵

블록체인간 통신(Inter Blockchain Communication: IBC)는 크기가 1KB이상이고 수십개 이상의 암호화 함수 및/또는 15개 이상의 서명검증을 포함하는 머클(merkle)증명의 유효성을 검사하는 두 개의 체인 사이에서 일어납니다. 즉, 다른체인의 메시지를 확인하는 데 소모하는 비용은 정상적인 트랜잭션을 확인하는 비용보다 약 15배에서 30배 정도 높습니다.

다행히도 이러한 증명을 검증하는 것은 블록체인의 상태에 의존하지 않으므로, 병렬화하는 것이 쉽습니다. 다른 체인의 메시지만 처리하는 블록체인은 초당 수 천개의 트랙잭션을 유지하면서 30개의 CPU 코어를 사용할 수도 있습니다.

우리는 블록체인간 통신을 통한 확장이 거의 무한한 확장 가능성을 제공할 수 있다고 믿고 있습니다. 이 방식을 통하여 RAM, 네트워크, 그리고 CPU까지 동시에 가용성을 확장시킬 수 있습니다. 서명 확인, 컨택스트-무료-행동-검증(context-free-action-validation) 및 IBC 증명만으로 이미 단일 스레드 처리량이 높은대부분의 CPU를 포화상태로 만들 것이라는 점을 감안할 때, 다중 스레드 WASM 실행을 위한 최적화는 다른 자원의 제약으로 인하여 병목 현상을 발생시킬 수 있습니다.

EOSIO Dawn 3.0에서는 미래의 다중 스레드 WASM실행의 가능성을 염두하고 많은 디자인 결정을 내렸습니다. 허나, 실제로 완전한 다중 스레드 구현을 실행할 때까지 저희 팀이 모든 코너 케이스를 검토하였는지 그 여부를 알 수 가 없습니다. 즉, EOSIO Dawn 3.0에는 아키텍쳐가 복잡하여, 서비스를 사용하는데 당장의 이익을 줄 수가 없었습니다.

(역자 주 : 본문에서 계속 언급되는 WASM은 웹 어셈블리(Webassembly)의 약자입니다. 간단히 말해서, C,C++의 native 언어로 짠 프로그램을 웹에서도 동일한 속도로 돌려보는 것이 목적입니다. 현재, 가장 빠른 언어 중 하나인 C,C++기반의 프로그램을 웹에서도 작동하게 만드는 WASM은 어플리케이션 구동을 목적으로 하는 플랫폼인 EOSIO에서 매우 중요합니다. 이와 별개로, 이번 챕터에서는 블록체인간 통신(IBC)를 소개합니다. 현재는 IBC로 인한 자원소모가 심하기에, 위에서 언급한 다중 스레드의 WASM 모델은 고려하기 힘드나, 이런 문제점들을 고치려 한다는 의지를 보이고 있습니다.)

이제 우리는 단일-스레드에서 다중-스레드로 실행으로 업그레이드 하는 과정이 동일한 블록 프로듀서가 다중-스레드 지원을 실행하고 동일한 네이티브 토큰으로 지분참여를 할 수 있는 새로운 체인을 만드는 것이라 믿습니다. 따라서, 새로운 체인은 라이브 체인의 전체 업그레이드를 덮어쓰기(in-place upgrade)하지 않고, 다중 스레드 작업을 하는 데 필요한 설계 수정을 할 수 있는 권한(freedom)을 얻습니다. 이런 병렬처리 로드맵을 통해서 EOSIO 1.0을 단순화하고 쉬운 개발과 단일-스레드 성능을 최대화 하기 위한 최적화를 진행할 수 있습니다.

이와 같은 병렬처리 로드맵을 통하여, 우리는 EOSIO 1.0을 단순화하고 단일-스레드의 성능을 최대 성능과 개발 용이성을 최적화할 수 있습니다. 우리는 EOSIO의 단일-스레드 버젼이 언젠가는 5,000에서 10,000TPS까지 도달할 수 있다고 예상합니다. 또한 다중 체인 방식들이 전체 비용을 낮추고, 빠르게 확장할 수 있도록 해주기 때문에, 많은 어플리케이션들이 다중체인 방식을 선호할 것이라고 예상합니다.

DPOS의 마지막 비가역 블록 알고리즘을 업그레이드 했습니다.

컨센서스 알고리즘에 관한 논쟁을 팔로우 하고 있던 사람들은 마지막 비가역 블록(LIB)알고리즘을 사용하는 DPOS가 특정하고 극단적인 네트워크의 끊김이 발생하는 상황에서 합의가 이루어지지 않을 가능성이 있다는 의견을 들었을 것입니다.

과거에는 이런 실패들이 순전히 이론적인 특성을 가지고 있고 상대적으로 최소한의 비용과 장애시간을 소모할 것이란 생각에 이러한 잠재적인 위험 요소들을 거들떠 보지도 않았습니다. LIB알고리즘은 비트코인의 6-block 규칙과 같은 하나의 기준입니다. 순수한 DPOS는 항상 최후의 합의에 도달할 수 있는 가장 긴 체인의 법칙을 따릅니다. LIB 알고리즘은 undo-기록을 최적화하고, 거래에 대한 신뢰도를 제공하기 위하여 제공하기 위하여 설계되었습니다.

(역자 주 : 1)비트코인의 6-block은 블록체인의 시초인 비트코인의 채굴난이도를 가르키는 말입니다. 1시간에 6개의 블록의 채굴하는 것을 목표로 네트워크는 수학적인 채굴난이도의 값을 조정합니다. 즉, LIB 알고리즘은 이런 ‘6개의 블록같이 EOS내에서 하나의 기준이다’ 라는 말을 강조하기 위하여 본 단어를 사용한 것입니다.
2)비가역 블록알고리즘이란, 2/3 + 1명의 BP가 컨펌하는 블록이 가장 긴 체인이라는 알고리즘입니다. 네트워크가 절단되면 BP들이 생산하는 포크들이 합의를 이루지 못 하고 길어지게 되는 상황에서 2/3 + 1의 컨펌을 얻은 체인만이 공식적으로 인정받는 것이지요.
허나, 극단적인 네트워크 상황(통신이 연결되는 지역을 제어하고, 분단위 간격으로 두 번이상을 제어하는 : 통신사가 개입해도 힘든 상황입니다.)에서는 두 개의 노드가 서로 다른 비가역 블록에 붙는 상황을 만들 수도 있습니다. 댄 라리머가 위와 같은 상황에서 발생할 수 있는 ‘두 개의 노드가 붙기에 합의가 불가능하다’라는 논쟁에 대하여 답변하는 것입니다.)

EOSIO의 IBC 알고리즘은 최종성을 확인하기 위하여 DPOS LIB에 의존합니다. IBC를 도입하면, LIB 실패와 관련된 비용과 이를 수정하는 난이도가 훨씬 어려워집니다. 우리 팀중에서도 특히, Bart와 Arhag는 1/3이상이 비잔틴이 되지 않는 이상 두개의 체인으로는 서로 다른 LIB에 접근하는 것이 불가능함을 보장하는 우아한 개선 방안을 제시하였습니다. 게다가, 단일 피어의 비잔틴 행위를 탐지할 수도 있습니다. 자세한 내용은 본 링크(번역본)를 참고하십시오.

Bitcoin이나 Ethereum 블록의 최종성이 부족하기 때문에 레거시(legacy)체인과 블록체인간 통신을 어렵게 만들고 지연시간을 많이 걸리게 합니다. DPOS에 추가된 시스템 조정사항으로 새로운 수준의 비잔틴 장애 허용(byzantine fault-tolerant)최종성과 모든 네트워크 환경에서의 견고함을 만들었습니다.

(역자 주 : 종합해서 설명 드리겠습니다. DPOS 알고리즘은 2단계로 이루어 집니다. 첫 번째로 EOSYS 나 EOSeoul같은 블록 프로듀서(통칭 BP)를 선정하는 단계, 두 번째는 블록 생성의 일정을 정하는 단계입니다.
BP들이 선정된 이후, 블록 생상을 위한 합의를 이루기 위해서는 2/3 + 1명의 동의가 필요합니다. 정상적인 작동상태라면 BP들은 3초마다 블록을 만들고 자기 차례를 잘 지킨다면 가장 긴 체인에 자연스레 블록을 붙일 것입니다. 허나, 가정을 해보면 최대 1/3의 노드들이 해킹되거나 비정상적으로 작동할 수 있으며, 이 경우에 소수(1/3)의 포크가 이루어 집니다. 소수 그룹은 원하는 대로 포크를 만들 수 있습니다만, 만들어진 포크는 다수 그룹(2/3)보다 항상 짧게 됩니다. 위에 설명한 상황을 A로 가정하겠습니다.
일반적인 네트워크 절단 상황에서는 블록의 연결이 끊어지고, 어떠한 포크도 다수 포크가 될 수 없습니다. 이런 경우 네트워크 연결이 되 살아난다면 소수 포크들이 긴 체인으로 옮겨탈 것이고 2개의 포크가 같은 수의 블록을 가져도 순서를 랜덤하게 섞는 BP 셔플링을 통하여 해결이 가능합니다.
댄 라리머가 본 문단을 쓴 이유는 이러한 상황이 통하지 않는 극단적인 네트워크의 절단이 있을 때, ‘A의 체인 길이와 다수 그룹의 체인이 합의를 이루지 못 할 가능성이 있다’라는 주장에 대하여서, 쓴 글입니다. 링크에 해결책이 나와있지만, 요약하자면 멀티 체인으로 구성되어 있는 이오스에서는 이런 소수그룹(A)가 서로 다른 LIB에 접근하는 것이 불가능하고 극단적인 네트워크 상황이 일어나도, 가장 긴 체인을 선택하거나 동일한 블록이면 BP 셔플링 혹은 TaPoS(Transaction as Proof of Stake)같은 방법을 사용하면 됩니다. 해당 링크나 키워드를 검색해보시면 더 자세한 정보를 얻을 수 있습니다.)

계정명 선점

몇 사용자 분들은 EOSIO 계정 이름에 사용할 수 있는 글자를 12자로 한정 지은 것에 대해서 우려를 표시했습니다. 12문자를 기반으로 한 이름은 64 비트 정수의 base-32 인코딩에서 나온 원리입니다. 64비트 정수는 기본적인 컴퓨터의 단어 크기이므로 매우 효율적입니다. 트랜잭션 내에서 계정이름을 여러 번(코드,범위,허가등) 사용하고 데이터베이스 인덱스는 64비트 정수를 기반으로 합니다. 그러므로 계정 이름의 길이를 늘리면 전반적인 성능과 아키텍쳐에 큰 영향을 미칩니다.

즉, 블록 체인에 대한 우리의 비젼은 사용자들의 계정에 관한 개념과 아이디(ID)와 분리하여 더 읽기 쉽게 표시할 수 있는 이름과 계정명 사이의 동적 체인 내 연결을 설정하는 것입니다.

기억하기 쉽도록 사용자가 손쉽게 선택하는 자동차 번호판같은 것들이 계정 명으로 적절합니다. 그 말인즉슨, 대부분의 사용자들은 12글자(또는 그 이하)의 매력적인 이름을 찾을 수 있어야 합니다.

특정 이름은 잠재적으로 높은 가치가 있으므로, EOSIO 시스템이 계정 명에 따라서 다양한 가격모델을 제시할 것입니다. 또한, .com같은 네임스페이스 계정은 사용자 또는 그룹들에 특별한 수준의 보장을 제공할 수 있습니다.

EOSIO의 현재버젼과 1.0버젼 사이에 개발할 시간이 제한되어 있기 때문에, 모든 계정이 ‘’같은 특정 문자들을 포함하지 않고 12글자의 이름을 쓰도록 권장합니다. 현실적인 가격과 계정 명 선점을 방지하기 위한 정책이 확정된 후에, 커뮤니티는 하드포크 없이 시스템 컨트랙트를 업그레이드 할 수 있습니다. 계정 이름이 길이와 글자가 나타내는 내용에 따라 가격이 책정되는 BitShare와 유사한 모델을 제공할 가능성이 높습니다.

블록 헤더만 검증

Steem, BitShares과 EOS Dawn 3.0과 그 전 버전에서는 전체 블록에 대한 검증이 없이도, 블록 헤더만으로 검증하는 것이 불가능했습니다. EOS Dawn 4.0에서는 헤더만을 이용해서 검쟁이 가능합니다. 이번 기능의 도입은 경량 클라이언트(light clients)와 블록체인간 통신(IBC)의 기반이 되며, 벡터 공격 범위를 차단하면서도 각 노드들이 전체 검증을 기다리지 않고 블록을 네트워크 전체로 전파할 수 있게 합니다.

높은 빈도의 통신을 위한 IBC의 단순한 형태는 모든 헤더를 처리하는 경량 클러이언트와 이미 알려진 블록에 대한 행동의 간단한 머클증명을 제공하는 사용자들로 구성됩니다.

블록 생성과 적용 아키텍쳐의 재구성

저희 팀은 블록을 생성하고 적용하는 과정을 정리하는 데 많은 시간을 보냈습니다. 이제 새 모델에서는 블록에 적용하는 데 사용 되는 것과 동일한 API 호출 순서로 블록을 만듭니다. 이렇게 하면 동일한 코드 경로를 따르고 블록 프로듀서가 유효하다고 생각하는 것과 검증자가 유효하다고 생각하는 것의 불일치를 최대한 좁혀줄 수 있습니다. 이런 정리 자체가 블록을 적용하는 과정을 블록 프로듀서가 한 작업을 재현하는 것과 유사하게 만들었습니다.

경량 프로듀서의 일정 변경 증명

블록체인간 통신(IBC)의 개념증명(proof-of-concept)을 구현할 때, Dawn 3.0이 간단한 서명 증명이 불가능한 몇 가지 경계 오류(edge case)가 있다는 사실을 알았습니다. 경량 최소 헤더 증명을 가능한 단순하게 만들고 싶어서, 블록이 서명되는 과정을 재구성하였습니다.

(역자 주 : 앞선 문단에서는 코너케이스를 설명해드렸습니다. 경계 오류 즉 Edge case는 알고리즘이 처리하는 데이터의 값이 알고리즘의 특성에 따라 일정한 범위를 넘을 경우에 발생하는 문제를 가르킵니다. 간단히 말하면, 개발자가 알고리즘을 검토하여 미리 예상할 수 있는 문제로서 본 글에서는 ‘IBC의 poc를 구현할 때, 발생할 수 있는 문제점이 예측되었기에 해당 문제를 해결하였다’라는 주장을 하고 있습니다.)

EOSIO Dawn 4.0을 사용하면 블록 헤더의 유효성을 검사하지 않고도 프로듀서 일정의 변경사항을 확인할 수 있습니다. 프로듀서가 블록에 서명을 하면서 2/3이상의 생산자가 담합을 하거나 1/3이상이 매우 나쁜 네트워크의 분할을 위해 공모가 없다면 서명이 유효한 프로듀서들의 일정이 충돌하는 일이 없도록 새로운 일정에도 서명을 합니다.

(역자 주 : 블록 프로듀서들의 일정이 조절이 안 되어서, 계속하여 같은 시기에 블록을 생성(그럴 가능성은 희박합니다)면 지속적인 포크이슈가 발생되므로 이런 현상을 방지하기 위하여 위와 같은 ‘경량 프로듀서의 일정 변경 증명에 대한 안’을 만든 것입니다.)

블록 프로듀서에 대한 새로운 보상 방식

프로듀서에 대한 보상과 최대 5% 인플레이션의 할당방법에 대하여 많은 논의가 있었습니다. block.one이 EOSIO 1.0과 함께 참고한 시스템 컨트랙트는 다음과 같은 인플레이션 분배를 할당할 계획입니다

실제로 블록을 생산하는 21군데의 블록 프로듀서와 대기 중인 프로듀서들이 있습니다. 상위 21위의 블록 프로듀서는 블록 수에 비례하여 각 프로듀서가 생산한 블록 당 0.25%의 보상을 받습니다. 모든 블록 프로듀서 출마자(상위 21곳을 포함)는 총 투표수에 비례하여 0.75%의 보상 예산을 나눕니다. 출마자들은 하루에 한 번 투표 보상을 청구할 수 있습니다. 투표 보상을 받기 위해서는 하루에 최소 100개의 토큰을 획득해야 합니다. 투표 수를 기준으로 하루에 최소한 100개의 토큰을 받지 못하는 출마자 후보군에게는 아무런 보상도 주어지지 않습니다.

이런 알고리즘의 배경에는 모든 프로듀서 출마자들이 커뮤니티에 제공하는 풀 노드 서비스에 대하여 정당한 보상을 받지 못하여 소모하는 비용을 충당하지 못하는 사태를 방지 하기 위한 생각이 있습니다. 상위 200명의 프로듀서 출마자들이 모두 같은 수의 투표를 받았다면, 21명의 활동적인 생산자와 179명의 대기자 상태인 프로듀서들을 지원할 것입니다. 실제로 일부 프로듀서 출마자들이 훨씬 많은 표를 얻어서 돈을 받으면서도 후보상태로서 대기 중인 프로듀서의 수를 줄일 가능성도 있습니다.

블록을 만들 의도가 없는 지분을 많이 보유한 사용자들이 자신의 프로듀서에 대한 투표로 프로듀서 출마자들이 이익을 얻지 못하도록 하기 위해, 하루에 최소 보상을 만들어 놓는 것도 중요합니다.

(역자 주 : EOS에서는 상위 21명 뿐 아니라, 대기 중인 블록 프로듀서들도 보상을 얻을 수 있도록 시스템을 설계하였습니다. 이런 배경에는 블록을 생성하기 위해 자원을 투입하고도 상위 21위에 들지 못 한다면 보상을 얻지 못하는 일이 없어야 한다는 철학에 기반한 것입니다. 글의 요지는 투표에 기반한 보상으로 인하여 실제 비즈니스에 적용을 할 때는 상위 21명의 생산자가 훨씬 더 많은 보상을 가져갈 수 있고, 이오스 토큰을 많이 보유한 투표수를 좌지우지 할 수 있으므로 방지책이 필요하다는 의견입니다.)

생산자 투표의 영향력 상실

Dawn 3.0 이후로 저희 팀은 시스템 컨트랙트를 변경하는 것에 몰두하고 있습니다. 이러한 변경점 중 하나가 투표수 감소를 구현하는 것입니다. 투표영향력을 높게 유지하고 싶다면, 매 주마다 각 투표자가 다시 투표를 진행해야 할 것입니다. 투표 영향력은 투표를 최신 상태로 유지 하지 않는 사람들의 경우 1년의 반감기가 있습니다.

저희 팀은 헌법에 자동투표 봇의 사용을 금지하는 조항이 있기를 권하고 있습니다. 투표 수 감소의 목적은 ‘투표대상에 대한 결정을 한 후 잊어버리는’ 상황이 아니라, 자신의 결정을 재고하는 것에 잊기 때문입니다. 봇의 사용을 증명할 수는 없지만, 사람들이 자동으로 투표하도록 스마트 컨트렉트를 사용하지 않는다는 점은 증명할 수 있습니다.

거래소 통합 지원

EOSIO 1.0의 출시가 가까워짐에 따라 많은 분께서 EOSIO를 위한 계좌의 입금확인을 위해 관찰하고 거래소 바깥으로 나가는 출금이 네트워크에 전달하여 비가역적인 승인(완전한 승인)이 가능한지 문의하고 있습니다. 저희 팀에서는 입금처리를 위한 체인을 관찰하는 별도의 튜토리얼을 cleos(EOS 인터페이스 커맨드 라인 명령어)를 이용하여 제작해왔습니다. 저희 팀은 입금과 출금을 관찰 할 수 있는 데모용 파이썬 스크립트도 작성하고 있습니다. 거래소들은 이 튜토리얼과 스크립트를 이용하여, 블록체인을 기반으로 한 EOSIO의 통합을 시작하기 위한 모든 사항을 해결할 수 있습니다.

EOSIO Dawn 4.0을 체험해보기

EOSIO Dawn 4.0의 코드 개발은 github의 ’slim’에서 진행되고 있습니다. 저희 팀은 5월 11일에 공식적인 공개를 할 예정입니다. 그 시간에 맞추어 저희 팀은 slim 브랜치를 master 브랜치로 옮기고 출시 태그를 달 것입니다. 최신 개발 진행 사항에 맞추어, 이를 체험하고 싶은 개발자들은 slim 브런치에서 저희의 진행사항을 팔로우 하실 수 있습니다.

결론

EOSIO 소프트웨어는 올 해 6월 출시한 1.0버젼을 위해서 지속적으로 발전하고 있습니다. Dawn 4.0에서는 깔끔하게 정리된 코드와 더불어 저희 팀은 그 어느 때보다 미래에 관한 큰 확신을 가지고 있습니다.

면책조항 — Disclaimer

면책조항: 블록원(block.one)은 소프트웨어 기업이며 EOS.IO 소프트웨어를 무료 오픈소스 소프트웨어로 제작합니다. 이 소프트웨어는, 특기할 만한 점으로, 이 소프트웨어를 도입하는 사용자가 다양한 기능을 갖춘 분산 애플리케이션 또는 블록체인을 시작할 수 있도록 합니다. 자세한 내용은 다음 사이트를 방문하십시오. https://github.com/eosio 블록원은 채택하거나 구현할 수있는 EOS.IO 플랫폼의 모든 버전에서 블록 프로듀서가가 되려는 사람에게는 경제적 지원을 제공하지 않습니다.

블록원은 EOS.IO 소프트웨어를 기반으로 하는 퍼블륵 블록체인을 론칭하지 않습니다. 자신들이 선택한 기능 및/또는 자신들이 선택한 서비스를 제공하도록, 자신들이 선택한 형태로 EOS.IO를 채택하며 구현하려는 제 3자, 커뮤니티 및/또는 블록 프로듀서가 되길 원하는 주체들의 단독 책임일 것입니다. 블록원은 그러한 기능을 채택하여 구현하거나 그런 서비스를 제공하거나 EOS.IO가 어떤 방식으로든 채택되고 구현된다는 것을 보증하지 않습니다.

이 문서는 블록원의 비전을 보여 주며 어떠한 보증도 아닙니다. 우리가 그 비전을 실현하도록 노력할 것이지만, 모든 측면이 모든 면에서 블록원의 단독 재량 하에 변경될 수 있습니다. 우리는 블록원의 비즈니스 전략, 계획, 전망, 개발 및 목표에 관한 진술과 같은 역사적 사실에 대한 진술 이외에 이 문서의 모든 진술을 포함하는 이 문서를 “미래 예측 진술”이라고 부릅니다. 이 진술은 예측일 뿐이며 미래의 사건에 대한 블록원의 현재의 믿음과 기대치를 반영하고 가정에 근거하며 언제든지 위험, 불확실성 및 변경의 영향을 받습니다. 우리는 급변하는 환경에서 사업을 운영합니다. 새로운 위험이 수시로 발생합니다. 이러한 위험과 불확실성을 감안할 때 이러한 미래 예측 진술에 의존하지 않도록 주의해야합니다. 실제 결과, 실적 또는 이벤트는 미래 예측 진술에 포함된 내용과 실질적으로 다를 수 있습니다. 실제 결과, 실적 또는 이벤트가 미래 예측 진술과 실질적으로 다른 원인이 될 수 있는 요인에는 시장 변동성, 자본, 재원 및 인력의 지속적인 가용성; 제품 수용; 어떤 새로운 제품이나 기술의 상업적 성공; 경쟁; 정부 규제 및 법률; 그리고 일반적인 경제, 시장 또는 사업 조건이 포함되며 이에 제한되지 않습니다. 블록원이 만든 모든 미래 예측 진술은 그것이 작성된 날짜에 대해서만 말하고 블록원은 새로운 정보, 후속 사건 또는 기타의 사건이건 간에 미래 예측 진술을 업데이트하거나 변경할 의무가 없으며 분명히 부인할 의무가 없습니다.

여기에있는 진술은 기술, 재무, 투자, 법률 또는 기타 조언을 구성하지 않으며 특정 상황이나 구현에 적용되지 않습니다. 이 문서에 포함된 내용을 구현하거나 활용하기 전에 해당 분야의 전문가에게 문의하십시오.

여기에서 표현된 아이디어와 정보는 전적으로 저자 개인의 것이며 블록원 또는 블록원 직원의 입장과 견해와 조언을 필연적으로 반영한 것은 아닙니다.

토마스 콕스(Thomas Cox)와 그렉리(Greg Lee)에게 감사의 말씀을 드립니다.