Type ;Hybrid;Public;Private;Global non-public, private
Scalability;The architecture allows infinite horizontal scaling, without points of any restrictions.;"Now absent. In 2.0, scalability is planned to be realized by creating new subordinate chains, where the main chain will be the guarantor of their reliability. Yet scaling via subordinate chains has several drawbacks: communication between subordinate chains is limited by the performance capabilities of the main chain the guarantee of reliability has the currency equivalent of the main chain, therefore actions within the subordinate chains should not go beyond the amount of the guarantor. Otherwise, it will be economically beneficial for participants to nivelate the agreement rules and pay the guarantee addressing of subordinate chains is independent of each other";"There is no automatic scalability mechanism employed by the system. Manual scaling by creating different chains is possible. For example, there is a separate chain for different organizations. The possibility of creating ""channels"" is provided when several chains’ data can be independently processed on one physical server. However, system performance degrades as each individual channel is added. Also, in the case of creating a system of independent chains, the problem of addressing arises, which must also be invented for a specific set of chains.";"There is Corda Network - the root of trust of the system, which allows data exchange between different “business networks” (the term Codes is similar to the meaning of the term “chain”). as in Ethereum 2.0 there is a main chain, which limits the interaction of secondary chains with the performance of the main one new chains can use different notary pools for validation, however, adding pools of new nodes to the system is strictly regulated and centralized, which does not facilitate scaling of the system in response to growing load to create new business networks, the developing organization also needs to go through a centralized selection and validation, so a separate set of organizations cannot create their own chain at their discretion"
Communication between chains;All public chains work directly with each other. Thanks to anchoring, private chains can easily communicate with each other, as well as work with public chains as a standard user.;Currently not available. In 2.0, it is assumed that data from one subordinate chain can be transferred to another, but such data can be trusted only if the “cost” of the data is less than the guarantees of the data source chain. It is possible to mark the validity of the data across the main chain, but this action will greatly increase the cost of data transmission.;Currently missing. To create such a connection in each specific case, one needs to create one’s own solutions.;Data between chains can be transferred through the main chain. Notary nodes are responsible for the validity of this data. There is no possibility of self-checking data validity
Consensus for the corporation;A synchronous BFT consensus is used, which also works very well for corporate purposes.;Proof-of-Work. Very costly to maintain a full node, which is needed to trust the data that is received from the platform.;"The system currently only offers Raft consensus. It is a consensus that helps to deal with hardware failures in distributed systems. This consensus does not belong to the BFT class, which means that any of the participants in the consensus can stop the entire system. Of course, in the case of corporations, when employees can turn off any of their servers, this is not as critical as, for example, for payment systems. However, due to such a problem in the system, the organization needs to have a wide variety of qualified specialists working constantly up to round-the-clock physical duty for employees. Yet even this will not remove the stop factor, but only reduce its time.";One can select the required consensus by choosing notary nodes for the business network. Raft and BFT are standard, but in principle, notary nodes can run on any of their own.
Security of data transmission between chains;Private chains of various organizations can transfer data directly to each other. Moreover, one can transfer only the necessary part of the data stored in a private chain, and at the same time, any user can independently check the validity of this data due to the employed Merkle Tree Proof algorithm.;There are currently no systems for the exchange of protected data between chains developed or in progress.;Absent. When transferring data, there is no standard way to check the validity of data employed within the system itself. It is possible to use centralized key systems within one corporation. However, in the case of connections between two or more organizations, it becomes more and more difficult to sustain data security within the architecture of the specific solution.;"The main chain is responsible for the security between the business networks of cash, digital assets and initiators. The validity of the transfer of the remaining data is monitored by the notary nodes of the source business network.there are no other ways to check the validity in the system, only trust in notary nodes (which are managed by members of the Corda Network Foundation, thus making the system fully centralized). the architecture of Corda is positioned so that many business networks can be located on the same pool of notary nodes, and access to these networks will only be given in accordance with the permissions of these networks. However, the owners of these nodes have full access to all the information of all business networks located on them, and can abuse this. accordingly, the only way to control the activities of notary nodes is the threat of punishment upon detection of their illegal actions in the business network by the network operators. The penalty is disconnection of this pool from the Corda system with possible legal prosecution. Therefore, enterprise companies connecting to the system need to assess the risks that the “value” of actions in the business network should not be higher than the reputational risks of notary nodes."
Stress test resistance;The architecture of the system is designed so that the network can be automatically reconfigured in order to withstand loads exceeding 50% of the current standard capacity. If such load becomes constant then the horizontal expansion of the network occurs, which leads to an increase in standard performance and consequently increases the system resistance for the next sudden loads.;The system currently cannot handle more than 10 transactions per second. Because of this, the system has repeatedly found itself in a situation where the execution of routine transactions was suspended in favor of more profitable ones.;The performance of a separate Hyperledger Fabric chain is limited by the performance of the servers included in it (the more expensive the equipment, the higher the speed) and the number of servers (the more servers, the lower the speed).;"Changes in the business network are recorded on the nodes of the notary pool. Therefore, performance and, accordingly, resistance to highloads depends on the parameters of the servers included in this pool, and the loads from other business networks served by this pool. Minuses: in general case, there is no way to guarantee the performance of a particular business network. Perhaps this can be done in the form of direct agreements with the owners of the pool of notary nodes. any business network is still limited by the performance of servers included in the notary pool and their number, as in the case of Hyperledger Fabric."
Utilization costs and protection from Sibyl attacks;Every action in the system, like in Ethereum, is paid, which is the main defense against the Sibyl attack. However, in private chains, this protection is not always convenient, so other options can be used - bandwidth limiting, transaction dating, or a combination of these depending on the user's needs.;"Protection against Sibyl attacks is based on the fact that all actions in the system are paid in the local currency of ethereum. To work, any account must buy a sufficient amount of this currency and independently monitor the timely replenishment. Yet: there are difficulties with legal framework for ETH currency purchases for organizations’ accounts as long as these are viewed as cryptocurrency or a digital asset It requires constant tracking and replenishment of accounts the cost of the same actions at different times may strongly vary depending on the system load and the ETH market conditions";Hyperledger Fabric does not have any value “expression” for assignments from users as long as the user pays for CPU per node per hour. As a result, the system has no defense against Sibyl attacks. Any user can complicate the work of the entire system by sending a lot of transactions on his own behalf. Unfortunately, unlike with the Raft consensus problems, this problem is much more difficult to solve.;As in Hyperledger Fabric or the systems alike, there is no expression of value for execution of user assignments in Corda as long as organizations pay for the CPU per node per hour and related infrastructure costs. However, the architecture of the system itself contains the possibility of punishing those participants, who attempted to harm the functioning of the network. Due to the centralized issuance of all types of certificates for the operation of the system, the path of punishment is a fairly effective way of solving protection against Sibyl attacks. Yet, this method solves the problem only after its occurrence, but does not prevent it from happening.
Cost for validation of the data received from the system;No additional cost is required to verify data from the system. Any user and automatic system can check the validity of the received data right on the client device.;In order to get guaranteed correct, valid data, you need to have a separate server with a large SSD disk.;It is believed that servers employed within the corporation are not subject to hacking, so clients connecting to them trust the data received from them. If it is necessary to create another point of connection for users, then the costs for it will be the cost of the server and the cost of maintaining it in the chosen location.;To receive data, one needs to own servers, which will receive the latest updates from the notary nodes. However, any kind of user verification is not supported, as the architecture implies complete trust in the notary nodes.