Main Page: Difference between revisions

From Quantum Protocol Zoo

Revision as of 05:47, 8 October 2018

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.

General Functionality Description

Certain functionalities which can be implemented via different kinds (using different resources) of protocols and thus, lead one to a general description where one finds 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.

Structure

Following is a structure of various formal descriptions presenting various protocols.

Functionality Description

A lucid definition of functionality achieved and properties satisfied by the method used.

Use Case

Bridges the gap between users and protocol designers.

Tags: Any related page or list of protocols is connected by this section

Assumptions

Adversarial Assumption
Setup Assumptions

Outline

It is a wordy outline for the protocol without any mathematical notations which helps the reader create a rough picture of the protocol. It does not involve any specific detail of protocol. This section may or may not include a figure for the protocol.

Properties

Any important information extracted from the protocol which is not obvious from the outline.

Parameters
lists all threshold values and other such parameters used.
Performance
lists all success and security claims.

Pseudo Code

Notations

Any mathematical notation or variable used in the Pseudo code is listed here. 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. Unlike outline, it contains all parameters and other details of the protocol

Resources

Yet to be discussed

Building Block: Illustrates the building blocks of which protocol is composed of.
Network Stage:

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.

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

Retrieved from "https://wiki.veriqloud.fr/index.php?title=Main_Page&oldid=462"

@@ Line 7: / Line 7: @@
 Certain functionalities which can be implemented via different kinds (using different resources) of protocols and thus, lead one to a general description where one finds 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==
+==Structure==
-A guideline explaining the structure of a Formal Descriptions is given below.
+Following is a structure of various formal descriptions presenting various protocols.
 ===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.
+A lucid definition of functionality achieved and properties satisfied by the method used.
 ===Use Case===
-It illustrates all the possible use cases implied by the concerned protocol.
+Bridges the gap between users and protocol designers.
+  '''Tags:''' Any related page or list of protocols is connected by this section
-  '''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<br/>States all the assumptions on the adversary. This point is important for most of the protocols.
+*Adversarial Assumption<br/>
-*Setup Assumptions<br/>lists all the assumptions in bullet points.
+*Setup Assumptions<br/>
 ===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.
+It is a wordy outline for the protocol without any mathematical notations which helps the reader create a rough picture of the protocol. It does not involve any specific detail of protocol. This section may or may not include a figure for the protocol.
- '''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.<br/>
+Any important information extracted from the protocol which is not obvious from the outline.
-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<br/> lists all threshold values and other such parameters used.
-*Parameters<br/> lists all the parameters with the notations used in one line
+*Performance<br/> lists all success and security claims.
-*Performance<br/>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.<br/>
-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.
+Any mathematical notation or variable used in the Pseudo code is listed here. 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. Unlike outline, it contains all parameters and other details of the protocol
-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
+*Building Block: Illustrates the building blocks of which protocol is composed of.
+*Network Stage:
 ===References===