This paper reports the use of the Schnorr Digital Signature as a new alternative instead of the Elliptic Curve Digital Signature Algorithm (ECDSA) currently used in Ethereum. Elliptic curve cryptography, which is the cryptographic background of blockchain digital signature, is explained in the background and related works. This study then examined, the problems facing ECDSA and how the Schnorr Digital Signature could solve them. The test was performed by comparing Schnorr and ECDSA implemented in a private Ethereum network environment. The performance results showed that Schnorr Digital Signature has strengths in terms of efficiency over ECDSA. The efficiency deals with the gas price, signature size, block size, block elapsed time, and signature algorithm calculation time.

※ The user interface design of www.jsts.org has been recently revised and updated. Please contact inter@theieie.org for any inquiries regarding paper submission.

### Journal Search

## 1. Introduction

As the interest in Bitcoin ^{[1]} increases worldwide, there are more opportunities for researching and developing
blockchain. Bitcoin was initially shunned by people to the extent that it was called
``bubbles and fraud'', but now it is developing by combining various technologies.
Since Vitalik Buterin published the Ethereum ^{[2]} blockchain platform, technology research, and applicable functions have progressed
rapidly in the blockchain industry. On the other hand, ECDSA, a digital signature
adopted by Ethereum, which is currently being used in the blockchain digital signature
system, has a problem with efficiency.

A Schnorr digital signature method was proposed to solve these problems and study
why Schnorr should be used by comparison with ECDSA. Section 2 describes the elliptic
curve and elliptic curve cryptography, which are the basic backgrounds of the blockchain
digital signatures. Section 3 outlines the digital signature algorithms for the ECDSA
and Schnorr digital signatures. Section 4 explains how the Schnorr digital signatures
are more efficient than ECDSA by showing the test environment and the results for
comparative testing of ECDSA and Schnorr. Schnorr has more strengths than ECDSA in
the gas price, block size, signature size, block elapsed time, and signature algorithm
calculation time. Hence, digital signatures that apply the Schnorr were implemented
in a cryptographic approach using a private Ethereum network ^{[3]}.

## 2. Background and Related Work

### 2.1 Elliptic Curve

The cryptographic background of the blockchain digital signature is elliptic curve cryptography. Elliptic curve cryptography is produced based on the Discrete Logarithm Problem (DLP) and the algebraic structure of elliptic curves on finite-body fields. The equation form of the elliptic curve is expressed as Eq. (1), and the expression of this equation is called the Weierstrass equation form.

The Standards for Efficient Cryptography (SEC), founded by Certicom in Canada, provide
standardized information for the widespread application of elliptic curve cryptography.
These elliptic curves require parameters that must be selected carefully because the
elliptic curve used is determined by these parameters. There are various ways to select
a parameter. For example, it may be generated randomly. Non-random curves are explicitly
formed when selecting verifiable random parameters. Fig. 1 provides an example of an elliptic curve ^{[4]}.

There are various standardized elliptic curves that include these characteristics
to ensure efficient computation. T in Eq. (2) is a tuple that expresses the six parameters required for the elliptic curve by the
expression. p denotes the boundary of the finite field of the elliptic curve. The
a and b are coefficients that determine the shape of the finite field elliptic curve
in Eq. (1). G is the constructor point that exists above the elliptic curve. n is the value
generated by circulating the subgroup of G. h is a cofactor required for signature
^{[5]}.

### 2.2 Elliptic Curve Cryptography (ECC)

#### 2.2.1 Hasse’s Theorem

Fig. 2 shows the typical shape of the elliptic curve for the finite field; it is no longer
a smooth curve but a set of points, as shown in Fig. 1. A finite series of points is scattered along the plane. It is symmetric on the x-axis
of $\frac{p}{2}$ and can define a geometrical method for point addition. The general
idea is to draw a line that passes like the considered point $Q_{1}$ and $Q_{2}$.
This line is tracked along itself through modular calculation. Once the line crosses
the point $-Q_{3}$, the opposite point $Q_{3}$ is selected to have the result of addition.
On the other hand, this approach can be confusing because it is depicted in pictures.
Therefore, it is expressed in algebraic notation. $E\left(F_{p}\right)$ is defined
as E (Elliptic Curve), F (Finite Field), and p (Prime Number). The number of points
on the elliptic curve relative to the $E\left(F_{p}\right)$ is determined by p. This
is called Hasse’s theorem or the boundary of Hasse ^{[6]}.

#### 2.2.2 Lagrange’s Theorem

According to Lagrange’s theorem, if $E\left(F_{p}\right)$ is a prime number, then
$E\left(F_{p}\right)$ is a cyclic group. Lagrange’s theorem is that the size of the
subgroup of the finite group is a subgroup of the original size of the group. The
order of each subgroup is the group order. Hence, it is a subgroup when the group
order is a prime number. This means that the entire group of G must exist. If G is
fixed, it should be added repeatedly. It will then reach a different point in the
$E\left(F_{p}\right)$. Eventually, it reaches infinity. We would have found a cyclic
subgroup when the private key is equal to the order of G. Therefore, if $E\left(F_{p}\right)$
is a prime number, the entire set of points in the elliptic curve forms a cyclic group
^{[7]}.

#### 2.2.3 Discrete Logarithm Problem (DLP)

DLP is a matter of determining the k integers in $x^{k}=y$. In other words, it is
to find a $k=log_{x}\,.$ Security cryptography systems based on ECC are determined
by the difficulty of the DLP defined through the Elliptic Curve Discrete Logarithm
Problem (ECDLP). This becomes difficult and impractical when k is an integer with
hundreds of bits, which is a huge number because SECP256K1 is 256 bits. Furthermore,
the time complexity to find the DLP increases to $O\left(2^{256}\right)$. The main
advantage of ECC is that the encryption key size is small. The DLP difficulty is still
difficult; the security level is the same, and the storage and transmission requirements
can be reduced. In the execution time of the elliptic curve algorithm, elliptic scalar
operations require a certain amount of time in milliseconds. ECDLP will require a
period of $10^{28}$ years if calculated approximately. Even with today's supercomputers,
the calculations are computationally impracticable. For this reason, DLP is the core
of many public key cryptosystems ^{[8]}.

#### 2.2.4 SECP256K1

The elliptic curve currently used by Ethereum for digital signatures is a curve called
SECP256K1. To explain the definition, SEC is the Standards for Efficient Cryptography
(SEC). P is the parameter representing the size of the boundary of the finite field.
P comes after 256 bits, which represents the length in bits. The field size suggests
that solving the DLP in the elliptic curve is difficult. K stands for the Koblitz
curve and is distinct from the random curve, representing verifiable random use. Finally,
it is sequence number 1, which is divided for discriminating the elliptic curves.
SECP256K1 is composed of a special method and has the equation, $y^{2}=x^{3}+7,$ to
ensure efficiency. The parameters for SECP256K1 configuration are defined, as listed
in Table 1 ^{[9]}.

##### Table 1. Parameters for ECDSA (secp256k1)[9].

##### Table 2. Experiment Parameters.

## 3. Algorithms used in the Experiment

### 3.1 Elliptic Curve Digital Signature Algorithm (ECDSA)

ECDSA is an elliptic curve-based digital signature algorithm used in Ethereum. It was proposed as an alternative to the RSA encryption method used in the past. It is an elliptic curve encryption technology that performs faster with small numbers of encryption keys than the longer encryption keys with slower encryption speeds. ECDSA is very difficult to infer a private key based on ECDLP encryption technology. That is, knowing the generator point G and the public key does not mean that the private key is known. On the other hand, ECDSA currently has various problems in efficiency, and the cases are as follows.

· High gas price, Large signature size, block size

· Inverse modular calculation, which means many inverse modular calculations are required.

· Scalar multiplication, in which the highest calculations are required.

These problems are a very slow task, which is valid for everything only if n is a
prime number; n must be a prime number because of the difficulty of the ECDLP. The
process involves taking the x-coordinate of the function K used in step 5 and modular
n (Fig. 3). This means that the attacker cannot find r, but the random value k cannot ignore
the probability of satisfying the equation in step 5 $r=x_{K}\left(\mathrm{mod}n\right)$
^{[10,}^{11]}.

The following explains how the ECDSA signing algorithm was implemented. Fig. 3 shows that it has a message and q (private key) as the input values. k is generated
as a random value, and z is the leftmost bit number of messages hashed with the keccak256
function. If r zero in the modular calculation in step 5, then return to step 3 and
generate the k random value again. The s signature value was made by inputting $s=k^{-1}\left(z+rq\right)\left(\mathrm{mod}n\right)$
into the equation. If the s zero, return to step 3 and generate the k random value
again. Finally, return values are public keys, s, and r signatures. How the ECDSA
verification algorithm was implemented will be described. Fig. 4 shows that it has a message, public keys, s, and r signature values as the input
values. z denotes the leftmost bit number of the same message, as shown in Fig. 3. To make the kG of step 6, the equations $u_{1},$ $u_{2}$ are defined and $kG=~ u_{1}G+u_{2}Q$.
Finally, the r signature received as an input is compared with K, which has performed
a modular calculation. The verification was performed as Eqs. (3)-(6) below ^{[10,}^{11]}.

Furthermore, there is a way to accelerate the verification process; it is Straus’s
algorithm, the sum of the two scalar multiplications. It is also known as Shamir’s
trick, which can be calculated faster than the two separate scalar multiplications
in the sixth step in Fig. 4. When K is made efficiently, the result can be obtained in less time, in which case
Fig. 4 multiplied by s in the sixth step becomes the $sK=zG+rQ$ equation, so inverse modular
calculations are not required. This can be achieved by including the K point ^{[10,}^{11]}.

### 3.2 Schnorr Digital Signature

Following Peter Wuille’s recent Bitcoin Improvement Proposal (BIP), Schnorr’s standardization
of Bitcoin protocols is explained. As specified in BIP, ECDSA is standardized, whereas
Schnorr signatures are not because they have had patent problems over the past few
years. On the other hand, Schnorr itself is better in many ways than ECDSA, and it
tries proving and analyzing the results through the test. Schnorr uses fewer signatures
than ECDSA and there is no inverse modular calculation. The efficiency is better in
terms of the speed of function calculation. Schnorr can be deployed easily through
a soft fork. The Schnorr signature can enable easier implementation of some of the
protocols required. Because Schnorr is not standardized, design selection is possible.
Schnorr usually uses the P-256 curve released by NIST in the United States, and uses
the sec256r1 curve by the SEC. The parameters for constructing the Barreto-Naehrig
(BN) curve for the Schnorr digital signature were defined, as shown in Table 3 ^{[11-}^{13]}.

This section explains how the Schnorr signing algorithm was implemented. Fig. 5 shows that it has a message and q (private key) as input values. In the k value,
the private key and the message are hashed with the keccak256 hash function, and two
public keys (x, y) coordinates are obtained by multiplying the generator point G in
q by the elliptic curve scalar. Find the equation $e=hash(kG|Q|M)$ required for Schnorr
signature and make $s=k-eq$ the equation. The public keys, s, and e signature values
are outputs as return values. The following describes how the Schnorr verification
algorithm was implemented. Fig. 6 has a message, Q (public keys), s, and e as input values resulting from the signature
algorithm. If the public key has an infinite value or does not exist in the elliptic
curve, the return value is False. As long as the equation $kG=sG+eQ$ is performed,
the result of hash with the e signature value received as an input value is compared
with the equation $e=hash(kG|Q|M)$. If it is wrong, return False, else if right return
True. Eqs. (7)-(9) performed the verification below. ECDSA has an inverse function, but Schnorr does
not ^{[11,}^{13]}.

##### Table 3. Parameters for Schnorr (BN Curve)[12].

## 4. Performance Analysis

Table 4 lists the test environment. Ethereum is the most representative blockchain platform
developed by Vitalik Buterin based on Bitcoin in July 2015. Ethereum can access the
main network, test network, and private network through the Go-Ethereum (Geth) client.
Geth ^{[2,}^{3]} is a client that allows access to the Ethereum blockchain network, and it is written
in the Go language. The so-called Ganache, which corresponds to the private network,
was used.

Solidity language ^{[2,}^{3]} was designed by the Ethereum Solidity team, starting with Gavin Wood’s proposal in
August 2014, to implement the Ethereum smart contract functionality operating on EVM
in a static type of programming language. The Solidity language is compiled into byte
codes that can operate on EVMs. Developers can implement the applications by putting
their business logic into smart contracts using Solidity language. Items recorded
in smart contracts cannot be denied and cannot be modified once deployed, so they
must be written carefully.

Remix IDE ^{[14]} is an integrated development environment site that enables integrated coding, compilation,
debugging, and deployment of Solidity languages on a browser. In other words, it is
a site where Solidity codes can be written and compiled on the Internet. It can be
used in a web browser without a separate installation, has its own compiler ‘solc’,
and can access Ethereum's network. Furthermore, it includes a private Ethereum network,
such as Ganache, which was used in the present study.

The above figures show the process of proving the Schnorr digital signature implemented in Remix IDE. The CreateProof function is an algorithm that signs a Schnorr digital signature (Fig. 7). Secret means a private key, and message can be viewed as message values to be signed. It can be seen that two public key values, s and e signature values appear as result values as output values. In Fig. 8, the VerifyProof function is an algorithm that verifies s, e signatures, public keys, and messages as input values in the Schnorr signature algorithm. As shown in Fig. 8, because the message value is signed 0x1111, entering a different message value of 0x1112 results in False. In Fig. 9, it is confirmed that the signature message value must match 0x1111 to become True. The Schnorr signature algorithm was confirmed to be working correctly; it was deployed in the present study for testing in the private Ethereum network environment.

##### Table 4. Test Environment.

Figs. 10 and 11 show that the next step was to confirm whether the Schnorr and ECDSA contracts were well deployed in the private Ethereum network. In Fig. 12, it can be confirmed that Schnorr and ECDSA are successfully recorded in the blockchain network. Schnorr’s gas price is 664052, and ECDSA’s gas price is 865141. Schnorr was recorded in the 212th block. The number of transactions (txs) value rose by 1. The block mining and sealing times were 11.968ms and 153.617ms, respectively, totaling 165.585ms. The ECDSA contract was recorded in the 385th block. Similarly, the number of transactions (txs) value increased by 1. The block mining and sealing elapsed times were 18.823ms and 392.950ms, respectively. The total block elapsed time was 411.773ms. Figs. 13 and 14 show that the block size was 3022bytes in the 212th block, and the block size was 3784bytes in the 385th block. Both Schnorr and ECDSA contracts have the same miner as 0xf03a27b9de2abf495e7c9b1a0fbd80b4f74908d2.

It is recommended to save this contract hash value separately. This is because several smartcontracts will be placed if the blockchain is used, which could cause problems in using them because they could lose hash values later. The deployed smartcontracts were stored in the Ethereum blockchain, and their attributes were examined. Moreover, approximately 600 blocks were mined for the simulation, and 100 experiments were conducted for the Schnorr and ECDSA. The process of the simulation is shown in Fig. 12.

ECDSA uses 70-72bytes (DER encoding) for the signature, and Schnorr uses fixed-sized
64 bytes. More specifically, ECDSA has v (6-8bytes), r (32bytes), and s (32bytes)
signatures. Schnorr has s (32bytes) and e (32bytes) signatures. Because ECDSA generally
includes a recovery parameter to support public key recovery, and Schnorr has a y-coordinate
as a parameter in one x-coordinate in the signature, the public key recovery becomes
possible without a recovery parameter. Moreover, regardless of function, the gas price
is determined by size. Hence, size is a critical issue when producing Ethereum smart
contracts. In Fig. 15, the gas price, Schnorr was 664052, and ECDSA was 865141. Schnorr could reduce the
gas price by approximately 23.24% compared to ECDSA. Figs. 16 and 17 show that the Schnorr signature size is 11.11% smaller than ECDSA, and Schnorr block
size is 20.13% less than ECDSA. Owing to the characteristics of most blockchain, the
blocks continue to be produced, and the size continues to grow in proportion to time.
Therefore, Schnorr can reduce this growth of blockchain size and has good efficiency
than ECDSA ^{[15]}.

Fig. 18 shows that elapsed time in both ECDSA and Schnorr. The experiments were deployed
100 times, and obtain the results with a graph. The Schnorr and ECDSA average times
were 445.07ms and 596.97ms, respectively. Schnorr was 25.44% faster than ECSDA. On
the other hand, in the case of a private Ethereum network, there are some variations
every time the expanded time works, so it needs to be taken into the Ethereum Main
network. The signature algorithm calculations are point multiplication, scalar multiplication,
and inverse operation. In Eqs. (10) and (11), reference ^{[17]} pointed out that the one scalar multiplication operation satisfies the requirement
of 923 multiplications. The inverse operation was approximately equal to 10 multiplication
operations. In Table 5, ECDSA has four point multiplications (Point Mul.), two inverse operations (Inverse),
and three scalar multiplications (Scalar Mul.). Schnorr has four point multiplications,
zero inverse operation, and two scalar multiplications. ECDSA used 2803 multiplication
calculation times, and Schnorr used 1850 multiplication calculation times. The signature
calculation time of Schnorr was 34% faster than that of ECDSA. In other words, ECDSA
has heavier operations, such as inverse operations and scalar multiplications in the
calculation process, while Schnorr was relatively small, so the Schnorr signature
calculations operate faster than ECDSA ^{[16,}^{17]}.

## 5. Conclusion

This study implemented and tested a digital signature using Schnorr instead of ECDSA currently used in Ethereum. The two plans were compared while studying the problems of ECDSA and solved using Schnorr. Schnorr has strengths in efficiency. The efficiency is approximately the size and speed of both algorithms. More specifically, it is the gas price, signature size, block size, block elapsed time, and algorithm calculation time. Schnorr has superior efficiency to ECDSA. On the other hand, these results were conducted on a private Ethereum network; it may be different on a public Ethereum network. The last thing to highlight was that the Schnorr advantages presented in this study were not all the advantages Schnorr has. Further research will be needed on the technical aspect and the possibilities of Schnorr in the blockchain.

### ACKNOWLEDGMENTS

This study was supported by the National Research Foundation of Korea (NRF) grant funded by the Korean government (MSIT) (No.2019R1A2C1008533), and this work was supported by the 2022 Hongik University Research Fund.

### REFERENCES

## Author

Jangho Na received his A.S. degree in Game development from Chunnam Techno University, South Korea, in 2018. He received his B.S. degree in Game Software from Hongik University, South Korea, in 2021. Since 2021, he has been a Master’s student at the School of Games at Hongik University, Sejong, South Korea. His research interests include blockchain, Ethereum, digital signature, NFT, Game servers, and cryptography.

Hye-Young Kim received her Ph.D. in Computer Science and Engineering from Korea University, Seoul, South Korea, in February 2005. During her Ph.D. study, she focused on location management schemes and traffic modeling, such as Mobile IPv6, cellular network, and mobility. In 2006, she was a Post-Doc. at the Wright State University (WSU). She has worked at Hongik University of South Korea as a full professor since March 2007. She developed a network protocol for nine years while she was working at Hyundai Electronics as a senior researcher. Her research interests include traffic modeling and load balancing scheme applying deep learning in IoT and Blockchain.

Nohpill Park received his B.S and M.S degrees in Computer Science from Seoul National University, Seoul, Korea, in 1987 and 1989, respectively, and Ph.D. degree from the Texas A&M University, College Station, in 1997. He is currently an Associate Professor at the department of computer science, Oklahoma State University, Stillwater. His current research interests include computer architecture, defect and fault-tolerant systems, testing and quality assurance of digital systems, parallel and distributed computer systems, multichip module systems, and programmable digital systems.

Beomjoo Seo received the B.S. and M.S. degrees from the Department of Computer Engineering, Seoul National University, Seoul, Korea, in 1994 and 1996, respectively, and the Ph.D. degree in computer science from the University of Southern California, Los Angeles, CA, USA, in 2008. His research at the University of Southern California was supervised by Dr. Roger Zimmermann. He worked for 5 years as a Research Engineer at LG Electronics, Seoul, Korea. He was formerly a Research Fellow at the School of Computing, National University of Singapore, Singapore. He is currently an Assistant Professor at the School of Games, Hongik University, Sejong, Korea. His research includes distributed storage model, distributed spatial audio streaming for virtual worlds, and sensor-rich mobile video acquisition, annotation, and its application.