Running a Node

There are four different types of nodes on the Plume testnet. Plume's node architecture is based on Arbitrum's node architecture, which means there are no incentives to running a full node. If you don't want to run your own node, you can connect to the Plume testnet by using the RPC endpoints in Network Parameters.

Currently, the Plume team maintains all the testnet infrastructure, so we are not looking for operators to run any testnet nodes. If you would still like to run a node yourself for free and without any promise of future fees, rewards, or potential airdrops, please follow the instructions in the Plume node config GitHub repo, and email [e-mail] if you'd like to be added to our list of public nodes.

Plume Sequencer

The Plume sequencer is a single full node that orders transactions on the Plume testnet. This forces all other full nodes to recognize the exact same transaction sequence, which allows them to deterministically compute the next state of the chain.

The sequencer can potentially be malicious and extract value by front-running transactions. However, the sequencer is unable to censor any transactions, which will all eventually get posted through the delayed inbox. Currently, the Plume sequencer is operated by the Plume team, but we made Plume a modular blockchain so we can integrate with decentralized sequencer providers like Espresso Systems in the future.

Plume Full Nodes

Plume full nodes work in the same way as Arbitrum full nodes. They read state with a direct connection to the underlying L1 chain—for the Plume testnet, that's Ethereum Sepolia—and retrieve the sequence of L2 transactions either directly from the sequencer, or through a feed relay. Then, each full node runs the deterministic state transition function locally to compute the next state based on the transaction sequence.

Because the state transition function is completely deterministic and the transaction sequence is generated by a single sequencer, there is no consensus mechanism on the Plume testnet and every honest full node is guaranteed to always have the same state. This is one benefit of building an L2 chain that leverages the security and consensus mechanism of the underlying L1 chain.

Running your own Plume node allows you to participate in this process independently. You would always be certain about the actual state of the chain even if other nodes are dishonest, and you wouldn't ever need to rely on any third-party operators or services.

Plume Archive Nodes

Plume archive nodes are full nodes that store the complete historical state of the entire network, not just the most recent transactions. They consume significantly more storage (8+ terabytes vs. 0.5 terabytes for a standard full node) and require much larger computational capacity and network bandwidth.

We advise users and developers that need to analyze historical blockchain data to set up and run their own Plume archive node. The Plume team does not currently operate any archive nodes.

Plume Validator Nodes

Plume validators are full nodes that participate in the rollup protocol, a completely separate chain that confirms the results of L2 transactions on the L1 chain. The rollup protocol is designed in a way so that even a single honest validator can ensure that the correct state of the chain is confirmed, even if all other validators are dishonest. See "Arbitrum Rollup Protocol" in the official Arbitrum documentation for more details.

There are three main types of validator nodes on the rollup protocol:

• Active validator nodes propose new blocks in the rollup protocol, must be staked, and get slashed if their proposed blocks are proven to not match the correct state.

• Watchtower validator nodes are not staked and do not propose new blocks, but they alert other parties, such as defensive validator node operators, if any active validators propose an incorrect block.

• Defensive validator nodes are not usually staked, but will stake to propose the correct block and generate a fraud proof if any active validators propose an incorrect block.

The combination of watchtower validators and defensive validators forces active validators to stay honest, at the risk of losing their stake. This means that the rollup protocol only needs a single honest active validator, which is currently operated by the Plume team.