🔹[EPIC] Improvements to Multichain Gas Relayer Docs for Mainnet Launch

[ravigautham]

Is your feature request related to a problem? Please describe. We are working towards a Mainnet launch for the Multichain Gas Relayer in June (along with Chain Signatures), and there are some enhancements we can make to the documentation.

Describe the solution you'd like

• [x] We should create a new page that provides a holistic overview of the Multichain Gas Relayer, this would involve a brief description and an up-to-date technical design diagram. Right now it is confusing to only have pages for the separate components of the system.

• [x] Under the Multichain Gas Relayer section in the navigation menu we should move "Multichain Gas Station" to be the first item and rename it to be "Multichain Gas Station Contract". The contract is the first component that a developer would interact with

On the Multichain Relayer Server page we should make the following changes:

• [x] Improved visual of technical system design diagram, would it be possible to recreate this to make the components more visible and we can move this diagram to the new section I described above ^
• [x] For the "Paymaster" section we need to add more details on the number of paymaster accounts that developers need to create and fund on destination chains. We need to highlight that having multiple paymaster accounts and rotating through them will be important for avoiding issues with nonces on destination chains. @encody Is there any specific process/guidelines we can provide devs on determining the number of paymaster addresses required? Does it scale with the number of transactions/users?
• [ ] In the "System Workflow" section we need to update the "canhazgas.testnet" to reference the specific mainnet contract that a developer deploys (In step 1.ii)
• [x] Add a deeplink to the settlement section in step 6. for "Cross Chain Settlement"

On the Multichain Gas Station Contract page we should make the following changes:

• [ ] In the gas fee estimation section, we reference BSC chain specifically but make no reference to other chains like ETH. We should add more context here. Maybe we can create a table that lists all supported chains and the corresponding gas fees associated for transferring funds?

Additional context Add any other context or screenshots about the feature request here.

### Tasks
- [ ] https://github.com/near/docs/issues/2012
- [x] Create improved technical system design diagram (Multichain relayer)
- [ ] https://github.com/near/docs/issues/2013
- [ ] https://github.com/near/docs/issues/2014

[ravigautham]

@encody Hey Jacob, I just drafted this issue to improve the MC Gas Relayer docs for the upcoming mainnet launch in June. Let me know what you think about these improvements.

cc @bucanero @gagdiez

[encody]

It is difficult to make recommendations about multiple paymaster accounts. Actually, if the relayer/transaction forwarder is fast enough, only one might be enough. Until we have actual performance/usage data, it is difficult to say.

For independent deployments of gas station contracts, generally, nonce synchronicity should be addressed using these three measures, in this order of preference:

1. Users/clients of the smart contract submit signed payloads independently.
   • This is the least reliable option; it is not wise to leave this up to the users, but it is potentially the lowest-latency option. Therefore, while this should be the first option in order of precedence, it must not be the only option.
2. The relayer service picks up signed payloads and submits them to the remote chain.
   • This relayer service provides the guarantee to the smart contract that signed payloads will make it to the remote chain and update the nonce.
3. Using multiple paymaster accounts.
   • This is a stopgap measure that essentially only serves as a small buffer in case the relayer service falls behind, or some of the paymaster nonces (temporarily) get out-of-sync. Adding more paymasters will not eliminate nonce synchronicity issues if they exist; it will only reduce latency for users while the system is working and experiencing high traffic.

[ravigautham]

Thanks adding your thoughts @encody!

@thisisjoshford I think we can slot this issue for execution in the coming weeks.

[charleslavon]

@bucanero is there still work to be done here or can this be closed?

[ravigautham]

@charleslavon @bucanero There's actually some additional updates we want to make to these docs leading to launch at the end of July. I'll be following up next week with more info. So we can keep this open for now.

[ravigautham]

@thisisjoshford I'll be sharing a doc sometime next week. Also added Anthony to this issue, he'll be adding context

[ravigautham]

cc @anthony-near