Question

区块链2.0时代，以以太坊（ETH）为代表的智能合约平台。 对区块链3.0的预测，killer dapp。 区块链2.0暴露的问题：

• 性能问题 公链共识算法；泛用支持；
• 难于开发和调试 不完善的新语言，不能及时跟进的工具链
• 价值波动 app受到以太币价格直接影响
• 性能隔离 forum3D的例子，app间竞争资源 以上问题导致2.0架构之上难以产生真正的商业应用。

chainSDK，新的思路，一链一应用。 类比操作系统的演进。

• 依需求特化链的共识和特性
• 支持运行复杂智能合同
• 应用之间性能隔离，价值隔离

chainSDK实现的特性：

• 精巧简单的内核
• 对应用层协议透明，集成BDT 更好的节点连通率，无中心DHT网络节点发现，更好的广播性能
• 对共识算法透明的基础架构，内建多种流行共识实现。 依据业务场景定制共识算法和链特性；极强的扩展性，立即落地业界前沿理论成果。
• 以javascript/typescript为开发语言 没有学习成本，完善的工具链支持
• 具备极强伸缩性的进程模型 支持灵活的横向扩展

自2009年BTC创世块落地始，区块链迅速席卷了整个世界。区块链包含了架构师们对公网分布式系统的一切幻想，最终一致、无中心、匿名、公开、不可篡改，让人魂牵梦绕难以割舍。人们无不期待着他如之前各种伟大的技术一般，改变商业模式，改变生活方式。随后ETH和智能合约出现，可编程区块链又朝这个梦想迈出了一大步。人们相信在链上孵育出诸如微信、淘宝般的杀手级应用，爆发一场新的革命近在眼前。然而几年过去，币价大跌，EOS难产，满目千篇一律的刮奖博彩，遍地朝生暮死的阿猫阿狗们透凉的尸骸，期待的未来还无比遥远。

这也难怪。当踌躇满志的策划们涌入ETH时，要面对的是贫瘠的性能和极高的时延，难以支撑商业应用场景；当一腔热血的开发者们涌入ETH时，要面对的是晦涩的开发语言，捉摸不透的隐含限制，极度缺失的工具链，高企的调试成本，难以完成复杂工程开发。更别提：当ETH跳水，以ETH结算的应用经济也难免池鱼之殃；当某个应用火爆一时，其他应用怕是一笔交易也难以吞吐。回过头来看ETH这些伟大的项目，是否是太过超前于时代？在公网共识仍然只有极其低效和缓慢的PoW经过千锤百炼的验证时，在新的开发语言尚未成熟普及时，在区块链经济仍然泡沫严重时，公网应用平台必然无法绕过上面那些问题。

回看过往操作系统的发展史，当超越时代的UNIX出现时，其多任务特性令开发者跃跃欲试，但是多任务带来的复杂度导致UNIX必须运行在以当时来说极其昂贵的高端硬件之上，这是用户难以承受的，多任务系统带来的各种特性也并非是用户急需的；此时技术上相对落后的的单任务DOS系统反而一度更加流行，无论对开发者还是用户来说，能够快速开发和部署应用，能够低成本的获取和使用应用才是最紧要的需求。

以史为鉴，我们这群小伙伴萌生了一链一应用的想法，为应用开发链，而非为链开发应用。上面那些问题的答案便豁然开朗起来：没有公网共识的负担，应用可以依照业务逻辑选择合适的共识，在性能和安全性间达到平衡；没有多应用一致的计费和运行时隔离需求，就无需定制可结算指令开销的虚拟机和新的编程语言；没有跨应用的经济共享，经济体系内循环更加稳定；没有多应用资源竞争，就不会受其他应用负载的影响。

我们的产品Bucky chainSDK应运而生。SDK贯彻了一链一应用的思路，旨在令开发者能够快速开发高性能的单应用链，快速落地。SDK以typescript开发，运行于nodejs环境，实现了如下特性：

• 精巧简单的内核，方便移植运行于各种规格的硬件之上，也方便开发者快速上手和深入定制
• 对应用层传输协议透明的IO架构，内建支持tcp协议之外，还集成了自研的BDT协议，旨在更好的节点连通率，无中心DHT网络节点发现，以及更好的广播性能
• 对共识算法透明的基础架构，内建PoW/DPoS/DBFT多种流行共识实现；可依据业务场景定制共识算法和链特性；极强的共识扩展性，方便立即落地业界前沿理论成果
• 智能合同以javascript/typescript为开发语言，使用流行语言天然降低学习门槛，并且得到海量开源库和完善工具链支持，保证开发者可以快速开发大型工程和复杂业务
• 具备极强伸缩性的进程模型，支持灵活的横向扩展和定制部署