Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
AIP #1: registry: Validator registry by staking ADX #7
Validator registry by staking ADX
One of the problems that arises from the way the AdEx works, that is not solved by the core protocol, is how to pick validators.
If you're creating a campaign, ideally you'd pick one validator controlled by you, and one being the publisher platform. You can delegate both validators, but you need to ensure that (1) they will serve opposing interests and (2) that they won't misbehave.
Because of the way the protocol works, if assumption (1) is valid, the only possible misbehavior is going offline. Which is a problem, because the campaign stalls. The funds would eventually be returned, but is still an issue.
An open registry of validators helps mitigate this issue.
A blockchain-based (smart contract or parachain) registry of validators, where the rank is determined of the amount of ADX staked. You need to stake a minimum of
If you misbehave as a validator, you lose a portion of the stake, possibly related to the amount of funds in the campaign (although that would need price oracles), or related to a specific parameter in the campaign description (allowing larger/stricter campaigns to penalize more).
To prove unavailability, a prover (any actor) will submit a commited to OUTPACE state (
Then, there would be a
We need to think about alternative ways of proving unavailability, since this only works for proving that a follower is unavailable. Alternatively, if we change the way it works naively, it might be vulnerable to tricking the leader into signing states that are valid but pay to the attacker.
Another mitigation could be to simply limit the registry to publisher-side platforms, who are usually going to be followers.
Other slashing conditions
Another slashing condition that we may want to explore is proving that both validators signed an invalid state transition. This means that assumption #1 (two validators act in opposite interests) is broken.
We can also introduce "time proofs": including the latest hash of a specific blockchain (e.g. ethereum) in the signed state. That way, we can prove a certain thing occured no earlier than that point.
After a validator is chosen from the registry, their availability has to be negotiated. A handshake protocol has to be designed, to ensure that validators have the capacity to accept a new channel (campaign).
This is different from
Any ADX holders can nominate certain validators, therefore increasing their visibility and earning from their fees. The nominators will be slashed proportionally in case the validator itself is slashed.
Unlike OUTPACE, which requires a small number of blockchain transactions, the registry might need high throughput or at least should be able to sustain high throughput.
Furthermore, the registry has a lot to benefit from on-chain governance and easy upgradability. Therefore, we think that the registry should be implemented on Substrate and should eventually run on Polkadot, as those solutions are very suitable for this particular usecase.
Since this system slashes validators for becoming unavailable, concerns like "what happens if my network connection dies" are absolutely valid.
The system should be designed to only slash unavailability longer than a few minutes, and most network outages on most cloud services do not last longer than that.
However, if you're staking large sums, you'd still want to ensure you don't get slashed just because of a technical failure.
This is why it's important to note that being a single validator does not imply you only have one server or you're located in one data center - you can run a validator in a distributed way, across a number of data centers/servers, in order to ensure redundancy.
Having an in-protocol distinction between types of unavailability (malicious or technical failure) is not only next to impossible, but also goes against what we're trying to ensure. Ultimately, whoever nominated the validator would expect availability, no matter what.
validators will be ranked by the formula:
if you're appointing 2 validators for your campaign (not using your own node), then:
UI: there should be a clear visual representation of this ranking coefficient in the UI, so that users are aware of potential risks
it can work for advertiser-side platforms too; if the advertiser is not satisfied with the platform (e.g. it's unavailable), they can launch an ongoing challenge where:
We need to think about throughput. The larger your stake, the higher you will be ranked, increasing the chance you'd be picked. This means you have to be able to handle more throughput, or else you'll be slashed for unavailability. In other words, stakers need to be careful not to stake large amounts unless they're ready for large visibility.
Another option is to just add a second stage of filtering everywhere the registry is used, which will simply ask the validators whether they have the capacity to take new channels. This might be flawed though - as how the throughput is balanced between the system should also depend on stake.
Difficulty of properly slashing
The main issue I see with this strategy is that a validator could be unresponsive to OUTPACE updates and yet still respond to challenges onchain, thus reducing the throughput of the advertising campaign to block times, but still avoiding being slashed.
If this were to happen in an obvious way, (e.g. the validator ignores all OUTPACE updates), then I would assume the publisher and advertiser would agree to drop them and to pick a different validator, then continue their business. However, the validator could also grief the publisher and advertisers by ignoring OUTPACE updates every so often, in which case it might take longer for them to get dropped. This could be solved by requiring the validator to agree to a certain SLA in advance, so the publisher and advertiser know exactly when to move on.
But because the validator misbehavior as described above will only get them dropped as a validator, but not have their stake slashed, it would be relatively inexpensive to conduct. A motivated third party who wanted to grief the AdEx ecosystem could stake a lot of ADX across various accounts, become the validator for many campaigns, and periodically force each of them to chain by ignoring their state updates (though the value may drop).
A different issue would be that instead of wanting to pick a validator at random, I may be concerned about data privacy and want to pick a validator who I trust not to leak data to my competitors. In the current paradigm, there is no way to coordinate around this behavior. Even if I were able to prove it in some offchain forum, the best I could hope for is to inspire others to not use the validator in question.
ADX as a Governance and Dispute Resolution token?
You might be able to solve a few of your problems at the same time here. If you plan on using Polkadot and Substrate anyways, it might make sense to allow for OUTPACE to bring general complaints (unavailability, data leaking) to a court-like system to request that a validator be slashed. My guess is that you'll want to coordinate governance (validator dispute resolution, registry upgradability) with staked ADX, and then may even be better off using a stablecoin like DAI for validator staking. This way the incentives for a validator to misbehave don't increase if the price of ADX drops.
In reverse order:
Re governance/dispute resolution: ultimately, this will get down to the classic on-chain gov vs off-chain gov debate; I am very excited about exploring the possibilities, but IMO core protocol must be up and running first, and we have to see what the problems/disputes are in real life before being close to even designing a good-ish on-chain gov system
The privacy concern is a very good point: there's no way (that I can think of) that will solve this. Furthermore, I'd consider it out of the scope of the Registry. I'd imagine that large parties who are concerned about privacy would run their own validators.
Re proper slashing
Let's view this in a simple case: there's one leader and one follower.
Leader proves that follower is unavailable
The leader submits the new state on-chain and demands that the follower will sign it within a certain period.
If they don't, they get slashed. If they do, nothing happens.
The way this works in real life is:
One might think that a problem with this is that the leader can effectively force the follower into signing a new state. However, they can't force them into signing an invalid state transition (since this is checked on-chain), and by design, the follower always signs new valid state transitions.
If the leader is the one misbehaving, read on...
Follower proves that leader is unavailable
This one is much more complicated. The only game theoretically sound way that I thought of is this:
The way this will work in real life is:
This is a bit like counterfactual channels.
However, indeed, this is not a large enough punishment for effectively stalling the campaign (@ameensol dothis is practically the issue you're referring too). A possible solution would be requiring that the challenge is exhausted within the channel
Another problem with this is that the follower might force the leader into spending gas/tx fees. Will think more on this
Another thing to explore, but is more complicated, is making mechanisms for (1) ensuring the chosen validators have opposing interests and (2) if they do form a coalition, there should be a way to punish them
one way to do this might be to make one validator be able to punish the other, should the other try to bribe them
A potential way to fix the "follower proves that leader is unavailable" is by combining this challenge with a request to close the campaign
The request to close the campaign pays a significant fee to the leader, so it's in the leader's interest to allow it ASAP and move on to other campaigns.
Furthermore, the challenge time could be significantly reduce, as we'd use a "timeout to close the campaign" rather than "channel timeout"
This puts the user at a slight disadvantage though, as irresponsible leaders can get away from getting punished by simply allowing users to close their campaign and pay them out.
Back to offline penalties
regarding section "Follower proves that leader is unavailable" and "if they are online on-chain but offline off-chain, they are dooming themselves into signing and submitting new states until the channel is exhausted"
This is very similar to producing empty blocks in Bitcoin/Ethereum - it's (kind of) expensive, you gain nothing from it, but it's a legitimate and functional attack that would stall the network, without a way to be punished for it.
The best way to mitigate (although as we've seen, not bullet proof) is to meter validator fees by processed events, so that you'd be losing out on validator fees. Again, needs more thought.
**^this would fit in with having groups of publishers running their own markets, no?