EOS.IO Dawn 2.0은, 블록원 팀이 운영할 퍼블릭 테스트 네트워크와 함께 출시되었습니다. 이번 출시는 2017년 가을 로드맵에 설명되고 원래 2017년 12월 21일을 완료일로 정했던 남은 기능들 대부분을 구현한 알파 버전입니다. 로드맵에 게시한 내용과 같이 "2단계 - 최소 실행 가능 테스트 네트워크"는 2017년 가을까지 아래 기능을 보여줄 예정이었습니다.
- P2P 네트워크 코드
- 웹어셈블리 정리 & CPU 샌드박싱
- 자원 사용량 추적 / 사용 속도 제한
- 제네시스 임포트 테스트
- 블록체인간 통신
현재 시점에서 본다면 우리는 기능 대부분의 초기 구현에 도달했습니다. 그런데 병렬적으로 개발을 진행하다보니 블록체인간 통신의 구현체는 초기 테스트 네트워크에서 사용하지 않을 별도 브랜치에서 개발되었습니다.
EOS.IO Dawn 2.0의 성능 테스트에 관심있는 분들은 프라이빗 네트워크를 론치하고 운영할 수 있는 모든 블록체인 코드와 네트워크 코드를 깃헙 저장소에서 찾을 수 있습니다. 평균적인 하드웨어에서 단일-쓰레드 구현을 이용해서 자체적으로 테스트해보니 1초마다 블럭을 생성할 때 초당 수천 건의 이체 트랜잭션 처리를 유지할 수 있습니다. 그렇긴 하지만, 우리가 아직 해결책을 구현해놓지 않은 알려진 공격 경로가 존재합니다. 예를 들면, 새로운 컨트랙트가 처음으로 컴파일될 때 34 밀리초(ms)가 소요될 수 있고, 30 TPS로 이런 트랜잭션을 보내는 방식으로 악용하면 네트워크가 부서지는 결과를 초래할 수 있습니다.
이 문제에 대한 우리의 해결책은 컨트랙트 코드가 업데이트될 수 있는 빈도와, 코드가 업데이트되는 시점과 새로운 코드를 사용하는 트랜잭션이 처리될 수 있는 시점 사이의 지연 시간에 제한을 설정하는 것입니다. 모든 블록 프로듀서가 웹어셈블리 코드로부터 최적화된 x86 인스트럭션을 컴파일하고 캐시하기까지의 시간을 허용하기 위해서, 이런 지연 시간은 약 60초가 될 것입니다.
이와 같은 아직 해결되지 않은 공격 경로가 존재하기 때문에, 성능 테스트는 프라이빗 테스트 네트워크에서 진행할 작업으로 남겨둡니다. 가동 시간과 접근성을 보장하기 위해서 우리가 인위적으로 30 TPS로 제한한 퍼블릭 테스트 네트워크를 통해서 기능 테스트를 이제 진행할 수 있습니다.
다음 6개월에 걸쳐서, 우리는 지속적으로 네트워크를 테스트하고 디버깅해서 안정성과 성능을 개선할 것입니다.
우리는 이더리움 네트워크에서 구동되는 EOS ERC-20 토큰 배포 결과에 기반한 초기 상태를 가져올 수 있는 스냅샷 툴을 구현해왔습니다. 우리의 테스트 네트워크에는 유효한 EOS 공개키로 등록된 잔고만 포함시킬 것입니다. ERC-20 토큰의 약 20%는 EOS 공개키로 적절하게 등록되어 있습니다. 서명된 이더리움 트랜잭션 정보를 이용해서 이더리움 계정의 공개키를 복원할 수 있기 때문에, 우리는 등록되지 않은 ERC-20 토큰을 소유한 모든 이더리움 계정을 위한 대비용 툴을 스냅샷 툴에 구현했습니다. 이 툴을 이용하면 전체 EOS ERC-20 토큰의 99%에 대응할 수 있지만, EOS.IO 지갑에 이더리움 비밀키를 임포트해야만 합니다.
보안상의 이유로, 우리의 테스트 네트워크는 대비용 프로세스를 통해서 사용자의 이더리움 비밀키를 임포트하도록 요청하지 않을 것입니다. 만약 당신의 EOS 비밀키가 테스트 도중에 노출된다면, 이더리움 네트워크를 통해서 언제나 새로운 키를 등록할 수 있습니다.
우리는 가진 토큰이 없거나 유효한 EOS 공개키를 등록하지 않은 사용자들이 네트워크를 테스트할 수 있도록 토큰을 나눠주는 수도꼭지 기능도 구현해왔습니다.
우리는 기본적인 사용 속도 제한 기능과 자원 사용량 추적 기능을 구현해왔습니다. 이 기능은 대역폭, 데이터베이스 스토리지 사용량, 연산 사용량을 추적합니다. 현재 시점에서 우리가 구현한 사용 속도 제한 알고리즘에 알려진 버그가 있습니다만, 어플리케이션을 테스트하고 진행하는 데 있어서 방해가 될 수 있는 것은 아무것도 없습니다.
우리는 많은 사람들이 사용 속도 제한 방식이 어떻게 동작하는지, 누구에게 사용량이 청구되는지, 수익을 얻기 위해서 지분참여한(staked) 토큰을 임대할 수 있는 방법에 대해 좀더 많은 정보를 요청하고 있다는 점을 알고 있습니다.
모든 트랜잭션은 블록 프로듀서들이 설정한 최대 네트워크 대역폭의 일부를 소모합니다. 트랜잭션 진행에 필요한 자격(authority)을 가진 모든 계정은 트랜잭션의 크기에 근거해서 증가되는 3일 평균 대역폭 사용량이 계산될 것입니다. 대역폭을 사용하기 위해서는, 소유 토큰 중 지분참여한 토큰이 있거나 어플리케이션 제공자가 지분참여한 토큰을 위임 받은 (컨트랙트가 아닌) 승인 자격을 가진 계정(authorizing account)을 이용해야 합니다.
모든 트랜잭션을 진행하려면 약간의 연산이 소모됩니다. 연산은 병렬로 실행될 수 있고, 그래서 서로 다른 모습으로 정체 구간이 생기는 다차선 고속도로로 비유할 수 있습니다. 각 scope(차선)은 저마다의 별도의 사용 속도 제한이 있고, 동시에 사용하는 scope(차선)의 수와 가장 정체가 많은 scope에 기반한 사용 속도 제한 정보를 이용해서 O(S^2) 만큼 사용량이 사용자에게 청구될 것입니다.
EOS.IO 컨트랙트는 어플리케이션 상태 정보를 저장할 수 있는 인-메모리(in-memory) 데이터베이스에 접근할 수 있습니다. 저장된 전체 데이터량과 각각의 데이터베이스 정보에 대한 고정된 오버헤드 지수를 더한 양으로 컨트랙트의 사용량을 청구할 것입니다. 앞에서 말한 인-메모리 데이터베이스는 대용량 분산 호스팅/저장소로 사용될 EOS.IO 스토리지 프로토콜과 독립된 별개의 데이터베이스입니다.
우리는 퍼블릭 테스트 네트워크에서 시연되고 있는 기본적인 메쉬(mesh) 네트워크 코드를 구현했습니다. 블록원은 21개의 독립된 서버를 운영하면서 각각의 서버에 프로듀서를 하나씩 초기설정해놓았습니다.
EOS Dawn 3.0은 단일 체인들을 이용한 수평 확장 기능과 안전한 블록체인간 통신을 이용한 무한 확장 기능을 다시 도입할 것입니다. 이 두 가지 기능을 이용하면 블록체인 기술을 이용해서 만들 수 있는 결과물과 블록체인을 이용한 분산된 네트워크가 변할 수 있는 모습에 아무런 제한이 없어질 것입니다.
블록체인 기술의 성배는 두 개의 독립된 블록체인이 어느 한 쪽의 블록체인에 담긴 정보 전체를 검증하지 않고도 서로 안전한 통신을 가능케하는 기능입니다. 이렇게 구현하려면 블록체인 하나는 다른 블록체인의 경량 클라이언트(light-client)로 구현할 수 있으면 됩니다.
경량 클라이언트는 블록 헤더와 머클 증명만 이용해서 트랜잭션을 인증합니다. EOS.IO는 경량 클라이언트 검증 기능을 지원하는 첫 번째 위임 증명 프로토콜이 될 것입니다. 더 중요한 점은, 완전성 증명(proof-of-completeness)을 생성할 수 있는 유일한 프토코톨이 될 것이라는 점입니다. 대기 기간이나 이의 기간 없이 다른 체인으로부터 관련된 과거의 모든 메시지를 순서대로 받아왔다는 점을 증명할 수 있게 될 것이라는 의미입니다.
전통적으로 경량 클라이언트는 블록 헤더 전부를 처리해야 하지만, EOS.IO를 사용하면 경량 클라이언트는 프로듀서가 변경되는 경우 또는 가장 최근의 블록에서 요구하는 새로운 메시지 처리가 필요할 때만 블록 헤더를 처리하면 됩니다. 이런 방식으로 빈번한 자체 통신이 발생하는 체인들 사이에서 일어나는 빈번하지 않은 통신을 효율적으로 처리할 수 있습니다. 최악의 경우, 500 밀리초(ms)마다 서로 통신하는 두 블록체인의 오버헤드는 전달한 메시지의 총 개수와 무관하게 초당 약 2건 정도일 것입니다.
이 모델을 이용하면, 최소 1/3의 프로듀서가 정직하기만 하면 통신 내용은 보장될 것입니다. 게다가, 프로듀서 하나가 배신하는 경우에도 배신자는 (다른 블록체인일) 경량 클라이언트를 잠재적으로 속이는 임의의 메시지에 서명할 것이므로 자동적으로 처벌할 수 있습니다.
마지막으로, 다른 블록체인과 통신에 소요되는 왕복 시간은 각 체인이 비가역 상태에 도달하는 데 필요한 소요 시간(latency)에 좌우됩니다. EOS.IO 기반의 체인은 3초 이하의 시간 내에 다른 EOS.IO 체인에 메시지를 보내서 암호화 방법으로 검증된 응답을 받을 수 있을 것입니다.
이런 수준의 블록체인간 통신과 보안성은 매우 낮은 소요 시간을 만족하면서 체인 사이의 양방향 연결을 만들 수 있습니다. 양방향 연결이 가장 눈에 보이는 예제이겠지만, 이와 동일한 방법을 이용하면 어떠한 비즈니스-비즈니스 사이의 통신을 수행할 수 있습니다.
블록체인간 통신을 이용하면 프라이빗 블록체인이 퍼블릭 블록체인과 안전한 양방향 통신을 맺는 모델이 가능합니다. 이를 이용하면, 데이터를 공개하는 성질을 가지는 일반적인 블록체인에 다소 적합하지 않았던 모든 종류의 블록체인 어플리케이션이 가능해집니다. 예를 들면, 은행 소유자와 은행 이용자를 제외한 다른 모든 사람들에게 엄청나게 비밀이 보장되는 스위스 은행 같은 블록체인을 만들 수도 있습니다.
퍼블릭 테스트 네트워크를 제공하기 위해서, 우리는 개발 경로를 두 개의 병렬적인 작업으로 나누었고 그래서 가독성, 성능, 블록체인간 통신을 구현하기 위한 코드의 많은 부분을 리팩토링할 수 있었습니다. 리팩토링 작업은 eos-noon 브랜치에서 진행되고 있습니다.
지난 번 업데이트를 통해서 다른 컨트랙트가 작동하는 도중에도 개발자들이 동기적인 읽기-접근과 원자성 트랜잭션(atomic transaction)을 쉽게 수행할 수 있도록 공유 메모리 아키텍처에 집중할 것이라는 의도를 내비친 바 있습니다. 이런 접근을 취하다 보니 하이엔드 머신 한 대를 넘어설 수 있는 수평 확장 기능 구현을 결과적으로 놓쳤습니다.
EOS Dawn 3.0을 통해서 최대 65,000개의 별도 리전(region)을 이용해서 머신 여러 대를 이용한 수평 확장 기능을 복원할 것입니다. 모든 리전은 동일한 계정과 동일한 컨트랙트 코드를 공유할 것이지만, 메모리 데이터베이스 사용의 측면에서는 모두 독립되어 있습니다. 리전 하나의 컨트랙트는 이에 대응하는 다른 리전의 컨트랙트(counterpart)와 비동기 트랜잭션을 이용해서 통신해야만 합니다. 이런 아키텍처를 사용하면 블록 프로듀서 하나는 클러스터로 구성할 수도 있습니다.
가장 최근 업데이트에서 우리는 애플, 안드로이드를 비롯한 많은 스마트카드 플랫폼에서 사용하는 것과 동일한 타원 곡선 알고리즘을 지원하겠다는 의도를 발표했습니다. 우리의 eos-noon 브랜치에는 최신 맥북 프로 노트북에 장착된 터치ID(또한 페이스ID)를 이용해서 메시지를 서명하고 검증할 수 있는, 제대로 동작하는 개념증명용 구현체가 이제 포함되어 있습니다. 비슷한 코드로 아이폰 네이티브 어플리케이션으로 역시 구현할 수 있습니다. 이로써 EOS.IO 기반의 모바일 어플리케이션은 지금까지 알려진 가장 안전한 블록체인 지갑에 포함될 것입니다.
게다가, eos-noon 브랜치는 다수의 서명 타입을 지원하는 기능이 추가되었기 때문에 애플 Secure Enclave를 이용해서 트랜잭션을 서명하는 것이 가능함을 의미하고 eos-noon 브랜치에서 이를 검증할 것입니다.
(옮긴이 주: 애플 Secure Enclave를 이용한 데모 코드가 깃헙에 올라와 있습니다. EOSIO Apple Secure Enclave 데모를 참조하세요.)
eos-noon 브랜치에서 우리는 기반이 되는 DPOS 프레임워크가 500 밀리초 블록 (1초 마다 블록 2개씩 생성) 기능을 지원하게끔 많은 수정을 가했습니다. 이 변화를 통해서 분산 어플리케이션의 응답성을 극적으로 높힐 것입니다. 이런 모습을 달성하기 위해서 블록 스케줄링이 일어나는 방법에 중요한 변화가 있었습니다.
프로듀서 하나는 다음 프로듀서에게 순서를 넘기기 전 블록 12개를 연속으로 생성할 것입니다. 이런 방법으로 블록 생산의 측면에서 가장 큰 병목인 프로듀서-프로듀서 순서 넘김 문제를 해결했습니다. 새로운 구조를 이용하면 순서 넘김이 일어나는 순간 예상치 못한 지연이 발생해도 몇 개의 블록 정도만 놓칠 것입니다. 그러나 순서가 넘어가는 사이에 매우 빠른 승인이 이루어져야 합니다. 우리는 다양한 순서 넘김 시간 설정을 이용해서 실험할 것입니다. 순서 넘김 시간이 길어지면 정상적인 작동 환경에서는 누락되는 블록이 더 적어질 것입니다. 그러나 순서 넘김 시간이 길어진 상황애서 노드 하나가 다운되면 장애가 일어날 것입니다. 500 밀리초마다 블록을 만들고 블록을 12개 만든 후 순서를 넘기는 경우라면, Steem과 BitShares에서 프로듀서 하나가 블록 하나를 누락하는 "다운 타임"보다 심하진 않습니다. 이런 상황이 발생하면 첫 번째 승인을 얻는 데 6초가 소요될 수 있습니다.
블록체인간 통신을 가능하게 하려면 활성 블록 프로듀서의 집합이 변화하는 모든 블록을 경량 클라이언트가 추적해야 합니다. "대기 프로듀서 목록(runner up producer list)"가 있어서 새로운 프로듀서가 매분마다 추가되거나 삭제되고, 그래서 경량 클라이언트는 더 많이는 아니더라도 매분마다 최소한 하나의 블럭 헤더를 처리해야만 합니다. 프로듀서 집합 변화의 빈도를 줄이기 위해서 우리는 블록 스케줄링 정보에 오직 상위 21개의 프로듀서 목록만 담는 것으로 변경했습니다. 우리는 대기 프로듀서에 대해서 일종의 대기 보상을 주는 방식을 고려하고 있습니다만, 대기 프로듀서들은 실제로 블럭 생성 작업을 수행하지 않을 것입니다.
모든 블록 프로듀서는 모든 블럭에 서명할 것이고, 블럭 하나는 2/3 이상의 프로듀서가 서명하는 대로 비가역 상태로 표시될 것입니다. 프로듀서는 블록 높이당 하나의 블록 헤더에만 서명할 수 있습니다. 이 말은, 포크가 발생하는 경우 프로듀서는 동일한 높이에 도달한 포크 양쪽 모두의 블록에 서명할 수 없다는 뜻입니다. 만약 그런 서명이 있다면 이것은 어느 프로듀서가 부정 행위를 했다는 암호적 증거이며, 프로듀서의 지위를 자동으로 잃게 만든다거나 잠재적으로 계약 상실에 이르게 한다거나 잠재적으로 중재에 따른 손해에 대한 잭임을 지도록 하는 등 여러 가지 방법으로 처리할 수 있습니다.
다음 블록을 만들기 전에 2/3 이상의 서명을 모으는 다른 프로토콜과 달리, EOS DPOS는 서명을 모으는 동안 낙관적 파이프라이닝(optimistic pipelining) 방식으로 작동하기 때문에, 블록체인을 "계류 상태(pending state)"로 계속 진행시킬 수 있도록 합니다. 블록체인 바깥에서 이와 같은 추가적인 서명이 일어나면, Steem과 BitShares와 같은 기존의 DPOS 규칙 아래에서는 블록이 비가역 상태에 도달한 뒤에야 검증이 완료된 블록을 정리(prune)할 수 있습니다.
이 모델을 이용하면, 비잔틴(배반자) 노드가 배반했다는 암호화 증거를 남기지 않고서는 어떤 블록도 2/3 이상의 서명을 받을 수 없기 때문에, 비잔틴 장애 내성을 얻을 수 있습니다.
프로듀서 순서가 넘어갈 때 누락되는 블록의 수를 최소화하기 위해서, 이어지는 프로듀서 사이의 지연 시간을 최소화하는 것이 바람직합니다. 뉴욕에 있는 프로듀서가 중국에 있는 프로듀서의 다음 순서라고 가정하면, 정상적인 경우 (블록 생성 간격의 50%인) 250 밀리초가 걸릴 지도 모르고 네트워크 정체가 있으면 잠재적으로 훨씬 더 긴 시간이 걸리지도 모릅니다. 반면에 뉴욕과 텍사스에 프로듀서가 있다면 (블록 생성 간격의 10%인) 50 밀리초 정도의 지연 시간만 걸릴 수도 있습니다. 즉, 뉴욕에서 중국으로 순서가 넘어가는 경우에 비해서 뉴욕에서 텍사스로 순서가 넘어가는 경우에 누락 블록이 발생할 수 있는 확률이 훨씬 더 줄어들 수 있습니다.
뉴욕에서 텍사스로, 캘리포니아로, 하와이로, 일본으로, 중국으로, 인도로, 이스라엘로, 이탈리아로, 영국으로, 아이슬란드로, 그리고 다시 뉴욕으로 오는 식으로 블록 생성 스케줄을 조정한다면, 50 밀리초에서 100 밀리초 이상의 지연 시간이 있는 순서 넘김은 절대로 발생하지 않습니다. 그러나 만약 랜덤하게 순서를 정한다면, 평균적인 순서 넘김 지연 시간은 훨씬 커질 것입니다.
프로듀서 셔플링은 프로듀서 하나가 후속 프로듀서를 부당하게 괴롭힐 수 있는 잠재적인 시나리오를 최소화하기 위해서 도입했습니다. 프로듀서가 잠재적으로 악의적일 수 있다고 추정되는 세계에는 이런 리스크가 존재했었습니다. 그러나 면밀히 심사받고 대중에게 알려지고 고품질의 데이터센터를 완비한 프로듀서들이 존재하는 세계에서는 이런 리스크가 타당하지 않습니다. 헌법이 존재하고, 프로듀서 하나가 의도적으로 이웃 프로듀서에 피해를 입히는 경우 분쟁을 해결하는 절차를 준수하는 행동 기대 수준이 있습니다.
평균 지연 시간을 최소화하고 인터넷 네트워크 정체로 인한 총 누락 블록 수를 최소화할 수 있도록, EOS에서 프로듀서는 블록 생성 교대 순서를 투표로 정할 것입니다.
EOS Dawn 2.0에는 알려진 몇 가지 문제점들이 있고 출시 초기 단계에서는 불안정성이 클 것으로 예상됩니다. 이번 출시의 목적은 기본적 능력을 시연하는 데 있고, 우리 팀은 다음 6개월간 버그를 없애고 안정성과 성능을 개선해나갈 것입니다.
테스트 네트워크의 안정성을 뒷받침하기 위해서, 우리는 프로듀서 투표 기능을 꺼두었습니다.
우리는 앞으로 시장에 나온 가장 강건하고 가장 높은 성능을 보이고 가장 분산화된 플랫폼이 될 소프트웨어의 알파 버전인 EOS Dawn 2.0을 작성하고 출시하기 위해 전세계에 걸쳐 24시간 내내 일하는 개발팀에게 감사의 말씀을 전하고 싶습니다. 우리는 우리가 발표한 로드맵에 따라서 작업을 실행하고 있고 원래 계획했던 이상의 기능과 능력을 제공하고 있습니다. 우리는 2018년을 고대하며 EOS 토큰 배포가 완결되는 시점까지 모든 기능 구현을 완료하고 버그를 해결할 것이라고 확신합니다.
블록원(block.one)은 소프트웨어 기업이며 EOS.IO 소프트웨어를 무료 오픈소스 소프트웨어로 제작합니다. 이 소프트웨어는 이 소프트웨어를 도입하는 사용자가 블록체인 또는 위에서 설명한 기능을 갖춘 분산 어플리케이션을 시작할 수 있도록 합니다. 블록원은 EOS.IO 소프트웨어를 기반으로 하는 퍼블륵 블록체인을 론칭하지 않습니다. 제 3자나 커뮤니티나 자신들이 적합하다고 보는 위에서 설명한 기능과/또는 서비스를 제공하여 블록 프로듀서가 되길 원하는 주체들의 단독 책임일 것입니다. 블록원은 임의의 주체가 그러한 기능을 구현하거나 그러한 서비스를 제공하거나 EOS.IO 소프트웨어가 어떤 방식으로든 채택되고 구현된다는 것을 보증하지 않습니다.
역사적 사실에 대한 진술 이외에, 블록원의 비즈니스 전략, 계획, 전망, 개발 및 목표에 관한 이 문서의 모든 진술은 미래 예측 진술입니다. 이 진술은 예측일 뿐이며 미래의 사건에 대한 블록원의 현재의 믿음과 기대치를 반영하고 가정에 근거하며 언제든지 위험, 불확실성 및 변경의 영향을 받습니다. 우리는 급변하는 환경에서 사업을 운영합니다. 새로운 위험이 수시로 발생합니다. 이러한 위험과 불확실성을 감안할 때 이러한 미래 예측 진술에 의존하지 않도록 주의해야 합니다. 실제 결과, 실적 또는 이벤트는 미래 예측 진술에 포함된 내용과 실질적으로 다를 수 있습니다. 실제 결과, 실적 또는 이벤트가 미래 예측 진술과 실질적으로 다른 원인이 될 수 있는 요인에는 시장 변동성, 자본, 재원 및 인력의 지속적인 가용성; 제품 수용; 어떤 새로운 제품이나 기술의 상업적 성공; 경쟁; 정부 규제 및 법률; 그리고 일반적인 경제, 시장 또는 사업 조건이 포함되며 이에 제한되지 않습니다. 블록원이 작성한 모든 미래 예측 진술은 진술이 이뤄진 날짜에 대해서만 말하고 블록원은 새로운 정보, 후속 사건 또는 기타 사건의 결과이건 간에 미래 예측 진술을 업데이트하거나 변경할 의무가 없으며 분명히 부인할 의무가 없습니다.
- 원문 : https://steemit.com/eos/@eosio/eos-io-dawn-2-0-released-and-development-update
- 원문 작성 시점 : 한국표준시 2017년 12월 5일