Add conflict set to validations stream

[MarkusTeufelberger]

https://ripple.com/build/rippled-apis/#validations-stream at most can show via a different ledger_hash that a validator is disagreeing with the rest of the network. It would be very interesting to know what it actually disagrees with.

I'd like to (optionally, maybe admin-only or only for selected validators?) see some kind of conflict_set field that contains the difference between what the queried server would vote for and what this validator voted for. This would make it at least somehow feasible to spot censorship vs. random network issues/flukes by tracking these conflicts for various validators over time.

[mDuo13]

Reporting the conflict set a good idea. I'd be interested to see what could be done with that. It might also highlight bugs. For example, you could detect nondeterministic transaction processing (or transaction processing changes that weren't correctly put on an amendment) if two servers have an empty conflict set but different ledger hashes for ledgers with the same index derived from the same parent.

[MarkusTeufelberger]

To realize this it would be necessary to be able to get a diff between 2 ledger states and validators would also need to be willing/able to send these diffs along with their validations (a conflict set would then be a diff between 2 of these diffs).

I'd expect a validator to be able (for a reasonable amount of time, let's say 90 days for a validator that wants to be trusted - the extreme case would probably be the 7 years that you are legally obligated to keep bookkeeping receipts) to serve all data that it has signed to enable others to get and calculate these conflict sets. This also means adding (potentially lots of) invalid headers and InnerNodes to the node_db and probably also archiving all validation signatures...

[nbougalis]

I think that an interesting case can be made to allow an admin to configure their server so that it saves every validation it generates (and, optionally, every one it receives also), similar to what you asked for in #2397, would be interesting @MarkusTeufelberger.

But including the conflict set in the overlay data seems a bit too much, at least to me, but we do already perform difference analysis (see https://github.com/ripple/rippled/blob/8a02903fa5eda4daa10972800d2598b9542b02d2/src/ripple/app/ledger/LedgerHistory.cpp#L313) and report mismatches in the log, which can be useful in some situations like the hypothetical "non-deterministic transaction processing" @mDuo13 describes above.

I'm going to close this issue, but if you feel it needs to be revisited, please feel free to reopen it.

[MarkusTeufelberger]

I can't reopen issues here... :-(

Anyways, I still think it would be important to know which validators vote on which version of 2 conflicting (valid) transactions - for example to detect potential collusion. I don't see how handleMismatch would help in this case and only having ledger hashes available is not enough to get this data either.

[nbougalis]

I’ve reopened this issue for you.

My point was that we already have some code to diff things, and it’s large, complicated and expensive. I don’t know that it makes sense to perform that kind of work for validations. It would really take a toll.

Logging all received validations, if configured, is certainly possible; PRs are welcome.

[carlhua]

We are supportive of this feature but it will not be a priority for the Ripple C++ team. External contribution is encouraged.

[vlntb]

@intelliot Can you confirm that this issue is still relevant?

[intelliot]

As far as I know, I think it's still as relevant as it was when it was opened. My guess is that it's a 3-5 day project.

[MarkusTeufelberger]

I also still think it is relevant.