TwitterDiscordGitHub logo

What is Redstone?

Redstone is an Optimistic Rollup building on the OP Stack codebase. In practical terms, this means it is an Ethereum blockchain that inherits most security guarantees from L1 (Ethereum mainnet), but has much cheaper transactions. This is important because L1 transactions are typically too expensive for many use cases, such as games.

Why is Redstone cheaper?

The main difference between Redstone and other OP Stack rollups is data availability. Instead of using L1 Ethereum for data availability (to post transactions), Redstone and Garnet use Plasma mode. This means that they only post input commitments (the hash of the transaction data) to L1, while making that data available offchain.

This architectural difference has two big effects:

  • Redstone transactions are considerably cheaper.
  • Because Redstone uses an alternative DA Provider, it does not inherit L1 Ethereum's data availability guarantee. Note that because of the input commitments, it does inherit L1 Ethereum's data integrity guarantee. DA Providers can refuse to provide information, but cannot provide incorrect information without being detected (because its hash won't match the input commitment).

How do we guarantee data availability?

Because we don't inherit the availability guarantee of L1 Ethereum, we need a separate mechanism to guarantee that data is available when needed. This mechanism is Data Availability Challenges (DA Challenges).

The process is this:

  1. The DA Provider posts an input commitment on L1 (onchain).
  2. Any node that wants to know the input data (typically, to be able to calculate the state of the rollup after the block is processed) can ask the DA Provider for the data offchain.
  3. Any node that wants the data and doesn't get it from the DA Provider can challenge the input commitment. The DA Provider, or any other entity, can post the input on L1 (onchain). If nobody posts input that hashes to the input commitment, that commitment is discarded.
  4. After the DA challenge period has passed, the proposer (which may be the same entity as the DA Provider) posts an output proposal on L1.
  5. Nodes can use the input data (which they got either offchain or onchain) and the previous state to verify if the output proposal is correct or not.
  6. If the output proposal is incorrect, the nodes can challenge it using the fault-proof mechanism (in development). If the output proposal is based on input that is to be ignored (because of a failed input challenge), it is not valid.

Paying for DA challenges

In theory, a node could challenge every input commitment, and turn a Redstone rollup into a standard OP Rollup with the attendant costs. To avoid that, when a node submits a DA challenge it has to post a bond with an amount equivalent to the cost of resolving the challenge (based on the amount of data that would have to be posted to L1).

If the challenge is not resolved successfully, that bond is returned to the challenger. If the challenge is resolved successfully, the bond is burned.

Note that the bond is burned, rather than given to the DA Provider, because if it were given to the DA Provider it would create a perverse incentive to not make data available offchain, to get such bonds.

Using the DA explorer

The data availability explorer is available.

Challenging an input commitment

To challenge an input commitment:

  1. Click Challenge in the appropriate line.
  2. A window opens up with the block whose input is being challenged, the challenge window, and the required bond to ensure you're not spamming challenges. If your wallet is not yet connected, when you hover over CHALLENGE it gives you an option to CONNECT WALLET instead. Connect your wallet.
  3. Click CHALLENGE and approve the transaction in your wallet.
  4. Currently the DA Provider automatically resolves all challenges.

Responding to a DA challenge

If a DA challenge is still pending, you can resolve it. On a production network that may be in your interest if you have a sufficiently valuable transaction as part of the input and the DA Provider does not resolve it for some reason.

Note: Anybody is allowed to resolve DA challenges because a DA Provider can refuse to resolve a challenge in the hope of causing a chain reorg into a more advantageous state.

  1. Click the transaction.


  3. Enter a URL that contains the relevant information (this is automatically provided for you) and click RESOLVE CHALLENGE again.

    You can also get the transaction data for an input commitment directly by clicking the arrow button and then DATA, or using<input commitment>.

  4. Approve the transaction in the wallet.