Principle and design goals

Technology implementation

Consensus mechanism

 Proof of Devotion (PoD) Consensus Algorithm
5.1 Design Goals
The consensus algorithm is one of the cornerstones of blockchains, and its rapidity and irreversibility are our focus. In addition, in order to build a good ecology of Nebulas, we believe that fairness is equally important. IfthebigcapitalcaneasilygainpowertocontroltheblockconsensusinNebulas,theinterests of many developers and users will be damaged. It is difficult for an ecology which cannot guarantee the interests of contributors to create in-depth value, as it goes against the design principles of Nebulas. Thus, the consensus algorithm should be designed to ensure the rapidity and irreversibility first, on which basis we will pursue fairness as much as possible, so as to guarantee the interests of contributors in Nebulas.
5.2 Defects of Commonly Used Consensus Algorithms
We have tried to find suitable commonly used consensus algorithms that match with our design goals, but these algorithms cannot completely meet our requirements. The PoW (Proof of Work) consensus algorithm is a zero-sum game, which uses the competitive hash calculation to determine the bookkeeper, rendering a great amount of electric power in the whole ecology wasted in the competition when any blocks are fed out, and thus the mining cost is high and the speed is restricted. With the increase of nodes involved in mining, the probability of each node to obtain the bookkeeping right will be reduced, leading to a continuous rise in the cost of stable feed-out of blocks under the PoW protocol. The Bitcoin, which continues to increase the difficulty of mining, has to face the situation sooner or later where the mining machine cannot make ends meet, while Ethereum has long been considering the use of the new PoS consensus algorithm Casper [55] to gradually replace the current PoW consensus [11]. It can be seen that in view of the mining speed and the economic cost, the PoW is not beneficial to the long-term rapid development of the ecology of Nebulas, which is against our “rapid” goals. The PoS (Proof of Stake) consensus algorithm attempts to use the asset amount to replace the hash rateanddistributetheprobabilityofobtainingthebookkeepingrightaccordingtothecoinageordeposit amount. Currently, both Peercoin [28] and the Casper Protocol of Ethereum adopt the PoS consensus algorithm. ThisalgorithmovercomestheshortcomingofthehighpowerconsumptionofPoWbutvisually enlarges the impact of the capital on the probability distribution of the bookkeeping right. Compared with PoW, the big capital under PoS is more likely to gain power to control the ecology and form large group monopoly, possibly damaging the interests of the ecology contributors and impacting adversely on the value generation of Nebulas, all of which are against our “fairness” goal. The PoI (Proof of Importance) consensus algorithm was first proposed by Nem [38]. Different from PoS, the concept of account importance is introduced to PoI, and the account importance score is used to distribute the probability of the bookkeeping right. This algorithm overcomes the shortcoming of the high power consumption of PoW and relieves the PoS capital monopoly crisis, but exposes the “nothingat-stake” problem. The cost for a cheater to reverse a block is significantly reduced, which goes against our “irreversibility” goal. In short, in view of the discrepancy between commonly used consensus algorithms and our goals, we haveproposedthePoD(ProofofDevotion)algorithmtointegratePoI,whichevaluatesthecomprehensive account influence, with PoS, which involves strict economic penalties. PoS enhances the irreversibility of PoI, while PoI reversely contains the monopoly of PoS, which facilitates the free and rapid development of the ecology.

5.3 Design of the PoD Algorithm
5.3.1 Generation of New Blocks
Similar to the PoI consensus algorithm that selects highly important accounts, the PoD selects the accounts with high influence in the ecology. The difference lies in that the PoD empowers the selected accounts to have the bookkeeping right with equal probability to participate in new block generation in order to prevent tilted probability that may bring about monopoly. When selecting accounts with high influence, we use NR, the universal measure of value generated from Nebulas. In the algorithm design of NR, we highlighted the liquidity and propagation of accounts (see §2.1). We believe that the accounts featured with these properties have a high influence with regard to the ecology construction. Thus, in the PoD, the accounts ranked Top N in the NR will be selected, and after these accounts voluntarily pay a certain number of NASs as the deposit, they will be qualified as the validator of new blocks to participate in bookkeeping. After the validator set is provided, the PoD algorithm uses the pseudo-random number to determine which one in the set is the new block proposer, which need to pack recent transactions to generate the new block. The validator set is changeable. The eligible account can choose to join or quit the set. Besides, the eligible accounts may vary with the periodical change of NR. Therefore, we designed the dynamic validator set change mechanism in the PoD to implement the change of the validator set.
5.3.2 Dynamic Validators Set
The validator set changes the same way as a dynasty, so the set is divided into different dynasties, and the validator set within a dynasty will not change. A dynasty cannot experience too rapid change, and no change should be made within a period of time. Thus, we define every X blocks as an Epoch, and in the same Epoch, no change takes place in the dynasty. Therefore, the change of dynasties will only occur when one Epoch is handed over to another. At that time, the first block of the previous Epoch will be investigated. If this block reaches the finality state, then the current Epoch will enter into the next dynasty of D1; otherwise, the previous dynasty of D0 will remain; the process of which is shown in Because of the network delay, the finality state of Block G at each node may not be the same when any change of dynasties takes place. Therefore, by reference to dynamic Casper validator set strategies, it is required that the consensus process of each dynasty will be completed jointly by the validator sets of the current and previous dynasties. Therefore, in any dynasty, an eligible account can only apply for joining or quiting the validator set of Dynasty D+2, and when the dynasty evolves into Dynasty D+2, it can participate in the consensus process of the new block.

Accounts and transactions

Appendix A Nebulas Account Address Design
We carefully design the Nebulas account address to start with “n”, which is short for “Nebulas”.
A.1 Account Address
Similar to Bitcoin and Ethereum, Nebulas also adopts an elliptic curve algorithm as its basic encryption algorithm for Nebulas accounts. The address is derived from the public key, which is in turn derived from the private key that is encrypted with the user’s passphrase. AlsowehavethechecksumdesignaimingtopreventauserfromaccidentallysendingNAStoawrong user account due to entry of several incorrect characters. The specific calculation method is provided as follows:
content = ripemd160(sha3_256(public key)) checksum = sha3_256(0x19<<(21*8) + 0x57<<(20*8) + content)[0:4] address = base58(0x19<<(25*8) + 0x57<<(24*8) + content<<(4*8) + checksum)
in which 0x19 is for padding, and 0x57 specifies the type of address. Notice that the length of content is 20 bytes, the length of checksum is 4 bytes, and the length of address is 26 bytes. A Nebulas address contains a total of 35 characters including the prefix “n”, which is encoded with base58. A typical address looks like this n1TV3sU6jyzR4rJ1D7jCAmtVGSntJagXZHC.
A.2 Smart Contract Address
Calculating the smart contract address differs from account slightly. The passphrase of the contract sender is not required. Instead, we need the sender’s address and the nonce. The calculation formula is as follows:
content = ripemd160(sha3_256(tx.from, tx.nonce)) checksum = sha3_256(0x19<<(21*8) + 0x58<<(20*8) + content)[0:4] address = base58(0x19<<(25*8) + 0x58<<(24*8) + content<<(4*8) + checksum)
in which 0x58 indicates the address type for smart contract. A typical smart contract address looks like n1sLnoc7j57YfzAVP8tJ3yK5a2i56QrTDdK.

Smart contract system

Appendix B Search for Similar Smart Contracts
The difficulty in code similarity lies in structural features of high-level language and diversity in the forms of logical expression of smart contracts. At present, there are various schools of code similarity algorithm in the academic circles, which are generally described as follows: • Edit Distance between Character Strings Both of the entered query code and candidate source code are deemed as texts. Edit distance between two character strings is used for measuring similarity between them. Edit Distance refers to the minimum number of editing operations required for converting one character string into the other character string. Permitted editing operations include replacement of one character with another character, i.e. insertion of a character and deletion of a character. Generally speaking, the shorter the edit distance, the higher the similarity between two character strings. This algorithm based on edit distance between character strings can be used not only for source code comparison but also in intermediate representation or even machine language. For the purpose of improving the robustness of the algorithm based on edit distance between character strings, a certain degree of conversion of the source code without any semantic change will be conducted, such as removal of blank character, removal of annotation, replacement of names of all local variables with ‘$’, normalized expression of algebraic expression, etc. This algorithm is characterized by fast speed, conciseness and high efficiency. However, its adaptability to complex programs is relatively poor and doesn’t take syntax and organizational structure of code into consideration. • Token Sequence Token sequence representation method refers to the conversion of the entered source code into a Token sequence through the analysis by a lexical analyzer. Similarity between two programs is similarity between two Token sequences, so the longest common substring or correlation matching algorithm (suffix treematching algorithm) maybe used to measure the degreeof similarity between two programs, through which code segments with different syntaxes but similar functions can be detected. However, this method conceals organizational structure of programs when measuring the similarity between two programs. • Abstract Syntax Tree (AST) AST is an intermediate expression form after syntactic analysis on a source code is conducted, based on which the similarity between two programs can be measured through comparison between one subtree and another subtree. For measurement of the similarity between two trees, the tree edit distance algorithm [58] may be used. The accurate tree edit distance algorithm is relatively complex and Literature [25] provides an approximate fast algorithm. According to Literature [15], syntax tree should be subject to Hash fingerprint in order to enable the syntax tree comparison algorithm to conduct high-efficiency searching on massive datasets. • Program Dependency Graph (PDG) PDG[18]canrepresentinternaldataandcontroldependencyrelationshipofaprogramandanalyze program code at the semantic level. Similar code protocol becomes search of isomorphic subgraphs, whichistheNP-completeproblemandrequiresaverycomplexalgorithm,soonlysomeapproximate algorithms are available currently.

We believe that the abovementioned algorithms describe similarity between codes in text, structure and syntax at different dimensions. Source Forager [27] provides a great engineering thought: Indexes of similarity at various dimensions are depicted as different features, each of which represents code similarity measurement from a specific aspect. Finally, vector similarity is used to conduct overall similarity measurement. This method integrates the advantages of the abovementioned algorithms. This thought is also used by Nebulas for reference in realizing search of similarity among smart contracts. We deem function as the fundamental unit of code search among smart contracts. 

Cryptography

Distributed storage protocol

There are some solutions to the upgradeable design of the smart contract in Ethereum, which are generally divided into two categories. The first one is the Proxy Contract available to the public. Its code is very simple, only forwarding the request to the following real function contract. When the contract needs upgrading, just make the pointer of the internal function contract of the Proxy Contract point to the new contract. The second one is to separate the code contract from storage contract. The storage contract is responsible for providing the external contract with methods to read and write the internal state. The code contract is responsible for the real business logic, and when upgrading, it is only responsiblefordeployingthenewcodecontractsoastolosenostate. Thesetwosolutionshavetheirown limitations correspondingly, so they cannot solve all the problems. For example, the separation between the code contract and storage contract makes it more complicated. Sometimes it is even unfeasible. Although the Proxy Contract is able to point to the new contract, the state data of the old contract cannot be migrated. Some contracts are not well designed at the initial development stage, so they fail to leave any interface for later upgrade. 

Cross-chain and exchange technology

Special technology

Economic model and incentive

 PoD Economic Analysis
5.4.1 Incentive Analysis
A validator participating in the PoD algorithm will be rewarded with 1x NAS on each legal block. In case of failure in finishing the Prepare stage and entering into the Commit stage due to poor network traffic or any cheating behavior, the validator will lose 0.5x NAS. Therefore, any validator becoming value nodes will secure a large amount of earnings from accounting under good network traffic when not engaging in any cheating behavior.
5.4.2 Cheating Analysis
Double-spend Attack
If it is assumed that a merchant confirms transaction and makes delivery when the new block reaches the status of finality, then the minimum cost to be paid by a fraud for realizing zero-cost shopping through completion of double-spend attack under the PoD consensus algorithm is described as follows: Firstly, the fraud needs to increase his/her Nebulas Rank to Top N, become a validator by paying a certain amount of NAS as deposit and apply for participation in validation of blocks in the D+2 dynasty.
Then, the fraud needs to be selected as the proposer of a new block by the pseudo-random algorithm. At this moment, the fraud proposes two new blocks at the same height, of which one block has a hash value of hash1 and contains a transferring transaction from the fraud to the merchant, while the other block has a hash value of hash2 and contains a transferring transaction from the fraud to himself/herself. Finally, in order to make both of hash1 and hash2 blocks reach finality, as shown in Fig.15, the fraud has to spend 1/3 of the total deposits in this dynasty to bribe 1/3 of the validators and make them to deliver Commit votes to both blocks.

Therefore, in order to complete a successful double-spend attack, the fraud needs to spend a certain amount of energy and financial resource to increase his/her Nebulas Rank (see §2.4 Resistance to Manipulation) and then spend at least 1/3 of the total deposits in current dynasty to make both of the blocks reach the finality status after he/she is luckily selected as a proposer.
51% attack
In PoW, launch of a 51% attack requires 51% of hashrate. In PoS, launch of a 51% attack requires 51% of deposit. However, in PoD,launch of a 51% attack requires 51% of accounts in the validators set, which means that a sufficient number of highly-reputed users need to rank at Top N in the Nebulas Rank and payment of a corresponding amount of deposit is required, so it will be more difficult to launch a 51% attack in PoD.
Short-range Attack
In PoD,block sat each height have term of expiration time of consensus. Therefore,it is almost impossible to complete a long-range attack in PoD, but it is still possible to launch short-range attacks within term of expiration time. When a short-range attacker (Attacker) attempts to forge A-chain to replace B-chain to become the canonical fork when block sat the height of H+1 are still with intermofexpirationtime,Attackerneedsto ensure that score of block A1 is higher than that of block B1. Multiple voting will be severely punished, so it will be unavoidable for Attacker to bribe validators; otherwise, it is impossible to complete a shortrange attack. For the purpose of presenting the safety of the PoD consensus algorithm, the costs to be paid by Attacker in reverting different numbers of blocks are analyzed as follows.

If Attacker plans to revert B1, the minimum cost to be paid by Attacker is as described in Fig.16, which is equivalent to a double-spend attack. If Attacker becomes the proposer of blocks at the height of H+1, then he/she has to bribe 1/3 of the validators in Dynasty D0 and make them conduct multiple voting in order to make A1 reach finality, for which the minimum cost is 1/3 of the total deposits.

Assume that B1 and B2 have reached the status of finality and transactions in the blocks have come into effect. If Attacker wants to revert B1-B2, the following two circumstances are taken into consideration.
• The first circumstance is shown in Figure 17 (a): When Heights H+1 and H+2 are in the same Epoch and dynasty, Attacker needs to bribe 1/3 of the validators in D0 in order to make A1 reach finality. Meanwhile, these 1/3 of the validators will be punished and their deposits will be totally confiscated. During validation of A2, sum of deposits equals to 2/3 of deposits in A1. At this moment, if Attacker wants to secure the same amount of commit votes as B2, he/she has to bribe all the remaining validators without cheating and lose at least 3/3 of the total deposits. Even if Attacker succeeds in doing this, it is impossible to guarantee that score of A1 is higher than that of B1 and Attacker will face a high risk of failure of attack. • The second circumstance is shown in Figure 17 (b): When Heights H+1 and H+2 are in different Epochs and different dynasties, Attacker needs to bribe 1/3 of the validators in D0 to make A1 reach finality and then bribe 1/3 of the validators in D1 to make A2 reach finality, so Attacker will lose at least 2/3 of the total deposits in order to complete such an attack. To sum up, to launch a short-range attack to cause invalidation of two blocks that have reached finality, Attacker needs to pay at least 2/3 of the total deposits.
If Attacker wants to revert B1-B3, as shown in Figure 18, Attacker needs to firstly bribe 1/3 of the validators in D0 in order to realize finality of A1 and then bribe 1/3 of the validators in D1 in order to realize finality of A2. Finally, Attacker needs to bribe all of the remaining 2/3 of the validators in D1 in order to realize finality of A3. To sum up, 4/3 of the total amount of deposits will be lost. It will be very difficult to prepare for these attacks. Even if an attacker manages to succeed in making necessary

Governance mechanism

Applications

The self-evolving of blockchain system and applications We believe that a well-conditioned system and the applications on it should be able to be selfevolving,tohaveabilitytoachievefastercomputing,betterresilience,andenhanceduserexperience under little intervention. We call this self-evolving ability “Nebulas Force” (see §3). In Nebulas’ System architecture, due to our well-designed block structure, our base protocols will become part ofthedataontheblockchainandachieveupgradethroughtheadditionofdata. Asforapplications (smart contracts) on Nebulas, we make the upgrade of smart contracts possible by enabling crosscontract access to state variables at the bottom layer storage of smart contracts. The self-evolving Nebulas blockchain will be advantageous over other public blockchains in terms of developmental and survival potential. It also allows developers to respond faster to loopholes with upgrades and prevents huge losses caused by hacking.