How Boeing, Toyota, Caterpillar, and other OEMs can double their current net profit by using smart contracts to become unmanned “virtual companies”, with or without cryptocurrency: Part 5

Roger Feng
4 min readOct 27, 2018

--

The critical security role of the oracle

It’s worth noting that smart contracts themselves cannot directly talk to APIs. Ethereum, and other Turing-complete cryptocurrencies, are deterministic. APIs are incompatible with their consensus mechanism. A piece of middleware called the “oracle” is needed.

The oracle handles the “if” part of the if-then statement. This is an excellent article that explains it further: https://www.americanbanker.com/news/the-race-to-connect-smart-contracts-to-the-real-world.

With so much depending on the inputs to the smart contract, it is imperative that the smart contract is not corrupted by “fake data”.

Suppliers would have plenty of incentive to trick the OEM into over-buying components (that will go into building vehicles that won’t actually sell). Ford alone spends over $100 billion each year on purchasing supplied components: https://www.bloomberg.com/news/articles/2013-10-21/ford-wants-to-pare-number-of-suppliers-by-40-executive-says.

Wall Street short sellers would also have billions of reasons to tank the stock by interfering with and/or sabotaging the OEM smart contract.

As mentioned in part 4, the banking and financial industries are already plagued by fake data, with the potential for catastrophe rising as automation increases (see appendix C towards the bottom of part 20). Why would the manufacturing industry be any different? The incentive is certainly there.

When it comes to securing the input, there are 4 levels of security:

1. Information from a centralized source, delivered by a centralized oracle node

2. Information from decentralized sources, delivered by a centralized oracle node

3. Information from a centralized source, delivered by decentralized oracle nodes

4. Information from decentralized sources, delivered by decentralized oracle nodes

With levels 1 and 2, the centralized oracle (i.e. Oraclize) would be the point of attack. With level 3, the attack would have to corrupt the cloud server that is hosting Clari. Having a centralized point of failure handle such critical and consequential information is clearly an unacceptable risk. To quote several industry voices:

1. “If the oracle is compromised, so is the entire contract; this is one reason why centralized oracle services are not considered a serious solution to “The Oracle Problem” in most cases”-https://medium.com/@DelphiSystems/the-oracle-problem-856ccbdbd14f

2. “The thing with smart contracts is that they are unable to take initiative. They will not react to events unless explicitly told to do so with a transaction. This is what makes oracles so important……An oracle which can alter the state of a smart contract is a potential attack vector. If it has elevated privileges, the oracle can do real damage and cause loss of funds.”-https://blog.sweetbridge.com/sweettech-writing-harmless-oracles-8ed97a077ee6

The chosen oracle must be decentralized, which leaves us with Chain Link by process of elimination. Chain Link is a novel solution and promising project that even has a partnership with SWIFT: https://fynestuff.com/chainlink-vs-decentralized-oracles-analysis/.

Chain Link allows security level 4 to be realized. What would that look like? 10 cloud servers each run their own instance of Clari. 100 Chain Link nodes, 10 for each server, pull the data from their respective Clari API.

For each Clari API, the 10 nodes reconcile via Chain Link’s consensus feature. Afterwards, the 10 groups reconcile again via Chain Link’s aggregation feature. Only then is the input finally fed into the smart contract.

These consensus and aggregation features have already been tested as part of the partnership with SWIFT: https://www.coindesk.com/swift-startup-winner-demos-smart-contract-trade-5-financial-firms/, https://create.smartcontract.com/sibos17.

Finally, it’s worth noting that Chain Link can handle any web API as an input. As well as inputs from CRM (customer relationship management) software like SAP and Salesforce.

If you are unclear on what APIs are, please see appendix E (at the end of part 20). APIs will come up again and again throughout this whitepaper.

Continue to part 6….

--

--