Skip to content

Bringing unmerged changes back#665

Open
a-noni-mousse wants to merge 14 commits intoXahau:devfrom
a-noni-mousse:dev
Open

Bringing unmerged changes back#665
a-noni-mousse wants to merge 14 commits intoXahau:devfrom
a-noni-mousse:dev

Conversation

@a-noni-mousse
Copy link
Contributor

@a-noni-mousse a-noni-mousse commented Jan 11, 2026

Some initial improvements to the code. Many of these are based on code by @nbougalis, before he left from Ripple, that aimed to improve the performance of the code but were never merged. I had cloned his repo before he deleted it and now I am taking those changes and updating them and merging them to xahaud.

a-noni-mousse and others added 6 commits January 20, 2026 09:46
- Fix several compilation warnings
- Fix header includes
- Fix unnecessarily verbose loggings
- Remove std::bind
 - Add function-based spinlock API
 - Properly use compare_exchange_strong for try_lock
 - Improve comments

Co-authored-by: Nikolaos D. Bougalis <nikb@bougalis.net>
 - Improve the slab allocator public interfaces
 - Support construction of slab allocators at compile time
 - Improve declaration of slab allocators
 - Reduce impact of thrashing around slab boundaries
 - Reduce overhead of locking and increase parallelization

Co-authored-by: Nikolaos D. Bougalis <nikb@bougalis.net>
The code originated from an external library and was modified
ad-hoc over time. This commit begins to address accumulated
technical debt and introduces performance improvements.

Changes:
- Improved move semantics
- Reduced object size
- Small-string optimization
- Slab allocator for string allocation

The slab allocator targets the observed allocation distribution
(across 9.5 billion calls):

    [ 1, 32]: 17%
    [33, 48]: 27%
    [49, 72]: 57%
    [   >72]:  2%

Expected improvement for JSON-heavy workloads (RPC, WebSocket) through
reduced allocation overhead and memory fragmentation.

Co-authored-by: Nikolaos D. Bougalis <nikb@bougalis.net>
Remove unused dynamic thread count adjustment and reduce indirection
layers. Retains lock-free design while improving code clarity and
reducing internal latency.

Co-authored-by: Nikolaos D. Bougalis <nikb@bougalis.net>
This commit cleans up and modernizes the JobQueue but does not change
the queueing logic. It focuses on simplifying the code by eliminating
awkward code constructs, like "invalid jobs" and the need for default
constructors.

It leverages modern C++ to initialize tables and data structures at
compile time and replaces `std:map` instances with directly indexed
arrays.

Lastly, it restructures the load tracking infrastructure and reduces
the need for dynamic memory allocations by supporting move semantics
and value types.

Co-authored-by: Nikolaos D. Bougalis <nikb@bougalis.net>
Chenna Keshava B S and others added 8 commits January 20, 2026 09:51
The existing code attempted to restrict the instantiation of `Coro`
only to a subset of helper functions, by using the `Coro_create_t`
helper structure. But the structure was public, which limited the
effectiveness of this method.

This commit uses a private type, fixing the issue.
This refactor was primarily aimed at reducing the size of
objects derived from TimeoutCounter, by improving packing
of structures. Other potential improvements also surfaced
during this process and where implemented.
Even with TLS encrypted connections, it is possible for a determined
attacker to mount certain types of relatively easy man-in-the-middle
attacks which, if successful, could allow an attacker to tamper with
messages exchanged between endpoints.

The risk can be mitigated if each side has a certificate issued by a
CA that the other side trusts. In the context of a decentralized and
permissionless network, this is neither reasonable nor desirable.

To prevent this problem all we need is to allow the two endpoints, A
and B, to be able to independently verify that they are connected to
each other over a single end-to-end TLS session, instead of separate
TLS sessions which the attacker bridges.

The protocol level handshake implements this security check by using
digital signatures: each endpoint derives a fingerprint from the TLS
session, which it signs with the private key associated with its own
node identity. This strongly binds the TLS session to the identities
of the two endpoints of the session.

This commit introduces a new fingerprint derivation that uses modern
and standardized TLS exporter functionality, instead of the existing
derivation whch uses OpenSSL APIs that are non-standard, and derives
different "incoming" and "outgoing" security cookies.

Lastly, this commit refines the "self-connection" check to allow for
the detection of accidental instances of node identity sharing. This
check was first introduced with #4195 but was partially reverted due
to a bug with #4438. By using distinct security cookies for incoming
and outgoing connections, an attacker is no longer able to claim the
identity of its peer by echoing its security cookie.

The change is backwards compatible and servers with this commit will
still generate and verify old-style fingerprints, in addition to the
new style fingerprints.

For a fuller discussion on this topic, please see:
    openssl/openssl#5509
    XRPLF/rippled#2413

This commit was previously introduced as #3929, which was closed. If
merged, it also fixes #2413 (which had been closed as a 'WONTFIX').
The hardened hash implementation carried dead weight: SipHash
compatibility code that never saw use, plus template indirection
now superseded by inline variables.

Separately, base_uint_hasher in RWDBFactory had a bug: it would
instantiate a new hardened hasher per operation. Since nothing
used this type anyway, it's been removed entirely.
@a-noni-mousse
Copy link
Contributor Author

I have signed all commits and tried to fix the clang-format issue

@a-noni-mousse a-noni-mousse changed the title Bringing Bringing unmerged changes back Jan 20, 2026
@sublimator
Copy link
Collaborator

I believe we're going to be upstreaming a bunch of changes from ripple[d] at some point soonish so these are probably going to the back of the queue

@tequdev knows more

@a-noni-mousse
Copy link
Contributor Author

a-noni-mousse commented Jan 25, 2026

After reviewing in response to your message, there does not appear to be much worth pulling. The rippled codebase quality has degraded significantly over the past two years.

This is still a work in progress and delays in merging contributions are expected in open-source projects so merging may not be desirable at this point.

Opening a PR with this many commits was an error on my part anyways. Splitting it into smaller PRs would have been more appropriate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants