├── .dockerignore ├── .gitignore ├── .node-version ├── .vercel ├── README.txt └── project.json ├── README.md ├── core └── Footer.js ├── docs ├── 404.md ├── apis │ ├── ethereum-beacon-node-api.md │ ├── keymanager-api.md │ └── prysm-public-api.md ├── archive │ └── fee-recipient-vNext.md ├── backup-and-migration │ ├── backup-and-restore.md │ ├── migrating-keys.md │ ├── slashing-protection.md │ └── switch-clients.md ├── configure-prysm │ ├── command-line-options.md │ ├── configure-an-execution-node.md │ ├── configure-fee-recipient.md │ ├── configure-jwt.md │ ├── configure-mev-builder.md │ ├── prysmctl.md │ ├── run-a-slasher.md │ ├── run-an-archival-node.md │ ├── setup-proof-of-stake-devnet.md │ ├── stay-up-to-date.md │ └── sync-from-a-checkpoint.md ├── contribute │ ├── contribution-guidelines.md │ └── file-bug-report.md ├── faq.md ├── getting-started.md ├── install-prysm │ ├── install-with-bazel.md │ ├── install-with-docker.md │ ├── install-with-script.md │ └── partials │ │ ├── _quickstart-install-prysm.md │ │ ├── _quickstart-intro.md │ │ ├── _quickstart-prereqs.md │ │ ├── _quickstart-run-beacon-node.md │ │ ├── _quickstart-run-execution-node.md │ │ └── _quickstart-run-validator.md ├── learn │ ├── concepts │ │ ├── blobs.md │ │ ├── execution-requests.md │ │ ├── keys-wallets-accounts.md │ │ ├── nodes-and-networks.md │ │ ├── slashing.md │ │ └── validator-lifecycle.md │ ├── dev-concepts │ │ ├── architecture-overview.md │ │ ├── bls-cryptography.md │ │ ├── boltdb-database.md │ │ ├── end-to-end-tests.md │ │ ├── initial-sync.md │ │ ├── network-design.md │ │ ├── optimistic-sync.md │ │ ├── p2p-networking.md │ │ ├── prysm-beacon-node.md │ │ ├── prysm-validator-client.md │ │ └── validator-deposit-contract.md │ ├── ethereum-reading.md │ ├── external-reading.md │ └── tools │ │ ├── bazel.md │ │ ├── golang-principles.md │ │ └── golang.md ├── manage-connections │ ├── configure-ports-and-firewalls.md │ └── secure-grpc-connections.md ├── manage-validator │ ├── add-graffiti.md │ ├── exit-a-validator.md │ └── withdraw-validator.md ├── manage-wallet │ ├── create-a-prysm-wallet.md │ ├── import-keys-into-prysm-wallet.md │ ├── maintain-validator-uptime.md │ └── use-web3signer.md ├── misc │ ├── block-explorers.md │ ├── prysm-license.md │ ├── security-audits.md │ └── testnet-postmortems.md ├── monitoring-alerts-metrics │ ├── check-node-and-validator-status.md │ ├── collect-metrics-with-client-stats.md │ ├── grafana-dashboard.md │ ├── monitor-prysm.md │ ├── monitor-validators-by-index.md │ ├── partials │ │ └── _status-checklist-partial.md │ └── web-interface.md ├── partials │ ├── _full-sync-warning-partial.md │ ├── _jwt-generation-partial.md │ ├── _jwt-guidance-partial.md │ ├── _multidimensional-content-controls-partial.md │ └── _singleton-warning-partial.md ├── prepare-for-merge.md ├── security-best-practices.md ├── terminology.md └── troubleshooting │ ├── partials │ ├── _beacon-troubleshooting.md │ ├── _execution-troubleshooting.md │ ├── _generate-troubleshooting-report.md │ ├── _troubleshooting-all.md │ └── _validator-troubleshooting.md │ └── troubleshooting.md ├── docusaurus.config.js ├── en.json ├── package-lock.json ├── package.json ├── pages └── en │ ├── help.js │ └── users.js ├── renovate.json ├── robots.txt ├── scripts └── postbuild.js ├── sidebars.json ├── src ├── components │ ├── GenerateTroubleshootingReportWidget.js │ ├── HeaderBadgesWidget.js │ ├── MultiDimensionalContentWidget.js │ ├── RequestUpdateWidget.js │ └── version.js ├── css │ ├── custom.css │ └── custom.less ├── fetchCliHelp.js └── theme │ ├── DocItem │ └── Content │ │ └── index.js │ ├── Footer │ └── index.js │ └── SearchBar │ ├── DocSearch.js │ ├── algolia.css │ ├── index.js │ ├── lunar-search.js │ ├── styles.css │ ├── templates.js │ └── utils.js ├── static ├── assets │ ├── Quantstamp_Prysm_Phase_0_Final_Report.pdf │ ├── Trail_of_Bits_Prysm_Phase_0_Final_Report.pdf │ └── grafana-dashboards │ │ ├── big_amount_validators.json │ │ └── small_amount_validators.json ├── css │ └── custom.css └── images │ ├── Prysm.svg │ ├── Prysm_Docs.pptx │ ├── Thumbs.db │ ├── beaconchain.png │ ├── blobs.png │ ├── boltdb.png │ ├── builder.png │ ├── client-stack.png │ ├── createawallet.png │ ├── createwebpass.png │ ├── dashboard_currency_converter.png │ ├── dashboard_overview.png │ ├── deposit.png │ ├── depositdata.png │ ├── dialog-error-expanded.png │ ├── dialog-error.png │ ├── eth.jpg │ ├── ethereum-2.0.png │ ├── fee-recipient-ui.png │ ├── fsm-state-trans.png │ ├── graffiti-default.png │ ├── graffiti-random.png │ ├── graffiti-specific.png │ ├── grpc-logo2.png │ ├── imports.svg │ ├── initialize-alert.png │ ├── logo-white.png │ ├── logo.png │ ├── logo2.png │ ├── logo3.png │ ├── logs.png │ ├── mainnetlaunchpad.png │ ├── metamasksend.png │ ├── network-layers.png │ ├── network.png │ ├── ok.png │ ├── pending.png │ ├── processingdeposits.png │ ├── prometheus_page.png │ ├── proposal1.png │ ├── proposal2.png │ ├── prysm-architecture.png │ ├── prysm-basic-docker-setup.png │ ├── prysm-basic-setup.png │ ├── prysm-beacon-chain.png │ ├── prysm-eth1-deposit.png │ ├── prysm-multiple-keys.png │ ├── prysm-p2p-host-ip.png │ ├── prysm-single-key.png │ ├── prysm-slasher.png │ ├── prysm-validator.png │ ├── prysm-with-slasher.png │ ├── prysm_together.png │ ├── pyrmont.png │ ├── remotesigner.svg │ ├── service-diagram.png │ ├── syncing.png │ ├── toaster-error.png │ ├── validator-lifecycle-electra.png │ ├── validator-lifecycle.png │ ├── validator.png │ ├── walletcreate.png │ └── webdashboard.png ├── vercel.json ├── versions.json └── yarn.lock /.dockerignore: -------------------------------------------------------------------------------- 1 | *.log 2 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Dependencies 2 | /node_modules 3 | 4 | # Production 5 | /build 6 | /dist 7 | 8 | # Generated files 9 | .docusaurus 10 | .cache-loader 11 | 12 | # Misc 13 | .DS_Store 14 | .env.local 15 | .env.development.local 16 | .env.test.local 17 | .env.production.local 18 | .env 19 | .idea/ 20 | .vscode/ 21 | .vercel 22 | 23 | # Logs 24 | npm-debug.log* 25 | yarn-debug.log* 26 | yarn-error.log* 27 | lerna-debug.log* 28 | logs 29 | *.log 30 | -------------------------------------------------------------------------------- /.node-version: -------------------------------------------------------------------------------- 1 | 20 -------------------------------------------------------------------------------- /.vercel/README.txt: -------------------------------------------------------------------------------- 1 | > Why do I have a folder named ".vercel" in my project? 2 | The ".vercel" folder is created when you link a directory to a Vercel project. 3 | 4 | > What does the "project.json" file contain? 5 | The "project.json" file contains: 6 | - The ID of the Vercel project that you linked ("projectId") 7 | - The ID of the user or team your Vercel project is owned by ("orgId") 8 | 9 | > Should I commit the ".vercel" folder? 10 | No, you should not share the ".vercel" folder with anyone. 11 | Upon creation, it will be automatically added to your ".gitignore" file. 12 | -------------------------------------------------------------------------------- /.vercel/project.json: -------------------------------------------------------------------------------- 1 | {"projectId":"prj_tXTeJT99pWgS7gtgHaCu9jcATjZM","orgId":"team_nAi5Hu1K8gqjKckTjyLZ6Aut"} -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Prysm Documentation Portal 2 | 3 | This repository houses all the documentation pertaining to the Prysm client and Ethereum. It is generated with [Docusaurus](https://github.com/facebook/docusaurus) and deployed with [Vercel](https://vercel.com/). 4 | 5 | Below are steps for initializing and reproducing this portal for development. 6 | 7 | ## Dependencies 8 | 9 | 1. The latest version of [Node](https://nodejs.org/en/download/) installed. 10 | 2. npm (comes with Node.js) 11 | 12 | > You have to be on Node >= 8.x. 13 | 14 | ## Installation 15 | 16 | 1. Clone this repository. 17 | 2. Enter the newly cloned repo. 18 | 3. Issue the command `npm install`. 19 | 4. Wait for the installation process to complete. 20 | 21 | ## Running the development server 22 | 23 | 1. From the root directory, run the local web server using `npm start`. 24 | 2. Load the example site at http://localhost:3000/prsym/docs if it did not already open automatically. If port 3000 has already been taken, another port will be used. Look at the console messages to see which. 25 | 26 | You should see the example site loaded in your web browser. There's also a LiveReload server running, and any changes made to the docs and files in the project directory will cause the page to refresh. 27 | 28 | ## Building Static HTML Pages 29 | 30 | To create a static build of the documentation portal, run the following script from the root directory: 31 | 32 | ```bash 33 | npm run build 34 | ``` 35 | 36 | This will generate a `build` directory containing the `.html` files from all of the docs and other files included in `pages`. 37 | 38 | ## Deployment with Vercel 39 | 40 | This project is configured to be deployed with Vercel. The `vercel.json` file in the root directory contains the necessary configuration for deployment. 41 | 42 | To deploy: 43 | 44 | 1. Push your changes to GitHub. 45 | 2. Connect your GitHub repository to Vercel. 46 | 3. Vercel will automatically build and deploy the site. 47 | 48 | Alternatively, you can use the Vercel CLI to deploy from your local machine: 49 | 50 | ```bash 51 | npm install -g vercel 52 | vercel 53 | ``` 54 | -------------------------------------------------------------------------------- /core/Footer.js: -------------------------------------------------------------------------------- 1 | /** 2 | * Copyright (c) 2017-present, Facebook, Inc. 3 | * 4 | * This source code is licensed under the MIT license found in the 5 | * LICENSE file in the root directory of this source tree. 6 | */ 7 | 8 | const React = require('react'); 9 | 10 | class Footer extends React.Component { 11 | docUrl(doc, language) { 12 | const baseUrl = this.props.config.baseUrl; 13 | const docsUrl = this.props.config.docsUrl; 14 | const docsPart = `${docsUrl ? `${docsUrl}/` : ''}`; 15 | const langPart = `${language ? `${language}/` : ''}`; 16 | return `${baseUrl}${docsPart}${langPart}${doc}`; 17 | } 18 | 19 | pageUrl(doc, language) { 20 | const baseUrl = this.props.config.baseUrl; 21 | return baseUrl + (language ? `${language}/` : '') + doc; 22 | } 23 | 24 | render() { 25 | return ( 26 | 98 | ); 99 | } 100 | } 101 | 102 | module.exports = Footer; 103 | -------------------------------------------------------------------------------- /docs/404.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Page Not Found 3 | description: The requested page could not be found 4 | hide_table_of_contents: true 5 | --- 6 | 7 | # Page Not Found 8 | 9 | Sorry, we couldn't find the page you were looking for. This might be because: 10 | 11 | - The page has been moved or renamed 12 | - The URL contains a typo 13 | - The page no longer exists 14 | 15 | ## What Can You Do? 16 | 17 | Here are some helpful links to get you back on track: 18 | 19 | - [Getting Started Guide](/) - Learn how to run Prysm 20 | - [Installation Options](/install-prysm/install-with-script.md) - Different ways to install Prysm 21 | - [FAQ](/faq) - Frequently asked questions 22 | - [Technical Documentation](/learn/dev-concepts/prysm-beacon-node.md) - Deep dive into how Prysm works 23 | 24 | You can also: 25 | - Use the search bar at the top of the page 26 | - Check the navigation menu on the left 27 | - [Report this broken link](https://github.com/OffchainLabs/prysm-documentation/issues/new) if you think this is an error 28 | 29 | Need more help? Join our [Discord community](https://discord.gg/prysm) for support. 30 | -------------------------------------------------------------------------------- /docs/apis/ethereum-beacon-node-api.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: ethereum-public-api 3 | title: Ethereum Beacon Node API 4 | sidebar_label: Ethereum Beacon Node API 5 | description: This section contains information about the official Ethereum beacon API 6 | --- 7 | 8 | import {HeaderBadgesWidget} from '@site/src/components/HeaderBadgesWidget.js'; 9 | 10 | 11 | 12 | Prysm supports the official [Ethereum Beacon Node API specification](https://ethereum.github.io/beacon-APIs/), the official API standard developed by the Ethereum R&D team. The specification describes a RESTful set of endpoints which should be implemented by an Ethereum beacon node or a third-party service. This reduces the overhead of having to learn a new set of APIs when trying out a different client, and it allows network participants to reliably talk to each other over HTTP. 13 | 14 | :::caution The official Ethereum specification contains multiple definitions 15 | 16 | As of the time of writing, there are three definitions: [v1](https://ethereum.github.io/beacon-APIs/?urls.primaryName=v1), [v2.x.x](https://ethereum.github.io/beacon-APIs/) and [dev](https://ethereum.github.io/beacon-APIs/?urls.primaryName=dev). `dev` is an unstable version and supporting it is **not** to be expected. 17 | 18 | ::: 19 | 20 | ## Performing requests against a local Prysm node 21 | 22 | :::danger Do not publicly expose the API 23 | 24 | The API's purpose is a means of communication between your beacon node and your validator client. Because of this it is not protected against external malicious users. Some endpoints are vulnerable to Denial-of-Service attacks, while others may disclose information about your beacon node. The communication between the beacon node and the validator client should be done privately, either on the same machine or through an SSH connection. 25 | 26 | ::: 27 | 28 | 29 | :::caution 30 | 31 | `http-host` and `http-port` have replaced `--grpc-gateway-host` and `--grpc-gateway-port` respectively. 32 | 33 | ::: 34 | 35 | The API is exposed by default on `127.0.0.1:3500`. The host can be changed by manipulating the `--http-host` flag and the port can be modified with the `--http-port` flag. 36 | 37 | Performing a request is straightforward - simply concatenate the host with the port and the API's URL, providing any required URL and query parameters. As an example, the finalized state's root can be obtained using: 38 | 39 | ```sh 40 | http://127.0.0.1:3500/eth/v1/beacon/states/finalized/root 41 | ``` 42 | 43 | Notice that in this example the `{state_id}` URL parameter has been replaced with the literal value `finalized`. Please read the specification carefully to understand how each endpoint behaves. 44 | 45 | ## Disabling the API 46 | 47 | By default the beacon node runs with all available set of APIs enabled. You might want to disable one or more APIs, for example for security reasons. The `--http-modules` flags allows fine-grained control over which APIs are available on your node. 48 | 49 | 50 | ## Tips and Recommendations 51 | 52 | If you're experiencing timeouts when using endpoints that require passing a `state_id`, such as `/eth/v1/beacon/states/{state_id}/validators`, and you pass in a state more than a few epochs in the past, consider lowering the value of the `--slots-per-archive-point` flag. The smaller the value, the faster it is to fetch states. For historical state fetching we recommend setting the value to `64` or even `32`. Mind you that decreasing the value will result in the beacon DB taking much more space. Unfortunately there's a trade-off between speed and storage size. 53 | 54 | 55 | -------------------------------------------------------------------------------- /docs/apis/keymanager-api.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: keymanager-api 3 | title: Keymanager APIs 4 | sidebar_label: Keymanager APIs 5 | --- 6 | 7 | Prysm supports the official [Keymanager APIs](https://github.com/ethereum/keymanager-APIs), a REST API specification for validator clients to provide an alternative to CLI commands for onboarding and offboarding their validator keys on the consensus client. 8 | 9 | All Prysm Validator Client APIs require the use of the `--rpc` flag. 10 | 11 | Please refer to the "local keystores APIs" to manage locally stored validator keys, and to the "remote keystores APIs" to manage public key settings for Web3Signer. 12 | Go to our [Web3Signer](/manage-wallet/use-web3signer.md) docs page for more information. 13 | 14 | ## Authentication 15 | A JWT token is needed to use the Keymanager APIs. This token is automatically generated and can be found on the second line of the `auth-token` file, located in the Prysm wallet directory. The Prysm wallet directory is defined by the `--wallet-dir` flag default or custom value, and is also displayed in the Validator Client logs at start. 16 | 17 | The JWT token itself is directly displayed at the Validator Client start as well, in this log: 18 | 19 | ```sh 20 | INFO rpc: http://127.0.0.1:7500/initialize?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.e30.ck3J6tcvHcI74IiFjyJqcBH-MmNAq-fMr0ncyZkGvFM 21 | ``` 22 | 23 | The token needs to be copied and set in the header of the API request: 24 | 25 | ```sh 26 | Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.e30.ck3J6tcvHcI74IiFjyJqcBH-MmNAq-fMr0ncyZkGvFM 27 | ``` 28 | 29 | 30 | ## Other Prysm specific errors and usecases 31 | 32 | Prysm comes with some client specific edge cases and usages. These cases will be documented on the [Keymanager API repos under flows](https://github.com/ethereum/keymanager-APIs/tree/master/flows/client-specific/prysm). 33 | 34 | 35 | -------------------------------------------------------------------------------- /docs/apis/prysm-public-api.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: prysm-public-api 3 | title: Prysm public API 4 | sidebar_label: Prysm-specific API 5 | description: This section contains service definitions and gRPC instructions to interact with the Prysm public API. 6 | --- 7 | 8 | import {HeaderBadgesWidget} from '@site/src/components/HeaderBadgesWidget.js'; 9 | 10 | 11 | 12 | :::info This API is only used by Prysm 13 | 14 | For a standard API that all Ethereum beacon nodes implement, see [here](/apis/ethereum-beacon-node-api.md). Over the next few quarters, we plan on deprecating this API and replacing it with the standard API. 15 | 16 | ::: 17 | 18 | One of the required components of nodes in the Ethereum beacon chain network is to expose an API server for outside interaction. This API is critical for running validators on Ethereum, as validator clients can connect to nodes and query their API to figure out their assigned duties, to submit block proposals, and more. Prysm's Ethereum consensus API schema is maintained in Prysm itself here: [github.com/OffchainLabs/prysm/proto](https://github.com/OffchainLabs/prysm/tree/develop/proto) and is implemented by Prysm beacon nodes and validators. 19 | 20 | ![gRPC](/images/grpc-logo2.png) 21 | 22 | Prysm implements its API by using the popular [gRPC](https://grpc.io) project created by Google, providing highly advanced functionality for Ethereum consensus. Interacting with the API requires the use of protocol buffers, also known as protobuf. These [protocol buffer](https://developers.google.com/protocol-buffers/). For information on the functionality of gRPC and protocol buffers more generally, see the [gRPC guide](https://grpc.io/guides/). 23 | 24 | ## Calling the API on your local beacon node 25 | 26 | :::danger Do not publicly expose the API 27 | 28 | The API's purpose is a means of communication between your beacon node and your validator client. Because of this it is not protected against external malicious users. Some endpoints are vulnerable to Denial-of-Service attacks, while others may disclose information about your beacon node. The communication between the beacon node and the validator client should be done privately, either on the same machine or through an SSH connection. 29 | 30 | ::: 31 | 32 | By default, the beacon node exposes a [gRPC](https://grpc.io) API on host `127.0.0.1:4000`, which is accessed by the validator client. This is not an HTTP endpoint, so you will not be able to perform API queries via HTTP on that port. 33 | Instead of using a regular `curl` command you will need to use `gRPCurl` or a similar tool to make API calls via your terminal. 34 | 35 | :::caution as of v5.1.1 HTTP for gRPC endpoints is no longer supported 36 | 37 | As of v5.1.1, gRPC gateway was removed from Prysm and no longer supports HTTP for gRPC endpoints. 38 | Some Prysm specific endpoints are still supported via REST under the prysm/v1 namespace. 39 | 40 | ::: 41 | 42 | ### gRPC tooling and resources 43 | 44 | * [Awesome gRPC](https://github.com/grpc-ecosystem/awesome-grpc) 45 | * [Google's API Style Guide](https://cloud.google.com/apis/design/) 46 | * [Language reference for proto 3](https://developers.google.com/protocol-buffers/proto3) 47 | * [Protocol Buffer Basics: Go](https://developers.google.com/protocol-buffers/gotutorial) 48 | * [Transcoding gRPC to JSON/HTTP using Envoy](https://blog.jdriven.com/2018/11/transcoding-grpc-to-http-json-using-envoy/) 49 | * [gRPCurl](https://github.com/fullstorydev/grpcurl) 50 | -------------------------------------------------------------------------------- /docs/archive/fee-recipient-vNext.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: fee-recipient-vNext 3 | title: Configure a Fee Recipient Address 4 | sidebar_label: Configure Fee Recipient (vNext) 5 | --- 6 | 7 | # Configure a Fee Recipient Address (vNext) 8 | 9 | :::caution 10 | 11 | **This content has been upgraded to vCurrent as part of [Prysm releases](https://github.com/OffchainLabs/prysm/releases)**. 12 | 13 | See [How to configure Fee Recipient](/configure-prysm/configure-fee-recipient.md) for the latest feature guidance. 14 | 15 | ::: 16 | -------------------------------------------------------------------------------- /docs/backup-and-migration/backup-and-restore.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: database-backups 3 | title: Back up & restore database 4 | sidebar_label: Back up & restore database 5 | --- 6 | 7 | import {HeaderBadgesWidget} from '@site/src/components/HeaderBadgesWidget.js'; 8 | 9 | 10 | 11 | This section outlines how to perform database backups for your beacon node and validator client. The validator client services expose an **HTTP backup endpoint** which is the **safest way** to trigger a database backup. 12 | 13 | :::danger Performing backups while the client is running is not safe 14 | 15 | If you perform backups by manually copying the database while the client is running, **you risk copying a corrupted database**! You might be copying the folder right when the client is in the middle of writing data to the database, and could end up with a bad backup. 16 | 17 | ::: 18 | 19 | ## Beacon node 20 | 21 | ### Backing up the database manually 22 | 23 | Your first need to find your base directory. If you don't usually run your beacon node with the `--datadir` option, then you can find the base directory by running your beacon node with 24 | the `--help` option. It will vary depending the operating system you use. 25 | 26 | For MacOS, it is: 27 | 28 | ```sh 29 | --datadir value Data directory for the databases. (default: "/Users//Library/Eth2") 30 | ``` 31 | 32 | If you usually run your beacon node with the `--datadir` option, then your base directory is the one specified by the `--datadir` option. 33 | 34 | Finally, your database is located in the `beaconchaindata` subdirectory, at the `beaconchain.db` file. 35 | 36 | ### Restoring from a backup 37 | 38 | Ensure your beacon node is turned off if restoring a backup. You can restore a beacon chain DB from a backup file with the following command: 39 | 40 | import Tabs from '@theme/Tabs'; 41 | import TabItem from '@theme/TabItem'; 42 | 43 | 53 | 54 | 55 | **Using the Prysm installation script** 56 | 57 | ```sh 58 | prysm.sh beacon-chain db restore --restore-source-file=/path/to/backup --restore-target-dir=/path/to/desired/datadir 59 | ``` 60 | 61 | **Using Bazel** 62 | 63 | ```sh 64 | bazel run //cmd/beacon-chain -- db restore --restore-source-file=/path/to/backup --restore-target-dir=/path/to/desired/datadir 65 | ``` 66 | 67 | 68 | 69 | 70 | **Using the Prysm installation script** 71 | 72 | ```sh 73 | prysm.bat beacon-chain db restore --restore-source-file=\path\to\backup --restore-target-dir=\path\to\desired\datadir 74 | ``` 75 | 76 | 77 | 78 | 79 | **Using the Prysm installation script** 80 | 81 | ```sh 82 | prysm.sh beacon-chain db restore --restore-source-file=/path/to/backup --restore-target-dir=/path/to/desired/datadir 83 | ``` 84 | 85 | **Using Bazel** 86 | 87 | ```sh 88 | bazel run //cmd/beacon-chain -- db restore --restore-source-file=/path/to/backup --restore-target-dir=/path/to/desired/datadir 89 | ``` 90 | 91 | 92 | 93 | 94 | **Using the Prysm installation script** 95 | 96 | ```sh 97 | prysm.sh beacon-chain db restore --restore-source-file=/path/to/backup --restore-target-dir=/path/to/desired/datadir 98 | ``` 99 | 100 | **Using Bazel** 101 | 102 | ```sh 103 | bazel run //cmd/beacon-chain -- db restore --restore-source-file=/path/to/backup --restore-target-dir=/path/to/desired/datadir 104 | ``` 105 | 106 | 107 | 108 | 109 | ## Validator client 110 | 111 | ### Add the backup flag to your validator client 112 | 113 | Add the following flag to your validator client: 114 | 115 | - `--db-backup-output-dir`: Folder path to where backups will be output to, such as `/path/to/mybackups`. 116 | 117 | Now, your validator client will expose an HTTP endpoint `http://monitoringhost:monitoringport/db/backup`, which is `http://127.0.0.1:8081/db/backup` by default. You can hit this endpoint using curl or any other tool you prefer, and a backup will initiate which will be output to your `--db-backup-output-dir` path. 118 | 119 | 120 | ### Restoring from a backup 121 | 122 | Ensure your validator client is turned off if restoring a backup. You can restore a validator DB from a backup file with the following command: 123 | 124 | 134 | 135 | 136 | **Using the Prysm installation script** 137 | 138 | ```sh 139 | prysm.sh validator db restore --restore-source-file=/path/to/backup --restore-target-dir=/path/to/desired/datadir 140 | ``` 141 | 142 | **Using Bazel** 143 | 144 | ```sh 145 | bazel run //cmd/validator -- db restore --restore-source-file=/path/to/backup --restore-target-dir=/path/to/desired/datadir 146 | ``` 147 | 148 | 149 | 150 | 151 | **Using the Prysm installation script** 152 | 153 | ```sh 154 | prysm.bat validator db restore --restore-source-file=\path\to\backup --restore-target-dir=\path\to\desired\datadir 155 | ``` 156 | 157 | 158 | 159 | 160 | **Using the Prysm installation script** 161 | 162 | ```sh 163 | prysm.sh validator db restore --restore-source-file=/path/to/backup --restore-target-dir=/path/to/desired/datadir 164 | ``` 165 | 166 | **Using Bazel** 167 | 168 | ```sh 169 | bazel run //cmd/validator -- db restore --restore-source-file=/path/to/backup --restore-target-dir=/path/to/desired/datadir 170 | ``` 171 | 172 | 173 | 174 | 175 | **Using the Prysm installation script** 176 | 177 | ```sh 178 | prysm.sh validator db restore --restore-source-file=/path/to/backup --restore-target-dir=/path/to/desired/datadir 179 | ``` 180 | 181 | **Using Bazel** 182 | 183 | ```sh 184 | bazel run //cmd/validator -- db restore --restore-source-file=/path/to/backup --restore-target-dir=/path/to/desired/datadir 185 | ``` 186 | 187 | 188 | 189 | -------------------------------------------------------------------------------- /docs/backup-and-migration/switch-clients.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: switch-clients 3 | title: Switch to a new client 4 | sidebar_label: Switch to a new client 5 | --- 6 | 7 | import {HeaderBadgesWidget} from '@site/src/components/HeaderBadgesWidget.js'; 8 | 9 | 10 | 11 | This document provides guidance on moving from Prysm to a new consensus-layer client like Teku, Lighthouse, or Nimbus. 12 | 13 | :::danger Slashing Prevention 14 | 15 | The following best practices will help minimize the risk of [slashing](/learn/concepts/slashing.md) while migrating between clients: 16 | 17 | 1. Never run more than a single validator process with the same keys loaded. 18 | 2. Maintain and utilize slashing protection. 19 | 3. Accept downtime as part of a successful migration. 20 | 21 | ::: 22 | 23 | 24 | ### Step 1: Sync the beacon node 25 | 26 | Regardless of which client you are switching to, the first step of the process will be to sync the beacon node. This may take some time to complete. Some clients offer a feature known as "checkpoint sync" which allows you to sync a node within a few minutes. Without this, the process may take several hours to a few days. 27 | 28 | Installation documentation links for each client can be found below: 29 | 30 | - [Prysm Quickstart](/install-prysm/install-with-script.md) 31 | - [Teku](https://docs.teku.consensys.io/development/get-started/install/install-binaries) 32 | - [Nimbus](https://nimbus.guide/quick-start.html) 33 | - [Lighthouse](https://lighthouse-book.sigmaprime.io/installation.html) 34 | - [Lodestar](https://chainsafe.github.io/lodestar/run/getting-started/quick-start) 35 | 36 | ### Step 2: Stop and Disable Prysm 37 | 38 | Ensuring you stop and disable Prysm is critical to avoiding slashing events before proceeding further. 39 | 40 | Disabling Prysm prevents it from automatically starting up again after a reboot. 41 | 42 | Remove Prysm's validator keys as an added protection by following [these](/backup-and-migration/migrating-keys.md#step-5--verification-and-restarting-the-validator-client) instructions. 43 | 44 | ### Step 3: Export slashing protection history 45 | 46 | Ensure that you stop Prysm before exporting slashing protection in order to capture all validator actions. 47 | 48 | We have a section dedicated to exporting and importing slashing protection history [here.](/backup-and-migration/slashing-protection.md) Follow the steps regarding exporting slashing protection history. 49 | 50 | ### Step 4: Update port forwarding 51 | 52 | This step is not required for nodes which are running on a virtual public cloud, but keep in mind - nodes will be required to run a an execution client locally post merge! 53 | 54 | By default, Prysm uses TCP/13000 and UDP/12000. Remove those two rules and replace them with the appropriate port forwards for the client you are switching to. The process will be very similar to the steps laid out [here.](/manage-connections/configure-ports-and-firewalls.md#port-forwarding) 55 | 56 | Teku, Nimbus, and Lighthouse all use port 9000 for both TCP and UDP. 57 | 58 | ### Step 5: Import Validator Keys 59 | 60 | To minimize slashing risk, wait until at least one full epoch has elapsed between stopping Prysm and importing your validator keys, approximately 6.5 minutes, before proceeding. The inactivity leak cost is negligible compared to the cost of getting slashed. 61 | 62 | Once that amount of time has passed, import your validator keys into the respective validator client you wish to run. 63 | 64 | 74 | 75 | import Tabs from '@theme/Tabs'; 76 | import TabItem from '@theme/TabItem'; 77 | 78 | 79 | 80 | https://nimbus.guide/migration.html#step-3---import-your-validator-keys-into-nimbus 81 | 82 | 83 | 84 | 85 | 86 | https://lighthouse-book.sigmaprime.io/validator-manager-create.html 87 | 88 | 89 | 90 | 91 | 92 | https://docs.teku.consensys.io/get-started/connect/mainnet#create-a-password-file-for-each-validator-key 93 | 94 | 95 | 96 | 97 | 98 | https://chainsafe.github.io/lodestar/run/validator-management/vc-configuration#import-a-validator-keystore-to-lodestar 99 | 100 | 101 | 102 | 103 | ### Step 6: Import Slashing Protection History 104 | 105 | Follow your new clients' instructions regarding importing slashing protection history. 106 | 107 | 117 | 118 | 119 | 120 | 121 | 122 | https://nimbus.guide/migration.html?highlight=import%20slashing#step-4---import-your-slashing-protection-history 123 | 124 | 125 | 126 | 127 | 128 | https://lighthouse-book.sigmaprime.io/slashing-protection.html?highlight=import#import-and-export 129 | 130 | 131 | 132 | 133 | 134 | https://docs.teku.consensys.net/en/stable/HowTo/Prevent-Slashing/ 135 | 136 | 137 | 138 | 139 | 140 | https://chainsafe.github.io/lodestar/run/validator-management/validator-cli#validator-slashing-protection-import 141 | 142 | 143 | 144 | 145 | 146 | ### Step 7: Start the New Validator 147 | 148 | Ensure your beacon node is fully synced with the network by checking your clients logs prior to starting your validator. Once it is fully synced, start the validator. 149 | 150 | Search a block explorer like https://beaconcha.in with your validator's public key to confirm that your validator is now active! 151 | -------------------------------------------------------------------------------- /docs/configure-prysm/command-line-options.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: parameters 3 | title: Command-line options 4 | sidebar_label: Command-line options 5 | --- 6 | 7 | import {FetchCLIHelp} from '../../src/fetchCliHelp.js'; 8 | 9 | import {HeaderBadgesWidget} from '@site/src/components/HeaderBadgesWidget.js'; 10 | 11 | 12 | 13 | Prysm's client software can be configured using flags and YAML files. This document provides a comprehensive list of all available flags and their descriptions. The flag descriptions that you see in this document are generated from code comments within the latest Prysm release. 14 | 15 | ## Beacon node flags 16 | 17 | 18 | 19 | ## Validator flags 20 | 21 | :::tip Graffiti 22 | 23 | You can use the `--graffiti` validator flag to add a string to your proposed blocks, which will be seen on the block explorer (i.e., ` --graffiti "Prysm is awesome!"`) 24 | 25 | ::: 26 | 27 | 28 | 29 | ## `prysmctl` flags 30 | 31 | Refer to the [Use `prysmctl`](prysmctl.md) for `prysmctl` download and installation instructions. 32 | 33 | 34 | 35 | ## Client stats flags 36 | 37 | Prysm's client stats service is an optional utility that reports process metrics to third-parties such as block explorers. Refer to our [client stats documentation](/monitoring-alerts-metrics/collect-metrics-with-client-stats.md) for more information. 38 | 39 | 40 | 41 | ## Loading parameters from a YAML file 42 | 43 | You can optionally configure Prysm to load flag values from a `.yaml` file. Consider this option if you're looking for a streamlined terminal experience or unique, portable configuration profiles. 44 | 45 | The below steps show how place a common Prysm flag into a YAML file, and how to specify the YAML file when Prysm starts up. 46 | 47 | ### GNU\Linux, Mac, ARM64 48 | 49 | 1. In your Prysm working directory, create a `.yaml` file and open it in a text editor. 50 | 51 | 2. Add the following lines to the file before closing and saving: 52 | 53 | ```sh 54 | datadir: '/data' 55 | ``` 56 | 57 | 3. Start the Prysm beacon chain as normal, while specifying the location of the `.yaml` like so: 58 | 59 | ```sh 60 | ./prysm.sh beacon-chain --config-file=/path/to/file.yaml 61 | 62 | ``` 63 | or for a validator like so: 64 | 65 | ```sh 66 | ./prysm.sh validator --config-file=/path/to/file.yaml 67 | ``` 68 | 69 | ### Windows 70 | 71 | 1. In your Prysm working directory, create a `.yaml` file and open it in a text editor. 72 | 73 | 2. Add the following lines to the file before closing and saving: 74 | 75 | ```sh 76 | datadir: 'c:\prysm' 77 | ``` 78 | 79 | 3. Start the Prysm beacon chain as normal, while specifying the location of the `.yaml` like so: 80 | 81 | ```sh 82 | .\prysm.bat beacon-chain --config-file=c:\path\to\file.yaml 83 | ``` 84 | 85 | or for a validator like so: 86 | 87 | ```sh 88 | .\prysm.bat validator --config-file=c:\path\to\file.yaml 89 | ``` 90 | 91 | It is possible to provide additional flags alongside the `.yaml` file, though if conflicting flags are provided, the flag defined in the`.yaml` file will take priority. For example, if the flag `--datadir=/data2` is specified and `datadir: "/data1"` is in the `.yaml` file, Prysm would prioritize writing to `/data1`. 92 | -------------------------------------------------------------------------------- /docs/configure-prysm/configure-an-execution-node.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: configuring-for-prysm 3 | title: Configure an execution node for Prysm 4 | sidebar_label: Configure an execution node 5 | --- 6 | 7 | import {HeaderBadgesWidget} from '@site/src/components/HeaderBadgesWidget.js'; 8 | 9 | 10 | 11 | :::info Looking for an end-to-end guide? 12 | 13 | If you're looking for end-to-end configuration guidance, refer to our [Quickstart](/install-prysm/install-with-script.md). 14 | 15 | ::: 16 | 17 |
18 | 19 | ## Select a configuration 20 | 21 | If you're looking for the simplest configuration, select `Geth` and `IPC`: 22 | 23 | import MultidimensionalContentControlsPartial from '@site/docs/partials/_multidimensional-content-controls-partial.md'; 24 | 25 | 26 | 27 |
28 | 29 | import QuickstartRunExecutionNodeJWTPartial from '@site/docs/install-prysm/partials/_quickstart-run-execution-node.md'; 30 | 31 | 32 | 33 | Congratulations! You’re now running an execution node that your Prysm beacon node can connect to. 34 | 35 |
36 | 37 |
38 | 39 | -------------------------------------------------------------------------------- /docs/configure-prysm/configure-jwt.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: authentication 3 | title: Configure JWT authentication 4 | sidebar_label: Configure JWT authentication 5 | --- 6 | 7 | import {HeaderBadgesWidget} from '@site/src/components/HeaderBadgesWidget.js'; 8 | 9 | 10 | 11 | :::info HTTP-JWT only 12 | 13 | This guidance is relevant only if your beacon node is connecting to your execution node over HTTP. If you're using IPC, you can ignore this. If you want to learn how to use IPC, see our [Quickstart](/install-prysm/install-with-script.md). 14 | 15 | ::: 16 | 17 | First, **select a configuration**: 18 | 19 |
20 | 21 | import MultidimensionalContentControlsPartial from '@site/docs/partials/_multidimensional-content-controls-partial.md'; 22 | 23 | 24 | 25 |
26 | 27 | import JwtGuidancePartial from '@site/docs/partials/_jwt-guidance-partial.md'; 28 | 29 | 30 | 31 |
32 | 33 |
34 | 35 | 36 | :::tip Congratulations 37 | 38 | Congrats! You're now using JWT authentication. 39 | 40 | ::: 41 | 42 | -------------------------------------------------------------------------------- /docs/configure-prysm/prysmctl.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: prysmctl 3 | title: Use prysmctl 4 | sidebar_label: Use prysmctl 5 | --- 6 | 7 | import {HeaderBadgesWidget} from '@site/src/components/HeaderBadgesWidget.js'; 8 | 9 | 10 | 11 | `prysmctl` is a command-line utility for common and one-off Ethereum proof-of-stake tasks, like helping users with validator exits or withdrawals. Most `prysmctl` commands require access to a fully synced beacon node. 12 | 13 | 14 | ### Run via binaries 15 | 16 | Binaries for the latest `prysmctl` tool can be found on the [latest Prysm release page](https://github.com/OffchainLabs/prysm/releases). Each binary is a unique version with its own set of features. New releases may include new features for `prysmctl` that will need to be downloaded separately. The installed binaries will need to be renamed to `prysmctl` to use the example below. 17 | 18 | :::info 19 | 20 | Some users will need to give permissions to the downloaded binaries to be executable. Linux users can do this by right clicking the file, going to permissions, and clicking the `Allow executing file as program` checkmark. This may be different for each operating system. 21 | 22 | ::: 23 | 24 | Example of running `prysmctl` by opening a terminal at the installed location after renaming: 25 | 26 | ```sh 27 | ./prysmctl --help 28 | ``` 29 | 30 | The binaries can be run through a terminal directly and won't need installation. Please refer to the [list commands](#list-commands section for additional information. 31 | 32 | ### Install via source 33 | 34 | Dependencies: 35 | 36 | - [Bazelisk](https://bazel.build/install/bazelisk) - this will automatically manage the version of **Bazel** required. 37 | - [golang](https://go.dev/) installed 38 | - The `cmake` package installed 39 | - The `git` package installed 40 | - `libssl-dev` installed 41 | - `libgmp-dev` installed 42 | - `libtinfo5` installed 43 | - `libprotoc` version 3.14 installed 44 | 45 | #### Install Bazelisk 46 | 47 | :::caution 48 | 49 | Windows users should run through binaries as some users may have issues building through bazel. 50 | 51 | ::: 52 | 53 | Bazelisk is a launcher for Bazel which automatically downloads and installs the version of Bazel that you need. There are several ways to install Bazelisk: 54 | 55 | - Using [a binary release](https://github.com/bazelbuild/bazelisk/releases) for Linux, macOS, or Windows 56 | - Using npm: `npm install -g @bazel/bazelisk` 57 | - Using apt: https://bazel.build/install/ubuntu 58 | - Using Homebrew on macOS: `brew install bazelisk` 59 | - By compiling from source using Go: `go install github.com/bazelbuild/bazelisk@latest` 60 | 61 | #### Clone the Prysm project locally 62 | 63 | Clone Prysm's [main repository](https://github.com/OffchainLabs/prysm). Switch to the latest version (the latest version number can be found on the [releases page](https://github.com/OffchainLabs/prysm/releases)). Once cloned, enter the directory: 64 | 65 | ```sh 66 | git clone https://github.com/OffchainLabs/prysm && cd prysm 67 | `````` 68 | 69 | #### Build `prysmctl` 70 | 71 | ```sh 72 | bazel build //cmd/prysmctl --config=release 73 | ``` 74 | 75 | Bazel will automatically pull and install any dependencies as well, including Go and necessary compilers. 76 | 77 | ### List commands 78 | 79 | ```sh 80 | ./prysmctl --help 81 | ``` 82 | 83 | **Using Docker** 84 | ```sh 85 | docker run -it gcr.io/offchainlabs/prysm/cmd/prysmctl:latest --help 86 | ``` 87 | 88 | The `—-help` flag will provide a list of commands, subcommands, and flags to use. 89 | 90 | Commands can also be found in our [Prysm parameter documentation](/configure-prysm/command-line-options.md) 91 | 92 | ### Frequently asked questions 93 | 94 | #### One of the Prysm guides tells me to use a `prysmctl` command that isn't available. What do I do? 95 | You may be using an older version of `prysmctl` and are required to download a newer version. 96 | 97 | #### Is `prysmctl` accessible from prysm.sh, prysm.s1, or prysm.bat? 98 | No. This utility will only be accessible by building from source or by downloading binaries for specific versions of Prysm. 99 | 100 | -------------------------------------------------------------------------------- /docs/configure-prysm/run-a-slasher.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: slasher 3 | title: Run a slasher 4 | sidebar_label: Run a slasher 5 | --- 6 | 7 | import {HeaderBadgesWidget} from '@site/src/components/HeaderBadgesWidget.js'; 8 | 9 | 10 | 11 | This section provides instructions on how to run [slasher](https://github.com/OffchainLabs/prysm/tree/develop/beacon-chain/slasher) as an **optional** process to report slashable offenses on Ethereum proof-of-stake. If slasher detects a slashable offense, proof is sent to the [beacon-chain node](/learn/dev-concepts/prysm-beacon-node.md) for inclusion in a block. [Validators](/learn/dev-concepts/prysm-validator-client.md) earn a small whistleblower reward for including this proof into a block. 12 | 13 | :::tip Slasher Requires Significant Disk Space 14 | 15 | Slasher is essentially a beacon node with **superpowers**. It uses significantly more disk space when running on mainnet. 16 | 17 | ::: 18 | 19 | ## System requirements 20 | 21 | ### Minimum specifications 22 | 23 | These specifications must be met in order to successfully run a Prysm beacon node in `--slasher` mode 24 | 25 | * Operating System: 64-bit Linux, Mac OS X 10.14+, Windows 64-bit 26 | * Processor: Intel Core i5–760 or AMD FX-8100 or better 27 | * Memory: 8GB RAM 28 | * Storage: 1TB available space SSD 29 | * Internet: Broadband connection 30 | 31 | ### Recommended specifications 32 | 33 | These hardware specifications are recommended, but not required to run the Prysm client. 34 | 35 | * Processor: Intel Core i7–4770 or AMD FX-8310 or better 36 | * Memory: 16GB RAM 37 | * Storage: 1TB available space SSD 38 | * Internet: Broadband connection 39 | 40 | ## What is Slashing 41 | 42 | Slashing occurs when there is evidence a validator has acted against the Ethereum network. Ethereum proof of stake works on a penalty-based incentive mechanism to heavily discourage actions on the network that could cause instability, malicious forking and conflicting information from validators. Slashing does not need to have been the result of malicious intent, it could also happen accidentally via misconfiguration. If a validator acts in a way that can confuse or disrupt the integrity of the system, the protocol removes, or **slashes**, a portion of the offending validator's existing stake, causing a gradual loss of `ETH` over time until the validator is forcefully ejected from the network and marked as `SLASHED`. This is an **irreversible** process. 43 | 44 | The main purpose of slashing is to discourage attacks against the Ethereum proof-of-stake network that might otherwise be cheap to perform such as trivially creating conflicting forks where validators attest on a different view of historical checkpoints. 45 | 46 | A validator that correctly follows the protocol should never emit a slashable vote during normal operation. Validators will not be slashed for simply being offline (however, they may be penalized). 47 | 48 | ## What is a Slasher 49 | 50 | **Slasher** is the name of software that can detect slashable events from validators and report them to the protocol. You can think of a slasher as the network “police”. Running a slasher is **optional**. In order to detect slashable messages, the slasher records the attesting and proposing history for every validator on the network, then cross references this history with what has been broadcasted to find slashable messages such as double blocks or surrounding votes. 51 | 52 | In theory all the network needs is *one honest, properly functioning slasher* to monitor the network because any slashings found are propagated to the entire network for it to be put into a block as soon as possible. 53 | 54 | Running a slasher is not meant to be profitable. Slashing is meant to be rare and whistleblower rewards are purposefully low. Running a slasher is meant to be an *altruistic action*, and as stated, only a single, honest, properly functioning slasher needs to be active in the network to catch slashable offenses. Thankfully, this is a low bar to entry, and we envision quite a lot of users and entities will run slashers to ensure network security. 55 | 56 | ## Running Slasher 57 | 58 | Running a slasher is as simple as adding the `--slasher` flag to your **beacon node**. Doing this will enable your beacon node to perform slashing detection. However, **home stakers are advised _not_ to run a slasher on personal hardware,** as it is a tremendously resource-hungry process. Slasher is very heavy on database access and disk usage, and the `slasher.db` will quickly grow to 1TB or more when running on mainnet. Given that slasher needs to store a lot of information about attestations and blocks within the network, this is to be expected. 59 | 60 | ### Whistleblower Rewards 61 | 62 | Running a slasher can also offer some profits to your validators given certain conditions. If slasher detects a slashable condition, it will **broadcast it to the network by default**. Some lucky validator will then package this slashing evidence into a block and be rewarded for doing so. You can **disable** this broadcast in Prysm using the `--disable-broadcast-slashings` option in your **beacon node**. 63 | 64 | ### Who Should Run a Slasher 65 | 66 | As summarized above, the slasher process is likely to overwhelm most home validator setups. The incentives for running a slasher accumulate irregularly, at great cost, so home stakers are advised to run their beacon node without it. It is an entirely optional process. Beacon node operators should consider running the slasher if they are operating a **staking pool** or **data center**. 67 | 68 | ## Using Slasher for Advanced Slashing Protection 69 | 70 | An alternative implementation for slashing prevention is the use of slasher itself as a middleware client between your beacon node and validator client. Before a validator client submits a block or an attestation, it asks the slasher if the object is slashable. If the check passes, the data will go through to the beacon node. This is the most advanced form of slashing protection as slasher is, ideally, aware of everything happening in the network and has a recorded history of blocks and attestations for every validator. 71 | 72 | ## Further Reading 73 | 74 | We recommend reading our piece on [slashing prevention tips](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) which has more detailed information on how to protect your own validator from being slashed, the document also clarifies a number of common misconceptions. 75 | -------------------------------------------------------------------------------- /docs/configure-prysm/run-an-archival-node.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: beacon_node_api 3 | title: Run an archival node 4 | sidebar_label: Run an archival node 5 | --- 6 | 7 | import {HeaderBadgesWidget} from '@site/src/components/HeaderBadgesWidget.js'; 8 | 9 | 10 | 11 | ## Using archival beacon nodes for API retrieval 12 | 13 | The beacon chain is the coordinator of Ethereum proof-of-stake. It is responsible for creating new blocks, ensuring their validity, and both rewarding and penalizing participating validators for their actions. This responsibility gives the beacon node full visibility of actions performed on the blockchain, and as such, can be used as a retrospective API in order to query chain information. While this could be considered analogous to log analysis, unlike in log analysis, previous states that have not had full data stored locally for review can be requested, then fetched retrospectively and queried. 14 | 15 | By default, the Prysm beacon node saves the state of the chain locally in a database every 2048 slots or 64 epochs. For clarity, a slot is every 12 seconds and 32 slots make an epoch. Hence the beacon node, by default, saves the state on a per 64 epochs basis. Should more detailed information on historical slots be required, these can be requested retrospectively. However, there will be a time delay whilst the data is requested and retrieved. 16 | 17 | :::tip If you wish to shorten the API response delay, we recommend saving the state once per epoch. 18 | 19 | Additional storage will be required 20 | In addition to having to download the slot/epoch data there will be an increased local storage requirement, potentially by a multiple of 32 should all data be requested. 21 | 22 | ::: 23 | 24 | The default setting will store one state per epoch, each being ~ 1Mb (or more) of data, setting the beacon node to capture all slots per epoch will increase the storage requirements to ~ 32Mb (or more) per epoch. 25 | 26 | ## Rationale 27 | 28 | While the default setting is sufficient for regular beacon chain functionality, it is not optimized for users who query the API multiple times per slot or require historical data not available within the currently saved state. In order to avoid the delays outlined above when retrieving data, the beacon node can be configured to save the state for each slot. **This will significantly improve performance for users creating multiple requests of local beacon nodes.** 29 | 30 | ## Beacon chain API information 31 | 32 | Full details of the Ethereum beacon API are available in the [Ethereum public API section](/apis/ethereum-beacon-node-api.md). 33 | 34 | ## Command line/Configuration file usage: 35 | 36 | Setting the beacon node to save the state for each slot can be done both on the command line and through the configuration file as outlined below. 37 | 38 | 39 | **Using Linux/MacOS based systems** 40 | 41 | ```sh 42 | ./prysm.sh beacon-chain --slots-per-archive-point=32 43 | ``` 44 | 45 | **Using Windows based systems** 46 | 47 | ```sh 48 | prysm.bat beacon-chain --slots-per-archive-point=32 49 | ``` 50 | 51 | **Using the Configuration file:** 52 | 53 | If you are running Prysm and specifying command line flags via a configuration file such as `/home/beacon/config.yaml` on Linux or MacOS or `c:\prysm\beacon\config.yaml` on Windows, you can add the following to that file: 54 | 55 | ```sh 56 | slots-per-archive-point: 32 57 | ``` 58 | -------------------------------------------------------------------------------- /docs/configure-prysm/setup-proof-of-stake-devnet.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: proof-of-stake-devnet 3 | title: How to Set Up an Ethereum Proof-of-Stake Devnet in Minutes 4 | sidebar_label: Configure an Ethereum devnet 5 | --- 6 | 7 | import {HeaderBadgesWidget} from '@site/src/components/HeaderBadgesWidget.js'; 8 | 9 | 10 | 11 | This page is now deprecated in favor of running a devnet using the [Kurtosis tool](https://github.com/ethpandaops/ethereum-package) for running and testing Prysm. Kurtosis is highly maintained and is the recommended way to set up a Prysm devnet locally. -------------------------------------------------------------------------------- /docs/contribute/file-bug-report.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: bugreports 3 | title: Report a bug 4 | sidebar_label: Report a bug 5 | --- 6 | 7 | import {HeaderBadgesWidget} from '@site/src/components/HeaderBadgesWidget.js'; 8 | 9 | 10 | 11 | Bug reports are critical to the rapid development of the Prysm client. In order to make the process quick and efficient for all parties, it is best to follow some common reporting etiquette when filing to avoid double issues or miscommunications. 12 | 13 | ## Checking if your issue exists 14 | 15 | Duplicate tickets are a hinderance to the development process and, as such, it is crucial to first check through Prysm's existing issues to see if what you are experiencing has already been indexed. 16 | 17 | To do so, head over to the [issue page](https://github.com/OffchainLabs/prysm/issues) and enter some related keywords into the search bar. This may include a sample from the output or specific components it affects. If this is unsuccessful, check the [issue labels index](https://github.com/OffchainLabs/prysm/labels) for related categories and review the tickets within. 18 | 19 | If searches have shown the issue in question has not been reported yet, feel free to open up a new issue ticket. 20 | 21 | ## Writing quality bug reports 22 | 23 | A good bug report is structured to help the developers and contributors visualize the issue in the clearest way possible. It's important to be concise and use comprehensive language, while also providing all relevant information available. Use short and accurate sentences without any unnecessary additions, and include all existing specifications with a list of steps to reproduce the expected problem. Issues that cannot be reproduced **cannot be solved**. 24 | 25 | If you are experiencing multiple issues, it is best to open each as a separate ticket. This allows them to be closed individually as they are resolved. 26 | 27 | An original bug report will very likely be preserved and used as a record and sounding board for users that have similar experiences in the future. Because of this, it is a great service to the community to ensure that reports meet these standards and follow the template closely. 28 | 29 | 30 | ## The bug report template 31 | 32 | Below is the standard bug report template used by all of Prysm's official repositories. 33 | 34 | ```sh 35 | 36 | 37 | ## Expected Behaviour 38 | 39 | 40 | ## Current Behaviour 41 | 42 | 43 | ## Steps to Reproduce 44 | 45 | 1. 46 | 2. 47 | 3. 48 | 4. 49 | 5. 50 | 51 | ## Detailed Description 52 | 53 | 54 | ## Specifications 55 | 56 | Operating system: 57 | Version(s) used: 58 | 59 | ## Possible Solution 60 | 61 | 62 | ## Further Information 63 |