We already presented the details of the Plonk component and how it can be used to represent different kinds of arithmetic relationships and therefore can be used to verify all kinds of computation. In this article, we will focus on the other component, Poseidon, which indeed has a much trickier and more intricate design.

The full recursive proof generation for Stwo has completed, and one can find the related source code in GitHub:

• Proof systems: https://github.com/Bitcoin-Wildlife-Sanctuary/stwo-circle-poseidon-plonk

• Recursion circuits: https://github.com/Bitcoin-Wildlife-Sanctuary/recursive-stwo

• Bitcoin verifier: https://github.com/Bitcoin-Wildlife-Sanctuary/recursive-stwo-bitcoin

We now dive into the detail of the Poseidon component of the proof system.

The role of hash functions in STARK

We just mentioned that the Plonk component, which was already discussed in the Part I article, can represent all kinds of computation, which, of course, also includes Poseidon hash functions. One may be curious about why we need a dedicated Poseidon component in the proof system, as one can just use Plonk to take care of the same computation.

The reason is about the cost of verifying Poseidon in Plonk. Throughout the entire STARK proof verification as part of the recursion, there are several places that involve hash functions, as shown in the figure below.

STARK uses Fiat-Shamir transform, which is used to generate the randomness in the zero-knowledge proof. This transform uses the output of the hash functions for such randomness. The specific procedure of the Fiat-Shamir transform has to do with the “size” of the proof system and the circuit. When the proof system that is being recursively verified has a lot of columns, the Fiat-Shamir transform may end up invoking hash functions a lot.

Then, STARK also uses proof-of-work (also known as grinding) as an optimization for verifiers. This would also require the verifier to compute the hash function, but it is usually only once.

What follows Fiat-Shamir transform and proof-of-work is all about Merkle trees—during STARK proof generation, some data is committed into Merkle trees, and the verifier opens the Merkle trees on random locations to check if the data matches up. This would constitute the majority overhead involving hash functions because STARK proof verification needs to open a number of Merkle trees, and since the check needs to be conducted on many random locations, the process is repeated a few times.

Experiments show us that, when doing recursive proof verification, the overhead involving hash functions can easily become the dominating overhead. This needs to be taken care of because we want to, eventually, verify the Stwo proof on Bitcoin or Ethereum, and this requires us to be able to recurse a larger proof into a small proof. If the recursion circuit is too complicated, one may run into the problem that recursion ends up increasing the verification overhead because the recursion circuit is larger than most applications that we care about.

Now that we have discussed why Poseidon requires more dedicated efforts instead of using Plonk to compute Poseidon hash functions directly, we want to talk about its overhead and how making dedicated columns can help verify Poseidon hash functions faster.

Poseidon hash function

The hash function that we use is Poseidon2. Today, this is a well battle-tested hash function that becomes almost the crown prince, especially because many other ZK-friendly hash functions, including Griffin, Arion, Anemoi, Rescue, have been shown to be weaker than originally expected and need larger parameters (see [1], [2], [3]).

We instantiate the Poseidon2 hash function over the Mersenne-31 field. Each input or output consists of two parts following the sponge construction: one called rate that is expected to be public, and one called capacity that is expected to remain private.

To achieve 128-bit security, each rate and capacity needs to be at least (around) 256 bits, so we set the rate and capacity to each consist of 8 elements of M31. That is to say, the input or output to the hash function would have 16 elements of M31, as shown below.

Poseidon2 will perform a sequence of transformations on the input to generate the output. At a high level, it starts with some linear transformation that preprocesses the input, and then it continues with 4 full rounds, 14 partial rounds, and then 4 full rounds.

Note that the full rounds are the first 4 and the last 4 rounds of such transformations. This is why it also receives the name “external” rounds, as they encapsulate the 14 partial rounds in the middle, which is also called “internal” rounds for this reason.

Full rounds differ from partial rounds, in that full rounds perform more heavy computation, while the partial rounds are more lightweight—nevertheless, there are more partial rounds. Since we will need to go into the detail of our Poseidon component, we now should discuss how the full rounds and partial rounds work.

Full round. In Poseidon2, a full round performs three steps.

• Add the current state (rate and capacity, in total 16 elements) with round constants, which are round-specific, fixed but random M31 elements.

• Apply S-box to each element of the state. In our case, the S-box maps x to x^5.

• Perform a linear transform with a 16x16 MDS matrix.

The first step and the last step are linear transformations (additions and multiplications by known and fixed constants), and representing them in ZK circuits is straightforward. The second step involves a degree-5 arithmetic transformation.

Previously, if we use Plonk to represent such relations, we run into the issue that each row in the Plonk component can either do one addition or one multiplication, and therefore, the full round would generate a number of rows.

• The first step, adding round constants, would basically generate 16 rows, while each row adds one element in the state by a corresponding constant.

• The second step, applying the S-box, would contribute 48 rows, while every three rows takes care of mapping one element from x to x^5.

• The last step, performing the MDS matrix, might be most expensive, as it would contribute 120 rows.

This adds up to 184 rows per full round. We will show, later in this article, how to do 2 full rounds in one row in the Poseidon component.

Partial round. The computation in full rounds is called “full” in that each and every element in the state (in total 16 elements) gets the S-box. Since S-box consumes more compute resources than the rest of the operations because it involves multiplication while the rest can be mostly implemented through additions, researchers have decided to reduce the use of S-box while preserving the security, at the cost of having more rounds (more frequent “diffusion”).

So, in Poseidon2, other than the 4 full rounds at the beginning and 4 full rounds at the end, there are also 14 partial rounds lying between them (and therefore called the internal rounds). It also has three steps, but the computation at each step is much more lightweight:

• Add the *first element* of the current state with a round constant, while the remaining 15 elements stay unchanged.

• Apply the S-box to only the *first element* while keeping the rest of the elements unchanged.

• Perform a linear transformation that is a lightweight matrix.

Implementing a partial round in Plonk is possible, and the cost would be smaller than a full round, but still a lot.

• The first step generates only one row.

• The second step generates only three rows.

• The last step involves 47 rows.

This adds up to 51 rows per partial round, and there are 14 such rounds. However, we can do much better than this. We will later show how to do 14 partial rounds in a single row in Stwo with the Poseidon component.

Idea for optimization

Before we present our construction of the Poseidon module, we first want to discuss how to optimize from the baseline (using Poseidon) and why such an optimization is possible.

Remember from the Part I article that the overhead for the prover is dominated by the number of columns times the number of rows (in other words, the number of cells in the proof system).

When we use the Plonk proof system to represent the computation, remember that each row can perform one addition or one multiplication, and each row has 10 + 12 + 8 = 30 columns. Based on our computation above, the entire Poseidon evaluation requires 2186 rows, and correspondingly 65580 cells.

This is in contrast to the construction that we will show later, which uses 6 rows in the Poseidon component, where the Poseidon component has 96 columns. This only uses 576 cells, reaching an improvement on prover time by at least 114x.

There are many reasons that contribute to the slowdown of the baseline approach, but we can summarize them into two aspects:

• The Plonk proof system has too many columns that are underutilized when running a Poseidon function.

• The Plonk proof system cannot represent linear operations in the Poseidon function efficiently.

Underutilization. Remember that the Plonk proof system that we discuss uses QM31 as elements. However, the Poseidon2 hash function that we use is defined over M31. This already means that out of the 12 “trace” columns, 9 of them are dummy and would all be zero.

Then, remember that the rest of the Plonk proof system is taking care of passing variables from one row to another. A lot of columns are actually used for this purpose. For example, among the 10 preprocessed columns, three columns “a_wire”, “b_wire”, “c_wire” are used to give an identifier for the A, B, C variables, and three columns “mult_a”, “mult_b”, “mult_c” are used for the logUp arguments. For each row, we also have 8 interaction columns for logUp.

This means that, when we perform additions over 16 elements, we need 16 rows, and each row would require independent and dedicated logUp columns. But, in fact, these 16 elements are processed often in a batch, and, being intermediate variables of the hash function computation, they would not be used in other places in the proof system, but just immediately consumed by subsequent rounds (the 4+14+4 rounds in the Poseidon) function. The power of the logUp argument to pass variables to any other rows in the proof system, for an arbitrary number of times, is an overkill.

One can think of the Plonk proof system as a very generic purpose CPU that has a random access memory—data can be read or written for arbitrary number of times, at any place of the program—and also a high CPU word size that processes 4 elements at the same time, but we often only use one element in evaluating the Poseidon hash function. This CPU is unaware of the batch operations that we are performing, and it gets and puts each element within the batch treating them as unrelated.

We address such underutilization, informally, by designing the Poseidon proof system as a dedicated CPU that performs operations in batch, including batch access to the memory, with also less frequent access to the memory by doing more computation steps between each access. It processes 16 elements each row. Before it uses the logUp argument, it either applies 2 full rounds in this row, or applies 14 partial rounds in this row, while previously even a single round may have 51 to 184 rows.

We will present the details very soon, but one can see that eliminating the redundancy and underutilization of the Plonk proof system can materially reduce the prover cost.

Inefficiency. The other reason for the slowdown is that it doesn’t represent the linear relations in the most efficient way. For example, consider a full round. If we use the Plonk proof system to implement the full round, all the three steps of the full round—adding round constants, applying S-box, and performing linear transform—all contribute to rows, and we know that the linear transform contributes the most. These rows lead to cells, which lead to prover inefficiency. From our previous computation, a full round leads to 5580 cells.

However, if we only focus on the computation related to the full round, in the purest form, this seems doable with only 48 cells, 16 cells for the round constants, 16 cells for the input, and 16 cells for the output. Note that round constants are preprocessed columns that the prover doesn’t have to commit every time.

The equation between these columns are, of course, more complicated—it is degree-5, it involves a lot of variables, but it is indeed very easy to verify.

• Additions are very efficient to compute.

• All the weights (w_{i,j} in the figure) are all very small values, and there are algorithms to evaluate this (the MDS matrix) very efficiently.

By using these equations to handle the 16 elements altogether, the number of the cells involved in the computation is significantly lower—in the example above, you can see that adding round constants does not introduce additional columns (other than the round constants preprocessed columns that the prover doesn’t need to compute), and the linear transform via the MDS matrix contributes to no columns as well.

The same applies to partial rounds. Applying the same rule of thumbs, we know that for each partial round, adding the round constant (which only involves the *first element*) only requires one preprocessed column, but no other columns, and the linear transform would involve no column. In this way, processing 14 rounds needs just about 14 + 16 + 16 = 46 columns.

Since 46 is smaller than 48, we can actually let the full rounds and partial rounds share the columns. Some rows will be for “full rounds”, so these columns are used for the full-round computation, while the other rows will be for “partial rounds”, where the same columns are instead used for partial-round computation.

Our construction

We here present the high-level construction of the Poseidon component, but we skip the detail about the logUp argument, which we already discussed in the Part I article. We will present a simplified version, and readers who want to learn about the full version can look at our implementation here in GitHub.

Each invocation of the Poseidon hash function would create 6 rows in the Poseidon component. There are two control columns, “First round?” and “Full round?”, that are changing in these 6 rows, and they directly impact how the 48 columns of input, intermediate, outputs are used.

The first row performs a linear transform (the MDS matrix) on the input, skipping the S-Box or round constants. This is a standard and necessary preprocessing step in Poseidon2. In recent years, doing so is known to be important for security.

After the first row, we have the second row and the third row for the first 4 full rounds, where each row takes care of two full rounds altogether. Within each row,

• The first full round applies to the 16 input columns and writes its output to the 16 intermediate columns.

• The second full round applies to the 16 intermediate columns and writes its output to the 16 output columns.

The logUp argument, which we skip here, is in charge of connecting the output of the first row (the input after the linear transformation) to the input of the second row, and so on and so forth.

The fourth row, which has both “First Row?” and “Full round?” set to zero, will complete all 14 partial rounds. We store the result after the first 4 full rounds in input, and we store the result after the 14 partial rounds in output. As for the intermediate columns, we use 14 out of 16 of them to store the first element after the S-box in each round, due to some technical necessity to do so.

Then we continue with another two rows, each taking care of 2 full rounds. So, we have completed all the 4 + 14 + 4 rounds of the Poseidon hash function.

There are some other columns and logic in the Poseidon component in our implementation that we are not presenting here: they take care of the inputs and outputs between the rows and with the Plonk component (through the logUp arguments discussed in the Part1 article). We also let the Poseidon component take care of swapping the first half and second half of the inputs given a bit, which is mostly used for Merkle tree path verification. The details of such extensions can be found in the code, but each Poseidon evaluation still only contributes to 6 rows.

Writing the recursion circuits

The full proof system for recursion proof verification in Stwo is the combination of the Plonk component and the Poseidon component. We program primarily in the Plonk component, and only when we use the Poseidon hash function, it programs in both components.

We write the recursion circuits in Rust, using a DSL similar to the one that we used to write Bitcoin scripts (which we discussed in a previous article). This DSL allows us to convert existing Rust code in the StarkWare’s Stwo library into the DSL code for circuits.

For example, in the Poseidon component, we need to perform the linear transformation in a full round, the corresponding Rust code in StarkWare’s Stwo library (here) looks like this. This Rust code takes in four field elements (x[0], x[1], x[2], x[3]), performs a series of additions, and outputs a few values as the result (t6, t5, t7, t4).

When we write the recursion circuit, we adapt basically the same code and make only a few mechanical edits, as shown below. The mechanical edits include using “QM31Var”—a DSL-powered data structure that is capable of recording operations for DSL—for the variables, and changing the “clone” into passing-by-references.

This DSL also allows us to mirror existing data structures and arrays in StarkWare’s Stwo libraries into DSL-powered ones.

For example, in Stwo, we have “ColumnSampleBatch” that is used for arranging the evaluation points and the columns together. We can create a one-to-one mapping in the DSL, called “ColumnSampleBatchVar”, and we can use it in place of “ColumnSampleBatch” when we adapt the code directly from Stwo.

We follow this procedure to implement the entire STARK verifier in DSL. On my 2023 MacBook Pro with the M3 Max chip (which was funded by Starknet airdrop) with 14 cores, it takes about 1 second to 3 seconds to recurse a modest size proof.

To give a concrete number, we ran a benchmark with the following configuration.

• The recursion circuit verifies a proof that is also a recursion circuit, with 2^16 rows in the Plonk component, and 2^16 rows in the Poseidon component.

• The proof being verified is optimized for prover efficiency and sacrifices verifier efficiency (which is the typical example to use recursion), by using a blow-up factor of 2.

• The verification above is repeated 5 times in total.

Here is a breakdown of the number of rows, by each step of the Stwo STARK proof verification, for a single time of the verification (out of five repetitions) .

• Fiat-Shamir: 1189 rows in the Plonk component, 840 rows in the Poseidon component.

• Composition: 2063 rows in the Plonk component, no Poseidon rows.

• Compute FRI answer and decommitment: 176947 rows in the Plonk component, 42720 rows in the Poseidon component.

• Folding: 51682 rows in the Plonk component, 120480 rows in the Poseidon component.

It takes 14.27s on my laptop to generate such a proof. On average, it means 2.85s for each proof to be recursively verified.

Note that the recursion time would be different if the proof is for a larger circuit, or if the proof uses a higher blowup factor (which would significantly reduce the verification overhead). Specifically, if we increase the blowup factor from 2 to 4, the amount of work in computing the FRI answer and folding would be halved.

We anticipate that using machines with more cores will further improve the latency—but this probably shouldn’t be the focus of optimization. As we mentioned in the Part I article, the power of recursion is to allow a very large compute task (e.g., verifying a block in Ethereum) to be sliced into many small chunks and be assigned to a large number of instances, where each instance takes care of one or a few chunks.

Then, when the instances complete the proof generation for each chunk, they use recursion to merge proofs together.

Let us do a concrete calculation. Assuming that the original computation takes about 100 hours to compute. By slicing it into 100 chunks, we can have 100 machines to finish the corresponding chunks in one hour.

Then, we use 20 machines to each merge 5 proofs into a single proof, through the recursion circuit above, which likely takes 15s, and it results in 20 proofs. We then use 4 machines and repeat the same process, which takes another 15s and results in only 4 proofs. We just need to use one final machine to merge the proof, which is approximately another 12s. This only adds an additional overhead of less than 1 minute to the original computation.

As the Part I article says, this fundamentally changes how we scale ZK proofs. Previously, we may try to optimize for single-machine prover efficiency by, for example, using a beefy machine with hundreds of cores. In practice, it has been shown that using many cores doesn’t improve the performance linearly—you may have increased the number of cores from 16 to 192, but the performance improvement is less than 2x.

This is very common in practice and often limits the scalability of single proof generation for ZK. Recursion has been the only approach to break this limitation. Instead of using larger machines, it is both more efficient and more cost-effective to entail a number of smaller machines.

Usage in Bitcoin STARK verifier

The recursive verifier that we have built is also used for Bitcoin STARK verification, which converts a ZK proof that is more prover-efficient to a ZK proof that is more verifier-efficient. By repeating this step multiple times, we can have a proof that is extremely verifier-efficient that is suitable for Bitcoin verification.

Our Bitcoin STARK verifier indeed involves a lot more optimization than what we have covered in this article. Here, we outline them for interested readers, but they all belong to the idea of using recursion to convert a proof from prover-efficient to verifier-efficient.

Switching hash functions. We generate the first Plonk proof using Poseidon hash functions, which is good for recursion, but evaluating the Poseidon hash function on Bitcoin (even with OP_CAT) is not very efficient.

What we do is that, in the last proof, which is the result of layers of layers of recursion, we no longer use Poseidon, but we switches to using SHA-256 as the hash function. Therefore, the Bitcoin STARK verifier, which is implemented in Bitcoin script and uses the Bitcoin execution environment, can simply use the SHA-256 opcode that is available in Bitcoin (subject to the availability of OP_CAT, without which the opcodes would not be as useful).

Although we have been focusing on OP_CAT, and the existing construction relies on OP_CAT, this ability to switch hash functions would also be useful for verifying STARK proofs in BitVM. Currently, in BitVM, we primarily use Blake3 hash functions since implementing it in Bitcoin script turns out to be the easiest. Recursion can also straightforwardly change the hash function from Poseidon to Blake3.

Increasing the blowup factor. We previously mentioned, in this article and in the Part I article, that one can trade-off between the prover efficiency and the verifier efficiency, and that can be done in multiple ways. The easiest way is to increase the blowup factor.

For example, to get the most efficient prover, we use the blowup factor as low as 2. This would require about 80 FRI queries inside the STARK proof verification protocol to achieve a desired level of security. However, we can change this factor while keeping the same security level.

• If we increase the blowup factor from 2 to 4, we only need 40 FRI queries.

• If we increase it to 8, we need 34 FRI queries.

• If we increase it to 16, we need 20 FRI queries

• If we increase it to 32, we need 16 FRI queries.

• If we increase it to 512, we only need about 9 FRI queries.

Though the verifier efficiency depends on a number of factors, looking at the ballpark number, the fewer the number of FRI queries is, the faster the verifier is. Note that this comes at the cost of a slower prover. For example, when we use a blowup factor of 512, the prover is doing 256x of the work compared with a blowup factor of 2—this is useful only if we are specifically smoothening the proof to be extremely verifier efficient—such as verifying it on Ethereum or Bitcoin as the last layer. In those cases, because on-chain verification could involve an expensive fee, it is financially worthwhile to increase the prover time (only at the last recursion proof) for better performance. In practice, it only takes about hundreds of seconds of computation.

Last-level recursing without Poseidon. Note that the verifier cost depends on a number of factors. The number of columns in the proof system, however, is also one of them.

In the Part I article, we introduced our recursion proof system, which consists of 30 columns for the Plonk component and 96 columns for the Poseidon component. A natural question is whether we can remove the Poseidon component for the last layer (knowing that, as a cost, it would make the prover slower), so that there would be fewer columns.

This is exactly what we do for the Bitcoin STARK verifier where, in the last layer, we use a Plonk component only, but this Plonk component has additional modifications (which can be found here) for processing Poseidon more efficiently without Plonk. Doing so, of course, will increase the number of rows in the Plonk component, and it grows with the number of invocations to the hash function throughout the entire proof verification process—mostly, as we see, from the Merkle trees that are used in decommitment and folding.

The number of the Poseidon operations could become a bottleneck for prover efficiency and in fact, also verifier efficiency. Therefore, we use a new technique to delegate most of the hash operations out to the Bitcoin script, which can be more efficient in evaluating certain hash functions such as SHA-256—of course, not Poseidon. So, we will switch hash functions again, make the “second to last” proof use SHA-256 instead of Poseidon, and then, when the last layer verifies this proof, it delegates the SHA-256 hash operations to Bitcoin. We find that this approach helps us manage the Bitcoin STARK verification cost better.

It is useful to point out that this approach also helps a STARK verifier on Ethereum.

Conclusion

In this article, we continue from the previous article and describe the Poseidon component of our recursive proof system for Stwo. We show why the dedicated Poseidon component can give rise to better performance, and support it with the concrete evaluation.

We are working with StarkWare to integrate the recursive proof techniques built here (for Bitcoin STARK verifier) into StarkWare’s Stwo proof system for settlement to Ethereum and Bitcoin, including BitVM-based Bitcoin bridges.

Find L2IV at l2iterative.com and on Twitter @l2iterative

Author: Weikeng Chen, Research Partner, L2IV

Disclaimer: This content is provided for informational purposes only and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisors as to those matters. References to any securities or digital assets are for illustrative purposes only and do not constitute an investment recommendation or offer to provide investment advisory services.

Recursive proofs

Before we define recursive proofs, we want to present three challenges in deploying zero-knowledge proofs in production.

The first challenge is memory constraints for large-computation proof generation. When generating a zero-knowledge proof, the larger the computation is, the larger the amount of memory needed, and it can go up to 256GB or 512GB, making it infeasible to fit in most consumer machines or even some cloud instances.

This becomes a serious issue when it comes to zkRollup, which usually runs a zkVM that processes a few blocks. Since each block can have a lot of transactions and each transaction can consume a lot of gas and thereby being computationally heavy, the overall computation adds up very quickly and can go to several TBs. It is infeasible to find machines with such a large memory that can generate a zkVM proof in one shot.

Recursive proofs can help with this by slicing the computation into smaller chunks that can fit into the memory constraints and generating a proof for each part of the computation. In the illustration above, we slice the computation into four chunks and create four individual proofs.

The verifiers can choose to simply verify the four proofs individually and check if the computation has been sliced correctly, but it means that the verifier needs to receive more data and do more work to verify the proofs.

For on-chain proof verification like the case in Ethereum or Bitcoin with OP_CAT, we want to minimize the verifier overhead, so we have another step that creates a proof that consolidates all these four proofs together. Specifically, it proves that:

This allows the verifier to only verify one proof, and this proof can be even smaller and easier to be verified than each of the four proofs, if we configure the proof system, here Stwo, properly. What is more, although having recursive verification means that additional proofs need to be generated, they tend to be small proofs that take only a small fraction of the overall proof generation time.

In summary, there are situations when proving a very large computation in one shot and in one proof is infeasible. Slicing the computation into smaller chunks and using recursive proof verification to compose them together solve this challenge.

The second challenge is parallel and distributed proof generation. This is especially useful for zkRollup because even the largest machine available in AWS has only 192 vCPU, and even with a very efficient proof system, it may take a lot of time to generate a proof, and for zkRollup, it would result in a settlement latency.

The latency, however, can be drastically shortened with recursive proof verification. Think that I have some computation that is expected to take one machine 100 hours. I can slice it to 100 chunks, expecting that each chunk takes one hour. Now, if I have 100 machines, I can distribute the proof generation among them as follows:

• Let each one of the 100 machines prove one chunk. This takes one hour to finish.

• Now, turn off 90 machines, and use only 10 machines. Each machine uses recursive verification to consolidate 10 proofs into one. This takes probably 1 minute.

• Turn off 9 machines, and use only one machine. This machine uses recursive verification to consolidate the 10 proofs into one. This takes another minute.

In this way, we generate a proof in one hour plus two minutes, instead of 100 hours, thanks to the ability to distribute the recursive proof generation among multiple machines. The benefit of using cloud servers is that you can scale up and down almost arbitrarily. Math does the magic: the cost of renting a cloud instance to do 100 hours is similar to the cost of renting 100 cloud instances each to do one hour, so you are not even increasing the cost with recursive proofs.

The third challenge is the battle between prover efficiency and verifier efficiency. This has been especially an issue for zkVM and zkEVM because in order to make proof generation efficient, the VM has many application-specific components. For example, zkEVM usually has customized components in the proof system for Keccak256 and elliptic curves. These special components have been indispensable, but they contribute to on-chain verification overhead (which takes $ETH).

One example is CairoVM and its “builtins”, which are special customized components in the proof system that takes care of certain computation. As the very first zkVM in the industry, these designs in CairoVM were inherited in many subsequent zkVM or zkEVM that we see today. In an article “Builtins and Dynamic Layouts”, StarkWare shared some benchmark data on how builtins improve the prover efficiency.

• Pedersen is 100x faster to be proven with builtins.

• Poseidon is 54x faster to be proven with builtins.

• Keccak is 7x faster to be proven with builtins.

• EC_OP is 83x faster to be proven with builtins.

However, there is a cost for using builtins, in that the verifier efficiency will decrease. To understand why this is the case for modern proof systems. We need to dive a little deeper on what prover efficiency and verifier efficiency looks like.

In modern proof systems, the computation to be proven is often organized/translated into a table with rows and columns, basically a spreadsheet. Columns are often organized into groups, and they take care of different functionalities. A builtin is usually implemented as a new group of columns.

The proof system defines some relations between the cells in this table. For example,

• We can enforce the first column of each row (say column A) to be either 0 or 1.

  • For every row i, Ai = 0 or 1. I.e., Ai * (Ai - 1) = 0

• We can enforce that the third column (say column C) equals the sum of the first column and second column (i.e. addition), say column A and B.

  • For every row i, Ci = Ai + Bi

• We can enforce that the fourth column (say column D) equals to the third column (say column C) in the previous row.

  • For every row i, Di = C{i-1}

These are just simple relations. When we deal with hash functions like Keccak256 or SHA256, chances are that it would consist of hundreds of columns and a long list of such arithmetic relations.

How does the table relate to the prover efficiency and verifier efficiency? Say that the table has X rows and Y columns.

• Prover’s work in generating the proof is largely related to the number of cells in the table, i.e., X * Y, number of rows times number of columns.

• Verifier’s work in verifying the proof is linear to the number of columns, but only logarithm to the number of rows, i.e., Y * log(X). Specifically, the verifier’s work relates to the complexity of all the arithmetic relations that need to be checked.

Builtins are effective for prover efficiency because although they increase the number of columns, the net total of the number of cells are significantly reduced. This, however, usually leads to increased verifier overhead, simply because there are more columns and the relations between the columns get more complex.

Recursive proof verification comes to rescue. The idea is that, for sufficiently large computation, it is always “better” if we use a hybrid of two proof systems:

• The first proof system is optimized for prover efficiency, with a modest verifier efficiency. The proof from the first proof system is not going to be verified on-chain.

• The second proof system is optimized for verifier efficiency and is specifically designed for verifying proofs from the first proof system. The proof from this second proof system will be verified on-chain.

Note that other than the need to design two proof systems to fulfill this purpose, there is really no downside for playing with two proof systems. One just gets improved prover efficiency and verifier efficiency altogether. This idea was originally from Madars Virza from MIT called zk-SHARKs in 2019 and has since evolved to be a standard practice.

Design recursive proofs in Stwo

In recursive proofs, the core task is to build a proof system that is used to verify a Stwo proof (i.e., run the computation of a Stwo verifier).

Designing this dedicated proof system is not trivial because a naive implementation could easily lead to a recursive proof that is larger than the original proof, making the final proof “harder to verify”. This is especially the case for hash-based proof systems because hash functions tend to be very expensive to verify in ZK proofs.

There is flexibility in picking hash functions. Stwo can work with many hash functions: Blake2s, Blake3, Poseidon2, and SHA-256. Among these hash functions, Poseidon2 is easiest to be verified, but running Poseidon2 in a naive proof system (that does not have Poseidon2 builtin) can easily be inefficient.

So, we build a proof system over Stwo that is dedicated to verifying Stwo proofs. It consists of two components: (1) Plonk and (2) Poseidon. Most of the logic of a Stwo verifier is implemented in Plonk, but whenever the verifier needs to compute a Poseidon2 hash, it delegates it to the Poseidon component. The two components are connected to each other through the LogUp checksum from Ulrich Haböck.

We believe that this is a fairly tidy and well-crated design, and we will show later that it delivers favorable performance. In this article series, we aim to provide you with the details of these components. Here we go!

The Plonk component has 10 + 12 + 8 columns:

• The first 10 columns are called “preprocessed” columns. They are descriptions of the Stwo verifier and do not depend on the proofs, so the prover can compute them once and doesn’t have to compute again. They are listed as follows: “a_wire”, “b_wire”, “c_wire”, “op”, “mult_a”, “mult_b”, “mult_c”, “poseidon_wire”, “mult_poseidon”, “enforce_c_m31”. We will explain their meanings soon.

• The next 12 columns are called “trace” columns. Every 4 columns represent a degree-4 extension of the M31 field element, where M31 means a number modulo the Mersenne prime 2^31 - 1. This is the basic unit of computation in a Stwo verifier. So, the 12 columns represent three such numbers, called “a_val”, “b_val”, “c_val”. We will soon discuss what they are, but the Stwo verifier computation is defined over this degree-4 extension.

• The last 8 columns are for LogUp checksum that connects different rows in the Plonk components together as well as connects the Plonk component to the Poseidon component.

The Poseidon component has 40 + 48 + 8 columns:

• The first 40 columns are also “preprocessed” columns. They are independent from the input and output of the hash functions, but rather, it provides some descriptions.

  • It starts with four columns “is_first_round”, “is_last_round”, “is_full_round”, “round_id” that describe whether this row corresponds to the first round, the last round, and/or a full round in the Poseidon2 hash function as well as the round index.

  • It is followed by 32 columns for round constants of the Poseidon2 hash function.

  • Finally there are four columns “external_idx_1”, “external_idx_2”, “is_external_idx_1_nonzero”, “is_external_idx_2_nonzero” that indicate which row in the Plonk component should correspond to this row—which connects the two components together.

• The next 48 columns are “trace” columns. It consists of three Poseidon2 states (each state has 16 elements), one as the input state, one as the intermediate state, and one as the output state.

• The last 8 columns, similarly, are for the LogUp checksum.

In this article, we will focus on the Plonk component and talk about how it works, as well as why we designed it in this way. In the Part II article, we will discuss more on the Poseidon component. And in the Part III article, we will devote ourselves to how to build a Bitcoin-verifier-friendly proof system, which involves some niche details only of interest to Bitcoin.

Arithmetic relations between A, B, C

We start with the most intuitive part of the Plonk component. This involves a preprocessed column “op” and 12 trace columns forming degree-4 extensions “a_val”, “b_val”, and “c_val”.

It can be then used to define addition and multiplication relationships between these values.

• When op = 1, we have C = A + B

• When op = 0, we have C = A * B

• When B = 0, we have C = op * A, which can be seen as multiplying A with a proof-independent constant op

With additions and multiplications, one can perform the rest of the arithmetic operations.

• Subtractions like A - B can be done by first negating the subtrahend B by multiplying it with -1 and then adding A and (-B) together.

• Divisions in the prime field A / B are often defined as A * (B^-1) where B^-1 is the multiplicative inverse of B such as B * (B^-1) = 1. This is done by presenting the modular inverse, using B * (B^-1) = 1 to check that it is the correct modular inverse, and then multiplying it with A.

However, there are two issues with this simple relation.

We start with the easier one. Note that A, B, C are all on the degree-4 extension of the M31 field, called QM31. An element in QM31 can be written, similar to complex numbers, as:

where i and j are units. A can also be viewed as a vector [a0, a1, a2, a3].

Although we can perform all kinds of operations over QM31, there is almost no way to enforce that an QM31 element is also a M31 element (i.e., a1 = a2 = a3 = 0). This is, however, necessary in the Stwo verifier, as some elements are supposed to be M31 rather than QM31.

To do this, we have another column, “enforce_m31”, which enforces C to be an M31, meaning that the second, third, fourth columns that represent “c_val” should be zero.

Although “enforce_m31” only enforces C, we will soon show how it can be used to enforce A and B to be M31 elements in an indirect way. This is exactly the other issue.

As one can see, although we can do a single addition or a single multiplication in one row, to be able to fit in more complicated computation, even subtraction and division, we will need to use more than one row, where the result C in a row could become input A in the other row.

But at this moment, we do not have a way to enforce that C here becomes A in another row. This is necessary for subtractions because subtrahend multiplied by -1 would need to appear in another row to compute the difference.

This is where “wire IDs” come into play, where for each value, we assign an ID. Values from the same ID, which could be in different rows, must stay the same. In this way, different rows can be connected together.

So, as the figure below shows, in each row, there are now three preprocessed columns “a_wire”, “b_wire”, “c_wire”. They are the corresponding wire IDs of A, B, and C.

Values with the same IDs, which could be in the same row or in different rows, must have the same value, so one row can now “continue” the computation unfinished by another row. The guarantee that values with the same IDs must be the same is enforced by the LogUp technique as follows.

Use LogUp to connect values across rows

LogUp is a technique by Ulrich Haböck, proposed in 2022, that can be used to connect values (and their IDs) across different rows in the table.

The idea is that, if all the values and IDs are consistent, we can derive “mult_a”, “mult_b”, “mult_c” for each row that satisfy the following equations.

In this equation, H is a random and unpredictable hash function that is selected by the verifier. Basically, this hash function would output the same number if the two inputs—wire ID and the value—are the same, but this number would be random and cannot be predicted by the prover. That is to say, if two inputs have the same wire ID but different values, their outputs from this hash function will be different, and the prover cannot predict the difference between the outputs.

“mult_a”, “mult_b”, “mult_c” can be set purely based on “a_wire”, “b_wire”, and “c_wire”. For example, if a specific wire ID has been used for 16 times in the entire table (which could be in positions A, B, or C), we can set the first “mult_X” value for this wire ID to be “-15”, and all the remaining “mult_X” for this wire ID be “1”. In this way, across the table, all the fractions with respect to this wire ID will add up to zero.

If all the wire IDs are being configured correctly in this way, then the total sum as above will also be zero.

Now, if there is any input that the wire ID and value have inconsistency, the LogUp paper proves that the sum will not be zero, with an overwhelming probability, thanks to the unpredictability of the hash function. This hash function can be concretely constructed using two random variables, “α” and “z”, both of which are chosen by the verifier after the prover has committed all the trace columns.

To compute the checksum of the entire table, there are 8 more columns used to aggregate the sum, and every 4 columns represent the intermediate aggregated result. We denote them as “sum_1” and “sum_2”.

As the figure shows, “sum_1” is simply the sum of the fractions for A and B, and “sum_2” adds the fraction for C and the previous row’s “sum_2” into “sum_1”. And the LogUp technique cleverly leverages a trick that in Circle STARK, the previous row of the first row of the table is “defined” as the last row of the table, so the first row will also add “sum_2” of the last row of the table. It can be shown that if the “sum_2” relation can be satisfied even in this circular manner, then all fractions for A, B, C in all rows add up to zero. Below is an example where the first row has sum_2[0] and the last row has sum_2[7]. The computation of sum_2[0] will involve sum_2[7], but sum_2[7] also depends on sum_2[0]. This can only happen when the total sum is zero.

Note that there are still “poseidon_wire” and “mult_poseidon” which will be involved in “sum_2” as well that we omit for now. They are used to enforce consistency on values shared between the Plonk component and the Poseidon component, and we will discuss that in Part II.

Next steps

In this article, we presented the design details of the Plonk component, the design of which can be summarized as two parts. One part takes care of the basic arithmetic operations (additions and multiplications) for three values A, B, and C within a row, and another part takes care of enforcing consistency between values under the same IDs across rows using the LogUp technique.

In the next article, we will dive into the design of the Poseidon component as well as how it interacts with the Plonk component. After presenting the two components, we will show how the recursive verifier can be implemented within these two components.

Find L2IV at l2iterative.com and on Twitter @l2iterative

Author: Weikeng Chen, Research Partner, L2IV

Disclaimer: This content is provided for informational purposes only and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisors as to those matters. References to any securities or digital assets are for illustrative purposes only and do not constitute an investment recommendation or offer to provide investment advisory services.

Fraud proofs are basically computation that can be publicly disputed before the computation goes into effect (i.e., after withdrawal period). To make the computation publicly disputable, there are two key requirements: (1) efficient on-chain challenge, in that the computation can be disputed on-chain, and (2) data availability, in that the public can obtain enough information to dispute the computation.

Fraud proofs have many tradeoffs. One can slice the computation into smaller or larger chunks, and one can have more or fewer rounds in the protocol. Fraud proofs also allow modifications. For example, user experience of fraud proofs has been impacted due to withdrawal periods. Satellite solutions such as fast confirmations can remedy the user experience by allowing third parties to facilitate verified withdrawals, often for smaller amounts, to be available instantly.

Although we often separate optimistic rollup and ZK rollup, aka fraud proofs vs validity proofs, they are two techniques that can be combined together, and this is important for our topic today—verifying fraud proofs on Bitcoin. Let us start with BitVM.

BitVM

BitVM is an innovative design proposed by Robin Linus back in December 2023. The first version of BitVM solely used fraud proofs, no ZK proofs at all, to enable programmability in Bitcoin. At a high level, the program is converted into a boolean circuit where signals take in the form of 1 and 0. The circuit consists of boolean gates that take two input wires and make one output wire. For example, the NAND gate outputs 0 if both input wires are 1, and outputs 1 otherwise. There can be many different boolean gates. The input wires are often output wires of another gate. Any program can be formatted into a boolean circuit.

In BitVM, if the program execution is incorrect, the challenger can find at least one output wire that is incorrect. The challenger can ask the operator to reveal the two input wires for this output wire. If the output wire is incorrect, then at least one of the two input wires must be incorrect, and the challenger can continue doing so until the operator eventually (1) fails to respond according to the protocol or (2) reveals the same input wire on both 0 and 1 (being used in one gate as 0 and used in another gate as 1), which would be a contradiction.

When either of those happen, BitVM can slash the operator, and that is where the security comes from. When the operator violates the protocol, the operator will lose the “security deposit”.

• If the operator fails to respond according to the protocol within a certain time window (similar to a withdrawal period), the challenger can slash the operator so that the operator loses the security deposit.

• If the operator reveals the same input wire on both 0 and 1, the challenger can similarly slash the operator.

The innovation of BitVM is how to implement these two slashing conditions in Bitcoin script.

The first slashing condition is done through pre-signed transactions (generated and agreed by both the operator and the challenger) and Bitcoin native lock-time mechanism. Pre-signed transactions force the operator to follow a chain of challenge-response, in which the only thing that an operator can do at a time is to “respond” correctly to a challenge. If the operator did not respond in time, the pre-signed transactions offer an “unhappy” path that slashes the operator, which would be executable by the challenger if the operator has “timeout” from making a response.

The second slashing condition is done by having the challenger show two conflicting digital signatures of the input wires. In the BitVM protocol, when the operator reveals a certain input wire, the operator is also asked to generate a digital signature of the wire identifier and the value on that wire. If the operator misbehaves, the challenger can see two signatures, signing on the same wire identifier, but with different values. By showing these two signatures, the challenger can slash the operator.

Note that slashing alone is not sufficient for fraud proofs. As we mentioned in the Part I article, there is a subtle difference between fraud proofs and slashing:

• “Fraud proofs do not rely on slashing. If the computation is wrong, there is always a way to challenge and invalidate the computation, so that the incorrect state can never be materialized on the L1 chain.”

• “Slashing protocols do rely on slashing. If all the nodes are not afraid of being slashed (for example, someone bribes them to misbehave and will compensate for being slashed), even if the computation is wrong, it still can be accepted.”

This would be a problem in the first version of BitVM in that it can only achieve slashing, but it wouldn’t be a fraud proof protocol. If the operator is managing billions of dollars but only has a security deposit of a few millions, the operator is almost “incentivized” to misbehave. Making the security deposit very high is possible, but it leads to a cost usually proportional to the amount of the deposit, as the operator could have used the money in lending protocols (in CEX and DEX) to earn passive income.

This limitation is sort of inherent to the programmability of Bitcoin script (without OP_CAT). So, in August 2024, a new version of BitVM was published, called BitVM2, which focuses on a special use case where slashing happens to be sufficient for fraud proofs.

BitVM2 as a lock-and-mint bridge

Unlike the first version of BitVM which focuses on general computation, BitVM2 focuses on a specific use case—lock-and-mint cross-chain bridge. It might sound very limited that BitVM2 only supports a specific type of cross-chain bridge, but this is exactly the missing fundamental part for bridging Bitcoin to other chains in a trust-minimized manner.

Today, we do have some cross-chain solutions that bridge BTC to Ethereum and other chains, including wBTC (wrapped BTC) and cbBTC (Coinbase BTC), but they are mostly custodian based. For example, in wBTC, to mint BTC on another chain, one needs to send Bitcoin BTC to a multisig wallet, which is held by institutions in the WBTC DAO. And cbBTC is a centralized solution backed by Coinbase. There are benefits of centralized approaches in that they are flexible and sometimes with a lower cost, usually with good user experience, but it would not be a trust-minimized solution.

The lack of trust minimization is usually the cause of depegging for stablecoins because during a sudden sell-off, people may not be very confident that the custodians are solvent. There are numerous examples of depegging, and while most are temporary as in the case of Tether and Circle, some stablecoins vanished away after depgging, such as TerraUSD. Kraken has an article talking about the history of stablecoin depegging.

Depegging with BTC hasn’t really happened much, but wBTC also once had a minor depegging, which was temporary, when Alameda and FTX fell apart in December 2022.

A more recent and related example for BTC is THORChain. It is not a stablecoin or a wrapped BTC, but a lending protocol in which users can use BTC as collateral and lend other assets such as RUNE. The lending protocol itself, however, has the issue of “Death Spiral Dynamics”, in that when people lose confidence in RUNE and want to redeem BTC back, RUNE price will continue to drop. Although wrapped BTC is not a lending protocol, we can learn a lesson from THORChain, in that it is important that the protocol is designed in such a way that under “any market conditions”, one can redeem BTC back 1:1.

This leads to the core motivation of BitVM2—building a lock-and-mint bridge. Say that we have a bridge between Bitcoin and Ethereum.

• To mint a new wrapped BTC in Ethereum, Alice locks 1 BTC in Bitcoin into a BitVM2 program. It is publicly verifiable that this BTC has been correctly deposited into a valid BitVM2 program.

• To redeem the wrapped BTC in Ethereum back to a native BTC in Bitcoin, Bob sends the wrapped BTC to a smart contract in Ethereum, which would “burn” this wrapped BTC. Then, an operator finds a suitable BitVM2 program with a locked BTC. The operator sends one native BTC to Bob on the Bitcoin network and then executes the BitVM2 program with a claim that the operator has correctly sent the native BTC to a user according to the unwrapping protocol. People can challenge this claim.

• If the claim is not challenged, the operator receives 1 native BTC, which equals the 1 BTC that the operator sent Bob previously. If the claim is challenged and proven incorrect, the operator will not receive the 1 native BTC, as the BitVM2 program is not convinced that the operator actually sends one BTC according to the protocol.

In this use case, slashing and fraud proofs are equivalent because if the operator misbehaves, the operator simply does not receive the 1 BTC that the operator fronts to Bob previously.

An advantage of this design is that, although that BTC was originally deposited by Alice, it could be redeemed to another user, here Bob, as long as the cross-chain protocol agrees that this withdrawal is correct (per the logic defined in the BitVM2 program). This flexibility can be attained because the BitVM2 program runs a general-purpose ZKP verifier. As long as the logic, even if very complicated, can be precisely programmed into a zero-knowledge proof, BitVM2 can verify it.

BitVM2 program workflow

The detailed transaction flow in BitVM2 is complicated due to a few optimizations and security mechanisms. But the BitVM2 whitepaper also presents a simplified workflow, as follows, that should be sufficient for us to understand how it works.

When Alice deposits the 1 BTC on the Bitcoin network, it starts the deposit transaction as shown above. After the deposit, the protocol can mint a new wrapped BTC on the other chain, after verifying that the deposit is done correctly to a BitVM2 program (which can be done using a cross-chain messaging protocol).

The BTC can stay locked in the BitVM2 program for a very long period of time, until it needs to be redeemed. As we discussed above, a BTC locked by Alice can be redeemed to a different user, say Bob, as long as it fits the prescribed logic, and therefore the operator can pick any available locked BTC for unwrapping.

To redeem, the operator first fronts the capital by giving 1 BTC to Bob on the Bitcoin chain. The operator then generates a zero-knowledge proof, which can be verified (aka challenged) by the BitVM2 program. The initial state of which would be z_0 as shown in the figure above.

The operator triggers the "Request payout” through a transaction, including the initial state z_0 as shown in the graph. At this moment, anyone on the Bitcoin chain can see that an operator is currently requesting a payout (due to correctly redeeming 1 BTC to Bob). If this is correct, and during the entire challenge period, nobody has challenged this proof, it reaches the “Payout” transaction on the right where the one locked BTC would be given to the operator (who fronted the capital previously to Bob).

However, if the proof is incorrect, one can challenge the proof by sending a “Challenge” transaction, in which the operator needs to reveal the intermediate computation results through an “Assert” transaction. The information in the “Assert” transaction is expected to meet the data availability needs for a fraud proof to be generated. If the challenger finds something wrong, the challenger can disprove the computation. If within the challenge period, nobody has disputed the computation, the operator can continue to redeem the 1 BTC. If no “Disprove” transaction is made within the challenge window, the operator can continue the “Payout” transaction.

The core mechanism of BitVM2 is to disprove incorrect computation. The computation here, related to wrapping and unwrapping, involves two chains’ latest states, essentially running two light clients.

First, the BitVM2 program is running a Bitcoin light client. It needs to verify that the operator has correctly sent Bob 1 BTC already (and this transaction corresponds to this withdrawal, not a previous withdrawal) on the Bitcoin blockchain. For the BitVM2 program to do so, it not only needs to examine the specific transaction for the transfer to Bob, but also verify that the transaction is on the actual Bitcoin chain, not a side chain, not a fork.

Second, the BitVM2 program also needs to run a light client that verifies the other chain where wrapped BTC are minted, for example, Ethereum. The light client will need to verify the lock-and-mint smart contract on the Ethereum blockchain has burnt a wrapped BTC, and this very BTC has been assigned to Bob.

There are solutions on how to implement the light client, with different trust assumptions and different difficulties of implementations. But usually, the computation necessary to run the two light clients is enormous in that the “Assert” transaction would be too large or the “Disprove” transaction becomes too complicated. To address this limitation, BitVM2 uses zero-knowledge proofs, in that the entire computation is wrapped into a zero-knowledge proof, and instead of doing the actual computation, the BitVM2 program merely verifies the zero-knowledge proof.

Here, we are not using the privacy property of zero-knowledge proofs, but scalability, in that the cost to verify the proof can be significantly smaller than doing the computation.

BitVM2 as a case study

Remember that in Part 1 article, we presented an information card for BitVM.

-------------
BitVM (as in BitVM 2 bridge)
-------------
Committed computation:
- verification of a ZK proof that proves the execution of the transactions
Methods to prove guilty:
- refereed delegation of computation
Methods to prove innocent:
- not being proven guilty during the withdrawal period
-------------

We can see that the BitVM2 bridge falls under the standard fraud proof paradigm, and the only difference from optimistic rollups like Arbitrum and Optimism is that the computation being verified is first wrapped into a zero-knowledge proof, and the on-chain computation is to verify this zero-knowledge proof. The reason for using zero-knowledge proofs is to reduce the on-chain computation overhead to make the challenge-response protocol on the Bitcoin blockchain affordable.

The same technique can also apply to Arbitrum or Optimism to reduce the rounds of interaction in the challenge period, as RISC Zero’s Kailua suggests.

Limitations of BitVM2 bridge

We now talk about some limitations of the BitVM2 bridge, as already listed in the BitVM2 bridge paper. Many other issues that people used to have around BitVM2 are mostly solvable with some engineering efforts, but these are open problems of BitVM2 that are somewhat inherent due to the restrictions of Bitcoin script.

• Requires a committee to presign transactions. Since Bitcoin script doesn’t have opcodes that enable covenants, additional trust assumptions are needed for the BitVM2 bridge to work, in that one needs a committee of members to generate and presign the transactions that the operator will use. These transactions will be chained together, and the operator must follow the order to invoke these transactions. Before Alice makes a deposit of 1 BTC into the protocol, Alice can examine if these transactions are correctly generated and only continue to deposit if they look correct. The security relies on at least one of the members of the committee to delete the key used to sign the transactions, otherwise, if the entire committee colludes with the operator, the system becomes insecure.

• Large, non-standard transactions. The BitVM2 bridge may have “Assert” and “Disprove” transactions that exceed the 400KB standard transaction size (which is like a soft limit), but below the 4MB hard limit. A non-standard transaction can still be accepted to the Bitcoin chain, but it often requires the collaboration of a miner, which is doable but could be costly.

• Fixed deposit amounts. The chain of transactions that the committee generates and presigns will fix a specific deposit amount, and Alice needs to deposit exactly that amount of BTC. Later, when Bob redeems the BTC on the Bitcoin chain, it would need to redeem a whole BTC, and it cannot partially redeem some of Alice’s locked BTC. Although it is possible to provide some flexibility on the amounts by pre-generating BitVM2 programs for different amounts (e.g., 0.5 BTC, 0.25 BTC, 0.1 BTC), it is not going to be as flexible as if users can specify any amount. In addition, the deposit amount cannot be too small because there is a cost to run the BitVM2 protocol.

• Operators must front BTC during peg-out. The protocol requires that the operator must front the BTC and then claim a “payout” for this BTC from the BitVM2 bridge. Because BitVM2 bridge has a challenge period, the payout to the operator will not be immediate, and the operator needs to have extra BTC to redeem more users. If there is a mass redemption, there is a possibility that the operator does not have enough liquidity in BTC to respond to all the redemption requests and has to “wait” until the payout arrives, which can take one or two weeks. In other words, a mass redemption in BTC can still be handled, but it would have to be slowed down depending on the liquidity that operators have.

• Light client security. A careful design is needed for light clients to be secure, specifically because Bitcoin script does not have magic opcodes that allow a script to introspect the Bitcoin blockchain or even learn about the latest block # or the time. A more practical solution so far until new opcodes are added is to use several third-party services, which can include Chainlink CCIP and zkBridge.

In addition, we also have the assumption that at least one of the operators would be willing to participate in the protocol, and therefore usually BitVM2 bridge needs to have multiple operators working for the same BitVM2 program, so that even if one of them does not participate, other operators may. This, of course, has a censorship risk.

Decentralization can be tricky. The specific way that the challenge protocol in BitVM2 protocol works also restricts that operators need to be permissioned for each BitVM2 program, and cannot be sourced directly from the public (or from a proof-of-stake protocol). A remedy is to have a satellite protocol with security deposits that compensates a user when operators do not respond to requests, but it can only issue compensation up to the security deposits.

To put it differently, without new opcodes being added to the Bitcoin chain, Bitcoin programmability is still naturally restricted to what BitVM2 bridge can offer, as we discuss above.

OP_CAT or other covenant opcodes

There has been a lot of discussion about opcode upgrades in the Bitcoin chain. Although there have been many proposals, most of them are around “covenants”, as listed in the discussion page in Bitcoin Wiki.

Covenants are basically Bitcoin transactions in which the corresponding Bitcoin script has the ability to look at the inputs and the outputs of the transactions. Previously, the Bitcoin script did not have these capabilities. All the Bitcoin script can do is to verify signatures on the transaction or check a few spending conditions such as lock-time for the UTXO that the script originates from, and it is why the BitVM2 bridge design has to rely on a committee to generate and presign transactions in order to enforce the workflow for the operator.

To change the situation and bring more programmability to Bitcoin, people are thinking about an opcode upgrade to Bitcoin. There are eight opcodes and one additional opcode flag being discussed, including:

• OP_CCV: CCV is short for “check contract verify”. It checks that the given input or output of a transaction is under a P2TR public key tweaked by a taptree. This opcode is intended to be used with OP_CAT.

• OP_CAT: CAT is short for “concatenation”. It is a simple opcode that pulls two strings from the top of the stack and combines them together into one string.

• OP_CTV: CTV is short for “check template verify”. Its functionality is somewhat similar to CCV, but based on a different implementation that is restricted to P2TR. It computes a hash of some information of the inputs and outputs of the transaction. This opcode is also ideally used together with OP_CAT.

• OP_CSFS: CSFS is short for “check signature from stack”. It is an extension of the CSV opcode (check-signature-verify). Both CSV and CSFS allow the script to specify the signature and the public key, but CSV doesn’t allow the script to pick the message—it verifies the signature against the transaction body, while CSFS asks the script to provide the message for signatures, which enables some delegation use cases.

• OP_PAIRCOMMIT: PAIRCOMMIT is an opcode that hashes two elements together, which can be used for Merkle tree verification. The same functionality can be realized by OP_CAT and OP_SHA256, but PAIRCOMMIT being a more restricted and specific version has the benefit that it doesn’t enable covenants, so it avoids potential risks and issues due to covenants.

• OP_INTERNALKEY: INTERNALKEY is an opcode that reads the taproot internal key for P2TR transactions. This opcode serves a very specific purpose and is mostly for lightning networks. Its functionality can somewhat be captured by OP_CCV.

• OP_VAULT: VAULT is an opcode for implementing a standard deferred withdrawal vault, which is commonly used to prevent wallet hacks. The idea is that a withdrawal from the vault will be made visible on the Bitcoin chain and deferred for a cooldown period, during which the withdrawal can be reverted. This is less related to general covenants, but it implements one of the popular use cases.

• OP_TXHASH: TXHASH is a more generalized version of CCV and CTV in that a user can specify a transaction field selector and compute the hash of those fields. This can be useful especially with OP_CAT.

• SIGHASH_ANYPREVOUT: ANYPREVOUT is not an opcode but a proposed feature flag for OP_CSV, which changes the behavior of signature verification to omit certain information on the transaction. It can somewhat be replaced by OP_TXHASH and OP_CSFS.

Developers active in the Bitcoin ecosystem have been sharing their opinions and somewhat “voting” for these protocols. Currently, the three opcodes—OP_CAT, OP_CTV, OP_CSFS—hava gained a lot of support from developers. But whether the opcodes will be added to the Bitcoin chain, and when, will require a process.

Our focus in this article is OP_CAT, as this single opcode can fulfill multiple functionalities that we need for verifying ZK proofs on Bitcoin—Merkle trees and recursive covenants. And among all these opcodes, OP_CAT is a more basic one that can already be used to build useful primitives.

We previously have shown how to use OP_CAT to build the ZK verifier for full-fledged validity proofs using StarkWare’s Stwo. It does not use fraud proofs, but just pure ZK proof verification, similar to ZK rollup, and unlike optimistic rollups. If we use it to verify (through recursive proof) a CairoVM, we will end up with a Bitcoin STARK verifier with the following properties.

-------------
Bitcoin STARK verifier (type I, validity-only)
-------------
Committed computation:
- execution of CairoVM
Methods to prove guilty: N/A
Methods to prove innocent:
- run the ZK proof verification
-------------

The issue with a full proof verification—aka validity proofs—is the cost to verify a proof. With the recent fee rate on Bitcoin mainnet 1sat/vByte and the Bitcoin price around $100k, verifying a proof will take about $1250 each. If the proof is settled every 10 hours, one would be spending around $1.1m every year for proof verification.

Although it should be doable for larger rollups with good revenue like Base ($92m last year) and Arbitrum ($42m), it is not doable for smaller rollups and individual applications (which may likely need to verify more than one proof every 10 hours), or for rollups who want to settle more frequently such as Scroll and Polygon, such as 30 minutes (which would be about 20 times more expensive, to be concrete).

To avoid such a high cost, we must avoid a full verification of the proof, while preserving decentralization. This leads to the solution of using a mix of fraud proofs and ZK proofs.

-------------
Bitcoin STARK verifier (type II, optimistic verification of validity proof)
-------------
Committed computation:
- verification of a ZK proof that proves the execution of the transactions
Methods to prove guilty:
- refereed delegation of computation
Methods to prove innocent:
- not being proven guilty during the withdrawal period
-------------

In this solution, the Bitcoin script that verifies the ZK proof is sliced into multiple segments, and the end state of each segment is revealed on-chain (so, one wouldn’t want too many segments, as it would lead to too many end states posted on-chain).

This almost removes all the on-chain cost, and the first transaction may just take a few dollars. We do not execute any segment of the Bitcoin script at this moment, so the on-chain cost, with nobody challenging it, is minimal and not related to the size of the Bitcoin script—we just need to publish a few hashes of intermediate states.

What if someone wants to challenge the proof? We can do it in two ways.

• Case 1: Operator runs the segment. The challenger labels a specific segment of the script and asks the operator to rerun this segment to show that this segment can be successfully executed.

• Case 2: Challenger runs the segment. The challenger executes the segment and shows that it cannot be successfully executed.

To avoid a malicious challenger who wants to challenge a valid proof and just wants to mess up with the operator, we can ask the challenger to bear the cost of the execution of that segment.

• In Case 1, we have the challenger make a deposit when labelling the segment, and the operator can earn this deposit when executing the corresponding segment. The deposit will cover the transaction cost of executing the segment (with leeway for fee spike).

• In Case 2, the challenger being the one that executes the segment will be directly paying the transaction fee. Similarly, since we expect each segment to be small enough after proper slicing, this cost should be manageable.

Note that, we can even move one step further, by deferring the proof generation to the time when a challenger brings it up, using the idea of Kailua from RISC Zero.

-------------
Bitcoin STARK verifier (type III, with Kailua)
-------------
Committed computation:
- execution of the transactions
Methods to prove guilty:
- requested the corresponding ZK proof verification for a section of the computation but did not provide in time
- or, after the ZK proof verification is provided, refereed delegation of computation about this ZK proof verification for a section
Methods to prove innocent:
- not being proven guilty during the withdrawal period
-------------

This design allows the operator to not generate a ZK proof unless a challenger asks for it, and the operator will be given enough time to generate the proof after the challenge is initiated. Moreover, in this design, the computation itself is sliced into several segments, and each time, the challenger asks for a specific segment for the ZK proof, rather than asking for a ZK proof for all the segments together.

Allowing the ZK proof to be requested on a segment-by-segment basis preserves the same security guarantees, because if the computation is incorrect, at least one of the segments is incorrect. It lowers the cost for the challenger to request a proof—since the challenger needs to pay for a deposit no less than the cost to generate the proof, the less amount of proof generation work implies that the deposit can be smaller, making the bar for challenging lower.

With these two changes, we can lower the net on-chain cost for the operator to be close to zero. This makes it suitable for applications with more frequent transactions. There are, however, a few disadvantages associated with the optimistic approach.

First, it may (or may not) take longer to achieve finality. Previously, when we perform a full verification of the proof, we need to wait for all the transactions necessary for the full verification to be settled on the Bitcoin blockchain. This already would take a lot of time, for two reasons:

• The full verification consists of a number of transactions and usually will be spread out across several blocks. So, naturally, the full verification will take a few blocks to settle, around 10 blocks (which would be about 2 hours).

• Operationally, since the full verification is expensive, if the fee rate is high, the operator may be inclined to wait for the fee to go down or accept a slower inclusion with a fee rate below the market price.

Using fraud proofs could make the time longer, in that we need some sort of withdrawal or challenge period to allow the challenger to examine the execution and get the challenge transaction included. Setting this challenge period is a study of its own, but in the ideal case, it is okay to assume that once the fraud proof transaction is posted on chain, within 10 minutes, a challenge can already finish the examination and submit a challenge transaction, and 1 hour can be enough for the challenge to initiate a challenge if necessary.

If the fraud proofs consist of a few rounds, the overall time for achieving finality could be longer than the full verification, but with careful design, and assuming that challengers are responsive, the finality could be achieved in a similar amount of time.

Second, it relies on challengers being online and responsive. This goal, as we discuss in the previous article, needs efforts to attain, as challengers may not have enough information/infrastructure or not have enough incentives to do so. It is especially necessary to make sure that the challengers have the software to examine the execution and submit the challenges, and that there is a sufficiently decentralized network of challengers.

Third, we are implicitly making assumptions about the lack of censorship of the Bitcoin blockchain. If, during the challenge window, all the miners decide to filter away any transaction trying to challenge the computation (for example, if miners have a financial interest in the operator’s business), then the challenge-response mechanism no longer works. Bitcoin has been known to be censorship-resistant, and there isn’t any historical event suggesting that blocking challenge transactions will happen, but we want to bring up that this is possible, especially when the challenge window is short and involves only a handful of miners.

Fourth, the program for fraud proofs is more complex. This is more like an engineering problem, but properly slicing the computation requires rewriting the Bitcoin script, and it would not be as natural as writing the full verification. Especially, remember that the previous Bitcoin script succeeds when the execution is successful, in the Case 2 of the fraud proofs, we need to revert it so that the execution is successful when the script fails (which means that the challenger detects an error). This would require a lot of work in rewriting, as our post in Bitcoin dev mailing list shows.

Conclusion

Fraud proofs have been a powerful tool in blockchain systems to provide a decentralized and low-cost way to verify off-chain computation and have seen success in optimistic rollups.

Programmability solutions for Bitcoin, including BitVM and OP_CAT-based covenants, are both using fraud proofs to either enable the programmability or lower the overhead making it affordable. This article describes how fraud proofs are used in these solutions.

Find L2IV at l2iterative.com and on Twitter @l2iterative

Author: Weikeng Chen, Research Partner, L2IV

Disclaimer: This content is provided for informational purposes only and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisors as to those matters. References to any securities or digital assets are for illustrative purposes only and do not constitute an investment recommendation or offer to provide investment advisory services.

The modern fraud proofs can be attributed to the seminal paper, “Practical Delegation of Computation using Multiple Servers”, by Ran Canetti, Ben Riva, Guy N. Rothblum, in 2011. In that paper, they built an “optimistic rollup” for x86 programs (basically any program that a computer can run), using techniques that are everywhere today for fraud proofs in EVM: bisection, Merkle hash tree, and a virtual machine.

In this article, we want to provide the background of fraud proofs. And in the upcoming Part II article, we will talk about fraud proofs in the Bitcoin ecosystem, specifically BitVM and OP_CAT-based optimistic proof verification.

Overview of fraud proofs

In fraud proofs, the computation is done off-chain, the result is being posted on-chain, and if the result is incorrect, everyone can challenge the result and invalidate the computation. Otherwise, after a period of time, often called withdrawal period, the computation is finalized on-chain.

For fraud proofs to be useful, there are two requirements:

• (efficient on-chain challenge) the computation can be challenged on-chain, at a cost much smaller than running the entire computation

• (data availability) sufficient information on how to reproduce the computation must be available to the public

Efficient on-chain challenge is achieved through smart contracts in EVM, the idea of which is that challenging only requires showing the smart contracts a very small part of the computation, which is cheap.

Data availability is application-specific, but, for example, in terms of an optimistic rollup, the public needs to know:

• the state of the blockchain prior to the execution

• the transactions

And the public expects the computation result to include a hash of all the transactions and a hash of the new state of the L2.

The public can locally execute those transactions over the prior state and see if the new state matches the result posted on-chain. If it doesn’t match, there is a fraud, and the public can challenge the rollup.

Since the prior state of the blockchain can be derived from previous transactions that appeared on the chain, the actual data availability boils down to the transactions themselves. Sometimes, data availability can be a significant part of the cost. There are different ways to reduce this cost.

Lossless compression. Arbitrum and Optimism both use Brotli, a general-purpose compression algorithm from Google, to compress the batched transaction data.

There is a reason why the compression is applied on a batch of transactions rather than each transaction individually—it improves the compression ratio. This observation was studied in a paper called MiniCrypt, which shows over a real-world dataset that batching improves the compression ratio by about 3 times. Many blockchain transactions are similar to each other, which makes batched compression even more powerful.

There still isn’t an endgame for “engineering” compression for fraud proofs, as we are still using the general-purpose compression algorithm, rather than one that specializes in Ethereum transactions. Indeed, even general-purpose compression algorithms can be made specialized by using a custom dictionary. But there is still a practicality concern, in that the complexity of the overall system would be higher with more specialized compression techniques, and whether it is worthwhile depends on the data availability cost.

Alternative data availability mechanisms. With the introduction of blobs in EIP-4844, the fees for rollups to provide Ethereum-aligned data availability have been significantly reduced. Previously, a rollup either has to store the data as regular calldata on Ethereum L1 and pays the high transaction fee or uses a third-party non-Ethereum-aligned way to store the data. Blobs introduce a cheaper option to store data on Ethereum for 18 days, which have been deemed sufficient for rollups to achieve decentralization and security.

The blob fee, however, may fluctuate. At the time of writing, to post a blob of 128KB, the cost is about $10, and this is already a 96% discount from using calldata (see [1], [2]), but still significant. In 7 months, our portfolio company Taiko paid about $3.5m worth of ETH for blobs, and our LP StarkNet paid about $700k worth of ETH for blobs. On the contrary, if they were settling the blobs on Celestia, it would be about 20x cheaper.

A project can also launch their own data availability committee, such as Arbitrum’s AnyTrust for their ecosystem chains, to further lower this cost.

Alternative data availability mechanism is an option for the rollups or applications to decide. It is okay to use it. It is okay to not use it. It is a matter of trade-off between the trust assumptions and the cost, and it can also be made secure.

For Bitcoin, the storage capacity on L1 is more limited, and therefore alternative data availability mechanism may be the only viable option. For example, a Bitcoin rollup cannot settle the data directly on the Bitcoin L1 due to the high cost and the unfavorable consequence of causing L1 congestion, defeating the purpose to use Bitcoin rollup to relieve the L1 pressure. It therefore requires an alternative data availability mechanism, ideally a decentralized one based on Bitcoin security.

Security

Now that we have an idea on how fraud proofs work, we can talk about the security of fraud proofs.

When the prover commits the execution onto the L1 blockchain, the execution has not been settled yet. For example, if account A wants to withdraw some tokens to L1, the rollup will publish this withdrawal request on L1, but the tokens have not been released to A yet.

It will need to wait for a withdrawal period, which is usually 7 days. This number, however, is sort of arbitrary and due to historical reasons (lightning network often waits for 1000 Bitcoin blocks, about 7 days). The 7-day withdrawal period may change in the near future:

• Arbitrum has been implementing “fast withdrawal” on Orbit chains, which allows users to receive the withdrawals within 15 minutes. This number is set based on Ethereum finality, which is about 12.8 minutes.

• Our portfolio company, RISC Zero, has released Kailua, which enables Optimism to be capable of 1-hour finality. There is a detailed study on why Kailua can provide 1-hour finality because the challenge protocol can be significantly shortened by either the challenger or the prover.

At the end of the day, the security of fraud proofs is not about how long the withdrawal period is, but it boils down to a simple question: when the rollup malfunctions, is there an honest party to run the challenge protocol and invalidate the incorrect computation? If the answer is yes, a shorter finality would work totally fine. If the answer is no, even a longer finality is not secure.

That leads to four factors of achieving fraud-proof security:

• Reduce the risk of rollup malfunction: This can be done through duplication, as long as the rollup is still performant. Even for a centralized rollup, it is helpful to have different machines running the same rollup functionality, and a settlement to L1 can only happen if these machines agree on the same. It is also helpful to have different implementations of the rollup functionality (called N-version programming) to reduce the impact due to program bugs. Our LP, StarkWare, is currently working on this. Note that this is different from decentralizing the sequencers to network participants, which is more for liveness and incentive-alignment purposes, but outside nodes may malfunction just like centralized nodes, if not more.

• Facilitate the honest party: The protocol needs to make it easy for the honest party to challenge the computation when something wrong happens. It is not easy to be an honest party. First of all, open-source implementation of the software for finding a discrepancy and automating the challenge protocol is needed, and its UX needs to be good enough not to discourage people from using it. Second, the cost to finish the challenge protocol should be low enough, rather than requiring the challenger to commit a large amount of capital. Third, a mechanism to prevent retaliation is needed. For example, if the honest party needs to be KYC-ed or whitelisted, they may not want to challenge at all because there might be retaliation. A solution is to use ZK, and this project “Credible Anonymous Whistleblowers” in ETH Bogotá that uses RISC Zero is a good example for making this anonymous.

• Allow enough time to finish the challenge protocol: Different fraud proofs have different challenge protocols, and there are trade-offs between the amount of data that needs to be made available to the public and the number of rounds. For example, in RISC Zero’s analysis on optimistic rollup vs ZK rollup vs hybrid rollup (i.e., Kailua), for a classic optimistic rollup protocol that uses bisection, one would need D + log(N) rounds, where D is the “computation depth” and N is the number of blocks in a batch. The total number would easily go to 10 or more rounds, depending on the specific parameters. It is necessary for the withdrawal period to be long enough for both parties to engage in these rounds, with some buffer for unexpected network delays, but at the same time one needs to be mindful that a long withdrawal period hurts user experience.

• Do fire drills: Normally, if the rollup operator is honest, and members of the public only challenge the execution when it is incorrect, the challenge protocol may never be used (which is often referred to as “the happy path”). But, that would result in a lack of practice: we don’t know if anyone is checking the correctness of the computation. One solution is to have regular fire drills where some “false” executions that are harmless are made by the rollup operator to test if there are still enough nodes paying attention to the system and whether they can finish the full challenge protocol.

It is important to note that fraud proofs do not equal slashing, which usually relates to EigenLayer and Babylon (both of which are our portfolio companies). It is possible for fraud proofs to have a slashing component, as an economic deterrence to the prover and the challenger for acting maliciously, but slashing is different from fraud proofs, due to a subtlety between the two.

Fraud proofs do not rely on slashing. If the computation is wrong, there is always a way to challenge and invalidate the computation, so that the incorrect state can never be materialized on the L1 chain. Slashing protocols do rely on slashing. If all the nodes are not afraid of being slashed (for example, someone bribes them to misbehave and will compensate for being slashed), even if the computation is wrong, it still can be accepted, and therefore it is important in EigenLayer or Babylon to build up the right economic incentives.

That being said, fraud proofs do not replace EigenLayer or Babylon because the problems that EigenLayer and Babylon are solving are what we call “intersubjectivity” problems, such as “is data available?” (which is why there is EigenDA) and “is 1 BTC = 1 USD?” (which needs data from centralized exchanges), the answers of which are formed through broad consensus and agreement rather than something mathematically defined or “computed”. This is also why EigenLayer and RISC Zero, two of our portfolio companies, can announce a collaboration in which ZK is used to make restaking and slashing more efficient because fraud proofs or ZK cannot solve these intersubjectivity problems that EigenLayer is solving.

In short, fraud proofs target at computation, and its security is based on computation. If there is computation to verify, fraud proofs likely will work.

Tradeoffs in fraud proofs

Now we shall take a deeper look into tradeoffs in fraud proofs.

Granularity of the computation. Consider an optimistic rollup that is committing 100,000 transactions. In fraud proofs, the computation is sliced into small chunks. Each chunk starts from some intermediate state and ends with a new state, where the new state would be used as the initial state of the next chunk.

The challenge protocol points out a chunk with at least a mistake in this chunk. It is easy to see that if the computation is incorrect, there must be at least one such chunk.

There are many ways to slice the computation, but how big should each chunk be? For example, given 100000 transactions, we can split them into 12 chunks where each chunk has about 8000 transactions, or split them into more chunks where each has about 3000 transactions. In practice, we may split more so that each chunk only deals with few transactions, to have a low on-chain challenge cost, but there is a balance.

Rounds. There is a cost in having too many chunks. To challenge the incorrect chunk, the public needs a hash of the initial state of each chunk and the new state after the computation in that chunk. There are two ways for the prover to provide these hashes, the cost of each increases with the number of chunks:

• On-demand, in which the prover provides the hashes when being asked for through a bisection protocol. This takes O(logN) rounds where N is the number of chunks.

• Published beforehand, in which the prover includes the hashes in the data availability layer so the public can directly use those hashes to find the incorrect chunk, without the need to confront the prover. This has the benefit that there is no round, but it requires publishing O(N) hashes.

The two methods can be used in hybrid, and each method is tunable. For example, to reduce the number of rounds, it can publish K hashes in the beginning, therefore reducing the number of rounds to O(log(N/K)). In addition, in each round, the prover does not have to strictly “bisect” the computation by offering only two hashes, but it can offer a few. Say if the prover, in each round, slices the remaining computation into S sections, then the number of rounds becomes log_S(N/K) instead of log_2(N_K). This can be significant, since it is reasonable to set S = 32 instead of 2, which would already cut the number of the rounds by 80%.

In practice, these parameters are decided by the cost of data availability on the L1 chain (as one can see, very large K or S would require a lot of data publication) and the desired number of rounds for the challenge to complete (if K=1 and S=2, there could be a lot of rounds). It is important to note that the cost differs in what we call the “happy path” and the “unhappy path”.

• “Happy path” is the case when the computation is correct and nobody wants to challenge it. In this case, the only data availability cost incurred is K, the data that is published beforehand (i.e., before any rounds of challenge). There is no round.

• “Unhappy path” is the case when a member of the public starts the challenge protocol. Usually, this challenger would be paying a deposit that covers the cost for the prover to respond to the challenge. This cost would include the data availability for log_S(N/K) * S hashes of the state as well. There would be S rounds, each round taking two transactions, one from the challenger, one from the prover.

It is okay to optimize for the happy path by setting K to be a small number, and the rounds in the unhappy path do not all have to use the same S. For example, it is possible that the first round in the unhappy path would divide the computation into K segments where K > S , to reduce the number of rounds.

Fast confirmation. Since the latency would impact the user experience in a fraud proof system, there have been many ad-hoc designs trying to alleviate this issue and provide some level of fast confirmation for users.

The first idea is to have some sort of “first challenge window” that is shorter than 7 days. If within this “first challenge window” nobody ever challenges the computation, then it assumes that this computation is correct and the challenge window will close early and the computation can be settled. After the “first challenge window”, even if the computation is incorrect, nobody can challenge that. But, if a member of the public senses that the computation is incorrect, it just needs to put the first challenge in within the “first challenge window”. After that, this challenger has more time to submit the subsequent challenges. This has been the core idea in RISC Zero’s Kailua on how to reduce the withdrawal period.

This idea only has a caveat, in that a malicious challenger who just wants to mess around and increase the latency can always try to challenge during the “first challenge window” so that the computation cannot be settled early. Setting a high deposit to prevent such malicious challengers is possible, but it would increase the bar for an honest challenger. It is also difficult to measure how much this deposit should be, because the loss due to delay to the users is hard to calculate.

Another idea is that, since the correct computation, even if being challenged, would eventually be settled, it is possible to “front” the capital for the users. For example, say that a user wants to withdraw just $10 USDT from L2 to L1, the L2 rollup operator can pay the user right away and, after the withdrawal period, claim the user’s $10 USDT from the L1. This significantly improves the user experience, and the rollup operator indeed does not really take risks.

This has been behind the reason why the centralized exchanges and bridges (such as Polyhedra, our portfolio company, and Orbiter Finance) allow users to deposit and withdraw money from optimistic rollup without waiting for 7 days. Specifically, they do not have to trust the rollup operator, as they can check the computation themselves from the published data. If the computation is correct, there is no way for the computation to be later invalidated.

BitVM also relies on the ability for the operator to front the capital and prove it afterwards. Of course, this would lead to an increased liquidity demand for the operator, and it could sometimes be troublesome (see [1], [2]). It would work great as long as the rollup operator fronts the capital, and the rollup operator may even be able to charge for a “fast withdrawal” fee for that. But it is not expected to work if a user wants to withdraw $100m but the rollup operator does not have that much liquidity. It also would not work if users are panicking, and there is a mass exit.

One idea for fast confirmation is to leverage ZK proof.

The extreme form is to do a full proof when needed. The idea is that if the rollup operator wants to accelerate the withdrawal period, it can do so by submitting a ZK proof that, upon being verified on-chain, immediately settles all the transactions and skips the entire withdrawal period. Basically, it is the ability to turn the optimistic rollup into a ZK rollup on-demand.

This is useful if a user wants to do a fast withdrawal of $100m and is willing to pay the rollup operator a lucrative fee to cover the cost. The operator does not need to have $100m in hand. Let us say if the operator only has $10m in liquidity, it can withdraw $10m to the user, claim the corresponding $10m from the L1 contract, withdraw another $10m to the user, claim another $10m from the L1 contract, and repeat the process until all the $100m is done. This is simply because the ZK proof, especially for this very purpose of proving one withdrawal, can be generated and verified quickly.

However, it does not have to be this extreme to have fast confirmation. Our portfolio company RISC Zero’s Kailua aims to provide fast confirmation by shortening the challenge protocol to be only a single round, in which the challenger needs to point out a section of the computation that does not sound right and request the prover to provide a validity proof. Since such a proof is expected to only take one hour to generate, the finality can be reached in about one hour (immediately when the proof is submitted).

That being said, we can summarize that modern fraud proof protocols have a lot of flexibility, and its efficiency is largely tunable. Particularly, it doesn’t have to be separate from ZK, but it is indeed somewhat orthogonal.

Fraud proofs and ZK

In the past, we treat fraud proofs and ZK to be two different families of protocols, and we used to describe optimistic rollup as “innocent until proven guilty” and ZK rollup as “guilty until proven innocent”. This did not correctly capture the fact that fraud proofs are also considered “guilty” unless, say, 7 days have passed and nobody can prove that the rollup operator misbehaves because the fund is not available during that withdrawal period.

It is helpful to think fraud proofs are like someone being detained by the police for investigation, and without a charge, the police will have to release the person after the 7-day “withdrawal period”. This does not sound like “innocent until proven guilty”, as if you trust the rollup operator, it does not have to be detained in the first place.

With this similarity, fraud proofs and ZK are not that different from each other. This leads us into the following question: if they are similar, what are some of the ways for fraud proofs and ZK to work together meaningfully?

First, Kailua can be considered as “optimistic rollup with an on-demand ZK validity proof”. The computation being committed is the execution of the transactions on the L2, and upon challenge, it can either be “proven guilty” through the existing challenge protocol or through the inability to provide a ZK proof upon request. We can summarize it as follows for Kailua.

-------------
Kailua from RISC Zero
-------------
Committed computation:
- execution of the transactions 
Methods to prove guilty: 
- requested the corresponding ZK proof verification for the specific section but did not have the ZK proof verified in time
- be shown by a challenger a valid ZK proof for a section that proves the execution is wrong
- or, refereed delegation of computation
Methods to prove innocent:  
- not being proven guilty during the withdrawal period
-------------

We can similarly summarize for optimistic rollup and ZK rollup.

-------------
Optimistic rollup
-------------
Committed computation:
- execution of the transactions
Methods to prove guilty:
- refereed delegation of computation
Methods to prove innocent:
- not being proven guilty during the withdrawal period
-------------

-------------
ZK rollup (such as Taiko and StarkNet)
-------------
Committed computation:
- execution of the transactions
Methods to prove guilty: N/A
Methods to prove innocent:
- verification of a ZK proof for the computation
-------------

Another example is BitVM, which our portfolio companies Fiamma and Nubit have been working on. BitVM differs from the examples before, in that the committed computation itself is a ZK proof verification of the execution of the transactions.

-------------
BitVM (as in BitVM 2 bridge)
-------------
Committed computation:
- verification of a ZK proof that proves the execution of the transactions
Methods to prove guilty:
- refereed delegation of computation
Methods to prove innocent:
- not being proven guilty during the withdrawal period
-------------

Our Bitcoin STARK verifier built for StarkWare’s CairoVM, which aims to verify a ZK proof on the Bitcoin L1 assuming OP_CAT, can be run without optimistic verification, and as a validity-only system like ZK rollups.

-------------
Bitcoin STARK verifier (type I, validity-only)
-------------
Committed computation:
- execution of CairoVM
Methods to prove guilty: N/A
Methods to prove innocent:
- run the ZK proof verification
-------------

But it can also add some optimistic verification, which would make it much more efficient and lightweight because the ZK proof verification is not necessary in the happy path. The optimistic verification, of course, will add some latency.

-------------
Bitcoin STARK verifier (type II, optimistic verification of validity proof)
-------------
Committed computation:
- verification of a ZK proof that proves the execution of the transactions
Methods to prove guilty:
- refereed delegation of computation
Methods to prove innocent:
- not being proven guilty during the withdrawal period
-------------

Note that the type II version still has a proof generation cost. Even if there is nobody from the public to challenge the proof, the operator needs to commit the verification of the ZK proof, which implies that the operator needs to generate that ZK proof even if nobody plans to challenge it. This inspires us that we can add RISC Zero’s Kailua idea to it, to create the type III Bitcoin STARK verifier.

-------------
Bitcoin STARK verifier (type III, with Kailua)
-------------
Committed computation:
- execution of the transactions
Methods to prove guilty:
- requested the corresponding ZK proof verification for a section of the computation but did not provide in time
- or, after the ZK proof verification is provided, refereed delegation of computation about this ZK proof verification for a section
Methods to prove innocent:
- not being proven guilty during the withdrawal period
-------------

This version has the benefit that the ZK proof is generated only when being challenged, and the ZK proof does not have to be the full proof, but it can focus on a section of the entire computation. This is not without tradeoffs. The member of the public who wishes to monitor the computation would have to get the transactions, execute them, and check the results, while if there is already a ZK proof, they can just check the ZK proof, without the need to even download the transactions. In addition, remember that the challenge protocol would desire the challenger to pay a deposit that covers the cost for requesting the ZK proof, and this deposit would not be small and would grow with the number of transactions being executed in a section. If this deposit is too large, it becomes a barrier of entry to become a challenger.

In conclusion, we can see that fraud proofs and ZK are not separate from each other, and starting from the example of Kailua from RISC Zero, one can see that there are indeed a number of different combinations for fraud proofs and ZK to work together.

Next article

In this article, we provide the background of modern fraud proofs and show that they are a very versatile family of protocols. A number of our portfolio companies are working in related directions, including RISC Zero, Fiamma, and Nubit.

In the next article, we will focus on fraud proofs in BitVM and in OP_CAT-enabled Bitcoin STARK verifier. Stay tuned for the Part II article.

Find L2IV at l2iterative.com and on Twitter @l2iterative

Author: Weikeng Chen, Research Partner, L2IV

Disclaimer: This content is provided for informational purposes only and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisors as to those matters. References to any securities or digital assets are for illustrative purposes only and do not constitute an investment recommendation or offer to provide investment advisory services.

This year, the Irreducible team released another Binius-family proof system, called FRI-Binius. FRI-Binius is a direct competitor to Plonky3, the proof system from Polygon Zero.

FRI-Binius improves over Ligero-Binius by having a smaller verification overhead, making itself more suitable for recursive proof verification, while the prover efficiency remains competitive.

In the second article, we talk about FRI-Binius. This article is available on HackMD.

https://hackmd.io/@l2iterative/binius2

FRI-Binius is more complicated than Ligero-Binius. Readers who have not read our article on Ligero-Binius should start with that article first, as it provides the background on error-correcting code on binary fields as well as packing small field elements into bigger elements.

In this article, we use animations and visual aids to assist understand the sumcheck protocol and the folding protocols, which are the hard part.

Even if you previously have looked into FRI-based protocols (such as STARK), be careful, the way that FRI-Binius works is very different from several popular FRI-based protocols. For example, Stwo and RISC Zero’s proof systems both use DEEP-FRI (where DEEP refers to “Domain Extending for Eliminating Pretenders”), in which a quotient protocol is used for opening polynomial, instead of the sumcheck and folding protocol used in FRI-Binius, which comes from a recent work, BaseFold. The reason why the quotient protocol does not work well with small fields have been discussed in the Ligero-Binius paper.

We would like to thank Radisav Cojbasic, Jim Posen, and Benjamin Diamond from Irreducible for reviewing the article series and providing feedback.

Find L2IV at l2iterative.com and on Twitter @l2iterative

Author: Weikeng Chen, Research Partner, L2IV

Disclaimer: This content is provided for informational purposes only and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisors as to those matters. References to any securities or digital assets are for illustrative purposes only and do not constitute an investment recommendation or offer to provide investment advisory services.

We pay specific attention to this proof system because our portfolio company, RISC Zero, who has been developing the RISC-V zkVM, told us that Binius will be the next generation proof system and we should keep an eye on. Eddy Lazzarin, CTO of a16zcrypto, also has put Binius "as a top priority" for their proof system, Jolt.

We want to provide a high-level explanation of the Binius protocol. There are two papers on Binius: Ligero-Binius (2023) and FRI-Binius (2024). We will dedicate two technical articles for Binius.

In the first article, we will explain Ligero-Binius, which is simpler, as the first step for understanding Binius. This article is available on HackMD.

https://hackmd.io/@l2iterative/binius

To help navigate the different concepts in Binius, we created a number of animations. This is the first time we use animations in research articles, and we are eager to get your feedback.

We would like to thank Radisav Cojbasic, Jim Posen, and Benjamin Diamond from Irreducible for reviewing this article and providing feedback.

The second article will discuss FRI-Binius, the more recent version of Binius.

Find L2IV at l2iterative.com and on Twitter @l2iterative

Author: Weikeng Chen, Research Partner, L2IV

Disclaimer: This content is provided for informational purposes only and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisors as to those matters. References to any securities or digital assets are for illustrative purposes only and do not constitute an investment recommendation or offer to provide investment advisory services.

Execution Abstraction allows front-end apps, wallets, and other entities to define and expand the context in which operations are executed within a transaction.

Execution itself is an abstract notion, as there is no single, granular form, design, or requirement for it. This inherent abstraction makes it challenging to explain execution abstraction, as it involves abstracting an already abstract concept. Execution Abstraction involves multiple layers of execution context, such as defining what happens before, during, and after operations, as well as the relationships between operations within the same transaction. These layers can be difficult to convey concisely and clearly.

Despite the challenges, execution abstraction offers several key benefits that address current issues in the DeFi ecosystem:

1. Expanded control over operation execution enables sophisticated and tailored transaction processing, protecting users from predatory practices like MEV exploitation.

2. The ability to capture and internalize value generated by operations ensures a more equitable distribution of value and promotes sustainability.

3. Execution Abstraction maintains decentralization and trustlessness by bundling operations into a single transaction and using smart contracts, potentially eliminating the need for whitelisting and trusted infrastructure.

4. By defining intents and verifying their fulfillment within the execution context, Execution Abstraction can be used as a fully generalized intent engine.

All of which, we’ll discuss in detail in the context of Atlas. 

What is Atlas?

Atlas, built and developed by FastLane Labs, is based on a subset of account abstraction called Execution Abstraction. The core idea behind Atlas is to create a generalized Execution Abstraction protocol that reduces the complexity and cost associated with deploying application-specific order flow auctions (OFAs). These OFAs are auctions used to determine the order of transactions or operations based on bids from participants, which can be prone to MEV-related issues.

Key features

One of Atlas's key features is its ability to capture and internalize the value generated by operations. In the current DeFi ecosystem, a significant portion of the value created by user transactions is extracted by miners, validators, and other third parties. Atlas allows apps and wallets to control who can capture and internalize this value, redirecting it to users, DAO treasuries, or public goods funding, thus promoting a more equitable value distribution. 

Atlas achieves this through the use of operations, which are EIP 712 messages (signed code, not full transactions) that are bundled into a single transaction by a bundler. This is one of the most impressive aspects of the Atlas architecture’s use of operations as the fundamental building blocks of transactions. This bundling process is crucial for maintaining decentralization and trustlessness, as it prevents block builders, validators, and other parties from manipulating the execution order of operations within a transaction (which is truly the whole point).  While validators and block builders can sequence transactions in a block, Atlas prevents them from sequencing operations inside a transaction. This ensures the intended execution order is maintained and protects against value leakage, even in the event of chain reorganizations.

Unlike traditional MEV bundles, Atlas allows operations to reference other operations in any direction within the same transaction, providing atomicity and protection against chain reorganizations. This ensures that the intended execution order is maintained and value is not leaked, even if there are chain reorganizations.

Another important aspect of Atlas is its use of smart contracts to determine operation interactions and auction winners. This eliminates the need for whitelisting solvers and trusted infrastructure, maintaining the protocol's permissionless and decentralized nature. By using smart contracts, Atlas ensures that the trust assumptions are handled within the protocol itself, preventing centralization and protecting users from potential manipulation by malicious actors.

Atlas Architecture

The main roles in the Atlas architecture include:

• Originator: The party that initiates the Atlas process by generating a signed operation representing their desired transaction(s). This is typically the User; the party perceived as having intrinsic value. But this role can also be designated more flexibly to other entities like contracts, block builders etc. 

  • Who: users, oracles, bridges, or co-processors initiating action requests

• Solvers: Entities that respond to originator operations by proposing solutions to internalize MEV or fulfill intents. Solvers compete in an auction to provide the best outcome for the Originator.

• Auctioneer: Responsible for aggregating the Originator’s operation  and the Solvers’ operations (solutions), and sorting them using the bid valuation function. To maintain incentive compatibility, the Auctioneer is typically the beneficiary of the auction, which is usually the Originator.

• Operations Relay (OR): An infrastructure layer that facilitates communication between Originators, Auctioneers, and Solvers. Choice of OR impacts factors like decentralization, privacy, etc.  In many cases, the Operations Relay is a smart contract on the same chain as the main Atlas smart contract.

• Bundler: Generates the full Atlas transaction after compiling the Originator’s, Solvers’, and Auctioneer’s operations and ensures the transaction’s inclusion on-chain. It can be permissionless or permissioned, depending on the dApp’s needs. 

To maintain trustlessness and decentralization, Atlas aims to handle these roles through smart contracts whenever possible. For example, the auctioneer role is often assigned to the auction beneficiary, as they have a vested interest in selecting the best solution.

One of the standout features is the separation of concerns among the various actors involved. The originator, solvers, auctioneer, and bundler each have distinct responsibilities, allowing for specialization and optimization at each stage of the process. This modular design promotes flexibility and adaptability, as different implementations or strategies can be employed for each role without disrupting the overall flow.

The Atlas SDK allows parties to easily sign a “CallChainHash”, which is verified by the Atlas smart contract to ensure the integrity of the execution order. Native bundling, using Execution Abstraction, enables permissionless, multi-chain OFAs without relying on guarantees from block builders or private relays. It enhances the likelihood of favorable execution outcomes and supports various enforcement techniques to increase the likelihood of successful execution.

atlETH, a wrapped representation of ETH within Atlas, enables solvers to escrow funds for gas consumption and supports an Atlas-native cross-operation flash loan system. The extra checks Atlas requires do consume more gas compared to builder-integrated OFAs. But solvers typically cover these higher fees. 

This is a visualization of atlETH in action

The diagram above is an example of a use case in the Atlas protocol involving the submission and execution of Solver operations using atlETH’s escrow. Specifically, it illustrates the process of Solvers participating in the Atlas ecosystem by submitting their proposed solutions to solve an Originator’s operation (User intent), while escrowing atlETH to cover the gas costs associated with executing their solutions.

We have simplified a few terms for better understanding. Here's a brief explanation of the diagram:

1. The Solvers deposit gas (atlETH) in the Atlas escrow system.

2. The Solver network submits proposed solutions to the Atlas contract  (Atlas EntryPoint Contract).

3. The Atlas contract verifies if the escrowed gas tokens are sufficient to cover the associated costs.

4. If the Solver’s solution is successful:

   • The Atlas contract executes the proposed solution by interacting with the specific application.

   • The application handles the necessary logic and value allocation based on the executed solution.

   • The Atlas contract releases or adjusts the escrowed gas token balances of the Solvers based on the actual costs incurred.

5. If the Solver’s solution  fails:

   • The Atlas contract cancels the Solver’s operation.

   • The gas cost of the Solver’s failed operation is deducted as a penalty.

   • The remaining escrowed gas tokens can be withdrawn or used for the Solver’s next operation.

The atlETH escrow mechanism ensures Solver accountability, covers gas costs, and incentivizes Solvers to submit valid and efficient solutions. By simplifying the escrow mechanism we have shown how the Atlas protocol leverages atlETH escrow to facilitate Solvers' participation in the ecosystem while maintaining the system's integrity and efficiency.

How to Integrate Atlas?

One of the most powerful features of the Atlas architecture is its modular design, which allows developers to create custom Atlas modules that define the specific rules and behaviors for their DeFi applications. 

To start using Execution Abstraction, an app or wallet must publish an Atlas module (a smart contract) that defines specific rules and behaviors for the execution context surrounding their use case, for example:

1. How solver bids are valued (e.g., based on amount, reputation, or other criteria)

2. Who can be the Auctioneer and Bundler

3. The hook functions that determine how the Originator and Solvers interact

To better understand the Atlas protocol's operational mechanics, let's consider how they are defined and implemented. These components are crucial for ensuring that Atlas operations align with the specific needs and governance structures of different DeFi applications. 

The Atlas module contains three key components that need to be defined by the application developer:

1. Solver Bid Valuation: The first component is the mechanism for valuing Solver bids. Solvers are entities that respond to Originator actions by fulfilling intents or performing triggered actions, and they compete in an auction to provide the best solution or outcome for the Originator.

The Atlas module must define how these Solver bids are evaluated and compared. This can be based on various criteria, such as:

The specific implementation of the Solver bid valuation mechanism is defined in the BidValue function of the Atlas module. This function takes the Solver bids as input and returns a ranking or score for each bid, allowing the Auctioneer to accurately sort Solver operations according to their own preference.

2. Auctioneer and Bundler Assignment: The second component of the Atlas module is the assignment of the Auctioneer and Bundler roles. The Auctioneer is responsible for running the auction process, which involves ranking and sorting the Solver bids based on the valuation mechanism defined in the BidValue function. The Bundler, on the other hand, is responsible for taking the sorted Solver operations, combining them with the originator's operation and any other necessary operations, and submitting the bundled transaction to the blockchain.  By submitting a sorted list of Solver operations, the Auctioneer and Bundler can be confident that at least one of them will successfully fulfill their obligation and pay their bid. 

The Atlas module must specify who can assume these roles for the particular use case. The options include:

The role assignment logic of the Atlas module defines the specific implementation of the Auctioneer and Bundler assignment mechanism.

3. Hook Functions: The third and arguably most critical component of the Atlas module is the definition of the hook functions. Hook functions are special functions that allow developers to customize the interaction between the Originator and Solvers, as well as define the pre-conditions and post-conditions for execution to be considered successful. .

The Atlas module can define several types of hook functions, including:

• Pre-operation hooks: These functions are called before the main operation is executed. They can be used to set up the necessary conditions or perform any required checks or validations. For example, a pre-operation hook could verify that the Originator has sufficient balance to cover the operation or define the Originator’s intent for the Solvers to fulfill.

• User operation hooks: These functions define the main operation that the originator wants to execute, such as a token transfer, swap, deposit, or other smart contract interaction. The user operation hook is where the core logic of the frontend’s application is implemented.  For frontends or wallets looking to internalize their MEV, this operation would simply point to the same smart contract and function that users were interacting with before Atlas was integrated.

• Solver operation hooks: These functions define the specific requirements that Solvers must meet and any assistance that they receive when fulfilling the Originator's intent. Solver operation hooks are where the solvers compete to provide the best solution or outcome for the originator.

• Post-operation hooks: These functions are called after the main operation and Solver operations have been executed. They can be used to perform any necessary cleanup, bookkeeping, or additional actions. For example, a post-operation hook could be used to distribute any earned fees or rewards to the relevant parties.

Developers have a high degree of flexibility in defining the logic and behavior of these hook functions. They can use them to implement custom value capture mechanisms, enforce specific conditions or constraints, or enable complex interactions between the originator and solvers. By allowing customization through hooks in Atlas modules, the Atlas protocol enables developers to build sophisticated and tailored solutions on top of the base execution abstraction layer.  In contrast, the FastLane Labs team has already published multiple simplified modules that can be used by developers looking to rapidly launch an intent-powered application or internalize the MEV created by their existing application.

By carefully designing the hook functions, developers can create powerful and innovative DeFi applications that leverage the full potential of the Atlas protocol's execution abstraction capabilities. The hook functions contain the majority of the application-specific logic, and they are critical for ensuring the desired outcomes and value capture for all parties involved. This flexibility is what makes Atlas particularly powerful for developing sophisticated DeFi applications.

Once the Atlas module is defined and published, it can be used by the DeFi application to enable Execution Abstraction. The application can then route its transactions through the Atlas protocol, which will load the appropriate Atlas module and execute the defined hook functions to facilitate the interaction between the originator, solvers, and other relevant parties.

Now, that we understand the architecture in detail, we try to explain in simple terms and visualization how a transaction at Atlas happens:

The process starts with the Originator creating and signing a UserOperation (as mentioned earlier these are either intents or path-defined operations provided by the users), which represents the desired transaction. The signed UserOp is sent to the Operations Relay, which broadcasts it to the permissionless Solver network. Solvers compete to provide the best solution for executing the UserOps, considering factors like gas optimization and transaction ordering. They submit their proposed solutions (SolverOps) back to the OR.

The OR collects all SolverOps and sends them to the Auctioneer, who evaluates and sorts them based on predefined criteria. The sorted SolverOps are then sent to the Bundler (if separate from the Auctioneer), who combines their targeted SolverOp(s) and the UserOp into an Atlas transaction. The Bundler submits this transaction to the Atlas EntryPoint Contract  via their preferred RPC, relay, or even the public mempool.

The Atlas EntryPoint Contract verifies signatures and executes the operations in the specified order, interacting with the Atlas module to perform app-specific logic. The Atlas module processes the hooks surrounding the operations, performs computations or state changes, distributes value according to defined rules, and returns the results to the Atlas EntryPoint Contract.

Finally, the Atlas EntryPoint Contract performs post-execution processing, such as updating state, emitting events, and attributing gas costs to the appropriate parties. Upon completion, the Operations Relay then notifies the Originator about the completion of the requested operation and provides any relevant updates or results.

Comparison with AppChains

Before we delve deeper into the intricacies of Atlas’s use cases, it becomes essential to understand how it compares with other solutions, such as appchains. 

Appchains are standalone blockchain networks that are purpose-built for specific applications, allowing developers to define custom rules, parameters, and functionalities tailored to their app's requirements. This level of control enables appchains to optimize their performance, security, and user experience for their specific use case.

Similarly, Execution Abstraction, as implemented in the Atlas protocol, allows front-end applications, wallets, and other entities to define and expand the context in which operations are executed within a transaction. This includes setting what happens before, during, and after the operations, as well as defining the relationships between operations in the same transaction (as we discussed in earlier sections above). By providing this level of control over the execution environment, Atlas, through Execution Abstraction, enables apps and wallets to tailor the transaction processing to their specific needs, much like appchains.

However, while Appchains and Execution Abstraction share this similarity in terms of control over the execution environment, the specifics emphasize the key advantages of execution abstraction over Appchains.

1. Enhanced Composability and Modularity:

   • Unlike appchains, which may struggle with interoperability and thus lead to ecosystem fragmentation, Execution Abstraction maintains strong composability and modularity. Apps utilizing Atlas can interact seamlessly with other applications on the same blockchain, benefiting from the broader ecosystem without isolation.

2. Lower Infrastructure Demands:

   • Execution Abstraction leverages the existing infrastructure of the underlying chain, avoiding the substantial costs and logistical challenges associated with launching and maintaining an independent appchain. This approach not only simplifies the technical demands but also capitalizes on the established network effects and security of the primary blockchain.

3. Balanced Trade-offs:

   • Appchains often face trade-offs related to decentralization, security, and scalability due to their isolated nature and potentially smaller validator sets. Execution Abstraction, on the other hand, allows applications to enjoy the benefits of a controlled execution environment while still partaking in the decentralization, security, and scalability advantages of a larger, established blockchain network.

This helps us understand the strategic approach that is needed for building the infrastructure for modern applications. 

Practical Applications of Execution Abstraction in Atlas

As we delve deeper into Atlas's potential within Execution Abstraction, Atlas not only reshapes how transactions are handled but also opens up a myriad of applications where Execution Abstraction can be leveraged to enhance functionality, security, and user experience.

Below are a few examples of how Execution Abstraction through Atlas can be applied across various sectors within the blockchain ecosystem, each tailored to address specific needs and challenges, including:

1. Protecting users from predatory MEV on DEX front-ends:

   • Atlas, through Execution Abstraction, empowers DEX front-ends to protect users from predatory MEV practices by giving them control over the execution context of transactions.

   • The Atlas module can implement checks to detect and prevent sandwich attacks, front-running, or other exploitative strategies.

2. Internalizing non-predatory MEV and redistributing value to users:

   • Atlas, through Execution Abstraction, allows DEX front-ends or other entities to capture and internalize non-predatory MEV opportunities, such as arbitrage and liquidations, without harming user transactions.

   • The captured value can be redistributed to users in the form of reduced trading fees, token rewards, or other incentives, aligning the interests of users and the platform.

3. Enabling gasless transactions for web3 gaming and dapps:

   • Atlas, through Execution Abstraction, allows gaming dapps and other applications to implement gasless transaction mechanisms by abstracting away the gas payment process.  This is possible even without a smart contract wallet.

   • The Atlas module can handle gas payments on behalf of the user, either by subsidizing fees, using meta-transactions, or other techniques, providing a seamless user experience.

4. Facilitating decentralized swap requests for quotation (RFQs):

   • Atlas, through Execution Abstraction, would allow the creation of decentralized and permissionless RFQ systems, where solvers compete to provide the best quote for a user's swap request.

   • The RFQ process can be managed through smart contracts within the Atlas module, promoting competition, price discovery, and efficiency in the token swapping process.

5. Enabling liquidity pools to internalize loss versus rebalancing (LVR):

   • Atlas, through Execution Abstraction, allows liquidity pools to internalize LVR by implementing custom market maker auctions, rebalancing mechanisms and strategies within the Atlas module.

   • The Atlas module can monitor token ratios, trigger rebalancing operations, and incorporate advanced algorithms to minimize impermanent loss and maintain a stable trading environment.

Conclusion

The journey through the intricacies of Atlas reveals a transformative approach to handling transactions within DeFi. Through the lens of Execution Abstraction, we've explored how Atlas enhances transaction processing by:

• Empowering front-end applications to dictate the operational context, thereby shielding users from predatory practices like MEV.

• Internalizing the value extracted from transactions to ensure a fair and equitable distribution among users, rather than losing it to miners or third-party validators.

• Maintaining the core principles of decentralization and trustlessness, crucial to the ethos of blockchain technology.

Atlas stands out not only for its robust mechanism of operation bundling and the strategic use of smart contracts but also for its atlETH escrow, which is even capable of cross-operation flashloans in which app-initiated flashloans for the Originator are paid back by the Solvers. This native token ensures that operations are financially backed, securing the network against spam and financially insincere actions. Moreover, the protocol's ability to handle complex order flow auctions and the integration of various roles—Originators, Solvers, Auctioneers, and Bundlers—into its architecture exemplifies a sophisticated yet flexible transaction system.

As an L2IV portfolio company, we strongly believe Atlas is poised to redefine the standards of transaction execution within DeFi. As we continue to witness how DeFi evolves and adapts, the role of advanced protocols such as Atlas will undoubtedly become more central with a specific focus on Security, Costs, and Democratizing benefits (through MEV).

About FastLane

• Website: FastLane

• Whitepaper: Atlas

• GitHub: Docs

We would like to express our sincere gratitude to Alex Watts for his invaluable insights on this article and cooperation throughout our evaluation of FastLane and Atlas.

Find L2IV at l2iterative.com and on Twitter @l2iterative

Subscribe now

Author: Arhat Bhagwatkar, Research Analyst, L2IV (@0xArhat)

References

• On ERC-4337, Intents, and MEV

• Why we are building Atlas

• EIP-712: Typed structured data hashing and signing

• Execution Abstraction

• What is Execution Abstraction

Disclaimer: This content is provided for informational purposes only and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisors as to those matters. References to any securities or digital assets are for illustrative purposes only and do not constitute an investment recommendation or offer to provide investment advisory services.

In other words, consumer protection has a side effect that it takes away some of consumers’ opportunities “to be rich”. Individuals may not be able to participate in token presales. What is more, today, many web3 projects do airdrops (see Celestia, Arbitrum, Optimism), but it explicitly filters out US residents. We don’t know how many US developers are disqualified from airdrops because of their tax residency, but it is of course very sad to hear.

The Securities Act of 1933, however, does provide an exception—accredited investors, the definition of which is shown in the picture above from Investopedia. This is Rule 501 of Regulation D. It gives an individual accredited investorship based on income.

The income test is fairly approachable to people in the tech industry. According to levels.fyi, except for the most entry-level titles, software engineers in top IT companies—Amazon SDE II, Google L4, Facebook E3, Microsoft Senior SDE—usually have a qualifying income after working for a few years. To put it differently, if you meet another software person living in San Francisco or Seattle, chances are that he/she is already an accredited investor.

But now the problem is: how do they prove that?

The traditional solution in web2 is to do KYC—to request documents as income proofs, which can be tax forms or pay slips. This is a poor fit for web3, and in fact, we believe it not sustainable for web2 as well.

• Lack of scalability. Since the income proofs are “unstructured data” and vary from each employer, it often requires manual inspection. But, since pay slips are easy to forge, to be certain, a landlord’s best bet is to call the employer for verification—an unsolicited phone call that is rarely welcomed—or to go for a comprehensive background check, the cost of which is above hundreds of dollars. 

• Lack of reliability. There are plenty of online articles teaching people, particularly landlords, to detect signs of fraudulent payslips (see 1, 2, 3, 4, 5), yet an educated adult can easily forge a perfect one. Today, one doesn’t need to be James Bond to create doctored payslips. In addition to payslips, fake IDs are not uncommon: an underage college student may already have one for getting alcohol (see this article). Law-abiding people like us just don’t know how much trust we are putting in from day to day.

• Lack of privacy. Too much information is revealed. Payslips expose home addresses. Tax forms reveal marriage status, number of children, and other sources of income. Credit reports are the worst: it includes current and previous addresses, current and previous employers, and other information that is much more than “I am an accredited investor.”

The culture of web3, however, distinctly differs from that of web2.

• Scalable: automated, disintermediation

  • Web2 has clerks and cashiers. In Web3, it is the smart contracts. 

  • Transactions are processed in a transparent, automated manner by a network of more than thousands of nodes. 24/7. Processing time is usually less than one minute. Since everyone can create a smart contract, there is little monopolization, and fees are often reasonable.

  • So here is the question: How do you prove accredited investorship in web3, or, to a smart contract?

• Reliable: decentralized, minimal trust

  • The traditional society relies a lot on trusting people to be honest until proven otherwise.

  • Many states in the US allow a voter without an ID to vote by signing an affidavit. But even if an ID is required, it doesn’t add much security. Most states’ REAL IDs don’t have a chip, and one doesn’t need to break any cryptography to forge one.

  • Our real world is an optimistic rollup. You challenge people by calling the district attorney. The fraud proof is centralized, as the so-called “data availability” is almost nonexistent for regular people so they are incapable of generating the fraud proof. Web3, however, needs to be open to verification by everybody. 

  • So here is the question: How do you prove accredited investorship in web3 reliably?

• Privacy-preserving: autonomous, pseudonymity

  • To create an account on a web2 website, chances are that you are asked for a phone number and at least an email address. For credit card payments, a zip code is the bare minimum, but oftentimes a billing address is needed. The prevalence of people search sites in the US (which is a legal business), such as TruthFinder, PeopleFinder, and Spokeo, renders privacy almost hopeless. 

  • Web3 is a privacy-by-default culture. The 0x addresses have no association with one’s real-world identities. Blockchains do not care who you are, but only care about your intent.

  • So here is the question: How do you prove accredited investorship in web3 without revealing your life?

This calls for us to rethink how our world should be operated. If I need to prove that I am an accredited investor, 

• Why do I need to submit my payslips? 

• Why do I have to reveal my home address?

• Why do I have to provide tax forms to prove my taxable income?

• How many people would be able to see the documents?

The other side, who will be verifying the documents, is also struggling.

• Are these payslips fake? Are they doctored?

• Do I need to cold-call the previous employer for verification? 

• Should I ask for consent to submit a formal background check?

• Do I need to manually check every line of the tax forms to see if it is doctored?

This happens to many web3 investors. Recently, I was admitted as a new member to the Zero DAO, a US-based DAO investing in zero-knowledge proofs. Prior to the admission, I went through the KYC process. The DAO is web3, but this KYC part remains web2. Although the KYC experience is smooth, I did submit a lot of documents, and I started to wonder if KYC is going to be a common routine for me if I continue working in the investment industry.

Think about it further. Even Web2 may benefit from a better solution. Imagine, probably not far in the future, you become a private equity investor and sign hundreds of SAFE agreements a day. Instead of sharing your phone number, your email address, or your home address to half of the people in the Sand Hill Road, what if you only need to open Metamask and click, click?

Today, we finally have the technology to fix that, thanks to the advancement of cryptography. I like a motto from one of our portfolio companies: “Fixing the Internet, one ZKP at a time”. And this is it.

In this series of articles, we describe a solution to prove accredited investorship with privacy and integrity, using zkPass. This comes out from a partnership between L2 Iterative and zkPass, with a goal to make zkPass a comprehensive tech stack for data ownership that can be used across web2 and web3. The code of our engineering work going to be discussed in this article series can be found at GitHub.

The first article will be focusing on the motivation—how to understand this narrative.

A tale of data ownership

We want to first conceptualize what we mean by data ownership. Particularly, we are thinking about personal data stored in third parties.

• Government has the personal identification information, including photo, nationality and citizenship, date of birth, and some unique identification numbers. Some part of such information can be found in the passport.

• The US tax agency, Internal Revenue Service (IRS), keeps records of the tax filings as well as wage and income transcripts, from individuals, banks, insurance providers, employers, and other corporations etc.

• Ownership of social accounts—such as Instagram, Twitter, Quora, Tiktok, Discord, and Reddit—as well as the related information such as memberships or subscriptions, number of followers, and contents of posts or tweets. 

• Banks and credit bureaus like Equifax hold historical account balance, spending activities, and financing situations. Think about credit reports and six-month bank statements that landlords want to see for background checks.

Data protection laws such as GDPR and CCPA, passed in the past decade, provide a solid foundation for a number of rights related to data ownership:

• GDPR: right of access, right of erasure, right to object, right to compensation, right to not be subject to automated individual decision-making

• CCPA: right to know, right to delete, right to opt-out of sale or sharing, right to correct, right to limit use and disclosure of sensitive personal information

But this is neither sufficient nor comprehensive. There is a large scope of data rights not covered by GDPR and CCPA. For example, people have more rights when it comes to healthcare data. According to HIPAA, the patient not only has the right to access their own protected health information (PHI) from a healthcare service provider (such as a doctor), but they can also request the data to be transferred to a specific third party.

This allows a patient to easily switch between different healthcare providers by asking the former provider to share prior records (including diagnosis, x-rays) to the new provider. It has been implemented in every clinic in the US. Below is the authorization for release form from UC Eye Center for a patient to request data be shared with a third party.

Compared with healthcare, Web2 must feel embarrassed.  You cannot expect the following to happen in Web2 soon:

• ask a bank to send an official email to the landlord confirming your account balance

• ask DMV to call the buyer to endorse that you hold a certain brand car

• ask Uber to share with Lyft about your driving records so that Lyft can match your rewards tier as a driver

• ask IRS to email zkPass that you are an accredited investor and should be qualified to receive airdrops

Focusing on the last point related to accredited investorship. It would be fairly convenient, just to imagine for a moment, if whenever someone doubts that you are an accredited investor, you could always call the IRS, and the IRS would immediately call he or she to confirm your accredited investorship…I used Comicai to draw a minicomic below.  

Nevertheless, this is not what happens today, and likely not in the near future. The IRS has an express income verification service, called IVES, that would soon be limited to “verify the income or creditworthiness of a taxpayer who is a borrower in the process of a loan application” (see Section 2201(b) of Taxpayer First Act of 2019), which definitely does not include “airdrops”. Talk about preciseness!

This example shows the limitations of today’s data protection laws.

The laws make sure that the third parties are not “data owners”. They need to allow you to access the data. They have to delete the data if you ask. They cannot share the data without your consent. In the case of the IRS, the Taxpayer First Act is acting as a data protection law here, as it limits how IRS shares the data.

But these data protection laws don’t make the user “the owner of the data” either. 

• The data is still proprietary to the third party. Third parties have no responsibility to testify for the user about the data.

• Users may want to customize the format of the data (such as redactions), but third parties may not have the options. For example, for accredited investorship, we only need to prove that the annual income is greater than US$200k rather than to reveal the exact number (think, what if you are a billionaire), but IRS current authorized release doesn’t have this level of granularity.

To restore the ownership to the user, here is what zkPass needs to tackle: 

• Enable the user to obtain data from reliable data feeds

• Enable the user to prove user-specified data processing (redactions, or generic computation like checking if income >US$200k) while preserving the authenticity of the source data

With zkPass, everything can be different. The accredited investorship can be made into a soul-bound token (SBT), and the user can prove the ownership of this SBT from Metamask with a few clicks.

This sounds like a Police Benevolent Association (PBA) card for airdrop clearance, but it can be even more convenient. In fact, you don’t even need to click on Metamask—dApps that know the user’s address can use Alchemy or Ankr to automatically find out if the user has this SBT and silently removes any blocker, as if the dApps already recognize you as an VIP.

In some way, zkPass resonates with the concept of the ZK coprocessors (think Hyper Oracle, Axiom, Bonsai, Brevis, and Herodotus) that focus on history web3 on-chain data. zkPass also resonates with ZK bridges (think Polyhedra, our portfolio company), which do message passing between different chains with mathematical security. Unlike them, zkPass is a unique one that focuses on off-chain data, including web2 data. 

• ZK coprocessor: Verifiable on-chain data

• ZK bridge: Verifiable cross-chain data

• zkPass: Verifiable off-chain data

zkPass: a stack for data ownership

zkPass is a full-stack solution for data ownership, which consists of various tools and applications that enable verifiable data sharing, with privacy and integrity guarantees.

• Data-feed:

  • HTTPS web connections (with 3P-TLS)

  • Electronic passport

  • DKIM emails

  • Digital signed PDFs

• Data-processing:

  • Interactive ZK

  • RISC Zero

  • Groth16

• Data-consuming:

  • On-chain identities

  • Off-chain verification

Currently, their testnet version already supports a long list of data-feeds, including internet companies, traditional industry, governments.

• banks and governments: Nagarik App, ANZ Bank, Australian myGov

• education: Coursera, Hubspot Academy

• video games: GOG.com

• real-world identities and assets: Ferrari, Uber

• cryptocurrency exchanges: OKX, Binance

• social platforms: Instagram, Twitter, Quora, Tiktok, Medium, Reddit, Discord

Our partnership: RISC Zero backend and PDF proofs

We have a partnership with zkPass to create an interactive proof for IRS-reported taxable income from the IRS website, which is then used to establish the accredited investorship, through the most commonly used income test for individuals.

This can be done with privacy and integrity by having the users interact with the data requestor as follows:

• prove—using zkPass 3P-TLS protocol—that he/she receives the account transcripts for the prior two years, which would be two PDF documents, from the IRS Transcript Delivery System (TDS). A redacted and desensitized sample of the 2022 IRS account transcript of the author can be found here. Since account transcripts contain sensitive personal information, such as the last four digits of the social security numbers (SSN) and abbreviated home address, the transcripts would not be revealed to the data requestor. The PDF below, which is my IRS account transcript for 2022, looks as follows.

  

• prove—using zkPass data processing protocol, here RISC Zero backend—that the two account transcripts are:

  • matching the user's profile

  • recently issued by the IRS

  • matching the requested years (such as 2022)

  • have a taxable income larger than US$200,000

This can be illustrated with the following diagram.

The zkPass 3P-TLS protocol is used to prove the internet connections with the IRS website, which works as follows.

• The user makes the usual HTTPS connection with the IRS website, with the encrypted network traffic rerouted through the validator. Validator here acts like a network proxy or, in laypersons' terms, a VPN.

• After the HTTPS connection concludes, the validator asks the user to generate a zero-knowledge proof about the encrypted traffic data. The validator independently verifies the integrity of the TLS connection, through PKI certificates.

• As we discussed above, zkPass supports multiproof. Several backends, including RISC Zero that we use, can be used to generate this zero-knowledge proof. This is often a selection that optimizes performance. RISC Zero is suitable for proofs that involve RAM-model computation rather than circuit-model computation.

This protocol that zkPass uses for 3P-TLS has been studied for many years, all the way starting from TLSNotary more than a decade ago (now, an Ethereum Foundation-funded PSE project). Academic work including BlindCA (IEEE S&P 2019), DECO (ACM CCS 2020), Oblivious TLS (CT-RSA 2021), MPCAuth (IEEE S&P 2023), and DiStefano from Brave Browser has moved this forward.

Next, zkPass will use the RISC Zero backend to read the PDF file.

RISC Zero takes care of processing the PDF file that the 3P-TLS protocol obtains, performing necessary parsing, decryption, and decompression, and then checks if the “taxable income” is greater than USD$200k, as shown in the code snippet below taken from our implementation.

let (tax_period_start, tax_period) = find_data(0, "TAX PERIOD: ".parse().unwrap(), ")".parse().unwrap());
assert_eq!(tax_period, "Dec. 31, 2022");

let (_, taxable_income) = find_data(tax_period_start, "TAXABLE INCOME: ".parse().unwrap(), ")".parse().unwrap());
let taxable_income = str::parse::<f64>(&taxable_income.trim().replace(',', "")).unwrap();
assert!(taxable_income >= 200000.00);

The next article in our series would explain how we implement the entire thing in RISC Zero backend in a few days and how this is then integrated with zkPass, such as issuing an on-chain SBT or finishing an off-chain verification (which is sufficient for airdrop clearance).

More applications

The techniques present here, proving data on PDFs, can be generalized to a lot of settings.

An example is CeDiploma, an electronic diploma provider with clients including Stanford and UC Berkeley, which embeds the digital signature in the PDF.

This is more challenging than IRS account transcripts for zero-knowledge proofs: not only does the decompression algorithm need to run over a larger amount of data, but the main body of the PDF consists of Bézier curves that form the text body rather than the original text in English characters (I believe it is intentional), for which a mini OCR algorithm is needed here to read my name. This, however, should be fairly affordable and do not require ZKML. Particularly, since CeDiploma always serves the same PDF file, the ZK proof only needs to be done once for each degree, and then it can be an on-chain SBT that will permanently live in the web3 world.

Another example is Docusign. The signed document together with the summary document, which are two PDF documents, can be used to prove that signers with those email addresses made the signature. See here for an example SAFT agreement (from https://saft-project.org/) and its eSignature summary. In fact, Docusign can go far away, as they also have support for more authentication methods including government ID verification and SMS verification, and they can then be verified by ZK, assuming that we trust Docusign to perform the identity verification.

Adobe Acrobat also has the same functionality as Docusign offers, through Adobe Sign, which means that one can ZK-verify the identity verification done by Docusign, Adobe, or have them both.

This can effectively create “Power of Attorney (POA)” that one can appoint a smart contract for representation on chain, by digitally signing a document. Interestingly, since “an electronic signature can be used to sign a contract, which is enforceable in a court of law” as Docusign mentions, it becomes legally enforceable.

Next article

In this first article, we are mainly addressing the motivation, positioning zkPass in the current modular blockchain stack, and presenting zkPass tech stack.

In the next article, we will dive into how zkPass can be used to obtain reliable data feeds from the IRS, as well as the RISC Zero backend.

Find L2IV at l2iterative.com and on Twitter @l2iterative

Author: Weikeng Chen, Research Partner, L2IV (@weikengchen)

Disclaimer: This content is provided for informational purposes only and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisors as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services.

Is this the end of crypto winter, or are we still being cautious, and our optimism returns after a tumultuous 2022 and 2023? It’s time to set our sights on the road ahead. While broader market indicators suggest stabilization, if not yet full-fledged recovery, the incredible building continues below the surface.

A watershed development cementing Bitcoin's institutional adoption was the U.S. SEC approval of Bitcoin spot ETFs on January 11th, 2024. This milestone saw 11 ETFs tracking Bitcoin's market price get regulatory greenlight. The move promises to funnel significant capital into Bitcoin from investors preferring regulated vehicles. Estimates suggest over $100 billion could enter Bitcoin markets in the next year through ETFs. The attendant publicity also promises to alter Bitcoin's cultural perception while redefining market dynamics.

ETFs represent the pinnacle of Bitcoin's integration with mainstream finance. Institutions can now offer customers broad access conveniently via traditional wrappers. Better visibility and liquidity beckon. Legacy giants’ aggressive marketing exposure will remove the stigma for customary investors. With the floodgates open, ETFs will likely dominate Bitcoin's narrative over 2024. Inflows stretching into the hundreds of billions would propel new all-time highs. Regulated on-ramps portend further convergence between TradFi and crypto.

Mirroring Bitcoin's watershed spot ETF moment, Ethereum is poised for a similar milestone with spot ETF approvals expected by May 2024. As the second largest cryptocurrency with a thriving Web3 economy, an Ethereum ETF opens the floodgates for billions in inflows from institutional capital seeking regulated exposure.

An SEC approved Ethereum ETF further cements the asset class' credibility in traditional finance circles. The attendant publicity promises to draw mainstream attention to Ethereum's technological leadership with transformations like proof-of-stake merging and scalability solutions catalyzing adoption.

With bluechip institutions scrambling to launch Bitcoin ETFs, allowing an Ethereum counterpart taps into intense competition around crypto offerings. The brand halo for DeFi and NFT ecosystem viability could significantly expand Ethereum's total addressable market and, subsequently, retail and institutional exposure to both ETH and BTC.

As we look towards 2024 and beyond, what are the key trends that will reshape architecture and applications dictating mainstream traction? This forward-looking analysis identifies eleven fundamental trajectories set to redefine blockchain’s evolution through 2024 based on today’s leading indicators:

• Trend 1: Restaking & Shared Security. Rollup restaking allows staked ETH validators to reuse assets for securing supplemental protocols. This amplifies staker yields while improving scalability and composability for chains. As blockchains interconnect via bridges and shared environments, understanding security tradeoffs becomes critical. Prospects appear bright for Actively Validated Services powering modular rollup stacks in 2024. 

• Trend 2: Data Availability. Ethereum's base layer upgrade "danksharding" will standardize data availability for rollups in 2023. This unlocks major cost savings that decisively boost rollup capabilities by resolving scalability bottlenecks.

• Trend 3: DEXs & Perpetuals. Decentralized exchanges are gaining share against centralized alternatives, with models like automated market makers and order book pools demonstrating incredible promise within fast-growing perpetual swaps markets.

• Trend 4: All things Zero-Knowledge (ZK). ZK rollups are gaining traction by resolving EVM compatibility issues. Also exponential growth expected in ZKML and ZK coprocessors to unlock new functionality realms for dApps constrained by blockchain limitations.

• Trend 5: Decentralized Physical Infrastructure (DePIN). Blockchains coordinating real-world infrastructure like networks and storage, efficiently displacing legacy providers via crypto-economic incentives and community alignment. 

• Trend 6: Real World Assets (RWAs). Tokenization of assets like real estate and invoices on blockchains bridges traditional finance, unlocking efficiency and transparency improvements. 

• Trend 7: Stablecoins. Despite moderate growth, stablecoins remain deeply embedded in on-chain workflows enabling vital functions like cross-chain liquidity movement and hedging volatility. 

• Trend 8: Intents. Middleware protocols decoding user intents and executing optimized transaction pathways to fulfill goals automatically, abstracting complexity.

• Trend 9: Bitcoin. Ordinal inscriptions like BRC-20 are transforming Bitcoin's utility and transaction mix, while price resilience returned in 2023. 

• Trend 10: Solana. Exceptional price and volume growth in 2023 validates Solana’s real-world capacity and ability to unlock unprecedented on-chain throughput and scalability.

Let’s dive deep.

Trend #1: Restaking and Shared Security:

Restaking refers to the concept of reusing or "re-staking" the collateral that validators have locked up in Ethereum to provide additional security guarantees or utility in other blockchain protocols or applications.

Restaking lets staked ETH that already secures Ethereum's base layer get reused to provide security for extra on-chain services.

·  Validators: Lock 32 ETH to stake on Ethereum. Restaking platforms like EigenLayer allow reuse of this collateral to secure other blockchains. EigenLayer restakes the ETH to validate transactions elsewhere. As compensation, validators get paid in that chain's token yield on their staked ETH. But they take on more slashing risk across multiple chains.

·  Users: Can stake ETH to validate Ethereum and earn rewards. Restaking directs the same staked ETH to also secure Ethereum layer 2 solutions. This "re-promises" the ETH to be slashed if validation of additional protocols fails. By reusing staked deposits, restaking maximizes capital efficiency to secure multiple solutions from the same ETH pools.

The Staking and Restaking ecosystem has grown exponentially this year. 

With this increased engagement and adoption, one key area we are excited to look into is the Restaked Rollups framework which was recently announced by EigenLayer and AltLayer.

Rollups have exploded in 2022-23, securing over $16B in assets. But smaller rollups often have centralized infrastructure, harming decentralization. Restaked rollups offer a path to resolve centralization and performance issues in Ethereum scaling solutions. By outsourcing key components like sequencing and validation to decentralized services powered by reused collateral, they promise better decentralization without sacrificing speed. They introduce:

1. SQUAD - Decentralized sequencers to order transactions

2. VITAL - Decentralized validators to verify computation

3. MACH - Faster finality of results before Ethereum settlement

If viable, this model could greatly accelerate rollup adoption and Ethereum scaling.

We foresee Actively Validated Services (AVS) powering modular rollups as a key 2024 trend based on:

1. AVS aligns with Ethereum's roadmap as rollups mature atop data availability systems. Reusable components match direction.

2. Crypto-economic primitives like programmable staking/restaking and pooled security will gain traction as tools to coordinate AVS.

3. Formalized ETH staking will enable leveraging collateral for decentralized rollup functions as it professionalizes.

It is also important to note that Restaking is not only limited to EigenLayer.

1. Polygon has shared its interest with “Enshrined Restaking”

• Polygon will enable POL stakers to earn extra rewards by redirecting staking to secure multiple L2 chains in Polygon ecosystem, not just Polygon's base layer.

• This resembles restaking by allowing staked assets to provide security to supplemental protocols beyond initial staking purpose.

2. Cosmos' Interchain Security

• Cosmos' interchain security model allows ATOM stakers to reuse staking to consensus-secure other blockchain networks beyond Cosmos Hub like Neutron and Stride leveraging shared security.

• This provides analog to restaking where validators can permissionlessly extend staking assets to power additional chains while keeping staking consolidated.

• EigenLayer recently announced strategic bridging of Ethereum and Cosmos, enabling mutual access to each other's security, liquidity, innovations, users, and node operators to amplify capabilities across both ecosystems. Now, that’s two of L2IV portfolio companies that provide shared security solutions to Cosmos: Babylon and now EigenLayer. 

3. Octopus Network for Near Protocol

• Octopus Network allows NEAR token stakers to lease their staking to secure application-specific chains like Ottochain via leased proof-of-stake model.

The fact that restaking is gaining broader traction even on chains like Near Protocol validates that the premise of amplifying staked assets for higher utility resonates. With this adoption outside of Ethereum, we will end up seeing different permutations like 

• leased security (Allowing stakers on one chain to lease their assets to secure other chains), 

• liquidity provider token staking (Staking LP tokens from AMMs to help secure protocol and earn additional yield), 

• guest blockchains bound to bridges (Standalone chains with security dependencies bound to a parent chain via bridges), etc., 

suggesting many creative configurations are possible by applying restaking.

The common driver seems to be allowing ecosystems to scale by tapping base-layer assurances to extend trust into emergent domains like app-specific chains, which expands into the concept of Shared Security.

This concept of 'shared security' refers to whether the security of assets on supplemental chains is ultimately dependent on and as robust as the security of the primary chain. 

• Rollups explicitly use Ethereum’s on-chain security because they are built on top of it while, 

• Platforms such as EigenLayer (with AVS) and Babylon (with staked BTC) enable permissionlessly 'sharing' the innate protections of base chains like Ethereum and Bitcoin by allowing staked BTC/ETH validators to reuse and redirect their collateral for securing those secondary environments like Cosmos. 

These architectures effectively maximize flexibility while ensuring integrity by leveraging decentralized assurances developed by anchor settlements.

The core question is – 

if assets or logic are moved from a highly secure "source" blockchain to an interconnected chain or ecosystem (for example, Cosmos) for on-chain validation, do they retain the same strong security model, or is security weakened?

Shared security aims to analyze these types of connections between chains and assess whether

• security is tightly shared and dependent on the primary chain 

  • "yes" for rollups via fraud/validity proofs, 

  • "no" for independent sidechains

or

• weakened through bridging across chains with now semi-independent security domains.

We believe Shared Security will become increasingly important as blockchain networks grow more interconnected through bridges, sidechains, rollups, etc., and ultimately through restaking platforms. 

Another area we are brainstorming about is reassessing where the "source of truth" lies in an interconnected system of chains, which we believe will be an evolving discussion. Specifically,  Is it the main L1 at all costs?

Chains without shared security may still derive value by providing use cases unsuitable for L1s and rollups like regulatory compliance, experimentation with new tech, customization, and more. The path to mass adoption likely involves both

1. pushing activity into shared security environments like rollups or the ones that use other L1s while also

2. improving bridges, sidechains to minimize threats for maximizing on-chain activity. 

There is room for both strategies based on use case nuances.

We also assess that the primary mechanism for shared security will be validity proofs (main component of ZK rollups). Validity proofs align well with the crypto-economic priorities of blockchains around verifying state integrity without reproducing all computations. They elegantly bridge consensus layers’ validation logic to ecosystems needing it.

If the interconnected chain supports validity proofs, it enables highly robust shared security with the source. Examples include rollups connected to Ethereum through fraud proofs, plasma chains with commitments published to root chains, some sidechain arrangements, etc.

But they come with drawbacks like requiring extra data availability, complex fraud proof mechanics, and some centralization around operators batching transactions. Tradeoffs exist.

However, in the long run, we expect solutions to mitigate these issues considerably. For example, 

• mass validity proof generation at client level, 

• UTXO commitments for data availability (a good case study for this Babylon with Bitcon), 

• universal fraud proofs, and so on.

These could theoretically enable sharing not just asset security, but also bandwidth, storage and computing between chains/rollups. However, questions persist if validation logic remains anchored on public base layers without mechanical verification cultures. Settlement finality may necessitate an immutable "ground truth".

Open Question: Are the L1 chain always the security source of truth?

Trend #2: Data Availability (DA)

In case you don’t know what DA is, here’s a short blurb:

Data availability refers to the ability of nodes in a decentralized blockchain network to easily access the complete and truthful record of transactions or state changes that have occurred on the network. 

• In blockchains like Ethereum, transactions get grouped into blocks which represent the latest state of the ledger. For the network to function securely, the full details of every block need to propagated to all nodes so they can validate state transitions.

• However, sometimes block producers may intentionally or accidentally withhold or limit access to some of the data in a published block. This constitutes a failure of "data availability".

• Lack of availability means nodes no longer have an accurate record of network state on which to evaluate future transactions. They cannot independently verify the integrity and correctness of state changes, severely compromising trust and security.

This is why data availability is critical - all nodes must receive the complete details of all blocks and transactions in a timely manner to achieve decentralization and censorship resistance. The full truthful dataset must be readily accessible to any node that wishes to validate the chain's state.

We also wrote a detailed three-part series on Data Availability, which you can read here: Part 1, Part 2, and Part 3.

We believe Data Availability will be a pivotal trend in the coming year due to the confluence of several key factors:

• Rollup adoption is accelerating as the preferred layer 2 scaling approach for Ethereum, with rising transaction volumes and total value locked. Ensuring efficient and decentralized data availability becomes increasingly critical to avoid bottlenecks or security risks as adoption grows.

• Innovations in data availability schemes are gaining momentum, including advances in erasure coding, polynomial commitments, and availability sampling techniques. These provide the cryptographic constructions for scalable and lightweight data availability perfect for fast-moving rollups processing thousands of transactions per second.

• Economic incentives around data availability are improving, including staking pools and protocols focused on decentralizing storage and rewarding availability providers. This supplements the technology with appropriate crypto-economic mechanisms.

• Changes at the base layer, like proto-danksharding, will provide standardized data availability and fraud-proof interfaces between Ethereum and rollups. This will allow seamless interoperability between DA schemes and Ethereum. 

As far as trends go in with DA and scaling Ethereum, as DA emerges as a crucial blockchain infrastructure sector, we face an important strategic choice:

• Should DA primarily be viewed as a commodity capability, with providers competing mainly on driving down costs for availability services and racing to achieve the best economies of scale?

OR

• Could there be lasting advantages for DA providers that actively differentiate by prioritizing community alignment rather than pure cost and capacity factors? Things like cultivating brand loyalty among developers, supporting specialized use cases, and bonding through shared values versus just transactions.

Put another way:

• Will the market evolve towards a few mammoth DA layers competing on the lowest price to serve the majority of rollup needs?

OR

• Can smaller, niche DA layers catering to specific aligned needs & use cases also thrive long-term alongside commoditized mass market offerings?

The case for viewing DA as a commodity service and cost-driven race to the bottom:

At its core, DA solutions provide a reliability function for rollups - allowing transaction data to persist over long timeframes so it remains accessible across clients for state derivation and withdrawal purposes. This data storage and serving requirement has parallels to cloud infrastructure offerings.

And infrastructure services, across computing, networking and storage categories, have consistently trended towards commoditization over time as our question notes. The drivers behind this apply to DA as well:

• Economies of Scale: As DA providers grow to serve more rollups and shards, they reap significant fixed cost savings that smaller niche players cannot match. Giants like AWS and Azure exemplify using sheer size and massive data centers to undercut niche cloud infrastructure providers on costs. Cloud infrastructure has demonstrated how economies of scale allow providers to drive surprisingly low costs over time for commoditized services like object storage, bandwidth, and computing. There is precedent for scale significantly reducing margins.

• Rapid Technology Maturation: The tooling and best practices for managing distributed data storage and query infrastructure are advancing quicker than ever thanks to public cloud maturation. DA providers can leverage proven foundational tech like distributed databases, erasure coding, and indexing to deliver availability services without substantial proprietary innovation. Quickly commoditizing the core technology stacks. Many core distributed systems technologies like erasure coding, content addressing, and global replication are now well-understood and increasingly adopted from public cloud providers. This maturity could accelerate commoditization.

• The baseline DA functionality mirrors simple cloud object/blob storage demands rather than specialized needs. Metrics like query throughput, latency, consistency, and, of course, ultra-low Total Cost of Ownership (overall expenses accrued over the lifespan of operating and managing a system) are shared requirements between both rollup availability providers and commodity cloud storage services, further driving commoditization.

In essence, DA solutions compete to provide a "good enough" reliability function that supports withdrawals and state proofs for the lowest viable cost. Just as cloud infrastructure has become dominated by economies of scale, the base DA needs seem primed for cost-driven commoditization as well rather than more bespoke reliability engineering.

The upcoming EIP-4844, also known as "proto-danksharding," will provide a significant boost to data availability for rollups and sidechains by reducing costs. Here is a brief overview:

• Native DA Layer: EIP-4844 introduces a native data availability layer to Ethereum, allowing rollups and sidechains to post data in a highly robust and decentralized way.

• Predictable Data Storage Costs: By having an invariant cost model for data, gas fees for data availability become predictable. This is a major improvement over reliance on calldata for posting data.

• Cheaper than Calldata: The gas costs for using the native DA layer data blobs are expected to be considerably cheaper than putting rollup data in calldata. Estimates are 1/10th the cost.

Data availability via proto-danksharding will be a game changer. We wrote about the influence of EIP-4844 on data availability, shared sequencing, and Ethereum fee markets in detail here: Road to Danksharding. It would help a bit if you read this (EIP-1559) before diving deep into EIP-4844.

Open Question: Will competition emerge on cost or community alignment?

Trend #3: DEXs and Perpetuals (Derivatives)

DEXs

DeFi has been witnessing significant changes, especially within DEXs and perpetual contracts. The year 2023 has seen groundbreaking shifts and trends in this space, marking a pivotal moment in the crypto community’s development and adoption of these technologies.

Surge of Solana in the DEX Space

One of the most noteworthy trends in 2023 has been the meteoric rise of Solana in the DEX market. Historically dominated by Ethereum, the DEX landscape saw a dramatic turn when Solana briefly surpassed Ethereum in DEX trading volume in December. Solana’s DEXs registered a trading volume of $1.536 billion, momentarily eclipsing Ethereum’s $1.164 billion during the same period. This shift indicated Solana’s growing influence in DeFi and its robust growth trajectory​​​​​​.

Two key elements fuelling Solana's ascent in the DEX space have been the USD Coin (USDC) stablecoin and the emergence of the Bonk memecoin. Bonk, particularly, has seen a rapid rise in market capitalization, becoming the third-largest memecoin by market cap. This surge in trading activity was not limited to digital assets alone; it also impacted the physical world, as evidenced by the sell-out of Solana’s blockchain-enabled Saga smartphones, with secondary sales reaching remarkable prices​​​​.

Shift Towards Cross-Chain Strategies

Leading DEXs such as dYdX, Pancakeswap, Uniswap, and Vertex have started embracing cross-chain strategies. Initially finding success on single chains, these platforms are now expanding to multiple chains to develop better products for their users. This move towards cross-chain interoperability signifies a maturing market and the need for more integrated and comprehensive DeFi solutions​​.

Cross-chain dex development allows tapping into the strengths of different blockchain networks. Leveraging Solana's speed for order matching while settling on Ethereum's security promises the best of both worlds. However, making these cross-chain systems work cohesively will require top-notch developer experience across frameworks like Wormhole and Connext. There is also the risk of increased centralization with bridges and liquidity siloed at only dominant hubs. Tackling these concerns will be pivotal as interoperability gains traction.

Perpetuals

The perpetual DEX landscape is characterized by a variety of innovative models. Protocols like dYdX replicate the Central Limit Order Book (CLOB) model, while others like DriftProtocol adopt a hybrid approach, combining traditional order books with automated market makers (AMMs) for effective on-chain matching. GMX and Kwenta.io have introduced novel Liquidity Pool (LP) models, with Kwenta.io leveraging the Synthetix Debt Pool to minimize slippage and facilitate trading in synthetic assets and perpetual futures​. So we have seen protocols building and innovating. 

Perpetuals have emerged as the go-to derivative instrument in crypto markets, catering seamlessly to leverage trading needs of both retail and institutional traders. Their flexible open duration and funding rate driven index price alignment results in a trading experience akin to spot markets. This intuitive appeal makes increased adoption inevitable.

Protocols are innovating along multiple dimensions:

• novel AMM algorithms to mimic order book behavior, 

• combinations of order books and AMM pools, 

• liquidity pools with pooled leverage, and 

• custom app-specific L1/L2 solutions. 

This expanded design space promises creation of products with unique value propositions.

The total potential market cap for these products adds up to over $1 trillion in monthly trade volumes across CEXs and DEXs. Perp DEXs have only scratched the surface, capturing a 3-5% share historically. But the innovation and DeFi mindshare make a doubling or tripling of market share over the next year seem feasible.

Perpetuals account for a relatively small portion of the total open interest (OI) on crypto exchanges, representing only 3% or $600 million of the $20 billion total OI on CEXs. The trading volume on decentralized perpetual platforms, after peaking in Q4 2021, has been on a downtrend, except for a spike in Q1 2023, indicating a fluctuating yet growing interest in this sector. Notably, dYdX dominates the decentralized perpetual protocol market with a 58.8% share, followed by other players like GMX and Level Finance​​.

There are several compelling reasons why DEXsand Perpetuals are key trends to watch in the coming year:

Shift Towards Decentralization in Trading: There's a notable shift from centralized to decentralized exchanges, as evidenced by Ethereum's ecosystem. The decline in Ethereum balance on centralized exchanges (29.7% decrease to $14.21 million in ETH in December 2023 from $20.23 million in ETH earlier in January 2023) and the concurrent increase in TVL in Ethereum-based DeFi (from $22.16 billion to $27.63 billion) highlights a pivot towards DeFi. This trend indicates a growing preference for decentralized and more autonomous financial solutions​​.

The accelerating withdrawals of Ethereum from centralized exchanges to private wallets or DeFi platforms indicates rising confidence among crypto investors to take custody into their own hands. This signals a maturation where concerns over safely storing private keys are getting gradually addressed through solutions around seed phrase backups, account abstractions, social recovery wallets, and insurance products. The trends validate growing mainstream comfort with principles of self-sovereignty.

The innovations in DEXs and Perpetuals, particularly those operating on efficient blockchain networks like Solana, showcase a trend toward more sophisticated trading platforms. For example, Jupiter, the top DEX on Solana, with a daily trading volume of over $180 million, demonstrates how these platforms are evolving to offer better liquidity, speed, and user experience​​.

Foreshadows an Evolution to Sophisticated Algorithmic Trading

The increasing volume of exchange inflow/outflows relative to overall network activity indicates the growing sophistication of trading strategies deployed on Ethereum. It likely points to adoption of advanced programmatic techniques like arbitrage, portfolio rebalancing, and liquidations across DeFi portfolio management platforms. As algorithms permeate trading, on-chain activity is bound to intensify. The numbers signify technological defensibility allowing sustainably decentralized and transparent financial use cases to gain traction. 

Open Question: Can long-term sustainability match early growth and volumes?

Trend #4: All Things Zero-Knowledge (Rollups, Coprocessors & ZKML)

Zero-knowledge technology has garnered substantial traction as a tool for enhancing scalability, privacy, efficiency, and functionality across blockchain systems. Specifically, 2023 marked extensive zero knowledge proof deployment, epitomized by high-profile launches of multiple zk-rollup networks designed to boost Ethereum transaction throughput.

Just a refresher, rollups involve bundling or "rolling up" batches of transactions off-chain before submitting condensed cryptographic proofs to the main chain, minimizing fees and congestion. Two main rollup variants exist – optimistic rollups with fraud proofs and ZK (zero knowledge) rollups leveraging novel zero-knowledge proofs for validity attestations without revealing underlying data. Due to their ingenious cryptography, we believe ZK rollups might be the king of spades and ultimately overtake market share.

ZK rollups initially struggled with EVM incompatibility, but new zkEVMs resolve this by elegantly facilitating EVM smart contract migration, as showcased through various 2023 zkEVM mainnet debuts of zkSync Era, Polygon zkEVM, Linea, Scroll and Taiko (an L2IV portfolio company). Parallel growth of rollup deployment simplification platforms (Rollups as a Service ‘RaaS’) further lowers the threshold for ongoing ZK innovation.

Looking beyond rollups, zero-knowledge techniques offer multifaceted applications like off-chain data relay and complex computation via “ZK coprocessors” without compromising decentralized security assurances. By generating proofs validating correct off-chain execution, dApps can unlock new functionality realms traditionally constrained by blockchain’s limitations. For example, coprocessors could allow L2 DEXs to implement opaque trading mechanisms or on-chain games to conduct intensive behind-the-scenes processing - all while benefiting from the robust integrity guarantees of Ethereum.

These capabilities relate to simmering discussions around optimizing dApp engineering frameworks. There are arguments for transitioning foundational infrastructure off-chain while retaining blockchain for permissionless settlement finality. There has been constant thinking suggesting rethinking the notion that everything requires on-chain enclosure, citing models like ZK coprocessors, which demonstrate that off-chain can confer equal or better effectiveness. However, fully exiting smart contracts risks unintended tradeoffs.

Smart contracts are revered for their efficient, automated code execution. However, their predefined rigidness sometimes hinders adaptability, especially in dynamic situations. This is where machine learning could confer improvements. ML models trained on massive datasets can continuously learn, adapt, and drive accurate forecasts. Integrating these capabilities into smart contract logic unlocks more customizable and intelligent capacities.

A major hurdle with on-chain ML remains the sheer computational overhead. This gave rise to Zero Knowledge Machine Learning (ZKML) - fusing zero knowledge proofs with off-chain ML to allow verifying model integrity without exposing underlying data. In this architecture, models train off-chain then generate proofs validating prediction accuracy for on-chain verification.

ZKML hence unlocks AI-powered smart contract versatility while still ensuring blockchain's inherent transparency and security. For example, automated market makers could leverage ZKML for long-tail asset pricing based on advanced ML valuation models, with validity proofs preventing exploitation. Prediction markets also benefit from enhanced crowd wisdom mining and assurance.

One example we saw was of Upshot's ZK Predictor using Modulus Labs zero knowledge circuits. This allows Upshot to securely harness complex data for asset appraisals, with Modulus technology encapsulating the AI's computations into proofs that verify to blockchain without revealing actual model mechanics or training data.

A concrete use case demonstrating the power of ZKML is that of Sturdy V2 with Risc Zero. This yield aggregation protocol aims to optimally allocate user funds across whitelisted lending pairs to maximize returns. However, determining ideal asset distributions to maximize yield poses an optimization challenge suitable for advanced algorithms. Although AI could solve this allocation problem, performing such heavy computation on-chain would be prohibitively expensive. This is where Sturdy leverages RiscZero's ZK coprocessor to enable verifiable off-chain computation.

Specifically, RiscZero's solution allows running ML algorithms off-chain while generating zkproofs that attest to the correctness of the asset recommendations. These proofs can be verified on-chain to validate algorithm integrity without exposing underlying intellectual property. This architecture provides major advantages to Sturdy users. First, yields are maximized through optimized AI-driven allocations. Second, gas costs are slashed by keeping intensive computation off-chain. And third, the zero knowledge proofs retain assurances around computation integrity. So in tangible terms, Sturdy V2 users can soon deposit funds into aggregated lending pairs personalized to their risk preferences, earning superior yields from AI-optimized allocation without expensive rebalancing or gas fees. The zk proofs guarantee computation validity without exposing proprietary models themselves.

At a high-level, the solution aptly demonstrates ZKML's value prop - customized ML algorithms for optimization tailored to the application, combined with trust minimization and gas efficiency from proofs verification without exposing sensitive IP or data. This could expand to other recommendation systems like personalized portfolio construction, credit modelling for on-chain underwriting, automated strategy rebalancing in DeFi, and more. Crypto native apps may lean more heavily into these techniques compared to traditional firms, given lower regulatory overhead.

But even initial proofs-of-concept demonstrate the immense potential of marrying AI and blockchain through cryptography. We truly believe exploring hybrid on- and off-chain schemas may grant ideal paths forward as the vision of modular ecosystem maturation continues.

ZK + Privacy

Another use case to look into as zero-knowledge proofs become integral is within blockchain's transparency with privacy demands. One such example is Elusiv, which brings programmable confidentiality to Solana using established zk-SNARK constructions.  By compiling high-level privacy circuits with systems like Circom into proofs that validate without exposing, Elusiv taps into the promise of mathematics to enable trustless anonymity. This allows relying on provable security instead of obscurity unlike previous mixers and tumblers. Yet unlike maximalist privacy chains severing auditability, Elusiv retains decentralized compliance making anonymous transactions viable at scale.

Its growth into an interoperable confidential layer will test whether zero-knowledge technology has crossed the chasm from cryptographic curiosity to an indispensable privacy apparatus across institutional blockchain adoption. Regardless, by addressing usability gaps of existing and compliance-restricted mixers and privacy networks, Elusiv's ability to reconcile the needs of confidentiality and accountability serves as an essential on-chain service for institutions and consumers alike.

Open Question: Is off-chain a necessity or dilution of decentralization?

Trend #5: Decentralized Physical Infrastructure (DePIN)

The world has grown dependent on large centralized providers controlling critical infrastructure like the internet, cloud computing, wireless connectivity, and more. A handful of opaque corporate gatekeepers dominate these trillion-dollar industries, extracting value while innovation stagnates. What if there was a better way to manage the infrastructure platforms we all rely on - one that is more transparent, fair, resilient, and empowering? Enter decentralized physical infrastructure networks (DePINs).

DePINs are blockchain-based networks that coordinate the buildout and operation of physical infrastructure, from data centers to wireless coverage, more efficiently than legacy providers. By leveraging crypto-economic incentives and community alignment, they promise to unlock the decades-old bottleneck of infrastructure centralization.

While the vision of DePIN has existed for years, 2024 could mark a pivotal moment for mass adoption due to several key trends aligning:

1. Inflationary pressures are driving the desire for lower-cost alternatives to legacy services amidst economic turbulence, perfectly aligning with DePIN value propositions around community ownership reducing costs.

2. Web3 participation has strengthened with prior crypto market cycles, priming a ready user base willing to contribute devices and assets to bootstrap network effects for DePIN platforms.

3. Maturing crypto-economic token models (1, 2) and reduced speculation is allowing protocols to focus resources on real-world utility over marketing, leading to demonstrations of sustainability.

4. Enterprise interest in tokenized business models and blockchain-enabled resource coordination is at all-time highs based on institutional capital inflows, pointing to future private sector utilization of DePIN networks at scale.

The collective momentum across these vectors explains why decentralized physical infrastructure adoption seems poised for an inflection point. Technological readiness, demand drivers, and proven real-world capacity combine to set the stage for an escape from niche footing into the mainstream.

Specifically, if we look at the telecom industry, behemoths like AT&T and Verizon have accumulated tremendous control over access and profits. They charge monopolistic fees for spectrum access and basic connectivity while customer service suffers.

DePINs like Helium and Althea are proving that decentralized grassroots networks can provide wireless bandwidth at lower cost, higher quality, and with community ownership. Anyone can participate by deploying some basic hardware and earning tokens in return.

The same dynamic is playing out in

• decentralized storage (Filecoin),

• compute (Golem),

• sensors (Presence), and

• identity (Civic).

What's unique about DePINs is that they create a positive feedback loop as they grow - accumulating more resources and aligning more interests within each network.

• For Helium, more wireless hotspots mean wider coverage at lower latency plus additional value-added services.

• For Filecoin, more distributed storage capacity means lower prices, better reliability and availability, and now additional computation use cases in web3.

• For Livepeer, more video transcoding miners means higher definition multimedia content can stream across the decentralized web. It unlocks adoption by platforms like Twitch, YouTube, and TikTok to tap censorship-resistant infrastructure.

• For Ocean Protocol, each new valuable dataset onboarded expands the data supply available to AI consumers. More data asset liquidity begets more model developers, thus more service demand. Eventually dominating vertical use cases currently relying on Big Tech corporates for intelligence.

This self-reinforcing flywheel is extremely powerful.

While traditional infrastructure plays suffer from diseconomies of scale, bureaucracy, and misaligned incentives between shareholders, employees, and users, DePINs largely avoid these issues by automating governance and simplifying participation through tokens. There's no need to trust CEO decisions or sign restrictive Terms of Service. Everything is voluntary, transparent, and community-driven. Solutions emerge organically from users and developers themselves.

With over $20 billion in market value across 650+ networks, DePINs are gaining tremendous momentum with support from top crypto investors. Annualized revenue exceeds $15 million generated on-chain, cementing real-world usage beyond speculation.

The trend boils down to consolidating the ecosystem into

• Consuming vs. Providing infrastructure resources as

  • Network Extractors & Network Contractors

• Capturing vs. Creating value in the network as

  • Capacity Lessees & lessors.

This is still just the beginning. However, realizing the potential requires avoiding past crypto pitfalls like ignoring usage in favor of speculation or insufficiently decentralized networks. Projects that focus first on building utility and usage tend to be more resilient.

For example, on-chain revenues for top DePINs dropped only ~20-35% during the last crypto bear market compared to over ~70% for most other crypto verticals.

As DePINs mature technologically and economically, they will continue intersecting with bleeding-edge trends like zero-knowledge proofs for privacy and verifiable claims, AI integration directly on-chain, play-to-earn gaming built on real-world activity, and viral memecoin distribution tactics. We will witness unexpected "vampire attacks" on legacy Web2 infrastructure as decentralized alternatives siphon off demand by better incentivizing users.

No one can predict how quickly decentralized regimes will displace the old guard, or which projects will lead the revolution. But the economic gravity of transparent, community-owned infrastructure is inevitable. The dominant platforms of today will eventually go the way of Ma Bell telephone monopoly or Myspace social network. Too much value will flow into open networks that grow stronger the bigger they get.

Of course, decentralized systems bring their own challenges like governance disagreements, incentive misalignments, regulatory uncertainty, and technical shortcomings. Not every DePIN project will succeed or be sufficiently decentralized in practice. But for an individual or collective trying to exit the prevailing regime of infrastructure control, or unlock and capture new value from physical networks, DePINs represent the most credible path forward.

Open Question: Can they decentralize sufficiently and avoid speculation distractions?

Trend #6: Real-World Assets (RWAs)

The concept of representing real world assets like real estate, invoices and commodities on the blockchain has rapidly gained momentum since 2020.

With initially only seeing the adoption within 

• Collectibles & Art (fine art, rare books, jewelery), 

• Financial assets (Public equity, treasuries, debts, and commodities) and 

• Real estate (commercial, residential, debt), 

This process of asset tokenization saw exponential growth through 2023, with over 100% increase in number of tokenized products coming on-chain, with new verticals emerging in 

• Infrastructure (Energy infrastructure, Renewables), 

• Gaming (IPs, royalties, physical assets) and 

• Data (Personal, financial, IoT).

This process of asset tokenization saw exponential growth through 2023, with over 100% increase in number of tokenized products coming on-chain across verticals, and 2837% increase in TVL from January 2022 ($178 million) to January 2024 ($5 billion).

A major part of this growth has come from stablecoins (discussed in next section) backed by real world assets instead of just fiat collateral. These RWA-backed stablecoins have carved a niche for usage in global trading and remittances. They provide the twin benefits of cryptocurrency systems as well as stability through asset backing.

Ethereum remains the leading blockchain for asset tokenization by total value, with over $1.5 billion in real world assets represented. This includes assets across real estate, gold, invoices, and more. Stellar and Polygon follow in second and third place, with $300 million and $116 million tokenized so far, with treasuries being the most tokenized assets.

The reasons for Ethereum’s lead are understandable when we consider the transformative impact that blockchain technology can have. Processes for securitization of loans and assets involve multiple intermediaries today, leading to higher costs and complexities. Blockchain enables automation through smart contracts, reduces costs and speeds up processes. Originators can now collect royalties on secondary trades, open credit scoring models can be built, and sale costs can be significantly reduced.

These real-world asset protocols are effectively collaborating with traditional finance institutions and attracting their interest in blockchain adoption. JP Morgan, Wells Fargo have also shown willingness to experiment with RWA technology. The scale of TradFi and DeFi collaboration has reached unprecedented levels in 2023.

For crypto-native entities like DAOs, tokenization provides previously unavailable opportunities in asset ownership and treasury management. Even intangible assets like intellectual property and patents are getting tokenized, promising more monetization avenues for individual creators.

As we look forward to 2024, integration of RWAs into DeFi is poised to accelerate even faster. Protocols facilitating asset tokenization and on-chain representations will gain more adoption.

With asset tokenization, the market can transfer both tangible and intangible assets like real estate as well as patents and copyrights respectively. RWA protocols are bridging to traditional finance markets, allowing more decentralized and efficient models for investment and growth.

Despite regulatory uncertainties that remain, the opportunities for efficiency, transparency, and accessibility improvements through asset tokenization continue to drive rapid innovation in this space. The balance between permissionless innovation and regulation will shape the final impact of RWAs.

Open Question: What is the ideal balancing innovation pace and necessary regulation?

Trend #7: Stablecoins

Stablecoins have risen in popularity as they enable several key functions - acting as a hedge against currency volatility, facilitating cross-border transfers and remittances, and allowing movement of funds between cryptocurrency exchanges and DeFi platforms. A major reason behind their success is the accessibility they provide to U.S. dollars, especially for overseas individuals who face difficulties or barriers in directly accessing USD otherwise.

As the demand & utility for stablecoins continues to grow, there are opportunities to further mature stablecoin solutions. On the technology side, different models are being explored to achieve an optimal balance between stability, scalability, and decentralization. Asset-backed stablecoins using real-world collateral like commodities and government securities can help minimize volatility. Solutions around user onboarding, education and simplifying access are also vital for driving mainstream adoption across retail and institutional users.

As we saw earlier in the RWA trend section, Ethereum-based tokenized U.S. Treasuries have gained some traction as they allow representing traditional assets over blockchain rails. However, availability remains constrained to professional investors in select jurisdictions due to compliance requirements around custody and redemption. Over time, such tokenization could help connect traditional and digital asset finance.

For most everyday users, fiat-backed stablecoins like USDC or Tether's USDT remain the most popular due to their relative stability and liquidity. Though decentralized algorithmic stablecoins offer theoretical advantages, they are yet to demonstrate real-world viability at global scale and adoption as a widespread medium of exchange.

As stablecoins have become deeply integrated and being widely used as a quoting currency-- this reliance became evident in the last market cycle where aggregate stablecoin supplies played an outsized role.

Total stablecoin market capitalization had reached an all-time high in May 2022 ($178B), but dropped 26% from those peak levels in January 2023. This decline can be attributed to a confluence of factors - ranging from regulatory actions like the SEC charges against Binance's BUSD, rotation into interest-bearing assets like U.S. Treasuries, and dampened investor appetite in a prolonged bear market.

As of January 2024, the total market capitalization of stablecoins stands at $133.75 billion. 

The draining liquidity has been a major headwind at a time when trading volumes and volatility have already dried up. However, stablecoins remain embedded in exchange workflows. As such, their ubiquity and importance in enabling transactions provide a strong case for not just U.S. dollar-denominated offerings but also euro and yen alternatives to facilitate global accessibility.

Speaking of regulations, the Financial Services and the Treasury Bureau (“FSTB”) and the HKMA have released a new consultation paper outlining a proposed regulatory overview for fiat-referenced stablecoin issuers. This represents an important step towards providing guardrails and protections in the evolving stablecoin landscape.

The motivation stems from risks around stablecoins failing to uphold pegs and disrupting economic activities. To mitigate such threats, the proposal plans to introduce stablecoin issuer licensing requirements and stabilization mechanisms like high-quality reserve asset backing. Redemption rights at par value are also proposed. Additionally, the consultation paper calls for governance, risk management, and AML safeguards while restricting stablecoin distribution to only licensed issuers.

The move aligns with global policymaker efforts to balance stablecoin innovation opportunities with financial stability imperatives. It reinforces the importance of delivering reliability assurances to realize mainstream potential. The consultation also underscores how maturing stablecoin solutions must instill trust by reconciling decentralization with pragmatic stabilization and accountability guarantees. Hybrid models adhering to jurisdictional norms could enable global reach.

This ties well back into the overarching RWA theme around bridging traditional and digital asset realms. Compliant stablecoin issuers, for instance, could fluidly transmit stable purchasing power across blockchain rails, spearheading convergence.

Open Question: Can algorithmic stablecoins achieve global scale and mainstream usage without crypto-collateralization if asset-backed models succumb to regulatory clampdowns?

Trend #8: Intents

Decentralized finance (DeFi) holds great promise to deliver financial access through disintermediation. However, critics have long argued that current DeFi systems are too complex for mainstream adoption. Interacting with DeFi protocols typically requires manually constructing intricate, multi-step transaction pathways - approving tokens, bridging assets across chains, setting slippage and gas fees, and more. This burdens users with unnecessary complexity. ​​

Now, the concept of “intents” aims to change all of this. Instead of needing to understand transactions, users can simply declare their overarching goals or “intents” in plain language. For example, “I intend to acquire 2 ETH on Optimistic Ethereum using my USDC tokens on Mainnet Ethereum when ETH drops below $1600 in the next 3 days.”

This high-level intent encapsulates the user’s desired outcome without any transaction specifics. It is relayed to an automated “solver” system that specializes in decoding intents and fulfilling them through optimized transactions. These solvers could be middleware protocols or professional market-maker entities equipped with trading algorithms, liquidity bridges, arbitrage infrastructure, and more for interchain execution.

Upon receiving a user’s intent transaction, the solver parses it, formulates an optimal transaction pathway to fulfill the goal, and executes trades across necessary protocols and chains - while charging the user a small fee. The user simply waits for their desired outcome while all complexity is handled behind the scenes by the infrastructure purpose-built for this job.

Some Key Trends We are Following

1. Convergence of Liquidity and Specialization

   In intent-based infrastructure, execution responsibility converges from end-users into dedicated solver entities. This reflects growing specialization and professionalization of market making in DeFi. Sophisticated algorithms can extract profits from volatility and arbitrage far better than regular users, so shifting execution onto professionally managed systems unlocks efficiency. There is also likely to be a convergence of liquidity from disparate DEXs into centralized exchange-like aggregated pools. This will allow solvers faster and cheaper access to liquidity needed to fulfill user intents, especially cross-chain intents.

2. Shift Towards Off-Chain Computation

   Another trend is the movement of execution itself off-chain when feasible, with only settlement transactions hitting layer-1 chains for security. Solvers may turn to centralized exchanges as liquidity sources, then settle token swaps on Optimistic Rollups in batches to reduce costs. Avoiding direct layer-1 transactions provides substantial savings on gas fees.

   Linkages bridging crypto with mainstream finance are also probable. Solvers may leverage traditional banks, prime brokers, and trading firms as part of bridging assets and executing user intents across both crypto and fiat currency environments seamlessly.

3. Focus on Simplicity of User Experience

   Finally, the rise of intents reveals a pivotal shift - away from retaining all complexity on L1 in pursuit of decentralization towards simplifying user experience by outsourcing complexity off-chain, even via some centralization. Mass adoption requires appropriate abstraction of unnecessary intricacies without sacrificing censorship resistance at the settlement layer.

   While this approach offers substantial usability improvements, some inherent downsides exist.

   1. Firstly, relying on solver intermediaries may reintroduce third-party dependencies.

   2. Secondly, extensive off-chain computation and exchanges with centralized entities dilute auditability and verification assurances.

   3. Finally, solver fees are likely to accrue over time, especially if the system entrenches oligopolies.

This shift marks an important step towards unlocking mainstream DeFi adoption by abstracting unnecessary complexity.

Open Question: Does relying on intermediary solvers to decode intents and execute on behalf of users reopen dependencies on trusted third parties and reduce auditability compared to on-chain transparency?

Trend #9: Bitcoin Market Updates

At the start of the year, we all prayed and speculated around when will Bitcoin cross the $30k mark. We finally got an answer in the past few weeks.

The Bitcoin market has demonstrated exceptional strength in the later part of 2023, surpassing multiple technical and on-chain pricing models.

As we all noticed, throughout 2023, Bitcoin prices found themselves oscillating between the least volatile periods in the cryptocurrency's history. This period of calm was briefly disrupted when a swift deleveraging event in August caused a dramatic drop in prices, from $29k to $26k, falling below both the aforementioned long-term averages.

The market dynamics point to a potential pause or pullback following exceptional performance. Specifically, Bitcoin rose to break the $44.5k level to reach a new peak for the year so far. However, it experienced the 3rd largest sell-off of 2023 subsequently. This round trip indicates the rally faced significant resistance on approach to $45k.

However, the real game-changer came in October, with a rally that not only recouped all previous losses but also shattered the crucial psychological barrier of $30k. This surge led Bitcoin to its yearly high of $44.5k, with a current consolidation around $42k.

The acceleration of capital flows and market momentum since late October is a central theme of this analysis. This was particularly evident when Bitcoin prices broke above the $30k level, transitioning from an 'uncertain recovery' phase to an 'enthusiastic uptrend'.

Additionally, the rise in exchange inflow and outflow volumes for both BTC and ETH throughout the year suggests a growing interest in spot trading. Notably, BTC volumes have increased more rapidly than ETH, a common trend following long bear markets:

1. In 2011, Bitcoin crashed from $32 to $0.01 due to a major security breach and bitcoin theft at the Mt. Gox exchange. It took over 2 years for Bitcoin to recover to its previous high.

2. In 2014-2015, Bitcoin crashed from over $1,000 to below $200. This was attributed to crackdowns on Bitcoin by Chinese financial institutions as well as major exchanges like Mt. Gox halting operations due to hacks and thefts. The bear market lasted over a year.

3. In 2018, after hitting an all-time high of $20,000 in late 2017, Bitcoin crashed to below $3,200 within a year. Major factors included hacking of exchanges like Coincheck, advertising bans by the likes of Facebook and Google, and rejection of Bitcoin ETFs by US regulators.

4. In mid-2021, Bitcoin fell from $63,000 to around $29,000 within months. Concerns over the environmental impact of Bitcoin mining, as well as mining bans in China, contributed to this crash. However, it lasted only a few months.

5. In 2022, Bitcoin crashed from an all-time high of $68,000 to below $20,000 in June. Major stablecoin crashes like that of TerraUSD triggered this latest bear market which wiped out nearly 2 years’ worth of price gains.

Bitcoin has always recovered from crashes eventually, as we saw in 4Q 2023.

Bitcoin transaction counts also reached new highs due to the rise of Ordinals and Inscriptions. These transactions, which embed data such as text files and images within Bitcoin transactions, have led to a significant increase in both the number and types of transactions.

Despite inscriptions accounting for about 50% of confirmed transactions, they surprisingly occupy only 10% to 15% of block space. This anomaly is due to the small size of text files and the nuances of the SegWit data discount. Inscriptions have contributed significantly to total transaction fee revenue for miners, highlighting the complexity of SegWit's impact on transaction fees and block space.

On the topic of Inscriptions and Ordinals, BRC-20 has been taking Bitcoin by storm.

The emergence of Bitcoin ordinal inscriptions has been transformative for the ecosystem in 2023. Originally pioneered by @domodata with the release of the BRC-20 specification in March, inscriptions have enabled seamless on-chain token creation and transferal leveraging Bitcoin's blockchain.

By embedding token contract logic within ordinal inscription transactions on Bitcoin, BRC-20 ushered in a revolutionary new paradigm. One that moves key functionality like minting and transfers directly onto Bitcoin's base layer in a decentralized manner.

The innovations have also sparked broader industry adoption. Inscriptions are now spreading to other chains as ways to embed arbitrary data. However, their popularity has also been a double-edged sword. Chains like Arbitrum and zkSync faced congestion issues earlier last week due to widespread inscription spamming.

Nonetheless, Bitcoin remains the trailblazer, with ordinal inscriptions forming a majority share of its transactions. Around 60% of Bitcoin transactions are currently BRC-20 ordinals carrying inscription data. Given the growth ahead for inscription-based tokens and contracts, this metric can rise further.

Open Question: Can inscription popularity and congestion be managed?

Trend #10: Solana Market Updates

Solana has been flying lately. Never in the history of cryptocurrencies and blockchains has any crypto made a miraculous recovery after being slashed down ~97% two years ago. 

Solana's price fluctuations in the past were heavily influenced by external factors, including the FTX collapse. However, the underlying blockchain technology remained fundamentally sound. This resilience played a crucial role in its recovery. By the end of 2023, Solana's price saw a remarkable increase, valued at around $111.7 (As of 27^th Dec, 2023), which marks a staggering growth of over 900% in less than a year. This recovery mirrors Solana's performance in 2021, showcasing its ability to reclaim a prominent position within its sector​​.

A key factor behind the price increase is Solana's unique consensus mechanism, Proof of History (PoH). PoH orders transactions using cryptographic timestamps, enabling a secure and efficient consensus. This technology enhances the scalability and security of the blockchain, contributing to higher transaction throughput and reduced computational workload. As of 2023, Solana's blockchain is capable of handling thousands of transactions per second, which is significantly higher than many other layer-1 blockchains​​.

In parallel, the Solana ecosystem has been growing, and growing fast.

Over the weekend of Dec. 24th, Solana's trading volume on major centralized exchanges surpassed that of Bitcoin and Ethereum combined. Data from Coinbase, Kraken, Gemini, Upbit and MEXC corroborated this - showing Solana beating Bitcoin and Ethereum for 2-3 days straight.

Charts shared by analytics platform Kaiko showed Solana’s trading volume approaching 40% share of total volume on centralized platforms. Bitcoin and Ethereum volumes were declining in comparison.

Solana crossing the trading volume of Bitcoin and Ethereum over a weekend signifies an intriguing shift in momentum. As the most valuable and established blockchain networks, Bitcoin and Ethereum have dominated trading volumes since the inception of crypto. Being surpassed by the upstart Solana merits deeper examination.

On one hand, the development is largely unsurprising given Solana's meteoric growth trajectory through 2022. The network has aggressively captured mindshare through sought-after capabilities like fast speeds and low costs. These attributes have resonated with builders and traders alike.

Many of us noted this milestone is "unprecedented" and indicates sustained interest and momentum for Solana in the market right now. Key factors driving Solana's growth include its high-profile partnerships with Visa, Shopify, etc over the past year to bring blockchain payments mainstream. Additionally, buoyant interest in Solana-based memecoin BONK and resurgent DeFi activity on Solana's smart contract platform are driving investor and trader interest.

That being said, sustainability remains an open-ended question despite the milestone. Crossing Bitcoin and Ethereum momentarily does not guarantee an enduring trend. For meaningful change, Solana must entrench itself within the mainstream steadily.

Network outages and reliability challenges have hampered adoption strides historically. Moreover, Bitcoin and Ethereum benefit from established network effects that have endured bear markets. Whether Solana's volumes versus the titans prove an ephemeral blip or watershed moment depends significantly on execution ahead.

Earlier last month, it was noted that Solana’s DEX volume broke the $9 billion mark, and it has gotten better every day since.  DEX trading volumes reflect growing adoption and trust in Solana's capabilities. Traders and investors are increasingly leveraging Solana-based DEXs.

The $9 billion figure exceeds previous DEX volume records on Solana. It caps a year of steady volume growth, showing the ecosystem's velocity.

The foremost factor is Solana unlocking throughput and scalability thresholds unseen before in the blockchain industry. Processing over $9 billion in DEX swaps requires handling immense transaction loads at speed and low cost. Achieving such figures showcases Solana’s real-world capacity as demand grows. And growth seems guaranteed given developer mindshare keeps rising despite industry malaise otherwise. That is because the network offers a genuinely differentiated infrastructure for builders in the space.

Open Question: Can network reliability and sustainability match late-2023 traction?

L2IV Thoughts

As we analyze the landscape, several macro factors signal an optimistic growth trajectory for digital assets in 2024.

• For starters, the approval of Bitcoin ETF has driven interest and frenzy in the market and we expect it to be bullish overall. With approvals expected for Ethereum spot ETFs, we can expect an immense wall of institutional capital into crypto and see inflows stretching into the hundreds of billions from pensions and asset managers allocating to this emerging asset class through accessible regulated wrappers.

• Additionally, Bitcoin's upcoming halving event has historically catalyzed multi-year bull runs by reducing selling pressure. This cyclical dynamic could fuel a prolonged price uptrend through 2025.

• And if inflation continues cooling, the Fed could very plausibly reverse course into rate cuts by the end of 2024. This would undeniably stimulate risk asset appetite across global markets.

The convergence of these macro drivers seems likely to recreate conditions that powered the 2021 Bitcoin bull run. This presents a hugely favorable landscape for institutions and retail alike.

Expanding horizons on the technology front reinforces this optimism. The analysis around ZK within blockchain and AI creates a paradigm shift that resonates with our thinking - decentralized data transmission promises to unlock new frontiers in machine learning, vastly expanding systemic trading design spaces.

Upgrades enabling low-latency trade execution across diversified venues also provide low-slippage access to capitalize on everything from spot to sophisticated derivatives plays. And with base layer scalability launch and functionality growth in Bitcoin and Ethereum, tactics can trade directly on-chain rather than proxies - capitalizing on basis and arb opportunities.

In summary, Positive macro forces alongside technological expansions have us bullish on crypto systematically extracting alpha from diverse sources through 2024 and beyond.

Conclusion

As we reflect on the trajectory of innovations traced across pivotal blockchain domains, several unifying themes emerge - painting a future grounded in decentralization yet scaled for global needs. The foundational trends analyzed around scalability, interoperability, functionality and adoption indicate that core tenets of permissionless and transparent participation remain firmly entrenched into the blockchain industry's DNA even as it permeates world infrastructure.

The advent of decentralized data/sequencing schemes powering modular rollup stacks bound by staked security represents a milestone where customizability need not compromise robust composability. The vital progress in formally analyzing security tradeoffs when bridging across chains further reifies cryptography's role as the immutable anchor upholding ecosystem honesty. Advances in areas as diverse as permanent records through Bitcoin's ordinal inscription to real-time swaps via customized DEX derivatives showcase technology maturing at every layer to meet specialized demands at scale. Meanwhile, the reassuring resurgence of pioneer networks like Solana dispels doubts over platform viability.

Granted uncertainties exist, particularly around managing disputes across interdependent security domains created by inter-blockchain connectivity models which span sequencing, verification and settlement finality in cross-chain contexts. As bridges, side-chains and ZK rollups permeate asset portability - enhanced interoperability frameworks will prove critical.

Nonetheless, the trends analyzed holistically underscore that iterative, guided growth remains both achievable and preferable to more centralized attempts at enforced adoption. In the process, the unique strengths across major network ecosystems seem likely to coalesce around specialization by use case while sharing essential base resources like liquidity, state storage and computing via interoperable cryptography and proof systems underpinning validity of computations across all domains.

As we wrap this up, we at L2IV, are actively investing and exploring deals in all the trends we have listed in. The list is not exhaustive. Reach out to us if you are building in any of the above verticals.

Find L2IV at l2iterative.com and on Twitter @l2iterative

Subscribe now

Author: Arhat Bhagwatkar, Research Analyst, L2IV (@0xArhat)

Disclaimer: This content is provided for informational purposes only and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisors as to those matters. References to any securities or digital assets are for illustrative purposes only and do not constitute an investment recommendation or offer to provide investment advisory services.

When people are doing optimization in RISC Zero, the most important lesson is to focus ONLY on the major bottleneck. To know where the bottleneck is, we profile the program by knowing how much “ZK-proving” overhead that each part of the program is contributing to. 

This article is dedicated to figuring out this proving overhead—through a combination of theory and experiments over RISC Zero.

Contributing factors of ZK proving overhead

Let us start with the theory. In RISC Zero, the amount of “ZK-proving” overhead is measured in terms of “cycles”. This is in essence similar to cycles of a CPU. Like a regular RISC-V CPU, the cycles in RISC Zero come from mainly two sources: compute and paging.

Compute. Every RISC-V instruction, when being executed, incurs some CPU compute cycles in RISC Zero, as shown below, based on the developer document. 

• one cycle: LUI, AUIPC, JAL, JALR, BEQ, BNE, BLT, BGE, BLTU, BGEU, LB, LH, LW, LBU, LHU, SB, SH, SW, ADDI, SLTI, SLTIU, SLLI, ADD, SUB, SLL, SLTU, MUL, MULH, MULHSU, MULHU

• two cycles: XORI, ORI, ANDI, SRLI, SRAI, XOR, SRL, SRA, OR, AND, DIV, DIVU, REM, REMU

• 76 cycles per 64 bytes: syscall for SHA-256

• 10 cycles: syscall for 256-bit modular multiplication

Most of the common instructions—such as those for adding and multiplying 32-bits numbers—incur one cycle. Some of the bitwise operations and division take two cycles. Syscalls, which invoke the cryptography accelerator, take more cycles. This is in essence similar to modern CPU’s SHA extension, which adds instructions dedicated for SHA256 that only take a few cycles to execute. 

It is necessary to note that RISC Zero’s cycle counts are specific to RISC Zero—a real-world RISC-V CPU chip is almost guaranteed to have a different cycle count, because computation cost is often higher than the verification cost. Future versions of RISC Zero may also have different cycle counts for each instruction.

However, an instruction may also incur non-compute cycles due to paging, which can also be a significant source of overhead.

Paging. To understand the overhead of paging in RISC Zero, it is useful to first remind ourselves about how modern CPU handles data access, depending on where the data is.

• in L1/L2 caches: the data access can be done within a few cycles. 

• in the main memory: the data access has a latency of hundreds of cycles. 

• in an external storage: the data needs to be first loaded into the main memory—called “paged-in”, during which the CPU has to wait and it can take more than tens of thousands of cycles even if the external storage is a high-end SSD. Data might also need to be “paged-out” from the main memory back to the external storage.

We call it “paged-in” and “paged-out” because modern operating systems organize the memory that a program can access into “pages”. Page sizes vary from platforms to platforms. In a Mac Studio with M2 chips, each page is 16KB. RISC-V standard uses 4KB. In RISC Zero, pages are smaller, and each page is of 1KB. 

In RISC Zero, the program can use up to ~192 MB of space addressed from 0x0400 to 0x0c000000. This space is split into pages each of 1KB. These pages are indexed by a number of page tables, which takes a space of about 6.7MB at the space starting at 0x0d000000. Similar to modern operating systems, page tables are multi-level, as illustrated in Figure 1. 

Figure 1: Multi-level page tables for the memory space in a guest program in RISC Zero.

In an RISC Zero program, when a page is being accessed for the first time, RISC Zero needs to “zk-load” this page so that its data is put into an authenticated format that the ZK circuit can use. At the end of the execution, RISC Zero will “zk-unload” the page, which verifies if the page has been modified in a way that is consistent with the ZK circuit execution.

Note that to load or unload a page, RISC Zero needs to load or unload its page table. In other words, the first instruction of the entire program will load 5 pages:

• Page A: The page where the instruction is located.

• Page B: The 4-th level page table for A.

• Page C: The 3-rd level page table for B.

• Page D: The 2-nd level page table for C. 

• Page E: The top-level page table.

Each page load/unload contributes about 1094 cycles, except for the top-level page table which takes 754 cycles, a little bit less. This can be visualized through a tool—which we will present soon—that allows us to see how the number of pages loaded or unloaded is changed throughout the execution. 

Figure 2: Example output from GDB for RISC Zero that illustrates the cycles.

For an RISC-V program running in RISC Zero, the amount of page cycles therefore depends on how many memory pages are accessed or modified throughout the execution—people also call that “memory footprint”. One can see that there is some necessity, in terms of optimization, to avoid using too much memory at a specific time. To put it differently, there is a preference to lower the peak memory in RISC Zero. 

Now that we have talked about the cycles, we want to explain why cycles are directly related to the ZK proving overhead. This has something to do with how RISC Zero performs the zero-knowledge proofs. There is not much documentation about the ZK circuit of RISC Zero, but the code is open-source. For us to understand the ZK proving overhead, let us first understand RISC Zero’s ZK.

From cycles to ZK proof

To put it simply, the proof system of RISC Zero can be summarized as follows.

• UltraPlonk (or Halo2). The arithmetization consists of customized gates, high-degree polynomial relations, many witness wires, and lookup arguments.

• FRI. Polynomial evaluation and commitment is done using fast Reed-Solomon interactive proof of proximity (just call it FRI). 

• BabyBear. The computation is defined over the BabyBear field (modulus 15 * 2^27 + 1) and a degree-four extension is used during the algebraic holographic proving. Each BabyBear element stores one byte of the data. In other words, a 32-bit integer uses four BabyBear elements. 

• Memory checking. Although pages are authenticated using the Merkle tree, the main memory uses an algebraic memory checking technique so that each access to the main memory always incurs only a constant overhead. 

• SHARK from Groth16. Proof generation results in STARK proofs that can be further compressed—without revealing information and in a trustless way—into very succinct SNARK proofs through Groth16. We expect RISC Zero to conduct their setup ceremony for the SNARK circuit over Privacy Scaling Exploration (PSE)’s public ceremony platform, P0tion.

The full circuit of the RISC Zero is available, but the compiler that converts the high-level description into the circuit, called Zirgen, is not released yet. Nevertheless, a few videos from Nethermind and RISC Zero should be able to give you a high-level idea of how the circuit comes from, and why a compiler is needed for efficiency, hardware agnostic, and formal verification. 

Note that the summary above about the RISC Zero proof system is just for today. It can be very different in the future. With the development of recursion (previously called “continuation”, but it is more generic now) in RISC Zero, RISC Zero likely will become some sort of “Plonk”, in that people can customize their own application-specific variants of RISC Zero that are tailored for different applications. 

One can imagine a future where RISC Zero becomes the hub of different ZK protocols, like Minecraft that has a very large modding/plugins ecosystem with 150k+ community projects. Here, RISC Zero provides general-purpose support and common features—in terms of RISC-V and SHA256/BigInt syscalls—as well as the infrastructure for circuit generation (Zirgen), remote proof delegation and compression (Bonsai), and also efficient implementation for different backends, including CPU, Metal, and CUDA, derived by Zirgen. Executable files from other target platforms—such as WASM—can be converted into RISC-V without much of the VM overhead through just-in-time compilation (JIT), which is similar to Solana’s JIT for VM—rbpf. 

Figure 3: A potential future with proof systems built based on RISC Zero.

Previously, the two biggest challenges for people to “Rolling Your Own Crypto” are (1) technical and knowledge barriers to create the proof system (2) insufficient confidence in the security. Fortunately, Zirgen helps with the first, and Nethermind has discussed how it facilitates formal verification. A generation of application-specific, formally verified, community-built proof systems that laypersons can create—probably with the help of GPT—is not far away, and this can be the true decentralization of ZK proof systems, and it removes the “elitism” risk of ZK.

In RISC Zero, there are about six ZK circuits that encode the constraints of RISC-V program execution, each of a different size, as follows.

• A circuit that verifies up to 32768 (=2^15) cycles of execution

• A circuit that verifies up to 65536 (=2^16) cycles of execution

• A circuit that verifies up to 131072 (=2^17) cycles of execution

• A circuit that verifies up to 262144 (=2^18) cycles of execution

• A circuit that verifies up to 524288 (=2^19) cycles of execution

• A circuit that verifies up to 1048576 (=2^20) cycles of execution

To select a circuit for a specific RISC-V program, RISC Zero first runs the program and finds out how many cycles it takes to finish. Then, the smallest circuit that can handle that cycle count is selected. If the execution takes more than 2^20 cycles, the entire execution would be split into segments, each of up to 2^20 cycles, and the segment proofs are merged together through proof recursion.

All these circuits follow a pretty simple structure. 

• Pre-loading sub-circuit: verify the initialization of the execution environment—the initialization of the lookup tables for byte formality checking and RAM, the initial data load to the RAM, and, lastly and importantly, disabling the pre-loading privileges. This is similar to “real mode” in x86-64, where the booter runs in a privileged mode and later switches to “protected mode” for the actual OS, with the privileges taken away. This sub-circuit occupies the space equivalent to N_{pre} = ~1592 cycles in the circuit.

• Boby sub-circuit: verify that, for the subsequent ~ 2^k - N_{pre} - N_{post} cycles, each cycle conforms to the behaviors of an RISC-V CPU. This is a highly repeated circuit, as each of the cycles here is equivalent to each other. Note that page loading and unloading are all done in the body. This is similar to the operating system taking care of the virtual memory and page management. 

• Post-loading sub-circuit: verify that the computation has been closed up properly, and close up the lookup tables for byte formality checking and RAM. This sub-circuit is placed exactly at the end of the circuit, and it takes space equivalent to N_{post} = ~6 cycles in the circuit. One can imagine this to be the machine powering-off itself.

In the RISC Zero GitHub repo, one can find the definitions of the body sub-circuit here.

Figure 4: The construction of the constraint system of the body phase of the zkVM.

And as one can see, the body sub-circuit is pretty simple, in that it just repeatedly writes “1” into the body wire of the underlying ZK circuit, until it is time to do post-loading. 

Like other FRI proof systems, since FRI does not care about whether the circuit is sparse or dense, the proving generation overhead is entirely dependent on the size of the circuit, or more specifically, which one out of the six circuits above is being used. 

Cycles are, in other words, the only thing that matters.

Note that recently, there has been discussion on proof systems that can leverage sparsity, such as Lasso + Jolt from a16zcrypto—which relies on committing structured multilinear extensions over homomorphic commitments—-and Binius from Ulvetanna—which is a binary proof system with hardware-friendly encoding. Both are relevant to RISC Zero. I personally consider Lasso + Jolt and Binius to be two separate cherry trees that contain very different, complementary techniques, and future versions of RISC Zero, or its community variants, can cherry-pick.

Since cycles are all we need to consider, we now turn our attention to tools that can help us study the cycles of a particular program.

A profiler that dives deep about cycles

As part of our research work, we built a profiler for RISC Zero, which we call profiler0.

https://github.com/l2iterative/profiler0

Remember that—to optimize the code, the first thing is to identify the major bottlenecks. The profiler0 tool enables us to add some timers into our code, as shown by “start_timer!”, “stop_start_timer!”, and “stop_timer!”, that verifies FHE in RISC Zero, as follows.

start_timer!("Total");

start_timer!("Load the bootstrapping key");

let bsk = black_box(unsafe {
    std::mem::transmute::<&u8, &[GgswCiphertext; 16]>(&BSK_BYTES[0])
});

stop_start_timer!("Load the ciphertext to be bootstrapped");

let c = black_box(unsafe {
    std::mem::transmute::<&u8, &LweCiphertext>(&C_BYTES[0])
});

stop_start_timer!("Perform trivial encryption and rotation");

let lut = black_box(GlweCiphertext::trivial_encrypt_lut_poly());
let mut c_prime = lut.clone();
c_prime.rotate_trivial((2 * N as u64) - c.body);

stop_start_timer!("Perform one step of the bootstrapping");

// set to one step
for i in 0..1 {
    start_timer!("Rotate");
    let rotated = c_prime.rotate(c.mask[i]);

    stop_start_timer!("Cmux");
    c_prime = cmux(&bsk[i], &c_prime, &rotated);

    stop_timer!();
}

stop_timer!();
stop_timer!();

This allows us to see how different parts of the code contribute to the number of cycles. The profiler follows the execution of the guest program and does statistics on the cycles. The result can be found here.

The result from the profiler can be summarized as follows.

• Load the bootstrapping key: 15 instructions, 3,297 cycles

• Load the ciphertext to be bootstrapped: 11 instructions, 11 cycles

• Perform trivial encryption and rotation: 66,096 instructions, 123,982 cycles

• Perform one out of the 1024 steps of bootstrapping: 151,619,979 instructions, 159,597,740 cycles

  • Rotate: 55,930 instructions, 75,670 cycles

  • Cmux: 151,564,031 instructions, 159,520,958 cycles

The total is 151,686,471 instructions and 159,726,565 cycles.

We can immediately draw some conclusions about where the cost comes from—cmux, as it accounts for 99% of the instructions and 99% of the cycles. Note that this is only a single step in the entire bootstrapping process. The entire TFHE bootstrapping example has 1024 such steps.

The natural next step of profiling is to go into the `cmux` function and have a breakdown. We add the following profiling codes into the TFHE library that we are using.

pub fn cmux(ctb: &GgswCiphertext, ct1: &GlweCiphertext, ct2: &GlweCiphertext) -> GlweCiphertext {
    start_timer!("subtract the ciphertext");
    let mut res = ct2.sub(ct1);
    stop_start_timer!("external product");
    res = ctb.external_product(&res);
    stop_start_timer!("add the result");
    res = res.add(ct1);
    stop_timer!();
    res
}

And we also put in the profiling codes to the external_product function, which would be central to the performance. Note that the profiler accepts static messages as well as messages that are dynamically generated in the runtime.

impl GgswCiphertext {
    /// Performs a product (GGSW x GLWE) -> GLWE.
    pub fn external_product(&self, ct: &GlweCiphertext) -> GlweCiphertext {
        start_timer!("apply g inverse");
        let g_inverse_ct = apply_g_inverse(ct);
        stop_start_timer!("multiply");

        let mut res = GlweCiphertext::default();
        for i in 0..(k + 1) * ELL {
            start_timer!(format!("i = {}", i));
            for j in 0..k {
                res.mask[j].add_assign(&g_inverse_ct[i].mul(&self.z_m_gt[i].mask[j]));
            }
            res.body
                .add_assign(&g_inverse_ct[i].mul(&self.z_m_gt[i].body));
            stop_timer!();
        }
        stop_timer!();
        res
    }
}

This allows us to have a more detailed breakdown of the instructions from `cmux`, as shown below. Note that the profiler injects a few instructions, and so `cmux` cycle counts increase slightly.

• Subtract the ciphertext: 38,495 instructions, 46,163 cycles

• Apply G inverse: 79,991 instructions, 167,498 cycles

• Multiply with i = 0: 37,840,587 instructions, 39,875,485 cycles

• Multiply with i = 1: 37,840,584 instructions, 39,759,520 cycles

• Multiply with i = 2: 37,840,584 instructions, 39,802,186 cycles

• Add the result: 50,816 instructions, 70,525 cycles

The total is 151,565,973 instructions and 159,619,414 cycles.

The profiler also gives us the locations of the instructions that trigger a lot of cycles. One can find the same from the new output from the profiler here. Interestingly, a few locations appear extremely frequently, suggesting that it is in a loop.

0x200d18, 0x200d20, 0x200d74, 0x200d78, 0x200d7c

These addresses are close to each other, suggesting that they are likely the assembly code from a single function, and this function is being called repeatedly in a way that it contributes to the majority of the cycles. Although the profiler does show what that instruction is, for example, the 0x200d74 that pops up extremely frequently is “lw s10, t5, 0”, but to understand what an instruction is doing, we need context.

What is the best way to have context? There is a clear answer— “go back to the scene”.

Use GDB for dynamic code analysis

We need a tool that allows us to come back to the scene and see what is happening with the code. As part of our research work, we built a GDB stub for the RISC Zero guest program. The GDB stub is like the “glue code” that enables GDB to work with RISC Zero. 

We call this GDB stub “gdb0”. 

https://github.com/l2iterative/gdb0

To get started, we first compile the program with debug information. This is done by the following steps.

First, in the “guest” directory’s Cargo.toml, add the following so that even if we compile the program in the debug mode, it would still apply the necessary optimization (without which Rust programs would be unreasonably slow).

[profile.dev] 
opt-level = 3 

[profile.dev.build-override] 
opt-level = 3

Then, we compile the guest with an environment variable that turns on the RISC Zero debug mode. 

RISC0_BUILD_DEBUG=1 cargo run

Then, we copy-paste the compiled guest program, which is a standard ELF file for RISC-V code, into the gdb0 directory. The bash command to do this may differ in your local environment, but in our setup, we just do the following in the gdb0 directory. Be sure to copy the compiled program in the “debug” directory, not the “release” directory.

cp ../vfhe0/target/riscv-guest/riscv32im-risc0-zkvm-elf/debug/method code

We should run the profiler again because the function may be in different locations. The new result from the profiler is attached here. We can see that addresses 0x200db0, 0x200db4, 0x200db8, 0x200dbc are instructions that often cause significant cycles (due to read/write). 

We now start the GDB. To find more detail about how to get the GDB running, please refer to the GitHub repo above. We set a software breakpoint at 0x200db0 based on the profiler’s output above. Then, we ask GDB to continue the execution, ending up on the following screen.

Figure 5: Arriving at the loop that contributes to a lot of overhead.

This allows us to visualize why 0x200db0 is frequently being invoked and where it belongs. This is in the inner loop of the polynomial multiplication function. Note that when we set the breakpoint, GDB already tries to tell us that it corresponds to Line 42 of the “src/ttfhe/poly.rs” file.

We can see how the Rust source code translates to the RISC-V instructions. For example, this inner loop, which performs 64-bit integer multiplication, looks like this. Here, “bne” often refers to the end of the loop.

Figure 6: The inner loop that performs 64-bit integer multiplication and accumulation.

RISC Zero is using 32-bit RISC-V, and we can see that the 64-bit integer multiplication is being simulated by 32-bit integer operations, such as mul, mulhu, and add. This is done by Rust during compilation, and one can experiment with this and check the consistency in Godbolt.

Now that we can see through all the information about the execution of our program, and we have all the necessary tools for us to return to the scene, it is time to create an attack plan.

Diagnose our code

As we are coming to the end of our article, we want to talk about what we want to do in order to optimize the performance. This would also be the topic in subsequent articles in this series.

First, as the VFHE library disclaims, the current algorithm that performs negacyclic convolution is a very naive algorithm that runs in time O(n^2). In other words, when we do this on two vectors of size 1024, the code will need to perform 1048576 64-bit integer multiplication, as well as the cost to load/save data in the middle.

We know other algorithms. First of all, we rule out NTT because, since the modulus is 2^64 and we do not want to change it (in order to be compatible with Zama), there is not much hope for integer NTT. We could, however, like Zama, use floating point NTT over the complex numbers. The reason why Zama takes such a heavy-looking approach—using floating points—is simple: floating points are not expensive at all on modern CPUs, as it only takes a few cycles like integer multiplication, much cheaper than integer division. 

This, however, is not the case for RISC-V or RISC Zero. The official document mentions that “floating point operations can take 60-140 cycles for basic operations such as add, subtract, multiply, and divide.” In RISC Zero, floating point operations are much more expensive. Based on our conversation with Rand Hindi from Zama, we conclude that a complex number NTT with floating point is likely not the solution for ZK.

The remaining option is non-NTT efficient polynomial multiplication (or, more specifically and precisely, negacyclic convolution). We plan to use the Karatsuba algorithm, which uses a divide-and-conquer manner to perform the computation, resulting in a subquadratic overhead. 

This should already bring two orders of magnitude speedup. 

Another opportunity of optimization is to find application-specific optimization opportunities. In TFHE, when we do the bootstrapping, we are multiplying a GGSW ciphertext to a GLWE ciphertext, and a very interesting thing about this multiplication is that GLWE would be decomposed into a format in which all the numbers are small (that is, applying the inverse G transform).

This means that we do not actually have to do 64-bit integer computation. The output of the inverse G transform, in our configuration, is only 8-bit. Karatsuba algorithm may add numbers here and there, so 16-bit representation should be comfortable as long as Karatsuba’s depth is not too large, to accommodate the intermediate results due to Karatsuba. In a 32-bit number, we can encode two of such numbers, which would save the memory space and load/save, and we can decode it on demand. 

Lastly, let us go back to the inner loop and its assembly code.

Figure 6: The inner loop that performs 64-bit integer multiplication and accumulation.

The inner loop has about 20 instructions in each iteration. We can imagine that if we use the compressed representation discussed above, we can save a few instructions. Then, let us observe the rest of the instructions. There are a few quick observations.

• 0x200da4 - 0x200dac is a sanity check that detects if the code is accessing a location beyond the slice’s boundary. This is a Rust thing for safety. But, here, we may want to remove it. 

• 0x200db4 - 0x200dc4, t4 is used to store the address of the rhs.coefs[N - j + i]. It seems very possible to simplify the computation rather than, for example, using “slli” to left-shift the value by 3 bits in order to multiply it by 8. We can have two pointers that move as the iteration progresses, one adding 8, one subtracting 8. This can be implemented around the code in 0x200df0 - 0x200df4.

• If we use the compressed representation discussed above, it helps to do two steps in one iteration. 

On average, each of the multiplications appears to contribute 36 cycles (=37840587 / 1024 / 1024). We shall be able to reduce this number through such optimization, and since Karatsuba can reduce the number of multiplications, we can reduce the total multiplication overhead.

An interesting idea is to see if we can use the RISC Zero bigint syscall to simulate three 16-bit times 64-bit computation, but it is uncertain if it would be more efficient because there would be overhead to pack and unpack.

Lastly, if we want to build the entire proof (for 1024 steps) within a reasonable amount of time, we need to have some acceleration: hardware acceleration and software acceleration. We will experiment with RISC Zero’s Metal GPU optimization, which appears to be very powerful, and we will look at RISC Zero’s continuation and how we can generate the proof for the entire computation in parallel, so that we can scale linearly to reduce the latency. 

We are also particularly interested in RISC Zero’s Zirgen tool, which may open up the possibility of customized proof systems that add a vectorized instruction specifically to help with negacyclic convolution. Another thing to look into is a probabilistic checking protocol from Jeremy Bruestle, discussed in RISC Zero Discord, which gives O(n) complexity, but the detail still needs to be worked out. 

Long story short, see you in the next article in the RISC Zero series for verifying FHE. 

Find L2IV at l2iterative.com and on Twitter @l2iterative

Author: Weikeng Chen, Research Partner, L2IV (@weikengchen)

Disclaimer: This content is provided for informational purposes only and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisors as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services.

• Off-chain computation for fhEVM: Fhenix and Inco are working on L1 chains that augment EVM with fully homomorphic encryption based on Zama’s fhEVM, where fhEVM stands for fully homomorphic Ethereum Virtual Machine (EVM). Off-chain computation can save validators from the need to rerun FHE computation (scalability) and may be able to further hide the functions (privacy).

• FHE mining: Inspired by Aleo’s proof of succinct work (PoSW) and the ZPrize initiatives, we consider FHE mining to be a notable future direction to encourage ASIC manufacture for FHE and incentivize FHE miners to become validators for fhEVM networks. The core task of FHE mining is to develop a ZKP system for PoSW in FHE contexts.

Among the different FHE schemes, we are particularly interested in TFHE that Zama used. This implementation of TFHE uses a modulus p = 2^64, selected for its computational efficiency on modern CPUs and other hardware platforms. Our interest in verifying FHE in this setting stems from its immediate applicability in fhEVM. 

However, employing a modulus of p = 2^64 presents significant challenges for ZKPs, as there are limited zero-knowledge proof systems effectively compatible with this modulus.

• Most zero-knowledge proof systems are designed to operate within a field, but modulus p = 2^64 does not form a field, as exemplified by the lack of a modular inverse for 2, making it merely a ring. We have a zero-knowledge proof system called Rinocchio that is designed for rings, but it does not work here because it only supports (1) arbitrary rings if the ZKP is designated-verifier, which is not suitable for blockchain applications and (2) rings associated with secure, composite-order pairing-friendly curves, which would not be compatible with p = 2^64. 

• Alternatively, using a suitable field to simulate 64-bit integer computations is an option, though it comes with its own set of costs. There are only a few VMs that have been designed with 64-bit integers, including RISC Zero and Aleo’s Leo. It's also feasible to simulate 64-bit integer computations from 32-bit ones, thereby broadening VM support options to include platforms like Polygon Miden (see this Miden assembly file for example) and Valida. 

We pick RISC Zero for three reasons. 

• The toolchain and the development ecosystem are notably stable and mature.

• The performance of proof generation on RISC Zero, especially when utilizing Apple M2 chips, as we do at L2IV, is impressively decent.

• We happen to have a highly coveted and limited Bonsai API key that allows us to offload the proof generation process to RISC Zero’s dedicated Bonsai servers, thereby alleviating the need for local proof generation.

Figure 1: RISC Zero’s Bonsai delegated proof generation services.

This article, Part I, will document our journey towards achieving a functional yet unoptimized prototype. In the subsequent articles, we will delve into our efforts to optimize the implementation. Additionally, we will explore various future directions inspired by our insightful conversations with RISC Zero developers.

What is TFHE?

To understand TFHE, it's essential to first grasp the concept of fully homomorphic encryption (FHE). At its core, FHE is an encryption algorithm, denoted as E, designed for data encryption. For example, given a plaintext a, encryption gives us the ciphertext E(a).

The full homomorphism means that we can compute over the ciphertexts, including additions, subtractions, and multiplications.

When the plaintexts are binary bits (0 and 1), it becomes possible to represent all binary logic gates using FHE. This includes fundamental gates like XOR and AND, as they form the basis of any binary logic operations in FHE.

Given its capability to represent all binary gates, FHE is thus able to perform arbitrary computations within a bounded size. In blockchain applications, FHE is garnering significant interest for enabling privacy in decentralized finance (DeFi) applications. For instance, in privacy-enhanced decentralized exchanges (DEXs), FHE can confidentially handle computations for automated market makers (AMMs).

A major portion of the computational overhead in FHE is attributed to managing and mitigating 'noise'. All existing FHE constructions rely on the learning-with-error (LWE) assumption or its variants, which form the foundational basis of these cryptographic systems. And for each step of the computation, the output—such as E(a + b - a × b)—will have more noise than the inputs E(a) and E(b), and this output may become the input for subsequent steps. As computations progress, the ciphertexts accumulate increasingly larger amounts of noise. As depicted in Figure 2, once the noise in a ciphertext reaches a certain threshold, it renders the ciphertext undecryptable.

Figure 2: An illustration of the noise in FHE, extracted from a paper of Marc Joye (Zama).

To facilitate unbounded computation in FHE, it's essential to find a method for clearing the noise before it becomes excessively large. This technique, known as 'bootstrapping', was first introduced by Craig Gentry in 2009 through his groundbreaking paper on FHE. Bootstrapping involves using an encrypted version of the FHE secret key, often referred to as the 'bootstrapping key', to decrypt and thereby refresh a noisy ciphertext, which results in a new ciphertext that contains the same data, but with less noise. 

One can imagine FHE computation to be a very exhausting exercise—like a marathon—for the ciphertext, and the ciphertext needs to take breaks in order to avoid “burnout”, as we illustrate in Figure 3.

Figure 3: Think of FHE bootstrapping as a person needing to take a break in order to avoid burnout in a marathon (illustration by Midjourney).

Among different fully homomorphic encryption (FHE) algorithms, TFHE has garnered significant attention because bootstrapping in TFHE is efficient, and TFHE is very suitable for evaluating Boolean circuits over encrypted data. Zama, Fhenix, Inco are all using TFHE.

Therefore, a principal challenge in verifying FHE lies in accurately validating the bootstrapping process. In TFHE, bootstrapping involves using a bootstrapping key to 'blindly rotate' a polynomial in line with the ciphertext being bootstrapped, subsequently extracting a refreshed ciphertext from this rotated polynomial.

While this might initially seem like a foray into advanced cryptography, it's reassuring to note that the process predominantly revolves around manipulating polynomials and matrices, as shown by Figure 4, which is extracted from Marc Joye’s primer on TFHE. For those keen on delving deeper, we highly recommend this primer by Marc Joye on TFHE, which is approachable for those with just a basic understanding of linear algebra.

Figure 4: A summary of the bootstrapping algorithm in TFHE from Marc Joye’s primer.

Now that we have some basic background about FHE, let’s explore how RISC Zero can be useful here.

What is RISC Zero?

RISC Zero is a versatile zero-knowledge proof system specifically designed for RISC-V architecture. In other words, any program that can be compiled into an ELF (executable and linkable format) program over riscv32im (RISC-V 32 bit with the “M” extension for integer multiplication and division) is compatible with RISC Zero. Upon execution by the VM, RISC Zero generates a zero-knowledge proof of this execution, termed as a 'receipt'. Figure 5 illustrates this process.

Figure 5: The workflow of RISC Zero.

A frequently asked question about RISC Zero is its preference for RISC-V over other instruction sets. We find two key reasons.

First, RISC-V has a simple but universal instruction set. RISC Zero only needs to support the following 46 instructions from riscv32im.

LB, LH, LW, LBU, LHU, ADDI, SLLI, SLTI, SLTIU, XORI, SRLI, SRAI, ORI, ANDI, AUIPC, SB, SH, AW, ADD, SUB, SLL, SLT, SLTU, XOR, SRL, SRA, OR, AND, MUL, MULH, MULSU, MULU, DIV, DIVU, REM, REMU, LUI, BEQ, BNE, BLT, BGE, BGEU, JALR, JAL, ECALL, EBREAK

This is much simpler from modern Intel x86—which has 1131 instructions, and modern ARM can be up to hundreds of instructions. RISC-V is also not too different from other minimalistic instruction sets—MIPS (the company of MIPS later transitioned into working on RISC-V), WASM, and very early generations of ARM such as ARMv4T.

Second, it is easy to compile various languages to RISC-V, thanks to LLVM. LLVM is a compilation toolchain that implements an intermediary layer (called “intermediate representation”) between the backends (“ISAs”) and the frontends (“programming languages”). Since RISC-V is one of the supported backends, LLVM allows the many frontends—including C, C++, Haskell, Ruby, Rust, Swift, and so on to be compiled into RISC-V. 

Figure 6: LLVM’s three-phase design (illustration from Chris Lattner’s book), where RISC-V is also an available LLVM backend.

In other words, through a bottom-up approach, RISC Zero is able to support programs that are written using existing, Web2 programming languages. One can also build their own ZKP domain-specific language (DSL)—which can include ZoKrates, Cairo, Noir, and Circom—and create a compiler that converts them into RISC-V. For languages where direct compilation to RISC-V is challenging, an alternative approach is to first compile the DSL into an intermediate language like C/C++, and then use an existing LLVM compiler for the final conversion to RISC-V.

Another question people would ask is, why, despite RISC-V being a favorable choice, we initiate with a virtual machine? Can’t we just write the “constraint system” in an existing ZK-specific DSL, such as ZoKrates, Cairo, Noir, and Circom?

There are two reasons.

Firstly, using RISC Zero significantly reduces development time. Traditionally, crafting the constraint system for ZKPs was a laborious task that can only be done by skillful developers, and it can take weeks. What’s worse is that debugging the constraint system can take even longer, and it is hard to make sure that the constraint system is bug-free. This has been one of the factors that limit the development and adoption of zero-knowledge proofs—because it is hard to build applications. 

It can be once an ambitious startup project to build historical proofs that verify the history of Bitcoin or Ethereum, or prove the output of an AI game bot in zero knowledge. Now, with RISC Zero, what was once an ambitious endeavor becomes feasible even as a hackathon project. For instance, verifying Zama’s FHE—an application that is very complicated and no one has ever written the ZKP constraint system for it before—can be done in RISC Zero with a few lines of the code. 

This shift also simplifies the process of recruiting developers. A person who has previous experience in Rust can easily migrate an existing piece of Rust code into RISC Zero, and this person does not even need a lot of Rust knowledge.

Secondly, RISC Zero may even surpass human performance in certain aspects. The key strength of RISC Zero lies in that it has been specifically optimized to do 32-bit and 64-bit integer computation as well as manage a large storage and memory, and even a skillful ZKP engineer cannot beat it. 

Before RISC Zero, performing such optimization required top-notch ZKP researchers and engineers, as such techniques are extremely recent and were never documented. The optimization requires at least months to develop, as it requires probably the most creative usage of the lookup arguments.

RISC Zero has encapsulated these cutting-edge technologies into its Bonsai framework, making them both accessible and affordable. If cryptography is like cooking, then RISC Zero is a microwave oven.

Returning to our initial discussion, let's explore how RISC Zero can be utilized to verify Zama’s FHE computation in zero knowledge. It appears that all it takes from us is reusing some code from Zama’s team and then adding a few lines of code.

The code

In this first part of our series, we demonstrate how to verify the main step of bootstrapping an FHE ciphertext: using a bootstrapping key to perform a “blind rotation” of a polynomial, as follows.

#![no_main]
risc0_zkvm::guest::entry!(main);

// load the toy FHE Rust library from Louis Tremblay Thibault (Zama)
use ttfhe::{N,
   ggsw::{cmux, GgswCiphertext},
   glwe::GlweCiphertext,
   lwe::LweCiphertext
};

// load the bootstrapping key and the ciphertext to be bootstrapped
static BSK_BYTES: &[u8] = include_bytes_aligned!(8, "../../../bsk");
static C_BYTES: &[u8] = include_bytes_aligned!(8, "../../../c");

pub fn main() {
   // a zero-copy trick to load the key and the ciphertext into RISC Zero
   let bsk = unsafe {
       std::mem::transmute::<&u8, &[GgswCiphertext; N]>(&BSK_BYTES[0])
   };
   let c = unsafe {
       std::mem::transmute::<&u8, &LweCiphertext>(&C_BYTES[0])
   };

   // initialize the polynomial to be blindly rotated
 let mut c_prime = GlweCiphertext::trivial_encrypt_lut_poly();   
  c_prime.rotate_trivial((2 * N as u64) - c.body);

   // perform the blind rotation
   for i in 0..N {
       c_prime = cmux(&bsk[i], &c_prime, &c_prime.rotate(c.mask[i]));
   }

   eprintln!("test res: {}", c_prime.body.coefs[0]);
}

Excluding the lines of code for trivial operations such as loading dependencies or constant data, the actual number of lines of code is just 5—encompassing the initialization of the polynomial and blindly rotating it. 

let mut c_prime = GlweCiphertext::trivial_encrypt_lut_poly();   
c_prime.rotate_trivial((2 * N as u64) - c.body);

for i in 0..N {
    c_prime = cmux(&bsk[i], &c_prime, &c_prime.rotate(c.mask[i]));
}

The key functions and algorithms executing the FHE steps, including `trivial_encrypt_lut_poly`, `rotate_trivial`, and `cmux`, come directly from the toy FHE Rust library (ttfhe), developed by Louis Tremblay Thibault at Zama.

Utilizing RISC Zero, we're able to generate a proof for the execution of this RISC-V program. The code below from RISC Zero executes the RISC-V program (an executable file in the ELF format) and generates a proof (called “receipt”) that certifies the execution. Let's examine the code snippet to understand how it accomplishes these tasks:

let env = ExecutorEnv::builder().build().unwrap();
let prover = default_prover();

let receipt = prover.prove_elf(env, METHOD_NAME_ELF).unwrap();
receipt.verify(METHOD_NAME_ID).unwrap();

The receipt can be transmitted to a third party who can then verify the execution of the RISC-V program without gaining access to its detailed workings. For situations requiring more compact proof formats, RISC Zero also has the capability to generate a succinct proof, which retains its verifiability while being more concise.

Starting point: VFHE from Louis Tremblay Thibault

Our starting point is the toy FHE Rust library (https://github.com/tremblaythibaultl/ttfhe/) by Louis Tremblay Thibault, who is a research engineer in Zama. This library is pretty suitable for two reasons.

• It is very close to Zama’s library that has been used in fhEVM in production. 

• It is written in Rust, which facilitates straightforward compilation to RISC-V.

Figure 7: Louis’s toy FHE Rust library.

The toy FHE Rust library is minimalistic—it only has 6 files and contains 800 lines of code—but it has full-fledged support for three different types of FHE ciphertexts that we will use.

• LWE ciphertexts (lwe.rs), the structure of which here is a vector of 1024 64-bit integers.

• General LWE (GLWE) ciphertexts (glwe.rs), the structure of which here is also a vector of 1024 64-bit integers.

• General Gentry–Sahai–Waters (GGSW) ciphertexts (ggsw.rs), the structure of which here is a matrix of 64-bit integers of size 4 x 1024.

This suffices for initiating our development with RISC Zero, as our primary requirement is an efficient Rust implementation that seamlessly compiles down to RISC-V. has developed a preliminary version of these concepts in the VFHE library (https://github.com/tremblaythibaultl/vfhe), serving as our foundational starting point.

#![no_main]
use risc0_zkvm::guest::env;
use ttfhe::{ggsw::BootstrappingKey, glwe::GlweCiphertext, lwe::LweCiphertext};
risc0_zkvm::guest::entry!(main);

pub fn main() {
    // bincode can serialize `bsk` into an blob that weighs 39.9MB on disk.
    // This `env::read()` call doesn't seem to stop - memory is allocated until the process goes OOM.
    let (c, bsk): (LweCiphertext, BootstrappingKey) = env::read();

    let lut = GlweCiphertext::trivial_encrypt_lut_poly();

    // `blind_rotate` is a quite heavy computation that takes ~2s to perform on a M2 MBP.
    // Maybe this is why the process is running OOM?
    let blind_rotated_lut = lut.blind_rotate(c, &bsk);

    let res_ct = blind_rotated_lut.sample_extract();

    env::commit(&res_ct);
}

However, this represents merely a starting point, as there are two significant issues highlighted by comments within the code.

The first issue pertains to data loading. We face a yet unresolved challenge in efficiently loading the bootstrapping key and the ciphertext—which can be of a significant size—into the RISC-V program. 

Louis’s approach is to use RISC Zero’s `env::read` channel, which is a standard approach for  feeding data externally into the RISC-V machine during proof generation. However, as Louis noted, this method is not optimal, primarily due to its significant memory requirements and the extensive VM CPU cycles needed just for data loading, leading to out-of-memory (OOM) issues. Parker Thompson at RISC Zero acknowledged that this could likely be the source of the issue: “Generally reading large chunks of data into the guest is pretty costly.” (Here, the guest refers to the RISC-V program for which a proof would be generated.)

As a preliminary solution to circumvent this data loading overhead, we propose embedding the data directly within the RISC-V program. In Rust, a typical solution involves the `include_bytes_aligned!` macro, instructing the compiler to integrate the data into the RISC-V executable. Subsequently, we can deserialize this data from the bytes, for instance, using `bincode::deserialize`. The code looks like the following.

static BSK_BYTES: &[u8] = include_bytes_aligned!(8, ("../../../bsk");

let bsk: BootstrappingKey = bincode::deserialize(BSK_BYTES);

However, a significant challenge arises from the extensive cycles required by the RISC-V program to allocate memory and copy data for the entire 64MB bootstrapping key. Our benchmark shows that it would take at least 2 hours just to prove the correct loading of the key. 

In this article, we unveil a 'zero-copy' trick within RISC Zero that addresses this issue. It allows us to materialize the bootstrapping key incurring almost zero CPU cycles. We'll delve into the details of this technique shortly in this article.

The second major issue concerns computation. As Louis commented on the code, the efficiency of blind rotation (which is the main step of bootstrapping) can be a problem because it is not a lightweight computation itself (“takes 2s to perform on a M2 MBP”). This is the larger challenge of the entire “verifying FHE in RISC Zero”. 

We have designed and implemented a number of tricks and techniques in RISC Zero to optimize this part. This journey into optimizing FHE computation in RISC Zero is extensive, and we plan to dedicate several articles in this series to thoroughly explain each trick and technique. Stay tuned for the forthcoming articles in this series! To ensure you don’t miss out, consider subscribing to our Substack.

Subscribe now

A zero-copy trick to load a large amount of data

In this section, we delve into our approach to overcoming the data loading challenge in the RISC-V program, emphasizing methods that significantly reduce RISC-V CPU cycles.

The core idea is to avoid copying data in the RISC-V. This is crucial because copying a 64MB data set in RISC-V would necessitate upwards of 50 million instructions—one instruction to read data, one instruction to write data, and one instruction to update the pointer. All of these instructions are to some extent, unnecessary, because the data is already available as the Rust compiler has included it as part of the RISC-V program.

Implementing this in Rust is challenging due to its inherent design for memory safety. The standard practice in Rust involves initializing data structures through a stringent process: allocate the data structures in the stack or in the heap, zeroize the memory of the data structures (by pedantically filling in that entire memory with zeros), and copy the data one after the other. One can see that Rust is spending the computation cycles even more lavishly because zeroizing the memory is going to take another 34 million instructions at the minimum.   

Our solution employs certain low-level Rust primitives that allow us to “bypass” the restrictions imposed by the Rust LLVM compiler, thus programming the RISC-V more efficiently.

During my collaboration with Greater Heat on Aleo mining, I learned a valuable technique involving 'std::mem::transmute'." This is a special Rust function that reinterprets the bits of one type to another type. In particular, it can be used to modify the types of a pointer. 

For our application, we explicitly embed (or, more accurately, hardcode) the bytes of the memory regions for the bootstrapping key (BSK_BYTES) and the ciphertext to be bootstrapped (C_BYTES) directly in the RISC-V files. To avoid the need to copy the data, we directly manipulate the type of the pointer, as follows.

let bsk = unsafe { 
   std::mem::transmute::<&u8, &[GgswCiphertext; N]>(&BSK_BYTES[0]) 
}; 

let c = unsafe { 
   std::mem::transmute::<&u8, &LweCiphertext>(&C_BYTES[0]) 
};

As demonstrated in the preceding code, we obtain the ELF segment pointer to the hardcoded data, initially a byte pointer (`&u8`).  We then transform this into either a pointer to a bootstrapping key (`&[GgswCiphertext; N]`) or a pointer to the LWE ciphertext (`&LweCiphertext`). Furthermore, it's necessary to encapsulate this code within an `unsafe` bracket as Rust categorizes this low-level function as unsafe and mandates explicit acknowledgment of its potential risks via unsafe. This use of unsafe doesn’t inherently imply danger; rather, it signifies the need for specialized expertise in handling such low-level operations.

For readers familiar with C/C++, this process can be likened to typecasting. In C/C++, the equivalent code would appear as follows.

/* C */
BootstrappingKey *bsk = (BootstrappingKey*) &BSK_BYTES[0];
LweCiphertext *c = (LweCiphertext*) &C_BYTES[0];

/* C++ */
BootstrappingKey *bsk = reinterpret_cast<BootstrappingKey*>(&BSK_BYTES[0]);
LweCiphertext *c = reinterpret_cast<LweCiphertext*>(&C_BYTES[0]);

Our experimental results reveal that the number of cycles typically consumed by data loading is virtually eliminated using this approach. In the forthcoming analysis, we will further validate this zero-copy operation through the use of an RISC-V decompiler.

Look at the RISC-V 

We have addressed the initial challenge encountered by Louis from Zama in using RISC Zero for FHE bootstrapping verification. In the upcoming articles of this series, we will delve deeper into the topic of performance improvement and its nuances.

As we conclude this first part, our next step involves using an RISC-V decompiler to examine the program verified by RISC Zero in a zero-knowledge context. Our objectives are twofold:

• Confirm that our technique effectively achieves zero-copy at the RISC-V assembly level.

• Gain a comprehensive understanding of the overall structure of our RISC-V program.

For this purpose, we utilize Ghidra (https://github.com/NationalSecurityAgency/ghidra), a comprehensive, free-to-use reverse engineering framework developed by the US National Security Agency (NSA), which notably includes support for RISC-V.

Figure 8: Ghidra’s CodeBrowser on the RISC-V program that RISC Zero is proving.

Ghidra allows us to see both the RISC-V assembly code—as displayed in the middle pane—and the decompiled code (presented in C)---as shown on the right. Reflecting on our previous mention of RISC-V's 46 instructions, it's noteworthy that the assembly code we're analyzing utilizes these exact instructions.

We will now focus on the automatically generated decompiled code, presented below, for a detailed analysis.

/* method_name::main */

void method_name::main(void)

{
  uint *puVar1;
  uint *puVar2;
  int iVar3;
  undefined auStack_c018 [8192];
  undefined auStack_a018 [8192];
  undefined *local_8018;
  code *local_8014;
  int *local_4018 [2];
  undefined1 *local_4010;
  undefined4 local_400c;
  undefined **local_4008;
  undefined4 local_4004;
  
  gp = &__global_pointer$;
  ttfhe::glwe::GlweCiphertext::trivial_encrypt_lut_poly(auStack_c018);
  ttfhe::glwe::GlweCiphertext::rotate_trivial((int)auStack_c018,0x600);
  puVar2 = &anon.874983810a662adbf4687c54e184621b.1.llvm.4718791565163837729;
  puVar1 = (uint *)&anon.874983810a662adbf4687c54e184621b.0.llvm.4718791565163837729;
  iVar3 = 0x400;
  do {
    ttfhe::glwe::GlweCiphertext::rotate(local_4018,(int)auStack_c018,*puVar2);
    ttfhe::ggsw::cmux(&local_8018,puVar1,(int)auStack_c018,(int)local_4018);
    memcpy(auStack_c018,&local_8018,0x4000);
    puVar2 = puVar2 + 2;
    iVar3 = iVar3 + -1;
    puVar1 = puVar1 + 0x4000;
  } while (iVar3 != 0);
  local_8018 = auStack_a018;
  local_8014 = u64>::fmt;
  local_4010 = anon.874983810a662adbf4687c54e184621b.4.llvm.4718791565163837729;
  local_400c = 2;
  local_4018[0] = (int *)0x0;
  local_4008 = &local_8018;
  local_4004 = 1;
  std::io::stdio::_eprint(local_4018);
  return;
}

Our initial observation confirms that the data loading process indeed achieves zero-copy efficiency. The code segment utilizing `std::mem::transmute` for data loading compiles into a 16-byte sequence of RISC-V machine codes:

37 c5 20 04 93 04 c5 4c 37 c5 20 00 13 04 c5 4c

Decompilation reveals four assembly instructions, responsible for storing the pointer values into the s1 and s0 registers. Essentially, this code assigns the value 0x420c4cc to the s1 register and 0x020c4cc to the s0 register.

        00200844 37 c5 20 04     lui        a0,0x420c

        00200848 93 04 c5 4c     addi      s1,a0,0x4cc

        0020084c 37 c5 20 00     lui        a0,0x20c

        00200850 13 04 c5 4c     addi      s0,a0,0x4cc

Next, we can further decompile this assembly code into a C-like format for a clearer understanding, as demonstrated below.

uint *puVar1;
uint *puVar2;

puVar2 = &anon.874983810a662adbf4687c54e184621b.1.llvm.4718791565163837729;
puVar1 = (uint *)&anon.874983810a662adbf4687c54e184621b.0.llvm.4718791565163837729;

In the decompiled code, the first label—anon.874983810a662adbf4687c54e184621b.1.llvm.4718791565163837729—specifically indicates the location of the ciphertext bytes, denoted as C_BYTES. Utilizing Ghidra, we are able to directly observe these ciphertext bytes within the code.

Figure 9: The ELF executable file’s data at location 0x420c4cc (i.e., the s1 register’s initial value), which is for the ciphertext to be bootstrapped.

Recall that C_BYTES is incorporated from a file named `c`. By employing Hex Fiend, a tool for hex editing, we can examine the contents of this file. The examination, as depicted below, confirms the consistency of the data.

static C_BYTES: &[u8] = include_bytes!("../../../c");

Figure 10: The “c” file that stores the ciphertext to be bootstrapped, shown in a hex editor.

In a similar vein, by navigating to the second label—anon.874983810a662adbf4687c54e184621b.0.llvm.4718791565163837729—we can locate the bytes corresponding to the bootstrapping key, referred to as BSK_BYTES.

Figure 11: The ELF executable file’s data at location 0x020c4cc (i.e., the s0 register’s initial value), which is for the bootstrapping key.

Additionally, we can validate this data by cross-checking it with its source file, 'bsk', ensuring that it aligns with the information presented above.

Figure 10: The “bsk” file that stores the bootstrapping key, shown in a hex editor.

Moving forward, let's explore how the key and ciphertext are utilized within the program. Recall from the Rust source code that both the key and ciphertext are integral in the for loop, specifically in the invocation of the `cmux` function.

// perform the blind rotation
for i in 0..N {
   c_prime = cmux(&bsk[i], &c_prime, &c_prime.rotate(c.mask[i]));
}

Now, let's turn our attention to Ghidra to locate and examine the corresponding decompiled code.

puVar2 = &anon.874983810a662adbf4687c54e184621b.1.llvm.4718791565163837729;
puVar1 = (uint *)&anon.874983810a662adbf4687c54e184621b.0.llvm.4718791565163837729;
iVar3 = 0x400;
do {
  ttfhe::glwe::GlweCiphertext::rotate(local_4018,(int)auStack_c018,*puVar2);
  ttfhe::ggsw::cmux(&local_8018,puVar1,(int)auStack_c018,(int)local_4018);
  memcpy(auStack_c018,&local_8018,0x4000);
  puVar2 = puVar2 + 2;
  iVar3 = iVar3 + -1;
  puVar1 = puVar1 + 0x4000;
} while (iVar3 != 0);

The decompiled code involves various components.

• Cursor Assignments: puVar2 serves as the current cursor pointing to c, while puVar1 is aligned with bsk. This setup facilitates the navigation through the ciphertext and the bootstrapping key.

• Loop Mechanics: The loop utilizes iVar3, a decrementing counter starting from 1024, which signals the loop's termination upon reaching zero. Within each iteration, several operations are performed:

• Ciphertext Manipulation: c_prime, stored in auStack_c018 on the stack, is first rotated with c.mask[i] (referred to as *puVar2) to yield a result placed in local_4018.

• `cmux` Function Invocation: This key function takes bsk[i] (puVar1), the original c_prime, and the rotated c_prime as inputs, outputting the result into local_8018.

• Optimization Opportunity: An intriguing aspect is the handling of local_8018, which is treated as the updated c_prime. It is copied back into the c_prime variable, hinting at a potential optimization. Eliminating this copy by performing cmux in an in-place manner could enhance efficiency.

• Cursor Updates: The loop includes updates to both puVar2 and puVar1. puVar2 moves forward by two dwords (64 bits) to the next c.mask[i], while puVar1 advances by 16384 dwords (524288 bits) to the subsequent bsk[i].

As the loop concludes when iVar3 reaches zero, these steps collectively represent the process of handling the FHE bootstrapping in the RISC-V program.

Further analysis using Ghidra enables us to scrutinize other segments of the program, providing insights into potential optimization opportunities. This process helps us assess whether the Rust RISC-V compiler is generating RISC-V instructions as intended.

For instance, let’s examine the decompiled code of the cmux function. To provide context, we’ll first consider the original Rust code as follows.

/// Ciphertext multiplexer. If `ctb` is an encryption of `1`, return `ct1`. Else, return `ct2`.
pub fn cmux(ctb: &GgswCiphertext, ct1: &GlweCiphertext, ct2: &GlweCiphertext) -> GlweCiphertext {
   let mut res = ct2.sub(ct1);
   res = ctb.external_product(&res);
   res = res.add(ct1);
   res
}

The decompiled code reveals that function calls to `sub` and `add` have been effectively inlined during compilation. This inlining results in visible loops within the code, which are responsible for simulating 64-bit integer operations. Additionally, the code utilizes several calls to `memset` and `memcpy`. Notably, some instances of `memset` are employed for zeroizing memory, which may not always be necessary. This observation opens up potential optimization avenues, particularly in eliminating unnecessary `memset` calls.

Figure 11: Decompiled code of the RISC-V instructions of the `cmux` function.

With this, we conclude Part I of our technical deep dive into verifying FHE in RISC Zero. This article provided an overview of FHE and RISC Zero, detailed the process of adapting existing Rust code for RISC Zero, introduced a novel data loading optimization trick in RISC Zero, and demonstrated the use of Ghidra for disassembling and analyzing RISC-V code to identify further optimization opportunities.

Keep an eye out for the upcoming articles in our 'Verifying FHE in RISC Zero' series, where we will delve deeper into more advanced concepts and optimizations.

Update on 12/14/2023: We notice that `include_bytes` may fail to align the data properly and can cause an alignment error. Therefore, we opt to use `include_bytes_aligned` from this crate.

Find L2IV at l2iterative.com and on Twitter @l2iterative

Author: Weikeng Chen, Research Partner, L2IV (@weikengchen)

Disclaimer: This content is provided for informational purposes only and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisors as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services.