一、腾讯云区块链TBaaS介绍
腾讯云区块链TBaas， 是结合云服务推出的区块链平台。其整体结构如下图：
作为一个完整的区块链服务，目前提供的特性有:
(1) 运营上，客户可以根据需要快速创建一套可灵活伸缩的自有应用, 内含高度自动化的合约发布、系统监控及运维。
(2) 调度上，整体系统通过kubernetes实现高效的调度运行。
(3) 安全上，实现基于CA及人脸等的强化用户身份认证。
(4) 隐私保护上，所有的链上数据都是加密的，只有在相关的用户或机构授权后，才能读写操作。
(5) 合约编辑，客户可在页面IDE上自助编写(见下图)，后端会做好相关的语法语义合法检查后自动提交链上，尽量避免目前行业常遇到的合约安全问题。
6) 底层存储上，基于分布式存储来实现几乎无限的拓展。
7) 性能上，目前已实际做到3000TPS(pbft)，高于行业平均值，足以开展一般的商业应用。
8) 在数据后处理上，TBaas还提供方便的AI分析等服务。
在具体的安全处理上，TBaas全面支持国密算法并引入CFCA(中国金融认证中心)，来满足国内金融等行业应用的合规要求，实现法律追溯及仲裁判定，同时还支持硬件加密，以进一步提升加密认证的处理速度。对于合约，基于零知识证明方法，可使得交易的各相关方只需也只能处理自身的数据，同时实现整体交易的完整及不可篡改。
TBaas支持的区块链项目有HyperledgerFabric 和 BCOS等。当前区块链底层研发主要基于Fabric构建。Hyperledger 是Linux基金会于2015年发起的推进区块链数字技术和交易验证的开源项目，目前进化到1.1版本。主要应用于联盟链。
HyperledgerFabric 主要的特点是架构通用化和模块化设计，这样就很便于根据需要来自行调整或优化，还有就是支持基于Go和Node.js的智能合约编辑，易用性较好。在Fabric架构中，明确划分了Endorse Peer(背书节点) / Commit Peer (all peers) / Orderer(共识服务) 三种角色，基本的结构如下图
整个流程，通过初始背书及合约模拟执行等耗时运算的并行执行来尽量提升性能，然后通过共识，按时间串行化交易序列及验证，来实现账本数据的一致性，做到性能及一致性的较好平衡。
在具体开发过程中，我们做了如下的探索。首先是整体系统级的优化，如Signature offload, TLS体系下请求签名处理为CPU密集，并且实际Fabric运行中有相当多同样运算，通过将重复结果缓存，就可以有效提升单链的处理能力，另节点的签名计算和数据落地，因存储链式结构都是单进程串行的，通过pipeline方式，可使签名计算并行化来大大提高整体性能。对于系统的异常如Kafka或底层存储的Leveldb、Couchdb crash，也都做了代码级的修改确保数据无损。
其次就是逻辑流优化， 目前Fabric其采用了乐观锁方法，模拟执行和版本号机制来保证链数据的一致，但对于热点账户等冲突大的情况，则容易导致交易的高失败率，这方面的改进有，1是放弃版本号，读写集改用增量， 2是用影子账号，即将热点账户做部分分拆，然后周期性做这些账户间的平衡调整。
在核心结构方面，现阶段Fabric设计中，Orderer通过Kafka来实现请求有序，这是一个有效的设计，实际测试性能可达10000TPS，但Kafka本身的中心化导致扩展性和稳定性受限，同时管理命令也通过Kafka一同下发来保证节点处理结果一致的机制，导致一旦遇有消息堆积，有可能无法及时生效的问题。解决方案，1对消息队列，要求管理消息可插队，即消息分优先级；2 引入分布式共识算法如pbft。在应用pbft并做实现优化后，实测数据达到3000TPS。客户可根据实际场景需要在两种共识方法中选择。
在底层存储方面，Fabric区块结构目前是完全链式的，这导致即便无关的两笔交易，节点的校验写入也必须串行进行，初步规划使用DAG或HashGraph图等结构来使操作并行化从而进一步提升性能。
当前的区块链应用，一类是各种数字货币，这是典型的天然适应场景，通过尝试激励等策略构建一个特定的生态，还有就是在其他各行业的推广应用，一般都是利用去中心化和数据不可篡改的特点，来解决多方之间的相互信任及信息处理问题，诸如供应链融资授信、商品防伪、医疗病历和影像共享、物联网数据安全、跨国清算、交易实时对账等。
就现阶段而言，区块链的应用还在不断的探索和尝试当中，亟需各种实际的落地案例来验证各类技术方案的可行性和有效性。而判断一个场景是否适合，我们建议考虑如下原则，1) 有明显的共识需求2) 多方有记账意愿 3)数据开放且多方对等(这里不代表可以直接查看，有可能要授权解密)，典型如交易对账，多方都有记录，也都需要一个明确认同的结果，就比较适合。
目前TBaaS 区块链落地场景很多，这里举两个比较典型的案例: 一个是爱心人寿，主打保险理赔，一个是微特，主打供应链金融。
在与爱心人寿的区块链合作上，主要探索将医疗机构、保险公司、卫生信息平台等组织成区块链联盟，打通诸多相关环节，将数字存证信息安全高效地保存在区块链上，力争从根本上解决医疗数字信息的安全性、关联性等应用技术问题，实现真正意义上的医疗、保险等信息安全共享和互联互通，为用户提供高效直通安全优价的健康医疗和保险保障服务。
具体做法如图，机构分医疗机构、保险公司、病例中心、监督节点多方，这里各方如医疗机构、保险公司等实际都是有多个组织组成的，为简化，图上只列一个。
实际的保险理赔中，客户的麻烦在于病例单据的收集和整理，保险公司的难点在于对病例的甄别及有效性验证，这是难以信任的两方，并都要有一定的成本付出（如跨医院处理），而医院作为中间方，承担着对于病例的保管责任，在现实中也有对其他医疗机构病例的查看需要。这就同时满足了区块链应用的几个要求: 有客户和保险公司共识需求，有医院间多方记录的需求，有数据开放共享的需求。考虑到客户记账的不便，引入病例中心和监督节点(可选)参与第三方记账，这些共同构成典型的区块链病例记录场景。
因区块数据的不可篡改性，保险公司只要经用户授权并经医疗方同意即可拿到翔实的病例单据实现有效准确理赔。对保险公司，只需付出少量的成本，对用户则无需成本还更方便。保险公司付出的成本将转化为对医疗机构及病例中心的物质激励，进一步促进整个区块链的良性运转。
在保险公司支付的成本转给到多方医疗机构和病例中心时，有定期对账清算的需求，这又是前文提及的典型对账场景，将实际医疗机构同意时(即背书)的交易信息上链，通过智能合约，各方就可以在本地清晰确定自己的收入，实现去中心的准确对账。也就是通过区块链，可以解决保险理赔全程各方间的数据核对及收入分成问题。
供应链金融，是区块链另一个相对契合的适配场景，基于区块链去中心化的共享、信任及安全机制，可以有效地解决供应链金融有关的转让、交易、及监督问题。微特场景，主要是将各类供应链有形资产数字化，比如农产品，可提前半年以数字化票据(通过区块链让更多人员参与)形式来公开预购，半年后到期交割。这期间如遇资金紧张，预购方可将部分票据提前卖出，到期则可以将票证转给批发商或最终用户，再由批发商等直接提货。这样可以省去仓储和提货成本，减少中间的步骤，并降低信息不对称的无效成本，通过互联网新技术来提升整个农产品的交易效率。
目前区块链还是属于一个方兴未艾的领域，不断地有精彩纷呈的新技术提出，有资料提到区块链已经进化到4.0，但细究下来看，更多还处于试水(POC)的状态，而从行业来讲，一般都是需求催生技术进步，或者说在周边技术已经基本成熟铺垫好的情况下由需求来选择，而当下的区块链，则更多是基于技术的特点来延展或构建需求，而非必然需求，这是当前区块链发展亟待解决的关键问题。在本文中，提出了两个与实际相对契合的例子供大家参考。
随着行业的发展，人与系统和系统间（如各种IOT设备）联系的不断紧密，传统的中心化架构必然在可伸缩性等方面面临挑战，而去中心的化的区块链应是有良好前景的可选解决方案。计费平台部将会结合自身在分布式系统事务及算法上的积累，来不断解决区块链面临的技术问题。相信随着区块链的不断进化，一定会有更多的应用场景来展现其价值。
原文地址：http://blog.51cto.com/13591395/2112169
