一、概述
EOS.IO 软件采用区块链架构，实现去中心化应用的横向和纵向扩展。具体方法为构建一个类操作系统的架构，在其中搭建应用程序；另外，提供跨 CPU 跨集群的账户系统、身份验证、数据库、异步通信，并且支持应用程序间的调度，在受管控的区块链环境中，可每秒处理百万级交易，消除用户手续费，并且可以部署和维护DAPP。
EOS.IO 采用授权委托证明（DPOS）的算法： EOS 区块链上所有代币持有者可以都通过一个持续的投票系统选择区块生产者。想参与区块生产，只要能说服代币持有人给自己投票，最终（得票最高的那些节点）被选为区块生产者。
EOS.IO每 0.5 秒产生一个区块，并且在任一时间仅有一个生产者获权生产区块。如果在预定时间内没有区块生成，则跳过该块。相应的，当跳过一个或多个块时，区块链中会存在一个大于等于 0.5 秒的时间间隔。每一轮产生 126 个区块（共 21 个区块生产者，每个生产者生产6个块）。在每轮开始时，根据代币持有者的投票选出 21 个不同的区块生产者。获选的生产者的生产顺序由 15 个或更多生产者一致同意决定。如果一个生产者错过了一个块，并且在过去 24 小时均未产生任何块，则会被从生产者的名单中剔除，直至他通知区块链表明他打算再次开始生产区块。这种方式可以排除不可靠的生产者来最小化错过的区块数量，从而确保网络的顺畅运行。
分叉的处理：因为其区块生产过程中，生产者是合作而不是竞争关系，理论上不会分叉。如果有分叉，将自动切换到最长的链上。原因是拥有较多生产者的区块链分叉会比生产者少的链增长速度要快得多，生产者占比越高的分叉链丢失的区块会更少。
添加了拜占庭容错机制的 DPOS 算法需要所有生产者签名所有区块，但禁止同一个生产者签名两个时间戳或高度相同的区块。一个区块一旦被 15 个生产者签名，那么这个区块就可以被视为不可逆了。 任何生产者一旦签名两个相同时间戳或相同区块高度的区块，这种不诚信行为就会留下密码学证据。在这一模型下，不可逆的共识将在 1 秒内达成。
在DPOS基础上，EOS.IO中加入了异步拜占庭容错(aBFT), 可实现更快的不可逆性。 aBFT算法在1秒时间内达到不可逆性的100％确认。
EOS.IO要求每一笔交易必须包括最近的区块头的哈希值。目的是为了：防止分叉区块链上出现大量重复事务，同时通知整个网络，某个特定用户和其权益存在于某个特定的分叉上。
如此一来，伪造假冒链将变得非常困难，因为伪造者无法将合法链中的交易迁移到假冒链上。
EOS.IO账户名称由帐户的创建者指定。帐户创建者必须使用 EOS 代币预留 RAM 用来存储新帐户，直至新帐户质押自己的代币来预留自己的 RAM。在去中心化的背景下，应用程序开发人员在新用户注册时，会象征性地支付账户创建费用。创建新的区块链账户所需的资金对于企业来说很低，而且如果用户在注册另一个应用程序时已经创建了帐户，那就没有必要再次创建了。
每个帐户可以将结构化的操作发送到其他帐户，并且可以定义脚本来处理收到的操作。EOS.IO为每个帐户提供自己的专用数据库，只能由自己的操作处理程序访问。操作处理脚本还可以将操作发送到其他账户。EOS.IO智能合是操作和自动操作处理程序的组合。
并发执行操作：每个账户同样可以在数据库内定义任意数量的范围。区块生成者以对内存访问范围没有冲突的方式调度事务。
权限管理包括确认某项操作是否被正确授权。最简单的权限管理是检查交易是否具有所需的签名，这也意味着所需的签名是已知的。一般而言，授权涉及个人或群体，并且往往是分类的。EOS.IO 通过一个声明式权限管理系统，对帐户进行细粒度、高级别的控制，以确定谁在何时可以做什么。
每个帐户都可以通过其他帐户和私钥的组合来控制，创建一个分层的权限结构。
帐户可以定义什么样的账户和密钥的组合，把特定的操作发送到另一个账户。例如，可以使用一个密钥访问用户的社交媒体帐户，另一个密钥用于访问交易所。甚至可以授权其他帐户来代表本账户进行操作，而无需为此账户分配密钥。
帐户可以定义命名的权限级别，每个权限级别可以从更高级别的命名权限中派生。每个命名权限级别定义一个权限。权限是一个多签名的阈值检查，由其他帐户的密钥和/或命名权限级别组成。例如，可以为一个帐户的某个操作设置”朋友”权限级别，该帐户的朋友对该操作具有相同等级的控制权限。
另一个例子是Steem区域链，它具有三个硬编码命名的权限级别：owner， active和posting。Posting权限只能执行诸如投票和发布等社交行为，而active权限可以执行除更改所有者的所有操作。Owner权限被保留，可以执行一切操作。EOS.IO允许每个账户所有者定义自己的权限级别以及消息的分组。
EOS.IO 允许每个帐户定义从合约/操作或其他账户的合约，到其自己的命名的权限级别之间的映射。例如，账户持有人可将其社交媒体应用程序映射到账户所有者的”朋友”权限组。通过此映射，该账户的任何朋友都可以作为账户所有者在社交媒体发布信息。尽管这些朋友可以作为帐户所有者发布信息，但他们仍然会使用自己的密钥来签名。这就意味着，哪些朋友以何种方式使用了该帐户，始终是可以确定的。
当从账户 @alice 发送操作到 @bob 时，EOS.IO 将首先检查 @alice 是否为 @bob.groupa.subgroup.Action 定义了权限映射。如果没有发现任何结果，那么将会检查 @bob.groupa.subgroup，然后检查 @bob.groupa，最后检查 @bob。如果没有找到进一步的匹配，则假定映射的命名权限组是 @alice.active。一旦确定了映射的命名权限，则使用多签名阈值来验证签名，并获取命名权限相关联的权限。如果失败，那么它会遍历父类权限，最后遍历 owner 的权限，即@alice.owner。
EOS.IO 给所有账户指定了两个默认权限组。一个是”owner”权限组,可以执行任何操作。还有一个“active”权限组，除了更改“owner” 权限组之外，可以执行所有操作。所有其他权限组均由“active”组派生。
权限验证成为一个只读与可并发化的过程:当重播区块链以从动作日志重新生成确定性状态时，不需要再次评估权限。因为事务包含在已知的状态良好的区块中，可以让其跳过这一步骤。这极大减少了重放区块链时消耗的计算量。
消息包含在区块后，EOS.IO支持应用程序开发人员可以指定某些消息在应用前必须等待一小段时间，在此期间可以取消该操作。
当这类消息被广播时，用户可以通过电子邮件或短信收到相应通知。如果用户没有授权，那么他们可以登录帐户来还原账户数据并撤回消息。
EOS.IO提供了密钥被盗时恢复其帐户控制的方法。帐户所有者可以使用过去30天内活跃的任何其批准的帐户恢复合作伙伴的密钥，重置帐户上的所有者密钥。没有账户所有者的配合，帐户恢复合作伙伴无法重置帐户的控制权。
这个过程也与简单的多重签名交易有着极大的不同。通过多签名交易，另一个实体会成为每个执行交易的一方。相比之下，通过恢复过程，恢复合作伙伴仅参与恢复过程，无权参与日常交易。这极大降低了所有参与者的成本和法律责任。
区块链共识取决于确定性 (可重复) 行为，这意味着所有并行执行必须避免使用互斥锁或者其他锁原语。如果没有锁，那么必须要有方法来保证可能被并行执行的交易不会产生非确定性结果。EOS.IO目前发行版将是单线程的，但是它会包含将来多线程、并行执行所需的数据结构。
EOS.IO 不能强迫区块生产者投递任何操作给其他帐户。每个区块生产者都需要对处理交易所需的计算复杂度和时间做出主观测量。无论是用户生成的还是智能合约自动生成的交易，这一点都适用。
在一个基于 EOS.IO 的区块链里，在网络层面上，所有交易会根据执行的 WASM 指令数来计算带宽成本。但是使用 EOS.IO 软件的每个区块生产者都可能会使用自己的算法和标准来计算资源的使用情况。当区块生产者判定某个交易或账户会消耗过多的计算能力时，在生产自己的区块时他们会直接拒绝这个交易；但是如果其他区块生产者都认为这个交易有效，他们还是会处理该交易。
一般而言，只要有 1 个区块生产者认为某个交易有效且在资源使用限制内，那么其他所有区块生产者也会接受这个交易；但是这个交易可能需要多达 1 分钟才能找到生产者。
在某些情况下，生产者创建的区块可能包含可接受范围之外的数量级的交易。遇到这种情况，下一个区块生产者可以选择拒绝该区块，这个僵局将会被第三个生产者打破。这和过大区块导致网络传播延迟相似。EOS.IO 社区会注意到这种滥用模式，并最终移除恶意生产者的投票。这种对计算成本的主观评估使得区块链不必精确和确定地测量交易需要运行多长时间，没必要精确地计算指令数，这可以在不违反共识的情况下显著增加优化性能的机会。
EOS.IO支持计划在未来执行的延期交易。
上下文无关操作仅涉及需要用到交易数据的计算，而不涉及区块链状态。例如，签名验证是一种仅需交易数据和签名以确定签署事务的公钥的计算。签名验证在区块链必须执行的计算中，属于最昂贵的单个计算之一，但由于此计算是上下文无关的，因此可并发执行。
上下文无关操作与其他用户操作类似，只是它们无法访问区块链状态来执行验证。这不仅使EOS.IO能够并发处理诸如签名验证等所有上下文无关操作，更重要的是可以实现通用签名验证。
通过支持上下文自由操作，可伸缩性技术变得更加可并发和实用，实现了高效的区块链间通信和潜在的无限可扩展性。
所有的区块链都是资源受限的，并且需要一个系统来防止滥用。在EOS.IO系统中，有三大类资源被应用程序消耗：
（1）带宽和日志存储（磁盘）（2）计算和计算积压（CPU）（3）状态存储器（RAM）
瞬时使用和长期使用都会消耗带宽和计算。区块链系统将维护所有消息的日志，这些日志会被所有的完整节点下载和存储。通过日志信息，可以重构所有应用程序的状态。
计算债务是必须执行的计算，以便从操作日志中重新生成状态。如果可计债务增长量过大，那么就有必要对区块链的当前状态进行快照，并放弃区块链的历史状态。如果计算债务增长过快，区块链可能需要6个月的时间来重放1年的交易。因此，谨慎管理计算债务至关重要。
区块链存储状态是可从应用程序逻辑访问的信息。它包括诸如订单和账户余额等信息。如果应用程序从未读取该状态，则不应该存储它。例如，应用程序逻辑不会读取博客文章内容和评论，因此不应将其存储在区块链状态中。同时，发布/评论，投票数量以及其他属性的存在将作为区块链状态的一部分进行存储。
区块生成者可以发布他们可用的带宽、计算资源和状态的容量。EOS.IO软件允许每个帐户消耗一定百分比的可用容量，该容量与3天赌注合同中持有的令牌数量成比例。 例如，如果启动了基于EOS.IO软件的区块链，并且如果一个帐户持有根据该区块链可分配的总令牌的1％，则该帐户有可能利用1％的状态存储容量。
在已启动的区块链中使用EOS.IO，带宽和计算能力将被分配到部分储备基础中，因为未使用的容量不能存储下来为将来使用。EOS.IO系统将使用类似于Steem的算法来限制带宽使用速率。
测量计算使用对性能和优化有重大影响，因此，所有资源使用限制最终是主观的，并且由区块生产者根据他们各自的算法和估算来执行，通常由区块生产者通过写自定义插件来执行。
虽说如此，但有些东西客观地衡量是微不足道的。交付的操作次数以及存储在内部数据库中的数据大小对于客观衡量都很便宜。EOS.IO使区块生产者能够在这些客观测量上应用相同的算法，但可以选择对主观度量应用更严格的主观算法。
没有网站强制其访问者在访问其网站时收取小额费用来支付管理成本。因此，去中心化的应用程序不应强迫使用区块链的用户直接支付区块链使用费用。使用EOS.IO软件的推出区块链不要求其用户直接支付区块链使用费，因此不会限制或阻止企业制定其产品的货币化策略。
尽管接收方可以支付，但EOS.IO使发送方能够支付带宽、计算和存储费用。这使得应用程序开发人员能够选择最适合其应用程序的方法。很多情况下，发件人支付大大降低了不想实施自己的配给系统的应用程序开发人员的复杂性。应用程序开发人员可以将带宽和计算委派给用户，然后让”发件人支付”模型执行使用。从最终用户的角度来看，它是免费的，但从区块链的角度来看，它是发件人支付的。
采用EOS.IO区块链上的令牌持有人，可能不需要立即消耗全部或部分可用带宽，可将这些未消耗的带宽委派或租借给其他人; 运行EOS.IO的区块生产者将会识别这种容量授权并分配相应带宽。
EOS.IO的主要优点之一是可用于应用程序的带宽量完全独立于令牌价格。如果应用程序所有者在使用EOS.IO程序的区块链上持有相应数量的令牌，则该应用程序可在固定状态和带宽的情况下无限期运行。，采用EOS.IO软件的区块链生产商能够自然地增加带宽，计算和存储，而不受令牌价值的影响。
使用EOS.IO的区块链每次新产生区块时都会授予区块生产者令牌。令牌的价值将影响生产商的带宽、存储和计算量，该模型利用自然上升的令牌价值来提高网络性能。
虽然可以委托带宽和计算，但应用程序存储状态需要应用程序开发人员持有令牌，直至该状态被删除。如果该状态从未被删除，那么令牌将从循环中有效移除。
创建的令牌数量由所有块生产者公布的期望收益的平均数决定。 EOS.IO可能被设为强制执行生产者奖励的上限，使得令牌供应总量的年增长率不得超过5％。
除了选择区块生产者之外，根据基于EOS.IO的区块链，令牌持有者可以选择一些旨在让社区受益的建议。获胜的提案将获得高令牌通货膨胀配置百分比的令牌减去已经支付给区块生产者的令牌。这些建议将获得与每个应用程序从令牌持有者收到的投票成比例的令牌，直到他们要求执行其工作的金额为止。当选的提案可以由代币持有人的新当选提案取代。
实施人工建议的系统合同可能在2018年6月初次启动时未到位，但资金机制将会实现。它将开始积累资金，同时开始区块生产者奖励。由于工作人员建议系统将在WASM中实施，因此可以在以后不加分叉的情况下添加。
EOS.IO 软件将会是账户间传递可信消息（称之为”操作”）的最重要的平台。脚本语言和虚拟机属于具体实现，与 EOS.IO 的技术设计几乎是相互独立的。任何确定性的语言或者虚拟机，只要性能足够好，并支持沙盒运行机制，都可以和 EOS.IO 的 API 整合起来。
任何账户间的操作都满足一定的范式，该范式也是区块链共识状态的组成部分。这一范式支持二进制格式和 JSON 格式间的无缝转换。
数据库状态也由类似的范式定义。这一范式使得所有应用储存的数据都遵循特定的格式，既能转换为可读性很强的 JSON 格式，又能以高效的二进制格式存储与操作。。
开发智能合约需要一个事先定义好的数据库来追踪、存储和查询数据。开发者们普遍需要支持数据排序或多字段索引的数据库，来保证数据的一致性。
为了最大化并行运算能力和最小化算力债（计算应用状态需要在交易日志中从头运算），EOS.IO 将验证逻辑分成了三部分：
验证一个操作在内部是一致的；验证所有的前置条件是有效的；修改应用状态。
验证操作的内部一致性是只读操作，且不需要区块链状态信息。这意味着这一操作可以最大程度地并行进行。验证前置条件的有效性（比如必要的余额）也是只读操作，因此也可以利用并行机制。只有修改应用状态这一步需要写操作，并且对每个应用必须严格按照顺序执行。
认证是用来验证操作是否可以被执行的一个只读过程。而（操作涉及的）真正的业务则是应用程序来完成的。当一个操作发生的时候，这两部分工作都需要实时计算。一旦（包含该操作的）交易被打包进了区块链，认证操作也就不再需要重复进行了。
EOS.IO 的设计能促进跨链通信，实现方式是简化生成操作存在证明和顺序证明。这些证明和围绕操作传递设计的应用架构一起，使得跨链通信的细节和验证工作对应用开发者不可见，开发者看到的只是更高层次的抽象。
如果客户端不需要处理全部交易的话，和其他区块链的结合将变得非常容易。毕竟类似交易所这样的客户端，它只关心资产的转入和转出。理想情况下，交易所的链可以用转账交易的轻量默克尔证明（来完成交易所业务），而不是完全信任某个区块生产者。每条链的区块生产者都希望和其他链同步的开销尽可能地小。轻量客户端验证（LCV）的目标是生成相对轻量的存在证明，这些证明可以被任何关心一个轻量的数据集的客户端用来验证。在上述例子中，LCV 的目的就是为了用来证明某笔交易已经被包含进某一特定区块，而这一区块已经被某条特定的链所收录。
任何有不可逆区块头数据的用户在交易被区块记录后，都可以使用 EOS.IO 提供的轻量证明。轻量证明的哈希连接（hash-linked）结构表明，最多只要 1024 个字节，即可验证任何一笔交易的存在与否。
考虑到区块链中的区块的 id 和区块头都是可信的且不可逆的，因此证明某个区块被包含在某个区块链中也是可行的。这类证明最多只需 ceil(log2(N)) 次摘要计算即可完成，其中 N 为区块链中的区块个数。就 SHA256 这种摘要算法来说，你只需要 864 个字节就可以在一个有着 1 亿个区块的链上验证某个区块的存在。使用合适的哈希连接（hash-linking）机制生产区块以启用上述证明，几乎不会带来什么额外开销，所以这种方式十分可行。
若要在其他链上验证证明，时间、空间和带宽上都有很多优化空间。追踪全部的区块头（每年 420MB 递增）可以将证明维持在比较小的空间占用。仅追踪最近的区块头会在最小长期存储和证明大小之间实现平衡。另外也可以采用惰性求值的方式，记录过去的证明的中间哈希值。新证明只需要包含已知的稀疏树的连接。具体选取何种方式，取决于默克尔证明引用的带有交易的外部区块的比例。
当互联和耦合程度达到一定的复杂度之后，将两条链的数据合并将更简单高效，如此一来也就不再需要默克尔证明了。因为性能的原因，跨链证明的频度当然是越小越好。
当和外部区块链进行通信的时候，区块生产者必须要 100% 确认一笔交易已经被不可逆转地写入到外部区块链之后，才可以将其当作合法输入。EOS.IO 的区块链加上 DPOS 算法 0.5 秒的出块速度，结合拜占庭容错机制，使得等待上述确认的时间大约为 0.5 秒。任何区块生产者若违背上述原则，不等待确认即开始下一步操作，例如交易所在未确认的情况下就将资产冲入用户账户，随后又将资产取消的行为，都将影响区块链的共识机制。EOS.IO 软件使用 DPOS 算法结合拜占庭容错机制快速实现交易的不可逆性。
当外部的区块链使用默克尔证明的时候，去知晓处理的全部交易全部有效，不同于去知晓没有交易被跳过或省略。因为想要证明”最近全部的交易都已经被知晓”是不可行的，而证明“交易历史记录里没有被跳过的交易”则很容易。EOS.IO 通过给发送到每个账户的每个操作一个顺序编号来实现这一点。用户可以使用这些顺序编号来验证某个特定账户的所有操作都已经被处理，并且是严格按照顺序来处理的。
隔离见证（SegWit）是指一笔交易被打包进不可变更的区块链之后，这笔交易的签名就与交易无关了。一旦交易变为不可变更状态，签名数据就可以被舍弃，其他人仍然能获得区块链当前状态。考虑到签名数据容量占据了多数交易的很大部分，隔离见证将能大幅缩减磁盘占用和数据同步时间。
隔离见证的概念对用于跨链通信的默克尔证明同样适用。一旦一个证明被接受并被不可逆地记录进区块链，那么这个证明用到的 2KB 大小的 sha256 哈希值就可以在不影响区块链状态的前提下被舍弃。值得一提的是，将隔离见证用于跨链通信节省的存储空间的是常规签名场景下的 32 倍。
隔离见证应用的另一个场景则是用于（存储） Steem 的博客文章。利用隔离见证，存储在区块链上的将只是一篇篇博客内容的 sha256 哈希值，真正的内容则存储于隔离见证数据中。区块生产者只需要依靠内容的哈希值就可以验证文章的存在。要从交易日志中恢复区块链当前状态，生产者无需存储全部的内容。这样一来，以下的证明方式变得可行：内容只要曾经有人看过即可，无需永久储存。
EOS.IO 使去中心化应用（dApp）的开发、部署和管理变得更加容易。
EOSIO使用的主要部分以及此处涉及的部分是：
nodeos（node + eos = nodeos） - 可以使用插件配置以运行节点的核心EOSIO节点守护程序。 示例用途是块生产，专用API端点和本地开发。
cleos（cli + eos = cleos） - 命令行界面，用于与区块链交互并管理钱包。
keosd（key + eos = keosd） - 将EOSIO密钥安全存储在钱包中的组件。