Polkadot vs. Cosmos

07.08.20

Introduction to blockchain technologies.

The past decade has witnessed an explosive expansion of the area of implementation of decentralized networks and blockchain technologies. One of the most critical problems is the integration of independent blockchains of different architecture created for different purposes and operating by different rules. The cryptocurrency exchange sector has found a number of solutions to this problem, however, neither of them can be regarded as universal.

In this context, the industry pins its hopes on the creation of a “central” blockchain technologies that can support the integration of other blockchains. The most remarkable ones of this kind are Polkadot and Cosmos. They are similar in goals and architecture but are fundamentally different in other aspects.

Adoriasoft contribution to Polkadot development and promotion

Communication between different blockchains and connecting them to a global ecosystem is an actual problem. Several projects are trying to solve it in different ways; among them, Polkadot and Cosmos projects are the most ambitious and perspective.

The Adoriasoft team had a great chance to dive into both systems in cooperation with the best developers and researchers from the Polkadot team. We started developing a tool that combines Polkadot consensus mechanism and Cosmos application logic. We believe that in the future it will help to connect these ecosystems. We were invited to this project in an appreciation of the skills and creativity of our engineers. Adoriasoft provided a team of Rust and Go developers who helped to shape the Polkadot concept and turn it into a working mechanism.

With this project, we proved once again that Adoriasoft can not only develop distributed apps on top of the existing protocols but also get to the very core of a blockchain concept to modify, update, and improve it. Our expertise goes as deep as building the most essential components of decentralized networks, and we demonstrated it fully in the Polkadot project. Now, Adoriasoft obtained a second grant from Polkadot to continue research and development in this area.

development objective blockchain technologies

1. Development objective and history. Current state

Polkadot is a decentralized system represented by a set of network protocols and designed to join individual blockchain technologies in a single system, provide them with security, and support their interaction. Parallel operation of individual blockchains allows reaching high scalability.

Polkadot was created by Web3 Foundation and Paritytech. As for the beginning of 2020, the Polkadot mainnet has not been launched yet – its beta versions and the Kusama test network are available.[1]

Cosmos is a decentralized network of independent blockchain technologies that supports their interaction.

Cosmos was created by Interchain Foundation and Tendermint team. As of the start of 2020, Cosmos Hub has been running in the test mode.

Both systems are focused on achieving maximum architecture integration and flexibility as well as minimizing the limitations for the participating blockchains.

2. Structure and main features

Polkadot. [3]

Two most important components of Polkadot`s architecture are the Relay chain and parachains.

The Relay chain which is Polkadot’s main blockchain contains data of the blocks and communicated messages of all connected parachains. The Relay chain is responsible for the confirmed storage of each parachain’s state transitions.

A parachain (parallel chain) is a separate blockchain within the Polkadot system connected to the Relay chain [4]. A parachain can also act as a Relay chain for other blockchain technologies creating a hierarchy. Parachain security is mostly provided by the Relay chain, except in some cases (which are considered more experimental by the Polkadot team)[5]. A parachain can exchange messages with other parachains. To connect to the Relay chain, a parachain should have a slot allocated to it at a special auction [6]. All slot owners have a right to send their blocks to the Relay chain, so the information about these blocks will be checked, confirmed and included to the chain.

Whereas a parathread is a special type of parachain that needs no slots and interacts with the Relay chain on a per-block basis. A parachain slot is like a subscription – costs more, but allows you to use a service at any time. In case of a parathread an initial price is lower but each new block requires a new small fee. Actually the main difference between parachains and parathreads is an economy. [7].

Likewise a bridge is a special type of parachain acting as an adapter between an independent blockchain and the Relay chain. In exceptional cases, such as non-standard consensus algorithms, etc., independent blockchain technologies should implement their own security mechanisms.[8]

Cosmos. [9]

A Hub is a central blockchain storing token balances and other data of connected blockchain technologies and transmitting tokens and messages.

Whereas a Zone is an independent blockchain based on the BFT consensus interacting with the hub and other zones via IBC messages. Unlike Polkadot, in Cosmos each zone should provide its own security mechanisms. A zone may be a hub for other zones building a hierarchy.

Likewise a Peg-Zone is a special type of zone allowing to connect Probabilistic-Finality blockchain technologies.[10]

Both systems have a similar structure consisting of a central blockchain (Relay chain / Hub) and connected external blockchain technologies (Parachain / Zone). Obviously, the integration of applications that were not primarily designed for such systems might require an intermediate system (Bridge / Peg-Zone).

3. User roles

Polkadot. [11]

Validators are full Relay Chain nodes that create and finalize Relay Chain blocks [12]. Validators are elected for an era (24 hours) through the Nominated Proof-of-Stake system [13], it guarantees that each validator has significant deposit – a frozen sum of tokens. Validators perform their duties for points that they are awarded in proportion to their activity and get commission from transactions. If a validator violates the rules, their deposits are slashed, actually they lose money and reputation. Penalty size depends on the type of misbehavior. [14, 15,16] As an attack prevention measure, validators are pseudo-randomly redistributed between parachains on a regular basis.

Nominators stake DOT tokens (native Polkadot currency) with the validators getting interest from their profit. If a validator violates the rules, the nominators lose part of their staked tokens. [17]

Fishermen analyze the blocks transmitted within the network and added to the relay chain. They also monitor the voting for blocks to be added, identify misconduct and file complaints.[18] If a misconduct is confirmed (this process is automated for minor misconducts, such as equivocating, while more complex misconducts, for example, coordinated attacks, are confirmed by voting), fishermen receive a part of the slashed misbehaving nominator’s stake.[19] In order to verify a parachain’s state transitions published in the Relay chain blocks, a fisherman must be a full node of that parachain.

Collators are full nodes of the respective parachain that verify the correctness of the state transition proposed in a block, provide the proof and transmit the parachain blocks to the corresponding validators. [20] Collators are responsible for the proof correctness [21, 27] The collator election system and their motivation mechanisms are defined by the corresponding parachain.

Cosmos.

Validators are full nodes of the Hub voting for blocks to be added and changes to be made to the system. Validators are awarded for the approved blocks and get commission from transactions. Validators are elected according to the Delegated Proof-of-Stake principle. In the event of a misconduct, the validator’s stake is slashed. A validator’s award is proportional to their deposit. [22]

Delegators stake tokens with the validators, share rewards and risks, receive interest on their profit, and can lose their tokens in the event of the validator’s misconduct.[23]

Hackers are similar to Fishermen in Polkadot, they file complaints about validators misbehaviour and get reward if it is true.[24]

User roles are similar in both systems while the validator election specifics differ. Since the Relay chain provides the parachains’ security by including their block data in its own blocks, a new intermediate role becomes necessary – the collator role. In Cosmos zones, interaction with the hub is limited to message sending in or out which is done by the validators of the particular zones.

4. Security

Polkadot.

Polkadot uses the sharded model with each shard representing a separate parachain having its own state transition function – a set of rules defining the parachain’s state transition logic after each transaction. [5] A consensual state transition and its validation by the Relay chain’s validators become possible due to a unified approach to the formation and execution of runtime, in particular using WebAssembly tools. [25]

One of Polkadot’s central ideas is the shared security concept. According to it the Relay chain contains the global state of the entire system and approves the correctness of state transitions of all connected parachains. The parachain nodes can verify whether the next block (state transition) is approved via Relay chain light clients.

To ensure storage efficiency, the Relay chain does not store the full data of parachain blocks (parablocks) but only a number of hash values including the state root before and after the block implementation.[26] This solution has a potential vulnerability in the form of asynchronous states resulting from a parablock being approved in the Relay chain but not broadcast in the parachain and stored by its nodes. This can happen when a collator broadcasting the block is disconnected from the network either accidentally or intentionally. Polkadot uses a special Availability protocol: when a validator receives a blob (a parachain block with a proof) from a collator, it splits it into n = 3f + 1 fragments through redundant encoding (Reed-Solomon codes). The initial blob can be reconstructed with the f + 1 fragment while the fragments are distributed between all Relay chain validators and also given to collators for additional backup. The validators must store the fragments for a certain period of time during which the block validity can be checked again and the parachain state can be synchronized. During the Relay chain block creation and before its finalization, the availability of parablocks it contains is verified. If at least one parablock is not available, the Relay chain block cannot be finalized. [27, 21]

Cosmos.

Cosmos uses the bridge-hub model: all zones are independent and provide their own security. Hubs communicate messages between zones and log the transmitted tokens. [28]

The security models supported by both systems differ significantly. Polkadot allows parachains to reduce the validator maintenance costs and provides block finalization and security at the Relay chain level. At the same time, Cosmos zones are responsible for their security and must provide their block finalization by their own means.

5. Consensus

In both systems, validators elections are based on DPoS consensus variation: Nominated Proof-of-Stake and Bonded Proof-of-Stake. For block creation and finalization, they use PBFT consensus variations – BABE + GRANDPA hybrid consensus and Tendermint BFT.

Polkadot.

Nominated Proof-of-Stake is based on the following concepts: [13]

– A Nominator can stake on several Validators (up to 16) [31].

– The elected validators’ deposits must be as similar to each other as possible.

– If at least one of the nominator’s candidates is elected, its entire stake is credited to their deposit(s).

– All candidates backed by a single nominator are equal – the stake is made on all candidates simultaneously.

The second and third condition can never be fully achieved in practice, as the optimal distribution of stakes between candidates is an NP problem. Therefore, the candidates are elected using the Weighted Phragmén method – an iterative algorithm electing one candidate per iteration, with each elected candidate decreasing its voters’ weight in the subsequent iterations. [29, 30] In one election cycle, a full set of validators is elected, no new validators can be assigned before the next election cycle, however, a misbehaving validator can be deactivated. The staked DOTs are blocked and cannot be used during a certain period. In the event of a validator’s misconduct, its deposit can be slashed causing the nominators to lose a fraction of their stakes.

All validators have equal weights in new blocks accepting consensus. This fact can create a system vulnerability when the stakes are distributed unequally – an attacker needs only to control the validators with the lowest deposit which reduces the attack cost. At the same time, the NPoS system makes such scenarios significantly more difficult by balancing the validators’ deposits.

Cosmos.

The design of Bonded Proof-of-Stake is not so complex – the candidates with the highest deposits become validators. Misconducts may lead to deposits being slashed. Delegators make stakes for specific validations rather than for a group. A validator’s weight in the process of achieving consensus is proportional to its deposit amount.[22]

Polkadot.

Consensus is achieved using two algorithms [32] – BABE [33] producing blocks and GRANDPA [34] finalizing them.

BABE (Blind Assignment for Blockchain Extension) was developed on the basis of Ouroboros Praos to produce Relay chain blocks. Let’s look at the algorithm components.

The time in the system is divided into epochs with epochs (e₁,e₂,….) in their turn, divided into slots e_i=(sl¹₁,sl¹₂,…., slⁱ_t). In Polkadot, a slot is 6 seconds long. For each slot, one or several leaders – block authors that are secret until the block is posted – are selected. Each slot has a primary author [35] and a second one [36]. A primary leader is elected by a pseudo-random procedure, with cases of no or several primary leaders possible. There may be only one secondary leader with this role passing from one author to the next one using a round-robin algorithm. A block produced by a secondary leader can be added to the chain if the respective slot has no blocks produced by a primary leader. If there are several primary leaders, the block that was the earliest has priority.

The primary leader is elected using the VRF (verifiable random function) based on elliptic curves [37]. With the VRF, the validator uses its secret key to generate a pseudo-random value d and a proof ?, that, together with the public key, allows validating the authorship of d.

Each validator has two pairs of asymmetric keys – VRF (verifiable random function) keys { sk^v_j, pk^v_j }, and signature keys {sk^s_j, pk^s_j}. All public keys are stored in the blockchain.

In order to prevent preliminary brute-forcing of keys and seizing the leadership of certain slots, the system uses public rand r influencing the VRF value. The public rand is changed with each new epoch and depends on the outputs of VRF validators that produced blocks in the previous epoch.

VRF_sk^v_j^{( r}_m^{|| sl}_k⁾→(d,π), where

_sk^v_j – validator’s private key,

^r_m – public rand of the epoch,

^sl_k – slot number.

If d<τ , the validator is a primary slot leader. Since d is a cryptographic hash – a pseudo-random value, and each validator has only one pair of VRF keys, all validators have an equal chance to become a leader.

The selection of the threshold value τ allows reaching a compromise in the number of slots with no primary leader and slots with several primary leaders.[38, 39] Here, the mathematical basis is largely similar to that of Ouroboros Praos [58] which laid the foundation for BABE. In Ouroboros Praos, the probability of validator V_i becoming a primary leader is determined by the following formula:

p_i= 1 – ( 1 – c )^θi

c – constant, probability of the slot having a primary leader.

θ_i – ratio of validator V_i’s stake to the sum total of all validators’ stakes.

τ=2^l.p=2^l.(1-(1-c)^θi)

l – bit length of d.

As BABE supposes that all validators’ stakes are equal

θ₁= θ₂= … = θ_n= θ = ¹/_n

The formula becomes as follows:

τ = 2^l . p = 2^l . ( 1 – ( 1 – c ) ^1∕n)

In their research, the BABE authors used value c=0,42.

The system capacity can be increased through reducing the number of empty slots by applying the concept of secondary leader elected by the round-robin principle.[36] Also Polkadot authors propose a simple round-robin Proof-of-Authority consensus protocol – Aura. The leaders are elected one by one from an ordered list of validators V, it can be useful in private or test networks.

leader = V [ slk % |V|]

GRANDPA standing for GHOST-based Recursive ANcestor Deriving Prefix Agreement [34] is a BFT consensus protocol finalizing one of the existing block chains without producing new blocks. The authors based their research on the idea that block finalizing means simultaneous finalizing of all its previous blocks. Therefore, there is no need to vote for each block but only for chains that may consist of hundreds or thousands blocks.

Generally, GRANDPA is similar to the classic Practical BFT consensus and is focused on working in a partially synchronous network. It allows up to n/3 malicious participants. Many BFT consensuses, GRANDPA included, use two-step voting:

– Voting for accepting the proposal for consideration
– Voting for approving the proposal.

Consensus protocols similar to GRANDPA are designed for use in networks of a certain type one of the main features of which is the synchronicity of the distributed system: [42]

– Synchronous where the maximum message delivery and processing time is known exactly (available only for local networks with high hardware connections quality and known characteristics of all hardware)

– Asynchronous where the maximum message delivery and processing time is unknown (large networks including different types of hardware, for example, Internet)

– Partially synchronous where the maximum message delivery and processing time is not known exactly but it is practically possible to determine the time period during which the delivery probability is rather high.

The validator nodes are assumed to have reliable Internet connection and use modern hardware. Such networks can be considered as partially synchronous.

In each round, a leader also called a primary is elected either pseudo-randomly or by the round-robin principle [34, section 3]

GRANDPA round:

1) The round leader broadcasts to other nodes the block of the previous round that the leader considers to be the highest.

2) After a certain delay, each validator sends a pre-vote for the block of the current round that the validator considers to be the highest.

3) Based on the pre-vote, each validator determines the highest block continuing the current state of the chain. When ⅔ of the pre-vote is received, the validator sends a pre-commit containing that block.

4) Having received ⅔ of the pre-commit for one of the blocks continuing the current state of the chain, each validator updates the finalized chain adding the current block together with all its predecessors (ancestors) and broadcasts this message.

The protocol supports weighted voting. By default, Polkadot uses an equilibrium system due to the NPoS election system aimed at equalizing the stakes. Therefore, to compromise the protocol functioning, the attacker needs to control at least one-third of the validator nodes (rather than one-third of the stake as in many other DPoS BFT systems). GRANDPA allows reducing the network load and increasing the system performance by approving a large number of blocks simultaneously. However, this may increase the delay of a particular block approval.

Cosmos.

To approve blocks, Cosmos uses the Tendermint BFT consensus algorithm. The consensus is reached for a specific block. In each round, there is a leader proposing a block. Leaders are elected by the weighted round-robin algorithm – the larger the validator’s stake, the more often he becomes a leader. When the validators set and their stakes are the changeless, the algorithm is deterministic, and the order of leader election results can be calculated.[60, 43, 59]

Generally, Tendermint is similar to the classic Practical BFT consensus algorithm and is designed for implementation in a partially synchronized network. [44] This algorithm allows up to n/3 malicious nodes.

Tendermint round:

– The round leader proposes a block.
– Having received a block from the leader, each validator verifies it and if the block is correct, the validator must vote for it by broadcasting a PreVote to other validators.
– Each validator waits for a PreVote for the block. If a block has at least 2/3 of the votes, it is called Polka (no relation to Polkadot; the Tendermint authors consider that the validator operation reminds a Polk dance).
– Each validator must vote for the block resulting in a Polka by broadcasting a PreCommit to other validators.
– Each validator waits for a PreCommit for a block. If a block has at least ⅔ of the votes, it is called a Commit.
– The validators approve the block that has a Commit.

The weights of the validators’ votes are proportional to their deposits. Therefore, to compromise the protocol functioning, an attacker needs to control the nodes whose sum of deposits is at least one-third of the total sum of the deposits. In this respect, it is different from polkadot where the validators’ votes are equal because the deposit sums are also considered equal.

message communication blockchain technologies

6. Message communication

Both systems plan to allow the connected blockchain technologies to interact via message communication. However, such interaction has a serious problem which is the possibility of forking and rolling back to a previous state of the blockchain technologies.

Polkadot.

Polkadot uses XCMP, Cross-Chain Message Passing. [45, 46]. This protocol is designed to communicate arbitrary messages between parachains. Messages are sent together with the next parachain block while the Relay chain blocks include only the proof of post. All messages must be processed in a proper order, a set of Merkle proves and hash chains are used for it. Messages are sent via one-way channels established between the parachains. Two message transfer methods are available:

– Via the devices that are full nodes of both parachains
– Via Relay chain validators.

Shared security that provides equal protection to all parachains and prevents forks, allows interaction between blockchain technologies that do not trust each other. For standardization of the message format and their processing by the recipient, the SPREE protocol is now being developed.[47]

Cosmos.

Cosmos uses IBC – Inter-blockchain Communication Protocol. [48] Initially, the protocol supports token communication while the ultimate goal is to support communication of arbitrary messages.

Cosmos Hub does not provide additional security to zones during the communication, it is just like a transport layer. Since in Cosmos each blockchain technologies provides its own security, interacting zones need to trust each other and accept the risks of each other’s failure.

governance and modification blockchain technologies

7. Governance and modification

Both systems have self-modification mechanisms. Any modifications may be made only upon a special referendum.

Polkadot.

Polkadot operating on a Wasm VM offers considerable flexibility in system modification up to modification of the protocol source code.[49]

The test variant of Polkadot – Kusama has three governance components [64], the same system is used in Polkadot mainnet[69].

Referendum is a global voting that can approve system modification proposals. Referendums are held once every 30 days. All DOT tokens holders can participate in a referendum.

A number of trusted participants form a council that can bring important proposals to referendum. In addition, the council has the right to veto dangerous or malicious proposals. [52] Each council member is elected for a year using deposit-based voting but can be divested of its powers by a referendum decision. At the system start there are 6 council member`s accounts with one new member added every two weeks for 9 subsequent months The total number of accounts is 24. [55] (More recent information: there are 13 members at the beginning and gradually expand to 23 [69]).

Each system user can propose their candidate list for the council. The candidate with the most votes gets elected. The votes for N leaders are retained till the next election cycle – in case of a tie vote, the candidate who got more votes at the previous elections gets elected.[55]

The council member with the biggest number of votes is a prime councillor and if it approves a proposal, all abstainers also approve it.

The Technical Committee is elected by the Council from among the developer teams who showed outstanding results in the development of the Polkadot system. The purpose of the Technical Committee is to trigger emergency referendums when it’s too dangerous to wait till a regular referendum, for example, when a critical bug is detected. [56].

A referendum consists of three steps:

1) Proposing,

2) Voting based on stakes,

3) Tallying.

Depending on the proposal initiator, there may be the following types of proposals:

1) A public proposal can be made by any user. A public proposal requires a deposit. Other participants can support the proposal by increasing the deposit.

2) Council proposal:

a. A unanimous council proposal,

b. A proposal by the majority of the council.

3) Proposal based on the enactment of the previous referendum decision

4) The emergency proposal by the Technical Committee approved by the Council.

The proposal type influences the vote ratio required for its approval. A unanimous Council proposal requires a minimum of votes while a public proposal requires a maximum.

A vote is represented by coins frozen temporarily (at least until the referendum finishes). Voting without coin freezing is also possible, however, in this case the vote weight is minimal.

votes = tokens * period

period – coin freeze time, 1 period = 2 weeks, coins can be frozen for 1-6 periods.

There are separate queues for public proposals (ordered according to the deposit amount) and Council proposals. For each referendum, a proposal from one of the queues is brought for consideration. Each time a different queue is used. If there are no proposals in the queue to be used for the referendum, a proposal from the other queue is used.

Any members can make stakes while validators cannot use the nominators’ deposits for voting. Upon the voting completion, only the winners’ tokens are blocked.

Cosmos.

Cosmos supports a less flexible modification system – the protocol parameters can be changed easily, however, changes to the source code may require a hard fork. [57]

The Cosmos Hub governance system described in the White Paper is somewhat different from the one that is actually implemented. The description below refers to the actually implemented Cosmos Hub version unless otherwise indicated.

In Cosmos, proposal approval is a three-step procedure:

1. The Deposit Period.

A proposal can be made by any member making a deposit. Other members can support the proposal by increasing the deposit. If the proposal reaches the specified deposit amount within the specified period (two weeks at the start of Cosmos Hub), the next step is launched.

2. The Voting Period.

During the specified period (two weeks at the start of Cosmos Hub), Atom holders can vote for the proposal with their vote weight proportional to the staked tokens. There are 4 vote types: Yes, No, NoWithVeto, Abstain. [61, 62] All validators must vote for each proposal, their votes are proportional to the deposits amount. A validator that ignores voting repeatedly may be penalized (not implemented at time of writing).

According to the White Paper [57], initially 5 vote types were planned: Yea, YeaWithForce, Nay, NayWithForce, Abstain. Three vote types were renamed, and YeaWithForce was not implemented as YesWithVeto.

3. Tallying Results.

For the proposal to be approved, the following conditions must be met:

– Quorum – there must be at least the specified number of tokens participating in the voting.
– Threshold – the number of Yes votes must be more than 50% of the total vote count except Abstain votes.
– Veto – the number of NoWithVeto votes must be less than ⅓ of the total vote count except Abstain votes.

If the proposal was vetoed, the deposit made towards its voting is burned.[63, 66] In the initial Cosmos Hub version the deposit was burned if any of the above three conditions was not satisfied. According to the White Paper [57], voters could vote for deposit burn, and when this decision received more than 50% of the votes, the deposit was burned. This mechanism was indirectly implemented through the veto system. Besides, the initial description [57] included the procedure of proposal rejection when it received the majority of votes (for approval or rejection) and was vetoed by the minority (initially there was the YeaWithForce vote type allowing to veto a proposal rejection). In this case, all validators were penalized. Such a solution could motivate the members to seek compromise, however, the current documentation contains no reference to this mechanism. [65]

Therefore, the actual protocol state needs to be checked in the specification of the corresponding Cosmos version.

8. Implementation

Polkadot.

Polkadot is implemented on the basis of the Substrate framework written in Rust. The framework includes around 35 modules (pallets) that can be used in blockchain development, the common name of all these modules is FRAME. [53]. Developers are free to decide whether to use certain pallets. For parachain connection to the Relay chain, the Cumulus extension is used.

A Substrate node is a multi-layer program, it includes a core, FRAMEs and an application. One of the main purposes of the project is to give developers maximum flexibility in blockchain logic and allow them to use well-designed modules as “black boxes” without the need to solve trivial problems like gossip protocols and block authorship.Substrate allows developers to start new blockchain technologies very quickly.

The Polkadot node functioning consists of two components:

– Runtime determining the logic of chain state transition;
– Runtime environment is responsible for network interaction and data storage in the device.

An important feature of Substrate is that its runtime is compiled into a native executable and a WebAssembly (Wasm) binary. Wasm component is a part of blockchain technologies, it allows to update nodes` source code rather easily.

Cosmos.

Cosmos is implemented on the basis of the Cosmos SDK framework written in Go. The framework includes around 10 modules used in blockchain operation [54].

The node architecture has three distinct levels:

– Application defining the state transition logic;
– Consensus – Tendermint BFT;
– Network interaction.

The lower two levels form the so-called Tendermint core communicating with the application level through the ABCI interface.

Both systems have similar architecture with the logic of network connection and consensus separated from the application per se that is responsible for the system state transitions. The selected development technologies are also based on similar architecture – the most frequently used in blockchain application tasks are shaped as independent modules that can be integrated in any project when needed. In general Substrate proposes a higher level of abstraction and more prospective capabilities for code update.

Conclusion.

Polkadot and Cosmos systems are designed to integrate independent blockchain technologies in a single infrastructure supporting communication between them. Both architectures propose using special blockchain technologies as central interaction nodes. The main difference is that Polkadot main chain – the Relay chain provides security for all other chains in the system. Polkadot has a more complex ecosystem and a lot of challenges must be solved, however, its options are wider.

search

Polkadot vs. Cosmos

Introduction to blockchain technologies.

Adoriasoft contribution to Polkadot development and promotion

1. Development objective and history. Current state