# Proposal: abstracting contract deployment **URL:** \ **Category:** Aztec\ **Created:** [November 27, 2023, 8:46pm UTC](https://forum.aztec.network/t/proposal-abstracting-contract-deployment/2576 "2023-11-27T20:46:32Z")\ **Posts on this page:** 1\ **Showing post:** 10
**Author:** ![spalladino](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/spalladino/32/32_2.png) [@spalladino](https://forum.aztec.network/u/spalladino)\ **Post date:** [November 29, 2023, 10:50pm UTC](https://forum.aztec.network/t/proposal-abstracting-contract-deployment/2576/10 "2023-11-29T22:50:35Z")
> [@Mike](#): > > (Please keep the criticisms coming!) Spent a few more hours on this and couldn’t find a flaw. I was going to point out that contract class data (ie bytecode) may be too big for conventional events. But then I checked how we’re handling it today: we are simply not validating it. And to validate it, it’ll need to go through the same flow as events. Maybe there’s a difference regarding how we’d commit to it…? The one other thing that bothers me is that, by placing everything in the nullifier tree, which grows _a lot_ faster than contract classes and instances, we may end up with more expensive merkle membership proofs whenever we need to lookup the bytecode to run for a given function. And if we implement [nullifier epochs](https://forum.aztec.network/t/reducing-nullifier-set-state-growth/155) this means that every client will need to store the old frozen trees that include the nullifiers for the contracts they need to run. Keeping contract classes and instances on a separate tree means we probably don’t need epochs for that tree, or at least we change them far less frequently. --- _[View the full topic](https://forum.aztec.network/t/proposal-abstracting-contract-deployment/2576)._