The multiparty setup is better than a singular-party setup, but it burdens its deployment. How can users be confident of at least one party they can trust whose preferences vary? Further, how can deployment be made so that a malicious party does not sabotage the setup process or is sabotaged by the organiser or network failures? In other words, who would need to be blamed? Doing these things properly makes the process’s deployment significantly more expensive than centralised deployment. Hence, I don’t see them bearing any practical relevance, as any authority that organises their deployment would also be subject to cost optimisation due to human nature and as security can’t be quantified, it suffers first.
There are zero-knowledge proofs that don’t require a trusted setup phase. A plain old logarithmic equality proof is a very powerful tool, making it possible to ensure correct reencryption shuffle, decryption or encoding. They don’t get the same appeal as generic ZKP systems that get all the hype, which deters practically-minded people from getting familiar with the mechanisms and opportunities. At least, that was my experience when getting into ZKP.
There are logarithmic-sized proofs with transparent setup for arbitrary computation. These are much better for practically-minded people than ZKPs for ad-hoc computations because you don’t have to be a cryptographer to figure out how to use them
There are zero-knowledge proofs that don’t require a trusted setup phase. A plain old logarithmic equality proof is a very powerful tool, making it possible to ensure correct reencryption shuffle, decryption or encoding. They don’t get the same appeal as generic ZKP systems that get all the hype, which deters practically-minded people from getting familiar with the mechanisms and opportunities. At least, that was my experience when getting into ZKP.