[CFRG] Should we spell out the star topology for VDAFs?

Christopher Patton <cpatton@cloudflare.com> Sat, 03 August 2024 00:27 UTC

Return-Path: <cpatton@cloudflare.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C42EC15199B for <cfrg@ietfa.amsl.com>; Fri, 2 Aug 2024 17:27:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cloudflare.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5eyo08-4ikw for <cfrg@ietfa.amsl.com>; Fri, 2 Aug 2024 17:27:01 -0700 (PDT)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B24CC151995 for <cfrg@irtf.org>; Fri, 2 Aug 2024 17:27:01 -0700 (PDT)
Received: by mail-qt1-x82e.google.com with SMTP id d75a77b69052e-44fe58fcf29so40350051cf.2 for <cfrg@irtf.org>; Fri, 02 Aug 2024 17:27:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1722644820; x=1723249620; darn=irtf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=v3Zq2i9eB43x0Gr3qLbTqV3/Mb3Wnu/h8ymSE2UiTFc=; b=TCejqxVvbOtYJD5dn1XIiMoRBP9ZchHsiR+qe6KcVHNVLISIqluHL4Vx41qPG6HM7b RVlXfFMPfbe7baQho2eQAMbKxAFKdgxYzHPBl4S902l024zdZ7A/z0SMDyldmoxyEBue rVET2f5cztCRa6Kyx6JRJHnZm9MhzWbt25n9N5Ll57ga2V14zol9wLoyx9xtIpa0DPiS XpI4nW+8FXLk1gUux+35JnFvOSsPn+SrnYf1KBlVeZq0O0q1g2/cjDqho5QAkTFQfpXr vwMBu1sdr/aKMdPOtlykZi3mTumsGO8ddZ5rGKV/UMBEAknzesPvnYMQm1Cg1gea8Jfo LvuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722644820; x=1723249620; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=v3Zq2i9eB43x0Gr3qLbTqV3/Mb3Wnu/h8ymSE2UiTFc=; b=mkjzvqc+MRAsmT+mcue8Fcziqa6OjnJOQ0btiQSg6bRPc1BmrYyx9FyAeF1Ka40Jn5 dmUssgooCxy6QWNnk/ZsMDm88z4i5XWKsGgEYTmUQPrgSnunCIeZney99g2mWuGqjE14 4PjrzxLA81X1BT/4oSreH/TRdXaHAjYEHQid2E0gYRX5opAz2yyFVZWtglZFLoIJGTIU s1G8urYQprHtElet5zZ0lQempqQG177hoC5LGjGnssEVuMAlvb4WUNt/rJ6+K9YeZQzV c04OfRgqSj+DWh+/DEuzXM+v6hRr5O99cYI5UA5w11d/CFPsgdCPT0DVl9i/x1SpE2VQ rJjA==
X-Forwarded-Encrypted: i=1; AJvYcCUIaCZaClUwYyYmrcwc/7fPF6xAr/xO1hlLZ+e4KAFwfF3ygtp1zC+tA3HurDG8VPrMyQC43C8dK19BeWit
X-Gm-Message-State: AOJu0Yyp2dmyzBgjKvWNFMwJomHNA6CFR3aDhi0otWUrYx1W+Gp91oOC UVVloLucu5GPtJ8wcshRyiDwthEr6wk1bWHkg/muFcHtvQVk5xwGtqzFoaMxgZhScLTlqziopeu aNOqYHcmA34Ytyv7xHt1fusRc+7oppt/qYUX8btb/L0tfoCYuvwY=
X-Google-Smtp-Source: AGHT+IG/6InJksSNQq1m2m94dgamy8GNh14LmjdBzq/G0W92+99i0if+aF9odV7N3BXoN2GuK1PGOAHUNWdFeu64O78=
X-Received: by 2002:ac8:574a:0:b0:44f:f06a:d6f5 with SMTP id d75a77b69052e-45189253d78mr72151591cf.36.1722644820468; Fri, 02 Aug 2024 17:27:00 -0700 (PDT)
MIME-Version: 1.0
From: Christopher Patton <cpatton@cloudflare.com>
Date: Fri, 02 Aug 2024 17:26:49 -0700
Message-ID: <CAG2Zi20Dt=x5BYqR_6fzQ3pfMbf+EtqzcAfFRP2GcWBC5LvU7w@mail.gmail.com>
To: ppm <ppm@ietf.org>, CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="000000000000994086061ebc8019"
Message-ID-Hash: 5Z6VEUYFGSBYXOM2NUIZPYNW5JMU27EW
X-Message-ID-Hash: 5Z6VEUYFGSBYXOM2NUIZPYNW5JMU27EW
X-MailFrom: cpatton@cloudflare.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cfrg.irtf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [CFRG] Should we spell out the star topology for VDAFs?
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/P7HEyXQxME1ez3xFsghyDN7JqjA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Owner: <mailto:cfrg-owner@irtf.org>
List-Post: <mailto:cfrg@irtf.org>
List-Subscribe: <mailto:cfrg-join@irtf.org>
List-Unsubscribe: <mailto:cfrg-leave@irtf.org>

Hi PPM+CFRG,

I'd like to get some feedback on what to do about this issue for the VDAF
draft:
https://github.com/cfrg/draft-irtf-cfrg-vdaf/issues/261

Prior to DAP draft 05, we envisioned a "star topology" in which there is a
single leader and any number of helpers. The idea was that for each round
of preparation, the leader would broadcast the prep message to each of the
helpers: each helper would respond with its prep share for the next round,
which the leader would use to compute the prep message for the next round,
and so on. In draft 05 we decided to specialize the protocol for a single
leader and helper and adopt the ping-pong topology [1], which requires
fewer round trips over the network to finish.

In theory, a future specification could execute a VDAF in a star topology,
so it may be useful to spell this out. Note however that not all VDAFs
support more than two aggregators: Prio3 does, but Poplar1 doesn't.

The VDAF draft spells out ping ponging in full detail. This is necessary
because the DAP draft consumes this API directly. Do folks think we should
spell out the star topology in the same level of detail?

Since we don't currently have a use case for it, I don't think it's
necessary to spell out in full detail. I suggest we just sketch it instead.

Thanks!
Chris P.

[1] https://www.ietf.org/archive/id/draft-irtf-cfrg-vdaf-10.html#section-5.8