Skip to content

Validator Tx Votes

Jump to bottom
Brennan Lamey edited this page Dec 23, 2023 · 2 revisions

Overview

The Kwil vote system allows validators to submit vote transactions to the network, to get external data. All votes must be unique and deterministic, and therefore should be given some sort of "uniqueness key" (like the txid of the originating transaction from Ethereum).

There are 2 transaction types:

  1. ValidatorVoteBodies: This is used to submit several "resolutions" to be voted on. It contains the full body of the "resolution"; e.g., if we are voting to increment an account balance, it would include the account balance, the target account, etc.

    Only the block proposer can include this tx. This is to prevent validators from accidentally submitting large amount of data, repeatedly and unnecessarily, if they all see an event at the same time.

  2. ValidatorVodeIDs This is used to submit several votes for resolutions, based on their resolution IDs. A resolution ID is simply a UUID v5, which is based on the hash of the event data and event type. If validators see an event, and are not the block proposer, they can vote for the events validity by submitting its resolution ID.

    It is possible for a validator to see an event, and attempt to vote approve on its corresponding resolution ID before the block proposer has submitted the full body. In this case, the resolution will still be created, and votes will still be tracked, but the resolution will be unable to pass until it is given an event body, even if it has enough votes.

    Validators send their VoteIDs at the end of processing a proposal, in FinalizeBlock. It doesn't matter too much, but it seems like this could also be in Commit. This was mostly an arbitrary choice.

Expiration

Resolution expirations are set via a consensus parameter. They are denoted by a block height. For example, if there is an expiration of 100 in the consensus parameter, and we are at block 50, then any resolution created within that block will expire at 150. Even if a resolution is only given an id, and is not given a body (in the case of it being added via ValidatorVoteIDs), it will still be given an expiration.

Mempool

The mempool will reject ValidatorVodeIDs txs if it does not come from a current validator. The mempool will also reject all ValidatorVoteBodies, since they should only be provided during block proposal.

Proposals

The block proposer will include all of its resolution bodies in its block proposal, in a single ValidatorVoteBodies tx.

Other nodes will reject blocks that have ValidatorVoteBodies txs from anyone other than the validator.

Potential Issues

  • Validators can spam ValidatorVoteBodies and ValidatorVodeIDs with no consequences. Perhaps this can be mitigated by charging a gas cost for added votes, and refunding the gas cost once the resolution passes.
  • Validator have no real incentive for getting votes in. For all intents and purposes, it is optional for a validator to do, and therefore a validator, acting purely out of self interest, would have no reason to spend the time, effort, and money to connect to other chains. Adding in some ability for programmable block rewards for validators who take part in the vote process seems like a great way to solve for this. I would consider this low priority, since anyone running a node right now has an interest in doing it well.
Clone this wiki locally