EVM Strategy
What we look for when deciding which EVMS to integrate with
Last updated
What we look for when deciding which EVMS to integrate with
Last updated
A blockchain is a shared database used to store an immutable set of information. In the context of Ethereum Virtual Machine compatible blockchains, this means storing EVM bytecode.
Any EVM we integrate with must have a reliable and performant way of sending data to the blockchain.
This requires:
a performant blockchain
performant RPC nodes
In the context of blockchain an RPC (Remote procedure call) is a URL used to connect to a blockchain. More specifically an API endpoint (applied programming interface) that will submit your request to a blockchain on your behalf.
For a Metamask user your RPC configuration is found in:
Settings -> Networks -> Choose a Network
The two important fields here are
Chain ID: This is a specific identifier for the EVM network
RPC URL: This is the API endpoint URL used to perform remote procedure calls.
Having a reliable default RPC supported by the EVM network is CRITICAL to the success of the EVM.
Central Point of Failure
When too many requests (be it legitimate or DDOS) attempt to call the network at the same time bad things can happen.
APIs are forced to rate limit the RPC endpoint which means when a user tries to perform a transaction they see something like this.
Or This
JSON-RPC is a specific type of RPC call designed for use with Ethereum.
Anyone can independently run their own RPC node. But this should be a public good provided by the EVM network using their tokens as resources to pay for the RPC.
If we ran our own RPC node and switched users to our hosted RPC network, we would then also have to pay for the bandwidth of any other service they use in the future.
Community funds alone should be sufficient on any EVM to support robust network funded RPC infrastructure so dApp developers can focus on building their dApps instead of hassling with RPC errors.
Too many developers, end users, and/or bots are trying to use the network
Short term Solution:
Internal JSON RPC Errors are coming because of Infura's rate limit. Not our infura app, Matic Mainnet's public RPC app. The solution to this is to connect to a different JSON RPC on Metamask or just wait a minute or so for the rate limit to reset. This is terrible for user experience and can cost many sales when users get frustrated before completing a transaction.
Long term Solution:
Choose to deploy on EVMs with robust RPC endpoints that run multiple full nodes which can dynamically redirect traffic.
Issues at the blockchain level
Keep nodes in sync
Manage mempool size. If the network gets clogged with a backlog of transactions to process this can cause the RPC nodes to get out of sync with the current state of the blockchain
Decrease Latency. So validator nodes retain as close to real time syncing with the current processed blocks as possible.
Build out excess capacity for the main RPC node that can dynamically fail over to other RPC nodes if the network detects rate limiting is occurring.
What is your RPC node capacity and expansion strategy?
What is your block processing capacity and expansion strategy?
How do you ensure reliable confirmation without re-org risk?
Each EVM we integrate with we perform automated scripts to test network performance.
This involves creating an NFT smart contract with very low priced tokens (1000 gwei) and a very large maximum mint size
We then run an automated script to purchase NFTs on each EVM which records
confirmation time
gas price
error logs (specifically RPC related API rate limiting errors)
Integrated
Polygon/MATIC - Currently experienced network degradation and RPC errors. See https://forum.polygon.technology/t/investigating-reorg-and-rpc-issues-on-polygon-pos/2190
Binance Smart Chain - Reliable L1 confirms transactions as expected
Ethereum Mainnet - Reliable L1 confirms transactions as expected
Potential Future Integrations
Fantom
Avalanche
Algorand
Terra
Skale
