Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

letter-coded sync modes instead of full, archive etc. #119

Closed
AlexeyAkhunov opened this issue Oct 17, 2019 · 2 comments · Fixed by #229
Closed

letter-coded sync modes instead of full, archive etc. #119

AlexeyAkhunov opened this issue Oct 17, 2019 · 2 comments · Fixed by #229

Comments

@AlexeyAkhunov
Copy link
Contributor

AlexeyAkhunov commented Oct 17, 2019

Some database buckets are mandatory for successful sync and block processing. For example, AT (current state of accounts), ST (current state of contract storage), SUFFIX (changesets used for rewinding). Other buckets are optional and only add value for certain users. We would like users to have flexibility to pick and choose those buckets in any combination. Users may specify the mode of operation as a combination of one-letter flags (similar to unix tar command). Here are suggested flags:

  1. r Transaction receipts. Currently turned off by default. If turned on, receipts are written to a special bucket, which is then used to server getTransactionReceipt and getLogs RPC commands. In blockchain.go this is set by EnableReceipts(true)
  2. h History of state. These are buckets hAT (history of state of accounts) and hST (history of state of contract storage). Although these buckets contain the same information as the SUFFIX (change-set) bucket, it is organised for quick access using addressHash | blockNr composite key for accounts, and addressHash | incarnation | blockNr composite key for contract storage. Bucket SUFFIX is organised for quick access for composite keys "hAT" | blockNr and "hST" | blockNr. History of state is used for answering various RPC queries related to account balances, contract storage contents at some point in the past.
  3. t Index allowing to look up block number and transaction index given a transaction hash. It is used by RPC requests such as getTransaction, because it allows retrieving the body of the transaction from the bucket with blocks
  4. p preimages for address hashes and storage key hashes. This information is needed by RPC queries such as getModifiedAccounts and getStorageRangeAt.
  5. Block headers and bodies? In order to perform reorgs, some short history of alternative blocks and headers is required.

Some examples of which modes might be useful for different use-cases:

  • Miners would prefer to turn all the flags off, they only care about the current state and occasional reorgs. Their priority - low latency of block processing, and lowering I/O would definitely help
  • Exchanges would need preimages (p) and history (h) to be able to watch for deposits. If they use logs (events) to figure out token transfers, they might also want to turn on receipts (r) for better performance
  • Block explorers might want to turn everything on
  • Dapp Web sites would want to turn on receipts (r) for better scanning of the logs (lots of dapp use logs as a substitute for storage).
@mandrigin
Copy link
Contributor

@AlexeyAkhunov I'm not sure about using h, because it is a well known shortcut for help (vi -h, etc). maybe we can either use them as --mode=rhtp (I would prefer that) or use a capital H.

@AlexeyAkhunov
Copy link
Contributor Author

@mandrigin Yes, I think the idea is to use --mode=rhtp

@yperbasis yperbasis added this to the Release 1 milestone Nov 12, 2019
cffls pushed a commit to cffls/erigon that referenced this issue Feb 14, 2024
* more counters and some streamlining on creation contract handling

* last of the opcode zk counters implemented

* slightly nicer handling of process tx for counters

* correctly handling bytecodesize and inputsize in zk counters

* counters handling nonce bytes and isCreate vs isDeploy logic fixed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants