Security and Finality
Validators set changes take place at the (epoch+N/2) blocks. (N is the size of validatorset before epoch block). Considering the security of light client, we delay N/2 block to let validatorSet change take place.
Every epoch block, validator will query the validatorset from contract and fill it in the extra data field of block header. Full node will verify it against the validatorset in contract. A light client will use it as the validatorSet for next epoch blocks, however, it cannot verify it against contract, it have to believe the signer of the epoch block. If the signer of the epoch block write a wrong extra data, the light client may just go to a wrong chain. If we delay N/2 block to let validatorSet change take place, the wrong epoch block won’t get another N/2 subsequent blocks that signed by other validators, so that the light client is free of such attack.
Slashing Logic
If a validator failed to produce a block, will record it and finally slash it. It implements the following interfaces:
If a validator failed to produce a block, will record it and finally slash it. It implements the following interfaces:
· Slash(validator address) external
· Conditions:
1. The message sender must in coinbase.
2. can only call once in one block.
Actions:
1. increase the missing blocks metrics of the validator by one.
2. if the missing blocks metrics is times of 50, will call misdemeanor func of ValidatorSet contract to trigger a misdemeanor event and distribute the revenue of the validator to others.
3. if the missing blocks metrics is times of 150, will call felony func of ValidatorSet contract to trigger a felony event, not only distribute the revenue of the validator to others, but also kick the validator out of validatorset.
Finality
Given there are more than 1/2*N+1 validators are honest, PoA based networks usually work securely and properly. However, there are still cases where certain amount Byzantine validators may still manage to attack the network, e.g. through the “Clone Attack”. To secure as much as Dexit users are encouraged to wait until receiving blocks sealed by more than 2/3*N+1 different validators. In that way, the Dexit can be trusted and can tolerate less than 1/3*N Byzantine validators.
With 21 validators, if the block time is 5 seconds, the 2/3*N+1 different validator seals will need a time period of (2/3*21+1)*5 = 75 seconds. Any critical applications for Dexit may have to wait for 2/3*N+1 to ensure a relatively secure finality. However, besides such an arrangement, dexit does introduce Slashing logic to penalize Byzantine validators for double signing or instability. This Slashing logic will expose the malicious validators in a very short time and make the Clone Attack very hard or extremely non-economic to execute. With this enhancement, 1/2*N+1 or even fewer blocks are enough as confirmation for most transactions.
Last modified 4mo ago