What are Redstone and Pyrope?
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.
Pyrope is the public testnet for Redstone, settling on the Ethereum Sepolia testnet.
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 Pyrope 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:
- The DA Provider posts an input commitment on L1 (onchain).
- 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.
- 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.
- 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.
- 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.
- 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.