[工信部区块链论坛]平安集团区块链产品总监陆一帆：根据平安内部的应用场景改进平安区 ...

记者：铅笔芯

平安一直是所有金融机构一直去学习的金融机构，平安发展过程当中，虽然锐意进取，包括在互联网金融的领域，平安不仅仅是领头羊，把很多互联网金融的事情做到极致，包括资产做到了第一，平安在整体上来讲，所有创新方面我们觉得是一个非常值得我们尊重和学习的企业。

陆一帆是平安集团区块链产品总监，他在会中说有的人可能知道我的背景，我之前长时间在IBM工作，三年前来到了平安。几年前我不记得是什么原因，我跟我的同事，因为当时我在CTO办公室工作，陪我的同事去介绍区块链，怎么利用区块链，区块链对IBM一系列产品的帮助。我的同事很大胆，当时其实我们想还是比较初步的，我的同事第二天找了IBM很高层的一个级别的人去谈这个事情，当时我跟另外一个同事都很害怕。

我为什么来平安，我在IBM过得也挺好的，来平安，区块链这个技术还走在成熟的轨道当中，但是基本的概念，解决这些问题的方式已经开始逐渐明朗了，其实我们在走上这个技术变成成熟，实际上要通过真正的应用来让他进行成熟。我来平安的目的，一方面推平安的区块链，另外让平安的区块链在一个真正的金融场景，或者其他的场景能真正实际的应用，这个是我来平安的目标。我来平安以后，首先要解决几个事情，各位老总都讲过了，各个技术都有它的局限性，技术有不成熟性，不稳定性，所以说你们不能拿着它马上来套用，所以技术改进是必须的，这是第一点。

第二点如果我们想要利用它，必须有一个平台，平安自己本身有一个平安云平台，今天胡总早上也讲过这个事情，我们第一个任务是两步走，我在搭建这个团队，在底层技术改造的同时，我在搭建平安的区块链云平台，与此同时结合在平安内部的应用场景，用它得到一些经验，来改进或者是知道我们要怎么改这个平台。

这个演讲准备得有点仓促，把云平台的图景直接截取下来了，我想这个云平台有什么一些技术特点？首先我想说第一点要做的是高吞吐量，刚才各位老总也说了，对于GPS来讲确实有一些局限性，这个确实不是不可以解决的。我们叫算法叫一个家族，如果你把分布式账本只放在不同的节点上，票据来讲，你把全中国的票据信息放在一个分布式账本上，再把这个节点分布给不同的公司，如果这个公司从中有一个公司它的节点被黑客，或者其他的原因被破坏了，中国的票据系统就瘫痪了，这个是为什么在区块链里面我们不能考虑（英语）的算法，算法其实五花八门。

第二点，我们怎么形成超大吞吐量，简单来讲，其实对于这个限制，有些情况下是算法有一些限制，但是你真正明白这种应用场景，有什么东西可以进行优化，通过这些场景对这些算法进行改造和优化，要大幅度提高你的算法吞吐量。高速和高效跟吞吐量有一个关系，吞吐量是你的一个很大的目标，你的高速和高效是有问题的。这里两个运用场景，两个不同的链，其中一点你看见一个场景的解释，我们设计的吞吐量是按照2000TPS设计的，我们非常强调速度。

另外一个点就是高稳定性，任何金融场景你要想到，不光是区块链用什么样的算法，必须保证实时的一致性，为什么公有链的算法是不能套的，你可以有延迟的信息，比如说可能拿一个信息比别人晚，可能是别人三分钟以前拿到的，但是数据跟别人三分钟以前是一样的，所以说任何在金融场景要应用的算法，必须保证100%的数据一致性，剩下一点点是讲的这个平台高一致性，这些事情如果你们知道算法，你都会很容易了解它对于运算消耗都是非常大，如果你直接套用一个普通的金融场景，80、90%的可能性是不适应的。你要怎么样保护客户的隐私性，实际上解决方案，这些同态加密算法，你是可以通过其他的一些应用场景有关的特定的定义，而可以把它分化，你不需要实现同态加密百分之百的实现，因为在银行中是有大机构，或者是有部分的可信制度，所以你只需要部分实现，因为你的目标是实现高一致性。所以这个目标要搞清楚。

安全性我就不说了，通过多种密码算法应用实现保证数据绝对安全。还有高兼容性，同时兼容以太坊及超级账本平台，并提供有自主产权中间件对公有平台进行性能提升机功能完善。再就是高扩展性，根据不同用户需求提供多类型节点扩展链网络，越往后的节点，节点上越大，越来越多的节点对1%的数据感兴趣，没有必要为这1%的数据花很多的容量。

这是一个我们应用的链的截图，这个链你会看到是根植于超级账本，我们设计成2000TPS，延迟时间控制在11-19毫秒之间，你要想延迟性一般，还有是来自于三个方面，首先是网络延迟性，再就是算法延迟性，还有逻辑延迟性。这些实际上才是产生最大问题的，具体我们怎么实现2000TPS，说实话很多方面是根据专门的应用场景而进行专门的优化，如果你搭一个区块链的平台，你想对它服务所有的场景，你是很难做优化的，如果你有一个目标，你是可以在很多方面优化的。

多种节点的选择，因为客户的需求不一样，如果你在创立一个联盟，有些联盟是大银行，大机构，有些联盟是中小型机构，不需要付费，只要负责跟自己有关1%的交易，每天而去花机房的钱，而去计算另外99%跟自己毫无关系的节点，这个节点的分化也是很有关系的。这个节点必须也对自己的客户有百分之百的控制权，这个在区块链里面是比较容易达到的。

然后多环境支持，因为我们确实是因为面对平安内部的一个云平台，将来不排除什么时候对外公开。如果任何一个实用平台，牵扯到开发测试，以及生产的多种环境支持，为整个区块链开始的设计，到测试，到上生产，提供一条龙的服务，很幸运，平安这个机构在里面，所以说我们也是跟平安云进行合作，满足内部一条龙的服务。

虽然是平台，展示的是智能合约，把它打包，通过一个节点把它发布。在我们搭建这个应用场景的时候，我们现在是碰到了一些问题，首先是多版本更新管控，区块链牵扯到不同方的加入，平安很多子公司，他们都有不同的自己的系统，一个团队搭建一个系统很简单，把它放在一起去做。但是在这种分布式的开发，的确碰到既有A和B，他们在不同的地方，不同的时间，效率可能不太高。我每次更新智能合约，其实在测试智能合约的话，对其他机构没有什么影响的，他们还是通过旧的地址，把他们的数据放到智能合约里面，然后进行运算。

还有第二点，就是运行流量控制，大家看到很多比较简单的应用，基本上把一个东西放在区块链上，因为所谓的篡改性有很简单的方式，数字证书不可篡改性比区块链的要好很多。稍微复杂一点，有一些计算是不可控的，因为很多公司一起来写这个（ATI），你必须在这种情况下考虑到智能合约采用流量控制。

第三个是数据缓存，这个是很危险，有可能会影响数据在数据节点的稳定性。再就是数据清理以及备份，每天的时间是不一样的，有些时候设置的是具备一个峰值而设置的，不管怎么样，这个区块链会越长越大。数据怎么样定期清理和备份，也是解决了一些问题。

平安云在不同的地理位置，或者是某些节点，因为网络原因不能工作，那么我们怎么办？这个涉及到很多不同算法的参数设计问题。还有系统通信安全，节点与节点通信采用加密保证数据在传输当中的安全特性。事务处理极限测试，测试区块链智能合约对不同负载事务的处理能力，以及应付特殊情况，如应对超时负载能力。