Transit UoPool from ONE chain with MULTIPLE entrypoint to ONE to ONE relationship

[zsluedem]

Currently the relationship between chain_id and entrypoint address woule be like one to multiple.
Like if we want to start a uopool service https://github.com/Vid201/silius/blob/main/crates/grpc/src/uopool.rs#L347-L359, we need to supply one chain and multiple entrypoints.

However, the real cases are more like one chain to one entrypoint relationship.

We should transit to one to one relationship.

@Vid201 Does that make sense?

[Vid201]

Currently the relationship between chain_id and entrypoint address woule be like one to multiple. Like if we want to start a uopool service https://github.com/Vid201/silius/blob/main/crates/grpc/src/uopool.rs#L347-L359, we need to supply one chain and multiple entrypoints.

However, the real cases are more like one chain to one entrypoint relationship.

We should transit to one to one relationship.

@Vid201 Does that make sense?

That's a good question. Generally, I agree with your suggestion. There should be only one entry point that is trusted and verified on each chain. The advantage that we can get with one chain and multiple entry point relationship is that we can support multiple version of entrypoints (example v0.7 and v0.8 ...) - of course in case the function signatures and things like that stay the same between these versions. I am not sure how this will play out in the future.

But at the moment, I guess it makes sense to make the change.

[zsluedem]

The thing is that one to one relationship could also cover multiple version of entrypoint here like 0.7 and 0.6 version for eth mainnet could be
Chain(eth) -> 0.6 version entrypoint
Chain(eth) -> 0.7 version entrypoint
although the Chain(eth) is duplicate here. But it would give us more flexibility

[Vid201]

The thing is that one to one relationship could also cover multiple version of entrypoint here like 0.7 and 0.6 version for eth mainnet could be Chain(eth) -> 0.6 version entrypoint Chain(eth) -> 0.7 version entrypoint although the Chain(eth) is duplicate here. But it would give us more flexibility

Ok, true. Then let's make a change!