Gateways
Validators communicate with the Marlin relay network using gateways.
Documentation to run gateways for specific networks are available below:
📄️ Ethereum Gateway
The Ethereum gateway acts as a bridge between your Ethereum node and the Marlin relay network
📄️ Polygon PoS Gateway
The Polygon gateway acts as a bridge between your Polygon node and the Marlin relay network
📄️ Polkadot Gateway
The Polkadot gateway acts as a bridge between your Polkadot node and the Marlin relay network
📄️ Near Gateway
The Near gateway acts as a bridge between your Near node and the Marlin relay network
📄️ Cosmos Gateway
The Cosmos gateway acts as a bridge between your Cosmos node and the Marlin relay network
📄️ Iris Gateway
The Iris gateway acts as a bridge between your Iris node and the Marlin relay network
Documentation for running relays are available here:
📄️ Run a node
Node operators are the backbone of the Marlin network
Discussion
What exactly is a Gateway?
Gateways are basically a stripped down version of the blockchain node (called a shadow node) which implement only the p2p networking parts. Most notably, there's no discovery, sync, storage or consensus, so the gateway is extremely lean.
On one side, since the gateway implements the p2p networking stack, you can add the gateway as a peer to your blockchain node and it will automatically communicate with it (no invasive code changes). On the other side, it automatically discovers and maintains connections with Marlin relay nodes and is able to send and receive data from it.
Why is a bridge sometimes needed?
The two sides of the gateway are occasionally incompatible with each other. This might be due to a variety of reasons including different event loops, incompatible languages/libraries, etc. Hence, the two sides are split into two parts which communicate between each other through the network instead.
Does it affect the safety/stability of my node?
Not more than connecting to any other peer. The shadow node approach is designed to affect the real blockchain node as little as possible:
- there are no codebase changes
- the blockchain node still verifies all messages and runs its consensus engine as always
- communication is strictly through its own p2p networking stack
- the blockchain node doesn't interact with the Marlin network directly (in fact, it doesn't even know that Marlin exists)
- the gateway can be run in a different VM separate from the node to further isolate it
Hence, the "attack surface" is pretty much the same as another peer that your node connects to.
My node doesn't connect to other (random) peers though.
The blockchain node still needs to get the data from some other node in your control. E.g. some chains secure their validator nodes by running them behind sentry nodes which insulate the validator against rogue peers. You can simply choose to run the gateway beside the sentry node instead of the validator.