The web site of jiawp

Surveying Blockchain Technologies for Enterprise

Introducing Blockchain: Improving Supply Chain Food Safety What Is Blockchain? How Is Enterprise Different Than Bitcoin? Hello. My name is Scott Driscoll. Welcome to Surveying Blockchain Technologies for Enterprise. This course will give you a tangible introduction to what blockchain is and how it can transform enterprise by surveying a broad array of different applications and software tools. Blockchain, the technology behind the digital currency bitcoin, is now being brought to bear on a range of enterprise applications beyond currency in almost every industry from supply chain to banking, energy, healthcare, and many more. At a high level, blockchain provides a new way for organizations to interact that doesn't require as much trust. This, in turn, promises improved efficiency, security, transparency, and even the opportunity for new business models. Let's dive into a specific application area, supply chains, to get some tangible insights into what blockchain is, how it can benefit enterprise, and some of its challenges. IBM and a group of retailers including Walmart have recently launched a pilot using blockchain to help increase food safety. A current outbreak of Salmonella in papayas gives us insight in to the motivations these companies have to improve the status quo. As of September 11, 2017, according to a U.S. government health organization, 210 people across 24 states have been infected with illnesses beginning in May and June. Based on the times of the press releases, it appears that it took several weeks between identifying strains of Salmonella in patients to identifying the likely source, a farm in Mexico. While the source of an outbreak is being tracked down, lives are at risk, as well as substantial money. The government initially recommended that an entire type of papaya from Mexico not be eaten. Later, after more tracing, the ban was restricted to specific brands and, finally, serialized lots of papayas. Given the cost and health risk, why did it take so long? To trace a specific papaya back to its source, the government likely had to contact retailers, distributors, multiple brands, importers, and farms all individually. One can imagine the situation gets even more complicated as products are mixed with other ingredients and long shelf-life products, as was evident in another recent outbreak of E. coli in SoyNut butter. Instead, what if there were a single database that kept track of every single papaya's journey? The government and companies would be able to immediately see the source of contamination and pull only the risky papayas. This sounds great, but even the most basic questions about how this might work reveal myriad complications. Who would hold that data? One retailer wouldn't want another to hold it. And, given all the recent security breaches at government databases, it's unlikely anyone would want the government to operate the database. Who would be able to see the data? Retailer A wouldn't want retailer B to know how many papayas it was buying, what price it was paying, and from what distributors. Finally, who decides what the right data is? Consider what happens when a retailer orders 10 crates of papayas and the supplier delivers 9 crates. Now the retailer system shows 9 whereas the supplier system may show 10. The retailer's accounting office will likely need to call the suppliers to request a credit on the invoice. Here we see that each organization up and down the supply chain maintains their own records, with good reason. One organization's records certainly may not reflect the truth according to another. Reconciling inevitable differences represents a major cost in almost any industry. Blockchain represents a new way to share data that addresses these questions. Blockchain can be thought of as a shared database, one in which control is truly shared between different organizations and is especially helpful when those organizations don't necessarily trust each other. In our papaya example, imagine if each papaya had a serial number and current owner. As the papayas move through the food supply chain, the owner is updated, providing immediate visibility of every papaya's path. This also looks like an accounting ledger, which is where another common name for blockchain comes from, distributed ledger technology, or DLT. So how does this work? What does it mean to share a database? For starters, changes to the database must be approved by everyone. In that case where the retailer and supplier disagreed about how many papayas were delivered, one or the other wouldn't be able to independently update that record. Rules are established that must be obeyed in order to accept changes. For instance, either both the supplier and retailer need to sign off on the number before entering the change or, perhaps, a third-party auditor needs to sign off on the number delivered. In this way, we effectively avoid any reconciliation. Valid data was required on the way in to the database. In addition to regulating the entry of new data, a blockchain database has protections against tampering. Every new change to the database is accompanied with a kind of data fingerprint called a cryptographic hash. Hashes provide a short representation for a larger amount of data. A hash of the entire Bible can be only 32 bits, but changing even a single letter in the Bible would generate a completely different hash. See how different the hashes are from these two similar sentences. In addition to this marker that tells us whether a single bit changes, blockchain goes further to link these markers together. Every time new data is added, a hash is calculated on that new data along with the previous hash. Because each hash builds on the previous one, the data forms a chain where any change in the historical data will immediately be obvious. For efficiency reasons, new records are usually added in groups called blocks, which is where we get the name blockchain. In addition, new data must be accompanied by a digital signature, another cryptographic tool that makes sure only authorized people can change data and that there's also a record of who did what in case of any wrongdoing. Finally, each peer maintains their own copy of this common ledger where they independently check the rules, hashes, and signatures as new data arrive. All these components contribute to a database where every participant has truly shared control and strong assurance that data won't be tampered with. The end result is more trustworthy data even though it's not on your own database. And with this new later of trust in data, we unlock all sorts of efficiencies and possibilities. With a single shared ledger, it would be trivial to track down the path of a papaya in seconds. Trusting data also unlocks automation possibilities across what I'll call trust boundaries. A new order for food could be placed automatically when stock runs low at a retailer. Or shipping insurance could automatically be paid when a shipment is late or a temperature censor indicates frozen goods have melted in route. All these types of automation are possible without blockchain, they require a certain amount of trusts in the inputs and, therefore, procedures to cross-check and verify information. Blockchain reduces and, in some cases, eliminates the checks and controls required with that trust, thereby unlocking automation. Now despite this promise, there is reason for skepticism. Couldn't a group of companies get together and form a consortium group that runs a database in which everyone is given controlled access? Why blockchain? There is a spirited debate going on about this. Is blockchain really different than a distributed database? And if so, where does it add value? Even determining exactly what a blockchain is and isn't is an evolving question. Hundreds of enterprises from almost every industry are currently running pilots to hone in on exactly what blockchain should look like and where it can deliver value. While many pilots recently begun to show promise, there are many details to be decided in any implementation, and adaptations must be made from the blockchain behind bitcoin to one that works well for enterprise. For example, in bitcoin, all data is viewable by everyone, whereas in enterprise data must be kept private, and not only from the outside, but also selectively within the network. In our papaya example, different retailers wouldn't want each other to see how much fruit was ordered, but it would be valuable to give governments or auditors access to this data. Performance is another area where the original blockchain falls far short of enterprise needs. Bitcoin can only handle a few transactions per second while modern databases handle millions. The blockchain behind bitcoin is also very expensive, by design in fact. Various fees and costs are needed to prevent abuse while keeping the system completely open. Almost all enterprise blockchain platforms in development hope to exchange openness for better privacy and performance while still retaining the benefits of decentralization. Our last module, Surveying Enterprise Blockchain Tools, will detail a broad range of these and the tradeoffs each has made. But first, let's better understand the problems at which blockchain is being targeted in the module Surveying Enterprise Applications.

Surveying Enterprise Blockchain Use Cases Improving Supply Chains with System-wide Transparency In this module, we're going to look across a broad array of industries to see example enterprise applications where blockchain promises substantial value. Despite blockchain's strong potential, many have commented that blockchain technology does not neatly fit into existing business models. It's not, for instance, just a different database that can be swapped in by IT alone. Blockchain adds value by creating a new way for separate organizations to work together, so realizing its benefits often requires innovation in business models in tandem with technology innovation itself. We're going to cover a number of areas including supply chains, energy, finance, banking, and healthcare. Along the way, we'll also touch on IoT, or internet of things, and insurance. We began looking at food safety in the supply chain and how blockchain could help track the provenance or history of ownership of a specific item from farm all the way to table. While giving government authorities extra visibility can help track down a safety concern, almost every other party in a supply chain can also benefit from extra insight. Let's start at the farm, the furthest point from end consumers. While consumers may be willing to pay a premium for features like sustainable production, GMO free, and simply better taste, farmers cannot necessarily capture those premiums. Food typically goes through many layers of middlemen like distributors, packers, processors, and retailers before it reaches consumers. Irrefutable documentation of the value added at each step not only will give consumers more confidence and willingness to pay, but will translate into higher pay for those adding the value. A company called ripe.io seeks to use IoT sensors to help in this documentation effort. This starts at the farm with humidity, temperature, and even color sensors on crops, continues with temperature sensors on trucks and in packing facilities, all the way to processors that record exactly which foods go into final products. With increased visibility, added value can be better rewarded. These quality markers can gain additional power as third-party auditors or agencies add additional confirmations or measurements to the chain. More data isn't just about fairer payments, but also about unlocking opportunities. Ripe.io says that 10% of crops are thrown out in peak seasons. A company called Sweetbridge says only 75% of all global assets like trucks, warehouses, etc. are used at any given time largely because of siloed data. With a better-connected network, there is ample opportunity for better utilization. This is especially true for smaller companies. While large companies like Apple and Walmart already have good visibility from retail inventory all the way down to raw material stocks, smaller players do not always have access to such data and cannot react efficiently. For example, is an uptake in orders due to a temporary marketing campaign or a general increased interest in a product? Unknowns like these often lead to oversized reactions far down the supply chain known as bullwhip effects. With better access to data like retail store inventories, marketing campaigns, the entire chain can better match supply with demand. A company called Everledger is also using the blockchain to improve transparency, but with diamonds rather than food. The goal is to prevent blood diamonds, diamonds whose sales fund wars, and also prevent theft and insurance fraud. Everledger says over 2 billion pounds of loss is due to insurance fraud every year. To address this, Everledger records a fingerprint of high-value diamonds on the blockchain based on inherit characteristics. As the diamond changes hands, these changes in ownership are also recorded. And importantly, any reported thefts are recorded. This way, a potential buyer can check the blockchain to make sure they're not about to buy a stolen diamond. And if police recover diamonds, they can be returned to the original owners or insurers. While a thief could try to modify a diamond to obscure its history, they wouldn't be able to do so without also damaging the diamond. Everledger is branching out to the art world too and even luxury goods as a way to reduce counterfeits and protect brand image. While provenance is important in almost any industry, it is vital in the drug industry where counterfeit drugs can lead to deaths. In these cases, blockchain technology's immutability is the key to the traceability. No one can make a change to a record after it has been entered.

Immutability on Private vs. Public Blockchains It's worth diving a little deeper into the details to understand some nuances in both the confidentiality and security of these systems. Everledger actually uses two different blockchains to store data. Data hashes are stored in a public ledger, like bitcoin, but additional details, of specific police reports for examples, are stored on a consortium chain that only provides access to select members. Why use two chains? Consider the immutability claim of a chain run by a group of, say, 10 companies. In private chains like these, immutability is a result of a single company not being able to change a record without the other nine agreeing to it. But if all 10 agree, there's not a technical reason they couldn't all rewind, change some data, and reenter the data. It turns out immutability, like many other properties of blockchains, is on a sliding scale. Now if transactions are never used outside of a small consortium, immutability may not matter. But if a large network of police departments and insurance companies want to trust it, immutability, or the inability for data to be changed without someone realizing, is vital. The most immutable blockchain currently running is the bitcoin blockchain. Hundreds of thousands of people maintain copies of the ledger and would notice any change. Furthermore, bitcoin's ledger is also protected by a concept called proof-of-work. Without going too far into the details, know that adding new records requires a substantial amount of computing power. This computation is not a technical requirement for a distributed system, but rather a way for everyone to differentiate the real ledger from potential fake ones without needing to trust any central authority and operate in an open, anonymous network. If presented with several different ledgers, the real one is the one with the most work. You can look at the bitcoin ledger and calculate how many millions of computer hours were needed to generate it. Even a large government would struggle to generate a competing ledger with more work than the bitcoin network, now the world's largest computer. Most private chains do away with this expensive function since internal members are more trusted, but with it goes some of the immutability. Everledger seeks to provide a middle ground where hashes of data on the private chain are stored on bitcoin. In this way, sensitive details are kept secret, but the system is able to leverage the much greater immutability of a public chain, which acts as a kind of notary.

Fine-grained Privacy, Digitization, and Automation Even within a private chain, there are many cases where data visibility needs to be nuanced. Consider financing and supply chains. Many suppliers must obtain loans to produce goods since payment isn't sent until after delivery. It would be beneficial for those suppliers to show financiers an indisputable record of their past performance including metrics like quality, delivery time, etc. However, those suppliers would certainly not want to reveal customer and performance data to competitors. A blockchain with selective privacy controls could reveal data as needed, as in this case to obtain a loan, but also to government authorities such as customs and tax officials. Now, while this may sound simple on the surface, there are complications. If data is private, how can everyone on the chain verify that data entered has complied with rules? More on this in the next module. The sheer number of participants in the supply chain makes data sharing and the movement of goods complicated. There are governments, importers, shippers, custom brokers, freight forwarders, ocean carriers, and many more. And many of these still require original paperwork, such as bills of lading, to accompany goods through the system. IBM and Maersk did a study of fresh flowers and found that over 200 documents were generated for a single shipment of flowers. A proof of concept system was developed to replace all these documents with a single blockchain-based system where all participants could access digital versions of these documents. For export, three government agencies electronically sign-off on chemical treatments, origin, and duties. Information about these approvals and a truck's departure is visible to the port so they can begin preparing immediately. Delays due to waiting on paperwork were reduced and participants were able to move the shipment faster by acting on data in real time. Now, is blockchain technology needed to replace all this paperwork or just a centralized database? I think a key consideration is the question of trust. Who would run this database and what assurance do all these different actors from export officials and government to shipping companies to end purchasers have that the database operator is faithful to their interest? Blockchain reduces this need for trust across very different parties while also unlocking the benefits of digitization. In addition to reducing the cost and chance of fraud with physical paper, digitization also provides opportunities for automation. Consider shipment insurance for perishable goods. If refrigeration is ever lost along the route of, say, seafood, the entire shipment could be lost. A shipper might have insurance to guard against refrigerator malfunction in cases like these. Before payouts can be made, claims must be investigated. Now, consider a blockchain-based world where information is more reliable. Perhaps a temperature sensor on a truck reports an errant condition directly to the chain and additional third parties verify the state of goods before and after shipment, all writing to the same database visible by the insurance company. It's hoped that by increasing the voracity of information from sensors and multiple parties not only will fraud go down, but systems can be automated. Blockchains can not only store data, but also process data through programs called smart contracts. These are programs that operate on the blockchain with high certainty. Members running a blockchain all run the smart contracts themselves to verify results. A smart contract could automate an insurance payout based on temperature data or arrival time, removing the cost of verifying and processing completely. Smart contracts get more interesting the more connected they are to the real world. One example of this is a smart lock to a warehouse. A smart contract could automatically transfer access to the warehouse and its contents upon payment of an invoice. While the legal framework is still under development, there are even more possibilities if we can tie legal, real-world ownership to records on a blockchain. This is called asset tokenization. Tokens are records of ownership, somewhat like deeds, but are easily transferable on a blockchain. The company Sweetbridge hopes to utilize tokenized assets to allow companies to provide pure-to-pure loans without any banks involved. Loans would be backed by tokenized assets like buildings, equipment, or even accounts receivables, all of which could be controlled by smart contracts that automatically transfer those assets if a loan is defaulted on. The World Bank and Sweetbridge note that 50% of small businesses lack access to financing and on average wait 42 days between invoice and payment. Sweetbridge hopes smart contracts can fulfill this massive, unmet need, but it will likely be some time before the legal world recognizes a blockchain smart contract that truly owns and controls physical property.

A Smarter, More Efficient Energy Grid, Peer-to-peer Markets Let's now move on to another industry that's increasingly becoming more decentralized, energy. As more green energy comes online, such as rooftops, solar panels, and wind generators, energy distribution is becoming more distributed and complicated. There's no longer a top-down model of a single generator and many end consumers, but rather a distributed network where consumers may also be suppliers. The grid is ill-suited for this new configuration, both electrically and financially. Siemens and a startup called LO3 piloted a micro grid in a Brooklyn block where owners of solar panels could directly sell power to neighbors via a blockchain ledger rather than back to the utility. The ledger enables direct pure-to-pure purchasing and also provides a secure record of transactions. There is also interest from local businesses buying green local power and giving those customers special credits. Now certainly the power company could deliver this service on a website, but blockchain removes the need and cost of a third party to stand in the middle. Blockchain can also unlock efficiencies beyond just enabling a pure-to-pure network. Let's look at the financial side of the energy market to understand how. Most people pay for electricity only after they use it, mainly because it would be infeasible to buy electricity one minute at a time. This introduces a risk that someone will use a whole month of electricity and not pay for it. A company called Grid+, made of people that also worked on that Brooklyn project, is making a device that will enable minute-by-minute purchases using the blockchain. Grid+ acts as a local utility, buying power from the wholesale market and selling it to its end customers who have these devices. The smart devices pay for power in near-real time. Grid+'s device gets even more interesting when customers start installing home batteries. The devices could buy power when it's cheap, sell power back to the grid when it's expensive, and even connect to thermostats and other appliances to make further automatizations. Interestingly, Grid+ is not using a private network, but rather the public Ethereum network. We've already mentioned several problems with public blockchains including performance, privacy, and cost, but another is the volatile price of their tokens. You can think of this as a kind of foreign exchange risk. If you enter into any smart contract over a period of time, say a month-long apartment rental, you might end up over paying if the price of a public network token, like Ether, goes up 25%. Grid+ has developed a range of technologies to overcome the public network drawbacks including payment channels to boost performance and reduce transaction fees, a stable token to shield customers from swings in price of Ether, and a physical device to simplify the management of cryptographic keys for the end user. So, with all these needs, why not just use a private network? For Grid+, it's important that their end customers retain what's known as user agency or control over their funds. Running on Ethereum provides a much stronger guarantee of user control. It also eliminates another major category of risk for Grid+ called custodian risk where they hold and control user funds. If the end users have true control over their funds at all times, Grid+ avoids that risk and its inherit regulatory oversight. Immutability and user agency are two aspects that private chains may struggle to port from public ones. These kinds of smarts on the edge of the grid can not only help individual customers save money, but also reduce overall system cost. Utilities must build transformers and power lines to handle the peak loads. Dramatic changes in loads, whether due to air conditioners turning on or clouds blocking solar panels, also cause large cost. Turning on and off powerplants is costly and the bigger the swings, the costlier. If demand can be leveled out by exposing real-time price incentives to end users, there could be substantial savings for the entire system. The additional visibility and secure record of energy production and consumption can enable other goals as well. For example, if you produce energy from renewable sources, your energy could be tagged as green. Other individuals, companies, or government incentive programs could pay a premium for that green energy, somewhat like carbon credits. Now this kind of world depends on smart meters and switches to fairly document energy flows. What's to stop someone from hacking a meter to defraud the system? Luckily blockchain's secure record can provide a clear trail of fraud in this case. There will also likely be providers that audit meters to inject additional trust into the system. Now, blockchain will not solve all problems as the grid becomes more decentralized and smarter. Even if I can buy power directly from my neighbor, somebody still has to pay to maintain the powerline going between our houses and the connection to the larger grid. But programs on blockchain could automatically reserve a portion for utility providers. And to be clear, some of the benefits I mention here are due to digitization, not just blockchain. But blockchain has the potential to help automate the marketplace of money and energy and do it in a cost-effective and secure way. I'll mention one other project that's now up and running and beginning to show the possibilities. Innogy, a subsidiary of RWE, the European energy giant, has recently launched an electric car charging system where consumers can purchase and sell electricity through an Ethereum-based network. The company called Share&Charge interestingly makes no mention of blockchain on its website. It only mentions the convenience of the app and benefits of using its network. Blockchain merely provides the back-end plumbing. This is exciting because it shows the power of blockchain and IoT together. We can even imagine a future where the car itself becomes connected. Imagine a self-driving car that runs its own business collecting fares from riders and using those fares to pay for power at charging stations as needed.

Equities, Finance, Banking, and Payments Let's now look to the financial world where some of the first experimentation with blockchain for enterprise took place. Just as paper bills of lading are still relied on in the supply chain world, stock issuance in the private equity market is also largely still paper based. In 2015, Nasdaq began testing a product called LINQ that digitizes stock issuance for pre-IPO companies. Rather than sending around paper certificates, stocks are issued digitally and stored on a blockchain-based ledger. This makes the current and historical ownership of shares easily visible. Now one could argue here that blockchain is not needed to digitize stock certificates, but Nasdaq sees this simplified case as an important first example of legally handling stocks on a blockchain. The larger public stock market where there are many intermediaries and regulations can yield much greater benefits. Despite public stocks being digital for some time now, there's still nearly 2 days between a buy or sell action and actual settlement. Settlement means that cash has changed hands and the security record is officially in the name of the new owner. Stocks are now largely stored in central security depositories, but investors do not interact directly with these registries. Investors act through what can be multiple layers of custodians, banks, and intermediaries, especially in international transfers. These intermediary layers handle numerous roles: checking investor identity to comply with anti-terrorism and money laundering laws, making sure those customers have sufficient capital for trades, and netting trades to reduce overall transfers. While these services are necessary, significant capital is tied up in this process. Records get confused and must be reconciled and there is risk of companies going bankrupt during the trades that must be insured against. In one shocking example of what can go wrong, when Bear Stearns collapsed, it was found out that 28% more Bear Stearns shares were on record than had ever been issued by the company according to a report by Euroclear. A single record maintained on the blockchain would eliminate the potential for these reconciliation costs and hopefully bring about tZero, or instant settlement, by giving investors direct control. Directly connecting investors could also bring benefits to other related processes like investor voting and communications. Right now, there is no easy way for a company to reach its investors. Communications must travel through layers of intermediaries. Nasdaq created another pilot in Estonia to address this where companies were able to send votes directly to share owners, and those owners could either vote or easily delegate those votes. Once data is shared on a blockchain, better opportunities for automation also arise. Smart contracts or programs that run on a blockchain could execute automated dividend payments, margin adjustments, and corporate actions. In such a highly regulated environment, this type of transformation will not be without its complications. There will be cases where these smart contract programs face situations that weren't thought of before deploying the code, and human intervention will be needed. Another regulatory complication involves jurisdiction. Currently, the location of the golden record of the stock takes precedence. In a distributed ledger, however, there is no single golden record as the record's ownership is truly distributed. The upcoming right to be forgotten law in the EU may also cause complications as blockchains are designed to be immutable. The regulatory issues are not all negative though. Currently, regulators receive reams of data from firms and must decipher this data in an attempt to ensure the market, as a whole, is not facing systemic risk. Fredrik Voss, VP of Nasdaq blockchain, uses the phrase regulatory goggles as a way to give regulators special access to the entirety of market data on a blockchain. By operating a blockchain node themselves, regulators could get access to data in real time and, importantly, the real data, not reports that must be cross checked. Moving beyond stocks, there are several other areas where financial institutions are exploring blockchain potential. Any organization involved in the financial system is facing more and more stringent customer identification requirements. In the U.S., these laws are known as KYC and AML, or know your customer and anti money laundering laws and require institutions to ensure their customers are not doing anything illegal. This requirement can be expensive and requires substantial data collection from customers, verification, and investigations into the data. Financial institutions spend anywhere from 60 million to 500 million per year to keep up with know your customer and customer due diligence regulations, according to a Thomson Reuters survey. The French bank, Credit Mutuel Arkea, is piloting the use of blockchain to share KYC documents between different divisions. For example, if a customer provided a passport to open a new life insurance policy, that information could immediately be made available to the bank's consumer credit group. The bank is even looking to provide identity as a service to third parties, such as utilities, retailers, and service providers. The State Bank of India has also recently announced a similar initiative to share customer data among banks using blockchain. If more verifiable information becomes available about customers, even on blockchains not run by banks, it could open up new lending markets, providing a credit history to previously unbanked. A blockchain track record of sales could provide sufficient creditworthiness. Similarly, small- and medium-sized businesses may be better able to provide collateral information. I'll end this section with a brief note on payments, perhaps the most obvious area of potential improvements given the ability of bitcoin to transfer millions in minutes across borders. International payments currently go through a system of correspondent, banks, a point-to-point relationship-based system. Once again, blockchains can remove the need for intermediaries. And if we look at the company side of payments, there is substantial reconciliation costs that could be saved. A report by IBM claims its own internal accounts payable group was able to save 60-80% off each invoice cost by utilizing blockchain technology. The report explains that much of the work performed by accounts payable teams results from inconsistent data between suppliers and buyers, and blockchain's single version of the truth eliminates this. The same report says IBM global financing is able to reduce dispute time from 40 days to 10 and free $100 million in capital through the use of blockchain.

More Efficient Patient-centric Healthcare Healthcare is another area where better data visibility and interoperability between organizations would yield massive benefits. On a personal level, at least in the United States, patients must fill out new paperwork at every new provider, as each provider maintains their own records. When doctors need to share records, fax machines and phone calls are used and oftentimes data is lost or changed in these transfers, leading to expensive reconciliation or patient harm. Siloed date is not only problematic for patients, but also for the larger healthcare ecosystem. Providers, insurers, and governments all must share data in order to approve payments for treatments. In the fragmented U.S. system, billing- and insurance-related payment processing cost over $470 billion in 2014, over 15% of total healthcare spending in that year. Claims can take months to resolve, leaving providers without pay in the duration. Part of the difficulty is due to patient privacy laws surrounding health information. Patient information must be securely maintained and transferred and only released as requested by the patient or for their care. Allow me to paint a picture of a world where patient data is owned and controlled by the patient and not providers. When the patient visits a new doctor, they use a smartphone app to provide the doctor a key that provides limited access to the patient's health record for the time needed. This could include a general health overview and x-rays, but maybe not genetic information or an AIDS test result. When the doctor accesses the information, a record of that access is permanently recorded in a blockchain along with any new test results and analysis done by that doctor. Needing an operation, the patient gives permission for the insurance company to view their record to provide preapproval. Preapproval is given automatically and without any human intervention because the insurer has proof via digital signatures that the notes are from the doctor and that the doctor has the appropriate licenses. After the procedure, payment is also automatically released. The hospital follows up with the patient to make sure the patient is taking necessary drugs and attending physical therapy, after which the insurance company provides a bonus payment for following best practices. The patient automatically receives a notification about a new clinical study for their procedure and elects to submit selective data about their health in return for a payment. That study takes advantage of long-term data about the patient's health and provides more personalized care in the future to another patient with similar characteristics. While this scenario may seem magical to U.S. citizens, many companies are working towards this vision with promising initial projects. Estonian citizens have actually had their health records stored on a blockchain since 2015. A company called Guardtime provides a blockchain where any change to data is recorded, thereby providing extremely durable, auditable health records. Another project is attacking an interesting niche, provider identity. When a provider wants to get a job at a new hospital, the doctor must submit their school, residency program, and information about any state licenses they have. The hospital then needs to verify each piece of information by calling the original sources individually. A company called Hashed Health is setting up a blockchain-based registry in the state of Illinois where all these different groups can submit information once and not have to repeatedly answer verification calls. Hospitals can trust records in the registry because digital signatures guarantee the data was produced by the entity claiming to have produced it. It's an interesting starting place because it doesn't involve sensitive patient data and can begin to show immediate benefits to the healthcare ecosystem. Several other companies are attacking the payment problem head-on with blockchain. A company called Gem has launched a project that reduces claim settlement from 48 days to 5 minutes. They take an interesting approach, never storing actual patient data on the blockchain, but just pointers to that data along with permission policies. All records are linked to a specific patient ID, thereby allowing long-term views of the patient's health. It even provides some amount of automation, sending out explanation of benefits based on preconfigured rules and approval of claims. These examples paint a promising picture of blockchain's potential, even in the extraordinarily regulated and entrenched healthcare industry. Extra visibility into more data should help research and even enable new payment schemes like value or outcome-based payments. Currently, there is little data available about outcomes when patients aren't taking part in explicit surveys. By better managing this data, blockchain may provide markets and incentives to collect this data. This could also include the flood of data from IoT devices like heart rate, glucose, steps, etc., now much of which is never utilized. There are, however, still many questions to answer. Existing health systems will not simply plug into new blockchain networks any more easily than they would to other systems. Integration work and agreement on standards will still be needed. Also, blockchains may be good at preventing data modification and recording who changes or accesses data, but duplicating data across many different nodes, even if encrypted, may increase potential for leaks.

Enterprise Application Survey Summary Blockchain technology provides a single version of the truth collaboratively maintained by untrusting groups. As we've seen, the potential benefits cut across a wide variety of industries. Blockchain eliminates the need for intermediaries to stand between people trading stocks, energy, health data, or money, enabling faster, cheaper, less risky transfers. Increased data visibility empowers regulators in food safety and finance, enables smarter decisions in the supply chain, and also opens new markets from customers looking for environmentally-friendly food or energy to bankers offering loans based on information outside traditional credit scores to health researchers looking for more data. Importantly, that information is only valid if it is indeed true. Blockchain ensures this with irrefutable signatures on data, a storage structure that makes tampering nearly impossible, and strict rules on new data entering the blockchain. Mistakes, fraud, and counterfeits can be drastically reduced. A flood of information is being generated from IoT sensors in our homes, cars, and bodies, and blockchain is poised to help create a market for that data while hopefully enabling people to truly own and control it. Finally, when companies and assets are digitally connected and can trust information, smart contracts on blockchains can automate processes that used to require manual intervention. But all these benefits do not come without significant challenges. Blockchain networks become more valuable as more members participate, but this requires wider-spread agreement on standards and protocols. After agreeing on standards, connections must be made to existing enterprise IT systems. While blockchain promises better insights for regulators from the financial world to the supply chain, regulators need to be involved in blockchain's development if blockchain is to be trusted. There are holes in current laws that simply don't contemplate what it means to have a shared database or to own a tokenized asset. And what happens when mistakes are made? What if a smart contract deletes an asset or someone loses a password? Any blockchain implementation will have to have human-level recovery and legal fallbacks. Finally, while sharing data unlocks numerous benefits, it must be carefully shared not to reveal commercially sensitive financial details to competitors or personal genetic information. The blockchains behind bitcoin and Ethereum display all data to everyone in order to provide trust in a resource that anyone can use. Providing that openness comes at the cost of very slow performance and high fees. Luckily, enterprises generally don't want or need such openness. As we'll see in the next module, a wide range of tools are just now coming out of development that provide blockchain technology with the performance and privacy enterprises need.

Surveying Enterprise Blockchain Tools Achieving Consensus: Performance, Security, or Scale? Back in 2015, when companies first started investigating enterprise use cases, many simply copied the public bitcoin or Ethereum code base, hoping to make few modifications to fit those systems into enterprise applications. Problems regarding performance and privacy immediately became apparent. Luckily, groups have been working to optimize for the enterprise world, and this module will give an overview of several of the more prominent ones including Hyperledger, Coco, Corda, Quorum, Stratumn, Guardtime, and BigChainDb. This is by no means an exhaustive list, but we'll cover a range of different technical approaches to highlight important tradeoffs in security, privacy, and performance. Along the way, you'll learn how these systems actually work to achieve consensus and privacy. I'll conclude the course with some comments on what are still controversial topics, including private versus private blockchains and whether a private blockchain is really more than a distributed database. Before discussing specific projects, I'd like to provide some background on consensus, the key algorithm behind any distributed system. Consensus is the process by which nodes reach agreement or stay in sync with each other, and choices about how this is done profoundly affect a network's performance and security. Interestingly, the main technical innovation of bitcoin was actually its consensus algorithm. But algorithms used by many modern databases were largely developed in the 1980s and 90s. The benefit that bitcoin's algorithm and blockchain in general bring to existing consensus algorithms is the ability for peers to work on networks with a lower level of trust. Also, in the case of bitcoin, open or permission-less networks where anyone can join at will. Even in networks where nodes trust each other, it's surprisingly hard to keep separate nodes in sync with each other. Information packets can get lost, corrupted, and computer clocks might be different. Adding the possibility of external and internal attacks further increases the challenge. I find it useful to consider a concrete example of why consensus is difficult. What if Alice has $100 in her bank account, but mails 2 checks out for $75 to Bob and Carol at the same time. This is known as the double-spend problem. The first person to cash a check should get paid while the second person's check should get rejected since Alice no longer has sufficient funds. With a single bank, it's easy to check whether Alice has already written a check. But in a distributed network, it's much harder. Information may reach different nodes at different times, and time stamps can't necessarily be relied on. Suppose Bob's check reaches some nodes first and they update their ledgers and Carol's check reaches others first and they update their ledger, not realizing that Alice's account has already spent that money. Alice just turned $100 into $150 in parts of the network. Both of those checks were valid, but agreement on the ordering of them was the critical part. Interestingly, for the network to remain valid, it doesn't even matter which check was considered first, just that all the nodes agree on that order. As long as all the nodes pick an order and agree to it, Alice can't double spend and only one of Bob or Carol will have been paid. In a hostile network, reaching agreement or consensus is known as the Byzantine General's Problem. It's based on the story of an army of generals that must all uniformly decide to attack or retreat, as a split effort would lead to an outmatched defeat. Just as with a distributed computer network, coming to agreement is hard, especially if there are traitors in the mix and messengers that might get corrupted. With that intro into the problem of consensus, I'd like to give you a flavor for some of the solutions. I'm going to stay fairly high-level, but I think it's useful to peer inside the algorithms to some extent to better understand tradeoffs. We've learned that part of getting a distributed group to share a database is to collectively make decisions on transaction order. One way is to simply appoint one leader to decide that order. All transactions are sent to this leader who picks the order and then sends that order back out to all the other nodes. Now this doesn't mean that the leader can write anything they want to the database. Each node will still verify that transactions are valid themselves. For instance, does the transaction sender have sufficient funds and are digital signatures that prove authenticity valid? To help spread power, a new leader might be selected every block. In bitcoin, the leader is decided through a kind of lottery. As transactions are generated by end users, they go into a pending pool. Next, all the nodes operating the bitcoin network select from these pending transactions and begin competing in the lottery that determines which of their selections will get officially confirmed. To compete, each node tries to solve a special math problem by guessing random numbers. It essentially boils down to rolling dice until you get a number that works. The first node that gets a correct result broadcasts their group of transactions. Other nodes check to make sure this result is correct along with the validity of the transactions, and then these get added to the end of the blockchain. The algorithm is called proof-of-work, and because that work costs money in terms of electricity and computers, it's too expensive for any one person to take over the network. While this scheme is an amazing way for a massive group of anonymous people to participate, it's very expensive. Over 10 million U.S. dollars of electricity is burned every day at the time of this course. The Ethereum network currently uses proof-of-work, but plans to switch to proof-of-stake where participants have to put up bonds that can be lost if they misbehave. While proof-of-stake promises a cheaper consensus, there are still open technical questions. While lottery systems provide a powerful way for systems with massive scale to reach consensus, even in hostile networks, they come at another cost, slow finality or settlement, or a long time between when a transaction is created and when it's considered confirmed. It's recommended to wait an hour after sending a bitcoin transaction, which is problematic for in-store purchases or stock trading, but potentially okay for slower supply chain applications. Let's go back to the leader selection process to see why. All nodes are rolling dice until they get a correct number and then broadcast a block. Because nodes are spread all over the world, some nodes might not hear about a new block immediately and build on the previous end of the chain. So you might receive multiple blocks at around the same time, which is known as a fork. The general rule is to build on the longest chain, but this is sometimes ambiguous. Worse, the branch you decide to build on might suddenly become replaced by two new blocks on a different branch. A malicious person with a substantial amount of nodes on a network could take advantage of this to replace a transaction, effectively undoing a payment. This is why it's recommended to wait over an hour until a transaction gets buried further into the chain where it's less likely to change. While bitcoin's algorithm is scalable and open to anyone, transactions are uncertain initially and take a while to become final. In many applications, this kind of delay is unacceptable. Another type of consensus doesn't have this delay and involves a more immediate voting system. Suppose we have a network of 10 nodes. Several nodes publish a proposed list of transactions for the next block, say three different transaction sets, A, B, and C. All the nodes make a preliminary vote, say two for A, four for B, and four for C. Upon seeing the votes, another round of voting occurs where everyone votes for the version that already has the most votes. The two nodes that voted for A might switch to C, making the score four B, six for C. Now there's a clear majority and a final round of voting results in 10 for C. This transaction set is now locked in and final. The downside is that each node had to talk to every other node multiple times and this quickly becomes slower as the number of nodes increases. Even with fast computers, the speed of light is a major limiter for scaling this type of consensus around the globe. So we start to see some properties of consensus algorithms that we must choose between, openness, scale, transaction finality time, and cost. Voting-based algorithms provide fast finality for small numbers, but slow down as the size of the network grows. Voting algorithms are also less open. Another important characteristic is the ability to handle a certain number of hostile or faulty nodes. Such systems are said to be BFT, or Byzantine fault tolerant, in reference to our Byzantine General's Problem. Both of the algorithms I've described, lottery or voting, can be designed to be BFT. Now, most high-performance distributed database systems that power the majority of our web are not BFT, but only crash tolerant, which means they can only handle nodes losing connections occasionally. These systems are also typically closed and only open to a small number of preapproved participants. As we'll see next, a wide range of tools now exist that allow you to select tradeoffs that best match a given application.

Hyperledger: Fabric, Sawtooth, and Composer Hyperledger is an organization under the Linux Foundation that sponsors a range of blockchain projects and developer tools. In a positive trend shared amongst almost all the larger enterprise blockchain tools, it's completely opensource. Blockchain connections between companies become more useful the more places they reach, so it makes sense that organizations like Hyperledger promote openness and seek collaboration on standards and design decisions. While IBM contributed most of the initial code, there are now over 100 organizations involved from financial organizations like J.P. Morgan, to technology companies like Intel, to automotives including Daimler, stock exchanges, and, recently, the enterprise software giant SAP. Interestingly, R3 is also a member, another group of financial institutions that have developed their own blockchain solution called Corda that we'll cover later. Hyperledger Fabric is the flagship blockchain project within Hyperledger and recently released a version 1.0 in July of 2017. It directly takes advantage of the protected environment most enterprise chains will run in, offering a consensus algorithm that's fast and scalable, but not Byzantine fault tolerant, only crash tolerant. The algorithm is based on the Kafka system originally developed at LinkedIn to handle their massive amount of data flowing to and from numerous applications. Another interesting design choice Hyperledger projects make in general is to separate out verification and ordering. Unlike bitcoin where every node verifies every transaction, in Hyperledger, only nodes affected by transactions need to sign off on them. This design choice improves network speed and also makes it easier to plug in different consensus algorithms for the ordering part. And this brings us to some of the other blockchain projects within Hyperledger, Sawtooth, Indy, and Iroha. Sawtooth uses a very special kind of intel processor to achieve many of the properties of the bitcoin network, including scalability and BFT, without the large cost of proof-of-work. The processors have what's known as a TEE, or trusted execution environment. This environment or protected enclave provides a protected place for code to run that can't even be touched by the operating system. The TEEs also digitally sign the results. This means I can give someone that I don't trust code to run and be reasonably sure that any results they send me were not manipulated. In the proof-of-work lottery algorithm in bitcoin, nodes compete to become the next leader by solving special problems. Instead, on a TEE, nodes just generate a random number, wait that amount of time, and broadcast their block. With proof-of-work, everyone could check the results to make sure no one was cheating and taking the leadership role too often. With TEEs, the signatures on the results prove that the random number was fairly generated within the TEE. This provides the fairness of bitcoin without the substantial cost. There is, however, still latency in transaction finality since this is a lottery-based algorithm. Hyperledger Iroha and Indy utilize a voting scheme that provides fast transaction finality, but can't scale to extremely large numbers. As opposed to Fabric, all these systems are Byzantine fault tolerant, which means they can handle malicious or faulty nodes. Hyperledger's separation between verification and ordering provides a solution to the problem of revealing transaction details to only some members of a network. A seller could create a transaction with a buyer and encrypt it before passing it to the rest of the network for ordering consensus, thereby hiding the pricing details to competitors. Because the transaction only involves that seller and buyer, as long as both of them sign off on it the rest of the network considers it valid without needing to see the details. Later on, the seller may wish to prove her track record to a bank so she might share the encryption key with banks only. I want to finish talking about Hyperledger with a note on some powerful developer tools also under production. Anyone looking into incorporating blockchain will need to experiment and also integrate blockchain technology with their other IT systems. The cost of both of these can be substantial, but Hyperledger has released tools to speed up these processes. Hyperledger Composer enables developers to configure blockchain networks using familiar JavaScript to define participants, process rules, and integrations with other systems. I'll briefly describe one of their sample applications available at composer-playground.mybluemix.net. It represents a vehicle lifecycle system. The participants include individual car buyers, manufacturers, regulators, insurers, police, and standards testing companies. This is a great blockchain application because it represents a case of completely separate organizations that all must share data. Now, blockchain doesn't remove the need for every participant to communicate with agreed-upon standards, but it does remove the reconciliation process that would inevitably be necessary when separate organizations maintain records. By having one view of the truth replicated on a node at each organization, information is kept more up-to-date and accurate. Here we can see the blockchain playground portion where you can set up the types of participants, the rules for how data gets added, including which participants need to sign off on various transactions, and also permissions. In addition to the blockchain portion, their demo provides some examples of how you might connect the blockchain application to other applications. For example, there's a mobile app that a buyer uses to select car color and then purchase and a web application dashboard that the regulator uses to monitor the vehicle registry. It has a suspect vehicle report showing a vehicle that was written-off by an insurance company, but then registered to a new buyer, a possible case of insurance fraud. These applications connect to nodes running the blockchain application to create transactions and also query data for analysis. Any blockchain application will need to similarly integrate with existing ERP and authentication systems and the outside world. Overall, Hyperledger provides a powerful toolset that has been developed with significant consideration towards helping developers get started and integrate with the existing IT world.

Microsoft Coco Framework Microsoft has recently announced an enterprise-focused blockchain framework that promises performance approaching standard databases along with substantial privacy enhancements. It also takes advantage of the trusted execution environments, or TEEs, on special processors like Intel's SGX line. We mentioned these previously as a way to pick the leader in the Hyperledger Sawtooth project. They enable you to trust the output of code running on machines that you don't trust. Coco takes advantage of this property by running a majority of the blockchain system within these environments. If we can trust that the code running on all the machines hasn't been tampered with, consensus algorithms that don't protect against malicious participants can be used. Another benefit is that non-deterministic functions can be run. We saw this with the Hyperledger Sawtooth project where a random wait time was calculated for each node and nodes would broadcast a block after their generated wait time. Everyone can trust that the wait times were generated fairly by looking at the digital signatures generated within the TEEs. In contrast, on the public Ethereum network, smart contracts cannot rely on random number generation. Every node runs every smart contract to check results for itself, therefore code must be written so that the results will be repeatable by anyone that runs it or in other words, deterministic. TEEs enable you to trust that someone else generated a fair, random number. In addition to faster consensus and the ability to use random numbers, TEEs provide compelling privacy advantages. Consider our example of the seller not wanting to reveal pricing data to competitors. All transactions remain encrypted unless inside the TEE where even the owner of the code cannot see the decrypted data. All nodes can run verification code themselves on the raw data, but never see it. This also opens up the possibility for even finer-grain privacy rules. Before, we mentioned that the seller might want to prove her track record with banks to get a loan. While she could give banks full access to all her transactions, she might also only want to give access to quantity information and not pricing. With a TEE, the program can decide exactly which data is delivered across the protected zone to the host system. This kind of fine-grain control is something that enterprises already have in their existing systems and will expect to have. It opens the door to many use cases, such as documenting practices that help the seller market himself. For example, proving that the seller pays a good wage to its workers without revealing who the workers are. One final feature of the Coco framework is its first-level support for system governance. By governance, I mean deciding things like which members can access the network and what version of code to run. Coco outlines two levels of nodes: members and participants. Members can vote on participants and code versions while participants can only operate on the network, not change it. Members also maintain portions of a master decryption key. If a major problem happens on the chain, they can combine their keys to decrypt the entire database outside of any TEE. Interestingly, Coco is not a complete solution, but rather an underlying framework to which you would need to bring your own smart contract code, which could be a ledger like Ethereum or Corda.

R3 Corda Blockchain Corda is another opensource blockchain project that focuses on privacy. Originally targeting financial services, Corda is a product of R3, a firm with investment from over 100 banks and technology companies. In May of 2017, a second round of $107 million U.S. was added with investment from SBI Group, Bank of America, Merrill Lynch, HSBC, Intel, and Temasek. A 1.0 version was released on October 3, 2017. Corda began designing their framework with specific financial use cases like stock and derivative contracts. A typical stock example is a payment versus delivery contract for a security where Bank A would agree to deliver a security in return for a cash payment in three days. An example derivative contract is an interest rate swap. Suppose Bank A has a given fixed rate loan for 1.5% and Bank B provides a loan for a floating rate. To avoid the risk that payments would go down if the interest rate falls, Bank B could enter a contract with Bank A to swap floating payments for fixed ones. These two examples give us some insight into one of Corda's staring assumptions, most contract information only needs to be shared between the participating banks. Unlike many of the other tools, transaction information is not shared with the wider network, even in encrypted form. There is no global ledger to which all transactions are broadcast and added. Rather, each node holds only the data relevant to transactions in which they are participating. Now there still needs to be a way for nodes to verify information about transactions. What if Bank A tries to send an asset to both B and C, how would they know it wasn't trying to double spend? Corda provides a notary service in this case. The notary can act on the full details of a transaction, or where privacy is more important, just on a hash or fingerprint of that transaction. The stronger privacy case does open the possibility for some attacks that would break the network, however. Like many other systems, the consensus algorithm is pluggable, so different users can decide what tradeoffs between security and performance they want. Like Hyperledger, Corda also seeks to provide developers with familiar tools to write smart contracts in. Corda uses a Java virtual machine to execute contracts, a very familiar environment for enterprise developers.

JP Morgan Quorum: Enterprise Ethereum Quorum, developed by J.P. Morgan Chase, is another blockchain initially targeting the financial world. It seeks a similar set of goals as Hyperledger, Corda, and Coco, high performance with privacy rules tailored for an enterprise world. Quorum initially targeted financial problems like long settlement times and providing regulators with a transparent view of risk inside institutions. Unlike the systems I've discussed already, which are largely built from scratch, Quorum is designed to be as close to the public Ethereum network as possible, pulling in updates as public Ethereum evolves. It differs in two main ways from public Ethereum. Quorum supports private transactions and a voting-based consensus mechanism rather than Ethereum's proof-of-work scheme. Quorum does still support public transactions and smart contract execution, but it adds a new class of private transactions and corresponding considerations for consensus on those private transactions. For a private transaction, data is encrypted so that only the nodes party to that transaction can decrypt it and run the internal smart contracts. Other nodes on the network receive a hash of the transactions, but cannot run it themselves to verify it. In this manner, nodes will end up with two ledgers: a public one that is generated by running all public transactions and a private one that's a result of private transactions. Quorum differs from Corda in that all nodes record a hash or fingerprint of every transaction, whereas in Corda, only notaries will be aware of private transactions. The Quorum method ensures a wide-spread, tamper-proof record that transactions occurred even if the contents are hidden. This concept of only processing and storing relevant transactions is a form of transaction sharding, a technique in the database world where the larger database is stored in pieces rather than fully replicated in every node. It intuitively makes sense that nodes that aren't part of a transaction shouldn't need to expend resources to check it. Hyperledger Fabric also offers a form of this by separating the validation of transactions from the ordering consensus. Only nodes that are part of a transaction need to run and verify it. Because Quorum is closely based on Ethereum, it naturally comes with a built-in token, whereas the other systems do not have native tokens. Quorum also benefits from technologies and development tools being developed for public Ethereum.

Guardtime and Stratumn I want to briefly mention these two companies because of their prominence in the space and their focus on the use of the blockchain as a powerful notary service. Guardtime is one of the oldest and largest enterprise blockchain-focused companies siting over 150 cryptographers on its staff and having been founding before bitcoin was introduced to the world. They have an impressive track record of working on many large projects including storing the health records of all the citizens of Estonia and recently a new project for the U.S. department of energy to help secure the energy grid by detecting attacks. Their keyless signature infrastructure technology stores timestamped hashes of the state of a system in a blockchain, notarizing a clean state. In this way, any unauthorized changes can be quickly and precisely detected, thereby providing a hacker detection system. Guardtime notes that hacks are only a matter of when for most systems, so their recommendation is to set up systems that can detect and respond to attacks quickly. Their systems only support a small number of nodes to provide BFT at the same time as high performance and fast transaction finality. Stratumn provides proofs of process, similarly based on hash chains that prove a record of who, what, when, where, and why a process happened. This can be used to prove that an agreement was carried through with a partner or to prove compliance with regulators. Interestingly, both Guardtime and Stratumn systems provide a kind of proof that doesn't reveal any private data. Hashes of data are unique to that data, but don't provide any way to go back to it.

Conclusions: Public Blockchain vs. Private vs. Database While there are many, many more private blockchain projects focusing on enterprise, I hope this selection gives you a good idea of the different ways groups are approaching blockchain. We see a surprising amount of commonality: open source projects, development tools that are friendly to enterprise developers, high performance requirements, and an emphasis on privacy. This not only includes strict controls on who can use the system, but also per-transaction privacy rules and ideally data within those transactions. We see there are many tradeoffs to be made on the consensus side, the key algorithm that enables distributed nodes to agree on one version of the truth. Smaller networks are easy to make fast and secure enough to handle some faulty or malicious nodes, but as we scale to larger networks, tradeoffs have to be made in terms of transaction settlement or finality and security. Interestingly, many of the projects provide the ability to swap out different consensus mechanisms so you can make these tradeoff decisions without switching the overall framework. Another key aspect to deploying blockchain is governance, and by this, I mean a system for deciding on the standards, code, and access. This is something that any network will need to perform on an on-going basis. More recent frameworks like Coco have governance voting systems built in from the start. I want to conclude with some thoughts on the still controversial differences between public blockchains, private ones, and databases. Initially, companies tried to use bitcoin or Ethereum code out of the box to bring all the promises of blockchain to the enterprise world. As we've seen throughout this course, these include better access to more reliable data, removing intermediaries, and automation across company borders. All of these hopefully yielding higher efficiency, reduce fraud and reconciliation cost, and new markets. But performance and privacy concerns were immediate roadblocks. Bitcoin and Ethereum can only handle a few transactions per second and broadcast every transaction to the entire internet. So enterprise developers have created their own systems, trading openness and sometimes scale for performance and privacy. But many people argue that by making blockchain systems private, you're fundamentally removing the value provided by public blockchains and are really just putting fancy clothing on existing distributed databases. Now, many of the projects discussed in this course have just been released to the world, so this debate will soon benefit from some real outcome data. But I do think there's some merit in the naysayer's arguments that's worth keeping in mind. In many respects, private blockchains are indeed very close to existing distributed databases. Hyperledger Fabric achieves its high performance by building on top of one of those, the Kafka system. Another company, BigChainDb, made similar design decisions. Rather than try to get a blockchain to perform as fast as a database, they started with a high-performance distributed database and added a blockchain layer on top of it. This blockchain layer requires digital signatures and adds hash chain connections to new data, thereby providing a more immutable and trustworthy record of data than the database would by itself. But there are some aspects of public blockchains that private ones don't share. We mentioned immutability before with the Everledger diamond-tracking example. While keeping full transaction details on a private chain, they stored hashes of those transactions on the public bitcoin network as a way to guarantee those transactions never change. It would be very difficult for a private group of companies to prove to an outsider that data had never changed. This may be even more relevant to regulators who may need to run a node themselves to be assured of data immutability. Another aspect from the public blockchain that enterprises have left behind is a token and currency. Many of the enterprise blockchain projects use this as a bragging point to help separate themselves from the criminal uses of bitcoin, such as tax evasion and illegal drug buying. But the outlook on tokens is beginning to change. Many companies are crowd sourcing funds and ICOs, or initial coin offerings, which provide a new way to connect with hybrid investor customers. In Ethereum, tokens provide powerful incentives to maintain good behavior. In a small network of 5-10 entities, the legal system might be sufficient to maintain good behavior, but what about an enterprise network on the supply chain with tens of thousands of participants? Tokens provide a way to easily exchange value that's also programable. A seller could require a buyer to post a deposit in a smart contract as a form of trustless escrow. In some sense, tokens are already being used by enterprises for things like airline miles or loyalty points or coffee stars. And as we saw with the Grid+ electricity buying network, tokens can provide a way for companies to reduce custodian risk, giving their users true agency or control. But a user's control depends on the immutability of the network. A single airline can change the formula for how many points are needed to buy a flight, but Grid+ cannot simply add new Ether to its devices without paying for it. Now I think privacy and performance considerations will outweigh the immutability and token benefits of public networks in the near term, but it's likely public networks will address these issues in the future. There are many technologies under development in public networks that will speed performance. Many of these work by enabling nodes outside of the network to do most of the processing, but providing systems that still ensure that work is valid. We saw some examples of this in Hyperledger by only requiring nodes involved in a transaction to process it. For cases where the entire network does need to check a transaction, check out lightning networks, payment channels, and a company called TrueBit. TrueBit is making a game-like checking system where transactions are executed by only a few nodes, but checked by others that get a reward if they find a problem. And on the privacy front, new encryption technology, like homomorphic encryption and zero knowledge proofs provide a way for nodes to check transactions without seeing the raw data. Right now, these methods are limited, but the technology is evolving rapidly. I hope this course has shown you that the characteristics of blockchains are not black and white, but rather sliding scales of performance, security, and privacy. Private blockchains may very well go the way of private intranets in the 1990s, but I believe that is still some time off. I'd like to make a final note on tools making it easier to get started. Blockchain is as new as the internet was when people were still debating whether customers would ever buy things online. So what it is and where it fits are evolving rapidly. Luckily, it's getting easier to test out blockchain to find out where it will shine. Both Microsoft and IBM provide blockchain as a service offering where you can stand up new blockchains in a single click on their cloud. I showed some of these tools when talking about Hyperledger before, but here is a listing of Microsoft's options, which include pure Ethereum, Quorum, Hyperledger, and many more. Once you test out your business case, you can run the code in their clouds or on-premise if you don't want to trust a cloud operator. Another great first step is to join a group like Hyperledger or the Enterprise Ethereum Alliance. It's a rapidly moving world. I encourage you to jump aboard to help shape blockchain to fit your business needs. I want to thank the Epicenter podcast for providing immeasurably helpful information on numerous enterprise blockchain projects.