The intent from the beginning was to build the independence of the Eden community. Many design decisions have been made to expand the independence of the communities that use EdenOS. While for reasons of expediency, we've had to delay some of those decisions, we have made a large number of them from the beginning in the name of independence.
In this document, we expose one more bit of information critical to the community's independence: documenting how to operate an election. For the first election, we will execute the instructions below to ensure it all goes smoothly, but these are all actions anyone can run at the appropriate times to nudge the contract into the next step of the election.
EdenOS is a portal that automates a lot of the election process, but there are a few things that must be known and understood to execute an election. This document will outline what the contract needs as far as event triggering to complete an election.
Smart contracts are reactive: they react to in-coming transactions, their own "events" internally, and other contracts' events. So during an election round, the contract is just responding to vote actions and video upload actions, but at times, we need outside triggers to transition the contract between rounds and other states where there isn't an event to trigger the next state.
The easiest smart contract limitation here to relate to is time... contracts can't run an action at a particular time (like a cron job, if that term means anything to you); they are always responding to in-coming events. So the eden contract exposes a few actions that anyone can call (no special permissions) that simply poke the contract awake, and if it's the right time, it will execute the relevant code.
Below, we outline what those are that need to be triggered manually, when they need to be called, and how to call them.
The actions involved are as follows:
electseeddistributeelectprocessNOTE: for each of the steps below, if the action you're invoking takes a "max_steps" argument, generally, you can enter 100. You need to rerun them until there's no more to do. You'll get 1 of 2 outcomes from these invocations.
electseed must be called with a bitcoin block header to provide the contract the ability to randomly assign members to groups. Instructions for that process can be found here.electprocess must be called to alert the contract that it's time to start the election. The contract knows whether to act or not; it just needs a trigger to "wake it up" in case there is action to take. So if this action is called too early or multiple times, the contract still acts properly. At the right time, when electprocess is called, the contract will transition itself into the first round state. Link to invoke this action.electprocess must be called again to have the contract wrap up the running round and kick off the next round.electseed must be called just as it is called prior to the election, except that the block headers used here must be from block produced within the sortition time window.electprocess must be called to finalize the sortition round and choose the Head Chief.distribute must be called to distribute funds from the treasury to the elected delegates, based on their allocated budgets. Link to invoke that action.distribute must be called for the contract to make the monthly disbursements. Note: we will very likely work this into the UI so that it becomes unnecessary to do this manually.