MinaFoundation · kaozenn · Jan 31, 2024 · Jan 31, 2024 · Jan 31, 2024 · Jan 31, 2024
diff --git a/docs/about-mina/faq.mdx b/docs/about-mina/faq.mdx
@@ -1,7 +1,7 @@
 ---
 title: Mina FAQ
 description: Frequently asked questions about Mina Protocol.
-keywords: 
+keywords:
   - mina faq
   - mina language
   - zkapp language
@@ -16,25 +16,21 @@ Answers to frequently asked questions about Mina Protocol.
 
 ### What language is Mina written in?
 
-The Mina node is written in OCaml. You don't need to know OCaml to write smart contracts for Mina.
+The Mina node is written in OCaml and Rust. You don't need to know OCaml/Rust to write smart contracts for Mina.
 
 ### What language are zkApp smart contracts written in?
 
 Mina's zero knowledge smart contracts (zkApps) are written in TypeScript.
 
 See [How to write a zkApp](/zkapps/how-to-write-a-zkapp).
 
-### How large is the Mina Blockchain?
-
-22 KB
-
-### Given Mina is only 22 KB, where are past transactions stored?
+### Where are past transactions stored?
 
 A Mina node can run with an optional flag to make it an archive node to store historical transactions. Archive nodes are useful for anyone running a service, such as a block explorer. Still, this historical data is not required to verify the current consensus state of the protocol.
 
 ### What zero knowledge (zk) proof system does Mina use?
 
-Mina Protocol uses a custom proof system called Kimchi,  developed by [O(1) Labs](https://o1labs.org/). Mina is the only blockchain offering infinite recursion.
+Mina Protocol uses a custom proof system called Kimchi,  developed by [o1Labs](https://o1labs.org/). Mina is the only blockchain offering infinite recursion.
 
 Check out the [Mina Book](https://o1-labs.github.io/proof-systems/plonk/overview.html) to learn more about Kimchi and the cryptography powering Mina Protocol.
 
@@ -50,9 +46,11 @@ Mina's consensus mechanism is an implementation of Ouroboros proof of stake. Due
 
 Yes, check out these block explorers:
 
-- https://minataur.net 
-- https://minaexplorer.com
-- https://minascan.io
+- [Mina Explorer](https://minaexplorer.com/)
+- [MinaScan](https://minascan.io/)
+- [MinaSearch](https://minasearch.com/) (in development by Granola)
+- [Minataur](https://minataur.net/)
+- [Minaverse](https://minaverse.xyz/)
 
 ### How does Mina achieve scalability?
 

diff --git a/docs/about-mina/index.mdx b/docs/about-mina/index.mdx
@@ -16,11 +16,14 @@ Mina is an L1 blockchain based on zero knowledge proofs (ZKP) with smart contrac
 
 ## Why Mina?
 
-Mina Protocol uses zero knowledge proofs to build a more ideal blockchain architecture.
+The Mina Protocol is a native ZK blockchain, but what does this mean? The Mina Protocol is a layer 1 blockchain built to use zero knowledge proofs. The Mina Protocol uses zk-SNARKS.
 
-Early blockchains, like Bitcoin and Ethereum, accumulate data over time and are currently hundreds of gigabytes in size. As time goes on, their blockchains will continue to increase in size. The entire chain history is required to verify the current consensus state of these networks.
+Some advantages of this approach are:
 
-With Mina, the blockchain always remains a constant size — about 22KB (the size of a few tweets). It's possible to verify the current consensus state of the protocol using this one recursive, 22KB zero knowledge proof. This means participants can quickly sync and verify the current consensus state of the network.
+- A succinct blockchain that facilitates decentralization. The lightweight design allows a node to sync faster and reduces both storage and bandwidth requirements for [node operators](../node-operators).
+- Zero knowledge proofs are used to secure the blockchain. Using recursive zk-SNARKs, the blockchain remains a constant size — about 22 KB.
+Client-side code execution: zkApps run code on the client, helping to scale blockchain technology. Client-side code execution generates zk-SNARKS (proofs) to prove correct execution. Transactions send these proofs to the blockchain and are verified on-chain.
+- Privacy by default, protect your data using zero knowledge proofs.     
 
 Learn more about Mina's unique [protocol architecture](about-mina/protocol-architecture).
 
@@ -32,7 +35,7 @@ Learn more in this video about [zero knowledge proofs](about-mina/what-are-zero-
 
 ## What are zkApps?
 
-Mina's zero knowledge smart contracts are referred to as zkApps. zkApps provide powerful and unique characteristics such as unlimited off-chain execution, privacy for private data inputs that are never seen by the blockchain, the ability to write smart contracts in TypeScript, and more.
+Mina's zero knowledge smart contracts, known as zkApps, offer distinct features, including off-chain proving, extensive off-chain execution capabilities, on-chain verification, privacy for confidential data (private inputs, by default, are not sent to the blockchain), the option to code smart contracts in TypeScript, and additional functionalities.
 
 See [zkApps Overview](/zkapps).
 

diff --git a/docs/about-mina/what-are-zero-knowledge-proofs.mdx b/docs/about-mina/what-are-zero-knowledge-proofs.mdx
@@ -11,6 +11,6 @@ import ResponsiveVideo from '@site/src/components/common/ResponsiveVideo';
 
 Zero knowledge proofs keep Mina's blockchain light and your personal data private.
 
-In this video, Brandon from <a href="https://o1labs.org/">O(1) Labs</a> explains what zero knowledge proofs are by comparing them to the game of "Where's Waldo?". Learn what zero knowledge proofs are, how they work, and their importance to Mina and the greater crypto community.
+In this video, Brandon from <a href="https://o1labs.org/">o1Labs</a> explains what zero knowledge proofs are by comparing them to the game of "Where's Waldo?". Learn what zero knowledge proofs are, how they work, and their importance to Mina and the greater crypto community.
 
 <ResponsiveVideo src="https://www.youtube.com/embed/GvwYJDzzI-g" />
diff --git a/docs/berkeley-upgrade/archive-migration-installation.mdx b/docs/berkeley-upgrade/archive-migration-installation.mdx
@@ -0,0 +1,151 @@
+---
+title: Installing the archive migration package
+sidebar_label: Installing archive migration package
+hide_title: false
+description: Satisfying the archive migration prerequisites.
+keywords:
+  - Berkeley
+  - upgrade
+  - archive migration
+  - installing 
+  - prerequisites
+  - mina archive node
+  - archive node
+---
+
+The archive node Berkeley migration package is sufficient for satisfying the migration from Devnet/Mainnet to Berkeley.
+However, it has some limitations. For example, the migration package does not migrate a non-canonical chain and it skips orphaned blocks that are not part of a canonical chain. 
+
+To mitigate these limitations, the archive node maintenance package is available for use by archive node operators who want to maintain a copy of their Devnet and Mainnet databases for historical reasons.
+
+## Install with Google Cloud SDK
+
+The Google Cloud SDK installer does not always register a `google-cloud-sdk` apt package. The best way to install gsutil is using the apt repostory:
+
+```sh
+curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/cloud.google.gpg
+echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
+sudo apt-get update && sudo apt-get install google-cloud-sdk
+```
+
+## Download the o1labs Mainnet archive database
+
+We strongly encourage you to perform the migration on your own data to preserve the benefits of decentralization. However, if you want to use the archive data that o1labs runs (for example, to bootstrap a new archive from SQL without waiting all day for the chain to download and replay), you can use the following steps:
+
+1. Download the Devnet/Mainnet archive data using cURL or gsutil:
+
+    - cURL:
+
+     For Devnet:
+     ```sh
+     curl https://storage.googleapis.com/mina-archive-dumps/devnet-archive-dump-{date}_0000.sql.tar.gz
+     ```
+
+     For Mainnet:   
+     ```sh
+     curl https://storage.googleapis.com/mina-archive-dumps/mainnet-archive-dump-{date}_0000.sql.tar.gz
+       ```
+
+     To filter the dumps by date, replace `{date}` using the required `yyyy-dd-mm` format. For example, for March 15, 2024, use `2024-03-15`.
+
+     :warning: The majority of backups have the `0000` suffix. If a download with that name suffix is not available, try incrementing it. For example, `0001`, `0002`, and so on.
+
+    - gsutil:
+
+       ```sh
+       gsutil cp gs://mina-archive-dumps/mainnet-archive-dump-2024-01-15* .
+       ```
+
+2. Extract the tar package.
+
+   ```sh
+   tar -xvzf {network}-archive-dump-{date}_0000.sql.tar.gz {network}-archive-dump-{date}_0000.sql
+   ```
+
+3. Import the Devnet/Mainnet archive dump into the Berkeley database.
+
+    Run this command at the database server:
+
+    ```sh
+    psql -U {user} -f {network}-archive-dump-{date}_0000.sql
+    ```
+
+    The database in the dump **archive_balances_migrated** is created with the Devnet/Mainnet archive schema.
+
+    Note: This database does not have any Berkeley changes.
+
+## Ensure the location of Google Cloud bucket with the Devnet/Mainnet precomputed blocks
+
+The recommended method is to perform migration on your own data to preserve the benefits of decentralization.
+
+`gsutil cp gs://mina_network_block_data/{network}-*.json .`
+
+:warning: Precomputed blocks for the Mainnet network take ~800 GB of disk space. Plan for adequate time to download these blocks. The Berkeley migration app downloads them incrementally only when needed.
+
+## Validate the Devnet/Mainnet database
+
+The correct Devnet/Mainnet database state is crucial for a successful migration. 
+
+[Missing blocks](/berkeley-upgrade/mainnet-database-maintenance#missing-blocks) is one the most frequent issues when dealing with the Devnet/Mainnet archive. Although this step is optional, it is strongly recommended that you verify the archive condition before you start the migration process.
+
+To learn how to maintain archive data, see [Devnet/Mainnet database maintenance](/berkeley-upgrade/mainnet-database-maintenance).
+
+## Download the migration applications
+
+Migration applications are distributed as part of the archive migration Docker and Debian packages.
+
+Choose the packages that are appropriate for your environment. 
+
+### Debian packages
+
+To get the Debian packages:
+
+```
+CODENAME=bullseye
+CHANNEL=stable
+VERSION=3.0.1-e848ecb
+
+echo "deb [trusted=yes] http://packages.o1test.net $CODENAME $CHANNEL" | tee /etc/apt/sources.list.d/mina.list
+apt-get update
+apt-get install --allow-downgrades -y "mina-archive-migration=$VERSION"
+```
+
+### Docker image
+
+To get the Docker image:
+
+```
+docker pull gcr.io/o1labs-192920/mina-archive-migration:3.0.1-e848ecb-{codename}
+```
+
+Where supported codenames are: 
+- bullseye
+- focal
+- buster
+
+
+## Devnet/Mainnet genesis ledger
+
+The Mina Devnet/Mainnet genesis ledger is stored in GitHub in the `mina` repository under the `genesis_ledgers` subfolder. However, if you are already running a daemon that is connected to the Mina Mainnet or the Devnet network, you already have the genesis ledger locally.
+
+## Berkeley database schema files
+
+You can get the Berkeley schema files from different locations:
+
+- GitHub repository from the `berkeley` branch. 
+
+    Note: The `berkeley` branch can contain new updates regarding schema files, so always get the latest schema files instead of using an already downloaded schema. 
+
+- Archive/Rosetta Docker from `berkeley` version
+
+### Example: Downloading schema sources from GitHub
+
+   ```sh
+   wget https://raw.githubusercontent.com/MinaProtocol/mina/berkeley/src/app/archive/zkapp_tables.sql
+
+   wget https://raw.githubusercontent.com/MinaProtocol/mina/berkeley/src/app/archive/create_schema.sql
+   ```
+
+## Next steps
+
+Congratulations on completing the essential preparation and verification steps. You are now ready to perform the migration steps in [Migrating Devnet/Mainnet Archive to Berkeley Archive](/berkeley-upgrade/migrating-archive-database-to-berkeley).
diff --git a/docs/berkeley-upgrade/archive-migration-prerequisites.mdx b/docs/berkeley-upgrade/archive-migration-prerequisites.mdx
@@ -0,0 +1,66 @@
+---
+title: Archive migration prerequisites
+sidebar_label: Archive migration prerequisites
+hide_title: false
+description: Overview of the migration tools and requirements to successfully migrate the Devnet/Mainnet archive database.
+keywords:
+  - Berkeley
+  - upgrade
+  - archive migration
+  - planning 
+  - prerequisites
+  - mina archive node
+  - archive node
+---
+
+To successfully migrate the archive database into the Berkeley version of the Mina network, you must ensure that your environment meets the foundational requirements.
+
+## Migration host
+
+- PostgreSQL database for database server
+- If you use Docker, then any of the supported OS by Mina (bullseye, focal, or buster) with at least 32 GB of RAM
+- gsutil application from Google Cloud Suite in version 5 or later
+- (Optional) Docker in version 23.0 or later
+
+## (Optional) Devnet/Mainnet database 
+
+One of the most obvious prerequisites is a Mainnet database.
+
+If you don't have an existing database with Devnet/Mainnet archive data, you can always download it from the Google Cloud bucket. However, we strongly encourage you to perform migration on your own data to preserve the benefits of decentralization.
+You can use any gsutil-compatible alternative to Google Cloud or a gsutil wrapper program.
+
+## (Optional) Google Cloud bucket with Devnet/Mainnet precomputed blocks
+
+Precomputed blocks are the JSON files that a correctly configured node updloads to the Google Cloud bucket.
+The Devnet/Mainnet to Berkeley archive data migration requires access to precomputed blocks that are uploaded by daemons that are connected to the Devnet or Mainnet networks. 
+
+The **berkeley-migration** app uses the gsutil app to download blocks. If you didn't store precomputed blocks during the first phase of migration, you can use the precomputed blocks provided by Mina Foundation.
+However, it is strongly recommended that you perform migration on your own data to preserve the benefits of decentralization.
+
+For Devnet blocks:
+
+```sh
+gsutil cp gs://mina_network_block_data/devnet-*.json .
+```
+
+For Mainnet blocks:
+
+```sh
+gsutil cp gs://mina_network_block_data/mainnet-*.json .
+```
+
+:warning: Precomputed blocks for the Mainnet network take ~800 GB of disk space. Plan for adequate time to download these blocks. The Berkeley migration app downloads them incrementally only when needed. You can instead download a 100 GB bundle of only the canonical Mainnet blocks that unpacks into ~220 GB: 
+
+```sh
+gsutil cp gs://mina_network_block_data/mainnet-bundle-2024-03-20.tar.zst . ; tar -xf mainnet-bundle-2024-03-20.tar.zst
+```
+
+:warning: Precomputed blocks for the Devnet network take several hundred GBs. Plan for adequate time to download these blocks. Instead, you can download a ~50 GB bundle of only the canonical Devnet blocks that unpacks into ~90 GB:
+
+```sh
+gsutil cp gs://mina_network_block_data/devnet-bundle-3NKRsRWBzmPR8Z8ZmJb4u8FLpnSkjRitUpKZzVkHp11QuwP5i839.tar.gz . ; tar -xf devnet-bundle-3NKRsRWBzmPR8Z8ZmJb4u8FLpnSkjRitUpKZzVkHp11QuwP5i839.tar.gz
+```
+
+These bundles are partial. Updated documentation with the new links and final data will be provided _after_ the Berkeley major upgrade is completed.
+
+The best practice is to collect precomputed blocks by yourself or by other third parties to preserve the benefits of decentralization. 
diff --git a/docs/berkeley-upgrade/index.mdx b/docs/berkeley-upgrade/index.mdx
@@ -0,0 +1,47 @@
+---
+title: Berkeley Upgrade
+sidebar_label: Berkeley Upgrade
+hide_title: true
+description: Berkeley upgrade is a major upgrade that requires all nodes in a network to upgrade to a newer version. It is not backward compatible.
+keywords:
+  - Berkeley
+  - upgrade
+  - archive migration
+  - mina archive node
+  - archive node
+---
+
+# Berkeley Upgrade
+
+The Berkeley upgrade is a major upgrade that requires all nodes in a network to upgrade to a newer version. It is not backward compatible. 
+
+A major upgrade occurs when there are major changes to the core protocol that require all nodes on the network to update to the latest software.
+
+## How to prepare for the Berkeley upgrade
+
+The Berkeley upgrade requires upgrading all nodes, including archive nodes. One of the required steps is to migrate archive databases from the current Mainnet format to Berkeley. This migration requires actions and efforts from node operators and exchanges. 
+
+Learn about the archive data migration:
+
+- [Understanding the migration process](/berkeley-upgrade/understanding-archive-migration)
+- [Prerequisites before migration](/berkeley-upgrade/archive-migration-prerequisites)
+- [Suggested installation procedure](/berkeley-upgrade/archive-migration-installation)
+- [How to perform archive migration](/berkeley-upgrade/migrating-archive-database-to-berkeley)
+
+Finally, see the shell script example that is compatible with a stock Debian 11 container:
+
+- [Worked example using March 22 data](/berkeley-upgrade/worked-archive-example)
+
+## What will happen with original Devnet/Mainnet data
+
+After the migration, you will have two databases:
+
+- The original Devnet/Mainnet database with small data adjustments (all pending blocks from last canoncial block until the fork block are converted to canoncial blocks)
+- A new Berkeley database based on Devnet/Mainnet data, but:
+  - Without Devnet/Mainnet orphaned blocks
+  - Without pending blocks that are not in the canonical chain
+  - With all pending blocks on the canonical chain converted to canonical blocks
+
+There is no requirement to preserve the original Devnet/Mainnet database after migration. However, if for some reason you want to keep the Mainnet orphaned or non-canonical pending blocks, you can download the archive maintenance package for the Devnet/Mainnet database.
+
+To learn about maintaining archive data, see [Devnet/Mainnet database maintenance](/berkeley-upgrade/mainnet-database-maintenance).