Had a few more thoughts about this thread at the end of the day 
We'd love to hear about your research/findings. We try to keep an eye on this space and support academic research where we can. If you have a project relevant to us or security research you're performing in this space please feel to reach out in forum DM or via e-mail if you think there's something we can do to make Let's Encrypt's domain validation more secure.
If you have specific questions about what implementation details you'd be interested in reading I can provide some pointers. We haven't done a great job of documenting the high level system design, sorry about that! I'll try to land some documentation in the new year (Filed #4609 to keep myself honest).
If you follow the Development Instructions to set up a Boulder environment in Docker and then change your docker-compose.yml's BOULDER_CONFIG_DIR to test/config-next instead of test/config you'll have a Boulder environment configured with two primary VA instances (validation requests are load balanced across the two) and two remote VA instances (each primary VA will ask both remote VAs to perform matching validations for each primary validation). Of course this is a dev env so both the primary and remote VAs are all running on one host.
The primary and remote VAs are both the same piece of software, the boulder-va service (cmd here, package here). The boulder-ra uses the same RPC interface to ask for a primary validation as the primary VA uses to ask a remote VA for a confirmation validation.
Primary VA instances know they are a primary based on the presence of the "remoteVAs" configuration element. If present it specifies gRPC service addresses for other VA instances to use as remotes. There's also a handful of feature flags that control how the primary VAs handle the remote VAs.
In the dev env with config-next the two primary VAs are va1.boulder:9092 and va2.boulder:9092 and use test/config-next/va.json as their configuration. This config file specifies two "remoteVA"s, va1.boulder:9097 and va2.boulder:9098 and enforces that a maximum of 1 of the 2 remote VAs disagree with the primary VA for all validations. The remote VA instances use test/config-next/va-remote-a.json and test/config-next/va-remote-b.json as their config files.
There's some integration tests that test this end to end. The most relevant is probably test_http_multiva_threshold_fail. It tests that a HTTP-01 challenge made to a webserver that only gives the correct key authorization to the primary VA and not the remotes will fail the multi-perspective validation.
Hope that helps give you a place to start. I'll be out of the office for a ~week but will follow-up if you have more questions when I'm back.