Blockchain simulator in Salesforce

Bram Julsing, 4 January 2020

Nowadays, many people have heard of blockchain. Blockchain is the fundamental technology behind cryptocurrencies like Bitcoin. However, blockchain technology also has a lot of potential for – and is already being used in – applications in various other industries. An example is a supply chain network, where many parties are involved in extracting, transforming, fabricating, and moving products or services that are in the end being delivered to a customer. People start to implement blockchain in such kind of business applications and processes, because of the security and decentralization aspects that blockchain provides. But how and why are blockchain applications secure and decentralized? In order to understand these benefits, I decided to dive into the algorithm and to build a simple simulator/application in Salesforce, to demonstrate the mechanism of blockchain. If you have a Salesforce (developer) org, you can install the Blockchain Simulator package for free. In this article I try to describe some of the basic principles of blockchain, accompanied by screenshots from my application.

Figure 1 – Blockchain simulator in Salesforce.

What is a blockchain?

In essence, a blockchain is a database with a shared ledger. It’s a structured way of storing data, whereby the ledger contains information about the transactions happening on/between the data. Multiple computers store a copy of the ledger. These ledger copies are kept in sync trough a distribution algorithm. Like the name ‘blockchain’ already hints to, the transactions are stored in blocks, linked to each other via a hash code that is generated from the hash of the previous block and the transaction data in the new block. Blockchain security is (partially) achieved by making it ‘difficult’ (computationally intensive) to generate a hash, which is accomplished by enforcing that every hash needs to meet a specific format, like a number of leading zeros.

Hash, Mining and Reward

Let’s consider a very simple blockchain application/network, named Cryptocoin. It consists of participants who send and receive cryptocoins from and to each other via transactions. Upon initialization of the blockchain, a first block is created, the so-called Genesis block. This block doesn’t contain any data, but it’s the start of the blockchain and it does have a hash (based on the created date and a so-called nonce).

Figure 2 – Genesis block.

This blockchain has the following two properties:

  • Difficulty: the number of (in this case) zeros that every hash needs to start with. It determines the amount of work (computing time) required for generating a new block on the blockchain. The higher the difficulty, the longer the computing time. Finding a hash with the specified number of leading zeros happens through an iterative process, called mining. A person who uses his/her computer for this mining process is called a miner. The nonce represents the number of iterations that were needed. In case of the Cryptocoin blockchain, the difficulty is set to two. And as is visible in figure 2, the hash of the genesis block starts with two zeros. It took 5079 iterations to find this hash.
  • Reward: the number of cryptocoins that a miner receives after finding the hash for a new block. It’s the incentive for people in the blockchain network to provide computer power, and therefore electricity, to find a hash. In case of a public blockchain, multiple people/computers in the network compete with each other to find the right hash and to get the reward.
Figure 3 – Blockchain properties.

Now let’s initiate some transactions. Marc transfers some coins to Elon, and Elon transfers some coins to Tim. The transactions are not directly processed. Their statuses are still pending, and the balances of the participants are not yet updated. The transactions are only actually executed when they have been validated during the mining process and recorded via a new block on the blockchain ledger. Assuming that the miner has an up-to-date copy of the global ledger and access to the transactions database table, the mining process for this application is as follows:

  1. Retrieve the pending transactions.
  2. Validate each transaction, by checking if the sender has sufficient coins on his/her balance.
  3. Serialize the valid transactions into one JSON string. For each transaction the following information is included: from-participant ID, to-participant ID, amount, type (transfer) and created date.
  4. Initialize a new block and set the following properties:
    • Index = Index previous block + 1
    • Previous Hash = Hash previous block
    • Timestamp = current date/time
    • Data = JSON string of the serialized pending transactions
    • Nonce = 0
  5. Concatenate the properties and create a hash code using the SHA-256 hashing algorithm.
  6. Validate if the resulting hash code already meets the specified difficulty, in this case by checking if it starts with two zeros.
    • If false: increment the nonce (i.e. nonce = nonce + 1) and go back to step 5.
    • If true: proceed to step 7.
  7. Save the final hash and nonce in the block, add the block to the ledger instance, and distribute it to the other computers in the network.
  8. Update the status of the transactions to committed.
  9. Create a (pending) reward transaction for the miner.
Figure 4 – Block mining.

This process is called Proof of Work. As described, a significant amount of computing time is required to generate new blocks. The return is data security.

Validation and data security

One of the advantages of using blockchain is data security, meaning it’s difficult to make changes to the processed data. This is achieved by a combination of the cryptographic validation method and the decentralization of the blockchain. During validation, the hash of each block is recalculated (using the final nonce) and compared with the stored hash. A minor change in the data would already result in a completely different hash. Since the recalculated hash of one block is also input for the recalculation of the hash of the next block, one small data change anywhere is also reflected in the recalculated hash of the last block.

Figure 5 – Validation before data tampering.
Figure 6 – Adjusting the amount of an already committed transaction in block 4.
Figure 7 – Validation after data tampering.

Conclusion

In this article I tried to explain and demonstrate some of the core aspects of blockchain technology, including hashing, mining, data validation, and ledger sharing and distribution. These algorithms make a blockchain network secure and decentralized, i.e. independent of a central authority. The figures in this article are screenshots from a simple blockchain application/simulator built in Salesforce. In a real blockchain application there are many more aspects to be taken care of, like the distribution of the ledger and making sure it’s continuously kept in sync with all the computers in the network. Also, beside Proof of Work, there are some more and different blockchain consensus algorithms out there, each with its pros and cons.

If you have a Salesforce (developer) org, you can install the Blockchain Simulator package or clone the code from Github, and experiment with this blockchain simulator yourself.