US20220383222A1 - Anonymous distributed consensus regarding the verification of protocols - Google Patents

Anonymous distributed consensus regarding the verification of protocols Download PDF

Info

Publication number
US20220383222A1
US20220383222A1 US17/883,138 US202217883138A US2022383222A1 US 20220383222 A1 US20220383222 A1 US 20220383222A1 US 202217883138 A US202217883138 A US 202217883138A US 2022383222 A1 US2022383222 A1 US 2022383222A1
Authority
US
United States
Prior art keywords
application
digraph
transitions
workflow
transition
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
US17/883,138
Inventor
Pamela E. Bell
Allen L. Brown, Jr.
David B. EZELL
Patrick J.D. SANTOS
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.)
Deixis PBC
Original Assignee
Deixis PBC
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 Deixis PBC filed Critical Deixis PBC
Priority to US17/883,138 priority Critical patent/US20220383222A1/en
Assigned to Deixis, PBC reassignment Deixis, PBC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BROWN, ALLEN L., JR., SANTOS, PATRICK J. D., EZELL, David B.
Publication of US20220383222A1 publication Critical patent/US20220383222A1/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063Operations research, analysis or management
    • G06Q10/0631Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06312Adjustment or analysis of established resource schedule, e.g. resource or task levelling, or dynamic rescheduling
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063Operations research, analysis or management
    • G06Q10/0631Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06316Sequencing of tasks or work
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063Operations research, analysis or management
    • G06Q10/0633Workflow analysis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/10Office automation; Time management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/06Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0658Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed locally
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821Electronic credentials
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/388Payment protocols; Details thereof using mutual authentication without cards, e.g. challenge-response
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/018Certifying business or products
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/0601Electronic shopping [e-shopping]
    • G06Q30/0609Buyer or seller confidence or verification
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02Banking, e.g. interest calculation or account maintenance
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00Business processing using cryptography

Definitions

  • a business process is generally automated on a computer by being represented as a workflow comprised of states and transitions between those states.
  • the formal business process for a workflow is called a protocol.
  • States represent an instance, and a transition represents the rules where an instance can change its state.
  • An instance of a process and the instance's state is generally stored in a central database.
  • An example process (or transition in workflow parlance) may be a money transfer transaction where there is a payment between two parties, both with a bank account. The paying party will debit their respective account and the payee party will credit their respective account.
  • a central database may be used to store the state of the user instances, in this case the balances of the paying party account and the payee party account.
  • the central may store the state of the transaction by keeping an audit log of the parties making the transaction, the amount transferred, the accounts affected, and a date/time stamp of the transaction.
  • DLT Distributed ledger technology
  • blockchain technology addresses this problem.
  • DLT provides a decentralized and distributed platform for software applications that is immutable and supports consensus and transparency. Parsing this description, a workflow's state is stored in a ledger that can be stored on a relatively large set of third parties called verifiers. Each verifier has its own redundant copy of the signatures of the states stored on the ledger. Hence the ledger is both distributed since it resides on multiple machines, and decentralized since no one party owns the ledger.
  • the ledger is also configured to be immutable, that is once a change is made, it cannot be undone. This is because any undo would have to be propagated to all the ledgers. Instead, if an undo has to be done, a reverse operation is propagated to all the ledgers—but the initial action is never deleted. Immutability also supports the notion of transparency; specifically, all actions performed on a ledger can be independently inspected. Indeed, sometimes transparency for DLT is referred to as “radical transparency.” This transparency enables independent verification by an arbitrary party, thereby increasing trust in the ledger.
  • the ledger is configured to support consensus. Specifically, if you ask one instance of a ledger a question, it will give the same answer as any other instance of the ledger. When you ask a central database a question, it returns the same answer because there is only one store. However, with DLT, there are multiple redundant ledgers, so the ledgers must be kept consistent with each other as to appear to be like a central database. When this consistency is achieved, the ledgers are described as having consensus.
  • DLTs such as blockchains
  • the widget buying party if the state of the shipment of the widget were stored on a DLT, the widget buying party would be assured that the website business owner wasn't presenting fraudulent data. Indeed, the DLT could act as a sort of representational escrow—an application could be created where a payment is not finalized without notification that the widget had been shipped, or better yet, received.
  • parties including third parties such as law enforcement would be able to see the progress as well.
  • DLT based applications are often called “DApps” a contraction of “Decentralized Applications.” DApps lower transactional costs because they lower the risk of reliance on non-performance by parties.
  • FIG. 1 is a top-level context diagram for protocol verification via anonymous distributed consensus.
  • FIG. 2 is a diagram of an exemplary hardware, software and communications environment for protocol verification via anonymous distributed consensus.
  • FIG. 3 is a block diagram of an exemplary architecture for a decentralized application development environment with protocol verification via anonymous distributed consensus.
  • FIG. 4 is a flow chart for an exemplary decentralized development process with protocol verification via anonymous distributed consensus.
  • FIG. 5 is a block diagram of an exemplary architecture for a decentralized application operational environment with protocol verification via anonymous distributed consensus.
  • FIG. 6 is a flow chart for an exemplary decentralized operation with protocol verification via anonymous distributed consensus.
  • Automated computing systems perform the instructions they are programmed with. If a program comprising computer instructions is correct, the computing system performs correctly. In other words, the computer system performs the tasks that the programmer intended, in the way the programmer intended. This is called semantic correctness. If the program is not correct, the computing system performs incorrectly, thereby creating semantic errors. Since computing systems are programmed by humans, it is inevitable that errors enter computing systems.
  • protocol that is a set of interacting actors and resources.
  • the concept underlying a business and enterprise process is typically referred to as a protocol.
  • the protocol is represented for automation, the representation is referred to as a workflow, or “the workflow for the protocol.”
  • the automated workflow for the protocol is referred to as a “smart contract.”
  • the underlying protocols for smart contracts may be captured graphically in the form of network or “swim lane” diagrams or state transition diagrams.
  • the underlying protocols for smart contracts have been represented in languages such as Business Process Execution Language (BPEL) and Microsoft's XLANG. Operation of tools to capture this information is described in further detail with respect to FIGS. 3 and 4 .
  • BPEL Business Process Execution Language
  • XLANG Operation of tools to capture this information is described in further detail with respect to FIGS. 3 and 4 .
  • LTS Labeled Transition System
  • An LTS is a directed graph (digraph) comprised of nodes representing states, and directed edges representing valid transitions between the states. An actor progresses through the protocol by transitioning between state to state via the edges.
  • Blockchains and DLT in general provide a means of providing anonymous consensus. Specifically, verifiers, usually anonymous third parties are able to review operations, in this case transitions in the LTS, and if the transition is verified, permitting the transition to be posted to the distributed ledger.
  • anonymity is a feature of open permissionless systems where anyone can be a verifier.
  • permissioned systems where participation is restricted to a known set of participants there may not be a need for anonymity.
  • permissioned systems One reason to use permissioned systems is to avoid the use of cryptocurrency.
  • verifiers participate in verifying DLT transactions because they receive remuneration in the form of a cryptocurrency.
  • permissionless systems where participants are maximized is useful.
  • permissioned systems may make more sense.
  • the proposed solution is to specify transitions with a language that supports formal methods, i.e. mathematical and logical operations. Insofar as mathematical and logical techniques are trusted, so too is a verification based on mathematical and logical techniques. Furthermore, mathematical and logical techniques lend themselves to automation as well. In general, we have the benefit of formal methods to program assertions and validity.
  • Asynchronous Pi (aPi) Calculus is an example of process calculi.
  • Process calculi can be used to encode an LTS and the transitions in an LTS.
  • Process calculi describe communications channels and ports and provide the means of expressing messages.
  • Process calculi provide congruence rules to show mathematical equivalence and reduction rules to transform expressions. Accordingly, process calculi support mathematical and logical operations (such as Hennessy-Milner logics) for mathematical proofs for verification, i.e. mathematically and logically showing that the software performs semantically as expected.
  • the aPi variant lends itself to distributed systems.
  • Hennessy-Milner logics are not the only kinds of logic that may be applied. Preference logics and modal logics may be applied as well. Application of preference logic is described in more detail in the paper, “Anonymous Distributed Consensus Regarding Contract Sanctioned Transition Sequences with Semantic Attachments” included in the provisional patents set forth in the Related Applications section and thereby incorporated by reference herein.
  • Validation of a protocol and/or workflow of a protocol need not be limited to formal language expressions.
  • a representation of a protocol/workflow is in a structure that lends itself to mathematical and logical analysis, that mathematical and logical apparatus may be brought to bear in the interests of verifying and translating the protocol/workflow.
  • LTS structures support bisimulation and coinduction, techniques to study the bigraph of a workflow LTS, as part of verification.
  • transitions from in the LTS are coded in aPi or another process calculus.
  • the LTS may support introspection which is the attribute of showing (also known as reflecting) information about the object being introspected.
  • the logic to verify a transition or to perform any verification may be shown to a user on demand, thereby providing transparency not on whether a transition was validated, but the logic applied.
  • protocols can be decomposed into binary exchanges where in a binary exchange, either both parties receive the other's artifacts or both don't. There is no attempted exchange where one party receive an artifact and the other doesn't. Since the results of the exchange are the same for both parties, this exchange is symmetric. Since the exchange is of artifacts representing assets, this (sub)protocol is called symmetric asset exchange (SAX).
  • SAX symmetric asset exchange
  • a specific decomposition can be of an input component, potentially representing a first process, and an output component, potentially representing a second process. These two components are atomic components that may be composed into larger protocols.
  • the input component is configured to logically determine either that a message has been received at a first channel and thereafter binds the message to a variable of the first channel, or that the message has been received at a second channel and thereafter binds the message to a variable of the second channel.
  • the output component is configured to receive a message comprised of two components, and upon receipt of the message, to send the first component on a first channel and to send the second component on a second channel A composition of the two results in the first process receiving an artifact from the second process and the second process receiving an artifact from the first process, or both processes not receiving an artifact.
  • the input and output components satisfy symmetric assets exchange.
  • the components may be configured as not to share any free names or free variables except for a name of a channel to signify completion of a process (known as “done”).
  • the done process may be used to synchronize the operation of the distributed components, similar in operation to a critical section or a mutual exclusion (mutex).
  • DLTs are not necessarily configured to store the state of a transition. Rather DLT's store Merkle tree hashes representing the signature of a transition. Since the hashes are based on the cryptographic keys of the parties performing the transitions as well as past hashes, the DLT is compact while enabling parties to determine whether a transition is legitimate. For the actual state of the transition, a party might access a traditional centralized database.
  • categorical databases are used as a sort of neutral lingua franca to identify semantic preserving transformation.
  • Categorical databases are databases that make use of mathematical category theory which enables a user to identify equivalent and congruent database schemas.
  • a smart contract may be characterized as a semantic preserving transformation of a categorical database
  • the LTS+DLT+aPi configuration allows users to apply computational, categorical and logical techniques at will.
  • FIG. 1 is a context diagram 100 for protocol verification via anonymous distributed consensus.
  • a protocol 102 is a business or enterprise process comprised of a set of actors 104 and resources 106 that interact. The actors may be humans or may be automated processes themselves. Resources represent some sort of asset that may be exchanged (goods) or some sort of asset that is transformed in performance of a contract (services). The assets may be represented electronically with some sort of token known as an artifact 108 .
  • the logic behind a protocol is known as a “workflow” or a “workflow of the protocol.”
  • the workflow may be encoded in a verification application 110 comprised of an LTS 112 where transitions are associated with verification rules 114 in a formal language such as aPi.
  • Persistence of successful transitions are on a distributed ledger 116 via a decentralized application (DApp) 118 performs and stores verification logic.
  • the verification application 110 may be comprised of atomic symmetric asset exchange components 120 communicatively coupled to the DLT corresponding to transitions.
  • the development time operation is described in further detail with respect to FIGS. 3 and 4 .
  • the run time operation is described in further detail with respect to FIGS. 5 and 6 .
  • Protocol verification via anonymous distributed consensus is generally performed on computing devices comprised of hardware, software and communications infrastructure.
  • FIG. 2 is an exemplary environment diagram 200 describing the hardware, software and communications environment for protocol verification via anonymous distributed consensus.
  • Client-side software such as web browsers, client cryptographic wallets and DApp clients are generally hosted on a client computing device 202 .
  • client computing devices 202 include without limitation personal computers, laptops, embedded devices, tablet computers, and smart phones. Since these client computing devices 202 are to access decentralized applications, these client computing devices 202 are networked.
  • the client computing device 202 has a processor 204 and a memory 206 .
  • the processor may be a central processing unit, an application processing unit, and/or a dedicated controller such as a microcontroller.
  • the client computing device 202 further includes an input/output (I/O) interface 208 , and/or a network interface 210 .
  • the I/O interface 208 may be any controller card, such as a universal asynchronous receiver/transmitter (UART) used in conjunction with a standard I/O interface protocol such as RS-232 and/or Universal Serial Bus (USB).
  • the network interface 210 may potentially work in concert with the I/O interface 208 and may be a network interface card supporting Ethernet and/or Wi-Fi and/or any number of other physical and/or datalink protocols.
  • the client computing device 202 is able to participate in both cellular and unlicensed wireless communications (e.g. Wi-Fi). Accordingly, in a smart phone/mobile embodiment, the network interface 210 may work in concert with one or more radios for cellular or unlicensed communications.
  • memory 206 is any computer-readable media which may store several software components including an operating system 218 and software components and client-side software 214 .
  • a software component is a set of computer-executable instructions stored together as a discrete whole. Examples of software components include binary executables such as static libraries, dynamically linked libraries, and executable programs. Other examples of software components include interpreted executables that are executed on a run time such as servlets, applets, p-Code binaries, and Java binaries. Software components may run in kernel mode and/or user mode.
  • Computer-readable media includes, at least, two types of computer-readable media, namely computer storage media and communications media.
  • Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data.
  • Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device.
  • communication media may embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transmission mechanisms. As defined herein, computer storage media does not include communication media.
  • Server-side applications such as verification applications 110 and DApps 118 are generally hosted on a physical server, or on a virtual machine.
  • the server 216 is any computing device that may participate in a network.
  • the network may be, without limitation, a local area network (“LAN”), a virtual private network (“VPN”), a cellular network, or the Internet.
  • the server 216 may be a computing device with sufficient I/O computing capacity to serve multiple clients.
  • the physical server 216 includes a processor 218 , a memory 220 , an input/output interface 222 and a network interface 224 .
  • In the memory 220 will be an operating system 226 and server-side applications 228 .
  • the server-side applications 228 may be hosted on a virtual machine via a cloud service 230 .
  • the cloud service 230 may represent a plurality of disaggregated servers which provide virtual application server 232 functionality and virtual storage/database 234 functionality.
  • the disaggregated servers are physical computer servers, which may have a processor, a memory, an I/O interface and/or a network interface.
  • the features and variations of the processor, the memory, the I/O interface and the network interface are substantially similar to those described for the physical server 216 . There may be differences where the disaggregated servers are optimized for throughput and/or for disaggregation.
  • machine learning/cognitive network software (not shown) and other server-side software (not shown) may be hosted on virtual application servers 232 .
  • the cloud service 230 may be made accessible via an integrated cloud infrastructure 236 .
  • Cloud infrastructure 236 not only provides access to cloud services 230 but also to billing services and other monetization services.
  • Cloud infrastructure 236 may provide additional service abstractions such as Platform as a Service (“PAAS”), Infrastructure as a Service (“IAAS”), and Software as a Service (“SAAS”).
  • PAAS Platform as a Service
  • IAAS Infrastructure as a Service
  • SAAS Software as a Service
  • LTS+DLT+aPi is configured to perform protocol verification via anonymous distributed consensus.
  • Key applications are divided into development time applications and run time applications.
  • Development time applications are described in the context of FIG. 3 , a block diagram 300 of an exemplary development environment for protocol verification via anonymous distributed consensus and FIG. 4 , a flow chart of the operation of the same.
  • Run time applications are described in more detail with respect to FIGS. 5 and 6 .
  • operation begins with a workflow design tool 302 .
  • the workflow design tool may receive specifications of actors and resources interacting.
  • the specification may be of actors, states, transitions between the states, and of artifacts representing resources as assets to be exchanged.
  • the output of the workflow design tool 302 is a specification of a protocol of a business or enterprise process
  • the workflow design tool 302 may be a graphical tool which receives as input the drawing of a network (swimlane) diagram or in the alternative a drawing of a state machine.
  • swimlanes correspond to actors. Arrows between swimlanes indicate interactions between actors and may be associated with artifacts or functions performed during the interactions. Note that in the network diagram, flow does not necessarily represent state transitions since flow is between actors rather than states.
  • nodes may represent states
  • arrows between states may represent transitions between states. Transitions again here may be associated with artifacts or functions performed during the interactions.
  • Graphical representations may be converted by the workflow design tool 302 into textual form, for example in BPEL or XLANG.
  • BPEL or XLANG may be hand edited with a text editor.
  • processing starts by a when a receiver module 304 receives a protocol based on a drawing of a protocol 402 , or from a textual protocol specification, edited with workflow design tool 302 .
  • the receiver module 304 parses the input specification, looks for syntax and other errors, and stores the parsed input specification into an intermediate representation format suitable for rules checking.
  • the representation is stored by a representation engine 308 in a representation data store 310 .
  • Rules are predetermined and are managed by the rules engine 312 and stored in rules data store 314 .
  • the intermediate representation format of the protocol is a virtual version of an LTS with associated transition rules stored in the rules data store 314 and accessible by the rules engine 312 . Rules may be reviewed from the workflow design tool 302 by selected transitions which reflect back the rules.
  • Static tests such as completeness checks, logic checks and bisimulations may be performed by a logic checker/validator 316 .
  • a validator application 320 a simulated application comprising a validator application 318 and a DApp 320 may be generated by an application generator 322 .
  • the generated application may be configured to be communicatively coupled with a test or even production distributed ledger 324 .
  • the application generator may also generated browser applications 326 and/or oracles 328 (which among other things provide representations of external state to distributed ledgers).
  • test inputs may be run to validate the intermediate representation as part of dynamic testing.
  • Checks may be based on rules specific to an application, or may be rules that are to be true of any application. Checks may be of the LTS itself, such as via bisimulation and/or coinduction, or may be of the transition rules themselves e.g. aPi checks.
  • testing need not be specific to the LTS and the rules in aPi.
  • categorical database representations may be generated to perform category theory based checks as well.
  • the application generator 322 generates the application components and deploys as described above.
  • the versioning, building, and deploying cycle may be scripted and orchestrated via integration with DevOps software.
  • FIG. 5 is a block diagram 500 of an exemplary run time environment for protocol verification via anonymous distributed consensus and
  • FIG. 6 is a flow chart 600 of the operation of the same.
  • a validator application 502 has been generated by an application generator 322 . Unlike the validator application 318 under test, validator application 502 is deployed into production.
  • the validator application 502 is configured to receive input triggers 504 which are software messages (either via a push communications protocol such as message passing or by a pull communications protocol such software notifications/events).
  • the validator application 502 includes a representation generally in the form of an LTS with rules 510 associated with transitions 512 in the LTS.
  • the rules 510 are encoded via aPi.
  • the generated application also includes clients such as a browser application 514 running on a web browser 516 optionally configured with a cryptocurrency wallet, oracles 518 , and a DApp 520 to perform persistence on a distributed ledger 522 .
  • the validator application 502 receives an input trigger 504 from a browser application 514 or an oracle 518 . In block 604 , the validator application 502 then identifies the relevant transition 512 in the protocol, and retrieves the rule 510 associated with the transition 512 .
  • the validator application 502 then performs the retrieved rule 510 .
  • the LTS is updated and the validator application 502 calls the DApp 520 to post the validated transaction to the distributed ledger 522 .

Abstract

Techniques to perform mathematically and logically rigorous validations for decentralized applications (DApp) communicatively coupled to a distributed ledger are disclosed. A protocol for a business or enterprise process is encoded as a workflow on a labeled transition system as part of a DApp. Transitions are coded via an asynchronous Pi Calculus or other process calculi. A rules engine validates transitions using process calculi operations, or alternatively performing mathematical and logical analyses on the labeled transition system. Validations are disclosed for both development time and run time. In some embodiments, the logic behind the DApp is composed of a predetermined set of components representing processes. In one specific embodiment, the predetermined set of components is solely of an input component and an output component when composed perform a transaction where either both components received artifact representations from the other component or neither do.

Description

    CROSS-REFERENCE TO RELATED PATENT APPLICATIONS
  • This patent application claims priority to U.S. Provisional Patent Application 62/712,768, entitled “Anonymous Distributed Consensus Regarding the Verification of Health Care Protocols,” filed on Jul. 31, 2018, U.S. Provisional Patent Application 62/712,792, entitled “Anonymous Distributed Consensus Regarding Contract-Sanctioned Transition Sequences with Semantic Attachments,” filed on Jul. 31, 2018, U.S. Provisional Patent Application 62/879,991, entitled “Symmetric Asset Exchange,” filed on Jul. 29, 2019, and U.S. patent application Ser. No. 16/526,872, entitled “Anonymous Distributed Consensus Regarding the Verification of Protocols,” filed Jul. 30, 2019, all of which are hereby incorporated by reference.
  • BACKGROUND
  • A business process is generally automated on a computer by being represented as a workflow comprised of states and transitions between those states. The formal business process for a workflow is called a protocol. States represent an instance, and a transition represents the rules where an instance can change its state. An instance of a process and the instance's state is generally stored in a central database. An example process (or transition in workflow parlance) may be a money transfer transaction where there is a payment between two parties, both with a bank account. The paying party will debit their respective account and the payee party will credit their respective account. A central database may be used to store the state of the user instances, in this case the balances of the paying party account and the payee party account. Furthermore, the central may store the state of the transaction by keeping an audit log of the parties making the transaction, the amount transferred, the accounts affected, and a date/time stamp of the transaction.
  • This state of affairs works very well for the class of software applications where transitions may be verified with rules. In the case of our debit/credit example above, a rule might be that the amount credited should equal the amount debited. Otherwise, either one party loses money, or the accounts reflect more money than the government issued. Since for this workflow, the transition can be independently verified by an automated system with this rule, the system can be open generally to any party with an account and still be expected to work in a robust manner.
  • Notwithstanding the theory, users prefer to secure their systems. This is generally accomplished with user account security and access control lists and their variants. The point is that just because a system can be open, doesn't mean that users trust the system. Presently, for centralized systems including the example system above with a central database, trust is effected with cryptographic methods.
  • However, what happens with the class of applications where the parties distrust each other to the point that they don't trust each other's systems? Consider a party that orders a widget from a website that accepts the party's payment. The widget doesn't arrive. The party contacts the website business owner who assures the party that the widget has been shipped. Indeed, the website itself reflects that state of affairs. At some point, the party may think the website is wrong, or worse that the business owner is fraudulent.
  • Distributed ledger technology (DLT), including blockchain technology, addresses this problem. DLT provides a decentralized and distributed platform for software applications that is immutable and supports consensus and transparency. Parsing this description, a workflow's state is stored in a ledger that can be stored on a relatively large set of third parties called verifiers. Each verifier has its own redundant copy of the signatures of the states stored on the ledger. Hence the ledger is both distributed since it resides on multiple machines, and decentralized since no one party owns the ledger.
  • The ledger is also configured to be immutable, that is once a change is made, it cannot be undone. This is because any undo would have to be propagated to all the ledgers. Instead, if an undo has to be done, a reverse operation is propagated to all the ledgers—but the initial action is never deleted. Immutability also supports the notion of transparency; specifically, all actions performed on a ledger can be independently inspected. Indeed, sometimes transparency for DLT is referred to as “radical transparency.” This transparency enables independent verification by an arbitrary party, thereby increasing trust in the ledger.
  • Finally, the ledger is configured to support consensus. Specifically, if you ask one instance of a ledger a question, it will give the same answer as any other instance of the ledger. When you ask a central database a question, it returns the same answer because there is only one store. However, with DLT, there are multiple redundant ledgers, so the ledgers must be kept consistent with each other as to appear to be like a central database. When this consistency is achieved, the ledgers are described as having consensus.
  • Thus far, DLTs such as blockchains, all have the attributes of being decentralized, distributed, immutable and supporting consensus and transparency. DLTs engender trust. In the case of our widget buying party, if the state of the shipment of the widget were stored on a DLT, the widget buying party would be assured that the website business owner wasn't presenting fraudulent data. Indeed, the DLT could act as a sort of representational escrow—an application could be created where a payment is not finalized without notification that the widget had been shipped, or better yet, received. Throughout the workflow, both the buyer and the seller, and indeed any party, including third parties such as law enforcement would be able to see the progress as well.
  • Such DLT based applications are often called “DApps” a contraction of “Decentralized Applications.” DApps lower transactional costs because they lower the risk of reliance on non-performance by parties.
  • All this begs the question as to whether the DLT itself has been programmed correctly. Because for DApps, the DLT represents the true state of the affairs, it is particularly important to ensure that the DLT itself is correct.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The Detailed Description is set forth with reference to the accompanying figures.
  • FIG. 1 is a top-level context diagram for protocol verification via anonymous distributed consensus.
  • FIG. 2 is a diagram of an exemplary hardware, software and communications environment for protocol verification via anonymous distributed consensus.
  • FIG. 3 is a block diagram of an exemplary architecture for a decentralized application development environment with protocol verification via anonymous distributed consensus.
  • FIG. 4 is a flow chart for an exemplary decentralized development process with protocol verification via anonymous distributed consensus.
  • FIG. 5 is a block diagram of an exemplary architecture for a decentralized application operational environment with protocol verification via anonymous distributed consensus.
  • FIG. 6 is a flow chart for an exemplary decentralized operation with protocol verification via anonymous distributed consensus.
  • DETAILED DESCRIPTION
  • Mathematical and Logical Foundations of Protocol Verification via Anonymous Distributed Consensus
  • Prior to describing embodiments of protocol verification via anonymous distributed consensus, it is useful to discuss some underlying techniques. These techniques are described in greater detail as in the papers, “Anonymous Distributed Consensus Regarding the Verified Execution of Health Care Protocols”, “Anonymous Distributed Consensus Regarding Contract Sanctioned Transition Sequences with Semantic Attachments”, “Symmetric Asset Exchange: A Universal Construction in Contract Patterns for Payments and Logistics”, and “Cones, Co-Cones and Causality: A Categorical Reconstruction of Digital Contracts” all of which are included in provisional patents that this application claims priority to and all of which are incorporated by reference in the Related Application section herein. Notwithstanding the incorporation by reference, some outline of these techniques are in order.
  • 1. Labeled Transition Systems+Distributed Ledger Technology+Formal Methods=Rigorous Verification
  • Automated computing systems perform the instructions they are programmed with. If a program comprising computer instructions is correct, the computing system performs correctly. In other words, the computer system performs the tasks that the programmer intended, in the way the programmer intended. This is called semantic correctness. If the program is not correct, the computing system performs incorrectly, thereby creating semantic errors. Since computing systems are programmed by humans, it is inevitable that errors enter computing systems.
  • To minimize the entrance of errors, there is a body of study known as “formal methods.” Specifically, programs are set forth in a representation, often in a language that supports formal methods, i.e. mathematical and logical operations. Because the programs are set forth in a representation that supports formal methods, the programs can use mathematical and logical operations to prove that the program is correct. Indeed, programs can be written to verify the correctness of other programs using mathematical and logical operations. In addition to verification, programs can be written to transform representations into other representations, i.e. translated into other programming languages. The translations may be trusted since mathematical and logical operations supported by the representation provide a rigorous means to specify the operations comprising the translation.
  • In short, a rigorous representation, and a use of a language that supports formal methods, provides the means to specify, verify and transform programs built on DLT with mathematical and logical rigor.
  • Accordingly, we start with a protocol, that is a set of interacting actors and resources. The concept underlying a business and enterprise process is typically referred to as a protocol. Where the protocol is represented for automation, the representation is referred to as a workflow, or “the workflow for the protocol.” Where a protocol is to be enforced via computer operation, the automated workflow for the protocol is referred to as a “smart contract.” The underlying protocols for smart contracts may be captured graphically in the form of network or “swim lane” diagrams or state transition diagrams. The underlying protocols for smart contracts have been represented in languages such as Business Process Execution Language (BPEL) and Microsoft's XLANG. Operation of tools to capture this information is described in further detail with respect to FIGS. 3 and 4 .
  • Once a protocol for a smart contract is identified for automation, the protocol workflow is to be captured in some automatable structure. One automatable structure is a Labeled Transition System (LTS). An LTS is a directed graph (digraph) comprised of nodes representing states, and directed edges representing valid transitions between the states. An actor progresses through the protocol by transitioning between state to state via the edges.
  • As previously mentioned, users assume that an automated system is correct, i.e. does not have semantic errors. If semantic errors are discovered, the users will not trust the system and will not use it. Accordingly, some means to verify transitions is in order.
  • Blockchains and DLT in general provide a means of providing anonymous consensus. Specifically, verifiers, usually anonymous third parties are able to review operations, in this case transitions in the LTS, and if the transition is verified, permitting the transition to be posted to the distributed ledger.
  • Note that it is not necessary for a verifier to be anonymous. Generally, anonymity is a feature of open permissionless systems where anyone can be a verifier. However, in some embodiments, such as permissioned systems where participation is restricted to a known set of participants there may not be a need for anonymity.
  • One reason to use permissioned systems is to avoid the use of cryptocurrency. In the case of permissionless systems, verifiers participate in verifying DLT transactions because they receive remuneration in the form of a cryptocurrency. Where a business model has substantial reliance on cryptocurrency economics, permissionless systems where participants are maximized is useful. Where a business model does not have substantial reliance on cryptocurrency economics, permissioned systems may make more sense.
  • But again, regardless if a verifier is anonymous or not, this begs the question of how verifiers can verify transitions in a way that can be trusted.
  • The proposed solution is to specify transitions with a language that supports formal methods, i.e. mathematical and logical operations. Insofar as mathematical and logical techniques are trusted, so too is a verification based on mathematical and logical techniques. Furthermore, mathematical and logical techniques lend themselves to automation as well. In general, we have the benefit of formal methods to program assertions and validity.
  • One example of a language supporting formal methods is a process calculus. The Asynchronous Pi (aPi) Calculus is an example of process calculi. Process calculi can be used to encode an LTS and the transitions in an LTS. Process calculi describe communications channels and ports and provide the means of expressing messages. Process calculi provide congruence rules to show mathematical equivalence and reduction rules to transform expressions. Accordingly, process calculi support mathematical and logical operations (such as Hennessy-Milner logics) for mathematical proofs for verification, i.e. mathematically and logically showing that the software performs semantically as expected. The aPi variant lends itself to distributed systems.
  • As a side note, Hennessy-Milner logics are not the only kinds of logic that may be applied. Preference logics and modal logics may be applied as well. Application of preference logic is described in more detail in the paper, “Anonymous Distributed Consensus Regarding Contract Sanctioned Transition Sequences with Semantic Attachments” included in the provisional patents set forth in the Related Applications section and thereby incorporated by reference herein.
  • Validation of a protocol and/or workflow of a protocol need not be limited to formal language expressions. When a representation of a protocol/workflow is in a structure that lends itself to mathematical and logical analysis, that mathematical and logical apparatus may be brought to bear in the interests of verifying and translating the protocol/workflow. For example, LTS structures support bisimulation and coinduction, techniques to study the bigraph of a workflow LTS, as part of verification.
  • As a side note, transitions from in the LTS are coded in aPi or another process calculus. In the name of radical transparency, the LTS may support introspection which is the attribute of showing (also known as reflecting) information about the object being introspected. In some embodiments, the logic to verify a transition or to perform any verification may be shown to a user on demand, thereby providing transparency not on whether a transition was validated, but the logic applied.
  • 2. Symmetric Asset Exchange
  • In the case of legal contracts, where one party exchanges an asset (such as a good or service) represented by an artifact for another artifact from a second party, confirming performance or receipt of consideration is key to determining substantive breach. With the use of DLT, it is preferable for a party to ensure performance or consideration of the other party prior to the first party's performance or consideration. In this way, the risk of certain classes of damages, such as reliance damages is virtually eliminated.
  • With the LTS+DLT+aPi configuration, protocols can be decomposed into binary exchanges where in a binary exchange, either both parties receive the other's artifacts or both don't. There is no attempted exchange where one party receive an artifact and the other doesn't. Since the results of the exchange are the same for both parties, this exchange is symmetric. Since the exchange is of artifacts representing assets, this (sub)protocol is called symmetric asset exchange (SAX).
  • A specific decomposition can be of an input component, potentially representing a first process, and an output component, potentially representing a second process. These two components are atomic components that may be composed into larger protocols. In this embodiment, the input component is configured to logically determine either that a message has been received at a first channel and thereafter binds the message to a variable of the first channel, or that the message has been received at a second channel and thereafter binds the message to a variable of the second channel. In turn, the output component is configured to receive a message comprised of two components, and upon receipt of the message, to send the first component on a first channel and to send the second component on a second channel A composition of the two results in the first process receiving an artifact from the second process and the second process receiving an artifact from the first process, or both processes not receiving an artifact. In this configuration, the input and output components satisfy symmetric assets exchange.
  • In some embodiments, the components may be configured as not to share any free names or free variables except for a name of a channel to signify completion of a process (known as “done”). In some embodiment, the done process may be used to synchronize the operation of the distributed components, similar in operation to a critical section or a mutual exclusion (mutex).
  • One of the advantages of making use of the asynchronous Pi Calculus (aPi), is that it lends itself to composability. Therefore, one can specify a protocol in terms of subprotocols and the subprotocols may be represented using aPi. The specific internals of the input and output components is described in further detail in the paper, “Symmetric Asset Exchange: A Universal Construction in Contract Patterns for Payments and Logistics” included in the provisional patents set forth in the Related Applications section and thereby incorporated by reference herein.
  • It is to be noted that the more processing a DApp performs on a DLT, especially for permissionless applications, the more expensive the DApp is to operate. In general, cryptocurrency processing costs are proportional to the amount of processing performed. For this reason, symmetric exchange and validations may be performed in a validator application that is not hosted on a DLT runtime thereby offloading processing off the DLT. A validator application calls the DLT typically only to post persistence, usually via a DApp. In this way, a non-DLT app, here the validator application divides work with a DApp in order to minimize cryptocurrency costs and DLT runtime load.
  • 3. Category Theory View
  • DLTs are not necessarily configured to store the state of a transition. Rather DLT's store Merkle tree hashes representing the signature of a transition. Since the hashes are based on the cryptographic keys of the parties performing the transitions as well as past hashes, the DLT is compact while enabling parties to determine whether a transition is legitimate. For the actual state of the transition, a party might access a traditional centralized database.
  • Leveraging centralized databases may lower the friction of making use of DLT. Since in this scenario DLT is augmenting existing infrastructure rather than replacing it, risks of porting the existing infrastructure are minimized.
  • However, it may be desirable to capture the schema of a traditional central database and determine whether a transformation preserves semantics. In some embodiments, categorical databases are used as a sort of neutral lingua franca to identify semantic preserving transformation. Categorical databases are databases that make use of mathematical category theory which enables a user to identify equivalent and congruent database schemas. In short, a smart contract may be characterized as a semantic preserving transformation of a categorical database
  • Internals of how to use category theory in this context is described in further detail in the paper, “Anonymous Distributed Consensus Regarding Contract Sanctioned Transition Sequences with Semantic Attachments” included in the provisional patents set forth in the Related Applications section and thereby incorporated by reference herein.
  • Accordingly, we have access to the additional apparatus made available from category theory to bring to bear. In this way, the LTS+DLT+aPi configuration allows users to apply computational, categorical and logical techniques at will.
  • Context of Protocol Verification via Anonymous Distributed Consensus
  • We are now ready to describe the context for protocol verification of anonymous distributed consensus. FIG. 1 is a context diagram 100 for protocol verification via anonymous distributed consensus. A protocol 102 is a business or enterprise process comprised of a set of actors 104 and resources 106 that interact. The actors may be humans or may be automated processes themselves. Resources represent some sort of asset that may be exchanged (goods) or some sort of asset that is transformed in performance of a contract (services). The assets may be represented electronically with some sort of token known as an artifact 108. The logic behind a protocol is known as a “workflow” or a “workflow of the protocol.”
  • The workflow may be encoded in a verification application 110 comprised of an LTS 112 where transitions are associated with verification rules 114 in a formal language such as aPi.
  • Persistence of successful transitions are on a distributed ledger 116 via a decentralized application (DApp) 118 performs and stores verification logic. The verification application 110 may be comprised of atomic symmetric asset exchange components 120 communicatively coupled to the DLT corresponding to transitions.
  • The development time operation is described in further detail with respect to FIGS. 3 and 4 . The run time operation is described in further detail with respect to FIGS. 5 and 6 .
  • Exemplary Environment for Protocol Verification via Anonymous Distributed Consensus
  • Protocol verification via anonymous distributed consensus is generally performed on computing devices comprised of hardware, software and communications infrastructure. FIG. 2 is an exemplary environment diagram 200 describing the hardware, software and communications environment for protocol verification via anonymous distributed consensus.
  • Client-side software, such as web browsers, client cryptographic wallets and DApp clients are generally hosted on a client computing device 202. Exemplary client computing devices 202 include without limitation personal computers, laptops, embedded devices, tablet computers, and smart phones. Since these client computing devices 202 are to access decentralized applications, these client computing devices 202 are networked.
  • The client computing device 202 has a processor 204 and a memory 206. The processor may be a central processing unit, an application processing unit, and/or a dedicated controller such as a microcontroller.
  • The client computing device 202 further includes an input/output (I/O) interface 208, and/or a network interface 210. The I/O interface 208 may be any controller card, such as a universal asynchronous receiver/transmitter (UART) used in conjunction with a standard I/O interface protocol such as RS-232 and/or Universal Serial Bus (USB). The network interface 210, may potentially work in concert with the I/O interface 208 and may be a network interface card supporting Ethernet and/or Wi-Fi and/or any number of other physical and/or datalink protocols. On many client computing devices 202, such as with smart phones, the client computing device 202 is able to participate in both cellular and unlicensed wireless communications (e.g. Wi-Fi). Accordingly, in a smart phone/mobile embodiment, the network interface 210 may work in concert with one or more radios for cellular or unlicensed communications.
  • Note that in general, memory 206 is any computer-readable media which may store several software components including an operating system 218 and software components and client-side software 214. In general, a software component is a set of computer-executable instructions stored together as a discrete whole. Examples of software components include binary executables such as static libraries, dynamically linked libraries, and executable programs. Other examples of software components include interpreted executables that are executed on a run time such as servlets, applets, p-Code binaries, and Java binaries. Software components may run in kernel mode and/or user mode.
  • Computer-readable media includes, at least, two types of computer-readable media, namely computer storage media and communications media. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device. In contrast, communication media may embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transmission mechanisms. As defined herein, computer storage media does not include communication media.
  • Server-side applications such as verification applications 110 and DApps 118 are generally hosted on a physical server, or on a virtual machine. Where the server-side applications 110, 118 are hosted on a physical server, the server 216 is any computing device that may participate in a network. The network may be, without limitation, a local area network (“LAN”), a virtual private network (“VPN”), a cellular network, or the Internet. The server 216 may be a computing device with sufficient I/O computing capacity to serve multiple clients. Specifically, the physical server 216 includes a processor 218, a memory 220, an input/output interface 222 and a network interface 224. In the memory 220 will be an operating system 226 and server-side applications 228.
  • Alternatively, the server-side applications 228 may be hosted on a virtual machine via a cloud service 230. Specifically, the cloud service 230 may represent a plurality of disaggregated servers which provide virtual application server 232 functionality and virtual storage/database 234 functionality. The disaggregated servers are physical computer servers, which may have a processor, a memory, an I/O interface and/or a network interface. The features and variations of the processor, the memory, the I/O interface and the network interface are substantially similar to those described for the physical server 216. There may be differences where the disaggregated servers are optimized for throughput and/or for disaggregation. In addition to hosting the server-side applications 228, machine learning/cognitive network software (not shown) and other server-side software (not shown) may be hosted on virtual application servers 232.
  • The cloud service 230 may be made accessible via an integrated cloud infrastructure 236. Cloud infrastructure 236 not only provides access to cloud services 230 but also to billing services and other monetization services. Cloud infrastructure 236 may provide additional service abstractions such as Platform as a Service (“PAAS”), Infrastructure as a Service (“IAAS”), and Software as a Service (“SAAS”).
  • Exemplary Development Environment for Protocol Verification via Anonymous Distributed Consensus
  • LTS+DLT+aPi is configured to perform protocol verification via anonymous distributed consensus. Key applications are divided into development time applications and run time applications. Development time applications are described in the context of FIG. 3 , a block diagram 300 of an exemplary development environment for protocol verification via anonymous distributed consensus and FIG. 4 , a flow chart of the operation of the same. Run time applications are described in more detail with respect to FIGS. 5 and 6 .
  • In FIG. 3 , operation begins with a workflow design tool 302. The workflow design tool may receive specifications of actors and resources interacting. The specification may be of actors, states, transitions between the states, and of artifacts representing resources as assets to be exchanged. While the output of the workflow design tool 302 is a specification of a protocol of a business or enterprise process, the workflow design tool 302 may be a graphical tool which receives as input the drawing of a network (swimlane) diagram or in the alternative a drawing of a state machine.
  • In the case of the network diagram, individual swimlanes correspond to actors. Arrows between swimlanes indicate interactions between actors and may be associated with artifacts or functions performed during the interactions. Note that in the network diagram, flow does not necessarily represent state transitions since flow is between actors rather than states.
  • In the cases of a state transition diagram, nodes may represent states, arrows between states may represent transitions between states. Transitions again here may be associated with artifacts or functions performed during the interactions.
  • Graphical representations may be converted by the workflow design tool 302 into textual form, for example in BPEL or XLANG. Alternatively, BPEL or XLANG may be hand edited with a text editor.
  • Turning to FIG. 4 , processing starts by a when a receiver module 304 receives a protocol based on a drawing of a protocol 402, or from a textual protocol specification, edited with workflow design tool 302. In particular, turning back to FIG. 3 , the receiver module 304 parses the input specification, looks for syntax and other errors, and stores the parsed input specification into an intermediate representation format suitable for rules checking. The representation is stored by a representation engine 308 in a representation data store 310. Rules are predetermined and are managed by the rules engine 312 and stored in rules data store 314.
  • In some embodiments, the intermediate representation format of the protocol is a virtual version of an LTS with associated transition rules stored in the rules data store 314 and accessible by the rules engine 312. Rules may be reviewed from the workflow design tool 302 by selected transitions which reflect back the rules.
  • Both static and dynamic tests may be performed. Static tests such as completeness checks, logic checks and bisimulations may be performed by a logic checker/validator 316.
  • For dynamic testing, a validator application 320 a simulated application comprising a validator application 318 and a DApp 320 may be generated by an application generator 322. The generated application may be configured to be communicatively coupled with a test or even production distributed ledger 324. For input triggers, the application generator may also generated browser applications 326 and/or oracles 328 (which among other things provide representations of external state to distributed ledgers).
  • Once the application has been generated, test inputs may be run to validate the intermediate representation as part of dynamic testing.
  • Turning back to FIG. 4 , in block 406 validations are performed by the logic checker/validator. Checks may be based on rules specific to an application, or may be rules that are to be true of any application. Checks may be of the LTS itself, such as via bisimulation and/or coinduction, or may be of the transition rules themselves e.g. aPi checks.
  • Note that because the generated application has an intermediate form, testing need not be specific to the LTS and the rules in aPi. For example, categorical database representations may be generated to perform category theory based checks as well.
  • In block 408, the application generator 322 generates the application components and deploys as described above. The versioning, building, and deploying cycle may be scripted and orchestrated via integration with DevOps software.
  • In this way mathematical and logical operations are accessible at all steps of the development, testing, build and deployment cycles.
  • Exemplary Run Time Environment and Operation for Protocol Verification via Anonymous Distributed Consensus
  • FIG. 5 is a block diagram 500 of an exemplary run time environment for protocol verification via anonymous distributed consensus and
  • FIG. 6 is a flow chart 600 of the operation of the same.
  • As described above, a validator application 502 has been generated by an application generator 322. Unlike the validator application 318 under test, validator application 502 is deployed into production.
  • The validator application 502 is configured to receive input triggers 504 which are software messages (either via a push communications protocol such as message passing or by a pull communications protocol such software notifications/events).
  • The validator application 502 includes a representation generally in the form of an LTS with rules 510 associated with transitions 512 in the LTS. In some embodiments, the rules 510 are encoded via aPi. As with the test version in the development environment, the generated application also includes clients such as a browser application 514 running on a web browser 516 optionally configured with a cryptocurrency wallet, oracles 518, and a DApp 520 to perform persistence on a distributed ledger 522.
  • Turning to FIG. 6 , in block 602, the validator application 502 receives an input trigger 504 from a browser application 514 or an oracle 518. In block 604, the validator application 502 then identifies the relevant transition 512 in the protocol, and retrieves the rule 510 associated with the transition 512.
  • In block 606, the validator application 502 then performs the retrieved rule 510. In block 608, if the rule 510 is satisfied, i.e. the checks specified by the rule 510 are verified, the LTS is updated and the validator application 502 calls the DApp 520 to post the validated transaction to the distributed ledger 522.
  • Conclusion
  • Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims (20)

What is claimed is:
1. A method to perform workflow transition validations, comprising:
receiving, at a server, a specification of a workflow, the specification comprising of actors, states, transitions between the states, and artifacts representing resources as assets to be exchanged in the transitions;
generating from a received workflow specification a directed graph (digraph) of the workflow comprised of a plurality of nodes representing the states and directed edges representing the transitions between the states, wherein each of the transitions is associated with at least one rule that includes a symmetric exchanging of the assets to verify the validity of the transitions between the states;
deploying, by the server, a validator application and a distributed ledger technology (DLT)-based application (decentralized application), wherein the validator application identifies the transitions and retrieves associated rules to offload processing off the decentralized application during a DLT runtime load on the workflow transition validations;
receiving, by the validator application, an input trigger that corresponds to a state transition in the digraph;
performing, by the validator application, a retrieved rule that is associated with the state transition in the digraph;
updating, by the validator application, the digraph based at least upon a verification of the state transition in the digraph, using at least the retrieved rule;
calling, by the validator application, the decentralized application to store an updated state of the digraph on a distributed ledger; and
storing, by the decentralized application, the updated state of the digraph on the distributed ledger.
2. The method of claim 1, wherein the digraph comprises nodes representing the states and directed edges representing valid transitions between the states.
3. The method of claim 1, wherein the transition in the digraph is encoded using expressions supporting formal methods, and the retrieved rule is encoded using a programmable language supporting formal method.
4. The method of claim 3, wherein the programmable language supporting formal method includes an asynchronous pi calculus.
5. The method of claim 3, wherein the digraph supports a bisimulation, a coinduction, or both and the retrieved rule includes an application of the bisimulation, the coinduction, or both.
6. The method of claim 3, wherein the retrieved rule includes an application of a Hennessy-Milner logic.
7. The method of claim 1, wherein the digraph includes a category theoretical representation of the received specification of the workflow.
8. A method to perform workflow transition validations, comprising:
receiving, at a server, a specification of a workflow, the specification comprising of actors, transitions, and artifacts that represent resources as assets to be exchanged in the transitions;
generating from a received workflow specification a labeled transition system (LTS), wherein each of the transitions in the LTS is associated with at least one rule that includes a symmetric exchanging of the assets to verify a validity of the transitions, and wherein a generated LTS is composed of a set of predetermined components communicatively coupled to a distributed ledger, the predetermined components representing processes;
deploying, by the server, a validator application and a distributed ledger technology (DLT)-based application (decentralized application), wherein the validator application identifies the transitions and retrieves associated rules to offload processing off the decentralized application during a DLT runtime load on the workflow transition validations;
receiving, by the validator application, an input trigger that corresponds to a state transition in a generated LTS, performing, by the validator application, a retrieved rule that is associated with the state transition in a directed graph (digraph);
updating, by the validator application, the digraph based at least upon a verification of the state transition in the LTS, using at least the retrieved rule; and
storing, by the decentralized application, an updated state of the digraph on the distributed ledger.
9. The method of claim 8, wherein the predetermined components are atomic components.
10. The method of claim 8, wherein the transition in the digraph is encoded using expressions supporting formal methods, and the retrieved rule is encoded using a programmable language supporting formal method.
11. The method of claim 10, wherein the programmable language supporting formal method includes an asynchronous pi calculus.
12. The method of claim 10, wherein the digraph supports a bisimulation, a coinduction, or both and the retrieved rule includes an application of the bisimulation, the coinduction, or both.
13. The method of claim 10, wherein the retrieved rule includes an application of a Hennessy-Milner logic.
14. The method of claim 8 further comprising: calling, by the validator application, the decentralized application to store the updated digraph on the distributed ledger.
15. The method of claim 8, wherein the predetermined components implement symmetrical exchange of artifacts.
16. The method of claim 8, wherein the predetermined components are comprised of either symmetric asset exchange input atomic components, symmetric asset exchange output atomic components, or both.
17. A system to automate a workflow, the system comprising:
a processor;
a memory coupled to the processor, the memory includes a plurality of computer-executable components that are executable with the processor to perform a plurality of actions, the plurality of actions comprising:
receiving a specification of a workflow, the specification comprising transitions and artifacts representing resources as assets to be exchanged in the transitions;
generating from a received specification a directed graph (digraph) of the workflow, wherein each of the transitions in the digraph is associated with at least one rule that includes a symmetric exchanging of the assets to verify a validity of the transition;
deploying a validator application and a distributed ledger technology (DLT)-based application (decentralized application), wherein the validator identifies the transitions and retrieves associated rules to offload processing off the decentralized application during a DLT runtime load on workflow transition validations;
receiving an input trigger that corresponds to a state transition in the digraph;
performing a retrieved rule that is associated with the state transition in the digraph;
updating a state of the digraph, using at least the retrieved rule;
calling via the validator application the decentralized application to store an updated state of the digraph on a distributed ledger; and
storing the updated state of the digraph on the distributed ledger.
18. The method of claim 17, wherein the transition in the digraph is encoded using expressions supporting formal methods, and the retrieved rule is encoded using a programmable language supporting formal method.
19. The method of claim 18, wherein the programmable language supporting formal method includes an asynchronous pi calculus.
20. The method of claim 18, wherein the digraph supports a bisimulation, a coinduction, or both and the retrieved rule includes an application of the bisimulation, the coinduction, or both.
US17/883,138 2018-07-31 2022-08-08 Anonymous distributed consensus regarding the verification of protocols Pending US20220383222A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/883,138 US20220383222A1 (en) 2018-07-31 2022-08-08 Anonymous distributed consensus regarding the verification of protocols

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201862712792P 2018-07-31 2018-07-31
US201862712768P 2018-07-31 2018-07-31
US201962879991P 2019-07-29 2019-07-29
US16/526,872 US11410162B2 (en) 2018-07-31 2019-07-30 Anonymous distributed consensus regarding the verification of protocols
US17/883,138 US20220383222A1 (en) 2018-07-31 2022-08-08 Anonymous distributed consensus regarding the verification of protocols

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US16/526,872 Continuation US11410162B2 (en) 2018-07-31 2019-07-30 Anonymous distributed consensus regarding the verification of protocols

Publications (1)

Publication Number Publication Date
US20220383222A1 true US20220383222A1 (en) 2022-12-01

Family

ID=69228107

Family Applications (2)

Application Number Title Priority Date Filing Date
US16/526,872 Active 2039-12-29 US11410162B2 (en) 2018-07-31 2019-07-30 Anonymous distributed consensus regarding the verification of protocols
US17/883,138 Pending US20220383222A1 (en) 2018-07-31 2022-08-08 Anonymous distributed consensus regarding the verification of protocols

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US16/526,872 Active 2039-12-29 US11410162B2 (en) 2018-07-31 2019-07-30 Anonymous distributed consensus regarding the verification of protocols

Country Status (5)

Country Link
US (2) US11410162B2 (en)
EP (1) EP3830773A4 (en)
KR (1) KR20210065933A (en)
CA (1) CA3107934A1 (en)
WO (1) WO2020028585A1 (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11410162B2 (en) 2018-07-31 2022-08-09 Deixis, PBC Anonymous distributed consensus regarding the verification of protocols
US20210281510A1 (en) * 2020-03-05 2021-09-09 Deixis, PBC High-resolution contract-based wireless network virtualization

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070288250A1 (en) * 2006-06-09 2007-12-13 Jens Lemcke Method and system for generating collaborative processes
US20130110576A1 (en) * 2011-10-28 2013-05-02 Infosys Limited System and method for checking the conformance of the behavior of a process
US8965827B2 (en) * 2011-03-30 2015-02-24 Computer Sciences Corporation Rules execution platform system and method
US20150379510A1 (en) * 2012-07-10 2015-12-31 Stanley Benjamin Smith Method and system to use a block chain infrastructure and Smart Contracts to monetize data transactions involving changes to data included into a data supply chain.
US20170352031A1 (en) * 2016-06-06 2017-12-07 Thomson Reuters Global Resources Unlimited Company Systems and methods for providing a personal distributed ledger
US20180218176A1 (en) * 2017-01-30 2018-08-02 SALT Lending Holdings, Inc. System and method of creating an asset based automated secure agreement
US20200389301A1 (en) * 2019-06-07 2020-12-10 Volum Holdings, OÜ Supply chain management system

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040055514A (en) 2002-12-21 2004-06-26 한국전자통신연구원 Location-based knowledge management method for intelligent moving object trajectory management
US20140229345A1 (en) 2013-02-14 2014-08-14 Microsoft Corporation Application process framework for integrated and extensible accounting system
US20170011460A1 (en) 2015-07-09 2017-01-12 Ouisa, LLC Systems and methods for trading, clearing and settling securities transactions using blockchain technology
EP3423999A1 (en) 2016-03-03 2019-01-09 NEC Laboratories Europe GmbH Method for managing data in a network of nodes
US11410162B2 (en) 2018-07-31 2022-08-09 Deixis, PBC Anonymous distributed consensus regarding the verification of protocols

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070288250A1 (en) * 2006-06-09 2007-12-13 Jens Lemcke Method and system for generating collaborative processes
US8965827B2 (en) * 2011-03-30 2015-02-24 Computer Sciences Corporation Rules execution platform system and method
US20130110576A1 (en) * 2011-10-28 2013-05-02 Infosys Limited System and method for checking the conformance of the behavior of a process
US20150379510A1 (en) * 2012-07-10 2015-12-31 Stanley Benjamin Smith Method and system to use a block chain infrastructure and Smart Contracts to monetize data transactions involving changes to data included into a data supply chain.
US20170352031A1 (en) * 2016-06-06 2017-12-07 Thomson Reuters Global Resources Unlimited Company Systems and methods for providing a personal distributed ledger
US20180218176A1 (en) * 2017-01-30 2018-08-02 SALT Lending Holdings, Inc. System and method of creating an asset based automated secure agreement
US20200389301A1 (en) * 2019-06-07 2020-12-10 Volum Holdings, OÜ Supply chain management system

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
Cai et al., Decentralized Applications: The Blockchain-Empowered Software System, September 17, 2018, IEEE Access (Year: 2018) *
Hennessy and Milner, Algebraic laws for nondeterminism and concurrency, 1985-01-01, Journal of the ACM, pp 137-161 (Year: 1985) *
Jung et al., A Study on Implementation of Model Checking Tool for Verifying LTS Specifications, 1998-01-01, IEEE Proceedings Twelfth International Conference on Information Networking (ICOIN-12) (Page(s): 539-543) (Year: 1998) *
Li et al., Saclable and Privacy-preserving Design of On/Off-chain Smart Contracts, April 1, 2019, IEEE 35th International Conference on Data Engineering Workshops (ICDEW) pages 7-12 (Year: 2019) *
Singer et al., An Ontological Analysis of Business Process Modeling and Execution, April 18, 2019, https://arxiv.org/pdf/1905.00499.pdf (Year: 2019) *
Suvorov et al., Smart Contract Design Meets State Machine Synthesis: Case Studies, June 7, 2019, https://arxiv.org/pdf/1906.02906v1.pdf (Year: 2019) *
Vitalik Buterin, Ethereum White Paper: A Next Generation Smart Contract & Decentralized Application Platform, 2013, https://ethereum.org/en/whitepaper/ (Year: 2013) *

Also Published As

Publication number Publication date
US11410162B2 (en) 2022-08-09
EP3830773A4 (en) 2022-04-20
CA3107934A1 (en) 2020-02-06
KR20210065933A (en) 2021-06-04
US20200042991A1 (en) 2020-02-06
WO2020028585A1 (en) 2020-02-06
EP3830773A1 (en) 2021-06-09

Similar Documents

Publication Publication Date Title
US20240028587A1 (en) System and method for a hybrid contract execution environment
Marchesi et al. An agile software engineering method to design blockchain applications
US20200252205A1 (en) Systems, methods, and apparatuses for implementing a multi tenant blockchain platform for managing einstein platform decisions using distributed ledger technology (dlt)
Marchesi et al. ABCDE—Agile block chain DApp engineering
US20200151017A1 (en) Event-driven blockchain workflow processing
US20220383222A1 (en) Anonymous distributed consensus regarding the verification of protocols
Jurgelaitis et al. Modelling principles for blockchain-based implementation of business or scientific processes
Holbrook Architecting enterprise blockchain solutions
Gaur et al. Blockchain with hyperledger fabric: Build decentralized applications using hyperledger fabric 2
Skotnica et al. Process Digitalization using Blockchain: EU Parliament Elections Case Study.
Morris et al. Developing a blockchain business network with hyperledger composer using the ibm blockchain platform starter plan
US11818206B2 (en) Visibility of digital assets at channel level
US11886810B2 (en) System and method for electronic document interaction with external resources
AU2022245375A1 (en) Reducing transaction aborts in execute-order-validate blockchain models
CN115705256A (en) Request facilitation for agreement on service transactions
US20140025439A1 (en) Regression free business process management
Liu FSM Modeling of Off-Blockchain Computation
Rasti et al. A Coin Marketplace Implementation on Blockchain Using the Hyperledger Platform
Stipsits Scalable Integration of Ethereum in a Microservice based Application through Layer 2 Rollups
Conceição Validation of Smart Contracts Through Automated Tooling
US20230097203A1 (en) System and method for generating blockchain token support from a set of declarations
Khan et al. Developing Microservices Architecture on Microsoft Azure with Open Source Technologies
Aas et al. Using Self-Sovereign Identity and Verifiable Data to improve public services
Chuva Governança Extensivel
Cai et al. In-Depth Interpretation of Ethereum

Legal Events

Date Code Title Description
AS Assignment

Owner name: DEIXIS, PBC, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BROWN, ALLEN L., JR.;EZELL, DAVID B.;SANTOS, PATRICK J. D.;SIGNING DATES FROM 20190729 TO 20190730;REEL/FRAME:060745/0906

STPP Information on status: patent application and granting procedure in general

Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION

STPP Information on status: patent application and granting procedure in general

Free format text: NON FINAL ACTION MAILED