What is the motivation of FallbackProvider？

[Cmonorail]

When I read the documentation and learned that there is a FallbackProvider, can you tell me the motivation or usage scenario of FallbackProvider? My current understanding is that if I have 5 providers, I can guarantee the stability and availability of the data, but then I have to wait for all nodes to return data. If I need a node with the fastest response, shouldn’t I use it? ,Looking forward to your reply

[ricmoo]

You do not need to wait for all backends to return a response, only q backends need to agree (q being the quorum, by default 50% of the backends).

You can reduce q to 1, to accept the first that responds, keeping in mind there is a stall timeout to stagger requests and reduce congestion. These parameters can all be adjusted.

The primary motivation was to allow for the default provider, which uses INFURA, Alchemy, Etherscan, Pocket, etc. which are all third-party services, while ensuring that if they become compromised or out-of-sync the results can still be trusted. The consequences of a lying node are tragic, so that is the main incentive, to guard again malice. :)

Feedback is always welcome, let me know if you have any further questions. :)

(converting this to a discussion)

[Cmonorail]

Thanks for your answer

[humblecoder]

So, is it a tool for "consensus", or closer to https://eeth.dev/docs/api/classes/FallthroughProvider? I need something closer to FallthroughProvider with basically a "first response wins" approach, and zero failure if one of the nodes happens to go down. Can you speak to this @ricmoo ?

[ricmoo]

For that, you can simply set the quorum to 1 in the constructor. :)