↓Skip to main content

What does a block look like?

·11 mins·
status-update
Author
Nazar Mokrynskyi

The question might seem somewhat obvious: you have a header and a body with transactions, many blockchains have it, what might be so difficult about it? Well, as I mentioned in the previous update, there are some complications and part of the challenge is related to the fact that we’re dealing with sharded architecture, which most blockchains don’t need to deal with.

Sharding architecture
#

The sharding design is not fully worked out yet, but it is quite certain that it’ll be hierarchical and look something like this:

L e a f I s n h t a e r r d m e 1 d 1 i a t e L e s a h f a r s d h a 1 r B d e a 1 c 2 o n c L h e a a i f n I s n h t a e r r d m e 2 d 2 i a t e L e s a h f a r s d h a 2 r d 2 2

So it is a tree with a Beacon chain at the top of the hierarchy, with intermediate shards below it and leaf shards at the bottom. The architecture supports about one million shards in total.

The shards are using a shared namespace for addresses and support cross-shard communication with both the ability to send information between shards and using contracts deployed on any shard on any other shard.

All this implies the need to be able to prove and verify that things exist or have happened on other shards, while only having access to the beacon chain block root. While at it, we’d like for proofs to be efficient too, which means both block header and block body need to be designed in a way that co-locates related information and minimizes the depth of various Merkle Trees.

In addition to cross-chain communication, we have to combine segments produced by individual shards into a global history, which also needs to be represented in a block in some verifiable way.

While the actual number of shards will be larger than on the above diagram, the number of layers is expected to be the same. This also means that both headers and bodies for different kinds of shards will be different. For example, the beacon chain will have no user transactions and leaf shards will have no shards below it. There are many more differences, of course.

Current state
#

While the current version is certainly not final, I think it’ll give a good idea of what to expect and how things work together. I’ll visualize it as a tree of trees, where you can think of every tree as a Merle Tree. It is about 95% accurate (there are segment root proofs missing on the diagram due to the difficulty to show them correctly).

Leaf shard block
#

Leaf shard blocks are the simplest. They reference the beacon chain in the header (which defines some consensus parameters) and include segment roots and transactions in the body.

B l o c k H e a d e r B o d y C o n s O T e w r n B n a s e n u a s s P R s c e a r e o g c e s i S n m t f u n e e i i l f a c n o x t o l h t n a s i r n o o i t v n s t p m b s s p f s p s n s e u h i a m o t l r u o u i f r m a m r r d a o o t l b g o s b r e e y t t o u u l n [ i e d s n r e f r t i a o r t t o r n e i c t t n i a o o r u o o u r n m r t o o m f p n k r a d p o t o b r e e b b [ n e o t e t o y l l s x t r i o o o s a m f c c e c e k k g t o m i f n r e o u o n n t m o t i b t ] m e r e r o o t ] G h e e n a e d r e i r c

Intermediate shard block
#

Intermediate shards on top of what is done by leaf shards need to include information about leaf shards in both block header and body.

B l o c k H e B a o d d e y r O w C n o n s s e L e g e n B m a T s e C e f r u a h n L a P R s c i t e s n r e o l a h s e s i S n d r f a a f u n e o r c i l f a c s o s d t x t o l h h t h i a a s a s o i r r e n n d d g s m i b b e v n s t p m b s s p f s p s n l l n e u h i a m o t l r u o u i f o o t r m a m r r d a o o t l b g o c c s b r e e y t t o u u l n k k r i e d s n r e f r t i a s [ o o r t t o r n e i c t h o [ n i a o o r u o o u s e t n m r t o o m f p n k r e a s t d p o t o b r e e b b g d r e o t e t o y l l m e a x t r i o o o e r n m f c c n s s e k k [ t a o c f n r b r t u o l o [ i t m o o o o i b t c t o n m e k w e r ] [ n ] r o b s o l e t o g c m G h ] k e e e n n a h t e d e r e a r i r d o c e o r t s ] ]

Beacon chain block
#

Beacon chain replaces reference to the beacon chain with actual consensus parameters. It still tracks child shards, but also contains PoT checkpoints in its body for faster verification later.

B l o c k H e B a o d d e y r C o n O s C w e h C n I n i o n s l n s t u d s e e P R s e g r r e s n m m e s i S h s e e f u n e a u n d I P i l f a r s t i n o x t o l d a t T p r r e b a o e r c l r o m h o a t s e e c m s h d c v n s t p m b s s p f s p s k e a i k e u h i a m o t l r u o u i s t r a p r m a m r r d a o o t l b g e d r o s b r e e y t t o u u l n r e i i e d s n r e f r t i a s s n o r t t o r n e i c t e s t n i a o o r u o o u g h s n m r t o o m f p n k r m a d p o t o b r e e [ e r e o t e t o y [ n d x t r i o s p O O O } s t m f b o o p p p p > e b e l l t t t t o g r l o o u i i i t m o o f c t s o o o e o c [ k i l n n n p n t k t o o < < < a t s c i r n t s n { r s s e h h m o u e a l l n r e e e o r i p x m o o t o a c t a t e t e t t r o d k n e r t o t e p ] g r s e i p r o e a s o r t y ] s i t e l s e [ ] n G h i g u r o c t e e o m t c a w h n a n e i h t n i ] e d s n o a i l r e t n n o s d i r g n e c r r e s g s [ o a m e o n e g b t g n m l > e t e o > n c r t k o o r h t o e s o a . t d . s e , . r . ]

As you can see, all three block types share some similarities, but also have unique differences dictated by their role.

Now if we need to prove that something was stored in leaf shard, we can do that by generating proofs for the following path:

B e a c o n c h S S a t t i a a n t t e e b l r i o o t c o e k t m r o o t R e s u l C t h i l d s L h e a a r f d s b h l a o r c d k s b l o c k I r n o t o e t r m e d i a C t h e i l s d h a s r h d a r b d l o b c l k o c r k o s o t

This way we can reach any piece of block header or body or anything stored in a state of any block. Not only that, information submitted from leaf shards to the intermediate shards and from intermediate shard to the beacon chain is verifiable for integrity (that segment roots correspond to the header). Moreover, since all block roots are added to the MMR, any historical information can also be proven/verified as well. It trees all the way down!

The whole structure and decoding ability was introduced in PR 245 with follow-up fixes in PR 246. There are no builders or owned versions of the data structures yet, but it will be easier to have them now that the structure is known.

There will be more changes to this in the future once/if we have to deal with data availability and potential misbehavior, but this should be sufficient for now.

Block root?
#

You may notice that instead of “block hash” I used “block root.” That is simply a reflection of the fact that a header in itself is a Merkle Tree. Our headers are larger than those in blockchains like Bitcoin, so it is desirable to compress the size of the proof when only a small part of it is needed (like timestamp).

Upcoming plans
#

I hope you appreciate the ASCII art, I spent a non-negligible amount of time formatting it 😅.

With block layout in this state, I’ll need to write even more boilerplate for builder and owned versions of data structures. Once that is done, I’ll be back to consensus verification in an attempt to get primitive blockchain going. There are still some open questions around plotting, but I think we have a pretty good intuition with Alfonso for how to approach it.

We post even more research updates on our Zulip as they happen, including meeting notes from out 1:1s with Alfonso.

With that, I’ll see you next time with more updates and maybe even more ASCII art 😆.