AI-based execution on blockchain

Abstract

Various aspects of the subject technology relate to systems, methods, and machine-readable media for writing transactions, including smart contracts, on a blockchain platform. Various aspects may include receiving natural language input specifying a transaction to be performed on the blockchain. Aspects may also include using machine learning (ML) models to identify the transaction intent and contextual information associated with the transaction based on the natural language input. Aspects may also include identifying actions (e.g., constraints / conditions) corresponding to the natural language input transaction based on the intent and contextual information. Aspects may also include executing the transaction on the blockchain based on the actions.

Description

Technical Field

[0001] Cross - reference to Related Applications This disclosure is related to U.S. Provisional Patent Application No. 63 / 463,472, filed May 2, 2023, by John Morrisett et al., titled "ARTIFICIAL - INTELLIGENCE - BASED BLOCKCHAIN AND SMART CONTRACT ARCHITECTURE WITH COIN OPERATED AGENTS FOR A BROAD USER BASE", and claims priority under 35 U.S.C. § 119(e). The entire content thereof is incorporated herein by reference for all purposes.

[0002] This disclosure generally relates to blockchain network architectures that use artificial intelligence / machine learning (AI / ML) algorithms to expand the user base through machine - user interactions. More specifically, this disclosure relates to a blockchain architecture that includes smart contracts and coin - operated agents, and that embeds large language models (LLMs) to facilitate their use and handling by non - experts, thereby expanding the user base.

Background Art

[0003] The use of blockchain networks has proven to be very effective in providing a trust - based environment for online applications such as smart contracts, cryptocurrency transactions, etc. However, the user base of these systems is almost limited to programming experts with advanced knowledge in current cryptographic technologies and network - based coding. This fact precludes the widespread use of blockchain technology and its global adoption by the general public.

Summary of the Invention

[0004] This disclosure provides a system and method for issuing transactions, writing smart contracts, and other actions in human-readable language by capturing intents such as transactions and smart contracts using an LLM. According to embodiments, the LLM is provided to interpret natural language input and introduce natural language processing capabilities into blockchain architectures. When interpreting a transaction, the necessary context is already encoded in the state built into the LLM. This greatly simplifies the creation and execution of transactions / smart contracts on the blockchain. Leveraging an LLM eliminates the need for programming and translation steps (e.g., to machine-executable code) and provides low-latency interaction with the blockchain network. LLM-based smart contracts and transactions can take many forms, including high-level code or a list of text-based prompts / instructions that can be stored in the LLM as the necessary context.

[0005] According to the embodiment, a computer implementation method for executing transactions on a blockchain platform is provided. The method includes receiving a natural language input specifying a transaction to be performed on the blockchain. The method also includes using an ML model to identify intent and context information associated with the transaction based on the natural language input. The method also includes identifying an action corresponding to the natural language input based on the intent and context information. The method also includes executing the transaction on the blockchain based on the action.

[0006] According to the embodiment, a system is provided which includes a processor and memory containing instructions stored therein, and when an instruction is executed by the processor, causes the processor to perform a method for implementing a transaction on a blockchain platform. The method includes receiving a natural language input specifying a transaction to be performed on the blockchain. The method also includes using an LLM to identify intent and context information associated with the transaction based on the natural language input. The method also includes identifying an action corresponding to the natural language input based on the intent and context information. The method also includes executing a transaction on the blockchain based on the action.

[0007] According to the embodiment, a non-temporary computer-readable storage medium is provided containing instructions (e.g., a sequence of stored instructions), which, when executed by a processor, cause the processor to perform a method for executing a transaction on a blockchain platform. The method includes receiving a natural language input specifying a transaction to be performed on the blockchain. The method also includes using an LLM embedded within the blockchain validator to identify intent and context information associated with the transaction based on the natural language input. The method also includes identifying an action corresponding to the natural language input based on the intent and context information. The method also includes executing a transaction on the blockchain based on the action.

[0008] According to one embodiment of the present disclosure, a system is provided which includes means for storing instructions and means for executing stored instructions, the instructions, when executed by the means for execution, cause the means for execution to perform a method for executing a transaction on a blockchain platform. The system also includes means for receiving natural language input specifying a transaction to be performed on the blockchain. The system also includes means for identifying intent and context information associated with a transaction based on the natural language input, using an ML model (e.g., LLM). The system also includes means for identifying an action corresponding to the natural language input based on the intent and context information. The system also includes means for executing a transaction on the blockchain based on the action.

[0009] These and other embodiments will be apparent from this disclosure. Other configurations of the subject art will be readily apparent to those skilled in the art from the following detailed description, and it will be understood that various configurations of the subject art are described and explained illustratively. As will be understood, the subject art may have other different configurations, and some of its details may be modified in various other ways without departing from the scope of the subject art. Accordingly, the drawings and detailed description should be considered illustrative and not limiting in nature. [Brief explanation of the drawing]

[0010] The accompanying drawings are included to provide further understanding, are incorporated herein, constitute part of this specification, illustrate the disclosed embodiments, and, together with the specification, help to illustrate the principles of the disclosed embodiments. The drawings are as follows:

[0011] [Figure 1] This is a block diagram of a device operating environment in which the embodiments of this disclosure can be implemented. [Figure 2]This block diagram illustrates the details of the devices used in the architecture of Figure 1 in several embodiments. [Figure 3] This is a block diagram illustrating a blockchain system for executing transactions on a blockchain platform, according to a particular aspect of this disclosure. [Figure 4] This is an exemplary flowchart for executing a transaction on a blockchain platform, according to a particular aspect of this disclosure. [Figure 5] This is a block diagram illustrating an exemplary computer system capable of implementing aspects of the subject technology.

[0012] Not all components shown in each figure are required in one or more implementations, and one or more implementations may include additional components not shown in the figures. Variations may be made in the arrangement and type of components without departing from the scope of this disclosure. Additional components, different components, or fewer components may be used within the scope of the disclosure. [Modes for carrying out the invention]

[0013] The following detailed description includes many specific details in order to provide a complete understanding of the disclosure. However, it will be apparent to those skilled in the art that embodiments of the disclosure can be practiced without some of these specific details. In other examples, well-known structures and techniques are not shown in detail so as not to obscure the disclosure.

[0014] The following detailed description illustrates various configurations of the subject art and is not intended to represent only one configuration in which the subject art can be practiced. The detailed description includes specific details for the purpose of providing a complete understanding of the subject art. Therefore, dimensions may be provided in relation to certain embodiments as non-limiting examples. However, it will be apparent to those skilled in the art that the subject art can be practiced without these specific details. In some examples, well-known structures and components are shown in block diagrams to avoid obscuring the concepts of the subject art.

[0015] General Overview A blockchain platform can host and execute computer programs such as smart contracts and process transactions. A smart contract may consist of code specifying predetermined conditions, and when those conditions are met, the smart contract automatically executes the agreed-upon action. A blockchain platform may require a consensus protocol as a fundamental building block for constructing a decentralized system. As an example, a blockchain platform may include multiple blockchains, such as a component exchange blockchain for creating and trading digital smart assets, a metadata blockchain for coordinating validators and tracking and creating subnets, and a contract blockchain for creating smart contracts. As used herein, a subnet or subnetwork includes a dynamic set of nodes (e.g., one or more validators) that seek to achieve consensus on the state of a set of blockchains. Validators are responsible for verifying new blocks of transactions and adding them to the blockchain. Validators verify the authenticity and accuracy of transaction records before they are permanently added to the blockchain. Thus, validators play a crucial role in maintaining the security, transparency, and integrity of the blockchain network.

[0016] Blockchain platforms feature application-level logic defined by multiple virtual machines (VMs). VM-based architectures enable more decentralized networks. Specifically, a blockchain can be an instance of a VM that specifies the blockchain's state, state transitions, transactions, and application programming interfaces (APIs) for user interaction. The VM enables the execution of smart contracts and decentralized applications on the blockchain, providing a secure and deterministic environment for code execution and enabling interoperability between blockchains. This VM is the core component that defines the blockchain's application-level logic. The blockchain utilizes the VM to execute low-level machine-readable code representing transactions and smart contracts. This code may include various actions and instructions that are interpreted and processed by the VM.

[0017] When executing a transaction or smart contract, the VM starts in a blank computational state, and the developer must encode all application logic into machine code. This means the VM has no prior context or knowledge of the application or blockchain state. The VM operates based solely on the instructions provided in this low-level code, without any additional context or interpretation. This places a significant burden on the developer, as they must consider all possible scenarios and state changes within the application. Developers cannot rely on any high-level abstractions or existing logic to alleviate this burden. Developers must meticulously define all the functions and behaviors of the transaction or smart contract in the VM code. This level of granularity and lack of high-level abstractions contribute to the complexity and difficulty of creating applications (e.g., smart contacts) on a blockchain platform, as developers must consider all possible states and transitions within the VM execution.

[0018] Errors can be introduced at multiple levels during the development and execution of smart contracts. For example, a user's high level of understanding of a smart contract's functionality may not match the details of its actual implementation. This mismatch between user perception and the contract's intent can lead to errors. The specialized programming required to capture the contract's operational logic, runtime, and execution environment requires skilled developers. This reliance on human programmers introduces the potential for coding errors. Additionally, compilers are responsible for translating programming language code into bytecode that can be executed by the blockchain. Compiler errors can have catastrophic consequences, even in thoroughly audited smart contracts. Many failures stem from semantic gaps between user intent, smart contract code, and the final executable bytecode. Any mismatch between these layers can lead to problematic outcomes.

[0019] Overcoming these challenges is crucial for ensuring the reliability and security of smart contracts and blockchain applications, as well as for facilitating their use and handling by non-experts and expanding the user base.

[0020] Embodiments, as disclosed herein, provide solutions to the aforementioned computer technology-based problems, namely, the execution of transactions and smart contracts on a blockchain platform. The technologies of the disclosed subject matter improve the capabilities of the computer itself by providing a blockchain architecture that integrates artificial intelligence (AI), machine learning (ML), and large-scale language models (LLM) to support augmented transaction processing and smart contract creation. The blockchain architecture described herein can be constructed as subnets. According to embodiments, the LLM can be embedded within the blockchain validator. The LLM can be trained on a massive corpus of data. The training process involves the model ingesting and learning from a wide range of datasets from various sources (e.g., available human-generated content on the internet). This gives the validator an improved ability to understand, process, and utilize relevant information (e.g., the intent of a smart contract) aligned with application objectives.

[0021] The disclosed subject matter technology further provides improvements to the technology field by expanding the user base through machine user interaction and improving how users interact with the blockchain, thereby making the blockchain architecture accessible to non-expert users. According to the embodiment, LLM provides natural language processing capabilities to the blockchain architecture. Furthermore, when interpreting a transaction, the necessary context is already encoded in the state built into the LLM. Validators can utilize the LLM to interpret input transactions expressed in natural language and execute transactions based on human language specifications.

[0022] According to an embodiment, a user can specify the purpose of an application in natural language using an LLM. The LLM interprets these purposes and processes them based on the available human knowledge captured by the trained LLM. The blockchain validator can automatically execute transactions upon understanding the user's purpose. This approach allows the blockchain architecture to fill the gap between the functionality of an application and what it can actually execute, and expand the user base to, for example, non-expert developers.

[0023] According to an embodiment, each transaction can be part of a sequence of related transactions. Each sequence is assigned a unique identifier that can be used to access, modify (e.g., add a transaction to the chain), or reference the sequence. As a non-limiting example, a new transaction (or subsequent interaction) can associate the new transaction with a sequence using the sequence identifier assigned during the creation of a given sequence. The start of a new sequence can be initiated by the user. In some implementations, a sequence ID of 0 indicates that the transaction is intended to create a new sequence. This enables the blockchain architecture to orchestrate and manage transactions in a structured sequential manner.

[0024] According to an embodiment, each validator within the blockchain can utilize an exact version of the LLM. The version can be implicitly and externally specified on the system or blockchain by the user (or application) submitting the transaction. In some implementations, the version is specified once within the genesis block for all blocks and serves as a common basis for transactions (e.g., a series of related transactions) on that chain. In some implementations, the version to be used for a sequence is specified upon creation of each sequence.

[0025] In some implementations, the validator executes a single LLM per transaction. In some implementations, the validator executes multiple LLMs per transaction. One or more of the multiple LLMs may generate potentially different interpretations (or actions) for a given transaction. In this case, the implementation may implement a resolution protocol. As a non-limiting example, the resolution protocol may roll back a transaction based on the ambiguity of the action. Rolling back the transaction stops the execution of the transaction and also deletes the state changes based on the transaction. As a non-limiting example, the resolution protocol may take the common part of the actions. Then, the transaction may be executed based on that common part.

[0026] According to an embodiment, a blockchain validator can enable probabilistic checking. In a typical blockchain, all other validators check the state transition and vote on the validity of a block proposed by a validator. In probabilistic checking, a validator posts a block, the transactions within the block, and a new state root, and other validators adopt it as the given correct state transition after a challenge period has elapsed. During the challenge period, other validators may point out that the state transition is invalid. Probabilistic checking of the validator's work can help reduce the costs associated with the execution of AI / ML components.

[0027] This disclosure relates to a method and system for specifying transactions and smart contracts in human-readable language by capturing their intents. This eliminates the traditionally error-prone programming and translation steps and provides low-latency interaction with blockchain networks. In other words, because the LLM captures and utilizes human knowledge available through its training set, the user or system does not need to translate from the input language to a programming language or executable bytecode. Similar to a human confidant or executor, the system instantiates the LLM within each interaction sequence, operating with the same sensibility, contextual awareness, and implicit understanding as a human. This is a significant difference from traditional computer programs that simply execute predefined instructions without being inherently aware of a higher purpose or underlying intent. Similarly, in traditional smart contract environments, coding errors are often encountered because the code is the law and does not consider user intent. The blockchain architecture described herein allows the LLM to leverage its learned knowledge to ensure fidelity to the original intent of its creator.

[0028] The implementation techniques disclosed herein further contribute to efficient runtime performance after training by enabling the LLM to rapidly process text input. The LLM implementation also allows, for example, ordinary people with read and write capabilities to interact with smart contracts. This has the potential to extend the benefits of blockchain networks to a wider range of users.

[0029] As used herein, the term “blockchain” generally refers to an open, distributed, public ledger containing a growing list of records linked using cryptography. By design, blockchains are resistant to data alteration. A blockchain may contain an auditable database, which provides a distributed, replicated ledger of cryptographically authenticated artifacts, and the contents of the artifacts are so difficult to tamper with without detection that they are highly likely to be authentic copies of the intended contents, and their contents can be inspected via a suitable query interface.

[0030] As used herein, the term “block” generally refers to a record held within a blockchain. For example, each block contains the cryptographic hash, timestamp, and transaction data of the previous block, which can generally be represented as a Merkle tree root hash.

[0031] In some embodiments, the term “subnet” or “subnetwork” generally refers to a dynamic set of validators working together to achieve consensus on the state of a set of blockchains. For example, each blockchain may be validated by only one subnet. A subnet can validate any number of blockchains. Validator nodes can be members of any number of subnets. A subnet can manage its own membership and require the validators it comprises to have certain properties (characteristics).

[0032] In some embodiments, a customized blockchain may include a VM marketplace with subnets serviced by unique VM modules, thereby enabling users to create feature sets tailored to specific needs. For example, a gaming application within the VM marketplace might have a different VM module than a financial application.

[0033] Exemplary system architecture Figure 1 shows an exemplary network architecture 100 used to provide a blockchain platform (e.g., a blockchain network implementation) that handles blockchains, according to an embodiment. The network architecture 100 in Figure 1 includes one or more participants 110 and one or more participants 130 that are communicatively connected via a network 150. The blockchain of the network architecture 100 can be a decentralized database that maintains a continuously growing list of records (e.g., transactions) ordered as blocks. The blockchain can be a linear chain of blocks of the same dimensions, e.g., the same height, size, length, etc. Blocks of the blockchain may contain or store data or organized information (e.g., a record of information), including, for example, the cryptographic hash, timestamp, and transaction data of the previous block. A feature of the blockchain network architecture 100 is that it can leverage AI / ML models (more specifically, LLMs) to create smart contracts hosted on one or more blockchains based on natural language specifications, using one or more LLMs embedded in each of the blockchain validators.

[0034] Participant 130 may host a blockchain or application that runs on Participant 110 and is used by one or more participants of the blockchain platform. Participant 130 may include a cloud server or a group of cloud servers. Participant 130 may provide Participant 110 with services such as internet-based services, including web2 services and web3 services. Thus, Participant 130 may implement computer applications for smart contracts, cryptocurrency-based services, transaction services, payment services, lookup services, data services, query services, etc. In some implementations, Participant 130 may not be a cloud-based server (i.e., may be implemented outside a cloud computing environment) or may be partially cloud-based. As an example, Participant 130 may function as a validator. As an example, Participant 130 may be a VM that forms a node in the blockchain network architecture 100. Participant 110, acting as a node, may run software to validate block and transaction data for an existing blockchain, store data, verify its validity, and respond to network requests for data. The VM can be a computer that runs on the blockchain and allows smart contracts from multiple sources to interact with each other. Participant 130 sends a message or issues a transaction in response to a request from participant 110. The message can be validated by validators on the blockchain network.

[0035] Participant 110 may include one of the following: a laptop computer, a desktop computer, or a mobile device such as a smartphone, palm device, or tablet device. For example, Participant 110 may be a client of a blockchain platform for creating, extending, or otherwise modifying a customized blockchain network and / or a private or public blockchain. Participant 130 may generate blocks at a request from Participant 110 at a specific time, such as during a designated time submission window (e.g., a window to allow the transfer of prescriptions), for example, via Participant 130's smart contract engine or module. Participant 130 may be configured to implement multiple chains of the blockchain.

[0036] According to the embodiment, the linear chain of blocks constituting the blockchain may consist of a genesis block, followed by blocks containing a free-form transaction type signed by a public-private key, each containing an arbitrary text input. This chain is implemented by a collection of distributed validators, each running an LLM, where transactions are executed. The public and private keys may be linked such that the public key is universally accessible, while the private key is hidden and available only to specific users. In some embodiments, if a message is signed by a private key, the signature must be uniquely traceable against the public key. To be accepted into a block, a transaction must be signed using the user's private key and included in a base transaction.

[0037] Validators maintain an associated sequence or mapping that links public key hashes or contract hashes (e.g., sequence identifiers) to token balances. This mapping allows validators to maintain ownership and track the distribution of tokens across the network. Certain tokens within a blockchain can function as gas tokens. Gas tokens may be designated by a genesis block. Validators may accept these gas tokens as payment for including transactions in a block, thus encouraging validators to process transactions efficiently. A genesis block may contain an initial balance of tokens that helps bootstrap the system. Alternatively, or additionally, token balances may be used to bring token balances into or out of a blockchain from another blockchain. A bridge can be a user for connecting isolated blockchain ecosystems, enabling seamless transfer of assets and data between them and facilitating improved interoperability and functionality within a decentralized space.

[0038] Participant 130 may be configured to implement multiple chains of the blockchain network architecture 100. For example, participant 130 may implement multiple chains of the blockchain network architecture 100, such as an asset blockchain (e.g., for creating new assets, asset exchange, and cross-subnet transfers), a metadata blockchain (e.g., for validator coordination, tracking active subnets, and creating new subnets), and a smart contract blockchain (e.g., for creating smart contracts and applications that require full ordering). Each of the multiple chains may be associated with a specific LLM or LLM version.

[0039] Network 150 may include one or more of the following: wired networks (e.g., via optical fiber or copper wire, telephone lines, etc.), wireless networks (e.g., cellular networks, radio frequency (RF) networks, Wi-Fi, Bluetooth, etc.), local area networks (LANs), wide area networks (WANs), the Internet, etc. Furthermore, Network 150 may include, but is not limited to, one or more of the following network topologies, including bus networks, star networks, ring networks, mesh networks, star bus networks, tree or hierarchical networks, and / or combinations of these or other types of networks.

[0040] Database 152 may store relevant information regarding rules for implementing, for example, execution and verification logic, and / or protocols, training data, etc. Participant 130 may store blockchain data in database 152 in a peer-to-peer (P2P) and / or distributed ledger format. In particular, participant 130 may function in conjunction with the P2P network and participant 130's distributed timestamp server to autonomously manage a decentralized database of an existing blockchain. In particular, participant 130 may function in conjunction with database 152 to autonomously manage a decentralized database of an existing blockchain.

[0041] Figure 2 is a block diagram of an exemplary computing network 200 for use in the network architecture of Figure 1, according to several embodiments. The exemplary computing network 200 may implement an AI-based blockchain architecture in which one or more LLMs are embedded in each of the blockchain validators. Participants 130 and 110 may be used to operate the AI-based blockchain architecture, according to one or more embodiments. The blockchain architecture of the exemplary computing network 200 may include blockchain validators represented by one or more participants 130, and multiple platform blockchains verified and secured by one or more participants 130. Participants 110 may connect to the blockchain network, enabling users to interact with the blockchain.

[0042] Each of the one or more participants 110 and the one or more participants 130 may access each other and other devices within the network 150 via their respective communication modules 218-1, 218-2 (collectively referred to as "communication modules 218"). Each communication module 218 may include wireless hardware and software such as an RF antenna, analog circuitry, digital-to-analog conversion circuitry, and digital signal processing circuitry. The communication modules 218 are configured to interface with the network 150 and transmit and receive information such as requests, responses, messages, and commands to and from other devices on the network 150 in the form of datasets. Participant 110 may be coupled with input device 214-1 and output device 216. Participant 130 may be coupled with input device 214-2. Input devices 214-1 and 214-2 (collectively referred to as "input devices 214") may include a keyboard, mouse, pointer, or even a touchscreen display that a user can use to interact with participant 110 / participant 130. Similarly, the output device 216 may include a display and speaker from which the user can obtain results from the participant 110.

[0043] Participant 110 may also include a processor 212-1 configured to execute instructions stored in memory 220-1 and cause participant 110 to perform at least some of the steps in a manner consistent with this disclosure. The processor 212-1 of participant 110 may be used to operate participant 110, such as executing applications and their functions rendered on participant 110. Memory 220-1 may further include an application 222. Application 222 may include specific instructions that, when executed by processor 212-1, cause a dataset from participant 130 to be displayed to a user. The configuration of participant 110 can be defined via user / operator input, such as via an input device 214. Participant 110 may implement smart contract creation as described herein, for example, based on information stored in application 222. Data and files associated with application 222 (e.g., one or more datasets) may be stored in database 152.

[0044] Participant 110 may be used by users of the blockchain platform for creating smart contracts, transferring messages, exchanging transactions, verifying blockchains, proposing blocks, and other blockchain functions, via a graphical user interface (GUI) or display for the user of Participant 110. For example, Participant 110 may be coupled to at least one input device 214 and output device 216 accessible by the user (e.g., for user input and output perceptible to the user). Input devices 214-1 may include a mouse, keyboard, pointer, stylus, touchscreen display, microphone, speech recognition software, GUI, etc. Output device 216 may include a display (e.g., the same touchscreen display as the input device), speaker, alarm, etc.

[0045] In some embodiments, participant 110 and / or participant 130 act as blockchain validators, such as verifying transactions on an existing blockchain. death Participant 110 may receive rewards (e.g., cryptocurrency) in exchange for verifying transactions or participating in and staking network tokens on a blockchain platform. Participant 110 may be part of a set or list of validators, including one or more other validators of Participant 110.

[0046] Each participant 130 includes an application programming interface (API) layer 215 that controls the application 222 in each participant 110. The API layer 215 may also provide participants 110 with instructions, procedural information, updates, etc., for example, when new features are uploaded to the application 222 (e.g., notifications such as newly added features or pharmacy closures). Participant 130 also includes memory 220-2 for storing instructions, which, when executed by processor 212-2, cause participant 130 to perform at least one or more actions in a manner consistent with this disclosure.

[0047] Processor 212-2 may be configured to control application 222 in participant 110. For example, memory 220-1 of participant 110 may be used to perform functions associated with a blockchain platform hosted by participant 130. Processor 212-2 may be used to implement blockchain protocols. Memory 220-2 includes engine 232. Engine 232 may include a computing platform comprising modules configured to perform aspects of the embodiment (as described, for example, with reference to system 300 in Figure 3). For example, engine 232 may include instructions that generate smart contracts and other transactions (e.g., blockchain assets) as disclosed herein. To do this, engine 232 may include, according to aspects of the embodiment, an LLM tool 226 configured to implement LLM, an encryption tool 228 configured to encrypt transactions on the blockchain using various cryptographic techniques, a verification tool 234 configured to verify transactions on the blockchain, and an execution tool 236 configured to execute submitted and / or verified transactions (or actions within transactions) on the blockchain. Processors 212-1 and 212-2, and memories 220-1 and 220-2 will collectively be referred to as "processor 212" and "memory 220," respectively, from now on.

[0048] The LLM tool 226 may be part of one or more AI / ML models stored in the database 152. In some embodiments, at least one training archive or machine learning model may be stored in one of the memories 220. The database 152 includes training archives and other data files that can be used by the engine 232 in training machine learning models according to user input via the application 222 and data extracted via the network 150.

[0049] The LLM tool 226 may include algorithms and tools trained for a specific purpose of engine 232. Algorithms may include machine learning or artificial intelligence algorithms that utilize any linear or nonlinear algorithm, such as neural network algorithms or multivariate regression algorithms. In some embodiments, machine learning models may include classical machine learning algorithms such as LLM, natural language understanding (NLU) models, neural networks (NN), convolutional neural networks (CNN), generative adversarial neural networks (GAN), unsupervised learning algorithms, deep recurrent neural networks (DRNN), random forests, or any combination thereof. More generally, machine learning models may include any machine learning model that includes training and optimization steps. In some embodiments, database 152 may include training archives for modifying coefficients according to the desired outcome of the machine learning model. Thus, in some embodiments, engine 232 is configured to access database 152 to retrieve data and archives as input to the machine learning model. In some embodiments, engine 232, the tools contained therein, and at least a portion of database 152 may be hosted on different servers accessible by participants 110 / 130.

[0050] The processor 212-2 may be configured to execute the LLM tool 226, the cryptography tool 228, the verification tool 234, and the action tool 236 by software, by hardware, by firmware, by some combination of software, hardware, and / or firmware, and / or by other mechanisms for configuring processing power on the processor 212-2. As used herein, the term “tool” may mean any component or set of components that perform a function resulting from one or more aspects of the embodiment. This may include one or more physical processors in which processor-readable instructions, circuitry, hardware, storage media, or any other components are executed.

[0051] Memory 220 can store instructions, and the processor 212 may be configured to execute instructions to perform at least partially one or more steps as described in one or more embodiments. For example, the memory 220-1 of participant 110 may be used to perform functions associated with a blockchain platform hosted by participant 130, such as acting as a validator node or VM for maintaining the integrity of existing blockchains, relays, and / or other entities. Participant 110 may be one of several validators (or nodes) that can be organized into a small list of validators for randomly sampling proposers of the next block to be added to an existing blockchain. The list of validators for a subnet can be drawn by participant 130 from a given blockchain platform chain.

[0052] The above description relates to certain functions performed by the processor 212-1 of participant 110 and other certain functions performed by the processor 212-2 of participant 130, but all functions described herein can be performed by participant 110 and / or participant 130 in several other alternative divisions of labor. It is also understood that participant 110 may include verification information in its memory 220-1, and participant 130 may include proposed block and data files in its memory 220-2 such that they have a parallel structure.

[0053] Figure 3 is a block diagram illustrating a blockchain system 300 for implementing transactions in a blockchain network 302, according to several embodiments. The blockchain network 302 may include one or more blockchains and / or one or more subnets. For simplicity, one blockchain 304 is shown in Figure 3.

[0054] Blockchain 304 contains several blocks 310a, 310b, and 310c (collectively referred to as "block 310"). For simplicity, three blocks 310 are shown within the chain of Blockchain 304, but Blockchain 304 may contain fewer blocks, more blocks, or more chains. Each block 310 may contain a cryptographic hash linking the current block to the previous block in the chain, a transaction root representing the transactions contained in the block, a timestamp record of when the block was added to the blockchain, and so on. Blockchain network 302 may contain nodes that can handle API calls and gossip transactions between other nodes, and run blockchain software / protocols. Nodes are responsible for maintaining the distributed ledger, verifying transactions, and providing access to the blockchain.

[0055] In some embodiments, the nodes include non-validator nodes for maintaining a distributed ledger, providing accessibility to users and applications, relaying transactions, and contributing to the decentralization of the blockchain network 302. In a non-limiting example, a non-validator node may maintain a complete copy of the blockchain's transaction history and current state. In a non-limiting example, a non-validator node, such as a relay, receives new transactions from clients and broadcasts them to validators (i.e., validator nodes) for inclusion in a new block. Validators are also responsible for generating and / or proposing blocks to be added to the blockchain network 302.

[0056] In some embodiments, the nodes include validator nodes (e.g., validator 306) responsible for verifying and / or maintaining a record of transactions for the blockchain network 302. According to the embodiments, validator nodes may be configured for probabilistic checking of validator work. For example, if one validator node posts a block, transactions within the block, and a new state root, other validator nodes, after a challenge period has elapsed, adopt that block as a given correct state transition.

[0057] Client 308 may specify transaction inputs in natural language (i.e., human-readable language) on the blockchain network 302. This initiates a new transaction within the network. According to the embodiment, client 308 may correspond to an application, user, computing device, user interface, or participant (e.g., participant 110) in the transaction. The transaction specification is sent to and broadcast on the blockchain network 302. This specification may be for describing a smart contract. As a non-limiting example, client 308 may specify a smart contract for playing chess with another participant.

[0058] Validator 306 may include an ML model, more specifically, LLM312. Validator 306 can receive a natural language specification of a transaction and use LLM312 to interpret the transaction intent. Specifying a transaction in human-readable language also eliminates the burden on developers to write equivalent machine-readable code. The free-form nature of specifying transactions creates many functions that are difficult in traditional blockchain systems. As a non-limiting example, a director may host fundraisers for a charitable cause. Donors may only want to contribute to the charity if the fundraiser can raise a certain amount of money by a specific date. Using system 300, the donor can sign a transaction containing that natural language clause and initiate a transaction in the network. A validator receives that transaction, uses LLM to interpret the intent, and validates the transaction for inclusion in a block (e.g., block 310).

[0059] According to the embodiment, each natural language specification entered by client 308 must be supported by LLM312. In some embodiments, system 300 may restrict the input language to improve the user experience (UX). For example, restricting the input to a widely spoken language has the advantage that more people can read and follow the sequence of events displayed in the Chain Explorer.

[0060] LLM312 may include a machine learning model trained on a comprehensive dataset compiled from various sources, enabling LLM312 to capture and emulate human knowledge and behavioral patterns. The training process allows LLM312 to interpret specifications in a manner very similar to how humans do, by utilizing the rich information contained in the training data. For example, LLM312 can be trained by ingesting human-generated content available on the internet. By processing specifications using a trained LLM312, validator 306 can access, trust, and utilize contextual information that may be associated with natural language input, even if that information is not explicitly specified by client 308.

[0061] According to some embodiments, contextual information may include high-level abstractions or existing logic that LLM312 has learned from its training data. This enables system 300 to provide a more comprehensive and informed interpretation of the specification (i.e., a specified transaction or smart contract). The necessary contextual information is effectively already encoded in the state of LLM312 and is leveraged to augment the specification.

[0062] According to some embodiments, LLM312 may include one or more AI models, ML models, and LLMs that understand and process human language, understand the context and meaning behind the language, and work together to provide context-relevant transactions within System 300 by leveraging their learned knowledge. In some implementations, multiple LLMs may be used to interpret natural language input. In the specification of each transaction, the client 308 may specify whether the transaction should be processed using, for example, one LLM or multiple LLMs. Processing input using multiple LLMs may lead to ambiguous interpretations, which may result in different actions based on the same specification. According to some embodiments, a resolution protocol is implemented to undo transactions due to ambiguity.

[0063] According to the embodiment, sequences can be used to create separation between concurrent, independent activities in order to prevent various different uses of the chain from potentially mixing with one another. A sequence is a contiguous set of transactions that instantiate and modify the state of a given LLM, enabling multiple concurrent streams of interactions with a single instance of a given LLM (e.g., associated transactions or interactions with a smart contract). Without proper separation, unrelated interactions could affect the state of another interaction (e.g., interactions in a chess game could affect the state of another concurrent game).

[0064] In some embodiments, the version of LLM312 (e.g., GPT-3, ChatGPT, BLOOM, etc.) is specified in the transaction specification and interprets all subsequent related transactions. A given LLM may be derived from the initial state of the LLM version specified in the chain's genesis block. A separate LLM may then deviate from the initial state as a result of a transaction modifying its sequence. According to embodiments, a new sequence may be assigned a unique sequence identifier (e.g., a number, a named identifier, etc.) when the new sequence is created. The unique sequence identifier is used to refer to each sequence and to interact with (or modify) each sequence.

[0065] A new sequence can be created by initializing a sequence ID in the transaction specification. For example, a sequence ID of zero indicates that the transaction intends to create a new sequence. In embodiments, there may be no restriction on which sequence ID is used for each new transaction, while still tracking significant state modifications (e.g., adding liquidity to a contract). Once a new sequence is created, a unique sequence identifier is assigned to the new sequence. As a non-restrictive example, the transaction hash of a transaction with sequence ID 0 starts a new smart contract, the specification specifies (in natural language) the rules for future interaction with that sequence, and the sequence is assigned a unique sequence identifier (different from the sequence ID).

[0066] As a non-limiting example, the specification could specify that a new sequence implements a lending platform, within which future transactions could deploy collateral that borrows other tokens deposited by liquidity providers. The specification could further include restrictions such as who can modify the contract's items, the fees the contract will collect, and when and how borrowers whose collateral requirements fall below a threshold will be liquidated. Following this example, future interactions with the lending platform would use a unique sequence identifier assigned when the sequence was created. This would allow multiple independent sequences to operate on the same chain through state isolation. Furthermore, this would enable more sophisticated fee collection strategies, such as ensuring that a particular sequence can guarantee space on the blockchain (for example, a lending platform might need such a guarantee to allow people to post collateral) or ensuring that the demand of one sequence does not affect the fees of other unrelated sequences.

[0067] In some embodiments, the LLM 312 may include and deploy a preamble that provides precise and unambiguous wording, syntax, and semantic context for common tasks. The preamble is used to set stages, define a particular task, or provide guidelines that the LLM should follow. In some embodiments, the smart contract may include a digital "small print" with a boilerplate language to ensure that future interactions cannot modify or invalidate initial clauses, including, but not limited to, the initial intent of the author (e.g., client 308). In some embodiments, the system 300 may incorporate a smart contract library containing reusable behaviors that can be added to user-initiated contracts. The smart contract library provides reusable implementations of these behaviors and implementations of various standards (before the client provides contextual information data to the LLM).

[0068] In some implementations, the specification may include mathematical formulas, computer code, etc., to specify complex mathematical intents within a transaction. As a non-limiting example, client 308 could simply provide a nugget of the clearing engine from online resources in the form of a mathematical formula, code script, etc., rather than specifying the clearing conditions within the lending application within a transaction. This has the advantage of separating the intent from the implementation, avoiding inaccuracies, and improving conciseness, but it may require client 308 to have some level of computer programming knowledge to evaluate the intent.

[0069] The intent and context information identified by LLM312 can be used to generate actions corresponding to rules, constraints, conditions, descriptions, etc., specified in the natural language specification. Transaction 314 may be executed based on the action. Transaction 314 may be a data packet containing the action and the validated natural language specification. The action may include specific actions, instructions, rules, etc., determined by validator 306 to constitute the transaction specified by client 308. The action may reflect LLM's understanding of the actions to be taken to execute the transaction according to the specification. When executing transaction 314, the action may instruct blockchain 304 to make several types of changes (e.g., transfer of assets or execution of a smart contract).

[0070] In some embodiments, executing transaction 314 may include validating transaction 314 and recording the transaction in a block (e.g., block 310c) on the blockchain network 302. In some implementations, the validator 306 may mine a new block corresponding to transaction 314. Once the new block is validated by the majority of network nodes, it is permanently added to the blockchain and transaction 314 is committed.

[0071] In some embodiments, LLM312 may be configured to generate a response output to client 308. The response may include, for example, a set of natural language constraints or actions that the execution of transaction 314 will adhere to, at least based on the input specifications. This provides a level of transparency between the client and the blockchain and avoids actions taken by the LLM based on potential hallucinations or inaccurate reasoning. Following an example of a donor who wants to donate based on certain conditions (e.g., only if the fundraiser can raise a certain amount by a certain date), LLM312 may generate a set of constraints defined based on the interpretation of the input. This approach can serve as a secondary verification mechanism to ensure that the client's intent for the transaction and the LLM's interpretation of that intent are properly aligned.

[0072] According to some embodiments, system 300 may define a transaction format that includes specific data fields enabling the efficient execution of transaction 314. In some embodiments, the transaction format may include at least a fee, a free-form field, and a sequence identifier. Each transaction initiated on the blockchain network 302 may include a fee attached by client 308 (e.g., as part of a specification). The fee may be used by validator 306 to submit transaction 314 to blockchain 304. The free-form field may include a natural language specification. The validator is responsible for performing actions according to the natural language specification in the free-form field by supplying the natural language specification via LLM. As described, the sequence identifier indicates an existing associated sequence of the transaction or indicates that the transaction initiates a new sequence.

[0073] In some implementations, fees may be used to determine the order of sequential transactions within a block corresponding to the execution order. Fees can act as a deterrent against denial-of-service (DoS) attacks, as it would be costly for a malicious attacker to overload the network with spam transactions. By requiring payment of a fee, system 300 can distinguish the most economically important transactions from less important ones. The fee structure allows for load reduction during periods of network congestion, enabling system 300 to prioritize the most important transactions and delay less important transactions until later times when network conditions are less congested. In some implementations, the transaction fee paid by users or transaction issuers is equal to the amount they bid or submit as a transaction fee, according to a first price auction mechanism approach. In some implementations, the transaction fee paid by users or transaction issuers is set not by their own submitted bid amount, but by the k-th highest bid in the current transaction block, leading to a more robust and predictable k-th price auction mechanism.

[0074] The collected transaction fees can be handled in various ways. Fees may be burned in whole or in part, effectively removing the funds from circulation. Alternatively, fees may be distributed as rewards to validators (e.g., validator 306) who performed the computationally intensive work of processing and verifying transactions on the network.

[0075] In some implementations, client 308 may submit a transaction that should not be executed if it is based on one or more fee conditions. For example, a transaction should not be executed if there is a preceding transaction paying a higher fee. These conditions can be specified in a transaction or dialogue (e.g., "move the bishop to E7 if it is the 17th move in chess" or "exchange X tokens for Y tokens only if the price offered by the decentralized exchange sequence is 2Y or more per X"). Transactions (as in consensus protocols) may simply sort transactions based on the proposed fee without the concept of failed transactions (e.g., transactions with valid signatures that fail to make changes to the global state).

[0076] According to the embodiment, system 300 may support deterministic and / or non-deterministic LLMs. In some implementations, the LLM instance utilized by the validator exhibits determinism, leading to the same set of state modifications on the validator. To ensure this is true, a non-deterministic LLM may be constructed as a deterministic component that receives its source of randomness from an external source. For example, random beacons on a blockchain have multiple implementation techniques that result in different intensities of randomness and can be utilized by system 300. The specific technique used by the LLM may be commensurate with the amount of value secured by the sequence.

[0077] In some implementations, the functions and operations of system 300 may be performed by one or more program modules of a computing platform. The computing platform may include electronic storage (e.g., database 152), and a processor (e.g., processor 212) and / or other components configured to provide information processing capabilities in the computing platform. The computing platform may be operablely linked via one or more electronic communication links to a remote platform. The computing platform may include multiple hardware, software, and / or firmware components that work together to provide functions attributed to the computing platform as described herein. For example, the computing platform may be implemented by a cloud of computing platforms working together as a computing platform.

[0078] The remote platform may include a client computing device which may include one or more processors, each configured to run a computer program module. The computer program module may be configured to enable an expert or user associated with a given remote platform to interface with system 300 and / or external resources, and / or provide the remote platform with other functions arising herein. For example, external resources may include externally designed blockchain elements and / or applications designed by a third party. In some implementations, some or all of the functions arising herein from external resources may be provided by resources included in system 300.

[0079] Electronic storage may include non-temporary storage media that electronically store information. The electronic storage media of electronic storage may include, for example, one or both of the system storage provided in conjunction with removable storage that is removablely connectable to the computing platform and / or removable storage that is removablely connectable to the computing platform via a port (e.g., a USB port, a FireWire port, etc.) or a drive (e.g., a disk drive, etc.). Electronic storage may include one or more of the following: optically readable storage media (e.g., optical discs, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drives, floppy drives, etc.), charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drives, etc.), and / or other electronically readable storage media. Electronic storage may include one or more virtual storage resources (e.g., cloud storage, a virtual private network, and / or other virtual storage resources). Electronic storage may store software algorithms, information determined by a processor, information received from a computing platform, information received from a remote platform, and / or other information that enables the computing platform to function as described herein.

[0080] The techniques described herein may be implemented as a method performed by a physical computing device, as one or more non-temporary computer-readable storage media that store instructions causing the method to be performed when executed by a computing device, or as a physical computing device specially configured with a combination of hardware and software that causes the method to be performed.

[0081] Figure 4 shows an exemplary flowchart (e.g., process 400) for executing a transaction on a blockchain network according to a particular aspect of the present disclosure. For illustrative purposes, the steps of the exemplary process 400 are described herein as occurring sequentially or linearly. However, multiple instances of the exemplary process 400 may occur in parallel, overlapping in time, occurring nearly simultaneously, or in an order different from the order shown in process 400. In addition, the blocks of the exemplary process 400 do not have to be performed in the order shown, and / or one or more blocks of the exemplary process 400 may not be performed.

[0082] In step 402, process 400 may include receiving (or accepting) natural language input specifying a transaction to be performed on the blockchain. For example, a transaction may be submitted by a user, broadcast to the blockchain network, and accepted by a validator node. The validator node may verify the transaction based on, for example, the blockchain network protocol. In addition to free-form fields including natural language input, fee and sequence ID fields may be specified in the transaction.

[0083] In step 404, process 400 may include identifying the transaction intent and contextual information associated with the transaction based on natural language input. An ML model may be embedded in a validator node and utilized to interpret the transaction intent specified by the user. The ML model may include an LLM configured for understanding and analyzing natural language. According to the embodiment, the ML model (or LLM) may be trained on a large dataset from the internet, one or more external sources, etc. Contextual information is encoded into the model's state based on the training dataset. According to the embodiment, the ML model (or LLM) may be trained on at least one natural language (e.g., English, Spanish, Japanese, etc.) used to specify the transaction. According to the embodiment, the version of the ML model (or LLM) is specified in the transaction.

[0084] According to some embodiments, the sequence ID field may associate a transaction with an existing sequence of related transactions using a unique identifier associated with the sequence. Each sequence may instantiate a specific instance or version of the LLM. According to some embodiments, a sequence ID of zero creates a new sequence of related transactions and assigns it a new unique sequence identifier. For example, if a transaction specifies that the interaction has a sequence ID of 37, the transaction will be processed using the same LLM of sequence 37.

[0085] Step 406 may include process 400 identifying an action corresponding to the natural language input based on intent and context information. The action may include a set of constraints, conditions, or rules. According to some embodiments, the intent of a transaction may be interpreted using multiple LLMs. A transaction may specify that multiple LLMs should be used to interpret the transaction. In some implementations, multiple LLMs may result in different interpretations. A part of the embodiment may include reversing the transaction based on at least two of the multiple LLMs that generate an ambiguous action.

[0086] According to some embodiments, the actions interpreted by the LLM may be output to the user in natural language. This allows the user to verify that the actions taken when executing a transaction match the user's intent.

[0087] In step 408, process 400 may include executing a transaction on the blockchain based on the action, which results in a change in the state of the blockchain maintained by the validator nodes.

[0088] The techniques described herein (e.g., process 400) may be implemented as a method performed by a physical computing device, or as one or more non-temporary computer-readable storage media that store instructions causing the method to be performed when performed by a computing device, or as a physical computing device specially configured with a combination of hardware and software that causes the method to be performed.

[0089] In some implementations, one or more operational blocks in Figure 4 may be performed by a processor circuit that executes instructions stored in a memory circuit, client device, remote server, or database, all of which are connected via a network (e.g., processor 212, memory 220, participant 110, participant 130, database 152, and network 150).

[0090] Figure 4 shows an exemplary block of process 400, but in some implementations, process 400 may include additional blocks, fewer blocks, different blocks, or blocks arranged differently from those shown in Figure 4.

[0091] Hardware Overview Figure 5 is a block diagram showing an exemplary computer system 500 that can implement aspects of the subject technology. In a particular embodiment, the computer system 500 may be implemented using hardware, or a combination of software and hardware, either as a dedicated server, integrated into another entity, or distributed across multiple entities.

[0092] A computer system 500 (e.g., a server and / or participant) includes a bus 508 or other communication mechanism for transmitting information and a processor 502 (e.g., a processor 212) coupled to the bus 508 for processing information. For example, a computer system 500 may be implemented by one or more processors 502. Each of the one or more processors 502 may be a general-purpose microprocessor, a microcontroller, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a programmable logic device (PLD), a controller, a state machine, gated logic, a discrete hardware component, or any other suitable entity capable of performing computation or other operations on information.

[0093] In addition to the hardware, the computer system 500 may include code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or one or more combinations thereof, stored in the accompanying memory 504, such as code that creates an execution environment for the computer program, for example, random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable PROM (EPROM), registers, hard disk, removable disk, CD-ROM, DVD, or any other suitable storage device coupled to the bus 508 for storing information and instructions executed by the processor 502. The processor 502 and memory 504 may be supplemented by or incorporated into special-purpose logic circuits.

[0094] Instructions may be stored in memory 504 and implemented in one or more modules of computer program instructions, i.e., one or more computer program products, i.e., one or more modules of computer program instructions, which are encoded on a computer-readable medium for execution by the computer system 500 or for controlling the operation of the computer system 500, in accordance with any method well known to those skilled in the art, including but not limited to computer languages ​​such as data-oriented languages ​​(e.g., SQL, dBase), system languages ​​(e.g., C, Objective-C, C++, Assembly), architecture languages ​​(e.g., Java, .NET), and application languages ​​(e.g., PHP, Ruby, Perl, Python). Instructions can also be implemented in computer languages ​​such as array languages, aspect-oriented languages, assembly languages, authoring languages, command-line interface languages, compiled languages, concurrent languages, curly brace languages, data flow languages, data structure languages, declarative languages, esoteric languages, extended languages, fourth-generation languages, functional languages, interactive mode languages, interpreted languages, iterative languages, list-based languages, little languages, logic-based languages, machine languages, macro languages, metaprogramming languages, multi-paradigm languages, numerical analysis, non-English-based languages, object-oriented class-based languages, object-oriented prototype-based languages, offside rule languages, procedural languages, reflexive languages, rule-based languages, scripting languages, stack-based languages, synchronous languages, syntactic processing languages, visual languages, Worth languages, and XML-based languages. Memory 504 can also be used to store temporary variables or other intermediate information during the execution of instructions performed by processor 502.

[0095] The computer programs described herein do not necessarily correspond to files in a file system. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., a file storing one or more modules, subprograms, or portions of code). Computer programs may be deployed to run on one or more computers located at one site or distributed across multiple sites and interconnected by a communication network. The processes and logical flows described herein can be performed by one or more programmable processors executing one or more computer programs to perform their functions by manipulating input data and producing outputs.

[0096] The computer system 500 further includes a data storage device 506, such as a magnetic disk or optical disk, coupled to a bus 508 for storing information and instructions. The computer system 500 may be coupled to various devices via an input / output module 510. The input / output module 510 can be any input / output module. An exemplary input / output module 510 includes a data port, such as a USB port. The input / output module 510 is configured to connect to a communication module 512. An exemplary communication module 512 includes a networking interface card, such as an Ethernet card and a modem. In certain embodiments, the input / output module 510 is configured to connect to multiple devices, such as an input device 514 and / or an output device 516. An exemplary input device 514 includes a keyboard and a pointing device, such as a mouse or trackball, through which a user can provide input to the computer system 500. Other types of input devices can also be used to provide user interaction, such as a tactile input device, a visual input device, a voice input device, or a brain-computer interface device. For example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback, and input from the user may be received in any form, including acoustic, voice, tactile, or electroencephalogram (EEG) input. An exemplary output device 516 includes a display device such as an LCD (liquid crystal display) monitor for displaying information to the user.

[0097] According to one aspect of the present disclosure, the system described above can be implemented using a computer system 500 in response to a processor 502 executing one or more sequences of one or more instructions contained in a memory 504. Such instructions may be read into the memory 504 from another machine-readable medium, such as a data storage device 506. The execution of a sequence of instructions contained in the main memory 504 causes the processor 502 to perform the process steps described herein. One or more processors in a multiprocessing configuration may also be used to execute a sequence of instructions contained in the memory 504. In alternative embodiments, hard-wired circuits may be used instead of or in combination with software instructions to implement various aspects of the present disclosure. Thus, aspects of the present disclosure are not limited to any specific combination of hardware circuits and software.

[0098] Various embodiments of the subject matter described herein can be implemented in a computing system that includes, for example, backend components such as data servers, middleware components such as application servers, or frontend components such as client computers having a graphical user interface or a web browser, and a user can interact with the implementation of the subject matter described herein through the graphical user interface or a web browser, or with any combination of one or more such backend, middleware, or frontend components. The components of the system can be interconnected by any form or medium of digital data communication, such as a communication network. The communication network may include, for example, one or more of LANs, WANs, and the Internet. Furthermore, the communication network may include, but is not limited to, one or more of the following network topologies, such as bus networks, star networks, ring networks, mesh networks, starbus networks, tree or hierarchical networks. The communication module may be, for example, a modem or an Ethernet card.

[0099] The computer system 500 may include a client and a server. The client and server are generally remote from each other and typically interact through a communication network. The client-server relationship is established by computer programs running on each computer that have a client-server relationship with each other. The computer system 500 may be, for example, a desktop computer, a laptop computer, or a tablet computer, for example. The computer system 500 may also be embedded in another device, for example, a mobile phone, a PDA, a mobile audio player, a Global Positioning System (GPS) receiver, a video game console, and / or a television set-top box, for example.

[0100] The terms “machine-readable storage medium” or “computer-readable medium” as used herein refer to any medium or medium involved in providing instructions to the processor 502 for execution. Such mediums can take many forms, including but not limited to non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks such as data storage device 506. Volatile media include dynamic memory such as memory 504. Transmission media include coaxial cables, copper wires, and optical fibers, including wires that constitute bus 508. Common forms of machine-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tapes, any other magnetic media, CD-ROMs, DVDs, any other optical media, punch cards, paper tapes, any other physical media having a pattern of holes, RAM, PROMs, EPROMs, FLASH EPROMs, any other memory chips or cartridges, or any other media that a computer can read. A machine-readable memory medium can be a machine-readable memory device, a machine-readable memory substrate, a memory device, a composition of a substance that affects machine-readable propagated signals, or a combination of one or more of these.

[0101] The phrase “at least one of” preceding a set of items, accompanied by the terms “and” or “or” to separate any of the items, when used herein, qualifies the list as a whole, rather than each member of the list (i.e., each item). The phrase “at least one of” does not require the selection of at least one item; rather, it allows for meanings including at least one of any one of the items, and / or at least one of any combination of the items, and / or at least one of each of the items. For example, the phrases “at least one of A, B, or C” or “at least one of A, B, or C” refer to A only, B only, or C only, any combination of A, B, and C, and / or at least one of each of A, B, and C, respectively.

[0102] To the extent that terms such as “include” and “have” are used in the description or claims, such terms are intended to be inclusive in the same manner as the term “comprise” is interpreted as “comprise” when used as a transitional term in a claim. The term “exemplary” is used herein to mean “serving as an example, case, or illustration.” No embodiment described herein as “exemplary” should necessarily be construed as being preferable or advantageous to any other embodiment.

[0103] References to elements in the singular form are intended to mean "one or more" rather than "one and only one" unless specifically stated otherwise. All structural and functional equivalents to the elements of the various configurations described throughout this disclosure, whether known to those skilled in the art or later known, are expressly incorporated herein by reference and are intended to be encompassed by the subject art. Furthermore, nothing disclosed herein is intended to be for the public only, whether such disclosure is expressly enumerated in the above specification.

[0104] While this specification contains many details, these should not be interpreted as limitations on the scope of claims, but rather as descriptions of specific implementations of the subject matter. Certain features described herein in the context of separate embodiments can be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment can be implemented separately in multiple embodiments or in any preferred partial combination. Furthermore, features described above as acting in a particular combination and initially claimed as such, may in some cases be removed from the claimed combination, and the claimed combination may be subject to partial combinations or variations of partial combinations.

[0105] While the subject matter of this specification is described in terms of a particular embodiment, other embodiments can be implemented and are within the scope of the following claims. For example, although the operations are depicted in a particular order in the drawings, this should not be understood as meaning that such operations must be performed in a specific order or sequence shown, or that all illustrated operations must be performed in order to achieve a desired result. The actions enumerated in the claims can be performed in a different order and still achieve the desired result. As an example, the processes depicted in the accompanying drawings do not necessarily require a specific order or sequence shown to achieve a desired result. In certain circumstances, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system components in the embodiments described above should not be understood as meaning that such separation is necessary in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged in multiple software products. These are within the scope of the claims in other variant forms.

[0106] In this specification, it should be understood that the original applicant will determine which technologies to use and / or commercialize, and what is best for the technology and its users, based on the usefulness and relevance of the technologies in an ever-evolving field. Accordingly, the systems and methods described herein may not yet be used by the original applicant, and / or may not be used, and / or commercialized in the future. It should also be understood that any implementation and use of the systems and methods described herein will be carried out by the original applicant in accordance with its privacy policy, if any. These policies are intended to respect and prioritize user privacy and are intended to meet or exceed the governmental and legal requirements of the respective jurisdictions. To the extent that such implementation or use of these systems and methods enables or requires the processing of users' personal information, such processing will be carried out in accordance with (i) the Privacy Policy outlined herein, (ii) an effective legal mechanism including, but not limited to, providing appropriate notice, or, where necessary, obtaining the consent of the respective user, and (iii) the user's privacy settings or preferences. Furthermore, it should be understood that the original applicant intends that, if implemented or used by other entities, the systems and methods described herein will comply with privacy policies and practices consistent with their purpose of respecting user privacy.

Claims

1. A computer implementation method for executing transactions on a blockchain platform, Receiving natural language input specifying transactions to be performed on the blockchain, Using a machine learning (ML) model, identify intent and context information associated with the transaction based on the natural language input, Based on the intent and the context information, identify the action corresponding to the natural language input, Based on the aforementioned action, the transaction is executed on the blockchain, Computer implementation methods, including those mentioned above.

2. The computer implementation method according to claim 1, wherein the ML is incorporated within a validator of a blockchain network.

3. The computer implementation method according to claim 1, wherein the ML model includes a learning language model (LLM) for interpreting the natural language input.

4. The computer implementation method according to claim 1, wherein the ML model is trained on a large dataset from multiple sources.

5. The computer implementation method according to claim 1, wherein the transaction corresponds to a smart contract, and the action corresponds to a condition of the smart contract identified based on the natural language input and the context information.

6. The computer implementation method according to claim 1, wherein the transaction is associated with a sequence of transactions that instantiate and modify the state of the ML model, and each sequence is assigned a unique identifier.

7. The computer implementation method according to claim 1, wherein the transaction includes at least one of a fee, a free-form field including the natural language input, and sequence identification information (ID) including a unique identifier associated with the set of transactions.

8. The computer implementation method according to claim 1, wherein the version of the ML model is specified within the transaction.

9. The computer implementation method according to claim 1, wherein a series of transactions are processed using the same version of the ML model.

10. The computer implementation method according to claim 1, wherein the ML model is trained in at least the natural language used to specify the transaction.

11. Identifying the aforementioned intent and context information is, Interpreting the transaction using multiple LLMs, Based on the fact that at least two of the aforementioned LLMs generate ambiguous actions, the transaction is reversed. The computer implementation method according to claim 1, including the method described in claim 1.

12. A system for executing transactions on a blockchain platform, One or more processors, A memory in which instructions are stored, and when an instruction is executed by one or more processors, the one or more processors, Receiving natural language input specifying transactions to be performed on the blockchain, Using a Learning Language Model (LLM), identify intent and context information associated with the transaction based on the natural language input, Based on the intent and the context information, identify the action corresponding to the natural language input, Based on the aforementioned action, the transaction is executed on the blockchain, A system that enables this to happen.

13. The system according to claim 12, wherein the LLM is incorporated within a validator of the blockchain network.

14. The system according to claim 12, wherein the LLM is trained on a large dataset from multiple sources and on natural language used to specify the transactions.

15. The system according to claim 12, wherein the transaction corresponds to a smart contract, and the action corresponds to a condition of the smart contract identified based on the natural language input and the contextual information.

16. The system according to claim 12, wherein the transaction is associated with a sequence of transactions that instantiate and modify the state of the LLM, and each sequence is assigned a unique identifier.

17. The system according to claim 12, wherein the transaction includes at least one of a fee, a free-form field including the natural language input, and sequence identification information (ID) including a unique identifier associated with the series of transactions.

18. The system according to claim 12, wherein the version of the LLM is specified within the transaction, and the set of transactions is processed using the version of the LLM.

19. Identifying the aforementioned intent and context information is, Interpreting the transaction using multiple LLMs, Based on the fact that at least two of the aforementioned LLMs generate ambiguous actions, the transaction is reversed. The system according to claim 12, including the above.

20. A non-temporary computer-readable storage medium in which instructions are stored, wherein, when an instruction is executed by one or more processors, it causes the one or more processors to perform an operation for executing a transaction on a blockchain platform, and the operation is Receiving natural language input specifying transactions to be performed on the blockchain, Using a learning language model (LLM) embedded within the blockchain validator, the intent and context information associated with the transaction are identified based on the natural language input. Based on the intent and the context information, identify the action corresponding to the natural language input, Based on the aforementioned action, the transaction is executed on the blockchain, Non-temporary computer-readable storage media, including [specific type of storage medium].

Images