From adbdb3c76e6b50b6498b537e72fb46ae7dca5135 Mon Sep 17 00:00:00 2001 From: teor Date: Tue, 27 Oct 2020 20:13:49 +1000 Subject: [PATCH] Note that `blocks_by_height` is also a bijection --- book/src/dev/rfcs/0005-state-updates.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/book/src/dev/rfcs/0005-state-updates.md b/book/src/dev/rfcs/0005-state-updates.md index 3692cb02..36cfa2c5 100644 --- a/book/src/dev/rfcs/0005-state-updates.md +++ b/book/src/dev/rfcs/0005-state-updates.md @@ -613,9 +613,14 @@ Zcash structures are encoded using `ZcashSerialize`/`ZcashDeserialize`. ### Notes on Sled trees -- The `hash_by_height` and `height_by_hash` trees provide the bijection between +- The `hash_by_height` and `height_by_hash` trees provide a bijection between block heights and block hashes. (Since the Sled state only stores finalized - state, this is actually a bijection). + state, they are actually a bijection). + +- The `block_by_height` tree provides a bijection between block heights and block + data. There is no corresponding `height_by_block` tree: instead, hash the block, + and use `height_by_hash`. (Since the Sled state only stores finalized state, + they are actually a bijection). - Blocks are stored by height, not by hash. This has the downside that looking up a block by hash requires an extra level of indirection. The upside is