总体架构
#
概述#
隐私计算基础设施随着互联网的蓬勃发展,以FAANG和BAT为代表的互联网巨头借自己的垄断地位,存储了大量用户数据,并以此为基础通过大数据以及AI计算,挖掘和享受数据的价值。用户不但未能获得数据的红利,而且承担着个人隐私被侵犯、个人数据被滥用的风险。
下一代互联网应该是无服务器的互联网,是去中心化的网络。在这个互联网里,用户完全拥有自己数据的所有权,未经允许,任何人任何组织都不能使用他人数据。但因此也带来以下问题:
- 任何单一实体永远都只能掌握数据集合的局部,而没有任意实体可以获取所有的全局数据。每个参与者都是“盲人”,其拥有的数据不足以反映全量数据—“大象”的特征。
- 参与者之间是弱信任甚至是无信任的,无法通过“可信任第三方”来归集计算数据,并验证数据的有效性,从而共享价值、信息和资产。现在方兴未艾的云计算平台是一个典型的“可信任第三方”。
PlatON致力于建设下一代隐私计算架构和数据交换网络,基于现代密码技术和区块链技术,创造全新的计算范式,保证用户数据隐私的前提下,无需依赖第三方就可进行协同计算并验证结果的完整性。
#
可扩展的隐私计算方案#
区块链:基于共识的计算广义上看,现有的区块链架构都是一种基于共识的计算,也就实现了一种简单计算(智能合约形式)协议:为了保证计算的正确性,每个计算操作都需要经过绝大多数节点的重复处理来验证计算的正确性,导致了区块链体系里效率和可信任之间的内在矛盾。
从实用性角度看,业界核心还是关注两个问题:可扩展性和隐私性。
可扩展性已经公认为区块链的最大难题。当前主流的区块链每秒处理交易数不高,与运行主流金融市场所需的处理能力相差几个数量级。虽然业界也在积极实施各种解决方案,但受限于”不可能三角“,都是以牺牲去中心化或安全性为前提的。区块链基于共识的计算方式也限制了智能合约不能支持复杂的计算逻辑。
隐私是区块链的另一个主要问题。尽管区块链的不可篡改、去中心化、无需信任等优势是诱人的,但其跟大数据和AI技术同样面临获取不到数据的困境,无论是公司还是个人,都没有意愿将隐私信息发布到公共账本中,这些账本可以不受限制地被政府、家人、同事和商业竞争对手随意读取。
#
PlatON:非交互证明的隐私计算PlatON使用包含且不限于零知识证明(ZKP)、可验证计算(VC)、同态加密(HE)、安全多方计算(MPC)、秘密分享(SS)等现代密码算法来实现非交互证明的计算扩容方案。
#
可扩展性现有区块链架构的问题源于两个很重要的部分:共识和计算耦合太紧密了。PlatON提出一种可验证计算的方案,能从本质上把两者拆开,对这两个问题分而治之,通过数学上可证明的密码学算法,弱化他们的内生绑定关系。
鉴于链上共识既有的局限性,链上的功能应该是”验证”而不是“计算”。虽然链上已经公认为是一个无需信任的环境,但是链下方案的实施又引入新的不信任因素。PlatON的可验证计算(VC)密码学算法将信任传递到链下。通过可验证计算,合约只需要在链下计算一次,所有节点可以快速验证计算的正确性,一方面提高了交易的处理性能,另一方面也使得PlatON支持复杂合约的Trustless计算。
#
隐私性PlatON通过叠加同态加密(HE)和安全多方计算(MPC),实现真正的隐私计算,保证输入数据以及计算逻辑本身的隐私。与依赖第三方制造商提供的可信硬件或TEE(例如SGX)进行计算完整性的可信计算相比,PlatON 上的Trustless 计算仅依赖于可证伪的密码学假设,从而在其生命周期内提供前所未有的私有数据安全性,不存在信任边界。
#
PlatON总体架构#
总体逻辑结构PlatON除了提供底层链外,同时提供钱包、区块浏览器和节点工具的开源实现:
- ATON钱包:一款支持冷热HD钱包、交易管理和委托管理的移动端钱包,账户私钥在客户端管理,后续支持Keyshared(基于门限签名的密钥管理系统)
- PlatScan区块浏览器:PlatON社区提供的区块浏览器
- 节点工具
#
底层逻辑结构PlatON中,Layer1共识网络在以太坊的技术框架上进行修改,核心组件重新编写,并扩展了一些新组件:
- 密码算法:沿用从比特币时代开始使用的SHA256Hash算法、ECDSA签名算法外,PlatON还使用BLS用作共识的聚合签名,VRF做PPoS的验证人随机选取,ZKP和HE做隐私保护方案。
- P2P网络:PlatON不用主流区块链项目常用的libp2p和devp2p库,实现RFC标准RFC6940的RELOAD(REsource LOcation And Discovery)定义的P2P协议,以及RFC7374的ReDiR(Recursive Distributed Rendezvous)定义的服务发现机制。
- 账户模型和数据存储:沿用以太坊的账户模型,状态数据保存在帕特里夏树。PPoS相关的数据由于数据量较大,存放在帕特里夏树性能较差,不保存在帕特里夏树,而是单独保存在另外一个不存储历史状态的SNAPDB中。
- 共识机制:使用BFT风格的PoS共识机制。PPoS为带VRF的DPoS机制,VRF引入的随机性,可内生地抑制矿池规模扩张,这对PlatON的去中心化和安全非常重要。另外PlatON的BFT是一种基于部分同步假设情形下的并行拜占庭协议CBFT(Concurrent Byzantine Fault Tolerance),CBFT参考了PBFT, Tendermint,Hotstaff等共识协议,通过pipeline的方式并行完成批量区块的生成和确认,从而提高共识效率。
- 智能合约:同时支持EVM和WASM引擎,根据具体交易自动选择对应的虚机执行合约,支持Solidity,C++,Java,Python等主流编程语言。基于LLVM实现WASM编译器,并基于Truffer修改相应的命令行IDE,以及图形化IDE,同时支持隐私合约和可验证合约。
- DAPP SDK:在以太坊的WEB3(支持Javascript,Java,Python,Swift语言)和JSON RPC的基础上根据PlatON的功能进行修改。另外需要增加更高效的GRPC接口。
Layer2将复杂计算扩展到链下,并通过链下安全多方计算实现隐私计算协议。
- 密码算法:可验证计算(VC)算法可实现非交互证明的链下计算扩容方案。安全多方计算(MPC)结合秘密共享(SS)和同态加密(HE)实现隐私计算协议。
- MPC虚拟机:隐私合约通过LLVM编译器编译成LLVM IR,MPC VM基于LLVM JIT实现,可执行LLVM IR代码,MPC VM内置MPC、SS、HE等隐私计算协议,减少隐私合约编译后的LLVM IR代码大小。
- 专用计算硬件:通过开发基于 FPGA/ASIC 的专用计算硬件,能够极大的提高计算性能,降低功耗/成本。
- 隐私计算和数据交换协议:不泄露原始数据的前提下能进行协同计算和结果验证的计算协议。
- 隐私计算框架:封装隐私计算和数据交换协议的开发框架,包括基于隐私计算协议的隐私AI开发框架。
#
网络结构#
基础网络PlatON的基础区块链网络主要由以下几类节点构成,这些节点通过P2P方式连接:
轻节点
不保存所有区块的数据,只保存区块头信息以及跟自己相关的数据,依赖全节点进行快速交易验证。轻节点参与交易和区块信息的全网广播。
全节点
保存了所有区块的数据,可以在本地直接验证交易数据的有效性。全节点参与交易和区块信息的全网广播。
归档节点
保存了所有区块的历史状态的节点,历史上任何一个区块对应的世界状态都被保存在节点上,归档节点是一种特殊的全节点。
种子节点
新节点加入PlatON网络,首先连接到种子节点,发现其他节点。
验证节点
负责执行交易并把交易数据打包成区块,验证节点通过 PPoS+VRF随机选出,并运行CBFT 协议进行共识。
#
分布式应用部署DAPP应用(包括区块链),需要在内网环境部署以下服务器:
全节点
用来接入PlatON网络,全节点可以对外开放公网P2P端口,但不建议开放节点RPC端口。
DAPP服务器
连接至本地全节点RPC端口,通过全节点监控链上交易、事件和区块,并发生交易。同时DAPP服务器也连接到企业原有业务系统。
#
验证节点池验证节点池部署多个验证节点,建议通过公开的全节点连接外网。具体安全部署方式参见验证节点部署结构图。
#
监控运维平台监控运维平台通过一个全节点同步所有区块、交易和事件,并进行指标监控。
#
PlatScan区块浏览器PlatScan区块浏览器通过一个全节点同步所有区块、交易和事件,并进行区块、交易等数据的展示。PlatScan区块浏览器需要部署以下服务器:
- 全节点:RPC端口只对内部数据处理服务器开放
- 数据处理服务器
- 数据库服务器
- WEB服务器
- 推送服务器
#
ATON钱包服务端ATON是一个移动端钱包,私钥在客户端管理,客户端负责签名转账交易、质押交易等,并通过ATON服务器转发到链上。链上的发送交易回执、接收交易、验证人信息、收益等由ATON服务器通过全节点进行同步处理并推送到移动客户端。ATON需要部署以下服务器:
- 全节点:RPC端口只对内部数据处理服务器开放
- 数据处理服务器
- 数据库服务器
- WEB服务器
- 推送服务器
#
验证节点部署结构为保护验证节点正常通信与运行,稳定出块,对节点需要进行安全防护:
- 全节点和验证节点RPC端口关闭。
- 验证节点不在公网上暴露,通过非共识全节点进行通信。
- 每个验证节点应至少准备 2 个公开全节点、2 个非公开全节点,公开全节点的 IP 可以对外公开,以供 和主网正常通信。另 2 个非公开全节点的 IP 只告知其他可靠验证节点,不对外公开,以避免同时遭遇 DDoS 攻击。
- 防止全网扫描定位高防后的服务器,修改同步端口 9876(同理 RPC 的 8888)至全网最大存活数量的端口 80、443 或 22,这样可以有效抬高攻击者定位成本。
#
PlatON核心模块#
P2P网络PlatON 完全实现 RELOAD(REsource LOcation And Discovery)标准[RFC6940]的P2P基础协议 和 Kademlia协议 。下图为 PlatON 网络整体分层结构。
#
链接层链接层定位于实现数据的安全传输,提供多种传输协议来防止窃听、篡改、消息伪造;提供安全、可认证的连接;保证消息来源认证和消息数据的完整性。本层实现安全传输层协议(TLS)和数据包传输层安全性协议(DTLS)。
#
分组转发和连接管理负责提供分组转发服务来实现存储路由表,同时负责点对点建立连接,包括位于 NAT设备和防火墙后的节点。RELOAD 使用 ICE 方法 [RFC5245] 实现 NAT 穿越。
#
拓扑插件RELOAD 是一个 P2P 网络框架,支持扩展不同的拓扑算法来实现全分布式非结构化拓扑或全分布式结构化拓扑网络。
拓扑算法可利用消息传输组件来管理消息的收发,利用存储组件来管理数据的存储。
拓扑算法与分组转发和链接管理层紧密配合,提供多种路由功能来满足不同需求。PlatON 网络采用 Kademlia 算法来实现全分布式结构化拓扑网络。
#
数据存储负责数据的存储,通过与拓扑插件的配合完成数据的复制、迁移等动作,同时与消息传输组件配合完成数据消息的收发。RELOAD 支持字符串、数组和 dictionary 类型的数据存储。
#
消息传输负责对应用提供可靠的点对点消息传输服务。PlatON 在 RELOAD 基础上扩展了分区泛洪算法来进行消息的快速全网广播。
#
应用层利用RELOAD 底层的通信、存储能力来构建服务发现扩展,以及基于服务发现的TURN服务、计算服务、数据服务、存储服务、区块链服务等。
#
服务发现PlatON 使用 ReDiR(Recursive Distributed Rendezvous)[RFC7374] 来实现服务发现机制,ReDiR 可以支持数万的服务提供节点及服务查询节点。
#
ReDiR 树ReDiR 使用树状结构实现 P2P 服务发现机制。同时使用 RELOAD 覆盖网络的存储能力保存数据,每一类服务都存储为一棵 ReDiR 树,树节点保存服务提供节点的信息。当某个节点请求查找指定服务的提供者时,对 ReDiR 树做有限次的查找就可以找到与请求节点最匹配的服务提供节点。 ReDiR 树节点使用 RELOAD 的 dictionary 结构存储服务提供节点,每一个 ReDiR 树节点属于 ReDiR 树的某一层(level),ReDiR 树的根节点为第 0 层, 根节点的子节点位于第1层,第一层的子节点位于第2层,以此类推。
ReDiR 树每层容纳的节点数取决于分支因子 b,每层最多容纳$b^{level}$ 个节点,每个节点用$ (level, j)$ 来唯一标识,其中$level$为节点所在的层数,$j$ 表示该节点为相应层中第$j$个节点。在每一层中,$b^{level}$ 个树节点把第$level $层分为$b^{level}$ 个 KEY 空间。
所有服务节点映射存储到相应的 KEY 空间,每个 KEY 空间由一个树节点负责存储,树节点 $(level, j) $包含的 KEY 范围为
$(2^{BitsInKEY}b^{-level}(j+\frac{b'}{b}), 2^{BitsInKEY}b^{-level}(j+\frac{b'+1}{b}))$
其中 $0 ≤ b′ < b$,树节点$ (level, j) $中保存的资源 ID 取值为 $ID = hash(service, level, j)$。
#
服务发布在 RELOAD 覆盖网络中,KEY 为 $k$ 的节点 $n$ 发布服务的步骤如下:
- 步骤一:选择一个初始层$ l = l_{start}$,一般为 2。
- 步骤二:节点 $n$ 发送查询请求到负责 KEY 空间 $I(l, k)$ 的树节点,获取该树节点存储的 服务节点列表。
- 步骤三:节点 $n$ 发送存储请求将自身信息存储到负责 KEY 空间 $I(l, k)$ 的树节点中。
- 步骤四:检查第一步返回的结果,如果节点 $n$的 KEY 值 $k$ 是其中最大或最小的,则将当前层数减 1,重复第 2-3 步,直到节点 $n$ 的 KEY 值不是最大或最小,或者到达根节点为止。
同理,节点 $n$ 从层 $l = l_{start}$ 往下层遍历处理,直到满足以下条件为止:负责 KEY 空间$I(l, k)$ 的树节点中,节点 $n$ 为唯一一个服务节点。
#
服务更新注册到 ReDiR 中的服务状态都是动态的,服务节点需要定期重复服务发布流程来更新服务状态。若超时未更新,负责存储的树节点需要将其从存储中删除。
#
服务查找服务查找过程跟服务发布类似,也是从一个初始层 $l = l_{start}$ 开始,每一步获取到当前KEY 空间 $I(l, k)$ 中的服务节点列表,按照以下方法处理:
- 步骤一:如果没有返回任何服务节点,则表明 KEY($k$) 对应的服务节点存在更大的 KEY空间,将层数减 1 然后重复查询,如果当前 $level$ 为 0 则查询失败。
- 步骤二:如果在返回的服务节点中,$k$ 不是其中最大或最小的,则表明对应的服务节点一定存在的子空间中,将层数加 1,然后重复查询。
- 步骤三:否则,返回的结果为最接近 KEY($k$)的服务节点,查询成功。
#
账户模型相比账户模型,UTXO不支持智能合约,而很多的DAG项目也在积极探索智能合约,但是还没有成熟稳定的解决方案,因此PlatON选择成熟稳定支持智能合约的账户模型。PlatON中,每个账户都有一个与之关联的状态(state)和一个20字节的地址(address)。账户分为两类:
普通账户
由私钥控制,用户可通过钱包客户端或命令行生成。PlatON中,普通账户可以创建交易,并使用私钥对交易签名。
合约账户
没有私钥,由代码控制,合约账户地址在部署合约时产生。与普通账户不同,合约账户不能自行发起新的交易。每当合约账户收到一条消息,合约内部的代码就会被激活,允许它对内部存储进行读取和写入,以及发送其它消息或者创建合约。
#
数据存储在最初的bitcoin区块链中, 只有普通的转账交易才需要存储,比特币是基于UTXO模型,也就是说链上存储的除了区块相关的信息(hash、nonce等)以外都是UTXO,在以Ethereum为代表的blockchain2.0公链中普遍支持了智能合约(Smart Contract),合约中存储的内容可以是任意的,除了账户相关的信息(如代币)外,用户还可以把文本、图片、视频等等存到链上。
在一些链上(比如以太坊)为了保证数据完整性,通常还需要把一些状态数据(或者叫做历史数据)存在链上,这些数据只在对应的块(高度)有用,在其他高度是没有任何用处的,这样做的好处是任何时候, 我都能追溯历史上某个高度上,账本的全貌是什么样子的,但弊端也显而易见, 就是存储的成本很高。所以就有了类似EOS这种公链的存储方案,除了只存最新状态数据, EOS还借助星级文件系统来分担存储上的压力。
PlatON认为,链上存储需要充分考虑成本, 只有有价值的、需要所有账本做出共识的信息才应该被存储到公共账本上,有价值的信息包括:区块、交易、账户数据。而对于经济模型中的一些信息,如当前共识轮的验证人列表、候选人列表、各个节点当前的出块率等,只需要存储当前最新数据即可。
PlatON的存储分为账户数据存储(statedb)和快照存储(snapshotdb)。
#
账户数据存储(statedb)PlatON的账户数据存储参考了以太坊的MPT树状存储模型,如下所示:
PlatON中,所有和账户相关的状态信息都是通过 StateDB 来存储和获取的。为了支持数据的快速查询以及区块的回滚操作,StateDB 使用 MPT 结构作为其下层的存储方式。MPT 中的所有节点最后都会以 key - value 的形式存入磁盘数据库。
最上层就是StateDB。StateDB负责将数据做最初步的记录。往下一层是Trie层,Trie负责将所有数据结构化,方便后续的存储查询回滚等操作。Trie分两种,State Trie和Storage Trie。前者是状态树,记录了所有账号的余额nonce等基本信息。后者用于记录各种合约存储数据。状态树只有一棵,存储树有很多棵,因为每个合约都有棵属于自己的存储树。Trie再往后就是TrieDB,TrieDB将Trie中的节点序列化后存储在内存中。TrieDB的主要作用是做为最终插入硬盘数据之前的缓存层。整个结构中最后一环就是最终硬盘上的数据库leveldb。
#
快照数据存储(snapshotdb)考虑到存储成本和读取性能,PlatON中部分数据只保留最终状态,通过snapshotdb来存储和获取,snapshotdb中的数据最后都会以key-value的形式存入磁盘数据库。
其中:
- unRecognizedBlockData: 一个未确认的数据集合,每个DB写入请求都更新数据集合。
- RecognizedBlockData: 被确认的区块数据,BlockData经过Flush后即变成RecognizedBlockData,RecognizedBlockData与区块hash和number有对应关系,同一块高可以有多个RecognizedBlockData,commit后删除同一块高及以下的其他RecognizedBlockData。
- CommitedBlockData: 等待Compaction的区块数据,有且只有一条路径(区块关联)。
- WAL: 日志文件,所有数据记录之前先写log。存储k,v,hash数据,hash = hash(k+v+hash)
- current: 用于存储当前最高提交区块(highest)和最高合并区块(base)区块的高度
#
共识机制“不可能三角”中,去中心化的量化指标就是参与共识的节点数量,可扩展性的量化指标是TPS或吞吐量,安全性的量化指标是作恶的经济成本,经过对这几个量化指标的权衡,PlatON采用BFT类的PoS机制。
PlatON共识运行分3个阶段:1. 备选节点选举;2. 用VRF从备选节点中选出验证节点;3. 验证节点轮流出块并运行拜占庭协议CBFT。
- 第1阶段:备选节点选举
每个LAT持有者都能参与选举。
如果一个LAT持有者想成为验证节点,必须锁定超过一个事先确定的最低数量LAT,成为备选节点候选人。每锁定1个LAT相当于自投1张选票。备选节点候选人之间不得相互投票。
其他想参与备选节点选举的LAT持有者也必须锁定LAT,对它们锁定的LAT数量必须大于等于10LAT,每锁定1个LAT兑换1张选票,它们可以将自己的选票投给任何它们支持的备选节点候选人。
所有投票完成后,备选节点候选人按照它们的得票排序。得票最高的前若干位候选人成为备选节点,备选节点数量也是事先确定的。备选节点及其支持者锁定的LAT将继续保持锁定状态,直到一个事先确定的锁定周期结束。没有入选备选节点的候选人及其支持者锁定的LAT,在选举后可以解锁,它们不参与这一轮共识,也不会获得任何补偿。
- 第2阶段:用VRF选出验证节点
VRF将从全部备选节点中,选出一定数量的验证节点,验证节点数量是事先确定的。
数学上可以证明,得票数越高的备选节点,经VRF被选为验证节点的概率越高。但因为VRF引入的随机性,最终选出的验证节点不一定正好是得票最高的那些备选节点。
- 第3阶段:验证节点运行CBFT
在CBFT中,每个验证节点均被分配一个时间窗口,在这个时间窗口内连续生产区块。每个验证节点在其时间窗口内生产的区块数量是事先确定的。此后,全部验证节点对候选区块运行CBFT直到达成共识。
#
智能合约从技术角度看,PlatON计算网络本质上是一个去中心化的FaaS(Functions as a Service)平台,相应地,智能合约可以认为就是FaaS上的function。PlatON中的智能合约分为四类。
#
Solidity合约(Solidity Contract)Solidity合约支持使用solidity语言开发,编译成solc bin执行。触发Solidity合约的交易由共识节点打包,全网节点重复执行验证。Solidity合约的状态保存在公共账本中。
#
WASM合约(WASM Contract)Wasm合约支持高级语言开发,编译成wasm执行。触发Wasm合约的交易由共识节点打包,全网节点重复执行验证。Wasm合约的状态保存在公共账本中。
#
WASM虚拟机PlatON 采用wagon作为PlatON虚拟机。作为PlatON的虚拟机,需要进行改造。实现链上的外部函数以及GAS的计算方式。
#
工具链PlatON 首先支持C++作为智能合约的编写语言,后续逐步提供Rust、Go等主流高级开发语言,针对C++提供以下工具链:
- platon-cpp : C++的编译器,负责生成WASM目标码和ABI文件。
#
WASM合约执行流程#
WASM合约GAS计费WASM合约的执行按照调用的WASM指令进行GAS计费,不同WASM指令GAS不同,具体WASM指令的GAS值后续补充。
#
隐私合约(Privacy Contract)#
隐私合约方案隐私合约同样支持高级语言开发,编译成llvm ir中间语言执行。隐私合约的输入数据保存在数据节点本地,由数据节点通过秘密分享给到多个随机计算节点,计算节点在链下以安全多方计算方式进行隐私计算,并提交计算结果到链上。
#
隐私合约执行流程#
可验证合约(VC Contract)可验证合约的开发和发布跟Wasm合约没有区别,最终也是编译成wasm执行。可验证合约的状态转换在链下由计算节点异步执行,计算完成后新的状态和状态转换证明提交到链上,全网节点可快速验证正确性并将新的状态更新到公共账本中。可验证合约可支持复杂、繁重的计算逻辑而不影响整条链的性能。
#
可验证合约方案PlatON的可验证方案暂时基于zk-SNARK算法,后续逐步替换为更优化算法。
vc-contract template:用户根据提供的模板编写 vc 合约,可以输入任意计算模型,主要实现三个接口:
compute():计算请求
real_compute() :生成计算结果和证明
set_result():验证计算结果和证明
vclang:将用户编写的 vc 合约编译,生成 wasm vm 支持的执行文件,合约开发者无需关心具体的 libsnark api 使用方法,只需编写好自己的计算模型代码即可
vcc-reslover:在wasm虚拟机中内置支持访问 libcsnark的接口层,以 c-go 的方式调用 libcsnark 接口
libcsnark:封装 libsnark api,将 c++ 实现的 libsnark 可以由 c 接口访问
vc_pool:负责 vc 的交易处理,分发 vc 计算任务,并将计算结果和证明上链
#
可验证合约执行流程- 合约编译之后,已经生成了 pk,vk,部署至 PlatON 网络之后,pk,vk 存储至链上,无法被篡改,可方便节点访问
- 当 vc compute 交易执行时,会创建一个 vc task,taskid 由 tx 的 nonce 组成,并以 taskid 为 key,存储输入参数 x
- compute交易写入区块之后,会触发 vc_pool解析交易event,从而决定是否将task加入vc_pool的队列中
- 区块确认之后,就可以开始执行 real_compute,由于是链下计算,不会产生交易费用。real_compute 的过程是首先根据执行此前编译生成的 gadget 序列运算产生 s(witness),一旦计算出 s ,就可以根据pk,计算出证明proof
- set_result(proof, result) 是将计算结果和证明上链,该过程主要是 verify(vk, proof, input) ,一旦验证通过,则交易发起者可获取计算酬劳。zk-SNARK的 verify 的时间相对产生 proof 的阶段比较短,但也是和输入参数长度相关,所以需要注意限制输入参数长度,防止该笔交易的gas费用过高,增加验证者成本
#
激励模型有计算外包需要的用户,需要先抵押合适费用至合约账户,各计算节点可自行竞争计算任务(后续将抢单模式修改为随机派单模式),一旦计算成功,生成结果和证明,就发起set_result交易请求,需要计算节点先支付该笔交易的矿工费,节点收到请求,执行set_result,一旦验证通过交易中携带的 proof 和 result 参数,则认为交易请求者成功计算出结果,会将合约账户抵押的费用转账至请求者账户中,失败则不会给以激励。