An engineering and implementation perspective
Disclaimer: this document just collates, links and include work published across many articles and contributions. the respective credits (including of images extracted from these links) goes to the respective authors/developers of the work.
ps: Special thanks goes to Ethereum R & D discord (especially to @vbuterin and @piper ) for helping understand some of the aspects of Kate. Additional gratitude to @vbuterin for reviewing the document.
pps: This document was developed for the benefit of 🌟 lodestar team, an awesome ETH POS client in works based on typescript enabling ETH everywhere, but also to enable the author's understanding of the ETH ecosystem and innovations.
Hopefully this will benefit other developers/techies from all around the world. All rights of this work waived through CC0
A wholesome guide to familiarize, summarize and provide pointers to deep dive into proposed used of Kate Commitments while staying in ethereum's context.
Aim of the document is more summarization and less rigor, but please follow the links as they explain in detail what is being talked about.
For e.g. h1=H(t1,t2,t3..)
, and give h1
to the verifier (for e.g. in a block header), and then give a tempered block (t1,t2',t3...)
, one would be able to fast calculate the integrity of the block and reject it as the tempered block.
Similarly root of a merkle tree is a commitment to the leaves and their indexes (paths), or in short to the map of indexes => values
.
Proof here is the merkle branch and its sibling hashes which can be used to check the consistency all the way to the merkle root.
The map of indexes => values
can be represented as a polynomial f(x)
which takes the value f(index)=value
courtesy of Lagrange Interpolation . This f(index)=value
is called evaluation form and the more typical representation f(x)=a0+ a1.x + a2.x^2...
is called coefficient form. Intuitively, we fit a polynomial on the (index,value)
points.
For optimizations, and for one to one mapping between polynomial and data map, instead of just index
as x
in f(x)
, w^index
is used i.e. f(w^index)=value
where w
is the d
th root of unity where d
is the degree of the polynomial (the maximum index value we are trying to represent), so that FFT can be deployed for efficient polynomial operations like multiplication and division which are of the O(d)
in evaluation form and can be converted back into coefficient form in O(d*log(d))
. So its still beneficial to keep d
small.
addresses => (version,balance,nonce,codeHash,storageRoot)
Ethereum currently use merkle trees and more specifically patricia merkle tries to commit to EVM data (EVM state, block transactions or transaction receipts and may be in near future contract code as well) , that can be
Trie
structure here gives that piece by piece capability.
Given a large d
-ary trie with size N
leaves, any leaf change will take O(log-d(N))
nodes updation (all the way to the root) to compute the new root
reflecting new state, which requires additional (d-1)*O(log-d(N))
sibling nodes Hashes/Commitments as witnesses for both time (and space if light clients are to be served). In a block, which is a batched update of lets say m
random leaf updates where m<<N
, only a very small percentage of nodes will be expected to share the witnesses and computations and hence the update Order
wouldn't change much for per update.
This problem is compounded even further (because of size of the witness data) in following scenarios:
In an experiment on stateless ethereum, the block proof sizes of 1MB were observed (of which majority of them were merkle proofs), which would even blow up in multiples in times of an attack.
One way to get around this is binary merkle trees taking d
out of the picture but then the depth of tree would increase but it would still remain O log(N)
Following properties are desirable for any ideal commitment scheme to have for committing to data in the block headers
index=>value
map) in an incremental wayKate commitment based constructions are the result of search of pursuing such an ideal scheme. Vanilla Kate excel at first three.
Kate commitment as such is just another Hashing scheme, but it doesn't Hash 'bytes', it hashes polynomials.
It actually is the evaluation of the polynomial f(x)
at a secret (fixed) value s
but represented on an elliptical curve i.e. [f(s)]=f([s])
, which requires a trusted setup ( of the sorts of zcash genesis) to generate [s]
, [s^2]
, … [s^d]
(to plug into the polynomial wherever there is x^i
) where d
is the max degree we would deal in.
Here notation [t]
means elliptical curve value at point t
which is basically t[1]
i.e. generator [1]
of the additive group on the elliptical curve added t
times (modulo Fp
). All operations on the curves are some modulo Fp
where Fp
imposes some field on the curve.
value
in the indexes=>values
map has also to be represented on an elliptical curve as curve element [value]
to calculate commitment (as you will see later). This imposes restriction on size of value
to be modulo Fp
~ BLS Curve order ~ somewhere between 31-32
bytes. For simplicity, it gets restricted to 31
bytes, any bigger value
will need to be chunkified and appropriately represented with its index
s (or truncated).[t]
can be treated as Hash of t
as obtaining t
from [t]
is discrete log problem known to be intractable for secure curves.s
is a secret and should be unknown forever to all/any but elliptical curve points [s]
, [s^2]
…[s^d]
as well as evaluation on another curve [s]'
(whose generator is [1]'
, only [s]'
is required) are generated, known, shared and public at trusted setup time.These are sort of system parameters which define the security of out entire system, as knowing s
would allow the attacker to construct any sort of proofs. So in a multi party trusted setup where N
participants come together to generate the setup in a protocol of combining their own local s
, even if 1
participant is honest and destroys his contributing s
, the system is fully secure. i.e. risk is ~ 1/N
and higher the number of participants, lower the risk!
[]
is a linear operator i.e. [x]+[y]=[x+y]
. also a[x]=[ax]
As mentioned before, we represent our data map (index=>value
) as f(w^index)=value
i.e. evaluation form of the polynomial (or in other words we fitted a polynomial here on these (w^index,value)
points).
So Kate commitment C(f)
of a polynomial f(x)
is elliptical curve point f([s])
which can be computed by plugging [s]
,[s^2]
… into expanded form of f(x)
.
f(s)
can't be computed as s
is unknown but C(f)=[f(s)]=f([s])
can be!f(x)
: C(f)=[f(s)]
is also a linear operator i.e. C(f+g)=C(f)+C(g)
.Rollups/Aggregators can use this property to update the commitments. In evaluation form, updating an evaluation point will lead to complete change in f(x)
but still its commitment C(f)
can still be easily updated using this property
[s]
,[s^2]
…[s^d]
is performed for upto d
exponents, then its impossible to represent commitment of any polynomial with degree >d
and viceversa.As there is no way multiply two curve points to get another curve point in secure curves, so [s^(d+k)]
can't be evaluated (ever!) and conversely it can be argued that any commitment C(f)
can only represent a polynomial of degree <=d
.
f(x) - some remainder
can be factored in a particular way, but this requires a way to multiply the factors and compare with the original commitment C(f)=f([s])
.For this we need pairing equation which is just a multiplication scheme for two points on curve and comparing it with the candidate point, since we can't directly multiply two curve points to get the resultant curve point.
f(x)
a particular commitment C(f)
represents, is of a low degree k
(< d
)So whats the good thing about this:
y=f(r)
of the underlying polynomial at any point r
and evaluation of the quotient polynomial q(x)=(f(x)-y)/(x-r))
at [s]
i.e. q([s])
and comparing with the previously provided commitment f([s])
using the pairing equationr
, and q([s])
is the proof. one can easily see that q(s)
is intuitively the quotient p(s)-r
divided by s-r
which is exactly what we check using the pairing equation i.e. check (f([s])-[y]) * [1]'= q([s]) * [s-r]'
r
as randomness only matters with respect to inputs we are trying to prove. i.e. once commitment C=f([s])
has been provided, r
can be obtained by hashing all inputs (r=Hash(C,..)
), where the commitment provider has to provide the opening and proof.f([s])
,q([s])
can be directly computed from the evaluation form. To compute an opening at r
, you would convert the f(x)
to coefficient form f(x)=a0+ a1*x^1....
(i.e. extract a0
,a1
,…) by doing the inverse FFT which is O(d log d)
, but even there is a substitute algorithm available to do it in O(d)
without applying (inverse)FFT
.f(x)
at their respective index
s, i.e. multiple index=>value
i.e. index1=>value1
, index2=>value2
… indexk=>valuek
i.e. k
data points using the single opening and proof
q(x)
the quotient polynomial (to calculate proof) is now the quotient if we divide f(x)
by the zero polynomial z(x) =(x-w^index1)*(x-w^index2)...(x-w^indexk)
r(x)
(r(x)
is a max degree k
polynomial that interpolates index1=>value1
, index2=>value2
… indexk
=valuek
)( f([s])-r([s]) )* [1] ' = q([s]) * z([s]')
In the sharded setup of the POS chain where the sharded data blobs will be represented as a low degree polynomial (and extended for erasure coding into twice its size using the same fitted polynomial), the Kate commitment can be checked against random chunks to validate and establish availability without needing siblings datapoints and hence enabling random sampling.
Now, for a state with possible 2^28
account keys, you would require atleast 2^28
degree polynomial (total account keys space can be much much bigger) for just a flat commitment construction. There are some downsides to that if updates and inserts are to be done. And any change in any one of those accounts will trigger the computation of the commitment (and more problematic witnesses/proofs)
k
index=>value
points, let say at indexk
, will require k
to update the commitment again using the corresponding Lagrange polys ~O(1)
per updatef(x)
has changed, all the witness q_i([s])
i.e. witness of i
th index=>value
will need to be updated ~ O(N)
q_i[s]
witnesses, any witness calculation from scratch requires O(N)
sqrt(N)
Hence for the 4rth point of ideal commitment we need a special construction: Verkel tries
The ethereum state that needs to be represented is 2^28 ~= 16^7 ~= 250m
size indexes=> values
map. If we just build a flat commitment (d
we would need will be atleast ~2^28
) then despite our proof still being O(1)
of the size of elliptical curve element
of 48 bytes, any insert or update will require either O(N)
updates to all precomputed witnesses (the q_i(s)
of all the points, as f(x)
has now changed) or O(N)
on the fly computation per witness if no precomputed witnesses are maintained.
Hence we need to move away from a flat structure to something called Verkle Trees which you will notice is also a trie like its merkle counterpart.
i.e. Build a commitment tree in same way as merkle, where we can keep d
low at each node of the tree (but can still go as high as ~256
or 1024
).
index => child values
where index
is the child's index
at that particular parent node.32
bytes size values (check note on size).32
byte hash of data that those leaves store or directly to data if its only 32
byte data as in case of proposed State Tree as mentioned in next section. (check note on size)D
,E
can be generated along with their openings at point relatively random point t
again using fiat shamir heruristic.This is an analysis of verkle branch multi proof
index=>value
will required log_d(N)
commitment updates ~ log_d(N)
f_i(X)/(X-z_i)
at [s]
for D
which is in total O(d log_d N)
, but can be pushed to save precomputes at update/inserts which will push its order to O d log_d(N)
m
~O( log_d(N) )
number of terms: f_i(t)
to evaluate h(t)
which is total O (d log_d N)
π
, ρ
which requires division of sum of m~ log_d N
exponent-ed polys ~O(d log_d N)
to get to the evaluation form of the numerator in order to compute the divisionE
) plus verification order ~ O( log_d(N) )
A single trie structure for account header, code chunks as well as storage chunks with node commitments of degree d=256
polys
storageKey
which essentially is a representation of the tuple (address,sub_key,leaf_key)
65536
chunks of 32
bytes(check note on size)65536*32
bytes is represented as a single depth-2 subtree, there can be many such subtrees in the main trie for storage of an account.(address, sub_key, leaf_key)
WITNESS_CHUNK_COST
for every unique access eventWITNESS_BRANCH_COST
for every unique address,sub_key
combinationCode will automatically become part of verkle trees as the part of unified state tree.
WITNESS_CHUNK_COST
and one main WITNESS_BRANCH_COST
for accessing account.One of the goals of ETH POS is to enable to commit ~1.5MB/s of data (think this throughput as the state change throughput and hence transaction throughput that layer 2 rollups can use and eventually layer 1 EVM) into the chain. To achieve this, many parallel proposals will be done and verified at any given ~12
second slot, and hence multiple (~64
) data shards will exists, each publishing its own shard blob every slot. Beacon block will include the shard blobs which have >2/3
voting support, and the fork choice rule will determine if the beacon block is canonical based on the availability of all the blobs on that beacon block and its ancestors.
Kate commitment can be used to create data validity and availability scheme without clients accessing full data published across shards by the shard proposer.
16384
(32 byte
check note on size) samples ~512kB
with the shard header comprising mainly of corresponding max 16384
degree polynomial commitment to these samples
D
of the evaluation representation of polynomial is 2*16384
size i.e. 1
,w^1
,…w^
,… w^32767
where w
is the 32768
th root of unity
and not 16384
.16384
degree polynomial on the data (f(w^i)=sample-i
for i<16384
), and then extend(evaluate) it to 32768
places (i.e. evaluate f(w^16384)
… f(w^32767
) as erasure coding samples16384
samples out of 32768
can be used to fully recover f(x)
and hence the original samples i.e. f(1)
,f(w^1)
,f(w^2)
… f(w^16383)
2048
chunks of these erasure coded 32768
samples (each chunk containing 16
samples i.e. 512 byte
chunks) are published by the shard proposer horizontally (i
th chunk going to 'i'th vertical subnet along with their respective proof), plus globally publishing the commitment
of the full blob.k~20
vertical subnets for the assigned (shard,slot)
to establish availability guarantees
~128
committee per (shard,slot)
out of which atleast ~70+
should attest to availability and validity i.e. 2/3
of the committee attesting for successful inclusion of shard blob in the beacon chain.~262144
validators (32
slots * 64
shards * 128
minimum committee size)` requiredAs we can see from the POC verkle go library after one time building of verkle
for the size of state tree, the inserts and updates to verkle
will be pretty fast.
PS: if you like this document and think this adds value to the ecosystem you could tip the author at: 0xb44ddd63d0e27bb3cd8046478b20c0465058ff04