---
tags: Proposals
---

# Kick Out Voting Proposal V1

## Summary

The following is the first attempt at creating a chain of actions to take care of kicking out a broker which is not doing its job.

*Note by J: Considerations overall:*
Brokers not doing their jobs:
- Definition needed: Broker receives data from stream but does not relay it...
- enough? Meeting a quota?
- (Q for due diligence: Revenue is stake-weighted, but performance is currently not tracked. -> Broker with 70% of bounty stake should relay 70% of stream data? (performance measure and kicking criteria need to be fleshed out)
- x-times when queried by watcher (queried but not relaying data -> 1 flag)
- Note: Brokers not relaying data does not mean they are malicious - could be network troubles or inactivity (which if serious enough should also be an offense)
- Definition needed: Punishment: Kicking out a broker...
- Any broker can already leave after waiting period at no cost
- Cost to broker: No more bounty revenue
- Share of stream revenue is proportional to stake
- Potential cost to consider: Slashing of bounty stake
- Where would slashed funds end up: Back in bounty (sponsor benefits), at watcher directly (how to assign to watchers), watcher pool
- Kicking out directly after x flags, OR x flags -> vote by sponsor to (not) kick
- Account Ban List: Cost of changing identity very low
- Who wants watchers?
- **Sponsors provide funds** for bounty and want to make sure that stream is relayed
- Sponsors are the most likely source for starting a watcher service
- Sponsors could have some insights into brokers and know that specific ones are trustworthy (reduces overhead in who to watch)
- Network overall benefits from brokers doing their jobs
- Publishers and subscribers both have an interest that brokers do their jobs
- Brokers might be affected by other brokers not doing their job (since brokers also relay to other brokers)
- Careful: There might be now mechanisms to check whether watchers flag correctly. If paying for identified bad brokers is overdone, watchers could be incentivized to flag in any case.

Things that were mentioned to check out:
- Helium: Authoritative packet approach

## Entities

- There will be a new entity of "watcher" which are users who earn rewards for watching the network

## Parameters

| Name | Description | Type |
| -------- | -------- | -------- |
|maximum_flags|The maximum number of times a broker can be flagged before they are kicked out|Integer|

## Behavioral Actions/Prior Actions

### Query Brokers

- This is the behavioral action where a watcher signals they are ready to query brokers and earn rewards
- At this stage, the broker has not been decided and it triggers the policy for choose broker

## Policies

### Select Broker to Query

- This policy would define which broker a watcher is going to observe
- The implementation for the base case is a random broker each time, and a random stream each time
- The selection could be something like:
- index = current_time_stamp % number_of_brokers
- current_broker = brokers_in_system[index]
- number_staked_streams = number of streams that current_broker is in
- index2 = current_time_stamp % number_staked_streams
- stream_to_query = current_broker_streams[index2]
- This would pass along a message of which broker and stream the watcher would query against and would give a pseudo-random selection
- The query broker policy would be called afterwards

*Note by J:*
- Watcher assignment:
- Watching/Checking all brokers too costly / large overhead
- Sponsors could initiate watcher service
- If a broker is doing his job well, sponsor has little benefit in kicking him
- If slashing of broker goes back to bounty, there could be scenarios in which a good broker with a large stake is still optimal to kick from sponsor view
- Without slashing, a large stake broker might do a minimum job not to get kicked, but not enough to warrant his stake-weighted revenue -> could still be good to kick from sponsor view
- If a broker is not doing his job well, sponsor benefits from kicking
- Sponsor should not be able to slash at will
- Provide hints to watchers to get a broker audited
- A targetted broker will always be at higher risk of punishment -> targetting in itself an abusable mechanism if whoever chooses target has scenarios that are profitable (large stake broker etc)
- Only sponsor has put financial stake in bounty, so only sponsor should be able to directly target / kick
- Hints could be supplemented with random audits
- Random audits reduce overhead for sponsors
- Random audits increase overhead for watchers
- Random audits increase risk for malicious brokers
- Watcher targetting:
- Need to be able to query specific nodes
- Could connect downstream from broker node but would not know whether it was broker or other node inbetween that dropped msgs
- Due Diligence Q: On a blockchain level, brokers are registering for bounty with their address. How is this mapped to network identification? Do we know exactly who is a broker and who is a regular node? Also: Can any node identify the entity type of other nodes? Would a broker be able to tell watchers apart from regular nodes, other brokers from regular nodes etc.
- Random targetting: Would still need to connect to brokers directly, but wouldn't need to be a specific one
- Note: Maybe some form of reputation could help this system long term -> brokers being queried and responding well could accumulate reputation to not be checked too easily, reducing overhead. slashing could then also be on reputation. Brokers could potentially gain preferential access to bounties through reputation, especially if bounty is oversubscribed (if that happens at all, since rewards should be balancing already)

### Query Broker Policy

- This policy would take the watcher, the broker, and the stream ID and then create the logic of what would be tested
- There might be considerations towards size of data differences etc.
- The logic of this policy would be:
- Determine the test query form
- Determine the rewards that should be allocated to the watcher based on test query computational work
- Run the test query and parse the response into query response message
- Call the "Watcher Reward Policy" and "Watcher Query Response Policy" passing along the messages

*Note by J:*
- Watcher action:
- Query specific nodes -> needs to have the ability to query those specific nodes, a little unclear how easy this currently is and whether a random node querying me suddenly with special request would be instantly discoverable
- Watchers could also request previously signed receipts (if those are signed already):
- Watchers could also join and sign others as well as be signed by others

### Watcher Reward Policy

- This policy would deal with how rewards are given to watchers
- 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
- The mechanisms that are called afterwards are:
- Increase Watcher Funds
- Decrease Stream Funds

*Note by J:*
- Watcher reward:
- Where is this reward coming from?
- Bounty funds? -> Sponsor pays for service -> does he only pay if watcher finds someone? does he always pay?
- If several flags are required to kick a broker or to initiate a vote, watcher payment coming from bounty works since individual watchers can be paid rather than waiting for conclusion of process (need to accumulate 3 flags for slashing)
- If negatively flagging somebody nets a reward for watchers, flagging is profitable -> can probably not prove malicious flagging (who watches the watchers)
- If any action nets reward, needs to be reasonable balanced to not drain bounty for identifying everyone's cool
- Slashed stake? -> Needs to be reasonable to not drastically slash non-malicious misbehavior, but could be a reasonable disincentive especially for bad malicious actors
- Maybe: Combination - querying on-request nets small reward from bounty, if several different watchers flag a broker for malicious behavior a slashing occurs and is partially divided among watchers that identified bad broker
- Rewards need to be tested very well, seems abusable for watchers to be paid for flagging

### Watcher Query Response Policy

- This is the policy which takes care of the query responses
- A simple logic would be:
- Take in a message about success of the query to the broker
- If it is a good response, then terminate the function here
- If it is a bad response, call the mechanism "Record Flag" for the stream and broker
- Check the number of flags on the broker
- If number of flags is greater than the maximum_flags parameter, call the "Kick Broker" mechanism for the broker/stream combination

*Note by J:
Probably not necessary in v2 already, but a good response could also potentially be stored for historical performance eval / reputation
*

## Mechanisms

### Increase Watcher Funds

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

### Decrease Stream Funds

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

### Record Flag

- Given a broker i/stream j combination, this will increase the number of flags for broker[i] @ stream[j] by 1.
- This will require adding a new variable to the stream to track flags

*Note by J:*
- Potentially storing broker i flags overall is useful too? Could identify optimization of malicious behavior across streams
- Are flags tracked publicly here? As in stream contract tracks broker ID -> flags?
- Could serve as warning for brokers
- Could serve as optimization for watchers (if I get a broker assigned and see he's got a couple flags I might flag him instantly for the reward, could potentially accept tons of watching requests and flag all who have flags already and none who do not, reducing my overhead and raising my chances of rewards)

### Kick Broker

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

*Note by J:*
- Slashing broker stake needs to be done carefully as to not slash accidental/bug and to not make it too abusable
- Slashed funds end up where ->
- if they're added to bounty, sponsors can top up their bounty by colluding with watchers
- could be used to pay for watchers (which incentivizes flagging)
- could partially end up in some watcher fund, which pays for regular watcher operations (while sponsors pay for targetted watchers?)
- List of banned brokers: Cost of changing identity very low

## System Guarantees

1. All brokers have an even chance of being selected for the query
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