Using Ethereum Registration Authorities to establish Trust for Ethereum Private Sidechains

Ethereum Private Sidechains are permissioned Ethereum blockchains which allow authorised participants to interact privately using Smart Contracts. Permissioned blockchains are appropriate for use in scenarios in which the list of blockchain participants and the code and state of contracts on the blockchain must be kept secret. Ethereum Registration Authorities are a system of Smart Contracts which can be used to resolve bootstrap information based on domain names to allow Ethereum Private Sidechains to be established between parties which have not previously interacted. This paper presents the architecture, design, and gas usage of a reference implementation for the Ethereum Registration Authority system. It analyses the security properties of the system and shows that it is secure, decentralized, and censorship resistant. The reference implementation gas usage is analysed and shown to be independent of the length of domain name and number of entries in the


Introduction
Ethereum Private Sidechains [1] are intended to be private Ethereum blockchains which can be established on-demand between previously unrelated organisations in a similar way to how a user of a web browser can establish a secure connection to a web server by simply entering in a URL such as https://example.com/.They will allow only permissioned nodes belonging to participating organisations to join the sidechain's peer-to-peer network and only allow permissioned accounts belonging to participating organisations to submit transactions to the nodes.These sidechains will facilitate a new wave of blockchain adoption by enabling complex new use-cases such as supply chains which include confidential business logic.They will provide the privacy and permissioning required by enterprises [2].
The strong privacy and permissioning features required by enterprises are in contrast to the permissionless Ethereum MainNet [3] which provides strong non-repudiation properties with no privacy or confidentiality [4].However, these strong nonrepudiation properties mean that Ethereum MainNet is the ideal location for securely storing data for which the authenticity and integrity of the data is paramount.
To establish an Ethereum Private Sidechain, the node IP addresses, verification public keys, encryption public keys, and accounts belonging to each organisation needs to be determined.This linking of real-world identity to blockchain information needs to be done securely.This article describes and analyses Ethereum Registration Authorities, an Ethereum smart contract-based approach for establishing bootstrapping information for Ethereum Private Sidechains.This paper reviews existing techniques for establishing trust, showing the existing techniques to be not appropriate for Ethereum Private Sidechains.It then describes the architecture of Ethereum Registration Authorities.The design of the system is discussed, explaining how the system minimizes complexity and gas usage, reduces round trips caused by multiple calls, whilst being extensible and providing organisations with autonomy.The gas usage of the Ethereum Registration Authority reference implementation [5] as measured using the Truffle test framework in combination with the Truffle EVM emulation is presented.The paper closes with a discussion of the security of Ethereum Registration Authorities.

Existing Techniques
A range of techniques have been devised to establish private blockchain networks.JP Morgan's Quorum [6], a fork of Go Ethereum [7], requires network addresses and keys to be shared out-of-band.
Similarly, Hyperledger Fabric requires the IP addresses of "anchor peers" and root CA certificates for each participating organisation to be distributed out-of-band to establish a network [8].Requiring this out-of-band sharing between parties precludes the establishment of networks on demand between previously unrelated organisations and as such is not a suitable technique for establishing trust for Ethereum Private Sidechains.R3's Corda [9] uses a centralised "Network Map Server" to distribute bootstrapping certificates which are ultimately signed by a single root "Network Certificate Authority".Having these points of architectural and political centralization goes against the core tenants of Ethereum [10], and the Internet [11] around decentralization.Though Ethereum Private Sidechains may be configured such that a certain party is explicitly given greater control than others, perhaps because this is required for regulatory compliance reasons, the system should be able to operate in a decentralized manner to allow it to be applicable in the greatest number of use-cases.As such, having a centralization point similar to Corda's "Network Map Server" is not an appropriate technique for establishing trust for Ethereum Private Sidechains.
InterPlanetary File System (IPFS)'s InterPlanetary Name System (IPNS) and Monero use DNS TXT records to store bootstrap information [12] [13].Domain Name Registrars typically exercise due diligence when issuing domain names such that they ensure that the domain names legitimately relate to the organisation's realworld identity.As such, if the information in DNS could be trusted, it would provide a mechanism for determining bootstrap information for previously unrelated organisations.However, DNSSEC, the additions to DNS to make it secure, are not widely deployed around the globe [14] [15].This means that using DNS TXT records is not an effective method of securely deploying bootstrap information.Additionally, domain name registrars control the issuance and resolution of domain names under their control.This results in political centralization and can be used for censorship.As such, using DNT TXT records is not an appropriate method to establish trust for Ethereum Private Sidechains.
NameCoin [16] proposed a decentralized name-value pair system based on Bitcoin to be used as a decentralized DNS.Using this system for the storage of Ethereum Private Sidechain bootstrap information would require applications to have both a NameCoin client and an Ethereum client, which means introducing more software, which increases the maintenance cost and complexity of the system.Additionally, this system is no longer secure as the majority of the mining of NameCoin is now done by one organisation [17].This organisation could re-write the history of the NameCoin blockchain given it mines more than 51% of the currency.
EthDNS [18] has been proposed as an approach to storing DNS information in Ethereum Name Service (ENS) [19].The authors espouse not having a hierarchy of name servers by storing all domains in the one contract.This lack of hierarchy is motivated by the desire to be immune from censorship by name servers delisting intermediate domains.However, having all domains listed in one contract provides no mechanism to distinguish highly trusted domains from less trusted domains.For example, it could be imagined that some registrars might complete significant audits prior to listing a domain, whereas other registrars may require minimal information.Additionally, EthDNS does not provide a way for organisations to certify a list of domains which should be used for a certain purpose.For example, with EthDNS, there is no way for a government regulator to specify which organisations are approved to offer a certain service.Ethereum Private Sidechains need to be able to group domains according to different types of trust to enable to maximum number of use-cases.As such, EthDNS is not an appropriate technique for establishing trust for Ethereum Private Sidechains.This article introduces the Ethereum Registration Authority architecture, explaining how this architecture overcomes the deficiencies of previous techniques.In particular, this technique allows for sharing of information between parties which have not previously interacted, is decentralized, censorship resistance, does not rely on DNS, and allows domains to be assembled into multiple trust groupings.

Architecture
The Ethereum Registration Authority (ERA) system of contracts are Solidity contracts [20] which reside on an Ethereum blockchain, typically Ethereum MainNet. Figure 1 shows the ERA system in the context of Enterprise Ethereum Clients.To establish a sidechain: As the ERA system of contracts are on Ethereum MainNet, both of the Enterprise Ethereum Clients could be certain of the integrity and authenticity of the bootstrap information stored in the contracts.The Sidechain Creators for each Enterprise Ethereum Clients was able to securely fetch bootstrap information based on the domain names of organisations that were participating in the sidechain.
The ERA system of contracts consists of Domain Information contracts which hold information for one or more domains, ERA contracts which hold look-up information to map between domain names and Delegate ERAs and/or Domain Information contracts, and Finder contracts which allow domain names to be resolved and domain information to be located using a set of Root ERA contracts.
Contracts for Root ERAs and Delegate ERAs are identical, thus allowing a Delegate ERA to operate as a Root ERA in some contexts and as a delegate in other contexts.This could be useful in situations such as when within an organisation, the organisation's own ERA contract should be considered a Root ERA whilst other organisations may wish to locate the organisation's ERA contract via an ERA contract they trust, thus treating the organisation's ERA contract as a delegate.
A Delegate ERA contract can be listed with any number of Root ERA contracts.Doing this means that a Delegate ERA contract can be locatable via multiple paths, thus not tying the Delegate ERA to one Root ERA, and thus reducing the risk of censorship of the Delegate ERA by a single Root ERA.
Domain Information contracts hold domain information for one or more domains.Holding the domain information for multiple domains in one contract reduces the gas cost as fewer contracts need to be deployed.Additionally, information which is relevant to all sub-domains can be stored efficiently in the contract.

Implementation
This section describes some design choices of the ERA reference implementation [5].The ERA contract holds information indexed using the Keccak-256 message digest of the domain name.The rationale for using the Keccak-256 message digest of the domain, rather than the domain itself is to both minimise the gas usage and make the gas usage deterministic.Ethereum uses a 32-byte word size, the size of the Keccak-256 message digest.When values are put into a map, the key is digested using Keccak-256 inside the Ethereum Virtual Machine.However, if the key value is longer than one word long, multiple digest calls must be made to digest the value, with each call increasing the gas cost.Keccak-256 digesting domain names which have variable length off-chain and submitting the thirty-two-byte digest value ensures the gas cost is fixed as the key is guaranteed to only be one word long.
In the ERA contract, each domain name entry can have an address of a Delegate ERA contract, an address of a Domain Information contract, and the address of the domain owner.This means that for each domain it can have both domain information and subdomains.
The data type used within the ERA and Domain Information contracts for storing data is a, "mapping".The gas used for storing and retrieving data from a mapping is not dependant on the number of entries in the mapping.As such, restricting data storage in the ERA contracts to this data type means that the gas usage is the same independent of the number of entries.
The Domain Information contracts hold information in a keyvalue mapping.The value is an array of bytes, the format of which depends on the key.The key is the Keccak-256 message digest of the raw key.The raw key has the format: Domain ":" Key Type.The domain can be a domain name (a1.aa.supply.com)or a wildcard (*), meaning the value for the key type applies to all domains in the Domain Information contract if domain specific values are not specified.
Standard Key Types have been specified in the documentation of the ERA reference implementation [5].User defined Key Types can be specified as a reverse domain name appended with dot separated names.For example, pegasys.tech has defined a Key Type tech.pegasys.sc.enc which is the public encryption key to be used for an Enterprise Ethereum node.

Gas Usage Evaluation
Gas is the fee charged for each instruction executed in Ethereum.Different instructions are charged different amounts of gas, with the fees reflecting the economic cost of executing the instruction.Users specify the price they are prepared to pay for the gas in each of their transactions.Miners preferentially include transactions in blocks which are configured to pay the highest gas price.As such, transactions which are submitted with a higher gas price are more likely to be included in a given block.
The Ethereum Gas Station [21] publishes live statistics on how quickly transactions will be processed based on the gas price specified for a transaction.For example, on August 28, 2018, it showed that some miners would process transactions at 0.6 gwei, however only three blocks in the past 200 had included transactions at this price.If a user was prepared to pay 2.6 gwei, then their transaction was likely to be processed within the next two blocks.Given an average block time of 15 seconds, this translates to transactions possibly being processed sometime in the next fifty minutes for gas prices of 0.6 gwei or with a high degree of probability processed in the next thirty seconds for gas prices of 2.6 gwei.This range of confirmation time versus gas price is shown in Figure 4. Confirmation times for gas prices below 1 gwei are either very high, or the transaction does not get mined at all.As the gas price increases, the confirmation time decreases.At 3 gwei, the transaction is likely to go into the next block.As such, there is no benefit to users for offering to pay gas prices above 3 gwei as the transaction is already likely to be mined as soon as it can be.In times of high network load, significantly higher gas prices may need to be paid to ensure transactions are mined in a timely manner.
The gas usage for the reference implementation of the Ethereum Registration Authority contract is shown in Table 1 and the gas usage for the reference implementation of the Domain Information contract is shown in Table 2.The values reflect the fact that the base cost of all transactions in Ethereum is 21,000 gas, that each write to a new storage location costs 20,000 gas, that subsequent writes to storage locations costs 5,000 gas, that gas is refunded for deleting storage locations, and that most other common functions cost relatively little compared to the cost of data storage.In the tables, the gas cost to US$ conversion is calculated based on an Ether price of US$284, and the fact that 1 Ether is 10 9 gwei.For transactions which are not time critical and involve a lot of gas, such as contract deployment, it makes sense to specify a low gas price such as 0.6 gwei.At this price, the Ethereum Registration Authority contract could be deployed for US$0.164 and the Domain Information contract could be deployed for US$0.091.For transactions which are time critical such as changing a value in a Domain Information contract which represents the public key to be used, a higher gas cost should be paid.Setting an ECC 256-bit public key which uses 96 bytes, with a gas price of 2.6 gwei, on the Domain Information contract would cost US$0.081if the storage locations occupied by the key had not previously been used and US$0.037 if they had.

Discussion
The goal of the ERA system is to allow bootstrap information to be determined securely to allow Ethereum Private Sidechains to be established on demand between parties that have not previously interacted.This section analyses whether the ERA system delivers on this goal and analyses its security.

Establishing Trust on Demand for Free
A user of the ERA system who wishes to establish a sidechain could determine the domain names of organisations which are going to participant in the sidechain and use the ERA system to resolve the Domain Information contract to be used for each domain.They could fetch the bootstrap information they need from the Domain Information contracts.As the user would be viewing existing information, and not submitting transactions, they would interact with the blockchain state on their local Ethereum node.As such, fetching this information would not cost anything.

Root ERA Business Model
The ERA system is likely to work only if ERAs are incentivized to behave well.There are likely to be two types of Root ERAs: Commercial and Regulated.A Regulated Root ERA would be an ERA which listed organisations that were members of a consortium, an association or other grouping.This type of ERA could be a central bank that listed all of the accredited banks within its jurisdiction, a professional body which listed member organisations, or a government regulator that listed accredited organisations.This type of Root ERA is incentivized to operate their ERA correctly to ensure they are held in high regard both by their member organisations and by users of the ERA system.
Commercial Root ERAs will charge organisations money to list with them.This type of ERA is similar to commercial root X.509 certificate authorities.They are incentivized to operate their ERA correctly to ensure organisations will wish to continue to be listed by them and to ensure users will continue to trust them.

Trusting Ethereum
The authenticity and integrity of the information stored in the Ethereum network is assured by the algorithms used by Ethereum and the diversity of miners.Users sign the transactions they submit to the Ethereum network.As such, miners and users can verify the authenticity of transactions.The three largest Proof of Work consensus algorithm miners would need to collude to mount a 51% attack [22] which would allow for the history of the blockchain to be re-written.As such, the information in the blockchain cannot be modified.Given this combination of authenticity and integrity, the Ethereum MainNet is deemed to have strong non-repudiation properties.
Though the Ethereum system typically cannot be modified, after a re-entrancy bug was exploited in the DAO attack [23], the system was modified to reverse the results of the attack.Doing this caused some to question trust in blockchain systems and Ethereum in particular [24].However, this type of history rewrite appears unlikely to occur again.Despite a bug in the Parity Wallet contract which resulted in hundreds of millions of dollars of funds becoming inaccessible, proposals to alter history to restore the funds have been refused [25] [26].

Trusting Domain Information
ERAs are responsible for ensuring that the domain names they list are owned by the entities purporting to own them.They are responsible for ensuring the Ethereum account which is used as the domain owner is owned by the entity.Doing this links the domain name, the Ethereum account, and the real world entity.
Typically, ERAs will need to undertake a Know Your Customer (KYC) audit and potentially an Anti-Money Laundering (AML) audit prior listing the domain.
An ERA which did not exercise due diligence prior to listing domains would be sanctioned.Users would not trust the ERA to provide information.Domain owners would not want to list on such an ERA.If the ERA was a delegate ERA, then Root ERAs may refuse to list the delegate ERA.

Malicious ERA and Existing Domains
The ERA Solidity contracts have been written such that once a domain has been registered, the owner of the domain is the only entity which can update the domain's listing, to change the Delegate ERA contract address, the Domain Information contract address, or the address of the owner of the domain.However, the ERA owner could delete a domain entry, create a new malicious domain entry with the same name, and then at some later point change the domain entry back to the original, thus temporarily providing malicious information to users.An ERA acting in this way could be detected by users observing changes to the ERA contract state and Finder results.Additionally, the actions of the malicious ERA would be recorded in the blockchain.An ERA acting in this way would be sanctioned.

Malicious Registration of Domains
A malicious ERA could maliciously list domain names and set the Delegate ERA contract address and Domain Information contract address to values of their choice.Similar to the abuse-case described above, this nefarious conduct could easily be detected, could not be later concealed, and would lead to the ERA being sanctioned.

Centralization
A concern with any authority system is that it leads to centralization.With the ERA system, owners of domains can choose to list their domains directly with any number of Root ERAs.They could operate a Delegate ERA and list that with any number of Root ERAs.An owner of an ERA could choose to not list it with any Root ERA.In this case, users would need to trust the ERA directly.Users of ERAs can choose to trust any number of Root ERAs.Users could choose to trust only specific Delegate ERAs.This flexibility of trust, where users can choose which Root ERAs to trust and domain owners can choose which Root ERAs to list in, means this solution can be decentralized.
In some consortium networks, for instance in an inter-banking scenario, a central bank may insist on operating the one and only Root ERA that the banks will use for the purposes of Ethereum Private Sidechains between banks.In this scenario, the consortium chooses to operate with a single Root ERA, recognising that it is a centralisation point.
Another aspect of decentralization of the ERA system is that domain owners can update their own information.They can choose what types of information to store in their Domain Information contracts.This is in contrast to the existing DNS system in which many Domain Registrars exercise control over what information can be stored in domain entries [13].

Censorship
If a Root ERA delisted a domain or a Delegate ERA, then the domain information for the domain would no longer be accessible by users which only trusted that ERA.Users could directly access the domain's Delegate ERA or Domain Information contracts.Additionally, the domain could be listed with multiple Root ERAs, thus allowing users to find the domain information via an alternative path.Given this, the ERA system has multiple ways of addressing censorship.

Conclusion
The Ethereum Registration Authority system allows Ethereum Private Sidechains to be established on demand between Enterprise Ethereum Clients operated by organisations that have not previously interacted.The system overcomes the limitations of previous techniques, providing organisations with a secure, decentralized, censorship resistant mechanism for storing information on Ethereum MainNet such that the information can be located using domain names and can be grouped according to different trust levels and different trust relationships.In particular the system allows users to obtain bootstrap information such as IP addresses, cryptographic verification keys and Ethereum addresses based on organisations' domain names.
A reference implementation of the Ethereum Registration Authority system of contracts has been developed which uses the same amount of gas, independent of the length of domain name and number of entries in the system.The implementation has been shown to be conservative with gas usage.The system can resolve domains and retrieve information based on a single function call, thus reducing latency and application complexity.
More work should be undertaken to explore Root ERA incentivization models and to standardize the Domain Information contract Key Types to promote interoperability between applications and registrars using the ERA system.This is particularly important as it is possible that the ERA system may be used for storing a wide variety of data, beyond just Ethereum Private Sidechain bootstrap information.

Figure 2
Figure 2 shows an example ERA set-up.In the example, there are two root registration authorities, A and B. Root ERA A has an

Figure 3 Figure 2 :Figure 3 :
Figure 3 shows the ERA system in the context of an Ethereum Sidechain Creator.The sidechain creator needs to determine a value from the Domain Information contract for s2.example.comand bank.co.uk.It uses a Finder contract to resolve the Domain Information contract to use for each domain and fetches the value based on the supplied key.Functions in the Finder contract only