Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrading Docusaurus from 2.0.0-beta.4 → 2.4.1 + required fixes #790

Merged
merged 6 commits into from
May 30, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .node-version
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
20
2 changes: 1 addition & 1 deletion package-lock.json

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

2 changes: 0 additions & 2 deletions website/docs/advanced/beacon_node_api.md
Original file line number Diff line number Diff line change
Expand Up @@ -54,6 +54,4 @@ If you are running Prysm and specifying command line flags via a configuration f
slots-per-archive-point: 32
```

import {RequestUpdateWidget} from '@site/src/components/RequestUpdateWidget.js';

<RequestUpdateWidget />
3 changes: 0 additions & 3 deletions website/docs/advanced/maintaining-uptime.md
Original file line number Diff line number Diff line change
Expand Up @@ -57,6 +57,3 @@ User=YOUR_USER
WantedBy=default.target
```

import {RequestUpdateWidget} from '@site/src/components/RequestUpdateWidget.js';

<RequestUpdateWidget />
16 changes: 7 additions & 9 deletions website/docs/advanced/migrating-keys.md
Original file line number Diff line number Diff line change
Expand Up @@ -201,13 +201,13 @@ You can also run the accounts backup command non-interactively by using the foll

**Flag Usage**

| Flag | Usage |
| ------------- |:-------------|
| `--wallet-dir` | Path to a wallet directory (default: "$HOME/Eth2Validators/prysm-wallet-v2")
| `--wallet-password-file` | Path to a plain-text, .txt file containing your wallet's password.
| `--backup-dir` | Path to a directory where accounts will be backed up into a zip file. (default: $HOME/Eth2Validators/)
| `--backup-public-keys` | Comma-separated list of public key hex strings to specify which validator accounts to backup.
| `--backup-password-file` | Path to a plain-text, .txt file containing the desired password for your backed up accounts.
| Flag | Usage |
| ------------------------ | :----------------------------------------------------------------------------------------------------- |
| `--wallet-dir` | Path to a wallet directory (default: "$HOME/Eth2Validators/prysm-wallet-v2") |
| `--wallet-password-file` | Path to a plain-text, .txt file containing your wallet's password. |
| `--backup-dir` | Path to a directory where accounts will be backed up into a zip file. (default: $HOME/Eth2Validators/) |
| `--backup-public-keys` | Comma-separated list of public key hex strings to specify which validator accounts to backup. |
| `--backup-password-file` | Path to a plain-text, .txt file containing the desired password for your backed up accounts. |


### Step 3: Importing Validator accounts
Expand Down Expand Up @@ -358,6 +358,4 @@ Once complete, verify the account removal using the validator accounts list comm

No. After successfully importing your slashing protection history from A -> B, you can discard A. If you need to migrate from B -> C, B's slashing protection history is all you need to export/import.

import {RequestUpdateWidget} from '@site/src/components/RequestUpdateWidget.js';

<RequestUpdateWidget />
2 changes: 1 addition & 1 deletion website/docs/advanced/proof-of-stake-devnet.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ sidebar_label: Configure a devnet

import {HeaderBadgesWidget} from '@site/src/components/HeaderBadgesWidget.js';

<HeaderBadgesWidget commaDelimitedContributors="Raul, Sammy, James" lastVerifiedDateString="March 22nd, 2023" />
<HeaderBadgesWidget commaDelimitedContributors="Raul, Sammy, James" />

:::info

Expand Down
6 changes: 2 additions & 4 deletions website/docs/advanced/switch-clients.md
Original file line number Diff line number Diff line change
Expand Up @@ -72,7 +72,8 @@ Once that amount of time has passed, import your validator keys into the respect
]
}>


import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';

<TabItem value="nim">

Expand Down Expand Up @@ -149,6 +150,3 @@ Ensure your beacon node is fully synced with the network by checking your client
Search a block explorer like https://beaconcha.in/ with your validator's public key to confirm that your validator is now active!


import {RequestUpdateWidget} from '@site/src/components/RequestUpdateWidget.js';

<RequestUpdateWidget />
45 changes: 22 additions & 23 deletions website/docs/concepts/nodes-networks.md
Original file line number Diff line number Diff line change
Expand Up @@ -34,26 +34,28 @@ When users stake 32 ETH to participate in Ethereum's proof-of-stake consensus me
<br />

<table>
<tr>
<th style={{minWidth: 170 + 'px'}}>Component</th>
<th>Description</th>
</tr>
<tr>
<td><strong>Ethereum node</strong><br />aka "Node"</td>
<td>An Ethereum node is an <strong>execution node</strong> and <strong>beacon node</strong> working together. Ethereum nodes communicate peer-to-peer to secure the Ethereum network, and require both <strong>execution-layer client software</strong> and <strong>consensus-layer client software</strong>.</td>
</tr>
<tr>
<td><strong>Execution node</strong></td>
<td>Execution nodes use execution client software to process transactions and smart contracts in Ethereum's <strong>execution layer</strong>. Nethermind, Besu, and Go Ethereum (Geth) are examples of execution client software.<br /> <br />An execution node will talk to other execution nodes via peer-to-peer networking, and to a local beacon node.</td>
</tr>
<tr>
<td><strong>Beacon node</strong></td>
<td>Beacon nodes use beacon node client software to coordinate Ethereum's proof-of-stake consensus. Prysm, Teku, Lighthouse, and Nimbus are consensus clients that contain both beacon node and validator client software. <br /> <br />A beacon node will talk to other beacon nodes via peer-to-peer networking, to a local execution node, and (optionally) to a local validator.</td>
</tr>
<tr>
<td><strong>Validator</strong></td>
<td>Validator clients are specialized software that let people stake 32 ETH as collateral within Ethereum's <strong>consensus layer</strong>. Validators are responsible for proposing blocks within Ethereum's proof-of-stake consensus mechanism, and will fully replace proof-of-work miners after <a href='https://ethereum.org/en/upgrades/merge/'>The Merge</a>. <br /> <br />A validator will talk only to a local beacon node. A validator's beacon node tells the validator what work to do, and broadcasts the validator's work to the Ethereum network as the validator performs its duties.</td>
</tr>
<tbody>
<tr>
<th style={{minWidth: 170 + 'px'}}>Component</th>
<th>Description</th>
</tr>
<tr>
<td><strong>Ethereum node</strong><br />aka "Node"</td>
<td>An Ethereum node is an <strong>execution node</strong> and <strong>beacon node</strong> working together. Ethereum nodes communicate peer-to-peer to secure the Ethereum network, and require both <strong>execution-layer client software</strong> and <strong>consensus-layer client software</strong>.</td>
</tr>
<tr>
<td><strong>Execution node</strong></td>
<td>Execution nodes use execution client software to process transactions and smart contracts in Ethereum's <strong>execution layer</strong>. Nethermind, Besu, and Go Ethereum (Geth) are examples of execution client software.<br /> <br />An execution node will talk to other execution nodes via peer-to-peer networking, and to a local beacon node.</td>
</tr>
<tr>
<td><strong>Beacon node</strong></td>
<td>Beacon nodes use beacon node client software to coordinate Ethereum's proof-of-stake consensus. Prysm, Teku, Lighthouse, and Nimbus are consensus clients that contain both beacon node and validator client software. <br /> <br />A beacon node will talk to other beacon nodes via peer-to-peer networking, to a local execution node, and (optionally) to a local validator.</td>
</tr>
<tr>
<td><strong>Validator</strong></td>
<td>Validator clients are specialized software that let people stake 32 ETH as collateral within Ethereum's <strong>consensus layer</strong>. Validators are responsible for proposing blocks within Ethereum's proof-of-stake consensus mechanism, and will fully replace proof-of-work miners after <a href='https://ethereum.org/en/upgrades/merge/'>The Merge</a>. <br /> <br />A validator will talk only to a local beacon node. A validator's beacon node tells the validator what work to do, and broadcasts the validator's work to the Ethereum network as the validator performs its duties.</td>
</tr>
</tbody>
</table>


Expand Down Expand Up @@ -115,6 +117,3 @@ Slashers, like validators, use specialized pieces of consensus-layer client soft
We recommend using [Paradigm's MultiFaucet](https://faucet.paradigm.xyz/). If that doesn't work, you can ask the community for testnet ETH on either the [Prysm Discord server](https://discord.gg/prysmaticlabs) or on [r/ethstaker](https://www.reddit.com/r/ethstaker).


import {RequestUpdateWidget} from '@site/src/components/RequestUpdateWidget.js';

<RequestUpdateWidget />
3 changes: 0 additions & 3 deletions website/docs/concepts/slashing.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,3 @@ Being slashed is the result of a validator undertaking one of three “bad” ac

Basic slashing protection is enabled by default using a database that keeps track of objects your validator has previously signed, ensuring the validator does not sign the same message again, causing a violation and getting slashed.

import {RequestUpdateWidget} from '@site/src/components/RequestUpdateWidget.js';

<RequestUpdateWidget />
3 changes: 0 additions & 3 deletions website/docs/contribute/bugreports.md
Original file line number Diff line number Diff line change
Expand Up @@ -63,6 +63,3 @@ Version(s) used:
<!--- Anything else to add?
```

import {RequestUpdateWidget} from '@site/src/components/RequestUpdateWidget.js';

<RequestUpdateWidget />
3 changes: 0 additions & 3 deletions website/docs/contribute/contribution-guidelines.md
Original file line number Diff line number Diff line change
Expand Up @@ -194,6 +194,3 @@ After you complete the questionnaire, the pull request will appear in the list o

Core developers may ask questions and request that you make edits. If you set notifications at the top of the page to “not watching,” you will still be notified by email whenever someone comments on the page of a pull request you have created. If you are asked to modify your pull request, edit your local branch, push up your fixes, then leave a comment to notify the original reviewer that the pull request is ready for further review.

import {RequestUpdateWidget} from '@site/src/components/RequestUpdateWidget.js';

<RequestUpdateWidget />
3 changes: 0 additions & 3 deletions website/docs/contribute/prysms-golang-principles.md
Original file line number Diff line number Diff line change
Expand Up @@ -99,6 +99,3 @@ func UpdateBeaconState(currentState *pb.BeaconState, blockCh chan<- *types.Block
}
```

import {RequestUpdateWidget} from '@site/src/components/RequestUpdateWidget.js';

<RequestUpdateWidget />
3 changes: 0 additions & 3 deletions website/docs/contribute/required-reading.md
Original file line number Diff line number Diff line change
Expand Up @@ -156,6 +156,3 @@ After reading the sharding material for part-time contributors, it is important
* [Go Official Website](https://golang.org/)


import {RequestUpdateWidget} from '@site/src/components/RequestUpdateWidget.js';

<RequestUpdateWidget />
3 changes: 0 additions & 3 deletions website/docs/devtools/block-explorers.md
Original file line number Diff line number Diff line change
Expand Up @@ -29,6 +29,3 @@ Their respective Github repositories are:
- [eth2-redot-com](https://github.com/AtlantPlatform/eth2-redot-com)


import {RequestUpdateWidget} from '@site/src/components/RequestUpdateWidget.js';

<RequestUpdateWidget />
3 changes: 0 additions & 3 deletions website/docs/devtools/end-to-end.md
Original file line number Diff line number Diff line change
Expand Up @@ -137,6 +137,3 @@ var E2EBeaconChainFlags = []string{
}
```

import {RequestUpdateWidget} from '@site/src/components/RequestUpdateWidget.js';

<RequestUpdateWidget />
3 changes: 0 additions & 3 deletions website/docs/devtools/extending-apis.md
Original file line number Diff line number Diff line change
Expand Up @@ -298,6 +298,3 @@ The example above did not cover everything that is possible with the library. Th
- Instead of implementing single hooks we can replace the whole response/request with one or more custom handlers, which we register in the factory. See `custom_handlers.go` for examples. This may be tricky to get right, but essentially allows to manipulate the request in any desirable way.
- `ProcessRequestContainerFields`, `ProcessMiddlewareResponseFields` and `process_field.go` are responsible for field translations e.g. hex to base64 and vice versa. If you need to process a field in a new way, you will need to register the struct tag and the processing function in one of the aforementioned functions. Notice that this is a global change, but it does not matter as long as you use a new tag. Because none of the existing structs contain this tag, their fields will not be processed in this new way.

import {RequestUpdateWidget} from '@site/src/components/RequestUpdateWidget.js';

<RequestUpdateWidget />
9 changes: 3 additions & 6 deletions website/docs/devtools/init-state.md
Original file line number Diff line number Diff line change
Expand Up @@ -126,7 +126,7 @@ FSM Manager is a container used to group machines together, for easier managemen
While event handlers operate on FSMs, they are not registered with machines themselves but with the queue, this is done for reasons of efficiency (machines are constantly removed and re-added, so are kept as simple as possible). When an event occurs (for example `Tick` event occurs every 200 milliseconds), each known FSM is passed to the corresponding event handler, depending on FSM’s current state. Here is the list of event handlers, required FSM start states and their corresponding handlers:

| Event | Required FSM state | Event Handler |
|---------------|--------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| ------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Tick | New | [Queue.onScheduleEvent()](https://github.com/prysmaticlabs/prysm/blob/ce397ce797c33dbcf77fa7670c356844ef6aad43/beacon-chain/sync/initial-sync/blocks_queue.go#L281) |
| Tick | Data parsed | [Queue.onReadyToSendEvent()](https://github.com/prysmaticlabs/prysm/blob/ce397ce797c33dbcf77fa7670c356844ef6aad43/beacon-chain/sync/initial-sync/blocks_queue.go#L334) |
| Tick | Skipped | [Queue.onProcessSkippedEvent()](https://github.com/prysmaticlabs/prysm/blob/ce397ce797c33dbcf77fa7670c356844ef6aad43/beacon-chain/sync/initial-sync/blocks_queue.go#L383) |
Expand All @@ -139,7 +139,7 @@ The above table is easy to read: for example it is easy to see that in order for
Below is a state transition table (depending on input there might be several possible transitions for a given event -- only one of which is valid, as our FSMs are deterministic):

| State/Event | New | Scheduled | Data Parsed | Skipped | Data Sent |
|-------------------|-------------------|-----------------|-------------------|---------|-------------|
| ----------------- | ----------------- | --------------- | ----------------- | ------- | ----------- |
| **Tick** | Scheduled Skipped | | Data Sent Skipped | New | New Skipped |
| **Data Received** | | Data Parsed New | | | |

Expand Down Expand Up @@ -401,7 +401,7 @@ bazel test //beacon-chain/sync/initial-sync:go_default_test --test_arg=-test.v -
The `--test_filter` can be empty (all tests will then be run), or specify a pattern to match:

| --test_filter | Component to be tested |
|-------------------|------------------------------|
| ----------------- | ---------------------------- |
| TestBlocksQueue | All blocks queue tests. |
| TestBlocksFetcher | All blocks fetcher tests. |
| TestStateMachine | All FSM related tests. |
Expand Down Expand Up @@ -430,6 +430,3 @@ bazel run //beacon-chain -- --datadir=$HOME/prysm \
--enable-debug-rpc-endpoints --prater
```

import {RequestUpdateWidget} from '@site/src/components/RequestUpdateWidget.js';

<RequestUpdateWidget />
27 changes: 12 additions & 15 deletions website/docs/devtools/net-design.md
Original file line number Diff line number Diff line change
Expand Up @@ -194,7 +194,7 @@ This sync mode requests subsets of the chain to multiple peers, perhaps even wit
For example, if we were to request blocks 10 through 25 from 4 peers:

| **Peer #** | **Batch Block Requests** |
|------------|--------------------------|
| ---------- | ------------------------ |
| Peer 1 | 10, 14, 18, 22 |
| Peer 2 | 11, 15, 19, 23 |
| Peer 3 | 12, 16, 20, 24 |
Expand All @@ -214,7 +214,7 @@ For example, if we were to request blocks 10 through 25 from 4 peers:
In the event that there is a failure for any subset of the requested range, the remaining blocks will be split across the remaining peers. For example, if peer 3 was disconnected without responding, we would round robin block requests for blocks [12, 24], [16], and [20].

| Peer # | Batch Block Requests |
|--------|-------------------------------|
| ------ | ----------------------------- |
| Peer 1 | 10, 14, 18, 22 |
| Peer 2 | 11, 15, 19, 23 |
| Peer 3 | 12, 16, 20, 24 (disconnected) |
Expand Down Expand Up @@ -311,16 +311,16 @@ GossipSub as our pubsub library is mostly implemented already with the [libp2p G

**Parameters**

| Parameter Name | Description | Value |
|----------------|----------------------------------|-------|
| D | Topic stable mesh target count | 6 |
| D_low | Topic stable mesh low watermark | 4 |
| D_high | Topic stable mesh high watermark | 12 |
| D_lazy | Gossip target | 6 ||
| fanout_ttl | TTL for fanout maps for topics we are not subscribed to but have published to, in seconds | 60 |
| gossip_advertise | Number of windows to gossip about | 3 |
| gossip_history | Number of heartbeat intervals to retain message IDs | 5 |
| heartbeat_internal | Frequency of heartbeat, in seconds | 1 |
| Parameter Name | Description | Value |
| ------------------ | ----------------------------------------------------------------------------------------- | ----- |
| D | Topic stable mesh target count | 6 |
| D_low | Topic stable mesh low watermark | 4 |
| D_high | Topic stable mesh high watermark | 12 |
| D_lazy | Gossip target | 6 | |
| fanout_ttl | TTL for fanout maps for topics we are not subscribed to but have published to, in seconds | 60 |
| gossip_advertise | Number of windows to gossip about | 3 |
| gossip_history | Number of heartbeat intervals to retain message IDs | 5 |
| heartbeat_internal | Frequency of heartbeat, in seconds | 1 |


Conveniently, these values are the default for libp2p GossipSub. See [godoc](https://godoc.org/github.com/libp2p/go-libp2p-pubsub#pkg-variables). However, we should specify these within Prysm to avoid any upstream change breaking interoperability compatibility. Separating these values from hard coded constants will require an upstream PR as it is not configurable. Enabling this functionality can be a bounty and prioritized at P2/P3. At a minimum, we can write a unit test that would fail if any of these config's change since the variables are public.
Expand Down Expand Up @@ -459,6 +459,3 @@ Similar to the sync migration, the existing mapping will be prefixed with deprec
16*1240 (deposit) = 19840
16*112 (voluntaryexit) = 1792

import {RequestUpdateWidget} from '@site/src/components/RequestUpdateWidget.js';

<RequestUpdateWidget />
7 changes: 2 additions & 5 deletions website/docs/execution-node/authentication.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,13 +16,13 @@ This guidance is relevant only if your beacon node is connecting to your executi

First, <strong>select a configuration</strong>:

<div class='jwt-guide'>
<div className='jwt-guide'>

import MultidimensionalContentControlsPartial from '@site/docs/partials/_multidimensional-content-controls-partial.md';

<MultidimensionalContentControlsPartial />

<div class='hide-tabs'>
<div className='hide-tabs'>

import JwtGuidancePartial from '@site/docs/partials/_jwt-guidance-partial.md';

Expand All @@ -39,6 +39,3 @@ Congrats! You're now using JWT authentication.

:::

import {RequestUpdateWidget} from '@site/src/components/RequestUpdateWidget.js';

<RequestUpdateWidget />
Loading