Xcoin Platform​ The Blockchain Superhighway​ (Launch soon)







  • Xcoin is a high scalable blockchain infrastructure based on hybrid proof-of-work and Byzantine fault tolerance consensus.

    Abstract. Present consensus methods, including Proof-of-Work, achieve a prohibitive trans-action throughput for large-scale applications, including the mainstream exchange of the digi-tal currencies that secure them. Additionally, transactions cannot be confirmed until a new block has been mined. We present Xcoin, wherein a dynamic group of replica nodes acts as validator committee within a Byzantine fault tolerance-based blockchain system. The system adopts proof-of-work instead of certificate authority to allow its open participation. Leader election and transaction validation are decoupled into two separate blockchains. Transactions are permanently recorded once verified by more than two-thirds of majority of members within the validator committee.



    Double Chain Mechanism:


    Within Bitcoin’s consensus, only one block exists at a certain height, because a transac-tion cannot be spent more than once. This not only generates several unconfirmed orphaned blocks, but also leads to prolonged transaction time. Under the double chain mechanism, be-cause the configuration of the validator committee is already achieved before voting starts, all transaction blocks are verified instantly without mining and confirmation time. The consensus of transaction blocks is achieved via Byzantine fault tolerance. A transaction block includes transaction records, Merkle root, UNIX timestamp, hash of the last block and the current elec-tion chain. The mining-independent transaction chain allows itself to have dynamic block time and size. Voting

    Voting process 

    The Xcoin consensus is de facto the process of state machine replication. Each round of validation consists of three phases: 


    pre-prepare 

    prepare and commit. Pre-prepare The leader node sends a message to all incumbent nodes and waits for their reply.


    • Prepare

    Incumbent node validates the message and sends a response to the leader node. If 2/3 majority of a quorum is achieved, then the leader broadcasts announces to proceed to the next phase. During the voting stage, a node can have three possible kinds of responses:
    1. The node approves the message.
    2. The node refused to approve the message.
    3. The node did not respond before timeout.


    Non-responding nodes are routinely excluded from the validator committee. Therefore, the voting process continues in the event of more than 1/3 validators become unreachable.


    Commit

    If a block receives 2/3 or more approval from incumbent validators, it will be committed to the blockchain and broadcast to all nodes in the network.
    If the leader node commits malicious behavior or fails to respond within a set time, other validators can impeach the leader by initiating a view change to replace the leader with the next candidate.


    An attacker cannot outvote honest nodes by creating millions of fake nodes to control the 2/3 majority, because all validators must provide proof-of-work before the network accepts them.




    Multi-sig voting

    To illustrate the voting process, we draw an analogy between the voting process of United Nations and Xcoin. In the General Assembly, delegates of each country can sign the draft as approval and each other can see who has signed. However, in peer-to-peer system there is no central authority that maintains identities of all nodes. How can the network make sure that all signatures are trusted? A simple approach is for each node to keep a list of all public keys of other nodes, which can be used to verify against their signatures. This means that for total of N nodes, each verification step takes N2 times of check against signatures. When the number of node grows, it could become considerably expensive to verify all signa-
    tures. Hence, we introduce a collective signing algorithm. It can produce a collective signa-ture with a group of decentralized nodes so that each node only needs to verify this signature once. The signing process has four steps:


    Announcement

    The leader announces a new round of voting, and multicast the announcement to all vali-dator nodes via a spanning tree from top to bottom.


    Commitment

    When a node receives the message from the leader, it generates a random key and uses that key to compute a Schnorr signature. Then it combines this signature with its direct child nodes and sends back to the leader.


    Challenge

    The leader computes a Schnorr challenge with a hash function, then multicast it along with the message M to all validators.


    Response

    With the collective challenge from the last step, all nodes return a combined response from leaf to root.
    The leader executes the signing process first time during the pre-prepare phase. How-ever, some nodes may lose contact, and then the leader must execute the signing process again during the commit phase. Two rounds of signing guarantee that the result comes from all responsive nodes.
    Tree multicast is flawed in itself; its stability is crucially depending on the leader node. We made improvements of this protocol to ensure that in the events of leader failure, a re-configuration process will start and the rest of nodes can continue to operate without causing errors.


    Smart contract

    To support more advanced and flexible transactions, Xcoin comes with a stack-based scripting system, also known as a smart contract. The smart contract runs inside an Xcoin vir-tual machine. Smart contracts can be programmed to create more complex decentralized apps, such as deferred payment, advanced access management and user defined digital assets. The high throughput of Xcoin is capable of satisfying large-scale requirements of enterprise appli-cations. The syntax of the scripting system will be similar to Bitcoin’s, which can perform basic mathematical operations and logic expressions.


    Use cases

    Alongside value transfer, an Xcoin smart contract can support storage for various for-mats of data. The distributed storage of Xcoin blockchain provides better stability and is ideal for anyone seeking high availability and security of their information Below is an incomplete list of use case scenarios of Xcoin.


    Finance

    Stock, bonds and other financial instruments can be implemented using Xcoin block-chain. Comparing with traditional exchange centered system, blockchain based solution is more effective and costs less.


    Digital contract

    An agreement between two or more parties can be signed with their digital signatures, which renders the agreement immutable in future. An Xcoin smart contract can also imple-ment asset ownership, wills and certifications.


    Messaging

    Xcoin’s built-in transaction fee mechanism can effectively prevent spamming. This al-lows users for more valuable and secure information exchange.


    Voting

    Xcoin can permanently store voting records for organizations and institutions, such as shareholder voting, governmental bidding and ballots. Voting result can be executed immedi-ately, or deferred until a time in future


    Notarization

    Traditional notarization relies on a trusted third party agency. The Xcoin blockchain can directly verify information while improving efficiency and security compared to traditional methods.


    Secure data storage

    Xcoin’s dynamic node election mechanism ensures that all nodes are replaced after a certain period, therefore minimizes the possibility of single point of failure. This feature makes it ideal to store high value critical data.


    Internet of Things

    Xcoin can register billions of IoT devices and enhance their security. Nodes can verify each other’s authenticity via information registered with Xcoin.



    Cryptographic algorithms

    Mining The process of mining is defined as nodes competing by their speed of hashing the block header, until a value less than the current difficulty d is found by one of the nodes. This diffi-culty is adjusted according to total computing power in the network in order to maintain the mining time within a certain range. Because it is virtually impossible to decipher the block header from the hash value, nodes must repeatedly try with a random nonce until the correct hash is discovered. As d becomes smaller, the computing power required to find the hash be-comes proportionally larger. Although it requires billions of calculations to mine the correct hash, it only takes one calculation to verify whether the hash is correct. The mining algorithm used by Bitcoin, SHA256, is vulnerable to Application Specific Integrated Circuits (ASIC) because they have significant advantages over CPU for mining purpose. The centralized pro-duction and employment of ASICs also contributes to centralization within a permission-less system. Xcoin proposes the use of an ASIC-resistant CPU mining algorithm which is bound to device memory.


    Address generation

    Xcoin uses Ed25519, an implementation of Schnorr signature algorithm, for its address generation. Ed25519 is faster than ECDSA, and has smaller size, thus making it the ideal sig-nature algorithm for cryptocurrency. A quad-core Intel 2.4G CPU (Xeon E5620) can validate 109,000 of Ed25519 key-pairs per second.
    The process of address generation:
    1. A Ed25519 key pair is generated
    2. A SHA3-256 hash is generated from step 1
    3. The RIPEMD-160 of step 2 is calculated
    4. The Base58 string is computed from step 3. This is the final unique ad-dress


    Transaction

    Traditional centralized payment-processing works by maintaining a list, which contains account, balances of all users. A transfer in such system is simply addition of one account and subtraction of the other. All transactions of an account can be easily linked. To protect user privacy and decentralization, Xcoin perceives account balances as unspent transaction out-puts, similar to bitcoin. In the transaction chain, each individual transaction consists of one or more inputs and outputs. Excluding the coinbase-output, input transactions are outputs from previous transactions, which designates this specific address as receiver. The input also con-tains sender’s signature, which can be verified against his public key. The output contains re-ceiver’s address. The balance of an account is the sum of all UTXO associated with it. An UTXO can only be spent once and the remainder will be refunded to the sender as change. Furthermore, client nodes can prune transactions that are too old and only keep UTXO.


    Coinbase transaction

    Coinbase is a special variant of a transaction. It does not have a sender address, but is awarded to validator nodes for validating transactions. This reward is determined by the cur-rent reward of the network. Unlike Bitcoin, the coinbase transaction of Xcoin does not occur immediately after an election block is mined, but after the tenure of current validator commit-tee has ended. This mechanism effectively ensures the honesty of nodes and suppresses self-ish-mining in Bitcoin.


    Transaction fees

    Because nodes consume resources such as electricity and bandwidth, and computing power in order to validate transactions, it is necessary for the sender of a transaction to in-clude a fee proportionate to the resources required to process it. This mechanism also miti-gates spam or 'dust' transactions. The difference between all transaction inputs and output is the transaction fee paid to the nodes.


    Multi-sig

    Sometimes it is insufficient to have only one signature for security concerns. Multi-sig requires all or at least two parties to sign the transaction before it can be executed. The Xcoin scripting language will provide native syntax for multi-signature transactions.


    Transaction verification

    When nodes begin syncing the blockchain, they first pick the election chain containing the most recent, longest chain of proof-of-work, then verify whether each transaction block associated with the election chain contains the collective signature of the validator committee. The verification of a single transaction is done by the incumbent validators. If one of the fol-lowing conditions is true, then the transaction is considered invalid:
    The signature of the transaction does not match sender’s private key
    The total output exceeds total input

    The input transaction has already been spent
    Nodes can validate the occurrence of a prior transaction by checking the Merkle tree. A Merkle tree is a binary tree by combining the hash of two adjacent transactions, until there is only one hash left. This hash is called the Merkle root. Any change to in the block will cause this value to change. Each transaction block contains the Merkle root of all transactions within. Through merging Merkle tree branches, a node can verify the transaction without downloading the entire blockchain.



    Security

    An attacker cannot forge a transaction of another user without obtaining the user’s pri-vate key first. In the worst-case scenario, he can only attempt to recall his own transactions by modifying the block history. All nodes must check if a key block contains enough Proof-of-work before accepting it and all transaction blocks associated with it.
    If a node becomes aware that it is maliciously excluded by another validator, it can broadcast view change to other validators and have the malicious validator removed from the committee. However, merely corrupting 1/3 validators is insufficient to allow the attacker re-write the blockchain history. Consequently, a malicious actor also must outvote the rest 2/3 honest validators to get the transaction block passed, and requires over 2/3 total computing power in the network to do so. In the unlikely event the attacker is able to outrun all honest nodes, he can only reverse his own payment in the past, which is unlikely to yield more profit than being honest. The rest of nodes can still verify all transactions if they are willing to.
    The validators does not receive their reward immediately, but only after they have vali-dated all transaction blocks designated to them. If during any round, a node goes offline, it will not receive any reward, and thus, nodes are encouraged to continue validating.



    Conclusion

    We have proposed a reconfigurable Byzantine fault tolerance based blockchain without permission authority. To allow anonymous participation of everyone while being resistant to Sybil attack, we introduced Proof-of-work as the node election mechanism. The elected nodes will only hold temporary position to verify transactions, thus the network will retain its decen-tralization. Confirmation time is no longer required as the mining process and transaction ver-ification are decoupled; therefore, transactions are confirmed without waiting. Our system has shown promise to mitigate the scalability problem that permission-less blockchain currently facing. The system can be further developed into different use cases such as permissioned and Proof-of-stake blockchains.


    Links:

    Website:

    Team:

    FAQ:

    Contact:

    More Information Soon!



Looks like your connection to Cryptocentral was lost, please wait while we try to reconnect.