1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
Return-Path: <AdamISZ@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 99E34C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Nov 2022 17:19:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 60E7881E06
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Nov 2022 17:19:37 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 60E7881E06
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=vKJQMVyH
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id R9AOuW8bKt8z
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Nov 2022 17:19:36 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org A53A781758
Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch
[185.70.40.134])
by smtp1.osuosl.org (Postfix) with ESMTPS id A53A781758
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Nov 2022 17:19:35 +0000 (UTC)
Date: Wed, 02 Nov 2022 17:19:23 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1667409572; x=1667668772;
bh=Jbqbed08rK+NuGnYKdOeIMS6iTmoeB963KKOFoVLptY=;
h=Date:To:From:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=vKJQMVyHqZrMOC97j7fed0zhxelOF7QW6qHpDj9Il0O3RTe0/KIOwm7Xy328ztXtz
ndQ7JHQIzUzUyR0Zl0gSTjM+Y85MNeB06cqKF3Xz78rV+KMFaqFCPOKS8uJd6iNkFN
pgQD8pdKGEyFhCeDnjEPX8sf7lwESgCOPEHc29OX+MBlDQNdJnpFxhWsWpKsVGU6Ok
MD9RPYtKZfq7iLWbmF6swoB85HHasENduNJohp7639Z+QNSKPlryadRQSIfiAGtLdq
C1BH3l+zSdDS/klgNQnA4ueFU9yqJIeyrlTgdlO4n6PEm36RyhtpGDsvBRCNK2rqZj
Pq46zUIX3kVNg==
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
X-Mailman-Approved-At: Wed, 02 Nov 2022 17:41:11 +0000
Subject: Re: [bitcoin-dev] Validity Rollups on Bitcoin
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Nov 2022 17:19:37 -0000
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
|
