Deep learning model for vulnerability or bug detection in executable code of distributed ledger

Abstract

An electronic device for vulnerability or bug detection in executable code of distributed ledger using deep learning model is disclosed. The electronic device received a first executable code associated with a distributed ledger and extract elements of the first executable code. The electronic device determines a code embedding associated with the elements of the first executable code. The electronic device applies a self-attention model and hierarchical cross-attention model on the code embedding. The electronic device determines attention weights for each of the elements associated with the first executable code, based on the application of the self-attention model and the hierarchical cross-attention model. Further, the electronic device trains a deep learning model configured to detect at least one of vulnerabilities or bugs in a second executable code associated with the distributed ledger. The deep learning model is trained based on the attention weights.

Description

DEEP LEARNING MODEL FOR VULNERABILITY OR BUG DETECTION IN EXECUTABLE CODE OF DISTRIBUTED LEDGERCROSS-REFERENCE TO RELATED APPLICATIONS / INCORPORATION BY REFERENCE

[0001] This application claims priority to Indian Provisional Application No. IN202411051086, filed July 3, 2024, which is hereby incorporated by reference in its entirety.FIELD

[0002] Various embodiments of the disclosure relate to distributed ledger technology (DLT). More specifically, various embodiments of the disclosure relate to an electronic device and a method disclosing deep learning model for vulnerability or bug detection in executable code of distributed ledger.BACKGROUND

[0003] Distributed ledger technologies (DLTs) have gained significant attention in recent years due to their potential to revolutionize various industries by providing secure, transparent, and decentralized systems for recording and verifying transactions. As DLTs have evolved, they have been applied to areas such as finance, supply chain management, and digital identity verification. Advancements in DLTs have led to the development of smart contracts, which are self-executing agreements with predefined rules encoded into blockchain networks. However, the complexity of these systems has introduced challenges related to code security and vulnerability detection. Traditional approaches to identifying vulnerabilities in DLT-based systems have included manual code reviews, static analysis tools, and dynamic testing methods. These techniques often struggle to keep pace with the rapid evolution of DLT platforms and the increasing sophistication of potential attacks. Additionally, existing solutions may face limitations indetecting cross-contract vulnerabilities, handling large-scale codebases efficiently, or adapting to new types of vulnerabilities as they emerge.

[0004] Limitations and disadvantages of conventional and traditional approaches will become apparent to one of skill in the art, through comparison of described systems with some aspects of the present disclosure, as set forth in the remainder of the present application and with reference to the drawings.SUMMARY

[0005] An electronic device and method for vulnerability or bug detection in executable code of distributed ledger using deep learning model is provided substantially as shown in, and / or described in connection with, at least one of the figures, as set forth more completely in the claims.

[0006] These and other features and advantages of the present disclosure may be appreciated from a review of the following detailed description of the present disclosure, along with the accompanying figures in which like reference numerals refer to like parts throughout.BRIEF DESCRIPTION OF THE DRAWINGS

[0007] FIG. 1 is a block diagram that illustrates an exemplary network environment for vulnerability or bug detection in executable code of distributed ledger using deep learning model, in accordance with an embodiment of the disclosure.

[0008] FIG. 2 is a block diagram that illustrates an electronic device for vulnerability or bug detection in executable code of distributed ledger using deep learning model, in accordance with an embodiment of the disclosure.

[0009] FIG. 3 is a diagram that illustrates an exemplary execution pipeline for vulnerability or bug detection in executable code of distributed ledger using deep learning model, in accordance with an embodiment of the disclosure.

[0010] FIG. 4 is a diagram that illustrates an exemplary architecture of deep learning model for vulnerability or bug detection in executable code of distributed ledger, in accordance with an embodiment of the disclosure.

[0011] FIG. 5 is a diagram that illustrates an exemplary architecture for hierarchical network for vulnerability or bug detection in executable code of distributed ledger, in accordance with an embodiment of the disclosure.

[0012] FIG. 6 is a diagram that illustrates an exemplary scenario for determination of attention weights for vulnerability or bug detection in executable code of distributed ledger using deep learning model, in accordance with an embodiment of the disclosure.

[0013] FIGs. 7A, 7B, and 7C are diagrams that illustrate exemplary user interfaces of DLT attack detection tool for determination vulnerability or bug detection in executable code of distributed ledger, in accordance with an embodiment of the disclosure.

[0014] FIG. 8 is a flowchart that illustrates operations of an exemplary method for vulnerability or bug detection in executable code of distributed ledger using deep learning model, in accordance with an embodiment of the disclosure.DETAILED DESCRIPTION

[0015] The following described implementations may be found in a disclosed electronic device and a method for vulnerability or bug detection in executable code of distributed ledger using deep learning model. Exemplary aspects of the disclosure may provide an electronic device that may receive an executable code (for example, a first executable code) associated with a distributed ledger and extract elements of the first executable code. The distributed ledger may correspond to, but not be limited to, a private distributed ledger, a public distributed ledger, or a hybrid distributed ledger. The distributed ledger may include but not be limited to a blockchain, a Directed Acyclic Graph (DAG), and a hashgraph. The electronic device may determine a code embedding associated with theelements of the first executable code. A self-attention model and a hierarchical crossattention model may be applied on the code embedding. The electronic device may determine attention weights for each of the elements associated with the first executable code, based on the application of the self-attention model and the hierarchical crossattention model. A deep learning model may be trained to detect the vulnerabilities or bugs in a second executable code associated with the distributed ledger. The deep learning model may be trained based on the attention weights.

[0016] Currently, existing methods for vulnerability detection in distributed ledger technology (DLT) may primarily rely on static analysis tools, which have several disadvantages. For example, the existing vulnerability detection tools for DLTs may depend heavily on predefined rules and semantics to identify vulnerabilities, which leads to a high number of false positives (an incorrect identification safe code as vulnerable) and false negatives (a failure to identify actual vulnerabilities). The existing static analysis tools may not accurately capture the dynamic and evolving nature of vulnerabilities. Additionally, existing static analysis tools may struggle to adapt to new and emerging vulnerabilities. As new attack vectors and vulnerabilities are discovered, the static analysis tools may require significant updates to their rule sets and semantics, which may be time-consuming and may not keep pace with the rapid evolution of threats. Furthermore, existing non-static vulnerability detection tools (which may be used as a reference system) may perform well in certain aspects but lack the ability to support cross-code vulnerability detection. This means they may not effectively identify vulnerabilities that arise from interactions between different pieces of code or smart contracts within the DLT ecosystem. Cross-code vulnerabilities may be critical, as they often involve complex dependencies and interactions that the existing vulnerability analysis tools may overlook.

[0017] The disclosed electronic device may receive the first executable code associated with the distributed ledger. The distributed ledger may include a private distributed ledger, a public distributed ledger, a hybrid distributed ledger, and the like. Elements may be extracted from the first executable code. The elements of the first executable code may correspond to an abstract syntax tree (AST). The elements may include but not limited to, syntactical structure information, semantic role information, data-type information, data- scope information, data-context information, control flow features, token-level features, and cross-module or dependency features. The code embedding may be determined associated with the elements of the first executable code. The code embedding may include tokenization of the first executable code, word embedding determination of the first executable code and positional embedding determination associated with the first executable code. The self-attention model and the hierarchical cross-attention model may be applied on the code embedding. The attention weights may be determined for each of the elements associated with the first executable code, based on the application of the self-attention model and the hierarchical cross-attention model.

[0018] The potential vulnerabilities in the smart contracts may include, but not be limited to, reentrancy vulnerability, overflow and underflow vulnerabilities, unprotected cryptocurrency (e.g., ether) withdrawal, front-running attacks, insecure random number generation, permissioning issues, gas limit and out-of-gas Issues, and timestamp dependence. Exploitation of vulnerabilities in smart contracts may lead to significant issues, including the loss of funds, data manipulation, service disruption, and chain reactions. Unauthorized access and manipulation of funds stored in the smart contract may result in attackers draining the contract’s balance, which may cause financial losses for users and stakeholders. Additionally, vulnerabilities may allow attackers to manipulate the state of a smart contract, which may lead to unauthorized changes in data or settings.Successful attacks on smart contracts can also disrupt the normal operation of decentralized applications or blockchain services, which may affect users’ ability to transact, trade, or interact with the affected application. Furthermore, vulnerabilities in one smart contract may have a cascading effect on other contracts within the ecosystem. If contracts interact or depend on each other, an exploit in one contract may compromise the security of others.

[0019] The disclosed deep learning model for vulnerability detection in DLT executable code utilizes a hierarchical attention model with cross-code and cross-function detection capabilities. This approach analyzes contracts at different levels of abstraction, from high- level contract structure down to lower-level code elements like functions and statements. Unlike traditional methods, the disclosed technique may employ a combination of selfattention and hierarchical cross-attention mechanisms to capture complex relationships within and between different parts of the code. The technique offers several advantages, including comprehensive vulnerability detection across multiple layers of blockchain technology, improved accuracy through advanced machine learning techniques, and the ability to adapt to both public and private DLTs. Additionally, the disclosed technique’s implementation as a plugin for development environments may allow detection of real-time vulnerability during smart contract development, that potentially catches security issues earlier in the development cycle.

[0020] FIG. 1 is a block diagram that illustrates an exemplary network environment for vulnerability or bug detection in executable code of distributed ledger using deep learning model, in accordance with an embodiment of the disclosure. With reference to FIG. 1 , there is shown a block diagram of a network environment 100. The network environment100 may include an electronic device 102, a server 104, communication network 108. The electronic device 102 may include a deep learning model 110. The electronic device 102may be communicatively coupled to a distributed ledger 112. The distributed ledger 112 may include an executable code (for example, a first executable code 114 and a second executable code 116). The server 104 may include a database 106. The electronic device 102 (and / or the distributed ledger 112), the server 104, and the database 106, may be communicatively coupled to the communication network 108.

[0021] The electronic device 102 may include suitable logic, circuitry, interfaces, and / or code that may be configured to receive the first executable code 114 associated with the distributed ledger 112. The electronic device 102 may be configured to extract elements of the first executable code 114. The extraction of elements may breakdown the executable code into fundamental components, such as functions, statements, and variables. Based on the isolation of these elements, the electronic device 102 may perform a granular level analysis, which may be essential to identify specific vulnerabilities within the executable code (for example, the first executable code 114). The electronic device 102 may determine a code embedding associated with the elements of the first executable code 114. The electronic device 102 may use the code embedding to transform the code elements into a numerical format that can be processed by the deep learning model 110. This may ensure that a semantic meaning and relationships between code elements is preserved for more accurate analysis and detection of vulnerabilities.

[0022] The electronic device 102 may apply a self-attention model and a hierarchical cross-attention model on the code embedding. The self-attention model may allow the electronic device 102 to weigh an importance of different code elements in relation to each other in the first executable code 114, while the hierarchical cross-attention model may focus on different levels of the code structure. This approach may ensure that the analysis captures both local and global contexts within the first executable code 114, that may improve a precision of vulnerability detection. The electronic device 102 may determineattention weights for each of the elements associated with the first executable code 114, based on the application of the self-attention model and the hierarchical cross-attention model. Based on the assigned attention weights, the electronic device 102 may prioritize most critical parts of the first executable code 114 that may be more likely to contain vulnerabilities. This approach may enhance the efficiency and effectiveness of the vulnerability detection process. The electronic device 102 may train the deep learning model 110 to detect the vulnerabilities or bugs in the second executable code 116 associated with the distributed ledger 112. Examples of the electronic device 102 may include, but may not be limited to, a desktop, a tablet, a television (TV), a laptop, a computing device, a smartphone, a cellular phone, a mobile phone, and a consumer electronic (CE) device having a display.

[0023] The server 104 that may include suitable logic, circuitry, interfaces, and / or code configured to receive requests from the electronic device 102 to receive the first executable code 114 associated with the distributed ledger 112. The server 104 may be configured to extract the elements of the first executable code 114. The server 104 may be configured to receive the code embedding associated with the elements of the first executable code 114 and apply the self-attention model and the hierarchical cross-attention model. The server 104 may be configured to determine the attention weights for each of the elements associated with the first executable code 114. The server 104 may be configured to train the deep learning model 110 to detect the vulnerabilities or bugs in a second executable code 116 associated with the distributed ledger 112. The determination of the attention weights and training the deep learning model is explained further in detail, for example, in FIG. 3, FIG. 4, FIG. 5, FIG. 6 and FIG. 8.

[0024] The server 104 may execute operations through web applications, cloud applications, HTTP requests, repository operations, file transfer, and the like. Exampleimplementations of the servers 104 may include, but are not limited to, a database server, a file server, a web server, an application server, a mainframe server, a cloud computing server, or a combination thereof. In at least one embodiment, the server 104 may be implemented as a plurality of distributed cloud-based resources by use of several technologies that are well known to those ordinarily skilled in the art. A person with ordinary skill in the art will understand that the scope of the disclosure may not be limited to the implementation of the server 104 and the electronic device 102 as separate entities.

[0025] The database 106 may include suitable logic, circuitry, interfaces, and / or code configured to store information, such as, the first executable code 114 and the second executable code 116. In some cases, the database 106 may also store the deep learning model 110. Further, the database 106 may store instructions associated with operations of the electronic device 102. For example, the database 106 may store the code embeddings associated with the elements of the first executable code 114 to apply the self-attention model and the hierarchical cross-attention model. The database 106 may be stored or cached on a device or server, such as the server 104. Based on a request received from the electronic device 102, the device storing the database 106 may be configured to query the database 106 for certain information such as, the first executable code 114 and / or attention weights for each of the elements associated with the first executable code 114. In response, the device storing the database 106 may be configured to retrieve the queried information and transmit the retrieved information to the electronic device 102 to train the deep learning model 110 to detect vulnerabilities and bugs in executable code of the distributed ledger 112.

[0026] In some embodiments, the database 106 may be hosted on a server 104 located at same or different locations. The operations of the database 106 may be implemented using hardware including a processor, a microprocessor (e.g., to perform or controlperformance of one or more operations), a field-programmable gate array (FPGA), or an application-specific integrated circuit (ASIC). In some other instances, the database 106 may be implemented using software.

[0027] The communication network 108 may include a communication medium through which the electronic device 102 and the server 104 may communicate with each other. The communication network 108 may be a wired or wireless communication network. Examples of the communication network 108 may include, but are not limited to, Internet, a cloud network, Cellular or Wireless Mobile Network (such as Long-Term Evolution and 5thGeneration (5G) New Radio (NR)), satellite communication system (using, for example, low earth orbit satellites), a Wireless Fidelity (Wi-Fi) network, a Personal Area Network (PAN), a Local Area Network (LAN), or a Metropolitan Area Network (MAN). Various devices in the network environment 100 may be configured to connect to the communication network 108, in accordance with various wired and wireless communication protocols. Examples of such wired and wireless communication protocols may include, but are not limited to, at least one of a Transmission Control Protocol and Internet Protocol (TCP / IP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), Zig Bee, EDGE, IEEE 802.11 , light fidelity(Li-Fi), 802.16, IEEE 802.11 s, IEEE 802.11 g, multi-hop communication, wireless access point (AP), device to device communication, cellular communication protocols, and Bluetooth (BT) communication protocols.

[0028] The electronic device 102 may be communicatively coupled with the distributed ledger 112. The distributed ledger 112 may be a decentralized and distributed database system that may maintain an immutable record of data operations or transactions. A set of data operations may be grouped together as a block and may be further linked to a previous block of data operations to form a chain of a plurality of blocks. All blocks of dataoperations may be stored in a decentralized manner, whereby all participants or nodes store all the plurality of blocks. Further, the distributed ledger 112 may include an operating system which may allow for deployment of the executable codes including group of smart contracts between multiple parties, for example, a user and the electronic device 102.The distributed ledger 112 may be a chain of blocks which mat use accounts as state objects and a state of each account may be tracked by the chain. Herein, the accounts represent identities of users, mining nodes, or automated agents. All the blocks of data operations or the smart contract are associated with the accounts on the chain of blocks. By way of example, and not limitation, the distributed ledger 112 may be an Ethereum blockchain which may use accounts as state objects and a state of each account can be tracked by the Ethereum blockchain. Herein, the accounts represent identities of users, mining nodes, or automated agents. All the blocks of data operations or the smart contract are associated with the accounts on the Ethereum Blockchain. The scope of the disclosure may not be limited to the implementation of the distributed ledger 112 as the Ethereum blockchain, a Hyperledger blockchain, or a Corda blockchain. Other implementations of the distributed ledger 112 may be possible in the present disclosure, without a deviation from the scope of the present disclosure.

[0029] The deep learning model 110 may be a type of artificial neural network with multiple layers between the input and output layers. The neural network may have more than one hidden layer, which may allow the deep neural network to model the complex patterns and relationships in data. The structure of the deep learning model 110 may include input layer, hidden layer and output layer, the hidden layer may include one or more layers between the input and the output layers. These layers may perform various transformations and computations on the input data. Each layer may include units called neurons or nodes. The neurons in one layer may be connected to neurons in the next layerthrough weighted connections. Each connection between the neurons may be associated with weight, and each neuron may include a bias. The weights associated with parameters (for example, elements of the first executable codes) may be adjusted during training process to minimize the error in the network’s predictions. The activation functions may introduce non-linearity into the neural network or the deep learning model 110, enabling the neural network to learn the complex patterns. Common activation functions may include Rectified Linear Unit (ReLU), sigmoid, and tanh. The deep learning model 110 may be trained using large dataset. The training process may involve adjusting the weights and biases to minimize the difference between the network’s predictions and the actual outcomes. This may be typically done using techniques such as backpropagation and optimization techniques such as gradient descent. One of the key advantages of deep learning model 110 may be their ability to automatically learn and extract relevant features from raw data. This may reduce the need for manual feature engineering. There may be a various type of deep learning model 110 such as convolution neural networks, recurrent neural networks, generative adversarial networks, autoencoders and the like.

[0030] The examples of the deep learning model 110 may include, but are not limited to, models such as, Bidirectional Encoder Representations from Transformers (BERT), Robustly Optimized BERT Pretraining Approach (RoBERTa), Generative Pre-trained Transformer (GPT), Text-to-Text Transfer Transformer (T5), Bidirectional and Auto- Regressive Transformers (BART), Embeddings from Language Models (ELMo), Universal Language Model Fine-tuning (ULMFiT), CodeBERT, GraphCodeBERT, Programming Language BART (PLBART), CodeT5, Distilled BERT (DistilBERT), XLNet, and Transformer-XL. In some cases, the deep learning model 110 may be a combination or adaptation of these models, tailored for specific tasks related to code analysis and vulnerability detection in distributed ledger technologies. The deep learning model 110may, in some respects, incorporate a combination of self-attention and hierarchical attention mechanisms to capture different levels of code structure to analyze smart contracts for potential vulnerabilities.

[0031] In operation, the electronic device 102 may be configured to receive the first executable code 114 associated with the distributed ledger 112. The first executable code 114 may include, for example, a source code of smart contracts associated with the distributed ledger 112. The smart contract may correspond to a source code program / application coded in, for example, solidity, viper, chain code, and the like. The distributed ledger 112 may be a type of database that is consensually shared, replicated, and synchronized across multiple sites, institutions, or geographies. The first executable code 114 may be statically analyzed, and manual labeling may be performed. The static analysis tools may be software applications that analyze the source code or compiled code without executing the source code. The static analysis tools may be used to identify potential vulnerabilities, bugs, code quality issues, and adherence to coding standards. The static analysis may be performed based on an examination of the code’s structure, syntax, and semantics to detect issues that may lead to runtime errors or security vulnerabilities. The manual labeling may include a manual review and annotation of data to create a labeled dataset.

[0032] In an embodiment, the electronic device 102 may extract elements of the first executable code 114. The elements of the first executable code 114 may include syntactical structure information, semantic role information, data-type information, data- scope information, data-context information, control flow features, token-level features, cross-module or dependency features, and the like.

[0033] In an embodiment, the electronic device 102 may determine the code embedding associated with the elements of the first executable code 114. The code embedding maybe determined based on word embeddings and positional embeddings. The word embeddings may be determined based on a tokenization of the first executable code 114 to determine code tokens. Based on the determined code tokens, the word embedding may be determined. The positional embedding associated with the first executable code 114 may be determined based on the word embeddings.

[0034] In an embodiment, the electronic device 102 may apply a self-attention model and a hierarchical cross-attention model on the code embedding. The application of the self-attention model may be based on an intra-level attention. The application of the hierarchical cross-attention model may be based on an inter-level attention. The intra-level attention and the inter-level attention associated with the elements of the first executable code 114 may be determined.

[0035] In an embodiment, the electronic device 102 may determine attention weights for each of the elements associated with the first executable code 114, based on the application of the self-attention model and the hierarchical cross-attention model. The attention weights may be categorized as. for example, a set of first weights, a set of second weights, a set of third weights, and a set of fourth weights. The set of first weights may be associated with the relationship among a set of functions in a contract of the first executable code 114. The second weights may be associated with a relationship among the contract and the set of functions. The set of third weights may be associated with a relationship among a set of first statements in a first function of the set of functions and the set of fourth weights may be associated with a relationship among the set of first statements in the first function and a set of second statements in a second function of the set of functions. The attention weights may be determined based on the aggregated weights. The aggregated weights may be determined based on the set of first weights, theset of second weights, the set of third weights, and the set of fourth weights. The attention weights are described further, for example, in FIG. 6.

[0036] In an embodiment, the electronic device 102 may train the deep learning model 110 configured to detect at least one of vulnerabilities or bugs in a second executable code 116 associated with the distributed ledger 112. The deep learning model 110 may correspond to an optimized code Bidirectional encoder representation from transformers (BERT) model. The vulnerabilities may correspond to, for example, but not limited to executable code vulnerabilities, mining pool vulnerabilities, consensus mechanism vulnerabilities, network vulnerabilities, and client vulnerabilities. The deep learning model 110 is described further, for example, in FIG. 3, FIG. 4 and FIG. 5.

[0037] FIG. 2 is a block diagram that illustrates an electronic device for vulnerability or bug detection in executable code of distributed ledger using deep learning model, in accordance with an embodiment of the disclosure. FIG. 2 is explained in conjunction with elements from FIG. 1 . With reference to FIG. 2, there is shown a block diagram 200 of the electronic device 102. The electronic device 102 may include a circuitry 202, a memory 204, an input / output (I / O) device 206, and a network interface 208. In at least one embodiment, the I / O device 206 may also include a display device 206A. In at least one embodiment, the memory 204 may include the deep learning model 110. The circuitry 202 may be communicatively coupled to the memory 204, the I / O device 206, the network interface 208, through a wired or wireless communication medium associated with the electronic device 102.

[0038] The circuitry 202 may include suitable logic, circuitry, and interfaces that may be configured to execute program instructions associated with different operations to be executed by the electronic device 102. The operations may include reception of the first executable code 114 associated with the distributed ledger 112 and extraction of elementsof the first executable code 114. The operations may further include determination of the code embedding associated with the elements of the first executable code 114 and application of the self-attention model on the code embedding. The operations may further include application of the hierarchical cross-attention model on the code embedding and determination of the attention weights for each of the elements associated with the first executable code 114, based on the application of the self-attention model and the hierarchical cross-attention model. The operations may further include training the deep learning model 110 configured to detect at least one of vulnerabilities or bugs in the second executable code 116 associated with the distributed ledger 112. The deep learning model 110 may be trained based on the attention weights. The determination of self-attention model and hierarchical cross-attention model, and determination of the attention weights may be further described in FIG. 3, FIG. 4, FIG. 5, FIG. 6, and FIG. 8.

[0039] The circuitry 202 may include one or more specialized processing units, which may be implemented as an integrated processor or a cluster of processors that perform the functions of the one or more specialized processing units, collectively. The circuitry 202 may be implemented based on a number of processor technologies known in the art. Examples of implementations of the circuitry 202 may be an x86-based processor, a Graphics Processing Unit (GPU), a Reduced Instruction Set Computing (RISC) processor, an Application-Specific Integrated Circuit (ASIC) processor, a Complex Instruction Set Computing (CISC) processor, a microcontroller, a central processing unit (CPU), and / or other computing circuits.

[0040] The memory 204 may include suitable logic, circuitry, interfaces, and / or code that may be configured to store the program instructions to be executed by the circuitry 202. The program instructions stored on the memory 204 may enable the circuitry 202 to execute operations of the circuitry 202 (and / or the electronic device 102). In at least oneembodiment, the memory 204 may store the first executable code 114, the second executable code 116, elements of the first executable code 114. The electronic device 102 may determine the code embedding associated with the elements of the first executable code 114. The memory 204 may further store the attention weights and the deep learning model 110. Examples of implementation of the memory 204 may include, but are not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Hard Disk Drive (HDD), a Solid- State Drive (SSD), a CPU cache, and / or a Secure Digital (SD) card.

[0041] The I / O device 206 may include suitable logic, circuitry, interfaces, and / or code that may be configured to receive input and provide an output based on the received input. For example, the I / O device 206 may receive the first executable code 114. In an example, the first executable code 114 may be received as a user-input from a user. Examples of the I / O device 206 may include, but are not limited to, a touch screen, a keyboard, a mouse, a joystick, a microphone, the display device 102B, and a speaker. Examples of the I / O device 206 may further include braille I / O devices, such as, braille keyboards and braille readers.

[0042] The I / O device 206 may include the display device 206A. The display device 206A may include suitable logic, circuitry, and interfaces that may be configured to receive inputs from the circuitry 202 to render on a display screen, for example, the first executable code 114. The display device 206A may further render an indication that whether the first executable code 114 is vulnerable or includes bugs. In at least one embodiment, the display device 206A may be at least one of a resistive touch screen, a capacitive touch screen, or a thermal touch screen. The display device 206A may be realized through several known technologies such as, but not limited to, at least one of a Liquid CrystalDisplay (LCD) display, a Light Emitting Diode (LED) display, a plasma display, or an Organic LED (OLED) display technology, or other display devices.

[0043] The network interface 208 may include suitable logic, circuitry, and interfaces that may be configured to facilitate communication between the circuitry 202, the I / O device 206, and the memory 204, via the communication network 108. The network interface 208 may be implemented by using various known technologies to support wired or wireless communication of the electronic device 102 with the communication network 108. The network interface 208 may include, but is not limited to, an antenna, a radio frequency (RF) transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a coder-decoder (CODEC) chipset, a subscriber identity module (SIM) card, or a local buffer circuitry.

[0044] The network interface 208 may be configured to communicate via wireless communication with networks, such as the Internet, an Intranet, or a wireless network, such as a cellular telephone network, a wireless local area network (LAN), a short-range communication network, and a metropolitan area network (MAN). The wireless communication may use one or more of a plurality of communication standards, protocols and technologies, such as Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), wideband code division multiple access (W-CDMA), Long Term Evolution (LTE), 5thGeneration (5G) New Radio (NR), code division multiple access (CDMA), time division multiple access (TDMA), Bluetooth, Wireless Fidelity (WiFi) (such as IEEE 802.11a, IEEE 802.11 b, IEEE 802.11g or IEEE 802.11 n), voice over Internet Protocol (VoIP), light fidelity (Li-Fi), Worldwide Interoperability for Microwave Access (Wi-MAX), a near field communication protocol, and a wireless pear-to-pear protocol.

[0045] FIG. 3 is a diagram that illustrates an exemplary execution pipeline for vulnerability or bug detection in executable code of distributed ledger using deep learning model, in accordance with an embodiment of the disclosure. FIG. 3 is explained in conjunction with elements from FIG. 1 and FIG. 2. With reference to FIG. 3, there is shown an exemplary execution pipeline 300 for the electronic device 102 for vulnerability or bug detection in the executable code (for example, the first executable code 114) of the distributed ledger 112. The execution pipeline 300 may include operations 302 to 314 executed by a computing device, such as, the electronic device 102 of FIG. 1 or the circuitry 202 of FIG. 2.

[0046] At 302, the first executable code associated with the distributed ledger may be received. The circuitry 202 may be configured to receive the first executable code 114 associated with the distributed ledger 112. The first executable code 114 may include, but is not limited to, smart contracts, chaincodes, scripts, and decentralized applications. The first executable code 114 may be used to define and enforce the rules and logic for transactions and interactions between participants or the users. The first executable code 114 may take various forms, each serving different purposes and offering different levels of functionality and flexibility. In an example, the circuitry 202 may receive a user-input including an address of a distributed ledger wallet / account associated with an executable code associated with the distributed ledger 112. The circuitry 202 may extract the executable code (e.g., the first executable code 114) from the address provided by the user as the user-input and store the extracted executable code on the memory 204.

[0047] At 304, data preprocessing may be performed. The circuitry 202 may be configured to preprocess the data. The data may include the first executable code 114. The data preprocessing may include preparation of the data for use in distributed ledger databases such as blockchain. The data preprocessing may ensure that the data is clean,consistent, and suitable for storage and processing on the distributed ledger 112. The data preprocessing may include data collection, data cleaning, data transformation, data encryption and the like. The data collection may include a collation of data from various sources that need to be recorded on the distributed ledger 112. The data may include transactional data, sensor data, financial records, supply chain information, and the like. The data cleaning may include removal of inconsistencies, errors, or irrelevant information. The data cleaning may include removing duplicates, handling missing values, correction of errors and the like. The data transformation may include transformation of the data into a format that is compatible with the distributed ledger 112. This may involve conversion of data types, normalization of values and encoding of information. The data validation may include a check to ensure that the data conforms to predefined rules and constraints. This ensures that only valid and authorized data is recoded on the distributed ledger 112. The data validation may include schema validation, business rules validation, integrity checks, and the like. The data encryption may encrypt the sensitive data to ensure privacy and security. The encryption of the data protects the data from unauthorized access and tampering. In an embodiment, the data preprocessing may include many other steps based on the type of data needs to be processed. Detailed description of such other steps is omitted here for the sake of brevity; however, the disclosure should not be limited to only the described steps of data preprocessing.

[0048] At 306, a code embedding associated with the elements of the first executable code may be determined. The circuitry 202 may be configured to determine the code embedding associated with the elements of the first executable code 114. This process may involve three key sub-steps: a tokenization process (306A), a word embeddings generation process (306B), and a positional embeddings generation process (306C), eachcontributing to the creation of a comprehensive numerical representation of the code (i.e. , the first executable code 114).

[0049] In the tokenization process (306A), the circuitry 202 may break-down the first executable code 114 into smaller units called tokens. Each token may include keywords, operators, identifiers, literals, or other meaningful elements within the code. For example, in a smart contract written in “Solidity”, the statement "uint256 public balance;" may be tokenized into "uint256", "public", "balance", and The circuitry 202 may perform a lexical analysis to identify and extract such and other tokens from the first executable code 114. The process of tokenization may be crucial for preparation of the code for further analysis, as it breaks-down complex structures into more manageable units.

[0050] In the word embeddings generation process (306B), the circuitry 202 may determine word embeddings from the extracted tokens. This process may involve conversion of the tokens into dense numerical vectors that capture semantic information. For instance, the token "balance" may be represented as a vector [0.2, -0.5, 0.8, ...] in a multi-dimensional space. The circuitry 202 may utilize various techniques for generation of these embeddings, such as one-hot encoding, word2vec, or more advanced methods like Global Vector for Word Representation (GloVe), BERT (Bidirectional Encoder Representations from Transformers). These embedding techniques may allow the system to capture relationships between different code elements, that potentially enable more nuanced vulnerability detection.

[0051] In the positional embeddings generation process (306C), the circuitry 202 may determine information about a position of each token in a sequence of words, which may be crucial to understand a structure and flow of the code. The circuitry 202 may employ techniques such as absolute position encoding or sinusoidal position encoding to achieve this. For example, in absolute position encoding, each position may be assigned a uniquevector, while sinusoidal encoding may use sine and cosine functions to represent positions. These positional embeddings may help to distinguish between identical tokens appearing in different parts of the code, to potentially improve the accuracy of vulnerability detection. The circuitry 202 may determine the code embedding of the first executable code 114 based on the generated tokens, the generated word embeddings, and the generated positional embeddings.

[0052] At 308, a self-attention model may be applied to the code embedding. The circuitry 202 may be configured to apply the self-attention model on the code embedding. In some respects, the application of the self-attention model may be based on an intralevel attention mechanism. The intra-level attention may be determined associated with the elements of the first executable code 114. The self-attention model may include, but may not be limited to, contract-level attention and function-level attention. The selfattention model may determine attention within levels of the first executable code 114.

[0053] The contract-level attention model may focus on the overall structure of the smart contract. It may capture the importance of each function in the context of the first executable code 114 or contract. For instance, in a smart contract with multiple functions, the self-attention model may assign weights to each function based on its significance within the contract. For example, a function that handles critical operations like fund transfers or state changes might receive higher attention weights compared to a utility function or a simple getter function. In some cases, the contract-level attention model may employ a transformer-based architecture, where each function is treated as a token in the sequence. The contract-level attention model may use multi-head attention mechanisms to capture different aspects of inter-function relationships. For example, one attention head may focus on data flow between functions, while another may prioritize control flow dependencies.

[0054] The function-level attention model may focus on the individual statements within each function. This model may capture the importance of different statements and their roles in the function's logic. The attention weights at this level may determine the relative importance of each statement within the function. For instance, within a function that processes a transaction, the attention model may assign weights to statements such as condition checks, state updates, and event emissions. Statements that perform critical checks or update important state variables may receive higher attention weights. In some implementations, the function-level attention model may utilize recurrent neural network (RNN) architectures, such as Long Short-Term Memory (LSTM) or Gated Recurrent Units (GRU), to capture the sequential nature of code statements. The function-level attention model may be augmented with attention mechanisms to focus on relevant parts of the input sequence when producing each output.

[0055] The self-attention model may also incorporate a statement-level attention mechanism. This fine-grained attention may focus on individual elements within statements, such as variables, operators, and literals. For example, in a statement like "require(msg. sender == owner, "Not authorized");" the model may assign higher attention weights to the "msg. sender" and "owner" variables, recognizing their importance in the authorization check. In some respects, the self-attention model may employ a hierarchical attention mechanism that combines attention at multiple levels. This approach may allow the model to capture both local and global context simultaneously. For instance, it may first apply attention at the statement level, then use the results to inform attention at the function level, and finally aggregate this information for contract-level attention.

[0056] The application of such attention models may significantly enhance an ability of the disclosed technique to detect vulnerabilities. By focusing on the most relevant parts of the code, the self-attention model may more effectively identify potential security risks. Forexample, it may be particularly adept at detection of reentrancy vulnerabilities based on a close attention to state changes before external calls.

[0057] In some implementations, the self-attention model may be trained using a combination of supervised and unsupervised learning techniques. The model may be pretrained on a large corpus of smart contracts to learn general code patterns, then fine-tuned on a dataset of known vulnerabilities to specialize in security analysis. The self-attention model may also incorporate domain-specific knowledge about common smart contract vulnerabilities. This may be achieved through techniques such as attention biasing, where the model's attention is guided towards code patterns known to be associated with specific types of vulnerabilities.

[0058] In some cases, the self-attention model may be extended to incorporate crosscontract attention mechanisms. This extension may allow the model to analyze interactions between multiple contracts, potentially uncovering vulnerabilities that arise from complex contract interactions in decentralized applications (DApps). The output of the self-attention model may be a set of attention weights for each element of the code, representative of a relative importance in the context of vulnerability detection. These weights may be used in subsequent stages of the analysis pipeline, potentially informing the operation of other components of the deep learning model 110.

[0059] At 310, a hierarchical cross-attention model may be applied to the code embedding. The circuitry 202 may be configured to apply the hierarchical cross-attention model on the code embedding. In some respects, the application of the hierarchical crossattention model may be based on an inter-level attention mechanism. The inter-level attention may be determined in association with the elements of the first executable code 114. The hierarchical cross-attention model may include, but may not be limited to, weights that capture relationships between the entire contract and its constituent functions, weightsthat capture relationships between functions and their contained statements, and weights that capture relationships between different contracts in a multi-contract system.

[0060] The hierarchical cross-attention model may employ a multi-head attention mechanism, where each head may focus on different aspects of the code structure. For example, one attention head may focus on data flow between different levels of the code hierarchy, while another may prioritize control flow dependencies. This multi-head approach may allow the model to capture various types of relationships simultaneously, potentially improving its ability to detect complex vulnerabilities.

[0061] In some implementations, the hierarchical cross-attention model may utilize a transformer-based architecture, where each level of the code hierarchy (contract, function, statement) is treated as a separate sequence. The hierarchical cross-attention model may then apply self-attention within each level and cross-attention between levels. For instance, when analyzing a function, the model may first apply self-attention to capture relationships between statements within the function, then apply cross-attention to relate the function-level representation to the contract-level context.

[0062] The hierarchical cross-attention model may capture the relationship between the entire contract and its constituent functions. This may help understand how the overall contract structure influences individual functions and vice versa. The attention weights may indicate the influence of the contract-level context on each function and the contribution of each function to the overall contract. For example, in a smart contract implementing a token system, the hierarchical cross-attention model may capture how the initialization of state variables at the contract level affects the behavior of functions that modify token balances. It may also identify critical functions that contribute significantly to the security and functionality of the smart contract, such as transfer functions or access control mechanisms.

[0063] Furthermore, the hierarchical cross-attention model may capture the relationship between functions and their contained statements. This may help understand how the logic within individual statements contributes to the overall function behavior and how functions interact with each other. The attention weights may capture the influence of the functionlevel context on individual statements and the contribution of each statement to the function's logic. For instance, within a function that processes a complex financial transaction, the hierarchical cross-attention model may capture how a series of conditional checks influences subsequent state updates, external calls, and event emissions. It might also capture how the outcome of one function, such as a permission check, affects the execution path of another function that depends on the permission status.

[0064] In some cases, the hierarchical cross-attention model may be extended to analyze relationships between different contracts in a multi-contract system. This may be particularly useful for detecting vulnerabilities that arise from complex interactions between multiple smart contracts in decentralized applications (DApps). For example, the model may capture how a vulnerability in one contract's access control mechanism could potentially be exploited through a series of inter-contract calls. The hierarchical crossattention model may also incorporate temporal aspects of code execution. By analyzing the sequence of function calls and state changes across different levels of the code hierarchy, the model may identify potential time-dependent vulnerabilities, such as those related to transaction ordering or block timestamp manipulation.

[0065] In some implementations, the hierarchical cross-attention model may be combined with graph neural networks (GNNs) to better capture the structural relationships within the code. The contract structure may be represented as a graph, with nodes representing different code elements (contracts, functions, statements) and edges representing their relationships. The GNN may then process this graph structure inconjunction with the attention mechanisms to provide a more comprehensive analysis of the code's security properties.

[0066] The output of the hierarchical cross-attention model may be a set of attention weights that represent the importance and relationships between different elements of the code across various levels of abstraction. The set of attention weights may be used in subsequent stages of the analysis pipeline, which may be utilized by the deep learning model 110 to provide interpretable insights into the detected vulnerabilities. In an embodiment, the set of attention weights may include, but are not limited to, a set of first weights associated with a relationship among a set of functions in a contract of the first executable code 114, a set of second weights associated with a relationship among the contract and the set of functions, a set of third weights associated with a relationship among a set of first statements in a first function of the set of functions, and a set of fourth weights associated with a relationship among the set of first statements in the first function and a set of second statements in a second function of the set of functions. The aggregated weights may be determined based on the set of first weights, the set of second weights, the set of third weights, and the set of fourth weights. The attention weights may correspond to the aggregated weights.

[0067] At 312, the deep learning model 110 may be trained to detect the at least one of vulnerabilities or bugs in a second executable code 116 associated with the distributed ledger 112. The deep learning model 110 may be trained based on the attention weights. The circuitry 202 may be configured to train the deep learning model 110 to detect the at least one of vulnerabilities or bugs in the second executable code 116 associated with the distributed ledger 112. The distributed ledger 112 may correspond to, but not limited to, the private distributed ledger, the public distributed ledger, and the hybrid distributed ledger.

[0068] At step 312, a deep learning model may be trained to detect at least one of vulnerabilities or bugs in a second executable code associated with a distributed ledger. The circuitry 202 may be configured to train the deep learning model 110 to detect the at least one of vulnerabilities or bugs in the second executable code 116 associated with the distributed ledger 112. The distributed ledger 112 may correspond to, but not limited to, the private distributed ledger, the public distributed ledger, and the hybrid distributed ledger. The circuitry 202 may be configured to determine attention weights for each of the code elements associated with the first executable code 114, based on the application of the self-attention model and the application of the hierarchical cross-attention model. The attention weights may help prioritize certain code elements that may be more likely to contain vulnerabilities. For example, the electronic device 102 may assign higher weights to functions that handle token transfers or modify state variables, as these may often be targets for exploitation. By learning from these weighted examples, the deep learning model 110 may improve its ability to detect similar patterns in future analyses.

[0069] In some implementations, the training process may involve a multi-stage approach. Initially, the model may be pre-trained on a large corpus of smart contracts to learn general code patterns and structures. This pre-training phase may utilize unsupervised learning techniques, such as masked language modeling or next token prediction, to build a foundational understanding of smart contract syntax and semantics. Following the pre-training, the deep learning model 110 may undergo fine-tuning on a dataset of known vulnerable and secure smart contracts. This supervised learning phase may allow the deep learning model 110 to specialize in identification of specific types of vulnerabilities. The training data may include a diverse range of smart contracts associated with various blockchain platforms and programming languages, to ensure a generalizability of the deep learning model 110.

[0070] The training process may incorporate techniques such as curriculum learning, where the model is initially trained on simpler, more obvious vulnerabilities before progressing to more complex, subtle security issues. This approach may help the model build a hierarchical understanding of vulnerabilities, from basic coding errors to sophisticated attack vectors. In some cases, the training may utilize adversarial examples to improve a robustness of the deep learning model 110. These examples may include slightly modified versions of known vulnerable contracts, designed to test an ability of the deep learning model 110 to detect variations of common exploits. For instance, the electronic device 102 may generate variants of reentrancy vulnerabilities with different code structures to ensure the model can identify the underlying pattern regardless of its specific implementation.

[0071] The training process may also incorporate domain-specific knowledge through techniques such as transfer learning or knowledge distillation. For example, the deep learning model 110 may be initialized with weights from a pre-trained model that has been exposed to a wide range of software vulnerabilities, not limited to, smart contracts. This approach may help the model leverage general security principles while adapting to the specific nuances of blockchain environments. The deep learning model 110 may be trained to detect a wide range of vulnerabilities, including but not limited to, reentrancy attacks, integer overflow / underflow, unchecked external calls, and access control issues. For each vulnerability type, the deep learning model 110 may learn to recognize specific code patterns and contextual clues that may indicate potential security risks.

[0072] At 314, detected vulnerabilities may be output. The circuitry 202 may be configured to receive the detected vulnerabilities. The circuitry 202 may apply the deep learning model 110 on the second executable code 116 to detect the vulnerabilities in the second executable code 116. The circuitry 202 may render information related to thedetected vulnerabilities on the display device 206A. This information related to the detected vulnerabilities may include a comprehensive list of potential vulnerabilities, their precise locations in the code, severity ratings, and detailed explanations of each issue. The information may be rendered in various output formats and mechanisms to effectively communicate vulnerability analysis results to developers and security teams. For instance, the circuitry 202 may generate a structured report that categorizes vulnerabilities based on their severity levels, such as critical, high, medium, and low. Each vulnerability entry in the report may include, but is not limited to, a vulnerability type and description, an affected code location (file name, line numbers, function names), potential impact on the smart contract (e.g., the second executable code 116) or the distributed ledger (e.g., the distributed ledger 112), exploitation scenarios, recommended fixes or mitigation strategies, and code snippets that highlight the vulnerable sections

[0073] FIG. 4 is a diagram that illustrates an exemplary architecture of deep learning model for vulnerability or bug detection in executable code of distributed ledger, in accordance with an embodiment of the disclosure. FIG. 4 is explained in conjunction with elements from FIG. 1 , FIG. 2, and FIG. 3. With reference to FIG. 4, there is shown an exemplary architecture 400 of the deep learning model 110 for vulnerability or bug detection in the first executable code 114 of the distributed ledger 112. The deep learning model 110 may receive a tokenized text input 402, The architecture of the deep learning model 110 may include a token embedding layer 404, a positional embedding layer 406, a first dropout layer 408, a first layer normalization (layerNorm) 410, a hierarchical crossattention model 412, a second dropout layer 414, a second layer normalization (layerNorm) 416, a feed forward layer 418, a third dropout layer 420, a final layer normalization (layerNorm) 422, and a linear output layer 424. The components of the deeplearning model 110 may be arranged in a sequential order, with each component processing an output of a previous component.

[0074] The tokenized text input 402 may represent a text of the executable code (for example, the first executable code 114) that has been segmented into smaller, meaningful units called tokens. This tokenization process may involve breaking down the code into individual keywords, operators, identifiers, or other syntactic elements. For instance, a smart contract function like "function transfer (address recipient, uint256 amount) public" might be tokenized into ["function", "transfer", "(", "address", "recipient", "uint256", "amount", ")", "public"]. Such granular representation may allow the deep learning model 110 to process the code at a fine-grained level, potentially enabling it to capture intricate patterns and relationships within the smart contract structure.

[0075] The token embedding layer 404 may convert each token into a dense vector representation. This process may transform discrete tokens into continuous vector spaces, that potentially capture semantic relationships between different code elements. For example, tokens like "uint256" and "int256" might have similar vector representations due to their related meanings in smart contract development. The embedding process may also help to handle out-of-vocabulary tokens, which may be particularly useful in analysis of novel or complex smart contract implementations.

[0076] The position embedding layer 406 may add information about the position of each token in the sequence. This positional information may be crucial to understand a structure and flow of the smart contract code. For instance, in a function definition, the position of parameters and their types may be significant to detect potential vulnerabilities related to parameter manipulation or type confusion. The combination of token embeddings and positional embeddings may allow the deep learning model 110 to capture both semantic and syntactic information about the code.

[0077] The first dropout layer 408 may randomly set a fraction of input units to zero during training. This technique may help prevent overfitting by reducing the deep learning model's reliance on specific features. In the context of smart contract analysis, this may improve an ability of the deep learning model 110 to generalize across different contract structures and coding styles. For example, it may help the deep learning model 110 to remain effective even when unconventional token arrangements or rare code patterns are encountered.

[0078] The first layer normalization 410 may normalize the input across the features of the first executable code 114. This normalization process may stabilize and accelerate the training process and ensure that the input features have similar scales. In smart contract analysis, this may be particularly important to deal with contracts of varying complexity and length, as it may help maintain consistent performance across different input distributions.

[0079] The hierarchical cross-attention model 412 may capture interactions between different levels of the model, such as token-level, function-level, and contract-level representations. This multi-level analysis may allow the deep learning model 110 to focus on relevant parts of the input sequence at different scales. For instance, when analyzing a potential reentrancy vulnerability, the model may simultaneously consider low-level details like state variable updates and high-level patterns of external function calls.

[0080] The dropout layers (414, 420) and layer normalizations (416, 422) may further regularize the deep learning model 110 and stabilize training. These components may work together to prevent overfitting and ensure that the deep learning model 110 remains robust during analysis of diverse smart contract implementations.

[0081] The feed forward layer 418 may apply non-linear transformations to the data, that potentially allows the model to learn more complex patterns. This may be particularlyimportant to detect sophisticated vulnerabilities that involve intricate interactions between different parts of the smart contract code.

[0082] The linear output layer 424 may process the encoded representations to detect vulnerabilities or bugs. This layer may act as a classification component, potentially outputting probabilities for the presence of various types of vulnerabilities. For example, it may assign probabilities to categories such as reentrancy, integer overflow, or access control issues based on the processed input.

[0083] In some implementations, the architecture may be extended to include additional components such as residual connections or multi-head attention mechanisms. These enhancements may potentially improve an ability of the deep learning model 110 to capture long-range dependencies in the smart contract code or to focus on multiple aspects of the code simultaneously.

[0084] In some embodiment, a plurality of dropout layers may be used in the deep learning model 110 for vulnerability or bug detection. The dropout layers (such as a first dropout layer, a second dropout layer, a third dropout layer) used in FIG. 4 is not limited to the “3” layers. In an embodiment, the dropout layers may be placed between different layers such as the dropout layer may be placed between the first LayerNorm 410 and the hierarchical cross attention model 412. In an embodiment, the layers 410 to 420 may correspond to a hierarchical block of the deep learning model 110 of the disclosure.

[0085] The deep learning model 110 may also be adapted to handle multi-modal inputs, based on a combination of code analysis with other sources of information such as transaction histories or gas usage patterns. This multi-modal approach may provide a more comprehensive view of potential vulnerabilities, considering both static code properties and dynamic execution behaviors.

[0086] By processing smart contract code through this sophisticated architecture, the deep learning model 110 may be configured to detect a wide range of vulnerabilities, from common issues like unprotected self-destruct calls to more subtle problems like transaction ordering dependencies. The hierarchical nature of the deep learning model 110 may allow it to consider vulnerabilities at multiple scales, that potentially identifies issues that arise from the interaction of seemingly unrelated code sections.

[0087] FIG. 5 is a diagram that illustrates an exemplary architecture for hierarchical network for vulnerability or bug detection in executable code of distributed ledger, in accordance with an embodiment of the disclosure. FIG. 5 is explained in conjunction with elements from FIG. 1 , FIG. 2, FIG. 3, and FIG. 4. With reference to FIG. 5, there is shown an exemplary architecture 500.

[0088] In an embodiment, the first executable code 114 or source code of smart contracts 502 may be received as an input. Elements of the first executable code 114 may be extracted. The source code may be a set of instructions written in a programming language that defines the rules and behaviors of the smart contract. The first executable code 114 may be self-executing contract with terms of the agreement directly written into the code. The first executable code 114 may be run on blockchain platforms (e.g., the distributed ledger 112) and automatically enforced and executed when the terms of the smart contract and predefined conditions are met. The elements may include, but are not limited to, syntactical structure information, semantic role information, data-type information, data-scope information, data-context information, control flow features, tokenlevel features, and cross-module or dependency features.

[0089] The source code (for example, the first executable code 114) may be fed to a static analysis tool 504 and a manual labelling model 506. The static analysis tool 504 may be automated software tools that may analyze the first executable code 114 withoutexecuting it. The static analysis tool 504 may help identify potential vulnerabilities, bugs, and code quality issues. The manual labelling model 506 may involve human experts who may review and annotate the code to identify vulnerabilities and bugs. The manual labelling may be crucial to create high-quality training datasets for machine learning models. The manual labelling may be integrated into a hierarchical network for vulnerability detection. Human experts may perform an initial review of the smart contract code (for example, the first executable code 114) to identify, and label known vulnerabilities and bugs. This may help in creation of a ground truth dataset.

[0090] In an embodiment, a data preprocessing stage 514 may include operations from blocks 508 to 512 (including a data collection layer 508, a data cleaning layer 510, and a data encoding layer 512). The data collection layer 508 may gather data from various sources related to the smart contract, such as first executable code 114, transaction logs, historical vulnerability reports, and the like. The source code may be collected from repositories such as source code repositories, transaction log repositories, vulnerability report repositories and the like. The data collection may include, for example, automated scraping, APIs, manual collection. The automated scraping may use automatically scraped smart contract repositories and blockchain explorers. The APIs may fetch transaction logs and contract details. Reports from security advisories and research papers may be manually collected and reviewed. The data cleaning layer 510 may preprocess the collected data to ensure it is accurate, consistent and ready for analysis. For example, the data cleaning layer 510 may remove duplicates, normalize data, handle missing values, filter noise, and the like. A data encoding layer 512 may encode the cleaned data into a format suitable for machine learning models to detect vulnerabilities. The data encoding layer 512 may include, for example, token embedding, position encoding, and feature extraction. The token embedding may convert tokens from the first executable code 114into a dense vector representation, while the positional encoding may add positional information to the token embeddings to capture the order of tokens in the code. Further, the feature extraction may extract relevant features from the transaction logs and vulnerability reports, such as function call patters, gas usage, and the like. The data preprocessing stage 514 and the vulnerability detection tool is explained further with an exemplary technique 1 , described herein.#Technique 1# Step 1 : Data Collection and Preprocessing# Gather a diverse dataset of smart contracts (vulnerable and non-vulnerable instances) dataset = load_smart_contract_dataset()# Preprocess the dataset by tokenizing code into hierarchical levels preprocessed_data = preprocess_smart_contract_dataset(dataset)# Step 2: Model Training and Fine-Tuning# Load pre-trained transformer-based model and define hierarchical attention model optimized_transformer-based model = load_pretrained_transformer-based_model() hierarchical_model = define_hierarchical_attention_model()# Train the hierarchical model using fine-tuned Optimized Transformer-based model trained_model = train_hierarchical_model(hierarchical_model, optimized_Transformer- based model, preprocessed_data)# Step 3: Validation and Evaluation# Split dataset into training and validation setstrain_data, val_data = split_dataset(preprocessed_data)# Train the model on training data and validate on the validation set trained_model = train_model(trained_model, train_data) evaluation_metrics = validate_model(trained_model, val_data)# Step 4: Hyperparameter Tuning and Optimization optimized_model = hyperparameter_tuning(trained_model, train_data, val_data)# Step 5: Deployment and Integration# Develop an application interface or API deployed_model = deploy_model(optimized_model)# Step 6: Continuous Improvement and Updates# Continuously update the model with new data updated_model = update_model(deployed_model, new_data)# Step 7: Documentation and Support provide_documentation() offer_support_channels()

[0091] In an embodiment, the exemplary technique 1 may use architecture of deep learning model as described in FIG. 4. However, the existing method may use, for example, a CodeBERT model as the transformer-based model.

[0092] The deep learning model 110 may be a type of neural network with multiple layers. The deep learning model 110 may be designed to automatically learn hierarchicalrepresentations of data, which may make it particularly effective for complex tasks such as, vulnerability detection in the first executable code 114. The preprocessed data may be given as an input to the deep learning model 110. The deep learning model 110 may be a hierarchical attention model that applies a self-attention model and a hierarchical crossattention model to capture complex dependencies within the first executable code 114. The self-attention model may be used to capture relationships within the same function or code block. The self-attention model may allow the model to weigh the importance of different parts of the input sequence, and help it focus on relevant sections of the first executable code 114. The hierarchal cross-attention model may capture relationships across different functions and code blocks. The hierarchical cross-attention may allow the deep learning model 110 to consider interactions between different parts of the first executable code 114. The attention weights may be determined and aggregated from different layers to capture complex relationships. This may involve a combination of the attention weights from the self-attention model and the hierarchical cross-attention model.

[0093] The deep learning model 110 may be include an input layer. The input layer of the deep learning model 110 may receive the first executable code 114 and may serve as an entry point for the first executable code 114 into a neural network of the deep learning model 110. The input layer may take in the first executable code 114, which may be in various forms such as images, text, or numerical values. In the context of smart contracts, this may be a tokenized code or encoded representations of the code. The output layer may be a final layer of the deep learning model 110 that produces the predictions or results based on the learned patterns from previous layers. The output layer may generate final predictions of the deep learning model 110. The output layer may typically use an activation function to transform the raw output into a suitable format. The choice of activation function may depend on the type of problem being solved. In an example, for abinary classification task (e.g., detecting whether a smart contract has a vulnerability or not), the output layer might use a sigmoid activation function to produce a probability score between 0 and 1. For a multi-class classification task (e.g., categorizing different types of vulnerabilities), the output layer might use a softmax activation function to produce a probability distribution over multiple classes. For a regression task (e.g., predicting a numerical value), the output layer might use a linear activation function to produce a continuous output.

[0094] The output from the trained deep learning model 110 may be passed to testing model 516. The testing model 516 may include a model evaluation block 518, a block for selection and saving of a best model 520, a block for a test dataset 522, and a block for detection of vulnerable smart contract 524. The test dataset 522 may be received from a version control repository 526. The trained deep learning model 110 may be analyzed for the first executable code 114, such as the smart contract and identify potential security issues. The input may be, for example, the smart contract to be tested. The trained model may process the input code and generate predictions indicative of a presence or absence of vulnerabilities. The testing dataset 522 may be used to evaluate the performance of the trained model. The testing dataset 522 may include labeled smart contract code that the model may not have seen during its training. During the training process, multiple models or configurations may be tested. The trained deep learning model 110 may be used to analyze the smart contract code and identify vulnerabilities. The performance of the trained deep learning model 110 may be evaluated using a labeled dataset of the smart contract code. Multiple models may be trained, and the best-performing one may be selected, and saved for future use by the block 520 (i.e., the block for selection and saving of a best model). The trained deep learning model 110 may assess its performance using various metrics and perform error analysis. Further, the trained deep learning model 110 may beintegrated with version control systems to receive the latest smart contract code for continuous testing.

[0095] FIG. 6 is a diagram that illustrates an exemplary scenario for determination of attention weights for vulnerability or bug detection in executable code of distributed ledger using deep learning model, in accordance with an embodiment of the disclosure. FIG. 6 is explained in conjunction with elements from FIG. 1 , FIG. 2, FIG. 3, FIG. 4 and FIG. 5. With reference to FIG. 6, there is shown the exemplary scenario 600.

[0096] In an example, the scenario 600 may include 4 layers with 3 nodes each and an output layer (after the 4 layers), which may correspond to a concatenated attention 626. Though only three nodes are shown at each layer, the scenario 600 may not be so limited. The scenario 600 may include two nodes or more than three nodes at each layer without departure from the scope of the disclosure. For example, an initial input layer (or a first layer) may include a set of inputs, such as, a contract input 602, a function input 610, and a statement input 618. A second layer (that may follow the first layer) may include a set of embeddings, such as, a contract embedding 604, a function embedding 612, and a statement embedding 620. A third layer (that may follow the second layer) may include a contract Long Short-Term Memory (LSTM) 606, a function LSTM 614, and a statement LSTM 622. A fourth layer (that may follow the third layer and precede the output layer) may include a contract attention 608, a function attention 616, and a statement attention 624.

[0097] The smart contract code or the first executable code 114 may be received as an input. The smart code may be in the form of a text, representative of a source code of the smart contract. The input code or the contract input 602 (i.e. , a smart contract code as an input) may be tokenized into smaller units such as keywords, operators, identifiers, and literals. The tokenization may help to break down the code into manageable pieces forfurther processing. The contract embedding 604 may convert the tokenized smart contract code into dense representations that capture the semantic meaning of the tokens. Each token may be mapped to a dense vector using an embedding layer. This may help capturing the semantic relationships between different tokens. The contract Long Short- Term Memory (LSTM) 606 may process the embedded tokens to capture sequential dependencies and long-term relationships within the smart contract code. The embedded tokens may be fed into the contract LSTM 606, which processes the sequence of tokens and maintains a hidden state that captures the context of the first executable code 114. The LSTMs may be effective for determination of sequential dependencies, which may make them suitable for analysis of code where the order of tokens matters. The contract attention 608 may apply attention mechanisms to focus on relevant parts of the first executable code 114, that may enhance an ability of the deep learning model 110 to detect vulnerabilities. The self-attention model (for example, the contract attention 608) may be applied to the output of the contract LSTM 606 to weigh an importance of different tokens within the same function or code block. The hierarchical cross-attention model may be used to capture relationships between different functions and code blocks, which allows the deep learning model 110 to consider interactions across various hierarchal levels (e.g., a contract-level, a function-level, and a statement-level) associated with the first executable code 114. Attention weights may be calculated to determine the relevance of each token or code block, which may help the deep learning model 110 focus on critical parts of the code.

[0098] The function input 610 may focus on individual functions within the first executable code 114, that may allow the deep learning model 110 to analyze each function separately. An individual function may be extracted from the first executable code 114. The code within each function may be tokenized into smaller units (tokens). The tokens ofthe functions in the first executable code 114 may be converted into dense vector representations. The function embedding 612 may convert the tokenized function code into dense vector representations that capture the semantic meaning of the tokens. Each token within the function may be mapped to a dense vector using an embedding layer. This may help to capture the semantic relationships between different tokens. The function LSTM (Long Short-Term Memory) 614 may process the embedded tokens to capture sequential dependencies and long-term relationships within the function code. The embedded tokens may be fed into the function LSTM 614, which processes the sequence of tokens and maintains a hidden state that captures the context of the function. The function LSTM 614 may be effective for determination of sequential dependencies, which may make them suitable for analysis of code where the order of tokens matters. The function attention 616 may apply attention mechanisms to focus on relevant parts of the function code, which may enhance an ability of the deep learning model 110 to detect vulnerabilities. The self-attention models may be applied to the output of the function attention 616 to weigh an importance of different tokens within the same function. Attention weights may be calculated to determine the relevance of each token or statement within the function, which may help the deep learning model 110 to focus on critical parts of the code.

[0099] The statement input 618 may be the entry point for individual statements within the first executable code 114 into the deep learning model 110. Individual statements may be extracted from each function within the smart contract code. Each statement may be treated as a separate unit for analysis. The first executable code 114 may be tokenized within each statement into smaller units (tokens) such as keywords, operators, identifiers, and literals. The statement embedding 620 may convert the tokenized statement code into dense vector representations that capture the semantic meaning of the tokens. Each tokenwithin the statement may be mapped to a dense vector using the embedding layer. This may help to capture the semantic relationships between different tokens. The statement LSTM (Long Short-Term Memory) 622 may process the embedded tokens to capture sequential dependencies and long-term relationships within the statement code. The embedded tokens may be fed into a statement LSTM 622, which may process the sequence of tokens and maintains a hidden state that captures the context of the statement. The statement LSTM 622 may be effective for determination of sequential dependencies, which may make them suitable for analysis of code where the order of tokens matters. The statement attention 624 may apply attention mechanism (for example, the statement attention 624) to focus on relevant parts of the statement code, which may enhance an ability of the deep learning model 110 to detect vulnerabilities. Self-attention model may be applied to the output of the LSTM layer to weigh an importance of different tokens within the same statement. Attention weights may be calculated to determine the relevance of each token or part of the statement, which may help the deep learning model 110 to focus on critical parts of the first executable code 114. The attention weights may include at least one of the set of first weights associated with a relationship among the set of functions in the contract of the first executable code 114, the set of second weights associated with the relationship among the contract and the set of functions, the set of third weights associated with the relationship among the set of first statements in the first function of the set of functions, the set of fourth weights associated with the relationship among the set of first statements in the first function and the set of second statements in a second function of the set of functions, and the like. The aggregated weights may be determined based on the set of first weights, the set of second weights, the set of third weights, and the set of fourth weights. The attention weights may correspond to the aggregated weights.

[0100] FIGs. 7A, 7B and 7C are diagrams that illustrate exemplary user interfaces of DLT attack detection tool for determination vulnerability or bug detection in executable code of distributed ledger, in accordance with an embodiment of the disclosure. FIGs. 7A, 7B and 7C are described in conjunction with elements from FIG. 1 , FIG, 2, FIG. 3, FIG. 4, FIG. 5, and FIG. 6. With reference to FIG. 7A, there is shown an exemplary user interface 700. The user interface 700 includes a cryptocurrency interface 702, a dialog window 704, a deposit field 706, a balance display 708, an analyzer interface 710, a code input field 712, an analysis button 714, and a confirmation button 716.

[0101] The user interface 700 may provide a comprehensive platform for interaction with a cryptocurrency system and may include vulnerability detection capabilities. The cryptocurrency interface 702 may display transaction-related information, allowing users to monitor and manage their cryptocurrency holdings. In some cases, the cryptocurrency interface 702 may include real-time price updates, transaction history, and portfolio analytics.

[0102] The dialog window 704 may be positioned at a top of the user interface 700, that may serve as a communication channel for system messages and status updates. For example, the dialog window 704 may display notifications about successful transactions, network status, or security alerts. The confirmation button 716 within a pop-up window over the dialog window 704 may enable users to acknowledge system messages and proceed with operations, which may enhance user interaction and ensure that important information is not overlooked.

[0103] The deposit field 706 may allow users to input cryptocurrency amounts for transactions. This field may support various input formats, such as decimal values or percentage of total holdings, to accommodate different user preferences. The balance display 708 may show the current cryptocurrency store balance, which may provide userswith real-time information about their available funds. In some cases, the balance display 708 may update dynamically as transactions occur or as cryptocurrency values fluctuate.

[0104] The analyzer interface 710 may be a component of the vulnerability detection system, integrated directly into the cryptocurrency management interface. This integration may allow for seamless security checks during normal cryptocurrency operations. The code input field 712 within the analyzer interface 710 may enable users to paste smart contract code for analysis. This feature may be particularly useful for developers or users who may wish to interact with decentralized applications (DApps) to verify the security of smart contracts before the users engage with them.

[0105] The analysis button 714 may be positioned below the code input field 712, that may allow the users to initiate the vulnerability detection process. When activated, the analysis button 714 may trigger the deep learning model 110 to analyze the input code for potential security issues. The analysis process may leverage the hierarchical crossattention model 412 and other components of the execution pipeline 300 to perform a comprehensive security assessment.

[0106] In some cases, the user interface 700 may provide real-time vulnerability checking during smart contract development. For instance, as a developer types in code within the code input field 712, the deep learning model 110 may continuously analyze the input and provide an immediate feedback on potential security issues. This real-time analysis may be visualized through color-coding of the input text or through dynamic notifications appearing in the dialog window 704.

[0107] The user interface 700 may be implemented as a plugin for easy integration with existing development environments. For example, the user interface 700 may be designed to seamlessly integrate with popular integrated development environments (IDEs) used for blockchain development. This integration may allow developers to access the vulnerabilitydetection capabilities directly within their preferred coding environment and may streamline the development and security audit process.

[0108] With reference to FIG. 7B, another view of the user interface 700 for the cryptocurrency system with vulnerability detection capabilities is shown. The user interface 700 of FIG. 7B includes the previously described elements of FIG. 7A and introduces a notification message 718.

[0109] The notification message 718 may display results of the vulnerability analysis performed by the deep learning model 110. In the example shown in FIG. 7B, the notification message 718 indicates "No Vulnerabilities Detected" with an "Okay" button (denoted by 716). This feedback mechanism may provide users with clear and actionable information about the security status of the analyzed smart contract code.

[0110] The notification message 718 may be designed to present analysis results in a user-friendly manner. For instance, the notification message 718 may use color-coding to quickly convey the seventy of detected issues. In some cases, the notification message 718 may include expandable sections that provide more detailed information about specific vulnerabilities, including their potential impact and suggested remediation steps.

[0111] With reference to FIG. 7C, an additional view of the user interface 700 for the cryptocurrency system with vulnerability detection capabilities is shown. The user interface 700, introduces a notification dialog 720. The notification dialog 720 may appear within the user interface 700 to display system messages and analysis results to the user.

[0112] The notification dialog 720 may provide more detailed information about detected vulnerabilities or other system events. For example, the notification dialog 720 may show a message from a “local host” regarding a reentrancy detection, including an estimated accuracy percentage. This level of detail may be particularly valuable for developers and security professionals who require in-depth information about potential vulnerabilities.

[0113] In some cases, the notification dialog 720 may include interactive elements that allow users to explore detected vulnerabilities further. For instance, the notification dialog 720 may provide links to relevant documentation, code snippets that illustrate the vulnerability, or suggestions to fix the issue. This interactive approach may enhance the educational aspect of the tool, and help developers improve their smart contract security knowledge over time.

[0114] The user interface 700, as illustrated across FIG. 7A, FIG. 7B, and FIG. 7C, may provide a comprehensive environment for managing cryptocurrency transactions and performing security analysis on smart contracts. Based on an integration of such functions into a single interface, the electronic device 102 may streamline a workflow for blockchain developers and users and promote the development of more secure decentralized applications.

[0115] It should be noted that the user interface 700 of FIGs. 7A, 7B, and 7C are for exemplary purposes and should not be construed to limit the scope of the disclosure.

[0116] FIG. 8 is a flowchart that illustrates operations of an exemplary method for vulnerability or bug detection in executable code of distributed ledger using deep learning model, in accordance with an embodiment of the disclosure. FIG. 8 is described in conjunction with elements from FIG. 1 , FIG, 2, FIG. 3, FIG. 4, FIG. 5, FIG. 6, FIG. 7A, FIG. 7B, and FIG. 7C. With reference to FIG. 8, there is shown a flowchart 800. The exemplary method of the flowchart 800 may be executed by any computing system, for example, by the electronic device 102 of FIG. 1 . The exemplary method of the flowchart 800 may start at 802 and proceed to 804.

[0117] At 804, a first executable code associated with a distributed ledger may be received. The circuitry 202 may be configured to receive the first executable code 114 from various sources, such as the server 104 or the distributed ledger 112. In some cases, thefirst executable code may be a smart contract or chain code intended for deployment on the distributed ledger 112. The reception of the first executable code is described further, for example, in FIG. 3 (at 302).

[0118] At 806, elements of the first executable code may be extracted. The circuitry 202 may be configured to extract the elements of the first executable code 114. The circuitry 202 may parse the received first executable code 114 and identify various components such as functions, variables, and control structures. This extraction process may involve a break-down of the code into smaller, analyzable units. The elements of the first executable code 114 may include syntactical structure information, semantic role information, datatype information, data-scope information, data-context information, control flow features, token-level features, cross-module or dependency features, and the like. The extraction of code elements is described further, for example, in FIG. 3 (at 304).

[0119] At 808, code embedding associated with elements of the first executable code may be determined. The circuitry 202 may be configured to determine the code embedding associated with the elements of the first executable code 114. The code embedding may be determined based on the word embeddings and positional embeddings. The word embeddings may be determined by tokenizing the first executable code 114 to determine the code tokens and based on the code tokens the word embedding may be determined. The positional embedding may be determined associated with the first executable code 114 based on the word embeddings. The determination of code embedding is described further, for example, in FIG. 3 (at 306, in its sub-steps 306A, 306B, and 306C).

[0120] At 810, a self-attention model may be applied on the code embedding. The circuitry 202 may be configured to apply self-attention model on the code embedding. The application of the self-attention model may be based on intra-level attention. The application of the hierarchical cross-attention model may be based on the inter-levelattention. The intra-level attention and the inter-level attention may be determined associated with the elements of the first executable code 114. The self-attention model may allow the model to weigh the importance of different parts of the input sequence, helping it focus on relevant sections of the first executable code 114. The application of the self-attention model is described further, for example, in FIG. 3 (at 308).

[0121] At 812, a hierarchical cross-attention model may be applied on the code embedding. The circuitry 202 may be configured to apply the hierarchal cross-attention model on the code embedding. The hierarchical cross-attention may allow the deep learning model 110 to consider interactions between different parts of the first executable code 114. The hierarchal cross-attention model 412 may capture the interaction between different levels of the models (for example, the set of first weights, the set of second weights, the set of third weights, and the set of fourth weights) to focus on relevant parts of the input sequence. The application of the hierarchical cross-attention model is described further, for example, in FIG. 3 (at 310).

[0122] At 814, attention weights for each of the elements associated with the first executable code may be determined, based on the application of the self-attention model and the hierarchical cross-attention model. The circuitry 202 may be configured to determine the attention weights for each elements associated with the first executable code 114, based on the application of self-attention model and hierarchical cross-attention model. The attention weights may be categorized for example, a set of first weights, a set of second weights, a set of third weights, a set of fourth weights. The set of first weights may be associated with the relationship among a set of functions in a contract of the first executable code 114. The second weights may be associated with a relationship among the contract and the set of functions. The set of third weights may be associated with a relationship among a set of first statements in a first function of the set of functions andthe set of fourth weights may be associated with a relationship among the set of first statements in the first function and a set of second statements in a second function of the set of functions. The aggregated weights may be determined based on the set of first weights, the set of second weights, the set of third weights, and the set of fourth weights. The determination of attention weights is described further, for example, in FIG. 3 (at 312)

[0123] At 816, a deep learning model configured to detect at least one of vulnerabilities or bugs in a second executable code associated with the distributed ledger may be trained, wherein the deep learning model may be trained based on the attention weights. The circuitry 202 may be configured to train the deep learning model 110 configured to detect at least one of vulnerabilities or bugs in second executable code 116 associated with distributed ledger 112. The deep learning model 110 may be trained based on the attention weights. The circuitry 202 may be configured to use the analyzed code and generated attention weights to improve the deep learning model's detection capabilities for future analyses. In an embodiment, the vulnerabilities correspond to at least one of executable code vulnerabilities associated with the distributed ledger 112, mining pool vulnerabilities associated with the distributed ledger 112, consensus mechanism vulnerabilities associated with the distributed ledger 112, network vulnerabilities associated with the distributed ledger 112, or client vulnerabilities associated with the distributed ledger 112. The training of the deep learning model is described further, for example, in FIG. 3 (at 312). The detection of vulnerabilities is described further, for example, in FIG. 3 (at 314). Control may pass to end.

[0124] Although the flowchart 800 is illustrated as discrete operations, such as, 804, 806, 808, 810, 812, 814, and 816, the disclosure is not so limited. Accordingly, in certain embodiments, such discrete operations may be further divided into additional operations,combined into fewer operations, or eliminated, depending on the particular implementation without detracting from the essence of the disclosed embodiments.

[0125] Various embodiments of the disclosure may provide a non-transitory computer- readable medium and / or storage medium having stored thereon, computer-executable instructions executable by a machine and / or a computer to operate an electronic device (for example, the electronic device 102). Such instructions may cause the electronic device 102 to perform operations that may include reception of a first executable code (e.g., the first executable code 114) associated with a distributed ledger (e.g., the distributed ledger 112) and elements from the first executable code 114 may be extracted. The operations may further include determination of a code embedding associated with the elements of the first executable code 114. The operations may further include application of a selfattention model and a hierarchical cross-model on the code embedding. The operation may further include determination of attention weights for each of the elements associated with the first executable code 114, based on the application of the self-attention model and the hierarchical cross-attention model. The operation may further include training a deep learning model (e.g., the deep learning model 110) configured to detect at least one of vulnerabilities or bugs in a second executable code (e.g., the second executable code 116) associated with the distributed ledger 112. The deep learning model 110 may be trained based on the attention weights.

[0126] Various embodiments of the disclosure may provide an electronic device (for example, the electronic device 102). The electronic device 102 may include circuitry (e.g., the circuitry 202) and memory (e.g., the memory 204). The circuitry 202 of the electronic device 102 may be configured to receive a first executable code (e.g., the first executable code 114) associated with a distributed ledger (e.g., the distributed ledger 112). The circuitry 202 of the electronic device 102 may be further configured to extract elements ofthe first executable code 114 and determine a code embedding associated with the elements of the first executable code 114. The circuitry 202 of the electronic device 102 may be further configured to apply a self-attention model and a hierarchical cross-attention model on the code embedding. The circuitry 202 of the electronic device 102 may be further configured to determine attention weights for each of the elements associated with the first executable code 114, based on the application of the self-attention model and the hierarchical cross-attention model. The circuitry 202 may be configured to train a deep learning model (e.g., the deep learning model 110) configured to detect at least one of vulnerabilities or bugs in a second executable code (e.g., the second executable code 116) associated with the distributed ledger 112. The deep learning model 110 may be trained based on the attention weights.

[0127] In an embodiment, the distributed ledger 112 corresponds to at least one of a private distributed ledger, a public distributed ledger, or a hybrid distributed ledger.

[0128] In an embodiment, the elements correspond to at least one of syntactical structure information associated with the first executable code 114, semantic role information associated with the first executable code 114, data-type information associated with the first executable code 114, data-scope information associated with the first executable code 114, data-context information associated with the first executable code 114, control flow features associated with the first executable code 114, token-level features associated with the first executable code 114, or cross-module or dependency features associated with the first executable code 114.

[0129] In an embodiment, the circuitry 202 may be further configured to tokenize the first executable code 114 to determine code tokens. The circuitry 202 may be further configured to determine word embeddings associated with the first executable code 114, based on the code tokens and determine positional embeddings associated with the firstexecutable code 114, based on the word embeddings. The determination of the code embedding may be based on the word embeddings and the positional embeddings.

[0130] In an embodiment, the circuitry 202 may be further configured to determine an intra-level attention associated with the elements of the first executable code 114. The application of the self-attention model may be based on the intra-level attention.

[0131] In an embodiment, the circuitry 202 may be further configured to determine an inter-level attention associated with the elements of the first executable code 114. The application of the hierarchal cross-attention model may be based on the inter-level attention.

[0132] In an embodiment, the elements correspond to an abstract syntax tree (AST) associated with the first executable code 114.

[0133] In an embodiment, the attention weights include at least one of a set of first weights associated with a relationship among a set of functions in a contract of the first executable code 114, a set of second weights associated with a relationship among the contract and the set of functions, a set of third weights associated with a relationship among a set of first statements in a first function of the set of functions, or a set of fourth weights associated with a relationship among the set of first statements in the first function and a set of second statements in a second function of the set of functions.

[0134] In an embodiment, the circuitry 202 may be further configured to determine aggregated weights based on the set of first weights, the set of second weights, the set of third weights, and the set of fourth weights. The attention weights correspond to the aggregated weights.

[0135] In an embodiment, the vulnerabilities correspond to at least one of executable code vulnerabilities associated with the distributed ledger 112, mining pool vulnerabilities associated with the distributed ledger 112, consensus mechanism vulnerabilitiesassociated with the distributed ledger 112, network vulnerabilities associated with the distributed ledger 112, or client vulnerabilities associated with the distributed ledger 112.

[0136] The present disclosure may be realized in hardware, or a combination of hardware and software. The present disclosure may be realized in a centralized fashion, in at least one computer system, or in a distributed fashion, where different elements may be spread across several interconnected computer systems. A computer system or other apparatus adapted to carry out the methods described herein may be suited. A combination of hardware and software may be a general-purpose computer system with a computer program that, when loaded and executed, may control the computer system such that it carries out the methods described herein. The present disclosure may be realized in hardware that includes a portion of an integrated circuit that also performs other functions.

[0137] The present disclosure may also be embedded in a computer program product, which includes all the features that enable the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer program, in the present context, means any expression, in any language, code or notation, of a set of instructions intended to cause a system with information processing capability to perform a particular function either directly, or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form.

[0138] While the present disclosure is described with reference to certain embodiments, it will be understood by those skilled in the art that various changes may be made, and equivalents may be substituted without departure from the scope of the present disclosure. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the present disclosure without departure from its scope. Therefore, it isintended that the present disclosure is not limited to the particular embodiment disclosed, but that the present disclosure will include all embodiments that fall within the scope of the appended claims.

Claims

CLAIMSWhat is claimed is:1 . An electronic device, comprising: circuitry configured to: receive a first executable code associated with a distributed ledger; extract elements of the first executable code; determine a code embedding associated with the elements of the first executable code; apply a self-attention model on the code embedding; apply a hierarchal cross-attention model on the code embedding; determine attention weights for each of the elements associated with the first executable code, based on the application of the self-attention model and the hierarchical cross-attention model; and train a deep learning model configured to detect at least one of vulnerabilities or bugs in a second executable code associated with the distributed ledger, wherein the deep learning model is trained based on the attention weights.

2. The electronic device according to claim 1 , wherein the distributed ledger corresponds to at least one of a private distributed ledger, a public distributed ledger, or a hybrid distributed ledger.

3. The electronic device according to claim 1 , the elements correspond to at least one of: syntactical structure information associated with the first executable code, semantic role information associated with the first executable code, data-type information associated with the first executable code, data-scope information associated with the first executable code,data-context information associated with the first executable code, control flow features associated with the first executable code, token-level features associated with the first executable code, or cross-module or dependency features associated with the first executable code.

4. The electronic device according to claim 1 , wherein the circuitry is further configured to: tokenize the first executable code to determine code tokens; determine word embeddings associated with the first executable code, based on the code tokens; and determine positional embeddings associated with the first executable code, based on the word embeddings, wherein the determination of the code embedding is based on the word embeddings and the positional embeddings.

5. The electronic device according to claim 1 , wherein the circuitry is further configured to: determine an intra-level attention associated with the elements of the first executable code, wherein the application of the self-attention model is based on the intra-level attention.

6. The electronic device according to claim 1 , wherein the circuitry is further configured to: determine an inter-level attention associated with the elements of the first executable code, whereinthe application of the hierarchal cross-attention model is based on the inter-level attention.

7. The electronic device according to claim 1 , wherein the elements correspond to an abstract syntax tree (AST) associated with the first executable code.

8. The electronic device according to claim 1 , wherein the attention weights include at least one of: a set of first weights associated with a relationship among a set of functions in a contract of the first executable code, a set of second weights associated with a relationship among the contract and the set of functions, a set of third weights associated with a relationship among a set of first statements in a first function of the set of functions, or a set of fourth weights associated with a relationship among the set of first statements in the first function and a set of second statements in a second function of the set of functions.

9. The electronic device according to claim 8, wherein the circuitry is further configured to: determine aggregated weights based on the set of first weights, the set of second weights, the set of third weights, and the set of fourth weights, wherein the attention weights correspond to the aggregated weights.

10. The electronic device according to claim 1 , wherein the vulnerabilities correspond to at least one of:executable code vulnerabilities associated with the distributed ledger, mining pool vulnerabilities associated with the distributed ledger, consensus mechanism vulnerabilities associated with the distributed ledger, network vulnerabilities associated with the distributed ledger, or client vulnerabilities associated with the distributed ledger.11 . A method, comprising: in an electronic device: receiving a first executable code associated with a distributed ledger; extracting elements of the first executable code; determining a code embedding associated with the elements of the first executable code; applying a self-attention model on the code embedding; applying a hierarchal cross-attention model on the code embedding; determining attention weights for each of the elements associated with the first executable code, based on the application of the self-attention model and the hierarchical cross-attention model; and training a deep learning model configured to detect at least one of vulnerabilities or bugs in a second executable code associated with the distributed ledger, wherein the deep learning model is trained based on the attention weights.

12. The method according to claim 11 , wherein the distributed ledger corresponds to at least one of a private distributed ledger, a public distributed ledger, or a hybrid distributed ledger.

13. The method according to claim 11 , the elements correspond to at least one of: syntactical structure information associated with the first executable code, semantic role information associated with the first executable code, data-type information associated with the first executable code, data-scope information associated with the first executable code, data-context information associated with the first executable code, control flow features associated with the first executable code, token-level features associated with the first executable code, or cross-module or dependency features associated with the first executable code.

14. The method according to claim 11 , wherein the method comprises: tokenizing the first executable code to determine code tokens; determining word embeddings associated with the first executable code, based on the code tokens; and determining positional embeddings associated with the first executable code, based on the word embeddings, wherein the determination of the code embedding is based on the word embeddings and the positional embeddings.

15. The method according to claim 11 , wherein the method comprises: determining an intra-level attention associated with the elements of the first executable code, wherein the application of the self-attention model is based on the intra-level attention.

16. The method according to claim 11 , wherein the method comprises:determining an inter-level attention associated with the elements of the first executable code, wherein the application of the hierarchal cross-attention model is based on the interlevel attention.

17. The method according to claim 11 , wherein the attention weights include at least one of: a set of first weights associated with a relationship among a set of functions in a contract of the first executable code, a set of second weights associated with a relationship among the contract and the set of functions, a set of third weights associated with a relationship among a set of first statements in a first function of the set of functions, or a set of fourth weights associated with a relationship among the set of first statements in the first function and a set of second statements in a second function of the set of functions.

18. The method according to claim 17, wherein the circuitry is further configured to: determining aggregated weights based on the set of first weights, the set of second weights, the set of third weights, and the set of fourth weights, wherein the attention weights correspond to the aggregated weights.

19. The method according to claim 11 , wherein the vulnerabilities correspond to at least one of: executable code vulnerabilities associated with the distributed ledger, mining pool vulnerabilities associated with the distributed ledger,consensus mechanism vulnerabilities associated with the distributed ledger, network vulnerabilities associated with the distributed ledger, or client vulnerabilities associated with the distributed ledger.

20. A non-transitory computer-readable medium having stored thereon, computerexecutable instructions that when executed by an electronic device, causes the electronic device to execute operations, the operations comprising: receiving a first executable code associated with a distributed ledger; extracting elements of the first executable code; determining a code embedding associated with the elements of the first executable code; applying a self-attention model on the code embedding; applying a hierarchal cross-attention model on the code embedding; determining attention weights for each of the elements associated with the first executable code, based on the application of the self-attention model and the hierarchical cross-attention model; and training a deep learning model configured to detect at least one of vulnerabilities or bugs in a second executable code associated with the distributed ledger, wherein the deep learning model is trained based on the attention weights.

Images