nwo: bootstrap a fabricx+EVM backend for token integration tests

[arunabha003]

Problem

The EVM network driver under development (feature/evm-network-driver) has no way to be exercised inside NWO. NWO today can only bootstrap Fabric and FabricX backends — there is no machinery to stand up an EVM-speaking node, deploy the token contracts onto it, and wire FSC nodes to talk to it. Nothing in integration/ currently knows how to launch an external JSON-RPC node, deploy Solidity contracts, or emit an EVM network config block.

The token integration suites should be able to bootstrap a fabricx + EVM gateway backend by switching topology, so the existing fungible test bodies run against it exactly like dlog vs dlogx today. The platform should be buildable and testable in isolation, without waiting on the driver's end-to-end methods.

Solution

Add a standalone NWO platform + token backend for the fabricx+EVM gateway, mirroring integration/nwo/token/fabricx/, and make it testable in isolation.

1. Token-layer backend — new package integration/nwo/token/evm/ implementing the token Backend interface (integration/nwo/token/fabric/fabric.go): PrepareNamespace(tms) registers the token namespace; UpdatePublicParams(tms, ppRaw) seeds public parameters on-chain (EVM analog of the FabricX TMSDeploy path). Register it as a NetworkHandler under a new platform name in integration/nwo/token/factory.go, reusing the backend-agnostic crypto/PP generation.
2. FSC-level EVM platform/topology — boot the fabric-x-evm gateway node, reusing the FSC container-lifecycle pattern (nwo/fabricx/extensions/scv2: port allocation, container create/start, log stream, readiness wait, cleanup). Expose an evm.Topology implementing api.Topology + BackedTopology.
3. Contract deployment — deploy EndorsementVerifier + a per-TMS TokenState clone, seeding PP v0 + endorser set + threshold + graphHiding, and inject the resulting addresses back into node config via the existing TMS.BackendParams seam. (Deploy mechanism — forge vs a JSON-RPC/view path — to confirm; leaning forge.)
4. EVM config + identity generation — emit the token.tms..services.network.evm.* block per node (endpoint, chainID, contract addresses, finality/gas, submitter/endorser keystores), including the endorser Ethereum-address ↔ FSC view.Identity registry + threshold + allowlist the driver expects (design §6.1/§10). New secp256k1 crypto-material path alongside the x509/idemix generators.
5. Topology switch — add a case in integration/token/fungible/topology/topology.go so common.Opts.Backend selects the EVM topology, keeping the token→FSC binding via AddTMS(...). Integration suites then flip the backend, dlog/dlogx-style.
6. evmdlog composed SDK — wire evm.NewDriver + token driver over viewsdk in the integration module (integration/token/common/sdk/evmdlog/, mirroring fxdlog), with the require+replace for the isolated EVM Go module.
7. Isolation test + Makefile target — a test that boots the node, deploys the contracts, and asserts reachability + a basic contract query, independent of the driver's end-to-end flow. Add integration-tests-evm.

Checklist:

• evm topology skeleton (integration/nwo/token/evm/ + evm.Topology)
• node bootstrap (gateway container + reachability)
• contract deployment (verifier + TokenState clone; seed PP/endorsers/threshold/graphHiding)
• EVM config + secp256k1 identity/registry generation
• token Backend + NetworkHandler registration
• topology switch + evmdlog SDK
• isolation test + integration-tests-evm target

[arunabha003]

@adecaro hi i've written up the approach here. Could you assign it to me, and let me know if you're aligned with the direction (esp. the deploy mechanism note in point 3)? Thanks!

[adecaro]

Hi @arunabha003 , thanks for pushing this. It sounds good to me modulo details that we will figure out during developing.

Please, @atharrva01 , have your assessment as well.

[atharrva01]

looks good to me @arunabha003 , direction is right and it lines up with how i was planning week 6, mirroring nwo/token/fabricx + the topology switch so the fungible bodies run on either backend, dlog/dlogx style.

one thing on the split so we don't build the same thing twice, a chunk of your points are backend-agnostic, not fabricx+evm specific:

• Integrate https://github.com/IBM/mathlib #1 the nwo/token/evm Backend, nwo token platform: customisation #4 #5 the topology switch, and additional documentation #3 #6 the evmdlog composed SDK are shared. i'll push a thin nwo/token/evm skeleton (the Backend interface + topology stub, no impl) first so you have a fixed contract to build against. then Besu is my impl of that interface and fabricx+evm is yours, same suite runs on both.
• the genuinely fabricx+evm specific part is Documentation for the Integration Tests #2, booting the gateway node (the scv2 container lifecycle). that's cleanly yours.
• Documentation #3 and nwo token platform: customization #4 are mostly shared too, the only backend specific bit is the endpoint, so let's keep one deploy path + one config emitter and just parametrize the node rather than fork them.

on #3 deploy mechanism (@adecaro's flag): forge is right imo, that's what i had. one gotcha to bake in though, the clone -> initialize is two steps and there's a front-running window on the clone (nothing binds initialize to the deployer, so someone could initialize the clone first). so either clone+initialize in one tx via a tiny factory contract, or the deploy script reads back and asserts the post-initialize state (verifier addr, PP hash, graphHiding) before it records the clone address. it's in my design (§3.8) / week 6 plan already, worth doing it once in the shared deploy path.

on #4 config: the evm config block + the endorser address <-> fsc identity registry + threshold + allowlist are exactly design §10, and i already landed that registry in the week 4 PR (#1988). so let's have the config emitter produce that same schema so it matches what the driver actually reads, i can point you at the exact struct.

driver side you won't need anything special from me, it's plain eth json-rpc so the gateway is just another endpoint. the isPending/superseded lifecycle is a finality optimization layered on top, not a dependency, so you're not blocked on it.

i'll ping you once the skeleton's up.

[arunabha003]

@atharrva01 got it thanks. I'll start on the gateway node bootstrap now since that's independent, and build the rest against your skeleton once it's up.

[adecaro]

thanks for effort @arunabha003 🙏

[atharrva01]

Thanks for the effort here man! @arunabha003

[atharrva01]

@arunabha003 skeleton's up, #1992 (the nwo/token/evm Backend + topology marker). you can build the fabricx+evm backend against that contract now. it satisfies fabric.Backend (PrepareNamespace / UpdatePublicParams) + a BackedTopology marker, no impl behind it so the shape is yours to fill. ping me if the interface needs anything.

also heads up on the base branch, target feature/evm-network-driver, not main. all the evm driver work lives on that branch until the whole thing's done, then it merges to main as one piece. #1992 is already based there, so branch off that and PR into it.

[arunabha003]

got it , thanks !

[arunabha003]

@atharrva01 could we get the skeleton merged into feature/evm-network-driver if possible? That unblocks the Backend + topology switch on my side. Thanks!

[atharrva01]

Cc @adecaro