Overview of Scroll SDK Stack

Stack Technical Overview

The architecture of a Scroll SDK chain is based on Scroll, and the architecture specifics of a Scroll SDK chain will match the base behavior of Scroll’s network. For more information on how Scroll works, please see the Technology section.

The articles in this section will be focus on the various parts a Scroll SDK chain operator will need to deploy and run.

Tooling

Scroll SDK Repo & Charts

Scroll SDK can be found on GitHub. The SDK built is leveraging Kubernetes and is designed to be easy to launch and maintain for anyone familiar with Kubernetes and Helm.

The repo consists of these major components:

Example config files for preparing your network (see Configuration)
Helm charts for deploying the necessary services and contracts (see Services)
A docker image for building the correct configuration files for these services and gathering smart contract addresses before deployment (see Smart Contracts)
An Ansible playbook for setting up a zk prover if not using a third party proof generation service (see Proof Generation)

Scroll SDK CLI

Additionally, the scroll-sdk-cli tool is available to help with common automations and testing tasks. It greatly simplifies the process of creating a new Scroll SDK chain and includes a number of helpful commands for interacting with your chain.

It also supports custom plugins using the oclif framework.

Scroll Proving SDK

The Scroll Proving SDK is a Rust crate for integrating Scroll SDK support into your prover services. The proof generation providers should use this SDK to build their own Helm charts, allowing SDK operators to out-source proof generation.

For an example service built using scroll-proving-sdk, see the cloud.rs example in theScroll Proving SDK repo.

Deployment Process

Scroll SDK has two deployment options: a local devnet and a production deployment.

When deploying a local Devnet, all services are deployed by a single “chart”. Configuration is minimal, and the deployment includes additional services like a hosting a database in the cluster. We assume users are working inside the devnet directory of a scroll-sdk cloned repo.

In production deployments, each service is deployed as an independent chart. This is often more natural for tight control over upgrades and configuration. Production deployments assume that services like a database or monitoring stacks will be provided by the chain operator. Because of the additional modularity and flexibility, additional configuration is needed and some knowledge of Kubernetes is required. We also assume users will create a new repo for storing their production workflow and configuration files.

Devnet

For a full devnet deployment walkthrough, see the Devnet Deployment guide.

PreReqs

To run a local devnet with all services running on a single machine (using minikube), you’ll want the following items installed:

Docker Engine (or Docker Desktop)
kubectl
minikube (for local dev cluster)
Helm

Docker and minikube will need to be running before starting the deployment process.

Deployment

Clone the Scroll SDK repo and navigate to the ./devnet directory.

git clone git@github.com:scroll-tech/scroll-sdk.git && cd scroll-sdk/devnet

Fetch all charts and create configuration files.
```
make bootstrap
```
(Optional) Modify ./scroll-sdk/config.toml with your settings and accounts.

For more information on modifying config.toml, see Customization.
(Optional) Modify ./scroll-sdk/values.yaml to disable any unneeded services.

For more information on which services to set enable:true, see Services.
(Optional) If modifications were made, run make config to update the configuration files.
Launch the Scroll SDK services by running:
```
make install
```
Wait for services to start and contracts to deploy, and you’ve got a new Scroll SDK chain!

Production

For a full production deployment walkthrough, see the guides for Digital Ocean and AWS.

PreReqs

Before getting started, be sure to install the following:

Docker Engine (or Docker Desktop)
kubectl
Helm

For a production environment, you’ll want to have a working Kubernetes cluster and kubectl configured to point to it. We assume users will create a new repo for storing their production workflow. Docker will be used locally in the configuration preparation workflow.

In addition, you’ll want to prepare the following items:

A PostgreSQL-compatible database with an admin user
- Up to 3 for chain services, optionally 1 more for Blockscout
A Kubernetes Monitor Service (i.e. Prometheus)
A Kubernetes Ingress Controller (i.e. Nginx)
A Secret Store for storing sensitive information (i.e. AWS Secrets, Hashicorp Vault) and a way to access it from Kubernetes using External Secrets

More information on choosing and setting up these services for various cloud providers is provided in the Guides section.