导语 | 云计算的发展为互联产业带来了巨大的变革，云上技术的下一站，又会有哪些新契机呢？本文是腾讯云区块链高级研发工程师李亮老师在云+社区技术沙龙深圳站的分享整理，为大家详细介绍腾讯云区块链应用开发的技术思考与探索。
点击视频查看完整沙龙回放
一、至信链
谈到区块链，不得不说一个很经典的问题：区块链的数据到底可不可以更改呢？刚才有人回答说可以，有回答说不可以。其实这两个答案从不同角度解释都是对的。
区块链是分布式的系统，单独对一个节点的数据修改是无法改变整个网络的数据状态的，这些修改必须达成全局共识，才能在区块链中生效。同时它是链式结构，后面的区块会包括前面区块的哈希，对前面区块的任何修改都会导致后面数据块全部需要修改。这些区块链特性，都保证了对于已存在链上的数据很难被修改。
基于以上，怎么理解链上数据既不可以更改又可以更改呢？区块链其实可以类比我们的人生，如果把每天当成一个区块的话，这一天一旦结束，昨天的数据就是无法修改的。但是我们能够在今天把昨天想做的事情做得更好一点，也即我们可以在昨天的区块后再附上一个新的区块。
所以说区块链既不可以修改，又可以修改，不可修改主要是对于已经存在的数据，可以修改主要是指可以附加新的区块，整个历史可追溯。
区块链的技术特性包含以下几个部分：
第一个是分布式共识，通过分布式共识，确保单个节点无法直接写入数据，需要多个节点共识后数据才能写进去。
第二是块链式结构，增加了区块的修改难度，保证数据的完整性。
第三是智能合约，有了在链上的智能合约以后，用户就可以把企业间合作的业务逻辑放在链上，结合链上可信的数据和透明的业务逻辑，加速整体业务流转。
最后一个是密码学技术，包括对称、非对称、零知识，同态加密等来保证链上的数据可信及交易隐私。
区块链的数据难篡改，全程可追溯，全网透明等特性，天然适合应用在存证领域。随着信息互联网的发展，现在的信息越来越多，每天都有海量的信息在网络上产生，这些信息有部分可能会被用来做案件的电子证据。
我们来看一下统计数据，2018年全国受理的总计2800万件的案件中，有73%的案件涉及到了电子数据，仅7%电子证据被认定。这背后的根本原因是什么？电子数据存在以下几个问题：首先它们大多是中心化的，很容易受到篡改。其次这些数据的量很大，很难有足够的人力去处理。另外电子数据的归属问题也难以解决。
从电子数据到电子证据，这中间需要一些必要的转化过程，那么区块链是否可以助力实现这样的过程呢？
从政策方面看，司法端在积极拥抱区块链技术，比如杭州互联网法院基于区块链做的一些判例，最高法对区块链的存证方式也表示了认可。区块链存证既满足合规的需求，同时也有实际的应用需求，这就是至信链落地的背景。
区块链应用是一个分布式的应用，需要多个组织共同加入维护。我们选择跟一些公信力机构合作，包括网安、北明、工信部一所等权威机构，让他们也成为区块链的节点，来共同维护链上的数据。
另外我们也跟司法端进行打通，至信链的节点会部署到一些法院，比如四川高院、前海法院等。
在满足存证的基本需求后，紧接着就会衍生一系列其他的需求。比如存证以后是不是有能力鉴别一下有没有侵权发生？是不是具备侵权监测的能力？如果侵权发生以后是不是能够取证？做完取证以后是不是还能及时的把数据上传到法院......
结合区块链技术，整个内容保护的生态形成了闭环。在整个闭环中，我们会在擅长的领域发力。同时我们也积极接入了其他的能力合作方，比如取证方，版权服务方等。
目前至信链整个内容生态已经加入了很多成员，比如腾讯系的企鹅号、腾讯音乐等，还有很多外部合作方，比如贝壳、得到等。
我们每个人每天在网上都会产生大量的信息，有些信息是有价值的。对于有价值的信息，我们需要及时保护，维护自己的利益。
在至信链中，我们主要是用区块链来做存证。当用户产生数据以后，用户对数据进行哈希处理，然后存储在至信链上。哈希可以保证一个文件到哈希值是一对一的关系，而且很难从哈希值再反推回原文件，如果对原文件做任何修改也都会导致哈希值发生巨大变化。
当用户认为某个数据很重要，比如一张图片很重要，用户可以把它哈希存储到至信链上。但是单纯的哈希值只能证明这个作品已存在，还不能证明它属于谁，所以还需要加上一些电子签名，同时附带上时间戳。这样我们就能知道：什么时候是谁拥有了什么东西。
虽然无法知道在这个用户存证之前这张照片是否已经存在，但至少可以保证：如果你是照片拥有方，第一时间上链基本上就可以保证你的权益。
当上链以后，如果发现这张图片被其他人盗用了，版权拥有方就可以起诉侵权方。版权拥有方提交证据原文到法院端，法院端可以跟至信链打通进行链上的校验，保障版权拥有方的权益。至信链其实和我们的生活息息相关，它服务的不仅是供应链、金融，也包括我们个人的版权。
二、联盟治理
1. 区块链部署方式
区块链是一个多中心的分布式网络。当我们需要搭建一个区块链以及在区块链上做业务的时候，第一个遇到的问题就是：我们该怎么搭建这条链？
这里有几种方式，第一是私有化。对于开发能力和运维能力很强的联盟，可能想要自己部署区块链网络把参与方的各个节点打通，同时所有的运维监控，包括智能合约部署全部都由自己的技术人员来负责。
这样操作是可行的，但是也会带来一些问题。主要问题是区块链的应用还没有正式开展的时候，就已经投入了大量的人力物力在区块链底层上，这也相对延缓了上链的进程。
另外一个方式是公有云，每个云厂商现在都提供了区块链整套的解决方案，只需要在公有云上轻轻地点击就可以帮助部署自己的区块链网络，包括部署智能合约，同时会自动的对区块链网络进行运维监控。
用户不用关心底层链到底怎么实现，只需要关心业务层怎么转化成区块链认可的智能合约。这种方式相对比较快。
随着业务的发展，会渐渐引入一些机构，这些机构或许对数据有一些合规性的要求，这个时候，可以在公有云上再拉一个节点到用户的IDC里面做混合云的解决方案。
2. 数据上链
当我们的网络已经部署好了以后，就需要考虑数据的问题。我们在做区块链应用的时候需要考虑：到底要将哪些数据放到链上？
区块链本身的计算能力和存储是有限的，所以不要浪费有限的计算和存储，只需要把一些关键的信息上链即可，而且关键信息如果很大的话，也可以把关键信息摘要进行上链。
另外对于有争议数据，比如是你单方产生的数据，但是其他方要使用，这时候建议上链；还有多方共同产生的数据，也建议放在链上；对于重要的数据，数据的整个生命周期都应在链上留痕；第三个是多方共同维护的不可拆分的数据也建议上链。
当这些数据上链以后，所有节点都有账本，所有的参与方都可以看到上链的数据。
区块链的透明性是一把双刃剑，所有节点都可以看到就意味着隐私性无法得到保护。这就要考虑怎么在数据上链和隐私安全之间做一个权衡。
数据上链有几种方式。第一种方式是明文上链，数据只要制度上保证联盟参与方不泄露，且不涉及到用户隐私是可以明文上链。
如果明文上链不可行，还可以选择密文上链。数据的原文参与方是看不到的，而且它是不可操作的，并且缺少明文和对应的私钥也是无法验证的。密文上链的典型场景是存证，哈希存证就是密文上链。当然也可以用对称、非对称的方法加密上链。
还有一些涉及到账户操作的，比如虽然是密文，但是需要对它进行加减操作。这时候可以引入同态加密的方式。链上的数据都是加密的，这些加密的数据可以和其他一些数据直接操作，比如密文跟明文相加，或者密文跟密文相加，得到的是密文的结果。持有相关私钥的用户，可以解出正确的结果。区块链在其中负责运算的过程，这就可以做到密文可操作。
密文可操作的缺点在于不可验证。比如用户在链上转了100的资产，这时候其实并不知道用户是否具有100的资产，区块链只是单纯的做了资产相减的操作。这时候希望密文除了可操作，并且还要做到可验证。
例如说链上资产需要减去100，这个时候不需要知道具体的资产数额，但只要能证明链上资产大于100就可以满足要求了。我们可以引入零知识来满足对应的需求。
这些加密算法并不是说每个应用都要全部使用到，主要是根据业务场景需求。在遇到这些场景的时候再结合云厂商提供的方案一起整合到智能合约里，让开发更加顺畅。
3. 数据膨胀
数据上链以后，另外一个挑战就是关于数据膨胀的问题。区块链是一个链式结构，数据存上去以后，后面会不停增加新的区块，它必然会导致大量数据的膨胀，该如何处理呢？
这里有几个解决方案：
第一个方案是：减少区块本身的大小。这样做一方面是优化区块链底层，在区块链底层引擎里把一些不必要的数据去掉或者存储在另外一个地方，只要能证明该区块的有效性就可以。
另一方面是减少区块里业务层的数据，放在区块链里面的数据应该尽量精简，要珍惜有限的存储资源。
此外我们还可以把存储放在云上的块设备里或者放在分布式存储设备里，这样可以支持很大的存储空间。另外如果本身的存储量已经很大了，可以考虑将一些不常用的存储或者几年前的存储归档存放起来。
最后，我们可以以从另外一个角度来考虑，比如数据单链很多，我们可以对区块链进行拆分，这也是做应用常见的方法：当一个库解决不了，就要分库，迁移到这里就是分链。
比如存证应用，特定的存证放在不同的链上，底层可以有多条链，通过底层多链的结构解决单链膨胀的问题。
4. 跨链机制
随着区块链技术的发展，以后涉及到的可能不仅是存证，还存在链上数据交易之类的场景。如果单纯的做接入层分层的话很难保证业务的原子性操作，这时就要引入跨链机制，需要有一个跨链事务层解决链和链之间的事务。
怎么样保证跨链的一致性呢？比如从这条链扣减了，到另外一条链增加，在整个过程要么全成功，要么全失败，所以一定要有一个跨链事务层。
联盟链网络有身份管理，跨链管理也有跨链身份的管理，将它们结合起来就是跨链的治理平台。我们搭建区块链应用的时候，如果场景需要，也要考虑跨链的技术。
5. 业务合规
在业务合规层，明文上链会导致一些敏感词在链上。因为区块链的不可篡改，虽然可以在后续的区块里面增加新的数据，但是它不可以修改原来的数据，这个敏感词就永远留在链上。我们建议：在做业务的过程中要考虑敏感词过滤处理。
另外一个点是：你的业务跟区块链的关系是强同步，还是可以接受异步。强同步的意思就是业务数据是强依赖于区块链数据的，当每次做一个业务，数据都必须从区块链上取，这时候你就需要强同步。但由于区块链本身是异步系统，如果做强同步的话，等待时间可能会影响到业务的体验，这是要考虑的问题。
如果是做异步的话，比如做存证的场景，虽然短时间产生了大量的数据，但是却可以慢慢地把这些数据推到链上。不过这里有个前提：在数据产生过程中，我们需要尽快得产生时间戳。因为只有附上时间戳才能定位数据产生的时间点。后续虽然是慢慢把数据推到链上，但至少证明在某个时间点上已经有了，这解决数据的及时性问题。
另外在区块链应用中还需要考虑整个业务该怎么取消或者撤回，这其实也是合约层需要考虑的。
停止服务在区块链里面是非常难的，因为最多可以停止业务层的服务，但是停止不了底层链，如果停止底层链就需要跟各方协作。所以我们一定要设置兜底方案，当整个业务层遇到问题该怎么兜底，是不是能引入保险机构或者其他机构，特别是在极端异常情况下能够补偿用户的损失。
6. 腾讯云联盟链治理
最后来跟大家介绍一下腾讯云联盟链治理的历程。我们在最开始搭建至信链的时候是跟网安、北明和司法机构一起合作。合作首先要达成一个共识，这个共识就是：我们到底要用区块链做什么。最后达成了统一的共识：从可信电子存证开始。
在此之后，我们跟相关的合作方共同设置一个组织架构，包括定义运作流程和相关的负责人，这样大家就可以一起去推进这个事情。我们知道，即使是一个公司不同的部门如果想协同做好一件事情也是很难的。当涉及到多个公司的时候，如果不设立章程制度的话是很难推进的，所以这点很重要。
当我们已经有了流程架构以后，接下来就要研究我们做的事情是否合规，这就要从政策和合规性去解读，如果有些事情不合规就不能做。
如果合规了我们也还要考虑一个点：它的兜底方案是什么。区块链有那么多特性，比如在供应链场景我们可以结合IoT、AI等能力，证明仓库货物存在。但是不排除这里面会存在某些问题。因为涉及到资金，所以一定要有兜底方案存在。
当有了合规体系构建以后，我们还需要长期的运营投入。搭建好了应用以后，后面就是不停的迭代过程，在迭代过程中也需要其他机构的配合。在这个过程中，需要提前定义好各参与方的利益分配，另外考核评估制度也要定义好。有了这些以后，才能把应用一直往前推。
前面三个点多是文件和组织架构性质的，看起来会和业务不太相关。但是如果没有前面三点打好的基础，后面的第四点就是空中楼阁了，当有前面三个点作为铺垫以后才真正进入到技术规范，在技术规范里面包括联盟网络、节点规划、上链数据、隐私保护、外部系统接入和智能合约等。
三、未来思考
在做至信链的过程中，我们也在考虑区块链未来到底是什么样的形态，区块链以后是不是没有链了呢？我个人认为区块链未来会成为一种底层的基础设施，用户不需要自己去建链，区块链跟其他的技术，如物联网、大数据、视频服务和人工智能会结合在一起，共同服务于复杂的业务场景。
区块链承载的是数据和业务的可信性，链的底层维护方是谁，是不是都需要为自己业务搭建一条独立的链，这也是们需要考虑的问题。从我个人的角度来说，我认为未来区块链不是每个业务都需要搭建一条链，而很可能会公用部分链。
那么至信链未来的发展定位是什么？目前我们和权威机构共同搭建一条数据存证链，保证了数据的可信，同时让可信的数据能够及时流转到法院端，用来更好地服务于内容机构、金融机构，目前的服务包括内容的存证、侵权取证、维权之类等。
后续我们会再结合其他的生态能力，比如版权的、合同的，把强相关的各种能力也做到这条链上，完善至信链服务种类。当这些能力完善后，至信链会为其他不同的产业区块链服务。比如用户可能有自己的区块链应用，但是需要做司法保护的时候，就可以运用至信链跨链把这些数据传过来。
四、Q&A
Q：对那些图片进行小规模的修改，怎么保证它的哈希值是一样的？
A：一旦图片修改了，它的哈希值都是对不上的，所以单纯比较hash是不可行的。在图片信息上链之前，至信链做全网的监控，进行相似性匹配。如果发现有相似的情况是不能上链的。
Q：刚刚提到相似的图片，这种相似度的匹配我个人觉得够呛？
A：我们只能立足于现在，把事情尽量做得更好，因为有些事情只能一步步往前推进，不能说一步就做到绝对，当上传一张图片，经过我们的全网检测，发现没有相似的情况下，就可以进行哈希上链。即使后来发现到有相似的，我们在至信链里也保留了一个申诉通道。用户可以提出申诉，提供相关的证据证明版权的归属，后台人工审核来保护用户的权益。相比从前和现在的版权保护情况，至信链能够让用户更容易地保护自己的版权。
Q：50%算力攻击，下一个区块肯定是在你手上，所以它能篡改上一个区块的信息，导致你上一个区块信息被撤销。比如币链可以先卖了，然后马上在币圈平台套现，在下一个区块出来的时候，上一个区块被回滚了，这时比特币就会回滚到上一家持有人手上，但是钱已经被套现出来了。如果有人套现一个司法证明，证明了一套房产是他的，在这种情况下他会拿到一个有公信力的司法文件，但这个是已经被篡改过的，怎么办？
A：联盟链和公链很大的区别在于联盟链是授权准入的，准入的机构都是权威机构，没有存在改动的必要性。
Q：法院在里面只是扮演查证的角色，还是它也是一个中心？如果不是，那么有没有一个中心？
A：法院是联盟链中的一个节点。在区块链应用中没有中心节点概念。
Q：我们的系统一直是在迭代的，在设计合约的时候有一些字段可能上链，有一些字段不需要上链，但是随着系统的迭代可能会增加字段，也可能会删减字段，那么在智能合约设计的时候，你们有什么样的考虑来解决字段合约设计的问题吗？
A：我们的业务系统在迭代过程中本身的业务数据模式必然会改变，建议你设计的时候放在链上的是最精简的数据。在以后升级的过程中，需要考虑数据兼容性问题，智能合约中需要对数据格式定义不同版本，不同的版本做兼容性配置。
Q：我们考虑的时候是只使用一个字段，全部序列化，在业务版本做校验，你觉得这两种方案哪个更优一点？
A：这要结合具体的场景，如果场景里面涉及到数据是多方协作的，需要合约执行操作的，在合约里面最好能够校验。
Q：当合约里面要做业务逻辑的时候呢？
A：如果要做业务逻辑尽量结构化的。
Q：前几年有人提过Web 3.0，区块链会改变互联网。Web 3.0主要的特性是：后端服务相当于是一个节点，通过前端直接连到节点，相当于服务是无处不在的。要达到这种状态就必须要解决存储过大的问题，这个问题在未来有没有可能会被解决掉？比如一个节点非常小型化？
A：任何数据都是有生命周期的，当然有的生命周期长一点，有的生命周期短一点，对于生命周期短一点的数据可以考虑归档的方案，对于生命周期长一点的，有些是全节点，有些是轻量级节点。
Q：在区块链的生命周期当中不应该只有一个密钥，整个加密的节点，当初存储的时候是分节点计算加密的值，当密钥需要更换的时候，应该不是在中心计算完这个值再去分节点存储，更换密钥的时候这个时间怎么把握，有没有什么好的方案？如果同时所有节点都去更换密钥的话对设计者是比较大的挑战。还有面临的一个风险是：受到攻击时必须要更换密钥了，这有一个不得不去做的时间点，这个要怎么做呢？
A：在联盟链里面节点的身份认定是依赖CA颁发的证书。在底层链设计过程中，更换私钥是有一个过程的，可以把私钥过期当成一笔交易存在链上，通过配置块来快速解决证书有效性问题。一旦你认为这个私钥有问题的话，可以把这个信息进行上链，所有链上的参与方读取到这笔交易后，都会认为这个私钥不能使用了。
讲师简介
李亮
腾讯云区块链高级研发工程师
李亮，腾讯云区块链高级研发工程师，至信链技术负责人。毕业后，一直从事分布式集群相关的工作，致力于打造安全，稳定，高效的系统。
文章推荐
鹅厂这个穷得成本精确到0.01元的微团队，怎么利用IoT与云原生监测大气质量的？
406
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
