程序猿们,别着急入手区块链,先给自己选好武林门派再练功不迟

在金庸的笔下,中原武林,门派林立:既有少林寺、逍遥派、丐帮、大理段氏、武当派、华山派、日月神教等强大派系,也有青城派,蓬莱派,峨嵋派,昆仑派,崆峒派等实力不凡的较小派系。学武拜师,入哪门哪派甚是关键。


同样,在孟岩的笔下,区块链江湖也有着自己的流派,不同的流派,其武功绝学流于不同平台,从而筑成一方诸侯,有强势的名门正派,也有表现不俗的小众门派。程序员初入区块链,搞懂相关门派的技术要求很是重要。


是时候放眼江湖,再给自己做点规划了。



作者 | 孟岩

编辑 | 鸽子


如果你关注区块链技术长达几个月,可能也会跟我一样,对没完没了的原理介绍、前景描绘、行业探讨和链圈新闻产生了审美疲劳。没错,区块链必须与行业紧密结合,它也有颠覆人类协作方式之洪荒巨力,但是说到底它还是一个技术活,是要写代码的,在咖啡厅里整天坐而论道是造不出金链子来的。技术人员的逻辑简单直接,这个事情有没有前(钱)途?有,那怎么干?


本文试图对区块链有关技术流派和主流平台进行一个概览,作为学习区块链技术体系的导览,意在抛砖引玉,促进区块链开发社区的讨论与共识。



区块链技术的流派


未战先谋局,你想投入区块链开发这个领域,至少先要搞清楚现在有哪些玩家,各自的主张和实力如何。


划分区块链技术流派并无一定之规,据我所见,或可有以下四种方式:


第一是按照节点准入规则,划分为公有链、私有链和联盟链。公有链的代表自然是比特币和以太坊,私有链则以R3 Corda声名最盛,联盟链的代表作品是Hyperledger名下的Fabric。公有链注重匿名性与去中心化,而私有链及联盟链注重高效率,而且还往往设置了准入门槛。公有链、私有链与联盟链之间的这些不同都在技术中有所体现,比如私有链和联盟链假设节点数目不大,可以采用PBFT算法来形成共识。而公有链假设有大量且不断动态变化的节点网络,用PBFT效率太低,只能采用类似抽彩票的算法来确定意见领袖。这就意味着,私有链与联盟链很难变成公有链,而用公有链来作联盟链或私有链虽然容易,却也并非即插即用。此种差异,学者不可不察。


第二是按照共享目标,划分为共享账本和共享状态机两派。比特币是典型的共享账本,而Chain和BigchainDB也应属此类,这几个区块链系统在各个节点之间共享一本总账,因此对接金融应用比较方便。另一大类区块链系统中,各个节点所共享的是可完成图灵完备计算的状态机,如以太坊、Fabric,它们都通过执行智能合约而改变共享状态机状态,进而达成种种复杂功能。


第三是按照梅兰妮 · 斯旺所描述的代际演进,将区块链系统分为1.0、2.0和3.0三代。其中1.0支撑去中心化交易和支付系统,2.0通过智能合约支撑行业应用,3.0支撑去中心化的社会体系。比特币和Chain应属于区块链1.0系统,而以太坊和Fabric是区块链2.0系统,目前尚无成功的区块链3.0系统出现,不成功的尝试倒是有那么一个,就是著名的The DAO。


第四是按照核心数据结构,分为区块链和分布式总账两派。区块链这一派在系统中真的实现了一个区块的链作为核心数据结构,而分布式总账这一派,只是吸取了区块链的精神,并没有真用一条区块链作为核心数据结构,或者虽然暂时用了,但声明说吾项庄舞区块链,意在分布式总账耳,若假以时日,因缘际会,未尝不可取而代之也。



主流区块链技术平台


了解流派划分,仍是只能用来指点江山,吹牛论道,要动手,总要有个切入点。区块链货币据说已经有上千个了,但值得关注的技术平台大概只有数十个,而如果要进入区块链开发领域,打下一个好基础,练出一身好功夫,捞到几个好offer,则值得深入研究学习的平台,屈指可数。


首先当然是比特币。比特币作为区块链的第一个也是目前为止最成功、最重要的样板工程,已经上线运行了八年多,本身没有发生任何严重的安全和运维事故,其稳定与强悍堪称当代软件系统典范。比特币Bitcoin Core是一个代码质量高、文档良好的开源软件,从学习区块链原理、掌握核心技术的角度来说,Bitcoin Core是最佳切入点,能够学到原汁原味的区块链技术。当然,Bitcoin Core是用C++写的,而且用了一些C++11和Boost库的机制,对学习者的C++水平提出了较高的要求。


学习比特币平台开发还有一个优势,就是可以对接繁荣的比特币技术社区。目前围绕比特币进行改进和提升的人很多,人多力量就大,诸如隔离验证、闪电网络、侧链等比较新的想法和技术,都率先在比特币社区里落地。比如侧链技术的主要领导者Blockstream是由密码学货币元老Adam Back领衔的,而Blockstream是Bitcoin Core最大的贡献者之一,所以一些有关侧链的技术在比特币社区里讨论最充分。


但比特币作为一个典型的区块链1.0系统,是不是支撑其他类型区块链应用的最佳技术平台,存在很大的争议。另外,也不是所有人都有能力和必要精通区块链底层技术。所以对那些急于冲到区块链领域里做(quān)事(qián)的人来说,可能更直截了当的学习目标是以太坊和Hyperledger Fabric。


在以太坊上面用Solidity进行的智能合约开发是切入区块链开发最简单的方式,没有之一。以太坊的理想非常宏大,由于配备了强大的图灵完备的智能合约虚拟机,因此可以成为一切区块链项目的母平台,是驮住整个区块链世界的大乌龟。在以太坊上开发一个类似比特币的加密货币,是一个不折不扣的小目标。一般有经验的开发者在文档指导下,半天到一天即可入门。问题在于,入门以后又如何?靠写Solidity是否就可以包打天下?这是大大存疑的。我们也可以反过来说,如果以太坊+Solidity是区块链的终极解决方案,那么怎么还会出现那么多区块链技术门派呢?特别是,以太坊似乎并没有给现实世界中巨型的中心化组织们留下一条活路,这种彻底不妥协的革命态度有可能也成为以太坊推广的障碍。


当前以太坊项目的开发进展并不顺利。一个比较突出的问题是项目过多,力量分散,导致项目质量参差不齐。但尽管如此,跟其他区块链2.0平台相比,以太坊提供的开发环境是最简单最完善的。初学区块链的人绝对有必要学习以太坊,从而对区块链和智能合约建立起一个最“正宗”的认识。


主流区块链技术平台的第三支就是Fabric,它是Hyperledger的第一个也是最知名的孵化项目。Fabric最早来自IBM的Open Blockchain项目,到2015年11月,IBM将当时已经开发完成的44,000行Go语言代码交给Linux基金会,并入Hyperledger项目之中。在2016年3月一次黑客马拉松中,Blockstream和DAH两家公司将各自的代码并入Open Blockchain,随后改名为Fabric。到目前为止,Fabric与Intel提供的Sawtooth Lake并列为Hyperledger的一级孵化项目,但前者得到的关注远超后者。


从技术角度来说,Fabric思路不错,重点是满足企业商用的需求,比如解决交易量问题。众所周知,比特币最大的短板是它每秒钟7个交易的上限,完全无法满足现实需要。而Fabric目标是实现每秒钟10万交易,这个量接近刚刚过去的双十一交易量瞬时峰值,完全可以满足正常条件下的行业级应用。Fabric用Go语言开发,也提供多种语言的API。特别值得一提的是,Fabric比较充分地运用了容器技术,比如其智能合约就运行在容器当中。这也是Go语言带给Fabric的一项福利,因为Go语言静态编译部署的特征很适合开发容器中的程序。


Fabric还有一些特点,比如其membership服务可以设置节点准入审查,这是典型的联盟链特征。再比如其共识算法是可定制的。Fabric自带PBFT共识算法实现,但是PBFT的算法效率是O(n²),其中n是节点数量。因此PBFT用在节点数量受限的联盟链里是没有问题的,但用在公有链里效率过低。


Fabric的短板是体系较为复杂,虽有文档,但缺少经验的开发者学习起来障碍比较大。然而由于其定位清楚,迎合了不少企业的心态,所以已经有多家机构在基于Fabric秘密研发行业内的联盟链项目。



小众门派


上述区块链开发的三大主流平台,从活跃度、受关注和参与人数来说,远远超过其他平台。但俗话说莫欺少年穷,一些眼下还默默无闻的平台也不容忽视。


Hyperledger的另一个一级孵化项目Sawtooth Lake是Intel开发的区块链平台,是一个很少被关注的项目,大概是因为被同在Hyperledger旗下的Fabric给掩盖了,再加上名字拗口,所以很少看到有人讨论它,项目活跃度也不高。但其实Sawtooth Lake是一个挺有想法的区块链项目,设计十分精心。它以数字金融资产管理为目标,整体架构清晰,模块化程度高,因此可定制能力也强。概念上独创了“交易族(transaction family)”概念,而且还支持PoET和Quorum两种共识机制。当节点数量很多(公有链环境)时,使用第6代Intel Core CPU所提供的SGX扩展功能提供一种称为时间流逝证明(PoET)的机制来形成共识,这种机制与比特币所采用的PoW同属“抽彩票”式的共识算法,但杜绝了通过ASIC专用硬件“作弊”的可能性,排除了比特币出现的算力过于集中的隐患,可靠性由Intel CPU硬件来保障,是公有链系统里很有价值的一个共识机制。另一方面,当节点数量少且受控时,Sawtooth Lake可以采用Quorum共识机制,这是由Ripple提出并验证的共识机制,非常适合于联盟链场景,这样Sawtooth Lake就摇身一变成为很好用的联盟链了。


Sawtooth Lake采用Python开发,并提供了Java SDK。由于这两种语言的流行度,实际上它应该有很大的潜在开发者人群。事实上,R3 CEV曾经测试过Sawtooth Lake并进行了成功的证券交易实验。当前它主要的问题是受关注度不足,不知Intel是否有足够的耐心和毅力坚持到底。如果Intel战略更明确一些,支持力度更大一些,我建议大家可以对它投以更多的关注。


R3 Corda是一个备受关注的分布式账本项目。R3是由数十家银行和金融机构支持的区块链企业,融资上亿美元,号称汇集了一票高手,潜心研究符合金融行业需求的分布式账本系统。Corda是R3分布式账本系统中的核心,在千呼万唤之后,于11月30日正式开源。


Corda采用JetBrain原创的小众语言Kotlin开发,对Java世界敞开大门,这是令人点赞的。此外,Corda更重要的特色是其与现有世界里大银行、大型中心机构的全面妥协、全面合作的姿态,这与以太坊革命无罪、造反有理的形象形成鲜明对比。Corda在设计中有多项独特考虑,就是为了对接现有的业务规则。比如在其他几乎所有区块链平台里,每一个交易对于各节点来说都是可见的,可见才能验证,能验证才谈得上共识,所以交易的全网可见性是顺理成章的。但是现实世界里金融机构之间的交易,只有交易相关方才能看到交易详情,工行与建行的一笔交易,绝无必要让招行看到。为了对接这个现实,Corda设计了与众不同的机制,牺牲了交易验证的全局可见性,确保只有交易相关方才能看到和验证交易本身。可是另一方面,银行业务是被重度监管的业务,不能因为你用了区块链系统,就把洋洋洒洒的巴塞尔协议晾在一边,监管机构的职能如何体现?这是其他区块链系统里考虑不多的。而Corda设计了独特的Notary和Oracle节点,为监管体系进入留下了空间。仔细品味,这些都是给现实世界当中的大机构预留的美差。这些设计上的考虑,无疑大大增强了Corda被现有大型金融机构采纳的机会。不过这一切看上去很美好,但目前Corda的实现基本上是个花架子,设想的种种,不少处于TODO状态。


另外两个值得点名的区块链门派分别是Chain和BigchainDB。前者跟Visa有合作,后者是一个基于RethinkDB开发的分布式账本,两者各有各的思路和特色,也拿到了为数可观的投资,不排除未来能有大的发展。限于篇幅,在这里不展开介绍了。


区块链开发所需具备的技术基础


可以预见,未来从事区块链开发的主要有三类开发者:


第一类是开发基于区块链的Web或移动App,这种开发者所需要的技能与今天的Web和移动开发者并无二致,这里就不赘述了。


第二类开发者是开发智能合约的。这类开发者使用类似Solidity这样的智能合约语言,或者直接用Go、Java、Python等语言开发。开发智能合约所要求的语言和算法技术水平不高,什么并发、多线程之类的东西一般用不到,普通开发者均可胜任。但是智能合约的难点在于业务与安全。本质上智能合约就是以代码写成的商业合同,必须对于业务有非常清晰的认识,对于安全有着深刻的理解,才能够写出正确的智能合约。因此,我认为未来智能合约的开发者,可能反而是具体应用领域的行业专家出身居多,因为让他们掌握Python语言,远比让程序员去理解进出口贸易规则或者商业票据业务要容易得多。


第三类开发者,就是区块链核心应用系统和核心平台的开发者。这部分人当然必须是技术高手,按现在通俗的说法,得是后端专家。从语言上讲,C++、Java、Python、Go、JavaScript都有可能要触及。从基础知识来说,要求对密码学、分布式系统、网络编程、系统架构和部署都有相当程度的理解和实践经验。这种开发者显然将是区块链技术浪潮当中的弄潮儿,也将是最大的受益者之一。


特别要点一下密码学。密码学是大多数开发人员的短板,但若要在区块链核心技术领域搞出能够碾压竞品的创新点,密码学是最有可能出成果的地方。不用说搞出什么密码学突破,就是将密码学现有成果充分运用在区块链里,都可能会搞出一些逆天的创新来。比如用零知识证明协议(zero-knowledge proof)构造高度匿名化的区块链系统,比如用私有计算外包(private computing outsourcing)技术让别的节点既能够验证交易,又对交易本身的内容一无所知,这都是能够激发大量商业模式创新的技术,等待密码学黑客们发掘和实现。因此,我相信密码学成为显学的时代即将到来。


区块链是一项前景无限、极具颠覆性和想象空间的技术,它有潜力带来一个完全不同的商业时代,塑造新一代的互联网,也有可能被传统势力合谋异化。无论如何,区块链为创业者和程序员提供了又一次弄潮的机会,在这片蓝海上将演出一场怎样的大戏,我们且拭目以待。


作者:孟岩,CSDN副总裁,区块链行业专家

RethinkDB 设计用来存储 JSON 文档的分布式数据库,可通过简单操作实现多机分布式存储。支持表的联合和分组查询。什么是RethinkDB?RethinkDB 是从头打造的第一个开源、可扩展的JSON数据库,用于搭建实时网页。全新的访问模型颠覆了传统的数据库结构:开发者只需告诉RethinkDB,实时连 续地将查询更新结果推送到应用就可以了,不用每次都去poll一遍。RethinkDB的实时推送结构为搭建可扩展实时应用节省了大量时间精力。除了为实时应用提供了全新的设计之外,RethinkDB 还提供了一种灵活的查询语言、直观的操作和监控API,安装学习起来也非常容易。你可以查看这篇 Advancing the realtime web 得到更多RethinkDB计划的技术细节。什么时候RethinkDB是一个好的选择?当你的应用很大程度上有赖于数据的实时反馈时,RethinkDB 就会成为一个很棒的选择。“查询-响应”式的数据库访问模型在web上的确很有用,它可以直接映射到HTTP的“请求-响应”。而现代应用则需要将数据直接实时地传送到客户端。能够最大化得益于RethinkDB实时推送架构的例子包括:协作网站和移动应用数据流分析应用多人在线游戏实时交易场所设备联机举个例子:在协作设计一个app的时候,其中一个用户改变了某个按钮的位置,服务器就必须在第一时间通知所有在完成同一项目的其他用户。网页浏览器 能够通过WebSockets和http持久连接来支持这一功能,但数据库系统要迎合实时需求仍然是一个大的工程难题。而RethinkDB作为第一个开 源、可扩展的数据库,就是特别为实时推送数据到应用而设计的。哪些人在用 RethinkDB?RethinkDB 的用户包括上百个科技创业公司、咨询工作室和世界五百强企业。这里是其中的一些:Jive Software 和 Mediafly 使用RethinkDB搭建强大的响应式网页和移动应用Pristine.io 和 Narrative Clip 使用RethinkDB搭建用于设备连接的云架构Platzi 和 Workshape.io 使用RethinkDB进行实时分析CMUNE 和 NodeCraft 使用RethinkDB构建大规模可扩展多人游戏RethinkDB 拥有超过十万开发者的活跃社区和上百个来自世界各地的代码贡献者。RethinkDB是基于现有技术的吗?高效实现实时推送架构需要重新设计绝大部分的数据库成分,包括查询执行引擎、分布式系统、超高速缓存子系统和存储引擎。因为架构影响到每一个数据库 组成部分,RethinkDB不得不从C 开始一步步写起来。RethinkDB 是由数据库专家组成的团队花了五年时间做出来的,还得到了来自世界各地上百个代码贡献者的帮助。RethinkDB和realtime sync不同在哪里?和Firebase, PubNub 或者Pusher 这类实时同步API相比,RethinkDB主要不同在以下三个方面:首先,实时同步API是云服务,而RethinkDB 是开源项目。RethinkDB也有云端,可以通过我们的合作伙伴 Compose.io 和 Amazon AWS获得。它还可以部署在你自己的架构中,没有任何限制。其次,同步实时API只局限于同步文档,而RethinkDB是一个有着更普遍应用范围的数据库系统。 在RethinkDB中你可以运行任意query,包括table joins, subqueries, geospatial queries, aggregation, 还有map-reduce。实时同步服务有更多查询功能上的限制。最后,实时同步API的设计是直接从浏览器访问。这使得基本的app能够快速地跑起来,然而一旦app扩展了,灵活性就会受到限制。 RethinkDB的设计是从应用服务器进行访问,这一点上更像是传统的数据库。可能会要多花一点设置代码,但拥有足够的灵活性去适应应用的成熟。RethinkDB和MongoDB又不同在哪里?RethinkDB所基于的架构和MongoDB非常不同。开发者只需告诉RethinkDB,实时连续地将查询更新结果推送到应用就可以了,不用 每次都去poll一遍。你同样可以在RethinkDB上用传统的“查询-响应”范式来书写应用。然后在你开始为app添加实时功能时再去订阅实时数据 流。举个例子,这是你让RethinkDB查询一个文件时的命令:r.table('users').get('coffeemug').run()然后这是你从RethinkDB订阅更新流时用到的语句,在任何时候文档发生了变化就会推送:r.table('users').get('coffeemug').changes().run()RethinkDB的实时架构可以和MongoDB的oplog相提并论,但前者提供了更高层次的抽象。RethinkDB的数据流与查询计算引擎无缝整合,并允许你订阅查询结果的变化,而不仅仅是把数据复制过来。这种架构大幅度地减少了搭建实时app所需的时间和精力。除了实时推送架构,RethinkDB 还有许多胜过 MongoDB的地方:一种高级的查询语言,能够支持table joins, subqueries 和大规模并行式分布计算。融合了查询语言的操作和监控API,大幅度降低了RethinkDB扩展的难度。简洁美观的UI 易于复制转发,拥有在线文档支持和查询语言建议。可以看看这篇 technical comparison of RethinkDB and MongoDB 里面的评论比较中立一些。想听听个人观点的,请看@coffeemug 的what makes RethinkDB different.什么时候RethinkDB是一个不好的选择?当你需要用到完整ACID支持或者更强大的架构实施,RethinkDB就不大好用了。在这种情况下你最好用一些传统的MySQL或者PostgreSQL数据库。如果你需要做深度、密集型计算分析的话,你最好用Hadoop或者类似于Verticaa的面向列的存储工具。在某些情况下RethinkDB会在一定程度上牺牲书写可用性(write availability)来保证数据一致性(data consistency)。如果高要求的书写可用性对你来讲很重要,那你也不要纠结了,像Riak这样的Dynamo式系统可能更适合你。想要更多地学习RethinkDB?阅读 ten-minute guide 开始学习RethinkDB。对于熟悉分布式系统的程序员可以直接阅读 architecture overview 。走捷径用 cookbook,你可以看到许多常用的 RethinkDB查询例子。 标签:分布式数据库
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值