A security system

The security system optimizes smart contract processing and detects vulnerabilities using a graph database to enhance data integrity and security, addressing the high vulnerability of smart contracts in blockchains.

WO2025172831A1PCT designated stage Publication Date: 2025-08-21ONEGUARD LLC
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
PCT/IB2025/051410
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Filing Date
2025-02-11
Publication Date
2025-08-21

AI Technical Summary

Technical Problem

Smart contracts in blockchains are vulnerable to cyberattacks, leading to significant financial losses due to compromised security and management issues, with 90% being susceptible, resulting in annual losses of $6.9 billion and 3.8 million records compromised.

Method used

A security system utilizing a graph database generates data by optimizing smart contract source code through error detection and correction, compiler version selection, and additional data extraction, creating high-selectivity and high-frequency indexes, and providing a framework for querying to enhance data integrity and vulnerability detection.

Benefits of technology

The system improves data integrity and security by optimizing smart contract processing, detecting vulnerabilities efficiently, and providing real-time alerts and analytics, reducing the risk of cyberattacks and enhancing transactional security.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure IB2025051410_21082025_PF_FP_ABST
    Figure IB2025051410_21082025_PF_FP_ABST
Patent Text Reader

Abstract

The present invention relates to a method for a security system comprising a graph database, the method comprising generating a graph database data for a smart contract The method comprises obtaining the smart contract; determining an error in a source code of the smart contract; and in response to determining the error, fixing the source code and / or metadata of the smart contract to produce the source code that can be compiled.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] A SECURITY SYSTEM

[0002] TECHNICAL FIELD

[0003] The present invention relates to a method for a security system, a security system and a query engine and particularly, but not exclusively, to generating a graph database data and querying for security analysis.

[0004] BACKGROUND

[0005] Recently the use of smart contracts in blockchains has been rising. A smart contract is a computer program or a transaction protocol that is intended to automatically execute, control or document events and actions according to the terms of a contract or an agreement. A diverse range of entities and individuals uses the smart contracts facilitated by a blockchain for various purposes. For example, a supply chain management can be carried out by automating tracking, payment and verification processes across the supply chain using the smart contracts. Another example may be a financial institute which uses smart contracts to provide their financial services. With popularity of such contracts, the security and management of the digitalised contracts and data across distributed system have become important. Due to the nature of distributed system, and the limitation of Web 3.0 the security of the smart contracts can be easily compromised. According to the FBI Internet Crime Report (2022), 90% of global smart contracts are vulnerable, leading to annual losses of $6.9 billion from cyberattacks and exploiting 3.8 million records including identity and data theft. It is an aim of the present invention to address disadvantages associated with the prior art.

[0006] SUMMARY OF INVENTION

[0007] Embodiments of the invention may be understood with reference to the appended claims.

[0008] According to an aspect of the present invention, there is provided a method for a security system comprising a graph database. The method comprises generating a graph database data for a smart contract by obtaining the smart contract, determining an error in a source code of the smart contract, and in response to determining the error, fixing the source code and / or metadata of the smart contract to produce the source code that can be compiled. Due to unnecessary comments or piece of code being in the source code the source code may not be processed correctly. By identifying and fixing the source code the source code of the smart contract is optimised for better processing and reducing the chance for incurring further errors.

[0009] In at least one embodiment, determining a first compiler version from a source code of the smart contract. In response to determining the first compiler version, compiling the smart contract based on the first compiler version and extracting an artifact file for the graph database. By checking for the most suitable compiler to compile the source code, the process can progress more effectively without an error in the query engine. The graph database data is based on the data extracted from the artifact file. This ensures data integrity of the graph database and enhances the quality of service provided by the security system.

[0010] In at least one embodiment, in response to determining that the compiler version not available, determining compiler options based on the source code of the smart contract, and in response to the determined compiler options, selecting a first compiler version and compiling the smart contract based on the first compiler version. The engine ensures that there is a mechanism to determine the most suitable compiler for compilation of the source code of the smart contract. This ensures the integrity of the generated data and provides consistency in the generation of the graph database data. Smart contracts written in various programming languages are supported. The security system is adaptable and versatile, resulting in increase of security of the protocol being used for the smart contract and / or blockchain.

[0011] In at least one embodiment, in response to the compiling of the smart contract based on the first compiler version generating a compiler error, parsing a compiler error of a first execution of the first compiler and selecting a second compiler version. The security system learns from errors caused by lack of information so that the generation of the graph database data is performed and in the most constructive way.

[0012] In at least one embodiment, determining remapping information of data from the source code of the smart contract to a graph database data index. In response to determining that the remapping not available, recreating a folder structure of the smart contract. The security system ensures the data integrity of the graph database and the provision of an effective mechanism for extracting and maintaining relevant information for querying and analysis.

[0013] In at least one embodiment, extracting an intermediate representation from the source code of the smart contract and analysing the intermediate representation to generate additional data for the graph database. In at least one embodiment, extracting semantic data from the source code of the smart contract. The engine provides a mechanism to obtain further information from the source code in a simple and effective manner. Not just relying on default values such as Abstract Syntax Tree (AST) information and metadata of the smart contract, additional data for plenishing the graph database is proactively generated for querying so that the data integrity and transactional integrity of the smart contracts can be maintained and / or improved and verified if queried.

[0014] In at least one embodiment, creating a collection for each entity in the source code of the smart contract; and creating edge collections between entities. In at least one embodiment, creating a high-selectivity index for the graph database. The high- selectivity index may comprise an array index for array type field on the entities. Alternatively, or additionally, creating a high-frequency index. The high-frequency index may comprise an array index for arran type field on the entities. The created collections and / or the indexes for the graph database ensure efficient organisation of the graph database and optimisation of the query engine. A query is quickly performed on a well organised data, optimised index values and index pointers. The vulnerability of the smart contract can be quickly detected and analysed.

[0015] In at least one embodiment, providing a framework for querying the database; receiving a query; processing the query via the framework and in response to processing the query performing an action. The framework may be localised. The framework for searching the graph database is provided such that the data related to a query can be quickly and efficiently accessed and analysed. The data may be manipulated via the framework. The flexibility of the security system increases the usability of the security system and also aids in training the security system to learn, via machine learning, as it produces a safe environment to analyse and save results to the graph database, via the framework. The framework is configured to support different programming languages when querying.

[0016] Performing an action may comprise one or more of: providing a tool and an environment for analysis of the data queried within the framework; producing an error message; submitting the query to a state database for state data and / or storage data of the smart contract; generating a second query based on the received query and submitting the second query to a state database for state data and / or storage data of the smart contract; performing taint / data flow analysis suggesting changes in the smart contract’s source code; resolving the vulnerability within the smart contract; activating tracking mechanism; producing a report; providing a vulnerability alert; and / or providing detailed analytics for rapid response and resolution. Various options are provided by the security system to address security risks. All these actions are provided to remedy the vulnerability identified during the query and generation of the graph database data.

[0017] In at least one embodiment, generating a query based on the entities identified in the source code of the smart contract; and optimising the query based on an order of the entities being queried, by filtering the query and / or a subquery and changing the order of the filtered query and subqueries. This improves the performance of the system along with modifying the query and the subquery. The query engine is constantly improving its operation and data integrity within the graph database such that vulnerability of the smart contract when queried can be detected in a more effective and optimised manner. These actions all lead to enhancement of data, identity and privacy protection and fortification of transactional security.

[0018] According to another aspect of the present invention, there is provided a query engine configured to generate a graph database data for a smart contract. The query engine is configured to obtain the smart contract, determining an error in a source code of the smart contract and in response to determining the error, fix the source code and / or metadata of the smart contract to produce the source code that can be compiled.

[0019] In a least one embodiment, the query engine is configured to determine a first compiler version from a source code of the smart contract and in response to determining the first compiler version, compile the smart contract based on the first compiler version and extracting an artifact file for the graph database.

[0020] In a least one embodiment, the query engine is configured to, in response to determining that the compiler version is not available, determine compiler options based on the source code of the smart contract and metadata of the smart contract. In response to the determined compiler options, the query engine is configured to select a first compiler version and compiling the smart contract based on the first compiler version.

[0021] In a least one embodiment, the query engine is configured to, in response to the compiling of the smart contract based on the first compiler version generating a compiler error, parse the compiler error of a first execution of the first compiler and selecting a second compiler version.

[0022] In a least one embodiment, the query engine is configured to determine remapping information of data from the source code of the smart contract to a graph database data index; and in response to determining that the remapping not available, recreate a folder structure of the smart contract.

[0023] In a least one embodiment, the query engine is configured to extract an intermediate representation from the source code of the smart contract; and analyse the intermediate representation to generate additional data for the graph database.

[0024] In a least one embodiment, the query engine is configured to extract semantic data from the source code of the smart contract.

[0025] In a least one embodiment, the query engine is configured to create a collection for each entity in the source code of the smart contract; and create edge collections between entities.

[0026] In a least one embodiment, the query engine is configured to create a high- selectivity index and / or a high-frequency index for the graph database. The high- selectivity index and / or the high-frequency index may comprise an array, index for array type fields on the entities; and use in-memory cache for the high-selectivity index and / or the high-frequency index. Necessary graph database data is accessed in much quicker matter in this way and improve the performance of the query engine.

[0027] In a least one embodiment, the query engine is configured to provide a framework for querying the database; receive a query; process the query via the framework; and in response to processing the query, perform an action. The action may comprise one or more of: providing a tool and an environment for analysis of the data queried within the framework; producing an error message; submitting the query to a state database for a state data and / or storage data of the smart contract; generating a second query based on the received query and submitting the second query to a state database for a state data and / or storage data of the smart contract; suggesting changes in the smart contract’s source code; resolving the vulnerability within the smart contract; activating tracking mechanism; producing a report; providing a vulnerability alert; and / or providing detailed analytics for rapid response and resolution.

[0028] In a least one embodiment, the query engine is configured to generate a query based on the entities identified in the source code of the smart contract; and optimise the query based on an order of the entities being queried, by filtering the query and / or a subquery and changing the order of the filtered query and subqueries. The optimisation may be based on changing the operators and functions used by the query or subquery.

[0029] According to yet another aspect of the present invention, there is provided a security system comprising the query engine described herein. The security system may also comprise the graph database described herein. The security system is configured to carry out any of the method described herein. The query engine may be configured to carry out any of the method described herein.

[0030] According to yet another aspect of the present invention, there is provided a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out any of the methods described herein. The computer program and / or the method described herein may be stored on a computer- readable medium.

[0031] Within the scope of this application, it is expressly intended that the various aspects, embodiments, examples and alternatives set out in the preceding paragraphs, in the claims and / or in the following description and drawings, and in particular the individual features thereof, may be taken independently or in any combination. That is, all embodiments and / or features of any embodiment can be combined in any way and / or combination, unless such features are incompatible, even if there is no direct pointer provided to accompany such a combination, and especially if such a combination would be apparent upon reading this specification.

[0032] BRIEF DESCRIPTION OF THE FIGURES

[0033] Embodiments of the invention will now be described by way of example only with reference to the figures, in which:

[0034] Figure 1 shows an embodiment of a method according to the present invention;

[0035] Figure 2 shows an embodiment of a method for generating a graph database data according to the present invention;

[0036] Figure 3 shows an embodiment of a method for providing a framework for querying the graph database according to the present invention; and

[0037] Figure 4 shows an embodiment of a security system according to the present invention. DETAILED DESCRIPTION

[0038] The following description is presented by way of example to enable a person skilled in the art to make and use the invention. The present invention is not limited to the embodiments described herein and various modifications to the disclosed embodiments will be apparent to those skilled in the art. Embodiments will now be described by way of example only.

[0039] Figure 1 shows an embodiment of the method for a security system. The security system comprises a query engine. The query engine comprises and / or is in communication with a graph database. The query engine also comprises and / or is in communication with a state database. The security system comprises a graph database. The security system comprises a state database. An embodiment of an overall method for the present invention is shown in Figure 1 . The method comprises, at step 102, generating a graph database data for a smart contract. Alternatively, or additionally, at step 102, generating a state database data for the smart contract. The graph database data and the state database data may be generated simultaneously in a single step. In this way all the necessary information is gathered in an optimal manner. Alternatively, the generation of the graph database data and the state database data may be performed in a sequential manner or at different procedural steps depending on the need of processing power and efficiency. The generation of the graph database data may be carried out by performing one or more steps of the method shown in Figure 2. The steps of method 200 shown in Figure 2 may be also applied to generating a state database data. At step 104, a framework for querying the graph database is provided. Alternatively, or additionally, at step 104, a framework for querying the state database is provided. The graph database and state database may be queried via the same framework. The provision of the framework and an embodiment of its operational steps are shown in Figure 3. The framework provides an environment to run arbitrary logic on the queried data. A graph database is created based on the graph database data. A state database is created based on the state database data. The state database data comprises data relating to state information, smart contract balance, the storage slot for the smart contract, storage information of the smart contract etc.

[0040] A query is received at step 106 and processed at step 108. At step 110, an action is performed, in relation to the processed query. Figure 2 shows an embodiment of the method 200 for generating a graph database data and / or a state database data. At step 202, the smart contract is obtained and, at step 212, an error in the source code of the smart contract is determined. In response to determining the error, the source code is fixed at step 222. The error may be one or more of: a syntax error and / or a compilation error. The source code of the smart contract and / or metadata of the smart contract is fixed by, for example but not limited to, removing comments in the source code and / or removing errors in the source code. The source code and / or the metadata is fixed to produce the smart contract that can be compiled. In response to the error not being determined, the smart contract may be compiled. Artifact files may also be extracted. The artifact files comprise data which are used to populate the graph database. The artifact files are used to generate the graph database data. Alternatively, or additionally, information from a blockchain node is extracted for state database data.

[0041] A compatibility of a compiler for the smart contract is verified for generating the graph database data and / or state database data. At step 232, a first compiler version from the source code of the smart contract is determined. In response to determining the first compiler version, the smart contract based on the first compiler version is compiled. An artifact file for the graph database is extracted. The artifact file may be imported into the graph database. Alternatively, or additionally, state database data is extracted from the blockchain node.

[0042] Although not shown in Figure 2, in some embodiments, in response to determining that the first compiler version is not available, compiler options based on the source code of the smart contract is determined. The compiler options are provided depending on parsing and determining the structure of the syntax code and / or metadata. In response to the determined compiler options, a first compiler version is selected and the smart contract is compiled based on the first compiler version. Various potential compilers are provided and / or supported to be used to compile and parse the source code of the smart contract. Determining compiler options aids in finding the most suitable compiler for the smart contract. The security system is adaptable to the different programming languages the smart contract is based on. For example, but not limited to, the security system supports Solidity, Vyper, Yul, Cairo, JavaScript, Rust, Move and any other programming languages used to create the smart contract. The query engine of the present invention is language independent and capable of supporting different programming language. The query engine supports different compilers for different programming language based smart contracts. The graph database is also language independent and capable of supporting and storing data based on different programming languages.

[0043] In some embodiments, a compiling error may occur. In response to the compiling of the smart contract based on the first compiler version generating a compiler error, the compiler error of a first execution of the first compiler is parsed. A second compiler version may also be selected from the determined compiler options. The security system constantly learns from any error that may be generated during the processing of the smart contract to optimise its data integrity and processing capabilities. In response to the compiling of the smart contract based on the first compiler version does not generate any compiler error, extracting of an intermediate representation and / or semantic data from the source code (step 252) may be performed.

[0044] In some embodiments, remapping information of data from the source code and / or metadata of the smart contract to a graph database data index is determined. The determination of the remapping information may be carried out at step 242 and / or step 252. Alternatively, or additionally remapping information of data from the source code and / or metadata of the smart contract to a state database data index is determined. This ensures the compatibility of the compiler and enables to generate the graph database data and / or state database data effectively. In response to determining that the remapping is not available, recreating a folder structure of the smart contract. The recreation of the folder structure of the smart contract enables compilation of the smart contract. Each of the folders may comprise one or more files or other folders. An artifact file comprising mapping information for the relevant smart contracts, functions and / or instructions, to the one or more files in the recreated folder structure is determined. This ensures that all the relevant information is available in the graph database for a query and for data integrity. In response to determining that the remapping is available, compiling the smart contract based on the first compiler version (step 242) may be performed.

[0045] In some embodiments, a recency of the smart contract is determined. For example, but not limited to, the use of the smart contract within a certain period of time and the frequency of the use, such as once in last month, once in past two weeks, twice in last month, may be determined. In response to determining the recency of the smart contract, the smart contract is placed into one of: a graph database for old smart contracts or a graph database for recent smart contracts. For example, if the smart contract was used once in last month, then the smart contract is place in the graph database for recent smart contracts. The threshold for determining the recency may be configured by the user. Alternatively, the threshold for determining the recency may be configured by the security system (for example, by the query engine or by the graph database) operator and / or supplier.

[0046] At step 252, an intermediate representation (IR) and / or semantic data from the source code are extracted. At step 262, the intermediate representation (IR) is analysed to generate additional data (e.g., extended IR information) for the graph database. At step 272 the additional data has been generated. The additional data comprises one or more of but not limited to: call qualifiers, dominators, variables being read / written, information about expressions such as the type and its size etc. In some embodiments, the intermediate representation (IR) may refer to SlitherIR representation of the source code of the smart contract. The additional data needed to reconstruct the Control Flow Graph (CFG) and Data Flow Graph (DFG) are extracted. The additional data are used to perform one or more of: control flow, data flow and / or taint analysis on the source code when requested by the user’s query. The additional data are stored in the graph database for the security system. In some embodiments, the CFG and DFG are stored in the graph database. The CFG and DFG may be reconstructed by the framework when requested. The IR of the source code with extended IR information are extracted for every single instruction and code part of the source code. The semantic data comprise one or more of: semantic information, contract, language constructs and property of the language constructs. The language construct comprises one or more of but not limited to: names of the functions, contract, variables, enumerated types (enums), errors. The property of the language construct comprises one or more of but not limited to: private, public, internal, external, modifiers data, return variables and its types, user defined structures.

[0047] The smart contract comprises one or more entities within its source code. The smart contract may be received from different open sources to be processed to generate the graph database data for the security system. Although not shown in Figures, in some embodiments, one or more collections for each entity in the source code of the smart contract is created. The entity in a source code may refer to contract, function, modifier, error, enum, event, structs, variable, instruction. Edge collections between the entities are created by determining and storing relationship (represented by an edge) between entities. For example, the edge collections may comprise contracts to contracts, contracts to enums, contracts to events, contracts to error, contracts to structures (structs), contracts to functions, contracts to modifiers, functions to functions, functions to errors, functions to instructions, functions to modifiers, functions to variables, functions to events, modifiers to errors, modifiers to functions, modifiers to instructions, modifiers to variables, modifiers to events. An edge collection between entities of the smart contract forms a part of the graph database data. The edge collection is stored in the graph database.

[0048] In some embodiments, an index is created. For example, a high-selectivity index or high-frequency usage index is created. The high-frequency index is based on the frequency of usage of the query functions (also refer to as methods). The indexes are created based on one or more of: the graph database implementation, specifics of the graph database implementation and / or historical data of writing queries. The historical data, in particular, may help locating the most frequently used query structures. The high-selectivity index or the high-frequency index may comprise different types of indexes. For example, the high-selectivity index or the high- frequency index may comprise one or more of: an array index and / or a hash index. An array index may be used for array type fields on the entities. In-memory-caching is used for the one or more collections and / or one or more of the indexes. In-memory- caching This provides enhanced performance by optimising a search.

[0049] Some of the steps of method 200 shown in Figure 2 may be processed in parallel. For example, in some embodiments, two or more of: determination of an error (step 212), determination of a first compiler version (step 232) and determination of remapping information (not shown) may be processed in parallel.

[0050] Some of the steps of method 200 shown in Figure 2 may be skipped or reordered in execution depending on the situation. For example, in some embodiments, fixing of the source code may not occur (step 222) as no error (syntax or compilation error) was found. In some embodiments, step 232, determination of a first compiler may not occur until compilation of the smart contract occurs at least once prior to executing step 232. In some embodiments, the compilation of the source code of the smart contract (step 242) may occur straight after obtaining the smart contract at the step 202. This may be an initiation of the method 200. By compiling the smart contract, the security system may obtain information regarding the smart contract such as but not limited to an error in syntax, recommended compiler, potential options for compilers, remapping information. Figure 3 shows a method 300 for querying the graph database. Alternatively, or additionally, the steps of method 300 are performed for querying the state database. At step 304 a framework for querying the graph database and / or the state database is provided. The same framework may be used for querying both the graph database and the state database. At step 306 a query is received. The query may be received from the user, the operator of the security system or automatically by the security system by design. At step 308, the query is processed via the framework. At step 310 an action is performed in response to processing the query. The action may comprise one or more of: providing a tool (such as methods to utilise within the framework interface) and a local environment for analysis of the data queried within the framework, producing an error message, submitting the query to the state database for state data and / or storage data of the smart contract, generating a second query based on the received query and submitting the second query to the state database for state data and / or storage data of the smart contract, performing taint and / or data flow analysis or other graph-based analysis, suggesting changes in the smart contract’s source code, resolving the vulnerability within the smart contract; activating tracking mechanism, producing a report, providing a vulnerability alert, and / or providing detailed analytics for rapid response and resolution. Messaging correct individuals, such as protocol handler, the user, the smart contract participants, to alert vulnerabilities in the smart contract. This ensures the integrity of data and the transaction in relation to the smart contract, enhancing the overall cyber security for the smart contract and the relevant blockchain. The system may be used as data analysis tool with or without the aim of checking the vulnerabilities. Steps 304 to 310 of Figure 3 corresponds to steps 104 to 110 of Figure 1 .

[0051] At step 312, a query based on the entities identified in the source code of the smart contract is generated. The query may be automatically generated by the security system, in particular the query engine. This query may be based on the query received at step 306. At step 314, the generated query is optimised. The optimisation may be based on an order of the entities being queried. The optimisation may be performed by filtering the query and / or its subqueries, changing the order of the filtered query and subqueries and changing the operators of the query and subqueries. The optimised queries are efficient and high-speed queries. These optimised queries may be generated by using a pruning mechanism of the graph database when traversing a graph and changing the order of filtering part of the queries. Different methods may be used to filter subqueries. The filtering of the subqueries of the query may be based on the length of the subquery result. For example, but not limited to, a QueryAggregator class may be incorporated in the framework to generate the query and subqueries. The framework may be formed in a Python environment. In some embodiments, ArangoDB may be used as a general-purpose graph database engine for the query engine. Sharding and query coordination mechanisms, multi-threading mechanisms provided by the graph database are used to boost performance of the framework for querying.

[0052] At step 316, the graph database and / or the state database is updated. The updating of the graph database and the state database also occurs when new smart contracts are created. Alternatively, or additionally the state database is updated based on the state change of the blockchain wherein the blockchain comprises the smart contract. The state change of the blockchain occurs when a new transaction or a block is added to the blockchain.

[0053] Figure 4 shows an embodiment of a security system 400 according to the present invention. The query engine may comprise one processor 410 as shown in Figure 4. The query engine may comprise more than one processor to perform the methods described herein. The query engine comprises one or more of: a vulnerability detection module 412, a vulnerability correction module 414, a tracking module 416, a query composition module 418, a machine learning (ML) platform 420, a contract composition module (not shown) and Integrated Development Environment (IDE) module (not shown). These modules and platform may be distributed across network of computers or distributed across different processors.

[0054] In some embodiments, the vulnerability detection module 412 is configured to systematically generate and send a composed query to the smart contracts within the blockchain network. The vulnerability detection module 412 is configured to delve deep into the smart contract’s logic and structure to detect even a subtle and complex security gap. When processing a query via the ML platform 420 (its Al operative) may be configured to identify and / or generate vectors of potential attack on the smart contract.

[0055] In some embodiments, the vulnerability correction module 414 is configured to communicate with the vulnerability detection module 412. In response to detecting a vulnerability, the vulnerability correction module 414 is configured to automatically suggest changes in the smart contract’s source code. This proactive approach not only addresses current vulnerabilities the smart contract but also reinforces the smart contract against similar exploits in the future. The vulnerability correction module 414 is configured to resolve the vulnerability of the smart contract with the fundamental operations and intents of the smart contract intact.

[0056] In some embodiments, the tracking module 416 is configured to detect and track an exploited smart contract. In response to detecting a fraudulent and / or corrupted transaction, the query engine activates the tracking mechanisms. The query engine is configured to provide real-time alerts and detailed analytics for rapid response and resolution. In some embodiments, the track module 416 enables this operation.

[0057] In some embodiments, the query composition module 418 is configured to generate queries for identifying potential vulnerabilities within smart contracts. The query composition module 418 is configured to communicate with the ML platform 420. The ML platform 420 is configured to simulate various attack vectors and potential weaknesses. This ensures that potential vulnerabilities and point of failure can be predicted.

[0058] In some embodiments, the contract composition module is configured to generate new smart contracts. The contract composition module is configured to feed the ML platform 420 with data about the smart contracts. By labelling the data, the generated smart contract will already be scanned using all the queries in the database. The smart contracts may be configurable, so that users can select modules and functions that they want, which are then generated using Artificial Intelligence (Al) and / or ML platform 420. IDE module provides an environment where the developer can develop code and getting real-time suggestions and / or errors based on the graph database and / or the state database.

[0059] The query engine is configured to generate a graph database data for a smart contract. Alternatively, or additionally, the query engine is configured to generate a state database data for a smart contract. The query engine may be configured to receive and / or collect smart contracts from different opensource systems, closed source systems with consent from the license owner. The users may upload smart contracts, source codes and run queries. The query is configured to obtain the smart contract, determine an error in a source code of the smart contract. The error may be a syntax error or a compilation error. If the error is determined, then the query engine is configured to fix the source code and / or metadata of the smart contract to produce the source code, or compilation parameters such that the contract can be compiled. The query engine comprises a fixing logic to fix the errors in the source code or metadata of the smart contract. For example, but not limited to, the query engine is configured to flattens the source code file via a flattener and fix compile errors via a fixer. The query engine may be configured to remove comments in the source code (in flattened file) and / or remove errors in the source code.

[0060] If the error is not determined, then the query engine may compile the source code. The query engine is configured to extract an artifact file from the flattened file using metadata of the smart contract. The metadata is saved in a database (such as but not limited to, PostgreSQL DB) along with the relevant smart contract. The query engine is configured to import the artifact file into the graph database 460 via an importer. The query engine is in communication with the graph database 460.

[0061] The query engine is configured to determine a first compiler version from a source code of the smart contract and / or metadata of the smart contract. If the first compiler version is determined, then the query engine is configured to compile the smart contract based on the first compiler version. The query engine is configured to extract an artifact file for the graph database 460. If the query engine determines that the compiler version not available, then the query engine is configured to determine compiler options based on the source code of the smart contract. The query engine is configured to select a first compiler version and compile the smart contract based on the first compiler version.

[0062] The query engine is configured to determine and / or generate a compiler error in response to the compiling of the smart contract based on the first compiler version. The query engine is configured to parse the compiler error of a first execution of the first compiler and select a second compiler version. The second compiler version is selected from the determined compiler options.

[0063] The query engine is configured to determine remapping information of data from the source code of the smart contract. The remapping information comprise one or more of: mapping of the source code to an entity and / or mapping of relationship between smart contracts. The remapping information relates to reconstructing the source code of the smart contract whilst maintaining relational information about other imported contracts.

[0064] The query engine is configured to check the compatibility of the compiler and the smart contract. In response to determining that the remapping is not available, the query engine is configured to recreate a folder structure of the smart contract. The recreation of the folder structure of the smart contract enables compilation of the smart contract. Each of the folders may comprise one or more files or folders. The query engine is configured to create an artifact file comprising mapping information for the relevant smart contracts, functions and / or instructions, to the one or more files in the recreated folder structure. In response to determining that the remapping is available, the query engine is configured to compile the smart contract based on the first compiler version.

[0065] In some embodiments, the query engine is configured to determine a recency of the smart contract. The query engine may use an instrumented node as a recency checker. For example, but not limited to, the use of the smart contract within a certain period of time and the frequency of the use, such as once in last month, once in past two weeks, twice in last month, may be determined. In response to determining the recency of the smart contract, the query engine is configured to place the smart contract into one of: a graph database for old smart contracts or a graph database for recent smart contracts. For example, if the smart contract was used once in last month, then the smart contract is placed in the graph database for recent smart contracts. The threshold for determining the recency may be configured by the user. Alternatively, the threshold for determining the recency may be configured by the query engine or the graph database operator and / or supplier. The graph database 460 for old smart contracts may be used as an archive database. The archive database and the database for the recent contracts may be a separate database (not shown in Figure 4) or may be formed as the same database. Alternatively, or additionally the query engine is configured to place the smart contract and / or information relevant to the smart contract into one of: a state database for old smart contracts or a state database for recent smart contracts. These state databases operate and are identified the same way as the graph database in light of determining the recency.

[0066] The query engine is configured to extract an intermediate representation (IR) from the source code of the smart contract. The query engine is configured to analyse the intermediate representation (IR) to generate additional data (e.g., extended IR information) for the graph database 460. The additional data comprises one or more of but not limited to: call qualifiers, dominators, variables being read / written, information about expressions such as the type and its size etc. In some embodiments, the intermediate representation (IR) may refer to SlitherIR representation of the source code of the smart contract. The additional data needed to reconstruct the Control Flow Graph (CFG) and Data Flow Graph (DFG) are extracted. The additional data are used to perform taint analysis, data flow analysis, or control flow analysis on the source code when requested by the user’s query. The additional data may be stored in the graph database 460 for the query engine. The IR of the source code with extended IR information are extracted for every single instruction, and any other language construct and code part of the source code.

[0067] Alternatively, or additionally, the query engine is configured to extract semantic data from the source code of the smart contract. The semantic data comprise one or more of: semantic information, contract, language constructs and property of the language constructs. The language construct comprises one or more of but not limited to: names of the functions, contract, variables, enumerated types (enums), errors. The property of the language construct comprises one or more of but not limited to: private, public, internal, external, modifiers data, return variables and its types, user defined structures.

[0068] The smart contract comprises one or more entities within its source code. In some embodiments, the query engine is configured to create one or more collections for each entity in the source code of the smart contract. The entity in a source code may refer to contract, function, modifier, error, enum, event, structs, variable, instruction. Edge collections between the entities are created by determining and storing relationship (represented by an edge) between entities. For example, the edge collections may comprise contracts to contracts, contracts to enums, contracts to events, contracts to error, contracts to structures (structs), contracts to functions, contracts to modifiers, functions to functions, functions to errors, functions to instructions, functions to modifiers, functions to variables, functions to events, modifiers to errors, modifiers to functions, modifiers to instructions, modifiers to variables, modifiers to events. An edge collection between entities of the smart contract forms a part of the graph database data. The query engine is configured to store an edge collection in the graph database 460.

[0069] In some embodiments, the query engine is configured to create and use an index. In some embodiments, the query engine is configured to use a high-selectivity index or a high-frequency index. An array index may be used for array type fields on the entities. The high-selectivity index or the high-frequency index may comprise an array index and / or hash index. The query engine is configured to use in-memory- caching 454 for the one or more collections and / or for the one or more indexes. The security system comprises memory 450. The memory 450 may comprise an operating system 452, a cache memory 454 and an application software 456.

[0070] The query engine is configured to provide a framework for querying the graph database. Alternatively, or additionally, the query engine is configured to provide a framework for querying the state database. In some embodiments, the query engine is configured to predict potential vulnerabilities in a smart contract and points of failure. The vulnerability detection module 412 may be configured to provide the framework. The query engine is configured to receive a query. The query may be received via a web application. The query is received via an input / output interface 440. The query may be received via a user input device 480. The user of the system can interact with the query engine using the user input device 480 such as but not limited to a keyboard, a touch screen, a digital pen, a mouse, a virtual interaction device etc. A display 470 is provided for the user to receive an output from the quey engine. The display may be a monitor or any device that support virtual reality interaction such as a head mounted device. The query may be received from a query composition module 418.

[0071] The query engine is configured to process the query via the framework. The vulnerability detection module 412 may be configured to process the query. In response to processing the query, the query engine is configured to perform an action. The action comprises one or more of: providing a tool (such as methods to utilise within the framework interface 440) and a local environment for analysis of the data queried within the framework, producing an error message, submitting the query to the state database for state data and / or storage data of the smart contract, generating a second query based on the received query and submitting the second query to the state database for state data and / or storage data of the smart contract, suggesting changes in the smart contract’s source code, activating tracking mechanism, producing a report, providing a vulnerability alert, resolve the vulnerability within the smart contract and / or providing detailed analytics for rapid response and resolution. The vulnerability detection module 412 and / or the vulnerability correction module 414 may be configured to produce the error message. The vulnerability detection module 412 and / or the vulnerability correction module 414 may be configured to submit the query to the state database for state data and / or storage data of the smart contract. The query composition module 418 is configured to generate a second query based on the received query. The vulnerability detection module 412 and / or the vulnerability correction module 414 may be configured to submit the second query to the state database for state data and / or storage data of the smart contract. The vulnerability correction module 414 may be configured to suggest or implement the changes in the smart contract’s source code. The tracking module 416 may be activated as a part of the action to perform. The tracking module 416 is configured to track the smart contract whose source code has been identified to have a vulnerability in it and / or whose source code has been resolved of identified vulnerability. The vulnerability detection module 412 and / or the vulnerability correction module 414 may be configured to produce a report. The vulnerability detection module 412 and / or the vulnerability correction module 414 may be configured to provide a vulnerability alert. The vulnerability detection module 412 and / or the vulnerability correction module 414 may be configured to provide detailed analytics for rapid response and resolution. Various options are provided by the security system, in particular the query engine, to address security risks. All these actions are provided to remedy the vulnerability identified during the query and generation of the graph database data and / or the state database data. For example, the actions such as producing an error can provide further data for the query engine to train its Machine Learning (ML) model via a ML platform 420 so that the query the query composition module 418 generates are more optimised to produce effective results when query is performed by a user.

[0072] Using a communication interface 430, the query engine is configured to send the error message, the query, the vulnerability alert, the detailed analytics and / or suggestions to changes in the smart contract’s source code mentioned in the action to be performed.

[0073] The query engine is configured to generate a query based on the entities identified in the source code of the smart contract. The query engine is configured to optimise the query based on an order of the entities being queried by filtering the query and / or a subquery and changing the order of the filtered query and subqueries. The query engine is configured to use a pruning mechanism of the graph database 460 when traversing a graph and change the order of filtering part of the queries to optimise the query. The query composition module 418 may be configured to generate the query based on the entities in the source code of the smart contract and / or optimise the query based on an order of the entities being queried.

[0074] Figure 4 shows a graph database 460. The graph database 460 may comprise more than one graph database. The graph database comprises at least one graph database for recent smart contracts. Figure 4 shows a state database 490. The state database 490 may comprise more than one state database. The state database comprises at least one state database for recent smart contracts. In some embodiments, the graph database for old smart contracts may be mainly used for training ML platform 420. Alternatively, or additionally, the state database for old smart contracts may be mainly used for training ML platform 420. The query engine is configured to process the functions based on semantic and property queries directly with the graph database. For example, but not limited to the query engine being configured to filter by function name, modifier, instruction types included in a function, the functions themselves, or any other entity property. The query engine is configured to process the functions operable with CFG, DFG and taint analysis to be provided in the local framework environment. For example, a typical query flow of the query engine may be filtering out the functions and / or contract entities from the graph database, then using one or more of CFG, DFG, taint functions to locally construct a graph for the source code and do the respective graph analysis. This allows an analysis to be performed in the local framework environment. The query engine is configured to create the local framework environment. Generating and saving CFG, DFG or taint information in the graph database will result in the significantly increasing the size of the graph database and slower response time to a query. Therefore, utilising the local framework environment for analysis allows for better query performance. To boost the query performance, the query engine is configured to use sharding, query coordination mechanisms and multi-threading mechanisms provided by the graph database, as well as utilizing efficient indexes. These mechanisms are automatically applied to during the generation of the graph database data and querying. The same mechanisms are available to the state database 490 and applied to during the generation of the state database data and querying.

[0075] The query engine is configured to use and / or train Artificial Intelligence / Machine Learning (AI / ML) model to learn to generate queries. The ML platform 420 may comprise the AI / ML model. The AI / ML models may provide remediation suggestions for correcting the vulnerability in the smart contract. The AI / ML model may be used to learn to generate queries based on text input. The text input may be provided via the input / output interface 440. The text input may be collected by incorporating a Generative Pre-trained Transformer (GPT). The query engine may be configured to train a custom GPT, or other model, instance to generate queries based on text input. The frameworks provided by the query engine can be used for labelling and analysing the data gathered for the graph database. In some embodiments, the ML platform 420 is configured to label data when generating the graph database data and / or the state database data. The ML platform 420 is configured to train ML models with the labelled data. In this way, for example, the ML platform 420 may be configured to classify contracts, functions and instruction sets by vulnerability types or any other classification and train model to identify vulnerabilities and code scenarios in contracts. Alternatively, or additionally, the ML platform 420 may be configured to label the smart contract by their functionality, such as but not limited to: “decentralized exchange’7”Oracle7”lending-borrowing protocol” / ”Non-Fungible Token (NFT)” etc. and train a model that identifies and labels contracts automatically. The ML platform 420 is configured to continuously learn from the existing smart contracts. The existing smart contract may comprise the smart contracts that have been exploited. The ML platform 420 is configured to detect bug reports when they are published on a blockchain or internet and generate the graph database data from the detected bug reports. The graph database data generated from a single bug Proof Of Concept (POC) may be used limitlessly by the ML platform (and its Al operative) to identify vulnerabilities in any smart contract for the specific vulnerability type. This continuous learning process enables the system to adapt to emerging threats and vulnerabilities, enhancing the security. It is appreciated that the query engine can be used for different types of data analysis purposes, not only just for vulnerability verification.

[0076] A computer program comprising instructions which, when the program is executed by a computer, cause the system 400 to carry out any of the methods described herein. The computer program may be stored on a computer-readable medium.

[0077] The methods described herein may be performed by a computer configured with software in machine readable form stored on a tangible storage medium e.g. in the form of a computer program comprising computer readable program code for configuring a computer to perform the constituent portions of described methods or in the form of a computer program comprising computer program code means adapted to perform all the steps of any of the methods described herein when the program is run on a computer and where the computer program may be embodied on a computer readable storage medium. Examples of tangible (or non-transitory) storage media include disks, thumb drives, memory cards etc. and do not include propagated signals. The software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously. The hardware components described herein may be generated by a non-transitory computer readable storage medium having encoded thereon computer readable program code. The method described herein, and the system described herein may be configured to be used in Web3.0 environment. For example, the method described herein, and the system described herein may be configured to be used in distributed systems, such as blockchains that operate state-transitioning programs such as smart contracts.

[0078] It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages.

[0079] Any reference to 'an' item refers to one or more of those items. The term 'comprising' is used herein to mean including the method blocks or elements identified, but that such blocks or elements do not comprise an exclusive list and an apparatus may contain additional blocks or elements and a method may contain additional operations or elements. Furthermore, the blocks, elements and operations are themselves not impliedly closed. The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. The arrows between boxes in the figures show one example sequence of method steps but are not intended to exclude other sequences or the performance of multiple steps in parallel. Additionally, individual blocks may be deleted from any of the methods without departing from the spirit and scope of the subject matter described herein. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought. Where elements of the figures are shown connected by arrows, it will be appreciated that these arrows show just one example flow of communications (including data and control messages) between elements. The flow between elements may be in either direction or in both directions.

[0080] The applicant hereby discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in the light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein. In view of the foregoing description, it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.

Claims

CLAIMS1. A method for a security system comprising a graph database, the method comprising: generating a graph database data for a smart contract by: obtaining the smart contract; determining an error in a source code of the smart contract; and in response to determining the error, fixing the source code to produce the source code and / or metadata of the smart contract that can be compiled.

2. The method according to claim 1 comprising: determining a first compiler version from a source code of the smart contract; and in response to determining the first compiler version, compiling the smart contract based on the first compiler version and extracting an artifact file for the graph database.

3. The method according to claim 1 or claim 2 comprising: in response to determining that the first compiler version is not available, determining compiler options based on the source code of the smart contract and metadata of the smart contract; and in response to the determined compiler options, selecting a first compiler version and compiling the smart contract based on the first compiler version.

4. The method according to any one of the preceding claims, comprising: in response to the compiling of the smart contract based on the first compiler version generating a compiler error, parsing the compiler error of a first execution of the first compiler and selecting a second compiler version.

5. The method according to any one of the preceding claims, comprising: determining remapping information of data from the source code of the smart contract to a graph database data index; and in response to determining that the remapping is not available, recreating a folder structure of the smart contract project.

6. The method according to any one of the preceding claims, comprising: extracting an intermediate representation from the source code of the smart contract; and analysing the intermediate representation to generate additional data for the graph database.

7. The method according to any one of the preceding claims, comprising: extracting semantic data from the source code of the smart contract.

8. The method according to any one of the preceding claims, comprising: creating a collection for each entity in the source code of the smart contract; and creating edge collections between entities.

9. The method according to claim 8 comprising: creating a high-selectivity index and / or a high-frequency index for the graph database, wherein the high-selectivity index and / or the high-frequency index comprises an array index for array type field on the entities.

10. The method according to any one of the preceding claims, comprising: providing a framework for querying the graph database; receiving a query; processing the query via the framework; and in response to processing the query performing an action.11 . The method according to claim 10, wherein performing an action comprises one or more of: providing a tool and a local environment for analysis of the data queried within the framework; producing an error message; submitting the query to a state database for state data and / or storage data of the smart contract;generating a second query based on the received query and submitting the second query to a state database for state data and / or storage data of the smart contract; performing taint and / or data flow analysis; suggesting changes in the smart contract’s source code; resolving the vulnerability within the smart contract; activating tracking mechanism; producing a report; providing a vulnerability alert; and / or providing detailed analytics for rapid response and resolution.

12. The method according to any one of the preceding claims, comprising: generating a query based on the entities identified in the source code of the smart contract; and optimising the query based on an order of the entities being queried, by filtering the query and / or a subquery and changing the order of the filtered query and subqueries.

13. A query engine configured to: generate a graph database data for a smart contract by: obtaining the smart contract; determining an error in a source code of the smart contract; and in response to determining the error, fixing the source code and / or metadata of the smart contract to produce the source code that can be compiled.

14. The query engine according to claim 13 configured to: determine a first compiler version from a source code of the smart contract; and in response to determining the first compiler version, compile the smart contract based on the first compiler version and extracting an artifact file for the graph database.

15. The query engine according to claim 13 or claim 14 configured to: in response to determining that the compiler version not available, determine compiler options based on the source code of the smart contract; andin response to the determined compiler options, select a first compiler version and compiling the smart contract based on the first compiler version.

16. The query engine according to claim 13 to 15, configured to: in response to the compiling of the smart contract based on the first compiler version generating a compiler error, parse the compiler error of a first execution of the first compiler and selecting a second compiler version.

17. The query engine according to any one of claims 13 to 16, configured to: determine remapping information of data from the source code of the smart contract to a graph database data index; and in response to determining that the remapping not available, recreate a folder structure of the smart contract.

18. The query engine according to any one of claims 13 to 17, configured to: extract an intermediate representation from the source code of the smart contract; and analyse the intermediate representation to generate additional data for the graph database.

19. The query engine according to any one of claims 13 to 18, configured to: extract semantic data from the source code of the smart contract.

20. The query engine according to any one of claims 13 to 19, configured to: create a collection for each entity in the source code of the smart contract; and create edge collections between entities.21 . The query engine according to any one of claims 13 to 20, configured to: create a high-selectivity index and / or a high-frequency index for the graph database, wherein the high-selectivity index and / or the high-frequency index comprise an array index for array type fields on the entities; and use in-memory cache for the high-selectivity index and / or the high-frequency index.

22. The query engine according to any one of claims 13 to 21 , configured to: provide a framework for querying the database; receive a query; process the query via the framework; and in response to processing the query, perform an action, wherein the action comprises one or more of: providing a tool and a local environment for analysis of the data queried within the framework; producing an error message; submitting the query to a state database for state data and / or storage data of the smart contract; generating a second query based on the received query and submitting the second query to a state database for state data and / or storage data of the smart contract; performing taint and / or data flow analysis; suggesting changes in the smart contract’s source code; resolving the vulnerability within the smart contract; activating tracking mechanism; producing a report; providing a vulnerability alert; and / or providing detailed analytics for rapid response and resolution.

23. The query engine according to any one of claims 13 to 22, configured to: generate a query based on the entities identified in the source code of the smart contract; and optimise the query based on an order of the entities being queried, by filtering the query and / or a subquery and changing the order of the filtered query and subqueries.

24. A system comprising the query engine according to claim 13 to 23 and a graph database.

25. A computer-readable medium having stored thereon and perform the steps of the method according to claims 1 to 12.

Citation Information

Patent Citations

  • Method and system for supporting smart contracts in a blockchain network

    US20240020109A1