TokenInsight 对话首席——底层公链展望之Monoxide篇

邀行业首席,谈市场现状,见趋势未来!本期《对话首席》线上活动于4月30日上午10点顺利举办。


本次《对话首席》特邀Harmony 联合创始人 兰荣坚、Conflux CTO 伍鸣、Nervos COO 吕国宁、Monoxide 创始人 王嘉平、超脑链 首席架构师 沈宇峰作为主嘉宾。


三家媒体观察团:链闻杨威、链得得常兴宇和火星财经陆洋。


同时,《对话首席》也欢迎交易所、钱包、挖矿等区块链各领域首席,参与到我们的活动中来,共同为行业的发展建言献策。详情可联系TokenInsight首席沟通官维维:tokeninsight_data。


本次【对话首席】活动,五位嘉宾分享的内容密集而精深,因此特分为五辑,以飨读者。以下为Monoxide 篇文字整理版:


第一环节:火星财经团提问 /


火星财经陆洋:2018年被称为公链元年,但过去一年的发展我们也看到了,许多项目遇到了瓶颈,在商业化上面临很大的问题。TokenInsight刚刚发布的报告里,我看到不少公链甚至开发停滞。虽然早上谷燕西(Ben Gu) 老师在这个群里跟大家分享说,“衡量公链的标准不是其技术性能多好,二是其同市场中的一个需求的匹配程度。”但我想,技术性能肯定是一个前提。我的问题便跟这个相关:


1. 分片、分层、DAG、新的共识机制,底层公链的性能拓展方式该如何选择?

2. 您的项目当时是如何考虑和权衡的?

3. 您觉得您项目技术架构的特点有哪些?


Monoxide 创始人 王嘉平:客气了,感谢!问题中这几个名词,实际上讲的不是同一个层面的技术点。当然我这边比较关注分片这个方向。


因为不管用什么方案,区块链性能问题在保证安全和去中心的前提下,首要解决的是不要再要求每一个节点都去重复一遍整个网络的工作量了。否则全网的性能极限就是单机性能和容量。这一点和用什么共识算法没关系,交易处理是不是并行也没本质关系。


让不同的节点去负责网络的不同部分,这个设计是大幅提升性能的关键。分片就是这样的一种设计。这类设计从来就不是给出一个达到多少多少TPS。而是TPS是一个可以由参与计算机的数量线性递增的值,这才是所谓的伸缩性。


就像刚刚 Conflux伍鸣总说的,要做到这件事情确实很难。不过,我们的Monoxide做到了。


640?wx_fmt=png


给个图,X是分片数量,Y是TPS,分片越多,TPS就越高。同时不仅仅TPS, 这个状态容量也是单机容量的 N倍,这个N就是分片数量。


Monoxide是Layer 1的区块链技术,不假设交易结构的任何局部特性,跨共识组的交易再多都无压力。性能提升包括吞吐量和状态容量,由划分的共识组个数决定。n个共识组将带来n/2倍的吞吐量提升和n倍的状态容量提升。在现在的互联网环境中,n最多可以到数万,这个是性能提升的上限。核心技术为一个中心,两个基本点:


一个中心是并行、异步并独立工作的多链架构(n个共识组),将网络通讯(网络)、合约计算(CPU)、状态表达(内存)和交易归档(磁盘)这个四个方面的工作量全部分片,即所谓的"全分片"。共识组是一个无锁(lock-free)的多链架构,独立完成共识,独立校验和执行交易,独立维护组内用户的状态和历史记录。


第一个基本点是高效的跨分片交易的处理。我们提出了"最终原子性",将交易中的原子操作拆分成多个,涉及不同共识组的操作,使之可以并行、交叠(interleave)地被处理。利用单链系统既有的未确认交易集合来完成各共识组之间的异步消息传递,完成一个交易的接力执行。使得跨分片交易对性能的影响最多折半,无论全网有多少个共识组。


第二个基本点是有效抵御多链结构中,算力分散的问题,即攻击者可以聚集算力攻击特定共识组(1%攻击)。我们提出了"连弩挖矿",允许一次成功的算力哈希刺探可以获得在多个共识组同时出块的权益。将物理算力(计算哈希的速度)最多提高为n倍对应的有效算力(实际出块的速度)。并且这种n倍放大之后的算力必须平均分配到各个共识组。如果攻击者企图针对特定共识组,将无法获得连弩挖矿带来的这种算力放大。从而使得对单个共识组的攻击依旧需要全网的51%物理算力。


之前广为流传的区块链不可能三角,在单链系统中,就是是要求每一个节点都去重复一遍整个网络的工作量的情况下才成立。在全分片的分片系统中,这个三角矛盾就迎刃而解。


安全方面。只要各个共识组本身是安全的,Monoxide就会是安全的。交易的安全和正确(例如避免双花)依赖于每个共识组内部的共识算法。Monoxide全网应对女巫攻击(Sybil Attack)也依赖于共识组内部的共识算法本身的抵御能力。就PoW而言,每个共识组的安全,依赖于其内部挖矿算力。


所以Monoxide架构的安全保障,核心是要能够抵御算力分散的问题,即全网算力分散到每个共识组之后,每个共识组的算力将是全网的1/n,这时单个共识组的防御壁垒将下降到 51/n %,(即所谓的1%攻击)。这将是一个完全无法接受的值。为了解决这个算力分散的问题,Monoxide引入了连弩挖矿(Chu-ko-nu Mining),使得单个共识组的防御壁垒回升到 51%。


去中心化方面。Monoxide依旧是一个彻底的permessionless的系统,并且每个共识组内部的全节点的负担始终保持在同维护一个单链系统相当的水平,可以被轻松部署到大部分有互联网接入的角落。


性能方面。由于各共识组的区块验证、存储和账簿状态更新完全独立,所以这三个方面将获得无代价的无限线性提升。共识组之间唯一需要打交道的地方,就是为了正确处理跨共识组的交易。这使得在数据传输方面,性能提升是有代价的,并且不是无限的。


为了高效完成跨共识组交易,Monoxide引入了最终原子性(Eventual Atomicity),使得即使跨共识组交易的比例就算是接近 100%,全网仍旧可以轻松地完成交易吞吐,其性能代价为一个和共识组个数无关的常数。


之前一直有误解,分片系统好像非常害怕跨分片交易,但在我们的系统中,跨分片的交易比例是100%也没有关系,对系统的性能并无影响。


最后,难,并不等于无解。

"我们时常遇到一些令人叹为观止的机遇,却一次次地被当成不可能解决的问题。”-- 約翰.加德納, 1965年


 / 第二环节:链得得提问 /


链得得常兴宇:首先还是感谢TokenInsight的邀请,2019年至今Staking Economy和跨链是底层公链的两大关注点。我的问题也与这两个方向有关:


1. 您如何看待PoS类项目采用Staking取代PoW算力的方式,未来会成为趋势吗?Staking 经济又会对区块链应用落地带来哪些影响?

2. 当前区块链不同链之间无法进行交互,跨链是必由之路。您认为未来跨链的生态图景是怎样的?

3. 2019年底层公链还会有哪些突围机会?


Monoxide 创始人 王嘉平:谢谢,前面几位已经分析很透彻了,我就补充一些些。这是很有趣的讨论,我看到了PoW 和 PoS的碰撞。我比较倾向于PoW这也是中本聪的本意。要知道PoW算法提出的时候,PoS的核心算法BFT早就有了,老人家不用,是有深意的。


我们先看安全性,我不大认同这个趋势,PoS用资产保护资产的做法,只会比PoW来得更中心化。现在还有矿主和交易所两极,而PoS就只有交易所一极了。


PoS背后的BFT算法本质上是premission系统,纯premissionless的共识算法只有PoW。共识算法就是拜占庭问题的这个错误理解,以讹传讹。大家看看,拜占庭问题的定义,上来就是N个将军。


这个N其实意味着premission,因为他有需要预先定义总共有多少个人能参与,而我们看PoW,根本没有N这个概念,不知道有多少个人在参与。


PoW其实解了一个比拜占庭问题更广泛的问题,他不需要定义一开始有多少参与方,这才是premissionless,更加去中心化。


然后,在分片系统中,PoS会带来更多的问题,PoS的出块证明比PoW的出块证明的数据量大好多倍,大大降低跨片的效率。在1%攻击问题上,强制分散Staking的做法,也很难解决大量分散的staker,其实背后是合谋的单一攻击方的问题。


所以在Monoxide系统中,我们采用PoW,每个分片内部的共识算法都是PoW。


再看Staking Economy,这个是上层的经济模型,无论底下是PoW 还是PoS,这样的经济模型都可以被实现,并不是只有PoS才能支持Staking Economy。


然后跨链是大趋势,这个没问题,帮助各个公链之间互操作。


最后,公链能不能突围,不取决于公链本身,作为基础设施只要其性能足够高,安全有保障就行。公链能不能突围取决于是不是有大体量的上层业务出现,大体量的上层业务选了哪个公链,哪个公链就能突围。不过至少,当这样的机会出现的时候,公链本身的吞吐量和容量要兜得住。


 / 第三环节:链闻提问


链闻杨威:作为TokenInsight 的好伙伴也是老朋友,感谢再次受邀。本人很荣幸代表「链闻」出席本次直播。我的问题是:


1. DApp 和稳定币,未来底层公链的生态发展方向有哪些?

2. To B 还是 To C,底层公链如何进行商业落地?

3. 您认为新成立的底层公链是否还有机会?

4. 您的项目未来在生态发展方向上有哪些规划?

5. 您认为哪些行业区块链会率先落地?


Monoxide 创始人 王嘉平:大面上,区块链解决的是共识的问题,那么哪里需要共识哪里就是区块链的机会。但是并不是所有业务逻辑都是共识,其实很多不是,那些没必要往区块链上面搬。


区块链本质是个技术,干的是提高生产力的活,扎扎实实在业务中找到提高效率降低成本的切入点才是正道。没必要为了落地而落地,作为基础设施,是需要耐心去等待上层业务的繁荣的,不必着急,急了也没用。


区块链这个事情现在其实还很小,存量不算什么,增量才是蓝海,大家都有机会。


刚刚提到Layer 2,倒是应该想想Layer 2应该解什么问题。首先需要明白,Layer 2是针对垂直业务优化的,因为在一个Layer 1上面可以部署很多不同Layer 2上去。这是Layer 2本质上可以做到Layer 1不能做到的优化。比如0x 就是非常优秀的Layer 2, 解了不适合在Layer 1上面做的事情。


公链的性能和容量需要Layer1去解决。Layer2如果真要做通用的性能,至少应该看Layer1收敛以后缺什么,而现在Layer1还没有收敛。


Layer1收敛后最可能的情况是容量大、吞吐量大,但延迟也大。因此延迟很可能依赖于Layer2去解决,而容量和吞吐量则不是一个很好的方向。因为Layer 2都是有假设和业务限定的,比如闪电假设,双方有频繁的来回转账。


但是有没有人去验证一下,在通道的存续时间窗口内,双方有频繁的来回转账的这种交易pattern是不是广泛存在。如果不是垂直业务,而是通用的高性能技术,有什么理由要放在Layer 2去解   而不是放在Layer 1。


微信小程序

Tokenin指数? Token白皮书? TIindex指数?


往日精选

底层公链行业2019 Q1报告 | TokenInsight

交易所行业2019 Q1报告 | TokenInsight

挖矿行业2019 Q1报告 | TokenInsight

【中心化交易所】行业月报 | TokenInsight

区块链赋能供应链金融研究报告 | TokenInsight


公众平台及联系方式

官网:https://www.tokeninsight.com

微博:@TokenInsight

电报中文:https://t.me/TokenInsightChinese

电报英文:https://t.me/TokenInsightOfficial

推特:https://twitter.com/TokenInsight

商务合作:bd@tokeninsight.com


查看项目报告请到官

https://tokeninsight.com/report


长按下图加维维好友

留邮箱地址收取干货周报邮件


640?wx_fmt=png

640?wx_fmt=png

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
MICROSOFT FOUNDATION CLASS LIBRARY : ZSCPascal AppWizard has created this ZSCPascal application for you. This application not only demonstrates the basics of using the Microsoft Foundation classes but is also a starting point for writing your application. This file contains a summary of what you will find in each of the files that make up your ZSCPascal application. ZSCPascal.h This is the main header file for the application. It includes other project specific headers (including Resource.h) and declares the CZSCPascalApp application class. ZSCPascal.cpp This is the main application source file that contains the application class CZSCPascalApp. ZSCPascal.rc This is a listing of all of the Microsoft Windows resources that the program uses. It includes the icons, bitmaps, and cursors that are stored in the RES subdirectory. This file can be directly edited in Microsoft Developer Studio. resSCPascal.ico This is an icon file, which is used as the application s icon. This icon is included by the main resource file ZSCPascal.rc. resSCPascal.rc2 This file contains resources that are not edited by Microsoft Developer Studio. You should place all resources not editable by the resource editor in this file. ZSCPascal.reg This is an example .REG file that shows you the kind of registration settings the framework will set for you. You can use this as a .REG file to go along with your application or just delete it and rely on the default RegisterShellFileTypes registration. ZSCPascal.clw This file contains information used by ClassWizard to edit existing classes or add new classes. ClassWizard also uses this file to store information needed to create and edit message maps and dialog data maps and to create prototype member functions. For the main frame window: MainFrm.h, MainFrm.cpp These files contain the frame class CMainFrame, which is derived from CMDIFrameWnd and controls all MDI frame features. resToolbar.bmp This bitmap file is used to create tiled images for the toolbar. The initial toolbar and status bar are constructed in the CMainFrame class. Edit this toolbar bitmap along with the array in MainFrm.cpp to add more toolbar buttons. AppWizard creates one document type and one view: ZSCPascalDoc.h, ZSCPascalDoc.cpp - the document These files contain your CZSCPascalDoc class. Edit these files to add your special document data and to implement file saving and loading (via CZSCPascalDoc::Serialize). ZSCPascalView.h, ZSCPascalView.cpp - the view of the document These files contain your CZSCPascalView class. CZSCPascalView objects are used to view CZSCPascalDoc objects. resSCPascalDoc.ico This is an icon file, which is used as the icon for MDI child windows for the CZSCPascalDoc class. This icon is included by the main resource file ZSCPascal.rc. Other standard files: StdAfx.h, StdAfx.cpp These files are used to build a precompiled header (PCH) file named ZSCPascal.pch and a precompiled types file named StdAfx.obj. Resource.h This is the standard header file, which defines new resource IDs. Microsoft Developer Studio reads and updates this file. Other notes: AppWizard uses "TODO:" to indicate parts of the source code you should add to or customize. If your application uses MFC in a shared DLL, and your application is in a language other than the operating system s current language, you will need to copy the corresponding localized resources MFC40XXX.DLL from the Microsoft Visual C++ CD-ROM onto the system or system32 directory, and rename it to be MFCLOC.DLL. ("XXX" stands for the language abbreviation. For example, MFC40DEU.DLL contains resources translated to German.) If you don t do this, some of the UI elements of your application will remain in the language of the operating system.

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值