doc: Off chain contract registry

[spalladino]

Adds a proposal for an off-chain contract registry.

[iAmMichaelConnor]

I guess I see these paths:

1. The private function bytecode was broadcast to L1, so every PXE should be able to download that (via a query to a full node or some other service).
2. The private function bytecode wasn't broadcast to L1, but it was uploaded to some central repo. It sounds like that's what this proposal is suggesting?
3. The dapp injects any private bytecode that it might need. Note: a dapp might not know all such bytecode, if the call stack is only determined at runtime - in which case the tx might not be executable.
4. The private function bytecode needs to remain private between a small group of people (e.g. two companies writing up a private contract). In this case, they need to share the bytecode through some private messaging channel and inject the bytecode into their PXE. I guess this is identical to the 'dapp' use case above; it's just this dapp is very private.
5. The private bytecode isn't available anywhere. The tx isn't executable. RIP.

So I think this proposal nicely satisfies 2, iiuc?

[spalladino]

Exactly! It's equivalent to 1 in that it's made available for everyone, but it's cheaper since it doesn't take up DA.

[PhilWindle]

Remind me again what would go in here? Is it simply the class id, the initialisation args/hash, deployer address etc?

[spalladino]

Exactly!

salt
deployer
contractClassId
initializationHash
publicKeysHash

[just-mitch]

Just seeing this, and wanted to mention that it reminds me of docker(hub).

With that in mind, it feels like we're talking about two products in this design: our canonical registry is dockerhub, and the local client that the PXE uses is the other.

So I'm wondering if the local client can be configurable such that it supports alternative/private registries (like docker). In that case, we'd have good support for path 5 pointed out by @iAmMichaelConnor

Also, is this a product that would be useful for noir contracts/programs outside of Aztec? I'm just thinking about how decoupled it should be from the PXE, and if that changes the design.

I don't think we need all that at the moment, but designing our first implementation with that in mind might result in cleaner code and dividends in the future.

How/where were you planning on plugging this into the PXE?

[spalladino]

@just-mitch I was thinking of doing something simple, where if the PXE couldn't find bytecode during a simulation in its local db (ContractDataSource I believe is the abstraction used) then it falls back to this registry. I thought of just embedding this client in the PXE itself, rather than making it a separate process like docker - at least initially.

Also, is this a product that would be useful for noir contracts/programs outside of Aztec? I'm just thinking about how decoupled it should be from the PXE, and if that changes the design.

It's a good point. Maybe something where we provide contract artifacts indexed by verification key, assuming the vk is a good enough identifier? @Savio-Sou do you think this would be useful for zk-apps built with Noir? The TLDR here is having a web2 repository (think something like Sourcify) where people can upload compilation artifacts (or even sources), indexed either by Aztec address or Noir verification key.

[Savio-Sou]

That would be awesome!

The Noir community has been relying on a barebone README to find libraries.
It'd be great to have a Sourcify- / crates.io-like registry for browsing and importing Noir libraries / contracts.

[Savio-Sou]

assuming the vk is a good enough identifier?

Not if devs are on different proving backends 🤔

I believe Noir's compiled artifacts come with checksums; @TomAFrench is that the hash field in Noir's compiled JSONs?

[TomAFrench]

That hash is not suitable for this purpose as we need to derive it from the compiled ACIR whereas that it derived during the compilation process.

Verification key doesn't seem to cover all situations as we need to handle multi-circuit programs and as you mention we'd end up with a proving-system specific index.

[spalladino]

The Noir community has been relying on a barebone README to find libraries.

To be clear, this would not be a replacement for a human-indexed list of available libraries, but rather something that a proving client would use under the hood. Think you have a zkpassport of sorts, and instead of having to bundle all circuits needed within it, apps could just say "I need a proof that you are over 18, which corresponds to a circuit with id X", and then your client would use the registry to find what's the ACIR for X and generate the proof, and if the user is a dev, present them with the corresponding source code.

But now that I'm writing it, I'm not sure it makes much sense in the context of zk-apps. Every wallet or app would have circuits specific to them and bundle them within their code most likely. The need for a sourcify-like registry is more for interoperability, as we'd have in the aztec network.

All that said, a searchable crates.io-like thing (or like this one) sounds great. Probably a good project for a grant!

[Savio-Sou]

something that a proving client would use under the hood

"Proving client" as in e.g. a level between private smart contract devs' code <> PXE?

[spalladino]

"Proving client" as in e.g. a level between private smart contract devs' code <> PXE?

In the context of Aztec Network, this would be the user wallet that runs the local proofs, in particular yeah, the PXE

[just-mitch]

Any status/update on this one?