System and method for compiling high-level language code into executable scripts on blockchain platform

Abstract

A computer-implemented method (and corresponding system) is provided that enables or facilitates execution of partial source code written in a high-level language (HLL) on a blockchain platform. The methods and systems may include a blockchain compiler configured to convert a portion of the advanced source code into a form that may be used with a blockchain platform. The method may include: receiving a portion of source code as an input; and generating an output script including a plurality of opcodes. The opcode is a subset of opcodes inherent to the function-limited block chain script. An output script is set and / or generated such that, when executed, the script provides, at least in part, the functionality specified in the source code. Block chain scripting languages are limited so that they do not inherently support complex control flow structures or recursion through jump-based loops or other recursive programming structures. The step of generating the output script may include unrolling at least one loop structure provided in the source code. The method may further include providing or using an interpretation program or virtual machine configured to convert the output script into a form executable on the blockchain platform.

Description

[0001] This application is a divisional application of the patent application with Chinese application number 201880045600.6 (PCT international application number PCT / IB2018 / 054971), application date July 5, 2018, and name “System and method for compiling high-level language code into executable scripts on a blockchain platform”. Technical Field

[0002] The present disclosure relates generally to distributed ledger technology, and more specifically to blockchain technology. The present invention also relates to compilers and compiler-related technologies for converting computer-based code. One or more embodiments of the present invention are suitable for use as a solution that enables and / or facilitates the automation and execution of high-level programs on a blockchain platform or protocol that includes a functionally limited script-based language. Background Art

[0003] In this article, we use the term "blockchain" to cover all forms of computer-based electronic distributed ledger technology. These include consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and their variants. It should be noted that the present invention is not limited to use with a specific blockchain, and alternative blockchain implementations and protocols fall within the scope of the present invention. The term "user" herein can refer to a human or a processor-based resource.

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

[0005] In order for a transaction to be written to the blockchain, it must be "validated". Network nodes 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 validation work on the unspent transactions (UTXO) by executing its locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to TRUE and possibly passes other checks, the transaction is valid and is written to the blockchain. Therefore, in order for a transaction to be written to the blockchain, the transaction must i) be validated by the first node that receives the transaction - if the transaction is validated, the node relays it to other nodes in the network; ii) be included in a new block built by the network nodes; iii) be mined, i.e. added to the public ledger of past transactions.

[0006] Digital entrepreneurs have begun exploring the use of both cryptographically secure systems and data that can be stored on blockchains to enable new systems. It would be extremely advantageous if blockchains could be used to automate tasks and processes. Such solutions would be able to leverage the benefits of blockchains (e.g., permanent, tamper-proof records of events, distributed processing, etc.) while being more versatile in their applications. Therefore, there is a need for wider use of the technology for new applications and technological innovations, similar to the early use of the Internet and the subsequent boom in the development of web-based systems.

[0007] However, writing programs in scripting languages ​​is not intuitively easy to accept by the wider programming community, for example, because it requires knowledge and skills about low-level programming techniques. It requires programmers to consider the location of the stack and the data therein. Writing programs composed of low-level opcodes is more time-consuming and labor-intensive than writing source code in high-level languages ​​(HLLs) such as C, Java, etc. The compiler / interpreter built for the HLL provides a convenient abstraction layer that keeps programmers away from more laborious low-level problems related to memory management, etc. Writing a sequence of opcodes to manipulate the data in one or more stacks is more technically complex and time-consuming than writing source code in HLL. Therefore, due to the difficulty of using low-level opcodes, errors and defects are more likely to occur.

[0008] In addition, HLL enables programmers to include complex control flow structures such as loops, case statements, and recursive calls in their source code. Programmers can focus on the required logic and express the logic flow in an intuitive way through mechanisms such as "while this is true, do X...". However, some scripting languages ​​associated with blockchains, such as Script, are functionally limited because they include classical operators such as arithmetic operations, as well as cryptographic functions such as hash operators and signature verification, but do not include inherent primitives for complex control structures (such as while loops) and do not allow the use of recursive techniques, as can be used in HLL. The restricted language does not support jump-based control flow. Therefore, by design, it limits the language and logic structures provided to programmers to include in the source code. This has led some people to argue that restricted languages ​​such as Script are non-Turing complete, although this definition has been disputed by others. Therefore, the phrase "functionally limited" will be used here.

[0009] It should be noted that while this deliberate restriction makes the coding process more difficult for the programmer, it also puts a bound on program execution time and, importantly, provides an important safety mechanism as it prevents malicious exploits, such as the use of infinite loops to carry out denial of service (DoS) attacks.

[0010] Therefore, there is a trade-off between critical security and the need to facilitate, encourage and improve development based on blockchain technology. To address the latter issue, HLL languages ​​can be included in blockchain platforms as native functionality. Like Script, a low-level interpreter is required to produce an executable version of the code. Some HLL languages ​​allow control flow to be enforced by using conditional and unconditional jumps. They also allow recursion. To avoid issues such as DoS attacks, transaction execution time is limited by introducing the concept of gas, which involves prepayment to cover the execution cost. Therefore, an additional layer of technical and commercial complexity is required due to the use of native HLL.

[0011] Therefore, it is desirable to provide a mechanism by which programmers can use their familiar HLL language to develop, design and generate effective blockchain solutions in an easier, faster and more efficient manner without compromising the security provided by the functionally limited scripting language. This is by no means a trivial task, and it is one that requires a considerable degree of technical innovation. This is one of the technical problems solved by the present invention. Summary of the invention

[0012] Thus, in accordance with the present disclosure, certain systems and corresponding methods are provided.

[0013] According to the present disclosure, a computer-implemented method and corresponding system may be provided. The method may be configured to enable or facilitate execution of a portion 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 software compilers. This may be referred to as a "blockchain compiler" hereinafter. The software compiler may be configured to be used in conjunction with any blockchain-based protocol / network.

[0014] Advantageously, the software compiler of the present disclosure can enable users (programmers) to write and create blockchain executable programs / applications in familiar languages ​​(such as C, Java, C++ syntax format). This expands the task of blockchain-based development to a wider development community. This also means that blockchain-based solutions can be written more quickly and can be error-checked by the present invention, which is described in more detail below. It is crucial that the security features of the underlying protocol and associated scripting language are retained and maintained. Therefore, the present invention provides a technology and system for retaining security related to blockchain during the script generation process, and facilitates or enables the generation of valid error-free scripts (and transactions) that are verified by nodes on the blockchain network.

[0015] According to one possible implementation, a computer-implemented method may be provided that uses static compilation to convert a portion of source code into a blockchain-compatible script. This may be referred to as an "output script" because it may form the output provided by the compiler. The present invention may be tested for one or more errors. It may provide an alert when one or more errors are detected. Static compilation may include a step of loop unrolling; one or more loops provided within the portion of source code may be unrolled. It should be noted that the terms "static compilation" and "loop unrolling" are terms known in the art and are readily understood by those skilled in the art.

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

[0017] A blockchain network may include a plurality of nodes that validate blockchain transactions. A blockchain transaction may include a script that may be executed by a plurality of nodes. The script may be represented by or include a set of opcodes belonging to a functionally restricted (or non-Turing complete) blockchain scripting language. The method may include the steps of generating an output script for inclusion in a blockchain transaction that is validated by a node of the blockchain network. The output script may be represented by a set of opcodes belonging to a functionally restricted blockchain scripting language, and the output script may be set or overwritten so that execution of the script by a node of the blockchain network may implement the functionality specified in the source code.

[0018] This part of the source code can be written in a high-level language (HLL). HLL can be described as a compilable HLL. HLL can be compiled by a software component (compiler) arranged according to the present invention. HLL can be compiled by a compiler to generate a script that can be executed by an interpreter. The script can be set in a blockchain transaction (Tx). The script can be associated with the input or output of the transaction. HLL can be a Turing complete language (constrained by the real world) because it can allow expressions, structures and / or statements that implement complex control flows (such as recursion), complex selection structures and / or loops. The syntax inherent to HLL may include syntax related to loops such as WHILE, FOR or REPEAT loops. It may include primitives for performing cryptographic operations, arithmetic operations and stack manipulation operations. HLL may include customized opcodes and / or high-level language structures, as described below.

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

[0020] The blockchain scripting language may be limited in functionality. It may be limited in the functionality that the syntax / interpreter is set up to allow or handle. It may not inherently support complex control flow such as recursion, complex selection structures, and / or loops.

[0021] Additionally or alternatively, a method may be provided, the method being arranged to enable or facilitate execution of a portion of source code written in a high level language (HLL) on a blockchain platform. The source code may be arranged to implement a smart contract. A smart contract may be a machine readable and executable application that can be executed on a blockchain, as is known in the prior art.

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

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

[0024] The method may include the steps of: providing or using a compiler configured to perform any of the above method embodiments. The output script may be generated by performing static compilation.

[0025] Using static compilation provides the advantage that the generated script will always stop. This not only provides practical benefits at runtime, but also enables the invention to be used as a verification tool because the blockchain compiler will stop if a certain type of error or invalid structure is encountered in the source code. The advantage of being able to use verification tools during script development means that the programming task is enhanced by reducing programmer time and effort. Further, the blockchain compiler provides a solution to security because it tests for defects and overflow errors, which enables the user (programmer) to statically test whether the program will execute and execute safely.

[0026] The blockchain scripting language may be limited such that it does not inherently support complex control flow structures or recursion through jump-based loops or other recursive programming structures. The step of generating the output script may include expanding at least one loop structure 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.

[0027] The method may further comprise the step of optimizing the output script at least once, thereby providing a more efficient or simplified version of the output script. This may comprise the use of derivative free optimisation (DFO). DFO is a term known in the art and is readily understood by those skilled in the art. Additionally or alternatively, the step of generating the output script may comprise the use of derivative free optimisation.

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

[0029] The HLL may include at least one primitive, operator, or structure that may be directly converted to one or more primitives / commands / opcodes native to the blockchain scripting language.

[0030] The blockchain scripting language may be stack-based. It may be configured to manipulate one or more stacks. The HLL may include one or more primitives or operators configured to cause operations to be performed on the stack used by the scripting language.

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

[0032] The HLL may include at least one of the following primitives or operators or their respective functional equivalents:

[0033] Initiate;

[0034] Declare;

[0035] Increment;

[0036] IF;

[0037] While;

[0038] Populate;

[0039] Monus;

[0040] Reset;

[0041] Rawscript;

[0042] Abort;

[0043] Retrieve;

[0044] Hash, hash 160, or other hash operations or variations thereof.

[0045] Additionally or alternatively, the present disclosure may provide a computer-implemented method comprising the steps of: receiving a portion of source code as input, wherein the portion of source code is written in a high-level language (HLL) and specifies functionality; and generating an output script, wherein the output script comprises a plurality of op_codes selected from and / or inherent to a functionally restricted blockchain scripting language, such that the output script at least partially provides the functionality specified in the portion of source code when executed; wherein the functionally restricted blockchain scripting language is restricted from, or does not support, recursive programming structures.

[0046] Optionally, the step of generating an output script includes: expanding at least one loop structure provided in the portion of source code, wherein the loop structure includes a code block, a condition, and a maximum number of iterations.

[0047] Optionally, the loop structure is a WHILE loop.

[0048] Optionally, said unrolling of said loop construct comprises: copying one or more op_code commands in said output script, a number of copies being equal to said maximum number of iterations, said one or more op_code commands testing a condition followed by an op_code sequence representing the functionality of a code block embedded in an OP_IF / OP_ENDIF pair.

[0049] Optionally, the condition is an evaluable expression that resolves to TRUE or FALSE.

[0050] Optionally, the method further comprises: executing the output script; wherein the limited-function blockchain scripting language is stack-based; and, during execution of the output script, one or more opcode commands that test the condition will evaluate to a TRUE or FALSE result and place the TRUE or FALSE result on top of the stack; and wherein, when the TRUE result is at the top of the stack, execution of the OP_IF statement will selectively execute the copied code block, and when the FALSE result is at the top of the stack, execution of the OP_IF statement will bypass execution of the copied code block.

[0051] Optionally, the maximum number of iterations is defined by a parameter specified in the loop structure.

[0052] The present disclosure may provide a method, the method comprising the following steps: 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.

[0053] The portion of source code may include at least one high-level programming structure. An output script may be generated by converting the high-level programming structure into one or more opcodes belonging to a functionally restricted blockchain scripting language. One or more opcodes of the output script may be set or rewritten so that the one or more opcodes are executed by a node of the blockchain network to implement (the function of) at least one high-level programming structure of the source code.

[0054] Preferably, the functionally limited blockchain scripting language does not support loop constructs. Preferably, at least one high-level programming construct includes a loop construct. Preferably, the script is generated by an unrolled loop construct (also referred to as a "looping construct"). Preferably, the loop construct includes a code block and an actual parameter argument specifying a number of iterations, and the unrolled loop construct includes an opcode for programming a function for the code block with the above number of iterations.

[0055] The method may further include the following steps: checking the syntax of the loop structure, thereby ensuring that the loop structure includes an actual parameter argument specifying the number of iterations, and ensuring that the actual parameter argument satisfies a constraint specifying a maximum number of iterations.

[0056] The loop structure may include a code block and a condition for specifying a number of iterations of the loop structure based on at least one variable. Preferably, unrolling the loop structure includes: duplicating an opcode for a function of the code block in conjunction with writing an opcode command, the opcode command selectively executing the duplicated opcode for the function of the code block at a maximum number of iterations based on an evaluation of the condition using a variable value determined according to execution of the output script.

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

[0058] 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 "blockchain-compatible script" and may include a plurality of opcodes. These opcodes may be selected from a functionally limited blockchain scripting language as described above, and / or these opcodes are inherent to the language so that when executed, the script at least partially provides the functionality specified in the source code.

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

[0060] The present invention also provides a system (e.g., a computer-implemented system), comprising:

[0061] Processor; and

[0062] A memory including executable instructions (eg, computer-executable instructions) that, due to execution by the processor, cause the system to perform any embodiment of the computer-implemented method described herein.

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

[0064] Any features described above with respect to one aspect or one embodiment of the present disclosure may also be applied to one or more other aspects or embodiments.Any features described with respect to the method of the present disclosure may be equally applied to the system according to the present disclosure, and vice versa. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] These and other aspects of the invention will become apparent from and will be elucidated with reference to the embodiments described herein. Embodiments of the invention will now be described by way of example only with reference to the accompanying drawings, in which:

[0066] Figure 1 An overview of the present invention is shown.

[0067] Figure 2 A code block for filling Try[] as described in the following example of unrolling a while loop is provided.

[0068] Figure 3 A blockchain environment is shown in which various embodiments may be implemented.

[0069] Figure 4 A blockchain protocol for validating and mining spent blockchain transactions that reference previous blockchain transactions is shown, according to an embodiment;

[0070] Figure 5 A computing environment is shown in which various embodiments may be implemented. DETAILED DESCRIPTION

[0071] summary

[0072] Hereinafter, we will mention some specific protocols, blockchains, networks or scripting languages ​​only for ease of reference because these are the most widely known and adopted. However, other blockchain technologies also fall within the scope of this disclosure.

[0073] As mentioned above, most programmers today write code in high-level languages ​​(e.g., C, C++, Java, etc.) rather than in low-level languages. Writing code at a lower level takes more time, requires more expertise in memory manipulation, and can introduce errors as a result. Therefore, it would be advantageous for programmers to be able to write valid, tested, and error-checked code for blockchain applications in a familiar language without compromising the security provided by the underlying restricted scripting language.

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

[0075] Advantageously, the blockchain compiler performs static compilation of the user's source code and enables complex control flow mechanisms to be implemented by using techniques such as loop unrolling. As is known in the art, "loop unrolling" may also be referred to as "loop unrolling". Loop unrolling is a loop transformation technique that a compiler may use to reduce the frequency of branches in certain types of loops and / or reduce loop maintenance instructions. By unrolling loops in the source code, the compiler may generate a transformed version of the source code that can be executed on a blockchain platform using a limited-function scripting language.

[0076] Go to Figure 1 , embodiments of the present disclosure enable users (programmers) to define code 101 for a desired application (e.g., a smart contract) using a high-level language (HLL), and then execute a blockchain compiler 102, which compiles the HLL code 101 into an executable file. These executable files can be in the form of 3G language program blocks (e.g., python, C++, etc.) that can be executed by a robot, or can be in the form of script 103 blocks. The latter is achieved by designing and generating script blocks that can perform specific functions. For example, a multiplication function called OP_MUL. This opcode is currently disabled. However, the same function can be recreated by using an existing opcode that has been enabled in a small part of the script.

[0077] Implementations of the present disclosure may include one or both of two primitives:

[0078] A customized operation code (hereinafter referred to as COP_CODE); and

[0079] High-level language (HLL) structure

[0080] The HLL structure requires the compiler 102 to convert it into script code 103, while COP_CODE only requires a direct replacement from COP_CODE to OP_CODE blocks. Typically, if the primitive does not need to access any variables, that is, the primitive can be fully described using only the OP_CODE (and other COP_CODEs) that already exist in the blockchain scripting language for a given protocol and hard-coded inputs, the primitive is made directly into COP_CODE.

[0081] For example, the monus primitive can be fully described using opcodes and can be made into a COP_CODE as follows:

[0082] OP_SUB

[0083] OP_0

[0084] OP_MAX

[0085] However, the execution of the WHILE loop depends on the required variables (e.g., execution condition; counter of the number of iterations; etc.). Therefore, WHILE is not suitable to be made as COP_CODE, but it should be written as an HLL structure.

[0086] Advantageously, the inclusion of both primitives provides additional flexibility to programmers. Programmers who write programs directly into blockchain scripts (i.e., not using HLL) will be able to use enhanced scripting functionality through COP_CODE. In effect, these provide script programmers with a replacement for OP_CODE blocks that will perform the desired functionality, which reduces programming time and effort. All that is needed is a "COP-CODE compiler" that simply replaces the COP_CODE with the OP_CODE blocks that constitute it. Programmers who are unable or unwilling to write programs in low-level scripts will be able to use the HLL supported by the present disclosure instead.

[0087] The customized OP_Code (COP_Code) is discussed further below.

[0088] 1. Customized OP_CODE (COP_CODE)

[0089] This section describes the following applicable standards related to script primitives for custom OP_CODEs (COP_CODEs) according to the present disclosure. The format of COP_CODEs is similar to conventional opcodes and operates in the same manner. That is, script (and / or compiler) writers use primitives in the same way as opcodes are traditionally used.

[0090] Naming conventions

[0091] Script primitives are named here in a similar way to script opcodes, as follows:

[0092] COP_xxx

[0093] Where "xxx" is shorthand for the function. For example, a multiplication function could be named: COP_MULT. Also, similar to opcodes, if a function has a specific number of parameters or a specific number used in a calculation, the name can include that number. For example, the opcode "OP_2DROP" means "delete the first two stack items", while "OP_1ADD" means "add 1 to the input". Therefore, COP_2MULT could specifically mean "multiply the input by 2".

[0094] Verification before execution

[0095] If a specific number of inputs or input formats are expected, the primitive performs a check before executing the functional logic, and aborts (marks the transaction as invalid) if the input does not match expectations. Advantageously, this prevents functions from executing and providing outputs that may be incorrect or misleading. For example, if a particular primitive is only intended to operate on inputs that are positive numbers, but still executes without error on negative numbers, the result may be a "valid transaction" with unexpected or incorrect results.

[0096] 2. High-Level Language (HLL) Structure

[0097] These are functions or statements that the compiler arranged according to the present disclosure can recognize and can be converted into a script. All of these together constitute a high-level programming language that uses a syntax familiar to programmers. In addition to familiar structures (such as IF-ELSE, CASE, WHILE loops, etc.), there are some unfamiliar HLL very specific structures. For example, the INITIATE structure performs a very specific function, which is to ensure that the number of data inputs automatically pushed into the main stack is saved as the first constant in the memory allocation (allocated to the reserved word NUM_INPUTS). In an embodiment, the INITIATE structure can be the first statement in the HLL program, and the DECLARE structure (which performs memory allocation for constants and variables) can be the second statement in the HLL program.

[0098] The HLL structure must be designed in such a way that the compiler converts it into a script (i.e., into OP_CODE and COP_CODE) using only information available at compile time. This usually means a lot of hard coding by the programmer, where constants are declared in DECLARE and assigned values ​​in the program. For example, even though NUM_INPUTS is considered a constant, the compiler cannot access its value before program execution and therefore cannot use it for compilation execution (however, of course the programmer can use it in the program like any other constant).

[0099] When designing the HLL structure, the designer can include the expected operation of the compiler using either pseudocode or clear descriptions in natural language. For example, the compiler may be required to perform certain checks - such as correct syntax and verification that any constraints (such as size limits) are met. This should be made clear, even though the specific constraints may not yet be known. The task of designing the HLL structure does not include writing the compiler itself, but must ensure that all the expected operations of the compiler can be carried out.

[0100] A series of HLL structures that may be used in accordance with exemplary embodiments of the present disclosure are now provided.

[0101] HLL Structure: While Loop

[0102] describe

[0103] A block of code (or code-block, often called the loop body) is executed repeatedly, up to a maximum number of iterations, as long as a specified condition remains True. The maximum number of iterations must be known and specified at compile time. Loops are simulated by a technique called "unrolling loops". This means that a sequence of opcodes representing the functionality (sequence of operations) of the code block is replicated for a specified maximum number of iterations. An IF statement preceding each replicated opcode sequence for the code block determines whether the opcode sequence of the code block is executed. The IF condition is checked at the beginning of the loop, i.e. before the first execution of the opcode sequence of the code block.

[0104] grammar:

[0105] WHILE(Iterations,Condition)

[0106] <code-block>

[0107] END_WHILE

[0108] in:

[0109] Iterations:

[0110] positive integer

[0111] The maximum number of times a code block can be executed. The compiler needs to know this value because it will generate code blocks up to that many times. It can be hard-coded, or it can refer to a constant in a DECLARE statement.

[0112] condition:

[0113] An evaluable expression that resolves to TRUE or FALSE

[0114] Can be compound conditions - i.e. using AND, OR, etc. (whichever the compiler currently recognizes) compiler operations:

[0115] Perform a syntax check.

[0116] Checks that the iterations satisfy any constraints (e.g., fall within a specified range)

[0117] Check that the expression in the Condition is evaluable:

[0118] All constants / variables in the expression are present in the memory allocation (DECLARE) list. Check that all operators used in the expression are currently allowed (=, <, >, etc.).

[0119] Checking that a compound expression satisfies any constraints (e.g., finite AND, OR, etc.) will iterate the code block's functionality "number of times":

[0120] Start copying the code

[0121] Write one or more opcodes that resolve the condition (i.e., execution of the opcode leaves a TRUE or FALSE value on the top of the stack):

[0122] A regular procedure can use a RETRIEVE structure, which takes each value needed for the test and places that value on the top of the main stack; then performs the relevant test operation (i.e., OP_EQUAL, OP_LESSTHAN, OP_GREATERTHAN, etc.). If the value to be tested is a constant, it will be located at a known location in allocated memory (i.e., a known location on the main stack) and will be copied to the top of the stack using OP_PICK. If the value to be tested is a variable (in which case the value to be tested is determined during script execution), the location of the variable will be located at a known location in allocated memory (i.e., a known location on the alt stack) and can be copied to the top of the main stack using the "borrow block" method.

[0123] If the test takes a compound condition (using AND, OR, etc.), each sub-condition is evaluated separately and the final result (0 or 1) is kept on top of the main stack. These are then combined to test the compound condition. For example, if the compound condition is of the form "Exp1 OR Exp2": the operation first evaluates Exp1, then Exp2, then OP_BOOLOR is written which will compare the first two values ​​on the stack (i.e. the evaluation results of Exp1 and Exp2).

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

[0125] Convert the functionality (sequence of operations) of the code block into a sequence of opcodes that represent the functionality of the code block. For any COP_CODE contained in the code block, this conversion can be bypassed and the COP_CODE can simply be substituted directly into the opcode sequence of the code block. Then, write the opcode sequence that represents the functionality of the code block in the OP_IF / OP_ENDIF pairs.

[0126] End of copied code

[0127] In some embodiments, the opcode sequence representing the copied code block can be configured so that: the initial stack position of constants and variables accessed by the opcode sequence for each iteration of the WHILE loop structure is constant across loop iterations. Note that the values ​​of variables may be updated across loop iterations; however, the stack positions of the constants and variables at the beginning of each loop iteration will remain constant during the loop iteration. This operation ensures that the copied opcode sequence accesses the appropriate constants and / or variables stored on the stack during each loop iteration.

[0128] In some embodiments, the condition of the copied code block may depend on the value of one or more variables determined during script execution and may therefore be updated in loop iterations. In this case, each iteration of the copied code block may include one or more opcode commands that test the relevant conditions, followed by an opcode sequence representing the copied code block embedded in an OP_IF / OP_ENDIF pair. In this configuration, during script execution, the opcode commands that test the relevant conditions will evaluate to TRUE or FALSE and place the TRUE or FALSE result on the top of the stack. Only when the TRUE result is at the top of the stack will the execution of the following OP_IF statement selectively execute the copied code block. Therefore, when the FALSE result is at the top of the stack, executing the OP_IF statement will bypass execution of the copied code block.

[0129] Additionally, the condition for copying a block of code may be limited by a maximum number of iterations, which may be defined by a parameter specified in a WHILE loop structure, a parameter fixed by system design, or some other parameter. In this case, the opcode command testing the condition and the subsequent opcode sequence representing the copied block of code embedded in the OP_IF / OP_ENDIF pairs may be copied a number of times corresponding to the maximum number of iterations defined by the above parameters.

[0130] Also note that an HLL program may use a nested WHILE loop structure, wherein an inner WHILE loop structure is contained within a code block of an outer WHILE loop structure. In this case, the compiler may perform loop unrolling on the inner WHILE loop structure in conjunction with loop unrolling of the outer WHILE loop structure. For example, loop unrolling of the inner WHILE loop structure may copy an opcode sequence representing the functionality of a code block of the inner WHILE loop structure between a pair of OP_IF / OP_ENDIF bytecode instructions, the number of copies being the number of iterations of the inner WHILE loop structure. In addition, loop unrolling of the outer WHILE loop structure may copy an opcode sequence representing the functionality of a code block of the outer WHILE loop structure between a pair of OP_IF / OP_ENDIF bytecode instructions, the number of copies being the number of iterations of the outer WHILE loop structure. In this case, the opcode sequence representing the functionality of a code block for each iteration of the outer WHILE loop structure includes an opcode sequence for the number of iterations of the inner WHILE loop structure.

[0131] Also note that the WHILE loop nesting can be expanded, wherein the code block of the inner (first inner) WHILE loop structure contains another inner WHILE loop structure, and has possible additional nesting. In this case, the loop unrolling operation described herein can be easily expanded to solve this further nesting.

[0132] HLL Structure: INITIATE

[0133] describe:

[0134] In an embodiment, this is the mandatory first statement of any HLL program.

[0135] The first part of the script execution provided by the transaction spender (i.e. the "script signature") is outside the control of the unlocking script. It usually consists of data that will be pushed onto the stack. The purpose of the INITIATE structure is to enable the programmer to manage this input (whether or not it is required by the rest of the script, which it most likely is).

[0136] This structure "assigns a value" to the reserved word NUM_INPUTS (which is the number of items pushed onto the stack from the input provided by the consumer). The first OP_CODE will always be OP_DEPTH so that the top of the stack (at this point) contains the number of data inputs that have been pushed onto the stack. This location in the stack will be fixed and known by the compiler at compile time, although the actual value will not be known at compile time.

[0137] grammar:

[0138] INITIATE

[0139] Compiler Actions:

[0140] Write OP_DEPTH / * This will set OP_DEPTH to the value of NUM_INPUTS HLL Structure: DECLARE

[0141] describe:

[0142] In an embodiment, this is a mandatory second structure of any HLL program.

[0143] All constants and variables are declared so that the compiler can reserve "memory storage space" (i.e. locations on the main and / or alt stacks). The standard is to keep constants on the main stack and variables on the alt stack. The compiler will associate the names given to variables and constants with their locations on the stack. The compiler will push the named items onto the main stack, which already contains the data inputs provided by the consumer (see INITIATE) and, at the top of it, a value representing the number of these data items (which is associated with the reserved word NUM_INPUTS).

[0144] grammar:

[0145]

[0146] Compiler Actions:

[0147] Write PUSHDATA commands to put the declared constant values ​​of the HLL program into the memory storage (e.g., the main stack). These commands can start at the top and push items one by one into the memory storage. The compiler can keep track of the location of each constant value in the memory storage (e.g., the main stack location).

[0148] Write the OP-TOALTSTACK command to put the variables of the HLL program into a memory storage (e.g., alt stack). Again, the compiler can keep track of the location of each variable in the memory storage (e.g., alt stack location).

[0149] Example:

[0150]

[0151]

[0152] After the compiler has finished executing these statements (and assuming that the mandatory INITIATE statement will fetch some values), the state of the memory storage (in this case, the main stack and the alt stack) will look like this:

[0153]

[0154] In this example, assume there are some input items provided to the unlocking script. At a minimum, there will be a value at the location marked "NUM_INPUTS" (which is a reserved word), even if that value is 0 and there are no values ​​in the stack below it. This value will be treated as the start of a memory block, regardless of how many items are below. The compiler knows the number of items in memory and their initial relative positions to the start of the top of the stack. These items will remain in position during program execution. Temporary calculations are done using the space on the top of the stack (shown as "(for temporary variables)") in the diagram. When items are temporarily pushed onto the top of the main stack for calculations, this changes the relative positions of the memory items. However, the compiler will always remain aware of the relative positions.

[0155] For example, after the DECLARE statement is executed, the compiler will calculate and internally maintain the value of Init-depth (In the example, Init-depth = 12) and the depth position in the stack for each item. That is:

[0156] Init-depth-Num_Hashes=5

[0157] Init-Depth-NUM_INPUTS=12

[0158] Init-Depth-Stock[i]=11–i+1

[0159] The compiler will be able to calculate the depth of any item at any time during compilation based on <initial depth of item> + <number of items added to the stack>.

[0160] HLL Structure: INCREMENT

[0161] describe:

[0162] The variable will be retrieved from its location in memory, incremented by 1, and then replaced at its location in memory.

[0163] grammar:

[0164] INCREMENT(Variable-name)

[0165] in:

[0166] Variable Name:

[0167] The name used in the declaration section to identify the variable.

[0168] Compiler Actions:

[0169] Note: The compiler keeps track of the different numbers of items on the two stacks (e.g. Main_Stack_Height and ALT_Stack_Height(). The compiler also knows the position of each variable and constant on each stack, which is established in the Declaration section, i.e. Var-Posn = the position of the variable name in the alt stack (i.e. the number of items up from the bottom of the stack).

[0170] This operation uses the Borrow Block technique.

[0171] Calculate Var-Depth = ALT_Stack_Height - Var-Posn + 1

[0172] Write OP_FROMALTSTACK Var-depth times / * put the required variable to the top of the main stack WriteOP_ADD1 / * add 1 to the value

[0173] Write OP_TOALTSTACK Var-depth (variable depth) times / * Replace all borrowed variables back to the alt stack

[0174] (See Example 2 in the borrow block description)

[0175] Example: Increment variable B

[0176]

[0177] The task is to increase the variable B. The compiler knows that the depth of B in the alt stack is: B-Depth (B depth) = 5. The compiler generates the following script code:

[0178] OP_FROMALTSTACK / * Move the top of the alt stack to the main stack 5 times (i.e. B_Depth times) OP_FROMALTSTACK

[0179] OP_FROMALTSTACK

[0180] OP_FROMALTSTACK

[0181] OP_FROMALTSTACK

[0182]

[0183] OP_ADD1 / * Add 1 to the top value of the main stack

[0184]

[0185] TO-ALTSTACK / * Return variables to the alt stack

[0186] TO-ALTSTACK / * That is, execute TO_ALTSTACK B-Depth times

[0187] TO-ALTSTACK

[0188] TO-ALTSTACK

[0189] TO-ALTSTACK

[0190]

[0191] HLL Structure: IF ELSE

[0192] describe:

[0193] Standard IF test

[0194] grammar:

[0195]

[0196] in:

[0197] Value1 hard-coded value or variable name or constant name

[0198] Value2 hard-coded value or variable name or constant name

[0199] Test operations Mathematical test operators such as "=", "<", ">", "≤", "≥", etc.

[0200] Compiler Actions:

[0201] Check syntax. This includes:

[0202] Match the test operation with the equivalent opcode (internal table):

[0203]

[0204]

[0205] Write:

[0206]

[0207] HLL structure: RESET

[0208] describe:

[0209] The variable is assigned the specified value.

[0210] grammar:

[0211] RESET(Variable-name,Reset-value)

[0212] in:

[0213] Variable-name The name of the variable to be assigned a new value

[0214] Reset-value assigns the value of Variable-name

[0215] Compiler Actions:

[0216] Note: The compiler keeps track of the different numbers of items on the two stacks (e.g. Main_Stack_Height and ALT_Stack_Height). The compiler also knows the location of each variable and constant in allocated memory (i.e. on each stack), which is established in the DECLARE section.

[0217] Assume Var-Posn = the position of the variable name in the alt stack (i.e. the number of items from the bottom of the stack upwards). This operation uses the borrowed block technique:

[0218] Calculate Var-Depth = <Current ALT_Stack_Height> - Var-Posn + 1

[0219] Write OP_FROMALTSTACK Var-depth times / * Make the required variables reach the top of the main stack

[0220] Write OP_DROP Reset-value / *Delete the previous value; replace it with the required value

[0221] Write OP_TOALTSTACK Var-depth times / * Replace all borrowed variables back to the alt stack

[0222] HLL Structure: ABORT

[0223] describe:

[0224] Mark transaction as void

[0225] grammar:

[0226] ABORT

[0227] Compiler Actions:

[0228] Write OP_0OP_VERIFY

[0229] HLL structure: POPULATE

[0230] describe:

[0231] The purpose of this structure is to populate programmer-declared constants with inputs from the spender of a transaction (such as provided by executing the unlocking script of the spending transaction).

[0232] Locking the script's inputs (i.e. the "script signature") pushes any data onto the main stack. This happens before the DECLARE structure, so the inputs are at the bottom of the stack. The number of stack items (NUM_INPUTS) is placed above them via the (mandatory) INITIATE statement. It is the programmer's responsibility to verify that the transaction rules are met (e.g. the correct number of inputs is provided). Syntax:

[0233] POPULATE(Stack-position,Constant-name)

[0234] in:

[0235] Stack-position:

[0236] Integer. The position counting down from the bottom of the memory block. Remember that the bottom of the memory block always contains the item NUM_INPUTS (the number of inputs), and below that is the input data that was pushed onto the stack before the locking script code was executed.

[0237] Constant-name:

[0238] The name of the constant to be filled in.

[0239] Compiler operation:

[0240] Calculate shift - count = the number of stack items to be temporarily moved from the main stack to the alt stack for safe keeping:

[0241] shift - count = the number of stack items above the target item (constant name)

[0242] Calculate Input - depth = <relative height of Constant - name> + stack - position Write:

[0243] OP_TOALTSTACK (duplicate this for the number of shift - counts)

[0244] OP_DROP / * Discard the current value of the constant name (may be set to 0)

[0245] <input-depth>OP_PICK / * Get the required value and place it in the constant name position

[0246] OP_FROMALTSTACK (Copy this with the transfer count)

[0247] HLL structure: RAWSCRIPT

[0248] describe:

[0249] An array of values ​​representing a valid block of script code. The compiler will first validate the array to ensure it is a valid block of script code (including OP_CODE, COP_CODE, and integers).

[0250] The intention is to allow the programmer to include low-level code directly into the compiler output. This is useful for any functionality that is easier to code directly into script code than using the currently available HLL constructs.

[0251] grammar:

[0252] RAWSCRIPT[Values]

[0253] in:

[0254] Values ​​OP_CODE, COP_CODE array (list) and its integer input

[0255] Compiler Actions:

[0256] The compiler first verifies that the set of values ​​together form a valid script. That is, the OP_CODEs are all part of the currently accepted enabled OP_CODEs, the COP-CODEs all exist in the COP_CODE dictionary, and all have the expected input values.

[0257] The compiler then simply writes the value out to the current location in the output script.

[0258] HLL Structure: CALCULATETEMP

[0259] describe:

[0260] A valid computation was performed, placing the result on the top of the main stack. "Valid" means that it is one of the functional structures currently available to the HLL. The programmer must write the program so that TEMP is available (i.e. still on the top of the stack) when it is referenced later. Note that TEMP can only be referenced once. (If it is needed more than once, it should be declared as a variable in DECLARE.)

[0261] grammar:

[0262] CALCULATE TEMP = expression

[0263] Compiler Actions:

[0264] Checks that expression is valid (is a member of the currently available function structure list).

[0265] Execute the expression, putting the result (TEMP) on the top of the stack.

[0266] Resolve the following reference to TEMP – determine if TEMP is indeed at the top of the stack at the time of the reference: if not, throw a compile error.

[0267] Example:

[0268] CALCULATE TEMP=HASH160 (123456789)

[0269] HLL structure: HASH160

[0270] describe:

[0271] It performs the same hashing arithmetic as OP_CODE: OP_HASH160

[0272] grammar:

[0273] HASH160(value1)

[0274] in:

[0275] value1 is any of the following:

[0276] Hard-coded integer

[0277] Declared constants

[0278] Declared variables

[0279] Compiler Actions:

[0280] If value1 is a hard-coded number, it is pushed to the top of the stack.

[0281] If value1 is a variable or constant, it is retrieved (pushed to the top of the stack)

[0282] Compiler writing:

[0283] OP_HASH160

[0284] HLL structure: RETRIEVE

[0285] describe:

[0286] The variable or constant will be retrieved from its location in memory and copied to the top of the main stack. The original value will remain unchanged at its current location in Memory.

[0287] grammar:

[0288] RETRIEVE(Item-name)

[0289] in:

[0290] Item-name declared variable or constant

[0291] Compiler Actions:

[0292] Note: The compiler keeps track of the different number of items in the two stacks (e.g. Main_Stack_Height and ALT_Stack_Height). The compiler also knows the position of each variable and constant in each stack, which is established in the Declaration section, i.e. Item-posn = the position of the item name in the stack (i.e., the number of items from the bottom of the stack up). This operation uses the borrowed block technique.

[0293] Calculate Item-Depth = Stack_Height - Item-posn + 1

[0294] If the desired item is in the alt stack (i.e. is a variable)

[0295] Write OP_FROMALTSTACK Item-depth times / * to get the desired variables to the top of the main stack

[0296] Write OP_DUP / * Copy the value onto the main stack for later use

[0297] Write the following Item-Depth times: / *Move the copied value to the bottom

[0298] <Item-Depth+1> / *Collection of borrowed variables

[0299] OP_ROLL

[0300] Write OP_TOALTSTACK Item-Depthtimes / * Replace all borrowed variables back to the alt stack

[0301] If the required item is on the main stack (i.e. is a constant)

[0302] Write <item-depth>OP_PICK / * Copy the desired constants to the top of the main stack

[0303] Example: Retrieve a copy of variable C

[0304] Assume the memory allocation looks like this:

[0305]

[0306] The task is to place a copy of the variable C on the top of the main stack. The compiler knows that the depth of C in the alt stack is: Item-Depth = 4. The compiler generates the following script code:

[0307] OP_FROMALTSTACK / * Move alt top to main stack 4 times (i.e. Item-Depth times)

[0308] OP_FROMALTSTACK

[0309] OP_FROMALTSTACK

[0310] OP_FROMALTSTACK

[0311]

[0312] OP_DUP / * Copy the value of C to the top of the stack

[0313]

[0314] <C_Depth+1> OP_ROLL / *OP_ROLL (expand) from depth 5 (i.e. C_Depth+1)

[0315] <C_Depth+1> OP_ROLL / *Execute 4 times (i.e. C_Depth times)

[0316] <C_Depth+1> OP_ROLL

[0317] <C_Depth+1> OP_ROLL

[0318]

[0319] TO-ALTSTACK / * Return borrowed variables to the alt stack

[0320] TO-ALTSTACK / * executes TO_ALTSTACK C_Depth times

[0321] TO-ALTSTACK

[0322] TO-ALTSTACK

[0323]

[0324] / * Required variable values ​​are kept on top of the main stack

[0325] Reserved words

[0326] Reserved word: NUM_INPUTS (number of inputs)

[0327] describe:

[0328] This is always the bottom constant of the storage block. That is, it is the "first" item in the block of allocated stack locations. Although it is a constant, it is not known at compile time. Therefore, the compiler cannot use it for any hard-coded script operations (for example, it cannot be used as a number to count how many OP_TOALTSTACK statements are generated in the compiled code). It is known at execution time, so the programmer or compiler can use it for tasks such as conditional testing in Loops and IF statements.

[0329] Reserved word: TEMP

[0330] describe:

[0331] This is a temporary, one-time variable that will remain on the top of the stack after the calculation. Its presence enables the programmer to reference it within the calculation. When TEMP is referenced later in the program, the compiler will check the syntax to ensure that TEMP is still at the top of the stack.

[0332] Reserved word: CONSTANTS

[0333] describe:

[0334] It is used with the DECLARE structure. It is followed by a list of constants which will be pushed to the main stack.

[0335] Reserved word: VARIABLES

[0336] describe:

[0337] It is used with the DECLARE construct. It is followed by a list of variables that will be pushed onto the alt stack.

[0338] For ease of illustration, we now provide a use case example involving a WHILE loop, a sample HLL program, and the script code that will be compiled from it. Note that the script code includes comments, which begin with / * or / / in the conventional way. These comments do not have to be part of the script code generated by the compiler, but are included below to illustrate the operation of the compiler in generating the exemplary script code.

[0339] While Loop Example – Transaction (Tx)

[0340] Consider a blockchain transaction (Tx) with an internal list of 10 hardcoded hash puzzles. In order to unlock the outputs of Tx, the spender needs to provide at least 3 correct hash solutions. The transaction locking script will accept up to 12 tries on the same input (i.e. in the "script signature"), and they can be in any order. The transaction will hash each input "try" and check if it matches one of the internally stored hashes.

[0341] For clarity, consider the traditional way of describing the unlocking script in the input section of a transaction:

[0342] <scriptsig> <scriptpubkey>

[0343] Part I <scriptsig>It is the data and / or OP_CODE contained in the consumption transaction to unlock the output of the previous transaction consumed. <scriptpubkey>Is the locking script used in the output of the previous transaction consumed.

[0344] These are called:

[0345] <Spender Input><locking script>

[0346] Assume that the consumption input is TRY1 TRY2 TRY3 TRY4 TRY5

[0347] That is, according to the rules specified above, the spender tries 5 different possible hashing schemes, of which only 3 need to be correct in order to unlock the transaction.<Spender Input><locking script> When<Spender Input> , which in this example is just pushing 5 data items onto the stack.

[0348] Locking script logic - pseudo code

[0349] Note: There will be nested WHILE loops

[0350] Standard first step: count the number of inputs and save as NUM_INPUTS

[0351] Declare variables and constants that will be used in the script and initialize them to known values:

[0352]

[0353] The internal array is filled with the input values ​​of the consumer (ie, in this example, Try[1]-Try[5] are assigned input values ​​TRY1, TRY2, TRY3, TRY4, and TRY5). The rest of the array remains at the value zero.

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

[0355]

[0356] Mark the transaction as valid

[0357] Formal HLL Procedure

[0358] The following code is written in HLL using the syntax according to the embodiments of the present disclosure. It is intended to illustrate the use of WHILE, but other HLL structures (written in uppercase letters) are also included out of necessity, some of which have been described in detail above, but those skilled in the art will readily understand these HLL structures because they are familiar structures used by traditional modern high-level languages.

[0359]

[0360]

[0361]

[0362]

[0363] Compiled scripts

[0364] / *INITIATE

[0365] OP_DEPTH / / Determine NUM_INPUTS (reserved word) and put it on the top of the stack

[0366] / *DECLARE CONSTANTS. Initialize constants and put them on the main stack. The compiler knows where the constants are; an array of 12 values ​​(these are the "try values" - will be filled with actual input values ​​later)

[0367] Actually an array: Try

[12]

[0368] OP_0OP_0OP_0OP_0OP_0OP_0OP_0OP_0OP_0

[0369] OP_3 / / Correct_Needed - The number of correct hash hits required to unlock the TX is hardcoded to 3

[0370] OP_10 / / Num_Hashes - The number of hashes in the array is hardcoded to 10

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

[10] .

[0372] 20HASH-SAVED1

[0373] 20HASH-SAVED2

[0374] 20HASH-SAVED3

[0375] 20HASH-SAVED4

[0376] 20HASH-SAVED5

[0377] 20HASH-SAVED6

[0378] 20HASH-SAVED7

[0379] 20HASH-SAVED8

[0380] 20HASH-SAVED9

[0381] 20HASH-SAVED10

[0382] / *DECLARE variables initialize the variable (index and boolean logic) and put it on the Alt stack. The compiler knows the location.

[0383] OP_0OP_TOALTSTACK / / Correct_Counter - number of correct hits (when getting a hash match)

[0384] OP_0OP_TOALTSTACK / / Try_counter - index of outer loop: counter of input values ​​to be tried

[0385] OP_0OP_TOALTSTACK / / Hash_counter - index into inner loop: counter of hashes to be tried

[0386] OP_0OP_TOALTSTACK / / Match_found - Boolean flag - set to True when a hash match is found

[0387] / *At this stage the Alt stack has been filled, and is used as memory storage for variables. The compiler will need to "track" the location of the variable - its "depth" on the alt stack. The main stack has been filled with constants. The compiler needs to keep track of that, too. The "first value" of the main stack memory block is taken to be the location of NUM_INPUTS (regardless of how many items are below).

[0388] / * At this stage, the compiler knows that the value of NUM_INPUTS is at depth 27 in the main stack. The following operation copies that value to the top of the stack. It then pushes the value "12" to the top of the stack and uses ">" for comparison. If NUM_INPUTS > 12 (which corresponds to the maximum of 12 "try"s allowed), abort. The operation can use OP_DROP because OP_VERIFY leaves the result at the top of the stack.

[0389] 27OP_PICK OP_12OP_GREATERTHAN OP_VERIFY OP_DROP

[0390] / * Fill the Try[] array. Note: The code block for filling the Try[] array has been moved to Figure 2 , to improve the clarity and readability of this application. Assume that the compiler writes the script code quickly. This script code block will read the input values provided by the consuming party of the Tx output and use them to fill the Try[] array. In one example, only 5 inputs (i.e., 5 "tries") are provided, so only the first 5 elements of Try[] are filled, and the other elements remain with the value 0.

[0391] / * Outer WHILE loop. The maximum possible number of iterations is 12 (e.g., according to predefined rules), so the compiler will unroll the outer WHILE loop by copying the following opcode sequence 12 times.

[0392] / * Borrow block for condition 1: "Is Try_counter < NUM_Inputs AND Correct_counter < Correct_Needed?" To test under condition 1, we need to extract the variables from the Alt stack; perform the test, and then put the variables back ("borrow block").

[0393] / * First, get a copy of Try_counter and put it on top of the stack.

[0394] OP_FROMALTSTACK

[0395] OP_FROMALTSTACK

[0396] OP_FROMALTSTACK

[0397] OP_DUP

[0398] OP_4OP_ROLL

[0399] OP_4OP_ROLL

[0400] OP_4OP_ROLL

[0401] OP_TOALTSTACK

[0402] OP_TOALTSTACK

[0403] OP_TOALTSTACK

[0404] / * Then, get a copy of NUM_Input and put it on top of the stack; the compiler knows that this constant is currently at depth 14 in the main stack.

[0405] OP_14OP_PICK

[0406] / * Now compare the two top stack items for part 1 of condition 1; this checks "Try-Counter < NUM_Inputs?" and leaves the result on top of the stack.

[0407] OP_LESSTHAN

[0408] / * Do part 2 of the condition 1 check ("Correct_counter < Correct_Needed?"). Leave the result on top of the stack.

[0409] / * First get a copy of Correct_counter and put it on top of the stack.

[0410] OP_FROMALTSTACK

[0411] OP_FROMALTSTACK

[0412] OP_FROMALTSTACK

[0413] OP_FROMALTSTACK

[0414] OP_DUP

[0415] OP_5OP_ROLL

[0416] OP_5OP_ROLL

[0417] OP_5OP_ROLL

[0418] OP_5OP_ROLL

[0419] OP_TOALTSTACK

[0420] OP_TOALTSTACK

[0421] OP_TOALTSTACK

[0422] OP_TOALTSTACK

[0423] OP_13OP_PICK / / Copy Correct_Needed to the top of the stack: the compiler knows the constant is currently at depth 13.

[0424] OP_LESSTHAN / / Compare the two top stack items for part 2 of condition 1; this checks "Correct_counter < Correct_needed?" and leaves the result on top of the stack.

[0425] OP_BOOLAND / / This completes the conditional 1 combined check: the results of both parts of the conditional 1 check are on the top of the stack. After this op, the final result of the conditional 1 test is on the top of the stack. It is popped by the following IF.

[0426] OP_IF

[0427] / * Borrow block used to increment the Try-Counter. The first step is to make it to the top of the main stack. The compiler knows its depth on the alt stack (depth = 3 in this case).

[0428] OP_FROMALTSTACK

[0429] OP_FROMALTSTACK

[0430] OP_FROMALTSTACK

[0431] OP_ADD1

[0432] OP_TOALTSTACK

[0433] OP_TOALTSTACK

[0434] OP_TOALTSTACK

[0435] / * Borrow block used to reset Hash_counter = 0. The compiler knows the location of this variable

[0436] OP_FROMALTSTACK

[0437] OP_FROMALTSTACK

[0438] OP_DROP OP_0

[0439] OP_TOALTSTACK

[0440] OP_TOALTSTACK

[0441] / * Borrow block to reset Match-Found = FALSE. The compiler knows the location of this variable.

[0442] OP_FROMALTSTACK

[0443] OP_DROP OP_FALSE

[0444] OP_TOALTSTACK

[0445] / * Copy the desired "Try" value to the top of the stack and hash it

[0446] <try-depth>OP_PICK

[0447] OP_HASH160 / / In the formal HLL, this is the value of TEMP and remains on top of the stack. Further operations push more values onto the main stack and pop more values from the main stack. The intention is that when the value of TEMP is needed next (for equality checking), it will be on top of the stack. The compiler can verify this at compile time because the compiler can keep track of what is on the stack based on the formal HLL code.

[0448] / * Inner WHILE loop

[0449] / * The inner WHILE loop is executed Num_Hashes iterations, which has a maximum value of 10 in the given example. Therefore, the compiler will unroll the inner WHILE loop by copying the following opcode sequence Num_Hashes iterations (less than or equal to 10 iterations) within each iteration of the outer WHILE loop.

[0450] / * Borrow block for condition 2: "Match_Found = FALSE AND Hash-Counter < NUM_Hashes?" For the test in condition 1, variables need to be extracted from the Alt stack; the test is performed, and then the variables are put back again ("borrow block").

[0451] / * First, get a copy of the variable Match_Found for part 1 of condition 2 and place it on top of the stack. The compiler knows the location of this variable.

[0452] OP_FROMALTSTACK

[0453] OP_DUP

[0454] OP_2OP_ROLL

[0455] OP_TOALTSTACK

[0456] / * Check if Match_Found = FALSE and put the result on top of the stack

[0457] OP_NOT

[0458] / * Now get copies of the variables Hash_countr and NUM_Hashes for part 2 of condition 2 (test if Hash_Counter < NUM_Hashes). The compiler knows the locations of the three variables

[0459] OP_FROMALTSTACK

[0460] OP_FROMALTSTACK

[0461] OP_DUP

[0462] OP_3OP_ROLL

[0463] OP_3OP_ROLL

[0464] OP_TOALSTACK

[0465] OP_TOALSTACK

[0466] OP_13OP_PICK

[0467] / * Check Hash_Counter <NUM_Hashes

[0468] OP_LESSTHAN

[0469] / *Complete condition 2 combined check: The results of both parts of condition 2 check are on the top of the stack. After this op, the final result is left on the top of the stack.

[0470] OP_BOOLAND

[0471] / * The result of the condition 2 test is at the top of the stack. It is popped by the following IF.

[0472]

[0473]

[0474] / * End of the inner WHILE loop.

[0475] / * Retrieve the opcode for NUM_INPUTS

[0476] / * Check for opcodes with NUM_INPUTS ≥ 1

[0477]

[0478] / *End the outer WHILE loop

[0479] A copy of the opcode sequence for the second iteration of the outer WHLE loop (including a copy of the opcode sequence for the inner WHILE loop for NUM_INPUTS number of iterations (up to 10))

[0480] A copy of the opcode sequence for the third iteration of the outer WHLE loop (including a copy of the opcode sequence for the inner WHILE loop for NUM_INPUTS number of iterations (up to 10))

[0481] A copy of the opcode sequence for the fourth iteration of the outer WHLE loop (including a copy of the opcode sequence for the inner WHILE loop for NUM_INPUTS number of iterations (up to 10))

[0482] A copy of the opcode sequence for the fifth iteration of the outer WHLE loop (including a copy of the opcode sequence for the inner WHILE loop for NUM_INPUTS number of iterations (up to 10))

[0483] A copy of the opcode sequence for the sixth iteration of the outer WHLE loop (including a copy of the opcode sequence for the inner WHILE loop for NUM_INPUTS number of iterations (up to 10))

[0484] A copy of the opcode sequence for the seventh iteration of the outer WHLE loop (including a copy of the opcode sequence for the inner WHILE loop for NUM_INPUTS number of iterations (up to 10))

[0485] A copy of the opcode sequence for the eighth iteration of the outer WHLE loop (including a copy of the opcode sequence for NUM_INPUTS number of iterations (up to 10) of the inner WHILE loop)

[0486] A copy of the opcode sequence for the ninth iteration of the outer WHLE loop (including a copy of the opcode sequence for NUM_INPUTS number of iterations (up to 10) of the inner WHILE loop)

[0487] A copy of the opcode sequence for the tenth iteration of the outer WHLE loop (including a copy of the opcode sequence for NUM_INPUTS number of iterations (up to 10) of the inner WHILE loop)

[0488] Copy of the opcode sequence for the eleventh iteration of the outer WHLE loop (including a copy of the opcode sequence for NUM_INPUTS number of iterations (up to 10) of the inner WHILE loop)

[0489] A copy of the opcode sequence for the twelfth iteration of the outer WHLE loop (including a copy of the opcode sequence for the inner WHILE loop for NUM_INPUTS number of iterations (up to 10))

[0490] / * At the completion of the outer WHILE loop of 12 iterations, the compiler checks whether it got the required number of hits (i.e., checks Correct_counter ≥ Correct_Needed)

[0491] OP_FROMALTSTACK / / Go to the top of the main stack to retrieve Correct_counter

[0492] OP_FROMALTSTACK

[0493] OP_FROMALTSTACK

[0494] OP_FROMALTSTACK / / Copy Correct_Needed to the top of the stack

[0495] OP_12OP_PICK

[0496] OP_GREATERTHAN

[0497] / / This final operation leaves the test result on the top of the stack. If TRUE (i.e. if Correct_counter ≥ Correct_Needed) and possibly other checks pass, the transaction is marked as valid.

[0498] In an embodiment, the blockchain compiler may be configured to optimize the output script at least once to provide a more efficient or simplified version of the output script. This may involve using derivative-free optimization (DFO). DFO is a term known in the art and well understood by those skilled in the art. Additionally or alternatively, the step of generating the output script may include using derivative-free optimization.

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

[0500] Figure 3 An example blockchain network 1000 associated with a blockchain according to an embodiment of the present disclosure is shown. In this embodiment, the example blockchain network 1000 includes peer-to-peer distributed electronic devices running an instance of a blockchain protocol. In some examples, the distributed electronic devices are referred to as nodes 1002.

[0501] Node 1002 may be implemented by any suitable computing device (e.g., by a server in a data center, by a client computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a smartphone, etc.), by multiple computing devices in a distributed system of a computing resource service provider, or by any suitable electronic client device such as Figure 5 The computing device 2600 is composed of.

[0502] In an embodiment, one or more nodes 1002 are communicatively coupled to one or more other nodes 1002. Such communicative coupling may employ one or more of well-known wired or wireless communication links. In this embodiment, each of the nodes 1002 maintains at least a portion of a "ledger" of all transactions in the blockchain. In this manner, the ledger is a distributed ledger. Blockchain transactions processed by a node affecting the ledger are verified by one or more other nodes, thereby maintaining the integrity of the ledger.

[0503] In an embodiment, at least some of the nodes 1002 perform a process involving complex computations (e.g., solving a cryptographic problem). The network node that solves the cryptographic problem creates a new block for the blockchain and broadcasts the new block to the other nodes in the nodes 1002. The other nodes in the nodes 1002 perform a verification process that verifies the work of the network node that solves the cryptographic problem, and after verification, accepts the block into the blockchain (e.g., by adding it to the distributed ledger of the blockchain). In some examples, a block is a group of transactions, typically marked with a timestamp and "fingerprint" (e.g., a hash) of the previous block. In this way, each block is linked to the previous block, creating a "chain" that links blocks in the blockchain. In an embodiment, valid blocks are added to the blockchain through the consensus of the nodes 1002. In addition, in some examples, the blockchain includes a list of verified blocks.

[0504] In an embodiment, at least some of the nodes 1002 function as validation nodes that perform a validation process to validate transactions as described in this disclosure. Figure 3 An exemplary transaction marked as 1004 is shown. In some examples, the transaction includes data that provides proof of digital asset ownership (e.g., a certain number of tokens) and conditions for accepting or transferring digital asset ownership / control. In some examples, a "spending transaction" refers to a transaction that reassociates (e.g., transfers ownership or control) at least a portion of the digital asset indicated by the unspent transaction output (UTXO) of a previous transaction to an entity associated with a blockchain address. In some examples, a "previous transaction" refers to a transaction that includes the UTXO referenced by the spending transaction. In some embodiments, a transaction may include an "unlocking script" and a "locking script". A locking script may be used to hinder a transaction with a condition that must be satisfied before the transaction is verified and ownership / control is transferred through the transaction. In some embodiments, a locking script may be associated with the output of a transaction and may be configured to define one or more conditions required to consume the output. In addition, the unlocking script of the spending transaction may be configured so that the execution of the unlocking script provides data that is used to derive a set of conditions that are evaluated by the execution of the locking script of the previous transaction for verifying the spending transaction. The locking script of the previous transaction and the unlocking script of the spending transaction are written in a low-level scripting language with limited functionality.

[0505] In some embodiments, verification of a spend transaction may include executing an unlocking script of the spend transaction together with executing a locking script of a previous transaction so as to satisfy and verify a set of conditions indicated by the locking script of the previous transaction. Verification of the spend transaction may involve other checks. Upon successful verification of the spend transaction, the spend transaction may be propagated to other network nodes. A network node may choose to embed a valid spend transaction as part of a block added to the blockchain as described herein.

[0506] like Figure 3 As shown, the blockchain compiler 1001 described herein is used to convert the HLL program into a blockchain compatible script (or script fragment). This can be referred to as an "output script" because it can form an output provided by the blockchain compiler 1001. The output script can be provided in a blockchain transaction (Tx). It can be part of a locking script associated with a transaction output, or part of an unlocking script associated with a transaction input. The output script can be formed by an opcode selected from a blockchain scripting language, inherent to the blockchain scripting language and / or forming a part of a blockchain scripting language, which can be executed by a node of a blockchain network. The opcode can be referred to as a primitive or command. The opcode of the script can be executed by an interpreter or virtual machine running on a node of the blockchain network 1000. The interpreter or virtual machine can convert the opcode of the script into a machine executable (object) code. The blockchain scripting language can be, for example, a Script language. The scripting language can include encryption, arithmetic, and stack manipulation opcodes.

[0507] The compiler 1001 may be part of an SDK, or may be an online service that uses static compilation to generate blockchain transaction scripts (or script fragments) that can be executed by a robot or a node of a blockchain network.

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

[0509] Figure 4 An exemplary blockchain protocol for validating and mining a spending transaction 204 (labeled “TX 2”) that consumes an output of a previous transaction 202 (labeled “TX1”) is shown. The previous transaction 202 has an output that includes a token amount (digital asset) and a locking script that is configured to define a set of conditions required to consume the token amount. The previous transaction 202 has been validated and mined so that it is embedded in a block, which is then validated so that it is stored on the blockchain 208. The spending transaction 204 includes an input having a transaction output identifier field (labeled “Tx Output ID”) and an unlocking script that refers to the output of the previous transaction 202. The locking script of the previous transaction 202 and the unlocking script of the spending transaction 204 are written using a low-level scripting language with limited functionality. For the spending transaction 204 to be considered valid, the unlocking script of the input must provide data that satisfies a set of conditions defined by the locking script of the previous transaction 202 that is referred to as the output. The locking script of the previous transaction 202 (or a portion thereof) and the unlocking script of the consumption transaction 204 may be generated by the blockchain compilation methods and tools described herein.

[0510] By executing the unlocking script of the consumption transaction 204 and executing the locking script of the previous transaction 202, one or more nodes ( Figure 4 ) to verify the consumption transaction 204, thereby satisfying and verifying a set of conditions specified by the locking script of the previous transaction 202. The verification of the consumption transaction 204 may involve other checks. After successfully verifying the consumption transaction 204, the consumption transaction may be propagated to other network nodes. The network nodes may perform a mining operation that selects and embeds valid consumption transactions as part of a block added to the blockchain 208, as described herein. Once verified and stored on the blockchain 208, the transaction sequence 202 and 204 provides for the transfer of control over the amount of tokens (digital assets) referenced by the transaction.

[0511] Figure 5 is an illustrative simplified block diagram of a computing device 2600 that can be used to practice at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 can be used to implement a blockchain compiler and a network node of a blockchain network as shown and described above. For example, the computing device 2600 can be configured to function as a data server, a network server, a portable computing device, a personal computer, or any electronic computing device. Figure 5 As shown, the computing device 2600 may include one or more processors 2602, which may be configured to communicate with a plurality of peripheral subsystems via a bus subsystem 2604 and be operably coupled to the peripheral subsystem. The processor 2602 may be used to compile the HLL source code program into a blockchain script (or fragment thereof) as described herein. These peripheral subsystems may include a storage subsystem 2606 (including a memory subsystem 2608 and a file / disk storage subsystem 2610), one or more user interface input devices 2612, one or more user interface output devices 2614, and a network interface subsystem 2616. The storage subsystem 2606 may be used for temporary or long-term storage of information, such as details associated with transactions described in the present disclosure.

[0512] The bus subsystem 2604 can provide a mechanism for enabling the various components and subsystems of the computing device 2600 to communicate with each other as expected. Although the bus subsystem 2604 is schematically shown as a single bus, alternative embodiments of the bus subsystem can utilize multiple buses. The network interface subsystem 2616 can provide an interface to other computing devices and networks. The network interface subsystem 2616 can be used as an interface to receive data from other systems and to send data from the computing device 2600 to other systems. For example, the network interface subsystem 2616 can enable a data technician to connect the device to a wireless network so that the data technician can send and receive data when in a remote location (e.g., a user data center). The bus subsystem 2604 can be used to transmit data such as details, search terms, etc. to the supervisory model of the present disclosure, and can be used to transmit the output of the supervisory model to one or more processors 2602 and to merchants and / or creditors via the network interface subsystem 2616.

[0513] 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, trackball, touchpad, or 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 all possible types of devices and mechanisms for inputting information to the computing device 2600. 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 be 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 all possible types of devices and mechanisms for outputting information from the computing device 2600. One or more user interface output devices 2614 may be used, for example, to present a user interface to facilitate user interaction with the application that performs the processing and changes therein—when such interaction is appropriate.

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

[0515] 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 which may store fixed instructions. The file / disk storage subsystem 2610 may provide non-transitory permanent (non-volatile) storage for program and data files and may include a hard disk drive, a floppy disk drive and associated removable media, a compact disk read-only memory (CD-ROM) drive, an optical drive, removable media cartridges, and other similar storage media.

[0516] The computing device 2600 may include at least one local clock 2624. The local clock 2624 may be a counter representing the number of ticks that have occurred since a specific start date, and may be integrally located within the computing device 2600. The local clock 2624 may be used to synchronize data transfers in the processor of the computing device 2600 and the processors of all subsystems included therein with specific clock pulses, and may be used to coordinate synchronization operations between the computing device 2600 and other systems in the data center. In one embodiment, the local clock 2624 is an atomic clock. In another embodiment, the local clock is a programmable interval timer.

[0517] The computing device 2600 may be of various types, including a portable computer device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 2600 may include another device that may be connected to the computing device 2600 via one or more ports (e.g., USB, a headphone jack, a lightning connector, etc.). The device that may be connected to the computing device 2600 may include a plurality of ports configured to accept fiber optic connectors. Thus, the device may be configured to convert optical signals into electrical signals that may be transmitted through the port connecting the device to the computing device 2600 for processing. Due to the ever-changing nature of computers and networks, there is a need for Figure 5 The description of the computing device 2600 depicted is only used as a specific example to illustrate a preferred embodiment of the device. Figure 5 Many other configurations with more or fewer components than shown.

[0518] It should be noted that the above embodiments illustrate rather than limit the present disclosure, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present disclosure. The methods, systems and devices (or parts thereof) of the present disclosure may be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be implemented by one and the same item of hardware. The fact that certain measures are recited in mutually different dependent claims does not mean that a combination of these measures cannot be used to advantage.

[0519] Therefore, the description and drawings should be considered as illustrative rather than restrictive. However, it is obvious that various modifications and changes can be made thereto within the scope of the invention. Likewise, other variations are also within the scope of the present disclosure. Therefore, the disclosed technology can have various modifications and alternative structures, but some of its illustrated embodiments are shown in the drawings and have been described in detail above. However, it should be understood that there is no intention to limit the invention to the specific form disclosed, on the contrary, the invention is intended to cover all modifications, alternative structures and equivalent forms that fall within the scope of the invention.

[0520] In the claims, any reference numerals in brackets shall not be interpreted as limiting the claims. In addition, the use of the terms "one" and "an" and "said" and "the", and similar references in the context of describing the disclosed embodiments (particularly in the context of the attached claims) shall be interpreted as covering singular and plural forms, unless otherwise stated or clearly contradicted by the context. Unless otherwise stated, the terms "include", "have", "include" and "include" shall be interpreted as open terms (i.e., meaning "including but not limited to"). The term "connected" shall be understood as partially or completely contained therein, attached to or combined together when there is no modification and refers to a physical connection, even if something intervenes. The range of values ​​mentioned in the present disclosure is only used as a shortcut to refer to each individual value falling within the range, unless otherwise stated, and each individual value is included in the specification as if it were mentioned separately. The term "set" (such as "a set of items") or "subset" shall be understood as a non-empty set including one or more members, unless otherwise stated or contradicted by the context. Furthermore, the term "subset" of a corresponding set does not necessarily denote a proper subset of the corresponding set, but rather: a subset and a corresponding set may be equivalent unless otherwise indicated or contradicted by context. The singular form of an element does not exclude the plural form of the element and vice versa.

[0521] Unless expressly stated otherwise or clearly contradicted by context, conjunction language such as phrases of the form "at least one of A, B, and C" or "at least one of A, B, and C" should be understood in the context of common usage to present that an item, term, etc. can be A, B, or C, or any non-empty subset of the sets of A and B and C. For example, in the illustrative example of a set with three members, the conjunction phrases "at least one of A, B, and C" and "at least one of A, B, and C" refer to any of the following sets: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Thus, such conjunction language is not generally intended to indicate that a particular implementation requires that at least one A, at least one B, and at least one C each be present.

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

[0523] The use of any and all examples or exemplary language (e.g., "such as") provided is intended only to better illustrate embodiments of the invention and does not constitute a limitation on the scope of the invention unless otherwise stated. No language in the specification should be construed as indicating any non-claimed element is essential to the practice of the invention.

[0524] Embodiments of the present disclosure are described, including the best mode known to the inventor for carrying out the present invention. By reading the foregoing description, variations of those embodiments will become apparent to those skilled in the art. The inventor expects that such variations will be appropriately adopted by a skilled person, and the inventor hopes that the embodiments of the present disclosure can be practiced in a manner different from that specifically described. Therefore, the scope of the present disclosure includes all modifications and equivalents of the subject matter recorded in the appended claims as permitted by applicable law. Moreover, unless otherwise noted or clearly contradictory to the context, any combination of the above-mentioned elements in all possible variations thereof is covered by the scope of the present disclosure.

[0525] All references cited, including publications, patent applications, and patents, are herein incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety. < / scriptpubkey> < / scriptsig> < / scriptpubkey> < / scriptsig>

Claims

1. A computer-implemented method comprising the following steps: receiving as input a portion of source code, wherein the portion of source code is written in a high level language (HLL) and specifies a functionality; and An output script is generated, wherein the output script includes a plurality of opcodes selected from a functionally restricted blockchain scripting language and / or inherent to the functionally restricted blockchain scripting language, so that the output script at least partially provides the functionality specified in the portion of source code when executed; wherein the functionally restricted blockchain scripting language has limited support for recursive programming structures.

2. The method according to claim 1, comprising the steps of: A compiler arranged to perform the steps of claim 1 is provided or used.

3. The method according to claim 1, wherein: The output script is generated by performing static compilation.

4. The method according to claim 1, wherein: The limited-functionality blockchain scripting language does not inherently support complex control flow structures, recursion, and jump-based loops.

5. A method according to any one of the preceding claims, wherein: The step of generating the output script comprises: At least one loop structure provided in the portion of source code is expanded, wherein the loop structure includes a code block, a condition, and a maximum number of iterations. The method according to claim 5 , wherein the loop structure is a WHILE loop.

7. The method according to claim 5, wherein: The unrolling of the loop construct comprises copying one or more opcode commands in the output script with a number of copies equal to the maximum number of iterations, the one or more opcode commands testing conditions followed by an opcode sequence representing the functionality of a code block embedded in an OP_IF / OP_ENDIF pair.

8. The method according to claim 7, wherein: The condition is an evaluable expression that resolves to TRUE or FALSE.

9. The method according to claim 7, further comprising: Executing the output script; wherein the limited-function blockchain scripting language is stack-based; and, during execution of the output script, one or more opcode commands that test the condition will evaluate to a TRUE or FALSE result and place the TRUE or FALSE result on the top of the stack; and wherein, when the TRUE result is at the top of the stack, execution of the OP_IF statement will selectively execute the copied code block, and when the FALSE result is at the top of the stack, execution of the OP_IF statement will bypass execution of the copied code block.

10. The method according to claim 5, wherein: The maximum number of iterations is defined by a parameter specified in the loop structure.

11. The method according to claim 1, further comprising the steps of: An interpreter or virtual machine is provided or used, the interpreter or virtual machine being arranged to convert the output script into a form capable of being executed on a blockchain platform.

12. The method according to claim 1, further comprising the steps of: The output script is optimized at least once to provide a more efficient or more streamlined version of the output script.

13. The method according to claim 1, wherein: The step of generating the output script comprises using derivative-free optimization.

14. The method of claim 1, wherein: The portion of source code is arranged to implement a smart contract.

15. The method of claim 1, wherein: The HLL includes at least one primitive or structure that can be directly converted into one or more primitives native to the limited-functionality blockchain scripting language.

16. The method of claim 1, wherein: The restricted functionality blockchain scripting language is stack-based, and the HLL includes one or more primitives arranged to perform operations on the stack used by the restricted functionality blockchain scripting language.

17. The method of claim 1, wherein: The HLL includes primitives arranged to push quantities of inputs of the source code onto a stack used by the limited functionality blockchain scripting language for memory allocation.

18. A computer-implemented system comprising one or more processors and a memory storing computer-executable instructions, the instructions, when executed, causing the one or more processors to: receiving as input a portion of source code, wherein the portion of source code is written in a high level language (HLL) and specifies a functionality; and Generate an output script, the output script comprising a plurality of opcodes selected from a functionally limited blockchain scripting language and / or inherent to a functionally limited blockchain scripting language, so that the output script at least partially provides the functionality specified in the portion of source code when executed; wherein, The functionally limited blockchain scripting language has limited support for recursive programming structures.

19. The system of claim 18, further comprising a compiler, wherein the compiler is configured to: receiving as input the portion of source code, the portion of source code being written in a high level language (HLL); and Generate the output script, wherein the output script includes a plurality of opcodes selected from and / or inherent to the limited-function blockchain scripting language, so that the script at least partially provides the functionality specified in the portion of source code when executed; wherein the limited-function blockchain scripting language has limited support for recursive programming structures.

20. The system of claim 18 or 19, further comprising a software development kit (SDK).

Images