EOSIO Dawn 4.0 소개   

block.one이 EOSIO Dawn 3.0을 대중들에게 공개한지 약 한달이 지났습니다. 지난 한 달 동안, 우리 팀은 EOSIO 소프트웨어의 최적화 및 안정화에 초점을 맞췄으며, 작업의 많은 부분이 블록체인 간 통신의 컨셉 검증(Proof of Concept)으로 편중 되고 있습니다.  

병합된 건을 제외하면, 총 43명의 개발자들이 818개의 Commit을 github에 제출하였고, 지난 한 달 동안  EOSIO는 github에서 가장 활발한 TOP 8 C++ project가 될 수 있었습니다. 보시다시피 많은 일들이 일어나고 있습니다.   

1. now()에 대한 정의
2. 시장 기반의 새로운 RAM 할당모델 
3. 블록체인 간 통신
4. DPOS 최신 비가역 블록 알고리즘 업그레이드
5. 네임 스퀏팅
6. 헤더만으로의 유효성
7. 경량화한 프로듀서 스케쥴 변경 증명
8. 신규 프로듀서 보상 모델
9. 투표권 감쇄
10. 거래소 통합 지원

now()에 대한 정의 

EOSIO Dawn 4.0 의 가장 큰 변화는 “current time”의 개념을 “헤드 블록 시간 (time of head block)”에서 “현재 블록 시간(time of current block)” 으로 재정의 하였습니다. 이런 변화를 통해, 스마트 컨트랙트의 경과 시간을 조금 더 정확하게 측정할 수 있을 뿐만 아니라, 시간 기반의 작동 중 블록 누락의 코너 케이스(corner-cases)를 해결할 수 있습니다.   

시장 기반의 새로운 RAM 할당모델 

테스트를 통해, 우리는 어떻게 EOSIO 시스템 컨트랙트가 토큰 보유자에게 RAM (데이터베이스 공간)을 할당하여 자원 부족을 초래하는지 확인 하였습니다. 그래서, 우리는 Bancor 알고리즘을 사용하여 마켓 기반 할당 방식으로 전환하였습니다. 

저희 측 계산에 따르면, 1TB의 RAM이 토큰 홀더에 비례하여 할당된 경우, 드는 비용은 $0.018/byte ($20/token 가정)입니다. 현실은 대부분의 토큰 홀더는 실제로 권한 대로 주어진 RAM을 모두 사용할 필요성이 없기 때문에, 초기에 우리는 RAM의 가격을 $0.000018/byte ($20/token가정)으로 책정했습니다. 새 계정은 약 4KB의 RAM이 필요하며, 약 $0.10을 지불해야 합니다. RAM은 가격이 자동으로 상승하게 되어 있으며, RAM이 고갈되기 전에는 가격이 무한대에 가까워 집니다. 

Dawn 3.0 시스템 컨트랙트에 의하면, 과거에 지불한 가격으로만 RAM을 팔 수 있습니다. 목적은 사재기 및 투기를 방지하기 위함이 였습니다. 이러한 방법의 단점은 RAM을 저렴하게 구매한 사람은 RAM의 품귀 상황에서도 보유하고 있는 RAM을 풀어 줄 경제적 동기가 결여되어 있습니다. Dawn 4.0 시스템 컨트랙트에서는, 현재 시장 가격으로 RAM의 판매와 구매가 이루어 집니다. 이로 인해, 내일의 부족 가능성을 예측하고, 오늘 시점에 RAM을 구매하게 될 것이며, 전반적으로 볼 때, RAM의 공급과 수요의 균형을 맞추어 나갈 수 있을 것 입니다. 

시간이 지나면서, 무어의 법칙에 따라 BP들은 4TB 또는 16TB RAM으로 업그레이드 할 수 있으며, 이에 따른 공급 증가로 인해 EOSIO RAM 시장 가격은 낮아 질 것입니다. 

스마트 컨트랙트 개발자들에게 미치는 영향 

스마트 컨트랙트 개발자에게, RAM은 데이터베이스 기록에 사용되는 소중한 자원입니다. RAM 비용으로 인해 메모리 내 데이터베이스에 저장하는 데이터양을 최소화하고, 사용자가 RAM을 사용 후 풀어줄 수 있도록 App을 설계하는 것이 매우 중요합니다. 예를 들어, Steem은 일주일 분량의 컨텐츠만 저장하므로 RAM의 총 사이즈는 시간에 따라 크게 늘어나지 않습니다.  

투기 최소화 

이제 RAM 시장이 존재하기 때문에, 투자자들은 RAM 가격 변동을 통해 이익을 얻기를 원할 수도 있습니다. EOSIO 시스템 컨트랙트로 인해 RAM은 양도가 불가하며, 거래 시 1%의 거래 수수료를 청구합니다. 이 수수료는 늘어나는 토큰을 시장에서 빼냄으로써 자연적 인플레이션을 상쇄 시키는 효과를 가져옵니다.  만약 연간 RAM 거래량이 토큰 공급량과 같다면. 모든 BP의 보상은 RAM 시장 수수료로 100% 충당될 것입니다. 

블록체인 간 통신 

디스크에 방문하는 방식은 거래의 효율을 초당 몇백건의 수준으로 낮추기 때문에, 블록체인의 높은 퍼포먼스를 보장 받기 위하여 모든 데이터가 RAM으로부터 사용되기를 요구 합니다. RAM 사용의 확장성을 위하여 복수 체인의 독립 된 메모리 영역이 독립 된 하드웨어에서 돌아가도록 해야 합니다.  

EOSIO BP는 복수의 체인을 운영할 수 있으며, 이러한 체인은 동일한 토큰으로 구입한 RAM과 staking한 대역폭을 사용하게 됩니다. BP 선출은 메인 체인에서 진행될 것이며, 관련된 모든 사이드 체인은 동일한 BP들을 통해 운영될 것입니다. 각 체인마다 그들만의 1TB 이상의 RAM과 dApp들을 보유할 수 있으며, 몇초만에 체인 간의 메시지를 전송할 수 있습니다.  

RAM 가격은 체인 마다 상이하며, 이 정보 또한 dApp 개발자들에게 어디가 가장 저렴하게 운영되고 있는지 알 수 있도록 제공이 될 것입니다.   

병렬처리 로드맵 

블록체인간 통신(Inter Blockchain Communication, IBC)은 양측 체인이 Merkle검증을 위하여 몇십개의 암호화 해시 함수와 15개 이상의 서명검증을 포함한 1KB+ 크기의 메시지를 취급하게 됩니다. 이 뜻인 즉, 다른 체인으로부터의 메시지를 검증하는 비용은 정상적 거래의 검증 비용 보다 약 15배에서 30배 높습니다.   

다행히, 이런 증명검증은 블록체인 상태에 의존하지 않기 때문에 병렬화 하기 쉽니다. 다른 체인으로부터 온 메시지만 처리하는 블록체인은 초당 수천개의 거래를 유지하면서 30 CPU코어를 소비합니다. 

IBC(블록체인 간 통신)를 통한 확장은 무제한 확장 가능성을 제공할 것이라고 확신하며, 이러한 접근 방식은 RAM, 네트워크, CPU를 동시에 확장합니다. 서명 검증, context-free-action 검증 및 IBC 검증만으로 대부분의 CPU들의 high-single-thread를 소진할 것이며, 멀티 스레드 WASM 최적화를 위한 노력은 기타 자원의 한계로 장애를 맞을 것입니다. 

EOSIO Dawn 3.0에서는 미래의 멀티 스레드 WASM 실행 가능성에 관한 많은 설계를 시도 하였습니다. 하지만 아쉽게도, 완정한 멀티 스레드를 구현하기 전까지는, 모든 코너 케이스를 다루고 있는지 여부를 알 수 없습니다. 이는 EOSIO Dawn 3.0이 가지고 있는 많은 설계의 복잡성은 즉각적인 효익을 제공하지 않음을 의미합니다.  

싱글 스레드부터 멀티 스레드 실행까지 업그레이드 하는 방법은 동일한 BP들이 동일한 네이티브 토큰으로 멀티 스레드 지원이 되는 새로운 체인을 런칭하는 것이라고 생각합니다. 이러한 방법으로 라이브 체인 자체의 업그레이드를 하지 않고도 멀티 스레드 작업이 필요한 새로운 체인의 디자인을 자유롭게 시도 할 수 있습니다. 

이러한 병렬 처리 로드맵으로 우리는 EOSIO 1.0의 싱글 스레드 성능과 개발 편이성 극대화를 심플하게 도모 할 수 있습니다. 우리는 EOSIO의 싱글 스레드 버전이 5,000~10,000 TPS에 도달 하리라고 기대 합니다. 또한 많은 App들이 저렴하고 빠른 확장성을 실현 하는 다중 체인의 시도를 선호 할 것으로 기대 합니다. 

DPOS 최신 비가역 블록 알고리즘 업그레이드

컨센서스 알고리즘 논쟁을 지켜 보신 분들은 최신비가역블록(Last Irreversible Block, LIB) 알고리즘(Steem & BitShares 에 존재하는 것처럼)을 사용하는 DPOS가 극한적 네트워크 연결 중단으로 인해 컨센서스에서 벗어날 가능성이 있다는 것을 들어 보았을 것입니다. 과거에 나는 너무나 이론적이고, 상대적인 최소비용과 다운타임 때문에, 이러한 잠재적 실패를 무시했습니다. LIB 알고리즘은 비트코인에 대한 6블록 규칙과 같은 척도일 뿐이었고, 퓨어 DPOS는 궁극적인 컨센서스에 도달하는 가장 긴 체인을 기준으로 하는 규칙에 항상 의존했습니다. LIB 알고리즘은 undo-history 최적화 및 교환에 대한 신뢰를 높이기 위해 고안된 지름길 이었습니다. 

EOSIO의 IBC 알고리즘은 최종성을 확인하기 위한 DPOS LIB에 따라 달라집니다. LIB 고장에 따른 비용과 어려움은 IBC 도입 이후 훨씬 더 높아집니다. 우리 팀 특히Bart와 Arhag은 두개의 노드가 1/3의 비잔틴 합의를 이루지 못한 상황에서 서로 다른 LIB에 도달할 수 없도록, LIB 알고리즘 개선책을 찾아냈습니다. 또한, 단일 개체의 비잔틴 행위도 탐지 할 수 있게 되었습니다. 이에 관해 여기를 참조 하세요.

비트코인과 이더리움 블록의 finality가 떨어지기 때문에, 레거시 체인(legacy Chain)과의 블록체인 간 통신이 어려워지고, 또한(또는) 긴 대기 시간 걸립니다. DPOS의 새로운 조정은 모든 네트환경에서의 비잔틴 결함 허용 한계를 새로운 수준으로 끌어 올렸습니다. 

네임 스퀏팅 (Name Squatting) 

일부 사용자는 EOSIO계정에 적용되는 12자 이름 제한에 대해 우려를 나타냈습니다. 12개 문자 이름은 64비트 정수의 base-32 인코딩에서 파생됩니다. 64비트 정수는 기본 시스템 워드 사이즈이므로 매우 효율적입니다. 트랜잭션마다 계정 이름(코드, 범위, 권한 등)을 여러 번 언급하며, 데이터베이스 인덱스도 64비트 정수를 기준으로 합니다. 계정 이름의 길이를 늘리면, 성능과 시스템 구조에 광범위한 영향을 미칠 수 있습니다. 

즉, 우리의 블록체인에 대한 비전은 계정의 컨셉을 정체성과 분리하고, 계정 이름과 읽기 쉬운 이름 사이에서 다이나믹 on-chain 매핑을 설정하는 것입니다. 

계정 이름을 외우기는 쉬운 번호로 자동차 번호판으로 선택하는 것 같이 생각하는 것이 가장 좋습니다. 대다수의 사람들은 매력적인 12자 이름을 찾을 수 있어야 합니다. 

특정 이름의 가치가 높을 수 있기 때문에, 우리는 EOSIO 시스템이 계정 이름에 대한 다이나믹한 가격 모델을 제시해야 한다고 생각합니다. 또한, *.com과 같은 계정의 네임 스페이스를 지정하는 기능은 사용자 또는 그룹에 추가적인 보안층을 제공 해야 할 것입니다. 

지금부터 EOSIO소프트웨어 버전 1.0 출시까지 제한된 개발 시간으로 인해, 모든 계정 이름을 12자로 확정하고, ‘.’과 같은 문자는 제한하려고 합니다. 그 다음 커뮤니티는 실행 가능한 가격 책정 및 이름 정책이 확인되면, 하드포킹 없이 시스템 컨트랙트를 업그레이드 할 수 있을 것입니다. 계정 이름 길이 및 컨텐츠 별로 가격이 책정된 Bitshares와 유사한 모델을 제공할 것입니다. 

헤더만으로의 유효성 검증(Header-Only Validation) 

Steem, BitShares, EOS Dawn 3.0또는 더 이전에는 전체 불록을 적용하지 않고 블록 헤더를 검증할 수 없었습니다. EOS Dawn 4.0은 헤더 전용 유효성 검사를 지원합니다. 이 기능은 라이트 클라이언트와IBC의 기초가 될것이며, 다양한 공격 경로를 막으면서, 각 노드가 전체 검증을 수행할 때까지 기다리지 않고도 네트워크를 통해 전파되도록 합니다. 

IBC 의 고빈도 통신에서 가장 간단한 형태는 라이트 클라이언트가 모든 헤더를 처리한 다음, 알려진 블록에 merkle 증명을 진행하는 것입니다. 

블록 빌딩과 적용 아키텍처 재구성(리팩토링) 

저희는 블록을 생산하고 실행하는 프로세스를 최적화하는데 상당한 시간을 투자했습니다. 새 모델에서는 블록을 적용하는 데 사용되는 동일한 API 호출 순서로 블록이 작성됩니다. 이렇게 하면 동일한 코드 경로를 따를 수 있으며 프로듀서가 유효하다고 생각하는 것과 검증자가 유효하다고 판단하는 사이의 불일치 가능성을 최소화할 수 있습니다. 이런 최적화를 통해 블록을 적용하는 과정을 BP가 했던 작업을 되풀이 하는 스크립트와 조금 더 비슷하게 만들었습니다. 

경량화한 프로듀서 스케쥴 변경 증명 

IBC 컨셉 증명을 실행하면서 우리는 Dawn 3.0 이 단순한 서명 증명이 불가능한 몇몇 사례를 가지고 있다는 것을 깨달았습니다. 우리는 최대한 간단하게 블록이 어떻게 서명되어야 하는지에 대한 경량화한 헤더 인증을 구현하고 싶었습니다.

EOSIO Dawn 4.0 를 통해, 블록 헤더의 유효성을 검사하지 않고도 프로듀서의 일정에 대한 변경 사항을 반영/검증 할 수 있습니다. 프로듀서가 블록에 서명할 때, 새로운 스케줄에도 사인을 하게 됩니다. 이를 통해 ⅔이상의 의 BP 합의 또는 ⅓이상의 악의적 네트워크 분할이 없다면 2개의 경쟁구도의 유효한 BP스캐쥴스캐쥴이 발생할 확률은 없습니다. 

신규 프로듀서 보상 모델 

커뮤니티 내에서 블록 프로듀서의 보수 그리고 최대 5%의 인플레이션을 어떻게 할당할 것인가에 대한 많은 토론이 있었습니다. block.one이 EOSIO1.0에 제공하는 참조 시스템 컨트랙트는 다음과 같이 인플레이션을 할당합니다.    

21개의 메인BP와 다수의 대기 BP가 있습니다. 상위 21개BP는 각 프로듀서의 생산한 블록 수에 비례하여 0.25%의 보상을 나누게 됩니다. 모든 BP 후보자(상위 21개 BP 포함)는 전체 투표 수에 비례하여 0.75%의 보상금 인플레이션 예산을 나눕니다. 그들은 하루에 한번만 보상금을 청구할 수 있으며, 보상금을 청구하기 위해서는 하루에 최소 100개 토큰 조건을 충족해야 합니다.  하루에 최소 100개 토큰을 충족하지 못하는 후보자들은 보상이 주어지지 않습니다. 

이 알고리즘 이면의 아이디어는 모든 후보자들이 완전한 풀 노드 서비스를 커뮤니티에 제공하여 충분한 보상을 받아 그 어떤 블록프로듀서 도 불이익을 받는 경우가 없도록 하는 것 입니다. 상위 200명의 프로듀서 후보자들 모두 같은 표를 받았다고 가정한다면 21명의 활동적인 BP들과 179개의 프로듀서들이 지원할 것입니다. 하지만, 일부 BP들은 다른 BP들보다 많은 표를 얻을 것이며 이 경쟁으로 인해 대기 프로듀서의 수가 감소할 것입니다. 

또한 중요한 것은 하루지불 최소량을 지정하여 블록을 만들 의도가 없는 부유한 BP후보들이 자신에게 투표를 함으로써 이익을 얻을 시도를 못하도록 하는 것 입니다. 

투표권 감쇄 

Dawn3.0 이후 우리가 하고 있는 대부분의 일은 시스템 컨트랙트를 조정하는 것입니다. 이들 중 하나는 투표권 감쇄입니다. 최대 투표 영향력을 유지하기 위해서 각 유권자들은 매주 재평가해야 합니다. 투표를 최신 상태로 유지하지 않는 사람들은 그 영향력이1년의 반감기를 가지고 줄어들게 됩니다. 

우리는 “헌법”에 자동 투표를 금지하는 문장을 포함하는 것을 추천합니다. 투표의 목적은 유권자들이 "투표를 하고 잊어 버리는 "것이 아니라 그들의 결정을 재평가하기 위함 입니다. 봇의 사용을 증명하는 것은 가능하지 않지만, 사람들이 자동 투표를 위해 스마트 컨트랙트를 사용하지 않는다는 것을 증명하는 것은 가능합니다.    

거래소 통합 지원 

EOSIO1.0 출시가 다가옴에 따라 많은 사람들이 거래소들이 EOSIO블록 체인에서 입금 및 출금이 블록체인에 올라가 비가역성이 확인 되었는지 등을 어떻게 모니터링 할 것인지에 대해 문의합니다. 하여 우리는 입금에 대한 블록체인을 모니터링하기 위한 cleos(eosio 인터페이스의 명령어) 사용법에 대한 튜토리얼을 만들었습니다. 우리는 또한 입금과 출금을 모니터링하는 데모 Python스크립트를 만들었습니다. 이 튜토리얼과 예제 스크립트들은 거래소들이 EOSIO기반 블록체인을 적용하기 위해 필요한 모든 것을 갖추고 있습니다.   

EOSIO Dawn 4.0의 사용 

EOSIO Dawn 4.0 code 개발은 github의 ‘slim’ 브렌치에서 진행/공유 되고 있습니다. 이것을 정리하여, 2018년5월11일에 공식적으로 배포할 예정입니다. 그 때 우리는 slim에서 마스터 브렌치로 옮겨 배포를 알릴 것입니다. 최신의 소식으로 기술공유를 원하는 개발자들은 slim에서 저희 프로그래스를 확인 할 수 있습니다. 

결론 

EOSIO 소프트웨어는 올 6월의 강력한 1.0 릴리스를 향해 큰 진전을 이루고 있습니다. Dawn 4.0을 통해 코드는 완벽하게 최적화 되었으며, 우리는 어느 때 보다 더 확신 합니다.    

면책조항 

block.one은 소프트웨어 회사로, EOS.IO 소프트웨어와 무료, 오픈소스 소프트웨어를 생산하고 있습니다. 무엇보다도, 이 소프트웨어는 배포자가 다양한 기능을 갖춘 블록체인 또는 DApp을 시작할 수 있습니다. 더 자세한 정보는 https://github.com/eosio  를참고하시기 바랍니다. block.one은 EOS.IO 플랫폼을 사용하는 BP 어느 누구에게도 어떠한 재정적인 지원을 제공하지 않습니다. 

 Block.one은 EOS.IO 소프트웨어 기반의 공개 블록체인을 런칭 하지 않을 것이며, 선택한 EOS.IO를 실행 하거나, 선택한 기능으로 서비스를 제공하는 것은 제 3자, 커뮤니티, BP선정을 희망하는 자들의 단독 책임입니다. block.one은 이러한 기능을 실행하거나 이러한 서비스 제공 또는 EOS.IO 소프트웨어 사용에 어떠한 것도 보장하지 않습니다. 

본 문서는 block.one의 비젼을 제시한 것이며, 어떠한 것도 보증할 수 없습니다. 우리는 이 비젼이 실현될 수 있도록 노력하겠지만, 비젼은 모든 면에 따라 변화 될 수 있습니다. 우리는 이것을 “미래예측 진술서” 라고 부르며, 여기에는 block.one의 비즈니스 전략, 계획, 전망, 발전 및 목표에 대한 역사적 팩트에 대한 내용이 모두 포함되어 있습니다. 본 내용은 예측일 뿐이며, block.one의 현재 신념, 미래 예측을 기반으로 한 희망에 불과합니다. 또한, 이는 리스크 및 불확실성에 따라 변화 할 수 있습니다. 우리는 급변하는 환경에서 운영을 하고 있으며, 새로운 리스크는 시시때때로 발생될 수 있습니다. 이러한 부분을 감안할 때, 이러한 미래예측 진술서에 의존하지 않도록 주의해야 합니다. 실제 결과, 성과는 실질적으로 미래예측 진술서의 내용과 상당히 다를 수 있으며, 이를 변화 시킬 수 있는 요인은: 시장 변동성, 자본의 지속 유동성, 재정 및 인원, 제품인증, 새로운 상품 또는 기술의 성공, 경쟁, 정부정책 및 법규, 경제 및 시장 상황 등이 있습니다. Block.one에 의해 만들어진 미래예측 진술서는 block.one데이터기반으로 만들어 졌으며, 새로운 정보, 추후의 일정 등을 수정하거나 업데이트 해야 할 법적 의무가 없습니다. 

본문은 기술, 재무, 투자, 법률 및 기타 내용을 구성하고 있지 않으며, 특별한 상황에서는 본문의 내용이 적용되거나, 실행되지 않을 수 있습니다. 본 내용을 적용하거나 실행하기 전에는 관련 분야 전문가에게 상의하시기 바랍니다. 

본문의 내용 및 주장은 전적으로 저자의 생각이며, block.one의 기타 직원 또는 block.one의 생각은 반영하지 않았습니다.