MIME-Version: 1.0
References: <689ed481-e7eb-4fea-8ca7-578503f3f285@app.fastmail.com>
 <CAB3F3Dt5oy93duGvYb7SZ7wn7DCvn9FjVwRU9ENNa79yjzmdCQ@mail.gmail.com>
 <224cf2f4-2577-4331-9977-ea71e9723ffe@app.fastmail.com>
 <WJ0jiInq_I_IiiT8EiAZZN6axo2pSIRCxQWfyvgU-4rjRmeHnCXFNGWFSXoeOv7nVmqoAPr6EHeXRgc-1DfiPX3C8xHwdYzs2qn4Lck06fs=@protonmail.com>
 <629da3d8-ee34-9acb-511b-4af1913eceff@protonmail.com>
In-Reply-To: <629da3d8-ee34-9acb-511b-4af1913eceff@protonmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Fri, 4 Nov 2022 16:29:26 -0400
Message-ID: <CAMZUoK=O967fgNkmbEcLAJ6N54GuT7vwAAP5FFvKLoYtoD4=2A@mail.gmail.com>
To: Trey Del Bonis <trey.delbonis@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c83c2705ecaaee7e"
Subject: Re: [bitcoin-dev] Validity Rollups on Bitcoin
Precedence: list

--000000000000c83c2705ecaaee7e
Content-Type: text/plain; charset="UTF-8"

On Fri, Nov 4, 2022 at 4:04 PM Trey Del Bonis via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Instead of that approach, I assume we have fairly granular transaction
> introspection opcodes from a list in Elements [2] (which seem like they
> aren't actually used in mainnet Liquid?)


These opcodes went live on Liquid along with Taproot <
https://blog.liquid.net/taproot-on-liquid-is-now-live/>, so feel free to
try them out on Elements or Liquid.

One complicated part is the actual proof verification.  I had considered
> looking into what it would take to build a verifying for a modern proof
> system if we used pairings as a primitive, but it turns out even that is
> pretty involved even in a higher level language (at least for PLONK [3])
> and would be error-prone when trying to adapt the code for new circuits
> with differently-shaped public inputs.  The size of the code on-chain
> alone would probably make it prohibitively expensive, so it would be a
> lot more efficient just to assume we can introduce a specific opcode for
> doing a proof verification implemented natively.  The way I assumed it
> would work is taking the serialized proof, a verification key, and the
> public input as separate stack items.  The public input is the
> concatenation of the state and deposit commitments we took from the
> input, the batch post-state commitment (provided as part of the
> witness), data from transaction outputs corresponding to
> internally-initiated withdrawals from the rollup, and the rollup batch
> data itself (also passed as part of the witness).
>

I'd be interested in knowing what sort of Simplicity Jets would facilitate
rollups.  I suppose some pairing-friendly curve operations would do.  It
might not make the first cut of Simplicity, but we will see.

Simplicity's design doesn't have anything like a 520 byte stack limit.
There is just going to be an overall maximum allowed Simplicity evaluation
state size of some value that I have yet to decide.  I would imagine it to
be something like 1MB.

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

<div dir=3D"ltr">On Fri, Nov 4, 2022 at 4:04 PM Trey Del Bonis via bitcoin-=
dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a>&gt; wrote:<br><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><br>
Instead of that approach, I assume we have fairly granular transaction<br>
introspection opcodes from a list in Elements [2] (which seem like they<br>
aren&#39;t actually used in mainnet Liquid?)</blockquote></div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote">These opcodes went li=
ve on Liquid along with Taproot &lt;<a href=3D"https://blog.liquid.net/tapr=
oot-on-liquid-is-now-live/">https://blog.liquid.net/taproot-on-liquid-is-no=
w-live/</a>&gt;, so feel free to try them out on Elements or Liquid.<br></d=
iv><div class=3D"gmail_quote"><br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
One complicated part is the actual proof verification.=C2=A0 I had consider=
ed<br>
looking into what it would take to build a verifying for a modern proof<br>
system if we used pairings as a primitive, but it turns out even that is<br=
>
pretty involved even in a higher level language (at least for PLONK [3])<br=
>
and would be error-prone when trying to adapt the code for new circuits<br>
with differently-shaped public inputs.=C2=A0 The size of the code on-chain<=
br>
alone would probably make it prohibitively expensive, so it would be a<br>
lot more efficient just to assume we can introduce a specific opcode for<br=
>
doing a proof verification implemented natively.=C2=A0 The way I assumed it=
<br>
would work is taking the serialized proof, a verification key, and the<br>
public input as separate stack items.=C2=A0 The public input is the<br>
concatenation of the state and deposit commitments we took from the<br>
input, the batch post-state commitment (provided as part of the<br>
witness), data from transaction outputs corresponding to<br>
internally-initiated withdrawals from the rollup, and the rollup batch<br>
data itself (also passed as part of the witness).<br></blockquote><div><br>=
</div><div>I&#39;d be interested in knowing what sort of Simplicity Jets wo=
uld facilitate rollups.=C2=A0 I suppose some pairing-friendly curve operati=
ons would do.=C2=A0 It might not make the first cut of Simplicity, but we w=
ill see.</div><div><br></div><div>Simplicity&#39;s design doesn&#39;t have =
anything like a 520 byte stack limit.=C2=A0 There is just going to be an ov=
erall maximum allowed Simplicity evaluation state size of some value that I=
 have yet to decide.=C2=A0 I would imagine it to be something like 1MB.<br>=
</div></div></div>

--000000000000c83c2705ecaaee7e--