TLDR:

PlonK is a new zkSNARK construction that utilizes a universally updatable structured reference string (SRS) which stands for “permutation argument over univariate polynomials and multiplicative subgroups”.

Unlike popular zkSNARKs schemes, such as the CRS [GROTH16] implementation used in Zcash and EVM applications, PlonK circuits are not applicationspecific. That carries usability benefits.

While the scheme still relies on a trusted setup to generate random parameters, no additional parameters are required for new applications to be built on top of it. That makes it a more practical system for the verification of smart contracts.

PlonK has attained industry interest by striking a good balance between efficiency in validating proofs and the convenience of building applications on top of it. Notably, the Aztec project is building a layer 2 solution based on this technology.
Core Research Question
How can we avoid having to redo trusted setups, while keeping setup time, proof size, prove time, and the verifier time reasonable i.e., succinct, compared to the CRS [GROTH16] model?
Citations
Vitalik Buterin. “Understanding PLONK“
Background
[GMR89] is the first interactive proving system utilizing public cointossing protocol for interactive proofs. In a similar sense, [GROTH16] is the first fully succinct noninteractive zeroknowledge (NIZK) proof protocol based on CRS. To solve the issue that CRS has to be preprocessed (called a trusted ceremony) and can’t be reused if the circuit needs to be updated, [GKMMM18] is the first NIZK protocol with SRS, but it comes with a caveat: the calculation of Gaussian elimination is expensive. [MBKM19] Sonic is the first fully succinct NIZK with SRS, but it has limited efficiency compared to PlonK. It is not until PlonK that we have a fully succinct and efficient SRSbased NIZK protocol, where the annoying trusted setup (that has to be redone for every circuit design update) and toxic waste issues have been solved.
Summary

Introduction

The authors claim to have better proving time than [MBKM19], thanks to the protocol of permutation argument over univariate evaluations on a multiplicative subgroup (based on [BG12]), rather than over coefficients of a bivariate polynomial in [MBKM19].

PlonK provides two variants, one with 9(n+a) combined degree of polynomials, one with 11(n+a). The former one has a larger proof size but reduced prover computation required for about 10% compared to the latter one. n stands for multiplication gates, and a stands for addition gates in the circuit.

Sonic, Groth16, Auroralight, Fractal, Marlin are thoroughly compared as their performance can’t be compared directly, because their circuit design (additive gates/multiplicative gates)=>constraint system is different.


Preliminaries
 The AGM [FKL18] model is used to evaluate the security assumption against algebraic adversaries (soundness check) to make sure PlonK makes them fool the game with only probability of negl(λ).

Kate commitment [KZG10] is improved in PlonK as a batched form, in order to make parallel processing (opening) of commitments for each evaluation point possible. To quote the authors: “Ultimately, in the “grand product argument”, this reduces to checking relations between coefficients of polynomials at “neighbouring monomials”.

The authors define a lowdegree polynomial, which is a slightly simplified version from [KZG10] and [MBKM19], in order to achieve the desired properties for polynomial commitments in PlonK.

The authors prove that the simplified lowdegree polynomial commitment achieved knowledge soundness under the AGM model.

The authors describe the preprocessing (trusted setup) of ranged polynomials.


PlonK’s heart: permutation argument with univariate polynomials on a multiplicative subgroup, is described here.
 PlonK’s batched version of permutation check on polynomial commitments is described here.

A new form of constraint system is described here. Vitalik describes it as having two kinds of constraint: copy constraints (will be “encoded” with permutation polynomials), and additive/multiplicative gate constraints (“encoded” with wire polynomials). Please refer to [Understanding PlonK] for more details.

Main protocol of the proving system.

A wrapup of all of the above: preprocessing, proving, calculating challenges beforehand, verifying via opening commitments, checking the opening proofs, and doing evaluations on points/commitments.
Method
Please refer to section 8.4 in the original paper for detailed formulae. What follows is a qualitative description of the steps provided.
The process for the respective roles is ordered below.

Trusted setup (preprocessing):
An Sranged polynomial protocol is defined so that a verifier can “ask” the protocol if some polynomial equations hold on a certain range of input values. This way the information can be “hidden” inside. The Kate commitment scheme and opening of such commitments also play a role in the zeroknowledge property. Please refer to section 4 in the original paper. 
Prover, to compute:
 Circuit=>(permutation/wire/quotient/)polynomials (and challenges to such polynomials)
 Evaluation points (and challenges of such points), opening evaluations (and challenges of such openings)
 Linearisation polynomials=>evaluation of such polynomials
 Finally, a multipoint evaluation challenge.

Verifier, to compute:
 Validate that the wire/permutation/quotient/opening commitments are indeed in range.
 Validate that the linearisation commitments and opening evaluation commitments are indeed in a valid range.
 Validate that the public inputs are indeed in range.
 Compute the challenges as what the prover did.
 Compute zero polynomial evaluation.
 Compute Lagrange polynomial evaluation.
 Compute public input polynomial evaluation.
 Compute quotient polynomial evaluation.
 Compute batched polynomial commitment, in two steps.
 Compute groupencoded batch evaluation.
 Batch validate all the above evaluations and compare them to the proof provided.
Results
PlonK is the second fully succinct version of SNARK with universal updatable SRS.
The performance comparison is shown below:
The authors claim that the choice of univariate polynomials over multiplicative subgroups increases both the prover and the verifier efficiency, under different circuit assumptions.
In common circuits, the ratio between additive gates and multiplicative gates is 2:1. Under this circuit assumption, this means PlonK is 2.25 times worse than [GROTH16], and 10 times better than [MBKM19], for prover’s work.
Please be advised that additive circuits are often considered calculationfree, as in the CRS/[GROTH16] setup, resulting in “unlimited” fanin circuits. However, PlonK prefers a constant number (two) fanin circuit, for performance reasons.
The following chart shows the benchmark via ttps://github.com/AztecProtocol/barretenberg/ .
For performance comparison between the notsoobvious setup, such as randomized sumcheck approach and Fractal/Marlin, the authors emphasized the approach of the constraint system design, quote: “we focus on constant fanin circuits rather than R1CS/unlimited addition fanin; thus our linear constraints are just wiring constraints that can be reduced to a permutation check”.
That makes Marlin a little bit tricky to compare directly, so the author compares the average (assuming the same value of n  numbers of multiplication gates; PlonK outperformed by 2x on prover group operations and proof size), the extreme, and the low bound  PlonK is superior to Marlin in all cases, unless in the most extreme condition where the R1CS constraints are “fully dense” in a sense that , where the circuit design is filled with many large numbers of fanins rather than constant numbers of fanins where PlonK prefers.
Discussion and Key Takeaways

CRS schemes generally used in the industry are bad for maintainability as new parameters must be generated in a trusted parameter generation ceremony for new applications. PlonK iterates upon this system through a new SRS scheme.

Under SRS, the trusted setup produces parameters that can be generalized under a certain bounded circuit size, and the security assumption is stronger as only one of the participants is required to be honest to achieve negl(λ) probability for adversaries to win the game (convince the verifier with false proof without knowing witness).

PlonK carries an interesting set of tradeoffs. It features increased performance compared to [MBKM19] and [GKMMM18]. While its performance is a little bit worse than CRSbased [GROTH16] schemes, its flexibility makes it better suited for layer 2 applications.
Implications and Followups

Instead of needing longwinded fullpowered zeroknowledge primitives to achieve soundness, we now have commitment schemes—a great tool in the zeroknowledge protocol toolbox.

We can open the commitments, evaluate the points and compare them to the argument and the proof provided by provers, while still “hiding” the nature of the computation inside the commitment to achieve computational soundness.

This enables the creation of private applications that provide proofs of computational soundness under the assumption that there was at least one honest participant in the initial parameter generation ceremony.
Vitalik Buterin provides some additional clarity:
“There are other types of polynomial commitments coming out too. A new scheme called DARK (“Diophantine arguments of knowledge”) uses “hidden order groups” such as class groups to implement another kind of polynomial commitment. Hidden order groups are unique because they allow you to compress arbitrarily large numbers into group elements, even numbers much larger than the size of the group element, in a way that can’t be “spoofed”; constructions from VDFs to accumulators to range proofs to polynomial commitments can be built on top of this. Another option is to use bulletproofs, using regular elliptic curve groups at the cost of the proof taking much longer to verify. Because polynomial commitments are much simpler than fullon zeroknowledge proof schemes, we can expect more such schemes to get created in the future.”
Applicability

PlonK is perfect for zkrollups on Ethereum to solve throughput issues on the mainnet. The authors of PlonK are currently pursuing an implementation under the Aztec project.

Aztec developed zk.money, a privacy shielding solution on Ethereum, based on zkzkrollup, which is further powered by PlonK. This scheme is intended to enable the creation of private smart contracts offchain with fast confirmation times onchain.

The Aztec team is also working on UltraPlonK, which precalculates some logics/calculations as lookup gates, and makes them available in regular PlonK  the precalculated gates can be “SNARK unfriendly”, this is exactly the distinctive feature of UltraPLONK.

If successful, UltraPLONK could be more succinct than most approaches to zkSNARKs and as it is expected to only consume 3k gas per transaction, whereas an average ERC20 transfer consumes 45k.

The team is also applying this scheme to SHPLONK  a unique polynomial commitment scheme that can be used in PlonK, or other zeroknowledge protocols.

TurboPLONK programs can make the usage of arbitrary arithmetic custom gates possible. This enabled breaking further away from the efficiency limitations of traditional R1CS, for example in the performance of elliptic curve operations.

Apart from the official PlonK implementation written in C++, there are two Rust implementations available. One from dusknetwork can be found here. For another implementation by Fluidex, you can even write circuits in a circomcompatible fashion.