Open mzabaluev opened 2 weeks ago
I'm not an expert on the MCR code, so correct me if I'm wrong.
The _acceptBlockCommitment
function containing the rollOverEpoch
call on line 228 is called on a commitment that gains a supermajority of stake. Any other commitments for the same height should not be accepted to get to the check on line 212, and furthermore such commitments should be slashed (which is not currently implemented). So it works as designed?
Equivocation by attesters is prevented here.
Any other commitments for the same height should not be accepted to get to the check on line 212, and furthermore such commitments should be slashed (which is not currently implemented). So it works as designed?
I believe this is correct. But, what I had started doing and not completed which would help auditing and our review here is annotating the pre- and post-conditions for these methods. I can re-engage on this.
Marking this as decentralized because MCR does not need to be safe for centralized launch.
Auditor: Ottersec Code: MCR Settlement Contract
Original filing
It’s possible for current epoch to go beyond yet uncommited block’s epoch assignments: Let’s assume there’s two commitments in queue: A(H=5, blockHeightEpochAssignments=10) and B(H=6, blockHeightEpochAssignments=10). The time based rollover in _acceptBlockCommitment here might roll over to the 11th epoch when accepting the first block, causing a Denial of Service for the contract since the epoch check here can never pass once this happens.
Scope of work
Accordingly to the team's evaluaution, there is no possibility to end up in an unreachable epoch with a correctly behaving supermajority, as explained in comment below.
The remaining work is in annotating the pre- and post-conditions for the relevant methods to facilitate audit and review.