Nano: Enhancements in the Upcoming Boulton Release

With the upcoming Boulton release right around the corner, let’s take a detailed look at each of the enhancements being introduced. As this is one of the largest releases to ever hit the Nano network, there is plenty to go through, including improvements to the node software, RPC, developer wallet and testing environment. These enhancements are subject to change before the official release and any changes will be noted upon release.Node EnhancementsEnable Lazy bootstrapping #1332When bootstrapping, enables nodes to monitor the real-time network for blocks being confirmed. Because each account-chain is a blockchain, when a block is confirmed, all of the previous blocks on its account-chain are also accepted by the network. For more information on this enhancement, please refer to the lazy bootstrapping explainer.Parameterized difficulty #1351Implement support for prioritizing blocks with higher work above those with lower work. This is the first change in a series to make Proof-of-Work ultimately dynamic based on network conditions and only implements processing priority on the server side.Store confirmation height in database to allow synchronously querying confirmation #1303Allows nodes to check on the confirmation of old blocks locally, instead of requesting confirmation from the network. Additionally, adds block cementing in nodes. If a rollback occurs, nodes will crash instead of replacing blocks in their ledger.Log vote processing time#1344Log vote processing time to record how many votes are coming in without the spam of logging every vote. Now counts the time spent voting instead of the individual amounts when there are more than 50 votes over 100 milliseconds.Reply to confirm_reqs with a vote by hash#1335Previously, reps would respond to new blocks with a vote by hash, but if you specifically asked for a confirmation request, they would return an old style vote containing the full block. With this addition, Representatives now respond with a hash vote.Block uniquer#1358When a node receives the same block multiple times, it now creates and assigns a unique identifier, resulting in the block being stored only once. Reduces memory usage.Log UPnP devices only if configured to do so#1333Instead of default logging things related to UPnP, introduces a toggle which allows you to turn the option on/off. Defaults to off.Bootstrap traffic stats#1330Payload traffic was previously only collected for the real-time network. With this change, statistics related to the bootstrapping network are now also recorded. Allows you to query how many bootstrapping packets have been processed by your node and how many megabytes of blocks have been used by the bootstrap network.Name threads by role#1258Users can now view the CPU utilization each thread is using, and how much time that thread has been runnable. The updated names correlate node activities to the current running thread and actively assist in finding issues or bottlenecks within the network.Add unreachable host stats#1329Whenever a node tries to reach out to a host and fails because it is unreachable, statistics are now recorded.Immediate election starts#1314Starts elections immediately instead of waiting for a threshold. As soon as a node receives a block, it begins to process votes, reducing latency.Logging vote tallies in a single block instead of separate lines.#1313Eliminates irrelevant timestamp spam and ensures no other logging comes between lines by logging vote tallies in a single block instead of on separate lines.Separate vote generation process#1302Decouples vote generation from quorum solicitation. Previously both were done in one large announce loop which on average would delay vote generation by 1/2 the announcement interval.Now we announce votes as soon as a local decision is made, i.e. a block is inserted into the ledger.Creates a new thread in the node that handles voting, separate from announcing and reduces the time from when a block enters a representative to when the votes are generated.Log common exceptions before asserting #1278If there is an exception thrown by the packet processor thread, now displays information related to the crash.Separate config option for network threads#1276When processing packets on the real-time network, you can now specify how many threads are used instead of using the same amount as I/O threads.Fix deadlock for elections escalation #1254When an election has been active for a long period of time, will move to the previous block on an account-chain to check confirmation.Check genesis on startup#1124Verifies the correct database is being utilized with the correct node. If you have a beta network database and try to run it on a real-time network node, it will fail.Additional message stats#1234Add two counters for packets which are received by a node that is malformed or belong to a different network, such as the beta network.Add “latest-including-rc” tag for Docker#1193Latest tag only points to the latest release, not release candidate. Introduces the latest-including-rc tag, which runs the most recent release or release candidate.Validate pending blocks#1160Extends debug_validate_blocks to also validate pending blocks in addition to confirmed blocks.Batch state blocks signatures verification #956When receiving state blocks, groups signatures together and verifies them at together, resulting in faster verification.Limit the amount of deduplication items we store#1371In order to avoid a situation where too much memory is committed to the bulk_pull_account bootstrap operation, duplicates are now allowed to be sent if too much memory has been allocated.Make signatures non-deterministic #1353When signing the same message twice, each signature will be different in order to prevent against side-channel attacks on CPUs.Dedicate a full r hash block to attacker unknown bytes#1368Dedicates a full hash block to the key and random bytes to prevent side-channel attacks, as recommended in EnhancementsNode ID RPC#948New RPC for Node ID and Node ID delete. Allows for the deletion of a Node ID and generates a new one upon next connection.Enhance version RPC#1194If you use the RPC command version, responds with network protocol version.Add weight option and account filter to representative_online RPC call#1300When querying the RPC for a list of representatives, enables the option to return voting weight. Allows filtering by account.Filter password, wallet, key, seed from RPC logging#1343Adds additional comprehensive filters to ensure removal of password, wallet, key, and seed for RPC logs.Added support for PENDING_HASH_AMOUNT_AND_ADDRESS to bulk_pull_account #1201The command now has the option to respond with the address, hash and amount of pending blocks to your account when enabled. The default is amount and hash.Developer Wallet EnhancementsCLI wallet_import force wallet creation if requested #1357When using the wallet_import currently the wallet_id must already exist on the node. With this change, passing — force 1 will allow it to create the wallet using the specified wallet_id and then import the accounts into that wallet from the supplied backup file. When you import a wallet, you no longer have to create the wallet first.New unit labels from legacy XRB to NANO style#1301Updates the GUI labeling to use NANO, Mnano, knano and nano instead of XRB, Mxrb, kxrb and xrb respectively in the developer wallet.Using QSettings to persist application settings for selected ratio scale#1299The developer wallet now remembers the base unit that was most recently selected.Force macOS wallet to use aqua light mode whilst QT adds support for…#1279Dark mode for macOS won’t be supported in QT until version 5.12 which is expected to be released in November. Until that time, this PR adds a patch to force the macOS client to use light mode and ignore the system setting of dark mode. References #1275Change default desktop config.json #1247For the developer desktop wallet, disables voting and reduces the number of bootstrap connections to reduce the load on slow PCs.Enhancements to the Testing EnvironmentSpeed up testing by using run_one_for #1312Enhancement to the testing suite. Improves how timeouts are dealt it.Initial bootstrap weight for betanet#1179Hardcodes bootstrap weight into the beta network, just like the production network.

Original article was created by: Nano at

Disclaimer: This article should not be taken as, and is not intended to provide, investment advice. Please conduct your own thorough research before investing in any cryptocurrency or ICO.

Interested in Cryptocurrencies and ICO's?

Follow our telegram channel for daily cryptomarket reports!

Join @cointrends

Related Articles

pubDate Newsline

Stay on top of Altcoins and ICO trends.

Subscribe to our free Weekly Cryptomarket report

Delivered once a week, strongly to your inbox.

Subscribe to our mailing list
November 09, 2018
November 07, 2018

Weekly Spotlight: OpenCAP

Nano Foundation does not endorse or approve products and/or services used or developed by third parties. Any links to third party software or sites are for informational purposes only. Nano Foundation bears no responsibility for the operability, accuracy, legality or content of third party...

From: Nano
November 06, 2018

Nano Explainer: Lazy Bootstrapping

With the Boulton release on the horizon, the focus turns to one of the more anticipated features to hit the network in some time, lazy bootstrapping! Lazy bootstrapping improves the current bootstrapping process, or the mechanism used by nodes to bulk update their ledger. Let’s take a look at...

From: Nano
November 05, 2018

Weekly Nano Update: 11/5/18

Blockchain for EuropeSummitOn November 27th, Colin will be attending the Blockchain for Europe Summit at the European Parliament. He will be participating in a panel on Tokenized Economies and Cryptocurrency hosted by Eva Kaili, an MEP representing the Social-Democratic party of Greece and...

From: Nano
November 02, 2018

The Incentives to Run a Node

When building the Nano protocol, the goal has always been to create the most efficient network possible without sacrificing security. By making the cost of reaching consensus, or the network determining transactions to be valid, trivial, requiring only minimal amounts of storage, bandwidth, and...

From: Nano
October 31, 2018

Spotlight: Nanollet

Hi everyone,This week I got to chat with Lucas, better known as “Inkeliz”, the developer of Nanollet! Nanollet is a bit different than other wallets in the Nano eco-system, as it does not require a back-end server. Lucas has continued to add unique, interesting features and I was excited to...

From: Nano
Upcoming ICO's
This week overview
Cryptocurrency rates
*Last hour average price&change
Coin Name Price Hour
Bitcoin logo BTC $3509.48631066 -0.6%
Ripple logo XRP $0.3019971257 -0.51%
Ethereum logo ETH $91.4814123604 -0.46%
Stellar logo XLM $0.1168249576 -1.07%
Tether logo USDT $1.0165882137 -0%
Bitcoin Cash logo BCH $106.510826127 -0.01%
EOS logo EOS $1.9783625088 0.11%
Litecoin logo LTC $24.7691839233 -0.82%
Tronix logo TRX $0.0132100472 -0.33%
Cardano logo ADA $0.0302286394 -0.62%
Monero logo XMR $44.7440546999 -0.56%
NEM logo XEM $0.072338529 -0.63%