From 5e4883ccbf4ed203edfd0d0c191ce8a0c0b0d7b4 Mon Sep 17 00:00:00 2001 From: Justin Date: Tue, 4 Dec 2018 15:50:44 +0000 Subject: [PATCH] Stick with Keccak-256/SHA3 for now See https://github.com/ethereum/eth2.0-specs/issues/218 --- specs/core/0_beacon-chain.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/core/0_beacon-chain.md b/specs/core/0_beacon-chain.md index 8d76006a8..47bb6d969 100644 --- a/specs/core/0_beacon-chain.md +++ b/specs/core/0_beacon-chain.md @@ -1560,7 +1560,7 @@ while len(state.persistent_committee_reassignments) > 0 and state.persistent_com # Appendix ## Appendix A - Hash function -We aim to have a STARK-friendly hash function `hash(x)` for the production launch of the beacon chain. While the standardisation process for a STARK-friendly hash function takes place—led by STARKware, who will produce a detailed report with recommendations—we use `BLAKE2b-512` as a placeholder. Specifically, we set `hash(x) := BLAKE2b-512(x)[0:32]` where the `BLAKE2b-512` algorithm is defined in [RFC 7693](https://tools.ietf.org/html/rfc7693) and the input `x` is of type `bytes`. +In Phase 0 the beacon chain is deployed with the same hash function as Ethereum 1.0, i.e. Keccak-256 (also incorrectly known as SHA3). We aim to migrate to a S[T/N]ARK-friendly hash function in a future Ethereum 2.0 deployment phase. # References