Skip to content

Configuration

Jump to bottom
bengetch edited this page Jun 14, 2021 · 2 revisions

Configuration

Along with a protocol, congregation ingests a configuration dictionary like the following:

{
  "general": {
    "workflow_name": "demo",
    "pid": 1,
    "all_pids": [1, 2, 3],
    "data_path": "party_one/data/",
    "code_path": "party_one/code/",
    "delimiter": ",",
    "use_floats": false
  },
  "network": {
    "parties": [
      "1:localhost:9001",
      "2:localhost:9002",
      "3:localhost:9003"
    ]
  },
  "jiff": {
    "jiff_lib_path": "",
    "server_ip": "0.0.0.0",
    "server_port": 9004,
    "server_pid": 1,
    "zp": 16777729,
    "extensions": {
      "fixed_point": {
        "use": false,
        "decimal_digits": 1,
        "integer_digits": 1
      },
      "negative_number": {
        "use": false
      },
      "big_number": {
        "use": false
      }
    }
  }
}

If using the Assemble.generate_and_dispatch() method to launch a workflow, this configuration
can be passed as either a path to a JSON file, or an in-memory python dictionary. What follows
will be an explanation of each section and its keys individually:

general

  • workflow_name: The name given to this workflow. This value isn't of critical importance, but
    will be used when writing generated code to file.

  • pid: The party ID of this party, must be an integer.

  • all_pids: All PIDs taking part in this workflow.

  • data_path: A local path to the directory that congregation uses to write job outputs to. If
    input_path is not specified when calling lang.create() for this party's input data, that
    data will also be assumed to be stored in this directory.

  • code_path: A local path to the directory that congregation uses to write job code to. This
    value can be the same as data_path. If unspecified, congregation will use /tmp/<workflow_name>-code/.

  • delimiter: Since congregation is generally meant to deal with CSV files, the default value
    for this field is ",". However, other delimiters can be specified here ("\t" for TSV files, for
    example).

  • use_floats: This key will tell congregation whether to cast the input data as a float or an
    int when doing local processing work over it. Note that this parameter will be removed in the
    future in favor of using the actual type of the data (as annotated by its column definition).

network

  • parties: A list of strings associating each PID in the computation with an IP address and port
    to use for communication during the workflow. Note that in the example above, we have 3 input
    parties with PIDs 1, 2, and 3, respectively, and each string is formatted as "<PID>:<IP>:<PORT>".

jiff

  • jiff_lib_path: Since JIFF is not yet available on npm, congregation requires an explicit path
    to its location on a user's local filesystem.

  • server_ip: The IP address of the JIFF server for this workflow. Congregation supports using an
    existing JIFF server for a workflow (i.e. - not hosted by one of the compute parties), or allowing
    one of the compute parties to spin up the server as needed during the workflow. In the latter case,
    this value would simply be the same as the IP address of the compute party that is hosting it. Note,
    though, that a different server_port value should be used than the port indicated for that party
    in the network.parties list.

  • server_port: The port that the JIFF server will be listening on.

  • zp: The prime number that defines the field that will be used for this computation. It is not
    totally necessary to understand exactly how this works unless you are dealing with either very large
    or floating point numbers. A good baseline to start with is 16777729. One helpful heuristic on
    choosing the right zp value with JIFF is that you'll know your zp is too small if the output
    you're getting is wildly wrong. For examples on picking zp values for different workflows, refer
    to the demos section of the JIFF library.

  • extensions:

    • fixed_point:

      • use: Boolean value to indicate whether to use the JIFF fixed point extension. This extension
        makes it possible to both express input and output as fixed decimal point numbers and compute
        over them as such. Note that for workflows involving plaintext data, this flag will actually
        trigger the extension to be used with the input data (whether or not that input data is stored
        on file as integers or decimals). For workflows involving data that has been secret shared, however,
        this flag (and all JIFF extension parameters) must match the parameters that were used when generating
        the shares themselves.
      • decimal_digits: The number of trailing decimal digits to use when expressing and computing over
        data. Note that a higher decimal_digits parameter often requires a larger zp value.
      • integer_digits: The number of leading integer digits to use when expressing and comuting over
        data.

    • negative_number:

      • use: Boolean value to indicate whether to use the JIFF negative number extension. This extension
        makes it possible to express negative numbers within computations.

    • big_number:

      • use: Boolean value to indicate whether to use the JIFF big number extension. This extension makes
        it possible to express very large numbers within computations. Note that this extension is a dependency
        for both the fixed_point and negative_number extensions, though it may also be used on its own.
Clone this wiki locally