Core crypto-currency support: wallets, chains, native/GPU kernels, async batches by shai-almog · Pull Request #6118 · codenameone/CodenameOne

shai-almog · 2026-10-27T10:16:07Z

Adds a built-in crypto-currency stack, shared between the client and the backend, with no third-party libraries.

API (com.codename1.crypto.*, plus additions to com.codename1.security)

Primitives: secp256k1 (ECDSA and recovery), BIP-340 Schnorr, Ed25519, Keccak-256, SHA-256/512, RIPEMD-160, HMAC and PBKDF2.
Keys: BIP-39 mnemonics, BIP-32 (including xpub derivation), SLIP-10 and derivation paths.
Chains:
- EVM: addresses, legacy/EIP-2930/EIP-1559 transactions, EIP-191/712 signing, the Solidity ABI.
- Bitcoin: addresses, transactions with sighash, Taproot and PSBT.
- Solana: addresses, messages, transactions and instructions.
Wallets: Signer, SeedSigner, the vault-backed VaultSigner, and the Wallet facade.
Network: RPC clients for EVM, Esplora and Solana, and price feeds.
Bastion now uses the core classes instead of its own copies.

Performance

Native C kernels on ParparVM targets and Android JNI, with SIMD paths:
- ARMv8.2 SHA3 instructions for Keccak;
- SHA instructions for SHA-256;
- AVX2 hash groups on x86.
CryptoBatch verifies and hashes many entries on every core, with packed zero-copy forms.
Large batches are split between the CPU and the GPU: Metal on Apple platforms, Vulkan elsewhere, WebGPU in the browser.
Every batch method has an ...Async form that takes a Callback, delivered on the EDT.
crypto-bench.yml holds each kernel to a ratio floor against libsecp256k1, OpenSSL/libsodium and BouncyCastle on the same runner.

Docs: a new developer-guide chapter, "Crypto wallets". It covers:

background on the algorithms;
each chain end to end;
batches and the asynchronous forms;
a Performance section with tables and five charts, drawn by scripts/crypto-bench/charts.py from the committed results.

Verification

The WebGPU kernels agree with the C kernels on 518 test vectors.
The Java record prep matches the C prep word for word.
In the browser, every GPU answer is checked against the CPU engine, including a pass where every GPU dispatch is forced to fail.
Local checks:
- core-unittests: 8272 tests pass, SpotBugs 0;
- ByteCodeTranslator SpotBugs 0;
- PMD and Checkstyle clean;
- javadoc builds for the client and backend references;
- vm/tests JavaScript: 413 tests pass.

🤖 Generated with Claude Code

secp256k1 moves from 16-bit limbs and Fermat inversion to 26-bit field limbs with lazy reduction, safegcd inversion, a signed-digit comb for k*G and a GLV/wNAF Strauss double multiplication for verify and recover: pubkey 573 -> ~45k/s, sign 506 -> ~34k/s, verify 266 -> ~20k/s on HotSpot, 1.2-2x BouncyCastle. Keccak-f is unrolled into locals (8x). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…pto kernels Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…nk them on use Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…bsodium, OpenSSL, BouncyCastle Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…swords, probed against the Mac loop Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…ation, SLIP-10 Ed25519, derivation paths Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…VM addresses, transactions, ABI, EIP-191, EIP-712, ERC-20 java.math is not in the device class library, so the encoding commit's Rlp could never have linked on a device; UInt256 replaces it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…BIP-341 sighash, Taproot, PSBT, WIF Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…sactions, System/Token/ComputeBudget/Memo; shared Base64 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

… PSBT signs through BitcoinKey and reads BIP-32 origins Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…ort with client and backend transports; randomness through CryptoEngine so the crypto stack builds in the backend; SpotBugs fixes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

… caching decorator Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…-1559/Wei/address classes ChainVectorTest keeps the recorded signed bytes and derived addresses byte-identical; EthRpc is a thin EvmRpc subclass over WebRpcTransport that keeps the HTTPS-or-localhost rule. SpotBugs exclusion for the one-shot NetworkTransport request. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Recovery phrase to wallet, addresses per chain, sending on EVM, Bitcoin (PSBT) and Solana, price feeds, and where keys live (vault vs server). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…encodings, HD and chain formats Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

… usage The ParparVM kernel sources compile unchanged against a JNI shim; four ABIs, API 21, 16 KB pages. AndroidImplementation loads them behind a guarded System.loadLibrary and falls back to the Java engine. A source stamp and scripts/check-android-crypto-kernels.sh catch stale binaries. Bench: dalvikvm leg in scripts/crypto-bench/android-run.sh. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…d CryptoEngine SHA instructions where the CPU has them (ARMv8 SHA-256, ARMv8.2 SHA-512, x86 SHA-NI), picked once per process, unrolled portable C otherwise; Ed25519's SHA-512 goes through the same path. Hash, Hmac and Pbkdf2 route the one-shot SHA-256/512 and RIPEMD-160 forms through new engine hooks, so BIP-32 and BIP-39 run native. Android libraries rebuilt; bulk ParparVM run covers every padding boundary (349 checks, 0 failing). Apple silicon vs OpenSSL: sha256 1.09x, sha512 1.21x, hmac 2.62x, pbkdf2 1.18x, ripemd160 1.34x. Android emulator vs BouncyCastle: 1.8-6.6x. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

One native call per batch, cut into chunks run by libdispatch on Apple, pthreads on Linux/Android and Win32 threads on Windows; small batches run inline. Every entry gets the single-call answer (no Ed25519 batch equation), and a malformed entry is invalid rather than an exception. The JNI wrapper uses Get<Type>ArrayElements so a long batch never holds a critical region. 16-core Apple silicon vs the reference on one core: ECDSA 8.0x libsecp256k1, Ed25519 17.6x OpenSSL, SHA-256 Merkle nodes 5.5x OpenSSL. Android emulator vs BouncyCastle: ECDSA 18.3x, Ed25519 4.7x. Bulk ParparVM run: 351 checks, 0 failing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…ve kernels Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Debian 12's clang 14 declares the SHA intrinsics only for a translation unit built for the extension, and GCC 12 refuses to inline them under the target names clang uses. Old clang gets the instructions as inline assembly, GCC asks for the targets its own header declares them under. selftest.c checks the hash kernels with only a C compiler, which is how this was found. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…ructions CryptoBatch gains fixed-stride forms of every batch (hashes 32*n, signatures 64*n, keys keyLength*n, one result byte each). On ParparVM the kernels read those arrays where they are: no flattening, no per-entry objects, nothing copied in or out. Simd.allocByte aligns them for the vector units. Keccak-f runs on EOR3/RAX1/XAR/BCAX, two states per permutation, one per lane: a single hash is 1.04x the portable code and a batch hashes two inputs per permutation, 2.1x on one core. SHA-256 batches run two streams through the SHA unit together. The core count is asked once, not per batch. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…N-wide batch grouping Hash batches now run in groups of the widest lane count the CPU has: two on ARMv8 (SHA3 / two-stream SHA-256), four Keccak and eight SHA-256 lanes in AVX2 on x86 (SHA-256 only without SHA-NI). AVX2 is used only when cpuid reports it and XGETBV says the OS saves YMM state. Also restores the escaped newlines in the old-clang SHA3 asm shims, which had become literal newlines and failed to compile on clang 14. selftest.c cross-checks every lane of each group against the single hash; passes on Apple clang, clang 14, GCC 12 (arm64) and x86-64 under Rosetta with and without ROSETTA_ADVERTISE_AVX. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Large verify and hash batches are split between the GPU and every CPU core in the ratio of their measured throughput, and both halves run at once. Metal on iOS and macOS; Vulkan, loaded at run time, on Android, Linux and Windows. The GPU only does the scalar multiplications of public data; parsing, decompression and challenge hashes are prepared on the CPU, so every result is exactly what a single verify answers. The curve kernels use complete projective formulas with one addition and one doubling site per scalar multiplication: drivers inline every call, and the earlier layout took 214 s to compile on lavapipe. All five pipelines now build in seconds. scripts/crypto-gpu holds the shader generator, a check of the hand-declared Vulkan subset against vulkan_core.h, and batch-check, which holds GPU batches to CPU batches and reports throughput and crossover per kernel; the crypto-bench workflow runs them on lavapipe. libcn1crypto.so is rebuilt with the Vulkan host. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

rand_s was implicitly declared, which clang 16+ rejects; found by a mingw cross build of the Vulkan host. libcn1crypto.so rebuilt for the new digest. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…hmarks in the guide Every CryptoBatch method gains an Async form taking a Callback: arguments are checked before it returns, the batch runs through CryptoEngine.runInBackground and the answer arrives through deliver (the EDT on a port). The JavaScript port's HTML5CryptoEngine sends large batches to WebGPU kernels generated from the same source as the Metal and Vulkan ones (WGSL through naga), with the Java prep held to the C prep word for word and the kernels to the C answers. The kernel asset ships only with applications that run a batch. The developer guide gains a Performance section: tables for the JVM, native, Android, the GPU split and the browser, and two charts drawn by scripts/crypto-bench/charts.py from the committed results. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

github-actions · 2026-10-27T12:37:51Z

Developer Guide build artifacts are available for download from this workflow run:

Developer Guide quality checks:

AsciiDoc linter: No issues found (report)
Vale: No alerts found (report)
Paragraph capitalization: No paragraph capitalization issues (report)
LanguageTool: No grammar matches (report)
Image references: No unused images detected (report)

… chart alt texts Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

… guide names the core classes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…point Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

# Conflicts: # Ports/LinuxPort/src/com/codename1/impl/linux/LinuxImplementation.java # docs/developer-guide/languagetool-accept.txt # vm/backend/package-docs/com/codename1/security/package-info.java

Two runners read 2.15 and 1.74 with our side unchanged (45 and 47 batches/s); the single-core reference moved 21 to 27. The row pits all cores against one, so it measures the runner's core count too. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The arm64 Linux suite landed on a runner CPU no run had measured, which the gate reports as calibration required. Rows from that job's perf-results.json via calibrate-perf-baseline.py; folded into base/ by the nightly job. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

# Conflicts: # scripts/bastion/common/src/test/java/com/codenameone/examples/bastion/net/GuardTest.java

…he Rust rps floor crypto.encoding.Hex and crypto.encoding.Base64 duplicated Hash.toHex/fromHex and java.util.Base64, which every target already has. Hash.fromHex now takes the 0x prefix Ethereum writes. The backend gate's peak-throughput floor against Rust moves from 1.0 to 0.97: passing runs lead by 0.5-2.7% and a noisy one fell 0.7% short with the request path unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

UTF-8 goes through StandardCharsets.UTF_8, which every target has; Bech32 uses Rlp's concat; Secp256k1Math's generator constants decode with Hash.fromHex. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…d parsers JSONParser no longer reaches processing.Result (mapToJson now has its own writer, held byte-for-byte to Result's output by JSONParserSharedTest), Log (a package-private Diagnostics sink Log installs from its static initializer) or Util. It, JSONParseCallback, JSONSanitizer and CharArrayReader are @SharedWithBackend. New JSONParser.parseStrict(String[, exactIntegers]) is the RFC 8259 reader moved from com.codename1.backend.Json; backend Json.parse delegates to it. Crypto uses parseStrict(.., true) (an integer past a long is a RawJson of its exact digits, never a double) and toJson for JSON-RPC requests; crypto/encoding/Json is deleted. NetworkTransport uses StandardCharsets. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

JSONParser now carries the writer Result used, so HashtableContent calls mapToJson and the new listToJson instead of keeping a second copy. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

com.codename1.util.BigInteger and the T* helpers it needs (plus MathUtil, for TConversion's radix log) are marked @SharedWithBackend. The three static bit helpers the T* classes borrowed from TBigDecimal move to TBitLevel so TBigDecimal stays client-only. UInt256 drops its hand-written limb arithmetic and keeps its API as a range-checked wrapper. Also removes the redundant java.util.List qualifiers PMD flagged in JSONParser. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

PrettyPrinter's code moved into JSONParser without the licence it carries; it is io.PrettyPrinter now, notice and history intact, shared with the backend. PriceFeeds wraps a malformed raw number in IOException as it does a string one. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…e backend The @SharedWithBackend marker touched eight vendored files (Apache Harmony, Google json-sanitizer, Bouncy Castle), which pulled them into the diff-scoped header gate. They keep their original notices, as their already-listed siblings do. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…64 and Hex Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

shai-almog · 2026-10-29T02:46:44Z

Compared 189 screenshots: 189 matched.
✅ Native iOS Metal screenshot tests passed.

Benchmark Results

VM Translation Time: 0 seconds
Compilation Time: 2318 seconds

Build and Run Timing

Metric	Duration
Simulator Boot	54000 ms
Simulator Boot (Run)	1000 ms
App Install	19000 ms
App Launch	5000 ms
Test Execution	434000 ms

Detailed Performance Metrics

Metric	Duration
SIMD kernel backend	SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300)	java 162ms / native 3ms = 54.0x speedup
SIMD float-mul (64K x300)	java 82ms / native 3ms = 27.3x speedup
SIMD kernel correctness	PASS (native result == scalar reference)
Base64 payload size	8192 bytes
Base64 benchmark iterations	6000
Base64 SIMD byte path	active (NEON-accelerated)
Base64 CN1 encode	53.000 ms
Base64 CN1 decode	64.000 ms
Base64 native encode	836.000 ms
Base64 encode ratio (CN1/native)	0.063x (93.7% faster)
Base64 native decode	807.000 ms
Base64 decode ratio (CN1/native)	0.079x (92.1% faster)
Base64 SIMD encode	55.000 ms
Base64 encode ratio (SIMD/CN1)	1.038x (3.8% slower)
Base64 SIMD decode	78.000 ms
Base64 decode ratio (SIMD/CN1)	1.219x (21.9% slower)
Base64 encode ratio (SIMD/native)	0.066x (93.4% faster)
Base64 decode ratio (SIMD/native)	0.097x (90.3% faster)
Image encode benchmark iterations	100
Image createMask (SIMD off)	9.000 ms
Image createMask (SIMD on)	1.000 ms
Image createMask ratio (SIMD on/off)	0.111x (88.9% faster)
Image applyMask (SIMD off)	393.000 ms
Image applyMask (SIMD on)	23.000 ms
Image applyMask ratio (SIMD on/off)	0.059x (94.1% faster)
Image modifyAlpha (SIMD off)	27.000 ms
Image modifyAlpha (SIMD on)	29.000 ms
Image modifyAlpha ratio (SIMD on/off)	1.074x (7.4% slower)
Image modifyAlpha removeColor (SIMD off)	32.000 ms
Image modifyAlpha removeColor (SIMD on)	34.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off)	1.063x (6.3% slower)

shai-almog · 2026-10-29T02:53:24Z

Compared 192 screenshots: 192 matched.
✅ Native Mac screenshot tests passed.

Benchmark Results

VM Translation Time: 0 seconds
Compilation Time: 449 seconds

Detailed Performance Metrics

Metric	Duration
SIMD kernel backend	SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300)	java 56ms / native 3ms = 18.6x speedup
SIMD float-mul (64K x300)	java 58ms / native 3ms = 19.3x speedup
SIMD kernel correctness	PASS (native result == scalar reference)
Base64 native bridge	unavailable (CN1 + SIMD + image benchmarks only)
Base64 payload size	8192 bytes
Base64 benchmark iterations	6000
Base64 SIMD byte path	active (NEON-accelerated)
Base64 CN1 encode	59.000 ms
Base64 CN1 decode	64.000 ms
Image encode benchmark iterations	100
Image createMask (SIMD off)	15.000 ms
Image createMask (SIMD on)	3.000 ms
Image createMask ratio (SIMD on/off)	0.200x (80.0% faster)
Image applyMask (SIMD off)	74.000 ms
Image applyMask (SIMD on)	69.000 ms
Image applyMask ratio (SIMD on/off)	0.932x (6.8% faster)
Image modifyAlpha (SIMD off)	66.000 ms
Image modifyAlpha (SIMD on)	51.000 ms
Image modifyAlpha ratio (SIMD on/off)	0.773x (22.7% faster)
Image modifyAlpha removeColor (SIMD off)	69.000 ms
Image modifyAlpha removeColor (SIMD on)	67.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off)	0.971x (2.9% faster)

ParparVM vs HotSpot (JDK 25): macOS arm64

Runner CPU: Apple M1 (Virtual) (baseline macos-arm64)

Ratios are ParparVM / JDK 25: below 1.00x ParparVM is faster (time) or smaller (RAM). Median of 5 interleaved, paired rounds; every run's output was verified. A ratio more than 20% (time) / 25% (RAM) above its baseline in vm/selfhost/perf-baseline/ is a regression and fails; one that far below is an improvement, reported but not failed (a row whose calibration runs were noisier carries a wider tolerance), and for RAM the change must also exceed 0.05x in absolute terms. Both run unpinned on all of the runner's CPUs, with their own default thread counts.

Benchmark	Cores	Time	RAM	Status
hello (HelloCodenameOne)	3	0.86x (base 0.96x, -9.6%)	0.89x (base 0.93x, -3.3%)	ok
translator (self)	3	0.60x (base 0.62x, -4.5%)	0.71x (base 0.78x, -9.4%)	ok
intArithmetic	3	1.07x (base 1.03x, +3.8%)	0.12x (base 0.12x, +2.0%)	ok
longArithmetic	3	1.02x (base 1.03x, -0.2%)	0.12x (base 0.07x, +66.8%)	ok
mathTranscendental	3	0.94x (base 1.01x, -6.4%)	0.12x (base 0.12x, +0.7%)	ok
arraySequential	3	0.44x (base 0.42x, +4.9%)	0.53x (base 0.53x, +0.3%)	ok
arrayRandom	3	0.98x (base 0.99x, -0.8%)	0.33x (base 0.32x, +0.5%)	ok
objectAllocation	3	1.03x (base 1.11x, -6.6%)	0.89x (base 0.72x, +22.5%)	ok
valueEscape	3	0.51x (base 0.51x, +0.2%)	0.09x (base 0.09x, +2.1%)	ok
hashMapChurn	3	1.00x (base 1.18x, -14.6%)	0.07x (base 0.07x, -1.6%)	ok
stringBuilding	3	0.86x (base 0.84x, +2.0%)	0.48x (base 0.46x, +4.6%)	ok
recursion	3	1.19x (base 1.24x, -4.0%)	0.12x (base 0.12x, +1.4%)	ok
quicksort	3	1.01x (base 1.01x, -0.0%)	0.11x (base 0.11x, +1.6%)	ok

Result: no regression

shai-almog · 2026-10-29T03:48:20Z

Compared 188 screenshots: 188 matched.
✅ Native Mac screenshot tests passed.

Benchmark Results

VM Translation Time: 0 seconds
Compilation Time: 763 seconds

Detailed Performance Metrics

Metric	Duration
SIMD kernel backend	SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300)	java 87ms / native 3ms = 29.0x speedup
SIMD float-mul (64K x300)	java 72ms / native 2ms = 36.0x speedup
SIMD kernel correctness	PASS (native result == scalar reference)
Base64 payload size	8192 bytes
Base64 benchmark iterations	6000
Base64 SIMD byte path	active (NEON-accelerated)
Base64 CN1 encode	73.000 ms
Base64 CN1 decode	93.000 ms
Base64 native encode	941.000 ms
Base64 encode ratio (CN1/native)	0.078x (92.2% faster)
Base64 native decode	431.000 ms
Base64 decode ratio (CN1/native)	0.216x (78.4% faster)
Base64 SIMD encode	76.000 ms
Base64 encode ratio (SIMD/CN1)	1.041x (4.1% slower)
Base64 SIMD decode	71.000 ms
Base64 decode ratio (SIMD/CN1)	0.763x (23.7% faster)
Base64 encode ratio (SIMD/native)	0.081x (91.9% faster)
Base64 decode ratio (SIMD/native)	0.165x (83.5% faster)
Image encode benchmark iterations	100
Image createMask (SIMD off)	12.000 ms
Image createMask (SIMD on)	15.000 ms
Image createMask ratio (SIMD on/off)	1.250x (25.0% slower)
Image applyMask (SIMD off)	145.000 ms
Image applyMask (SIMD on)	131.000 ms
Image applyMask ratio (SIMD on/off)	0.903x (9.7% faster)
Image modifyAlpha (SIMD off)	70.000 ms
Image modifyAlpha (SIMD on)	90.000 ms
Image modifyAlpha ratio (SIMD on/off)	1.286x (28.6% slower)
Image modifyAlpha removeColor (SIMD off)	112.000 ms
Image modifyAlpha removeColor (SIMD on)	141.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off)	1.259x (25.9% slower)

shai-almog · 2026-10-29T04:27:24Z

Compared 249 screenshots: 249 matched.
✅ Native Apple Watch (watchOS, Core Graphics) screenshot tests passed.

shai-almog · 2026-10-29T04:39:14Z

Compared 189 screenshots: 189 matched.
✅ Native iOS Metal screenshot tests passed.

Benchmark Results

VM Translation Time: 0 seconds
Compilation Time: 2298 seconds

Build and Run Timing

Metric	Duration
Simulator Boot	88000 ms
Simulator Boot (Run)	1000 ms
App Install	19000 ms
App Launch	4000 ms
Test Execution	592000 ms

Detailed Performance Metrics

Metric	Duration
SIMD kernel backend	SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300)	java 218ms / native 4ms = 54.5x speedup
SIMD float-mul (64K x300)	java 195ms / native 11ms = 17.7x speedup
SIMD kernel correctness	PASS (native result == scalar reference)
Base64 payload size	8192 bytes
Base64 benchmark iterations	6000
Base64 SIMD byte path	active (NEON-accelerated)
Base64 CN1 encode	84.000 ms
Base64 CN1 decode	183.000 ms
Base64 native encode	1896.000 ms
Base64 encode ratio (CN1/native)	0.044x (95.6% faster)
Base64 native decode	1599.000 ms
Base64 decode ratio (CN1/native)	0.114x (88.6% faster)
Base64 SIMD encode	107.000 ms
Base64 encode ratio (SIMD/CN1)	1.274x (27.4% slower)
Base64 SIMD decode	197.000 ms
Base64 decode ratio (SIMD/CN1)	1.077x (7.7% slower)
Base64 encode ratio (SIMD/native)	0.056x (94.4% faster)
Base64 decode ratio (SIMD/native)	0.123x (87.7% faster)
Image encode benchmark iterations	100
Image createMask (SIMD off)	7.000 ms
Image createMask (SIMD on)	3.000 ms
Image createMask ratio (SIMD on/off)	0.429x (57.1% faster)
Image applyMask (SIMD off)	97.000 ms
Image applyMask (SIMD on)	133.000 ms
Image applyMask ratio (SIMD on/off)	1.371x (37.1% slower)
Image modifyAlpha (SIMD off)	608.000 ms
Image modifyAlpha (SIMD on)	98.000 ms
Image modifyAlpha ratio (SIMD on/off)	0.161x (83.9% faster)
Image modifyAlpha removeColor (SIMD off)	173.000 ms
Image modifyAlpha removeColor (SIMD on)	721.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off)	4.168x (316.8% slower)

shai-almog · 2026-10-29T05:23:18Z

Compared 184 screenshots: 184 matched.
✅ Native Apple TV (tvOS, Metal) screenshot tests passed.

shai-almog and others added 30 commits October 26, 2026 15:11

security: Secp256k1 docs describe the new engine

10a4adb

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

security: PBKDF2 with precomputed HMAC states, CryptoEngine seam

5f19ae9

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

security: Ed25519, BIP-340 Schnorr, RIPEMD-160, encodings, native cry…

82570e6

…pto kernels Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

security: native crypto kernels wired through the engine, builders li…

5de0aa5

…nk them on use Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

crypto-bench: native and JVM benchmark gates against libsecp256k1, li…

b7b88fc

…bsodium, OpenSSL, BouncyCastle Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

android: PBKDF2 through the provider's SecretKeyFactory for ASCII pas…

87904c1

…swords, probed against the Mac loop Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

crypto.hd: BIP-39 mnemonics, BIP-32 with xpub derivation and serializ…

b406316

…ation, SLIP-10 Ed25519, derivation paths Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

crypto.bitcoin: addresses, scripts, transactions with legacy/BIP-143/…

b809e65

…BIP-341 sighash, Taproot, PSBT, WIF Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

crypto.solana: addresses, PDAs and ATAs, legacy and v0 messages, tran…

13bc334

…sactions, System/Token/ComputeBudget/Memo; shared Base64 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

crypto.wallet: Signer, SeedSigner, VaultSigner and the Wallet facade;…

2238b48

… PSBT signs through BitcoinKey and reads BIP-32 origins Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

crypto.rpc: JSON-RPC, EvmRpc, EsploraClient, SolanaRpc over RpcTransp…

79aa74b

…ort with client and backend transports; randomness through CryptoEngine so the crypto stack builds in the backend; SpotBugs fixes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

crypto.market: PriceFeed, Quote, CoinGecko, template JSON feeds and a…

8146faf

… caching decorator Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Developer guide: Crypto wallets chapter with compiled snippets

7087217

Recovery phrase to wallet, addresses per chain, sending on EVM, Bitcoin (PSBT) and Solana, price feeds, and where keys live (vault vs server). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

crypto: clear PMD forbidden rules; ParparVM bulk checks for UInt256, …

4b120f2

…encodings, HD and chain formats Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

vm/tests: compile the shared crypto stack into the bulk program

b7b0cfa

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

javadoc: no links to client-only classes from shared sources

6fa410f

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Backend API: describe the shared signatures, PBKDF2, batches and nati…

f644bbd

…ve kernels Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

crypto-bench.yml: hold the prebuilt Android kernels to their sources

3e17884

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

crypto kernels: define _CRT_RAND_S before the first stdlib.h on Windows

500df24

rand_s was implicitly declared, which clang 16+ rejects; found by a mingw cross build of the Vulkan host. libcn1crypto.so rebuilt for the new digest. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

shai-almog and others added 20 commits October 27, 2026 15:45

crypto: Ed25519 base table without doublings, divstep inverse, quoted…

1e871f5

… chart alt texts Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

crypto: Schnorr.KeyPair, benchmark signs with a prepared key; Bastion…

a216b7a

… guide names the core classes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs: crypto chapter passes Vale and LanguageTool

2fd7887

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

ci: cancel-stale reads a PR too large for pulls.get from the list end…

5159404

…point Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

bastion: GuardTest installs its own implementation

0b52139

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Merge remote-tracking branch 'origin/master' into core-crypto-wallets

1ce1e55

# Conflicts: # Ports/LinuxPort/src/com/codename1/impl/linux/LinuxImplementation.java # docs/developer-guide/languagetool-accept.txt # vm/backend/package-docs/com/codename1/security/package-info.java

crypto: secp256k1 field product by subtractive Karatsuba on x86

6cc1690

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

crypto: one declaration per line in the secp256k1 field product

72b73eb

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Merge remote-tracking branch 'origin/master' into core-crypto-wallets

806d27a

# Conflicts: # scripts/bastion/common/src/test/java/com/codenameone/examples/bastion/net/GuardTest.java

crypto: drop the UTF-8, concat and hex helper copies

c12d72e

UTF-8 goes through StandardCharsets.UTF_8, which every target has; Bech32 uses Rlp's concat; Secp256k1Math's generator constants decode with Hash.fromHex. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

processing: Result writes JSON through JSONParser, PrettyPrinter is gone

14e74c3

JSONParser now carries the writer Result used, so HashtableContent calls mapToJson and the new listToJson instead of keeping a second copy. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

initializr: resync the Bastion template with the sample

0e915ef

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

vm-tests: the bulk program no longer compiles the deleted crypto Base…

aa4c294

…64 and Hex Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

shai-almog merged commit 24a8459 into master Oct 29, 2026
206 of 207 checks passed

shai-almog deleted the core-crypto-wallets branch October 29, 2026 12:32

shai-almog mentioned this pull request Oct 30, 2026

Release 7.0.280 blockers: backend writer close order, x64 Linux native swap #6135

Merged

Navigation Menu

Repository navigation

Core crypto-currency support: wallets, chains, native/GPU kernels, async batches - #6118

Core crypto-currency support: wallets, chains, native/GPU kernels, async batches#6118
shai-almog merged 56 commits into
masterfrom
core-crypto-wallets

shai-almog commented Oct 27, 2026

Uh oh!

github-actions Bot commented Oct 27, 2026 •

edited

Loading

Uh oh!

shai-almog commented Oct 29, 2026 •

edited

Loading

Uh oh!

shai-almog commented Oct 29, 2026 •

edited

Loading

Uh oh!

shai-almog commented Oct 29, 2026 •

edited

Loading

Uh oh!

shai-almog commented Oct 29, 2026 •

edited

Loading

Uh oh!

shai-almog commented Oct 29, 2026 •

edited

Loading

Uh oh!

shai-almog commented Oct 29, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

shai-almog commented Oct 27, 2026

Uh oh!

github-actions Bot commented Oct 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

shai-almog commented Oct 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Benchmark Results

Build and Run Timing

Detailed Performance Metrics

Uh oh!

shai-almog commented Oct 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Benchmark Results

Detailed Performance Metrics

ParparVM vs HotSpot (JDK 25): macOS arm64

Uh oh!

shai-almog commented Oct 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Benchmark Results

Detailed Performance Metrics

Uh oh!

shai-almog commented Oct 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

shai-almog commented Oct 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Benchmark Results

Build and Run Timing

Detailed Performance Metrics

Uh oh!

shai-almog commented Oct 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

github-actions Bot commented Oct 27, 2026 •

edited

Loading

shai-almog commented Oct 29, 2026 •

edited

Loading

shai-almog commented Oct 29, 2026 •

edited

Loading

shai-almog commented Oct 29, 2026 •

edited

Loading

shai-almog commented Oct 29, 2026 •

edited

Loading

shai-almog commented Oct 29, 2026 •

edited

Loading

shai-almog commented Oct 29, 2026 •

edited

Loading