---
tags: Proposals
---

# Kick Out Voting Proposal V3

## Summary

This third version of the proposal improves on V1 and V2 by requiring brokers to be watchers (instead of sustaining a seperate entity type) and adds a two round process for audits started by a broker in the same bounty as the suspect and requires that broker to put up stake.
The main scenario this proposal defends against are brokers not doing any work (no strategic maliciousness yet).

## Graphics

### How to Read

Behavioral Actions
These are any of the behaviors that we see an entity calling to initiate a chain of actions.

Policies
These are the blocks that take a message and map out what policies or mechanisms to call next as well as the new messages to pass to them. This is where logic such as if an audit passes happens.

Mechanisms
These are the blocks that update state in the system.

Messages
These are the inputs/outputs passed between behavioral actions, policies, and mechanisms.

### Full System Visualization

Message Legend:

red: BrokerFlaggingMessage -> {'flagging_broker': <class 'primitives.BrokerAddress'>, 'flagged_broker': <class 'primitives.BrokerAddress'>, 'stream': <class 'primitives.StreamAddress'>}

grey: BrokerAddressMessage -> {'address': <class 'primitives.BrokerAddress'>}

blue: PeerReviewMessage -> {'reviewer': <class 'primitives.BrokerAddress'>, 'flagged_broker': <class 'primitives.BrokerAddress'>, 'stream': <class 'primitives.StreamAddress'>, 'passed_audit': <class 'bool'>}

orange: PeerBrokersMessage -> {'address': <class 'primitives.BrokerAddress'>, 'peer_addresses': <class 'primitives.BrokerAddresses'>}

pink: AuditResultMessage -> {'flagged_broker': <class 'primitives.BrokerAddress'>, 'stream': <class 'primitives.StreamAddress'>, 'passed_audit': <class 'bool'>}


### Flag Broker Visualization

Message Legend:

red: BrokerFlaggingMessage -> {'flagging_broker': <class 'primitives.BrokerAddress'>, 'flagged_broker': <class 'primitives.BrokerAddress'>, 'stream': <class 'primitives.StreamAddress'>}

orange: PeerBrokersMessage -> {'address': <class 'primitives.BrokerAddress'>, 'peer_addresses': <class 'primitives.BrokerAddresses'>}


### Broker Join Visualization

Message Legend:

grey: BrokerAddressMessage -> {'address': <class 'primitives.BrokerAddress'>}

orange: PeerBrokersMessage -> {'address': <class 'primitives.BrokerAddress'>, 'peer_addresses': <class 'primitives.BrokerAddresses'>}


### Check Reputation Score Visualization


### Peer Review Brokers Visualization

Message Legend:

blue: PeerReviewMessage -> {'reviewer': <class 'primitives.BrokerAddress'>, 'flagged_broker': <class 'primitives.BrokerAddress'>, 'stream': <class 'primitives.StreamAddress'>, 'passed_audit': <class 'bool'>}

pink: AuditResultMessage -> {'flagged_broker': <class 'primitives.BrokerAddress'>, 'stream': <class 'primitives.StreamAddress'>, 'passed_audit': <class 'bool'>}


## New Entities & Smart Contracts

- Peer-Review-Smart-Contract: which has voting logic, staking / reward logic, and a target suspect (could be one for all, or new one for each case)

## New Parameters

| Name | Description | Type |
| -------- | -------- | -------- |
|number_peer_broker|The number of peer brokers which are given to a new broker on joining|Integer|

## New Local State (Broker)

| Name | Description | Type |
| -------- | -------- | -------- |
|number_of_flags|The number of times a broker has been flagged in streams|Integer|
|broker_warning_boolean|A flag which can be activated when a broker (who must be staked in the same bounty) flags another broker to start an auditing process |Boolean|
|number_passed_audits|The number of audits which a broker has passed with success|Integer|
|age|The length of time that a broker has been in the system|Integer|
|reputation|A score of reputation that can be updated when someone calls for it and used for purposes of checking which broker pools a delegator might want to stake in, or other needs|Integer|

## Functional Parameters

| Name | Description | Type |
| -------- | -------- | -------- |
|weighting_scheme|The function which determines probabilities of being audited for each node if using random query|f(number_of_flags, sponsor_warning_boolean)|
|reputation_score|The function which can compute a score of reputation for a broker|f(number_of_flags, number_passed_audits, age)|

## Behavioral Actions/Prior Actions

### Broker Join
- This behavior is called by a broker **when joining the network**
- This behavioral action triggers the policy for random selection of n-peers

### Flag Broker

- This behavior is called by a broker on another broker in the same bounty to start the peer review process
- Broker calling this action needs to put up a stake to cover rewards if the flagging was false
- It leads to Peer Review Policy afterwards

### Check Reputation Score

- This policy could be called by anyone willing to pay the gas and would re-calculate reputation score for a broker
- It would lead to the Check Reputation Score Policy being called

### Peer Review Brokers

- This is the behavior of brokers peer reviewing brokers which they have been assigned to audit

### Random Checks

- This is an optional behavior to add where brokers randomly audit non-flagged other brokers and can add a flag for the second round full audit
- <b>This has not been implemented but can be added if it makes sense for the system</b>

## Policies

### Broker Join Policy
- This policy determines if a broker can join the system in the first place
- If they are allowed to join then the policy called after will be the assign peer brokers policy for giving the broker their assignment of peers

### Assign Peer Brokers Policy

- This policy would define which other brokers a broker is going to be responsible for when review time comes
- Base case is **n** random brokers assigned when **first** joining the network
- The selection under complete randomness could be something like: (specific randomness not needed yet?)
- index = current_time_stamp % number_of_brokers
- current_broker = brokers_in_system[index]

- This would pass along a message of which peer broker a broker is responsible for and would give a pseudo-random selection

### Flag Broker Policy

- The policy which decides whether or not a flag for a broker should be added.

### Peer Review Stake Policy
- This policy determines the amount needed to be staked to start a peer-review process by a specific broker on another specific broker in the same bounty
- The basecase here could again be a flat amount that is always the same, but in reality it might depend on the bounty specifics.
- One contract for all peer reviews?

### Peer Review Policy
- This policy determines the voting logic for external peer reviews
- Specifics needed: Time for the process, voting response, evaluation of responses
- When time is over, every non-voter gets slashed. (necessary/possible to encourage voting service?)
If found guilty, Kick Broker Mechanism + Peer Review Reward Policy. If found not-guilty, Decrease Peer-Review SC funds + Peer Review Reward Policy.

### Passed Peer Review Policy

- This policy would deal with how rewards are given to Peer Reviewers
- There is many considerations including vesting, timing of payments, bundling of payments, etc.
- For the moment we will assume it is a simple policy that takes the reward and immediately pays out to:
- If guilty: Rewards go to all guilty voters + the neighbor that initially flagged and started the process
- If not guilty: Rewards go to all non-guilty voters
- The mechanisms that are called afterwards are:
- Increase Peer-Reviewer Funds
- Decrease Peer-Review Stake Contract Funds

### Failed Peer Review Policy
- This policy which takes care of a failed peer review.

### Penalize Peer Review Stake Policy
- This policy determines the penalty for a successful peer review given to the flagger

### Reward Peer Review Stake Policy
- This policy determines the reward for a failed peer review given to the flagger

## Mechanisms

### Increase Peer-Review-Smart-Contract Funds

- This mechanism will take in an amount of funds determined by Peer Review Stake Policy and increase the smart contract funds by this much

### Increase Peer-Reviewer Funds

- This mechanism will take in an amount of funds that should be allocated to the peer-reviewers for their work and increase their funds by this much

### Decrease Peer-Review-Smart-Contract Funds

- This mechanism is the counter to "Increase Peer-Reviewer Funds", it is the contract paying out the funds as compensation for ensuring the brokers are doing their job

### Record Passed Peer Review
- Given a broker i/stream j combination, this will increase the number_passed_reviews for broker[i] @ stream[j] by 1.

### Kick Broker

- Given a broker i/stream j combination, this will do the following:
- Slash broker[i]'s stake completely and send funds to Peer Review Contract
- Kick the broker from the stream
- Possibly add them to a list of banned accounts

## System Guarantees

1. All brokers have either an even chance of being selected for the query or a "fair" as defined by the weighting scheme chance of selection
2. Sybil attacks to kick out a broker actually doing work are not easily done
3. There is a way to keep track of past infractions
4. Doing the work is rewarded by higher reputation