杂记 去中心化系统介绍

一、去中心化系统概述

        去中心化系统（Decentralized System）是一类没有任何中央协调或管理单元的系统。换句话说，没有一个单一的中央服务器来协调或管理系统。与集中式系统相比，分散式系统既有优点也有缺点，因此您为系统选择这两种拓扑原型中的哪一种取决于您需要或想要的优点中的哪一种。

        去中心化系统可以分为两类：

        分散式服务器系统

        对等 (P2P) 系统

二、分散式服务器系统

分散式服务器系统是客户端-服务器系统的服务器端分散的系统。例如，去中心化数据库，如 Cassandra 或 MongoDB。

分散式服务器系统通常仅分散整个系统的服务器部分。整体架构仍然是客户端-服务器架构——系统中的一些节点是客户端，而其他节点是服务器。

        分散式服务器系统的示例有：

        Apache Cassandra

        MongoDB

        Amazon DynamoDB 

三、对等系统

        对等系统 (P2P)，有时也称为对等网络，是网络中的所有节点既是客户端又是服务器的系统。每个节点（对等点）既作为服务器向其他节点（对等点）提供服务，又作为客户端从其他节点使用该服务。因此，对等系统中的所有节点都是彼此的对等节点——意味着功能和角色相同。下图显示了一个完全去中心化的系统，其中所有节点都具有相同级别的功能和权限。这就是为什么他们经常被称为同伴——彼此平等。

         P2P 网络和 P2P 网络算法和拓扑的示例有：

        Chord (algorithm)

        Kademlia (algorithm)

        Polymorph polyring (algorithm)

        Dandelion - 目标是提供强大的、可证明的匿名性保证。

        Gnutella - 一种文件共享协议，它定义了分布式节点通过对等 (P2P) 网络进行通信的方式。

四、区块链系统

        比特币、以太坊、LBRY 等区块链系统也使用 P2P 网络进行通信和协作。他们这样做是因为区块链系统（如数据库）保持分布式状态，因此区块链系统中的节点需要就该状态是什么达成共识。

        注意：一些区块链系统的节点并不都执行完全相同的工作/角色。例如，一些节点是“验证者节点”，而其他节点是“钱包节点”等。这样的区块链系统可能被归类为去中心化服务器系统，而不是纯粹的 P2P 系统。然而，重要的不是你给给定区块链系统的分类。重要的是你了解它是如何工作的。

五、去中心化系统的好处

        与集中式系统相比，分散式系统可以有一些好处——取决于这些分散式系统的设计方式。

        更大的d性

        一个设计良好的去中心化系统可以比中心化系统具有更大的d性，因为去中心化系统没有可以导致整个系统崩溃的单点故障。如果去中心化系统中的一个节点崩溃，系统中的其他节点可以接管。

        水平可扩展性

        一个设计良好的去中心化系统通常可以很好地水平扩展——这意味着通过向网络添加更多节点（计算机）来扩展，而不是让每个节点使用更强大的硬件（垂直扩展）。

        降低硬件成本

        P2P 网络有时可以直接在最终用户设备（计算机、电话、控制台等）上独占运行。在这些情况下，最终用户正在贡献运行系统所需的硬件。因此，创建 P2P 网络的软件的创建者可以节省大量的硬件成本。他们很可能无法实现零硬件成本——但可能比他们必须为运行系统所用的所有硬件付费的情况要少得多。

六、去中心化系统挑战

        在去中心化系统中实现某些类型的功能比在集中式系统中更具挑战性。

        去中心化共识

        去中心化系统的最大挑战之一是就共享状态达成共识——如果系统中的多个节点可以启动对该状态的更改。“状态”通常是指存储在与数据库（即分散式数据库）相对应的数据中的一些数据。

        如果去中心化系统中的两个或多个节点都试图改变同一个逻辑对象的状态，那么系统需要以某种方式确定应该以什么顺序应用状态改变。

        想象一下，如果系统中的两个节点都想在共享状态下更改同一“客户”的“名称”。如果第一个节点想要将名称更改为“Satoshi”，而第二个节点想要将名称更改为“Vitalik” - 客户最终会使用哪个名称？这种情况如下所示：

         去中心化共识，有时也称为分布式共识，是一个广泛的话题，并且有几种不同的方法来实现它。

        广播、组播、路由和查找

        根据分散系统的拓扑结构，向网络中的所有节点或节点的子集有效和高效地广播或多播消息可能具有挑战性。实际上，我的意思是确保所有预期的节点都实际接收到消息。高效我的意思是没有节点不止一次地接收消息。一些分散式广播的模型可能能够保证一个但不能保证另一个。

        在系统中执行有效的消息路由和节点或数据查找时也存在类似问题。您如何有效地发现系统中还有哪些其他节点？如果该对象仅存储在系统中的一个节点上，您如何有效地查找该对象的位置？

        分散系统使用的拓扑对这些问题有很大影响。您可能必须设计系统的拓扑以满足您的特定需求，而不是为所有用例使用相同的通用拓扑。