[번역] EOS.IO 기술 백서 (EOS.IO Technical White Paper)

시간을 아끼려 그다지 중요하지 않은 부분은 생략하였습니다.
배경 지식이 미천하여 번역이 매끄럽지 못한 점 양해 바랍니다.

---

EOS.IO Technical White Paper
EOS.IO 기술 백서

초록 抄錄 :
EOS.IO 소프트웨어는 분산된 애플리케이션의 수직적, 수평적 확산이 가능하도록 설계된 새로운 블록체인 제작 기술을 선보인다. 이 기술은 그 위에 애플리케이션을 구축할 수 있는, (일종의) 운영체제와 비슷한 구성체를 만들어냄으로서 가능해졌다. 이 소프트웨어는 수백 개의 CPU 코어와 클러스터에 계정, 인증, 데이터베이스, 비동기 통신, 그리고 애플리케이션 순서 계획 작성 기능을 제공해 준다. 그 결과, 초당 수백만 건의 거래로 확장되고, 사용자 수수료가 없으며, 분산된 애플리케이션의 신속하고 쉬운 전개가 가능한 블록체인 제작기술이 되었다.

[Background]
[배경]

블록체인 기술은 2008년 비트코인 출범에 따라 도입되었고, 그 이후 기업가들과 개발자들이 이 기술을 일반화하여 단일 블록체인 플랫폼에서 다양한 애플리케이션을 지원해보려고 시도해왔다.

많은 블록체인 플랫폼이 기능적으로 분산된 애플리케이션을 지원해보려고 노력하는 사이에, BitShares decentralized exchange(분산 교환) (2014)와 Steem social media platform(소셜 미디어 플랫폼) (2016)과 같은 애플리케이션 특화 블록체인이 널리 사용되게 되었고, 일일 활성 사용자가 수만 명에 이르게 되었다. 이러한 성과를 거두게 된 원인은, 거래 횟수를 초당 수 천 건으로 증가시켰고, 지연 시간은 1.5초로 감소시켰으며, 수수료를 없애고, 기존의 중앙집중식 서비스에 의해 제공되는 것과 유사한 사용자 경험을 제공한 데에 있다.

기존의 블록체인 플랫폼은 비싼 수수료와 제한적인 계산 능력이 부담이어서, 블록체인이 광범위하게 도입되는 것을 방해하였다.

[Requirements for Blockchain Applications]
[블록체인 애플리케이션의 요건]

폭넓게 사용이 되려면, 블록체인 애플리케이션은 다음의 요건을 충족시키기에 충분한 유연성이 있는 플랫폼이 필요하다.

[Support Millions of Users]
[수백만 명의 사용자 지원]

Ebay, Uber, AirBnB, 그리고 Facebook과 같은 혼란스러운 비즈니스에는 수천만 명의 일일 활성 사용자를 관리할 수 있는 블록체인 기술이 필요하다. 어떤 경우에는, 사용자의 수가 최소한에 도달하지 않으면 애플리케이션이 작동하지 않는 경우가 있다. 어쨌든 엄청나게 많은 사용자를 관리할 수 있는 플랫폼이 무엇보다 중요하다.

[Free Usage]
[무료 사용]

애플리케이션 개발자는 사용자에게 무료 서비스를 제공할 수 있을 정도의 유연성이 필요하다. 사용자는 플랫폼을 사용한다든지 서비스를 받기 위해 돈을 지불할 필요가 없다. 무료 사용이 가능한 블록체인 플랫폼은 더 광범위한 선택을 받을 가능성이 높다. 그러면 개발자와 사업가는 효율적인 수익창출 전략을 만들어낼 수 있다.

[Easy Upgrades and Bug Recovery]
[쉬운 업그레이드와 버그 수정]

사업 구축 블록체인 기반 애플리케이션에는 새로운 특징을 강화시킬 수 있는 유연성이 필요하다.

모든 중요한 소프트웨어는 버그에 시달리고, 가장 엄격한 형식 인증을 받은 경우에도 그렇다. 어쩔 수 없이 버그가 생겼을 때 플랫폼은 버그 수정이 가능하도록 충분히 강력해야 한다.

[Low Latency]
[저지연]

양호한 사용자 경험을 위해서는 지연 시간이 수초 이내인 신뢰성 있는 피드백이 필요하다. 긴 지연 시간은 사용자를 당혹스럽게 만들고, 블록체인에 구축된 애플리케이션이 기존의 비블록체인 애플리케이션에 비해 경쟁력이 떨어지게 만든다.

[Sequential Performance]
[순차적인 성능]

순차 의존적 절차로 인해, 병렬 알고리즘으로 실행할 수 없는 애플리케이션이 있다. 교환과 같은 애플리케이션은 많은 양을 관리하기에 충분한 순차적 성능이 필요하고, 따라서 빠른 순차적 성능이 있는 플랫폼이 필요하다.

[Parallel Performance]
[병렬 성능]

대규모 애플리케이션은 여러 개의 CPU와 컴퓨터로 업무 부하를 분산시켜야 한다.

[Consensus Algorithm (DPOS)]
[합의 알고리즘(DPOS)]

EOS.IO 소프트웨어는 블록체인에서의 애플리케이션의 성능요건을 충족시킬 수 있는, 유일하게 분산되어 있는 합의 알고리즘인 DPOS(Delegated Proof of Stake; 위임된 증거물)을 이용한다. 이 알고리즘에서는, 블록체인에 토큰을 가지고 있는 사람들은 지속적인 승인 투표 시스템을 통해 블록 제작자를 선택할 수 있고, 누구든지 블록 제작에 참여할 수 있으며, 자기가 받은 투표수와 다른 제작자가 받은 투표수의 비율에 따라 블록을 제작할 수 있는 기회가 주어진다. 개인적인 블록체인의 경우, 경영자는 그 토큰을 이용하여 IT직원을 늘리거나 줄일 수 있다.

EOS.IO 소프트웨어는 정확하게 3초마다 제작될 수 있도록 해주고, 주어진 그 시점에서 정확하게 한 명의 제작자가 제작을 승인 받는다. 만약 블록이 계획된 시간에 제작되지 않을 경우, 그 시간 슬롯의 블록은 건너뛰게 된다. 하나 이상의 블록이 건너뛰게 되면, 블록체인에는 6초 이상의 갭이 생긴다.

EOS.IO 소프트웨어를 사용하면, 블록이 21 라운드에서 제작된다. 각 라운드 시작 시점에서, 고유한 블록 제작자가 선택된다. 총 승인 기준 상위 20 제작자가 매 라운드마다 자동적으로 선택되고, 최후의 제작자는 다른 사람 대비 자기의 득표 비율에 따라 선택된다. 선택된 제작자는 블록 시간에서 도출된 의사 난수를 이용하여 뒤섞는다. 이렇게 뒤섞는 이유는 모든 제작자가 다른 모든 제작자와 균형된 연결성을 유지할 수 있도록 보장하기 위함이다.

EOS.IO 소프트웨어를 사용하면, 블록이 21 라운드에서 제작된다. 각 라운드 시작 시점에서, 고유한 블록 제작자가 선택된다. 총 승인 기준 상위 20 제작자가 매 라운드마다 자동적으로 선택되고, 최후의 제작자는 다른 사람 대비 자기의 득표 비율에 따라 선택된다. 선택된 제작자는 블록 시간에서 도출된 의사 난수를 이용하여 뒤섞는다. 이렇게 뒤섞는 이유는 모든 제작자가 다른 모든 제작자와 균형된 연결성을 유지할 수 있도록 보장하기 위함이다.

정상적인 상태에서는, 블록 제작자가 블록을 제작하기 위해 경쟁하기보다는 협조를 함으로써, DPOS 블록체인은 분쟁을 경험하지 않는다. 포크(fork)가 있을 경우, 합의가 자동적으로 가장 긴 체인으로 전환된다. 체인 포크에 추가되는 블록의 비율이 동일한 동의를 공유하는 블록 제작자의 비율과 직접적인 상관관계가 있기 때문에, 이 매트릭스가 작동이 된다. 다른 말로 하면, 더 많은 제작자가 있는 블록체인 포크는 더 적은 제작자가 있는 블록체인 포크보다 길이가 더 빨리 길게 된다. 게다가 어떠한 블록 제작자도 동시에 두 개의 포크에서 블록을 제작할 수 없다. 만약 이런 하자가 적발되면, 그 블록 제작자는 투표로 퇴출될 가능성이 높다. 이러한 이중 제작의 암호 증거를 이용하여 이러한 남용자를 자동적으로 제외시켜버릴 수도 있다.

[Transaction Confirmation]
[거래 인증]

일반적으로 DPOS 블록체인은 블록 제작자 참여율이 100%이다. 고지 시간으로부터 1.5초 이후 99.9% 확실하게 거래가 확인된다고 생각하면 된다.

소프트웨어 버그, 인터넷 정체와 같은 예외적인 경우도 있고, 악의적인 블록 제작자가 두 개 이상의 포크에서 제작하는 경우도 있을 수 있다. 거래는 불가역적이라는 절대적인 확실성으로 인해, 21명의 블록 제작자 중 15명의 확인을 받기 위해 노드(node)는 기다릴 수 있다. EOS.IO 소프트웨어의 일반적인 구성을 근거로 하면, 이것은 정상적인 상황에서는 평균 45초가 소요될 것이다. 기본적으로 모든 노드는 21명의 제작자 중 15명의 확인을 받은 블록을 불가역적이라고 생각할 것이고, 길이에 관계없이 그런 블록을 제외시키는 포크로 전환하지 않을 것이다.

노드가 사용자에게 사용자가 포크 시작 9초 내의 소수 포크(minority fork)에 있을 가능성이 매우 높다고 경고할 수 있다. 2번 연속하여 놓친 블록의 경우, 소수 포크에 있을 가능성이 99%이다. 놓친 노드에 대한 정보, 최근 참가율, 그리고 무언가 잘못되었다고 작업자에게 재빨리 경고를 보내기 위한 기타 요소를 활용하는 강건한 예측 모델을 생성할 수 있다.

그러한 경고에 대한 반응은 전적으로 비즈니스 거래의 특성에 달려있지만, 가장 간단한 방법은 15/21의 확인이 성사되어 경고가 중지될 때까지 기다리는 것이다.

[Transaction as Proof of Stake (TaPoS)]
[증거물로서의 거래(TaPoS)]

EOS.IO 소프트웨어는 모든 거래에 최근의 블록 헤더(block header: 한 블록의 데이터 내용을 설명하는 간단한 레코드-네이버)의 해시(hash; 함수의 한 종류-네이버)가 포함되도록 요구한다. 이 해시는 두 가지 목적이 있다:

1. 참조 블록을 포함하고 있지 않은 포크에서 거래 재생 방지
2. 특정 사용자와 그 증거물이 특정 포크에 있다는 신호 발송

시간이 경과함에 따라 결국 모든 사용자가 직접 블록체인을 확인하게 되고, 이렇게 되면 위조 체인은 합법적인 체인으로부터 거래를 이동시킬 수가 없기 때문에 위조 체인을 만드는 것은 어렵게 된다.

[Accounts]
[계정]

EOS.IO 소프트웨어는 모든 계정이 길이가 2~32글자로 된, 인간이 읽을 수 있는 고유한 이름으로 참조될 수 있도록 해준다. 이름은 계정을 만드는 사람이 정한다. 모든 계정에는 계정이 만들어지는 시점에 계정 정보를 저장할 수 있는 비용을 충당할 수 있는 최소 계정 잔고가 들어 있어야 한다. 계정 이름은 @domain 계정 소유자만이 @user.domain 계정을 만들 수 있도록 되어있다.

분산의 맥락에서, 애플리케이션 개발자는 신규 사용자가 등록할 수 있도록 계정 작성에 대한 명목 비용을 지불한다. 전통적인 비즈니스에서는 이미 광고, 무료 서비스 등의 형태로 회사가 지불하는 고객당 금액이 상당하다. 신규 블록체인 계정을 만들기 위한 명목 비용이 이것과 비교하면 대수롭지 않다. 다행히 다른 애플리케이션에 등록된 사용자는 사용자 계정을 만들 필요는 없다.

[Messages & Handlers]
[메시지 및 처리기]

각각의 계정은 다른 계정에 구조화된 메시지를 보낼 수 있으며, 메시지가 접수되면 메시지를 처리하기 위한 스크립트를 규정할 수 있다. EOS.IO 소프트웨어는 각 계정에 자체적인 메시지 처리기만 접근할 수 있는 자체적인 데이터베이스를 제공해준다. 메시지 처리 스크립트도 다른 계정에 메시지를 보낼 수 있다. 메시지와 자동 메시지 처리기의 결합이 EOS.IO가 스마트 거래를 규정하는 방법이다.

[Role Based Permission Management]
[역할 기반 승인 관리]

승인 관리에는 메시지가 적절하게 승인되었는지 아닌지를 판단하는 것이 포함된다. 승인 관리의 가장 간단한 형태는 거래에 필요한 서명이 되어있는지를 확인하는 것이지만, 이것은 필요한 서명을 이미 알고 있다는 것을 의미한다. 일반적으로 권한은 개인 또는 개인으로 이루어진 그룹에게 주어지고, 종종 구분되어 있다. EOS.IO 소프트웨어는 누가 언제 무엇을 할 수 있는지에 대한 정교하고 수준 높은 통제가 가능한 선언형 승인 관리 시스템을 제공해준다.

인증과 승인 관리는 표준화되어야 하고, 애플리케이션의 비즈니스 로직과는 구분되어야 한다는 것이 핵심이다. 이렇게 해야 일반적인 목적을 위한 방법으로 승인을 관리할 수 있는 툴 개발이 가능해지고, 성능 최적화를 위한 중요한 기회도 제공해줄 수 있다.

모든 계정은 다른 계정과 개인 키의 가중 조합을 통해 통제할 수 있다. 이렇게 하면 실제로 승인이 조직된 방법을 반영하는 계층적 승인 구조를 만들 수 있고, 펀드에 대해 이전에는 경험할 수 없었던 다중 사용자 처리가 가능해진다.

EOS.IO 소프트웨어는 계정이 개인 키 및/혹은 다른 계정의 어떤 조합이 다른 계정에 특정 메시지 형태를 보낼 수 있는지를 규정할 수 있도록 해준다. 예를 들면, 한 사용자의 소셜 미디어 계정에 대한 하나의 키를 가지고, 교환에 접근하기 위한 다른 키를 가지는 것이 가능하다. 키를 부여하지도 않고, 다른 계정이 한 사용자의 계정을 대신하여 활동할 수 있도록 승인해주는 것도 가능하다.

[Named Permission Levels]
[지정된 승인 수준]

EOS.IO 소프트웨어를 사용하면, 모든 계정은 한 차원 높은 지정 승인 수준에서 파생되는 지정 승인 수준을 규정할 수 있다. 각각의 지정 승인 수준은 권한을 규정한다. 이 권한은 다른 계정의 지정된 승인 수준 및/혹은 사용자 키로 구성된 한계치 복수 서명 확인이다. 예를 들면, 한 계정의 “친구” 승인 수준은 그 계정의 다른 모든 친구에 의해 동등하게 통제되는 계정으로 설정할 수 있다.

또 다른 예는 Steem 블록체인인데, 이것은 세 가지의 하드 코딩된 지정 승인 수준 – 소유자, 활성 및 포스팅 - 을 가지고 있다. 포스팅 승인은 투표와 포스팅과 같은 사회적 기능만 수행할 수 있는 반면, 활성 승인은 소유자 변경을 제외한 모든 것을 할 수 있다. 소유자 승인은 저온 저장(cold storage)을 의미하고, 모든 것을 할 수 있다. EOS.IO는 각각의 계정 소유자가 자기 자신의 계층을 규정할 수 있도록 해줄 뿐만 아니라 활동을 그룹으로 묶을 수 있도록 함으로써 이 개념을 일반화 해준다.

[Named Message Handler Groups]
[지정 메시지 처리기 그룹]

EOS.IO 소프트웨어는 각 계정이 자체적인 메시지 처리기를 지정 그룹과 내포 그룹으로 구성시킬 수 있도록 해준다. 이러한 지정 메시지 처리기 그룹이 승인 수준을 설정할 때 다른 계정에 의해 참조될 수 있다.

가장 높은 수준의 메시지 처리기 그룹은 계정 이름이고 가장 낮은 수준은 그 계좌가 접수하는 개별적인 메시지 유형이다. 이러한 그룹은 다름과 같이 참조될 수 있다: @accountname.groupa.subgroupb.MessageType.

이 모델에서는 교환 거래가 오더 생성을 그룹으로 묶는 것과, 보증금과 인출금으로부터 각각 취소하는 것이 가능하다. 교환 거래를 기준으로 하는 이렇게 그룹으로 묶는 것은 교환 거래 사용자에게 편리하다.

[Permission Mapping]
[승인 매핑]

EOS.IO 소프트웨어는 각 계정이 모든 계정의 지정 메시지 처리기 그룹(Named Message Handler Group of any account)과 자체적인 지정 승인 수준(Named Permission Level) 사이의 매핑을 규정할 수 있도록 해준다. 예를 들면, 계정 소유자는 계정 소유자의 소셜 미디어 애플리케이션을 계정 소유자의 “친구” 승인 그룹으로 매핑할 수 있다. 이 매핑을 이용하면, 모든 친구는 계정 소유자의 소셜 미디어에 계정 소유자처럼 포스팅을 할 수 있다. 그들이 계정 소유자처럼 포스팅을 하더라도, 그들은 메시지에 서명을 하기 위해 그들 자신의 키를 계속 사용할 것이다. 이것은 어느 친구가 그 계정을 사용하였는지 그리고 어떤 식으로 사용하였는지 확인하는 것이 항상 가능하다는 것을 의미한다.

[Evaluating Permissions]
[평가 승인]

@alice에서 @bob로 "Action" 유형의 메시지를 전달할 때, EOS.IO 소프트웨어는 우선 @alice가 @bob.groupa.subgroup.Action 에 대한 승인 매핑을 규정하였는지 확인한다. 아무 것도 발견되지 않으면, @bob.groupa.subgroup에 대한 매핑을, 그 다음으로는 @bob.groupa에 대한 매핑을, 마지막으로 @bob에 대한 매핑을 확인한다. 아무 것도 매칭이 되지 않으면, 지정 승인 그룹 @alice.active 이 추정 매핑이 된다.

일단 매핑이 확인되면, 한계치 복수 서명 확인 절차와 지정 승인 관련 권한을 이용하여 서명 권한을 확인한다. 실패할 경우, 전 단계 승인으로 되돌아가고, 궁극적으로는 소유자 승인인 @alice.owner으로 되돌아간다.

[Default Permission Groups]
[디폴트 승인 그룹]

이 기술은 모든 계정이 모든 것을 할 수 있는 “소유자” 그룹과, 소유자 그룹을 변경하는 것을 제외한 모든 것을 할 수 있는 “활성(active)” 그룹을 가질 수 있도록 해준다. 모든 다른 승인 그룹은 “활성” 그룹에서 파생된다.

[Parallel Evaluation of Permissions]
[병렬 승인 평가]

승인 평가 절차는 “읽기 전용”이고, 거래에 의해 이루어진 승인 변경은 블록이 끝날 때까지 효력이 발생하지 않는다. 이것은 모든 거래에 대한 승인 평가와 모든 키는 병행 처리 될 수 있다는 것을 의미한다. 게다가 이것은 결국은 되돌려야 하는 값비싼 애플리케이션 로직을 시작하지도 않고, 신속하게 승인 확인을 할 수 있다는 것을 의미한다. 마지막으로 이것은 미종료 거래가 접수되면 거래 승인을 평가할 수 있고, 다른 거래를 위해 거래 승인을 재평가할 필요가 없다는 것을 의미한다.

모든 것을 감안하면, 승인 확인은 거래 확인에 엄청난 비중의 컴퓨터 작업이 필요하다는 것을 의미한다. 이것을 읽기 전용으로 만들고, 병행 처리가 가능하도록 만들면, 성능이 극적으로 향상된다.

메시지 로그로부터 결정 상태로 다시 생성하기 위해 블록체인을 재생할 때, 승인을 다시 평가할 필요가 없다. 거래가 잘 알고 있는 양호한 블록에 포함되어 있다는 사실만 안다면 이 단계를 뛰어넘기에 충분하다. 이것은 점점 용량이 커지는 블록체인을 재생하는 것과 관련된 컴퓨터 작업의 부하를 극적으로 감소시켜준다.

[Messages with Mandatory Delay]
[의무 지연 메시지]

시간은 보안에 치명적인 요소이다. 대부분의 경우, 사용되기 전까지는 개인 키가 도난 당한 줄을 모른다. 매일 사용하기 위해 인터넷에 연결되어 있는 컴퓨터에 키를 저장해야 하는 애플리케이션을 가지고 있는 사람의 경우, 시간 기반 보안은 훨씬 더 치명적이다. EOS.IO 소프트웨어는 특정 메시지가 적용되기 전에 그 메시지가 블록에 포함된 이후 기다려야 하는 최소한의 시간을 애플리케이션 개발자가 표시할 수 있도록 해준다. 이 시간에는 취소가 가능하다.

이런 메시지 중 하나가 전달될 때, 사용자들은 이메일이나 문자로 통보를 받는다. 사용자가 권한이 없으면, 계정 복구를 위해 계정 복구 절차를 사용할 수 있으며, 메시지를 취소할 수 있다.

필요한 지연은 그 작업이 얼마나 민감한지에 달려있다. 커피 값을 지불하는 것은 지연될 수 없으며 수초 내에 불가역적이 된다. 반면에 주택 구매는 72시간의 확정 기간이 필요할 수 있다. 계정 전체를 새로운 관리 기능으로 이동시키는 데에는 30일까지 소요될 수 있다. 선택된 정확한 지연은 애플리케이션 개발자와 사용자에게 달려있다.

[Recovery from Stolen Keys]
[도난된 키의 복구]

EOS.IO 소프트웨어는 사용자에게 키가 도난 당했을 때 계정의 관리를 복구할 수 있는 방법을 제공해준다. 계정 소유자는 소유자 키를 리셋하기 위해 지정해 둔 계정 복구 파트너로부터 승인을 받으면, 지난 30일간 활성상태였던 소유자의 키를 사용할 수 있다. 계정 복구 파트너는 소유자의 도움 없이는 계정 관리를 리셋할 수 없다.

소유자가 이미 계정을 “관리”하고 있기 때문에, 해커가 복구 과정을 뚫고 들어가보려고 시도하여도 얻는 것은 아무 것도 없다. 게다가 복구 과정을 뚫고 들어갔다고 하더라도, 복구 파트너가 ID와 복수 요인 승인(전화 번호와 이메일 주소)을 요구할 것이다. 이리하여 해커는 위태로워지거나 이 과정에서 얻는 것이 아무 것도 없게 된다.

또한 이 과정은 단순한 복수 서명 확인 과정과는 매우 다르다. 복수 서명 거래의 경우, 실행되고 있는 모든 거래에는 상대방 회사가 있지만, 회복 절차의 경우에는 행위자는 회복 절차의 유일한 일방이며, 일상적인 거래에는 아무런 권한이 없다. 이리하여 관련된 모든 사람의 법적 책임과 비용이 극적으로 감소된다.

[Deterministic Parallel Execution of Applications]
[애플리케이션의 결정론적 병행 실행]

블록체인 합의는 결정론적(재현가능) 행위에 달려있다. 이것은 모든 병행 실행이 뮤텍스(하나의 뮤텍스는 다중 작업을 허용하는 하나의 전역 변수-인터넷) 또는 기타 락(locking primitives)의 사용으로부터 자유로워야 한다는 것을 의미한다. 락이 없으면, 모든 계정이 자기 자신의 개인적 데이터베이스를 읽고 쓸 수만 있다는 사실을 보장할 수 있는 방법이 있어야 한다. 이것은 또한 각 계정이 메시지를 순차적으로 처리한다는 것을 의미하고, 계정 차원에서 병행 실행이 이루어진다는 것을 의미한다.

EOS.IO 소프트웨어를 사용하면, 쓰레드가 병행 평가될 수 있도록 메시지 전달을 독립적인 쓰레드 안으로 구성시키는 것은 블록 제작자의 몫이다. 각 계정의 상태는 그 안으로 전달된 메시지에만 달려있다. 스케줄은 블록 제작자의 출력물이고, 결정론적으로 시행될 것이지만, 스케줄 생성 과정은 결정론적일 필요는 없다. 이것은 블록 제작자가 거래 스케줄 작성을 위해 병행 알고리즘을 활용할 수 있다는 것을 의미한다.

병행 실행의 부분적인 의미는, 스크립트가 새로운 메시지를 생성할 때, 즉시 전달되지 않고, 다음 사이클에 전달되도록 계획된다는 것을 의미한다. 즉시 전달되지 않는 이유는 접수자가 다른 쓰레드에서 자기 자신의 상태를 적극적으로 수정하고 있을 수 있기 때문이다.

[Minimizing Communication Latency]
[통신 지연 최소화]

지연이란 한 계정이 다른 계정으로 메시지를 보내는 데 걸리는 시간이다. 목표는 두 계정이 각 메시지 사이에 3초를 기다릴 필요 없이 단일 블록에서 메시지를 주고 받을 수 있도록 하는 것이다. 이렇게 하기 위해서는, EOS.IO 소프트웨어는 각 블록을 사이클로 나준다. 각 사이클은 쓰레드로 나누어지고, 각 쓰레드에는 거래 목록이 포함되어 있다. 각 거래에는 전달되어야 하는 일련의 메시지가 있다. 이 구조는 나무 모양으로 나타낼 수 있는데, 각 층은 순차 처리와 병행 처리가 교대로 나타난다.

한 사이클에서 생성된 거래는 그 다음 사이클 또는 블록에서 전달될 수 있다. 블록 제작자는 최대 벽시계 시간(측정치가 하드웨어 시계로부터의 전형적인 출력일 때, 실제 전역 시간에 대한 연합 참여 체계의 측정치-네이버)이 지날 때까지, 또는 전달할 새로이 생성된 거래가 없을 때까지, 블록에 사이클을 계속 추가한다.

주어진 사이클 내의 그 어떠한 두 개의 쓰레드에도 동일한 계정을 수정하는 거래가 포함되지 않았다는 것을 확인하기 위해 블록에 대해 정적 분석(static analysis)을 하는 것도 가능하다.

[Read-Only Message Handlers]
[읽기 전용 메시지 처리기]

어떤 계정은 내부 상태 수정 없이 합격/불합격을 기준으로 메시지를 처리할 수 있을 것이다. 이럴 경우, 특정 사이클 내의 하나 이상의 쓰레드에 특정 계정에 대한 읽기 전용 메시지 처리기가 포함되어 있을 경우에만, 이러한 처리기가 병행 처리 될 수 있다.

[Atomic Transactions with Multiple Accounts]
[복수 계정에 대한 원자적 거래 ]

때로는 복수의 계정에 메시지가 원자적으로 전달되고 접수되도록 하는 것이 바람직할 때가 있다. 이럴 경우, 전달 메시지와 접수 메시지가 하나의 거래로 묶이고, 두 계정에는 동일한 쓰레드가 부여되고, 메시지는 순차적으로 적용된다. 이 상황은 성능의 측면에서는 이상적이지 않고, “청구(billing)”의 경우, 사용자들은 거래에 의해 참조되는 고유한 계정의 숫자만큼 청구를 받게 될 것이다.

성능과 비용 때문에, 두 개 이상의 많이 활용되는 계정을 포함하는 작업의 경우 원자적 작업을 최소화하는 것이 상책이다.

[Partial Evaluation of Blockchain State]
[블록체인 상태 부분 평가]

블록체인 기술을 확장시키기 위해서는 구성요소가 모듈 형식이어야 한다. 모든 사람이 모든 기능을 구현할 필요는 없다, 특히 몇몇 애플리케이션만 사용하면 되는 경우는 더욱 그러하다.

교환 애플리케이션 개발자는 사용자에게 교환 상태를 보여줄 목적으로 풀 노드(full node)를 구현한다. 이 교환 애플리케이션은 소셜 미디어 애플리케이션과 관련된 상태가 필요하지 않다. EOS.IO 소프트웨어는 풀 노드가 구현할 애플리케이션을 선택할 수 있도록 해준다. 애플리케이션의 상태가 전부 애플리케이션에 전달된 메시지로부터 파생되기 때문에, 다른 애플리케이션에 전달된 메시지는 안전하게 무시된다.

이것은 다른 계정과의 통신에 중요한 함의를 가지고 있다. 가장 중요한 것은, 다른 계정의 상태가 동일한 기계에서 접근 가능하다고 생각될 수 없다는 것이다. 이것은 또한 한 계정이 다른 계정을 동시에 콜(call)할 수 있도록 해주는 “락”을 풀려고 시도하는 동안, 다른 계정이 메모리의 거주자가 아닌 경우 디자인 패턴이 파괴된다는 것을 의미한다.

계정들간의 모든 상태 통신은 블록체인에 포함된 메시지를 통해 전달되어야 한다.

[Subjective Best Effort Scheduling]
[주관적인 최선의 노력 스케줄 작성]

EOS.IO 소프트웨어는 블록 제작자에게 다른 계정에 어떤 메시지를 전달하라고 강제할 수 없다. 각각의 블록 제작자는 컴퓨터 작업의 복잡성과 거래 처리 소요 시간에 대해 자체적으로 주관적인 판단을 한다. 이것은 거래가 사용자에 의해 생성될 것인지 아니면 스크립트에 의해 자동으로 생성될 것인지에 적용된다.

EOS.IO 소프트웨어에서의 모든 거래에는, 네트워크 수준에서, 그것을 실행하는 데에 .01ms 또는 전체 10ms가 걸리든지 관계 없이, 고정된 컴퓨터 대역폭(bandwidth; 컴퓨터 네트워크나 인터넷이 특정 시간 내에 보낼 수 있는 정보량. 흔히 초당 비트로 측정됨-역자) 비용이 청구된다. 하지만 EOS.IO 소프트웨어를 사용하는 각각의 블록 제작자는 자체적인 알고리즘과 측정을 이용하여 리소스 사용량을 계산할 수 있다. 블록 제작자가 어떤 거래나 계정이 너무 많은 양의 컴퓨터 능력을 소비하였다고 판단한다면, 자체적인 블록 제작 시 거래를 그냥 거부한다. 하지만 다른 블록 제작자가 유효하다고 간주한다면 그 거래를 계속 처리할 것이다.

일반적으로 1 블록 제작자가 어떤 거래를 유효하다고 간주하고, 리소스 사용량 한도 내에 있을 경우, 다른 모든 블록 제작자들도 그것을 받아들이겠지만, 그 거래가 그 제작자를 찾는 데에 1분까지 걸릴 수 있다.

어떤 경우, 제작자는 받아 들일 수 있는 범위를 벗어나는 거래가 포함된 블록을 제작할 수 있다. 이런 경우, 그 다음 블록 제작자는 그 블록을 거부할 수 있고, 세 번째 제작자에 의해 연대는 끊어진다. 이것은 대형 블록이 네트워크 전달 지연을 야기했을 때 일어나는 일과 다르지 않다. 공동체는 남용의 패턴을 고지하고, 결국 그 나쁜 제작자를 투표를 통해 몰아낼 것이다.

컴퓨터 작업 비용에 대한 이러한 주관적인 평가로 인해 블록체인은 어떤 것이 구현되는 데에 얼마나 오래 걸리는지 정확하고 결정론적으로 측정할 필요 없다. 이러한 설계로 인해, 합의를 깨지 않고 최적화 기회를 극적으로 증가시켜주는 지시를 정확하게 셀 필요가 없다.

[Token Model and Resource Usage]
[토큰 모델과 리소스 사용량]

모든 블록체인은 리소스가 제한되어 있고, 시스템 남용 방지가 필요하다. EOS.IO 소프트웨어에는, 애플리케이션이 사용할 수 있는 세 가지의 리소스 종류가 있다.

1. 대역폭 및 로그 저장소 (디스크);
2. 컴퓨터작업(computation) 및 컴퓨터작업 백로그 (CPU);
3. 상태 저장소 (RAM).

대역폭과 컴퓨터작업은 순간 사용과 장기 사용이라는 두 가지 요소로 구성되어 있다. 블록체인은 모든 메시지에 대한 로그(log)를 유지하고 있고, 이 로그는 궁극적으로 모든 풀 노드에 의해 저장되고 다운로드 된다. 메시지 로그를 이용하면, 모든 애플리케이션의 상태를 재구성할 수 있다.

컴퓨터작업 부채는 메시지 로그로부터 상태를 재생성할 때 수행해야 하는 계산이다. 만약 컴퓨터작업 부채가 너무 커지면, 블록체인 상태를 스냅샷으로 찍어놓고 블록체인의 과거 기록을 삭제해야 한다. 컴퓨터작업 부채가 너무 빨리 커지면 1년 분의 거래를 재생하는 데 6개월이 걸릴 수 있다. 그러므로 컴퓨터작업 부채를 신중하게 관리하는 것이 중요하다.

블록체인 상태 저장소는 애플리케이션 로직에서 접근할 수 있는 정보이다. 여기에는 주문서 및 계좌 잔고와 같은 정보가 포함된다. 블록체인 상태를 애플리케이션으로 읽을 수 없으면, 저장하면 안 된다. 예를 들어, 블로그 게시물 내용과 코멘트는 애플리케이션 로직으로 읽을 수 없으므로, 블록체인의 상태에 저장하면 안 된다. 한편 게시물/코멘트의 존재, 투표 수 및 기타 속성은 블록체인의 상태의 일부로 저장된다.

블록 제작자는 대역폭, 컴퓨터작업 및 상태에 대해 가용 용량을 게시한다. EOS.IO 소프트웨어는 각 계정이 3 일간의 증거물 거래(staking contract)에서 보유된 토큰의 양에 비례하는 가용 용량을 소비할 수 있도록 해준다. 예를 들어, EOS.IO 소프트웨어를 기반으로 하는 블록체인이 시작되고, 그리고 어떤 계정이 해당 블록체인과 관련하여 배분할 수 있는 전체 토큰의 1 %를 보유하고 있는 경우, 해당 계정은 상태 저장 용량의 1 %를 사용할 수 있다.

EOS.IO 소프트웨어를 사용하면, 대역폭과 컴퓨터작업 용량이 일시적이기 때문에(사용되지 않은 용량은 나중에 사용하기 위해 저장할 수 없음), 부분 비축 기준으로 할당된다. EOS.IO에서 사용되는 알고리즘은 대역폭 사용량의 속도를 제한하기 위해 Steem에서 사용하는 알고리즘과 유사하다.

앞에서 설명한 것처럼 컴퓨터작업 사용량 측정은 성능 및 최적화에 중요한 영향을 준다. 따라서 모든 리소스 사용량 제한은은 궁극적으로 주관적일 수 밖에 없고, 강제 실행은 개별 알고리즘 및 추정에 따라 블록 제작자가 수행한다.

즉, 객관적으로 측정하기에는 사소한 것들이 있다. 전달되는 메시지의 수와 내부 데이터베이스에 저장되는 데이터의 크기는 객관적으로 측정할 가치가 없다. EOS.IO 소프트웨어는 블록 제작자가 이러한 객관적 측정에 대해 동일한 알고리즘을 적용할 수 있도록 해주지만, 주관적 측정에 대해 보다 엄격하게 주관적 알고리즘을 적용할 수도 있다.

[Receiver Pays]
[수익자 부담]

전통적으로 사무실 공간, 컴퓨터작업 및 비즈니스 운영에 필요한 기타 비용을 지불하는 쪽은 회사이다. 고객은 회사로부터 특정 제품을 구입하고, 해당 제품 판매에서 얻은 수익은 비즈니스 운영 비용을 충당하기 위해 사용된다. 마찬가지로 웹사이트가 웹사이트에 방문객이 방문을 하는 것에 대해 방문객에게 잔돈을 지불하도록 하도록 만들어, 웹 사이트 호스팅 비용을 충당해서는 안 된다. 따라서 분산 애플리케이션은 고객에게 블록체인 사용에 대해 직접적으로 비용을 지불하도록 강제해서는 안 된다.

EOS.IO 소프트웨어는 사용자에게 블록체인 사용에 대해 블록체인에 직접 비용을 지불하도록 요구하지 않으므로, 회사가 자기 제품에 대한 자체적인 수익 창출 전략을 결정하는 것을 제한하거나 방해하지 않는다.

[Delegating Capacity]
[용량 대여]

EOS.IO 소프트웨어를 사용하여 블록체인을 시작한 경우, 그리고 가용 대역폭의 전부 또는 일부를 즉시 소비할 필요가 없는 소유자가 토큰을 보유한 경우, 이러한 소유자는 소비되지 않은 대역폭을 다른 사람에게 주거나 빌려줄 수 있다. EOS.IO 소프트웨어를 이용하는 블록 제작자는 이 용량 대여 기능을 이해하고, 그에 따라 대역폭을 할당하면 된다.

[Separating Transaction costs from Token Value]
[거래 비용을 토큰 가치로부터 분리]

EOS.IO 소프트웨어의 주요 장점 중 하나는 애플리케이션의 가용 대역폭의 양이 토큰 가격과 완전히 독립적이라는 것이다. 애플리케이션 소유자가 상당한 수의 토큰을 보유하고 있으면, 그 애플리케이션은 고정된 상태 및 대역폭 사용량 내에서 무제한 실행될 수 있다. 개발자와 사용자는 토큰 시장의 가격 변동성에 영향을 받지 않는다, 따라서 제공되는 가격 정보에 연연해하지 않는다. EOS.IO 소프트웨어를 사용하면 블록 제작자는 토큰의 가치와 관계없이, 토큰당 사용 가능한 대역폭, 컴퓨터작업 및 저장소를 자연스레 증가시킬 수 있다.

EOS.IO 소프트웨어는 블록 제작자가 블록을 제작할 때마다 토큰을 수여한다. 토큰의 가치는 제작자가 구매할 수 있는 대역폭, 저장소 및 컴퓨터작업의 양에 영향을 준다. 이 모델은 증가하는 토큰 가치를 자연스레 활용하여 네트워크 성능을 향상시킬 수 있도록 해준다.

[State Storage Costs]
[상태 저장소 비용]

대역폭과 컴퓨터작업을 위임 할 수 있지만, 애플리케이션 상태를 저장하려면 해당 상태가 삭제될 때까지 애플리케이션 개발자가 토큰을 보유해야 한다. 상태가 삭제되지 않으면, 토큰이 유통되지 않고 사실상 제거된다.

모든 사용자 계정에는 일정량의 저장소가 필요하다. 그러므로 모든 계좌는 최소 잔고를 유지해야 한다. 네트워크의 저장 용량이 증가함에 따라, 이 최소 필요 잔고는 감소될 것이다.

[Block Rewards]
[블록 보상]

EOS.IO 소프트웨어는 블록이 제작될 때마다 새로운 토큰을 블록 제작자에게 보상으로 수여한다. 생성된 토큰의 수는 모든 블록 제작자가 게시한 원하는 지불의 중간 값으로 결정된다. EOS.IO 소프트웨어는 토큰 공급 연간 증가치가 5 %를 초과하지 않도록, 제작자에게 수여하는 보상 수량에 상한을 설정할 수 있다.

[Community Benefit Applications]
[공동체 혜택 애플리케이션]

EOS.IO 소프트웨어를 기반으로 하여 블록 제작자를 선택하는 것 외에도, 사용자들은 스마트 거래로 알려진 3가지 공동체 혜택 애플리케이션을 선택할 수 있다. 이 3가지 애플리케이션은 설정된 연간 토큰 공급량에서, 이미 블록 제작자에게 지불한 양을 뺀, 나머지 토큰을 받는다. 이러한 스마트 거래는 각 애플리케이션이 토큰 보유자로부터 받은 투표수에 비례한 토큰을 받는다. 선택 된 애플리케이션 또는 스마트 거래는 토큰 소유자가 새로 선택한 애플리케이션 또는 스마트 거래로 대체 할 수 있다.

[Governance]
[거버넌스(관리)]

거버넌스는 사람들이 소프트웨어 알고리즘으로는 완전히 포착할 수 없는 주관적인 문제에 대해 합의에 이르는 과정이다. EOS.IO 소프트웨어는 블록 제작자의 기존 영향력을 효율적으로 행사할 수 있는 거버넌스 절차를 실행한다. 이전의 블록체인에는 규정된 거버넌스 절차가 없어, 즉흥적이고, 비공식적인, 그리고 종종 논란의 소지가 있는 거버넌스 절차에 의존하였고, 때문에 결과가 예측 불가능하였다.

EOS.IO 소프트웨어는 권한을 블록 제작자에게 위임을 해준 토큰 소지자에게서 권한이 나온다는 것을 알고 있다. 블록 제작자에게는 계정을 동결하고, 결함이 있는 애플리케이션을 업데이트하고, 기본 프로토콜에 대해 하드 포크(hard fork) 변경을 제안할 수 있는, 제한적이고 확인된 권한만 부여된다.

EOS.IO 소프트웨어의 한 부분은 블록 제작자를 선택하는 것이다. 어떠한 블록체인 변경을 위해서도, 블록 제작자의 승인이 필요하다. 만약 블록 제작자가 토큰 소지자가 원하는 대로 변경을 하지 않는다면, 해당 블록 제작자는 투표로 제거할 수 있다. 만약 블록 제적자가 토큰 소지자의 허가 없이 변경하면, 다른 모든 제적하지 않는 풀 노드 확인장치(교환 등)가 변경을 거부할 것이다.

[Freezing Accounts]
[계정 동결]

때로는 스마트 거래가 비정상적이거나 예측할 수 없는 방식으로 작동되고, 의도한대로 수행되지 않는 경우가 있다. 또 다른 때에는, 애플리케이션 또는 계정이 불합리한 양의 리소스를 소비할 수 있도록 되어있는 경우를 발견할 수 있다. 이러한 문제가 부득이하게 발생하면, 블록 제작자는 이러한 상황을 바로 잡을 수 있는 권한을 가지고 있다.

모든 블록체인의 블록 제작자는 자기에게 계정 동결 권한을 주는 블록에, 어느 거래를 포함시킬지 선택할 수 있는 권한을 가지고 있다. EOS.IO 소프트웨어는 활성 제작자의 17/21의 투표로 계정 동결 과정을 승인해 줌으로써, 이 권한을 공식화한다. 제작자가 권한을 남용하면 투표로 퇴출시킬 수 있고, 계정 동결은 해제된다.

[Changing Account Code]
[계정 코드 변경]

다른 모든 방법이 실패하고, "중지 불가 애플리케이션"이 예기치 않은 방식으로 작동하면, EOS.IO 소프트웨어는 블록 제작자가 전체 블록체인을 하드 포크 하지 않고 계정 코드를 변경할 수 있도록 해준다. 계좌 동결 과정과 마찬가지로, 이 코드 변경도 활성 블록 제작자의 17/21의 득표가 있어야 한다.

[Constitution]
[헌법]

EOS.IO 소프트웨어는 블록체인이 P2P (peer-to-peer) 조건의 서비스 약정을 체결하거나, 약정에 서명하는 사용자간에 구속력 있는 계약을 체결할 수 있도록 해준다("헌법"이라고 함). 이 헌법에는 코드로 완전히 강제될 수 없는, 사용자 간의 의무가 규정되어 있고, 관할지역 결정, 법률 및 상호 인정하는 다른 규칙 선택을 통해, 분쟁 해결을 용이하게 해주는 내용이 포함되어 있다. 네트워크에서 고지되는 모든 거래는 헌법의 해시(hash)를 서명의 일부로 포함시켜야 하고, 그리하여 서명자가 명시적으로 계약에 구속이 되도록 해야 한다.

헌법에는 또한 사람이 읽을 수 있도록 소스 코드 프로토콜이 규정되어 있다. 이 의도는 오류가 발생했을 때, 버그와 기능의 차이를 식별하고, 공동체가 어떤 해결책이 적절한지 판단하는 데에 사용된다.

[Upgrading the Protocol & Constitution]
[프로토콜과 헌법 업그레이드]

EOS.IO 소프트웨어에는 다음 프로세스를 사용하여, 정식 소스 코드 및 헌법으로 규정되어 있는 프로토콜을 업데이트 할 수 있는 프로세스가 규정되어 있다.

1. 블록 제작자는 헌법의 변경을 제안하고, 17/21 득표로 승인 받는다.
2. 블록 제작자는 30일 연속 17/21 승인을 유지한다.
3. 모든 사용자는 새 헌법의 해시를 사용하여 거래에 서명해야 한다.
4. 블록 제작자는 헌법의 변경을 반영하기 위해 소스 코드의 변경을 채택하고, git commit의 해시를 이용하여 블록체인에 제안한다.
5. 블록 제작자는 30일 연속 17/21 승인을 유지한다.
6. 코드 변경은 소스 코드 승인 후 업그레이드하는 데에 1 주일을 풀 노드에 주고, 7일 후부터 효력이 발생된다.
7. 새 코드로 업그레이드하지 않는 모든 노드는 자동으로 종료된다.

EOS.IO 소프트웨어를 디폴트로 설정하면, 새로운 기능을 추가하기 위해 블록체인을 업데이트하는 데에 2~ 3개월이 걸리지만, 헌법 변경이 필요 없는 중요하지 않은 버그를 수정하는 데는 1~2개월이 걸릴 수 있다.

[Emergency Changes]
[긴급 변경]

사용자를 적극적으로 해치고 있는 유해 버그 또는 보안 문제를 수정하기 위해 소프트웨어 변경이 필요한 경우, 블록 제작자는 절차를 가속화 할 수 있다. 일반적으로 새로운 기능을 도입하거나 무해한 버그를 수정하기 위해 업데이트를 가속화하는 것은 헌법에 위배될 수 있다.

[Scripts & Virtual Machines]
[스크립트 및 가상 기계]

EOS.IO 소프트웨어는 인증된 메시지를 계정에 전달하도록 조정된, 최초이자 가장 중요한 플랫폼일 것이다. 스크립트 언어 및 가상 기계의 세부 사항은 EOS.IO 기술 설계와는 독립적인, 실행에 고유한 세부 사항이다. EOS.IO 소프트웨어 API는 결정론적이고 충분한 성능으로 적절하게 보안 처리된 모든 언어 또는 가상 기계를 통합할 수 있다.

[Schema Defined Messages]
[스키마 정의 메시지]

계정간에 전송되는 모든 메시지는 블록체인 동의 상태의 일부인 스키마에 의해 정의된다. 이 스키마는 메시지의 바이너리 표현과 JSON 표현간에 원활한 변환이 가능하도록 해준다.

[Schema Defined Database]
[스키마 정의 데이터베이스]

데이터베이스 상태도 유사한 스키마를 사용하여 정의된다. 이렇게 되면 모든 애플리케이션에 저장된 모든 데이터의 포맷은 사람이 읽을 수 있는 JSON으로 해석될 수 있지만, 저장과 조작은 효율적인 바이너리로 할 수 있게 된다.

[Separating Authentication from Application]
[승인과 애플리케이션 분리]

병렬 기회를 극대화하고, 거래 로그에서 애플리케이션 상태를 다시 생성하는 것과 관련된 컴퓨터작업 부채를 최소화하기 위해, EOS.IO는 확인 로직을 세 가지로 구분한다.

1. 메시지가 내부적으로 일관성이 있는지 확인
2. 모든 전제 조건이 유효하다는 것 확인
3. 애플리케이션 상태 수정.

메시지의 내부 일관성을 확인하는 것은 읽기 전용이며, 블록체인 상태에 접근할 필요는 없다. 이것은 최대 병렬 처리로 수행될 수 있음을 의미한다. 필요 잔고와 같은 전제 조건을 확인하는 것은 읽기 전용이므로, 병렬 처리에도 도움이 된다. 애플리케이션 상태의 수정에만 쓰기 접근이 필요하며, 각 애플리케이션에 순차적으로 처리되어야 한다.

인증은 메시지를 적용할 수 있는지 확인하는 읽기 전용 과정이다. 애플리케이션이 실제로 그 작업을 수행하고 있다. 두 가지 계산이 동시에 수행되어야 하지만, 일단 거래가 블록체인에 포함되면, 더 이상 인증 작업을 수행할 필요는 없다.

[Virtual Machine Independent Architecture]
[가상 기계 독립 제작기술]

EOS.IO 소프트웨어의 의도는 복수의 가상 기계를 지원하고, 시간이 지나면서 필요하면 새로운 가상 기계를 추가하는 것이다. 따라서 이 백서에서는 특정 언어나 가상 기계에 대한 세부 내용을 다루지 않는다. 굳이 밝히자면, 현재 EOS.IO에서 사용하기 위해 평가되고 있는 가상 기계는 두 대이다.

[Web Assembly (WASM)]
[웹 어셈블리(WASM)]

웹 어셈블리는 고성능 웹 애플리케이션을 구축하기 위한 새로이 부상하는 웹 표준이다. 약간만 수정하면, 웹 어셈블리를 결정론적으로 만들고, 보안 처리를 할 수 있다. 웹 어셈블리의 이점은 업계의 광범위한 지지와, C 또는 C ++와 같은 친숙한 언어로 계약을 개발할 수 있다는 것이다.

이더리움 개발자는 이미 웹 어셈블리를 수정하여, 자신만의 이더리움 향기가 나는 웹 어셈블리(WASM)에 적절한 보안처리 및 결정론을 제공하기 시작하였다. 이 접근 방식은 EOS.IO 소프트웨어에 쉽게 조정되고, 통합될 수 있다.

[Ethereum Virtual Machine (EVM)]
[이더리움 가상 기계(EVM)]

이 가상 기계는 대부분의 기존의 스마트 거래에 사용되어 왔고, EOS.IO 블록체인 내에서 작동하도록 조정될 수 있다. EVM 계약은 EOS.IO 블록체인 내부의 자체 보안 시스템 내에서 실행될 수 있으며, 약간만 조정하면, EVM 계약이 다른 EOS.IO 블록체인 애플리케이션과 통신 할 수 있다.

[Inter Blockchain Communication]
[블록체인 간 통신]

EOS.IO 소프트웨어는 블록체인 간 통신을 용이하게 하기 위해 설계되었다. 이것은 메시지 존재 증명 및 메시지 시퀀스 증명을 생성하는 것이 용이하도록 만들었기에 가능하게 되었다. 이러한 증명이, 메시지 전달과 관련하여 설계된 애플리케이션 제작기술과 결합되었기 때문에, 블록체인 간 통신 및 증명 확인의 세부 내용을 애플리케이션 개발자가 모르도록 숨길 수 있게 되었다.

[Merkle Proofs for Light Client Validation (LCV)]
[경량 클라이언트 컴퓨터 확인(LCV)을 위한 머클 증명

클라이언트가 모든 거래를 처리 할 필요가 없으면, 다른 블록체인과 통합하는 것은 훨씬 쉽다. 결국, 교환은 교환 내외부로의 이동에 대해서만 관심이 있을 뿐, 다른 것에 대해서는 관심이 없다. 교환 체인이 자체 블록 제작자를 완전히 신뢰할 필요 없이, 경량 머클 보증금(deposit) 증명을 사용할 수 있다면 이상적일 것이다. 적어도 체인블록 제작자는 다른 블록체인과 동기화 할 때, 최소한의 가능한 경비를 유지하려고 한다.

LCV의 목표는 상대적으로 경량인 데이터 세트를 추적하는 사람이 확인할 수 있는, 상대적으로 경량인 존재 증명을 생성할 수 있게 하는 것이다. 이 경우, 목표는 특정 거래가 특정 블록에 포함되었으며, 그 블록이 특정 블록체인의 확인된 과거 역사에 포함되었다는 것을 증명하는 것이다.

비트코인은 모든 노드가 연간 4MB에 해당되는 블록 헤더의 완전한 역사에 접근한다고 가정하며, 거래 확인을 지원해준다. 초당 10회의 거래의 경우, 유효한 증명에는 약 512 바이트가 필요하다. 이것은 10분간의 블록 간격을 가진 블록체인에서는 잘 작동하지만, 3초간의 블록 간격을 가진 블록체인에서는 더 이상 "경량"이 아니다. EOS.IO 소프트웨어는 거래가 포함된 시점 이후에 불가역적인 블록 헤더를 가진 사람이라면 누구에게 대해서도 경량 증명이 가능하게 해준다. 아래에 나와있는 해시 링크 구조를 사용하면, 크기가 1024바이트 미만인 증명이 있는 모든 거래의 존재를 증명할 수 있다. 노드 확인이 전날의 모든 블록 헤더를 유지하고 있다고 생각된다면(2MB의 데이터), 이들 거래를 증명하는 데에는 고작 200바이트 길이의 증명만이 필요할 것이다.

이러한 증명이 가능하도록 적절한 해시-링크로 블록을 제작하는 것과 관련된 비용 증가는 거의 없다. 이 말은 이러한 방법으로 블록을 생성하지 않을 이유가 없다는 의미이다.

다른 체인에 대한 증명을 확인할 때가 되면, 실행할 수 있는 시간/공간/대역폭 최적화가 매우 다양하다. 모든 블록 헤더를 추적하면(420MB/년) 증명 크기가 작게 유지된다. 최신 헤더만 추적하면, 장기적인 최소 저장 공간과 증명 크기 사이에 균형이 일어난다. 아니면 블록체인은 과거 증명의 중간 수준의 해시를 기억하는, 지연 평가 방식을 사용할 수 있다. 새로운 증명에는 알려진 sparse tree(희박한 트리?)에 대한 링크만 포함하면 된다. 사용된 정확한 접근법은 필연적으로 머클 증명에 의해 참조된 거래를 포함하는, 외국 블록의 비율에 따라 달라질 것이다.

상호 연관성이 특정한 밀도를 가진 후에는, 그냥 하나의 체인에 다른 체인의 전체 블록 역사가 포함되도록 하고, 전체를 증명할 필요를 없애는 것이 더 효율적일 것이다. 성능상의 이유로, 체인 간 증명의 빈도를 최소화하는 것이 이상적이다.

[Latency of Interchain Communication]
[체인 간 통신 지연]

블록체인 외부의 다른 블록 제작자와 통신을 할 때, 블록 제작자는 거래를 유효한 입력 값으로 받아들이기 전에, 거래가 다른 블록체인에 의해 불가역적으로 확정되었다고 100 % 확신할 때까지 기다려야 한다. 3초 블록과 21명의 제작자가 있는 EOS.IO 소프트웨어와 DPOS를 사용하면 이것은 약 45초가 소요된다. 체인블록 제작자가 불가역 상태를 기다리지 않는다면, 나중에 뒤집어질 수 있는 보증금을 받는 교환과 같을 것이고, 체인의 동의 확인에 영향을 줄 수 있다.

[Proof of Completeness]
[완전성 증명]

블록체인 외부에서 나온 머클 증명을 사용할 때, 처리된 모든 거래가 유효하다는 것을 아는 것과, 거래가 건너 뛰거나 생략되지 않았다는 것을 아는 것 사이에는 상당한 차이가 있다. 가장 최근의 거래 전부에 대해 알고 있다는 것을 증명하는 것은 불가능하지만, 거래 역사에는 아무런 갭이 없었다는 것을 증명하는 것은 가능하다. EOS.IO 소프트웨어는 모든 계정에 전달되는 모든 메시지에 일련 번호를 할당함으로써 이를 용이하게 해준다. 사용자는 이러한 일련 번호를 사용하여, 특정 계정을 대상으로 하는 모든 메시지가 처리되었고, 순서대로 처리되었음을 증명할 수 있다.

[Conclusion]
[결론]

EOS.IO 소프트웨어는 입증된 개념과 모범 사례의 경험을 바탕으로 설계되었으며 블록체인 기술의 근본적인 진보를 보여준다. 이 소프트웨어는 분산형 애플리케이션을 쉽게 전개하고 관리할 수 있는, 전 세계로 확장 가능한 블록체인 공동체를 위한, 전체론적 청사진의 일부이다.