# xxxxx

**Repository Path**: kt10/xxxxx

## Basic Information

- **Project Name**: xxxxx
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2021-05-09
- **Last Updated**: 2021-11-30

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 范辉: 关于 Storage Layer 方案和现状的见解

> 声明：本文基于客观事实进行论述，不做任何的意气之争，若有表述偏差，敬请指正。

从如下几个方面展开阐述:

- 必要性
- 可靠性
- 兼容性

## 必要性

storage layer 方案的设计思路，是对状态类数据的存储方式，进行统一的抽象。

这有助于项目逻辑的解耦，对项目的规范性和后续的开发效率，也会有积极的推动作用。

若能完善的实施，将带来较大的实际效益，从长期来看，具备较大的必要性。

## 可靠性

从如下几个方面展开阐述:

- 业界先例
- 设计方案的成熟度
- 业务层框架的成熟度
- 第三方依赖库的成熟度

#### 业界先例

基于 AVL 变种的 merkle 存储方案，业界已有先例，如 COSMOS 生态的 iAVL 等。

故可认为这个技术方向的可行性，已得至充分的证明，具备典型的、可借鉴的业界先例。

#### 设计方案的成熟度

详情参见 Google Doc: [设计文档 by Tanmay](https://docs.google.com/document/d/1Bt0mQCubxAHz9q9UFAQa5nvPORHXVLjNuiv0iwbWiQo/edit#heading=h.fjjig2ero9if)

此文档对 storage layer 的实现进行了粗粒度的描述，基本展示出了其设计意图。

但也存在如下问题:

- 无相关的逻辑流程图(宏观的和局部的都没有)，难以直观的论证其设计的完备性
- 行文较粗糙，基本处于草稿状态，距离一篇完备且严谨的设计文档，还有较大的差距

综上，观其目前的状态，做为一个定位为“核心”的基础组件，该设计方案远未成熟，继而可认为，基于此方案实现的代码逻辑，在宏观层面上也必然处于不稳定状态。

#### 业务层框架的可靠性

业务层框架代码，已基本实现其设计方案的意图，即 API 接口。

作为一个核心基础库的角色，认为如下方面仍需完善:

- 代码质量有较大的优化空间
- 说明文档及代码注释等不完备
- 测试覆盖率、性能测试结果等未呈现

#### 第三方依赖库的成熟度

目前的 storage layer 用的基础库是 nomic-io/merk，这个第三方库，其质量无法保证:

- 这个库的核心数据结构是作者自己造的新轮子(AVL新变种)，并无配套的学术论证，潜在风险较大
- 其在 crate.io 上发布的时间已有三年，被外界其它库引用的次数为零(不包括作者自产自销的那个记录)
- 三年总计下载量只有两千多，很明显，这些记录是在作者自己调试编译的过程中产生的，并没有实际的用户
  - 在 crate.io 上发布过自己的 crate 的工程师很容易理解这一点
- 综观其 Github 代码提交记录，基本上只有原作者(mappum)一个人在维护，并无其它的实质贡献者
  - 甚至连 issue 也都是作者自己提的，而且内容比较混乱

总结来说，就是: 既无完备的理论支持，也没有在正式的生产环境中被验证过，就连在个人层面的粗浅验证也不充分。

## 兼容性

从如下几个方面展开阐述:

- 后向兼容
- 前向兼容

#### 后向兼容

针对主网已产生的历史数据，兼容机制尚不完备。

因此，此方案目前尚无法保证历史数据的一致性和安全性(要达到这一点，需要很严格的测试，也就需要很长的时间)。

#### 前向兼容

- 业务层的整合和规划尚不明确，如: 
  - 原有业务逻辑的整体移植，如何保证完整性、安全性等方面
  - key prefix 的分配和管理规则，用于避免后续的混乱分配现象等
  - ...
- 统一的抽象层带来其优点的同时，也限制了未来的灵活性和可扩展性，需要慎重的权衡

这些工作都很琐碎而耗时，若仓促上线，非但不能为将来节省成本，反本会增加成本。

## 总结

总体来说，认为:

- 这是一个很好的研究方向，具备较高的可行性和实用价值
- 但该方案目前的状态，远未成熟，不应该仓促上线
  - 若因此而 block 其它所有的开发进度，将是对公司利益的一种巨大伤害
  - 将来待其真正成熟以后，再稳步上线，是一种更明智的选择

> **只要我们有能力安然度过每一个今天，那么我们必然能迎来美丽的明天，因为明天的今天，就是明天，这才是务实的生存之道。**