联盟链战国:五大巨头横向对比
2018-10-23
猎云网注:从技术选型角度来讲,应用者,尤其是新入局的应用者,最好还是在Hyperledger Fabric这种影响广泛的成熟框架或者FISCO BCOS这种有实力且能提供较强本土支持的平台上做选择,而在开发过程中借鉴下Coco、Quorum、Corda中的优秀设计理念。文章来源:区块链前哨(ID:blockchain-666),作者:付晓岩:原中国建设银行资深业务架构师,负责业务架构设计、项目管理,热衷新技术探索与实践,具有丰富的银行业务经验和企业级项目业务架构设计经验。
联盟链是目前区块链落地实践的热点,也是大家对“杀手级应用”期望最大的区块链部署形态。联盟链的诞生源于对区块链技术的“反思”,是对比特币、以太坊所体现的技术特点与企业客户实际需要的融合与折衷,蕴含了大量区块链工作者的智慧与辛劳。
由于对未来价值的“共识”,很多厂商推出了自己的联盟链框架或平台,本文选择了Hyperledger Fabric、FISCO BCOS、微软的Coco、企业以太坊联盟(EEA)及R3的Corda这五个具有一定影响力的联盟链,拟从设计理念、生态、效率、扩展性、节点管理与权限管理、智能合约、部署与运维友好性、隐私保护八个方面进行比对,以供各位开发者、爱好者参考。
其中,EEA由于只出具规范而不涉及代码,所以比对中采用了其官方承认的技术基础——摩根大通的Quorum平台;Corda并不是区块链,严格说与其他四者的比较属于分布式账本技术这个层级的比较,但是由于其承认设计上是受到区块链技术启发,且对其他联盟链也产生了一定的影响,因此,也列入了比较范围。本文的信息主要来源于公开的技术白皮书、Github中的开源信息,就不在文中一一注明了。
一、设计理念
设计理念其实决定了一个框架或者系统的最佳应用方式,是其设计的出发点,因此,研究每种区块链时,都应当认真关注其如何“看待自己”,以免在应用上出现“硬套”的问题。设计理念上本文分成核心思路与市场定位两部分进行比较。
(一)核心思路
核心思路体现的是其设计初衷,这个“初心”对其后续技术走向有一定的影响。
Hyperledger Fabric是希望改变公链的单一通用网络模式,通过建立多个可以互联的区块链网络覆盖各类不同的业务场景,实现设计的灵活性,满足多样化的要求,并实现网络间的交互,这种思路体现在了其独特的通道机制设计上。
FISCO BCOS初衷是设计一个国内企业主导研发、自主可控、对外开源的满足金融行业需求企业级区块链底层平台,并逐渐扩展至其他领域、适用于广泛的分布式商业场景,所以进行了自底向上的完整设计,并考虑了较多国内的特殊需求。
Coco基于保密联盟环境的假定,重新评估了公链的设计,通过将其他区块链协议集成为底层,快速高效地构建区块链应用。在这种思路下Coco大胆放松了一些关键的设计限制,并且最终实现了一个对现有区块链协议的加速机制,可集成的协议已经包括Hyperledger Fabric、以太坊、Corda、Quorum等。
EEA是力求引导一种基于以太坊的标准区块链设计,可根据成员需要定制,但不提供代码(Quorum提供部分开源代码)。官方承认其技术基础是摩根大通开发的Quorum平台,该平台的目标则是提供高速、高吞吐量交易的能力,以解决区块链技术在金融等领域遭遇的挑战。
(二)市场定位
市场定位反映了对自身应用方向的价值主张。五个联盟链都是面向企业级应用的,但是具体的定位略有差异:
Hyperledger Fabric旨在打造不分行业的通用区块链开源框架;
FISCO BCOS源自企业级区块链平台BCOS,做为一个金融版本分支,保留通用性的同时,更关注于金融行业,并且较多考虑了监管机构的特殊性;
Coco希望提供更高效易用的区块链技术,没有特殊的行业定位;
EEA比较有趣,它以将所有企业导向一个统一的路线图(该路线图以以太坊技术发展为基础)为目标,但是由于目前的技术代表是摩根大通的Quorum,所以,应用实例上对金融行业更有指导性;
Corda则是针对金融行业的,并且明确提出至少一定时间内不会考虑其他行业。
二、生态
大家常说建联盟链就是建生态,所以本文就比较下要帮着别人建生态的联盟链,其自身的生态建的如何。生态考察主要包括管理方、社区和商业应用这三个方面。
(一)管理方
从管理方看,各家都是“实力派”。
Hyperledger Fabric的管理方是Linux基金会,基金会管理下的Hyperledger其实是一个项目系列,包括Cello、Swatooth、Burrow、Iroha等;
FISCO BCOS管理方是金链盟,金链盟是由深圳市金融科技协会、深圳前海微众银行、深证通、腾讯、华为、中科院等金融机构、科技企业、学术机构等组成的非营利性组织;(参考https://www.fisco.com.cn/views/member.html)
Coco的管理方是微软;
EEA是由芝加哥交易所、因特尔、ING、摩根大通和微软等三十几家创始成员组成的;
Corda的管理方R3是以银行为主的组织,至少已经吸收了42家金融巨头,包括富国银行、美国银行、花旗银行、德意志银行、加拿大皇家银行等,我国的平安、招行等也是其成员,不过R3麻烦不断,也有些重量级成员已经退出。
(二)社区
现今科技发展比较流行开源,五大联盟链也都是开源的,开源意味着要搞好社区建设,通过社区推广和改进设计,凝聚更多智慧。
Hyperledger Fabric已经打造了国际化的社区,除了在GitHub上比较活跃外,大量的线下Meetup、技术推广活动也比较多,加上IBM的有力推动,使其有了大量的活跃用户;
FISCO BCOS社区建设初现规模,已有了千级成员、百级机构参与,除了GitHub外,还有官方微信群。FISCO BCOS在不断迭代源码和文档的基础上,陆续推出了线上线下多种形式的系列运营活动,包括技术培训、高校开课、线上线下讲座沙龙、包括近期举办的金链盟中国区块链大赛,影响力逐渐扩散。作为国内开源项目,相信未来发展上会有一定的“天时地利人和”;
Coco社区不是很活跃;
Quorum在GitHub上已经有了551个话题,有一定活跃度;
Corda也不是很活跃。
(三)商业应用
商业应用是大家打造区块链平台的目的,也是一个联盟链最重要的人气所在。
Hyperledger Fabric得益于IBM的大力推广,加上技术框架比较成熟、推出较早,目前已有较多商业应用,据IBM披露有400多个落地项目,其中不乏马士基、沃尔玛、联想、邮储银行这类大型客户,也有统计称,所有联盟链项目中Hyperledger Fabric已占据半壁江山;
FISCO BCOS从金融出发,携本土优势,落地项目也有数十个,包括微众银行的机构间对账平台、网易的竞猜游戏,四方精创的供应链金融、城商行旅游金融联盟的旅游金融、仲裁链、安妮股份的版权存证平台、乐寻坊的人才活动平台、链动时代的不动产登记系统等;
Coco目前在项目方面乏善可陈,除了其白皮书中提到的Mojix将其供应链Dapp转移到Coco平台上之外,没有更多公开的项目信息;
Corda也是同样的境地,雷大雨小,耗费巨资,但是测试的多,落地的少。
从生态角度看,Hyperledger Fabric启动的比较早,目前领先一步,但是 FISCO BCOS 奋起直追,已经初见规模,Coco、Quorum、Corda 还需要做很大努力。
三、效率
区块链目前最差强人意的指标莫过于效率,虽然现在也有些人开始反思也许不应当苛求区块链的效率,但是商业应用总是回避不了这个问题。效率方面,本文从共识协议、出块速度、TPS和存储消耗这四点加以比对。
(一)共识协议
联盟链为了提升交易速度,往往是先从共识协议“下手”。POW和POS都无法满足商业应用的需要,“挖矿”对联盟链来讲也是没必要的,因此,各家都采用了替代的共识方案。
Hyperledger Fabric在0.6版中应用了PBFT,而在1.0版中放弃了PBFT,转而采用效率更高的Kafka,支持单点和集群两种方式,由Kafka直接给交易排序和出块;
FISCO BCOS支持并行计算的PBFT和标准RAFT两种方式,前者是将通常的PBFT中议长节点和投票节点分步验证的方式优化为并发验证,从而进一步提高共识效率;
Quorum支持Raft和Istanbul BFT两种协议。后者是由来自台湾的AMIS帐联网公司在2017年研发的,可以大幅提升现有的以太坊架构的讯息交换效率;
Corda比较特殊,它借鉴“矿工”角色设计了公证人模块来提供交易公证(也即签名)服务,整个网络不依赖于任何特定的共识算法。但公证人是一个集群概念,一般使用BFT或Raft在公证人间达成一致,因此,公证人是存在效率问题,可能成为效率瓶颈。
与传统分布式系统的共识设计相比,Hyperledger Fabric并没有什么改进,其共识方式与中心化共识的分布式数据库一致;FISCO BCOS支持PBFT共识算法,具备拜占庭容错功能,也提供RAFT共识算法,适用于在节点可信度比较乐观的场景;Coco是通过TEEs提高节点可信性,以降低共识协议的复杂度;Quorum也没做多少调整,尤其是在引入Istanbul BFT之前;Corda应该说是在传统设计中引入了“矿工”理念。
(二)出块速度
由于替换了共识机制,因此相比使用POW的比特币、以太坊,联盟链出块速度要提高很多。Hyperledger Fabric、FISCO BCOS、Coco都是秒级出块;Quorum则称是毫秒级,默认设定是50毫秒,可以调整;Corda没有块,所以也没有出块速度可以考量。
(三)TPS
TPS相当于区块链世界中的“网红”,很多新出现的链都把TPS贴在“脑门”上。这五大联盟链虽然TPS远高于比特币、以太坊,但还是比现有的分布式系统逊色:
Hyperledger Fabric通常实测的TPS在300-500之间;
FISCO BCOS 实测单链可以达到 1000 以上。并且支持多链架构下的并行计算,可灵活扩展,理论上无上限。
Coco官方数据是1600;
Quorum在Istanbul BFT协议下可以达到400-800,Raft下缺少数据;
Corda由于其网络结构的原因,没有全局吞吐量可以衡量。
其实TPS方面如果没有达到一个数量级以上的差异,是不用特殊关注的,因为在实际应用中,节点数量、网络环境、硬件配置、软件设计等都会对TPS产生影响,而现有的联盟链在吞吐量上已经可以满足相当一部分商业场景的要求,毕竟Visa在2016年每秒实际处理的交易也只有1,667笔,尽管Visanet据称有每秒处理56,000笔交易的能力。
(四)存储消耗
区块链可以说是以“浪费”存储来换取信任的技术。虽然存储设备的价格越来越低廉,但这不代表“浪费”就没毛病,存储的快速膨胀一定会带来效率、成本、可用性等诸多问题,甚至会要求改变设计架构,尤其是在大家都想追求“杀手级应用”的时候。
Hyperledger Fabric方面,蚂蚁金服倒是给出了一个详细的计算公式,Fabric数据容量估算(GB) = 每种业务每天平均交易笔数 * (Fabric每笔交易基本开销 + 每笔交易平均业务数据大小 KB * 2 ) * 业务Channel数量 * (365 * 年数 *(Peer节点数量 * 2~1之间 + Orderer 节点数量)+ Kafka Retention天数 * Kafka Replica数量) / (1024* 1024),其计算示例中,在业务笔数每天10万、4节点、2通道、单笔交易容量1K的情况(其他因素不详细列出了)下,年存储消耗4619G;
FISCO BCOS支持历史数据快速追踪,对接数据库,实现分布式存储,能够支持海量服务的存储需求,提高存储访问速率,节省存储消耗。
Coco由于设计上需要集成区块链协议做底层,因此其消耗就取决于集成的区块链协议,比如集成了Hyperledger Fabric,那加上Coco自身的消耗,其存储消耗量至少应该是比肩Fabric的;
Quorum也没有针对存储的特殊优化,至少应当按照大于以太坊消耗来估算;
Corda倒是不同于其他联盟链,因为它基本上就是传统的分布式数据库,而且没有任何节点保存全局数据,每个节点都只保存跟自己有关的数据,所以,其存储消耗应该与传统分布式系统设计类似,没有过多的冗余消耗。
综上,从效率方面看,在Hyperledger Fabric之后推出或开源的其他联盟链,效率高于它也属正常。FISCO BCOS、Quorum本就是面向金融的设计,所以效率要求自然要高于一开始就希望做通用框架Hyperledger Fabric;Coco设计理念上就是希望做成“加速器”的,它的效率理应高于任何它可以集成的区块链;而Corda的设计模式决定了很难全面评价其效率,只能去单独观察每个实例。
四、扩展性
联盟链的用户都希望自己能发展成生态圈,比如海尔的供应链、中化的原油进出口贸易平台、马士基的全球交易平台等,因此,扩展性是联盟链设计必须要考虑的问题。这方面本文关注了节点数量扩展、共识扩展、单多链模式、加密算法扩展、第三方认证证书支持这五点。
(一)节点数量扩展
Hyperledger Fabric在节点数量扩展方面是弱项,已落地项目多是个位数节点,但是可以支持较多的客户端,算是一种弥补,不过节点数少其实意味着参与方的独立性是会有所下降的;
FISCO BCOS的分组模式支持根据节点数量进行水平扩容,因此理论上节点数量是不受限制的;
Coco在这方面有些“投机取巧”,可支持的节点数量取决于其集成的区块链协议,如果集成的是公链协议,在理论上也不受限制;
Quorum是基于以太坊的,因此理论上也没有限制;
Corda同样也没有节点数限制。
虽然除了Hyperledger Fabric,其他联盟链似乎都没有节点数量问题,但是节点数量其实还受共识协议的影响,BFT类共识协议在节点数量超过一定水平时会出现吞吐量下降,设计时应当考虑这点。
(二)共识协议扩展
共识协议的扩展能力对联盟链的稳定性有很大影响,能否根据节点数量、网络平衡情况、吞吐量进行调整决定了其网络的扩展能力。
Hyperledger Fabric虽然很早在设计上就称其共识模块可插拔,但是目前实际应用上看是不具备插拔能力的,每个版本仅支持一种共识模式;
FISCO BCOS支持共识协议的插件式实现,允许切换共识机制;
Coco、Quorum目前也具备了这种能力;
Corda实现的应该说不是共识协议的直接插拔,而是公证人模块的可插拔,可以通过切换公证人模块来选择公证人的共识模式。
(三)单多链模式
多链模式目前被很多新出现的链用于性能扩展,不过多链模式有利有弊,提升性能的同时也增加了设计复杂度。
Hyperledger Fabric的通道机制其实可以算是早期的多链设计,但是通道在Hyperledger Fabric中并不是出于提升效率的目的设计的,而是为了满足业务多样性要求,以降低业务复杂度,因此,通道机制目前在性能扩展方面没有显著贡献;
FISCO BCOS是明确的并行计算多链设计,设计上要求开发者尽可能保持多链的同构特征以减少冲突,多链设计被直接应用在系统扩展方面;
Coco的模式仍然取决于其集成的区块链协议;
Quorum是单链模式的,底层的性能扩展要跟随以太坊的技术路线,可能要依赖以太坊的分片等技术进行扩展;
Corda设计上是多网络模式,没有单多链的概念,但是可以建立两个网络节点的双向连接,配置双方信任的公正和认证机构进行网络融合,融合算是其扩展的一种方式。
(四)加密算法扩展
对于国内的应用,加密算法的扩展也即国密替换是一个强烈需求,尤其是在金融领域。
Hyperledger Fabric不支持国密替换,目前已有的应用凡实现国密的基本上是自行替换或者依赖第三方服务;
FISCO BCOS是支持国密的;
Coco未对加密算法的选择有明确说明,因为这对Coco而言属于底层,取决于其集成区块链协议,但目前它所集成的协议中还没有支持国密的;
Quorum、Corda都没有对国密的支持方案。
(五)第三方认证证书支持
这一点对国内的应用也很重要。
Hyperledger Fabric目前不支持第三方CA;
FISCO BCOS支持第三方证书,支持证书的撤销,支持多CA;
Coco由于私钥都保管在本地业务系统且允许自己生成,网络上只存公钥集,因此技术上看应该可以支持第三方CA;
Quorum、Corda都未见有此类支持。
综上,Hyperledger Fabric在扩展性上有一定的限制; FISCO BCOS的可扩展性是很有优势的,尤其是面向国内应用时;Coco扩展性取决于其集成的协议;Quorum的扩展性与以太坊关系密切;Corda除了在加密算法和第三方认证证书方面外,扩展的自由度有可能是最高的。
五、节点管理与权限管理
除了共识之外,联盟链与公链的显著区别当属在节点和权限上的设计了。本文从节点类型、作用、成员准入控制、角色和权限管理这几个方面比较下各联盟链之间的差异。
(一)节点类型
Hyperledger Fabric网络中的节点主要分为排序节点、背书节点和记账节点三类,实际应用中还可以加入只有同步账本能力的二级节点;
FISCO BCOS中包含核心节点、全节点、轻节点;
Coco是一个可信验证节点(VN)分布式网络,也即,它只有一类节点就是VN;
Quorum中的节点是基于的以太坊Golang版本实现的,因此节点之间是对等的,没有节点类型的区分,节点之间可以有白名单管理;
Corda也不区分节点类型。
(二)节点作用
Hyperledger Fabric网络中背书节点负责提供签名服务,经背书节点签名且满足签名策略的交易提案会提交给排序节点进行交易排序和出块,再由记账节点完成账本更新;
FISCO BCOS中核心节点负责共识和记账,共识节点参与记账共识, 观察节点同步账本;
Coco、Quorum、Corda中节点都是对等的。
(三)准入控制
Hyperledger Fabric中有专门的CA模块提供用户信息注册、数字证书发行、延期和吊销等服务,成员管理采用MSP方式,同一个组织内的成员通过共用同一个MSP标识进行识别
FISCO BCOS中,成员加入网络采用管理员认证的方式,提供合法有效的成员信息与CA证书,由管理员审核通过后,加入网络
Coco网络中的角色分为成员和参与者两种,成员是网络的集体管理者,拥有投票权,投票决定其他机构的加入或删除;
Quorum网络中节点通过授权才能加入网络,授权是集中式的,通过Java控制台操作;
Corda中节点也是需要授权加入的,节点选择加入一个或多个网络地图,网络地图相当于网络成员及其地址列表,节点只能与所在地图中的成员进行交易。
(四)角色
Hyperledger Fabric中虽然成员没有明确的角色划分,但是基于其运维或对应的节点的差异会自然形成不同的角色;
FISCO BCOS网络中的角色包含超级管理员、链或权限管理员、运维、交易、监管等;
Coco网络中的角色分为成员和参与者两种,但不是必须同时具有两类参加者,也可以只有成员类型;
Quorum网络中没有角色的区分;
Corda网络中的角色分为公证人和参与者两种,公证人提供公证服务,参与者进行交易。
(五)权限管理
Hyperledger Fabric中权限主要通过策略进行管理,策略实际上是成员通过节点进行某种操作,比如提交交易提案等,所需要满足的签名数量要求。
FISCO BCOS权限管理采用系统合约的方式,并可以通过自定义合约的方式进行权限管理功能的扩展,权限管理模型为ARPI(账户——角色——权限——接口)模式,多个账户可以对应同一个角色,角色有明确的权限列表,每个权限对应一个接口,接口指向智能合约,权限列表按照系统合约方式维护。业务中的权限管理则采用交易权限链的方式,一个交易相当于一组权限链,包含多个Filter,交易处理是逐个Filter进行权限判断,一个交易完成相当于一组Filter审核都通过。
Coco网络有成员负责治理,参与者是没有投票权的,不能参加网络管理。成员和参与者都可以拥有VN。成员对网络的管理通过共同维护一个可编程的网络章程来进行,章程内容至少包括成员列表、VN列表、代码清单、TEE清单和投票策略。
Quorum、Corda没有明显的权限管理内容。
综合比较,FISCO BCOS的设计比较周全,也有一定的复杂性,但这也意味着它能够支持更复杂的场景; Hyperledger Fabric 、Coco带有一定中心化因素;相较之下,Quorum、Corda更接近公链思路。带有中心化因素本就是联盟链对其应用的商业环境的体现,这也无可厚非。
六、智能合约
为了提升效率,支持更加友好的设计,各联盟链在智能合约上也出现了不同的发展思路。
Hyperledger Fabric中的智能合约称为“链码”。链码分为系统链码和普通链码,前者包括生命周期管理、配置管理等,属于系统控制层面的链码;普通链码则是用于实现业务逻辑的链码,智能合约开发通常指的就是这部分链码。链码的业务模型为“MCV-B”,即,在传统的MVC(模型、控制器、视图)模式中嵌入B(区块链),强调链码是业务逻辑的加强。链码的生命周期包括打包、安装、实例化、升级、停止和启动,运行在Docker中,由背书节点进行调用,目前主要支持的是Go语言。Hyperledger Fabric虽然提供了跨通道机制,允许跨通道调用链码,但是跨通道调用只支持读而不支持写。
FISCO BCOS 中除了通常用于业务逻辑的智能合约外,将系统管理也智能合约化了,统称为系统合约,包含系统代理、节点管理、机构证书、权限管理、全网配置五类。上述合约原则上由区块链管理员在网络启动时部署,网络运行期间的变更则需要在去全网所有节点许可的情况下由管理员操作。FISCO BCOS主要支持EVM引擎的智能合约。
Coco由于其节点运行在可信执行环境中,因此,与其他联盟链不同的是智能合约只需单个节点运行,不必多次验证。更与众不同的是,因为可以单点只运行一次,所以Coco的智能合约支持不确定交易。此外,允许智能合约直接连接外部可信数据源。
Quorum是基于以太坊智能合约的,智能合约本身没有特别之处,合约运行结果方面,节点只对公开交易和节点涉及的私有交易进行验证,而不必验证所有交易。
Corda的智能合约设计思路也比较独特,首先,它主张智能合约的业务数据和业务逻辑要能关联到明确的法律依据上,这相当于要智能合约跟业务凭证之间具有强联系;其次,Corda主张纯函数式设计,力推金融合约的标准化,提供小型类库,以减少对低层次逻辑的重新开发;再次,单纯看智能合约的话,Corda的智能合约是“碎片化”的小段程序,而且只能做为起流转控制作用的“验证程序”,做不到一般智能合约那种价值转移功能,在Corda中,“交易”、“智能合约”和“流式架构”加起来才能与其他平台的智能合约相当。
总结一下,Hyperledger Fabric的链码设计给了智能合约一个新的设计框架,这方面它是开创性的;FISCO BCOS则将智能合约应用扩展到了系统管理方面;Coco采取了改变公链设计假定的思路,不仅不对智能合约进行重复验证,还支持不确定交易;Quorum 的智能合约基本沿袭公链思路;Corda的思路也比较另类,但是智能合约本身却更弱化了。
智能合约是随着以太坊火起来的,成了区块链的标志性技术,但其实目前的智能合约还远不够“智能”,这个名字容易引起误解。以太坊创始人Vitalik最近在推特上发文称对使用智能合约这个术语表示“十分遗憾”,应该使用更专业或更无聊的名字,比如,“持续的脚本”之类的东西,想来也有此意。
七、部署与运维友好性
联盟链常被称为是个“坑”,这个“坑”主要是在部署和运维方面。
(一)部署
Hyperledger Fabric虽然已经是个成熟框架了,有良好的社区环境,市面上还有若干不错的教材,但是部署方面依然让很多新人不知就里,笔者所在的微信群里大部分时间都在交流部署问题而非设计问题;
FISCO BCOSFISCO BCOS提供一键安装/step-by-step/docker等搭链方式,同时还未企业生产部署提供物料包的打包工具,简化部署复杂度。
Coco的部署特点是增加了一次对其他区块链协议的集成,要先有底层区块链协议,才能部署Coco,这其实要设计人员对Coco和其集成的区块链协议都有一定了解才好,学习成本较大,此外,Coco需要部署TEE硬件设备来支持可信执行环境构建,这是其他联盟链通常不需要的,TEE因此也成为一个安全隐患;
Quorum需要在以太坊之上部署,依赖以太坊,与Coco相同,设计人员最好也要了解以太坊;
Corda的部署目前缺乏实例来做比较。
(二)运维
Fabric目前没有提供多少支持工具,多数需要设计者自己开发;
FISCO BCOS提供了方便运维的合约命名服务,提供区块链浏览器和监控,并且有上帝模式用于处理节点崩溃问题,运维友好度有一定改善;
Coco目前未见提供多少运维工具;
Quorum有一些第三方支持工具;
Corda与其他联盟链相比,运维方面最大的特色莫过于支持受限形式的数据库回滚。
联盟链的部署和运维都有一定的学习曲线,其复杂度远高于公链,一个新手部署一条以太坊要不了多少时间,但是运转起一个联盟链,还是需要打听不少“小伙伴”的。
八、隐私保护
联盟链有一个让大家纠结的问题是,明明要上链一起共建生态、共享信息,却纷纷要求隐私保护,要上链又不能随意公开,不仅希望身份保密,还希望交易信息保密,这与公链信息公开、身份保密的设计理念有很大不同,但这是合理要求,尤其是在金融领域。本文从可见范围、加密措施两方面对各链加以比较。
(一)可见范围
Hyperledger Fabric的通道可以用来隔离数据,只有在同一通道内的节点才可以共享同一套账本信息,而通过组织设计,基于MSP标识可以在同一通道内进一步控制数据可见范围,1.2版中加入了私有数据模式,允许指定的节点间共享信息,这比组织更加灵活;
FISCO BCOS 设计了AMOP协议,以提供机构间的点对点通信,通信信息属于链下信息,不在全网共享,链上部分在引入中央对手方提供信用背书的情况下,数据也仅在交易方和中央对手方之间共享,多链方式也可用于数据隔离,必要时通过跨连互通;
Coco支持两个或多个交易者的机密交易,通过TEE控制可见性,但要求集成的区块链协议最好也提供一定支持;
Quorum区分公开数据和私有数据,私有数据只允许限定的交易方可见;
Corda数据仅在交易方之间可见,节点之间提供一个交易依赖关系图,数据根据需要发送,而不在全局广播,任何参与方都无法见到包含全部数据的全局账本。
(二)加密措施
Hyperledger Fabric1.1开始支持账本数据加密,1.2版引入私有数据后,设计上允许只给Kafka提供交易Hash用于排序而不向Kafka提供交易信息,以防排序节点泄露数据;
FISCO BCOS允许采用高强度的加密数据信封进行保护,未参与交易的机构只能接收到密文,此外,建议对敏感数据采用脱敏上链、Hash上链等方式进行保密处理;支持零知识证明组件,群签名,环签名,同态加密等方式进行各种场景的数据隐私保护。
Coco允许应用程序先进行数据加密再提交事务,公网数据采用加密传播的方式,以对不受信任的host保密;
Quorum有独立的Constellation模块,对私有事务的交易数据进行加密保护,还提供了独立的零知识证明(ZSL)模块以防止验证用户身份时发生信息泄露;
Corda也使用enclave进行数据保护,并考虑使用安全硬件。
在隐私保护上,各链都下了很大力气,这方面与其一较短长,不如考虑互相借鉴。
九、选型建议
通过以上九个方面,本文粗略比较了五大联盟链的设计与差异,如果非要从技术角度给各家打个分、排个名,实在有些“霸王硬上弓”之嫌,各家原本思路和焦点就不同,都有自己的“小目标”,非要不管人家自己的想法去论个短长,有些不太“科学”,也不是应用的合理“姿势”。各联盟链毕竟都是为了解决实际问题、为了落地区块链项目而设计的,所以,本文最后从大家都会关心的技术选型角度做个总结。
整体而言,Hyperledger Fabric的综合实力依然最强,推出时间早、框架完整且比较成熟,有国际化应用和国际化社区加持,案例和技术支持对于仍属早期发展阶段的区块链而言非常重要,Hyperledger Fabric在这方面可以说优势极大。但是,它也有些不能回避的问题,比如基础研发进展缓慢,研发主体不明确,一些应用者关心的关键问题迟迟不见解决。随着百度、阿里、腾讯、京东等一众国内大厂的强势加入,Hyperledger Fabric的优势地位也会受到越来越多的挑战,对此,它急需合适的应对措施。
FISCO BCOS应该说是本土化设计的代表,其在底层研究上的投入、关键技术上的改进、对国内需要的适应性调整、对社区建设和运维的重视,都有可圈点之处,平台在各行业的通用性也在加强,随着开源工作的推进和案例的不断增加,其本土化优势会逐步显现。在国家政策的鼓励下,国内大厂如今纷纷高调杀入联盟链市场,如果这些大厂真的“倾情”加入,那与Hyperledger Fabric相较,其开发主体、资金投入的稳定性要更有优势,而且,大厂们基本自带生态和流量,案例的增长、生态的发展也是可以预期的,是很多项目可以借力之处。
Coco、Quorum、Corda都存在支持能力不足、缺乏有效案例的问题,虽然微软目前在Coco以及其他基于Azure的区块链平台和应用上投入了一定力量,但是对国内应用者而言,仍显不足。
西安软件开发、西安APP开发、西安软件外包、西安软件开发、西安网站建设、电商软件开发、社交软件开发、直播软件开发、西安网站制作、西安区块链开发
因此,从技术选型角度来讲,应用者,尤其是新入局的应用者,最好还是在Hyperledger Fabric这种影响广泛的成熟框架或者FISCO BCOS这种有实力且能提供较强本土支持的平台上做选择,而在开发过程中借鉴下Coco、Quorum、Corda中的优秀设计理念。
区块链仍属于技术的早期阶段,这个阶段必然要求应用者具备较强的学习能力,多做基础研究,敢于对所选择的技术平台进行改良,积极与平台提供商合作进行技术探索,区块链还没到像主流操作系统那样可以“坐享其成”的阶段,仍然需要所有参与者秉持“开源”思想,不辞辛苦、热情奉献、共同进步。
互联网医院大门已敞开,信息安全有哪些薄弱点、又该如何保障?
2018-10-23
2018年,医疗信息化、互联网医疗重量级政策和标准频发,这为医院进入下一个发展阶段奠定了基础。但无论是医院信息化建设、互联网医院还是远程医疗,都离不开数据安全的问题。云时代的来临,更是让医院保障信息系统和数据的安全性,显得尤为重要。
医疗行业的信息安全市场情况如何?医院目前的信息安全的薄弱点有哪些?医院该如何应对信息化创新产品下的信息安全,以及日益泛滥的网络勒索?这些问题,将在本篇文章中得到深度探讨。
医疗信息安全市场缺乏活力,根本原因是?
下面这张表,是动脉网结合2018年《全国医院信息化建设标准与规范(试行)》安全要求 ,以及中国医院协会信息管理专业委员会CHIMA发布的《2017-2018中国医院信息化状况调查报告》中的相关数据得出。将两者相互印证之后,动脉网得出了目前三级医院信息安全建设情况:
从表中可以看出,目前三级医院的信息安全建设,主要集中在防火墙、反病毒、VPN/网闸和容灾备份这四个方面;建设较差的主要包括安全审计、身份认证、隐私保护、终端安全和网络安全。
针对医疗行业信息安全市场的现状,广州市妇女儿童医疗中心数据中心副主任曹晓均给出了自己的观点。他认为,市场的大小根本原因在于医疗行业的安全建设相对落后。
行业中,并没有整体的安全规划或建设思路。并且,大部分医院的安全建设都是满足合规性要求上的投入。如采购几台防火墙、终端管理软件再加上管理制度,就可以通过等保要求,真正用心做安全整体设计的并不多。这种现状,导致整个医疗信息安全市场缺乏活力。
此外,目前国内医疗行业更关注业务发展需求,缺乏专业的网络安全人才储备,这也是目前比较大的挑战。
一位业内人士则透露,一方面医院信息部门的地位相对弱势,信息化建设大多取决于院方领导的意识。对医院来说,单位网络设备体量不大,一般是纯内网的环境,当前重点建设基本集中在网络基础设施完善,安全建设相对滞后。再加上医疗行业属于财政差额拨款单位,有相当一部分医院资金不富裕,因此安全建设的优先级相对较低。
对于国内医疗信息安全市场现阶段的产值规模,作为国内信息安全企业的代表,绿盟科技相关负责人分析了以下两点原因:
其一,信息安全相关配套政策和标准较少。在网络安全法正式实施之前,国内对于个人隐私信息的安全要求几乎空白。而医疗行业是涉及个人隐私信息最为深入的领域,没有法律法规上的明确要求,没有行业标准的具体指向,各级医疗机构很难认识到信息安全对自身业务的深刻影响,也就很少会主动考虑在安全方面有所投入。
其二,信息或网络安全对医疗行业的实际业务推进上缺乏直观的价值感受。举例而言,一所三甲医院每年的IT类投资可能达到千万级。
但医院决策者基于业务发展的考虑更多的会对临床、研究、医技等业务领域方面进行投入,原因就在于这些IT投资对业务的推进和支撑几乎是肉眼可见,而信息安全的价值却很难被感知。
防护了多少安全攻击、解决了多少安全漏洞、抵御了多少次信息泄露,这些都不会被直接展示到决策者的案桌上。
正因如此,最近两年,各大信息安全厂商均在重点考虑和投入安全运营和效果可视化。
互联网医院扎堆出现,如何保障它们的信息安全?
如何保障互联网医院的信息安全?在回答这一问题前,首先要明确而其定义和具体要求。
互联网医院的概念提出,是为了解决原有传统医疗体系中所欠缺的专业医疗资源不均衡和医疗服务体验差的问题。因此互联网医院为了解决这两大核心问题,采用的机制是借助互联网这个强大的资源共享方式,借助云计算和大数据等技术,从模式和能力上对作为传统医疗业务的补充。
互联网医院的管理办法中提到,互联网医院由互联网进行远程访问,会涉及到实体医疗机构的重要系统数据交换,同时根据互联网医院信息系统按照国家有关法律法规和规定,实施第三级信息安全等级保护。所以,在满足医院的互联网接入和虚拟专用用上,医院还要满足数据安全的要求。
从本质上讲,互联网医院的信息安全所要保障的根本并没有变,依然是对于数据,特别是医疗临床等相关的健康数据的保护,从传输、处理、共享、存储各方面考虑其安全性。因此,要满足这类安全需求,绝不是单一的安全产品能实现。医院需要充分结合实际的技术场景,选择在各个维度能够达到风险控制需要的安全产品。
例如,在传输层面,互联网边界需要考虑访问控制、入侵防护、病毒检测和防护、WEB安全防护等措施。而在数据交换场景下,医院需要考虑数据脱敏、数据加密、数据防泄漏、数据库审计或防护等。所以,没有最好的安全产品,只有最适合业务的安全解决方案。
对于目前备受关注的互联网医院的信息安全建设,国内知名数据安全厂商安华金和医疗行业负责人认为,互联网专线和VPN能够解决一部分的外网接入的安全问题,但从业务访问的角度来讲,业务数据系统对外提供,包括远程医疗、医保查询、预约挂号等都需要直接访问业务数据,对于数据本身的访问安全以及对于内网访问安全也需要加强。
例如,在数据库安全方面可以采用数据库审计、数据库防火墙、数据库加密、数据库脱敏等手段进行安全加固。整体而言,可以从主动防御体系的思路做安全建设,这涉及四道防线:
第一道防线:检查预警。通过数据库漏扫产品对数据库威胁进行检查分析,给出安全建议。
第二道防线:主动防御。通过数据库安全运维产品的身份识别、运维审批、流程管理,防止非法人员操作;防止外部攻击破坏;与此同时做好内部防护,防止内部超级权限。
第三道防线:底线防守。
阈值管控:规避批量恶意访问,针对大批量医疗泄密进行告警控管,防止医疗数据批量查询;
数据库加密产品:防止防止医患数据泄露 “脱库”;
数据库脱敏产品:医疗数据去隐私化,防止泄漏真实数据给第三方。
第四道防线:事后追查。利用数据库审计产品来区分是外部威胁还是内鬼作案,可以对安全事件进行责任追溯。
对于互联网医院APP的安全问题,绿盟科技则认为应该从应用服务端、网络通信和用户三个层面来整体看待。
对于服务端而言,基于移动应用端的APP安全与传统的WEB安全并无本质区别,现有的WAF类防护产品依然适用,能够防护来自APP端的攻击,网络通信端的安全则主要考虑数据的保密与完整性。因此,医院可以通过SSL或HTTPS来解决。
而移动端的安全,对医院这样的企业级用户而言,几乎不可能通过传统意义上的安全产品来解决安全漏洞问题。因为无法要求每个移动端用户自己按照要求安装指定的安全软件,那会带来极大的用户体验下降。
因此,目前更多的医疗机构在上线APP应用前,会进行系统性的安全评估和安全的黑白盒测试。基于测试和评估结果,安全厂商能够指导开发者对不安全的漏洞进行及时修复,以此来彻底解决APP的安全问题。
曹主任的观点与绿盟科技类似,他认为,在远程移动的访问上,采用SSL VPN(国密)实现远程访问的却是较好的方案。在互联网医院与偏远地区医疗机构、基层医疗卫生机构、全科医生与专科医生的数据资源共享和业务协同上,可以考虑采用安全一体机部署在基础医疗机构本地,实现VPN安全组网和数据加密传输。
VPN和防火墙,医院青睐的两大香饽饽
在腾讯最近发布的医疗行业安全指数报告中提到,目前医疗行业的网络安全设备首选防火墙和VPN设备。
造成这个结果的原因,绿盟科技负责人认为主要有两个:一是这两类产品的使用范围更多,凡是有网络边界的地方几乎都要用到防火墙进行逻辑隔离。而VPN则是目前最为低成本和稳定的专用网络解决方案,凡是涉及到有需要远程接入访问内网的场景,都需要借助VPN实现,这造成了巨大的需求基数。
另外一方面,医疗用户普遍对网络安全的认识还不够深刻。特别在广大的基层医疗机构,因为网络规模较小、信息数据量也不大,认为边界防护有防火墙,通信数据保障有VPN即可确保整体网络安全。
但其实无论医疗机构的大小,涉及到病患隐私信息数据、临床信息数据等敏感数据的重要程度都是不言而喻。对这类数据的保护除了防火墙和VPN之外,还需要考虑边界的纵深防护,诸如入侵防护、病毒过滤、针对WEB应用的WAF产品,针对数据库保护的数据库防火墙和安全审计等环节,等需要考虑建设。
对于目前医院VPN的使用现状,安华金和负责人在与某三级医院信息科主任沟通之后,也给出了自己的观点:VPN一方面用于远程维护,另外一个主要的用途是区域联网。但目前区域联网更倾向于专线,只有条件不够,医院才选择走VPN。比如不少医院与市卫健委、省卫健委的连接方式就采用专线,而条件达不到的医院,则只能使用VPN实现连接。
此外,在实际使用中,医院不仅要考虑互联网访问的接入安全,还需考虑数据平台的安全。如果用户的VPN账户被盗取或者边界被入侵,那么核心的数据将直接暴露在攻击者面前。因此在对访问进行准入控制的同时,也需要通过数据安全手段对核心数据进行专业的防护。
对此曹主任也给予了认同,他表示,在目前医院的安全建设中,医院内网及远程医疗的发展尤为重要。因此,防火墙和VPN自然就作为刚需或首先。但随着如大数据、云计算、移动互联网、物联网等新技术的发展,安全技术同样需要发展和更新。
曹主任建议,医院可以进行体系化的安全建设,包括安全技术体系、管理体系、运营体系(服务体系),三者相辅相成。在方案上,可以采用融合安全、立体保护的架构,比如采用一体化的安全设备,减少设备运维管理压力。另外,在端点安全、网络边界安全、云端安全、安全服务、安全管理制度等,医院都应该及时加强。
保护医院数据安全,都有哪些妙招?
根据2018年《全国医院信息化建设标准与规范(试行)》安全的要求,三级医院的数据安全保护主要包括以下8大措施:
1、防火墙
2、安全审计设备
3、系统加固设备
4、数据加固设备
5、入侵防范设备
6、身份认证系统
7、访问控制系统
8、安全管理系统
对于现阶段三级医院建设较弱的身份认证环节,绿盟科技负责人表示,目前这部分医院普遍使用4A产品如堡垒机,来解决院内的统一认证的问题。通过将账号、认证、授权、审计四个过程,来解决对数据的访问权限的问题。
而认证的方式则可以根据所访问的数据和系统,医院可以自行选择强度适合的方式。例如针对核心的HIS数据,访问可以采用多人、多因素的认证方式,两个或两个以上的人员保存一副密钥的部分,通过静态密码结合短信令牌、CA证书、指纹或其他生物特征识别技术来实现强认证方式。针对医院的医护工作人员,则仅进行静态密码的认证来实现,以保障业务的顺畅性。
在2018版的《电子病历应用管理规范(试行)》解读中,首都医科大学附属北京天坛医院信息中心主任王韬曾阐述了现有数字签名在电子病历数据保护上存在的两大隐患:
1、签名内容的专属性,目前尚未出台电子病历签名内容的标准,这导致CA(证书授权中心)在签名时不考虑提交签名的内容是否存在问题,这到这患者存在“被掉包”的可能性。
2、签名内容完整性。由于医院签名次数较多,CA在验签时无法发现医院是否每次提交内容中有包含不利信息。
以上两种隐患,王主任认为可以通过签名+时间戳的方式进行解决。如此一来,就能保证每次的操作人员和操作时间可查询、可追溯。
但据曹主任所言,目前普遍的认证方式都没真正在医院用起来。比如内网中采用最多的CA认证,虽然它可以实现双因素认证,提高认证的安全性,但因为使用起来比较麻烦,并且还存在兼容性问题,因此医院采用的其实并不多。
而在数据的查询、追溯、管理上,医院可以采用日志审计、堡垒机、数据库审计等方式进行管理,实现一定程度上的数据保护。
但是在大数据上,非结构化的数据会存在一定的问题。并且多设备的部署,医院在管理运维方面也会比较麻烦。因此曹主任认为,在新的安全技术方向上,医院可以采用软件定义安全的模式进行部署。
面对日益泛滥的勒索攻击,医院该如何应对?
2018年1月15日,位于印第安纳州汉考克健康的Greenfield受到勒索软件攻击,这促使技术人员关闭了整个网络 。在医院电脑屏幕上出现勒索软件通知后不久。黑客竟然猖狂地表示,在技术人员支付比特币赎金前,他会长期“保管”一定数量的系统“人质”。
对此,卫生系统的IT团队立即关闭了包括医生办公室和健康中心在内的所有网络,以隔离病毒。相关技术人员表示,黑客正试图让医院无法运营,使用“数字挂锁”来限制人员对系统部分功能的访问。
McAfee首席科学家Raj Samani表示:“就勒索软件而言,医疗行业遭受的损失可能是最多的。勒索软件的爆炸式增长,其发源也是医疗领域。黑客们或将从传统形式的勒索软件,转向更多的网络破坏和服务中断型攻击。”
据动脉网了解,勒索病毒和挖矿病毒之所以威力巨大,一般是由于利用了永恒之蓝等远程攻击方式,能够自我传播。因此,一个有趣的现象是,即所谓的内外网隔离的内网环境反倒更多地遭到侵袭,病毒也更泛滥。
原因在于,相比于跟互联网直接接触的场景,纯内网的生产环境对安全少了对危机的敏感度。因此,被攻击或遭到病毒的侵袭也就成为必然结果。
在应对勒索病毒一事上,曹主任认为安全事件并非遥远不及。安全建设也不是单单的满足合规性建设,因为,哪怕很多医院通过等级保护三级的验收,也一样会中勒索病毒。原因是安全技术的发展,传统的防御技术对新型的威胁或者病毒是逐步失效的,所以需要加强监测与响应的能力。
在针对勒索病毒或者挖矿软件的风险上,曹主任认为可以采用四个阶段的防护措施:
第一阶段:加强端点安全的建设,包括主机(PC\服务器)的系统补丁管理、安全基线管理、病毒查杀软件等。可以部署下一代端点安全系统,如EDR软件,可以通过人工智能、大数据技术实现勒索病毒变种及未知威胁的防护。
第二阶段:加强全网流量风险监控及安全可视化的能力,通过整体安全感知平台,通过流量分析实现网络中的风险可视化,例如出现病毒感染时,可以通过全网的主机风险展示进行管理。
第三阶段,在网络边界处部署下一代防火墙设备,需要支持IPS、僵尸网络识别、AV防护等一体化的设备,并且可以和感知平台实现联动,当平台发现问题后下方策略到防火墙上进行阻断。
第四阶段,加强全网应急响应及应急演练的能力,可以通过采购第三方专业的安全服务,实现快速的事件响应。对勒索病毒进行预防和应急处置。
医疗信息安全虽有政策加持,但仍是一个长期过程
医疗行业性政策标准和近两年随着网络安全法正式实施,以及一些跟个人信息保护、关键信息基础设施保护等相关的法规、条例和标准,都对于医疗行业整体的网络安全环境形成有着非常正向的作用。
西安软件开发、西安APP开发、西安软件外包、西安软件开发、西安网站建设、电商软件开发、社交软件开发、直播软件开发、西安网站制作、西安区块链开发
细化行业政策和标准的出台,从顶层设计到具体实现各个层面进行了一定的归一化和标准化,统一共性问题的认识,统一解决思路,这不管是对于医院还是安全厂商都是非常利好的事情。
医院用户具有了在细分业务上权威的信息网络安全参考,安全厂商也可以在解决行业需求的问题上,更多的朝同一个大方向上的不同维度和领域来扩充和输出优势能力,对产业和行业用户来说,是一个多赢的结果。
虽然行业形势一片大好,但曹主任也给出了自己的一点建议:
虽然目前几乎所有的安全企业都在积极的学习和解读这些安全标准和政策,并根据自己的安全实践提炼出切实可行的医疗安全方案。但也应该清醒地看到,政策标准到具体执行落地还需要一定的时间,短期内对应医院的信息化建设上效应不明显,这是一个长期的过程。
程序员着装的改变史,你都了解吗?
2018-10-19
是什么力量,让任何地方的程序员都享有「免于体面的自由」?
在今天的社会里,工程师往往代表着知识水平和社会地位。每当普通人听到这个头衔,总会报之以敬仰的目光:
但有一种工程师,虽然也是如假包换的高级技术人员,却很少能享受到和同类相近的社交待遇:程序员。
和工程师的耀眼形象不同,多数人眼里的程序员更接近于一群情趣干瘪的宅男,而非高智商高收入的精英群体。网络上嘲笑程序员的段子俯拾皆是,简直发展成了一种文化现象:
客观而言,这些评价并不公正。作为高级技术人员,多数北上广的程序员都能做到月入万元以上,毫不逊色于其他工程师或职业。大多数嘲笑程序员的人,实现阶层逆袭的可能性都远远不及。
由「极客学院」发布的 2016 年程序员薪资统计
不过,程序员群体遭到戏谑的原因实在也不难理解。其中最重要的因素,就是他们与自身收入和社会地位完全不匹配的服饰装扮。
而且,这种现象并非仅仅存在于中国:硅谷技术精英的固定装束,也早已引起美国人民的注意。
美国网络总结的硅谷精英日常着装。
美剧《硅谷》(2014)中的程序员形象
程序员为什么穿得如此不讲究?这种鸡立鹤群的行业文化,又是如何形成的?程序员,曾经的体面人
程序员平凡的打扮的确很难让人联想到头顶光环的工程师。因为自工业革命以来,凭借技术创新带来的财富,工程师们的服饰早不复为从前的中下层匠人可比。
在阶层分明的正常社会,社会审美风尚往往是向上看齐。作为新富阶层的工程师,很快就如同旧时代的贵族一样穿着考究,其绅士派头俨然与政客难分轩轾。
例如,发电机的发明人迈克尔·法拉第出生于寒微之家,但留下的照片却都身着礼服:
而出身农家,仅仅中学毕业的著名电气工程师维尔纳·冯·西门子,也总是一副上流社会的打扮:
同时期出身富商家庭的英国首相威廉·尤尔特·格莱斯顿,和法拉第、西门子的着装风格非常相近,很难看出双方存在什么阶级差异:
即便在电脑的发源地美国,早期程序员(或者说软件工程师)的着装也完全是上流社会的造型。
由于计算机程序的设计基础是数理逻辑,所以最早的软件开发人员大多为数学家出身。他们来自美国的各大名校,其学院历史悠久,无论师生都对穿戴正装习以为常。
1939 年的斯坦福大学旧照
1950 年代的普林斯顿大学,大部分师生穿戴西装上课。这种偏向舒适的风格被称为常春藤联盟风格,对美国主流西装文化产生重大影响 / 图片来自:LIFE
因此,在这批人物的活跃时期,早期程序员也都衣着体面,绝不会在着装方面遭到企业家、政客、金融从业者的鄙夷。
被誉为「计算机之父」的普林斯顿大学教授约翰·冯·诺依曼身着正装站在计算机前
被誉为「人工智能之父」的数学家约翰·麦卡锡也是西装笔挺
体面人是怎样「堕落」的
然而,正是因为程序员与大学的紧密联系,导致程序员的着装文化发生历史性转折。
1960 年代中期,随着反越战、民权运动和嬉皮士运动的兴起,欧美的学院文化发生了翻天覆地的转变。
尤其是在以大学生为主体的「嬉皮士运动」中,学生们为了反抗既有的「传统秩序」,把传统着装体系中整洁、体面的绅士派头视为对个性和自由的压迫。休闲随性的便装和体现流行文化的奇装异服取而代之,在现代服装体系中的地位陡然上升。
这场学生运动对大学着装文化造成了深远影响,基本摧毁了西方大学里的正装习俗。如今,几乎没有哪个学生还会西服革履地前去教室上课,甚至老师们在讲课时也大多身着休闲装:
所幸的是,对于较传统的行业,职业着装已有行业惯例,学院时尚影响有限。即便藤校毕业的嬉皮士,一旦成为律师、医生或商务精英,还是该穿什么穿什么。
1970 年代初就读于耶鲁法学院的两位嬉皮士
然而,计算机编程却是与学院研究前沿关系紧密的新兴行业,完全不存在任何职业着装传统,因此给了新兴的高校着装文化可乘之机。
与之类似的,还有 C++语言的创始人比雅尼·斯特劳斯特鲁普,对服装品味同样不讲究。
电影「社交网络」中的程序员男主角,与一旁传统装扮的男子形成鲜明对比
而相比于见过世面但故意逆反的美国 geek,中国程序员的不修边幅更有底气:因为中国大学生几乎从未有过「体面人」的经历。
1952 年高校改制后,中国高校提倡「教育为无产阶级政治服务」,民国时代高校流行的西装和学生装都被革除。
当 1960 年代的西方大学生穿着奇装异服在大学里反对正装时,中国的大学生还穿着「劳动人民的服装」或「军装」,最体面也不过「中山装」而已。
这套传统的服装语言,在改革开放后迅速遭到淘汰,但体面的着装文化至今仍未能确立。穿背心拖鞋上课已是中国高校常态。
有趣的是,改革开放后中国的第一代程序员,由于大多出身于传统技术行业,出于工程师「自觉」,反而是一副「复古之风」,普遍喜欢正装出镜。
机电技术员出身的「王江民」,作为中国程序员界的老前辈,留下的媒体照片几乎全是西装、领带、白衬衫、金丝眼镜
直到中国互联网行业开始快速发展,程序员与传统工程师的生涯轨迹偏离得越来越远,信科或软工专业的毕业生实现了高校到企业的直达,后来的几代程序员,在着装方面才逐渐赶上西方发达国家的「先进水平」。
作为后起之秀的丁磊,服饰风格显得休闲了许多。
穿正装,有什么用?
除了「着装文化」的影响,程序员不注重仪表的原因和工作性质也是分不开的。
程序员的劳动强度较大,对产品的不定期维护(升级功能,修正 bug)显著延长了他们的加班时间。沉重的工作压力导致许多程序员一直处于精神疲惫状态,顾不上保养自己的个人形象。
同时,由于全天候生活在一种「只闻其声,不见其人」的社交状态下,程序员们自然也不需要注意衣着搭配。
一旦社交需求有所升级,程序员们并不会固守刻板印象中的邋遢形象。如比尔·盖茨这类公司老板,功成名就后,宅男气质迅速被商业精英的气息冲淡。
谷歌公司的两位创始人谢尔盖·布林和拉里·佩奇,出席一些正式场合时也会以体面的西装示人:
反过来说,假如长期与世隔绝,那么即使你不是程序员,你的服饰品味估计也会在不知不觉中跌落到和程序员一样的水平,甚至更糟。
例如,在普通人眼中,狭义上的宅男(游戏宅、动漫宅)和程序员往往可共用同一张标准像,但二者的重合度远没有他们想象中那么高。
西安软件开发、西安APP开发、西安软件外包、西安软件开发、西安网站建设、电商软件开发、社交软件开发、直播软件开发、西安网站制作、西安区块链开发
如果未来所有东西都能自动运转,人类会失业吗?
2018-10-19
据一份来自世界经济论坛(World Economic Forum )题为《未来的职业》的研究报告,人工智能和自动化创造的职业会比它所取代的更多。但报告里也警告道,对于一部分工人而言,这一转变过程将异常艰难。
「根据我们的研究,对于一部分新职业所产生的需求将会抵消另一部分职业需求的减少,」报告里说道,「但是,这里的净增长并不是必然发生的。这场变局对于数以百万计的工人而言必然是困难的,同时也牵涉新一轮全球性教育投资,以培养出适应新时代的人才。」
以下是这份报告里的研究发现:
到2022年,自动化将取代全球范围内的7500万就业岗位。但同时也会创造出约1.33亿的新就业岗位。这一则预测是根据送往全球超过300家雇主企业的调查问卷得来的。
2018年,在人类和机器的总工作时长中,人类占比71%。但在2022年,人类的工作时长占比预计将下降至58%。到2025年,世界经济论坛预计,人类占比将跌至48%。
被自动化所创造出来的职业和被它所取代的职业将完全不同。数据分析、AI,和机器学习专家,运营经理在新职业中名列前茅。而数据录入、会计和出纳、行政管理秘书则处在最有可能消失职业的清单里。
现在,我们对政府改进教育系统、刺激就业市场、为受影响的工人建立「安全网」有着迫切的需求,并且「支持终身学习者」。工人应该活到老学到老,而雇主则应该帮助他们学习。
西安软件开发、西安APP开发、西安软件外包、西安软件开发、西安网站建设、电商软件开发、社交软件开发、直播软件开发、西安网站制作、西安区块链开发
未来避免出现两败俱伤的局面——技术进步导致对相关人才的迫切需求,但也会导致大量失业以及社会两极分化加剧——对于企业而言,应该在推动现有工人学习新技术、帮助他们终身学习方面,主动发挥积极作用,而政府则应该创造一个良好的环境,在这方面帮助企业。