Suggestions for EVM package

Have an idea for an EVM package? Building an EVM package? Here’s the place to talk about ideas, projects in progress and anything else related to EVM packages!

1 Like

Hi there! I have unfinished implementation of AVL Tree on Solidity. Wanted to create EVM package. Feel free to contribute, as I have no time now. Thanks!

1 Like

Hello Zeppeliners! I’ve been brainstorming some ideas for EVM packages that the community might want to try their hand at whipping up and I wanted to share a few thoughts:

When considering what might make for a good EVM package, there are a few questions to keep in mind:

Could this work as a library? (Would it work better as a library?)
Is it something you might want to upgrade at some point? (point your proxy to a new implementation)

A good example of this might be SafeMath versus ERC20. SafeMath works better as a library, as it doesn’t need to keep any state of it’s own while ERC20’s do need to keep state (A list of who owns what tokens) and thus this state you would want to store inside the proxy contract.

One source of ideas I always like to look at is the fantastic resource:

They have many easy to understand examples for projects on Ethereum, many of which would not be so difficult to create an EVM package from. I may try my hand at a few of them myself!

If anyone is interested, I converted OpenZeppelin-solidity’s SafeMath library into an EVM package.
It’s not what I would particularly recommend doing (indeed I’ll have a post coming out soon that kind of argues against doing it) but I got curious and decided to do it anyway.

Basically, I changed the internal functions into external functions, so now you can call it externally.

You call it the same way you would make an external call to a normal contract. Just, in this case, you use it for doing, well, safemath. :slight_smile:

Don’t use it for anything production. All I changed what the functions from internal to external, but of course now it’s no longer “audited” or default ‘secure’ in anyway. (You’ve been warned!) It’s not what I would consider a very ‘useful’ EVM package, but it might get someone thinking anyway!

Let me know if you’re interested in documentation and I’ll add it! (A touch busy at the moment preparing for ETHDenver)

1 Like

Now that ETHDenver has finished, we had two projects that built EVM packages that I wanted to share.

Super Random - an EVM package to generate secure random numbers. There are two versions- a “decent” version which returns a ‘reasonably random’ number that can only slightly be influenced by miners, and a “Super Random” which uses a novel process to generate much more secure random numbers. A great example of a EVM use case. It’s hard to generate random numbers but now if you simply plug into SuperRandom they are easy.

Lambdeth - is a functional programming library. It’s very cool and I think might start to point the way towards what we can start building with EVM packages that bring traditional functional programing tools to Solidity.

1 Like

Hey Dennison thanks for the mention(my partner and I hacked on Lambdeth at ETHDenver.) We’re going to get it registered as a ZeppelinOS package in the next day or two here now that the dust has settled from the hackathon. We plan to continue fleshing out the library and hopefully start exposing methods for types other than uint although first we will do some gas cost profiling and attempt to optimize the initial map and filter methods :slight_smile:


Sounds good! Let me know if you need any help with getting registered as a ZeppelinOS package.

Also, gas profiling is very good to do- however in my personal opinion in the future gas costs will eventually matter less and less (for example at ETHDenver everyone was in love with xDai which is essentially super cheap regardless). My point being- as contracts are upgradable, don’t let gas profiling be a blocker to adding new functions. I personally really like the Lambdeth idea and hope to see more methods on this library!

Ah interesting with respect to the future of gas prices, I hadn’t really considered the power of future scaling to really reduce the gas footprint of something like Lambdeth.

I also just wanted to drop two more ideas in here that came up at ETHDenver before I forget them - a type casting library (one problem we ran into with Lambdeth is teasing uints and bools out of bytes,) and starting to build out some data structure providers (I think half the people I talked to implemented their own Linked List structures.) I’ll probably take a look at a type casting lib sooner than later and get some of that logic out of Lambdeth (currently implemented as private methods - one to cast bytes to uint and another that wraps the uint cast method and returns a bool from a bytes input.)

Sounds good! Let us know if you need anything! :slight_smile:

Hi guys, I needed a way to trigger an event after being paid. That being, saving a user file on IPFS after they paid a fee.
So I tough of a smart contract that will forward the eth it receives to the recipient, it will also trigger an event, with the information passed, where the listening page can react to. This allows for the construction of webpage service that reacts to payment without the need to deploy its own ethereum logic.

Not only end users could use it but other contracts to notify payments between each other.

Am I overcomplicating things? does it make sense to make an EVM out of it? I would love to hear your opinion. Thanks!

I think that could make a really cool EVM package! I would say do it! We’re here if you need any help, so feel free to ask any questions!

1 Like

After searching around I found some really neat sol implementations of good tools:

The latter is slightly incomplete I think but I’d love to see these implemented as EVM packages.

1 Like

great ideas! thanks :slight_smile: