Retrieval chain with zebra and zips repos

Ask me any technical questions about zebra or quiz me about which ZIPs say what and I’ll report what the RAG bot says.

5 Likes

List rpc commands for all the capabilities of a full zebra node?

Can zebra be used as a web server or reverse proxy?

List available zebra node configuration options for the node configuration file?

In [1]: chat(“List rpc commands for all the capabilities of a full zebra node”)
A full Zebra node supports various RPC commands that allow interaction with the Zcash blockchain. These commands are utilized by wallets, block explorers, and other applications for retrieving information from the blockchain or submitting data to it. Below is a list of RPC commands that highlight the capabilities of a full Zebra node:

  1. getinfo: Returns basic information about the Zebra node and the Zcash network it’s connected to.

  2. getblock: Retrieves a specific block by its hash or height, returning details about the block in JSON format. This command can be used to fetch block data, including transactions.

  3. getblockhash: Given a block height, this command returns the block hash, allowing users to query specific blocks in the blockchain.

  4. getblockcount: Returns the height of the latest block in the blockchain, providing an overview of the current size of the blockchain.

  5. getblocktemplate: This command is used by miners to request a block template for mining new blocks. It returns data needed for constructing a block that can be submitted to the network upon successful mining.

  6. submitblock: Allows submitting a new block to the blockchain. This is typically used by miners after successfully mining a block.

  7. getrawtransaction: Retrieves the raw transaction data for a given transaction ID. This command can be used to inspect transaction details that are not readily visible in block explorations.

  8. sendrawtransaction: Submits a raw transaction to the network. This command is used for broadcasting a transaction that has been created offline or by another service.

  9. getaddressbalance: Queries the balance of a given Zcash address, allowing users to check the amount of ZEC held by an address.

  10. getaddresstxids: Returns the transaction IDs associated with a specific Zcash address, useful for tracking the transaction history of an address.

  11. getaddressutxos: Fetches unspent transaction outputs (UTXOs) for a given address, which is essential for constructing new transactions.

  12. getpeerinfo: Provides details about the peers connected to the Zebra node, including information such as IP addresses, connection status, and more.

  13. addnode: Manually adds a node to the peer list of the Zebra node, allowing for direct connection to specified peers.

  14. disconnectnode: Disconnects a node from the Zebra node’s peer list, useful for managing network connections.

  15. getchaintips: Returns information about all known blockchain forks, including the main chain and any side chains.

  16. getmempoolinfo: Provides information about the current state of the transaction mempool, including the number of transactions waiting to be confirmed.

  17. getbestblockhash: Returns the hash of the highest block in the longest blockchain, indicating the most recent block.

  18. getdifficulty: Shows the current difficulty target for the next block to be mined, reflecting the network’s mining difficulty.

These RPC commands enable comprehensive interaction with the Zcash blockchain through a Zebra node, covering functionalities from basic blockchain queries to transaction submission and block mining support.

In [2]: memory.clear()

In [3]: chat(“Can zebra be used as a web server or reverse proxy?”)
No, Zebra cannot be used as a web server or reverse proxy. Zebra is an implementation of a Zcash node, designed for network participation, block and transaction validation, and related functionalities within the Zcash blockchain ecosystem. It does not have the capabilities to serve as a web server or perform the functions of a reverse proxy, which involve handling HTTP requests, serving web content, or distributing incoming network traffic across multiple servers for load balancing. For web server or reverse proxy functionalities, software specifically designed for those purposes, such as Nginx or Apache HTTP Server, should be used.

In [4]: memory.clear()

In [5]: chat(“List available zebra node configuration options for the node configuration file?”)
The Zebra node configuration options are specified in the zebrad.toml file. Below is a comprehensive list of available configuration sections and their respective options based on the provided configuration examples and documentation:

[consensus]

  • checkpoint_sync: Enables checkpoint-based verification up to the Sapling activation height, speeding up the initial chain sync. (Boolean)
  • debug_skip_parameter_preload: Skips Groth16 parameter download and verification. This option is for development use only. (Boolean)

[mempool]

  • eviction_memory_time: The time duration a transaction remains in the mempool before being evicted. (Duration, e.g., ‘1h’)
  • tx_cost_limit: The total cost limit of all transactions in the mempool. (Integer)

[metrics]

This section is reserved for metrics-related configurations but does not have specific options listed in the provided examples.

[mining]

This section is reserved for mining-related configurations but does not have specific options listed in the provided examples.

[network]

  • crawl_new_peer_interval: The time interval between each attempt to discover new peer addresses. (Duration, e.g., ‘1m 1s’)
  • initial_mainnet_peers: A list of initial peers for the Zcash mainnet. (Array of strings)
  • initial_testnet_peers: A list of initial peers for the Zcash testnet. (Array of strings)
  • listen_addr: The local address and port on which the node listens for incoming connections. (String, e.g., ‘0.0.0.0:8233’)
  • network: Specifies the blockchain network (‘Mainnet’ or ‘Testnet’). (String)
  • peerset_initial_target_size: The target size for the initial set of peers. (Integer)
  • max_connections_per_ip: (Optional) Limits the maximum number of connections per IP address. (Integer)
  • cache_dir: (Optional) Enables or specifies the cache directory. (Boolean or String)

[rpc]

  • debug_force_finished_sync: Forces the sync service to consider the sync finished. This option is for development use only. (Boolean)
  • parallel_cpu_threads: The number of CPU threads to use for parallel operations in the RPC interface. (Integer)

[state]

  • cache_dir: Specifies the directory used for the state cache. (String)
  • delete_old_database: Whether to delete the old state database when starting. (Boolean)
  • ephemeral: If true, Zebra does not store the chain state between runs. (Boolean)

[sync]

  • checkpoint_verify_concurrency_limit: The maximum number of concurrent checkpoint verifications. (Integer)
  • download_concurrency_limit: The maximum number of concurrent block downloads. (Integer)
  • full_verify_concurrency_limit: The maximum number of concurrent block verifications after the checkpoint range. (Integer)
  • parallel_cpu_threads: The number of CPU threads to use for parallel operations in the sync service. (Integer)

[tracing]

  • buffer_limit: The maximum size of the tracing buffer. (Integer)
  • force_use_color: Forces the use of colors in log output. (Boolean)
  • use_color: Enables the use of colors in log output if the terminal supports it. (Boolean)
  • use_journald: Enables logging to the systemd journal. (Boolean)

These options allow for extensive customization of the Zebra node’s behavior, including its consensus mechanism, mempool management, network settings, RPC interface, state management, synchronization process, and logging/tracing capabilities.

Seems plausible. Fact check?

Looking Good,

New Questions:

Demonstrate a zcash sendrawtransaction using a zebra node to the zcash network?

Give an example zcash.toml configuration file?

How to create a pruned zebra node?

Well, if it doesn’t know then submitting a raw tx to zebra is just like zcashd, for example

curl --data-binary ‘{“jsonrpc”: “1.0”, “id”:“curltest”, “method”: “sendrawtransaction”, “params”: [“signedhex”] }’ -H ‘content-type: text/plain;’ http://127.0.0.1:8232/

The zebrad.toml configuration file needs the “listen_addr = ‘127.0.0.1:8232’” line under [RPC]

zebrad, by default, generates and uses a file named ‘zebrad.toml’ in the ‘.config’ folder for the configuration, though you could rename it ‘zcash.toml’, or whatever you like, assuming you use the --conf flag to point to the correct file. The contents for a default configuration file can be generated with ‘zebrad generate’. The current default is

❯ zebrad generate

Default configuration for zebrad.

This file can be used as a skeleton for custom configs.

Unspecified fields use default values. Optional fields are Some(field) if the

field is present and None if it is absent.

This file is generated as an example using zebrad’s current defaults.

You should set only the config options you want to keep, and delete the rest.

Only a subset of fields are present in the skeleton, since optional values

whose default is None are omitted.

The config format (including a complete list of sections and fields) is

documented here:

ZebradConfig in zebrad::config - Rust

zebrad attempts to load configs in the following order:

1. The -c flag on the command line, e.g., zebrad -c myconfig.toml start;

2. The file zebrad.toml in the users’s preference directory (platform-dependent);

3. The default config.

The user’s preference directory and the default path to the zebrad config are platform dependent,

based on dirs::preference_dir, see preference_dir in dirs - Rust :

| Platform | Value | Example |

| -------- | ------------------------------------- | ---------------------------------------------- |

| Linux | $XDG_CONFIG_HOME or $HOME/.config | /home/alice/.config/zebrad.toml |

| macOS | $HOME/Library/Preferences | /Users/Alice/Library/Preferences/zebrad.toml |

| Windows | {FOLDERID_RoamingAppData} | C:\Users\Alice\AppData\Local\zebrad.toml |

[consensus]
checkpoint_sync = true

[mempool]
eviction_memory_time = “1h”
tx_cost_limit = 80000000

[metrics]

[mining]
debug_like_zcashd = true

[network]
cache_dir = true
crawl_new_peer_interval = “1m 1s”
initial_mainnet_peers = [
“dnsseed.z.cash:8233”,
“dnsseed.str4d.xyz:8233”,
mainnet.seeder.zfnd.org:8233”,
“mainnet.is.yolo.money:8233”,
]
initial_testnet_peers = [
“dnsseed.testnet.z.cash:18233”,
testnet.seeder.zfnd.org:18233”,
“testnet.is.yolo.money:18233”,
]
listen_addr = “0.0.0.0:8233”
max_connections_per_ip = 1
network = “Mainnet”
peerset_initial_target_size = 25

[rpc]
debug_force_finished_sync = false
parallel_cpu_threads = 0

[state]
cache_dir = “/home/john/.cache/zebra”
delete_old_database = true
ephemeral = false

[sync]
checkpoint_verify_concurrency_limit = 1000
download_concurrency_limit = 50
full_verify_concurrency_limit = 20
parallel_cpu_threads = 0

[tracing]
buffer_limit = 128000
force_use_color = false
use_color = true
use_journald = false

Zebra currently can’t be pruned. Current total DB size is

2024-05-13T17:08:31.031601Z INFO zebra_state::service::finalized_state::disk_db: Total Live Data Disk Size: 264.1 GB