Main Page
Welcome to QuPedia- Explore, Learn and Implement Quantum Porotcols
With the advent of vast number of protocols in the reign of Quantum Information era, we are in urgent need of a standard platform which presents these protocols in a compressed form to communicate with the computer scientists, engineers and physicists at one time. We propose to create QuPedia, the Quantum Protocol Wikipedia, a zoo of quantum protocols linked to each other depending on the functionalities they achieve and the implementation they follow. QuPedia curators take you on a ride to the world of quantum protocols unveiling the mysterious functionalities and implementations achieved by quantum cryptographers over the century. We present to you the QuPedia Team.
- THE ZOO CURATORS
-
Elham Kashefi -
Shraddha Singh
- CONTRIBUTORS*
We list the people who have helped in the construction of QuPedia by contributing class of quantum protcols in the best of their knowledge with no less effort.
'*'Criterion: In order to become a contributor one must contribute a minimum of ten classes of quantum protocols to the QuPedia.
Getting started
QuPedia directs you to a set of General Description 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. We 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 called "Supplementary Information".
Categorisation
We also provide you with different lists of categories used for tags. These tags help one explore QuPedia better.
- Two Party
- Multi Party
- Universal Task
- Specific Task
- Quantum Functionality
- Quantum Enhanced Classical Functionality
- Building Blocks
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. We try to make it as general and complete as possible in order to cover a wide range of protocols under the same functionality and similar methods used. It should be able to give 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. Eg. 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.
Tags: This block should include all different classes of categorization that this protocol belongs to, in the quantum library. Example- Two party crypto/ client-server/multi party(three or more), quantum enhanced classical/fully quantum functionality, specific/ universal task. It would also include the stage of the protocol.
See Also
Any related formal description can be mentioned here. Tags and See Also are essential parts of this formal description. The peron in charge of writing the first draft of the formal description should make the attempt of adding as many tags and see also point as possible as this will eventually defines the structure of the Wikipedia.
Outline
This section is a simple wordy outline of the protocol. It should tell you what the protocol is, but not the minute details of the protocol. As far as possible, one must refrain from using mathematical notations or variables. It should 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 preferred. This part should be self-consistent, precise but self-explanatory. If we use 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, we do not aim at answering the ’why’ for different steps nor do we provide with the security proof. That would just make the description as long as the paper. It is redundant and not the aim of this formal description. The reader may refer to the specific paper in order to understand any such detail.
Figure
This section shall be replaced with a picture made using cryptocode package which gives a diagrammatic representation of the protocol. For the time being, one can add pictures of hand-drawn figures. No need to explicitly draw on tikz and waste your time unnecessarily.
Notations
Any mathematical notations or variables used in the Pseudo code can be listed here in order to make the picture clear. It serves the purpose of connecting the wordy outline and the mathematical pseudo code.
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 - 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. - Security Claim
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
This section contains an algorithm/ pseudo code of the protocol. It would be stepwise description of the protocol with mathematical notations. We try to avoid words as much 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 should cover all the papers that one finds easy to understand after reading this formal description.
Use Case
It illustrates all the possible use cases implied by the concerned protocol.
Submission Format
It is a dynamic platform and we would like the entire community of quantum information and computation to help and 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 QuPedia, they could submit *.tex/*.txt/*.html version of their protocol in the format for guidelines given above along with their request. Note that QuPedia accepts only published article. The final decision on your request resides with the QuPedia team.
Link to QuPedia Google Form: https://goo.gl/forms/uRMJWWICZRiwu5yY2
In an attempt to make QuPedia better we request to address your questions and suggestions in the comments section on making it more user-friendly.