Skip to content

Add a Rosetta method spec and import it into the cosmos bundle - #265

Open
BabyScope wants to merge 1 commit into
drpcorg:mainfrom
BabyScope:rosetta-method-spec
Open

BabyScope wants to merge 1 commit into
drpcorg:mainfrom
BabyScope:rosetta-method-spec

Conversation

@BabyScope

Copy link
Copy Markdown

What this adds

Rosetta is a POST-only HTTP API that a cosmos operator runs beside the node — cosmos/rosetta, since the SDK dropped its in-process implementation in v0.50. Its paths are already expressible in the existing spec format (POST#/block, POST#/network/status), but no spec declares them, so nodecore cannot route to a Rosetta sidecar at all.

This PR adds pkg/methods/specs/rosetta.json — a plain spec on the rest-additional connector covering the Data API, the Construction API and /search/transactions — and imports it into the cosmos bundle. It is modelled directly on the existing hyperliquid-rest-additional.json.

   "spec-imports": [
     "cosmos-tendermint",
     "cosmos-rest",
-    "cosmos-grpc"
+    "cosmos-grpc",
+    "rosetta"
   ]

Why rest-additional

Rosetta is a separate service on its own port, not a namespace on the node, which is exactly what rest-additional is described as in data.go: "used for connectors that provide extra REST methods, but they can't be used for chain-specific". It also keeps the change inert for everyone else:

  • an operator opts in per upstream by adding a rest-additional connector pointing at their Rosetta URL;
  • upstreams without one are unaffected, since a method is only dispatchable on a connector the upstream declares;
  • IsAdditionalApiConnectorType excludes it from head and internal-request connector selection, so it can never become an upstream's head connector.

Verification

Run against an Axelar mainnet archive (axelar-dojo-1, earliest_block_height 1), on an upstream with a tendermint connector for the head and a rest-additional connector for Rosetta:

POST /queries/<chain>/network/status
  -> {"current_block_identifier":{"index":34661178,...},
      "genesis_block_identifier":{"index":1,...}}

POST /queries/<chain>/network/list
  -> {"network_identifiers":[{"blockchain":"app","network":"network"}]}

Historical blocks through the same upstream, ~0.11 s per call:

block result
1 ok, 1 tx
100 000 ok, 1 tx
5 000 000 ok, 2 txs
15 000 000 ok, 2 txs
25 000 000 ok, 1 tx
30 000 000 ok, 1 tx
34 000 000 ok, 1 tx

The tendermint methods on that same upstream keep answering unchanged (statusaxelar-dojo-1), and an undeclared path still fails cleanly with the method POST#/... does not exist/is not available.

Note for reviewers

The one-line edit to cosmos.json could not be exercised locally, because NewMethodSpecLoaderWithExtraFs adds specs rather than overriding them and rejects a duplicate name. The runs above used a bundle with the same import pattern and this exact rosetta.json; only the bundle's name differs.

Happy to split the spec out of the cosmos bundle and leave it standalone if you would rather have chains opt in explicitly, or to extend it to other chain families.

Rosetta is a POST-only HTTP API that a cosmos operator runs beside the node
(cosmos/rosetta, since the SDK dropped its in-process implementation in v0.50).
Its paths are already expressible in the existing spec format - "POST#/block",
"POST#/network/status" - but no spec declares them, so nodecore cannot route to
a Rosetta sidecar at all.

This adds pkg/methods/specs/rosetta.json: a plain spec on the rest-additional
connector, covering the Data API, the Construction API and /search/transactions,
modelled on hyperliquid-rest-additional.json. It is imported into the cosmos
bundle so every cosmos chain can carry it.

An operator opts in per upstream by adding a rest-additional connector pointing
at the Rosetta URL; upstreams without one are unaffected, because a method is
only dispatchable on a connector the upstream actually declares. rest-additional
is excluded from head and internal-request connector selection by
IsAdditionalApiConnectorType, so it cannot become an upstream's head connector
either.

Verified against an Axelar archive: /network/status, /network/list and /block
return the node's own Rosetta payloads, while the tendermint methods on the same
upstream keep answering unchanged. Historical blocks 1, 100000, 5000000,
15000000, 25000000, 30000000 and 34000000 all resolve, at about 0.11 s per call.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant