Blockchain in enterprise - Challenges, Considerations and Designs
•Download as PPTX, PDF•
4 likes•313 views
What are challenges you will be facing while working on an enterprise Blockchain solution ? What are possible services, solutions we can leverage to create an enterprise blockchain solution ? Here we share our experience and walk you step by step through an on-production blockchain project process.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Blockchain in enterprise - Challenges, Considerations and Designs
Similar to Blockchain in enterprise - Challenges, Considerations and Designs (20)
More from Michael Chi
Recently uploaded
Recently uploaded (20)
Blockchain in enterprise - Challenges, Considerations and Designs
- 1. Blockchain in Enterprise Challenges, Considerations and Designs Michael Chi 紀尚豪 michi@microsoft.com Software Development Engineer, CSE Dev Crew
- 2. Reference • Sample Codes • https://github.com/michael-chi/blockchain-learning • https://github.com/michael-chi/ethereumsupplychain • Ethereum ARM Templates • https://github.com/EthereumEx/ethereum-arm-templates • OpenZeppelin • https://github.com/OpenZeppelin/openzeppelin-solidity
- 3. Agenda • Case Sharing • Agriculture • Certificates • Digital Wallet Case
- 4. Before we start… • We assume you have basic Blockchain knowledge • What is Blockchain • What is distributed ledger • What is smart contract • We assume you have hands-on experience on Blockchain • Or have programming knowledge • Azure Knowledge (is a plus) • This is a technical sharing session
- 5. Before we start… • Some of the technical designs had changed due to scope/requirements change • But the idea is to share considerations and designs
- 6. Blockchain Sales Enablement November December 27 28 29 30 1 4 5 6 7 8 11 12 13 14 15 18 19 20 21 22 DeliverablesPMO Key: Challenge • The customer has a systematic agriculture solution which manages farmer and their lands, they also provides trainings for their farmers. Identity is a critical topic when managing so many different famers from different country in different regions. Strategy • The customer wants to use IoT technology and Blockchain technology to create a digital identity management solution to manage their farmers as well as to better understand their performance, land status…etc Project • Microsoft is to work with customer’s development team to create an IoT solution which sends telemetry to a blockchain backed backend that records land status. • An Identity solution is also to be developed to recognize each farmers and their learning status, previous performance…etc
- 8. Challenge • Customer offers maritime companies a vibrant marketplace and a conducive operating environment to conduct business. Certain certification process at this moment runs manually which spend a lot of human resource and time to track and share between the ship owner, shipyard, customer and other parties. Strategy • Customer chooses blockchain for its transparency and shared data. With smart-contract and blockchain technology they are looking to reduce certificate round-trip as well as time spent. Results • Partnered with Microsoft, Customer and Microsoft have developed 1st proof of concept application which recognized by Customer, Shipowner and Shipyards that can hugely reduce round-trip and time processing certificates
- 9. SHARED LEDGER CONSENSUS Builder Certificate Update trusted participants Shipowner Shipyard CONSENSUS Shipowner Shipyard Vessel Smart contract 0x8ea31de93f0714004cc1bb6bd46317f939aa0c44 Builder Smart contract 0xe0b1fc9e04593d7800f1b62bd9f68fad153ff347 Builder Certificate Builder Certificate Signed
- 10. • More participants, more value • On-chain data is public to participants Baseline
- 12. 12 How we work with the customer • Business Discussion to clarify scenario and business value • Around 3 weeks • Prototyping • 2 on-site Coding sessions • Around 2 month remote works • Customer and their partners continue to work on this project • Code-Reviews, Product Team discussion…etc
- 13. Scenario
- 14. Problems We need… • A Standard “Currency” and Exchange mechanism to trade goods • A Standard Platform that shares information among different companies • Has to be secure • Globally Distributed • Easy for partners to participate
- 15. A cryptographically secure, shared, distributed ledger Secure Each transaction recorded in the database is digitally signed and mathematically guaranteed to be authentic and impervious to fraud. Shared The database’s main value is that it is shared between separate entities More entities shared, the greater the value. Distributed Many copies of the database exist and they are replicas of each other in relative time. Ledger A write once, thus immutable, ledger that records every transaction. The entire history of all transactions is available, math doesn’t lie and there is no where to hide. Blockchain | Advantages
- 16. Questions How do we… • “Foreign currency Exchange” for different participates ? • Track Transaction ? • Integrated with existing membership system or other backend systems ? • Interact with other participates ? • Create a secure, reliable, globally distributed system ? • Create a Digital “Token”? With Ethereum ? Hyperledger ?
- 17. Questions How do we… • Manage changes ? • Manage user information ? ……and MORE questions… • Communicate with partners in different region ?
- 18. Start Small, Think Big 18
- 19. • Architect a solution for single partner • Expend the solution from there… • Solve one very basic problem first
- 20. 20 Create a Digital Token Exchange Rate Transaction History Participants Management
- 21. 21 Create a Digital Token Address Address Address AddressSmart Contract Token Contract Exchange Rate Contract Transaction Contract
- 22. 22 Create a Digital Token • A Token is nothing but a smart contract • There’re several Token protocol out there • Different Blockchain has different implementation Token Contract
- 23. 23 Create a Digital Token • Start from Ethereum • Uses ERC 20 Standard • https://theethereum.wiki/w/index.php/ERC20_Token_Sta ndard We decide to…
- 24. 24 Create a Digital Token ERC20 Interface methods • totalSupply • balanceOf • Transfer • transferFrom • Approve • allowance
- 25. 25 Create a Digital Token ERC20 Interface events • Transfer • Approval
- 26. 26 Create a Digital Token ERC20 • OpenZeppelin • https://github.com/OpenZeppelin/openzeppelin-solidity/tree/master/contracts • Sample • https://github.com/OpenZeppelin/openzeppelin- solidity/blob/master/contracts/token/ERC20/ERC20.sol
- 27. 27 Create a Digital Token Exchange Rate Contract • Manage Exchange Rate Proposal of each Merchant/Participant • Merchant to Approve or Reject Proposed Rate • List All Exchange Rates for All Merchants • Buy/Sell Rate
- 28. 28 Create a Digital Token Exchange Rate Contract Methods • proposeSellRate • proposeBuyRate • approveSellRate • approveBuyRate • rejectSellRate • rejectBuyRate • getExchangeRateForMerchant
- 29. 29 Create a Digital Token Transaction Contract • Transfer Token from Merchant to end-customers • Transfer Token from customer to Merchants • Buy/Sell Token from the system • Get Token Balance of a participant
- 30. 30 Create a Digital Token Merchant Contract Methods • transferToken • getBalanceOf • buyToken • sellToken
- 31. 31 Create a Digital Token Merchant Contract Events • tokenTransferred • buyToken • sellToken
- 32. 32 Create a Digital Token TokenTransaction Exchange Rate
- 33. Questions • What if we need to update smart contracts • How to migrate data from existing contracts to new contracts Now we have smart contracts ready… • How can different versions work together
- 34. Proxy Pattern Now we have smart contracts ready… Proxy Contract Business Contract v1 Data Contract Business Contract v2
- 35. Questions • How to programmatically interact with them ? • How to Expose These API to consumer Applications ? • How to restrict access to these APIs ? Now we have smart contracts ready…
- 36. API Layer • We need a library to interact with Smart contract from off- chain Now we have smart contracts ready… • An API Layer to wrap the library • Authentication/Authorization • In Smart Contract • In API Layer
- 38. 38 Interact with Smart Contracts Truffle • truffle.js
- 39. 39 Interact with Smart Contracts Truffle • truffle init • truffle compile • Output: <ContractName>.json • truffle deploy
- 40. 40 Interact with Smart Contracts WEB3.JS • 1.0 (Beta) • https://web3js.readthedocs.io/en/1.0/ • ~0.14 • https://github.com/Ethereum/web3.js/ • Truffle • Development, Deployment and Testing environment for Smart contracts
- 41. 41 Interact with Smart Contracts WEB3.JS
- 42. Creating APIs • RESTful APIs • Security • Integrated with Internal Membership system • Node.JS Challenges
- 43. Creating APIs • Existing Membership service located in own IDC • Database/API based • At this stage, we mock it • VPN or not ? Membership system integration
- 44. Creating APIs • Function App • Serverless • Integrated with Vnet ( requires non Consumption plan) or ASE • Web App/API App • PaaS, Supports most programming languages • Integrated with VNet via Vnet support or ASE • Virtual Machines • IaaS, Do-it-yourself • Fully integrated with VNet RESTful APIs options on Azure
- 45. Creating APIs • API Authentication/Authorization • Azure AD Integration • Data Transportation • SSL , Custom Encryption • Data in Rest • Leverage Azure’s Data Encryption Mechanism Security considerations
- 46. Creating APIs End User/ Mobile App/ Web App Function App/Http Trigger Ethereum Network SQL Database Virtual NetworkAzure AD HTTP RPCHTTPS Firewall SQL/1433
- 47. Creating APIs • Difficult to handle Ethereum/SQL Database synchronization • What if a transaction written to database needs to rollback ? 1st Architecture, Challenges
- 48. Firewall Azure AD Virtual Network Creating APIs End User/ Mobile App/ Web App Function App/Http Trigger Ethereum Network SQL Database oracle HTTP RPCHTTPS 1433 2nd Architecture
- 49. Creating APIs • oracle does not aware of return values of a smart contract method • It is only available in caller contracts • High-Availability of oracle ? 2nd Architecture, Challenges
- 50. Creating APIs • Actual member information stored in relational database • Blockchain addresses stored in Blockchain • We need a mapping table which • Handles millions of mapping records • Secure Membership management Azure Key-Vault
- 51. How users interact with Blockchain ? Login UserId/User Info…etc Request Blockchain Key Return Blockchain Key Request Transaction
- 53. Reference Architecture Partner Application Partner Application Smart contracts
- 55. • Each Participants manage their customer’s secret in a secure storage/key-vault…etc • Blockchain nodes connected to each other in different participants environment via virtual network/VPN • Solution has to be deployed to each participant’s environment (ideally) • Reporting through SQL database/Relational Database • Auditing application directly talk to the chain Design
- 56. Technical challenges… • Transaction Time is slow comparing to existing Apps • Off-chain transaction ? • Raiden Network ? • Other options ? • Database/Blockchain transaction sync • Blockchain or Database as major data storage ? • Connectivity with other partners
- 57. CI/CD • Azure Services has built-in CI/CD support • Functions • Web App/API App
- 58. CI/CD • VSTS to create Build/Release Pipeline
- 59. CI/CD • Smart Contract CI/CD • https://medium.com/@jacobappleton/truffle-continuous-integration-with-codeship-3f79e86a03fd • https://github.com/wbuchwalter/circleci-ethereum
- 60. What’s Next ? • We want to have a easier way to deploy the whole architecture for another engagement/project • We want to have best practice, patterns ready for us to developing our own solutions • We don’t want to start from scratch every time
- 61. What’s Next ? • Azure Workbench was a project prototype • We extend it to a solution that allows you to quickly develop your own Blockchain solution • Similar architecture design as we discussed previously
- 62. Q&A
- 63. Thank you
Editor's Notes
- This session is to share what problems, challenges we were facing in this project. What technology we choose to overcome that challenge, the reason we choose and how we architect it. YOU maybe facing different scenarios that lead to different designs, we can discuss that after this session if you like. Again, the purpose of this session is to share with you the challenges and considerations we had in this blockchain project. As your scenario changes you may face different challenges
- 6
- 8
- Imaging current loyalty programs, airline has their own points Hotel has its own Shops has its own. As an end customer you need so many points/cards to really use your points
- Once we understand the scenario and requirements, we started to discuss business flow, design with customer. And we identified some problems we need to solve in this case. In a high-level view
- We know that Blockchain is the technology we need to leverage in this case, mainly because… Blockchain as a Distributed Ledger has four advantages, --click -- Security – everything in the Blockchain is encrypted with digital signing. --click -- Shared – The potential benefits of Blockchain (over conventional technology) are achieved when we use it to link organizations to share information on a distributed ledger. --click -- Ledger – Every transaction is written into the ledger once and cannot be changed after the fact. This has great advantages to the financial services industry because we have an auditable trace of every transaction. The compliance overheads for Financial Services have escalated since the financial crash and this feature of the technology has huge potential benefits for compliance teams and financial regulators. --click -- Distributed – a Blockchain can be distributed across multiple organizations and can become more secure as replicas are added.
- Let’s think about the scenario – what we have ? What we want to archive ? And how can we archive that ? We have different companies – airway, hotel…etc, each has their own membership points We want to “exchange” different points to one single common used “currency” – we probably need some kind of exchange rate Then we want to track transactions, who transfer how many token to whom at when ? We want to manage all those members in this system
- Now let’s think it in a blockchain’s way Each participates, be it companies or end-users, are addressed in Blockchain as an “Address” A Smart contract is an “Address” as well
- ERC 20 is the most popular one ERC223/ERC621/ERC721…etc. ERC stands for “ethereum request for comments” Ethereum has “Smart Contracts”, Hyperledge has Chaincode
- Start from Ethereum – Microsoft has deep relationship with Ethereum Foundation, we probably need their help. Ethereum is most popular blockchain network. ERC20 – Most popular ERC standard. Most tokens issued on Ethereum use it; ERC stands for Ethereum Request for Comment Other Standards – ERC223/ERC621/ERC721…etc
- Methods totalSupply Get the total token supply balanceOf(address _owner) constant returns (uint256 balance) Get the account balance of another account with address _owner transfer(address _to, uint256 _value) returns (bool success) Send _value amount of tokens to address _to transferFrom(address _from, address _to, uint256 _value) returns (bool success Send _value amount of tokens from address _from to address _to approve(address _spender, uint256 _value) returns (bool success) Allow _spender to withdraw from your account, multiple times, up to the _value amount. If this function is called again it overwrites the current allowance with _value allowance(address _owner, address _spender) constant returns (uint256 remaining) Returns the amount which _spender is still allowed to withdraw from _owner
- Events Transfer(address indexed _from, address indexed _to, uint256 _value). Triggered when tokens are transferred. Approval(address indexed _owner, address indexed _spender, uint256 _value Triggered whenever approve(address _spender, uint256 _value) is called.
- OpenZeppelin is a battle-tested framework of reusable smart contracts for Ethereum and other EVM blockchain OPEN “OpenZeppelin” GitHub to show the audience sample codes - Looks like writing a token is not a big problem for us
- Now let’s talk about Exchange Rate Think it as a real-world exchange rate We want participants to be able to buy and sell tokens to another participant We want participants can negotiate exchange rates, approve proposed rate or reject it
- Transaction Contract should be the programing interface client application used to interact with our Token – so every transaction can be tracked easily
- Now we have 3 contracts, we have clear definition on these contracts. Let’s put these things together to see how it should work together So we implemented 3 contrats. User exchange points to token User transfer token to company to buy stuff
- Business changes often, smart contracts changes. If something changes in the business logic in smart contracts. What should we do ? A transaction cannot be modified once written into Blockchain If new smart contract deployed, it is totally new. Every thing that was in old contract has to be somehow referenced by the new one
- Create a business contract that does business logic validation…etc Store data in another smart contract (The data contract) Create another “Proxy” contract that holds references to business logic contract & data contract and expose certain methods for consumer to interact with it Consumer applications interact with Proxy contract instead of data & business contract
- Next questions are Now we have our codes deployed to blockchain, who can we interact with them ? We need some kind of APIs so that client applications are able to work with them Also, we need restrict access to blockchain
- The answer to those questions are…
- You create a function modifier to check if certain conditions are met. And allow access accordingly
- Now we have our smart cotnracts. We use truffle to test and deploy our smart cotnracts.
- NOTE: Walk Through the codes quickly – how to interact with a contract
- Now we have tools to develop a smart contract, we can test it and we can deploy it to Blockchain. Next step is to wrap these into a REST API
- Let’s start from membership system, which we will need it in the first step
- Our first architecture was above. End user choose to opt-in the program, the mobile app invokes API exposed, in the API we use web3.js to invoke Ethereum to interact with samrtcontracts. The API also in charges of writing transaction logs and other required information into a SQL databse
- SQL: transaction logs/amount balance/merchant or end-user information/exchange rates…etc Challenge If I need to check balance before process the transaction, should I check SQL first ? Or Ethereum first ? What if SQL database rollback transaction ?
- In our 2nd design, we decide to introduce oracle. Anything gets written into Ethereum will notify oracle. Oracle will then write data to SQL database. In this way, Ethereum is the major data storage and where logic happens. Everything should rely on Ethereum. SQL database is just a transaction log store.
- Smart contract may throw exception if there’re exceptions. We need to parse the result json to identify error Oracle does not aware of function return values. If a function returns false. It does not aware of that. We need to well organize our codes to trigger failure event & success event in order to have oracle properly logs into SQL database What about HA of oracle ? If we run two oracle instance, events will be captured twice. How do we handle this ?
- Azure Key Vault is a service that provides HSM to encrypt your secret in the cloud. In this case, we created an Azure Key-Vault and stores address/private Key mapping in Key-Vault
- Message flow of this archtiecture
- Physical deployment diagram
- To be honest, we do not have a “one-for-all” answer for above questions. And the answers to these questions really depends on your scenario. For transaction time, we eventually use POA and changed gas limit…etc to reduce it to 2~3 seconds, but is it fast enough for you ?