From ca679bf0ff71acc1a45b134c0e003f7b45040607 Mon Sep 17 00:00:00 2001 From: radhuslanteg Date: Tue, 9 Jan 2018 22:02:57 +0100 Subject: [PATCH 01/28] first version of readme --- README.md | 94 ++++++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 73 insertions(+), 21 deletions(-) diff --git a/README.md b/README.md index 0b0e6dc..e954264 100644 --- a/README.md +++ b/README.md @@ -1,28 +1,80 @@ -# iExec dapp samples -## 1 branch = 1 dapp -Each branch of this repo is a sample iExec dapp, and can be easily played with by using the [iexec sdk cli](https://github.com/iExecBlockchainComputing/iexec-sdk) like this: -```iexec init branchName``` +##Abstract +This distributed app enables the on-chain usage of date computations in Smart Contracts, +by providing access to an off-chain date API; its functionality includes addition of dates and time zone +conversion, being correct even w.r.t. nasty details such as leap seconds. -```bash -iexec init # current branch containing minimum working config -iexec init factorial # download and init factorial dapp -iexec init echo # download and init echo dapp -``` +##Idea proposal -Start a [Pull Request](https://github.com/iExecBlockchainComputing/iexec-dapp-samples/pulls) to add you dapp to this repo. +Every author of a smart contract faces this problem: +Calculation of dates and times get quite involved/involved if correctness is required/crucial. +As no correct and efficient Library for that exists in Solidity, any author of smart contracts has +to implement these functions themselves and have them executed on chain. +This has two big disadvantages: +* time computations are involved and hard to implement correctly. (citation! to some hidden bug) +* time/date computations are complicated and especially time/gas intensive + +By pulling these computations off chain one can trust/delegate these problems to an API that is +designed to be correct and executed in a distributed and cost efficient framework. +This enables authors of smart contracts to base their work on a correct foundation of API functionality. + + +As future developments of usage of smart contracts can hardly be estimated let alone foreseen/forcasted, +it is hard to rate the usefullness of these specific API functionality, nevertheless we came up with +this one (speculative) use case where involved date computations are crucial or at least beneficial: + +Imagine a speed up of the time difference of two consecutive Ethereum blocks to under 1 second, also +imagine that micro trading gets a use case for Etherium, then things like leap seconds may result in +problematic behaviour of smart contracts. +Using correct API functionality for time and date computations lay the foundations of correct and +safe smart contracts that involve timed actions. + +##Roadmap + + * Design of a simple use case Smart Contract + + * Analysis of competitors (pricing) + + * Design Choice: which existing Library to use (Linux date library? is there some Haskell library? ...) + + * Design of API functionality and priceing (version 0.1) + --> how can an author of a SC react if pricing changes suddenly? + --> can we change the price of an API call freely? + --> are the prices demanded by IExcec stable or volatile? in which currency? + --> + + * Development of the DApp w.r.t. the aforementioned Design + + * Deployment of API as version 0.1 + + * Process Mining and Platform for Feedback and Feature Requests (in order to monitor usage behaviour) + +##Component diagram + + + + + +##Sequential diagram of the solution + +1. User Smart Contract (calling SC) calls our Wrapper Smart Contract by ForeignFunctionCall + +2. Our Wrapper Smart Contract takes care of spawning off an off-chain date API call, by calling the IExcec submit function via the IExcec API +[advantage of this approach: the author of the calling SC does not have to invest the time to learn the IExcec API] + +[IExcec stuff: +3a. IExcec block (?) is included in the next Ethereum block +3b. IExcec reads the IExcec block and DApp binary, runs it in a distributed manner, verifies its legitimacy, and writes back the return value to the calling SC. +] + +4. Smart Contract uses the computation's result for the next killer App. + +It's as Easy as that! :) + +##Bonus: a dapp smart contract with truffle tests + +Done -## [iExec Dapp Challenge](https://medium.com/iex-ec/the-iexec-%C3%B0app-challenge-150k-of-grants-to-win-abf6798b31ee) - * Go checkout the [iExec Dapp Challenge](https://medium.com/iex-ec/the-iexec-%C3%B0app-challenge-150k-of-grants-to-win-abf6798b31ee) - * Go submit a request to be listed on the [iExec dapp store](https://dapps.iex.ec/) ---- -# My Dapp name -## Description -My Dapp description here... -## Dapp params -An example of a iexec.js conf -## [Examples](./examples) -A link to all iexec.js conf examples for the dapp. From 2131dcad240312d6eea604d74300fed4906058e2 Mon Sep 17 00:00:00 2001 From: radhuslanteg Date: Tue, 9 Jan 2018 22:07:52 +0100 Subject: [PATCH 02/28] first version of haskell list operations project --- README.md | 87 +++++++++++++++++++++++++++---------------------------- 1 file changed, 43 insertions(+), 44 deletions(-) diff --git a/README.md b/README.md index e954264..f452346 100644 --- a/README.md +++ b/README.md @@ -1,80 +1,79 @@ +bstract +We propose an API for off-chain execution of programs in the side-effect-free fragment of Haskell. +This enables smart contracts to delegate gas intensive computations and thus save money. -##Abstract +#Idea Proposal -This distributed app enables the on-chain usage of date computations in Smart Contracts, -by providing access to an off-chain date API; its functionality includes addition of dates and time zone -conversion, being correct even w.r.t. nasty details such as leap seconds. +For-loops are heavily used in Solidity but can be very expensive in terms of gas. +Most of such easy computations can be compactely reformulated in a functional programming language +such as Haskell (example below). +By pulling those computations off the blockchain, a lot of gas and thus money can be saved. -##Idea proposal +Example of for-loop in solidity and an equivalent functional program: -Every author of a smart contract faces this problem: -Calculation of dates and times get quite involved/involved if correctness is required/crucial. -As no correct and efficient Library for that exists in Solidity, any author of smart contracts has -to implement these functions themselves and have them executed on chain. -This has two big disadvantages: -* time computations are involved and hard to implement correctly. (citation! to some hidden bug) -* time/date computations are complicated and especially time/gas intensive +for(uint j=0;j<=betIndex;j++) { + sum = sum + bets[j]; +} -By pulling these computations off chain one can trust/delegate these problems to an API that is -designed to be correct and executed in a distributed and cost efficient framework. -This enables authors of smart contracts to base their work on a correct foundation of API functionality. +for(uint j=0;j<=betIndex;j++) { + bets[j] = bets[j]/sum; +} +> bets = [1,20,3,4,5] +> sum = fold (+) bets +> map (%b. b / sum ) bets -As future developments of usage of smart contracts can hardly be estimated let alone foreseen/forcasted, -it is hard to rate the usefullness of these specific API functionality, nevertheless we came up with -this one (speculative) use case where involved date computations are crucial or at least beneficial: +Spawning an offchain-computation on iexec could be compactely wrapped like this: -Imagine a speed up of the time difference of two consecutive Ethereum blocks to under 1 second, also -imagine that micro trading gets a use case for Etherium, then things like leap seconds may result in -problematic behaviour of smart contracts. -Using correct API functionality for time and date computations lay the foundations of correct and -safe smart contracts that involve timed actions. +iexecSubmit("bets = [1,20,3,4,5]; sum = fold (+) bets; map (%b. b / sum ) bets") -##Roadmap +For larger arrays the cost of RLC could be much lower than the cost of gas. + + +* Potentially this MapReduce can be calculated distributed +* foreign code in Haskell's side-effect-free fragment can be executed without security concerns +* - * Design of a simple use case Smart Contract - * Analysis of competitors (pricing) - * Design Choice: which existing Library to use (Linux date library? is there some Haskell library? ...) - * Design of API functionality and priceing (version 0.1) - --> how can an author of a SC react if pricing changes suddenly? - --> can we change the price of an API call freely? - --> are the prices demanded by IExcec stable or volatile? in which currency? - --> +##Roadmap + * Design of a simple use case Smart Contract + + * Design Choice: which existing Library to use (Python lambda expression? is there some Haskell library? ...) * Development of the DApp w.r.t. the aforementioned Design - * Deployment of API as version 0.1 + * Deployment of API as version 0.1 including map, reduce + + * Deployment of API as version 0.1 including sort * Process Mining and Platform for Feedback and Feature Requests (in order to monitor usage behaviour) -##Component diagram +##Component diagram +Wrapper Smart Contract +Wraps the call to the offchain-app, takes care of conversion to the correct format +Offchain-app +Input: Float Array and lambda expression as string +output: Float Array ##Sequential diagram of the solution 1. User Smart Contract (calling SC) calls our Wrapper Smart Contract by ForeignFunctionCall 2. Our Wrapper Smart Contract takes care of spawning off an off-chain date API call, by calling the IExcec submit function via the IExcec API -[advantage of this approach: the author of the calling SC does not have to invest the time to learn the IExcec API] -[IExcec stuff: -3a. IExcec block (?) is included in the next Ethereum block -3b. IExcec reads the IExcec block and DApp binary, runs it in a distributed manner, verifies its legitimacy, and writes back the return value to the calling SC. -] -4. Smart Contract uses the computation's result for the next killer App. +3b. IExcec reads the IExcec block and DApp binary, runs it i, verifies its legitimacy, and writes back the return array to the calling SC. -It's as Easy as that! :) -##Bonus: a dapp smart contract with truffle tests - -Done +4. Smart Contract uses the computation's result for the next killer App. +##Bonus: a dapp smart contract with truffle tests + From 125d8b88b6d0ab63ccb931429cbce9730dbd13d5 Mon Sep 17 00:00:00 2001 From: radhuslanteg Date: Sat, 13 Jan 2018 22:06:27 +0100 Subject: [PATCH 03/28] extend idea to more use cases --- README.md | 99 ++++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 73 insertions(+), 26 deletions(-) diff --git a/README.md b/README.md index f452346..0e1009e 100644 --- a/README.md +++ b/README.md @@ -1,77 +1,124 @@ -bstract +Abstract We propose an API for off-chain execution of programs in the side-effect-free fragment of Haskell. This enables smart contracts to delegate gas intensive computations and thus save money. #Idea Proposal -For-loops are heavily used in Solidity but can be very expensive in terms of gas. -Most of such easy computations can be compactely reformulated in a functional programming language -such as Haskell (example below). + +It would be ideal if smart contract deverlopers could just run general purpose code that is computationally intensive off-chain instead of on the blockchain. This is, however, a security risk for the people running the calculations of their personal computers. We believe that side-effect-free Haskell functions allows for a large multitude of possible programs that can be run while ensuring that there is no legal or security risk for the person selling their computational ressources. Ensuring and proofing the security of all possible programs that can be run on the servers running the offchain-computations is part of the project (TODO: write some more). + +There are many use-cases for this, we propose three of them here: + +1) Operations on numeric array + +One possible use-case for this would be performing operations on arrays. For-loops are heavily used in Solidity but can be very expensive in terms of gas. +Most of such easy computations can be compactly reformulated in Haskell (example below). By pulling those computations off the blockchain, a lot of gas and thus money can be saved. -Example of for-loop in solidity and an equivalent functional program: +Example of for-loop in solidity and an equivalent functional program, which calulates the total payout for each users, if user i has correctly betted the amount bets[i]: +Solidity: for(uint j=0;j<=betIndex;j++) { sum = sum + bets[j]; } for(uint j=0;j<=betIndex;j++) { - bets[j] = bets[j]/sum; + payout[j] = (bets[j] * totalPayout)/sum; } +Haskell: > bets = [1,20,3,4,5] -> sum = fold (+) bets -> map (%b. b / sum ) bets +> let sum = fold (+) bets +> let bets2 = map (%b. b*3000) bets +> map (%b. round b / sum ) bets2 + +Spawning an offchain-computation on iexec could be wrapped like this: + +iexecSubmit("bets = [1,20,3,4,5]; let sum = fold (+) bets;let bets2 = map (%b. b*3000) bets; map (%b. round b / sum ) bets2") + +For larger arrays the cost of RLC could be much lower than the cost of gas. Here the values of the array bets are hardcoded, but they can come from any uint array in the smart contract. + + +2) String operations +Another use-case could be string operations, eg. replace: + +iexecSubmit("replace \"O\" \"X\" ".toSlice().concat(text.toSlice())) -Spawning an offchain-computation on iexec could be compactely wrapped like this: +In this example all O are replaced by X in the solidity string text. All string operations in Haskell could be used that way. -iexecSubmit("bets = [1,20,3,4,5]; sum = fold (+) bets; map (%b. b / sum ) bets") -For larger arrays the cost of RLC could be much lower than the cost of gas. +3) Date API +A third use-case is to calculate dates exactly, taking into consideration leap seconds and time zones. For example, it would then be possible to get the exact date as a string given the unix time stamp: +iexecSubmit("formatTime defaultTimeLocale \"%c\".toSlice().concat(stringUtils.uintToBytes(now).toSlice())) -* Potentially this MapReduce can be calculated distributed -* foreign code in Haskell's side-effect-free fragment can be executed without security concerns -* +Other possible functions include estimating unix time from dates as string and adding/substracting specific time intervals to/from dates. +The example above uses https://github.com/Arachnid/solidity-stringutils and https://github.com/pipermerriam/ethereum-string-utils for string manipulation. + + +#Challenges/Problems + +These are the main challenges of the project: + +1) Getting the input data into the correct format + +To use the example iexecSubmit("bets = [1,20,3,4,5]; let sum = fold (+) bets;let bets2 = map (%b. b*3000) bets; map (%b. round b / sum ) bets2") with dynamic arrays it would first be necessary to convert an array, for example uint array uint[] bets = [1,20,3,4,5]; into the string "[1,20,3,4,5]". The returned string "[90, 1800,270,360,450]" would then have to be turned into a uint array again, which would cost gas. For complex operations our solution might still be cheaper, but it would be good to find a way around this. If the Iexec API would allow to give arrays as parameters and return arrays as parameters, this would be much simpler. The function could then be called simply as iexecSubmit(bets, "let sum = fold (+) bets;let bets2 = map (%b. b*3000) bets; map (%b. round b / sum ) bets2"). Independently of that, a wrapper function iexecArrayOperation(bets, "let sum = fold (+) bets;let bets2 = map (%b. b*3000) bets; map (%b. round b / sum ) bets2") will be made available by out wrapper smart contract that takes care of converting the parameters into the right format for the iexecSubmit function + +Additionally the wrapper function would ensure that it is not necessary to manually concatenate the strings in a complicated manner. One way to do this might be to have an iexecSubmic function with several string parameters, and $x in the last parameter is replaced by the first parameter and $y in the last parameter is replaced by the second parameter. Example function call: +iexecSubmit(text, "replace \"O\" \"X\" $x) +or +iexecSubmit(stringUtils.uintToBytes(now), "formatTime defaultTimeLocale \"%c\ $x") + +These wrapper functions will also be written by us if they are not made available at a deeper level. + +2) Ensuring that all functions are side-effect free and there is no IO operations except at the beginning and at the end. +Two extremes: Either allow only functions written by us and allow any Haskell code. TODO: Max ##Roadmap - * Design of a simple use case Smart Contract + * Implement the three mentioned use cases + + * Research how parameters could be passed and returned in the cheapest way + + * Benchmark starting at which level of complexity calling iexecSublit is cheaper then calculating everything on-chain - * Design Choice: which existing Library to use (Python lambda expression? is there some Haskell library? ...) + * Research how to ensure that all functions are side-effect free - * Development of the DApp w.r.t. the aforementioned Design + * Document the existing API so that it can be used and extended by other people - * Deployment of API as version 0.1 including map, reduce - * Deployment of API as version 0.1 including sort +Version 1.0: +* The three mentioned use-cases can be called with one string parameter from smart contracts. - * Process Mining and Platform for Feedback and Feature Requests (in order to monitor usage behaviour) +Version 2.0: +* The parameter wrapping (eg. from uint array to string) is done in a wrapper smart contract or possibly directly in the iexecSubmit function. +Version 3.0: +* Additional Haskell functions are available if they are guaranteed to be save. ##Component diagram Wrapper Smart Contract -Wraps the call to the offchain-app, takes care of conversion to the correct format +Wraps the variables and the pure code to haskell code, converts the haskell string output into the proper format. Offchain-app -Input: Float Array and lambda expression as string -output: Float Array +Input: Haskell code as string, or any solidity data types + haskell code as string +output: string ##Sequential diagram of the solution 1. User Smart Contract (calling SC) calls our Wrapper Smart Contract by ForeignFunctionCall -2. Our Wrapper Smart Contract takes care of spawning off an off-chain date API call, by calling the IExcec submit function via the IExcec API +2. Our Wrapper Smart Contract takes care of converting all required data into a string containing the haskell code and spawns an off-chain computation, by calling the IExcec submit function via the IExcec API -3b. IExcec reads the IExcec block and DApp binary, runs it i, verifies its legitimacy, and writes back the return array to the calling SC. +3. IExcec reads the block and finds out there was a call to our iexec project and the binary in the apps folder starts to run with the given parameters. After running it writes back the return string to the calling smart contract. -4. Smart Contract uses the computation's result for the next killer App. +4. The wrapper Smart Contract converts the computation's result into the required format and returns it to the User Smart Contract. ##Bonus: a dapp smart contract with truffle tests From ae48a2fb0705cc31a92b4d3494031ac98c57eecb Mon Sep 17 00:00:00 2001 From: radhuslanteg Date: Sat, 13 Jan 2018 22:14:30 +0100 Subject: [PATCH 04/28] formatting changes --- README.md | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 0e1009e..58f18fb 100644 --- a/README.md +++ b/README.md @@ -63,11 +63,32 @@ These are the main challenges of the project: 1) Getting the input data into the correct format -To use the example iexecSubmit("bets = [1,20,3,4,5]; let sum = fold (+) bets;let bets2 = map (%b. b*3000) bets; map (%b. round b / sum ) bets2") with dynamic arrays it would first be necessary to convert an array, for example uint array uint[] bets = [1,20,3,4,5]; into the string "[1,20,3,4,5]". The returned string "[90, 1800,270,360,450]" would then have to be turned into a uint array again, which would cost gas. For complex operations our solution might still be cheaper, but it would be good to find a way around this. If the Iexec API would allow to give arrays as parameters and return arrays as parameters, this would be much simpler. The function could then be called simply as iexecSubmit(bets, "let sum = fold (+) bets;let bets2 = map (%b. b*3000) bets; map (%b. round b / sum ) bets2"). Independently of that, a wrapper function iexecArrayOperation(bets, "let sum = fold (+) bets;let bets2 = map (%b. b*3000) bets; map (%b. round b / sum ) bets2") will be made available by out wrapper smart contract that takes care of converting the parameters into the right format for the iexecSubmit function +To use the example + +iexecSubmit("bets = [1,20,3,4,5]; let sum = fold (+) bets;let bets2 = map (%b. b*3000) bets; map (%b. round b / sum ) bets2") + +with dynamic arrays it would first be necessary to convert an array, for example uint array + +uint[] bets = [1,20,3,4,5]; + +into the string "[1,20,3,4,5]". The returned string "[90, 1800,270,360,450]" would then have to be turned into a uint array again, which would cost gas. +For complex operations our solution might still be cheaper, but it would be good to find a way around this. If the Iexec API would allow to give arrays as parameters and return arrays as parameters, this would be much simpler. +The function could then be called simply as + +iexecSubmit(bets, "let sum = fold (+) bets;let bets2 = map (%b. b*3000) bets; map (%b. round b / sum ) bets2"). + +Independently of that, a wrapper function + +iexecArrayOperation(bets, "let sum = fold (+) bets;let bets2 = map (%b. b*3000) bets; map (%b. round b / sum ) bets2") + + will be made available by out wrapper smart contract that takes care of converting the parameters into the right format for the iexecSubmit function Additionally the wrapper function would ensure that it is not necessary to manually concatenate the strings in a complicated manner. One way to do this might be to have an iexecSubmic function with several string parameters, and $x in the last parameter is replaced by the first parameter and $y in the last parameter is replaced by the second parameter. Example function call: + iexecSubmit(text, "replace \"O\" \"X\" $x) + or + iexecSubmit(stringUtils.uintToBytes(now), "formatTime defaultTimeLocale \"%c\ $x") These wrapper functions will also be written by us if they are not made available at a deeper level. From e9d331ee5a6b4548296879ae0cbb8c99e311eacf Mon Sep 17 00:00:00 2001 From: radhuslanteg Date: Sat, 13 Jan 2018 22:16:30 +0100 Subject: [PATCH 05/28] formatting --- README.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index 58f18fb..421462b 100644 --- a/README.md +++ b/README.md @@ -28,8 +28,11 @@ for(uint j=0;j<=betIndex;j++) { Haskell: > bets = [1,20,3,4,5] + > let sum = fold (+) bets + > let bets2 = map (%b. b*3000) bets + > map (%b. round b / sum ) bets2 Spawning an offchain-computation on iexec could be wrapped like this: @@ -67,11 +70,7 @@ To use the example iexecSubmit("bets = [1,20,3,4,5]; let sum = fold (+) bets;let bets2 = map (%b. b*3000) bets; map (%b. round b / sum ) bets2") -with dynamic arrays it would first be necessary to convert an array, for example uint array - -uint[] bets = [1,20,3,4,5]; - -into the string "[1,20,3,4,5]". The returned string "[90, 1800,270,360,450]" would then have to be turned into a uint array again, which would cost gas. +with dynamic arrays it would first be necessary to convert an array, for example uint array uint[] bets = [1,20,3,4,5]; into the string "[1,20,3,4,5]". The returned string "[90, 1800,270,360,450]" would then have to be turned into a uint array again, which would cost gas. For complex operations our solution might still be cheaper, but it would be good to find a way around this. If the Iexec API would allow to give arrays as parameters and return arrays as parameters, this would be much simpler. The function could then be called simply as @@ -82,7 +81,6 @@ Independently of that, a wrapper function iexecArrayOperation(bets, "let sum = fold (+) bets;let bets2 = map (%b. b*3000) bets; map (%b. round b / sum ) bets2") will be made available by out wrapper smart contract that takes care of converting the parameters into the right format for the iexecSubmit function - Additionally the wrapper function would ensure that it is not necessary to manually concatenate the strings in a complicated manner. One way to do this might be to have an iexecSubmic function with several string parameters, and $x in the last parameter is replaced by the first parameter and $y in the last parameter is replaced by the second parameter. Example function call: iexecSubmit(text, "replace \"O\" \"X\" $x) From ab7f21eb91823168c4bdba456319c3b4eb1095b2 Mon Sep 17 00:00:00 2001 From: radhuslanteg Date: Sat, 13 Jan 2018 22:17:54 +0100 Subject: [PATCH 06/28] formatting --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 421462b..b0346c7 100644 --- a/README.md +++ b/README.md @@ -18,6 +18,7 @@ By pulling those computations off the blockchain, a lot of gas and thus money ca Example of for-loop in solidity and an equivalent functional program, which calulates the total payout for each users, if user i has correctly betted the amount bets[i]: Solidity: + for(uint j=0;j<=betIndex;j++) { sum = sum + bets[j]; } @@ -27,6 +28,7 @@ for(uint j=0;j<=betIndex;j++) { } Haskell: + > bets = [1,20,3,4,5] > let sum = fold (+) bets From cd47ff6566919ccb0c8f8eff8b7230bf8bcc85fa Mon Sep 17 00:00:00 2001 From: radhuslanteg Date: Sat, 13 Jan 2018 22:21:27 +0100 Subject: [PATCH 07/28] formatting --- README.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index b0346c7..30a8909 100644 --- a/README.md +++ b/README.md @@ -45,6 +45,8 @@ For larger arrays the cost of RLC could be much lower than the cost of gas. Here 2) String operations + + Another use-case could be string operations, eg. replace: iexecSubmit("replace \"O\" \"X\" ".toSlice().concat(text.toSlice())) @@ -53,6 +55,8 @@ In this example all O are replaced by X in the solidity string text. All string 3) Date API + + A third use-case is to calculate dates exactly, taking into consideration leap seconds and time zones. For example, it would then be possible to get the exact date as a string given the unix time stamp: iexecSubmit("formatTime defaultTimeLocale \"%c\".toSlice().concat(stringUtils.uintToBytes(now).toSlice())) @@ -64,6 +68,7 @@ The example above uses https://github.com/Arachnid/solidity-stringutils and http #Challenges/Problems + These are the main challenges of the project: 1) Getting the input data into the correct format @@ -82,7 +87,7 @@ Independently of that, a wrapper function iexecArrayOperation(bets, "let sum = fold (+) bets;let bets2 = map (%b. b*3000) bets; map (%b. round b / sum ) bets2") - will be made available by out wrapper smart contract that takes care of converting the parameters into the right format for the iexecSubmit function + will be made available by out wrapper smart contract that takes care of converting the parameters into the right format for the iexecSubmit function. Additionally the wrapper function would ensure that it is not necessary to manually concatenate the strings in a complicated manner. One way to do this might be to have an iexecSubmic function with several string parameters, and $x in the last parameter is replaced by the first parameter and $y in the last parameter is replaced by the second parameter. Example function call: iexecSubmit(text, "replace \"O\" \"X\" $x) @@ -94,6 +99,8 @@ iexecSubmit(stringUtils.uintToBytes(now), "formatTime defaultTimeLocale \"%c\ $x These wrapper functions will also be written by us if they are not made available at a deeper level. 2) Ensuring that all functions are side-effect free and there is no IO operations except at the beginning and at the end. + + Two extremes: Either allow only functions written by us and allow any Haskell code. TODO: Max From 9c47e7471aa88a071965d47b395e5025b1a691f0 Mon Sep 17 00:00:00 2001 From: radhuslanteg Date: Sat, 13 Jan 2018 22:23:23 +0100 Subject: [PATCH 08/28] formatting --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 30a8909..cd5278f 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,6 @@ Abstract + + We propose an API for off-chain execution of programs in the side-effect-free fragment of Haskell. This enables smart contracts to delegate gas intensive computations and thus save money. From 8b13793b3023892d1f4551c80d9bd03bde5e6095 Mon Sep 17 00:00:00 2001 From: radhuslanteg Date: Sat, 13 Jan 2018 22:26:51 +0100 Subject: [PATCH 09/28] formatting --- README.md | 29 +++++++++++++++++++++-------- 1 file changed, 21 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index cd5278f..0cd1656 100644 --- a/README.md +++ b/README.md @@ -7,17 +7,24 @@ This enables smart contracts to delegate gas intensive computations and thus sav #Idea Proposal -It would be ideal if smart contract deverlopers could just run general purpose code that is computationally intensive off-chain instead of on the blockchain. This is, however, a security risk for the people running the calculations of their personal computers. We believe that side-effect-free Haskell functions allows for a large multitude of possible programs that can be run while ensuring that there is no legal or security risk for the person selling their computational ressources. Ensuring and proofing the security of all possible programs that can be run on the servers running the offchain-computations is part of the project (TODO: write some more). +It would be ideal if smart contract deverlopers could just run general purpose code that is computationally intensive off-chain instead of on the blockchain. + This is, however, a security risk for the people running the calculations of their personal computers. +We believe that side-effect-free Haskell functions allows for a large multitude of possible programs that can be run while +ensuring that there is no legal or security risk for the person selling their computational ressources. + Ensuring and proofing the security of all possible programs that can be run on the servers running the offchain-computations is part of the project + (TODO: write some more). There are many use-cases for this, we propose three of them here: 1) Operations on numeric array -One possible use-case for this would be performing operations on arrays. For-loops are heavily used in Solidity but can be very expensive in terms of gas. +One possible use-case for this would be performing operations on arrays. +For-loops are heavily used in Solidity but can be very expensive in terms of gas. Most of such easy computations can be compactly reformulated in Haskell (example below). By pulling those computations off the blockchain, a lot of gas and thus money can be saved. -Example of for-loop in solidity and an equivalent functional program, which calulates the total payout for each users, if user i has correctly betted the amount bets[i]: +Example of for-loop in solidity and an equivalent functional program, which calulates +the total payout for each users, if user i has correctly betted the amount bets[i]: Solidity: @@ -43,7 +50,8 @@ Spawning an offchain-computation on iexec could be wrapped like this: iexecSubmit("bets = [1,20,3,4,5]; let sum = fold (+) bets;let bets2 = map (%b. b*3000) bets; map (%b. round b / sum ) bets2") -For larger arrays the cost of RLC could be much lower than the cost of gas. Here the values of the array bets are hardcoded, but they can come from any uint array in the smart contract. +For larger arrays the cost of RLC could be much lower than the cost of gas. +Here the values of the array bets are hardcoded, but they can come from any uint array in the smart contract. 2) String operations @@ -59,7 +67,8 @@ In this example all O are replaced by X in the solidity string text. All string 3) Date API -A third use-case is to calculate dates exactly, taking into consideration leap seconds and time zones. For example, it would then be possible to get the exact date as a string given the unix time stamp: +A third use-case is to calculate dates exactly, taking into consideration leap seconds and time zones. +For example, it would then be possible to get the exact date as a string given the unix time stamp: iexecSubmit("formatTime defaultTimeLocale \"%c\".toSlice().concat(stringUtils.uintToBytes(now).toSlice())) @@ -79,8 +88,10 @@ To use the example iexecSubmit("bets = [1,20,3,4,5]; let sum = fold (+) bets;let bets2 = map (%b. b*3000) bets; map (%b. round b / sum ) bets2") -with dynamic arrays it would first be necessary to convert an array, for example uint array uint[] bets = [1,20,3,4,5]; into the string "[1,20,3,4,5]". The returned string "[90, 1800,270,360,450]" would then have to be turned into a uint array again, which would cost gas. -For complex operations our solution might still be cheaper, but it would be good to find a way around this. If the Iexec API would allow to give arrays as parameters and return arrays as parameters, this would be much simpler. +with dynamic arrays it would first be necessary to convert an array, for example uint array uint[] bets = [1,20,3,4,5]; into the string "[1,20,3,4,5]". +The returned string "[90, 1800,270,360,450]" would then have to be turned into a uint array again, which would cost gas. +For complex operations our solution might still be cheaper, but it would be good to find a way around this. +If the Iexec API would allow to give arrays as parameters and return arrays as parameters, this would be much simpler. The function could then be called simply as iexecSubmit(bets, "let sum = fold (+) bets;let bets2 = map (%b. b*3000) bets; map (%b. round b / sum ) bets2"). @@ -90,7 +101,9 @@ Independently of that, a wrapper function iexecArrayOperation(bets, "let sum = fold (+) bets;let bets2 = map (%b. b*3000) bets; map (%b. round b / sum ) bets2") will be made available by out wrapper smart contract that takes care of converting the parameters into the right format for the iexecSubmit function. -Additionally the wrapper function would ensure that it is not necessary to manually concatenate the strings in a complicated manner. One way to do this might be to have an iexecSubmic function with several string parameters, and $x in the last parameter is replaced by the first parameter and $y in the last parameter is replaced by the second parameter. Example function call: +Additionally the wrapper function would ensure that it is not necessary to manually concatenate the strings in a complicated manner. +One way to do this might be to have an iexecSubmic function with several string parameters, and $x in the last parameter is replaced by +the first parameter and $y in the last parameter is replaced by the second parameter. Example function call: iexecSubmit(text, "replace \"O\" \"X\" $x) From bacda697a8ccf9d7f0aa382ba3d541bbab326fda Mon Sep 17 00:00:00 2001 From: radhuslanteg Date: Sat, 13 Jan 2018 22:40:55 +0100 Subject: [PATCH 10/28] formatting --- README.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 0cd1656..efa33f3 100644 --- a/README.md +++ b/README.md @@ -120,7 +120,8 @@ Two extremes: Either allow only functions written by us and allow any Haskell co -##Roadmap +#Roadmap + * Implement the three mentioned use cases * Research how parameters could be passed and returned in the cheapest way @@ -145,15 +146,17 @@ Version 3.0: ##Component diagram Wrapper Smart Contract -Wraps the variables and the pure code to haskell code, converts the haskell string output into the proper format. + +Wraps the solidity variables and the code-string to the full code-string and converts the haskell string output into the proper format in the callback function. Offchain-app + Input: Haskell code as string, or any solidity data types + haskell code as string output: string ##Sequential diagram of the solution -1. User Smart Contract (calling SC) calls our Wrapper Smart Contract by ForeignFunctionCall +1. User Smart Contract calls our Wrapper Smart Contract by ForeignFunctionCall 2. Our Wrapper Smart Contract takes care of converting all required data into a string containing the haskell code and spawns an off-chain computation, by calling the IExcec submit function via the IExcec API From a8aa3b14ed10c518c8a8e35ba600be72285a68b7 Mon Sep 17 00:00:00 2001 From: radhuslanteg Date: Sun, 14 Jan 2018 01:59:50 +0100 Subject: [PATCH 11/28] haskell now compiles --- README.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index efa33f3..45468db 100644 --- a/README.md +++ b/README.md @@ -38,17 +38,17 @@ for(uint j=0;j<=betIndex;j++) { Haskell: -> bets = [1,20,3,4,5] +let bets = [1,20,3,4,5] -> let sum = fold (+) bets +let su = sum bets + +let payout = map ((round) . (/su) . (*3000)) bets -> let bets2 = map (%b. b*3000) bets -> map (%b. round b / sum ) bets2 Spawning an offchain-computation on iexec could be wrapped like this: -iexecSubmit("bets = [1,20,3,4,5]; let sum = fold (+) bets;let bets2 = map (%b. b*3000) bets; map (%b. round b / sum ) bets2") +iexecSubmit("bets = [1,20,3,4,5]; let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets") For larger arrays the cost of RLC could be much lower than the cost of gas. Here the values of the array bets are hardcoded, but they can come from any uint array in the smart contract. @@ -86,7 +86,7 @@ These are the main challenges of the project: To use the example -iexecSubmit("bets = [1,20,3,4,5]; let sum = fold (+) bets;let bets2 = map (%b. b*3000) bets; map (%b. round b / sum ) bets2") +iexecSubmit("bets = [1,20,3,4,5]; let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets") with dynamic arrays it would first be necessary to convert an array, for example uint array uint[] bets = [1,20,3,4,5]; into the string "[1,20,3,4,5]". The returned string "[90, 1800,270,360,450]" would then have to be turned into a uint array again, which would cost gas. @@ -94,11 +94,11 @@ For complex operations our solution might still be cheaper, but it would be good If the Iexec API would allow to give arrays as parameters and return arrays as parameters, this would be much simpler. The function could then be called simply as -iexecSubmit(bets, "let sum = fold (+) bets;let bets2 = map (%b. b*3000) bets; map (%b. round b / sum ) bets2"). +iexecSubmit(bets, "let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets"). Independently of that, a wrapper function -iexecArrayOperation(bets, "let sum = fold (+) bets;let bets2 = map (%b. b*3000) bets; map (%b. round b / sum ) bets2") +iexecArrayOperation(bets, "let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets") will be made available by out wrapper smart contract that takes care of converting the parameters into the right format for the iexecSubmit function. Additionally the wrapper function would ensure that it is not necessary to manually concatenate the strings in a complicated manner. From 25094ddf5648fc6e94970bd62a670651c8a4e473 Mon Sep 17 00:00:00 2001 From: radhuslanteg Date: Sun, 14 Jan 2018 02:01:44 +0100 Subject: [PATCH 12/28] formatting --- README.md | 40 ++++++++++++++++++++++------------------ 1 file changed, 22 insertions(+), 18 deletions(-) diff --git a/README.md b/README.md index 45468db..41ad176 100644 --- a/README.md +++ b/README.md @@ -28,27 +28,31 @@ the total payout for each users, if user i has correctly betted the amount bets[ Solidity: -for(uint j=0;j<=betIndex;j++) { - sum = sum + bets[j]; -} +>for(uint j=0;j<=betIndex;j++) { -for(uint j=0;j<=betIndex;j++) { - payout[j] = (bets[j] * totalPayout)/sum; -} +> sum = sum + bets[j]; + +>} + +>for(uint j=0;j<=betIndex;j++) { + +> payout[j] = (bets[j] * totalPayout)/sum; + +>} Haskell: -let bets = [1,20,3,4,5] +>let bets = [1,20,3,4,5] -let su = sum bets +>let su = sum bets -let payout = map ((round) . (/su) . (*3000)) bets +>let payout = map ((round) . (/su) . (*3000)) bets Spawning an offchain-computation on iexec could be wrapped like this: -iexecSubmit("bets = [1,20,3,4,5]; let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets") +>iexecSubmit("bets = [1,20,3,4,5]; let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets") For larger arrays the cost of RLC could be much lower than the cost of gas. Here the values of the array bets are hardcoded, but they can come from any uint array in the smart contract. @@ -59,7 +63,7 @@ Here the values of the array bets are hardcoded, but they can come from any uint Another use-case could be string operations, eg. replace: -iexecSubmit("replace \"O\" \"X\" ".toSlice().concat(text.toSlice())) +>iexecSubmit("replace \"O\" \"X\" ".toSlice().concat(text.toSlice())) In this example all O are replaced by X in the solidity string text. All string operations in Haskell could be used that way. @@ -70,11 +74,11 @@ In this example all O are replaced by X in the solidity string text. All string A third use-case is to calculate dates exactly, taking into consideration leap seconds and time zones. For example, it would then be possible to get the exact date as a string given the unix time stamp: -iexecSubmit("formatTime defaultTimeLocale \"%c\".toSlice().concat(stringUtils.uintToBytes(now).toSlice())) +>iexecSubmit("formatTime defaultTimeLocale \"%c\".toSlice().concat(stringUtils.uintToBytes(now).toSlice())) Other possible functions include estimating unix time from dates as string and adding/substracting specific time intervals to/from dates. -The example above uses https://github.com/Arachnid/solidity-stringutils and https://github.com/pipermerriam/ethereum-string-utils for string manipulation. +>The example above uses https://github.com/Arachnid/solidity-stringutils and https://github.com/pipermerriam/ethereum-string-utils for string manipulation. #Challenges/Problems @@ -86,7 +90,7 @@ These are the main challenges of the project: To use the example -iexecSubmit("bets = [1,20,3,4,5]; let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets") +>iexecSubmit("bets = [1,20,3,4,5]; let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets") with dynamic arrays it would first be necessary to convert an array, for example uint array uint[] bets = [1,20,3,4,5]; into the string "[1,20,3,4,5]". The returned string "[90, 1800,270,360,450]" would then have to be turned into a uint array again, which would cost gas. @@ -94,22 +98,22 @@ For complex operations our solution might still be cheaper, but it would be good If the Iexec API would allow to give arrays as parameters and return arrays as parameters, this would be much simpler. The function could then be called simply as -iexecSubmit(bets, "let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets"). +>iexecSubmit(bets, "let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets"). Independently of that, a wrapper function -iexecArrayOperation(bets, "let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets") +>iexecArrayOperation(bets, "let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets") will be made available by out wrapper smart contract that takes care of converting the parameters into the right format for the iexecSubmit function. Additionally the wrapper function would ensure that it is not necessary to manually concatenate the strings in a complicated manner. One way to do this might be to have an iexecSubmic function with several string parameters, and $x in the last parameter is replaced by the first parameter and $y in the last parameter is replaced by the second parameter. Example function call: -iexecSubmit(text, "replace \"O\" \"X\" $x) +>iexecSubmit(text, "replace \"O\" \"X\" $x) or -iexecSubmit(stringUtils.uintToBytes(now), "formatTime defaultTimeLocale \"%c\ $x") +>iexecSubmit(stringUtils.uintToBytes(now), "formatTime defaultTimeLocale \"%c\ $x") These wrapper functions will also be written by us if they are not made available at a deeper level. From 5aa39287840f1c2809efdf2aaadd7693fbcd1f30 Mon Sep 17 00:00:00 2001 From: radhuslanteg Date: Sun, 14 Jan 2018 02:06:00 +0100 Subject: [PATCH 13/28] minor improvements --- README.md | 30 +++++++++++++----------------- 1 file changed, 13 insertions(+), 17 deletions(-) diff --git a/README.md b/README.md index 41ad176..9354dda 100644 --- a/README.md +++ b/README.md @@ -78,7 +78,7 @@ For example, it would then be possible to get the exact date as a string given t Other possible functions include estimating unix time from dates as string and adding/substracting specific time intervals to/from dates. ->The example above uses https://github.com/Arachnid/solidity-stringutils and https://github.com/pipermerriam/ethereum-string-utils for string manipulation. +The example above uses https://github.com/Arachnid/solidity-stringutils and https://github.com/pipermerriam/ethereum-string-utils for string manipulation. #Challenges/Problems @@ -126,37 +126,33 @@ Two extremes: Either allow only functions written by us and allow any Haskell co #Roadmap - * Implement the three mentioned use cases - * Research how parameters could be passed and returned in the cheapest way +Release 1.0: +* All Haskell code can be called with one string parameter from smart contracts. - * Benchmark starting at which level of complexity calling iexecSublit is cheaper then calculating everything on-chain +Release 2.0: +* The parameter wrapping (eg. from uint array to string) is done in a wrapper smart contract or possibly directly in the iexecSubmit function. - * Research how to ensure that all functions are side-effect free +Release 3.0: +* Haskell code is only run when it is ensured that is side-effect free - * Document the existing API so that it can be used and extended by other people +Release 4.0: +* Documentation and communicating the API to the community -Version 1.0: -* The three mentioned use-cases can be called with one string parameter from smart contracts. +##Component diagram -Version 2.0: -* The parameter wrapping (eg. from uint array to string) is done in a wrapper smart contract or possibly directly in the iexecSubmit function. +Offchain-app -Version 3.0: -* Additional Haskell functions are available if they are guaranteed to be save. +Input: Haskell code as string, or any solidity data types + haskell code as string +Output: String -##Component diagram Wrapper Smart Contract Wraps the solidity variables and the code-string to the full code-string and converts the haskell string output into the proper format in the callback function. -Offchain-app - -Input: Haskell code as string, or any solidity data types + haskell code as string -output: string ##Sequential diagram of the solution From 0ae397d3268b561503ed675509826aaef64e536e Mon Sep 17 00:00:00 2001 From: radhuslanteg Date: Sun, 14 Jan 2018 02:08:47 +0100 Subject: [PATCH 14/28] minor addition --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 9354dda..55b58e2 100644 --- a/README.md +++ b/README.md @@ -137,7 +137,7 @@ Release 3.0: * Haskell code is only run when it is ensured that is side-effect free Release 4.0: -* Documentation and communicating the API to the community +* Proofing and benchmark the cost-efficiency of our proposed API for the three use-cases; Documentation and communicating the API to the community ##Component diagram From bcded82c8f5c20574b9ed20ccc45c24fa6e48088 Mon Sep 17 00:00:00 2001 From: radhuslanteg Date: Sun, 14 Jan 2018 02:10:43 +0100 Subject: [PATCH 15/28] formatting --- README.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index 55b58e2..6262b3f 100644 --- a/README.md +++ b/README.md @@ -1,10 +1,10 @@ -Abstract +##Abstract We propose an API for off-chain execution of programs in the side-effect-free fragment of Haskell. This enables smart contracts to delegate gas intensive computations and thus save money. -#Idea Proposal +##Idea Proposal It would be ideal if smart contract deverlopers could just run general purpose code that is computationally intensive off-chain instead of on the blockchain. @@ -16,7 +16,7 @@ ensuring that there is no legal or security risk for the person selling their co There are many use-cases for this, we propose three of them here: -1) Operations on numeric array +#Operations on numeric array One possible use-case for this would be performing operations on arrays. For-loops are heavily used in Solidity but can be very expensive in terms of gas. @@ -58,7 +58,7 @@ For larger arrays the cost of RLC could be much lower than the cost of gas. Here the values of the array bets are hardcoded, but they can come from any uint array in the smart contract. -2) String operations +#String operations Another use-case could be string operations, eg. replace: @@ -81,12 +81,12 @@ Other possible functions include estimating unix time from dates as string and a The example above uses https://github.com/Arachnid/solidity-stringutils and https://github.com/pipermerriam/ethereum-string-utils for string manipulation. -#Challenges/Problems +##Challenges/Problems These are the main challenges of the project: -1) Getting the input data into the correct format +#Getting the input data into the correct format To use the example @@ -117,14 +117,14 @@ or These wrapper functions will also be written by us if they are not made available at a deeper level. -2) Ensuring that all functions are side-effect free and there is no IO operations except at the beginning and at the end. +#Ensuring that all functions are side-effect free and there is no IO operations except at the beginning and at the end. Two extremes: Either allow only functions written by us and allow any Haskell code. TODO: Max -#Roadmap +##Roadmap Release 1.0: From 153253fca97226b1633a9779c9666cad1d6909e9 Mon Sep 17 00:00:00 2001 From: radhuslanteg Date: Sun, 14 Jan 2018 02:12:08 +0100 Subject: [PATCH 16/28] formatting --- README.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/README.md b/README.md index 6262b3f..cf2d399 100644 --- a/README.md +++ b/README.md @@ -1,10 +1,10 @@ -##Abstract +####Abstract We propose an API for off-chain execution of programs in the side-effect-free fragment of Haskell. This enables smart contracts to delegate gas intensive computations and thus save money. -##Idea Proposal +####Idea Proposal It would be ideal if smart contract deverlopers could just run general purpose code that is computationally intensive off-chain instead of on the blockchain. @@ -16,7 +16,7 @@ ensuring that there is no legal or security risk for the person selling their co There are many use-cases for this, we propose three of them here: -#Operations on numeric array +##Operations on numeric array One possible use-case for this would be performing operations on arrays. For-loops are heavily used in Solidity but can be very expensive in terms of gas. @@ -58,7 +58,7 @@ For larger arrays the cost of RLC could be much lower than the cost of gas. Here the values of the array bets are hardcoded, but they can come from any uint array in the smart contract. -#String operations +##String operations Another use-case could be string operations, eg. replace: @@ -68,7 +68,7 @@ Another use-case could be string operations, eg. replace: In this example all O are replaced by X in the solidity string text. All string operations in Haskell could be used that way. -3) Date API +##Date API A third use-case is to calculate dates exactly, taking into consideration leap seconds and time zones. @@ -81,12 +81,12 @@ Other possible functions include estimating unix time from dates as string and a The example above uses https://github.com/Arachnid/solidity-stringutils and https://github.com/pipermerriam/ethereum-string-utils for string manipulation. -##Challenges/Problems +####Challenges/Problems These are the main challenges of the project: -#Getting the input data into the correct format +##Getting the input data into the correct format To use the example @@ -117,14 +117,14 @@ or These wrapper functions will also be written by us if they are not made available at a deeper level. -#Ensuring that all functions are side-effect free and there is no IO operations except at the beginning and at the end. +##Ensuring that all functions are side-effect free and there is no IO operations except at the beginning and at the end. Two extremes: Either allow only functions written by us and allow any Haskell code. TODO: Max -##Roadmap +####Roadmap Release 1.0: @@ -140,7 +140,7 @@ Release 4.0: * Proofing and benchmark the cost-efficiency of our proposed API for the three use-cases; Documentation and communicating the API to the community -##Component diagram +####Component diagram Offchain-app @@ -154,7 +154,7 @@ Wrapper Smart Contract Wraps the solidity variables and the code-string to the full code-string and converts the haskell string output into the proper format in the callback function. -##Sequential diagram of the solution +####Sequential diagram of the solution 1. User Smart Contract calls our Wrapper Smart Contract by ForeignFunctionCall From 3c9281dc178897dbf46119011b5ecd615bc5a366 Mon Sep 17 00:00:00 2001 From: radhuslanteg Date: Sun, 14 Jan 2018 12:29:02 +0100 Subject: [PATCH 17/28] added link to game --- README.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index cf2d399..e0c230b 100644 --- a/README.md +++ b/README.md @@ -167,6 +167,12 @@ Wraps the solidity variables and the code-string to the full code-string and con 4. The wrapper Smart Contract converts the computation's result into the required format and returns it to the User Smart Contract. ##Bonus: a dapp smart contract with truffle tests - + +The following code on github includes solidity code and truffle tests for a simple game that can be played on the Ethereum blockchain. +There are two teams, Red and Blue. Players can add money to the stack of Red or Blue and independently of which team gets money from the player, the player can bet which team wins. +A team wins if it has more than 50% or less than 25% of the total ETH sent to the team. + + +https://github.com/ahoelzl/smartContract From e99ac2d7e09c4a0cf79e18aa6df85ede4ce659d4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ond=C5=99ej=20Kun=C4=8Dar=20kuncar=40in=2Etum=2Ede?= <> Date: Mon, 22 Jan 2018 20:01:49 +0100 Subject: [PATCH 18/28] typo --- README.md | 54 ++++++++++++++++++++++++++---------------------------- 1 file changed, 26 insertions(+), 28 deletions(-) diff --git a/README.md b/README.md index e0c230b..3352174 100644 --- a/README.md +++ b/README.md @@ -7,24 +7,24 @@ This enables smart contracts to delegate gas intensive computations and thus sav ####Idea Proposal -It would be ideal if smart contract deverlopers could just run general purpose code that is computationally intensive off-chain instead of on the blockchain. - This is, however, a security risk for the people running the calculations of their personal computers. -We believe that side-effect-free Haskell functions allows for a large multitude of possible programs that can be run while +It would be ideal if smart contract developers could just run general purpose code that is computationally intensive off-chain instead of on the blockchain. + This is, however, a security risk for the people running the calculations of their personal computers. +We believe that side-effect-free Haskell functions allows for a large multitude of possible programs that can be run while ensuring that there is no legal or security risk for the person selling their computational ressources. Ensuring and proofing the security of all possible programs that can be run on the servers running the offchain-computations is part of the project (TODO: write some more). There are many use-cases for this, we propose three of them here: - -##Operations on numeric array -One possible use-case for this would be performing operations on arrays. +##Operations on numeric array + +One possible use-case for this would be performing operations on arrays. For-loops are heavily used in Solidity but can be very expensive in terms of gas. -Most of such easy computations can be compactly reformulated in Haskell (example below). +Most of such easy computations can be compactly reformulated in Haskell (example below). By pulling those computations off the blockchain, a lot of gas and thus money can be saved. -Example of for-loop in solidity and an equivalent functional program, which calulates -the total payout for each users, if user i has correctly betted the amount bets[i]: +Example of for-loop in solidity and an equivalent functional program, which calulates +the total payout for each users, if user i has correctly betted the amount bets[i]: Solidity: @@ -40,7 +40,7 @@ Solidity: >} -Haskell: +Haskell: >let bets = [1,20,3,4,5] @@ -54,7 +54,7 @@ Spawning an offchain-computation on iexec could be wrapped like this: >iexecSubmit("bets = [1,20,3,4,5]; let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets") -For larger arrays the cost of RLC could be much lower than the cost of gas. +For larger arrays the cost of RLC could be much lower than the cost of gas. Here the values of the array bets are hardcoded, but they can come from any uint array in the smart contract. @@ -71,7 +71,7 @@ In this example all O are replaced by X in the solidity string text. All string ##Date API -A third use-case is to calculate dates exactly, taking into consideration leap seconds and time zones. +A third use-case is to calculate dates exactly, taking into consideration leap seconds and time zones. For example, it would then be possible to get the exact date as a string given the unix time stamp: >iexecSubmit("formatTime defaultTimeLocale \"%c\".toSlice().concat(stringUtils.uintToBytes(now).toSlice())) @@ -89,35 +89,35 @@ These are the main challenges of the project: ##Getting the input data into the correct format To use the example - + >iexecSubmit("bets = [1,20,3,4,5]; let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets") -with dynamic arrays it would first be necessary to convert an array, for example uint array uint[] bets = [1,20,3,4,5]; into the string "[1,20,3,4,5]". -The returned string "[90, 1800,270,360,450]" would then have to be turned into a uint array again, which would cost gas. -For complex operations our solution might still be cheaper, but it would be good to find a way around this. +with dynamic arrays it would first be necessary to convert an array, for example uint array uint[] bets = [1,20,3,4,5]; into the string "[1,20,3,4,5]". +The returned string "[90, 1800,270,360,450]" would then have to be turned into a uint array again, which would cost gas. +For complex operations our solution might still be cheaper, but it would be good to find a way around this. If the Iexec API would allow to give arrays as parameters and return arrays as parameters, this would be much simpler. -The function could then be called simply as +The function could then be called simply as ->iexecSubmit(bets, "let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets"). +>iexecSubmit(bets, "let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets"). -Independently of that, a wrapper function +Independently of that, a wrapper function >iexecArrayOperation(bets, "let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets") will be made available by out wrapper smart contract that takes care of converting the parameters into the right format for the iexecSubmit function. -Additionally the wrapper function would ensure that it is not necessary to manually concatenate the strings in a complicated manner. -One way to do this might be to have an iexecSubmic function with several string parameters, and $x in the last parameter is replaced by -the first parameter and $y in the last parameter is replaced by the second parameter. Example function call: +Additionally the wrapper function would ensure that it is not necessary to manually concatenate the strings in a complicated manner. +One way to do this might be to have an iexecSubmic function with several string parameters, and $x in the last parameter is replaced by +the first parameter and $y in the last parameter is replaced by the second parameter. Example function call: >iexecSubmit(text, "replace \"O\" \"X\" $x) -or +or >iexecSubmit(stringUtils.uintToBytes(now), "formatTime defaultTimeLocale \"%c\ $x") These wrapper functions will also be written by us if they are not made available at a deeper level. -##Ensuring that all functions are side-effect free and there is no IO operations except at the beginning and at the end. +##Ensuring that all functions are side-effect free and there is no IO operations except at the beginning and at the end. Two extremes: Either allow only functions written by us and allow any Haskell code. TODO: Max @@ -131,7 +131,7 @@ Release 1.0: * All Haskell code can be called with one string parameter from smart contracts. Release 2.0: -* The parameter wrapping (eg. from uint array to string) is done in a wrapper smart contract or possibly directly in the iexecSubmit function. +* The parameter wrapping (eg. from uint array to string) is done in a wrapper smart contract or possibly directly in the iexecSubmit function. Release 3.0: * Haskell code is only run when it is ensured that is side-effect free @@ -173,6 +173,4 @@ There are two teams, Red and Blue. Players can add money to the stack of Red or A team wins if it has more than 50% or less than 25% of the total ETH sent to the team. -https://github.com/ahoelzl/smartContract - - +https://github.com/ahoelzl/smartContract From 97305cfc651f3b71c79717470a3fa3483af43f73 Mon Sep 17 00:00:00 2001 From: ahoelzl Date: Mon, 22 Jan 2018 22:40:08 +0100 Subject: [PATCH 19/28] next iteration --- README.md | 100 +++++++++++++++++++++++++++++++++++------------------- 1 file changed, 66 insertions(+), 34 deletions(-) diff --git a/README.md b/README.md index 3352174..a05a170 100644 --- a/README.md +++ b/README.md @@ -6,21 +6,54 @@ This enables smart contracts to delegate gas intensive computations and thus sav ####Idea Proposal +As computational power on the blockchain is expensive (due to high gas consumption) it is favorable +to pull computations off the blockchain. +In this proposal we want to adress two problems (A and B): -It would be ideal if smart contract developers could just run general purpose code that is computationally intensive off-chain instead of on the blockchain. - This is, however, a security risk for the people running the calculations of their personal computers. -We believe that side-effect-free Haskell functions allows for a large multitude of possible programs that can be run while -ensuring that there is no legal or security risk for the person selling their computational ressources. - Ensuring and proofing the security of all possible programs that can be run on the servers running the offchain-computations is part of the project - (TODO: write some more). +A) +There are many ideas how to pull off onchain executions off the chain. +But it is too much boiler-plate and deployment effort to generate a unique DApp +for each of these problems. +Should we really have a specific single purpose DApp that computes +the human readable date from unix timestamp. +And then another one that computes the median of a list of integers. +Ah, I need a new DApp for my lottery that calculates the average of a list of integers... -There are many use-cases for this, we propose three of them here: +Common, this can't be real. You guys at IExec do not want to review all these boring code snippets +wrapped into a distributed app. +And we don't want to write these wrappers!! + +So what we propose is a general framework for executing such code snippets. + + +B) +But we shouldn't forget that with power comes responsability. +We have to guarantee security for the providers of computational power, +one of the main objectives of the IExec project. +In other words, we are trying to solve an optimisation problem: between expressiveness and security. + +In our opinion, side-effect free programs are the sweet spot on this scale. +Such programs are amonst others not allowed to access the internet, write to disk +or call system functions. But they ARE allowed to compute any desired function that only +depends on its parameters and return its result. + + +Of course, such a proposal is only then useful if there is a simple mechanical check for the absence of side effects. +In comparison to imperative programming languages such as C++ or Java, the functional programming language Haskell provides such facilities. +Every program in Haskell has a unique type that reveals +whether the program is side effect free. Qed. + +When brainstorming for this challenge we made the same mistake and came up with +countless simple single purpose applications. +At some point we realized that all of these snippets are side effect free programs, +which will now serve as mere demonstrators for the proposed frame work. +We will briefly sketch three of them in the next section. ##Operations on numeric array -One possible use-case for this would be performing operations on arrays. +One possible use-case for this is performing operations on arrays. For-loops are heavily used in Solidity but can be very expensive in terms of gas. -Most of such easy computations can be compactly reformulated in Haskell (example below). +Most of such easy computations can be compactly formulated in Haskell (example below). By pulling those computations off the blockchain, a lot of gas and thus money can be saved. Example of for-loop in solidity and an equivalent functional program, which calulates @@ -81,10 +114,10 @@ Other possible functions include estimating unix time from dates as string and a The example above uses https://github.com/Arachnid/solidity-stringutils and https://github.com/pipermerriam/ethereum-string-utils for string manipulation. -####Challenges/Problems +####Technical Challenges/Problems -These are the main challenges of the project: +There is one main obstacle: ##Getting the input data into the correct format @@ -92,10 +125,12 @@ To use the example >iexecSubmit("bets = [1,20,3,4,5]; let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets") -with dynamic arrays it would first be necessary to convert an array, for example uint array uint[] bets = [1,20,3,4,5]; into the string "[1,20,3,4,5]". -The returned string "[90, 1800,270,360,450]" would then have to be turned into a uint array again, which would cost gas. -For complex operations our solution might still be cheaper, but it would be good to find a way around this. -If the Iexec API would allow to give arrays as parameters and return arrays as parameters, this would be much simpler. +with dynamic arrays it is necessary to convert an array, for example uint array uint[] bets = [1,20,3,4,5]; into the string "[1,20,3,4,5]". +The returned string "[90, 1800,270,360,450]" then has to be turned into a uint array again, which costs gas. +The overhead of converting to and from strings is considerable. +For complex operations this solution might still be cheaper, but is preferable to find a way around this. +If the IExec API allowed us to give arrays as parameters and returned arrays, this would be much simpler +(Consider this as a feature request!). The function could then be called simply as >iexecSubmit(bets, "let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets"). @@ -104,40 +139,34 @@ Independently of that, a wrapper function >iexecArrayOperation(bets, "let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets") - will be made available by out wrapper smart contract that takes care of converting the parameters into the right format for the iexecSubmit function. -Additionally the wrapper function would ensure that it is not necessary to manually concatenate the strings in a complicated manner. + will be made available by our wrapper smart contract that takes care of converting the parameters into the right format for the iexecSubmit function. +The wrapper function additionally would ensure that it is not necessary to manually concatenate the strings in a complicated manner. One way to do this might be to have an iexecSubmic function with several string parameters, and $x in the last parameter is replaced by the first parameter and $y in the last parameter is replaced by the second parameter. Example function call: ->iexecSubmit(text, "replace \"O\" \"X\" $x) +>iexecSubmit(text, "replace \"O\" \"X\" $x") or ->iexecSubmit(stringUtils.uintToBytes(now), "formatTime defaultTimeLocale \"%c\ $x") +>iexecSubmit(stringUtils.uintToBytes(now), "formatTime defaultTimeLocale \"%c\" $x") These wrapper functions will also be written by us if they are not made available at a deeper level. -##Ensuring that all functions are side-effect free and there is no IO operations except at the beginning and at the end. - - -Two extremes: Either allow only functions written by us and allow any Haskell code. TODO: Max - - ####Roadmap -Release 1.0: +Alpha: * All Haskell code can be called with one string parameter from smart contracts. -Release 2.0: +Beta: * The parameter wrapping (eg. from uint array to string) is done in a wrapper smart contract or possibly directly in the iexecSubmit function. -Release 3.0: +Release: * Haskell code is only run when it is ensured that is side-effect free -Release 4.0: -* Proofing and benchmark the cost-efficiency of our proposed API for the three use-cases; Documentation and communicating the API to the community +Post-release: +* Proofing and benchmarking the cost-efficiency of our proposed API for the three use-cases; Documentation and communicating the API to the community ####Component diagram @@ -146,7 +175,7 @@ Offchain-app Input: Haskell code as string, or any solidity data types + haskell code as string -Output: String +Output: String if the program is side-effect free, "Program invalid because of side-effects" otherwise. Wrapper Smart Contract @@ -158,11 +187,14 @@ Wraps the solidity variables and the code-string to the full code-string and con 1. User Smart Contract calls our Wrapper Smart Contract by ForeignFunctionCall -2. Our Wrapper Smart Contract takes care of converting all required data into a string containing the haskell code and spawns an off-chain computation, by calling the IExcec submit function via the IExcec API - +2. Our Wrapper Smart Contract takes care of converting all required data into a string containing the haskell code and spawns an off-chain computation, + by calling the IExcec submit function via the IExcec API. -3. IExcec reads the block and finds out there was a call to our iexec project and the binary in the apps folder starts to run with the given parameters. After running it writes back the return string to the calling smart contract. +3. IExcec reads the block and finds out that there was a call to our iexec project and the binary in the apps folder starts to run with the given parameters. +In the "analysis phase" the Haskell interpreter is instructed to infer the type of the provided Haskell program. +If it is side effect free and thus regarded as safe, it is executed using the Haskell interpreter (in an "execution phase") +and its result is written back as the return string to the calling smart contract. 4. The wrapper Smart Contract converts the computation's result into the required format and returns it to the User Smart Contract. From 841333399e76d74461b5e3c3369662b8dc8c42e5 Mon Sep 17 00:00:00 2001 From: radhuslanteg Date: Mon, 29 Jan 2018 21:14:15 +0100 Subject: [PATCH 20/28] minor improvements --- README.md | 55 ++++++++++++++++++++++--------------------------------- 1 file changed, 22 insertions(+), 33 deletions(-) diff --git a/README.md b/README.md index a05a170..4d4053c 100644 --- a/README.md +++ b/README.md @@ -6,47 +6,38 @@ This enables smart contracts to delegate gas intensive computations and thus sav ####Idea Proposal -As computational power on the blockchain is expensive (due to high gas consumption) it is favorable -to pull computations off the blockchain. +As computational power on the blockchain is expensive (due to high gas consumption) it is favorable to pull computations off the blockchain. In this proposal we want to adress two problems (A and B): A) -There are many ideas how to pull off onchain executions off the chain. +There are many use cases for substituting onchain calculations with cheaper offchain calculations. But it is too much boiler-plate and deployment effort to generate a unique DApp for each of these problems. Should we really have a specific single purpose DApp that computes -the human readable date from unix timestamp. -And then another one that computes the median of a list of integers. -Ah, I need a new DApp for my lottery that calculates the average of a list of integers... +the human readable date from unix timestamps, another one that computes the median of a list of integers and another that that calculates the average of a list of integers? Each of these ideas also has to be submitted as an app to the Iexec app store and the code of each of these dapps has to be reviewed individually, even though most of it is just boilerplate code. -Common, this can't be real. You guys at IExec do not want to review all these boring code snippets -wrapped into a distributed app. -And we don't want to write these wrappers!! -So what we propose is a general framework for executing such code snippets. +What we propose is a general framework for executing such code snippets. B) -But we shouldn't forget that with power comes responsability. -We have to guarantee security for the providers of computational power, -one of the main objectives of the IExec project. +But we shouldn't forget that with power comes responsibility. +We have to guarantee security for the providers of computational power, so that no malicious code can be executed on the servers running the calulcations + In other words, we are trying to solve an optimisation problem: between expressiveness and security. In our opinion, side-effect free programs are the sweet spot on this scale. -Such programs are amonst others not allowed to access the internet, write to disk -or call system functions. But they ARE allowed to compute any desired function that only -depends on its parameters and return its result. +Such programs are amonst others not allowed to access the internet, write to disk or call system functions. But they ARE allowed to compute any desired function that only depends on its parameters and return its result. -Of course, such a proposal is only then useful if there is a simple mechanical check for the absence of side effects. -In comparison to imperative programming languages such as C++ or Java, the functional programming language Haskell provides such facilities. +Of course, such a proposal is only useful if there is a simple mechanical check for the absence of side effects. +In contrast to imperative programming languages such as C++ or Java, the functional programming language Haskell provides such facilities. Every program in Haskell has a unique type that reveals -whether the program is side effect free. Qed. +whether the program is side effect free. When brainstorming for this challenge we made the same mistake and came up with countless simple single purpose applications. -At some point we realized that all of these snippets are side effect free programs, -which will now serve as mere demonstrators for the proposed frame work. +At some point we realized that all of these snippets are side effect free programs, which will now serve as mere demonstrators for the proposed frame work. We will briefly sketch three of them in the next section. ##Operations on numeric array @@ -117,8 +108,6 @@ The example above uses https://github.com/Arachnid/solidity-stringutils and http ####Technical Challenges/Problems -There is one main obstacle: - ##Getting the input data into the correct format To use the example @@ -141,23 +130,18 @@ Independently of that, a wrapper function will be made available by our wrapper smart contract that takes care of converting the parameters into the right format for the iexecSubmit function. The wrapper function additionally would ensure that it is not necessary to manually concatenate the strings in a complicated manner. -One way to do this might be to have an iexecSubmic function with several string parameters, and $x in the last parameter is replaced by -the first parameter and $y in the last parameter is replaced by the second parameter. Example function call: - ->iexecSubmit(text, "replace \"O\" \"X\" $x") -or +The call to out wrapper function could for example look like this: ->iexecSubmit(stringUtils.uintToBytes(now), "formatTime defaultTimeLocale \"%c\" $x") +>iexecSubmit(text, "replace \"O\" \"X\" $x") -These wrapper functions will also be written by us if they are not made available at a deeper level. ####Roadmap Alpha: -* All Haskell code can be called with one string parameter from smart contracts. +* All Haskell code can be called with one string parameter from a wrapper smart contracts. Beta: * The parameter wrapping (eg. from uint array to string) is done in a wrapper smart contract or possibly directly in the iexecSubmit function. @@ -171,11 +155,16 @@ Post-release: ####Component diagram +Verifier +Input: haskell code as a string +Output: The type of the function containing this code. If it is a pure function,the code can be executed, if it is not return an exception + + Offchain-app Input: Haskell code as string, or any solidity data types + haskell code as string -Output: String if the program is side-effect free, "Program invalid because of side-effects" otherwise. +Output: String of the output of the program. Wrapper Smart Contract @@ -192,7 +181,7 @@ Wraps the solidity variables and the code-string to the full code-string and con 3. IExcec reads the block and finds out that there was a call to our iexec project and the binary in the apps folder starts to run with the given parameters. -In the "analysis phase" the Haskell interpreter is instructed to infer the type of the provided Haskell program. +In the "verification phase" the Haskell interpreter is instructed to infer the type of the provided Haskell program. If it is side effect free and thus regarded as safe, it is executed using the Haskell interpreter (in an "execution phase") and its result is written back as the return string to the calling smart contract. From 555db43ac5efbc5542fe239b74af868d5a709d79 Mon Sep 17 00:00:00 2001 From: radhuslanteg Date: Mon, 29 Jan 2018 21:25:04 +0100 Subject: [PATCH 21/28] added team section --- README.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 4d4053c..26a37e3 100644 --- a/README.md +++ b/README.md @@ -11,7 +11,7 @@ In this proposal we want to adress two problems (A and B): A) There are many use cases for substituting onchain calculations with cheaper offchain calculations. -But it is too much boiler-plate and deployment effort to generate a unique DApp +But it is too much boiler-plate code and deployment effort to generate a unique DApp for each of these problems. Should we really have a specific single purpose DApp that computes the human readable date from unix timestamps, another one that computes the median of a list of integers and another that that calculates the average of a list of integers? Each of these ideas also has to be submitted as an app to the Iexec app store and the code of each of these dapps has to be reviewed individually, even though most of it is just boilerplate code. @@ -22,7 +22,7 @@ What we propose is a general framework for executing such code snippets. B) But we shouldn't forget that with power comes responsibility. -We have to guarantee security for the providers of computational power, so that no malicious code can be executed on the servers running the calulcations +We have to guarantee security for the providers of computational power, so that no malicious code can be executed on the servers running the calulcations. In other words, we are trying to solve an optimisation problem: between expressiveness and security. @@ -156,6 +156,7 @@ Post-release: ####Component diagram Verifier + Input: haskell code as a string Output: The type of the function containing this code. If it is a pure function,the code can be executed, if it is not return an exception @@ -195,3 +196,8 @@ A team wins if it has more than 50% or less than 25% of the total ETH sent to th https://github.com/ahoelzl/smartContract + + +##Team + +ahoelzl: Working as a data scientist and cryptocurrency enthusiast. From 3636fcb26e54dc9f9c52d577c18e37e1ae1c04aa Mon Sep 17 00:00:00 2001 From: radhuslanteg Date: Tue, 30 Jan 2018 20:00:34 +0100 Subject: [PATCH 22/28] minor changes --- README.md | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index 26a37e3..8e22e92 100644 --- a/README.md +++ b/README.md @@ -11,10 +11,8 @@ In this proposal we want to adress two problems (A and B): A) There are many use cases for substituting onchain calculations with cheaper offchain calculations. -But it is too much boiler-plate code and deployment effort to generate a unique DApp -for each of these problems. -Should we really have a specific single purpose DApp that computes -the human readable date from unix timestamps, another one that computes the median of a list of integers and another that that calculates the average of a list of integers? Each of these ideas also has to be submitted as an app to the Iexec app store and the code of each of these dapps has to be reviewed individually, even though most of it is just boilerplate code. +But it is too much boiler-plate code and deployment effort to generate a unique DApp for each of these problems. +Should we really have a specific single purpose DApp that computes the human readable date from unix timestamps, another one that computes the median of a list of integers and another that that calculates the average of a list of integers? Each of these ideas also has to be submitted as an app to the Iexec app store and the code of each of these dapps has to be reviewed individually, even though most of it is just boilerplate code. What we propose is a general framework for executing such code snippets. @@ -144,10 +142,11 @@ Alpha: * All Haskell code can be called with one string parameter from a wrapper smart contracts. Beta: -* The parameter wrapping (eg. from uint array to string) is done in a wrapper smart contract or possibly directly in the iexecSubmit function. +* Haskell code is only run when it is ensured that is side-effect free + Release: -* Haskell code is only run when it is ensured that is side-effect free +* The parameter wrapping (eg. from uint array to string) is done in a wrapper smart contract or possibly directly in the iexecSubmit function. Post-release: * Proofing and benchmarking the cost-efficiency of our proposed API for the three use-cases; Documentation and communicating the API to the community @@ -157,7 +156,7 @@ Post-release: Verifier -Input: haskell code as a string +Input: Haskell code as a string Output: The type of the function containing this code. If it is a pure function,the code can be executed, if it is not return an exception @@ -200,4 +199,4 @@ https://github.com/ahoelzl/smartContract ##Team -ahoelzl: Working as a data scientist and cryptocurrency enthusiast. +We are a team of four people. Two of us are working in the area of data science/machine learning, one PhD student in the field of formal verification and interactive theorem solving and one postdoc in the same field. From 35f678a45bab7d176acd7a4433b449b5ccf86cc4 Mon Sep 17 00:00:00 2001 From: Anton Brandl Date: Wed, 31 Jan 2018 21:34:00 +0100 Subject: [PATCH 23/28] Update README.md --- README.md | 137 +++++++++++++++++++++++++----------------------------- 1 file changed, 64 insertions(+), 73 deletions(-) diff --git a/README.md b/README.md index 8e22e92..85a4c7f 100644 --- a/README.md +++ b/README.md @@ -1,52 +1,50 @@ ####Abstract - -We propose an API for off-chain execution of programs in the side-effect-free fragment of Haskell. +We propose an API for the off-chain execution of programs in the side-effect-free fragment of Haskell. This enables smart contracts to delegate gas intensive computations and thus save money. ####Idea Proposal -As computational power on the blockchain is expensive (due to high gas consumption) it is favorable to pull computations off the blockchain. -In this proposal we want to adress two problems (A and B): +As computational power on the blockchain is expensive (due to high gas consumption), it is favorable to pull computations off the blockchain. +In this proposal, we want to address two problems (A and B): -A) -There are many use cases for substituting onchain calculations with cheaper offchain calculations. -But it is too much boiler-plate code and deployment effort to generate a unique DApp for each of these problems. -Should we really have a specific single purpose DApp that computes the human readable date from unix timestamps, another one that computes the median of a list of integers and another that that calculates the average of a list of integers? Each of these ideas also has to be submitted as an app to the Iexec app store and the code of each of these dapps has to be reviewed individually, even though most of it is just boilerplate code. +A) +There are many use cases for substituting on-chain calculations with cheaper off-chain calculations. +But it is too much boilerplate code and deployment effort to generate a unique DApp for each of these problems. +Should we really have a specific single purpose DApp that computes the human readable date from unix timestamps, another one that computes the median of a list of integers and another that calculates the average of a list of integers? Each of these ideas also has to be submitted as an DApp to the Iexec app store and the code of each of these DApps has to be reviewed individually, even though most of it is just boilerplate code. -What we propose is a general framework for executing such code snippets. +We propose a general framework for executing such code snippets. This enables us to solve a multitude of problems with one DApp, but we shouldn’t forget that with power comes responsibility. This leads us to the second problem: B) -But we shouldn't forget that with power comes responsibility. -We have to guarantee security for the providers of computational power, so that no malicious code can be executed on the servers running the calulcations. +We have to guarantee security for the providers of computational power, so that no malicious code can be executed on the servers running the calculations. -In other words, we are trying to solve an optimisation problem: between expressiveness and security. +In other words, we are trying to find the sweet spot between expressiveness and security. -In our opinion, side-effect free programs are the sweet spot on this scale. -Such programs are amonst others not allowed to access the internet, write to disk or call system functions. But they ARE allowed to compute any desired function that only depends on its parameters and return its result. +In our opinion, both can be achieved by allowing only the definition of side-effect free programs. Such programs are not allowed to access the internet, write to disk or call system functions. Thus, these kind of programs cannot pose a security risk for the host machine. -Of course, such a proposal is only useful if there is a simple mechanical check for the absence of side effects. -In contrast to imperative programming languages such as C++ or Java, the functional programming language Haskell provides such facilities. -Every program in Haskell has a unique type that reveals -whether the program is side effect free. +Of course, such a proposal is only useful if there is a simple mechanical check for the absence of side-effects. +The functional programming language Haskell provides such tools. +Every function in Haskell has a unique type that reveals +whether the function is side-effect free. +In order to check if the entire program is side-effect free, it is sufficient to check the type of the main function. -When brainstorming for this challenge we made the same mistake and came up with -countless simple single purpose applications. -At some point we realized that all of these snippets are side effect free programs, which will now serve as mere demonstrators for the proposed frame work. +Before creating this proposal, we came up with countless simple single-purpose applications for the iExec challenge. +At some point, we realized that all of those snippets are side-effect free programs, which will now serve as mere demonstrators for the proposed framework. We will briefly sketch three of them in the next section. ##Operations on numeric array -One possible use-case for this is performing operations on arrays. For-loops are heavily used in Solidity but can be very expensive in terms of gas. -Most of such easy computations can be compactly formulated in Haskell (example below). -By pulling those computations off the blockchain, a lot of gas and thus money can be saved. +Most of these can be compactly formulated in Haskell (example below). +By pulling the computations off the blockchain, a lot of gas and thus money can be saved. + +The following shows a typical example of a for-loop in Solidity. Imagine a betting game, where each user gets a payout depending on the number of correct guesses. The Solidity script calculates the total payout for each user. + +Let bets[i] be the number of correct guesses of User i. -Example of for-loop in solidity and an equivalent functional program, which calulates -the total payout for each users, if user i has correctly betted the amount bets[i]: Solidity: @@ -62,23 +60,20 @@ Solidity: >} -Haskell: +The following Haskell code is functionally equivalent: ->let bets = [1,20,3,4,5] >let su = sum bets ->let payout = map ((round) . (/su) . (*3000)) bets +>let payout = map ((round) . (/su) . (*total_payout)) bets - - -Spawning an offchain-computation on iexec could be wrapped like this: +For a very concrete example, spawning an off-chain computation on iExec could be wrapped like this: >iexecSubmit("bets = [1,20,3,4,5]; let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets") -For larger arrays the cost of RLC could be much lower than the cost of gas. -Here the values of the array bets are hardcoded, but they can come from any uint array in the smart contract. +Here, the values of the array bets are hardcoded, but they can come from any uint array in the smart contract. +For larger arrays, the cost of RLC could be much lower than the cost of gas. ##String operations @@ -87,20 +82,20 @@ Another use-case could be string operations, eg. replace: >iexecSubmit("replace \"O\" \"X\" ".toSlice().concat(text.toSlice())) -In this example all O are replaced by X in the solidity string text. All string operations in Haskell could be used that way. +In this example all “O” are replaced by “X” in the solidity string text. All other string operations in Haskell could be used in the same way. ##Date API A third use-case is to calculate dates exactly, taking into consideration leap seconds and time zones. -For example, it would then be possible to get the exact date as a string given the unix time stamp: +For example, it would be possible to convert a Unix timestamp into a human readable string: >iexecSubmit("formatTime defaultTimeLocale \"%c\".toSlice().concat(stringUtils.uintToBytes(now).toSlice())) -Other possible functions include estimating unix time from dates as string and adding/substracting specific time intervals to/from dates. +Other possible functions include converting string dates to Unix timestamps and adding/subtracting specific time intervals to/from dates. -The example above uses https://github.com/Arachnid/solidity-stringutils and https://github.com/pipermerriam/ethereum-string-utils for string manipulation. +The example above uses the Solidity libraries https://github.com/Arachnid/solidity-stringutils and https://github.com/pipermerriam/ethereum-string-utils for string manipulation. ####Technical Challenges/Problems @@ -112,44 +107,38 @@ To use the example >iexecSubmit("bets = [1,20,3,4,5]; let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets") -with dynamic arrays it is necessary to convert an array, for example uint array uint[] bets = [1,20,3,4,5]; into the string "[1,20,3,4,5]". -The returned string "[90, 1800,270,360,450]" then has to be turned into a uint array again, which costs gas. +with dynamic arrays, it is necessary to convert the integer arrays into strings. (e.g. the uint array uint[] bets = [1,20,3,4,5]; into the string "[1,20,3,4,5]") +The callback function, which returns the result, has to turn the string "[90, 1800,270,360,450]" into an integer array again, which costs gas. The overhead of converting to and from strings is considerable. -For complex operations this solution might still be cheaper, but is preferable to find a way around this. -If the IExec API allowed us to give arrays as parameters and returned arrays, this would be much simpler +For complex operations, our solution might still be cheaper, but it is preferable to find a way around this. +If the iExec API allowed to provide arrays as parameters and also returned arrays, this would be much simpler (Consider this as a feature request!). -The function could then be called simply as +The function could then simply be called with >iexecSubmit(bets, "let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets"). -Independently of that, a wrapper function +Independently of this feature, a wrapper function >iexecArrayOperation(bets, "let su = sum bets;let payout = map ((round) . (/su) . (*3000)) bets") - will be made available by our wrapper smart contract that takes care of converting the parameters into the right format for the iexecSubmit function. -The wrapper function additionally would ensure that it is not necessary to manually concatenate the strings in a complicated manner. - -The call to out wrapper function could for example look like this: - ->iexecSubmit(text, "replace \"O\" \"X\" $x") - - +will be made available by our wrapper smart contract that takes care of converting the parameters into the right format for the iexecSubmit function. ####Roadmap Alpha: -* All Haskell code can be called with one string parameter from a wrapper smart contracts. +* All Haskell code can be called with one string parameter from a wrapper smart contract. Beta: -* Haskell code is only run when it is ensured that is side-effect free +* Haskell code is only run when it is proven to be side-effect free. Release: * The parameter wrapping (eg. from uint array to string) is done in a wrapper smart contract or possibly directly in the iexecSubmit function. Post-release: -* Proofing and benchmarking the cost-efficiency of our proposed API for the three use-cases; Documentation and communicating the API to the community +* Proofing and benchmarking the cost-efficiency of our proposed API for the three use-cases. +* Documenting and communicating the API to the community. ####Component diagram @@ -157,41 +146,41 @@ Post-release: Verifier Input: Haskell code as a string -Output: The type of the function containing this code. If it is a pure function,the code can be executed, if it is not return an exception +Output: The type of the function containing this code. If it is a pure function, the code can be executed. If it is not, return an exception. -Offchain-app +Off-chain App -Input: Haskell code as string, or any solidity data types + haskell code as string +Input: Haskell code as String or any Solidity data types + Haskell code as String -Output: String of the output of the program. +Output: String of the program output. Wrapper Smart Contract -Wraps the solidity variables and the code-string to the full code-string and converts the haskell string output into the proper format in the callback function. +The Wrapper Smart Contract has two objectives: +Wraps the Solidity variables and the String containing the code into a String containing the full Haskell code. (including the variable initializations) +Converts the returned result string into Solidity variables in the callback function. ####Sequential diagram of the solution 1. User Smart Contract calls our Wrapper Smart Contract by ForeignFunctionCall -2. Our Wrapper Smart Contract takes care of converting all required data into a string containing the haskell code and spawns an off-chain computation, - by calling the IExcec submit function via the IExcec API. +2. Our Wrapper Smart Contract takes care of converting all required data into a String containing the Haskell code and spawns an off-chain computation by calling the iExcec submit function via the iExcec API. +3. iExcec reads the block and finds out that there was a call to our iExec project. +In the "verification phase", the Haskell interpreter is instructed to infer the type of the provided Haskell program. +If it is side-effect free and thus regarded as safe, it is executed using the Haskell interpreter (in an "execution phase"). +Its result is written back as the return string to the calling smart contract. -3. IExcec reads the block and finds out that there was a call to our iexec project and the binary in the apps folder starts to run with the given parameters. -In the "verification phase" the Haskell interpreter is instructed to infer the type of the provided Haskell program. -If it is side effect free and thus regarded as safe, it is executed using the Haskell interpreter (in an "execution phase") -and its result is written back as the return string to the calling smart contract. +4. The Wrapper Smart Contract converts the computation’s result into the required format and returns it to the User Smart Contract. -4. The wrapper Smart Contract converts the computation's result into the required format and returns it to the User Smart Contract. +##Bonus: a DApp smart contract with truffle tests -##Bonus: a dapp smart contract with truffle tests - -The following code on github includes solidity code and truffle tests for a simple game that can be played on the Ethereum blockchain. -There are two teams, Red and Blue. Players can add money to the stack of Red or Blue and independently of which team gets money from the player, the player can bet which team wins. -A team wins if it has more than 50% or less than 25% of the total ETH sent to the team. +The following code on github includes Solidity code and truffle tests for a simple game that can be played on the Ethereum blockchain. +There are two teams, Red and Blue. Players can add money to the stack of Red or Blue and regardless of which team gets money from the player, the player can bet which team wins. +A team wins if it has either more than 50% or less than 25% of the total ETH sent to the team. https://github.com/ahoelzl/smartContract @@ -199,4 +188,6 @@ https://github.com/ahoelzl/smartContract ##Team -We are a team of four people. Two of us are working in the area of data science/machine learning, one PhD student in the field of formal verification and interactive theorem solving and one postdoc in the same field. +We are an international Munich based team of four people. Two of us are working as Software Engineers in the area of Data Science/Machine Learning, one is a PhD student in the field of Formal Verification and Interactive Theorem Solving and one a Postdoc in the same field. +In our opinion, this is the right mixture of academia and industry. + From 765ed2562445cf19300691ab42c5286c98e330d2 Mon Sep 17 00:00:00 2001 From: ahoelzl Date: Wed, 31 Jan 2018 21:47:32 +0100 Subject: [PATCH 24/28] Update README.md --- README.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index 85a4c7f..46f3812 100644 --- a/README.md +++ b/README.md @@ -1,9 +1,9 @@ -####Abstract +#### Abstract We propose an API for the off-chain execution of programs in the side-effect-free fragment of Haskell. This enables smart contracts to delegate gas intensive computations and thus save money. -####Idea Proposal +#### Idea Proposal As computational power on the blockchain is expensive (due to high gas consumption), it is favorable to pull computations off the blockchain. In this proposal, we want to address two problems (A and B): @@ -35,7 +35,7 @@ Before creating this proposal, we came up with countless simple single-purpose a At some point, we realized that all of those snippets are side-effect free programs, which will now serve as mere demonstrators for the proposed framework. We will briefly sketch three of them in the next section. -##Operations on numeric array +## Operations on numeric array For-loops are heavily used in Solidity but can be very expensive in terms of gas. Most of these can be compactly formulated in Haskell (example below). @@ -85,7 +85,7 @@ Another use-case could be string operations, eg. replace: In this example all “O” are replaced by “X” in the solidity string text. All other string operations in Haskell could be used in the same way. -##Date API +## Date API A third use-case is to calculate dates exactly, taking into consideration leap seconds and time zones. @@ -123,7 +123,7 @@ Independently of this feature, a wrapper function will be made available by our wrapper smart contract that takes care of converting the parameters into the right format for the iexecSubmit function. -####Roadmap +#### Roadmap Alpha: @@ -141,7 +141,7 @@ Post-release: * Documenting and communicating the API to the community. -####Component diagram +#### Component diagram Verifier @@ -163,7 +163,7 @@ Wraps the Solidity variables and the String containing the code into a String co Converts the returned result string into Solidity variables in the callback function. -####Sequential diagram of the solution +#### Sequential diagram of the solution 1. User Smart Contract calls our Wrapper Smart Contract by ForeignFunctionCall @@ -176,7 +176,7 @@ Its result is written back as the return string to the calling smart contract. 4. The Wrapper Smart Contract converts the computation’s result into the required format and returns it to the User Smart Contract. -##Bonus: a DApp smart contract with truffle tests +## Bonus: a DApp smart contract with truffle tests The following code on github includes Solidity code and truffle tests for a simple game that can be played on the Ethereum blockchain. There are two teams, Red and Blue. Players can add money to the stack of Red or Blue and regardless of which team gets money from the player, the player can bet which team wins. @@ -186,7 +186,7 @@ A team wins if it has either more than 50% or less than 25% of the total ETH sen https://github.com/ahoelzl/smartContract -##Team +## Team We are an international Munich based team of four people. Two of us are working as Software Engineers in the area of Data Science/Machine Learning, one is a PhD student in the field of Formal Verification and Interactive Theorem Solving and one a Postdoc in the same field. In our opinion, this is the right mixture of academia and industry. From 7477a54ba27cc0f655883cb9acd94fc6a3080c4c Mon Sep 17 00:00:00 2001 From: ahoelzl Date: Wed, 31 Jan 2018 21:49:39 +0100 Subject: [PATCH 25/28] Update README.md --- README.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index 46f3812..f756565 100644 --- a/README.md +++ b/README.md @@ -1,9 +1,9 @@ -#### Abstract +# Abstract We propose an API for the off-chain execution of programs in the side-effect-free fragment of Haskell. This enables smart contracts to delegate gas intensive computations and thus save money. -#### Idea Proposal +# Idea Proposal As computational power on the blockchain is expensive (due to high gas consumption), it is favorable to pull computations off the blockchain. In this proposal, we want to address two problems (A and B): @@ -75,7 +75,7 @@ Here, the values of the array bets are hardcoded, but they can come from any uin For larger arrays, the cost of RLC could be much lower than the cost of gas. -##String operations +## String operations Another use-case could be string operations, eg. replace: @@ -98,10 +98,10 @@ Other possible functions include converting string dates to Unix timestamps and The example above uses the Solidity libraries https://github.com/Arachnid/solidity-stringutils and https://github.com/pipermerriam/ethereum-string-utils for string manipulation. -####Technical Challenges/Problems +# Technical Challenges/Problems -##Getting the input data into the correct format +## Getting the input data into the correct format To use the example @@ -123,7 +123,7 @@ Independently of this feature, a wrapper function will be made available by our wrapper smart contract that takes care of converting the parameters into the right format for the iexecSubmit function. -#### Roadmap +# Roadmap Alpha: @@ -141,7 +141,7 @@ Post-release: * Documenting and communicating the API to the community. -#### Component diagram +# Component diagram Verifier @@ -163,7 +163,7 @@ Wraps the Solidity variables and the String containing the code into a String co Converts the returned result string into Solidity variables in the callback function. -#### Sequential diagram of the solution +# Sequential diagram of the solution 1. User Smart Contract calls our Wrapper Smart Contract by ForeignFunctionCall @@ -176,7 +176,7 @@ Its result is written back as the return string to the calling smart contract. 4. The Wrapper Smart Contract converts the computation’s result into the required format and returns it to the User Smart Contract. -## Bonus: a DApp smart contract with truffle tests +# Bonus: a DApp smart contract with truffle tests The following code on github includes Solidity code and truffle tests for a simple game that can be played on the Ethereum blockchain. There are two teams, Red and Blue. Players can add money to the stack of Red or Blue and regardless of which team gets money from the player, the player can bet which team wins. @@ -186,7 +186,7 @@ A team wins if it has either more than 50% or less than 25% of the total ETH sen https://github.com/ahoelzl/smartContract -## Team +# Team We are an international Munich based team of four people. Two of us are working as Software Engineers in the area of Data Science/Machine Learning, one is a PhD student in the field of Formal Verification and Interactive Theorem Solving and one a Postdoc in the same field. In our opinion, this is the right mixture of academia and industry. From 35d90007b2228f18fa678d773c876d17735f6569 Mon Sep 17 00:00:00 2001 From: ahoelzl Date: Wed, 31 Jan 2018 21:50:24 +0100 Subject: [PATCH 26/28] Update README.md --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index f756565..8a06fd7 100644 --- a/README.md +++ b/README.md @@ -35,7 +35,7 @@ Before creating this proposal, we came up with countless simple single-purpose a At some point, we realized that all of those snippets are side-effect free programs, which will now serve as mere demonstrators for the proposed framework. We will briefly sketch three of them in the next section. -## Operations on numeric array +### Operations on numeric array For-loops are heavily used in Solidity but can be very expensive in terms of gas. Most of these can be compactly formulated in Haskell (example below). @@ -75,7 +75,7 @@ Here, the values of the array bets are hardcoded, but they can come from any uin For larger arrays, the cost of RLC could be much lower than the cost of gas. -## String operations +### String operations Another use-case could be string operations, eg. replace: @@ -85,7 +85,7 @@ Another use-case could be string operations, eg. replace: In this example all “O” are replaced by “X” in the solidity string text. All other string operations in Haskell could be used in the same way. -## Date API +### Date API A third use-case is to calculate dates exactly, taking into consideration leap seconds and time zones. From 8fd11dbaf58e3e287bb14ee08569ca6b72b484d3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ond=C5=99ej=20Kun=C4=8Dar=20kuncar=40in=2Etum=2Ede?= <> Date: Wed, 31 Jan 2018 22:31:26 +0100 Subject: [PATCH 27/28] tuned --- README.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index 8a06fd7..3f2b185 100644 --- a/README.md +++ b/README.md @@ -22,14 +22,14 @@ We have to guarantee security for the providers of computational power, so that In other words, we are trying to find the sweet spot between expressiveness and security. -In our opinion, both can be achieved by allowing only the definition of side-effect free programs. Such programs are not allowed to access the internet, write to disk or call system functions. Thus, these kind of programs cannot pose a security risk for the host machine. +In our opinion, side-effect-free programs are the sweet spot in the above-mentioned optimization problem. Such programs are not allowed to access the internet, write to disk or call system functions. Thus, this kind of programs cannot pose a security risk for the host machine. Of course, such a proposal is only useful if there is a simple mechanical check for the absence of side-effects. The functional programming language Haskell provides such tools. Every function in Haskell has a unique type that reveals whether the function is side-effect free. -In order to check if the entire program is side-effect free, it is sufficient to check the type of the main function. +In order to check whether the entire program is side-effect free, it is sufficient to check the type of the main function. Before creating this proposal, we came up with countless simple single-purpose applications for the iExec challenge. At some point, we realized that all of those snippets are side-effect free programs, which will now serve as mere demonstrators for the proposed framework. @@ -41,7 +41,7 @@ For-loops are heavily used in Solidity but can be very expensive in terms of gas Most of these can be compactly formulated in Haskell (example below). By pulling the computations off the blockchain, a lot of gas and thus money can be saved. -The following shows a typical example of a for-loop in Solidity. Imagine a betting game, where each user gets a payout depending on the number of correct guesses. The Solidity script calculates the total payout for each user. +The following shows a typical example of a for-loop in Solidity. Imagine a betting game in which each user gets a payout depending on the number of correct guesses. The Solidity script calculates the total payout for each user. Let bets[i] be the number of correct guesses of User i. @@ -137,13 +137,13 @@ Release: * The parameter wrapping (eg. from uint array to string) is done in a wrapper smart contract or possibly directly in the iexecSubmit function. Post-release: -* Proofing and benchmarking the cost-efficiency of our proposed API for the three use-cases. +* Proofing and benchmarking the cost-efficiency of our proposed API for the three use-cases. * Documenting and communicating the API to the community. # Component diagram -Verifier +Verifier - takes the the input code, asks GHC, an open-source Haskell compiler, to type-check the program (if it does not type-check -> exception) and checks whether the type corresponds to a side-effect-free program (e.g., does not contain the IO monad) if not -> exception. Input: Haskell code as a string Output: The type of the function containing this code. If it is a pure function, the code can be executed. If it is not, return an exception. @@ -188,6 +188,7 @@ https://github.com/ahoelzl/smartContract # Team -We are an international Munich based team of four people. Two of us are working as Software Engineers in the area of Data Science/Machine Learning, one is a PhD student in the field of Formal Verification and Interactive Theorem Solving and one a Postdoc in the same field. -In our opinion, this is the right mixture of academia and industry. +The MAOH Team +We are an international Munich-based team of four people. Two of us are working as software engineers in the area of data science/machine learning and the other two are a PhD student and a postdoc in the field of formal verification and interactive theorem proving. +In our opinion, our team represents the right mixture of academia and industry. From ebea6a96854add1679132681187ce8c9ec7ae8e2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ond=C5=99ej=20Kun=C4=8Dar=20kuncar=40in=2Etum=2Ede?= <> Date: Wed, 31 Jan 2018 22:48:36 +0100 Subject: [PATCH 28/28] tuned --- README.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index 3f2b185..5f9a270 100644 --- a/README.md +++ b/README.md @@ -1,9 +1,9 @@ -# Abstract +## Abstract We propose an API for the off-chain execution of programs in the side-effect-free fragment of Haskell. This enables smart contracts to delegate gas intensive computations and thus save money. -# Idea Proposal +## Idea Proposal As computational power on the blockchain is expensive (due to high gas consumption), it is favorable to pull computations off the blockchain. In this proposal, we want to address two problems (A and B): @@ -98,10 +98,10 @@ Other possible functions include converting string dates to Unix timestamps and The example above uses the Solidity libraries https://github.com/Arachnid/solidity-stringutils and https://github.com/pipermerriam/ethereum-string-utils for string manipulation. -# Technical Challenges/Problems +## Technical Challenges/Problems -## Getting the input data into the correct format +### Getting the input data into the correct format To use the example @@ -123,7 +123,7 @@ Independently of this feature, a wrapper function will be made available by our wrapper smart contract that takes care of converting the parameters into the right format for the iexecSubmit function. -# Roadmap +## Roadmap Alpha: @@ -141,7 +141,7 @@ Post-release: * Documenting and communicating the API to the community. -# Component diagram +## Component diagram Verifier - takes the the input code, asks GHC, an open-source Haskell compiler, to type-check the program (if it does not type-check -> exception) and checks whether the type corresponds to a side-effect-free program (e.g., does not contain the IO monad) if not -> exception. @@ -163,7 +163,7 @@ Wraps the Solidity variables and the String containing the code into a String co Converts the returned result string into Solidity variables in the callback function. -# Sequential diagram of the solution +## Sequential diagram of the solution 1. User Smart Contract calls our Wrapper Smart Contract by ForeignFunctionCall @@ -176,7 +176,7 @@ Its result is written back as the return string to the calling smart contract. 4. The Wrapper Smart Contract converts the computation’s result into the required format and returns it to the User Smart Contract. -# Bonus: a DApp smart contract with truffle tests +## Bonus: a DApp smart contract with truffle tests The following code on github includes Solidity code and truffle tests for a simple game that can be played on the Ethereum blockchain. There are two teams, Red and Blue. Players can add money to the stack of Red or Blue and regardless of which team gets money from the player, the player can bet which team wins. @@ -186,9 +186,9 @@ A team wins if it has either more than 50% or less than 25% of the total ETH sen https://github.com/ahoelzl/smartContract -# Team +## Team -The MAOH Team +### The MAOH Team We are an international Munich-based team of four people. Two of us are working as software engineers in the area of data science/machine learning and the other two are a PhD student and a postdoc in the field of formal verification and interactive theorem proving. In our opinion, our team represents the right mixture of academia and industry.