Election Dapp Architecture (Factory & Upgradeable)

General
1

Hi Everyone,

I trust you are all well.

I’m working on an election dapp using ERC1155 tokens as the votes. I’ve recently transitioned from working on the project as a single contract for a single election to thinking about what I need to do to implement a contract factory and proxy contracts to make it upgradeable. As I don’t have the EVM or Yul knowledge to interact directly with the proxy contracts, I plan on using the Truffle plug-in. I’m at the beginning of my journey in understanding how to use that plug-in.

However, before I go to deep into the proxy contract area, I wanted to share what I think the architecture will be and see if anyone had any thoughts. I’ve copied a diagram below of what I think it will look like.

Election Dapp Architecture

So, the Dapp will allow users to go through the proxy contract to interact with the election factory. The user will input information about number of offices and candidates and the factory will create a new instance of the election contract. The election contract (the diamond shape) is available to the factory contract. These created contracts will contain the state variables related to the candidates and tokens for that particular election.

Those created contracts will point towards an already implemented logic contract that will control contract state (election not started, started, ended), how tokens (votes) are transferred between accounts, how tokens are minted, and events.

So, as the created elections have finite lifetimes, I don’t need to upgrade those contracts. When the election is over, it’s over. I can upgrade future elections by simply changing the election.sol file that is available to the factory contract. So, I can upgrade the factory contract by simply deploying a new factory contract and having the proxy contract point at it.

I suppose I’m not clear on how I get the created contracts to point at the logic contract. If that’s something that I can easily do when creating them from the factory contract, then I don’t need to upgrade the implemented logic contract, I just need to deploy a new logic contract and upgrade the factory contract to point at it.

Does anyone have any advice or comments on getting created contracts from a factory to point at an already implemented logic contract? Any advice on the architecture in general?

Please feel free to flay me alive and don’t spare my feelings. Thanks in advance for any input. Cheers.

Sincerely,
Craig

1 Like
2

Hi Everyone,

Quick update. It occured to me last night that I probably need the candidates/token contract to be a proxy contract. It will hold the state of the candidates and tokens and will need to delegatecall functions in the implemented logic contract.

So, I’ll need a proxy contract between the dapp and the factory contract for upgrading and a proxy contract between the factory and implemented logic contract which will contain the states of the candidates and tokens. Does that sound right?

Also, can a proxy contract be deployed from a contract factory?

I appreciate any advice or comments. Cheers.

Sincerely,
Craig

Election Dapp Architecture (2)

1 Like
3

Hi @cjd9s,

If I recall correctly you are doing onchain voting on a private network so gas fees are less of an issue.

I keep wondering if there are lessons to be learnt from DeFi governance.

Each eligible voter gets one token and then they could vote to elect officers.

I had a quick look at Snapshot off-chain gasless multi-governance client.

https://docs.snapshot.page/