Testing functionality of and generating on-chain programs

In recent years, bad actors have become increasingly skilled at generating on-chain programs that exhibit malicious behavior. These on-chain programs behave normally during their early phases of execution. However, at a certain point (e.g., based on a malicious actor's command or at a particular time), the on-chain program executes malicious code, thereby exhibiting malicious behavior and damaging user accounts. These on-chain programs are difficult to identify beforehand as the malicious behavior is usually hidden and user accounts are not affected until the malicious code is executed. Accordingly, there is a need for testing on-chain programs for malicious behavior and generating on-chain programs that are free of malicious code.

One mechanism for testing on-chain programs involves retrieving that on-chain program from a blockchain and deploying that on-chain program onto a test blockchain. The system may then use formal verification models or similar mechanisms to determine whether the on-chain program is malicious. In particular, a verification system may be used to perform formal model operations. The verification system may receive from a public blockchain node of a public blockchain an on-chain program designated for testing. For example, the verification system may monitor the public blockchain for new on-chain programs. In another example, an operator may trigger the retrieval of the on-chain program by requesting that a particular on-chain program be retrieved by the verification system.

The verification system may then cause the on-chain program to be deployed onto a test blockchain network. In particular, the verification system may transmit a command to a test blockchain node to install the on-chain program onto a test blockchain. For example, the verification system may have access to a test blockchain network via a test blockchain node. The blockchain node may accept commands from the verification system.

When the on-chain program is ready to be tested (e.g., deployed on a test blockchain network), the verification system may identify functions for testing the on-chain program (e.g., using a formal model). Thus, the verification system may retrieve a plurality of functions associated with a formal model generated for testing on-chain programs. For example, a formal model for testing a particular on-chain program may require a specific set of tests to ensure that the results of those tests match the expected results. The verification system may retrieve that formal model and the corresponding functions.

The verification system may then generate blockchain commands for each function to be executed on the test blockchain. In particular, the verification system may generate, based on each function of the multitude of functions, a plurality of blockchain operations for testing the on-chain program. For example, the verification system may iterate through each function and generate a corresponding blockchain operation that is enabled to be executed on the test blockchain via the blockchain node. In another example, the verification system may retrieve a list of required functions and determine, for each required function, corresponding blockchain code. The verification system may then modify the blockchain code for a particular instance of the test blockchain.

Once each blockchain operation is generated, the verification system may use a cryptography-based storage application to execute the blockchain operations (e.g., send each command to a blockchain node of the test blockchain for execution). In particular, the verification system may input each blockchain operation of the plurality of blockchain operations into a cryptography-based storage application. The cryptography-based storage application may be configured to execute blockchain operations against the test blockchain using a blockchain node that is part of the test blockchain. Thus, the verification system may instruct the cryptography-based storage application to execute the plurality of blockchain operations against the test blockchain.

When the verification system executes (e.g., via the cryptography-based storage application) the blockchain operations (e.g., using the test blockchain node), the verification system may receive the results of the blockchain operations. In particular, the verification system may receive, from the test blockchain node via the cryptography-based storage application, a plurality of results based on execution of the plurality of blockchain operations. For example, the blockchain operations may test how the on-chain program behaves when different operations are executed against the on-chain program. One such blockchain operation may involve determining how swapping different blockchain tokens via the on-chain program affects where and how the tokens are allocated.

The verification system may then compare results received from the tests with expected results. In particular, the verification system may compare each result of the plurality of results with each corresponding expected result associated with a corresponding function of the plurality of functions. For example, each blockchain operation (e.g., as stored within a formal model) may have a corresponding expected result. Each expected result may be compared with the actual result of the blockchain operation that is received from the test blockchain node.

Based on determining that one or more results of the plurality of results do not match a corresponding expected result associated with the corresponding function of the plurality of functions, the verification system may generate a notification indicating that the on-chain program has failed one or more tests. For example, if, after a particular blockchain token swap operation, the tokens are not transferred as expected, the verification system may indicate a test failure.

In some embodiments, the verification system may identify the tests that have failed and determine, based on the tests, corresponding malicious activities. The verification system may then add identifiers of those malicious activities to the notification.

This mechanism may also be used for generating on-chain programs or modifying on-chain programs that do not have the functionality required by a corresponding formal model. That is, this mechanism may be built into a generation system. In particular, the generation system may receive a request to generate on-chain program code for an on-chain program. The request may include an indication of a blockchain where the on-chain program is to be installed. For example, a developer may desire to create an on-chain program. However, the developer may want that on-chain program to be compliant with one or more systems. Thus, the developer may request to generate the on-chain program with all the functionality that is required to be compliant and then add other code into the on-chain program. Thus, the developer may request that an on-chain program be generated.

In some embodiments, the on-chain program may be modified instead of generated. For example, the developer may generate an on-chain program and add the functionality desired (e.g., by users). The developer may then request that the on-chain program be modified to include required program code so that the on-chain program is compliant with various systems. Thus, the developer may request and the generation system may receive the request to modify the on-chain program.

Based on the request, the generation system may determine which formal model is required for the on-chain program. In particular, the generation system may determine, based on the request, a formal model required for the on-chain program. The formal model may be one of a plurality of formal models. Furthermore, each formal model may include a corresponding function group. For example, different types of on-chain applications may be required to comply with a particular set of rules or systems. Each formal model may be generated for complying with a particular set or multiple sets of rules or systems. Thus, the generation system may identify the formal model that is required for the particular on-chain program being created.

The generation system may then retrieve a plurality of functions associated with the formal model. The plurality of functions may provide required functionality for the on-chain program. For example, a particular formal model may require four specific functions to be supported or executed in a particular way. Thus, the formal model may include those functions. One function may describe what happens when an individual tries to exchange one type of token for another type of token using the on-chain program.

The generation system may then determine, based on the function, the particular blockchain operations required to be supported by the on-chain program. In particular, the generation system may determine, based on the plurality of functions, a plurality of blockchain operations to be added to the on-chain program. Each blockchain operation may correspond to a function of the plurality of functions. For example, the generation system may iterate through each function and determine a corresponding blockchain operation.

The generation system may then determine parameters for the blockchain operations. In particular, the generation system may determine, based on the indication of the blockchain, a plurality of blockchain parameters for the plurality of blockchain operations. For example, the parameters may include a type of tokens that the on-chain program may swap, the type of blockchain that is supported, etc. The generation system may then generate, based on the plurality of blockchain operations and the plurality of blockchain parameters, the on-chain program code for the on-chain program. For example, the generation system may create the code from the blockchain operations and add the parameters required. Once the parameters are added, the generation system may add the corresponding code to the on-chain program.

Various other aspects, features, and advantages of the system will be apparent through the detailed description and the drawings attached hereto. It is also to be understood that both the foregoing general description and the following detailed description are examples and not restrictive of the scope of the disclosure. As used in the specification and in the claims, the singular forms of “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise. In addition, as used in the specification and the claims, the term “or” means “and/or” unless the context clearly dictates otherwise. Additionally, as used in the specification, “a portion” refers to a part of, or the entirety of (i.e., the entire portion), a given item (e.g., data) unless the context clearly dictates otherwise.

In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the disclosed embodiments. It will be appreciated, however, by those having skill in the art, that the embodiments may be practiced without these specific details or with an equivalent arrangement. In other cases, well-known models and devices are shown in block diagram form in order to avoid unnecessarily obscuring the disclosed embodiments. It should also be noted that the methods and systems disclosed herein are also suitable for applications unrelated to source code programming.

Attempting to create a system to test and generate on-chain programs to ensure security and safety in view of the available conventional approaches created significant technological uncertainty. Creating such systems required addressing several unknowns in conventional approaches in testing and generating such programs.

One such issue is resource expenditure. In particular, conventional on-chain programs, such as blockchain programs and smart contracts, cannot be modified once deployed. This makes it difficult to provide for an iterative process in debugging without significant computational expense. Furthermore, testing on a main blockchain can incur heavy gas fees, making testing a computationally- and resource-expensive process. Because tens of thousands of smart contracts are being deployed daily, many small bugs can fly under the radar.

Another such issue is the testing of programs against dynamic, ever-changing legal or entity-specific standards. For example, existing systems test on-chain programs for technical issues and never consider legal standards, e.g., such as those set forth by Uniform Commercial Code Article 12 (UCC-12), which dictates legal transactions amongst digital assets. However, even when on-chain programs compile and run without errors, the programs may still be malicious and violate several legal standards that cannot be tested using conventional techniques.

Conversely, the disclosed system provides a system that enables the testing of on-chain programs using standards and models set by various entities, e.g., such as the UCC standards. The new system may identify a formal model that tests for adherence to standards set by a government agency, a company, or other entity and generates blockchain operations to test that the on-chain program adheres to the model. Since regulations and guidelines from the government and different companies may be dynamic over time, the system enables testing and code generation to be based off of a model, which may be subject to change over time. By referencing a model as opposed to hard-programming specific functions, the system may be enabled to leverage and match up preexisting functions to perform new functionality rather than expending time and computational resources in developing and generating new functions.

In particular, to overcome the technological uncertainties, the inventors systematically evaluated multiple design alternatives. For example, the inventors use modular functions and blockchain operations that can be used in common with different models, e.g., different models may use the same blockchain operations and functions. By doing so, space can be saved by simply identifying the operations and functions by identifier so no duplicates exist.

However, this introduced more uncertainties, as using the same functions and syntax over different on-chain programs does not always work given context-specific variables and parameters. In order to solve this, the inventors made the blockchain operations and on-chain code parameterized so that the same blockchain operations can be used over different models and programs but memory space can be saved by avoiding storing different variations of the same operation. In this way, specific parameters can be used and input so as to make the blockchain operations operable and executable within the specific context of the on-chain program. By doing so, not only did the inventors enable testing and generation of code that is automatic and time-effective, but they also enabled a less resource-intensive system through modular architecture.

As mentioned herein, the modular architecture is also enabled for dynamic models, as new models may use existing functions and operations from a superset of functions and operations rather than developing new functions and operations over time. Thus, the system is enabled to leverage and match up preexisting functions to perform new functionality rather than expending time and computational resources in developing and generating new functions.

The system allows for generation of code, which created further technological uncertainty for the inventors since legacy approaches only enable users to identify problems and debug the programs themselves. However, in order to ensure that programs can deploy quickly so that services won't be interrupted and in order to conserve computational resources, systems herein are enabled to generate necessary code and insert/modify on-chain programs to adhere to regulations and guidelines set by different entities. Legacy systems do not enable generation of on-chain code, and so the inventors considered many technical uncertainties, such as how to quickly test and deploy on-chain programs, modular architectures for functions and models that are memory-space efficient, and testing and generating code that is secure and deployable.

Thus, the inventors experimented with different methods for testing and generating on-chain program code. For example, the inventors tried different architectures for storing blockchain operations, functions, and models to identify the most efficient and effective approaches.

As described herein, in order to protect against on-chain programs from executing malicious code, on-chain programs may be tested and validated to ensure safety to users who may use such on-chain programs to perform various actions with their accounts. EnvironmentA ofshows an illustrative system for testing on-chain program code. EnvironmentA includes on-chain program verification system, data nodeA, data nodeB, device, and repository.

On-chain program verification systemof environmentA may execute instructions for testing on-chain programs and may additionally communicate results of testing an on-chain program to an operator or operator device. On-chain program verification systemmay include several subsystems, each configured to perform one or more steps of the methods described herein, such as communication subsystem, on-chain program installation subsystem, blockchain operation generation subsystem, blockchain operation input subsystem, and results analysis subsystem.

On-chain program verification systemmay include software, hardware, or a combination of the two. For example, on-chain program verification systemmay be hosted on a physical server or a virtual server that is running on a physical computer system. In some embodiments, on-chain program verification systemmay be configured on a user device (e.g., a laptop computer, a smartphone, a desktop computer, an electronic tablet, or another suitable user device).

On-chain program verification systemmay be in communication (e.g., via network) with a data nodeA, through which the system may access a public blockchain. For example, data nodeA may be a public blockchain node of a public blockchain. Data nodeA may store various data, including user data, copies of on-chain programs, and/or other suitable data. Data nodeA may include software, hardware, or a combination of the two. For example, data nodeA may be a physical server or a virtual server that is running on a physical computer system. In some embodiments, the verification system and data nodeA may reside on the same hardware and/or the same virtual server/computing device. Networkmay be a local area network, a wide area network (e.g., the Internet), or a combination of the two.

Devices such as devicemay be associated with a cryptography-based storage application used at the data nodes. A cryptography-based storage application may also include software, hardware, or a combination of the two. For example, each cryptography-based storage application may include software executed on one or multiple devices or may include hardware, such as a physical device. In some cases, the cryptography-based storage application may be software and may be stored in user devices (e.g., client devices such as smartphones, laptops, electronic tablets, etc.), and a user of the cryptography-based storage application may access the cryptography-based storage application on those devices. Alternatively, or additionally, the cryptography-based storage application may reside on a special device (e.g., a fob) intended for storing the cryptography-based storage application. For example, the device may store private keys in a memory of the device and allow transactions to be signed (e.g., via generating a cryptographic signature) on the device itself. Examples of cryptography-based storage applications may include cryptographic wallets. For example, a cryptography-based storage application may be referred to as a digital wallet (e.g., hot wallet, cold wallet, etc.). As described herein, some examples of hardware cryptographic wallets include Ledger® and Trezor®. Software cryptographic wallets may include Metamask® and others.

Communication subsystemof on-chain program verification systemmay be used to receive an on-chain program designated for testing, such as from a public blockchain accessed through data nodeA via network. Communication subsystemmay include software components, hardware components, or a combination of both. For example, communication subsystemmay include a network card (e.g., a wireless network card and/or a wired network card) that is associated with software to drive the card. Communication subsystemmay pass at least a portion of the data, or a pointer to the data in memory, to other subsystems such as on-chain program installation subsystem, blockchain operation generation subsystem, blockchain operation input subsystem, and results analysis subsystem.

In some examples, prior to deploying an on-chain program, entities such as operators may request that an on-chain program be tested, e.g., to ensure that the program is in accordance with guidelines or laws. In this case, communication subsystemmay receive the on-chain program as part of a request. Alternatively, or additionally, on-chain program verification systemmay monitor a blockchain for new on-chain programs and retrieve the programs from the blockchain via communication subsystemfor testing.

As described herein, an on-chain program or on-chain program code may refer to a computer program or any suitable code for performing computing operations stored on a blockchain. For example, an on-chain program may reference a program stored on a blockchain or other distributed ledger. In particular, an on-chain program may be used to automate the execution of a transaction, such as a blockchain operation. In some examples, an on-chain program may refer to a smart contract executed on a blockchain. In one example, an on-chain program may run when predetermined conditions are satisfied.

For example,illustrates an exemplary on-chain programdesignated for testing, in accordance with one or more embodiments of this disclosure. For example, the on-chain programincludes a smart contract for minting “contract_mint” that sends an amount of newly created coins to an address and can only be called by the contract creator. The communication subsystemmay pass the on-chain program, or a pointer to the program in memory, to on-chain program installation subsystem.

The on-chain program installation module may install the on-chain program onto a test blockchain. As referred to herein, a test blockchain may be a blockchain environment that replicates a main blockchain. In some instances, the test blockchain may be used exclusively for testing and development purposes. Test blockchains may include testnets such as Ethereum Testnets, Binance Smart Chain Testnets, etc. By using test blockchains, the system can avoid incurring financial losses and also may reduce gas costs and optimize performance.

In some examples, on-chain program verification systemmay be in communication (e.g., via network) with a data nodeB, through which the system may access a test blockchain. For example, data nodeB may be a test blockchain node of a test blockchain. Data nodeB may store various data, including user data, copies of on-chain programs, and/or other suitable data. Data nodeB may include software, hardware, or a combination of the two. For example, data nodeB may be a physical server or a virtual server that is running on a physical computer system. In some embodiments, the verification system and data nodeB may reside on the same hardware and/or the same virtual server/computing device.

As described herein, the on-chain program installation subsystemmay be configured to install an on-chain program, including by transmitting a command to a test blockchain node, such as via data nodeB, to install the on-chain program designated for testing onto a test blockchain. In some examples, installing the on-chain program may include selecting a test blockchain from a plurality of test blockchains for which testing the on-chain program is suitable. For example, the system may consider the type of program, the type of digital asset involved in the program, the syntax of the program, and/or keywords from the program to determine which test blockchain to use. In some examples, the program itself may indicate the test blockchain to use. In some embodiments, the system may obtain test tokens for testing purposes. In some embodiments, the system may further compile the program.

In order to test the program, on-chain program verification systemmay determine suitable tests to execute and retrieve results from. For example, the on-chain program verification systemmay retrieve functions, such as those associated with a model generated for testing on-chain programs. The system may then generate, based on each function, blockchain operations for testing the on-chain program. The blockchain operation input subsystemmay later execute those blockchain operations to test the on-chain program.

As described herein, an operator or entity may seek to test or otherwise validate the on-chain program, such as to identify suspicious snippets of code that, when executed, may cause damage to one or more users. One way of doing so may include checking that the program functions correctly or as expected according to a specific guideline or model. According to some examples, the model may be set by operators, such as testers. In other examples, the model may be in accordance with legal requirements, such as UCC-12.

The model may be a formal model, wherein a formal model may include a set of components and relationships used to characterize a structure for at least one on-chain program. In particular, the formal model may be a logical representation of how a system would perform, such as a system in compliance with a guideline (e.g., UCC-12). A formal model may be defined with components, rules, symbols, and/or structures that provide a rigorous framework for analyzing, verifying, and reasoning about system behavior.is an exemplary formal modelthat can be used in generating or testing on-chain program code, in accordance with one or more embodiments of this disclosure. In the case where the on-chain program is submitted as part of a request to test the program, the request may indicate which model(s) to test against using identifiers. The system can identify the model(s) from a repository of models, whether remote or local, to test against and retrieve them.

In the example of, the formal modelis a plaintext file with definitions, relationships, and operations. Although formal modelis represented in plaintext in set notation and logical representation, a formal model may also be stored as programmatic code, compiled code, or data structures stored in one or more files. The formal modelcorresponds to Uniform Commercial Code (UCC) Article 12, or UCC-12, which is a section of the UCC that governs the transfer of Controllable Electronic Records (CERs), where CERs include digital assets that can be owned and controlled (e.g., Bitcoin and NFTs); however, it can be appreciated that a model may adhere to any guideline, including governmental (e.g., public) or entity-specific (e.g., private). The formal model may include definitions, which include definitions for entities such as “Entities {U: users; A: asset; C: contract owner; Tx: transaction}.” The formal model may also specify relationships, which indicate what suitable or correct relationships look like when the on-chain program is performing in accordance with a guideline (e.g., UCC-12). For example, when an on-chain program exhibits activity that indicates that one or more of the relationships is not satisfied or violated, the on-chain program being tested can be said to not be in accordance with the formal model.

In the example of, the relationships include “O(a)∈U,” indicating that an owner “O” of an asset “a” is an element of the group “U” of users and “Control(a)∈U,” indicating that control of the asset “a” belongs to a user in the group “U.” The formal modelmay also include operations such as operations. Operationsdepict an operation “Valid Tx {Tx(a, U, U):(O(a)=U)∧(Control(a)=U))⇒(O(a)=U)∧(Control(a)=U))}” illustrating that a valid transaction in accordance with the formal model would logically follow the specified definition. The operation indicates that a valid transaction “tx” of an asset “a” from a user Uto a user Uis defined as being possible if “U” is the owner of asset “a” (e.g., “O(a)”) and also has control of the asset “a” (e.g., “Control(a)=U) and the new owner would be “U” and control would also be given to “U” (e.g., “(O(a)=U)∧(Control(a)=U)”). In the example of formal model, the operations and relationships may be positive and identify correct operations or relationships. However, the formal model may also include negative operations or relationships, which identify what types of operations or relations are not allowed or not in accordance with the formal model. One example may include, for example, the following: “Invalid Tx {Tx(a, U, U):(¬O(a)=U)∧(Control(a)=U))⇒(O(a)=U)∧(Control(a)=U))}.” That is, where a first user does not have ownership of the asset, the transfer of the asset to a second user from a first user is invalid and therefore not in compliance with the guidelines.

According to some examples, the formal modelcan be generated by scraping text, e.g., from a website, images, or other media (e.g., using OCR or ASR). In particular, the formal modelmay periodically review legal websites and scrape text and convert the text, e.g., to set notation for the formal model, programmatic code, and/or the like, such as using machine learning. Since guidelines may be updated periodically, the system may be configured to periodically scrape text from known URLs or links and input the text into a machine learning model configured to generate the formal model in a suitable format (e.g., set notation, logical representation, code, etc.). Alternatively, or additionally, the formal model may be input or otherwise edited (e.g., via a user or operator device) via one or more input techniques (e.g., keyboard, touch screen, gesture recognition, voice commands, etc.).

As described herein, in order to generate blockchain operations for testing the on-chain program, blockchain operation generation subsystemmay retrieve a plurality of functions associated with a formal model generated for testing on-chain programs. In some examples, the functions may be operations or relationships within the formal model, such as formal model. For example, the functions may provide required functionality for the on-chain program. In the example of formal model, the operation for a valid transaction “valid_tx” may be a function.

Alternatively, or additionally, the functions may not be the operations or relationships themselves, but they may instead be associated with the operations or relationships within the formal models and used to test the on-chain program. For example, in order to test the operation “valid_tx” to ensure all transactions possible when executing the on-chain program follow the valid_tx framework, functions to test invalid operations and valid operations can be used. In one example, the functions can include functions such as trying to execute a transaction when a user owns an asset but lacks control over the asset, trying to execute a transaction when a user has control over the asset but no ownership, trying to execute a transaction without transferring ownership, trying to execute a transaction without transferring control, trying to execute a transaction correctly, e.g., by transferring control and ownership, or the like. Similarly, the functions may be used to test the relationships, such as attempting to create ownership for a non-user (e.g., to test “O(a)∈U”).

According to some examples, the system may generate functions based on the operations or relationships defined in the formal model. Alternatively, or additionally, the functions can be retrieved, such as from internal or external memory or a repository. For example, the system may generate commands or search queries to obtain the functions from memory or from a repository (e.g., such as repository) to be obtained via communication subsystem.

Alternatively, or additionally, the formal model may be generated based on required functions. In some examples, the on-chain program verification systemmay retrieve a list of required functions for testing one or more on-chain programs. The list may include the functions themselves (e.g., function definitions or compiled versions of the functions) or may include identifiers for the functions. In one example, the system may retrieve the list by receiving an indication of a function group that includes requirements for the on-chain program and determining, based on the function group, the list of required functions. For example, the system may determine that the on-chain program is used to transfer specific types of assets and, based on that indication, may obtain functions specific to testing the asset type. Based on the list of required functions, the system may retrieve corresponding blockchain code associated with the required functions and generate, using each corresponding blockchain code, a formal model for testing the on-chain programs.

illustrates exemplary functions for testing an on-chain program, in accordance with one or more embodiments of this disclosure. For example, data structureincludes functions for testing invalid transactions with users who have no ownership “¬O(a)=U)∧(Control(a)=U))⇒(failure)” and with users who have no control “O(a)=U)∧(¬Control(a)=U))⇒(failure)” attempting to make a transaction. The expected result in each case should yield no change in the blockchain state since the transaction should not go through if the on-chain program is in accordance with the formal model.