ZeppelinOS: tools for smart contract applications(blog.zeppelin.solutions)
blog.zeppelin.solutions
ZeppelinOS: tools for smart contract applications
https://blog.zeppelin.solutions/introducing-zeppelinos-the-operating-system-for-smart-contract-applications-82b042514aa8
38 comments
Sounds interesting and important, but you probably need a new term for this category of software. "OS" is taken, and it means something else.
Also it's built on top of Ethereum Virtual Machine. Quick look at http://ethdocs.org/en/latest/introduction/what-is-ethereum.h..., which calling that a VM from what I read isn't screaming VM to me, more like a distributed computing application.
Which sense of virtual machine do you mean? There are already at least two. One is a virtualization thing like VMware. Ethereum is not that. The other sense is a bytecode interpreter/compiler like the Java Virtual Machine. Ethereum is like that. Except that it duplicates computations across many physical machines.
Also Zeppelin.
https://zeppelin.apache.org/
https://zeppelin.apache.org/
Should be OSS. What is strange is that the refer to the core of their software as a "Kernel".
OSS meaning operational support system?
how does this compare to Tezos?
Tezos and zeppelinOS are very different things. zeppelinOS is building an operating system on top of the Ethereum Virtual Machine to provide secure infrastructure for the development of smart contract applications. A technology that is still being developed but used by thousands of developers, and maturing into it's next phase.
Tezos is building a new blockchain with a different infrastructure altogether.
sounds the same as EOS
What about this is an operating system?
To avoid title disputes we'll use the word "tools" above.
It's an operating system insofar as it's a layer of services on top of the "bare metal" that is the EVM. Through those services it allows the development of complex applications in the same way a normal OS does.
How does that differ from installing a web framework, or an application? That doesn't seem like an operating system to me.
Good question. Both libraries and frameworks (the main difference between the two being the inversion of control) are addenda to your application, aimed at providing more features and building blocks to set up more complex behaviours.
zOS takes this one step further, including not only libraries for SC development, but also aiming at defining interoperability standards, mechanics and economics for having independent contracts interact between them as independent actors (or processes, if you will) on a shared computing space that is the blockchain.
I think the key here in terms of semantics is that zOS is not just an Operating System, but rather an Operating System for the blockchain. And when we go there, we don't have many definitions available, but are rather waiting to be made.
zOS takes this one step further, including not only libraries for SC development, but also aiming at defining interoperability standards, mechanics and economics for having independent contracts interact between them as independent actors (or processes, if you will) on a shared computing space that is the blockchain.
I think the key here in terms of semantics is that zOS is not just an Operating System, but rather an Operating System for the blockchain. And when we go there, we don't have many definitions available, but are rather waiting to be made.
Seems like "framework" or "library" would be better; this isn't exactly a scheduler or resource allocator in the same way an os implies.
↑↑ Check the reply above by spalladino2.
Standard 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...
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-...
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-...
Thanks for linking docs
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.
I'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.
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.
Quite the exaggeration, this silly meme has to stop. You make it sound like writing even a hello world would have horrible vulnerabilities or something. There are thousands of perfectly safe contracts deployed, one can't take some isolated incidents and make such conclusions from such a small sample.
If the creator of Solidity, Gavin Wood, cannot write a
secure multisig wallet in Solidity, pretty much confirms
Ethereum is hacker paradise.
[2] https://www.cryptocoinsnews.com/hackers-seize-32-million-in-...
That's tweet is factually incorrect.
Gavin Wood DID NOT write the change that caused that bug, he was not the assigned reviewer either. https://github.com/paritytech/parity/pull/3773
Gavin Wood DID NOT write the change that caused that bug, he was not the assigned reviewer either. https://github.com/paritytech/parity/pull/3773
Gavin Wood is the designer of solidarity and the founder of Parity.
https://en.wikipedia.org/wiki/Solidity
http://gavwood.com/
https://en.wikipedia.org/wiki/Solidity
http://gavwood.com/
Yes but that doesn't mean that they wrote this particular code. Authorship isn't transitive.
I know who Gavin Wood is. The fact is he didn't write the change the tweet claimed.
There are thousands of contracts where no vulnerabilities have been discovered yet. Mostly because there are larger targets to go after.
It's not true to say that something is secure just because it hasn't been broken yet.
I agree with your call for balance, but it's unnecessary to jump to the opposite extreme.
It's not true to say that something is secure just because it hasn't been broken yet.
I agree with your call for balance, but it's unnecessary to jump to the opposite extreme.
maybe not a hello world, but even very rudimentary 20 LoC contracts for, say, keeping account balances can have reentrancy vulnerabilities when written in the obvious way. so your customer could just give themselves an infinite balance.
i don't think it's impossible to write secure smart contracts but it takes quite a bit of care even for simple stuff.
there are many issues that arise because your functions might be called by an adversary who has set up the stack in an evil way.
i don't think it's impossible to write secure smart contracts but it takes quite a bit of care even for simple stuff.
there are many issues that arise because your functions might be called by an adversary who has set up the stack in an evil way.
Agree with this, especially with the "it takes quite a bit of care even for simple stuff", but this should not discourage developers to do so.
One of the reasons to build this kind of infrastructure is to set proper standards for smart contracts development which are currently missing.
As long as we are aware that we need to be careful, and we raise the quality of the code and keep on developing tools to improve development as a whole things should keep on moving forward.
So 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?
Would you sign a contract that references a contract that can be changed at anytime without your agreement?
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.
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.
yeah, people do this all the time, to a greater or lesser extent! referencing past or future agreements, agreements between other parties, the prime interest rate published in the WSJ, etc.
the difference is, if someone does something really abusive with one of these clauses, a judge will throw it out.
the difference is, if someone does something really abusive with one of these clauses, a judge will throw it out.