# Implementation Study of Cost-Effective
Verification for Pietrzak’s Verifiable Delay Function
in Ethereum Smart Contracts

Suhyeon Lee §
Tokamak Network
<EMAIL_ADDRESS>
&Euisin Gee §
School of Cybersecurity
Korea University
<EMAIL_ADDRESS>
Onther
<EMAIL_ADDRESS>
&Junghee Lee
School of Cybersecurity
Korea University
<EMAIL_ADDRESS>

###### Abstract

Verifiable Delay Function (VDF) is a cryptographic concept that ensures a
minimum delay before output through sequential processing, which is resistant
to parallel computing. Among the two well-known VDF protocols, Wesolowski and
Pietrzak VDF, we focus on the Pietrzak VDF due to its computational efficiency
and suitability for blockchain environments. Pietrzak’s approach uses a
recursive proof verification with the halving protocol, offering a practical
alternative despite the longer proof length than Wesolowski’s approach. Given
the scarcity of research on practical VDF verification implementation,
especially within smart contracts, this paper aims to implement cost-effective
verification for the Pietrzak VDF in an Ethereum-based environment without
compromising the VDF verification’s integrity and reliability. Firstly, we
propose generalized proof generation and verification algorithms for potential
efficiency improvement. Secondly, we categorize and measure the gas cost of
each part in a transaction for VDF verification. Thirdly, based on the
analysis, we theoretically predict the optimized proof construction. Finally,
we demonstrate the theoretical prediction matches the implementation results.
Furthermore, our research shows that the proof length of the Pietrzak VDF is
generated under 8 KB with the 2048-bit RSA key length, much smaller than the
previous expectation. This implies that the Pietrzak VDF can be practically
used for cryptographic applications on blockchains.

§§footnotetext: These authors contributed equally to this work.

_Keywords_ Ethereum $\cdot$ blockchain security $\cdot$ cryptographic protocol
$\cdot$ decentralized application $\cdot$ gas optimization $\cdot$ verifiable
delay function

##  1 Introduction

††footnotetext: We express our special thanks to Prof. Seungjoo Kim at Korea
University for his invaluable advice on cryptographic algorithms.

In blockchain technology, one critical element is the generation and use of
cryptographically secure random numbers. These secure random numbers play a
pivotal role in various applications of blockchain; for example, in consensus,
random numbers can ensure fair selections of sequencers and block proposers
based on a probabilistic process. Random numbers are essential for ensuring
anonymity and serve as the basis for cryptographic techniques. Despite the
significance of secure random numbers, incorporating them into smart contracts
results in challenges. Due to the lack of random number methods in the smart
contract interface, individuals previously used to apply future block data
(i.e. the blockhash of a future block) as an ad-hoc random number. It can be
manipulated by a block generator. Hence, leveraging ad-hoc random numbers is
not a suitable approach for the present situation.

In this context, two notable techniques have emerged: Verifiable Random
Functions (VRFs) and Verifiable Delay Functions (VDFs). VRFs are cryptographic
primitives that produce a random number along with proof of its correctness,
allowing anyone to verify the number’s authenticity without compromising its
unpredictability. Several commercial random number generating services using
VRF, such as Chainlink VRF, are already available. As part of their operation,
a node acting as an oracle transmits a randomly generated number from off-
chain nodes to a blockchain.

On the other hand, VDFs are designed to produce a unique output that requires
a predetermined amount of time to compute, but whose result can be efficiently
verified by others. Therefore, VDFs do not directly generate a random number.
Rather, VDFs support random number generation of the commit-reveal scheme by
utilizing their time-lock property. The most critical weakness of the commit-
reveal scheme is that all the participants must reveal to generate a secure
random number. VDFs’ time-lock property ensures that the random outcome cannot
be predicted or accelerated by computational power in case of any absence. It
makes VDFs practical for applications that benefit from a guaranteed delay in
randomness generation. Financial penalties alone in the commit-reveal scheme
may not ensure the reliable generation of random numbers. Integrating VDFs
with it, restructured as a commit-reveal-recover mechanism, can significantly
enhance security.

Figure 1: In our model, a user sends a VDF proof after the Pietrzak VDF
evaluation. The primary issue is the significant gas usage for the VDF
verification. The secondary issue is the length of the VDF proof as the
Pietrzak VDF’s length increases as the time delay increases.

Pivotal advancements in VDFs have been made through the research of Pietrzak
[1] and Wesolowski [2], who each proposed practical implementations of VDFs.
Despite these theoretical developments, there remains a notable gap in
research regarding the application of VDFs within blockchain environments. The
challenge lies not only in the theoretical construction of VDFs, but also in
adapting these constructions to the resource usage context of blockchain
systems. For example, the Pietrzak VDF uses the halving protocol that makes
the length of proof proportional to the delay time. It makes utilizing the
Pietrzak VDF considered unrealistic in blockchain [3]. The Wesolowski VDF
needs a hash-to-prime oracle that is not supported in most blockchains.

When implementing VDFs, the process can broadly be divided into three parts:
evaluation, proof generation, and verification. In the context of blockchain,
the verification component must be implemented on-chain. This segmentation is
due to our belief that in typical blockchain applications, both evaluation and
proof generation processes are performed off-chain, mainly due to their
computational intensity and the associated costs when executed on a blockchain
network.

Our goal has been to efficiently implement VDF verification within smart
contracts as Figure 1’s illustration. Specifically, we have targeted the
Pietrzak VDF model. There are two reasons: Firstly, the Wesolowski VDF
requires a hash-to-prime function that is challenging to implement on smart
contracts. Secondly, we conjectured that optimization can mitigate the long-
proof length issue partially. Based on this algorithm choice, consequently,
this research demonstrated that the Pietrzak VDF verification can be utilized
in the EVM-compatible smart contract environment through various cost-saving
analysis and experiments.

The contributions of this paper are as follows:

  * •

To the best of our knowledge, this research presents the first academic study
of Pietrzak VDF implementation on smart contracts.

  * •

We proposed generalized algorithms for proof generation and verification of
the Pietrzak VDF for potential efficiency enhancement.

  * •

Through theoretical analysis, we demonstrated the existence of a unique
parameter that reduces the proof length. Additionally, the actual
implementation results were consistent with our theoretical expectations.

  * •

Contrary to previous studies’ expectations, we demonstrated that the Pietrzak
VDF could be utilized in the Ethereum environment with under 8 KB calldata
size with the 2048-bit RSA key length.

The rest of the paper is organized as follows: Section 2 introduces related
studies about VDFs and their implementation. Section 3 describes the proposed
target algorithms and our implementation environment. Section 4 illustrates
the data structures of proofs and analyzes gas costs for the data and its
dispatching cost. Section 5 studies arithmetic operations in the verification
process and their gas costs. In Section 6, based on the previous sections’
outcomes, we present theoretical analysis and the cost-effective
implementation. Section 7 discusses this research’s contributions,
limitations, and future directions. Finally, Section 8 concludes the paper.

##  2 Background

This section introduces VDFs, cryptographic algorithms crucial for blockchain
applications and secure timestamping. It also reviews related works that
inform the VDF implementations discussed in this paper.

###  2.1 Verifiable Delay Functions

VDFs are cryptographic protocols crafted to ensure that their execution takes
a predefined minimum amount of time, regardless of the computational power
applied. Here we introduce the core mechanisms that define VDFs and the core
properties that VDFs get from the elements.

####  2.1.1 Definition and Fundamental Properties

A VDF consists of three key algorithms that facilitate one round: setup,
evaluation, and verification.

  * •

Setup $(\text{Setup}(1^{\lambda})\rightarrow(\mathbb{G},T))$: Initializes the
VDF with public parameters. Here, $1^{\lambda}$ represents the security
parameter indicating the required security level, $\mathbb{G}$ is a
cryptographic group used in computations, and $T$ is the time delay parameter
that sets the duration of the computation.

  * •

Evaluation $(\text{Evaluate}(\mathbb{G},T,X)\rightarrow(Y,\pi))$: For a given
input $X$, the VDF computes an output $Y$ over time $T$, which is deliberately
designed to be sequential, preventing acceleration through parallel
processing. The output includes a proof $\pi$ that validates the computation.

  * •

Verification
$(\text{Verify}(\mathbb{G},T,X,Y,\pi)\rightarrow\\{\textsf{true},\textsf{false}\\})$:
Enables any observer to quickly and efficiently verify the correctness of the
output $Y$ and its proof $\pi$ without undergoing the time-intensive
computation themselves. A return of true confirms the validity of the output,
while false indicates an error.

From the above algorithms, VDFs must get the three primary attributes [4]:

  * •

Sequentiality in evaluation: The computation must take a fixed minimum time,
irrespective of the available computational resources.

  * •

Efficiency in verification: Although the computation itself is intentionally
delayed, the verification process is designed to be quick and require minimal
resources.

  * •

Uniqueness in output: Each input to a VDF yields a unique, unpredictable
output, ensuring reliability and consistency in applications.

###  2.2 Feasibility of On-Chain VDF Verification

Both Wesolowski [2] and Pietrzak [1] VDFs operate by transforming a value $x$
into $y=x^{2^{T}}\mod N$, where $N$ is an RSA modulus, although their
verification methods differ. Scalability and implementation costs are
significant challenges in blockchain systems. Employing the Fiat-Shamir
heuristic, both methods facilitate non-interactive verification, suitable for
blockchain environments. However, the computational intensity and memory
demands for managing large numeric values pose substantial hurdles.

Wesolowski’s VDF maintains a constant proof length ($O(1)$), independent of
the time delay parameter $T$, making it particularly advantageous where proof
size is a concern. The implementation on blockchain platforms like Ethereum is
particularly challenging due to the high cost associated with verifying or
finding primes for large numbers, such as 2048 bits. This necessity
significantly increases the implementation cost, making full on-chain
execution unfeasible.

Pietrzak’s VDF does not require operations like hash-to-prime, simplifying its
on-chain implementation. The protocol involves a halving process, where $T$ is
divided by two until it becomes one, reducing the complexity of computations
with each iteration. However, the proof length and cost are influenced by the
time delay variable $T$, and the proof length grows with $O(\log_{2}(T))$.
This characteristic can result in verifications that exceed the size limit for
feasible blockchain implementation. The research anticipated that the length
of the proof will approximate 40 KB [3].

###  2.3 Related Works

In this subsection, we review the critical advancements in VDFs, from their
theoretical foundations to practical implementations related to this study.

Theoretical research on VDFs. The concept of VDFs has garnered significant
attention for its potential to enable new applications in cryptography and
blockchain technology. The foundational work by Rivest, Shamir, and Wagner on
"Time-Lock Puzzles and Timed-Release Crypto" [5] laid the groundwork for the
development of protocols that secure data until a certain amount of time has
passed. This seminal paper introduced the concept of time-lock puzzles, a
precursor to VDFs, demonstrating how cryptographic operations could be used to
create a delay mechanism that is practically infeasible to bypass without
solving the puzzle.

Building upon these principles, Pietrzak [1] and Wesolowski [2] independently
proposed two distinct approaches to VDFs, each with unique advantages in terms
of efficiency and security. Pietrzak’s method focuses on using iterated
sequential squaring in a group of unknown order, providing a balance between
computation time and verification efficiency. Wesolowski’s approach, on the
other hand, introduces an elegant solution that reduces the verification
complexity, making it more practical for applications that require fast and
efficient verification processes.

Further advancing the field, Dan Boneh et al. [6] have conducted extensive
research on optimizing VDFs, addressing critical aspects such as the
construction of more efficient protocols and the reduction of computational
requirements for both generation and verification phases. Their work not only
highlights the theoretical advancements in VDF technology but also emphasizes
the practical implications for secure, decentralized systems.

Implementation of VDFs. The practical realization of VDFs has become an area
of intense research and development, seeking to bridge the gap between
theoretical robustness and real-world applicability. A significant
contribution to this endeavor is the study by Attias et al. [3], which
provides a comprehensive implementation analysis of two leading VDFs, Pietrzak
and Wesolowski. Their work meticulously evaluates the performance of VDFs’
evaluation, proof generation, and verification. Their work provided us with
insight into the research and optimization techniques for VDFs. However, they
expected the Pietrzak VDF would not be viable for blockchains. This is
contrary to our results that presented the feasibility of the Pietrzak VDF on
Ethereum smart contracts.

Choi et al. [7] proposed three practical commit-reveal-recover techniques.
Their protocols are crucial for establishing the commit-reveal-recover scheme,
which mostly existed at the conceptual level. They incorporated the Wesolowski
VDF into Ethereum smart contracts for the purpose of demonstration. Our
research covers VDF verification, which corresponds to the Proof-of-
Exponentiation (PoE) stated in their work. Their PoE gas usage is
approximately 2.3 million, which is comparable to the gas consumption of our
work with the time delay variable of $2^{22}$. Due to the Wesolowski VDF not
having increased calculation requirements with greater time delays, our
approach becomes less efficient when the time delay variable exceeds $2^{23}$.
Nevertheless, the Wesolowski VDF encounters an issue when it comes to fully
implementing the hash-to-prime function as previously indicated.

##  3 Implementation Target and Environment

In this section, we provide the target algorithm and environment. Firstly, we
define the Pietrzak VDF algorithms we aim to implement in this research.
Secondly, we describe the experiment environment in the following sections.

###  3.1 Pietrzak VDF Algorithms

Our research has a model with a smart contract that supports a function that
performs Pietrzak VDF verification. Referring to the Pietrzak’s original paper
[1], we define the evaluation as described in Algorithm 1 and the halving
protocol for proof generation in Algorithm 2.

####  3.1.1 VDF Evaluation

$y\equiv x^{2^{T}}\equiv x^{2^{2^{\tau}}}\mod{N}$ (1)

The VDF evaluation process as defined in Algorithm 1 is pivotal in generating
a VDF output from given inputs. It basically computes Equation 1. The
algorithm takes an initial value $x$, a time parameter $T$ (also notated as
$2^{\tau}$), and a modulus $N$ to produce the output $y$. $N$ that is a
$\lambda$-bit number is produced by an RSA setup ($N=p\cdot q$ where $p,q$ are
two big prime numbers). The process involves exponentiating $x$ to $2^{T}\mod
N$ to ensure the difficulty and time consumption of the evaluation are as
intended. This evaluation serves as the foundation for verifying that the
output can only be computed with a predefined amount of real-time
computational work, which is crucial in applications requiring guarantees
against parallelization.

Algorithm 1 Evaluation of the Pietrzak VDF

1:input: $x,T,N$

2:output: $y$

3:$y\leftarrow x$

4:for $k\leftarrow 1$ to $T$ do

5: $y\leftarrow y^{2}\mod N$

6:end for

7:return $y$

####  3.1.2 Halving Protocol

The halving protocol detailed in Algorithm 2 optimizes the proof generation
process for VDFs by reducing the verification time incrementally. At each
step, the protocol halves the time parameter $T$, recalculates intermediate
values $x_{i}$ and $y_{i}$, and updates these values based on a cryptographic
hash function to ensure integrity. As we implement it on Ethereum, we use
Keccak256 as the cryptographic hash function. This iterative reduction
continues until the desired granularity is reached, ensuring that the
verifier’s workload is minimized while maintaining cryptographic security.

Algorithm 2 Halving Protocol of the Pietrzak VDF

1:input: $N,x_{i},T,y_{i}$

2:output: $N,x_{i+1},T/{2^{i}},y_{i+1},\mu_{i+1}$

3:$\mu_{i}\leftarrow x_{i}^{2^{T/{2^{i}}}}$

4:$r_{i}\leftarrow\text{Hash}(x_{i}+y_{i}+v_{i})$

5:$x_{i+1}\leftarrow x_{i}^{r_{i}}\cdot v_{i}\mod N$

6:if $T/2^{i-1}$ is odd then

7: $y_{i}\leftarrow y_{i}^{2}\mod N$

8:end if

9:$y_{i+1}\leftarrow v_{i}^{r_{i}}\cdot y_{i}\mod N$

10:return $N,x_{i+1},T/{2^{i}},y_{i+1},\mu_{i+1}$

####  3.1.3 Introduction of Generalized Proof Generation/Verification and Its
Rationale

In the original paper [1] and the related works [6, 3], the conventional
Pietrzak halving protocol is repeated until the time parameter $T$ gets 1 for
proof generation. It helps the verifier consume the nearly least resources to
verify VDF proofs in general systems. However, on Ethereum, the cost of
resource usage, called gas, significantly differs from general environments.
Ethereum Yellowpaper [8] provides predefined gas prices for transactions and
opcodes executions. Especially in this context, repeating the halving protocol
till $T=1$ does not guarantee the most efficient verification. Therefore, we
generalized the Pietrzak verification algorithm with flexible repetition of
the halving protocol. In Algorithm 4, we introduced a new parameter $\delta$.
The halving protocol is repeated till the time variable becomes equal to
$\delta$. Then, the verifier checks
$y\stackrel{{\scriptstyle?}}{{=}}x^{2^{2^{\delta}}}$.

####  3.1.4 Generalized Proof Generation

In Algorithm 3, the generalized proof generation is used to construct the
cryptographic proofs required for VDF verification under flexible conditions.
The proof generation starts with the evaluation result and halves the
exponentiation of a proof step-by-step until reaching the specified parameter
$\delta$. Each halving can be tracked as intermediate values $v_{i}$ are
stored as part of the proof. This mechanism allows for flexible adjustment of
the verification process to accommodate different system capacities and
security requirements.

Algorithm 3 Generalized Proof Generation of the Pietrzak VDF with Evaluation

1:input: $x,T,\delta,N$

2:output: $\\{\pi_{i}\\}_{i=1}^{\tau-\delta}$

3:$\tau\leftarrow\lfloor\log_{2}(T)\rfloor$

4:$y\leftarrow x$

5:for $k\leftarrow 1$ to $T$ do

6: $y\leftarrow y^{2}\mod N$

7:end for

8:$(x_{1},y_{1})\leftarrow(x,y)$

9:for $i\leftarrow 1$ to $\tau-\delta$ do

10: $v_{i}\leftarrow x^{2^{T/2^{i}}}$

11: $r_{i}\leftarrow keccak256(x_{i}+y_{i}+v_{i})$

12: $x_{i+1}\leftarrow x_{i}^{r_{i}}\cdot v_{i}\mod N$

13: if $T/2^{i-1}$ is odd then

14: $y_{i}\leftarrow y_{i}^{2}\mod N$

15: end if

16: $y_{i+1}\leftarrow v_{i}^{r_{i}}\cdot y_{i}\mod N$

17: $\pi_{i}\leftarrow v_{i}$

18:end for

19:return $\\{\pi_{i}\\}_{i=1}^{\tau-\delta}$

####  3.1.5 Generalized Verification

Algorithm 4 describes the generalized verification process for VDFs on
Ethereum. It utilizes the proofs generated by the generalized proof generation
method to validate the sequence of operations leading to the final result. The
verifier iteratively computes and checks each step of the proof against the
corresponding intermediate values and the final condition
$y_{\tau-\delta+1}=x_{\tau-\delta+1}^{2^{2^{\delta}}}$. This process ensures
that the computation was performed correctly and meets the specified delay
constraints, which is crucial for applications relying on the integrity of
timed cryptographic operations.

Algorithm 4 Generalized Verification of the Pietrzak VDF

1:input: $x,y,T,\delta,\\{\pi_{i}\\}_{i=1}^{\tau-\delta},N$

2:output: True or False

3:$\tau\leftarrow\lfloor\log_{2}(T)\rfloor$

4:$(x_{1},y_{1})\leftarrow(x,y)$

5:for $i\leftarrow 1$ to $\tau-\delta$ do

6: $v_{i}\leftarrow\pi_{i}$

7: $r_{i}\leftarrow keccak256(x_{i}+y_{i}+v_{i})$

8: $x_{i+1}\leftarrow x_{i}^{r_{i}}\cdot v_{i}\mod N$

9: if $T/2^{i-1}$ is odd then

10: $y_{i}\leftarrow y_{i}^{2}\mod N$

11: end if

12: $y_{i+1}\leftarrow v_{i}^{r_{i}}\cdot y_{i}\mod N$

13:end for

14:if $y_{\tau-\delta+1}=x_{\tau-\delta+1}^{2^{2^{\delta}}}$ then

15: return True

16:else

17: return False

18:end if

According to Algorithm 3, and 4, the data should be submitted are the root
($x$), the VDF evaluation result ($y=x^{2^{T}}$), the time delay variable
($T$), the VDF proof ($\\{\pi_{i}\\}_{i=1}^{\tau-\delta}$), and the group
description ($N$) as described in Equation 2.

$\Big{(}N,x,y,\tau,\overbrace{(\pi_{1},\pi_{2},\pi_{3},...,\pi_{k})}^{\overbrace{\lfloor\log_{2}(T)\rfloor}^{\tau}-\delta}\Big{)}$
(2)

###  3.2 Target Time Delay and the Bit Length

Recent advances in VDF implementation using C++, as studied by Attias et al.
[3], demonstrate that VDF evaluation times can range from $2^{20}$ to $2^{25}$
cycles. These findings suggest that the implementations are not only effective
but also efficient in experimental setups. In the context of Ethereum, where
block generation typically requires around 12 seconds and even less time in
other blockchain systems, we recommend that the time delay for generating VDF-
based random numbers should not exceed one minute. This recommendation aims to
prevent excessive resource consumption without compromising practical utility.

The experimental results from Attias et al. [3] show that a performance
duration of approximately one minute at the 2048-bit RSA key level is
feasible. Consequently, we advocate for a similar time range in VDF
applications. The security of our target Pietrzak VDF configuration depends on
the difficulty of the prime factoring problem, akin to that in the RSA
encryption system. Currently, a 2048-bit key length is deemed sufficient for
maintaining security standards. However, considering potential advancements in
computational capabilities, a 3072-bit key length might be necessary after ten
years. Therefore, our experiments included tests with both 2048-bit and
3072-bit settings for VDFs.

###  3.3 Environment for Gas Usage Measurement

Here we describe the setup of this research used to measure gas usage in
Ethereum smart contracts, detailing the use of Solidity and the related
framework.

####  3.3.1 Development Environment and Compiler Version

The development of the contract was conducted using Solidity version 0.8.23.
This choice was driven by the compatibility and full support provided by the
Hardhat framework, a comprehensive Ethereum development environment with
integrated debugging capabilities. At the start of the development process,
Solidity 0.8.23 was the latest compiler version fully supported by Hardhat for
debugging and other essential development functionalities. Generally, gas
optimization is best achieved with the latest version of the compiler.

####  3.3.2 Optimizer Configuration

For configuration, the core parameter of the Solidity optimizer is Runs which
indicates how often each opcode will be used in the deployed contract. That
is, higher Runs implies less gas cost for execution and higher gas cost for
deployment. We set the optimizer parameter Runs to 4,294,967,295($2^{32}-1$),
which is the maximum value of the parameter, indicating the highest level of
optimization for execution.

We set up Via-IR (Intermediate Representation) and the Yul optimizer in the
Solidity compiler to generate efficient bytecode. Via-IR helps efficiency,
security, and simplicity in code generation by deviating from the direct
compilation of Solidity code to EVM bytecode. Instead, via-IR processes an
intermediate step where Yul code, an intermediate representation, is
generated.

In this step, we can enhance the Yul optimizer’s efficiency. We replaced the
msize() operation with the free memory pointer. This adjustment necessitated
manual updates to the memory indexes, a process rigorously tested to ensure
the integrity of our implementation. We also applied memory-safe assembly
blocks in our code. This change not only aligns with Solidity’s memory model
but also activates Via-IR in the compiler settings, resulting in significant
gas savings.

####  3.3.3 Gas Measurement

We implemented external functions in MinimalApplication.sol, the major source
file for implementation, to measure the gas used with different strategies.
The gas cost depends on the order of the function selectors in these external
functions, but the differences are considered to be negligible, with a maximum
difference of about 60 gas used across the seven external functions.
Therefore, an error margin of about 60 gas exists for the results presented in
the figures.

####  3.3.4 Local Testing Environment

We utilized the Hardhat node, provided by the Hardhat framework, to create a
local testing environment. The amount of gas usage was obtained using the
eth_estimateGas method, which generates and returns an estimate of the gas
required to complete the transaction. This method accurately measures the gas
used in the execution of different contract functions and provides valuable
insights into the efficiency of the implementations. It is important to note
that the actual gas cost incurred on the real network is determined by
multiplying the estimated gasUsed by the gasPrice at the Ethereum network
circumstance.

##  4 Data and Accompanying Gas Cost

In this section, we introduce the data structure we used to send VDF proofs in
the Ethereum transaction calldata. Then, we investigate the gas cost to send
VDF proofs and regress the results to linear functions for the next sections.

###  4.1 Data Structure

In this study, the VDFs are implemented with key sizes of 2048 and 3072 bits.
However, the EVM natively supports arithmetic operators only up to 256-bit
numbers. Therefore, to facilitate efficient computation of numbers exceeding
256 bits, it is necessary to employ customized data formats. We revised the
big number library implementation for Solidity developed by Firo [9]. The
original data structure in this library includes bytes data (bytes val), bit
length (uint bitlen), and a sign indicator (bool neg). Among the three
elements, we deleted the sign indicator and its related low-level logic since
our implementation does not require handling negative values. This library
optimizes on-chain operations such as addition and subtraction by adding
leading zeros for 32-byte alignment with the EVM’s memory word size,
eliminating offset management. Also, it utilizes the bit length data field to
optimize multiplication and comparison operations. Therefore, we format the
bytes data and pre-calculate bit length off-chain before submission,
significantly reducing unnecessary on-chain computations. For example, the
data format for a 2048-bit representation in JSON is as shown in Listing 1. In
this way, we can reduce the gas cost even though the calldata size increases.
This decision is reasonable because the primary goal is to reduce the gas
cost, not the transaction calldata size.

⬇

1{

2 "big_number": {

3 "val":
"0x4621c26320fe0924bba1b7d5bc863495b9f0db3823b12a9a18e21d23...........b2127fd6390f5f6234a164bd39d1dd6884b768c4dd790586ee",

4 "bitlen": 2047

5 }

6}

Listing 1 Calldata for a Big Number Example

###  4.2 Gas Cost of Calldata

The gas cost for Ethereum transaction calldata was fixed in EIP-2028
"Transaction data gas cost reduction" [10]. According to the document, the
cost of calldata is divided into two cases:

  * •

Non-zero byte: 16 gas

  * •

Zero byte: 4 gas

Considering the above gas pricing, we can calculate the cost for sending one
2048-bit length data in the aforementioned data structure. Taking into account
the probability of each byte being non-zero, which is $\frac{1}{256}$, the
expected gas cost for sending one 2048-bit length data is 1036 gas. The gas
for the Big Number structure is added to this.

In our implementation, the function verifyRecursiveHalvingProof processes the
generalized verification (Algorithm 4). It is defined as the Listing 2 in
Solidity codes.

⬇

1function verifyRecursiveHalvingProof(

2 BigNumber[] memory v,

3 BigNumber memory x,

4 BigNumber memory y,

5 BigNumber memory n,

6 uint256 delta,

7 uint256 T

8)

Listing 2 Interface of the Halving Verification Function

A call to this function involves encoding parameter values. Start by computing
the keccak256 of the UTF-8 byte representation of the
string111verifyRecursiveHalvingProof((bytes,uint256)[],(bytes,uint256),(bytes,uint256),(bytes,uint256),uint256,uint256)
based on Listing 2 and use the first four bytes, which results in 0xd8e6ac60.

For static types such as uint256, fields including delta and T are padded to
32 bytes. On the other hand, In EVM, dynamic types, including bytes, struct,
and dynamic arrays, are encoded by specifying an offset to the start of the
data, its length, and then the data itself. This routine is applied
recursively for nested dynamic types. In case of BigNumber[] memory v, it is
the dynamic array of dynamic type struct BigNumber that contains dynamic bytes
val. So the way dynamic types are encoded is recursively applied to each
halving proof v.

Parameters such as $T$, $\delta$, $\lambda$, and parameter count (e.g., 6 in
our model) determine the offsets and lengths. The gas usage for data depends
probabilistically on the distribution of zero and non-zero bytes in the data.
Since EVM organizes memory in 32-byte words, we can consider the same number
of word is repeated when data is repeated. Finally, we can predict the
approximate gas usage of calldata using this EVM data construction structure.

Considering the precision of data and its cost, we performed experiments to
test the size of calldata and the related gas usage. The related gas usage
comprises of the intrinsic gas and data dispatching gas. The intrinsic gas in
EVM refers the minimum cost for a transaction. It contains the constant
transaction cost (21000 gas) and the cost for data supply. For verification,
we need not only to allocate data in a transaction, but also to dispatch data
into the verification function. The dispatching cost is proportional to the
data size. Therefore, we decided to include the dispatching cost into the data
cost in this study. Figure 2(a) for $\lambda=2048$ and 2(b) for $\lambda=3072$
show the calldata size with the number of proofs and the related gas usage. We
can see the gas usage and the calldata size simply and linearly increase with
the number of proofs.

Figure 2: Experiment results of the calldata length and cost for the proofs

(a) Calldata size and gas cost including intrinsic gas and dispatching gas
($\lambda=2048$)

(b) Calldata size and gas cost including intrinsic gas and dispatching gas
($\lambda=3072$)

Finally, to elucidate the relationship between transaction size and gas costs,
we perform a regression analysis. By applying the least squares method to
approximate the best fit, we derive the following linear regression equations
3 and 4 for data sizes of 2048 and 3072 bytes, respectively:

$\mathcal{G}_{data,2048}(\tau)=5295.73\cdot\tau+37610.11$ (3)

$\mathcal{G}_{data,3072}(\tau)=7389.31\cdot\tau+43943.88$ (4)

These equations estimate the gas cost $\mathcal{G}$ as a function of
transaction size $\tau$, highlighting the increase in required gas with larger
transaction calldata.

##  5 Arithmetic Operations and Accompanying Gas Cost

This section focuses on analyzing the expenses associated with performing
arithmetic operations in the context of verifying the Pietrzak VDF. The cost
consists of two components: the cost of repeated halving and the cost of
modular exponentiation for the final check. The algorithm executes a halving
operation and then proceeds with a modular exponentiation verification. The
modular exponentiation cost is studied before the halving cost, as the halving
process includes the modular exponentiation. Using the results, we perform a
regression analysis to formulate mathematical equations for the cost in the
section that follows.

###  5.1 Modular Exponentiation Cost

This part explores strategies for optimizing the computational cost of modular
exponentiation, a frequent operation in various cryptographic algorithms. It
discusses algorithms such as Square and Multiply [11], Dimitrov
multiexponentiation [12], and the ModExp contract introduced by EIP-198.

####  5.1.1 Square and Multiply

The square and multiply algorithm, also called binary exponentiation, is an
efficient approach for computing exponentiation operations $x^{n}$,
particularly beneficial for large number modular exponentiation. As described
in Algorithm 5, by converting the exponent $b$ into its binary representation,
the algorithm optimizes computation through a series of square (squaring) and
multiply (multiplying by the base $x$) operations based on the binary digits
of $n$. For an exponent represented by $k$ bits, the algorithm requires at
most $k-1$ squaring and $k-1$ multiplication operations, making the
computational complexity $O(\log_{2}n)$. This optimization is simple but
significantly enhances efficiency for large-scale modular exponentiation
tasks.

Algorithm 5 Square and Multiply for Modular Exponentiation

1:input: $a,b,N$

2:output: $a^{b}$ mod $N$

3:$r\leftarrow 1$

4:$a\leftarrow a\mod N$

5:while $b>0$ do

6: if $b\mod 2=1$ then

7: $r\leftarrow(r\cdot a)\mod N$

8: end if

9: $b\leftarrow b>>1$

10: $a\leftarrow(a\cdot a)\mod N$

11:end while

12:return $r$

####  5.1.2 Dimitrov Multiexponentiation

The Dimitrov algorithm [12, 3] presented in Algorithm 6 enhances the
efficiency of large integer multiplication, crucial in fields such as
cryptography and computational mathematics, by significantly reducing the
computational complexity. Traditionally, the multiplication of large integers
($x^{a}y^{b}$) exhibits a complexity of $O(2\log_{2}max(a,b))$. Utilizing the
binary exponentiation method [13], the Dimitrov algorithm achieves a
computational complexity closer to $O(\frac{7}{4}\log_{2}max(a,b))$. This
characteristic allows for the rapid and resource-efficient multiplication of
very large integers, making the algorithm particularly valuable for
applications requiring efficient large-scale numerical operations. In the
generalized verification (Algorithm 4), lines 9 – 12 perform
multiexponentiation only if $T/2$ is odd. Therefore, we considered the
Dimitrov algorithm as a candidate algorithm to apply for optimization.

Algorithm 6 Dimitrov Multiexponentiation Algorithm

1:input: $x,y,a,b,N$

2:output: $x^{a}\cdot y^{b}\mod N$

3:$h\leftarrow\max(\lfloor\log_{2}a\rfloor+1,\lfloor\log_{2}b\rfloor+1)$

4:$z\leftarrow 1$

5:$q\leftarrow x\cdot y\mod N$

6:for $i=h-1$ down to $0$ do

7: $z\leftarrow z\cdot z\mod N$

8: if $a_{i}=1$ and $b_{i}=0$ then

9: $z\leftarrow z\cdot x\mod N$

10: else if $a_{i}=0$ and $b_{i}=1$ then

11: $z\leftarrow z\cdot y\mod N$

12: else if $a_{i}=1$ and $b_{i}=1$ then

13: $z\leftarrow z\cdot q\mod N$

14: end if

15:end for

16:return $z$

Figure 3: Experiment results of the modular exponentiation cost

(a) Gas usage of exponentiation by squaring, square and multiply, and
precompiled ModExp, x is 2048-bit level

(b) Gas usage of exponentiation by squaring, square and multiply, and
precompiled ModExp, x is 3072-bit level

(c) Gas usage of Dimitrov multiexponentiation and only precompiled ModExp, x
is 2048-bit level

(d) Gas usage of Dimitrov multiexponentiation and only precompiled ModExp, x
is 3072-bit level

####  5.1.3 ModExp by EIP-198

EIP-198 [14], known for introducing "Big Integer Modular Exponentiation",
introduces the ModExp (Modular Exponential) precompiled contract to the EVM,
offering a streamlined and cost-efficient approach to conducting large integer
modular exponentiation, a foundational operation in numerous cryptographic
algorithms.

This function calculates $a^{b}\mod n$, where $a$, $b$, and $n$ are large
numbers, and prior to EIP-198, such execution on-chain was not officially
supported by any operations. The ModExp contract mitigates these expenses by
providing a standardized computation method, thus facilitating the
incorporation of cryptographic computations within smart contracts. Building
on this, EIP-2565 [15] contributed to further refining the gas cost model for
these modular exponentiation operations by proposing adjustments to the
pricing formula.

####  5.1.4 Comparison of Exponentiation Techniques and Regression

Figure 3(a) and Figure 3(b) present the gas usage experiment results of three
modular exponentiation techniques. We name a naive exponentiation approach as
exponentiation by squaring in the figures. The comparing data named
‘Precompile’ is the gas usage when only the precompiled ModExp is used for
multiexponentiation. Even if square and multiply (Algorithm 5) reduces the gas
usage, it is obvious that the precompiled ModExp uses outstandingly less gas
for the modular exponentiation than the others. Figure 3(c) and Figure 3(d)
show the gas usage experiment results for modular multiexponentiation. We
implemented Dimitrov multiexponentitaion including the precompiled ModExp. The
latter takes significantly less gas than the Dimitrov algorithm. Therefore, we
applied ModExp for both the modular exponentiation and multiexponentiation
operations in the implementation in Algorithm 4.

In the experiment, the pricing of ModExp is linearly proportional to the
number of exponentiation as $\mathcal{G}(T)=aT+b$. As Equation 1, we denote
$\tau$ as the logarithmic value of T. We could get the following results from
a simple regression process.

$\mathcal{G}_{exp,2048}(\tau)=346.92\cdot 2^{\tau}+33432.08$ (5)

$\mathcal{G}_{exp,3072}(\tau)=780.83\cdot 2^{\tau}+37445.60$ (6)

###  5.2 Halving Cost

The halving cost of the arithmetic operations in the verification indicates
the gas usage for lines 5 – 13 in Algorithm 4. The modular exponentiation
operations in lines 8, 10, and 12 use the precompiled ModExp since its best
efficiency in the previous subsection. For simplicity, as we assumed
$T=2^{\tau}$, in this case, the if statement in line 9 is always false,
therefore line 10 is never executed. Hence, the gas usage will be clearly
proportional to the number of the repetition time, that is, $\tau-\delta$.

Figure 4: Experiment results of the halving repetition cost

(a) Gas usage of the halving algorithm ($\lambda=2048$)

(b) Gas usage of the halving algorithm ($\lambda=3072$)

The results of our experiments demonstrate the anticipated correlation. Figure
4(a) and Figure 4(b) display the gas cost of the repeated halving operations
with $\lambda=2048$ and $\lambda=3072$ correspondingly. The data exhibits a
clear linear relationship, allowing us to perform a regression analysis and
model the results using a linear function. By employing the method of least
squares approximation, we obtain the subsequent functions as Equation 7 and 8:

$\mathcal{G}_{halving,2048}(\tau)=165482.26\cdot\tau-155642.3$ (7)

$\mathcal{G}_{halving,3072}(x)=306089.32\cdot\tau-238572.65$ (8)

##  6 Cost-Effective Implementation

This section explains the implementation of a cost-efficient Pietrzak VDF
verifier as an Ethereum smart contract. In the beginning, we utilize the gas
cost outcomes obtained from the preceding sections to make theoretical
predictions for the optimized proof generating process. Secondly, we prove
that there exists a unique $\delta$ that minimizes the gas usage for VDF
verification, and this minimization is independent of $\tau$. In the end, we
compare the anticipated outcome based on theory with the actual results
obtained from the experiment.

###  6.1 Theoretical Analysis on Proof Generation for Gas Usage Optimization

The optimized proof generation in this research means minimizing the
verification gas cost. We can define the total gas cost function $g_{total}$
using the previous regression results.

$\mathcal{G}_{total}(\tau,\delta)=\mathcal{G}_{calldata}+\mathcal{G}_{halving}+\mathcal{G}_{exp}+C$
(9)

$=\big{(}\alpha\cdot(\tau-\delta)+c_{1}\big{)}+\big{(}\beta\cdot(\tau-\delta)+c_{2}\big{)}+\big{(}\gamma\cdot
2^{\delta}+c_{3}\big{)}+C$ (10)

$=(\alpha+\beta)(\tau-\delta)+\gamma\cdot 2^{\delta}+C^{\prime}$ (11)

Then, we get Theorem 1 says that there is a unique delta minimizing the total
gas cost.

######  Theorem 1.

The function $\mathcal{G}_{total}(\tau,\delta)$ has exactly one unique minimum
for $\delta$ when
$\tau>\delta=\log_{2}(\alpha+\beta)-\log_{2}(\ln{2}\cdot\gamma)$.

###### Proof.

Firstly, we calculate the partial derivative of $\mathcal{G}_{total}$ with
respect to $\delta$, which yields

$\frac{\partial\mathcal{G}_{total}}{\partial\delta}=\ln{2}\cdot\gamma\cdot
2^{\delta}-(\alpha+\beta).$

To show that there is a unique $\delta$ that minimizes $\mathcal{G}_{total}$,
we need to find where this derivative equals zero. This leads us to the
equation

$2^{\delta}=\frac{\alpha+\beta}{\ln{2}\cdot\gamma}.$

The function $2^{\delta}$ is strictly increasing. Hence, the equation
$2^{\delta}=\frac{\alpha+\beta}{\ln{2}\cdot\gamma}$ has a unique solution
$\delta$, which can be expressed as

$\delta=\log_{2}(\alpha+\beta)-\log_{2}(\ln{2}\cdot\gamma).$

This $\delta$ is where the first derivative equals zero.

Further, to confirm that this $\delta$ is indeed a minimum, we need to check
the second derivative. The monotonic nature of the exponential function in
this context implies that as $\delta$ increases, $\gamma\cdot 2^{\delta}$
grows without bounds, while decreasing $\delta$ below this point leads to
$\gamma\cdot 2^{\delta}$ becoming smaller than $\alpha+\beta$, thereby
confirming that the function is minimized at this $\delta$.

Thus, $\mathcal{G}_{total}(\tau,\delta)$ indeed has one unique minimum at
$\delta$ within the specified range of $\tau>\delta\geq 0$, completing the
proof. ∎

Also, we denote the minimizing $\delta$ as

$\delta_{m}=\arg\min_{\delta}\mathcal{G}_{total}(\tau,\delta).$ (12)

From Theorem 1, we can get the unique $\delta_{m}$ optimizing the gas cost.
Applying all the regression results in Equation 3, 4, 5, 6, 7, and 8, we get
the optimizing $\delta_{m}\approx 9.47$ for $\lambda=2048$ and
$\delta_{m}\approx 9.18$ for $\lambda=3072$ respectively. In practice,
$\delta$ for implementation must be an integer. Therefore, we can get the
practical integer $\delta$ with the following corollary.

######  Corollary 2.

Let $\delta_{m}$ be a real number, and let $\mathcal{G}(\tau,\delta)$ denote a
function in $\tau$ and $\delta$. Define
$\Delta=\delta_{m}-\lfloor\delta_{m}\rfloor$ as the fractional part of
$\delta_{m}$. Then, the relationship between
$\mathcal{G}(\tau,\lfloor\delta_{m}\rfloor)$ and
$\mathcal{G}(\tau,\lceil\delta_{m}\rceil)$ depends on $\Delta$ as follows:

  1. 1.

If $\Delta<-\log_{2}(\ln 2)$, then
$\mathcal{G}(\tau,\lfloor\delta_{m}\rfloor)<\mathcal{G}(\tau,\lceil\delta_{m}\rceil)$.

  2. 2.

If $\Delta=-\log_{2}(\ln 2)$, then
$\mathcal{G}(\tau,\lfloor\delta_{m}\rfloor)=\mathcal{G}(\tau,\lceil\delta_{m}\rceil)$.

  3. 3.

If $\Delta>-\log_{2}(\ln 2)$, then
$\mathcal{G}(\tau,\lfloor\delta_{m}\rfloor)>\mathcal{G}(\tau,\lceil\delta_{m}\rceil)$.

###### Proof.

Define

$f(\delta)=\mathcal{G}(\tau,\delta+1)-\mathcal{G}(\tau,\delta)=\gamma\cdot(2^{\delta+1}-2^{\delta})+(\alpha+\beta)(-(\delta+1)+\delta)=\gamma\cdot
2^{\delta}-(\alpha+\beta).$ (13)

Then, $f(\delta)=0$ when

$\delta=\log_{2}(\alpha+\beta)-\log_{2}\gamma.$ (14)

Also, as given $\gamma>0,\delta>0$

$\frac{df}{d\delta}=\ln 2\cdot\gamma\cdot 2^{\delta},$ (15)

$f$ is a monotone-increasing function in the boundary. Therefore, after the
point $\delta^{\prime}$ where

$\delta^{\prime}=\log_{2}(\alpha+\beta)-\log_{2}\gamma=\delta_{m}+\log_{2}(\ln
2),$ (16)

$f$ is bigger than 0.

For the 1st case of the lemma, $\Delta<-\log_{2}(\ln 2)$ implies

$f(\lfloor\delta_{m}\rfloor)>0.$ (17)

As the definition of $f$,

$\mathcal{G}(\tau,\lfloor\delta_{m}\rfloor)<\mathcal{G}(\tau,\lceil\delta_{m}\rceil).$
(18)

In the same way, we can get the other two cases. ∎

Since $\log_{2}(\ln 2)\approx-0.52$, the optimal integer value of $\delta$ is
9 for both $\lambda=2048$ and $3072$, as the 1st case of Corollary 2.

###  6.2 Optimized Verification Gas Cost

Figures 5(a) and 5(b) depict the total gas cost for Pietrzak VDF verification
at $\lambda=2048$ and $\lambda=3072$ respectively. Consistent with the
theoretical predictions in Theorem 1, the gas usage graph shows a decline to a
minimal point before increasing sharply. Optimal gas costs were observed at
$\delta=9$ for both configurations, aligning perfectly with the findings of
Corollary 2. This alignment between theoretical expectations and empirical
results confirms the accuracy of our model and highlights its potential for
optimizing Pietrzak VDF verification in blockchain applications.

Table 1 details the gas consumption and calldata sizes for the implemented
parameters, uniformly using $\delta=9$. Contrary to the previous expectation
of calldata sizes around 40KB [3], the sizes recorded were significantly
lower, ranging from 5.38 to 7.25 KB for $\lambda=2048$ and from 7.13 to 9.63
KB for $\lambda=3072$. Gas usage varied from 1.97 to 2.80 million for
$\lambda=2048$ and from 3.68 to 5.25 million for $\lambda=3072$. These
findings not only demonstrate the efficacy of our approach but also highlight
potential areas for further optimization in VDF implementations. Such
improvements could lead to significant cost reductions in blockchain networks,
enhancing the overall efficiency of cryptographic operations.

Figure 5: Experiment results for halving proof skipping parameter $\delta$
with $\tau=20,21,22,23,24,25$

(a) Skipping parts of halving proofs ($\lambda=2048$)

(b) Skipping parts of halving proofs ($\lambda=3072$)

Table 1: Implementation results based on the analysis $\lambda$ |  $\delta$ |  $\tau$ |  Gas used |  Calldata size (KB)
---|---|---|---|---
2048 |  9 |  20 |  1970844 |  5.38
|  |  21 |  2133372 |  5.75
|  |  22 |  2297629 |  6.13
|  |  23 |  2470594 |  6.50
|  |  24 |  2620907 |  6.89
|  |  25 |  2799805 |  7.25
3072 |  9 |  20 |  3680363 |  7.13
|  |  21 |  3967114 |  7.63
|  |  22 |  4318050 |  8.13
|  |  23 |  4614955 |  8.63
|  |  24 |  4947040 |  9.13
|  |  25 |  5254521 |  9.63

##  7 Discussion

This section discusses the implementation of VDFs on Ethereum, focusing on
programming choices for Ethereum’s Virtual Machine and their impact on gas
optimization. We introduce challenges associated with VDF deployment on
Ethereum’s Layer 1 due to high costs and explore Layer 2 solutions. The
discussion concludes with an analysis of economic factors critical for VDF
integration and sustainability on the blockchain.

###  7.1 Implementation Languages

There are main development languages in EVM-compatible network environments,
for example, Viper, Huff, Solidity, and Yul. For our implementation, which
requires dynamically adjusting proof lengths, we excluded Vyper due to its
inability to handle dynamic data structures efficiently. Instead, we chose
Solidity combined with Yul, leveraging Solidity for its comprehensive features
and developer familiarity, and Yul for its superior gas optimization
capabilities. This combination provides a balance between high-level language
safety and low-level control over the Ethereum Virtual Machine.

Considering future enhancements, we are exploring Huff, noted for its
exceptional gas efficiency and direct control over the EVM. Huff originated
from the Aztec team where contracts needed extreme efficiency, even more than
what Yul could provide. Although Huff offers significant optimization
opportunities, it lacks the built-in safety checks of higher-level languages,
raising the implementation complexity. Nevertheless, given our
implementation’s emphasis on gas optimization, the benefits of adopting Huff
justify its consideration for future development.

###  7.2 Practicality of VDF on EVM

Implementing VDFs on Ethereum’s Layer 1 presents significant challenges
primarily due to high gas costs and the computational intensity required. Our
detailed optimization trials reveal that despite employing cutting-edge
optimization techniques, verifying a Pietrzak VDF on Layer 1 still demands at
least one million gas units. This high resource consumption makes VDF
applications impractical for widespread use on Ethereum’s primary network,
especially for operations requiring frequent and repetitive VDF verifications.
The economic implications of these requirements can stifle innovation and
discourage developers from incorporating VDFs into their decentralized
applications, limiting the exploration of potentially valuable use cases such
as randomized governance protocols or secure public randomness in blockchain
networks.

However, the emergence of Layer 2 solutions, such as optimistic rollups and
zkRollups, offers a promising alternative for leveraging VDFs within the
Ethereum ecosystem. These technologies provide a secondary processing layer
that can handle complex computations off the main Ethereum chain, thereby
significantly reducing gas costs and improving transaction throughput.
Platforms like Optimism capitalize on these advantages, offering gas prices
that are often thousands of times cheaper than those on Layer 1. This dramatic
cost reduction opens up new possibilities for using VDFs on Ethereum, allowing
for more frequent and economically viable implementations. Layer 2 solutions
not only mitigate the high cost barriers associated with Layer 1 but also
broaden the scope for adopting VDFs in a variety of applications, thus
encouraging further development and research into this promising area of
blockchain technology.

###  7.3 Lack of Economic VDF Protocols in Ethereum

The integration of VDFs into smart contracts holds great promise for enhancing
blockchain security and reliability. However, beyond the technical challenges,
there exists a substantial hurdle in the lack of a robust economic model
specifically designed to support the unique operational needs of VDFs, such as
incentivizing both provers and verifiers and managing commit-reveal-recover
protocols. The absence of such an economic framework complicates the practical
deployment of VDFs as it does not adequately address compensation for
participants who dedicate substantial computational resources to generate and
verify proofs. This gap can deter the participation of potential contributors,
ultimately hindering the scalability and effectiveness of VDFs in real-world
blockchain applications.

Moreover, considering the decentralized essence of blockchain technology, it
is crucial that any protocol, especially those as intricate as VDFs, is
underpinned by an economic strategy that not only supports technical execution
but also ensures economic sustainability without the need for central
governance. This calls for innovative research into economic models that are
specifically tailored to the decentralized context of blockchain networks.
These models need to effectively balance incentives and deterrence, fostering
a system where honest participation is rewarded while dishonest behavior is
penalized. Such economic strategies are vital for maintaining the integrity
and fairness of the blockchain ecosystem, ensuring that VDFs are not only
technically feasible but also economically viable and beneficial to all
participants, thereby aligning with the overarching principles of
decentralization and trust minimization in blockchain systems.

###  7.4 Future Works on a General Environment

Through this research, we investigated the efficient implementation of
Pietrzak VDF verification within the Ethereum Virtual Machine (EVM)
environment and observed results that align both theoretically and
experimentally. During our study, we identified significant effects of
generalized proof generation and verification, which were also included within
the predictable realms of theoretical analysis. We anticipate that such an
approach could be applicable not only within the EVM but also in more general
computing environments. Although resource pricing in general systems would
differ from the gas costs in the EVM, with elements like the repetition of
halving protocols and resource consumption proportional to the proof length
being predictable, the costs of exponentiation in VDF ($x^{2^{2^{\tau}}}$) are
expected to be exponential. Therefore, based on the outcomes of this study,
further research on optimizing Pietrzak VDFs in general computing environments
appears reasonable.

##  8 Conclusion

In conclusion, our research has successfully demonstrated the feasibility and
significance of implementing VDFs within blockchain environments, particularly
through smart contracts in Ethereum. By focusing on the Pietrzak VDF
construction, we have not only bridged a crucial gap in the academic studies
of VDFs but also highlighted their practical utility in enhancing the security
and efficiency of blockchain applications. Contrary to previous expectations,
our work represents the first academic result in the cost-effective on-chain
verification of the Pietrzak VDF, showing significant potential in ensuring
cryptographically secure random number generation across various blockchain
applications. Through strategic implementation, we have achieved substantial
cost reductions, making the Pietrzak VDF more accessible and applicable. This
research opens new avenues for the integration of VDFs in blockchain systems,
promising to enhance security, fairness, and functionality in the evolving
distributed ledger technologies.

## References

  * [1] K. Pietrzak, “Simple verifiable delay functions,” in 10th innovations in theoretical computer science conference (itcs 2019), Schloss-Dagstuhl-Leibniz Zentrum für Informatik, 2019.
  * [2] B. Wesolowski, “Efficient verifiable delay functions,” in Advances in Cryptology–EUROCRYPT 2019: 38th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Darmstadt, Germany, May 19–23, 2019, Proceedings, Part III 38, pp. 379–407, Springer, 2019.
  * [3] V. Attias, L. Vigneri, and V. Dimitrov, “Implementation study of two verifiable delay functions,” Cryptology ePrint Archive, 2020.
  * [4] D. Boneh, J. Bonneau, B. Bünz, and B. Fisch, “Verifiable delay functions,” in Annual international cryptology conference, pp. 757–788, Springer, 2018.
  * [5] R. L. Rivest, A. Shamir, and D. A. Wagner, “Time-lock puzzles and timed-release crypto,” 1996.
  * [6] D. Boneh, B. Bünz, and B. Fisch, “A survey of two verifiable delay functions,” Cryptology ePrint Archive, 2018.
  * [7] K. Choi, A. Arun, N. Tyagi, and J. Bonneau, “Bicorn: An optimistically efficient distributed randomness beacon,” in Financial Cryptography and Data Security: 27th International Conference, FC 2023, Bol, Brač, Croatia, May 1–5, 2023, Revised Selected Papers, Part I, (Berlin, Heidelberg), p. 235–251, Springer-Verlag, 2023.
  * [8] G. Wood, “Ethereum: A secure decentralised generalised transaction ledger eip-150 revision (705168a - 2024-03-04),” 2017.  Accessed: 2024-05-10.
  * [9] firo, “Full bignumber library implementation for solidity.” https://github.com/firoorg/solidity-BigNumber, 2024.  Accessed: 2024-05-10.
  * [10] A. Akhunov, E. Ben Sasson, T. Brand, L. Guthmann, and A. Levy, “Eip-2028: Transaction data gas cost reduction.” Ethereum Improvement Proposals, 2019.  Accessed: 2024-05-10.
  * [11] A. J. Menezes, P. C. Van Oorschot, and S. A. Vanstone, Handbook of applied cryptography.  CRC press, 2018.
  * [12] V. S. Dimitrov, G. A. Jullien, and W. C. Miller, “Complexity and fast algorithms for multiexponentiations,” IEEE Transactions on Computers, vol. 49, no. 2, pp. 141–147, 2000.
  * [13] C. K. Koc, “High-speed rsa implementation,” tech. rep., Technical Report TR-201, RSA Laboratories, 1994.
  * [14] V. Buterin, “Eip-198: Big integer modular exponentiation.” Ethereum Improvement Proposals, 2017.  Accessed: 2024-05-10.
  * [15] K. Olson, S. Gulley, S. Peffers, J. Drake, and D. Feist, “Eip-2565: Modexp gas cost.” Ethereum Improvement Proposals, 2020.  Accessed: 2024-05-10.


# CME Deflection and East-West Asymmetry of Energetic Storm Particle Intensity
during Solar Cycles 23 and 24

A. Santa Fe Dueñas Space Science and Engineering Division, Southwest Research
Institute, San Antonio, TX 78228, USA  R. W. Ebert Space Science and
Engineering Division, Southwest Research Institute, San Antonio, TX 78228, USA
Department of Physics and Astronomy, University of Texas at San Antonio, San
Antonio, TX, USA  Gang Li Department of Space Science and CSPAR, University of
Alabama in Huntsville, Huntsville, AL 35805, USA  Zheyi Ding Centre for
Mathematical Plasma Astrophysics, KU Leuven, 3001 Leuven, Belgium  M. A. Dayeh
Space Science and Engineering Division, Southwest Research Institute, San
Antonio, TX 78228, USA  Department of Physics and Astronomy, University of
Texas at San Antonio, San Antonio, TX, USA  M. I. Desai Space Science and
Engineering Division, Southwest Research Institute, San Antonio, TX 78228, USA
Department of Physics and Astronomy, University of Texas at San Antonio, San
Antonio, TX, USA  L. K. Jian Heliophysics Science Division, NASA Goddard Space
Flight Center, Greenbelt, MD 20771, USA

###### Abstract

We investigate the East-West asymmetry in energetic storm particle (ESP) heavy
ion intensities at interplanetary shocks driven by coronal mass ejections
(CMEs) during solar cycles (SCs) 23 and 24. We use observations from NASA’s
ACE and STEREO missions of helium (He), oxygen (O), and iron (Fe) intensities
from $\sim$0.13 to 3 MeV/nucleon. We examine the longitudinal distribution of
ESP intensities and the correlation of ESP intensities with the near-Sun CME
speed and the average transit CME speed for eastern and western events. We
observed an East-West asymmetry reversal of ESP heavy ion intensities from SC
23 to 24. We have determined that this change in asymmetry is caused by a
shift in the heliolongitude distribution of the CME speed ratio (the ratio of
CME near-Sun speed to CME average transit speed) from west to east.

Energetic Particle, Heavy ions, Peak intensities, CME, Solar Cycle

##  1 Introduction

There are two classes of Solar Energetic Particle (SEP) events: impulsive SEP
events associated with impulsive X-ray solar flares and gradual SEP events
accelerated by Coronal Mass Ejections (CME) driven shocks (Reames, 2013). The
enhancement of the intensity of energetic particles during the passage of the
interplanetary (IP) shock in SEP events is known as an Energetic Storm
Particle (ESP) event (Bryant et al., 1962). Figure 1 shows an example ESP
event observed by the STEREO-A spacecraft. The sudden increase in the solar
wind speed and the magnetic field, shown in the third and fourth rows,
indicates the arrival of the IP shock, whereas the rise in the Helium (He)
intensities at about the shock arrival time is the ESP event.

Figure 1: An example of an ESP event observed by STA at one au on November 10
and 11, 2012. The first panel shows the Helium (He) time-intensity profiles
(0.137 - 3.090 MeV/n), the second panel shows the He spectral index from
$\sim$ 0.1-3 MeV/nucleon, the solar wind speed is shown in the third panel,
and the fourth panel shows the magnetic field strength. The blue vertical
lines denote the shock arrival time. The orange line in the spectral index
panel is the running average of a 21-sample window. To identify the peak
intensity values, a time window is defined by the green vertical lines, which
set the limits of the time range to be considered.

The properties of ESP events depend on the spacecraft (s/c) position along the
IP shock, the shock properties, and the upstream conditions. For instance,
Desai et al. (2003) and Dayeh et al. (2009) found a correlation of ESP
properties with the upstream seed particle population. Cane et al. (1988)
showed how the intensity–time profiles of solar proton events depend on the
longitude of the observing s/c relative to the location of solar flare. Mäkelä
et al. (2011), Reames (2012), and Lario et al. (2023) found that ESP
intensities have a strong correlation with the CME and IP shock speeds. Santa
Fe Dueñas et al. (2022) and Lario et al. (2023) showed correlations of the
peak intensities of ESP events with the observing s/c heliolongitude and the
CME average transit speed. ESP properties are also affected by the strength of
the solar cycle (SC, Santa Fe Dueñas et al., 2023). In addition, Santa Fe
Dueñas et al. (2022) showed that the ratio of the CME average transit speed to
the CME near-Sun speed correlates with the observing s/c heliolongitude. By
combining this correlation and the correlation of the ESP peak intensities to
the CME average transit speed, the authors obtained an empirical equation that
relates the ESP peak intensities and spectral index to the CME near-Sun speed
and the observing s/c heliolongitude. However, this heliolongitude
distribution of ESP peak intensities shown in Santa Fe Dueñas et al. (2022) is
asymmetric, with eastern ESP events having slightly higher intensities than
western events. According to Ding et al. (2022), the difference in fluence and
peak flux between the East and West during entire Solar Energetic Particle
(SEP) events is caused by the time-extended shock acceleration and the
geometry of Parker field lines. On the other hand, Ding et al. (2023) suggest
that the asymmetry in ESP events is due to the injection efficiency of seed
populations, which depends on the shock geometry. Both studies propose that
Eastern events have higher intensities than Western events, resulting from
combining these two effects. In this study, we want to determine if the East-
West asymmetry in ESP properties is consistent between SC 23 and the
relatively weaker SC 24. Specifically, we compare heavy ion (He, O, and Fe)
intensities from ESP events observed during these two SCs and their dependence
on the CME near-Sun and average transit speeds, and the parent flare
longitude.

##  2 Observations

We use data from instruments on board NASA’s Advanced Composition Explorer
(ACE; Stone et al., 1998) and Solar Terrestrial Relations Observatory (STEREO;
Kaiser et al., 2008) missions. ACE is located at the Sun-Earth L1 Lagrange
Point. STEREO consists of two spacecraft, each drifting apart from Earth in
opposite directions at about 22° per year, where STEREO-A (STA) orbits ahead
of Earth and STEREO-B (STB) behind. Communication with STB was lost in October
2014.

We surveyed energetic helium (He), oxygen (O), and iron (Fe) ion observations
with energies ranging from 0.1 to 3 MeV/nucleon using the Ultra-Low Energy
Isotope Spectrometer (ULEIS) on ACE spacecraft during SC 23 ESP events between
August 1998 and December 2006. Additionally, we surveyed the same type of
observations using Suprathermal Ion Telescope (SIT) on STA and STB and ULEIS
on ACE during SC 24 events between January 2009 and December 2019. Several
multi-s/c studies have described the inter-calibration process of these
instruments (e.g. Müller-Mellin et al., 2008; Dresing et al., 2009; Cohen &
Mewaldt, 2018). We use the solar wind plasma and magnetic field instruments on
STA and STB (PLASTIC; Galvin et al. (2008) and MAG; Acuña et al. (2008)) and
ACE (SWEPAM; McComas et al. (1998) and MAG; Smith et al. (1998)) to detect and
analyze interplanetary (IP) shocks and their properties. We also examine the
solar wind conditions upstream and downstream of these structures. CME speeds
near the Sun and parent flare location are obtained from estimates reported in
Gopalswamy et al. (2010) for SC 23 events and from the Space Weather Database
of Notifications, Knowledge, and Information
(DONKI111https://kauai.ccmc.gsfc.nasa.gov/DONKI/) for SC 24 events, while the
CME average transit speeds to 1 au are estimated from the transit time of the
event.

###  2.1 ESP event selection

We analyzed the list of events from previous studies (Santa Fe Dueñas et al.,
2022, 2023), where we visually inspected the plots of the events. We selected
the events where the energetic particle intensity profiles exhibited a
synchronized increase of at least 200% within $\pm$3 hours of the shock
arrival time in the He, O, and Fe intensities at each energy bin (10 bins for
He, 11 bins for O, and 11 bins for Fe) between 0.1 - 3 MeV/nucleon. We also
ensured no other dominant shocks were present within a 1-day window.

##  3 Results

The number of ESP events detected by ACE decreased during the weaker SC 24
compared to the stronger SC 23. However, including ESP events from the STEREO
mission, which fortunately began operating during this period, improved the
statistics for SC 24. As a result, 76 events from SC 23 and 94 events from SC
24 were selected. The histogram in Figure 2 shows the distribution of ESP
events during SC 23 (left) and SC 24 (right) as a function of the spacecraft-
flare angle $\phi$ from Santa Fe Dueñas et al. (2022). In this context, the
CME solar source location is approximated by the solar flare location for each
event (Ontiveros & Vourlidas, 2009). The distribution shows a mean helio-
longitude of 5.2 $\pm$ 4.5°for SC 23 ESP events, whereas for SC 24, the mean
helio-longitude is 1.8 $\pm$ 3.7°. Similar results have been shown by Santa Fe
Dueñas et al. (2022) and Lario et al. (2023). We have categorized the ESP
events into three groups based on their spacecraft-flare angle $\phi$. The
Eastern events are those where $\phi\leq-20\degree$, which are shown within
the purple shadow region in the figure. The Central events are those where
$-20\degree<\phi<20\degree$. The Western events are those where $\phi\geq
20\degree$, which are shown within the green shadow region in the figure.

During SC 23, there were 22 Western ESP events and 13 Eastern ESP events. In
SC 24, there were 27 Western ESP events and 27 Eastern ESP events.

Figure 2: Helio-longitude distributions of ESP events observed during SC 23
(left) and SC 24 (right). The events are grouped in bins of 20 degrees. The SC
24 ESP events include STA (red), STB (blue), and ACE (green) observations,
whereas SC 23 includes only events from ACE. The mean spacecraft-flare angle
is shown with a black solid line.

Using the methodology from Santa Fe Dueñas et al. (2022), we calculate the
average transit speed of each CME event using the formula
$\bar{V}_{T}=R/(t_{1au}-t_{R_{Sun}})$, where $R$ stands for the distance
between the Sun and the observing s/c, $t_{1au}$ is the shock arrival time at
the observing s/c (which is about one au away from the Sun), and $t_{R_{Sun}}$
is the CME onset time observed on the Sun by LASCO/C2 at about 1.5 $R_{Sun}$.
We calculated the ratio between the average transit speed of CMEs and their
near-Sun speeds for ESP events, expressed as $CME\ Speed\
Ratio=\bar{V}_{T}/V_{i}$. We also analyzed its heliolongitudinal distribution.

Figure 3: CME speed ratio (CME average transit speed/ CME near-Sun speed)
versus spacecraft-flare angle of ESP events observed during SCs 23 (blue) and
24 (orange).

Figure 3 displays the $CME\ Speed\ Ratio$ in relation to the angle between the
spacecraft and the flare for ESP events observed during SCs 23 (blue) and 24
(orange). The plot compares the near-Sun speed of a CME at 21.5 $R_{Sun}$ to
its average transit speed at different longitudes for each solar cycle. In SC
23, for example, at 15°, the CME average transit speed is, on average,
$\sim$90% of the estimated value at $\sim$21.5 $R_{Sun}$; whereas at -50° it
is $\sim$60%. The events of each SC were divided into six bins, and each bin’s
mean and standard errors are shown as triangles and crosses, respectively. The
mean values of the bins were used to fit the following equation:

$CME\ Speed\ Ratio(\phi)=V_{0}cos(\phi-\phi_{0})+V_{1},$ (1)

Here, $V_{0}$ represents the cosine amplitude of 0.42±0.114 and 0.42±0.012 for
SC 23 and SC 24 events, respectively. $\phi$ represents the longitude between
the observer and the CME solar source, while $\phi_{0}$ represents the offset
longitude of the shock front nose and is -17.00±6.48°and 3.01±0.99° for SC 23
and SC 24 events respectively. Lastly, $V_{1}$ is an offset fitting constant
of -0.44±0.095 and -0.54±0.008 for SC 23 and SC 24 events, respectively. Fits
to individual data points yield similar results. SC 23 events generally have a
higher speed ratio than SC 24 events along the longitudinal distribution.
However, it’s important to note that the eastern events display a similar
speed ratio longitude distribution during both SCs. Meanwhile, the western
events show a significant difference, with SC 23 events having a higher speed
ratio than SC 24 events. It is noteworthy that the CME speed ratio shown in
Figure 3 is correlated to the number of Eastern and Western ESP events
displayed in Figure 2. During SC 23, Western events are more dominant than
Eastern events, but during SC 24, the number of Eastern and Western events is
similar. It is also important to note that some of the speed ratios of SC 23
CME are greater than 1. There could be various reasons, such as slow CMEs
accelerated by a faster solar wind, plane-of-sky projection effects, or an
error in the near-Sun CME speed estimate. Estimating these speeds during SC 23
was more challenging due to the lack of longitudinally separated observing s/c
than during SC 24.

Figure 4: Average angular deflection and deceleration of the driving CMEs of
ESP events observed during SCs 23 (blue) and 24 (orange).

Our analysis shows a change in the deflection of CME events from approximately
17 degrees west during SC 23 to around 3 degrees east during SC 24, as
depicted in Figures 3 and 4. We also observed a significant increase in the
deceleration of SC 24 CME events from Figure 3. These findings suggest that
physical mechanisms may be involved in these changes, which have been
discussed in studies such as Wang et al. (2004) and Jian et al. (2018).
Further investigation is necessary to understand the implications of these
discoveries fully.

For each ESP event, we identified the intensity peak value between a $\pm
3$-hr window for each energy bin in the range from $\sim$ 0.1 - 3 MeV/nucleon
for He, O, and Fe energetic ions. Figures 6 and 7 show the peak intensity at
$\sim 0.5$, $\sim 1.1$ and $\sim 1.5$ MeV nucleon-1 of He-ion ESP events
observed during SCs 23 (top panel) and 24 (bottom panel) versus the CME near-
Sun and average transit speeds, respectively. Eastern events (in magenta) and
Western events (in green) are shown with their fit lines.

During SC 23 ESP events, the peak intensities of western ESP events shown in
Figure 6 are approximately five times higher than those in the east in all
three energy bins. However, during SC 24, this feature is not observed; in
fact, Eastern events generally have similar (slightly higher) peak intensity
to Western events.

In Figure 7, it is noticeable that the fit lines of SC 23 Eastern events have
a steeper slope compared to those of Western events. However, for SC 24 ESP
events, a contradictory trend is observed. On the other hand, a study
conducted by Ding et al. (2023) reveals that when combining SC 23 and SC 24
events, Eastern ESP events exhibit slightly higher intensities than Western
events based on their CME transit speed.

Figure 5: Distribution of CME average transit speeds in Eastern (purple) and
Western (green) ESP events during SCs 23 (left) and 24 (right). Figure 6: Peak
intensity of He ion ESP observations versus CME near-Sun speed at $0.546$
MeV/n (left column), $1.093$ MeV/n (middle column) and $1.545$ MeV/n (right
column) during SCs 23 (top panel) and 24 (bottom panel). The magenta dots and
lines represent Eastern events and fit, respectively, while the green dots and
lines represent the same for Western events. Figure 7: Peak intensity of He
ion ESP observations versus CME average transit speed at $0.546$ MeV/n (left
column), $1.093$ MeV/n (middle column) and $1.545$ MeV/n (right column) during
SCs 23 (top panel) and 24 (bottom panel). The magenta dots and lines represent
Eastern events and fit, respectively, while the green dots and lines represent
the same for Western events. Figure 8: Peak intensity of He ion ESP
observations versus CME near-Sun speed at $0.546$ MeV/n (left column), $1.093$
MeV/n (middle column) and $1.545$ MeV/n (right column) during SCs 23 and 24.
All events of both SCs are shown in the first row. Eastern
($\phi<=-20\degree$), central ($-20\degree<\phi<20\degree$), and Western
($\phi>=20\degree$) events are shown in rows 2, 3, and 4, respectively. Blue
(orange) dots and lines denote SC 23 (SC 24) observations and fits,
respectively. Figure 9: Peak intensity of He ion ESP observations versus CME
average transit speed at $0.546$ MeV/n (left column), $1.093$ MeV/n (middle
column) and $1.545$ MeV/n (right column) during SCs 23 and 24. All events of
both SCs are displayed in the first row. Eastern ($\phi<=-20\degree$), central
($-20\degree<\phi<20\degree$), and Western ($\phi>=20\degree$) events are
shown in rows 2, 3, and 4, respectively. The blue dots and lines represent the
SC 23 observations and fits, respectively, while the orange dots and lines
represent the same for SC 24.

Figure 6 indicates a reversal in the east-west asymmetry of the ESP peak
intensity versus the near-Sun CME speed distribution. Additionally, Figure 7
suggests that the trend of the slopes of the peak intensity versus the CME
average transit speed has also reversed. Thus, in SC 23, the intensity of
Western events was higher in Figure 6, and they had faster CME transit speeds
compared to Eastern events in Figures 3 and 5. However, the scenario was
reversed in SC 24, where Eastern events had higher intensities and faster CME
transit speeds than Western events.

Figures 8 and 9 compare the peak intensities of each heliolongitude group
(Eastern, Central, and Western) during both SCs with respect to their CME
near-Sun and average transit speeds, respectively. The figures help illustrate
the variations in east-west peak intensity and their respective relationship
with the CME near-Sun and average transit speeds.

The plot in Figure 8 illustrates the peak intensity of He-ion ESP events at
around 0.5, 1.1, and 1.5 MeV nucleon-1 for SCs 23 (blue) and 24 (orange) in
relation to the CME speed near the Sun. The top row displays all the events
for both SCs, while the second, third, and fourth rows show eastern, central,
and western events, respectively. In general, the fits (blue and orange lines)
for all events show higher intensities in SC 23 events than for SC 24. The
same is true across all three energy ranges of He ions, similar to O and Fe
(not shown).

Figure 9 shows the peak intensity at $\sim 0.5$, $\sim 1.1$ and $\sim 1.5$ MeV
nucleon-1 of He-ion ESP events observed during SCs 23 (blue) and 24 (orange)
versus the CME average transit speed. The top row shows that all the events’
fit (blue and orange lines) are steeper for SC 24 than for SC 23 events, as
reported by Santa Fe Dueñas et al. (2023). However, the slope and y-intercept
values of Eastern events in both SCs are more similar than those of Central
and Western events. Western events in SC 24 have steeper fit lines than SC 23.

We point out that a direct correlation exists between the speed ratio of CMEs
for the Eastern, Central, and Western clusters of ESP events, their respective
peak intensities, and the CME near-Sun and average transit speeds. The Eastern
ESP events of both SCs display a degree of similarity in various aspects.
Figure 3 indicates that the Eastern CME speed ratio heliolongitude
distributions are similar in both SCs. Similarly, Figures 8 and 9 demonstrate
that the Eastern peak intensities exhibit comparable patterns for high-speed
ESP events. The analysis of the Western ESP events reveals that SC 23 events
exhibit a higher CME speed ratio than SC 24 events, as demonstrated in Figure
3. Similarly, the peak intensities of SC 23 events are higher than those of SC
24, as illustrated in Figures 8. Furthermore, Figures 9 indicate that SC 23
events demonstrate higher CME average transit speeds than SC 24 events. In
other words, the steeper slope of the Western ESP events of SC 24 shown in
Figure 9 can be explained by their stronger deceleration compared to SC 23
events as shown in Figure 3.

##  4 Discussion

ESP events profoundly impact space weather and pose a significant threat to
space-based technologies (Barth et al., 2003). As such, a comprehensive
investigation is paramount to fully comprehend the underlying mechanisms that
drive these events (Cucinotta et al., 2010). It has been suggested that the
differences in peak intensities of ESP events between the east and west could
be influenced by the characteristics of the IP CME shock and the ambient
conditions (Sarris & Krimigis, 1985). Ding et al. (2023) shows the peak
intensity at the eastern flank of CME shock is generally larger than the one
at the western flank. However, our results reveal a reversal of the east-west
asymmetry in the intensity of ESP peak events from SC 23 to SC 24. It
highlights the need for further research to understand better the complex
dynamics of ESP events and their relationship to solar activity.

Our analysis found that the distribution of CME speed ratio with respect to
observing s/c heliolongitude (Figure 3) plays a crucial role in the east-west
asymmetry of the intensities of ESP events. Based on the distribution, it is
observed that the average CME during SC 23 would deflect from the western
heliosphere with an angle of $\sim 17\pm 6\degree$ towards Earth. On the other
hand, for SC 24, the CME would deflect from the eastern heliosphere with an
angle of $\sim 3\pm 1\degree$. Additionally, during SC 23, on average, the
nose shock-front of a CME had a transit speed of roughly $90\%$ of its initial
speed near the Sun, and experienced weaker deceleration on both flanks.
However, for SC 24, the nose shock-front of the average CME had an average
transit speed of approximately $75\%$ of its initial speed near the Sun,
experiencing stronger deceleration on both flanks. These observations support
the hypothesis that weak CMEs are deflected to the west and fast CMEs to the
east by the Parker spiral, as proposed by Wang et al. (2004), and that SC 24
energetic particle events were weaker than those of SC 23, as reported by Jian
et al. (2018).

The variations in the speed evolution and deflection of CME events during SCs
23 and 24 have led to notable differences in the speed ratios of Eastern and
Western events, as shown in Figure 3. Specifically, it has been observed that
the Eastern events had comparable speed ratios in both cycles. However, the
Western events of SC 23 exhibited higher speed ratios than those of SC 24. As
a result, the peak intensities distributions in relation to the CME average
transit speed are similar for Eastern ESP events during both SCs, as shown in
Figure 9. Meanwhile, for Western events, SC 23 events had higher peak
intensities in relation to the CME near-Sun speed than SC 24, as shown in
Figure 8.. In addition, the more substantial deceleration of Western SC 24
events depicted in Figure 3 is also represented in Figure 9 by the steeper
slopes of their fitting lines compared to Western SC 23 events.

The results indicate that the primary factor responsible for the reversal of
the east-west asymmetry in the intensity of ESP events between SC 23 and 24 is
the shift in the peak of the CME speed ratio heliolongitude distribution from
$\sim 17\pm 6\degree$ to $\sim-3\pm 1\degree$, as illustrated in Figures 3 and
4. This finding suggests that the shift in the peak of the CME speed ratio is
a crucial determinant of the reversal of the asymmetry. It is essential to
conduct further research to determine whether the variable behavior of CME
events during different solar cycles is influenced by the reversal of magnetic
fields (Gopalswamy et al., 2003), the strength of the solar cycle (Santa Fe
Dueñas et al., 2023), the strength of the interplanetary magnetic field (Jian
et al., 2018), the CME interchange reconnection (Winslow et al., 2023) or
other underlying mechanisms. This is especially important due to the
significant impact that CMEs have on space weather, particularly on space
assets and astronauts.

In conclusion, our study has found that there has been a reversal of the east-
west asymmetry in the intensity of ESP events from SC 23 to SC 24. We have
also discovered that the primary reason for this asymmetry reversal is the
heliolongitude shift of the peak of the distribution of the CME speed ratio
from west to east. However, more research is necessary to understand the
mechanisms underlying this heliolongitude shift.

## Acknowledgements

Work at SwRI was supported by NASA grants NNX17AI17G, 80NSSC23K0975 and
80NSSC23K1470. LKJ was supported by NASA’s STEREO mission and HGI Grant
80NSSC23K044. We would like to express our gratitude to the teams behind
STEREO/SIT, PLASTIC, MAG, ACE/ULEIS, SIS, SWEPAM, and MAG for generously
providing their data for public use. We thank NASA’s Community Coordinated
Modeling Center for making the WSA-ENLIL simulations publicly available
through the Space Weather Database of Notifications, Knowledge, Information
(DONKI).

## References

  * Acuña et al. (2008) Acuña, M. H., Curtis, D., Scheifele, J. L., et al. 2008, Space Science Reviews, 136, 203, doi: 10.1007/s11214-007-9259-2
  * Barth et al. (2003) Barth, J., Dyer, C., & Stassinopoulos, E. 2003, IEEE Transactions on Nuclear Science, 50, 466, doi: 10.1109/TNS.2003.813131
  * Bryant et al. (1962) Bryant, D. A., Cline, T. L., Desai, U. D., & McDonald, F. B. 1962, Journal of Geophysical Research (1896-1977), 67, 4983, doi: 10.1029/JZ067i013p04983
  * Cane et al. (1988) Cane, H. V., Reames, D. V., & von Rosenvinge, T. T. 1988, Journal of Geophysical Research: Space Physics, 93, 9555, doi: 10.1029/JA093iA09p09555
  * Cohen & Mewaldt (2018) Cohen, C. M. S., & Mewaldt, R. A. 2018, Space Weather, 16, 1616, doi: 10.1029/2018SW002006
  * Cucinotta et al. (2010) Cucinotta, F. A., Hu, S., Schwadron, N. A., et al. 2010, Space Weather, 8, doi: https://doi.org/10.1029/2010SW000572
  * Dayeh et al. (2009) Dayeh, M. A., Desai, M. I., Dwyer, J. R., et al. 2009, The Astrophysical Journal, 693, 1588, doi: 10.1088/0004-637x/693/2/1588
  * Desai et al. (2003) Desai, M. I., Mason, G. M., Dwyer, J. R., et al. 2003, The Astrophysical Journal, 588, 1149, doi: 10.1086/374310
  * Ding et al. (2023) Ding, Z., Li, G., Santa Fe Dueñas, A., et al. 2023, Journal of Geophysical Research: Space Physics, 128, e2023JA031502, doi: https://doi.org/10.1029/2023JA031502
  * Ding et al. (2022) Ding, Z., Li, G., Ebert, R. W., et al. 2022, Journal of Geophysical Research: Space Physics, 127, doi: 10.1029/2022JA030343
  * Dresing et al. (2009) Dresing, N., Gómez-Herrero, R., Heber, B., et al. 2009, Solar Physics, 256, 409, doi: 10.1007/s11207-009-9356-3
  * Galvin et al. (2008) Galvin, A. B., Kistler, L. M., Popecki, M. A., et al. 2008, Space Science Reviews, 136, 437, doi: 10.1007/s11214-007-9296-x
  * Gopalswamy et al. (2003) Gopalswamy, N., Lara, A., Yashiro, S., & Howard, R. A. 2003, The Astrophysical Journal, 598, L63, doi: 10.1086/380430
  * Gopalswamy et al. (2010) Gopalswamy, N., Xie, H., Mäkelä, P., et al. 2010, The Astrophysical Journal, 710, 1111, doi: 10.1088/0004-637X/710/2/1111
  * Jian et al. (2018) Jian, L. K., Russell, C. T., Luhmann, J. G., & Galvin, A. B. 2018, The Astrophysical Journal, 855, 114, doi: 10.3847/1538-4357/aab189
  * Kaiser et al. (2008) Kaiser, M. L., Kucera, T. A., Davila, J. M., et al. 2008, Space Science Reviews, 136, 5, doi: 10.1007/s11214-007-9277-0
  * Lario et al. (2023) Lario, D., Richardson, I. G., Aran, A., & Wijsen, N. 2023, The Astrophysical Journal, 950, 89, doi: 10.3847/1538-4357/acc9c5
  * Mäkelä et al. (2011) Mäkelä, P., Gopalswamy, N., Akiyama, S., Xie, H., & Yashiro, S. 2011, Journal of Geophysical Research: Space Physics, 116, doi: 10.1029/2011JA016683
  * McComas et al. (1998) McComas, D. J., Bame, S. J., Barker, P., et al. 1998, Space Science Reviews, 86, 563, doi: 10.1023/A:1005040232597
  * Müller-Mellin et al. (2008) Müller-Mellin, R., Böttcher, S., Falenski, J., et al. 2008, The Solar Electron and Proton Telescope for the STEREO Mission, ed. C. T. Russell (New York, NY: Springer New York), 363–389, doi: 10.1007/978-0-387-09649-0_13
  * Ontiveros & Vourlidas (2009) Ontiveros, V., & Vourlidas, A. 2009, The Astrophysical Journal, 693, 267, doi: 10.1088/0004-637X/693/1/267
  * Reames (2012) Reames, D. V. 2012, The Astrophysical Journal, 757, 93, doi: 10.1088/0004-637x/757/1/93
  * Reames (2013) —. 2013, Space Science Reviews, 175, 53, doi: 10.1007/s11214-013-9958-9
  * Santa Fe Dueñas et al. (2023) Santa Fe Dueñas, A., Ebert, R. W., Dayeh, M. A., et al. 2023, The Astrophysical Journal, 953, 176, doi: 10.3847/1538-4357/acdede
  * Santa Fe Dueñas et al. (2022) —. 2022, The Astrophysical Journal, 935, 32, doi: 10.3847/1538-4357/ac73f5
  * Sarris & Krimigis (1985) Sarris, E. T., & Krimigis, S. M. 1985, Solar Physics, 96, 413, doi: 10.1007/BF00149694
  * Smith et al. (1998) Smith, C. W., L’Heureux, J., Ness, N. F., et al. 1998, Space Science Reviews, 86, 613, doi: 10.1023/A:1005092216668
  * Stone et al. (1998) Stone, E. C., Frandsen, A. M., Mewaldt, R. A., et al. 1998, Space Science Reviews, 86, 1, doi: 10.1023/A:1005082526237
  * Wang et al. (2004) Wang, Y., Shen, C., Wang, S., & Ye, P. 2004, Solar Physics, 222, 329, doi: 10.1023/B:SOLA.0000043576.21942.aa
  * Winslow et al. (2023) Winslow, R. M., Scolini, C., Lugaz, N., Schwadron, N. A., & Galvin, A. B. 2023, The Astrophysical Journal, 958, 41, doi: 10.3847/1538-4357/ad02f2