Introduction:

Blockchain is the technology that drives all cryptocurrencies. In each of them, a group of validator nodes is responsible for validating all transactions. Assume validators are rational and self-interested, i.e. they are only interested in earning as much money as possible themselves. Under such assumptions, it is generally assumed that the required majority of validators will agree on the order in which transactions have ever occurred on the blockchain.

However, such blockchain validator nodes are usually expensive in terms of the amount of disk space required. For example, the oldest and most popular cryptocurrency, Bitcoin, requires about 200 GB of disk space to store the entire transaction log. This makes it necessary to have a high-speed Connect and a lot of time to even start mining or validating. This problem has prompted researchers to propose sharding as a solution, storing only part of the log in each node, but storing the entire log as a whole. Sharding involves Verifying the transaction.

But does it make sense for nodes to store transaction logs from the genesis block? This is an important question to answer before such solutions can be formulated.

To understand if it is possible/needed to keep all transaction logs, we consider the following –

1. Does the entire transaction log need to be stored to verify transactions? 2. Is storing transaction logs more secure than not storing them? 3. Can validator nodes be incentivized to store logs?

We will discuss these points in the rest of this article.

Is it necessary to store the entire transaction log to verify transactions?

To verify a transaction, the only thing a node needs to do is know the state of the blockchain prior to the transaction. How this state is achieved is not important. So storing the state after each block is enough. In fact, we can go even further—because already Blocks mined long before the current time are almost never undone. It is safe to delete all previous blocks.

A natural question that comes to our mind is whether it somehow compromises the security of the blockchain, ie – does it somehow cause the blockchain to approve incorrect transactions based on the current state of the blockchain? To answer this question, we proceed to the next part.

Is storing transaction logs more secure than not storing them?

When thinking about it, we need to consider the security of the entire transaction, not just the part on the blockchain. Most transactions have two parts – the payment on the blockchain and the receipt of something of value in exchange. The second part of the transaction is not stored in the blockchain. This means that a seller who sells a product or service in exchange for some cryptocurrency relies on the blockchain not to resume the transaction after he/she has provided the product or service. This in turn means that there must be a reasonable time after which the trade must become completely immutable, requiring the block containing it to be immutable as well. In other words, we need transaction and block finality. When a block is completed in some form or other, it is possible to forget what happened before and simply continue as if the block is the genesis block. This usually means that transaction history can only be stored for a short period of time. For Bitcoin, people usually think that a block is basically finalized after an hour, so it makes sense to delete all previous history. That means that in the case of Bitcoin, validators only need the list of UTXOs at the end of each of the last few blocks.

We now turn towards our final point.

Can validator nodes be incentivized to store logs?

As mentioned earlier, validators are assumed to be selfish and rational. This means they need to be paid or rewarded for doing anything. Since validators are only paid in cryptocurrency for mining blocks in all public blockchains, this is the only thing they should be doing. We have Also see that the storage of data is not necessary to complete the validation work. Therefore, there is no incentive for any validator to store the entire transaction log from genesis. If we really want rational validators to store the entire history We must sufficiently incentivize validators to do so. We may need proof of storage of all transactions in a block to be considered valid. Is it possible to do it? Indeed, if we change the proof-of-work consensus protocol as follows – 1. Let a block is proposed as B, and the corresponding proof-of-work is p. This means that p is a nounce satisfying hash(B||p) < threshold. 2. Let the number of transactions before this block be N. 3. Let h = hash(B||hash(p)) where || means concatenation. 4. Compute the remainder r of dividing h by N. Since h is usually a 256-bit number, h must be much larger than N, so this means that r is smaller than h and N, and can be considered a random sample from the set of natural numbers smaller than N. 5. Let the transaction number r be tr. Transactions are indexed From 0 to N-1. 6. Now the block proposal must be (B||p|| tr ) to be considered valid.

It’s easy to see that if a validator doesn’t store all the transaction logs, then it needs more effort to generate valid blocks, because if the corresponding transactions aren’t stored, it has to discard all the proof-of-work and start over through it. More specifically, if the validator is stored in Over all history, it has to discard the fraction f of proof-of-work 1/f times on average significantly reducing the average mining reward for the same processing power. Therefore, it is most efficient for any validator to simply store all transactions from the genesis block. but No such system is in use yet, so validators are effectively providing a social service by storing all transactions. However, it is clear from our discussion of security that such modifications may be completely unnecessary.

Another problem is that when a new validator joins, it must download the entire transaction log from its peers. However, nodes have no incentive at all to feed this data to their new peers. They’re just adding competitive mining capacity while also adding their own bandwidth to broadcast information. The least we can do is save them from having to broadcast the entire transaction history.

Conclusion:

We can see that if we choose to design the blockchain in this way, it becomes mandatory to store all transaction histories. However, this seems very unnecessary and cumbersome. It could even give existing miners more incentive to provide the data they need to any new entrants. us Also see that there is no advantage to storing transaction history in terms of the security of the blockchain, so we don’t want to do that either.