SimpleBlockchain is a modular, developer-friendly, and open-source framework to develop blockchain applications. In this article, I will be taking through the explanation of the Block and the Transaction structure of the SimpleBlockchain framework. Keep following the GitHub repository for updates.
SimpleBlockchain framework is modular enough to integrate different consensus without changing its other core component. Also, it is generic enough to support multiple applications simultaneously using its generic Block and Transaction structures. We are using Rust language to develop the SimpleBlockchain framework. This article may contain Rust-specific code snaps, as I will explain the block and the transaction structures and how they are capable to support these functionalities.
Block
A Blockchain is a chain of blocks where each block is linked with the previous block (the parent block) via adding the previous block hash. Generally, a block contains the previous block hash, miner’s id, transactions list, creation timestamp, state headers, block height, and signature. Figure (1) shows the structure of a block.
Figure (1): – Block Structure in Blockchain
A root block is a topmost block of the blockchain. A peer or an active miner node gathers transactions, executing them on the updated global state from the root block, and then includes other headers details to forge a new bock. In Blockchain, a parent hash or a previous block hash are interchangeable terms. Both terms represent the hash value of the n-1th index block for the nth index block. Since, each block holds a hash of the parent block so that if a malicious peer tries to modify data of any previously appended block, it needs to re-compute and update the parent hash of each block up to the latest block. That is why data tempering in the blockchain is near to impossible. In Figure (2), three blocks are shown Block 101, Block 102, and Block 103. Block 102 is the child of Block 101 and Block 103 is the child of Block 102. Each block has only one child. In the case of two children, one child will be discarded by the blockchain eventually. Now the question emerges is, who is the parent of the first block. Each Blockchain creates a genesis block (first block). This genesis block is created by using a predefined set of values known to everyone in the network.
Figure (2): – Simplified Blockchain
How the block structure generic enough to support the different consensus
The block structure shown in figure (1) is imprecise. In actual implementation, the block structure may contain various other fields depending on the blockchain consensus and the blockchain permission level. Example: – Blockchain consensus POW needs extra fields in block structure such as nonce, a block difficulty unit, and a block reward, etc. Blockchain consensus Gosig needs extra fields in the block such as signer’s list, a block reward, and round number, etc.
There is one more thing we need to consider. Not every field in block structure is used to generate the block signature. Example: Signer’s list in Gosig consensus will be used for the authentication process and will be excluded while generating signatures. We can call these types of extra fields as authentication headers. Besides, the nonce integer, the block difficulty unit, and the block reward are extra fields that are included while generating a block signature. We can call these types of extra fields as custom headers. It is possible to have the only either kind of header type require in the blockchain.
While working on the SimpleBlockchain Framework, we addressed this generic block structure issue, so that developers can integrate different consensus with the SimpleBlockchain framework without doing any extra work on Block Structure. Figure (3) shows the generic block structure of the SimpleBlockchain framework.
Figure (3): – Generic Block Structure
Figure (4) shows an example of the custom headers in the case of Aura Consensus
Figure (4): – Consensus Specific Custom Header
Transaction
A transaction is an activity that tries to modify a blockchain global state.
A Peer executes transactions to forge a new block. When a transaction gets executed, it invokes a function of a smart-contract. Typically, a transaction structure contains From Account, Smart Contract, function, headers, function payload, and signature, etc.
Figure (5): – Transaction Structure in Blockchain
Figure (5) shows a general structure of a transaction. From Account is the transaction invoker’s identity and this identity will be used to authentication the transaction’s digital signature. The smart-contract and the function field contain the application information which will be going to validate and handle the payload data. The function payload is the list of input parameters to the function call. The header field can have various fields such as nonce, timestamp, transaction fee, etc.
The transaction structure depends on the blockchain consensus and application it is supporting at present. That is why we need to make sure that our transaction structure should be generic enough to support these modifications.
Let me show you how the blockchain consensus and applications affect the transaction structure. Let us assume a user wants to build one application on top of the SimpleBlockchain framework that has support for Multi-Signature. In that case, the framework must have that much structural flexibility to add support for the same. On the consensus side, one consensus can have fields such as Gas price or Transaction fee. To resolve the upper mentioned challenges, we created a generic transaction structure shown in Figure (6).
Figure (6): – Generic Signed Transaction Structure
As shown in Figure (6), the txn field stands for serialized data of User-defined internal transaction details. The app_name is an application identification. The header may hold some consensus defined values and timestamp in key-value pair format. The signature field as the name suggests holds the digital signature of the transaction. This signature field data can be multi-signed or the normal one and its validation process will be defined accordingly by the application itself. The developer needs to take care of a transaction data sanitization and the other validations.
Figure (7): – User-defined Transaction Structure for Cryptocurrency Use Case
Figure (8): – User-defined Transaction Structure for Document Review Use Case
How does Transaction Structure support multiple applications?
As shown in Figure (6), the “txn” field contains serialized transaction data of the user-defined application. That means the application developer got free hands to develop application business flow, the validation mechanism, the state management, etc. The only constraint is that the developer must implement traits shown in line no 2 & 3 figure (7) on its Transaction structure. Figure (7) shows a user-defined transaction structure for a cryptocurrency use case where one can trade money with others. Figure (8) shows a user-defined transaction structure for the Document Review use case.
You can find both applications for your reference under a simpleblockchain/src/user module. If you happen to have a new bug or a new idea, feel free to open a new issue.
Have any blockchain requirement? If yes, you may check our blockchain offerings here.
