Systems and methods for optimistic machine learning (OPML) on blockchain

Abstract

Embodiments of the present disclosure are directed to systems and methods for optimistic machine learning on blockchain (opML) that provide an integrated framework of one or more machine learning (ML) models with blockchain technology, driven by the vision of decentralized, secure, and transparent artificial intelligence (AI) services. The combination of blockchain and AI through opML, the opML systems and methods provide a transformative platform with paradigm shift toward accessible, secure, and efficient onchain machine learning. An opML system comprises an offchain system including a machine learning engine and an offchain fraud proof engine, the machine learning engine receiving a user's input and a local-environment executable file, the offchain fraud proof engine for receiving the user's input and a fraud proof virtual machine executable file, wherein given the same user's input, both the machine learning engine and the FP engine generating the same output.

Description

Systems and Methods for Optimistic Machine Learning (opML) on Blockchain

[0001] Inventors: Canhui Chen

[0002] Jiatian. Wang

[0003] Xiaohang Yu

[0004] CROSS REFERENCE TO RELATED APPLICATIONS

[0005] This application claims priority to and the benefit of U.S. Provisional Application Ser. No. 63 / 557,791 entitled “Systems and Methods for Optimistic Machine Learning (opML) on Blockchain, ” filed on 26 February 2024, the disclosure of which is incorporated herein by reference in its entirety.BACKGROUNDTechnical Field

[0006] The present disclosure generally relates to blockchain and artificial intelligence technologies, and more particularly to integration of machine learning and blockchain.

[0007] Background Art

[0008] In the rapidly evolving digital landscape, technological innovations are continually reshaping the way the society interacts with and harnesses the power of information. Among various innovations, the convergence of two remarkable forces, Artificial Intelligence (AI) and blockchain technology, stands out as a pivotal development. AI, with its capacity for advanced data analysis and decision-making, and blockchain, a decentralized ledger known for its security and transparency, have joined forces to explore new frontiers in the digital realm. As two emerging powerful forces, each with its distinct capabilities, AI and blockchain are now merging to redefine boundaries and to extend what is possible in the digital world. This synergy has given rise to the concept known as "Onchain AI, ” a paradigm that holds the promise of delivering decentralized, secure, and efficient AI services directly within the blockchain network.

[0009] However, a prevalent challenge in the current landscape of "Onchain AI" is the infeasibility of conducting AI computations directly on chain. For example, a simple task of matrix multiplication of 1000 x 1000 integers would cost over 3 billion gas,  which far exceeds the current Ethereum’s block gas limit. Consequently, most of these  resort to off-chain computations on centralized servers, uploading only the results onto the blockchain. While this strategy may yield functional results, it inherently sacrifices decentralization. Such a trade-off not only poses significant security challenges but also diminishes the core principles of trust and transparency that blockchain technology aims to uphold.

[0010] One alternative approach is to leverage zero-knowledge machine learning (zkML) . zkML represents a new paradigm in the integration of machine learning and blockchain. zkML’s reliance on zk-SNARKs (zero-knowledge succinct non-interactive arguments of knowledge) has been instrumental in safeguarding confidential model parameters and user data during the training and inference processes. This not only mitigates privacy concerns but also reduces the computational burden on the blockchain network, making zkML a promising candidate for decentralized ML applications.

[0011] While zkML undeniably presents a range of advantages in enhancing privacy and security within machine learning on the blockchain, it is crucial to acknowledge its inherent limitations. One of the most significant challenges is the high cost associated with proof generation in zkML. The process demands considerable computational resources, resulting in extended generation times and substantial memory consumption. Consequently, zkML is most suitable for relatively small models, as its inefficiency becomes apparent when handling larger and more complex models. zkML would take more than 1000 times the memory and computation consumption for the ZK proof generation. As a result, zkML may prove undesirable, and even impractical, for extensive AI applications that require the processing of substantial datasets and intricate model parameters.

[0012] It is therefore desirable to have methods and systems with fraud proof to prove the correctness of the machine learning (ML) results on chain, rather than using the zero-knowledge proof (ZKP, also known as validity proof) .

[0013] SUMMARY OF THE DISCLOSURE

[0014] Embodiments of the present disclosure are directed to systems and methods for optimistic machine learning on blockchain (opML) that provide an integrated framework of one or more machine learning (ML) models with blockchain technology, driven by the vision of  decentralized, secure, and transparent artificial intelligence (AI) services. By combining the capabilities of blockchain and AI through opML, the opML systems and methods provide a transformative platform with paradigm shift toward accessible, secure, and efficient onchain machine learning.

[0015] In a first aspect of the present disclosure, the inconsistency in machine learning results can be attributed to two factors: randomness and variability in floating-point computations. To address randomness, fixing the random seed in the random number generator is a common practice since computer-generated randomness is essentially pseudo-randomness. On the inconsistency in floating-point computations, during the native execution of deep neural network (DNN) computations, especially across diverse hardware platforms, differences in execution result may arise due to the nature of floating-point numbers. To tackle these challenges and ensure the consistency of opML, the present disclosure describes two key approaches. The first approach is a fixed-point arithmetic, also known as quantization technology. A fixed-point arithmetic module is configured to represent and perform computations using fixed precision rather than floating-point numbers. By doing so, the effect of floating-point rounding errors can be mitigated or reduced, leading to a more reliable and consistent result. A second approach is to leverage software-based floating-point libraries (softfloat) that are designed to function consistently across different platforms. The software-based floating-point libraries ensure a cross-platform consistency and determinism of machine learning results, irrespective of the underlying hardware or software configurations. The combination of a fixed-point arithmetic and software-based floating-point libraries provide a robust foundation for achieving consistent and reliable machine learning results within an opML framework.

[0016] In a second aspect of the present disclosure, following the design principle ``separate execution from proving” , the present disclosure provides a highly efficient machine learning engine for opML. There are two approaches on how the machine learning program is executed.. The first approach is to compile the machine learning program for native execution, which is optimized for high speed. A multi-thread CPU and GPU are used to speed up the native execution. A second approach is to compile a fraud proof program for a fraud proof virtual machine (FPVM) . This dual-target approach assures that the execution is fast, while proving is based on the machine-independent code. For example, in a matrix multiplication in the machine learning engine, a native execution employs GPU calculation (CUDA calculator) for acceleration. For the proving phase, the machine learning engine is configured to compile into machine-independent FPVM instructions. The two implementations yield consistent execution results.

[0017] In a third aspect of the present disclosure, the disclosed protocol addresses disagreements between a submitter and a verifier regarding the outcome in a sequence of virtual machine instructions executed within a virtual machine state . The protocol operates through iterative rounds where both parties initially agree on a starting VM state but disagree on an ending state, where the starting position is smaller than the ending position. Each round involves a challenger identifying a middle virtual machine (VM) state, which is then confirmed or disputed by a submitter. In a first scenario where the challenger and the submitter agree, the starting position is modified to a middle position, and the focus shifts to resolving the disagreement between the starting position and ending position. In a second scenario where the challenger and the submitter disagree, the ending position is modified to the middle position and the attention turns to resolving the disagreement between the starting position and ending position. This process continues, halving the scope of disagreement each round until the process converges to a single instruction, facilitating an efficient dispute resolution. In an onchain arbitration scenario, the agreed-upon state, along with its fraud proof and supporting data, are sent to a smart contract. The contract employs an onchain virtual machine to execute a single instruction based on a partially expanded Merkle tree, ensuring a minimal computational and memory usage suitable for Ethereum gas limits. The arbitration outcome is determined by the validity of the challenger's proof. A success validates the claim, while a failure results in victory for the submitter.

[0018] In a fourth aspect of the present disclosure, the present disclosure describes a multi-phase protocol. The multi-phase dispute game comprises the following properties: Firstly, {Semi-Native Execution} : with the multi-phase design, the computation is conducted in the virtual machine (VM) only in the final phase, resembling a single-phase protocol. For other phases, there is flexibility to perform computations that lead to state transitions in the native environment, leveraging the capabilities of parallel processing in CPU (s) , GPU (s) , or even TPU (s) . By reducing the reliance on the virtual machine, the overhead is significantly minimized, resulting in a remarkable enhancement in the execution performance of the opML system, almost akin to that of the native environment. Secondly, {Lazy Loading Design} : to optimize the memory usage and performance of the fraud proof virtual machine, a lazy loading technique is implemented. The lazy loading technique means not loading all of the data into the virtual machine memory at once, but loading only the keys that identify each data item. When the virtual machine requires access to a specific data item, the virtual machine uses a key to fetch from an external source and load data into the memory. Once the data item is no longer needed, the data item is swapped out of the memory to free up space for other data items. In this way, large amounts of data can be processed without exceeding a memory capacity or compromising the efficiency of the virtual machine.

[0019] In a first feature of opML {Deterministic ML Execution} , the native ML execution may result in different execution results due to the randomness and computation on floating-point numbers. opML adopts the fixed-point arithmetic, the cross-platform floating point module and the deterministic random library to guarantee the consistency and determinism of the ML execution. Therefore, a deterministic state transition function is used to represent the ML execution process.

[0020] In a second feature of opML {Separate Execution from Proving} , the opML takes the same source code and compiles the source code twice. A first compilation is for native execution, which is optimized for speed. A multi-thread CPU and GPU may be used to speed up the native execution. In the second compliation, the same source code is also compiled to for fraud proof virtual machine (VM) instruction.

[0021] In a third feature of opML {Optimistic Machine Learning with Interactive Fraud Proofs} , the opML adopts an interactive fraud proof, which bisects a dispute down to a single instruction, and resolves the base-case using the onchain fraud proof virtual machine.

[0022] In a fourth feature of opML {Optimizing ML fraud proof with Multi-Phase Protocol} , the existing fraud proof systems that are widely adopted in optimistic rollup systems require to cross-compile the whole computation into fraud proof VM instructions, which results in inefficient execution and huge memory consumption. The opML of the present disclosure provides a multi-phase protocol, which allows a semi-native execution and lazy loading, which significantly speeds up the fraud proof process.

[0023] Broadly stated, a opML system comprises an offchain system including a machine learning (ML) engine and an offchain fraud proof (FP) engine, the machine learning engine receiving a user’s input and a local-environment executable file, the offchain fraud proof engine receiving the user’s input and a fraud proof virtual machine (FPVM) executable file, wherein given the same user’s input, both the machine learning engine and the FP engine generate the same output; wherein during the fraud proof generation process of FP engine, the machine learning engine is configured to speed up the execution in the FPVM; an onchain system, communicatively coupled to the offchain system, including a dispute game contract module and an onchain FP engine, the dispute game contract module configured to record at least one interaction of different opML nodes, and configured to locate a dispute point, the dispute game contract module sending the dispute point to the onchain FP engine for arbitration, the onchain FP engine configured to conduct an onchain arbitration; wherein the offchain FP engine is configured to provide the same execution trace as the onchain FP engine.

[0024] Where a cross-compiler is coupled to both the a machine learning engine and the offchain fraud proof (FP) engine, the cross-compiler generates the local-environment executable file and the FPVM executable file. The offchain FP engine comprises a FPVM and a fraud proof generator, the FPVM configured to load the FPVM executable file and the user’s input, and subsequently generate the FPVM state at a specific position, the fraud proof generator coupled to the FPVM and configured to generate the corresponding fraud proof at a specific position. The onchain FP engine comprises a fraud proof (FP) verifier and a FPVM, the fraud proof verifier configured to check the correctness of a fraud proof, and subsequently load a set of data into the onchain FPVM for computation, the set of data having the FPVM registers data and memory data. Responsive to a previous FPVM state and the set of data, the onchain FPVM is configured to conduct a one-step execution to generate the next FPVM state.

[0025] The machine learning engine comprises a machine learning executor configured to process the user input and the local-environment executable file within the offchain system to generate an inference result based on the user input; a communication module configured to enabling a bidirectional exchange between the machine learning engine and the offchain fraud proof engine; wherein the machine learning engine receives a host function input from the offchain fraud proof engine via the communication module; and wherein a host function executor is configured to compute on the host function input to generate a host function output, and subsequently relay the host function output back to the offchain fraud proof engine.

[0026] A method for ensuring deterministic at least one machine learning result in an optimistic machine learning (opML) system that comprises (a) providing a consistent result of at least one floating-point operation across diverse hardware and software configurations by replacing a hardware-dependent floating-point calculation with the cross-platform floating-point module, thereby maintaining the integrity and reproducibility of ML program outcomes, the cross-platform floating-point module integrated within a cross-compiler; (b) mitigating one or more floating-point rounding errors of an output generated from the hardware-dependent floating d-point calculation during a machine learning program execution by integrating a fixed-point arithmetic into the cross-compiler, thereby ensuring consistent and reliable results; and (c) generating a sequence of numbers that are deterministic under the same initial conditions or seed by integrating a deterministic random library into the cross-compiler.

[0027] In some embodiments, the method further comprises receiving a user input and a local-environment executable file by a machine learning engine; and generating an inference result based on the user input by machine learning executor.

[0028] A method embodiment comprises generating a fraud proof virtual machine (FPVM) state and the corresponding fraud proof comprises loading a fraud proof virtual machine executable file compiled by a cross-compiler; receiving a user input for execution by a machine learning program within the fraud proof virtual machine; responsive to receiving the user input, executing, by the fraud proof engine, the machine learning program within the fraud proof virtual machine, until reaching a predetermined position; capture execution state: at the specified position, the fraud proof engine captures the execution state of the FPVM, including memory and function inputs and results; generates fraud proof virtual machine state: using the captured execution state, the fraud proof engine generates the fraud proof virtual machine state, which represents a snapshot of the program's execution at the specified position; produce fraud proof: Based on the captured execution state, the fraud proof engine utilizes a fraud proof generator to produce a fraud proof, which serves as evidence of the program's execution integrity.

[0029] An opML method comprises generating, by the cross-compiler, a local-environment executable file and a fraud proof virtual machine executable file, in response to executing a machine learning program; responsive to a user’s input, generating an inference result using a machine learning engine based on the local-environment executable file; generating a fraud proof virtual machine state and a fraud proof at a specific position by the offchain fraud proof engine based on the fraud proof virtual machine executable file; responding or starting a challenge in a dispute game by an onchain dispute game contract module based on the fraud proof virtual machine state; and generating an onchain arbitration result by the onchain fraud proof engine with the previous fraud proof virtual machine state and the corresponding fraud proof.

[0030] A method embodiment comprises starting a challenge of a dispute game comprises initializing one or more dispute game parameters; setting an initial starting position (start_position) to zero and an ending position (end_position) to the length of an execution trace; generating, by a fraud proof (FP) engine, a fraud proof virtual machine (VM) state (FPVM state) at the ending position; and submitting the fraud proof virtual machine state to a dispute game contract module to initiate a challenge for an onchain submitted result, thereby triggering a commencement of an interactive dispute game where at least one opML node participatea in the verification and validation of the FPVM state, wherein the challenge of a dispute game is initiated when an onchain submitted result is inconsistent with a local generated result. The method further comprises (a) continuously monitoring an interactive dispute game by a dispute game monitor to at least one response from at least one participating opML node; (b) upon receiving at least one response by a first (responding) opML node, calculating the middle position (middle_position) between a starting position (start_position) and an ending position (end_position) ; generating, by the  offchain fraud proof (FP) engine associated with a second (local) opML node, a first FPVM state at the middle position and submitting the FPVM state to an onchain dispute game contract module; (d) comparing the first FPVM state generated from the second (local) opML node with a second FPVM state generated by the first (responding) opML node: if the first FPVM state and the second FPVM are consistent, updating from the starting position to the middle position; if the first FPVM state and the second FPVM are not consistent, updating from the ending position to the middle position; and (e) recalculating the middle position, generating a third FPVM state based on the middle position by the second opML node, and submitting the FPVM state back to the dispute game contract module; and iterating steps (b) , (c) , (d) , (e) until a dispute point is reached, indicating a subsequent step is to enter into an onchain arbitration process, wherein the dispute point is reached when the starting position plus one is not less than the ending position. The method further comprises verifying a fraud proof generated by the offchain FP engine; upon verification, loading a portion of data from the fraud proof into the onchain Fraud-Proof Virtual Machine (FPVM) ; based on a previous FPVM state and the loaded data, the onchain FPVM is configured to conduct a one-step execution to generate the next FPVM state; comparing the FPVM state generated by the onchain FP Engine with the FPVM state provided by the second (local) opML node; if the FPVM state generated by the onchain FP Engine and the FPVM state provided by the second (local) opML node are consistent, declaring the second (local) opML as a winner of the dispute; and if inconsistencies are found between the FPVM state generated by the onchain FP Engine and the FPVM state provided by the second (local) opML node, declaring the second (local) opML node as losing the dispute. The method further comprises determining, by the fraud proof verifier, the authenticity and correctness of the fraud proof, thereby ensuring that the loaded data accurately reflects the previous FPVM state. The method further comprises generating a fraud proof virtual machine state onchain, comprising: based on the previous fraud proof virtual machine state and the corresponding fraud proof, the onchain FP engine is configured to process the information to generate the next fraud proof virtual machine state after the one-step execution.

[0031] A system embodiment comprises a requester module configured for sending an onchain request (by a user) ; a requester module configured for listening for the onchain request; a machine learning engine configured for receiving an onchain request and conducting (local) execution and providing an inference result; a submitter module configured for submitting an onchain inference result; if the onchain inference result is incorrect (which is inconsistent with the local executed version) , a dispute module is configured for a challenger to submit for a fraud proof verification; (if the onchain inference result is correct and) if the current node is challenged by  another node that prompts the current node to defend the correctness of the onchain inference result, the dispute module is configured for a challenger to submit for a fraud proof verification, wherein the dispute module includes (a) a first fraud proof virtual machine for offchain, (b) a first fraud proof virtual machine for onchain, (c) a machine learning program, (d) a cross-compiler to compile the machine learning program to fraud proof virtual machine binary code, (e) a dispute game contract on chain to record the interaction and for arbitration using onchain fraud proof virtual machine, (f) a dispute game monitor to monitor the status of the dispute game, and (g) a fraud proof submitter to submit the fraud proof to the dispute game contract.

[0032] A method embodiment comprises sending an onchain request by a requester module (from a user) ; listening for the onchain request by a requester module; receiving an onchain request from a machine learning engine; conducting (local) execution by the machine learning engine and providing an inference result; submitting an onchain inference result by a submitter module; if the onchain inference result is incorrect (inconsistent with the local executed version) , submitting for a fraud proof verification by a dispute module configured from a challenger; if the onchain inference result is correct and if the current node is challenged by another node that prompts the current node to defend the correctness of the onchain inference result, submit for a fraud proof verification by the dispute module configured from a challenger; wherein·the dispute module includes (a) a first fraud proof VM (FPVM) for offchain, (b) a first fraud proof VM (FPVM) for onchain, (c) a machine learning program, (d) a cross-compiler to compile the machine learning program to FPVM binary code, and (e) a dispute game contract on chain to record the interaction and for arbitration using onchain FPVM.

[0033] The structures and methods of the present disclosure are disclosed in detail in the description below. This summary does not purport to define the disclosure. The disclosure is defined by the claims. These and other embodiments, features, aspects, and advantages of the disclosure will become better understood with regard to the following description, appended claims, and accompanying drawings.BRIEF DESCRIPTION OF THE DRAWINGS

[0034] The disclosure will be described with respect to specific embodiments thereof, and reference will be made to the drawings, in which:

[0035] Figure 1 is an architectural diagram illustrating one embodiment of an optimistic machine learning (opML) on blockchain in accordance with the present disclosure.

[0036] Figure 2 is a flow chart illustrating a first embodiment of a process (also referred to as a workflow) 200 of the opML architecture 100 with a plurality of nodes in accordance with the present disclosure.

[0037] Figure 3 is a flow chart illustrating a second embodiment of the workflow 300 of the opML system 100 to process and execute a new user request in accordance with the present disclosure.

[0038] Figure 4 is a block diagram illustrating a cross-compiler 128 with a floating-point module 401 in the opML architecture 100 in accordance with the present disclosure.

[0039] Figure 5 is a block diagram illustrating one embodiment of functional flow of the machine learning engine 124 in accordance with the present disclosure.

[0040] Figure 6 is a block diagram illustrating one embodiment of the offchain fraud proof engine 132 in accordance with the present disclosure.

[0041] Figure 7 is a block diagram illustrating one embodiment of an onchain fraud proof (FP) engine 116 in accordance with the present disclosure.

[0042] Figure 8 is a flow diagram illustrating a process (workflow) of an opML node receiving a user request in accordance with the present disclosure.

[0043] Figure 9 is a block diagram illustrating one embodiment of a divergent locating workflow for single phase and multi-phase in accordance with the present disclosure.

[0044] Figure 10 is a block diagram illustrating one embodiment of a process (workflow) of an onchain AI oracle (OAO) as an application of opML in accordance with the present disclosure.

[0045] Figure 11 is a block diagram illustrating an example of a computer device on which computer-executable instructions to perform the blockchain methodologies discussed herein may be installed and executed.DETAILED DESCRIPTION

[0046] A description of structural embodiments and methods of the present disclosure is provided with reference to FIGS. 1-11. It is to be understood that there is no intention to limit the disclosure to the specifically disclosed embodiments, but that the disclosure may be practiced using other features, elements, methods, and embodiments. Like elements in various embodiments are commonly referred to with like reference numerals.

[0047] The following definitions apply to the elements and steps described herein. These terms may likewise be expanded upon.

[0048] Cross-compiler –The cross-compiler compiles the ML program (e.g., source code) into the FPVM binary code.

[0049] Execution trace –An execution trace refers to a record of sequence of operations executed by a software program during its run.

[0050] Fraud proof –Fraud proofs refer to providing proof that a state transition was wrong.

[0051] Inference result –given the user’s input, the inference result means the output of a specific AI model (ML program) .

[0052] ML engine (also referred to as machine learning engine) –The machine learning (ML) engine includes the machine learning program and the local execution environment, such as a GPU and CPU. Given an input to the machine learning engine, the machine learning engine conducts the execution locally and then provides (returns) the inference result.

[0053] ML program (also referred to as a machine learning program, or an AI model) –machine learning (ML) program refers to the source of a machine learning inference program with its associated model data.

[0054] Offchain FPVM (also referred to as “offchain fraud proof virtual machine” , or “offchain fraud proof VM” ) –In one embodiment, FPVM can function as a virtual machine with any architecture, for example, MIPS, RISC-V, WASM. After loading binary code into the FPVM, the FPVM executes a software program step by step and generates the corresponding fraud proof.

[0055] Onchain FPVM (also referred to as “onchain fraud proof virtual machine” , or “onchain fraud proof VM” ) –In one embodiment, FPVM functions as a virtual machine with any architecture, for example, MIPS, RISC-V, WASM. In one implementation, the onchain FPVM is implemented in a smart contract. Given a specific FPVM state and the corresponding fraud proof, the onchain FPVM conducts a one-step execution and generates the FPVM state in the next step (or the following step or the subsequent step) .

[0056] Position –refers to a non-negative number, representing the position in an execution trace.

[0057] Request (also referred to as a user request) – refers to a request for onchain AI inference initiated by a user. A request includes the user’s input.

[0058] Submitter module –refers to a module for the user to submit his request onchain, and it is also a module for an opML node to listen and receive the onchain request.

[0059] Virtual Machine (also referred to as VM) –A virtual machine is a software-based emulation of a physical computer that executes one or more software programs like a real machine.

[0060] The present disclosure describes using a fraud proof to prove the correctness of the ML results on chain instead of using the zero-knowledge proof (ZKP, also known as validity  proof) . Fraud proofs are used in blockchain systems, including rollup systems, which are part of a broader category known as optimistic systems. In a system using fraud proof, the system optimistically assumes that every proposed result is valid by default. In the case of mitigating potentially invalid results, the system using fraud proof introduces a challenge period during which participants may challenge the submitter. The fraud proof is generated via interactive pinpoint protocol proving that the provided result is incorrect. The arbitration process is designed to validate a fraud proof by executing only a few minor computation steps, making the onchain cost extremely low.

[0061] Building upon the foundation of optimistic system design, the present disclosure introduces an optimistic machine learning (opML) on the blockchain. Diverging from the approach of zkML, which relies on zero-knowledge proofs, opML adopts a fraud-proof system to guarantee the correctness of machine learning results. In the opML framework, submitters executes machine learning computations within a native environment and subsequently provide the results directly on the blockchain. This approach maintains an optimistic assumption that each proposed result is inherently valid. During the challenge process, validators checks the correctness of these submitted result. If the result is invalid, he will start the dispute game (bisection protocol) with the submitter and tries to disprove the claim by pinpointing one concrete erroneous step. Arbitration about a single step is conducted on smart contract. Table 1 below summarizes a comparison between opML and zkML.

[0062] Table 1

[0063] Figure 1 is an architectural diagram illustrating one embodiment of an optimistic machine learning (opML) architecture 100 (or “the opMl node 100” “opML system” ) on blockchain in accordance with the present disclosure. Specifically, the opML architecture 100 includes two parts, an onchain system 110 on blockchain and an offchain system 120. The onchain system 110 includes three modules on the blockchain, namely a request contract module 112, a dispute game  contract module 114 and an onchain fraud proof engine (also referred to as “onchain FP engine” ) 116. The offchain system 120 comprises six modules, namely, a submitter module 122, a machine learning engine (also referred to as “ML engine” ) 124, a machine learning program (also referred to as “ML program” ) 126, a cross-compiler 128, a dispute game monitor 130, and an offchain fraud proof engine 132. The architecture of opML 100 also includes one or more applications 134, e.g., an onchain AI oracle ( “OAO” ) 136.

[0064] From an opML node perspective, to provide an artificial intelligence (AI) inference service, there is the ML program 126, which includes the source code of an AI inference and an AI model. The cross-compiler 128 is a compiler that cross compiles the ML program 126 into two different targets (or two different paths) . A first target is directed to the offchain fraud proof engine 132. A second target is directed to the machine learning engine 124. To phrase it another way, the cross-compiler 128 cross compiles the machine learning program 126 and generates a first executable file (anative-environment executable file) two and a second executable file (the FPVM executable file) . For the first target, which is the machine learning engine 124, the cross compiler 132 cross complies and generates the native-envrionment executive file to the machine learning engine 124, wherein the machine learning engine 124 generates an output containing a first inference result 123. For the second target, which is the offchain fraud proof engine 132, the cross compiler 132 cross complies and generates the FPVM executable file to the offchain fraud proof engine 132, wherein the offchain fraud proof engine 132 an output containing (the FPVM state, corresponding fraud proof, and a second inference result) . The first inference result generated by machine learning engine 124 and the second inference result generated from the offchain fraud proof engine 132 are the same. In addition, the execution of the machine learning engine 124 and the offchain fraud proof engine 132 are deterministic (i.e., given the same input, both the machine learning engine 124 and the offchain fraud proof engine 132 generate the same output) .

[0065] A sample workflow for the opML 100 goes as follows. Initially, a user initiates an AI inference request to the request contract module 112. To phrase it another way, the request contract module 112 receives the AI inference request from a source, such as a user. The submitter module 122 listens 121 to an onchain user request. Upon receiving a user request by the submitter module 122, the submitter module 122 sends the request to the machine learning engine 124. The machine learning engine 124 runs in the local environment using the user’s input in the corresponding request, and then generates an inference result 123. The submitter module 122 submits 125 the inference request back to the request contract module 112. Next, the dispute game monitor 130 starts to monitor 115 the onchain dispute game contract module 114 to determine whether there is a challenge. When the dispute game monitor 130 finds that a dispute  game needs the current node to respond, the dispute game monitor 130 uses the offchain fraud proof engine 132 to generate a fraud proof 133 and the virtual machine state and then submits the fraud proof 133 and the virtual machine state to the onchain dispute game contract module 114. After locating a dispute point in the dispute game contract, the onchain fraud proof engine 132 is configured to conduct arbitration.

[0066] Based on the opML architecture 100, the onchain AI oracle (OAO ) provides an AI inference service in the onchain smart contract.

[0067] Figure 2 is a flow chart illustrating a first embodiment of a process (also referred to as a workflow) 200 of the opML architecture 100 with a plurality of nodes in accordance with the present disclosure. At step 202 (receive the request) , the submitter module 122 is configured to receive the initiated request. Assume that “submitter” is the first opML node 100 that handles the incoming request. At step 203 (generate an infererence result) , the machine learning engine 124 is configured to process the request and generate an inference result, thereby generating an output of the machine learning model based on the input data. At step 204 (submit inference result to onchain smart contract) , the submitter module 122 is configured to check if a result has already been submitted to the smart contract. If no result exists, the generated inference result is then submitted to an onchain request contract module (or request contract module) 112 by the submitter module 122. If a result is already present, the submitter module checks for consistency between the submitted inference result and the inference result generated by the machine learning engine 124.

[0068] At the same time, there is another opML node (shown as the verifier in Figure 2 that functions as another opML node or a second opML node, while the opML node 100 in Figure 1 functions as a submitter) , named “verifier” configured to also receive a request at step 206, generate an inference result at step 207, and then submit an inference result to the onchain request contract module 112 at step 208. Alternatively, the term “submitter” and the term “verifier” in Figure 2 can be flipped, for example in a first instance, a first module is functioning as a submitter and a second module is functioning as a verifier, but in a second instance, the second module is functioning as a submitter and the first module is functioning as a verifier.

[0069] At step 209 (generate a VM state with the offchain fraud proof engine 132) , in case of a discrepancy between the submitted result and the machine learning engine's result, the offchain fraud proof engine 132 is configured to generate a VM state. At step 210 (start challenge) , the submitter (for example, the opML node 100) submits the virtual machine (VM) state, which initiates a challenge within the onchain dispute game. At steps 211 to 214 (interactive dispute game) , the dispute game monitor 130 is configured to monitor the dispute game state at step 211. If the  current opML node is required to respond, the offchain fraud proof engine 132 is configured to generate the virtual machine state at step 212 and then submit the virtual machine state to the onchain dispute game contract module at step 213. At the same time, another opML node (not shown) “verifier” is configured to conduct the same functions at steps 214, 215, 216. This leads to an interactive dispute game where both parties engage to identify a dispute point. The interactive dispute game concludes when a dispute point is found.

[0070] At steps 217-218 (generate a fraud proof) , once a dispute point is found, the offchain fraud proof engine 132 is configured to again generate a fraud proof, where the fraud proof can be used to resolve the dispute, and then submit to the onchain fraud proof engine 116. At step 219 (onchain arbitration) , given the fraud proof, the onchain fraud proof engine 116 is configured to conduct an onchain arbitration, and then return the arbitration result to the participants. At step 221 (challenge period) , after the fraud proof is submitted, there is a challenge period where other parties can challenge the onchain submitted result. At steps 220 and 222 (finalize an arbitration result) , after the challenge period, the onchain submitted result is finalized, which is then returned, thereby completing the workflow.

[0071] Figure 3 is a flow chart illustrating a second embodiment of the workflow 300 of the opML system 100 to process and execute a new user request in accordance with the present disclosure. At step 302, a requester module is configured to receive a new user request. At step 304, after receiving the user request, the machine learning engine is configured to conduct a local execution and then provide an executed inference result. At step 306, the opML node 100 is configured to check whether there already exists a submitted result onchain (this result can be submitted by other opML nodes) . On the one hand, if there is no onchain submitted result, at step 308, the submitter module is configured to submit the executed inference result onchain. At step 310, the dispute game monitor 130 is configured to start to monitor the status of the onchian dispute game contract. On the other hand, if there is an onchain submitted result, at step 312, the submitter module 122 is configured to check whether the result is consistent with the local executed result. If the result is consistent, at step 314, the dispute game monitor 130 is configured to start to monitor the status of the onchin a dispute game contract. Otherwise, if the result is inconsistent, at step 316, the offchain FPVM conducts the local execution and generates a fraud proof. At step 318, the fraud proof submitter is configured to submit the fraud proof to the onchain dispute game contract. At step 320, the dispute game monitor is configured to start monitoring the status of the onchain dispute game contract.

[0072] Figure 4 is a block diagram illustrating a cross-compiler 128 with a floating-point module 401 in the opML architecture 100. The cross-compiler 128 in the opML system 100 is a  versatile tool in the compilation process of the machine learning program 126. A suitable implementation of the floating-point module 401 is SoftFloat (which refers to a Berkeley software implementation of binary floating-point that conforms to the IEEE 754 Standard for Floating-Point Arithmetic, written by John Hauser at UC Berkeley) . To guarantee the determinism and consistency of the output of machine learning program 126, the cross-platform floating-point module 401, a fixed-point arithmetic 402, and a deterministic random library 403 are applied to the compilation of the machine learning program 126. The cross-platform floating-point module 401 is designed to function consistently across different platforms. These libraries ensure cross-platform consistency and determinism of the machine learning results, regardless of the underlying hardware or software configurations. Fixed-point arithmetic, also referred to as quantization technology, enables the system to represent and perform computations using fixed precision rather than floating-point numbers. By doing so, we mitigate the effects of floating-point rounding errors, leading to more reliable and consistent results. The deterministic random library 403 is a software library designed to generate sequences of numbers that appear random but are actually predictable. When the same seed is used, the library will produce the exact same sequence of numbers every time it is run, ensuring reproducibility. A cross-compiler module 404 is designed to receive the source code of the machine learning program 126 and compile the source code into two distinct executable targets, tailored for different environments: (1) fraud proof virtual machine (FPVM) Executable File 405 (the compiled output specifically designed to run within the FPVM) . (2) local-environment executable file 406 (the compiled output for execution in a local environment, which could be any standard computing environment that supports the execution of the compiled code) .

[0073] To ensure that the machine learning results are consistent and deterministic across different platforms, the cross-compiler 128 utilizes a cross-platform floating-point module 401, such one comprising software-based floating-point libraries, which are designed to provide a consistent behavior of floating-point operations, irrespective of the underlying hardware or software configurations. The cross-platform floating-point module 401 also serves to maintain the integrity and reproducibility of the machine learning program's outcomes.

[0074] Lastly, the cross-compiler 128 incorporates a deterministic random library 403. The deterministic random library is configured to be responsible for generating sequences of numbers that are deterministic in nature. That means, given the same initial conditions or seed, the library will always produce the same sequence of numbers. This feature is crucial for scientific computing and machine learning, where the ability to reproduce results is essential for debugging, testing, and ensuring the reliability of the algorithms.

[0075] Figure 5 is a block diagram illustrating one embodiment of functional flow of the machine learning engine 124. The machine learning engine 124 performs two primary functionalities within the offchain system 120. The first functionality is centered around generating inference results. When a machine learning executor 502 receives a user's input 501 along with the local-environment executable file 406, the machine learning executor 502 loads the inputs (or data) into the offchain system 120 and executes data within the designated environment. The machine learning engine 124 then generates of an inference result 503.

[0076] The second functionality of the machine learning engine 124 is closely tied to the design of fraud proofs. This aspect involves a communication module 505 that facilitates the exchange of information between the machine learning engine 124 and the offchain fraud proof engine 132. Specifically, when the offchain fraud proof engine 132 sends a host function input 504 to the machine learning engine 124 via the communication module 505, the machine learning engine 124 responds by invoking a host function executor 506. The host function executor 506 processes the host function input and generates a host function output 507, which is then relayed back through the communication module 505 to the offchain fraud proof engine 132.

[0077] The host function output 504 represents data that the offchain fraud proof engine 132 uses to further its processes, such as in the context of fraud detection or dispute resolution mechanisms within the offchain system 120. This back-and-forth communication ensures that the machine learning engine's analytical capabilities are leveraged not only for direct inference but also in support of the broader system's integrity and security measures.

[0078] Figure 6 is a block diagram illustrating one embodiment of the offchain fraud (FP) proof engine 132. The offchain fraud proof engine 132 is a significant system within the opML architecture 100 designed to produce fraud proofs by analyzing the execution of machine learning programs. One embodiment of the workflow of the FP Engine 132 is described as follows.

[0079] The process starts with the FPVM Executable File (405) , which is prepared for execution within a fraud proof virtual machine (FPVM) 604. This file contains the machine learning program 126 to be analyzed for potential fraud. A file loader 602 is configured for loading the executable file into the fraud proof virtual machine 604, preparing a file for the execution phase. With the user's input is provided (501) , an Input Loader 603 receives the input and loads the input into the fraud proof virtual machine 604, ensuring that the fraud proof virtual machine program 126 has the necessary data to perform computations. As the fraud proof virtual machine 604 executes the program, the fraud proof virtual machine 604 reaches a specific point in the code, identified as Position i (601) . At this point, the fraud proof virtual machine 604 captures the state of its execution, including memory and function inputs and results. A fraud proof generator 605  then uses the output and the execution trace from the fraud proof virtual machine 604 at Position i to generate a fraud proof 607. The fraud proof 607 represents a piece of data (or a piece of evidence) that can be used to identify discrepancies or fraudulent activities within the execution of the machine learning program 126.

[0080] During the execution, if the fraud proof virtual machine604 needs to call a host function, the fraud proof virtual machine6 04 sends the function input to a multi-phase extension module 606. The multi-phase extension module 606 acts as an intermediary, facilitating communication between the fraud proof virtual machine 604 and the machine learning engine 124. The multi-phase extension module 606 retrieves the executed result of the host function from the machine learning engine 124 and returns the result back to the fraud proof virtual machine 604, allowing the fraud proof virtual machine 604 to proceed with its execution using the correct output from the host function. The machine learning engine 124 is configured to provide the computational results for the host functions, which are essential for the fraud proof virtual machine 604 to generate one or more accurate and reliable fraud proofs.

[0081] In summary, the fraud proof engine 132 operates by executing machine learning programs 126 within the fraud proof virtual machine604, capturing the execution state at specific points, and uses this information to generate fraud proofs. The fraud proof engine 132 works in conjunction with the machine learning engine 124 through the multi-phase extension module 606 to ensure that function calls are accurately resolved, contributing to the creation of valid and trustworthy fraud proofs.

[0082] Figure 7 is a block diagram illustrating one embodiment of an onchain fraud proof (FP) engine 116. The onchain fraud proof engine 116 is a component of the onchain system 110 that operates to verify the integrity and correctness of the fraud proofs generated by the offchain fraud proof engine 132. Its workflow is as follows. A fraud proof verifier 701 is the initial point of contact for the fraud proof, which is provided as input, denoted as the fraud proof 607. The fraud proof verifier 701 serves to ascertain the authenticity and correctness of a fraud proof. Once the fraud proof has been verified by the fraud proof verifier 701, the corresponding data from the fraud proof is then loaded into the memory of a fraud proof virtual machine 702. This data includes any necessary data that are required for the fraud proof virtual machine 702 to function correctly. With the data loaded, the fraud proof virtual machine 702 is given a previous state 608 and the corresponding data from the fraud proof. Using this information, the fraud proof virtual machine 702 is tasked with generating the correct virtual machine state. The fraud proof virtual machine 702 processes this data to produce a next fraud proof virtual machine state (703) , which is the output of the fraud proof virtual machine 702 after considering the verified fraud proof and the  loaded data. The newly generated virtual machine state serves as a confirmation or refutation of the fraud proof's claims, providing a deterministic outcome based on the inputs and previous state provided. In essence, the onchain fraud proof engine 116 operates to verify the fraud proofs, loading relevant data into the fraud proof virtual machine 702, and then uses the fraud proof virtual machine 702 to generate the new (or next) virtual machine state 703 that either corroborates or disputes the claims made by the fraud proof. This process acts to ensure the trustworthiness and reliability of the fraud detection system within the blockchain environment.

[0083] Figure 8 is a flow diagram illustrating a process (or a workflow) 800 of the opML node 100 receiving a user request. The workflow of the opML node 100 receiving a user request is a sequence of steps designed to handle the request and engage with the blockchain and machine learning systems as needed. One embodiment of the workflow is described below. The process 800 starts when the submitter module receives a new user request at step 801. The submitter module 122 is configured to receive an initial intake of user queries or tasks. At step 802, the machine learning engine 124 is configured to take over, conducting a local execution of the user's request. The machine learning engine 124 processes the request using its machine learning capabilities and generates an executed inference result. After obtaining the inference result, at step 803, the workflow reaches a decision point, and the submitter module is configured to check whether there is an onchain submitted inference result already present on the blockchain.

[0084] If an onchain submitted inference result exists (yes path) , at step 806, the submitter module 122 compares the local executed result with the onchain submitted result to ensure consistency. If no onchain submitted inference result is found (no path) , at step 804, the submitter module 122 proceeds to submit the locally executed inference result onto the blockchain for further processing and verification. Regardless of whether the result was already onchain or newly submitted, at step 807, the dispute game monitor 130 is configured to monitor the status of the onchain dispute game contract, thereby ensuring that any disputes or challenges related to the submitted inference results are handled appropriately. In parallel, if a dispute arises, at step 808, the offchain fraud proof engine 132 is utilized to start an onchain dispute game challenge. The offchain fraud proof engine 132 is configured to operate in conjunction with the onchain system 110 to provide the necessary evidence or proofs to support or refute the dispute. The dispute game monitor 130 is configured to use the offchain fraud proof engine 132 to initiate a challenge on the blockchain if required, ensuring that the dispute resolution process is integrated and efficient. In summary, the workflow 800 involves receiving a user request, processing the user request through the machine learning engine, checking for existing onchain results, submitting new results if necessary, and monitoring the status of any disputes through the dispute game  monitor and offchain fraud proof engine. The workflow 800 ensures a robust system for handling user requests and disputes within the opML node's ecosystem.

[0085] Figure 9 shows the workflow of a dispute game starting from the opML node 100 initiating a challenge in a systematic process designed to resolve discrepancies in the execution trace within the blockchain environment, which is applicable to both single-phase and multi-phase embodiments. At step 901 (initialization) , the starting position is set to the beginning of the execution trace (position 0) , and the ending position is set to the length of the execution trace. At step 902 (fraud proof engine utilization) , the offchain fraud proof engine 132 is configured generate a virtual machine (VM) state at the final position. At step 903 (dispute game submission, the virtual machine state at the final position is submitted to the dispute game contract to initiate the challenge and enter the interactive dispute game. At step 904 (condition check) , the dispute game monitor 130 is configured to check if the starting position plus one is less than the ending position. If true, the process exits the interactive dispute game and moves to the onchain arbitration process. At steps 904 –915 (interactive dispute game) , if the condition in step 904 is not met, the interactive dispute game continues. The dispute game monitor 130 is configured to wait for one or more responses from other nodes.

[0086] At step 905 (node response) , the other node (see, for example, steps 905a, 905b , 905c) , in response, calculates the middle point between the starting and ending positions, configures the offchain fraud proof engine 132 to obtain the FPVM state, and submits this state to the onchain dispute game contract module 114. At steps 906-907 (challenge period) , during the challenge period, if no response is received, the challenger is declared the winner. If a response is received, the middle position is calculated. At steps 908 –910 (virtual machine state generation and comparison) , the offchain fraud proof engine 132 is configured to generate the virtual machine state at the middle position, which is then compared with the response state from other nodes. At steps 911, 912 (position update) , if the generated virtual machine state and the response state are consistent, the starting position is updated to the middle position. If the generated virtual machine state and the response state are not consistent, the ending position is updated to the middle position. At steps 913 –915 (loop continuation) , the middle position is recalculated. The fraud proof engine is configured again to generate a virtual machine state, and the virtual machine state is submitted back to the dispute game contract module 114, which forms a loop that returns to the initial condition check and continues the interactive dispute game.

[0087] At steps 916 –922 (onchain arbitration process) , if the decision point (step 904) check fails (i.e., the starting position plus one is not less than the ending position) , the process enters the onchain arbitration process. At step 916 (fraud proof generation) , the offchain fraud proof engine  132 is configured to generate a fraud proof. In one embodiment, the dispute game can be configured in two ways, one for a single-phase system and another for a multi-phase system. At step 917 (host function check) , the onchain fraud proof engine 116 is configured to check if the instruction at the starting position calls a host function. If the instruction at the starting position calls the host function (that is, the dispute game is configured for a multi-phase system) , a new dispute subgame is created recursively using the fraud proof. To phrase it another way, a call for host function pertains to the multi-phase system; also, the host function exists as part of the multi-phase system. At step 918 (next state generation) , if the instruction does not call a host function, the onchain fraud proof engine 116 is configured to generate the next state. At steps 919 –921 (state comparison and decision) , the generated next state is compared with the challenger's state. If they are consistent, at step 920, the challenger wins; otherwise, at step 921, the challenger loses.

[0088] Figure 10 is a block diagram illustrating one embodiment of a process (workflow) of an onchain AI oracle (OAO) as an application of opML. The onchain AI oracle, powered by opML on Ethereum, integrates machine learning models directly into blockchain applications. At step 1001, the architecture of OAO involves user contracts initiating AI requests through the requestCallback function on the OAO contract. Upon receiving a request, OAO broadcasts the request to opML nodes for processing. Once processed, OAO returns the AI inference result to the user via a callback function. During this workflow, the process is bifurcated into usage and challenge phases. In the usage phase, at step 1002, each AI request triggers an opML execution, and at step 1003, with OAO emitting a requestCallback event collected by opML nodes. At step 1004, one or more opML nodes execute AI inference and upload the result onto the blockchain. Subsequently, the challenge phase begins immediately after result submission. Validators within the opML network or any interested parties review and may challenge the validity of the uploaded result within a specified window. Successful challenges lead to an update of the result onchain, thereby ensuring accuracy. Following the challenge period, the result is finalized and immutable onchain. At step 1005, upon result upload or update, opML dispatches the verified result to the user's smart contract through a dedicated callback function at step 906, ensuring seamless integration and reliability in blockchain-based AI services.

[0089] Figure 11 illustrates an exemplary form of a computer system (or a computer device, or a distributed computing, or a decentralized computing) 1100, in which a set of instructions can be executed to cause the computer system to perform any one or more of the methodologies discussed herein. The computer system 1100 may represent any or all of the clients, servers, or network intermediary devices discussed herein. Further, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or  jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. The exemplary computer system 1100 includes a processor 1102 (e.g., a central processing unit (CPU) , a graphics processing unit (GPU) , or both) , a main memory 1104, and a static memory 1106, which communicate with each other via a bus 1108. The computer system 1100 may further include a video display unit 1110 (e.g., a liquid crystal display (LCD) . The computer system 1100 also includes an alphanumeric input device 1112 (e.g., a keyboard) , a cursor control device 1114 (e.g., a mouse) , a disk drive unit 1116, a signal generation device 1118 (e.g., a speaker) , and a network interface device 1124.

[0090] The disk drive unit 1116 includes a machine-readable medium 1120 on which is stored one or more sets of instructions (e.g., software 1122) embodying any one or more of the methodologies or functions described herein. The software 1122 may also reside, completely or at least partially, within the main memory 1104 and / or within the processor 1102. During execution, the computer system 1100, the main memory 1104, and the instruction-storing portions of the processor 1102 also constitute machine-readable media. The software 1122 may further be transmitted or received over a network 1126 via the network interface device 1124.

[0091] While the machine-readable medium 1120 is shown in an exemplary embodiment to be a single medium, the term "machine-readable medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) that store the one or more sets of instructions. The term "machine-readable medium" shall also be taken to include any tangible medium that is capable of storing a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention. The term "machine-readable medium" shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media.

[0092] Some portions of the detailed descriptions herein are presented in terms of algorithms and symbolic representations of operations on data within a computer memory or other storage device. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of processing blocks leading to a desired result. The processing blocks are those requiring physical manipulations of physical quantities. Throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical  quantities within the computer system memories or registers or other such information storage, transmission or display devices.

[0093] The present invention also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but not limited to, any type of disk including cloud computing, flash memories, optical disks, magnetic-optical disks, read-only memories (ROMs) , random access memories (RAMs) , erasable programmable ROMs (EPROMs) , electrically erasable and programmable ROMs (EEPROMs) , magnetic or optical cards, application specific integrated circuits (ASICs) , or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. Furthermore, the computers and / or other electronic devices referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability for artificial intelligence, machine learning, and big data high performance computing.

[0094] Moreover, terms such as "request" , "client request" , "requested object" , or "object" may be used interchangeably to mean action (s) , object (s) , and / or information requested by a client from a network device, such as an intermediary or a server. In addition, the terms "response" or "server response" may be used interchangeably to mean corresponding action (s) , object (s) and / or information returned from the network device. Furthermore, the terms "communication" and "client communication" may be used interchangeably to mean the overall process of a client making a request and the network device responding to the request.

[0095] In respect of any of the above system, device or apparatus aspects, there may further be provided method aspects comprising steps to carry out the functionality of the system. Additionally or alternatively, optional features may be found based on any one or more of the features described herein with respect to other aspects.

[0096] The present disclosure has been described in particular detail with respect to possible embodiments. Those skilled in the art will appreciate that the disclosure may be practiced in other embodiments. The particular naming of the components, capitalization of terms, the attributes, data structures, or any other programming or structural aspect is not mandatory or significant, and the mechanisms that implement the disclosure or its features may have different names, formats, or protocols. The system may be implemented via a combination of hardware and software, as described, or entirely in hardware elements, or entirely in software elements. The particular division of functionality between the various system components described herein is merely  exemplary and not mandatory; functions performed by a single system component may instead be performed by multiple components, and functions performed by multiple components may instead be performed by a single component.

[0097] In various embodiments, the present disclosure can be implemented as a system or a method for performing the above-described techniques, either singly or in any combination. The combination of any specific features described herein is also provided, even if that combination is not explicitly described. In another embodiment, the present disclosure can be implemented as a computer program product comprising a computer-readable storage medium and computer program code, encoded on the medium, for causing a processor in a computing device or other electronic device to perform the above-described techniques.

[0098] As used herein, any reference to "one embodiment" or to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least one embodiment of the disclosure. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment.

[0099] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that, throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "displaying" or "determining" or the like refer to the action and processes of a computer system, or similar electronic computing module and / or device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system memories or registers or other such information storage, transmission, or display devices.

[0100] Certain aspects of the present disclosure include process steps and instructions described herein in the form of an algorithm. It should be noted that the process steps and instructions of the present disclosure could be embodied in software, firmware, and / or hardware, and, when embodied in software, it can be downloaded to reside on, and operated from, different platforms used by a variety of operating systems.

[0101] The algorithms and displays presented herein are not inherently related to any particular computer, virtualized system, or other apparatus. Various general-purpose systems may also be used with programs, in accordance with the teachings herein, or the systems may prove convenient to construct more specialized apparatus needed to perform the required method steps. The required structure for a variety of these systems will be apparent from the description  provided herein. In addition, the present disclosure is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the present disclosure as described herein, and any references above to specific languages are provided for disclosure of enablement and best mode of the present disclosure.

[0102] In various embodiments, the present disclosure can be implemented as software, hardware, and / or other elements for controlling a computer system, computing device, or other electronic device, or any combination or plurality thereof. Such an electronic device can include, for example, a processor, an input device (such as a keyboard, mouse, touchpad, trackpad, joystick, trackball, microphone, and / or any combination thereof) , an output device (such as a screen, speaker, and / or the like) , memory, long-term storage (such as magnetic storage, optical storage, and / or the like) , and / or network connectivity, according to techniques that are well known in the art. Such an electronic device may be portable or non-portable. Examples of electronic devices that may be used for implementing the disclosure include a mobile phone, personal digital assistant, smartphone, digital watch, kiosk, desktop computer, laptop computer, tablet, consumer electronic device, television, set-top box, or the like. An electronic device for implementing the present disclosure may use an operating system such as, for example, iOS available from Apple Inc. of Cupertino, Calif., Android available from Google Inc. of Mountain View, Calif., Microsoft Windows 11, Windows 11 Enterprise, Windows Server 2022 available from Microsoft Corporation of Redmond, Wash., or any other operating system that is adapted for use on the device. In some embodiments, the electronic device for implementing the present disclosure includes functionality for communication over one or more networks, including for example a cellular telephone network, wireless network, and / or computer network such as the Internet.

[0103] Some embodiments may be described using the expression "coupled" and "connected" along with their derivatives. It should be understood that these terms are not intended as synonyms for each other. For example, some embodiments may be described using the term "connected" to indicate that two or more elements are in direct physical or electrical contact with each other. In another example, some embodiments may be described using the term "coupled" to indicate that two or more elements are in direct physical or electrical contact. The term "coupled, " however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other. The embodiments are not limited in this context.

[0104] As used herein, the terms "comprises, " "comprising, " "includes, " "including, " "has, " "having" or any other variation thereof are intended to cover a non-exclusive inclusion. For  example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, "or" refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present) , A is false (or not present) and B is true (or present) , and both A and B are true (or present) .

[0105] The term "at least one" as used herein is a mathematical term meaning “one or more” . For example, the phrase “at least one constraint set” is synonymous as “one or more constraint sets. ”

[0106] The terms "a" or "an, " as used herein, are defined as one as or more than one. The term "plurality, " as used herein, is defined as two or as more than two. The term "another, " as used herein, is defined as at least a second or more.

[0107] An ordinary artisan should require no additional explanation in developing the methods and systems described herein but may find some possibly helpful guidance in the preparation of these methods and systems by examining standardized reference works in the relevant art.

[0108] While the disclosure has been described with respect to a limited number of embodiments, those skilled in the art, having benefit of the above description, will appreciate that other embodiments may be devised which do not depart from the scope of the present disclosure as described herein. It should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter. The terms used should not be construed to limit the disclosure to the specific embodiments disclosed in the specification and the claims, but the terms should be construed to include all methods and systems that operate under the claims set forth herein below. Accordingly, the invention is not limited by the disclosure, but instead its scope is to be determined entirely by the following claims.

Claims

1.An optimistic machine learning on blockchain (opML) system, comprising:an offchain system including a machine learning (ML) engine and an offchain fraud proof (FP) engine, the machine learning engine receiving a user’s input and a local-environment executable file, the offchain fraud proof engine receiving the user’s input and a fraud proof virtual machine (FPVM) executable file, wherein given the same user input, both the machine learning engine and the fraud prof engine generate the same output, wherein during a fraud proof generation process conducted by the fraud proof engine, the machine learning engine is configured to speed up the execution in the fraud proof virtual machine; andan onchain system, communicatively coupled to the offchain system, including a dispute game contract module and an onchain fraud proof engine, the dispute game contract module configured to record at least one interaction of different opML nodes, and configured to locate a dispute point, the dispute game contract module sending the dispute point to the onchain fraud proof engine for arbitration, the onchain fraud proof engine configured to conduct an onchain arbitration;wherein the offchain fraud proof engine is configured to provide the same execution trace as the onchain fraud proof engine.2.The opML system of claim 1, further comprising a cross-compiler coupled to both a machine learning engine and the offchain fraud proof engine, the cross-compiler generating the local-environment executable file and the fraud proof virtual machine executable file.3.The opML system of claim 2, wherein the offchain fraud proof engine comprises a fraud proof virtual machine and a fraud proof generator, the fraud proof virtual machine configured to load the fraud proof virtual machine executable file and the user’s input, and subsequently generate the fraud proof virtual machine state at a specific position, the fraud proof generator coupled to the fraud proof virtual machine and configured to generate the corresponding fraud proof at a specific position.4.The opML system of claim 3, wherein the onchain FP engine comprises a fraud proof (FP) verifier and a fraud proof virtual machine, the fraud proof verifier configured to check the correctness of a fraud proof, and subsequently load a set of data into the onchain FPVM for computation, the set of data comprising the FPVM registers data and memory data.5.The opML system of claim 4, wherein responsive to a previous FPVM state and the set of data, the onchain fraud proof virtual machine is configured to conduct a one-step execution to generate a next FPVM state.6.The opML system of claim 2, wherein the machine learning engine (124) comprises:a machine learning executor (502) configured to process the user’s input and the local-environment executable file within the offchain system (120) to generate an inference result based on the user’s input; anda communication module (505) configured to enabling a bidirectional exchange between the machine learning engine (124) and the offchain fraud proof engine (132) ;wherein the machine learning engine (124) receives a host function input from the offchain fraud proof engine (132) via the communication module (505) ; anda host function executor (506) is configured to compute on the host function input to generate a host function output, and subsequently relay the host function output back to the offchain fraud proof engine (132) .7.A method for ensuring deterministic at least machine learning (ML) result in an optimistic machine learning (opML) system, comprising:(a) providing a consistent result of at least one floating-point operation across diverse hardware and software configurations by replacing a hardware-dependent floating-point calculation with a cross-platform floating-point module, thereby maintaining the integrity and reproducibility of machine learning program outcomes, the cross-platform floating-point module (301) integrated within a cross-compiler (128) ;(b) mitigate at least one floating-point rounding error of an output generated from the hardware-dependent floating-point calculation during a machine learning program execution by integrating a fixed-point arithmetic (302) into the cross-compiler (128) , thereby ensuring consistent and reliable results; and(c) generate a sequence of numbers that are deterministic under the same initial conditions or seed by integrating a deterministic random library (303) into the cross-compiler (128) .8.The method of claim 7, further comprising:a machine learning engine (124) receiving a user input and a local-environment executable file; anda machine learning executor (502) generating an inference result based on the user input.9.A method for starting a challenge of a dispute game, comprising:initializing at least one dispute game parameter;setting an initial starting position (start_position) to zero and an ending position (end_position) to the length of an execution trace;generating, by a fraud proof (FP) engine, a fraud proof virtual machine (VM) state (FPVM state) at the ending position; andsubmitting the FPVM state to a dispute game contract module to initiate a challenge for an onchain submitted result, thereby triggering commencement of an interactive dispute game where at least one opML node participates in the verification and validation of the FPVM state, wherein the challenge of a dispute game is initiated when an onchain submitted result is inconsistent with a local generated result.10.The method of claim 9, further comprising:(a) a dispute game monitor continuously monitoring an interactive dispute game to receive at least one response from at least one other participating opML node;(b) upon receiving the one or more responses by a first (responding) opML node, calculating the middle position (middle_position) between a starting position (start_position) and an ending position (end_position) ;(c) generating, by the offchain fraud proof engine associated with a second (local) opML node, a first FPVM state at the middle position and submitting the FPVM state to an onchain dispute game contract module;(d) comparing the first FPVM state generated from the second (local) opML node with a second FPVM state generated by the first (responding) opML node:if the first FPVM state and the second FPVM are consistent, updating from the starting position to the middle position;if the first FPVM state and the second FPVM are not consistent, updating from the ending position to the middle position; and(e) recalculating the middle position, generating a third FPVM state based on the middle position by the second opML node, and submitting the FPVM state back to the dispute game contract module; and(f) iteratively repeating steps (b) , (c) , (d) , (e) until a dispute point is reached, indicating a subsequent step is to enter into an onchain arbitration process, wherein the dispute point is reached when the starting position plus one is not less than the ending position.11.The method of claim 10, further comprising:for an onchain fraud proof engine for onchain arbitration, verifying a fraud proof generated by the offchain fraud proof engine;upon verification, loading a portion of data from the fraud proof into the onchain fraud proof virtual machine (FPVM) ;based on a previous FPVM state and the loaded data, configuring the onchain FPVM to conduct a one-step execution to generate a next FPVM state;comparing the FPVM state generated by the onchain FP Engine with the FPVM state provided by the second (local) opML node;if the FPVM state generated by the onchain fraud proof egnine and the FPVM state provided by the second (local) opML node are consistent, declaring the second (local) opML as a winner of the dispute; andif inconsistencies are found between the FPVM state generated by the onchain FP Engine and the FPVM state provided by the second (local) opML node, declaring the second (local) opML node as losing the dispute.12.The method of claim 11, further comprising the fraud proof verifier determining the authenticity and correctness of the fraud proof, thereby ensuring that the loaded data accurately reflects the previous FPVM state.13.The method of claim 12, further comprising based on the previous FPVM state and the corresponding fraud proof, configuring the onchain FP engine to process the information to generate the next FPVM state after the one-step execution.14.An opML method, comprising:generating, by a cross-compiler, a local-environment executable file and a fraud proof virtual machine (FPVM) executable file, in response to executing a machine learning (ML) program;responsive to a user’s input, generating an inference result using a machine learning engine based on a local-environment executable file;generating a FPVM state and a fraud proof at a specific position by an offchain fraud proof engine based on the FPVM executable file;responding or starting a challenge in a dispute game by an onchain dispute game contract module based on the FPVM state; andgenerating an onchain arbitration result by an onchain fraud proof engine with the previous FPVM state and the corresponding fraud proof.15.A method for generating a fraud proof virtual machine (FPVM) state and a corresponding fraud proof, comprising:loading a fraud proof virtual machine executable file compiled by a cross-compiler;receiving a user input for execution by a machine learning program (126) within the FPVM;responsive to receiving the user input, executing, by a fraud proof engine, the machine learning program within the FPVM, until reaching a predetermined (specified) position (508) ;at the specified position, the fraud proof engine capturing the execution state (or a captured execute state) of the FPVM, including memory and function inputs and results;using the captured execution state, the fraud proof engine generating the FPVM state, which represents a snapshot of the program's execution at the specified position; andbased on the captured execution state, the fraud proof engine utilizeing a fraud proof generator to produce a fraud proof, which serves as evidence of the program's execution integrity.16.A system, comprising:a requester module configured for sending an onchain request by a source;a requester module configured for listening for the onchain request;a machine learning engine configured for receiving an onchain request and conducting an execution with a local executed version and providing an inference result;a submitter module configured for submitting an onchain inference result;if the onchain inference result is inconsistent or incorrect with the local executed version, a dispute module is onfigured for a challenger to submit for a fraud proof verification;if the onchain inference result is correct and if the current node is challenged by another node, the current node is prompted to defend the correctness of the onchain inference result, and the dispute module configured for a challenger to submit for a fraud proof verification;wherein the dispute module includes (a) a first fraud proof VM (FPVM) for offchain, (b) a first fraud proof VM (FPVM) for onchain, (c) a machine learning program, (d) a cross-compiler to compile the machine learning program to FPVM binary code, (e) a dispute game contract on chain to record the interaction and for arbitration using onchain FPVM, (f) a dispute game monitor to monitor the status of the dispute game and (g) a fraud proof submitter to submit the fraud proof to the dispute game contract.17.A method, comprising:sending an onchain request by a requester module from a source;listening for the onchain request by a requester module;receiving an onchain request by a machine learning engine;conducting execution by the machine learning engine and providing an inference result; andsubmitting an onchain inference result by a submitter module;if the onchain inference result is inconsistent or incorrect with a local executed version, submitting for a fraud proof verification by a dispute module configured from a challenger;if the onchain inference result is correct and if the current node is challenged by another node, the current node is prompted to defend the correctness of the onchain inference result, and to submit for a fraud proof verification by the dispute module configured from a challenger; wherein the dispute module includes (a) a first fraud proof VM (FPVM) for offchain, (b) a first fraud proof VM (FPVM) for onchain, (c) a machine learning program, (d) a cross-compiler to compile the machine learning program to FPVM binary code, and (e) a dispute game contract on chain to record the interaction and for arbitration using onchain FPVM.

Images