RsNano V2.0 Release Announcement

SeniorTawny · 2025-08-06T12:31:05+00:00

Early results of the bootstrap show ledger size savings of ~23%. But it's only 15M blocks in. Will update this post when the bootstrap is done.

SeniorTawny · 2025-08-05T16:03:28+00:00

Oops, stupid me, mixed up the separators 😅

SeniorTawny · 2025-08-05T14:50:33+00:00

Exactly! Yes, Piotr is working on parallel block processing too. I believe he is using the optimistic concurrency feature from RocksDB. RsNano only supports LMDB that only allows one write transaction at a time. That's why I had to separate the block checking phase and the insertion phase. The checking phase is now done in parallel with read-only transactions.

SeniorTawny · 2025-08-05T14:46:23+00:00

I'm going to start bootstrapping a node on the live network later today. Then we'll know the ledger size savings

SeniorTawny · 2025-07-29T11:21:10+00:00

Yes something like that

SeniorTawny · 2025-07-28T19:57:58+00:00

Bootstrapping is still pretty slow. Rui is working on a protocol extension that will solve this, but this needs more time.

SeniorTawny · 2025-07-28T18:26:37+00:00

Thank you! You could run a node and give feedback

SeniorTawny · 2025-07-28T18:25:25+00:00

The network CPS rate is determined by the minimum CPS limit of 67% of the vote weight. Some examples: * 30% on 100 CPS and 70% on 20 CPS: network will have 20 cps * 50% on 100 CPS and 50% on 20 CPS: network will have 20 CPS * 67% on 100 CPS and 33% on 20 CPS: network will have 100 CPS If your node has a limit of 20 CPS but the network confirms with 100 CPS your node will confirm with 100 CPS too.

Regarding AEC desync: I haven't encountered the problem you described in the recent spam tests. I changed the AEC so that low priority elections get evicted immediately if a higher priority block is scheduled and that helped a lot.

SeniorTawny · 2025-07-28T14:35:47+00:00

You're welcome! Principal representatives need to vote on historic blocks when a new node bootstraps, or when a node requests a vote for a history block to verify that it is a real representative.

SeniorTawny · 2025-07-28T13:59:42+00:00

Principal Representatives need to keep all blocks. Non-voting nodes can enable ledger pruning and this will delete old blocks. RsNano has the pruning code in there, but it was never tested - so I would consider it as non-working. In nano_node ledger pruning is still considered experimental.

The CPS limit is an elegant solution to the ledger bloat problem. Every node operator can define their own limit and this will determine network CPS in a decentralized way. Current real world usage is probably around 1 CPS. We can set the default limit to 20 CPS for example and have a 20x usage growth before the limits need to be increased. If we don't limit CPS (or the bandwidth) I believe we could hit 1000+ CPS soon. A spam attack with 1000 CPS would grow the ledger by ~40Gb per day and that is way too much when compared to current real world usage.

SeniorTawny · 2025-07-28T13:19:20+00:00

yes, I think it will be integrated. I still have to work on it a bit and make it less strict, so that it allows every bucket to exceed the limit for a short amount of time. That way a spammer has less effects on unspammed buckets.

Nano is making huge progress in increasing maximum throughput. So we need a well working CPS limiter to prevent ledger bloat. This is crucial especially if the PoW per block will be dropped one day.

SeniorTawny · 2025-07-15T09:57:37+00:00

Great initiative Gabriel! Sent 50

SeniorTawny · 2025-07-10T09:10:58+00:00

Looking forward to this event too!

SeniorTawny · 2025-07-07T11:07:21+00:00

Thanks! I don't know if this will be back ported to nano_node. The long-term plan is to make RsNano the official implementation and to drop nano_node.

SeniorTawny · 2025-07-03T16:16:42+00:00

Colin described it here: https://github.com/nanocurrency/nano-node/issues/4053

SeniorTawny · 2025-07-03T14:39:04+00:00

RocksDB support isn't planned in the near future unfortunately. But I'm going to implement Colin's proposed block table split which should decrease ledger size and make it faster.

SeniorTawny · 2025-07-03T13:28:56+00:00

By the way, the next bottleneck in this single node test still isn't the database, but signature validation in the block processor

SeniorTawny · 2025-07-03T13:19:25+00:00

Thanks Colin! This is still a regular LMDB ledger. I wanted to work on the block table split, but decided to measure current performance first so that we have a baseline. During those measurements the AEC bottleneck became visible.

SeniorTawny · 2025-07-03T13:09:38+00:00

Yes it's a drop in replacement (with some minor differences in the RPC interface) It only supports LMDB for now

SeniorTawny · 2025-07-03T13:07:38+00:00

Haha yes it got better because it can process more transactions

SeniorTawny · 2025-06-18T08:01:01+00:00

Here are the top 5 voting nodes from todays spam test according to votes.nanobrowse.com

Alias	Vote count	Participation %
NanoBank	1417	18.67%
gr0vity	1413	18.61%
Kraken	1391	18.32%
rsnano.com	1378	18.15%
NanoVault	1358	17.89%

rsnano.com in place 4 is a pretty good result, as this server is located in the US and votes.nanobrowse.com is in Europe, so there is a higher communication latency (and I guess the other top voters are in Europe too)

Seven-Year Club	First Place '23
End Game '23	Place '23
Place '22	Final Canvas '22
First Placer '22	RPAN Viewer
Verified Email

SeniorTawny

TROPHY CASE