Submissions

We invite you to contribute to the Quantum Protocol Zoo. Your contribution can have one of the following forms:

• Functionality page: describing a general task for a quantum network;
• Protocol page: describing a particular protocol for a defined functionality.

Each of pages has a predefined format, see below. To keep the wiki consistent, we kindly ask you to follow the guidelines on the format.

Currently, submissions can be made via Google forms, see link below. In the Google form, you should specify which page (functionality or protocol page) you would like to submit. Currently, we accept submissions in plain text (.txt file), supplemented with .png, .jpg or .pdf for figures. Note that Quantum Protocol Zoo accepts only published work. Submissions will be considered by the Quantum Protocol Zoo team and the final decision on acceptance resides with the team.

What is more, you can submit a request for an article in the Discussion section on this page. Such a request will be considered and, if accepted, added by to the wiki by the team. You are welcome to express your general comments in the Discussion to make the wiki more user-friendly.

Link to Google Form

https://forms.gle/ANokaD4iCzwvYjdb6

Guidelines

Protocol page describes a specific protocol implementing the defined functionality (the "how"). Following are the section-wise guidelines for protocol pages for submission. Contributors may consider an example from the Protocol Library too if needed.

• Introductory paragraph gives a link to the functionality page, article on the example protocol and justify how the

protocol is different from other protocol drafts for the concerned functionality.

• • No new terms should be used unless explained in the same paragraph. If the term is complex and needs further explanation one can also provide a link for the same to the supplementary information page. e.g. fidelity (a measure of how close two quantum states are), and the link would direct one to a mathematical formula of the same in the supplementary page.
  • No fictional names to be used. The parties should be called according to their roles. E.g. Client-Server instead of Alice-Bob is preferred.
  • Avoid mathematical equations or notations.
  • Try to provide a real-life use case for the protocol example signing documents etc..
• Tags are terms used to link several pages on the zoo similar or useful in certain aspect for the concerned page. Categories to which the pages belong can also be mentioned here.
  • Available categories for the zoo pages can be found in the Navigation menu.
• Assumptions describe the scenario in which the protocol will be successful and hence, it is necessary to be mentioned before one starts discussing the protocol.
  • List all the assumptions taken on the hardware setup or adversary in the given protocol.
• Outline is a comprehensive wordy description. Guidelines should be strictly followed for this section.
  • No mathematical notations or equations should be used.
  • Bullet points are preferred.
  • It should be lucid, and one is free to make this section lengthy (yet avoid redundancy) such that it gives a rough picture of the protocol without any specific details like the number of qubits used or threshold value if any.
• Notations The following sections on properties and pseudo code contain mathematical equations and hence to connect it with the wordy outline this section displays all notations used.
• Requirements **Network Stage
  • Relevant network parameters
  • Technology required by each party
  • Availbale information from implementations like, order of digits related to threshold values, QBit Error Rate (QBER), parameters, etc..

It accommodates a figure on the decomposition of the protocol into various components required for implementation including the physical resources, nodal subroutines, and other protocols used. Color Coding:

• • • The protocols are shown in a blue rectangular box.
    • The nodal subroutines are shown in a green rounded rectangular box.
    • The physical resources are shown in red ovals.
• Properties This section is a list of all important details which were not given in the wordy outline. One could list all that one thinks is important for the reader to know and can be extracted from the protocol. e.g:

1. List of parameters used e.g. threshold value etc.
2. Security Claims and other theorems used for the protocol e.g. correctness, verifiability, blindness, universality
3. Advantages in terms of resources. e.g. no quantum memory needed etc.
4. Success probability of protocols (for entanglement routing and other building blocks protocols).
5. Mathematical equations or inequalities for security claims and other items mentioned above can be accommodated here.
6. If using a new term for any of the above, please explain it here itself and if needed, provide a link to the supplementary information page for a detailed explanation. E.g. Any property not defined in the functionality description already could be defined here.

• Protocol Description This section contains an algorithm/ pseudo code of the protocol.
  • Should be a step-wise description of the protocol with mathematical equations. Avoid words as much as possible.
  • Can be divided into stages common for all the protocols in the concerned functionality. For example, Delegated Computing

can be divided into Preparation and Computation Stage.

• • Every stage (there can be only one stage in a protocol too) should have Inputs and Outputs for each party.
• Further Information This is a review section on all the similar protocol in terms of the method used. It can be skipped and different contributors can choose to write this section for various pages uploaded on the zoo.