mirror of
https://github.com/cheetahlou/CategoryResourceRepost.git
synced 2025-11-19 15:43:44 +08:00
del
This commit is contained in:
119
极客时间专栏/geek/深入浅出区块链/第四章 区块链与当下互联网/第29讲 | 互联网身份与区块链数字身份.md
Normal file
119
极客时间专栏/geek/深入浅出区块链/第四章 区块链与当下互联网/第29讲 | 互联网身份与区块链数字身份.md
Normal file
@@ -0,0 +1,119 @@
|
||||
<audio id="audio" title="第29讲 | 互联网身份与区块链数字身份" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a1/7b/a18a2ad7520f804522a31b9068a4847b.mp3"></audio>
|
||||
|
||||
前面的一系列的文章,我们一起从区块链技术聊到了数字货币,接下来又讲到了数字资产的话题,相信你应该对区块链应该有了一些了解。接下来,我们将要进入一个全新的专题,来聊聊区块链可以与互联网发生什么反应。
|
||||
|
||||
今天我要讲的是数字身份,为什么要聊身份这个概念呢?
|
||||
|
||||
这也是从比特币身上获得的启发,比特币上不存在无主的资产,也就说任意的资产必然归属到一个地址上。所以我们就在思考,是否可以更进一步,这种联系是否可以不仅限于地址,而是可以扩大到人的身上。
|
||||
|
||||
## 什么是身份
|
||||
|
||||
数字身份是一个依托互联网产生的概念,那么在谈论数字身份之前,我觉得有必要先和你达成一下“身份”这个概念的共识。
|
||||
|
||||
如果说比特币记账记录的是资产的转移,那么对应到身份上,也可以抽象出类似的概念。
|
||||
|
||||
想象一下,“你的出生”这一事件是被谁所记录,“你昨天发的朋友圈”都在被谁所记录?
|
||||
|
||||
这么一来,身份的概念几乎也呼之欲出,身份是指有关你发生的一切客观历史的事件集合。
|
||||
|
||||
例如,你的身份证上简要记录了有关你的客观事实:你的出生日期、民族、户籍所在地,为了证明这些信息属实,所以国家给了这么一个证件,为此还戳上了一个唯一编号,也就是你的身份证号。
|
||||
|
||||
但我们要弄清楚的是,身份证并不是你的身份,只是你的凭证,你真正的身份托管在政府机构、银行、医院、社交平台的数据库中,换句话说,有关你的重要客观历史事件记录被这些机构所记录下来,这些记录组成了独一无二的你,使得你变得具有一定的辨识度。
|
||||
|
||||
你的身份记录也分为了两种,一种是资产和消费记录,另外一种是社交记录。支付宝做了前者,微信做了后者,这两者都是中心化的设施。
|
||||
|
||||
## “身份”的前世今生
|
||||
|
||||
关于身份的难题古往今来一直有之,上至皇帝大臣,下至教书先生普通老百姓,如何证明自己的身份一直是一个难题。
|
||||
|
||||
从历史上来看,主要经历了三个阶段。
|
||||
|
||||
### 1.印章实物身份
|
||||
|
||||
这个很好理解,就是自己给自己颁发一个刻章,这个章由于带有私人标记,一般独此一份,很难被人模仿,例如玉玺、虎符等,这些就是为了表达身份的概念。
|
||||
|
||||
但是这个概念特别弱,因为古代生产力低下,无法大量记录客观事件,才把所有事件集合归并退化成一个小小的章。这也是不得已而为之,所以在古代谈不上准确的可定义身份概念,但是,现代的身份却也都是基于这种逻辑下产生的,例如我接下来要讲的卡片型身份。
|
||||
|
||||
### 2.卡片型身份
|
||||
|
||||
随着技术发展,卡片的流行发展了身份的概念,这里的典型就是名片、护照、身份证、驾照等等。
|
||||
|
||||
但这些卡片背后记录的依然是割裂的身份片段,例如医院就诊记录归医院所有,出入境记录归出入境管理局所有,商场消费记录归商场所有,这些记录都是割裂的。
|
||||
|
||||
如果出入境管理要你出具商场的消费记录,显然就变成了你的跑腿工作,这就是你的身份片段割裂所引起的。
|
||||
|
||||
不过这种情况在国内稍有改善,这得益于身份实名制的强制实施,身份证编号是被所有系统统一的唯一索引,通过打通身份后台系统,可以共享一些基本信息。
|
||||
|
||||
卡片型身份也在自我迭代,目前多数都被做成了芯片卡的样式,里面集成了一些基本的终端验证信息,所以可以提供电子化身份。
|
||||
|
||||
### 3.互联网身份
|
||||
|
||||
这个阶段就有了一些真正意义上的身份概念了。
|
||||
|
||||
你的出生地、户籍、微信朋友圈的记录、授权过的App、消费记录、挂号就医记录,通过微信或支付宝可以将以往的身份片段串联起来,形成一个可定义你的唯一身份。
|
||||
|
||||
举个典型例子,微信和支付宝可以满足大多数场合的身份证明的要求,例如医院就诊使用微信预约,医院需要知道你登记的信息是否准确,所以可以通过微信授权。支付宝也是如此,芝麻信用甚至可以提供身份声誉的概念了。
|
||||
|
||||
这两者的最终一步只需要打通和政府机构的身份数据管理,那么互联网身份有了这份加持以后就可以变成身份的完全体了。
|
||||
|
||||
在中国的任意区域的绝大部分场景,出示微信或支付宝来证明身份似乎不再遥远。
|
||||
|
||||
## 现阶段的身份问题
|
||||
|
||||
总结来说,我们正处于卡片型和信息化身份混用的阶段,我们在日常交流中需要的身份证件,例如护照、驾照、社会保险卡、商品序列号等,基本都是由国家或第三方机构颁发的,虽然这可能是模拟现实世界运作的首要方法,但这种方式也逐渐凸显了许多问题。
|
||||
|
||||
<li>如果国家撤销其证书,个人可能会失去他们的身份,身份应当是与生俱来的概念,国家可以选择承认与否,但不应该存在黑户这样的人群。
|
||||
</li>
|
||||
<li>某个中心机构签发的身份证明,往往不能被其他机构所接受。
|
||||
</li>
|
||||
1. 集中控制的身份管理,只能在一个辖区或一个在线服务内有效。
|
||||
|
||||
随着区块链的出现,身份证明的瓶颈逐渐缓解,就像使用比特币并不需要申请账户一样,它也创造了重新定义身份的崭新机遇。
|
||||
|
||||
## 从互联网身份到区块链数字身份
|
||||
|
||||
互联网本身其实是围绕着机器建立的,而不是人类,换句话说,互联网虽然提供了信息高速公路,但是并没有提供中立、开放、统一的身份层。
|
||||
|
||||
于是,我们在互联网里,无法知道谁究竟是谁,它帮助谁连接了谁。当然,这在互联网早期是一件好事,它们并不能从我们身上窃取太多数据。
|
||||
|
||||
但是现在随着互联网应用程序变得越来越丰富多样,场景也十分复杂,典型的就是电子商务和社交媒体的普及。
|
||||
|
||||
W3C以及一些标准化组织,提供了一些互联网身份的标准。这些标准的初衷是为了更好地服务互联网应用,但是这些标准被实施的过程中,仍然凸显了很多问题,例如前段时间Facebook 8000多万账户数据滥用事件。
|
||||
|
||||
面对这些问题,我们这里总结了互联网身份问题以下的几个点。
|
||||
|
||||
1. 身份数据的安全性问题,面临泄露和被篡改的风险。
|
||||
1. 不同机构之间的身份数据的兼容成本很高,带来身份数据碎片化且不一致的问题。
|
||||
1. 用户无法控制属于自己的数据,例如你今天发布的照片,并不知道会被哪个推荐系统采用。
|
||||
1. 重复创建和管理不同应用下的身份,典型案例就是重复注册各种账户。
|
||||
1. 虚假身份欺诈,这个比较好理解,就是被我的身份被盗用,尤其在账户泄露的时候。
|
||||
|
||||
概括起来主要是三个方面:非用户自主的身份、身份数据安全与隐私问题、身份数据所有权问题。
|
||||
|
||||
以上这些问题,例如W3C、Sorvin基金会和OpenID基金会正在寻求一些去中心化的数字身份方案,微软也在关注如何利用区块链构建去中心化的区块链身份,这也是区块链数字身份研究的前沿。
|
||||
|
||||
如果想做区块链数字身份,我认为,这里必须涵盖身份的两大核心功能:验证和授权。
|
||||
|
||||
有关授权的内容,区块链天生就可以做授权,基于密码学的账户体系可以很好地控制数据自主,也会强制性地让运营商把身份控制权还给用户,并且,一切的关键数据都可以被登记下来。
|
||||
|
||||
这似乎迎合了我们一开始对身份的定义,记录客观事件的集合,并且,数据的集合可以被登记到区块链上。
|
||||
|
||||
另外,区块链数字身份还有个天然的优势是,可以无缝与区块链数字资产进行连接,把以往割裂的信息化身份和金融身份打通,这也是支付宝一直没有做到的。
|
||||
|
||||
换句话说,区块链的数字身份系统,它自带了去中心化用户自主的身份、并且可以与用户的资产进行连接,这些都是以往没有做到的内容。
|
||||
|
||||
当然,机遇越大,挑战也越大。这里,我也总结了一下区块链数字身份面临的三个挑战。
|
||||
|
||||
1. 如何控制个人身份在区块链上的隐私边界?
|
||||
1. 现实中会产生庞大的身份数据,区块链无法承载这么多数据该如何解决?
|
||||
1. 如何兼容上述三种类型的身份,例如已经存在的互联网身份?
|
||||
|
||||
在光明与挑战兼具的路途之下,区块链的数字身份究竟会如何发展,关于未来,让我们拭目以待。
|
||||
|
||||
## 总结
|
||||
|
||||
好了,今天我带领你一起探讨了区块链数字身份的话题,我们先从身份的原始概念开始讲解,接着介绍了身份的简要发展和现在面临的问题,最后介绍了区块链数字身份和它面临的挑战。
|
||||
|
||||
那么今天的问题是,你觉得区块链数字身份会是接下来的热门概念吗?你可以给我留言,我们一起讨论。感谢你的收听,我们下期再见。
|
||||
|
||||
|
||||
161
极客时间专栏/geek/深入浅出区块链/第四章 区块链与当下互联网/第30讲 | 区块链即服务BaaS.md
Normal file
161
极客时间专栏/geek/深入浅出区块链/第四章 区块链与当下互联网/第30讲 | 区块链即服务BaaS.md
Normal file
@@ -0,0 +1,161 @@
|
||||
<audio id="audio" title="第30讲 | 区块链即服务BaaS" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/f9/f4/f9572f7426874455f6d4be72033dc9f4.mp3"></audio>
|
||||
|
||||
今天我来聊一个常常被公链忽略的区块链概念:区块链即服务。
|
||||
|
||||
“区块链即服务”,也就是Blockchain as a Service,它的缩写是“BaaS”,一看这个概念,就知道它离不开云计算了,毕竟云计算的领域已经有了IaaS(Infrastructure as a Service)、PaaS(Platform as a Service)和SaaS(Software as a Service)等概念。我们看见了带有“aaS”的后缀,便很容易联想到了云计算的范畴。
|
||||
|
||||
从商业角度来说,商业技术公司提及BaaS主要还是为了卖云服务,因为大型机构偏向标准流程化的协作方式,也就很难意识到区块链带来的非技术层面的革新,这种现象在公链领域的数字资产上尤为突出,如果单纯地把区块链作为一种技术框架集成到云计算中,未免失去了区块链原有的魅力。
|
||||
|
||||
那么区块链到底与云计算有什么千丝万缕的关系呢?这就是我今天想抛砖引玉的地方。
|
||||
|
||||
## 两个角度出发
|
||||
|
||||
在讨论“区块链即服务”之前,我想提出一个比较新奇的观点,就是假如我们把比特币看做一个云,那么比特币就是世界上最大的云,只是比特币没有特定的供应商,它是开放式的,这个云提供了价值存储和价值传输的功能。
|
||||
|
||||
如果你也认同我的这种假设,那么接下来就需要考虑一个问题:它应该如何与已经存在的云计算进行结合呢?
|
||||
|
||||
以上是我从云计算角度提出的观点。另外一个观点是从协议考虑,如果比特币是一种开放式协议,云计算可以说是一堆成熟协议和框架的集合,那么是否可以把比特币这种支付协议集成到云计算中呢?
|
||||
|
||||
带着这两个问题,我们重新考虑一下“区块链即服务”这个概念。
|
||||
|
||||
## 什么是“区块链即服务”
|
||||
|
||||
如果我们打算弄清楚“区块链即服务”的概念,首先我们需要找到“区块链即服务”与PaaS的联系。这里没有提到IaaS与SaaS,因为我认为“区块链即服务”与PaaS更接近一点。
|
||||
|
||||
我们先来简要地了解一下PaaS, 我们在上文提到过,PaaS的英文是“Platform as a Service”。它是一组通用业务组件(Component)的集合,它能够提供开箱即用的业务服务,但并不类似于AWS的Amazon Translate服务、阿里云的短信服务这样单纯的技术框架或者代码包。
|
||||
|
||||
我们接下来考虑比特币,比特币提供了全球支付的功能。那么这种功能是否可以集成到云服务中呢?答案是肯定的。
|
||||
|
||||
例如我们希望可以在云计算平台快速实例化一个比特币的全节点,而不是自己去比特币的官网下载,并经历将区块同步至最新的漫长过程。
|
||||
|
||||
与此同时,对于有比特币支付需求的应用来说,除了搭建全节点,往往还要解析每一个区块的信息,因为区块本身是非结构化的,无法进行精细化控制查询,所以结构化区块数据显得尤为重要。
|
||||
|
||||
并且,这里往往是通过RDB数据库进行存储的。等待区块完成异常同步之后,接着还要解析并且结构化存储区块,可以说是雪上加霜。
|
||||
|
||||
从技术角度考虑,比特币全节点本身提供的查询API功能有限,查询负载也非常有限,我们不可能使用部署多个比特币钱包集群的方式来分担负载,因为全节点的数据非常庞大,5个比特币全节点已经是TB级别,而且还在一直增长。
|
||||
|
||||
随之而来的,还有各种区块链软硬分叉维护、节点宕机监控,简直是噩梦。
|
||||
|
||||
但是暂停一下,我们回过头来看看,这难道不就是以往PaaS解决过的痛点吗?
|
||||
|
||||
以上只是举了例子,那么以太坊也可以如此,其他公链也是如此,实际上由于区块链本身就是基础设施,所有的区块都已经被历史定格不需要改变,这些庞大的区块数据本身也是PaaS的一部分。
|
||||
|
||||
结合云计算厂商的技术能力,它们可以提供稳定、方便、安全的区块链服务,帮助中小企业快速集成区块链服务,例如支付、身份验证服务。
|
||||
|
||||
根据以上分析,这样我们便可以给出区块链即服务的定义。
|
||||
|
||||
“区块链即服务”是指:提供多种方式的查询、交易广播、交易验证服务,使得公有区块链的服务可以集成到到互联网应用的架构中,这些服务包括了数字货币、数字资产、身份验证服务、第三方监管服务。
|
||||
|
||||
以前的这些服务是处于割裂状态的,那么从PaaS衍生出来的BaaS可以帮助区块链被快速地集成和整合到已有的技术架构中。
|
||||
|
||||
上文提到,与BaaS最接近的是PaaS,那为什么不是SaaS呢?SaaS最好的例子是Google Docs,直接面向普通用户,并且按需按时间付费使用厂商的应用是SaaS的显著特征。
|
||||
|
||||
这里一个典型的例子是公告公证,今年北京大学发生了一件事情,就是有人将有关某个教师的事件登记在区块链上,那么这可以算作一个SaaS的典型,进一步看,blockchain.info这个平台也算作一个SaaS平台。
|
||||
|
||||
SaaS要求用户可以直接使用区块链快速构建应用,构建过程最好是可视化的,而不是一堆代码,所以目前来看区块链领域的SaaS还尚不成熟。
|
||||
|
||||
IBM和微软曾经提出过BaaS的概念,它也对标PaaS,这里的区别在于客户是使用区块链技术框架构建起属于自己的联盟链,还是使用公链上的服务。
|
||||
|
||||
前者更多的是DLTs技术(destributed leder technology),所以这里我们叫做BTaaS,BTaaS也可以被传统IT方案替代,例如分布式存储方案。
|
||||
|
||||
由于公链提供的服务往往会比联盟链丰富,生态发展快速,如果公链具有匿名性和权限管理机制,也许可以替代许可链。
|
||||
|
||||
## 架构集成与快速构建
|
||||
|
||||
架构集成主要考虑在已知的系统架构模式情况下,如果让“区块链即服务”可以更快速方便地被已有架构集成。这里的挑战困难主要包括两个方面。
|
||||
|
||||
第一、系统级的多币种私钥管理体系。因为区块链本身就包含了大量资产,这些资产可以看做是线上资产,如果有没有进行良好的权限管理,那么资产将面临极大的失窃风险。
|
||||
|
||||
第二、稳定可控的区块链服务。稳定可用是考虑任何一个钱包稳定连续运行,一旦被控制或者被分叉,系统可以快速识别并警告运营者。
|
||||
|
||||
总之,架构集成是一个比较大的话题,也有很多经验可以从经典互联网应用中获得,主要还是开发和运维的思路需要转变。
|
||||
|
||||
## 互联网公司在区块链领域的尝试
|
||||
|
||||
既然聊到了区块链即服务,就不得不聊聊国内已经尝试实践“区块链即服务”的公司了,无论是BaaS还是BTaaS,这其中都有所体现。
|
||||
|
||||
一线互联网公司更倾向DLTs技术,也就是BTaaS类,三四线以及业绩边缘化的互联网公司倾向于Token为代表的经济生态,也就是BaaS技术。
|
||||
|
||||
下面是我们公司的Frank收集分类的国内应用案例,涉及的行业有金融、公益、互联网、食品溯源、物流、电商等领域,我在这里列出来供你参考。
|
||||
|
||||
<li><p>蚂蚁金服区块链,联盟链。
|
||||
蚂蚁金服技术实验室宣布开放区块链技术,支持进口食品安全溯源、商品正品溯源、支付宝爱心捐赠平台。</p>
|
||||
</li>
|
||||
<li><p>阿里健康区块链,联盟链。
|
||||
阿里与常州市政府就医疗数据保护达成共识,推出了国内首个在医疗行业的区块链解决方案——阿里健康。</p>
|
||||
</li>
|
||||
<li>Symbiont,其起源于Counterparty(合约币)项目,旨在建立第一个用于发行区块链智能证券和交易智能证券的平台。
|
||||
</li>
|
||||
<li><p>跨境食品溯源,联盟链。
|
||||
阿里巴巴与普华永道(PwC)达成合作关系共同开发一种使用区块链技术的系统来减少食品假冒。</p>
|
||||
</li>
|
||||
<li><p>阿里邮箱+法链,公链。
|
||||
将使用名为“法链”的区块链技术,推出基于阿里云平台的邮箱存证产品等。</p>
|
||||
</li>
|
||||
<li><p>阿里云+Hyperledger,联盟链。
|
||||
阿里云上推出了Hyperledge Fabric区块链自动化配置和部署的解决方案。</p>
|
||||
</li>
|
||||
<li><p>数字雄安区块链实施平台,联盟链。
|
||||
阿里巴巴、蚂蚁金服与雄安签署战略合作协议,将承建“数字雄安区块链实施平台”。</p>
|
||||
</li>
|
||||
<li><p>天猫奢侈平台Luxury Pavilion溯源,联盟链。
|
||||
阿里云发布区块链解决方案,支持天猫奢侈平台Luxury Pavilion推出全球首个基于区块链技术的正品溯源功能。未来消费者只需点击“一键溯源”,便可了解产品产地、入境报关时间等信息。</p>
|
||||
</li>
|
||||
<li><p>金链盟FISCO BCOS区块链平台,联盟链。
|
||||
由腾讯牵头,集结了微众银行、平安银行、招银网络、京东金融、华为等31家企业。旨在整合及协调金融区块链技术研究资源,形成金融区块链技术研究和应用研究的合力与协调机制,提高成员单位在区块链技术领域的研发能力,探索、研发、实现适用于金融机构的金融联盟区块链,以及在此基础之上的应用场景。</p>
|
||||
</li>
|
||||
<li><p>微黄金,联盟链。
|
||||
腾讯财付通与工商银行合作,以工商银行的黄金产品为基础,联合推出的在线黄金交易服务。其中,由腾讯提供联盟链的底层技术支持。</p>
|
||||
</li>
|
||||
<li><p>公益寻人链,联盟链。
|
||||
将区块链技术应用到公益领域,连接腾讯内部多个寻人平台,实现各大公益平台的信息共享。</p>
|
||||
</li>
|
||||
<li><p>星贝云链,联盟链。
|
||||
以腾讯区块链技术为底层打造的供应链金融服务平台“星贝云链”,是国内首家与银行战略合作共建的基于区块链的供应链金融平台,也是国内首个基于大健康产业构建的供应链金融平台。</p>
|
||||
</li>
|
||||
<li><p>TrustSQL,联盟链。
|
||||
腾讯发布区块链项目TrustSQL,旨在以区块链基础设施构建安全高效的解决方案,为企业及机构搭建价值连接器,共同推动价值互联网发展。</p>
|
||||
</li>
|
||||
<li><p>腾讯云金融级解决方案BaaS,联盟链+私链。
|
||||
腾讯云发布区块链金融级解决方案BaaS(Blockchain as a Service)。</p>
|
||||
</li>
|
||||
|
||||
这套方案构建在腾讯金融云之上,并整合了腾讯在支付、社交网络、媒体网络、征信平台等业界领先领域的资源在内的解决方案,将在智能合约、互助保险、大数据交易及资产交易、供应链金融与供应链管理、跨境支付/清算/审计等场景下,为金融用户提供安全、可靠、灵活的区块链服务。
|
||||
|
||||
<li><p>腾讯云+Hyperledger,联盟链。
|
||||
腾讯云加入Hyperledger,参与国际区块链生态建设,推动区块链技术以及相关标准的制定。</p>
|
||||
</li>
|
||||
<li>区块供应链联盟链+云单平台,联盟链,腾讯与中国物流与采购联合会(简称“中物联”)签署了战略合作协议,并发布了区块供应链联盟链及云单平台。
|
||||
</li>
|
||||
<li><p>京东区块链平台,联盟链。
|
||||
京东发布自己的区块链平台,愿景是协同盟友构建新一代基于互联网的“可信价值传递基础设施”,服务于商业数据的高效可信传递。与此同时,京东积极推动自身的零售和供应链大数据“上链”,通过场景数据在区块链中的传递,助力基于区块链技术实现规模化应用,建立社会化跨主体共享的区块链联盟链网络。</p>
|
||||
</li>
|
||||
<li><p>国内信用证信息传输系统,联盟链。
|
||||
苏宁银行加入由中信银行上线的国内首个区块链信用证信息传输系统,成为联盟成员。</p>
|
||||
</li>
|
||||
<li><p>区块链黑名单共享平台,联盟链。
|
||||
苏宁金融宣布上线基于区块链黑名单共享平台系统,即采用超级账本Fabric联盟链技术,将金融机构的黑名单数据加密存储在区块链上,金融机构可通过独立部署节点接入联盟链,开展区块链黑名单数据上传和查询等业务。</p>
|
||||
</li>
|
||||
<li><p>小米移动+Hyperledger,联盟链。
|
||||
北京小米移动软件加入超级账本项目。</p>
|
||||
</li>
|
||||
<li><p>网易星球,区块链应用。
|
||||
网易星球为用户构建星球居民身份,集合用户的社交、娱乐、购物、出行等相关数据(实际跟区块链技术并无天多关系)。</p>
|
||||
</li>
|
||||
<li><p>玩客云,区块链应用。
|
||||
迅雷推出基于区块链技术的玩客云共享计算生态、CDN共享经济,并发行代币玩客云(现已改名链克,停止了内地转账功能)。</p>
|
||||
</li>
|
||||
<li><p>迅雷链,公链。
|
||||
迅雷发布了拥有百万级并发处理能力的区块链项目——迅雷链。采用独创的同构多链框架,在业内率先实现了链间的确认和交互,不同交易可以分散在不同链上执行,从而达到百万TPS。</p>
|
||||
</li>
|
||||
<li><p>暴风播酷云,区块链应用。
|
||||
它是一台可以赚取BFC积分的家庭私人影院智能终端。在非工作状态下,用户通过闲置的存储空间和宽带帮助暴风系列软件、第三方CDN业务、第三方区块链业务进行超大文件网络加速甚至区块链网络全节点部署,不仅可以共享资源,还可以赚取BFC积分。</p>
|
||||
</li>
|
||||
|
||||
## 总结
|
||||
|
||||
今天我们主要了解了“区块链即服务”的概念,我们先从比特币出发,再从云出发,得到了“区块链即服务”的不同视角。接着我们浅析了“区块链即服务”应该做什么,并从架构集成的角度探讨了“区块链即服务”。最后我还列出了国内互联网公司在区块链即服务商的尝试。
|
||||
|
||||
好了,今天的问题是,如何设计一个稳定可控的区块链服务呢?你可以给我留言,我们一起讨论。感谢你的收听,我们下次再见。
|
||||
|
||||
|
||||
300
极客时间专栏/geek/深入浅出区块链/第四章 区块链与当下互联网/第31讲 | 数字货币钱包服务.md
Normal file
300
极客时间专栏/geek/深入浅出区块链/第四章 区块链与当下互联网/第31讲 | 数字货币钱包服务.md
Normal file
@@ -0,0 +1,300 @@
|
||||
<audio id="audio" title="第31讲 | 数字货币钱包服务" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/bb/20/bb2672945b84319fc5c0c05239e3a820.mp3"></audio>
|
||||
|
||||
上一篇,我们谈到了“区块链即服务”的概念。实际上,区块链第一个需要解决的服务就是数字货币支付服务。如何将数字货币钱包集成到系统中,我认为这是区块链行业最为迫切的问题。
|
||||
|
||||
今天我们就来了解一下数字货币钱包,它面临了什么样的问题,这样的问题又需要什么技术才能解决,而数字货币平台想要定制自己的数字货币钱包服务,又应当如何集成。
|
||||
|
||||
## 数字货币钱包的分类
|
||||
|
||||
目前市面上的数字货币钱包有很多种,看起来似乎有些眼花缭乱,不过,我们可以将它们进行分类后,再快速了解。
|
||||
|
||||
下图展示了按照不同属性区分的区块链钱包。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/02/e6/0220a3863fa1c5e3cd8b87cba6a5c5e6.jpg" alt="">
|
||||
|
||||
左一是按照用户端平台划分的钱包,这种钱包实际是在服务端运行的,用户端的钱包实际上只是一个代理,所以用户不需要关心钱包的细节,使用起来十分方便,典型的例子是各种在线钱包。
|
||||
|
||||
左二是按照货币类型分类的钱包,主要是指这款钱包到底是否支持多币种,这里的多币种可以是基于以太坊ERC20 Token的同一个区块链上的多币种,也可以是集成了比特币和以太坊等不同区块链的多币种。
|
||||
|
||||
右二是按照私钥存储的方式来区分的钱包,实际上这里主要涉及了用户私钥是否被平台托管,如果不托管直接存储在用户端,也就是硬件、终端设备、纸质记录,这些都可以被称为On-chain的钱包;如果用户无法接触到私钥,私钥被托管在平台,那么这种钱包也被称为Off-chain的钱包。
|
||||
|
||||
右一是按照访问方式进行分类的钱包,例如可以多个人共同管理,同时它也是需要多重签名支持的钱包,否则就变成了个人私有的钱包。
|
||||
|
||||
以上的分类并不是绝对的,一个钱包可以兼具以上不同的属性,例如某个Mobile钱包是提供On-chain的,也提供多重签名、提供多币种的钱包,这种钱包通常就是业界比较流行的钱包类型。
|
||||
|
||||
但是,对于平台方来说,上述钱包类型可能不足以支持自己平台的需求,并发挥出最佳的功效。毕竟作为平台来说,对高可用、分叉检测、区块确认的要求是远远高于普通钱包的,这样的问题又是如何解决的呢?这就引入了一项新的技术。
|
||||
|
||||
## 扫描区块技术 Block scan
|
||||
|
||||
我们之前在深入区块链技术部分介绍过,构成区块链的四个核心技术是:P2P网络协议、分布式一致性算法、加密签名算法、账户与交易模型。这四个技术对应到数字货币钱包中就是,P2P网络、持久化存储、账户以及私钥管理、共识与交易验证四大模块。
|
||||
|
||||
其中,持久化存储模块是由全节点钱包自带的嵌入式数据库提供的,这里有LevelDB、BerkerlyDB、SQLite3等多种选择。
|
||||
|
||||
但是无论选择哪种嵌入式数据库,都面临了一个严峻问题,精细化的交易查询验证与性能不可兼具。换句话来说,任何全节点的嵌入式数据库都无法和服务器级别的数据库相媲美。
|
||||
|
||||
对于平台开发来说,显然选择服务器级别的数据库是更为合适的选择。那么这里就涉及了一个问题,如何把全节点钱包中的数据转换成为数据库服务器中的数据,这就需要用到一种扫描区块技术,简称扫块。
|
||||
|
||||
扫块,顾名思义,就是指扫描全节点钱包中的所有区块,然后将其解析后存储到数据库服务器的过程,这些数据库可以是MongoDB,也可以是MySQL,取决于你的业务需要。
|
||||
|
||||
我们可以举元界区块链扫块的例子,元界上的区块结构与比特币接近,你可以将其类比成比特币区块链。
|
||||
|
||||
以下是Python代码,展示了基于MySQL的关系型表结构,目的是从元界的嵌入式数据库中扫描区块,然后存储到MySQL中。
|
||||
|
||||
```
|
||||
def init_table(conn):
|
||||
tables = []
|
||||
tb_block = '''
|
||||
create table if not EXISTS block (
|
||||
number bigint primary KEY ,
|
||||
hash char(64) not null,
|
||||
bits bigint,
|
||||
transaction_count INTEGER ,
|
||||
mixhash VARCHAR (128),
|
||||
version char(8) ,
|
||||
merkle_tree_hash char(64),
|
||||
previous_block_hash CHAR (64),
|
||||
nonce varchar(128) ,
|
||||
time_stamp bigint
|
||||
) DEFAULT charset=utf8;
|
||||
'''
|
||||
|
||||
tb_tx = '''
|
||||
create table if not EXISTS tx (
|
||||
id bigint PRIMARY KEY ,
|
||||
block_height bigint REFERENCES block(id),
|
||||
hash char(64) not null
|
||||
)DEFAULT charset=utf8 ;'''
|
||||
|
||||
tb_address = '''
|
||||
create table if not EXISTS address(
|
||||
id int PRIMARY KEY ,
|
||||
address VARCHAR (64) UNIQUE
|
||||
)DEFAULT charset=utf8;
|
||||
'''
|
||||
|
||||
tb_output = '''
|
||||
create table if not EXISTS tx_output(
|
||||
id bigint PRIMARY key,
|
||||
hash char(64) NOT NULL ,
|
||||
tx_id bigint REFERENCES tx(id),
|
||||
output_index bigint not null,
|
||||
output_value bigint,
|
||||
address_id bigint REFERENCES address(id),
|
||||
script varchar(1024),
|
||||
asset varchar(64),
|
||||
decimal_number varchar(8)
|
||||
)DEFAULT charset=ascii;
|
||||
'''
|
||||
|
||||
tb_output_fork = '''
|
||||
create table if not EXISTS tx_output_fork(
|
||||
id bigint PRIMARY key,
|
||||
hash char(64) NOT NULL ,
|
||||
tx_id bigint,
|
||||
output_index bigint not null,
|
||||
output_value bigint,
|
||||
address_id bigint,
|
||||
script varchar(1024),
|
||||
asset varchar(64),
|
||||
decimal_number varchar(8)
|
||||
)DEFAULT charset=ascii;
|
||||
'''
|
||||
tb_tx_fork = '''
|
||||
create table if not EXISTS tx_fork (
|
||||
id bigint PRIMARY KEY ,
|
||||
block_height bigint,
|
||||
hash char(64) not null
|
||||
)DEFAULT charset=ascii ;'''
|
||||
|
||||
tb_input_fork = '''
|
||||
create table if not EXISTS tx_input_fork(
|
||||
id bigint PRIMARY key,
|
||||
tx_id bigint,
|
||||
belong_tx_id bigint,
|
||||
tx_index bigint,
|
||||
tx_value bigint not null,
|
||||
script varchar(1024),
|
||||
address_id bigint,
|
||||
asset varchar(64),
|
||||
decimal_number varchar(8)
|
||||
)DEFAULT charset=ascii;
|
||||
'''
|
||||
|
||||
tb_block_fork = '''
|
||||
create table if not EXISTS block_fork (
|
||||
number bigint primary KEY ,
|
||||
hash char(64) not null,
|
||||
bits bigint,
|
||||
transaction_count INTEGER ,
|
||||
mixhash VARCHAR (128),
|
||||
version char(8) ,
|
||||
merkle_tree_hash char(64),
|
||||
previous_block_hash CHAR (64),
|
||||
nonce varchar(128) ,
|
||||
time_stamp bigint
|
||||
) DEFAULT charset=ascii;
|
||||
'''
|
||||
tb_output_asset = '''
|
||||
create table if not EXISTS tx_output_asset(
|
||||
id bigint PRIMARY key,
|
||||
hash char(64) NOT NULL ,
|
||||
tx_id bigint REFERENCES tx(id),
|
||||
output_index bigint not null,
|
||||
output_value bigint,
|
||||
address_id bigint REFERENCES address(id),
|
||||
asset_name varchar(64),
|
||||
issuer varchar(64),
|
||||
asset_type varchar(8),
|
||||
description varchar(64)
|
||||
)DEFAULT charset=utf8;
|
||||
'''
|
||||
|
||||
tb_input = '''
|
||||
create table if not EXISTS tx_input(
|
||||
id bigint PRIMARY key,
|
||||
tx_id bigint REFERENCES tx(id),
|
||||
belong_tx_id bigint REFERENCES tx(id),
|
||||
tx_index bigint REFERENCES tx_output(output_index),
|
||||
tx_value bigint not null,
|
||||
script varchar(1024),
|
||||
address_id bigint REFERENCES address(id),
|
||||
asset varchar(64),
|
||||
decimal_number varchar(8)
|
||||
)DEFAULT charset=ascii;
|
||||
'''
|
||||
|
||||
```
|
||||
|
||||
我们按照元界区块链的结构,可以把表分为四大类:
|
||||
|
||||
第一类是区块block;
|
||||
第二类是交易Tx;
|
||||
第三类是交易输入输出:tb_input,tb_output;
|
||||
第四类是分叉处理。
|
||||
|
||||
下面我贴一个普通的以JSON格式展示的区块和交易,你可以对比一下和上述表的关系:
|
||||
|
||||
下面是一个区块,里面包含了一笔交易。
|
||||
|
||||
```
|
||||
|
||||
{
|
||||
"header" :
|
||||
{
|
||||
"result" :
|
||||
{
|
||||
"bits" : "7097242144892",
|
||||
"hash" : "cb36f2a1cbbf6a6300f4bf4915a5f54476ab603f2703a99e5d8d2db7ae2b37ed",
|
||||
"merkle_tree_hash" : "3457b988bc6b61a7ad803f0742a68064c622ec618b833d99d153b92cba264d53",
|
||||
"mixhash" : "47266114351983928450891657703600980449927404535067001902399906817438963939929",
|
||||
"nonce" : "1864926684099479906",
|
||||
"number" : 1000000,
|
||||
"previous_block_hash" : "049257f31f4412bf115ed44a9305012ccea888cf842c2f0b66a528f258016e50",
|
||||
"time_stamp" : 1520339120,
|
||||
"transaction_count" : 1,
|
||||
"version" : 1
|
||||
}
|
||||
},
|
||||
"txs" :
|
||||
{
|
||||
"transactions" :
|
||||
[
|
||||
{
|
||||
"hash" : "3457b988bc6b61a7ad803f0742a68064c622ec618b833d99d153b92cba264d53",
|
||||
"inputs" :
|
||||
[
|
||||
{
|
||||
"previous_output" :
|
||||
{
|
||||
"hash" : "0000000000000000000000000000000000000000000000000000000000000000",
|
||||
"index" : 4294967295
|
||||
},
|
||||
"script" : "[ 0340420f ]",
|
||||
"sequence" : 0
|
||||
}
|
||||
],
|
||||
"lock_time" : "0",
|
||||
"outputs" :
|
||||
[
|
||||
{
|
||||
"address" : "MUiW2CViWLQBg2TQDsRt1Pcj7KyrdqFPj7",
|
||||
"attachment" :
|
||||
{
|
||||
"type" : "etp"
|
||||
},
|
||||
"index" : 0,
|
||||
"locked_height_range" : 0,
|
||||
"script" : "dup hash160 [ e45695c2c390625376a7225a7ebea90dbb4147cf ] equalverify checksig",
|
||||
"value" : 270750000
|
||||
}
|
||||
],
|
||||
"version" : "1"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
我们可以发现区块头部分的数据被存储到tb_block表中,然后交易哈希被存储的tb_tx表中,接着交易的输入输出被存储到tb_input和tb_output中,这三者是通过区块高度、交易哈希被链接起来的。
|
||||
|
||||
```
|
||||
tb_block <--区块高度--> tb_tx <--交易哈希--> tb_input/tb_output
|
||||
|
||||
```
|
||||
|
||||
完整的Python脚本可以通过这个链接查看:
|
||||
|
||||
[https://github.com/mvs-org/mvsd-mysql-sync/blob/master/tools/sync.py](https://github.com/mvs-org/mvsd-mysql-sync/blob/master/tools/sync.py)
|
||||
|
||||
整体的思路是使用getblock的JSON-RPC,从第0个高度的区块一直扫描到最新区块,并且存储到MySQL中。
|
||||
|
||||
这里最难以处理的问题是保持MySQL中的区块数据与全节点数据的一致性,也就是当区块链分叉时,MySQL需要感知到发生了分叉,接着移除被分叉的区块,并且接着同步到正确的区块上。
|
||||
|
||||
这个处理方法有不同的思路,上述脚本使用了移动区块数据的方法,也就是将孤儿块移动到tb_tx_fork下,接着同步正确的区块。实际上也可以通过标记法,即在tb_block中,将此块标记为孤儿块。
|
||||
|
||||
关系型的表结构也可以做成标准化的,区块链本身作为基础设施,历史交易已经不可篡改,如果把这些结构化的区块做成公共基础设施,并提供基于API的开放调用,这便就是我们常见的区块浏览器了。
|
||||
|
||||
上文我们介绍了扫描区块的思路和实践,实际上我们也可以使用Presto技术将钱包中的数据转换成类SQL查询,但这里服务的稳定性和性能需要经过测试才可以被平台使用。
|
||||
|
||||
扫描区块技术解决了所有区块链资产可视化、高并发查询的问题,所以它在一些大规模的数字货币交易所中也有应用。区块浏览器就是基于这种技术产生的一种Web服务,下面我们就来看一看区块浏览器与扫描区块的具体关系。
|
||||
|
||||
## 区块浏览器
|
||||
|
||||
我在前面介绍数字货币和交易所时有提到过区块浏览器,它提供了可视化的交易查询和验证服务。
|
||||
|
||||
从技术上看,一个区块浏览器的主要工作就是把区块扫描到数据库服务器中,然后搭建一个Web访问服务,用户只需要输入交易哈希或者区块哈希,即可查询到交易是否已经被打包和确认。
|
||||
|
||||
目前比特币和以太坊的流行区块浏览器比较多,不局限在某一个区块浏览器,因为大家看到的区块数据是一样的,区别就是如何更好地展示,做得更好的话,还可以集成一些咨询和资产托管的功能。
|
||||
|
||||
从产品意义上来说,我认为区块浏览器更适合叫做资产浏览器,因为它为人们提供了资产证明的服务,而不必肉眼识别交易或者自行手动解析交易,一般来说,区块浏览器也提供基本的API查询服务。
|
||||
|
||||
区块浏览器也为人们提供了区块和交易的统计数据,帮助人们直接地了解这个区块链的活跃程度,人们也可以根据统计数据制作区块活跃度等指数帮助投资者了解这个区块链项目。
|
||||
|
||||
区块浏览器降低了普通人查询和验证交易的门槛,其实它也是整个区块链行业的配套基础设施,而对于平台来说,从第三方获取交易验证始终是一件不安全的事情,也面临着中心化的风险,那么平台如果想搭建自己的交易查询和验证服务,需要如何操作?
|
||||
|
||||
这就需要把数字货币钱包服务,集成到自己的系统里。下面我们就来聊一聊具体是如何集成的。
|
||||
|
||||
## 数字货币钱包服务
|
||||
|
||||
实际上,大规模的区块链应用都需要搭建一个数字货币钱包服务,数字货币钱包服务为系统中的其他模块提供了可扩展的、统一的、安全的交易查询和验证服务。
|
||||
|
||||
下图是我从交易平台开发归纳出来的数字货币钱包服务。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/d4/4b/d478d2523f22e437d781a0d7b5b21e4b.png" alt="">
|
||||
|
||||
数字货币钱包服务可以为交易平台其他模块提供接口统一的API,同时将不同的数据结构化到数据库服务中,最后可以通过传统高可用手段完成交易查询和验证。
|
||||
|
||||
当然,这也和交易所的规模有关,如果是一个小型交易所,扫块可能不是必需的,但是统一接口的API却是必须的。
|
||||
|
||||
我认为数字货币钱包服务应当有一套标准的钱包服务框架,支持主流数字货币,从而降低大家的使用和部署门槛,这也和我们上一篇聊到的“区块链即服务”的概念不谋而合。
|
||||
|
||||
可以说区块链的配套设施和技术还很原始,还有很大的发展和提升的余地。
|
||||
|
||||
## 总结
|
||||
|
||||
好了,今天我们先了解了一下数字货币钱包的分类,接着详细讲解扫块技术,然后又谈到了区块浏览器,最后分享了一下数字货币钱包服务的集成思路,希望可以让你对区块服务的实践有一个初步了解,你也可以根据已有的技术知识重新拆解和分析区块链技术。
|
||||
|
||||
那么今天的问题是,数字货币钱包服务可以应用到微服务架构中吗?
|
||||
|
||||
|
||||
108
极客时间专栏/geek/深入浅出区块链/第四章 区块链与当下互联网/第32讲 | 区块链与供应链(一).md
Normal file
108
极客时间专栏/geek/深入浅出区块链/第四章 区块链与当下互联网/第32讲 | 区块链与供应链(一).md
Normal file
@@ -0,0 +1,108 @@
|
||||
<audio id="audio" title="第32讲 | 区块链与供应链(一)" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/92/9f/923c9e1f1c03c4bc6cbb3c308fcb549f.mp3"></audio>
|
||||
|
||||
前面的文章里,我们聊了很多与区块链数字资产、数字金融相关的内容,它们都属于基础设施。今天,我们来聊聊另外一个话题:区块链与供应链。
|
||||
|
||||
供应链是一个非常大的话题,几乎在任何的实业里都会有供应链的身影。对于企业来说,如何做好供应链管理,似乎是一个万年不变的难题。
|
||||
|
||||
而对于一个行业来说,如何站在行业全局的角度提供出供应链的最佳配置策略,也是一个万年不变的难题。
|
||||
|
||||
所以当供应链遇到区块链,区块链的一些优秀特性刚好可以解决目前供应链领域的痛点。
|
||||
|
||||
## 什么是供应链
|
||||
|
||||
在聊区块链和供应链之前,我先简单地向你介绍一下什么是供应链。供应链虽然也带了一个“链”字,它其实是一个网链状的结构。
|
||||
|
||||
下图展示了笔记本电脑供应链的各个环节。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/0a/e2/0afaa9dbe589379ccb42cf946669a7e2.png" alt="">
|
||||
|
||||
(图片来自维基百科)
|
||||
|
||||
图片中展示笔记本电脑的生产制造过程,左侧表示了制造一个笔记本电脑的原料供给侧,Laptop的右侧表示为需求侧,包含了批发商(wholesaler)、经销商(retailer)等多个角色,它们都是围绕了笔记本电脑而形成的供应链。
|
||||
|
||||
通过上面的图,我们来归纳一下到底什么是供应链?供应链围绕核心企业与产品构建,是一个从供应商开始、途径制造商、运输商、分销商最终到消费者的网链状结构。
|
||||
|
||||
我们可以发现供应链是一个网链状的复杂结构,每个角色又与其他角色互相交叉,于是可见它的管理也是非常复杂的。
|
||||
|
||||
## 供应链领域
|
||||
|
||||
供应链领域又分供应链管理和供应链金融,我们先从供应链管理开始。
|
||||
|
||||
### 1.供应链管理
|
||||
|
||||
供应链管理就是指对整个供应链系统进行计划、协调、操作、控制和优化的各种活动和过程,其目标是使这一过程所耗费的总成本最小。需要注意的是:这里的总成本是指整个供应链参与的企业总成本最小,不是指单个环节的成本最小。
|
||||
|
||||
我们已经知道了,供应链涉及了供应商、制造商、渠道商等角色。那么连接这些角色的,主要是采购(Purchasing)、库存(Inventory)、物流(Logistics)等一系列事务。采购、库存和物流主要围绕仓储、配送中心、物流运输展开,所以我们也可以把供应链看作是由供应商、制造商、渠道商、仓库、配送中心、物流运输等构成的网络。
|
||||
|
||||
在这个网络之中,各个角色之间最大的问题就是信任问题,因为只有建立信任才能协作完成一个完整的产品制造和销售过程。供应链管理面对的首要问题就是如何降低信任成本,将原本松散的企业形成互信的链式结构,每个角色必须通过有效的链上管理来协调自身和外部的资源,从而满足市场需求。
|
||||
|
||||
在这个链式结构中,有信息流、物流、资金流三种流动过程。
|
||||
|
||||
1. 信息流:是指每个角色需要了解并追踪产品在供应链中的当前位置和状态;
|
||||
1. 物流:是指产品或原材料被转移到目标角色手中的过程;
|
||||
1. 资金流:是指上下游资金结算的过程。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/67/4d/67683f40d4f32203038e3c1a9625704d.png" alt="">
|
||||
|
||||
上述图片展示了在供应链管理过程中,物流指向需求侧,资金流指向供应侧,信息流则需要在各个角色之间共享。
|
||||
|
||||
而目前供应链的现状是,资金流、信息流、物流各自独立运行,资金流靠银行,信息流靠供应链管理工具,物流靠运输行业,它们都是围绕一个或多个核心企业展开的,所以各个角色极度依赖核心企业,这种模式暴露了以下几个问题:
|
||||
|
||||
1. 核心企业对上下游的延伸和掌控范围有限;
|
||||
1. 上下游可能因为竞争关系,存在信息流作假和被篡改的风险。
|
||||
1. 市场供需变化无法及时传导到供给侧,从市场需求到供给侧的风险依次放大。
|
||||
|
||||
这些问题一方面会增加核心企业的供应链管理的复杂度,另一方面是非核心企业参与感不强导致的风险忽视。虽然市场上也出现了一系列工具来帮助提升供应链上下游协同能力,但是还是存在了一些问题。
|
||||
|
||||
1. 在整个供应链过程中,存在多个不同的参与方。由于不同参与者可能使用不同的数据库甚至是纸质文档,因此,数据的跨系统整合较难。
|
||||
1. 传统数据库体系中的数据本身存在被篡改、被攻击的风险。在准确性和安全性上还存在较大的提升空间。
|
||||
1. 由于产品的追踪难度大,一旦某个环节出现问题,监管机构对于不合规的活动在调查、取证及问责上存在一定的难度。
|
||||
|
||||
换句话说,只要中心化的思路不变,只是形式变换了,传统技术仍然难以有效地解决问题。但是区块链的信息透明共享、节点之间对等、不可篡改等各种特性,几乎就是针对供应链的对症下药,所以区块链也被誉为供应链管理的终极武器。
|
||||
|
||||
### 2.供应链金融
|
||||
|
||||
供应链金融和供应链是两个概念,因为多了金融两个字,于是严格来说,供应链金融属于金融的范畴,它是专门为供应链服务的金融。
|
||||
|
||||
供应链金融(supply chain finance, SCF)可以泛指各种融资工具,它可用于为供应链中的各方提供资金,通过短期信贷手段来平衡上下游之间的流动资金差,从而最大限度地减少总供应链成本,企业也可以利用供应链融资与供应商建立更牢固的关系,降低金融风险和提高流动性。
|
||||
|
||||
与其他金融一样,供应链金融的核心也是风险管理,良好的风险管理前提是供应链信息真实可靠的透明共享。传统供应链金融围绕银行展开,银行在供应链信息上的收集也受制于传统技术,并不能完全掌握企业之间的真实订单情况,那么风险控制则十分依赖对企业的信誉判断了。
|
||||
|
||||
所以,如果所有的参与方都可以真实准确地查阅整个供应链的流程和状态,那么风险管理就变成了整个供应链参与方共同分担,而不仅仅只是核心企业和银行。
|
||||
|
||||
## 区块链为供应链带来的新曙光
|
||||
|
||||
区块链为供应链主要带来了思维上的变革,不再是以围绕核心企业打造的生态,而是共治的生态,区块链作为基础设施可以为参与方提供良好的可信环境,从而降低供应链的成本。
|
||||
|
||||
通过上文我们知道,供应链有三流:物流、信息流、资金流。理想的情况其实是“三流合一”,也就是由区块链本身提供信息流、资金流、物流三流管理。
|
||||
|
||||
这里如何理解呢?
|
||||
|
||||
- 区块链本身也可以提供信息登记,例如订单状态可以被格式化成区块链的交易附加内容。
|
||||
- 区块链应用到资金流,这个想必你也应该猜到了数字资产,其实物品被登记后也属于一种有价凭证,对有价凭证的验证和交付可以看成数字资产的另外一种形式。
|
||||
- 区块链应用到物流,这里或许要结合IoT技术一起完成,因为区块链作为分布式系统,无法直接感知物流状态,例如运输途中食品的温度,这个是需要依赖传感器的,传感器获得的数据可以上传到区块链,也可以通过哈希处理后登记到区块链。
|
||||
|
||||
实际上,现阶段在供应链商达到“三流合一”是十分困难的,但我认为这是一种趋势,这取决于区块链的发展速度。
|
||||
|
||||
所以区块链在供应链中的切入点往往是从物流切入的,因为物流是连接各方最直观的表现,也是关系最紧密的。从物流切入可以避免与现有供应链工具的直接竞争,例如既存的供应链管理工具已经提供了信息流管理,银行提供了资金流管理,所以从物流入手项目落地的可能性最大。
|
||||
|
||||
在物流上,区块链可以保证数据登记真实可信,信息对所有参与方公开透明,并且提供产品溯源功能,这似乎就已经发挥了很大的功用,解决了一些难题。
|
||||
|
||||
说到这里你可能觉得奇怪,国内“四通一达”效率之高几乎吊打全世界,为什么还说物流有很多问题呢?其实国内的环境比较特殊,“四通一达”的创始人之间有比较好的信任基础,而且国内电商的和互联网技术的崛起,也为国内物流环境创造了良好的土壤。
|
||||
|
||||
所以这里主要针对的是跨境物流环境,跨境物流面临的痛点还涉及了海关、跨境汇率、目的地国家政策等多方面的影响,相互之间的信任程度更低,所以解决跨境物流是区块链在供应链上的一个突破点。
|
||||
|
||||
区块链应用到供应链上也有很多著名案例,比如业界经常提到的几个案例:
|
||||
|
||||
1. 马士基(Maersk)和IBM的海运保险区块链平台案例;
|
||||
1. 沃尔玛利用区块链进行食品追踪溯源案例;
|
||||
1. 众安的区块链养鸡场实时记录和追溯整个鸡的成长过程案例;
|
||||
1. 海航科技基于区块链技术的物流端到端的虚实融合信息流平台。
|
||||
|
||||
实际上,通过仔细分析我们可以发现,以上机构使用的是DLT技术,也就是联盟链,并非公链。下一篇我们通过技术视角来详细剖析一下这个现象。
|
||||
|
||||
## 总结
|
||||
|
||||
好了,今天我主要介绍了什么是供应链,供应链的现状以及面临的难题,最好又聊到了区块链又可以为供应链带来什么,应该从哪里切入。今天的问题是,你觉得供应链还有什么难题是区块链可以解决的呢?你可以给我留言,我们一起讨论。
|
||||
|
||||
|
||||
136
极客时间专栏/geek/深入浅出区块链/第四章 区块链与当下互联网/第33讲 | 区块链与供应链(二).md
Normal file
136
极客时间专栏/geek/深入浅出区块链/第四章 区块链与当下互联网/第33讲 | 区块链与供应链(二).md
Normal file
@@ -0,0 +1,136 @@
|
||||
<audio id="audio" title="第33讲 | 区块链与供应链(二)" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/8d/f1/8d2d62ba98118090c5878d12075da3f1.mp3"></audio>
|
||||
|
||||
上一篇我们一起学习了供应链的相关知识,并探讨了区块链是否可以为供应链带来新的机遇。今天,我们就从一个具体的案例出发,看看区块链到底是如何帮助供应链的。
|
||||
|
||||
由于区块链应用到供应链上的典型案例并不多,所以本文主要是以一种探讨的角度和你分享,希望给你提供一些思路。
|
||||
|
||||
## 跨境物流问题
|
||||
|
||||
上一篇我们剖析了区块链切入供应链的点是跨境物流。我们先来看看跨境物流会涉及哪些环节。
|
||||
|
||||
跨境物流一般包含了托运方、仓储、港口、海关、航运公司几个角色。
|
||||
|
||||
航运公司提供实际的运输服务,从航运公司的角度来说,一个集装箱要尽可能地装满才能获取最大收益;然而实际的货物托运需求,可能并不能装满一个集装箱。
|
||||
|
||||
那么,围绕货物与集装箱资源配置的货运中介就出现了,货运中介提供集装箱与货物的调度、拼凑、与上述参与方沟通协调的服务。
|
||||
|
||||
在实际的操作过程中,航运公司一般不与托运方直接对接,而是和货运中介对接,托运方与货运中介对接。
|
||||
|
||||
```
|
||||
托运方 <--> 货运中介 <--> 航运公司
|
||||
|
||||
```
|
||||
|
||||
这里隐含了三个问题:
|
||||
|
||||
1. 航运可能出现短时间大量的物流调度,同时也产生庞大的信息流,但货运中介处理能力有限,不能及时处理,这就属于订单匹配问题;
|
||||
1. 托运货物如果是贵重物品,托运方往往要求中介现金抵押,所以中介也要求航运公司抵押,这属于供应链金融问题;
|
||||
1. 三方议价会造成议价成本过高,这属于供应链流程问题。
|
||||
|
||||
在实际航运过程中,还会出现“丢包”的情况。换句话说就是集装箱丢了,如果你看过了《一切尽失》这部电影,就知道主角的船是被随波漂流的集装箱撞毁的。所以,即使是集装箱的供应商,也未必有能力跟踪集装箱的去向,一旦集装箱交付给下游,剩下的就只有听天由命了。
|
||||
|
||||
这中间其实还是会有一些信任问题,集装箱交付给下游后,如果有一种技术可以让参与方们都承认交付过程是真实无误的,那么在丢包时可以追踪到是谁在哪个环节出了问题,而不至于在追责参与方时,出现“踢皮球”的情况。
|
||||
|
||||
上述案例,我们可以从联盟链方案和公链方案两个角度进行剖析。下面我们先来看看联盟链方案。也就是基于分布式账本技术DLT的解决方案。
|
||||
|
||||
## 基于分布式账本技术DLT的解决方案
|
||||
|
||||
分布式账本技术,英文全称是Distributed Ledger Technology,缩写为DLT。DLT技术是联盟链的首选技术,在DLT技术中,关注点不是Token,而是核心业务可编程逻辑,所以DLT技术可以看成是区块链技术的一个变种。
|
||||
|
||||
基于DLT技术的供应链解决方案的思路,还是围绕核心企业展开,也就是前期的方案制定和执行依然是核心企业牵头,上下游企业需要成为平台的会员才可以享受服务。联盟链可以为这些平台上的会员提供一定的信任保障。
|
||||
|
||||
在上述航运的案例中,DLT可以围绕航运公司的订单展开,参与方都可以成为DLT的会员节点。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/a2/5a/a2be3368000d6575768b697f000afb5a.png" alt="">
|
||||
|
||||
在DLT技术中,关注点是如何连接核心企业。DLT技术很可能首先运用到航运、货运中介和银行之间。
|
||||
|
||||
方案1:自建DLT物流追踪平台
|
||||
|
||||
自建一个物流追踪平台,核心参与方可以选择部署节点,或成为记账节点。如果DLT使用的是PBFT或PoET算法,则要求参与方节点不能联合作弊,也就是核心参与方之间必须有基础信任,否则任意参与方就算有意发起攻击,也会造成不可估量的损失。
|
||||
|
||||
方案2:选择第三方DLT技术平台
|
||||
|
||||
另外一种情况是选择第三方DLT平台,而不是自建,这方便让中小企业加入,但这里的风险也是显而易见的,由于记账节点都是第三方DLT平台,所以参与方首先要信任DLT平台。
|
||||
|
||||
从技术角度来看,一般DLT平台也搭建在云端,例如Azure、IBM Bluemix等,这也是为什么这些机构不遗余力地销售“区块链即服务”的概念,对所有参与方而言,记账节点是否需要自己参与运行取决于业务敏感度。
|
||||
|
||||
以上两个方案中,不可篡改性是由DLT技术的共识算法保证的,这里还是会退化成对记账节点的信任问题,所以DLT技术的实践形式往往是“某某区块链供应链平台”,这里的信任问题转化为对平台的信任。
|
||||
|
||||
除了上述结构,托运方和货运中介之间也可以直接搭建DLT技术平台,略过货运中介,这个取决于托运方的规模,如果托运方是一个大中型企业,那么也直接参与,形成如下结构。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/2f/d0/2f390410bd421f0b7fb036f8d26d78d0.png" alt="">
|
||||
|
||||
探讨到这里,我们也可以发现DLT技术的局限性。
|
||||
|
||||
1. 仍然围绕核心企业展开,通常只解决了单个问题,也会面临传统技术相同的问题;
|
||||
1. DLT价值孤岛,由于DLT平台太多,会造成数据孤岛,DLT平台之间并没有打通,面临着天花板。
|
||||
|
||||
但是DLT技术有如下优势:
|
||||
|
||||
1. 能解决实际问题,可以快速落地;
|
||||
1. 有行业巨头的大力支持,可以和现有供应链管理工具栈无缝对接。
|
||||
|
||||
## 基于公链的解决方案
|
||||
|
||||
基于公链的供应链解决方案目前极少,本文我主要是提出一种思路和你一起探讨。
|
||||
|
||||
用公链解决供应链难题,也是从协作信任的角度出发。在上述案例中,问题主要集中在订单匹配和货物追踪上。
|
||||
|
||||
### 1.订单匹配
|
||||
|
||||
订单匹配其实不是区块链的长项,即使有智能合约技术,但受制于TPS,低效的计算使得海量匹配不可行,那么我们换个思路。
|
||||
|
||||
订单匹配本质上也是一种撮合计算,如果我们把所有的货物看成一种资产,那么以资产的体积、重量、存储要求作为条件进行最优匹配,生成最优货运策略。这个过程其实与数字货币交易所的职能十分相像。
|
||||
|
||||
所以我们可以把订单匹配这一步暂时放到链下,只在链上记录最优货运策略,所有人可以根据当前订单的状态验证是否为最优货运策略,如果满足预期则执行最优货运策略。
|
||||
|
||||
换句话说,托运方事先在链上生成订单,订单被全网的航运公司看到以后,通过自己的链下订单匹配生成最优订单策略,接着向托运方发起承运请求,托运方验证是否满足自己的期望,是的话则接受承运请求,那么这笔订单成交。
|
||||
|
||||
在成交的同时,托运方要求航运公司进行资产抵押,这里的抵押则不必是现金了,可以是物流行业的通用Token,这里的Token具有可编程属性,双方可在协商一致的情况,指定抵押的解锁条件。
|
||||
|
||||
### 2.货物追踪
|
||||
|
||||
完成订单匹配和抵押以后,进入实际承运阶段,这时候对货物的追踪则显得至关重要。传统的技术是通过中心化数据库来记录货物的位置和状态,在终端使用 IoT 传感器技术,将货物状态和位置数据上传至数据库。
|
||||
|
||||
这里的策略很简单,我们不变更终端部分,仅仅把中心化数据库的职责替换由公链来执行。
|
||||
|
||||
这里也并不是百分百的替换,而是把关键数据记录在公链上,非关键数据依然留在中心化数据库或者类DAG技术区块链账本中,主要考虑到公链是一种珍贵的共享资源,海量数据上链会形成对公链的DDoS攻击。例如货物的实时温度变化,区块链无法承载如此海量的数据,也算是在公链上的折衷方案。
|
||||
|
||||
这里也会涉及数字资产的概念,如果给货物一个唯一的编号,那么这个编号可以被区块链记录而形成唯一性的数字资产,类似ERC721 Token标准。
|
||||
|
||||
### 3. 可能的结构
|
||||
|
||||
图中是一套以元界为基础的公链方案。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/4b/24/4b77dd318de1563048daead6d7460e24.png" alt="">
|
||||
|
||||
在Back-end部分,元界区块链承担了货物追踪和订单撮合的职能,而所有参与方可以通过搭建属于自己的元界区块链节点服务,获得链上的订单信息。
|
||||
|
||||
在Front-end部分,工作人员可以通过移动设备获得订单数据,工作人员也可以像以前一样,通过IoT蓝牙传感器获得货物的数据,接着通过移动设备上传至服务器,由服务器挑选并计算后登记到元界区块链上。
|
||||
|
||||
## 两者的比较
|
||||
|
||||
公链方案与DLT技术相比,具备以下优势。
|
||||
|
||||
1. 透明度高:对于可公开的信息,零售环节的普通购买者也能够通过区块浏览器查询到产品来源。
|
||||
1. 不可篡改性:由于公链的共识算法的不可篡改性比DTL技术更强,且参与的节点更多,所以数据的真实和可靠性更好。
|
||||
1. Token转移:由于区块链本身支持Token登记,所以物流提单可以做成Token,变成有价证券进行转移。
|
||||
1. 参与性强:任何客户、政府或是监管机构都可以参与到供应链流程整个或某个特定环节,并跟踪与浏览者相关的某些公开或非公开信息。
|
||||
1. 共享公链的基础设施,例如参与方不需要再搭建可视化Web服务,直接使用区块浏览器即可,货物Token也可以参与到交易平台进行二级交易。
|
||||
|
||||
DLT技术与公链方案相比,具备以下优势。
|
||||
|
||||
1. 可控性高:DLT技术一般严格控制参与方,核心企业的权益可以得到保障。
|
||||
1. 可快速落地:方案和思路延续传统技术,实施起来方便,对参与方的认知门槛要求低。
|
||||
1. 匿名性较好:一般公链并没有提供清晰的权限管理和匿名技术,所以企业的数据必须脱敏才可以明文上链,而DLT技术不存在这个问题。
|
||||
|
||||
## 总结
|
||||
|
||||
好了,今天我和你一起探讨了区块链技术在供应链上的两种实践方案,第一种是DLT技术,第二种是围绕公链展开的方案,这两种方案各有优劣。
|
||||
|
||||
所以今天的问题是,你认为哪种方案会是未来的主流呢?你可以给我留言,我们一起讨论。感谢你的收听,我们下次再见。
|
||||
|
||||
[https://github.com/hyperledger/sawtooth-supply-chain](https://github.com/hyperledger/sawtooth-supply-chain)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user