Microsoft Word - MagnaChain_Tech_WhitePaper_CN 技术白皮书 - v2.6.2 中文.docx

Size: px

Start display at page:

Download "Microsoft Word - MagnaChain_Tech_WhitePaper_CN 技术白皮书 - v2.6.2 中文.docx"

炀谈房
5 years ago
Views:

1 MagnaChain 技术白皮书改变游戏规则摘要 Abstract MagnaChain 的设计理念稳定性安全性高并发, 高处理速度易用性 MagnaChain 实现方案帐户模型共识机制 MagnaChain 的挖矿经济学合约和 MLVM 的实现并发式侧链技术开发工具的集成与支持竞争公链比较路线图免责声明参考文献 / 34

2 2 / 34

3 摘要 Abstract MagnaChain 是一个全新的, 从头开始构建的公有区块链和相关集成工具, 用于分布式应用程序的开发该系统采用了多种独特的技术来解决当前公有区块链所面临的最大问题, 包括 : l 可扩展性 l 安全保障 l 交易速率 (TPS) l 共识机制 l 使用便利性 l 拥有长期和可持续的生态系统建设能力我们的最终目标是将 MagnaChain 打造成领先的公有区块链和分布式应用 (DApp) 的集成开发工具集对于中小型的 DApp, 利用基于区块链的分布式应用开发技术, 可以做到完全不需要后端程序, 即可完成整个 DApp 的开发与发布根据 MagnaChain 的规划, 第一个落地的应用场景是游戏产业, 它将作为游戏世界的第一个也是最快速的公有区块链, 致力于使得游戏开发者和游戏的最终用户获得区块链的优势和利益 MagnaChain 让游戏开发者轻松利用区块链技术开发游戏产品平台交易市场和其他游戏应用程序同时,MagnaChain 也具有在其他行业及领域运行其应用的潜力 ; 作为一个公有区块链,MagnaChain 中长期的规划将是在系统上运行无限领域的 DApps 应用程序 3 / 34

4 1 MagnaChain 的设计理念 1.1 稳定性稳定性是确保 MagnaChain 可用的必要条件区块链自带去中心化特征, 去中心化网络通常较复杂并充满不确定性因此, 我们借助模块化设计工具对区块链进行抽象和简化, 通过单独构建模块化虚拟机 MagnaChain Lua Virtual Machine( 以下简称 MLVM) 运行智能合约, 这样的设计可带来两个好处一是优化 MLVM 性能直接提升合约执行效率, 减少系统耦合带来的干扰因素 ; 二是弱化区块链网络与智能合约运行状态的相关性, 即便合约执行出现问题, 或虚拟机运行异常, 区块链网络的稳定性依然能够保证 1.2 安全性 PoW 曾对比特币网络的安全贡献功不可没, 但由于日益增长的挖矿需求和算力难度提升, 几乎所有权利都集中到矿工和矿池手中通过专业合作, 他们事实上已经成了高度中心化的中央服务器如果联合超过 51% 的算力, 理论上就能够控制大多数比特币交易, 如我们熟知的 DOS(Denial of Service) 攻击此外, 高昂的电力消耗也同样让人诟病相对于 PoW 模式来说,PoS 模式仍在发展, 这些发展方向主要立足于安全和应用 PoS 模式比 PoW 模式在能源消耗上有很大优势, 但前提是吸引到足够的持有者来进行 PoS 挖矿, 才能充分的发挥出其优势 DPoS 是 PoS 的改进, 可以通过持币用户, 投票选出代理来做验证, 这保证了网络的稳定可用, 但在一定程度上牺牲了去中心化这个特性而 MagnaChain 创新出更具商业普适意义的 VH-PoS 共识机制在 PoS 机制的安全节能基础上, 能大幅提高安全性, 也不需要 DPoS 的代理验证机掉, 在去中心化上做的更好 4 / 34

5 同时其设计之初就考虑到吸引尽可能多的活跃节点, 活跃节点数也会大幅高于普通 PoS 模式 1.3 高并发, 高处理速度每秒可以处理的事物笔数 Tps(transaction per second) 是用来衡量一个区块链系统交易处理能力的指标传统区块链系统只有每秒几笔, 或是几十笔的处理速度 ( 比特币比秒 6 笔, 以太坊每秒 30 笔 ) 对于游戏来说, 如果基于区块链模式做分布式应用开发, 那 TPS 可以近似理解成一次 IO 请求一个大型游戏可能就会有数十万人同时在线, 对应的每秒可能就会有数万次请求如果在未来, 主流的游戏全部基于区块链的分布式模式开发进行, 则整个网络的 TPS 数可能在数百万的量级现在区块链网络每秒数十笔的 TPS 处理速度, 在面对这种数百万量级的 TPS 需求时, 只能说是玩具这会导致整个网络交易拥堵, 进而让交易费变得非常高, 体验完全无法接受所以我们认为 MagnaChain 的高处理速度和高并发性, 是游戏应用能够落地的一个前提通过我们独创的并发式侧链技术, 完美地解决了这个问题理论上整个网络的 TPS 是可以轻易扩展的, 只受限于物理网络的吞吐极限, 目前的测试来看支持到数十万至百万级的 TPS, 是完全没有问题的我们的解决方案并非一味地缩短主链的区块产生时间和增加块大小, 因为这两者的优化都有极限, 而且也容易导致需要更大的磁盘空间, 更快的网络, 进而导致矿工验证变得更加困难, 对安全性有损害 MagnaChain 的并发式侧链技术创造性地在系统内增加了多条侧链, 通过多并发的方式解决了这个问题这些侧链是可自由生成和按需修剪的, 这样主链体积不会过度膨胀, 对安全性验证和磁盘空间也更加友好 5 / 34

6 1.4 易用性 MagnaChain 初期的定位是给专注于游戏应用的区块链系统, 为了让游戏开发者更方便地使用这套工具, 我们在系统设计和开发实践的各个环节, 都考虑到了游戏开发者的使用习惯与使用便利性得益于团队核心开发成员都有多年的游戏开发经验, 最终产品也基本上符合了这个要求这体现在产品的各个方面, 比如我们采用了游戏业服务端常用的 Lua 虚拟机作为智能合约的虚拟机, 智能合约也是采用的 Lua 语言在智能合约的语法设计上, 我们也是尽量贴近正常游戏开发者的使用习惯再如我们提供了对常用游戏开发引擎的 SDK 集成, 以及一系列提高易用性的集成工具, 让游戏开发者可以更快速地上手和转移到分布式应用开发模式中来同时我们还准备在系统内直接上线内容发布工具, 让游戏开发者可以直接在 MagnaChain 网络上一键发布游戏客户端, 降低游戏部署成本 6 / 34

7 2 MagnaChain 实现方案 2.1 帐户模型比特币 UTXO 模型剖析在比特币的网络中,UTXO(Unspent Transaction Output 未花费交易输出 ) 是比特币交易的基本单位, 通过交易的输入和输出, 比特币网络将金钱变化成一段数据结构, 区别于信用卡支付必须在加密安全网络中传输, 比特币的数据可以在任何不一定安全的网络中传输 (WiFi 蓝牙,NFC, 表格等 ) UTXO 可以是一聪 (1 10 BTC -9 ) 的任意整数倍尽管 UTXO 可以是小于 2100 万的任意数值, 但是一旦 UTXO 被创造出来, 只能作为一个整体被花掉如果一笔交易需要的 BTC 小于某一个 UTXO 的值, 那么该 UTXO 依然会被当做一个整体花费掉, 并形成一个找零的 UTXO UTXO 可以看做被私钥的拥有者锁定的并被整个比特币网络识别的比特币货币单位在 UTXO 模型中, 被某一个交易消耗的 UTXO 被称为交易输入, 由交易创建的 UTXO 被称为交易输出通过这种方式, 一定量的比特币在不同的私钥所有者之间转移, 并在交易链条中不断消耗和创建新的 UTXO 一笔比特币交易通过所有者的私钥签名来解锁 UTXO, 并通过使用新的所有者的比特币地址来锁定并创建 UTXO 在比特币网络的起始的阶段, 矿工通过一种特殊的交易类型,Coinbase 交易创造的交易的输出 ( 该交易没有输入 ), 所产生的比特币, 可以用于创建其他的 UTXO UTXO 被每一个全节点 (Full Node) 比特币客户端在一个储存于内存中的数据库所追踪, 该数据库也被称为 UTXO 集或者 UTXO 池, 新的交易构建时从 UTXO 池中消耗一个或多个输出, 而比特币网络监测着以百万为单位的所有可用的 UTXO, 世界上在比特币网络中并不存在比特币余额的概念, 因为比特币网络上只会记录所有未花费的 1 0 UTXO, 比特币的余额的概念更多是通过比特币钱包客户端派生出来的产物, 比特币钱包通过扫描区块链并聚合所有属于该用户的 UTXO 来计算该用户的余额另外关于交易费用的问题, 我们可以通过计算输入和输出的差额, 来计算一笔交易的交易费用比特币网络交易费用 = 交易输入总和交易输出总和比特币网络中的交易输入和输出数据结构 : 7 / 34

由于每一个比特币的全客户端都会对每一笔交易按照一系列的规则, 进行独立校验, 一笔比特币交易所有的交易信息都包含在脚本中, 如果任何一个节点按照脚本执行, 并对结果的有效性进行了校验, 那么其他所有节点必将得到一致性的校验结果, 这也意味着一笔有效的交易对所有人都是有效的比特币网络中的每一笔交易的执行依赖于解锁脚本和锁定脚本解锁脚本可以解决锁定脚本对某一输出值的阻碍,

8 由于每一个比特币的全客户端都会对每一笔交易按照一系列的规则, 进行独立校验, 一笔比特币交易所有的交易信息都包含在脚本中, 如果任何一个节点按照脚本执行, 并对结果的有效性进行了校验, 那么其他所有节点必将得到一致性的校验结果, 这也意味着一笔有效的交易对所有人都是有效的比特币网络中的每一笔交易的执行依赖于解锁脚本和锁定脚本解锁脚本可以解决锁定脚本对某一输出值的阻碍, 锁定脚本会在某一笔输出值上设置花费的条件解锁脚本通常包含私钥的一个签名, 也被称为 ScriptSig, 锁定脚本通常会把一个交易输出锁定到一个比特币地址上 ( 公钥的哈希 Hash 值 ) 比特币全节点客户端会同时执行锁定脚本和解锁脚本来验证某一笔交易的合法性客户端会先检索输入所指向的 UTXO, 这个 UTXO 包含一个定义了花费条件的锁定脚本, 然后客户端会读取试图花费这个 UTXO 的由客户端构造的输入中所包含的解锁脚本, 并执行这两个脚本如果从解锁脚本处复制好堆栈数据之后, 再执行锁定脚本的结果为真, 那么说明解锁脚本有权使用该 UTXO, 并发起新的交易一个简单的解锁脚本和锁定脚本的示意图如下 : 8 / 34

比特币在交易中使用脚本系统, 与 FORTH( 一种编译语言 ) 一样, 脚本是简单的基于堆栈的并且从左向右处理, 它特意被设计成非图灵完备的, 没有循环 (LOOP) 语句的一种系统在比特币网络中, 脚本系统对数据的操作都通过堆栈完成 ( 主堆栈和副堆栈 ), 堆栈是一个常用的抽象数据类型, 最主要的特点就是后进先出 (LIFO:Last In First Out) 在比特币的客户端中,

9 比特币在交易中使用脚本系统, 与 FORTH( 一种编译语言 ) 一样, 脚本是简单的基于堆栈的并且从左向右处理, 它特意被设计成非图灵完备的, 没有循环 (LOOP) 语句的一种系统在比特币网络中, 脚本系统对数据的操作都通过堆栈完成 ( 主堆栈和副堆栈 ), 堆栈是一个常用的抽象数据类型, 最主要的特点就是后进先出 (LIFO:Last In First Out) 在比特币的客户端中, 开发者把比特币客户端支持的脚本类型通过 Standard() 函数做了一个总结, 在 Standard() 函数中包含 5 种类型的脚本 :P2PKH (Pay to publickey hash) P2PK(Pay to publickey) MultiSignature( 限 15 个私钥签名 ) P2SH(Pay to Script hash) 和 OP_Return 这 5 种标准的脚本类型实现了, 通过公钥哈希支付通过公钥支付多重签名通过脚本哈希支付以及数据输出的功能通过这 5 种标准的脚本类型, 比特币客户端可以实现较复杂的支付逻辑另外, 一个非标准化的脚本类型也有可能被创建, 但是必须找到一个愿意打包该非标准化的交易的矿工, 该非标准化的脚本才会被执行我们以 P2PKH (Pay to publickey hash) 为例, 来说明脚本的产生和执行过程假设我们需要向某一个面包店支付 0.01BTC 来购买面包, 面包店的地址为 :Bread Address 则该交易的输出为 : 锁定脚本对应的解锁脚本为 : 9 / 34

10 将两个脚本结合起来可以形成如下组合脚本 : 只有当解锁版脚本与锁定版脚本的设定条件相符合的时候, 执行组合脚本时才会显示结果为真 (Ture) 要想执行组合脚本的结果为真, 也就意味着, Bread Signature 的签名是有 Bread Address 对应的私钥所签名, 是一个 Bread Address 的有效签名, 只有这样交易执行结果才会通过 ( 结果为真 ) 虽然比特币的脚本语言包含很多的操作符, 但是需要注意的是比特币脚本语言是非图灵完备的在该脚本语言中, 是没有循环功能的, 这也意味着交易的复杂性有限, 交易的可执行次数有限脚本并不是一种通用的编程语言, 这些限制也避免了潜在创造无限循环或者其他复杂逻辑漏洞的支付条件, 从而对比特币网络的安全性留下隐患在 UTXO 模型中, 我们可以通过公开的账本清晰的追溯每一笔交易的历史记录, 并且可以做到完全透明, 另外 UTXO 模型也带来了一定的并行处理能力, 可以发起多地址到多地址的交易, 为可拓展性带来一定借鉴除此之外 UTXO 模型也带来了一定的隐私性, 用户可以通过 Change address, 来作为 UTXO 的输出地址但是 UTXO 本身是无状态的, 我们将通过一系列的创新的设计, 实现基于 UTXO 类型的智能合约以太坊 Account 模型剖析与 UTXO 模型不同的是, 以太坊是有账户体系的, 在以太坊的白皮书中, 我们可以看到以太坊的账户体系 : 在以太坊系统中, 状态是由被称为账户 ( 每个账户由一个 20 字节的地址 ) 的对象和在两个账户之间转移价值和信息的状态转换构成的以太坊的账户包含四个部分 : A. 随机数, 用于确定每笔交易只能被处理一次的计数器 B. 账户目前的以太币余额 C. 账户的合约代码, 如果有的话 D. 账户的存储 ( 默认为空 ) 10 / 34

11 以太币 (Ether) 是以太坊内部的主要加密燃料, 用于支付交易费用一般而言, 以太坊有两种类型的账户 : 外部所有的账户 ( 由私钥控制的 ) 和合约账户 ( 由合约代码控制 ) 外部所有的账户没有代码, 人们可以通过创建和签名一笔交易从一个外部账户发送消息每当合约账户收到一条消息, 合约内部的代码就会被激活, 允许它对内部存储进行读取和写入, 和发送其它消息或者创建合约在以太坊系统中, 通过一个有状态的账户系统来记录账户余额, 每个账户余额的增加 / 减少更像现实世界中的银行记账方式, 每产生一个新的区块, 都会可能对全局状态造成影响每个账户都有自己的余额存储和代码区域这样合约就可以调用账户或者地址, 并且把相应的执行结果在存储区域进行存储在目前以太坊的账户系统中, 通过 client/rpc, 只能进行一对一的转账, 也就意味着每次只能从一个账户转移到另外一个账户尽管通过智能合约可以发送到更多的账户, 但是这些内部交易只能在用户的账户余额上显示, 却很难在以太坊的公开账本上追踪比特币网络的 UTXO 模型, 保证了比特币交易的连续性和可追溯性, 也是比特币架构的核心设计, 考虑到比特币的网络效应和 UTXO 模型的优点, 以及其核心系统的稳定性和安全性, 在 MagnaChain 的公链系统中, 我们决定采取基于比特币的 UTXO 模型帐号与密钥管理在区块链网络中, 账户地址是为了安全交换而设计出来的方案, 其中的账户公钥私钥生成过程存在如下关系 : 私钥 > 公钥 > 账户地址, 这三者都使用了安全散列算法 (Secure Hash Algorithm, 简称 SHA), 可确保足够的安全散列是信息的提炼, 通常其输出要比输入小得多, 且为一个固定长度以目前的技术手段, 加密性强的散列一定是不可逆的即通过用户的账户地址, 无法推导出用户的私钥信息私钥公钥账户的具体的生成过程见如下流程 : 11 / 34

2 共识机制 2.2.1 共识算法简介之前社区对共识机制的讨论较多, 从工作量证明 (PoW:Proof

12 MagnaChain 使用了与比特币完全一致的帐号管理模型, 包括双哈希计算与 base58 编码部分, 这是一套安全且经过验证的解决方案 2.2 共识机制共识算法简介之前社区对共识机制的讨论较多, 从工作量证明 (PoW:Proof of Work) 到股权证明 (PoS:Proof of Stake) 到委任权益证明 (DPoS:Delegated Proof of Stake), 再到 12 / 34

13 HyperLedger 提出的实用拜占庭容错算法 (PBFT:Practical Byzantine Fault Tolerance) 共识机制的本质在于在一个分布式系统中如何通过一些算法, 最后取得数据的一致性关于共识机制的讨论最后都会回归到计算机领域的分布式系统的一致性问题, 之前这个领域已经有很多的研究和成果, 例如分布式系统中的 FLP 定理和 CAP 定理指导人们如何根据具体的需求来设计共识机制在比特币的网络中, 矿工通过比特币的全客户端一起参与到比特币网络的校验过程, 通过工作量证明的方式, 来随机碰撞 Hash 值, 当矿工计算 Hash 值, 满足一定条件时, 我们就说该矿工挖到了一个区块也即 Hash 函数代表 2 次的 SHA256 计算, 取值范围是 [0,M],D 是 [1,M] 的一个整数, 比特币网络的 SHA256 挖矿算法可以让每一个节点快速验证区块的有效性, 并且 BlockHeader 每一个区块都随着 Nonce 和 extra Nonce 的不同而改变整体挖矿的难度会根据网络的总算力而动态调整, 根据共识协议, 让网络有分叉产生的时候, 我们会选取包含更多工作量的区块作为有效的区块后面根据挖矿算法的不同, 还产生了其他的 Proof of Work 的算法, 例如 Litecoin 的 Script 算法,Darkcoin 的 X11 算法, 设计的初衷是抵制算力集中化, 从而保证网络的去中心化目前社区所采用的 Proof of Stake 的代码大多分叉于 PeerCoin, 而 PeerCoin 是基于非常老版本的比特币代码修改的, 无法体现最近几年的 BIP 协议的特性和代码的完善性 VH-POS 算法从安全实用考虑,MagnaChain 选取 PoS, 并在其基础上改进得到 VH-PoS 共识机制 13 / 34

14 VH-PoS 不仅继承了 PoS 的优点不需要消耗额外算力即可实现产块后的权益分配, 也通过独特的算法实现, 让 51% 攻击的问题变得非常困难同时又不需要像 DPoS 机制一样, 需要特定的代理人进行验证 DPos 的做法, 本质上是对去中心化进行的一种妥协在 DPos 网络中, 持有 Token 不仅可获得合约发布网络分叉等区块链基础服务, 还能参与投票, 成为代理节点提供服务获得 Token 奖励每一个 Token 持有者称之为权益人, 根据 Token 持有数量分配相应的投票权重代理节点由权益人投票选出票数最多的代理依次轮流验证交易, 顺序由所有代理节点共同决定, 并保证无法被篡改代理正常工作可以获收益, 反之工作异常或不工作, 则会受到惩罚从理论上看, DPoS 的代理人有可能通过合谋实施 51% 攻击, 因为验证的代理人顺序是明确的, 而且也容易演化为一个中心化的网络而类似点点币 (PeerCoin) 的 Pos 机制, 则有另一个问题 Pos 的产出机制是明确与矿工的币天数相关的, 这导致双重支付攻击的成本可能降低了, 攻击者可以累积一定量的币龄来迫使区块链重组在点点币中, 为使此系统在商业上具操作性, 引入了一个中心校验机制, 每一天大概会向全网广播若干次, 以冻结区块链及结算交易这种新型的校验机制与 BTC 的警报系统类似但同样会带来中心化的担忧 MagnaChain 的 VH-POS 试图同时解决几个问题, 即 POW 算法的能耗问题, 与 DPOS 的代理人中心化问题, 以及普通 POS 机制可能发生的区块链重组, 即双花攻击与比特币相同,VH-POS 的区块归属于产出区块的特征哈希值较小的矿工但这个特征哈希值不止与区块数据有关, 也与币天数有关区块 n 的挖矿特征值 VHash_n 是由区块哈希值 BlockHash_n 与经过平滑后的币天数 (CoinDays_n) 以及调整系数 (Factor_n) 相除得来, 公式示意如下 : 14 / 34

15 其中调整系数 Factor_n 是由前 99 个块的特征值以及挖矿地址哈希异或后再取模得到, 这相当于一个可验证的伪随机数, 取值在 0 到 100 之间公式示意如下 : 同时类似 PoW 挖矿中的难度调整, 系统会限制参与挖矿计算的币天数的上限币天数的上限调整, 会动态根据前 100 个块的币天数平均值, 进行平滑调整调整系数的加入, 让矿工挖矿变成一种类似中本聪骰子 (SatonishDice) 的概率游戏即币天数越多的矿工, 越有可能挖到下一个块, 但这只是概率更高, 并不是确定的这会大大增加 51% 攻击的难度, 在 PoS 算法中, 如果攻击者有保留到足够多的币天数和帐户, 是比较容易实施 51% 攻击的, 所以在点点币中, 才需要加入中心验证机制而在 VH-POS 中, 因为难度系数和之前的若干个块的哈希, 以及挖矿地址的哈希都有关, 如果要重组区块链, 需要准备更多的币天数, 更多的帐号因为当重组完第一个块时, 会影响第二个块的难度系数, 这时需要挑选到同时拥有合适的币天数, 以及合适的地址哈希的帐号, 才有可能正确挖到下一个块这个难度会随着重组区块的个数变多, 而呈几何级数增加同时这让更多的持币数不多的矿工, 有了挖到区块的机会这会带来几个好处其一, 挖矿过程类似 PoS, 对哈希难度寻找没有要求, 没有过多的能耗需求, 绿色环保其二, 没有 DPos 中的代理或是有些 POS 实现中的中心验证机制, 更符合去中心化的理念, 也更安全其三, 因为挖矿难度大大降低, 更像是个概率游戏, 这会带来更多的矿工与活跃节点这为后续我们引入多并发的侧链, 带来了条件具体挖矿步聚 : 1. 从挖矿地址所属钱包中, 取出一个 UTXO 数据, 进行以下操作 : 15 / 34

16 2. 计算有效的币和时间的乘积, 我们记为 C, 时间以深度为单位, 将减去成熟时间 3. 计算前一百个块的 C 的平均值, 当前块的 C 值, 限制为不超过前一百个块的平均值的 105% 4. 取前一千个块内与当前块的深度之差能被 3 整除的 Block HASH, 再加上地址公钥, 计算 HASH, 并转为一个 0~100 的数, 我们记为 R, 这是一个伪随机数 5. 将币和时间的乘积 C, 剩以 R 再除以 100. 即 C=C*100/R, 这样 C 会变成从 0 到 C*R 之间的一个伪随机数 6. 取前一千个块内与当前块的深度之差能被 2 整除的 Block HASH, 再加上地址公钥, 挖矿地址对应的交易 HASH 与输出序号, 共同构成新块的 hash, 我们记为 H 7. 将 H 除以 C, 即 H=H/C, 这样 C 越大, 则 H 越小, 代表算力越大 8. 对钱包中所有的可用 UTXO, 重复以上步骤, 找到 H 最小的值, 即为当前可挖到的算力最大的块 2.3 MagnaChain 的挖矿经济学 MagnaChain 的代币产出机制, 与比特币的产出机制严格一致, 即在每产出总货币数的一半时, 让每天的产量减半除预挖的 20 亿枚代币作为运营团队及社区分配外, 矿工挖矿及营销合作等总币数在 20 亿枚在最初的 4 年, 将产生新增代币总量的一半, 之后每天的产出将减半这个减半过程平均每 4 年会发生一次, 将持续 63 次, 之后挖工挖矿将只有手续费产出, 而没有新的货币发行行出来 MagnaChain 也没有 POS 挖矿中的利息机制, 所有新增的货币全部通过在新区块中发这体现了我们对 MagnaChain 整个内部以及外部经济系统的一个思考, 也代表了我们对奥地利经济学派思想的认同 16 / 34

17 总量有限且通缩的产出策略, 有助于 MagnaChain 投资者的资产保值增值, 不会被通胀稀释由于 MagnaChain 代币与比特币一样, 可以在小数点后做 9 位数的划分, 不会有单枚价值太高而失去交易功能的问题同时, 在整个内部生态中,MagnaChain 又有与比特币不同之处在比特币挖矿的经济循环中, 矿工需要先付出法币资本, 购买矿机进行投资, 获得比特币后, 又需要至少卖出一部分换取法币来偿还投资或购买新的矿机由于比特币每天的产出量是明确的, 不管多少算力, 都只会平分掉固定的这些比特币产出矿工之间实际上进行的是一场算力的军备竞赛即矿工会持续有动力购买新的矿机, 否则就会在竞争中失败, 而产出减少所以在比特币的经济循环中, 一直会有持续的卖压要么是矿工卖出比特币购买矿机, 要么是矿机生产商卖出比特币进行其他开支的支付而在 MagnaChain 中, 每天的产出也是确定的, 只不过与算力无关, 而与币天数有关也就是说, 与比特币一样同样是进行挖矿的军备竞赛, 比特币比拼的是矿机的算力, 而在 MagnaChain 中, 比拼的是持币数额这会带来一个好处是, 矿工为了一直有收益, 就必须至少把一部分新增的挖矿收益, 投入到下一轮挖矿之中, 否则就会在竞争中落败由于没有持续的卖压, 这对稳定币价相对来说会比较有利 2.4 合约和 MLVM 的实现基于 Lua 的智能合约 Lua 是一种图灵完备的编程语言, 编译器和字节码虚拟机为在区块链中做了针对性设计和优化 MagnaChain 使用 Lua 作为 MagnaChain 区块链上智能合约编程的语言, 除了因为其轻巧灵活, 容易嵌入宿主语言之外, 还因为 MagnaChain 主要是针对游戏开发应用在当前的游戏开发社区中,Lua 作为游戏服务端常用的脚本语言非常流行在我们的设计中, 整个智能合约的编写, 也非常接近传统游戏服务端的开发这可以大大降低开发者的学习成本和上手难度 17 / 34

18 它支持静态编译成字节码并在区块链网络中按需执行合约在区块链网络中的生命周期可分为五个阶段 (1) 创建 Lua 源码 ; (2) 编译器将源码编译为 lua 字节码 ; (3) 用 Lua 字节码创建智能合约 ; (4) 调用合约 API; (5) 升级或销毁合约 ; 上述生命周期中, 合约的注册调用升级需要消耗 Token 一方面执行合约必须占用计算机资源区块链容量和网络流量, 需要对资源提供者做出奖励 ; 另一方面也是利用经济手段提高网络攻击的门槛从而降低风险为了更加稳定地执行合约, 我们构建独立 MLVM 模块, 其结构如下 : MLVM 的架构图 18 / 34

19 MLVM 包含四个模块合约通过用户控制台 (Console-User), 以命令行的形式进行编写 Cli(Command Line Interface) 是合约命令行的处理模块, 负责接收, 并将输入传递到中间层, 还负责将底层处理完的结果反馈给控制台 RPC(Remote Procedure Call) 模块负责接收来自区块链网络的 Lua 执行请求, 并将请求发送到中间层, 待合约执行完成之后将结果返回给区块链网络中间层 (Mid-Ware) 负责将 Cli 和 RPC 传来的命令和请求同步传递给底层的 Lua 编译器和执行器进行编译, 执行并将编译执行结果返回给 Cli 或 RPC Lua 编译执行器 (Lua Compiler & Actuator) 负责编译, 运行 Lua 执行环境, 接收和执行 Lua 脚本, 并将执行结果反馈给中间层一个活跃的区块链网络, 合约调用非常频繁, 为确保合约能够稳定而高效地运行 LVM 有两个设计原则 : 一是尽可能缩短进程启动和关闭时间 ; 二是任何操作在不同节点不同时间每次调用的结果必须一致 MagnaChain 中的智能合约交易在 UTXO 模型的区块链系统中,VM 部分会独立于原有的脚本语言单独存在在 MagnaChain 系统中, 存在两种交易类型, 分别是 Standard Transaction 和 Contract Transaction Standard Transaction: 标准交易类型, 我们可以简单理解成转帐交易 ; Contract Transaction: 智能合约交易, 当目标地址对应的是智能合约时, 即智能合约交易, 每次交易都会触发智能合约虚拟机执行智能合约中的对应功能 19 / 34

20 正常的类似比特币的交易类型我们标记为 Version1,Version1 的 transaction 保持与比特币网络标准交易的相似性, 对于智能合约部分我们创造了一个新的交易类型, 我们标记为 Version2 在 Version2 的交易类型中, 我们会设计以下区域 : 交易中有一个 contract 数据块, 保存了智能合约调用中需要使用的必要参数智能合约地址与调用者地址在 MagnaChain 系统中, 我们会根据以下规则构建新的合约地址类型, 该地址区别于 Standard Transaction Address Contract Address= hash160(version + publisher address + spending_vout_txids[] + spending_vout_numbers[] + contract_bytes + contract_vout_number) 当我们使用基于 UXTO 的区块链系统转帐或发起调用时, 每一个交易可能包括不同的输入, 每个输入可能来自由不同的地址, 这让智能合约在执行时, 无法确定调用者的地址在 MagnaChain 中, 我们通过在 Contract Transaction 中的 contract 数据块中, 指定一个调用者地址来解决此问题这将确保在同一个钱包中对同一个智能发约发起多次调用, 其调用者地址不会发生变化标准交易的手续费与优先级在 MagnaChain 网络中的节点产生新区块时, 节点需要为内存池中的每笔交易分配一个优先级, 并选择较高优先级的交易记录来构建候选区块交易的优先级是由交易输入所花费的 UTXO 的块龄决定, 交易输入值高块龄大的交易比那些新的输入值小的交易拥有更高的优先级如果区块中有足够的空间, 高优先级的交易行为将不需要矿工费交易的优先级是通过输入值和输入的块龄乘积之和除以交易的总长度得到的 : Priority = Sum (Value of input * Input Age) / Transaction Size 20 / 34

21 在这个等式中, 交易输入的值是由 MagnaChain 最小单位 mmgc( 百万分之一 MGC) 来表示的 UTXO 的块龄是自该 UTXO 被记录到区块链为止所经历过的区块数, 即这个 UTXO 在区块链中的深度交易记录的大小由字节来表示一个交易想要成为较高优先级, 需满足的条件 : 优先值大于 57,600,000, 相当于一个 MGC(100 万个 mmgc), 年龄为一天 (144 个区块 ), 交易的大小为 250 个字节 : High Priority > 100,000,000 mmgc * 144 blocks / 250 bytes = 57,600,000 区块中用来存储交易的前 50K 字节是保留给较高优先级交易的节点在填充这 50K 字节的时候, 会优先考虑这些最高优先级的交易, 不管它们是否包含了矿工费这种机制使得高优先级交易即便是零矿工费, 也可以优先被处理然后, 挖矿节点会选出那些包含最小矿工费的交易, 并按照每千字节矿工费进行排序, 优先选择矿工费高的交易来填充剩下的区块, 区块大小上限为 MAX_BLOCK_SIZE 如区块中仍有剩余空间, 挖矿节点可以选择那些不含矿工费的交易有些矿工会竭尽全力将那些不含矿工费的交易整合到区块中, 而其他矿工也许会选择忽略这些交易智能合约的手续费与优先级智能合约的优先级与标准合约基本一致, 但有一些细微区别, 包括 : 发布智能合约的交约, 优先级会是同一个区块内调用这个智能合约的调用之和, 来保证发布合约的交易总是会比后续的调用优先打包入区块内同时, 在计算所算的手续费时, 会添加对当前调用的虚拟机指令执行个数和合约执行后状态保存需增加的字节数的计算, 这部分类似以太坊中 Gas 的计算最终的计算公式如下 : Contract Transaction Fee = Stand Transaction Fee + Vm Runtime Code Count * CodeFee + State Added Size * State save Fee 并发调用与调用顺序 21 / 34

22 设想在同一个区块产生周期内, 两个用户同时对同一个智能合约发起调用 A 发起 a1,a2 两次调用,B 发起 b1,b2 两次调用这四次调用都将会对虚拟机保存状态产生影响那么最终的执行顺序和结果是怎样的在 MagnaChain 系统中, 最终调用顺序和结果由矿工产生的区块决定矿工在区块中将按以下原则决定调用顺序 : 1. 同一个调用者发起的调用, 在区块中的调用顺序与调用者的发起顺序一致 2. 多个调用者并行发起的调用, 遵从与所述的交易费与优先级原则, 优先级高的优先打包进区块, 并优先发起调用 2.5 并发式侧链技术设计理念 MagnaChain 在设计之初, 即希望解决当前区块链平台的两个问题, 即吞吐率过低以及数据累积过多的问题我们的解决方案是引入并发式侧链技术侧链是比特币社区最先提出的一个概念, 相当于在主链之外, 可以有多条并行的区块链, 用户的虚拟资产可以在多条链之间自由的转移最初是为了解决比特币网络拥堵的二层网络的区别简单理解并发式侧链技术与传统的区块链的区别, 就类似于 CPU 中的多线程与单线程 22 / 34

在 MagnaChain 的实现中, 整个网络有一条唯一的主链, 新货币只在主链的区块中发行同时可以有任意多条侧链, 每条侧链的前一个块, 可以是主链中的某个块, 也可以是另一条侧链中的某个块整体数据结构是一棵树, 而不是一条链用户可以通过指令, 自由的创建侧链, 也可以用特殊的交易, 自由地将代币从一条链移往另一条链

23 在 MagnaChain 的实现中, 整个网络有一条唯一的主链, 新货币只在主链的区块中发行同时可以有任意多条侧链, 每条侧链的前一个块, 可以是主链中的某个块, 也可以是另一条侧链中的某个块整体数据结构是一棵树, 而不是一条链用户可以通过指令, 自由的创建侧链, 也可以用特殊的交易, 自由地将代币从一条链移往另一条链这样我们可以为某个应用, 甚至某个应用的某个模块, 单独开一条侧链使用过程中也可以再灵活调整矿工可以自由地选择在多条链上进行挖矿侧链上虽然没有新货币发行, 但也会有交易费交易越多, 则费用也会越多当某条链矿工比较少, 挖矿有利可图, 就会吸引新矿工加入, 而如果某条链矿工很多而交易很少, 慢慢矿工就会变少整个挖矿就像一个市场, 通过 23 / 34

24 交易费的激励, 自动地调节矿工与多条链的关系, 让矿工在最合适的链上挖矿这会让整个网络的吞吐率, 即每秒交易数 (TPS) 达到一个很高的级别在传统的区块链项目中,TPS 的计算可以通过简单的 ( 每区块最大交易数 / 出块时间 ) 来计算得出, 如比特币是每块 4000 笔交易, 每 10 分钟出一个块, 那么 TPS 只有 4000/ (10 *60) = 6.6 笔, 即每秒大约 6 笔链个数而在 MagnaChain 中, 由于有多条链并发在处理数据, 总吞吐率是单条链的 TPS * 侧 24 / 34

25 在 MagnaChain 中, 每块可以处理笔交易, 平均约 8 秒出一个块, 那么每条链的 TPS 是 / 8=2000 笔那么当有 500 条侧链在跑时, 则可达到 100 万的 TPS 总的吞吐率变成不但会更高, 而且可以随时动态地按需调整极限只受限于整个网络的 IO 极限, 可以比较容易地达到 100 万的 TPS 除了极大的提高了 TPS 外, 并发式侧链还有另一个好处, 对于开发者来说, 只需要同步主链与当前应用所在的支链相关的数据, 而不需要同步整个网络所有支链的数据这可以大大减少用户的磁盘空间占用, 以及对网络带宽的需求具体实现方式 : 支链的创建首先需要在主链上构造一个创建支链的交易, 交易里包含了新链的 DNSSeed( 种子服务器的域名 ) 和 SeedSpec6( 拥有 ipv6 地址和端口的种子节点 ) 数据, 和足够虚拟币作为创建押金创建支链的交易需要经过足够多的确认后, 新链才能生效创建押金是根据当前已创建的支链数来确定的, 且呈指数级上涨, 需要经过大约半年时间才能赎回其中的设计意图是为了防止恶意创建支链攻击创建押金在主链上被输出到永久锁定的地址上, 同时新建一个押金赎回交易, 该交易被序列化包含进创建支链交易里等创建支链交易经过个确认后, 大约 183 天, 押金赎回交易被发往新链上当新链收到押金赎回交易时, 会检查本地是否已经收录的该交易, 若没收录, 则向主链查询该押金赎回交易是否有效当所有安全检查完毕后, 赎回交易才能被打包进新链的区块中, 这样押金在新链上被赎回了篡改赎回交易直接包含在创建支链的交易里, 使得赎回交易的数据受到签名保护, 防止恶意表 - 创建支链交易的结构字段描述 version 创建支链的 version id 25 / 34

26 vin vout dnsseed SeedSpec6 txhexdata 普通 vin 押金在主链上被输出到永久锁定地址上新链种子服务器的 host 固定种子服务器,ipv6 地址和端口押金赎回交易的 hex 数据, 该交易的 vout 包含押金输出图 - 创建支链主链创建支链 tx1 块 n 激活新链块 n+500 从 tx1 取出押金赎回 tx2 块 n 支链新链生效 tx2 被新链打包跨链交易主链和支链之间可以相互交易, 即可以在主链上向支链某个地址发起交易, 反之亦然首先在源链创建跨链交易, 指明向哪个目标链的哪个地址发起交易, 交易会把转到目标链的币输出到永久锁定地址上, 同时包含另外一个目标链交易, 该交易包含实际在支链的输出等跨链交易在源链中经过足够的高度后, 目标链交易才被发送到目标链上通过足够高度可以保证跨链交易不能被撤销最终目标链交易被目标链打包, 跨连交易完成表 - 跨链交易的结构字段 version 描述跨链交易的 version id 26 / 34

27 vin vout 普通 vin 目标链的输出在源链上被输出到永久锁定地址上 branchid txhexdata 目标链的 id 目标链交易 tx2, 该交易的 vout 包含真正目标链输出图 - 跨链交易源链创建跨链交易 tx1 块 n 块 n+500 tx1 里取出 tx2 目标链 tx2 被新链打包创建支链交易和跨链交易的 txhexdata 所包含的交易 tx2 是相似的,tx2 里也包含了一小笔虚拟币, 用于奖励矿工的费用, 确保 tx2 顺利在目标链上打包创建支链交易和跨链交易的验证都需要启动对应的链链间交易通信通过 rpc 接口来完成, 为确保通信安全, 各个链节点都配置了 rpc 用户名和密码主链矿工为了验证所有的跨链交易, 需要启动所有的支链支链矿工则需要启动主链和所在支链, 主链可以通过配置关闭验证其他支链的交易, 交由网络上的其他矿工去验证优化方案 27 / 34

28 当前做法的限制在于, 这对主链的矿工有一定的要求, 因为主链矿工需要同步主链及所有的支链数据, 才能确保整个网络的安全性当整个网络的支链条数变多时, 对主链矿工的磁盘和带宽要求会比较高, 目前可以通过用服务器集群的方式来解决我们希望在将来有更好的实现方式当前期望的解决方案是 : (1) 支链矿工在挖矿前在主链上抵押资产, 支链挖矿时, 会将支链的区块头写入主链, 区块头内包含支链区块的 Markel Tree 的根 (2) 主链矿工不再监视所有支链 (3) 有一个在链上的举报机制, 如果支链矿工做恶 ( 比如创造不存在的交易, 将其他用户的资产转入特定账户 ), 任何用户均可在链上举报, 举报内容包括指出某个不存在的交易输入举报需要一定的代币做抵押 (4) 这时支链矿工将对举报内容做出回应, 用某个区块头的 Markel true, 以 SPV 证明的方式来证明这个交易的输入是存在的 (5) 如果支链矿工的证明能通过, 则支链矿工可以继续挖矿, 且举报用户的抵押代币将归矿工所有如果证明不能通过, 则支链矿工为了挖矿而抵押的代币将归举报者所有这个做法增加了系统的复杂性, 但降低了对主链矿工同步的要求同时安全性会比现在的做法稍弱我们将在测试链上线后, 尝试实现这个优化方案 2.6 开发工具的集成与支持我们将提供一系列工具, 方便开发者快速上手, 快速上线包括 Unity,Cocos 等引擎插件, 智能合约生成工具等 28 / 34

29 我们的最终目标是,MagnaChain 会成为和 Unity 一样的集成开发工具对中小游戏的开发来说, 利用基于区块链的分布式应用开发技术, 可以完全不需要后端程序, 即可完成游戏的开发与发布 29 / 34

30 3 竞争公链较 EOS NEO LISK GameChainSystem 运营中共识机制 VH-POS PoW PoW DPoS DBFT PoS DPoS DPoS/LPoS PoS DPoS 出块时间 5 秒 10 分钟 15 秒 0.5 秒秒 2 分钟秒 1 分钟 - 目前 TPS 最高值 > 1,000, ,000, 目前 TPS 最高值 13, ,275 1, 区块链大小 Gb 75 Gb 区块链增长速度 Gb/ 月 187 Gb/ 月可运行行 dapp 多重签名 - 扩展方案支链 - Sharding 分区支链智能合约 / 使用语言 Lua Solidity C/C++ C#, Pyton, Java Solidity 使用语言 C/C++ C/C++ C/C++ C/C++ Pyton, JS, VB,.Net, C++ C/C++ Javascript Javascript Java - 30/34

31 4 路线图 2016 年全年原型开发 2017 年 Q2 原型测试 / 添加智能合约 Q4 结构更新 / 加入支链 Q2 外部测试 / 测试链上线召开及参加各项开发者大会 2018 年 2019 年 Q3 软件开源 Q2-Q3 第一款游戏或应用上线 Q3-Q4 主网上线 Q4 商业合作和技术支持中心开始成立 / 50 款以上游戏及应用上线 Q1 更新版本的测试链上线全年全球技术支持中心的扩展 / 1000 款以上游戏及应用上线 31 / 34

32 5 免责声明该档只于传达信息之途, 并不构成买卖 MagnaChain 代币的相关意见以上信息或分析不构成投资决策本档不构成任何投资建议, 投资意向或教唆投资本档不组成也不理解为提供任何买卖为或任何邀请买卖任何形式证券的为, 也不是任何形式上的合约或者承诺相关意向户明确了解 MagnaChain 的风险, 投资者旦参与投资即表了解并接受该项风险, 并愿意个为此承担切相应结果或后果 MagnaChain 团队不承担任何参与 MagnaChain 项造成的直接或间接的资产损失 32 / 34

33 6 参考文献 [1] Satoshi Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. bitcoin.pdf. Oct 2008 [2] Vitalik Buterin. Ethereum White Paper : A Next-Generation Smart Contract and Decentralized Application Platform. wiki/white-paper. [3] Wikipedia. Directed acyclic graph. [4] Serguei Popov for Jinn Labs. The tangle. April [5] Anton Churyumov. Byteball: A Decentralized System for Storage and Transfer of Value. [6] Wikipedia. PoW. [7] Wikipedia. PoS. [8] "Nxt Whitepaper (Blocks)". nxtwiki. Retrieved 2 January [9] mthcl (pseudonymous). "The math of Nxt forging" (PDF). pdf on docdroid.net. Retrieved 22 December [10] Vasin, Pavel. "BlackCoin s Proof-of-Stake Protocol v2" [11] [12] Ori Brafman. The Starfish and the Spider: The Unstoppable Power of Leaderless Organizations / 34

34 [13] Yochai Benkler. Wealth of networks: How Social Productions Transforms Markets and Freedom [14]HOFFSTEIN J,PIPHER J,SILVERMAN J H.NTRU : A ring - based public key cryptosystem [15]LYUBASHEVSHY V,PEIKERT C,REGEV O.On ideal lattice and learning with errors over rings [16] Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gregory Maxwell, Andrew Miller, Andrew Poelstra, Jorge Timón, and Pieter Wuille.Enabling Blockchain Innovations with Pegged Sidechains.2014 [17] Sergio Demian Lerner.RSK White paper Overview [18] Sergio Demian Lerner.Lumino Transaction Compression Protocol (LTCP) [19] Sergio Demian Lerner.Sidechains and Drivechains, A view on 2-way peg designs / 34

PowerPoint 演示文稿

PowerPoint 演示文稿 The BitCoin Scripting Language 交易实例交易结构 "result": { "txid": "921a dd24", "hash": "921a dd24", "version": 1, "size": 226, "locktime": 0, "vin": [ ], "vout": [ ], "blockhash": "0000000000000000002c510d