mirror of
git://holbrook.no/eth-monitor.git
synced 2024-11-22 04:16:45 +01:00
50 lines
2.9 KiB
Plaintext
50 lines
2.9 KiB
Plaintext
.SH MATCHING ADDRESSES
|
|
By default, addresses to match against transactions need to be explicitly specified. This behavior can be reversed with the \fB--include-default\fP option. Addresses to match are defined using the \fB--input\fP, \fB--output\fP and \fB--exec\fP options. Addresses specified multiple times will be deduplicated.
|
|
.P
|
|
Inclusion rules may also be loaded from file by specifying the \fB--includes-file\fP and \fB--excludes-file\fP options. Each file must specify the outputs, inputs and exec addresses as comma separated lists respectively, separated by tabs.
|
|
.P
|
|
In the current state of this tool, address matching will affect all parts of the processing; cache, code execution and rendering.
|
|
|
|
.SH SYNCING
|
|
When a sync is initiated, the state of this sync is persisted. This way, previous syncs that did not complete for some reason will be resumed where they left off.
|
|
.P
|
|
A special sync type \fB--head\fP starts syncing at the current head of the chain, and continue to sync until interrupted. When resuming sync, a new sync range between the current block head and the block height at which the previous \fB--head\fP sync left off will automatically be created.
|
|
.P
|
|
Syncs can be forced to (re)run for ranges regardless of previous state by using the \fB--single\fP option. However, there is no protection in place from preventing code filters from being executed again on the same transaction when this is done. See \fBDEFINING FILTERS\fP below.
|
|
|
|
|
|
.SH CACHE
|
|
When syncing, the hash of a block and transaction matching the address criteria will be stored in the cache. The hashes can be used for future data lookups.
|
|
.P
|
|
If \fB--store-block-data\fP and/or \fB--store-tx-data\fP is set, a copy of the block and/or transaction data will also be stored, respectively.
|
|
|
|
|
|
.SH RENDERING
|
|
Rendering in the context of \fBeth-monitor\fP refers to a formatted output stream that occurs independently of caching and code execution.
|
|
.P
|
|
Filters for rendering may be specified by specifying python modules to the \fB--renderer\fP option. This option may be specified multiple times.
|
|
.P
|
|
Rendering filters will be executed in order, and the first filter to return \fIFalse\fP
|
|
|
|
|
|
.SH DEFINING FILTERS
|
|
|
|
Filters will strictly be executed in the order which they are defined on the command line.
|
|
|
|
A python module used for filter must fulfill two conditions:
|
|
|
|
.IP
|
|
1. It must provide a class named \fIFilter\fP in the package base namespace.
|
|
.IP
|
|
2. The \fIFilter\fP class must extend the \fIchainsyncer.filter.SyncFilter\fP interface, and at least override the \fIfilter\fP method.
|
|
|
|
|
|
.SS SYNCER AND FILTER CONTEXT
|
|
|
|
Key-value pairs specified with `--context-key` will be passed to the filter's \fIprepare\fP method, aswell as the \fIctx\fP parameter of the \fIfilter\fP method.
|
|
|
|
|
|
.SH FURTHER READING
|
|
|
|
Refer to the \fBchainsyncer\fP chapter n \fIinfo chaintool\fP for in-depth information on the subjects of syncing and filtering.
|