-
Notifications
You must be signed in to change notification settings - Fork 793
Automatic Actions Framework
- Place automatic actions in a new block extension type,
automatic_actions - The block extension should have a maximum serialized size equal to a fraction of the block size (perhaps 20%).
- Witnesses are free to determine the set of block actions from the set of available actions using any algorithm.
- Each action is completely determined by a corresponding action key. The rest of the action's fields must be a deterministic function of the action type, action key, and the blockchain state.
- For now, the witness plugin will implement a simple FIFO ordering of actions. A single SMT's market maker and inflation actions will be included at most once per hour.
- In the future, if actions start to queue because the block extension is consistently full, the witnesses (or any subset of them) can implement and switch to a different ordering algorithm at any time. For example, we may use the Steem in the SMT's market maker to determine how often the SMT's actions can occur.
all automatic actions have a cost. Some of these costs are handled by the blockchain itself and others by users. Of these, we have two types of automatic actions.
-
Deterministic actions. Savings withdrawals, reward payouts, etc. are examples of deterministic actions. A single op generates a deterministic number of automatic actions. The cost of the automatic actions should be included in the cost of the operation when it is initially included in a block. These automatic actions should be guaranteed to be included as quickly as possible when they occur.
-
Non-deterministic actions. Market Maker pings and SMT Inflation are examples of non-deterministic actions. The number of automatic actions generated is not deterministically determined at the time of the op. An account needs to pay for the actions as they occur. Our solution to this is an operation that states intent to pay bandwidth for some automatic actions. In this way, an account is responsible to pay bandwidth, but they do not need to run any software for such actions to occur. If they cannot pay for an automatic action, the inclusion of it will be delayed until they can.
In order for this to be compatible with bandwidth, blocks will need to be accepted even if they omit certain automatic actions.
This potentially causes problems. For example, we first need to payout author rewards for content to calculate how much of the rewards pool gets divided between the author and curators. Then curators can be paid. If the first op was skipped and curators were paid, the action would fail. In order to get around this, automatic actions will be able to generate more automatic actions which will be placed at the end of the queue. This behavior also prevents a single burst of automated actions from starving other actions.
For deterministic actions, we want to employ the use of batch actions as much as possible to prevent duplication of data in the blocks. Such examples of batch actions are:
- Payout the next 50 curators for post A
- Expire the next 50 limit orders
- Process the next 50 vesting withdrawals
Such relative batch actions also prevent witness manipulation of state through front running actions.
Actions creating new actions also helps prevent front running. While we cannot prevent witnesses from including actions in a specific order, (doing so would require moving bandwidth back in to consensus) if an action generates another action, it enforces a relative ordering between certain actions that may have ordering dependencies associated with them.
Within a given SMT, claims MUST be processed in FIFO order. The code should be written to allow processing of multiple claims for a single SMT within a single block.
The action key for SMT claims is the SMT's asset ID.
Refunds should not be automatic actions. Refunds should be operations; a user must explicitly issue a transaction in order to receive a refund for an SMT launch that did not occur. If the total contribution of users who do not choose to be refunded is greater than the minimum, a delayed launch can occur.
The action key for a market maker ping transaction is the SMT's asset ID.
SMT emission should have its own clock which advances one "tick" every time an action occurs. So if an SMT is programmed to emit every hour, and it has been 20 hours since the last action, the next action will only do a single hour's worth of emission. For an SMT whose emission has become backlogged, multiple emission actions could potentially be included in a single block.
The action key for SMT emissions is the SMT's asset ID.