ECOC“轻链”一个基于POS机制底层算法的公有链计算集成系统

去中心化应用

ecoc 合约机制使得任何一个人能够在一个虚拟机上建立通 过全网共识来运行命令行应用（从根本上来说是），它能够更改 一个全网可访问的状态作为它的“硬盘”。然而，对于多数人来 说，用作交易发送机制的命令行接口缺乏足够的用户友好使得去 中心化成为吸引力的替代方案。最后，一个完整的“去中心化应 用”应该包括底层的商业逻辑组件和上层的图形用户接口组件。 客户端被设计成一个网络浏览器，但包括对吐絮应用户接口组 件，客户端设计成一个网络浏览器，单包括对“ecoc”javascriptapi 对象的支持，可备客户端里看到的特定的网页用来与 ecoc 区块链交互。从“传统”网页的角度来看，这些网页完全静态的内容， 因为区块链和其他的去中心化协议将完全代替服务器来处理用 户发起的请求。最后，去中心化协议游戏王自己利用莫种方式。

utxo模型

在未花费交易输出（utxo）模型中，交易使用未花费的比特 币作为输入，此时输入的 utxo 就会作废，而输出是另一个 utxo, 比特币数量上变化的结果会返还到发送者 [1]。一定数 量 的比特币在不同私钥持有人之间进行转移，新的未花费交易输出 在交易中花费，并记录在 区块上。在比特币交易中，utxo 可用 交易接收方公钥地址生成的秘钥进行解锁。需要说 明的是，矿 工在 coinbase 交易中生成比特币，这个过程中并没有包含任何 输入。同时，比 特币利用脚本语言只能进行有限的操作 7 ，并 以堆栈（分为主堆栈和 alt 堆栈）的形式进行 数据处理，并遵 循“后进先出”（lifo）原则。 开发者在比特币客户端定义了五 种交易标准，分别为：p2pkh（pay to public key hash）、 p2pk （pay to public key）、多重签名（少于 15 个私钥签名）、p2sh （pay to script hash） 和 op_return。利用这五种交易标准，比 特币客户端可以满足复杂的支付逻辑。除此之 外，如果矿工同 意对非标准交易进行封装，比特币客户端也可创建并执行一个非 标准的脚 本。 举例来说，使用 p2pkh 交易方式，我们假设用 户向虚拟比特币地址 bread address 支付了 0.01 比特币购买面 包。该交易的输出为： op_dup op_hash160 op_equal op_checksig op_dup 复制 堆栈顶层数据；op_hash160 返回比特币地址并存入栈顶。除了 比特币地 址，还需要数字签名和数字秘钥才能拥有比特币所有 权。若栈顶数据一致，则 op_equal 返回真值（1），否则返回 非真值（0）。op_checksig 生成公钥和签名，并校验交易哈希 值。若一致，则返回真值。 锁定脚本相对应的解锁脚本为： 将 上述两个脚本相结合： op_dup op_hash160 op_equal op_checksig 只有当解锁脚本和锁定脚本满足预先设定的条件 时，执行结合脚本的输出为真。当 bread signature 签名与 bread 03：utxo 方案address 私钥相匹配，则返回真值。 但比特币脚本语言并不是图 灵完备的，无法实现循环功能。这极大地制约了交易执行量和交 易复杂度。此外，比特币脚本语言作为编程语言并没有被广泛使 用。当然，这些限制也降低 了诸如无限循环在内的复杂支付逻 辑安全漏洞的风险。 当然 utxo 模型也有诸多优势：任何人可 以通过比特币公共账本对每一笔交易历史进行查 询；utxo 有良 好的可拓展性，能够同时处理多个地址发起的交易请求。此外， utxo 模 型也提供了隐私保护，用户可以使用变更地址作为 utxo 输出。但 utxo 并不提供状态 

信息，因此 ecoc 的目标是 在 utxo 模型的基础上加入全新设计，提供全新的智能 合约平 台。 与 utxo 模型不同，以太坊使用了账户（account）模型。 具体来说，ecoc 通过账户状态的改变进行价值和信息的交换与 传输，并通过长度为 20 字节的随机数作为指针以确保交 易处 理的唯一性。用于支付交易费用、供内部使用的加密货币称为以 太坊。合约代码是可选 的，而账号的存储默认为空。 以太坊账 户有两种类型，一种由外部私钥控制的外部账户，另一种由合约 代码控制的合约账 户。外部账户用于信息传输的创建、交易签 名。合约账户用于收到内部存储读写操作信息后 创建合约或发 送其他信息。 以太坊中的账户余额管理与日常生活中的银行账 户管理相类似。每一个新产生的区块都有可能影响其他账户的全 局状态。每个账户都有各自的余额、存储和代码空间用于调用其 他账户或地址，并存储相应的代码执行结果。现有的 ecoc 账户 系统中，用户通过客户端远程调 用合约账号进行 p2p 交易。尽 管通过智能合约向多个账户发送信息是可以实现的，但具体 交 易信息只有参与交易的账户可见，无法在 ecoc 公共账簿上进行 追踪仍无法实现。 综上所述，我们认为 ecoc 在扩展性方面的瓶 颈使比特币 utxo 模型拥有更多的优势。 utxo 模型与 ecoc 提供的平台一致性更相关，因此 ecoc 决定使用 utxo 模型作为 交易模型的基础。

tps解决方案

ecoc 以字节为单位计算平均事物大小，首先我们将计算所有需 要的跳数节点获取数据，因为连接数是固定的，c 和因为具有数 据（块）的每隔节点想起他节点广播它连接后，流程遵循“雪球” 效应。这在数学上是一个几何级数：

其中 h-1 希望之后通知的节点数。在这里，我们假设 a0 = 1，因 为 a0 是形成（获胜）块的节点，并且是准备开始广播。 h 跳后 的总通知节点 n 将是：

并且很容易理解为什么。节点应该有足够的时间来“获取”（下 载）块数据。因此，虽然某些节点可以容忍它来自先前块的数据 在创建新数据时，这是不安全的长期的;总传播时间应低于平均创 建时间一个街区的时间。结合（3）和（4）我们得到

equality（5）清楚地显示了网络必须的最低带宽 bmin 必须以字节 为单位维持大小为 s 的块大小。值得注意的还有数据的传播很容 易扩展，因为存在对数关系在网络 n 的节点数和连接数之间 c。换句话说，跳数 h（n）是 o（log n）。原因在于此 效率是指传播是基于八卦协议[1]。比特币和 ecochain 遵循八卦协 议（默认）连接数 c = 8.在 src / net.h 文件的代码中可以很容易地 看到：从上面我们得出结论，对于 ecochain c = 8.作为旁注，我们 必须强调任何节点都可以*更改出站号码关系;也就是说，c 不 是共识协议的参数。只是将上面的代码行从 8 更改为任何数字是 可以接受的网络，因为它不是真的可以检测到。例如，节点可能 具有高上传带宽也可能想要帮助网络，所以选择设置 c 或者节点 是自私的或恶意的，并将 c 设置为零，而不是广播 任何东西。简而言之，改变 c 是一个简单的软叉。我们可以安全 地假设这里绝大多数节点都不会改变 c，因为它们没有鼓励这样 做。如果 c 的默认值设置为大于 8 的值没有必要带来更快的传播 时间;有限制数据库提交时的磁盘写入时间和由于的 cpu 延迟 4 当交易数量很大时所需的验证时间。所以 ecochain 保持 c = 8，正 如我们已经提到的那样，不限制节点;每个节点都可以很容易地改 变它。让我们看一个数字的例子：对于最大块大小 s = 4m 字节， 块时间 bt = 32sec，节点数 n = 4,000，连接数 c = 8 来自 equeation （5）的最小网络速度（带宽）应该是《技术数据参考链接http://t.cn/aipaalby》

图灵完备

需要强调的是以太坊虚拟机是图灵完备的； 这意味着 evm 代码可以实现任何可以想象的计算，包括无限循环。evm 代码有 两种方式实现循环。首先， jump 指令可以让程序跳回至代码前 面某处，还有允许如 while x < 27: x = x * 2 一样的条件 语句的 jumpi 指令实现条件跳转。其次，合约可以调用其它合约， 有通过递归实现循环的潜力。这很自然地导致了一个问题：恶意 用户能够通过迫使矿工和全节点进入无限循环而不得不关机 吗？ 这问题出现是因为计算机科学中一个叫停机问题的问题： 一般意义上没有办法知道，一个给定的程序是否能在有限的时间 内结束运行。 正如在状态转换章节所述，我们的方案通过为每一个交易设定运 行执行的最大计算步数来解决问题，如果超过则计算被恢复原状 但依然要支付费用。消息以同样的方式工作。为显示这一方案背 后的动机，请考虑下面的例子： 一个攻击者创建了一个运行无限循环的合约，然后发送了 一个激活循环的交易给矿工，矿工将处理交易，运行无限 循环直到瓦斯耗尽。即使瓦斯耗尽交易半途停止，交易依 然正确（回到原处）并且矿工依然从攻击者哪里挣到了每 一步计算的费用。 一个攻击者创建一个非常长的无限循环意图迫使矿工长 时间内一直计算致使在计算结束前若干区块已经产生于 是矿工无法收录交易以赚取费 用。然而，攻击者需要发 布一个 startgas 值以限制可执行步数，因而矿工将提前 知道计算将耗费过多的步数。 一个攻击者看到一个包含诸如 send(a,self.storage); self.storage = 0 格式的合约然后发送带有只够执行第一 06：图灵完备步的费用的而不够执行第二步的交易（即提现但不减少账 户余额）。合约作者无需担心防卫类似攻击，因为如果执 行中途停止则所有变更都被回复。 一个金融合约靠提取九个专用数据发布器的中值来工作 以最小化风险，一个攻击者接管了其中一个数据提供器， 然后把这个按 dao 章节所述的可变地址调用机制设计成可 更改的数据提供器转为运行一个无限循环，以求尝试逼迫 任何从此金融合约索要资金的尝试都会因瓦斯耗尽而中 止。然而，该金融合约可以在消息里设置瓦斯限制以防范 此类问题。 图灵完备的替代是图灵不完备，这里 jump 和 jumpi 指令不存在并且在某个给定时间每个合约只允许 有一个拷贝存在于调用堆栈内。在这样的系统里，上述的 费用系统和围绕我们的方案的效率的不确定性可能都是 不需要的，因为执行一个合约的成本将被它的大小决定。 此外，图灵不完备甚至不是一个大的限制，在我们内部设 想的所有合约例子中，至今只有一个需要循环，而且即使 这循环也可以被 26 个单行代码段的重复所代替。考虑到 图灵完备带来的严重的麻烦和有限的益处，为什么不简单 地使用一种图灵不完备语言呢？事实上图灵不完备远非 一个简洁的解决方案。为什么？请考虑下面的合约： c0: call(c1); call(c1); c1: call(c2); call(c2); c2: call(c3); call(c3);... c49: call(c50); call(c50); c50: (作一个图灵机的步计算和记录结果在合约的长期存储) 现在，发送一个这样的交易给 a，这样，在 51 个交易中，我们有 了一个需要花费 2^50 步计算的合约，矿工可能尝试通过为每一 个合约维护一个最高可执行步数并且对于递归调用其它合约的合约计算可能执行步数从而预先检测这样的逻辑炸弹，但是这会 使矿工禁止创建其它合约的合约（因为上面 26 个合约的创建和 执行可以很容易地放入一个单独合约内）。另外一个问题点是一 个消息的地址字段是一个变量，所以通常来讲可能甚至无法预先 知道一个合约将要调用的另外一个合约是哪一个。于是，最终我 们有了一个惊人的结论：图灵完备的管理惊人地容易，而在缺乏 同样的控制时图灵不完备的管理惊人地困难- 那为什么不让协 议图灵完备呢？

去中心化应用（dapp）

ecoc 系统致⼒从技术层⾯全⾯⽀持去中⼼化应⽤，尤其是 通过移动端策略的引⼊，将不 同的 dapp 想法产品化，使普通互 联⽹⽤户可以真正感受到区块链技术带来的价值。 ⾯向不同⾏ 业的 dapp 应⽤，可以把区块链技术带给更多的⽤户和⾏业。例 如去中⼼化的 社交、去中⼼化的存储和去中⼼化的域名服务、 去中⼼化的计算服务等，通过激励机制的 引⼊，将更深层次利 ⽤共享经济的理念，改变现有的 app 市场和商业模式。 区块链 技术为搭建去中⼼化应⽤（decentralized applications）提供基础 架构。 在量⼦链 中，通过完善的 ecoc api 的设计和 docker 的分发，简化开发者的准备⼯作，使开发者可 以快速上⼿相应 的开发⼯作。并将通过 ecoc 系统内部的 token 激励开发者开发 出⾼质量的 dapp。