常见问题解答

系统相关

Q

** XuperChain 按照一般的分法,是属于联盟链还是公链?仅从源码看,XuperChain是否更偏向于采用公链的理念设计,先记账后共识,只有一条主链?**

A

XuperChain在设计中以模块化和可插拔作为基本原则之一,对共识、合约等核心组件都可高度定制开发。因此从这点来讲,XuperChain并不是只为公链或联盟链设计,而是一种通用可定制的区块链架构。在多链方面,未来我们也会开源我们的跨链技术,请持续关注。

Q

超级节点技术中说到,“ XuperChain 实现了计算和存储分离的这样一个架构,即一个节点,它表面上是节点网络中的一个节点,它的背后则是一个强大的、分布式的计算和存储集群。”,这段话怎么理解?

A

超级结点技术现在还不太完善,目前仅支持存储放到nfs上。我们的技术理想是,采用分布式存储+分布式计算调度技术,将超级结点的处理请求分发到这两个内部集群里面去。链内并行技术理论上是能分析出DAG并行处理依赖,然后将无依赖的请求调度计算集群里面分开计算。这样,以后超级结点其实是一个集群技术。

Q

** XuperChain 强调自己是100%自主研发,为什么要重新开发全新的区块链系统?新系统的可靠性和健壮性如何验证?**

A

技术是无国界的,但是工程师是有国籍的。几乎每个流行的区块链项目都有一个稳定的核心开发团队圈子,为了不受制于人,尤其对于新兴技术,唯有自主研发才是正途。 百度 XuperChain 的愿景是让信任的建立更加便捷,未来区块链会广泛应用在各行各业的大量业务,成为信任的连接器,当前我们已经在版权保护、司法存证、数据流通等领域落地了应用,可靠性健壮性得到了验证。此次开源也是为了在更广泛的业务场景中应用,我们也会不断迭代代码、打磨系统,完善文档。

Q

XuperChain能跨链吗?XuperChain上的各个平行链之间数据能相互访问交互吗?如果现有的eth、eos或者fabric要和XuperChain对接该如何对接呢?

A

XuperChain 支持跨链,但此次开源的XuperChain里面没有包含跨链的组件,XuperChain 中的平行链不具备互操作性。跨链的功能后续将会开源在XuperCross这个项目里,目前已经实现对 XuperChain 平行链之间可以跨链,也可以实现对fabric的跨链,目前跨链技术仍在完善中。

Q

百度 XuperChain 在实现上和Fabric相比,具有哪些异同呢?

A

与Fabric相比,唯一的相似点是都有合约预执行阶段,其他很多地方都不一样。首先, Fabric的Ledger是不支持分叉的,XuperChain是支持的。Fabric中数据的版本编码是和区块高度绑定的,因此它不支持在同一个区块内多笔事务修改同一个Key。在智能合约开发方面,Fabric没有合约虚拟机啊,不支持合约资源消耗控制,而且是通过Docker来实现粗粒度的资源限制。在网络方面,Fabric是用的RPC,并不能构建大规模的P2P网络。

Q

超级节点的服务器存储量是有限的,如果达到上限怎么办?是采取什么样的结构存储数据?

A

目前提供多盘存储能力,如果超过单机容量可以挂载nfs,底层是扁平化的key-value存储,而且是可插拔的,目前支持leveldb和badger两种key-value存储引擎。如果有需要也可以开发分布式key-value 的组件。

Q

** XuperChain 在部署方面的亮点和技术优势是什么?**

A

部署亮点:不同于传统的联盟链系统, XuperChain 具备全球化部署能力,节点通信基于加密的P2P网络,支持广域网超大规模节点,且底层账本支持分叉管理,自动收敛一致性,先进的TDPOS算法确保了大规模节点下的快速共识。 主要技术优势是: 高性能:通过原创的XuperModel模型,真正实现了智能合约的并行执行和验证,通过自研的WASM虚拟机,做到了指令集级别的极致优化。 架构灵活: 其可插拔、插件化的设计使得用户可以方便选择适合自己业务场景的解决方案,通过独有的XuperBridge技术,可插拔多语言虚拟机,从而支持丰富的合约开发语言。 安全: 内置了多私钥保护的账户体系,支持权重累计、集合运算等灵活的鉴权策略。保障了智能合约运行的安全和可控。

共识相关

Q

可插拔共识具体指什么?为什么设计成支持热更新的共识机制?

A

当前,每种共识都有各自的优缺点。POW太消耗能源,而DPOS经常被质疑是不够去中心化的。所以,在XuperChain的代码中,我们实现了一种可插拔的共识机制,开发者自己实现相关接口,编译成插件就可以完成替换。并且我们认为在系统运行的不同阶段会对共识机制有不同的要求,例如某些场景下冷启动时可能使用PoW更合适,而当系统进入一个稳定状态时,可能使用TDPoS更合适,因此设计了一种共识热更新机制,通过提案投票,可以在区块链网络不停服的情况下完成共识更新。

Q

** XuperChain 目前支持哪些共识算法?推荐使用哪个共识算法?**

A

XuperChain 是可插拔共识,具有统一的共识接口,目前已经开源了包括TDPoS、PoW、Chained-BFT、授权证明等多种共识机制。我们建议的是TDPoS共识,开发者也可以选择自己实现共识接口,扩展出更多的共识机制。

Q

此次开源的出来的共识中, 最终确认时间是多少?

A

目前开源的共识算法有TDPoS、PoW、Single、Chained-BFT。这几种共识算法的出块时间都是可配置的。一般来说Single是强一致模型,可以认为是即可生效;PoW的交易确认时间根据网络情况而定,一般是6个块以上;如果采用TDPoS+Chained-BFT,则交易确认时间是3个块。

Q

现在 XuperChain 支持一条链共识算法无缝由pow切换为tdpos吗?

A

支持,共识的热更新是基于提案投票机制,可以通过提交一个proposal,并在提案中设定好触发高度,当提案收到足够比例的投票后,系统会在之前设定的高度时统一触发共识升级,调用consensus的updateConsensusMethod方法,来实现共识切换。

Q

在TDPOS机制是怎么优化DPOS机制的分叉问题的?如果此时有一两个块由于网络延时其他节点未收到该广播,那是再发广播,等到其他节点确认收到该广播以后再切换BP节点?

A
主要是有以下2点:
1. 首先在时间调度算法切片上,我们有3个时间间隔配置,分别为出块间隔、轮内BP节点切换的时间间隔和切换轮的时间间隔,这个其实很简单,这样在切换BP节点时会可以让区块有足够的时间广播给下一个BP;
2. 在网络拓扑上进行的优化,我们超级节点的选举是在每轮的第一个区块,并且提前一轮确定,这时我们网络层有足够的时间在BP节点之间建立直接的链接,这样也可以降低我们切换BP节点的分叉率。
Q

如果想扩展自定义共识算法,有相关文档吗?

A

目前没有具体的文档,如果感兴趣的话可以参考一下开源共识代码的实现,主要接口参考文件consensus/base/consensusinterface.go。

性能相关

Q

请问百度 XuperChain 8.7万的TPS是在什么样的硬件环境下测得的?

A

目前百度 XuperChain 通过了国家工业信息安全发展研究中心评测鉴定所的测评,在性能测试中,百度 XuperChain 并发可达每秒87000笔交易;测试环境采用TDPOS共识,5节点异步模式, 万兆网络,每个节点64核 2.4GHZ CPU,NVME SSD存储。

Q

链内并行在开源版本实现了吗?

A

实现了,在func (xc *XChainCore) PostTx中。 节点收到一个tx后,除了校验密码学签名, 还会校验其依赖的Input哈希指针(指向依赖的其他tx output)是否有效(up to date),如果有效则加载数据构造合约执行环境,然后重新执行合约,看输出的数据是否和tx中声明的写集合“TxOutputExts“一致。这整个过程都是无锁的,因此能并行,利用多核能力。 验证通过后,最后调用doTxInternal写入账本, 这个过程是有锁的,会再次check 哈希指针的有效性,因为前面放锁了。 简单而言,是一种乐观锁实现。

Q

XuperChain引入链内并发及多版本事务处理技术, 那么它又是如何保证事务的原子性及时序性? 是否与分布式数据库的事务相似呢?

A

通过将一个事务涉及的数据变更打包在一个底层KV数据库的Batch写,保证其原子性。 事务的处理时序是通过事务的引用关系来定序:DAG的拓扑序。 在经典的UTXO模型中,事务声明了“资金引用”,而XuperChain的事务模型中,有两种引用:资金引用和数据引用,通过数据引用来支持通用的智能合约。 链内并行原理:节点收到一个事务后,除了校验密码学签名,还会校验其依赖的Input哈希指针(指向依赖的其他事务的output)是否有效(up to date),如果有效则加载数据构造合约执行环境,然后重新执行合约,验证输出的数据是否和其声明的Output一致。这整个过程都是无锁的,因此能并行,利用多核能力。验证通过后,事务的Output写入账本, 这个过程是有锁的,写入前会再次检查一次哈希指针的有效性。整体上的原理和分布式数据库的MVCC并发控制有相似之处。

Q

链内并行技术中,如果多个并发交易具有时序性, 是否会产生死锁问题?为什么?

A
不会有死锁。从前面对链内并行的原理分析也可以看到,我们是采用的“乐观锁”的机制,有点类似CPU的硬件同步原语Compare and swap。 事务之间最差情况是冲突导致单次提交失败,不会死锁。

XuperChain 中事务的提交分为两阶段,预执行(PreExec)和提交(PostTx)。预执行阶段合约对账本是只读(Read-Only)的,预执行结果会返回事务的“读写集合”,其中读集合描述了事务依赖数据各个Key的Hash指针,这个Hash指针指向已经成功提交的事务的Output域。客户端将读写集和自己的签名组装起来,开始第二阶段:提交,节点验证成功后,事务输出才写入生效,进入待上链状态。如果提交失败,客户端可以返回第一阶段重新开始。

Q

请问DAG技术有较为详细的文档么?或者在代码中哪个模块能看到相关实现?

A

DAG并发执行目前已经开源了块验证时的DAG识别和并发执行,具体可以参见开源代码中的UTXO模块。对于通过PostTx接收到的交易,目前还没有开源DAG并行架构,会在未来的版本中

合约相关

Q

** XuperChain 合约虚拟机开源了吗,兼容性怎么样?**

A

已经开源了,目前主要支持XVM和WAVM两种虚拟机。XVM开源在XuperChain主框架项目中,可以看下XVM的实现,基本过程是wasm -> code injection -> c -> dylib. 然后go里面调用特定的几个导出函数符号执行。wasm import的符号会在c里面体现为外部导入符号,然后通过cgo,在go里面暴露出来。这个方式算是一种比较巧妙而且简洁的方式吧。 另外wavm开源在XuperChain/Wavm这个项目中。

Q

XuperBridge是合约虚拟机和区块链账本的桥梁, 它的好处当然有很多, 可以统一接口, 更低的耦合度, 但同时也会限制一些灵活性, 关于这点是如何处理的呢?

A

XuperBridge通过统一接口降低了将不同类型的虚拟机接入到XuperChain的难度,给予开发者更多的选择来开发Dapp,而不限于某一类特定的编程语言。目前我们已经接入了WASM和Docker来满足不同场景的业务需求,后续我们会开放更多的接口来满足开发者的多样的开发需求。事实上,我们通过XuperBridge也已经支持了以太坊的solidity虚拟机,只是由于License问题,此次不便开源。

Q

合约预执行,与Fabric的endorser阶段策略类似吗?先生成read/write set?

A

流程上大体类似,实现上是有差别的,例如数据版本定义等。Fabric中数据的版本编码是和区块高度绑定的,因此它不支持在同一个区块内多笔事务修改同一个Key, XuperChain 中的版本类似于UTXO,同一个块中可以对一个key进行多次修改,因此可以大幅提升交易性能。

Q

合约之间是否可访问,例如A账户a1合约里面存储的数据在B账户b1合约里面可以访问么? 那用户B能调用A账户部署的合约吗?

A

目前夸合约调用还不支持,出于用户权限和数据安全考虑,合约数据属于受保护的私有数据,不能被其他合约直接使用,即使两个合约都属于同一账户。未来可以通过系统级跨合约调用的方式实现数据共享,目前这部分技术还没有开源,请持续关注 XuperChain 后续版本。 但用户可以调用其他账户部署的合约,每个合约接口可以设置单独的ACL权限控制,因此合约所有者可以在合约接口ACL中配置哪些账户有权限访问该接口,这里的账户并不限于合约所有者。1. ACL权限模型可以自由扩充定制。 2. 如果合约接口创建后没设置ACL,默认是public,所有用户都可以访问。

Q

是否支持原生合约?原生合约有没有资源消耗机制?

A

XuperChain 支持原生(Native)合约,原生合约可以在docker环境中执行,但原生合约目前不支持资源消耗控制机制。

Q

智能合约是什么时候触发执行的?只能由客户端触发吗, 有没有可能就是在某个条件满足的时候自动触发呢?

A

简单说,智能合约是在用户调用的时候触发执行的。更详细得说,用户在客户端发起一个智能合约调用,服务端会为该智能合约调用创建Context,然后将Context相关信息通过XBridge传给虚拟机,虚拟机通过调用SyscallService服务,来修改/获取智能合约的数据状态。

Q

是不是每种合约都需要有一条单独的链呢?

A

合约由虚拟机来管理,一条链上可以部署很多智能合约,不过每一个智能合约都需要有不同的合约名字。

账户权限相关

Q

普通账户和合约账户的区别是什么?

A

账户是指一种本地或自定义权限的链上标识符。本地标识符称为用户账户,通常分配一个公钥和一个私钥,并对应一个address;自定义权限的链上标识符称为合约账户,通常分配一个或多个密钥或多个账户。

Q

什么是AK? XuperChain 中所说的AK集合是什么?

A

AK是 XuperChain 中对一个公私钥用户账户的称呼,可以理解为Address,即通过一对公私钥转换来的一个唯一用户账户地址。AK集这是权限系统模块中的一种权限模型,是指多个AK组成的具有一定逻辑规则的权限模型,例如多个AK之间满足”或”的关系等。

Q

** XuperChain 的权限设计为什么采用的是ACL设计模式而不是ABAC的设计模式?关于权限验证目前是只有SIGN_THRESHOLD和SIGN_AKSET 的权限规则在使用吗?**

A
  1. ACL更加简单,我们基于ACL实现了一套可扩展的权限模型,能够满足去中心权限系统的要求,同时又可扩展。而ABAC相对比较复杂,不易用;

  2. 目前对外开源的是SIGN_THRESHOLD和SIGN_AKSET这两种权限模型。

Q

在权限系统的设计中 身份账户的验证中会buildPermTree 和 validatePermTree,这个PermTree的设计思想是什么 这个Perm这个词是跟权限框架casbin中的PERM模型有关系吗?

A

在身份验证中,PermTree主要是验证客户提供的账户与签名是否正确以及它们的权重是否满足对应的ACL要求。 XuperChain 的PERM与casbin并不相同, XuperChain 的PERM指的是可扩展规则权限模型(Permission with Extensible Rule Model), XuperChain 而账户/合约权限中可能嵌套其他账户,在验证账户的权重是否满足要求时,由于这种嵌套关系,权限会自然形成树形结构,每个节点都是一个账户或合约方法的权限ACL,而每个节点的ACL可以使用不同的权限规则模型,节点的子节点是代表子节点账户对父节点的授权关系。

Q

在执行背书签名时默认读取data/acl/addrs文件,例如multisig gen 时要读取这个文件的数据,请问这个文件的内容应该是什么?

A

这是一个文本文件,文件内容中每一行表示一个需要签名的账户,是用于多重签名的地址,每个地址用换行分割。如果需要其他个人账户的授权,那么把个人账户的address作为一行写入这个文件中;如果需要合约账户授权,则需要使用”合约账户/个人账户address”的写法,表示需要某个合约账户ACL中的某个个人账户签名。

使用问题

Q

平行链是什么角色有权限创建?创建平行链的权限白名单是写在创世块中的么?

A

目前创建平行连有两种方法:一种直接通过xchain-cli的createChain命令,这种没有权限限制,只在本机创建;另一种是调用创建链的合约,这种情况可以在全网创建平行链,节点可以通过配置白名单的方式指定哪些用户能调用创建链的合约。创建平行链的权限白名单目前不在创世块中,而是在节点配置文件中。这么做的初衷是使每个节点有能力通过配置决定只托管符合自己要求的平行链。具体节点配置可以参考:https://github.com/xuperchain/xuperchain/blob/master/core/conf/xchain.yaml#L52

Q

自己搭链有root链和平行链之分么,还是自己搭的只是xuperchain的平行链?通过xchain-cli的createChain命令能在本地创建多条平行链吗?

A

自己搭建的网络首先需要创建主链(代码里叫xuper链),然后再创建其他平行链,主链具有部分管理其他链的能力,例如创建平行链的系统合约是在主链中执行。通过xchain-cli的createChain命令可以在本地创建任意多条链。

Q

搭建多节点网络时,其他节点需要在配置里面指定根节点的网络地址吗?

A

XuperChain 的P2P网络具有自动路由功能,因此只要在配置中指定任意一个已经在网络中的节点地址即可。

Q

** XuperChain 中的rootBlockid和tipBlockid是什么意思,他们的关系是什么?**

A

rootBlockid和tipBlockid都是指代区块的id,区块的id就是区块的唯一标识,通过两次SHA256生成。而rootBlockid特指创世区块id,即当前链的第一个区块的id;tipBlockid表示当前链主干分支最新的区块的id。也可以从rootBlockid和tipBlockid两个变量名称得知它们的意思,root有”根”的意思,而tip有”尖端”的意思。

Q

客户端发送交易后,怎么查询是否成功上链。通过querytx判断tx状态还是有其他事件机制?支持事件通知么?

A

首先查询交易所在区块,然后查询区块是否在区块链主干上,如果交易所在区块在区块链主干上,表明此交易已经生效。事件通知暂不支持,后续有计划支持部分类型事务执行结果的事件通知。

Q

RPC的文档中没有看到创建账户相关的说明?

A

创建普通账户属于本地操作,该数据不上链,考虑到创建账户涉及到用户私钥传输,处于安全原因不提供RPC接口;创建合约账户属于系统合约调用,没有单独的RPC接口。

Q

Windows系统可以编译运行么?可以用windows安装虚拟机来实现Linux环境么?

A

目前暂不支持Windows的,要求是Linux或者Mac OS。可以使用虚拟机实现。

其他问题

Q

密码学中椭圆曲线选择使用P-256的考虑?

A

首先,P-256曲线目前依然在密码学界被广泛使用。其次,这次开源的是我们的基础版本,而在xchain的代码架构下,密码学相关的模块是插件化使用的,密码学crypto模块是可以独立研发并集成进开源框架中的。同时,在ECDSA之外,也已开源了多重签名、EDDSA、环签名等多种签名算法。在尚未开源的版本中,通过可变签名算法,我们已经支持国密/NIST的多条椭圆曲线。最后,这些算法和曲线被支持混合使用,开发者可以自由选择他们认为安全的曲线和算法来保护自己的数字资产。所以,敬请期待百度xchain后续的密码学相关开源进展。

Q

** XuperChain 有密钥保护机制吗?怎么实现的?**

A

有的,主要实现了两种方式:1) 通过支付密码在私钥加密后保存在本地。2)云端密钥保险箱。密钥保护功能在SDK里有实现,目前尚未开源。

Q

环签名、零知识证明等技术开源了么?他们的使用场景是什么?

A

环签名、零知识证明等技术适用于对隐私保护有较高需求的网络中。目前环签名已经在crypto模块中开源,可以实现对交易发起者信息的混淆,例如在论文评审场景里,实现评审者对论文的匿名打分等;零知识证明目前尚未开源。

Q

** XuperChain 有区块链浏览器吗?**

A

暂时没有,在计划中,敬请关注。

Q

什么是VAT,它的作用是什么?

A

VAT (Verifiable Auto-generated Transaction, 可验证的自动生成事务)是智能合约在运行过程中,根据需要自动生成的系统Tx。这些Tx无法手动发起,结果也会上链,系统可验证。目前主要用在共识,提案等模块中,例如切换到tdpos共识,会自动生成候选人选举检票的VAT等。

Q

商用环境中,需要考虑数据隐私保护的问题,在这一块,xuper怎么考虑,有成熟的方案吗?

A

在xuper+的应用中,有xuperdata,它是基于百度 XuperChain 、多方安全计算、数据隐私保护等技术的多企业数据安全协同计算方案。相关文档介绍:https://xuperchain.baidu.com/case/xuperdata

Q

百度 XuperChain 的多盘存储是什么实现原理?

A

XuperChain 按照goleveldb的storage.go中的接口实现了自己的storage逻辑作为自己的file-system backed storage,代码可参考multi_disk_storage.go。具体实现中,leveldb的sst文件按照编号均匀散列放置在多块盘上,如果盘数扩容,第一次打开某个编号的sst文件的时候可能需要遍历尝试各个盘。另外,由于这个放置策略在compact的时候也生效,所以扩容的场景下,运行一段时间后,sst就会按新的路径均匀分布了。