mirror of
https://github.com/status-im/status-go.git
synced 2025-01-09 06:12:55 +00:00
a92a95cf83
*** How it worked before this PR on multiaccount creation:
- On multiacc creation we scanned chain for eth and erc20 transfers. For
each address of a new empty multiaccount this scan required
1. two `eth_getBalance` requests to find out that there is no any
balance change between zero and the last block, for eth transfers
2. and `chain-size/100000` (currently ~100) `eth_getLogs` requests,
for erc20 transfers
- For some reason we scanned an address of the chat account as well, and
also accounts were not deduplicated. So even for an empty multiacc we
scanned chain twice for each chat and main wallet addresses, in result
app had to execute about 400 requests.
- As mentioned above, `eth_getBalance` requests were used to check if
there were any eth transfers, and that caused empty history in case
if user already used all available eth (so that both zero and latest
blocks show 0 eth for an address). There might have been transactions
but we wouldn't fetch/show them.
- There was no upper limit for the number of rpc requests during the
scan, so it could require indefinite number of requests; the scanning
algorithm was written so that we persisted the whole history of
transactions or tried to scan form the beginning again in case of
failure, giving up only after 10 minutes of failures. In result
addresses with sufficient number of transactions would never be fully
scanned and during these 10 minutes app could use gigabytes of
internet data.
- Failures were caused by `eth_getBlockByNumber`/`eth_getBlockByHash`
requests. These requests return significantly bigger responses than
`eth_getBalance`/`eth_transactionsCount` and it is likely that
execution of thousands of them in parallel caused failures for
accounts with hundreds of transactions. Even for an account with 12k
we could successfully determine blocks with transaction in a few
minutes using `eth_getBalance` requests, but `eth_getBlock...`
couldn't be processed for this acc.
- There was no caching for for `eth_getBalance` requests, and this
caused in average 3-4 times more such requests than is needed.
*** How it works now on multiaccount creation:
- On multiacc creation we scan chain for last ~30 eth transactions and
then check erc20 in the range where these eth transactions were found.
For an empty address in multiacc this means:
1. two `eth_getBalance` transactions to determine that there was no
balance change between zero and the last block; two
`eth_transactionsCount` requests to determine there are no outgoing
transactions for this address; total 4 requests for eth transfers
2. 20 `eth_getLogs` for erc20 transfers. This number can be lowered,
but that's not a big deal
- Deduplication of addresses is added and also we don't scan chat
account, so a new multiacc requires ~25 (we also request latest block
number and probably execute a few other calls) request to determine
that multiacc is empty (comparing to ~400 before)
- In case if address contains transactions we:
1. determine the range which contains 20-25 outgoing eth/erc20
transactions. This usually requires up to 10 `eth_transactionCount`
requests
2. then we scan chain for eth transfers using `eth_getBalance` and
`eth_transactionCount` (for double checking zero balances)
3. we make sure that we do not scan db for more than 30 blocks with
transfers. That's important for accounts with mostly incoming
transactions, because the range found on the first step might
contain any number of incoming transfers, but only 20-25 outgoing
transactions
4. when we found ~30 blocks in a given range, we update initial
range `from` block using the oldest found block
5. and now we scan db for erc20transfers using `eth_getLogs`
`oldest-found-eth-block`-`latest-block`, we make not more than 20 calls
6. when all blocks which contain incoming/outgoing transfers for a
given address are found, we save these blocks to db and mark that
transfers from these blocks are still to be fetched
7. Then we select latest ~30 (the number can be adjusted) blocks from
these which were found and fetch transfers, this requires 3-4
requests per transfer.
8. we persist scanned range so that we know were to start next time
9. we dispatch an event which tells client that transactions are found
10. client fetches latest 20 transfers
- when user presses "fetch more" button we check if app's db contains next
20 transfers, if not we scan chain again and return transfers after
small fixes
112 lines
2.9 KiB
SQL
112 lines
2.9 KiB
SQL
CREATE TABLE IF NOT EXISTS settings (
|
|
type VARCHAR PRIMARY KEY,
|
|
value BLOB
|
|
) WITHOUT ROWID;
|
|
|
|
CREATE TABLE IF NOT EXISTS accounts (
|
|
address VARCHAR PRIMARY KEY,
|
|
wallet BOOLEAN,
|
|
chat BOOLEAN,
|
|
type TEXT,
|
|
storage TEXT,
|
|
pubkey BLOB,
|
|
path TEXT,
|
|
name TEXT,
|
|
color TEXT,
|
|
created_at DATETIME NOT NULL,
|
|
updated_at DATETIME NOT NULL
|
|
) WITHOUT ROWID;
|
|
|
|
CREATE UNIQUE INDEX unique_wallet_address ON accounts (wallet) WHERE (wallet);
|
|
CREATE UNIQUE INDEX unique_chat_address ON accounts (chat) WHERE (chat);
|
|
CREATE INDEX created_at_account ON accounts (created_at) WHERE (created_at);
|
|
|
|
CREATE TABLE IF NOT EXISTS browsers (
|
|
id TEXT PRIMARY KEY,
|
|
name TEXT NOT NULL,
|
|
timestamp USGIGNED BIGINT,
|
|
dapp BOOLEAN DEFAULT false,
|
|
historyIndex UNSIGNED INT
|
|
) WITHOUT ROWID;
|
|
|
|
CREATE TABLE IF NOT EXISTS browsers_history (
|
|
browser_id TEXT NOT NULL,
|
|
history TEXT,
|
|
FOREIGN KEY(browser_id) REFERENCES browsers(id) ON DELETE CASCADE
|
|
);
|
|
|
|
CREATE TABLE IF NOT EXISTS dapps (
|
|
name TEXT PRIMARY KEY
|
|
) WITHOUT ROWID;
|
|
|
|
CREATE TABLE IF NOT EXISTS permissions (
|
|
dapp_name TEXT NOT NULL,
|
|
permission TEXT NOT NULL,
|
|
FOREIGN KEY(dapp_name) REFERENCES dapps(name) ON DELETE CASCADE
|
|
);
|
|
|
|
|
|
CREATE TABLE IF NOT EXISTS transfers (
|
|
network_id UNSIGNED BIGINT NOT NULL,
|
|
hash VARCHAR NOT NULL,
|
|
address VARCHAR NOT NULL,
|
|
blk_hash VARCHAR NOT NULL,
|
|
tx BLOB,
|
|
sender VARCHAR,
|
|
receipt BLOB,
|
|
log BLOB,
|
|
type VARCHAR NOT NULL,
|
|
blk_number BIGINT NOT NULL,
|
|
timestamp UNSIGNED BIGINT NOT NULL,
|
|
loaded BOOL DEFAULT 1,
|
|
FOREIGN KEY(network_id,address,blk_hash) REFERENCES blocks(network_id,address,blk_hash) ON DELETE CASCADE,
|
|
CONSTRAINT unique_transfer_per_address_per_network UNIQUE (hash,address,network_id)
|
|
);
|
|
|
|
CREATE TABLE IF NOT EXISTS blocks (
|
|
network_id UNSIGNED BIGINT NOT NULL,
|
|
address VARCHAR NOT NULL,
|
|
blk_number BIGINT NOT NULL,
|
|
blk_hash BIGINT NOT NULL,
|
|
loaded BOOL DEFAULT FALSE,
|
|
CONSTRAINT unique_mapping_for_account_to_block_per_network UNIQUE (address,blk_hash,network_id)
|
|
);
|
|
|
|
CREATE TABLE IF NOT EXISTS blocks_ranges (
|
|
network_id UNSIGNED BIGINT NOT NULL,
|
|
address VARCHAR NOT NULL,
|
|
blk_from BIGINT NOT NULL,
|
|
blk_to BIGINT NOT NULL
|
|
);
|
|
|
|
CREATE TABLE IF NOT EXISTS mailservers (
|
|
id VARCHAR PRIMARY KEY,
|
|
name VARCHAR NOT NULL,
|
|
address VARCHAR NOT NULL,
|
|
password VARCHAR,
|
|
fleet VARCHAR NOT NULL
|
|
) WITHOUT ROWID;
|
|
|
|
CREATE TABLE IF NOT EXISTS mailserver_request_gaps (
|
|
gap_from UNSIGNED INTEGER NOT NULL,
|
|
gap_to UNSIGNED INTEGER NOT NULL,
|
|
id TEXT PRIMARY KEY,
|
|
chat_id TEXT NOT NULL
|
|
) WITHOUT ROWID;
|
|
|
|
CREATE INDEX mailserver_request_gaps_chat_id_idx ON mailserver_request_gaps (chat_id);
|
|
|
|
CREATE TABLE IF NOT EXISTS mailserver_topics (
|
|
topic VARCHAR PRIMARY KEY,
|
|
chat_ids VARCHAR,
|
|
last_request INTEGER DEFAULT 1,
|
|
discovery BOOLEAN DEFAULT FALSE,
|
|
negotiated BOOLEAN DEFAULT FALSE
|
|
) WITHOUT ROWID;
|
|
|
|
CREATE TABLE IF NOT EXISTS mailserver_chat_request_ranges (
|
|
chat_id VARCHAR PRIMARY KEY,
|
|
lowest_request_from INTEGER,
|
|
highest_request_to INTEGER
|
|
) WITHOUT ROWID;
|