NO.18 什么是拜占庭将军问题

2024-02-15 11:18
文章标签 问题 拜占庭 将军 no.18

本文主要是介绍NO.18 什么是拜占庭将军问题,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

本文是转载,转载自苏神的博客,原文地址:https://www.jianshu.com/p/5fea30b25f0a

 

拜占庭将军问题很多人可能听过,但不知道是什么意思,本文从非专业的角度来讲讲,拜占庭将军问题到底是说什么的。

 

拜占庭将军问题(Byzantine Generals Problem),首先由Leslie Lamport与另外两人在1982年提出,很简单的故事模型,却困扰了计算机科学家们数十年。

 

故事大概是这么说的:

 

拜占庭帝国即中世纪的土耳其,拥有巨大的财富,周围10个邻邦垂诞已久,但拜占庭高墙耸立,固若金汤,没有一个单独的邻邦能够成功入侵。任何单个邻邦入侵的都会失败,同时也有可能自身被其他9个邻邦入侵。拜占庭帝国防御能力如此之强,至少要有十个邻邦中的一半以上同时进攻,才有可能攻破。

 

然而,如果其中的一个或者几个邻邦本身答应好一起进攻,但实际过程出现背叛,那么入侵者可能都会被歼灭。

 

于是每一方都小心行事,不敢轻易相信邻国。这就是拜占庭将军问题。

 

在拜占庭问题里,各邻国最重要的事情是:所有将军如何能过达成共识去攻打拜占庭帝国。

 

达成共识并非坐下来开个会那么简单,有的将军心机深不可测,口是心非,如果有叛徒,可能会出现各种问题:

 

叛徒可能欺骗某些将军自己将采取进攻行动。

叛徒可能怂恿其他将军行动。

叛徒可能迷惑其他将军,使他们接受不一致的信息,从而感到迷惑。

 

针对拜占庭问题的深入研究,科学家们得出一个结论:如果叛徒的数量大于或等于1/3,拜占庭问题不可解。

 

解释过程可以用一个副官模型来解释:

 

假设只有3个人,ABC,三人中如果其中一个是叛徒。当A发出进攻命令时,B如果是叛徒,他可能告诉C,他收到的是撤退的命令。这时C收到一个进攻,一个撤退,于是C被信息迷惑,而无所适从。

 

如果A是叛徒。他告诉B“进攻,告诉C“撤退。当C告诉B,他收到撤退命令时,B由于收到了司令进攻的命令,而无法与C保持一致。

 

正由于上述原因,在只有三个角色的系统中,只要有一个是叛徒,即叛徒数等于1/3,拜占庭问题便不可解。

 

当然,只要叛徒数小于1/3,问题还是可解的。

 

科学家们提出了口头信息方案和书面协议两个方案。

 

解决方案一:用口头信息

口头信息即使将军们派人用口信传达消息,口头传达消息的实际含义指的是:

 

每个被发送的消息都能够被正确投递

信息接受者知道消息是谁发的

沉默(不发消息)可以被检测

 

口头协议的算法很简单,如果其中一个节点,比如1发布消息出去,210都接受到1的消息,然后210也分别转告给其他的节点,每个节点都是信息的转达者,一轮下来,每个节点手上都会有10个信息(进攻或者撤退),有叛徒的话,那信息可能有进攻或者不进攻的不一致消息。每个人相当于手里有一本消息的账本,该怎么决策呢?如果有一半以上的人说进攻,那么采取进攻行动就是能成功的,所以这时即便有叛徒,只要听大部分人的,少数服从多数来行动即是有利的。

 

这种口头协议的算法也存在明显的缺点:口头协议并不会告知消息的上一个来源是谁,也就是消息不可追根溯源,出现信息不一致也很难找到叛徒在哪。

 

解决方案二:用书面协议

可以假设10个国家,每个国家都可以派人向各个国家派信,比如一起约定 某天早上六点,大家一起进攻拜占庭,同意就签个字。收到信的国家如果同意的话,就可以在原信上签名盖章。

 

书面协议相比口头协议,实际说的是在这个多人的将军模型中加了了个隐含条件:

 

将军们能够使用签名技术,签名不可伪造,一旦篡改即可发现。

同时任何人都可以验证签名的可靠性。

 

书面协议相比口头协议,所有的消息都是有记录的,解决了追根溯源的问题。

 

但在现实中仍然可能面临各种问题:

 

中世纪的邻邦之间沟通只能靠信使骑马,将军们互不信任,也不可能亲自聚在一起开会,物理距离导致信息传输延迟。

真正可信的签名体系难以实现。签名造假的问题也没法避免。

签名消息记录的保存难以摆脱中心化的机构。

 

另外,倘若每个国家都各自向其他9个国家派出信使,在这个网络即需要90次的传输才能完成一轮信息交流,但是每个国家可能回馈不同的进攻时间,在这种异步通信的条件下,要能协商一致是个大问题。

 

也就是如果能够依赖中心化可信的机构,也许能通过多方的签名记录整合在一起,更容易地实现9个国家的意见统一,但这是个伪假设,因为前提是这个网络就是互不信任的。

 

这就是一个由互不信任的各个邻邦国家所构成的分布式网络,要获得最大的利益,又必须一起努力才能完成,如何达成一致的共识,变成了一个难题。

 

莱斯利·兰伯特提出了拜占庭将军问题,但真正解决这以难题的是——中本聪。

 

终极解决方案:区块链技术

互联网的存在,首先降低了信息的流通成本。每个将军配一台电脑,就解决了书面协议中骑马通讯造成时间延迟的问题。

 

如果10个将军中的几个同时发起消息,势必会造成系统的混乱,造成各说各的攻击时间方案,行动难以一致。

 

谁都可以发起进攻的信息,但由谁来发出呢?中本聪巧妙地在个系统加入了发送信息的成本,即:一段时间内只有一个节点可以传播信息。

 

它加入的成本就是工作量“——节点必须完成一个计算工作才能向各城邦传播消息,当然,谁第一个完成工作,谁才能传播消息。

 

当某个节点发出统一进攻的消息后,各个节点收到发起者的消息必须签名盖章,确认各自的身份。中本聪在这里引用现代加密技术为这个信息签名。

 

这种加密技术——非对称加密完全可以解决古代难以解决的签名问题:

 

消息传送的私密性

能够确认身份

签名不可伪造、篡改

 

非对称加密算法的加密和解密使用不同的两个密钥.这两个密钥就是我们经常听到的"公开密钥"(公钥)"私有密钥"(私钥).

 

公钥和私钥一般成对出现, 如果消息使用公钥加密,那么需要该公钥对应的私钥才能解密; 同样,如果消息使用私钥加密,那么需要该私钥对应的公钥才能解密.

 

非对称加密的作用是:保护消息内容, 并且让消息接收方确定发送方的身份.

 

比如,将军A想给将军B发送消息,为防止消息泄露,将军A只需要使用B的公钥对信息加密,而B的公钥是公开的,B只需要用只有他自己只的私钥解密即可。

 

将军B想要在信件上声明自己的身份,他可以自己写一段签名文本,并用私钥签名,并广播出去,所有人可以根据B的公钥来验证该签名,确定的B的身份。

 

由此,一个不可信的分布式网络变成了一个可信的网络,所有的参与者可以在某件事在达成一致。

 

写到这里,同时终于明白了工作量证明(Proof Of Work)的意义。有人说挖矿浪费了巨大的社会资源,但建立信任的成本可不是0,挖矿是维护比特币网络可靠性的最好办法。

 

工作量证明,简单的理解就是一份证明,现实中的毕业证、驾驶证都属于工作量证明,它用以检验结果的方式证明你过去所做过了多少工作。

 

在拜占庭的系统里,加入工作量证明,其实就是简单粗暴地引入了一个条件:大家都别忙着发起消息,都来做个题,看谁最聪明,谁就有资格第一个发起消息。

 

这个题必须是绝对公平的,中本聪在设计比特币时,它采用了一种工作量证明机制叫哈希现金,在一个交易块这要找到一个随机数,计算机只能用穷举法来找到这个随机数,可以说,能不能找到全靠运气,所以对于各个节点来说,这个世界上,只有随机才是真正的公平,实现随机的最好办法是使用数学,所有的将军在寻找共识的过程,借助了大家都认可的数学逻辑。

 

如果不同的将军先后解出了题,各自先后向这个网络发布消息,于是各个节点都会收到来自不同节点发起的进攻或者不进攻的消息,那怎么办的?只有时间最早的发起者才是有效的。中本聪巧妙的设计了一个时间戳的东西,为每个将军在解好题的时间(出块时间)盖上时间印章。

 

将军们那又凭什么要一起做工作量证明呢?中本聪也完全可以设置一个奖励机制,比特币的奖励机制是每打包一个块,目前是奖励25个比特币,当然,拜占庭将军问题的奖励机制可以是瓜分拜占庭获得的利益。

 

对了,如果有出现背叛怎么办?

 

在这个分布式网络里:

 

每个将军都有一份实时与其他将军同步的消息账本。

账本里有每个将军的签名都是可以验证身份的。如果有哪些消息不一致,可以知道消息不一致的是哪些将军。

尽管有消息不一致的,只要超过半数同意进攻,少数服从多数,共识达成。

 

由此,在一个分布式的系统中,尽管有坏人,坏人可以做任意事情(不受protocol限制),比如不响应、发送错误信息、对不同节点发送不同决定、不同错误节点联合起来干坏事等等。但是,只要大多数人是好人,就完全有可能去中心化地实现共识(Consensus)。

 

区块链上的共识机制主要解决由谁来构造区块,以及如何维护区块链统一的问题。

 

拜占庭容错问题需要解决的也同样是谁来发起信息,如何实现信息的统一同步的问题。

 

到这里也可以知道了,基于互联网的区块链技术,它克服了口头协议与书面协议的种种缺点,使用消息加密技术、以及公平的工作量证明机制,创建了一组所有将军都认可的协议,这套协议的出现,拜占庭将军问题也就完美的得到了解决。

 

伟大的创新往往是站在前人的肩膀上,中本聪就是各种前沿技术的整合者,古老的疑难杂症在这种整合创新下,就变得不再是问题了。

 

【作者:Sammy,做为区块链的一个长期学者,研究者,对区块链有着强烈的兴趣,愿意跟大家分享区块链知识,带领大家一起进入区块链的大门,共同体验区块链带来的变革。原创作品(本篇非原创),欢迎转载,转载请标明出处。可加微信公众号共同探讨、学习,扫码或搜索:区块链之我见】


这篇关于NO.18 什么是拜占庭将军问题的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



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

相关文章

IDEA和GIT关于文件中LF和CRLF问题及解决

《IDEA和GIT关于文件中LF和CRLF问题及解决》文章总结:因IDEA默认使用CRLF换行符导致Shell脚本在Linux运行报错,需在编辑器和Git中统一为LF,通过调整Git的core.aut... 目录问题描述问题思考解决过程总结问题描述项目软件安装shell脚本上git仓库管理,但拉取后,上l

idea npm install很慢问题及解决(nodejs)

《ideanpminstall很慢问题及解决(nodejs)》npm安装速度慢可通过配置国内镜像源(如淘宝)、清理缓存及切换工具解决,建议设置全局镜像(npmconfigsetregistryht... 目录idea npm install很慢(nodejs)配置国内镜像源清理缓存总结idea npm in

pycharm跑python项目易出错的问题总结

《pycharm跑python项目易出错的问题总结》:本文主要介绍pycharm跑python项目易出错问题的相关资料,当你在PyCharm中运行Python程序时遇到报错,可以按照以下步骤进行排... 1. 一定不要在pycharm终端里面创建环境安装别人的项目子模块等,有可能出现的问题就是你不报错都安装

idea突然报错Malformed \uxxxx encoding问题及解决

《idea突然报错Malformeduxxxxencoding问题及解决》Maven项目在切换Git分支时报错,提示project元素为描述符根元素,解决方法:删除Maven仓库中的resolv... 目www.chinasem.cn录问题解决方式总结问题idea 上的 maven China编程项目突然报错,是

Python爬虫HTTPS使用requests,httpx,aiohttp实战中的证书异步等问题

《Python爬虫HTTPS使用requests,httpx,aiohttp实战中的证书异步等问题》在爬虫工程里,“HTTPS”是绕不开的话题,HTTPS为传输加密提供保护,同时也给爬虫带来证书校验、... 目录一、核心问题与优先级检查(先问三件事)二、基础示例:requests 与证书处理三、高并发选型:

前端导出Excel文件出现乱码或文件损坏问题的解决办法

《前端导出Excel文件出现乱码或文件损坏问题的解决办法》在现代网页应用程序中,前端有时需要与后端进行数据交互,包括下载文件,:本文主要介绍前端导出Excel文件出现乱码或文件损坏问题的解决办法,... 目录1. 检查后端返回的数据格式2. 前端正确处理二进制数据方案 1:直接下载(推荐)方案 2:手动构造

Python绘制TSP、VRP问题求解结果图全过程

《Python绘制TSP、VRP问题求解结果图全过程》本文介绍用Python绘制TSP和VRP问题的静态与动态结果图,静态图展示路径,动态图通过matplotlib.animation模块实现动画效果... 目录一、静态图二、动态图总结【代码】python绘制TSP、VRP问题求解结果图(包含静态图与动态图

MyBatis/MyBatis-Plus同事务循环调用存储过程获取主键重复问题分析及解决

《MyBatis/MyBatis-Plus同事务循环调用存储过程获取主键重复问题分析及解决》MyBatis默认开启一级缓存,同一事务中循环调用查询方法时会重复使用缓存数据,导致获取的序列主键值均为1,... 目录问题原因解决办法如果是存储过程总结问题myBATis有如下代码获取序列作为主键IdMappe

k8s容器放开锁内存限制问题

《k8s容器放开锁内存限制问题》nccl-test容器运行mpirun时因NCCL_BUFFSIZE过大导致OOM,需通过修改docker服务配置文件,将LimitMEMLOCK设为infinity并... 目录问题问题确认放开容器max locked memory限制总结参考:https://Access

Java中字符编码问题的解决方法详解

《Java中字符编码问题的解决方法详解》在日常Java开发中,字符编码问题是一个非常常见却又特别容易踩坑的地方,这篇文章就带你一步一步看清楚字符编码的来龙去脉,并结合可运行的代码,看看如何在Java项... 目录前言背景:为什么会出现编码问题常见场景分析控制台输出乱码文件读写乱码数据库存取乱码解决方案统一使