update docs (#3890)
* update docs * introduce mdbook-admonish for nice looking callouts * new section on data directory * recommend source build for advanced users and direct the rest to binaries * more strongly highlight that execution client is needed * write an actual deposit guide * remove cruft / fix links / etc
This commit is contained in:
Jacek Sieka
GitHub
parent
76fa4772fb
commit
f98e9ec8bc
1
Makefile
1
Makefile
|
|
@ -661,6 +661,7 @@ book:
|
|||
[[ "$$(mdbook --version)" = "mdbook v0.4.18" ]] || { echo "'mdbook v0.4.18' not found in PATH. See 'docs/README.md'. Aborting."; exit 1; }
|
||||
[[ "$$(mdbook-toc --version)" == "mdbook-toc 0.8.0" ]] || { echo "'mdbook-toc 0.8.0' not found in PATH. See 'docs/README.md'. Aborting."; exit 1; }
|
||||
[[ "$$(mdbook-open-on-gh --version)" == "mdbook-open-on-gh 2.1.0" ]] || { echo "'mdbook-open-on-gh 2.1.0' not found in PATH. See 'docs/README.md'. Aborting."; exit 1; }
|
||||
[[ "$$(mdbook-admonish --version)" == "mdbook-admonish 1.7.0" ]] || { echo "'mdbook-open-on-gh 1.7.0' not found in PATH. See 'docs/README.md'. Aborting."; exit 1; }
|
||||
cd docs/the_nimbus_book && \
|
||||
mdbook build
|
||||
|
||||
|
|
|
|||
|
|
@ -4,13 +4,18 @@ Some books also use [mdbook-toc](https://github.com/badboy/mdbook-toc) for table
|
|||
|
||||
```bash
|
||||
# Install or update tooling (make sure you add "~/.cargo/bin" to PATH):
|
||||
cargo install mdbook mdbook-toc mdbook-open-on-gh
|
||||
cargo install mdbook --version 0.4.18
|
||||
cargo install mdbook-toc --version 0.8.0
|
||||
cargo install mdbook-open-on-gh --version 2.1.0
|
||||
cargo install mdbook-admonish --version 1.7.0
|
||||
|
||||
# Work on the book locally - open "http://localhost:4000" for live version
|
||||
cd docs/the_nimbus_book
|
||||
mdbook serve -p 4000
|
||||
|
||||
# Create a local copy of the book
|
||||
make book
|
||||
|
||||
# Publish book using makefile (in the top-level dir)
|
||||
make publish-book
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -9,8 +9,12 @@ title = "The Nimbus Beacon Chain Book"
|
|||
command = "mdbook-open-on-gh"
|
||||
renderer = ["html"]
|
||||
|
||||
[preprocessor.admonish]
|
||||
command = "mdbook-admonish"
|
||||
assets_version = "2.0.0" # do not edit: managed by `mdbook-admonish install`
|
||||
|
||||
[output.html]
|
||||
additional-css = ["custom.css"]
|
||||
additional-css = ["custom.css", "mdbook-admonish.css"]
|
||||
git-repository-url = "https://github.com/status-im/nimbus-eth2"
|
||||
git-branch = "unstable"
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,352 @@
|
|||
@charset "UTF-8";
|
||||
:root {
|
||||
--md-admonition-icon--note:
|
||||
url("data:image/svg+xml;charset=utf-8,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'><path d='M20.71 7.04c.39-.39.39-1.04 0-1.41l-2.34-2.34c-.37-.39-1.02-.39-1.41 0l-1.84 1.83 3.75 3.75M3 17.25V21h3.75L17.81 9.93l-3.75-3.75L3 17.25z'/></svg>");
|
||||
--md-admonition-icon--abstract:
|
||||
url("data:image/svg+xml;charset=utf-8,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'><path d='M17 9H7V7h10m0 6H7v-2h10m-3 6H7v-2h7M12 3a1 1 0 0 1 1 1 1 1 0 0 1-1 1 1 1 0 0 1-1-1 1 1 0 0 1 1-1m7 0h-4.18C14.4 1.84 13.3 1 12 1c-1.3 0-2.4.84-2.82 2H5a2 2 0 0 0-2 2v14a2 2 0 0 0 2 2h14a2 2 0 0 0 2-2V5a2 2 0 0 0-2-2z'/></svg>");
|
||||
--md-admonition-icon--info:
|
||||
url("data:image/svg+xml;charset=utf-8,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'><path d='M13 9h-2V7h2m0 10h-2v-6h2m-1-9A10 10 0 0 0 2 12a10 10 0 0 0 10 10 10 10 0 0 0 10-10A10 10 0 0 0 12 2z'/></svg>");
|
||||
--md-admonition-icon--tip:
|
||||
url("data:image/svg+xml;charset=utf-8,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'><path d='M17.66 11.2c-.23-.3-.51-.56-.77-.82-.67-.6-1.43-1.03-2.07-1.66C13.33 7.26 13 4.85 13.95 3c-.95.23-1.78.75-2.49 1.32-2.59 2.08-3.61 5.75-2.39 8.9.04.1.08.2.08.33 0 .22-.15.42-.35.5-.23.1-.47.04-.66-.12a.58.58 0 0 1-.14-.17c-1.13-1.43-1.31-3.48-.55-5.12C5.78 10 4.87 12.3 5 14.47c.06.5.12 1 .29 1.5.14.6.41 1.2.71 1.73 1.08 1.73 2.95 2.97 4.96 3.22 2.14.27 4.43-.12 6.07-1.6 1.83-1.66 2.47-4.32 1.53-6.6l-.13-.26c-.21-.46-.77-1.26-.77-1.26m-3.16 6.3c-.28.24-.74.5-1.1.6-1.12.4-2.24-.16-2.9-.82 1.19-.28 1.9-1.16 2.11-2.05.17-.8-.15-1.46-.28-2.23-.12-.74-.1-1.37.17-2.06.19.38.39.76.63 1.06.77 1 1.98 1.44 2.24 2.8.04.14.06.28.06.43.03.82-.33 1.72-.93 2.27z'/></svg>");
|
||||
--md-admonition-icon--success:
|
||||
url("data:image/svg+xml;charset=utf-8,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'><path d='m9 20.42-6.21-6.21 2.83-2.83L9 14.77l9.88-9.89 2.83 2.83L9 20.42z'/></svg>");
|
||||
--md-admonition-icon--question:
|
||||
url("data:image/svg+xml;charset=utf-8,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'><path d='m15.07 11.25-.9.92C13.45 12.89 13 13.5 13 15h-2v-.5c0-1.11.45-2.11 1.17-2.83l1.24-1.26c.37-.36.59-.86.59-1.41a2 2 0 0 0-2-2 2 2 0 0 0-2 2H8a4 4 0 0 1 4-4 4 4 0 0 1 4 4 3.2 3.2 0 0 1-.93 2.25M13 19h-2v-2h2M12 2A10 10 0 0 0 2 12a10 10 0 0 0 10 10 10 10 0 0 0 10-10c0-5.53-4.5-10-10-10z'/></svg>");
|
||||
--md-admonition-icon--warning:
|
||||
url("data:image/svg+xml;charset=utf-8,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'><path d='M13 14h-2V9h2m0 9h-2v-2h2M1 21h22L12 2 1 21z'/></svg>");
|
||||
--md-admonition-icon--failure:
|
||||
url("data:image/svg+xml;charset=utf-8,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'><path d='M20 6.91 17.09 4 12 9.09 6.91 4 4 6.91 9.09 12 4 17.09 6.91 20 12 14.91 17.09 20 20 17.09 14.91 12 20 6.91z'/></svg>");
|
||||
--md-admonition-icon--danger:
|
||||
url("data:image/svg+xml;charset=utf-8,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'><path d='M11 15H6l7-14v8h5l-7 14v-8z'/></svg>");
|
||||
--md-admonition-icon--bug:
|
||||
url("data:image/svg+xml;charset=utf-8,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'><path d='M14 12h-4v-2h4m0 6h-4v-2h4m6-6h-2.81a5.985 5.985 0 0 0-1.82-1.96L17 4.41 15.59 3l-2.17 2.17a6.002 6.002 0 0 0-2.83 0L8.41 3 7 4.41l1.62 1.63C7.88 6.55 7.26 7.22 6.81 8H4v2h2.09c-.05.33-.09.66-.09 1v1H4v2h2v1c0 .34.04.67.09 1H4v2h2.81c1.04 1.79 2.97 3 5.19 3s4.15-1.21 5.19-3H20v-2h-2.09c.05-.33.09-.66.09-1v-1h2v-2h-2v-1c0-.34-.04-.67-.09-1H20V8z'/></svg>");
|
||||
--md-admonition-icon--example:
|
||||
url("data:image/svg+xml;charset=utf-8,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'><path d='M7 13v-2h14v2H7m0 6v-2h14v2H7M7 7V5h14v2H7M3 8V5H2V4h2v4H3m-1 9v-1h3v4H2v-1h2v-.5H3v-1h1V17H2m2.25-7a.75.75 0 0 1 .75.75c0 .2-.08.39-.21.52L3.12 13H5v1H2v-.92L4 11H2v-1h2.25z'/></svg>");
|
||||
--md-admonition-icon--quote:
|
||||
url("data:image/svg+xml;charset=utf-8,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'><path d='M14 17h3l2-4V7h-6v6h3M6 17h3l2-4V7H5v6h3l-2 4z'/></svg>");
|
||||
--md-details-icon:
|
||||
url("data:image/svg+xml;charset=utf-8,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'><path d='M8.59 16.58 13.17 12 8.59 7.41 10 6l6 6-6 6-1.41-1.42Z'/></svg>");
|
||||
}
|
||||
|
||||
:is(.admonition) {
|
||||
display: flow-root;
|
||||
margin: 1.5625em 0;
|
||||
padding: 0 1.2rem;
|
||||
color: var(--fg);
|
||||
page-break-inside: avoid;
|
||||
background-color: var(--bg);
|
||||
border: 0 solid black;
|
||||
border-inline-start-width: 0.4rem;
|
||||
border-radius: 0.2rem;
|
||||
box-shadow: 0 0.2rem 1rem rgba(0, 0, 0, 0.05), 0 0 0.1rem rgba(0, 0, 0, 0.1);
|
||||
}
|
||||
@media print {
|
||||
:is(.admonition) {
|
||||
box-shadow: none;
|
||||
}
|
||||
}
|
||||
:is(.admonition) > * {
|
||||
box-sizing: border-box;
|
||||
}
|
||||
:is(.admonition) :is(.admonition) {
|
||||
margin-top: 1em;
|
||||
margin-bottom: 1em;
|
||||
}
|
||||
:is(.admonition) > .tabbed-set:only-child {
|
||||
margin-top: 0;
|
||||
}
|
||||
html :is(.admonition) > :last-child {
|
||||
margin-bottom: 1.2rem;
|
||||
}
|
||||
|
||||
a.admonition-anchor-link {
|
||||
display: none;
|
||||
position: absolute;
|
||||
left: -1.2rem;
|
||||
padding-right: 1rem;
|
||||
}
|
||||
a.admonition-anchor-link:link, a.admonition-anchor-link:visited {
|
||||
color: var(--fg);
|
||||
}
|
||||
a.admonition-anchor-link:link:hover, a.admonition-anchor-link:visited:hover {
|
||||
text-decoration: none;
|
||||
}
|
||||
a.admonition-anchor-link::before {
|
||||
content: "§";
|
||||
}
|
||||
|
||||
:is(.admonition-title, summary) {
|
||||
position: relative;
|
||||
margin-block: 0;
|
||||
margin-inline: -1.6rem -1.2rem;
|
||||
padding-block: 0.8rem;
|
||||
padding-inline: 4.4rem 1.2rem;
|
||||
font-weight: 700;
|
||||
background-color: rgba(68, 138, 255, 0.1);
|
||||
display: flex;
|
||||
}
|
||||
:is(.admonition-title, summary) p {
|
||||
margin: 0;
|
||||
}
|
||||
html :is(.admonition-title, summary):last-child {
|
||||
margin-bottom: 0;
|
||||
}
|
||||
:is(.admonition-title, summary)::before {
|
||||
position: absolute;
|
||||
top: 0.625em;
|
||||
inset-inline-start: 1.6rem;
|
||||
width: 2rem;
|
||||
height: 2rem;
|
||||
background-color: #448aff;
|
||||
mask-image: url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"></svg>');
|
||||
-webkit-mask-image: url('data:image/svg+xml;charset=utf-8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"></svg>');
|
||||
mask-repeat: no-repeat;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
mask-size: contain;
|
||||
-webkit-mask-size: contain;
|
||||
content: "";
|
||||
}
|
||||
:is(.admonition-title, summary):hover a.admonition-anchor-link {
|
||||
display: initial;
|
||||
}
|
||||
|
||||
details.admonition > summary.admonition-title::after {
|
||||
position: absolute;
|
||||
top: 0.625em;
|
||||
inset-inline-end: 1.6rem;
|
||||
height: 2rem;
|
||||
width: 2rem;
|
||||
background-color: currentcolor;
|
||||
mask-image: var(--md-details-icon);
|
||||
-webkit-mask-image: var(--md-details-icon);
|
||||
mask-repeat: no-repeat;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
mask-size: contain;
|
||||
-webkit-mask-size: contain;
|
||||
content: "";
|
||||
transform: rotate(0deg);
|
||||
transition: transform 0.25s;
|
||||
}
|
||||
details[open].admonition > summary.admonition-title::after {
|
||||
transform: rotate(90deg);
|
||||
}
|
||||
|
||||
:is(.admonition):is(.note) {
|
||||
border-color: #448aff;
|
||||
}
|
||||
|
||||
:is(.note) > :is(.admonition-title, summary) {
|
||||
background-color: rgba(68, 138, 255, 0.1);
|
||||
}
|
||||
:is(.note) > :is(.admonition-title, summary)::before {
|
||||
background-color: #448aff;
|
||||
mask-image: var(--md-admonition-icon--note);
|
||||
-webkit-mask-image: var(--md-admonition-icon--note);
|
||||
mask-repeat: no-repeat;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
mask-size: contain;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
}
|
||||
|
||||
:is(.admonition):is(.abstract, .summary, .tldr) {
|
||||
border-color: #00b0ff;
|
||||
}
|
||||
|
||||
:is(.abstract, .summary, .tldr) > :is(.admonition-title, summary) {
|
||||
background-color: rgba(0, 176, 255, 0.1);
|
||||
}
|
||||
:is(.abstract, .summary, .tldr) > :is(.admonition-title, summary)::before {
|
||||
background-color: #00b0ff;
|
||||
mask-image: var(--md-admonition-icon--abstract);
|
||||
-webkit-mask-image: var(--md-admonition-icon--abstract);
|
||||
mask-repeat: no-repeat;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
mask-size: contain;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
}
|
||||
|
||||
:is(.admonition):is(.info, .todo) {
|
||||
border-color: #00b8d4;
|
||||
}
|
||||
|
||||
:is(.info, .todo) > :is(.admonition-title, summary) {
|
||||
background-color: rgba(0, 184, 212, 0.1);
|
||||
}
|
||||
:is(.info, .todo) > :is(.admonition-title, summary)::before {
|
||||
background-color: #00b8d4;
|
||||
mask-image: var(--md-admonition-icon--info);
|
||||
-webkit-mask-image: var(--md-admonition-icon--info);
|
||||
mask-repeat: no-repeat;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
mask-size: contain;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
}
|
||||
|
||||
:is(.admonition):is(.tip, .hint, .important) {
|
||||
border-color: #00bfa5;
|
||||
}
|
||||
|
||||
:is(.tip, .hint, .important) > :is(.admonition-title, summary) {
|
||||
background-color: rgba(0, 191, 165, 0.1);
|
||||
}
|
||||
:is(.tip, .hint, .important) > :is(.admonition-title, summary)::before {
|
||||
background-color: #00bfa5;
|
||||
mask-image: var(--md-admonition-icon--tip);
|
||||
-webkit-mask-image: var(--md-admonition-icon--tip);
|
||||
mask-repeat: no-repeat;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
mask-size: contain;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
}
|
||||
|
||||
:is(.admonition):is(.success, .check, .done) {
|
||||
border-color: #00c853;
|
||||
}
|
||||
|
||||
:is(.success, .check, .done) > :is(.admonition-title, summary) {
|
||||
background-color: rgba(0, 200, 83, 0.1);
|
||||
}
|
||||
:is(.success, .check, .done) > :is(.admonition-title, summary)::before {
|
||||
background-color: #00c853;
|
||||
mask-image: var(--md-admonition-icon--success);
|
||||
-webkit-mask-image: var(--md-admonition-icon--success);
|
||||
mask-repeat: no-repeat;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
mask-size: contain;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
}
|
||||
|
||||
:is(.admonition):is(.question, .help, .faq) {
|
||||
border-color: #64dd17;
|
||||
}
|
||||
|
||||
:is(.question, .help, .faq) > :is(.admonition-title, summary) {
|
||||
background-color: rgba(100, 221, 23, 0.1);
|
||||
}
|
||||
:is(.question, .help, .faq) > :is(.admonition-title, summary)::before {
|
||||
background-color: #64dd17;
|
||||
mask-image: var(--md-admonition-icon--question);
|
||||
-webkit-mask-image: var(--md-admonition-icon--question);
|
||||
mask-repeat: no-repeat;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
mask-size: contain;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
}
|
||||
|
||||
:is(.admonition):is(.warning, .caution, .attention) {
|
||||
border-color: #ff9100;
|
||||
}
|
||||
|
||||
:is(.warning, .caution, .attention) > :is(.admonition-title, summary) {
|
||||
background-color: rgba(255, 145, 0, 0.1);
|
||||
}
|
||||
:is(.warning, .caution, .attention) > :is(.admonition-title, summary)::before {
|
||||
background-color: #ff9100;
|
||||
mask-image: var(--md-admonition-icon--warning);
|
||||
-webkit-mask-image: var(--md-admonition-icon--warning);
|
||||
mask-repeat: no-repeat;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
mask-size: contain;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
}
|
||||
|
||||
:is(.admonition):is(.failure, .fail, .missing) {
|
||||
border-color: #ff5252;
|
||||
}
|
||||
|
||||
:is(.failure, .fail, .missing) > :is(.admonition-title, summary) {
|
||||
background-color: rgba(255, 82, 82, 0.1);
|
||||
}
|
||||
:is(.failure, .fail, .missing) > :is(.admonition-title, summary)::before {
|
||||
background-color: #ff5252;
|
||||
mask-image: var(--md-admonition-icon--failure);
|
||||
-webkit-mask-image: var(--md-admonition-icon--failure);
|
||||
mask-repeat: no-repeat;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
mask-size: contain;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
}
|
||||
|
||||
:is(.admonition):is(.danger, .error) {
|
||||
border-color: #ff1744;
|
||||
}
|
||||
|
||||
:is(.danger, .error) > :is(.admonition-title, summary) {
|
||||
background-color: rgba(255, 23, 68, 0.1);
|
||||
}
|
||||
:is(.danger, .error) > :is(.admonition-title, summary)::before {
|
||||
background-color: #ff1744;
|
||||
mask-image: var(--md-admonition-icon--danger);
|
||||
-webkit-mask-image: var(--md-admonition-icon--danger);
|
||||
mask-repeat: no-repeat;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
mask-size: contain;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
}
|
||||
|
||||
:is(.admonition):is(.bug) {
|
||||
border-color: #f50057;
|
||||
}
|
||||
|
||||
:is(.bug) > :is(.admonition-title, summary) {
|
||||
background-color: rgba(245, 0, 87, 0.1);
|
||||
}
|
||||
:is(.bug) > :is(.admonition-title, summary)::before {
|
||||
background-color: #f50057;
|
||||
mask-image: var(--md-admonition-icon--bug);
|
||||
-webkit-mask-image: var(--md-admonition-icon--bug);
|
||||
mask-repeat: no-repeat;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
mask-size: contain;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
}
|
||||
|
||||
:is(.admonition):is(.example) {
|
||||
border-color: #7c4dff;
|
||||
}
|
||||
|
||||
:is(.example) > :is(.admonition-title, summary) {
|
||||
background-color: rgba(124, 77, 255, 0.1);
|
||||
}
|
||||
:is(.example) > :is(.admonition-title, summary)::before {
|
||||
background-color: #7c4dff;
|
||||
mask-image: var(--md-admonition-icon--example);
|
||||
-webkit-mask-image: var(--md-admonition-icon--example);
|
||||
mask-repeat: no-repeat;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
mask-size: contain;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
}
|
||||
|
||||
:is(.admonition):is(.quote, .cite) {
|
||||
border-color: #9e9e9e;
|
||||
}
|
||||
|
||||
:is(.quote, .cite) > :is(.admonition-title, summary) {
|
||||
background-color: rgba(158, 158, 158, 0.1);
|
||||
}
|
||||
:is(.quote, .cite) > :is(.admonition-title, summary)::before {
|
||||
background-color: #9e9e9e;
|
||||
mask-image: var(--md-admonition-icon--quote);
|
||||
-webkit-mask-image: var(--md-admonition-icon--quote);
|
||||
mask-repeat: no-repeat;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
mask-size: contain;
|
||||
-webkit-mask-repeat: no-repeat;
|
||||
}
|
||||
|
||||
.navy :is(.admonition) {
|
||||
background-color: var(--sidebar-bg);
|
||||
}
|
||||
|
||||
.ayu :is(.admonition), .coal :is(.admonition) {
|
||||
background-color: var(--theme-hover);
|
||||
}
|
||||
|
||||
.rust :is(.admonition) {
|
||||
background-color: var(--sidebar-bg);
|
||||
color: var(--sidebar-fg);
|
||||
}
|
||||
.rust .admonition-anchor-link:link, .rust .admonition-anchor-link:visited {
|
||||
color: var(--sidebar-fg);
|
||||
}
|
||||
|
|
@ -8,7 +8,11 @@
|
|||
# Quickstart
|
||||
- [Run the beacon node](./quick-start.md)
|
||||
- [Run a validator](./run-a-validator.md)
|
||||
- [Run Kiln](./kiln.md)
|
||||
|
||||
# Downloads
|
||||
- [Binaries](./binaries.md)
|
||||
- [Docker](./docker.md)
|
||||
- [Source code](./build.md)
|
||||
|
||||
# How-to (beacon node)
|
||||
- [Install dependencies](./install.md)
|
||||
|
|
@ -20,19 +24,19 @@
|
|||
# How-to (validator)
|
||||
- [Make a deposit](./deposit.md)
|
||||
- [Import your validator keys](./keys.md)
|
||||
- [Connect your validator to eth2](./connect-eth2.md)
|
||||
- [Set up transaction fee recipients](./suggested-fee-recipient.md)
|
||||
- [Start validating](./connect-eth2.md)
|
||||
- [Graffiti the blockchain](./graffiti.md)
|
||||
- [Set up transaction fee recipient](./suggested-fee-recipient.md)
|
||||
- [Keep an eye on your validator](./keep-an-eye.md)
|
||||
- [Recover / generate keys](./more-keys.md)
|
||||
- [Perform a voluntary exit](./voluntary-exit.md)
|
||||
- [Monitor validator actions](./validator-monitor.md)
|
||||
- [Recover or generate keys](./more-keys.md)
|
||||
- [Add an additional validator](./additional-validator.md)
|
||||
- [Monitor attestation performance](./attestation-performance.md)
|
||||
- [Monitor specific validators](./validator-monitor.md)
|
||||
- [Run a separate validator client](./validator-client.md)
|
||||
|
||||
# How-to (misc)
|
||||
- [Upgrade / downgrade Nimbus](./keep-updated.md)
|
||||
- [Run an Execution layer node](./eth1.md)
|
||||
- [Run an Execution client](./eth1.md)
|
||||
- [Obtain Goerli ETH](./goerli-eth.md)
|
||||
- [Set up a systemd service](./beacon-node-systemd.md)
|
||||
- [Set up log rotation](./log-rotate.md)
|
||||
|
|
@ -40,36 +44,33 @@
|
|||
- [Back up your database](./database-backup.md)
|
||||
- [Set up logging](./logging.md)
|
||||
- [Set up email notifications](./email-notifications.md)
|
||||
- [Graffiti the blockchain](./graffiti.md)
|
||||
- [Optimise for profitability](./profits.md)
|
||||
- [Monitor the health of your node](./health.md)
|
||||
- [Networking](./networking.md)
|
||||
- [Prater testnet](./prater.md)
|
||||
- [Kiln testnet](./kiln.md)
|
||||
|
||||
# Guides
|
||||
- [Grafana and Prometheus](./metrics-pretty-pictures.md)
|
||||
- [Create your own Infura endpoint](./infura-guide.md)
|
||||
- [Migrate from another client](./migration.md)
|
||||
- [Validate with a Raspberry Pi](./pi-guide.md)
|
||||
- [Analyze attestation performance](./attestation-performance.md)
|
||||
|
||||
# Security
|
||||
- [Security Issues / Responsible Disclosure](./security_issues.md)
|
||||
- [Security Audit](./audit.md)
|
||||
- [Reproducible Builds](./distribution_internals.md)
|
||||
|
||||
|
||||
# Downloads
|
||||
- [Download binaries](./binaries.md)
|
||||
- [Download Docker images](./docker.md)
|
||||
|
||||
# Reference
|
||||
- [JSON-RPC API](./api.md)
|
||||
- [REST API](./rest-api.md)
|
||||
- [Keymanager API](./keymanager-api.md)
|
||||
- [Help / Command line options](./options.md)
|
||||
- [Data directory](./data-dir.md)
|
||||
- [Advanced migration options](./migration-options.md)
|
||||
- [Troubleshooting](./troubleshooting.md)
|
||||
- [For developers](./developers.md)
|
||||
- [Contribute](./contribute.md)
|
||||
- [Resources](./resources.md)
|
||||
- [Prater testnet](./prater.md)
|
||||
- [FAQ](./faq.md)
|
||||
- [JSON-RPC API (deprecated)](./api.md)
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
# Add an additional validator
|
||||
|
||||
To add an additional validator, just follow [the same steps](./keys.md) as you did when you added your first.
|
||||
To add an additional validator, [generate a new key](./more-keys.md) then follow [the same steps](./keys.md) as you did when adding your other keys.
|
||||
|
||||
You'll have to restart the beacon node for the changes to take effect.
|
||||
You'll have to [restart](./connect-eth2.md) the beacon node for the changes to take effect.
|
||||
|
||||
> Note that a single Nimbus instance is able to handle multiple validators.
|
||||
```admonish tip
|
||||
A single Nimbus instance is able to handle multiple validators.
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
# JSON-RPC API
|
||||
|
||||
> ⚠️ As of v22.6.0, the Nimbus JSON-RPC interface has been **removed** following an extended deprecation period. You are encouraged to migrate your applications to the [REST API](./rest-api.md).
|
||||
```admonish warning
|
||||
As of v22.6.0, the Nimbus JSON-RPC interface has been **removed** following an extended deprecation period. You are encouraged to migrate your applications to the [REST API](./rest-api.md).
|
||||
```
|
||||
|
||||
The JSON-RPC API pre-dated the REST API and was based on early designs of the beacon chain.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Monitor attestation performance
|
||||
# Analyze attestation performance
|
||||
|
||||
`ncli_db validatorPerf` is an advanced tool that helps you monitor the performance of your validator over time.
|
||||
`ncli_db validatorPerf` is an advanced tool that helps you analyze the performance of your validator over time.
|
||||
|
||||
The tool requires that you [built nimbus from source](./build.md).
|
||||
|
||||
|
|
@ -10,14 +10,14 @@ Make sure you're in the `nimbus-eth2` repository.
|
|||
|
||||
### 1. Build ncli_db
|
||||
The first step is to build `ncli_db`:
|
||||
```
|
||||
```sh
|
||||
make ncli_db
|
||||
```
|
||||
|
||||
### 2. View options
|
||||
|
||||
To view the options available to you, run:
|
||||
```
|
||||
```sh
|
||||
build/ncli_db --help
|
||||
```
|
||||
|
||||
|
|
@ -55,7 +55,7 @@ Use `start-slot` and `slots` to restrict the analysis on a specific block range.
|
|||
### 3. Run
|
||||
|
||||
To view the performance of all validators on Prater so far across the entire block range stored in your database, run:
|
||||
```
|
||||
```sh
|
||||
build/ncli_db validatorPerf \
|
||||
--network=prater \
|
||||
--db=build/data/shared_prater_0/db
|
||||
|
|
@ -74,7 +74,7 @@ validator_index,attestation_hits,attestation_misses,head_attestation_hits,head_a
|
|||
### 4. Adjust to target a specific block range
|
||||
|
||||
To restrict the analysis to the performance between slots 0 and 128, say, run:
|
||||
```
|
||||
```sh
|
||||
build/ncli_db validatorPerf \
|
||||
--network=prater \
|
||||
--db=build/data/shared_prater_0/db \
|
||||
|
|
|
|||
|
|
@ -2,9 +2,9 @@
|
|||
|
||||
## Summary
|
||||
|
||||
Nimbus has undergone an extensive, multi-vendor ([ConsenSys Diligence](https://consensys.net/diligence/), [NCC Group](https://www.nccgroup.com/uk/), and [Trail of Bits](https://www.trailofbits.com/)) security assessment over a period of many months. During that process, we were notified of several issues within the codebase. These issues have been addressed and the overall security of the Nimbus-eth2 software has been drastically improved.
|
||||
Nimbus has undergone an extensive, multi-vendor ([ConsenSys Diligence](https://consensys.net/diligence/), [NCC Group](https://www.nccgroup.com/uk/), and [Trail of Bits](https://www.trailofbits.com/)) security assessment over a period of several months. During that process, we were notified of several issues within the codebase. These issues have been addressed contributing significantly to the overall security of Nimbus and other applications that use its libraries.
|
||||
|
||||
Additionally, as a result of the work done from our security vendors, we are now working to incorporate many new security processes and tooling to improve our ability to find security issues in the future.
|
||||
Additionally, as a result of the work done from our security vendors, we have incoroprated many new security processes and tooling to improve our ability to find security issues in the future.
|
||||
|
||||
For more information on the issues and how they were addressed, the interested reader should direct themselves to the [scoped repositories](https://github.com/status-im/nimbus-eth2/labels?q=audit); all reported issues and their mitigations are open to the public.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,19 +4,21 @@ This page will take you through how to set up a `systemd` service for your beaco
|
|||
|
||||
`systemd` is used in order to have a command or program run when your device boots (i.e. add it as a service). Once this is done, you can start/stop enable/disable from the linux prompt.
|
||||
|
||||
> [`systemd`](https://systemd.io/) is a service manager designed specifically for Linux - it cannot be used on Windows / Mac. You can get more information about systemd [here](https://fedoramagazine.org/what-is-an-init-system/)
|
||||
```admonish note
|
||||
[`systemd`](https://systemd.io/) is a service manager designed specifically for Linux - it cannot be used on Windows / Mac. You can get more information about systemd [here](https://fedoramagazine.org/what-is-an-init-system/)
|
||||
```
|
||||
|
||||
When installing Nimbus via your package manager, a user and service will already have been created for you and you can skip straight to the configuration section.
|
||||
|
||||
### 1. Create a dedicated user
|
||||
|
||||
It is recommended that you create a dedicated user and group for running Nimbus. The same user can also be used for the execution client.
|
||||
We will start by creating a dedicated user and [data directory](./data-dir.md) for Nimbus. The same user can also be used for the execution client.
|
||||
|
||||
```sh
|
||||
# Create the `nimbus` group
|
||||
sudo groupadd nimbus
|
||||
|
||||
# Create the `nimbus` user in the `nimbus` group - chain data will be stored in /var/lib/nimbus
|
||||
# Create the `nimbus` user in the `nimbus` group - we will use /var/lib/nimbus as data directory.
|
||||
sudo useradd -g nimbus nimbus -m -d /var/lib/nimbus
|
||||
```
|
||||
|
||||
|
|
@ -33,7 +35,9 @@ curl -s https://raw.githubusercontent.com/status-im/nimbus-eth2/stable/scripts/p
|
|||
|
||||
The format of service files is documented in the [systemd manual](https://www.freedesktop.org/software/systemd/man/systemd.service.html).
|
||||
|
||||
> ℹ️ Automatic restarts increase the risk that the doppelganger detection fails - set `RestartPreventExitStatus=1031` to prevent this from happening
|
||||
```admonish tip
|
||||
Automatic restarts increase the risk that the doppelganger detection fails - set `RestartPreventExitStatus=1031` to prevent this from happening
|
||||
```
|
||||
|
||||
### 3. Configure your service
|
||||
|
||||
|
|
@ -55,7 +59,9 @@ The service file contains several options for controlling Nimbus. Important opti
|
|||
* `Environment=METRICS_ENABLED`: Metrics are used for monitoring the node - see the [metrics](./metrics-pretty-pictures.md) setup guide
|
||||
* `ExecStart=`: Custom options - see the [options](./options.md) guide
|
||||
|
||||
```admonish note
|
||||
The example assumes Nimbus was installed in `/usr/bin/nimbus_beacon_node` - if you installed Nimbus elsewhere, make sure to update this path.
|
||||
```
|
||||
|
||||
### 4. Notify systemd of the newly added service
|
||||
|
||||
|
|
@ -97,6 +103,19 @@ To rewind logs - by one day, say - run:
|
|||
sudo journalctl -u nimbus_beacon_node.service --since yesterday
|
||||
```
|
||||
|
||||
## Import validator keys
|
||||
|
||||
When using a service, the beacon node is running as a different user - key import must be performed as this user in order for the key files to have the correct permission:
|
||||
|
||||
```
|
||||
# Run import command as the `nimbus` user
|
||||
sudo -u nimbus /usr/bin/nimbus_beacon_node deposit import --data-dir=/var/lib/nimbus/shared_mainnet_0 /path/to/keys
|
||||
```
|
||||
|
||||
```admonish note
|
||||
Make sure to use the same `--data-dir` option as is used in the service file! Some guides use `--data-dir=/var/lib/nimbus` instead.
|
||||
```
|
||||
|
||||
## Running multiple beacon nodes
|
||||
|
||||
You can run multiple beacon nodes on the same machine simply by copying the `.service` file and adjusting the parameters.
|
||||
|
|
|
|||
|
|
@ -16,6 +16,13 @@ Click on the file that corresponds to your OS and architecture, unpack the archi
|
|||
|
||||
To install or upgrade a binary release, simply unpack the downloaded archive in a directory of your choice.
|
||||
|
||||
```sh
|
||||
# Create a directory that can hold the beacon chain data and applications - this should be a fast SSD
|
||||
mkdir -p nimbus-eth2
|
||||
# Unpack the archive into the `nimbus-eth2` directory you just created
|
||||
tar xvf nimbus-eth2_Linux_amd64_22.6.1_2444e994.tar.gz --strip-components 1 -C nimbus-eth2
|
||||
```
|
||||
|
||||
After unpacking, you may wish to [verify the checksum](./checksums.md).
|
||||
|
||||
## Docker
|
||||
|
|
|
|||
|
|
@ -1,8 +1,72 @@
|
|||
# Build the beacon node
|
||||
|
||||
Building the beacon node from source ensures that all hardware-specific optimizations are turned on. The build process itself is simple and fully automated, but may take a few minutes.
|
||||
|
||||
```admonish note
|
||||
Nimbus is written in the [Nim](https://nim-lang.org) programming language - the correct version will automatically be downloaded as part of the build process!
|
||||
```
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before building and running the application, make sure you've installed the [required dependencies](./install.md).
|
||||
```admonish tip
|
||||
If you are planning to use the precompiled binaries, you can skip this section and go straight to the [binaries](./binaries.md)!
|
||||
```
|
||||
|
||||
When building from source, you will need additional build dependencies to be installed:
|
||||
|
||||
- Developer tools (C compiler, Make, Bash, Git)
|
||||
|
||||
Nimbus will build Nim as part of its build process - you do not need to have the Nim compiler installed.
|
||||
|
||||
### Linux
|
||||
|
||||
On common Linux distributions the dependencies can be installed with
|
||||
|
||||
```sh
|
||||
# Debian and Ubuntu
|
||||
sudo apt-get install build-essential git
|
||||
|
||||
# Fedora
|
||||
dnf install @development-tools
|
||||
|
||||
# Archlinux, using an AUR manager
|
||||
yourAURmanager -S base-devel
|
||||
```
|
||||
|
||||
### macOS
|
||||
|
||||
Assuming you use [Homebrew](https://brew.sh/) to manage packages
|
||||
|
||||
```sh
|
||||
brew install cmake
|
||||
```
|
||||
|
||||
### Windows
|
||||
|
||||
To build Nimbus on windows, the Mingw-w64 build environment is recommended.
|
||||
|
||||
Install Mingw-w64 for your architecture using the "[MinGW-W64 Online Installer](https://sourceforge.net/projects/mingw-w64/files/)":
|
||||
|
||||
1. Select your architecture in the setup menu (`i686` on 32-bit, `x86_64` on 64-bit)
|
||||
2. Set threads to `win32`
|
||||
3. Set exceptions to "dwarf" on 32-bit and "seh" on 64-bit.
|
||||
4. Change the installation directory to `C:\mingw-w64` and add it to your system PATH in `"My Computer"/"This PC" -> Properties -> Advanced system settings -> Environment Variables -> Path -> Edit -> New -> C:\mingw-w64\mingw64\bin` (`C:\mingw-w64\mingw32\bin` on 32-bit)
|
||||
|
||||
Install [Git for Windows](https://gitforwindows.org/) and use a "Git Bash" shell to clone and build `nimbus-eth2`.
|
||||
|
||||
> **Note:** If the online installer isn't working you can try installing `Mingw-w64` through [MSYS2](https://www.msys2.org/).
|
||||
|
||||
### Android
|
||||
|
||||
- Install the [Termux](https://termux.com) app from FDroid or the Google Play store
|
||||
- Install a [PRoot](https://wiki.termux.com/wiki/PRoot) of your choice following the instructions for your preferred distribution.
|
||||
Note, the Ubuntu PRoot is known to contain all Nimbus prerequisites compiled on Arm64 architecture (the most common architecture for Android devices).
|
||||
|
||||
Assuming you use Ubuntu PRoot
|
||||
|
||||
```sh
|
||||
apt install build-essential git
|
||||
```
|
||||
|
||||
## Building the node
|
||||
|
||||
|
|
@ -15,10 +79,12 @@ cd nimbus-eth2
|
|||
|
||||
### 2. Run the beacon node build process
|
||||
|
||||
To build the Nimbus beacon node and it's dependencies, run:
|
||||
To build the Nimbus beacon node and its dependencies, run:
|
||||
|
||||
```sh
|
||||
make -j4 nimbus_beacon_node
|
||||
```
|
||||
|
||||
> ℹ️ Omit `-j4` on systems with 4GB of memory or less.
|
||||
```admonish tip
|
||||
Omit `-j4` on systems with 4GB of memory or less.
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,23 +1,23 @@
|
|||
# Start performing validator duties
|
||||
# Start validating
|
||||
|
||||
Once your keys have been [imported](./keys.md), it is time to restart the beacon node and start validating!
|
||||
|
||||
## (Re)start the node
|
||||
|
||||
Press `ctrl-c` to stop the beacon node if it's running, then use the same command as before to run it again:
|
||||
|
||||
**Prater**
|
||||
|
||||
```
|
||||
./run-prater-beacon-node.sh
|
||||
```
|
||||
Press `Ctrl-c` to stop the beacon node if it's running, then use the same command as before to run it again:
|
||||
|
||||
**Mainnet**
|
||||
|
||||
```
|
||||
```sh
|
||||
./run-mainnet-beacon-node.sh
|
||||
```
|
||||
|
||||
**Prater**
|
||||
|
||||
```sh
|
||||
./run-prater-beacon-node.sh
|
||||
```
|
||||
|
||||
## Check the logs
|
||||
|
||||
Your beacon node will launch and connect your validator to the beacon chain network. To check that keys were imported correctly, look for `Local validator attached` in the logs:
|
||||
|
|
@ -27,3 +27,5 @@ INF 2020-11-18 11:20:00.181+01:00 Launching beacon node
|
|||
...
|
||||
NOT 2020-11-18 11:20:02.091+01:00 Local validator attached
|
||||
```
|
||||
|
||||
Congratulations! Your node is now ready to perform validator duties. Depending on when the deposit was made, it may take a while before the first attestation is sent - this is normal.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,105 @@
|
|||
# The data directory
|
||||
|
||||
Nimbus stores all the information it needs to run in a data directory. In this directory, you'll find a database, your validator keys and secrets and several other items.
|
||||
|
||||
When following the installation guide, the chain data will be stored in `build/data` with separate directories for each chain (mainnet, prater, etc).
|
||||
|
||||
```admonish tip
|
||||
The `--data-dir=/path/to/data` allows picking a specific data directory to store the chain - make sure you use the same `--data-dir` option for all beacon node commands!
|
||||
```
|
||||
|
||||
## Contents
|
||||
|
||||
Inside the data directory, you'll find several subdirectories and files containing various information about the node, chain and validators.
|
||||
|
||||
You can examine the contents of the data directory using the `ls -l` command:
|
||||
```sh
|
||||
cd nimbus-eth2
|
||||
ls -l build/data/shared_mainnet_0
|
||||
```
|
||||
|
||||
```sh
|
||||
-rw-r--r-- 1 nimbus nimbus 234 Jul 19 18:18 beacon_node.enr
|
||||
drwx------ 1 nimbus nimbus 22 Jul 19 18:18 db
|
||||
drwx------ 1 nimbus nimbus 196 Jul 19 17:36 secrets
|
||||
drwx------ 1 nimbus nimbus 250 Jul 19 18:18 validators
|
||||
```
|
||||
|
||||
### `db`
|
||||
|
||||
The `db` folder contains historical chain data and information about the latest observed state of the chain. If you remove the `db` folder, the beacon node will have to resync.
|
||||
|
||||
### `secrets` and `validators`
|
||||
|
||||
These two folders contain your validator keys as well as the passwords needed to unlock them when starting the beacon node.
|
||||
|
||||
```admonish warning
|
||||
Be careful not to copy the `secrets` and `validator` folders, leaving them in two locations - instead, always move them to the new location! Using the same validators with two nodes poses a significant slashing risk!
|
||||
```
|
||||
|
||||
## Moving the data directory
|
||||
|
||||
You can move the data directory to another location or computer simply by moving its contents and updating the `--data-dir` option when starting the node.
|
||||
|
||||
## Permissions
|
||||
|
||||
To protect against key loss, Nimbus requires that files and directories be owned by the user running the application. Furthermore, they should not be readable by others.
|
||||
|
||||
It may happen that the wrong permissions are applied, particularly when creating the directories manually.
|
||||
|
||||
The following errors are a sign of this:
|
||||
|
||||
- `Data folder has insecure ACL`
|
||||
- `Data directory has insecure permissions`
|
||||
- `File has insecure permissions`
|
||||
|
||||
Here is how to fix them.
|
||||
|
||||
### Linux/ BSD / MacOS
|
||||
|
||||
Run:
|
||||
|
||||
```sh
|
||||
# Changing ownership to `user:group` for all files/directories in <data-dir>.
|
||||
chown user:group -R <data-dir>
|
||||
# Set permissions to (rwx------ 0700) for all directories starting from <data-dir>
|
||||
find <data-dir> -type d -exec chmod 700 {} \;
|
||||
|
||||
# Set permissions to (rw------- 0600) for all files inside <data-dir>/validators
|
||||
find <data-dir>/validators -type f -exec chmod 0600 {} \;
|
||||
|
||||
# Set permissions to (rw------- 0600) for all files inside <data-dir>/secrets
|
||||
find <data-dir>/secrets -type f -exec chmod 0600 {} \;
|
||||
|
||||
```
|
||||
|
||||
In sum:
|
||||
|
||||
- Directories `<data-dir>`, `<data-dir>/validators`, `<data-dir>/secrets` MUST be owned by user and have `rwx------` or `0700`permissions set.
|
||||
|
||||
- Files stored inside `<data-dir>`, `<data-dir>/validators`, `/secrets` MUST be owned by user and have `rw------` or `0600` permission set.
|
||||
|
||||
### Windows
|
||||
|
||||
From inside `Git Bash`, run:
|
||||
|
||||
```sh
|
||||
# Set permissions for all the directories starting from <data-dir>
|
||||
find <data-dir> -type d -exec icacls {} /inheritance:r /grant:r $USERDOMAIN\\$USERNAME:\(OI\)\(CI\)\(F\) \;
|
||||
|
||||
# Set permissions for all the files inside <data-dir>/validators
|
||||
find <data-dir>/validators -type f -exec icacls {} /inheritance:r /grant:r $USERDOMAIN\\$USERNAME:\(F\) \;
|
||||
|
||||
# Set permissions for all the files inside <data-dir>/secrets
|
||||
find <data-dir>/secrets -type f -exec icacls {} /inheritance:r /grant:r $USERDOMAIN\\$USERNAME:\(F\) \;
|
||||
```
|
||||
|
||||
```admonish note
|
||||
Make sure you run the above from inside `Git Bash`, these commands will not work from inside the standard Windows Command Prompt. If you don't already have a `Git Bash` shell, you'll need to install [Git for Windows](https://gitforwindows.org/).
|
||||
```
|
||||
|
||||
In sum:
|
||||
|
||||
- Directories `<data-dir>`, `<data-dir>/validators`, `<data-dir>/secrets` MUST be owned by user and have permissions set for the user only (OI)(CI)(F). All inherited permissions should be removed.
|
||||
|
||||
- Files which are stored inside <data-dir>, <data-dir>/validators, <data-dir>/secrets MUST be owned by user and have permissions set for the user only (F). All inherited permissions should be removed.
|
||||
|
|
@ -1,5 +1,3 @@
|
|||
# Back up your database
|
||||
|
||||
The best way to do this is to simply copy it over: you'll find it either in `build/data/shared_mainnet_0/db/` (if you're running Prater, `shared_prater_0`) or the directory you supplied to the `--data-dir` argument when you launched Nimbus).
|
||||
|
||||
|
||||
The best way to do this is to simply copy it over: you'll find it either in `build/data/shared_mainnet_0/db/` (if you're running Prater, `shared_prater_0`) or the directory you supplied to the `--data-dir` argument when you launched Nimbus).
|
||||
|
|
|
|||
|
|
@ -1,40 +1,70 @@
|
|||
# Make a deposit for your validator
|
||||
The easiest way to get your deposit in is to follow the Ethereum Foundation's launchpad instructions here:
|
||||
|
||||
**Prater testnet**:
|
||||
[https://prater.launchpad.ethereum.org/](https://prater.launchpad.ethereum.org/)
|
||||
To make a deposit, you will need to generate keys then submit a deposit transaction to the execution chain.
|
||||
|
||||
> Use Prater to stress test / future proof your set up against peak mainnet load. See [here](./prater.md) for all you need to know
|
||||
```admonish tip
|
||||
The process of setting up a validator is also documented at the Ethereum launchpad site:
|
||||
|
||||
**Mainnet**: [https://launchpad.ethereum.org/](https://launchpad.ethereum.org/)
|
||||
* [Mainnet](https://launchpad.ethereum.org/)
|
||||
* [Prater](https://prater.launchpad.ethereum.org/)
|
||||
```
|
||||
|
||||
> ⚠️ If you are making a mainnet deposit make sure you verify that the deposit contract you are interacting with is the correct one.
|
||||
>
|
||||
> You should verify that the address is indeed: [0x00000000219ab540356cBB839Cbe05303d7705Fa](https://etherscan.io/address/0x00000000219ab540356cBB839Cbe05303d7705Fa)
|
||||
```admonish tip
|
||||
Use Prater to stress test / future proof your set up against peak mainnet load. See [here](./prater.md) for all you need to know
|
||||
```
|
||||
|
||||
We won't elaborate on each individual step here, since they are well explained on the site itself. However, there are two points of note:
|
||||
## Download the deposit tool
|
||||
|
||||
## 1. Execution client / web3 connection
|
||||
|
||||
Start by downloading and unpacking the [deposit tool](https://github.com/ethereum/staking-deposit-cli/releases/latest) provided by the Ethereum Foundation:
|
||||
|
||||
In the `Select Client` section you'll first be asked to choose an execution client. You need to run an execution client in order to perform your validator duties.
|
||||
```sh
|
||||
# Enter the nimbus folder we previously created
|
||||
cd nimbus-eth2
|
||||
|
||||
|
||||
# Make sure to get the latest version from the download page
|
||||
wget https://github.com/ethereum/staking-deposit-cli/releases/download/v2.2.0/staking_deposit-cli-9ab0b05-linux-amd64.tar.gz
|
||||
|
||||
*If you've followed the book up to this point, you should already have an execution client up and running.*
|
||||
# Unpack the archive
|
||||
tar xvf staking_deposit-cli-9ab0b05-linux-amd64.tar.gz --strip-components 2
|
||||
```
|
||||
|
||||
## 2. Block explorer
|
||||
Once you've sent off your transaction, you should see the following screen.
|
||||
## Generate keys
|
||||
|
||||
|
||||
```admonish tip
|
||||
You can increase the security of this process by downloading a [Live linux image](https://ubuntu.com/tutorials/try-ubuntu-before-you-install). To do so, copy `deposit` to a USB stick, boot into the live image, and run the tool from inside the image. Make sure you **don't** enable Wifi and unplug any Ethernet cables when using this process.
|
||||
```
|
||||
|
||||
The deposit tool generates a seed phrase, and uses this to create validator and withdrawal keys.
|
||||
|
||||
```admonish warn
|
||||
If you lose you seed phrase and your withdrawal key, your funds will be lost forever!
|
||||
```
|
||||
|
||||
We recommend you click on `Beaconchain`. This will open up a window that allows you to keep track of your validator's status.
|
||||
**Mainnet**
|
||||
|
||||
|
||||
```sh
|
||||
# Run the deposit tool and follow the instructions on screen
|
||||
./deposit new-mnemonic --chain mainnet
|
||||
```
|
||||
|
||||
It's a good idea to bookmark this page.
|
||||
**Prater**
|
||||
```sh
|
||||
# Run the deposit tool and follow the instructions on screen
|
||||
./deposit new-mnemonic --chain prater
|
||||
```
|
||||
|
||||
## Expected waiting time (the queue)
|
||||
## Make the deposit
|
||||
|
||||
Once created, the keys are used to create a deposit transaction on the Ethereum execution chain. Follow the instructions at https://launchpad.ethereum.org/en/upload-deposit-data to upload the deposit data.
|
||||
|
||||
```admonish warning
|
||||
If you are making a mainnet deposit make sure you verify that the deposit contract you are interacting with is the correct one.
|
||||
|
||||
You should verify that the address is indeed: [0x00000000219ab540356cBB839Cbe05303d7705Fa](https://etherscan.io/address/0x00000000219ab540356cBB839Cbe05303d7705Fa)
|
||||
```
|
||||
|
||||
```admonish info
|
||||
Once you send off your transaction(s), your validator will be put in a queue based on deposit time. Getting through the queue may take a few hours or days (assuming the chain is finalising). No validators are accepted into the validator set while the chain isn't finalising. The `Pending Validators` metric on the [beaconcha.in](https://beaconcha.in/) will give you the size of the queue.
|
||||
```
|
||||
|
||||
With the keys created, you're ready to perform the [key import](./keys.md).
|
||||
|
|
|
|||
|
|
@ -6,13 +6,19 @@ Nimbus has been tested all major execution clients - see the [execution client c
|
|||
|
||||
The `--web3-url` option informs the beacon node how to connect to the execution client - both `http://` and `ws://` URL:s are supported.
|
||||
|
||||
Assuming the execution client is running on the same computer as the beacon node:
|
||||
You can pass one or more `--web3-url` parameters to the node. Any additional web3 url:s will be used for backup, should the first client become unavailable:
|
||||
|
||||
```sh
|
||||
./run-mainnet-beacon-node.sh --web3-url=ws://127.0.0.1:8546
|
||||
./run-mainnet-beacon-node.sh --web3-url=ws://127.0.0.1:8546 --web3-url=http://other:8545
|
||||
```
|
||||
|
||||
> ⚠️ You need to run your own execution client after [the merge](./merge.md) - relying on third-party services such as Infura, Alchemy and Pocket will not be possible.
|
||||
```admonish warn
|
||||
You need to run your own execution client after [the merge](./merge.md) - relying on third-party services such as Infura, Alchemy and Pocket will not be possible.
|
||||
```
|
||||
|
||||
```admonish note
|
||||
Syncing an execution client may take hours or even days, depending on your hardware!
|
||||
```
|
||||
|
||||
## Nimbus
|
||||
|
||||
|
|
@ -50,11 +56,6 @@ Let it sync - Geth uses snap sync by default. It may take anywhere between a few
|
|||
You'll know Geth has finished syncing, when you start seeing logs that look like the following:
|
||||
|
||||
```
|
||||
INFO [05-29|01:14:53] Imported new chain segment blocks=1 txs=2 mgas=0.043 elapsed=6.573ms mgasps=6.606 number=3785437 hash=f72595…c13f23
|
||||
INFO [05-29|01:15:08] Imported new chain segment blocks=1 txs=3 mgas=0.067 elapsed=7.639ms mgasps=8.731 number=3785441 hash=be7e55…a8c1c7
|
||||
INFO [05-29|01:15:25] Imported new chain segment blocks=1 txs=21 mgas=1.084 elapsed=33.610ms mgasps=32.264 number=3785442 hash=fd54be…79b047
|
||||
INFO [05-29|01:15:42] Imported new chain segment blocks=1 txs=26 mgas=0.900 elapsed=26.209ms mgasps=34.335 number=3785443 hash=2504ff…119622
|
||||
INFO [05-29|01:15:59] Imported new chain segment blocks=1 txs=12 mgas=1.228 elapsed=22.693ms mgasps=54.122 number=3785444 hash=951dfe…a2a083
|
||||
INFO [05-29|01:16:05] Imported new chain segment blocks=1 txs=3 mgas=0.065 elapsed=5.885ms mgasps=11.038 number=3785445 hash=553d9e…fc4547
|
||||
INFO [05-29|01:16:10] Imported new chain segment blocks=1 txs=0 mgas=0.000 elapsed=5.447ms mgasps=0.000 number=3785446 hash=5e3e7d…bd4afd
|
||||
INFO [05-29|01:16:10] Imported new chain segment blocks=1 txs=1 mgas=0.021 elapsed=7.382ms mgasps=2.845 number=3785447 hash=39986c…dd2a01
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
## General
|
||||
|
||||
### How do I check which version of Nimbus I'm currently running?
|
||||
### Which version of Nimbus am I running?
|
||||
|
||||
You can check the version through a number of methods:
|
||||
|
||||
|
|
@ -22,7 +22,7 @@ curl -s http://localhost:9100/eth/v1/node/version
|
|||
The metrics server is disabled by default: enable it by passing `--metrics` to the run command:
|
||||
|
||||
```sh
|
||||
./run-mainnet-beacon-node.sh --metrics ...
|
||||
build/nimbus_beacon_node --metrics ...
|
||||
```
|
||||
|
||||
### Why is the REST server not working?
|
||||
|
|
@ -30,7 +30,7 @@ The metrics server is disabled by default: enable it by passing `--metrics` to t
|
|||
The REST server is disabled by default: enable it by passing `--rest` to the run command:
|
||||
|
||||
```sh
|
||||
./run-mainnet-beacon-node.sh --metrics ...
|
||||
build/nimbus_beacon_node --rest ...
|
||||
```
|
||||
|
||||
### Why does my validator miss two epochs of attestations after restarting?
|
||||
|
|
@ -55,7 +55,9 @@ To stress test it, add `--subscribe-all-subnets` to the [beacon node options](./
|
|||
|
||||
To add an additional validator, follow [the same steps](./keys.md) as you did when you added your first. You'll have to restart the beacon node for the changes to take effect.
|
||||
|
||||
> Note that a single Nimbus instance is able to handle multiple validators.
|
||||
```admonish note
|
||||
Note that a single Nimbus instance is able to handle multiple validators.
|
||||
```
|
||||
|
||||
## Networking
|
||||
|
||||
|
|
@ -89,61 +91,13 @@ The following errors are a sign of this:
|
|||
- `Data directory has insecure permissions`
|
||||
- `File has insecure permissions`
|
||||
|
||||
Here is how to fix them.
|
||||
|
||||
### Linux/ BSD / MacOS
|
||||
|
||||
Run:
|
||||
|
||||
```sh
|
||||
# Changing ownership to `user:group` for all files/directories in <data-dir>.
|
||||
chown user:group -R <data-dir>
|
||||
# Set permissions to (rwx------ 0700) for all directories starting from <data-dir>
|
||||
find <data-dir> -type d -exec chmod 700 {} \;
|
||||
|
||||
# Set permissions to (rw------- 0600) for all files inside <data-dir>/validators
|
||||
find <data-dir>/validators -type f -exec chmod 0600 {} \;
|
||||
|
||||
# Set permissions to (rw------- 0600) for all files inside <data-dir>/secrets
|
||||
find <data-dir>/secrets -type f -exec chmod 0600 {} \;
|
||||
|
||||
```
|
||||
|
||||
In sum:
|
||||
|
||||
- Directories `<data-dir>`, `<data-dir>/validators`, `<data-dir>/secrets` MUST be owned by user and have `rwx------` or `0700`permissions set.
|
||||
|
||||
- Files stored inside `<data-dir>`, `<data-dir>/validators`, `/secrets` MUST be owned by user and have `rw------` or `0600` permission set.
|
||||
|
||||
### Windows
|
||||
|
||||
From inside `Git Bash`, run:
|
||||
|
||||
```sh
|
||||
# Set permissions for all the directories starting from <data-dir>
|
||||
find <data-dir> -type d -exec icacls {} /inheritance:r /grant:r $USERDOMAIN\\$USERNAME:\(OI\)\(CI\)\(F\) \;
|
||||
|
||||
# Set permissions for all the files inside <data-dir>/validators
|
||||
find <data-dir>/validators -type f -exec icacls {} /inheritance:r /grant:r $USERDOMAIN\\$USERNAME:\(F\) \;
|
||||
|
||||
# Set permissions for all the files inside <data-dir>/secrets
|
||||
find <data-dir>/secrets -type f -exec icacls {} /inheritance:r /grant:r $USERDOMAIN\\$USERNAME:\(F\) \;
|
||||
```
|
||||
|
||||
> **N.B.** Make sure you run the above from inside `Git Bash`, these commands will not work from inside the standard Windows Command Prompt. If you don't already have a `Git Bash` shell, you'll need to install [Git for Windows](https://gitforwindows.org/).
|
||||
|
||||
In sum:
|
||||
|
||||
- Directories `<data-dir>`, `<data-dir>/validators`, `<data-dir>/secrets` MUST be owned by user and have permissions set for the user only (OI)(CI)(F). All inherited permissions should be removed.
|
||||
|
||||
- Files which are stored inside <data-dir>, <data-dir>/validators, <data-dir>/secrets MUST be owned by user and have permissions set for the user only (F). All inherited permissions should be removed.
|
||||
|
||||
See the [data directory](./data-dir.md#permissions) page for instructions on how to fix this
|
||||
|
||||
## Validating
|
||||
|
||||
### What exactly is a validator?
|
||||
|
||||
A validator is an entity that participates in the consensus of the Ethereum protocol.
|
||||
A validator is an entity that participates in the consensus of the Ethereum protocol, and has staked 32 ETH to do so.
|
||||
|
||||
Or in plain english, a human running a computer process. This process proposes and vouches for new blocks to be added to the blockchain.
|
||||
|
||||
|
|
@ -194,7 +148,7 @@ At the other end of the spectrum, if your balance is closer to 31 ETH, it's prob
|
|||
|
||||
### When can I withdraw my funds, and what's the difference between exiting and withdrawing?
|
||||
|
||||
You can signal your intent to stop validating by signing a voluntary exit message with your validator.
|
||||
You can signal your intent to stop validating by signing a [voluntary exit](./voluntary-exit.md) message with your validator.
|
||||
|
||||
However, bear in mind that in Phase 0, once you've exited, there's no going back.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,15 +2,14 @@
|
|||
|
||||
You can use your node's graffiti flag to make your mark on history and forever engrave some words of your choice into an Ethereum block. You will be able to see it using the block explorer.
|
||||
|
||||
To do so on **Prater**, run:
|
||||
**Mainnet**
|
||||
|
||||
```
|
||||
./run-prater-beacon-node.sh --graffiti="<YOUR_WORDS>"
|
||||
```
|
||||
|
||||
To do so on **Mainnet**, run:
|
||||
|
||||
```
|
||||
```sh
|
||||
./run-mainnet-beacon-node.sh --graffiti="<YOUR_WORDS>"
|
||||
```
|
||||
|
||||
**Prater**
|
||||
```sh
|
||||
./run-prater-beacon-node.sh --graffiti="<YOUR_WORDS>"
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ See [here](./networking.md) for our networking related tips and tricks.
|
|||
|
||||
## Keep track of your attestation effectiveness
|
||||
|
||||
Attestation effectiveness is a metric that directly affects your validator rewards. In simple terms, an attestation is more valuable the sooner it is put into a block and included in the chain.
|
||||
Attestation effectiveness is a metric that directly affects your validator rewards. In simple terms, an attestation is more valuable the sooner it is put into a block and included in the chain.
|
||||
|
||||
This interval is called the *inclusion distance* of an attestation. The smaller it is, the more profitable your validator will be. For a deeper understanding we highly recommend reading [Attestant's wonderful blog post](https://www.attestant.io/posts/defining-attestation-effectiveness/#:~:text=Stakers%20looking%20to%20maximize%20their,provide%20clear%20metrics%20for%20performance.) on the matter.
|
||||
|
||||
|
|
@ -30,16 +30,5 @@ sudo apt install vnstat
|
|||
|
||||
To run it:
|
||||
|
||||
*TBC -See [here](https://github.com/jclapis/rp-pi-guide/blob/main/Native.md#monitoring-your-pis-performance) for more*
|
||||
*TBC -See [here](https://docs.rocketpool.net/guides/node/performance.html#beaconcha-in-website-using-the-beacon-chain-as-a-metric-source) for more*
|
||||
|
||||
## Keep an eye on the logs
|
||||
|
||||
## Keep an eye on the metrics
|
||||
|
||||
## Grafana
|
||||
|
||||
## Relevant REST API queries
|
||||
|
||||
## External tools
|
||||
|
||||
### beaconchain
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Check that your machine matches the [minimal system requirements](./hardware.md)
|
|||
|
||||
## Time
|
||||
|
||||
The beacon chain relies on your computer having the correct time set (plus or minus 0.5 seconds). It is important that you periodically synchronize the time with an NTP server.
|
||||
The beacon chain relies on your computer having the correct time set (±0.5 seconds). It is important that you periodically synchronize the time with an NTP server.
|
||||
|
||||
If the above sounds like latin to you, don't worry. You should be fine as long as you haven't messed around with the time and date settings on your computer (they should be set automatically).
|
||||
|
||||
|
|
@ -27,72 +27,14 @@ To install it:
|
|||
sudo apt-get install -y chrony
|
||||
|
||||
# Fedora
|
||||
dnf install chrony
|
||||
sudo dnf install chrony
|
||||
|
||||
# Archlinux, using an AUR manager
|
||||
yourAURmanager chrony
|
||||
```
|
||||
|
||||
Once installed, the default configuration works well.
|
||||
## Execution client
|
||||
|
||||
At a minimum, you should run an NTP client (such as chrony) on the server. Note that most operating systems (including macOS') automatically sync with NTP by default.
|
||||
To run a beacon node, you need to have access to an execution client exposing the web3 API - throughout, we'll assume an execution client is running on the same machine as the beacon node, but this is not required.
|
||||
|
||||
## Building from source
|
||||
|
||||
> ℹ️ If you are planning to use the precompiled binaries, you can skip this section and go straight to the [binaries](./binaries.md)!
|
||||
|
||||
When building from source, you will need additional build dependencies to be installed:
|
||||
|
||||
- Developer tools (C compiler, Make, Bash, Git)
|
||||
|
||||
Nimbus will build Nim as part of its build process - you do not need to have the Nim compiler installed.
|
||||
|
||||
### Linux
|
||||
|
||||
On common Linux distributions the dependencies can be installed with
|
||||
|
||||
```sh
|
||||
# Debian and Ubuntu
|
||||
sudo apt-get install build-essential git
|
||||
|
||||
# Fedora
|
||||
dnf install @development-tools
|
||||
|
||||
# Archlinux, using an AUR manager
|
||||
yourAURmanager -S base-devel
|
||||
```
|
||||
|
||||
### macOS
|
||||
|
||||
Assuming you use [Homebrew](https://brew.sh/) to manage packages
|
||||
|
||||
```sh
|
||||
brew install cmake
|
||||
```
|
||||
|
||||
### Windows
|
||||
|
||||
To build Nimbus on windows, the Mingw-w64 build environment is recommended.
|
||||
|
||||
Install Mingw-w64 for your architecture using the "[MinGW-W64 Online Installer](https://sourceforge.net/projects/mingw-w64/files/)":
|
||||
|
||||
1. Select your architecture in the setup menu (`i686` on 32-bit, `x86_64` on 64-bit)
|
||||
2. Set threads to `win32`
|
||||
3. Set exceptions to "dwarf" on 32-bit and "seh" on 64-bit.
|
||||
4. Change the installation directory to `C:\mingw-w64` and add it to your system PATH in `"My Computer"/"This PC" -> Properties -> Advanced system settings -> Environment Variables -> Path -> Edit -> New -> C:\mingw-w64\mingw64\bin` (`C:\mingw-w64\mingw32\bin` on 32-bit)
|
||||
|
||||
Install [Git for Windows](https://gitforwindows.org/) and use a "Git Bash" shell to clone and build `nimbus-eth2`.
|
||||
|
||||
> **Note:** If the online installer isn't working you can try installing `Mingw-w64` through [MSYS2](https://www.msys2.org/).
|
||||
|
||||
### Android
|
||||
|
||||
- Install the [Termux](https://termux.com) app from FDroid or the Google Play store
|
||||
- Install a [PRoot](https://wiki.termux.com/wiki/PRoot) of your choice following the instructions for your preferred distribution.
|
||||
Note, the Ubuntu PRoot is known to contain all Nimbus prerequisites compiled on Arm64 architecture (the most common architecture for Android devices).
|
||||
|
||||
Assuming you use Ubuntu PRoot
|
||||
|
||||
```sh
|
||||
apt install build-essential git
|
||||
```
|
||||
See the [execution client](./eth1.md) guide for further instructions!
|
||||
|
|
|
|||
|
|
@ -1,10 +1,14 @@
|
|||
# The Nimbus book
|
||||
|
||||
*This book focuses on our consensus layer client. If you're eager to get started, check out our [quickstart guide](./quick-start.md).*
|
||||
```admonish
|
||||
If you're eager to get started, check out our [quickstart guide](./quick-start.md).
|
||||
```
|
||||
|
||||
Nimbus is a client implementation for both the `consensus layer` (eth2) and `execution layer` (eth1) that strives to be as [lightweight as possible](https://our.status.im/ethereum-is-green/) in terms of resources used. This allows it to perform well on embedded systems, resource-restricted devices -- including Raspberry Pis and mobile devices.
|
||||
Nimbus is an implementation of both the `consensus layer` (eth2) and `execution layer` (eth1) that is [lightweight](https://our.status.im/ethereum-is-green/), [secure](./audit.md) and easy to use. This book describes the consensus layer client in particular.
|
||||
|
||||
However, resource-restricted hardware is not the only thing Nimbus is good for. Its low resource consumption makes it an excellent choice to pair with an [execution client](./eth1) and makes it easy to run together with other workloads on your server, lowering the total cost.
|
||||
Its efficiency and low resource consumption allows it to perform well on embedded systems, resource-restricted devices -- including Raspberry Pis and mobile devices.
|
||||
|
||||
Being efficient also makes it an excellent companion for [execution clients](./eth1.md) and other nodes running on your server, lowering the overall hardware requirements and therefore the total cost.
|
||||
|
||||
</br>
|
||||
|
||||
|
|
@ -14,10 +18,11 @@ However, resource-restricted hardware is not the only thing Nimbus is good for.
|
|||
|
||||
This book explains the ways in which you can use Nimbus to either monitor the beacon chain or become a fully-fledged validator.
|
||||
|
||||
> **N.B.** The reality is that we are very early in the eth2 validating life cycle. Validating is not for everyone yet, and it comes with both risks and responsibilities. It isn't a particularly easy way to make money. You'll need to put effort into updating your software, researching hard-forks, having a robust setup... . As such, you should only stake if you are genuinely interested in securing the protocol.
|
||||
|
||||
> ⚠️ The Merge is happening soon! Bookmark our [merge readiness](./merge.md) page to stay on top of how you need to prepare.
|
||||
```admonish tip
|
||||
[The Merge](https://ethereum.org/en/upgrades/merge/) is happening soon! Bookmark our [merge readiness](./merge.md) page to stay on top of how you need to prepare.
|
||||
```
|
||||
|
||||
> **N.B.** Staking and becoming a validator on Ethereum requires 32 ETH, a stable high-speed internet connection and an always-on server. Before staking, make sure that you understand the requirements and practice setting up a validator on a testnet. [Pooled staking](https://ethereum.org/en/staking/pools/) and [Staking as a service](https://ethereum.org/en/staking/saas/) are alternative ways to stake in the network. You can also run a Nimbus node without staking.
|
||||
|
||||
## Helpful resources
|
||||
|
||||
|
|
@ -27,7 +32,6 @@ This book explains the ways in which you can use Nimbus to either monitor the be
|
|||
- [Vitalik's annotated spec](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md)
|
||||
- [Danny Ryan's annotated spec](https://notes.ethereum.org/@djrtwo/Bkn3zpwxB)
|
||||
|
||||
|
||||
### Get in touch
|
||||
|
||||
Need help with anything? Join us on [Status](https://join.status.im/nimbus-general) and [Discord](https://discord.gg/9dWwPnG).
|
||||
|
|
@ -40,14 +44,9 @@ If you'd like to contribute to Nimbus development:
|
|||
* We're also listed on [GitCoin](https://gitcoin.co/grants/137/nimbus-2)
|
||||
|
||||
### Stay updated
|
||||
Subscribe to our newsletter [here](https://subscribe.nimbus.guide/).
|
||||
|
||||
Subscribe to our newsletter [here](https://subscribe.nimbus.guide/).
|
||||
|
||||
### Disclaimer
|
||||
|
||||
This documentation assumes Nimbus is in its ideal state. The project is still under active development. Please submit a [Github issue](https://github.com/status-im/nimbus-eth2/issues) if you come across a problem.
|
||||
|
||||
<!-- > > > TODO:
|
||||
|
||||
1. fill up the gitbook content
|
||||
2. write questions in the faq.md page -->
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
# Keep an eye on your validator
|
||||
|
||||
|
||||
The best way to keep track of your validator's status is using the `beaconcha.in` explorer (click on the orange magnifying glass at the very top and paste in your validator's public key):
|
||||
|
||||
- **Testnet:** [prater.beaconcha.in](https://prater.beaconcha.in)
|
||||
|
|
@ -8,7 +7,6 @@ The best way to keep track of your validator's status is using the `beaconcha.in
|
|||
|
||||
If you deposit after the [genesis](https://hackmd.io/@benjaminion/genesis) state was decided, your validator(s) will be put in a queue based on deposit time, and will slowly be inducted into the validator set after genesis. Getting through the queue may take a few hours or a day or so.
|
||||
|
||||
|
||||
You can even create an account ([testnet link](https://prater.beaconcha.in/register), [mainnet link](https://beaconcha.in/register)) to add alerts and keep track of your validator's performance ([testnet link](https://prater.beaconcha.in/dashboard), [mainnet link](https://beaconcha.in/dashboard)).
|
||||
|
||||
-------------------------------
|
||||
|
|
@ -17,18 +15,6 @@ You can even create an account ([testnet link](https://prater.beaconcha.in/regis
|
|||
|
||||
On startup, you should see a log message that reads `Local validator attached`. This has a `pubkey` field which should the public key of your validator.
|
||||
|
||||
## Check your IP address
|
||||
|
||||
Check that Nimbus has recognised your external IP properly. To do this, look at the end of the first log line:
|
||||
|
||||
```
|
||||
Starting discovery node","topics":"discv5","tid":2665484,"file":"protocol.nim:802","node":"b9*ee2235:<IP address>:9000"
|
||||
```
|
||||
|
||||
`<IP address>` should match your external IP (the IP by which you can be reached from the internet).
|
||||
|
||||
Note that the port number is displayed directly after the IP -- in the above case `9000`. This is the port that should be opened and mapped.
|
||||
|
||||
## Keep track of your syncing progress
|
||||
|
||||
To keep track of your sync progress, pay attention to the `Slot start` messages in your logs:
|
||||
|
|
|
|||
|
|
@ -2,11 +2,15 @@
|
|||
|
||||
Make sure you stay on the lookout for any critical updates to Nimbus. This best way to do so is through the **announcements** channel on our [discord](https://discord.com/invite/XRxWahP). The release page can be found [here](https://github.com/status-im/nimbus-eth2/releases/).
|
||||
|
||||
> **Note:** If your beacon node is already running, you'll need to restart it for the changes to take effect.
|
||||
```admonish note
|
||||
If your beacon node is already running, you'll need to restart it for the changes to take effect.
|
||||
```
|
||||
|
||||
To update to the latest version, either download the binary or compile the beacon node release (see below).
|
||||
|
||||
> **Tip:** To check which version of Nimbus you're currently running, run `build/nimbus_beacon_node --version`
|
||||
```admonish tip
|
||||
To check which version of Nimbus you're currently running, run `build/nimbus_beacon_node --version`
|
||||
```
|
||||
|
||||
## Binaries
|
||||
|
||||
|
|
@ -14,9 +18,9 @@ Open the latest [Nimbus release](https://github.com/status-im/nimbus-eth2/releas
|
|||
|
||||
Once downloaded, unpack the binaries in the same folder as your current version, overwriting the existing files.
|
||||
|
||||
```
|
||||
```sh
|
||||
wget <insert download link here>
|
||||
tar -xzf nimbus-eth2_Linux_arm64v8*.tar.gz -C nimbus-eth2
|
||||
tar -xzf nimbus-eth2_Linux_arm64v8*.tar.gz --strip-components 1 -C nimbus-eth2
|
||||
rm nimbus-eth2_Linux_arm64v8*.tar.gz
|
||||
```
|
||||
|
||||
|
|
@ -26,21 +30,22 @@ Upgrading Nimbus when built from source is similar to the installation process.
|
|||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
```sh
|
||||
# Download the updated source code
|
||||
git pull && make update
|
||||
```
|
||||
|
||||
Followed by:
|
||||
|
||||
```
|
||||
```sh
|
||||
make -j4 nimbus_beacon_node
|
||||
```
|
||||
|
||||
Now, restart your node.
|
||||
|
||||
> **Tip:** In order to minimise downtime, we recommend updating and [rebuilding](./build.md) the beacon node **before restarting**.
|
||||
|
||||
```admonish tip
|
||||
In order to minimise downtime, we recommend updating and [rebuilding](./build.md) the beacon node **before restarting**.
|
||||
```
|
||||
|
||||
## Urgency guidelines
|
||||
|
||||
|
|
@ -58,29 +63,32 @@ As of `v1.4.0`, releases are marked with the following tags:
|
|||
*Occassionally you may need to either upgrade or downgrade to a specific version of Nimbus.*
|
||||
|
||||
To pull a specific version of Nimbus (e.g. `v1.3.0`), run:
|
||||
```
|
||||
```sh
|
||||
git checkout v1.3.0 && make update
|
||||
```
|
||||
|
||||
Followed by:
|
||||
|
||||
```
|
||||
```sh
|
||||
make nimbus_beacon_node
|
||||
```
|
||||
|
||||
Now, restart your node.
|
||||
|
||||
> **Note:** Alternatively, you can grab the appropriate binary release - create a backup of your `build` folder, then download the appropriate binary from here: [https://github.com/status-im/nimbus-eth2/releases/tag/v1.3.0](https://github.com/status-im/nimbus-eth2/releases/tag/v1.3.0)
|
||||
```admonish note
|
||||
Alternatively, you can grab the appropriate binary release - create a backup of your `build` folder, then download the appropriate binary from here: [https://github.com/status-im/nimbus-eth2/releases/tag/v1.3.0](https://github.com/status-im/nimbus-eth2/releases/tag/v1.3.0)
|
||||
```
|
||||
|
||||
### Go back to stable
|
||||
|
||||
If you need to go back to the latest (stable) version, run:
|
||||
```
|
||||
```sh
|
||||
git checkout stable && make update
|
||||
```
|
||||
|
||||
Followed by
|
||||
|
||||
```
|
||||
```sh
|
||||
make nimbus_beacon_node
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
# Keymanager API
|
||||
|
||||
> ⚠️ This feature is currently in BETA - we are still testing it and implementation details may change in response to community feedback. **We strongly advise against using it on mainnet** - your validators may get slashed
|
||||
```admonish warning
|
||||
This feature is currently in BETA - we are still testing it and implementation details may change in response to community feedback. **We strongly advise against using it on mainnet** - your validators may get slashed
|
||||
```
|
||||
|
||||
The standardized [Keymanager API](https://ethereum.github.io/keymanager-APIs/) can be used to add, remove, or [migrate](./migration.md) validators on the fly while the beacon node is running.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,53 +1,67 @@
|
|||
# Import your validator keys into Nimbus
|
||||
|
||||
To import your signing key(s) into Nimbus, copy the `validator_keys` directory -- the directory that was created for you when you generated your keys using the [command line app](https://github.com/ethereum/eth2.0-deposit-cli) -- into `nimbus-eth2`. Then run:
|
||||
|
||||
**Prater**
|
||||
```sh
|
||||
build/nimbus_beacon_node deposits import --data-dir=build/data/shared_prater_0
|
||||
```admonish tip
|
||||
`systemd` service file users will want to follow the [service file guide](./beacon-node-systemd.md#import-validator-keys) instead!
|
||||
```
|
||||
|
||||
Having followed the [deposit](./deposit.md) guide, you will have a `validator_keys` folder containing several `.json` files in the `nimbus-eth2` directory.
|
||||
|
||||
|
||||
We'll import the signing key of each validator to the [data directory](./data-dir.md) using the `deposits import` command:
|
||||
|
||||
**Mainnet**
|
||||
```sh
|
||||
build/nimbus_beacon_node deposits import --data-dir=build/data/shared_mainnet_0
|
||||
```
|
||||
**Prater**
|
||||
```sh
|
||||
build/nimbus_beacon_node deposits import --data-dir=build/data/shared_prater_0
|
||||
```
|
||||
|
||||
>**Note:** You can also specify a different path to your `validator_keys` directory as follows:
|
||||
>
|
||||
>*Prater*
|
||||
>```
|
||||
>build/nimbus_beacon_node deposits import \
|
||||
> --data-dir=build/data/shared_prater_0 "<YOUR VALIDATOR KEYS DIRECTORY>"
|
||||
> ```
|
||||
>
|
||||
> *Mainnet*
|
||||
> ```
|
||||
>build/nimbus_beacon_node deposits import \
|
||||
> --data-dir=build/data/shared_mainnet_0 "<YOUR VALIDATOR KEYS DIRECTORY>"
|
||||
>```
|
||||
>
|
||||
> Replacing `<YOUR VALIDATOR KEYS DIRECTORY>` with the full pathname of the `validator_keys` directory that was created when you generated your keys using the [command line app](https://github.com/ethereum/eth2.0-deposit-cli/releases/).
|
||||
```admonish note
|
||||
You'll be asked to enter the password you created to encrypt your keystore(s).
|
||||
```
|
||||
|
||||
> **Tip:** You can run `pwd` in your `validator_keys` directory to print the full pathname to the console (if you're on Windows, run `cd` instead).
|
||||
If your `validator_keys` folder is stored elsewhere, you can pass its location to the import command:
|
||||
|
||||
**Mainnet**
|
||||
```sh
|
||||
build/nimbus_beacon_node deposits import \
|
||||
--data-dir=build/data/shared_mainnet_0 \
|
||||
/path/to/keys
|
||||
```
|
||||
|
||||
You'll be asked to enter the password you created to encrypt your keystore(s).
|
||||
**Prater**
|
||||
```sh
|
||||
build/nimbus_beacon_node deposits import \
|
||||
--data-dir=build/data/shared_prater_0 \
|
||||
/path/to/keys
|
||||
```
|
||||
|
||||
Don't worry, this is entirely normal. Your validator client needs both your signing keystore(s) and the password encrypting it to import your [key](https://blog.ethereum.org/2020/05/21/keys/) (since it needs to decrypt the keystore in order to be able to use it to sign on your behalf).
|
||||
Replacing `/path/to/keys` with the full pathname of where the `validator_keys` directory is found.
|
||||
|
||||
>**Note:** If you come across an error, it's probably because the wrong permissions have been set on either a folder or file. See [here](faq.md#folder-permissions) for how to fix this.
|
||||
On success, a message will be printed that your keys have been imported:
|
||||
```
|
||||
NOT 2022-07-19 17:36:37.578+02:00 Keystore imported
|
||||
```
|
||||
|
||||
```admonish note title=''
|
||||
`NOT` is short for `NOTICE` and not not :)
|
||||
```
|
||||
|
||||
## Storage
|
||||
After importing keys, it's time to [restart](./connect-eth2.md) the node and check that the keys have been picked up by the beacon node.
|
||||
|
||||
When you import your keys into Nimbus, your validator signing key(s) are stored in the `build/data/shared_<prater or mainnet>_0/` folder, under `secrets` and `validators` - **make sure you keep these folders backed up somewhere safe.**
|
||||
```admonish tip
|
||||
You can read more about the different types of keys [here](https://blog.ethereum.org/2020/05/21/keys/) - the `deposit import` command will import the **signing key** only.
|
||||
```
|
||||
|
||||
The `secrets` folder contains the common secret that gives you access to all your validator keys.
|
||||
## Troubleshooting
|
||||
|
||||
The `validators` folder contains your signing keystore(s) (encrypted keys). Keystores are used by validators as a method for exchanging keys. For more on keys and keystores, see [here](https://blog.ethereum.org/2020/05/21/keys/).
|
||||
If you come across an error, make sure that:
|
||||
|
||||
>**Note:** The Nimbus client will only ever import your signing key. In any case, if you used the deposit launchpad, this is the only key you should have (thanks to the way these keys are derived, it is possible to generate the withdrawal key from your mnemonic when you wish to withdraw).
|
||||
|
||||
## Export
|
||||
|
||||
*Todo*
|
||||
* You are using the correct data directory
|
||||
* for `systemd` users, look for the `--data-dir` option in the `.service` file
|
||||
* You are running the command as the correct user
|
||||
* for `systemd` users, look for the `User=` option in the `.service`. Assuming the user is called `nimbus`, prefix all commands with: `sudo -u nimbus`
|
||||
* Permissions for the data directory are wrong
|
||||
* See [folder permissions](./data-dir.md#permissions) for how to fix this.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,9 @@
|
|||
|
||||
Nimbus offers several options for logging - by default, logs are written to stdout using the [chronicles](https://github.com/status-im/nim-chronicles#introduction) `textlines` format which is convenient to read and can be used with tooling for [heroku/logfmt](https://brandur.org/logfmt).
|
||||
|
||||
> ℹ️ `NOT` at the beginning of a log line means 'NOTICE`
|
||||
```admonish tip
|
||||
`NOT` at the beginning of a log line means 'NOTICE`
|
||||
```
|
||||
|
||||
## Change log level
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
# Recover lost keys and generate new ones
|
||||
|
||||
Your mnemonic can be used to recover lost keys and generate new ones.
|
||||
When generating your [first deposit](./deposit.md) you will be asked to save a mnemonic in a safe location.
|
||||
|
||||
This mnemonic can be used to recover lost keys and generate new ones.
|
||||
|
||||
Every time you generate a keystore from your mnemomic, that keystore is assigned an index. The first keystore you generate has index 0, the second index 1, etc. You can recover any key using your mnemonic and that key's index. For more on how keys are derived, see this [excellent post](https://blog.ethereum.org/2020/05/21/keys/).
|
||||
|
||||
|
|
@ -12,12 +14,24 @@ Specifically, we'll be using the `existing-mnemonic` command. Here's a descripti
|
|||
|
||||
## Recover existing key
|
||||
|
||||
> ⚠️ Recovering validator keys from a mnemonic should only be used as a last resort. Exposing your mnemonic to a computer at any time puts it at risk of being compromised. Your mnemonic is not encrypted and if leaked, can be used to steal your funds.
|
||||
```admonish warning
|
||||
Recovering validator keys from a mnemonic should only be used as a last resort. Exposing your mnemonic to a computer at any time puts it at risk of being compromised. Your mnemonic is not encrypted and if leaked, can be used to steal your funds.
|
||||
```
|
||||
|
||||
***N.B.** the commands below assume you are trying to recover your original key, hence `--validator_start_index` has been set to `0`.*
|
||||
```admonish note
|
||||
The commands below assume you are trying to recover the first key you created, hence `--validator_start_index` has been set to `0`.
|
||||
```
|
||||
|
||||
Run the following command from the directory which contains the `deposit` executable:
|
||||
|
||||
**Mainnet**
|
||||
```
|
||||
./deposit existing-mnemonic \
|
||||
--validator_start_index 0 \
|
||||
--num_validators 1 \
|
||||
--chain mainnet
|
||||
```
|
||||
|
||||
**Prater**
|
||||
```
|
||||
./deposit existing-mnemonic \
|
||||
|
|
@ -26,30 +40,32 @@ Run the following command from the directory which contains the `deposit` execut
|
|||
--chain prater
|
||||
```
|
||||
|
||||
**Mainnet**
|
||||
```
|
||||
./deposit existing-mnemonic \
|
||||
--validator_start_index 0 \
|
||||
--num_validators 1 \
|
||||
--chain mainnet
|
||||
```
|
||||
|
||||
You'll be prompted to enter your mnemonic, and a new password for your keystore.
|
||||
|
||||
Check that the `validator_keys` directory contains your extra keystore.
|
||||
Check that the `validator_keys` directory contains your keystore.
|
||||
|
||||
Copy the `validator_keys` directory to `nimbus-eth2` and then follow the instructions [here](./keys.md). Your key will be added to your node on next restart.
|
||||
|
||||
## Generate another key
|
||||
|
||||
> ⚠️ If you wish to generate another validator key, you must take great care
|
||||
to not generate a copy of your original key. Running the same key on two different validator clients will likely get you slashed.
|
||||
|
||||
***N.B.** the commands below assume you already have one key and wish to generate a second, hence `--validator_start_index` has been set to `1` (as `0` would be the original key).*
|
||||
```admonish warning
|
||||
If you wish to use your new key with a separate client instance, make sure not to include your first key in the second setup - doing so will lead to it being slashed!
|
||||
```
|
||||
|
||||
```admonish note
|
||||
The commands below assume you already have one key and wish to generate a second, hence `--validator_start_index` has been set to `1` (as `0` would be the original key)
|
||||
```
|
||||
|
||||
Run the following command from the directory which contains the `deposit` executable:
|
||||
|
||||
**Mainnet**
|
||||
```
|
||||
./deposit existing-mnemonic \
|
||||
--validator_start_index 1 \
|
||||
--num_validators 1 \
|
||||
--chain mainnet
|
||||
```
|
||||
|
||||
**Prater**
|
||||
```
|
||||
./deposit existing-mnemonic \
|
||||
|
|
@ -58,14 +74,6 @@ Run the following command from the directory which contains the `deposit` execut
|
|||
--chain prater
|
||||
```
|
||||
|
||||
**Mainnet**
|
||||
```
|
||||
./deposit existing-mnemonic \
|
||||
--validator_start_index 1 \
|
||||
--num_validators 1 \
|
||||
--chain mainnet
|
||||
```
|
||||
|
||||
You'll be prompted to enter your mnemonic, and a new password for your keystore.
|
||||
|
||||
Check that the `validator_keys` directory contains an extra keystore.
|
||||
|
|
@ -73,8 +81,3 @@ Check that the `validator_keys` directory contains an extra keystore.
|
|||
Copy the `validator_keys` directory to `nimbus-eth2`.
|
||||
|
||||
Make sure you've made a [deposit](./deposit.md) for your new keystore, and then follow the instructions [here](./keys.md). Your key will be added to your node on next restart.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Command line options allow you to customize the way your beacon node operates.
|
|||
|
||||
You pass options to the beacon node by adding them to the command line. For example, if you want to launch Nimbus on mainnet with different base ports than the default `9000/udp` and `9000/tcp`, say `9100/udp` and `9100/tcp`, run:
|
||||
|
||||
```
|
||||
```sh
|
||||
./run-mainnet-beacon-node.sh --tcp-port=9100 --udp-port=9100
|
||||
```
|
||||
|
||||
|
|
@ -12,7 +12,7 @@ You pass options to the beacon node by adding them to the command line. For exam
|
|||
|
||||
To see the full list of command line options availabe to you, with descriptions, run:
|
||||
|
||||
```
|
||||
```sh
|
||||
build/nimbus_beacon_node --help
|
||||
```
|
||||
|
||||
|
|
@ -123,9 +123,8 @@ sub-commands should appear in a section of the file matching the sub-command nam
|
|||
|
||||
Here is an example config file illustrating all of the above:
|
||||
|
||||
```
|
||||
# nimbus-eth2-config.toml
|
||||
|
||||
```admonish example title='nimbus-eth2-config.toml'
|
||||
# Comments look like this
|
||||
doppelganger-detection = true
|
||||
web3-url = ["ws://192.168.1.10:8000"]
|
||||
num-threads = 0
|
||||
|
|
|
|||
|
|
@ -21,16 +21,17 @@ One of the most important aspects of the Raspberry Pi experience is trying to ma
|
|||
- Basic understanding of the [command line](https://www.learnenough.com/command-line-tutorial/basics)
|
||||
- 200GB SSD (2TB recommended if also running execution client)
|
||||
|
||||
> ⚠️ You will need an SSD to run the Nimbus (without an SSD drive you have absolutely no chance of syncing the Ethereum blockchain). You have two options:
|
||||
>
|
||||
> 1. Use an USB portable SSD disk such as the Samsung T5 Portable SSD.
|
||||
>
|
||||
> 2. Use an USB 3.0 External Hard Drive Case with a SSD Disk. For example, [Ethereum on Arm](https://twitter.com/EthereumOnARM) use an Inateck 2.5 Hard Drive Enclosure FE2011. Make sure to buy a case with an UASP compliant chip, particularly, one of these: JMicron (JMS567 or JMS578) or ASMedia (ASM1153E).
|
||||
>
|
||||
> In both cases, avoid low quality SSD disks (the SSD is a key component of your node and can drastically affect both the performance and sync time). Keep in mind that you need to plug the disk to an USB 3.0 port (the blue port).
|
||||
>
|
||||
> **N.B**
|
||||
> *If you have a Raspberry Pi 4 and are getting bad speeds transferring data to/from USB3.0 SSDs, please [read this recommended fix.](https://www.raspberrypi.org/forums/viewtopic.php?t=245931#p1501426)*
|
||||
```admonish note
|
||||
You will need an SSD to run the Nimbus (without an SSD drive you have absolutely no chance of syncing the Ethereum blockchain). You have two options:
|
||||
|
||||
1. Use an USB portable SSD disk such as the Samsung T5 Portable SSD.
|
||||
2. Use an USB 3.0 External Hard Drive Case with a SSD Disk. For example, [Ethereum on Arm](https://twitter.com/EthereumOnARM) use an Inateck 2.5 Hard Drive Enclosure FE2011. Make sure to buy a case with an UASP compliant chip, particularly, one of these: JMicron (JMS567 or JMS578) or ASMedia (ASM1153E).
|
||||
|
||||
In both cases, avoid low quality SSD disks (the SSD is a key component of your node and can drastically affect both the performance and sync time). Keep in mind that you need to plug the disk to an USB 3.0 port (the blue port).
|
||||
|
||||
```admonish note
|
||||
If you have a Raspberry Pi 4 and are getting bad speeds transferring data to/from USB3.0 SSDs, please [read this recommended fix.](https://www.raspberrypi.org/forums/viewtopic.php?t=245931#p1501426)
|
||||
```
|
||||
|
||||
### 1. Download Raspberry Pi Imager
|
||||
|
||||
|
|
|
|||
|
|
@ -22,4 +22,4 @@ Systemd will also ensure your validator keeps running when you exit your ssh ses
|
|||
|
||||
## Ethereum Foundation's Checklist
|
||||
|
||||
Ad a final check, we recommend you also go through the EF'S [staker checklist](https://launchpad.ethereum.org/checklist).
|
||||
As a final check, we recommend you also go through the EF'S [staker checklist](https://launchpad.ethereum.org/checklist).
|
||||
|
|
|
|||
|
|
@ -1,26 +1,78 @@
|
|||
# Run the beacon node
|
||||
|
||||
This page takes you through how to run just the beacon node **without a validator attached.**
|
||||
This page takes you through the steps of getting a standard setup the Nimbus beacon node up and running.
|
||||
|
||||
The beacon node connects to the network, syncs the chain and provides [API's](./rest-api.md) to monitor and interact with the beacon chain. To become a validator, you will need to run a beacon node.
|
||||
The quickstart setup involves running two nodes: an [execution client](./eth1.md) and a beacon node - both are needed to run a full Ethereum setup.
|
||||
|
||||
The beacon node connects to the beacon chain network, syncs historical data and provides [API's](./rest-api.md) to monitor and interact with the beacon chain.
|
||||
|
||||
Running a beacon node is a [worthwhile endeavor](https://vitalik.ca/general/2021/05/23/scaling.html#its-crucial-for-blockchain-decentralization-for-regular-users-to-be-able-to-run-a-node) even if your are not planning on validating yourself!
|
||||
|
||||
The guide assumes [Ubuntu Linux](https://ubuntu.com/download/server) is being used, and therefore some familiarity with [the linux command line](https://ubuntu.com/tutorials/command-line-for-beginners) is needed.
|
||||
|
||||
```admonish note
|
||||
To become a validator, you will first need to be running a beacon node.
|
||||
```
|
||||
|
||||
```admonish note
|
||||
You can practice running the node safely on the [Prater testnet](./prater.md) - throughout, we'll provide instructions for both Prater and Mainnet.
|
||||
```
|
||||
|
||||
## 1. Prepare
|
||||
|
||||
Prepare your machine by installing [Nimbus' dependencies](./install.html)
|
||||
|
||||
|
||||
Prepare your machine by installing [Nimbus' dependencies](./install.md). In particular, this step will show how to set up an [execution client](./eth1.md).
|
||||
|
||||
## 2. Install
|
||||
|
||||
You have two options for installing Nimbus itself:
|
||||
Next, download the [latest release](./binaries.md) and install it by unpacking the archive. Using a command line terminal:
|
||||
|
||||
* [Install precompiled release](./binaries.md)
|
||||
* [Build from source](./build.md)
|
||||
```sh
|
||||
# Create a directory that can hold the beacon chain data and applications - this should be a fast SSD
|
||||
mkdir -p nimbus-eth2
|
||||
|
||||
# Download the latest release - replace the link with the latest release on the download page!
|
||||
wget https://github.com/status-im/nimbus-eth2/releases/download/v22.6.1/nimbus-eth2_Linux_amd64_22.6.1_2444e994.tar.gz
|
||||
|
||||
# Unpack the archive into the `nimbus-eth2` directory you just created
|
||||
tar xvf nimbus-eth2_Linux_amd64_22.6.1_2444e994.tar.gz --strip-components 1 -C nimbus-eth2
|
||||
```
|
||||
|
||||
## 3. Sync
|
||||
```admonish tip
|
||||
Advanced users looking to take advantage of hardware-specific features and optimization may wish to [build from source](./build.md) instead!
|
||||
```
|
||||
|
||||
[Sync the chain](./start-syncing.md)
|
||||
## 3. Start the node
|
||||
|
||||
Once you've installed the binaries, you can [start the node](./start-syncing.md) which will initiate the sync process.
|
||||
|
||||
```sh
|
||||
cd nimbus-eth2
|
||||
```
|
||||
|
||||
**Mainnet**
|
||||
|
||||
```sh
|
||||
# Start a mainnet node
|
||||
./run-mainnet-beacon-node.sh
|
||||
```
|
||||
|
||||
**Prater**
|
||||
|
||||
```sh
|
||||
# Start a prater testnet node
|
||||
./run-prater-beacon-node.sh
|
||||
```
|
||||
|
||||
Once the beacon node starts, you'll see it logging information to the console, like so:
|
||||
|
||||
```sh
|
||||
INF 2022-07-19 15:42:58.145+02:00 Launching beacon node topics="beacnde" version=v22.6.1-2444e9-stateofus ...
|
||||
```
|
||||
|
||||
Congratulations! Your beacon node is up and running, and syncing the network!
|
||||
|
||||
## Where to go from here
|
||||
|
||||
* If you will be running the node on a regular basis, it is recommended you set up a [systemd service](./beacon-node-systemd.md) that automatically restarts your node if the computer reboots.
|
||||
* If you wish to stake, continue your journey by following the [validator quick start](./run-a-validator.md).
|
||||
* The [monitoring](./health.md) page contains information about how to keep your node healthy
|
||||
|
|
|
|||
|
|
@ -1,6 +1,14 @@
|
|||
# Run a validator
|
||||
|
||||
Once your beacon node is [running and synced](./quick-start.md), the next step is to run a validator.
|
||||
Once your beacon node is [running and synced](./quick-start.md), the next step is to set up a validator.
|
||||
|
||||
```admonish note
|
||||
Unlike other beacon chain clients, Nimbus does not require setting up a separate validator client process - the beacon node can itself perform validator duties.
|
||||
|
||||
This is a simple, safe and efficient way to get started.
|
||||
|
||||
Advanced users may want to use a separate [validator client](./validator-client.md) process instead.
|
||||
```
|
||||
|
||||
## 1. Deposit
|
||||
|
||||
|
|
@ -14,17 +22,6 @@ Once your beacon node is [running and synced](./quick-start.md), the next step i
|
|||
|
||||
[Start performing duties](./connect-eth2.md) by restarting the node
|
||||
|
||||
|
||||
</br>
|
||||
|
||||
------------------------------------------------------
|
||||
|
||||
</br>
|
||||
|
||||
```admonish tip
|
||||
While that's all there is to it, it is essential that you both [keep an eye on your validator](keep-an-eye.md) and [keep Nimbus updated](keep-updated.md) regularly 💫
|
||||
|
||||
</br>
|
||||
|
||||
|
||||
|
||||
|
||||
```
|
||||
|
|
|
|||
|
|
@ -4,15 +4,21 @@ Before you can use your node, it needs to sync with the network. Syncing starts
|
|||
|
||||
If you are planning to become a validator, you should ensure that your beacon node is [completely synced](./keep-an-eye.md#keep-track-of-your-syncing-progress) before submitting your deposit, or you might miss attestations and proposal duties until it has finished syncing.
|
||||
|
||||
> **Tip:** To get started more quickly, you can perform a [trusted node sync](./trusted-node-sync.md) instead - this requires access to a synced node or a third-party service.
|
||||
```admonish tip
|
||||
To get started more quickly, you can perform a [trusted node sync](./trusted-node-sync.md) instead - this requires access to a synced node or a third-party service.
|
||||
```
|
||||
|
||||
> **N.B.** You need need to run an execution client (**web3 provider**) together with the beacon node. See [here](./eth1.md) for instructions on how to do so.
|
||||
```admonish note
|
||||
You need need to run an execution client (**web3 provider**) together with the beacon node. See [here](./eth1.md) for instructions on how to do so.
|
||||
```
|
||||
|
||||
## Networks
|
||||
|
||||
Using Nimbus, you can connect either to a testnet, or mainnet. Mainnet is the main ethereum network where real assets are at stake, while testnets are used by users and developers alike to test their node and setup before committing real assets.
|
||||
|
||||
> If this is the first time you're setting up your node, it is recommended you run it on a testnet first. Later, when everything is working, you can easily switch to mainned.
|
||||
```admonish tip
|
||||
If this is the first time you're setting up your node, it is recommended you run it on a testnet first. Later, when everything is working, you can easily switch to mainned.
|
||||
```
|
||||
|
||||
### Testnet
|
||||
|
||||
|
|
@ -31,6 +37,8 @@ To start syncing the Ethereum beacon chain mainnet, run:
|
|||
./run-mainnet-beacon-node.sh
|
||||
```
|
||||
|
||||
## Log output
|
||||
|
||||
You should see the following output:
|
||||
|
||||
```
|
||||
|
|
@ -50,15 +58,7 @@ INF 2020-12-01 11:26:36.285+00:00 Slot end top
|
|||
|
||||
## Data directory
|
||||
|
||||
While running, the beacon node will store chain data and other information in `build/data/` in the directory where you installed Nimbus. You can change the storage location with the `--data-dir` option:
|
||||
|
||||
```sh
|
||||
./run-mainnet-beacon-node.sh --data-dir=/data/mainnet
|
||||
```
|
||||
|
||||
You will need to pass `--data-dir` to all commands, including when importing your keys!
|
||||
|
||||
> ℹ️ Don't forget to put `=` after `--data-dir`!
|
||||
While running, the beacon node will store chain data and other information its data directory, which by default is found in `build/data` - for more information, see the [data directory](./data-dir.md) guide.
|
||||
|
||||
## Command line options
|
||||
|
||||
|
|
|
|||
|
|
@ -1,16 +1,22 @@
|
|||
# Troubleshooting
|
||||
|
||||
> ⚠️ The commands on this page refer to the Prater testnet. If you're running mainnet, replace `prater` with `mainnet` in the commands below.
|
||||
```admonish note
|
||||
The commands on this page refer to mainnet. If you're running on `prater` or another testnet, replace `mainnet` accordingly
|
||||
```
|
||||
|
||||
We are continuously making improvements to both stability and resource usage. If you run into any problem with Nimbus and are not running the latest version, chances are they have already been fixed - see the [update guide](./keep-updated.md) for instructions of how to upgrade.
|
||||
|
||||
As it stands, we are continuously making improvements to both stability and memory usage. So please make sure you keep your client up to date! This means restarting your node and updating your software regularly from the `stable` branch. If you can't find a solution to your problem here, feel free to get in touch with us on our [discord](https://discord.com/invite/XRxWahP)!
|
||||
If you can't find a solution to your problem here, get in touch with us on our [discord](https://discord.com/invite/XRxWahP)!
|
||||
|
||||
> **Note:** While the `stable` branch of the `nimbus-eth2` repository is more stable, the latest updates happen in the `unstable` branch which is (usually) merged into master every week on Tuesday. If you choose to run Nimbus directly from the `unstable` branch, be prepared for instabilities!
|
||||
```admonish note
|
||||
When installing Nimbus, you will typically be using the latest `stable` release.
|
||||
|
||||
However, the latest changes happen in the `unstable` branch - if you're looking to test the chaings coming to the _next_ Nimbus release, consider building Nimbus from [source](./keep-updated.md#build-from-source) using the `unstable` branch.
|
||||
```
|
||||
|
||||
## Networking
|
||||
|
||||
> For more complete advice on fine-tuning your networking setup see [here](./networking.md)
|
||||
A correctly configured network is key to getting good performance - the [networking guide](./networking.md) details everything you need to know!
|
||||
|
||||
### Low peer count
|
||||
|
||||
|
|
@ -20,10 +26,10 @@ If you see a message that looks like the following in your logs:
|
|||
Peer count low, no new peers discovered...
|
||||
```
|
||||
|
||||
Your node is finding it hard to find peers. It's possible that you may be behind a firewall. Try restarting your client and passing `--nat:extip:$EXT_IP_ADDRESS` as an option to `./run-prater-beacon-node.sh`, where `$EXT_IP_ADDRESS` is your real IP. For example, if your real IP address is `1.2.3.4`, you'd run:
|
||||
Your node is finding it hard to find peers. It's possible that you may be behind a firewall. Try restarting your client and passing `--nat:extip:$EXT_IP_ADDRESS` as an option to `./run-mainnet-beacon-node.sh`, where `$EXT_IP_ADDRESS` is your real IP. For example, if your real IP address is `1.2.3.4`, you'd run:
|
||||
|
||||
```
|
||||
./run-prater-beacon-node.sh --nat:extip:1.2.3.4
|
||||
./run-mainnet-beacon-node.sh --nat:extip:1.2.3.4
|
||||
```
|
||||
|
||||
If this doesn't improve things, you may need to [set enr-auto-update](./networking.md#set-enr-auto-update) and/or [set up port forwarding](./networking.md#set-up-port-forwarding).
|
||||
|
|
@ -45,6 +51,7 @@ There can be several reasons behind why this is the case. The first thing to che
|
|||
If this doesn't fix the problem, please double check your node is able to [receive incoming connections](./networking.md#check-for-incoming-connections).
|
||||
|
||||
## Misc
|
||||
|
||||
### Console hanging for too long on update
|
||||
|
||||
To update and restart, run `git pull`, `make update`, followed by `make nimbus_beacon_node`:
|
||||
|
|
@ -54,7 +61,7 @@ cd nimbus-eth2
|
|||
git pull
|
||||
make update # Update dependencies
|
||||
make nimbus_beacon_node # Rebuild beacon node
|
||||
./run-prater-beacon-node.sh # Restart using same keys as last run
|
||||
./run-mainnet-beacon-node.sh # Restart using same keys as last run
|
||||
```
|
||||
|
||||
If you find that `make update` causes the console to hang for too long, try running `make update V=1` or `make update V=2` instead (these will print a more verbose output to the console which may make it easier to diagnose the problem).
|
||||
|
|
@ -62,12 +69,14 @@ If you find that `make update` causes the console to hang for too long, try runn
|
|||
>**Note:** rest assured that when you restart the beacon node, the software will resume from where it left off, using the validator keys you have already imported.
|
||||
|
||||
### Starting over after importing wrong keys
|
||||
The directory that stores the blockchain data of the testnet is `build/data/prater_shared_0` (if you're connecting to another testnet, replace `prater` with that testnet's name). If you've imported the wrong keys, and wish to start over, delete this repository.
|
||||
|
||||
Your keys and secrets are stored in the [data directory](./data-dir.md) (usually `build/data/shared_mainnet_0`). If you imported the wrong keys, simply remove them from `validators` and `secrets` found in the data directory.
|
||||
|
||||
### Sync problems
|
||||
If you’re experiencing sync problems, we recommend running `make clean-prater` to delete the database and restart your sync (make sure you’ve updated to the latest `stable` first though).
|
||||
|
||||
> **Warning**: `make clean-prater` will erase all of your syncing progress so far, so it should only be used as a last resort -- if your client gets stuck for a long time (because it's unable to find the right chain and/or stay with the same head value) and a normal restart doesn't improve things.
|
||||
If you’re experiencing sync problems, make sure that your network is healthy and that you have a recent version installed.
|
||||
|
||||
In rare cases, such as after an unclean shutdown, it may happen that the database has been corrupted and you need to restart the sync - to do so, remove the `db` folder from the [data directory](./data-dir.md) and restart the node. You can get re-synced faster using [trusted node sync](./trusted-node-sync.md).
|
||||
|
||||
### noCommand does not accept arguments
|
||||
|
||||
|
|
@ -75,6 +84,10 @@ If, on start, you see `The command 'noCommand' does not accept arguments`
|
|||
|
||||
Double check to see if your command line flags are in the correct format, i.e. `--foo=bar`, `--baz`, or `--foo-bar=qux`.
|
||||
|
||||
```admonish tip
|
||||
All options accepting values need a `=` between the option name and the value!
|
||||
```
|
||||
|
||||
### Address already in use error
|
||||
|
||||
If you're seeing an error that looks like:
|
||||
|
|
@ -83,19 +96,19 @@ If you're seeing an error that looks like:
|
|||
Error: unhandled exception: (98) Address already in use [TransportOsError]
|
||||
```
|
||||
|
||||
It's probably because you're running multiple validators -- and the default base port `9000` is already in use.
|
||||
It means that you're running another node that is using the same port as the one you're trying to start (or that you're trying to start a second instance of the same node).
|
||||
|
||||
To change the base port, run:
|
||||
|
||||
```
|
||||
./run-prater-beacon-node.sh --tcp-port=9100 --udp-port=9100
|
||||
./run-mainnet-beacon-node.sh --tcp-port=9100 --udp-port=9100
|
||||
```
|
||||
|
||||
(You can replace `9100` with a port of your choosing)
|
||||
|
||||
### Catching up on validator duties
|
||||
|
||||
If you're being flooded with `Catching up on validator duties` messages, then your CPU is probably too slow to run Nimbus. Please check that your setup matches our [system requirements](./hardware.md).
|
||||
If you're being flooded with `Catching up on validator duties` messages, your CPU is probably too slow to run Nimbus. Please check that your setup matches our [system requirements](./hardware.md).
|
||||
|
||||
### Local timer is broken error
|
||||
|
||||
|
|
@ -111,11 +124,10 @@ This is likely due to the fact that your local clock is off. To compare your loc
|
|||
cat </dev/tcp/time.nist.gov/13 ; date -u
|
||||
```
|
||||
|
||||
The first line in the output will give you internet time. And the second line will give you the time according to your machine. These shouldn't be more than a second apart.
|
||||
The first line in the output will give you internet time. And the second line will give you the time according to your machine. These shouldn't be more than half a second apart. See the [requirements](./install.md#time) page for more information on how to set automatic time synchronization.
|
||||
|
||||
### Eth1 chain monitor failure
|
||||
|
||||
|
||||
If you see an error that looks like the following:
|
||||
|
||||
```
|
||||
|
|
@ -141,10 +153,9 @@ If that doesn't fix the problem, double check that your [ports are open](https:/
|
|||
See our page on [monitoring the health of your node](./health.md) for more.
|
||||
|
||||
|
||||
|
||||
## Raspberry Pi
|
||||
|
||||
### Trouble transferring data to/from USB3.0 SSDs
|
||||
|
||||
We have seen reports of extremely degraded performance when using several types of USB3.0 to SSD adapter or when using native USB3.0 disk drives. [This post](https://www.raspberrypi.org/forums/viewtopic.php?t=245931#p1501426) details why there is a difference in behaviour from models prior to Pi 4 and the recommended workaround.
|
||||
We have seen reports of degraded performance when using several types of USB3.0 to SSD adapters or when using native USB3.0 disk drives. [This post](https://www.raspberrypi.org/forums/viewtopic.php?t=245931#p1501426) details why there is a difference in behaviour from models prior to Pi 4 and the recommended workaround.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +1,12 @@
|
|||
# Sync from a trusted node
|
||||
|
||||
> **Note:** This feature is available from `v1.7.0` onwards
|
||||
```admonish title=''
|
||||
This feature is available from `v1.7.0` onwards
|
||||
```
|
||||
|
||||
When you [start the beacon node](./quick-start.md) for the first time, it will connect to the beacon chain network and start syncing automatically - a process that can take several days.
|
||||
|
||||
Trusted node sync allows you to get started more quickly with Nimbus by fetching a recent checkpoint from a trusted node - you can get started in minutes instead of days.
|
||||
Trusted node sync allows you to get started more quickly by fetching a recent checkpoint from a trusted node - you can get started in minutes instead of days.
|
||||
|
||||
To use trusted node sync, you must have access to a node that you trust that exposes the [Beacon API](./rest-api.md) (for example a locally running backup node).
|
||||
|
||||
|
|
@ -14,32 +16,32 @@ It is possibly to use trusted node sync with a third-party API provider -- see [
|
|||
|
||||
## Perform a trusted node sync
|
||||
|
||||
> **Tip:** Make sure to replace `http://localhost:5052` in the commands below with the appropriate endpoint for you. `http://localhost:5052` is the endpoint exposed by Nimbus but this is not consistent across all clients. For example, if your trusted node is a [Prysm node](https://docs.prylabs.network/docs/how-prysm-works/ethereum-public-api#performing-requests-against-a-local-prysm-node), it exposes `127.0.0.1:3500` by default. Which means you would run the commands below with
|
||||
>
|
||||
> `--trusted-node-url=http://127.0.0.1:3500`
|
||||
```admonish tip
|
||||
Make sure to replace `http://localhost:5052` in the commands below with the appropriate endpoint of the trusted beacon node. `http://localhost:5052` is the default endpoint exposed by Nimbus, but this is not consistent across all clients.
|
||||
|
||||
For example, if your trusted node is a [Prysm node](https://docs.prylabs.network/docs/how-prysm-works/ethereum-public-api#performing-requests-against-a-local-prysm-node), it exposes `127.0.0.1:3500` by default. Which means you would run the commands below with `--trusted-node-url=http://127.0.0.1:3500`
|
||||
```
|
||||
|
||||
**Mainnet**
|
||||
|
||||
To sync Mainnet, from the `nimbus-eth2` directory run:
|
||||
|
||||
```sh
|
||||
build/nimbus_beacon_node trustedNodeSync --network:mainnet \
|
||||
--data-dir=build/data/shared_mainnet_0 \
|
||||
--trusted-node-url=http://localhost:5052
|
||||
build/nimbus_beacon_node trustedNodeSync \
|
||||
--network:mainnet \
|
||||
--data-dir=build/data/shared_mainnet_0 \
|
||||
--trusted-node-url=http://localhost:5052
|
||||
```
|
||||
|
||||
**Prater (testnet)**
|
||||
|
||||
To sync Prater, from the `nimbus-eth2` directory run:
|
||||
|
||||
```sh
|
||||
build/nimbus_beacon_node trustedNodeSync --network:prater \
|
||||
--data-dir=build/data/shared_prater_0 \
|
||||
--trusted-node-url=http://localhost:5052
|
||||
```
|
||||
|
||||
> **Note:**
|
||||
> Because trusted node sync by default copies all blocks via REST, if you use a third-party service to sync from, you may hit API limits. If this happens to you, you may need to use the `--backfill` option to [delay the backfill of the block history](./trusted-node-sync.md#delay-block-history-backfill).
|
||||
```admonish note
|
||||
Because trusted node sync by default copies all blocks via REST, you may hit API limits if you are using a third-party provider. If this happens to you, you may need to use the `--backfill` option to [delay the backfill of the block history](./trusted-node-sync.md#delay-block-history-backfill).
|
||||
```
|
||||
|
||||
## Verify you synced the correct chain
|
||||
|
||||
|
|
@ -53,14 +55,12 @@ curl http://localhost:5052/eth/v1/beacon/blocks/head/root
|
|||
|
||||
The `head` root is also printed in the log output at regular intervals.
|
||||
|
||||
> **Note:** this same [Beacon API](./rest-api.md) request should work with any third-party provider.
|
||||
>
|
||||
> For example, to test it out with our mainnet [testing server](rest-api.md#test-your-tooling-against-our-servers), you could run:
|
||||
>
|
||||
> ```
|
||||
> curl -X GET http://testing.mainnet.beacon-api.nimbus.team/eth/v1/beacon/blocks/head/root
|
||||
> ```
|
||||
```admonish note
|
||||
The same [Beacon API](./rest-api.md) request works with any third-party provider.
|
||||
|
||||
For example, to compare it out with our mainnet [testing server](rest-api.md#test-your-tooling-against-our-servers), you can run:
|
||||
`curl -X GET http://testing.mainnet.beacon-api.nimbus.team/eth/v1/beacon/blocks/head/root`
|
||||
```
|
||||
|
||||
## Advanced
|
||||
|
||||
|
|
@ -72,15 +72,19 @@ It is possible to get started more quickly by delaying the backfill of the block
|
|||
|
||||
You can also resume the trusted node backfill at any time by simply running the trusted node sync command again.
|
||||
|
||||
> **Warning:** While backfilling blocks, your node will not be able to answer historical requests or sync requests. This might lead to you being de-scored, and eventually disconnected, by your peers.
|
||||
```admonish
|
||||
While backfilling blocks, your node will not be able to answer historical requests or sync requests. This might lead to you being de-scored, and eventually disconnected, by your peers.
|
||||
```
|
||||
|
||||
### Modify sync point
|
||||
|
||||
By default, the node will sync up to the latest finalized checkpoint of the node that you're syncing with. While you can choose a different sync point using a block hash or a slot number, this block must fall on an epoch boundary:
|
||||
|
||||
```
|
||||
build/nimbus_beacon_node trustedNodeSync --blockId:0x239940f2537f5bbee1a3829f9058f4c04f49897e4d325145153ca89838dfc9e2 ...
|
||||
|
||||
```sh
|
||||
build/nimbus_beacon_node trustedNodeSync \
|
||||
--network:mainnet \
|
||||
--data-dir=build/data/shared_mainnet_0 \
|
||||
--blockId:0x239940f2537f5bbee1a3829f9058f4c04f49897e4d325145153ca89838dfc9e2
|
||||
```
|
||||
|
||||
### Sync from checkpoint files
|
||||
|
|
@ -89,11 +93,17 @@ If you have a state and a block file available, you can start the node using the
|
|||
|
||||
```sh
|
||||
# Obtain a state and a block from a Beacon API - these must be in SSZ format:
|
||||
curl -o state.32000.ssz \
|
||||
-H 'Accept: application/octet-stream' \
|
||||
http://localhost:5052/eth/v2/debug/beacon/states/32000
|
||||
curl -o block.32000.ssz \
|
||||
-H 'Accept: application/octet-stream' \
|
||||
http://localhost:5052/eth/v2/beacon/blocks/32000
|
||||
|
||||
curl -o state.32000.ssz -H 'Accept: application/octet-stream' http://localhost:5052/eth/v2/debug/beacon/states/32000
|
||||
curl -o block.32000.ssz -H 'Accept: application/octet-stream' http://localhost:5052/eth/v2/beacon/blocks/32000
|
||||
|
||||
build/nimbus_beacon_node --data-dir:trusted --finalized-checkpoint-block=block.32000.ssz --finalized-checkpoint-state=state.32000.ssz
|
||||
# Start the beacon node using the downloaded state and block as starting point
|
||||
./run-mainnet-beacon-node.sh \
|
||||
--finalized-checkpoint-block=block.32000.ssz \
|
||||
--finalized-checkpoint-state=state.32000.ssz
|
||||
```
|
||||
|
||||
## Recreate historical state access indices
|
||||
|
|
@ -101,5 +111,8 @@ build/nimbus_beacon_node --data-dir:trusted --finalized-checkpoint-block=block.3
|
|||
When performing checkpoint sync, the historical state data from the time before the checkpoint is not available. To recreate the indices and caches necessary for historical state access, run trusted node sync with the `--reindex` flag - this can be done on an already-synced node as well, in which case the process will simply resume where it left off:
|
||||
|
||||
```sh
|
||||
build/nimbus_beacon_node trustedNodeSync --reindex=true
|
||||
build/nimbus_beacon_node trustedNodeSync \
|
||||
--network:mainnet \
|
||||
--data-dir=build/data/shared_mainnet_0 \
|
||||
--reindex=true
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,12 +1,16 @@
|
|||
# Run a separate validator client
|
||||
|
||||
> ⚠️ This feature is currently in BETA - we are still testing it and implementation details may change in response to community feedback. **We strongly advise against using it on mainnet** - your validators may get slashed
|
||||
```admonish warning
|
||||
This feature is currently in BETA - we are still testing it and implementation details may change in response to community feedback. **We strongly advise against using it on mainnet** - your validators may get slashed
|
||||
```
|
||||
|
||||
By default, Nimbus loads validator keys into the main beacon node process, which is a simple, safe and efficient way to run a validator.
|
||||
|
||||
Advanced users may wish to run validators in a separate process, allowing more flexible deployment strategies. The Nimbus beacon node supports both its own and third-party validator clients via the built-in [REST API](./rest-api.md).
|
||||
|
||||
> ⚠️ So far, all slashings with known causes have been linked to overly complex setups involving separation between beacon node and validator client! Only use this setup if you've taken steps to mitigate the increased risk.
|
||||
```admonish warning
|
||||
So far, all slashings with known causes have been linked to overly complex setups involving separation between beacon node and validator client! Only use this setup if you've taken steps to mitigate the increased risk.
|
||||
```
|
||||
|
||||
## Build
|
||||
|
||||
|
|
@ -34,9 +38,13 @@ build/nimbus_beacon_node deposits import \
|
|||
--data-dir:build/data/vc_shared_prater_0 "<YOUR VALIDATOR KEYS DIRECTORY>"
|
||||
```
|
||||
|
||||
> ⚠️ Do not use the same data directory for beacon node and validator client - they will both try to load the same keys which may result in slashing!
|
||||
```admonish warning
|
||||
Do not use the same data directory for beacon node and validator client - they will both try to load the same keys which may result in slashing!
|
||||
```
|
||||
|
||||
> ⚠️ If you are migrating your keys from the beacon node to the validator client, simply move the `secrets` and `validators` folders in the beacon node data directory to the data directory of the validator client
|
||||
```admonish warning
|
||||
If you are migrating your keys from the beacon node to the validator client, simply move the `secrets` and `validators` folders in the beacon node data directory to the data directory of the validator client
|
||||
```
|
||||
|
||||
With the keys imported, you are ready to start validator client:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
# Validator monitoring
|
||||
|
||||
> ⚠️ This feature is currently in BETA - implementation details such as metric names and counters may change in response to community feedback.
|
||||
```admonish warning
|
||||
This feature is currently in BETA - implementation details such as metric names and counters may change in response to community feedback.
|
||||
```
|
||||
|
||||
The validator monitoring feature allows for tracking the life-cycle and performance of one or more validators in detail.
|
||||
|
||||
|
|
@ -56,7 +58,9 @@ NOT 2021-11-17 20:53:42.108+01:00 Attestation failed to match head top
|
|||
|
||||
Failures are reported with a lag of two epochs (~13 minutes) - to examine the log for potential root causes, the logs from the epoch in the failure message should be looked at.
|
||||
|
||||
> ⚠️ It should be noted that metrics are tracked for the current history - in the case of a reorg on the chain - in particular a deep reorg - no attempt is made to revisit previously reported values. In the case that finality is delayed, the risk of stale metrics increases.
|
||||
```admonish warning
|
||||
It should be noted that metrics are tracked for the current history - in the case of a reorg on the chain - in particular a deep reorg - no attempt is made to revisit previously reported values. In the case that finality is delayed, the risk of stale metrics increases.
|
||||
```
|
||||
|
||||
Likewise, many metrics, such as aggregation inclusion, reflect conditions on the network - it may happen that the same message is counted more than once under certain conditions.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,34 +1,44 @@
|
|||
# Perform a voluntary exit
|
||||
|
||||
```admonish title=''
|
||||
This feature is available from `v1.7.0` onwards - earlier versions relied on the now removed [JSON-RPC API](./api.md).
|
||||
```
|
||||
|
||||
Voluntary exits allow validators to permanently stop performing their duties, and eventually recover the deposit.
|
||||
|
||||
Exits are subject to a wait period that depends on the length of the exit queue. While a validator is exiting, it still must perform its duties in order not to lose funds to inactivity penalities.
|
||||
|
||||
> ⚠️ Voluntary exits are **irreversible**. You won't be able to validate again with the same key. And you won't be able to withdraw your stake until the Eth1 and Eth2 merge. *Note that voluntary exits won't be processed if the chain isn't finalising.*
|
||||
```admonish warning
|
||||
Voluntary exits are **irreversible**. You won't be able to validate again with the same key.
|
||||
|
||||
You will also not be able to withdraw your funds until a future hard fork that enables withdrawals.*
|
||||
```
|
||||
|
||||
```admonish note
|
||||
Voluntary exits won't be processed if the chain isn't finalising.
|
||||
```
|
||||
|
||||
To perform a voluntary exit, make sure your beacon node is running with the `--rest`option enabled (e.g. `./run-mainnet-beacon-node.sh --rest`), then run:
|
||||
|
||||
**Prater**
|
||||
|
||||
```
|
||||
build/nimbus_beacon_node deposits exit \
|
||||
--validator=<VALIDATOR_PUBLIC_KEY> \
|
||||
--data-dir=build/data/shared_prater_0
|
||||
```
|
||||
|
||||
|
||||
**Mainnet**
|
||||
|
||||
```
|
||||
build/nimbus_beacon_node deposits exit \
|
||||
--validator=<VALIDATOR_PUBLIC_KEY> \
|
||||
--data-dir=build/data/shared_mainnet_0
|
||||
--data-dir=build/data/shared_mainnet_0 \
|
||||
--validator=<VALIDATOR_PUBLIC_KEY>
|
||||
```
|
||||
|
||||
> **Note:** Make sure your `<VALIDATOR_PUBLIC_KEY>` is prefixed with `0x`. In other words the public key should look like `0x95e3...`
|
||||
**Prater**
|
||||
```
|
||||
build/nimbus_beacon_node deposits exit \
|
||||
--data-dir=build/data/shared_prater_0 \
|
||||
--validator=<VALIDATOR_PUBLIC_KEY>
|
||||
```
|
||||
|
||||
```admonish note
|
||||
Make sure your `<VALIDATOR_PUBLIC_KEY>` is prefixed with `0x`. In other words the public key should look like `0x95e3...`
|
||||
```
|
||||
|
||||
## `rest-url` parameter
|
||||
|
||||
> **Note:** This feature is available from `v1.7.0` onwards - earlier versions relied on the now removed [JSON-RPC API](./api.md).
|
||||
|
||||
The `--rest-url` parameter can be used to point the exit command to a specific node for publishing the request, as long as it's compatible with the [REST API](./rest-api.md).
|
||||
|
|
|
|||
|
|
@ -2,11 +2,11 @@
|
|||
|
||||
It's a good idea to add a backup web3 provider in case your main one goes down. You can do this by simply repeating the `--web3-url` parameter on launch.
|
||||
|
||||
> ℹ️ As of `v1.7.0` Nimbus will no longer automagically rewrite HTTP(S) web3 URLs to their respective WebSocket alternatives.
|
||||
|
||||
For example, if your primary execution client is a [local Geth](./eth1.md#geth), but you want to use [Infura](./infura-guide.md) as a backup you would run:
|
||||
|
||||
> ⚠️ After [the merge](./merge.md), it will no longer be possible to rely on third-party services like Infura to run a beacon node!
|
||||
```admonish warn
|
||||
After [the merge](./merge.md), it will no longer be possible to rely on third-party services like Infura to run a beacon node!
|
||||
```
|
||||
|
||||
```sh
|
||||
./run-mainnet-beacon-node.sh \
|
||||
|
|
|
|||
Loading…
Reference in New Issue