M-H09: use channel signer for all channel state node sigs

[philanton]

Description

The app-session router constructs two different signing paths. The channel API is initialized with a channel signer, while the app-session API is initialized with the generic signer directly.

channelV1Handler := channel_v1.NewHandler(useChannelV1StoreInTx, memoryStore, actionGateway, nodeChannelSigner, stateAdvancer, statePacker, nodeAddress, cfg.MinChallenge, runtimeMetrics, cfg.MaxSessionKeyIDs)
appSessionV1Handler := app_session_v1.NewHandler(useAppSessionV1StoreInTx, memoryStore, actionGateway, signer, stateAdvancer, statePacker, nodeAddress, runtimeMetrics, cfg.MaxParticipants, cfg.MaxSessionDataLen, cfg.MaxSessionKeyIDs, cfg.MaxRebalanceSignedUpdates)

When an app deposit is processed, the handler verifies that the submitted user channel state uses the channel signature format, then packs that channel state and signs NodeSig with the generic app-session signer before storing it. The same pattern is used when app withdrawals and app closes issue release channel states. The release helper packs a channel state, signs it with the generic signer, and stores it as the node signature for that channel state.
This is inconsistent with the channel approach. Channel signatures are not plain Ethereum signatures. The channel signer wraps the underlying signature with a leading signer-type byte.

func (s *ChannelDefaultSigner) Sign(data []byte) (sign.Signature, error) {
    sig, err := s.Signer.Sign(data)
    if err != nil {
        return sign.Signature{}, err
    }

    return append([]byte{byte(ChannelSignerType_Default)}, sig...), nil
}

That prefix is required because both the off-chain verifier and the ChannelHub contract treat the first byte of the signature as the validator/signer identifier and verify only the remaining bytes. Because the app-session flows write raw signatures into core.State.NodeSig, the first byte of the signature body is misinterpreted as the signer type. The stored value is therefore not a valid channel signature, and it is persisted as if it were.
As a result, app deposits, withdrawals, and closes can store channel states with invalid NodeSig values. Later checkpoint, challenge, or settlement flows will reject those states, making the latest app-produced state unusable.

Summary by CodeRabbit

• Tests

  • Updated test fixtures across multiple test suites to use channel-specific mock signer implementation.

• Refactor

  • Updated handler signer dependency type to channel-specific implementation.
  • Adjusted RPC router configuration to align signer routing with handler requirements.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 07011f92-e75b-4ec5-8d1f-09feeb7a5837

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/clearnode-h-09

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[nksazonov]

LGTM
Still, is it possible to create a (non-integration) test that will verify that a signed state produced by an app session operation is valid to be submitted on-chain?