IV. Secure Ownership Records
Computers are prized for their ability to quickly edit data. In the context of asset management, this feature becomes a drawback.
Computers are prized for their ability to quickly edit data. In the context of asset management this feature becomes a drawback. To maintain the integrity of our transaction records they cannot be edited. We need our transaction records to be immutable.
Immutable information cannot be modified once it is recorded. Immutable transaction records can be trusted to present true information because we can prove they have not been edited. In a system without central authority immutability is essential. Immutability proves that information has not been edited.
To determine if transaction information has been edited we first identify every transaction uniquely. Identifying transactions allows us to refer back to them easily. With a fast way to refer to transactions we can check them for unauthorized edits at any time.
One-way computer programs, called Hash Functions, achieve this objective perfectly. Hash Functions create unique identifiers for data out of its literal bytes. Hash Functions allow us to identify transactions and check if any transaction data has been changed. Hash Functions take input data, process it, and output unique “Hash Values.”
Regardless of the size of input data, whether an entire dictionary or a single word, a Hash Function will output a unique Hash Value corresponding to input instantly.
- Collision Resistant:
The Hash Value output is unique to the input. It is impossible to find two pieces of data that produce an identical Hash Value.
Hash Functions produce an unpredictable output for an identical input. Though Hash Values change unpredictably if any part of input data is changed — even a byte, even if just one comma is removed — the Hash Value output for the same piece of input data will be identical every single time.
Blockchain systems use Hash Functions to determine if transaction records have been modified. A Hash Function will produce identical Hash Value for the identical input data. To determining if edits have been made we record a transaction’s Hash Value when first recording it. We then recalculate the transaction’s Hash Value when we referring back to it and compare. The pseudorandom and collision resistant properties of Hash Values allow us to detect any changes to the input data instantly.
- Record all of the information for a transaction.
- Calculate and record the Hash Value for this transaction.
- Recalculate a Hash Value for the transaction every time you reference it.
- Compare the transaction’s original recorded Hash Value and the recalculated Hash Value. If the Hash Values differ the data has been modified. If the Hash Values are identical the information is unmodified.
We can use Hash Functions to make entire databases change-sensitive. If we calculate the Hash Values for two transactions, then calculate the Hash Value of their combined Hash Values, we can detect a change in either transaction from one Hash Value. This idea can be extend to multiple transactions. We can create long, complicated chains of interdependent Hash Values in a process called “Hash Referencing.”
Systems that retrieve data by Hash Reference are immutable. When a modification is made to any piece of data the interdependent Hash References will be broken. A broken Hash Reference proves that data has been modified. Immutability is essential to safely protect asset ownership data without centralization.
Blockchain Data Structure
Blockchain systems have a distinct architecture for storing data. A blockchain is a chronology of interdependent data units called “blocks.” Blocks contain transaction data and are ordered chronologically. Every Block consists of a body, which contains a Merkle Tree of transaction data, and a chained Block Header.
Merkle Trees: Merkle Trees are useful for grouping data that is available simultaneously. A Merkle tree begins with two pieces of data. Individual Hash Values for these pieces of data are calculated, the Hash Values are combined, and then a Hash Value for this combination is calculated. This process is repeated until no more data can be paired. We have then arrived at a single Hash Value for the entire data structure: the “Root” of the Merkle Tree.
Block Headers: Every block’s header contains a Hash Reference to the preceding block. This ensures that the chronological order of blocks is unchanged. “Chaining” blocks allows us to create immutability for data that arrives in an on-going fashion, such as transaction information.
Blocks are added to the blockchain in a specific process.
- Transaction Requests are grouped into a Merkle Tree which forms the body of the block.
- A Block Header is created. The Block Headers contain a Hash Reference to the preceding block and a Hash Reference to the root of the transaction data Merkle Tree.
- A Hash Reference for the new Block Header is calculated and added to the Block.
- When the new block is added to the blockchain it will be added to the the end as the “Head of the Chain.” The next block added will point to this Block Header’s Hash Reference to ensure chronology is maintained.
No edits of a block, a block header, or a Merkle Tree of transaction data will be undetected. Without a central authority to judge whether edits are appropriate or not, the blockchain data structure relies solely on the validity of Hash References. A broken Hash Reference will invalidate the entire data structure — regardless of the motivation behind an edit.
If one edits a piece of transaction data then the Hash Value of this transaction data will change. This breaks the transaction’s Merkle Tree hash reference. The data structure becomes invalid.
Editing a transaction and its grouped Hash Reference will result in a valid Hash Reference. However, the Hash Reference is part of the Merkle Tree. The Merkle Tree’s Root is then invalid.
It is possible to edit the data, grouped Hash References, and the root of an entire Merkle Tree. This will invalidate the data structure because the Merkle Tree’s root hash reference is also placed in the Block Header. This reference will be inconsistent.
Editing an entire Merkle Tree and its hash reference in the Block Header results in a new, invalid Block Header hash reference. The Block Headers of incoming blocks will be unable to point to the correct Block Header Hash Reference and the structure will be invalid.
Successfully editing data on the blockchain requires editing every subsequent Hash Reference from the point of manipulation to the current head of the blockchain. This all-or-nothing approach to editing transaction data requires immense computing power and time. Manipulating data becomes impossible and immutability is achieved. With immutability, we can trust that our transaction records maintain integrity and enforce trust in the blockchain system.