Arbitrum和Optimism是以太坊Layer2扩容的主要项目，因为两者是以Rollup为技术核心实现的二层扩容，符合以太坊未来发展方向。
但面对未来丰富的生态应用预期，需要一个虚拟机来实现可编辑能力。因为Rollp的技术核心，却让这个方向成为一个实现略难的技术需求，目前两者也限于虚拟机并不成熟。使得在这一层的可编辑能力有所限制。
今天本文中，我们将摘录资料来了解Arbitrum网络的虚拟机设计原理。
AVM设计的起点是基于以太坊虚拟机(EVM)，因为Arbitrum目标是高效地执行为EVM编写或编译的程序，所以Arbitrum并未更改EVM设计的绝大部分。例如，AVM采用EVM的数据类型以及对EVM整数进行的操作指令等。
金色相对论 | William：Compound与Fcoin机制设计上的显著不同在于是否有分红机制:7月16日消息，在今日举行的金色相对论中，针对“DeFi项目总市值快速增长的市值是否合理”的问题，OKEx Research首席研究员William表示，DeFi项目总市值的迅速增长出现在Compound发行COMP之后，是由Token激励带来市值和交易量的上涨。其实大家不需要对“流动性挖矿”过度神话，其本质是一种用户补贴，这种快速增长的市值从中长期看并不可持续。Compound项目的成功很大程度上在于其发行的COMP价格一路高涨；但同样的，如果COMP代币的价格降低或放缓，用户就没有了继续在Compound上“提供流动性”的动力，进而会减少在平台上的借贷交易。
刚刚提到Compound与Fcoin的区别，双方在机制设计上有一个显著不同：Ft当时有分红机制的，即持有Ft可享受交易费分红，但Compound没有。Fcoin的暴雷很大程度上是由分红机制引起的---当时Fcoin的后台财务系统没有建设好，导致分红出现问题，Fcoin产生很多亏损。
分红机制可以增加用户对Token本身的粘性，但容易带来财务风险；COMP去除该风险，但却少了用户粘性，所以COMP的繁荣时间变得更短，仅仅只有半个月的时间。
由于COMP每天发放的数量固定，随着平台借贷规模的不断上涨，每借贷出价值一美元的资产，其所能分配到的COMP数量将会下降。当用户借贷能获取的COMP收益低于所需支付的成本时，类似开始十天的疯狂增长便会放缓。因此大家可以看到，COMP的神话持续时间仅仅是6月下半旬，无论是Comp价格、交易量，还是锁仓价值。[2020/7/16]
这样看来，AVM和EVM之间的差异源于Arbitrum的layer2需求和Arbitrum的多轮挑战协议。
金色晚报 | 7月2日晚间重要动态一览:12:00-21:00关键词：央行、LBCoin、比特币巨鲸、链上党建
1.立陶宛数字货币LBCoin将于下周开始预售。
2.日本央行公布央行数字货币技术课题总结报告。
3.斯里兰卡央行将启动基于区块链的KYC平台开发计划。
4.比特币巨鲸Joe007：一旦衍生品危机爆发加密市场将无法幸免。
5.StrixLevithan首席信息官质疑PlanB提出的S2F模型。
6.前高盛高管：比特币是针对全球央行不确定性的“看涨期权”。
7.加拿大银行：数字美元应具有可访问性和包容性。
8.黑龙江省基于区块链的党建服务平台“链上党建”启动。
9.Coinbase被美国法院视为传统银行，其交易记录不受第四条修正案保护。[2020/7/2]
执行与证明
金色财经现场报道 Coinbase CTO：第三波入场的投资者将来自小额支付:金色财经现场报道，今日在Coindesk 2018共识会议上，Coinbase的CTO Balaji Srinivasan称：“目前像微软这样的公司正在密切关注加密行业。当VR达到了iPhone目前的状态，自然的交易形式将变为加密货币，但我们必须首先建设基础设施。如果Twitter将世界变成出版商，那么区块链将世界变成投资者。目前有三种类型的投资者入场，投资者数量正在迅速增加。第一波组是数字黄金，第二波是智能合约，我认为第三波将是小额支付。”[2018/5/17]
与EVM架构不同，Arbitrum需要支持本地执行和受信证明。基于EVM的系统通过重新执行有争议的代码来解决争议，而Arbitrum依赖于形成最终证明的挑战协议解决争议。
Arbitrum希望在本地可信环境中针对速度做优化执行，因为本地执行是常见情况。系统很少需要证明，但需要一直保持准备证明的状态。
操作系统
Arbitrum使用2层操作系统ArbOS。ArbOS控制单独合约的执行，以将它们彼此隔离并跟踪它们的资源使用情况。
此外，上面这些功能是执行在2层的可信软件中，而不是像以太坊那样将可信添加到的1层网络搭建的强制规则中，这样参与者都会从2层较低的计算和存储成本中受益，而不是必须将这些资源成本作为1层EthBridge合约的一部分进行管理，增加成本。
Merkleize
任何依赖断言和争议解决的2层协议都必须定义一个规则，用于对虚拟机的完整状态进行Merkle哈希。该规则必须是架构定义的一部分，因为它依赖于解决争议。
维护的Merkle哈希在需要重新计算时也需要保持有效。这会带来一些构建内存的影响。任何大型且可变的存储结构对于Merkleize来说都是较贵的，并且Merkleize的算法必须是架构规范的一部分。
AVM架构通过只有大小有限、不可变的内存对象来应对这一需求，这些对象可以通过引用包含其他元组。元组不能就地修改，但有一条指令可以复制带有修改的元组。这允许构建树结构，其行为类似于大型平面存储器。通过访问在内部使用元组的库，应用程序可以使用诸如大型平面数组、键值存储等功能。
元组的语义使得创建元组的循环结构变得不可能，因此AVM实现可以通过使用引用计数的、不可变的结构来安全地管理元组。每个元组值的哈希只需要计算一次，因为内容是不可变的。
代码点
代码的常规组织是存储指令的线性阵列，并需要保持指向下一条指令的程序计数器。使用这种传统方法，证明执行指令需要对数时间和空间，因为必须提供Merkle证明来证明当前PC下的指令。
AVM使用这种传统的执行方法，但它增加了一个功能，使证明和证明检查需要恒定的时间和空间。出于证明目的，“程序计数器”被替换为“当前代码点哈希”值，它是机器状态的一部分。
在正常执行中，实现通常只使用传统架构上的PC值。但是，当需要证明时，证明者可以使用查找表来获取与任何相关PC对应的代码点哈希值。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。