# US 12,003,618 B2 · Methods and systems for a heterogeneous multi-chain framework

> Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt

- Number: US 12,003,618 B2
- Document ID: US12003618B2
- Status: Granted
- Kind: B2
- Application number: 17/501,646
- Filed: 2021-10-14
- Published: 2022-06-09
- Granted: 2024-06-04
- Earliest claimed: 2017-08-03
- Assignees: Parity Technologies Ltd.
- Applicants: Parity Technologies Ltd.
- Inventors: Gavin Wood; Robert Habermeier
- Web page: https://patentgrep.com/patent/US12003618B2

## CPC

- H04L 9/0637: {Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]}
- G06F 16/2308: {Concurrency control (transaction processing G06F9/466)}
- G06F 16/2379: {Updates performed during online database operations; commit processing}
- G06F 16/27: Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
- G06F 21/60: Protecting data
- G06F 21/602: {Providing cryptographic facilities or services}
- G06F 21/64: Protecting data integrity, e.g. using checksums, certificates or signatures
- H04L 9/3218: {using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs}
- H04L 9/3239: {involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD}
- H04L 9/50: {using hash chains, e.g. blockchains or hash trees}
- H04L: TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION (arrangements common to telegraphic and telephonic communication H04M)
- G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N)

## Abstract

Present-day blockchain architectures suffer from several problems, including poor extensibility and scalability. This may stem from tying two parts of the consensus architecture, namely canonicality and validity, too closely together. The Polkadot architecture, which is a heterogeneous multi-chain, provides better extensibility and scalability by setting canonicality and validity apart. Compartmentalizing canonicality and validity and keeping overall functionality to a minimum of security and transport introduces practical core extensibility in situ. Scalability is addressed through a divide-and-conquer approach to canonicality and validity, scaling out of its bonded core through the incentivization of untrusted public nodes. The heterogeneity of this architecture enables many highly divergent types of consensus systems interoperating in a trustless, fully decentralized “federation,” allowing open and closed networks to have trust-free access to each other. This architecture is compatible with pre-existing networks, including Ethereum, and a useful component in a practical system for global-commerce scalability and privacy.

## Claims

### Claim 1

A method of evaluating and establishing a record of validity of a candidate block representing a state transition of a parallelized blockchain (parachain), the method comprising:
providing, by a relay blockchain (relay chain), security advancement and communication channels for a plurality of heterogeneous parachains;
receiving, at a validator node in the relay chain, a header associated with the candidate block and a state-transition proof associated with the candidate block from a collator node in the parachain, the parachain being one of the plurality of heterogeneous parachains;
validating, at the validator node, (i) the state transition represented by the candidate block and (ii) extrinsic data representing external transactions referenced by the candidate block based on the header and the state-transition proof;
rebroadcasting the candidate block to at least one other validator node in the relay chain in response to validation of the state transition and the extrinsic data;
broadcasting a statement about validity and availability of the candidate block to the at least one other validator node in the relay chain;
forming a consensus among the validator node and the at least one other validator node that the state transition represented by the candidate block is valid; and
in response to the consensus, sealing the candidate block and the header within a block of the relay chain to prevent reorganization of the parachain,
wherein the sealing the candidate block within the block of the relay chain comprises collecting the statement about validity and availability of the candidate block signed by the validator node and the at least one other validator node and procures security for various ones of the plurality of heterogeneous parachains ensured through a dispute resolution process.

### Claim 2 (depends on 1)

The method of claim 1, wherein the candidate block references a header associated with a previously included candidate block of the parachain, external input or ingress data, and egress queue data.

### Claim 3 (depends on 1)

The method of claim 1, wherein validating the state transition comprises verifying the state-transition proof according to validation logic stored on the relay chain.

### Claim 4 (depends on 1)

The method of claim 1, further comprising:
monitoring the statement about the validity and the availability of the candidate block to prevent illegal actions by the validator node.

### Claim 5 (depends on 4)

The method of claim 4, further comprising:
conducting the dispute resolution process in response to a challenge to the validity of the candidate block.

### Claim 6 (depends on 1)

The method of claim 1, further comprising:
trustlessly synchronizing the parachain with the relay chain in isolation from other parachains in the plurality of heterogeneous parachains.

### Claim 7 (depends on 1)

The method of claim 1, wherein validating the state transition and the extrinsic data comprises determining that the candidate block constitutes a valid child of an intended parent block on the parachain.

### Claim 8 (depends on 1)

The method of claim 1, further comprising:
persisting the statement about validity and availability of the candidate block.

### Claim 9 (depends on 1)

The method of claim 1, wherein the validator node is one of a plurality of validator nodes, and further comprising:
shuffling the plurality of validator nodes over the plurality of heterogeneous parachains.

### Claim 10 (depends on 1)

The method of claim 1, wherein the statement about the validity and the availability of the candidate block signed by the validator node and the at least one other validator node represents information enabling the validator node and the at least one other validator node to validate subsequent candidate blocks.

### Claim 11

A decentralized computer network to enable shared security for a plurality of heterogeneous parallelized blockchains (parachains), the decentralized computer network comprising:
computers connected in a peer-to-peer network and comprising respective processors and respective non-volatile memories storing instructions which, when executed by the respective processors, cause the computers to provide:
a collator node, assigned to a first parachain in the plurality of heterogeneous parachains, to provide a header associated with a candidate block and a state-transition proof associated with the candidate block representing a state transition of the first parachain;
a first validator node running a first client implementation for a relay blockchain (relay chain), the relay chain providing security advancement and communication channels for the plurality of heterogeneous parachains; and
a second validator node, running a second client implementation for the relay chain, to receive the header and the state-transition proof from the collator node, to validate (i) the state transition represented by the candidate block and (ii) extrinsic data representing external transactions referenced by the candidate block based on the header and the state-transition proof, and to transmit the candidate block and a statement about validity and availability of the candidate block to the first validator node,
wherein the first validator node and the second validator node are configured to form a consensus that the state transition represented by the candidate block is valid and, in response to the consensus, to seal the candidate block and the header within a block of the relay chain to prevent reorganization of the first parachain to procure security for various ones of the plurality of heterogeneous parachains ensured through a dispute resolution process,
wherein the first validator node and the second validator node are configured to seal the candidate block within the block of the relay chain by collecting the statement about validity and availability of the candidate block signed by the first validator node and the second validator node.

### Claim 12 (depends on 11)

The decentralized computer network of claim 11, wherein the candidate block references a header associated with a previously included candidate block of the first parachain, external input or ingress data, and egress queue data.

### Claim 13 (depends on 11)

The decentralized computer network of claim 11, wherein the second validator node is configured to validate the state transition represented by the candidate block by verifying the state-transition proof according to validation logic stored on the relay chain.

### Claim 14 (depends on 11)

The decentralized computer network of claim 11, further comprising:
at least one node to monitor the statement about the validity and the availability of the candidate block.

### Claim 15 (depends on 14)

The decentralized computer network of claim 14, wherein the at least one node is further configured to conduct the dispute resolution process in response to a challenge to the validity of the candidate block.

### Claim 16 (depends on 11)

The decentralized computer network of claim 11, wherein the first parachain can be trustlessly synchronized with the relay chain in isolation from other parachains in the plurality of heterogeneous parachains.

### Claim 17 (depends on 11)

The decentralized computer network of claim 11, wherein the second validator node is configured to determine that the candidate block constitutes a valid child of an intended parent block on the first parachain.

### Claim 18 (depends on 11)

The decentralized computer network of claim 11, wherein the first validator node and the second validator node are two of a plurality of validator nodes and the plurality of validator nodes is configured to be shuffled over the plurality of heterogeneous parachains.