Submissions

Submissions can be made to the google form provided in the link below. You can register a request to include their article as a "relevant paper" for a certain formal description. If you do not find any required functionality or think your protocol requires a new page, submit *.tex/ *.txt/ *.html version of the protocol using instructions in the guidelines given below. Note that Quantum Protocol Zoo accepts only published articles. The final decision on a request resides with the Quantum Protocol Zoo team.

Link to Google Form: https://goo.gl/forms/UXhrqzQEVpm98Mkt1

Comments are welcomed in order to make it more user-friendly and can be addressed in the Discussion.

Functionality Description

• Defines the functionality and objective of the concerned protocol.
• Should define all the properties of protocol that fit the functionality. E.g. For Blind Quantum Computation, it defines Delegated Quantum Computation, Blind Computation and the properties concerned i.e. blindness, correctness and universality.
• 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 (measure of how close two quantum states are), and the link would direct one to a mathematical formulae of the same in the supplementary page.
• No fictional names to be used. The parties should be called according to their role e.g. Client-Server instead of Alice-Bob is preferred.
• Should be a short and precise paragraph.
• Should be lucid.
• Avoid mathematical equations or notations.

Use Case

• All possible use cases/ applications at user level of the protocol.
  

Tags

• One- or two-word tags.
• Tags are terms used to indicate any term related to the concerned functionality or formal description.
• All related pages which one wants to bring notice to the reader are also included in tags.
• One should try to put as many tags as possible. e.g for Public Quantum Money, Tags: Money, Specific Task, Multi party, Private Quantum Money,..

Requirements

• Network Stage: See Network Stages
• Technological Readiness:

Outline

• A detailed wordy description.
• No mathematical notations or equations to be used.
• Bullet points are preferred.
• Same as functionality description it should be lucid, but one is free to make this section lengthy (yet avoid redundancy)
• Should give a rough picture of the protocol without any specific details like number of qubits used or threshold value if any.
• In the end, this section can accommodate a figure of the protocol. An example can be seen on UBQC.

• 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.

Properties

---

• This section is a list of all required information and specific details which were not given in the wordy outline.
• Contains no subsections. 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 assumptions.
2. Assumptions on adversary. A link to the security definitions section on the supplementary information page should be provided if this is listed (This is mandatory item for almost every protocol except some building blocks protocols).
3. List of parameters used e.g. threshold value etc.
4. Security Claims and other theorems used for the protocol e.g. correctness, verifiability, blindness, universality
5. Advantages in terms of resources. e.g. no quantum memory needed etc.
6. Success probability of protocols (for entanglement routing and other building blocks protocols).

• Mathematical equations or inequalities for security claims and other items mentioned above can be accommodated here.
• If using new term for any of the above, please explain it here itself and if needed provide a link to supplementary information page for a detailed explanation. E.g. Any property not defined in the functionality description already could be defined here.

Pseudo Code

---

• This section contains an algorithm/ pseudo code of the protocol.
• Should be stepwise description of the protocol with mathematical notations.
• Can be divided into stages as governed by the 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 illustrated before the steps of the stage. These inputs and outputs are determined by the resources used. See an example in the wikipedia
• Avoid words as much as possible.

Relevant Paper

• Mentions all related papers which one could find easy to understand after reading the given description.
• Every paper enlisted here is accompanied by a line or two explaining how the paper is different from the given description in terms of resources used, better or worse security, any assumption, change of steps for parties e.g. instead of preparing and sending the qubits, the protocol uses only measurement device to send qubits, in a different version of the protocol.
• Unless using different resources from the given version, a protocol does not need a different formal description. All such papers can be addressed here.

Extra Information

• If the paper used for given description has multiple protocols, pick the most general one and if needed one can merge it. The concerned paper thus goes in the relevant papers section mentioning the other versions of protocols as its one line description.
• Only published papers with proper security proof are to be considered. One that is easy to summarize and extract pseudo code from.
• Every formal description should contain the above mentioned structure in order to make it an independent page as we cannot direct the user to go through the general functionality description and then the concerned formal description.
• General Functionality Description is not needed for every protocol. One can write as many different versions of formal descriptions, depending on how different the protocols are in terms of resources used.
• Title of the formal description should reflect the functionality/branch of the functionality discussed in the concerned formal description. If not so, the main functionality should at least be included in tags such that when one searches for the concerned functionality he/she has the list of all the different versions in the search result.
• Only if the number of different formal descriptions for a functionality grows too big such that one can come up with a structure to categorize them in terms of resources, a general functionality description shall be designed.

Link for tex file of skeleton for the above format:yet to be uploaded (a downloadable link)