-
Notifications
You must be signed in to change notification settings - Fork 2
Comparing Our Blockchain App to Bitcoin
As we develop our blockchain, it is useful to consider how it compares to a public blockchain like Bitcoin. There are thousands of variations on the Bitcoin protocol, and thousands more to come. But it is the most well-established and tested. Here is I will list some of the foundational elements of the protocol, and how well our blockchain does or doesn’t compare to it.
We do have an essentially workable blockchain, in the sense that it will hold data, and can be passed around from node to node. But it is missing at least three key features:
-
Each block can be identified by a hash of its contents. By storing the hash of each block in the block that follows it, the blocks are effectively chained together in sequence. If any block’s contents are changed, its hash value will also change, causing every subsequent block hash to change as well. This is what gives the blockchain its immutability.
In Bitcoin, mining nodes gain the right to add a block to the chain by inserting a nonce (a simple number) into the block that causes its hash value to be within a certain range. Sure enough, if you use a block inspector to examine Bitcoin’s block headers, you will notice that the previous block hash value always starts with some number of zeroes (the exact number adjusts every so often according to the protocol on order to maintain a consistent time interval for block creation).
To find this nonce, miners effectively start with 1 and calculate the hash value. They repeat this process, incrementing the nonce each time, until they hit upon a hash that has the required number of leasing zeroes.
For whatever reason, our blockchain mining algorithm determines the nonce value by hashing it with the nonce of the most recent block, instead of the entire contents of the block it is working to create. Because our genesis block starts with a hard-coded nonce value (100 to be precise), the sequence of nonce values is predictable, in fact trivial to figure out. So, a dishonest node could easily create a long chain with altered or entirely made-up transactions, and fool the other nodes into accepting it. We must correct the proof of work to ensure that the nonce values are not predictable in advance.
-
In Bitcoin, only the block headers are used to create the hashes that link blocks together, but those headers contain a hashed representation of their transactions (this is called a Merkle root; actual transactions are organized into a Merkle tree). This method allows the transactions to be physically stored ‘off-chain’ while maintaining their immutability: any change to a transaction would result in a different Merkle root in its containing block’s header.
Our blockchain is linked with hashes of the entire contents of each block, including their transactions. This will work fine for now, but eventually we will implement Merkle trees for our transactions; otherwise the blocks will become too unwieldy.
-
Our consensus algorithm works by fetching the entire chain from each node, and checking its length. If a node receives a chain that is longer than its own current chain, it will adopt the longer chain in its entirety. But the chains we receive are not validated, so it would be trivial for a dishonest node to replace the entire chain.
Eventually, our blockchain nodes will only receive entire chains when they need to instantiate a copy of the chain. To achieve consensus, they will receive candidate blocks from each other, validate them and the transactions they contain, and use them to extend their existing copies of the chain.
-
Currently transactions are not validated. We must implement the ability to verify that senders are authorized to send the amounts specified in the transactions. This requires inspecting the entire chain to maintain a running list of unspent outputs.
-
Our application supports only a single transaction type: sending amounts from A to B, or some combination of A’s to some combination of B’s. Protocols like Bitcoin and Ethereum support the use of smart contracts, which are essentially small programs embedded into the transaction that execute based on specific conditions.
Our application has no storage capability, which means that if a node is stopped, all of its data in memory is lost. In theory, a node can recover the latest blockchain from other nodes, but it has no knowledge of other nodes unless someone registers them manually.
Our application has limited capability to keep individual nodes in sync with each other. Critically, nodes lack the ability to broadcast newly mined blocks to other nodes. There is also no ability to discover other nodes, broadcast unconfirmed transactions, identify neighboring nodes, or determine whether a particular node has gone offline.
Nodes can receive new transactions, but a practical application would provide wallet software that allows users to generate public/private keys and keep up with their coins, which are often distributed among several addresses. It would also provide a user-friendly way to format and inject transactions into the system. Wallets also need the ability to query the blockchain for existing transactions, so that it can determine available balances.