# Fieres Blockchain ## Overview Fieres is an open-source platform for launching decentralized applications and enterprise blockchain deployments in one interoperable, highly scalable ecosystem. Fieres Blockchain is the first decentralized smart contracts platform built for the scale of global finance, with near-instant transaction finality. Ethereum developers can quickly build on the Fieres blockchain as Solidity works out of the box. Fieres is a fast, scalable, and secure layer-1 platform built on the POA consensus protocol. # How can I add Fieres to Metamask? To connect with Metamask to Fieres network, you should go to Metamask network settings and paste following parameters. \ **Mainnet Configuration Parameters:** Network Name: `Fiero Blockchain - Mainnet` **RPC URL 1:** rpc1.fieroscan.com **RPC URL 2:** rpc2.fieroscan.com **RPC1 URL 3:** rpc3.fieroscan.com **RPC1 URL 4:** rpc4.fieroscan.com **RPC1 URL 5**: rpc5.fieroscan.com **ChainID**: `1001` **Symbol**: `FS` **Block Explorer URL:** # What is Blockchain? A blockchain is a shared, publicly accessible database that is shared among numerous computers in a network. Data and information are kept in units called "blocks," which are grouped together in sequential order. The transaction data must be included in a block in order for Fiero to be sent to a recipient. The term "chain" describes how each block contains a cryptographic reference to its parent. Blocks are therefore connected together. The data in a block cannot be modified without also changing all blocks that come after it, which would necessitate network-wide consensus. Every computer in the network must agree to accept both the chain as a whole and each new block. "Nodes" are the titles given to these computers. Nodes ensure that the same data is accessible to everyone using the blockchain. A consensus mechanism is required for blockchains in order to implement this distributed agreement.
In blockchain platforms, consensus mechanisms can be divided into permissionless (Bitcoin, Etherium) and permissioned (Apla, Ethereum Private). In a permissioned blockchain, all nodes are pre-authenticated. This advantage allows to use of consensus types that provide a high transaction rate in addition to other benefits. One of these consensus types is Proof-of-Authority (POA) consensus. Proof-of-Authority (POA) is a new consensus algorithms family that provides high performance and fault tolerance. In POA, rights to generate new blocks are awarded to nodes that have proven their authority to do so. To gain this authority and a right to generate new blocks, a node must pass a preliminary authentication. The network's nodes check and verify new blocks once they are broadcast to them, updating everyone's knowledge of the blockchain's current state. # What is Fieres? The native cryptocurrency of the Fieres Blockchain is called Fiero. In order to provide a market for computation, Fiero was created. Such a market gives participants a financial incentive to validate and execute transaction requests and gives the network computational resources. Any participant that broadcasts a transaction request is also required to provide a bounty to the network in the form of some Fiero. Whoever completes the process of verifying the transaction, carrying it out, committing it to the blockchain, and broadcasting it to the network will ultimately receive this payout. # What are Smart Contracts? In reality, participants don't create fresh code each time they need to ask the EVM to perform a computation. Instead, programmers for applications upload programmes (reusable bits of code) into the EVM state, and users submit requests to run these bits of code with various parameters. The programmes that are uploaded to and run by the network are referred to as smart contracts. At its most basic level, a smart contract can be compared to a type of vending machine: a script that, when invoked with specific parameters, does certain actions or computations if specific criteria are met. For instance, if the caller transfers Fiero to a particular receiver, a straightforward vendor smart contract might generate and assign ownership of a digital asset. With the blockchain serving as its data layer, any developer may build a smart contract and publish it to the network for a fee. The smart contract can then be called by any user, again in exchange for a charge given to the network to run its code. Developers can therefore create and implement any levels of complexity in user-facing apps and services, such as marketplaces, financial instruments, games, etc., using smart contracts. # What are Dapps? A frontend user interface and a smart contract are both components of a decentralised application (dapp), which is a programme created on a decentralised network. Your dapp can even incorporate a smart contract that someone else has created because smart contracts on the Fieres Blockchain are transparent and accessible, much like open APIs. **PREREQUISITES** Learn about the fundamentals of blockchain technology and the decentralized nature of the Fieres Blockchain network before diving into the world of dapps.
**DEFINITION OF A DAPP** A dApp is a decentralized application that runs on a distributed ledger, such as a blockchain. Unlike traditional apps, which rely on a central server, dApps are powered by a peer-to-peer network. This decentralized structure offers several advantages, including improved security and transparency. * **Decentralised** - dApps run on Fieres Blockchain, an open, public, decentralized platform that is not controlled by any one entity or group. * **Deterministic** - dApps serve the same purpose no matter what environment they are executed in. * **Turing complete** - dApps can carry out any activity if they have the necessary resources. * **Isolated** - dApps are run in a virtual environment called the Ethereum Virtual Machine so that if a smart contract has a problem, it won't interfere with the blockchain network's regular operation. **On smart contracts** In order to introduce dapps, smart contracts—the backend of a dapp, for lack of a better term—must be introduced. Visit our section on smart contracts for a thorough description. A smart contract is a piece of code that operates exactly as intended and is stored on the Fieres Blockchain. Once implemented on the network, smart contracts cannot be changed. Dapps can be decentralised because the logic spelt forth in the contract, not a person or organisation, governs them. This also implies you need to draft your contracts very carefully and test them thoroughly. **BENEFITS OF DAPP DEVELOPMENT** **Zero downtime –** The network as a whole will always be able to serve users trying to engage with the smart contract once it has been placed on the blockchain. Therefore, malicious actors are unable to conduct denial-of-service attacks against individual dapps. **Privacy –** A real-world identity is not required in order to use or deploy a dapp. **Resistance to censorship –** Users cannot be prevented from submitting transactions, establishing dapps, or reading data from the blockchain by a single entity on the network. **Complete data integrity –** Cryptographic primitives provide for the immutability and irrefutability of data recorded on the blockchain. Malicious actors are unable to alter transactions or other data that has already been made available to the public. **Trustless computation/verifiable behavior –** Without the need to rely on a centralized authority, smart contracts can be analyzed and are guaranteed to execute in predictable ways. This is not the case with traditional models; for instance, while using online banking services, we must have faith that financial companies won't mishandle our personal information, falsify records, or experience a hack. #### DRAWBACKS OF DAPP DEVELOPMENT **Maintenance –** dApps can be more difficult to maintain since it is more difficult to change the code and data that is published on the blockchain. Once a dapp (or the underlying data stored by a dapp) is launched, it might be challenging for developers to update it, even if defects or security threats are found in an older version. **Performance overhead –** Scaling is quite challenging, and there is a significant performance overhead. Every node processes and saves every transaction in order to reach the degree of security, integrity, transparency, and dependability that Fieres Blockchain strives for. Additionally, the proof-of-work process takes time. Back of the envelope math estimates the overhead at approximately 1,000,000x that of the current standard compute. **Network congestion –** The entire network experiences a lag when one dapp consumes excessive amounts of processing resources. If transactions are put in quicker than the network can currently handle (15–20 transactions per second), the number of unconfirmed transactions will quickly increase. **User experience –** Because the typical end user might find it too challenging to set up the tool stack required to connect with the blockchain in a properly safe manner, it might be more difficult to design user-friendly experiences. **Centralisation –** On top of the Fieres Blockchain's basic layer, user- and developer-friendly solutions may ultimately resemble centralized systems. Such services might, for instance, conduct critical business logic on a centralized server before writing to the blockchain, offer a frontend using a centralized server, or store keys or other sensitive information there. Many, if not all, of blockchain's advantages over the conventional approach, are eliminated by centralized control. # Consensus Consensus is the process of getting a bunch of computers to reach a consensus. By following a series of instructions known as a consensus protocol, computers can come to a consensus. POA, a trustworthy consensus process that is scalable, reliable, and decentralized, is used by Fieres. It offers a quick throughput and minimal latency. It uses little energy and doesn't need specialized computer hardware. It functions effectively in difficult conditions and is resistant to "51% attacks." Consensus systems (networks of computers) can cooperate and maintain security thanks to consensus methods, often known as consensus protocols or consensus algorithms. Consensus algorithms and protocols are frequently used interchangeably. Algorithms and protocols, however, differ from one another. A protocol is a set of guidelines outlined in a standard that controls how a system and all of its component elements work in unity. Algorithms are like detailed instructions on how to perform calculations or solve problems. The establishment of consensus among database nodes, application servers, and other enterprise infrastructure has been accomplished for many years using these approaches. New consensus techniques have been developed in past years to enable crypto-economic systems, such Fieres Blockchain, to concur on the network's state. # Proof Of Authority In blockchain platforms, consensus mechanisms can be divided into permissionless (Bitcoin, Etherium) and permissioned (Apla, Ethereum Private). In a permissioned blockchain, all nodes are pre-authenticated. This advantage allows the use of consensus types that provide high transaction rate in addition to other benefits. One of these consensus types is Proof-of-Authority (PoA) consensus. Proof-of-Authority (POA) is a new consensus algorithms family that provides high performance and fault tolerance. In PoA, rights to generate new blocks are awarded to nodes that have proven their authority to do so. To gain this authority and a right to generate new blocks, a node must pass a preliminary authentication. # Fieres Blockchain CLI Parameters This reference describes the syntax of the QI Blockchain Command Line Interface (CLI) options. ### Specifying options You can specify QI options: * On the command line. ``` besu [OPTIONS] [SUBCOMMAND] ``` * As an environment variable. For each command line option, the equivalent environment variable is: * Uppercase. * `_` replaces `-`. * Has a `BESU_` prefix. For example, set `--miner-coinbase` using the `BESU_MINER_COINBASE` environment variable. If you specify an option in more than one place, the order of priority is command line, environment variable, configuration file. If using Bash or Z shell, you can view option suggestions by entering `--` and pressing the Tab key twice. ``` besu --Tab+Tab ``` ### Options #### `api-gas-price-blocks` Syntax ``` --api-gas-price-blocks= ``` Number of blocks back from the head block to examine for `eth_gasPrice`. The default is `100`. #### `api-gas-price-max` Syntax ``` --api-gas-price-max= ``` Maximum gas price to return for `eth_gasPrice`, regardless of the percentile value measured. The default is `500000000000` (500 GWei). #### `api-gas-price-percentile` Syntax ``` --api-gas-price-percentile= ``` Percentile value to measure for `eth_gasPrice`. The default is `50.0`. For `eth_gasPrice`, to return the: * Highest gas price in `--api-gas-price-blocks`, set to `100`. * Lowest gas price in `--api-gas-price-blocks`, set to `0`. #### `bootnodes` Syntax ``` --bootnodes[=[,...]...] ``` A list of comma-separated enode URLs for P2P discovery bootstrap. When connecting to Mainnet or public testnets, the default is a predefined list of enode URLs. In private networks defined using `--genesis-file` or when using `--network=dev`, the default is an empty list of bootnodes. #### `color-enabled` Syntax ``` --color-enabled[=] ``` ExampleEnvironment variableExample configuration file Enables or disables color output to console. The default is `true`. #### `config-file` Syntax ``` --config-file= ``` The path to the TOML configuration file. The default is `none`. #### `data-path` Syntax ``` --data-path= ``` The path to the Besu data directory. The default is the directory you installed Besu in. #### `discovery-dns-url` Syntax ``` --discovery-dns-url= ``` The `enrtree` URL of the DNS node list for node discovery via DNS. The default is `null`. #### `discovery-enabled` Syntax ``` --discovery-enabled[=] ``` Enables or disables P2P discovery. The default is `true`. Note You can override the default DNS server if it’s unreliable or doesn’t serve TCP DNS requests, using the experimental option `--Xp2p-dns-discovery-server=`. #### `engine-host-allowlist` Syntax ``` --engine-host-allowlist=[,...]... or "*" ``` A comma-separated list of hostnames to allow for Engine API access (applies to both HTTP and WebSocket). Tip To allow all hostnames, use `"*"`. We don’t recommend allowing all hostnames in production environments. #### `engine-rpc-port` Syntax ``` --engine-rpc-port= ``` The listening port for the Engine API calls (`ENGINE`, `ETH`) for JSON-RPC over HTTP and WebSocket. The default is `8551`. #### `ethstats` Syntax ``` --ethstats= ``` Reporting URL of an Ethstats server. #### `ethstats-contact` Syntax ``` --ethstats-contact= ``` Contact email address to send to the Ethstats server specified by `--ethstats`. Note A server must be specified by `--ethstats` in order to use this option. #### `fast-sync-min-peers` Syntax ``` --fast-sync-min-peers= ``` The minimum number of peers required before starting fast synchronization. The default is 5. Note If synchronizing in `FAST` mode, most historical world state data is unavailable. Any methods attempting to access unavailable world state data return `null`. #### `genesis-file` Use the genesis file to create a custom network. Tip To use a public Ethereum network such as Rinkeby, use the `--network` option. The network option defines the genesis file for public networks. Syntax ``` --genesis-file= ``` The path to the genesis file. Important You cannot use the `--genesis-file` and `--network` options at the same time. #### `graphql-http-cors-origins` Syntax ``` --graphql-http-cors-origins= ``` A list of comma-separated origin domain URLs for CORS validation. The default is none. #### `graphql-http-enabled` Syntax ``` ---graphql-http-enabled[=] ``` Enables or disables the GraphQL HTTP service. The default is `false`. The default GraphQL HTTP service endpoint is `http://127.0.0.1:8547/graphql` if set to `true`. #### `graphql-http-host` Syntax ``` --graphql-http-host= ``` The host on which GraphQL HTTP listens. The default is `127.0.0.1`. To allow remote connections, set to `0.0.0.0`. #### `graphql-http-port` Syntax ``` --graphql-http-port= ``` The port (TCP) on which GraphQL HTTP listens. The default is `8547`. Ports must be exposed appropriately. #### `help` Syntax ``` -h, --help ``` Show the help message and exit. #### `host-allowlist` Syntax ``` --host-allowlist=[,...]... or "*" ``` A comma-separated list of hostnames to access the JSON-RPC API and pull Besu metrics. By default, Besu accepts requests from `localhost` and `127.0.0.1`. Note If using [Prometheus](https://prometheus.io/) to pull metrics from a node, you must specify all the other nodes you want to pull metrics from in the list of allowed hostnames. #### `logging` Syntax ``` -l, --logging= ``` Sets logging verbosity. Log levels are `OFF`, `FATAL`, `ERROR`, `WARN`, `INFO`, `DEBUG`, `TRACE`, `ALL`. The default is `INFO`. #### `max-peers` Syntax ``` --max-peers= ``` The maximum number of P2P connections you can establish. The default is 25. #### `metrics-category` Syntax ``` --metrics-category=[,metrics-category...]... ``` A comma-separated list of categories for which to track metrics. The defaults are `BLOCKCHAIN`, `ETHEREUM`, `EXECUTORS`, `JVM`, `NETWORK`, `PEERS`, `PERMISSIONING`, `PROCESS`, `PRUNER`, `RPC`, `STRATUM`, `SYNCHRONIZER`, and `TRANSACTION_POOL`. Other categories are `KVSTORE_ROCKSDB`, `KVSTORE_PRIVATE_ROCKSDB`, `KVSTORE_ROCKSDB_STATS`, and `KVSTORE_PRIVATE_ROCKSDB_STATS`. Categories containing `PRIVATE` track metrics when you enable private transactions. #### `metrics-enabled` Syntax ``` ---metrics-enabled[=] ``` Enables or disables the metrics exporter. The default is `false`. You can’t specify `--metrics-enabled` with `--metrics-push-enabled`. That is, you can enable either Prometheus polling or Prometheus push gateway support, but not both at once. #### `metrics-host` Syntax ``` --metrics-host= ``` The host on which [Prometheus](https://prometheus.io/) accesses Besu metrics. The metrics server respects the `--host-allowlist` option. The default is `127.0.0.1`. #### `metrics-port` Syntax ``` --metrics-port= ``` The port (TCP) on which [Prometheus](https://prometheus.io/) accesses Besu metrics. The default is `9545`. Ports must be exposed appropriately. #### `metrics-protocol` Syntax ``` --metrics-protocol= ``` Metrics protocol to use: `PROMETHEUS`, `OPENTELEMETRY`, or `NONE`. The default is `PROMETHEUS`. #### `metrics-push-enabled` Syntax ``` --metrics-push-enabled[=] ``` Enables or disables push gateway integration. You can’t specify `--metrics-push-enabled` with `--metrics-enabled`. That is, you can enable either Prometheus polling or Prometheus push gateway support, but not both at once. #### `metrics-push-host` Syntax ``` --metrics-push-host= ``` The host of the Prometheus Push Gateway. The default is `127.0.0.1`. The metrics server respects the `--host-allowlist` option. Note When pushing metrics, ensure you set `--metrics-push-host` to the machine on which the push gateway is. Generally, this is a different machine to the machine on which Besu is running. #### `metrics-push-interval` Syntax ``` --metrics-push-interval= ``` The interval, in seconds, to push metrics when in `push` mode. The default is 15. #### `metrics-push-port` Syntax ``` --metrics-push-port= ``` The port (TCP) of the [Prometheus Push Gateway](https://github.com/prometheus/pushgateway). The default is `9001`. Ports must be exposed appropriately. #### `miner-coinbase` Syntax ``` --miner-coinbase= ``` The account you pay mining rewards to. You must specify a valid coinbase when you enable mining using the `--miner-enabled` option or the `miner_start` JSON-RPC API method. #### `miner-enabled` Syntax ``` --miner-enabled[=] ``` Enables or disables mining when you start the node. The default is `false`. #### `miner-extra-data` Syntax ``` --miner-extra-data= ``` A hex string representing the 32 bytes included in the extra data field of a mined block. The default is 0x. #### `miner-stratum-enabled` Syntax ``` --miner-stratum-enabled ``` Enables a node to perform stratum mining. The default is `false`. #### `miner-stratum-host` Syntax ``` --miner-stratum-host= ``` The host of the stratum mining service. The default is `0.0.0.0`. #### `miner-stratum-port` Syntax ``` --miner-stratum-port= ``` The port of the stratum mining service. The default is `8008`. You must expose ports appropriately. #### `min-gas-price` Syntax ``` --min-gas-price= ``` The minimum price a transaction offers to include it in a mined block. The minimum gas price is the lowest value `eth_gasPrice` can return. The default is 1000 Wei. Important In a free gas network, ensure the minimum gas price is set to zero for every node. Any node with a minimum gas price set higher than zero will silently drop transactions with a zero gas price. You can query a node’s gas configuration using `eth_gasPrice`. #### `nat-method` Syntax ``` --nat-method=UPNP ``` Specify the method for handling NAT environments. The options are: * `UPNP` * `UPNPP2PONLY` * `KUBERNETES` * `DOCKER` * `AUTO` * `NONE`. The default is `AUTO`. `NONE` disables NAT functionality. Tip UPnP support is often disabled by default in networking firmware. If disabled by default, explicitly enable UPnP support. You must specify `DOCKER` when using the Besu Docker image. #### `network-id` Syntax ``` --network-id= ``` The P2P network identifier. Use this option to override the default network ID. The default value is the same as the chain ID defined in the genesis file. #### `node-private-key-file` Syntax ``` --node-private-key-file= ``` The private key file for the node. The default is the key file in the data directory. If no key file exists, Besu creates a key file containing the generated private key, otherwise, the existing key file specifies the node private key. Attention The private key is not encrypted. This option is ignored if `--security-module` is set to a non-default value. #### `p2p-enabled` Syntax ``` --p2p-enabled[=] ``` Enables or disables all P2P communication. The default is `true`. #### `p2p-host` Syntax ``` --p2p-host= ``` The advertised host that can be used to access the node from outside the network in P2P communication. The default is `127.0.0.1`. Info If `--nat-method` is set to `NONE`, `--p2p-host` is not overridden and must be specified for the node to be accessed from outside the network. #### `p2p-interface` Syntax ``` --p2p-interface= ``` The network interface on which the node listens for P2P communication. Use the option to specify the required network interface when the device that Besu is running on has multiple network interfaces. The default is 0.0.0.0 (all interfaces). #### `p2p-port` Syntax ``` --p2p-port= ``` The P2P listening ports (UDP and TCP). The default is `30303`. You must expose ports appropriately. #### `pruning-block-confirmations` Syntax ``` --pruning-block-confirmations= ``` The minimum number of confirmations on a block before marking of newly-stored or in-use state trie nodes that cannot be pruned. The default is 10. Important Using pruning with private transactions is not supported. #### `pruning-blocks-retained` Syntax ``` --pruning-blocks-retained= ``` The minimum number of recent blocks to keep the entire world state for. The default is 1024. #### `pruning-enabled` Syntax ``` --pruning-enabled ``` Enables pruning to reduce storage required for the world state. The default is `false`. #### `random-peer-priority-enabled` Syntax ``` --random-peer-priority-enabled[=] ``` Enables or disables random prioritisation of incoming connections. Enable in small, stable networks to prevent closed groups of peers forming. The default is `false`. #### `remote-connections-limit-enabled` Syntax ``` --remote-connections-limit-enabled[=] ``` Enables or disables using the `--remote-connections-max-percentage` option to limit the percentage of remote P2P connections initiated by peers. The default is `true`. Important To prevent eclipse attacks, ensure you enable the remote connections limit when connecting to any public network, and especially when using `--sync-mode` and `--fast-sync-min-peers`. #### `remote-connections-max-percentage` Syntax ``` --remote-connections-max-percentage= ``` The percentage of remote P2P connections you can establish with the node. Must be between 0 and 100, inclusive. The default is 60. #### `required-block` Syntax ``` --required-block, --required-blocks[=BLOCK=HASH[,BLOCK=HASH...]...] ``` Requires a peer with the specified block number to have the specified hash when connecting, or Besu rejects that peer. #### `revert-reason-enabled` Syntax ``` --revert-reason-enabled[=] ``` Enables or disables including the revert reason in the transaction receipt, `eth_estimateGas` error response, `eth_call` error response, and `trace` response. The default is `false`. Caution Enabling revert reason may use a significant amount of memory. #### `rpc-http-api` Syntax ``` --rpc-http-api=[,...]... ``` A comma-separated list of APIs to enable on the HTTP JSON-RPC channel. When you use this option you must also specify the `--rpc-http-enabled` option. The available API options are: `ADMIN`, `CLIQUE`, `DEBUG`, `EEA`, `ETH`, `IBFT`, `MINER`, `NET`, `PERM`, `PLUGINS`, `PRIV`, `QBFT`, `TRACE`, `TXPOOL`, and `WEB3`. The default is: `ETH`, `NET`, `WEB3`. Tip The singular `--rpc-http-api` and plural `--rpc-http-apis` are available and are two names for the same option. #### `rpc-http-authentication-credentials-file` Syntax ``` --rpc-http-authentication-credentials-file= ``` The credentials file for JSON-RPC API authentication. #### `rpc-http-authentication-enabled` Syntax ``` --rpc-http-authentication-enabled[=] ``` Enables or disables authentication for the HTTP JSON-RPC service. #### `rpc-http-cors-origins` Syntax ``` --rpc-http-cors-origins=[,...]... or all or "*" ``` A list of domain URLs for CORS validation. Listed domains can access the node using JSON-RPC. If your client interacts with Besu using a browser app (such as Remix or a block explorer), add the client domain to the list. The default value is `"none"`. If you do not list any domains, browser apps cannot interact with your QI node. #### `rpc-http-enabled` Syntax ``` --rpc-http-enabled[=] ``` Enables or disables the HTTP JSON-RPC service. The default is `false`. #### `rpc-http-host` Syntax ``` --rpc-http-host= ``` The host on which HTTP JSON-RPC listens. The default is `127.0.0.1`. To allow remote connections, set to `0.0.0.0`. Caution Setting the host to `0.0.0.0` exposes the RPC connection on your node to any remote connection. In a production environment, ensure you are using a firewall to avoid exposing your node to the internet. #### `rpc-http-max-active-connections` Syntax ``` --rpc-http-max-active-connections= ``` The maximum number of allowed HTTP JSON-RPC connections. Once this limit is reached, incoming connections are rejected. The default is 80. #### `rpc-http-port` Syntax ``` --rpc-http-port= ``` The port (TCP) on which HTTP JSON-RPC listens. The default is `8545`. You must expose ports appropriately. #### `rpc-http-tls-ca-clients-enabled` Syntax ``` --rpc-http-tls-ca-clients-enabled[=] ``` Enables or disables clients with trusted CA certificates to connect. The default is `false`. Note You must enable client authentication using the `---rpc-http-tls-client-auth-enabled` option. #### `rpc-http-tls-enabled` Syntax ``` --rpc-http-tls-enabled[=] ``` Enables or disables TLS for the JSON-RPC HTTP service. The default is `false`. Note `--rpc-http-enabled` must be enabled. #### `rpc-http-tls-keystore-file` Syntax ``` --rpc-http-tls-keystore-file= ``` The Keystore file (in PKCS #12 format) that contains private key and the certificate presented to the client during authentication. #### `rpc-http-tls-keystore-password-file` Syntax ``` --rpc-http-tls-keystore-password-file= ``` The path to the file containing the password to decrypt the keystore. #### `rpc-http-tls-protocol` Syntax ``` --rpc-http-tls-protocol=[, ...] ``` A list of comma-separated TLS protocols to support. The default is `DEFAULT_TLS_PROTOCOLS`, a list which includes `TLSv1.3` and `TLSv1.2`. Tip The singular `--rpc-http-tls-protocol` and plural `--rpc-http-tls-protocols` are available and are two names for the same option. #### `rpc-tx-feecap` Syntax ``` --rpc-tx-feecap= ``` The maximum transaction fee (in Wei) accepted for transactions submitted through the `eth_sendRawTransaction` RPC. The default is 1000000000000000000 (1 ether). If set to 0, then this option is ignored and no cap is applied. #### `rpc-ws-api` Syntax ``` --rpc-ws-api=[,...]... ``` A comma-separated list of APIs to enable on the WebSockets channel. When you use this option you must also specify the `--rpc-ws-enabled` option. The available API options are: `ADMIN`, `CLIQUE`, `DEBUG`, `EEA`, `ETH`, `IBFT`, `MINER`, `NET`, `PERM`, `PLUGINS`, `PRIV`, `QBFT`, `TRACE`, `TXPOOL`, and `WEB3`. The default is: `ETH`, `NET`, `WEB3`. Tip The singular `--rpc-ws-api` and plural `--rpc-ws-apis` options are available and are two names for the same option. #### `rpc-ws-enabled` Syntax ``` --rpc-ws-enabled[=] ``` Enables or disables the WebSocket JSON-RPC service. The default is `false`. #### `rpc-ws-host` Syntax ``` --rpc-ws-host= ``` The host on which WebSocket JSON-RPC listens. The default is `127.0.0.1`. To allow remote connections, set to `0.0.0.0` #### `rpc-ws-max-active-connections` Syntax ``` --rpc-ws-max-active-connections= ``` The maximum number of WebSocket connections allowed for JSON-RPC. Once this limit is reached, incoming connections are rejected. The default is 80. #### `rpc-ws-max-frame-size` Syntax ``` --rpc-ws-max-frame-size= ``` The maximum size in bytes for JSON-RPC WebSocket frames. If this limit is exceeded, the WebSocket disconnects. The default is 1048576 (or 1 MB). #### `rpc-ws-port` Syntax ``` --rpc-ws-port= ``` The port (TCP) on which WebSocket JSON-RPC listens. The default is `8546`. You must expose ports appropriately. #### `strict-tx-replay-protection-enabled` Syntax ``` --strict-tx-replay-protection-enabled[=] ``` Enables or disables replay protection, in accordance with EIP-155, on transactions submitted using JSON-RPC. The default is `false`. #### `sync-mode` Syntax ``` --sync-mode=X_SNAP ``` The synchronization mode. Use `FAST` for fast sync, `FULL` for full sync, `X_SNAP` for snap sync, and `X_CHECKPOINT` for checkpoint sync. * The default is `FULL` when connecting to a private network by not using the `--network` option and specifying the `--genesis-file` option. * The default is `FAST` when using the `--network` option with named networks. #### `version` Syntax ``` -V, --version ``` Prints version information and exit. # RPC API # ADMIN methods * `version` - P2P protocol version. * `name` - Client name. * `caps` - List of Ethereum sub-protocol capabilities. * `network` - Local and remote addresses established at time of bonding with the peer. The remote address might not match the hex value for `port`. The remote address depends on which node initiated the connection. * `port` - Port on the remote node on which P2P discovery is listening. * `id` - Node public key. Excluding the `0x` prefix, the node public key is the ID in the enode URL `enode://@:`. * `protocols` - Current state of peer including `difficulty` and `head`. `head` is the hash of the highest known block for the peer. BODY ```json { "jsonrpc": "2.0", "method": "admin_peers", "params": [], "id": 1 } ``` \ \ Example Request ```json POST / HTTP/1.1 Host: localhost:8545 Content-Length: 84 { "jsonrpc": "2.0", "method": "admin_peers", "params": [], "id": 1 } ``` Example Response ```json { "jsonrpc": "2.0", "id": 1, "result": [ { "version": "0x5", "name": "besu/v20.10.4-dev-0905d1b2/osx-x86_64/adoptopenjdk-java-11", "caps": [ "eth/62", "eth/63", "eth/64", ``` POST : admin\_removePeer Removes a static node. **Parameters** `string` : Enode URL of peer to remove. **Returns** `result` : `boolean` - `true` if peer removed or `false` if peer not a static node). BODY ```json { "jsonrpc": "2.0", "method": "admin_removePeer", "params": [ "enode://f59c0ab603377b6ec88b89d5bb41b98fc385030ab1e4b03752db6f7dab364559d92c757c13116ae6408d2d33f0138e7812eb8b696b2a22fe3332c4b5127b22a3@127.0.0.1:30304" ], "id": 1 ```
# QBFT Methods The `QBFT` API methods provide access to the QBFT consensus engine. Note The `QBFT` API methods are not enabled by default for JSON-RPC. To enable the `QBFT` API methods, use the `--rpc-http-api` or `--rpc-ws-api` options. #### `qbft_discardValidatorVote` Discards a proposal to add or remove a validator with the specified address. **Parameters** `address`: *string* - 20-byte address of proposed validator **Returns** `result`: *boolean* - indicates if the proposal is discarded ``` curl -X POST --data '{"jsonrpc":"2.0","method":"qbft_discardValidatorVote","params":["0xef1bfb6a12794615c9b0b5a21e6741f01e570185"], "id":1}' http://127.0.0.1:8545 ``` #### `qbft_getPendingVotes` Returns votes cast in the current epoch. **Parameters** None **Returns** `result`: *map* of *strings* to *booleans* - map of account addresses to corresponding boolean values indicating the vote for each account; if `true`, the vote is to add a validator. If `false`, the proposal is to remove a validator. ``` curl -X POST --data '{"jsonrpc":"2.0","method":"qbft_getPendingVotes","params":[], "id":1}' http://127.0.0.1:8545 ``` #### `qbft_getSignerMetrics` Provides the following validator metrics for the specified range: * Number of blocks from each validator * Block number of the last block proposed by each validator (if any proposed in the specified range) * All validators present in the last block of the range **Parameters** * `fromBlockNumber`: *string* - integer representing a block number or the string tag `earliest` as described in Block Parameter * `toBlockNumber`: *string* - integer representing a block number or one of the string tags `latest` or `pending`, as described in Block Parameter If you specify: * No parameters, the call provides metrics for the last 100 blocks, or all blocks if there are less than 100 blocks. * Only the first parameter, the call provides metrics for all blocks from the block specified to the latest block. **Returns** `result`: *array* of *objects* - list of validator objects Note The proposer of the genesis block has address `0x0000000000000000000000000000000000000000`. ``` curl -X POST --data '{"jsonrpc":"2.0","method":"qbft_getSignerMetrics","params":["1", "100"], "id":1}' http://127.0.0.1:8545 ``` #### `qbft_getValidatorsByBlockHash` Lists the validators defined in the specified block. **Parameters** `block`: *string* - 32-byte block hash **Returns** `result`: *array* of *strings* - list of validator addresses ``` curl -X POST --data '{"jsonrpc":"2.0","method":"qbft_getValidatorsByBlockHash","params":["0xbae7d3feafd743343b9a4c578cab5e5d65eb735f6855fb845c00cab356331256"], "id":1}' http://127.0.0.1:8545 ``` #### `qbft_getValidatorsByBlockNumber` Lists the validators defined in the specified block. **Parameters** * `blockNumber`: *string* - integer representing a block number or one of the string tags `latest`, `earliest`, or `pending`, as described in Block Parameter **Returns** `result`: *array* of *strings* - list of validator addresses ``` curl -X POST --data '{"jsonrpc":"2.0","method":"qbft_getValidatorsByBlockNumber","params":["latest"], "id":1}' http://127.0.0.1:8545 ``` #### `qbft_proposeValidatorVote` Proposes to add or remove a validator with the specified address. **Parameters** * `address`: *string* - account address * `proposal`: *boolean* - `true` to propose adding validator or `false` to propose removing validator **Returns** ``` curl -X POST --data '{"jsonrpc":"2.0","method":"qbft_proposeValidatorVote","params":["42d4287eac8078828cf5f3486cfe601a275a49a5",true], "id":1}' http://127.0.0.1:8545 ```
# Run a Fieres Blockchain full node This section provides documents on how to build and maintain a Fieres blockchain full node and then validate the Fieres network using a Fieres node. The quickest way to learn about Fieres is to run a node and interact with the network. In this tutorial, we will: * Install and run an Fieres node * Connect to Fieres **Requirements**[**​**](https://docs.avax.network/nodes/build/run-avalanche-node-manually#requirements) **Computer Hardware and OS** Nodes can operate on common hardware because Fieres is such a lightweight protocol. Keep in mind that hardware requirements may alter as network demand grows. * CPU: Equivalent of 6 AWS vCPU * RAM: 8 GB * Storage: 250 GB **Networking**[**​**](https://docs.avax.network/nodes/build/run-avalanche-node-manually#networking) To run successfully, Fieres needs to accept connections from the Internet on the network port 1337 for mainnet. You must decide the networking environment your node will operate in before you start the installation. **Running on a Cloud Provider**[​](https://docs.avax.network/nodes/build/run-avalanche-node-manually#running-on-a-cloud-provider) Your node will have a static IP if it is operating on a cloud provider's computer instance. Find out what that static IP is, or if you haven't already, configure it. **Running on a Home Connection**[​](https://docs.avax.network/nodes/build/run-avalanche-node-manually#running-on-a-home-connection) You have a dynamic IP, which means that it will change from time to time if you are running a node on a computer connected to a residential internet connection. In order to access the computer, the node is installed on from the Internet, you must configure inbound port forwarding 1337 for the test net. # Starting a Full Node For running a full node of Fieres Blockchain, execute the following shell script with root privileges. It will install and run Besu Client on your linux instance. #### Testnet Shell Script \`\``` ` #!/bin/sh `` `sudo ufw allow 30303` `sudo apt-get update` `sudo apt install default-jdk` `java - version` `wget https://hyperledger.jfrog.io/artifactory/besu-binaries/besu/22.7.4/besu-22.7.4.zip` `sudo apt-get install unzip` `unzip besu-22.7.4.zip` `cd besu-22.7.4/bin` `export PATH=$PWD:$PATH` `cd` `mkdir EVMProtocol` `cd EVMProtocol` `echo "Copy the testnet genesis file details on nano text editor and Press control+x and then press y and hit the enter to save genesis data"` `nano genesis.json` `echo "Run below command in $HOME/EVMProtocol directory"` `besu --data-path=data --genesis-file=../genesis.json --bootnodes=` enode://a86b9e92c6e10e5d7d901688ca47c3db709b94575aebba18c173afe9be2c5c04297d23675069702a7f467fff09f6890a3ead9c5b37a542f84c11e93b84f868f3\@35.178.223.52:30303 `--p2p-port=30304 --rpc-http-enabled --rpc-http-api=ETH,NET,QBFT --host-allowlist="*" --rpc-http-cors-origins="all" --rpc-http-port=8545 --rpc-http-host=0.0.0.0` By default **RPC** port is **8545**. If the port is open, anyone can make RPC. # Add a validator **Step 1** - Create a folder in your machine . **Step 2** - copy and paste genesis content in genesis.json file. **Step 3** - Install besu in your machine. **Step 4** - run this command on that directory where your genesis file is saved - `besu --data-path=data --genesis-file=./genesis.json --bootnodes=` enode://a86b9e92c6e10e5d7d901688ca47c3db709b94575aebba18c173afe9be2c5c04297d23675069702a7f467fff09f6890a3ead9c5b37a542f84c11e93b84f868f3\@35.178.223.52:30303 `--p2p-port=30304 --rpc-http-enabled --rpc-http-api=ETH,NET,QBFT --host-allowlist="*" --rpc-http-cors-origins="all" --rpc-http-port=8545 --rpc-http-host=0.0.0.0`
**Step 5** - Wait for full synchronization. **Step 6** - Once your full node syncs successfully. Then you will notice the data directory created by besu in your running chain directory. Just go into the data folder and extract your signing private key from the key file.
**Step 7** - Extract your public address from private key via metamask.This public address will be used while proposing as a validator in chain. Then you would more than 51% of added validator to purpose/add your votes to a validator.If 51 % of existing validators accept your proposal you become a validator. Request to run this command by more than 51% of existing validators - `curl -X POST --data '{"jsonrpc":"2.0","method":"qbft_proposeValidatorVote","params":["",true], "id":1}'` [`http://127.0.0.1:8545`](http://127.0.0.1:8545) Once 51% existing added validators run this command on their machines. You will become a validator. \ **Step 8** - **Run this command to get the validator Metrice-** `curl -X POST --data '{"jsonrpc":"2.0","method":"qbft_getSignerMetrics","params":[], "id":1}' http://127.0.0.1:8545` If your address comes in Metrice with some no of proposal block and participate in block. That means you become a network validator. For cross verification you need to check your node’s logs.