签名的提案和投票信息被发送到 Snapshot 中心，然后该中心将它们上传到 IPFS 进行分布式存储。此外，中心在数据库中也存储了所有提案及其投票的 IPFS 索引信息，以便满足客户端快速加载的请求。

用于计算提案投票结果的方法叫策略（Strategies ）。策略是 web 界面中的 JavaScript 函数，它会返回一组地址的得分。默认的策略是为投票人计算提案项目的 ERC20 代币在区块链中的余额。在链下执行这些计算实际上为试验不同的治理模型提供了更大的灵活性，因为使用 JavaScript 策略进行迭代比使用链上智能合约更快。

去中心化挑战

在 DeFi 治理过程中，链下信息传递正在成为链上投票的前提。链上投票越来越不可信，也更分散，昂贵且效率低。信息传递则是有效的练下投票，是免费且快速的。然而，由于练下交易的中介特性，这种操作势必会削弱去中心化。

如果这些挑战能够得到充分解决，我们就可以在不损害链上执行的去中心化特性的情况下，从免费、快速和不断增加的 (更低的交易摩擦) 链下投票中显著受益。我们目前可以以 Snapshot 为蓝本进行研究。

就现在的 Snapshot 而言，如果有提议和投票必须转化为具有约束力的链上治理，那么它们将取决于两个中介 :

可信多重签名：回想一下，多重签名钱包最初 (在以太坊上) 出现在智能合约钱包账户中，它通过强制执行最少签名数 (m-of-n) 来执行钱包交易。在 DeFi 项目的环境中，受信任的多重签名往往来自于社区中一组受人尊敬的成员，他们被委托通过签署与提案的得票相对应的链上治理交易，来执行项目的决策（投票)。这些决策可能关乎财务、交易或合约协议的修改。

从社会化技术的角度来看，可信的多重签名却有中心化的风险。虽然多重签名权力的持有者不太可能做出偏离社区主旋的决定。但理论上，他们可能会推翻和滥用他们的权力。m-of-n 串通的概率很低 (如果 m 足够大，例如 6-of-9)，但不为零。相比之下，根据项目社区的规模和代币分布，可以设定一个数量级 (例如 100 个)，要求持有特定数量以上的代币持有者来才能共通决策提案结果。

综上所述，其实如果我们能够探索出一种非授信的方式，将批准权从链下投票转移到链上，就可以防止这种去中心化的稀释。

中心化 Hub：Snapshot Hub 是一个服务器，它的 web 界面用来存储和检索与提案和投票对应的 IPFS 签名信息。这显然有一种中心化风险，虽然可能会被削弱。例如，通过运行一个由参与项目管理的服务器联盟，客户端-服务器范式固有地削弱了去中心化，并增加了与点对点 (p2p) 网络相比的监督潜力。

这也许可以通过用 p2p 网络或某种方式把存储 / 检索提案直接从 IPFS 中完全删除来解决。人们目前认为后一种选择可能性大，方法是将相关的 IPFS hash 值连接在一起，但这样做的话检索的顺序性可能使它的效率变得缓慢和不切实际。 (责任编辑：admin)