Patent Description:
The subject matter disclosed herein generally relates to the design of Integrated Circuits (ICs), and more particularly, some embodiments relate to the design of ICs for secure communications.

Application-specific integrated circuits (ASICs) are integrated circuits designed and built to serve a particular purpose or application. ASICs provide fast computational speed compared with slower, more generalized solutions, such as software solutions running on general-purpose processors or field programmable gate arrays (FPGAs). As the name implies, ASICs are generally designed to perform only one specific application, resulting in a trade-off between flexibility and computational speed. ASICs are increasing in importance in cryptography-related fields, such as proof-of-work systems, digital rights management systems, and other applications generally having stringent speed and efficiency requirements.

<CIT> (<CIT>) describes a transform-enabled integrated circuit for use in cryptographic proof-of-work systems. The transform-enabled integrated circuit includes a transformation block embedded among other circuitry components within the cryptographic datapath of the transform-enabled integrated circuit. The transformation block may be configured at a time subsequent to the manufacture of the integrated circuit to embody as circuitry any one of a plurality of mathematical transformation functions, thus enabling a user to systemically modify the results of cryptographic operations performed by the integrated circuit while retaining the high performance and efficiency characteristics of application-specific integrated circuits.

<CIT> concerns mining circuitry that may be used to mine digital currency such as bitcoins by computing solutions to a cryptographic puzzle. Successful computation of a solution to the cryptographic puzzle may provide a reward of the digital currency. The mining circuitry may partition the mined reward between a first digital wallet and a second digital wallet. The first digital wallet may be user-provided, whereas the second digital wallet may be hardcoded into the dedicated mining circuitry. The mining circuitry may include control circuitry and multiple processing core circuits. The control circuitry may control the processing cores to solve the cryptographic puzzle via exhaustive search over possible inputs to the cryptographic puzzle.

In Internet Engineering Task Force, IETF, Internet-Draft entitled "PKCS #<NUM> Password Based Key Derivation Function <NUM> (PBKDF2) Test Vectors" [draft-josefsson-pbkdfl-testvectors-<NUM>. txt], Josefsson S. discloses text vectors for the PKCS #<NUM> Password Based Key Derivation Function <NUM> (PBKDF2) with the Hash-based Message Authentication Code (HMAC) Secure Hash Algorithm (SHA-<NUM>) pseudorandom function.

<CIT> describes a processing system that includes a processor to construct an input message comprising a target value and a nonce and a hardware accelerator, communicatively coupled to the processor, implementing a plurality of circuits to perform stage-<NUM> secure hash algorithm (SHA) hash and stage-<NUM> SHA hash, wherein to perform the stage-<NUM> SHA hash, the hardware accelerator is to perform a plurality of rounds of compression on state data stored in a plurality of registers associated with a stage-<NUM> SHA hash circuit using an input value, calculate a plurality of speculative computation bits using a plurality of bits of the state data, and transmit the plurality of speculative computation bits to the processor.

<CIT> concerns a system for performing hashing that includes a controller for controlling the system and for providing a clock signal; an array of integrated circuits; in each integrated circuit, a plurality of cores for performing hashing; and in each core, a plurality of data expanders and data compressors, the data expanders and the data compressors having pipelined circuitry so that two iterations of a hashing loop are performed for each cycle of the clock signal.

The invention is an integrated circuit, a method and a machine readable medium as defined in the appended claims.

Various ones of the appended drawings illustrate embodiments of the present disclosure.

Circuits, methods, and computer programs are directed to performing proof-of-work (POW) validations using mathematical operations that change for each POW cycle. Unless explicitly stated otherwise, components and functions are optional and may be combined or subdivided, and operations may vary in sequence or be combined or subdivided. In the following description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding of embodiments. It will be evident to one skilled in the art, however, that the present subject matter may be practiced without these specific details.

In some embodiments, an integrated circuit (IC) includes circuitry for dynamically modifying the mathematical POW operations the IC applies to a given input, where the modification is based on said input and hardware-implemented calculations performed during previous POW validations. The resulting outputs appear to be random but are programmatically replicable, allowing for the external verification of the POW operations by other ICs or by software programs executing on other devices.

In some embodiments, an ASIC circuit, for performing proof-of-work (POW) of blockchain headers, includes a dynamic transform function circuit between two one-way function (OWF) circuits. The dynamic transform circuit performs an operation on the output of a first OWF to alter one or more bits, and the result are used as an input to a second OWF. The output of the second OWF is used for checking if the output meets a certain accuracy criterion. The dynamic transform function circuit is named "dynamic" because the function changes at every cycle during POW operations, where each cycle includes a different value for the nonce in the header being checked. The dynamic transform function circuit is initialized with a value and then changed every cycle based on one or more parameters, such as the value of the nonce register.

One integrated circuit includes a nonce register for storing a nonce value, a first OWF circuit configured to generate a hash of a header, a dynamic transform circuit configured to transform the hash of the header to generate a transform value, and a second OWF circuit configured to generate a hash of the transform value to obtain a validation parameter. The header includes the nonce value for proof-of-work (POW) validation of the header. Further, the transformation by the dynamic transform circuit is based on the nonce value. The validation parameter determines if the POW meets a predetermined target for validation of the header with the nonce value.

In one embodiment, a method includes operations for receiving a header, initializing a nonce register with a nonce value, and performing a first OWF to generate a hash of the header. The header, that includes the nonce value, is checked for proof-of-work (POW) validation. Further, the method includes an operation for performing a dynamic transform to transform the hash of the header resulting in a transform value. The transformation by the dynamic transform is based on the nonce value. Additionally, the method includes operations for performing a second OWF to generate a hash of the transform value resulting in a validation parameter and for determining, based on the validation parameter, if the POW meets a predetermined target for validation of the header with the nonce value.

<FIG> shows the operation of an integrated circuit (IC) <NUM> for transform-enabled cryptographic operations, according to some embodiments. The IC <NUM> contains a transform-enabled hashing core <NUM>, implemented as a stand-alone integrated circuit, that performs transform-enabled hashing operations.

The IC <NUM> also contains a programming and configuration interface <NUM> and a configuration key <NUM>. The configuration key <NUM> is composed of a string of binary digits and is also referred to herein as a transform key or a transformation key.

Two exemplary users <NUM> and <NUM> can access the IC <NUM>, with a first user <NUM> accessing the programming and configuration interface <NUM>, and a second user <NUM> accessing the transform-enabled hashing core <NUM>. The second user <NUM> uses a hashing core user interface (not shown). In various embodiments, some or all of the functions of the configuration and programming interface <NUM> and the hashing core user interface are combined into a single configuration, programming, and hashing core user interface, while in other embodiments, such functions are divided among more than two interfaces.

The general mode of operation is that the first user <NUM> uses the programming and configuration interface <NUM> to both configure various parameters of the operation of the IC <NUM> and to program one or more configuration keys <NUM> into the programmable transformation function or functions in the transform-enabled hashing core <NUM>, where they are implemented as datapath circuitry. Note that configuration keys <NUM> are not conventional cryptographic keys in the strictest sense, but instead are customized descriptions of how a selected transformation function is to be activated, such as to transform original input data into transformed input data.

The second user <NUM> enters an input value, a transaction, or a message that is directly communicated to the core <NUM> that will calculate and output the corresponding hash value. For a given input value and configuration key <NUM>, any user of an instance of transform-enabled IC <NUM> is able to calculate the same corresponding hash value. The input value may comprise a transaction block header from a blockchain, for example, but other types of inputs may be used. It is noted that processing the input to produce a corresponding hash value may be carried out by the second user without requiring knowledge of the configuration key, or configuration keys, programmed into the core <NUM>.

The core <NUM> includes one or more blocks of circuitry implementing a cryptographic function (generally a cryptographic OWF that is hard to reverse, such as a secure hashing algorithm). Due to interaction of the transformation with the mathematical properties of the cryptographic algorithms involved, particularly their nature as OWFs that are hard to revert, the combined effect is to produce a systemic transformation of the bits contained in the final value calculated by the circuit that is not easily deciphered, not easily distinguishable from noise, and not easily replicable by a party lacking full prior knowledge of the user's key or keys, but yet is fully consistent and easily replicable and thus verifiable by a party with prior knowledge of the keys or access to the means to utilize them in calculation even while lacking knowledge of them (such as a party in possession of an ASIC programmed to embody the keys within its datapath circuitry). As used herein, terms such as "hard" and "easy" may be understood in the sense of computational complexity theory, particularly polynomial time theory. For example, "hard to revert" may refer to the impossibility of reversing a hash function, unless a huge amount of computational resources were used for a very long time (e.g., weeks, months, or years). On the other hand, the calculation of a hash function is considered "easy" as the core <NUM> may take milliseconds to perform the hash.

Due to the interaction thus established between the programmatic transformation and certain mathematical properties of the cryptographic algorithms involved (particularly, as noted earlier, their nature as OWFs that are easy to perform but hard to revert), the combined effect is to produce a systemic transformation of the bits contained in the final value calculated by the circuit. The transformation is not easily deciphered, not easily distinguishable from noise, and not easily replicable by a party lacking full prior knowledge of the key or keys programmed into the transformation function. Yet the transformation is fully consistent and easily replicable, and thus verifiable, by a party with prior knowledge of the keys or access to the means to utilize them in calculation even while lacking knowledge of them (e.g., a party in possession of a previously-programmed ASIC that embodies said keys within its datapath circuitry).

In some embodiments, each user is a person, while in other embodiments, each user is an automated process such as wallet software, mining software, or other kinds of automated processes. In certain embodiments, there is a single interface for the configuration of the various operating aspects of the IC <NUM> as a whole, with the programming of keys and the obtaining of final transform-enabled hash values calculated on the basis of data supplied by a user. In other embodiments, some or all of those functions are separate.

In some embodiments, various implementations of the IC <NUM> are physically integrated into the same semiconductor material, such as silicon, as other embodiments of the technology described herein. In some such embodiments, the IC <NUM> may additionally be further connected to other embodiments of the technology described herein. For example, in various cases, the IC <NUM> have a shared access to programmable transformation functions or functions in the transform-enabled hashing core <NUM> as other circuits within the same IC <NUM>. In various other embodiments, the transform-enabled IC <NUM> may be physically integrated into the same semiconductor material as another integrated circuit carrying out a different task, such as a microprocessor, a network processor, a system-on-a-chip, and others. In certain embodiments, the core <NUM> embodies the configuration key <NUM> as circuitry by means of one-time programmable circuit elements such as micro-fuses, while in certain embodiments, other rewriteable circuit elements are used, such as binary registers, flip flop circuits, latches, gates, random access memory (RAM), non-volatile RAM, and the like.

<FIG> shows a block diagram of the transform-enabled hashing core <NUM>, according to an embodiment. This diagram depicts the operations performed for the second user <NUM> to obtain final transform-enabled hash values.

A user provides a passphrase <NUM> that controls aspects of the information stream management methodology. This user may comprise the first user <NUM> of <FIG>, for example, who provides, in one embodiment, the user passphrase <NUM> via the programming and configuration interface <NUM>. The passphrase <NUM> is provided during the manufacture of IC <NUM>, or thereafter. The passphrase <NUM> comprises a string of binary numbers or a string of text that may be more easily remembered by a human user but still readily convertible into a string of binary numbers.

The secrecy of the passphrase <NUM> prevents any other parties from enabling the creation of the information stream being managed. The passphrase <NUM> enables control of all other operations performed in the information hierarchy (e.g., processing of the information stream, performing POW operations, and identifying the information stream).

A configuration key generation processing <NUM> calculates the configuration key <NUM> based on the passphrase <NUM>. The IC <NUM> receives the passphrase <NUM> and performs on-the chip configuration key generation processing <NUM> to produce the configuration key <NUM> at the IC <NUM>. In other embodiments, the configuration key is received as input at the IC <NUM>. The on-chip configuration key generation <NUM> processing, rather than a separate off-chip implementation, may enhance security, as will be described.

The configuration key generation processing <NUM> comprises at least one application of an OWF to the passphrase <NUM>. In one embodiment, the configuration key generation processing <NUM> comprises two sequential applications of an OWF to the passphrase <NUM>. The configuration key generation processing <NUM> comprises two sequential applications of SHA256 to the passphrase <NUM>.

Use of an OWF renders derivation of the passphrase <NUM> from the configuration key <NUM> computationally infeasible. That is, the passphrase <NUM> is upstream of the OWF and is therefore cryptographically secure. Knowledge of the passphrase <NUM> and of the calculation process enables the easy calculation of the configuration key <NUM>. However, knowledge of the configuration key <NUM> and of the process by which it is calculated, on the basis of the passphrase <NUM>, does not enable easy calculation of the passphrase <NUM>. Thus, in such embodiments, knowledge of the passphrase <NUM> implies knowledge of the configuration key <NUM>, but knowledge of the configuration key <NUM> does not imply knowledge of the passphrase <NUM>. Knowledge of the passphrase <NUM> is required to generate the configuration key <NUM> used to configure the static transform <NUM> and thus the IC <NUM> to perform in the specific manner that is described by passphrase <NUM>.

Therefore, in one embodiment, the passphrase <NUM> enables creation of a blockchain, while the configuration key <NUM> enables others, who do not know the passphrase <NUM>, to nevertheless process and verify headers <NUM> such as blockchain headers. Further, knowledge of the configuration key <NUM> enables the creation of any number of transform-enabled cryptographic ICs <NUM> for processing headers <NUM>, if the formulation of the static transform <NUM> is known.

An input message <NUM> includes a header <NUM>, and the header is provided to the core <NUM> and passed through a first OWF <NUM> implementation hashing block. The header <NUM> is a candidate block header, such as from a blockchain.

In general, the first OWF <NUM> (e.g., hashing block) is configured as a set of circuitry that executes the mathematical operations defined by the applicable hashing algorithm. One widely used hashing algorithm is the SHA, the second version of which is now used as a standard hashing algorithm, often for input messages of <NUM> bits in length (referred to herein as SHA-<NUM> or simply SHA unless otherwise indicated). However any OWF may be used. Although some embodiments are presented with reference to <NUM>-bit values, the same principles may be utilized for values with different sizes (e.g., <NUM> bits).

The output of the first OWF <NUM> is a hash <NUM> of the header <NUM>. A hash, sometimes known as a message digest, is used as a type of cryptographic description of original message content.

The hash <NUM> is then processed by a customizable programmable transformation function, referred to herein as static transform <NUM>, which is also implemented in circuitry as a transform block. The static transform <NUM> is referred to as "static" because, once programmed, the circuitry within the transform block effects a specific programmatic transformation upon the data provided, reflecting the configuration key <NUM> configured for the transform block. Thus, the transformation the circuitry applies will directly and consistently affect the final value calculated by circuitry further along the datapath.

As discussed in more detail below, a dynamic transform refers to a transform function that is changed by the core <NUM> based on different parameters. The dynamic transform is described by a binary value that includes a plurality of bits. The dynamic transform performs a logical operation on an input value to generate an output value (e.g., performing an XOR, bit by bit, of the input value with the bits that define the dynamic transform). The dynamic transform is referred to as "dynamic" because its value changes for the validation of each header. In other embodiments, the dynamic transfer is reused and changed every few headers.

The static transform <NUM> is based on a passphrase entered by the user, but the dynamic transform does not depend on the passphrase, although sometimes, the dynamic transform may be adjusted based on the configuration key. In some cases, the dynamic transform is changed based on the configuration key and additional parameters, and in other cases the dynamic transform is changed without being dependent on the configuration key.

The static transform <NUM> generates a transformed hash <NUM>, referred to as the transform value, of the header <NUM>. The static transform <NUM> is a simple transformation of the hash of the header <NUM>, such as an inversion of one or more bits, in some embodiments, the transposition or swapping of bits in other embodiments, or a combination thereof. The programming of the static transform customizes the treatment to which data fed into the transformation function is subjected. The configuration key <NUM> controls the specific programming of the static transform <NUM>. The configuration key <NUM> is simply a string of binary digits denoting which corresponding bits of input data are to be inverted, transposed, or both, by the static transform <NUM>, according to various embodiments. That is, in one embodiment, each particular bit of the configuration key <NUM> determines whether each corresponding particular bit of input data is passed through directly without transformation or passed after being inverted. In some embodiments, the transformation of an input bit depends on one or more bits in the static transform and/or other input bits.

The transformed hash <NUM> of the original header <NUM> is then processed by a second OWF <NUM> (e.g., a second hashing block). In some embodiments, the second OWF <NUM> implements the same cryptographic operation as the first OWF <NUM>. In other embodiments, the second OWF <NUM> implements a different cryptographic operation than the first OWF <NUM>. The output value <NUM> of the core <NUM> is thus a hash of a transformed hash <NUM> of the original header <NUM>.

The secure programming of the transform-enabled IC <NUM> enables a variety of advantages. A novel information hierarchy may be defined and cryptographically secured via the IC <NUM> that stores configuration data without providing external visibility or accessibility to that data. The information hierarchy enables a cryptographic management methodology that enables the creation of, provides for useful processing of, and allows the simple identification of an information stream to be processed. The information stream comprises a blockchain.

The formulation of the static transform <NUM> is either published or kept obscured. The cryptographic strength of the embodiments does not rely on the secrecy of the static transform <NUM>. The configuration key <NUM> that controls the customization of the static transform <NUM> is also either kept secret or made public. However, this choice depends on whether the second users <NUM> are intended to be able to process the information stream with only original programmed circuitry or also with replicated or "cloned" circuitry. In some cases, only members of a given group, such as a government, corporation, or other set of the second users <NUM>, are intended to have the capability to process a private information stream, so the configuration key <NUM> is a secret shared only with such intended parties. In other cases, the intent is for anyone to be able to process a public information stream without the requirement for a shared secret, so the configuration key <NUM> is made public.

The specific predetermined output value <NUM> is a unique identifier of a given information stream from which header <NUM> originated. A second user <NUM> who possesses neither knowledge of the passphrase <NUM> nor of the configuration key <NUM> may therefore nonetheless identify a given information stream using an instance of the programmed IC <NUM>. Such a second user <NUM> may process messages but cannot make copies of the IC <NUM> that has been programmed to inaccessibly and invisibly contain the configuration key <NUM>. This ability to identify an information stream with no direct knowledge of the passphrase <NUM> nor of the configuration key <NUM> is particularly advantageous in certain use scenarios.

In one embodiment, the information stream is a blockchain, and the predetermined output value <NUM> is a ChainID that uniquely identifies the blockchain. In the future, there may be a large number of different blockchains, so using a ChainID allows any second user <NUM> with a programmed transform-enabled cryptographic IC <NUM> to distinguish the blockchain from which headers <NUM> originate from all others.

The ChainID is thus the lowest derivation level of the information hierarchy. The ChainID does not enable the creation of a blockchain (that requires knowledge of the passphrase <NUM>) and does not by itself enable the ability to replicate the IC <NUM> (that requires knowledge of the configuration key <NUM> by the second user <NUM> which may not be accessible or visible from the IC <NUM>). The ChainID functionality does, however, enable the easy identification of the blockchain. Thus, the information hierarchy can separate out the ability to create a blockchain, interact with it, and identify it. Someone who knows only the configuration key <NUM> but not the passphrase <NUM> cannot create a blockchain, for example, but can identify and verify it. Such verification is the basis of a proof-of-work system (e.g., bitcoin mining).

POW verification systems are predicated on solving complex computational problems, not for any intrinsic value of the answer arrived at, but for the probative value such an answer provides that a significant amount of computational work has been expended in producing such a result. POW verification systems have applications across a broad range of modem computational systems, including: systems used for the deterrence of denial-of-service (DoS) network attacks; systems used for the prevention of unwanted commercial email (spam); and systems used for other applications. Another use of POW verification is for the cryptographic network POW verification process underlying blockchain technology, which enables decentralized trustless transaction systems, such as those supporting cryptographic currencies, the most widely known of which is bitcoin.

Certain embodiments of the technology disclosed herein allow a user to enable third parties to easily verify the proof-of-work produced by transform-enabled integrated circuits by providing the third parties with knowledge of the configuration key and thus enabling them to verify such proof of work by means of software running on general-purpose microprocessors, FPGAs programmed for this purpose, or other means. But knowledge of the configuration key does not enable the third parties to program additional copies of the integrated circuit to calculate transform-modified proof-of-work in the same manner as they are calculated by instances of the integrated circuit that have been programmed using the user passphrase. The circuit described has been designed to perform such validations while not revealing information about the precise mathematical operations involved in the production of the transformed hash values verified.

Further, the system described is also applicable to fields other than the field of blockchain technology. In such other fields, the system is used for the creation of other secure hardware-based products.

<FIG> shows a flowchart <NUM> of the management methodology of the information hierarchy, according to an embodiment. At <NUM>, the method <NUM> initially determines if a user knows the passphrase <NUM>. If so, at <NUM>, the user is granted full control over the information hierarchy. Such a user is provided with the ability to create a new unique information stream, such as a blockchain. The user proceeds to create an information stream by customizing the programming of a transformation function and using the IC <NUM> to create blockchain block headers, for example. The headers may include a field indicating the particular validation method to be used for corresponding message content.

If the user does not know the passphrase <NUM>, the method <NUM> proceeds to <NUM>. At <NUM>, the methodology determines if the user knows the configuration key <NUM>. If so, the user, at <NUM>, is granted the further privilege of programming additional instances or copies of transform-enabled cryptographic ICs <NUM>. The programming occurs during a manufacturing process or thereafter.

If the user does not know the configuration key <NUM>, the method <NUM> proceeds to <NUM>. At <NUM>, the method <NUM> determines if the user at least has a programmed transform-enabled cryptographic IC <NUM> to process an information stream that has been created in view of the technology described in this disclosure. If so, then at <NUM>, the method <NUM> processes a predetermined test header <NUM> to produce a predetermined output value <NUM> that serves as a ChainID. The ChainID indicates a particular information stream, such as a blockchain, from which input messages originate. If user does not have a programmed transform-enabled cryptographic IC <NUM>, the method ends. This operation <NUM> is optional in some embodiments.

At <NUM>, the method <NUM> enables the processing of other headers from the information stream. In one embodiment, the information stream is a blockchain, and the processing comprises verification of the blockchain through computation of transform-customized hashes for subsequent comparison. If the user does not have a programmed transform-enabled cryptographic IC <NUM>, then an information stream that has been created in view of the technology described in this disclosure cannot be processed nor identified by the user.

In example embodiments, particular circuitry may advantageously secure the programming of the transform-enabled cryptographic IC <NUM>. Such particular circuitry enables the first user <NUM> to provide a copy of the passphrase <NUM> to the transform-enabled cryptographic IC <NUM>, which is used to generate the unique configuration key <NUM> for the cryptographic IC <NUM>. Similarly, the circuitry enables the derivation of the configuration key <NUM> from the passphrase <NUM>.

The configuration key <NUM> in the circuitry is stored in isolation (e.g., in a manner that is neither accessible nor visible outside of IC <NUM>) and serves to enable enforcement of part of the information hierarchy. That is, if the user <NUM> has knowledge of the configuration key <NUM> during or after its generation, the user <NUM> may replicate circuitry (or executable instructions) that implements the particular customized transform-enabled hashing used to process headers <NUM>. In contrast, if the user <NUM> does not have knowledge of the configuration key <NUM> but simply has access to circuitry that invisibly stores the configuration key <NUM> in isolation, such user <NUM> may process headers but may not replicate the circuitry. That is, the invisible, inaccessible, and indelible isolated storage of the configuration key <NUM> prevents the circuitry from being "cloned. " The processing of headers <NUM> may include identifying a given information stream and verifying messages from the information stream, for example, as previously described, whether by circuitry or executable instructions.

Hardware based enforcement of the management of the information hierarchy may not only enable different users to be granted different levels of control of the information hierarchy <NUM>, it may also limit the availability of the configuration key <NUM>. For example, if the first user <NUM> who has the passphrase <NUM> wants to generate a configuration key <NUM>, that does not necessarily mean that the first user <NUM> wants to have actual knowledge of the configuration key <NUM>, or even knowledge of how the configuration key <NUM> is derived from the passphrase <NUM>. The first user <NUM> may not want to be capable of determining the configuration key <NUM> at all.

Instead, the first user <NUM> may simply wish to create hardware that only generates and securely stores the configuration key <NUM> internally, that is, in isolation, to enable input message processing and information stream identification by, for example, second users <NUM>. The particular methodology for generating the configuration key <NUM> from the passphrase <NUM> thus may not need to be known even to the first user <NUM> who has control of the entire information hierarchy.

Similarly, particular circuitry better protects the passphrase <NUM> that enables complete control of the entire information hierarchy. That is, the first user <NUM> may provide the passphrase <NUM> to the transform-enabled cryptographic IC <NUM>, but that IC <NUM> may delete the received passphrase <NUM> after the configuration key <NUM> has been determined and the key value or values are indelibly and inaccessibly stored within the IC <NUM>.

The technologies for one-time programmable memory include micro-fuses, anti-fuses, non-volatile RAMs including flash memory or other types of non-volatile memory. In general, determination of the state of each element of such memories via external physical examination is intentionally very difficult or infeasible.

Software-based implementations of the transform-customized message hashing process previously described are also within the scope of this disclosure. However, hardware-based implementations are more immune to monitoring during operation. The undesirable consequences of such monitoring could include the eventual discovery of the passphrase <NUM>, the configuration key <NUM>, and the configuration key generation <NUM> methodology.

Hardware implementations therefore offer better enforcement of the restricted creation of information streams, such as blockchains, based on the secrecy of the passphrase <NUM>. Hardware implementations also offer better enforcement of the restricted ability to replicate transform-customized hashing circuitry, based on the availability of the configuration key <NUM>.

<FIG> shows a functional diagram of an internally-programmable integrated circuit, according to an embodiment. The IC <NUM> acts as a conceptual "shopkeeper" that receives instructions from a customer (e.g., the first user <NUM>) at the front counter of a shop, and then performs various tasks the customer requires, but does so "behind the scenes" or out of view of the customer, in isolation.

In this case, the IC <NUM> receives a copy of the passphrase <NUM> from the first user <NUM> via the programming and configuration interface <NUM> as previously described. The programming and configuration interface <NUM> acts as a "black box" that accepts certain inputs, but only outputs acknowledgements and does not echo the inputs provided. That is, the programming and configuration interface <NUM> does not allow access to or visibility of the isolated internal operations of the IC <NUM>.

The IC <NUM> then generate the configuration key <NUM> according to a configuration key generation <NUM> methodology embedded in its circuitry. The first user <NUM> is not aware of the configuration key generation <NUM> methodology, in some embodiments.

The IC <NUM> then stores the generated configuration key <NUM> in an indelible and hidden manner and deletes its copy of the passphrase <NUM>. In one embodiment, the configuration key <NUM> is stored in a one-time programmable memory <NUM>, which comprises an array of micro-fuses, anti-fuses, or various types of non-volatile memory. Micro-fuses are generally short circuits until they are effectively "blown" open (e.g., rendered non-conductive), typically by application of a voltage pulse of particular magnitude and duration. Anti-fuses, in contrast, are generally open circuits until they are effectively "burned" closed (e.g., rendered conductive), typically again by application of a voltage pulse of particular magnitude and duration. These state changes may not result in physical changes that are readily visible.

The IC <NUM> provides an acknowledgement <NUM> to the first user <NUM> to denote at least one of the receipt of the passphrase <NUM>, the deletion of the passphrase <NUM>, or the successful completion of the storage of the configuration key <NUM> into memory <NUM>. Thus, the conceptual shopkeeper effectively provides the internally-programmed IC <NUM> to the customer (e.g., the first user <NUM>) after having customized it in isolation (e.g., without any customer access or visibility into the programming process).

The approach provided offers the first user <NUM> the advantage of trusting the hardware implementation with the passphrase <NUM> for only a limited time, because the hardware implementation will not store the passphrase <NUM> once the configuration key <NUM> has been generated and stored internally. Further, the first user <NUM> knows that the hardware implementation is relatively secure from attack. That is, a hacker may be able to dismantle the integrated circuit <NUM> to attempt to determine the configuration key generation methodology and the programmable transformation function, but the security of the system does not depend on knowledge of either.

Recovery of the actual configuration key <NUM> (which was generated from the now-deleted passphrase <NUM> and stored in the one-time programmable memory <NUM>), which is required for cloning of the IC <NUM>, is generally infeasible via physical examination. Further, a hacker may have to destroy a new copy of the programmed IC <NUM> with every hacking attempt, which would rapidly become expensive.

<FIG> shows the structure of a blockchain message <NUM>, according to some embodiments. Although some of the embodiments presented herein are described with reference to blockchain messages, the principles presented herein may be utilized with any other type of messages.

The message <NUM> includes a header <NUM> and a body <NUM>. The header <NUM> includes information about the message <NUM>, and the body <NUM> includes the information being transmitted, such as blockchain transactions.

The header includes a version <NUM> (e.g., <NUM> bytes), a previous block hash <NUM> (e.g., <NUM> bytes), a Merkle root <NUM> (e.g., <NUM> bytes), a timestamp <NUM> (e.g., <NUM> bytes), a target <NUM> (e.g., <NUM> bytes), and a nonce <NUM> (e.g., <NUM> bytes). The version <NUM> is used to keep track of upgrades and changes in the blockchain protocol. The previous block header hash <NUM> is the linkage into the previous block and secures the chain. The Merkle root <NUM> is a hash of the root of the Merkle tree of the block's transactions in the body <NUM>.

Further, the timestamp <NUM> is the number of seconds since the first of January <NUM> and the difficulty target <NUM> of the block identifies the number of zeroes to be found when hashing the block header <NUM> in order to meet the required level of proof of work to maintain the block time at <NUM> minutes.

The nonce <NUM> is a parameter that may be changed with the goal of obtaining a validation parameter (calculated from the header with the nonce value) that meets the target difficulty level required for the blockchain, such as a predetermined leading number of zeros in the validation parameter (e.g., <NUM> zeros but the number of zeros may change over time based on network parameters). The nonce <NUM> value is altered by miners to try different permutations to achieve the difficulty level required or the first transaction of the Merkle root signifying the recipient of the block reward.

<FIG> is a flowchart of a method <NUM> for generating a proof of work, according to some embodiments. At operation <NUM>, the header is received (e.g., by the core <NUM>).

From operation <NUM>, the method flows to operation <NUM> where the dynamic transform is initialized. The initial value of the dynamic transform is referred to as the seed and may be calculated based on one or more parameters, which may include one or more bits from the configuration key <NUM> (associated with the static transform <NUM>), one or more bits from the header, one or more bits from the body of the input message, or combinations thereof. For example, the seed includes some bits from the configuration key <NUM>, some bits from the nonce, and some bits that are a combination (e.g., a logical XOR operation) of bits from the configuration key and some bits from the nonce.

Any combination of bits may be used, as long as the process is clearly defined so other blockchain nodes may validate the operations using the same process to calculate the seed. In some example embodiments, the seed is a numerical value having <NUM> bits, but the seed may have other sizes.

At operation <NUM>, the core <NUM> performs the hash of the header with the current value of the nonce. In some example embodiments, the initial value of the nonce is the value received in the header of the input message, but other initial values may also be applied.

The seed defines a dynamic transform to be applied to the hash of the header. In some example embodiments, the dynamic transform includes performing an XOR (exclusive logical OR) operation of each bit in the seed with a corresponding bit from the hash of the header. In other embodiments, other logical operations may be performed, such as logical AND, logical OR, or combinations thereof.

At operation <NUM>, the dynamic transform of the hash of the header is performed, which results in a transform value. From operation <NUM>, the method flows to operation <NUM>. Additionally, after operation <NUM>, the value of the dynamic transform is updated at operation <NUM>. More details are provided below with reference to <FIG> regarding the update of the dynamic transform.

The IC design includes a circuit that is dynamically reconfigured, at each cycle, to apply different POW calculations, at each cycle, based on one or more of: the input (e.g., header for validation), a modification of the dynamic transform circuit at each cycle, and the static transform. In some embodiments, the reconfiguration is not based on the static transform, and in other embodiments, the reconfiguration is not based on the input (e.g., is based on the value of the nonce register).

In some example embodiments, the reconfiguration is based on a portion of the nonce value, such as the ending <NUM> out of <NUM> bits, but other embodiments use fewer or more bits, such as <NUM>, <NUM>, <NUM>, <NUM>, etc., from the beginning, the middle, or the end of the nonce value.

In other example embodiments, the dynamic transform is based on a <NUM>-bit checksum of the input, for example, the header with the current nonce value, or on a <NUM>-bit checksum calculated using the odd-number bits in the input, or a <NUM>-bit string calculated by seeding a PRBS circuit with the first <NUM> bits of the SHA hash of the input, etc..

The dynamic transform is calculated based on the input and results from previous-cycles, and the dynamic transform can be independently replicated given knowledge of the input value (e.g., the header). Thus, the dynamic transform (DT) is bit-sensitive to the input value, and the process of calculating the DT value involves complex operations that complicate attacks from malicious users.

At operation <NUM>, a hash of the transform value is calculated and the result is referred to as the validation parameter. At operation <NUM>, a check is made to determine if the validation parameter is below the target (e.g., enough number of leading zeros). If the validation parameter is below the target, the method <NUM> continues to operation <NUM>, where a determination is made that the golden nonce has been found. The golden nonce is the nonce value that, when inserted into the header, generates the validation parameter that has the required number of leading zeros.

If the validation parameter is not below the target, the method <NUM> continues to operation <NUM>, where the nonce is incremented for a new check of the header with the incremented nonce. In other embodiments, the nonce is changed in other ways, such as by adding a value greater than one to the nonce.

From operation <NUM>, the method flows to operation <NUM>, where the header is updated with the new value of the nonce. From operation <NUM>, the method flows back to operation <NUM> to start the check of a new header beginning with the hash of the header.

It is noted that if the golden nonce is not found after a certain number of cycles, the process may abort, or the process may be aborted when an external signal is received to stop the proof-of-work operations.

Further, the DT may be used in other areas besides header POW, such as spam prevention, establishment of trust, etc..

<FIG> illustrates the operation of the dynamic transform, according to some embodiments. The core <NUM> is one of a plurality of cores in the IC <NUM>. The core <NUM> receives the header <NUM>. In other example embodiments, the core <NUM> receives the input message <NUM> that includes the header <NUM> and the body <NUM>.

In some embodiments, the core <NUM> includes a nonce register <NUM>, a first hash (SHA <NUM>) <NUM>, a dynamic transform <NUM>, a second hash (SHA <NUM>) <NUM>, a seed generator <NUM>, a dynamic transform updater <NUM>, and a checker module <NUM>. In other embodiments, there are additional transforms operating between the first hash <NUM> and the second hash <NUM>, such as one or more static transforms.

The nonce register <NUM> is initialized with the nonce in the header <NUM>, and the nonce register <NUM> is incremented each time a new value of the nonce is checked for proof of work, as described above with reference to <FIG>. The value of the nonce register is transferred as nonce output <NUM>.

Further, the seed generator <NUM> generates the seed that constitutes the initial value of the dynamic transform, and the seed generator <NUM> may use values from the static transform <NUM> (e.g., the configuration key <NUM>), from the input message <NUM>, or may use constant values (e.g., bits with a logical value of <NUM> or <NUM>) during initialization for one or more bits.

In some example embodiments, the seed includes the ending <NUM> bits of the nonce register <NUM>, but other seeds are also possible, such as by using more bits or fewer bits and different types of PRBS circuits. In this case, the seed does not depend on the value of the static transform <NUM>.

After the dynamic transform is applied, as discussed above, the DT updater <NUM> updates the value of the DT for the next iteration of proof of work. Additionally, the checker module <NUM> determines if the validation parameter <NUM> meets the target (e.g., required number of leading zeros) and outputs a found value <NUM> indicating if the golden nonce has been found. The DT updater <NUM> includes a clock CLK <NUM> as an input and performs the updating of the dynamic transform after the required number of cycles for checking the value of the nonce. In some example embodiments, the clock CLK <NUM> also triggers the increment of the nonce register <NUM>.

The first hash <NUM> performs the hash of the header <NUM> with the current value of the nonce register, then the dynamic transform is applied, followed by the second hash <NUM>, to obtain the validation parameter <NUM>.

It is noted that the embodiments illustrated in <FIG> do not describe every possible embodiment. Other embodiments may utilize different components, additional components, or combine the functionality of several components. The checker module <NUM> is located outside the core <NUM>, in some embodiments.

<FIG> illustrates the calculation of the initial value for the dynamic transform, according to some embodiments. As discussed above, the user enters a passphrase <NUM> and the static transform <NUM> is calculated, such as by performing an OWF <NUM> (e.g., SHA256) of the passphrase <NUM>. The input message <NUM> includes the header, with a nonce, and the body. At operation <NUM>, the bits from the static transform <NUM> and the input message <NUM> are combined to generate the initial dynamic transform <NUM>.

For example, the initial DT includes one or more bits from the nonce and one or more bits from the static transform <NUM>, and fixes one or more bits to a value of <NUM> or <NUM>. The initial DT includes <NUM> bits from the nonce and <NUM> bits from the static transform, or <NUM> bits from the nonce, <NUM> bits from the static transform, and then fills <NUM> bits with alternating zeros and ones. In another embodiment, the initial DT is a hash of the nonce. In yet another embodiment, the initial DT includes an XOR of the bits from a hash of the nonce and the bits from the static transform.

A person skilled in the art would readily appreciate that there are different ways to combine the static transform with information from the input message <NUM>, as long as the process is well-defined and can be reproduced at other network nodes for proof-of-work validation.

<FIG> illustrates the process for calculating the next dynamic transform using a pseudorandom binary sequence (PRBS), according to some embodiments. In some embodiments, the dynamic transform is implemented with registers <NUM>, such as linear feedback shift registers (LFSR), and each register <NUM> represents one bit of the dynamic transform.

The LFSR is a shift register whose input bit is a linear function of its previous state. The most commonly used linear function of single bits is exclusive-or (XOR). Thus, an LFSR is most often a shift register whose input bit is driven by the XOR of some bits of the overall shift register value. The initial value of the LFSR is called the seed, and because the operation of the register is deterministic, the stream of values produced by the register is completely determined by its current (or previous) state. Because the register has a finite number of possible states, the LFSR will eventually enter a repeating cycle. An LFSR with a well-chosen feedback function can produce a sequence of bits that appears random and has a very long cycle.

To calculate the next DT, the registers <NUM> are shifted to the right, although other embodiments may shift to the left, according to a PRBS polynomial. A PRBS is a binary sequence that, while generated with a deterministic algorithm, is difficult to predict and exhibits statistical behavior similar to a truly random sequence.

The PRBS is defined by the position of the XOR gates <NUM> that are expressed as the PRBS polynomial <NUM>. In the example of <FIG>, the XOR gates are at positions a, b, c, and d, which define the polynomial Xa + Xb + Xc + Xd + <NUM> <NUM>. The XOR gate <NUM> at position n defines the coefficient of Xn as <NUM>, otherwise the coefficient at position n is <NUM> so there will be no term in the polynomial <NUM> for position n. The coefficient for X<NUM> (position <NUM>) is defined as <NUM>.

Some common sequence generating polynomials are:.

After the CLK <NUM> triggers, the dynamic transform shifts the values of the registers as defined by the PRBS polynomial <NUM>. The triggering of the shift is performed at every cycle of the clock or every several clock cycles.

The PRBS of <FIG> includes <NUM> bits and is applied directly to the output of the first hash SHA transform. This way, the DT changes every cycle, but in a predictable manner that may be reproduced for validating proof-of-work.

In some embodiments, when applying the dynamic transform to a given variable, an XOR logical operation is performed for each bit of the given variable with the corresponding bit of the shift register <NUM> of the dynamic transform. If the shift register <NUM> for bit <NUM> is <NUM> and bit <NUM> of the given variable is <NUM>, then the resulting bit <NUM> of the result will be <NUM> (e.g., the logical XOR of <NUM> and <NUM>).

<FIG> illustrates the process for calculating the next dynamic transform when using partial PRBS, according to some embodiments. In some embodiments, a PRBS, with a fewer number of registers than bits in the static transform, is used by combining the PRBS with other values, such as some bits from the static transform (e.g., first <NUM> bits from the static transform) or some constant bits (e.g., first <NUM> bits set to alternating zeros and ones).

As illustrated in <FIG>, a first portion of the dynamic transform is set to a fixed value, such as the beginning (or some other section) of the static transform, all zeros, all ones, alternating zeros and ones, and so forth. The second portion of the dynamic transform is implemented using a PRBS (e.g., PRBS31 with <NUM> registers).

When the CLK <NUM> triggers the updating of the dynamic transform, the fixed registers <NUM> do not change and the PRBS registers <NUM> change according to the PRBS polynomial <NUM>. The resulting updated dynamic transform is then used for the next transform operation.

<FIG> illustrates the calculation of the next dynamic transform when using the value of the previous first SHA transformation, according to some embodiments. In some embodiments, the dynamic transform is based on the transform value resulting from the hash of the previous checked header (e.g., the header with a nonce value equal to the current nonce value minus one, and not the header from the previous blockchain).

The value of the transform value is saved and then the dynamic transform is configured with the transform value for the next proof-of-work check of the header. This way, if the golden nonce is found, it is easy to know the value of the dynamic transform used to calculate the header with the golden nonce because the dynamic transform is equal to the hash of the header with a nonce equal to the previous value of the nonce (e.g., nonce - <NUM>).

In some embodiments, after the first hash <NUM> of the header <NUM> is performed, the value is stored in registers. After the dynamic transform <NUM> is applied to the transform value (result from hash <NUM>), the dynamic transform is updated <NUM> after a predetermined delay (e.g., in the next clock cycle).

This way, the dynamic transform is dynamic because it changes with every nonce value. Trying to reproduce the same process in software would be much slower than when using the core <NUM> (e.g., an ASIC device). Thus, a malicious user that tried to perform the validation quickly to attack the block chain network would not be able to perform the calculations faster in software than in hardware and would not be able to attack the blockchain network.

In some embodiments, the initial value for the dynamic transform may be set as the OWF of the header with (nonce-<NUM>) for consistency, but other initial values may also be used (e.g., all zeros, all ones, or alternating zeros and ones).

The update of the dynamic transform using the transform value of the previous header may also be combined with the use of PRBS, as described above with reference to <FIG> and <FIG>. The dynamic transform could be updated by performing an XOR of the updated PRBS value and the transform value.

<FIG> illustrates the process for validating proof of work, according to some embodiments. After a node finds the golden nonce that meets the target requirement, the node sends the header to other nodes for validation. Each receiving node then validates the proof-of-work by recalculating the validation parameter and verifying the validation target.

The input message <NUM> includes the golden nonce <NUM>. At operation <NUM>, the delta, or difference, between the golden nonce <NUM> and the initial nonce <NUM>, which is the value of the nonce received by the core <NUM> to start checking headers, is calculated, which results in a value of delta nonce <NUM>. In some embodiments, operation <NUM> is optional if the dynamic transform is not a function of the initial nonce <NUM> (e.g., dynamic transform is based on the transform value of the previous nonce as described with reference to <FIG>).

Additionally, as described earlier, the OWF <NUM> of the passphrase <NUM> results in the static transform <NUM>. At operation <NUM>, the dynamic transform value is calculated based on the delta nonce <NUM>, the static transform <NUM>, and the input message <NUM>. Calculating the dynamic transform requires following the same process followed for POW. However, when doing POW, the core <NUM> dynamically changes the dynamic transform for each nonce value, so calculating the dynamic transform for the given golden nonce <NUM> requires replicating this process. When using PRBS, the value of the random number for the given nonce is calculated to determine the dynamic transform.

In the embodiment of <FIG>, the dynamic transform is calculated as the OWF of the header with a nonce value equal to (golden nonce - <NUM>).

Once the dynamic transform is calculated, the header is validated by performing the SHA <NUM><NUM>, followed by the DT <NUM>, and a second SHA <NUM><NUM>, which results in the validation parameter, which is then validated at operation <NUM> to determine if the required number of leading zeros is present. The result <NUM> indicates if the validation has been successful or not.

One of the advantages of the operation of the DT with PRBS is that it makes replicating the operation in software straightforward by utilizing a software program that implements PRBS, such as the srand() function in the Linux implementation of the C programming language.

In some example embodiments, replicating the DT in software includes the following operations: selecting part of the header, using the selection as the seed of the srand() function, and using the result of the srand() function for the POW operation.

In some example embodiments, using the result of the srand() function for the POW operation may be performed in software as follows:.

This approach results in the following benefits:.

<FIG> illustrates an integrated circuit <NUM> with a plurality of cores <NUM> for proof-of-work operations, according to some embodiments. The IC <NUM> also includes controller <NUM> that manages operations of the cores <NUM>.

The controller communicates with the different cores <NUM> and assigns POW tasks to the different cores. To validate a header <NUM>, the controller assigns POW tasks to the different cores by assigning a different starting nonce value. If a core <NUM> finds the golden nonce, then the core <NUM> communicates to the controller that the nonce has been found via output <NUM>. The controller then stops the other cores from the POW and assign a new task.

The controller <NUM> includes input/output (I/O) ports <NUM>, Process-Voltage-Temperature (PVT) <NUM>, efuse <NUM>, SHA <NUM><NUM>, manufacture efuse <NUM>, framer <NUM>, memory <NUM>, processor <NUM>, and Phase-Locked Loop (PLL) <NUM>. The memory may include program instructions that may be executed by the processor <NUM>.

Further, a level shift <NUM> separates the voltage level of the controller from the voltage levels of the cores, which operate at a lower level. One of the goals of POW is to use as little energy as possible, so having cores <NUM> that perform at low voltage allows calculating hashes using a small amount of energy. The framer <NUM> communicates with, assigns tasks to, and receives results from the cores <NUM>.

In the embodiment of <FIG>, the core <NUM> includes a dynamic transform <NUM> and a second transform <NUM>, which is a static transform. In other embodiments, the static transform is not included. Further, one or more dynamic transforms <NUM> may be combined with one or more static transforms <NUM>, in any order, in order to generate the validation parameter. As long as the process can be reproduced by a similar integrated circuit, any combination is possible. In some embodiments, the static transform is performed ahead of the dynamic transform <NUM>.

It is noted that the embodiments illustrated in <FIG> do not describe every possible embodiment. Other embodiments may utilize different modules, distribute functionality across multiple modules, combined functionality of two or more modules, etc..

<FIG> illustrates a programmable transformation block <NUM> configuration prior to being coded, in accordance with embodiments of the technology disclosed herein. The programmable transformation block <NUM> includes sets of programmable circuitry defining the transformation function represented by the configuration key <NUM> (illustrated in <FIG>). In various embodiments, the programmable transformation block <NUM> is configured to enable one of a plurality of transposition operations, whereby one or more bits of input data (e.g., 1a1, 1b1) are transposed with another bit of the input data to generate a modified output data (e.g., 5a1, 5b1). In other embodiments, the programmable transformation block <NUM> is configured to enable one of a plurality of direct bit inversion, or bit flipping, operations, whereby one or more bits of input data are flipped to generate modified output data.

Various embodiments utilizing a direct bit inversion transformation scheme as described herein may be implemented to take advantage of the fact that a <NUM>-bit binary configuration key provides a succinct means to enable access to the full key space provided by the programmable transformation function (e.g., static transform <NUM>). That is, <NUM> bits is the minimum length necessary to enable the user to specify which one among <NUM> distinct transformations is to be performed by the programmable transformation function <NUM> on the first hash <NUM> or used to initialize the dynamic transform. Using a direct bit inversion transformation scheme may also enable the use of a minimal amount of new circuit elements to embody the transformation function as datapath circuitry. This is important because the fact that the transformation function is embodied as datapath circuitry means that any additional circuitry placed on the datapath will operate at line speed and result in an overall degradation of the performance of the transform-enabled integrated circuit <NUM> as a whole.

A direct bit inversion transformation scheme may also provide a straightforward means to disable all effects of the programmable transformation by simply setting all values in the <NUM> bit configuration key to zero. Such a key may be referred to as a null key. One result of this is that it simplifies the process of configuring a transform-enabled integrated circuit <NUM> so that it operates in a manner undistinguishable from that of a comparable integrated circuit not incorporating the programmable transformation function. The practical result of this is that integrated circuits incorporating the technology described herein may easily be configured to operate in the same manner as standard bitcoin mining ASICs and be used to mine bitcoins with no particular difficulty, (aside from and in addition to being able to operate in manners that are not replicable by bitcoin mining ASICs not incorporating the technology described herein).

For ease of discussion, <FIG> are discussed with reference to a direct bit inversion configuration, but other configurations may also be applied (e.g., combining two bits from the configuration key to configure one bit of the static transform).

The coding of the programmable transformation block is illustrated in <FIG>. The programmable transformation block <NUM> is shown being coded in accordance with the configuration key <NUM>. To indicate the configuration key <NUM> embodied within the programmable transformation block <NUM>, shaded boxes are used to indicate that a micro-fuse has been disabled (e.g., stopping data from flowing through the disabled micro-fuse). When micro-fuse 3a1 is disabled, the input bit 1a1 flows through the programmable transformation block <NUM> unchanged because the input bit 1a1 travels through micro-fuse 2a1 unchanged. The result is that output bit 5a1 is equal to input bit 1a1.

When micro-fuse 2b1 is disabled, the input bit flows through the micro-fuse 3b1 and then is inverted by the bit flipper 4b1, and the result is bit 5b1 that is equal to 1b1 inverted.

<FIG> is a flowchart of a method <NUM> for performing proof-of-work operations, according to some embodiments. While the various operations in this flowchart are presented and described sequentially, one of ordinary skill will appreciate that some or all of the operations may be executed in a different order, be combined or omitted, or be executed in parallel.

At operation <NUM>, a header is received. From operation <NUM>, the method flows to operation <NUM> for initializing a nonce register with a nonce value.

Further, at operation <NUM>, a first OWF is performed to generate a hash of the header, that includes the nonce value, for POW validation of the header.

From operation <NUM>, the method flows to operation <NUM> for performing a dynamic transform to transform the hash of the header resulting in a transform value. In some embodiments, the transformation by the dynamic transform is based on the nonce value.

From operation <NUM>, the method flows to operation <NUM> where a second OWF is performed to generate a hash of the transform value resulting in a validation parameter.

Operation <NUM> is for determining, based on the validation parameter, if the POW meets a predetermined target for validation of the header with the nonce value.

Performing the dynamic transform comprises performing a logical XOR operation of each bit of the hash of the header with a corresponding bit value associated with the dynamic transform.

The method <NUM> further comprises calculating a static transform binary value based on a passphrase, and initializing a dynamic transform circuit, for performing the dynamic transform, with a value based on the nonce value and the static transform binary value.

The method <NUM> further comprises, when the validation parameter does not meet the predetermined target, incrementing the nonce value in the nonce register, and using a new header, after incrementing the nonce value, for a new POW operation. the The dynamic transform is performed by a dynamic transform circuit that comprises one or more LFSRs, and the method <NUM> further comprises updating the LFSRs, before the new POW operation, based on a PRBS.

<FIG> is a block diagram illustrating a machine upon or by which one or more example process embodiments described herein may be implemented or controlled. The machine <NUM> may act as a peer machine in a peer-to-peer (P2P) (or other distributed) network environment. Further, while only a single machine <NUM> is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as via cloud computing, software as a service (SaaS), or other computer cluster configurations.

Embodiments may include, or may operate by, logic, a number of components, or mechanisms. Circuitry is a collection of circuits implemented in tangible entities that include hardware (e.g., simple circuits, gates, logic). Circuitry membership may be flexible over time and underlying hardware variability. Circuitries include members that may, alone or in combination, perform specified operations when operating. Hardware of the circuitry may be immutably designed to carry out a specific operation (e.g., hardwired). Hardware of the circuitry may include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.) including a computer-readable medium physically modified (e.g., magnetically, electrically, by moveable placement of invariant massed particles, etc.) to encode instructions of the specific operation. In connecting the physical components, the underlying electrical properties of a hardware constituent are changed (for example, from an insulator to a conductor or vice versa). The instructions enable embedded hardware (e.g., the execution units or a loading mechanism) to create members of the circuitry in hardware via the variable connections to carry out portions of the specific operation when in operation. Accordingly, the computer-readable medium is communicatively coupled to the other components of the circuitry when the device is operating. Any of the physical components may be used in more than one member of more than one circuitry. Under operation, execution units may be used in a first circuit of a first circuitry at one point in time and reused by a second circuit in the first circuitry, or by a third circuit in a second circuitry, at a different time.

The machine (e.g., computer system) <NUM> may include a hardware processor <NUM> (e.g., a central processing unit (CPU), a hardware processor core, or any combination thereof), a graphics processing unit (GPU) <NUM>, a main memory <NUM>, and a static memory <NUM>, some or all of which may communicate with each other via an interlink (e.g., bus) <NUM>. The machine <NUM> may further include a display device <NUM>, an alphanumeric input device <NUM> (e.g., a keyboard), and a user interface (UI) navigation device <NUM> (e.g., a mouse). In an example, the display device <NUM>, alphanumeric input device <NUM>, and UI navigation device <NUM> may be a touch screen display. The machine <NUM> may additionally include a mass storage device (e.g., drive unit) <NUM>, a signal generation device <NUM> (e.g., a speaker), a network interface device <NUM>, and one or more sensors <NUM>, such as a Global Positioning System (GPS) sensor, compass, accelerometer, or another sensor. The machine <NUM> may include an output controller <NUM>, such as a serial (e.g., universal serial bus (USB)), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate with or control one or more peripheral devices (e.g., a printer, card reader, etc.).

The mass storage device <NUM> may include a machine-readable medium <NUM> on which is stored one or more sets of data structures or instructions <NUM> (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions <NUM> may also reside, completely or at least partially, within the main memory <NUM>, within the static memory <NUM>, within the hardware processor <NUM>, or within the GPU <NUM> during execution thereof by the machine <NUM>. One or any combination of the hardware processor <NUM>, the GPU <NUM>, the main memory <NUM>, the static memory <NUM>, or the mass storage device <NUM> may constitute machine-readable media.

While the machine-readable medium <NUM> is illustrated as a single medium, the term "machine-readable medium" may include a single medium, or multiple media, (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions <NUM>.

The term "machine-readable medium" may include any medium that is capable of storing, encoding, or carrying instructions <NUM> for execution by the machine <NUM> and that cause the machine <NUM> to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding, or carrying data structures used by or associated with such instructions <NUM>. Machine-readable medium examples may include solid-state memories, and optical and magnetic media. A massed machine-readable medium comprises a machine-readable medium <NUM> with a plurality of particles having invariant (e.g., rest) mass. Accordingly, massed machine-readable media are not transitory propagating signals. Specific massed machine-readable media may include non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

Claim 1:
An integrated circuit (<NUM>, <NUM>) comprising:
a nonce register (<NUM>) for storing a nonce value (<NUM>);
a first one-way function, OWF, (<NUM>, <NUM>) circuit configured to generate a hash (<NUM>) of a header (<NUM>), the header (<NUM>) including the nonce value (<NUM>) for proof-of-work, POW, validation of the header (<NUM>);
a dynamic transform (<NUM>) circuit configured to transform the hash (<NUM>) of the header (<NUM>) to generate a transform value, the transformation by the dynamic transform (<NUM>) circuit including performing a logical operation on the hash (<NUM>) with the nonce value (<NUM>); and
a second OWF (<NUM>, <NUM>) circuit configured to generate a hash of the transform value to obtain a validation parameter, the validation parameter determining whether the POW meets a predetermined target for validation of the header (<NUM>) with the nonce value.