Coinbase Mesh API Adapter

Created a lightweight Node.js server that implements the Coinbase Mesh API on top of the native REST APIs of two blockchains. Both blockchain implementations share a common server shell while keeping blockchain-specific translation logic separate. At startup, configuration determines which blockchain implementation the server activates.

Context

Our client wanted to satisfy the technical requirements for an exchange listing on Coinbase. This included providing an implementation of Coinbase's Mesh API for each of their two blockchains.

In 2020, Coinbase introduced Rosetta, which was subsequently renamed to Mesh. Coinbase claimed its motivation for introducing this specification was to make it easier to build blockchain-agnostic applications - like block explorers and network monitors. In practice, Mesh also shifts much of the work traditionally done by Coinbase's engineering team when adding support for a new blockchain to the blockchain teams requesting integration.

Mesh standardizes the API contract, but it cannot completely abstract away the semantics of the underlying blockchain, especially those with less common functionality. One limitation of the Mesh API is that it expects the deconstruction of blocks and transactions into operations, but does not define a set of known operations that must be supported upstream, even for something as fundamental as an account balance change. At a minimum, integrating any new blockchain requires the Mesh API caller (e.g., Coinbase) to manually add support for the custom set of operations a blockchain defines. As a consequence, while the integration costs are substantially reduced, they are not zero. This is especially true if a blockchain exposes custom functionality that few, if any, others do.

Mesh was primarily designed to support blockchains like Bitcoin and Ethereum. Our client's blockchains did not perfectly mimic either. They used an account-based model, like Ethereum, but supported only a deterministic, fixed set of transactions instead of allowing arbitrary code execution in a VM.

Engineering Approach

After a careful review of the Mesh API and the REST APIs of our client's blockchains, we discussed our findings with them and clarified the implementation priorities. The client's existing REST APIs already met their needs, and they didn't need the ability to create the full breadth of their transactions through the Mesh API. Rather than implementing transaction construction for every operation supported by the native blockchains, we focused on implementing the capabilities required for the Coinbase integration.

These included:

• Track native and custom-token balance changes while allowing Mesh to initiate native-currency transfers.
• Track multisignature account and cosignatory changes while allowing Mesh to initiate those changes.

Lightweight Adapter Server

We created a lightweight Node.js server that exposes the Mesh Data and Construction APIs. The common server handles transport, configuration, logging, and error handling in a blockchain-agnostic way. At startup, the server reads a configuration file that determines which blockchain-specific Mesh implementation to activate.

Native API Proxy

We created a thin proxy around each blockchain's native REST API. The proxy centralized request and error handling and provided caching for frequently requested data. Many of the simpler Mesh APIs could be implemented by making one or more calls through this proxy and mapping the responses to the corresponding Mesh API objects.

Operation Processing

The trickiest part of the integration was deconstructing blocks and transactions into operations. Processing all of these operations must reproduce the same account balances as processing the underlying blocks and transactions according to the native blockchain protocol. The resulting balance for every account must match exactly. While certain transactions that change account balances - like sending funds - are directly observable in the blockchain, others are not. For example, the creation of a custom token involves paying a fee to a predefined account, in accordance with the rules of the protocol, but that balance change is not directly encoded in the transaction. As a result, we needed to review every transaction type and identify all potential direct and indirect balance changes. Each balance change then needed to be represented as a corresponding credit or debit operation to an account. Similarly, we needed to extract operations representing the creation and modification of multisignature accounts as well as the cosignatures of those.

Alongside this deconstruction, we also added support for the Mesh Construction API, which performs the reverse transformation. Given one or more operations, it will build a transaction, sign it with optional multisig support, and submit it to the native blockchain network. For transaction construction, signing, and submission, we reused the Multi-Blockchain SDK developed in an earlier engagement rather than duplicating blockchain-specific transaction logic in the adapter.

Results

Shared Adapter Server Shell

We delivered a single Node.js server that can expose the implemented Mesh API for either blockchain. A common server shell allows our client to deploy and operate both implementations consistently.

Coinbase Integration Capabilities

We implemented the Mesh Data and Construction capabilities required for the client's Coinbase listing effort. Callers can track native and custom-token balance changes, send native currency across accounts, and create and manage multisignature accounts without having to learn our client's custom SDKs or REST APIs. Implementations for both of our client's blockchains passed all standard Mesh Construction API tests included in Coinbase's Mesh CLI.

Verified Data Fidelity

Processing the full blockchain history through the Mesh Data API produced account balances that reconciled exactly with those returned by the native APIs. Implementations for both of our client's blockchains passed all standard Mesh Data API tests included in Coinbase's Mesh CLI.