I have a question about the NEAR bridge, especially the verification side on eth for the NEAR header.
The NEAR chain’s consensus is based on PoS, which is regarded as valid or invalid based on a majority of committees. On the ether side, the near’s header is not verifiable as the doc mentioned. Instead, the header is verified off-chain and observe some challenges. However, I doubt how its block (header) can be verified. For example, the current verifiers on the NEAR chain do not generate an invalid block, but make a fake header off-chain and send it to etherClient. The fake header contains valid signatures and thus passes the signatures test. Could you explain how your architecture solves this one? I couldn’t find this question and answer in the official doc.
I’m not the expert on bridges - but I’ll try to answer.
AFAIK - the security of the chain (and bridge) works only under the assumption that there is less than 1/3 of malicious validators. The scenario that you’re describing, assumes that 2/3 of validators have behaved in malicious way (by signing a fake block off-chain).
In the future - such behaviour would be also slashable - as this would mean that the block producer has created 2 blocks at the same height.
First of all, creating a fake block out of on-chain is not a malicious behavior in view of nodes that participate network because they don’t see any corrupted block. Thus, the honestness of 2/3 is still preserved on chain.
How is it slashable? Say there are n of submitted blocks at the same height with valid signatures. How the contract can distinguish which block is really mined on chain?
creating a fake block out of on-chain is not a malicious behavior
it is. Thats’s why you should be very careful what you sign with your validator key.
Say there are n of submitted blocks at the same height with valid signatures.
In such case, either the chain will stall (if next block producers don’t agree which block to pick) - or it would proceed by picking one of them.
Imagine you’re a block producer at height H. You produce two blocks B1 & B2 - and B1 gets added to the chain, while B2 gets somehow “distributed off-chain” to trick bridges.
In such scenario - anyone who will see a B2 later, will be able to say “A-ha - this is a duplicate block for this height as I saw B1 in my chain” - and they can take block B2 and submit it as a challenge to the chain.
And any validator on the chain can quickly verify that such challenge is successful (as they can clearly see two different blocks at the same height, signed by you). So you would be slashed in such scenario.
Your question has motivated me to write a little bit longer article on how slashing & challenges will work on NEAR - so stay tuned - it should arrive in a week or so.
In such scenario - anyone who will see a B2 later, will be able to say “A-ha - this is a duplicate block for this height as I saw B1 in my chain” - and they can take block B2 and submit it as a challenge to the chain.
This challenge can be raised by attack too. For instance, the attacker can raise a challenge that says the B1 is a duplicated bock.
And any validator on the chain can quickly verify that such challenge is successful (as they can clearly see two different blocks at the same height, signed by you). So you would be slashed in such scenario.
How it can be verified? The contract checks only the 2/3 validators’ signatures. The fake block must be signed by validators over 2/3. So, this seems not verifiable on contract. Say there are A, B, and C blocks submitted at the same height. The watchers submit challenges that says A is duplicated, b is duplicated or c is duplicated. However, the contract cannot distinguish which block is really mined on the counterpart chain. Of course, the malicious validators over 2/3 can submit fake headers forever, but they do not make a corrupted block on chain.
If the bridge contract decides with the majority of challenges, it seems not a trustless-verification manner. Also, it means that attackers can submit numerous challenges over than honest watchers submit.