ED25519 and Ethereum String Serialization Support #170

heifner · 2026-01-09T19:01:51Z

This PR changes standardized string serialization and deserialization for Solana Ed25519 (ED) and Ethereum (EM) cryptographic types. It enables conversion between native string formats (e.g., Solana-style Base58 for ED25519 and Hex for Ethereum) and the project's internal public_key, private_key, and signature storage types.

Changes

`fc::crypto` type changes

fc::crypto public_key, private_key, signature types now have a from_string() instead of constructors for converting from a string. The from_string takes an optional type for specification of the type of key/signature to create. If the default unknown is provided then the prefix strings like PUB_ED_ is required so that the type can be inferred from the string.
to_string() now takes a bool include_prefix defaulting to false. If true then the type prefix, e.g. PUB_ED_ is added to the string. This is useful for knowing how to parse the string according to its type. If the default false is provided then the prefix is not included. This currently only affects ED and EM as other existing Wire types like R1 and BLS always provide the prefix since that is part of their "native" string representation.

Ed25519 String Formatting

Implementation: Added to_string and from_string methods to public_key_shim, private_key_shim, and signature_shim using standard Ed25519 Base58 encoding.
Native Support: Integrated Solana-compatible native string parsing through from_native_string_to_signature<chain_key_type_solana> in key_serdes.hpp.

Ethereum (EM) String Formatting

Hex Support: Implemented to_string and from_string for Ethereum types, supporting standard hexadecimal representations for keys and signatures.
Routing: Updated signature.cpp and private_key.cpp to correctly route em types to Ethereum-specific hex utilities via key_serdes.hpp.

Unified Prefix Support

Updated parsing logic to support the following project-standardized prefixes:

Ed25519: PVT_ED_, PUB_ED_, and SIG_ED_.
Ethereum: PVT_EM_, PUB_EM_, and SIG_EM_.
These prefixes are added to unmolested ED base58 and EM hex strings. Clients can simply remove the prefixes. For example, PUB_EM_0x04e68a... => 0x04e68a....

`clio` updates

Add new option clio create key --k1 which will generate K1 keys with PUB_K1_ & PVT_K1_ prefix.
Add new option clio convert k1_public_key which will read either form of K1 key and output both.
Add new option clio convert k1_private_key which will read either form of K1 key and output private key and public key in both formats.

PR also removes unneeded padding from ED signature_shim.

Noticed this: AntelopeIO/spring#1561 after creating the pull request. Need to consider how these changes can co-exist.

…Ethereum norm. Use a from_string instead of a constructor. Optionally allow for string prefixes on EM strings to encode the type. ED string format not implemented yet.

…t' into feature/key-string-formats

… signature. Remove unneeded padding of ED25519 signature_shim.

…PUB_K1_ & PVT_K1_ prefix.

…the wallet.

jglanz

Generally it looks solid; it's to large to go thru every line, but as long as the test suites are running successfully then all is good

Comments/Notes

nits
Use fc::split for string tokenizing instead of boilerplate std::find
Method naming for parse wire [priv|pub|sig] unknown

jglanz · 2026-01-12T02:05:03Z

libraries/libfc/include/fc/crypto/bls_common.hpp

+   inline public_key_data deserialize_bls_base64url(const std::string& base64urlstr) {
+      using namespace fc::crypto::bls::constants;
+      auto res = std::mismatch(bls_public_key_prefix.begin(), bls_public_key_prefix.end(), base64urlstr.begin());
+      FC_ASSERT(res.first == bls_public_key_prefix.end(), "BLS Public Key has invalid format : ${str}", ("str", base64urlstr));


nit: _FMT macro

Not available on this branch.

jglanz · 2026-01-12T02:08:15Z

libraries/libfc/include/fc/crypto/bls_public_key.hpp

      static bls12_381::g1 from_affine_bytes_le(const public_key_data& affine_non_montgomery_le);
   private:
-      public_key_data _affine_non_montgomery_le{};
+      public_key_data         _affine_non_montgomery_le{};


nit: whitespace? could just be browser

jglanz · 2026-01-12T02:11:31Z

libraries/libfc/include/fc/crypto/elliptic_ed.hpp

+   }
+
+   static public_key_shim from_string(const std::string& str) {
+      constexpr size_t max_key_len = 44;


is this equivalent to key data_size literals? If yes, move up to key_type types?

These are max lengths for base58 encoding. Probably best thing would be to rename this to from_base58_string()

jglanz · 2026-01-12T02:17:00Z

libraries/libfc/include/fc/crypto/key_serdes.hpp

+}
+
+// Given PUB_K1_xxx returns <'PUB','K1','xxx'>
+inline std::tuple<std::string, std::string, std::string> parse_base_prefixes(std::string_view str) {


Use fc::split

fc::split actually doesn't work because BLS strings can have _ in them. For example: PUB_BLS_no1gZTuy-0iL_FVrc6q4ow5KtTtdv6ZQ3Cq73Jwl32qRNC9AEQaWsESaoN4Y9NAVRmRGnbEekzgo6YlwbztPeoWhWzvHiOALTFKegRXlRxVbM4naOg33cZOSdS25i_MXywteRA

jglanz · 2026-01-12T02:19:16Z

libraries/libfc/include/fc/crypto/public_key.hpp


-         std::string to_native_string(const fc::yield_function_t& yield) const;
+         // If include_prefix is true, the prefix will be included in the string representation.
+         // Note for Wire native types (k1, r1, wa, bls) the prefix is always included.


nit: doc format /**

jglanz · 2026-01-12T02:20:21Z

libraries/libfc/src/crypto/private_key.cpp

+      case key_type::r1:
+      case key_type::bls: {
+         private_key k(parse_unknown_wire_private_key_str(str));
+         FC_ASSERT( k.type() == type, "Parsed type ${pt} does not match specified type ${t} for ${k}",


nit: _FMT

Not available on this branch.

jglanz

read other notes first

heifner · 2026-01-12T14:24:17Z

Method naming for parse wire [priv|pub|sig] unknown

Not sure what this is referring to?

…formats

heifner added 4 commits January 8, 2026 17:34

Modify string format of EM public/private/signature to correspond to …

c529a7f

…Ethereum norm. Use a from_string instead of a constructor. Optionally allow for string prefixes on EM strings to encode the type. ED string format not implemented yet.

Merge remote-tracking branch 'origin/feature/trx-block-key-enforcemen…

8f47263

…t' into feature/key-string-formats

Add to/from base58 string support to ED25519 public_key, private_key,…

1bef82d

… signature. Remove unneeded padding of ED25519 signature_shim.

Use valid ed key

9f4e199

heifner requested a review from jglanz January 9, 2026 19:01

heifner added 5 commits January 9, 2026 13:23

Fix signature to_variant and add tests

c4209f6

Fix BLS string parsing and add additional tests

792090b

Add new option clio create key --k1 which will generate K1 keys with …

01b3c55

…PUB_K1_ & PVT_K1_ prefix.

Add new convert options k1_private_key and k1_public_key

042bb53

Use --k1 option for create key since that is the default returned by …

5478fc3

…the wallet.

jglanz reviewed Jan 12, 2026

View reviewed changes

jglanz approved these changes Jan 12, 2026

View reviewed changes

Address PR comments: Updated comments and renames.

cc6473b

Base automatically changed from feature/trx-block-key-enforcement to master January 12, 2026 15:10

Merge remote-tracking branch 'origin/master' into feature/key-string-…

d2e2167

…formats

heifner merged commit 7513746 into master Jan 16, 2026
21 of 27 checks passed

heifner deleted the feature/key-string-formats branch January 16, 2026 16:21

ED25519 and Ethereum String Serialization Support #170

ED25519 and Ethereum String Serialization Support #170

Uh oh!

Conversation

heifner commented Jan 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

fc::crypto type changes

Ed25519 String Formatting

Ethereum (EM) String Formatting

Unified Prefix Support

clio updates

Uh oh!

jglanz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

heifner Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jglanz left a comment

Choose a reason for hiding this comment

Uh oh!

heifner commented Jan 12, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

heifner commented Jan 9, 2026 •

edited

Loading

`fc::crypto` type changes

`clio` updates

heifner Jan 12, 2026 •

edited

Loading