使用 Basil 去中心化数据库

使用区块链构建应用程序

区块链的承诺很简单，但功能强大：提供完全有序的日志（或统一的状态机）的抽象，该日志分布在一组参与者中，并且对篡改保持稳健。

这种完全有序的日志抽象保证了参与的每一方将看到 i) 相同的一组操作，并且 ii) 将以相同的顺序看到这些操作。考虑下面的简单资产转移示例：Alice 和 Bob 分别有两次存款，然后是从 Bob 转移到 Alice，最后是 Alice 提款。每个操作都记录在一个完全有序的日志中，由一个（可能相互不信任的）银行联盟维护。

实现共享日志的简单银行联盟。

然后可以轻松地使用生成的共享日志来实现共享状态，其有效性得到所有联盟参与者的证明。Bob 可以在 BoA 查询状态，而 Alice 是 Chase 的客户，但他们仍然保证同意。到目前为止，一切都很好！

走向交易系统

虽然完全有序日志抽象的推理很简单，但遗憾的是它不能满足大多数传统 Web 服务应用程序的实际需求。一个简单的日志可能足以满足上述基本资产转移，但（就其本身而言）无法满足更复杂的在线交易处理 (OLTP) 风格的应用程序，例如在线供应商、（成熟的）在线银行或多航空公司/酒店预订。从广义上讲，造成这种情况的原因有两个：

原始日志可扩展性。

应用程序希望他们的数据库快速。当请求不在同一数据上竞争时，它们应该水平扩展，否则优雅地降级。通常，数据库通过依赖分片、可序列化和并发控制来做到这一点。

相反，我们完全有序的日志抽象的现有实现通常采用分布式和复制状态机 (RSM) 的形式，它可以容忍一部分节点任意行为不端（我们说，它是拜占庭容错- 或简称 BFT）。有很多很酷的协议可以解决这个问题，尽管最流行的协议（在许可空间中）是PBFT (OSDI'99) 和Hotstuff (PODC'19)。这些来自许多 fotm 改编，尽管通常都有相同的缺点：

一方面，每个副本完全对每个操作进行排序，然后按顺序执行——显然，这对于扩展吞吐量来说并不理想。

其次，他们依赖专门的领导者（通常是单个领导者）充当排序器，这既是瓶颈又是公平问题——（A）领导者必须接收、处理和转发所有事务，以及（B）它具有不成比例的影响过度订购，并可能“意外”审查交易，或抢先获得财务优势。

最后，这些协议需要几个阶段来安全地提交每个操作，与通常部署的崩溃容错系统相比，延迟明显更高……

好的——此时你可能会问“你是不是简化太多了？我们知道如何以更优化的方式构建我们的系统！”当然，你是对的——为了改善可扩展性瓶颈，我们投入了大量精力来仔细调整这些共识协议——直到我们能够每秒订购100 或 1000 次额外的（虚拟）操作。

虚拟操作的高排序速度并不是高应用速度的决定性因素。

不幸的是，可扩展性只是故事的一半。同样重要的是可编程性和可用性：

可用性和应用程序可扩展性。

通常容易被搁置的问题是我们真正想要订购的操作是什么？

答案相当简单。当今世界已经使用传统数据库系统构建的应用程序希望继续使用数据库。

应用程序可能会寻求许可的区块链来实现去中心化的分布式数据库的功能。

不幸的是，现有的数据库不是去中心化的，对攻击或不诚实的一方也不健壮。那么我们能做些什么来弥补这个差距呢？为了采用我们很酷的 BFT 工作，应用程序想要（和需要）我们什么？

1.应用程序需要事务和查询功能。它们必须能够将操作组捆绑在一起，并以原子方式执行它们。这样做极大地简化了应用程序开发和无错误（不变安全）代码的设计。此外，应用程序还希望能够执行查询以有效地计算过度状态。许多人使用 SQL 这样做，并且不愿意（或不能）放弃大量遗留代码。