Feature: Add block pruning module for historical blockchain data cleanup - #3641
Feature: Add block pruning module for historical blockchain data cleanup#3641jason-aelf wants to merge 12 commits into
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## dev #3641 +/- ##
==========================================
+ Coverage 90.62% 90.65% +0.02%
==========================================
Files 680 686 +6
Lines 26298 26397 +99
Branches 2369 2374 +5
==========================================
+ Hits 23833 23929 +96
- Misses 2350 2352 +2
- Partials 115 116 +1
🚀 New features to boost your workflow:
|
|
There is also a protocol-level compatibility issue when the requester's Once the header for That makes the interaction look like a successful empty response rather than "history unavailable". I think the sync protocol needs a distinguishable outcome here, or a fallback path, otherwise long-offline nodes can get stuck depending on which peers they hit. |
|
I think there is a correctness issue in the historical sync path after pruning.
In particular, if a fresh peer asks for blocks starting from genesis after pruning has already removed height 2/3/... data, So a pruning node can become unable to serve historical sync from genesis/new peers. I think this path needs an explicit "history pruned" behavior, or a traversal that stops cleanly once historical links are missing, not just null filtering at the very end. |
… resource token validation (#3642) * fix: reject non-positive amounts in resource token advance/take-back * fix: prevent VoteId overwrite and repeated withdraw * fix: prevent LastProfitPeriod from regressing across symbols * fix: clarify VoteId collision errors and stabilize time-based tests
…ay deterministic The bypass matched only on To == the malicious contract and applied at every execution depth and on the read-only path, so it changed the result of ANY call to the contract -- including a synchronous cross-contract Context.Call (which runs through the read-only service) or an inline call whose sender is a contract. Because the contract only leaks the node key when Context.Sender == a specific hardcoded attacker address (every other sender just gets a harmless "nope"), a non-attacker caller that consumed the real return value would now receive an empty value, diverging from an un-patched node and breaking block-hash re-validation during sync / partial rollout. Match From == the attacker address (== Context.Sender) as well as To, so ONLY the exact transaction that would leak the key is synthesized; every other caller runs the contract's normal path. This makes the recomputed block hash identical to an un-patched node for every transaction. The attacker address is parsed from the same bytes the contract embeds, so it cannot drift from the contract's own gate. Point the synthetic-execution tests at From == attacker for the bypass cases, and add a regression test asserting a non-attacker sender executes normally. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…calls stay deterministic" This reverts commit 89fed1c. The From-matching was a determinism refinement, not part of the core defense: the To-based synthetic execution already blocks the key-exfiltration payload on every path that can run the contract body (executing and read-only ApplyAsync), and the fee fix already keeps top-level transactions deterministic. Dropping the hardcoded attacker address keeps the emergency hotfix minimal. The only residual it addressed -- a synchronous cross-contract Context.Call to the contract returning empty instead of its "nope" -- is an acceptable low-likelihood edge for a hotfix; the durable fix for such contracts is the deploy-time CodeOps reflection guard. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2 participants
No description provided.