Difference between revisions of "Mini-blockchain"

From Mini-blockchain Project
Jump to: navigation, search
m (fixed image)
m (resized and relocated image)
Line 1: Line 1:
The mini-blockchain is 1 of the [[3 core components]] of the [[mini-blockchain scheme]], it performs the 1st [[functions of the blockchain|function of a blockchain]]. The mini-blockchain is essentially just a normal blockchain, except that we don't need to keep a copy of historic blocks. It isn't truly finite, because changing the max block size could increase the average size of the mini-blockchain. A mechanism for achieving a [[dynamic max block size]] is actually a part of [[Cryptonite]] but it's not a necessary part of the scheme.
+
[[File:mini-blockchain.jpg|right|thumb|350px|Figure 0-a: Mini-blockchain diagram.]]
  
[[File:mini-blockchain.jpg|right|thumb|500px|Figure 0-a: Mini-blockchain diagram.]]
+
The mini-blockchain is 1 of the [[3 core components]] of the [[mini-blockchain scheme]], it performs the 1st [[functions of the blockchain|function of a blockchain]]. The mini-blockchain is essentially just a normal blockchain, except that we don't need to keep a copy of historic blocks. It isn't truly finite, because changing the max block size could increase the average size of the mini-blockchain. A mechanism for achieving a [[dynamic max block size]] is actually a part of [[Cryptonite]] but it's not a necessary part of the scheme.
  
 
If we are going to keep track of the [[account tree]] with a set of node hashes and a [[master hash]], we can't allow every single separate transaction to alter the database on demand. We must break them up into groups of [[transactions]] which are inserted into the database in periodic intervals of time. Without having the transactions solved in groups of transactions as blocks we have no viable method of maintaining the account tree. This creates an inherent need for a blockchain, but since we can discard old blocks let's call it a “mini-blockchain”.
 
If we are going to keep track of the [[account tree]] with a set of node hashes and a [[master hash]], we can't allow every single separate transaction to alter the database on demand. We must break them up into groups of [[transactions]] which are inserted into the database in periodic intervals of time. Without having the transactions solved in groups of transactions as blocks we have no viable method of maintaining the account tree. This creates an inherent need for a blockchain, but since we can discard old blocks let's call it a “mini-blockchain”.

Revision as of 08:16, 16 July 2014

Figure 0-a: Mini-blockchain diagram.

The mini-blockchain is 1 of the 3 core components of the mini-blockchain scheme, it performs the 1st function of a blockchain. The mini-blockchain is essentially just a normal blockchain, except that we don't need to keep a copy of historic blocks. It isn't truly finite, because changing the max block size could increase the average size of the mini-blockchain. A mechanism for achieving a dynamic max block size is actually a part of Cryptonite but it's not a necessary part of the scheme.

If we are going to keep track of the account tree with a set of node hashes and a master hash, we can't allow every single separate transaction to alter the database on demand. We must break them up into groups of transactions which are inserted into the database in periodic intervals of time. Without having the transactions solved in groups of transactions as blocks we have no viable method of maintaining the account tree. This creates an inherent need for a blockchain, but since we can discard old blocks let's call it a “mini-blockchain”.

Bitcoin requires the full blockchain because that's the only real way to determine the full balance of all the addresses. However we have the account tree to fulfill the task of managing account balances and recording the ownership of coins. We don't need the full thing, we can throw away old blocks and save an immense amount of disk space. However we do keep a few hundred or a few thousand of the newest blocks and that makes our mini-blockchain. The mini-blockchain also provides us with a level of security.

Each block has the master hash embedded in the header and we can verify each block in the mini-blockchain starting from the beginning, making sure the transactions in each block always correspond to the master hash in the previous block. Since there is a proof-of-work process required for each block before it will be accepted into the mini-blockchain, it becomes extremely difficult for an attacker to generate a fake mini-blockchain. Although difficult, if we totally delete old blocks, it is far from impossible.

With Bitcoin we can start at the very beginning and work our way up to the latest point because we have the full blockchain. If an attacker creates a new mini-blockchain from the oldest block available, new nodes would have trouble telling it apart from the real mini-blockchain, because before that oldest block they have no history of what happened. The attacker can spend as much time as they need building up the cumulative difficulty of their mini-blockchain because it's not an ever-growing chain they have to out-pace.

The attacker could then start broadcasting the fake chain and it might propagate enough to impose a risk of becoming the main chain. The proof chain solves this by providing a mechanism which can act as a container for storing the long term proof-of-work history so that we can calculate the total cumulative difficulty of any chain. Instead of totally deleting old blocks we must maintain the block headers so that we can always trace the history of any given chain and compare the total cumulative difficulty each chain.