对于公证人模式的跨链,X链能够带来哪些突出的特点

2024-02-04 08:10

本文主要是介绍对于公证人模式的跨链,X链能够带来哪些突出的特点,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

一、X链Canal

当前一些知名的区块链项目,采用了不同的模式实现了跨链,比如Cosmos和波卡链采用了中继模式,瑞波(ILP)协议采用了公证人模式。公证模式一直被人批判过于中心化,造成这个的主要原因是公证特别少,公证人模式大部分是用于非链的模式下两个系统的相互交互或交易所模式,这样设计公证人模式由于节点特别少,中心化程度肯定高。这样的化必然会引入拜占庭容错算法去保证整个流程的有效性,对于跨链模式来说,并不能像比特币一样要10000万个节点去承担公证这种角色,实际上也不现实,这样也违背了三角理论,从三角理论来看,所谓的区块链“不可能三角”,也称为“三元悖论”,通常是指区块链系统无法同时兼顾去中心(Decentralization)、可扩展性(Scalability)、安全性(Security),至多只能三者取其二。是否有一种新的机制能够让少部分公证人验证每笔交易?足够多的节点来验证每笔交易系统必然安全,但又不能并行处理更多的交易。针对以上的情况,X链在这些基础上对公证人模式进行了一些改进,让公证人并不是中心化的公证人模式也能够快速验证交易的有效性。

二、怎样有效防止公证人过于中心化问题

依据三角理论系统安全提高的同时可扩展性和性能必然受限 。一般的做法是采用DPOS的方式,DPOS的方式会导致公证人权益过于集中,有没有一种方法,既能满足性能和扩展的同时,也能保证公证人权益不过于集中呢?这些都是值得深思的问题,X链对于公证人模式做了如下改进,对公证人节点进行随机分组,按照一定周期打乱公证人所在的组,这样公证人能并不知道自己什么时候能够参加交易的验证,这样有效的保证了公证人过于中心化的问题。原理架构如下图所示:

三、随机数怎样产生?

需要在保证公平性的前提下,保证公证人分配的随机性。

  • 公平性:每一个有效的公证人都有相同的概率被选中。
  • 随机性:单次分配结果随机且无法预测。

VRF简介

X链Canal的公证人产生使用VRF(Verifiable Random Function)算法来产生随机数,VRF 原理示意如下:

图 VRF 原理图

VRF算法过程如下:

  • 产生一对非对称密钥对(PK,SK):验证密钥PK(公钥)和SK(私钥)。
  • 生成可验证证明Proof。
  • 使用密钥SK对消息Entropy进行签名生成Proof,对于不同的密钥对(PK,SK)无法生成一样的Proof,所以输出的Proof是唯一的,并且具有无法伪造和抵赖性。由于每个生成的密钥对不同,Proof具有一定随机性。
  • 验证Proof。验证函数输入为消息Entropy、证明数据Proof、公钥PK,计算输出结果true/false,结果为true表示验证通过否则表示失败。Verify证明了Proof是否由密钥对(PK,SK)对消息Entropy生成。
  • VRF随机数产生。通过VRF过程Verify结果为true后,依据Proof的随机性,随机数Rand的产生就仅需对Proof进行Hash计算即可。

附加权益的BLS机制

一般情况下,基于所有公证人签名的随机数才具有唯一性。假设公证人集{1 2 3 4},则必须要他们共同签名,若4节点发生故障,则会导致随机数无法产生。如果仅使用其中3个节点签名,则无法确保随机数的唯一性,实际签名结果会有如下四种组合:{1 2 3}、{2 3 4}、{1 3 4}、{1 2 4}。由于私钥(Ed25519签名机制)不同,所以这四组签名结果也不一样,导致其产生的随机数也不同。

Orbits 使用阈值BLS[16][17]签名算法来生成随机数,原因如下:

  • 保证签名的唯一性。,通过BLS签名算法对前组签名进行再次签名的方式实现,其中BLS签名作为阈值多签签名,有其唯一性特性。BLS签名算法中,验证组签名成员数大于阈值,即可生成当前组唯一性签名。比如验证组有10人,其中6人签名即超过阈值,可生成这个组唯一的签名。
  • 签名存储空间需求小。若一个区块中有1000笔交易,每笔交易都有独立的公钥Pi、签名Si以及交易内容mi。如需知道区块中的交易签名是否正确,传统方法是对区块中交易进行依次验证签名,区块中需要存储所有交易的签名。而使用BLS算法进行签名的合并后,则只需要存储一个33个字节的BLS签名。合并签名的结果是:

验证过程是:

证明过程如下:

从证明过程可见,主要是原理是使用e函数交换规则。

为增强公证人安全性,BLS机制采用了附加权益方式。BLS 服务组属于公证人集,通过PoS方式缴纳质押金,押金在BLS 服务组存续期间不得转出。如果在BLS 服务组到期之前,申请提前退出,则扣除部分押金。如在BLS服务过程中作恶则扣除作恶者全部押金。BLS服务没有到期前,不能转走押金。

四、怎样让公证人愿意作为验证参与交易的验证?

无论是联盟链或是公链的模式下,每个跨链跨链交易在整个过程中都会产生成本费用,即每笔跨链交易公证人会分到这笔交易的手续费,而且涉及到跨链的手续费用比单独在一条链上获得的收益要高,这样公证人更愿意参与,考虑到部署成本和硬件的需求,X链的公证人节点采用的是单链的验证节点,这样验证节点不仅能够分到本身链的奖励还能够获得跨链交易的奖励。

通过以上的论述,X链在公证人模式下设计跨链,并不是单存的增加几个节点做公证人,而是通过随机混洗的算法,让公证人无法知道自己属于那一笔跨链交易的验证人,这样破除了公证人联合作恶的问题,也解决了公证人过于中心化的问题,X链的公证人模式相对于其它的公证人模式来说应该更安全,欢迎大家评论和转载。

这篇关于对于公证人模式的跨链,X链能够带来哪些突出的特点的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/676848

相关文章

便携式气象仪器的主要特点

TH-BQX9】便携式气象仪器,也称为便携式气象仪或便携式自动气象站,是一款高度集成、低功耗、可快速安装、便于野外监测使用的高精度自动气象观测设备。以下是关于便携式气象仪器的详细介绍:   主要特点   高精度与多功能:便携式气象仪器能够采集多种气象参数,包括但不限于风速、风向、温度、湿度、气压等,部分高级型号还能监测雨量和辐射等。数据采集与存储:配备微电脑气象数据采集仪,具有实时时钟、数据存

在JS中的设计模式的单例模式、策略模式、代理模式、原型模式浅讲

1. 单例模式(Singleton Pattern) 确保一个类只有一个实例,并提供一个全局访问点。 示例代码: class Singleton {constructor() {if (Singleton.instance) {return Singleton.instance;}Singleton.instance = this;this.data = [];}addData(value)

模版方法模式template method

学习笔记,原文链接 https://refactoringguru.cn/design-patterns/template-method 超类中定义了一个算法的框架, 允许子类在不修改结构的情况下重写算法的特定步骤。 上层接口有默认实现的方法和子类需要自己实现的方法

【iOS】MVC模式

MVC模式 MVC模式MVC模式demo MVC模式 MVC模式全称为model(模型)view(视图)controller(控制器),他分为三个不同的层分别负责不同的职责。 View:该层用于存放视图,该层中我们可以对页面及控件进行布局。Model:模型一般都拥有很好的可复用性,在该层中,我们可以统一管理一些数据。Controlller:该层充当一个CPU的功能,即该应用程序

迭代器模式iterator

学习笔记,原文链接 https://refactoringguru.cn/design-patterns/iterator 不暴露集合底层表现形式 (列表、 栈和树等) 的情况下遍历集合中所有的元素

Git 的特点—— Git 学习笔记 02

文章目录 Git 简史Git 的特点直接记录快照,而非差异比较近乎所有操作都是本地执行保证完整性一般只添加数据 参考资料 Git 简史 众所周知,Linux 内核开源项目有着为数众多的参与者。这么多人在世界各地为 Linux 编写代码,那Linux 的代码是如何管理的呢?事实是在 2002 年以前,世界各地的开发者把源代码通过 diff 的方式发给 Linus,然后由 Linus

《x86汇编语言:从实模式到保护模式》视频来了

《x86汇编语言:从实模式到保护模式》视频来了 很多朋友留言,说我的专栏《x86汇编语言:从实模式到保护模式》写得很详细,还有的朋友希望我能写得更细,最好是覆盖全书的所有章节。 毕竟我不是作者,只有作者的解读才是最权威的。 当初我学习这本书的时候,只能靠自己摸索,网上搜不到什么好资源。 如果你正在学这本书或者汇编语言,那你有福气了。 本书作者李忠老师,以此书为蓝本,录制了全套视频。 试

利用命令模式构建高效的手游后端架构

在现代手游开发中,后端架构的设计对于支持高并发、快速迭代和复杂游戏逻辑至关重要。命令模式作为一种行为设计模式,可以有效地解耦请求的发起者与接收者,提升系统的可维护性和扩展性。本文将深入探讨如何利用命令模式构建一个强大且灵活的手游后端架构。 1. 命令模式的概念与优势 命令模式通过将请求封装为对象,使得请求的发起者和接收者之间的耦合度降低。这种模式的主要优势包括: 解耦请求发起者与处理者

springboot实战学习(1)(开发模式与环境)

目录 一、实战学习的引言 (1)前后端的大致学习模块 (2)后端 (3)前端 二、开发模式 一、实战学习的引言 (1)前后端的大致学习模块 (2)后端 Validation:做参数校验Mybatis:做数据库的操作Redis:做缓存Junit:单元测试项目部署:springboot项目部署相关的知识 (3)前端 Vite:Vue项目的脚手架Router:路由Pina:状态管理Eleme

状态模式state

学习笔记,原文链接 https://refactoringguru.cn/design-patterns/state 在一个对象的内部状态变化时改变其行为, 使其看上去就像改变了自身所属的类一样。 在状态模式中,player.getState()获取的是player的当前状态,通常是一个实现了状态接口的对象。 onPlay()是状态模式中定义的一个方法,不同状态下(例如“正在播放”、“暂停