Repository navigation
Core crypto-currency support: wallets, chains, native/GPU kernels, async batches - #6118
shai-almog wants to merge 40 commits into
Conversation
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>
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>
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>
…copes and device recovery, background and charts in the guide Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…d open, every-dispatch-fails fallback pass, measured figures saved Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…first browser run described as sampled Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Cloudflare Preview
|
|
Compared 191 screenshots: 191 matched. Native Android coverage
✅ Native Android screenshot tests passed. Native Android coverage
Benchmark ResultsDetailed Performance Metrics
|
|
Compared 227 screenshots: 227 matched. |
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
|
Compared 206 screenshots: 206 matched. Benchmark ResultsDetailed Performance Metrics
|
|
Compared 206 screenshots: 206 matched. Benchmark ResultsDetailed Performance Metrics
ParparVM vs HotSpot (JDK 25): Windows x64Runner CPU: AMD64 Family 25 Model 1 Stepping 1, AuthenticAMD (baseline 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
Result: no regression |
|
Compared 206 screenshots: 206 matched. ParparVM vs HotSpot (JDK 25): Linux x64Runner CPU: AMD EPYC 9V45 96-Core Processor (baseline 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
Result: no regression |
|
Compared 206 screenshots: 206 matched. ParparVM vs HotSpot (JDK 25): Linux arm64Runner CPU: Neoverse-N2 (baseline 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
Result: no regression |
|
Compared 206 screenshots: 206 matched. Benchmark ResultsDetailed Performance Metrics
ParparVM vs HotSpot (JDK 25): Windows arm64Runner CPU: ARMv8 (64-bit) Family 8 Model D49 Revision 0, MICROSOFT CORPORATION (baseline 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
Result: no regression |
…uct on x86, CI fixes - Ed25519.verify checks [u]B - [v1]R - [v0]A = O with v0 = v1 k (mod 8L), v1 odd, both near 2^127 (binary Euclid on the lattice); exact for every input, torsion included, with (k, 1) as the fallback row. Half the doublings. - Field product: Karatsuba over the two limb halves (75 products instead of 100) on x86 JVMs, where ref10's form is multiplier-bound; ref10 stays on arm64. - Guide and javadoc snippets self-contained for the Playground; the bash block moved to docs/demos. The Playground auto-imports the outer class of Outer.Inner. - Android kernel stamp, bastion template zip, Vulkan ABI check kernel ids, a narrowing compound assignment CodeQL flagged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
✅ ByteCodeTranslator Quality ReportTest & Coverage
Benchmark Results
Static Analysis
Generated automatically by the PR CI workflow. |
Flutter vs Codename OneNo benchmark results were produced. |
|
Developer Guide build artifacts are available for download from this workflow run:
Developer Guide quality checks:
|
… 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>
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 tocom.codename1.security)Signer,SeedSigner, the vault-backedVaultSigner, and theWalletfacade.Performance
CryptoBatchverifies and hashes many entries on every core, with packed zero-copy forms....Asyncform that takes aCallback, delivered on the EDT.crypto-bench.ymlholds 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:
scripts/crypto-bench/charts.pyfrom the committed results.Verification
🤖 Generated with Claude Code