⏰ The Shapella network upgrade will activate on Ethereum Mainnet at Epoch 194048, scheduled for 22:27:35 UTC on Apr. 12, 2023.

Do you want to withdraw your sweet, sweet ETH? Here are the instructions explaining:

1. The Basics: How do withdrawals work?
2. The comprobation: Check to see if you are have an Execution Address set as your Withdrawal Credentials or have Legacy BLS Withdrawal Credentials
3. The preparation: How To make your validator(s) ready and eligible for withdrawals if it is not already eligible
4. The Withdrawal: how to initiate a voluntary full withdrawal

For a simple video explanation, you can check this out — BUT ATTENTION! WE HIGHLY RECOMMEND DOING ANYTHING RELATED TO THE MNEMONIC COMPLETELY OFFLINE IN AN AIR-GAPPED COMPUTER!

The Basics: How do withdrawals work?

A common misconception is to think that withdrawals can be triggered by the user. Withdrawals are passive and cannot be triggered manually. Instead, the act of receiving your extra balance ETH in your wallet will occur automatically if you fulfill all the right conditions.

All you can do is to make sure you fulfill the conditions for the type of withdrawal you want to be performed: Partial or Full withdrawal

The beacon chain will check 16 validators per slot and will trigger either a full withdrawal or a partial withdrawal. The next slot, it will check for the next 16 validators of the validator set, and will go on until the end of the validator list, at which point it will start from the beginning again.

Withdrawals automatically begin being processed by the network regularly at a current network set maximum rate of 16 validators per slot starting on the next Beacon Chain slot following the activation of Shapella at epoch 194048.

Here’s a rough representation of how the beacon chain would go, slot by slot, down the validator list, and attempt to process a withdrawal, either an Excess Balance Withdrawal (Partial Withdrawal) or if it’s already exited, a Full Withdrawal.

Types of withdrawals and the necessary conditions for them to happen:

There are full withdrawals and partial withdrawals:

To be fully withdrawable, your validator(s) needs to:

1. Be exited, either voluntarily exited or slashed (forcibly exited).
2. Have waited for enough time to have passed since its exit (to be past its withdrawable epoch).
3. Have an Execution / Eth1 withdrawal address set. (NOT a BLS withdrawal credential, more on that below)
4. Of course, still have a balance!

Then, when the turn of this validator arrives on the Beacon Chain, all the balance will be transferred to the withdrawal address.

To be partially withdrawable you need to:

1. Have an Execution / Eth1 withdrawal address set
2. Have excess effective balance (that is balance over 32 ETH)

Then, all your balance over 32 ETH will be sent to the withdrawal address.

If you just want to reap your hard earned rewards, you only need to set up an Execution Withdrawal Address and your excess balance will be automatically deposited every time the Beacon Chain processes it!

So, how do you know if you are ready and everything will happen automatically?

The comprobation: Check to see if you are have an Execution Address set as your Withdrawal Credentials or have Legacy BLS Withdrawal Credentials

Depending on when and how you created your validator keys, it is possible that your address is already an eth1 address and you don’t need to do anything extra!

The easiest way is to go to beaconcha.in and find your validator.

Remember that you can go to the Web3Signer UI and click on this button to be sent to the beaconcha.in page of your validator!

If you see 0x01 in the field “Withdrawal Credentials” in the Beaconcha.in image above, you’re good to go! You don’t need to do anything else to receive partial withdrawals, and you can voluntarily initiate the validator exit process should you want to do so.

If instead you see 0x00 in Yellow as shown in the image above, you will need to change it to an Execution/Eth1 withdrawal address, and you can read how to do it below.

The Preparation: Changing to an Execution Address from a BLS Withdrawal Credential (0x00) => (0x01)

First we need to gather the needed data and software online to create your BTEC (BLS to Execution Credentials) message.

We need:

• your seed/mnemonic used to create your validator(s). If you used more than one seed/mnemonic for your validators you need to complete this process for each seed from which you generated active validator keys.
• The Validator’s Index: Upper Left Red Box on Beaconcha.in as shown in the image below
• The Validator’s BLS Credentials: Lower Red Box below (should begin with 0x00 or else you already have an Execution Address). Click the copy icon circled in green to copy the full BLS Withdrawal credential

Keep the mnemonic safe and note the Validator’s index and the corresponding BLS for each validator you want to generate the BLS to Execution Message in a text editor.

⏰ If you have many validators perhaps 5 or more you will likely want to do this process using ETH-DO’s CLI which can handle and create batch transactions without needing to pull all your validator’s information i.e. PubKeys, BLS Withdrawal Credentials, Validator Indexes, manually — -{Instructions are in this more advanced guide Here}

Using Wagyu to generate the message

🔒 This guide is going to take into account best security practices (Which we at Dappnode STRONGLY recommend you always follow) for handling sensitive information such as validator seeds.

⚠️ This includes using 2 machines: one offline air-gapped machine and another online computer able to connect to your dappnode. This setup drastically increases security.

⚠️ If you do not have another air-gapped offline computer, like an old laptop, you could use a Linux Live CD/USB such as Tails to use on your regular computer with the internet disabled

⚠️ Whatever you choose to do, DO NOT have your computer online when dealing with your seed/mnemonic. And make sure to clear your clipboard (Wagyu automatically clears your clipboard upon close of the app), and to clear and remove any and all versions of your seed/mnemonic from your computer before reconnecting to the internet.

⚠️ If you use an offline computer you will need a USB drive to transfer the file created by Wagyu onto the online computer for broadcasting the message

1. Download wagyu from wagyu.gg and open the app.
2. Click on “USE EXISTING RECOVERY PHRASE”

3. It will ask you to confirm which network you want to use. Test first on goerli if you have validators there and then proceed to mainnet.

4. Finally you will be shown the following screen select the Bottom option “GENERATE YOUR BLS TO EXECUTION CHANGE (ADD A WITHDRAWAL ADDRESS)”.

5. This brings up this page to enter your seed/mnemonic/recovery-phrase.

6. Enter your securely stored mnemonic here. Double check your mnemonic is correct before continuing. (It will validate the mnemonic after clicking import.)

7. Once your mnemonic is verified it will show this page

• Starting Index. You will in most cases use 0 as the starting index if your first validator was created from the first generated keystore of the seed/mnemonic.
• The Validator Index or Validator Indices collected in step 1 should be entered in the upper right text field separated by commas.
• The Validator BLS credentials collected in step 1 should be entered in the large field in the center of the page, also separated by commas.

Make sure the order of your validator indexes is in the same order as the BLS withdrawal credentials (i.e. first listed validator index will have its corresponding BLS withdrawal credential be the first listed in its field, and so on.)

• Finally the last parameter is your Execution address/ETH1 Address you want to set as your withdrawal credential; ensure you have full control over this address.

Example:

8. Click Next and it will ask for the folder you’d like to have Wagyu save the BTEC message.

9. Once you select the destination folder and click create it will begin creating the BTEC message for you to broadcast from your online computer

The next page shows the completed BTEC message’s location on your drive (its blacked out in my example)

10. This listed file path leads to the signed BTEC message file you now need to copy onto the USB drive used earlier in the process, to be transferred back to the online computer to broadcast the message to the network or node.

Submit the message in the file you have created to the Beacon Chain

💡 This step needs to be done online — on your online computer or after wiping your cache / resetting the laptop and coming back online.

The easiest way to broadcast your BTEC Message is simply going to Beaconcha.in’s Broadcast Message Tool and drag and drop, copy paste, or select inside the box to open a dialog to select your signed BTEC Message .json file.

And that’s it! After submitting, you are ready to roll! It is possible that the message will only be propagated after Shapella activates, so check back after in your Beaconcha.in validator page to see the change.

The Withdrawal: Performing a voluntary exit with Dappnode

If you have set your withdrawal address to a 0x01 address, you will automatically receive everything you generate above 32 ETH.

You don’t need to do anything else to collect the ETH you generated!

But if you want to fully exit and stop validating, you must follow the following steps on dappnode:

1. Select the validator you want to exit and click on the exit icon on the top right, as in the image below

2. Type “I want to exit” in the confirmation box and press “EXIT”. You can also download the signed exit message, but it is not relevant for solo stakers, in most cases.

Downloading this message (known as a Voluntary Exit Message, or VEM) can have utility in some situations where you want to have an emergency way to exit your validators without needing to be on your node with you validators active (i.e. full node crash, stolen node, death/severe injury that requires non technical family or friends to exit your validators all they need to do is have the VEM downloaded, its already signed and cannot be altered and can simply be dragged and dropped onto the Beaconcha.in Broadcast Message Page which will exit the validator(s) and withdraw the full remaining balance to your set Execution Withdrawal Address)

And that’s it! You have exited and if you have set your withdrawal address to an Execution/Eth1 address, you will receive your full balance when the Beacon Chain iterates over your validator and determines you fulfil all the conditions.

Thanks to Voss and Chuy for their help writing this guide!

Questions? Join our discord!

You don’t have a Dappnode yet? Check our website!

Wanna be up to date? Follow us on twitter!

How to Prepare for Withdrawals for Ethereum Stakers using Dappnode was originally published in DAppNode on Medium, where people are continuing the conversation by highlighting and responding to this story.

You’ve probably heard about Praise, the rewards system that great projects like Gnosis Chain, Giveth and BanklessDAO have been using. We’re very happy to let you know that Praise is now one of the tools that Dappnode will be using to… well, praise and reward the community!

…but, what is Praise?

Praise is a community intelligence system that promotes active participation and collaboration through peer recognition and rewards. Here’s a few examples of how Praise can be used:

Why does Dappnode + Praise makes sense?

Dappnode is an open-source software where anybody can make contributions. Dappnode is also all about decentralization, and by giving the community the power to recognize contributions that solve issues, give support and bring value to the project, we’re not only limited to better rewarding and recognizing contributors, but to also build a culture around gratitude.

What do I need to participate?

All you need to do is go to the Dappnode’s Discord server and look for the #how-to-praise channel to get the Praise Giver role! Also, don’t forget to /activate to link the wallet where you’ll be receiving $NODLR, our reputation token.

Why do I want Praise?

You definitely want Praise! Praise converts to $NODLR, a non-transferrable reputation token. This reputation token will identify you as a great community member and will give you benefits in the community.
Among the first benefits of being recognized by the Dappnode community is the fact that you’ll be able to participate in the Stakehouse-Dappnode LSD Staking Pool (in construction right now). This means you will be able to stake 4 ETH and earn as a Node Operator for the LSD Network! This LSD pool will only be available to community members that hold a minimum amount of $NODLR.

You can start right now! Go and dish some Praise to people that you think have had valuable contributions to the Dappnode community. And if you help someone or contribute, you might get praise yourself!

Give Praise! Get Praise!

Praise is now part of Dappnode was originally published in DAppNode on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introducing Ethical Monitor, a service that allows users to receive notifications and alerts about the status of their Dappnode without compromising their privacy.

A lot of people have asked us to have a service that can warn them when their dappnode is offline, but there were two main problems:

First, you can’t monitor if your dappnode is down with the dappnode itself, because if it’s down it can’t send you alerts. This means that a secondary service needs to be set up.

This brings us to the second problem: we firmly believe in user privacy and dappnode is designed with privacy in mind… we needed a solution that could do this but without revealing anything about the person’s identity.

And finally, we have done just that.

Ethical Monitor works by installing it like any other package, and then requiring users to enter an email address to receive alerts. We encourage users to use a “burner” email address, or a separate email address that is not connected to their identity, in order to maintain their privacy.

Once Ethical Monitor is installed, it creates a Tor hidden service in order to send metrics about the Dappnode, such as the packages that are running, their versions, and whether the Dappnode is online or not. By using a hidden service, we are able to separate the IP address from the data that is being sent, ensuring that no identifying information is shared.

Currently, Ethical Monitor only alerts users when their Dappnode is offline, but we plan to add more alert options in the future. These could include notifications about outdated packages, open or closed ports, and more. Let us know which alerts or metrics would be useful for you here.

Let us know which alerts or metrics would be useful for you!

We are committed to maintaining our privacy-by-design principle, and Ethical Monitor is a great example of how we can provide valuable services to our users without compromising their privacy. We hope you will find it useful, and please don’t hesitate to reach out with any feedback or suggestions.

PS: We believe that capturing user data and turning it into the core of your business is a plague in tech that disenfranchises users and makes them vulnerable. We did a talk in Devcon 5 (2019) with good examples of how the data that gets captured for initially good purposes can end up threatening lives, our free will or even democracy itself. That’s a No for us.

Don’t have a dappnode yet? Go to our website and find out how to install Dappnode for free or get a plug-and-play Dappnode Home and start staking Ethereum and other chains!

Follow us on twitter!
We’re open source, see our code on github

Introducing Ethical Monitor: A Privacy-Focused Service for Dappnode Alerts was originally published in DAppNode on Medium, where people are continuing the conversation by highlighting and responding to this story.

DAppNode users have been able to pick the Execution Layer (EL) client and the Consensus Layer (CL) client of their choice in the Prater Testnet and in Gnosis Chain (and in the recently born Gnosis Chain testnet “Chiado”!).

The moment has arrived to deploy the Multi-client setup to our Mainnet validators!

Read below for important info and for a step-by-step guide on how to migrate to Multi-client.

Two things you need to know:

The prysm UI will stop working — even if you keep using prysm! This is because the keys will be securely stored in the web3signer. A new keymanager UI is also built into the web3signer package. It will display information about your keys, and you will have a DMS dashboard to keep track of all your validator data, but it’s not as complete when it comes to calculating earnings. The new UI is Open Source and compatible with all clients, and it will be improved over time. For now we suggest using beaconcha.in to keep track of the earnings of your validator.

How does the multi-client work and why does it help me?

The multiclient setup allows you to use the CL client you want without being restricted to Prysm, as you were before. This has huge advantages for you as you can react quickly to any potential bugs on any client implementation and you can support client diversity — which means that you make the entire Ethereum Network more resilient by running minority clients.

For a diagram of how the solution works and why we chose to make it work this way, please look at this 1 minute section of this video https://youtu.be/Z0aK1OYPhQg?t=19

Here’s what you need to do once the update hits your dashboard:

1. Install the new Core version 0.2.57. A new DAppNode core release will be published. This DAppNode version will prohibit you to have any combination of packages that could be hosting keys at the same time. This way, we make it impossible for you to even have installed two packages that, if misused, could cause a slashing event.
2. Install the new Prysm version 2.0.0. A new major update of the Prysm client will be published. You will need to trigger this update manually, auto updates won’t work for such an update. Updating Prysm will install the web3signer package and will move the keys to it. The new Prysm version will be communicating with the web3signer to receive the pubkeys of your validators and start sending attestation assignments to the new key holder.

Once you reach this point, you’re good. You’re validating and there’s nothing else you need to do if you want to keep using Prysm. But now you have the option of switching to another validator client. If that’s your choice, keep reading.

1. Optional — Install an alternative CL client. Once you’re up and running with Prysm, you can then install Teku or Lighthouse (Nimbus and Lodestar don’t work at the expected performance level yet), and use checkpoint sync to not have to wait for the full beacon chain to sync (watch this to know how to configure checkpoint sync with Infura, or just copy the recommended link and paste it in the field).
   ⚠️ Please note that Lighthouse will wait 3 to 4 epochs to activate your validator due to the doppelganger protection ⚠️
2. Point the web3signer to the new CL client. Then you can go to the web3signer package > Config and use the drop-down menu to change to a client that you have installed and synced. Please note that if you choose a client that is not installed, the web3signer will be pointing to a package that doesn’t exist and hence you won’t submit any validation work.

What if the automatic migration of the keys to the web3signer fails?

Not to worry. Some edge cases might make the automatic migration of keys from Prysm to the web3signer fail, that’s why there is a manual migration route that takes just 2 steps.

Please follow the instructions in this link:https://mainnet-manual-migration.dappnode.io/

—

Do you have any questions? Join DAppNode’s discord, where we have a dedicated channel for Gnosis Beacon Chain validators!

For getting your own dappnode visit our website!
If you want to be the first to find out about any new DAppNode updates, follow us on Twitter or check out our blog. You can engage with our community on our Discord server or our forum.

Multiclient on Ethereum Mainnet has arrived. This is all you need to know was originally published in DAppNode on Medium, where people are continuing the conversation by highlighting and responding to this story.

Having a productive DAO is hard. Successfully coordinating people in a novel structure isn’t something that can be taken lightly. DAppNode DAO initially planned to launch in February but could not coordinate enough members across the various guilds to get them off the ground.

What went wrong? In retrospect, we think that the primary failure might have been being too ambitious and trying to do too many things simultaneously.

In this piece, we will look at lessons learned from the first attempt and how we will be applying these lessons moving forward.

“Mistakes are a fact of life. It is the response to error that counts.”

DAppNode DAO initially planned to launch in February 2022 with four separate guilds and an overseeing governance guild. The guilds that were initially planned were:

•Builders

•Communications

•Support

•Tokenomics

An additional governance guild would be formed by the guild leads of the four project guilds in combination with DAppNode core guild members. The idea was that the governance guild would be responsible for allocating the DAO treasury funds across the project guilds and settling any disagreements within the guilds.

This plan had no fundamental flaw, but the implementation didn’t go as planned. One common difficulty for DAOs is everyone assuming things will happen organically. In reality, DAOs depend on community members pushing things forward. Without a structured leadership hierarchy driving objectives down the chain of command, projects can stall. Community members stepping into leadership roles is the only way to achieve goals. In a world of cats minding their own businesses, the figure of the Cat Herder is more important than ever.

So, what went wrong? There’s probably a combination of things, but mainly, by trying to start all guilds at the same time, the Cat Herder got overwhelmed before other community figures could rise to the task in every guild.

Fall, get up and try again.

There were a lot of lessons and takeaways from the first attempt at launching the DAppNode DAO. On June 8, 2022, DAppNode hosted a community call to discuss the future direction of the DAO and to assess the issues of the first attempt. The primary takeaway was that less is more. Starting with a single guild and focusing on learning how to accomplish objectives would have a higher chance of success than multiple guilds working on separate projects.

With that in mind, the DAO has decided to launch a singular Communications Guild that would be primarily focused on creating educational content around DAppNode’s product offerings.

Community member MaxShytoshi has already made a DAppNode Dashboard that will help DAppNode users find documentation that is useful to them. The DAppNode Newsletter also has a planned revival, which will also allow users to stay up-to-date on developments in the DAppNode ecosystem. Lastly, the Ethereum merge is right around the corner. As a leader in at-home staking infrastructure, DAppNode will be releasing documentation to make sure all Ethereum stakers running on DAppNode will be fully prepared for the Merge.

Who can join this guild? Anyone with the willingness to contribute. We are learning from best practices in the ecosystem and using DAO-native tools like Coordinape and Dework to track and appraise people’s contributions. These tools help to integrate new contributors and align the work being done with the objectives of the guild.

A builder’s guild is brewing

Following the movement in the Communications guild, a few of the builders in the community are gathering around the #dao-builders-team channel in Discord to put some structure to the development needs of the DAO.

Are you a communicator? A project manager? A builder? A Devops? Someone excited about contributing to the future of distributed infrastructure? These guilds are completely open to anyone and work is appraised by the peers participating in the guild. Join us in the Discord and let’s start collaborating!

Wanna contribute to the DAppNodeDAO? Join the Discord and join the #dao-communications-guild or the #dao-builders-guild channels and introduce yourself! We can take it from there to get you onboarded!

If you want your own dappnode and become a Node Runner, visit us here to install it or buy a plug-and-play machine.

DAppNode DAO V2.0 was originally published in DAppNode on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you are a staker and have not been unconscious for the most part of the year, it is likely you know that The Merge Is Coming.

You are probably using DAppNode because it makes things easy for you, and The Merge will not be an exception. Here’s what to expect!

This document is with the information from today — but we will publish further updates to keep you informed ;)

1. Timeline

There are currently 3 beacon chains that will merge in the near future in DAppNode. You will be able to perform the merge in all of them. Keep an eye open for the expected Merge dates!

1. Prater — will merge with Göerli. The biggest CL testnet with the most popular EL testnet! We recommend you set up a Prater Validator to practise in advance ;) The expected Merge date is estimated between the 8th and the 10th of August.
2. Gnosis Chain — will merge with the Gnosis Beacon Chain
3. Ethereum — will merge CL with EL!

Other testnets like Sepolia, Kiln and Ropsten have already merged. There are Sepolia packages in the explorer, but not in the main DAppStore. Feel free to download them from the IPFS hash in the explorer, but we recommend focusing your efforts on going through the motions in Prater and performing a live merge.

2. What needs to happen

1. You need to run an Execution Layer Client. If you are NOT running your Execution Layer Client (Geth, Nethermind) PLEASE START RUNNING IT NOW or you will not be able to validate. Most DAppNode users already run it as we recommended it from the beginning, but if you’ve been testing other configs with a remote EL node, you need the main node to go back to the mothership.
2. You will need to be in the latest version. We have not decided yet whether you will need to do a manual upgrade or the automatic updates will suffice. We recommend keeping an eye on your DAppNode and in the DAppNode community to make sure you are in the right version when we are closer to the merge.
3. If you were using your EL node without running a validator, you will now need to also run a CL node as the EL alone won’t know where’s the head of the chain.

… and that’s it. Really, from your part, that’s all you will need to do.

3. What we are doing to get you ready

If you’d like to get deep on what changes are coming to the packages you are running, here’s a brief list of what we’re changing.

1. Execution clients:

• We will publish an update that will override the Terminal Total Difficulty or TTD (this is the metric that determines the exact block when The Merge happens)
• Enable Engine API — the new API to connect EL with CL
• Implement JWT authentication for the Engine API

2. Consensus clients

• Enable Engine API on the CL side
• Implement JWT authentication for the Engine API

4. I wanna go deeper

Alright, let’s jump into it.

4.1 Ethereum now

On Ethereum there are two chains:

• Execution chain or Execution Layer (EL): this chain contains all the information relative to transactions, EVM(Ethereum virtual machine, state of the ethereum chain), and it’s secured by the Proof Of Work consensus protocol.
• Beacon chain or Consensus Layer (CL): This chain contains the Proof of Stake consensus mechanism. After The Merge it will dictate which blocks are accepted as ethereum blocks and hence what is the Ethereum chain.

The next image is a representation of these two chains.

4.2 The merge transition

For The Merge to take place, it is very important that there is coordination between the execution chain and consensus chain.. To get this coordination in both chains there will be 2 hard fork upgrades, one on each layer:

• Bellatrix (Consensus Layer)
• Paris (Execution Layer)

4.2.1 Bellatrix

Bellatrix upgrade happens on the consensus chain and prepares it for the merge. After this upgrade, the beacon will build blocks which contain a placeholder for the execution payload. This execution payload is information related to the transactions, EVM, etc which it will be sent by the execution client. This upgrade will enable a new communication channel between the execution client and the beacon client. This new channel is called Engine API. The Bellatrix hard fork happens when we reach a specific moment in the chain, the BELLATRIX_FORK_EPOCH.

4.2.2 Paris

The Paris fork changes the consensus from PoW to PoS! Paris-ready clients also implement the Engine API to communicate with the Beacon Chain. The Paris fork is activated when the TTD is reached.

How do we put everything together?

1. Nodes are upgraded to be compliant with Bellatrix (CL part) and Paris (EL part).
2. We wait for the Bellatrix fork epoch to happen.
3. After the epoch is hit, CL clients wait for a terminal PoW block. Once a terminal PoW block reaches TTD…
4. …the Beacon chain proposer builds the first PoS block on top of a terminal PoW block, and Paris is activated on the Execution Layer.
5. Congratulations, we have Merged!

For more info, get into this extensive internal document. Careful, it’s a work-in-progress and things change!

Have you got more questions? Head over to DAppNode’s Discord and drop your Qs in the #eth2-stakers channel!

We will also regularly publish updates leading up to the following Merges (Göerli/Prater, Gnosis Chain and Mainnet) with specific instructions for each, so stay tuned.

If what you want is to know how to run a validator with dappnode and start staking, visit our website!

Happy Merging!

The Merge in DAppNode — Everything you need to know as a DAppNode Validator was originally published in DAppNode on Medium, where people are continuing the conversation by highlighting and responding to this story.

Switching between different client implementations has been in testing on the Prater testnet on DAppNode for a while, and is finally coming to a production environment on the Gnosis Chain.

We presented the multi-client setup at the EthStakers event at Devconnect. The setup was bulletproof enough back then, and any user starting from zero would not experience any hiccups. It was almost ready. But for those who were already validating, the migration of the keys on-the-fly so the user could update from their current Prysm setup to a web3signer + beacon chain client of choice setup without a hiccup was a technical hurdle!

After weeks of extensive testing, of failed migrations (but no slashings, even in the worst conditions!), several migration approaches and lots of cheeky edge cases, we are confident we can bring this into production.

What should I expect as a current GNO validator?

You can expect a seamless transition from a setup that restricts you to only validate in prysm to being able to switch client validators at will without losing more than a few seconds of online time, and likely no more than one missed attestation.

Here’s the timeline of events that’s coming for you:

1. A new DAppNode core release will be published. This DAppNode version will prohibit you to have any combination of packages that could be hosting keys at the same time. This way, we make it impossible for you to even have installed two packages that, if misused, could cause a slashing event.
2. A new major update of the Prysm client will be published. You will need to trigger this update manually, auto updates won’t work for such an update. Updating Prysm will install the web3signer package and will move the keys to it. The new Prysm version will be communicating with the web3signer to receive the pubkeys of your validators and start sending attestation assignments to the new key holder.
3. Once you reach this point, you’re good. You’re validating and there’s nothing else you need to do if you want to keep using Prysm. But now you have the option of switching to another validator client. If that’s your choice, keep reading.
4. Once you’re up and running with Prysm, you can then install Teku or Lighthouse (Nimbus doesn’t work at a level that we are fully comfortable with in Gnosis Chain yet), and use checkpoint sync to not have to wait for the full beacon chain to sync (watch this to know how to configure checkpoint sync).
5. Then you can go to the web3signer package > Config and use the drop-down menu to change to a client that you have installed and synced. Please note that if you choose a client that is not installed, the web3signer will be pointing to a package that doesn’t exist and hence you won’t submit any validation work.

Voilà! You are now validating using another client and, what’s best, you can change whenever you want!

Some considerations:

• The UI that you might have been using, Prysm’s UI, won’t be available anymore, as the keys will be securely stored in the web3signer. A new keymanager UI is also built into the web3signer package. It will display information about your keys, and you will have a DMS dashboard to keep track of all your validator data.
• It is highly recommended for you to activate the Telegram Bot. It will let you know if you are trying to validate with a package that you have not installed. Your bot is your friend!
• What if the migration goes wrong?

Not to worry. First of all, it shouldn’t, unless there’s some problem with your machine, the power goes off mid-migration or your cpu gets hit by a cosmic ray. And even in this case, we backup your keys and prepare them for a manual migration. The backup gets eliminated if the migration goes well or after 20 days, so there’s ample time to manually move them to the web3signer. Let us know if that happens and we’ll guide you on the process (spoiler alert, it’s almost as simple as the automatic way).

• How does the multi-client work and why does it help me?

For a diagram of how the solution works and why we chose to make it work this way, please look at this 1 minute section of this video https://youtu.be/Z0aK1OYPhQg?t=19

• When can I expect the multi-client setup to come to Ethereum?

Soon.

This multi-client setup will be coming in a few weeks to Ethereum Mainnet. Gnosis Chain and its beacon chain are the perfect canary network, with the right balance of skin in the game and lower stakes than Ethereum. We fully appreciate and support Gnosis Chain in their effort to give back to the Ethereum ecosystem by working closely with the client implementer teams and other ecosystem players like us to make sure Ethereum evolves safely.

Coming next to your DAppNode… Multi-client validation in production on Gnosis Chain was originally published in DAppNode on Medium, where people are continuing the conversation by highlighting and responding to this story.

We are pleased to announce that Gnosis chain (formerly xDai) has partnered with DAppNode to bring individual node runners into securing the Gnosis Chain ecosystem. We are excited to get into the details of the partnership but first, a quick look into what Gnosis is aiming to achieve.

Gnosis Chain inherits from xDAI the quality of being an Ethereum Virtual Machine (EVM) blockchain designed for seamless Ethereum compatibility, while pegging the price of gas to the US Dollar via DAI. Gnosis Chain is looking to take xDAI’s mission even further. It is building to have a symbiotic relationship with Ethereum by acting as the canary in the coal mine for the large steps along Ethereum’s scaling roadmap (the Merge, rollups, etc.). By taking this path it will hopefully be able to prevent issues that might arise by implementing changes before Ethereum while simultaneously benefiting greatly from the development being done on Ethereum. Its own roadmap will mimic that of Ethereum’s and will run as a Beacon Chain until its own merge, which will take place some time prior to the Ethereum merge. This will offer a critical confidence check prior to the Ethereum 2 launch.

Post merge, stakers will be validating the Gnosis Chain which will become a shard in the larger GBC ecosystem. For more info on Gnosis Chain check out their website here and for more specific information on the GNO beacon chain visit here.

Where Gnosis and DAppNode align is through the critical mission of making it possible for anyone to stake and validate the chain. 1 GNO token is all that is required to run a validator making the financial requirements more accessible to a wider audience. DAppNode makes it even easier by lowering the technical barrier of entry and offering a fleet of decentralized applications that will be used to validate the Gnosis chain. There is already an evolving full guide detailing how to set up a GNO validator on DAppNode! It is a Work-In-Progress that will be updating as the tooling advances, but can already take an adventurous node runner from zero to validator in Gnosis Chain.

The Incentive Program

Edit 25/01/22: The incentive program has now evolved and is explained below.

From now on (25/01/22), every DAppNode Xtreme will include a 4 validator incentive (equivalent to 4 GNO) until the end of the GNO pool to distribute.

Users will have to follow some instructions to create their private keys and will be responsible for maintaining the validator and avoiding slashing. Users will have to claim their validators via the official Gnosis Deposit UI.

W̶e̶’̶r̶e̶ ̶e̶x̶c̶i̶t̶e̶d̶ ̶t̶o̶ ̶s̶h̶a̶r̶e̶ ̶t̶h̶a̶t̶ ̶D̶A̶p̶p̶N̶o̶d̶e̶ ̶a̶n̶d̶ ̶G̶n̶o̶s̶i̶s̶ ̶a̶r̶e̶ ̶o̶f̶f̶e̶r̶i̶n̶g̶ ̶a̶ ̶d̶e̶a̶l̶ ̶f̶o̶r̶ ̶t̶h̶e̶ ̶f̶i̶r̶s̶t̶ ̶3̶0̶ ̶p̶e̶o̶p̶l̶e̶ ̶w̶h̶o̶ ̶p̶u̶r̶c̶h̶a̶s̶e̶ ̶a̶ ̶D̶A̶p̶p̶N̶o̶d̶e̶X̶t̶r̶e̶m̶e̶.̶ ̶T̶h̶e̶ ̶n̶o̶d̶e̶s̶ ̶w̶i̶l̶l̶ ̶c̶o̶m̶e̶ ̶w̶i̶t̶h̶ ̶4̶ ̶G̶N̶O̶ ̶v̶a̶l̶i̶d̶a̶t̶o̶r̶s̶ ̶a̶l̶r̶e̶a̶d̶y̶ ̶r̶e̶g̶i̶s̶t̶e̶r̶e̶d̶ ̶o̶n̶ ̶t̶h̶e̶ ̶d̶e̶v̶i̶c̶e̶.̶ ̶T̶h̶e̶s̶e̶ ̶v̶a̶l̶i̶d̶a̶t̶o̶r̶s̶ ̶w̶i̶l̶l̶ ̶h̶a̶v̶e̶ ̶t̶o̶ ̶b̶e̶ ̶m̶a̶i̶n̶t̶a̶i̶n̶e̶d̶ ̶b̶y̶ ̶t̶h̶e̶ ̶D̶A̶p̶p̶N̶o̶d̶e̶ ̶u̶s̶e̶r̶,̶ ̶u̶s̶i̶n̶g̶ ̶t̶h̶e̶ ̶D̶A̶p̶p̶N̶o̶d̶e̶ ̶f̶o̶r̶ ̶t̶h̶i̶s̶ ̶t̶a̶s̶k̶,̶ ̶a̶n̶d̶ ̶w̶i̶l̶l̶ ̶b̶e̶ ̶a̶b̶l̶e̶ ̶t̶o̶ ̶k̶e̶e̶p̶ ̶t̶h̶e̶ ̶G̶N̶O̶ ̶a̶n̶d̶ ̶t̶h̶e̶ ̶v̶a̶l̶i̶d̶a̶t̶i̶o̶n̶ ̶r̶e̶w̶a̶r̶d̶s̶ ̶g̶e̶n̶e̶r̶a̶t̶e̶d̶ ̶(̶p̶l̶u̶s̶ ̶p̶o̶t̶e̶n̶t̶i̶a̶l̶ ̶n̶e̶t̶w̶o̶r̶k̶ ̶f̶e̶e̶s̶ ̶a̶f̶t̶e̶r̶ ̶t̶h̶e̶ ̶m̶e̶r̶g̶e̶)̶.̶
̶T̶h̶i̶s̶ ̶i̶s̶ ̶a̶ ̶p̶i̶l̶o̶t̶ ̶p̶r̶o̶g̶r̶a̶m̶ ̶a̶n̶d̶ ̶o̶n̶c̶e̶ ̶w̶e̶ ̶g̶a̶t̶h̶e̶r̶ ̶r̶e̶l̶e̶v̶a̶n̶t̶ ̶d̶a̶t̶a̶,̶ ̶w̶e̶ ̶a̶r̶e̶ ̶l̶o̶o̶k̶i̶n̶g̶ ̶i̶n̶t̶o̶ ̶w̶a̶y̶s̶ ̶o̶f̶ ̶e̶x̶p̶a̶n̶d̶i̶n̶g̶ ̶s̶u̶c̶h̶ ̶i̶n̶c̶e̶n̶t̶i̶v̶e̶s̶ ̶r̶e̶t̶r̶o̶a̶c̶t̶i̶v̶e̶l̶y̶ ̶t̶o̶ ̶e̶x̶i̶s̶t̶i̶n̶g̶ ̶o̶w̶n̶e̶r̶s̶ ̶o̶f̶ ̶D̶A̶p̶p̶N̶o̶d̶e̶ ̶h̶a̶r̶d̶w̶a̶r̶e̶ ̶a̶n̶d̶ ̶e̶v̶e̶n̶ ̶a̶n̶o̶t̶h̶e̶r̶,̶ ̶b̶i̶g̶g̶e̶r̶,̶ ̶r̶o̶u̶n̶d̶ ̶o̶f̶ ̶n̶e̶w̶ ̶h̶a̶r̶d̶w̶a̶r̶e̶ ̶p̶u̶r̶c̶h̶a̶s̶e̶r̶s̶.̶ ̶I̶n̶ ̶t̶h̶i̶s̶ ̶w̶a̶y̶,̶ ̶w̶e̶ ̶h̶o̶p̶e̶ ̶t̶o̶ ̶c̶r̶e̶a̶t̶e̶ ̶a̶n̶ ̶e̶v̶e̶n̶ ̶s̶t̶r̶o̶n̶g̶e̶r̶ ̶n̶e̶t̶w̶o̶r̶k̶ ̶o̶f̶ ̶d̶e̶c̶e̶n̶t̶r̶a̶l̶i̶z̶e̶d̶ ̶h̶a̶r̶d̶w̶a̶r̶e̶ ̶u̶n̶d̶e̶r̶p̶i̶n̶n̶i̶n̶g̶ ̶t̶h̶e̶ ̶s̶e̶c̶u̶r̶i̶t̶y̶ ̶o̶f̶ ̶d̶e̶c̶e̶n̶t̶r̶a̶l̶i̶z̶e̶d̶ ̶n̶e̶t̶w̶o̶r̶k̶s̶!̶

̶U̶s̶e̶r̶s̶ ̶w̶i̶l̶l̶ ̶h̶a̶v̶e̶ ̶t̶o̶ ̶f̶o̶l̶l̶o̶w̶ ̶s̶o̶m̶e̶ ̶i̶n̶s̶t̶r̶u̶c̶t̶i̶o̶n̶s̶ ̶t̶o̶ ̶c̶r̶e̶a̶t̶e̶ ̶t̶h̶e̶i̶r̶ ̶p̶r̶i̶v̶a̶t̶e̶ ̶k̶e̶y̶s̶ ̶a̶n̶d̶ ̶w̶i̶l̶l̶ ̶b̶e̶ ̶r̶e̶s̶p̶o̶n̶s̶i̶b̶l̶e̶ ̶f̶o̶r̶ ̶m̶a̶i̶n̶t̶a̶i̶n̶i̶n̶g̶ ̶t̶h̶e̶ ̶v̶a̶l̶i̶d̶a̶t̶o̶r̶ ̶a̶n̶d̶ ̶a̶v̶o̶i̶d̶i̶n̶g̶ ̶s̶l̶a̶s̶h̶i̶n̶g̶.̶ ̶I̶n̶ ̶o̶r̶d̶e̶r̶ ̶t̶o̶ ̶q̶u̶a̶l̶i̶f̶y̶ ̶f̶o̶r̶ ̶t̶h̶i̶s̶ ̶d̶e̶a̶l̶,̶ ̶t̶h̶e̶ ̶D̶A̶p̶p̶N̶o̶d̶e̶X̶t̶r̶e̶m̶e̶ ̶m̶u̶s̶t̶ ̶b̶e̶ ̶p̶u̶r̶c̶h̶a̶s̶e̶d̶ ̶w̶i̶t̶h̶ ̶N̶O̶D̶E̶ ̶t̶o̶k̶e̶n̶s̶ ̶a̶n̶d̶ ̶r̶e̶g̶i̶s̶t̶e̶r̶e̶d̶ ̶t̶h̶r̶o̶u̶g̶h̶ ̶t̶h̶i̶s̶ ̶f̶o̶r̶m̶.̶

—

We hope this incentivizes more people to become node runners and continues to push forward the ethos of decentralization. We look forward to watching the Gnosis ecosystem continue to thrive and grow.

—

Do you have any questions? Join DAppNode’s discord, where we have a dedicated channel for Gnosis Beacon Chain validators!

If you want to be the first to find out about any new DAppNode updates, follow us on Twitter or check out our blog. You can engage with our community on our Discord server or our forum.

DAppNode and Gnosis Chain — Node Incentive Program was originally published in DAppNode on Medium, where people are continuing the conversation by highlighting and responding to this story.

DAppNode Runners will be able to become operators in SSV.Network, offering their machines to validate safely with deposits from those who want to validate but don’t have the hardware, expertise or time

SSV.Network is an Ethereum based community effort to develop the first secure and robust way to split an ETH staking validator key between non-trusting operators and deliver network-wide improvements for decentralization and security. What they are building is highly customizable and DAppNode can build on top of it to develop a solution to leverage the decentralized hardware network made out of the DAppNode Runners to secure the network safely and in a decentralized, non-custodial way.

Eth2 is, by design, meant to be run by anyone. This is because a network that is able to run in most setups, is a lot more resilient to governmental or big power pressure, centralized service outages and cataclysm among others. Basically, if lots of people run validators everywhere, it doesn’t matter whether AWS goes down or the US Govt. declares that creating a block with an unregulated stablecoin is illegal; the chain will go on thanks to all those who are anonymously validating from who knows where.

DAppNode has built up a solution to help anyone run a validator, and has a numerous community of validators. With SSV.Network, we can leverage this Node Runners’s hardware and expertise to include decentralized hardware to the SSV.Network list of operators!

Baby steps

In the most naive implementation, DAppNode users can offer themselves as SSV Operators so they can validate for other people and get rewarded thanks to the SSV.network.

This opens up the door for someone spinning up lots of DAppNodes in the hope to be randomly assigned a minimum of 3 parts of the same key, and then be able to:

• Slash the validator
• Ask for a ransom the deposit’s owner

Demanding ransom would just trigger an immediate exit from the staker, leaving the attacker with nothing; and just slashing also does not give the attacker any economic benefit. Hence we put the probability of this attack as very low and unfeasible.

Nevertheless, it opens the door to a large-scale attack on the Ethereum network as a whole, where you silently try to control as many validators as possible and then cause maximum havoc due to correlation penalties.

To avoid this, someone depositing their validator keys into SSV.Network testnet should choose a maximum of 2 DAppNodes… and, problem solved!

In the future, DAppNode will become an operator in itself and build security measures with all the bells and whistles to give validators and operators the best possible experience.

This is one of the first steps for a full-fledged ValidatorDAO, so testing by current DAppNode users is greatly appreciated.

How to participate?

1- Get on your DAppNode and look for the ssv.network package in the DAppStore or click this link while connected to your DAppNode.

2- During install, you will be guided by the setup wizard to perform a simple command and generate a SK (Secret Key)

You will have to run this command in a machine that has docker installed (your dappnode has it, but you can use any other) via command line / terminal:

$ docker run — rm ‘bloxstaking/ssv-node:latest’ /go/bin/ssvnode generate-operator-keys

If you want to access the terminal of your DAppNode but you are unsure on how to do it, you can follow Step 1 of this tutorial (only Step 1!).

From this you will create a PK (Public Key) and a SK (Secret Key). They are identified as such and between “ “ (not included!).

Make sure you save this output somewhere safe! For now you only need the SK in the first box as indicated, the rest has already been prefilled for you :)

Time to hit “install”!

If you don’t have the prerequisite packages, Goerli and Prater, it will also install them. Bear in mind that SSV won’t work properly until both Goerli and Prater’s beacon chain are synced.

3. Once the package is installed, open it and read the Getting Started section. It will guide you to SSV.Network’s test webapp where you can register your operator! You’ll need some Goerli ETH to submit the registration on-chain.

In order to be acknowledged as a part of this testing batch, you should name your operator starting with the word DAppNode + whatever name you would like to give your operator.

Moreover… there’s an incentivized testnet coming up where you will be able to earn SSV tokens by running a node! By starting the testing now you will be ready when the incentives drop 🔥🔥🔥

⚠️ Are you experiencing the following issue right after the installation ?

2p/p2p.go:178 IP address is not accessible {“app”: “SSV-Node:v0.0.16”, “component”: “p2p”, “id”: “16Uiu2HAmJV4oiFA7mRu8y8ZzKyAQuJVp9aBsJAw47oexDXxFqjVP”, “error”: “dial tcp X.X.X.X:13000: i/o timeout”}

The issue is due to an internal check done by the SSV package, which will be edited in the near future. To solve it you will have to disable the firewall for the port 13000, on Debian machines:

sudo ufw disable

After the installation you will be able to put back on again ufw with

sudo ufw enable

We know this is not ideal, but we are working with the SSV team to create a fix for next versions.

Do you have any questions? Join DAppNode’s discord, where we have a dedicated channel for SSV and reach out to one of the @core team members!

You think this is a good idea for DAppNode? Hit the DAppNodeDAO temperature check post in its forum here.

To keep up with SSV’s efforts to make trustless delegated validation a reality, join SSV.network’s discord!

DAppNode and SSV.Network: Decentralized hardware for shared validators was originally published in DAppNode on Medium, where people are continuing the conversation by highlighting and responding to this story.

TLDR:

• All Gitcoin donors that donated more than 1 USD will receive their NODEdrop.
• Some ETH, USDT and USDC donors of over $1 were mistakenly left out of the initial distribution.
• The price of the ETH donation on the day of the donation is what counts, not the current price
• It will take a few days to create the technical solution to include those that have been left out

After the deployment of the NODEconomy, we realized we made two mistakes.

One of them was a mistake in communications, where the threshold for Gitcoin donors to receive an airdrop was stated as $0.15 USD, when it was actually $1. This has been corrected.

The second one was a mistake in validating the donation for the NODEdrop. It was supposed to filter for a value of more than 1 USD, but, for ether donations, it ended up filtering out all donations below 1 Ether. A similar issue happened with USDC and USDT.

To be clear:

Everyone that has donated for a value of more than 1 USD will receive a NODEdrop

The issue now is with those who have donated with ether for more than 1 USD value and their donation has not been counted towards the NODEdrop. Those in this category are upwards of 2000+ transactions, and we are coming up with a plan to include them in the NODEdrop.

To make this happen, we must overcome two hurdles:

1. Since the merkle drop contract did not include the 2000+ addresses that are missing, we will need to deploy another Smart Contract. The testing, deployment and plugging to the UI might take some time, so it will probably happen in the following days more likely than hours.
2. Since the token distribution towards the NODEdrop was divided among the addresses counted, we will need to fund the NODEdrop with other funds.

We’re working hard at trying to fix this ASAP, so we can dedicate our efforts to building an ecosystem for Node Runners!

NODEdrop Update was originally published in DAppNode on Medium, where people are continuing the conversation by highlighting and responding to this story.