Summary
Synthetic publish tests show a graph-specific ACK quorum failure on RepNet CG15.
The same local node can publish and finalize to the public graph edge-rounds-1778454122, but cannot finalize to the RepNet paranet / CG15:
0x8fb6dcd4B3e07E610958750DbD72Ae4acdce3738/repnet-v2-official
The key difference is identity=1 / nWcpzsge:
- On the public graph,
nWcpzsge provides a valid ACK and completes quorum.
- On RepNet CG15,
nWcpzsge resets/times out, so publish stays at 2/3 ACKs and falls back to self-sign.
Environment
DKG version: 10.0.0-rc.8
Node: Buba
Role: edge
PeerId: 12D3KooWKymSf1Y91A7gPCHFJGXELVn35jxHBERhUCSd6kCMJmUT
Network: 7449c543ff04a550
Relay: connected
Test setup
Public graph:
RepNet paranet / CG15:
0x8fb6dcd4B3e07E610958750DbD72Ae4acdce3738/repnet-v2-official
Publish command shape:
dkg publish <context-graph> \
--subject <synthetic-subject> \
--predicate http://schema.org/name \
--object <synthetic-object> \
--publisher-node-identity-id 0
All subjects/objects were synthetic test data.
Results
Public graph edge-rounds-1778454122:
- confirmed: 4/5
- tentative: 1/5
- query-back: 5/5
RepNet paranet / CG15:
- confirmed: 0/5
- tentative: 5/5
- query-back: 5/5
Public graph ACKs
The confirmed public publishes got these valid ACKs:
identity=4, peer=aijsNrWw, signer=0x75BDF866...
identity=5, peer=Ce8Q82bZ, signer=0xF822793d...
identity=1, peer=nWcpzsge, signer=0xb8625AD8...
Collected 3 ACKs successfully
Confirmed KCs from the public graph batch:
KC 57: tx 0xf2265d84eb59da76c7c697e5263709e8517899e9648c6e64aec8f2793c8aee0f
KC 58: tx 0x4ac3aac74f792ac17eb8b664fc043b05bc441c99468a79458673810347144235
KC 59: tx 0xe732229099c6dfd34c429be69138d1dab37ed863b0b64adb34902d3a4e86533e
KC 60: tx 0xcb12f4622d141f8cabe5b30211e5574a52e83622848f2c0551d61802cd5f3d60
The one public tentative attempt still collected 3 ACKs, then failed later with 0x7000ca77 from a rotated wallet. That appears to be the known payment/allowance path, not an ACK quorum issue.
RepNet CG15 ACKs
All 5 RepNet CG15 attempts only got:
identity=4, peer=aijsNrWw, signer=0x75BDF866...
identity=5, peer=Ce8Q82bZ, signer=0xF822793d...
They never got the third valid ACK from:
identity=1, peer=nWcpzsge
Observed CG15 failure pattern:
storage_ack_insufficient: got 2/3 valid ACKs. Tried 6 core peers.
Self-signing ACK — ACK collection failed/skipped
On-chain tx failed: execution reverted ... data="0xa6bc6322..."
Stored as tentative
Candidate peer failures on CG15:
Gq6hB57M -> stream reset
nWcpzsge -> stream reset / timeout
pb7US1LG -> All multiaddr dials failed
3ogJ2cxH -> All multiaddr dials failed
0xa6bc6322 corresponds to MinSignaturesRequirementNotMet(required=3, received=1) in our previous debugging.
Expected behavior
If identity=1 / nWcpzsge can ACK edge-rounds-1778454122, it should either:
- also ACK
0x8fb6dcd4B3e07E610958750DbD72Ae4acdce3738/repnet-v2-official, or
- return/log a clear reason why it cannot ACK that context graph.
Actual behavior
For CG15, nWcpzsge resets/times out, leaving the publisher with only identities 4 and 5. The publish then falls back to self-sign and fails on-chain quorum.
What to inspect
The useful place to inspect seems to be graph-specific ACK handling for identity=1 / nWcpzsge, especially:
CG15 hosting/subscription state
CG15 visibility/access for identity 1
StorageACK handler access to CG15 data
P2P stream reset cause on nWcpzsge for CG15 payloads
This does not look like a general local-node publish failure, because the same node confirms public graph publishes with identities 1 + 4 + 5.
Summary
Synthetic publish tests show a graph-specific ACK quorum failure on RepNet CG15.
The same local node can publish and finalize to the public graph
edge-rounds-1778454122, but cannot finalize to the RepNet paranet / CG15:The key difference is
identity=1 / nWcpzsge:nWcpzsgeprovides a valid ACK and completes quorum.nWcpzsgeresets/times out, so publish stays at 2/3 ACKs and falls back to self-sign.Environment
Test setup
Public graph:
RepNet paranet / CG15:
Publish command shape:
All subjects/objects were synthetic test data.
Results
Public graph ACKs
The confirmed public publishes got these valid ACKs:
Confirmed KCs from the public graph batch:
The one public tentative attempt still collected 3 ACKs, then failed later with
0x7000ca77from a rotated wallet. That appears to be the known payment/allowance path, not an ACK quorum issue.RepNet CG15 ACKs
All 5 RepNet CG15 attempts only got:
They never got the third valid ACK from:
Observed CG15 failure pattern:
Candidate peer failures on CG15:
0xa6bc6322corresponds toMinSignaturesRequirementNotMet(required=3, received=1)in our previous debugging.Expected behavior
If
identity=1 / nWcpzsgecan ACKedge-rounds-1778454122, it should either:0x8fb6dcd4B3e07E610958750DbD72Ae4acdce3738/repnet-v2-official, orActual behavior
For CG15,
nWcpzsgeresets/times out, leaving the publisher with only identities4and5. The publish then falls back to self-sign and fails on-chain quorum.What to inspect
The useful place to inspect seems to be graph-specific ACK handling for
identity=1 / nWcpzsge, especially:This does not look like a general local-node publish failure, because the same node confirms public graph publishes with identities
1 + 4 + 5.