Portable bootloader using blockchain

Abstract

A computer implementation method for booting a device using a portable bootloader device, wherein the portable bootloader device comprises a bootloader and operating system files, the blockchain has a bootloader transaction, the bootloader transaction has an output locked to a master public key, the bootloader transaction includes a first signature for signing the bootloader and a second signature for signing the operating system files, and the computer implementation method comprises the steps of: obtaining the bootloader transaction; verifying the first signature using the master public key; verifying the second signature using the master public key; and loading the operating system files using the bootloader.

Description

Technical Field

[0001] The present invention relates to a method for booting a device using a portable bootloader, which utilizes a blockchain and relates to a portable bootloader device such as a USB stick.

Background Art

[0002] Booting is an important process for starting a computing device and includes initialization of hardware components and loading of an operating system into the device's memory. Generally, the main hardware and software components of a device that support the boot process are as follows. · ROM (Read-Only Memory) - A memory for storing built-in programs. · RAM (Random Access Memory) - A memory for storing temporary files. · BIOS (Basic Input / Output System) - A small set of instructions stored in ROM. · CPU (Central Processing Unit) - Executes all programs in ROM and RAM. · OSF (Operating System File) - A file loaded from a hard disk or other hardware to RAM by a bootloader and executed by the CPU. · BL (Bootloader) - A program used to load (OSF) into RAM. · Firmware - Refers to a program closely linked to hardware that includes BIOS.

[0003] The Secure Boot process is widely adopted in the computing industry to prevent unauthorized software from being executed on a computer, protect the computer from various security threats such as malware and viruses, and ensure the integrity and security of the operating system. That is, the Secure Boot process enables the device to boot safely by implementing software trusted by the manufacturer. Figure 3 is an example showing how Secure Boot is executed within a computer. ·PK BS is a public key managed by the manufacturer and used to verify the signature on the BIOS. ·SIG BS is the signature on the BIOS generated by the manufacturer using the secret key related to PK BS PK BL is a public key managed by the manufacturer and used to verify the signature on the bootloader. ·SIG BL is the signature on the bootloader generated by the manufacturer using the secret key related to PK BL

[0004] The Secure Boot process includes the following steps. 1. BIOS verification: When the power-on signal is sent to the CPU, the CPU identifies the BIOS and uses PK BS to verify SIG BS to confirm that the BIOS has not been tampered with. 2. Bootloader verification: After passing the BIOS signature verification, the BIOS checks SIG BL against the public key PK BL stored in the BIOS. If the bootloader is not signed or is signed by an untrusted entity, the Secure Boot process prevents the bootloader from being loaded and executed on the computer. ​3. Operating System Verification: The bootloader checks the digital signature of the OSF to verify that it has not been tampered with. If it is not signed or signed by an untrusted authority, the Secure Boot process prevents it from being loaded into RAM. 4. System Initialization: Once all signatures have been verified and all software is trusted, the operating system is loaded into memory and initialized. Finally, the CPU can execute the operating system files and perform tasks for the user.

[0005] During system initialization, the CPU may use file pointers to access OSF files. A file pointer is a data structure that represents a location within a file. When reading a file, a file pointer can be used to point to a specific location within the file. File pointers have the following advantages: • Efficient data reading: File pointers help determine the current location from which data is being read. • Sequential data access: File pointers allow you to read data sequentially from the beginning to the end of a file. This is useful when dealing with files where the data needs to be processed in a specific order. • Random data access: File pointers allow you to read data from any desired location within a file. This is useful when dealing with large files or databases where you need to access or modify data at a specific location without reading the entire file. [Overview of the project]

[0006] With the rapid development of the Internet of Things (IoT) and the growing demand for privacy and data ownership, users are storing more and more sensitive data on their devices. This makes these devices more vulnerable to attacks, and each attack leads to further damage due to the loss of more information. To protect sensitive data, it is desirable to equip devices with secure and reliable hardware that can implement secure software and operating systems. In particular, a secure boot process is necessary to load trusted applications and software. The boot process is typically implemented by a bootloader, a special program that allows the user to load the operating system into memory. Roughly speaking, the bootloader runs before other user applications stored in memory.

[0007] Booting a device with an insecure bootloader can make it easier to load an insecure operating system. As a result, the device becomes more vulnerable to security threats that can lead to data loss, theft of sensitive information, and unauthorized access.

[0008] Currently, the computing industry generally accepts the use of secure boot mechanisms to prevent unauthorized software or operating systems from running on devices. Typically, devices contain trusted hardware, including the bootloader itself. The bootloader is usually stored on one of the device's hard drives and signed by the original device manufacturer (ODM). However, this makes it difficult for users to update the bootloader or boot a special system on the device.

[0009] To flexibly accommodate user requirements, bootloaders can be stored on external sources such as USB drives, SD cards, and Ethernet-connected devices. Therefore, bootloaders require a secure verification mechanism to prevent malicious code or malware from being introduced onto USB drives or other external devices, and to ensure that the code is verified and updated only from trusted sources.

[0010] Therefore, there is a need for a secure boot protocol using an external (i.e., portable) boot loader device.

[0011] According to one aspect disclosed herein, a computer implementation method is provided for booting a device using a portable bootloader device, wherein the portable bootloader device comprises a bootloader and operating system files, the blockchain comprises a bootloader transaction, the bootloader transaction comprises an output locked to a master public key, the bootloader transaction comprises a first signature for signing the bootloader and a second signature for signing the operating system files, the method comprising the steps of: obtaining the bootloader transaction; verifying the first signature using the master public key; verifying the second signature using the master public key; and loading the operating system files using the bootloader.

[0012] According to one aspect disclosed herein, a computer implementation method is provided for booting a device using a portable bootloader device, wherein the portable bootloader device comprises a bootloader and operating system files, and the method comprises the step of submitting an initial bootloader transaction to a blockchain network, wherein the bootloader transaction comprises an output locked to a master public key, and the bootloader transaction comprises a first signature for signing the bootloader and a second signature for signing the operating system files.

[0013] A portable boot loader (PBL) in this specification refers to an external storage medium (such as a CD / DVD, USB memory stick, or external hard drive) containing a boot loader, from which the user can boot a device. A PBL may be necessary if a device fails to boot due to a virus, system failure, or other reasons. A PBL can also be used for backing up operating system data and / or booting an operating system on one or more devices.

[0014] However, external storage media can make the bootloader vulnerable to risks such as malware and virus infection, unauthorized software execution, data theft, and tampering. To mitigate these risks, embodiments of this disclosure provide a verification mechanism that allows users to check the validity of the portable bootloader and the integrity of the data using blockchain transactions. Furthermore, in some embodiments, the portable bootloader can be revoked, replaced, or updated from a trusted source (such as a blockchain) in the event of loss, theft, or tampering of the media, for example.

[0015] For the sake of brevity, we will use a personal computer as an example of a device and a USB drive as an example of an external source for storing a portable bootloader. However, it will be understood that booting may be required on virtually any device, and other types of portable hardware or storage devices can also be used as portable bootloaders.

[0016] In some embodiments, the verification mechanism is built on top of the aforementioned secure boot protocol and assumes that all computers have a BIOS. This allows the verification mechanism to be seamlessly integrated into the existing boot process. In these embodiments, the existing process is used to download the boot loader and operating system to a USB drive. Brief Description of the Drawings: To aid in understanding the embodiments of this disclosure and to illustrate how such embodiments are carried out, the accompanying drawings are provided for reference as examples. [Brief explanation of the drawing]

[0017] [Figure 1] This is a schematic block diagram of a system for implementing blockchain. [Figure 2] This diagram schematically illustrates examples of transactions that may be recorded on the blockchain. [Figure 3] This diagram schematically illustrates an example of the Secure Boot protocol. [Figure 4] This diagram schematically illustrates an example of a system that boots a device using a portable bootloader. [Figure 5] This figure shows a more detailed example of the system shown in Figure 4. [Modes for carrying out the invention]

[0018] 1. Portable Bootloader Figure 4 shows an example of a system 400 that boots device 401 using a portable bootloader 402. Generally, device 401 can be any type of computing device running an operating system. For example, device 401 could be a desktop or laptop computer, a mobile device such as a cell phone or tablet, or an IoT device such as a sensor. The portable bootloader 402 can be any portable storage device such as a USB drive, CD or DVD, portable hard drive, flash drive, or memory card. In some examples, the portable storage device 402 could be a smartphone, tablet, or laptop. System 400 also includes a user 103a. For convenience, user 103a is referred to as Alice 103a. Generally, user 103a can be configured to perform any actions described below as being performed by Alice 103a and / or Bob 103b, referring to Figures 1 and 2. System 400 includes one or more blockchain nodes 104 of a blockchain network 106.

[0019] In some embodiments, the Portable Bootloader (PBL) 402 stores the operating system files and a bootloader configured to load the operating system files into the device's memory. The PBL 402 also stores Alice's public key (i.e., the public key corresponding to the private key owned (i.e., accessible) by Alice 103a). The PBL 402 also stores two signatures. The first signature signs messages containing the bootloader. The first signature is generated using Alice's private key associated with a public key authenticated using a master public key. The master public key is owned by a trusted third party, such as a Certificate Authority (i.e., a trusted authority that issues certificates for public keys) or the manufacturer of device 401. The master public key is stored in device 401. The certificate for Alice's authenticated public key is also stored in the PBL 402. The second signature signs messages containing the operating system files and is generated using the private key associated with Alice's public key, or a trusted public key (e.g., the Certificate Authority's public key, the device manufacturer's public key, or the publisher of the operating system files). The transaction identifier (TxID) of the blockchain transaction ("bootloader transaction") is also stored in PBL402. Transactions recorded on blockchain 150 include outputs (e.g., P2PK or P2PKH) locked to Alice's public key.

[0020] In these embodiments, PBL402 is connected to device 401, and when device 401 is booted (for example, by Alice 103a), device 401 is configured to extract the certificate and first and second signatures from PBL402. Device 401 verifies the extracted certificate using the master public key; that is, device 401 verifies that the certificate is signed with a signature generated using the private key corresponding to the master public key, or contains such a signature. Device 401 may also verify that the certificate certifies Alice's public key (i.e., was issued for Alice). This includes verifying that the certificate contains Alice's public key. Device 401 also verifies the first signature using Alice's public key and the second signature using Alice's public key or a trusted public key. Those skilled in the art will be familiar with the signature verification itself. If any verification fails, device 401 aborts the boot operation.

[0021] If verification is successful, device 401 retrieves the bootloader transaction using the TxID stored in PBL402. For example, device 401 can retrieve the bootloader transaction directly from the blockchain (e.g., by sending a transaction request to blockchain node 104) or via a service provider. Device 401 verifies that the output of the bootloader transaction locked in Alice's public key is unconsumed, i.e., not allocated. This involves requesting the status of the output from blockchain node 104 and / or the service provider. If the output is unconsumed, device 401 continues the boot operation by loading the operating system files. If the output is consumed, device 401 aborts the boot operation. The output may be used by invalid transactions (e.g., Alice 103a sends to blockchain 150) to prevent device 401 from booting using the bootloader and operating system files stored in PBL402.

[0022] In some examples, the bootloader transaction or PBL402 contains a file address (e.g., a pointer). Device 401 uses this file address to locate one or more operating system files and executes the identified file.

[0023] The bootloader transaction may contain a hash of a file address. Device 401 hashes the file address (obtained from PBL402 or the bootloader transaction) and compares the result to the hash stored in the bootloader transaction. In these examples, device 401 identifies and executes the file only if the hashes match.

[0024] Similarly, a bootloader transaction may contain a hash of the operating system file. Device 401 calculates the hash of the operating system file obtained from PBL402 and compares the result to the hash stored in the bootloader transaction. In these examples, device 401 loads and / or executes the operating system file only if the hashes match.

[0025] Boot loader transactions are generated by Alice 103a or the owner of the master public key (e.g., the device manufacturer). Information stored in PBL402 is stored by Alice 103a or the owner of the master public key (e.g., the device manufacturer).

[0026] In other embodiments, PBL402 stores the operating system files and a bootloader configured to load the operating system files into the memory of device 401. The transaction identifier (TxID) of a blockchain transaction ("bootloader transaction") is stored in PBL402 or device 401. Transactions recorded on blockchain 150 include output (e.g., P2PK or P2PKH) locked to a master public key. The master public key is owned by a trusted third party, such as a certificate authority or the device manufacturer. The master public key is stored in device 401 or PBL402. A bootloader transaction includes two signatures. The first signature signs the message containing the bootloader and is generated using the master private key corresponding to the master public key. The second signature signs the message containing the operating system files and is generated using the master private key.

[0027] In these embodiments, when PBL402 is connected to device 401 and device 401 is booted (for example by Alice 103a), device 401 is configured to use the TxID to obtain the bootloader transaction and extract the first and second signatures from the transaction. The bootloader transaction can be obtained in any of the aforementioned ways. Device 401 verifies the first and second signatures. If verification fails, device 401 aborts the boot operation. If verification is successful, device 401 extracts the bootloader and operating system files from PBL402 and loads the operating system files using the bootloader.

[0028] In some examples, the bootloader transaction or PBL402 contains a file address (e.g., a pointer). Device 401 can use this file address to locate one or more operating system files and execute the located files.

[0029] In some examples, the TxID stored in device 401 or PBL402 is the transaction identifier of a transaction belonging to a chain of bootloader transactions, starting with the first bootloader transaction and ending with the last (or most recent) bootloader transaction. Device 401 can use the stored TxID to retrieve one of the bootloader transactions (e.g., the first bootloader transaction) and determine that the output of the transaction locked to the master public key is being used (e.g., by querying blockchain node 104 or the storage service provider). Device 401 can retrieve the most recent bootloader transaction and boot device 401 using the bootloader and operating system files stored in that most recent transaction. Device 401 can also obtain a transaction chain certificate (e.g., from a trusted service provider) to verify that the most recent bootloader transaction is linked on the chain to the initial bootloader transaction. This updates the bootloader and / or operating system files, allowing device 401 to use the updated versions. In some examples, the TxID stored in device 401 or PBL402 is the transaction identifier of the initial bootloader transaction.

[0030] A bootloader transaction can be generated by Alice 103a or the owner of the master public key (e.g., the device manufacturer). Information stored in PBL402 can be stored by Alice 103a or the owner of the master public key (e.g., the device manufacturer). The owner of the master public key sends an initial bootloader transaction containing the initial bootloader and initial operating system files to blockchain 150. The owner of the master public key can then consume the output of the initial bootloader transaction and send an updated bootloader transaction containing the updated bootloader and / or updated operating system files to blockchain 150. The updated bootloader transaction contains the output locked in the master public key. This process of updating the bootloader and / or operating system files can be repeated once or multiple times.

[0031] In other embodiments, PBL402 stores a boot loader configured to load operating system files into the memory of device 401, where the operating system files are stored. PBL402 also stores Alice's public key (i.e., the public key corresponding to the private key owned (i.e., accessible) by Alice 103a). PBL402 also stores a first signature generated using the private key corresponding to Alice's public key, which signs the message containing the boot loader. The transaction identifier (TxID) of the blockchain transaction ("boot loader transaction") is also stored in PBL402. Transactions recorded on blockchain 150 include Alice's public key. For example, a boot loader transaction may include output locked to Alice's public key.

[0032] In these embodiments, when PBL402 is connected to device 401 and device 401 is booted (for example by Alice 103a), device 401 is configured to use the TxID (extracted from PBL402) to obtain a bootloader transaction, for example, via a blockchain node 104 or a service provider. Device 401 verifies that Alice's public key stored in PBL402 matches the public key stored in the transaction. Device 401 also verifies the first signature using Alice's public key. If verification fails, device 401 aborts the boot operation. If verification is successful, device 401 extracts the bootloader from PBL402 and uses that bootloader to load the operating system files. In some examples, the bootloader transaction and / or PBL402 store file addresses, and device 401 uses the file addresses to find one or more operating system files and execute the found files. Alternatively, the entire file can be executed.

[0033] In some examples, operating system files are stored on device 401 in an encrypted format. The appropriate encryption format is arbitrary. In this case, device 401 first decrypts the file before reading it. For example, the file is encrypted with Alice's public key, and device 401 uses Alice's private key to decrypt the file.

[0034] Device 401 can perform one or more additional checks before loading and / or executing operating system files.

[0035] For example, a bootloader transaction might contain a bootloader hash. Device 401 calculates the bootloader hash obtained from PBL402 and compares the result to the hash stored in the bootloader transaction. In these examples, device 401 loads and / or runs the operating system files only if the hashes match.

[0036] Similarly, a bootloader transaction may contain a hash of an operating system file. Device 401 calculates the hash of the operating system file stored on device 401 and compares the result to the hash stored in the bootloader transaction. In these examples, device 401 loads and / or executes the operating system file only if the hashes match.

[0037] In an example where the bootloader transaction includes output locked to Alice's public key, device 401 can verify that the output is untapped by querying, for example, blockchain node 104 or the service provider. In these examples, device 401 will only load and / or execute the operating system files if the output is untapped.

[0038] Bootloader transactions may be generated by Alice 103a. Information stored in PBL402 may be stored by Alice 103a. Alice 103a may invalidate the bootloader by sending a transaction to blockchain 150 that consumes the output of the bootloader transaction.

[0039] 1.1 Example Mechanism 1 - Public Key Infrastructure (PKI) This section provides specific examples of how to verify a portable bootloader and the operating system it contains.

[0040] 1.1.1 Verification of the portable bootloader PK stored in the BIOS by the device manufacturer BL This can be considered the master public key of the bootloader. The manufacturer authenticates a trusted service provider and the PK BL Use the user's public key PK user Authenticate and certificate

number

number

number

number

[0041] PK userThis is used for blockchain transactions, as shown in Table 1 below. This transaction is used for operating system verification. In the lock script, the hash value H(0SF) of the OSF and a file pointer are included as a data payload after the OP_RETURN opcode, for example. This point address is associated with the memory address that stores the loaded OSF in RAM. The output is fixed by the user, hence the PK. user Only can it be consumed. The output value can be set to the "dust" value x, which is the minimum amount that blockchain node 104 will accept. When the transaction is published to blockchain 150, the user will have a PK. user Related information includes the transaction identifier TXID. PBL It can be sent and authenticated by the service provider. [Table 1]

[0042] The hash value of the file pointer is stored in the transaction, and the file pointer itself is stored on the USB drive. Furthermore, the file pointer may be any other type of data structure that the user can use to specify the location of the OSF that the CPU needs to read first.

[0043] 1.1.2 Operating System Verification A USB drive contains some or all of the following information: ·

number

[0044] The OSF verification mechanism is implemented as follows: The boot loader is PK user Using SIG user-OSF Verify. SIG user-OSF If enabled, the bootloader loads OSF into RAM. When the CPU executes OSF, it first uses TXID. PBL It is necessary to identify the TXID and request a trusted service provider to check if it is being used. If it is being used, the CPU will abort without executing OSF. If it is not being used, the CPU will terminate the TXID. PBL The pointer address and H(0SF) can be extracted from this. The CPU uses the pointer address to identify the file in RAM. The CPU calculates the hash value of the identified file and compares it to H(0SF). If they match, the CPU executes the identified OSF. If they do not match, the computer aborts.

[0045] TXID as part of the bootloader operation PBL Using it offers at least the following advantages: 1. PK user If the private key associated with the TXID is compromised, the user will lose their TXID PBL Consume PK user This can be disabled. This also applies if the PBL USB drive is stolen. However, the attacker can compromise the PK user Use TXID at any time PBL Note that it can be replaced. This allows the attacker to replace TXID PBL This allows you to bypass the check. TXID PBL To avoid replacement, the user should use TXID PBL of

number

number

[0046] Figure 5 provides an overview of how a portable boot loader boots an operating system according to this example.

[0047] 1.2 Example Mechanism 2 - Transaction ID on BIOS This section provides specific examples of how to verify a portable bootloader and the operating system it contains.

[0048] In contrast to the PKI mechanism mentioned earlier, the mechanism described in this section uses blockchain transaction TXID instead of BIOS. BL Use PK BL and SIG BL Stores the blockchain transaction TXID. BL (See Table 2 below) The public key PK is published by the manufacturer. BL It contains output that can only be used by the manufacturer, identified by SIG. BL and SIG user-OSF This is included as data payload, for example, after the OP_RETURN opcode.

[0049] In this example, device 401 (such as a computer) connects to the network and uses TXID BLIdentify the TXID. This can also be done by the manufacturer through a trusted service provider. This mechanism gives the manufacturer the flexibility to update the bootloader and OSF without modifying the BIOS. The manufacturer identifies the TXID. BL A new blockchain transaction can be published that consumes the output and pays for a new public key linked to the manufacturer, and this new transaction includes the updated bootloader and / or OSF. The BIOS is TXID BL Check if it has been consumed. If not, retrieve the necessary information. If it has been consumed, contact a trusted service provider for the TXID. BL Request that they provide the latest UTXO and proof of the transaction chain linked to it. Additionally, in this example, the TXID BL By checking the consumption status, transparency is provided so that users can see whether the bootloader has been updated. [Table 2]

[0050] 1.2.1 Verification This mechanism allows the USB drive to store only the boot loader and OSF. When the PBL USB drive is connected to the computer, the valid BIOS connects to network 106 and TXID BL Identify the PK from the transaction. BL SIG BL , and SIG OSF Obtain the TXID. BL If it is consumed, the BIOS will tell a trusted service provider the TXID BL Identify the most recent unconsumed transaction related to the consumption chain and request proof of the transaction chain for verification. This will allow the user to capture the updated bootloader and the latest public key and signature of the OSF. PK BL SIG BL and SIG OSFThis is used to verify that the BL and OSF stored on the USB have not been tampered with. If all signatures are valid, the BL and OSF are trustworthy. The OSF is then loaded into RAM.

[0051] Compared to PKI solutions, TXID-based solutions reduce the data size stored on USB drives. Furthermore, manufacturers can easily update the bootloader. Users can check the bootloader update status and boot OSF on any computer device using the USB drive.

[0052] 1.3 Discussion on Security and Restrictions The portability of the device gives users the flexibility to boot the device 401 or load the operating system onto other devices. However, this increases the risk of theft, loss, and tampering.

[0053] The verification mechanisms described above can be used to mitigate risks even if the portable bootloader is stolen and tampered with. PKI or TXID solutions guarantee the authenticity of the bootloader. Furthermore, blockchain transactions may include hash values ​​for the PBL and OSF. Because the blockchain is immutable, if someone other than the original user tampers with the PBL USB drive, the hash match or signature verification will fail. In addition, these verification mechanisms prevent the implementation of a fake portable bootloader created by a malicious actor, as the BIOS verifies its validity before bootloader execution.

[0054] 1.4 Dedicated portable boot loader Typically, bootloaders are designed by trusted manufacturers and associated with operating systems. This section describes an example of a user creating a portable bootloader for a custom operating system. The operating system may be encrypted and stored on the computer's hard drive. This allows the operating system to be booted using the custom bootloader. Blockchain transaction TXID PBL This will be made public on the blockchain. Transaction TXID PBL The network address used to identify it may be stored on the hard disk.

[0055] A PBL USB drive contains some or all of the following information: • BL - A boot loader designed by the user and stored on a USB drive. H(PBL) - The hash value of BL. PK PBL - User-generated public key. · SIG H(PBL) -H(PBL) signature, user private key Priv PBL Sign using [this method]. TXID PBL - Transaction ID.

[0056] The verification mechanism is implemented as follows: The BIOS may start the BIOS verification process as described above. If the BIOS verification is successful, the BIOS will detect the hard disk, find the network address, connect to the network address, and set the TXID. PBL Identify the TXID. If the connection fails, an error message is returned and the BL will not run. PBL A check is performed to determine if the TXID is equal to the transaction ID stored on the USB drive. If they are equal, the CPU proceeds to the next step. If they are not equal, it pauses and returns an error message. PBL From the lock script to PKPBL H(PBL) and H(SF) are extracted. A check is performed to determine if the retrieved public key and hash value are equal to those stored on the USB drive. If they are equal, the CPU retrieves the stored signature SIG. H(PBL) PK PBL and continues verification against the PBL. If the stored signature is valid, the boot loader identifies the encrypted OSF from the hard disk. The OSF is decrypted. If decryption fails, the boot process stops and returns an error message. The hash value of the decrypted OSF is calculated and the TXID is entered. PBL It is compared with H(0SF) captured from [source]. If they match, OSF is transferred to RAM.

[0057] Portability allows users to easily update the bootloader. Furthermore, blockchain transactions can be used to verify the integrity of the portable bootloader's data. If it has been tampered with, the user will not connect it to the target computer and boot the proprietary operating system. In other words, security is enhanced because a malicious attacker attempting to access the proprietary operating system would need to obtain the portable bootloader, the target computer, and the decryption key associated with the proprietary operating system.

[0058] 2. Device Operation Some embodiments of this disclosure relate to operating a device using (or at least based on data stored on) a blockchain 150. The device can take any form, such as a computer machine 102. In some examples, the device is a mobile device such as a mobile phone or tablet.

[0059] A blockchain transaction (hereinafter referred to as a "data transaction") is created and sent to blockchain 150. A data transaction consists of data (also called data items) that is used to operate the device, or at least affects the operation of the device. For example, a data item may cause the device to load or "boot" (as in the embodiments described above). For example, a data item may consist of a boot loader that causes the device to retrieve and / or execute the boot loader (stored in or elsewhere on the device) (i.e., as a trigger). A data item may also cause the device to update, for example, one or more software modules of the device (i.e., as a trigger). For example, a data item may consist of an update that is executed that causes the device to retrieve and / or execute one or more updates (stored in or elsewhere on the device) (i.e., as a trigger).

[0060] Data transactions may be created by the device manufacturer or distributor, the device user, or the creator or distributor of data items (such as a software company) and sent to Blockchain 150.

[0061] References to data transactions are stored on the device. For example, the transaction identifier (TxID) of a data transaction can be used as a reference. Any appropriate reference can be used, such as the block height of the block containing the data transaction or the index of the transaction within that block. If the data transaction contains a public key or public key hash, that can be used as a reference.

[0062] The device is configured to retrieve data transactions using a reference, for example, by sending a request for a data transaction to blockchain node 104 or by searching for a data transaction in blockchain 150. The device may also be configured to retrieve data transactions when powered on (or after a certain period of use), when a specific action is performed on the device (for example, by the user of the device), or at a specific time and / or date.

[0063] References to data transactions may be stored in the device's hardware, such as the device's CPU. References may also be stored in the device's secure hardware, such as a secure enclave or trusted execution environment. In some examples, references may be stored in the SIM card (subscriber identification module) of a mobile device.

[0064] When a data transaction is acquired, the device is configured to operate based on the data items. That is, the device extracts the data items from the data transaction and operates (i.e., performs actions) based on those data items. For example, as mentioned above, these actions include booting, loading programs, and updating programs or software modules.

[0065] Data items stored in a data transaction can be encrypted. A device can be configured to decrypt data items. The necessary decryption key is stored within the device, for example, in the device's secure hardware.

[0066] In some examples, a device can determine that a second data transaction references a first data transaction on blockchain 150. The second data transaction contains a second data item. In this case, the device retrieves the second data transaction, extracts the second data item, and is configured to act based on the second data item, for example, by performing an additional update operation.

[0067] 3. Example of a system overview A blockchain is a form of decentralized data structure in which duplicate copies of the blockchain are maintained on each of several nodes within a decentralized peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network") and are widely publicized. A blockchain consists of a chain of data blocks, each containing one or more transactions. Each transaction, other than so-called "coinbase transactions," points to a preceding transaction in a sequence, which can span one or more blocks and trace back to one or more coinbase transactions. Coinbase transactions will be discussed further below. Transactions submitted to the blockchain network are included in a new block. New blocks are created through a process often called "mining," which involves each of several nodes competing to perform "proof of work," that is, solving a cryptographic puzzle based on a defined representation of an ordered, validated, and unprocessed set of transactions waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned on some nodes, and block publication may be achieved through the publication of only the block header.

[0068] Transactions in a blockchain can be used for one or more purposes, such as moving digital assets (i.e., a certain number of digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or ordering index pointers in time. Blockchains can also be leveraged to overlay additional functionality on top of them. For example, blockchain protocols can enable the storage of additional user data or indexing of data within transactions. Since there is no predetermined limit on the maximum amount of data that can be stored within a single transaction, increasingly complex data can be incorporated. For example, this can be used to store electronic documents or audio or video data on a blockchain.

[0069] In the "output-based" model (sometimes called the UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Every consumable output comprises an element specifying the amount of digital asset that can be derived from the preceding sequence of the transaction. Consumable outputs are sometimes called UTXOs ("unconsumed transaction outputs"). Outputs may further comprise a locking script that specifies the conditions for the future redemption of the output. A locking script is a predicate that defines the conditions necessary to validate and transmit digital tokens or assets. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such an output in a preceding transaction and may further comprise an unlocking script to unlock the locking script of the pointed-to output. Thus, we consider pairs of transactions, which we call the first transaction and the second transaction (or "target" transaction). The first transaction comprises at least one output specifying the amount of digital asset and a locking script that defines one or more conditions for unlocking the output. The second target transaction has at least one input, which is a pointer to the output of the first transaction and a lock release script for unlocking the output of the first transaction.

[0070] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded on the blockchain, one of the legitimacy criteria applied at each node is that the unlock script satisfies all one or more conditions defined in the lock script of the first transaction. Another criterion is that the output of the first transaction has not yet been redeemed by another earlier, legitimate transaction. Any node that finds the target transaction to be fraudulent according to any of these conditions will not propagate the target transaction (not as a legitimate transaction, but possibly to register a fraudulent transaction), nor will it include the target transaction in a new block to be recorded on the blockchain.

[0071] An alternative type of transaction model is the account-based model. In this case, each transaction is defined not by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but by referring to the absolute balance of the account. The current state of all accounts is stored separately on the blockchain by multiple nodes and is constantly updated.

[0072] Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may comprise a packet-switched network 101, typically a wide-area internet such as the internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104, which may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a near-complete graph, so that each blockchain node 104 is highly connected to other blockchain nodes 104.

[0073] Each blockchain node 104 is equipped with the computer equipment of its peers, and different nodes of node 104 belong to different peers. Each blockchain node 104 is equipped with one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or processing units comprising field-programmable gate arrays (FPGAs), as well as other equipment such as application-specific integrated circuits (ASICs). Each node also has memory, i.e., computer-readable storage in the form of non-temporary computer-readable media. The memory may comprise one or more memory units utilizing one or more memory media, such as magnetic media such as hard disks, solid-state drives (SSDs), electronic media such as flash memory or EEPROMs, and / or optical media such as optical disc drives.

[0074] Blockchain 150 comprises a chain of data blocks 151, and each copy of blockchain 150 is maintained in each of the multiple blockchain nodes 104 within the decentralized network or blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean storing blockchain 150 completely. Instead, blockchain 150 can be pruned in terms of data, as long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction refers to some kind of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout.

[0075] Each blockchain node 104 is configured to forward transaction 152 to other blockchain nodes 104, thereby allowing transaction 152 to spread throughout the network 106. Each blockchain node 104 is configured to create block 151 and store each copy of the same blockchain 150 in its own memory. Each blockchain node 104 also maintains an ordered set (or “pool”) 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is often referred to as the “mempool”. In this specification, this term is not limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that a node 104 has accepted as legitimate, and for which node 104 is not obligated to accept other transactions that seek to consume the same output.

[0076] In a given current transaction 152j, its (or each) input contains a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "consumed" in the current transaction 152j. Consuming or redeeming is certainly one common use, but it does not necessarily mean the transfer of a financial asset. More generally, consumption can be described as consuming an output or assigning it to one or more outputs in another subsequent transaction. Generally, a preceding transaction can be any transaction in an ordered set 154 or any block 151. The preceding transaction 152i does not necessarily exist when the current transaction 152j is created or even when it is sent to the network 106, but for the current transaction to be valid, the preceding transaction 152i must exist and be validated. Therefore, in this specification, "preceding" refers to something that precedes a logical sequence linked by pointers, and does not necessarily refer to the time of creation or transmission in chronological order, and does not necessarily exclude the possibility that transactions 152i and 152j may be created or transmitted in a different order (see the following discussion on orphan transactions). The preceding transaction 152i may be equivalently called an ancestor transaction or predecessor transaction.

[0077] Due to the resources involved in verifying and publishing the validity of transactions, each of the blockchain nodes 104 typically takes the form of a server with one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal, or a group of user terminals connected together to the network.

[0078] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 in order to perform its respective role and handle transaction 152 in accordance with the blockchain node protocol. It will be understood herein that any action attributed to blockchain node 104 may be performed by software running on the processing unit of the respective computer equipment. Node software may be implemented in one or more applications at the application layer, or in lower layers such as the operating system layer or protocol layer, or in any combination thereof.

[0079] Any given blockchain node can be configured to perform one or more of the following actions: transaction verification, transaction storage, transaction propagation to other peers, and consensus (e.g., proof-of-work) / mining actions. In some examples, each type of action is performed by a different node 104; that is, a node can specialize in a particular action. For example, node 104 can specialize in transaction verification and propagation, or in block mining. In some examples, blockchain node 104 can perform multiple processes of these actions in parallel. A reference to blockchain node 104 may refer to an entity configured to perform at least one of these actions.

[0080] Each computer device 102 of the multiple parties 103, who act as consuming users, is also connected to the network 101. These users can interact with the blockchain network 106, but do not participate in validating transactions or building blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store a copy of the blockchain 150 (for example, by obtaining a copy of the blockchain from a blockchain node 104).

[0081] Some or all of the parties 103 may be connected as part of a different network, such as a blockchain network 106 superimposed on it. Users of the blockchain network (often called “clients”) are sometimes said to be part of the system including the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each party 103 may utilize the blockchain 150 by interacting with the blockchain network 106 and thereby connecting to (i.e., communicating with) the blockchain network 106. Two parties 103 and their respective devices 102, namely the first party 103a and its respective computer device 102a, and the second party 103b and its respective computer device 102b, are shown for illustrative purposes. It will be understood that more such parties 103 and their respective computer devices 102 may be present and participate in the system 100 but are not shown for convenience. Each party 103 may be an individual or an organization. For illustrative purposes only, the first party 103a is referred to herein as Alice and the second party 103b as Bob, but this is not limiting, and it will be understood that any reference herein to Alice or Bob may be replaced by “the first party” and “the second party,” respectively.

[0082] Each computer device 102 of Party 103 comprises a processing unit comprising one or more processors, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each computer device 102 of Party 103 further comprises memory, i.e., computer-readable storage in the form of a non-temporary computer-readable medium. This memory may comprise one or more memory units utilizing one or more memory media, for example, magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory of each computer device 102 of Party 103 stores software comprising each entity of at least one client application 105 configured to run on the processing unit. It will be understood that any action attributed herein to a given Party 103 can be performed using the software running on the processing unit of each computer device 102. Each computer device 102 of Party 103 comprises at least one user terminal, for example, a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment 102 of a given party 103 may also include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

[0083] The client application 105 is initially provided to the computer equipment 102 of any given party 103 on a suitable computer-readable storage medium, which may be downloaded from a server and provided on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or removable optical drive.

[0084] The client application 105 has at least a “wallet” function. This has two main functions. One is to enable each party 103 to create, authorize (e.g., sign) a transaction 152 and send it to one or more Bitcoin nodes 104 so that the transaction 152 is disseminated throughout the network of blockchain nodes 104 and thereby included in blockchain 150. The other is to report to each party the amount of digital assets that each party currently owns. In an output-based system, the second function is to match the amounts defined in the outputs of various transactions 152 scattered throughout blockchain 150 that belong to the party in question.

[0085] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limited, and any client function described herein may instead be implemented in a suite of two or more separate applications, for example, interfaced via an API, or one being a plug-in to the other. More generally, client functions may be implemented in the application layer, lower layers such as the operating system, or any combination thereof. The following description will be based on client application 105, but it should be understood that this is not limited.

[0086] Each computer device 102, an entity of a client application or software 105, is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact the blockchain node 104 to inquire about any transaction to which each party 103 is the recipient (or, in an embodiment, to actually investigate the transactions of other parties on blockchain 150, since blockchain 150 is a public institution that brings credibility to transactions by being publicly visible in part). The wallet function of each computer device 102 is configured to organize and send transaction 152 according to the transaction protocol. As stated above, each blockchain node 104 runs software configured to validate transaction 152 according to the blockchain node protocol and to forward transaction 152 to propagate transaction 152 throughout the blockchain network 106. Transaction protocols and node protocols correspond to each other; a given transaction protocol is associated with a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in blockchain 150. The same node protocol is used by all nodes 104 in network 106.

[0087] An alternative type of transaction protocol operated by some blockchain networks may be called an “account-based” protocol as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred not by referencing the UTXO of a preceding transaction in a sequence of past transactions, but by referencing the absolute balance of the account. The current state of all accounts is stored separately on the blockchain by the nodes of that network and is constantly updated. In such a system, transactions are ordered using the account’s transaction execution record (also called a “position”). This value is signed by the sender as part of the sender’s cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be the signed transaction. This data field may point to a previous transaction, for example, if a previous transaction ID is included in this data field.

[0088] Some account-based transaction models share some similarities with the output-based transaction models described here. For example, as mentioned earlier, the data fields in an account-based transaction may reference previous transactions. This is equivalent to the input in an output-based transaction referencing the output point of a previous transaction. Thus, both models enable links between transactions. As another example, an account-based transaction may include a "Recipient" field (specifying the account's receiving address) and a "Value" field (where the amount of the digital asset can be specified). The recipient and value fields, combined, are equivalent to the output in an output-based transaction and can be used to assign the amount of the digital asset to a blockchain address. Similarly, an account-based transaction may have a "Signature" field containing the transaction's signature. This signature is generated using the sender's private key and confirms that the sender has approved this transaction. This is typically equivalent to the input / unlock script in an output-based transaction that includes the transaction's signature. Once both types of transactions are sent to their respective blockchain networks, the signatures are checked to determine whether the transaction is valid and recordable on the blockchain. In account-based blockchains, a “smart contact” refers to a transaction that contains a script configured to perform one or more actions (for example, sending or “releasing” a digital asset to a recipient’s address) in response to one or more inputs (provided by the transaction) that satisfy one or more conditions defined in the smart contact’s script. Smart contracts exist as transactions on the blockchain and are invoked (or triggered) by subsequent transactions.Therefore, in some examples, a smart contract can be considered equivalent to a locking script for an output-based transaction, which is triggered by a subsequent transaction and checks whether the input of the subsequent transaction satisfies one or more conditions defined in the locking script.

[0089] 4. UTXO base model Figure 2 shows an exemplary transaction protocol, which is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 contains one or more transactions 152). The following description will refer to the output-based or "UTXO"-based protocol. However, this is not a limitation to all possible embodiments. While the exemplary UTXO-based protocol is described with reference to Bitcoin, it should be noted that it can be equally implemented on other exemplary blockchain networks.

[0090] In the UTXO-based model, each transaction ("Tx") 152 comprises a data structure having one or more inputs 202 and one or more outputs 203. Each output 203 may have an unconsumed transaction output (UTXO), which can be used as a source for the inputs 202 of another new transaction (if the UTXO has not yet been redeemed). The UTXO contains a value specifying the amount of the digital asset, which represents a set number of tokens on the distributed ledger. The UTXO may also contain, among other information, the transaction ID of the transaction from which it originates. The transaction data structure may also have a header 201, which may indicate the sizes of the input fields 202 and the output fields 203. The header 201 may also contain the ID of the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to node 104.

[0091] Suppose Alice 103a wants to create transaction 152j to transfer the amount of the target digital asset to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". It has the amount of the digital asset locked in Alice in output 203 of the preceding transaction 152i in the sequence, and transfers at least a portion of this to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in blockchain 151, nor that Tx1 is the next transaction in pool 154. Tx1 could point to any preceding (i.e., ancestor) transaction that still has the unspent output 203 locked in Alice.

[0092] In the context of transaction sequences, the terms “preceding” and “successor” as used herein refer to the order of transactions in a sequence as defined by the transaction pointers specified in the transaction (e.g., which transaction points to which other transaction). They can be equally replaced with “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. It does not necessarily imply the order in which they are created, the order in which they are sent to network 106, or the order in which they reach any given blockchain node 104. Nevertheless, a successor transaction (descendant transaction or “child”) pointing to a preceding transaction (ancestor transaction or “parent”) will not be validated until the parent transaction has been validated, and unless it has been validated. A child that reaches blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a period of time to wait for its parent.

[0093] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a specific UTXO, here labeled UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO, and a lock script defining conditions that must be met by the unlock script in the subsequent transaction's input 202 for the subsequent transaction to be validated and thus for the redemption of the UTXO to be successful.

[0094] A lock script (also known as scriptPubKey) is code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (uppercase S), used by blockchain networks. The lock script specifies what information is needed to consume transaction output 203, for example, the requirements for Alice's signature. The unlock script appears in the transaction output. The unlock script (also known as scriptSig) is code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it might include Bob's signature. The unlock script appears in transaction input 202.

[0095] Therefore, in the example shown, UTXO0 in output 203 of Tx0 is the lock script [Checksig P A This includes Alice's signature Sig P, which is necessary for the UTXO0 to be redeemed (more precisely, for subsequent transactions attempting to redeem the UTXO0 to be legitimate). A [Checksig P A ] is the public key P from Alice's public key-private key pair. AThe input 202 of Tx1 includes a representation (i.e., a hash). The input 202 of Tx1 includes a pointer that points to Tx1 (for example, by transaction ID TxID0, where in an embodiment TxID0 is the hash of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies the UTXO0 in Tx0 in order to identify the UTXO0 from all other possible outputs of Tx0. The input 202 of Tx1 further includes a lock release script <Sig P A > comprises Alice's cryptographic signature, which is created by Alice applying her private key from a key pair to a predetermined portion of the data (sometimes called a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a lock script, by a node protocol, or a combination thereof.

[0096] When a new transaction Tx1 reaches blockchain node 104, that node applies the node protocol. This involves executing both the lock script and the unlock script to check whether the unlock script satisfies the conditions defined in the lock script (which may consist of one or more criteria).

[0097] It should be noted that script code is often expressed in a general way (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the Script language. For example, OP_RETURN is a Script language opcode that, when preceded by OP_FALSE at the beginning of a lock script, creates an immutable output of the transaction that can store data within the transaction, thereby immutably recording the data on blockchain 150. For example, the data may consist of documents that are desired to be stored on the blockchain.

[0098] Typically, the input to a transaction is the public key P. A This includes a corresponding digital signature. In embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific part of the output that the digital signature signs depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that selects (and is therefore fixed at the time of signing) which outputs to sign.

[0099] A lock script is sometimes called a "scriptPubKey," which relates to the fact that the lock script typically contains the public key of the party to which each transaction is locked. An unlock script is sometimes called a "scriptSig," which relates to the fact that the unlock script typically supplies the corresponding signature. However, more generally, it is not required in all application examples of blockchain150 that the condition for a UTXO to be redeemed includes authenticating a signature. More generally, a scripting language can be used to define any one or more conditions. Thus, the more general terms "lock script" and "unlock script" may be preferred.

[0100] 5. Note: Other variations or use cases of the techniques disclosed may become apparent to those skilled in the art if the disclosures herein are given. The scope of this disclosure is limited only by the appended claims and not by the embodiments described herein.

[0101] For example, some of the embodiments described above relate to a Bitcoin network 106, a Bitcoin blockchain 150, and a Bitcoin node 104. However, it will be understood that the Bitcoin blockchain is one specific example of blockchain 150, and the above description may apply in general to any blockchain. That is, the present invention is by no means limited to the Bitcoin blockchain. More generally, any reference above to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104 may be replaced by a reference to blockchain network 106, blockchain 150, and blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described properties of Bitcoin blockchain 150, Bitcoin network 106, and Bitcoin node 104, as described above.

[0102] In a preferred embodiment of the present invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the described functions of creating, publishing, distributing, and storing block 151 of blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some of these functions, rather than all of them. That is, a network entity may perform the function of distributing and / or storing blocks without creating and publishing them (as stated above, these entities would not be considered nodes of the preferred Bitcoin network 106).

[0103] In other embodiments of the present invention, the blockchain network 106 may not be a Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or more functions, rather than all, of creating, publishing, distributing, and storing blocks 151 of blockchain 150. For example, on those other blockchain networks, “node” may be used to refer to a network entity configured to create and publish blocks 151 but not to store and / or distribute those blocks 151 to other nodes.

[0104] More generally, any reference to the term “Bitcoin node” 104 above may be replaced with the term “network entity” or “network element,” such entities / elements configured to perform some or all of the roles of creating, publishing, distributing, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same way as described above with reference to blockchain nodes 104.

[0105] Several embodiments describe blockchain networks that implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is only one type of consensus mechanism, and in general embodiments, any type of appropriate consensus mechanism can be used, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a special case, proof-of-stake uses a randomized process to determine which blockchain node 104 will be given the opportunity to generate the next block 151. The selected node is often called a validator. Blockchain nodes can lock tokens for a certain period of time to have a chance of becoming a validator. Generally, the node that locks the largest stake for the longest period of time is most likely to become the next validator.

[0106] Please note that the embodiments described above are illustrative. More generally, methods, apparatus, or programs can be provided in accordance with any one or more of the following statements.

[0107] Statement - Set A Statement 1. A computer implementation method for booting a device using a portable bootloader device, wherein the portable bootloader device comprises a bootloader and operating system files, the blockchain has a bootloader transaction, the bootloader transaction has an output locked to a master public key, the bootloader transaction includes a first signature to sign the bootloader and a second signature to sign the operating system files, and the computer implementation method Steps to obtain the bootloader transaction, The first step is to verify the signature using the master public key, The steps include verifying the second signature using the master public key, The steps of loading operating system files using the boot loader and A method that includes [a certain feature].

[0108] Statement 2. The method according to Statement 1, wherein a boot loader transaction or boot loader device includes a file address, and the method comprises the step of using the file address to identify one or more files of the operating system files.

[0109] Statement 3. The method of Statement 2, comprising the step of executing one or more identified files.

[0110] Statement 4. The bootloader transaction is the latest bootloader transaction in a chain of bootloader transactions linked to the initial bootloader transaction, and each respective bootloader transaction has an output locked to its respective master public key, and the step of obtaining the bootloader transaction is: Steps to obtain bootloader transactions other than the most recent bootloader transaction, The steps include determining that the output of the acquired bootloader transaction has been consumed, Accordingly, the steps to obtain the latest bootloader transaction and The method described in any of statements 1 to 3, including the method described in any of statements 1 to 3.

[0111] Statement 5. A step of obtaining a transaction chain proof for the latest bootloader transaction, wherein the transaction chain proof provides proof that the latest bootloader transaction is linked to the first bootloader transaction, The steps include using transaction chain proof to verify that the most recent bootloader transaction is linked to the first bootloader transaction, and The method described in Statement 4, comprising:

[0112] Statement 6. A method of any of Statements 1-5, wherein the step of obtaining a bootloader transaction includes the step of requesting a bootloader from a trusted party.

[0113] Statement 7. The boot loader transaction is stored on the device in any of the manner described in statements 1 through 5.

[0114] Statement 8. A computer implementation method for booting a device using a portable boot loader device, wherein the portable boot loader device comprises a boot loader and operating system files, and the computer implementation method A method comprising the step of submitting the initial bootloader transaction to the blockchain network, wherein the bootloader transaction has an output locked to a master public key, and the bootloader transaction includes a first signature to sign the bootloader and a second signature to sign the operating system files.

[0115] The method in statement 8 may be a method for creating a portable boot loader to boot the device.

[0116] Statement 9. The first signature is verifiable using the master public key. The method described in Statement 8, wherein the second signature is verifiable using the master public key.

[0117] Statement 10. The method according to Statement 8, wherein the first bootloader transaction has a file address for indicating the location of one or more files in the operating system files.

[0118] Statement 11. The method according to Statement 8 or Statement 9, comprising the step of submitting an updated bootloader transaction to the blockchain network, wherein the updated bootloader transaction consumes the output of the initial bootloader transaction and has an output locked to its respective master public key, and the updated bootloader transaction comprises an updated bootloader and / or updated operating system files.

[0119] Statement 12. Memory comprising one or more memory units, Computer equipment comprising a processing unit having one or more processing units, wherein memory stores code configured to be executed on the processing unit, and the code, when executed on the processing unit, is configured to perform the method described in any of statements 1 to 11.

[0120] Statement 13. A computer program, embodied on computer-readable storage, configured to perform a method described in any of statements 1 to 11 when executed on one or more processors.

[0121] Statement-Set B Statement 1. A computer implementation method for booting a device using a portable bootloader device, wherein the portable bootloader device comprises a bootloader, an operating system file, a user public key, a certificate proving the user public key, a first signature for signing the bootloader, a second signature for signing the operating system file, and a transaction identifier for a bootloader transaction, wherein the bootloader transaction is a blockchain transaction having an output locked to the user public key, and the method is The steps include verifying the certificate using the master public key stored on the device, The first step is to verify the signature using the user's public key, The second step involves verifying the signature using a user public key or a trusted public key, A method comprising the steps of obtaining a bootloader transaction using a transaction identifier, wherein the condition for loading the operating system files is that the output of the bootloader transaction is unconsumed.

[0122] Statement 2. The method according to Statement 1, further comprising the step of loading operating system files using a boot loader.

[0123] Statement 3. The method according to Statement 1 or Statement 2, wherein the bootloader transaction includes a file address, and the method comprises the step of using the file address to identify one or more files of the operating system files.

[0124] Statement 4. The method according to Statement 1 or Statement 2, wherein the portable boot loader device has a file address, and the method comprises the step of using the file address to identify one or more files of the operating system.

[0125] Statement 5. The bootloader transaction has a hash of the file address, and the method is The steps include hashing the file address to obtain a first hash value, The method according to statement 4, comprising the step of comparing a first hash value with the hash value of a file address, wherein the condition for identifying one or more files is that the first hash value matches the hash value of a file address.

[0126] Statement 6. A method of any of statements 2 to 5, comprising the step of executing one or more identified files.

[0127] Statement 7. The bootloader transaction includes a hash of the operating system file, and the method is The steps include hashing the operating system file to obtain a second hash value, The method according to statement 6, further comprising the step of comparing a second hash value with the hash value of a file address, wherein the condition for executing one or more identified files is that the second hash value matches the hash value of a file address.

[0128] Statement 8. A method of any of statements 1-7, comprising the step of requesting a trusted party to provide the status of the output of the bootloader transaction.

[0129] Statement 9. The method according to any of statements 1 to 8, wherein the steps of verifying the certificate using a master public key stored on the device and / or verifying the first signature using a user public key are performed by the device's Basic Input / Output System (BIOS).

[0130] Statement 10. The method according to any one of statements 1 to 9, wherein the certificate includes or is generated based on the transaction identifier of the bootloader transaction.

[0131] Statement 11. A method for booting a device using a portable boot loader device, A step of submitting a bootloader transaction to a blockchain network, wherein the bootloader transaction is a blockchain transaction that includes output locked to a user public key, A method comprising the steps of storing a boot loader, operating system files, a user public key, a certificate proving the user public key, a first signature for signing the boot loader, a second signature for signing the operating system files, and a transaction identifier for a boot loader transaction on a portable boot loader device.

[0132] The method in statement 11 may be a method for creating a portable boot loader device for booting a device.

[0133] Statement 12. The statement includes the step of storing the master public key on a portable boot loader device, The certificate can be verified using the master public key, The first and second signatures can be verified using the user's public key. The method described in statement 11, which allows a bootloader transaction to be verifiable using a user public key.

[0134] Statement 13. The method described in Statement 12, wherein the second signature is verifiable using a trusted public key.

[0135] Statement 14. The method described in Statement 11, comprising the step of booting the device using a boot loader.

[0136] Statement 15. The method of any of Statements 11-14, comprising the step of submitting an invalid transaction to the blockchain network, wherein the invalid transaction consumes the output of the bootloader transaction.

[0137] Statement 16. The method described in any of statements 11-15, wherein the portable bootloader device includes a file address, or the bootloader transaction includes a file address.

[0138] Statement 17. The method described in Statement 16, wherein the bootloader transaction includes a hash of a file address.

[0139] Statement 18. The method described in any of statements 11-17, wherein the bootloader transaction includes a hash of the operating system files.

[0140] Statement 19. Memory comprising one or more memory units, Computer equipment comprising a processing unit having one or more processing units, wherein memory stores code configured to be executed on the processing unit, and the code, when executed on the processing unit, is configured to perform the method described in any of statements 1 to 18.

[0141] Statement 20. A computer program, embodied on computer-readable storage, configured to perform a method described in any of statements 1 to 18 when executed on one or more processors.

[0142] Statement 21. Computer-readable storage containing a bootloader, operating system files, a user public key, a certificate proving the user public key, a first signature for signing the bootloader, a second signature for signing the operating system files, and a transaction identifier for a bootloader transaction, wherein the bootloader transaction is a blockchain transaction containing an output locked to the user public key.

[0143] Statement 22. Computer-readable storage as described in Statement 21, wherein the first and second signatures are verifiable using the user's public key.

[0144] Statement-Set C Statement 1. A computer implementation method for booting a device using a portable bootloader device, wherein the device has an operating system file, the portable bootloader device includes a bootloader, a user public key, a first signature to sign the bootloader, and a transaction identifier for the bootloader transaction, the blockchain includes the bootloader transaction, the bootloader transaction has a candidate user public key, and the method is The steps include: obtaining the bootloader transaction using the transaction identifier, The steps include verifying that the candidate user public key corresponds to the user public key, and verifying the first signature using the user public key. The steps of loading operating system files using the boot loader and A method that includes [a certain feature].

[0145] Statement 2. The bootloader transaction includes the bootloader hash, and the method is The steps include hashing the bootloader to obtain a first hash value, The method according to statement 1, comprising the step of comparing a first hash value with the hash of a boot loader, wherein the condition for loading operating system files is that the first hash value matches the hash of a boot loader.

[0146] Statement 3. The bootloader transaction includes a hash of the operating system file, and the method is The process includes the step of hashing the operating system file to obtain a second hash value, The method according to statement 1 or statement 2, wherein the condition for loading an operating system file and / or executing an operating system file is that a second hash value matches the hash of the operating system file.

[0147] Statement 4. The method according to any of statements 1-3, wherein the operating system files are encrypted, and the method comprises a step of decrypting the operating system files.

[0148] Statement 5. The method according to any of Statements 1-4, wherein the bootloader transaction is a blockchain transaction containing output locked to a user public key, and the condition for loading the operating system files is that the output of the bootloader transaction is unconsumed.

[0149] Statement 6. The bootloader transaction includes a file address and the method is The method of any of statements 1 to 5, comprising the step of identifying one or more operating system files using a file address.

[0150] Statement 7. The method includes the step of the portable boot loader device requesting a file address, The method of any of statements 1 to 5, comprising the step of identifying one or more operating system files using a file address.

[0151] Statement 8. The bootloader transaction contains a hash of the file address, and the method is The steps include hashing the file address to obtain a third hash value, The method according to statement 7, further comprising the step of comparing a third hash value with the hash of a file address, wherein the condition for loading and / or executing an operating system file is that the third hash value matches the hash of a file address.

[0152] Statement 9. A method of any of statements 6-8, comprising the step of executing one or more identified files.

[0153] Statement 10. A method for booting a device using a portable boot loader device, A method comprising the steps of submitting a bootloader transaction to a blockchain network, wherein the bootloader transaction is a blockchain transaction including a user public key, and storing a bootloader, a user public key, a first signature for signing the bootloader, and a transaction identifier for the bootloader transaction on a portable bootloader device.

[0154] The method in statement 10 may be a method for creating a boot loader device for booting a device.

[0155] Statement 11. The first signature is verifiable using the user's public key, as described in Statement 10.

[0156] Statement 12. The method according to Statement 11, comprising the step of booting the device using a boot loader.

[0157] Statement 13. The method of any of statements 10-12, which has the output that the bootloader transaction is locked to the user's public key.

[0158] Statement 14. The method of Statement 13, comprising the step of submitting an invalid transaction to the blockchain network, wherein the invalid transaction consumes the output of the bootloader transaction.

[0159] Statement 15. The method described in any of statements 10-14, wherein the bootloader transaction includes a hash of the bootloader and / or a hash of the operating system files.

[0160] Statement 16. Memory comprising one or more memory units, Computer equipment comprising a processing unit having one or more processing units, wherein memory stores code configured to be executed on the processing unit, and the code, when executed on the processing unit, is configured to perform the method described in any of statements 1 to 15.

[0161] Statement 17. A computer program, embodied on computer-readable storage, configured to perform any method described in statements 1 to 15 when executed on one or more processors.

[0162] Statement 18. Computer-readable storage storing a bootloader, a user public key, a first signature for signing the bootloader, and a transaction identifier for a bootloader transaction, wherein the bootloader transaction is a blockchain transaction containing the user public key.

[0163] Statement 19. Computer-readable storage as described in Statement 18, the first signature of which is verifiable using a user public key.

[0164] Statement-Set D Statement 1. A computer implementation method for operating a device using a blockchain, wherein the blockchain includes a first blockchain transaction, the first blockchain transaction has first data, and a reference to the first blockchain transaction is stored on the device, and the computer implementation method Using a reference, the first step is to obtain the blockchain transaction, A method comprising the step of operating a device based on first data.

[0165] Statement 2. A step of determining that the blockchain includes a second blockchain transaction that references a first blockchain transaction, wherein the second blockchain transaction has second data, The method according to statement 1, further comprising the step of operating a device based on second data.

[0166] Statement 3. The method of Statement 1 or Statement 2, wherein operating the device includes booting the device.

[0167] Statement 4. A method of statement 1 or statement 2, wherein operating the device includes updating the device.

[0168] Statement 5. The method according to any of statements 1 to 4, wherein the first data and / or the second data are encrypted, and the method comprises a step of decrypting the first data and / or the second data before the step of operating the device.

[0169] Statement 6. The method described in any of statements 1-5, wherein the reference is stored in the device hardware.

[0170] Statement 7. A computer implementation method that uses a device to enable the device to operate, A step of submitting a first blockchain transaction to a blockchain network, wherein the first blockchain transaction has first data, and a device is configured to operate based on the first data. The steps include storing a reference to the first blockchain transaction on the device and A method that includes [a certain feature].

[0171] Statement 8. The method according to Statement 7, the step of submitting a second blockchain transaction to a blockchain network, wherein the second blockchain transaction references a first blockchain transaction and has second data, and the device is configured to operate based on the second data.

[0172] Statement 9. A device having a reference to a first blockchain transaction, wherein the first blockchain transaction has first data, and the device, Using a reference, retrieve the first blockchain transaction, It operates based on the first data and A device configured to perform the following actions.

[0173] Statement 10. Memory comprising one or more memory units, Computer equipment comprising a processing unit having one or more processing units, wherein memory stores code configured to be executed on the processing unit, and the code, when executed on the processing unit, is configured to perform the method described in any of statements 1 to 9.

[0174] Statement 11. A computer program, embodied on computer-readable storage, configured to perform any method described in statements 1 to 9 when executed on one or more processors. [Explanation of Symbols]

[0175] 101 Internet, packet-switched network 102 Computer terminals and equipment 103 users 104 Blockchain Nodes 105 Client Applications 106 P2P Network 107 Side Channel 150 Blockchains 151 blocks 152 transactions 153 Genesis Block 154 Pool 155 Block pointers 201 Header 202 inputs 203 Output

Claims

1. A computer implementation method for booting a device using a portable bootloader device, wherein the portable bootloader device comprises a bootloader and operating system files, the blockchain has a bootloader transaction, the bootloader transaction has an output locked to a master public key, the bootloader transaction includes a first signature for signing the bootloader and a second signature for signing the operating system files, and the computer implementation method is The steps include obtaining the aforementioned bootloader transaction, A step of verifying the first signature using the master public key, The steps include verifying the second signature using the aforementioned master public key, The steps include loading the operating system files using the boot loader and A method that includes [a certain feature].

2. The method according to claim 1, wherein the boot loader transaction or boot loader device includes a file address, and the method comprises the step of using the file address to identify one or more files of the operating system files.

3. The method according to claim 2, further comprising the step of executing one or more identified files.

4. The bootloader transaction is the latest bootloader transaction in a chain of bootloader transactions linked to the first bootloader transaction, and each bootloader transaction has an output locked to its respective master public key, and the step of acquiring the bootloader transaction is: The steps include obtaining bootloader transactions other than the most recent bootloader transaction, The steps include determining that the output of the acquired bootloader transaction has been consumed, Accordingly, the steps include obtaining the latest bootloader transaction and The method according to any one of claims 1 to 3, including the method described in any one of claims 1 to 3.

5. A step of obtaining a transaction chain certificate for the latest bootloader transaction, wherein the transaction chain certificate provides proof that the latest bootloader transaction is linked to the first bootloader transaction. The steps include verifying that the latest bootloader transaction is linked to the first bootloader transaction using the transaction chain proof, and The method according to claim 4, comprising:

6. The method according to any one of claims 1 to 5, wherein the step of obtaining the bootloader transaction includes the step of requesting the bootloader from a trusted party.

7. The method according to any one of claims 1 to 5, wherein the boot loader transaction is stored on the device.

8. A computer implementation method for booting a device using a portable boot loader device, wherein the portable boot loader device comprises a boot loader and operating system files, and the computer implementation method A method comprising the step of submitting an initial bootloader transaction to a blockchain network, wherein the bootloader transaction has an output locked to a master public key, and the bootloader transaction includes a first signature for signing the bootloader and a second signature for signing the operating system files.

9. The first signature described above is verifiable using the master public key, The method according to claim 8, wherein the second signature is verifiable using the master public key.

10. The method according to claim 8 or 9, wherein the initial bootloader transaction has a file address for indicating the location of one or more files in the operating system files.

11. The method according to any one of claims 8 to 10, comprising the step of submitting an updated bootloader transaction to the blockchain network, wherein the updated bootloader transaction consumes the output of the initial bootloader transaction and has an output locked to its respective master public key, and the updated bootloader transaction comprises an updated bootloader and / or updated operating system files.

12. A memory having one or more memory units, Computer equipment comprising a processing unit having one or more processing units, wherein the memory stores code configured to be executed on the processing unit, and the code, when executed on the processing unit, is configured to perform the method according to any one of claims 1 to 11.

13. A computer program, which is implemented on computer-readable storage, and which, when executed on one or more processors, is configured to perform the method described in any one of claims 1 to 11.

14. A computer implementation method for operating a device using a blockchain, wherein the blockchain includes a first blockchain transaction, the first blockchain transaction has first data, a reference to the first blockchain transaction is stored on the device, and the computer implementation method is Using the aforementioned reference, the steps include obtaining the first blockchain transaction, The steps of operating the device based on the first data and A method that includes [a certain feature].

15. A step of determining that the blockchain includes a second blockchain transaction that references the first blockchain transaction, wherein the second blockchain transaction has second data, The steps of operating the device based on the second data and The method according to claim 14, comprising:

16. The method according to claim 15 or 16, wherein operating the device includes booting the device.

17. The method according to claim 15 or 16, wherein operating the device includes updating the device.

18. The method according to any one of claims 14 to 17, wherein the first data and / or the second data are encrypted, and the method comprises a step of decrypting the first data and / or the second data before the step of operating the device.

19. The method according to any one of claims 14 to 18, wherein the aforementioned reference is stored in the hardware of the device.

20. A computer implementation method that uses a device to enable the device to operate, A step of submitting a first blockchain transaction to a blockchain network, wherein the first blockchain transaction has first data, and the device is configured to operate based on the first data. The steps include storing a reference to the first blockchain transaction on the device and A method that includes [a certain feature].

21. A step of submitting a second blockchain transaction to the blockchain network, wherein the second blockchain transaction references the first blockchain transaction and has second data, and the device is configured to operate based on the second data. The method according to claim 20.

22. A device having a reference to a first blockchain transaction, wherein the first blockchain transaction has first data, and the device Using the aforementioned reference, obtain the first blockchain transaction, It operates based on the first data mentioned above. A device configured to perform the following actions.

23. A memory having one or more memory units, Computer equipment comprising a processing unit having one or more processing units, wherein the memory stores code configured to be executed on the processing unit, and the code, when executed on the processing unit, is configured to perform the method according to any one of claims 14 to 21.

24. A computer program, which is implemented on computer-readable storage, and which, when executed on one or more processors, is configured to perform the method described in any one of claims 14 to 21.

Images