SevenLunas

Jiang：之前我想过用分布式的KV存储去替代ethereum节点的KV存储，但是调研之后觉得可能换存储层的收益并不高，节点本身也不支持kv分布式调度，最近想到了能不能把节点的kv存储换成像s3这种kv，如果这样同步下来的话应该会把节点的运维成本降低很多，可能 Node As A Service 真的有可能。比方说我在 s3 上存储了 1-1500w 区块范围的数据，当前区块高度是 1501w，如果 user 申请一个节点，我只需要把 secret key 返回给 user 然后 user 只需要在 user 的本机同步 1w 个区块就可以有一个全节点了。我调研过其实节点的热点层并不在kv层，假如说热点层不在 kv 层，那么 s3 的 qps 限制应该可以完全覆盖 blockchain 的同步需求？

大佬：
具体 KV 层的改造其实我觉得无论是从哪方面来说其实 ROI 都不算高。
社区的链节点，无论是 OP，aurora，还是比如 ftm 这种，他们核心的问题都在于两点：

1. 全新启动节点后的 P2P 速度，这其实是共识层要解决的问题。
2. 快速迭代的导致的硬分叉。
   对于2的场景来说，实际上 S3 无法解决。因为硬分叉的问题在于：
3. 不可预知性。
4. 部分写入数据后导致的底层 block 或者 metadata 的损坏。
   对于2来说，如果不依赖定时的快照，重新追块的的话，那么依赖官方修复工具进行修复，也会存在一定的失败概率。所以即便切换 sk 到新的 S3 也会存在问题。
   另外一方面考虑，刨除 S3 低性能以及带来的流量 NAT 费用来说。你在生产环境下长远来看是不太可能只有一个类型的节点的，为了满足你们数据同步的需求，预执行，transaction trace 都可能成为独立的状态节点。所以从这个角度考虑，即便依赖 S3 ，节点之间的状态同步也会成为问题。
   现阶段如果你们没有遇到 KV 曾的瓶颈的话，改造 ROI 不高。倒是可以把 snapshot 之类的操作，SOP 化和自动化，依托 K8S Operator 等设施尽可能减少人力投入。
   之前说的 热点不在 KV 并不代表着性能不重要。实际上社区许多节点对磁盘性能都有要求。因为很多链底层对于随机读写性能要求都比较高。S3 在这方面实际上还是比较欠缺的。