Truffle: Ethereum Dapp Development Framework(truffleframework.com)
truffleframework.com
Truffle: Ethereum Dapp Development Framework
http://truffleframework.com/
55 comments
I’m a pretty experienced solidly / ethereum developer, and a developer with 13 years experience in vast array of systems and languages (from embedded C on ppc to high performance c++ and now deep learning and scientific computing in python). I completely agree with you, that there’s some very odd language choices in solidity, seemingly rookie mistakes, and the tooling is very poor. But! It’s the 1.0 of crypto. Early C stuff was poor, early html development was poor, early OpenGL development was poor, it’s just new.
I see it as a lot of room for opportunity, but I could also see how it could be frustrating to some more senior people - but I have found part of growing old and seeing things constantly get re-invented but slightly different are windows of opportunity - so I get excited
I see it as a lot of room for opportunity, but I could also see how it could be frustrating to some more senior people - but I have found part of growing old and seeing things constantly get re-invented but slightly different are windows of opportunity - so I get excited
There was a semi-joke post on HN a while back where someone created a 'pyramid' lispy language using Racket, which complied to solidity.
But in seriousness, a Haskell -> solidity compiler, might make it bearable.
But in seriousness, a Haskell -> solidity compiler, might make it bearable.
Solidity is a complex moving target with limitations such as max 16 local variables, missing optimizations and only partial support for dynamic allocation.
You might want to compile directly to EVM instead of through Solidity. The EVM is very simple, as far as virtual machines go. It's fully documented in [the yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf) and only changes with hardforks (and then only incrementally in a backwards compatible way).
Smart contract development feels like embedded systems development. Every instruction has a significant cost associated to it. There are different memory spaces like a Harvard architecture (code, memory, storage, input, output, other peoples code). Like embedded systems, you need to be absolutely sure your code is correct before you deploy, as updates are impossible and a lot of economic value depends on correctness.
But contrary to embedded systems it has 256 bit registers, 256 bit address space and SHA3 as a cheap instruction. This means that if you pick a 'random' hash, you can safely assume it's free! Hashtables in Solidity are implemented like this.
Recently I've been doing some combined Solidity/EVM-assembly that I wrote about [here](https://medium.com/wicketh/mathemagic-chinese-remainder-theo...). I'll post more this month doing some advanced tricks in Solidity/EVM.
You might want to compile directly to EVM instead of through Solidity. The EVM is very simple, as far as virtual machines go. It's fully documented in [the yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf) and only changes with hardforks (and then only incrementally in a backwards compatible way).
Smart contract development feels like embedded systems development. Every instruction has a significant cost associated to it. There are different memory spaces like a Harvard architecture (code, memory, storage, input, output, other peoples code). Like embedded systems, you need to be absolutely sure your code is correct before you deploy, as updates are impossible and a lot of economic value depends on correctness.
But contrary to embedded systems it has 256 bit registers, 256 bit address space and SHA3 as a cheap instruction. This means that if you pick a 'random' hash, you can safely assume it's free! Hashtables in Solidity are implemented like this.
Recently I've been doing some combined Solidity/EVM-assembly that I wrote about [here](https://medium.com/wicketh/mathemagic-chinese-remainder-theo...). I'll post more this month doing some advanced tricks in Solidity/EVM.
Suboptimal smart contracts directly incur unnecessary transaction costs for users, and it's hard to imagine that Haskell as a source language would translate to efficient EVM bytecode.
For one, do you really want to have a lazy evaluation runtime compiled into your multisig? Now do you want to prove the correctness of that runtime? ...
I don't think Haskell is anywhere near a good source language for Ethereum smart contracts, if you think of it as "compiling Haskell".
There was a master's thesis about compiling Idris to EVM, and it also shows that the performance problems are difficult indeed even without laziness.
https://publications.lib.chalmers.se/records/fulltext/234939...
But I do think it's very interesting to think of Haskell as a powerful metalanguage for defining smart contracts that then get compiled to EVM.
Other examples of Haskell as a DSL environment for generating more restricted programs:
https://hackage.haskell.org/package/accelerate
http://ku-fpg.github.io/software/kansas-lava/
http://www.clash-lang.org/
Quote from the Kansas Lava site:
Kansas Lava is a Domain Specific Language (DSL) for expressing hardware-oriented descriptions of computations, and is hosted inside the language Haskell. Kansas Lava programs are descriptions of specific hardware entities, the connections between them, and other computational abstractions that can compile down to these entities. Large circuits have be successfully expressed using Kansas Lava, and Haskell’s powerful abstraction mechanisms, as well as generic generative techniques, can be applied to good effect to provide descriptions of highly efficient circuits.
That's an approach I think is much more appropriate for the strengths and weaknesses of Haskell!
As it happens, we've started very modestly at using Haskell like this. At the moment we only have a simple monadic assembler that lets you write EVM code. See this example:
https://github.com/dapphub/ds-weth/blob/master/src/weth4.hs
Of course we want to take this further and find some more abstractions for cleanly expressing actual smart contract patterns...
For one, do you really want to have a lazy evaluation runtime compiled into your multisig? Now do you want to prove the correctness of that runtime? ...
I don't think Haskell is anywhere near a good source language for Ethereum smart contracts, if you think of it as "compiling Haskell".
There was a master's thesis about compiling Idris to EVM, and it also shows that the performance problems are difficult indeed even without laziness.
https://publications.lib.chalmers.se/records/fulltext/234939...
But I do think it's very interesting to think of Haskell as a powerful metalanguage for defining smart contracts that then get compiled to EVM.
Other examples of Haskell as a DSL environment for generating more restricted programs:
https://hackage.haskell.org/package/accelerate
http://ku-fpg.github.io/software/kansas-lava/
http://www.clash-lang.org/
Quote from the Kansas Lava site:
Kansas Lava is a Domain Specific Language (DSL) for expressing hardware-oriented descriptions of computations, and is hosted inside the language Haskell. Kansas Lava programs are descriptions of specific hardware entities, the connections between them, and other computational abstractions that can compile down to these entities. Large circuits have be successfully expressed using Kansas Lava, and Haskell’s powerful abstraction mechanisms, as well as generic generative techniques, can be applied to good effect to provide descriptions of highly efficient circuits.
That's an approach I think is much more appropriate for the strengths and weaknesses of Haskell!
As it happens, we've started very modestly at using Haskell like this. At the moment we only have a simple monadic assembler that lets you write EVM code. See this example:
https://github.com/dapphub/ds-weth/blob/master/src/weth4.hs
Of course we want to take this further and find some more abstractions for cleanly expressing actual smart contract patterns...
> early html development was poor,
what you got against <blink>?
what you got against <blink>?
Couple years(?) back, i stumbled upon this blog post about the origin of <blink>
http://www.montulli.org/theoriginofthe%3Cblink%3Etag
Could you touch on what you find are the short comings of solidity?
> But! It’s the 1.0 of crypto.
What will(is) the crypto 2.0 ?
What will(is) the crypto 2.0 ?
EOS.
state-regulated crypto currencies. It might sound strange, but Russia might be the first country that starts this practice. I wouldn't be surprised if Mr. Putin will make it part of his play book for the upcoming presidential elections. When it might be China. Once USA will throw Mr. Trump out of the WH and the sane person will rule the country, they will want to regulate crypto as well.
What do you think of viper?
What do you think about other blockchain related projects, like exonum or eos?
I believe a huge barrier to entry is the lack of accurate, concise documentation.
I did my fair share of solidity development myself and it was hard for me to find references on simple basic development on the platform. Diff ways to setup, diff sandboxes, no proper introduction of the tools, etc.
I did my fair share of solidity development myself and it was hard for me to find references on simple basic development on the platform. Diff ways to setup, diff sandboxes, no proper introduction of the tools, etc.
What's your take on these? http://truffleframework.com/docs/
I had the exact same experience, joined a project which was relying upon Ethereum. Spent several days learning everything about it and messing with the technology. Every moment the interest slowly waned as frustration upon frustration added up into a realization that this tech is nowhere near ready to base huge important projects off of it.
I generally agree with you, but would like to know about your specific concerns, what did you dislike about it?
Here were mine
Here were a few of mine, I’ve tried to get into ethereum a couple times
- installing mist and getting it to sync is very difficult and time consuming
- connecting to a testnet and getting ether on the testnet is also very difficult
- most ‘cool’ dapp ideas rely on oracles to publish data about the real world into the block chain. When you dive into it you realize that such an Oracle would be very very expensive to run for even trivial usecases.
- installing mist and getting it to sync is very difficult and time consuming
- connecting to a testnet and getting ether on the testnet is also very difficult
- most ‘cool’ dapp ideas rely on oracles to publish data about the real world into the block chain. When you dive into it you realize that such an Oracle would be very very expensive to run for even trivial usecases.
> most ‘cool’ dapp ideas rely on oracles to publish data about the real world into the block chain. When you dive into it you realize that such an Oracle would be very very expensive to run for even trivial usecases.
how much does it cost to run an Oracle?
how much does it cost to run an Oracle?
Depends greatly on the problem domain.
For example, if the problem domain is football games and gambling, well, scraping the results of those games from existing apis isn't too hard nor expensive.
If it's based on real-world stuff with no existing consistent API (e.g. you want a app based on housing), you'll either need to build that API, find a company to research and enter the data, etc.
For example, if the problem domain is football games and gambling, well, scraping the results of those games from existing apis isn't too hard nor expensive.
If it's based on real-world stuff with no existing consistent API (e.g. you want a app based on housing), you'll either need to build that API, find a company to research and enter the data, etc.
What's the point of building the app on Ethereum if the source (the Oracle) is centralized anyway?
There are implementations like Chainlink running decentralized oracles. At the end of the day, the data-source is still the bottleneck but they try to discourage bad actors through e.g. reputation mechanisms.
Okay, how much cost will it cost to run an Oracle for some existing API?
An Oracle is just a program that movies data onto the blockchain for dapps to use.
The data is an input to a transaction that eventually results in the EVM storing that data into a contracts (dapps) memory (which you pay per byte) that can then be exposed to other dapps.
The data is an input to a transaction that eventually results in the EVM storing that data into a contracts (dapps) memory (which you pay per byte) that can then be exposed to other dapps.
Thank for that explanation. How much would you say a simple Data input will cost?
So both instructions and memory uses something called gas. Right now 1 gas = 0.00000002 eth.
Now a MUL costs 5 gas and a ADD costs 3 for example. So you have to pay for contract complexity.
Now memory costs are not linear. The current gas cost equation for memory is Gmem * a * (a^2/512) where Gmem is a constant that is currently 3 and 'a' is the number of 255bit words (ints) you are storing.
This is for EVM internal memory that can later be accessed by the smart contract or other contracts. There is a way for contracts to output data that can be read out-of-band called logs but that is for getting data out of the EVM, not in.
Now a MUL costs 5 gas and a ADD costs 3 for example. So you have to pay for contract complexity.
Now memory costs are not linear. The current gas cost equation for memory is Gmem * a * (a^2/512) where Gmem is a constant that is currently 3 and 'a' is the number of 255bit words (ints) you are storing.
This is for EVM internal memory that can later be accessed by the smart contract or other contracts. There is a way for contracts to output data that can be read out-of-band called logs but that is for getting data out of the EVM, not in.
You have to conceptualise ethereum as a market communication bus to exchange business information between autonomously acting market partners. Nothing more nothing less.
Smart contracts encapsulate market logic, i. e. the stuff where market partners have a need to verify that the information (or value) shared was/is processed exactly as specified.
The key insight is to limit your utilisation of smart contracts to this type of application. You want to keep your smart contract super simple and focused on doing only one thing. Also note that marktet logic is almost always just a tiny fraction of the overall business logic of whatever you are building. So there will always be this other place where you develop the rest of your app with more traditional means (e. g. Javascript)
To integrate the blockchain powered market communication bit into your app, you simply wrap your deployed smart contracts into a software wallet such as ethters.js. This makes the solidity methods available in you application as simple js functions via dot notation for example.
Here is an implementation of this: https://github.com/energychain/StromDAO-BusinessObject
you can just `require` the business object in you app and have access to 30 or so smart contracts that fire into a PoA blockchain network called Fury. Its actually quite simple. Take a look at the tests in the github repository. You can even trigger smart contract factories to mint your own preconfigured contracts if need be.
Here is an other example. A subset of the same smart-contracts but implemented withing a command line tool:
https://github.com/energychain/BusinessObject-MeterPointOper...
What you end up with then is a rather traditional app that 'composes' smart contracts to read and write stuff into/out of a blockhain network where appropriate.
Smart contracts encapsulate market logic, i. e. the stuff where market partners have a need to verify that the information (or value) shared was/is processed exactly as specified.
The key insight is to limit your utilisation of smart contracts to this type of application. You want to keep your smart contract super simple and focused on doing only one thing. Also note that marktet logic is almost always just a tiny fraction of the overall business logic of whatever you are building. So there will always be this other place where you develop the rest of your app with more traditional means (e. g. Javascript)
To integrate the blockchain powered market communication bit into your app, you simply wrap your deployed smart contracts into a software wallet such as ethters.js. This makes the solidity methods available in you application as simple js functions via dot notation for example.
Here is an implementation of this: https://github.com/energychain/StromDAO-BusinessObject
you can just `require` the business object in you app and have access to 30 or so smart contracts that fire into a PoA blockchain network called Fury. Its actually quite simple. Take a look at the tests in the github repository. You can even trigger smart contract factories to mint your own preconfigured contracts if need be.
Here is an other example. A subset of the same smart-contracts but implemented withing a command line tool:
https://github.com/energychain/BusinessObject-MeterPointOper...
What you end up with then is a rather traditional app that 'composes' smart contracts to read and write stuff into/out of a blockhain network where appropriate.
Ethereum is limited. If you ran into limits with solidity then you ran up against the limits of Blockchain tech as we enter 2018. Use those limits as programming puzzles and go create something great. I find the limitations make me more creative. Solidity has some funkyness and that will get resolved, but there is still a ton you can do with it.
I had so much issue also. Getting unit tests working with Truffle was a real pain. There is a serious lack of good, concise and clear documentation.
Glad I'm not insane, spent a long haul flight digging into Solidity docs and truffle and it seemed like a minefield of trouble to build crippled applications.
Heh, you think that now, was trying almost two years ago and it was rather arduous. It's improved some though not by a ton.
I've only tried some small things with it, but ever understanding what it was trying to do two years ago was a major challenge. Not Urbit-level esoteric, but in the same realm.
At least now it's more or less coherent with some good intros and good tutorials.
One thing I do like is having a meaningful incentive to be efficient. Kinda like my earliest days fiddling with assembler as a kid.
At least now it's more or less coherent with some good intros and good tutorials.
One thing I do like is having a meaningful incentive to be efficient. Kinda like my earliest days fiddling with assembler as a kid.
I feel the same way. I find it hard to get started even with truffle. I wish there were more blog posts and examples
[deleted]
Another confusing name, it has nothing to do with Truffle - part of Graal Java compiler... https://github.com/graalvm/graal/tree/master/truffle
It's not as bad as "Riot" (at least 3 projects with this name), but seriously, are we running out of words to name projects?
It's not as bad as "Riot" (at least 3 projects with this name), but seriously, are we running out of words to name projects?
Swarm is another overly-common one :)
But really, what does any brand name have to do with what its product actually does? Microsoft might be the most important exception LOL.
But really, what does any brand name have to do with what its product actually does? Microsoft might be the most important exception LOL.
Do people not Google their potential names or what?
Apparently not.
Jade/Pug comes to mind. Pug (the HTML templating language) was originally called Jade.
Jade is already a programming language (well, whole environment) made by Jade Software in New Zealand. They literally took the name of another programming language.
Jade/Pug comes to mind. Pug (the HTML templating language) was originally called Jade.
Jade is already a programming language (well, whole environment) made by Jade Software in New Zealand. They literally took the name of another programming language.
Yeah... I thought this would be something about Graal/Truffle and Ethereum...
Anyone who is interested in getting started in Ethereum coding may want to start with this:
https://cryptozombies.io/
https://cryptozombies.io/
Thanks for the mention. One of the devs here, if anyone has questions on getting started on Solidity ask here
Do you know if there’s anyway to create integration tests via Solidity / without learning JavaScript?
You can use web3.py (https://github.com/ethereum/web3.py) to interact with Solidity contracts using Python. I'm looking into using it instead of truffle/web3.js so I can stick with a Python stack.
I tried truffle for one project, but found Embark [777] more flexible and better designed.
[777] https://github.com/iurimatias/embark-framework
[777] https://github.com/iurimatias/embark-framework
What did you like better about embark?
* plugin system
* console & web console
* dealing with testrpc and tests is much easier in embark
* better documented and more configurable
* embark CLI more powerful and has help, while truffle almost doesn’t
* truffle has so many trivial bugs that are unresolved for months, usually no even word in reply from developers. Embark developers seem to fix bugs faster.
* integration with IPFS, Whisper OOB.
* probably forgot something else important. Overall experience is so much better with Embark.
* console & web console
* dealing with testrpc and tests is much easier in embark
* better documented and more configurable
* embark CLI more powerful and has help, while truffle almost doesn’t
* truffle has so many trivial bugs that are unresolved for months, usually no even word in reply from developers. Embark developers seem to fix bugs faster.
* integration with IPFS, Whisper OOB.
* probably forgot something else important. Overall experience is so much better with Embark.
It is a great framework to develop on, but we had some challenges using MetaMask with it. Lots of room for growth, has serious potential.
I also tried to develop with Truffle but after a few hours I decided to avoid it and really start learning all the internals without a framework. To this day I haven't had the need to use Truffle at all to develop the majority of my projects.
How do you do unit testing?
I came away with my initial enthusiasm completely dashed. I can't for the life of me imagine why any sane developer would ever want to work within the constraints of Ethereum. It just doesn't seem to me anywhere near ready for any kind of serious development, or even trivial development for that matter.
I'd love to hear rebuttals to this. Is anyone out there doing anything interesting with this platform?