XEM （NEM）新经币白皮书.pdf

NEMTechnical ReferenceVersion 1.2.1February 23, 2018ContentsPreface iii1 Introduction 12 Accounts and Addresses 22.1 Account state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 NEM addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.3 Converting a public key into an address . . . . . . . . . . . . . . . . . . . . 42.4 Intentional address collision . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Cryptography 73.1 Private and public key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2 Signing and verification of a signature . . . . . . . . . . . . . . . . . . . . . 83.3 Encoding and decoding messages . . . . . . . . . . . . . . . . . . . . . . . 84 Transactions 104.1 Transfer transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.2 Importance transfer transactions . . . . . . . . . . . . . . . . . . . . . . . . 114.2.1 Activating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2.2 Deactivating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.3 Multisig related transaction types . . . . . . . . . . . . . . . . . . . . . . . 114.3.1 Aggregate modification transactions multisig modification . . . . 124.3.2 Multisig signature transactions . . . . . . . . . . . . . . . . . . . . 124.3.3 Multisig transactions . . . . . . . . . . . . . . . . . . . . . . . . . . 134.4 Unconfirmed transactions spam filter . . . . . . . . . . . . . . . . . . . . 135 Blocks and the block chain 165.1 Block difficulty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.2 Block score . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.3 Block creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.4 Block chain synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . 196 A reputation system for nodes 216.1 Node interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216.2 Local trust value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216.3 Aggregating local trust values . . . . . . . . . . . . . . . . . . . . . . . . . 226.4 Enhancing the algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.5 Benefits of the reputation system . . . . . . . . . . . . . . . . . . . . . . . 247 Proof-of-Importance 267.1 Eligibility for Entering the Importance Calculation . . . . . . . . . . . . . 267.2 The outlink matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277.3 NCDawareRank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307.4 Clustering the transaction graph . . . . . . . . . . . . . . . . . . . . . . . . 327.5 Calculating Importance Scores . . . . . . . . . . . . . . . . . . . . . . . . . 347.6 Resistance to Manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . 357.6.1 Sybil Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357.6.2 Loop Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377.7 Nothing-at-Stake Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.8 Comparing importance to stake . . . . . . . . . . . . . . . . . . . . . . . . 398 Time synchronization 448.1 Gathering samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448.2 Applying filters to remove bad data . . . . . . . . . . . . . . . . . . . . . . 458.3 Calculation of the effective offset . . . . . . . . . . . . . . . . . . . . . . . 468.4 Coupling and threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 Network 499.1 Node Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499.2 Node Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509.3 Node Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509.3.1 Announcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509.3.2 Refresh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519.4 Node Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Preface“You miss 100 of the shots you don’t take. ”- Wayne GretzkyNEM is a movement that aims to empower individuals by creating a new economy basedon the principles of decentralization, financial freedom, and equality of opportunity.We would like to thank the contributors and the many people who have inspired us. . .BloodyRookie gimre Jaguar0625 Makoto1 Introduction“He’d say hello and introduce himself, but most of the cats turned a deaf ear,pretending they couldn’t hear him, or stare right through him. ”- Haruki MurakamiNEM, in its most basic , is a crypto currency that is built on block chaintechnology. The NEM block chain is an improvement on existing blockchain technologies. It integrates concepts from other cryptocurrencies e.g.Bitcoin and academic research in network theory.NEM’s primary contribution to the crypto currency landscape is a new consensus mech-anism called Proof of Importance PoI. Unlike Proof of Work PoW, it is environmen-tally sustainable and does not require large scale computing resources in perpetuity. PoIis similar to Proof of Stake PoS except that it is not solely derived from the size of anaccount’s balance. It incorporates other behaviors that are believed to be positive for theholistic economy. In this way, it attempts to reward active economy participants at theexpense of inactive ones and dampens the rich getting richer effect that is inherent toPoS.NEM’s vision is to be the foundation of a vibrant crypto currency ecosystem thatemphasizes security and trustless computing. NEM was launched with built-in supportfor multisig transactions and encrypted messages. Additionally, the peer-to-peer P2PNEM network implements a modified version of Eigentrust to identify and minimizethe impact of malicious nodes.NEM is evolving and this is just the beginning. Stay tuned for more things to come.Page 1 of 542 Accounts and Addresses“No wind serves him who addresses his voyage to no certain port. ”- Michel de MontaigneNEM uses elliptic curve cryptography to ensure confidentiality, authenticityand non-repudiability of all transactions. Each account is a privatepublicEd25519 keypair section 3 Cryptography and is associated with a mutablestate that is updated when transactions are accepted by the network. Ac-counts are identified by NEM addresses, which are derived in part from one way mutationsof Ed25519 public keys.2.1 Account stateThe state associated with each account includes the following items account balance number of harvested blocks see subsection 5.3 Block creation height of the first transaction that referenced the account list of multisig accounts and list of cosignatories see subsection 4.3 Multisig relatedtransaction types ination about delegated account status see subsection 4.2 Importance transfertransactions importance and NCD aware rank see section 7 Proof-of-Importance vested balance crucial for PoI and NEM itselfThe underlying crypto currency of the NEM network is called XEM. Each account’sXEM balance is split into two parts vested and unvested.Whenever an account receives XEM, the new XEM are added to the account’s unvestedbalance. When an account sends XEM, XEMs are taken from both the vested and theunvested balance, to retain the vested to unvested ratio1. Additionally, every 1440 blocks,110 of the unvested balance is moved to the vested part.1Of course that is not always possiblePage 2 of 540 2 4 6 8 10 12 14 16 18 20010,00020,00030,00040,00050,00060,00070,00080,00090,000daysvestedpartFigure 1 Vesting of 100,000 XEMAll accounts in the nemesis block2 are fully vested.2.2 NEM addressesA NEM address is a base-323 encoded triplet consisting of network byte 160-bit hash of the account’s public key 4 byte checksumThe checksum allows for quick recognition of mistyped addresses. It is possible to sendXEM to any valid address even if the address has not previously participated in any2first block in the NEM block chain3http//en.wikipedia.org/wiki/Base32Page 3 of 54transaction. If nobody owns the private key of the account to which the XEM is sent, thM is most likely lost forever.2.3 Converting a public key into an addressIn order to convert a public key to an address, the following steps are pered1. Per 256-bit Sha3 on the public key2. Per 160-bit Ripemd of hash resulting from step 1.3. Prepend version byte to Ripemd hash either 0 x68 or 0 x984. Per 256-bit Sha3 on the result, take the first four bytes as a checksum5. Concatenate output of step 3 and the checksum from step 46. Encode result using base32Example1. public keyX deb73ed7d0334e983701feba4599a37fb62e862e45368525b8d9fb9ab80aa57eY 169318abc3e5b002059a396d4cf1c3d35ba022c675b15fb1c4943f7662eef268Z a90573bd221a3ae33fec5d4efc4fa137897a40347eeafe87bee5d67ae5b4f7252. compressed public keyc5247738c3a510fb6c11413331d8a47764f6e78ffcdb02b6878d5dd3b77f38ed3. sha3-25670c9dcf696b2ad92dbb9b52ceb33ec0eda5bfdb7052df4914c0919caddb9dfcf4. ripemd 1f142c5ea4853063ed6dc3c13aaa8257cd7daf115. prepend version 681f142c5ea4853063ed6dc3c13aaa8257cd7daf116. sha3-256 of above09132a5ea90ab7fa077847a699b4199691b4130f66876254eadd70ae459dbb537. 4-byte checksum 09132a5e first 4 bytes of the above8. binary address 681f142c5ea4853063ed6dc3c13aaa8257cd7daf1109132a5e9. base-32 encoding NAPRILC6USCTAY7NNXB4COVKQJL427NPCEERGKS610. pretty-print NAPRIL-C6USCT-AY7NNX-B4COVK-QJL427-NPCEER-GKS6Page 4 of 54Public Key X Y32 bytescompressed-public-keyripemd160sha3 256 compressed-public-key 1 20 bytesNetwork byte0 x68 - main net0 x98 - test net sha3 256 1 20 bytes 32 bytes. . . 28 bytes4 bytes4 bytes20 bytes1binary address - 25 bytesNANEMO-ABLAGR-72AZ2R-V3V4ZH-DCXW25-XQ73O7-OBT5Base-32 encodingFigure 2 Address generationPage 5 of 542.4 Intentional address collisionIt is possible that two different public keys will yield the same address. If such an addresscontains XEM it would be possible for an attacker to withdraw funds from such account.In order for the attack to succeed, the attacker would need to find a privatepublickeypair such that the sha3 256 of the public key would at the same time be equal to theripemd-160 preimage of 160-bit hash mentioned above. Since sha3 256 offers 128 bits ofsecurity, it’s mathematically improbable for a single sha3 256 collision to be found. Dueto similarities between NEM addresses and Bitcoin addresses, the probability of causing aNEM address collision is roughly the same as that of causing a Bitcoin address collision.Page 6 of 543 Cryptography“I understood the importance in principle of public key cryptography but it’sall moved much faster than I expected. I did not expect it to be a mainstayof advanced communications technology. ”- Whitfield DiffieBlock chain technology demands the use of some cryptographic concepts.NEM, like many other crypto currencies, is using cryptography based onElliptic Curve Cryptography. The choice of the underlying curve is impor-tant in order to guarantee security and speed.NEM has chosen to use the Twisted Edwards curve−x2 y2 1− 121665121666x2y2over the finite field defined by the prime number 2255 − 19 together with the digitalsignature algorithm called Ed25519. It was developed by D. J. Bernstein et al. and is oneof the safest and fastest digital signature algorithms [2].The base point for the corresponding group G is called B. The group has q 2252−27742317777372353535851937790883648493 elements. Every group element A can be en-coded into a 256 bit integer A which can also be interpreted as 256-bit string and A canbe decoded to receive A again. For details see [2].For the hash function H mentioned in the paper, NEM uses the 512 bit SHA3 hashfunction.3.1 Private and public keyThe private key is a random 256-bit integer k. To derive the public key A from it, thefollowing steps are takenHk h0,h1,...,h511 1a 2254 summationdisplay3≤i≤2532ihi 2A aB 3Since A is a group element it can be encoded into a 256-bit integer A which serves as thepublic key.Page 7 of 543.2 Signing and verification of a signatureGiven a message M, private key k and its associated public key A, the following steps aretaken to create a signatureHk h0,h1,...,h511 4r Hh256,...,h511,M where the comma means concatenation. 5R rB 6S r HR,A,Mamodq 7Then R,S is the signature for the message M under the private key k. Note thatonly signatures where S 0 are considered as valid to prevent the problemof signature malleability.To verify the signature R,S for the given message M and public key A one checksS 0 and then calculates˜R SB−HR,A,MAand verifies that˜R R 8If S was computed as shown in 7 thenSB rB HR,A,MaB R HR,A,MAso 8 will hold.3.3 Encoding and decoding messagesNEM uses Bouncy Castle’s AES block cipher implementation in CBC mode4 to encryptand decrypt messages.If Alice has the private key kA and wants to encrypt a message for Bob who has thepublic key AB with corresponding group element AB then the shared secret used whensetting up the cipher is calculated as followsaA is computed from kA according to 2salt 32 random bytesG aAABshared secret ˜HG Y salt4http//en.wikipedia.org/wiki/Block_cipher_mode_of_operationCBCPage 8 of 54where ˜H is the 256-bit SHA3 hash function.Another 16 random bytes are used as IV data. Thus, the encrypted message payloadconsists of1. the salt2. the IV data3. the encrypted message blockDecryption works in a similar manner. Bob has to know Alice’s public key AA and hisown private key kB and the salt to derive the shared secretaB is computed from kB according to 2G aBAAshared secret ˜HG Y saltSupplying the shared secret and the IV data to the cipher engine decrypts the encodedmessage.Page 9 of 544 Transactions“To transact business with the girl who ran the gas-pump Dean merely threwon his T-shirt like a scarf and was curt and abrupt as usual and got back inthe car and off we roared again. ”- Jack KerouacTransactions introduce dynamism into a cryptocurrency system. They arethe only way of altering the state of an account. A newly created transactionthat has not yet been included in a block is called an unconfirmed transaction.Unconfirmed transactions are not guaranteed to be included in any block.As a result, unconfirmed transactions have no effect on the account state. The accountstate is only updated when a transaction is included in a harvested block and therebyconfirmed.Different types of transactions exist. Each type has a specific purpose, e.g. transferXEM from one account to another or convert an account to a multisig account. Sincetransactions consume resources of the p2p network there is a fee for each transaction. Thefee depends on the transaction type and other parameters of the transaction.Transactions have a deadl