# \[Proposal\] Contract Deployment **URL:** \ **Category:** Aztec\ **Tags:** specs\ **Created:** [December 18, 2022, 4:45pm UTC](https://forum.aztec.network/t/proposal-contract-deployment/48 "2022-12-18T16:45:03Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![Mike](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/mike/32/7_2.png) [@Mike](https://forum.aztec.network/u/Mike)\ **Post date:** [December 18, 2022, 4:45pm UTC](https://forum.aztec.network/t/proposal-contract-deployment/48/1 "2022-12-18T16:45:03Z")
See [here](https://hackmd.io/IDd5U7BJRAil-XoNb4uZQA) for the latest contract creation proposal from Zac. Just opening up a discussion thread on this topic. ---
**Author:** ![Mike](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/mike/32/7_2.png) [@Mike](https://forum.aztec.network/u/Mike)\ **Post date:** [December 18, 2022, 5:02pm UTC](https://forum.aztec.network/t/proposal-contract-deployment/48/2 "2022-12-18T17:02:30Z")
From the hackmd: > ### Function Tree > > Each contract’s function data is stored in a Merkle tree, where each leaf contains a hash of the following data: > > 1. Function Signature > 2. `bool isPrivate` flag > 3. Verification Key Hash Where the ‘function signature’ in this context would be something like the first 4 bytes of the hash of the abi encoding of the function. This is a nice leaf, because we get the following: - A Noir++ contract can import another contract’s interface, and will be able to compute the function’s function signature using that interface (first 4 bytes of hash of abi encoding). - The Kernel Circuit will then be able to validate the existence of that function in this contract\*. - The function tree can be kept nice and small; e.g. 32 leaves (or however many we think is a reasonable upper bound). \ ***Just a small note** : at the time of deployment, we MUST ensure each function signature is unique, within the contract. Similarly, we must also ensure uniqueness of verification key hashes. ---
**Author:** ![jtriley-eth](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/jtriley-eth/32/70_2.png) [@jtriley-eth](https://forum.aztec.network/u/jtriley-eth)\ **Post date:** [May 4, 2023, 5:18pm UTC](https://forum.aztec.network/t/proposal-contract-deployment/48/3 "2023-05-04T17:18:24Z")
Question: Is the contract tree a sparse merkle tree as well as the public state tree? Or are the contract leaves on the public state tree? ---
**Author:** ![jtriley-eth](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/jtriley-eth/32/70_2.png) [@jtriley-eth](https://forum.aztec.network/u/jtriley-eth)\ **Post date:** [May 4, 2023, 6:02pm UTC](https://forum.aztec.network/t/proposal-contract-deployment/48/4 "2023-05-04T18:02:17Z")
Also, a note on the function signature. Is it a hard requirement that function selectors be 4 bytes? ABI compatibility with Solidity is already broken by using different underlying primitive types and function selector derivation. Because of this, I would advocate for a larger function selector size, ideally no less than 8 bytes. This is useful to reduce the odds of function selector collision within a single contract as well as reducing selector ambiguity in client-side tooling. ---
**Author:** ![david-banks](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/david-banks/32/31_2.png) [@david-banks](https://forum.aztec.network/u/david-banks)\ **Post date:** [May 4, 2023, 8:14pm UTC](https://forum.aztec.network/t/proposal-contract-deployment/48/5 "2023-05-04T20:14:42Z")
I believe the contract tree will _not_ be sparse. It will be a standard merkle tree and will be append-only. It is declared as such in code [here](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/world-state/src/world-state-db/merkle_trees.ts#L56) ---
**Author:** ![david-banks](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/david-banks/32/31_2.png) [@david-banks](https://forum.aztec.network/u/david-banks)\ **Post date:** [May 4, 2023, 8:16pm UTC](https://forum.aztec.network/t/proposal-contract-deployment/48/6 "2023-05-04T20:16:07Z")
No hard requirement on function selector size. You make a good point and we will likely choose \>4 bytes for this exact reason 👍 ---
**Author:** ![LasseAztec](https://avatars.discourse-cdn.com/v4/letter/l/90db22/32.png) [@LasseAztec](https://forum.aztec.network/u/LasseAztec)\ **Post date:** [May 4, 2023, 8:16pm UTC](https://forum.aztec.network/t/proposal-contract-deployment/48/7 "2023-05-04T20:16:07Z")
There should come more info in here [Trees | Aztec Docs](https://docs.aztec.network/aztec/protocol/trees#contract-tree), but the contracts tree is not a sparse tree. As @david-banks says, its an append-only tree to allow us to easily do batch insertions. ---
**Author:** ![LasseAztec](https://avatars.discourse-cdn.com/v4/letter/l/90db22/32.png) [@LasseAztec](https://forum.aztec.network/u/LasseAztec)\ **Post date:** [May 4, 2023, 8:21pm UTC](https://forum.aztec.network/t/proposal-contract-deployment/48/8 "2023-05-04T20:21:06Z")
There have been some discussions on function selector lengths earlier; the main thoughts were around 8 bytes and longer. I think the main reason that it was not changed already was just that no one made the PR fixing the length everywhere, as it was discussed when everything was in different repos instead of mono. ---
**Author:** ![spartucus](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/spartucus/32/126_2.png) [@spartucus](https://forum.aztec.network/u/spartucus)\ **Post date:** [June 1, 2023, 3:51am UTC](https://forum.aztec.network/t/proposal-contract-deployment/48/9 "2023-06-01T03:51:54Z")
I have a question: In doc [tree](https://docs.aztec.network/aztec/protocol/trees#contract-tree), it says: > The contract tree contains information about every function of every contract deployed to the Aztec network. This allows the Kernel Circuits to validate that for every function execution request, the requested function actually belongs to a deployed contract. How exactly does the Kernel Circuits to validate one function belongs to one deployed contract? IIUC, one circuit(pk/vk) for one function, how does contract work in this situation? ---
**Author:** ![david-banks](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/david-banks/32/31_2.png) [@david-banks](https://forum.aztec.network/u/david-banks)\ **Post date:** [June 3, 2023, 6:38pm UTC](https://forum.aztec.network/t/proposal-contract-deployment/48/10 "2023-06-03T18:38:25Z")
> [@spartucus](#): > > How exactly does the Kernel Circuits to validate one function belongs to one deployed contract? IIUC, one circuit(pk/vk) for one function, how does contract work in this situation? For reference, this kernel logic lives [here](https://github.com/AztecProtocol/aztec-packages/blob/master/circuits/cpp/src/aztec3/circuits/kernel/private/common.cpp#L116) in the `common_contract_logic` function which is called from both the [initial](https://github.com/AztecProtocol/aztec-packages/blob/master/circuits/cpp/src/aztec3/circuits/kernel/private/native_private_kernel_circuit_init.cpp#L171) and [inner](https://github.com/AztecProtocol/aztec-packages/blob/master/circuits/cpp/src/aztec3/circuits/kernel/private/native_private_kernel_circuit_inner.cpp) variations of the private kernel. There are two relevant trees here: - Contract tree: contains one leaf for each contract - Function tree: contains one leaf for every function in a specific When a user executes a private function, they will provide its proof of execution to the private kernel along with the some information about the function and contract they are calling: - Function info - For leaf computation: `function_selector`, `vk_hash`, `acir_hash` - For merkle root computation: `leaf_index`, `sibling_path` - Note that the function’s raw VK is provided as a private input to the kernel. It is then hashed in-circuit. - Contract info - Needed for leaf computation: `storage_contract_address`, `portal_contract_address` - Plus `leaf_index`, `sibling_path` We basically want to ensure the following: 1. The function’s proof is valid according to the VK provided as input 2. The function called matches an existing leaf in that contract’s function tree - This also confirms that the VK used to verify the function’s proof matches this existing function leaf 3. The contract called exists in the contracts tree So how do we do this? First off, we can verify the function proof using snark recursion and the VK provided as a private input the kernel. We compute a function tree leaf given the `function_selector`, `vk_hash` (computed in-circuit from the VK), and `acir_hash`. We can then use the provided `leaf_index` and `sibling_path` to compute the merkle root (`function_tree_root`) of this contract’s function tree. Cool so now we have a `function_tree_root`, but how do we know it’s right? Well next we can compute a contract tree leaf using this `function_tree_root` along with contract address and portal address. We then use the provided `leaf_index` and `sibling_path` to compute the merkle root (`contract_tree_root`) of the contract tree. Okay so now we have a `contract_tree_root`, but how do we know it’s right? Well we don’t… Not at this stage. The private kernel proves the numbered items above with an important exception; someone else needs to prove that this contract tree root matches a real historical root. That is the job of the rollup circuits. By this point we know that the function and its vk matches a leaf in the contract’s function tree. We know that the function’s execution is valid according to that vk. And we know that the contract along with the root of this function tree match a leaf in some contract tree. We then put off the job of verifying that contract tree root until a later stage. ---
**Author:** ![david-banks](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/david-banks/32/31_2.png) [@david-banks](https://forum.aztec.network/u/david-banks)\ **Post date:** [June 4, 2023, 4:00pm UTC](https://forum.aztec.network/t/proposal-contract-deployment/48/11 "2023-06-04T16:00:43Z")
TLDR: A contract is basically a function tree (including VKs) along with an address that is used to silo storage accesses. We validate that a function belongs to a deployed contract by doing merkle membership proofs for the function in the contract’s function tree, and the contract in the contract tree. ---
**Author:** ![spartucus](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/spartucus/32/126_2.png) [@spartucus](https://forum.aztec.network/u/spartucus)\ **Post date:** [June 5, 2023, 6:50am UTC](https://forum.aztec.network/t/proposal-contract-deployment/48/12 "2023-06-05T06:50:36Z")
> [@david-banks](#): > > And we know that the contract along with the root of this function tree match a leaf in some contract tree. We then put off the job of verifying that contract tree root until a later stage. Thanks for detailed reply, it makes much sense! Is `acir_hash` a commitment of deployed bytecode for function/contract? ---
**Author:** ![david-banks](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/david-banks/32/31_2.png) [@david-banks](https://forum.aztec.network/u/david-banks)\ **Post date:** [June 5, 2023, 2:10pm UTC](https://forum.aztec.network/t/proposal-contract-deployment/48/13 "2023-06-05T14:10:06Z")
That’s right! I’m not sure if it needs to be calculated in-circuit for private functions. We will need to perform some bytecode validation for public functions though since Sequencers and Provers are responsible for executing public function bytecode. @Mike may be able to provide some more insight here.