block.one 팀이 유지할 공개 테스트 네트워크와 함께 EOS.IO Dawn 2.0이 공개되었습니다. 이번 배포는 로드맵 상 2017년 가을까지 목표한 기능들과 원래 2017년 12월 21일까지를 목표로 했던 기능들의 대부분을 알파 구현 수준으로 제공합니다. 로드맵에서 밝힌대로 "2 단계 - 최소 사용가능한 테스트 네트워크" 는 2017년 가을에 아래의 내용들을 보여줄 예정이었습니다.
- P2P 네트워크 코드 (P2P Network Code)
- WASM 보완 및 CPU 샌드박싱 (Wasm Sanitation & CPU Sandboxing)
- 리소스 사용 추적 / 비율 제한 (Resource Usage Tracking / Rate Limiting)
- 제네시스 테스트 (Genesis Import Testing)
- 블록체인 간 통신 (Inter-Blockchain Communication)
현재 이 기능들의 초기구현을 마쳤습니다만, 병렬적인 개발 과정으로 인해 블록체인 간 커뮤니케이션은 별도의 브랜치에 존재하고 최초 테스트 네트워크에서는 사용되지 않을 예정입니다.
역주: 브랜치는 개발자용 저장소(Repository)에서 사용하는 개념으로, 동일소스 코드 기반으로 두 개 이상의 서로 다른 개발을 시작할 때 서로의 개발이 영향을 주지 않게 하기 위해 만들어둔 복사본이라고 생각하시면 됩니다.
EOS.IO Dawn 2.0 의 퍼포먼스 테스트를 해보고 싶은 사람들은 Github 저장소에서 프라이빗 네트워크를 구동하고 운영해볼 수 있는 필요한 모든 블록체인과 네트워크 코드를 찾을 수 있습니다. 내부 테스트에서는 평균적인 하드웨어를 이용할 때 단일 쓰레드에서 수천 TPS와 1초의 블록주기를 유지할 수 있었습니다. 그렇긴 하지만, 아직 대응법이 마련되지 않은 공격 방법(Attack vector)들이 있습니다. 예를들어, 새로운 컨트랙트들을 처음 컴파일하는 과정에는 34ms가 소요될 수 있고, 이를 악용하면 네트워크가 30 TPS 이상의 속도를 내고 있을 때 네트워크 이상을 초래할 수 있습니다.
이 이슈에 대한 해결책은 컨트랙트 코드 업데이트의 빈도를 제한하고, 새로운 코드가 업데이트 되었을 때 그 코드를 통해 트랜잭션을 실행할 수 있기까지 지연시간을 설정하는 것입니다. 이 지연시간은 모든 블록생성자가 웹어셈블리를 통해 최적화된 x86 명령을 컴파일하고 캐싱을 할 수 있게 하기 위한 대략 60초 정도가 될 것입니다.
이러한 강력한 공격 방법들 때문에 성능 테스트는 프라이빗 테스트 네트워크에서 해야 하며, 기능 테스트는 가동시간과 접근가능성을 보장하기 위해 인공적으로 30 TPS로 제한한 퍼블릭 테스트 네트워크에서 수행할 수 있습니다.
다음 6개월간 지속적으로 테스트와 디버깅을 진행하여 네트워크의 안정성과 성능을 높여 나갈 것입니다.
Dawn 2.0의 새로운 기능들
제네시스 테스트
스냅샷 툴을 구현하여 이더리움 네트워크 상에서의 EOS ERC-20 배분에 기반한 초기 상태를 가져올 수 있게합니다. 테스트 네트워크는 EOS 공개키를 올바르게 등록한 잔고만을 포함합니다. 대략 20%정도의 ERC-20 토큰이 EOS 공개키에 올바르게 등록이 되었습니다. 스냅샷 툴은 등록되지 않은 ERC-20 토큰 보유 이더리움 계정에 대해서 사인된 이더리움 트랜잭션을 통해 public key를 복구할 수 있는 대비책을 구현합니다. 이를 통해 전체 EOS ERC-20 토큰의 99%가 커버되지만, 사용자의 EOS.IO 지갑에 이더리움 개인키를 넣어야합니다.
보안상의 이유로, 본 테스트 네트워크에서는 사용자에게 이더리움 개인키를 넣도록 요구하지 않을 것입니다. 만약에 당신의 EOS 개인키가 테스트 도중 유출될 위험에 처한다면, 당신은 언제든 새로운 키를 이더리움 네트워크에 등록할 수 있습니다.
토큰 수도꼭지
우리는 또한 "수도꼭지(faucet)" 기능을 구현하여, 토큰을 가지고 있지 않거나 아직 유효한 EOS 퍼블릭 키를 등록하지 않은 사람도 네트워크를 테스트해볼 수 있게 하였습니다.
자원 사용 및 비율 제한
우리는 기본적인 비율 제한과 자원 사용 추적을 구현해왔습니다. 이것는 대역폭과 데이터베이스 저장소, 그리고 연산 사용량을 추적합니다. 현재 우리의 비율 제한 알고리즘에는 몇개의 알려진 버그들이 존재합니다만, 어플리케이션 개발과 테스트를 방해할만한 것은 없습니다.
많은 사람들이 비율 제한이 어떻게 동작하는지, 누가 비용을 내는지, 어떻게 그들의 토큰을 임대하고 수익을 낼 수 있는 지에 대해서 질문해 왔다는것을 알고 있습니다.
대역폭
모든 트랜잭션은 블록생성자들이 설정한 최대 네트워크 대역폭의 일부를 소모합니다. 트랜잭션에 권한을 부여하는 모든 계정들은 트랜잭션의 사이즈에 따라 가산된 3일 평균 대역폭을 가집니다. 대역폭은 권한 부여 계정 (컨트랙트가 아니라)으로 하여금 어플리케이션 공급자에 의해 임대되거나 예치된 토큰들을 보유하도록 요구합니다.
계산 대역폭
모든 트랜잭션은 어느정도 연산자원을 소모합니다. 연산은 병렬적으로 실행될 수 있기 때문에, 각 차로의 혼잡정도가 다른 다차로 고속도로라고 볼 수 있습니다. 각 스코프(차로)는 그 스스로의 독립적인 비율 제한을 가지고, 사용자에게는 동시 스코프 (차로)들의 숫자와 가장 혼잡한 스코프의 비율 제한에 대해 O(S^2) 만큼의 비용이 청구될 것입니다.
데이터베이스 저장소
EOS.IO 컨트랙트는 어플리케이션 상태를 저장할 수 있는 메모리 내 데이터베이스에 접근할 수 있습니다. 요금은 저장한 총 데이터에 각 데이터베이스 입력의 상수 오버헤드 펙터를 더한만큼 해당 컨트랙트에 청구합니다. 이 메모리 내 데이터베이스는 탈중앙화 일괄 호스팅과 저장소인 EOS.IO 저장소 프로토콜과는 단독으로 분리되어있습니다.
P2P 네트워크 코드
우리는 메시 네트워크(Mesh network) 코드의 기본 구현을 마쳤고, 이는 퍼블릭 테스트 네트워크에서 시연되고 있습니다. Block.one은 21개의 독립적인 서버를 운영하고 있으며, 각각은 초기 블록생성자로 설정되어 있습니다.
EOS Dawn 3.0
EOS Dawn 3.0은 싱글 체인의 수평확장과 안전한 블록체인 간 통신(inter-blockchain communication)을 통한 무한한 확장을 새롭게 선보일 것입니다. 이 두가지 특징으로 인해 블록체인 기술위에 어떤 것이든 구현할 수 있으며, 블록체인 네트워크도 제한없이 얼마든지 탈중앙화 될수 있을 것입니다.
무한의 확장성과 무한의 탈중앙화
블록체인 기술의 성배는 두 독립적인 블록체인이 서로의 모든 것을 검증하지 않으면서도 안전하게 통신하게 할수 있는 것입니다. 이는 하나의 블록체인을 상대 블록체인의 경량 클라이언트(Light-client)로 만드는 것을 요구합니다.
경량 클라이언트는 블록헤더와 머클 증명 만을 이용해서 트랜잭션을 증명합니다. EOS.IO 는 경량 클라이언트 검증을 지원하는 최초의 지분증명(Proof-of-stake) 프로토콜이 될 것입니다. 더 중요한 것은 이것이 유일하게 완결성 증명(Proof-of-completeness)를 생성할 수 있다는 것입니다. 이는 당신이 대기나 검증 기간 없이 다른 블록체인에서 모든 관련된 선행 메시지를 순서대로 받았다는 것을 검증하는 것이 가능하다는 뜻입니다.
전통적으로 경량 클라이언트는 모든 블록 헤더를 처리해야하는 반면에, EOS.IO는 생성자가 바뀌거나 새로운 메시지가 더 최신의 블록에서 요구 될때만 경량 클라이언트가 블록헤더를 처리하도록 합니다. 이를 통해 블록체인들이 간에 빈번한 통신 뿐 아니라 효율적이고 드문 통신도 가능하게 합니다. 최악의 상황에 매 500ms마다 두 블록체인이 통신 하는 오버헤드는 보내진 모든 메시지의 숫자를 넘어서 대략 2 TPS가 될 것입니다.
이 모델에서는, 최소 ⅓ 의 블록생성자가 정직하다면 통신 안전이 보장됩니다. 나아가 한 생성자가 부패하다고 하여도 그들이 경량 클라이언트(다시말해 외부 블록체인)를 변질시킬 수 있는 어떤 메시지에 사인을 한다면 자동으로 처벌될 수 있습니다.
마지막으로, 다른 블록체인으로의 통신 왕복시간은 각 체인의 비가역성을 확보하는데에 걸리는 지연시간에 달려있습니다. EOS.IO 기반 체인은 다른 EOS.IO 체인에 메시지를 보내고 암호학적으로 검증된 응답을 받는데 3초이내면 됩니다.
이 정도 수준의 블록체인 간 통신과 보안은 매우 낮은 지연시간으로 체인들 사이의 양방향 결합(Two-way pegs) 생성을 가능케 합니다. 양방향 결합이 가장 명백한 예시라면, 어떠한 비즈니스 간 통신도 같은 방식으로 수행될 수 있습니다.
퍼블릭 / 프라이빗 통신
블록체인 간 통신 기술을 통해 프라이빗 블록체인이 퍼블릭블록체인과 안전한 양방향 통신을 하는 것이 가능합니다. 이는 전통적인 블록체인이 가진 공개적 속성에 적합치 않은 모든 종류의 블록체인 어플리케이션을 가능케 합니다. 예를들어 누군가 스위스 은행 블록체인을 만들어 은행 소유자와 회원들을 제외한 모두에게 완벽히 비밀보장이 되게 할수도 있습니다.
개발 진행
퍼블릭 공개 네트워크를 공개하기 위해서, 우리는 우리의 개발을 두 개의 병렬적인 경로로 나누면서 가독성, 성능, 블록체인 간 통신에 대한 상당량의 코드를 리팩토링(refactoring)할 수 있게 했습니다. 이 리팩토링 작업은 eos-noon 브랜치에서 일어나고 있습니다.
역주: 리팩토링이란 이미 동작하는 코드를 더 나은 구조로 근본적으로 개선하는 작업을 뜻합니다. 코어코드의 리팩토링일 수록 이에 종속되는 기능들이 많아 다른 모든 후속 작업들이 대기상태가 될 수 있습니다. 이를 막기 위해 보통 리팩토링은 별도 브랜치에서 진행하고 나중에 병합하는 형태로 진행합니다. 지금 공개되는 EOS의 버전이 Dawn(새벽)인 것을 감안 할때 eos-noon(정오)는 좀 더 먼 미래에 적용될 코드라고 볼 수 있습니다.
과거 업데이트에서 우리는 공유된 메모리 아키텍처에 집중하여 개발자들이 쉽게 동기화된 읽기 접근을 수행하고 다른 컨트랙트와 아토믹 트랜잭션을 할 수 있게 하려고 한다고 밝혔습니다. 이러한 접근의 결과는 단일 고성능 기기를 넘어선 수평적 확장에서의 손실이었습니다.
EOS Dawn 3.0에서는 우리는 65,000개의 서로 다른 구역(region)을 사용하여 다기기 수평 확장 능력을 복구할 것입니다. 모든 구역은 같은 계정과 컨트랙트 코드를 공유하지만, 메모리 데이터베이스에 독립적으로 가지고 있을 것 입니다. 한 구역에서의 컨트랙트는 다른 구역의 상대방에 커뮤니케이션 할때는 비동기 트랜잭션을 사용해야만 합니다. 이 구조에서는 개별 블록 생성자가 마치 하나의 클러스터처럼 구현될 수 있습니다.
애플 보안 구역(Secure Enclave)와의 통합 작업
지난 번에 우리는 애플, 안드로이드, 많은 스마트 카드들이 사용하는 동일한 타원곡선 암호화 방식을 지원할 계획을 공개했었습니다. 지금 eos-noon 브랜치는 최신 맥북 프로의 Touch ID (그리고 Face ID)를 이용해서 메시지를 사인하고 검증하는 완전히 동작하는 증명수준의 결과물(Proof-of-concept)을 포함하고 있습니다. 유사한 코드가 아이폰 어플리케이션에서도 동작합니다. 이는 EOS.IO 기반의 모바일 어플리케이션들은 가장 안전한 블록체인 월렛들에 이름을 올리게 될 것이라는 것을 뜻합니다.
역주: 제품개발프로세스에서 Proof-of-concept, POC는 컨셉을 증명할 수 있는 수준의 최소한의 요구사항을 만족시킨 일종의 프로토타입을 의미합니다. 완성된 제품이 되기 위해서는 훨씬 더 많은 구현이 필요할 수 있지만, POC가 제작되었다는 말은 적어도 시간과 자원만 들이면 제품 완성이 가능하다는 것을 확인했다는 뜻입니다.
500ms 의 블록 확인
eos-noon 브랜치에서는 500ms 블록생성주기(매초 2개 블록)를 지원하기 위해 근본이 되는 DPOS 프레임워크 수 많은 변화를 적용하였습니다. 이 변화는 탈중앙화 어플리케이션의 반응성을 극적으로 높일 것입니다. 이를 달성하기 위해 우리는 블록 스케줄링이 일어나는 방식에 몇몇 변화를 도입했습니다.
동일한 생성자가 이제는 다음 생성자한테 인수인계를 할때까지 12개의 블록을 연달아 생성합니다. 이는 생성자-생성자간 인수인계라는 블록생성에서의 단일 최대 병목(bottleneck)을 해결합니다. 새로운 구조 아래서는 인수인계가 있을 때마다 몇개 블록이 놓쳐지는 예상치못한 지연시간이 존재할수는 있습니다만, 인수인계 사이에서는 매우 빠른 확인이 일어날 것입니다. 우리는 여러가지 인수인계 주기를 실험해볼 것입니다. 일반적인 운영상황에서는 인수인계 주기가 길수록 놓쳐지는 블록이 줄어들지만, 만약에 한개의 노드가 다운될 때 전체 블록체인이 다운되는 시간도 길어질 것입니다. 500ms의 블록생성주기에 매 12 블록마다 인수인계를 하면, "다운 시간"이 스팀(Steem)이나 비트쉐어(BitShares)에서 개별 블록생성자가 개별블록을 놓칠 때보다 더 나쁘지는 않습니다. 이런 상황이 벌어지면 첫 확인에 6초가 걸릴 수 있습니다.
Removing Runner Up Producers
블록체인 간 통신은 경량 클라이언트로 하여금 활성 생성자 세트가 바뀔 때 모든 블록을 추적하도록 요구합니다. "대기 생성자 리스트"는 매 분마다 새로운 생성자가 하나씩 추가되거나 저게되도록 하고, 이는 경량 클라이언트로 하여금 매 분 하나의 블록헤더 또는 그 이상을 처리하도록 강제합니다. 생성자 세트 변화의 빈도를 줄이기 위해서 블록 스케줄링이 상위 21개 생성자만 포함시키도록 변경하였습니다. 대기 생성자를 위해 어떤 종류의 대기 보상을 지금하는 방안을 고려하고 있지만, 블록을 생성하는 일을 실제로 맡게되지는 않을 것입니다.
역주: 백서에 보면 상세하게 기술되어있지는 않지만 20개의 생성자는 상위에서 뽑고 나머지 1개는 약간의 랜덤성을 가미하여 대기자 리스트에서 가져온다는 내용이 있습니다. 이것을 하지 않겠다는 뜻으로 해석이 되며, 그러나 여전히 대기자가 필요한 것은 서버가 다운되거나 이상행동을 하는 노드가 생겼을 때 이 노드를 제거하고 다른 노드로 바로 채우기 위해서라고 생각합니다. 정상적인 상황에서 블록생성에 참여는 못할테니, 별도의 보상은 필요하겠지요.
1초의 비가역성
모든 블록생성자들이 모든 블록을 사인할 것이고, 이를 통해 ⅔ 이상의 생성자들이 사인을 하기만 하면 단일 블록이 되돌려지지 않는 것으로 표시되게 할 것입니다. 생성자들은 블록 높이마다 1개의 블록헤더를 사인하도록 허락됩니다. 이는 포크가 있을 때 동일 높이에 있는 두개의 포크에서 두 블록을 모두 다 사인하지는 못한다는 뜻입니다. 만약 그런 사인을 한다면 생성자의 잘못된 행동이 암호학적인 증거로 남게될 것이며, 이 경우 생성자 지위의 자동 상실, 잠재적 채권 상실, 그리고 중재를 통해서 피해에 대한 잠재적 책임 부과을 포함한 여러가지 조치가 취해질 것입니다.
⅔ 이상의 사인을 다음블록이 생성하기 전에 모으는 다른 프로토콜과는 다르게, EOS DPOS는 낙관적인 파이프라이닝을 통해서 사인들이 모이는 "보류 상태(Pending state)"에서도 블록체인이 생성을 계속 진행하도록 허용합니다. 이런 추가적인 사인들은 블록체인 밖에서 일어나며, 스팀이나 비트쉐어의 전통적인 DPOS 규칙에 따라 블록이 비가역적이 되면 제거될 수 있습니다.
이 모델 아래서는 비잔틴노드의 암호학적 증거 없이 어떤 블록이 ⅔ 이상의 사인을 받는 것이 불가능하기 때문에, 비잔틴 오류 허용을 달성하는것이 가능합니다.
생성자 일정 뒤섞기 제거
생성자 인수인계 시 블록 손실 갯수를 최소화하기 위해서 연속된 생성자간 지연시간을 최소화할 필요가 있습니다. 만약 뉴욕의 한 생성자가 중국의 다른 생성자를 뒤 따르도록 계획되어 있다면 일반적인 상황에서 250ms(블록주기의 50%)이 소요되며, 네트워크가 혼잡한 상화이라면 훨씬 더 걸릴 수도 있습니다. 반면에 뉴욕의 생성자와 텍사스의 생성자라면 50ms의 지연시간(블록주기의 10%)이면 될 것입니다. 이는 뉴욕에서 중국으로의 인수인계보다 뉴욕에서 텍사스로의 인수인계가 현저하게 블록 손실의 확률이 낮다는 것을 의미합니다.
만약에 우리가 블록생성을 뉴욕에서 텍사스로, 캘리포니아로, 하와이로, 일본으로, 중국으로, 인도로, 이스라엘로, 이탈리아로, 영국으로, 아이스랜드로, 그리도 다시 뉴욕으로 순환하여 한다고 할때 인수인계가 50ms에서 100ms 를 넘는 일은 없습니다. 하지만 순서가 임의로 정해진다면 평균 인수인계에 걸리는 시간은 현저하게 높아질 것입니다.
생성자 뒤섞기는 한 생성자가 뒤따르는 다른 생성자를 지정할 가능성을 최소화하기위해 도입되었습니다. 이 위험성은 생성자가 잠재적으로 악의적일수 있다면 말이되지만, 실제로는 생성자들이 고도로 검증되고, 공개되어있을 것이며 고성능 데이터센터를 운영할 것이기 때문에 말이 되지 않습니다. 한 생성자가 일부러 다른 생성자에게 피해를 입히는 상황에 대해 헌법과, 기대되는 행동수준 그리고 분쟁을 해결하기 위한 프로세스가 있습니다.
EOS 에서는 생성자들이 평균 지연시간과 네트워크 혼잡으로 인한 총 불록 손실을 최소화하는 방향으로 생성 순서에 보팅을 할 것입니다.
알려진 이슈
EOS Dawn 2.0에는 알려진 이슈들이 많이 있고, 이 초기 배포에서는 큰 불안정성이 존재할 수도 있습니다. 이번 배포의 목적은 기본적인 가용성을 시연하는 것이며 우리 팀은 앞으로의 6개월동안 버그를 제거해나가고 안정성과 성능을 높여나갈 것입니다.
테스트 네트워크의 안정성을 유지하기 위해서, 생성자 보팅은 막아두었습니다.
결론
EOS Dawn 2.0을 배포하기 위해 세계 각지에서 밤낮으로 일해온 개발팀에게 감사를 전하고 싶습니다. EOS Dawn 2.0은 가장 튼튼하고, 고성능에, 현존하는 가장 탈중앙화된 플랫폼의 알파버전입니다. 우리는 공개된 로드맵에 맞추어 실행하나가고 있고, 원래 계획된 것 보다 더 많은 기능과 가능성을 보여줄 것입니다. 2018년이 기대되고, EOS 토큰 분배가 끝날때에는 모든 기능이 완성되고 버그들이 해결될 것임을 자신합니다.
면책사항
block.one은 소프트웨어 회사로서 무료 오픈소스인 EOS.IO 소프트웨어를 제작하고 있습니다. 이 소프트웨어는 이를 구동하는 이들로 하여금 위에서 묘사된 기능들을 가지는 블록체인이나 탈중앙화 애플리케이션을 출시하게 할수 있습니다. block.one은 EOS.IO 소프트웨어 기반의 어떠한 퍼블릭 블록체인도 출시하지 않을 것입니다. 위에 나온 것과 같은 기능을 도입하고 서비스를 제공하는 것은 온전히 서드파티나 커뮤니티 그리고 블록생성자가 되고 싶어하는 이들이 적합하다고 여길 때이며, 그들의 몫입니다. block.one은 누군가 이런 기능들을 도입하고 이런 서비스를 제공할 것을 보장하지 않으며, EOS.IO 소프트웨어가 어떤식으로든 도입되어 전개될 것도 보장하지 않습니다.
역사적 사실에 대한 서술을 제외하고, block.one의 사업 전략, 계획, 전망, 개발과 목표를 포함한 모든 진술은 기대 진술 (Forward looking statement)입니다. 이런 진술들은 단지 예측일 뿐이며 block.one의 미래 사건에 대한 현재의 믿음과 기대를 반영합니다. 또한, 가정들을 기반으로 하고 있으며, 언제든 위험요소와 불확실성 그리고 변화에 쉽게 영향을 받을 수 있습니다. 우리는 급격히 변화하는 환경 속에 프로젝트를 운영하고 있습니다. 새로운 위험요소는 시시각각 떠오릅니다. 이러한 위험요소와 불확실성을 고려할 때, 기대진술을 믿지 않도록 주의할 것을 당부드립니다. 실제 결과나 성과, 사건은 기대 진술에서 언급된 것과 실질적으로 다를 수도 있습니다. 실제 결과나 성과, 사건이 기대진술로 부터 실질적으로 달라질 수 있게 하는 요인에는 제한 없이 다음과 같은 요소들이 포함될 수 있습니다.
시장 변동성; 자본, 금융, 인력의 지속적인 가용성; 제품 수용도; 어떠한 새로운 제품이나 기술의 상업적 성공; 경쟁; 정부의 규제와 법; 일반적인 경제, 시장 그리고 사업의 조건들.
block.one에 의한 어떠한 기대 진술이든 그것이 만들어진 그 날짜에 대해서만 말하고 있으며, block.one은 새로운 정보나 이후의 사건, 다른 것들의 결과로 그의 기대진술을 갱신하거나 고칠 어떠한 의무도 없으며, 그에 대한 어떠한 책임도 명시적으로 부인합니다.
@eosio의 EOS.IO DAWN 2.0 Released & Development Update 를 번역한 글입니다. 검수에는 @clayop님께서 도움을 주셨습니다.
EOS 현재 공개 테스트넷이 담고있는 내용과, 앞으로 담기게 될 내용을 꽤나 자세하게 다루고 있습니다.
글이 상당히 길어서 번역자도 힘들었고 독자들도 힘드실 것이라고 생각합니다만, 너무나도 새롭고 중요한 내용이 많기 때문에 기존 백서만큼이나 여러 번 정독할만한 가치가 있을 것입니다.
바뀐 내용이 정말 많아서 초보 EOS 시리즈 구성에도 변화가 다소 있을 수 있겠습니다. 이번 주말에 또 초보 EOS로 찾아뵙겠습니다.