igneum-network/igneum
1
0
Fork 0
Code Issues Pull requests Releases Activity

release 0.3.22 section 10: the chain id row as the node lane corrected it (the id as a function of the block's DAA at the v5 floor; the replay window to the floor's crossing; the uniqueness table)

Browse source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
igneum-labs 2026-10-07 20:03:29 +00:00
parent 3438c3f1e2
commit 81060708c5
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/plans/release-0.3.22.md
View file

@ -107,7 +107,7 @@ Three commits on 96161037: bd710a36 the sub-version 3 re-pin (byte 7, igneum-pow
## 10. The chain id finding, the proven share, the pool hour (20:5x to 21:0x BST)
**Chain id, a fact for the record (main's ruling 21:0x BST):** eth_chainId answers 0x116f (4463) on both the live shared devnet and Devnet 3 (the fleet's read at 20:59 BST while closing the steward's MINER_KEY item), so from Devnet 3's first block at 18:06 BST until the 0.3.24 sweep a signed transaction replays across the two chains by the chain id alone (the networks refuse each other at p2p; a raw transaction carried by hand to the other chain's RPC is accepted). Nothing of value sits on either chain. Devnet 3 takes its own chain id, 4464, in the 0.3.24 object (the v5 object moves the digest anyway), every Devnet 3 node and app in the same sweep, existing transactions judged by the chain id they carry at acceptance. Rule from tonight, a gate check: every network object names a chain id no other object carries (the shared devnet 4463, Devnet 3 4464, the testnet 4462, mainnet its own), a test over every Params table, known-failed first on tonight's duplicate.
**Chain id, a fact for the record (main's ruling 21:0x BST, corrected by the node lane 21:1x):** eth_chainId answers 0x116f (4463) on both the live shared devnet and Devnet 3 (the fleet's read at 20:59 BST while closing the steward's MINER_KEY item), so from Devnet 3's first block at 18:06 BST until the class v5 floor's crossing (the 0.3.24 object, about 01:00 BST on 8 October at the estimate) a signed transaction replays across the two chains by the chain id alone (the networks refuse each other at p2p; a raw transaction carried by hand to the other chain's RPC is accepted). Nothing of value sits on either chain. The first form ("existing transactions judged by the id they carried at acceptance, new ones at 4464") does not hold: body validation checks every EVM transaction of every block against one fixed id and the executor runs each recorded transaction under one env id, on history as on new blocks, so a 0.3.24 node at a flat 4464 would refuse every past Devnet 3 block carrying a 4463 transaction and re-execution would move the state root. The form that lands in the v5 object commit: on a suffixed devnet the chain id is a function of the block's DAA score, 4463 below program_class_v5_activation_daa and 4464 from the floor on, for validation, execution and CHAINID; the mempool and templates take the id valid at the tip (so until the floor a new transaction still carries 4463), eth_chainId answers the executed tip's; one digest move at the crossing the v5 object already makes. Rule from tonight, a gate check: every network object names a chain id no other object carries (mainnet 4461, the testnet 4462, the shared devnet 4463, Devnet 3 4464, a suffix N devnet 4461 + N; the simnet keeps 4463 as the devnet's tooling twin), a test over every Params table, known-failed first on tonight's duplicate.
**The steward's two items before the public repository opens, both closed:** tools/exec-attacks/lib/common.mjs MINER_KEY is the public Anvil/Hardhat default account 1 key (five harnesses use it; balance 0 and nonce 0 on both chains at 20:55 and 20:59 BST; the fix is a chain-id guard in the five harnesses and a README line, a 0.3.24 steward row); app/igneum-wallet/src/hd.rs's KEY in one history commit is the public Hardhat default account 0 key in a removed test.