MIME-Version: 1.0
References: <CA+ydi=LtskFh89TW75=CBwbdZzWR-ZjWS77TnrF4G+xUfm8z+Q@mail.gmail.com>
 <xNzSDtvj-BH4EW9eJMqn_yAiVUEiggnS3WIrvLml6gGAZ6CPADO9pbPV4B30txzSY9laEmX3ckXX8L2Hu18ZrWMUjMH23csL-YK-mDse6DY=@protonmail.com>
 <CA+ydi=K7kePFPXbTP6S63SdddORnc6nVoHqR4gDVoeX3uY-S-Q@mail.gmail.com>
 <s3urNahBotY-aYGaQyY7wz2Sh8UXbqHX2PvZyRcyaMJF6MjUrabv0p_ytE3m1Cu9r79MY649RoulaBPuqGLrSD8qwOfCS-n-HymOEyih5yQ=@protonmail.com>
In-Reply-To: <s3urNahBotY-aYGaQyY7wz2Sh8UXbqHX2PvZyRcyaMJF6MjUrabv0p_ytE3m1Cu9r79MY649RoulaBPuqGLrSD8qwOfCS-n-HymOEyih5yQ=@protonmail.com>
From: Weiji Guo <weiji.g@gmail.com>
Date: Thu, 4 May 2023 23:31:22 +0800
Message-ID: <CA+ydi=+6oSQ2oEeuBDQs7fzWL75h4CYb3k4_SS3VbFgxJwDGiA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000015bc2b05fadfdefd"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] proposal: new opcode OP_ZKP to enable ZKP-based
 spending authorization
Precedence: list

--00000000000015bc2b05fadfdefd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi ZmnSCPxj,

I do mean to have specialized computing power vendors, which could happen
to be miners, or not. Optiming ZKP computations is rather different from
Bitcoin mining so I expect those vendors to be from more research-driven
teams focused in cryptographic engineering.

I am open to whether to put those transactions in mempool or not. I
apologize for giving an inaccurate number earlier about the verification
cost. I just ran gnark-bench on my Mac M2, it turns out the cost for
Groth16 verification could be as fast as 1ms. For Plonk it is around 1.6ms.
So it seems even a common fullnode could handle thousands of OP_ZKP
transactions. In that case, the ZKP transactions could be put into mempool,
and be open to be aggregated by some vendor. Fullnodes should verify these
transactions as well. It does not seem a good idea to treat them with
special rules as there is no guarantee that certain OP_ZKP transactions
will be aggregated or recursively verified. Of course, the weighting should
be well benchmarked and calculated. The cost for those *standalone* OP_ZKP
transactions might be higher due to more data and/or higher weighting. This
incentivizes vendors to develop aggregation / recursive verification
services to drive down the fee requirements and profit from doing so (fee
extraction). I also expect to see an open market where various vendors can
compete against each other, so it makes sense to have these transactions
openly visible to all participants.

Meanwhile, some transactions are meant to be off-chain. For example, a
would-be smart contract can aggregate many related transactions in a OP_ZKP
transaction. Those aggregated transactions should *not* be transmitted
within the Bitcoin network. They could even be *not* valid Bitcoin
transactions. Usually the smart contract operator or its community could
host such a service.

Consider a potential situation in a few years: there are thousands of
active smart contracts based on OP_ZKP, and each block contains a few
hundred OP_ZKP transactions, each one of them aggregates / recursively
verifies many transactions. The effective TPS of the Bitcoin network could
far exceed the current value, reaching the range of thousands or even more.

Hope this clarifies.
Weiji

On Tue, May 2, 2023 at 11:01=E2=80=AFPM ZmnSCPxj <ZmnSCPxj@protonmail.com> =
wrote:

>
> Good morning Weiji,
>
> > Meanwhile, as we can potentially aggregate many proofs or recursively
> verify even more, the average cost might still be manageable.
>
> Are miners supposed to do this aggregation?
>
> If miners do this aggregation, then that implies that all fullnodes must
> also perform the **non**-aggregated validation as transactions flow from
> transaction creators to miners, and that is the cost (viz. the
> **non**-aggregated cost) that must be reflected in the weight.
> We should note that fullnodes are really miners with 0 hashpower, and any
> cost you impose on miners is a cost you impose on all fullnodes.
>
> If you want to aggregate, you might want to do that in a separate network
> that does ***not*** involve Bitcoin fullnodes, and possibly allow for som=
e
> kind of extraction of fees to do aggregation, then have already-aggregate=
d
> transactions in the Bitcoin mempool, so that fullnodes only need validate
> already-aggregated transactions.
>
> Remember, validation is run when a transaction enters the mempool, and is
> **not** re-run when an in-mempool transaction is seen in a block
> (`blocksonly` of course does not follow this as it has no mempool, but mo=
st
> fullnodes are not `blocksonly`).
> If you intend to aggregate transactions in the mempool, then at the worst
> case a fullnode will be validating every non-aggregated transaction, and
> that is what we want to limit by increasing the weight of heavy-validatio=
n
> transactions.
>
> Regards,
> ZmnSCPxj
>

--00000000000015bc2b05fadfdefd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi ZmnSCPxj,<div><br></div><div>I do mean to have speciali=
zed computing power vendors, which could happen to be miners, or not. Optim=
ing ZKP computations is rather different from Bitcoin mining so I expect th=
ose vendors to be from more research-driven teams focused in cryptographic =
engineering.=C2=A0</div><div><br></div><div>I am open to whether to put tho=
se transactions in mempool or not. I apologize for giving an inaccurate num=
ber earlier about the verification cost. I just ran gnark-bench on my Mac M=
2, it turns out the cost for Groth16 verification could be as fast as 1ms. =
For Plonk it is around 1.6ms. So it seems even a common fullnode could hand=
le thousands of OP_ZKP transactions. In that case, the ZKP transactions cou=
ld be put into mempool, and be open to be aggregated by some vendor. Fullno=
des should verify these transactions as well. It does not seem a good idea =
to treat them with special rules as there is no guarantee that certain OP_Z=
KP transactions will be aggregated or recursively verified. Of course, the =
weighting should be well benchmarked and calculated. The cost for those *st=
andalone* OP_ZKP transactions might be higher due to more data and/or highe=
r weighting. This incentivizes vendors to develop aggregation / recursive v=
erification services to drive down the fee requirements and profit from doi=
ng so (fee extraction). I also expect to see an open market where various v=
endors can compete against each other, so it makes sense to have these tran=
sactions openly visible to all participants.=C2=A0</div><div><br></div><div=
>Meanwhile, some transactions are meant to be off-chain. For example, a wou=
ld-be smart contract can aggregate many related transactions in a OP_ZKP tr=
ansaction. Those aggregated transactions should *not* be transmitted within=
 the Bitcoin network. They could even be *not* valid Bitcoin transactions. =
Usually the smart contract operator or its community could host such a serv=
ice.=C2=A0</div><div><br></div><div>Consider a potential situation in a few=
 years: there are thousands of active smart contracts based on OP_ZKP, and =
each block contains a few hundred OP_ZKP transactions, each one of them agg=
regates / recursively verifies many transactions. The effective TPS of the =
Bitcoin network could far exceed the current value, reaching the range of t=
housands or even more.</div><div><br></div><div>Hope this clarifies.</div><=
div>Weiji</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Tue, May 2, 2023 at 11:01=E2=80=AFPM ZmnSCPxj &lt;<a hre=
f=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Good morning Weiji,<br>
<br>
&gt; Meanwhile, as we can potentially aggregate many proofs or recursively =
verify even more, the average cost might still be manageable.<br>
<br>
Are miners supposed to do this aggregation?<br>
<br>
If miners do this aggregation, then that implies that all fullnodes must al=
so perform the **non**-aggregated validation as transactions flow from tran=
saction creators to miners, and that is the cost (viz. the **non**-aggregat=
ed cost) that must be reflected in the weight.<br>
We should note that fullnodes are really miners with 0 hashpower, and any c=
ost you impose on miners is a cost you impose on all fullnodes.<br>
<br>
If you want to aggregate, you might want to do that in a separate network t=
hat does ***not*** involve Bitcoin fullnodes, and possibly allow for some k=
ind of extraction of fees to do aggregation, then have already-aggregated t=
ransactions in the Bitcoin mempool, so that fullnodes only need validate al=
ready-aggregated transactions.<br>
<br>
Remember, validation is run when a transaction enters the mempool, and is *=
*not** re-run when an in-mempool transaction is seen in a block (`blocksonl=
y` of course does not follow this as it has no mempool, but most fullnodes =
are not `blocksonly`).<br>
If you intend to aggregate transactions in the mempool, then at the worst c=
ase a fullnode will be validating every non-aggregated transaction, and tha=
t is what we want to limit by increasing the weight of heavy-validation tra=
nsactions.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--00000000000015bc2b05fadfdefd--