-
Notifications
You must be signed in to change notification settings - Fork 30
Usage
The recommended way to configure Blutgang is via the config file:
# To use the config file, use the -c/--config option pointing to the path of a config file
# Config for blutgang goes here
[blutgang]
# Clear the cache DB on startup
do_clear = false
# Where to bind blutgang to
address = "127.0.0.1:3000"
# Moving average length for the latency
ma_length = 100
# Sort RPCs by latency on startup. Recommended to leave on.
sort_on_startup = true
# Enable health checking
health_check = true
# Enable content type header checking. Set this to `true` if you want
# Blutgang to be JSON-RPC compliant.
header_check = true
# Acceptable time to wait for a response in ms
ttl = 30
# How many times to retry a request before giving up
max_retries = 32
# Block time in ms, used as a sanity check when not receiving subscriptions
expected_block_time = 13000
# Time between health checks in ms
health_check_ttl = 400
# Supress the health check running info messages
supress_rpc_check = false
# Note: the admin namespace contains volatile functions and
# should not be exposed publicly.
[admin]
# Enable the admin namespace
enabled = false
# Address for the admin RPC
address = "127.0.0.1:5715"
# Only allow read-only methods
# Recommended `true` unless you 100% need write methods
readonly = true
# Enable the use of JWT for auth
# Should be on if exposing to the internet
jwt = false
# jwt token
key = ""
# Sled config
# Sled is the database we use for our cache, for more info check their docs
[sled]
# Path to db
db_path = "./blutgang-cache"
# sled mode. Can be HighThroughput/LowSpace
mode = "HighThroughput"
# Cache size in bytes.
cache_capacity = 1000000000
# Use zstd compression. Reduces size 60-70%,
# and increases CPU and latency by around 10% for db writes and 2% for reads.
# If storage constrained, it's fine to have it be on.
compression = false
# Print DB profile when dropped. Doesn't do anything for now.
print_profile = false
# Frequency of flushes in ms
flush_every_ms = 240
# Add separate RPCs as TOML tables
# DO NOT name an rpc `blutgang`, `admin`, or `sled`
[merkle]
url = "https://eth.merkle.io"
ws_url = "wss://eth.merkle.io"
# The maximum amount of time we can use this rpc in a row.
max_consecutive = 150
# Max amount of queries per second.
max_per_second = 200
To use the config file, use the -c/--config option pointing to the path of a config file:
blutgang -c ./config.tomlIf you prefer to use command line arguments, you can find the equivalent CLI options using blutgang --help. This is not recommended as you cannot configure individual RPC access settings.
If Blutgang started successfully, you will see output similar to this:
Using config file at ./config.toml...
Sorting RPCs by latency...
https://eth.llamarpc.com: 40414699.6ns
http://redacted:8945: 64087717.5ns
https://eth-mainnet.g.alchemy.com/v2/redacted: 194172905.3ns
Bound to: 127.0.0.1:3000
Reorg detected!
Removing stale entries from the cache...You can now use Blutgang by forwarding your RPC requests to the address provided in the config! In this case: 127.0.0.1:3000.
An uncached request forwarded to blutgang will produce the following output:
Forwarding to: https://eth.llamarpc.com
Request time: 30.602093ms
LA 35330012.25-
Forwarding to: RPC we're sending request to -
Request time: Time between sending the request, blutgang processing it, and sending it back -
LA: Latency average for that RPC in microseconds.
Request time: 4.292µs
Request time: 6.917µs
Request time: 4.375µsA request produces only Request time if it's queried from the cache.
You will occasionally see the following output that relates to the health of your RPC endpoints and the network:
Checking RPC health... OK!
New finalized block!
Removing stale entries from the cache...-
Checking RPC health...: Blutgang will occasionally check if your nodes are responsive and following the tip of the chain. The period for this check is specified in the config -
New finalized block!: A new block has been finalized, meaning that everything before it can not be reorged. Blutgang will delete all stale entries in it's reorg hash storage, freeing up memory. -
Reorg detected!: The chain has been reorged, meaning its state has changed. Blutgang will revert all unfinalized changes made to the database to compensate.