Date: Wed, 02 Nov 2022 17:19:23 +0000
To: John Light <bitcoin-dev@lightco.in>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: AdamISZ <AdamISZ@protonmail.com>
Message-ID: <WJ0jiInq_I_IiiT8EiAZZN6axo2pSIRCxQWfyvgU-4rjRmeHnCXFNGWFSXoeOv7nVmqoAPr6EHeXRgc-1DfiPX3C8xHwdYzs2qn4Lck06fs=@protonmail.com>
In-Reply-To: <224cf2f4-2577-4331-9977-ea71e9723ffe@app.fastmail.com>
References: <689ed481-e7eb-4fea-8ca7-578503f3f285@app.fastmail.com>
 <CAB3F3Dt5oy93duGvYb7SZ7wn7DCvn9FjVwRU9ENNa79yjzmdCQ@mail.gmail.com>
 <224cf2f4-2577-4331-9977-ea71e9723ffe@app.fastmail.com>
Feedback-ID: 11565511:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Validity Rollups on Bitcoin
Precedence: list

Hi John,

Sorry for late feedback. Very much appreciated the in depth report!

So, I second Greg's main question, which I've really been thinking about a =
bit myself since starting to research this area more: it feels like the Bit=
coin protocol research community (or, uh, some of it) should focus in on th=
is question of: what is the minimal functionality required onchain (via, pr=
esumably soft fork) that enables something close to general purpose offchai=
n contracting that is provable, ideally in zero knowledge, but at the very =
least, succinctly, with onchain crypto operations. An example might be: if =
we had verification of bilinear pairings onchain, combined with maybe some =
covenant opcode, does it give us enough to do something like a rollup/sidec=
hain model with full client side computation and very compact state update =
and verification onchain? (To be clear: just made that up! there is certain=
ly no deep theory behind that particular combination .. although I did see =
this [1] thread on *optimistic* + covenant).

Is the actual answer to this something like Simplicity? (Above my paygrade =
to answer, that's for sure!)

Ideally you would want (don't laugh) for this to be the 'soft fork to end a=
ll soft forks' so that innovation could all be then in higher layers.

As to rollups themselves: centralization in the sequencer/publisher of stat=
e updates seems to be a really big issue that's somewhat brushed under the =
carpet. Depending on the model, there are cases where it actually is a thef=
t risk (e.g. full control of an onchain smart contract), but there's signif=
icant censorship risk at the very least, as well as availability/uptime ris=
k. At the extreme, Optimism has a 'security model' [3] that is frankly laug=
hable (though, no doubt it's possible that will radically change) and for t=
hings like Arbitrum you have centralized sequencers, where the claim is tha=
t it will migrate to a more decentralized model; maybe, but that's a huge p=
art of the challenge here, so while it's nice to see the sexy 'fast, cheap,=
 scale' aspect straight away, I feel like those models haven't done the har=
d part yet. I also think these optimistic L2 models have a 'fake finality' =
issue from my perspective; the delay needed onchain is how long it takes to=
 *really* confirm. (e.g.: rollups look cool compared to sidechains from the=
 pov of 'instant' instead of confirmations on a chain, but that seems a bit=
 sleight-of-hand-y).

It's notable to compare that with a payment-channels style L2 where decentr=
alization and trustlessness are sine-qua-non and so the limitations are muc=
h more out in the open (e.g. the capacity tradeoff - while the 'instantness=
' is much more real perhaps, with the appropriate liveness caveat).

For the validity rollups, some of the above qualms don't apply, but afaik t=
he concrete instantiations today still have this heavy sequencer/publisher =
centralization. Correct me if I'm wrong.

In any case, I do agree with a lot of people that some variant of this mode=
l (validity rollups) intuitively looks like a good choice, for the future, =
in comparison with other possible L2s that focus on *functionality* - with =
a mild censorship and centralization tradeoff perhaps.

And I'm maybe a bit heretical but I see no issue with using 1 of N security=
 models for trusted setup here (note how it's probably different from base =
chain), so PLONK type stuff is just as, if not more, interesting than STARK=
S which aiui are pretty big and computationally heavy (sure, maybe that cha=
nges). So if that's true, it comes back to my first paragraph.

Cheers,
AdamISZ/waxwing

[1] https://nitter.it/salvatoshi/status/1537362661754683396
[3] https://community.optimism.io/docs/security-model/optimism-security-mod=
el/


Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, October 12th, 2022 at 16:40, John Light via bitcoin-dev <bitc=
oin-dev@lists.linuxfoundation.org> wrote:


> On Wed, Oct 12, 2022, at 9:28 AM, Greg Sanders wrote:
>=20
> > Is there a one page cheat sheet of "asks" for transaction
> > introspection/OP_ZKP(?) and their uses both separately and together for
> > different rollup architectures?
>=20
>=20
> We do not have this yet. Trey Del Bonis wrote a more detailed technical p=
ost about how those components would be used in a validity rollup, which wa=
s cited in my report and can be found here:
> https://tr3y.io/articles/crypto/bitcoin-zk-rollups.html
>=20
> But it'll take more research and design work to suss out those details yo=
u asked for and put them into a nice cheatsheet. I like this idea though!
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev