Switch to JSON-RPC as de facto provider implementation

[xJonathanLEI]

Full node fee estimation has just been implemented by pathfinder: https://github.com/eqlabs/pathfinder/pull/388

Now the full node JSON-RPC implementation has everything we need to implement a transaction sender. We should probably move away from the sequencer gateway.

Only one problem: due to the lack of a decentralized mempool, currently all the write methods are just proxied to the sequencer gateway. Therefore, if a full node is used by many people at the same time, you're more likely to get rate limited than just going to the sequencer yourself.

Should we wait for the mempool be become available (which will take some very long time I guess)? Or do we just do it anyways? Or do we take a hybird approach, where all the write methods are sent directly to the sequencer (probably with an option to go thru JSON-RPC instead anyways)?

[bbrandtom]

This is only an issue if you use an API provider (e.g. Chainstack) right? Running a local node should not have this problem

[xJonathanLEI]

Yes you're right. I guess with Infura coming into the field they should be able to properly handle the rate limit issue anyways (maybe getting whitelisted by StarkWare idk). By then even those using public RPC should be fine.

Personally I would really love to see JSONRPC becoming the defacto way of interacting with StarkNet. There are just still a few issues out there, including handling of pending state. Hope they get resolved sooner.