1/ As I promised yesterday, I am going to write a thread about @CelestiaOrg but before diving into what Celestia is, in this thread, I wanna start exploring some of the basic concepts that you need to know to understand why Celestia exists? Let's start 👇 .....
2/ Data availability is the problem that #Celestia is trying to solve, but what is it?
In a nutshell, we ask the following question:
Is the data behind the given block is available to the network? So that we can make sure there is no malicious transaction inside that block. 👇
In a nutshell, we ask the following question:
Is the data behind the given block is available to the network? So that we can make sure there is no malicious transaction inside that block. 👇
3/Hmm okay, well I need to explain couple more things.
In the Blockchain, each block has 2 pieces:
1- Block Header, This is the meta-data of the given block. There are some information about the given block, one of them is the Merkle Root of transactions. 👇
In the Blockchain, each block has 2 pieces:
1- Block Header, This is the meta-data of the given block. There are some information about the given block, one of them is the Merkle Root of transactions. 👇
4/ As you probably know all transactions have a hash, and each block has various numbers of transactions, You can think of Merkle root as the hash of all the given transactions. So instead you have many hashes, you only have one which is called Merkle root. 👇
5/ 2- Transaction data, this is the actual transactions in that given block. 👇
6/ Also, there are generally two types of nodes in the chain (There are actually more but I am not going to discuss them here I might do a different thread for them later) 👇
7/
1- Full nodes that download and check that every transaction in the blockchain is valid. This requires a lot of resources.
2- Light nodes only download the block header, and assume that the block only contains valid transactions. Therefore they are less secure.
👇
1- Full nodes that download and check that every transaction in the blockchain is valid. This requires a lot of resources.
2- Light nodes only download the block header, and assume that the block only contains valid transactions. Therefore they are less secure.
👇
8/ How does a light client actually check if the transactions in the given block are valid or not?
The below diagram shows the way. We have a way called fraud-proof that a specific transaction in a block is valid or not. 👇
The below diagram shows the way. We have a way called fraud-proof that a specific transaction in a block is valid or not. 👇
9/ But How full nodes generate the fraud-proof? 👇
10/ Hmm so Full nodes have to go and ask Block Producers for the data in that given block. So that they can generate the proof and send it to light clients. 👇
11/ What if we have the below scenario? What if the block producer only publishes the block header but not the transactions? 👇
12/ It is a requirement that block producers must publish all the data for their blocks, but we don't want light nodes to download all the data, otherwise, we break the rule for being a light client. 👇
13/ How do we solve this?
Hmm well, this is going to be discussed in the next thread, I already gave quite a good amount of information for the people who don't know the concept. See you in the next thread 🙂
Hmm well, this is going to be discussed in the next thread, I already gave quite a good amount of information for the people who don't know the concept. See you in the next thread 🙂
• • •
Missing some Tweet in this thread? You can try to
force a refresh
