A blockchain is a series of blocks - so let us start by understanding the BLOCK. In our hypothetical blockchain - each block is going to contain specific information about our engineers within the council. We need to keep records about their schools, university, work experience, training etc. To organise this information we are going to package it in to transactions. Each transaction representing an entry by the engineer. The transactions must have the name of the engineer, the type of record, the date, and details of the record. Let us start with this as the BLOCK DATA - The specific information the blockchain is designed to store.
The building blocks of a block
Block architecture has three important elements that make the technology work. In our example we will look at transaction control, block production management and block signature. Transaction control is how we will manage data that enters the block. Block production is how new blocks will be formed. Finally the block signature is the unique hash that is used to identify the block
"You could imagine something like a completely automated system for renting bikes that's just done completely over blockchain crypto-payments. And theoretically just sort of start-it up, and it workscompletely autonomously."
Vitalik Biterin
founder of Ethereum
In our example there will be two main players, the engineers that will enter data in to the blocks and their supervisors who will confirm these entries. Each engineer will be given an account - the account will be assigned a private and public key. The users will need their private keys to sign transactions.
In cryptocurerncy blocks the mining difficulty is used to control the rate of new blocks being produced. This is not necesary for our blockchain. Transactions will be added based on volume. We are not worried about inflation as we have no currency.
SHA256 hashing function will be used, to assign the data a signature or hash. Before the hashing process - a randon nonce number will be added. If the data is altered in future, - the nonce and hash will be completely different. see more in the chain tab
Our first demonstration will be for the signing of the transaction. Click the button below to get your private key. Copy it somewhere safe, you will need it to sign the transaction
Enter any data you like below and paste your private key to sign the data, when you are ready get your signature.
Signature will be displayed below:
Signature
Public key
The signature is just a bunch of numbers, in fact two very long numbers (r, s) in a tuple. We will use that signature and your public key to verify your data
Now copy that signature and public keys as they are - including the brackets in to the boxes below. You are now the miner or supervisor - you get a signature, publicly available key and the data. Confirm if the signature is valid by clicking the button. Change something in the data or signature, even a sigle digit and the signature will be invalid.
This works because of a cryptographic technology called - Eliptic Curve Cryptography. In this method, a message can be passed in a public forum between two parties, where each party holds a private key. This public message can only be decoded using the public key , which is available to everyone and the message signature, which accompanies the message. But in order to decode this message you need to know with eliptic curve and hash function we are working with. In our application the signature of the message is used to ensure that the message was signed using the private key which is associated to the public key of the user. Each user can only have one private-key, but the same private key can generate multiple public keys, however the public keys and private key are connected and paired.
A main requirement of the signature function is the trap-door effect. Going forward verifying the message is an easy job, a quick calculation, but you cant move backwards. Meaning if you had the public-key, message signature and message - you would not be able to calculate the private key. Its a one way highway. The second important aspect is the 'snow-ball effect'. If the message is altered even a little, the entire signature is 100% different, not simmilar with a digit off. This means, if you alter the message by adding a ',' or even a space where there was no space - the resulting hash and signature will be 100% different. So you CANNOT correlate a message to its signature or hash.
This is a very important requirement because EC cryptography governs systems like Bitcoin, a monetary financial system with value. If i could correlate signatures and hashes - then i could get a message where someone sent 100BTC for example, add a zero and its a 1000BTC. Then recalculate the signature using the correlations -if its true, i would pass the test and cheat the system. We dont want that - the system would be useless if that were possible. We also dont want people to do back-calculations: hence the 'trap door effect'.