FAQs
short answer
you need it when you ...
- need to query for logs
- OR need to query for historical tx receipt that exist before you start the provider or rpc adapter
explanation
Transactions from unfinalized blocks only live in cache, so new transactions will usually be in the cache first (for a couple blocks), then live in both the cache and the subquery, later, after the cache expires, they only live in subquery.
Developers who run a mandala node and eth-rpc-adaptor locally, usually won’t need to start any subquery or database services for testing, since new transaction receipt will be in cache and findable without subquery, as long as there is no need for querying the transactions older than 200 blocks.
Also, logs are NOT cached (we will probably implement log cache in the future). So if your tests rely on logs, for example if they call
eth_getLogs, you will need subquery.
Cache vs. SubQuery representation
The main difference between Acala EVM+ and legacy EVM is that we need to use pre-computed
gasPrice and gasLimit combination. Manually inputting random gas parameters will fail to decode. Please refer to gas parameter section for detailed explanations.- Using an RPC call
- Using hardcoded values
- Using an SDK helper
They are suitable for different senarios:
- in Dapp: we suggest to use the RPC call to avoid importing extra dependencies of
@acala-network/eth-providers.
Metamask will sometimes cache the nonce locally, which is used to infer next tx nonce. For example, if we send a tx with nonce 3, metamask will set nonce 4 for next tx. However, after we restart the local mandala node, all accounts are reset and the nonce is back to 0, but metamaks doesn't know it!
As a result, the account with nonce 0 send a tx with nonce 4, which won't be mined and got stuck!
To solve this, we need to reset metamask after restarting local Mandala, so the nonce and cache will be cleared:
settings => advanced => reset account. Or we can simply manually override the nonce to 0 for the first metamask tx after restarting the network.Metamask shows total balance, which might include non-transferable balances. For example, if some of your ACA is staking, they will still show in metamask, but can't be transfered.
Every EVM+ transaction is essentially a substrate transaction, so we can find more details about it in substrate chain explorer.
For example, for this failing tx, we can copy and paste the tx hash into the Acala Subscan, which takes us to the tx details page, the exact error should show up in the bottom
Events section.In this case
ReserveStorageFailed means account balance not enough.
tx failed reason
there are 2 ways:
- use
eth_getBlockByNumberwithfinalizedblock tag to get the latest finalized block number, and compare the tx block number with it.
We recommend keeping 30+ ACA in account for contract deployment. This is because even if the actual deployment or contract call doesn't consume that much ACA, it still requires a little bit more when doing balance check.
For example, the tx might first reserve 30 ACA, and the acutal operation takes 10 ACA, then the remaining 20 ACA will be refund.