review technical-stack docs, pt 2

dghelm · dghelm · commit 8205d6a72a58 · 2024-10-29T12:36:10.000-05:00
diff --git a/src/content/docs/en/sdk/technical-stack/contracts.mdx b/src/content/docs/en/sdk/technical-stack/contracts.mdx
@@ -13,7 +13,7 @@ import Aside from "../../../../../components/Aside.astro"
 
 ## Overview
 
-Contracts deployed for a Scroll SDK chain include both contracts on the L1 (or basechain), and contracts deployed on the L2. Additionally, the L2 has "pre-deployed" contracts, matching those on [Scroll](/en/developers/scroll-contracts#l2-predeploys).
+Contracts deployed for a Scroll SDK chain include both contracts on the L1 (or basechain), and contracts deployed on the L2 (or SDK chain). Additionally, the L2 has "pre-deployed" contracts, matching those on [Scroll](/en/developers/scroll-contracts#l2-predeploys).
 
 ## Primary Contracts
 
@@ -49,30 +49,23 @@ Although there are many contracts deployed during a new chain deployment, the mo
 
 ## Deployment Process
 
-All contracts are available in the [scroll-contracts repo](https://github.com/scroll-tech/scroll-contracts), and [Docker files](https://github.com/scroll-tech/scroll-contracts/tree/feat-deterministic-deployment/docker) and [Foundry scripts](https://github.com/scroll-tech/scroll-contracts/tree/feat-deterministic-deployment/scripts/deterministic) used for deployment available in the `feat-deterministic-deployment` branch.
-
-Contracts are deployed using deterministic addresses, with a salt used to generate the address of the contract. For every new deployment, a unique salt should be configured in `config.toml`.
-
-During deployment, a simulation is first done to determine what address a contract will deploy to. This step is done during the creation the config files for each service's chart and when the `genesis.json` file is created. Contract addresses are then used to set each service's configuration (see [`gen-configs.sh`](https://github.com/scroll-tech/scroll-contracts/blob/feat-robust-deployment/docker/scripts/gen-configs.sh)).
+Contracts are deployed by the `contracts` chart. Deterministic addresses are used, with a salt used to generate the address of the contract. For every new deployment, a unique salt should be configured in `config.toml`.
 
-{/* <!-- TODO: modify URL to develop branch --> */}
+During the configuration generation step, a simulation is first done to determine what address a contract will deploy to. This step is done during the creation of the config files for each service's chart and when the `genesis.json` file is created. Contract addresses are then used to set each service's configuration (see [`gen-configs.sh`](https://github.com/scroll-tech/scroll-contracts/blob/feat-robust-deployment/docker/scripts/gen-configs.sh)).
 
 Then, before the `contracts` chart is installed, you will need to fund your SDK `DEPLOYER` account to deploy all contracts on L1 and L2 using actual transactions.
 
-The `contracts` pod will connect to the cluster's RPCs and deploy the necessary contracts. 
+The `contracts` pod will connect to the L2 RPC and deploy the necessary contracts from the `DEPLOYER` account.
 
-{/* TODO: is this still true? */}
-{/* To view the complete logs from the deployment process, see the `broadcast` folder in `/charts/scroll-stack/`. */}
-
-{/* TODO: check again once we do this. */}
 <Aside type="tip">
+All contracts are available in the [scroll-contracts repo](https://github.com/scroll-tech/scroll-contracts), and [Docker files](https://github.com/scroll-tech/scroll-contracts/tree/feat-deterministic-deployment/docker) and [Foundry scripts](https://github.com/scroll-tech/scroll-contracts/tree/feat-deterministic-deployment/scripts/deterministic) used for deployment available in the `feat-deterministic-deployment` branch.
+
 For manually deploying contracts without the reliance on a docker container, please review [this guide](https://github.com/scroll-tech/scroll-contracts/blob/feat-deterministic-deployment/docs/manual-deployment.md).
-{/* TODO: Link to develop branch once merged. */}
 </Aside>
 
 ### Funding Deployment Accounts
 
-You will need to manually fund the following wallet addresses from `config.toml`:
+In production deployments, you will need to manually fund the following wallet addresses from `config.toml`:
 
 - `DEPLOYER_ADDR` *(only needs funded on L1)*
   {/* - Suggested funds: `(L1 basefee * VARIABLE * 10e-9) ETH` */}
@@ -85,11 +78,11 @@ You will need to manually fund the following wallet addresses from `config.toml`
 - `L2_GAS_ORACLE_SENDER_ADDR` *(funded after L2 chain deployment)*
   {/* - Suggested funds: `(L1 basefee * VARIABLE * 10e-9) ETH` */}
 
-{/* <!-- TODO: modify for how this works after --> */}
+{/* TODO: Consider recommending an initial funding amount. */}
 
-<Aside type="tip">
+<Aside type="tip" title="Funding L1 Devnet Accounts">
 
-To fund an L1 addresses when using Anvil, you can run the command below, replacing the first param with the address.
+To fund an L1 addresses when using Anvil in a devnet, run `scrollsdk helper fund-accounts --dev`. Or, to manually set individual account balances, you can also run the command below, replacing the first param with the address.
 
 ```bash
 curl --location 'http://l1-devnet.scrollsdk/' \
@@ -101,16 +94,19 @@ curl --location 'http://l1-devnet.scrollsdk/' \
   "id":0
 }'
 ```
+
 </Aside>
 
-<Aside type="tip">
+<Aside type="tip" title="Funding L2 Addresses">
 
 To fund an L2 address directly via the L1 bridge, you can run the command below, replacing the RPC and setting a private key of an account funded on L1 and a recipient address on L2.
 
 ```bash
 cast send --rpc-url https://rpc2.sepolia.org  --private-key "$PRIVATE_KEY" "$L1_GATEWAY_ROUTER_PROXY_ADDR" "depositETH(address,uint256,uint256)" "$L2_RECIPENT_ADDR" "1ether" "300000" --value "1.1ether"
 ```
 
+You can also use the interactive `scrollsdk helper fund-accounts --layer=2 [--private-key=<private-key>]` command to fund an L2 address, optionally passing a private key as funder.
+
 </Aside>
 
 
diff --git a/src/content/docs/en/sdk/technical-stack/proof-generation.mdx b/src/content/docs/en/sdk/technical-stack/proof-generation.mdx
@@ -10,20 +10,58 @@ excerpt: "Documents how zk proof generation is done on Scroll SDK."
 import Aside from "../../../../../components/Aside.astro"
 
 {/* TODO: Review full page before launch */}
+Generating ZK Proofs is a key component for any ZK Rollup, and it can often be the most painful part of operating a zk rollup.
 
-{/* Info about running the Ansible script for proof generation (and eventually using external prover partners) will go here. */}
+## Proof Generation Flow
 
-Currently, Scroll SDK requires that you run your own provers. We're actively working with proof generation platforms to make proof generation as easy as providing an API key.
 
 ## Mock Finalization
 
-In its default configuration, testnets can run without a ZK provers and simulate finalization. The L1 contract allows finalizing a batch without a valid proof, and the `rollup-relay` is configured to call the finalize method after 1 hour without a proof in the default configuration.
+Scroll SDK supports being run in two modes -- one using mock finalization, the other requiring valid zk proofs to finalize. Mock finalization is useful for devnets and testnets, where the zk proof generation is an unnecessary cost beyond brief testing periods.
 
-To change this mock finalization delay, adjust `config.toml` to change `TEST_ENV_MOCK_FINALIZE_TIMEOUT` from `3600` to the number of seconds you want to delay.
+In its default configuration, testnets are without a ZK provers and simulate finalization. The L1 contract allows finalizing a batch without a valid proof, and the `rollup-relay` is configured to call the finalize method after 1 hour without a proof in the default configuration.
+
+To change this mock finalization delay, adjust `config.toml` to change `rollup.TEST_ENV_MOCK_FINALIZE_TIMEOUT` from `3600` to the number of seconds you want to delay.
 
 To disable mock finalization entirely, adjust `config.toml` to change `TEST_ENV_MOCK_FINALIZE_ENABLED` to `false`.
 
-## Deploy a Prover
+<Aside type="danger">
+
+Because different "testnet" contracts are deployed depending on if `TEST_ENV_MOCK_FINALIZE_ENABLED` is true, it should be set to true from the genesis block for any production environments intended to secure user funds.  
+
+</Aside>
+
+## Outsourcing Proof Generation to External Service Providers
+
+Teams shouldn't need to become ZK infrastructure experts (or professional GPU sourcers) to run a chain. We've partnered with proof generation specialists to make outsoucing proof generation as easy as deploying one more chart.
+
+Using a proof generation service offers the following benefits:
+- Generate proofs on-demand through API-based services
+- Choose between enterprise solutions or proof marketplaces
+- Scale proof generation elastically based on your actual usage instead of reserving a specific capacity
+- Maintain flexibility to switch between providers, distribute load between them, or run your own GPUs
+
+The following providers already support generating Scroll SDK proofs:
+- Sindri
+	- Chart
+	- Docs
+- Snarkify
+	- Chart
+	- Docs
+
+{/* TODO: Add links to charts and docs */}
+
+<Aside type="caution">
+These Helm Charts are not maintained by Scroll, but we have collaborated with the teams to integrate the [`scroll-proving-sdk`](https://github.com/scroll-tech/scroll-proving-sdk).
+</Aside>
+
+See the [Enable Proof Generation using External Providers](/en/sdk/guides/digital-ocean-alt-gas-token#enable-proof-generation-using-external-providers) section of the Digital Ocean guide for an example of how to enable chunk, batch and bundle proofs using external providers.
+
+## Self-host a Prover
+
+<Aside type="danger">
+As of Oct. 31, 2024, these instructions are out-of-date. We are working on updating them.
+</Aside>
 
 <Aside type="caution">
 These instructions are an outline of the process, but our testing of the SDK has focused on working with external proving service providers, so may be out of date with out current SDK implementation.
