Blockchain compiler

Abstract

To provide a method and a system for enabling and / or facilitating automatization and execution of a high level program on a block chain platform or a protocol including a language based on a functionally restricted script.SOLUTION: A method includes the steps of: receiving a portion of a source code as input to describe the portion of the source code by a high-level language (HLL); and generating an output script including a plurality of operation codes selected from a block chain script language and / or unique to the language. The generated output script provides at least a function partially designated in the portion of the source code. The block chain script language is restricted in supporting a repeat programming constitution.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present disclosure generally relates 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 technologies for the conversion of computer-based code. One or more embodiments of the present invention are suitable for use as a solution to enable and / or facilitate the automation and execution of high-level programs on a protocol including a blockchain platform or a language based on a functionally constrained script.

Background Art

[0002] As used herein, the term "blockchain" is used to include any form of electronic, computer-based, distributed ledger. These include blockchain and transaction chain technologies based on consensus, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known use of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. Bitcoin is mentioned herein for convenience and illustrative purposes only, and it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are included within the scope of the present invention. The term "user" may represent 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. Also, a block is composed of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants within a blockchain system and includes at least one input and at least one output. Each block contains the hash of the previous block, and the blocks together form a chain that produces a permanent and immutable record of all the transactions written to the blockchain from its inception. A transaction includes a small program known as a script incorporated into its input and output. The script specifies how and by whom the output of the transaction can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language called Script. The script is written using commands (opcodes), which are converted into executable code by an interpreter.

[0004] For a transaction to be written to the blockchain, it must be "verified". Network nodes (miners) perform work to ensure that each transaction is valid, and invalid transactions are rejected from the network. The software client installed on the node performs this verification work on unspent transactions (UTXOs) by executing its lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to true and passes the checks, the transaction is valid and the transaction is mined to be included in the blockchain. Therefore, for a transaction to be written to the blockchain, the transaction must i) be verified by the first node that receives the transaction, and if the transaction is verified, the node relays the transaction to other nodes within the network, ii) be added to a new block constructed by the miner, and iii) be mined, i.e., added to the public ledger of past transactions.

[0005] Blockchain technology is most widely known for its use in cryptocurrency implementations, but digital entrepreneurs are beginning to explore the use of both Bitcoin-based cryptocurrency security systems and the data that can be stored on the blockchain to implement new systems. It would be highly advantageous if the blockchain could be used for automated tasks and processes that are not limited to the cryptocurrency realm. Such solutions can take advantage of the benefits of the blockchain (e.g., permanent, tamper-resistant record of events, decentralized processes, etc.) while being more diverse in their applications. Therefore, similar to the adoption of the early Internet and the subsequent rapid growth in the development of web-based systems, there is a need for widespread adoption and technological innovation of the technology for new applications.

[0006] However, writing programs in such a scripting language cannot be intuitively or immediately adopted by a wider programming community because, for example, it requires knowledge and proficiency related to low-level programming techniques. This requires the programmer to consider the stack and the position of the data in it. Writing a program 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 (registered trademark), etc. Compilers / interpreters built for such HLLs provide a convenient level of abstraction that keeps the programmer away from many cumbersome low-level problems related to memory management, etc. Describing a sequence of opcodes for manipulating data in one or more stacks is more technically complex and time-consuming than writing source code in an HLL. Therefore, due to the difficult characteristics of using low-level opcodes, the possibility of errors and bugs occurring is higher.

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

[0008] This intentional restriction can make the coding process more difficult for programmers, but it provides an important security mechanism by limiting program execution time and, importantly, protecting against malicious means, such as the use of infinite loops to carry out a Denial of Service (DoS) attack.

[0009] Therefore, there is a trade-off between significant security and the need to promote, encourage, and improve the development of blockchain-based technologies. To address the latter issue, Ethereum incorporates a high-level language (HLL) as an inherent feature into its own blockchain platform. Similar to Script, a low-level interpreter is required to generate an executable version of the code. Ethereum's HLL, known as Ether, allows for the execution of control flow through the use of conditional and unconditional jumps, which also enables iteration. To avoid issues such as denial-of-service (DoS) attacks, Ethereum limits transaction execution time by introducing the concept of gas, which is a portion of a cryptocurrency paid upfront to cover the execution cost. Therefore, the use of an inherent HLL requires a technically and commercially complex additional layer. Furthermore, Ethereum has suffered from at least one significant iteration-based attack. See, for example, http: / / hackingdistributed.com / 2016 / 06 / 18 / analysis-of-the-dao-exploit /

[0010] Therefore, it is desirable to provide a mechanism that allows programmers to more easily, quickly, and efficiently develop, design, and produce effective blockchain solutions using a programmer-friendly HLL language without exposing the security provided by a functionally restricted scripting language. This is by no means a trivial task and requires significant technological innovation. This is one of the technical problems addressed by the present disclosure. SUMMARY OF THE INVENTION

[0011] Accordingly, the present disclosure provides a system and corresponding method as defined in the appended claims.

[0012] Accordingly, according to the present invention, a method and corresponding system implemented by a computer can be provided. The method may be configured to enable or facilitate the 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. This may hereinafter be referred to as a "blockchain or Bitcoin compiler". The software compiler may be configured for use associated with a 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 programs / applications executable by a blockchain in a language they are familiar with, such as C, Java®, C++-style syntax. This expands blockchain-based development work to a wider development community. This also means that, as detailed below, blockchain-based solutions can be described and error-checked more quickly according to the present invention. Importantly, the security features of the underlying protocol and related scripting language are preserved and maintained. Accordingly, the present invention provides techniques and systems for preserving blockchain-related security during the process of script generation, facilitating or enabling the generation of valid, error-free scripts (and thus transactions) verified by nodes on a blockchain network.

[0014] According to one possible embodiment, a method implemented by a computer may be provided that uses static compilation to convert portions of source code into a script compatible with a blockchain. This may form the output provided by a compiler and may be referred to as an "output script". The present invention may test for one or more errors. The present invention may provide a warning if one or more errors are detected. Static compilation may include a loop unrolling step, and one or more loops provided within portions of the source code may be unrolled. Note that the terms "static compilation" and "loop unrolling" are well-known terms and will be immediately 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. This may be a "proof-of-work" blockchain. This may be a blockchain based on consensus. This may be a public and / or permissionless blockchain. This may be a peer-to-peer distributed blockchain.

[0016] The blockchain network may include a plurality of nodes that verify blockchain transactions. The blockchain transaction may include a script executable by the plurality of nodes. The script may be represented by or include a set of op_codes belonging to a functionally restricted (or also represented as Turing incomplete) blockchain script language. The method may include the step of generating an output script for inclusion in a blockchain transaction verified by a node of the blockchain network. The output script may be represented by a set of op_codes belonging to a functionally restricted blockchain script language, and the output script may be configured or adapted such that execution of the script by a node of the blockchain network performs the functions specified in the source code.

[0017] The source code portion 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 according to the present invention. The HLL may be compiled by a 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 that allows expressions, structures, and / or statements that implement complex control flows such as loops, complex selection structures, and / or loops (subject to real-world constraints). The syntax specific to the HLL may include loop-related syntax such as WHILE, FOR, or REPEAT loops. This may include primitives for performing encryption, arithmetic, and stack operation operations. The HLL may include customized opcodes and / or high-level language constructs substantially described below.

[0018] A script compatible with a blockchain may be a script (i.e., a program) formed of opcodes selected from a blockchain script language executable on the blockchain and forming its own and / or a part thereof. The opcode may be called a primitive or a command. The script may pass through an interpreter or a virtual machine before being executed / executable on the blockchain. (The term "blockchain" in this context may include a protocol and an implementation platform). The interpreter may convert the script into machine-executable (object) code. The blockchain script language may be, for example, the Script language used in connection with the Bitcoin protocol or a variant thereof. The script language may be configured for use with a blockchain protocol. The script language may include encryption, arithmetic, and stack operation opcodes.

[0019] The blockchain scripting language may be functionally restricted. The blockchain scripting language may be restricted with respect to functions configured to be permitted or processed by the syntax / interpreter. This may not inherently support complex control flows such as iteration, complex selection structures, and / or loops.

[0020] Additionally or alternatively, a method may be provided that enables or facilitates 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 and executable application executable on a blockchain as is conventionally known.

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

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

[0023] The method may include providing or using a compiler configured to execute any of the embodiments of the methods described above. The output script may be generated by executing static compilation.

[0024] The use of static compilation provides the advantage that the resulting script always halts. This not only provides a practical advantage at runtime, but also enables the present invention to function as a verification tool since the blockchain compiler halts when encountering any kind of error or invalid configuration in the source code. The advantage of being able to use the verification tool during script development means that programming work is improved by reducing the programmer's time and effort. Furthermore, the blockchain compiler provides a security solution in terms of testing for bugs and overflow errors, enabling the user (programmer) to statically test whether the program will execute and execute safely.

[0025] The blockchain scripting language may be restricted in that it does not natively support iteration by complex control flow constructs or loops or other iterative programming constructs based on jumps. The step of generating the output script may include the step of unwinding at least one loop construct provided in the source code. The method may include the step of providing or using an interpreter or virtual machine configured to convert the output script into a form executable on the blockchain platform.

[0026] The method may further include the step of optimizing 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 optimisation (DFO). DFO is a term known in the art and will be immediately understood by those skilled in the art. Additionally or alternatively, the step of generating the output script may include the use of derivative free optimisation.

[0027] The blockchain compiler may be configured to form part of and / or operate in relation to a software development kit (SDK). The SDK may include an editor, a debugger, and other known components to be used with the SDK to facilitate the generation of code-based solutions.

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

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

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

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

[0032] The present disclosure may provide a method including a step of using static compilation to convert a portion of source code into a script compatible with a blockchain. The static compilation may include a loop unrolling step.

[0033] The portion of 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 restricted blockchain script language. 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 at least one high-level programming construct (function) of the source code.

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

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

[0036] The loop configuration may include a code block and a condition for specifying the number of iterations of the loop configuration based on at least one variable. Desirably, the expansion of the loop configuration is related to describing an opcode command that selectively executes replicated opcodes of the function of the code block up to the maximum number of iterations, based on the evaluation of a condition that uses the value of a variable determined from the execution of the output script, and includes the step of replicating the opcodes of the function of the code block.

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

[0038] A computer-implemented system according to an embodiment of the present disclosure may include a compiler. The compiler may be configured to receive a portion of source code as input. 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 "script compatible with blockchain" and may include a plurality of opcodes. These opcodes may be selected from and / or be specific to a functionally restricted blockchain script language as described above, and when executed, the script provides at least partially the functions specified in the source code.

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

[0040] The present invention also provides a system including a processor and a memory including executable instructions that cause the system to execute any embodiment of the computer-implemented methods described herein as a result of execution by the processor.

[0041] The present invention also provides a non-transitory computer-readable storage medium storing executable instructions, which, as a result of being executed by a processor of a computer system, cause the computer system to execute at least an embodiment of the computer-implemented method described herein.

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

[0043] The above and other aspects of the present disclosure will be apparent from, and will be taught by, the embodiments described herein. Embodiments of the present disclosure will be described below by way of example only with reference to the accompanying drawings.

Brief Description of the Drawings

[0044]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Modes for Carrying Out the Invention

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

[0046] As noted 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 operations, and can consequently introduce errors. Thus, it can be advantageous for programmers to be able to write effective, tested, and error-checked code for blockchain applications in a language with which they are familiar, without risking the security provided by the underlying, restricted scripting language.

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

[0048] Advantageously, the blockchain compiler performs static compilation of the user's source code and enables implementation of complex control flow mechanisms through the use of techniques such as loop unrolling. As is conventionally known, "loop unrolling" may also be referred to as "loop unwinding". Loop unrolling is a loop transformation technique available to compilers to reduce the frequency of branches within a particular type of loop and / or to reduce loop maintenance instructions. By unrolling loops found in the source code, the compiler can generate a transformed version of the source code. This is executable on a blockchain platform using a functionally restricted scripting language.

[0049] Referring to FIG. 1, one embodiment of the present disclosure enables a user (programmer) to define code 1010 for a desired application, such as a smart contract, using a high-level language (HLL), and then execute 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 executable by bots (such as python, C++, etc.). Alternatively, they may be in the form of chunks of scripts 103 (such as Bitcoin). The latter is achieved by designing and generating chunks of scripts capable of performing specific functions. For example, the original version of the Bitcoin script included a function for multiplication called OP_MUL. This opcode is now disabled. However, the same function can be regenerated by using existing valid opcodes within small script portions.

[0050] Embodiments of the present disclosure may include one or both of the following two types of primitives. · Customized opcodes (hereinafter referred to as COP_CODE), · High-level language (HLL) constructs.

[0051] The HLL constructs require the compiler 102 to convert them into script code 103. On the other hand, COP_CODE only requires direct replacement from COP_CODE to a block of OP_CODE. Typically, a primitive is made into COP_CODE when it does not require access to variables, i.e., when it can be fully described using only OP_CODE and hard-coded inputs that already exist in the blockchain script language for a given protocol (and other COP_CODE).

[0052] For example, the monus primitive can be fully described by an opcode and thus can be made into the following COP_CODE. OP_SUB OP_0 OP_MAX

[0053] However, the execution of a WHILE loop depends on the variables required (e.g., the condition for execution, a counter for the number of iterations, etc.). Therefore, WHILE is not suitable to be made into COP_CODE and is described as an HLL construct.

[0054] Advantageously, the combination of the two types of primitives provides the programmer with additional flexibility. Programmers who write programs directly in Bitcoin script (i.e., do not use HLL) can use the script functionality extended with COP_CODE. In fact, these give the script programmer the replacement of a block of OP_CODE that executes their required functions, reducing programming time and effort. All that is needed is a "COP-CODE compiler" that simply replaces the COP_CODE with a block of the OP_CODE that makes up the COP_CODE. Programmers who cannot or do not want to write programs in low-level Bitcoin script can instead use the HLL supported by this disclosure.

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

[0056] (1) Customized OP_CODE (COP_CODE) This chapter describes the standards that may be applied in accordance with the present disclosure below, in relation to the script primitives of the customized OP_CODE (COP_CODE). The COP_CODE has a given format similar to a normal opcode and operates in the same way. That is, the writer of the Script (and / or compiler) uses the primitives in the same way as they conventionally use opcodes. A list of Bitcoin opcodes is available on the Bitcoin wiki. https: / / en.bitcoin.it / wiki / Script. ● Naming convention The script primitives are named here in the same way as Bitcoin Script opcodes as follows. COP_xxx Here, "xxx" is an abbreviation of the function. For example, the multiplication function may be named COP_MULT. Further, similar to the opcode, if the function has a specific number of parameters or a specific numerical value 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". Therefore, COP_2MULT specifically means "the input is multiplied by 2". ● Verification before execution If a specific number of inputs or a specific input format is expected, the primitive executes a check before executing the functional logic and terminates abnormally (marks the transaction as invalid) if the input does not match the expectation. Advantageously, this prevents executing and providing an output that the function may be incorrect or false. For example, if a specific primitive is intended to operate only on inputs that are positive numerical values, but is executed without error for negative numerical values, the result may be a "valid transaction" but with an unexpected or incorrect result.

[0057] (2) High-Level Language (HLL) Composition These are functions or statements that a compiler according to the present disclosure can recognize and convert into Bitcoin script. Collectively, they constitute a high-level programming language that uses a syntax familiar to programmers. Similar to familiar constructs (such as IF-ELSE, CASE, WHILE loops, etc.), there are also constructs that are very specific to HLL and unfamiliar for Bitcoin transactions to operate. For example, the INITIATE construct is a very specific function to ensure that the number of data inputs automatically pushed onto the main stack is saved as the first constant within the memory allocation (assigned to the reserved word NUM_INPUTS). In an embodiment, the INITIATE construct can be the first statement in the HLL program, and the DECLARE construct (which performs memory allocation for constants and variables) can be the second statement in the HLL program.

[0058] The HLL composition must be designed to be convertible into Bitcoin script (i.e., into OP_CODE and COP_CODE) using only the information available when being compiled by the compiler. This usually means a lot of hardcoding by the programmer where constants are declared (DECLARE) and values are assigned within the program. For example, even if NUM_INPUTS is considered a constant, the compiler does not have access to its value until the program is executed. Therefore, this cannot be used for compile-time execution (although of course the programmer can use it in the same way as other constants 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 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 the 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 may be used according to an embodiment for the description of the present disclosure is provided below. <HLL Construct: WHILE Loop> ● Description A 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: Execute syntax checking. Check that the iterations satisfy any constraints (e.g., are within a predetermined range). Check that the expression within the condition is evaluable. All constants / variables within the expression exist in the memory allocation (DECLARE) list. Check that all operators used within the expression are currently permitted (=, <, >, etc.). Check that the composite expression satisfies any constraints (e.g., AND, OR, etc.). Duplicate the function of the Code-Block "Iterations" times. START OF REPLICATED CODE Describe one or more opcodes that resolve the condition (i.e., the execution leaves true or false at the top of the stack).

[0063] General processing utilizes the RETRIEVE construct that fetches each value required for testing and places the value on top of the main stack, and then the related test operation (i.e., OP_EQUAL, OP_LESSTHAN, OP_GREATERTHAN, etc.) can be executed. If the value to be tested is a constant, the value is at a known position in the 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 this case, the value to be tested is determined during script execution), the position of the variable is at a known position in the 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] When the test utilizes a composite condition (using AND, OR, etc.), each sub-condition is evaluated separately and the final result (0 or 1) is left on top of the main stack. These are then combined to test the composite condition. For example, if the composite condition is in the form of "Exp1 OR Exp2", the operation first evaluates Exp1, then evaluates Exp2, and then describes OP_BOOLOR that compares the top two values on the stack (i.e., the evaluation results of Exp1 and Exp2).

[0065] The evaluation result is left on top of the main stack. Other values are not on the stack (except for the allocated memory, of course). The value is used by the next operation (OP_IF).

[0066] Convert the function of the Code-Block (sequence of operations) into a sequence of opcodes representing the function of the Code-Block. Such conversion can bypass any COP_CODE included in the Code-Block. This only requires a direct replacement of the Code-Block's sequence of opcodes for the COP_CODE. Next, describe the sequence of opcodes representing the function of the Code-Block within the OP_IF / OP_ENDIF pair. END OF REPLICATED CODE(End of Replicated Code)

[0067] In some embodiments, the sequence of opcodes representing the replicated Code-Block can be configured such that the initial stack positions of the constants and variables accessed by the sequence of opcodes are constant across loop iterations of a WHILE loop construct. The value of a variable can be updated across loop iterations, but such stack positions of constants and variables when starting the execution of each loop iteration remain constant across loop iterations. Such behavior ensures that the replicated 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 replicating a Code-Block depends on the value of one or more variables determined during script execution and can thus be updated across loop iterations. In this case, each iteration of the replicated Code-Block can include one or more opcode commands that test the associated condition. After the condition, a sequence of opcodes representing the replicated Code-Block embedded within an OP_IF / OP_ENDIF pair follows. In this configuration, during the execution of the script, the opcode commands that test the associated condition are evaluated as either TRUE or FALSE and place the result of TRUE or FALSE on top of the stack. The execution of the subsequent OP_IF statement selectively executes the replicated Code-Block only when the result of TRUE is on top of the stack. Thus, when the result of FALSE is on top of the stack, the execution of the OP_IF statement bypasses the execution of the replicated Code-Block.

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

[0070] Also, note that an HLL program can utilize a WHILE loop construct with a nested structure 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 relation to the loop unrolling for the outer WHILE loop construct. For example, the loop unrolling of the inner WHILE loop construct can replicate the sequence of opcodes representing the function of the Code-Block of the inner WHILE loop construct the number of times equal to the number of iterations of the inner WHILE loop construct between pairs of OP_IF / OP_ENDIF bytecode constructs. Furthermore, the loop unrolling of the outer WHILE loop construct can replicate the sequence of opcodes representing the function of the Code-Block of the outer WHILE loop construct the number of times equal to the number of iterations of the outer WHILE loop construct between pairs of OP_IF / OP_ENDIF bytecode constructs. In this case, the sequence of opcodes representing the function of the Code-Block for each iteration of the outer WHILE loop construct contains the sequence of opcodes the number of times equal to the number of iterations of the inner WHILE loop construct.

[0071] Also, note that WHILE loop nesting can be extended, with an additional inner WHILE loop construct contained within the Code-Block of the inner (first inner) WHILE loop construct and having the potential for further nesting. In this case, the loop unrolling operation as described in this specification can be immediately extended 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., the ' 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 inputs 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. Declare all constants and variables. Thus, the compiler can reserve "memory locations" (i.e., positions in the main and / or alt stacks). The standard is to hold constants in the main stack and variables in the alt stack. The compiler associates the names given to variables and constants with their positions on the stack. The compiler pushes the named items that already contain the data input provided by the user (see INITIATE) onto the main stack. On 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] ● Compiler operation: Describe the PUSHDATA command to place the declared (DECLARE) constant values of the HLL program into memory storage (such as the main stack). The command can push items one by one into memory storage starting from the top. The compiler can track the position of each constant value in memory storage (e.g., the main stack position). Describe the OP-TOALTSTACK command to place the variables of the HLL program into memory storage (such as the alt stack). Again, the compiler can track the position of each variable in memory storage (e.g., the alt stack position).

[0074] ● Example: [Number] Assuming that the compiler executes these statements subsequently (assuming that the required INITIATE statement obtains some values), the state of the memory storage (in this example, the main stack and alt stack) will be as follows. [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 position 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 beginning 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 pushed onto the top of the main stack for temporary 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 the item> + <number of items added to the stack>.

[0078] <HLL Structure: INCREMENT> ● Explanation: The variable is read from its position in memory, incremented by 1, and then relocated to that position 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 changing items 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 part. That is, Var-Posn = the position of Variable-name in 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 in 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: A variable is assigned a specified value. ● Syntax: RESET(Variable-name, Reset-value) Here, Variable-name: The name of the variable to which a new value should be assigned, Reset-value: The value to be assigned to Variable-name. ● Operation of the compiler: 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 ● Operation of the compiler: 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 the input from the transaction user (e.g., the input supplied by the execution of the unlock script of a spending transaction). The input to the lock script (i.e., "scriptsig") pushes 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 on top of them by the (mandatory) INITIATE statement. It is the programmer's responsibility to verify whether the rules of the transaction are met (e.g., the correct number of inputs are 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 on top of 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 into the script than using 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 parts of 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 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 it is 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: Hard-coded integer Declared constant Declared variable ● Compiler operation: If Velue1 is a hard-coded 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: The variable or constant is read from its position in its own memory and copied to the top of the main stack. The original value remains unchanged in its current position in its own "memory". ● Syntax: RETRIEVE(Item - name) Here, Item - name is a declared variable or constant ● Compiler operation: 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 part. That is, Item - posn = the position of Item - name within the stack (i.e., the number of items from the bottom of the stack). Operations use the Borrow Block technique. Calculate Item - Depth = Stack_Height - Item - posn + 1. If the required item is on the alt stack (i.e., it is a variable),

Number

Number

[0090] ● Example: Reading a copy of variable C Assume that the memory allocation looks like the following.

Number

Number

Number

[0091] <Reserved Word> ● Reserved Word: NUM_INPUTS Description: This is always the constant at the bottom of the memory block. That is, it is the "first" item within the block at the allocated stack position. Although this is a constant, it is not known during compilation. Therefore, this cannot be used by the compiler for any hard-coded script operations (e.g., this cannot be used as a numerical value to count how many times the OP_TOALTSTACK statement is generated within the compiled code). This is known at runtime. Therefore, this can be used by the programmer or the compiler for tasks such as conditional tests within loops and IF statements.

[0092] ● Reserved Word: TEMP Description: This is a temporary one-time variable that remains at the top of the stack after calculation. This exists to allow the programmer to refer to it during the calculation. The compiler checks the syntax to ensure that TEMP is still at the top of the stack when it is later referenced in the program.

[0093] ● Reserved Word: CONSTANTS Description: This is used in relation to the DECLARE construct. This is followed by a list of constructs that are pushed onto the main stack.

[0094] ● Reserved Word: VARIABLES Description: This is used in relation to the DECLARE construct. This is followed by a list of variables that are pushed onto the alt stack.

[0095] For the purpose of explanation, a usage example including a WHILE loop, an exemplary HLL program, and the Bitcoin script code that can be compiled therefrom are provided here. 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 in the prior art. These comments do not have to be part of the Bitcoin script code generated by the compiler, but are included below for the purpose of explaining the operation of the compiler when generating the exemplary Bitcoin script code.

[0096] <Example of WHILE Loop ~ Transaction (Tx)> Consider a blockchain transaction (Tx) with an internal list of 10 hardcoded 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 input "try" and checks whether it matches one of the hash values stored internally.

[0097] For clarity, consider the conventional method of describing the unlock script in the INPUT section of a Bitcoin transaction. <scriptsig> <scriptpubkey> Initial part <scriptsig>is the data and / or OP_CODE included in the spending transaction to unlock the OUTPUT of the previous transaction that was used. The second part <scriptpubkey>It 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. That is, the user has tried 5 different possible hash solutions. According to the above rules, 3 of them need to be correct to unlock the transaction. When the combined <Spender Input> <locking script> is executed, the first operation will be the one within the <Spender Input>. In this example, this is simply pushing 5 data items onto the stack.

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

Number

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

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

Number

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

Number

[0104] <Formal HLL Program> The following code is written in HLL using the syntax according to the embodiments of the present disclosure. This is intended to illustrate the use of WHILE, but unavoidably includes other HLL constructs (these are capitalized), and some of these will be immediately understood by those skilled in the art who are familiar with the syntax used by conventional up-to-date 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 load the corresponding array element.

Number

[0106] / * Outer loop. Pay attention to the synthesis conditions.

Number

Number

[0107] <Compiled Bitcoin Script> / * INITIATE (Initialization) Determine OP_DEPTH / / NUM_INPUTS (reserved word) and place it on top of the stack / *DECLARE CONSTANTS (Declaration of constants) Initialize the constants and place them on the main stack. The compiler knows the positions of the constants. An array of 12 values (these are the "try values" and will later have the actual input values inserted). Actually, 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 required to unlock Correct_Needed-TX is hardcoded as 3 OP_10 / / Num_Hashes - The number of hashes in the array is hardcoded as 10

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

[10] .

Number

[0109] / *DECLARE VARIABLEs (Declaration of variables). Initialize the variables (index and boolean) and place them on the alt stack. The compiler knows the positions. OP_0 OP_TOALTSTACK / / Correct_Counter - The number of correct hits (when a hash match is found). OP_0 OP_TOALTSTACK / / Try_counter - Index of the outer loop: Counter for the input values being tried. OP_0 OP_TOALTSTACK / / Hash_counter - Index of the inner loop: Counter for the hashes being tried. 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 pushed and acts as a memory store for variables. The compiler needs to "track" the position of the variables, i.e., their "depth" in the alt stack. The main stack is being pushed with constants. The compiler also needs to track the position of the constants. The "first value" of the main stack memory block is considered to be at the position of NUM_INPUTS (regardless of how many items are below it).

[0111] / * At this stage, the compiler knows that the value of NUM_INPUTS is at a depth of 27 in the main stack. The following operation copies this value to the top of the stack. Then, it pushes the value "12" onto the top of the stack and compares using ">". If NUM_INPUTS > 12 (corresponding to the allowed 12 "trials"), terminate abnormally. Since OP_VERIFY leaves the 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 a block of script code that reads the input values supplied by the user of the Tx output and populates them into the Try[] array. In one example, only 5 inputs (i.e., 5 "trials") are provided, so only the first 5 elements of Try[] are populated and the other elements remain with the value 0.

[0113] / * Outer WHILE loop. The maximum number of possible iterations (e.g., for each of a given set of rules) is 12. Therefore, the compiler unfolds 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 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 on 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 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 on 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 unfolds 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 variables from the alt stack, perform the test, and then return the variables again (“borrow block”).

[0122] / * First, get 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 thus knows that the position of the first hash value is 9 (because there are 5 Try values and 3 more constants are at the bottom of the stack). / * There is one TEMP value at the top of the main stack, so the current stack height is 19. If the depth of HASH-SAVED[4] (Hash_counter = 4) is desired, the depth is as follows. 「Hash-depth」 = 19 - 9 - 4 + 1 = 8 (That is, currently it is 8 from the top of the main stack).

Number

Number

[0127] / *End of the outer WHILE loop Duplication of the opcode sequence for the 2nd iteration of the outer WHILE loop (including the duplication of the opcode sequence for NUM_INPUTS iterations (up to 10) of the inner WHILE loop). Duplication of the opcode sequence for the 3rd iteration of the outer WHILE loop (including the duplication of the opcode sequence for NUM_INPUTS iterations (up to 10) of the inner WHILE loop). Duplication of the opcode sequence for the 4th iteration of the outer WHILE loop (including duplication of the opcode sequences for NUM_INPUTS iterations (up to 10) of the inner WHILE loop). Duplication of the opcode sequence for the 5th iteration of the outer WHILE loop (including duplication of the opcode sequences for NUM_INPUTS iterations (up to 10) of the inner WHILE loop). Duplication of the opcode sequence for the 6th iteration of the outer WHILE loop (including duplication of the opcode sequences for NUM_INPUTS iterations (up to 10) of the inner WHILE loop). Duplication of the opcode sequence for the 7th iteration of the outer WHILE loop (including duplication of the opcode sequences for NUM_INPUTS iterations (up to 10) of the inner WHILE loop). Duplication of the opcode sequence for the 8th iteration of the outer WHILE loop (including duplication of the opcode sequences for NUM_INPUTS iterations (up to 10) of the inner WHILE loop). Duplication of the opcode sequence for the 9th iteration of the outer WHILE loop (including duplication of the opcode sequences for NUM_INPUTS iterations (up to 10) of the inner WHILE loop). Duplication of the opcode sequence for the 10th iteration of the outer WHILE loop (including duplication of the opcode sequences for NUM_INPUTS iterations (up to 10) of the inner WHILE loop). Duplication of the opcode sequence for the 11th iteration of the outer WHILE loop (including duplication of the opcode sequences for NUM_INPUTS iterations (up to 10) of the inner WHILE loop). Duplication of the opcode sequence for the 12th iteration of the outer WHILE loop (including duplication of the opcode sequences for NUM_INPUTS iterations (up to 10) of the inner WHILE loop). When the 12 iterations of the outer WHILE loop are completed, the compiler checks whether the required number of hits has been reached (i.e., checks Correct_counter ≧ Correct_Needed). [Number]

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

[0129] In an embodiment, 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 optimisation (DFO). DFO is a term known in the art and will be immediately understood by those skilled in the art. Additionally or alternatively, the step of generating the output script may include the use of derivative free optimisation.

[0130] In an embodiment, the blockchain compiler may be configured to form part of and / or operate in association with a software development kit (SDK). The SDK may include an editor, a debugger, and other known components to be used with the SDK to facilitate the generation of code-based solutions.

[0131] FIG. 3 shows an exemplary blockchain network 1000 associated with a blockchain according to an embodiment of the present disclosure. In this embodiment, the exemplary blockchain network 1000 is composed of peer-to-peer distributed electronic devices that execute an instance of a blockchain protocol. In some examples, the distributed electronic device is referred to as node 1002. An example of a blockchain protocol is the Bitcoin protocol.

[0132] Node 1002 may be constituted by any suitable computing device (e.g., by a server in a data center, by a client computing device (such as a desktop computer, a laptop computer, a tablet computer, a smartphone, etc.), by a plurality of computing devices in a distributed system of a computing resource service provider, or by any suitable electronic client device such as the 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 nodes of the nodes 1002. Such a communication coupling can utilize one or more of well-known wired or wireless communication links. In an embodiment, each of the nodes 1002 maintains at least a portion of a "ledger" of all transactions within the blockchain. Thus, the ledger is a distributed ledger. Blockchain transactions processed by a node that affects the ledger are verified by one or more of the other nodes so that 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 related to complex calculations such as solving cryptographic problems. The miner nodes that solve the cryptographic problems generate new blocks of the blockchain and broadcast the new blocks to other nodes among the nodes 1002. The other nodes among the nodes 1002 execute a verification process to verify the work of the miner nodes, and upon verification, accept the blocks into the blockchain (e.g., by adding the blocks to the distributed ledger of the blockchain). In some examples, a block is a group of transactions and may be marked by a timestamp and the "fingerprint" (e.g., hash) of the previous block. Thus, each block becomes linked to the previous block, thereby generating a "chain" that links the blocks within the blockchain. In an embodiment, a valid block is added to the blockchain by the consensus of the nodes 1002. Also, in some examples, the blockchain includes a list of verified blocks.

[0135] In one embodiment, at least some of the nodes 1002 operate as verification nodes that perform a verification process to verify transactions as described in the present disclosure. FIG. 3 shows one exemplary labeled transaction 1004. In some examples, a transaction includes data that provides proof of ownership of a digital asset (e.g., the amount of Bitcoin tokens), and conditions for accepting or transferring ownership / control of the digital asset. In some examples, a "spending transaction" represents a transaction that reassigns (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" represents a transaction that includes the UTXO referenced by the spending transaction. In some embodiments, a transaction may include an "unlock script" and a "lock script". The lock script can be used to prevent a transaction unless conditions are met before the transaction can be made valid and ownership / control transferred by the transaction. In some embodiments, the lock script can be associated with an output of a transaction and used to define one or more conditions required to use the output. Further, the unlock script of a spending transaction can be configured to provide data such that execution of the unlock script derives a set of conditions that are evaluated by execution of the lock script of the previous transaction for verification of the spending transaction. The lock script of the previous transaction and the unlock script of the spending transaction are described using a low-level functionally constrained scripting language such as Bitcoin's Script.

[0136] In some embodiments, verification of a spending transaction may include execution of the unlocking script of the spending transaction, along with execution of the locking script of the previous transaction, to satisfy and verify a set of conditions described by the locking script of the previous transaction. Verification of a spending transaction may include other checks. Upon successful verification of a spending transaction, the spending transaction may be propagated to other network nodes. A miner node may select a valid spending transaction to embed as part of a block to be 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 script (or a fragment of a script) that is compatible with the blockchain. Since this may form the output provided by the blockchain compiler 1001, it may be referred to as an “output script”. The output script may be provided to a blockchain transaction (Tx). The output script may be part of the locking script associated with a transaction output, or part of the unlocking script associated with a transaction input. The output script may be formed of opcodes selected from and forming a unique and / or a portion thereof of a blockchain script language executable by nodes of the blockchain network. The opcodes may be referred to as primitives or commands. The opcodes of the script may be executed by an interpreter or virtual machine executing on a node of the blockchain network 1000. The interpreter or virtual machine may convert the opcodes of the script into machine-executable (object) code. The blockchain script language may be, for example, the Script language used in connection with the Bitcoin protocol or a variation thereof. The script language may include encryption, arithmetic, and stack operation opcodes.

[0138] The compiler 1001 can be part of an online service that uses static compilation to generate an SDK, or in some cases, a blockchain transaction script (or a fragment of a script) executable by a bot or node of a blockchain network.

[0139] Alternatively, the compiler method described herein can be used as part of the runtime environment of a bot or node of a blockchain network. Here, the runtime environment interprets, dynamically compiles, or converts a chunk of an HLL program (e.g., a program written in a 3G language such as python, C++, etc.) into a blockchain transaction script or script fragment executable by a bot or node of a blockchain network.

[0140] Figure 4 shows an exemplary blockchain protocol for the verification and mining of transaction 204 (designated as "TX2") that uses the output of transaction 202 (designated as "TX1") before spending. The previous transaction 202 has an output that includes a token amount (digital asset) and a lock script configured to define a set of conditions required to use the token amount. The previous transaction 202 is verified and mined. As a result, the previous transaction 202 is embedded in a block, which is then verified and stored in the blockchain 208. The spending transaction 204 includes an input that has a transaction output identifier field (designated as "Tx output ID") that references the output of the previous transaction 202 and an unlock script. The lock script of the previous transaction 202 and the unlock script of the spending transaction 204 are described using a low-level functionally restricted scripting language such as Bitcoin's Script. For the spending transaction 204 to be considered valid, the unlock script of the input must provide data that satisfies the set of conditions defined by the lock script of the referenced output of the previous transaction 202. The lock script (or a portion thereof) of the previous transaction 202 and the unlock script of the spending transaction 204 can be generated by the blockchain compilation methods and tools described herein.

[0141] The spending transaction 204 is verified by one or more nodes of the blockchain network (Figure 4) by executing the unlock script of the spending transaction 204 and the lock script of the previous transaction 202 to satisfy and verify the set of conditions described by the lock script of the previous transaction 202. Verification of the spending transaction 202 may include other checks. Upon successful verification of the spending transaction, the spending transaction may be propagated to other network nodes. The miner node can execute a mining operation to select a valid spending transaction and embed it as part of the block to be added to the blockchain 208, as described herein. Once verified and stored in the blockchain 208, the sequence of transactions 202 and 204 provides a transfer of control over the amount of tokens (digital assets) referenced by the transaction.

[0142] FIG. 5 shows 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 the blockchain compiler and network nodes of the blockchain network illustrated and described above. 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 operably coupled and configured to communicate via a bus system 2604 with a number of peripheral subsystems. The processor 2602 may be utilized for compilation of the HLL source code program into a blockchain script (or a fragment thereof) as described herein. These peripheral subsystems may include a memory 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 memory subsystem 2606 may be used for temporary or long-term storage of information such as details related to the transactions described in the present disclosure.

[0143] The bus subsystem 2604 may provide a mechanism for various components and subsystems of the computing device 2600 to communicate with each other as needed. Although the bus subsystem 2604 is schematically shown 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 function 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 being at a remote location such as a user data center. The bus system 2604 may be utilized to communicate data such as details, search terms, etc. to the monitoring model of the present disclosure, and the output of the monitoring model may be utilized to communicate to one or more processors 2602 and to merchants and / or creditors via the network interface subsystem 2616.

[0144] The user interface input device 2612 may include one or more user input devices such as a keyboard, a pointing device such as an integrated mouse, a touch pad, or a graphics tablet, a scanner, a barcode scanner, a touch screen built into a display, an audio input device such as a voice recognition system, a microphone, and other types of input devices. Generally, the use of the term "input device" is intended to include any possible type of device and mechanism 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, etc. 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. Generally, the use of the term "output device" is intended to include any possible type of device and mechanism for outputting information from the computing device 2600. The one or more user interface output devices 2614 may be used, for example, to present a user interface to assist in the user interaction when appropriate with an application that executes the processes described herein and variations thereof.

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

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

[0147] The computing device 2600 may include at least one local clock 2624. The local clock 2624 may be a counter representing the number of time units elapsed since a particular start date, and may be integrated and located inside the computing device 2600. The local clock 2624 may be used to synchronize data transfers to a particular clock pulse within the processor of the computing device 2600 and all subsystems included therein, and may be used to coordinate synchronization operations between the computing device 2600 and other systems within a data center. In one embodiment, the local clock 2624 is an atomic clock. In another embodiment, the local clock 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. Further, computing device 2600 may include another device that can be connected to computing device 2600 through one or more ports (e.g., USB, headphone jack, optical connector, etc.). The device that can be connected to computing device 2600 may include a plurality of ports configured to receive an optical fiber connector. Thus, the device may be configured to convert an optical signal into an electrical signal. The electrical signal may be transmitted through the port 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 the purpose of explaining a preferred embodiment of the device. Many other configurations are possible with more or fewer components than the system shown in FIG. 5.

[0149] Note that the above embodiments are illustrative rather than limiting the present disclosure, and those skilled in the art can devise numerous alternative embodiments without departing from the scope of the invention as defined by the appended claims. The methods, systems, and apparatuses (or portions thereof) of the present disclosure may be implemented by hardware having a plurality of distinct elements or by a computer appropriately programmed. In the claims of an apparatus that lists a plurality of means, these plurality of means may be implemented by one and the same hardware element. The fact that certain quantities are recited in mutually different dependent claims does not indicate that combinations of these quantities cannot be used advantageously.

[0150] Therefore, this specification and the accompanying drawings are to be construed as illustrative and not restrictive. However, it is apparent that various changes can be made without departing from the scope of the invention as set forth in the claims. Similarly, other modifications are within the scope of the disclosure. Thus, the disclosed technology is subject to various modifications and alternative configurations, although the specific illustrated embodiments are shown in the drawings and described in detail above. However, it should be understood that the invention is not limited to the one or more specific forms disclosed, but rather, as set forth in the appended claims, all modifications, alternative configurations, and equivalents are intended to be included within the scope of the invention.

[0151] In a claim, any reference signs in parentheses shall not be considered as limiting the claim. Further, in the context of describing the disclosed embodiments, the terms "a", "an", and "the", as well as similar referents (in particular, 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 the context. The terms "comprising", "having", "including", "containing" should be considered as broad terms (i.e., meaning "including, but not limited to") unless otherwise specified. The term "connected" should be considered to mean that something is physically connected without modification, even when something intervenes, and is considered to be included, attached, or joined together, either partially or wholly. In the present disclosure, the detailed description of a range of values is intended to function simply as a concise way of referring individually to each distinct value included in the range, and each individual value is incorporated into the present specification as if it were individually detailed in the present specification. The use of the term "set" (e.g., "a set of items") or "subset" should be considered as a non-empty set containing one or more components, unless otherwise specified or contradicted by the context. Further, unless otherwise noted or contradicted by the context, the term "subset" of a corresponding set does not necessarily denote a proper subset of the corresponding set, and the subset and the corresponding subset may be equal. A reference to a single element does not exclude the existence of a plurality of such elements, and vice versa.

[0152] Logical language such as phrases in the form of "at least one of A, B, and C" or "at least one A, B, and C" is understood to be used, unless otherwise specified or unless clearly inconsistent with the context, to indicate that an item, etc. may be any of A or B or C, or any non-empty subset of the set of A and B and C. For example, in an example for the description of a set having three components, the logical language "at least one of A, B, and C" or "at least one 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 not usually intended to mean that a particular embodiment requires the presence of at least one A, at least one B, and at least one C respectively.

[0153] The operations of the described processes, unless otherwise indicated or clearly inconsistent with the context, can be executed in any suitable order. The described processes (or their variations and / or combinations) may be executed under the control of one or more computer systems composed of executable instructions, and may be implemented in hardware, or in combination, as code (e.g., executable instructions, one or more computer programs or one or more applications) executed collectively on one or more processors. The code may be stored in 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 in this specification is merely intended to better illustrate embodiments of the present invention and is not intended to limit the scope of the present invention unless otherwise specified. No language in the specification should be considered as indicating any non-claimed element essential for the implementation of the present invention.

[0155] Embodiments of the present disclosure include the best modes described in the present disclosure and 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 skilled artisans to appropriately utilize these variations, and the inventors intend for the embodiments of the present disclosure to be practiced in a manner different from that particularly described. Accordingly, the scope of the present disclosure includes all variations and equivalents of the subject matter recited in the appended claims as permitted by appropriate law. Further, any combination of the above-described elements in all possible variations is included within the scope of the present disclosure unless otherwise specifically stated or clearly inconsistent with the context.

[0156] All references, including the publications, applications, and patents cited, are incorporated herein by reference as if each reference were individually and specifically indicated and were set forth in its entirety.

Description of Symbols

[0157] 101 HLL source code (CPO_Codes, HLL configuration) 102 Blockchain compiler 103 Script (opcode) compatible with the blockchain protocol / platform 104 Interpreter 105 Execute on the blockchain < / scriptpubkey> < / scriptsig> < / scriptpubkey> < / scriptsig>

Claims

**Claim 1** A method implemented by a computer, comprising: receiving, as an input, a portion of source code, the portion of source code being written in a high-level language (HLL); generating an output script that includes a plurality of opcodes selected from and / or specific to a blockchain scripting language, the output script, when executed on a blockchain platform, providing at least partially a function specified in the portion of source code, the blockchain scripting language being restricted to support an iterative programming construct; wherein the step of generating the output script includes expanding a loop construct provided in the portion of source code, the loop construct including a block of code, a condition, and a maximum number of iterations, the method implemented by a computer. **Claim 2** The method implemented by a computer according to claim 1, wherein the loop construct is a WHILE loop. **Claim 3** The method implemented by a computer according to claim 1 or 2, wherein the step of expanding the loop construct includes, in the output script, replicating one or more opcode commands that test the condition the number of times equal to the maximum number of iterations, followed by a sequence of opcodes representing the function of the block of code embedded inside an OP_IF / OP_ENDIF pair. **Claim 4** The method implemented by a computer according to any one of claims 1 to 3, wherein the condition is an evaluable expression that evaluates to true or false. **Claim 5** The method implemented by a computer according to any one of claims 1 to 4, wherein the restriction that the blockchain scripting language is restricted to support an iterative programming construct further includes a restriction that the blockchain scripting language does not natively support loops based on iteration and / or jumps. **Claim 6** The method implemented by a computer according to any one of claims 1 to 5, wherein the blockchain scripting language is stack-based and the HLL includes one or more primitives configured to perform operations on a stack used by the blockchain scripting language.

7. The output script is generated by a compiler, and is a computer-implemented method according to any one of claims 1 to 6.

8. The method further includes the step of executing the output script, the blockchain script language is stack-based, during the execution of the output script, one or more opcode commands for testing the conditions are evaluated as true or false results, and the true or false result is placed at the top of the stack. When the true result is at the top of the stack, the execution of the subsequent OP_IF statement selectively executes the block of the replicated code. When the false result is at the top of the stack, the execution of the OP_IF statement bypasses the execution of the block of the replicated code. The method is implemented by a computer according to claim 3.

9. The maximum number of iterations is defined by a parameter specified within the loop configuration, and is a computer-implemented method according to claim 1.

10. A computer-implemented system, comprising one or more processors and a memory storing computer-executable instructions, the computer-executable instructions causing, as a result of execution, the one or more processors to receive, as input, a portion of source code, the portion of source code being described in a high-level language (HLL), generate an output script including a plurality of opcodes selected from and / or specific to a blockchain script language, the output script, when executed on a blockchain platform, providing at least partially the functionality specified in the portion of the source code, the blockchain script language being restricted to support an iterative programming configuration, wherein, to generate the output script, the one or more processors are configured to expand a loop configuration provided in the portion of the source code, the loop configuration including a block of code, a condition, and a maximum number of iterations.

11. Further comprising a compiler, the compiler receives, as input, the portion of the source code, the source code being described in a high-level language (HLL), Generate an output script that includes a plurality of opcodes selected from a functionally restricted blockchain scripting language, such that when executed, the output script provides at least in part the functionality specified in the portion of the source code. Generating the output script includes expanding a loop construct provided in the portion of the source code, the loop construct including blocks of code, conditions, and a maximum number of iterations. Expanding the loop construct includes, within the output script, replicating one or more opcode commands that test the condition the number of times equal to the maximum number of iterations, followed by a sequence of opcodes representing the functionality of the block of code embedded inside an OP_IF / OP_ENDIF pair. The system according to claim 10.

12. The system according to claim 10 or 11, further including a software development kit (SDK).

13. The computer-executable instructions further cause the one or more processors to execute the output script, the blockchain scripting language is stack-based, during execution of the output script, the one or more opcode commands that test the condition are evaluated as a true or false result, the true or false result is placed at the top of the stack, and execution of a subsequent OP_IF statement selectively executes the replicated block of code when the true result is at the top of the stack, and bypasses execution of the replicated block of code when the false result is at the top of the stack. The system according to claim 11.

Images