ZeppelinOS: tools for smart contract applications
blog.zeppelin.solutions
ZeppelinOS: tools for smart contract applications
1–10 of 39 posts
Re: ZeppelinOS: tools for smart contract applications
#2Standard peer reviewed libraries for the new world of smart contracts is sorely needed. Hopefully the increased complexity does not increase the gas costs of the contracts too much. I think most devs would trade higher gas costs for a more secure platform to develop on. Anyone who lost funds in the parity wallet hack would probably agree.
https://www.coindesk.com/30-million-ether-reported-stolen-pa...
Re: ZeppelinOS: tools for smart contract applications
#3Standard peer reviewed libraries for the new world of smart contracts is sorely needed. Hopefully the increased complexity does not increase the gas costs of the contracts too much. I think most devs would trade higher gas costs for a more secure platform to develop on. Anyone who lost funds in the parity wallet hack would probably agree. https://www.coindesk.com/30-million-ether-reported-stolen-pa...
Exactly. If a higher level of security and robustness of the platform is not achieved we will continue to see hacks like the Parity one over and over again.
This is one of the main drivers for building zeppelinOS.
Re: ZeppelinOS: tools for smart contract applications
#4I'm a big fan of Zepplin devs and the open source work they have been putting out there since the early days. Their medium posts are a goldmine for any beginner developer looking to develop DAPPs.
Re: ZeppelinOS: tools for smart contract applications
#5So if I read this right, I am supposed to trust a contract that sits on top of a mutable 'OS' that is managed by the community? I feel like all of these contract-as-code groups really need to have a lawyer on their team as well; for some reason, it seems like developers believe they understand the purpose of financial/other contracts and how they're actually used.
Would you sign a contract that references a contract that can be changed at anytime without your agreement?
Re: ZeppelinOS: tools for smart contract applications
#6So if I read this right, I am supposed to trust a contract that sits on top of a mutable 'OS' that is managed by the community? I feel like all of these contract-as-code groups really need to have a lawyer on their team as well; for some reason, it seems like developers believe they understand the purpose of financial/other contracts and how they're actually used. Would you sign a contract that references a contract…
You're ignorant of how of how contracts work.
Once a contract is published and referenced, it is impossible to change.
Therefore I can read Solidity source with my own eyes and agree to use it, at that point in time.
This place is now what Slashdot was a few years ago. Thanks for your ignorant comment
Re: ZeppelinOS: tools for smart contract applications
#7So if I read this right, I am supposed to trust a contract that sits on top of a mutable 'OS' that is managed by the community? I feel like all of these contract-as-code groups really need to have a lawyer on their team as well; for some reason, it seems like developers believe they understand the purpose of financial/other contracts and how they're actually used. Would you sign a contract that references a contract…
First of all, upgrades are opt-in, so you can build on top of the OS and only switch to a new kernel version under certain conditions, such as if all parties in the contract agree.
Also, keep in mind that financial contracts are not subject to hacks, unlike smart contracts, as we have seen several times. One of the goals of upgradeability is the possibility to roll out security patches as needed.
Re: ZeppelinOS: tools for smart contract applications
#8how does this compare to Tezos?
Re: ZeppelinOS: tools for smart contract applications
#9Standard peer reviewed libraries for the new world of smart contracts is sorely needed. Hopefully the increased complexity does not increase the gas costs of the contracts too much. I think most devs would trade higher gas costs for a more secure platform to develop on. Anyone who lost funds in the parity wallet hack would probably agree. https://www.coindesk.com/30-million-ether-reported-stolen-pa...
> Hopefully the increased complexity does not increase the gas costs of the contracts too much
It's possible to save gas by pulling in libraries' code into the contracts via the "internal" keyword [0]. This way JUMP will be used instead of DELEGATECALL.
Peer reviewed libraries will definitely help to make the platform more secure. However, the engineers decide whether to use libraries or not. What's needed is more discipline and willingness to raise the overall quality level of smart contracts and DApp development.
Writing software that handles money is different from some random web app, where bugs can be quickly fixed. We see some ICOs using OpenZeppelin [1] for their contracts, using practices like continuous integration and measurement of code coverage. However, we need much more quality-oriented practices to become widespread like mutation testing. In the current environment, developers are often more motivated to participate in bug bounties or exploit already deployed code, rather than contribute to the ecosystem/tooling.
[0] http://solidity.readthedocs.io/en/develop/contracts.html#lib...
[1] https://medium.com/@bocytko/would-you-trust-your-money-to-a-...
Re: ZeppelinOS: tools for smart contract applications
#10I'm a big fan of Zepplin devs and the open source work they have been putting out there since the early days. Their medium posts are a goldmine for any beginner developer looking to develop DAPPs.
it's pretty hard to write even a simple smart contract that doesn't have horrible vulnerabilities. far harder, I would say, than writing C code that can't be buffer-overflowed on an old system with no protections in place. and solidity the language does NOT make this any easier. read all the resources you can. there are really counterintuitive best practices.
the reason for all these hacks is not stupidity or laziness of the developers. the EVM execution model just makes it very easy to write vulnerable code.