---
# System prepended metadata

title: Kick Out Voting Due Diligence V3
tags: [Proposals]

---

---
tags: Proposals
---

# Kick Out Voting Due Diligence V3

The following are general topics with questions and ideas which would benefit from input from the streamr team.

## Logic for what a review looks like

Proposed version

- Vote: For now simple question of “Is this peer relaying stream data?” - “Yes / No”
- Vote result: Majority Yes / No
- If Majority Yes: The PR staked funds are divided by number of Yes votes and sent to respective yes voters
- If Majority No: The malicious broker is slashed and the funds are divided by all No votes +1, and sent to no voters and the neighbor that flagged and started review process. PR staked funds are returned. The malicious broker is also removed from the stream.

## Receipts vs. Queries

- In general, there are two possible implementations, one with a query based system and one where receipts are checked
- Receipts is under development but not yet complete
- Is it better to start with the query system as the baseline, or would integrating with the research for receipts be better?
- Query system is likely the easier version at the moment to implement

## Bounty Rewards

- The current implementation has rewards earned by amount staked, but does that translate to the broker doing more of the work overall?
- Put another way, if a broker has 70% stake, does/should it do 70% of the work or do all brokers do the same amount of work?

## Defining Malicious Behavior vs. Network Troubles vs. Broker Problems

- Is it possible that a broker is doing their job but all of their neighbors fail them and that is why the message doesn't go through?
- Is there a way to account for broker specific troubles, like, say a power outage? Once a broker is flagged can they be checked daily/weekly for some time period to see if it was one off versus malicious?
- Would a system where probability of being audited be related to the number of times one is flagged be a good way to over time track things like this?

## Sponsor Veto

- Should a sponsor be able to veto a broker being kicked out?


## Sponsor Targeting

- Sponsors should not be required for actions, but could get the privilege
- Open question of whether sponsors should be allowed to either directly target brokers or hint at brokers that might not be performing
- Could this mechanism be abused?

## When are brokers assigned their peers?

- When they initially join the network (topology changes could leave some brokers uncovered)
- At certain intervals (overhead)
- When a Peer Review process starts (might need to check whether we can notify brokers of that process, or whether everyone listens to this? Maybe a stream that every broker needs to subscribe to where we send through data on this PR that started?)

## Blockchain Level Question

- 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 (peer-reviewing broker) apart from regular nodes, other brokers from regular nodes etc.


## Watcher Discoverability

- Would it be easily discovered that a query came from a watcher (peer-reviewing broker)?
- If you only expect 4 neighbors to query and all of a sudden a watcher (peer-reviewing broker) is querying, would it be obvious?

## Payment of Watchers

- Brokers doing the watching likely would be best paid from the stream
- Should it only be when a broker has been found to not be doing the work?
- Should there be baseline payments no matter what since knowing that brokers are all working is also good 
- Should there be a combination of a baseline payment plus bonus for finding bad actors?
- It probably is better to have just baseline so that watchers don't have an incentive to lie and get brokers kicked out
- Should rewards be (roughly/exactly) equal no matter the outcome of the vote? 

## How much should be staked with a flag?

- The staked funds need to cover the rewards in case the Peer Review finds no wrong-doing.

## Reputation Rewards

- One possible way to deal with the issue of brokers being kicked out and coming back with a new identity is to have rewards also possibly be a function of reputation / time
- This would make it so that a broker would also fear being kicked because it could impact future earnings

## Global vs. Stream Level Flags

- The times a broker is flagged in a stream are of course important, but it could also be useful for global flags
- Could increase the odds of audit in other streams if a broker is flagged in one
- Could also be a consideration to kick the broker entirely from the ecosystem if they are found to be in violation across many streams

## Watcher Payment Incentives
(Question 1 is for seperate watcher entity, not relevant if brokers put up stake in case they flag innocent peers, as well as slashing of guilty brokers)

- Question 1: Does the idea of a stream paying out from their funds for the watchers after each query that happens make the most sense?
    - Original Jakob comment: from stream funds or bounty funds? In my understanding, a stream can have many bounties, and brokers stake to a bounty. I guess this terminology might be used interchangeably though. This raises another point though - what if a sponsor does not want his funds to be used for this service, but then random watchers are allocated and “drain” his bounty? Maybe when starting a bounty, the sponsor could have an opt-in/opt-out to this watcher service, which removes it from indexing? Might be high overhead for an edge case though, but could keep in mind.
- Question 2: Does there need to be a different reward for finding bad behavior so watchers are incentivized to actually look for these behaviors vs. just flag randomly and not do the work?
    - Original Jakob comment: no matter whether the result is positive/negative? If result does not matter for payment, watchers will be less incentivized to flag negatively (or might even flag randomly - might want to think about whether the query response can be proven/challenged) and sponsors marking brokers for audits will know there is a cost even if the broker is not malicious (which is good, since it drives down sponsors flagging brokers arbitrarily)

