Fix: Update wallet_propose method to use ED25519 as the default algorithm

[ckeshava]

High Level Overview of Change

This PR aims to bring consistency between client library behavior and the rippled CLI's wallet_propose RPC. This PR needs to be viewed in conjunction with https://github.com/XRPLF/xrpl-py/pull/770, https://github.com/XRPLF/xrpl-dev-portal/pull/2844. The client libraries use ed25519 as the default algorithm for Wallet-related methods, unlike rippled CLI which uses secp256k1 algorithm.

Note: keyPairForSignature method still uses secp256k1 as the default cryptographic signing algorithm. I have not made any changes such internal methods.

Context of Change

Since this is a breaking-change, I expect that I need to document this change somewhere in a CHANGELOG. But I'm not sure of the exact filename.

Type of Change

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] Refactor (non-breaking change that only restructures code)
• [ ] Performance (increase or change in throughput and/or latency)
• [x] Tests (you added tests for code that already exists, or your new feature included in this PR)
• [ ] Documentation update
• [ ] Chore (no impact to binary, e.g. .gitignore, formatting, dropping support for older tooling)
• [ ] Release

API Impact

• [ ] Public API: New feature (new methods and/or new fields)
• [x] Public API: Breaking change (in general, breaking changes should only impact the next api_version)
• [ ] libxrpl change (any change that may affect libxrpl or dependents of libxrpl)
• [ ] Peer protocol change (must be backward compatible or bump the peer protocol version)

I don't expect any impact on the performance of the wallet_propose RPC. ed25519 algorithm is expected to be more efficient than secp256k1.

[mvadari]

This is a breaking change and shouldn't be done without an API version bump.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 77.9%. Comparing base (9d58f11) to head (969bcaa). Report is 154 commits behind head on develop.

Additional details and impacted files

@@            Coverage Diff            @@
##           develop   #5186     +/-   ##
=========================================
- Coverage     77.9%   77.9%   -0.0%     
=========================================
  Files          782     782             
  Lines        66616   66615      -1     
  Branches      8161    8137     -24     
=========================================
- Hits         51902   51893      -9     
- Misses       14714   14722      +8     

Files with missing lines	Coverage Δ
src/xrpld/rpc/handlers/WalletPropose.cpp	90.9% <100.0%> (ø)

... and 5 files with indirect coverage changes

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[bthomee]

@mrtcnk would you be able to take a look and assess the impact of this change?

[Bronek]

@ckeshava if you want to proceed with this version then put it under API version guard, for API version 3 (beta).

[mrtcnk]

Based on recent benchmarks and verification performance, I have some concerns about changing the default key type.

Ed25519 signatures provide advantages such as batch verification support for faster verifications and cleaner integration into threshold signature schemes. These features are valuable, particularly for advanced wallet and protocol designs.

However, from a performance perspective, preliminary benchmarks show that the latest version of libsecp256k1 offers faster signature verification than ed25519-donna. Since signature verification is required on-chain (performed by nodes during transaction processing), this may matter for XRPL's long-term scalability. That makes the claim in the PR that Ed25519 is more efficient misleading. It may be true for signing or verifications with batch computation but not for single verification.

Until there is a broader consensus around this tradeoff or until batch verification or Schnorr-like threshold signatures are introduced on XRPL, I recommend delaying any change to the default key type.

[bthomee]

Per @mrtcnk's comment, closing this PR for now.