본 글은 block.one이 2017.9.3 (한국시간 기준)에 발표한 The Dawn of EOS.IO 를 한국어로 번역한 글입니다.
원문의 의미와 느낌을 최대한 살리기 위해서 약간 번역투에 가깝게 번역을 했습니다.
잘못된 번역이나 기술적표현이 있다면 댓글로 지적해 주시면 바로 수정하겠습니다.
EOS.IO의 기술백서(Technical White Paper)에서 우리는 EOS.IO 소프트웨어를 새 시대의 블록체인 컴퓨팅의 여명으로서 제시했습니다. EOS.IO 개발팀은 이번 여름동안 매우 열심히 일해왔습니다. 이제 여름은 끝났고, EOS.IO 소프트웨어 개발은 예정보다 앞서나가고 있습니다. 이제 EOS.IO를 분산네트워크 설정과 함께 사용할 수 있습니다. EOS.IO 소프트웨어 개발에 대해 공유할 내용이 많으니 끝까지 읽어주길 바랍니다.
성능의 증명(Proof of Performance)
이제 EOS.IO소프트웨어가 분산네트워크 설정에서 이용될 수 있기 때문에, 우리는 성능을 측정할 수 있습니다. 우리 내부 테스트에 따르면 현재 멀티노드네트워크에서 초당 10,000이 넘는 단일 쓰레드 트랜잭션을 유지할 수 있습니다. 이는 100개가 넘는 코어를 가진 장치에서 100만 TPS를 지원하기 위한 소프트웨어로서 궤도에 올라있다고 할 수 있습니다.
디자인에서의 진보 (Advancements in Design)
우리의 최신 소프트웨어 아키텍쳐상의 향상은 서로 통신하는 병렬어플리케이션을 만드는데 있어 그 어느 때보다도 쉽다는 사실을 알게되면 개발자들은 흥분할 것 입니다.
공유된 데이터베이스 접근 (Shared Database Access)
이제 우리는 복잡한 비동기 통신 없이도 한 어플리케이션이 다른 어플리케이션의 데이터베이스 상태를 읽도록 할 수 있습니다. 우리는 병렬로 실행할 수 있는 능력은 유지하면서 각 트랜잭션이 읽기/쓰기를 해야하는 데이터 범위의 스코프를 선언하도록 하면서 달성합니다. 블럭 생성자들이 트랜잭션의 시간계획을 세우게 될 것이고, 이에 따라 데이터 충돌은 없을 것입니다.
어플리케이션 데이터의 사용자 로컬 저장소 (User Local Storage of Application Data)
계정, 어플리케이션을 넘어서 읽기 접근을 할 수 있을 뿐 아니라, 이제 다른 계정에 데이터를 저장할 수도 있습니다. 이는 화폐 계약이 그것 고유의 스코프가 아니라 개인 계정의 잔고(Balance)에 작성될 수 있다는 뜻입니다. Alice가 Bob에게 화폐를 전송하는 경우라면 둘의 범위에서만 읽기/쓰기 권한이 필요하지, 화폐 계약의 스코프에는 영향을 주지 않습니다. 이는 어플리케이션의 많은 클래스들을 아주 간단하게 병렬로 만들어주고, 싱글 쓰레드 처리량 제한을 넘어 화폐 전송을 처리할 수 있게 합니다.
인라인 메시지 전달 (Inline Message Passing)
이제 다른 어플리케이션으로 메시지를 보내고 이것이 받아들여지거나 유효해질지를 아는 것이 어느 때보다도 쉽습니다. 하나의 어플리케이션은 몇개든 추가적인 메시지를 생성해 현재 트랜잭션에 덧붙일 수 있습니다. 이렇게 생성된 메시지들이 같은 읽기/쓰기 스코프를 공유하고 할당단 시간내에 실행될수만 있다면, 이들은 같이 전달되거나 트랜잭션이 통째로 되돌려질 것입니다.
이런 접근은 다른 플랫폼에서 사용되는 동기적(synchronous) 접근법과는 차이가 있습니다. 동기적 메시지 전달은 현재 쓰레드가 되돌아올때까지 다른 실행을 막고, 예상치 못한 재진입의 가능성을 야기합니다. 재진입은 수많은 버그와 취약점의 원천이었습니다. 왜냐하면 다른 개발자들로 하여금 동기적인 호출을 만드는데 앞서 그들의 계약이 일관성있는 상태에 있는지 확신하기가 어렵게 만들기 때문입니다. 인라인 메시지 전달방식은 현재 트랜잭션 핸들러의 종료때까지 실행(execution)을 지연시키므로써, 개발자들로하여금 메시지를 송신하고 이것이 성공한 것처럼 진행할 수 있다. 만약 이것이 실패하면 어떠한 부작용 없이 트랜잭션이 통째로 되감아질 것입니다. 이는 당신의 메시지 핸들러가 일관성 없는 상태에서는 절대 호출되지 않는다는 것을 의미합니다.
지연된 메시지 전달 (Deferred Message Passing)
때로는 당신은 메시지가 유효한지 또는 현재 트랜잭션에서 인라인을 실행할만큼 충분한 시간이 남았는지 모를때가 있습니다. 예전에는 당신은 현재 트랜잭션 스콥 밖의 데이터에 접근하기 위한 메시지를 전송해야 했습니다. 이런 상황에서 어플리케이션들은 블록생성자들에게 메시지가 다음번 주기(cycle)나 미래 블록에서 전달되도록 계획해달라고 요청할 수 있습니다. 이것이 유요하다면 당신의 어플리케이션에게 통지될 것입니다. 만약 그렇지 않다면 요청한대로 계획될 일은 없을 것이며 당신의 어플리케이션은 타임아웃 이후에 클린업을 할 수 있을 것입니다.
역주: 위에서 클린업이란 해당 메시지와 관련된 프로세스들을 정리하는 행위로 볼 수 있을 것 같습니다.
무제한의 수평적 확장 (Unlimited Horizontal Scaling)
EOS.IO에서의 최신의 디자인 진보는 개발자로 하여금 높음 단일기계 성능(Single-machine performance)을 줍니다. 사업들을 더 복잡한 비동기 구조 없이도 백만 트랜잭션으로 확장할 수 있습니다.
그렇긴 하지만, EOS.IO 소프트웨어는 서로 상태를 공유할 필요가 없는 어플리케이션들의 그룹간 비동기 메시지 전달을 여전히 지원할 것입니다. 비동기 메시지 전달에는 Trivial cluster 지원과 같은 다양한 장점들이 있습니다. 하지만 이러한 장점들은 개발 복잡성을 증가시켜야만 얻을 수 있습니다. EOS.IO 소프트웨어는 수백만의 TPS를 필요로 하는 사업들을 위해 이러한 비동기 메시지 전달을 지원하지만, 그렇지 않은 이들을 위해서는 간결한(streamlined) 접근법을 제공합니다.
네트워크 토폴로지의 다음 세대 (Next Generation Network Topology)
EOS.IO 소프트웨어는 블록 생성자들이 고성능의 탈중앙화 인프라를 서비스 형태로 제공하도록 권한을 부여합니다. 어플리케이션 개발자들은 트랜잭션을 모아주는 블록생산자들 이외에도 API 노드(API nodes)들과 Seed 노드(Seed nodes)들, 데이터베이스 인덱스(Database indexes), 저장소(storage) 그리고 호스팅(hosting)을 필요로 합니다.
고성능 블록체인은 기존 블록체인의 매우 다양한 요구사항을 만족시키는 고성능 네트워크 아키텍처를 필요로 합니다. 연결당 100메가바이트를 달성하려면 노드당 백만TPS가 요구됩니다. 이는 큰 데이터 센터들에게는 별일 아니지만, 일반 가정 사용자들에게는 상상도 할수 없는 일입니다.
또한 고성능 블록체인은 서로다른 부분집합의 블록체인은 돌리는 여러 종류의 노드들로 구성되며, 트랜잭션 히스토리를 제거할 가능성이 높습니다. 이것은 각각의 노드가 동일하며 모든 기록을 가지고 있었던 이전의 블록체인 시스템들과는 다른 매우 중대한 변화입니다.
전통적인 블록체인은 망사형 네트워크(mesh network)에서 임의적으로 연결된 노드들의 동적인 세트를 포함합니다. 그들은 가정 사용자에게 제한된 대역폭을 제공하는것을 목표로 하며, 가정용 라우터를 지나 동적으로 노드들을 네트워크에 더하도록 설계되어 있습니다. 우리가 관찰한 바에 따르면 이런 아키텍쳐는 고성능 블록체인 인프라스트럭처에는 적합하지 않습니다.
EOS.IO 소프트웨어는 모든 노드는 의도적으로 다른 노드에 연결되어있다는 가정으로 부터 출발합니다. 노드 운영자들은 네트워크 토폴로지가 안전한고, 잘 계획되고, 효율적이 되도록 함께 동작합니다. 이는 블록 생성자들로 하여금 서로 직접적이고 안전한 연결을 수립하게 하고 공격자(역주. 해커)들로 하여금 정지시킬 노드들을 찾기위해 전체 네트워크를 스캐닝할 수 없게합니다.
역주: 비탈릭이 EOS에 대해 비판할 때 노드가 중앙화 되어있으면 ddos공격에 취약하다고 주장했습니다. 이 주장에 대해서 정면 반박하는 내용입니다. 중요한 연결은 신뢰할 수 있는 블록생성자들 끼리만 하므로 오히려 안전하다는 것이죠. 물론 개념적인 수준에서는 양쪽의 주장이 다 가능성이 있습니다만, 중앙화된 노드들이 해킹이 쉽다는 주장은 각 노드가 이더리움과 같이 일반 가정집 수준의 보안을 하고 있을 때를 가정한다고 생각합니다. 중앙화된 만큼 각 블록생성자들에게는 기업수준의 보안솔루션이 적용이 되어야 하고 자연스럽게 그렇게 될 것이고 해킹위험은 현저히 낮을 것이라고 봅니다. 해킹이 쉬운 노드 수만개를 동시에 해킹하는 것은 불가능하지만, 해킹이 어려운 노드 51개를 동시에 해킹하는 것도 불가능에 가까울 만큼 어려울 것입니다.
블록생성자들은 공개 엔드포인트를 호스트하여, 누구든 접속하고 그들이 원하는 어떠한 트랜잭션의 부분집합이든 구독할수 있게할 것입니다. 이것은 블록생성자가 아닌이들에 의해 운영되는 노드를 위한 대역폭 요구사항을 최소화합니다. 단일 블록생성자를 신뢰하기 싫은 노드들은 여러 출처들을 동시에 구독하거나 아니면 2/3의 블록생성자들로 부터 확인을 받을때 까지 기다릴 수 있습니다. (약 45초정도 소요됩니다.)
이 아키텍쳐의 장점은 새로운 노드들이 블록생성자들로 부터 제공되는 고대역 인프라스트럭처에서 매우 높은 속도로 연결하고 동기화 할 수 있다는 것입니다. 더 나아가 이 아키텍쳐는 비효율적인 양방향 프로토콜 보다는 효율적인 단방향 스트리밍을 가능케 하도록 설계되었습니.
크게보면 블록생성자들은 새로운 인터넷의 근간을 EOS.IO 소프트웨어를 이용해 운영하게 될 것입니다. 블록생성자들은 대륙간 광섬유를 제공했던 이를테면 1티어 인터넷 공급자와 같아질 것입니다. 이런 생성자들은 2-Tier 구독자들이 연결할 수 있는 데이터센터들을 운영할 것입니다. 2티어에는 전체 또는 일부 노드나 아니면 큰 어플리케이션을 구동하기 원하는 누구나 속할 수 있습니다. 예를들면 블록 탐색기(Block explorer), 전자지갑(web wallets), 암호화폐 거래소(crypto-currency exchange)가 블록생성자의 2티어 구독자가 될 수 있습니다.
우리는 의도적인 협동네트워크 구축 아키텍쳐가 블록생성자들로하여금 암호화폐 산업에 거의 없는 양질의 서비스를 제공하도록 할 것이라는 느낌이 듭니다.
나아갈 길 (The Road Ahead)
올해 9월, block.one은 EOS.IO Dawn 1.0을 배포할 것입니다. 이는 충분히 안정적이고 잘 문서화 되어서 누구나 자신의 테스트 네트워크를 실행하고, 그들의 어플리케이션을 구축/실행 해볼 수 있을 것입니다. EOS.IO Dawn 1.0은 우리의 EOS.IO SDK의 첫 선배포가 될 것입니다.
EOS.IO의 로드맵을 따라가고 있었던 이들이라면 우리가 기존 스케줄보다 앞서 있다는 사실에 기쁠 것입니다. 1단계(Phase 1), 최소 성공가능 테스트 환경(Minimal Viable Testing Environment) 은 이미 완료되었습니다. 이는 독립노드, 네이티브 계약, 가상머신 API, RPC 인터페이스, 커맨드라인 툴 (eosc) 그리고 기본 개발자 문서를 포함합니다. 우리는 "EOS.IO Dawn 1.0"이라고 태그된 배포를 할 것입니다. 이 단계는 이번 여름 9월 22일 전에 끝내기로 예정되어 있었습니다.
우리는 이미 2단계, 최소 성공가능 테스트 네트워크 (Minimal Viable Test Network)의 절반을 끝냈습니다. 이 단계는 2017년 가을에 끝내기로 예정되어있으며, 워킹 네트워킹 코드, 가상머신 샌드박싱, 자원 사용과 레이트 제한, 제네시스 임포팅 그리고 블록체인간 커뮤니케이션을 포함합니다. 현재 우리는 이미 기능적인 분산 네트워크들과 가상머신샌드박싱을 이미 가지고 있습니다. 우리는 2단계를 일정내에 끝낼 수 있다고 확신합니다.
EOS.IO Dawn 2.0, 다음 메이저 선배포는 올해 말에 있을 것입니다.
EOS.IO Dawn 2.0은 EOS.IO Dawn 1.0에는 없는 몇몇 중요한 특징들을 포함합니다.
이는 다음과 같습니다:
- Resource Rate Limiting (preventing spam / abuse)
- Merkle Tree Generation (for cross chain communication)
역주: 비탈릭이 EOS에 대해 비판할때 머클트리가 없다는 점을 지적하기도 했었는데, 당시 댄은 머클트리는 퍼포먼스에 악영향을 준다고 답변한 바 있습니다. 퍼포먼스를 떨어트리지 않으면서 어떻게 머클트리를 구현할지 기대됩니다.
- Upgrade Management and Governance
- More robust SDK
역주: SDK가 Robust해진다는 것은 쉽게말해 더 대충짜도 잘 돌아간다고 이해하면 됩니다. 에러에 더 잘 대응한다고도 볼 수 있습니다.
- General Infrastructure improvements
- Example Snapshot from ERC20 tokens
EOS.IO Dawn 2.0의 목표는 실제 블록체인을 구동할만큼 충분히 기능적이게 만드는 것입니다.
One More Thing....
EOS.IO Storage....
최초로, 개발자들은 탈중앙화 앱과 웹인터페이스를 대역폭이나 저장소 비용 심지어는 그들이 직접 호스팅할 걱정 없이 만들고 구동할 수 있을 것입니다. 이는 탈중앙화 유튜브, 사운드클라우드 또는 다른 저장소 집중적인 프로젝트와 같이 새롭고 혁신적인 탈중앙화 비즈니스모델을 가능케합니다.
컴퓨터의 대역폭에 더하여, EOS.IO 순정 소프트웨어 기반의 블록체인 보유자들은 무료 클라우드 스토리지, 호스팅, IPFS/HTTPS를 통한 다운로드 대역폭에 접근할 수 있을 것입니다. 이 접근은 토큰을 소모하거나 어디 보내지 않고도 가능합니다.
이를 달성하기 위해, 블록 생성자들은 사용자에게 파일들을 IPFS/HTTPS로 호스팅하고 다른 유저들이 이 파일들을 다운로드 할수 있게 합니다. 저장소 자원들은 블록체인 방출과 토큰보유자들에 대한 이자를 통해서 보상됩니다. EOS.IO 대역폭 모델과 마찬가지로, 저장소는 EOS.IO 소프트웨어 블록체인 토큰을 소모하지 않으며, 토큰당 저장소 용량은 블록 생성자들의 하드웨어 업그레이드를 통해 점점 늘어나게 될 것 입니다.
EOS.IO 소프트웨어 저장소 솔루션은 또한 토큰을 전혀 가지고 있지 않은 사람들의 퍼블릭 호스팅을 지원할 수도 있습니다. 더 자세한 내용은 상하이와 런던에서 곧 열릴 블록체인 산업 행사에서 공개될 예정입니다.
P.S. Disclaimer는 법적인 고지내용이라서 번역에서 제외하였습니다.