-
Notifications
You must be signed in to change notification settings - Fork 52
Network Specifications
This document is a technical whitepaper. It will explain the differences between Nano and Banano and also provides some further guidance for node operators and developers but does not cover complete integration strategies.
Internally, the node uses 'RAW' as the smallest unit, which the node will use for input&output by default.
1 Banano is 10^29 RAW (100000000000000000000000000000). In other words, a Banano has up to 29 digits after the decimal separator.
1 Banoshi is 10^27 RAW (1000000000000000000000000000)
1 Banano is 100 Banoshi
For comparison, 1 nano/XNO is 10^30 RAW.
Blocks with 1 RAW transaction size will be completely valid and will be processed by all nodes, but by default, wallets will not process incoming transactions smaller than 1 Banano automatically, and some wallets are not intended to send small fractions of Banano. The many digits could be used for data encoding for example.
The maximum initial supply is 2^128 RAW (340282366920938463463374607431768211455 RAW = 3 402 823 669 Banano) of which some are being burnt. So far, more than 1.4 billion Banano were burnt. The burn account is ban_1burnbabyburndiscoinferno111111111111111111111111111aj49sw3w
Market cap tracking sites typically use the API to determine current supply: https://api.creeper.banano.cc/supply. On November 16th, 2021 it returned: {"circulating":1333964378.9289043,"uncirculating":585007255.1363083,"burned":1483852035.1347873,"total":1918971634.0652125}
Node-to-node communication: 7071 (TCP and UDP)
RPC: 7072 (TCP. Disabled by default)
IPC: 7073 (Disabled by default)
Websocket: 7074 (Introduced in V20. Disabled by default)
Default NANO ports for comparison: peering 7075, RPC 7076, IPC 7077, WS 7078
SSD storage is highly recommended. 1GB of RAM will work, but 2GB or more, plus a swapfile are recommended. 2 or more cpu cores are recommended - when it comes to generating proof of work for send blocks, a GPU works best, or you can use an external work provider or client side work generation. Currently, the nodes will download the whole ledger history, which consumes roughly 10GB of disk space. For upgrades, you need double that. If you run a representative node, more resources will help with stability in turbulent times.
Banano addresses start with either ban_1 or ban_3, and they are 64 characters long. The last 8 characters are a checksum. So it's virtually impossible to send Banano to nonexistent addresses unvoluntarily.
Banano addresses are all-lowercase, and the Base32 table does not contain the characters 0,2,L,V
You do not necessarily need a node to generate addresses, if you have a cryptographic library in your desired language. There also is a client-side paperwallet generator and a vanity generator.
Regex for checking the characters of an address: /^ban_[13][13456789abcdefghijkmnopqrstuwxyz]{59}$/ (does not check the checksum)
The genesis account is ban_1bananobh5rat99qfgt1ptpieie5swmoth87thi74qgbfrij7dcgjiij94xr - from there on, the distribution funds were equipped with banano.
A seed is used to generate multiple private keys without having to write them all down separately. The regular hexadecimal seeds and private keys are 64 characters long, consisting of characters from A-F and 0-9. Regex for checking a valid seed or private key: /^[A-F0-9]{64}$/
Sometimes there also are optional mnemonic seeds (word seeds) added for convenience, which are not consistenly used among all Banano apps. The BIP44/SLIP44 coin type index is "198" (Only the Ledger Nano S uses this key derivation scheme at the moment). Wallets like Kalium and Nanovault directly translate the Hex seed to a mnemonic seed, using the standard word list.
BANANO does not offer master public keys at the moment. You need to either keep the seed available, or generate a lot of addresses in advance. There also is technique called "camo banano", which is a case study at the moment, that allows the sender to generate covert child keys on behalf of the recipient.
N of M multisig sending restrictions are not prossible at the moment. N of N multisig is possible, but not implemented in most wallets.
By default, a node will download the complete block lettuce, so you can query the node for other peoples' accounts. To see the current local block count, use curl -g -d '{ "action": "block_count" }' '[::1]:7072' which will output e.g.
{ "count": "29965818", "unchecked": "73", "cemented": "29965818" }. A complete synchronisation might take a couple of days until all blocks are cemented. If you're in a hurry, you can download prebuilt rocksdb database.
Block generation, hashing and signing works the same as NANO. The purpose of a block (send/receive/...) is mainly determined by the difference of the balance when compared to its predecessor. For a detailed graphic guide on how a block is built, go to the Nanoo.tools website
Keep in mind that blocks do not contain timestamp consensus. As of node V18 however, the node will internally record the block discovery timestamp.
In order to communicate with the node, you can use CURL with json-strings on the RPC port, or you can use a custom IPC wrapper, or CLI parameters for a small set of operations. The capabilities do not completely overlap. For a list of all important RPC commands, go to the NANO RPC guide. Commands involving NANO units will not work on the Banano network however.
A public node endpoint for testing purposes is available. It is descibed on https://nanoo.tools/bananode-api and also has extended capabilities.
If your app requires a simple real-time notification on new blocks, you can use plain old HTTP callback. That means, the node will send a stateless HTTP POST call to your webserver every time there's a new confirmed block. It contains not only the bare block but also some metadata. Note: HTTPS is not available natively, you can however use a middleware to further process HTTP callback before it reaches your app. As of V20, you can also use websockets which are a bit more complex to set up but more efficient and allow for more granular subscriptions to specific accounts' actions. For more information on websockets, read https://docs.nano.org/integration-guides/advanced/#websocket-support
For each transaction, you will need to calculate a nonce that exceeds the target threshold of after concatenating it with the previous block's hash (or the account's public key if it's the first block) and hashing it afterwards. The minimum threshold for Banano currently is ff ff fe 00 00 00 00 00 for all block types (Nano initially had ff ff ff c0 00 00 00 00 which is 8 times more work on average, the nano number got increased in 2020 to: send or change 0xfffffff800000000, Receive 0xfffffe0000000000). You can outsource work generation to a cluster of servers or the users if you want. For standard applications with low block volume, outsourcing is not necessary at the moment. Future versions of banano will use these values: send or change 0xfffffff000000000, receive 0x0000000000000000. Node are prepared for that as of v23.
The Bananode node unix binary is called ./bananode
As of V.18, the default directory for node configuration, logs, blockchain and wallet data is ~/BananoData . You can override this with a special parameter nohup ./bananode --daemon --data_path /root/mybananodatadir &. This is also helpful when you mount an external disk for an upgrade procedure that requires more resources.
banano's data directory mainly contains
- log folder (logging detail can be adjusted in config.json)
- backup folder (contains a copy of the private keys, auto-refreshed every 5 minutes, can be disabled completely. It's unencrypted if you didn't set a wallet password)
- data.ldb (contains all the block data, about 8GB after full sync)
- wallet.ldb (contains your private keys. It's unencrypted if you didn't set a wallet password) It may also include: config.json wallets.ldb-lock data.ldb-lock snapshot.ldb config_rpc.toml config-nano-pow-server.toml config-qtwallet.toml /rocksdb
Starting with V20, you can delete the json config files which will make the node use default values. To override default values, you can then create these files and add the parts you want to override:
- config_node.toml
- config_rpc.toml
The V20 node can create sample files with all possible config options for you:
./bananode --generate_config node > /root/BananoData/config_node.toml
./bananode --generate_config rpc > /root/BananoData/config_rpc.toml
You can then uncomment and edit the parts you need. For further information about configuration, read the documentation by the Nano foundation: https://docs.nano.org/running-a-node/configuration/
If you want to run a representative node (nodes that are actively negotiating on forks), you have to manually enable this in the config. By default, your node will only be processing the voting results.
To avoid clashing with NANO nodes, the network sets a Banano header for each network communication packet. Banano uses BX for the mainnet (NANO: RC). Betanet currently is not in use (Nano: NB). For private testnet, the magic packet is BZ (NANO: RA).
For debugging with gdb:
cmake -DBOOST_ROOT=/usr/local/boost/ -DCMAKE_BUILD_TYPE=Debug -G "Unix Makefiles"
apt install gdb
gdb
(gdb) file ./bananode
(gdb) run --daemon
(gdb) bt
for debuggung with libbacktrace:
cmake -DBOOST_ROOT=/usr/local/boost/ -DCMAKE_BUILD_TYPE=Debug -DNANO_STACKTRACE_BACKTRACE=ON -G "Unix Makefiles"
To get the bananode_backtrace.dump file, run ./bananode --debug_output_last_backtrace_dump
NANO/Banano currently does not support the issuing of custom tokens ("colored coins"). There's no standard for storing text on the blockchain, however there are some workarounds for this by encoding information into fields that normally serve a different purpose.