A 51% attack in a PoS consensus is where more than 50% of the staked ETH in the network belongs to validators with malicious intent. Obtaining a 51% stake in the network would be very expensive and so a 51% attack is less likely to occur than in a PoW chain (but that would also be very challenging - to control 51% of all the mining power behind the network).
The end goal of a 51% attack is to double spend coins, essentially. The malicious validator set signs two competing chains at the same height and make it impossible for the light client to know which chain is the correct chain.
To detect eclipse attacks, our bridge would have to be able to detect equivocation. An option is to add a challenge window (essentially waiting a certain amount of time before validating messages or validating finalized header updates to be used for proofs). We would need to handle competing header updates. Practically, when we get a header update for a header that has already been processed by the light client, we would have to check if the header is the same, and if not, freeze the bridge.
A long range attack in a PoS network is when a node that has been offline for a certain amount of time, or freshly syncs from genesis, is convinced by other nodes to follow the wrong chain. The wrong chain originates from genesis or from a much older block (hence the long range attack name).
This happens when a node has been offline for an extended period and holds an outdated view of the validator stakes. For example, a validator could have exited their stake in the chain (or sold their private key on the black market) while the node has been offline, and when the node comes online again, the node sees the now invalid validator as valid still and believes it’s version of the chain, continuing to sync on an alternative chain instead of the canonical chain.
A crucial thing to understand about these long range attacks is that even though the validator set may be very large now and difficult to corrupt, if for example 2 validators sell their keys and are considered corrupted, if at any point in the chain’s history those 2 validators existed and are a majority, they could create an alternative chain.
Some diagrams illustrating this:
Ideally, the light client should check the time between header imports on Ethereum to raise an alarm if time passed without any header import, longer than the weak subjectivity period. A complication in the length of this period is that it changes based on how many validators are in the system (the more validators, the longer the weak subjectivity period is). For safety, our maximum safe weak subjectivity period should be 27 hours.
https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2#:~:text=The maximum safe weak subjectivity period is always at least 27 hours.