What is Cypherium and why it makes a diffrent?
Introduction
Since the inception of Bitcoin, the first public blockchain, researchers, engineers, and entrepreneurs throughout the world have wanted to expand this technology to a broader range of applications. Ethereum, the world’s first blockchain with Turing-complete smart contracts, made a bold attempt to transform blockchain into a general-purpose computing platform.
Although the early pioneers first mapped out blockchain’s potential as a digital payment network and a collaborative data sharing platform, poised to reshape human society entirely, the stark reality of the last ten years has shown us that these technologies were simply not ready to achieve these lofty goals. Blockchain has yet to see“killer dApps” other than the issuance of digital currencies. Even Bitcoin has not attained its original goal of “a peer-to-peer cash payment system”.
As regulatory bodies around the world began to impose stricter regulation over ICOs, with some completely banning them, blockchain and crypto fell into a long period of hibernation.
However, blockchain technology’s revolution has never stopped. Two of the most prominent digital currency projects were announced in 2019: Facebook’s Libra and People’s Bank of China’s DC/EP. Although these projects appear to have abundant resources and a huge potential user base, they are not the best use cases of blockchain technology because they revert back to the use of trusted third parties to expedite their regulatory compliance. However, true decentralization should not run into conflict with any regulator. Just as the internet is permissionless, blockchains can be both fully realized in their decentralization and governed with meaningful oversight.
The Cypherium team, hereby set forth five goals for thier project:
An instant ledger to process real-time transactions for billions of users.
A smart contract platform to enable enterprise use cases for all industries.
A trusted database to connect isolated data islands around the world.
An open network to enfranchise any participant or contributor.
A secure vault to combat the increasing threats to data privacy.
To achieve our goals, we have built Cypherium only on a foundation of the most cutting-edge and bulletproof technologies to date.
Technical Background
A blockchain is a data ledger shared across a network of nodes, which store and replicate a consistent state of transactions. According to the admissions mechanism of the network, a blockchain can be classified into two categories: permissionless (open to any participant) and permissioned (open only to credentialed members). Typically, a blockchain consists of three layers: network, consensus, and smart contract.
A network is a collection of interconnected nodes that exchange information. The nodes can include computers, servers, mobile devices, or any other device that can be configured to communicate with other nodes in the network. The network may be configured as a centralized system, such as a client-server system having one or more central servers in communication with one or more client devices, or may be configured as a decentralized system, such as a peer-to-peer (P2P) network. A P2P network is a system in which each network node, sometimes called a “peer,” may be directly connected to one or more other nodes in the network. Peers typically have similar privileges and may share a portion of their resources with other peers in the network without coordination by any centralized servers or hosts. P2P networks have been implemented using various technologies, including for example file-sharing systems, such as Napster, and blockchain technologies, such as Bitcoin.
A transaction-based system is a system that processes data in units of “transactions,” which may have different contents, formats, or other characteristics depending on the system. An example of a conventional transaction-based system is Sabre, which is a system used by travel agents and companies to process transactions that are used to book airline tickets. A transaction may be a message, event, or process initiated or invoked by a user or computer program and may provide a single unit of work in the system. For example, a transaction may contain data corresponding to an electronic funds transfer between different bank accounts. A transaction could also correspond to an event when two or more parties enter into an agreement, such as a legal contract. In this example, the action of entering into the agreement is processed and recorded as a single transaction, and the transaction data may correspond to the agreement itself and/or any other information relating to the agreement. In another example, each transaction may correspond to the identity of the party or parties that have signed an agreement, in which case the signing of the agreement by each party is processed and recorded as one transaction. A transaction, alone or combined with other transactions, may be represented or transmitted as a unit of data. In a Bitcoin setting, a transaction usually is defined as the transfer of a certain amount of Bitcoin cryptocurrency from one Bitcoin account to another.
To facilitate a demand for higher speed processing and convenience in transaction-based systems, some transaction-based systems have been built on network infrastructures. Originally and conventionally, such systems have been implemented in centralized networks: all the transactions were processed by centralized servers and the related transaction data was stored in centralized databases. The system reliability thus depended solely on the reliability of the centralized system. A failure of the centralized server could cause catastrophic results to the transaction-based system.
A decentralized transaction-based system, sometimes referred to as a distributed transaction-based system, is desirable because the system depends less on centralized servers and, thus, may be more reliable. Implementing such a distributed system on a P2P network is often preferred because the necessity of using a centralized host server is eliminated and the system is reliable until many network nodes fail at the same time, which is typically unlikely. However, implementing such a distributed transaction-based system is challenging because the lack of a centralized host may result in complicated and dynamic component interdependencies. Several critical issues must be solved: for example, how is transaction data organized and stored in the system; how is a consensus reached by the network nodes to confirm or reject a new transaction request; and how are network nodes in the system authenticated and/or their authentication verified.
Unlike in a centralized system, data in a distributed P2P system may be stored as many copies, for example, by one or more of the network nodes. For example, each node may have a copy of the entire data set in a transaction-based system or it may store only a portion of the data. Many schemes have been designed to ensure that each network node may effectively store and verify the system data through cooperation with the other nodes.
One exemplary scheme uses blockchain technology, which is widely known as the technology behind the popular cryptocurrency Bitcoin. In a blockchain scheme, transaction data can be organized into discrete “blocks,” each of which may be linked with a predecessor (“parent”) block by storing a cryptographic hash value of the parent block, or by using other techniques such as using hash values and/or digital signatures of one or more preceding blocks. The contents in each block can be verified against its cryptographic hash value stored in a subsequent adjacent (“child”) block. Therefore, once the accuracy of the current block of the blockchain is verified, a network node can verify every preceding block contained in the blockchain without having to contact any of the other nodes.
To ensure that data is valid and consistently replicated over all nodes in the network, a blockchain requires that a consensus mechanism determine the validity of the blockchain data. Bitcoin introduced the Nakamoto consensus, named after its pseudonymic author. In the Bitcoin network, nodes recognize the version of the chain with the greatest number of valid blocks as the “real” blockchain.
CypherBFT
Cypherium’s proprietary consensus algorithm, CypherBFT overcomes disadvantages of the prior art by providing a distributed transaction system including a group of validator nodes that are known to each other in a network but are indistinguishable to the other network nodes in the network. As used herein, the group of validator nodes may be referred to as a “Committee” of validator nodes. In some embodiments, the system reconfigures one or more validator nodes in the Committee based on the results of proof-of-work (POW) challenges. According to some disclosed embodiments, a network node that is not already a validator node in the Committee may be added to the Committee if it successfully completes a POW challenge. In such an event, the network node may become a new validator node in the Committee, replacing an existing validator node. In alternative embodiments, a network node may become a new validator node in the Committee based on a proof-of-stake (POS) consensus. In yet another embodiment, a network node may become a new validator node in the Committee based on a proof-of-authority (POA) consensus. In other alternative embodiments, a network node may become a new validator node in the Committee based on a combination of any of POW, POA, and POS consensus.
In some disclosed embodiments, the new validator node replaces a validator node in the Committee. The replacement may be based on a predetermined rule known by all the nodes in the network. For example, the new validator node may replace the oldest validator node in the Committee. According to another example, the new validator node may replace a validator node that has been determined to have gone off-line, become compromised (e.g., hacked), failed (e.g., due to hardware malfunction), or otherwise is unavailable or no longer trusted. In the exemplary embodiments, the distributed system assumes that for a fault-tolerance of f nodes, the Committee includes at least 3f +1 validator nodes. Because the validator nodes in the Committee may be frequently replaced, for example, depending on the amount of time required to complete the POW challenges, it is difficult for malicious third parties to detect the complete set of validator nodes in the Committee at any given time.
Cypherium, on the other hand, runs its proprietary CypherBFT consensus, anchored by the HotStuff algorithm, and can authentically offer instant finality for its network users. With its HotStuff-based design, the CypherBFT’s runtime lasts only 20-30 milliseconds (ms). Two-to-three confirmations are all that is required to permanently accept a proposed block into the blockchain, and it only takes 90ms for these confirmations to transpire, making the process significantly faster than the two-minutes required by EOS. Cypherium’s CypherBFT, which also utilizes HotStuff, does not need to choose between responsiveness and linearity.
Cypherium’s dual blockchain structure includes the speeds of a dag, but its recall for users can happen much simpler and faster, which adds to the availability of information and makes the information more decentralized.
In accordance with some disclosed embodiments, the validator nodes in the Committee may receive transaction requests from other network nodes, for example, in a P2P network. The Committee may include at least one validator node that serves as a “Leader” validator node; the other validator nodes may be referred to as “Associate” validator nodes. The Leader node may be changed periodically, on demand, or sporadically by the members of the Committee. When any validator node receives a new transaction request from a non-validator node in the network, the transaction request may be forwarded to all of the validator nodes in the Committee. Further to the disclosed embodiments, the Leader node coordinates with the other Associate validator nodes to reach a consensus of a disposition (e.g., accept or reject) for a transaction block containing the transaction request and broadcasts the consensus to the entire P2P network. If the consensus is to accept or otherwise validate the transaction request, the requested transaction may be added in a new block of a blockchain that is known to at least some of the network nodes in the network.
In accordance with some embodiments, the Leader node may use improved protocols for reaching a consensus with the Associate validator nodes in the Committee when determining the disposition of a received request, such as a transaction request to add one or more transactions to an existing blockchain or a candidate request to request that a node join the Committee as a new validator node. For example, in some embodiments, the Leader node may use aggregate signatures in reaching a consensus for a new transaction request, allowing the consensus to be reached by validating digital signatures from fewer than all of the validator nodes in the Committee. In contrast with prior systems, the Leader node’s use of aggregate signatures may permit the Committee to reach a consensus of whether to accept or reject a preliminary transaction block faster and/or more efficiently, for example, in the event that one or more of the validator nodes in the Committee do not respond sufficiently quickly or at all. In some embodiments, as long as the number of responding validator nodes reaches a predetermined threshold, the Leader node can conclude that a consensus in the Committee has been reached. In some exemplary embodiments, in a network having a fault-tolerance of f nodes, and the Committee includes 3f +1 validator nodes, this predetermined threshold may be set equal to 2f + 1 validator nodes.
In accordance with some disclosed embodiments, the improved protocols used by the Leader node for reaching a consensus based on receipt of a new transaction request or candidate request may comprise a plurality of phases. In some embodiments, the Leader node employs a three-phase protocol, for example including a Prepare phase, a Pre-Commit phase, and a Commit phase, for determining whether to accept or reject a new transaction request or candidate request. In other exemplary embodiments, the Leader node may determine the disposition of the new request using a two-phase protocol, for example including a Prepare phase and a Commit phase.
Advantageously, the disclosed embodiments provide a distributed-system architecture and related protocols that allow a distributed system, such as a blockchain system, to scale up without incurring an unacceptable increase in decision-making complexity while also preserving the benefit of using a decentralized system. The disclosed embodiments reduce the distributed system’s reliance on the stability of any particular node(s), as the validator nodes in the Committee may be changed at a sufficient frequency to remove unreliable, unavailable, or otherwise untrusted nodes. Further, the system and method of the disclosed embodiments provides a scheme that helps ensure the Leader node, as well as the other Committee members, functions properly.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosed embodiments or the scope of the inventions as claimed. The concepts in this application may be employed in other embodiments without departing from the scope of the inventions.
they recently made a contract with a bank in england :
https://publish.twitter.com/?query=https%3A%2F%2Ftwitter.com%2FCryptoDiffer%2Fstatus%2F1296850506946686977&widget=Tweet
website : https://www.cypherium.io/
https://twitter.com/cypheriumchain
Mohammad Modares