前言

本文是本人在毕业论文研究期间，对2021至2022两年内发生的、与合约漏洞相关的重大跨链桥攻击事件的分析。主要分析这些事件中的攻击流程和漏洞利用细节。

前言

此前区块链实习时，接触的数据库，碍于2023年事情较多，一直未总结。

本文将整理LevelDB相关知识，并进行总结。

概述

在区块链中，谈到数据库就不得不提LevelDB，比特币、以太坊等都使用LevelDB作为底层数据库。

LevelDB的前身是Google的Bigtable——大数据三驾马车之一。Bigtable由Google在2006发表的Bigtable: A Distributed Storage System for Structured Data论文中提出，是一个分布式的高性能KV数据库，但Bigtable的具体实现并未开源。LevelDB可以看作单机版的Bigtable，它由Bigtable的作者共同完成，并被Google开源。

LevelDB是一个单机KV数据库，采用LSM(Log Structured Merge)结构，具有很高的写性能和较高的读性能，适用于写多读少的情况。LSM的基本思想是：顺序写代替随机写、延时进行归并处理。

0. 前言

实习期间，去年年末调研的一个跨链项目。由于焦虑着毕业论文，一直拖着没更新到博客上，今天一时兴起打算先把这篇更新了。我本人比较看好这个项目，也在此介绍给大家。

1. 项目调研

1.1. 团队介绍

0. 前言

MIT6.824 LEC13 Spanner

Spanner由谷歌2012年的论文《Spanner: Google’s Globally-Distributed Database》提出，是谷歌的一个全球级别的分布式数据库。它管理着全球成百上千个数据中心，数百万个服务器，将数万亿数据分片存储到这些服务器上。同时，它支持以下特性：

1. 支持高可用（数据的备份和恢复）。数据可以有多个备份副本，并且可以灵活、细粒度地配置：副本数量、副本所在的数据中心等。副本甚至可以跨国家存储，即使面临大范围自然灾害，数据依旧可用。

2. 同时，Spanner保证这些副本的外部一致性（谷歌创造出来的一种一致性）。

3. 支持广域的分布式事务，对于涉及不同数据中心的事务，也能保证ACID特性。

Spanner如何保证这些特性呢？具体内容请看下文。

0. 前言

MIT6.824 LEC12: Frangipani

《Frangipani: A Scalable Distributed File System》是1997年发表的一篇论文，年代较为久远，但其中关于缓存一致性(cache coherence)、分布式事务(distributed transactions)、分布式故障恢复(distributed crash recovery)的设计思想，依旧值得我们学习。

Frangipani可以看作是一个分布式文件系统，它为上层应用提供文件系统的接口。

0. 前言

一台服务器的读写性能有限，当数据量过大时，我们需要将数据分割到不同的服务器上，从而使系统能够并行处理客户请求，提高系统整体性能。但这又引出新的问题：分布式事务(Distributed Transactions) 。

举个例子：一家银行将北京用户的数据存放在北京的服务器中，将上海用户的数据存储在上海的服务器中。此时，一个北京的用户A向上海的用户B汇款100元。按照正常流程，需要同时进行2个操作：到北京服务器中将用户A的余额-100，到上海服务器中将用户B的余额+100。但是，分布式网络充满复杂性，如果北京服务器操作完之后，上海服务器宕机了，那用户A的余额-100，而用户B的余额并没有+100。或者，北京服务器执行操作出错了，因为用户A余额并不够100，而上海服务器执行操作成功，用户B余额+100。不管是哪种结果，这肯定是不符合预期的，系统应该保证2个操作都成功或都失败。而这就是分布式事务所要解决的问题之一。

0. 前言

MIT6.824 LEC10

为了容错，我们需要对数据进行备份。而当数据有多个备份副本之后，我们又需要保证各副本的一致性，即需要将状态（数据）同步到各个副本。

常见的一致性算法，比如raft，都采用主从拓扑结构。这种结构下，主节点接收读写请求，并负责将状态同步到所有备份节点。主节点负载较高，系统整体性能将受限于主节点。当然，也可以与Zookeeper一样，舍弃强一致性（线性一致性），将读请求分摊给备份节点。

而链式复制(CR, Chain Replication)采用链式拓扑结构，不选择主节点，每个节点只需将状态同步到下一个节点。CRAQ是基于CR的改进，它允许从任意副本中读数据，同时还保证线性一致性。

0 前言

实习期间调研的公链跨链项目THORChain——一个去中心化跨链流动性网络，类似于Layer1 Uniswap，分享给大家。

0. 前言

MIT6.824 LEC9: Zookeeper。

当单机性能到达瓶颈时，我们需要对应用服务进行横向扩展，将同一个应用部署到多台服务器上，以提高整体性能。但新的解决方法总会带来新的问题：应用的配置（比如数据库连接、地址黑名单）需要更新时，如何进行统一更新？当多个应用对同一个外部资源进行修改时，如何保证同步互斥？为了解决这些问题，就有了Zookeeper的出现。

Zookeeper是大数据组件中的一员，由于它起到协调管理的作用，而其它大数据组件大多以动物名字命名，因此它就被称为动物园管理员。

Zookeeper是一个提供分布式协调的中心化服务，官网中的一句话介绍了Zookeeper的主要功能：配置管理、命名服务（类似于DNS）、分布式同步（分布式锁）和集群管理（集群节点的加入与退出）。

ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.

接下来将结合Zookeeper论文来学习它的具体设计与实现。

0. 前言

VMware公司在2010年发表了一篇有关虚拟机容错的论文：《The Design of a Practical System for Fault-Tolerant Virtual Machines》。同时，它也是MIT6.824 LEC4的Preparation Read。本文将结合课程简单介绍论文内容。