1. Smart Contracts that Learn (Extended Version)
Mike Slinn June 29, 2018 IBM Ottawa
This is a complex subject where details matter, so this presentation is a longer version of what I presented at the Global Blockchain Conference in April earlier this year. You do not need a background in ML in order to appreciate this presentation.

2. About Mike Slinn Distinguished engineer
Contributor to Ethereum Java and Scala libraries
Operates ScalaCourses.com
Author of EmpathyWorks (artificial personality)
Expert witness
Twitter: mslinn
Recognized as a software expert in US federal court and in Europe.

3. Key Facts about Mike Slinn
Focuses on generating business value by applying people, process and technology
Wrote 3 books on distributed computing
Created hundreds of online lectures on advanced computing concepts
Uses many computer languages (“polyglot”)

4. In 10 Years (2028) I would like to begin with a brief look ahead.
Traditionally, businesses and legal frameworks and societies have evolved much slower than technology.
All 4 (technology, businesses, laws and societies) must co-evolve together.
Technology will not always be the leading force – today societies all over the world are under intense pressure to evolve, and once key factors are addressed, huge forces for change will be unleashed.
Businesses will also change.
The meaning and purpose of work and currency will fundamentally alter.

5. The most popular language or framework used to write smart contracts in 10 years probably has not been conceived of yet.
-- Mike Slinn, March 3,
These are early days for blockchain and cryptocontracts.
There is much experimentation, and evolution is fiercely competitive.
Most platforms, languages and frameworks used for smart contracts today will probably no longer be in common usage in 10 years time.
You should not expect that smart contracts you might have in this timeframe will be able to run on the most popular platforms 10 years from now without significant work.
Maintenance costs for early technology such as smart contracts inevitably become quite significant over time.
Today, proof of concept projects using smart contracts have run their course, at the present time, projects are now underway that are intended to return significant benefit.
Regulatory jurisdictions will probably fall under several spheres of influence, and technology will become balkanized to some extent as a result.

6. Machine Learning & Smart Contracts
Machine learning (ML) will be commonly used with smart contracts in 10 years.
Highly specialized languages will evolve to define and verify contracts in various industries.
ML will have features added to guarantee deterministic results for decentralized apps.
Security will surely have to improve
Languages evolve in order to express concepts efficiently. For example, Eskimos are well-known for having many words to describe snow and ice.
Runtime libraries dedicated to specific industries will likely not be robust enough to meet security and correctness requirements.
A language optimized for supply chain should be somewhat different than languages optimized for insurance, online gambling or tourism.

7. Espionage
In 10 years time corporate and nation/state espionage will include:
Sabotaging training data
Spoofing smart contract events
Seeding smart contract templates with security weaknesses
… and lots more …

8. Key Takeaways Newspaper Style
This portion of the talk contains the top-level conclusions.
This presentation will give you the conclusions first, then delve into more detail.
You do not need to wait for the end to know the main points.
Some of the slides that follow might seem disconnected because the background will be presented throughout the remainder of the talk.

9. Dogma and ideology are not good for business
Dial Back the Koolaid
Dogma and ideology are not good for business
There is an American expression “Drinking too much of the Koolaid”, which is a reference to the 1960s, when young people mixed LSD (a powerful psychoactive drug) with a sweet artificial drink called KoolAid. They of course lost touch with reality, at least for a while. Some people never returned from that trip.
I will reference web3 dogma when appropriate.
I will also commit heresy by advocating that the choice of centralization vs. decentralization is a business decision, and that decision will likely change over time.

10. However, these can learn:
Confession
On-chain smart contracts cannot actually learn
However, these can learn:
User interfaces for on-chain distributed applications (ĐApps)
Oracles
Gateway contracts
Off-chain smart contracts (systems integrated via json- rpc, IPC and other mechanisms)
inter-process communication (IPC)

11. On/Off Chain Computation
Geth Parity
etc
This diagram shows the blockchain on the right, with four nodes shown, each of which has an Ethereum Virtual Machine (EVM).
For Ethereum, onchain computation means that every Ethereum node executes every contract in their EVM, and the results are compared. This is how consensus is achieved. Consensus is required for a transaction to succeed.
Off-chain computation can be performed in an application that uses json-rpc or inter-process communication (IPC) to communicate with an Ethereum client, which forwards state changes to the blockchain. Consensus is not required for off-chain computation.
Off-chain computation is appropriate for long-lived, resource-intensive processes, such as those required by ML.
I will show you some diagrams for several use cases of off-chain computation shortly.

12. Beware Non-Deterministic Behavior
Blockchain requires determinism for consensus
A ML-driven product may not have deterministic behavior and may produce counter-intuitive results
A personalized recommender system may produce different results for a user action after learning additional preferences
On-chain smart contracts must operate autonomously with predictable behavior.
They execute transactions on multiple nodes of the blockchain network when they are triggered.
On-chain smart contracts must be deterministic in order to achieve consensus of the smart contract output for each transaction.
This means that for a given transaction, the same input to a smart contract must produce the same output on every node that it executes on.
In contrast, a non-deterministic contract could return different results for each node, which would make consensus impossible.
Smart contracts that learn by definition produce different results (in terms of regressions and classifications) for the same input over time.
The challenge for on-chain smart contracts is to integrate machine learning in such a way that multiple instances of a given smart contract achieve consensus for each transaction.

13. ML is Done Offchain
ML is currently centralized offchain, because significant computation and storage are required
Centralized, offchain processes can respond to onchain events and initiate activity via json-rpc or IPC to Ethereum clients
ML likely not decentralized for several years

14. ‘(De)centralization’ is Misleading
Decentralization uses consensus before output is accepted from multiple EVMs, which then leads to transactions.
Centralization does not use consensus; note that the web3 definition of centralization includes federated systems and distributed applications that employ DNS with geolocation routing and failover.
“Centralized” is a misleading term, as is “decentralized”.
Modern enterprise-level distributed computing architecture is “federated”: distributed, not centralized, featuring edge computing, regional DNS, failover DNS and stateless lambda functions.
Reliability and resilience is not a reason for abandoning modern distributed computing in favor of web3 consensus-driven transactions.
This presentation uses the terms centralized and decentralized in the web3 sense, even though the terms are misleading.

15. Centralization Architectural (de)centralization
Political (de)centralization 
Logical (de)centralization
From Vitalik Butarin
Architectural (de)centralization — how many physical computers is a system made up of? How many of those computers can it tolerate breaking down at any single time?
Political (de)centralization — how many individuals or organizations ultimately control the computers that the system is made up of?
Logical (de)centralization— does the interface and data structures that the system presents and maintains look more like a single monolithic object, or an amorphous swarm? One simple heuristic is: if you cut the system in half, including both providers and users, will both halves continue to fully operate as independent units?

16. Logical Clocks
Distributed systems experience Einstein’s relativistic effects due to the limitation of the speed of light
If ML systems were enhanced to incorporate logical clocks to associate the learned state at arbitrary global timestamp values they could become deterministic.
If ML systems were enhanced to incorporate logical clocks to associate the learned state for arbitrary global timestamp values they could become deterministic.
Matrix clocks seem interesting

17. Security Issues Discussion later in this talk
Features/Complexity versus Security
Solidity is misnamed

18. Dogma Is Bad For Business
The degree of centralization is mostly a business decision
System integration strategies
ML systems can indirectly interact with the blockchain using json-rpc or IPC to an Ethereum client such as geth or Parity
Native apps can combine ML with blockchain
Solidity is suboptimal
Dispensing with dogma, let’s be practical. Smart contracts do not:
- require Solidity, and I claim that Solidity is not a good language.
- require decentralization, even though this might be desirable for some use cases.
- need to run onchain, even though this might be desirable for some use cases.

19. Issues With Solidity: Primitive type system.
Compiler bugs (more surely exist).
Few software tools available.
Expensive to work with
Hard to hire for
Low productivity
High risk
Very expensive to maintain.
Shelf life for this technology will be short.
Solidity is the most commonly used smart contract language today.

20. Avoid Solidity If Possible
Write the smart contract in the language of your choice, and use json-rpc calls as desired.
Resulting code will be well understood by all.
Audits will be more reliable.
Costs will be much less using a common language instead of Solidity.
Talent will be much easier to find.
Audits will be more reliable because of better software tools for your language than Solidity, which has very little support.
Talent will be much easier to find – makes sense to take a quick course on how to work with the language support library such as web3.js, web3j, or web3j-scala.

21. Ethereum Is Not Symmetric
Onchain smart contracts are distributed and use consensus
Offchain smart contracts (using Ethereum clients) are currently centralized and so do not use consensus
This will likely evolve over the next several years

22. ChainLink (1/2)
Wraps existing singleton services and presents them as a decentralized oracles
Run by a for-profit organization
See smartcontract.com

23. ChainLink (2/2) Does not address the motivations for decentralization:
Fault tolerance – single point of failure
Attack resistance
Collusion resistance
Wrapping a singleton and presenting it in a decentralized manner does not make the singleton decentralized

24. Transpiling
Process of converting a program written in one language into another language.
Solidity could be transpiled to json-rpc calls from node.js and JVM languages (Java, Scala, JRuby, Jython, Groovy, etc).
… but don’t bother because you endure all the problems with Solidity and get none of the benefits of native contracts
I introduce the term transpiling now because it will be used in the remainder of the presentation.

25. Use Cases With Architecture Diagrams
The first 3 use cases will show different ways that ML can be employed with decentralized applications.
The 4th use case will show more than one usage of ML in a decentralized application.
The last use case will show a global enterprise system, featuring a federated architecture (distributed yet ‘centralized’, according to the web3 definition of that word), which uses json-rpc to connect off-chain processes, including ML, with the blockchain.

26. Self-Optimizing Contracts
Optimize transactions for greatest margin, minimal waste, constant deal flow, or other criteria
Results would improve over time
This is an onchain example
Improvement would be a result of learning

27. Evolutionary programming Simulated annealing Gaussian adaptation
Genetic algorithms
Evolution strategies
Evolutionary programming
Simulated annealing
Gaussian adaptation
Hill climbing
Swarm intelligence
Integer linear programming
In this diagram the dispatcher is a smart contract that routes incoming events to the appropriate smart contract for the desired type of optimization.
The oracles accessed by the various optimizer contracts utilize some form of machine learning to perform the optimization.
I will discuss determinism for ML shortly.
There are many types of machine learning, however for optimization tasks the following are often used:
Genetic algorithms
Evolution strategies
Evolutionary programming
Simulated annealing
Gaussian adaptation
Hill climbing
Swarm intelligence
Integer linear programming

28. Fraudulent Event Detection
Smart contracts currently act on all events
Fraud detection often employs machine learning
Incorporating ML into smart contracts could make them resistant to fraud
This is an onchain example
Credit card companies, for example, make heavy use of ML for fraud detection.

29. The diagram shows an onchain smart contract used as a filter, or gateway, that employs an oracle that uses machine learning to detect fraudulent events.
The target smart contract does not necessarily need to employ machine learning for this architecture to have merit.
False negatives are fraud that is not identified or prevented by the fraud detection smart contract.
False positives are legitimate events that are inadvertently blocked by the fraud detection smart contract.
It is not possible to optimize for both minimal false negatives and minimal false positives.
The decision of what to optimize for is a business decision, not a technical decision.
If a business’s margins are small, the system should allow some legitimate events to be misclassified as fraud.
If margins are large, the reverse is true and some fraud would be tolerable.
There are two general types of machine learning techniques used for fraud detection: statistical classification and regression analysis.
Many types of statistical classification exist, including logistic regression, decision trees, and random forests.
Two popular types of regression analysis are linear regression and regression trees.

30. Automated Customer Service Agents
Chatbots and voice interfaces (Alexa)
Much more natural to use
Can be built into devices
This is an onchain example
Chatbots and voice interfaces are becoming popular for customer service, and I expect that it will become common to integrate them with smart contracts to sell goods and services.

31. Geth Parity
etc
Chatbots and voice interfaces (such as Alexa) that use machine learning might be employed to provide a user interface, while the smart
contract might reference oracles powered by machine learning to offer individualized sales and service.
Here we see that the machine learning is deployed in the user interfaces (chatbot and voice). The UIs invoke the appropriate smart contract according to the user’s wishes.
Note that the user interfaces are not on-chain, instead they interact with the blockchain via an Ethereum client such as geth or Parity.
We’ll discuss json-rpc later in this presentation.

32. Medical Diagnosis Expert System
Smart contract mediates access to an expert system (oracle, incorporates machine learning)
Accepts anonymous patient data
Passes data to an expert system that performs analysis
Returns diagnostic results
Charges for the service
This is an offchain example

33. Geth Parity
etc
This is similar to what we saw before

34. Supply Chain
Native application (JVM, .NET, C++, whatever) uses json-rpc to interact with the blockchain
Solidity is not required
This is an offchain example
This use case shows an off-chain smart contract, written in any computer language that is convenient, likely not Solidity.

35. Supply Chain Geth Parity Node.js Java Scala Jython JRuby C C++ C# F#
etc
Node.js Java Scala Jython JRuby C C++ C# F#
IoT sensors create a lot of data.
The centralized application might be written as a Kafka Streaming application.
The image recognition service might verify the validity of the driver’s documentation, the vehicle’s status (via CAN bus).
Json-rpc could add to inventory, subtract from inventory, etc.
Smart contract could be transpiled from Solidity to JavaScript or Java with embedded json-rpc calls, but it would be better to write in the language of your choice and use an Ethereum library, or even just a json-rpc library.

36. Contracts

37. Traditional Contracts…
Outline the terms of a relationship
According to a specific jurisdiction
So that the specified government can enforce the terms
A traditional contract outlines the terms of a relationship, according a specific jurisdiction so that the specified government can enforce the terms according to the government’s legal code.

38. Smart Contracts…
Enable rule-based autonomous actions in response to events.
Work within and between organizations and the rest of society, world-wide.

39. Smart Contracts Threaten Tradition
Enforce a relationship with cryptographic code
Without regard to the jurisdiction of any government
Smart contracts accept information input to them in some fashion, assigning value to the input through the rules set out in the contract, and executing the actions required by those contractual clauses.
For example, a contract might determine whether an asset should be transferred to a party to the contract or be returned to the person from whom the asset originated.

40. Smart Contracts … Also known as cryptocontracts Are computer programs
Directly control the transfer of blockchain-based digital currencies or assets
Define the rules and penalties for an agreement
Might automatically enforce those obligations
According to current web3 dogma, smart contracts have no need for central, controlling brokers such as fiduciaries or banks.
In fact, no human supervision of smart contracts is needed.
Many other hybrid schemes are also being experimented with.
Side chains, secondary chains and state channels are often used by hybrid technologies.

41. System Integration
Collecting inputs and outputs to smart contracts requires system integration.
Approaches vary according to input sources, output destinations, volumes of data, required reliability, fairness (near-constant latency), etc.
Beware of introducing single points of failure
For some applications the inputs and outputs arise from a single source; other types of applications must contend with inputs and outputs that span multiple network nodes.

42. Smart Contract Capabilities
Manage relationship between parties by:
Maintaining virtual ledgers
Reading/writing arbitrary on-chain data
Reading/writing off-chain data
Forwarding events to other contracts
Acting as a software library
Manage a relationship between people (for example, pay someone if they somehow fulfill an agreement)
Maintaining virtual ledgers (bookkeeping, stored on-chain)
Reading/writing on-chain data (key/value store, e.g. pure, view keywords - also see this)
Reading/writing off-chain permanent data storage (optional generalized state. Large data storage is expensive on blockchain. An application may rely on a server (oracle) for storing large amounts of data, while only a hash is stored on-chain for verification.)
Forwarding events to other contracts (acting as a dispatcher)
Act as a software library (contracts can use some or all of the functionality provided by other contracts)

43. Smart Contract Requirements
Observability
Verifiability
Privity
Enforceability
Nick Szabo philosophically defined a smart contract as a digital agreement with the following (I have paraphrased his words):
Observability – the ability of the participants to observe each others' performance of the contract, or to prove their performance to other participants.
Verifiability – the ability to prove that a contract has been performed or breached. Observability and verifiability might include the ability to differentiate between intentional violations of the contract and good faith errors.
Privity – The common law principle of contract privity states that uninvolved third parties should have no say in the enforcement of a contract. In other words, information about a contract is only available on a “need to know basis“. Knowledge and control over the contents and performance of a contract should be distributed among parties only as much as is necessary for the performance of that contract. In order to accomplish this, some data on the public blockchain pertaining to a specific contract might be encrypted.
Enforceability – The ability to automatically enforce the terms of the contract.

44. Oracles
Smart contracts need oracles to resolve details that cannot be precisely known at the time the contract is written.
Oracles provide reference information for smart contracts.
An oracle is usually a (singleton) REST API connected to a data source.
Using oracles generally decreases security
Oracles provide reference information for smart contracts.
At its most abstract, an oracle is a REST API connected to a data source.
The data might change over time, for example, an oracle might provide the temperature at a certain location at a certain time.
Doug von Kohorn explains why oracles will be so important to Ethereum infrastructure in 2018: "Smart contracts need oracles to resolve details that cannot be precisely known at the time the contract is written."
Using oracles decreases security, unless special provisions are made to mitigate that issue.
For example, physical security can be used on a secure channel to ensure that data has not been tampered with, and that the data source continues to supply data.

45. Smart Contract Platforms
Bitcoin
Cardano (eventually)
DFinity
EOSIO
Ethereum
Hyperledger
Lisk
Pact on Kadena
NEO
Quorum
Qtum
RSK
Stratis
Wanchain
Bitcoin – provides a limited scripting language for basic smart contracts. Can implement multisignature accounts, payment channels, escrows, time locks, atomic cross-chain trading, oracles, and multi-party lottery with no operator.
Cardano – written in Haskell, Cardano does not yet have a working smart contract layer, however it is being built to improve upon Ethereum.
DFinity – an Ethereum work-alike that prioritizes performance and scalability and where smart contracts are subject to a decentralized intelligence, which can override smart contracts according to a complex mechanism. DFinity claims their Blockchain Nervous System (or "BNS") offers decentralized governance by leveraging distributed AI. DFinity smart contracts are not compatible with Ethereum smart contracts. I am not convinced that ewasm (their webassembly dialect) is a suitable language for smart contracts, but we’ll see what Dfinity looks like when released.
EOSIO – a new blockchain architecture for scalable decentralized apps.
Ethereum – the primary blockchain platform that supports smart contracts today. Provides the Ethereum Virtual Machine (EVM) that is the basis for its smart contract capability. Ethereum is unable to automate cross-organization supply-chain logistics, and lacks privacy protocols for internal and external private contracts. Smart contracts for Distributed Applications (ĐApps) run in the EVM on the main chain so any error should just waste transaction fees (Ethereum “gas”), and problems are restricted to the specific EVM instance that the contract executed on. Gas adds lots of complexity and security issues and was a poor design decision.
Hyperledger – permissioned blockchain infrastructure, executes chaincode (native language contracts).
Lisk – apps are deployed on their own sidechains, which are linked to the main Lisk network. Lisk was forked from Crypti (defunct) in Lisk is written in node.js, which is not very efficient or secure. Smart contracts (known as Lisk Blockchain Applications) are written in JavaScript. If a Lisk application has problem it will be contained to only the sidechain that it resides on, but fixing the problem will require a hard fork.
Kadena – Not Ethereum-compatible. Runs the Pact smart contract language. Supports checkpointing of the smart contract database, which enables efficient replay and startup (this is reminiscent of event sourcing). Developed by some of the same people at JP Morgan who had earlier worked on Hyperledger.
NEO – newer than Ethereum. The NEO Universal Lightweight Virtual Machine (ULVM) supports high levels of concurrency, scalability, and determinism. NEO’s smart contract system, NeoContract, can process over 10,000 transactions per second, compared to Ethereum’s modest 7-15 transactions per second. Instead of Solidity, all the .NET (C#, F#, VB.NET, etc.) and JVM languages (Java, Scala, Kotlin, Jython, JRuby, etc.) are supported, plus Python. Support for C, C++, Golang and JavaScript is planned.
Quorum – Ethereum fork with permissions, from JPMorgan, for enterprises.
Qtum (pronounced quantum) – mixes the Bitcoin blockchain with the Ethereum Virtual Machine. Qtum is intended to be used as public blockchain for business environments. It was designed with certain industries in mind, including mobile telecommunications, finance, industrial logistics, manufacturing, and counterfeit protection.
RSK – is a parallel process that connects to the Bitcoin blockchain through a sidechain. RSK is compatible with onchain smart contracts created for Ethereum.
Stratis – Supports decentralized smart contracts written using the Microsoft .NET framework. Smart contracts run on sidechains, so the Stratis main chain experiences less load and is more secure.
Wanchain – a fork of Ethereum with privacy protection. Private and public smart contracts, cross-chain interoperability. WANLab provides financial support for select projects, similar to how Y Combinator works.

46. Ethereum Virtual Machine (EVM)
Deterministic.
Each Ethereum node has an EVM instance.
EVM has a similar execution model to both the Java and the .NET virtual machines.
All these VMs are stack machines executing bytecode.
EVM adds storage and its bytecode is somewhat more suited for contracts.
Each Ethereum node in the network includes a unique EVM instance, and each instance merely needs to implement the EVM specification.
Implementations have been written in Clojure, C++, Go, Haskell, Java, JavaScript, Python, Rust, and Ruby.
EVM has a similar execution model to both the Java and the .NET virtual machines.
All these VMs are stack machines executing bytecode.
EVM adds a concept of storage and its bytecode instructions are more suited for smart contract development.
BTW, none of these (neither JVM, .NET or EVM) are actually virtualized in the way that cgroups work for Linux-based operating system-level virtual machines. It would be more accurate to rename EVM to “Ethereum Smart Contract Processor”

47. Interesting Smart Contract Languages
All compile to EVM byte code except Chaincode
AxLang
Chaincode (Hyperledger)
LLL
Pact (Kadena)
Solidity
AxLang – Details in a few slides.
Chaincode – Hyperledger smart contract, can be written in any programming language.
LLL – Low-level, LISP-Like Language for Ethereum.
Pact – Details in a few slides.
Serpent – (not shown) A low-level language that compiles to EVM code. Syntax is somewhat similar to Python. Few contracts are written in Serpent, and this language is not recommended for most use cases because of compiler bugs that seem unlikely to be fixed.

48. Solidity
Solidity is currently the most popular language to write smart contracts in.
Difficult to recognize or prevent serious programming errors.

49. Solidity Solidity contracts are difficult to secure.
Formal verification could help.
Most Solidity contracts ignore security recommendations.
Solidity’s support for types is rather primitive.
Solidity Supports inline assembly, which is unfortunately necessary for some use cases.
The majority of Solidity contracts written to date ignore best-practice recommendations for security (see the Ethereum documentation, and an independent guide from UMD). Unfortunately, even the Solidity examples in the official documentation do not teach best practices.

50. Solidity and Security
Contracts written in Solidity are difficult to make secure.
Formal verification could help.
Solidity’s support for types is primitive
Solidity’s support for types is rather primitive, when compared to languages that have strong type systems, such as Scala.
For example, Solidity does not provide any way to distinguish between an address of a private key and an address of a wallet.
The Solidity compiler does not provide any help for preventing a common class of bugs.

51. Better On-Chain Language Support
Both of the following languages and platforms are really interesting to me.
I have no relationship with the companies behind this technology.
I expect many more will appear.

52. AxLang
Newest, cross-compiled Scala DSL, designed to scale, not yet ready.

53. AxLang
Smart contract language designed to support formal verification.
Cross-compiled Scala DSL for Ethereum
Designed to scale
Not yet ready
AxLang is not yet ready, expected before 2018 year end.
Newest, cross-compiled Scala DSL for Ethereum, designed to scale and support formal verification.
Built using Scala.
Scala is an existing and proven programming language, with a large user base, a highly developed tools ecosystem, including formal verification tools, and is widely deployed within the financial services industry.
Scala is often used to create strongly typed Domain-Specific Languages (DSLs).

54. Pact / Kadena Functional, interpreted Lisp-like syntax
Features type inference
Similar to database stored procedures in an online transaction processing (OLTP) system
Not Turing complete
Runs on the Kadena blockchain
Pact – Functional, interpreted Lisp-like syntax, with a REPL, runs on the Kadena blockchain, features type inference.
Has a strong database influence, rather like database stored procedures in an online transaction processing (OLTP) system.
Deliberately not Turing complete, which is a security feature, and as a result Ethereum’s concept of gas is not required.
The concept of gas is unfortunate, adds a lot of complexity and reduces security.
Pact is designed to allow direct integration with an industrial RDBMS for efficient publication of historical data.

55. json-rpc (Off-Chain apps)
Let’s change topics slightly

56. json-rpc Popular communications protocol
Communicates between off-chain applications and their Ethereum clients
Next we will discuss a few libraries for a popular communications protocol for communicating from off-chain applications to Ethereum clients: json-rpc.

57. Some json-rpc Libraries
web3.js – for node.js
Can also transpile Solidity to JavaScript
web3j – for Java
Can also transpile Solidity to Java
web3j-scala – for Scala
(I wrote this one)
Idiomatic Scala wrapper around web3j
Web3.js is the most popular, because node.js/JavaScript is the most popular language/runtime library combination for Ethereum DApps.
Web3j is similar to web3.js in many ways, and is usable with most JVM languages.
I wrote web3j-scala as an idiomatic Scala wrapper around web3j.
These libraries transpile into JavaScript or Java, and use json-rpc to communicate with the blockchain via an Ethereum client.
As I mentioned earlier, I don’t recommend using a transpiler, because it:
- might be buggy
- requires a Solidity contract, which can be a problem if you cannot find good Solidity programmers
- generates programs with all of the weaknesses of Solidity but few of the strengths of the target language
- easier to write the offchain smart contract using your favorite computing language and include json-rpc calls as required

58. Learning

59. How do Computers Learn?
Trial and error with feedback
Training

60. Types of Machine Learning
Association rule
Artificial neural networks
Bayesian networks
Clustering
Decision tree
Deep
Genetic algorithms
Inductive logic programming
Classifier systems
Reinforcement
Representation
Rule-based
Similarity and metric
Sparse dictionary
Support vector machines

61. How Might Smart Contracts Learn?
“Learning” computation must occur off-chain
Enforced by the Ethereum fee structure

62. Machine Learning Applications
Automated theorem proving
Adaptive websites
Bioinformatics
Classifying DNA sequences
Detecting credit-card fraud
General game playing
Information retrieval
Internet fraud detection
Insurance
Linguistics
Medical diagnosis
Machine perception, including computer vision and object recognition
Optimization and metaheuristic
Recommendation systems
Robot locomotion (autonomy)
Sentiment analysis
Speech and handwriting recognition
Structural health monitoring
Syntactic pattern recognition
User behavior analytics
Translation
These applications are likely to be useful for blockchain applications requiring machine learning.
Culled and paraphrased from Wikipedia.

63. Caution

64. Security / Complexity Tradeoff
The only way to guarantee perfect security is to provide no features.
Adding machine learning to smart contracts creates a complex system.
Increasing complexity increases attack surface, so we trade increasing functionality for reduced security.
Security risk increases significantly as features add complexity to the overall system.

65. Security Cannot Be Retrofitted
Secure systems can only be designed that way from the start
Trying to secure an existing platform can only give marginal improvements
Need orders of magnitude of improvements to smart contract security
Not possible without a fresh start
Let’s say security was improved 10%, or 50%, or even 200%.
Marginal improvement won’t be good enough.
Orders of magnitude improvement is required.

66. Thank you!
Mike Slinn