Search

EP-4740131-A1 - COMPUTING TECHNOLOGIES FOR LARGE LANGUAGE MODELS

EP4740131A1EP 4740131 A1EP4740131 A1EP 4740131A1EP-4740131-A1

Abstract

This disclosure enables various computing technologies for smart contracts to be audited in ways that improve on conventional auditing approaches mentioned above. These technologies improve functioning of computers by enabling large language models to review bytecodes executable on distributed ledgers to determine whether those bytecodes enable smart contracts on those distributed ledgers and then acting accordingly.

Inventors

  • DAS, ARIJIT
  • CHAPMAN, JUSTIN

Assignees

  • Northern Trust Corporation

Dates

Publication Date
20260513
Application Date
20240215

Claims (20)

  1. 1. A system, comprising: a computing instance programmed to: host a large language model (LLM) trained to (i) read a bytecode capable of being executed on a distributed ledger, (ii) determine whether the bytecode enables a smart contract on the distributed ledger, and (iii) take a first action based on the bytecode being determined to enable the smart contract and a second action based on the bytecode being determined to not enable the smart contract, wherein the bytecode enables the smart contract by expressing (1) an offeror identifier associated with an offeror network address on the distributed ledger, (2) an offeree identifier associated with an offeree network address on the distributed ledger, (3) an offer expression associated with the offeror identifier, (4) an acceptance expression associated with the offeree identifier, and (5) a consideration expression associated with the offeror identifier and the offeree identifier, wherein the first action includes (a) identifying the offer expression, the acceptance expression, and the consideration expression, (b) generating a human-readable content describing the offer expression, the acceptance expression, and the consideration expression, and (c) outputting the human-readable content for consumption on a computing terminal, wherein the second action includes outputting a notice for consumption on the computing terminal, wherein the notice indicates the bytecode being determined to not enable the smart contract; and host a logic programmed to (i) receive the offeror network address from the computing terminal and the offeree network address from the computing terminal, (ii) locate the bytecode on the distributed ledger based on the offeror network address and the offeree network address, (iii) form a copy of the bytecode, and (iv) prompt the LLM with the copy such that the LLM (a) determines whether the copy enables the smart contract and (b) takes the first action based on the copy being determined to enable the smart contract and the second action based on the copy being determined to not enable the smart contract.
  2. 2. The system of claim 1, wherein the human-readable content includes an unstructured text describing the offer expression, the acceptance expression, and the consideration expression.
  3. 3. The system of claim 1, wherein the human-readable content includes an image describing the offer expression, the acceptance expression, and the consideration expression.
  4. 4. The system of claim 1, wherein the human-readable content includes a sound describing the offer expression, the acceptance expression, and the consideration expression.
  5. 5. The system of claim 1, wherein the first action includes identifying a potential defense statement to the offer expression, the acceptance expression, or the consideration expression, generating the human-readable content including the potential defense statement, and outputting the human-readable content including the potential defense statement for consumption on the computing terminal.
  6. 6. The system of claim 5, wherein the bytecode includes a jurisdictional identifier associated with the offer expression, the acceptance expression, and the consideration expression, wherein the first action includes identifying the jurisdictional identifier, determining whether the potential defense statement is applicable to the jurisdictional identifier, and taking a third action based on the potential defense statement being determined to be applicable to the jurisdictional identifier and a fourth action based on the potential defense statement being determined to not be applicable to the jurisdictional identifier.
  7. 7. The system of claim 6, wherein the third action includes generating the human-readable content including the potential defense statement and outputting the human-readable content including the potential defense statement for consumption on the computing terminal.
  8. 8. The system of claim 6, wherein the fourth action includes outputting an alert indicating the potential defense statement being determined to not be applicable to the jurisdictional identifier for consumption on the computing terminal.
  9. 9. The system of claim 6, wherein the LLM is prompted from the computing terminal at a location, wherein the computing instance is programmed to determine the location such that the third action or the fourth action involves determining whether the location is covered by the jurisdictional identifier and outputting a first message based the location being determined to be covered by the jurisdictional identifier for consumption on the computing terminal and a second message based the location being determined to not be covered by the jurisdictional identifier for consumption on the computing terminal.
  10. 10. The system of claim 1, wherein the first action includes determining whether the offeror identifier, the offeror network address, the offeree identifier, the offeree network address, the offer expression, the acceptance expression, or the consideration expression include or relate to an entity identifier listed in a list and outputting a message indicating the entity identifier being listed in the list for consumption on the computing terminal.
  11. 11. The system of claim 1, wherein the first action includes determining whether the offeror identifier, the offeror network address, the offeree identifier, the offeree network address, the offer expression, the acceptance expression, or the consideration expression include or relate to an entity identifier not listed in a list and outputting a message indicating the entity identifier not being listed in the list for consumption on the computing terminal.
  12. 12. The system of claim 1, wherein the distributed ledger includes a distributed virtual machine which the logic accesses to locate the bytecode on the distributed ledger based on the offeror network address and the offeree network address.
  13. 13. The system of claim 1, wherein the logic is user interactable from the computing terminal.
  14. 14. The system of claim 1, wherein the LLM and the logic are separate and distinct from each other.
  15. 15. The system of claim 1, wherein the LLM is trained to (i) read the bytecode capable of being executed on the distributed ledger, (ii) determine whether the bytecode enables the smart contract on the distributed ledger, and (iii) take the first action based on the bytecode being determined to enable the smart contract and the second action based on the bytecode being determined to not enable the smart contract, via a supervised learning technique.
  16. 16. The system of claim 1, wherein the LLM is trained to (i) read the bytecode capable of being executed on the distributed ledger, (ii) determine whether the bytecode enables the smart contract on the distributed ledger, and (iii) take the first action based on the bytecode being determined to enable the smart contract and the second action based on the bytecode being determined to not enable the smart contract, via a non-supervised learning technique.
  17. 17. The system of claim 1, wherein the computing instance is a physical server.
  18. 18. The system of claim 1, wherein the computing instance is a set of physical servers.
  19. 19. The system of claim 18, wherein the set of physical servers is a server farm.
  20. 20. The system of claim 1, wherein the computing instance is configured to operate scalably and fault-tolerantly.

Description

TITLE OF INVENTION COMPUTING TECHNOLOGIES FOR LARGE LANGUAGE MODELS CROSS-REFERENCE TO RELATED PATENT APPLICATION [0001] This patent application claims a benefit of priority to US non-provisional patent application 18/219,383 filed 07 July 2023, which is incorporated by reference herein in its entirety for all purposes. TECHNICAL FIELD [0002] This disclosure relates to large language models. BACKGROUND [0003] A digital asset (e.g., a digital token) may be deployed on a distributed ledger (e.g., a blockchain) and be managed by a smart contract deployed on the distributed ledger. The smart contract may need to be audited. Conventionally, the smart contract is audited by a "black box" testing method and a code review method. [0004] The "black box" testing method involves an auditor providing a set of test inputs to the smart contract, receiving a set of corresponding outputs from the smart contract, and verifying the set of corresponding outputs against a set of expected outputs. This method is technologically deficient, because this approach may miss an edge case or have an input that is not easy to anticipate. [0005] The code review method involves a software engineer reviewing a bytecode for the smart contract. This method is not fool proof and often relies on expertise of the software engineer to determine what the smart contract represents. Since the smart contract may be difficult to reason about directly, such review of the bytecode may be time-consuming and laborious. [0006] Regardless of what method is employed to audit the smart contract, this technological problem is compounded by an uncertainty in a legal implication of the smart contract itself. Since the auditor or the software engineer are typically not legally trained, there may be a legal nuance that may not appreciated (e.g., missed) by the auditor or the software engineer, especially if the legal nuance impacts the smart contract from an enforceability perspective. SUMMARY [0007] This disclosure enables various computing technologies for smart contracts to be audited in ways that improve on conventional auditing approaches mentioned above. These technologies improve functioning of computers by enabling large language models to review bytecodes executable on distributed ledgers to determine whether those bytecodes enable smart contracts on those distributed ledgers and then acting accordingly. [0008] A system may comprise: a computing instance programmed to: host a large language model (LLM) trained to (i) read a bytecode capable of being executed on a distributed ledger, (ii) determine whether the bytecode enables a smart contract on the distributed ledger, and (iii) take a first action based on the bytecode being determined to enable the smart contract and a second action based on the bytecode being determined to not enable the smart contract, wherein the bytecode enables the smart contract by expressing (1) an offeror identifier associated with an offeror network address on the distributed ledger, (2) an offeree identifier associated with an offeree network address on the distributed ledger, (3) an offer expression associated with the offeror identifier, (4) an acceptance expression associated with the offeree identifier, and (5) a consideration expression associated with the offeror identifier and the offeree identifier, wherein the first action includes (a) identifying the offer expression, the acceptance expression, and the consideration expression, (b) generating a human-readable content describing the offer expression, the acceptance expression, and the consideration expression, and (c) outputting the human-readable content for consumption on a computing terminal, wherein the second action includes outputting a notice for consumption on the computing terminal, wherein the notice indicates the bytecode being determined to not enable the smart contract; and host a logic programmed to (i) receive the offeror network address from the computing terminal and the offeree network address from the computing terminal, (ii) locate the bytecode on the distributed ledger based on the offeror network address and the offeree network address, (iii) form a copy of the bytecode, and (iv) prompt the LLM with the copy such that the LLM (a) determines whether the copy enables the smart contract and (b) takes the first action based on the copy being determined to enable the smart contract and the second action based on the copy being determined to not enable the smart contract. [0009] A method may comprise: hosting, by a computing instance, a large language model (LLM) trained to (i) read a bytecode capable of being executed on a distributed ledger, (ii) determine whether the bytecode enables a smart contract on the distributed ledger, and (iii) take a first action based on the bytecode being determined to enable the smart contract and a second action based on the bytecode being determined to not enable the smart contract, wherein the bytecode enables