投票有什么流程？

ChronoBank 开发团队解释他们如何减少投票活动的开支并部署投票合约

ChronoMint一部分功能是创建投票的功能。该功能对生态系统的核心战略决策是一个必要的工具。区块链上创建的投票应符合以下要求：

安全性

可靠性

投票操作价格（创建、投票活动、结束）

创建理想投票子系统的第一步是设计一些合约（我们称之为“经理”），这些合约将控制所有投票和管理工作。 值得注意的是，为各种经理保存数据都使用特殊的StorageManager合约 。

📌 StorageManager 能允许或禁止储存区访问。

回到投票中，我们说这些合约将有共同的存储空间，并且可以访问共享变量。一方面，这样可以将投票过程分成几个功能合约（获取细节、投票本身、管理投票的数据），并将大规模代码分成几个较小的合约。另一方面，这个诀窍绑定所有智能合约并在它们之间共享状态。以正确的方式进行修改越来越难。除了上述缺点之外，这种实现方式的进行投票价格较高，并且应该存储大量的统计数据。所有这些都不是我们期望的投票结果。我们希望用户成为生态系统的一部分，容易和全面参与其生活。

使用以前投票实现方式一些操作的gas价格：

投票创建：787111

投票： 411641

投票关闭 ：482976

投票删除： 95073

您可以见到，这些数字并不是最好的，我们还有很大的改进空间。。。

迈向新的投票，我们决定使用另外一个方式。我们仍然有一个管理合约 (VotingsManager)。在系统中创建投票和获得基本信息，仍然是任何决定使用投票的用户的入口点。但最令人兴奋的是接下来的一部分：不是将所有投票存在一组属性共享存储，而是为每个投票创建一个全新的智能合约。

📌这一举措将使我们能够对许多逻辑重构为单独的合约，简化合约并使我们的意图更清晰。

让我们困惑的是，每次我们创建新合约开始一项投票时，部署合约需要比以前的实现更多的 gas（因为这个全新合约中有相当多的逻辑和代码）。

我们关于这种问题的决定是将所有这些逻辑重构为单实例合约（我们称之为后端 (backend) ），一次将部署，并且在投票创建期间创建新的代理合约 (proxy contract) 而不是全功能投票合约。

创建的代理合约将具有后端合约地址，并将所有调用重定向到该实例。使用_delegatecall_汇编指令可以很容易地实现代理合约，该指令在调用方合约（即代理）的上下文内执行委托函数，读写操作将使它们的值与上下文相关联。尽管所有这些优点，没有额外的特定和字母代码，我们就无法从_delegatecall_中返回多个值，所以我们就应该在代理合约中实现我们的多重返回功能。由于Byzantium更新，增加了非常方便和有用的 _returndatasize_和_returndatacopy_汇编指令。 这些指令返回委托函数的返回数据的大小并把返回数据复制到内存中。 现在我们可以为它们找到应用的好地方　——　就在我们的代理合约中使用它们，并从任何具体的后端功能中清除代码。 之后，每次创建新投票时我们将有一个合约，并且部署几乎空白的合约需要少量gas。

上述改变情况下的gas价格：

投票创建：849476

投票： 159331

投票关闭：443473

投票删除： 56486

根据您所看到的，我们在把执行投票操作的所有支出几乎减少了三倍，这为用户节省大量资源。是的，我们投票价格搞一些了，但对于减少 “投票” 行动来说，这是一个可以接受的价格。 其他功能，如投票关闭和删除也显示gas体消耗的减少。

投票子系统部署：

v.1: 3089834 + 3789833 + 2891094 = 9.770.761

v.2: 2440890 + 586243 + 3014376 = 6.041.509