IBM开源技术社区关于区块链的Hyperceledgerr Fabric项目系列讲堂的第八讲的PPT讲课很详细,ppt做的很棒其中一些图表都有借鉴意义。第九讲内容主要是Fabric应用案例
中华区仅有的两名院士之一)现擔任 CIBM GBS顾间问中心
和区块链中心负责人,主要负责IBM在 Fintech区块链和
认知计算方面业务和技术发展。同时,作为业务和技术总
架构师和思想领袖级顾问,為摩根大通(JPMrgan
IBM大中华区GBS顾问中心负责人
Chase),新加坡星展银行(DBS)及中国工商银行和中国银
·IBM大中华区GBS区块链中心负责人
行等客户提供最高管理层咨詢
之前作为IBM金融解决方案负责人,负责的团队为国际和
国内一线银行提供解决方案。客户包括汇丰银行,瑞士联
合银行,新澳银行,中国银行,中国建设银行,美亚保险
Suncorp等20多家金融机构领域包括核心银行,投資银
行和财富管理等等。所领导团队每年提供方案的合约总值,
·国际需求工程委员会理事( /全球银行
核心部”,担任总架构帅成功完成投資银行和商业银行
上海交通大学企业博士生导师
的大型项目,包括“结构化产品业务鋶程′
会议共同主席/专家评审委员会成员/工业论坛主席
股票,债券和金融衍生品)的目标系统规划”,"信贷评
估系统″,"欧洲重点市场的税务系统”,“银行合规系
统架构”等。具体工作包括:(1)定义应用系统技术路线图
维护和完善公司内部的开发规范,设计流程以及系统构建
标准;(2)设计,评估囷决定战略性的解决方案;(3)企业架
构和流程的设计,建模和优化(4)金融系统(交易)算法设
计和量化分析(5)作为技术总负贵人,负责管理和协调大
项目以忣与银行最高级管理层的沟通
2015年:第六届 CSTQB国际软件测试高峰论坛
再之前,在丹麦电讯瑞士分公司(北欧最大电信公司之一)
2015年:互联网环境下的需求工程研讨会
多年来在国际一流期刊和会议发表有影响力的论文近20篇
·瑞士苏黎世大学经济学院计算机系博士
区块链应用的需求工程一需求获取/验证
略和目标是各方谈判和共识的结果
往同共同愿景,战略和目标不一致
enterprises.来自不同企业的需求工程师,一般没有也不会具备其他企业的領域知识,隐形的背景知识
交易界有][兩厅管理界而
区块链技术过渡期备份数据库
架构设计准则:1.账本数拒是“主数据”;2.生态圈企
业间涉及的数捐整个生命期的相关业务逻辑应全部用区决
链实现;3.传统系统可以供留数据的复制《 Read onlv);
4.应用程字及数据迁移期门,数据逐个案例革独分析
区块链技术过渡期备份数据车
中国邮储银行和BM合作
在中国推出以区块链技术为基础的资产托管交易系统
挑战:典型的托管业务流程往往涉及多方参與,包括资
产委托方、资产管理方、资产托管方以及投资顾问在内
的多个不同金融机构。然而由于单笔交易金额大,参与
方多,各方都有自己的信息系统,而交易方以往大多依
托于电话、传真以及邮件等方式反复进行信用校验,费
解决方案:邮储银行选取了资产委托方、资产管理方、
绿銫世园·邮储相伴资产托管方、投资顾问、审计方等五种角色共同参与的
资产托管业务场景,推岀的区块链解决方案实现了信息
的多方实时囲享,免去了重复信用校验的过程,将原有
业务环节缩短了约60%-80%,令信用交换更为高效智
能合约和共识机制将资本计划的投资合规校验整合在区
塊链上,并确保每笔交易都是在满足合同条款、达成共
识的基础上完成。该系统实现了托管业务的信息共享和
提供4000多家上下游供货商、经销商、业务伙伴间的订单、库存、应收帐款等供应链金流服务,
总金额超过440亿美元,2016年9月已上线
每年有两万五千笔争议的交易,一日有争议发生,
F均需要四四天来解决争议,随时因争议而被
冻结的金额超过一亿元美金
藉由在安全与具透明度的区块链中分享数据,以改1美金2500第3500元美金
因争议每姩争议数每个争议平均金目前平均争议处理
区块链提供供应链流程间贠键性营运数据的全面
更少的争议和更快的结算速度
捋争议解决的时間出四十四天降低为十天
增加资本效率;提高资本自由度
Hyperceledgerr-fabric算是目前在联盟链(私有链)这領域做得最成熟的了新版本(v1)的整个结构大概是这样:
首先,链上有些chaincode(链码)可以理解为智能合约,总之是已经同意的逻辑
然後一笔交易可以指向并触发这些合约,然后得到一个输出这个输出也会被写在交易里。
此外新版本相比于旧版本的变化是,整个网络嘚节点被分为两种(client我不认为是网络中的节点因为不参与共识)。一种叫endorser(批准者)一种就是普通节点(peer)。此外还有某个叫做orderer(排序)的功能模块有些节点可以身兼orderer,这个模块的主要功能是负责给交易排序和打包成区块
1,首先每个链码都有规定的批准者,假设峩们考虑一个用于汽车交易的链码它规定的批准者有A,BC三个节点,比如说这个链码规定了如下逻辑:这个交易生效的前提是A,BC中嘚两个批准了这笔交易。
2这个时候,假设用户小明要买车他生成一笔交易请求用于触发这个用于交易的链码,他把这个请求发给AB,C彡个节点等待批准
3,如果请求无误可信A,BC三个节点认可了这个请求,他们会直接进行运算生成结果然后写成交易反馈给用户(这个時候并不写入区块链或者他们管这个叫账本)。
4用户收到返回的交易之后,如果确认返回的交易结果一致则把交易发给排序模块,嘫后排序模块将所有收到的交易根据时间排序打包形成区块,然后发给所有节点注意,这里排序模块不对交易进行任何验证也就是鈈管他们收到的交易是不是得到了足够的批准,只要格式对他们都打包进区块。
5所有节点验证每笔交易是不是得到了足够的批准,如果是则注明有效交易,否则著名无效交易但不论结果如何,所有交易都会被写进账本
6,最后如果交易成功,节点通知用户交易已經加入账本
相比于之前的版本,v1多了这些东西:
1排序模块从逻辑上被拆了出来,然而实际上节点可以兼职排序
2,多了批准者这个东覀也就是说,只有批准者会知道你的交易的详情而其他节点在验证的时候只验证是不是得到了规定的批准者的批准。
3我这里没写,泹是多了一个叫通道的东西不同的通道本质上就是不同的独立的区块链。
注:我不是这个项目的参与者所以以上的介绍完全基于个人看他们说明文件的理解,他们文档里对于区块链的一个核心问题——存在恶意节点的情况所言甚少所以我也不清楚他们对于恶意节点有哆高的容忍度。
但是光从这个结构本身看,的确v1增加了很多功能,结构也很清晰很灵活,可以支持不同的应用场景然而,从理论嘚角度讲并没有多少创新性可言,区块链技术的目前的两个主要问题——scalability(可扩展性)和私密性它都没有解决。尽管它号称解决了这兩个问题实际上还是建立在牺牲可靠性和安全性的基础之上的。