You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hashgraph will propose two new HIPs, one for Block Streams, and one for Block Nodes. The ideas behind these were first born well over a year ago. Since they have such a huge impact on the system and the ecosystem, it has taken a lot of effort to work out the details very carefully.
Today, each consensus node independently gossips with other consensus nodes, agrees on the order of transactions, handles those transactions, and emits record streams, event streams, and saved states. Each node independently signs these files and uploads their signature files too. These are stored in AWS / GCP public buckets. Anyone in the world can download those files. Mirror nodes download record stream files.
There are some challenges with this design:
Along the path to full decentralization, the record streams should be stored more widely (i.e. beyond AWS/GCP)
It is very expensive to access these files. While mirror nodes can be configured to only store a subset of the history, they must download the full record file and they must download sufficient signature files to verify the record file has been signed by 1/3 of the network. And mirror nodes must "list" files on GCP/AWS and this also costs money.
These were the initial two problem we set out to solve. Along the way, we found that redesigning the record stream led to enormous benefits far outside these two initial criteria.
The entire idea would make a very long thread, we have tried to document this thoroughly in the HIP that we will publish. But here are some high-level design concepts and benefits.
First, we propose to replace the three sets of files (events, records, saved states, and their signature files) with a single Block Stream. A Block Stream is simply a stream of blocks. Each block contains the events and transactions that went into producing that block, the full entities that were changed as part of handling that block, and a network signature on the block. The network signature is from the family of cryptographic signing technologies called BLS -- we call our specific implementation TSS.
This block stream has enormous benefits. The block is completely self-contained and since it is signed by the network, it carries with it the full trust of the network. Since it doesn't contain a delta of changes to entities, but the entire entity that was changed, it is not necessary for a mirror node to read the entire chain history to construct a mirror node's state for a particular entity -- it only needs the latest block in which that entity was updated. Blocks can be delivered through any content delivery mechanism without having to trust the delivery mechanism, since each block has trust self-contained within it. And anyone with access to blocks can construct both block proofs and state proofs! And with state proofs, we open the door to inter-ledger communication and inter-shard communication.
A Block Node is a new type of node we propose to build that, like mirror nodes, can be run by anyone. They will have a rich API, allowing consumers to receive a subset of the stream, or the full stream. Consequently, lightweight "filtered" mirror nodes that, for example, are only interested in a specific HCS topic or a specific set of accounts will not have to download every block to maintain their state. BlockNodes can innovate on payment -- they can be commercial and have connectivity rules / rate limits / SLAs for customers. They can require payment for serving blocks, or they can serve blocks for free.
Since a block stream contains blocks, and each block contains all state changes, block nodes are able to reconstruct the full merkle tree, and verify everything done by the consensus nodes. They will have access to all events that came to consensus, so they can rerun the hashgraph consensus algorithm and verify the results. They can reapply all the state changes and have a complete copy of the current state (as of that block) and verify the root hash of the merkle tree by using the block signature. They can independently verify everything done by the consensus nodes, and generate state proofs and answer queries based on the current state. This is very powerful for decentralization.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hashgraph will propose two new HIPs, one for Block Streams, and one for Block Nodes. The ideas behind these were first born well over a year ago. Since they have such a huge impact on the system and the ecosystem, it has taken a lot of effort to work out the details very carefully.
We have the following main nodes in Hedera today:
Today, each consensus node independently gossips with other consensus nodes, agrees on the order of transactions, handles those transactions, and emits record streams, event streams, and saved states. Each node independently signs these files and uploads their signature files too. These are stored in AWS / GCP public buckets. Anyone in the world can download those files. Mirror nodes download record stream files.
There are some challenges with this design:
These were the initial two problem we set out to solve. Along the way, we found that redesigning the record stream led to enormous benefits far outside these two initial criteria.
The entire idea would make a very long thread, we have tried to document this thoroughly in the HIP that we will publish. But here are some high-level design concepts and benefits.
First, we propose to replace the three sets of files (events, records, saved states, and their signature files) with a single Block Stream. A Block Stream is simply a stream of blocks. Each block contains the events and transactions that went into producing that block, the full entities that were changed as part of handling that block, and a network signature on the block. The network signature is from the family of cryptographic signing technologies called BLS -- we call our specific implementation TSS.
This block stream has enormous benefits. The block is completely self-contained and since it is signed by the network, it carries with it the full trust of the network. Since it doesn't contain a delta of changes to entities, but the entire entity that was changed, it is not necessary for a mirror node to read the entire chain history to construct a mirror node's state for a particular entity -- it only needs the latest block in which that entity was updated. Blocks can be delivered through any content delivery mechanism without having to trust the delivery mechanism, since each block has trust self-contained within it. And anyone with access to blocks can construct both block proofs and state proofs! And with state proofs, we open the door to inter-ledger communication and inter-shard communication.
A Block Node is a new type of node we propose to build that, like mirror nodes, can be run by anyone. They will have a rich API, allowing consumers to receive a subset of the stream, or the full stream. Consequently, lightweight "filtered" mirror nodes that, for example, are only interested in a specific HCS topic or a specific set of accounts will not have to download every block to maintain their state. BlockNodes can innovate on payment -- they can be commercial and have connectivity rules / rate limits / SLAs for customers. They can require payment for serving blocks, or they can serve blocks for free.
Since a block stream contains blocks, and each block contains all state changes, block nodes are able to reconstruct the full merkle tree, and verify everything done by the consensus nodes. They will have access to all events that came to consensus, so they can rerun the hashgraph consensus algorithm and verify the results. They can reapply all the state changes and have a complete copy of the current state (as of that block) and verify the root hash of the merkle tree by using the block signature. They can independently verify everything done by the consensus nodes, and generate state proofs and answer queries based on the current state. This is very powerful for decentralization.
Beta Was this translation helpful? Give feedback.
All reactions