1 Introduction

Domain Name System (DNS) [1] is one of the crucial infrastructures of the Internet. In particular, people with the help from the DNS can conveniently use a human-readable domain name to visit websites instead of a hard-to-remember digital IP address. This process is usually called domain name resolution. One of the fundamental components of the DNS is the management of root domain names and top-level domain names (TLDs), which currently are maintained by the Internet Corporation for Assigned Names and Numbers (ICANN) [2]. This centralized architecture of the current DNS has received much criticism [3], such as the single point of failure [4] and power abuse. One of the famous incidents of a single point of failure on the current DNS is the DDoS attacks on Dyn [5]. The failure of the DNS provided by Dyn caused major websites, including Amazon.com, GitHub, Twitter, and Reddit, to convert unreachable via their corresponding domain names. As a result, it is natural to introduce the decentralized architecture into the current DNS to mitigate the above issues.

The past decade has witnessed a rapid development of blockchain, which has become the most famous and successful decentralized architecture. Recently, many works [6,7,8,9,10,11,12] have suggested introducing blockchain into DNS. Unfortunately, all of them suffer from the following problems, more or less.

  • Limited Functionality: Most of the current solutions cannot support the whole life cycle of domain names [6, 9,10,11,12]. For example, the solution in [9] does not support the renewal process of the domain name, i.e., the domain name owner cannot prolong the use time of the domain name.

  • Weak Security: Some solutions [8] cannot provide fairness among the domain name users. Specifically, the domain name user bidding for the domain name later has more advantages to obtain the domain name.

  • Limited applicable objects: Some solutions are only applicable to designated objects. For instance, the solution in [7] only supports mapping domain names to cryptocurrency addresses, but not to IP addresses.

As a result, it is desirable to design a new blockchain-based domain name management system without the above problems. In this paper, we propose a new domain name management system by employing some advanced cryptographic techniques, such as Pedersen commitment, zero-knowledge proof, and the account-based consortium blockchain with smart contractFootnote 1. The main contributions of this paper can be summarized as follows:

  • Our proposal supports the whole life cycle of domain names, including the registration, transfer, renewal, and update of domain names, in a fair and privacy-preserving way. The definition of fairness and privacy preservation can be found in Section 2.3.

  • To realize the desired security properties of our domain name management system, we propose an account-based consortium blockchain system with anonymous funds and a blockchain-based Vickrey auction. To the best of our knowledge, the proposed blockchain-based Vickrey auction is the first one holding fairness and privacy preservation, which may be of independent interest.

  • The security properties of our proposal can be easily obtained from those of the underlying cryptographic primitives. To show the efficiency and effectiveness of our proposal, we also provide a prototype implementation of our proposal in Python.

The remainder of the paper is structured as follows. We first formalize our system model, security model, and design goals in Section 2. In what follows, we recall some basic knowledge related to our proposal in Section 3. After that, we present our scheme in Section 4, followed by security analysis and performance evaluation in Section 5, respectively. Some related works are discussed in Section 6, and finally, conclusions are drawn in Section 7.

2 Models and design goals

In this section, we formalize our system model, security model and set out the design goals for our domain name management system.

2.1 System model

In our system model, as shown in Fig. 1, we mainly consider a typical blockchain-based domain name management scenario. We only have two kinds of entities in this paper: an account-based consortium blockchain with anonymous funds and many domain name users. The detailed descriptions of the two kinds of entities are as follows.

  • Blockchain system: Our system is heavily based on the blockchain system. Especially, we use the decentralization property of the blockchain to solve the problems due to the centralized architecture of the current DNS. In other words, all the nations together, instead of the single entity ICANN alone, maintain the mapping from domain names to IP addresses. To follow the fact that the internet in every country is usually controlled by network authority, we adopt the consortium structure for the underlying blockchain, and the consensus nodes in the blockchain are assumed to be the authorities. The blockchain is used to record the states of all the domain names, and everyone can map the domain name to an IP address by using the states. More details of our account-based consortium blockchain can be found in Section 4.1.

  • Domain name users: Domain name users refer to those who possess domain names or are interested in registering/buying domain names in our system. They can register, sell/buy, renew, and update domain names with the help of our blockchain system. In particular, the user registers and transfers domain names in a sealed-bid auction way (i.e., Vickrey auction). More details of the Vickrey auction can be found in Section 3.1. Anyone who has enough funds in the consortium blockchain can prolong the use time of any domain name, no matter he/she is the owner of the domain name or not. In contrast, only the domain name owner can update the IP address corresponding to the domain name. In the rest of this paper, we simply say “user” instead of “domain name user”.

Fig. 1
figure 1

The system model considered in this paper

Full size image

2.2 Security model

This paper assumes that the underlying consortium blockchain is honest-but-curious as other blockchain-based systems [14,15,16]. In particular, the consensus nodes in the blockchain system will faithfully execute the specified steps in the system, such as verifying whether a user has the right to register a domain name, and exactly running the smart contract deployed in the blockchain. However, the consensus nodes may be curious about users’ secret information, such as users’ funds. On the contrary, the users are assumed to be malicious. They would try their best to register, buy/sell, renew, and update the domain name without any payment. For instance, a malicious user sells a domain name not belonging to him/her or obtain the coins from the domain name buyer without transferring the domain name.

2.3 Design goal

Given the above system and security model, our design goal is to present a blockchain-based domain name management system with the following properties.

  • Fairness: In this paper, we mainly consider two kinds of fairness: transaction and bidding. The former means that the exchange between the domain name and the coins happens in a fair way. Once the owner obtains the coins, the domain name will be transferred to the buyer, and vice versa. The latter requires that all the users (bidders) have the same probability of obtaining the domain name in the Vickrey auction in terms of chronological order.

  • Fund-Privacy: In our system, anybody holding a network link with any consensus node can access the data stored in the blockchain. Hence, the second security requirement of our proposal is to protect the user’s privacy, such as the fund value. In particular, the adversary cannot deduce how many coins the user has by interacting with the user in domain name registration, update, transfer, and renewal processes.

  • Payment-Guarantee: According to Fund-Privacy, we should protect the confidentiality of the user’s fund. However, when users make payments, we need to guarantee that he/she has enough coins to cover the payment. Otherwise, the payment will fail. Therefore, in this paper, anyone can verify the sufficiency of the corresponding fund.

  • Efficiency: The proposed blockchain-based domain name management system aims to relieve the problems of the current DNS. Hence, it also needs to be (relatively) efficient in terms of computational cost.

3 Preliminaries

In this section, we would like to review the concept of the Vickrey auction, Pederson commitment, and zero-knowledge proof, which will be applied in our proposal.

3.1 Vickrey auction

An auction is a process where people can buy items via the bidding method, and it usually involves an auctioneer and many bidders. The corresponding seller typically does not appear but delegates the auctioneer to sell the items. In this paper, we adopt the Vickrey auction in our proposal due to its properties. Specifically, bidders in the Vickrey auction submit their bids to the auctioneer only once in a private way. After all the bids are submitted in a preset period, the auctioneer will open the bids and decide who the winner is, and the winner only needs to pay with the second-highest bid instead of the highest one. It has been shown that the bidders in the Vickrey auction only need to focus on evaluating the value of the goods, which may bring more benefits to the bidders and the seller [17]. In our proposal, the role of the auctioneer is played by the blockchain system.

3.2 Pedersen commitment

All the parts related to payments in our proposal require Pedersen commitment, which contains stages commit and reveal. The committer commits a value to the verifier in the former stage and reveals it in the latter stage. It requires that the receiver cannot reveal the committed value before the latter stage, and the sender cannot change the committed value after the former stage.

The Pedersen commitment goes as follows. In the commit stage, the committer sends the commitment \(\textrm{fund}=g^{x}h^{r}\) to the verifier, where x is the committed value, r is a random number, g and h are two elements in the underlying finite cyclic group, and everybody knows g and h but no one knows \(\log _h g\). Later on, the committer in the reveal stage sends \((x',r')\) to the verifier. If \(\textsf{fund}=g^{x'}h^{r'}\) holds, the verifier accepts the committed value; otherwise, he/she rejects it. One of the properties of the Pedersen commitment is homomorphic addition. In particularly, given \(\textsf{fund}_1=g^{x_1}h^{r_1}\) and \(\textsf{fund}_2=g^{x_2}h^{r_2}\), we have that

$$\textsf{fund}_1\cdot \textsf{fund}_2=g^{x_1}h^{r_1}\cdot g^{x_2}h^{r_2}=g^{x_1+x_2}h^{r_1+r_2}.$$

The value of \(\textsf{fund}_1\cdot \textsf{fund}_2\) is essentially a commitment to \(x_1+x_2\).

3.3 Zero-knowledge proof

Our proposal applies the zero-knowledge proof to prove the sufficient fund for payment but without revealing the concrete fund of the user. In other words, the value of fund should be not less than the value of payment. The concrete scheme used in the proposal is original from [18].

Given \(\textsf{fund}_1=g^{x_1}h^{r_1}\) and \(\{\textsf{fund}_{2i}'=g^{a_i\cdot 2^i}h^{r_{2i}'}\}_{i=0}^{\ell }\), the prover proves that \(x_1 \ge \sum _{i=0}^{\ell } a_i\cdot 2^i\) with the knowledge of \(x_1,r_1\), and \(\{a_i\in \{0,1\},r_{2i}'\}_{i=0}^{\ell }\), where g and h are the same as that in the Pedersen commitment, and \(\ell\) is a positive integer larger than the bit-length of any possible value of the fund in our system. The whole process contains the following two parts.

In the first part, the prover proves that \(x_1=\sum _{i=0}^{\ell } a_i\cdot 2^i+\sum _{i=0}^{\ell } b_i\cdot 2^i\) with the conditions \(\textsf{fund}_1=g^{x_1}h^{r_1}\), \(\{\textsf{fund}_{2i}'=g^{a_i\cdot 2^i}h^{r_{2i}'}\}_{i=0}^{\ell }\), and \(\{\textsf{fund}_{3i}'=g^{b_i\cdot 2^i}h^{r_{3i}'}\}_{i=0}^{\ell }\) by providing a signature corresponding to the public key \((h,\textsf{fund}_1/(\prod _{i=0}^{\ell }\textsf{fund}'_{2i}\cdot \textsf{fund}'_{3i}))\). Note that if \(x_1=\sum _{i=0}^{\ell } a_i\cdot 2^i+\sum _{i=0}^{\ell } b_i\cdot 2^i\), the prover knows the value of \(\log _h \textsf{fund}_1/(\prod _{i=0}^{\ell }\textsf{fund}'_{2i}\cdot \textsf{fund}'_{3i})=r_1-\sum _{i=0}^{\ell }(r'_{2i}+r'_{3i})\), and hence he/she can generate the signature; otherwise, the prover without knowing it cannot generate the signature since \(\log _h g\) is kept secret from everyone.

In the second part, the prover proves that all \(a_i\)’s and \(b_i\)’s belong to \(\{0,1\}\) as follows. Let us take \(a_i\) as an example. The prover only needs to provide a ring signature corresponding to the public keys \((h,\textsf{fund}'_{2i})\) and \((h,\textsf{fund}'_{2i}/g^{2^i})\). The ring signature scheme [19] allows the verifier to check the signature’s validity without revealing the public key corresponding to the real signing key. Note that if \(a_i=0\), the prover knows \(\log _h \textsf{fund}'_{2i}=r'_{2i}\); and if \(a_i=1\), the prover knows \(\log _h \textsf{fund}'_{2i}/g^{2^i}=r'_{2i}\) instead; for other cases, the prover does not know either \(\log _h \textsf{fund}'_{2i}\) or \(\log _h \textsf{fund}'_{2i}/g^{2^i}\) since \(\log _h g\) is kept secret from everyone. As a result, the verifier can check whether \(a_i\in \{0,1\}\) via the ring signature.

4 Our proposal

All the steps in our proposal work for the state maintenance of domain names. Usually speaking, there are two kinds of states for one domain name: “\(\textsf{NoOwner}\)” and “\(\textsf{Possessed}\)”. The former state means that no one possesses the domain name, and it can be transited into the latter by the Vickrey auction. The latter state refers to that someone owns the domain name. For this state, we have three variables, namely IP address, owner, and validity. Changing these variables may lead to a new “\(\textsf{Possessed}\)” state. The validity change even leads to the “\(\textsf{NoOwner}\)” state. We give the high-level description of the state change in Fig. 2. In the rest of this section, we will explain how the state does change. Before that, we would like to introduce an account-based blockchain system of which all the state changes run on top.

Fig. 2
figure 2

State changes of a domain name

Full size image

4.1 Account-based consortium blockchain

As we mentioned before, our blockchain is a consortium blockchain, where only a group of specific nodes could be the consensus ones that can add transactions to the blockchain. Our system assumes that the consensus nodes are internet authorities in each country. Furthermore, the consensus algorithm used in our blockchain system is the PBFT (Practical Byzantine Fault Tolerance) consensus algorithm, where the nodes can reach a consensus on some state via a three-round communication.

Fig. 3
figure 3

The structure of three accounts considered in this paper

Full size image

4.1.1 Account Structure

In our blockchain, there are three types of accounts, namely external account, contract account, and domain name account, as shown in Fig. 3. The external account contains two fields: \(\textsf{ID}_{\textsf{EA}}\) and \(\mathsf {EncFund_{EA}}\). The former is the public key whose private key is only known to the corresponding user. The latter is with the format \(g^{c}h^r\), where r is a random number, c is the amount of coin belonging to the account, g and h used by all users are two elements in the underlying finite cyclic group, but no one knows \(\log _h g\). Similar to the Pedersen commitment, c cannot be revealed by \(g^{c}h^r\). In addition to sending and receiving coins, the external account can also establish and trigger smart contracts.

The contract account has three fields: \(\mathsf {ID_{CA}}\), \(\textsf{EncFund}_{CA}\), and \(\textsf{HashCode}\), where \(\mathsf {ID_{CA}}=H(\mathsf {ID_{EA}} \Vert \textsf{HashCode})\), H is a cryptographic-secure hash function (such as SHA-256), \(\textsf{EncFund}_{CA}\) is of the same meaning with that in the external account, and \(\textsf{HashCode}\) is the hash of the corresponding smart contract code. The contract account can only trigger the smart contract corresponding to \(\textsf{HashCode}\), and it cannot establish any smart contract.

The domain name account contains five fields, including \(\mathsf {ID_{DNA}}\), \(\textsf{IP}\), \(\textsf{ValidPeriod}\), \(\textsf{Owner}\), and \(\textsf{state}\) as shown in Fig. 3. These five fields are the hash value, IP address, valid period, \(\mathsf {ID_{EA}}\), and state of the corresponding domain name, respectively. \(\textsf{state}= 0\) denotes that the domain name is not in an active state, hence the domain name cannot be used. Otherwise, the domain name is in an active state.

4.1.2 PBFT consensus algorithm

Practical Byzantine Fault Tolerance (PBFT) consensus algorithm was proposed by Castro et al. [20], aiming to improve the original BFT consensus algorithm in the context of distributed systems. Due to its low energy consumption, the PBFT has been adopted widely in the blockchain community, especially for private and consortium blockchains. In addition, there are many other variants, such as [21, 22], and [23]. However, in order to pursue universality, in this paper, we apply PBFT algorithm as the underlying consensus protocol of our blockchain system.

There are two kinds of roles in the PBFT: one master node and the other followers. They will all communicate with each other in three phases, named pre-preparation, preparation, and commitment. The ultimate goal is that honest nodes can reach a consensus on the data based on the principle of minority obeying the majority. In particular, the user initiates a transaction and sends it to the master node, who in the pre-preparation phase will store it and broadcast it to the followers if the transaction passes the verification. Upon receiving the transaction from the master node, the followers in the preparation phase will store it and broadcast it to other followers if the transaction passes the verification. Once the follower receives the same transaction from more than 2/3 of followers, it will send the confirmation message to other followers in the commitment phase. More details can be found in [20].

4.2 Description of our proposal

As shown in Fig. 3, the domain name has attributes: \(\textsf{IP}\), \(\textsf{ValidPeriod}\) and \(\textsf{Owner}\). The management of the first two attributes usually does not affect the domain name owner, which can be realized by the smart contract alone, as shown in the \(\mathsf {IP~Update}\) and \(\textsf{Renewal}\) phases in Sections 4.2.4 and 4.2.5, respectively. However, the change of the attribute \(\textsf{Owner}\), happening in the \(\mathsf {Name~Registration}\) and \(\textsf{Name~Transfer}\) phases, is more complex since it usually involves more users. In particular, we propose a new blockchain-based sealed-bid auction to realize the process. For clarification, we would like to present the notations involved in the whole life circle of the domain name in Table 1 and our sealed-bid auction protocol at first.

4.2.1 Blockchain-based sealed-bid auction

The underlying sealed-bid auction of our proposal is the Vickrey auction. As we introduced in Section 3.1, it contains four phases: launching, bidding, opening, and closing, which are implemented by using functions Create, Commit, Reveal and Finalize, respectively. The details of these phases can be found in the followings.

Launching phase In this phase, the auction is set up by deploying the smart contract and invoking the function Create by using (\(T_\textrm{c}\), \(T_r\), \(\textsf{item}\), \(\sigma _{\mathrm o}\)). Note that the function Create in each smart contract could have only one successful invocation, since the bidding item could be in only one auction at every moment. When the consensus nodes in the blockchain receive the function call, they check whether (\(T_\textrm{c}\)-now) \(\in \mathbb {R}_{c}\), whether (\(T_r\)- \(T_\textrm{c}\)) \(\in \mathbb {R}_{cr}\), whether the \(\texttt{item}\) has \(\textsf{Owner}\), the validity of \(\sigma_{\mathrm o}\), and whether the \(\texttt{item}\) is in an active state. If all of them are checked successfully, the consensus nodes initialize the dictionary \(\texttt{bidders}[\,][\,]\) and set the \(\texttt{state}\) about the \(\texttt{item}\) is in an active state. Otherwise, they stop running the function. The pseudo-code of the function Create can be found in Fig. 4.

Table 1 Notations used in the smart contract
Full size table
Fig. 4
figure 4

Functions in the smart contract of the blockchain-based sealed-bid auction

Full size image

Bidding phase Once the auction is launched successfully, bidders, who are interested in the bidding item, will invoke the function Commit with (\(\mathsf {ID_b}\), \(\{\textsf{fund}'_i\}_{i=0}^{\ell }\), \(\sigma_{\mathrm b}\), \(\textsf{ZKP}_{c,\textsf{fund}}\)). When the consensus nodes in the blockchain receive the function call, they check whether the bidder has submitted the bid by inspecting whether the dictionary \(\texttt{bidders}[\,][\,]\) contains \(\mathsf {ID_b}\) or not, whether the call is still in the valid period according to \(T_\textrm{c}\), and the validity of (\(\sigma_{\mathrm b}\), \(\textsf{ZKP}_{c,\textsf{fund}}\)). If all of them are checked successfully, the consensus nodes record the commitment of the bid (\(\{\textsf{fund}'_i\}_{i=0}^{\ell }\)) into the dictionary \(\texttt{bidders}[\mathsf {ID_b}][\)“commit”], reduce the committed bid \(\{\textsf{fund}'_i\}_{i=0}^{\ell }\) from the corresponding \(\mathsf {EncFund_{EA}}\) in the external account, and add the committed bid \(\{\textsf{fund}'_i\}_{i=0}^{\ell }\) into the \(\mathsf {EncFund_{CA}}\) in the contract account. Otherwise, they stop running the function. The pseudo-code of the function Commit can be found in Fig. 4.

Opening phase When the bidding phase stops according to \(T_\textrm{c}\), the bidders can start to reveal their bids by invoking the function Reveal with (\(\mathsf {ID_b}\), \(\{(\bar{c}'_i,\bar{r}'_i)\}_{i=0}^{\ell }\), \(\sigma_{\mathrm v}\)). When the consensus nodes in the blockchain receive the function call, they check whether the call is still in the valid period according to \(T_r\), whether the dictionary \(\mathtt{bidders[][]}\) contains \(\mathsf {ID_b}\) or not, whether \(\sigma_{\mathrm v}\) is valid, and whether all the \(\textsf{fund}'_i=g^{\bar{c}'_i\cdot 2^i}h^{\bar{r}'_i}\) for \(i=0,\cdots ,\ell\) hold. If all of them are checked successfully, the consensus nodes add the bid value \(\{(\bar{c}'_i,\bar{r}'_i)\}_{i=0}^{\ell }\) into the dictionary \(\texttt{bidders}[\mathsf {ID_b}][\)“bid”]. Otherwise, they stop running the function. The pseudo-code of the function Reveal can be found in Fig. 4.

Closing phase If the time arrives at \(T_r\), the bidders can invoke the function Finalize to get the domain name and terminate the auction. Note that anyone can invoke the function Finalize and deduce who is the winner according to \(\{\bar{c}_i'\}\) recorded in the dictionary \(\texttt{bidders[][]}\). When the consensus nodes in the blockchain receive the function call, they check whether it is the time to finalize the auction according to \(T_r\) and whether the \(\texttt{state}\) about the \(\texttt{item}\) is in an active state. If both of them are checked successfully, they continue running the function. Otherwise, they stop running. The pseudo-code of the function Finalize can be found in Fig. 4. In fact, we mainly deal with three cases for the bidders in the function Finalize. The first one is that the bidders follow the specific steps but losing this auction, the consensus nodes will deduct their funds from the contract account, and return to their external accounts. The second one is that if the bidders fail to open their bids in the opening phase, in addition to returning the corresponding fund from the contract account to their external account, the consensus nodes will also deduct a certain percentage of the penalty from the funds in the corresponding external accounts. The last one is for the winner whose money of the second-highest bid value will be destroyed in our account-based consortium blockchain, and the \(\texttt{item}\) will belong to the winner. However, if the \(\texttt{item}\) has owner, the winner’s whole money of the second-highest bid value will be added to the owner’s external account, and the \(\texttt{item}\) will belong to the winner.

4.2.2 Name registration

Now, we can utilize the sealed-bid auction above to register a domain name. In \(\mathsf {Name~Registration}\), any user can only register a domain name he/she is interested in by deploying an auction smart contract. The relevant steps are as follows.

  • Any user can use his/her external account to register a domain name by invoking the function Create in the corresponding smart contract with (\(T_\textrm{c}\), \(T_r\), \(\texttt{name}\), null) attached. By doing so, if there are other interested users, they can join in this sealed-bid auction to compete for registering this domain name through anonymous bidding.

  • After that, the interested users will use their external accounts to invoke the function Commit with (\(\mathsf {ID_b}\), \(\{\textsf{fund}'_i\}_{i=0}^{\ell }\), \(\sigma_{\mathrm b}\), \(\textsf{ZKP}_{c,\textsf{fund}}\)) attached. Note that each user cannot change his/her bid after submitting his/her bid successfully in an auction. By doing so, it proves to other users in the blockchain that he/she has bid on the domain name.

  • Then, if \(T_\textrm{c}\) now \(\le\) \(T_r\), the users can use their external accounts to invoke the function Reveal in the smart contract with (\(\mathsf {ID_b}\), \(\{(\bar{c}'_i,\bar{r}'_i)\}_{i=0}^{\ell }\), \(\sigma_{\mathrm v}\)) to open their bids. By doing so, it proves to other users in the blockchain that their bids for the domain name have not been tampered with.

  • Finally, if now > \(T_r\) and the \(\texttt{state}\) about the domain name is in an active auction contract, any user can use his/her external account to invoke the function Finalize to get the domain name, get the punishment or return \(\{\textsf{fund}'_i\}_{i=0}^{\ell }\) to their \(\mathsf {EncFund_{EA}}\)’s.

4.2.3 Name transfer

In \(\mathsf {Name~Transfer}\), users can transfer domain names to other users. There are two methods of domain name transfer in our domain name management system: direct and indirect. They are free to choose which method to use for domain name transfer.

Direct In the direct transfer method, the owner can transfer the domain name to the recipient directly, if they have reached an agreement on the transfer fee. It works as follows.

  • Firstly, the owner can invoke the function Transfer (as shown in Fig. 5) with (\(\mathsf {ID_o}\), \(\texttt{name}\), \(\mathsf {ID_v}\), \(c_t\), \(\texttt{t}\), \(\sigma_{\mathrm t}\)) attached. When the consensus nodes in the blockchain receive the function call, they check whether the the \(\texttt{name}\)’s \(\textsf{ValidPeriod}\) is valid, whether the \(\texttt{state}\) about the \(\texttt{name}\) is not in an active state, whether \(\sigma_{\mathrm t}\) is valid, and whether the \(\textsf{Owner}\) of the \(\texttt{name}\) is equal to \(\mathsf {ID_o}\). If all of them are checked successfully, consensus nodes run the rest of the function.

  • After that, any user can invoke the function Receive with (\(\texttt{name}\), \(c_t\), \(\sigma_{\mathrm r}\), \(\textsf{ZKP}_{c,\textsf{fund}}\)) to pay the transfer fee. When the consensus nodes in the blockchain receive the function call, they check whether \(\texttt{t}\) and (\(\sigma_{\mathrm r}\), \(\textsf{ZKP}_{c,\textsf{fund}}\)) are valid. If all of them are checked successfully, the consensus nodes will deduct \(c_t\) from the \(\mathsf {EncFund_{EA}}\) of the user’s external account, and add the same amount of money to the owner’s external account. At the same time, the ownership of the domain name will be transferred to the recipient.

Fig. 5
figure 5

Direct transfer method in \(\mathsf {Name~Transfer}\) phase in our proposal

Full size image

Indirect We illustrate the sealed-bid auction with which the indirect transfer method relies in Fig. 4. However, unlike in the \(\mathsf {Name~Registration}\), during the \(\mathsf {Name~Transfer}\), only the domain name owner can call the function Create to launch the auction.

4.2.4 IP update

In this phase, when the user decides to change the mapping relationship between a domain name and its IP address in a domain name account, he/she only needs to invoke the function Update with (\(\texttt{name}\), \(\texttt{ip}\), \(\sigma_{\mathrm u}\)). When the consensus nodes in the blockchain receive the function call, they check the validity of (\(\textsf{ValidPeriod}\), \(\texttt{ip}\), \(\sigma_{\mathrm u}\)). If all of them are valid, consensus nodes update the \(\textsf{IP}\) address of the \(\texttt{name}\). The pseudo-code of the function Update can be found in Fig. 6.

Fig. 6
figure 6

IP Update phase in our proposal

Full size image

4.2.5 Renewal

In this phase, the owner or even anyone else can renew the corresponding \(\textsf{ValidPeriod}\) field in the domain name account by invoking the function Renewal with (\(\texttt{name}\), \(c_r\), \(\textsf{ZKP}_{c,\textsf{fund}}\)) at any time. When the consensus nodes in the blockchain receive the function call, they check whether the corresponding \(\textsf{ValidPeriod}\) and \(\textsf{ZKP}_{c,\textsf{fund}}\) are valid. If all of them are verified successfully, consensus nodes will deduct \(c_r\) in the \(\mathsf {EncFund_{EA}}\) of the caller’s external account, and extend a period of ownership for the \(\texttt{name}\). The pseudo-code of the function Renewal can be found in Fig. 7.

Fig. 7
figure 7

Renewal phase in our proposal

Full size image

5 Analysis of our proposal

In this section, we will analyze the security properties of our proposal one by one as listed in Section 2.3 and show the (relative) efficiency by experiments.

5.1 Security analysis

Fairness The fairness of our proposal contains the transaction fairness and bidding fairness. As other blockchain-based systems [14,15,16], we simply assume that our PBFT-based consortium blockchain is secure. In this case, the consensus nodes should faithfully execute smart contracts involved in the maintenance of domain names. Furthermore, the codes in lines 32-43 in the function Finalize, lines 12-16 in the function Receive, and lines 3-4 in the function Renewal show that the transfer of the money and the domain name should happen or not at the same time. Hence, we have the transaction fairness immediately.

Regarding the bidding fairness of our proposal, we only need to show that no one can reveal the bid during the bidding phase, which is guaranteed by Theorem 1.

Theorem 1

The bidding values are confidential in the Bidding Phase.

Proof

According to the description of proposed blockchain-based sealed-bid auction, only \(\{\textsf{fund}'_i,\sigma '_i\}_{i=0}^{\ell }\) contain the information of the bidding value, where \(\textsf{fund}'_i=g^{c'_i}h^{r'_i}\), and \(\sigma '_i\) is the ring signature corresponding to public keys \((h,\textsf{fund}'_i)\) and \((h,\textsf{fund}'_i/g^{2^i})\). In this proof, we only need to prove that these data won’t leak any information about the bid \(c'=\sum _{i=0}^{\ell }c'_i\cdot 2^i\).

For simplicity, we here only show that the pair \((\textsf{fund}'_0,\sigma '_0)\) won’t reveal any information on \(c'_0\). We have the following steps.

  • We randomly choose \(\{0,1\}\) as the challenge messages to the challenge oracle in confidentiality security of Pedersen commitment. The oracle will output a challenge commitment \(\textsf{fund}^*\). After that, we set \(\textsf{fund}'_0=\textsf{fund}^*\). Note that, the committed value in \(\textsf{fund}^*\) is set as \(c'_0\) implicitly.

  • We send \((h,\textsf{fund}'_0)\) and \((h,\textsf{fund}'_0/g)\) as the challenge public keys to the challenge oracle in anonymity security of the underlying ring signature. The oracle will output a challenge ring signature \(\sigma ^*\). After that, we set \(\sigma '_0=\sigma ^*\).

  • Now, assume there exists an adversary that can get \(c'_0\) from \((\textsf{fund}'_0,\sigma '_0)\). With this, we can correctly response the guess oracles for Pedersen commitment and the underlying ring signature, which however is impossible.

Hence, we get the theorem.

Fund-Privacy Fund-privacy requires that the concrete value of user’s fund won’t be revealed during the maintenance process of domain names. This property can be easily obtained by using Theorem 2.

Theorem 2

The fund value c won’t be revealed in our proposal.

Proof

According to the description of our proposal, anyone can get the value of \(g^ch^r\) and ring signature \(\sigma ''_i\) of public keys \((h,\textsf{fund}''_i)\) and \((h,\textsf{fund}''_i/g^{2^i})\) for \(i=0,\cdots , \ell\), where \(g^ch^r=\prod _{i=0}^{\ell }\textsf{fund}''_i\) and \(\textsf{fund}''_i=g^{c''_i}h^{r''_i}\). Note that, one may argue that \(g^ch^r=\prod _{i=0}^{\ell }\textsf{fund}''_i\) should be \(g^ch^r=\prod _{i=0}^{\ell }\textsf{fund}'_i\textsf{fund}''_i\). However, the value \(c_i\) in \(\textsf{fund}'_i\) will be revealed in the opening phase. Hence, we use \(g^ch^r=\prod _{i=0}^{\ell }\textsf{fund}''_i\) instead of \(g^ch^r=\prod _{i=0}^{\ell }\textsf{fund}'_i\textsf{fund}''_i\). In this case, similar with the proof of Theorem 1, we can get the theorem.

Payment-Guarantee Payment-guarantee means that users have the ability to complete payment. This property can be obtained according to Theorem 3.

Theorem 3

The auction winner always has the enough money to pay the wined domain name.

Proof

According to the description of our proposal, the bidder’s fund c will be reduced by the bided value \(c'=\sum _{i=0}^{\ell }c'_i\cdot 2^i\) in the bidding phase. Only if \(c\le c' \le 0\), then we have the theorem.

For \(c' \le 0\), we only need to show that \(c'_i\in \{0,1\}\). Assume that the malicious bidders generate a ring signature of public keys \((h,\textsf{fund}'_i)\) and \((h,\textsf{fund}'_i/g^{2^i})\), i.e., \(c'_i\not \in \{0,1\}\). In other words, the malicious can generate a ring signature using a secret key whose public key is not in the public key set, which is against the unforgeability of the underlying ring signature.

Using the similar method, we can have \(c\le c'\). Hence, we get the theorem.

5.2 Comparison and performance evaluation

In this part, we would like to give the comparison between our proposal and the previous works, along with an evaluation.

5.2.1 Comparison with existing schemes

Our proposal is related to two kinds of schemes, namely blockchain-based DNS and blockchain-based auction. Hence, we give two comparisons in Tables 2 and 3, respectively. From Table 2, we can see that only ENS [7], Handshake [8], and our proposal can support the auction method for domain name management. Furthermore, our proposal is the only one holding fairness, fund-privacy, payment-guarantee, and efficiency at the same time. From Table 3, we can see that only ShadowEth [24], the solution in [25], and our proposal do not require any (semi-) trusted auctioneer. Furthermore, ShadowEth and our proposal can simultaneously hold fairness, fund-privacy, payment-guarantee, and efficiency. However, ShadowEth makes use of the trusted execution environment (TEE), whose security is still controversial [26, 27]. In summary, our proposal is the best one in terms of holding properties.

Table 2 Comparison between our proposal and existing blockchain-based DNS solutions
Full size table
Table 3 Comparison between our proposal and existing blockchain-based auction solutions
Full size table

5.2.2 Performance evaluation

We evaluate the performance of our proposal in terms of off-chain cost and on-chain cost. In particular, we use the ECDSA with the secp256k1 curve as the underlying signature algorithm as that in most blockchain systems. In our python-type prototypeFootnote 2, users can only invoke the specified smart contracts but cannot modify them. We test our prototype on an Ubuntu virtual machine with version 16.04, 4 processors, and 3GB of RAM allocated by the Windows 10 operating system. Additionally, the Ubuntu virtual machine runs on an Intel(R) Core(TM) i5-7300HQ CPU @2.5GHz Windows Platform with 16.0GB RAM. Note that, since PBFT is a well-recognized consensus mechanism for consortium blockchain. Therefore, in the following experiments, we only count the computational cost of off-chain and on-chain. All the numbers in Figures 8-10 are conducted 50 times and the averages are recorded. As we can see from the figures, our proposal is (relatively) efficient in terms of off-chain cost and on-chain cost.

Fig. 8
figure 8

The off-chain computational cost

Full size image
Fig. 9
figure 9

The on-chain computational cost

Full size image
Fig. 10
figure 10

The on-chain computational cost of the function Finalize

Full size image

Off-chain Cost The main computational cost for the off-chain part of our proposal is due to the generation of commitments and zero-knowledge proofs. In particular, in the function Commit, the bidder has to generate a commitment for the \(\textsf{fund}\) and a zero-knowledge proof for a statement. The statement shows that the bidder has enough money to cover his/her bidding. Similarly, in functions Receive and Renewal, users also have to generate zero-knowledge proofs off-chain for \(c_t\) and \(c_r\). As illustrated in Fig. 8, we can see that the computational cost of the off-chain parts in “Renewal”, “Receive”, “Commit” and “Reveal” is proportional to \(\ell\), while it is always acceptable. Furthermore, we can see that the computational cost of the off-chain parts in “Create”, “Finalize”, “Update” and “Transfer” are almost the same and computationally negligible. In addition, it is worth noting that, all the computational cost in “Finalize” is related to on-chain.

5.2.2.1 On-chain cost

For the on-chain cost, which is mainly due to the computational cost for the on-chain part of our system, especially, the verification of zero-knowledge proofs in the functions Commit, Receive, and Renewal, and the verification of commitments in the function Reveal. As shown in Fig. 9, the trend of the computational cost of on-chain parts in “Renewal”, “Receive”, “Commit” and “Reveal” is similar to Fig. 8. Furthermore, “Finalize” produces a slightly higher than “Create”, “Update” and “Transfer”, since it needs to compute \(\mathsf {EncFund_{CA}}\) in the contract account. To better evaluate the performance of the function Finalize, we generate different numbers of bidders in an auction to evaluate the corresponding on-chain cost. We can see from Fig. 10 that with the increase of the number of bidders, the computational cost generally shows an upward trend. When the number increases to 100 bidders, it requires around 7.59 seconds to complete the function “Finalize”.

6 Related work

As mentioned before, our proposal is close to blockchain-based DNS and blockchain-based auction, hence we give related works in two parts respectively.

6.1 Blockchain-based DNS

To solve the traditional DNS’ centralization problem, Namecoin [28], as the first project utilizing blockchain technology to solve the centralization problem of DNS, uses an additional preregistration method to avoid cybersquatting. Based on Namecoin, Ali et al. [29] proposed Blockstack Naming Service (BNS), which solved the security and performance issues for Namecoin. Unfortunately, both of them can’t avoid damage caused by malicious cybersquatting to the current domain name owners. Compared with Namecoin and BNS, a recent study presented by Wang et al. [6] named ConsortiumDNS also supports the same registration method to prevent cybersquatting but cannot defend the single point of failure attack [36]. In addition, it mainly focuses on the optimization of storage performance for domain names’ data, rather than the management of domain names’ life cycle. Similar to the previous three solutions, TD-Root [12] mainly focuses on domain name registration and update but ignores domain name renewal and transfer. The DNSonChain scheme recently proposed by Jin et al. [30] only allows owners to claim their domain name ownership on the blockchain. As we know, the domain name auction is one of the typical ways to obtain the domain name [37]. However, none of the above blockchain-based systems provide such functionality. In [7], Ethereum officials proposed a domain name system based on the smart contract to resolve domain names into Ethereum addresses but not the digital IP address. The Namebase team recently proposed a blockchain-based DNS, named Handshake [8], with a domain name auction protocol. Their auction protocol follows the Vickrey auction, where the submitted bids are not revealed until all the bids are submitted, and the bidder with the highest bid wins the auction while paying with the second-highest bid. However, in their auction protocol, anyone can deduce the possible highest bid of the submitted bids, which may bring advantages over the latter bidders. In other words, the auction protocol cannot hold the bidding-fairness property. To the best of our knowledge, it is still challenging to design a fair, secure, and privacy-preserving blockchain-based sealed-bid domain name auction protocol.

6.2 Blockchain-based auction

Using the secure multi-party computing (MPC) technique, Kosba et al. [31] proposed the first blockchain-based auction protocol named Hawk. However, the underlying secure MPC scheme is of a high level of interactivities, which leads to an inefficient solution, especially in the blockchain scenario. With the help of TEE, Yuan et al. [24] proposed an efficient blockchain-based auction protocol without sacrificing the smart contract’s confidentiality. Nevertheless, the TEE technique usually demands users to update their hardware, which not everyone can afford. What’s worse, the security of implementation of TEE is still controversial [26, 27]. Blass and Kerschbaum [32] proposed a new blockchain-based auction protocol still based on the secure MPC technique with a good performance. Nonetheless, the proposed protocol needs a pre-fixed bidding order and a semi-trusted auctioneer which is usually unnecessary in the blockchain scenario. Galal and Youssef [33] proposed an auction protocol over the Ethereum blockchain. However, it is not as efficient as expected due to the use of interactive zero-knowledge proof schemes. Furthermore, there is no mechanism to check whether the bidder has enough money to bid in the proposed auction protocol. Note that, although there is a deposit in their protocol, this deposit cannot be used as proof that the bidder has enough money to fulfill the bid. Recently, Nguyen and Thai [25] proposed a new efficient auction protocol based on multi-party state channels in terms of storage cost. However, the resulting protocol cannot support the sealed-bid auction. Qusa et al. [34] also proposed a new blockchain-based auction protocol, while the bidder colluding with some bidders can obtain some advantages over the rest of the bidders. Furthermore, Zhang et al. [35] proposed a time-released blockchain-based sealed-bid e-auction scheme, but the auctioneer has to initiate the auction and decide the time to terminate the auction, which cannot avoid the risk of ethical problems for the auctioneer. It is fair to say that a fair, secure, and privacy-preserving blockchain-based auction protocol is still desired. It is fair to say that a fair, secure, and privacy-preserving blockchain-based auction protocol is still desired.

7 Conclusion

To the best of our knowledge, the blockchain-based DNS is considered one of the most promising decentralized DNSs. However, the current blockchain-based DNSs fail to provide a management system of the entire life cycle of a domain name, and most of them are not secure or fair. To fill this gap, we in this paper have proposed a domain name management system based on an account-based consortium blockchain. Based on the security assumptions on the underlying blockchain system, the Pedersen commitment, and zero-knowledge proof, we have also shown that the proposed scheme is indeed privacy-preserving, secure, and fair. By running the extensive experiments, our proposal is indicated as (relatively) efficient in terms of computational cost.