Repository navigation
Core crypto-currency support: wallets, chains, native/GPU kernels, async batches - #6118
Open
shai-almog wants to merge 56 commits into
Open
shai-almog wants to merge 56 commits into
shai-almog wants to merge 56 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>
Contributor
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
Collaborator
Author
|
Compared 206 screenshots: 206 matched. Benchmark ResultsDetailed Performance Metrics
|
Collaborator
Author
|
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 |
Collaborator
Author
|
Compared 206 screenshots: 206 matched. ParparVM vs HotSpot (JDK 25): Linux x64Runner CPU: AMD EPYC 9V74 80-Core Processor (baseline 1 improvement past the baseline (not a failure; rebaseline to lock it in):
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
A change that moves performance ON PURPOSE records the new baseline in Result: no regression (improved past the baseline: consider rebaselining) |
Collaborator
Author
|
Compared 206 screenshots: 206 matched. ParparVM vs HotSpot (JDK 25): Linux arm64Runner CPU: Neoverse-V3 (no baseline for this CPU model -- the gate fails until one is added; see below) 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
No baseline for 13 rows on The rows it will add{
"linux-arm64@neoverse-v3": {
"hello": {
"all": {
"time": 1.001,
"memory": 0.886
}
},
"translator": {
"all": {
"time": 0.739,
"memory": 0.417
}
},
"intArithmetic": {
"all": {
"time": 1.0,
"memory": 0.035
}
},
"longArithmetic": {
"all": {
"time": 1.043,
"memory": 0.036
}
},
"mathTranscendental": {
"all": {
"time": 1.076,
"memory": 0.037
}
},
"arraySequential": {
"all": {
"time": 0.362,
"memory": 0.368
}
},
"arrayRandom": {
"all": {
"time": 0.939,
"memory": 0.202
}
},
"objectAllocation": {
"all": {
"time": 2.32,
"memory": 0.316
}
},
"valueEscape": {
"all": {
"time": 0.508,
"memory": 0.031
}
},
"hashMapChurn": {
"all": {
"time": 0.696,
"memory": 0.118
}
},
"stringBuilding": {
"all": {
"time": 1.573,
"memory": 0.317
}
},
"recursion": {
"all": {
"time": 1.419,
"memory": 0.036
}
},
"quicksort": {
"all": {
"time": 0.972,
"memory": 0.094
}
}
}
}Result: no baseline: calibration required |
Collaborator
Author
|
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>
Contributor
✅ ByteCodeTranslator Quality ReportTest & Coverage
Benchmark Results
Static Analysis
Generated automatically by the PR CI workflow. |
Contributor
Flutter vs Codename OneNo benchmark results were produced. |
Contributor
|
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>
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>
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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