안녕하세요, 대한민국을 대표하는 EOSIO Block Producer 후보 EOSYS 입니다.
한국 시간으로 4월 6일 오전 7:17경, EOSIO Dawn 3.0이 댄 라리머의 Medium글과 Github 업데이트를 통해 발표되었습니다. 해외 네트워크와 커뮤니티 모니터링을 통해 EOSIO/ block.one 소식을 정확하고 빠르게 전해 드리고 있는 EOSYS팀이 기술백서 v2에 이어, 댄 라리머의 “EOSIO Dawn 3.0 Now Available” 글을 번역했습니다.
Block.one은 기능 구현이 완성된 EOSIO, Dawn 3.0의 사전 공개를 하게 되어 기쁩니다. 이 사전 공개는 2018년 6월을 목표로 하고 있는 EOSIO 1.0의 주요 마일스톤을 포함하고 있습니다. 전 세계에 있는 우리 개발 팀은 EOSIO를 블록체인 어플리케이션을 구축하기에 가장 강력한 플랫폼으로 만들기 위해 밤낮없이 노력해 왔습니다. EOSIO Dawn 2.0 이 출시된지 4개월이 지난 지금, 정말 많은 것들을 보여드릴 수 있게 되었습니다.
블록체인 아키텍처를 구축하는 과정은 우리가 무언가를 새롭게 배워가면서 그 설계가 변하기도 합니다. 오리지널 EOSIO 백서에서는 고려되지 않았던, 뛰어난 성능과 유연성 그리고 쉬운 개발을 위한 플랫폼 등 많은 기능들이 Dawn 3.0에서 추가되었습니다.
확장성 기능(Scalability Features)
확장성이란 시장의 수요 상황에 따라 확장할 수 있는 능력을 의미합니다. 우리 팀은 모든 디자인 단계에서 향후 확장성을 고려해 설계했습니다. 즉 Dawn 3.0은 EOSIO의 미래의 확장성을 고려해 일부 부분만 구현합니다. 이를 통해, 향후에 구현될 것들이 하드포크 없이도 병렬 컴퓨팅을 사용하여 처리 속도를 높일 수 있게 되었습니다.
블록체인간 통신(Inter-blockchain communication)
블록체인간 통신은 사이드체인이나 플라즈마, 샤딩처럼 산업계 전체가 갈구해왔던 확장성을 위한 기능입니다. 블록체인간 통신은 한 블록체인이 다른 블록체인에서 일어나는 이벤트를 입증 가능한 안전한 방식으로 진위를 확인하도록 합니다. 우리는 인터블록체인을 스마트 컨트랙트 사이의 인트라체인 커뮤니케이션처럼 안전하게 만드는 목적을 달성했습니다.
인터블록체인이란 라이트 클라이언트(light client)를 스마트 컨트랙트로 구현해 내는 것 뿐입니다. 라이트 클라이언트는 블록체인 전체를 거치지 않고도 거래를 검증할 수 있습니다. 이를 통해 효율적이고 안전한 POS(Proof-of-stake) 블록체인을 구축할 수 있습니다. 이 부분은 나중에 추가로 구현하는 것이 불가능하기에, 프로토콜 디자인 단계부터 고려되어야 합니다.
최소한의 헤더 검증(Sparse Header Verification)
기존 라이트 클라이언트의 경우, 모든 블록 헤더를 처리하고 그 다음 블록 헤더와 관련된 증명을 거쳐야 했습니다. 하지만 EOSIO는 매 초 마다 2개의 블록을 생성할 수 있으며, 블록체인은 모든 블록 헤더를 처리하기 위해 매 초 당 최소 2개의 거래를 요구합니다. 이것은 블록체인간 통신 빈도가 비교적 적은 경우에는 해당되지 않습니다. 우리는 이 문제를 해결하기 위해 처음으로 byzantine fault-tolerant sparse-header validation을 적용한 첫 블록체인을 만들었습니다. 라이트 클라이언트를 속이기 위해서는 블록 프로듀서의 2/3(예를 들어 21명의 블록 생산자 중 15명 이상)가 변질되어야 합니다. 게다가 라이트 클라이언트는 실제 활동하는 블록 프로듀서 세트가 변경하는 블록 헤더와, 인터블록체인 메시지를 포함하는 블록 헤더만 처리하면 됩니다. 이는 비잔틴 오류를 허용하는 라이트 클라이언트 유지에 드는 간접 비용을 크게 줄이며, 블록체인간 통신의 효율성을 획기적으로 높여줍니다.
Context Free Actions
Context free Actions는 효율적인 블록체인 간 통신에 중요한 기능 중 하나입니다. 이것들은 거래에 포함이 될 수 있다는 점에서 특별한 액션에 속하지만 “context-free”이기 때문에 블록체인 상태에 의존하지 않습니다. context free의 예로는 머클 증명(merkle proof)이나 서명(signature)을 들 수 있습니다. 이들 컴퓨팅이 context-free이기 때문에 쉽게 병렬 형식으로 검증이 가능하고, 컴퓨팅은 재생 과정에서 제거될 수 있습니다.
또한 모든 context-free action은 거래 중 제거가 가능한 데이터 섹션을 참조할 수도 있습니다. 이는 머클 증명(merkle proofs)이 제거될 수 있음을 의미하며 동시에 고 비용의 컴퓨팅이 생략될 수 있음을 말합니다.
Context free action은 블록체인간 통신에서 간접비용이 가장 많이 드는 부분을 병렬로 처리 할 수 있도록 합니다. 또한, confidential transactions(기밀 거래), bullet proofs, zkSNARKs 처럼 컴퓨팅에 고 비용이 드는 비밀 기술의 간접비용 또한 병렬화하고 제거할 수 있게 됩니다.
context free action 사용을 장려하기 위해서, 기존의 거래가 아닌 context free action의 일부로 계산이 수행될 때 블록 프로듀서는 사용자에게 CPU 사용량의 일부분만 청구하게 됩니다.
Context-Free Inline Actions as Events
EOSIO Dawn 2.0의 개발자들은 외부 소스로 처리되는 이벤트를 생성하는 효율적인 방법을 탐색했습니다. 이더리움에서는 이 이벤트들을 사용해 컨트랙트의 내부 운영에 대한 구조화된 정보를 알립니다. context-free action이 추가되면서 잠재적으로 context-free inline action을 할 수 있게 되었습니다. inline action은 컨트랙트 코드에 의해 생성되고 현재 거래의 일부로 집행됩니다. context free inline action은 저렴한 비용과 병렬 방식으로 처리될 수 있습니다. 모든 inline action들이 머클 루트에도 포함되어 있기 때문에, 이 action들을 외부 서비스나 다른 블록체인에 입증할 수 있는 알림으로 사용하는 것도 가능합니다.
거래 압축(Transaction Compression)
거래들 안에는 압축 가능한 데이터가 많이 존재합니다. 가장 대표적인 예시는 컨트랙트 웹어셈블리 코드를 들 수 있습니다. 또 다른 예로는 ABI 사양과 계정, 컨트랙트와 관련된 리카르디안(Ricardian) 컨트랙트가 있습니다. 소셜 미디어와 같은 몇몇 어플리케이션들은 유저의 압축 가능한 컨텐츠를 블록체인에 포함시키길 원합니다.
거래 압축을 사용함으로써 블록체인은 더 효율적으로 저장하고 대량의 거래를 전파할 수 있으며 사용자로 하여금 압축 불가능한 데이터를 사용하는 거래에 비해 더 적은 비용을 지불하게 합니다.
인터프리터 & JIT 컴파일(Interpreter & Just-In-Time Compilation)
Dawn 2.0과의 큰 변화 웹어셈블리(WebAssembly) 실행시간 환경의 추상화 되었다는 점입니다. 이제 Dawn 3.0은 더 빠른 Just-in-Time (JIT) 컴파일러를 사용하지 않고 기본적으로 2진법 웹어셈블리(Binaryen WebAssembly) 인터프리터를 사용합니다. 이 결정을 통해 성능은 저하되었지만 안정성이 향상되고 표준에 더 적합하게 되었으며, 필요할 때 더 높은 성능의 JIT 환경에서 쉽게 스왑을 할 수 있게 되었습니다.
인터프리터는 우리가 Dawn 2.0에서 마주했던 가장 큰 과제중 하나인, 컨트랙트 컴파일링으로부터 야기된 지연 문제도 해결했습니다. 추후에는 백그라운드에서 컨트랙트를 컴파일하고 최적화 하는 동안 갓 배포된 컨트랙트의 속도를 늦추면서 지연을 줄이고, 갓 배포된 컨트랙트를 실행하기 위해 인터프리터를 사용할 수 있습니다. 이러한 이중 구현은 우리의 모든 유닛 테스트가 컴파일된(compiled) 코드와 해석된(interpreted) 코드 양쪽에 대해 진행되었다는 것을 의미하므로 하이브리드 방식의 접근 이전에 결정적이지 않거나 또는 표준을 준수하지 않는 행위를 찾아낼 수 있습니다.
자원 측정 비율 제한(Resource Metering Rate Limiting)
이제 Dawn 3.0에서 완전히 새로운 자원 측정 비율 제한을 갖게 되었습니다. 아마도 가장 크게 달라진 점은 objective instruction-counting algorithm을 도입했다는 점일 것입니다. 우리가 EOSIO 구축을 시작했을 때, 완전히 주관적인 비율 제한과 실행만을 목표로 삼았습니다. 우리는 주관적 시행의 비용이 객관적인 접근 비용과 동일하다는 것을 발견했습니다. 이제는 유저가 객관적인 사용을 통해 청구된 경우 하이브리드 솔루션을 사용하지만, 블록 프로듀서들은 컨트랙트에 주관적인 wall-clock time 제한을 둡니다. 우리가 이 접근법을 적용한 가장 큰 이유는 개별 거래가 이전 보다 더 많은 계산을 할 수 있게 하기 위함입니다. 이전에는 모든 거래가 1ms 미만으로 실행되어야 했지만 이제는 실행되는 데 100ms가 소요되는 단일 거래를 블록에 포함시키는 것이 이론적으로 가능합니다.
rate limiting 에 대한 또 한가지 변경점은 토큰을 정의하려는 필요로부터 제한을 분리하는 것입니다. 이를 통해 EOSIO를 어떤 토큰도 사용하지 않는 블록체인으로서, 비공개로 사용할 수 있게 됩니다. 퍼블릭 블록체인은 지분을 통해 제한을 구현하는 시스템 컨트랙트를 도입할 수 있고, 커뮤니티는 할당이 집행되는 방법과는 별개로 다이나믹 하게 자원이 할당되는 방법을 업그레이드 할 수 있습니다.
500 ms의 블록 생성 간격(Block Interval) & BFT DPOS
우리는 Dawn 3.0에서 블록 생성 간 간격을 3초에서 0.5초로 변경했습니다. 이는 블록 승인(confirmation)까지의 대기 시간을 획기적으로 단축시킵니다. BFT DPOS가 적용되면, 거래는 되돌릴 수 없이 1초 미만으로 승인될 수 있습니다. 외부 체인으로부터 증명을 결합하기 전 비가역성 상태가 되도록 기다려야 하기 때문에, 비가역성에 소요되는 지연 시간은 블록체인간 통신에 가장 주요한 요소 중 하나입니다. 두 EOSIO 기반 블록체인에서 둘 사이를 한 번 왕복하는 커뮤니케이션은 3초 아래로 수행되어야 합니다. 이더리움에서의 비슷한 커뮤니케이션 패턴은 9분이 소요되고, 비트코인에서는 3시간 이상이 소요됩니다.
BFT DPOS는 비-하드포크에 최적화 되어있기 때문에 아직 구현되지 않았습니다. EOSIO 1.0이 출시되기 전에 BFT DPOS를 구현 할 것입니다.
BIOS 아키텍쳐(BIOS Architecture)
BIOS 아키텍쳐는 EOSIO Dawn 2.0과 가장 많이 변경된 아키텍쳐 사항 중 하나입니다. EOSIO Dawn 3.0에서, 대다수의 블록체인 비즈니스 로직이 하드포크 없이 커뮤니티에 의해 다이나믹하게 업데이트 될 수 있는 스마트 컨트랙트로 옮겨갔습니다. 이제 EOSIO 블록체인의 기본 골자는 어떤 토큰, 투표, DPOS도 없는 단일의 프로듀서입니다. 코어 블록체인에는 계정을 생성하고, 컨트랙트를 배포하고, 리소스를 할당하는 능력을 가진 권한 시스템만이 구현되어 있습니다. 블록체인을 토큰, 투표, 지분, 리소스 할당을 포함하는 DPOS로 만드는 것은 시스템 컨트랙트 기반의 웹어셈블리에 의해 정의됩니다.
이 새로운 아키텍쳐를 통해 우리는 블록체인의 정적 비-웹어셈블리 부분의 개발에 집중할 수 있게 되었습니다. 이것들은 안정성에 가장 중요한 영향을 끼치는 부분이며, 업그레이드를 하기 가장 어려운 부분이기도 합니다. EOSIO Dawn 3.0과 1.0 사이에 우리는 시스템 컨트랙트와 지분행사(staking), 투표에 대한 세부 사항들을 마무리 지을 것입니다.
보안 기능(Security Features)
보안은 모든 컴퓨팅 시스템에 있어 중요한 요소이며 우리는 EOSIO를 시장에서 가장 안전한 블록체인으로 설계했습니다. 보안은 해킹의 위험, 하드웨어 장애와 분실, 비밀번호 분실 등 다차원적으로 고려해야 하는 문제입니다. 하드웨어 지갑은 해킹으로부터 보호하기에 좋지만 그럼에도 불구하고 만약 보호에 실패하는 경우에는 접근하지 못 하게 될 수도 있습니다. 뿐만 아니라 종이에 적어두는 백업은 잃어버리거나 도난당할 수 있는 위험이 있습니다.
보안 지연 거래(Security Delayed Transactions)
EOSIO Dawn 3.0에 추가된 가장 중요한 기능 중 하나는 각 작업들에 대해 사용자가 지연 시간을 설정 가능하게 되었다는 점입니다. 이 지연을 통해, 거래는 적용이 될 수 있기 전 까지 수 시간/수 일에 걸쳐서 블록체인에 전파되어야 합니다. 지연되는 시간 동안 사용자는 그들의 계정을 더 높은 권한 레벨로 재설정하기 위해 조치를 취할 수 있으며 거래를 취소할 수도 있습니다. 이는 해킹을 당했다는 사실을 알았을 때 이미 너무 늦어서 아무 조취도 취할 수 없는 다른 블록체인들과 비교했을 때 정말 크게 개선된 점이라고 할 수 있습니다.
분실 패스워드 찾기(Lost Password Recovery)
모든 계정은 최소 두개의 승인 레벨이 있습니다: “Owner” 와 “Active”. Owner 승인 레벨은 Owner의 키를 포함하지 않는 N이 없는 M개의 멀티시그의 N입니다. Owner 승인 레벨은 Active 키를 분실하였거나 도난당하였을 시 언제든지 Active 승인을 재설정할 수 있습니다.
만약 Owner 키를 분실하였거나 멀티시그 파트너가 비협조적일 경우, 계정의 Active 승인은 Owner 승인이 비활성화 된지 30일 후에 Owner 승인의 재설정을 요청할 수 있습니다. Owner 권위자는 Active 권위자를 업데이트하여 향 후 7일간 해당 요청에 이의를 제기할 수 있습니다.
이러한 모델 내에서 하나 또는 다수의 하드웨어 월렛에 의해 통제되는 계정 Owner 승인은 해킹과 장치 오류 발생으로부터 안전할 것입니다. 만약 장치가 하드웨어 및 지문/얼굴 인식 개인키가 있는 애플의 아이폰이라면, 공격자는 당신의 멀티시그 파트너를 해하여야 하고 물리적으로 당신의 스마트폰과 지문과 얼굴을 훔쳐야 합니다. 당신의 멀티시그 파트너도 생물학적으로 안전한 하드웨어 장치를 사용 중일 것이지만 말입니다.
거래 제안 시스템(Transaction Proposal System)
멀티시그(Multisig)는 기존 거래의 제한된 시간 내에 모든 서명을 모아야 하는 것이 아니라, 사용자가 본인의 승인을 독립적으로 원하는 시간대에 추가 및 제거할 수 있어야 쉬워집니다. 제안 시스템을 통하여 누구든지 거래를 제안할 수 있으며 그 거래에 속해 있는 당사자가 거래를 간단히 승인할 수 있습니다. 승인을 추가한 뒤 충분히 많은 한계치에 도달하기 전까지 언제든지 승인은 제거될 수 있습니다.
이 시스템을 구현하기 위하여 우리는 컨트랙트가 특정 계정 승인이 거래를 인가하기에 충분한지를 평가할 수 있도록 하는 새로운 API를 추가하였습니다. 이는 하드포크를 필요로 하는 것이 아닌, 새로운 웹어셈블리(WebAssembly)를 사용하여 멀티시그 과정을 업그레이드 할 수 있게 합니다.
간소화된 컨트랙트 개발(Simplified Contract Development)
EOSIO의 수 많은 목표 중 하나는 컨트랙트 개발을 가능한 간단하고 힘들지 않게 하는 것입니다. 만약 개발자가 C++를 사용할 줄 안다면 가능한 적은 복잡한 표준 문안을 토대로 스마트 컨트랙트를 작성할 수 있을 것입니다.
우리는 간소화된 “Hello World” 컨트랙트를 몇 줄의 간단한 코드로 작성하였습니다. 우리의 도구들은 컨트랙트 ABI를 생성하는 과정과 사용자의 행동을 상대방이 지정해 놓은 방법으로 보내는 과정을 자동화 하였습니다. 즉, 컨트랙트를 개발하는 일이 매우 쉬워졌습니다.
부동 소수점 지원(Floating Point Support)
스마트 컨트랙트 개발을 간소화하는 작업의 일부는 개발자들이 필요로 하는 수학적 알고리즘이 더욱 쉽게 구현되도록 하는 것입니다. 블록체인 개발의 가장 어려운 부분 중 하나는 바로 부동 소수점 계산 및 이와 관련된 power, root, trig 함수의 부재였습니다. Bancor와 같은 많은 알고리즘들은 모든 계산을 오류가 쉽게 발생하고 메모리 사용이 많은 고정 소수점(Fixed point)을 사용하는 대신, 부동 소수점을 사용하여 훨씬 더 쉽게 알고리즘이 구현되도록 할 수 있습니다.
우리는 웹어셈블리 컨트랙트(WebAssembly contracts)에 의하여 투명하게 사용되어지고 있는 소프트웨어 부동 소수점 라이브러리(Software floating point library)를 통합시켜 하드웨어 부동 소수점의 비결정적(Non-deterministic) 성질을 해결하였습니다. 소프트웨어 부동 소수점 라이브러리를 통하여 우리는 여러 상황에서 고정 소수점보다 별로 크지 않은 비용으로 결정성 및 개발의 용이와 같은 이점을 얻습니다. 많은 상황에서 고정 소수점은 결정적 성질을 지닌 부동 소수점보다 에러가 쉽게 발생하거나 메모리를 더욱 많이 차지합니다.
C++ 표준 템플릿 라이브러리(C++ Standard Template Library Support)
EOSIO Dawn 3.0에서 우리는 대다수의 C++ 표준 템플릿 라이브러리 사용자들을 지원할 수 있도록 큰 힘을 쏟았습니다. 이는 개발자들이 그들이 이미 친숙한 툴, 라이브러리 및 알고리즘을 사용할 수 있으며 이러한 알고리즘의 비표준 구현으로 발생할 수 있는 버그의 가능성을 제거합니다.
예약 거래(Scheduled Transactions)
특정 컨트랙트가 충분한 대역폭을 보유하고 있다는 전제 하에, 예약 거래 개발자를 통하여 이제는 영원히 작동하는 컨트랙트를 작성할 수 있습니다. 다른 플랫폼들은 적절한 시기에 컨트랙트를 작동시키기 위하여 오프체인(Off-chain) 방식을 필요로 합니다. 하지만 예약 거래를 통하여 개발자들은 더 이상 그들만의 서버를 불러와 컨트랙트가 돌아가게 할 필요가 없으므로 더욱 효율적이고 사용이 용이해 졌습니다.
자동 범위 감지(Automatic Scope Detection)
EOSIO Dawn 2.0에서는 모든 거래가 어떠한 데이터 범위에 접근하려는 것인지 직접 밝혀야 했습니다. 이는 오류가 쉽게 발생할 뿐만 아니라 개발자들에게 큰 부담이 되었었습니다. Dawn 3.0에서는 블록생성자(BP)가 어떠한 데이터 범위가 접근되어지고 이들 사이의 충돌을 방지하는 결정을 하는 의무를 지게 됩니다. 이는 모든 거래를 더 가벼워지게 하며 스케줄링 오버헤드(Scheduling Overhead)를 사용자, 개발자 또는 풀노드(Full nodes)가 아닌 블록생성자에게 전달하게 됩니다.
다중 색인 데이터베이스 API(MultiIndex Database API)
EOSIO Dawn 3.0은 boost::multi_index_container를 반영하는 새로운 데이터베이스 API를 소개합니다. 이 API를 통하여 다중 키로 분류된 데이터베이스 테이블 지원, 아이템 검색, 하한/상한 설정, 데이터베이스 내 반복작업 등이 수월해집니다. 이 새로운 API는 반복자 인터페이스(Iterator Interface)를 사용하여 테이블을 통한 스캐닝의 효율을 극대화합니다.
또한 64, 128, 256 및 512 비트 정수는 물론 64 비트 부동 소수점에서도 색인을 가질 수 있습니다. 스트링 인덱스(String Index)는 EOSIO 1.0이 출시되기 전에 지원될 예정입니다. 이는 동일 테이블 내 거의 무한한 수량의 색인필드를 가질수 있다는 점에서 유연성의 증가와 개발의 편의제공에 큰 기여를 할 예정입니다.
성능(Performance)
우리 팀은 현실에서의 성능을 면밀히 모니터링해 왔으며 이 결과에 매우 기쁩니다. 우리는 미래의 최적화(optimization)를 가능하게 하며 성능의 하한선과 상한선을 이해하기 위해 소프트웨어를 여러 다른 구성으로 벤치 마크했습니다. 이 모든 테스트는 연산 복잡성 측면에서 토큰 전송이 비트코인 또는 이더리움 ERC20 토큰 전송과 동등하게 비교되는 것을 가정합니다.
워스트 케이스(Worst Case) — 1,000 TPS
이 경우는 어떠한 최적화도 없는 우리의 기본 성능입니다.
우리는 단일 스레드 서명 확인으로 인터프리터(interpreter)를 실행하는 다중 노드 네트워크를 사용하여 1000 TPS 이상을 유지할 수 있습니다.
일반 케이스(Average Case) — 3,000 TPS
JIT 컴파일러(compiler)를 사용하면 단일 스레드 서명 확인을 통하여 인터프리터(interpreter)를 실행하는 다중 노드 네트워크를 사용하여 3000 TPS를 유지할 수 있습니다.
베스트 케이스(Best Case) — 6,000 TPS
병렬 서명 검증을 구현 한 후에는 병렬 처리 수준(level of parallelism)과 서명 수가 증가함에 따라 서명 당 벽 시간(wall-clock-time)이 0에 가까워 진다고 가정 할 수 있습니다. 서명 검증을 사용하지 않음으로써 이 환경을 시뮬레이션할 수 있습니다. 이 모델에서는 JIT 컴파일러(compiler)를 사용하여 다중 노드 네트워크에서 6,000 TPS를 달성 할 수 있습니다.
이론적 케이스(Theoretical Case) — 8,000TPS
방정식에서 네트워킹 코드를 제거하고 서명 확인 기능을 끄고 JIT를 사용하여, CPU가 수행 할 수있는 작업에만 초점을 맞추면 초당 8,000의 단일 스레드 거래를 달성할 수 있습니다. 단일 체인에서 성능을 이보다 더 높이기 위해서는 WebAssembly의 병렬 처리구현과 보다 진보된 스케줄러가 필요합니다. 같은 경우로 JIT 대신 Interpreter를 사용하는 경우 2700 TPS를 얻을 수 있습니다.
이는 JIT를 사용하는 비교적 간단한 변화로 전송 성능을 약 3배 향상시킬 수 있음을 의미하며 본 수치들은 MacBook 2.8His i7에서 측정되었습니다.
초당 무한 거래(Unlimited Transactions Per Second)
“초당 거래”의 정의는 종종 큰 의미가 없는 비교일 뿐입니다. 블록체인간 통신(Inter-blockchain communication)을 통해 우리가 원하는 만큼 많은 블록체인 사이에서 작업량을 나눌 수 있습니다. 토큰은 다른 체인들 간 안정적이고 안전하게 전송될 수 있습니다. 동일한(혹은 다른) 블록 생산자에 의해 병렬로 운영되는 1000 개의 체인을 통해 우리는 초당 수백만의 거래를 얻을 수 있었습니다. 이는 다른 블록체인에 의해 제시된 이론상의 확장 제안이 실질적으로 실현됨을 의미합니다.
우리는 EOSIO 기반 퍼블릭 네트워크의 블록 생산자에게 사용자 수요를 충족시키는데 필요한 많은 체인을 운영할 것을 강력하게 권합니다. 모든 체인은 동일한 토큰을 기본으로 하고 이를 통하여 스테이킹(Staking) 및 자원 할당을 할 수 있습니다. 이것은 한 토큰에 대하여 가능한 큰 네트워크 효과를 만들어 낼 것이며 큰 시가총액을 가진 토큰이 주는 경제적 인센티브(Economic Incentive)의 신뢰성과 보안성을 최대한으로 활용할 수 있을 것입니다.
거래소, 통화, 그리고 소셜 미디어와 같은 어플리케이션은 여러 병렬 체인을 통하여 업무량의 균형을 쉽게 잡을 수 있습니다.
나아갈 길(The Road Ahead)
EOSIO Dawn 3.0은 핵심 플랫폼의 안정성에 초점을 두었습니다.
다음 몇 달에 걸쳐 스테이킹, 투표 그리고 거버넌스 메커니즘을 구현하는 최종 시스템 컨트랙트를 준비할 것입니다. 또한 우리는 토큰 기준(Token Standard)도 마무리 지을 예정입니다.
시스템 컨트랙트가 우리가 예상했던 바와 같이 성숙해지면 우리는 새로운 퍼블릭 테스트 네트워크를 런칭할 것입니다. 그 때까지 우리는 여러분 개인의 테스트 네트워크 및 어플리케이션 개발 과정을 최대한 간소화 할 것입니다. 또한 개발자 분들에게 혼선을 빚지 않게 하기 위하여 새로운 테스트 네트워크를 준비하는 다음 몇 주간 현재의 퍼블릭 테스트 네트워크를 닫을 예정입니다.
요약(Summary)
EOSIO Dawn 3.0은 안정적인 API를 통하여 개발자들에게 기능적 완벽(Feature Complete)을 제공하도록 고안되었습니다. 우리는 현재 이 플랫폼이, 전문 개발자들이 어플리케이션을 구축을 시작 할 수 있을 정도로 안정적이라고 생각합니다. EOSIO는 우리가 1년 전 구상했던 것보다 훨씬 더 강력해지고 개발하기 쉬운 환경을 제공하게 되었습니다.
우리 팀은 계속 성장하고 있고 개발은 여느 때보다 빨리 진행되고 있습니다. 우리 저장소(Repository)는 과거 몇 달간 모든 깃헙(Github)을 통틀어 C++ 저장소 중 가장 활발한 활동을 보인 Top 10 저장소 중 한 곳이 되었습니다. 모든 일들이 올해 6월에 있을 EOSIO 1.0 의 수준 높은 공식 출시를 위하여 순조롭게 진행 되고 있습니다.
EOSYS는 한국 대표 EOSIO Block Producer 후보로서 EOSIO 커뮤니티 내 한국 커뮤니티의 목소리를 내고, 해외 BP들은 물론 타 국내 BP 후보들을 돕고 이끌며 성공적인 6월 mainnet launch를 지원합니다.
건강한 EOSIO 생태계 활성화를 위해 지속적으로 고민하고 발전해나가고 있으니, EOSYS 와 함께 건전한 EOSIO 생태계와 한국 커뮤니티 건설에 참여해 주시기 바랍니다.
감사합니다.
EOSYS 팀 드림
Website: http://eosys.io
Steemit: https://steemit.com/@eosys
Medium: https://medium.com/@eosys
Twitter: https://twitter.com/@eosys_io
Telegram (영문): https://t.me/eosysio
Telegram (한글): http://t.me/eosysiokr