🚨SonicDB 是区块链状态访问的革命吗？ 💡零读放大 ⚡️比 Geth 快 6 倍 💼直接二进制存储 但它到底是如何工作的？👇👇👇 读放大一直是效率的瓶颈。 ➡️读放大问题 - 瓶颈 ➡️SonicDB 的工作原理 ➡️与 Geth 的区别 ➡️性能 Sonic 正在为区块链数据性能设定新标准。 读放大问题：（普通区块链） ➡️每个区块链数据库中的隐藏瓶颈 普通区块链数据库（LevelDB/RocksDB）在基于默克尔树的键值存储之上层叠了默克尔-帕特里夏树（MPT）。 ➡️这造成了读放大问题，MPT 需要多对数查找，导致访问时间较差。 ➡️对于 TB 级的数据，这会减慢数据结构中的查找速度。 SonicDB 的工作原理： ➡️SonicDB 将账户、余额、随机数和所有智能合约数据存储在二进制文件中，绕过键值存储。 ➡️直接将二进制数据索引到常量时间 MPT 节点访问，这减少了复杂性。 ➡️双重结构 1）内存中的 MPT（蓝色）用于快速哈希计算 2）磁盘上的二进制文件（绿色）用于直接节点索引 节点保持固定，空间被池化以供重用，新节点附加到文件末尾，避免了昂贵的重组。 与 Geth 的区别： ➡️LevelDB 在读放大方面非常有限（瓶颈） ➡️SonicDB 通过在二进制文件上构建 MPT 来消除键值存储的开销，从而实现常量时间节点访问。 ➡️SonicDB 避免了不必要的范围查询支持，针对区块链特定需求进行了优化。 性能： ➡️SonicDB 以 1,300 MGas/s 处理了 1100 万个 Sonic 主网区块 ➡️比 Geth 快 6.2 倍 ➡️随着 SonicDB 的增长，其高效的系统将会闪耀，从而实现更高的吞吐量。 Sonic 进行了区块链特定的升级，提升了性能并为存储优化留出了更多空间。@DrSonicScholz 正在创新区块链数据库。