建议和反馈

请填写你的反馈内容

链客Talk|YOUChain 首席架构师 何畅彬:YOUChain技术白皮书首次亮相,首席架构师深度解读

2020-04-09 ·3443次阅读 ·读完需要23分钟

今天“链客Talk”邀请YOUChain 首席架构师何畅彬来到链客直播间,和大家一起探讨YOUChain技术白皮书首次亮相,首席架构师深度解读这一话题。

 

何畅彬 YOUChain 首席构架师。毕业于北京大学,在分布式计算和高并发系统构架上有扎实的理论功底和丰富的实践经验。擅长十亿级 PV 的分布式系统设计实现与调优,是微服务和容器化的深度实践者。在加盟 YOUChain 前,作为联合创始人&CTO 创立业内知名的开发者服务平台 Bugtags,服务数万企业客户。在此之前曾于多家国内一线互联网公司担任技术专家。

 

以下是AMA问答内容

 

主持人首先请何总简要的介绍一下YOUChain是怎样的一个项目?

何畅彬:YOUChain(有链)核心团队来自蚂蚁金服、腾讯、微软、比特大陆等公司,致力于研发可承载大规模商业应用的公链系统及其繁荣生态。

 

YOUChain 具有四大技术突破。YPoS(Caravel)  支撑海量节点进行快速共识;超级路由实现了复杂网络的穿透和高效通讯;存储压缩让移动设备成为节点,实现完全去中心化。

 

主持人共识投票分为三类,其中的NextIndex投票是共识失败时才会被用到,共识成功时会不会产生额外的通信消耗,影响整个链的运行?

 

何畅彬:验证者进行NextIndex投票的主要作用在于告诉其它验证者,若这一轮共识失败,下一轮共识它将会继续对某个区块进行投票。若超过2/3的验证者对同一个区块进行了NextIndex投票,就意味着下一轮的区块提议者不会形成新的区块并广播到全网,进而节省了通信消耗。

 

若这一轮共识成功,NextIndex投票机制也是有益的。由于所有的验证者并不能保证处于同一轮共识的同一阶段,有些验证者很有可能是处于超前状态,而另一部分的验证者处于滞后状态。超前状态的验证者很有可能未来得及收集到滞后状态验证者的Precommit投票,从而超时并判定共识失败,开始下一轮的共识。但验证者只要收集到了足够多的Prevote投票,到了固定时间就会进行NextIndex投票。所以超前状态的验证者很有可能收集到某个区块超过2/3的NextIndex投票的。由此一来,超前状态的验证者进入下一轮共识后,不会再一次打包交易形成新的区块并广播出去,进而减少对带宽的损耗。

 

在我们技术白皮书的复杂度分析章节,通过对比提议一个新区块需要的通信消耗,与进行一轮NextIndex投票所需要的通信消耗,我们可以得知,当区块size超过382kB,使用NextIndex机制就可以降低通信消耗。所以,即时共识成功,只要能减少哪怕一个新区块在全网的广播,所有验证者进行一轮的NextIndex投票也是值得的。

 

主持人:共识成功后,并不像其他共识算法一样在commit阶段会将commit信息广播到全网,这样会不会影响到节点的同步?

 

何畅彬:首先,验证者在commit阶段将commit信息广播到全网的目的是为了通知其他验证者,它认可了某个区块。而我们的共识中没有这个环节主要是因为验证者只有同时收集到某个区块超过2/3的Prevote投票及Precommit投票,才会认可该区块。所以再进行一轮commit投票显得多余,因为若其它验证者也收集到了该区块超过2/3的Prevote投票及Precommit投票,自然也会认可这个区块。

 

在我们技术白皮书的安全性证明章节,可以得知在同一轮共识中,不可能出现两个区块会同时拥有超过2/3的Prevote及Precommit投票。所以,若其它验证者没有收集到足够多的投票,而收集到了足够多投票的验证者将commit信息广播出去,有两种可能。一、commit信息中包含了它所收集到的所有投票信息,其它验证者自然可以凭借这些投票信息,对该区块达成共识。但是,那会极大的增加整个网络的通信消耗。二、commit信息中不包含所收集到的Prevote及Precommit投票信息,则其它收到commit信息的验证者也无法根据该信息来做出认可这个区块的决定。因此,在commit阶段广播commit信息显得多余。

 

我们实际测试过程中发现,单个投票消息包大小不超过300B,大部分节点是能收集到足够多票数的,只有少数网络环境不好或严重落后的节点才会出现无法收集到足够多票数的情况。对于这些节点,我们在共识模块外有额外的区块同步机制,来保证节点能快速同步。

 

主持能否进一步解释一下,数据同步与存储技术是如何支持“手机即节点”这个目标的?

 

何畅彬“手机即节点”是我们努力的方向,手机这种设备,可以对应于技术白皮书中的“轻节点”的概念。关于轻节点,我们基于一些基本的约束条件以及功能要求来考虑数据同步与存储技术对轻节点的支持,即:1. 轻节点的存储资源比较受限,无法提供大容量存储;2. 轻节点加入和离开网络可能比较频繁,在其加入网络的时候,应该要能快速跟上当前的区块高度;3. 轻节点可以参与共识投票。

 

基于上述考虑,我们从一开始就考虑了快速同步的问题。

 

首先,在区块数据结构以及共识机制上,就为快速同步的实现打下了基础,即通过CHT的概念,将已共识完成的区块的区块号与区块哈希组织起来,形成一棵树,然后按固定的区块间隔,将CHT树根存储在特定的区块头上,然后通过额外的一轮共识投票对其附加了见证。从而新的节点通过跨越式的方式,通过验证附加见证,就可以验证CHT树根是否可信,进而通过该树根就能形成对一大批历史区块的背书。

 

其次,对于较近的一些区块,可能还没有CHT对其进行背书,但是基于caravel共识的特性,我们在快速同步区块时也可以跳跃式的对区块的合法性进行验证。上述两种机制加以结合,就是我们快速同步技术的核心,其技术细节以及安全性和性能论证,感兴趣的可以进一步查阅技术白皮书 2.4、2.5、2.6等章节。

 

然后,在上述快速同步的基础上,就能让轻节点较好地实现轻量级数据存储。

 

首先,对一个新加入网络的轻节点来说,我们还提供了轻同步的模式,轻同步跟快速同步原理上一样,不同点在于对较旧的大量历史区块,可以不同步其数据以及世界态,而只在同步到最新的若干区块的时候,才会同步相关的数据。这就极大地减轻了轻节点对历史数据的存储负担。

 

其次,在轻节点参与共识之后,是需要持续存储数据的,但是随着区块的增长,我们也有定期删除一些对轻节点来说不必要继续存储的旧数据,从而轻节点的数据存储量是远小于全节点的。

 

主持人你们的快速同步跟以太坊的快速同步有什么不同?

 

何畅彬:我们的同步技术跟以太坊的同步技术有类似的地方,我们确实也从以太坊学习借鉴了一些思路。但是在一些关键机制上来说,我们有很多独创之处:

 

首先,我们从区块数据结构以及共识层面就对数据同步问题做了考虑,增加了机制上的支持,我们的跨越式同步技术,是首创的。像以太坊以及其他一些项目,最多是依赖于可信检查点的机制实现首次的大跨度追赶(可信检查点之前的历史数据就不要了或不检查了)。

 

其次,我们的快速同步技术,是确定性的,是基于共识机制可验证的。而以太坊的快速同步,也有跳跃式验证的逻辑,但它这个跳跃式验证的安全性是基于概率的,不是确定性的。

 

最后,以太坊依赖的可信检查点机制,一定程度上说,是中心化的;而我们的数据同步技术,是没有任何中心化控制的,是任何新加入的节点都即时可用的。

 

综上,我们的数据同步技术具有全新的考虑,能够为节点快速加入网络提供非常好的支持。对于一个无许可的区块链网络来说,任意节点快速加入网络的能力是很重要的,而我们很好地提供了这个能力。

 

主持人为什么要使用QUIC代替TCP

 

何畅彬:Caravel是一种交互式的共识协议,所以在共识过程中会产生大量的数据,占用比较高的网络消耗。在实际的公网中,数据包的丢失是不可避免的,TCP协议的核心在于"丢包必须处理",在丢包发生时,连接会进行阻塞,从而等待数据包的恢复,这是由于TCP协议的拥塞控制机制决定的。TCP使用滑动窗口用来动态调整发送速率,而丢包恢复的过程中,滑动窗口总有停等的时刻,会消耗一个RTT,相当于50~100msg的时间。另外在丢包时会发送速率会减半,所以带宽利用率也不高。QUIC协议在连接上进行了IO多路复用,针对每个数据传输流提供了独立的丢包恢复机制和滑动窗口机制,若单个传输流发生丢包,不会影响其他的数据传输,更好的提高了数据的传输效率和带宽的利用。

 

QUIC默认支持TLS加密技术,并且连接建立消耗一个RTT优于TCP的TLS加密连接建立。

 

移动网络设备一直是我们的重点,移动网络中的设置IP和端口会跟随连接的基站进行变化的,TCP协议使用了四元组(源IP,源端口,目的IP,目的端口)来唯一标识连接,如四元组中的任何一个元素发生改变,连接都需要重新建立。QUIC在连接建立后会生成一个ID来表示连接,当节点的IP或端口发生改变后,可以无需重新建立连接,通过ID继续进行数据通信,对移动设备的用户体验正好。

 

主持人:为什么NAT优化会提连接成功率

何畅彬我们每个人都有一个身份证号码以识别个人身份,而互联网上的每台设备也有一个”身份”—IP来识别,IP是internet Protocol(网际互连协议)的缩写,是TCP/IP体系中的网络层协议。我们熟知的IPv4,诞生在1970年,意思是网际协议的第4版(internet Protocol version 4),是TCP/IP协议使用的数据报传输机制。虽然IPv4设计的很好,但随着互联网的发现,它的缺点也逐渐暴露了出来,其中最致命的是—数量有限。IPv4地址由点号分隔的四组数字表示,每个数字都是8位二进制数,因此IPv4总共有32位,表示的IP地址大约为43亿个。在2019年11月26日,全球所有43亿IPv4地址都已分配完毕,这意味着没有更多的IPv4地址可以使用了。为了解决IPv4地址耗尽问题,人们提出并设计了一种新的技术NAT技术来解决此问题,NAT全名网络地址转换(Net Address Translate),他的主要作用就是对IP地址进行转换。NAT通常部署在一个组织的网络出口位置,通过将内部网络的IP地址替换为出口的公网IP地址提供公网可达性和上层协议的连接能力。当前NAT的应用非常广泛,遍布网络的每个角落,他可以更好的利用有限的IPv4地址。有研究报告指出70%的P2P用户位于NAT以内,这个数字意味着大多数的PC设备需要通过NAT连接到互联网中。但是不同的NAT设备对IP地址转换的策略不一样,形成了6种不同的NAT类型,这就造成了不同的设备在通过NAT连接到互联网中后,因其NAT类型不同而无法进行连接的问题。因此我们在节点的发现过程,做了针对NAT类型的优化,在发现过程中保证节点收到的邻居节点的NAT类型与其节点本身的NAT类型是匹配的,可以进行连接的。所以节点路由中的邻居节点都可以进行连接,这样,大大的提高了连接的成功率。避免了连接资源的浪费。

 

主持人白皮书里看到有个rewards level的概念,可以介绍一下吗?

 

何畅彬:rewards level是我们在奖励结算中引入的一个概念,意在最大限度的避免产生不必要的数据,从而进一步减少对节点存储的压力。

 

我们在奖励计算中会对每种节点各有一个全局的rewards level,对于一个节点,它只需要用本节点历史结算的level快照,跟当前最新的rewards level比较,就可以知道这段时间它可得的奖励并进行结算。

 

主持人:节点怠工是怎么判断的?有什么代价?如果服务器要重启,会被判定成怠工吗?

 

何畅彬:我们以节点的活跃程度来判断众议节点是否怠工。在一段特定的区块区间内,如果众议节点没有参与足够的区块投票,则会被认定为怠工,并被惩罚一定额度的抵押。

 

如果服务器需要维护,可以发送一个节点离线的操作,待生效后即可关闭服务器了。待维护完毕,要记得重新让节点上线,这样才能参与到共识中获取区块奖励。

 

主持人主网何时上线,用户如何参与挖矿?

 

何畅彬:官方主网,将于 2020-05-18 上线;

进入https://node.iyouchain.com/ 节点管理平台进行抵押可以成为节点,或者上线之后,进行链上抵押,就可以进行参与验证者,分得奖励。

 

主持人对于开发者招募有何计划?另外YouChain代码是否友好,社区开发者需要掌握哪些开发语言?需要专门的培训吗?

 

何畅彬我们将会拿出丰厚的 YOU 作为奖励,与开发者共建公链生态。

YOUChain 将会彻底开源;支持主流语言的 SDK;编程模型与 eth/tron 类似。所以入门成本极低,现有的 DApp 迁移成本也极低。

 

YOUChain开发者资源网站:https://dev.iyouchain.com/

YOUChain开发者联系人:YOUChain9999


评论(0)问答(0)
请先登录或注册

请先登陆或注册

相关推荐

链客Talk|时空云科技联合创始人梁远升:IPFS矿工如何挖到属于自己的Filecoin

7月3日,“链客Talk”邀请时空云科技联合创始人梁远升来到链客直播间。给大家分享了“IPFS矿工如何挖到属于自己的Filecoin”这一话题。 以下是此次活动的问答内容整理: 大......
链客Talk · 2020-07-06
148阅读 · 0赞赏 · 0问答

链客Talk| PolkaBase联合发起人林晓:跨链之王—Polkadot公链项目上线进展与生态参与

链客Talk| PolkaBase联合发起人林晓:跨链之王—Polkadot公链项目上线进展与生态参与6月25日,“链客Talk”邀请PolkaBase联合发起人林晓来到链客直播间。给大家分享了“跨链......
链客Talk · 2020-06-29
2150阅读 · 0赞赏 · 0问答

链客Talk|卡尔达诺大使陈哲:用科学和严谨突破公链瓶颈

6月17日,“链客Talk”邀请卡尔达诺大使陈哲来到链客直播间。给大家分享了“卡尔达诺,用科学和严谨突破公链瓶颈”这一话题。   首先给大家介绍一下陈哲的背景资料:Ans......
链客Talk · 2020-06-18
1622阅读 · 0赞赏 · 0问答

链客Talk|EOSwriter创始人Peter:两周年的EOS还有诗和远方吗?

6月12日,“链客Talk”邀请EOSwriter创始人Peter来到链客直播间。给大家一起分享了“两周年的EOS还有诗和远方吗?”这一话题。 首先给大家介绍一下Peter的背景资料:&nb......
链客Talk · 2020-06-15
1755阅读 · 0赞赏 · 0问答

链客Talk|以太经典亚太地区社区经理胥康:ETC Phoenix硬分叉升级与ETH保持一致

6月1日,“链客Talk”邀请以太经典亚太地区社区经理胥康来到链客直播间。和大家一起聊聊“ETC Phoenix硬分叉升级与ETH保持一致”这一话题。 首先给大家介绍一下胥康的背景资料:&n......
链客Talk · 2020-06-03
2239阅读 · 0赞赏 · 0问答

链客Talk|《IPFS原理与实践》作者、IPFS技术布道者董天一:深度解读IPFS和Filecion

内容:5月15日,“链客Talk”邀请《IPFS原理与实践》作者、IPFS技术布道者 嘉宾董天一来到链客直播间。和大家一起聊聊“深度解读IPFS和Filecion”这一话题。  以......
链客Talk · 2020-05-22
2219阅读 · 0赞赏 · 0问答

链客Talk

381

LK币

2

粉丝

44

笔记

感谢"链客Talk"

这篇精彩的笔记,目前已经帮助

  • 0
  • 3
  • 4
  • 4
  • 3
喜欢0
链客社群 加入

微博进入

商务合作>

广告投放>

公司名称:北京链客行科技有限公司

联系方式:010-67707199

ICP备案号:京ICP备18032136号

Copyright:链客区块链技术问答社区 版权所有

感谢您的提问,问题被社区永久收入以便新人查看。一定要记得采纳最佳答案哦!加油!

感谢您的善举,每一次解答会成为新人的灯塔,回答被采纳后获得20算力和相应的LK币奖励

您将赞赏给对方2LK币的奖励哦!感谢您的赞赏!

您将赞赏给对方2LK币的奖励哦!感谢您的赞赏!