Why "sendTransaction" in case of Fallback provider is broadcasted using all the rpcs #4613
Replies: 1 comment
-
The primary goal (originally) of the FallbackProvider was to allow decentralized behaviour against centralized providers. So, for example backing your interactions against Etherscan, INFURA and Alchemy, means that even if one of those services decided to censor you or return wrong data, the other two would continue to provide you accurate data. While the original intention was to protect against intentional or malicious backends, it has also served well in cases where a service was offline, as most services backed by Ethers didn’t even notice since they would just fallback onto the other backends. :) For sending transactions, it is signed (with a nonce) and sent to the network where it sits in the mempool until a block producers (formerly miners) includes it in a block. It is therefore safe to be sent to the network multiple times, and has an associated DoS-mitigating cost, and so by sending it to all the backends protects even further from censorship or bad backends; as long as any one of the services passes it to the gossip network, it will get included properly. The main reason other calls only require a quorum of 2 is reduce latency and provider request costs, but sendTransaction is also relatively rare, so it is relatively low overhead, and sending a transaction is a more important operation. I think kinda rambled on a bit, but please feel free to ask follow-up, clarifying questions. I have plenty of opinions on being as trustless as possible, but balanced against the real-world costs associated with blockchains and using third-party providers. :) |
Beta Was this translation helpful? Give feedback.
-
In fallback provider code, there is comment mention "sendtransaction" is a special call where it is broadcasted to all backends there we are sending transaction to blockchain from all the rpcs why?
Beta Was this translation helpful? Give feedback.
All reactions