Thoughts on a unified smart contract

[hmrtn]

Huxwell, Swapp, and I were discussing a unified contract that could potentially support all the current implementations of quadratic diplomacy.

A singular contract with event-helpers could be used for the event-driven, on-chain, cermaic/db, metatxs, signature-based(?), etc. The only difference between the versions would be the usage on the front-end calls to the contract protocol. Because both major versions of the quadratic diplomacy contracts effectively play the same role, it may be possible to reduce them to a common form. We could probably achieve this by being specific about event emissions.

For example, the contract could look something like:

contract quadratic_diplomacy {
  Election struct { ... }; 

  event ElectionCreatedEvent();
  event voteCastEvent();
  
  function emitElectionCreatedHelper() pure {
    emit ElectionCreatedEvent();
  }

  function emitVoteCastHelper() pure {
    emit voteCastEvent();
  }

  function createElection() public {
    // election logic
    emitElectionCreatedHelper();
  }

  function castVote() public {
    // vote logic
    emitVoteCastHelper(...);
  }
}

And depending on the version implementation:

for on-chain, we'd use the castVote function to write the data to the chain. Something like:

  const createChainElection = async () => {
    // Create a new election
    const result = tx(
      writeContracts.CONTRACT.castVote( ... election metadata ... )
    );
  };

and for event-driven, we'd just call the event-helper when casting a vote

  const createEventElection = async () => {
    // Create a new election
    const result = tx(
      writeContracts.CONTRACT.emitCastVoteHelper(...);
    );
  };

And so on...

What does this do?

This approach could offer a flexible way to construct applications based upon the contract limitations. This would reduce the # of deployments necessary, focus more eye balls on the contract code, and (as far as I'm aware ;)) still offer the same utility the different versions of the contract offer. With a unified rock-solid contract, we could deploy all the separate versions. Then using some form of metrics, decide if/which version(s) we should focus on supporting in the future.

Cons:

• Would require all versions to support at least some consistent notions, i.e. an "election" (maybe?)
• Would be more difficult to update the contract and subsequent front-ends
• Probably other stuff, idk please let me know if you think of any

Anyway, thought I'd throw this idea out in the wild and get everyone's input on the matter. Please comment and share what you think!

[damianmarti]

I like the idea to have a unified contract.

When a new election is created must have a kind attribute, that set how the votes must be done (on chain, events, signed, etc).

[Cali93]

I love this idea!

It's amazing because we can even emit events for the on-chain version by calling the helpers at the end.
So that we can create a subgraph that will gather election and voting data over time, which will be used in charts and what not.
💹 🚀