Successfully reported this slideshow.
Your SlideShare is downloading. ×

Fullsize Smart Contracts That Learn

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
Smart Contracts That Learn
Smart Contracts That Learn
Loading in …3
×

Check these out next

1 of 66 Ad
Advertisement

More Related Content

Slideshows for you (20)

Similar to Fullsize Smart Contracts That Learn (20)

Advertisement

Recently uploaded (20)

Advertisement

Fullsize Smart Contracts That Learn

  1. 1. Smart Contracts that Learn (Extended Version) Mike Slinn June 29, 2018 IBM Ottawa
  2. 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
  3. 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. 4. In 10 Years (2028)
  5. 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, 2018 --
  6. 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
  7. 7. Espionage • In 10 years time corporate and nation/state espionage will include: o Sabotaging training data o Spoofing smart contract events o Seeding smart contract templates with security weaknesses o … and lots more …
  8. 8. Newspaper Style Key Takeaways
  9. 9. Dogma and ideology are not good for business Dial Back the Koolaid
  10. 10. 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)
  11. 11. On/Off Chain Computation Geth Parity etc
  12. 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
  13. 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. 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.
  15. 15. Centralization • Architectural (de)centralization  • Political (de)centralization  • Logical (de)centralization
  16. 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.
  17. 17. Security Issues • Discussion later in this talk o Features/Complexity versus Security o Solidity is misnamed
  18. 18. Dogma Is Bad For Business • The degree of centralization is mostly a business decision • System integration strategies o ML systems can indirectly interact with the blockchain using json-rpc or IPC to an Ethereum client such as geth or Parity o Native apps can combine ML with blockchain • Solidity is suboptimal
  19. 19. Issues With Solidity: • Primitive type system. • Compiler bugs (more surely exist). • Few software tools available. • Expensive to work with o Hard to hire for o Low productivity o High risk • Very expensive to maintain. • Shelf life for this technology will be short.
  20. 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.
  21. 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. 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. 23. ChainLink (2/2) • Does not address the motivations for decentralization: o Fault tolerance – single point of failure o Attack resistance o Collusion resistance • Wrapping a singleton and presenting it in a decentralized manner does not make the singleton decentralized
  24. 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
  25. 25. Use Cases With Architecture Diagrams
  26. 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
  27. 27. Genetic algorithms Evolution strategies Evolutionary programming Simulated annealing Gaussian adaptation Hill climbing Swarm intelligence Integer linear programming
  28. 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
  29. 29. Automated Customer Service Agents • Chatbots and voice interfaces (Alexa) • Much more natural to use • Can be built into devices • This is an onchain example
  30. 30. Geth Parity etc
  31. 31. 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
  32. 32. Geth Parity etc
  33. 33. 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
  34. 34. Supply Chain Node.js Java Scala Jython JRuby C C++ C# F# Geth Parity etc
  35. 35. Contracts
  36. 36. Traditional Contracts… • Outline the terms of a relationship • According to a specific jurisdiction • So that the specified government can enforce the terms
  37. 37. Smart Contracts… • Enable rule-based autonomous actions in response to events. • Work within and between organizations and the rest of society, world-wide.
  38. 38. Smart Contracts Threaten Tradition • Enforce a relationship with cryptographic code • Without regard to the jurisdiction of any government
  39. 39. 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
  40. 40. 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
  41. 41. 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
  42. 42. Smart Contract Requirements • Observability • Verifiability • Privity • Enforceability
  43. 43. 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
  44. 44. Smart Contract Platforms • Bitcoin • Cardano (eventually) • DFinity • EOSIO • Ethereum • Hyperledger • Lisk • Pact on Kadena • NEO • Quorum • Qtum • RSK • Stratis • Wanchain
  45. 45. 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.
  46. 46. Interesting Smart Contract Languages All compile to EVM byte code except Chaincode • AxLang • Chaincode (Hyperledger) • LLL • Pact (Kadena) • Solidity
  47. 47. Solidity
  48. 48. 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.
  49. 49. Solidity and Security • Contracts written in Solidity are difficult to make secure. o Formal verification could help. • Solidity’s support for types is primitive
  50. 50. Better On-Chain Language Support
  51. 51. AxLang
  52. 52. AxLang • Smart contract language designed to support formal verification. • Cross-compiled Scala DSL for Ethereum • Designed to scale • Not yet ready
  53. 53. 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
  54. 54. json-rpc (Off-Chain apps)
  55. 55. json-rpc • Popular communications protocol • Communicates between off-chain applications and their Ethereum clients
  56. 56. Some json-rpc Libraries • web3.js – for node.js o Can also transpile Solidity to JavaScript • web3j – for Java • Can also transpile Solidity to Java • web3j-scala – for Scala o (I wrote this one) o Idiomatic Scala wrapper around web3j
  57. 57. Learning
  58. 58. How do Computers Learn? • Trial and error with feedback • Training
  59. 59. Types of Machine Learning Classifier systems Reinforcement Representation Rule-based Similarity and metric Sparse dictionary Support vector machines Association rule Artificial neural networks Bayesian networks Clustering Decision tree Deep Genetic algorithms Inductive logic programming
  60. 60. How Might Smart Contracts Learn? • “Learning” computation must occur off-chain • Enforced by the Ethereum fee structure
  61. 61. Machine Learning Applications 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 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
  62. 62. Caution
  63. 63. Security / Complexity Tradeoff
  64. 64. Security Cannot Be Retrofitted • Secure systems can only be designed that way from the start o Trying to secure an existing platform can only give marginal improvements • Need orders of magnitude of improvements to smart contract security o Not possible without a fresh start
  65. 65. Thank you! Mike Slinn mslinn@micronauticsresearch.com 650-678-2285

×