FR3100350A1 - migration of a data blockchain - Google Patents

Abstract

A process for migrating a chain of blocks to be replaced, referred to as the first chain of blocks, to a chain of replacement blocks, referred to as the second chain of blocks. The migration method comprises: an initialization of the second blockchain, the initialization comprising a generation, in a main blockchain configured to supervise the access to the first and second blockchains, of a supervision area of the second blockchain configured to store user rights on the second blockchain; a registration of one or more users with the second blockchain, the registration of a user comprising a registration in a user directory in the main blockchain of a secondary address allocated to this user for connection to the second chain of blocks; generating in the second blockchain a set of data blocks corresponding to an image of the first blockchain; recording new transactions both in the first blockchain and in the second blockchain during a so-called mirror period; switching all or part of the users from the first blockchain to the second blockchain so as to prohibit the recording of transactions on behalf of these users in the first blockchain and allow the recording of transactions on behalf of these users in the second blockchain. Figure for the abstract: Fig. 4B

Description

data blockchain migration

FIELD OF THE INVENTION

The invention relates to the field of blockchains and more particularly to a blockchain migration technique.

STATE OF THE ART

Data recording technology using blockchains (a technique better known as "blockchain") is a technology that supports the confidence that can be had in the data recorded on the history of data. A priori, we cannot delete any data stored in a chain of blocks. As a result, a blockchain only increases in storage size. However, systems generally have a limited storage capacity which therefore cannot cope with the potentially infinite growth of a blockchain.

A blockchain indexes data deemed important. Every block, every transaction, every address, for example, is an indexed key for fast data access. On the other hand, the more keys an index contains, the more its performance is reduced. As a blockchain only increases in storage size, the more it is used, the more that blockchain stores stale data, the more its performance decreases.

There thus appears a need to remedy all or part of the problems, drawbacks or shortcomings of the state of the art and/or to make improvements thereto.

SUMMARY

According to a first aspect, the present description concerns a method for migrating a chain of blocks to be replaced, called the first chain of blocks, to a chain of replacement blocks, called the second chain of blocks, the method being implemented by a or more computers. The migration method includes: an initialization of the second blockchain, the initialization comprising generating, in a main blockchain configured to supervise access to the first and second blockchains, a supervision area of the second blockchain configured to store user rights to the second blockchain; a registration of one or more users with the second blockchain, the registration of a user comprising a record in a directory of users in the main blockchain of a secondary address allocated to this user for the connection to the second blockchain; generating in the second blockchain a set of data blocks corresponding to an image of the first blockchain, the image corresponding to a determined time in the history of the first blockchain; a record of new transactions for which a record request has arrived at the first blockchain in both the first blockchain and the second blockchain during a so-called mirror period; a switchover of all or part of the users of the first chain of blocks to the second chain of blocks so as to prohibit the recording of transactions in the name of these users in the first chain of blocks and to authorize the recording of transactions in the name of these users in the second blockchain.

In one or more embodiments, the method according to the first aspect comprises a definitive switch to the second chain of blocks by modifying the rights of the users on the first chain of blocks, so that no more transactions can be recorded in the first blockchain and any new transaction is recorded only in the second blockchain.

In one or more embodiments of the method according to the first aspect, the first chain of blocks is implemented in a communication system comprising a plurality of nodes and an instance of the first chain at each node, the method comprising, for at least one node of the communication system, following the definitive failover, a deletion of the instance of the first chain of blocks located at the level of the node considered.

In one or more embodiments, the method according to the first aspect comprises an allocation to each user of the second chain of blocks of a multisigned address for the signature of transactions to be recorded in the second chain of blocks in the name of this user, the multisigned address being generated from the secondary address allocated to this user for the connection to the second chain of blocks and an administrator address of the second chain of blocks.

In one or more embodiments of the method according to the first aspect, the secondary address allocated to a user for the connection to the second chain of blocks is stored in the user directory in association with the multisigned address.

In one or more embodiments of the method according to the first aspect, the multisigned address is used to register new transactions in the second blockchain during the mirror period.

In one or more embodiments of the method according to the first aspect, the rights of a user on the second chain of blocks are recorded in the supervision zone in association with the multisigned address allocated to this user.

In one or more embodiments of the method according to the first aspect, the generation of the image of the first chain of blocks comprises a recording in the second chain of blocks of a set of data blocks representative of units of assets held by one or more users of the first blockchain at the determined time.

In one or more embodiments, the method according to the first aspect comprises recording in the main blockchain a marker for each user indicating whether or not this user has switched to the second blockchain.

The various embodiments mentioned above can be combined with each other for the implementation of the method according to the first aspect.

According to a second aspect, the present description relates to a computer device or computer system comprising means for implementing the method according to the first aspect. These means may comprise one or more processors and one or more memories comprising computer program code, the memory or memories and the computer program code being configured to, together with the processor or processors, cause execution by the device of the steps of the method according to the first aspect. For example, the at least one memory comprises a computer program comprising instructions configured to cause the device to perform the steps of the method according to the first aspect.

In one or more embodiments, the different steps of the method according to the first aspect are implemented by one or more computer programs.

According to a third aspect, the present description thus relates to a data storage medium readable by a processor on which is recorded a computer program comprising instructions for the execution of the steps of a method according to the first aspect are implemented by one or more computer programs.

According to a fourth aspect, the present description thus relates to a computer program product comprising instructions for the execution of the steps of a method according to the first aspect when the computer program is executed by a data processor.

BRIEF DESCRIPTION OF FIGURES

Other aims, characteristics and advantages of the invention will appear through the description which will follow, given solely by way of non-limiting example, and made with reference to the appended drawings in which:
schematically depicts a communication system comprising blockchains;
schematically illustrates aspects of a node of a communication system according to FIG. 1A;
illustrates aspects of generating a user address;
illustrates aspects of generating a multisigned address;
schematically represents the relationships between a primary blockchain and secondary blockchains;
schematically represents the relationships between a main block chain and secondary block chains for managing a user's rights and addresses;
schematically illustrates aspects of a method of connecting a user to a secondary blockchain;
shows a flowchart of a method of connecting a user to a secondary blockchain according to one or more embodiments according to one or more embodiments;
schematically illustrates aspects of a method of migrating from a secondary blockchain to be replaced to a secondary blockchain of replacement;
depicts a flowchart of a method of migrating from a secondary blockchain to be replaced to a secondary secondary blockchain according to one or more embodiments.

DETAILED DESCRIPTION

As is known, blockchains can be used to record any type of transactions. In the background, a blockchain is generally defined as a computerized record of transactions. The blockchain (this computerized ledger) "grows" as blocks of data are recorded on it, these blocks of data corresponding to new transactions or sets of new transactions that are added to the chain of blocks. New blocks of data corresponding to new transactions are recorded in the blockchain after a validation process that is specific to each blockchain.

The term "transaction" can cover any type of operation between one or more actors. It may relate to any type of product or material, device component, packaging and/or physical or electronic document or file, including virtual assets such as data, electronic files, intangible assets or even crypto- cash. The so-called "block chain" technology allows the creation of a computerized register of operations, non-repudiable, resistant to falsification.

Fig. 1A schematically represents a communication system 1000 for the implementation of blockchains, in the case of a decentralized architecture. This communication system 1000 comprises several nodes 100, 101, 102 communicating with each other through a communication network 110. These nodes are generally organized into a network of peers.

Each node 100, 101, 102 of the communication system 1000 can correspond to one or more physically distinct computing devices, implementing software corresponding to one or more software applications. This software implements, at the level of the node considered, the functionalities of a chain of blocks and accesses one or more data sets for the storage of the blocks of data of the chain of block considered.

For each node 100, 101, 102 of the communication system 1000, the data blocks can be stored in a distributed manner (in this case, we speak of a distributed ledger, or "distributed ledger" according to the Anglo-Saxon terminology), for example on one or more sub-nodes of a local network at the level of the node considered.

Simplified and by way of example, in the case of Fig. 1, the node 100 comprises a computing device 150, implementing the functionalities of two chains of blocks 130, 140 and accessing two sets of data 130, 140, which respectively correspond to these two chains of blocks 130, 140. Similarly , the node 101 comprises a computing device 151, implementing the functionalities of two chains of blocks 131, 141 and accessing two sets of data 131, 141, which respectively correspond to these two chains of blocks 131, 141. Similarly, the node 102 comprises a computing device 152, implementing the functionalities of two chains of blocks 132, 142 and accessing two sets of data 132, 142, which correspond respectively to these two chains of blocks 132, 142.

Each computing device 150, 151, 152 may be implemented by one or more physically separate machines. The computer device 150 can globally present the architecture of a computer, including components of such an architecture: data memory(s), processor(s), communication bus, hardware interface(s) for connection of this device to a network or other equipment, user interface(s), etc.

Each computing device 150, 151, 152 is configured to communicate via the communication network 110 with the other nodes 100, 101, 102 of the communication system and implements all or part of the functions of one or more chains of associated blocks. 130, 131, 132 and/or 140, 141, 142.

In the case of a permissioned block chain (with rights management), each computing device 150, 151, 152 implements user registration functions, allocation of rights on the block chain, allocation of user addresses, access control to the blockchain, signing and recording of transactions, reading and writing of data sets or data blocks, etc., according to what is described in this document for the relevant blockchain.

A node 100, 101, 102 can be a full node or a light node for a given blockchain. If the node 100, 101, 102 is a complete node, the node stores locally (in one of the local data sets) all the data blocks of the chain of blocks: the data blocks are in this case duplicated as many times as there are knots.

In the example of Fig. 1, assuming that block chain 130 (140, respectively) is initially created by an administrator Z0 using computing device 150, then each of block chains 131 and 132 (141 and 142, respectively) are an instance of this same chain of blocks 130 (respectively 140). If node 100, 101, 102 is a lightweight node, the node locally stores only that node's user Z0, Z1, or Z2 data blocks. The invention described in this document is applicable regardless of the type of node.

If, for example, a user Z1 of node 101 wishes to connect to a chain of blocks 130, he will establish, by means of a computer device 151, a connection via a telecommunications network to the computer device 150 corresponding to an administrator Z0 of the targeted blockchain. If node 101 is a full node, a full copy of blockchain 130 will be created at node 101 after the first login and after this user Z1 has been granted rights to blockchain 130. Each new next user Z2, Z3 etc. will be able to connect to any of the nodes 100 or 101 already created.

Fig. 1B schematically illustrates the principle of updating block chains in the example case of a block chain 141 and a node 101. It is assumed here that the block chains 140, 141, and 142 are instances of the same chain of blocks 141. For a given chain of blocks, each node 101 (respectively 100, 102) comprises software 161 (respectively 160, 162) implementing all the functions associated with the chain of blocks considered. This software 161 (respectively 160, 162) can comprise at least a first software subset 161A (respectively 160A, 162A) configured to perform the data block write and read operations as well as the synchronization operations with the other instances of the blockchain on other nodes. According to what is requested by the user of the node 101, the software subset 161A locally updates the instance 141 of the chain of blocks considered by recording one or more new blocks of data. In a known manner, by a synchronization mechanism implemented through the communication network 110 connecting the various nodes 100, 101, 102, the other instances 140 and 142 of this chain of blocks are updated by recording these new blocks. of data at the level of the other nodes 100 and 102 respectively managing these other instances 140 and 142 of the chain of blocks. In the case of light nodes, this update may be limited to the data blocks concerned. The software 161 can also comprise at least a second software subset 161B (respectively 160B, 162B), based on the first software subset 161A and configured to implement the various functionalities described in this document. The software 161 (respectively 160, 162) may further comprise at least a third software subset 161C (not shown) based on the first and second software subsets 161A and 161B and configured to implement the functionalities of 'user interface.

Blockchain software can be one or more software applications. Each software subset of the software of a blockchain can correspond for example, depending on the chosen software architecture, to an autonomous software application within the software, or else an application layer within the software or even to one or more several software components within the software. Any other architecture is possible. Each operation performed on a given chain of blocks is carried out by means of the software associated with this chain of blocks, executed by the computing device of one of the nodes. For example, the operations carried out by a user Z1 on a given block chain will be carried out by means of the software 161 associated with the block chain in question, executed by the computing device 151 of the node 101 associated with the user Z1.

Similarly, the chains of blocks 130, 131, and 132 can be instances of the same chain of blocks and a synchronization mechanism is then implemented for these instances 130, 131, 132 through the communication network 110 connecting the various nodes 100, 101, 102.

. Each block of data stored in a chain of blocks 130, 131, 132 or 140, 141, 142 can be accessed by one or more users according to the rights of these users Z0, Z1, Z2 on this block of data.

The trust of blockchains is, in particular, based on the empowerment of each user who becomes fully involved in their own data management. A user can therefore have the possibility of creating datasets, if this is the case then he is the legitimate owner of the dataset, no one other than him can create new data within this dataset . In addition, everyone has on their own address, which is not accessible by any other actor, the data they may have received. It is therefore, a priori, impossible to carry out an action in place of someone else while leaving them autonomous on similar actions regardless of the level of rights of the person carrying out the action.

The rights of users on a blockchain are defined for the different user addresses of the permitted blockchain. A user address (173) corresponds to a personal identifier on the blockchain (as could be an email address on a mail server).

Fig. 1C illustrates the principle of generating a user address (173) for a chain of blocks. The user address (173) of a user entity (or user) of the blockchain can be seen as the (unique) identifier of this entity. This user address (173) is generally, in the case of asymmetric encryption, generated from a public signature key (172) (and therefore from the private key (171) since the public key (172) is in general calculated from the private key (171)). A user address (173) can be used by a user entity such as: a natural person, a script or any system, standalone or not, that can connect to a blockchain.

Fig. 1C notably illustrates the dependence between the private key (171), the public key (172) and the associated signature. The private key (171) is for example generated randomly, then by a first algorithm (for example ECDSA, Elliptic Curve Digital Signature Algorithm) the public key (172) is generated from the private key (171), then by a second algorithm (for example a hash function or "hash" according to the English terminology) the user address is generated from the public key (172).

In general, a blockchain user can manage several user addresses, these user addresses are kept in a wallet or “wallet”.

For a blockchain, it is possible to distinguish different categories of assets (or object classes). In Anglo-Saxon terminology, we speak of "assets", which is translated here as "assets". For example, the term "Bitcoin" usually refers to a blockchain that contains only one asset class of the same name: Bitcoin. Newer blockchain systems allow for different asset classes to be created according to user needs. The object class is usually the property of a single user address belonging to the user who created this object class and in this case only this user is able to generate new asset units for this asset. In the case of the Bitcoin blockchain, each user owns the Bitcoin asset.

Asset units are the units used to quantify each asset in an asset class. For example if an asset corresponds to an "Apple" category, the asset unit corresponds to an "apple". Asset units are held by addresses that have received these asset units, for example following transactions carried out by the blockchain. An instance of an object class, indicating a number of units of an asset of a given category, is the property of one and the same user address (173), i.e. is the property of a single user to whom this user address (173) is assigned. Only a user who owns units of assets is able to transmit or carry out operations on units of assets that he owns. .

Blockchain processors are the processes that move transactions from "unconfirmed" to "confirmed" status, miners for example in the case of a proof-of-work blockchain. By definition, processors can only accept, upon confirmation, technically complete and valid transactions. A partial transaction cannot be accepted by processors and therefore cannot be stored, as a transaction, in a blockchain.

Permissions (or user rights) define the rights of a user address (173) on a permitted blockchain. These are the permissions that indicate if the address is able to connect to the blockchain, if it can send and/or receive transactions, if it has the ability to create assets. This description covers both permitted systems and so-called non-permitted systems, that is to say without the slightest restriction of rights for any present or future user.

• Des droits de connexion pour une adresse utilisateur (173) ayant le droit de se connecter à la chaîne de blocs (cet ensemble de droits est nommé « Connect » sur la Fig. 1D) ; cet ensemble de droits inclut des droits de lecture, un utilisateur peut donc lire les blocs de données ;
• Des droits d’envoi pour une adresse utilisateur (173) ayant la possibilité d’envoyer de nouvelles transactions dans la chaîne de blocs (possède implicitement le droit de se connecter) (cet ensemble de droits est nommé « Send » sur la Fig. 1D) ;
• Des droits de réception pour une adresse utilisateur (173) ayant la possibilité de recevoir des transactions dans la chaîne de blocs (possède implicitement le droit de se connecter) (cet ensemble de droits est nommé « Receive » sur la Fig. 1D) ;
• Des droits de création d’actif pour une adresse utilisateur (173) ayant le droit de créer de nouveaux actifs dans la chaîne de blocs (possède implicitement le droit d’envoi et de réception) (cet ensemble de droits est nommé « Issue » sur la Fig. 1D) ;
• Des droits de création de blocs pour une adresse utilisateur (173) qui gère la création de nouveaux blocs dans la chaîne de blocs (cet ensemble de droits est nommé « Miner » sur la Fig. 1D)  ;
• Des droits d’administrateur grâce auxquels il est possible de donner et retirer différents droits à n’importe quelle adresse (cet ensemble de droits est nommé « Admin » sur la Fig. 1D);
• Des droits du créateur de la chaîne de blocs qui incluent au moins les droits d’administrateur (cet ensemble de droits est nommé « Origin Node» sur la Fig. 1D).

Examples of rights that can be granted to one or more user addresses of the blockchain are schematically illustrated in Fig. 1D and may include:

• Connection rights for a user address (173) having the right to connect to the blockchain (this set of rights is named "Connect" in Fig. 1D); this set of rights includes read rights, a user can therefore read the data blocks;
• Send rights for a user address (173) having the ability to send new transactions into the blockchain (implicitly has the right to connect) (this set of rights is named “Send” in Fig. 1D );
• Receive rights for a user address (173) having the ability to receive transactions in the blockchain (implicitly has the right to connect) (this set of rights is named "Receive" in Fig. 1D);
• Asset creation rights for a user address (173) having the right to create new assets in the blockchain (implicitly has the right to send and receive) (this set of rights is named "Issue" on Fig. 1D);
• Block creation rights for a user address (173) that manages the creation of new blocks in the blockchain (this set of rights is named “Miner” in Fig. 1D);
• Administrator rights with which it is possible to give and withdraw different rights at any address (this set of rights is named "Admin" in Fig. 1D);
• Blockchain creator rights that include at least administrator rights (this set of rights is named “Origin Node” in Fig. 1D).

Fig. 1D further illustrates the principle of generating a multisigned address (180, 190) for a plurality of blockchain users. A multisigned address (180, 190) can be used to sign transactions in a blockchain. A multisigned address (180, 190) can take different forms depending on the blockchain involved. A multisigned address (180, 190) is an address whose use is reserved for a predefined number of authorized signatories (or users). A multisigned address (180, 190) is generated from the signatures of authorized signers. A multisignature address (180, 190) is defined by the number of signatures required to confirm a transaction using that multisignature address (180, 190) and the list of associated authorized users (or signers) associated with those signatures. A multi-signed address (180, 190) is an address used for a transaction that can be signed by P different signing public key(s) associated with authorized signers and that must be signed by at least S public key(s) (s) of signature associated with the authorized signatories, with S <= P. Thus, a multisigned address (180, 190) is noted with (S x P) to inform of the number (S) of signatures necessary among the (P) keys possible public.

For example, if two signatories Alice and Bob have the right to sign on a multisigned address (180), then the number of signatures required for a transaction involving these two signatories is at least 1 (multisigned address 180) and at most 2 (multisigned address 190). If the number of signatures required is 1, then any transaction created with the multisigned address (180) can be confirmed if it has only one signature. If the number of signatures required is 2, then any transaction created with the multi-signed address (180) will require 2 signatures (one signature per signatory) in order to be confirmed. Any transaction carried out with a multi-signed address (180) bears the signature of the original address of the signature distinctly. For example, if Alice and Bob each have an address, a multisigned address (180) can be generated and if this multisigned address (180) only requires the signature of Alice or Bob, then for any transaction resulting from the address multisigned (180) and bearing only one signature, any user who can consult the transaction will be able to determine whether the transaction was signed by Alice or by Bob.

According to what is shown in FIG. 1D:
- the rights allocated to Alice are the rights "Miner", "Origin node" for a first address and "Send" and "Receive" for a second address;
- the rights allocated to Bob are the “Send”, “Issue” and “Receive” rights for a first address, the “Send” and “Receive” rights for a second address;
- the rights associated with the multisigned address can be assigned as needed; in the example of figure 1D, the associated rights correspond to the rights named “Send” and “Receive”.

Primary Blockchain and Secondary Blockchain

In the context of the present description, the notion of main block chain (also called master block chain or, more simply, master) and of secondary block chains is used. The master is the primary blockchain which has a supervisory function over the secondary blockchains. The master stores in particular the technical supervision information allowing the supervision of secondary blockchains, for example: user addresses, rights associated with users, connection parameters, etc….

Secondary blockchains are blockchains that store application information, such as information needed by systems/projects/applications associated respectively with each of these secondary blockchains. These chains of secondary blocks therefore generally do not contain any technical supervision information, unlike the master.

For all the situations where systems cannot support a chain of blocks whose size increases infinitely, the present description proposes a method of migrating chains of blocks. This migration process is applied to secondary blockchains supervised by a master or master blockchain.

During such a migration process, a secondary blockchain is replaced by a second secondary blockchain. The migration process can subsequently be applied to this second secondary blockchain so that this second secondary blockchain is itself replaced by a third secondary blockchain and so on. A secondary block chain thus succeeds a previous secondary block chain and the block chains thus form a temporal succession (or time series) of secondary block chains. A time series of blockchains is for example denoted BS26, and two successive chains of blocks with indexes 41 and 42 in the time series BS26 will be denoted for example BS26-41 and BS26-42. The index of the blockchain starts for example at 1 (BS26-1) for the initial blockchain and has, a priori, no limit. For the BS26 blockchain time series, we will denote BS26-Y a secondary blockchain (220) of any Y index and BS26-(Y-1) the previous secondary blockchain (220) in the time series and BS26-(Y+1) the next secondary blockchain (220) in the time series. The Y index thus corresponds to a version number of the BS26-Y blockchain.

Supervisory technical data is stored by the master (200) for each secondary blockchain (220) supervised by the master (200). The supervision technical data includes secondary blockchain creation parameters (220) and migration parameters.

The parameters for creating a secondary block chain (220) are a set of parameters that define criteria for creating block chains or a time series of block chains and parameters for migrating block chains within a time series. These creation parameters can be modified over time but are, by nature, set for a relatively long duration, at least for the duration of use of a blockchain of a time series.

Parameters for creating a blockchain may include: a description of the blockchain and/or a maximum size and/or a minimum size and/or a migration trigger size and/or a migration frequency and/ or a switchover time range and/or a migration end. Parameters such as maximum size and/or minimum size and/or migration trigger size and/or migration frequency and/or switchover time range and/or end of migration serve as migration parameters. These creation settings are described in more detail below.

Parameters such as maximum size and/or a minimum size and/or a migration trigger size and/or a migration frequency and/or a switchover time range and/or a migration end are migration parameters. Migration parameters are used to determine when a secondary blockchain should be migrated and the duration of this migration operation so that a migration start date can be derived from which the migration process should be triggered.

The description of a blockchain may comprise a general description valid for the entire time series, for example comprising information specific to the time series of blockchains concerned and/or a chain-specific description of specific blocks of a time series. All the information contained in the description is sufficiently exhaustive or explicit to allow a user to know if he is interested in this time series or a particular blockchain.

The maximum size of a blockchain is the maximum size allocated to this blockchain before this blockchain is replaced by another blockchain.

The minimum size of a blockchain is the minimum size allocated to this blockchain before this blockchain is replaced by another blockchain.

The migration trigger size of a blockchain is the desired size for that blockchain to trigger the replacement of that blockchain. If the system follows an evolution close to a linear evolution then a prediction system can be set up to determine, in advance, the moment when this size will be reached. The migration trigger size is greater than or equal to the minimum size and it is less than or equal to the maximum size. A migration frequency, expressed in units of time, can also be used instead of the migration trigger size to set the time after which the blockchain must be replaced.

The migration trigger size can be specified as an interval so as not to force a change at a time that is not suitable for application systems/projects. The failover time range allows you to specify one or more time ranges where the replacement of the blockchain will be best accepted by the application systems/projects.

At the end of the failover time range, the chain of blocks to be replaced is stopped and only the chain of replacement blocks is kept. The end of migration is therefore calculated as the moment when the criteria of size and time range of failover are met, and at the latest when the maximum size is reached.

When a BSX-Y blockchain comes to take over from another BSX-(Y-1), i.e. the BSX-Y blockchain contains up-to-date information for normal continuity of the system/application project, it may be necessary not to be limited to the only immediate information, i.e. a photograph of the data at the time of the start of the migration, but to include the data over a past period prior to the start of migration. This past period is called memory period or afterglow period. It can be determined so as to contain information from the past necessary for the proper consideration of the BSX-Y blockchain by the application systems/projects.

When a BSX-Y blockchain comes to replace another BSX-(Y-1) blockchain, in the majority of cases, the BSX-(Y-1) blockchain cannot be stopped (this is i.e. decommissioned and offline) before the BSX-Y blockchain is fully functional. It is therefore necessary to wait until all the application systems/projects have migrated from BSX-(Y-1) to BSX-Y. The duration allowed for this migration is defined as the migration allowed duration. The allowed duration for migrating a blockchain is before the switchover date to the new BSX-Y blockchain and may be the result of a predictive calculation. The result of the predictive calculation will be all the more consistent if the evolution of the size of the chain of blocks can be predicted (regular evolution, at best linear).
Supervisory areas

The master (200) comprises, for each chain of blocks under the supervision of the master (200), a supervision data storage zone, also called here technical zone or supervision zone (250), accessible, in read-only mode, by the users of the relevant blockchain. This supervision zone (250) makes it possible to store and exchange all the information necessary for the connection to the chain of blocks concerned, whether this chain of blocks is a first chain of blocks of a new time series or a chain of blocks replacing a previous blockchain in an already existing time series. The supervision zone (250) is also used to configure the use of the blockchain during the authorized migration period.

• une zone de supervision ZTBS1 commune est associée à la série temporelle de chaînes de blocs BS1-1, …BS1-42, …BS1-kk ;
• une zone de supervision ZTBS26 commune est associée à la série temporelle de chaînes de blocs BS26-1, …BS26-23, …BS1-ll ;
• une zone de supervision ZTBSxx commune est associée à la série temporelle de chaînes de blocs BSxx-1, …BSxx-15, …BSxx-mm.

The supervision area of a blockchain can be specific to a single blockchain version or can be common to all the blockchains of the blockchain time series to which this blockchain belongs. By the example of FIG. 2A, a single supervisory area (250) is used for the different blockchains of a blockchain time series:

• a common ZTBS1 supervision area is associated with the time series of blockchains BS1-1, …BS1-42, …BS1-kk;
• a common ZTBS26 supervision zone is associated with the time series of blockchains BS26-1, …BS26-23, …BS1-ll;
• a common supervision zone ZTBSxx is associated with the time series of blockchains BSxx-1, …BSxx-15, …BSxx-mm.

The supervision area (250) of a chain of blocks can include the parameters for creating the chain of blocks concerned.

The supervision area (250) of a secondary blockchain (220) (BS26) may include the connection parameters associated with the secondary blockchain (220) (BS26) concerned.

In the rest of the description, it is assumed for simplicity that a single supervision zone is used for a time series (BSX) of chains of secondary blocks and the corresponding supervision zone is denoted ZTBSX. The supervision zone (250) can include the associated user rights and the user addresses for the connection to each BSX-Y secondary blockchain concerned. The supervision zone (250) of a secondary block chain BSX-Y stores for example for each user Z, the user address (173) AM-BSX-Y-Z in association with the rights D-BSX-Y-Z associated with this user address (173) on the relevant blockchain. If for example the rights of a user are removed on a chain of secondary blocks (220) then the supervision zone (250) mentions it just as the supervision zone (250) includes data specifying the rights obtained by a user on a particular user address (173).

Phone book

According to what is illustrated by FIG. 2B, the master (200) stores in memory a directory (230) of users. This directory (230) of users comprises a first part, here called directory (230) master (200), composed of niches, called master niches (231). An NM-Z master niche (231) is a storage space (corresponding to one or more data blocks) associated with a user Z (with Z=Z0, Z1, Z2, etc.) of the master (200) and is configured to store the user address (173) A-M-Z allocated to this user Z for the connection to the master (200). The user address (173) A-M-Z allocated to a user for connection to the master (200) is called here master address or master address.

A master niche NM-Z (231) is configured to also store a business card of this user Z (with Z=Z0, Z1, Z2, etc.) in association with the master address of this user. The business card is a storage space where the identity of the user is detailed, for example in compliance with the regulations in force. A user's business card may include public and/or private information about that user such as last name, first name, alias, etc. Depending on the operation set up, this identity card can be managed by the user himself or by the administrator of the master (200). A user evaluation ("scoring" according to the Anglo-Saxon terminology) can be set up and open to participation by all other users of the master (200): in this case the business card can be used to store this type evaluation information.

The technical manager (also called administrator) of a secondary blockchain is also identified in a business card in the master's directory, like any other user. In the case of a secondary blockchain time series, there can be one administrator per secondary blockchain version or a single administrator for all versions of a blockchain time series.

The directory (230) of users comprises a second part, here called secondary directory, composed of niches, called secondary niches (232). An NBSX-Y-Z secondary niche (232) is a storage space (corresponding to one or more blocks of data) associated with a user Z and a given BSX-Y secondary blockchain. A secondary niche NBSX-Y-Z (232) is used to reference a user Z (with Z=Z0, Z1, Z2…) of a given BSX-Y secondary blockchain. A secondary niche NBSX-Y-Z (232) is stored in association with this user's master A-M-Z address and/or this user's business card. In a secondary niche NBSX-Y-Z (232) is stored the user address (173) AT-BSX-Y-Z (also called technical address) allocated to this user Z for the connection to the secondary block chain BSX-Y concerned in association with the user profile for this secondary blockchain. The user address (173) AT-BSX-Y-Z allocated to a user Z for connection to the secondary blockchain BSX-Y is also referred to here as secondary address. The user profile includes the user's rights to the relevant secondary blockchain.

The directory (230) may be structured per secondary blockchain such that niches associated with users with access to a secondary blockchain are grouped together. For example, the directory (230) can be structured in hives, with one hive per secondary blockchain, this hive comprising the niches associated with this secondary blockchain.

In one or more embodiments, a multisigned address (180) (also called "business address") AM-BSX-Y-Z is generated from two addresses: on the one hand, the user address (173) AT-BSX -Y-Z allocated to user Z for BSX-Y sub-blockchain login and on the other hand BSX-sub-blockchain administrator AT-BSX-Y-Z0 admin address Y. This multisigned address (180) is used for performing operations on the BSX-Y secondary blockchain (220), so that the technical administrator of the BSX-Y secondary blockchain is able to perform operations on behalf of this user Z1. Digital signature operation(s) of business transactions in the BSX-Y blockchain are performed: either through the secondary address AT-BSX-Y-Z1 when requested by user Z1, or through the admin address AT-BSX-Y-Z0, when requested by the technical administrator of the BSX-Y blockchain.

Catalog

According to what is illustrated by FIG. 2B, the master (200) also stores in memory a catalog (240) of secondary blockchains (see FIG. 2B). This catalog (240) lists the chains of secondary blocks supervised by the master (200) and the descriptions associated respectively with these chains of secondary blocks. The catalog (240) further comprises for each chain of secondary blocks (220) (for example BS26) a link to the supervision zone (250) (for example ZTBS26) of this chain of secondary blocks (220). For example in FIG. 2B, the catalog (240) contains a data block (241) which points to the supervision area ZTBS26 (250) of the secondary block chain BS26. The ZTBS26 supervisory area (250) includes a data block (251) associated with user Z which stores in association a multisigned address AM-BS26-Y-Z allocated to user Z for transaction signing in the blockchain secondary BS26 with user Z's D-BS26-Y-Z rights on secondary blockchain BS26.

A method of connecting a user to a blockchain will now be described with reference to FIGS. 3A and 3B. To simplify the description, the example case of a connection to a particular BS26 secondary blockchain (220) is described, but is applicable to any other secondary blockchain (220).

Although the steps of this method are presented sequentially, the order of execution of these steps can be modified, some of the steps can be executed at least partly in parallel, some of the steps can be omitted or repeated.

By way of example, reference will be made to Fig. 1A, and it will be assumed that the block chain master corresponds to block chain instances 140, 141, 142, that the administrator of the master corresponds to the user Z0 and therefore the node of the administrator of the master corresponds to the node 100.

Step 300: Save Catalog to Master

The master stores a catalog (240) of secondary blockchains. This catalog (240) includes for each chain of secondary blocks (220) a description and a link to a supervision zone (250) of the chain of secondary blocks (220) concerned. The storage of this information can be done as secondary blockchains are created and updates are made to these secondary blockchains.

This recording of the catalog can be done under the supervision of the Z0 administrator of the master. For example, with reference to FIG. 1A, this recording is done by means of the computer device 150 in the instance 140 of the master. It should be noted that at this stage, instances 141 and 142 of the master may not exist if users Z1 and Z2 are not yet registered with the master. If these instances exist, a synchronization takes place so as to update the different instances 141 and 142 of the master.

Step 305: Connect user to master (200)

User Z1 connects to the master (200) by means of a computing device 151 of node 101. The user is authenticated on the basis of his master address (173) A-M-Z1 which is allocated to him for access to the master and associated authentication data (for example a password or other).

By way of example, reference will be made to Fig. 1A, and this user will be assumed to be user Z1 of node 101. Thus, operations (e.g., reading or writing data, searching for data, etc.) performed by user Z1 on the master will be performed using of the software associated with the master executed by the computing device 151 of the node 101 of the user Z1. Similarly, operations (e.g. read or write data, transaction, etc.) performed by user Z1 on a given secondary block chain, e.g. BS26 will be performed by means of the software associated with the secondary block chain BS26 , executed by the computer device 151 of the node 101 associated with the user Z1.

This may be the first connection to the master, i.e. the phase where a user wishes to obtain a user address (173) (serving as an identifier) A-M-Z1 for connection to the master (200) and the rights relating to the master (200) which are attached to this user address (173) A-M-Z1. This first connection can be made using any known connection procedure. Thus, after the first successful authentication, the master address A-M-Z1 of the user Z1 is stored, by means of the software associated with the master executed by the computing device 151 of the node 101, in the master niche NM-Z1 (231) of this user. It can be stored in association with the Z1 user's business card.

In the event that a user loses the means to connect and wishes to access the master (200) again, this may correspond, technically, to a first authentication. To be connected to the master (200), it is usually necessary to request access rights via a communication channel other than the master (200), in order to be able to finalize access to the master (200).

Subsequently, for each secondary blockchain (220) to which the user will be connected, the secondary address (or technical address) AT-BSX-Y-Z1 of the user Z1 for the secondary blockchain (220 ) will be stored in the NBSX-Y-Z1 niche (232) of the relevant secondary blockchain (220) and refers to the user's business card and/or the user's master address.

After successful authentication, a Z1 user has access to the master (200), and in particular to the directory (230) and the catalog (240). In particular, a new instance 141 of the master is created at node 101. In the case of full nodes, this new instance is an integral copy of the instance 140 of the master of the administrator node 100 associated with the administrator Z0.

Like all data recording operations in the master, a synchronization takes place between the different instances 140, 141, 142 of the master block chain. For example, with reference to FIG. 1A, if it is assumed that the master block chain corresponds to block chain instances 140, 141, 142, and if the master block chain instance 141 is modified at node 101 as a result of the registration of the master address A-M-Z1 of user Z1 in the master niche NM-Z1 (231), instances 140 and 142 are also updated at the level of the other nodes 100 and 102 respectively.

Step 310: access the catalog (240) and search for a chain of blocks

After the user has connected to the main blockchain, the master (200) presents the catalog (240) of the secondary blockchains supervised by the master (200). Following a first authentication, the catalog (240) thus allows the user to know all the chains of secondary blocks managed.

A search (310) for at least one secondary blockchain (220) is performed in the blockchain catalog (240) based on search criteria entered by a user. As explained above, this search is carried out by means of the software associated with the master executed by the computer device 151 of the node 101 of the user Z1.

Step 320: Obtain Secondary Blockchain Connection Parameters.

The catalog (240) being linked to the supervision zones of the chains of secondary blocks, this makes it possible to find the connection parameters present in the supervision zone of each chain of secondary blocks (220).

Thus, the user Z1 obtains from the master, by means of the software associated with the master executed by the computer device 151, parameters for connection to a chain of secondary blocks BS26 corresponding to the search criteria or to a chain of secondary blocks BS26 selected by the user. These connection parameters are read in the supervision zone (250) of the secondary block chain BS26 concerned. According to the storage mode by full node or light node, the supervision zone (250) can be stored in the different instances 140, 141, 142 of the master or only in the instance 140 of the node 100 of the administrator Z0 of the master .

When a user Z1 finds and selects in the catalog (240) a chain of secondary blocks, for example BS26, to which the user wishes to connect (for example, after a search by keywords in the description of the chains of secondary blocks), the user thus obtains, via the ZTBS26 supervision zone of the secondary block chain BS26, connection parameters which will enable him to register with the secondary block chain BS26.

Step 330: Connect to Secondary Blockchain

This step concerns a first user connection to the secondary blockchain previously selected, this blockchain being a BS26 secondary blockchain whose access is supervised via the master.

The user sends, by means of a computing device (151), a connection request to the secondary blockchain BS26 using the connection parameters obtained at step 320. In practice, when the secondary blockchain BS26 is part of a series of blockchains, the connection is made on the current Y version of the secondary blockchain. Thus, the block chain concerned by steps 340 to 380 will be denoted BS26-Y, but these steps are applicable in the same way to an isolated block chain, not part of a series. This connection request is made by means of the software associated with the secondary block chain BS26-Y executed by the computer device 151 of the node 101 of the user Z1.

Step 340: allocation of technical address and multisigned address

The user obtains in return a user address (173) AT-BS26-Y-Z1 (secondary address, or technical address), serving as a connection identifier for the secondary blockchain BS26-Y.

After registration in the directory and allocation of the address AM-BS26-Y-Z1, the user Z1 also obtains the multisigned address (180) AM-BS26-Y-Z1 which is allocated to him for signing transactions to be registered in the name of this user in the secondary blockchain BS26-Y. The multisigned address (180) is generated from the secondary address AT-BS26-Y-Z1 and a technical address AT-BS26-Y-Z0 (or administrator address) of a blockchain administrator secondary BS26-Y. For the sake of simplicity of presentation and notations, it is assumed that the administrator of the secondary blockchain BS26-Y is the user Z0 of node 100 just like for the master. But it could be another user, for example user Z2 of node 102.

The secondary address AT-BS26-Y-Z1 (173) and the multisigned address (180) AM-BS26-Y-Z1 are generated by the software associated with the secondary blockchain BS26-Y, executed by means of the device computer 150 of the administrator node 100 of the secondary blockchain BS26-Y, under the control of the administrator Z0 of the secondary blockchain BS26-Y. During this step 340, the software associated with the chain of secondary blocks BS26-Y, executed by means of the computer device 150 of the administrator node 100 of the chain of secondary blocks BS26-Y is thus in communication with the software associated with the chain of secondary blocks BS26-Y, executed by means of the computing device 151 of the node 101 associated with the user Z1.

The multisigned address (180) AM-BS26-Y-Z1 is based on two signatures: on the one hand, the user's signature from the secondary address AT-BS26-Y-Z1 and, on the other hand , the signature of the technical manager (or administrator) taken from the AT-BS26-Y-Z0 address of the Z0 administrator of the secondary blockchain BS26-Y. The multisigned address (180) AM-BS26-Y-Z1 is determined so that it requires only one signature among the two possible signatures.

Step 350: recording in the directory (230) of the master (200).

The multisigned address (180) AM-BS26-Y-Z1 is registered in the master in the secondary directory (230) as a business address for the BS26-Y blockchain. The multisigned address (180) AM-BS26-Y-Z1 is recorded, in the NBS26-Y-Z1 niche of the BS26-Y secondary blockchain concerned, in association with the technical address AT-BS26-Y-Z1 so that an explicit link exists between the two addresses.

Only the administrator of the secondary blockchain BS26-Y has write rights in the supervision area of the secondary blockchain BS26-Y and in the secondary directory associated with the secondary blockchain BS26-Y. These rights of the administrator of the secondary blockchain BS26-Y on the master were previously requested from the master by an external process. Thus the registration in the directory of the master is carried out in the instance 140 of the master, by the software associated with the chain of secondary blocks BS26-Y, executed by means of the computing device 150 of the administrator node 100 of the chain of blocks secondary BS26-Y, under the control of the Z0 administrator of the secondary blockchain BS26-Y. Then, by a synchronization mechanism, the other instances 141 and 142 of the master are updated at the level of the associated nodes 101 and 102.

User Z1 has read rights on the master niche NBS26-Y-Z1 of the directory associated with it. After synchronization of the master instances, user Z1 can read the multisigned address (180) AM-BS26-Y-Z1 and the technical address AT-BS26-Y-Z1 in this master niche NBS26-Y-Z1 using of the software associated with the master, executed by means of the computing device 151 of the node 101 associated with the user Z1.

Step 360: registration of rights.

Rights on the secondary blockchain BS26-Y are allocated to the user by the administrator of the secondary blockchain BS26-Y. Like the generation of addresses, the allocation of rights on the secondary blockchain BS26-Y is carried out by the software associated with the secondary blockchain BS26-Y, executed by means of the computing device 150 of the administrator node 100 of the secondary blockchain BS26-Y, under the control of the Z0 administrator of the secondary blockchain BS26-Y.

The D-BS26-Y-Z1 rights granted to the AM-BS26-Y-Z business address are recorded in the master (200) in the ZTBS26 supervision zone of the BS26-Y secondary blockchain. These D-BS26-Y-Z1 rights are registered by the administrator of the BS26-Y blockchain in association with the multisigned address (180) AM-BS26-Y-Z1 in the ZTBS26 supervision zone of the blockchain. secondary blocks BS26-Y. This registration in the ZTBS26 supervision area of the master is carried out in the instance 140 of the master, by the software associated with the secondary block chain BS26-Y, executed by means of the computing device 150 of the administrator node 100 of the block chain. secondary BS26-Y, under the control of the Z0 administrator of the secondary blockchain BS26-Y. Then, by a synchronization mechanism, the other instances 141 and 142 of the master are updated at the level of the associated nodes 101 and 102.

User Z1 has read rights to the data in the ZTBS26 supervision zone that concerns him. After synchronization of the instances of the master, the user Z1 can read the rights D-BS26-Y-Z1 registered in the supervision zone ZTBS26 by means of the software associated with the master, executed by means of the computer device 151 of the node 101 associated with the user Z1.

Step 370: Connect to secondary blockchain BS26-Y.

The user uses the technical address AT-BS26-Y-Z1 to log in and access the secondary blockchain BS26-Y. The user is authenticated based on his user address (173) AT-BS26-Y -Z1 and associated authentication data (for example a password). This connection is made by means of the software associated with the secondary blockchain BS26-Y, executed by means of the computing device 151 of the node 101 associated with the user Z1.

Step 380: Record transaction in secondary blockchain BS26-Y.

The user sends, by means of his computer device 151, to the secondary block chain BS26-Y a request for recording a transaction. This transaction record request is issued from the multisigned address AM-BS26-Y-Z1. This request sending is carried out by the software associated with the secondary block chain BS26-Y, executed by means of the computer device 151 of the node 101 associated with the user Z1.

The transaction sent via the multi-signed address AM-BS26-Y-Z1 (if the transaction meets the required validation conditions) is signed by the user using the signature corresponding to the secondary address AT-BS26- Y-Z1, used for the generation of the multisigned address AM-BS26-Y-Z1.

When using a BS26-Y secondary blockchain, any transaction between two or more users is made from one multisigned address (180) to another multisigned address (180). Depending on the rights granted and the applications envisaged, transactions may allow the creation of assets, the creation of asset units, the sending of asset units, the carrying out of transactions which contain data not linked to an asset or any other action enabled by secondary blockchain technology BS26-Y within the rights granted.

After validation of the transaction, one or more blocks of data are recorded in the secondary block chain BS26-Y. Assuming here by way of example that the secondary blockchain BS26-Y corresponds to the instances 130, 131, 132 described with reference to FIG. 1A. This recording is thus carried out in the instance 131 of the chain of secondary blocks BS26-Y, by the software associated with the chain of secondary blocks BS26-Y, executed by means of the computing device 151 of the node 101 associated with the user Z1 . Then, by a synchronization mechanism, the other instances 130 and 132 of the corresponding secondary block chain BS26-Y are (depending on the need and the full node / light node mode) updated at the level of the associated nodes 100 and 102.

Migrating a Secondary Blockchain

A secondary blockchain migration method will now be described in more detail with reference to Figs. 4A and 4B.

Although the steps of this method are presented sequentially, the order of execution of these steps can be modified, some of the steps can be executed at least partly in parallel, some of the steps can be omitted or repeated.

This migration process is implemented in such a way as to retain only certain information from the migrated secondary blockchains, for example the application information. In this way the memory size occupied by the replacement secondary block chain is reduced compared to the memory size occupied by the replaced block chain. During this migration, the master (200) is in a way the conductor of the migration in that it supervises the migration by acting as a communication hub.

The migration of a chain of blocks is carried out under the supervision of the administrator of the BS26 and with the corresponding software 160 (in particular the software subset 160B, based on the software subset 160A), implemented works on the administrator's node Z0.

The migration of a blockchain is preferably carried out in such a way as to guarantee continuity of service for the applications (systems/application projects) implemented by this blockchain.

In the example below, the current secondary blockchain (220) BSX-(Y-1) (i.e. BS26-23 if for example X=26 and Y=24) is migrated to a new secondary blockchain ( 220) BSX-Y (i.e. BS26-24 if for example X=26 and Y=24).

During an initial step 400, a migration start date is calculated by the administrator of the current secondary blockchain (220). This calculation can be done in several ways.

In one embodiment, the end of migration is calculated, for example at regular time intervals. From the end of migration, the start of the switchover time range is calculated and, from the switchover time range and/or the end of migration, the start of the authorized migration duration is calculated. From the end of migration, the start of the buffer period is also calculated.

During step 410, on the occurrence of the start of the authorized migration duration, the new chain of secondary blocks BS26-Y is initialized and saved (connection parameters, migration parameters, description, and other useful parameters) in the master (200) at the request of the administrator of the current secondary block chain (220), this new secondary block chain being intended to replace a secondary block chain to be replaced.

Either the ZTBS26 supervision area is completed if only one supervision area is used for the series of blockchains, or a new ZTBS26-Y supervision area is created in the master (200) for the new secondary blockchain BS26- Y if a supervision zone specific to each version is used. This supervision area ZTBS26-Y includes the parameters for creating the new secondary block chain BS26-Y, these creation parameters can be identical or different from the parameters for creating the current secondary block chain BS26-(Y-1) .

Optionally, a new description of the new secondary blockchain BS26-Y is recorded in the catalog (240) of the master (200) or the description of the secondary blockchain series BS26-Y is updated.

These registration operations in the master's directory and catalog are executed by the Z0 administrator of the BS26 via the software associated with the master, by means of the computing device 150 of the administrator node 100 of the secondary block chain BS26-23 current, under the control of the Z0 administrator of the current BS26-23 secondary blockchain.

The triggering of the migration of the different instances of the current BS26-23 secondary blockchain that exist at the level of the different nodes 100, 101, 102 will be carried out at the same time by the Z0 administrator of the BS26. Then these different instances will be migrated according to the same migration method described below in steps 420 to 460 for the administrator node, possibly at different rates depending on the capacities and resources of the node concerned. We will describe below what happens for one of the instances, at the level of a node 100, 101 or 102.

During step 420, after initialization of the new secondary blockchain BS26-Y, the registration period begins and all users wishing or needing to register on the new secondary blockchain BS26-Y are invited to s connect to it and register in the directory (230) of the master (200) their new technical address for this new chain of secondary blocks BS26-Y.

For each new registration on the new chain of secondary blocks BS26-Y, the business address and the technical address of the user concerned are recorded in the master in the directory (230) associated with the new chain of secondary blocks as described with reference to FIGS. 3A and 3B. Only the administrator of the new secondary blockchain BS26-Y has write rights in the supervision area of the new secondary blockchain BS26 and in the secondary directory associated with the secondary blockchain BS26. Thus the recording in the directory of the master is carried out in the instance 140 of the master, under the control of the administrator Z0 of the chain of secondary blocks BS26-Y via the software associated with the chain of secondary blocks BS26-Y , executed by means of the computing device 150 of the administrator node 100 of the secondary blockchain BS26-Y. Then, by a synchronization mechanism, the other instances 141 and 142 of the master are updated at the level of the associated nodes 101 and 102. It is recalled here that there can be a single administrator for all the blockchains of a time series or one administrator per blockchain version. During the registration period, user rights may be modified or may not be renewed.

Each time a user registers for the new secondary blockchain, a new instance of this secondary blockchain is created at the node corresponding to the user concerned.

When the directory (230) of the new secondary block chain is completed with all or part of the business addresses of the current secondary block chain BS26-(Y-1), the rights are assigned to all the business addresses (multisigned addresses ) allocated for the new secondary blockchain BS26-Y. The technical addresses remain without rights, or alternatively with rights to send but without rights to receive for all the corresponding users, such that the state of the new chain of secondary blocks remains frozen until step 450 of switching users. In particular, no new data blocks can be generated in the new secondary blockchain.

During step 430, the initialization period, called "business initialization", begins after granting rights to business addresses. During this step 430, the administrator of the new chain of secondary blocks BS26-Y, having the right to sign on each multisigned business address, generates, with the business addresses (multisigned addresses) of the owner users, in the new chain of blocks, a set of data blocks corresponding to an image of the first block chain. The signing of these data blocks is done by the administrator by means of the administrator address of the secondary block chain BS26-Y. This image matches. at a specific time in the history of the first blockchain. For example, each asset and asset unit is recreated and asset units are allocated to user addresses such that the data image of the new secondary blockchain BS26-Y is identical to the data picture of the old secondary blockchain BS26-(Y-1) in terms of assets held by users.

The instant of generation of the image corresponds to the beginning of the memory period of the old secondary block chain BS26-(Y-1). The operations performed in the past on the old secondary blockchain BS26-(Y-1) during a time period of duration at the memory period of the old secondary blockchain BS26-(Y-1) are additionally performed on the new secondary blockchain BS26-Y so as to reproduce the corresponding relevant part of the history of the blockchain BS26-(Y-1).

According to what is illustrated in fig. 4A, the initial image is generated at time T0, corresponding to the start of the memory period. Then the operations carried out during a time period of duration T1-T0 are reproduced on the new chain of secondary blocks BS26-Y so that, following this reproduction, the state of the new chain of secondary blocks BS26-Y corresponds to the current state of the old blockchain at time T1. Time T1 also corresponds to the start of the migration period.

The generation of this image is carried out in a local instance of the new secondary block chain BS26-Y, by the software associated with the new secondary block chain BS26-Y, executed by means of the computing device 150 of the administrator node 100 of the new secondary blockchain BS26-Y, under the control of the Z0 administrator of the new secondary blockchain BS26-Y. Since no users are registered, there are no other instances of the new secondary block chain BS26-Y for which synchronization is necessary.

When, after the business initialization period, the so-called mirror period begins, corresponding to step 440. During this mirror period, the old secondary block chain BS26-(Y-1) coexists with the new block chain secondary BS26-Y and remains accessible for all operations in accordance with the rights granted. In addition, during the mirror period, new operations (transactions or other) carried out under the control of the Z0 administrator on the old secondary blockchain BS26-(Y-1) via the software associated with the secondary blockchain BS26-(Y-1), are also carried out under the control of the Z0 administrator on the new secondary block chain BS26-Y via the software associated with the secondary block chain BS26-Y, so that the image of the data always remains identical, at time t, on the two chains of secondary blocks BS26-Y and BS26-(Y-1). These new transactions are transactions for which a registration request has arrived at the block chain to be replaced or in the block chain of replacement. In the event that such a transaction involves a user who is not yet registered on the new blockchain, the registration of this user can be simulated by creating by assigning him a secondary address and a multisigned address and the registrations in the new blockchain are requested by the administrator of the new blockchain using this user's multi-signed address and signed with this administrator's secondary address.

During the mirror period, any new block created in the new or old blockchain is also duplicated by a synchronization mechanism in each of the existing instances of the new or old blockchain.

The user failover period begins after the start of the mirror period and corresponds to step 450. As illustrated by FIG. 4A, this user failover period can occur at least in part in parallel with the mirror period. At the beginning of the switchover time window, rights are allocated to technical addresses and systems/projects using the old secondary blockchain and having rights to the new secondary blockchain are allowed to switch to the new blockchain secondary BS26-Y. To record the switching of a user, a marker is stored, by means of the software associated with the master, under the control of the administrator Z0, for this user in the master (200) which includes the identifier of the block chain secondary to which a user is connected. A marker indicates whether or not a user has switched to the replacement blockchain. In practice, the switch of a user thus corresponds to a switch of rights from this user to the replacement blockchain (whether or not these rights are identical on these two blockchains).

From the moment the value of the marker is modified, the records of new transactions are redirected appropriately. Thus, if the user was on the blockchain to be replaced BS26-(Y-1) then it is the replacement blockchain BS26-Y which is updated with the software associated with BS26-Y, on the part of the user, to keep it in the image of the chain of blocks to be replaced BS26-(Y-1). Conversely, when the user has migrated to the replacement blockchain BS26-Y then the update is done on the blockchain to be replaced BS26-(Y-1) with the software associated with BS26-(Y- 1), from the user, so as to maintain an identical data image on both blockchains at a time when users are still logged in on one of the two blockchains and other users on the other of the two blockchains. It should be noted that this image does not take the past into account, since, as explained above for the creation of the starting image in step 430, the transactions prior to the start of the memory period are not reproduced, only the distribution of assets among users at the beginning of the memory period being replicated in the new blockchain.

During migration, the master serves as a communication registry in that the master helps to determine which version of the secondary blockchain a user must connect to at a given moment in the migration process, thanks in particular to the marker registered for this user. The two blockchains coexist for the duration of the mirror period during which users can be migrated from one chain to the other, each at different times and without constraint. Moreover, as a new chain of blocks is calculated, the calculation time required to start the new chain is reduced to a minimum.

When all users have migrated to the new secondary blockchain BS26-Y and no later than the scheduled migration end date, then the old secondary blockchain BS26-(Y-1), is stopped at step 460. This step corresponds to the switching between the old secondary blockchain BS26-(Y-1) and the new secondary blockchain BS26-Y. This switch between secondary blockchains is permanent so that any new transaction is recorded only in the new blockchain so that no more transactions can be recorded in the old blockchain BS26-(Y-1) and any new transaction is recorded only in the new BS26-Y blockchain. The mirror period therefore ends and all rights, except possibly the right to connect (set of rights "Connect" described with reference to Fig. 1D), are removed from the user addresses for the old secondary blockchain BS26-( Y-1). Retaining only connection rights does not allow users to delete their local instance on the old secondary blockchain BS26-(Y-1), but only to be able to reconnect to it and find all historical data there (rights of reading) if necessary.

The registration of the restricted rights on the old secondary blockchain is carried out in the master in the supervision area of the old blockchain in a local instance of the master, by the software associated with the master, executed by means of the device computer 150 of the administrator node 100 of the old secondary blockchain, under the control of the administrator Z0 of the old secondary blockchain.

If all users (except the administrator) only have connection rights on the old secondary blockchain, no changes can be made on the old secondary blockchain which therefore serves as an archive by compared to the new secondary blockchain. It is also possible that the rights of the administrator be reduced in one way or another.

A Z1 user has the option to delete the local instance at their node 101 of older blockchain versions for which migration is complete. All information relating to transactions prior to the migration (prior to the migration period) is indeed kept at the level of the BS26 administrator node without it being necessary to keep at the level of the other nodes.

After switching to the new secondary blockchain, any new user is forced to use the new secondary blockchain BS26-Y from the shutdown of the old secondary blockchain BS26-(Y-1) so to be able to continue to use the functionalities associated with this secondary BS26 blockchain.

In all the processes described in this document, the master has a supervisory role but does not determine how rights are allocated to users in the various secondary blockchains. The master therefore has a declarative and storage role for information relating to supervised blockchains.

An administrator of a secondary blockchain could not store on the rights allocated to users in the master and rely solely on the secondary blockchain's internal management of these rights to determine which rights to apply. The rights of an administrator on the master could in this case be withdrawn.

Migration of Master

The master (200) is the entity that manages secondary blockchain migrations within a single secondary blockchain time series. Technically, the master (200) is a blockchain just like secondary blockchains. Thus, the master (200) can also exceed a maximum size limit, for example a size limit tolerated by the users. It may therefore be necessary to replace the master (200) in the same way as replacing secondary blockchains.

The current master (200) can thus be replaced by a new master (200) by following the same migration process as the secondary blockchains with the only difference that the migration data is self-supporting, i.e. the current master (200) itself stores all the data necessary for the migration of users from the current master (200) to the new master (200).

In one or more embodiments, the creation parameters of a new master (200) contain, in addition to the creation parameters described for the secondary blockchains, a pointer to the previous master (200) which allows users having had an activity to better use the history stored in the previous master (200) if necessary.

The various methods described in this document can be implemented by one or more programmed computers. Thus, in this document, certain representations are also intended to cover computer program storage devices, for example digital data storage media, which are machine or computer readable and encode instructions executable by a machine or by a computer, in which the instructions make it possible to implement all or part of the steps of the methods described in this document.

The functions of the various elements shown in the figures, including the functional blocks called "processors", can be provided by the use of dedicated hardware as well as hardware capable of running software in conjunction with appropriate software . When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by several individual processors, some of which may be shared. Other materials, conventional and/or specific, can also be included.

This document thus relates to a computer program, capable of being executed by a computer or by a data processor, this computer program comprising instructions for controlling the execution of the steps of a method or several of the methods described in this document.

This computer program may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in partially compiled form, or in no any other desirable shape.

The instructions are intended to be stored in a memory of a computer device 150, 151, 152 in order to be processed (read, interpreted, etc.) with a view to their execution by one or more processors of this device.

Computing device 150, 151, 152 may be implemented by one or more physically separate machines. The device may globally present the architecture of a computer, including components of such an architecture: data memory(s), processor(s), communication bus, hardware interface(s) for the connection of this device to a network or other equipment, user interface(s), etc.

Further, the term "processor" shall not be construed to refer exclusively to hardware capable of executing software, and may include pure hardware components, a digital signal processor (DSP), a network processor, a circuit Application-Specific Integrated (ASIC), Programmable Gate Array (FPGA), etc.

This description also relates to a data storage medium readable by a computer, transient or not, and comprising instructions of a computer program as mentioned above. The data storage medium can be any entity or device capable of storing the computer program. For example, the data storage medium may comprise one or more ROM or RAM memories, one or more flash memories, one or more digital memories, one or more magnetic storage media such as magnetic disks and magnetic tapes, disks drives or optically readable digital data storage media, etc.

Claims (12)

Method for migrating a chain of blocks to be replaced, called the first chain of blocks, to a chain of replacement blocks, called the second chain of blocks, the method being implemented by one or more computers and comprising:
- an initialization (410) of the second chain of blocks, the initialization comprising a generation, in a chain of main blocks configured to supervise access to the first and second chains of blocks, of a supervision zone (250) of the second blockchain configured to store user rights to the second blockchain;
- a registration (420) of one or more users with the second blockchain, the registration of a user comprising a record in a directory (230) of users in the primary blockchain of a secondary address allocated to this user for connecting to the second blockchain;
- a generation (430) in the second chain of blocks of a set of data blocks corresponding to an image of the first chain of blocks, the image corresponding to a given instant in the history of the first chain of blocks;
- a recording (440) of new transactions for which a recording request has arrived at the first block chain both in the first block chain and in the second block chain during a so-called mirror period;
- a switch (450) of all or part of the users of the first chain of blocks to the second chain of blocks so as to prohibit the recording of transactions in the name of these users in the first chain of blocks and to authorize the recording of transactions on behalf of these users in the second blockchain. Method according to claim 1, comprising a permanent switch to the second chain of blocks by modifying the rights of the users on the first chain of blocks, so that no more transactions can be recorded in the first chain of blocks and any new transaction is recorded only in the second blockchain. A method according to claim 1 or 2, wherein the first chain of blocks is implemented in a communication system comprising a plurality of nodes (100, 101, 102) and an instance of the first chain at each node, the method comprising, for at least one node of the communication system, following the definitive failover, a deletion of the instance of the first chain of blocks located at the level of the node considered. A method as claimed in claim 1 or 2, comprising allocating to each user of the second blockchain a multi-signed address (180) for signing transactions to be recorded in the second blockchain on behalf of that user, the address multisignature (180) being generated from the secondary address allocated to this user for the connection to the second chain of blocks and an administrator address of the second chain of blocks. A method as claimed in claim 4, wherein the secondary address allocated to a user for connecting to the second blockchain is stored in the user directory (230) along with the multisigned address (180). A method according to any of claims 4 to 5, wherein the multisigned address (180) is used to register new transactions in the second blockchain during the mirror period. A method according to any of claims 4 to 6, wherein a user's rights to the second blockchain are registered in the supervision area (250) in association with the multisigned address (180) allocated to that user . A method according to any preceding claim, wherein generating the image of the first blockchain includes storing in the second blockchain a set of data blocks representative of units of assets held by one or more users of the first blockchain at the determined time. A method according to any preceding claim, comprising recording in the main blockchain a marker for each user indicating whether or not that user has switched to the second blockchain. Device comprising means for implementing the method according to any one of Claims 1 to 9. Data storage medium readable by a data processor on which is recorded a program comprising instructions for the execution of the steps of a method according to any one of claims 1 to 9. Computer program product comprising instructions for carrying out the steps of a method according to any one of claims 1 to 9 when said program is executed by a data processor.