区块链statedb数据膨胀怎么办？分片和状态租金的解决思路

导读： 说实在的，区块链statedb跟那种专门用来记录总账的本子没啥两样。每一笔交易发生过后，账户上谁持有多少资金，还有合约呈现出何种状态等这些信息，都得在这个本子上做相应的改动与更新。...

说实在的，区块链statedb跟那种专门用来记录总账的本子没啥两样。每一笔交易发生过后，账户上谁持有多少资金，还有合约呈现出何种状态等这些信息，都得在这个本子上做相应的改动与更新。

这个物品所呈现出的样子看起来较简易，然而在实际运用它的时候却令人头疼不已，数据以很快的速度不断上涨，各个节点根本承受不住呀。

数据膨胀是个老难题。

你想想，每个区块都往账本里塞东西，几年下来就是座大山。

新节点同步数据得花好几天，普通电脑硬盘根本装不下。

存在一些链尝试过状态剪枝，将老树枝进行砍伐，仅仅留下树根，然而在操作的时候必须要格外小心，千万不要把重要数据错误删除了。

解决的思路是什么呢，有的人想到了采用搞分片的方式， 把那规模巨大极为庞大的账本拆分成一本一本彼此分开的小册子，进而进行分开来记录；另外还有人在思考琢磨状态租金这一想法思路，觉得只要占据着相应的位置，就必须得缴纳“存储费”，凭借这么做来迫使逼迫用户清理那些没有用处无用的数据。

我曾试着运用默克尔树的变体，处于实际操作进程里发现，在需要修饰一部分数据之际，单单只需变动几个分支就能成就操作。和之前运用的别的方法相比，如此这般的操作令同步速率大幅提高，快了好多。然而，与此同时，整个系统的复杂性跟着也提升了。

往后有可能要踏上无状态的路径，验证者无需存有完全的状态，凭借证明去开展工作。

这仿佛是，你无需将整本字典都背下来，然而有人向你询问某个字时，你能够马上翻到，并且证实它就在那里。

不过这么搞，证明生成和验证的开销又成了新问题，平衡点难找。

你们在项目里咋处理状态膨胀的？

有啥野路子不妨聊聊。