Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think most developers know not to eval()

Why would you execute arbitrary text in any other languages?



Your parallel is not an accurate one.

One of the key and powerful features of the Ethereum Virtual Machine or, EVM, is the ability to delegate execution to external libraries. You can think of this much the same way you think of installing 3rd party libraries in your favorite programming language of choice.

In the EVM you can write a "library" which performs some common functionality such as manipulation of date-time objects much like the `datetime` library in Python. Any other contract may then make use of this code simply by delegating execution to the deployed library address. This has inherent risks that every Ethereum developer should understand fully, but with that risk comes some incredible power and potential.

There currently is no "Standard Library" for the EVM but it is looking very likely that it will be comprised of this type of contract. Slowly, overtime, these library contracts will be written and deployed to the network. There is work being done on using theorem solvers to mathematically prove that a contract satisfies certain properties which opens the door to a "provably correct" standard library.

I know of no other computing environment or packaging system that has these properties. For me, it has been an enlightening subject and I feel like we've only just scratched the surface.


The parallel is totally damn right. eval with an unverified user input.

> _walletLibrary.delegatecall(msg.data)

Dunno how much contracts in the wild have such brilliant feature.


A serious question: are the benefits really worth it? How much overhead would it be to just include the library code directly into the contracts instead (so that the whole thing can be verified as a single black box)?


I think the answer to that question is extremely contextual and going to be very different for different applications. I also think that

I'd like to point out that the idea of including the library code within the contract is untennable at a certain level as contracts currently have an upper limit on size which is determined by the block gas limit. It also doesn't make it any safer because it's still functionally the same as executing external code because it's the same code being executed.


Its not really worth it. Very over complicated. Really they just need to do code/data deduplication on chain somehow and forget about using contracts as libraries in this way.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: