# Ordering Verifications

In an effort to achieve feature parity with the Merkle backend, we want to maintain a one-to-many mapping between verified ETH addresses and fids. An ETH address can be connected to a single fid, though an fid can have many connected ETH addresses.

In order to do so, we will have to resolve conflicts in a deterministic way between `VerificationAddEthAddress` messages that reference the same ETH address. We already handle these conflicts between messages from the same fid, but the problem is more complex across multiple fids.

### Example problem

One idea might be to continue to resolve conflicts solely using a LWW mechanic based on messages' timestamps. However, this method is bad, because two fids that both want to connect the same ETH address could continue signing messages after each other to flip the ETH address back and forth between them. In this situation, both fids would have gotten a signature from the ETH address at one point, and they're re-using that ETH signature with each subsequent message.

### Ideal solution

It's clear that the ETH address should determine which fid should be allowed to claim it, not the fids. But for two verifications with the same claim, we can fall back on normal LWW mechanics.

Right now, we include a block hash in the claim that is signed by the ETH address. However, a hub or client has to connect to the Ethereum network in order to check that block hash and turn two block hashes into an order (i.e. by converting them into block numbers).

Here is the current `VerificationEthAddressClaim` that is signed by the ETH address:

export type VerificationEthAddressClaim = {
  fid: Uint8Array; // Must be big-endian typed array
  address: string;
  network: FarcasterNetwork;
  blockHash: Uint8Array;
};

Ideally, `VerificationAddEthAddress` messages are self-verifiable and self-orderable, meaning that a hub does not have to look up information from a separate system (i.e. Ethereum) in order to merge messages.

### Option 1: use block number and reject block numbers too far in the future

We could replace block hash with block number in the verification claim that is signed by the ETH address, which would allow us to order signed verification claims.

The downside of this approach is that ETH addresses can lie about the block number, so we'd have to add a way to reject claims with a block number too far in the future.

Since we're merging events from the ID Registry and Name Registry, the hubs already have some sense for recent block numbers. So hubs could maintain an estimated `currentBlockNumber` and reject claims that include a block number more than 100 blocks beyond that (arbitrary). If hubs lose connection with Ethereum, the hub can still project the `currentBlockNumber` based on the time since the last block number (i.e. the delta / ~12 seconds per block).

### Option 2: continue using block hash

Hubs can continue accepting `VerificationAddEthAddress` messages in the current format (i.e. using block hahs) and look up the block number by block hash with each message. This would allow hubs to:
1. Order all verification claims signed by ETH addresses
2. Prevent ETH addresses from claiming invalid block numbers

The downside of this approach is that it adds two contract calls for every conflict that needs to be resolved. And if the hub ever disconnects from Ethereum, it cannot merge new verification messages until it reconnects.