区块链账本怎么归类数据才不乱
从事多年区块链底层开发工作，目睹过众多项目, 因数据分类处于混乱状态, 致使查询效率变得极为低下, 甚至造成系统崩溃的情况。区块链账户数据有别于传统数据库, 在管理方面并不容易, 它不但要确保呈现不可篡改特性, 而且还要支持快速检索功能, 如此一来, 分类方法便成为了最为关键的要点。
账户状态数据怎么区分存储
链上账户相关数据, 其类别实际上确实分成两种, 其中一种类型属于经由存储而并不发生改变的基础性信息, 像地址所具备的余额以及由特定算法得出的nonce值；另外一种类型则是处于不断变化之中的业务表现状态, 类似智能合约里针对广大用户所记录的积分或者资产归属状况。我亲眼目睹过一些团队, 他们将这两种不同类别的数据混同在一起进行存储, 最终导致在每一次展开查询操作的时候, 都必须对全部的数据进行扫描, 由此产生的gas费用高到令人感到十分震惊。
正确的做法是, 将账户基础状态存于世界状态树之中, 采用Merkle Patricia Trie这种结构予以组织, 每个账户对应一个叶子节点, 该叶子节点囊括余额以及代码哈希这些核心字段, 业务状态数据应当按照DApp维度予以分开, 存储至各自的槽位内, 例如, 对于一个DeFi协议的用户抵押数据, 单独开辟一个存储映射, 以用户地址作为键。
实际的项目历程当中, 我常常会目睹有人将所有的事物都一股脑地塞入到一个庞大的映射表格里面。从短期的视角去观察, 这样做看似颇为省事, 然而一旦链上的数据总量有所增加致使更多, 那么遍历所需要耗费的成本将会呈现出指数级别的攀升态势。更为合乎情理的划分方式则是把那些高频查询所涉及的数据以及低频归档所涵盖的数据区分开来, 对于高频的数据采用更为简短的内存路径去实施访问操作, 而对于低频的数据则能够进行压缩之后再予以存储。
交易记录按什么维度归类
相较于账户状态, 交易数据分类无疑更为繁杂, 原因在于每一笔交易极有可能关联多个账户。我向来惯于采用三个维度予以切分, 分别是: 时间维、账户维、业务维。时间维相对而言较易领会, 乃是依照区块高度或者时间戳进行分区, 如此一来, 历史数据便能够径直归档至冷存储。
账户维依照参与方进行归类, 会将每一笔交易分别关联至发送方以及接收方的交易列表当中, 此处存在一个坑, 要是每个账户的交易列表都存储完整数据, 那么存储量将会出现爆炸情况, 我一般仅仅存储交易哈希索引, 而将完整数据统一放置到交易池里。
业务维依照交易类型予以分开, 像是转账以及合约调用, 我于以太坊主网上开展过优化, 将ERC20转账、NFT转移、普通ETH转账各自归入到不一样的分类桶当中, 查询时径直指定业务类型, 便能够越过无关数据, 有个项目如此改动完毕之后, 历史查询速度提高了40倍。
不存银弹于真正的分类方法之中, 需结合你链上业务实际查询模式予以设计, 先找出最为频繁的查询路径, 再反向推导数据应依据何种键值进行分片, 如此这般设计而成的分类体系, 方可于不可篡改的约束条件下, 使数据既具备安全性又拥有实用性。
TAG: TP下载安卓最新版本