Unravelling Blockchain with Salesforce
YAY! BLOCKCHAIN — The technology behind Bitcoins. One of the most talked about technologies after AI and Machine Learning. There are lot many definitions of Blockchain available on the internet and its very important to know which framework (Ethereum, Hyperledger etc.) are we referring to while trying to explore Blockchain because each of these has slightly different flavour of consensus algorithms, architecture and methods to solve double spending problem.
So what has Blockchain got to do with Salesforce — a PaaS provider and how exactly are we trying to unravel Blockchain with Salesforce as both are different ends of the technology spectrum.
Well, this article is NOT about
- Salesforce Blockchain Integration. I would be working on it at some point later (@inteygrate.com), AND
- Also this article is not about an application of a Blockchain Technology
This article is
- A work of imagination where we try to understand the basics of Blockchain architecture in contrast to the contemporary Multitenant architecture on which most of the cloud technologies are based — Salesforce being one of them.
- This is more like an analogy where its oversimplified for brevity and Blockchain experts are encouraged to share their views and feedback on this.
In this article we will try to understand the below two major aspects of Blockchain and the most frequently used terms in Blockchain world — Mining, Consensus, Smart Contracts, Cryptocurrency etc.
1. Blockchain is Decentralized AND
2. Blockchain is Trustless
Salesforce’s Multitenant Architecture
Multitenancy is the fundamental technology that clouds use to share IT resources cost-efficiently and securely. Salesforce uses multitenancy for not just sharing the Database but also the Codebase. This codebase is a runtime engine that materializes all application data from metadata — data about the data
Every logical entity that Salesforce exposes is internally managed using metadata. Objects, fields, stored procedures, and database triggers are all abstract constructs that exist merely as metadata . For example, when you define and configure a new application object, fields, workflows or write some apex classes, triggers etc. Salesforce does not create an actual table in a database or compile any code. Instead, Salesforce simply stores it as metadata in the Universal Data Dictionary (UDD). When you modify or customize something about the application schema, like modify an existing field in an object, all that’s happens is a simple non-blocking update to the corresponding metadata.
The metadata, and pivot table structures, including underlying database indexes, are physically partitioned by OrgID (by tenant) using native database partitioning mechanisms. Let us try to understand this ecosystem using some sample tables and figures:
The table above shows a simple way for storing the various objects and fields information Org wise
Now whenever any user from a particular org requests a page after logging in, the Salesforce engine based upon the Org id identified from the session, gathers necessary information from the tables and generates the virtual application components at runtime. It renders the final output and serves the page to the user. For e.g., suppose we created a Visualforce page helloworld.page which contains merge fields, action functions, and many other apex tags like apex:repeat, apex:form etc. This page will also be stored in as metadata and when we request this page (i.e by hitting https://sf_instance/apex/helloworld.page) Salesforce run time engine will fetch it from the metatdata and will process it. Processing the page includes parsing and rendering the page to replace the merge fields with the data processed in the related controller and other apex tags with relevant HTML tags, Javascript functions etc. because the browsers do not understand the apex tags. Similarly we also have a query processing engine (for SOQL queries), search engine (SOSL queries), transaction engine (for DMLs) etc. that works behind the scenes and keeps the application running.
The multiple requests including the bulk jobs and future calls from various orgs are served using Salesforce’s queue-based Asynchronous Processing framework. This framework is used to manage asynchronous requests for multiple organisations within each instance. The request lifecycle is made up of three parts:
1. Enqueue — The Salesforce application will enqueue requests (which could be an Apex batch request, @future Apex request or one of many custom code developed for customisation) along with the appropriate data to process that request.
2. Persistence — The enqueued request are stored in persistent storage for failure recovery.
3. Dequeue — The enqueued request is removed from the the queue and processed. Each request is processed by a handler — code that performs functions for a specific request type.
Handlers are executed by worker threads on each of the application servers that make up an instance. The threads request work from the queuing framework and when received, start a specific handler to do the work. The following diagram shows the asynchronous processing in action:
Apart from pages, code and data; Salesforce Metadata also stores information about access control. Every time a user attempts to open a record, run a report, access a list view, or search for data using the user interface or API, Salesforce checks the configuration of its record access features and determines which records the user can access. These calculations are also done during runtime and the configuration information is stored in various tables i.e metadata.
Summary
Salesforce Platform’s Multinenant Architecture is Metadata Driven. All Code — Standard and Custom, Objects, Fields, Apex Classes, Visualforce pages, Triggers, Access Control Configuration, Permissions etc. are all stored as Metadata. Salesforce’s runtime engine fetches the necessary information from the metadata and serves the Users.
Salesforce on Blockchain (if it ever happens!)
Remember BitTorrent? uTorrent? Yes, the clients that were used to download huge files from various locations/sources using a Torrent file (Metadata that contains information about the files and folders to be downloaded and their network locations). Salesforce on Blockchain would have to provide similar clients to users that would serve as an user interface which otherwise is served by the Browsers. We need a client because in Blockchain world everything is Decentralized — Code and data both and so Salesforce will no longer spend money on commissioning and maintaining the different server instances to host data or the codebase/engines. Instead the runtime engine and metadata updates that we have been discussing so far would be executed by each of the user computer within an organisation. Let us see how a simple request in such a scenario would look with the help of each of steps in the below figure.
- Going back to our previous example, suppose we try to hit and request our helloworld.page.
2. This time instead of the request being routed to a remote central server, it would be broadcasted to a network of computers (of users in the same organisation) called nodes. The nodes aren’t any special machines and are indeed same as the requesting computer.
3. Each node has the codebase i.e runtime engine, data and the Metadata installed on their machines. The request that they receive is processed in the same manner as discussed in the previous section, this time though it is multiple times.
This redundant storage and execution might seem silly but that is indeed what gives Blockchain the nature of being ”trustless”. Because with this mechanism in place we enforce all parties in the system reach a consensus on what the truth is. Power and trust is distributed (or shared) among the network’s stakeholders, rather than concentrated in a single individual or entity. Blockchains are thus built on the basis of distributed trust: We are trusting everyone in aggregate.
Each node after executing the runtime engine will update the Metadata which in a way defines the state of the application and can thus be compared to Ledger State. The runtime engine being executed on every node henceforth can be compared to Smart Contract (Ethereum parlance) or Chaincode (Hyperledger parlance)
4. The above execution is followed by a Consensus Algorithm where each node will try to generate a Block (by calculating a hash in a predefined format). If all the nodes are part of same organisation then there isn’t any reward for generating a block. But if few or all of the nodes are outside the organisation (a simple reason could be that your organisation lacks the resources or compute power for the Engines. Something similar to the Governor Limits that we had in multitenant architecture) the owner of nodes should obviously be motivated with some rewards for executing the code and generating a block.
While using BitTorrent like applications the only motivation you had contributing/spending your upload speed was to be called upon as a good Seeder OR not to be called upon as a Leecher 😜
This is when Cryptocurrency comes into picture. You might have to pay to get a cryptocurrency (say Salesforce Coins) to get the runtime engine i.e. Smart Contract executed. They describe this as paying Ether — Ethereum’s Cryptocurrency for Gas— the execution fee for every operation made on Ethereum. And every time those nodes successfully generates a Block — a Coin is automatically generated/mined and rewarded to the owner of the node called Miner and this process is recognised as Mining.
Did you notice that we are exposing the data and code to node outside organisation. For this I will take an escape saying hey chill!! its a work of fiction as I pointed out earlier. At the same time will also point towards the option of using Public Key Cryptography and Encryption techniques etc. Nevertheless the sole purpose is to give an analogy to the common jargons of Blockchain and I will take a back seat on this for now.
In a Bitcoin Blockchain there isn’t any Smart Contract. The miners run only the Consensus Algorithm (Proof-Of-Work) to mine a BitCoin.
5. So yes we will eventually have Salesforce Coins working as “Digital Oil” for keeping the application running. And may be just like we used to spend dollars for Licenses, Editions and Storage; we will have to then buy Salesforce Coins. Though there isn’t any intrinsic value to the Cryptocurrency, this dollar association with the Cryptocurrency is what makes mining real worthy 🤑.
6. Once the Metadata i.e Ledger is updated, a new block is generated and verified which is then added to the Blockchain. This update is now unalterable — another potential property of Blockchain. Blockchain is nothing but a track of all the ledger state changes that again resides on each of the nodes.
7. The final response is then served to the user who has requested it.
Happy Ending? Not quite. This is a very vague overview and comparison of Blockchain and there are in-numerous features (viz. Security, Releases, Integration etc.) that might fail or just be impossible with such setup.
Because our articles are all about Salesforce integrations its interesting to look at the integration aspect of Salesforce on Blockchain. Straightforward — its near to impossible because everything that takes place on a blockchain must be completely deterministic, with no possible way for differences to creep in. The moment that two honest nodes disagree about the chain’s state, the entire system becomes worthless.
Smart contracts are executed independently by every node on a chain. Therefore, if a smart contract retrieves some information from an external source, this retrieval is performed repeatedly and separately by each node. But because this source is outside of the blockchain, there is no guarantee that every node will receive the same answer.
Perhaps the source will change its response in the time between requests from different nodes, or perhaps it will become temporarily unavailable. Either way, consensus is broken and the entire blockchain dies.
Any workaround? Yes — Instead of a smart contract initiating the retrieval of external data, one or more trusted parties called **”oracles”** creates a transaction which embeds that data in the chain. Every node will have an identical copy of this data, so it can be safely used in a smart contract computation.
In other words, an oracle pushes the data onto the blockchain rather than a smart contract pulling it in. Someone is already doing similar thing it seems
http://www.oraclize.it/
The 3 (Spring, Summer, and Winter) Salesforce releases that we have every year for new features would also be not possible because Contract code is permanent. Scaling Challenge. There is no way to alter the code of a deployed contract except by destroying it altogether and re-creating it!
That said we aren’t concluding that Blockchain has some flaws. The fact is implementing applications like salesforce isn’t really a good use case to explore the real potential of Blockchain. What we tried to do here was understand the architecture and the core properties of Blockchain when compared to contemporary architecture. Salesforce esp. because our articles are targeted towards Salesforce at the heart of all.
