EOS 이오스 백서

[비오는날]

EOS.IO 기술 백서
- 초안 작성일: 2017년 6월 26일, 번역: 이태민 (taeminlee), 감수: 조재우, - 2017년 9월 3일, 2차개정안 @loum와 @testz가 번역.
초록: EOS.IO 소프트웨어는 탈중앙화 애플리케이션의 수직 및 수평 확장이 가능하게 디자인된 새로운 블록체인 구조를 소개합니다. 이것은 애플리케이션들(applications)을 만들 수 있는 운영체제와 유사한 구조를 생성함으로 가능합니다. 본 소프트웨어는 수백 개의 CPU 코어 또는 클러스터를 통해 계정(accounts), 인증(authentication), 데이터베이스(databases), 비동기 통신(asynchronous communication), 애플리케이션의 스케쥴링(application scheduling)을 제공합니다. 그 결과 초당 수백만 건의 트랜잭션 처리 능력을 갖추면서도, 수수료가 없고, 빠르고 쉽게 애플리케이션을 개발할 수 있는 블록체인 아키텍처 기술이 탄생했습니다.
주의사항: 본 백서에서 언급되는 암호화폐 토큰은 EOS.IO 소프트웨어를 사용할 수 있는 블록체인 상에 존재하는 토큰을 지칭합니다. 이 토큰은 EOS 분배에 사용되는 이더리움 블록체인 상에 존재하는 ERC-20 기반 토큰을 가리키는 것이 아닙니다.
저작권 소유 © 2017 block.one
누구든지 허가 없이 원래의 출처와 해당 저작권 고지가 언급된 경우 비영리적이고 교육적인 용도 (즉, 유료 또는 상업적 목적 이외의 목적)로 본 백서의 자료를 사용, 복제 또는 배포할 수 있습니다.
면책 조항: EOS.IO 기술 백서는 오직 정보 제공의 목적으로써 제공됩니다. block.one의 정확성을 보증 하지 않습니다 또는이 백서의 결론 도달하고 이 백서는 "있는 그대로" 제공 됩니다. block.one은 이 백서에서 도달한 결론의 정확성을 보장하지 않으며, 백서는 "있는 그대로" 제공되며 이는 (단, 이에 한정되지는 않음) 명시적이거나 묵시적인 것으로서 어떠한 보증도 하지 않습니다. (i) 상품성에 대한 보증, 특정 목적을 위한 적합성, 타이틀 또는 법규의 위반이 없음; (ii) 본 백서의 내용에 오류가 없거나 어떤 목적에 적합하다는 것; (iii) 그러한 내용이 제3자의 권리를 침해하지 않을 것입니다. block.one과 그 계열사는 이 백서에 포함된 정보의 사용, 참조 또는 신뢰로 인해 발생하는 모든 종류의 손해에 대해 명시적으로 책임을 지지 않습니다. 어떠한 경우에도 block.one 또는 그 계열사 책임을 지지 것입니다. 어떤 사람 또는 단체(entity)의 모든 손해, 손실, 책임, 비용 또는 어떠한 종류의 비용에 대 한 직접 또는 간접, 결과적, 보상, 부수적, 실제, 모범, 징벌적 또는 의 사용, 참조, 또는 이 백서 또는 비즈니스의 손실을 포함하되 이 제한 없이, 여기에 포함 된 내용에 대한 의존도 대한 특별 한 수익, 이익, 데이터, 사용, 영업권 또는 기타 무형 손실.
• 배경 (Background)
•  블록체인 애플리케이션의 요구사항 (Requirements for Blockchain Application)
•  수백만의 사용자 허용 (Support Millions of Users)
•  무료 사용 (Free Usage)
•  간편한 업그레이드 및 버그 해소 (Easy upgrades and Bug Recovery)
•  짧은 지연 시간 (Low Latency)
•  순차(sequential) 처리 성능 (Sequential Performance)
•  병렬 처리 성능 (Parallel Performance)
•  합의 알고리즘 (DPOS) (Consensus Algorithm)
•  트랜잭션 확인 (Transaction Confirmation)
•  트랜잭션 기반 지분 증명 (Transaction as Proof of Stake, TaPoS)
•  계정 (Accounts)
•  메시지와 처리기 (Messages &Handlers)
•  역할 기반 권한 관리 (Role Based Permission Management)
•  명명된 권한 레벨 (Named Permission Levels)
•  명명된 메시지 처리기 그룹 (Named Message Handler Groups)
•  권한 매핑 (Permission Mapping)
•  권한 검사 (Eval‎uating Permissions)
•  기본 권한 그룹( Default Permission Groups)
•  권한 검사의 병렬화 (Parallel Eval‎uation of Permissions)
•  메시지의 필수 지연 시간 (Messages with Mandatory Delay)
•  키 도난으로부터 복구 (Recovery from Stolen Keys)
•  애플리케이션의 결정론적 병렬 실행 (Deterministic Parallel Execution of Applications)
•  통신 지연 최소화 (Minimizing Communication Latency)
•  읽기 전용 메시지 처리기 (Read-Only Message Handlers)
•  다중 계정의 원자적 트랜잭션 (Atomic Transactions with Multiple Accounts)
•  블록체인 상태의 부분 검사 (Partial Eval‎uation of Blockchain State)
•  주관적 최선 스케쥴링 (Subjective Best Effort Scheduling)
•  토큰 모델과 리소스 사용 (Token Model and Resource Usage)
•  객관적 측정과 주관적 측정 (Objective and Subjective Measurements)
•  수취인 부담 (Receiver Pays)
•  리소스 허용량 위임 (Delegating Capacity)
•  토큰의 가치로부터 트랜잭션 비용의 분리 (Separating Transaction costs from Token Value)
•  상태 저장 비용 (State Storage Costs)
•  블록 보상 (Block Rewards)
•  커뮤니티 혜택 애플리케이션 (Community Benefit Applications)
•  거버넌스 (Governance)
•  계정 동결 (Freezing Accounts)
•  계정 코드 변경 (Changing Account Code)
•  약관 (Constitution)
•  프로토콜과 헌법의 개정 (Upgrading the Protocol &Constitution)
•  응급 변경 (Emergency Changes)
•  스크립트와 가상 머신 (Scripts &Virtual Machines)
•  스키마 정의 메시지 (Schema Defined Messages)
•  스키마 정의 데이터베이스 (Schema Defined Database)
•  애플리케이션과 인증 분리 (Separating Authentication from Application)
•  가상 머신 독립 아키텍처 (Virtual Machine Independent Architecture)
•  웹어셈블리 (WASM; Web Assembly)
•  이더리움 가상머신 (EVM; Ethereum Virtual Machine)
•  블록체인 간 통신 (Inter Blockchain Communication)
•  경량화된 클라이언트 검증(LCV)을 위한 머클 증명 (Merkle Proofs for Light Client Validation)
•  체인 간 통신의 지연 시간 (Latency of Interchain Communication)
•  완전성 증명 (Proof of Completeness)
•  결론 (Conclusion)
 탄생 배경 (Background)
블록체인 기술은 2008년 비트코인 화폐의 출현과 함께 시작되었으며, 이후 기업가와 개발자들이 하나의 블록체인 플랫폼에서 다양한 애플리케이션들을 지원하기 위해 블럭체인 기술의 일반화를 시도해 왔습니다.
다수의 블록체인 플랫폼이 제대로 작동하는 분산화 애플리케이션을 지원하기 위해 노력하였지만, BitShares의 분산화 거래소(2014) 및 Steem의 소셜 미디어 플랫폼(2016)과 같은 애플리케이션용 블록체인은 이미 수만 명의 일일 사용자를 가진 블록체인으로 성장하였습니다. 이는 초당 수천 건의 트랜잭션 지원, 1.5초의 지연시간과 같은 성능 향상, 사용 수수료의 제거, 현재 서비스되는 중앙 집중형 서비스와 유사한 수준의 사용자 경험 제공을 통해 가능하게 되었습니다.
현존하는 블록체인 플랫폼들은 비싼 수수료와 연산능력의 한계 때문에 블록체인의 광범위한 사용에 있어서 어려움을 겪고 있습니다.

블록체인 애플리케이션의 요구사항 (Requirements for Blockchain Application)
대중적으로 사용되기 위해서, 블록체인 위에서 돌아가는 애플리케이션은 다음의 요구사항을 만족하는 유연한 플랫폼을 갖춰야 합니다.

수백만의 사용자 허용 (Support Millions of Users)
Ebay, Uber, AirBnB, Facebook 과 같은 기존 서비스와 경쟁하기 위해서, 수천만의 일일 사용자를 수용할 수 있는 블록체인 기술이 필요합니다. 경우에 따라, 많은 사용자들이 있어야 이용할 수 없는 애플리케이션들도 있으므로 많은 사용자를 수용하는 플랫폼은 매우 중요합니다.
무료 사용 (Free Usage)
애플리케이션 개발자는 사용자들에게 무료 서비스를 제공할 수 있는 유연성이 필요하며, 사용자들은 플랫폼을 사용하거나 플랫폼의 서비스를 이용하기 위해 비용을 지불해서는 안됩니다. 사용자가 무료로 이용할 수 있는 블록체인 플랫폼이 더 널리 사용될 것입니다. 따라서, 개발자와 기업은 효과적인 수익 창출 전략을 만들 수 있습니다.

간편한 업그레이드 및 버그 해소 (Easy upgrades and Bug Recovery)
블록체인 기반 애플리케이션을 만드는 기업은 그들의 애플리케이션에 새로운 기능을 추가하고 개선할 수 있어야 합니다.
많은 소프트웨어들은 엄격한 공식적인 검사를 진행하더라도 버그가 발생합니다. 플랫폼은 애플리케이션에서 버그가 발생하였을 때 버그를 수정할 수 있을 만큼 안정적이어야 합니다.

짧은 지연 시간 (Low Latency)
좋은 사용자 경험은 수 초 이하의 지연시간의 안정적인 피드백을 필요로 합니다. 긴 지연 시간은 사용자의 불만을 일으키며, 이러한 블록체인 애플리케이션은 블록체인을 사용하지 않는 기존의 애플리케이션에 비해 경쟁력이 떨어집니다.

순차(sequential) 처리 성능 (Sequential Performance)
몇몇 애플리케이션은 순차적인 처리 단계를 거쳐야 하기 때문에 병렬 알고리즘으로 구현될 수 없습니다. 거래소(exchange)와 같은 애플리케이션들은 많은 양의 거래를 순차적으로 처리하는 충분한 순차적 성능을 요구하므로, 플랫폼은 빠른 순차 처리 성능이 필요합니다.

병렬 처리 성능 (Parallel Performance)
대규모 애플리케이션은 하나의 작업을 다수의 CPU와 컴퓨터에 작업부하를 나누어 처리할 수 있어야 합니다.

합의 알고리즘 (DPOS) (Consensus Algorithm)
EOS.IO 소프트웨어는 블록체인 애플리케이션의 성능 요구사항을 충족할 수 있는 유일한 분산 합의 알고리즘인 지분 위임 증명(DPOS; Deleteged Proof-Of-Stake)을 사용합니다. 이 알고리즘은 다음과 같이 동작합니다. 토큰 보유자는 상시 운영되는 투표 시스템을 통해 블록 생산자(block producer)를 선출하고, 누구나 블록 생산자로 참여할 수 있으며, 블록을 생산할 기회는 모든 다른 생산자들이 받은 전체 투표 중 본인이 받은 투표 비율에 따라 결정됩니다. 프라이빗 블록체인에서 관리자는 토큰을 사용하여 IT 직원을 추가하거나 제거할 수 있습니다.
EOS.IO 소프트웨어는 정확히 3초마다 블록을 만들 수 있고, 오직 한 명의 블록 생산자만이 블록을 생성할 수 있습니다. 만약 정해진 시간에 블록이 생산되지 않을 경우, 해당 시점의 블록 생성은 건너뛰게 됩니다. 1개 혹은 그 이상의 블록이 생성되지 않을(skipped) 경우, 블록체인의 생성은 6초 혹은 그 이상의 시간이 필요합니다.
EOS.IO 소프트웨어에서 블록들은 21번의 단계의 라운드로 생성됩니다. 각 라운드가 시작될 때마다, 21명의 블록 생산자가 새로 선출됩니다. 많은 득표를 받은 상위 20명의 블록 생산자가 각 라운드 마다 자동적으로 선출이 되고, 마지막(21번째) 생산자는 다른 생산자와의 상대적인 투표수에 비례하여 선출됩니다. 선택된 블럭 생성자는 블럭 생성 시간에 의해 얻어지는 의사 난수(pseudorandom number)에 따라 랜덤하게 섞여집니다. 블록 생성 순서를 섞는 것은 모든 생산자에게 균형적인 연결(balanced connectivity)을 유지하기 위한 것입니다.
생산자가 블록 생성에 실패(misses a block)하고 지난 24시간 동안 어떠한 블록을 생성하지 않았다면, 그는 블록체인에 블록 생성 참여 의사를 알려주기 전까지 블럭 생성에서 제외됩니다. 이렇게 하면 믿을 수 없는(unreliable) 사람을 블럭 생성에서 배제하므로, 놓치는 블록을 최소화하고 네트워크가 원활하게 동작하도록 합니다.
일반적인 상황에서, 지분 위임 증명(DPOS) 알고리즘을 사용하는 블록체인은 어떠한 포크(fork)도 일어나지 않습니다. 포크가 발생되면, 합의는 가장 긴 체인에 자동으로 전환됩니다. 이 방법이 동작하는 이유는 특정 블록체인 포크에 블록들이 추가되는 속도가 같은 합의를 공유하는 블록 생성자의 비율과 직접 연관되기 때문입니다. 즉, 더 많은 블록 생산자가 참여하는 블록체인이 적은 블록 생산자가 참여하는 블록체인에 비하여 빠르게 생성됩니다. 추가로, 어떠한 블록 생성자도 동시에 두 개의 포크에 블록을 생성할 수 없습니다. 만일 이러한 것이 적발되면, 해당 블록 생성자는 투표에서 제외될 것입니다. 이렇게 두개 이상의 블럭체인을 생성하는 악용자는 암호학적 증거(cryptographic evidence)에 의해 자동으로 제거될 수 있습니다.

트랜잭션 확인 (Transaction Confirmation)
일반적인 DPOS 블록체인은 100%의 블록 생산자 참여율을 가집니다. 블록의 전파(braodcasting) 시간부터 평균 1.5초의 시간이 흐르면 트랜잭션은 99.9%의 신뢰도로 확인(confirm‎)됩니다.
소프트웨어 버그, 인터넷 속도 저하 및 비정상적 블록 생산자와 같은 특수한 상황에서 두 개 혹은 그 이상의 포크가 생성될 수 있습니다. 트랜잭션를 못 바꾸도록(irreversible) 확정하기 위해서, 노드는 21명의 블록 생산자 중 15명의 확인(confirmation)을 기다릴 수 있습니다. EOS.IO 소프트웨어의 기본 설정에 따르면, 이것(트랜잭션 확인)은 보통 상황에서 45초의 시간이 걸릴 수 있습니다. 기본적으로 모든 노드는 21명 중 15명이 확인(confirmed)되면 이 블록은 바뀔 수 없고, 블록의 길이와 상관없이 다른 블럭체인(포크)로 전환되지 않습니다.
노드는 포크가 분기된 후 9초 이내에 소수 포크(minority fork)에 속해있을 가능성이 높음을 사용자에게 경고할 수 있습니다. 블록체인에 2개의 블록이 연속적으로 추가되지 않을(missed) 경우, 이 노드는 95% 확률로 소수 포크에 속합니다. 3번 연속으로 블럭이 추가되지 않을 경우, 소수 포크에 있을 확률이 99%가 됩니다. 운영자에게 무언가 잘못되었다는 사실을 신속하게 경고하기 위해 누락된(missed) 노드, 최근 참여율 및 기타 요인에 대한 정보를 활용할 안정적인 예측 모델을 생성 할 수 있습니다.
경고(warning)에 대한 대응은 비즈니스 트랜잭션의 성격에 따라 다르며, 가장 간단한 대응은 경고가 끝나는 15/21의 확인(confirmations)을 기다리는 것입니다.

트랜잭션 기반 지분 증명 (Transaction as Proof of Stake, TaPoS)
EOS.IO 소프트웨어는 모든 트랜잭션이 최근 블록 헤더의 해쉬값을 포함하도록 요구합니다. 해쉬값은 두 가지 용도로 사용됩니다.
1. 참조 블록(referenced block)이 포함되지 않은 포크에서 트랜잭션이 재실행(replay)되는 것을 방지합니다.
1. 특정 사용자와 그의 지분(stake)이 특정 (블럭체인) 포크에서 존재하는지 네트워크에 알려줍니다.
시간이 지날수록, 모든 사용자는 블록체인을 직접 확인(confirm‎)하게 되고, 이것은 위조하여 합법적 체인의 거래를 옮길 수 없으므로 위조 체인을 만드는 것을 어렵게 합니다.

계정 (Accounts)
EOS.IO 소프트웨어는 모든 계정이 2~32 글자의 읽을 수 있는 고유 이름을 가집니다. 계정 이름은 생성자가 선택합니다. 모든 계정은 생성되는 시점에 계정 정보의 저장 비용 이상의 최소 계정 잔액(minimal account balance )을 보유해야 합니다. 계정 이름은 네임스페이스(namespaces)를 지원합니다. 예를 들어, @domain 계정의 소유자만이 @user.domain을 생성할 수 있도록 합니다.
분산 환경에서, 애플리케이션 개발자는 새로운 사용자가 가입하여 계정을 생성하는 최소한의 비용을 부담해야 합니다. 일반적인 기업들은 이미 광고나 무료 서비스 제공으로 단위 사용자당 상당한 돈을 지출하고 있습니다. 이와 비교할 때 새로운 블록체인 계정에 부담하는 비용은 상대적으로 미미할 것입니다. 이미 다른 애플리케이션에 가입한 사용자는 계정을 중복하여 가입할 필요는 없습니다.

메시지와 처리기 (Messages &Handlers)
한 계정에서 다른 계정으로 구조화된 메시지(structured message)를 전송할 수 있으며, 이를 송신하였을 때 처리하는 스크립트(script)를 정의할 수 있습니다. EOS.IO 소프트웨어는 각각의 계정이 독립된 프라이빗 데이터베이스(own private database)를 주고, 자신의 메시지 처리기만이 이것에 접근하도록 허용합니다. 메시지 처리 스크립트(Message handling scripts)에서 다른 계정으로 메시지를 전송할 수도 있습니다. EOS.IO는 스마트 컨트렉트(smart contracts)를 메시지(messages)와 자동화된 메시지 처리기(automated message handlers)의 결합으로 정의합니다.

역할 기반 권한 관리 (Role Based Permission Management)
권한 관리(Permission management)는 메시지가 정상적으로 인증(authorized)되었는지 결정합니다. 가장 단순한 형태의 권한 관리는 트랜잭션의 서명 여부를 검사하는 것고, 이는 이미 필요한 서명을 알고 있을 때 가능합니다. 일반적으로 권한은 사용자와 그룹에 부여되며 이들은 구분됩니다. EOS.IO 소프트웨어는 계정별로 누가, 언제, 어떤 작업을 할 수 있는지에 대하여 세밀하고 높은 수준의 통제를 제공하는 선언적 권한 관리 시스템(declarative permission management system)을 제공합니다.
인증과 권한 관리(authentication and permission management)를 표준화하고, 애플리케이션의 비즈니스 로직과 분리하는 것이 중요합니다. 이것은 권한 관리가 범용적인 관점에서 이루어지도록 하는 도구를 개발할 수 있게 하며, 또한 성능 최적화의 큰 가능성이 열리게 합니다.
모든 계정은 다른 계정들(other accounts)과 개인키들(private keys)의 가중치 조합(weighted combination)으로 제어될 수 있습니다. 이를 통해 현실의 권한 구성 방식과 유사한 계층적 인증 구조(hierarchical authority structure)를 생성할 수 있으며, 또한 자금(funds)에 대한 다중 사용자 제어(multi-user control)를 쉽게 하도록 합니다. 다중 사용자 제어(Multi-user control)는 보안 관점에서 가장 큰 기여자(single biggest contributor)이며, 이를 올바르게 사용할 경우 해킹으로 인한 도난의 위험을 크게으로 감소시킬 수 있습니다.
EOS.IO 소프트웨어는 계정에서 키 및/또는 계정의 조합(combination of keys and/or accounts)이 특정 메시지 유형을 다른 계정으로 보낼 수 있게 정의할 수 있습니다. 예를 들어, 사용자의 소셜 미디어 계정의 키와 별도로 거래소에 접근할 수 있는 키를 가질 수 있습니다. 심지어, 다른 계정(other accounts)에 키를 할당하지 않고도 다른 계정이 사용자 계정(user's account)을 대신하여 활동할 수 있는 권한을 줄 수 있습니다.
명명된 권한 수준 (Named Permission Levels)

EOS.IO 소프트웨어에서 계정은 상위 레벨의 명명된 권한(higher level named permissions)으로부터 파생되는 명명된 권한 수준(named permission levels)을 정의할 수 있습니다. 각각 명명된 권한 수준은 인증 방식(authority)을 정의합니다. 인증은 다른 계정의 키와 명명된 권한 레벨의 자유로운 조합에 대한 임계 다중서명 확인(threshold multi-signature check)입니다. 예를 들면, 계정의 "친구"권한 수준을 설정하면 그 계정의 친구 중 아무나 그 계정을 동등하게 제어 할 수 있습니다.
다른 예제로서 Steem 블록체인이 있으며, 여기에는 3가지 하드 코딩된 명명된 권한 수준을 가지고 있습니다. 즉, 소유자(owner), 활동(active), 포스팅(posting) 입니다. 포스팅 권한은 투표나 글쓰기와 같은 소셜 활동을 할 수 있으며, 활동 권한은 소유자 변경을 제외한 모든 활동이 가능합니다. 소유자(owner) 권한은 콜드 스토리지(cold storage)를 의미하며 모든 활동이 가능합니다. EOS.IO는 steem의 개념을 일반화하여 각각의 계정 소유주가 활동 그룹을 포함하는 독자적인 계층(hierarchy)을 정의할 수 있습니다.
명명된 메시지 처리기 그룹 (Named Message Handler Groups)
EOS.IO 소프트웨어는 각각의 계정이 독자적인 메시지 처리기를 명명(named)하고 중첩 그룹화(nested groups)하는 것을 허용합니다. 명명된 메시지 핸들러 그룹(named message handler groups)들은 자신의 권한 수준을 설정할 때 다른 계정으로부터 참조될 수 있습니다.
최상위 레벨의 메시지 처리기 그룹은 계정 이름이며, 가장 낮은 레벨은 특정 계정으로부터 받은 개별적인 메시지 타입(individual message type)입니다. 이러한 그룹들은 다음과 같이 참조될 수 있습니다. @계정명.그룹A.하위그룹B.메시지타입 (@accountname.groupa.subgroupb.MessageType)
이러한 모형을 이용하여 거래소의 계약을 거래 단위로 그룹화하여 입금과 출금을 별개로 다룰 수 있습니다. 이러한 거래 계약의 그룹화는 거래소의 사용자에게 편의성을 제공합니다.
권한 매핑 (Permission Mapping)
EOS.IO 소프트웨어는 계정별로 어떠한 계정의 명명된 메시지 처리기 그룹과 보유하고 있는 명명된 관리 수준 간의 매핑을 진행할 수 있도록 합니다. EOS.IO 소프트웨어는 각 계정이 어떤 계정의 명명 된 메시지 처리기 그룹(Named Message Handler Group of any account)과 그들 자신의 명명된 권한 레벨(their own Named Permission Level) 간의 매핑을 정의 할 수 있습니다. 예를 들어, 계정 소유자는 해당 계정 소유자의 소셜 미디어 애플리케이션을 "친구" 관리 그룹과 매핑할 수 있습니다. 이 매핑을 통해, 어떤 친구들이라도 계정 소유자처럼 계정 소유자의 소셜 미디어에 글을 포스팅할 수 있습니다. 친구들이 계정 소유자처럼 글을 포스팅할지라도, 친구들 자신의 키로 메시지에 서명합니다. 이로서, 어떤 친구가 계정을 사용했고 그가 무엇을 하였는지 알 수 있습니다.
권한 검사 (Eval‎uating Permissions)
@앨리스가 @밥에게 "액션" 타입의 메시지를 보낸다고 가정해봅시다. EOS.IO 소프트웨어는 먼저 @앨리스가 @밥.그룹A.하위그룹.액션 처리기에 대한 권한을 매핑하였는지 확인합니다. 만약 매핑되어 있지 않다면, 매핑이 발견될 때 까지 @bob.groupa.subgroup, @bob.groupa, 그리고 @bob의 순서로 검사합니다. 만약 메시지 처리기에 대한 매핑이 없으면**@alice.active**로 명명된 권한 그룹으로 매핑된 것을 가정합니다.
만약 매핑이 확인이 되면, 임계 다중서명 절차(threshold multi-signature process)와 명명된 권한에 대한 인증(authority associated with the named permission)을 사용하여 서명된 인증을 검증합니다. 실패할 경우, 상위 권한으로 검사를 수행하며 최종적으로 소유자 권한인 @alice.owner로 검사를 진행합니다.

 기본 권한 그룹( Default Permission Groups)
모든 계정은 모든 것을 할 수 있는 "소유자(owner)" 권한과 소유자 변경을 제외한 모든 것이 가능한 "활동(active)" 권한을 가집니다. 그 외의 다른 권한은 "활동(active)"으로부터 파생됩니다.
권한 검사의 병렬화 (Parallel Eval‎uation of Permissions)
권한 검사 절차(permission eval‎uation process)는 "읽기"이며, 트랜잭션에 의한 권한의 변경은 블록이 종료될 때까지는 어떠한 영향도 발휘하지 못합니다. 이것은 모든 트랜잭션의 모든 키와 권한 검사가 병렬적으로 진행될 수 있음을 뜻합니다. 더 나아가, 롤백해야 하는 값비싼 애플리케이션 로직을 시작하지 않고도, 신속한 권한 검사의 가능함을 의미합니다. 마지막으로, 이는 보류 중인 트랜잭션이 수신될 때 트랜잭션 권한을 평가할 수 있으며, 이미 승인된 트랜잭션은 다시 검사할 필요가 없습니다.
전체적인 관점에서, 권한 검사(permission verification)는 트랜잭션에 필요한 연산의 많은 비중을 차지합니다. 그러므로 권한 검사를 읽기 연산만으로 구성하여 병렬화하면 전체 성능이 크게 향상됩니다.
메시지 로그(message log)로부터 블록체인의 결정된 상태(deterministic state)로 재구축(replay, 새 노드가 블럭체인을 처음부터 받는 것)하는 과정에서 권한 검사를 다시 수행할 필요는 없습니다. 정상적인 블록에 트랜잭션이 포함되어 있으므로, 이 과정은 넘어갈(skip) 수 있습니다. 이것은 점점 더 커지는 블록체인의 재구축에 드는 계산 비용을 큰 폭으로 감소시킬 수 있습니다.
메시지의 필수 지연 시간 (Messages with Mandatory Delay)
시간은 보안의 핵심 요소입니다. 대부분의 경우, 개인 키(private key)가 도난당한 경우 사용되기 전에는 이를 알기가 어렵습니다. 인터넷에 연결된 컴퓨터에 보관되는 키를 사용하는 애플리케이션을 일상적으로 사용하는 사람들에게 시간 기반의 보안(time based security)은 더욱 중요합니다. EOS.IO 소프트웨어는 애플리케이션 개발자가 특정 메시지가 블록에 포함되었지만 적용되기 이전에 지정한 시간 만큼 기다리도록 할 수 있습니다. 이 시간 동안에 이 메시지는 취소 가능합니다.
사용자는 이메일이나 단문으로 메시지가 전송되었음을 안내받을 수 있습니다. 만약 그들이 해킹을 당한 것이라면, 그들은 계정 복구 절차를 통해 계정 복구와 메시지 철회를 할 수 있습니다.
필수 지연 시간은 작업의 중요도에 따라 다릅니다. 커피 한잔을 구매하는 것은 지연시간을 갖지 않아 몇 초 내로 취소 불가능한 상태가 되며, 집을 사는 것이라면 72시간의 거래 완료 조정 기간을 둘 수 있습니다. 전체 계정을 새로운 권한(new control)으로 이전하는 것은 30일의 기간을 둘 수도 있습니다. 애플리케이션 개발자와 사용자가 이 지연 시간을 정할 수 있습니다.
키 도난으로부터 복구 (Recovery from Stolen Keys)
EOS.IO 소프트웨어는 사용자의 키가 도난당하였을 때, 계정에 대한 복구 작업을 제공합니다. 계정 소유자는 최근 30일 이내에 사용했 소유자의 키를 가지고 지정된 계정 복구 협력자와 협력하여 그 계정에 대한 자신의 키를 재설정할 수 있습니다. 계정 복구 협력자는 소유자의 허가 없이 계정에 작업할 수 없습니다.
키를 가진 해커는 이미 계정을 제어할 수 있기 때문에, 복구 프로세스를 시도하여 얻을 수 있는 것이 없습니다. 복구 프로세스에 진입하여도 복구 협력자는 추가적인 신분 증명이나 2채널 인증(핸드폰이나 이메일)을 요구할 것입니다. 이 과정에서 해커를 위험하게 하거나 그가 아무것도 얻지 못하게 할 수 있습니다.
이 과정은 단순한 다중서명 합의(multi-signature arrangement)와 매우 다릅니다. 다중서명 트랜잭션의 경우, 모든 트랜잭션에 참여하는 별도의 회사가 존재하는 것입니다. 복구 처리 과정을 이용하면, 복구 협력자는 복구과정에만 관여하며 트랜잭션에 관해서는 어떠한 영향력도 행사하지 않습니다. 이로 인해 참여자들에 대한 비용과 법적 책임을 큰폭으로 감소시킬 수 있습니다.
애플리케이션의 결정론적 병렬 실행 (Deterministic Parallel Execution of Applications)
블록체인 합의(consensus)는 결정론적 행위(재현 가능한, deterministic behavior)에 달려있습니다. (결정론적: 어느때나 같은 입력에 같은 결과를 얻는 것) 이는 모든 병렬 실행은 뮤텍스(mutex)나 다른 잠금 기본요소(locking primitive) 없이 수행되어야 함을 뜻합니다. (뮤텍스: mutualy exclusive라는 잠금임) 잠금(lock)이 없다면, 모든 계정이 자신의 프라이빗 데이터베이스에만 읽기/쓰기를 하는 다른 방법이 있어야 합니다. 또한 각 계정이 메시지들을 순차적으로 처리하며, 연산의 병렬성이 계정별로 처리되는 것을 뜻합니다.
EOS.IO 소프트웨어를 사용할 때, 블록 생산자가 메시지를 독별적인 쓰레드(threads)로 구성하여 이들이 병렬로 평가되도록 합니다. 각 계정의 상태(state)는 전달받은 메시지(messages)에만 의존합니다. 블록 생산자들은 실행 스케쥴을 만들고, 이는 결정론적으로 실행됩니다. 다만, 이 스케쥴을 만드는 과정은 결정론적일 필요가 없습니다. 이는 블록 생산자가 트랜잭션을 스케쥴링할 때 병렬 알고리즘을 활용할 수 있음을 뜻합니다.
스크립트가 새로운 메시지를 만들 때, 바로 전달되지 않고 다음 사이클(cycle)에 전달되도록 스케쥴을 구성하는 것을 부분적 병렬 실행(Part of parallel execution)이라 합니다. 메시지를 바로 전달할 수 없는 이유는 수신자(receiver)가 다른 쓰레드로 인해 자신의 상태(state)가 변경될 수 있기 때문입니다.
통신 지연 최소화 (Minimizing Communication Latency)
지연 시간(latency)은 한 계정에서 다른 계정으로 메시지를 보내고 응답을 받기까지 걸리는 시간입니다. 기술적 목표는 두 계정 사이의 한 블록 안에서 메시지의 교환이 앞뒤로 이루어지고, 메시지의 간격이 3초 이내에 들어가게 하는 것입니다. 이것을 이루기 위해, EOS.IO 소프트웨어는 각 블록을 사이클(cycles)로 나눕니다. 각 사이클에는 여러 개의 스레드(threads)가 있으며, 각 스레드는 트랜잭션들의 목록(list of transactions)을 포함합니다. 각 트랜잭션(transaction)은 전달하는 메시지의 집합(set of messages)으로 구성됩니다. 이러한 구조는 트리(tree) 형태로 시각화가 가능하며, 레이어(alternating layers) 단위로 순차(sequentially) 처리되거나 병렬(parallel) 처리됩니다.
    블록(Block)

      사이클(Cycles) (순차 처리)

        쓰레드(Threads) (병렬 처리)

          트랜잭션(Transactions) (순차 처리)

            메시지(Messages) (순차 처리)

              수신자 및 계정 알림(Receiver and Notified Accounts) (병렬 처리)

하나의 사이클에서 생성된 트랜잭션들은 이어지는 어느 사이클 혹은 블록으로 전달됩니다. 블록 생산자는 블록에 지정된 시간(3초)이 지나거나 더 전달할 트랜잭션이 없을 때까지 사이클을 계속 추가합니다.
정적 분석(static analysis)으로 한 블록에서 동일 사이클에 같은 계정을 수정하는 2개 이상의 쓰레드를 가진 트랜잭션이 없는지 알 수 있습니다. 불변성(invariant)이 유지되면, 하나의 블록은 여러 개의 쓰레드로 병렬 처리할 수 있습니다.
읽기 전용 메시지 처리기 (Read-Only Message Handlers)
어떤 계정은 내부 상태의 수정하지 않고 통과/실패(pass/fail)으로 메시지를 처리할 수 있습니다. 이러면 특정 사이클에 하나 이상의 쓰레드가 포함될 경우 해당 작업을 수행하는 메시지 처리기는 병렬 처리가 가능합니다. 이러면, 특정 계정에 대한 읽기 전용 메시지 처리기(read-only message handlers)가 특정 사이클에 하나 이상의 스레드를 포함하고 있다면, 이러한 처리기는 병렬로 처리될 수 있습니다.
다중 계정의 원자적 트랜잭션 (Atomic Transactions with Multiple Accounts)
종종 메시지의 전달 및 적용이 다수의 계정에서 원자성(atomically)으로 보장되어야 합니다. 이 경우, 두 메시지는 하나의 트랜잭션에 위치하고, 두 계정은 같은 쓰레드에 할당되며, 메시지는 순차적으로 적용됩니다. 이 방식은 성능 면에서 이상적이지 않습니다. 사용량을 "청구(billing)"를 수행할 때, 트랜잭션에 참고된 계정의 수 만큼 비용이 청구됩니다.
성능과 비용 때문에서, 2개 이상의 많이 사용되는 계정들(heavily utilized accounts)이 참여하는 원자적 작업(atomic operations)을 줄이는 것이 좋습니다.
블록체인 상태의 부분 검사 (Partial Eval‎uation of Blockchain State)
블록체인 기술의 확장성을 보장하려면 구성 요소는 모듈화되어야 합니다. 애플리케이션의 일부만 사용할 때 전체를 다 구동할 필요는 없습니다.
거래소 애플리케이션의 개발자(exchange application developer)는 풀 노드(full node)를 실행하여 거래소 상태(exchange state)를 사용자들에게 보여주어야 합니다. 이러한 거래소 애플리케이션은 소셜 미디어 애플리케이션과 연동하여 동작할 필요가 없습니다. EOS.IO 소프트웨어는 풀 노드가 애플리케이션 중 일부를 구동할 수 있도록 허용합니다. 애플리케이션의 상태가 전달받은 메시지를 통해 결정되기 때문에, 다른 애플리케이션에서 전달된 메시지 전송은 안전하게 무시됩니다.
이것은 다른 계정과의 통신에 중요한 의미를 가집니다. 가장 중요한 것은 다른 계정의 상태가 동일한 머신(same machine)에서 접근할 수 있다고 가정해서는 안됩니다. 또한 한 계정이 다른 계정을 동기적으로 호출하도록 허용하는 "잠금(locks)"을 사용하려는 경우에도 다른 계정이 메모리에 상주하지 않으면이 디자인 패턴이 손상된다는 것을 의미합니다.
계정사이의 상태 통신(state communication)은 블록체인의 메시지로 전달되어야 합니다.
주관적 최선 스케쥴링 (Subjective Best Effort Scheduling)
EOS.IO 소프트웨어는 블록 생산자가 어떤 다른 계정으로 어떤 메시지를 보낼지에 대하여 강제할 수 없습니다. 각각의 블록 생산자는 계산 복잡도와 트랜잭션을 처리하기 위한 요구 시간에 대한 주관적인 측정을 수행합니다. 이것은 트랜잭션이 사용자에 의해 생성되거나 스크립트에 의해 자동으로 생성될 때 모두 적용됩니다.
EOS.IO 소프트웨어는 네트워크 관점에서 모든 트랜잭션에 대해 0.01ms의 시간이 걸리든지 10ms가 걸리는 것에 상관없이 같은 연산 대역폭(computational bandwidth) 비용을 청구합니다. 하지만 블록 생산자들은 개별적인 측정 알고리즘을 이용하여 리소스 사용 비용을 계산할 수 있습니다. 그러나 소프트웨어를 사용하는 각 블록 제작자는 자체 알고리즘 및 측정을 사용하여 리소스 사용을 계산할 수 있습니다. 물론 이 경우에도 다른 블록 생산자는 그 트랜잭션이 적합하다고 판단하여 처리할 수 있습니다. 블록 생산자가 트랜잭션 또는 계정이 과도한 양의 계산 용량을 소비했다고 결론을 내면, 블록을 생성할 때 그들은 단순히 그 트랜잭션을 거부합니다. 그러나 다른 블록 제작자가 유효하다고 간주하면 그 트랜잭션을 처리할 것입니다.
일반적으로 한명의 블록 생산자라도 트랜잭션이 리소스 사용 제한을 넘지 않아 적합하다고 간주하면 다른 블록 생산자도 이를 승인하게 됩니다. 그러나, 이 경우 그 트랜잭션을 받아주는 블록 생산자를 찾기까지 1분 가까운 시간이 소요될 수 있습니다. (설명: 21명이 3초 간격으로 블록을 생산하므로)
간혹 어떤 블록 생산자가 허용 가능한 범위를 몇 배나 넘는 트랜잭션을 블록에 포함시킬 수도 있습니다. 이 경우 다음 블록 생산자는 그 블록을 거절해버릴 수 있으며, 승인과 거절이 동률인 상태(tie)이면 다음 블록 생산자에 의해 이것이 결정됩니다. 이는 큰 블록(large block)이 네트워크 전파 지연을 발생시키는 경우와 같습니다. 커뮤니티는 이상 패턴(pattern of abuse)을 파악하고, 이러한 나쁜 생산자(rogue producer)에게 표를 주지 않을 것입니다.
이러한 블록 생산자의 주관적 평가가 있기에 블록체인은 정확하고 명확한 실행 시간 계산의 측정을 하지 않아도 됩니다. 이러한 설계로, 합의를 어기지 않고 최적화 기회를 극적으로 증가시키는 명령(instructions)을 정확하게 집계(count)할 필요가 없습니다.

토큰 모델과 리소스 사용 (Token Model and Resource Usage)
주의사항: 본 백서에서 언급되는 암호화폐 토큰은 EOS.IO 소프트웨어를 사용할 수 있는 블록체인 상에 존재하는 토큰을 지칭합니다. 이 토큰은 EOS 분배에 사용되는 이더리움 블록체인 상에 존재하는 ERC-20 기반 토큰을 가리키는 것이 아닙니다.
모든 블록 체인은 자원이 제한되어 있으므로 악용을 막기위한 시스템이 필요합니다. EOS.IO를 사용하는 블록체인과 함께, 응용 프로그램에서 사용 하는 리소스의 3 개의 넓은 종류가 있다: EOS.IO 소프트웨어를 사용하는 블록체인에서, 애플리케이션에서 소비하는 자원은(resources)은 세 가지의 넓게 분류(class)합니다.
1. 대역폭과 로그 저장소(Log Storage) (디스크)
1. 연산과 연산 백로그(backlog) (CPU)
1. 상태 저장소 (램)
대역폭과 연산은 즉시 사용과 장기 사용의 2개의 구성요소로 구분됩니다. 블록 체인은 모든 메시지의 로그를 관리하며,이 로그는 모든 완전노드(full nodes)에 의해 저장되고 다운로드됩니다. 메시지의 로그( log of messages)를 가지고, 모든 애플리케이션의 상태를 재구축할 수 있습니다.
메시지 로그로부터 상태를 재쟁성하기 위해 수행되는 계산을 연산 부채(computational debt)라 합니다. 만약에 연산 부채가 과다하게 증가하면, 블록체인 상태의 스냅샷(snapshot)을 저장하고 과거 이력을 제거하는 것이 필요합니다. 만약에 연산 부채가 너무 빠르게 증가하면, 때론 1년의 트랜잭션을 재현하기 위해 6개월의 시간이 필요할 수도 있습니다. 이는 매우 치명적이므로 연산 부채는 주의 깊게 관리되어야 합니다.
블록체인 상태 저장소(blockchain state storage)는 애플리케이션 로직이 접근할 수 있는 정보입니다. 이는 계정 잔액(account balances)과 주문서(order books)와 같은 정보를 가지고 있습니다. 만약에 애플리케이션이 특정 상태를 읽지 않는다면, 이것을 저장할 필요는 없습니다. 예를 들어, 블로그 작성 글의 내용과 댓글 내용은 애플리케이션 로직이 읽지 않으므로 블록체인 상태에 저장할 필요가 없습니다. 반면에 글/댓글의 존재 여부와 투표 횟수와 다른 특성들은 블록체인의 상태에 기록되어야 합니다.
블록 생산자는 그들이 가용 가능한 대역폭, 연산 능력, 상태 허용량을 알려주어야 합니다. EOS.IO 소프트웨어는 각각의 계정이 3일간 계약에서 보유한 토큰 양에 비례하는 자원량의 사용을 허용합니다. 예를 들어, EOS.IO 기반의 블록체인이 출시된 후, 한 계정이 전체 토큰의 1%를 보유하고 있다면 해당 계정은 전체 상태 저장소의 1%를 사용할 수 있습니다.
EOS.IO 소프트웨어에서 대역폭과 연산 허용량은 일시적(사용하지 못한 리소스를 나중에 다시 쓸 수 없음)이므로 이들은 부분 예비 예약 기준(fractional reserve basis)에 따라 할당됩니다. EOS.IO의 알고리즘은 스팀에서 사용하는 대역폭 사용량을 제한(rate-limit bandwidth usage)하는 알고리즘과 유사합니다.

객관적 측정과 주관적 측정 (Objective and Subjective Measurements)
연산 사용량의 측정(instrumenting computational usage)은 성능과 최적화에 큰 영향을 미칩니다. 그러므로 모든 리스스 사용 제한은 궁극적으로 블록 생산자의 개별적인 측정 방식과 알고리즘에 의하여 주관적으로 이루어져야 합니다.
즉, 객관적으로 측정 가능한 것들도 있습니다. 메시지 전달 수와 내부 데이터베이스에 저장하는 데이터의 양은 객관적으로 측정할 수 있습니다. EOS.IO 소프트웨어는 블록 생산자가 객관적 측정에 대해 동일한 알고리즘을 적용할 수 있게 합니다. 하지만 주관적인 측정보다 엄격한 주관적인 알고리즘을 적용 할 수 있습니다.

수취인 부담 (Receiver Pays)
전통적으로, 사업을 하기 위해서는 오피스 공간, 연산 능력, 그 외의 요소들을 구매해야 하며 여기에서 비용이 발생합니다. 고객이 특정 물품을 구매할 때, 벌어들인 이익의 일부는 이러한 사업 비용을 결재할 때 사용됩니다. 마찬가지로, 어떤 웹 사이트도 호스팅 비용을 충당하기 위해 방문자에게 웹 사이트 방문을 위한 소액 결제를 요구하지 않습니다. 그러므로, 탈중앙화 애플리케이션 역시 고객으로 하여금 블록체인을 사용할 때 블록체인 사용료를 요구하여서는 안 됩니다.
EOS.IO 소프트웨어를 사용하는 블록 체인은 사용자가 블록체인을 사용하기 위해 직접 지불 할 필요가 없으므로, 제품의 자체 수익 창출 전략(own monetization strategy for its products)을 결정하는 비즈니스를 제한하거나 방지하지 않습니다
리소스 허용량 위임 (Delegating Capacity)
EOS.IO 소프트웨어를 사용하여 블록체인을 출시하였을 때, 필요한 대역폭보다 많은 토큰을 가지고 있는 소유자를 가정해 봅시다. 해당 소유자는 남은 대역폭을 다른 사람에게 양도하거나 빌려줄 수 있습니다. EOS.IO의 블록 생산자는 이러한 대역폭 허용량의 양도를 인지할 수 있으며, 이에 맞추어 대역폭을 재할당합니다.

토큰의 가치와 트랜잭션 비용의 분리 (Separating Transaction costs from Token Value)
EOS.IO 소프트웨어의 큰 장점 중 하나는 애플리케이션에서 사용할 수 있는 대역폭의 양이 토큰 가격에 완전히 독립적이라는 것입니다. 만약에 애플리케이션 소유자가 충분한 양의 토큰을 가지고 있다면, 애플리케이션은 할당된(fixed) 상태와 대역폭 사용량의 범위 안에서 제한 없이 실행됩니다. 이 경우, 개발자와 사용자는 토큰 시장의 가격 변동에 영향을 받지 않으므로 가격 추이에 의존하지 않습니다. 다른 말로, EOS.IO 소프트웨어에서 블록 생산자는 토큰의 가치와 무관하게 토큰 당 사용가능한 대역폭, 연산 능력, 저장 능력을 자연스럽게 증기시킬 수 있습니다.
EOS.IO 소프트웨어는 블록 생산자가 블록을 생성할 때마다 보상으로 토큰을 제공합니다. 토큰의 가치는 블록 생산자가 구매할 수 있는 대역폭, 저장소, 계산량에 영향을 줍니다. 이러한 모델은 증가하는 토큰 값을 활용하여 네트워크 성능을 향상시킵니다.

상태 저장 비용 (State Storage Costs)
대역폭과 연산 능력은 위임할 수 있지만, 어플리케이션 개발자는 애플리케이션 상태가 제거되기 전까지 애플리케이션 상태 저장소(storage of application state)를 위한 토큰을 보유해야 합니다. 만약에 상태가 영원히 유지된다면, 해당 토큰은 순환하지 못하게 효과적으로 제거됩니다.
모든 사용자 계정은 어느 정도의 저장 공간이 필요합니다. 그러므로 모든 계정은 최소한의 잔액을 가지고 있어야 합니다. 네트워크의 저장 용량이 증가하면 요구되는 최소 잔액은 줄어들 것입니다.

블록 보상 (Block Rewards)
EOS.IO 소프트웨어는 블록이 생성될 때마다 블록 생성자에게 보상으로 토큰을 줍니다. 생성되는 토큰의 양은 블록 생산자들이 제출한 요구 금액의 중앙값으로 결정됩니다. EOS.IO 소프트웨어는 생산자 보상의 총량이 연 토큰 증가분의 5%를 넘지 못하도록 제한될 수 있습니다.

커뮤니티 혜택 애플리케이션 (Community Benefit Applications)
블록 생산자를 선출함과 더불어, EOS.IO 소프트웨어의 사용자들은 3개의 커뮤니티 애플리케이션(스마트 컨트렉트)을 선출할 수 있습니다. 이 3개의 커뮤니티 애플리케이션은 설정된 연간 토큰 공급량에서 블록 생산자에게 지급한 토큰을 제외한 토큰을 받게 됩니다. 이 스마트 컨트렉트들이 받는 토큰의 양은 각 어플리케이션이 토큰 소유자들로부터 받은 투표 수에 비례하여 결정됩니다. 선정된 애플리케이션 혹은 스마트 컨트렉트는 토큰 소유자들의 투표 결과에 따라 바뀔 수 있습니다.

거버넌스 (Governance)
거버넌스는 사람들이 소프트웨어 알고리즘으로 결정할 수 없는 주관적 문제에 대하여 합의를 이루는 과정을 말합니다. EOS.IO 소프트웨어는 블록 생산자가 가지고 있는 영향력을 효과적으로 행사하는 거버넌스 절차를 구현합니다. 정의된 가버넌스 과정의 부재로 인해, 이전의 블록체인들은 즉흥적이고 비공식적이고 때로는 예측할 수 없는 결과를 발생시키는 논란을 일으키는 거버넌스 방법에 의존했습니다.
EOS.IO 소프트웨어는 블록 생산자에게 그 권한을 위임한 토큰 소유자로부터 권한이 발생됨을 인지하고 있습니다. 블록 생산자는 계정을 동결하고, 결함이 있는 애플리케이션을 업데이트하며, 기본 프로토콜을 변경하는 하드포크를 제안하는 제한적이면 확인된 권한을 가집니다.
블록 생산자를 선출하는 것은 EOS.IO 소프트웨어에 내장되어 있습니다. 블록체인의 모든 변경사항은 블록 생산자의 승인을 받아야 합니다. 만약에 블록 생산자들이 토큰 소유자들이 원하는 변경을 거부하면 그들은 낙선될 수 있습니다. 블록 생산자가 토큰 소유자의 허가 없이 변경하면, 모든 비생산 풀 노드 검사자(non-producing full-node validators)(거래소 등)들은 이 변경을 거부할 것입니다.

계정 동결 (Freezing Accounts)
가끔 스마트 컨트렉트는 비정상적이거나 예측하지 못한 방식으로 동작하여 의도했던 기능이 동작하지 않을 수 있습니다. 이외에도 비정상적인 양의 리소스를 소비하는 취약점(exploit)으로 애플리케이션이나 계정에 문제를 발견할 수 있습니다. 이러한 문제점이 발생했을 때, 블록 생산자는 이러한 상황을 바로 잡을 권한을 가집니다.
모든 블록체인의 블록 생산자들은 블록에 포함되는 트랜잭션을 선택하는 권한을 가지고 있으며, 이를 이용하여 계정을 동결할 수 있습니다. EOS.IO 소프트웨어는 활성화된 블록 생산자들 간의 17/21 투표를 통해 특정 계정에 대한 동결할 수 있는 권한을 가집니다. 만약에 블록 생산자들이 이 기능을 악용한다면, 그들은 투표에서 제외되고 동결된 계정은 복원될 것입니다.

계정 코드 변경 (Changing Account Code)
다른 모든 수단이 실패하고 "멈추지 않은 애플리케이션"이 예측할 수 없이 동작한다면 EOS.IO 소프트웨어는 블록 생산자들이 전체 블록체인의 하드 포크 없이 계정의 코드를 바꾸는 것을 허용합니다. 계정 동결과 유사하게, 코드의 이런 변경은 선출된 블록 생산자들 간의 17/21 투표가 필요합니다.

헌법 (Constitution)
EOS.IO 소프트웨어는 블록체인에서 P2P 서비스 약정을 체결하거나, 서명 한 사용자 간의 구속력있는 계약인 "헌법"을 만드는 것이 가능합니다. 헌법으로 코드로 제약을 가하기 어려운 사용자 간의 의무를 규정하며, 상호 간의 관할권을 확립하고 법률을 제정함으로 분쟁 해결을 쉽게 합니다. 이 헌법의 내용은 코드에 의해 완전히 시행될 수없는 사용자 간의 의무를 정의하고 상호 인정 된 다른 규칙과 함께 관할권과 준거법 선택을 확립하여 분쟁 해결을 용이하게 합니다. 네트워크로 전파되는 모든 트랜잭션은 약관의 해시(hash)를 서명에 포함해야 하며, 이를 통해 서명자가 명시적으로 계약에 구속되도록 합니다.
약관은 사람이 읽을 수 있는 형식으로 소스코드 프로토콜의 의도를 정의합니다. 이를 통해 오류가 발생하였을 때, 버그와 기능의 차이를 인식할 수 있도록 하고 커뮤니티가 수정사항이 적합한지 여부를 판단하도록 해줍니다.

프로토콜과 헌법의 개정 (Upgrading the Protocol &Constitution)
EOS.IO 소프트웨어는 정식 소스 코드 및 헌법으로 규정되는 프로토콜의 절차를 규정하며, 다음의 절차로 개정할 수 있습니다.
1. 블록 생산자들은 약관의 개정을 제안하고 17/21 승인을 받습니다.
1. 블록 생산자들은 17/21 승인을 30일간 유지합니다.
1. 모든 사용자는 새 약관의 해시를 사용하여 거래에 서명해야 합니다.
1. 블록 생산자들은 약관의 변화를 반영하도록 소스 코드의 변경을 채택하며, git 커밋의 해시값을 이용하여 블록체인에 이를 제안합니다.
1. 블록 생산자들은 17/21 승인을 30일간 유지합니다.
1. 코드 변경은 7일간의 소스코드 적용 유예기간을 주며, 7일이 지난 이후 적용됩니다.
1. 새 코드로 업그레이드하지 않은 노드는 강제로 종료됩니다.
EOS.IO 소프트웨어의 기본 설정에 따르면, 새로운 기능을 추가하는 블록체인의 업그레이드 작업은 2달이 걸립니다.

응급 변경 (Emergency Changes)
치명적인 버그나 공격자로 인한 보안 문제가 발생할 경우, 블록 생산자는 업그레이드 과정을 빠르게 진행할 수 있습니다. 일반적으로 새로운 기능을 도입하거나 치명적이지 않은 버그를 수정하기 위해 업그레이드를 빠르게 하는 것은 헌법에 어긋납니다.
스크립트와 가상 머신 (Scripts &Virtual Machines)
EOS.IO 소프트웨어는 인증된 메시지를 계정으로 전달하는 과정을 조정하는 최초이자 가장 중요한 플랫폼입니다. 스크립트 언어와 가상 머신(virtual machine)의 세부 내용은 EOS.IO의 기술 설계로부터 독립된 세부 구현 사항입니다. 어떠한 언어나 성능을 보장하는 샌드박스 처리되며 결정론적으로 동작하는 가상 머신이든지 EOS.IO 소프트웨어 API와 통합할 수 있습니다.

스키마 정의 메시지 (Schema Defined Messages)
계정 간의 모든 메시지는 블록체인 합의 상태의 일부인 스키마(schema)에 따라 정의됩니다. 이 스키마는 바이너리와 JSON 형식의 메시지 사이의 경계 없는(seamless) 대화를 허용합니다.

스키마 정의 데이터베이스 (Schema Defined Database)
데이터베이스 상태는 유사한 스키마를 이용하여 정의됩니다. 모든 애플리케이션에서 저장되는 모든 데이터는 사람이 읽을 수 있는 JSON으로 처리될 뿐만 아니라 효율적인 바이너리 형태로 저장 관리되는 것이 보장됩니다.

애플리케이션과 인증 분리 (Separating Authentication from Application)
병렬 처리 효율의 극대화와 트랜잭션 로그(transaction log)로부터 애플리케이션 상태(application state)를 다시 생성할 때의 과다 연산( computational debt)을 최소화하기 위하여, EOS.IO는 인증 방법(authentication logic)을 세 가지로 분리합니다.
1. 메시지의 내적 일관성(internal consistency) 검증
1. 모든 전제 조건(preconditions )의 유효성 검증
1. 애플리케이션 상태( application state)의 변경
메시지의 내적 일관성 검증(internal consistency)은 읽기 연산으로만 구성되며, 블록체인 상태(blockchain state)에 대한 접근을 요구하지 않습니다. 이는 최대한의 병렬성을 가질 수 있음을 뜻합니다. 필요 잔액(required balance)과 같은 전제 조건을 검증하는 것은 읽기 연산이므로 이것은 병렬 처리를 할 수 있습니다. 오직 애플리케이션 상태의 변경만 쓰기 접근을 요구하고, 이것은 각각의 애플리케이션마다 순차적으로 처리되어야 합니다.
인증(authentication)은 메시지의 적용 가능 여부를 검증하는 읽기 연산 작업입니다. 애플리케이션은 실제 작업을 수행합니다. 두 가지 계산은 실시간으로 수행되어야 하지만 트랜잭션이 블록체인에 포함되었다면 더 이상 인증 작업을 수행할 필요가 없습니다.
가상 머신 독립 아키텍처 (Virtual Machine Independent Architecture)
EOS.IO 소프트웨어의 목적은 다수의 가상 머신을 지원하고, 필요에 따라 새로운 가상 머신을 추가하는 것입니다. 그러므로 본 백서에서는 특정 언어나 가상머신에 세부적인 내용에 관하여 기술하지 않습니다. 즉, 현재 EOS.IO 소프트웨어 기반 블록 체인과 함께 사용되기 위해 평가 중인 가상 머신은 2개입니다.

웹어셈블리 (WASM; Web Assembly)
웹 어셈블리는 고성능의 웹 애플리케이션을 제작하기 위하여 새로이 등장한 웹 표준입니다. 웹 어셈블리를 일부 수정하여 결정론적이며 샌드박스인 형태로 만들 수 있습니다. 웹 어셈블리의 장점은 업계의 광범위한 지원을 받는 것과 친숙한 언어인 C나 C++로 컨트렉트를 개발할 수 있습니다.
이더리움 개발자들은웹 어셈블리를 샌드박싱(sandboxing)하고 결정론적으로 수정하여 Ethereum flavored Web Assembly (EWASM) 으로 만들고 있습니다. EWASM은 EOS.IO 소프트웨어로 쉽게 적용하고 통합될 수 있습니다.

이더리움 가상 머신 (EVM; Ethereum Virtual Machine)
이 가상머신은 현존하는 대부분의 스마트 컨트렉트를 구동할 수 있으며, 이를 이용하여 그들의 작업물을 EOS.IO 블록체인에 적용할 수 있습니다. EVM의 컨트렉트는 샌드박스 안에서 구동되며, 약간의 조정을 거치면 EOS.IO의 블록체인 애플리케이션과 통신할 수 있습니다.

블록체인 간 통신 (Inter Blockchain Communication)
EOS.IO 소프트웨어는 블록체인 간 통신이 쉽도록 설계되었습니다. 이는 메시지 존재 증명과 메시지 순서 증명의 생성을 손쉽게 함으로 이루어집니다. 이러한 증명들은 메시지 전달을 감싸는 애플리케이션 아키텍처와 결합하여 블록체인 간 통신과 증명 검증 과정이 애플리케이션 개발자로부터 은닉되도록 합니다. 메시지 전달과 관련된 응용 프로그램 아키텍처와 결합된 이러한 증명은 블록 간 통신 및 증명 검증에 대한 세부 정보를 응용 프로그램 개발자에게 숨길 수 있습니다.

 경량화된 클라이언트 검증(LCV)을 위한 머클 증명 (Merkle Proofs for Light Client Validation)
클라이언트들이 모든 트랜잭션을 처리할 필요가 없을 때, 다른 블록체인들과 결합하는 것이 쉬워집니다. 사실, 모든 거래소는 전체 블록체인 중 거래소의 입/출금에 대해서만 관리하면 됩니다. 거래소 체인(exchange chain)의 입금에 대한 경량화된 머클 증명(lightweight merkle proofs of deposit)을 이용하는 것이 블록 생산자 전체를 신뢰하는 것보다 이상적입니다. 적어도 해당 체인의 블록 생산자들은 다른 블록체인과 동기화를 위해 최소한의 연산 부담을 감당하기를 원합니다.
LCV(경량화된 클라이언트 검증)의 목표는 상대적 경량 데이터 집합을 보고 있는 누구든지 검증할 수 있는 상대적 경량 증명을 만들 수 있게 하는 것입니다. 특정 트랜잭션이 어떤 블록에 포함되어 있고, 그 블록이 블록체인의 인증 이력(verified history)에 포함되어 있는지를 증명하는 것을 목표로 합니다.
비트코인은 모든 노드가 연 4MB 가량의 블록 헤더의 모든 기록에 접근하는 것을 가정하고 트랜잭션의 검증을 수행합니다. 초당 10개의 트랜잭션이 발생할 경우, 유효한 증명(valid proof)은 512 바이트를 필요로 합니다. 10분의 블록 간격을 가지는 블록체인에서 이 방법은 사용할 수 있지만, 3초의 블록 간격을 가지는 블록체인에서 이것은 "경량"이 아닙니다.
EOS.IO 소프트웨어는 트랜잭션이 포함 된 시점 이후에 되돌릴 수없는 블록 헤더를 가진 사람이라면 누구나 가벼운 증명을 가능하게합니다. 아래에 보이는 해쉬 연결 구조(hash-linked structure)를 이용하여 1,024바이트 이하의 증명(proof)을 가지는 모든 트랜잭션에 대한 존재 증명(existence prove)이 가능합니다. 검증 노드(validating nodes )가 지난 하루 간(2MB의 데이터)의 모든 블록 헤더를 유지한다 가정하면, 트랜잭션의 검증을 위해서 200바이트의 증명이면 충분합니다.
경량 검증 방식을 도입하기 위해 적절한 해쉬-연결(hash-linking)이 포함된 블록을 생성하는 것은 추가 비용은 매우 적으므로, 이 방식으로 블록을 생성하지 않을 이유는 없습니다.
다른 체인에 속한 증명들을 검증할 경우 다양한 연산 시간/공간/대역폭 최적화가 가능합니다. 모든 블록 헤더(연간 420MB)의 추적(tracking)은 증명의 크기를 작게 유지하게 할 것입니다. 최근의 헤더만 추적하는 것은 최소 장기 저장소 관리와 증명 사이의 절충(trade off)이 발생합니다. 대안으로, 블록체인은 과거 증명의 중간 해쉬를 기억하는 지연 평가(lazy eval‎uation) 방식을 사용할 수 있습니다. 새로운 증명은 이미 알려진 희소 트리(sparse tree)에 대한 링크가 포함하면 됩니다. 어떤 방식을 사용할지는 머클 증명을 참조하는 트랜잭션을 포함하는 외부 블록의 비율에 따라 결정됩니다.
상호 연결이 일정 비율 이상 이루어진다면, 단순하게 다른 체인의 모든 블록 기록을 해당 체인이 가지게 하여 검증을 위해 두 체인을 볼 필요가 없게 하는 것이 효율적입니다. 성능 관점에서 체인 간 증명의 비율을 낮추는 것이 좋습니다.

체인 간 통신의 지연 시간 (Latency of Interchain Communication)
외부의 다른 블록체인과 통신할 때, 블록 생산자는 적합한 입력값으로 받아들이기 이전에 다른 블록체인에서 바뀌지 않는 확인 상태에 돌입하였음을 100% 확신할 때까지 기다려야 합니다. EOS.IO 소프트웨어와 21명의 생산자와 3초 블록 생성 시간을 가지는 DPOS(지분 위임 증명; Delegated Proof-Of-Stake)를 이용할 때 약 45초가 걸립니다. 만약에 특정 체인의 블록 생산자가 바뀌지 않는 상태(irreversibility)가 되는 것을 기다리지 않는다면 거래소에 취소한 입금이 승인되는 것과 같은 일이 일어나며 체인의 합의 검증에 문제가 발생할 것입니다.

완전성 증명 (Proof of Completeness)
블록체인 외부의 머클 증명을 사용할 때, 모든 트랜잭션이 수행된 것을 확인하는 것과 무시하거나 빠진 트랜잭션이 없음을 확인하는 것은 상당한 차이가 있습니다. 최근의 모든 트랜잭션을 모두 알고 있음을 증명하기는 불가능하지만, 트랜잭션 이력의 빈틈(gap)이 없음을 증명하는 것은 가능합니다. EOS.IO는 모든 계정간 메시지 전달에 일렬 번호를 부여하여 이를 가능하게 합니다. 사용자는 특정 계정에 대한 모든 메시지가 정상적으로 처리되었으며, 순서에 맞추어 처리되었음을 증명할 때 이러한 일렬 번호를 사용할 수 있습니다.

결론 (Conclusion)
EOS.IO 소프트웨어는 검증된 개념과 실질적인 경험을 통해 설계되었으며, 블록체인 기술의 근본적인 발전을 대표하는 제품입니다. 이 소프트웨어는 전 세계적 규모의 블록체인의 탈중앙화 애플리케이션을 쉽게 구현하고 운영(governing)하는 전체적인 청사진의 일부입니다.