For those not in the jumbucks slack, here's a snippet from today.
Julian:
There are 2 issues and items of contention with smart contracts and the Ethereum approach of adding a Virtual Machine to the processing of Nodes.
*1) Smart contracts are too complicated and will fail with security issues*
The main case study here is The DAO contract. I would say this serves as a warning and now in retrospect serves as an example of “what not to do”. This is similar to normal code and programs that we run. Take for instance the internet and web applications/sites.
Any web site is open to hacks. The more functionality you add, the complexity you have and the increased attack surface.
Here are the counter arguments:
Smaller code is easier to audit.
We need standards and best practices for writing smart contracts.
We should not try to do too much too soon in this evolution.
The example is the code used for ERC: 20 Token Standard -
https://github.com/ethereum/EIPs/issues/20This is well documented, standardized and openly deployed smart contract code. This is something we should not fear.
There is also this project:
https://openzeppelin.org "Zeppelin is a community effort to build secure smart contracts in blockchain systems.”
*2) Adding a Virtual Machine increases the attack surface and is causing issues with nodes*
Firstly, the Virtual Machine is acknowledged as a feature and it isn’t going away. It adds more functionality to a blockchain so adding functionality will always be negatively referred to as “increasing the attack surface”.
The main mechanism for controlling the VM is gas cost. For all intents and purposes, this is similar to a transaction fee.
The theory is that CPU cycles should match closely gas cost. If a VM function is “too cheap” to run and conversely expends a lot of CPU cycles, then we have an issue. Note that this is a previously known and acknowledged issue (
https://blog.ethcore.io/onwards/) that will be addressed in the protocol.
Where the shift in thinking occurs is with the question “Is this something that is inherently bad and flawed or is it something we can address?”
Myself as well as many others believe this is something which can be resolved long term
Luke(me):
this is why i plan to focus on small modules at the beginning, that alone achieve nothing for the end user, but provide a robust, well tested, and standardized framework to build more complex contracts on top of. these modules (for lack of a better name) will be much like libraries in a programming language. an example i often refer to is a random number generator, which is hugely important for cryptographic functions, having a well tested random module, that other contracts can use, means the contract devs dont need to create their own random code, significantly lowering the chances of any issues regarding random seeds etc (bad random code can be predictable, not good). the idea behind this approach is to a) ensure more complex contracts are using standardized, and well tested code for a lot of their functions, and b) make it easier and faster to dev more complex contracts, resulting in a rich development environment.
Instead of focusing on a single complex contract/dapp, like other projects in this space, we plan to focus on the platform itself. no point building a website if the internet is flaky. build a better internet first, then worry about websites.
