From: "Russell O'Connor" <roconnor@blockstream•com>
To: Trey Del Bonis <trey.delbonis@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Validity Rollups on Bitcoin
Date: Fri, 4 Nov 2022 16:29:26 -0400 [thread overview]
Message-ID: <CAMZUoK=O967fgNkmbEcLAJ6N54GuT7vwAAP5FFvKLoYtoD4=2A@mail.gmail.com> (raw)
In-Reply-To: <629da3d8-ee34-9acb-511b-4af1913eceff@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 2049 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 2744 bytes --]
next prev parent reply other threads:[~2022-11-04 20:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-11 15:40 John Light
2022-10-12 13:28 ` Greg Sanders
2022-10-12 15:40 ` John Light
2022-11-02 17:19 ` AdamISZ
2022-11-04 19:53 ` Trey Del Bonis
2022-11-04 20:29 ` Russell O'Connor [this message]
2022-11-04 23:07 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMZUoK=O967fgNkmbEcLAJ6N54GuT7vwAAP5FFvKLoYtoD4=2A@mail.gmail.com' \
--to=roconnor@blockstream$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=trey.delbonis@protonmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox