Unique Reports - Chainlink OCR2Base.sol

Question

I was checking the OCR2Base.sol file in the CCIP repo and was wondering what the i_uniqueReports variable stands for. Especially, why would it change the transmit() function such that the expected number of signatures changes:

uint256 expectedNumSignatures;
if (i_uniqueReports) {
  expectedNumSignatures = (configInfo.n + configInfo.f) / 2 + 1;
} else {
  expectedNumSignatures = configInfo.f + 1;
}
if (rs.length != expectedNumSignatures) revert WrongNumberOfSignatures();
if (rs.length != ss.length) revert SignaturesOutOfRegistration();

I have taken a look at their older OCR PDF, but I don't see anything that may resemble this.

You can see the shared excerpt in the following link at line 219: https://github.com/smartcontractkit/ccip/blob/ccip-develop/contracts/src/v0.8/ccip/ocr/OCR2Base.sol

Thank you very much in advance!

Answer 1

It is important to understand that Smart Contracts verify signatures on-chain, which can be costly. The more signatures, the higher the cost, so we should have as few signatures as possible. A report is considered valid if it has f+1 signatures, which means that at least one of the f+1 signers is correct. Remember that f is the maximum number of potentially malicious oracles. This may be enough for some use cases.

However, there is a scenario where the current leader of OCR report generation can be malicious and force a subset of oracles to create report r, while another subset creates report r'. Since f+1 oracles sign both reports, they are considered valid but not unique. As a result, one transmitter might transmit report r while another might transmit report r'.

We use the uniqueReports flag to avoid this scenario, which forces each report to be signed by 2f+1 oracles. This ensures that it is impossible to have two different subsets of oracles that sign different reports. Since we only have 3f+1 oracles in total, the two sets would intersect at least once with a correct oracle that would not sign both r and r'. This property is known as the quorum intersection.

By setting the uniqueReports flag, a transmitter can only ever transmit a unique report. However, even with f+1 signatures, we can depend on the blockchain to choose which report to finalize first among r and r'. This may be acceptable for some use cases but not for others.

OCR3 combines the best of both worlds, as it only requires f+1 signatures to be verified on-chain but always produces unique reports. This is achieved by decoupling consensus on unique reports from gathering signatures on the reports.