[go: up one dir, main page]

WO2024249378A2 - Devices, systems, and methods for transpiling machine-readable code into a human-readable format for the improved generation of an electronic contract stored on a blockchain network - Google Patents

Devices, systems, and methods for transpiling machine-readable code into a human-readable format for the improved generation of an electronic contract stored on a blockchain network Download PDF

Info

Publication number
WO2024249378A2
WO2024249378A2 PCT/US2024/031190 US2024031190W WO2024249378A2 WO 2024249378 A2 WO2024249378 A2 WO 2024249378A2 US 2024031190 W US2024031190 W US 2024031190W WO 2024249378 A2 WO2024249378 A2 WO 2024249378A2
Authority
WO
WIPO (PCT)
Prior art keywords
smart contract
code
readable
processor
human
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/US2024/031190
Other languages
French (fr)
Other versions
WO2024249378A3 (en
Inventor
Richard E. Silver
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Pyxelchain Technology Corp
Original Assignee
Pyxelchain Technology Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Pyxelchain Technology Corp filed Critical Pyxelchain Technology Corp
Publication of WO2024249378A2 publication Critical patent/WO2024249378A2/en
Publication of WO2024249378A3 publication Critical patent/WO2024249378A3/en
Anticipated expiration legal-status Critical
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/64Protecting data integrity, e.g. using checksums, certificates or signatures

Definitions

  • the present disclosure is generally related to decentralized systems and, more particularly, devices, systems, and methods configured to provide an improved transpiling method to convert machine-readable code into a human-readable format for an efficient, intuitive means of generating an electronic contract stored on a blockchain network.
  • a computer-implemented method of improving the generation of electronic contracts to be deployed on a decentralized network can include receiving, via a processor, smart contract code, wherein the smart contract code includes a machine-readable format, receiving, via the processor, supplemental code, wherein the supplemental code is generated in a syntactic language, compiling, via the processor, the smart contract code, extracting, via the processor, comments from the supplemental code, generating, via the processor, an artifact file based on the compiled smart contract code and the extracted comments, wherein the artifact file includes an Application Binary Interface (“ABI”), deploying, via the processor, the abstract file to the blockchain network, and generating, via the processor, an Application Human Interface (“AHI”) file based on artifact file.
  • ABSI Application Binary Interface
  • AHI Application Human Interface
  • an apparatus can include a processor, and a memory configured to store a transpiler that, when executed by the processor, causes the apparatus to receive smart contract code, wherein the smart contract code includes a machine-readable format, receive supplemental code, wherein the supplemental code is generated in a syntactic language, compile the smart contract code, extract comments from the supplemental code, generate an artifact file based on the compiled smart contract code and the extracted comments, wherein the artifact file includes an Application Binary Interface (“ABI”), deploy the abstract file to the blockchain network, generate an Application Human Interface (“AHI”) file based on artifact file, transmit the AHI file to an application accessible via a user device, and generating a human-readable interface for display via the user device based on the AHI file.
  • ABSI Application Binary Interface
  • AHI Application Human Interface
  • a system can include a user device, a decentralized sub-system, and a data management sub-system, wherein the data management sub-system includes a processor and a memory configured to store a transpiler that, when executed by the processor, causes the data management subsystem to receive smart contract code, wherein the smart contract code includes a machine-readable format, receive supplemental code, wherein the supplemental code is generated in a syntactic language, compile the smart contract code, extract comments from the supplemental code, generate an artifact file based on the compiled smart contract code and the extracted comments, wherein the artifact file includes an Application Binary Interface (“ABI”), deploy the abstract file to the decentralized subsystem, generate an Application Human Interface (“AHI”) file based on artifact file, transmit the AHI file to an application accessible via the user device.
  • ABSI Application Binary Interface
  • AHI Application Human Interface
  • FIG. 1 illustrates a system configured to transpile machine-readable code into a human-readable format and improve the generation of electronic contracts stored on a blockchain network, according to at least one non-limiting aspect of the present disclosure
  • FIG. 2 illustrates a block diagram of a decentralized system of the system of FIG. 1 , according to at least one non-limiting aspect of the present disclosure
  • FIG. 3 illustrates a block diagram of an architecture that is not configured to transpile machine-readable code into a human-readable format, according to at least one non-limiting aspect of the present disclosure
  • FIG. 4 illustrates an example of a machine-readable code, according to at least one non-limiting aspect of the present disclosure
  • FIG. 5 illustrates an example of the machine-readable interface, according to at least one non-limiting aspect of the present disclosure
  • FIG. 6 illustrates a block diagram of an architecture that is configured to transpile machine-readable code into a human-readable format and improve the generation of electronic contracts stored on a blockchain network, according to at least one non-limiting aspect of the present disclosure
  • FIG. 7 illustrates a human-readable interface configured for use by the system of FIG. 1 and the architecture of FIG. 6, according to at least one non-limiting aspect of the present disclosure
  • FIG. 8 illustrates another human-readable interface configured for use by the system of FIG. 1 and the architecture of FIG. 6, according to at least one non-limiting aspect of the present disclosure
  • FIG. 9 illustrates another human-readable interface configured for use by the system of FIG. 1 and the architecture of FIG. 6, according to at least one non-limiting aspect of the present disclosure
  • FIG. 10 illustrates another human-readable interface configured for use by the system of FIG. 1 and the architecture of FIG. 6, according to at least one non-limiting aspect of the present disclosure
  • FIG. 11 illustrates another human-readable interface configured for use by the system of FIG. 1 and the architecture of FIG. 6, according to at least one non-limiting aspect of the present disclosure
  • FIG. 12 illustrates FIG. 12, an algorithmic flow diagram of a method 1200 of transpiling machine-readable code into a human-readable format and improving the generation of electronic contracts stored on a blockchain network, according to at least one non-limiting aspect of the present disclosure
  • FIG. 13 illustrates a combined human and machine-readable interface configured for use by the system of FIG. 1 and the architecture of FIG. 6, according to at least one non-limiting aspect of the present disclosure
  • system can include one or more computing devices, servers, databases, memories, processors, and/or logic circuits configured to perform the functions and methods disclosed herein.
  • sub-system can include one or more computing devices, servers, databases, memories, processors, and/or logic circuits configured to perform a particular function and/or method as part of a broader system.
  • system and “subsystem” can be used interchangeably.
  • devices described as “sub-systems” herein may be referred to as “systems.”
  • the term “device” can include a laptop computer, a personal computer, a server, a database, and/or a mobile computing device, such as a smart phone, wearable, and/or a tablet, a server, a personal computer, a laptop, a tablet, a wearable, and/or a mobile device, such as a smart phone.
  • machine readable code While optimized for efficiency and precision in computer processing, is generally not ideal for people because it lacks the features that make text easily understandable for humans. For example, machine-readable code often uses strict syntax and structure that can be difficult for humans to parse without specialized training. It includes numerous symbols, abbreviations, and commands that are not intuitive. Such code typically lacks the context, comments, and explanatory text that help humans understand what the code is doing. It is designed to be executed by machines, not read by people.
  • Machine-readable code When humans read or write machine-readable code, the likelihood of errors increases. These errors can be minor syntax mistakes or more significant logical errors that are hard to debug.
  • Machine-readable code is optimized for efficiency and performance rather than clarity and readability. This optimization often results in code that is compact and abstract, which can be challenging for humans to interpret. Additionally, human-readable formats often include formatting, indentation, and other visual cues that aid in understanding. Machine-readable code lacks these cues, making it harder to follow the flow of logic.
  • the system 100 can include one or more user devices 102 and an application configured to broker communications to and from the one or more user devices 102, such as an application programming interface (“API”) 106.
  • the data management sub-system 110 can communicate with a decentralized sub-system 112 via an optional wallet application 111.
  • the wallet application 111 configured to interface with a data management sub-system 110 and/or the decentralized sub-system 112.
  • the wallet application 111 can be hosted by the data management sub-system 110. However, according to other non-limiting aspects, the wallet application 111 can be hosted by another sub-system, such as a centralized sub-system. Of course, according to other non-limiting aspects, the data management sub-system 110 can directly communicate with the decentralized sub-system 112.
  • the one or more components of the system 100 of FIG. 1 can be communicably coupled with one or more communication networks 108.
  • the one or more communication networks 108 can include any infrastructure network (e.g., a local area network (“LAN”), a wireless local area network (“WLAN”), a cellular network, including 3G, LTE, 5G, etc.), an ad hoc network (e.g., a Bluetooth® connection, a Near Field Communication (“NFC”) connection, a Zigbee® connection, etc.), or combinations thereof.
  • LAN local area network
  • WLAN wireless local area network
  • cellular network including 3G, LTE, 5G, etc.
  • an ad hoc network e.g., a Bluetooth® connection, a Near Field Communication (“NFC”) connection, a Zigbee® connection, etc.
  • the decentralized sub-system 112 can include a blockchain network, which — as explained in reference to FIG. 2 — is a type of distributed ledger technology (“DLT”) where smart contracts and transactions, including those executed in accordance with smart contracts, are stored, recorded, and executed with an immutable cryptographic signature called a hash.
  • the data management sub-system 110 can include a memory configured to store a transpiler that, when executed by a processor of the data management sub-system 110, cause the data management sub-system 110 to perform the functions and methods described herein.
  • the transpiler can be configured to cause the data management sub-system 110 to convert source code from one programming language into another, while preserving the original functionality.
  • the transpiler for example, can convert code between a machine-readable format, suitable for use via the decentralized sub-system 112, and an alternate source code language, which may be more suitable for use and presentation via the one or more user devices 102.
  • the memory of the data management sub-system 110 of the system 100 of FIG. 1 can be further configured to store a hash algorithm and a cryptographic algorithm that, when executed by the processor, can cause the data management sub-system 110 to perform one or more functions and/or methods described herein.
  • the data management sub-system 110 can include a “single combiner” server configured to receive information — such as highly-secure data from an entity request — and generate, distribute, and combine shares of that information.
  • the data management sub-system 110 can further include a “cluster” configured to perform the same functions. It shall be appreciated that one or more components of the system 100 of FIG. 1 can be communicably coupled with one or more communication networks 108.
  • system 100 of FIG. 1 can be implemented as a component of, or configured to interface with, one or more larger systems.
  • the system 100 of FIG. 1 can be implemented as a component of, or configured to interface with one or more systems or sub-systems described in International Patent Application No. PCT/US2024/017852, titled DEVICES, SYSTEMS, AND METHODS FOR INTEGRATING A DECENTRALIZED, BLOCKCHAIN-BASED SYSTEM WITH A CENTRALIZED, LEGACY SYSTEM, and filed on February 29, 2024, the disclosure of which is hereby incorporated by reference, in its entirety, herein.
  • the entire system 100 of FIG. 1 can be decentralized.
  • user device 102 can be a node in the embodiment wherein system 100 is decentralized as can data management sub-system 110.
  • the functionality described herein with reference to the data management sub-system 110 can be distributed across multiple nodes of the decentralized system 100.
  • the wallet application 111 can be hosted on one or more nodes of the decentralized system 100. Accordingly, it shall be appreciated that, by transpiling Application Human Interface (“AHI”) files, as will be described in further detail herein, on a decentralized, system 100 (e.g., any Web3 filesystem, such as Interplanetary File System (“IPFS”), etc), certain benefits can be achieved.
  • AHI Application Human Interface
  • implementing the entire system 100 in a decentralized manner can create immutability and enhanced auditing, enabling AHI files to be hashed and stored in a decentralized manner.
  • This means the AHI’s generated by the system 100 can be guaranteed to be consistent and can be independently audited anytime.
  • Such an embodiment would also yield AHIs that have exceptional security, since Web2 dApps are prone to all sorts of security issues, including Man-in-the-Middle Attacks, DNS Takeovers, Phishing, Deployment Risks, Internal Developer Threats, Accidental Misinformation, and/or Various OWASP Vulnerabilities, amongst others.
  • AHIs generated on a Web3 based decentralized system 100 will not be prone to such vulnerabilities, as they ensure data integrity with files that cannot be altered without detection, resistance to centralized attacks via no single point of failure, and verifiable authenticity, with users that can easily verify the file integrity and origin, protecting against phishing and tampering.
  • an embodiment wherein the entire system 100 of FIG. 1 is decentralized can leveraging Web3 benefits that generate AHIs that are secure, reliable, and easy to audit, which address critical issues plaguing Web2 dApps and AHIs.
  • FIG. 2 a block diagram of a decentralized system 112 configured to interface with the data management sub-system 110 of the system 100 of FIG. 1 is depicted in accordance with at least one non-limiting aspect of the present disclosure.
  • the decentralized system 112 of FIGS. 1 and 2 can include one or more blockchain networks.
  • the decentralized system 112 of FIG. 2 is simplified and merely illustrative.
  • the present disclosure contemplates non-limiting aspects wherein the decentralized system 112 includes other DLT-based architectures, such as alternate blockchain structures that are not necessarily represented by the non-limiting aspect of FIG. 2.
  • the decentralized system 112 can include one or more nodes 202, 204, 206, 208 configured to interact with each other such that the nodes 202, 204, 206, 208 can collectively host, modify, and verify a distributed ledger 210.
  • the decentralized system 112 can include one or more laptop computers 202, personal computers 204, servers 206, and/or mobile computing devices 208, such as a smart phone and/or a tablet.
  • the non-limiting aspect of FIG. 2 is merely illustrative.
  • the decentralized system 112 can include any number and/or type of nodes 202, 204, 206, 208 necessary to effectively host, modify, and verify a distributed ledger 210.
  • certain privileges associated with the distributed ledger 210 can be selectively allocated to certain nodes 202, 204, 206, 208 of the decentralized system 112 .
  • most nodes may be configured only to verify or validate the distributed ledger 210, while a select number of nodes may have the ability to modify the distributed ledger 210 and/or generate new blocks.
  • the distributed ledger 210 can include records of transactions conducted between accounts associated with the decentralized system 112.
  • the decentralized system 112 can be further configured to store highly-secure data and/or information associated with entity requests on the distributed ledger 210.
  • the distributed ledger 210 can include records associated with transactions executed via smart contracts, or code that automatically executes all components of an agreement that is then stored in the distributed ledger 210.
  • the code itself can be replicated across the multiple nodes 202, 204, 206, 208 of a decentralized system 112 and, therefore, the distributed ledger 210 and its records benefit from the security, permanence, and immutability provided by the decentralized system 112 .
  • the decentralized system 112 can include any foundational, “layer two,” or tributary chain, including chains such as the Bitcoin blockchain, Ethereum, Polygon, Arbitrum, and/or Loopring, amongst others.
  • a node 202, 204, 206, 208 or a computing device in communication with a node 202, 204, 206, 208 can initiate a transaction by generating a cryptographically signed message and sending the message to decentralized system 112 .
  • the message can include transaction data such as information pertaining to an object of the transaction (e.g., a block including cryptographically secured data, a cryptocurrency, a token, a NFT, etc.), a user of the one or more user devices 102 (FIG. 1), and/or other information associated with the entity request, amongst other information.
  • the node 202, 204, 206, 208 can distribute the message to the other nodes 202, 204, 206, 208 in the decentralized system 112 for recordation on the distributed ledger 210.
  • each of the nodes 202, 204, 206, 208 of the decentralized system 112 can include the transaction represented in the generated message in a block of other transactions and can attempt to validate or cryptographically solve the block.
  • the first node 202, 204, 206, 208 that solves the block can provide the solution to the other validation nodes for verification, and ledger 210 maintained at each of the nodes 202, 204, 206, 208 can be updated to add the block to the distributed ledger 210 to affect the transaction.
  • select nodes 202, 204, 206, 208 can earn at least a part of a token hosted on the distributed ledger 210 (e.g., a cryptocurrency) and/or a fee for participating in the validation of the block.
  • a token hosted on the distributed ledger 210 e.g., a cryptocurrency
  • the distributed ledger 210 and more generally, the decentralized system 112 — of FIG. 2 can be used to stored smart contracts, execute smart contracts, and/or track transactions, records, and/or ownership of any number of digital assets in accordance with smart contracts, including highly- secure data and/or information associated with entity requests.
  • the smart contracts stored and executed by the decentralized system 112 are generally constructed from a machine-readable code.
  • the data management sub-system 110 of FIG. 1 can be configured to interface with the decentralized system 112 and the one or more user devices 102 (FIG.
  • the data management sub-system 110 can broker communications via the aforementioned transpiler, converting the underlying code of a smart contract from machine readable format, suitable for use via the decentralized system 112, and a human readable format, suitable for use via the one or more user devices 102 (FIG. 1).
  • FIG. 3 a block diagram of an architecture 300 that is not configured to transpile machine-readable code into a human-readable format and improve the generation of electronic contracts stored on a blockchain network is depicted in accordance with at least one non-limiting aspect of the present disclosure.
  • the architecture directly translates user inputs received via a machine-readable interface 302, such as an Application Binary Interface (“ABI”), for example, into a machine readable code 304.
  • a machine-readable interface 302 such as an Application Binary Interface (“ABI”)
  • FIG. 4 an example of the machine-readable code 304 is depicted in FIG. 4 is depicted in accordance with at least one non-limiting aspect of the present disclosure.
  • the machine-readable code 304 can include a format that does not make intuitive sense to the average user. However, the machine-readable code 304 is generated based on user inputs provided via the machine readable interface 302, which prompts the provision of inputs that directly correlate to the machine-readable code 304 of FIG. 4.
  • FIG. 5 an example of a machine-readable interface 302 is depicted in accordance with at least one non-limiting aspect of the present disclosure.
  • the machine-readable interface 302 can be displayed via the user device 102 (FIG. 1) of the system 100 of FIG. 1.
  • the machine- readable interface 302 of FIG. 5 can include an ABI interface configured to interact with smart contracts in a particular ecosystem (e.g., Ethereum).
  • the machine-readable interface 302 can be a JSON-formatted document that defines the functions, variables, modifiers, and parameters of a smart contract and defines how to encode and decode data to call those functions.
  • the machine-readable interface 302 can be tool by which developers understand how contracts communicate with each other and how users communicate with smart contracts.
  • the machine-readable interface 302 can include a plurality of write functions 506, 508, 514, a plurality of read functions 510, 512, 516, and a plurality of widgets 507 in which a user can provide a requested input associated with each function.
  • the system can generate machine-readable code, such as the machine-readable code 304 of FIG. 4.
  • machine-readable code 304 of FIG. 4.
  • FIG. 6 a block diagram of an architecture 600 that is configured to transpile machine-readable code into a human-readable format and improve the generation of electronic contracts stored on a blockchain network is depicted according to at least one non-limiting aspect of the present disclosure.
  • the architecture of FIG. 6 is notably different from the architecture 300 of FIG. 3 due to the inclusion of data management sub-system 110 — and more specifically, the transpiler — of the system 100 of FIG. 1. Accordingly, it shall be appreciated that the system 100 of FIG. 1 can be utilized for implementation of the architecture 600 of FIG. 6.
  • the architecture 600 can implement one or more human readable interfaces 602 to enhance efficiency and promote increased use of smart contracts.
  • the architecture 600 can receive one or more user inputs via the one or more human readable interfaces 602 and, via the transpiler of the data management sub-system 110, can generate a machine readable code based on the human-readable inputs, such as the same machine readable code 304 depicted and described with reference to FIG. 4.
  • the transpiler executed by the data management sub-system 110 can algorithmically translate human-readable inputs, provided via one or more human readable interfaces 602, into another programming language that is machine-readable, such as the machine-readable code 304 of FIG. 4 by parsing the human-readable input, generating an intermediate representation, transforming the intermediate representation, and ultimately, generating the machine readable code 304.
  • the data management sub-system 110 can algorithmically parse the human- readable input to define its structure and syntax, breaking it down into an abstract syntax tree (“AST”), which is a hierarchical representation of the input’s structure that captures the syntax and semantic information.
  • the data management sub-system 110 uses the AST as an intermediate representation or generates an intermediate representation of the input to abstract the details of the human-readable language, which prepares the code for transformation into the target machine-readable language.
  • the data management sub-system 110 can then algorithmically transform the IR or AST according to the rules and syntax of the target machine-readable language, which involves mapping constructs and idioms from the human-readable input to equivalent constructs in the machine-readable language. This can ensure that the human-readable input’s intended functionality is preserved while adapting it to the target machine-readable syntax and semantics. Finally, the data management sub-system 110 can algorithmically use the transformed IR or AST to generate the machine-readable code 304. The data management subsystem 110 assembles the machine-readable code 304 from the transformed representation, ensuring that the resulting code adheres to the correct syntax and conventions of the target language.
  • the data management sub-system 110 can optionally algorithmically optimize the machine-readable code 304 to improve the performance or readability of the generated code. These optimizations can involve refactoring, inlining functions, or other enhancements that make the target code more efficient or maintainable.
  • the data management sub-system 110 can subsequently output the machine-readable code 304 in the target language for compiling, execution, or storage on the decentralized sub-system 112 (FIGS. 1 and 2).
  • the data management sub-system 110 can employ artificial intelligence (“Al”), such as a machine learning model and/or a neural network, to perform any of the aforementioned steps.
  • Al artificial intelligence
  • FIGS. 7-11 several human-readable interfaces will be described, which are depicted in accordance with several non-limiting aspects of the present disclosure. It shall be appreciated that the human-readable interfaces of FIGS. 7-11 can be associated with an application stored on a memory of the user device 102 (FIG. 1) and executed by a processor of the user device 102 (FIG. 1), hosted by the data management sub-system 110 (FIG. 1) and accessed by the user device 102 (FIG. 1) via a web-portal, or otherwise accessed by the user device 102 (FIG. 1). Regardless, the application — and more specifically, human-readable interfaces of FIGS.
  • FIGS. 7-11 can be configured to interface with the transpiler of the data management sub-system 110 (FIG. 1) and transmit and/or receive inputs from the data management sub-system 110 (FIG. 1) to ensure human-readable inputs received via the human-readable interfaces of FIGS. 7-11 are transformed into machine-readable code and machine-readable code is transformed into human-readable outputs displayed by the human-readable interfaces of FIGS. 7-11.
  • a human-readable interface 700 configured for use by the system 100 of FIG. 1 and the architecture 600 of FIG. 6 is depicted according to at least one non-limiting aspect of the present disclosure.
  • the human-readable interface 700 can be displayed via the user device 102 (FIG. 1) of the system 100 of FIG. 1 and can be one of the human-readable interfaces 602 contemplated by the architecture 600 of FIG. 6.
  • the human-readable interface 700 can include a template with one or more widgets 702, 704, 706, 707, 708, 710 that prompt user-inputs in a human-readable format.
  • the human-readable interface 700 can include a first widget 702 for the insertion of a title for the smart contract, a second widget 704 for the insertion of a description of the smart contract, a third widget 706 for the insertion of participants of the smart contract, a fourth field 707 that displays a total number of deployments for this particular template, and a fifth field 708 that displays a number of times the use themselves has deployed this particular template.
  • a sixth widget 710 can include an example use of the smart contract template, with sub-fields, represented via bold text and underlines in which the user can insert the contract particulars, such as participants, loan amounts, interest rates, penalties, and penalty durations. It shall be appreciated that, although amounts are depicted throughout the figures in USDC, these can easily be modified to include the object of any transaction, including another currency, a digital or cryptocurrency, a non-fungible token, a tangible good, and/or a service, amongst other objects of other transactions.
  • the human-readable interface 700 of FIG. 7 enables a user to easily and intuitively select a smart contract template stored on the data management subsystem 110 via the user device 102 and easily customize the smart contract pursuant to their individual objectives and preferences.
  • This enables the user to efficiently interface with and program a smart contract by interacting with the widgets and sub-fields. Interacting with the widgets and sub-fields will provide the user with an option to fill in that field with the relevant information, providing a “mad-libs” means of programming the terms of a Riccardian contract.
  • the data management sub-system 110 can then use the transpiler to generate machine-readable code 304 (FIG. 4) prior to issuing it for publishing and execution via the decentralized sub-system 112 (FIGS. 1 and 2).
  • FIG. 8 illustrates another human-readable interface 800 configured for use by the system of FIG. 1 and the architecture of FIG. 6 is depicted according to at least one non-limiting aspect of the present disclosure.
  • the human- readable interface 800 of FIG. 8 is similar to the human-readable interface 700 of FIG. 7, including both a first widget 802 for the insertion of a title for the smart contract, a second widget 804 that includes an example use of the smart contract template, with sub-fields, represented via bold text and underlines in which the user can insert the contract particulars, such as participants, loan amounts, interest rates, penalties, and penalty durations.
  • the human-readable interface 800 can further include a third widget 806 with sub-fields that allow the user to select an amount and unit of required collateral.
  • a fourth widget 808 can include a sub-field that allows the user to select a starting date for the smart contract.
  • a fifth widget 810 can include a widget that allows the user to select one or more lenders under the contract, and sixth widget 812 can include a similar widget that allows the user to select one or more borrowers under the contract.
  • a dropdown list 814 allows a user to further select a specific decentralized sub-system 112 (FIGS. 1 and 2), or blockchain network, on which the smart contract can be hosted and/or executed.
  • the human-readable interface 800 can generate and display a scannable image 816 (e.g., a QR code, a UPC code, etc.) that prompts the user to join the selected decentralized sub-system 112 (FIGS. 1 and 2).
  • a scannable image 816 e.g., a QR code, a UPC code, etc.
  • the use can automatically access and/or join the decentralized sub-system 112 (FIGS. 1 and 2) selected via the dropdown list 814.
  • the human-readable interfaces 700, 800 of FIGS. 7 and 8 depict “normal” view of the smart contract terms, which provides an intuitive means of depicting the smart contract by presenting a “mad-libs” style smart contract fields for programming.
  • the human-readable interfaces contemplated by the present disclosure can include a widget that allows a user to toggle between a “normal” view, as depicted in FIGS. 7 and 8, and a “form” view as will be described in further detail with reference to FIG. 9.
  • FIG. 9 another human-readable interface configured for use by the system of FIG. 1 and the architecture of FIG. 6 is depicted according to at least one non-limiting aspect of the present disclosure.
  • the human-readable interface 900 of FIG. 9 presents a “form” vie of the smart contract terms as an alternative to the “normal” view of FIGS. 7 and 8. According to the non-limiting aspect of FIG.
  • the human- readable interface 900 can include a first widget 902 for the insertion of a title for the smart contract, a second widget 904 for the insertion of an object of the smart contract (e.g., a transaction amount, a good, a service, etc.), a third widget 906 for the insertion of an interest rate, a fourth widget 908 for the insertion of a type of interest, a fifth widget 910 for the insertion of a payment period (e.g., hourly, daily, monthly, yearly, etc.), a sixth widget 912 for the insertion of a payment date, a seventh widget 914 for the insertion of a penalty, an eight widget 916 for the insertion of contract start date, and a ninth widget 918 for the insertion of a required collateral.
  • a first widget 902 for the insertion of a title for the smart contract e.g., a transaction amount, a good, a service, etc.
  • an object of the smart contract e.g., a transaction
  • the human-readable interface 900 can further include a first widget 920 by which the user can select one or more lenders and/or signatories under the smart contract.
  • signatories can be implemented via a DLT-technology, such as those disclosed in International Patent Application No. PCT/US2024/017852, titled DEVICES, SYSTEMS, AND METHODS FOR INTEGRATING A DECENTRALIZED, BLOCKCHAIN-BASED SYSTEM WITH A CENTRALIZED, LEGACY SYSTEM, and filed on February 29, 2024, the disclosure of which is hereby incorporated by reference, in its entirety, herein.
  • the human-readable interface 900 can further include a second widget 922 by which the user can select one or more borrowers under the smart contract.
  • a dropdown list 924 allows a user to further select a specific decentralized sub-system 112 (FIGS. 1 and 2), or blockchain network, on which the smart contract can be hosted and/or executed.
  • the human-readable interface 800 can generate and display a scannable image 926 (e.g., a QR code, a UPC code, etc.) that prompts the user to join the selected decentralized sub-system 112 (FIGS. 1 and 2).
  • the use can automatically access and/or join the decentralized sub-system 112 (FIGS. 1 and 2) selected via the dropdown list 924.
  • the contract details will be updated in the “mad-libs” view and made available for review and confirmation in subsequent interfaces.
  • the human-readable interface can include a button to confirm, which causes the data management sub-system 110 (FIG. 1) to generate, via the transpiler, the smart contract into machine-readable code 304, which is subsequently published to the decentralized sub-system 112 (FIG. 1) for execution.
  • FIG. 10 another human-readable interface 1000 configured for use by the system of FIG. 1 and the architecture of FIG. 6 is depicted according to at least one non-limiting aspect of the present disclosure.
  • the human-readable interface 1000 of FIG. 10 illustrates a means by which a user can review and interact with the smart contract generated by the human-readable interfaces 700, 800, 900 of FIGS. 7-9.
  • the data management sub-system 110 (FIG. 1) can utilize the transpiler to access machine-readable code 304 published on the decentralized sub-system 112 (FIG. 1) and transform it into the human-readable interface 1000 depicted in FIG. 10.
  • the human-readable interface 1000 can include a first field 1002 that displays the decentralized sub-system 112 (FIGS. 1 and 2) the smart contract is published and executed on, a second field 1004 that displays a next payment due date, a third field 1006 that displays a total interest paid to date, a fourth field 1008 that displays a total amount due under the smart contract, a fifth field 1010 that displays a payment amount due, a sixth field 1012 that displays a number of remaining payments, a widget 1014 that can display an amortization table associated with the smart contract, a seventh field 1016 that displays the terms of the smart contract in “mad-libs” or narrative form, an eighth field 1018 that displays a required collateral, a ninth field 1020 that displays a starting date, another widget 1020 that can display an amortization table associated with the smart contract, a dropdown list 1022 that can display participants associated with the smart contract, a tenth field 1024 that can display payment history associated with the smart contract, and
  • the human- readable interface 1000 can include a button 1026 that allows a user to make a payment required by the smart contract.
  • the lender may use the button 1026 to transmit or lend assets required under the smart contract.
  • the human-readable interface 1000 of FIG. 10 is displayed to a borrower under the smart contract, the borrower can use the button 1026 to transmit or payback a payment, including principle and/or interest required under the smart contract.
  • the action associated with the button 1026 can be attenuated as needed.
  • the button 1026 can enable a borrower to withdraw assets loaned under the smart contract or assets paid back or a lender to withdraw assets paid back under the smart contract.
  • a lender and/or borrower under the smart contract can view a “contract overview” interface, similar to that of FIG. 10.
  • money is loaned at a cost, and thus, the description of the smart contract pertains to the borrower’s payment of such costs to the lender in compliance with the terms of the smart contract.
  • the terms lender and borrower are merely directed to one non-limiting aspect of the present disclosure.
  • FIG. 10 illustrates a human-readable interface 1000 that provides the user with a summary of the smart contract that was previously launched, and the terms of the transaction that they will be authorizing. Accordingly, the button 1026 at the bottom of the contract overview interface 1000 of FIG. 10 allows the user to take actions or otherwise authorize actions in compliance with the terms of the aforementioned smart contract that was launched via the human-readable interfaces 700, 800, 900 of FIGS. 7-9.
  • FIG. 11 another human-readable interface 1100 configured for use by the system of FIG. 1 and the architecture of FIG. 6 is depicted according to at least one non-limiting aspect of the present disclosure.
  • the data management sub-system 110 can cause the user device 102 (FIG. 1) to display the human-readable interface 1100 of FIG. 11 upon a user interaction with the action button 1026 (FIG. 1).
  • the human-readable interface 1100 can include a first widget 1102 configured to enable a user to select a source of assets (e.g., a bank account, a digital wallet, etc.) for use to complete the action and a second widget 1104 configured to enable the user to choose an object of the transaction or asset (e.g., fiat, a digital currency, a non-fungible token, etc.) to utilize to complete the transaction.
  • a source of assets e.g., a bank account, a digital wallet, etc.
  • an object of the transaction or asset e.g., fiat, a digital currency, a non-fungible token, etc.
  • the available assets may be limited to those contained within selected source.
  • a third widget 1106 can allow the user to see a specific term of the smart contract the action is used to fulfill, such as a payment due, for example, whereas a fourth widget 1106 can allow the user to see a broader term of the smart contract, such as a total amount due under the contract.
  • a fifth widget 1110 can enable the user to see and/or alter the action they are about to authorize, such as a payment of the to be made from the selected source.
  • the human-readable interface 1100 can include an action button 1112 configured to authorize the data management sub-system 110 (FIG. 1) to take the action specified via the above widgets 1102, 1104, 1106, 1108, 1110.
  • the system 100 upon authorizing the action, the system 100 (FIG. 1) will execute the action in accordance with the details provided via the human- readable interface 1100, including the source of funds, the type of funds, and the transaction value in the terms set forth in the aforementioned smart contract.
  • the human-readable interface 1100 presents this information for the user’s review prior to signing and submitting the action for translation via the transpiler of the data management sub-system 110 (FIG. 1) and processing via the decentralized subsystem 112 (FIG. 1).
  • the human-readable interface 1100 allows the user to change any of details prior to signing and submitting the payment.
  • the human-readable interface 1100 and authorization provided via the button 1112 can be attenuated as needed.
  • the button 1112 can authorize a borrower’s withdrawal of assets loaned under the smart contract and/or a lender’s withdrawal of assets paid back under the smart contract.
  • the withdrawing user could use the widgets 1102, 1104, 1106, 1108, 1110 to specify a destination for withdrawn funds, a type (e.g., digital currency, non-fungible token, fiat, etc.) of funds to be withdrawn, etc.
  • FIG. 12 an algorithmic flow diagram of a method 1200 of transpiling machine-readable code into a human-readable format and improving the generation of electronic contracts stored on a blockchain network is depicted according to at least one non-limiting aspect of the present disclosure. It shall be appreciated that the method 1200 of FIG. 12 can be performed via a processor of the data management system 110 (FIG. 1) in response to the transpiler, which can be stored in memory of the data management system 110 (FIG. 1). However, according to other non-limiting aspects, certain steps can be performed by any other components of the system 100 of FIG. 1.
  • the method 1200 can include generating 1202 smart contract code (e.g., Solidity) and generating 1204 supplemental code in syntactic language (e.g., not Solidity) in the form of comments within the smart contract code or a standalone file.
  • the method 1200 can further include compiling 1206 the smart contract code into an artifact file, wherein the artifact file includes ABI and extracted comments from the supplemental code.
  • the method 1200 can include deploying 1208 the smart contract to a blockchain, for example, to the decentralized sub-system 112 (FIG. 1).
  • the method 1200 can also include transmitting 1210 the artifact file and extracted comments to the transpiler of the data management sub-system 110 (FIG. 1) and generating 1212 an AHI file based on artifact file and/or extracted comments.
  • the method can further include transmitting 1214 the AHI file to an application (e.g., mobile application, wallet) accessed via the user device 102 (FIG. 1), generating 1216 the human-readable interfaces 700, 800, 900, 1000, 1100 (FIGS. 7-11) for display via the user device 102 (FIG. 1) based on AHI file, receiving 1218 user inputs via human-readable user interface, and modifying the smart contract based on user input.
  • an application e.g., mobile application, wallet
  • the human and machine-readable interface 1300 can include a human-readable component summarizing the details of the smart contract, and a plurality of scannable images (e.g., a QR code, a UPC code, etc.) that can be read by a machine and direct a user to specific evidences, proofs, and/or maps associated with the smart contract.
  • scannable images can direct a user to smart contract information 1304, such as a contract location and Ricardian proof, and/or various evidentiary proofs 1306, including an evidence proof and/or maps, or a participant proof.
  • the human and machine-readable interface 1300 of FIG. 13 can also provide scannable images associated with individual evidences 1308, including a driver’s license, a recorded conversation, videos, witness commentaries, purchase receipts, business transcripts, employee registers, and/or call recordings, amongst other forms of evidence associated with the smart contract.
  • individual evidences 1308 including a driver’s license, a recorded conversation, videos, witness commentaries, purchase receipts, business transcripts, employee registers, and/or call recordings, amongst other forms of evidence associated with the smart contract.
  • the specific examples of evidence are merely illustrative and that, according to other non- limiting aspects, the evidences can be customized to better suit the smart contract and/or user preference.
  • the scannable images therefore, make it easier for a human to observe, identify, and access specific components of the smart contract while relying on machine-readable formats.
  • FIG. 13 illustrates a human-readable component 1302 and several machine-readable components 1304, 1306, 1308 generated by the system 100 of FIG. 1 to provide a user with simple, verifiable information pertaining to the smart contract generated via the user interfaces of FIGS. 7-11.
  • one or more machine-readable components 1304, 1306, 1308 can be used to simplify access and verify various evidences associated with the smart contract via the mobile application of the user device 102 (FIG. 1) of the system 100 (FIG. 1).
  • a computer-implemented method of improving the generation of electronic contracts to be deployed on a decentralized network including receiving, via a processor, smart contract code, wherein the smart contract code includes a machine-readable format, receiving, via the processor, supplemental code, wherein the supplemental code is generated in a syntactic language, compiling, via the processor, the smart contract code, extracting, via the processor, comments from the supplemental code, generating, via the processor, an artifact file based on the compiled smart contract code and the extracted comments, wherein the artifact file includes an Application Binary Interface (“ABI”), deploying, via the processor, the abstract file to the blockchain network, and generating, via the processor, an Application Human Interface (“AHI”) file based on artifact file.
  • ABSI Application Binary Interface
  • AHI Application Human Interface
  • Clause 2 The method according to clause 1 , further including transmitting, via the processor, the AHI file to an application accessible via a user device.
  • Clause 3 The method according to either of clauses 1 or 2, further including generating, via the processor, a human-readable interface for display via the user device based on the AHI file.
  • Clause 4 The method according to any of clauses 1-3, further including receiving, via the processor, a user input provided via the human-readable interface.
  • Clause 5. The method according to any of clauses 1-4, wherein the generated human-readable interface includes normal view including a narrative form, and wherein the user input is provided via a sub-field of the narrative format.
  • Clause 6 The method according to any of clauses 1-5, wherein the generated human-readable interface includes a form view including a plurality of form fields, and wherein the user input is provided via a form field of the plurality of form fields.
  • Clause 7 The method according to any of clauses 1-6, wherein the user input includes a modified term of the smart contract code, and wherein the method further includes modifying, via the processor, the smart contract code based on the user input.
  • Clause 8 The method according to any of clauses 1-7, wherein the user input includes an instruction to execute an action in compliance with a term of the smart contract code, and wherein the method further includes executing, via the processor, the action in accordance with the received instruction.
  • Clause 9 The method according to any of clauses 1-8, wherein the action includes a payment to be made in accordance with the term of the smart contract code.
  • Clause 10 The method according to any of clauses 1-9, wherein the action includes a withdrawal to be made in accordance with the term of the smart contract code.
  • An apparatus including a processor, and a memory configured to store a transpiler that, when executed by the processor, causes the apparatus to receive smart contract code, wherein the smart contract code includes a machine-readable format, receive supplemental code, wherein the supplemental code is generated in a syntactic language, compile the smart contract code, extract comments from the supplemental code, generate an artifact file based on the compiled smart contract code and the extracted comments, wherein the artifact file includes an Application Binary Interface (“ABI”), deploy the abstract file to the blockchain network, generate an Application Human Interface (“AHI”) file based on artifact file, transmit the AHI file to an application accessible via a user device, and generating a human-readable interface for display via the user device based on the AHI file.
  • ABSI Application Binary Interface
  • AHI Application Human Interface
  • Clause 13 The apparatus according to either of clauses 11 or 12, wherein the generated human-readable interface includes normal view including a narrative form, and wherein the user input is provided via a sub-field of the narrative format.
  • Clause 14 The apparatus according to any of clauses 11-13, wherein the generated human-readable interface includes a form view including a plurality of form fields, and wherein the user input is provided via a form field of the plurality of form fields.
  • Clause 15 The apparatus according to any of clauses 11-14, wherein the user input includes a modified term of the smart contract code, and wherein, when executed by the processor, the transpiler further causes the apparatus to modify the smart contract code based on the user input.
  • Clause 16 The apparatus according to any of clauses 11-15, wherein the user input includes an instruction to execute an action in compliance with a term of the smart contract code, and wherein, when executed by the processor, the transpiler further causes the apparatus to execute the action in accordance with the received instruction. [0117] Clause 17.
  • a system including a user device, a decentralized sub-system, and a data management sub-system
  • the data management sub-system includes a processor and a memory configured to store a transpiler that, when executed by the processor, causes the data management sub-system to receive smart contract code
  • the smart contract code includes a machine-readable format
  • receive supplemental code wherein the supplemental code is generated in a syntactic language
  • compile the smart contract code extract comments from the supplemental code
  • the artifact file includes an Application Binary Interface (“ABI”)
  • AHI Application Human Interface
  • Clause 18 The system according to clause 17, wherein, when executed by the processor, the transpiler further causes the data management sub-system to generate a human-readable interface for display via the user device based on the AHI file.
  • Clause 19 The system according to either of clauses 17 or 18, wherein, when executed by the processor, the transpiler further causes the data management subsystem to receive a user input provided via the human-readable interface.
  • Clause 20 The system according to either of clauses 17-19, wherein the user input includes a modified term of the smart contract code, and wherein, when executed by the processor, the transpiler further causes the data management sub-system to modify the smart contract code based on the user input.
  • any reference to “one aspect,” “an aspect,” “an exemplification,” “one exemplification,” and the like means that a particular feature, structure, or characteristic described in connection with the aspect is included in at least one aspect.
  • appearances of the phrases “in one aspect,” “in an aspect,” “in an exemplification,” and “in one exemplification” in various places throughout the specification are not necessarily all referring to the same aspect.
  • the particular features, structures or characteristics may be combined in any suitable manner in one or more aspects.
  • the terms “about” or “approximately” as used in the present disclosure means an acceptable error for a particular value as determined by one of ordinary skill in the art, which depends in part on how the value is measured or determined. In certain aspects, the term “about” or “approximately” means within 1, 2, 3, or 4 standard deviations. In certain aspects, the term “about” or “approximately” means within 50%, 200%, 105%, 100%, 9%, 8%, 7%, 6%, 5%, 4%, 3%, 2%, 1%, 0.5%, or 0.05% of a given value or range.
  • any numerical range recited herein includes all sub-ranges subsumed within the recited range.
  • a range of “1 to 100” includes all sub-ranges between (and including) the recited minimum value of 1 and the recited maximum value of 100, that is, having a minimum value equal to or greater than 1 and a maximum value equal to or less than 100.
  • all ranges recited herein are inclusive of the end points of the recited ranges.
  • a range of “1 to 100” includes the end points 1 and 100.
  • Any maximum numerical limitation recited in this specification is intended to include all lower numerical limitations subsumed therein, and any minimum numerical limitation recited in this specification is intended to include all higher numerical limitations subsumed therein. Accordingly, Applicant reserves the right to amend this specification, including the claims, to expressly recite any sub-range subsumed within the ranges expressly recited. All such ranges are inherently described in this specification.
  • Instructions used to program logic to perform various disclosed aspects can be stored within a memory in the system, such as dynamic random access memory (DRAM), cache, flash memory, or other storage. Furthermore, the instructions can be distributed via a network or by way of other computer readable media.
  • DRAM dynamic random access memory
  • cache cache
  • flash memory or other storage.
  • the instructions can be distributed via a network or by way of other computer readable media.
  • a machine- readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer), but is not limited to, floppy diskettes, optical disks, compact disc, read-only memory (CD-ROMs), and magneto-optical disks, read-only memory (ROMs), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic or optical cards, flash memory, or a tangible, machine-readable storage used in the transmission of information over the Internet via electrical, optical, acoustical or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.).
  • a machine e.g., a computer
  • the non-transitory computer-readable medium includes any type of tangible machine-readable medium suitable for storing or transmitting electronic instructions or information in a form readable by a machine (e.g., a computer).
  • a processor or microprocessor can be substituted for any “control circuit,” which may refer to, for example, hardwired circuitry, programmable circuitry (e.g., a computer processor including one or more individual instruction processing cores, processing unit, processor, microcontroller, microcontroller unit, controller, digital signal processor (DSP), programmable logic device (PLD), programmable logic array (PLA), or field programmable gate array (FPGA)), state machine circuitry, firmware that stores instructions executed by programmable circuitry, and any combination thereof.
  • DSP digital signal processor
  • PLD programmable logic device
  • PLA programmable logic array
  • FPGA field programmable gate array
  • the control circuit may, collectively or individually, be embodied as circuitry that forms part of a larger system, for example, an integrated circuit (IC), an application-specific integrated circuit (ASIC), a system on-chip (SoC), desktop computers, laptop computers, tablet computers, servers, smart phones, etc.
  • IC integrated circuit
  • ASIC application-specific integrated circuit
  • SoC system on-chip
  • control circuit includes, but is not limited to, electrical circuitry having at least one discrete electrical circuit, electrical circuitry having at least one integrated circuit, electrical circuitry having at least one application specific integrated circuit, electrical circuitry forming a general purpose computing device configured by a computer program (e.g., a general purpose computer configured by a computer program which at least partially carries out processes and/or devices described herein, or a microprocessor configured by a computer program which at least partially carries out processes and/or devices described herein), electrical circuitry forming a memory device (e.g., forms of random access memory), and/or electrical circuitry forming a communications device (e.g., a modem, communications switch, or optical-electrical equipment).
  • a computer program e.g., a general purpose computer configured by a computer program which at least partially carries out processes and/or devices described herein, or a microprocessor configured by a computer program which at least partially carries out processes and/or devices described herein
  • electrical circuitry forming a memory device
  • logic may refer to an app, software, firmware and/or circuitry configured to perform any of the aforementioned operations.
  • Software may be embodied as a software package, code, instructions, instruction sets and/or data recorded on non-transitory computer readable storage medium.
  • Firmware may be embodied as code, instructions or instruction sets and/or data that are hard- coded (e.g., nonvolatile) in memory devices.
  • the terms “component,” “system,” “module” and the like can refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution.
  • One or more components may be referred to herein as “configured to,” “configurable to,” “operable/operative to,” “adapted/adaptable,” “able to,” “conformable/conformed to,” etc.
  • “configured to” can generally encompass active-state components and/or inactive-state components and/or standby-state components, unless context requires otherwise.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Bioethics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Devices For Executing Special Programs (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

A computer-implemented method of improving the generation of electronic contracts to be deployed on a decentralized network is disclosed herein. The method can include receiving smart contract code, wherein the smart contract code comprises a machine-readable format, receiving supplemental code, wherein the supplemental code is generated in a syntactic language, compiling the smart contract code, extracting comments from the supplemental code, generating an artifact file based on the compiled smart contract code and the extracted comments, wherein the artifact file includes an Application Binary Interface ("ABI"), deploying the abstract file to the blockchain network, and generating an Application Human Interface ("AHI") file based on artifact file.

Description

TITLE
DEVICES, SYSTEMS, AND METHODS FOR TRANSPILING MACHINE-READABLE CODE INTO A HUMAN-READABLE FORMAT FOR THE IMPROVED GENERATION OF AN ELECTRONIC CONTRACT STORED ON A BLOCKCHAIN NETWORK
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] The present application claims the benefit of and priority under 35 U.S.C. § 120 to U.S. Provisional Patent Application No. 63/504,682, titled DEVICES, SYSTEMS, AND METHODS FOR TRANSPILING MACHINE-READABLE CODE INTO HUMAN- READABLE USER INTERFACES FOR IMPROVED GENERATION OF ELECTRONIC CONTRACTS TO BE STORED ON A BLOCKCHAIN NETWORK, filed May 26, 2023, the disclosure of which is incorporated by reference in its entirety herein.
FIELD
[0002] The present disclosure is generally related to decentralized systems and, more particularly, devices, systems, and methods configured to provide an improved transpiling method to convert machine-readable code into a human-readable format for an efficient, intuitive means of generating an electronic contract stored on a blockchain network.
SUMMARY
[0003] The following summary is provided to facilitate an understanding of some of the innovative features unique to the aspects disclosed herein and is not intended to be a full description. A full appreciation of the various aspects can be gained by taking the entire specification, claims, and abstract as a whole.
[0004] In various aspects, a computer-implemented method of improving the generation of electronic contracts to be deployed on a decentralized network is disclosed. The method can include receiving, via a processor, smart contract code, wherein the smart contract code includes a machine-readable format, receiving, via the processor, supplemental code, wherein the supplemental code is generated in a syntactic language, compiling, via the processor, the smart contract code, extracting, via the processor, comments from the supplemental code, generating, via the processor, an artifact file based on the compiled smart contract code and the extracted comments, wherein the artifact file includes an Application Binary Interface (“ABI”), deploying, via the processor, the abstract file to the blockchain network, and generating, via the processor, an Application Human Interface (“AHI”) file based on artifact file. [0005] In various aspects, an apparatus is disclosed. The apparatus can include a processor, and a memory configured to store a transpiler that, when executed by the processor, causes the apparatus to receive smart contract code, wherein the smart contract code includes a machine-readable format, receive supplemental code, wherein the supplemental code is generated in a syntactic language, compile the smart contract code, extract comments from the supplemental code, generate an artifact file based on the compiled smart contract code and the extracted comments, wherein the artifact file includes an Application Binary Interface (“ABI”), deploy the abstract file to the blockchain network, generate an Application Human Interface (“AHI”) file based on artifact file, transmit the AHI file to an application accessible via a user device, and generating a human-readable interface for display via the user device based on the AHI file.
[0006] In various aspects, a system is disclosed. The system can include a user device, a decentralized sub-system, and a data management sub-system, wherein the data management sub-system includes a processor and a memory configured to store a transpiler that, when executed by the processor, causes the data management subsystem to receive smart contract code, wherein the smart contract code includes a machine-readable format, receive supplemental code, wherein the supplemental code is generated in a syntactic language, compile the smart contract code, extract comments from the supplemental code, generate an artifact file based on the compiled smart contract code and the extracted comments, wherein the artifact file includes an Application Binary Interface (“ABI”), deploy the abstract file to the decentralized subsystem, generate an Application Human Interface (“AHI”) file based on artifact file, transmit the AHI file to an application accessible via the user device.
[0007] These and other features and characteristics of the present disclosure, as well as the methods of operation and functions of the related elements of structure and the combination of parts and economies of manufacture, will become more apparent upon consideration of the following description and the appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals designate corresponding parts in the various figures. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] Various features of the aspects described herein are set forth with particularity in the appended claims. The various aspects, however, both as to organization and methods of operation, together with advantages thereof, may be understood in accordance with the following description taken in conjunction with the accompanying drawings as follows:
[0009] FIG. 1 illustrates a system configured to transpile machine-readable code into a human-readable format and improve the generation of electronic contracts stored on a blockchain network, according to at least one non-limiting aspect of the present disclosure;
[0010] FIG. 2 illustrates a block diagram of a decentralized system of the system of FIG. 1 , according to at least one non-limiting aspect of the present disclosure;
[0011] FIG. 3 illustrates a block diagram of an architecture that is not configured to transpile machine-readable code into a human-readable format, according to at least one non-limiting aspect of the present disclosure;
[0012] FIG. 4 illustrates an example of a machine-readable code, according to at least one non-limiting aspect of the present disclosure;
[0013] FIG. 5 illustrates an example of the machine-readable interface, according to at least one non-limiting aspect of the present disclosure;
[0014] FIG. 6 illustrates a block diagram of an architecture that is configured to transpile machine-readable code into a human-readable format and improve the generation of electronic contracts stored on a blockchain network, according to at least one non-limiting aspect of the present disclosure;
[0015] FIG. 7 illustrates a human-readable interface configured for use by the system of FIG. 1 and the architecture of FIG. 6, according to at least one non-limiting aspect of the present disclosure;
[0016] FIG. 8 illustrates another human-readable interface configured for use by the system of FIG. 1 and the architecture of FIG. 6, according to at least one non-limiting aspect of the present disclosure;
[0017] FIG. 9 illustrates another human-readable interface configured for use by the system of FIG. 1 and the architecture of FIG. 6, according to at least one non-limiting aspect of the present disclosure;
[0018] FIG. 10 illustrates another human-readable interface configured for use by the system of FIG. 1 and the architecture of FIG. 6, according to at least one non-limiting aspect of the present disclosure;
[0019] FIG. 11 illustrates another human-readable interface configured for use by the system of FIG. 1 and the architecture of FIG. 6, according to at least one non-limiting aspect of the present disclosure;
[0020] FIG. 12 illustrates FIG. 12, an algorithmic flow diagram of a method 1200 of transpiling machine-readable code into a human-readable format and improving the generation of electronic contracts stored on a blockchain network, according to at least one non-limiting aspect of the present disclosure;
[0021] FIG. 13 illustrates a combined human and machine-readable interface configured for use by the system of FIG. 1 and the architecture of FIG. 6, according to at least one non-limiting aspect of the present disclosure;
[0022] Corresponding reference characters indicate corresponding parts throughout the several views. The exemplifications set out herein illustrate various aspects of the invention, in one form, and such exemplifications are not to be construed as limiting the scope of the invention in any manner.
DETAILED DESCRIPTION
[0023] Numerous specific details are set forth to provide a thorough understanding of the overall structure, function, manufacture, and use of the aspects as described in the disclosure and illustrated in the accompanying drawings. Well-known operations, components, and elements have not been described in detail so as not to obscure the aspects described in the specification. The reader will understand that the aspects described and illustrated herein are non-limiting examples, and thus it can be appreciated that the specific structural and functional details disclosed herein may be representative and illustrative. Variations and changes thereto may be made without departing from the scope of the claims. Furthermore, it is to be understood that such terms as "forward", "rearward", "left", "right", "upwardly", "downwardly", and the like are words of convenience and are not to be construed as limiting terms.
[0024] As used herein, the term “system” can include one or more computing devices, servers, databases, memories, processors, and/or logic circuits configured to perform the functions and methods disclosed herein. As used herein, the term “sub-system” can include one or more computing devices, servers, databases, memories, processors, and/or logic circuits configured to perform a particular function and/or method as part of a broader system. However, depending on the context, the terms “system” and “subsystem” can be used interchangeably. For example, when discussed outside of the context of a higher-level system, devices described as “sub-systems” herein may be referred to as “systems.” As used herein, the term “device” can include a laptop computer, a personal computer, a server, a database, and/or a mobile computing device, such as a smart phone, wearable, and/or a tablet, a server, a personal computer, a laptop, a tablet, a wearable, and/or a mobile device, such as a smart phone.
[0025] Electronic or “smart” contracts have revolutionized the way people do business by introducing a degree of automation and convenience unavailable via conventional contracts. Moreover, because smart contracts are stored on a blockchain, they are immutable, transparent, and decentralized. However, like many aspects of blockchain technology, the ability to generate, use, and review smart contracts has been inhibited by a lack of familiarity, comfort, and understanding by the general populace. For example, conventional smart contracts rely on machine-readable code (e.g., bytecode), which can be written in a variety of programming languages and executed via an execution environment (e.g., the Ethereum Virtual Machine, etc.).
[0026] Although the code underlying a smart contract is publicly recorded on a blockchain and available for anyone to review in detail, it is called “machine readable” for a reason. In short, it is tailored for use and execution by machines, not humans. Machine-readable code, while optimized for efficiency and precision in computer processing, is generally not ideal for people because it lacks the features that make text easily understandable for humans. For example, machine-readable code often uses strict syntax and structure that can be difficult for humans to parse without specialized training. It includes numerous symbols, abbreviations, and commands that are not intuitive. Such code typically lacks the context, comments, and explanatory text that help humans understand what the code is doing. It is designed to be executed by machines, not read by people. When humans read or write machine-readable code, the likelihood of errors increases. These errors can be minor syntax mistakes or more significant logical errors that are hard to debug. Machine-readable code is optimized for efficiency and performance rather than clarity and readability. This optimization often results in code that is compact and abstract, which can be challenging for humans to interpret. Additionally, human-readable formats often include formatting, indentation, and other visual cues that aid in understanding. Machine-readable code lacks these cues, making it harder to follow the flow of logic.
[0027] Thus, the technical construction and implementation of conventional smart contracts represent a technical problem that inhibits a majority of the population from easily understanding the sentences and commands that define an electronic contract's terms. Worse, such technical problems reduce efficiency of implementation and have inhibited the adoption of smart contracts, including the generation of smart contracts by the general populace for storage on a blockchain network and execution via an execution environment. Accordingly, there is a need for improved devices, systems, and methods for transpiling machine-readable code into a human-readable format for the improved generation of electronic contracts to be stored on a blockchain network.
[0028] Referring now to FIG. 1 , a system 100 configured to transpile machine- readable code into a human-readable format and improve the generation of electronic contracts stored on a blockchain network is depicted in accordance with at least one non-limiting aspect of the present disclosure. According to the non-limiting aspect of FIG. 1, the system 100 can include one or more user devices 102 and an application configured to broker communications to and from the one or more user devices 102, such as an application programming interface (“API”) 106. According to some nonlimiting aspects, the data management sub-system 110 can communicate with a decentralized sub-system 112 via an optional wallet application 111. For example, the wallet application 111 configured to interface with a data management sub-system 110 and/or the decentralized sub-system 112. According to some non-limiting aspects, the wallet application 111 can be hosted by the data management sub-system 110. However, according to other non-limiting aspects, the wallet application 111 can be hosted by another sub-system, such as a centralized sub-system. Of course, according to other non-limiting aspects, the data management sub-system 110 can directly communicate with the decentralized sub-system 112.
[0029] It shall be appreciated that one or more components of the system 100 of FIG. 1 can be communicably coupled with one or more communication networks 108. For example, the one or more communication networks 108 can include any infrastructure network (e.g., a local area network (“LAN”), a wireless local area network (“WLAN”), a cellular network, including 3G, LTE, 5G, etc.), an ad hoc network (e.g., a Bluetooth® connection, a Near Field Communication (“NFC”) connection, a Zigbee® connection, etc.), or combinations thereof. It shall be appreciated that, because the components of the system 100 of FIG. 1 are configured to be coupled to the communications network 108, any component can be configured communicate with any other component of the system 100 and therefore, lines of communication and the functionality described herein shall not be limited to the specific block diagram construction depicted in FIG. 1.
[0030] According to the non-limiting aspect of FIG. 1, the decentralized sub-system 112 can include a blockchain network, which — as explained in reference to FIG. 2 — is a type of distributed ledger technology (“DLT”) where smart contracts and transactions, including those executed in accordance with smart contracts, are stored, recorded, and executed with an immutable cryptographic signature called a hash. The data management sub-system 110 can include a memory configured to store a transpiler that, when executed by a processor of the data management sub-system 110, cause the data management sub-system 110 to perform the functions and methods described herein. For example, the transpiler can be configured to cause the data management sub-system 110 to convert source code from one programming language into another, while preserving the original functionality. The transpiler, for example, can convert code between a machine-readable format, suitable for use via the decentralized sub-system 112, and an alternate source code language, which may be more suitable for use and presentation via the one or more user devices 102.
[0031] As will be discussed in further detail herein, the memory of the data management sub-system 110 of the system 100 of FIG. 1 can be further configured to store a hash algorithm and a cryptographic algorithm that, when executed by the processor, can cause the data management sub-system 110 to perform one or more functions and/or methods described herein. For example, according to some nonlimiting aspects, the data management sub-system 110 can include a “single combiner” server configured to receive information — such as highly-secure data from an entity request — and generate, distribute, and combine shares of that information. However, according to other non-limiting aspects, the data management sub-system 110 can further include a “cluster” configured to perform the same functions. It shall be appreciated that one or more components of the system 100 of FIG. 1 can be communicably coupled with one or more communication networks 108.
[0032] It shall be further appreciated that the system 100 of FIG. 1 can be implemented as a component of, or configured to interface with, one or more larger systems. For example, according to some non-limiting aspects, the system 100 of FIG. 1 can be implemented as a component of, or configured to interface with one or more systems or sub-systems described in International Patent Application No. PCT/US2024/017852, titled DEVICES, SYSTEMS, AND METHODS FOR INTEGRATING A DECENTRALIZED, BLOCKCHAIN-BASED SYSTEM WITH A CENTRALIZED, LEGACY SYSTEM, and filed on February 29, 2024, the disclosure of which is hereby incorporated by reference, in its entirety, herein.
[0033] According to still other non-limiting aspects, the entire system 100 of FIG. 1 can be decentralized. For example, user device 102 can be a node in the embodiment wherein system 100 is decentralized as can data management sub-system 110. However, according to other non-limiting aspects, the functionality described herein with reference to the data management sub-system 110 can be distributed across multiple nodes of the decentralized system 100. Furthermore, the wallet application 111 can be hosted on one or more nodes of the decentralized system 100. Accordingly, it shall be appreciated that, by transpiling Application Human Interface (“AHI”) files, as will be described in further detail herein, on a decentralized, system 100 (e.g., any Web3 filesystem, such as Interplanetary File System (“IPFS”), etc), certain benefits can be achieved. Specifically, implementing the entire system 100 in a decentralized manner can create immutability and enhanced auditing, enabling AHI files to be hashed and stored in a decentralized manner. This means the AHI’s generated by the system 100 can be guaranteed to be consistent and can be independently audited anytime. Such an embodiment would also yield AHIs that have exceptional security, since Web2 dApps are prone to all sorts of security issues, including Man-in-the-Middle Attacks, DNS Takeovers, Phishing, Deployment Risks, Internal Developer Threats, Accidental Misinformation, and/or Various OWASP Vulnerabilities, amongst others. AHIs generated on a Web3 based decentralized system 100 will not be prone to such vulnerabilities, as they ensure data integrity with files that cannot be altered without detection, resistance to centralized attacks via no single point of failure, and verifiable authenticity, with users that can easily verify the file integrity and origin, protecting against phishing and tampering. In short, an embodiment wherein the entire system 100 of FIG. 1 is decentralized can leveraging Web3 benefits that generate AHIs that are secure, reliable, and easy to audit, which address critical issues plaguing Web2 dApps and AHIs.
[0034] Referring now to FIG. 2, a block diagram of a decentralized system 112 configured to interface with the data management sub-system 110 of the system 100 of FIG. 1 is depicted in accordance with at least one non-limiting aspect of the present disclosure. As previously discussed, the decentralized system 112 of FIGS. 1 and 2 can include one or more blockchain networks. However, the decentralized system 112 of FIG. 2 is simplified and merely illustrative. Thus, it shall be appreciated that the present disclosure contemplates non-limiting aspects wherein the decentralized system 112 includes other DLT-based architectures, such as alternate blockchain structures that are not necessarily represented by the non-limiting aspect of FIG. 2.
[0035] According to the non-limiting aspect of FIG. 2, the decentralized system 112 can include one or more nodes 202, 204, 206, 208 configured to interact with each other such that the nodes 202, 204, 206, 208 can collectively host, modify, and verify a distributed ledger 210. For example, according to the non-limiting aspect of FIG. 2, the decentralized system 112 can include one or more laptop computers 202, personal computers 204, servers 206, and/or mobile computing devices 208, such as a smart phone and/or a tablet. However, as previously noted, the non-limiting aspect of FIG. 2 is merely illustrative. As such, the decentralized system 112 can include any number and/or type of nodes 202, 204, 206, 208 necessary to effectively host, modify, and verify a distributed ledger 210. Moreover, certain privileges associated with the distributed ledger 210 can be selectively allocated to certain nodes 202, 204, 206, 208 of the decentralized system 112 . For example, most nodes may be configured only to verify or validate the distributed ledger 210, while a select number of nodes may have the ability to modify the distributed ledger 210 and/or generate new blocks.
[0036] According to the non-limiting aspect of FIG. 2, the distributed ledger 210 can include records of transactions conducted between accounts associated with the decentralized system 112. However, the decentralized system 112 can be further configured to store highly-secure data and/or information associated with entity requests on the distributed ledger 210. For example, the distributed ledger 210 can include records associated with transactions executed via smart contracts, or code that automatically executes all components of an agreement that is then stored in the distributed ledger 210. The code itself can be replicated across the multiple nodes 202, 204, 206, 208 of a decentralized system 112 and, therefore, the distributed ledger 210 and its records benefit from the security, permanence, and immutability provided by the decentralized system 112 . Notably, the decentralized system 112 can include any foundational, “layer two,” or tributary chain, including chains such as the Bitcoin blockchain, Ethereum, Polygon, Arbitrum, and/or Loopring, amongst others.
[0037] In further reference to FIG. 2, a node 202, 204, 206, 208 or a computing device in communication with a node 202, 204, 206, 208, can initiate a transaction by generating a cryptographically signed message and sending the message to decentralized system 112 . The message can include transaction data such as information pertaining to an object of the transaction (e.g., a block including cryptographically secured data, a cryptocurrency, a token, a NFT, etc.), a user of the one or more user devices 102 (FIG. 1), and/or other information associated with the entity request, amongst other information. Once a node 202, 204, 206, 208 receives the message, the node 202, 204, 206, 208 can distribute the message to the other nodes 202, 204, 206, 208 in the decentralized system 112 for recordation on the distributed ledger 210.
[0038] According to some non-limiting aspects, each of the nodes 202, 204, 206, 208 of the decentralized system 112 can include the transaction represented in the generated message in a block of other transactions and can attempt to validate or cryptographically solve the block. The first node 202, 204, 206, 208 that solves the block can provide the solution to the other validation nodes for verification, and ledger 210 maintained at each of the nodes 202, 204, 206, 208 can be updated to add the block to the distributed ledger 210 to affect the transaction. As an incentive to cryptographically solve blocks — which consumes electricity and computing resources — select nodes 202, 204, 206, 208 can earn at least a part of a token hosted on the distributed ledger 210 (e.g., a cryptocurrency) and/or a fee for participating in the validation of the block.
[0039] As such, it shall be appreciated that the distributed ledger 210 — and more generally, the decentralized system 112 — of FIG. 2 can be used to stored smart contracts, execute smart contracts, and/or track transactions, records, and/or ownership of any number of digital assets in accordance with smart contracts, including highly- secure data and/or information associated with entity requests. However, it shall be further appreciated that the smart contracts stored and executed by the decentralized system 112 are generally constructed from a machine-readable code. Thus, because the data management sub-system 110 of FIG. 1 can be configured to interface with the decentralized system 112 and the one or more user devices 102 (FIG. 1), the data management sub-system 110 can broker communications via the aforementioned transpiler, converting the underlying code of a smart contract from machine readable format, suitable for use via the decentralized system 112, and a human readable format, suitable for use via the one or more user devices 102 (FIG. 1).
[0040] Referring now to FIG. 3, a block diagram of an architecture 300 that is not configured to transpile machine-readable code into a human-readable format and improve the generation of electronic contracts stored on a blockchain network is depicted in accordance with at least one non-limiting aspect of the present disclosure. According to FIG. 3, the architecture directly translates user inputs received via a machine-readable interface 302, such as an Application Binary Interface (“ABI”), for example, into a machine readable code 304.
[0041] Referring now to FIG. 4, an example of the machine-readable code 304 is depicted in FIG. 4 is depicted in accordance with at least one non-limiting aspect of the present disclosure. The machine-readable code 304 can include a format that does not make intuitive sense to the average user. However, the machine-readable code 304 is generated based on user inputs provided via the machine readable interface 302, which prompts the provision of inputs that directly correlate to the machine-readable code 304 of FIG. 4.
[0042] Referring now to FIG. 5, an example of a machine-readable interface 302 is depicted in accordance with at least one non-limiting aspect of the present disclosure. The machine-readable interface 302, for example, can be displayed via the user device 102 (FIG. 1) of the system 100 of FIG. 1. It shall be appreciated that the machine- readable interface 302 of FIG. 5 can include an ABI interface configured to interact with smart contracts in a particular ecosystem (e.g., Ethereum). The machine-readable interface 302 can be a JSON-formatted document that defines the functions, variables, modifiers, and parameters of a smart contract and defines how to encode and decode data to call those functions. In short, the machine-readable interface 302 can be tool by which developers understand how contracts communicate with each other and how users communicate with smart contracts.
[0043] According to the non-limiting aspect of FIG. 5, the machine-readable interface 302 can include a plurality of write functions 506, 508, 514, a plurality of read functions 510, 512, 516, and a plurality of widgets 507 in which a user can provide a requested input associated with each function. Based on inputs provided via the user interface 302, the system can generate machine-readable code, such as the machine-readable code 304 of FIG. 4. In other words, neither the machine-readable interface 302 nor the machine-readable code 304 is easily understood by a non-technical user, illustrating the need for an improved architecture.
[0044] Referring now to FIG. 6, a block diagram of an architecture 600 that is configured to transpile machine-readable code into a human-readable format and improve the generation of electronic contracts stored on a blockchain network is depicted according to at least one non-limiting aspect of the present disclosure. The architecture of FIG. 6 is notably different from the architecture 300 of FIG. 3 due to the inclusion of data management sub-system 110 — and more specifically, the transpiler — of the system 100 of FIG. 1. Accordingly, it shall be appreciated that the system 100 of FIG. 1 can be utilized for implementation of the architecture 600 of FIG. 6. As will be described in further detail with reference to FIGS. 7-13, the architecture 600 can implement one or more human readable interfaces 602 to enhance efficiency and promote increased use of smart contracts. The architecture 600, for example, can receive one or more user inputs via the one or more human readable interfaces 602 and, via the transpiler of the data management sub-system 110, can generate a machine readable code based on the human-readable inputs, such as the same machine readable code 304 depicted and described with reference to FIG. 4.
[0045] Specifically, the transpiler executed by the data management sub-system 110 can algorithmically translate human-readable inputs, provided via one or more human readable interfaces 602, into another programming language that is machine-readable, such as the machine-readable code 304 of FIG. 4 by parsing the human-readable input, generating an intermediate representation, transforming the intermediate representation, and ultimately, generating the machine readable code 304. For example, the data management sub-system 110 can algorithmically parse the human- readable input to define its structure and syntax, breaking it down into an abstract syntax tree (“AST”), which is a hierarchical representation of the input’s structure that captures the syntax and semantic information. The data management sub-system 110 then uses the AST as an intermediate representation or generates an intermediate representation of the input to abstract the details of the human-readable language, which prepares the code for transformation into the target machine-readable language.
[0046] According to the architecture 600 of FIG. 6, the data management sub-system 110 can then algorithmically transform the IR or AST according to the rules and syntax of the target machine-readable language, which involves mapping constructs and idioms from the human-readable input to equivalent constructs in the machine-readable language. This can ensure that the human-readable input’s intended functionality is preserved while adapting it to the target machine-readable syntax and semantics. Finally, the data management sub-system 110 can algorithmically use the transformed IR or AST to generate the machine-readable code 304. The data management subsystem 110 assembles the machine-readable code 304 from the transformed representation, ensuring that the resulting code adheres to the correct syntax and conventions of the target language. Of course, the data management sub-system 110 can optionally algorithmically optimize the machine-readable code 304 to improve the performance or readability of the generated code. These optimizations can involve refactoring, inlining functions, or other enhancements that make the target code more efficient or maintainable. The data management sub-system 110 can subsequently output the machine-readable code 304 in the target language for compiling, execution, or storage on the decentralized sub-system 112 (FIGS. 1 and 2). It shall be appreciated that, according to some non-limiting aspects, the data management sub-system 110 can employ artificial intelligence (“Al”), such as a machine learning model and/or a neural network, to perform any of the aforementioned steps.
[0047] In reference to FIGS. 7-11 , several human-readable interfaces will be described, which are depicted in accordance with several non-limiting aspects of the present disclosure. It shall be appreciated that the human-readable interfaces of FIGS. 7-11 can be associated with an application stored on a memory of the user device 102 (FIG. 1) and executed by a processor of the user device 102 (FIG. 1), hosted by the data management sub-system 110 (FIG. 1) and accessed by the user device 102 (FIG. 1) via a web-portal, or otherwise accessed by the user device 102 (FIG. 1). Regardless, the application — and more specifically, human-readable interfaces of FIGS. 7-11 — can be configured to interface with the transpiler of the data management sub-system 110 (FIG. 1) and transmit and/or receive inputs from the data management sub-system 110 (FIG. 1) to ensure human-readable inputs received via the human-readable interfaces of FIGS. 7-11 are transformed into machine-readable code and machine-readable code is transformed into human-readable outputs displayed by the human-readable interfaces of FIGS. 7-11.
[0048] Referring now to FIG. 7, a human-readable interface 700 configured for use by the system 100 of FIG. 1 and the architecture 600 of FIG. 6 is depicted according to at least one non-limiting aspect of the present disclosure. The human-readable interface 700, for example, can be displayed via the user device 102 (FIG. 1) of the system 100 of FIG. 1 and can be one of the human-readable interfaces 602 contemplated by the architecture 600 of FIG. 6.
[0049] According to the non-limiting aspect of FIG. 7, the human-readable interface 700 can include a template with one or more widgets 702, 704, 706, 707, 708, 710 that prompt user-inputs in a human-readable format. For example, the human-readable interface 700 can include a first widget 702 for the insertion of a title for the smart contract, a second widget 704 for the insertion of a description of the smart contract, a third widget 706 for the insertion of participants of the smart contract, a fourth field 707 that displays a total number of deployments for this particular template, and a fifth field 708 that displays a number of times the use themselves has deployed this particular template. A sixth widget 710 can include an example use of the smart contract template, with sub-fields, represented via bold text and underlines in which the user can insert the contract particulars, such as participants, loan amounts, interest rates, penalties, and penalty durations. It shall be appreciated that, although amounts are depicted throughout the figures in USDC, these can easily be modified to include the object of any transaction, including another currency, a digital or cryptocurrency, a non-fungible token, a tangible good, and/or a service, amongst other objects of other transactions.
[0050] In other words, the human-readable interface 700 of FIG. 7 enables a user to easily and intuitively select a smart contract template stored on the data management subsystem 110 via the user device 102 and easily customize the smart contract pursuant to their individual objectives and preferences. This enables the user to efficiently interface with and program a smart contract by interacting with the widgets and sub-fields. Interacting with the widgets and sub-fields will provide the user with an option to fill in that field with the relevant information, providing a “mad-libs” means of programming the terms of a Riccardian contract. The data management sub-system 110 can then use the transpiler to generate machine-readable code 304 (FIG. 4) prior to issuing it for publishing and execution via the decentralized sub-system 112 (FIGS. 1 and 2).
[0051] FIG. 8 illustrates another human-readable interface 800 configured for use by the system of FIG. 1 and the architecture of FIG. 6 is depicted according to at least one non-limiting aspect of the present disclosure. It shall be appreciated that the human- readable interface 800 of FIG. 8 is similar to the human-readable interface 700 of FIG. 7, including both a first widget 802 for the insertion of a title for the smart contract, a second widget 804 that includes an example use of the smart contract template, with sub-fields, represented via bold text and underlines in which the user can insert the contract particulars, such as participants, loan amounts, interest rates, penalties, and penalty durations.
[0052] However, according to the non-limiting aspect of FIG. 8, the human-readable interface 800 can further include a third widget 806 with sub-fields that allow the user to select an amount and unit of required collateral. Likewise, a fourth widget 808 can include a sub-field that allows the user to select a starting date for the smart contract. A fifth widget 810 can include a widget that allows the user to select one or more lenders under the contract, and sixth widget 812 can include a similar widget that allows the user to select one or more borrowers under the contract. A dropdown list 814 allows a user to further select a specific decentralized sub-system 112 (FIGS. 1 and 2), or blockchain network, on which the smart contract can be hosted and/or executed. Upon selecting the desired decentralized sub-system 112 (FIGS. 1 and 2) via the dropdown list 814, the human-readable interface 800 can generate and display a scannable image 816 (e.g., a QR code, a UPC code, etc.) that prompts the user to join the selected decentralized sub-system 112 (FIGS. 1 and 2). Upon scanning the scannable image 814, the use can automatically access and/or join the decentralized sub-system 112 (FIGS. 1 and 2) selected via the dropdown list 814.
[0053] In other words, the human-readable interfaces 700, 800 of FIGS. 7 and 8 depict “normal” view of the smart contract terms, which provides an intuitive means of depicting the smart contract by presenting a “mad-libs” style smart contract fields for programming. However, as depicted in FIGS. 7 and 8, the human-readable interfaces contemplated by the present disclosure can include a widget that allows a user to toggle between a “normal” view, as depicted in FIGS. 7 and 8, and a “form” view as will be described in further detail with reference to FIG. 9.
[0054] Referring now to FIG. 9, another human-readable interface configured for use by the system of FIG. 1 and the architecture of FIG. 6 is depicted according to at least one non-limiting aspect of the present disclosure. The human-readable interface 900 of FIG. 9 presents a “form” vie of the smart contract terms as an alternative to the “normal” view of FIGS. 7 and 8. According to the non-limiting aspect of FIG. 9, the human- readable interface 900 can include a first widget 902 for the insertion of a title for the smart contract, a second widget 904 for the insertion of an object of the smart contract (e.g., a transaction amount, a good, a service, etc.), a third widget 906 for the insertion of an interest rate, a fourth widget 908 for the insertion of a type of interest, a fifth widget 910 for the insertion of a payment period (e.g., hourly, daily, monthly, yearly, etc.), a sixth widget 912 for the insertion of a payment date, a seventh widget 914 for the insertion of a penalty, an eight widget 916 for the insertion of contract start date, and a ninth widget 918 for the insertion of a required collateral.
[0055] According to the non-limiting aspect of FIG. 9, the human-readable interface 900 can further include a first widget 920 by which the user can select one or more lenders and/or signatories under the smart contract. For example, signatories can be implemented via a DLT-technology, such as those disclosed in International Patent Application No. PCT/US2024/017852, titled DEVICES, SYSTEMS, AND METHODS FOR INTEGRATING A DECENTRALIZED, BLOCKCHAIN-BASED SYSTEM WITH A CENTRALIZED, LEGACY SYSTEM, and filed on February 29, 2024, the disclosure of which is hereby incorporated by reference, in its entirety, herein. The human-readable interface 900 can further include a second widget 922 by which the user can select one or more borrowers under the smart contract. Once again, a dropdown list 924 allows a user to further select a specific decentralized sub-system 112 (FIGS. 1 and 2), or blockchain network, on which the smart contract can be hosted and/or executed. Upon selecting the desired decentralized sub-system 112 (FIGS. 1 and 2) via the dropdown list 9244, the human-readable interface 800 can generate and display a scannable image 926 (e.g., a QR code, a UPC code, etc.) that prompts the user to join the selected decentralized sub-system 112 (FIGS. 1 and 2). Upon scanning the scannable image 926, the use can automatically access and/or join the decentralized sub-system 112 (FIGS. 1 and 2) selected via the dropdown list 924.
[0056] Based on inputs provided via the “form” view of FIG. 9, the contract details will be updated in the “mad-libs” view and made available for review and confirmation in subsequent interfaces. Upon reviewing the inputted contract details in the “normal” view and/or the “form” view, the human-readable interface can include a button to confirm, which causes the data management sub-system 110 (FIG. 1) to generate, via the transpiler, the smart contract into machine-readable code 304, which is subsequently published to the decentralized sub-system 112 (FIG. 1) for execution.
[0057] Referring now to FIG. 10, another human-readable interface 1000 configured for use by the system of FIG. 1 and the architecture of FIG. 6 is depicted according to at least one non-limiting aspect of the present disclosure. The human-readable interface 1000 of FIG. 10 illustrates a means by which a user can review and interact with the smart contract generated by the human-readable interfaces 700, 800, 900 of FIGS. 7-9. In other words, in response to a user request, the data management sub-system 110 (FIG. 1) can utilize the transpiler to access machine-readable code 304 published on the decentralized sub-system 112 (FIG. 1) and transform it into the human-readable interface 1000 depicted in FIG. 10.
[0058] According to the non-limiting aspect of FIG. 10, the human-readable interface 1000 can include a first field 1002 that displays the decentralized sub-system 112 (FIGS. 1 and 2) the smart contract is published and executed on, a second field 1004 that displays a next payment due date, a third field 1006 that displays a total interest paid to date, a fourth field 1008 that displays a total amount due under the smart contract, a fifth field 1010 that displays a payment amount due, a sixth field 1012 that displays a number of remaining payments, a widget 1014 that can display an amortization table associated with the smart contract, a seventh field 1016 that displays the terms of the smart contract in “mad-libs” or narrative form, an eighth field 1018 that displays a required collateral, a ninth field 1020 that displays a starting date, another widget 1020 that can display an amortization table associated with the smart contract, a dropdown list 1022 that can display participants associated with the smart contract, a tenth field 1024 that can display payment history associated with the smart contract, and a button 1026 that can allow a user to take an action in accordance with the smart contract. For example, according to the non-limiting aspect of FIG. 10, the human- readable interface 1000 can include a button 1026 that allows a user to make a payment required by the smart contract. For example, wherein the user is a lender under the smart contract, the lender may use the button 1026 to transmit or lend assets required under the smart contract. Alternately, if the human-readable interface 1000 of FIG. 10 is displayed to a borrower under the smart contract, the borrower can use the button 1026 to transmit or payback a payment, including principle and/or interest required under the smart contract. Of course, the action associated with the button 1026 can be attenuated as needed. For example, the button 1026 can enable a borrower to withdraw assets loaned under the smart contract or assets paid back or a lender to withdraw assets paid back under the smart contract.
[0059] In other words, upon confirming the contract details via the human-readable interfaces 700, 800, 900 of FIGS. 7-10 and publishing the smart contract, a lender and/or borrower under the smart contract can view a “contract overview” interface, similar to that of FIG. 10. However, it shall be further appreciated that money is loaned at a cost, and thus, the description of the smart contract pertains to the borrower’s payment of such costs to the lender in compliance with the terms of the smart contract. Additionally, the terms lender and borrower are merely directed to one non-limiting aspect of the present disclosure. The devices, systems, and methods, disclosed herein can be implemented for any transaction including a sale or hiring or license or lease or any other transaction or binding agreement requiring the transfer of something (be it tangible or intangible) from one party to another. These transactions or agreements can involve any number of participants, parties, entities, etc. For example, FIG. 10 illustrates a human-readable interface 1000 that provides the user with a summary of the smart contract that was previously launched, and the terms of the transaction that they will be authorizing. Accordingly, the button 1026 at the bottom of the contract overview interface 1000 of FIG. 10 allows the user to take actions or otherwise authorize actions in compliance with the terms of the aforementioned smart contract that was launched via the human-readable interfaces 700, 800, 900 of FIGS. 7-9.
[0060] Referring now to FIG. 11, another human-readable interface 1100 configured for use by the system of FIG. 1 and the architecture of FIG. 6 is depicted according to at least one non-limiting aspect of the present disclosure. For example, the data management sub-system 110 (FIG. 1) can cause the user device 102 (FIG. 1) to display the human-readable interface 1100 of FIG. 11 upon a user interaction with the action button 1026 (FIG. 1). The human-readable interface 1100 can include a first widget 1102 configured to enable a user to select a source of assets (e.g., a bank account, a digital wallet, etc.) for use to complete the action and a second widget 1104 configured to enable the user to choose an object of the transaction or asset (e.g., fiat, a digital currency, a non-fungible token, etc.) to utilize to complete the transaction. According to some non-limiting aspects, the available assets may be limited to those contained within selected source. A third widget 1106 can allow the user to see a specific term of the smart contract the action is used to fulfill, such as a payment due, for example, whereas a fourth widget 1106 can allow the user to see a broader term of the smart contract, such as a total amount due under the contract. A fifth widget 1110 can enable the user to see and/or alter the action they are about to authorize, such as a payment of the to be made from the selected source. Finally, the human-readable interface 1100 can include an action button 1112 configured to authorize the data management sub-system 110 (FIG. 1) to take the action specified via the above widgets 1102, 1104, 1106, 1108, 1110.
[0061] In further reference to FIG. 11, upon authorizing the action, the system 100 (FIG. 1) will execute the action in accordance with the details provided via the human- readable interface 1100, including the source of funds, the type of funds, and the transaction value in the terms set forth in the aforementioned smart contract. In other words, the human-readable interface 1100 presents this information for the user’s review prior to signing and submitting the action for translation via the transpiler of the data management sub-system 110 (FIG. 1) and processing via the decentralized subsystem 112 (FIG. 1). Of course, the human-readable interface 1100 allows the user to change any of details prior to signing and submitting the payment. Of course, the human-readable interface 1100 and authorization provided via the button 1112 can be attenuated as needed. For example, the button 1112 can authorize a borrower’s withdrawal of assets loaned under the smart contract and/or a lender’s withdrawal of assets paid back under the smart contract. Similar to the payment aspect of FIG. 11, the withdrawing user could use the widgets 1102, 1104, 1106, 1108, 1110 to specify a destination for withdrawn funds, a type (e.g., digital currency, non-fungible token, fiat, etc.) of funds to be withdrawn, etc.
[0062] Referring now to FIG. 12, an algorithmic flow diagram of a method 1200 of transpiling machine-readable code into a human-readable format and improving the generation of electronic contracts stored on a blockchain network is depicted according to at least one non-limiting aspect of the present disclosure. It shall be appreciated that the method 1200 of FIG. 12 can be performed via a processor of the data management system 110 (FIG. 1) in response to the transpiler, which can be stored in memory of the data management system 110 (FIG. 1). However, according to other non-limiting aspects, certain steps can be performed by any other components of the system 100 of FIG. 1.
[0063] According to the non-limiting aspect of Fig. 12, the method 1200 can include generating 1202 smart contract code (e.g., Solidity) and generating 1204 supplemental code in syntactic language (e.g., not Solidity) in the form of comments within the smart contract code or a standalone file. The method 1200 can further include compiling 1206 the smart contract code into an artifact file, wherein the artifact file includes ABI and extracted comments from the supplemental code. As such, the method 1200 can include deploying 1208 the smart contract to a blockchain, for example, to the decentralized sub-system 112 (FIG. 1). The method 1200 can also include transmitting 1210 the artifact file and extracted comments to the transpiler of the data management sub-system 110 (FIG. 1) and generating 1212 an AHI file based on artifact file and/or extracted comments. The method can further include transmitting 1214 the AHI file to an application (e.g., mobile application, wallet) accessed via the user device 102 (FIG. 1), generating 1216 the human-readable interfaces 700, 800, 900, 1000, 1100 (FIGS. 7-11) for display via the user device 102 (FIG. 1) based on AHI file, receiving 1218 user inputs via human-readable user interface, and modifying the smart contract based on user input.
[0064] Referring now to FIG. 13, a combined human and machine-readable interface 1300 configured for use by the system of FIG. 1 and the architecture of FIG. 6 is depicted according to at least one non-limiting aspect of the present disclosure. According to the non-limiting aspect of FIG. 13 the human and machine-readable interface 1300 can include a human-readable component summarizing the details of the smart contract, and a plurality of scannable images (e.g., a QR code, a UPC code, etc.) that can be read by a machine and direct a user to specific evidences, proofs, and/or maps associated with the smart contract. For example, these scannable images can direct a user to smart contract information 1304, such as a contract location and Ricardian proof, and/or various evidentiary proofs 1306, including an evidence proof and/or maps, or a participant proof.
[0065] The human and machine-readable interface 1300 of FIG. 13 can also provide scannable images associated with individual evidences 1308, including a driver’s license, a recorded conversation, videos, witness commentaries, purchase receipts, business transcripts, employee registers, and/or call recordings, amongst other forms of evidence associated with the smart contract. However, it shall be appreciated that the specific examples of evidence are merely illustrative and that, according to other non- limiting aspects, the evidences can be customized to better suit the smart contract and/or user preference. The scannable images, therefore, make it easier for a human to observe, identify, and access specific components of the smart contract while relying on machine-readable formats.
[0066] In other words, FIG. 13 illustrates a human-readable component 1302 and several machine-readable components 1304, 1306, 1308 generated by the system 100 of FIG. 1 to provide a user with simple, verifiable information pertaining to the smart contract generated via the user interfaces of FIGS. 7-11. For example, one or more machine-readable components 1304, 1306, 1308 can be used to simplify access and verify various evidences associated with the smart contract via the mobile application of the user device 102 (FIG. 1) of the system 100 (FIG. 1).
[0100] Various aspects of the subject matter described herein are set out in the following numbered clauses:
[0101] Clause 1. A computer-implemented method of improving the generation of electronic contracts to be deployed on a decentralized network, the method including receiving, via a processor, smart contract code, wherein the smart contract code includes a machine-readable format, receiving, via the processor, supplemental code, wherein the supplemental code is generated in a syntactic language, compiling, via the processor, the smart contract code, extracting, via the processor, comments from the supplemental code, generating, via the processor, an artifact file based on the compiled smart contract code and the extracted comments, wherein the artifact file includes an Application Binary Interface (“ABI”), deploying, via the processor, the abstract file to the blockchain network, and generating, via the processor, an Application Human Interface (“AHI”) file based on artifact file.
[0102] Clause 2. The method according to clause 1 , further including transmitting, via the processor, the AHI file to an application accessible via a user device.
[0103] Clause 3. The method according to either of clauses 1 or 2, further including generating, via the processor, a human-readable interface for display via the user device based on the AHI file.
[0104] Clause 4. The method according to any of clauses 1-3, further including receiving, via the processor, a user input provided via the human-readable interface. [0105] Clause 5. The method according to any of clauses 1-4, wherein the generated human-readable interface includes normal view including a narrative form, and wherein the user input is provided via a sub-field of the narrative format.
[0106] Clause 6. The method according to any of clauses 1-5, wherein the generated human-readable interface includes a form view including a plurality of form fields, and wherein the user input is provided via a form field of the plurality of form fields.
[0107] Clause 7. The method according to any of clauses 1-6, wherein the user input includes a modified term of the smart contract code, and wherein the method further includes modifying, via the processor, the smart contract code based on the user input.
[0108] Clause 8. The method according to any of clauses 1-7, wherein the user input includes an instruction to execute an action in compliance with a term of the smart contract code, and wherein the method further includes executing, via the processor, the action in accordance with the received instruction.
[0109] Clause 9. The method according to any of clauses 1-8, wherein the action includes a payment to be made in accordance with the term of the smart contract code.
[0110] Clause 10. The method according to any of clauses 1-9, wherein the action includes a withdrawal to be made in accordance with the term of the smart contract code.
[0111] Clause 11. An apparatus, including a processor, and a memory configured to store a transpiler that, when executed by the processor, causes the apparatus to receive smart contract code, wherein the smart contract code includes a machine-readable format, receive supplemental code, wherein the supplemental code is generated in a syntactic language, compile the smart contract code, extract comments from the supplemental code, generate an artifact file based on the compiled smart contract code and the extracted comments, wherein the artifact file includes an Application Binary Interface (“ABI”), deploy the abstract file to the blockchain network, generate an Application Human Interface (“AHI”) file based on artifact file, transmit the AHI file to an application accessible via a user device, and generating a human-readable interface for display via the user device based on the AHI file.
[0112] Clause 12. The apparatus according to clause 11 , wherein, when executed by the processor, the transpiler further causes the apparatus to receive a user input provided via the human-readable interface.
[0113] Clause 13. The apparatus according to either of clauses 11 or 12, wherein the generated human-readable interface includes normal view including a narrative form, and wherein the user input is provided via a sub-field of the narrative format.
[0114] Clause 14. The apparatus according to any of clauses 11-13, wherein the generated human-readable interface includes a form view including a plurality of form fields, and wherein the user input is provided via a form field of the plurality of form fields. [0115] Clause 15. The apparatus according to any of clauses 11-14, wherein the user input includes a modified term of the smart contract code, and wherein, when executed by the processor, the transpiler further causes the apparatus to modify the smart contract code based on the user input.
[0116] Clause 16. The apparatus according to any of clauses 11-15, wherein the user input includes an instruction to execute an action in compliance with a term of the smart contract code, and wherein, when executed by the processor, the transpiler further causes the apparatus to execute the action in accordance with the received instruction. [0117] Clause 17. A system, including a user device, a decentralized sub-system, and a data management sub-system, wherein the data management sub-system includes a processor and a memory configured to store a transpiler that, when executed by the processor, causes the data management sub-system to receive smart contract code, wherein the smart contract code includes a machine-readable format, receive supplemental code, wherein the supplemental code is generated in a syntactic language, compile the smart contract code, extract comments from the supplemental code, generate an artifact file based on the compiled smart contract code and the extracted comments, wherein the artifact file includes an Application Binary Interface (“ABI”), deploy the abstract file to the decentralized sub-system, generate an Application Human Interface (“AHI”) file based on artifact file, transmit the AHI file to an application accessible via the user device.
[0118] Clause 18. The system according to clause 17, wherein, when executed by the processor, the transpiler further causes the data management sub-system to generate a human-readable interface for display via the user device based on the AHI file.
[0119] Clause 19. The system according to either of clauses 17 or 18, wherein, when executed by the processor, the transpiler further causes the data management subsystem to receive a user input provided via the human-readable interface.
[0120] Clause 20. The system according to either of clauses 17-19, wherein the user input includes a modified term of the smart contract code, and wherein, when executed by the processor, the transpiler further causes the data management sub-system to modify the smart contract code based on the user input.
[0121] All patents, patent applications, publications, or other disclosure material mentioned herein, are hereby incorporated by reference in their entirety as if each individual reference was expressly incorporated by reference, respectively. All references, and any material, or portion thereof, that are said to be incorporated by reference herein are incorporated herein only to the extent that the incorporated material does not conflict with existing definitions, statements, or other disclosure material set forth in this disclosure. As such, and to the extent necessary, the disclosure as set forth herein supersedes any conflicting material incorporated herein by reference and the disclosure expressly set forth in the present application controls.
[0122] The present invention has been described with reference to various exemplary and illustrative aspects. The aspects described herein are understood as providing illustrative features of varying detail of various aspects of the disclosed invention, and therefore, unless otherwise specified, it is to be understood that, to the extent possible, one or more features, elements, components, constituents, ingredients, structures, modules, and/or aspects of the disclosed aspects may be combined, separated, interchanged, and/or rearranged with or relative to one or more other features, elements, components, constituents, ingredients, structures, modules, and/or aspects of the disclosed aspects without departing from the scope of the disclosed invention. Accordingly, it will be recognized by persons having ordinary skill in the art that various substitutions, modifications, or combinations of any of the exemplary aspects may be made without departing from the scope of the invention. In addition, persons skilled in the art will recognize, or be able to ascertain using no more than routine experimentation, many equivalents to the various aspects of the invention described herein upon review of this specification. Thus, the invention is not limited by the description of the various aspects, but rather by the claims.
[0123] Those skilled in the art will recognize that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as “open” terms (e.g., the term “including” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “includes” should be interpreted as “includes but is not limited to,” etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases “at least one” and “one or more” to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim recitation to claims containing only one such recitation, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an” (e.g., “a” and/or “an” should typically be interpreted to mean “at least one” or “one or more”); the same holds true for the use of definite articles used to introduce claim recitations. [0124] In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should typically be interpreted to mean at least the recited number (e.g., the bare recitation of “two recitations,” without other modifiers, typically means at least two recitations, or two or more recitations). Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc.” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., “a system having at least one of A, B, and C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). In those instances where a convention analogous to “at least one of A, B, or C, etc.” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., “a system having at least one of A, B, or C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). It will be further understood by those within the art that typically a disjunctive word and/or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms unless context dictates otherwise. For example, the phrase “A or B” will be typically understood to include the possibilities of “A” or “B” or “A and B.”
[0125] With respect to the appended claims, those skilled in the art will appreciate that recited operations therein may be performed in any order. Also, although claim recitations are presented in a sequence(s), it should be understood that the various operations may be performed in other orders than those which are described or may be performed concurrently. Examples of such alternate orderings may include overlapping, interleaved, interrupted, reordered, incremental, preparatory, supplemental, simultaneous, reverse, or other variant orderings, unless context dictates otherwise. Furthermore, terms like “responsive to,” “related to,” or other past-tense adjectives are generally not intended to exclude such variants, unless context dictates otherwise. [0126] It is worthy to note that any reference to “one aspect,” “an aspect,” “an exemplification,” “one exemplification,” and the like means that a particular feature, structure, or characteristic described in connection with the aspect is included in at least one aspect. Thus, appearances of the phrases “in one aspect,” “in an aspect,” “in an exemplification,” and “in one exemplification” in various places throughout the specification are not necessarily all referring to the same aspect. Furthermore, the particular features, structures or characteristics may be combined in any suitable manner in one or more aspects. [0127] As used herein, the singular form of “a”, “an”, and “the” include the plural references unless the context clearly dictates otherwise.
[0128] Directional phrases used herein, such as, for example and without limitation, top, bottom, left, right, lower, upper, front, back, and variations thereof, shall relate to the orientation of the elements shown in the accompanying drawing and are not limiting upon the claims unless otherwise expressly stated.
[0129] The terms “about” or “approximately” as used in the present disclosure, unless otherwise specified, means an acceptable error for a particular value as determined by one of ordinary skill in the art, which depends in part on how the value is measured or determined. In certain aspects, the term “about” or “approximately” means within 1, 2, 3, or 4 standard deviations. In certain aspects, the term “about” or “approximately” means within 50%, 200%, 105%, 100%, 9%, 8%, 7%, 6%, 5%, 4%, 3%, 2%, 1%, 0.5%, or 0.05% of a given value or range.
[0130] In this specification, unless otherwise indicated, all numerical parameters are to be understood as being prefaced and modified in all instances by the term “about,” in which the numerical parameters possess the inherent variability characteristic of the underlying measurement techniques used to determine the numerical value of the parameter. At the very least, and not as an attempt to limit the application of the doctrine of equivalents to the scope of the claims, each numerical parameter described herein should at least be construed in light of the number of reported significant digits and by applying ordinary rounding techniques.
[0131] Any numerical range recited herein includes all sub-ranges subsumed within the recited range. For example, a range of “1 to 100” includes all sub-ranges between (and including) the recited minimum value of 1 and the recited maximum value of 100, that is, having a minimum value equal to or greater than 1 and a maximum value equal to or less than 100. Also, all ranges recited herein are inclusive of the end points of the recited ranges. For example, a range of “1 to 100” includes the end points 1 and 100. Any maximum numerical limitation recited in this specification is intended to include all lower numerical limitations subsumed therein, and any minimum numerical limitation recited in this specification is intended to include all higher numerical limitations subsumed therein. Accordingly, Applicant reserves the right to amend this specification, including the claims, to expressly recite any sub-range subsumed within the ranges expressly recited. All such ranges are inherently described in this specification.
[0132] Any patent application, patent, non-patent publication, or other disclosure material referred to in this specification and/or listed in any Application Data Sheet is incorporated by reference herein, to the extent that the incorporated materials is not inconsistent herewith. As such, and to the extent necessary, the disclosure as explicitly set forth herein supersedes any conflicting material incorporated herein by reference. Any material, or portion thereof, that is said to be incorporated by reference herein, but which conflicts with existing definitions, statements, or other disclosure material set forth herein will only be incorporated to the extent that no conflict arises between that incorporated material and the existing disclosure material.
[0133] The terms "comprise" (and any form of comprise, such as "comprises" and "comprising"), "have" (and any form of have, such as "has" and "having"), "include" (and any form of include, such as "includes" and "including") and "contain" (and any form of contain, such as "contains" and "containing") are open-ended linking verbs. As a result, a system that "comprises," "has," "includes" or "contains" one or more elements possesses those one or more elements, but is not limited to possessing only those one or more elements. Likewise, an element of a system, device, or apparatus that "comprises," "has," "includes" or "contains" one or more features possesses those one or more features, but is not limited to possessing only those one or more features.
[0134] Instructions used to program logic to perform various disclosed aspects can be stored within a memory in the system, such as dynamic random access memory (DRAM), cache, flash memory, or other storage. Furthermore, the instructions can be distributed via a network or by way of other computer readable media. Thus a machine- readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer), but is not limited to, floppy diskettes, optical disks, compact disc, read-only memory (CD-ROMs), and magneto-optical disks, read-only memory (ROMs), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic or optical cards, flash memory, or a tangible, machine-readable storage used in the transmission of information over the Internet via electrical, optical, acoustical or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.). Accordingly, the non-transitory computer-readable medium includes any type of tangible machine-readable medium suitable for storing or transmitting electronic instructions or information in a form readable by a machine (e.g., a computer). [0135] As used in any aspect herein, any reference to a processor or microprocessor can be substituted for any “control circuit,” which may refer to, for example, hardwired circuitry, programmable circuitry (e.g., a computer processor including one or more individual instruction processing cores, processing unit, processor, microcontroller, microcontroller unit, controller, digital signal processor (DSP), programmable logic device (PLD), programmable logic array (PLA), or field programmable gate array (FPGA)), state machine circuitry, firmware that stores instructions executed by programmable circuitry, and any combination thereof. The control circuit may, collectively or individually, be embodied as circuitry that forms part of a larger system, for example, an integrated circuit (IC), an application-specific integrated circuit (ASIC), a system on-chip (SoC), desktop computers, laptop computers, tablet computers, servers, smart phones, etc. Accordingly, as used herein “control circuit” includes, but is not limited to, electrical circuitry having at least one discrete electrical circuit, electrical circuitry having at least one integrated circuit, electrical circuitry having at least one application specific integrated circuit, electrical circuitry forming a general purpose computing device configured by a computer program (e.g., a general purpose computer configured by a computer program which at least partially carries out processes and/or devices described herein, or a microprocessor configured by a computer program which at least partially carries out processes and/or devices described herein), electrical circuitry forming a memory device (e.g., forms of random access memory), and/or electrical circuitry forming a communications device (e.g., a modem, communications switch, or optical-electrical equipment). Those having skill in the art will recognize that the subject matter described herein may be implemented in an analog or digital fashion or some combination thereof.
[0136] As used in any aspect herein, the term “logic” may refer to an app, software, firmware and/or circuitry configured to perform any of the aforementioned operations. Software may be embodied as a software package, code, instructions, instruction sets and/or data recorded on non-transitory computer readable storage medium. Firmware may be embodied as code, instructions or instruction sets and/or data that are hard- coded (e.g., nonvolatile) in memory devices.
[0137] As used in any aspect herein, the terms “component,” “system,” “module” and the like can refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution.
[0138] Unless specifically stated otherwise as apparent from the foregoing disclosure, it is appreciated that, throughout the foregoing disclosure, discussions using terms such as “processing,” “computing,” “calculating,” “determining,” “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.
[0139] One or more components may be referred to herein as “configured to,” “configurable to,” “operable/operative to,” “adapted/adaptable,” “able to,” “conformable/conformed to,” etc. Those skilled in the art will recognize that “configured to” can generally encompass active-state components and/or inactive-state components and/or standby-state components, unless context requires otherwise.

Claims

WHAT IS CLAIMED IS:
1. A computer-implemented method of improving the generation of electronic contracts to be deployed on a decentralized network, the method comprising: receiving, via a processor, smart contract code, wherein the smart contract code comprises a machine-readable format; receiving, via the processor, supplemental code, wherein the supplemental code is generated in a syntactic language; compiling, via the processor, the smart contract code; extracting, via the processor, comments from the supplemental code; generating, via the processor, an artifact file based on the compiled smart contract code and the extracted comments, wherein the artifact file includes an Application Binary Interface (“ABI”); deploying, via the processor, the abstract file to the blockchain network; and generating, via the processor, an Application Human Interface (“AHI”) file based on artifact file.
2. The method of claim 1 , further comprising transmitting, via the processor, the AHI file to an application accessible via a user device.
3. The method of claim 2, further comprising generating, via the processor, a human- readable interface for display via the user device based on the AHI file.
4. The method of claim 3, further comprising receiving, via the processor, a user input provided via the human-readable interface.
5. The method of claim 4, wherein the generated human-readable interface comprises normal view comprising a narrative form, and wherein the user input is provided via a subfield of the narrative format.
6. The method of claim 4, wherein the generated human-readable interface comprises a form view comprising a plurality of form fields, and wherein the user input is provided via a form field of the plurality of form fields.
7. The method of claim 4, wherein the user input comprises a modified term of the smart contract code, and wherein the method further comprises modifying, via the processor, the smart contract code based on the user input.
8. The method of claim 5, wherein the user input comprises an instruction to execute an action in compliance with a term of the smart contract code, and wherein the method further comprises executing, via the processor, the action in accordance with the received instruction.
9. The method of claim 8, wherein the action comprises a payment to be made in accordance with the term of the smart contract code.
10. The method of claim 8, wherein the action comprises a withdrawal to be made in accordance with the term of the smart contract code.
11. An apparatus, comprising: a processor; and a memory configured to store a transpiler that, when executed by the processor, causes the apparatus to: receive smart contract code, wherein the smart contract code comprises a machine-readable format; receive supplemental code, wherein the supplemental code is generated in a syntactic language; compile the smart contract code; extract comments from the supplemental code; generate an artifact file based on the compiled smart contract code and the extracted comments, wherein the artifact file includes an Application Binary Interface (“ABI”); deploy the abstract file to the blockchain network; generate an Application Human Interface (“AHI”) file based on artifact file; transmit the AHI file to an application accessible via a user device; and generating a human-readable interface for display via the user device based on the AHI file.
12. The apparatus of claim 11 , wherein, when executed by the processor, the transpiler further causes the apparatus to receive a user input provided via the human-readable interface.
13. The apparatus of claim 12, wherein the generated human-readable interface comprises normal view comprising a narrative form, and wherein the user input is provided via a sub-field of the narrative format.
14. The apparatus of claim 12, wherein the generated human-readable interface comprises a form view comprising a plurality of form fields, and wherein the user input is provided via a form field of the plurality of form fields.
15. The apparatus of claim 12, wherein the user input comprises a modified term of the smart contract code, and wherein, when executed by the processor, the transpiler further causes the apparatus to modify the smart contract code based on the user input.
16. The apparatus of claim 12, wherein the user input comprises an instruction to execute an action in compliance with a term of the smart contract code, and wherein, when executed by the processor, the transpiler further causes the apparatus to execute the action in accordance with the received instruction.
17. A system, comprising: a user device; a decentralized sub-system; and a data management sub-system, wherein the data management sub-system comprises a processor and a memory configured to store a transpiler that, when executed by the processor, causes the data management sub-system to: receive smart contract code, wherein the smart contract code comprises a machine-readable format; receive supplemental code, wherein the supplemental code is generated in a syntactic language; compile the smart contract code; extract comments from the supplemental code; generate an artifact file based on the compiled smart contract code and the extracted comments, wherein the artifact file includes an Application Binary Interface (“ABI”); deploy the abstract file to the decentralized sub-system; generate an Application Human Interface (“AHI”) file based on artifact file; transmit the AHI file to an application accessible via the user device.
18. The system of claim 17, wherein, when executed by the processor, the transpiler further causes the data management sub-system to generate a human-readable interface for display via the user device based on the AHI file.
19. The system of claim 18, wherein, when executed by the processor, the transpiler further causes the data management sub-system to receive a user input provided via the human-readable interface.
20. The method of claim 4, wherein the user input comprises a modified term of the smart contract code, and wherein, when executed by the processor, the transpiler further causes the data management sub-system to modify the smart contract code based on the user input.
PCT/US2024/031190 2023-05-26 2024-05-27 Devices, systems, and methods for transpiling machine-readable code into a human-readable format for the improved generation of an electronic contract stored on a blockchain network Pending WO2024249378A2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202363504682P 2023-05-26 2023-05-26
US63/504,682 2023-05-26

Publications (2)

Publication Number Publication Date
WO2024249378A2 true WO2024249378A2 (en) 2024-12-05
WO2024249378A3 WO2024249378A3 (en) 2025-02-06

Family

ID=93658791

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2024/031190 Pending WO2024249378A2 (en) 2023-05-26 2024-05-27 Devices, systems, and methods for transpiling machine-readable code into a human-readable format for the improved generation of an electronic contract stored on a blockchain network

Country Status (1)

Country Link
WO (1) WO2024249378A2 (en)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017066431A1 (en) * 2015-10-13 2017-04-20 TransActive Grid Inc. Use of blockchain based distributed consensus control
WO2018006072A1 (en) * 2016-06-30 2018-01-04 Clause, Inc. Systems and method for forming, storing, managing,and executing contracts
US11055703B2 (en) * 2017-06-19 2021-07-06 Hitachi, Ltd. Smart contract lifecycle management
US20190392536A1 (en) * 2018-06-26 2019-12-26 bootstrap legal Inc. Method and System for Creating and Managing a Smart Contract on a Distributed Ledger
WO2019170175A2 (en) * 2019-06-28 2019-09-12 Alibaba Group Holding Limited System and method for executing different types of blockchain contracts

Also Published As

Publication number Publication date
WO2024249378A3 (en) 2025-02-06

Similar Documents

Publication Publication Date Title
US20220383417A1 (en) System and method of providing and recording personalized context-specific advice in the form of an artificial intelligence view of a hierarchical portfolio
US12020178B2 (en) Method and apparatus for information representation, exchange, validation, and utilization through digital consolidation
KR102749705B1 (en) Upgradeable security token
US20240220983A1 (en) Blockchain-implemented systems and methods for concurrent bytecode interpretation
US20210149656A1 (en) Offline capabilities for live applications in a cloud collaboration platform
AU2023203202A1 (en) Method and system for automatically extracting relevant tax terms from forms and instructions
EP4430547A1 (en) Method and system of associating custom card designs with non-fungible tokens
CN110874739A (en) Distributed computing and storage network implementing high integrity, high bandwidth, low latency, secure processing
US9854109B2 (en) Document output processing
EP4614876A2 (en) Event streams for a sequence of events associated with a blockchain
CN105094793A (en) System and method for linguist-based human/machine interface components
US20240296350A1 (en) Computed values for knowledge graph
Sun et al. Smart contract as a service: A paradigm of reusing smart contract in web3 ecosystem
Kumble Practical Artificial Intelligence and Blockchain: A guide to converging blockchain and AI to build smart applications for new economies
CN101989255B (en) Method for automatically generating authentication test report of online authentication test
WO2024249378A2 (en) Devices, systems, and methods for transpiling machine-readable code into a human-readable format for the improved generation of an electronic contract stored on a blockchain network
EP4107686A1 (en) Synchronising event streams
US12282962B1 (en) Distributed ledger for retirement plan intra-plan participant transactions
CN117609379A (en) Model training method, system, equipment and medium based on vertical application of blockchain database
JP2025504434A (en) Digital Integration
Singh A blockchain-based decentralized application for user-driven contribution to Open Government Data
CN115422239A (en) Decision result generation method and device, processor and electronic equipment
Teles Data protection with Ethereum blockchain
US12045825B2 (en) Linguistic transformation based relationship discovery for transaction validation
Castell Ferreres Development of a DAPP