Connect with us

Ethereum

Validated, staking on eth2: #4 – Keys 🔑

Published

on

Validated, staking on eth2: #4 - Keys 🔑



Special thanks to Sacha Yves Saint-Leger & Danny Ryan for their review.

At the core of every Proof of Stake system is a signature scheme. Signatures are used to verify the identity of each validator allowing their actions, both good and bad, to be attributed to them.

We can verify honesty by looking at a validator’s signed messages and we can prove malice by showing messages that violate the rules of consensus.

In fact, in eth2, the identity of a validator is their public key. Specifically, each validator has two sets of keys: a signing key and a withdrawal key.

Signing keys

A signing key is the key a validator needs to sign attestations and propose blocks. Because a validator needs to sign a message at least once per epoch, the client software must have custody of the key.

Withdrawal keys

Because the client software is always connected to the internet, there is of course a chance that one’s signing key is compromised. To reduce the impact of such a breach, the actions a validator can perform are split between two keys.

The signing key, as explained above, is used for the validator to perform their duties. On the other hand, the withdrawal key has the power to control a validator’s funds (transferring*, and withdrawing* ETH).

A validator should only need to use their withdrawal keys a few times over the lifetime of being a validator. This means they can be put into cold storage and stored with a high degree of security (offline).

* Transfers and withdrawals are not enabled until at least phase 1

That’s a lot of keys!

If for every 32ETH staked, one needed to save and use 2 unrelated keys to make a deposit, this would get out of hand very quickly.

Luckily, we have a solution. The remedy is to have the keys use a common secret, so that storing a single secret gives access to multiple keys.

In eth2, this is achieved via EIPs 2333 and 2334: a set of standards that describe how withdrawal and signing keys are related, and how they can be derived from a single mnemonic.

Mnemonics

Mnemonics are another way of encoding secrets and are a much simpler means for people to store and back up their private keys.

The idea being that it is simpler to remember or write down sausage solution loud isolate focus glide frame door clown million shuffle impulse than 0x1e9f2afcc0737f4502e8d4238e4fe82d45077b2a549902b61d65367acecbccba without making any mistakes.

Deriving keys from other keys

When interacting with wallets, you may have encountered “paths” of the form m/44’/60’/0’/0/0. These paths describe a relationship between keys.

According to EIP 2333, this relationship takes the form of a tree structure in which a key is determined by a source of entropy (the tree’s seed) and a tree path.

We use the seed to calculate the root of the tree and then build the tree in layers on top of this root. This tree of keys is defined purely through the relationship between the branch followed in the tree, and the tree’s root.

In practical terms, it allows us to find any key in the tree by starting at the root, and calculating the intermediate key at each branch we follow, until we reach the leaf we are interested in.

A wonderful consequence of this is that we can start with a single source of entropy (a mnemonic, for example), and from there build out a practically unlimited number of keys.

In addition, by securely storing just the mnemonic, you have a backup of every key that your validator uses.

This idea is used in eth2 to allow a single mnemonic to generate as many keys as a validator needs. For example, if you wanted to run 3 validators, you could use a single mnemonic to generate the withdrawal keys located at
m/0,
m/1,
m/2.

      [m / 0]
     /
    /
[m] - [m / 1]
    
     
      [m / 2]

Each branch is separated by a / so m/2 means start with the master key and follow branch 2.

EIP 2334 states that the validator’s signing key is the 0th child-branch of the withdrawal key. In practice this means that, when the standard is followed, if you know the private key for withdrawal, you can calculate the corresponding private key for signing.

Continuing with the above example, the signing keys would be found at:
m/0/0,
m/1/0,
m/2/0.

      [m / 0] - [m / 0 / 0]
     /
    /
[m] - [m / 1] - [m / 1 / 0]
    
     
      [m / 2] - [m / 2 / 0]

While we tried to keep this example as simple as possible, in practice the paths involved are a little longer (EIP 2334 requires using m/12381/3600/i/0, and m/12381/3600/i/0/0 for withdrawal and signing keys respectively). Nevertheless, the logic remains the same.

The important thing to remember is that if you know the mnemonic, you can calculate your withdrawal keys, and from there derive your signing keys.

Storing keys

Validator clients use keystores as a method for exchanging keys.

Keystores are files that contain private keys encrypted with a user’s password. They can be safely stored and transferred between computers provided the password is not stored on the same computer.

When you are ready to start validating, you can give your client the keystores and the password encrypting them (it needs both pieces of information to import your keys).

Becoming a validator

The first step in becoming a validator is to generate the appropriate keys. These will be generated once you’ve written down your mnemonic.

Since there are no withdrawals or transfers in phase 0, you do not need to have keystores for your withdrawal keys; storing your mnemonic safely is sufficient.

As your validator clients need your signing keys, you will receive a keystore for each of your validators to store these keys.

Now it’s deposit time! To become a validator, you will need to send 32 ETH per validator in addition to your deposit data containing all of your validator public keys.

The deposit data are then recorded in the deposit contract on eth1. This contract is watched by eth2 nodes who are responsible for copying over the deposit data. Once your deposit data has been copied over, you are now officially a validator!

Becoming a validator the easy way

We’re happy to announce that we’ve been working hard on a friendly interface to walk validators through this process. Stay posted for an update shortly on what the Eth2 Launchpad is and how to use it!



Source link

Continue Reading
Click to comment

Leave a Reply

Your email address will not be published.

Ethereum

eth2 quick update | Ethereum Foundation Blog

Published

on

Ethereum Muir Glacier Upgrade Announcement


Although the internet has been more quiet than usual, we’ve been super busy hacking away on eth2! Between Devcon5 and keeping our heads down to work, it seems we’ve left the community in the dark on a couple of items. Here’s a quick update to fill in the gaps.

Deposit Contract

Although the deposit contract has been written, tested, and formally verified, we are working to allow the BLS standardization to stablize prior to launch. One goal of eth2 is to be easily interoperable with other blockchains and systems in general, and to that end, we do not want our BLS signatures to go the way of keccak (whoops!).

The BLS Standard (BLS Signature, Hash to Curve) has reached a point of stability recently with a number of blockchain teams on board (Eth2, Chia, Filecoin, Algorand, etc). There is an IETF meeting in November at which we expect the draft to be even more cemented. That said, official standards can take quite a while so those involved plan to signal public support for the draft and have a “blockchain agreement” to use the standard as drafted regardless of its final form in IETF. That way, if it becomes the keccak of signatures, we won’t be there alone. 🙂

Fortunately, the deposit contract does not need to be put into production until we near Phase 0 launch, so this focus on standardization is not expected to have any effect on the Phase 0 launch date.

Eth2 Testnets

If you follow ethresearch, the specs repo, or any of the many workshops at Devcon, we have altered the sharding proposal in such a way to greatly improve developer and user experience — cross-shard communication between all shards at every slot. To facilitate this improved design, we have to modify the Phase 0 spec a bit. To do this with limited disruption to Phase 0 development and testnets, we’ve gone the simplifying route — the removal of crosslinks entirely from Phase 0 (they were stubbed anyway). This change is coded and under final review here and is expected to be released for development within the week.

We expect multi-client public testnets to launch soon after this simplifying change is completed, for this update to aid Phase 0’s progress to mainnet, and ultimately to make Phases 1 and 2 easier to ship.

Eth2 testnets are coming! Individual clients are in the process of spinning on some nets for both private and public consumption. Many clients are just getting their eth1-to-eth2 machinery in place so these single-client testnets are useful in initially testing that component. On these nets there will be some limited cross-client testing, but will be largely stable due to having a majority single-client.

Once clients adequately test larger single-client nets and once they have time to incorporate the Phase 0 changes, we will be full speed ahead on public multi-client nets. We’re just as excited about this as you are and will be publishing more info on participation (staking your eth) in both testnets and mainnet shortly. Casper is indeed coming.



Source link

Continue Reading

Ethereum

eth2 quick update no. 2

Published

on

eth2 quick update no. 2


Welcome to the second installment of eth2 quick update.

tldr;

  • Spec release of v0.9.0 — Tonkatsu to ensure Phase 0 development can continue unimpeded.
  • Work continues in ironing out the details of the modified Phase 1 proposal.
  • Quiet client development focused on eth1 -> eth2 infrastructure, general hardening for production, and optimizations.

Tonkatsu Release

As promised on the latest eth2 call, we pushed things forward to release v0.9.0 release — Tonkatsu. This release is largely simplifying with respect to Phase 0. The goal here is to remove any portions of Phase 0 that are opinionated about Phase 1 to ensure Phase 0 development can continue unimpeded regardless of the work-in-progress modified sharding proposal.

Read the release notes for more info.

Ongoing Phase 1 Redesign

As mentioned in the last eth2 quick update, we are almost certainly taking a new and simpler direction for Phase 1. The new sharding proposal facilitates “crosslinks” for all shards at each slot. This drastically simplifies communication between shards and will result in a much better and simpler developer/user experience come Phase 2.

Previous cross-shard communication (approximate)

sharding-new-proposal

New shard design proposal

To support this new proposal, the total shard count to start must be reduced from 1024 to the new estimate of 64, with the intention to scale up the number of shards over time (~10 years) as standard resources available to consumer laptops increases. The following are the primary reasons for the requisite reduction in total shards:

  • Each shard induces an attestation load on the network and beacon chain at each slot rather than at each epoch
  • Each committee must be of a minimum safe number of validators. If there are too many committees per epoch due to high shard count, then there couldn’t possibly be enough 32-ETH validators to safely allocate enough to each committee

[EDIT: the following paragraph was added after initial release of the blog post in response to some discussion on reddit]

To achieve a similar scalability as the previous proposal, target shard block sizes are being increased 8x, from 16kB to 128kB. This provides the system with greater than 1 MB/s of data availability which synergizes well with promising L2 schemes such as ZKRollup and OVM. The network safety of these larger shard block sizes are justified by recent experimental research done on the existing Ethereum network.

Much of the EF research team’s focus in the past few weeks has been around vetting and ironing out the details of this new proposal. For more details, check out the work-in-progress PR or some of the Phase 1 issues.

Quiet, yet effective client development

Eth2 clients continue to quietly develop. As discussed on the latest eth2 call, effort is being put into handling deposits from eth1, generally hardening clients for production, optimization of state transition and BLS implementations, cross-client fuzzing, networking monitoring tooling, and more! Larger single client testnets are in the works as well as continued cross-client experimentation.

Now that v0.9.0 has been released, clients are updating their state transition logic to pass the new test vectors and are introducing the simple attestation aggregation strategy.



Source link

Continue Reading

Ethereum

Eth2 at ETHWaterloo: Prizes for Eth2 education, tooling, and research

Published

on

Ethereum Muir Glacier Upgrade Announcement


For the first time ever, the Ethereum Foundation will be sponsoring a range of hacker prizes related to Eth2 at a major hackathon.

With Eth2 development proceeding rapidly, there are now many discrete areas of work that a team of motivated hackers can complete over a weekend. The bounties below include useful educational tools for Eth2 development, necessary tooling, and valuable research.

Members of Eth2 teams will be available remotely during the hackathon to answer questions from hackers and provide advice related to these prizes.

The EF will offer 5 prizes of $1,000 each, for projects that tackle any (or more than one!) of the following ideas:

Education


Tooling

  • Implement the proposed BLS key standards (EIPs 2333, 2334, 2335) in a language of your choice (suggestion: one of the eth2 client languages)
  • Fast viz: Given just a single BeaconState, visualize the last events and validator registry state (suggestion: use lodestar code to work in the browser)
  • Attestation surround/double vote checker (suggestion: look at eth2.0-pm repo issue 63)
  • Attestation pool: make a bare bones tool that listens on the attestation aggregation subnets and global net, and show what’s there (suggestion: start with logging received attestations)
  • Beacon node load balancer: implement a validator API that proxies traffic to any healthy up-to-date beacon node (suggestion: take existing http proxy, and focus on the nodes health status)
  • Netstats2: log/visualize the health status of a list of eth2 testnet nodes (suggestion: prysm or lighthouse testnet, start with simple api queries like latest block)
  • Merkle multi proof builder: check out simpleserialize.com and the tree visualization. This could be enhanced with checkboxes in each node to interactively create multiproofs with (suggestion: start with a simple proof encoding format – Cayman Nava and Proto will be available to help on the ETHWaterloo discord)
  • Validator tracking: a service that you can point at a validator and it notifies you if the validator is offline.

Research


Interested in other bounties or prizes offered by the Ethereum Foundation?

Here are a few other bounties currently live:

Ethereum.org Gitcoin Bounties


Legendre PRF

  • The Legendre pseudo-random function is an extremely MPC-friendly one bit PRF. This PRF is currently slated to be used in the proof of custody scheme in Phase 1 of Eth 2.0, as it is the only known method to make the proof of custody possible in a shared secret setting. To encourage more research about this PRF, the Ethereum Foundation has set out a series of bounties here: legendreprf.org/bounties

STARK-Friendly Hash Challenge

  • The Ethereum Foundation has asked StarkWare to recommend a STARK-Friendly Hash (SFH). The StarkWare hash challenge is a public competition aimed at evaluating the security of current proposed SFH candidates. The challenge is proposed at four security levels: low-security, medium-security, target-security, and high-security in multiple scenarios. See starkware.co/hash-challenge for more details about the competition and how to get started.





Source link

Continue Reading

Trending