Rollux.com

What is Rollux?

Rollux, built by SYS Labs, is a project dedicated to scaling blockchain technology and expanding its ability to coordinate people from across the world to build effective decentralized economies and governance systems. More specifically, Rollux is the EVM-equivalent Layer 2 optimistic rollup that introduces some key scaling technologies and security characteristics to Optimism's OP Stack. Built on Syscoin's holistically modular Layer 1, Rollux inherits the security of Bitcoin’s mining network through merged-mining, combined with decentralized multi-quorum finality. Rollux fully factors Syscoin's efficient data availability (Proof of Data Availability - PoDA) and data fee market rather than relying on EVM calldata or danksharding. Rollux is secure, scalable, and offers very low fees. Additionally, Rollux provides native Layer 2 data availability which makes it ideal for supporting Layer 3 and fractal scaling.

In all, Rollux is a unique and powerful alternative to other rollup-based stacks and blockchain scaling technologies in general.

In this repository, you'll find numerous core components of Rollux, the decentralized software stack maintained by SYS Labs, and much of the upstream OP Stack which is maintained by the Optimism Collective. We encourage you to explore, modify, extend, and test the code as needed. By collaborating on free, open software and shared standards, SYS Labs, Syscoin Foundation and the Optimism Collective aim to prevent siloed software development and rapidly accelerate the development of blockchain ecosystems. Come contribute, build the future, and redefine power, together.

NOTE: It is important to understand that this repository became public relatively recently. As such, some READMEs might be incomplete. We appreciate your patience while we work quickly to expand technical information about Rollux and refactor existing content! Should you have questions about this repo, feel free to chat with the Rollux community at the links below!

Documentation

• If you want to build on top of Rollux Mainnet, refer to the Rollux Developers Docs
• If you want to contribute to Rollux, check out the Protocol Specs
• If you want to build your own OP Stack based blockchain, refer to the OP Stack docs
• If you want to build on top of OP Mainnet, refer to the Optimism Documentation
• If you want to build your own OP Stack based blockchain, refer to the OP Stack Guide

Specification

If you're interested in the technical details of how Optimism works, refer to the Optimism Protocol Specification.

Community

General dev discussion happens most frequently on the Rollux discord in the #🔨│builder-general channel.

Contributing

Read through CONTRIBUTING.md for a general overview of the contributing process for this repository. Use the Developer Quick Start to get your development environment set up to start working on the Rollux Monorepo. Then check out the list of Good First Issues to find something fun to work on! Use the Developer Quick Start to get your development environment set up to start working on the Optimism Monorepo. Then check out the list of Good First Issues to find something fun to work on! Typo fixes are welcome; however, please create a single commit with all of the typo fixes & batch as many fixes together in a PR as possible. Spammy PRs will be closed.

Security Policy and Vulnerability Reporting

If you are reporting any vulnerabilites exclusive to the Rollux codebase, you should follow the common sense "How to" guidelines echoed in Optimism's canonical Security Policy. Bounty hunters are encouraged to check out the Optimism Immunefi bug bounty program. While this does not apply to any Rollux-specific discoveries, the Optimism Immunefi program offers up to $2,000,042 for in-scope critical vulnerabilities in the Optimism codebase. For vulnerabilities in any Rollux or SYS Labs websites, email servers or other non-critical infrastructure, please email SYS Labs at contact@syslabs.com. We appreciate detailed instructions for confirming the vulnerability.

Bedrock-based

Rollux is based upon Optimism Bedrock! You can find detailed specifications for the Bedrock upgrade within the specs folder in this repository.

Directory Structure

~~ Production ~~
├── packages
│   ├── common-ts: Common tools for building apps in TypeScript
│   ├── contracts-bedrock: Rollux Bedrock smart contracts.
│   ├── core-utils: Low-level utilities that make building Rollux easier
│   ├── chain-mon: Chain monitoring services
│   └── sdk: provides a set of tools for interacting with Rollux
├── docs: A collection of documents including audits and post-mortems
├── op-bindings: Go bindings for Bedrock smart contracts.
├── op-batcher: L2-Batch Submitter, submits bundles of batches to L1
├── op-bootnode: Standalone op-node discovery bootnode
├── op-chain-ops: State surgery utilities
├── op-challenger: Dispute game challenge agent
├── op-e2e: End-to-End testing of all bedrock components in Go
├── op-heartbeat: Heartbeat monitor service
├── op-node: rollup consensus-layer client
├── op-preimage: Go bindings for Preimage Oracle
├── op-program: Fault proof program
├── op-proposer: L2-Output Submitter, submits proposals to L1
├── op-service: Common codebase utilities
├── op-wheel: Database utilities
├── ops-bedrock: Bedrock devnet work
├── packages
│   ├── chain-mon: Chain monitoring services
│   ├── common-ts: Common tools for building apps in TypeScript
│   ├── core-utils: Low-level utilities that make building Rollux easier
│   ├── chain-mon: Chain monitoring services
├── indexer: indexes and syncs transactions
├── op-exporter: A prometheus exporter to collect/serve metrics from a Rollux node
│   ├── contracts-ts: ABI and Address constants
│   ├── contracts-bedrock: Bedrock smart contracts
│   ├── core-utils: Low-level utilities that make building Optimism easier
│   └── sdk: provides a set of tools for interacting with Rollux
├── proxyd: Configurable RPC request router and proxy

Branching Model

Active Branches

Branch	Status
master	Accepts PRs from develop when intending to deploy to production.
develop	Accepts PRs that are compatible with master OR from release/X.X.X branches.
release/X.X.X	Accepts PRs for all changes, particularly those not backwards compatible with develop and master.

Overview

This repository generally follows this Git branching model. Please read the linked post if you're planning to make frequent PRs into this repository.

Production branch

The production branch is master. The master branch contains the code for latest "stable" releases. Updates from master always come from the develop branch.

Development branch

The primary development branch is develop. develop contains the most up-to-date software that remains backwards compatible with the latest testnet network deployments. If you're making a backwards compatible change, please direct your pull request towards develop.

Changes to contracts within packages/contracts-bedrock/src are usually NOT considered backwards compatible and SHOULD be made against a release candidate branch. Some exceptions to this rule exist for cases in which we absolutely must deploy some new contract after a release candidate branch has already been fully deployed. If you're changing or adding a contract and you're unsure about which branch to make a PR into, default to using the latest release candidate branch. See below for info about release candidate branches.

Release candidate branches

Branches marked release/X.X.X are release candidate branches. Changes that are not backwards compatible and all changes to contracts within packages/contracts-bedrock/src MUST be directed towards a release candidate branch. Release candidates are merged into develop and then into master once they've been fully deployed. We may sometimes have more than one active release/X.X.X branch if we're in the middle of a deployment. See table in the Active Branches section above to find the right branch to target.

Releases

Changesets

We use changesets to mark packages for new releases. When merging commits to the develop branch you MUST include a changeset file if your change would require that a new version of a package be released.

To add a changeset, run the command pnpm changeset in the root of this monorepo. You will be presented with a small prompt to select the packages to be released, the scope of the release (major, minor, or patch), and the reason for the release. Comments within changeset files will be automatically included in the changelog of the package.

Triggering Releases

Releases can be triggered using the following process:

1. Create a PR that merges the develop branch into the master branch.
2. Wait for the auto-generated Version Packages PR to be opened (may take several minutes).
3. Change the base branch of the auto-generated Version Packages PR from master to develop and merge into develop.
4. Create a second PR to merge the develop branch into the master branch.

After merging the second PR into the master branch, packages will be automatically released to their respective locations according to the set of changeset files in the develop branch at the start of the process. Please carry this process out exactly as listed to avoid develop and master falling out of sync.

NOTE: PRs containing changeset files merged into develop during the release process can cause issues with changesets that can require manual intervention to fix. It's strongly recommended to avoid merging PRs into develop during an active release.

License

All other files within this repository are licensed under the MIT License unless stated otherwise.