Main Page

Welcome to The Quantum Protocol Zoo- Explore, Learn and Implement Quantum Protcols

With the advent of vast number of protocols in the reign of Quantum Information era, there is an urgent need of a standardardization which presents a compressed form of these protocols in order to communicate with the computer scientists, engineers and physicists at one time. The Quantum Protocol Zoo, a wikipedia of quantum protocols linked to each other depending on the functionalities they achieve and the implementation they follow, provides one such platform.

Getting started

Quantum Protocol Zoo directs you to a set of General Descriptions of different quantum and classical functionalities achieved by various quantum protocols. This description elicits the definition, properties and use cases of a given functionality. Further, it directs you to various different protocols used to achieve the functionality presenting a formal description for each. Every such formal description groups all quantum protocols/articles based on the method described, in the reference section. It also directs one to any related protocol or functionality in the "Tags/See Also" section. It also illustrate use cases for different protocols to bridge the gap between users and protocol designers. Finally, some esoteric concepts used by these quantum protocols are explained via internal links that would direct you to a wiki page Supplementary Information.

Submission Format

It is a dynamic platform and the entire community of quantum information and computation is invited to make this attempt a success by further contribution. Submissions can be made to the google form provided in the link below. People can register a request to include their article in the reference of a certain formal description they feel their protocol is similar to. Also, if people think their protocol requires a new formal description not covered by the existing library in the Zoo, they could submit *.tex/ *.txt/ *.html version of their protocol in the format for guidelines given above along with their request. Note that Quantum Protocol Zoo accepts only published article. The final decision on a request resides with the Quantum Protocol Zoo team.

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

Questions and suggestions are welcomed in order to make it more user-friendly and can be addressed in the comments section.


General Description

Functionalities listed in categories above direct you to a general description where you find the definition, properties, use cases of the functionality. It further segregates protocols covering the functionality based on several different aspects like implementation used by quantum protocols to achieve the concerned functionality. Each section opens up a formal description for a particular implementation. Any protocol linked to a given formal description would be listed in its reference section as illustrated before.

Guidelines

A guideline explaining the structure of a Formal Descriptions is given below.

Functionality Description

This paragraph gives objective of the protocol in brief and should be kept as general and complete as possible in order to cover a wide range of protocols under the same functionality and similar methods used. It gives a clear idea about the task to be achieved and roles of the parties involved. No arbitrary names should be given to the parties. This would help avoid any confusion and also, make the functionality (roles) of the parties obvious. E.g. Blind Quantum Computing protocols should be written as Client-Server participating in the protocol, not Alice-Bob. We escape the use of fictional names unless needed, for e.g.- Key Distribution.

Use Case

It illustrates all the possible use cases implied by the concerned protocol.

Tags: This block should include all different classes of categorization that this protocol belongs to, in the quantum protocol zoo. Example- Two party crypto/multi party(three or more), quantum enhanced classical/fully quantum functionality, specific/ universal task. It would also include the stage of the protocol.

Assumptions

  • Adversarial Assumption
    States all the assumptions on the adversary. This point is important for most of the protocols.
  • Setup Assumptions
    lists all the assumptions in bullet points.

Outline

This section is a simple wordy outline of the protocol which tells one about the method used, but not the minute details of the protocol. As far as possible, one must refrain from using mathematical notations or variables. It is to be kept as a general outline of the Procedure. It should not contain any new terminology that has not been explained before or here itself. If one does, it should be linked to a Wikipedia page or a supplementary draft, whichever is preferred. This part should be self-consistent, precise but self-explanatory. If using bullet points and give steps/levels some name, one should aim at describing the target of the step in the first line and then proceed with the ’what’ and ’how’ of the step. A key point to be noted, this description does not aim at answering the ’why’ for different steps nor does it provide the reader with proofs. The reader may refer to the specific paper in order to understand any such detail.

Figure A figure of the protocol in jpeg format could be used. A pdf file of the image drawn using tikz or cryptopackage would also suffice.


Properties

The structure of this section is not specific and would be protocol based. It should highlight any point, parameter, security claim, assumption or clearly anything in the paper that one finds important to emphasize. Contents are preferred to be pointwise to make it limpid.
This section would elicit all the important elements required for the above discussion but not needed to understand the protocol. For example, definitions of any new parameter or threshold used by the parties or agreed universally by everyone for security, assumptions used and the security claims of the protocol. It should be to the point and clear(one line description preferred). Below is a format one could use (you can create your own subsections depending on the protocol).

  • Parameters
    lists all the parameters with the notations used in one line
  • Performance
    gives all the security definitions. Any specific property particular to the concerned protocol should be already defined in the functionality description. E.g. in case of Blind Quantum Computation, blindness is claimed. This property should be already mentioned in a well-defined manner in the functionality description.

One could also include definitions like soundness, verifiability and correctness, etc.. if the protocol mentions it. As mentioned earlier, the structure is flexible for this section.

Pseudo Code

Notations

Any mathematical notations or variables used in the Pseudo code is listed here in order to make the picture clear. It serves the purpose of connecting the wordy outline and the mathematical pseudo code.

This section contains an algorithm/ pseudo code of the protocol. It is a step-wise description of the protocol with mathematical notations and is kept as less wordy as possible.

Resources

Yet to be discussed

References

This section mentions all the different protocols under the same functionality description with similar method. With each reference, a one line description of how it is different from the given (discussed) protocol (resources used, type of measurement or storage etc..) is necessary. This list covers all the papers that one would find easy to understand after reading this formal description.