EP4026016A1 - Migration d'une chaîne de blocs de données - Google Patents

Migration d'une chaîne de blocs de données

Info

Publication number
EP4026016A1
EP4026016A1 EP20757362.7A EP20757362A EP4026016A1 EP 4026016 A1 EP4026016 A1 EP 4026016A1 EP 20757362 A EP20757362 A EP 20757362A EP 4026016 A1 EP4026016 A1 EP 4026016A1
Authority
EP
European Patent Office
Prior art keywords
blockchain
user
blocks
chain
address
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP20757362.7A
Other languages
German (de)
English (en)
Inventor
Hubert MARTEAU
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Worldline SA
Original Assignee
Worldline SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from FR1909627A external-priority patent/FR3100351B1/fr
Priority claimed from FR1909624A external-priority patent/FR3100350B1/fr
Application filed by Worldline SA filed Critical Worldline SA
Publication of EP4026016A1 publication Critical patent/EP4026016A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/214—Database migration support

Definitions

  • the invention relates to the field of block chains and more particularly to a technique for migrating block chain (s).
  • a chain of blocks indexes the data deemed important. Every block, every transaction, every address, for example, is an indexed key for quick access to data. 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 slower its performance.
  • the present description relates to a method of 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. implemented by one or more computers.
  • 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 chain of blocks; 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; generation 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 determined instant in the history of the first chain of blocks; a switchover of all or part of the users from the first chain of blocks to the second chain of blocks 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.
  • the method according to the first aspect comprises recording new transactions for which a registration request has reached the first blockchain both in the first blockchain and in the second chain of blocks for a period, called the mirror period, before the switching step. This makes it possible to avoid a sudden switch from one blockchain to another and to provide a period during which the users will be able to switch individually, each according to their needs, from the first blockchain to the second blockchain.
  • the method according to the first aspect comprises a definitive switch to the second blockchain by modifying the rights of the users on the first blockchain, so that no more transactions can be recorded in the first blockchain and any new transaction is recorded only in the second blockchain.
  • the method according to the first aspect the supervision area of the second blockchain configured to store user rights on the second blockchain.
  • the first blockchain 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 switchover, a deletion of the instance of the first chain of blocks located at the level of the node considered.
  • the method according to the first aspect comprises an allocation to each user of the second blockchain of a multi-signed address for signing transactions to be recorded in the second blockchain on behalf of this user, the multisigned address being generated from the secondary address allocated to this user for connection to the second block chain and from an administrator address of the second block chain.
  • the secondary address allocated to a user for connection to the second blockchain is stored in the user directory in association with the multi-signed address .
  • the multi-signed address is used to record new transactions in the second blockchain during the mirror period.
  • the rights of a user on the second blockchain are recorded in the supervision area in association with the multisigned address allocated to this user.
  • 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. assets held by one or more users of the first blockchain at the determined time.
  • the method according to the first aspect comprises recording in the main blockchain of a marker for each user indicating whether or not this user has switched to the second blockchain.
  • 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 (s) and the computer program code being configured to, together with the processor (s), cause execution by the processor.
  • device of the steps of the method according to the first aspect the memory (s) comprise a computer program comprising instructions configured to cause the device to perform the steps of the method according to the first aspect.
  • the various steps of the method according to the first aspect are implemented by one or more computer programs.
  • 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.
  • 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.
  • FIG. 1A schematically shows a communication system comprising block chains
  • FIG. 1B schematically illustrates aspects of a node of a communication system according to Fig. 1A;
  • FIG. 1C illustrates aspects of generating a user address
  • FIG. 1D illustrates aspects of generating a multi-signed address
  • FIG. 2A schematically shows the relationships between a main blockchain and secondary block chains
  • FIG. 2B schematically represents the relationships between a main block chain and secondary block chains for the management of the rights and addresses of a user
  • FIG. 3A schematically illustrates aspects of a method of connecting a user to a secondary blockchain
  • FIG. 3B represents 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;
  • FIG. 4A schematically illustrates aspects of a process for migrating from a secondary blockchain to be replaced to a secondary blockchain replacement
  • FIG. 4B is a flowchart of a process for migrating from a secondary blockchain to be replaced to a replacement secondary blockchain according to one or more embodiments.
  • blockchains can be used to record any type of transaction. Behind the scenes, a blockchain is generally defined as a computerized ledger of transactions. The blockchain (this computerized ledger) "grows" as more data blocks are recorded in it, these data blocks corresponding to new transactions or to sets of new transactions that are added to the chain. of blocks. New data blocks corresponding to new transactions are recorded in the blockchain after a validation process that is specific to each blockchain.
  • transaction can cover any type of transaction between one or more actors. It can relate to any type of product or material, device component, packaging and / or document or physical or electronic file, including virtual assets such as data, electronic files, intangible assets or even data. cryptocurrency.
  • blockchain technology allows the creation of a computerized register of transactions, non-repudiable, resistant to forgery.
  • FIG. 1A schematically represents a communication system 1000 for the implementation of blockchains, in the case of a decentralized architecture.
  • This communication system 1000 includes several nodes 100, 101, 102 communicating with each other through a communication network 110. These nodes are generally organized in a network of peers.
  • This figure shows an example of a network illustrating the “decentralized” nature of the blockchain and the relationships between network nodes (peer-to-peer network).
  • This figure schematically illustrates a possible architecture of an operating network and / or use of one or more blockchains. Another architecture or infrastructure could be chosen.
  • Each node 100, 101, 102 of the communication system 1000 can correspond to one or more physically distinct computer devices, implementing software corresponding to one or more software applications.
  • This software implements, at the node level in question, the functionalities of a block chain and accesses one or more data sets for the storage of the data blocks of the block chain in question.
  • the data blocks can be stored in a distributed manner (in this case, we speak of a distributed register, or "distributed ledger" according to English terminology) , for example on one or more sub-nodes of a local network at the level of the node considered.
  • the node 100 comprises a computer device 150, implementing the functionalities of two chains of blocks 130, 140 and accessing two sets of data 130, 140, which correspond respectively to these two chains of blocks 130, 140.
  • the node 101 comprises a computer device 151, implementing the functionalities of two chains of blocks 131, 141 and accessing two sets of data 131, 141, which correspond respectively to these two chains of blocks 131, 141.
  • 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 computer device 150, 151, 152 can be implemented by one or more physically distinct machines.
  • the computing device 150 can have the overall 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, interface (s) user, etc.
  • Each computer 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 channels of associated blocks 130, 131, 132 and / or 140, 141, 142.
  • each computer device 150, 151, 152 implements user registration functions, allocation of rights on the block chain , user address allocation, blockchain access control, signing and recording transactions, reading and writing data sets or data blocks, etc., as described in this document for the relevant blockchain.
  • a node 100, 101, 102 can be a full node or a lightweight node for a given blockchain. If the node 100, 101, 102 is a full node, the node stores locally (in one of the local data sets) all the data blocks of the blockchain: the data blocks are in this case duplicated as many times as 'there are knots. [0037] In the example of FIG. 1A, if it is assumed that the blockchain 130 (respectively 140) is initially created by an administrator Z0 by means of the computing device 150, then each of the blockchains 131 and 132 (respectively 141 and 142) are an instance of the same. blockchain 130 (respectively 140). If node 100, 101, 102 is a lightweight node, the node locally stores only user Z0, Z1, or Z2 data blocks from that node. The invention described in this document is applicable regardless of the type of node.
  • a user Z1 of the 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 connection and after rights have been given to this user Z1 on blockchain 130. Each new one following user Z2, Z3 etc will be able to connect to any one of the nodes 100 or 101 already created.
  • FIG. 1 B schematically illustrates the principle of updating block chains in the exemplary case of a block chain 141 and of a node 101.
  • This figure schematically illustrates a possible architecture of a computer system. for the operation and / or use of a blockchain.
  • Fig. 1B represents an example of a local node serving to illustrate the "autonomous" character of the blockchain where the data is stored locally for each node and updated by the network and requires a "Interface" to be used by the local node.
  • Another architecture or physical / material structure could be considered.
  • each node 101 includes software 161 (respectively 160, 162) implementing all the functions associated with the chain of blocks considered.
  • This software 161 can comprise at least a first software sub-assembly 161 A (respectively 160A, 162A) configured to perform the operations of writing and reading of data blocks as well as the operations of synchronization with the data blocks. other instances of the blockchain on other nodes.
  • the software subset 161A locally updates the instance 141 of the considered blockchain by recording one or more new data blocks.
  • the software 161 may further include at least a second software sub-assembly 161 B (respectively 160B, 162B), based on the first software sub-assembly 161A and configured to implement the various functionalities described in this document.
  • the software 161 (respectively 160, 162) can further include at least a third software subset 161C (not shown) based on the first and second software subsets 161A and 161 B and configured to implement the functionalities. user interface.
  • the software of a blockchain can correspond to one or more software applications and one or more computer devices.
  • Each software subset of the software of a blockchain can correspond for example, depending on the software architecture chosen, to a stand-alone software application within the software, or 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 blockchain is performed by means of the software associated with this blockchain, executed by the computing device of one of the nodes. For example, the operations performed by a user Z1 on a given block chain will be performed by means of the software 161 associated with the block chain considered, executed by the computer device 151 of the node 101 associated with the user Z1.
  • the blockchains 130, 131, and 132 can be instances of the same blockchain 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 data block stored in a chain of blocks 130, 131, 132 or 140, 141, 142 can be accessed by one or more users depending on the rights of these users Z0, Z1, Z2 on this data block.
  • the trust of blockchains is, in particular, based on the empowerment of each user who becomes fully involved in his 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.
  • each has on its own address, which is not accessible by any other actor, the data that it may have received. It is therefore, a priori, impossible to carry out an action for someone else while leaving him or her autonomous over similar actions regardless of the level of law of the person carrying out the action.
  • a user address (173) is a personal identifier on the blockchain (like an email address on a mail server).
  • FIG. 1C illustrates the principle of generating a user address (173) for a blockchain.
  • the user address (173) of a user entity (or user) of the blockchain can be seen as the (unique) identifier of that entity.
  • This user address (173) is generally, in the case of asymmetric encryption, generated from a public signing 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 physical person, a script or any system, autonomous or not, which can connect to a blockchain.
  • FIG. 1C illustrates in particular 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).
  • a blockchain user can manage several user addresses, these user addresses are kept in a wallet or “wallet”.
  • asset For a chain of blocks, it is possible to distinguish different categories of assets (or object classes).
  • assets In Anglo-Saxon terminology, we speak of “assets”, which is translated here as “assets”.
  • the term “Bitcoin” usually refers to a blockchain that contains only one category of assets of the same name: Bitcoin. Newer blockchain systems allow different categories of assets to be created according to user needs.
  • the object class is generally owned by a single user address belonging to the user who created this object class and in this case only that user is able to generate new units of assets for this asset.
  • each user owns the Bitcoin asset.
  • Asset units are the units used to quantify each asset of an asset class. For example if an asset corresponds to an "Apple" category, the asset unit corresponds to an "apple". Units of assets are held by addresses that received those units of assets, for example as a result of blockchain transactions. An instance of an object class, indicating a number of units of an asset of a given category, is owned by 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 transact on units of assets he owns. .
  • Blockchain processors are the processes that move transactions from "unconfirmed” to "confirmed” status, such as miners 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.
  • the permissions define the rights of a user address (173) on a permitted blockchain. These are the permissions that indicate whether the address is able to connect to the blockchain, whether it can send and / or receive transactions, whether it has the ability to create assets.
  • the present description is aimed at both authorized systems and so-called non-authorized systems, that is to say without the slightest restriction of rights for any present or future user.
  • 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, so a user can read the data blocks;
  • 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) which manages the creation of new blocks in the blockchain (this set of rights is named "Miner” in Fig. 1D);
  • FIG. 1D further illustrates the principle of generating a multi-signed address (180, 190) for a plurality of users of a blockchain.
  • a multi-signed address (180, 190) can be used to sign transactions in a blockchain.
  • a multi-signed address (180, 190) can take different forms depending on the blockchain involved.
  • a multisigned address (180, 190) is an address the use of which is reserved for a predefined number of authorized signatories (or users).
  • a multisigned address (180, 190) is generated from the signatures of the authorized signatories.
  • a multi-signed address (180, 190) is defined by the number of signatures required to confirm a transaction using that multi-signed address (180, 190) and the list of authorized associated users (or signatories) associated with these signatures.
  • S x P to inform of the number (S) of signatures required among the (P) keys public possible.
  • the number of signatures required for a transaction involving these two signers is at least 1 (multisigned address 180) and at maximum of 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 signer) to be able to be confirmed. Any transaction carried out with a multisigned address (180) bears the signature of the original address of the signature.
  • a multi-signed address (180) can be generated and if this multi-signed address (180) only requires the signature of Alice or Bob, then for any transaction 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.
  • FIG. 1D According to what is shown in FIG. 1D:
  • the rights allocated to Alice are the "Miner”, "Origin node” rights 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 multi-signed address can be assigned as needed; in the example of Figure 1D, the associated rights correspond to the rights named "Send” and "Receive”.
  • main block chain and secondary block chain In the context of the present description, the notion of main block chain (also called master block chain or, more simply, master) and of chains of secondary blocks.
  • the master is the main blockchain which has a supervisory function on the secondary blockchains.
  • the master notably stores the technical supervision information allowing the supervision of secondary blockchains, for example: user addresses, rights associated with users, connection parameters, etc.
  • Secondary block chains are block chains which store application information, for example information necessary for systems / projects / applications associated respectively with each of these secondary block chains. These secondary block chains therefore generally do not contain any technical supervision information, unlike the master.
  • a secondary blockchain is replaced by a second secondary blockchain.
  • the migration method 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 block chains of index 41 and 42 in the time series BS26 will be denoted for example BS26-41 and BS26-42.
  • the blockchain index starts at 1 (BS26-1) for the initial blockchain and does not presumably have a limit.
  • BS26-Y a secondary blockchain (220) of any index Y 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.
  • Technical supervision data is stored by the master (200) for each secondary block chain (220) supervised by the master (200).
  • the technical data for supervision includes parameters for creating a secondary blockchain (220) and parameters for migration.
  • the parameters for creating a secondary blockchain (220) are a set of parameters that define criteria for creating blockchains or time series of blockchains and parameters for migrating blockchains within of a time series. These creation parameters can be changed over time but are inherently set for a relatively long duration, at least for the duration of use of a blockchain in a time series.
  • the parameters for creating a blockchain can 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 frequency of migration and / or a switchover time range and / or an end of migration.
  • 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 parameters are described in more detail below.
  • the parameters such as maximum size and / or a minimum size and / or a size of Migration trigger and / or migration frequency and / or switchover time range and / or migration end are migration parameters.
  • Migration parameters are used to determine when a secondary blockchain should be migrated and the duration of that migration operation so that a migration start date can be derived when the migration process should be triggered.
  • the description of a blockchain can include a general description valid for the entire time series, for example comprising information specific to the time series of blockchains concerned and / or a description specific to a specific blockchain. of a time series. All of the information contained in the description is sufficiently comprehensive or explicit to allow a user to know if they are interested in this time series or a particular blockchain.
  • the maximum size of a blockchain is the maximum size allocated to that blockchain before this blockchain is replaced by another blockchain.
  • the minimum size of a blockchain is the minimum size allocated to that blockchain before that blockchain is replaced by another blockchain.
  • the blockchain migration trigger size is the desired size for this blockchain to trigger the replacement of this blockchain. If the system follows an evolution close to a linear evolution then a prediction system can be set up to determine, in advance, 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 length of time after which the blockchain should be replaced.
  • the migration trigger size can be specified as an interval so as not to force a change at a time that is unsuitable for systems / application projects.
  • the failover time range allows you to specify one or more time ranges where blockchain replacement will be best accepted by application systems / projects.
  • 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.
  • BSX-Y blockchain takes over from another BSX- (Y-1), that is to say that the BSX-Y blockchain contains up-to-date information for the normal continuity of the system / application project, it may be necessary not to limit oneself to the only immediate information, that is to say a snapshot of the data at the time of the start of migration, but to include data over a period preceding the start of migration. This past period is called the memory period or the remanence period.
  • BSX-Y blockchain replaces another BSX- (Y-1) blockchain
  • the BSX- (Y-1) blockchain cannot be stopped ( i.e. decommissioning and offline) before the BSX-Y blockchain is fully functional. It is therefore necessary to wait until all systems / application projects have migrated from BSX- (Y-1) to BSX-Y.
  • the time allowed for this migration is defined as the time allowed for migration.
  • the allowed time to migrate a blockchain is prior to 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 as the evolution of the size of the blockchain can be predicted (regular evolution, at best linear).
  • the master (200) comprises, for each chain of blocks under the supervision of the master (200) a supervision data storage area, here also called technical area or supervision area (250), accessible, read only , by users of the relevant blockchain.
  • This supervision zone (250) makes it possible to store and exchange all the information necessary for connection to the block chain concerned, whether this block chain 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 area (250) is also used to configure the use of the blockchain during the authorized migration period.
  • the supervision area of a blockchain can be specific to a single version of the blockchain or else be common to all the blockchains of the blockchain time series to which this blockchain belongs.
  • a single supervision zone (250) is used for the different blockchains of a time series of blockchains: a common supervision zone ZTBS1 is associated with the time series of blockchains BS1-1, .. BS1-42, ... BS1-kk; a common ZTBS26 supervision area is associated with the time series of blockchains BS26-1, ... BS26-23, ... BS1-II; a common ZTBSxx supervision zone is associated with the time series of blockchain BSxx-1, ... BSxx-15, ... BSxx-mm.
  • the supervision area (250) of a blockchain can include the parameters for creating the blockchain concerned.
  • the supervision area (250) of a secondary blockchain (220) (BS26) can include the connection parameters associated with the secondary blockchain (220) (BS26) concerned.
  • the supervision zone (250) can include the associated user rights and the user addresses for connection to each concerned BSX-Y secondary blockchain.
  • the supervision zone (250) of a secondary block chain BSX-Y stores for example for each user Z, the user address (173) AM-BSX-YZ in association with the D-BSX-YZ rights associated with this user address (173) on the affected blockchain. If for example the rights of a user are deleted on a secondary blockchain (220) then the supervision zone (250) mentions it just as the supervision zone (250) comprises data specifying the rights obtained by a user on a particular user address (173).
  • the master (200) stores in memory a directory (230) of users.
  • This directory (230) of users includes a first part, called here directory (230) master (200), composed of niches, called niches master (231).
  • the user address (173) A-M-Z allocated to a user for connection to the master (200) is referred to here as the master address or master address.
  • 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 implemented, this identity card can be managed by the user himself or by the administrator of the master (200).
  • An evaluation of the user (“scoring” according to the Anglo-Saxon terminology) can be set up and open for participation to all the other users of the master (200): in in this case the business card can be used to store this type of evaluation information.
  • the technical manager (also called administrator) of a secondary blockchain is also identified in a business card in the directory of the master, like any other user.
  • a secondary blockchain time series there may be one administrator per secondary blockchain version or a single administrator for all versions of a blockchain time series.
  • the directory (230) of users includes a second part, referred to herein as a secondary directory, composed of niches, called secondary niches (232).
  • An NBSX-Y-Z (232) secondary niche is storage space (corresponding to one or more data blocks) associated with a Z user and a given BSX-Y secondary blockchain.
  • An NBSX-Y-Z (232) secondary niche is stored in association with that user's A-M-Z master address and / or that user's business card.
  • NBSX-YZ In a secondary niche NBSX-YZ (232) is stored the user address (173) AT-BSX-YZ (also called technical address) allocated to this user Z for connection to the secondary block chain BSX-Y concerned in association with the user profile for this secondary blockchain.
  • the AT-BSX-Y-Z user address (173) allocated to a Z user for connection to the BSX-Y secondary blockchain is also referred to herein as the secondary address.
  • the user profile includes the rights of the user on the relevant secondary blockchain.
  • the directory (230) can be structured by secondary blockchain so that the niches associated with users having access to a secondary blockchain are grouped together.
  • the directory (230) can be structured in hives, with one hive per secondary blockchain, this hive comprising the niches associated with this secondary blockchain.
  • a multisigned address (180) (also called "business address”) AM-BSX-YZ is generated from two addresses: on the one hand, the user address (173) AT-BSX-YZ allocated to user Z for connection to the secondary blockchain BSX-Y and, on the other hand, the administrator address AT-BSX-Y-Z0 of the blockchain administrator secondary BSX-Y.
  • This multi-signed address (180) is used for performing operations on the secondary blockchain (220) BSX-Y, so that the technical administrator of the secondary blockchain BSX-Y is able to perform operations. on behalf of this Z1 user.
  • the digital signature operation (s) of business transactions in the BSX-Y blockchain are performed: either by means of the secondary address AT-BSX-Y-Z1 when requested by user Z1, or by means of the administrator address AT-BSX-Y-ZO, when requested by the technical administrator of the BSX-Y blockchain.
  • the master (200) also stores in memory a catalog (240) of secondary blockchains (see FIG. 2B).
  • This catalog (240) lists the secondary block chains supervised by the master (200) and the descriptions respectively associated with these secondary block chains.
  • the catalog (240) further includes for each secondary block chain (220) (eg BS26) a link to the supervision area (250) (eg ZTBS26) of this secondary block chain (220).
  • the catalog (240) contains a data block (241) that points to the ZTBS26 supervision area (250) of the secondary blockchain BS26.
  • the ZTBS26 supervision area (250) comprises a data block (251) associated with the user Z which stores in association a multisigned address AM-BS26- YZ allocated to the user Z for the transaction signing in the blockchain.
  • the blockchains to which a user is likely to connect can multiply. These blockchains may correspond to related applications so that there is a need for centralized management and / or control of connections to different blockchains.
  • a method for connecting to a block chain is implemented by one or more computers and comprises: receiving a request for connection to the block chain, the block chain being a secondary blockchain whose access is supervised via a primary blockchain; allocation to the user of a secondary address for connection to the secondary blockchain; a record, in the primary blockchain, in a user directory, of the secondary address; a recording, in the main block chain, in a supervision area of the secondary block chain, of the rights of the user on the secondary block chain granted by the administrator of the secondary block chain; authentication of the user by means of the secondary address following a connection request to the secondary blockchain.
  • Such a method allows a user to connect to at least one secondary blockchain independently of the blockchain while allowing centralized management and supervision of connections. to the various secondary block chains.
  • the method according to the first exemplary embodiment comprises receiving a request for recording a transaction sent by the user via a multisigned address generated from the secondary address and a user address of an administrator of the secondary blockchain; a signature of the transaction by the user by means of the signature corresponding to the secondary address.
  • the method according to the first exemplary embodiment comprises a recording, in the main block chain, of a catalog of secondary block chains, the catalog comprising for each secondary block chain a description and a link to a supervision area of the relevant secondary blockchain.
  • the method may include searching for at least one secondary blockchain in the blockchain catalog based on search criteria entered by a user; obtaining, in the supervision zone of the secondary block chain concerned, of connection parameters to the secondary block chain corresponding to the search criteria.
  • the method according to the first exemplary embodiment may comprise a connection of the user to the main blockchain by means of a main address allocated to this user; a read, by means of a primary address, in the user directory of the secondary address of the user and of the multi-signed address; a read, in the main blockchain in the supervision area of the secondary blockchain, of the user rights stored in association with the read multisigned address; receiving a request for access from the user to the secondary blockchain and authenticating the user based on the read secondary address; a user login to the secondary blockchain on successful authentication.
  • the secondary address allocated to a user for connection to the blockchain is stored in the user directory in association with the address multisigned.
  • the rights of a user on the second blockchain are recorded in the supervision area in association with the multi-signed address allocated to this user.
  • a computer device or computer system comprises means for implementing the method according to the first example of achievement.
  • These means may comprise one or more processors and one or more memories comprising computer program code, the memory (s) and the computer program code being configured to, together with the processor (s), cause execution by the processor.
  • device of the steps of the method according to the first exemplary embodiment the memory or memories comprise a computer program comprising instructions configured to cause the device to execute the steps of the method according to the first exemplary embodiment.
  • the various steps of the method according to the first exemplary embodiment are implemented by one or more computer programs.
  • 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 exemplary embodiment when the instructions are implemented by one or more computer programs.
  • a computer program product comprises instructions for executing the steps of a method according to the first exemplary embodiment when the computer program is executed by a data processor.
  • FIGS. 3A and 3B An example of a method of connecting a user to a blockchain is described in detail with reference to FIGS. 3A and 3B. To simplify the description, the example case of connecting to a particular BS26 secondary blockchain (220) is described, but is applicable to any other secondary blockchain (220).
  • the master blockchain corresponds to instances 140, 141, 142 of blockchains, that the administrator of the master corresponds to the user Z0 and that the node of the administrator of the master thus corresponds to the node 100.
  • Step 300 Recording of the catalog in the master
  • the master stores a catalog (240) of secondary blockchains.
  • This catalog (240) includes for each secondary block chain (220) a description and a link to a supervision area (250) of the secondary block chain (220) concerned. The storage of this information can be done as the channels are created. Secondary blockchains and updates on those secondary blockchains.
  • This catalog registration 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 computing device 150 in the instance 140 of the master. Note that at this point, 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, synchronization takes place so as to update the various instances 141 and 142 of the master.
  • Step 305 User connection to the master (200)
  • the user Z1 connects to the master (200) by means of a computer device 151 of the node 101.
  • the user is authenticated on the basis of his master address (173) AM-Z1 which is allocated to him for the 'access to the master and associated authentication data (for example a password or other).
  • This first connection can be made using any known connection procedure.
  • the master address AM-Z1 of the user Z1 is stored, by means of the software associated with the master executed by the computer device 151 of the node 101, in the master niche NM-Z1 (231) of this user. It can be stored in conjunction with user Z1's business card.
  • the secondary address (or technical address) AT-BSX-Y-Z1 of the user Z1 for the block chain secondary (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 .
  • a Z1 user 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
  • this new instance is a full copy of instance 140 of the master of administrator node 100 associated with administrator Z0.
  • Step 310 access to the catalog (240) and search for a chain of blocks
  • the master (200) After connecting the user to the main blockchain, the master (200) presents the catalog (240) of the secondary block chains supervised by the master (200). Following a first authentication, the catalog (240) thus allows the user to know all the managed secondary blockchains.
  • 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 computing device 151 of the node 101 of the user Z1.
  • Step 320 obtaining parameters for connection to the secondary block chain.
  • the catalog (240) being linked to the supervision areas of the secondary block chains, this makes it possible to find the connection parameters present in the supervision area of each secondary block chain (220).
  • the user Z1 obtains from the master, by means of the software associated with the master executed by the computing device 151, parameters for connection to a secondary blockchain BS26 corresponding to the search criteria or to a secondary blockchain.
  • BS26 selected by the user.
  • connection parameters are read in the supervision zone (250) of the secondary block chain BS26 concerned.
  • 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.
  • Step 330 connection to the secondary block chain
  • This step concerns a first connection of the user to the secondary blockchain selected previously, this blockchain being a secondary BS26 blockchain, access to which is supervised via the master.
  • the user sends, by means of a computing device (151), a request for connection to the secondary blockchain BS26 using the connection parameters obtained in step 320.
  • a computing device 151
  • connection is made on the current Y version of the secondary blockchain.
  • BS26-Y will denote the block chain concerned by steps 340 to 380, but these steps are applicable in the same way to an isolated block chain, not forming part of a series.
  • This connection request is made by means of the software associated with the secondary blockchain BS26-Y executed by the computing device 151 of the node 101 of the user Z1.
  • Step 340 Allocation of Technical Address and Multi-signed Address
  • the user obtains in return a user address (173) AT-BS26-Y-Z1 (secondary address, or even technical address), serving as a 'BS26-Y secondary blockchain connection identifier.
  • the user Z1 After registration in the directory and allocation of the address AM-BS26-Y-Z1, the user Z1 also obtains the multi-signed address (180) AM-BS26-Y-Z1 which is allocated to him for the signing transactions to be recorded on behalf of this user in the secondary blockchain BS26-Y.
  • the multi-signed 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.
  • AT-BS26-Y-Z0 or administrator address
  • the secondary address AT-BS26-Y-Z1 (173) and the multi-signed address (180) AM-BS26- Y-Z1 are generated 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 administrator Z0 of the secondary blockchain BS26-Y.
  • the software associated with the secondary block chain BS26-Y, executed by means of the computer device 150 of the administrator node 100 of the secondary block chain 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, d on the other hand, the signature of the technical manager (or administrator) from the address AT-BS26-U-Z0 of the administrator Z0 of the secondary block chain BS26-Y.
  • the multi-signed (180) AM-BS26-Y-Z1 address is determined so that it requires only one of the two possible signatures.
  • Step 350 recording in the directory (230) of the master (200).
  • the multi-signed (180) address 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 registered, in the niche NBS26-Y-Z1 of the secondary blockchain BS26-Y concerned, in association with the technical address AT-BS26-Y-Z1 so that an explicit link exists between the two addresses.
  • the Z1 user has read rights on the master niche NBS26-Y-Z1 of the directory associated with it. After synchronization of the master instances, the Z1 user 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 computer device 151 of the node 101 associated with the user Z1. [0134] Step 360: registration of rights.
  • Rights to the secondary blockchain BS26-Y are assigned 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 performed 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 business address AM-BS26-Y-Z are recorded in the master (200) in the supervision area ZTBS26 of the secondary blockchain BS26-Y.
  • D-BS26-Y-Z1 rights are registered by the administrator of the BS26-Y blockchain in association with the multi-signed address (180) AM-BS26-Y-Z1 in the ZTBS26 supervision zone of the chain of secondary blocks BS26-Y.
  • This recording in the ZTBS26 supervision zone 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 computer device 150 of the administrator node 100 of the block chain BS26-Y secondary, under the control of the Z0 administrator of the BS26-Y secondary blockchain.
  • the other instances 141 and 142 of the master are updated at the level of the associated nodes 101 and 102.
  • the Z1 user 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 D-BS26-Y-Z1 rights 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 connection to the secondary block chain BS26-Y.
  • the user uses the technical address AT-BS26-Y-Z1 to log in and access the secondary BS26-Y blockchain.
  • the user is authenticated on the basis of his user address (173) AT-BS26-Y-Z1 and associated authentication data (eg 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 recording of a transaction in the secondary blockchain BS26-Y.
  • the user sends, by means of his computer device 151, to the secondary block chain BS26-Y a request to record a transaction.
  • This transaction registration request is issued from the multi-signed address AM-BS26-Y-Z1.
  • This request is sent by 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.
  • 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 by means of the signature corresponding to the secondary address AT -BS26-Y-Z1, used for the generation of the multi-signed address AM-BS26-Y-Z1.
  • any transaction between two or more users is performed from one multi-signed address (180) to another multi-signed address (180).
  • transactions can be used to create assets, create units of assets, send units of assets, perform transactions that contain data unrelated to an asset or any other action permitted by BS26-Y secondary blockchain technology subject to the rights granted.
  • one or more data blocks are recorded in the secondary block chain BS26-Y.
  • the secondary blockchain BS26-Y corresponds to instances 130, 131, 132 described with reference to FIG. 1A.
  • This registration is thus carried out in the instance 131 of the secondary block chain BS26-Y, 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 other instances 130 and 132 of the corresponding secondary blockchain BS26-Y are (as needed and full node / thin node mode) updated at the associated nodes 100 and 102.
  • 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 in part in parallel, some of the steps can be omitted or repeated. .
  • the steps of this method relating to a block chain can be carried out by one or more of the physical entities (computers) implementing the functions of this block chain at the level of at least one node. .
  • This migration method is implemented so as to keep only certain information of the migrated secondary block chains, for example the application information. In this way the memory size occupied by the secondary blockchain replacement is reduced compared to the memory size occupied by the replaced blockchain.
  • the master (200) is in a way the conductor of the migration in that he supervises the migration by behaving like a communication hub.
  • the migration of a blockchain 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 on the administrator node Z0.
  • the migration of a blockchain is preferably carried out so as to guarantee continuity of service for the applications (systems / application projects) implemented by this blockchain.
  • a migration start date is calculated by the administrator of the current secondary blockchain (220). This calculation can be done in several ways.
  • 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 allowed migration time is calculated. From the end of migration, the start of the buffer period is also calculated.
  • step 410 on the occurrence of the start of the authorized migration period, the new secondary blockchain BS26-Y is initialized and recorded (connection parameters, migration parameters, description, and other parameters. useful) 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.
  • a supervision zone is created in the main block chain for the new secondary block chain. Either the ZTBS26 supervision area is completed if only one supervision area is used for the blockchain series, 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 ZTBS26-Y supervision zone 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). As described above, this supervision zone is intended to store the associated user rights and the user addresses for connection to the secondary block chain concerned.
  • 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.
  • step 420 after initialization of the new secondary blockchain BS26-Y, the registration period begins and all the users wishing or having to register on the new secondary blockchain BS26-Y are invited to connect to it and to register in the directory (230) of the master (200) their new technical address for this new secondary blockchain 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.
  • the registration 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 secondary block chain BS26-Y via 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 secondary blockchain BS26-Y.
  • 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 channels number of blocks in a time series or one administrator per blockchain version. During the registration period, user rights can be modified or not renewed
  • the rights are assigned to all the business addresses (multi-signed addresses) allocated for the new secondary blockchain BS26-Y.
  • the technical addresses remain without rights, or alternatively with rights to send but without reception rights for all the corresponding users, so that the state of the new secondary blockchain remains frozen until step 450 of failover of users. In particular, no new data block can be generated in the new secondary blockchain.
  • the initialization period begins after allocation of rights to business addresses.
  • the administrator of the new secondary blockchain 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 chain of blocks.
  • the signing of these data blocks is done by the administrator using the secondary blockchain administrator address BS26-Y. This image corresponds to a specific time in the history of the first blockchain.
  • each asset and each asset unit is recreated and the asset units are allocated to user addresses so that the data image of the new secondary blockchain BS26-Y is the same as The data image of the old secondary blockchain BS26- (Y-1) in terms of assets owned by users.
  • the instant at which the image is generated corresponds to the start of the memory period of the old secondary blockchain BS26- (Y-1).
  • operations performed in the past on the old secondary blockchain BS26- (Y-1) during a memory period of the old secondary blockchain BS26- (Y-1) are carried out on the new secondary blockchain BS26-Y so as to reproduce the relevant part of the history of the blockchain BS26- (Y-1).
  • the initial image is generated at the instant 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 secondary blockchain BS26-Y so that, following this reproduction, the state of the new secondary blockchain BS26-Y corresponds to the current state of the 'old blockchain at time T 1. Time T 1 also corresponds to the start of the migration period.
  • the generation of this image is performed 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 BS26-Y secondary blockchain, under the control of the Z0 administrator of the new BS26-Y secondary blockchain. With no user registered, there are no other instances of the new BS26-Y secondary blockchain for which synchronization is required.
  • the so-called mirror period begins, corresponding to step 440.
  • the old secondary blockchain BS26- (Y-1) coexists with the new one.
  • secondary blockchain BS26-Y remains accessible for all operations in accordance with the rights granted.
  • These new transactions are transactions for which a registration request has reached the blockchain to be replaced or the replacement blockchain.
  • the registration of this user can be simulated by creating by assigning it a secondary address and a multi-signed address and the registrations in the new blockchain are required by the administrator of the new blockchain using this user's multi-signed address and signed with this administrator's secondary address.
  • 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 switchover period begins after the start of the mirror period and corresponds to step 450. As illustrated by FIG. 4A, this user switching period can be done at least in part in parallel with the mirror period.
  • the rights are allocated to the addresses techniques and systems / projects using the old secondary blockchain and having rights to the new secondary blockchain are allowed to switch to the new secondary blockchain BS26-Y.
  • 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 blockchain secondary to which a user is connected.
  • a marker indicates whether or not a user has switched to the replacement blockchain.
  • the switching of a user thus corresponds to a switching of rights from this user to the replacement block chain (whether or not these rights are identical on these two block chains).
  • the records of new transactions are reoriented in an appropriate manner.
  • the BS26- (Y-1) blockchain to be replaced then the BS26-Y replacement blockchain is updated with the software associated with BS26-Y, from the user, to keep it like the blockchain to be replaced BS26- (Y-1).
  • the master serves as a communication register in that the master makes it possible to determine to 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 another, each at different times and without constraint.
  • the computation time required to start the new chain is reduced to a minimum.
  • step 460 This step corresponds to the switching between the old BS26- (Y-1) secondary blockchain and the new BS26-Y secondary blockchain.
  • This switch between secondary blockchains is final so that any new transaction is recorded only in the new blockchain so that no more transactions can be recorded in the old BS26- (Y-1) blockchain and any new transaction is recorded only in the new BS26-Y blockchain.
  • the mirror period therefore ends and all rights, except possibly the connection right (set of “Connect” rights described with reference to Fig. 1D), are removed from the user addresses for the old secondary blockchain BS26- ( Y-1). Keeping 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 and find all historical data (rights reading) if necessary.
  • the recording of the restricted rights on the old secondary block chain is carried out in the master in the supervision area of the old block chain in a local instance of the master, by the software associated with the master, executed at means of the computing device 150 of the administrator node 100 of the old secondary blockchain, under the control of the administrator Z0 of the old secondary blockchain.
  • a Z1 user has the option of removing the local instance at his node 101 from older versions of blockchains for which the migration is complete. All information relating to transactions prior to the migration (prior to the migration period) is in fact kept at the level of the BS26 administrator's node without it being necessary to keep at the level of the other nodes.
  • 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 that you can continue to use the functionality associated with this secondary BS26 blockchain.
  • the master has a supervisory role but does not determine how the rights are allocated to the users in the different chains of secondary blocks.
  • the master therefore has a declarative role and storage of information about supervised blockchains.
  • An administrator of a secondary blockchain could not store the rights allocated to users in the master and rely solely on internal management of the secondary blockchain of these rights to determine which rights to apply. .
  • the rights of an administrator on the master could in this case be withdrawn.
  • the master (200) is the entity that manages the migrations of secondary blockchains in the same time series of secondary blockchains.
  • the master (200) is a blockchain just like the secondary blockchains.
  • 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 the secondary blockchains are replaced.
  • 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, that is to say say that 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).
  • the parameters for creating a new master (200) contain, in addition to the creation parameters described for the chains of secondary blocks, a pointer to the previous master (200) which allows users who have had an activity to make better use of the history stored in the previous master (200) if necessary.
  • processors can be ensured by the use of dedicated hardware as well as of hardware capable of executing software in association with appropriate software.
  • functions may be provided by a single dedicated processor, by a single shared processor, or by multiple individual processors, some of which can be shared. Other materials, conventional and / or specific, can also be included.
  • the present 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 one or more method. of the methods described in this document.
  • This computer program can 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 a partially compiled form, or in any other desirable form.
  • the instructions are intended to be stored in a memory of a computing 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.
  • the computing device 150, 151, 152 can be implemented by one or more physically distinct machines.
  • the device can have the overall 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.
  • processor should not be interpreted as referring exclusively to hardware capable of executing software, and may include purely hardware components, a digital signal processor (DSP), a network processor , an application specific integrated circuit (ASIC), a programmable gate network (FPGA), etc.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA programmable gate network
  • the present 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.
  • 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 hard drives or optical readable digital data storage media, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Procédé de migration d'une chaîne de blocs à remplacer, dite première chaîne de blocs, vers une chaîne de blocs de remplacement, dite deuxième chaîne de blocs. Le procédé de migration comprend : une initialisation de la deuxième chaîne de blocs, l'initialisation comprenant une génération, dans une chaîne de blocs principale configurée pour superviser l'accès aux première et deuxième chaînes de blocs, d'une zone de supervision (250) de la deuxième chaîne de blocs; l'inscription d'un utilisateur comprenant un enregistrement dans un annuaire d'utilisateurs dans la chaîne de blocs principale d'une adresse secondaire allouée à cet utilisateur pour la connexion à la deuxième chaîne de blocs; une génération dans la deuxième chaîne de blocs d'un ensemble de blocs de données correspondant à une image de la première chaîne de blocs; un basculement de tout ou partie des utilisateurs de la première chaîne de blocs vers la deuxième chaîne de blocs de sorte à interdire l'enregistrement de transactions au nom de ces utilisateurs dans la première chaîne de blocs et autoriser l'enregistrement de transactions au nom de ces utilisateurs dans la deuxième chaîne de blocs.

Description

migration d’une chaîne de blocs de données
[0001] [DOMAINE DE L’INVENTION
[0002] L’invention concerne le domaine des chaînes de blocs et plus particulièrement une technique de migration de chaîne(s) de blocs.
[0003] ETAT DE LA TECHNIQUE
[0004] La technologie d’enregistrement de données au moyen de chaînes de blocs (technique plus connue sous l’appellation anglo-saxonne « blockchain ») est une technologie qui appuie la confiance que l’on peut avoir sur les données enregistrées sur l’historique des données. A priori, on ne peut supprimer aucune donnée stockée dans une chaîne de blocs. Par conséquence, une chaîne de blocs ne fait qu’augmenter en taille de stockage. Or les systèmes ont, généralement, une capacité limitée de stockage qui ne peut donc pas faire face à la croissance potentiellement infinie d’une chaîne de blocs.
[0005] Une chaîne de blocs indexe les données jugées importantes. Chaque bloc, chaque transaction, chaque adresse, par exemple, est une clé indexée pour un accès rapide aux données. Par contre, plus un index contient de clés plus ses performances sont réduites. Comme une chaîne de blocs ne fait qu’augmenter en taille de stockage, plus elle est utilisée, plus cette chaîne de blocs stocke des données obsolètes, plus ses performances se réduisent.
[0006] Il apparaît ainsi un besoin de remédier à tout ou partie des problèmes, inconvénients ou insuffisances de l'état de la technique et/ou d'y apporter des améliorations.
[0007] RESUME
[0008] Selon un premier aspect, la présente description concerne un procédé de migration d’une chaîne de blocs à remplacer, dite première chaîne de blocs, vers une chaîne de blocs de remplacement, dite deuxième chaîne de blocs, le procédé étant mis en œuvre par un ou plusieurs ordinateurs. Le procédé de migration comprend : une initialisation de la deuxième chaîne de blocs, l’initialisation comprenant une génération, dans une chaîne de blocs principale configurée pour superviser l’accès aux première et deuxième chaînes de blocs, d’une zone de supervision de la deuxième chaîne de blocs; une inscription d’un ou plusieurs utilisateurs auprès de la deuxième chaîne de blocs, l’inscription d’un utilisateur comprenant un enregistrement dans un annuaire d’utilisateurs dans la chaîne de blocs principale d’une adresse secondaire allouée à cet utilisateur pour la connexion à la deuxième chaîne de blocs; une génération dans la deuxième chaîne de blocs d’un ensemble de blocs de données correspondant à une image de la première chaîne de blocs, l’image correspondant à un instant déterminé dans l'historique de la première chaîne de blocs ; un basculement de tout ou partie des utilisateurs de la première chaîne de blocs vers la deuxième chaîne de blocs de sorte à interdire l’enregistrement de transactions au nom de ces utilisateurs dans la première chaîne de blocs et autoriser l’enregistrement de transactions au nom de ces utilisateurs dans la deuxième chaîne de blocs.
[0009] Dans un ou plusieurs modes de réalisation, le procédé selon le premier aspect comprend un enregistrement de nouvelles transactions pour lesquelles une requête d’enregistrement est parvenue auprès de la première chaîne de blocs à la fois dans la première chaîne de blocs et dans la deuxième chaîne de blocs pendant une période, dite période miroir, avant l’étape de basculement. Ceci permet d’éviter un basculement brutal d’une chaîne de bloc à une autre et de prévoir une période pendant laquelle les utilisateurs vont pouvoir individuellement, chacun selon son besoin, passer de la première chaîne de blocs vers la deuxième chaîne de blocs.
[0010] Dans un ou plusieurs modes de réalisation, le procédé selon le premier aspect comprend un basculement définitif vers la deuxième chaîne de blocs par modification des droits des utilisateurs sur la première chaîne de blocs, de sorte que plus aucune transaction ne peut être enregistrée dans la première chaîne de blocs et toute nouvelle transaction est enregistrée uniquement dans la deuxième chaîne de blocs.
[0011] Dans un ou plusieurs modes de réalisation, le procédé selon le premier aspect la zone de supervision de la deuxième chaîne de blocs configurée pour stocker des droits utilisateurs sur la deuxième chaîne de blocs.
[0012] Dans un ou plusieurs modes de réalisation du procédé selon le premier aspect, la première chaîne de blocs est mise en œuvre dans un système de communication comprenant une pluralité de nœuds et une instance de la première chaîne au niveau de chaque nœud, le procédé comprenant, pour au moins un nœud du système de communication, suite au basculement définitif, une suppression de l’instance de la première chaîne de blocs localisée au niveau du nœud considéré.
[0013] Dans un ou plusieurs modes de réalisation, le procédé selon le premier aspect comprend une allocation à chaque utilisateur de la deuxième chaîne de blocs d’une adresse multisignée pour la signature de transactions à enregistrer dans la deuxième chaîne de blocs au nom de cet utilisateur, l’adresse multisignée étant générée à partir de l’adresse secondaire allouée à cet utilisateur pour la connexion à la deuxième chaîne de blocs et d’une adresse administrateur de la deuxième chaîne de blocs.
[0014] Dans un ou plusieurs modes de réalisation du procédé selon le premier aspect, l’adresse secondaire allouée à un utilisateur pour la connexion à la deuxième chaîne de blocs est stockée dans l’annuaire d’utilisateurs en association avec l’adresse multisignée. [0015] Dans un ou plusieurs modes de réalisation du procédé selon le premier aspect, l’adresse multisignée est utilisée pour enregistrer les nouvelles transactions dans la deuxième chaîne de blocs pendant la période miroir.
[0016] Dans un ou plusieurs modes de réalisation du procédé selon le premier aspect, les droits d’un utilisateur sur la deuxième chaîne de blocs sont enregistrés dans la zone de supervision en association avec l’adresse multisignée allouée à cet utilisateur.
[0017] Dans un ou plusieurs modes de réalisation du procédé selon le premier aspect, la génération de l’image de la première chaîne de blocs comprend un enregistrement dans la deuxième chaîne de blocs d’un ensemble de blocs de données représentatifs d’unités d’actifs détenus par un ou plusieurs utilisateurs de la première chaîne de blocs à l’instant déterminé.
[0018] Dans un ou plusieurs modes de réalisation, le procédé selon le premier aspect comprend un enregistrement dans la chaîne de blocs principale d’un marqueur pour chaque utilisateur indiquant si cet utilisateur a basculé ou non vers la deuxième chaîne de blocs. [0019] Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre du procédé selon le premier aspect.
[0020] Selon un deuxième aspect, la présente description concerne un dispositif informatique ou système informatique comprenant des moyens de mise en œuvre du procédé selon le premier aspect. Ces moyens peuvent comprendre un ou plusieurs processeurs et une ou plusieurs mémoires comprenant un code de programme d'ordinateur, la ou les mémoires et le code de programme d'ordinateur étant configurés pour, avec le ou les processeurs, causer l’exécution par le dispositif des étapes du procédé selon le premier aspect. Par exemple, la ou les mémoires comprennent un programme d’ordinateur comprenant des instructions configurées pour causer l’exécution par le dispositif des étapes du procédé selon le premier aspect.
[0021] Dans un ou plusieurs modes de réalisation, les différentes étapes du procédé selon le premier aspect sont mises en œuvre par un ou plusieurs programmes d'ordinateur.
[0022] Selon un troisième aspect, la présente description concerne ainsi un support de stockage de données lisible par un processeur sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l'exécution des étapes d’un procédé selon le premier aspect sont mises en œuvre par un ou plusieurs programmes d'ordinateur.
[0023] Selon un quatrième aspect, la présente description concerne ainsi un produit programme d’ordinateur comprenant des instructions pour l’exécution des étapes d’un procédé selon le premier aspect lorsque le programme d’ordinateur est exécuté par un processeur de données.
[0024] BREVE DESCRIPTION DES FIGURES
[0025] D'autres buts, caractéristiques et avantages de l'invention apparaîtront à travers la description qui va suivre, donnée uniquement à titre d'exemple non limitatif, et faite par référence aux dessins annexés dans lesquels:
[Fig. 1A] représente de manière schématique un système de communication comprenant des chaînes de blocs;
[Fig. 1B] illustre de manière schématique des aspects d’un nœud d’un système de communication selon la Fig. 1A ;
[Fig. 1C] illustre des aspects de la génération d’une adresse utilisateur ;
[Fig. 1D] illustre des aspects de la génération d’une adresse multisignée ;
[Fig. 2A] représente de manière schématique les relations entre une chaîne de blocs principale et des chaînes de bloc secondaires ;
[Fig. 2B] représente de manière schématique les relations entre une chaîne de blocs principale et des chaînes de bloc secondaires pour la gestion des droits et adresses d’un utilisateur ;
[Fig. 3A] illustre de manière schématique des aspects d’un procédé de connexion d’un utilisateur à une chaîne de blocs secondaire ;
[Fig. 3B] représente un organigramme d’un procédé de connexion d’un utilisateur à une chaîne de blocs secondaire selon un ou plusieurs modes de réalisation selon un ou plusieurs modes de réalisation ;
[Fig. 4A] illustre de manière schématique des aspects d’un procédé de migration d’une chaîne de blocs secondaire à remplacer vers une chaîne de blocs secondaire de remplacement ;
[Fig. 4B] représente un organigramme d’un procédé de migration d’une chaîne de blocs secondaire à remplacer vers une chaîne de blocs secondaire de remplacement selon un ou plusieurs modes de réalisation.
[0026] DESCRIPTION DETAILLEE
[0027] De manière connue, les chaînes de blocs peuvent être utilisées pour enregistrer n'importe quel type de transactions. En arrière-plan, une chaîne de blocs est généralement définie comme étant un registre informatisé de transactions. La chaîne de blocs (ce registre informatisé) "s'agrandit" au fur et à mesure que des blocs de données y sont enregistrés, ces blocs de données correspondant à de nouvelles transactions ou à des ensembles de nouvelles transactions qui sont ajoutés à la chaîne de blocs. Les nouveaux blocs de données correspondant aux nouvelles transactions sont enregistrés dans la chaîne de blocs après un processus de validation qui est propre à chaque chaîne de bloc.
[0028] Le terme "transaction" peut couvrir tout type d’opération entre un ou plusieurs acteurs. Elle peut être relative à tout type de produit ou matériel, composant de dispositif, emballage et/ou document ou fichier physique ou électronique, y compris des actifs virtuels tels que des données, des fichiers électroniques, des actifs incorporels ou même de la crypto-monnaie. La technologie dite de "chaîne de blocs" permet la création d'un registre informatisé d'opérations, non répudiable, résistant à la falsification.
[0029] La Fig. 1A représente de manière schématique un système de communication 1000 pour la mise en œuvre de chaînes de blocs, dans le cas d’une architecture décentralisée.
Ce système de communication 1000 comprend plusieurs nœuds 100, 101, 102 communiquant entre eux au travers d’un réseau de communication 110. Ces nœuds sont généralement organisés en réseau de pairs. Cette figure présente un exemple de réseau illustrant le caractère « décentralisé » de la chaîne de blocs et les relations entre nœuds du réseau (réseau pair à pair). Cette figure illustre de manière schématique une architecture possible d’un réseau d’exploitation et/ou utilisation d’une ou plusieurs chaînes de blocs. Une autre architecture ou infrastructure pourrait être choisie.
[0030] Chaque nœud 100, 101, 102 du système de communication 1000 peut correspondre à un ou plusieurs dispositifs informatiques physiquement distincts, mettant en œuvre un logiciel correspondant à une ou plusieurs applications logicielles. Ce logiciel met en œuvre, au niveau du nœud considéré, les fonctionnalités d’une chaîne de blocs et accède à un ou plusieurs jeux de données pour le stockage des blocs de données de la chaîne de bloc considérée.
[0031] Pour chaque nœud 100, 101, 102 du système de communication 1000, les blocs de données peuvent être stockés de manière répartie (dans ce cas, on parle de registre distribué, ou « distributed ledger » selon la terminologie anglo-saxonne), par exemple sur un ou plusieurs sous-nœuds d’un réseau local au niveau du nœud considéré.
[0032] De manière simplifiée et à titre d’exemple, dans le cas de la Fig. 1A, le nœud 100 comprend un dispositif informatique 150, mettant en œuvre les fonctionnalités de deux chaînes de blocs 130, 140 et accédant à deux jeux de données 130, 140, qui correspondent respectivement à ces deux chaînes de blocs 130, 140. De même, le nœud 101 comprend un dispositif informatique 151, mettant en œuvre les fonctionnalités de deux chaînes de blocs 131, 141 et accédant à deux jeux de données 131, 141, qui correspondent respectivement à ces deux chaînes de blocs 131, 141. De même, le nœud 102 comprend un dispositif informatique 152, mettant en œuvre les fonctionnalités de deux chaînes de blocs 132, 142 et accédant à deux jeux de données 132, 142, qui correspondent respectivement à ces deux chaînes de blocs 132, 142.
[0033] Chaque dispositif informatique 150, 151, 152 peut être mis en œuvre par une ou plusieurs machines physiquement distinctes. Le dispositif informatique 150 peut présenter globalement l’architecture d’un ordinateur, incluant des composants d’une telle architecture: mémoire(s) de données, processeur(s), bus de communication, interface(s) matérielle(s) pour la connexion de ce dispositif à un réseau ou un autre équipement, interface(s) utilisateur, etc.
[0034] Chaque dispositif informatique 150, 151 , 152 est configuré pour communiquer via le réseau de communication 110 avec les autres nœuds 100, 101 , 102 du système de communication et met en œuvre tout ou partie des fonctions d’une ou de plusieurs chaînes de blocs associées 130, 131, 132 et/ou 140, 141, 142.
[0035] Dans le cas d’une chaîne de blocs permissionnée (avec gestion de droits), chaque dispositif informatique 150, 151 , 152 met en œuvre des fonctions d’inscription d’utilisateurs, d’allocation de droits sur la chaîne de blocs, d’allocation d’adresses utilisateurs, de contrôle d’accès à la chaîne de blocs, de signature et d’enregistrement de transactions, de lecture et écriture de jeux de données ou blocs de données, etc, selon ce qui est décrit dans ce document pour la chaîne de blocs concernée.
[0036] Un nœud 100, 101 , 102 peut être un nœud complet ou un nœud léger pour une chaîne de blocs donnée. Si le nœud 100, 101 , 102 est un nœud complet, le nœud stocke localement (dans un des jeux de données locales) tous les blocs de données de la chaîne de blocs: les blocs de données sont dans ce cas dupliqués autant de fois qu’il y a de nœuds. [0037] Dans l’exemple de la Fig. 1A, si on suppose que la chaîne de bloc 130 (respectivement 140) est initialement crée par un administrateur Z0 au moyen du dispositif informatique 150, alors chacune des chaînes de blocs 131 et 132 (respectivement 141 et 142) sont une instance de cette même chaîne de blocs 130 (respectivement 140). Si le nœud 100, 101 , 102 est un nœud léger, le nœud stocke localement uniquement les blocs de données de l’utilisateur Z0, Z1 , ou Z2 de ce nœud. L’invention décrite dans ce document est applicable quel que soit le type de nœud.
[0038] Si par exemple un utilisateur Z1 du nœud 101 souhaite se connecter à une chaîne de blocs 130, il va établir, au moyen d’un dispositif informatique 151 , une connexion via un réseau de télécommunication au dispositif informatique 150 correspondant à un administrateur Z0 de la chaîne de blocs visée. Si le nœud 101 est un nœud complet, une copie intégrale de la chaîne de blocs 130 sera créée au niveau du nœud 101 après la première connexion et après que les droits aient été donnés à cet utilisateur Z1 sur la chaîne de blocs 130. Chaque nouvel utilisateur suivant Z2, Z3 etc pourra se connecter à l’un quelconque des nœuds 100 ou 101 déjà créés.
[0039] La Fig. 1 B illustre de manière schématique le principe de mise à jour des chaînes de blocs dans le cas d’exemple d’une chaîne de blocs 141 et d’un nœud 101. Cette figure illustre de manière schématique une architecture possible d’un système informatique pour l’exploitation et/ou d’utilisation d’une chaîne de blocs. La Fig. 1 B représente un exemple de nœud local servant à illustrer le caractère « autonome » de la chaîne de blocs où les données sont stockées localement pour chaque nœud et mises à jour par le réseau et nécessitent une « interface » pour être utilisées par le nœud local. Une autre architecture ou structure physique / matérielle pourrait être envisagée.
[0040] On suppose ici que les chaînes de blocs 140, 141, et 142 sont des instances d’une même la chaîne de blocs 141. Pour une chaîne de blocs donnée, chaque nœud 101 (respectivement 100, 102) comprend un logiciel 161 (respectivement 160, 162) mettant en œuvre toutes les fonctions associées à la chaîne de blocs considérée. Ce logiciel 161 (respectivement 160, 162) peut comprendre au moins un premier sous-ensemble logiciel 161 A (respectivement 160A, 162A) configuré pour effectuer les opérations d’écriture et de lecture de blocs de données ainsi que les opérations de synchronisation avec les autres instances de la chaîne de blocs sur les autres nœuds. Selon ce qui est demandé par l’utilisateur du nœud 101, le sous-ensemble logiciel 161A met à jour localement l’instance 141 de la chaîne de blocs considérée par enregistrement d’un ou plusieurs nouveaux blocs de données. De manière connue, par un mécanisme de synchronisation mis en œuvre au travers du réseau de communication 110 reliant les différents nœuds 100, 101, 102, les autres instances 140 et 142 de cette chaîne de blocs sont mises à jour par enregistrement de ces nouveaux blocs de données au niveau des autres nœuds 100 et 102 gérant respectivement ces autres instances 140 et 142 de la chaîne de blocs. Dans le cas de nœuds légers, cette mise à jour peut se limiter aux seuls blocs de données concernés. Le logiciel 161 peut en outre comprendre au moins un deuxième sous-ensemble logiciel 161 B (respectivement 160B, 162B), s’appuyant sur le premier sous-ensemble logiciel 161A et configuré pour mettre en œuvre les différentes fonctionnalités décrites dans ce document.
Le logiciel 161 (respectivement 160, 162) peut en outre comprendre au moins un troisième sous-ensemble logiciel 161C (non représenté) s’appuyant sur les premier et deuxième sous- ensembles logiciels 161A et 161 B et configuré pour mettre en œuvre les fonctionnalités d’interface utilisateur.
[0041] Le logiciel d’une chaîne de blocs peut correspondre à une ou plusieurs applications logicielles et un ou plusieurs dispositifs informatiques. Chaque sous-ensemble logiciel du logiciel d’une chaîne de blocs peut correspondre par exemple, selon l’architecture logicielle choisie, à une application logicielle autonome au sein du logiciel, ou bien une couche applicative au sein du logiciel ou bien encore à un ou plusieurs composants logiciels au sein du logiciel. Toute autre architecture est envisageable. Chaque opération effectuée sur une chaîne de blocs donnée est effectuée au moyen du logiciel associée à cette chaîne de blocs, exécuté par le dispositif informatique d’un des nœuds. Par exemple, les opérations effectuées par un utilisateur Z1 sur une chaîne de bloc donnée seront effectuées au moyen du logiciel 161 associé à la chaîne de bloc considérée, exécutée par le dispositif informatique 151 du nœud 101 associé à l’utilisateur Z1. [0042] De la même façon, les chaînes de blocs 130, 131, et 132 peuvent être des instances d’une même chaîne de blocs et un mécanisme de synchronisation est alors mis en œuvre pour ces instances 130, 131, 132 au travers du réseau de communication 110 reliant les différents nœuds 100, 101, 102.
[0043] . Chaque bloc de données stocké dans une chaîne de blocs 130, 131, 132 ou 140, 141, 142 peut être accédé par un ou plusieurs utilisateurs selon les droits de ces utilisateurs Z0, Z1 , Z2 sur ce bloc de données.
[0044] La confiance des chaînes de blocs est, notamment, basée sur la responsabilisation de chaque utilisateur qui devient complètement acteur dans sa propre gestion de données. Un utilisateur peut donc avoir la possibilité de créer des jeux de données, si c’est le cas alors il est le propriétaire légitime du jeu de données, personne d’autre que lui ne peut créer de nouvelles données au sein de ce jeu de données. De plus chacun possède sur sa propre adresse, qui n’est accessible par aucun autre acteur, les données qu’il a pu recevoir. Il est donc, a priori, impossible de réaliser une action à la place de quelqu’un d’autre tout en le laissant autonome sur les actions similaires quel que soit le niveau de droit de celui qui réalise l’action.
[0045] Les droits des utilisateurs sur une chaîne de blocs sont définis pour les différentes adresses utilisateurs de la chaîne de blocs permissionnée. Une adresse utilisateur (173) correspond à un identifiant personnel sur la chaîne de blocs (comme pourrait l’être une adresse mail sur serveur de mail).
[0046] La Fig. 1C illustre le principe de génération d’une adresse utilisateur (173) pour une chaîne de blocs. L’adresse utilisateur (173) d’une entité utilisatrice (ou utilisateur) de la chaîne de blocs peut être vue comme l’identifiant (unique) de cette entité. Cette adresse utilisateur (173) est généralement, dans le cas d’un chiffrement asymétrique, générée à partir d’une clé publique (172) de signature (et donc de la clé privée (171) puisque la clé publique (172) est en général calculée à partir de la clé privée (171)). Une adresse utilisateur (173) peut être utilisée par une entité utilisatrice telle que : une personne physique, un script ou tout système, autonome ou non, pouvant se connecter à une chaîne de blocs.
[0047] La Fig. 1C illustre notamment la dépendance entre la clé privée (171), la clé publique (172) et la signature associée. La clé privée (171) est par exemple générée aléatoirement, puis par un premier algorithme (par exemple ECDSA, Elliptic Curve Digital Signature Algorithm) la clé publique (172) est générée à partir de la clé privée (171), puis par un deuxième algorithme (par exemple une fonction de hachage ou « hash » selon la terminologie anglo-saxonne) l’adresse utilisateur est générée à partir de la clé publique (172). [0048] D’une manière générale, un utilisateur de chaîne de blocs peut gérer plusieurs adresses utilisateurs, ces adresses utilisateurs sont conservées dans un portefeuille ou “wallet”.
[0049] Pour une chaîne de blocs, il est possible de distinguer différentes catégories d’actifs (ou classes d’objet). Dans la terminologie anglo-saxonne, on parle d’ « assets », que l’on traduit ici par « actifs ». Par exemple, le terme « Bitcoin » désigne usuellement une chaîne de blocs qui ne contient qu’une seule catégorie d’actifs du même nom: le Bitcoin. Les systèmes de chaînes de blocs plus récents permettent de créer différentes catégories d’actifs selon les besoins des utilisateurs. La classe d’objet est généralement la propriété d’une seule adresse utilisateur appartenant à l’utilisateur créateur de cette classe d’objet et dans ce cas seul cet utilisateur est en mesure de générer de nouvelles unités d’actif pour cet actif. Dans le cas de la chaîne de blocs Bitcoin, chaque utilisateur est propriétaire de l’actif Bitcoin.
[0050] Les unités d’actif sont les unités utilisées pour quantifier chaque actif d’une catégorie d’actifs. Par exemple si un actif correspond à une catégorie « Pomme », l’unité d’actif correspond à une « pomme ». Les unités d’actif sont détenues par des adresses qui ont reçues ces unités d’actifs, par exemple suite à des transactions réalisées par la chaîne de blocs. Une instance d’une classe d’objet, indiquant un nombre d’unités d’un actif d’une catégorie donnée, est la propriété d’une seule et même adresse utilisateur (173), c’est-à-dire est la propriété d’un seul utilisateur auquel est affectée cette adresse utilisateur (173). Seul un utilisateur propriétaire d’unités d’actifs est en mesure de transmettre ou de faire des opérations sur des unités d’actifs dont il est propriétaire. .
[0051] Les processeurs de chaîne de blocs sont les processus qui passent les transactions du statut « non confirmé » au statut « confirmé », les mineurs par exemple dans le cas d’une chaîne de blocs avec preuve de travail. Par définition, les processeurs ne peuvent accepter, à confirmation, que les transactions techniquement complètes et valides. Une transaction partielle ne peut pas être acceptée par les processeurs et ne peut donc pas être stockée, en tant que transaction, dans une chaîne de blocs.
[0052] Les permissions (ou droits utilisateurs) définissent les droits d’une adresse utilisateur (173) sur une chaîne de blocs permissionée. Ce sont les permissions qui indiquent si l’adresse est en mesure de se connecter à la chaîne de blocs, si elle peut envoyer et/ou recevoir des transactions, si elle a la possibilité de créer des actifs. La présente description vise aussi bien des systèmes permissionés, que des systèmes dit non-permissionés, c’est- à-dire sans la moindre restriction de droits pour tout utilisateur présent ou à venir.
[0053] Des exemples de droits pouvant être accordés à une ou des adresses utilisateurs de la chaîne de blocs sont illustrés schématiquement par la Fig. 1D et peuvent comprendre: 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. 1 D) ;
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. 1 D);
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). [0054] La Fig. 1D illustre en outre le principe de génération d’une adresse multisignée (180, 190) pour une pluralité d’utilisateurs d’une chaîne de blocs. Une adresse multisignée (180, 190) peut être utilisée pour signer des transactions dans une chaîne de blocs. Une adresse multisignée (180, 190) peut prendre différentes formes selon la chaîne de blocs concernée. Une adresse multisignée (180, 190) est une adresse dont l’utilisation est réservée à un nombre prédéfini de signataires (ou utilisateurs) autorisés. Une adresse multisignée (180, 190) est générée à partir des signatures des signataires autorisés. Une adresse multisignée (180, 190) est définie par le nombre de signatures requises pour confirmer une transaction au moyen de cette adresse multisignée (180, 190) et la liste des utilisateurs associés autorisés (ou signataires) associés à ces signatures. Une adresse multisignée (180, 190) est une adresse utilisée pour une transaction qui peut être signée par P clé(s) publique(s) de signature différentes associées aux signataires autorisés et qui doit être signée par au moins S clé(s) publique(s) de signature associées aux signataires autorisés, avec S <= P. Ainsi, une adresse multisignée (180, 190) est notée avec (S x P) pour informer du nombre (S) de signatures nécessaires parmi les (P) clés publiques possibles. [0055] Par exemple, si deux signataires Alice et Bob ont le droit de signature sur une adresse multisignée (180), alors le nombre de signatures requises pour une transaction impliquant ces deux signataires est au minimum de 1 (adresse multisignée 180) et au maximum de 2 (adresse multisignée 190). Si le nombre de signatures requises est 1, alors toute transaction créée avec l’adresse multisignée (180) pourra être confirmée si elle ne possède qu’une seule signature. Si le nombre de signatures requises est 2, alors toute transaction créée avec l’adresse multisignée (180) nécessitera 2 signatures (une signature par signataire) pour pouvoir être confirmée. Toute transaction effectuée avec une adresse multisignée (180) porte distinctement la signature de l’adresse d’origine de la signature. Par exemple, si Alice et Bob possèdent chacun une adresse, une adresse multisignée (180) peut être générée et si cette adresse multisignée (180) ne nécessite que la signature d’Alice ou de Bob, alors pour toute transaction issue de l’adresse multisignée (180) et ne portant qu’une seule signature, tout utilisateur pouvant consulter la transaction pourra déterminer si la transaction a été signée par Alice ou par Bob.
[0056] Selon ce qui est représenté sur la Fig. 1D :
- les droits alloués à Alice sont les droits « Miner », « Origin node » pour une première adresse et « Send » et « Receive » pour une deuxième adresse ;
- les droits alloués à Bob sont les droits « Send », « Issue » et « Receive » pour une première adresse, les droits « Send » et « Receive » pour une deuxième adresse ;
- les droits associés à l’adresse multisignée peuvent être affectés selon besoin ; dans l’exemple de la figure 1D, les droits associés correspondent aux droits nommés « Send » et « Receive » .
[0057] Chaîne de bloc principale et chaîne de blocs secondaires [0058] Dans le cadre de la présente description, on utilise la notion de chaîne de blocs principale (appelée également chaîne de blocs master ou, plus simplement, master) et de chaînes de blocs secondaires. Le master est la chaîne de blocs principale qui a une fonction de supervision sur les chaînes de blocs secondaires. Le master stocke notamment les informations techniques de supervision permettant la supervision des chaînes de blocs secondaires, par exemple: adresses utilisateurs, droits associés aux utilisateurs, paramètres de connexion, etc....
[0059] Les chaînes de blocs secondaires sont des chaînes de blocs qui stockent les informations applicatives, par exemple les informations nécessaires aux systèmes/projets/applications associés respectivement à chacune de ces chaînes de blocs secondaires. Ces chaînes de blocs secondaires ne contiennent donc, généralement, aucune information technique de supervision contrairement au master.
[0060] Pour toutes les situations où des systèmes ne peuvent pas supporter une chaîne de blocs dont la taille augmente infiniment, la présente description propose un procédé de migration de chaînes de blocs. Ce procédé de migration est appliqué à des chaînes de blocs secondaires supervisées par une chaîne de blocs maître ou master.
[0061] Lors d’un tel procédé de migration, une chaîne de blocs secondaire est remplacée par une deuxième chaîne de blocs secondaire. Le procédé de migration peut ultérieurement être appliqué à cette deuxième chaîne de blocs secondaire de sorte que cette deuxième chaîne de blocs secondaire est elle-même remplacée par une troisième chaîne de blocs secondaire et ainsi de suite. Une chaîne de blocs secondaire succède ainsi à une chaîne de blocs secondaire précédente et les chaînes de blocs forment ainsi une succession temporelle (ou série temporelle) de chaînes de blocs secondaires. Une série temporelle de chaînes de blocs est par exemple notée BS26, et deux chaînes de blocs successives d’index 41 et 42 dans la série temporelle BS26 seront notées par exemple BS26-41 et BS26-42. L’index de la chaîne de blocs commence par exemple à 1 (BS26-1) pour la chaîne de blocs initiale et n’a pas, a priori, de limite. Pour la série temporelle de chaînes de blocs BS26, nous noterons BS26-Y une chaîne de blocs secondaire (220) d’index Y quelconque et BS26-(Y-1) la chaîne de blocs secondaire (220) précédente dans la série temporelle et BS26-(Y+1) la chaîne de blocs secondaire (220) suivante dans la série temporelle. L’index Y correspond ainsi à un numéro de version de la chaîne de blocs BS26-Y.
[0062] Des données techniques de supervision sont stockées par le master (200) pour chaque chaîne de blocs secondaire (220) supervisée par le master (200). Les données techniques de supervision comprennent des paramètres de création d’une chaîne de blocs secondaire (220) et des paramètres de migration.
[0063] Les paramètres de création d’une chaîne de blocs secondaire (220) sont un ensemble de paramètres qui définissent des critères de créations des chaînes de blocs ou série temporelle de chaînes de blocs et des paramètres de migration de chaînes de blocs au sein d’une série temporelle. Ces paramètres de création peuvent être modifiés au cours du temps mais sont, par nature, définis pour une durée relativement longue, au moins pour la durée d’utilisation d’une chaîne de blocs d’une série temporelle.
[0064] Les paramètres de création d’une chaîne de blocs peuvent comprendre : une description de la chaîne de blocs et/ou une taille maximum et/ou une taille minimum et/ou une taille de déclenchement de migration et/ou une fréquence de migration et/ou une plage temporelle de basculement et/ou une fin de migration. Les paramètres tels que taille maximum et/ou taille minimum et/ou taille de déclenchement de migration et/ou fréquence de migration et/ou plage temporelle de basculement et/ou fin de migration servent de paramètres de migration. Ces paramètres de création sont décrits plus en détail ci-dessous. [0065] Les paramètres tels que taille maximum et/ou une taille minimum et/ou une taille de déclenchement de migration et/ou une fréquence de migration et/ou une plage temporelle de basculement et/ou une fin de migration sont des paramètres de migration. Les paramètres de migration servent à déterminer quand une chaîne de blocs secondaire doit être migrée et la durée de cette opération de migration de sorte à pouvoir en déduire une date de début de migration à laquelle le processus de migration doit être déclenché.
[0066] La description d’une chaîne de blocs peut comprendre une description générale valable pour toute la série temporelle, par exemple comprenant des informations spécifiques à la série temporelle de chaînes de blocs concernée et/ou une description spécifique à une chaîne de blocs spécifiques d’une série temporelle. L’ensemble des informations contenues dans la description sont suffisamment exhaustives ou explicites pour permettre à un utilisateur de savoir s’il est intéressé par cette série temporelle ou une chaîne de blocs en particulier.
[0067] La taille maximum d’une chaîne de blocs est la taille maximum allouée à cette chaîne de blocs avant que cette chaîne de blocs ne soit remplacée par une autre chaîne de blocs. [0068] La taille minimum d’une chaîne de blocs est la taille minimum allouée à cette chaîne de blocs avant que cette chaîne de blocs ne soit remplacée par une autre chaîne de blocs. [0069] La taille de déclenchement de migration d’une chaîne de blocs est la taille souhaitée pour cette chaîne de blocs pour déclencher le remplacement de cette chaîne de blocs. Si le système suit une évolution proche d’une évolution linéaire alors un système de prédiction peut être mis en place pour déterminer, en avance, le moment où cette taille sera atteinte.
La taille de déclenchement de migration est supérieure ou égale à la taille minimum et elle est inférieure ou égale à la taille maximum. Une fréquence de migration, exprimée en unité de temps, peut également être utilisée au lieu de la taille de déclenchement de migration pour fixer la durée au bout de laquelle la chaîne de blocs doit être remplacée.
[0070] La taille de déclenchement de migration peut être spécifiée sous la forme d’un intervalle afin de ne pas imposer un changement à un moment qui ne convient pas aux systèmes/projets applicatifs. La plage temporelle de basculement permet de spécifier une ou des plages temporelles où le remplacement de la chaîne de blocs sera le mieux accepté par les systèmes/projets applicatifs.
[0071] En fin de plage temporelle de basculement, la chaîne de blocs amenée à être remplacée est arrêtée et seule la chaîne de blocs de remplacement est conservée. La fin de migration est donc calculée comme le moment où les critères de taille et de plage temporelle de basculement sont remplis, et au plus tard quand la taille maximale est atteinte.
[0072] Lorsqu’une chaîne de blocs BSX-Y vient prendre la suite d’une autre BSX-(Y-1), c’est-à-dire que la chaîne de blocs BSX-Y contient l’information à jour pour la continuité normale du système/projet applicatif, il peut être nécessaire de ne pas se limiter à la seule information immédiate, c’est-à-dire à une photographie des données au moment du début de migration, mais d’inclure les données sur une période passée précédent le début de migration. Cette période passée est appelée période mémoire ou période de rémanence.
Elle peut être déterminée de sorte à contenir des informations du passé nécessaire à la bonne prise en compte de la chaîne de blocs BSX-Y par les systèmes/projets applicatifs. [0073] Lorsqu’une chaîne de blocs BSX-Y vient remplacer une autre chaîne de blocs BSX- (Y-1), dans la majorité des cas, la chaîne de blocs BSX-(Y-1) ne peut pas être arrêtée (c’est- à-dire mise hors service et hors connexion) avant que la chaîne de blocs BSX-Y ne soit complètement fonctionnelle. Il est ainsi nécessaire d’attendre que tous les systèmes/projets applicatifs aient migré de BSX-(Y-1) à BSX-Y. La durée autorisée pour cette migration est définie comme la durée autorisée de migration. La durée autorisée de migration d’une chaîne de blocs est antérieure à la date de basculement vers la nouvelle chaîne de blocs BSX-Y et peut être le résultat d’un calcul prédictif. Le résultat du calcul prédictif sera d’autant plus cohérent que l’évolution de la taille de la chaîne de blocs peut être prédite (évolution régulière, au mieux linéaire).
Zones de supervision
[0074] Le master (200) comprend, pour chaque chaîne de blocs sous la supervision du master (200) une zone de stockage de données de supervision, appelée ici aussi zone technique ou zone de supervision (250), accessible, en lecture seulement, par les utilisateurs de la chaîne de blocs concernée. Cette zone de supervision (250) permet de stocker et d’échanger toutes les informations nécessaires à la connexion à la chaîne de blocs concernée, que cette chaîne de blocs soit une première chaîne de blocs d’une nouvelle série temporelle ou une chaîne de blocs remplaçant une chaîne de blocs précédente dans une série temporelle déjà existante. La zone de supervision (250) est en outre utilisée pour paramétrer l’utilisation de la chaîne de blocs durant la durée autorisée de migration.
[0075] La zone de supervision d’une chaîne de blocs peut être propre à une seule version de chaîne de blocs ou bien être commune à toutes les chaînes de blocs de la série temporelle de chaîne de blocs à laquelle appartient cette chaîne de blocs. Par l’exemple de la Fig. 2A , une unique zone de supervision (250) est utilisée pour les différentes chaînes de blocs d’une série temporelle de chaînes de blocs: 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-II ; une zone de supervision ZTBSxx commune est associée à la série temporelle de chaînes de blocs BSxx-1, ... BSxx-15, ... BSxx-mm.
[0076] La zone de supervision (250) d’une chaîne de blocs peut comprendre les paramètres de création de la chaîne de blocs concernée.
[0077] La zone de supervision (250) d’une chaîne de blocs secondaire (220) (BS26) peut comprendre les paramètres de connexion associés à la chaîne de blocs secondaire (220) (BS26) concernée.
[0078] Dans la suite de la description, on suppose pour simplifier qu’on utilise une unique zone de supervision pour une série temporelle (BSX) de chaînes de blocs secondaires et on note ZTBSX la zone de supervision correspondante. La zone de supervision (250) peut comprendre les droits utilisateurs associés et les adresses utilisateurs pour la connexion à chaque chaîne de blocs secondaire BSX-Y concernée. La zone de supervision (250) d’une chaîne de blocs secondaire BSX-Y stocke par exemple pour chaque utilisateur Z, l’adresse utilisateur (173) AM-BSX-Y-Z en association avec les droits D-BSX-Y-Z associés à cette adresse utilisateur (173) sur la chaîne de blocs concernée. Si par exemple les droits d’un utilisateur sont supprimés sur une chaîne de blocs secondaire (220) alors la zone de supervision (250) le mentionne tout comme la zone de supervision (250) comprend des données spécifiant les droits obtenus par un utilisateur sur une adresse utilisateur (173) particulière.
[0079] Annuaire
[0080] Selon ce qui est illustré par la Fig. 2B, le master (200) stocke en mémoire un annuaire (230) d’utilisateurs. Cet annuaire (230) d’utilisateurs comprend une première partie, appelée ici annuaire (230) master (200), composée de niches, appelées niches master (231). Une niche master NM-Z (231) est un espace de stockage (correspondant à un ou plusieurs blocs de données) associé à un utilisateur Z (avec Z=Z0, Z1, Z2...) du master (200) et est configurée pour stocker l’adresse utilisateur (173) A-M-Z allouée à cet utilisateur Z pour la connexion au master (200). L’adresse utilisateur (173) A-M-Z alloué à un utilisateur pour la connexion au master (200) est appelée ici adresse master ou adresse maître.
[0081] Une niche master NM-Z (231) est configurée pour stocker en outre une carte de visite de cet utilisateur Z (avec Z=Z0, Z1, Z2...) en association avec l’adresse maître de cet utilisateur. La carte de visite est un espace de stockage où l’identité de l’utilisateur est détaillée, par exemple dans le respect des réglementations en vigueur. La carte de visite d’un utilisateur peut comprendre des informations publiques et/ou privées sur cet utilisateur telles que nom, prénom, alias, etc. Selon le fonctionnement mis en place, cette carte d’identité peut être gérée par l’utilisateur lui-même ou par l’administrateur du master (200). Une évaluation de l’utilisateur (« scoring » selon la terminologie anglo-saxonne) peut être mise en place et ouverte à participation à tous les autres utilisateurs du master (200) : dans ce cas la carte de visite peut servir à stocker ce type d’information d’évaluation.
[0082] Le gestionnaire technique (appelé aussi administrateur) d’une chaîne de blocs secondaire est également identifié dans une carte de visite dans l’annuaire du master, comme tout autre utilisateur. Dans le cas d’une série temporelle de chaînes de blocs secondaires, il peut y avoir un administrateur par version de chaîne de bloc secondaire ou un administrateur unique pour toutes les versions d’une série temporelle de chaînes de blocs.
[0083] L’annuaire (230) d’utilisateurs comprend une deuxième partie, appelée ici annuaire secondaire, composée de niches, appelées niches secondaires (232). Une niche secondaire NBSX-Y-Z (232) est un espace de stockage (correspondant à un ou plusieurs blocs de données) associé à un utilisateur Z et une chaîne de blocs secondaire BSX-Y donnée. Une niche secondaire NBSX-Y-Z (232) sert à référencer un utilisateur Z (avec Z=Z0, Z1, Z2...) d’une chaîne de blocs secondaire BSX-Y donnée. Une niche secondaire NBSX-Y-Z (232) est stockée en association avec l’adresse master A-M-Z de cet utilisateur et/ou la carte de visite de cet utilisateur. Dans une niche secondaire NBSX-Y-Z (232) est stockée l’adresse utilisateur (173) AT-BSX-Y-Z (appelée aussi adresse technique) allouée à cet utilisateur Z pour la connexion à la chaîne de blocs secondaire BSX-Y concernée en association avec le profil utilisateur pour cette chaîne de blocs secondaire. L’adresse utilisateur (173) AT-BSX- Y-Z allouée à un utilisateur Z pour la connexion à la chaîne de blocs secondaire BSX-Y est appelée ici également adresse secondaire. Le profil utilisateur comprend les droits de l’utilisateur sur la chaîne de blocs secondaire concernée.
[0084] L’annuaire (230) peut être structuré par chaîne de blocs secondaire de sorte que les niches associées aux utilisateurs ayant accès à une chaîne de blocs secondaire soient regroupées. Par exemple, l’annuaire (230) peut être structuré en ruches, avec une ruche par chaîne de blocs secondaire, cette ruche comprenant les niches associées à cette chaîne de blocs secondaire.
[0085] Dans un ou plusieurs modes de réalisation, une adresse multisignée (180) (appelée aussi « adresse métier ») AM-BSX-Y-Z est générée à partir de deux adresses : d’une part, l’adresse utilisateur (173) AT-BSX-Y-Z alloué à l’utilisateur Z pour la connexion à la chaîne de blocs secondaire BSX-Y et, d’autre part, l’adresse administrateur AT-BSX-Y-Z0 de l’administrateur de la chaîne de blocs secondaire BSX-Y. Cette adresse multisignée (180) est utilisée pour la réalisation d’opérations sur la chaîne de blocs secondaire (220) BSX-Y, de sorte que l’administrateur technique de la chaîne de blocs secondaire BSX-Y est en mesure de faire des opérations pour le compte de cet utilisateur Z1. La ou les opérations de signature numérique de transactions métier dans la chaîne de blocs BSX-Y sont effectuées : soit au moyen l’adresse secondaire AT-BSX-Y-Z1 lorsqu’elles sont demandées par l’utilisateur Z1, soit au moyen l’adresse administrateur AT-BSX-Y-ZO, lorsqu’elles sont demandées par l’administrateur technique de la chaîne de blocs BSX-Y.
[0086] Catalogue
[0087] Selon ce qui est illustré par la Fig. 2B, le master (200) stocke également en mémoire un catalogue (240) de chaînes de blocs secondaires (voir FIG. 2B). Ce catalogue (240) liste les chaînes de blocs secondaires supervisées par le master (200) et les descriptions associées respectivement à ces chaînes de blocs secondaires. Le catalogue (240) comprend en outre pour chaque chaîne de blocs secondaire (220) (par exemple BS26) un lien vers la zone de supervision (250) (par exemple ZTBS26) de cette chaîne de blocs secondaire (220). Par exemple sur la FIG. 2B, le catalogue (240) contient un bloc de données (241) qui pointe vers la zone de supervision ZTBS26 (250) de la chaîne de blocs secondaire BS26. La zone de supervision ZTBS26 (250) comprend un bloc de données (251) associé à l’utilisateur Z qui stocke en association une adresse multisignée AM-BS26- Y-Z allouée à l’utilisateur Z pour la signature de transaction dans la chaîne de blocs secondaire BS26 avec les droits D-BS26-Y-Z de l’utilisateur Z sur la chaîne de blocs secondaire BS26.
[0088] Les chaînes de blocs auxquelles un utilisateur est susceptible de se connecter peuvent se multiplier. Ces chaînes de blocs peuvent correspondre à des applications connexes de sorte qu’il apparaît un besoin pour une gestion et/ou un contrôle centralisé(e) des connexions à différentes chaînes de blocs.
[0089] Concernant la connexion à une chaîne de bloc, différents modes de réalisation sont envisageables.
[0090] Selon un premier exemple de réalisation, un procédé de connexion à une chaîne de blocs, est mis en œuvre par un ou plusieurs ordinateurs et comprend : une réception d’une demande de connexion à la chaîne de blocs, la chaîne de blocs étant une chaîne de blocs secondaire dont l’accès est supervisé via une chaîne de blocs principale ; une allocation à l’utilisateur d’une adresse secondaire pour la connexion à la chaîne de blocs secondaire; un enregistrement, dans la chaîne de blocs principale, dans un annuaire d’utilisateurs, de l’adresse secondaire ; un enregistrement, dans la chaîne de blocs principale, dans une zone de supervision de la chaîne de blocs secondaire, des droits de l’utilisateur sur la chaîne de blocs secondaire accordés par l’administrateur de la chaîne de blocs secondaire ; une authentification de l’utilisateur au moyen de l’adresse secondaire suite à une demande de connexion à la chaîne de blocs secondaire. Un tel procédé permet à un utilisateur de se connecter à au moins une chaîne de blocs secondaire de manière indépendante de la chaîne de blocs tout en permettant une gestion et supervision centralisées des connexions aux différentes chaînes de blocs secondaires.
[0091] Dans un ou plusieurs modes de réalisation, le procédé selon le premier exemple de réalisation comprend une réception d’une requête d’enregistrement d’une transaction envoyée par l’utilisateur via une adresse multisignée générée à partir de l’adresse secondaire et d’une adresse utilisateur d’un administrateur de la chaîne de blocs secondaire ; une signature de la transaction par l’utilisateur au moyen de la signature correspondant à l’adresse secondaire.
[0092] Dans un ou plusieurs modes de réalisation, le procédé selon le premier exemple de réalisation comprend un enregistrement, dans la chaîne de blocs principale, d’un catalogue de chaînes de blocs secondaires, le catalogue comprenant pour chaque chaîne de blocs secondaire une description et un lien vers une zone de supervision de la chaîne de blocs secondaire concernée. Le procédé peut comprendre une recherche d’au moins une chaîne de blocs secondaire dans le catalogue de chaînes de blocs sur la base de critères de recherche entrés par un utilisateur; une obtention, dans la zone de supervision de la chaîne de blocs secondaire concernée, de paramètres de connexion à la chaîne de blocs secondaire correspondant aux critères de recherche.
[0093] Dans un ou plusieurs modes de réalisation, le procédé selon le premier exemple de réalisation peut comprendre une connexion de l’utilisateur à la chaîne de blocs principale au moyen d’une adresse principale allouée à cet utilisateur; une lecture, au moyen d’une adresse principale, dans l’annuaire d’utilisateurs de l’adresse secondaire de l’utilisateur et de l’adresse multisignée; une lecture, dans la chaîne de blocs principale dans la zone de supervision de la chaîne de bloc secondaire, des droits de l’utilisateur stockés en association avec l’adresse multisignée lue; une réception d’une demande d’accès de l’utilisateur à la chaîne de blocs secondaire et une authentification de l’utilisateur sur la base de l’adresse secondaire lue ; une connexion de l’utilisateur à la chaîne de blocs secondaire en cas d’authentification réussie.
[0094] Dans un ou plusieurs modes de réalisation du procédé selon le premier exemple de réalisation, l’adresse secondaire allouée à un utilisateur pour la connexion à la chaîne de blocs est stockée dans l’annuaire d’utilisateurs en association avec l’adresse multisignée. [0095] Dans un ou plusieurs modes de réalisation du procédé selon le premier exemple de réalisation, les droits d’un utilisateur sur la deuxième chaîne de blocs sont enregistrés dans la zone de supervision en association avec l’adresse multisignée allouée à cet utilisateur. [0096] Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre du procédé selon ce premier exemple de réalisation.
[0097] Selon un deuxième exemple de réalisation, un dispositif informatique ou système informatique comprend des moyens de mise en œuvre du procédé selon le premier exemple de réalisation. Ces moyens peuvent comprendre un ou plusieurs processeurs et une ou plusieurs mémoires comprenant un code de programme d'ordinateur, la ou les mémoires et le code de programme d'ordinateur étant configurés pour, avec le ou les processeurs, causer l’exécution par le dispositif des étapes du procédé selon le premier exemple de réalisation. Par exemple, la ou les mémoires comprennent un programme d’ordinateur comprenant des instructions configurées pour causer l’exécution par le dispositif des étapes du procédé selon le premier exemple de réalisation.
[0098] Dans un ou plusieurs modes de réalisation, les différentes étapes du procédé selon le premier exemple de réalisation sont mises en œuvre par un ou plusieurs programmes d'ordinateur.
[0099] Selon un troisième exemple de réalisation, un support de stockage de données lisible par un processeur sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l'exécution des étapes d’un procédé selon le premier exemple de réalisation lorsque les instructions sont mises en œuvre par un ou plusieurs programmes d'ordinateur.
[0100] Selon un quatrième exemple de réalisation, un produit programme d’ordinateur comprend des instructions pour l’exécution des étapes d’un procédé selon le premier exemple de réalisation lorsque le programme d’ordinateur est exécuté par un processeur de données.
[0101] Un exemple de procédé de connexion d’un utilisateur à une chaîne de blocs est décrit en détail par référence aux FIGS. 3A et 3B. Pour simplifier la description, le cas d’exemple d’une connexion à une chaîne de blocs secondaire (220) BS26 particulière est décrit, mais est applicable à toute autre chaîne de blocs secondaire (220).
[0102] Bien que les étapes de ce procédé soient présentées de manière séquentielle, l’ordre d’exécution de ces étapes peut être modifié, certaines des étapes peuvent être exécutées au moins en partie en parallèle, certaines des étapes peuvent être omises ou répétées.
[0103] A titre d’exemple, on se référera à la Fig. 1A, et on supposera que la chaîne de bloc master correspond aux instances 140, 141, 142 de chaînes de bloc, que l’administrateur du master correspond à l’utilisateur Z0 et que le nœud de l’administrateur du master correspond donc au nœud 100.
[0104] Etape 300 : Enregistrement du catalogue dans le master
[0105] Le master stocke un catalogue (240) de chaînes de blocs secondaires. Ce catalogue (240) comprend pour chaque chaîne de blocs secondaire (220) une description et un lien vers une zone de supervision (250) de la chaîne de blocs secondaire (220) concernée. Le stockage de ces informations peut s’effectuer au fur et à mesure de la création des chaînes de blocs secondaires et des mises à jour sur ces chaînes de blocs secondaires.
[0106] Cet enregistrement du catalogue peut se faire sous la supervision de l’administrateur Z0 du master. Par exemple, par référence à la Fig. 1A, cet enregistrement se fait au moyen du dispositif informatique 150 dans l’instance 140 du master. Il est à noter qu’à ce stade, les instances 141 et 142 du master peuvent ne pas exister si les utilisateurs Z1 et Z2 ne sont pas encore enregistrés auprès du master. Dans le cas où ces instances existent, une synchronisation a lieu de sorte à mettre à jour les différentes instances 141 et 142 du master.
[0107] Etape 305 : Connexion de l’utilisateur au master (200)
[0108] L’utilisateur Z1 se connecte au master (200) au moyen d’un dispositif informatique 151 du nœud 101. L’utilisateur est authentifié sur la base de son adresse master (173) A-M- Z1 qui lui est allouée pour l’accès au master et de données d’authentification associées (par exemple d’un mot de passe ou autre).
[0109] A titre d’exemple, on se référera à la Fig. 1A, et on supposera que cet utilisateur est l’utilisateur Z1 du nœud 101. Ainsi, les opérations (par exemple, lecture ou écriture de données, recherche de données, etc) effectuées par l’utilisateur Z1 sur le master seront effectuées au moyen du logiciel associé au master exécutée par le dispositif informatique 151 du nœud 101 de l’utilisateur Z1. De même, les opérations (par exemple, lecture ou écriture de données, transaction, etc) effectuées par l’utilisateur Z1 sur une chaîne de bloc secondaire donnée, par exemple BS26 seront effectuées au moyen du logiciel associé à la chaîne de bloc secondaire BS26, exécutée par le dispositif informatique 151 du nœud 101 associé à l’utilisateur Z1.
[0110] Il peut s’agir de la première connexion au master, c’est-à-dire la phase où un utilisateur souhaite obtenir une adresse utilisateur (173) (servant d’identifiant) A-M-Z1 pour la connexion au master (200) et les droits relatifs au master (200) qui sont rattachés à cette adresse utilisateur (173) A-M-Z1. Cette première connexion peut être réalisée selon toute procédure de connexion connue. Ainsi, après la première authentification réussie, l’adresse master A-M-Z1 de l’utilisateur Z1 est stockée, au moyen du logiciel associé au master exécutée par le dispositif informatique 151 du nœud 101, dans la niche master NM-Z1 (231) de cet utilisateur. Elle peut être stockée en association avec la carte de visite de l’utilisateur Z1.
[0111] Dans le cas où un utilisateur perd les moyens de se connecter et souhaite accéder, à nouveau, au master (200), cela peut correspondre, techniquement, à une première authentification. Pour être connecté au master (200), il est usuellement nécessaire de demander les droits d’accès via un canal de communication autre que le master (200), pour pouvoir finaliser l’accès au master (200). [0112] Par la suite, pour chaque chaîne de blocs secondaire (220) à laquelle l’utilisateur sera connecté, l’adresse secondaire (ou adresse technique) AT-BSX-Y-Z1 de l’utilisateur Z1 pour la chaîne de blocs secondaire (220) sera stockée dans la niche NBSX-Y-Z1 (232) de la chaîne de blocs secondaire (220) concernée et fait référence à la carte de visite de l’utilisateur et/ou l’adresse maître de l’utilisateur.
[0113] Après une authentification réussie, un utilisateur Z1 a accès au master (200), et notamment à l’annuaire (230) et au catalogue (240). En particulier, une nouvelle instance
141 du master est créée au niveau du nœud 101. Dans le cas de nœuds complets, cette nouvelle instance est une copie intégrale de l’instance 140 du master du nœud administrateur 100 associé à l’administrateur Z0.
[0114] Comme toutes les opérations d’enregistrement de données dans le master, une synchronisation a lieu entre les différentes instances 140, 141, 142 de la chaîne de bloc master. Par exemple, par référence à la Fig. 1A, si on suppose que la chaîne de bloc master correspond aux instances 140, 141, 142 de chaînes de bloc, et si l’instance 141 de chaîne de bloc master est modifiée au niveau du nœud 101 suite à l’enregistrement de l’adresse master A-M-Z1 de l’utilisateur Z1 dans la niche master NM-Z1 (231), les instances 140 et
142 sont mises à jour également au niveau respectivement des autres nœuds 100 et 102. [0115] Etape 310 : accès au catalogue (240) et recherche d’une chaîne de blocs
[0116] Après connexion de l’utilisateur à la chaîne de blocs principale, le master (200) présente le catalogue (240) des chaînes de blocs secondaires supervisées par le master (200). Suite à une première authentification, le catalogue (240) permet ainsi à l’utilisateur de connaître l’ensemble des chaînes de blocs secondaires gérées.
[0117] Une recherche (310) d’au moins une chaîne de blocs secondaire (220) est effectuée dans le catalogue (240) de chaînes de blocs sur la base de critères de recherche entrés par un utilisateur. Comme expliqué plus haut, cette recherche s’effectue au moyen du logiciel associé au master exécutée par le dispositif informatique 151 du nœud 101 de l’utilisateur Z1.
[0118] Etape 320 : obtention de paramètres de connexion à la chaîne de blocs secondaire. [0119] Le catalogue (240) étant relié aux zones de supervision des chaînes de blocs secondaires, ceci permet de retrouver les paramètres de connexion présents dans la zone de supervision de chaque chaîne de blocs secondaire (220).
[0120] Ainsi, l’utilisateur Z1 obtient du master, au moyen du logiciel associé au master exécutée par le dispositif informatique 151, des paramètres de connexion à une chaîne de blocs secondaire BS26 correspondant aux critères de recherche ou à une chaîne de blocs secondaire BS26 sélectionnée par l’utilisateur. Ces paramètres de connexion sont lus dans la zone de supervision (250) de la chaîne de blocs secondaire BS26 concernée. Selon le mode de stockage par nœud complet ou nœud léger, la zone de supervision (250) peut être stockée dans les différentes instances 140, 141, 142 du master ou seulement dans l’instance 140 du nœud 100 de l’administrateur Z0 du master.
[0121] Lorsqu’un utilisateur Z1 trouve et sélectionne dans le catalogue (240) une chaîne de blocs secondaire par exemple BS26 à laquelle l’utilisateur souhaite se connecter (par exemple, après une recherche par mots clefs dans la description des chaînes de blocs secondaires), l’utilisateur obtient ainsi via la zone de supervision ZTBS26 de la chaîne de blocs secondaire BS26 des paramètres de connexion qui vont lui permettre de s’enregistrer à la chaîne de blocs secondaire BS26.
[0122] Etape 330 : connexion à la chaîne de blocs secondaire
[0123] Cette étape concerne une première connexion de l’utilisateur à la chaîne de blocs secondaire sélectionnée précédemment, cette chaîne de blocs étant une chaîne de blocs secondaire BS26 dont l’accès est supervisé via le master.
[0124] L’utilisateur envoie, au moyen d’un dispositif informatique (151), une demande de connexion à la chaîne de blocs secondaire BS26 en utilisant les paramètres de connexion obtenus à l’étape 320. En pratique, lorsque la chaîne de blocs secondaire BS26 fait partie d’une série de chaîne de blocs, la connexion est effectuée sur la version Y courante de la chaîne de blocs secondaire. Ainsi on notera BS26-Y la chaîne de bloc concernée par les étapes 340 à 380, mais ces étapes sont applicables de la même manière à une chaîne de blocs isolée, ne faisant pas partie d’une série. Cette demande de connexion s’effectue au moyen du logiciel associé à la chaîne de blocs secondaire BS26-Y exécutée par le dispositif informatique 151 du nœud 101 de l’utilisateur Z1.
[0125] Etape 340 : allocation d’adresse technique et d’adresse multisignée [0126] L’utilisateur obtient en retour une adresse utilisateur (173) AT-BS26-Y-Z1 (adresse secondaire, ou encore adresse technique), servant d’identifiant de connexion à la chaîne de blocs secondaire BS26-Y.
[0127] Après inscription dans l’annuaire et allocation de l’adresse AM-BS26-Y-Z1 , l’utilisateur Z1 obtient en outre l’adresse multisignée (180) AM-BS26-Y-Z1 qui lui est allouée pour la signature de transactions à enregistrer au nom de cet utilisateur dans la chaîne de blocs secondaire BS26-Y. L’adresse multisignée (180) est générée à partir de l’adresse secondaire AT-BS26-Y-Z1 et d’une adresse technique AT-BS26-Y-Z0 (ou adresse administrateur) d’un administrateur de la chaîne de blocs secondaire BS26-Y. Par souci de simplification de l’exposé et des notations, on suppose que l’administrateur de la chaîne de blocs secondaire BS26-Y est l’utilisateur Z0 du nœud 100 tout comme pour le master. Mais il pourrait s’agir d’un autre utilisateur, par exemple de l’utilisateur Z2 du nœud 102.
[0128] L’adresse secondaire AT-BS26-Y-Z1 (173) et l’adresse multisignée (180) AM-BS26- Y-Z1 sont générées par le logiciel associé à la chaîne de blocs secondaire BS26-Y, exécutée au moyen du dispositif informatique 150 du nœud administrateur 100 de la chaîne de blocs secondaire BS26-Y, sous le contrôle de l’administrateur Z0 de la chaîne de blocs secondaire BS26-Y. Pendant cette étape 340, le logiciel associé à la chaîne de blocs secondaire BS26-Y, exécutée au moyen du dispositif informatique 150 du nœud administrateur 100 de la chaîne de blocs secondaire BS26-Y est ainsi en communication avec le logiciel associé à la chaîne de blocs secondaire BS26-Y, exécutée au moyen du dispositif informatique 151 du nœud 101 associé à l’utilisateur Z1.
[0129] L’adresse multisignée (180) AM-BS26-Y-Z1 est basée sur deux signatures : d’une part, la signature de l’utilisateur issue de l’adresse secondaire AT-BS26-Y-Z1 et, d’autre part, la signature du gestionnaire technique (ou administrateur) issue de l’adresse AT-BS26- U-Z0 de l’administrateur Z0 de la chaîne de blocs secondaire BS26-Y. L’adresse multisignée (180) AM-BS26-Y-Z1 est déterminée de sorte qu’elle ne requiert qu’une seule signature parmi les deux signatures possibles.
[0130] Etape 350 : enregistrement dans l’annuaire (230) du master (200).
[0131] L’adresse multisignée (180) AM-BS26-Y-Z1 est enregistrée dans le master dans l’annuaire (230) secondaire en tant qu’adresse métier pour la chaîne de blocs BS26-Y. L’adresse multisignée (180) AM-BS26-Y-Z1 est enregistrée, dans la niche NBS26-Y-Z1 de la chaîne de blocs secondaire BS26-Y concernée, en association avec l’adresse technique AT-BS26-Y-Z1 pour qu’un lien explicite existe entre les deux adresses.
[0132] Seul l’administrateur de la chaîne de blocs secondaire BS26-Y possède les droits en écriture dans la zone de supervision de la chaîne de blocs secondaire BS26-Y et dans l’annuaire secondaire associé à la chaîne de blocs secondaire BS26-Y. Ces droits de l’administrateur de la chaîne de blocs secondaire BS26-Y sur le master ont été préalablement demandés au master par un processus externe. Ainsi l’enregistrement dans l’annuaire du master est effectué dans l’instance 140 du master, par le logiciel associé à la chaîne de blocs secondaire BS26-Y, exécutée au moyen du dispositif informatique 150 du nœud administrateur 100 de la chaîne de blocs secondaire BS26-Y, sous le contrôle de l’administrateur Z0 de la chaîne de blocs secondaire BS26-Y. Puis, par un mécanisme de synchronisation, les autres instances 141 et 142 du master sont mises à jour au niveau des nœuds 101 et 102 associés.
[0133] L’utilisateur Z1 dispose de droits en lecture sur la niche master NBS26-Y-Z1 de l’annuaire qui lui est associée. Après synchronisation des instances du master, l’utilisateur Z1 peut lire l’adresse multisignée (180) AM-BS26-Y-Z1 et l’adresse technique AT-BS26-Y- Z1 dans cette niche master NBS26-Y-Z1 au moyen du logiciel associé au master, exécutée au moyen du dispositif informatique 151 du nœud 101 associé à l’utilisateur Z1. [0134] Etape 360 : enregistrement des droits.
[0135] Des droits sur la chaîne de blocs secondaire BS26-Y sont alloués à l’utilisateur par l’administrateur de la chaîne de blocs secondaire BS26-Y. Tout comme la génération d’adresses, l’allocation des droits sur la chaîne de blocs secondaire BS26-Y est effectuée par le logiciel associé à la chaîne de blocs secondaire BS26-Y, exécutée au moyen du dispositif informatique 150 du nœud administrateur 100 de la chaîne de blocs secondaire BS26-Y, sous le contrôle de l’administrateur Z0 de la chaîne de blocs secondaire BS26-Y. [0136] Les droits D-BS26-Y-Z1 accordés à l’adresse métier AM-BS26-Y-Z sont enregistrés dans le master (200) dans la zone de supervision ZTBS26 de la chaîne de blocs secondaire BS26-Y. Ces droits D-BS26-Y-Z1 sont enregistrés par l’administrateur de la chaîne de blocs BS26-Y en association avec l’adresse multisignée (180) AM-BS26-Y-Z1 dans la zone de supervision ZTBS26 de la chaîne de blocs secondaire BS26-Y. Cet enregistrement dans la zone de supervision ZTBS26 du master est effectué dans l’instance 140 du master, par le logiciel associé à la chaîne de blocs secondaire BS26-Y, exécutée au moyen du dispositif informatique 150 du nœud administrateur 100 de la chaîne de blocs secondaire BS26-Y, sous le contrôle de l’administrateur Z0 de la chaîne de blocs secondaire BS26-Y. Puis, par un mécanisme de synchronisation, les autres instances 141 et 142 du master sont mises à jour au niveau des nœuds 101 et 102 associés.
[0137] L’utilisateur Z1 dispose de droits en lecture sur les données de la zone de supervision ZTBS26 qui le concernent. Après synchronisation des instances du master, l’utilisateur Z1 peut lire les droits D-BS26-Y-Z1 inscrits dans la zone de supervision ZTBS26 au moyen du logiciel associé au master, exécutée au moyen du dispositif informatique 151 du nœud 101 associé à l’utilisateur Z1.
[0138] Etape 370 : connexion à la chaîne de blocs secondaire BS26-Y.
[0139] L’utilisateur utilise l’adresse technique AT-BS26-Y-Z1 pour se connecter et accéder à la chaîne de blocs secondaire BS26-Y. L’utilisateur est authentifié sur la base de son adresse utilisateur (173) AT-BS26-Y-Z1 et de données d’authentification associées (par exemple d’un mot de passe). Cette connexion s’effectue au moyen du logiciel associé à la chaîne de blocs secondaire BS26-Y, exécutée au moyen du dispositif informatique 151 du nœud 101 associé à l’utilisateur Z1.
[0140] Etape 380 : enregistrement d’une transaction dans la chaîne de blocs secondaire BS26-Y.
[0141] L’utilisateur envoie, au moyen de son dispositif informatique 151, à la chaîne de blocs secondaire BS26-Y une requête d’enregistrement d’une transaction. Cette requête d’enregistrement de transaction est émise à partir de l’adresse multisignée AM-BS26-Y-Z1. Cet envoi de requête est effectué par le logiciel associé à la chaîne de blocs secondaire BS26-Y, exécutée au moyen du dispositif informatique 151 du nœud 101 associé à l’utilisateur Z1.
[0142] La transaction envoyée via l’adresse multisignée AM-BS26-Y-Z1 (dans le cas où la transaction remplie les conditions de validation requises) est signée par l’utilisateur au moyen de la signature correspondant à l’adresse secondaire AT-BS26-Y-Z1, utilisée pour la génération de l’adresse multisignée AM-BS26-Y-Z1.
[0143] Lors de l’utilisation d’une chaîne de blocs secondaire BS26-Y, toute transaction entre deux utilisateurs ou plus est réalisée d’une adresse multisignée (180) vers une autre adresse multisignée (180). Selon les droits accordés et les applications envisagées, les transactions peuvent permettent de créer des actifs, créer des unités d’actif, d’envoyer des unités d’actif, d’effectuer des transactions qui contiennent des données non liées à un actif ou toute autre action permise par la technologie de la chaîne de blocs secondaire BS26-Y dans la limite des droits accordés.
[0144] Après validation de la transaction, un ou des blocs de données sont enregistrées dans la chaîne de blocs secondaire BS26-Y. Si on suppose ici à titre d’exemple que la chaîne de blocs secondaire BS26-Y correspond aux instances 130, 131, 132 décrites par référence à la Fig. 1A. Cet enregistrement est ainsi effectué dans l’instance 131 de la chaîne de blocs secondaire BS26-Y, par le logiciel associé à la chaîne de blocs secondaire BS26-Y, exécutée au moyen du dispositif informatique 151 du nœud 101 associé à l’utilisateur Z1. Puis, par un mécanisme de synchronisation, les autres instances 130 et 132 de la chaîne de blocs secondaire BS26-Y correspond sont (selon le besoin et le mode nœud complet / nœud léger) mises à jour au niveau des nœuds 100 et 102 associés.
[0145] Migration d’une chaîne de bloc secondaire
[0146] Un procédé de migration d’une chaîne de blocs secondaire va maintenant être décrit plus en détail par référence aux Figs. 4A et 4B.
[0147] Bien que les étapes de ce procédé soient présentées de manière séquentielle, l’ordre d’exécution de ces étapes peut être modifié, certaines des étapes peuvent être exécutées au moins en partie en parallèle, certaines des étapes peuvent être omises ou répétées. Selon l’architecture physique / matérielle choisie, les étapes de ce procédé concernant une chaîne de bloc peuvent être réalisées par une ou plusieurs des entités physiques (ordinateurs) mettant en œuvre les fonctions de cette chaîne de bloc au niveau d’au moins un nœud.
[0148] Ce procédé de migration est mis en œuvre de sorte à ne conserver que certaines informations des chaînes de blocs secondaires migrées, par exemple l’information applicative. De cette manière la taille mémoire occupée par la chaîne de blocs secondaire de remplacement est réduite comparée à la taille mémoire occupée par la chaîne de blocs remplacée. Lors de cette migration, le master (200) est en quelque sorte le chef d’orchestre de la migration en ce qu’il supervise la migration en se comportant comme un hub de communication.
[0149] La migration d’une chaîne de blocs s’effectue sous la supervision de l’administrateur de la BS26 et avec le logiciel 160 correspondant (notamment le sous-ensemble logiciel 160B, s’appuyant sur le sous-ensemble logiciel 160A), mise en œuvre sur le nœud de l’administrateur Z0.
[0150] La migration d’une chaîne de blocs est effectuée de préférence de sorte à garantir une continuité de service pour les applications (systèmes/projets applicatifs) mis en œuvre par cette chaîne de blocs.
[0151] Dans l’exemple ci-dessous, la chaîne de blocs secondaire (220) courante BSX-(Y-1) (soit BS26-23 si par exemple X=26 et Y=24) est migrée vers une nouvelle chaîne de blocs secondaire (220) BSX-Y (soit BS26-24 si par exemple X=26 et Y=24).
[0152] Lors d’une étape initiale 400, une date de début de migration est calculée par l’administrateur de la chaîne de blocs secondaire (220) courante. Ce calcul peut s’effectuer de plusieurs manières.
[0153] Dans un mode de réalisation, la fin de migration est calculée, par exemple à intervalles de temps réguliers. A partir de la fin de migration, le début de la plage temporelle de basculement est calculé et, à partir de la plage temporelle de basculement et/ou de la fin de migration, le début de la durée autorisée de migration est calculé. A partir de la fin de migration, le début de période tampon est également calculé.
[0154] Lors de l’étape 410, à l’occurrence du début de la durée autorisée de migration, la nouvelle chaîne de blocs secondaire BS26-Y est initialisée et enregistrée (paramètres de connexion, paramètres de migration, description, et autres paramètres utiles) dans le master (200) sur demande de l’administrateur de la chaîne de blocs secondaire (220) courante, cette nouvelle chaîne de blocs secondaire étant destinée à remplacer une chaîne de blocs secondaire à remplacer.
[0155] Une zone de supervision est créée dans la chaîne de bloc principale pour la nouvelle chaîne de blocs secondaire. Soit on complète la zone de supervision ZTBS26 si une seule zone de supervision est utilisée pour la série de chaîne de blocs, soit une nouvelle zone de supervision ZTBS26-Y est créée dans le master (200) pour la nouvelle chaîne de blocs secondaire BS26-Y si une zone de supervision propre à chaque version est utilisée. Cette zone de supervision ZTBS26-Y comprend les paramètres de création de la nouvelle chaîne de blocs secondaire BS26-Y, ces paramètres de création peuvent être identiques ou différents des paramètres de création de la chaîne de blocs secondaire courante BS26-(Y- 1). Comme décrit plus haut cette zone de supervision est destinée à stocker les droits utilisateurs associés et les adresses utilisateurs pour la connexion à la chaîne de blocs secondaire concernée.
[0156] Optionnellement, une nouvelle description de la nouvelle chaîne de blocs secondaire BS26-Y est enregistrée dans le catalogue (240) du master (200) ou la description de la série de chaîne de blocs secondaire BS26-Y est mise à jour.
[0157] Ces opérations d’enregistrement dans l’annuaire et le catalogue du master sont exécutées par l’administrateur Z0 de la BS26 via le logiciel associé au master, au moyen du dispositif informatique 150 du nœud administrateur 100 de la chaîne de blocs secondaire BS26-23 courante, sous le contrôle de l’administrateur Z0 de la chaîne de blocs secondaire BS26-23 courante.
[0158] Le déclenchement de la migration des différentes instances de la chaîne de blocs secondaire BS26-23 courante qui existent au niveau des différents nœuds 100, 101, 102 sera effectué au même moment par l’administrateur Z0 de la BS26. Puis ces différentes instances seront migrées selon le même procédé de migration décrit ci-dessous aux étapes 420 à 460 pour le nœud administrateur, éventuellement à des rythmes différents selon les capacités et ressources du nœud concerné. On va décrire ci-dessous ce qui se passe pour une des instances, au niveau d’un nœud 100, 101 ou 102.
[0159] Lors de l’étape 420, après initialisation de la nouvelle chaîne de blocs secondaire BS26-Y, la période d’inscription commence et tous les utilisateurs souhaitant ou devant s’inscrire sur la nouvelle chaîne de blocs secondaire BS26-Y sont invités à s’y connecter et à enregistrer dans l’annuaire (230) du master (200) leur nouvelle adresse technique pour cette nouvelle chaîne de blocs secondaire BS26-Y.
[0160] Pour chaque nouvelle inscription sur la nouvelle chaîne de blocs secondaire BS26-Y, l’adresse métier et l’adresse technique de l’utilisateur concerné sont enregistrées dans le master dans l’annuaire (230) associé à la nouvelle chaîne de blocs secondaire comme décrit par référence aux FIGS. 3A et 3B. Seul l’administrateur de la nouvelle chaîne de blocs secondaire BS26-Y possède les droits en écriture dans la zone de supervision de la nouvelle chaîne de blocs secondaire BS26 et dans l’annuaire secondaire associé à la chaîne de blocs secondaire BS26. Ainsi l’enregistrement dans l’annuaire du master est effectué dans l’instance 140 du master, sous le contrôle de l’administrateur Z0 de la chaîne de blocs secondaire BS26-Y via le logiciel associé à la chaîne de blocs secondaire BS26-Y, exécutée au moyen du dispositif informatique 150 du nœud administrateur 100 de la chaîne de blocs secondaire BS26-Y. Puis, par un mécanisme de synchronisation, les autres instances 141 et 142 du master sont mises à jour au niveau des nœuds 101 et 102 associés. Il est rappelé ici qu’il peut y avoir un administrateur unique pour toutes les chaînes de blocs d’une série temporelle ou bien un administrateur par version de chaîne de blocs. Durant la période d’inscription, les droits d’utilisateurs peuvent être modifiés ou ne pas être renouvelés
[0161] A chaque nouvelle inscription d’un utilisateur à la nouvelle chaîne de blocs secondaire, une nouvelle instance de cette chaîne de blocs secondaire est créée au niveau du nœud correspondant à l’utilisateur concerné.
[0162] Quand l’annuaire (230) de la nouvelle chaîne de blocs secondaire est complété avec tout ou partie des adresses métier de la chaîne de blocs secondaire courante BS26-(Y-1), les droits sont affectés à toutes les adresses métiers (adresses multisignées) allouées pour la nouvelle chaîne de blocs secondaire BS26-Y. Les adresses techniques restent sans droits, ou alternativement avec des droits d’envoyer mais sans droits de réception pour tous les utilisateurs correspondants, de telle sorte que l’état de la nouvelle chaîne de blocs secondaire reste figé jusqu’à l’étape 450 de basculement des utilisateurs. En particulier, aucun nouveau bloc de données ne peut être généré dans la nouvelle chaîne de blocs secondaire.
[0163] Lors de l’étape 430, la période d’initialisation, dite « initialisation métier », commence après allocation des droits aux adresses métiers. Lors de cette étape 430, l’administrateur de la nouvelle chaîne de blocs secondaire BS26-Y, ayant le droit de signature sur chaque adresse métier multisignée, génère, avec les adresses métiers (adresses multisignées) des utilisateurs propriétaires, dans la nouvelle chaîne de blocs, un ensemble de blocs de données correspondant à une image de la première chaîne de blocs. La signature de ces blocs de données est effectuée par l’administrateur au moyen de l’adresse administrateur de la chaîne de blocs secondaire BS26-Y. Cette image correspond à un instant déterminé dans l’historique de la première chaîne de blocs. Par exemple, chaque actif et chaque unité d’actif est recréé(e) et les unités d’actifs sont alloués aux adresses utilisateurs de façon à ce que l’image des données de la nouvelle chaîne de blocs secondaire BS26-Y soit identique à l’image des données de l’ancienne chaîne de blocs secondaire BS26-(Y-1) en termes d’actifs détenus par les utilisateurs.
[0164] L’instant de génération de l’image correspond au début de la période mémoire de l’ancienne chaîne de blocs secondaire BS26-(Y-1). Les opérations réalisées dans le passé sur l’ancienne chaîne de blocs secondaire BS26-(Y-1) pendant une période de temps de durée à la période mémoire de l’ancienne chaîne de blocs secondaire BS26-(Y-1) sont en outre réalisées sur la nouvelle chaîne de blocs secondaire BS26-Y de sorte à reproduire la partie pertinente correspondant de l’historique de la chaîne de blocs BS26-(Y-1).
[0165] Selon ce qui est illustré sur la fig. 4A, l’image initiale est générée à l’instant T0, correspondant au début de la période mémoire. Puis les opérations réalisées pendant une période de temps de durée T1-T0 sont reproduites sur la nouvelle chaîne de blocs secondaire BS26-Y de sorte que, suite à cette reproduction, l’état de la nouvelle chaîne de blocs secondaire BS26-Y corresponde à l’état courant de l’ancienne chaîne de bloc à l’instant T 1. L’instant T 1 correspond aussi au début de la période de migration.
[0166] La génération de cette image est effectuée dans une instance locale de la nouvelle chaîne de bloc secondaire BS26-Y, par le logiciel associé à la nouvelle chaîne de blocs secondaire BS26-Y, exécutée au moyen du dispositif informatique 150 du nœud administrateur 100 de la nouvelle chaîne de blocs secondaire BS26-Y, sous le contrôle de l’administrateur Z0 de la nouvelle chaîne de blocs secondaire BS26-Y. Aucun utilisateur n’étant inscrit, il n’y a pas d’autres instances de la nouvelle chaîne de bloc secondaire BS26- Y pour laquelle une synchronisation est nécessaire.
[0167] Lorsque, après la période d’initialisation métier, commence la période dite période miroir, correspondant à l’étape 440. Pendant cette période miroir, l’ancienne chaîne de blocs secondaire BS26-(Y-1) coexiste avec la nouvelle chaîne de blocs secondaire BS26-Y et reste accessible pour toutes les opérations conformes aux droits accordés. En outre, durant la période miroir, les nouvelles opérations (transactions ou autres) réalisées sous le contrôle de l’administrateur Z0 sur l’ancienne chaîne de blocs secondaire BS26-(Y-1) via le logiciel associé à la chaîne de blocs secondaire BS26-(Y-1), sont aussi réalisées sous le contrôle de l’administrateur Z0 sur la nouvelle chaîne de blocs secondaire BS26-Y via le logiciel associé à la chaîne de blocs secondaire BS26-Y, afin que l’image des données reste toujours identique, à l’instant t, sur les deux chaînes de blocs secondaires BS26-Y et BS26-(Y-1).
Ces nouvelles transactions sont des transactions pour lesquelles une requête d’enregistrement est parvenue auprès de la chaîne de blocs à remplacer ou dans la chaîne de blocs de remplacement. Dans le cas où une telle transaction implique un utilisateur qui n’est pas encore inscrit sur la nouvelle chaîne de blocs, l’inscription de cet utilisateur peut être simulée en créant en lui affectant une adresse secondaire et une adresse multisignée et les inscriptions dans la nouvelle chaîne de blocs sont requises par l’administrateur de la nouvelle chaîne de blocs au moyen de l’adresse multisignée de cet utilisateur et signées avec l’adresse secondaire de cet administrateur.
[0168] Lors de la période miroir, tout nouveau bloc créé dans la nouvelle ou l’ancienne chaîne de blocs est aussi dupliqué par un mécanisme de synchronisation dans chacune des instances existantes de la nouvelle ou de l’ancienne chaîne de blocs.
[0169] La période de basculement des utilisateurs débute après le début de la période miroir et correspond à l’étape 450. Comme illustré par la Fig. 4A, cette période de basculement des utilisateurs peut se faire au moins en partie en parallèle avec la période miroir. Au début de la plage temporelle de basculement, les droits sont alloués aux adresses techniques et les systèmes/projets utilisant l’ancienne chaîne de blocs secondaire et ayant des droits sur la nouvelle chaîne de blocs secondaire sont autorisés à basculer vers la nouvelle chaîne de blocs secondaire BS26-Y. Pour enregistrer le basculement d’un utilisateur, un marqueur est stocké, au moyen du logiciel associé au master, sous le contrôle de l’administrateur Z0, pour cet utilisateur dans le master (200) qui comprend l’identifiant de la chaîne de blocs secondaire à laquelle est connecté un utilisateur. Un marqueur indique si un utilisateur a basculé ou non vers la chaîne de blocs de remplacement. En pratique, le basculement d’un utilisateur correspond ainsi à un basculement de droits de cet utilisateur vers la chaîne de blocs de remplacement (que ces droits soient ou non identiques sur ces deux chaînes de blocs).
[0170] A partir du moment où la valeur du marqueur est modifiée, les enregistrements de nouvelles transactions sont réorientées de manière appropriée. Ainsi, si l’utilisateur était sur la chaîne de blocs à remplacer BS26-(Y-1) alors c’est la chaîne de blocs de remplacement BS26-Y qui est mise à jour à jour avec le logiciel associé à BS26-Y, de la part de l’utilisateur, pour la conserver à l’image de la chaîne de blocs à remplacer BS26-(Y-1). A contrario, lorsque l’utilisateur a migré vers la chaîne de blocs de remplacement BS26-Y alors la mise à jour se fait sur la chaîne de blocs à remplacer BS26-(Y-1) avec le logiciel associé à BS26- (Y-1), de la part de l’utilisateur, de sorte à conserver une image des données identique sur les deux chaînes de blocs à un moment où des utilisateurs sont toujours connectés sur l’une des deux chaînes de blocs et d’autres utilisateurs sur l’autre des deux chaînes de blocs. Il est à noter que cette image ne tient pas compte du passé, puisque, comme expliqué plus haut pour la création de l’image de départ à l’étape 430, les transactions antérieures au début de la période mémoire ne sont pas reproduites, seule la répartition des actifs entre les utilisateurs au début de la période mémoire étant reproduite dans la nouvelle chaîne de blocs.
[0171] Lors de la migration, le master sert de registre de communication en ce que le master permet de déterminer à quelle version de la chaîne de blocs secondaire un utilisateur doit se connecter à un moment donné du processus de migration, grâce notamment au marqueur enregistré pour cet utilisateur. Les deux de chaînes de blocs coexistent pendant la durée de la période miroir pendant laquelle les utilisateurs peuvent être migrés d’une chaîne à l’autre, chacun à des instants différents et sans contrainte. De plus comme une nouvelle chaîne de blocs est calculée, le temps de calcul nécessaire au démarrage de la nouvelle chaîne est réduit au minimum.
[0172] Lorsque tous les utilisateurs ont migré sur la nouvelle chaîne de blocs secondaire BS26-Y et au plus tard à la date de fin de migration prévue, alors l’ancienne chaîne de blocs secondaire BS26-(Y-1), est arrêtée à l’étape 460. Cette étape correspond au basculement entre l’ancienne chaîne de blocs secondaire BS26-(Y-1) et la nouvelle chaîne de blocs secondaire BS26-Y. Ce basculement entre chaînes de blocs secondaires est définitif de sorte que toute nouvelle transaction est enregistrée uniquement dans la nouvelle chaîne de blocs de sorte que plus aucune transaction ne peut être enregistrée dans l’ancienne chaîne de blocs BS26-(Y-1) et toute nouvelle transaction est enregistrée uniquement dans la nouvelle chaîne de blocs BS26-Y. La période miroir se termine donc et tous les droits, sauf éventuellement le droit de connexion (ensemble de droits « Connect » décrit par référence à la Fig. 1D), sont retirés des adresses utilisateurs pour l’ancienne chaîne de blocs secondaire BS26-(Y-1). La conservation des seuls droits de connexion ne permet pas aux utilisateurs de supprimer leur instance locale sur l’ancienne chaîne de blocs secondaire BS26-(Y-1), mais seulement de pouvoir s’y reconnecter et y retrouver toutes les données historiques (droits de lecture) si besoin.
[0173] L’enregistrement des droits restreints sur l’ancienne chaîne de blocs secondaire est effectuée dans le master dans la zone de supervision de l’ancienne chaîne de blocs dans une instance locale du master, par le logiciel associé au master, exécutée au moyen du dispositif informatique 150 du nœud administrateur 100 de l’ancienne chaîne de blocs secondaire, sous le contrôle de l’administrateur Z0 de l’ancienne chaîne de blocs secondaire.
[0174] Si tous les utilisateurs (hormis l’administrateur) n’ont plus que des droits de connexion sur l’ancienne chaîne de blocs secondaire, aucun changement ne pourra plus être apporté sur l’ancienne chaîne de blocs secondaire qui sert donc d’archive par rapport à la nouvelle chaîne de blocs secondaire. Il est envisageable également que les droits de l’administrateur soit réduits d’une manière ou d’une autre.
[0175] Un utilisateur Z1 a la possibilité de supprimer l’instance locale au niveau de son nœud 101 des anciennes versions de chaînes de blocs pour laquelle la migration est terminée. Toutes les informations relatives transactions antérieures à la migration (antérieure à la période de migration) sont en effet gardées au niveau du nœud de l’administrateur de la BS26 sans qu’il soit nécessaire de conserver au niveau des autres nœuds.
[0176] Après le basculement sur la nouvelle chaîne de blocs secondaire, tout nouvel utilisateur est contraint à utiliser la nouvelle chaîne de blocs secondaire BS26-Y à partir de l’arrêt de l’ancienne chaîne de blocs secondaire BS26-(Y-1) de sorte à pouvoir continuer à utiliser les fonctionnalités associées à cette chaîne de blocs secondaire BS26.
[0177] Dans tous les procédés décrits dans ce document, le master a un rôle de supervision mais ne détermine pas comment les droits sont alloués aux utilisateurs dans les différentes chaînes de blocs secondaires. Le master a donc un rôle déclaratif et de stockage des informations relatives aux chaînes de blocs supervisées.
[0178] Un administrateur d’une chaîne de blocs secondaire pourrait ne pas stocker sur les droits alloués aux utilisateurs dans le master et se baser uniquement sur une gestion interne à la chaîne de blocs secondaire de ces droits pour déterminer quels ont les droits à appliquer. Les droits d’un administrateur sur le master pourraient dans ce cas être retirés.
[0179] Migration du master
[0180] Le master (200) est l’entité qui gère les migrations de chaînes de blocs secondaires dans une même série temporelle de chaînes de blocs secondaires. Techniquement, le master (200) est une chaîne de blocs au même titre que les chaînes de blocs secondaires. Ainsi, le master (200) peut également dépasser une taille maximale limite, par exemple une taille limite tolérée par les utilisateurs. Il peut donc être nécessaire de remplacer le master (200) de la même façon qu’on remplace les chaînes de blocs secondaires.
[0181] Le master (200) courant peut ainsi être remplacé par un nouveau master (200) en suivant le même procédé de migration que les chaînes de blocs secondaires à la seule différence que les données de migration sont autoportées, c’est-à-dire que le master (200) courant stocke lui-même tous les données nécessaires à la migration des utilisateurs du master (200) courant vers le nouveau master (200).
[0182] Dans un ou plusieurs modes de réalisation, les paramètres de création d’un nouveau master (200) contiennent, en plus des paramètres de création décrits pour les chaînes de blocs secondaires, un pointeur vers le master (200) précédent ce qui permet aux utilisateurs ayant eu une activité de mieux recourir à l’historique stocké dans le master (200) précédent en cas de besoin.
[0183] Les divers procédés décrits dans ce document peuvent être mis en œuvre par un ou plusieurs ordinateurs programmés. Ainsi, dans le présent document, certaines représentations sont également destinées à couvrir les dispositifs de stockage de programmes d’ordinateurs, par exemple les supports de stockage de données numériques, qui sont lisibles par une machine ou par un ordinateur et codent des instructions exécutables par une machine ou par un ordinateur, dans lesquels les instructions permettent de mettre en œuvre tout ou partie des étapes des procédés décrits dans ce document.
[0184] Les fonctions des différents éléments représentés dans les figures, y compris les blocs fonctionnels appelés "processeurs", peuvent être assurées par l'utilisation d'un matériel dédié ainsi que d'un matériel capable d'exécuter des logiciels en association avec des logiciels appropriés. Lorsqu'elles sont fournies par un processeur, les fonctions peuvent être fournies par un seul processeur dédié, par un seul processeur partagé ou par plusieurs processeurs individuels, dont certains peuvent être partagés. D'autres matériels, conventionnels et/ou sur spécifiques, peuvent également être inclus.
[0185] Le présent document concerne ainsi un programme d'ordinateur, susceptible d’être exécuté par un ordinateur ou par un processeur de données, ce programme d'ordinateur comprenant des instructions pour commander l'exécution des étapes d'un procédé ou plusieurs des procédés décrits dans ce document.
[0186] Ce programme d'ordinateur peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
[0187] Les instructions sont destinées à être stockées dans une mémoire d’un dispositif informatique 150, 151, 152 afin d’être traitées (lues, interprétées, etc) en vue de leur exécution par un ou plusieurs processeurs de ce dispositif.
[0188] Le dispositif informatique 150, 151, 152 peut être mis en œuvre par une ou plusieurs machines physiquement distinctes. Le dispositif peut présenter globalement l’architecture d’un ordinateur, incluant des composants d’une telle architecture: mémoire(s) de données, processeur(s), bus de communication, interface(s) matérielle(s) pour la connexion de ce dispositif à un réseau ou un autre équipement, interface(s) utilisateur, etc.
[0189] En outre, le terme "processeur" ne doit pas être interprétée comme se référant exclusivement à du hardware capable d'exécuter des logiciels, et peut comprendre des composants purement hardware, un processeur de signaux numériques (DSP), un processeur réseau, un circuit intégré à application spécifique (ASIC), un réseau de portes programmables (FPGA), etc.
[0190] La présente description concerne aussi un support de stockage de données lisible par un ordinateur, transitoire ou non, et comportant des instructions d'un programme d’ordinateur tel que mentionné ci-dessus. Le support de stockage de données peut être n'importe quelle entité ou dispositif capable de stocker le programme d’ordinateur. Par exemple, le support de stockage de données peut comprendre une ou des mémoires ROM ou RAM, une ou des mémoires flash, une ou des mémoires numériques, un ou des supports de stockage magnétiques tels que des disques magnétiques et des bandes magnétiques, des disques durs ou des supports de stockage de données numériques à lecture optique, etc.

Claims

Revendications
1. Procédé de migration d’une chaîne de blocs à remplacer, dite première chaîne de blocs, vers une chaîne de blocs de remplacement, dite deuxième chaîne de blocs, le procédé étant mis en œuvre par un ou plusieurs ordinateurs et comprenant :
- une initialisation (410) de la deuxième chaîne de blocs, l’initialisation comprenant une génération, dans une chaîne de blocs principale configurée pour superviser l’accès aux première et deuxième chaînes de blocs, d’une zone de supervision (250) de la deuxième chaîne de blocs;
- une inscription (420) d’un ou plusieurs utilisateurs auprès de la deuxième chaîne de blocs, l’inscription d’un utilisateur comprenant un enregistrement dans un annuaire (230) d’utilisateurs dans la chaîne de blocs principale d’une adresse secondaire allouée à cet utilisateur pour la connexion à la deuxième chaîne de blocs;
- une génération (430) dans la deuxième chaîne de blocs d’un ensemble de blocs de données correspondant à une image de la première chaîne de blocs, l’image correspondant à un instant déterminé dans l'historique de la première chaîne de blocs ;
- un basculement (450) de tout ou partie des utilisateurs de la première chaîne de blocs vers la deuxième chaîne de blocs de sorte à interdire l’enregistrement de transactions au nom de ces utilisateurs dans la première chaîne de blocs et autoriser l’enregistrement de transactions au nom de ces utilisateurs dans la deuxième chaîne de blocs.
2. Procédé selon la revendication 1, comprenant en outre un enregistrement (440) de nouvelles transactions pour lesquelles une requête d’enregistrement est parvenue auprès de la première chaîne de blocs à la fois dans la première chaîne de blocs et dans la deuxième chaîne de blocs pendant une période dite période miroir avant ledit basculement.
3. Procédé selon la revendication 1 ou 2, dans lequel la zone de supervision (250) de la deuxième chaîne de blocs est configurée pour stocker des droits utilisateurs sur la deuxième chaîne de blocs.
4. Procédé selon l’une quelconque des revendications précédentes, comprenant un basculement définitif vers la deuxième chaîne de blocs par modification des droits des utilisateurs sur la première chaîne de blocs, de sorte que plus aucune transaction ne peut être enregistrée dans la première chaîne de blocs et toute nouvelle transaction est enregistrée uniquement dans la deuxième chaîne de blocs.
5. Procédé selon l’une quelconque des revendications précédentes, dans lequel la première chaîne de blocs est mise en œuvre dans un système de communication comprenant une pluralité de nœuds (100, 101, 102) et une instance de la première chaîne au niveau de chaque nœud, le procédé comprenant, pour au moins un nœud du système de communication, suite au basculement définitif, une suppression de l’instance de la première chaîne de blocs localisée au niveau du nœud considéré.
6. Procédé selon l’une quelconque des revendications précédentes, comprenant une allocation à chaque utilisateur de la deuxième chaîne de blocs d’une adresse multisignée (180) pour la signature de transactions à enregistrer dans la deuxième chaîne de blocs au nom de cet utilisateur, l’adresse multisignée (180) étant générée à partir de l’adresse secondaire allouée à cet utilisateur pour la connexion à la deuxième chaîne de blocs et d’une adresse administrateur de la deuxième chaîne de blocs.
7. Procédé selon la revendication 6, dans lequel l’adresse secondaire allouée à un utilisateur pour la connexion à la deuxième chaîne de blocs est stockée dans l’annuaire (230) d’utilisateurs en association avec l’adresse multisignée (180).
8. Procédé selon l’une quelconque des revendications 6 à 7, dans lequel l’adresse multisignée (180) est utilisée pour enregistrer les nouvelles transactions dans la deuxième chaîne de blocs pendant la période miroir.
9. Procédé selon l’une quelconque des revendications 6 à 8, dans lequel les droits d’un utilisateur sur la deuxième chaîne de blocs sont enregistrés dans la zone de supervision (250) en association avec l’adresse multisignée (180) allouée à cet utilisateur.
10. Procédé selon l’une quelconque des revendications précédentes, dans lequel la génération de l’image de la première chaîne de blocs comprend un enregistrement dans la deuxième chaîne de blocs d’un ensemble de blocs de données représentatifs d’unités d’actifs détenus par un ou plusieurs utilisateurs de la première chaîne de blocs à l’instant déterminé.
11. Procédé selon l’une quelconque des revendications précédentes, comprenant un enregistrement dans la chaîne de blocs principale d’un marqueur pour chaque utilisateur indiquant si cet utilisateur a basculé ou non vers la deuxième chaîne de blocs.
12. Système informatique comprenant des moyens de mise en œuvre du procédé selon l'une quelconque des revendications 1 à 11.
13. Support de stockage de données lisible par un processeur de données sur lequel est enregistré un programme comprenant des instructions pour l'exécution des étapes d'un procédé selon l'une quelconque des revendications 1 à 11.
14. Produit programme d’ordinateur comprenant des instructions pour l’exécution des étapes d’un procédé selon l'une quelconque des revendications 1 à 11 lorsque ledit programme est exécuté par un processeur de données.
EP20757362.7A 2019-09-02 2020-08-21 Migration d'une chaîne de blocs de données Pending EP4026016A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR1909627A FR3100351B1 (fr) 2019-09-02 2019-09-02 connexion à chaîne de blocs de données
FR1909624A FR3100350B1 (fr) 2019-09-02 2019-09-02 migration d’une chaîne de blocs de données
PCT/EP2020/073486 WO2021043599A1 (fr) 2019-09-02 2020-08-21 Migration d'une chaîne de blocs de données

Publications (1)

Publication Number Publication Date
EP4026016A1 true EP4026016A1 (fr) 2022-07-13

Family

ID=72088141

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20757362.7A Pending EP4026016A1 (fr) 2019-09-02 2020-08-21 Migration d'une chaîne de blocs de données

Country Status (3)

Country Link
US (1) US11934386B2 (fr)
EP (1) EP4026016A1 (fr)
WO (1) WO2021043599A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220051129A1 (en) * 2020-08-14 2022-02-17 International Business Machines Corporation Blockchain-enabled model drift management
CN114866560B (zh) * 2022-04-29 2023-12-01 蚂蚁区块链科技(上海)有限公司 区块链节点迁移的方法、装置、电子设备及可读存储介质
US12457264B2 (en) * 2023-05-22 2025-10-28 Verizon Patent And Licensing Inc. Systems and methods for migration of distributed ledger node environments

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7189144B2 (ja) * 2017-04-11 2022-12-13 エヌチェーン ライセンシング アーゲー 動的ノードグループのための秘密鍵のセキュアな再利用
US11240035B2 (en) * 2017-05-05 2022-02-01 Jeff STOLLMAN Systems and methods for extending the utility of blockchains through use of related child blockchains
US11177961B2 (en) * 2017-12-07 2021-11-16 Nec Corporation Method and system for securely sharing validation information using blockchain technology
WO2019142049A1 (fr) * 2018-01-17 2019-07-25 Geeq Corporation Procédés, nœuds, systèmes, et produits associés à des chaînes de blocs
CN108829350B (zh) * 2018-05-31 2020-02-21 阿里巴巴集团控股有限公司 基于区块链的数据迁移方法和装置
US10671315B2 (en) * 2018-08-17 2020-06-02 Bank Of America Corporation Blockchain architecture for selective data restore and migration
US11032292B2 (en) * 2018-09-04 2021-06-08 Allen Gluck Systems and methods for hybrid blockchain control
US12147399B2 (en) * 2018-11-06 2024-11-19 International Business Machines Corporation Migration of a legacy system
US20200162263A1 (en) * 2018-11-15 2020-05-21 Eleven01 International Limited System and method of validation of block chain by secondary chain having incentivization and insurance coverage powered by proof of work
US11025431B2 (en) * 2018-12-31 2021-06-01 Mastercard International Incorporated Method and system for two factor authentication for blockchain transactions
US11734655B2 (en) * 2019-01-17 2023-08-22 Mastercard International Incorporated Method and system for a failsafe mechanism for blockchain wallets
US11044074B2 (en) * 2019-01-22 2021-06-22 Mastercard International Incorporated Method and system for state associated device identification for digital payments using blockchain technology
US11405181B2 (en) * 2019-07-12 2022-08-02 Microsoft Technology Licensing, Llc Lightweight blockchain based on split-trust
US10860259B1 (en) * 2019-07-17 2020-12-08 Tyson York Winarski Multi-tiered storage system for blockchain
US11573780B2 (en) * 2019-08-16 2023-02-07 Red Hat, Inc. Automated generation of status chains for software updates

Also Published As

Publication number Publication date
WO2021043599A1 (fr) 2021-03-11
US20220300488A1 (en) 2022-09-22
US11934386B2 (en) 2024-03-19

Similar Documents

Publication Publication Date Title
EP3676787B1 (fr) Procédés et dispositifs de fourniture de données clé-valeur pouvant être parcourues sur une chaîne de blocs
US11847099B2 (en) Synchronizing content
Ali et al. Blockstack: A new decentralized internet
US11528129B2 (en) Synchronizing content
EP4026016A1 (fr) Migration d&#39;une chaîne de blocs de données
FR3107416A1 (fr) Tokenisation aléatoire efficace dans un environnement dématérialisé
WO2009147357A1 (fr) Procede et systeme de synchronisation de modules logiciels d&#39;un systeme informatique distribue en grappe de serveurs, application au stockage de donnees
Ali et al. Blockstack technical whitepaper
CN114500119A (zh) 区块链服务的调用方法和装置
CN116886758B (zh) 云存储信息安全管理方法、装置、系统及存储介质
FR3100350A1 (fr) migration d’une chaîne de blocs de données
FR3100351A1 (fr) connexion à chaîne de blocs de données
EP2353076A1 (fr) Procede et systeme de stockage virtualise d&#39;un ensemble de donnees numeriques
FR2873219A1 (fr) Procede de sauvegarde distribuee sur des postes clients dans un reseau informatique
EP3903210A1 (fr) Reseau de communication securisee et tracee
US10409780B1 (en) Making a copy of a profile store while processing live updates
FR3022716A1 (fr) Procede de partage de fichiers numeriques entre plusieurs ordinateurs, et ordinateur, ensemble de stockage de donnees et systeme de partage de fichiers numeriques associes
WO2026013504A1 (fr) Procédé pour l&#39;exécution d&#39;un programme d&#39;application au moyen d&#39;un module de sécurité matérielle équipé d&#39;une mémoire sécurisée
FR3164301A1 (fr) Procédé pour l’exécution d’un programme d’application au moyen d’un module de sécurité matérielle équipé d’une mémoire sécurisée.
FR3073061B1 (fr) Procede de communication entre processus, programme d’ordinateur et installation informatique correspondants
FR3147922A1 (fr) Dérivation de clés de preuve pour la gestion d’une infrastructure à clé publique
FR3012900A1 (fr) Procede de protection de metadonnees
WO2009136030A1 (fr) Procede de sauvegarde/restauration de fichiers dans un reseau pair a pair
HK40036621A (en) Methods and devices for providing traversable key-value data storage on blockchain
WO2011039317A1 (fr) Procede de synchronisation d&#39;elements stockes par des dispositifs d&#39;un systeme de communication de type paire a paire

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20220228

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230527

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20241118