Introducing the SIEVE Circuit-IR: Plugins
Written: , Published: , Author: Kimberlee Model, Tags: SIEVE IR, Circuit-IR, v2.1.0,
During development of the IR, the SIEVE Program sort of decided that circuits are not expressive enough to express certain functionality. For example, the comparison and division operations previously described on this blog cannot be encoded with the IR because they require plaintext computations to be performed and passed into the circuit. Certainly the frontend could do that, but so could the backend — and many already can, with further tricks that a frontend can’t reliably expect to exist. Hence, we created the plugin system to enable backends to implement certain functionalities on their own and provide an interface through the IR.
Plugin Functions
The IR Plugin system integrates with the IR using functions. Any functionality of a plugin is exposed as a function gate. The body of the function gate — ordinarily a list of gates — is replaced by by a plugin binding. The plugin binding has the name of a plugin, and an operation within the plugin. It may also have arbitrary additional numbers or identifiers, but most don’t.
Here is an example of the less than function, using a plugin.
// Return 1 if the first input is less than the second, otherwise return 0. // output wire (bit) // | first input wire // | | second input wire @function(less_than, @out: 0:1, @in: 0:1, 0:1) @plugin(extended_arithmetic_v1, less_than);
The plugin function is called just like an ordinary function-gate. Here it is showing that a secret value is between two public values.
$0 <- @public(); $1 <- @public(); $2 <- @private(); $3 <- @call(less_than, $1, $0); $4 <- @call(less_than, $2, $1); $5 <- @add($3, $4); @assert_zero($5);
Before using a plugin function, it must be declared in the circuits header — much like #includeing a function in C/C++.
The plugin include section goes between the circuit keyword and the first type.
version 2.1.0; circuit; @plugin extended_arithmetic_v1; @type field 127;
Plugin Types
Some plugins need to store data between calls. Consider the "Circuits with RAM" paradigm — most of the computation is a circuit, however it occasionally accesses a random offset within a storage buffer. The RAM plugin would need to store buffers between its read and write operations. For this, the plugin system allows for plugin types.
version 2.1.0; circuit; @plugin ram_arith_v1; @type field 127; @type @plugin(ram_arith_v1, ram, /* index/element type */ 0);
Most plugin types must be interacted with through plugin functions.
The RAM plugin defines an init operation to create a new buffer, and, of course, read and write.
// Initialize a RAM buffer. Initialize each element with the fill parameter. // buffer output // | fill input @function(ram_init, @out: 1:1, @in: 0:1) // number of elements to create @plugin(ram_arith_v0, init, 100); // Read an element from a buffer // element output // | buffer input // | | index input @function(ram_read, @out: 0:1, @in: 1:1, 0:1) @plugin(ram_arith_v0, read); // Write an element into a buffer // buffer input (mutated) // | index input // | | element input @function(ram_write, @in: 1:1, 0:1, 0:1) @plugin(ram_arith_v0, write);
Conclusion
The SIEVE IR plugin system enables backends to provide functionality it otherwise could not, and to optimize operations beyond what a frontend could. Check out the plugins which have been standardized by the SIEVE Program, and those which are implemented/implementable in WizToolKit.