Block chain complier

Abstract

To provide a method of and a system for executing or promoting a part of source codes described by a high-level language (HLL) on a block chain platform.SOLUTION: A system according to the present invention includes a block chain complier for converting a high-level source code into a format which can be used in a block chain platform. A method according to the present invention has steps of receiving a source code, and generating an output script including a plurality of opcodes. The output script is generated so as to provide a function designated in the source code. The output script generating step has a step of expanding at least loop configuration provided in the source code. The method also has a step of providing or using an interpreter or a virtual machine configured so as to convert the output script into a format executable in the block chain platform.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates generally to distributed ledger technology, and more particularly to blockchain technology, such as the Bitcoin network or related protocols. The present disclosure also relates to compilers and compiler-related technology for the translation of computer-based code. One or more embodiments of the present invention are suitable for use as a solution for enabling and / or facilitating the automation and execution of high-level programs on blockchain platforms or protocols, including functionally constrained script-based languages. [Background technology]

[0002] The term "blockchain" is used herein to include all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. While Bitcoin is referred to herein for convenience and illustrative purposes, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention. The term "user" may refer to a human or computer-based resource.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized, distributed system composed of blocks. Blocks, in turn, are composed of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and includes at least one input and at least one output. Each block contains a hash of the previous block, and blocks chain together to create a permanent, immutable record of all transactions written to the blockchain since its inception. Transactions contain small programs known as scripts embedded in their inputs and outputs. Scripts specify how and by whom the transaction's outputs can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language called Script. Scripts are written using commands (opcodes), which are converted into executable code by an interpreter.

[0004] In order for a transaction to be written to the blockchain, it must be "verified." Network nodes (miners) perform work to ensure each transaction is valid; invalid transactions are rejected by the network. Software clients installed on nodes perform this validation work on unspent transactions (UTXOs) by running their own locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to true, and the checks pass, the transaction is valid and is mined for inclusion in the blockchain. Thus, for a transaction to be written to the blockchain, it must i) be verified by the first node that receives the transaction; if the transaction is verified, the node relays the transaction to other nodes in the network; ii) be added to a new block constructed by miners; and iii) be mined, i.e., added to the public ledger of past transactions.

[0005] While blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are beginning to explore the use of both Bitcoin's underlying cryptocurrency security system and the data that can be stored on the blockchain to implement new systems. It would be highly advantageous if blockchain could be used for automated tasks and processes not limited to the cryptocurrency realm. Such solutions could leverage the benefits of blockchain (e.g., permanent, tamper-resistant records of events, distributed processes, etc.) while being more diverse in their uses. Thus, there is a need for widespread adoption and innovation of the technology for new applications, similar to the early adoption of the internet and the subsequent rapid growth in the development of web-based systems.

[0006] However, writing programs in such scripting languages ​​is not intuitive or readily adoptable by the broader programming community because, for example, they require knowledge and expertise related to low-level programming techniques. This requires the programmer to consider stacks and the location of data within them. Writing programs composed of low-level opcodes is more time- and labor-intensive than writing source code in a high-level language (HLL) such as C, Java, etc. Compilers / interpreters built for such HLLs provide a convenient level of abstraction that insulates programmers from many of the tedious low-level issues associated with memory management and the like. Writing sequences of opcodes to manipulate data in one or more stacks is technically more complex and time-consuming than writing source code in an HLL. Therefore, the difficult nature of using low-level opcodes makes errors and bugs more likely.

[0007] Furthermore, HLLs allow programmers to include complex control flow constructs such as loops, case statements, and iterative calls in their source code. Programmers can focus on the desired logic and express logical flow in an intuitive way through mechanisms such as "while this is true, do X...". However, some blockchain-related scripting languages, such as Bitcoin's Script, are functionally constrained in the sense that while they include typical operations such as arithmetic operations and cryptographic functions such as hashing and signature verification, they do not include native primitives for complex control structures such as while loops or allow the use of iterative techniques that are available in HLLs. Such constrained languages ​​do not support jump-based control flow. Thus, by design, they constrain the language and logical constructs offered to programmers for inclusion in source code. This has led some to argue that constrained languages ​​like Script are Turing-incomplete, but this definition has been disputed by others. Hence, we use the term "functionally constrained."

[0008] Note that this intentional constraint may make the coding process more difficult for the programmer, but it also provides an important security mechanism, as it limits program execution time and, importantly, protects against malicious means, e.g., the use of infinite loops to perform Denial of Service (DoS) attacks.

[0009] Thus, there is a trade-off between critical security and the need to facilitate, encourage, and improve the development of blockchain-based technologies. To solve the latter problem, Ethereum has incorporated an HLL language as an inherent feature into its blockchain platform. Similar to Script, a low-level interpreter is required to generate an executable version of the code. Ethereum's HLL language, known as Ether, enforces control flow through the use of conditional and unconditional jumps. It also allows for iteration. To avoid problems like denial-of-service attacks, Ethereum limits transaction execution time by introducing the concept of gas, a portion of cryptocurrency paid in advance to cover execution costs. Therefore, the use of an inherent HLL requires an additional layer of technical and commercial complexity. Furthermore, Ethereum has suffered from at least one significant iteration-based attack to date. See, for example, http: / / hackingdistributed.com / 2016 / 06 / 18 / analysis-of-the-dao-exploit /

[0010] It would therefore be desirable to provide a mechanism by which programmers can develop, design, and produce effective blockchain solutions in an easier, faster, and more efficient manner, using HLL languages ​​that are familiar to programmers, but without compromising the security offered by functionally limited scripting languages. This is by no means a trivial task and requires significant technical innovation. This is, among other things, one of the technical problems solved by the present disclosure. Summary of the Invention

[0011] Thus, in accordance with the present disclosure, there is provided a system and corresponding method as defined in the accompanying claims.

[0012] Thus, in accordance with the present invention, a computer-implemented method and corresponding system may be provided. The method may be configured to enable or facilitate execution of portions of source code on a blockchain platform. The source code may be written in a high-level language. The present disclosure describes compilation techniques and systems / components that may be implemented as a software compiler, which may hereinafter be referred to as a "blockchain or Bitcoin compiler." The software compiler may be configured for use in connection with the Bitcoin blockchain or any other blockchain-based protocol / network.

[0013] Advantageously, the software compiler of the present disclosure may enable users (programmers) to write and generate blockchain-executable programs / applications in a language familiar to them, e.g., C-, Java-, or C++-style syntax. This opens up blockchain-based development efforts to a wider development community. This also means that blockchain-based solutions can be written more quickly and error-checked with the present invention, as described in more detail below. Importantly, the security features of the underlying protocol and associated scripting language are preserved and maintained. Thus, the present invention provides techniques and systems that preserve the security associated with blockchains during the script generation process, facilitating or enabling the generation of valid, error-free scripts (and therefore transactions) that can be verified by nodes on the blockchain network.

[0014] According to one possible embodiment, a computer-implemented method may be provided that uses static compilation to convert a portion of source code into a blockchain-compatible script. This may form an output provided by the compiler, which may be referred to as an "output script." The method may test for one or more errors. The method may provide a warning if one or more errors are detected. The static compilation may include a loop unrolling step, in which one or more loops provided in the portion of source code are unrolled. It is noted that the terms "static compilation" and "loop unrolling" are conventional terms and are readily understood by those skilled in the art.

[0015] The method may be configured for use with a blockchain network. The blockchain network may be associated with a protocol. It may be a "proof-of-work" blockchain. It may be a consensus-based blockchain. It may be a public and / or permissionless blockchain. It may be a peer-to-peer decentralized blockchain.

[0016] The blockchain network may include a plurality of nodes that validate blockchain transactions. The blockchain transactions may include a script executable by the plurality of nodes. The script may be represented by or include a set of opcodes (op_codes) belonging to a functionally constrained (also referred to as Turing-incomplete) blockchain scripting language. The method may include generating an output script for inclusion in a blockchain transaction validated by the nodes of the blockchain network. The output script may be represented by a set of opcodes belonging to the functionally constrained blockchain scripting language, and the output script may be configured or adapted such that execution of the script by the nodes of the blockchain network performs a function specified in the source code.

[0017] Portions of the source code may be written in a high-level language (HLL). The HLL may be described as a compilable HLL. The HLL may be compiled by a software component (compiler) configured in accordance with the present invention. The HLL may be compiled by the compiler to generate a script executable by an interpreter. The script may be provided to a blockchain transaction (Tx). The script may be associated with the input or output of the transaction. The HLL may be a Turing-complete language (subject to real-world constraints) that may allow expressions, constructs, and / or statements that implement complex control flow, such as iterations, complex selection constructs, and / or loops. Syntax specific to the HLL may include loop-related constructs, such as WHILE, FOR, or REPEAT loops. This may include primitives for performing cryptographic, arithmetic, and stack manipulation operations. The HLL may include customized opcodes and / or high-level language constructs, substantially as described below.

[0018] A blockchain-compatible script may be a script (i.e., a program) formed of opcodes inherent in and / or forming part of a blockchain scripting language selected from a blockchain scripting language executable on the blockchain. The opcodes may be referred to as primitives or commands. The script may pass through an interpreter or virtual machine before being executed / made executable on the blockchain. (The term "blockchain" in this context may include protocols and implementation platforms.) The interpreter may convert the script into machine-executable (object) code. The blockchain scripting language may be, for example, the Script language used in connection with the Bitcoin protocol or variants thereof. The scripting language may be configured for use with the blockchain protocol. The scripting language may include cryptographic, arithmetic, and stack manipulation opcodes.

[0019] A blockchain scripting language may be functionally constrained. A blockchain scripting language may be limited in terms of the functions that its syntax / interpreter allows or is configured to handle. It may not natively support complex control flows such as iterations, complex selection constructs, and / or loops.

[0020] Additionally or alternatively, a method may be provided for enabling or facilitating the execution of portions of source code written in a high-level language (HLL) on a blockchain platform. The source code may be configured to implement a smart contract. The smart contract may be a machine-readable, executable application that can be run on a blockchain as known in the art.

[0021] The method may include receiving as input a portion of source code, the portion of source code may be received by a software implemented compiler.

[0022] The method may include generating an output script. The output script may be a blockchain-compatible script as described above. The output script may include a plurality of opcodes selected from and / or specific to a functionally constrained blockchain scripting language. The scripting language may be as described above. When executed, the script may provide, at least in part, functionality specified in the source code.

[0023] The method may include providing or using a compiler configured to perform any embodiment of the method described above. The output script may be generated by performing static compilation.

[0024] The use of static compilation offers the advantage that the resulting script always stops. This not only provides a practical advantage in runtime, but also allows the present invention to function as a verification tool, as the blockchain compiler will stop if it encounters any kind of error or invalid construct in the source code. The advantage of being able to use a verification tool during script development means that programming efforts are improved by reducing the programmer's time and effort. Furthermore, the blockchain compiler offers a security solution in that it tests for bugs and overflow errors, allowing users (programmers) to statically test whether a program will run and whether it will run safely.

[0025] The blockchain scripting language may be limited in that it does not natively support complex control flow constructs or iteration through jump-based loops or other iterative programming constructs. Generating the output script may include unrolling at least one loop construct provided in the source code. The method may include providing or using an interpreter or virtual machine configured to convert the output script into a format executable on the blockchain platform.

[0026] The method may further include optimizing the output script at least once to provide a more efficient or reduced version of the output script. This may include using derivative free optimization (DFO). DFO is a term known in the art and readily understood by those skilled in the art. Additionally or alternatively, generating the output script may include using derivative free optimization.

[0027] The blockchain compiler may be configured to form part of and / or operate in conjunction with a software development kit (SDK), which may include editors, debuggers, and other known components to be used in conjunction with the SDK to facilitate the creation of code-based solutions.

[0028] The HLL may include at least one primitive, operator, or construct that is directly translatable to one or more primitives / commands / opcodes native to the blockchain scripting language.

[0029] A blockchain scripting language may be based on a stack. The blockchain scripting language may be configured to manipulate one or more stacks. The HLL may include one or more primitives or operators configured to cause the execution of operations on the stacks used by the scripting language.

[0030] The HLL may include a primitive or construct configured to push a number of inputs to the source code onto a stack used for memory allocation by the blockchain scripting language. The HLL may include one or more primitives configured to cause execution of cryptographic operations or functions, arithmetic operations, and / or loops.

[0031] The HLL may include at least one of the following primitives or operators or their respective functional equivalents: Initiate; Declare; Increment; IF; While; Populate; Monus; Reset; Rawscript; Abort; Retrieve Hash, hash160, or any hash operation or variant thereof.

[0032] The present disclosure may provide a method that includes using static compilation to convert portions of source code into a blockchain-compatible script. The static compilation may include a loop unrolling step.

[0033] The portion of the source code may include at least one high-level programming construct. The output script may be generated by converting the high-level programming construct into one or more opcodes belonging to a functionally constrained blockchain scripting language. The one or more opcodes of the output script may be configured or adapted such that execution of the one or more opcodes by a node of the blockchain network executes (the functionality of) the at least one high-level programming construct of the source code.

[0034] Preferably, the functionally constrained blockchain scripting language does not support loop constructs. Preferably, at least one high-level programming construct includes a loop construct. Preferably, the script is generated by unfolding a loop construct (which may also be referred to as a "loop construct"). Preferably, the loop construct includes a code block and an argument specifying a number of iterations, and unfolding the loop construct includes writing an opcode for the function of the code block for the number of iterations.

[0035] The method may further include checking the syntax of the loop construct to ensure that it includes an argument specifying the number of iterations and that the argument satisfies a constraint specifying the maximum number of iterations.

[0036] The loop construct may include a code block and a condition for specifying a number of iterations of the loop construct based on at least one variable. Preferably, unrolling the loop construct includes duplicating opcodes of the function of the code block in conjunction with writing opcode commands that selectively execute the duplicated opcodes of the function of the code block for a maximum number of iterations based on evaluation of the condition using the value of the variable determined from execution of the output script.

[0037] According to the present disclosure, there is provided a computer-implemented system configured to perform the steps of any of the embodiments of the methods described herein.

[0038] A computer-implemented system according to one embodiment of the present disclosure may include a compiler. The compiler may be configured to receive as input a portion of source code. The source code may be written in a high-level language (HLL). The compiler may be configured to generate an output script. The output script may be referred to as a "blockchain script" or a "blockchain-compatible script" and may include a number of opcodes. These opcodes may be selected from and / or specific to a functionally constrained blockchain scripting language, such as those described above, and when executed, the script provides functionality specified, at least in part, in the source code.

[0039] The system may include a software development kit (SDK), and the compiler may form part of the SDK.

[0040] The present invention also provides a system comprising a processor and a memory containing executable instructions that, upon execution by the processor, cause the system to perform any embodiment of the computer-implemented method described herein.

[0041] The present invention also provides a non-transitory computer-readable storage medium having stored thereon executable instructions that, when executed by a processor of a computer system, cause the computer system to perform at least one embodiment of a computer-implemented method described herein.

[0042] Any feature described above in connection with one embodiment or aspect of the present disclosure may be applied to one or more other embodiments or aspects, and any feature described in connection with a method of the present disclosure may be equally applied to a system of the present disclosure, and vice versa.

[0043] These and other aspects of the present disclosure will be apparent from and will be taught with reference to the embodiments described herein, which are described hereinafter, by way of example only, with reference to the accompanying drawings, in which: [Brief explanation of the drawings]

[0044] [Figure 1] 1 shows an outline of the present invention. [Figure 2] Provide a code block that populates the Try[] array, which will be discussed in conjunction with the following example of unrolling a while loop. [Figure 3] 1 illustrates a blockchain environment in which various embodiments may be implemented. [Figure 4] 1 illustrates a blockchain protocol for validating and mining spending blockchain transactions that reference previous blockchain transactions, according to one embodiment. [Figure 5] 1 illustrates a computing environment in which various embodiments may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0045] <Summary> In the following, we may refer to the Bitcoin protocol, blockchain, network, or scripting language for ease of reference, as it is the most widely known and adopted. However, the present invention is not limited to use with Bitcoin-related blockchains, and other blockchain technologies are within the scope of this disclosure.

[0046] As mentioned above, most programmers today write code in high-level languages ​​such as C, C++, Java, etc., rather than at a low level. Writing code at a low level takes more time, requires more specialized knowledge for memory manipulation, and can result in the introduction of errors. Therefore, it would be advantageous for programmers to be able to write valid, tested, error-checked code for blockchain applications in a language more familiar to them, without jeopardizing the security provided by the underlying, constrained scripting language.

[0047] The methods and systems described herein enable the development of an "SDK" for the creation of specialized blockchain transactions or clusters of transactions. For example, the transactions may be intended to automatically enforce the terms and conditions of a machine-executable smart contract. However, many other applications are possible, and the invention is not limited in this respect. Thus, the present invention may form part of a "toolkit" or system for creating and testing blockchain-related technologies.

[0048] Advantageously, the blockchain compiler performs static compilation of a user's source code, enabling the implementation of complex control flow mechanisms through the use of techniques such as loop unrolling. As known in the art, "loop unrolling" may also be referred to as "loop unwinding." Loop unrolling is a loop transformation technique that can be used by a compiler to reduce the frequency of branches and / or reduce loop maintenance instructions within certain types of loops. By unrolling loops found in the source code, the compiler can generate a transformed version of the source code, which can be executed on a blockchain platform that uses a functionally constrained scripting language.

[0049] Referring to FIG. 1 , one embodiment of the present disclosure allows a user (programmer) to define code 1010 for a desired application, e.g., a smart contract, using a high-level language (HLL) and then run a blockchain compiler 102 that compiles the HLL code 101 into an executable file. These executable files may be in the form of chunks of 3G language programs (such as Python, C++, etc.) that can be run by a bot. Alternatively, they may be in the form of chunks of (e.g., Bitcoin) script 103. The latter is achieved by designing and generating chunks of script that can perform specific functions. For example, the original version of Bitcoin script included a function for multiplication called OP_MUL. This opcode is now disabled. However, the same functionality can be recreated by using existing valid opcodes in small script sections.

[0050] Embodiments of the present disclosure may include one or both of the following two types of primitives: Customized opcode (hereafter referred to as COP_CODE), ·High Level Language (HLL) configuration.

[0051] HLL constructs require a compiler 102 to convert them into script code 103. COP_CODE, on the other hand, only requires a direct substitution of COP_CODE for blocks of OP_CODE. Typically, a primitive is made into COP_CODE if it does not require access to variables, i.e., it can be written entirely using only OP_CODE and hard-coded inputs that already exist in the blockchain scripting language for the given protocol (and other COP_CODE).

[0052] For example, the monus primitive can be fully described by its opcode, thus resulting in the following COP_CODE: OP_SUB OP_0 OP_MAX

[0053] However, the execution of a WHILE loop depends on required variables (e.g., a condition for execution, a counter for the number of iterations, etc.), so WHILE is not suitable for being a COP_CODE and is written as an HLL construct.

[0054] Advantageously, combining the two types of primitives provides additional flexibility to programmers. Programmers who write programs directly in Bitcoin Script (i.e., without using an HLL) can use COP_CODE to provide extended scripting capabilities. In effect, these provide script programmers with replacements for blocks of OP_CODE that perform the functions they need, reducing programming time and effort. All that is needed is a "COP-CODE compiler" that simply replaces COP_CODE with the blocks of OP_CODE that make up the COP_CODE. Programmers who cannot or do not want to program in low-level Bitcoin Script can instead use the HLL supported by this disclosure.

[0055] Customized OP_CODE (COP_CODE) is discussed further below.

[0056] (1) Customization OP_CODE (COP_CODE) This section below describes standards that may be applied in accordance with this disclosure in relation to script primitives for customized OP_CODE (COP_CODE). COP_CODE has the same given format as regular opcodes and behaves in the same way. That is, Script (and / or compiler) writers use primitives in the same way they traditionally use opcodes. A list of Bitcoin opcodes can be found on the Bitcoin wiki: https: / / en.bitcoin.it / wiki / Script. Naming conventions Script primitives are named here in a similar manner to Bitcoin Script opcodes: COP_xxx Here, "xxx" is shorthand for the function. For example, a multiplication function might be named COP_MULT. Further, similar to opcodes, if the function has a specific number of parameters or specific numerical values ​​used in the calculation, the name may incorporate that number. For example, the opcode "OP_2DROP" means "remove the top two stack items," while "OP_1ADD" means "1 is added to the input." Thus, COP_2MULT specifically means "the input is multiplied by 2." ●Verification before execution If a particular number of inputs or a particular input format is expected, the primitive performs a check before executing its functional logic and aborts (marks the transaction as invalid) if the inputs do not match the expectations. Advantageously, this prevents the function from executing and providing an output that may be incorrect or false. For example, if a particular primitive is intended to operate only on inputs that are positive numbers, but nevertheless executes without error on negative numbers, the result may be a "valid transaction," but with unexpected or incorrect results.

[0057] (2) High-Level Language (HLL) Configuration These are functions or statements that a compiler according to the present disclosure can recognize and translate into BitcoinScript. Taken together, they constitute a high-level programming language with a syntax familiar to programmers. As well as familiar constructs (e.g., IF-ELSE, CASE, WHILE loops, etc.), there are also unfamiliar constructs that are very specific to HLLs, due to the way Bitcoin transactions work. For example, the INITIATE construct is a very specific function that ensures that the number of data inputs automatically pushed onto the main stack is stored as the first constant in memory allocations (assigned to the reserved word NUM_INPUTS). In an embodiment, the INITIATE construct may be the first statement in an HLL program, and the DECLARE construct (which performs memory allocation for constants and variables) may be the second statement in an HLL program.

[0058] HLL constructs must be designed so that they can be translated by the compiler into Bitcoin script (i.e., into OP_CODE and COP_CODE) using only the information available at compile time. This usually means a lot of hard-coding by the programmer, where constants are declared (DECLARE) and assigned values ​​in the program. For example, even though NUM_INPUTS is considered a constant, the compiler does not have access to its value until the program is run. Therefore, it is not available for compilation (although of course the programmer can use it like any other constant in the program).

[0059] When designing an HLL construct, the designer can include in the pseudocode or clear description in natural language the expected behavior of the compiler. For example, the compiler may be required to perform certain checks such as verification of compliance with correct syntax and any constraints (such as size limits). This should be clear even if the specific constraints are not yet known. The task of designing an HLL construct does not include writing the compiler itself, but must ensure that all expected behaviors of the compiler are possible.

[0060] A selection of HLL constructs that can be used according to embodiments for the description of the present disclosure is provided below. <HLL construct: WHILE loop> ● Description The code block (or code-block, commonly called the loop body) is repeatedly executed up to a maximum number of iterations as long as the specified condition is true. The maximum number of iterations must be known and specified at compile time. The loop is emulated by a technique known as "unrolling the loop". This means that a sequence of opcodes representing the functionality (sequence of operations) of the code block is replicated up to the specified maximum number of iterations. An IF statement preceding each replicated sequence of opcodes of the code block determines whether the sequence of opcodes of the code block is to be executed. The IF condition is checked at the beginning of the loop (i.e., before the first execution of the sequence of opcodes of the code block).

[0061] ● Syntax:

Number

[0062] ●Compiler operation: Perform a syntax check. Check that iterations satisfy any constraints (e.g., they are within a given range). Checks that the expression in the Condition can be evaluated. All constants / variables in an expression are present in the memory allocation (DECLARE) list. Check that all operators used within the expression are currently allowed (=, <, >, etc.). Check that the composite expression satisfies any constraints (e.g., AND, OR, etc.). Duplicate the functionality of the Code-Block "Iterations" times. START OF REPLICATED CODE It describes one or more opcodes that resolve a condition (i.e., execution leaves either true or false on the top of the stack).

[0063] A typical process would utilize a RETRIEVE construct that fetches each value needed for testing and places it on the top of the main stack, and then may perform the associated test operation (i.e., OP_EQUAL, OP_LESSTHAN, OP_GREATERTHAN, etc.). If the value to be tested is a constant, the value is at a known location in allocated memory (i.e., a known position on the main stack) and is copied to the top of the stack using OP_PICK. If the value to be tested is a variable (in which case the value to be tested is determined during script execution), the variable's location is at a known location in allocated memory (i.e., a known position on the alt stack) and can be copied to the top of the main stack using the "Borrow Block" method.

[0064] If the test makes use of a compound condition (using AND, OR, etc.), each subcondition is evaluated separately and the final result (0 or 1) is left on the top of the main stack. These are then combined to test the compound condition. For example, if the compound condition is of the form "Exp1 OR Exp2", the operation would write an OP_BOOLOR which first evaluates Exp1, then evaluates Exp2, and then compares the top two values ​​on the stack (i.e., the results of evaluating Exp1 and Exp2).

[0065] The result of the evaluation is left on the top of the main stack. No other values ​​are on the stack (except allocated memory, of course). The value is used by the next action (OP_IF).

[0066] It converts the functionality (sequence of operations) of a Code-Block into a sequence of opcodes that represent the functionality of the Code-Block. Such conversion can be bypassed for any COP_CODE contained in the Code-Block; it just requires a direct replacement of the COP_CODE with the sequence of opcodes of the Code-Block. Then, within an OP_IF / OP_ENDIF pair, we write the sequence of opcodes that represent the functionality of the Code-Block. END OF REPLICATED CODE

[0067] In some embodiments, the sequence of opcodes representing the duplicated Code-Block may be constructed such that the initial stack locations of constants and variables accessed by the sequence of opcodes for each iteration of the WHILE loop construct remain constant across the loop iterations. Although the values ​​of the variables may be updated across the loop iterations, the stack locations of such constants and variables at the beginning of execution of each loop iteration remain constant across the loop iterations. This operation ensures that the duplicated sequence of opcodes accesses the appropriate constants and / or variables stored on the stack during each loop iteration.

[0068] In some embodiments, the condition for duplicating a Code-Block depends on the value of one or more variables determined during script execution and may therefore be updated across loop iterations. In this case, each iteration of the duplicated Code-Block may include one or more opcode commands that test an associated condition. The condition is followed by a sequence of opcodes representing the duplicated Code-Block embedded within an OP_IF / OP_ENDIF pair. In this configuration, during script execution, the opcode command that tests the associated condition evaluates as true or false and places the true or false result on the top of the stack. Execution of a subsequent OP_IF statement selectively executes the duplicated Code-Block only if the true result is on the top of the stack. Thus, when a false result is on the top of the stack, execution of the OP_IF statement bypasses execution of the duplicated Code-Block.

[0069] Additionally, the condition for replicating a Code-Block can be limited by a maximum number of iterations. This can be defined by a parameter specified in a WHILE loop construct, a parameter asserted by system design, or some other parameter. In this case, the opcode command that tests the condition, followed by the sequence of opcodes representing the replicated Code-Block embedded within an OP_IF / OP_ENDIF pair, can be replicated a number of times corresponding to the maximum number of iterations defined by the parameter.

[0070] It should also be noted that an HLL program can utilize nested WHILE loop constructs, where an inner WHILE loop construct is contained within the Code-Block of an outer WHILE loop construct. In this case, the compiler can perform loop unrolling for the inner WHILE loop construct in conjunction with loop unrolling for the outer WHILE loop construct. For example, loop unrolling of the inner WHILE loop construct can duplicate the sequence of opcodes representing the functionality of the Code-Block of the inner WHILE loop construct between a pair of OP_IF / OP_ENDIF bytecode constructs for the number of iterations of the inner WHILE loop construct. Furthermore, loop unrolling of the outer WHILE loop construct can duplicate the sequence of opcodes representing the functionality of the Code-Block of the outer WHILE loop construct between a pair of OP_IF / OP_ENDIF bytecode constructs for the number of iterations of the outer WHILE loop construct. In this case, the sequence of opcodes representing the functionality of the Code-Block of each iteration of the outer WHILE loop construct includes the same opcode sequence as the number of iterations of the inner WHILE loop construct.

[0071] Also, note that WHILE loop nesting can be expanded, with additional inner WHILE loop constructs being included within the Code-Block of the inner (first inner) WHILE loop construct, and with the possibility of further nesting, in which case the loop unrolling operation as described herein can be readily expanded to resolve this further nesting.

[0072] <HLL Structure: INITIATE> ● Description: In an embodiment, this is the mandatory first statement of any HLL program. The first part of the script execution supplied by the transaction user (i.e., “scriptsig”) is outside the control of the unlock script. This usually consists of data pushed onto the stack. The purpose of the INITIATE structure is to enable the programmer to manage this input (most likely whether the input is needed for the rest of the script). This structure “assigns a value” to the reserved word NUM_INPUTS (which is the number of items in the user-supplied input pushed onto the stack). The first OP_CODE is always OP_DEPTH. As a result, the top of the stack (at this point) contains the number of data inputs pushed onto the stack. This position within the stack is fixed and known to the compiler at compile time, but the actual value is not known at compile time. ● Syntax: INITIATE ● Compiler Operation: WriteOP_DEPTH OP_DEPTH / * This sets OP_DEPTH to the value of NUM_INPUTS.

[0073] <HLL Structure: DECLARE> ● Description: In an embodiment, this is the mandatory second statement of any HLL program. All constants and variables are declared so the compiler can reserve "memory storage" (i.e., locations in the main and / or alt stack). The standard is to keep constants on the main stack and variables on the alt stack. The compiler associates names given to variables and constants with their location on the stack. The compiler pushes named items onto the main stack that already contain data inputs provided by the user (see INITIATE). At the top of the main stack is a value representing the number of those data items (this is associated with the reserved word NUM_INPUTS). ●Syntax:

number

[0074] Example:

number

number

[0075] In this example, assume that there are a number of input items supplied to the unlock script. At a minimum, there is a value at the location labeled "NUM_INPUTS" (which is a reserved word), even if the value is 0 and there are no values on the stack below it. This value is considered the start of the memory block, regardless of how many items are below it. The compiler knows the number of items in memory and their relative positions from the top of their initial stack. These items maintain their positions during program execution. Temporary calculations are performed using the space at the top of the stack (shown as "for temp variables" in the figure). When an item is temporarily pushed onto the top of the main stack for calculation, this changes the device position of the memory item. However, the compiler always maintains knowledge of the relative positions.

[0076] For example, after the DECLARE statement is executed, the compiler calculates and internally holds the value of Init-depth and the position of each item in the stack (in our example, Init-depth = 12). That is,

Number

[0077] The compiler can calculate the depth of any item at any point during compilation based on <initial depth of item> + <number of items added to the stack>.

[0078] <HLL Structure: INCREMENT> ● Explanation: The variable is read from its location in memory, incremented by 1, and then relocated to its location in memory. ● Syntax: INCREMENT (Variable-name) Here, Variable-name: The name used in the Declaration part to identify the variable. ● Operation of the compiler: Note: The compiler maintains knowledge of the number of items changing on both stacks (i.e., Main_Stack_Height and ALT_Stack_Height). The compiler also knows the position of each variable and constant on each stack established during the Declaration section. That is, Var-Posn = the position of Variable-name within the alt stack (i.e., the number of items from the bottom of the stack).

[0079] The operation uses the Borrow Block technique.

Number

[0080] ● Example: Increment variable B

Number

[0081] The task is to increment variable B. The compiler knows that the depth of B within the alt stack is B-Depth = 5. The compiler generates the following script code.

Number

[0082] <HLL Structure: IF ELSE> ● Explanation: Standard IF test. ● Syntax:

Number

Number

[0083] <HLL Configuration: RESET> ● Description: The variable is assigned the specified value. ● Syntax: RESET(Variable-name,Reset-value) Here, Variable-name: The name of the variable to which the new value should be assigned, Reset-value: The value to be assigned to Variable-name. ● Compiler operation: Note: The compiler maintains knowledge of the changing number of items on both stacks (i.e., Main_Stack_Height and ALT_Stack_Height). The compiler also knows the position of each variable and constant in the allocated memory (i.e., on each stack) established during the DECLARE section. Let Var-Posn be the position of Variable-name in the alt stack (i.e., the number of items from the bottom of the stack). The operation uses the Borrow Block technique.

Number

[0084] <HLL Configuration: ABORT> ● Description: Mark the transaction as invalid. ● Syntax: ABORT ● Compiler operation: Write OP_0 OP_VERIFY

[0085] <HLL Structure: POPULATE> ● Description: The purpose of this structure is to populate constants declared (DECLARE) by the programmer using inputs from transaction users (e.g., inputs supplied by the execution of the unlock script for a spending transaction). Inputs to the lock script (i.e., "scriptsig") push any data onto the main stack. This occurs before the DECLARE structure. Therefore, these inputs are at the bottom of the stack. The number of stack items (NUM_INPUTS) is placed above them by the (mandatory) INITIATE statement. It is the programmer's responsibility to verify that the rules of the transaction are met (e.g., that the correct number of inputs has been provided). ● Syntax: POPULATE(Stack-position,Constant-name) Here, Stack-position: An integer. The position counted down from the bottom of the memory block. Note that the bottom of the memory block always contains the item NUM_INPUTS, and below this are the input data pushed onto the stack before the locking script code is executed. Constant-name: The name of the constant to be populated. ● Compiler operation: Calculate shift-count = the number of stack items to be temporarily moved from the main stack to the alt stack for storage. shift-count = the number of stack items above the target item (Constant-name).

Number

[0086] <HLL Structure: RAWSCRIPT> ● Description: An array of values representing a valid chunk of Bitcoin Script code. The compiler first verifies the array to ensure that it consists of valid chunks of script code (including OP_CODE, COP_CODE, and integers). The purpose is to enable programmers to directly include low-level code in the Compiler output. This is useful for functions that are easier to code directly in the script code rather than using the currently available HLL structures. ● Syntax: RAWSCRIPT [Values] Here, Values is an array (list) of OP_CODE, COP_CODE, and their integer inputs ● Compiler Behavior: The compiler first verifies that the set of values together form a valid Bitcoin script. That is, all OP_CODEs are part of the currently accepted and enabled OP_CODEs, all COP_CODEs exist in our vocabulary of COP_CODEs, and they all have the expected input values. Next, the compiler simply writes the values to the current position in the output script.

[0087] <HLL Structure: CALCULATE TEMP> ● Description: A valid calculation is performed and the result is placed on top of the main stack. "Valid" means that it is one of the currently available function structures in the HLL. The programmer must write the program such that TEMP is available when later referenced (i.e., still on top of the stack). Note that TEMP can only be referenced once. (If more than once is needed, it should be declared as a variable instead). ● Syntax: CALCULATE TEMP=expression ● Compiler operation: Check that the expression is valid (is a member of the list of currently available function constructs). Execute the expression and leave the result (TEMP) at the top of the stack. Parse the following references to TEMP. Determine whether TEMP needs to be present at the top of the stack when referenced. If not, do not throw a compile error. ● Example: CALCULATE TEMP=HASH160 (123456789)

[0088] <HLL configuration: HASH160> ● Explanation: This executes a hashing algorithm equivalent to OP_CODE: OP_HASH160. ● Syntax: HASH160(value1) Here, value1 is one of the following: Hardcoded integer Declared constant Declared variable ● Compiler operation: If Velue1 is a hardcoded number, it is pushed onto the top of the stack. If Velue1 is a variable or constant, it is retrieved (placed on the top of the stack). The compiler writes the following: OP_HASH160

[0089] <HLL configuration: RETRIEVE> ● Explanation: A variable or constant is read from its location in memory and copied to the top of the main stack. The original value remains unchanged at its current location in its own "memory". ●Syntax: RETRIEVE(Item-name) where: Item-name: A declared variable or constant ●Compiler operation: Note: The compiler maintains knowledge of the varying number of items in both stacks (i.e. Main_Stack_Height and ALT_Stack_Height). The compiler also knows the position on each stack of each variable and constant established during the Declaration part: Item-posn = position of Item-name in the stack (i.e. number of items from the bottom of the stack). The operation uses the Borrow Block technique. Calculate Item-Depth=Stack_Height-Item-posn+1. If the item you want is in the alt stack (i.e., it's a variable),

number

number

[0090] Example: Read a copy of variable C Assume your memory allocation looks like this:

number

number

number

[0091] <Reserved word> ●Reserved word: NUM_INPUTS Description: This is always a constant at the bottom of a block of memory; that is, it is the "first" item in a block of allocated stack locations. Although it is a constant, it is not known at compile time. Therefore, it cannot be used by the compiler for any hard-coded script operations (for example, it cannot be used as a number to count how many times an OP_TOALTSTACK statement is generated in compiled code). It is known at run time. Therefore, it can be used by the programmer or compiler for tasks such as conditional tests in loops and IF statements.

[0092] ●Reserved word: TEMP Description: This is a temporary, one-time variable that is left on the top of the stack after a computation. It exists so that the programmer can refer to it during the computation. The compiler will check the syntax to ensure that TEMP is still on the top of the stack when it is referenced later in the program.

[0093] ●Reserved word: CONSTANTS Description: This is used in conjunction with a DECLARE construct, followed by a list of constructs to be pushed onto the main stack.

[0094] ●Reserved word: VARIABLES Description: This is used in conjunction with the DECLARE construct, followed by a list of variables to be pushed onto the alt stack.

[0095] For purposes of explanation, here is provided an example of usage including a WHILE loop, an exemplary HLL program, and Bitcoin script code that can be compiled therefrom. The Bitcoin script code utilizes opcodes belonging to Script, the Bitcoin script language. Note that the Bitcoin script code includes comments starting with / * or / / as is conventional. These comments are not necessarily part of the Bitcoin script code generated by the compiler, but are included below for purposes of explaining the operation of the compiler when generating exemplary Bitcoin script code.

[0096] <Example of WHILE Loop - Transaction (Tx)> Consider a blockchain transaction (Tx) having an internal list of 10 hard - coded hash puzzles. To unlock the output of the Tx, the user needs to provide at least 3 correct hash solutions. The lock script of the transaction accepts up to 12 attempts with the same input (i.e., "scriptsig"), and they can be in any order. The transaction hashes each "try" input and checks whether it matches one of the hash values stored internally.

[0097] For clarity, consider the conventional way of writing the unlock script in the INPUT section of a Bitcoin transaction. <scriptsig> <scriptpubkey> First part <scriptsig>is the data and / or OP_CODE included in the spending transaction to unlock the output of the previous transaction being used. <scriptpubkey>is the lock script used in the OUTPUT of the previous transaction being used.

[0098] We represent these as follows: <Spender Input><locking script>

[0099] Assume that the Spender Input is TRY1 TRY2 TRY3 TRY4 TRY5. This means that the user tried five different possible hash solutions, three of which, according to the rules above, must be correct to unlock the transaction.<Spender Input><locking script> When executed, the first operation is<Spender Input> This, in this example, simply pushes five data items onto the stack.

[0100] <Lock Script Logic ~ Pseudocode> Note: There are nested WHILE loops. Standard first step: Count the number of inputs and store it as NUM_INPUTS. Declare variables and constants used in the script and initialize them to known values.

number

[0101] Populates an internal array with the user's input values ​​(i.e., in this example, assigns Try[1]-Try[5] to input values ​​TRY1 TRY2 TRY3 TRY4 TRY5). The rest of the array remains with a value of zero.

[0102] / * Outer loop starts here: take each input value (TRY1-TRY5) and hash it for checking.

number

[0103] / * The inner loop starts here: For each hash value we saved, we check if it matches the hashed Try value.

number

[0104] <Formal HLL Program> The following code is written in HLL using syntax according to an embodiment of the present disclosure. It is intended to illustrate the use of WHILE, but necessarily includes other HLL constructs (which are CAPITALISED), some of which are described above and will be readily understood by those skilled in the art who are familiar with the syntax used by conventional modern high-level languages.

number

[0105] / * For each array element, check if there is a corresponding input value available on the stack, and if so, use it to populate the corresponding array element.

number

[0106] / * Outer loop, keeping in mind compound conditions.

number

number

[0107] <Compiled Bitcoin Script> / * INITIATE (initialization) OP_DEPTH / / Determine NUM_INPUTS (reserved word) and place it on top of the stack / * DECLARE CONSTANTS *Initialize constants and put them on the main stack. The compiler knows where the constants are. *Array of 12 values ​​(these are "try values" that will be populated later with the actual input values). In fact, the array: Try

[12] OP_0 OP_0 OP_0 OP_0 OP_0 OP_0 OP_0 OP_0 OP_0 OP_3 / / The number of correct hashes needed to unlock Correct_Needed-TX is hardcoded to 3 OP_10 / / Num_Hashes - the number of hashes in the array is hardcoded to 10

[0108] / * The hardcoded hash value is stored on the main stack (i.e. the next 20 bytes are pushed onto the stack), actually in the array HASH-SAVED

[10] .

number

[0109] / * DECLARE VARIABLES. Initialize variables (index and boolean) and put them on the alt stack. The compiler knows where they are. OP_0 OP_TOALTSTACK / / Correct_Counter - number of correct hits (when a hash match is found). OP_0 OP_TOALTSTACK / / Try_counter - outer loop index: counter of input values ​​being tried. OP_0 OP_TOALTSTACK / / Hash_counter - index of inner loop: counter of hashes being attempted. OP_0 OP_TOALTSTACK / / Match_found - Boolean flag: set to true when a hash match is found.

[0110] / *At this stage, the alt stack is populated and acts as a memory store for variables. The compiler needs to "keep track" of the location of variables, i.e. their "depth" in the alt stack. The main stack is populated with constants. The compiler needs to keep track of the location of constants as well. The "first value" of the main stack memory block is considered to be at position NUM_INPUTS (regardless of how many items are below it).

[0111] / * At this stage, the compiler knows that the value of NUM_INPUTS is 27 deep on the main stack. The following operation copies this value to the top of the stack. It then pushes the value '12' onto the top of the stack and compares it using '>'. If NUM_INPUTS > 12 (corresponding to the 12 allowed 'try'), it aborts. Since OP_VERIFY leaves its result on the top of the stack, the operation can use OP_DROP. 27 OP_PICK OP_12 OP_GREATERTHAN OP_VERIFY OP_DROP

[0112] / *POPULATE THE Try[] array. Note: The code block for populating the Try[] array has been moved to Figure 2 to improve the clarity and readability of this application. We assume that the compiler writes out a block of script code that reads the input values ​​provided by the consumer of the Tx output and populates them into the Try[] array. In one example, only five inputs (i.e., five "trys") are provided, so only the first five elements of Try[] are populated, and the other elements remain with value 0.

[0113] / * Outer WHILE loop. The maximum number of iterations possible (e.g. per a given rule) is 12. Therefore, the compiler unrolls the outer WHILE loop by replicating the following sequence of opcodes 12 times: / * Borrow Block for Condition1: "is Try_counter < NUM_Inputs AND Correct_counter < Correct_Needed?". To perform the test within Condition1, we extract variables from the alt stack, perform the test, and then return the variables again ("borrow block"). / * First, get a copy of Try_counter and place it on top of the stack.

Number

[0114] / * Next, get a copy of NUM_Inputs and place it on top of the stack. The compiler knows that this constant is currently at a depth of 14 on the main stack. OP_14 OP_PICK / * Here, for part1 of Condition1, compare the top two stack items. This checks "Try - Counter < NUM_Inputs?" and leaves the result on top of the stack. OP_LESSTHAN / * Check part (part2) of Condition1 ("is Correct_counter < Correct_Needed?"). Leave the result on top of the stack. / * First, get a copy of Correct_counter and place it on top of the stack.

Number

[0115] OP_13 OP_PICK / / Copy Correct_Needed to the top of the stack: The compiler knows that this constant is currently at a depth of 13. OP_LESSTHAN / / Here, for part 2 of Condition1, the top two stack items are compared. This checks "Correct_counter < Correct_needed?" and leaves the result on top of the stack. OP_BOOLAND / / Complete the combined check of condition1: The results of both parts of condition1 are on top of the stack. After this operation, the final result of the test of Condition1 is on top of the stack. It is popped off by the following IF. OP_IF

[0116] / * Borrow block for incrementing Try - Counter. The first step is to obtain it on top of the main stack. The compiler knows the depth on its alt stack (depth = 3 in this example).

Number

[0117] / * Borrow block for resetting Hash_counter = 0. The compiler knows the position of this variable.

Number

[0118] / * Borrow block for resetting Match - Found = FALSE. The compiler knows the position of this variable.

Number

[0119] / * Copy the required "Try" value to the top of the stack and hash it. <try-depth>OP_PICK OP_HASH160 / / In a formal HLL, this is the value of TEMP and is left at the top of the stack. Further operations push more values onto the main stack and / or pop values off the main stack. The goal is for the value of TEMP to be at the top of the stack when it is next needed (for equivalence checking). Since the compiler can always track what is in the stack based on the formal HLL code, the compiler can verify this during compilation

[0120] / * Inner WHILE loop. / * The inner WHILE loop is executed for Num_Hashes iterations with a maximum value of 10 in the given example. Thus, the compiler expands the inner WHILE loop by replicating the following sequence of opcodes Num_Hashes times (less than 10 iterations) within each iteration of the outer WHILE loop.

[0121] / * Borrow Block for Condition2: "‘Is Match_Found = FALSE AND Hash - Counter < NUM_Hashes?" To perform the test within Condition1, we extract the variable from the alt stack, perform the test, and then return the variable again ("borrow block").

[0122] / * First, obtain a copy of the variable Match_Found from part 1 of Condition2 and place it at the top of the stack. The compiler knows the position of this variable.

Number

Number

[0123] / * Check if Hash_Counter < NUM_Hashes. OP_LESSTHAN / * Complete the combined check for condition2. The results of both parts of the condition2 check are at the top of the stack. After this, the final result is left at the top of the stack.

[0124] OP_BOOLAND

[0125] / * The result of the Condition2 test is at the top of the stack. It is popped off by the following IF. OP_IF

[0126] / * Borrow block for incrementing Hash_Counter. The depth of the required hash values (i.e., <hash-depth>) can be calculated by the compiler as "current-stack-height" - "Hash1-position" - Hash_counter+1. / * The compiler can maintain knowledge of the positions of all constants, and therefore knows that the first hash value is at position 9 (because there are 5 Try values ​​and 3 other constants at the bottom of the stack). / * There is one TEMP value on top of the main stack, so the current stack height is 19. If we want a depth of HASH-SAVED[4] (Hash_counter=4), the depth is: "Hash-depth" = 19-9-4+1 = 8 (i.e., currently 8 from the top of the main stack).

number

number

[0127] / *End outer WHILE loop Duplicate the opcode sequence for the second iteration of the outer WHILE loop (including duplicating the opcode sequence for NUM_INPUTS iterations (up to 10) of the inner WHILE loop). Duplicate the opcode sequence for the third iteration of the outer WHILE loop (including duplicating the opcode sequence for NUM_INPUTS iterations (up to 10) of the inner WHILE loop). Duplicate the opcode sequence for the fourth iteration of the outer WHILE loop (including duplicating the opcode sequence for NUM_INPUTS iterations (up to 10) of the inner WHILE loop). Duplicate the opcode sequence for the fifth iteration of the outer WHILE loop (including duplicating the opcode sequence for NUM_INPUTS iterations (up to 10) of the inner WHILE loop). Duplicate the opcode sequence for the sixth iteration of the outer WHILE loop (including duplicating the opcode sequence for NUM_INPUTS iterations (up to 10) of the inner WHILE loop). A duplication of the opcode sequence for the seventh iteration of the outer WHILE loop (including a duplication of the opcode sequence for NUM_INPUTS iterations (up to 10) of the inner WHILE loop). A duplication of the opcode sequence for the eighth iteration of the outer WHILE loop (including a duplication of the opcode sequence for NUM_INPUTS iterations (up to 10) of the inner WHILE loop). A duplication of the opcode sequence for the 9th iteration of the outer WHILE loop, including a duplication of the opcode sequence for NUM_INPUTS iterations (up to 10) of the inner WHILE loop. Duplicate the opcode sequence for the 10th iteration of the outer WHILE loop (including duplicating the opcode sequence for NUM_INPUTS iterations (up to 10) of the inner WHILE loop). A duplication of the opcode sequence for the 11th iteration of the outer WHILE loop (including a duplication of the opcode sequence for NUM_INPUTS iterations (up to 10) of the inner WHILE loop). Duplicate the opcode sequence for the 12th iteration of the outer WHILE loop (including duplicating the opcode sequence for NUM_INPUTS iterations (up to 10) of the inner WHILE loop). After 12 iterations of the outer WHILE loop are completed, the compiler checks whether the required number of hits has been reached (ie, checks whether Correct_counter >= Correct_Needed).

number

[0128] / / This final operation leaves the test result on top of the stack. If it is TRUE (i.e., Correct_counter >= Correct_Needed) and other checks may pass, the transaction is marked as valid.

[0129] In embodiments, the blockchain compiler may be configured to optimize the output script at least once to provide a more efficient or reduced version of the output script. This may include the use of derivative free optimization (DFO). DFO is a term known in the art and readily understood by those skilled in the art. Additionally or alternatively, generating the output script may include the use of derivative free optimization.

[0130] In embodiments, the blockchain compiler may form part of and / or be configured to operate in conjunction with a software development kit (SDK), which may include editors, debuggers, and other known components to be used in conjunction with the SDK to facilitate the creation of code-based solutions.

[0131] 3 illustrates an example blockchain network 1000 associated with a blockchain according to one embodiment of the present disclosure. In this embodiment, the example blockchain network 1000 is made up of peer-to-peer distributed electronic devices running instances of a blockchain protocol. In some examples, the distributed electronic devices are referred to as nodes 1002. One example of a blockchain protocol is the Bitcoin protocol.

[0132] Node 1002 may comprise any suitable computing device (e.g., a server in a data center, a client computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a smartphone, etc.), a plurality of computing devices in a distributed system of a computing resource service provider, or any suitable electronic client device such as computing device 2600 of FIG. 5).

[0133] In one embodiment, one or more of the nodes 1002 are communicatively coupled to one or more other of the nodes 1002. Such communicative coupling may utilize one or more of well-known wired or wireless communication links. In an embodiment, the nodes 1002 each maintain at least a portion of a "ledger" of all transactions in the blockchain. As such, the ledger is a distributed ledger. Blockchain transactions processed by a node that affect the ledger are verified by one or more of the other nodes to ensure the integrity of the ledger is maintained.

[0134] In one embodiment, at least some of the nodes 1002 are miner nodes that perform mining processes involving complex computations such as solving cryptographic problems. Miner nodes that solve the cryptographic problems generate new blocks for the blockchain and broadcast the new blocks to other nodes 1002. Other nodes 1002 perform validation processes that verify the work of the miner nodes and, upon validation, accept the blocks into the blockchain (e.g., by adding them to the blockchain's distributed ledger). In some examples, a block is a group of transactions and may be marked with a timestamp and a "fingerprint" (e.g., a hash) of the previous block. In this way, each block becomes linked to the previous block, thereby creating a "chain" that links the blocks in the blockchain. In embodiments, valid blocks are added to the blockchain by consensus of the nodes 1002. Also, in some examples, the blockchain includes a list of validated blocks.

[0135] In one embodiment, at least some of the nodes 1002 operate as validating nodes, performing a validation process to validate transactions as described in this disclosure. FIG. 3 illustrates one exemplary labeled transaction 1004. In some examples, a transaction includes data providing proof of ownership of a digital asset (e.g., an amount of Bitcoin tokens) and conditions for accepting or transferring ownership / control of the digital asset. In some examples, a "spending transaction" refers to a transaction that reallocates (e.g., transfers ownership or control) at least a portion of a digital asset represented by an unspent transaction output (UTXO) of a previous transaction to an entity associated with a blockchain address. In some examples, a "previous transaction" refers to a transaction that includes a UTXO referenced by the spending transaction. In some embodiments, a transaction may include an "unlock script" and a "lock script." A lock script can be used to block a transaction with conditions that must be met before the transaction is valid and ownership / control is transferred by the transaction. In some embodiments, a lock script can be associated with a transaction output and used to define one or more conditions required to use the output. Additionally, the spending transaction's unlock script may be configured such that execution of the unlock script provides data used to derive a set of conditions that are evaluated by execution of the previous transaction's lock script for validation of the spending transaction. The previous transaction's lock script and the spending transaction's unlock script are written using a low-level, functionally constrained scripting language such as Bitcoin's Script.

[0136] In some embodiments, validating a spending transaction may include executing the locking script of the previous transaction, along with executing the unlocking script of the spending transaction, to satisfy and verify the set of conditions described by the locking script of the previous transaction. Validating a spending transaction may include other checks. If the spending transaction is successfully validated, the spending transaction may be propagated to other network nodes. Miner nodes may select valid spending transactions to embed as part of a block that is added to the blockchain, as described herein.

[0137] As shown in FIG. 3 , the blockchain compiler 1001 described herein is used to convert an HLL program into a blockchain-compatible script (or fragment of a script). This may form the output provided by the blockchain compiler 1001, and therefore may be referred to as an “output script.” The output script may be provided in a blockchain transaction (Tx). The output script may be a portion of a lock script associated with a transaction output or a portion of an unlock script associated with a transaction input. The output script may be formed of opcodes inherent in and / or forming part of a blockchain scripting language selected from a blockchain scripting language executable by nodes of the blockchain network. The opcodes may be referred to as primitives or commands. The script opcodes may be executed by an interpreter or virtual machine running on the nodes of the blockchain network 1000. The interpreter or virtual machine may convert the script opcodes into machine-executable (object) code. The blockchain scripting language may be, for example, the Script language used in connection with the Bitcoin protocol or a variant thereof. The scripting language may include cryptographic, arithmetic, and stack manipulation opcodes.

[0138] The compiler 1001 may be part of an SDK or, in some cases, an online service that uses static compilation to generate blockchain transaction scripts (or fragments of scripts) that can be executed by bots or nodes in a blockchain network.

[0139] Alternatively, the compiler methods described herein can be used as part of a runtime environment for a bot or node of a blockchain network, where the runtime environment interprets or dynamically compiles or translates chunks of HLL programs (e.g., programs written in 3G languages ​​such as Python, C++, etc.) into blockchain transaction scripts or script fragments that can be executed by the bot or node of the blockchain network.

[0140] FIG. 4 illustrates an exemplary blockchain protocol for validating and mining a transaction 204 (labeled “TX2”) that uses the output of a previous spending transaction 202 (labeled “TX1”). The previous transaction 202 has an output including a token amount (a digital asset) and a locking script configured to define a set of conditions necessary to spend the token amount. The previous transaction 202 is validated and mined. As a result, the previous transaction 202 is embedded in a block, which is then validated and stored in the blockchain 208. The spending transaction 204 includes an input having a transaction output identifier field (labeled “Tx output ID”) that references the output of the previous transaction 202 and an unlocking script. The locking script of the previous transaction 202 and the unlocking script of the spending transaction 204 are written using a low-level, functionally constrained scripting language such as Bitcoin Script. For a spending transaction 204 to be considered valid, the input's unlock script must provide data that satisfies the condition set by the lock script of the referenced output of the previous transaction 202. The lock script (or portion thereof) of the previous transaction 202 and the unlock script of the spending transaction 204 may be generated by the blockchain compilation methods and tools described herein.

[0141] A spending transaction 204 is validated by one or more nodes in the blockchain network (FIG. 4) by executing the lock script of the previous transaction 202 along with executing the unlock script of the spending transaction 204 to satisfy and verify the set of conditions described by the lock script of the previous transaction 202. Validation of a spending transaction 202 may include other checks. If the spending transaction is successfully validated, the spending transaction may be propagated to other network nodes. A miner node may perform mining operations, as described herein, to select valid spending transactions and embed them as part of a block that is added to the blockchain 208. Once validated and stored in the blockchain 208, the sequence of transactions 202 and 204 provides for the transfer of control over the token amount (digital asset) referenced by the transaction.

[0142] FIG. 5 illustrates a simplified block diagram of a computing device 2600 that may be used to implement at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 may be used to implement a blockchain compiler and network node of the illustrated and described blockchain network. For example, the computing device 2600 may be configured for use as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 5, the computing device 2600 may include one or more processors 2602 that may be configured to operably couple to and communicate with a number of peripheral subsystems via a bus system 2604. The processor 2602 may be utilized for compiling HLL source code programs into blockchain scripts (or fragments thereof) as described herein. These peripheral subsystems may include a storage subsystem 2606, including a memory subsystem 2608 and a file / disk storage subsystem 2610, one or more user interface input devices 2612, one or more user interface output devices 2614, and a network interface subsystem 2616. Such a storage subsystem 2606 may be used for temporary or long-term storage of information such as details related to the transactions described in this disclosure.

[0143] The bus subsystem 2604 may provide a mechanism for allowing the various components and subsystems of the computing device 2600 to communicate with each other as needed. While the bus subsystem 2604 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may serve as an interface for receiving data from and transmitting data to other systems from the computing device 2600. For example, the network interface subsystem 2616 may enable a data technician to connect the device to a wireless network. As a result, the data technician may be able to send and receive data while at a remote location, such as a user data center. The bus system 2604 may be used to communicate data such as details, search terms, etc., to the monitoring model of the present disclosure and to communicate the output of the monitoring model to one or more processors 2602 and to merchants and / or creditors via the network interface subsystem 2616.

[0144] The user interface input devices 2612 may include one or more user input devices, such as a keyboard, a pointing device such as an integrated mouse, a touchpad or graphics tablet, a scanner, a barcode scanner, a touchscreen with a built-in display, an audio input device such as a voice recognition system, a microphone, and other types of input devices. In general, the use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computing device 2600. The one or more user interface output devices 2614 may include a display subsystem, a printer, or a non-visual display such as an audio output device. The display subsystem may include a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a light emitting diode (LED) display, or a projection or other display device. In general, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. One or more user interface output devices 2614 may be used to present a user interface, for example, to facilitate user interaction with applications that perform the processes and variations thereof described herein, where appropriate.

[0145] The storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data constructs that may provide the functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions), which when executed by one or more processors, may provide the functionality of one or more embodiments of the present disclosure, may be stored in the storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. The storage subsystem 2606 may also provide a repository for storing data used in accordance with the present disclosure. The storage subsystem 2606 may include a memory subsystem 2608 and a file / disk storage subsystem 2610.

[0146] The storage subsystem 2608 may include multiple memories, including a main random access memory (RAM) 2618 for storage of instructions and data during program execution, and a read-only memory (ROM) 2620 in which fixed instructions may be stored. The file / disk storage subsystem 2610 may provide non-transitory permanent (non-volatile) storage for program and data files, and may include hard disk drives, floppy disk drives with associated removable media, compact disk read-only memory (CD-ROM) drives, optical drives, removable media cartridges, and other similar storage media.

[0147] Computing device 2600 may include at least one local clock 2624. Local clock 2624 may be a counter representing the number of hours that have lapsed since a particular start date and may be integrated within computing device 2600. Local clock 2624 may be used to synchronize data transfers to particular clock pulses within the processor of computing device 2600 and all subsystems contained therein, and may be used to coordinate synchronous operations between computing device 2600 and other systems within a data center. In one embodiment, local clock 2624 is an atomic clock. In another embodiment, local clock 2624 is a programmable interval timer.

[0148] Computing device 2600 may be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described below. Additionally, computing device 2600 may include another device that may be connected to computing device 2600 through one or more ports (e.g., USB, headphone jack, optical connector, etc.). A device that may be connected to computing device 2600 may include multiple ports configured to receive fiber optic connectors. Thus, the device may be configured to convert optical signals into electrical signals. The electrical signals may be transmitted through the ports connecting the device to computing device 2600 for processing. Due to the ever-changing nature of computers and networks, the description of computing device 2600 shown in FIG. 13 is intended only as a specific example for purposes of describing a preferred embodiment of the device. Many other configurations are possible, having more or fewer components than the system shown in FIG. 5 .

[0149] It should be noted that the above-described embodiments illustrate rather than limit the present disclosure, and that those skilled in the art can devise numerous alternative embodiments without departing from the scope of the present invention, which is defined by the appended claims. The disclosed methods, systems, and apparatus (or parts thereof) may be implemented by means of hardware comprising several distinct elements, or by means of a suitably programmed computer. In a device claim enumerating several means, these several means may be embodied by one and the same hardware element. The fact that certain quantities are recited in mutually different dependent claims does not indicate that a combination of these quantities cannot be used to advantage.

[0150] Accordingly, the specification and accompanying drawings should be interpreted in an illustrative rather than a restrictive sense. However, it will be apparent that various modifications can be made without departing from the scope of the invention as set forth in the claims. Likewise, other variations are within the scope of this disclosure. Thus, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof have been shown in the drawings and have been described above in detail. It is to be understood, however, that the invention is not limited to the particular form or forms disclosed, but rather, all modifications, alternative constructions, and equivalents are intended to be embraced within the scope of the invention, as set forth in the appended claims.

[0151] In the claims, any reference signs placed between parentheses should not be construed as limiting the claim. Moreover, the terms "a," "an," and "the," and similar referents in the context of describing embodiments of the disclosure (particularly in the context of the following claims) should be considered to cover both the singular and the plural, unless otherwise specified or clearly contradicted by context. The terms "comprising," "having," "including," "including," "with," and "comprising" (including, having, including, containing) should be considered in their open sense (i.e., meaning "including, but not limited to") unless otherwise noted. The term "connected," when referring to an unaltered physical connection, should be considered as being partially or wholly contained within, attached to, or joined together, even if there is something intervening. The recitation of ranges of values ​​in this disclosure is intended to serve merely as a shorthand way of referring individually to each separate value encompassed by the range, unless otherwise specified herein, and each separate value is incorporated herein as if it were individually recited herein. Use of the term "set" (e.g., "set of items") or "subset" should be considered as a non-empty set containing one or more members, unless otherwise noted or contradicted by context. Further, unless otherwise noted or contradicted by context, the term "subset" of a corresponding set does not necessarily indicate a proper subset of the corresponding set, although a subset and a corresponding subset may be equivalent. The singular reference of an element does not exclude the plural presence of that element, and vice versa.

[0152] Logical language such as phrases of the form "at least one of A, B, and C" or "at least one of A, B, and C" is understood to be used to express that an item, after, etc., can be either A or B or C, or any non-empty subset of the set A, B, and C, unless otherwise stated or clearly contradicted by context. For example, in the illustrative example of a set having three components, the logical language "at least one of A, B, and C" or "at least one of A, B, and C" represents any of the following sets: {A}, {B}, {C}, {A,B}, {A,C}, {B,C}, {A,B,C}. Thus, such logical language is generally not intended to imply that a particular embodiment requires that at least one A, at least one B, and at least one C each be present.

[0153] The actions of the processes described may be performed in any suitable order unless otherwise indicated or clearly contradicted by context. The processes described (or variations and / or combinations thereof) may be performed under the control of one or more computer systems configured with executable instructions, and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) collectively executing on one or more processors, in hardware, or a combination thereof. The code may be stored on a computer-readable storage medium, for example, in the form of a computer program including a plurality of instructions executable by one or more processors. The computer-readable storage medium may be non-transitory.

[0154] The use of any and all examples or exemplary language (e.g., "such as") provided herein is intended merely to better elucidate embodiments of the invention and is not intended to limit the scope of the invention unless specifically stated. No language in the specification should be construed as indicating any non-claimed element essential to the practice of the invention.

[0155] The embodiments of the present disclosure are described in this disclosure, including the best mode known to the inventors for carrying out the invention. Variations of these embodiments may become apparent to those skilled in the art upon reading the foregoing description. The inventors expect that skilled artisans will take advantage of these variations as appropriate, and the inventors intend for the embodiments of the present disclosure to be practiced otherwise than as specifically described. Accordingly, the scope of the present disclosure includes all modifications and equivalents of the subject matter recited in the appended claims as permitted by applicable law. Furthermore, any combination of the above-described elements in all possible variations thereof is encompassed within the scope of the present disclosure unless otherwise indicated or clearly contradicted by context.

[0156] All references, including cited publications, applications, and patents, are herein incorporated by reference to the same extent as if each reference was individually and specifically indicated to be set forth in its entirety. [Explanation of symbols]

[0157] 101 HLL source code (CPO_Codes, HLL configuration) 102 Blockchain Compiler 103 Blockchain protocols / platform compatible scripts (opcodes) 104 Interpreter 105 Runs on the blockchain < / scriptpubkey> < / scriptsig> < / scriptpubkey> < / scriptsig>

Claims

1. 1. A computer-implemented method comprising: receiving a portion of source code as input, said portion of source code being written in a high level language (HLL); generating an output script including a plurality of opcodes selected from and / or specific to a functionally constrained blockchain scripting language, the output script, when executed, providing functionality specified at least in part in the portion of the source code, the functionally constrained blockchain scripting language not natively supporting complex control flow constructs, iterations, and jump-based loops; 10. A computer-implemented method comprising:

2. 2. The computer-implemented method of claim 1, further comprising: executing the output script, wherein the functionally constrained blockchain scripting language is stack-based, and during execution of the output script, one or more opcode commands that test conditions evaluate as true or false results and place the true or false results on the top of a stack used by the functionally constrained blockchain scripting language.

3. 3. The computer-implemented method of claim 1, wherein the step of generating an output script is performed by a compiler.

4. The computer-implemented method of any of claims 1 to 3, wherein the output script is generated by performing static compilation.

5. 5. The computer-implemented method of any of claims 1 to 4, further comprising providing or using an interpreter or virtual machine configured to convert the output script into a format that is executable on a blockchain platform.

6. 6. The computer-implemented method of claim 1, wherein the portion of source code is at least a portion of a smart contract.

7. 7. The computer-implemented method of claim 1, wherein generating the output script further comprises testing for errors and outputting a warning if one or more errors are detected.

8. 8. The computer-implemented method of claim 7, wherein testing for an error includes testing for an overflow error.

9. The HLL includes at least one of the following primitives or operators, or functional equivalents of the following primitives or operators: Initiate, Declare, Increment, IF, While, Populate, Monus, Reset, Rawscript, Abort, Retrieve, Hash, hash 160, or another hash operation or variant of a hash operation; A computer-implemented method according to any one of claims 1 to 8.

10. 1. A computer-implemented system comprising one or more processors and a memory storing computer-executable instructions that, upon execution, cause the one or more processors to: receiving as input a portion of source code, the portion of source code being written in a high-level language (HLL); generating an output script including a plurality of opcodes selected from and / or specific to a functionally constrained blockchain scripting language, the output script, when executed, providing functionality specified at least in part in the portion of the source code, the functionally constrained blockchain scripting language not natively supporting complex control flow constructs, iterations, and jump-based loops; system.

11. The method further includes a compiler, the compiler comprising: receiving as input a portion of said source code, said source code being written in a high level language (HLL); generating the output script; The system of claim 10 configured to:

12. The system of claim 11 , wherein the compiler is configured to test for errors in the portion of the source code and to output a warning in response to detecting one or more errors.

13. The system of claim 12 , wherein the compiler is configured to test for overflow errors.

14. The system of any one of claims 10 to 13, further comprising a software development kit.

15. The system of any of claims 10 to 14, wherein the computer-executable instructions further cause the one or more processors to execute the output script, wherein the functionally constrained blockchain scripting language is stack-based, and wherein during execution of the output script, one or more opcode commands that test conditions evaluate as a true or false result and place the true or false result on the top of a stack used by the functionally constrained blockchain scripting language.

16. The HLL includes at least one of the following primitives or operators, or functional equivalents of the following primitives or operators: Initiate, Declare, Increment, IF, While, Populate, Monus, Reset, Rawscript, Abort, Retrieve, Hash, hash 160, or another hash operation or variant of a hash operation; A system according to any one of claims 10 to 15.

Images