Any available chips / gadgets?

[dan-da]

I was wondering if there are any chips or gadgets available besides those in the examples? in other crate(s) perhaps...

I see these quotes in the halo2 book that led me to believe this is intended:

Our hope is that less expert users will normally be able to find an existing chip that supports the operations they need, or only have to make minor modifications to an existing chip. Expert users will have full control to do the kind of circuit optimizations that ECC is famous for 🙂.

When implementing a circuit, we could use the features of the chips we've selected directly. Typically, though, we will use them via gadgets.

and also in issue #94:

Let's say that at some point we have a healthy ecosystem of third-party gadget implementations

...

An alternative approach would be to just depend on a Rust crate versioning policy for gadgets

Under halo2/src, I do not see any chips or gadgets subdir. I was wondering if it is planned to have some defaults included with the crate? Or at least a sample gadget crate to kind of point the way for anyone interested in making one.

I guess a related question would be: where are the chips/gadgets that zcash itself uses?

[therealyingtong]

We have a few gadgets in the Orchard repo: Poseidon, Sinsemilla, ECC addition and multiplication, and some utilities. These are used in the Orchard circuit.

Some of the gadget implementations are quite specific to Orchard (for example, ECC variable-base scalar mul only takes in a base field element as scalar). I think any plans to upstream them would involve more generic versions.

[dan-da]

thx for the pointer. yeah it would be nice to see these extracted out into general purpose crate(s).

I find myself a bit unclear on the distinction between chips and gadgets. In particular:

• in src/circuit.rs, there is a Chip trait defined but no definition of a Gadget.
• in examples/*, there is no "Gadget" struct, enum, or trait being used.
• in Poseidon, Sinsemilla, ECC, there is likewise nothing that is clearly a "Gadget".
• in src/circuit.rs I see pop_namespace() that takes a gadget_name.

So it would seem that "Gadget" is sort of a meta concept of a grouping of chips/circuits that exists mainly in the programmer's mind, or possibly in a namespace. Is that right?

Since they are referred to quite a bit in the book, perhaps the examples should comment about what constitutes a gadget (vs a chip).

[str4d]

So it would seem that "Gadget" is sort of a meta concept of a grouping of chips/circuits that exists mainly in the programmer's mind

Correct. From the outside, a gadget is the same kind of thing as in any other ZKP system: a common reusable unit that corresponds to some useful logical operation. However, in PLONK-style circuits there are a lot of low-level details that the top-level circuit builder might need to care about. We use the "Chip" abstraction to represent these.

• Chips provide implementations of "instructions", potentially optimised in specific ways, and are responsible for gate configuration and circuit assignments.
• Gadgets implement logical operations in terms of "instructions"; they do not deal directly with any circuit assignments (which is incidentally why we don't have any specific trait for them, just usage patterns for how to pass Layouters through).

The boundary between a Gadget and a Chip is therefore context-dependent; you need to decide how much of the logical operation makes sense to tightly control, and how much can just be implemented generically and reusably.

Take the Poseidon gadget as an example:

• poseidon.rs defines traits specifying the required instructions (permute being the main one, and then some sponge-related instructions), and then implements the user-facing gadgets in terms of them.
• poseidon/pow5t3.rs contains a chip that implements the instructions for a specific optimisation context: it requires 4 advice columns and processes two partial rounds per row (requiring a higher degree bound to do so).

Someone with a different set of optimisation requirements (e.g. needing a lower degree bound, or reusing some of the internal Poseidon circuit logic for some other purpose) could implement their own chip that provides those properties, and then reuse all of the gadget logic we implemented.

Since they are referred to quite a bit in the book, perhaps the examples should comment about what constitutes a gadget (vs a chip).

We've had a long-standing issue to document this more clearly (#312) that we haven't had time for yet 😅

[str4d]

We now have the halo2_gadgets crate that provides chips and gadgets. #312 covers the documentation aspect.