Cartesi和他的二层野心

Cartesi和他的二层野心

“能让DApp开发者使用所熟练的编程语言,工具,库,软件基础设施及服务去开发区块链应用,将极大的提高DApp开发效率,我们要实现这个梦想。“,在上海新天地朗廷酒店户外的开放咖啡空间,Eric,这位颇具南美风情的创业者在给我们讲解他的项目核心,一个能摆脱现有合约执行虚拟机的桎梏,并用所熟知工具集来开发合约的新的方式,Cartesi Machine,一个可验证的RISC-V虚拟机。

共识的范围论

如果说要给现有的公链下定义的话,可以高度归纳为这一句话:公链是一种机制,这种机制可使得一个去中心化的网络在某一种共享状态下达成共识。机制的背后运作是经济的激励和博弈,他们需要网络中所有的参与者永久的保存并验证所有的交易,这种全冗余的设计方式低效性是制约交易速度的根本阻碍,伴随而来的高昂的交易费用和确认延迟,对区块链应用落地,创新,形成一种障碍。目前对区块链性能提升的尝试可以归于Layer-1和Layer-2两大类,一层的优化包括诸如提升区块大小, 分片,DPoS这类,但在更基础设施级别的优化尝试,始终受制于保持全局共识的这个核心需求,举步维艰。虽然对于货币支付系统而言,保持全局共识是至关重要的,这无可厚非,但对于其他大量区块链应用,执行交易验证的节点范围可以安全的缩小到那些只受其影响的利益相关方(例如对于某一种DApp而言,共识范围只需要在DApp用户之间即可),我们可以初步认识到一个事实:

“共识的范围大小正比于交易执行的成本。“

基于这个事实,二层网络例如Plasma,侧链,TrueBit,状态通道,把数据和计算从全局范围的链上共识移到链下进行局部共识,而昂贵的链上全局共识只扮演一个并不频繁现身的仲裁法庭角色。

计算环境与可重现性

每一步计算都会影响交易,不管是链上计算还是链下计算,计算过程必须被验证各方完整重现。可重现计算模型一定是自包含且确定性的。换言之,整个计算的状态-计算上下文,和对此状态(计算上下文)改变的计算过程,必须是明确的且已商定的。可惜的是,真实世界的计算体系并不满足可重现性约束,因此真实世界的计算体系并不是可重现的。现存的区块链平台通过一个定制化的虚拟机(VMs)用于处理合约(例如EVM),暂时满足了计算的可重现性需求,但计算能力却又局限在特定功能领域,一方面来说,他们(如EVM)提供了满足可重现智能合约功能支持(例如:审计,回滚,关联存储器,身份鉴别,密码这类功能等),但严重缺乏通用计算中的许多宝贵特性(例如:浮点计算,虚拟内存,中断等)。

纵观过去20年来的发展,软件能力的提升主要可归于两个方面,一是硬件平台的性能指数提升使得软件可以处理大量数据,同等重要的第二点,是软件开发环境带来的生产力不断提升(例如golang的口号是: The Go programming language is an open source project to make programmers more productive,可见开发效率是核心关注。)。真实环境下的计算并非是割裂的程序孤岛,实际上,绝大多数软件都是由一堆分散的功能模块整合而来,这些模块和服务也依赖于操作系统提供的标准功能(内存管理,进程管理,文件系统,网络等),操作系统把这些模块有机的整合到一起协同工作,可惜的是,这种软件组织方式在典型的提供智能合约开发的区块链中并不能提供,甚至连编程语言和编译器也缺乏标准支持,于是不同的实现会产出各异的执行结果。

可重现性和伸缩性的同时关注(共识需求所致)使得链上计算环境非常受限,要提高区块链开发的效率和适用范围,我们需要一个支持现代操作系统可重现的计算模型

Cartesi

Cartesi DApp是一种混合模式,包括链上和链下两个部分。
链下部分运行在一个Cartesi Nodes组成的网络中,链下部分可再细分为两个模块,直接运行在宿主机的本地计算,虽然本地计算可以访问节点的全部计算能力(包括GPUs),但论其计算本质则是不可重现的。可重现计算运行在Cartesi Machine中,受Cartesi Node控制,这是一种完整的,运行在确定性的RISC-V平台上的自包含的Linux系统(self-contained deterministic linux system),节点通过一些确定的主机接口和Cartesi Machine进行交互。

DApp开发者可以指定链下计算采用可重现方式,Cartesi Nodes会自动根据所指定方式执行离线计算,DApp开发者可以请求节点提交结果,验证交易和辩论其他节点提交的结果。从链的角度来说,处理有争议的计算只需占用微不足道的资源,当争议发生,争议处理成本只是存储和时间的对数复杂度,即O(logN),离线部分的Cartesi Nodes计算复杂度,也只是线性开销O(n),且常数不超过2。通过这种方式,Cartesi事实上填平了传统计算和合约计算之间的计算和存储能力缺口

把计算移到链下会获得除了伸缩性之外的另外的好处,例如Cartesi Machine让开发者使用其所熟练的开发语言,工具,库,软件和服务变得可能了,此外,由于Cartesi就其本质来说,计算的组织形式和底层区块链类型并无关连,那么通过把现有的复杂的合约逻辑隔离到链下进行可重现计算,开发者甚至可以使其DApp能够做到跨链交互

和TrueBit相关性

和Cartesi最相近的项目是TrueBit(作者多次在文章中提及TrueBit,可惜团队已经分裂,幸运的是Cartesi是更好的一个方案。)。Cartesi和TrueBit都是把密集计算移到链下的技术,链上做验证游戏(verification game)来解决计算结果的争议,除了这点相近之外,设计方案有较大差异。

TrueBit是基于WebAssembly这个怪兽做的虚拟机,WASM是W3C Community Group用于支持高效web应用的指令集架构(ISA),而Cartesi是基于RISC-V的开放指令集架构,这个指令集是UC Berkeley设计用于硬件实现的(如:SiFive公司生产RISC-V芯片)。就复杂度而言,WebAssembly和RISC-V旗鼓相当,主要差异在于其定位分别是application级别和os级别。WebAssembly是被设计用于应用程序间粘合或者应用程序和宿主OS的交互(注意这里引入的外部性,indeterministic!),RISC-V则处于操作系统和application之下更为底层的承载。TrueBit技术选型关注点在于扩展合约的计算能力(contract computational power boost),其运行在严格约束的环境下,真实世界的应用程序不可能割裂存在,他们依赖于现代操作系统所提供的运行时环境,开发者能够使用环境中他们熟知的工具,库,服务,软件来开发去中心化应用,Cartesi选择了去支持Linux运行时环境,因此一个真实的ISA,即RISC-V,会更好的服务于这个目的。

Cartesi在协同链下计算的利益和责任和其他设计有很大不同(激励层面)。在TrueBit内部并没有这种协同,智能合约将计算需求提交至一个非置信方构成的池子,并等待其中一个参与者执行离线计算并发回结果。在某种意义上,TrueBit可以看作是为那些不同种类的合约增强算力的,并通过一个复杂的激励层去奖励成功的争议。但为了保持成员的参与度,带有错误结果的计算(诱饵)必须被人为的注入到激励层中去以保持成员的兴奋度和参与感,这种低效性激励是TrueBit设计中必须存在的部分。相反的,Cartesi可以被看作是一种依赖智能合约背书的线下计算形式,所有受此背书影响的参与方都有责任去执行离线计算,并在需要的情况,对争议结果进行辩论,虽然这个过程可以外包到一个争议解决市场去解决,但在激励层并不存在TrueBit激励层中人为投放诱饵的问题。

此外,现实世界的计算通常包含大型存储,这个挑战TrueBit并未处理,大型数据和代码的直接表达并不适合在区块链上直接出现,利用Cartesi Machine,因其代码和数据状态的哈希值(计算环境上下文的Hash值,严格来说是整个运行中的RISC-V虚拟机)是会提交到链上的,并且由于计算上下文只需要在利益相关方节点中存在(共识范围的缩小),这种设计使得多轮链下计算成为可能(多阶段的长期性的计算事务),最终,在这样的结构下,Cartesi可以做到离线计算的跨链性

和一层扩容方案的对比

Vitalik提出的扩容三难困境指出没有一个简单的办法能够在提高交易性能的同时不会减少去中心化或者不会减少区块链的安全性。换句话说,要求提高节点吞吐量必会提高节点运营成本,进而导致算力的中心化,变成一个只有少数玩家才能玩得起的游戏,另一方面,如果把大的共识范围割裂到几条独立的链,缩小共识范围,会导致每条链更容易受到51%攻击。

针对以上问题,流行的两大扩容方案分别为,1. DPoS,让一个小范围的超级节点去验证所有交易,节点通过民主投票而选定。2.分片,独立验证,这些独立分片会链接到一条主链以减少成功攻击的机率。这两种想法都希望极大的提升区块链的交易处理能力,但都不可避免的需要对每个交易都达成全局共识,当计算规模扩大时,全局共识开销会加速提高。

Cartesi只试图达到计算的本地共识(相对于全局共识),准确的说,只有利益相关方才需要执行复杂计算,且由于链上争议处理成本很低,这使得只有DApp利益相关方才需要执行密集的链下计算,并交由链上合约确保执行结果的争议调解能力。这样,DPoS和分片技术与Cartesi是正交关系,Cartesi可以通过Cartesi基础设施获得更快速和廉价的交易,而区块链受益于Cartesi去提供更实用丰富的应用计算。

和二层扩容方案的对比

各种各样的二层解决方案被提出用以提高区块链的性能,即交易吞吐量,例如Plasma,State Channels,各有千秋,但就其本质讲,是让大量的交易在链下进行,并只在需要最终性确认的时候,或者在出现争议的时候提交到链上仲裁。这类方案普遍需要区块链能解决任何可能出现的争议(当Plasma退出,或者通道被关闭),但这些交易关闭机制限制了最大交易体量(计算量),比如对于双方需要大量计算的才能完成的争议处理过程,主链是无法正确的处理分歧的。

Cartesi能极大改善以上技术,它允许Plasma和State Channel执行大型交易,如果分歧发生了,主链依然能够高效和正确的解决分歧。

信用解决方案

有一类项目试图把大规模灵活性计算带入区块链,并依赖于一个由冗余,信用,验证构成的系统(例如SONM,Golem,iExec),虽然这类系统设计各异,但本质上是把计算提交到离线计算服务提供者,由其独立提交计算结果,如果有任何人尝试挑战这个结算结果,由一个被系统随机指派的验证者来判定谁是合法的。

虽然这类系统有内置的信用解决方案用于争议避免,作弊避免,但这种方案在同谋或贿赂的考验下(collusion and bribing)是否依然存在抵抗力始终是个未知数。而Cartesi在这个问题上提供了数学上的保证。

可信执行环境

还有一类项目是利用enclave技术(例如:Intel’s SGX, ARM’s TrustZone, or AMD’s SEV)做链上解决方案。概括地说,enclave技术是一种硬件技术,这种技术使得代码可以运行在一个受到硬件保护的环境中,其隐私性和完整性通过硬件确保。

Enclave中的计算并不能保证可重现性,使用远程佐证(remote attestation)技术的验证方式等同于信任硬件生产商,采用这种中心化方式开发的合理性选择则取决于应用本身,厂商竞争,利益博弈等外在条件,即便不考虑这些外在因素,隐私性也并不能够完全保证,例如针对enclave的旁路攻击也出现过。

不可否认的是,enclave技术在未来区块链发展中,仍将会扮演重要角色,但其风险模型和安全保障和Cartesi有极大差异。在未来,应用程序可能希望在Cartesi Nodes中,部分使用enclave完成计算,甚至可以把整个Cartesi Node运行在enclave中(maybe “A privacy-preserving self-contained deterministic linux based on RISC-V virtual machine for DApps“ ^-^ )

零知识证明

另外一种能同时保证隐私性和伸缩性的技术是通用零知识证明技术,例如zk-SNARKS,这类系统能够以快速,非交互并且私密方式执行交易验证。然而,这种模型下的可计算形式非常受限,其计算模型本质上是不带控制逻辑的电路计算,因此并不是图灵完备的

在链下计算环境中,零知识证明正在变得越来越成熟,例如Pinocchio, libsnark这类项目。零知识证明最开始出现在区块链中,是用于隐私币,通过保护交易方的地址,以保护身份。在以太坊的Metropolis分叉中,也引入了zk-SNARKS元语到以太坊虚拟机中。就目前环境而言,Cartesi可以提供离线的zk-SNARKS实现来加速开发过程。

编译器和虚拟机

除了以上提到的伸缩性解决方案以外,有些项目试图提供用于合约编写的不同语言,类似于Vyper,LLL,Bamboo,虽然这些项目提供了一套方便开发合约的语言和工具集,但并没减轻区块链开发的根本困境,主要原因是这种开发形式是割裂的,并不能充分利用底层操作系统提供的成熟开发和运行环境。

更多的Cartesi的虚拟机设计细节可以参考cartesi的白皮书

(完)

编辑于 2019-03-07

文章被以下专栏收录