以太坊2.0致命缺陷

来源：区块链中的那些东西；

比特币减半后，货币界另一件大事正在酝酿，即以太坊将升级换代。在我开始谈论以太坊2.0之前，让我问你一个问题。

如果一家银行的准备金总额为1万元，那么在a、B两个城市分别有一**立的ATM机。一个人在a市的ATM机上取5000元，另一个人在B市的ATM机上取5000元。现在银行里还剩多少钱？

这是一道很简单的数学题。我相信每个人都能给出正确的答案。银行一共拿了1万元，a和B分别拿了5000元，所以总共是1万元。10000-10000=0，所以银行还剩0元。

这个问题对我们来说很简单，但对计算机来说就不那么容易了。例如，我们需要编写一个应用程序来实现上述功能。其难点在于如何保证银行数据在取款过程中实时同步。因为如果不同步，当B操作ATM机时，他读到的准备金可能仍然是10000，而不扣除A取出的5000，这显然是一团糟！我将使用一个jaa程序来模拟它，您将看到。

我们首先定义一个简单的类bank。只有一个自定义变量是balance，它用于引用帐户余额。只有两个操作功能：支取取和查询余额getbalance。

public class Bank{   //银行余额   priate int balance; 
    public Bank(int balance){       this.balance = balance;   } 
    //用户提款   public oid withdraw (int alue)  {       try {           Thread.sleep(300); //0.3秒的模拟时延       } catch (InterruptedException e) {           e.printStackTrace();       }       this.balance -= alue;   } 
    //查询当前余额   public int getBalance(){       return this.balance;   } 
 } 
 

接下来是演示的主要程序：

public class Demo { 
    public static oid main(String args[]) throws InterruptedException {       Bank bank = new Bank(10000); //银行的初始余额       Runnable Atm1 = () -gt; {           bank.withdraw(5000);           System.out.println("A 提款 5000");       }; 
        Runnable Atm2 = () -gt; {           bank.withdraw(5000);           System.out.println("B 提款 5000");       }; 
        Thread A = new Thread(Atm1); //提款人A的操作线程       Thread B = new Thread(Atm2);//提款人B的操作线程       A.start();//A开始提款       B.start();//B开始提款       A.join();//等待A操作结束       B.join();//等待B操作结束 
        //显示余额       System.out.println("银行余额："+bank.getBalance());   }} 
 

在这个程序中，我们将初始余额设置为10000。然后我们模拟了两个操作线程a和B，它们几乎同时提取5000元。让我们看看程序的运行结果：

但问题是B筹到5000后，银行没有余额，所以应该显示0。但还是5000块。这就是问题所在！有趣的是，如果你反复运行这个程序，你会发现每次运行的结果可能不同。有时是0，有时是5000。这种现象在计算机中有一个典的名字叫“种族状况”指存在多个计算机线程争夺同一资源，导致数据更新混乱。在我们的例子中，a和B通过不同的自动柜员机打开两个取款操作线程。两个线程都需要修改银行余额。在这种情况下，B相当于占用a的数据更改权，导致B立即覆盖新更新的数据。

为什么会这样？这是由计算机CPU的特殊结构决定的。计算机的任何指令都需要知道它的操作对象和它的价值。否则，本指令无意义。我在哪里能找到这个接线员？CPU有一个称为寄存器的组件来存储这些信息。任何指令都需要访问这个寄存器来获取其操作对象的值，这样指令才能完全执行。例如，下图中的ax是CPU的寄存器。它可以存储16位二进制数。

在我们的案例中，支取是支取指令，其操作对象是银行余额。这个余额值多少钱？这将在登记册上。

一旦获得这个值，指令就开始执行。在此过程中，它将修改寄存器的内容并更新数据。所以我们的银行结余就是这样更新的。此时，如果有新的指令来获取当前余额，我们可以返回到该寄存器来找到答案。

但问题是，我们的计算机不只是每单位时间执行一个命令。在许多情况下，多个指令同时运行。否则，你怎么能一边上网一边听音乐呢？为了实现并行操作，我们的CPU引入了多线程管理机制。它是将这些指令封装在不同的线程中，通过合理的调度并行运行多个程序。例如，可以使用一个线程执行支取指令，分配另一个线程查询当前余额，如下图所示：

查询操作不会影响寄存器的状态，因此这两个线程是安全的，但是如果此时引入第三个线程来执行撤回操作，将变得非常困难。因为它可能从与线程1相同的寄存器中获取资源。如下图所示，线程1和线程3同时更新寄存器的状态。当线程3执行时，线程1可能还没有更新balance值，因此它读取的值与之前相同，即balance=10000。当线程1完成运行时，尽管余额已更新为5000，但这将不会有帮助，因为线程3已经在运行。所以线程3对寄存器的更新仍然基于旧的值：10000，最终的余额为5000。 ；（10000-5000=5000）

因此为了避免这种情况，我们必须确保这个寄存器的状态在多线程中是同步的。尽管它们都共享同一块数据资源，但必须先到先得。在上述情况下，我们必须确保当线程1操作寄存器时，其他线程无法访问它。线程3只能在线程1完成时操作。这样，每个线程读取的寄存器数据就同步了。

为了实现多线程之间的同步，我们的CPU引入了一种“锁”机制。此共享注册资源将标记为“锁定”状态。任何线程在访问寄存器时都可以“锁定”它。这样，其他线程就无法访问它，只能顺从地等待。在执行当前线程之前，不会释放此“保护锁”然后，其余的线程被自动唤醒以访问注册资源。在我们的例子中，线程1在访问寄存器时可以被“锁定”，线程3将被迫等待。线程1完成执行后，余额将更新为10000-5000=5000。然后寄存器释放保护锁，线程3唤醒以访问平衡变量。同样，它有一个保护锁。此时，它的值为5000。执行后，余额更新为5000-5000=0。具体如下：

相应地，我们的jaa源代码只需要修改如下以实现这种“锁保护”机制：

public class Bank{   //银行余额  priate int balance;  priate final ReentrantLock lock = new ReentrantLock();  …….   //用户提款   public oid withdraw (int alue)  {       lock.lock(); //加上保护锁       try {           Thread.sleep(300); //0.3秒的模拟时延       } catch (InterruptedException e) {           e.printStackTrace();       }       this.balance -= alue;       lock.unlock(); //释放保护锁   }} 
 

操作结果如下：

根据这次操作的结果，您可以看到，在a和B两次提款后，我们的银行余额已正确更新为0。

所以我们可以看到，虽然每个线程是独立的，但是整个线程的调度是中心化的。CPU就像一个大脑。为了保证数据同步，必须合理地分配资源给不同的线程，并安排执行顺序。所以大脑必须知道哪些寄存器被锁定，哪些线程正在访问，哪些线程正在等待。换句话说，它有一个“上帝视角”，可以实时监控每个线程和每个寄存器的状态。

这是一台计算机的程序运行的方式，但是如果我们进行大规模部署，那么多台计算机的节点部署也是如此。拿**来说。以Com为例，double 11的当天，它必须处理数千万个事务请求，因此一个服务器肯定是不够的。它必须部署多个服务器节点，然后通过负载平衡器将这些请求均匀地分布到每个服务器。如下图所示：

但是不管有多少服务器节点，不管有多少请求，它们最终都访问同一个数据库！这很重要。因为只有这样才能引入“保护锁”机制，在事务处理过程中锁定相应的数据库表单，保证读写同步。例如，一家天猫店现在有10个香奈儿包，八折，100人抢购。当第一个人下单并开始交易时，数据库必须将其他购买请求放入等待队列。这样可以确保下一个人看到9个袋子，而不是前10个。

因此，**的节点部署是一个分布式架构，但本质上是中心化式的。这种中心化体现在节点线程的监视和调度以及数据库的解决方案上。也就是说，**服务器后面有一个控制中心，可以实时检测每个节点的状态，这些节点访问同一个数据库。它是一个如此中心化的体系结构，允许如此多的节点并行处理如此多的请求，同时确保数据同步。

但是公链的分布式体系结构是完全不同的，因为它本质上是去中心化的，每个节点都在各自为战。所以它没有控制所有节点状态的控制面板。其次，它没有供这些节点访问的中心化式数据库，但是每个节点都独立地配置了自己的数据库。因此，将同时有多个分类账。我们只能引入投票机制来确定最终的分类账，并间接实现节点之间的同步。比特币通过算力投票选择最长的区块链作为最终分类账。尽管不同的节点会生成多个区块链账本，导致拜占庭将军的问题，比特币的算法仍然有效。因为它是一个单链结构，在单位时间内只能生成一个块。虽然不同的节点可以同时广播块，但是比特币的挖矿机制保证了块的唯一性。因此比特币本质上是一种单线程数据库读写操作。

以太坊没有问题，因为它是一个像比特币一样的单链结构，使用POW共识。但升级到2.0之后，问题将非常大。因为以太坊2.0引入了一种叫做分片的机制。简单来说，就是**的负载均衡机制——设置多个节点，批量处理不同的请求。例如，现在有10000个事务请求。我要求节点a处理5000，节点B处理剩余的5000。那不快。我承认初衷是好的，但事实上它不起作用。根据以太坊2.0的介绍，它首先引入了一个名为beacon的主链，负责记录所有交易的状态，相当于账本的核心。然后将整个节点网络划分为不同的区域，每个区域作为一个分区，相当于负载均衡。每个段处理不同的事务请求，这些请求记录在主链上。如下图所示：

你可能有点困惑，但我会用另一种方式来解释。只要你读了我的介绍，你就应该对多线程同步有一个简单的理解。以太坊2.0是一个类似的架构。您可以将beacon链理解为一个中心数据库，每个片段相当于一个独立的线程。每个线程广播的块是不同的。例如，段1的块中包含的事务序列是1到3000，段2的块中包含的事务序列是3000到6000。所以以太坊2.0相当于一个多线程数据库读写操作。这与比特币有本质区别。

如果多个线程在同一个数据库上操作，则很容易出现数据异步问题。因此，正确的方法是在每个线程执行期间向数据库添加一个保护锁，以避免其他线程同时访问。所以我们也是这样。当每个分区更新信标链时，必须在主链中添加“保护锁”，以强制其他分区进入等待队列。神五确实考虑到了这一点，并准备引入“保护锁”机制。但错误的是，这个信标链并不是唯一的中央数据库。

我们需要知道以太坊是公链，公链是去中心化的！所以每个挖矿节点都有自己的信标链。所以这里的“锁”就是添加到你的信标链上的锁。显然，这个锁的状态与其他节点不同步，因此其他分片节点将继续访问主链。此时，我之前说过的比赛条件将在不同的片段之间生成。碎片1的更新可能被碎片2覆盖。如下图所示：

由此可见，去中心化体系结构中的保护锁无疑是一个虚拟锁。而以太坊2.0也允许片之间的读写操作，这将暴露出同样的多线程同步问题。

然后有人可能会问，我们能把这个信标链的锁定状态同步到其他碎片吗？这是一个投票的问题。因为如果每个节点都是从自己的角度来看的，那么它看到的主链状态是不同的。例如，上图中的节点1锁定了自己记录的主链，但节点2不这么认为。因为它没看到锁。所以节点1认为有锁，而节点2认为没有锁。拜占庭的普遍问题再次出现，因此只能通过投票来决定。但以太坊2.0使用的是POS，而POS已经不再是POW了，所以你选择最长链的共识毫无意义。因为分块生产没有成本，只要做好记账，就可以一次广播多个分块，所以最长的链条不能代表最一致的意见。此时，选票统计将变得更加复杂。即使协商一致算法能够正确计算投票数并确定节点1获胜，也意味着段2的块将同时被丢弃。此时分割的意义何在？如果要保留分区2块，则必须将此线程放入等待队列。但问题是，您没有与控制面板相同的东西，它可以全局分配不同线程的资源。你甚至不知道每个线程的状态。那么，这是不是又回到了过去的集权方式？

基于以上分析，我可以得出结论，以太坊2.0上线后，会出现很多数据同步问题。不仅切片不同步，而且每个节点的信标链也不同步。这家公共公链不同于**网。如果**有数据同步问题，我最多可以修改数据库或者重启服务器。但公链上的不同步会导致矿工阵营的分裂和分歧，这是一个非常严重的问题。