Understood To play a bit more of Devil’s Advocate, guys with lots of money (large deposits) may be able to get in very late by bumping up gas payments. If my deposit is $1 zillion and my bounty is a percentage of the deposit I can afford to pay whatever it takes to get included in one of the last block before the epoch ends.
So ironically, validators with large deposits may end up doing less work and ripping most of the bounties, because they will be able to afford to be included in the last block.
More of Devil’s Advocate: nothing precludes validators from reaching agreements with large miners to have guaranteed inclusion in the last block. In this case, there may be a funny situation where a large portion of the votes will be in the last block
I have some questions,can anyone answer it for me? Thank you very much! Q1: Mentioned in section 3,"Once validator ν leaves the validator set, the validator’s public key is forever forbidden from rejoining the validator set."As time goes on, the contents of this collection will grow to a lot. Then how to maintain this set of verifiers. Q2: Mentioned in section 2.1,“if ≥ 23 of validators follow the protocol, then it’s always possible to finalize a new checkpoint without any validator violating a slashing condition.” Why is “without”. Q3: Mentioned in section 2.1,“the inequality h(s1) < h(s2) < h(t2) < h(t1) cannot hold.” Then what about inequality h(s1) < h(s2) < h(t1) < h(t2)?
Q1: Mentioned in section 3,"Once validator ν leaves the validator set, the validator’s public key is forever forbidden from rejoining the validator set."As time goes on, the contents of this collection will grow to a lot. Then how to maintain this set of verifiers.
Technically we don’t actually need this in the protocol; the issue is that if you withdraw and then re-deposit with the same public key, then the second-round deposit could get slashed for conflicts between messages made by the first-round deposit, or for inconsistencies between the two deposit rounds. It should be a client-side responsibility to make sure not to do this.
Mentioned in section 2.1,“if ≥ 23 of validators follow the protocol, then it’s always possible to finalize a new checkpoint without any validator violating a slashing condition.” Why is “without”.
Because if some validator has to violate a slashing condition to finalize a new checkpoint, the protocol is “stuck”, and can’t move forward without someone voluntarily sacrificing their own money.
Mentioned in section 2.1,“the inequality h(s1) < h(s2) < h(t2) < h(t1) cannot hold.” Then what about inequality h(s1) < h(s2) < h(t1) < h(t2)?
That’s okay. This intuitively means “At time t1, the best source checkpoint I was aware of is s1, but then at the later time t2, I became aware of a better source checkpoint at s2, so I switched to using it”. We expect this to be a very normal occurrence, at least in cases where the PoW blockchain is unstable enough that forks become an issue.
Let’s say I wish to reclaim my validation-deposited ETH, but not to wait the required time. My friend, on the other hand, wishes to become a validator. I can give him my key in exchange for ETH, but that will be really bad practice, as he can never be sure I did not save a copy. I’m assuming it is possible to have the exit address as a smart contract, and change the owner. That solves most of the problem, but can I also point to a contract owner for validation signature? If not, is it possible to include something like this? This will limit the buyer risk to misbehavior that occurred prior to the sell. It will also enable longer lockup times and thus better security, as there will be a market for quick exits and validation of proper behaviors.
The issue that arises if we allow validators to change their keys is that we can’t necessarily check if some message they signed in the past was actually signed by them.
Aka: imagine some validator signs a message m_1 with key k_1, and then later signs a conflicting message m_2 with k_2. We need to ensure that we can check that this specific validator was the one who equivocated, which pretty much requires storing all old keys from any validator ever (or something equivalent). A much easier approach is just checking that signature contracts are pure functions, which is what the current version of the FFG contract does.
Maybe I should have been more explicit about it: the idea is to let the validator store the keys on the blockchain, if he wishes to use this method. For example, lets say the algorithm is SHA3 and signing-contract owner gets to sign. Validator 1 creates this contract as owner, storing his k1. At block N, he sells it to validator 2, changing on the blockchain the owner key to k2 (SHA3 cannot change). Every block before N signed by k1 and every block after N signed by k2 are attributed to this validator.
Every block before N signed by k1 and every block after N signed by k2 are attributed to this validator.
The point is that this isn’t particularly easy to implement in a smart contract, especially in regards to slashing conditions (although I don’t think it would be too horrible).
Note that even though you sold both “validation rights” and “withdrawal rights” to your friend at some point in time, you can still produce slashable messages at later times with your old key. So I don’t think this provides much value over simply copying the validation key (it’s still not trustless).
To play a bit more of Devil’s Advocate, guys with lots of money (large deposits) may be able to get in very late by bumping up gas payments. If my deposit is $1 zillion and my bounty is a percentage of the deposit I can afford to pay whatever it takes to get included in one of the last block before the epoch ends.