Secure firmware updating requires authentic artifacts and auditable decisions about release approval, rollout progression, and reported outcomes. This paper presents LedgerGuard, a permissioned distributed ledger technology (DLT) control plane for multi-stakeholder firmware-update governance. LedgerGuard records release commitments, role-distinct approvals, signer revocation, rollout transitions, emergency controls, expected-cohort metadata, and compact outcome commitments on-chain, while firmware packages, software bills of materials, provenance records, and detailed receipts remain off-chain. Authenticated EIP-712 receipts are reconciled against a precommitted cohort, and separate aggregator and witness processes reconstruct receipt and terminal-outcome roots before finalization. Evaluation combines a local four-validator Hyperledger Besu network, a persistent HTTP/SQLite comparator, authenticated software-cohort execution, local IPFS and cache experiments, analytical accountability projections, and security and fault testing. Fifty governance paths produced 350 successful transactions; median submission-to-receipt latency was approximately 2.03 s and followed the configured block period. Across 180 cohort runs, 96,000 signed receipts were generated and reverified. For 500 identities and a batch size of 50, integrity-only and complete-cohort witnessed aggregation reduced transaction counts by 98% and 94%, respectively. The witnessed approach required less gas than per-device reporting for full batches of at least three identities. The results support LedgerGuard when several known organizations require shared authoritative policy state.
A common worry about depeg predictors is that an adversary who manipulates oracle prices can blind them. We test it on a new multi-source corpus of twelve historical stress episodes across nine assets and three chains. Under retrospective leave-one-event-out testing, the reconstructed models span 0.558–0.772 ROC-AUC, with our reference predictor at 0.762; the source papers report different metrics and tasks that are not directly comparable. Manipulable price features hurt out-of-event generalization: on the seven-episode live-feed subgroup, retained features reach 0.75 AUC versus 0.72 for the full model, directional, not significant at seven events. We define the Oracle Manipulation Index (OMI), prove that shifting the aggregate by δ while one honest feed survives forces the unnormalized cross-feed price range to be at least δ/L for L-Lipschitz aggregators, and measure on a Foundry mainnet fork (Curve 3pool, block 25,238,878) that a 0.1% move requires about USD 50 M in deployed capital. Excluding individually affordable channels gives a sufficient input-invariance rule under fixed channel costs; the robust subset matches clean accuracy and degrades less under tested synthetic attacks in point estimate (directional, not significant at seven events). OMI’s empirical lift is modest and regime-dependent (pooled 0.0037, not significant; it helps off-chain and multi-venue settings, not single-venue on-chain ones), and precision is low (about 33 false-positive windows per true-positive window at 10% recall). Within this early-warning setting, oracle manipulation is a weak evasion vector because the tested subset is empirically less sensitive to the evaluated perturbations.
Blockchain and machine learning (ML) are combined in systems that must learn from multi-party data and keep a verifiable record of what was used and decided. This scoping-style review of a ranked sample covers seven domains: healthcare, finance, supply chain, energy, smart contracts, transportation and education. We searched Scopus and IEEE Xplore on 15 October 2026, ranked 5,195 candidate records, read 345 abstracts in rank order, coded a core corpus of 192 studies and read 38 in full. Federated learning is the most common method (93 of 192 core studies name it), and detection of fraud, intrusions and vulnerabilities is the most common task among the 38. None of the 38 reports a deployment, 24 report a measured ledger figure and two measure ledger energy. Ten use more than one privacy mechanism, and only two report accuracy with and without it. Attack tests are small, and one study tests a Sybil attacker. Studies differ too much to compare, so we do not rank domains. A ledger shows that a record has not changed, not that it was correct when written. The main gaps are realistic evaluation, shared benchmarks and reporting standards, and tested explanations for decisions made inside contracts.
Double counting in supply-chain carbon accounting can arise when an emission-related claim remains usable after splitting or integration. Existing systems can strengthen traceability, evidence integrity, or ex-post auditing without defining whether a consumed claim remains valid for reuse. We model this gap as a lifecycle-state consistency problem and present a three-tier framework compatible with Ethereum Request for Comments 1155 (ERC-1155), with three non-fungible token (NFT) lifecycle roles: parent NFT (P-NFT), child NFT (C-NFT), and integrated NFT (I-NFT). The execution-time control layer enforces quantity conservation, immediate parent retirement, and complete-set same-transaction consumption, rejecting violations before state commitment. I-NFT verification binds each integrated claim to its consumed input set through a compact header and issuance-transaction events. Functional validation shows that quantity inflation, parent reuse, partial integration, and consumed-child reuse revert with unchanged checked post-state, while a valid lifecycle passes consistency checks. Gas evaluation over n∈{1,3,6,9,12,50,100} shows near-linear growth: Split at n=50 uses 12.91 M gas, while n=100 uses 25.75 M and exceeds the current 16.78 M Ethereum transaction cap. Blockchain and ERC-1155 are deployment and representation choices rather than correctness mechanisms. The security claim is limited to on-chain lifecycle consistency; physical-world input authenticity remains external.
Starting a private blockchain testbed takes hours; starting a local Ethereum backend takes one second. Tools such as Anvil, Hardhat Network, Ganache, and the EthereumTesterProvider of web3.py each deliver a fully functional EVM, pre-funded accounts, and a JSON-RPC endpoint instantly, with no containers, genesis configuration, or consensus parameters required. This raises a question that prior work has not answered: does a multi-node private blockchain testbed still justify its engineering cost? Testbed studies benchmark permissioned platforms against one another but, to our knowledge, never against the lightweight backends practitioners reach for first. We close this gap through controlled measurement. We construct a containerised Hyperledger Besu 23.4.1 testbed running QBFT consensus across four validators with integrated observability, then replay an invariant smart-contract workload of identical bytecode, constructor arguments, and accounts across five local backends and the testbed on a shared host. An observational analysis covers 11,397 unique block-height transitions, recovered from 74,427 per-node log observations across two corpora collected eleven months and one processor architecture apart. Local backends returned deployment receipts 341 to 3190 times faster than the consensus-bound testbed, but that speed is purchased by omitting properties a deployment target possesses. A phase-controlled experiment shows why: inclusion latency on the testbed is governed entirely by where a submission falls within the block period (L=5.009−1.012ϕ, R2=0.9998), so the comparison measures scheduling semantics rather than execution speed. No local backend produced a block while idle, exposed peer state, or surfaced transaction-pool or permissioning data. Across four contracts spanning 339 to 7408 bytes of initialisation code, every default-configured backend charged more gas than the testbed by exactly the EIP-3860 initcode surcharge of two gas per 32-byte word, from 22 to 464 gas, so the divergence is systematic and predictable though small in relative terms (<0.04%). Across five independent crash-fault trials, removing one of four validators left 68.6% of blocks unaffected while delaying 31.4% to 15.015±0.057 s, exactly the configured request timeout beyond the normal interval; removing a second halted the chain in every trial, with liveness restored after 83.2±4.0 s. The testbed occupies 3318 MiB and 36% of one host’s CPU against 12–13 MiB and 0.12% for a local backend. The block interval held at means of 5.0018 s and 4.9988 s across both deployments, indicating cross-architecture reproducibility. The two families are complementary: local backends validate contract logic rapidly and cheaply, while a private testbed remains necessary for network-level behaviour, gas fidelity, permissioning, and liveness under validator loss.
