CN110192212B

CN110192212B - Digital asset platform

Info

Publication number: CN110192212B
Application number: CN201680087670.9A
Authority: CN
Inventors: 亚历山大·伯诺尔; 陶马斯·布吕默; 绍尔·克弗尔; 詹姆士·利齐奥斯; 西蒙·迈耶
Original assignee: Digital Asset Switzerland GmbH
Current assignee: Digital Asset Switzerland GmbH
Priority date: 2016-07-14
Filing date: 2016-07-14
Publication date: 2024-06-04
Anticipated expiration: 2036-07-14
Also published as: WO2018013124A1; EP3472779A1; CN110192212A; EP3472779A4

Abstract

A system and method for performing a multi-sided transaction bookkeeping workflow between a plurality of participants is provided, comprising: receiving previously agreed upon and normalized rules; receiving an authorization decision; based on the authorization decision and rules, performing protocol evolution; notifying participants of the protocol of the evolved protocol; and storing the evolved protocol and notification credential in a shared append-only ledger.

Description

Digital asset platform

Technical Field

The present disclosure relates to digital asset platforms and methods of use.

Background

Existing closed central management ledgers for settlement of assets, liabilities and transactions are considered opaque and error-prone. This makes supervision cumbersome, requires many repeated processes and ledgers, and is prone to fraud. The first and most currently applied alternative to existing ledger architectures is represented by a distributed digital ledger known as bitcoin, which uses blockchain data structures. One basic principle of bitcoin operation is: the system is configured as a peer-to-peer transaction mechanism utilizing public-private key cryptography, without a central intervening repository or central repository, and allows all participants in the network to hold and verify the integrity of a complete copy of the ledger in real time. The bitcoin blockchain is designed to create a naturally unreliable asset, bitcoin, that can be exchanged with anonymous parties worldwide.

The platforms currently being built on top of the analog coin or analog blockchain systems that support digital assets are not typically structured to provide comprehensive protection for financial institutions that may be required by law for many existing transaction businesses of the financial institutions. These platforms may not typically take into account regulatory regimes for financial institutions and financial transactions. Thus, institutional investors are hesitant to enter the digital asset market and avoid using distributed ledgers for their existing business.

Disclosure of Invention

Exemplary embodiments disclosed herein provide a distributed system for executing a transaction workflow between a plurality of participants. A method of manipulating a data structure of distributed multi-sided bookkeeping comprising: receiving previously agreed upon and normalized rules; receiving an authorization decision; based on the authorization decision and rules, performing protocol evolution; notifying participants of the protocol of the evolved protocol; and storing the evolved protocol and notification credential in a shared append-only ledger.

The method may include: detecting mutually contradictory protocols; and excluding contradictory agreements based on the shared additional ledger-only credentials. The method may include: the participant is provided with partial insight into the agreement by a partial pool of agreements sufficient for the participant's own authorization and records, wherein the partial pool of agreements of the participant remains non-contradictory to the records of the other participants and verifiable in the range visible to the participant.

The method may include: automatically auditing the evolution of the authorization and protocol. This approach may be employed in situations where only the append ledger includes blockchains.

The method may include executing a transaction workflow between a plurality of participants, the executing including: a Command Query Role Separation (CQRS) pattern (pattern) with multiple modules is used to interact with an append only ledger, wherein the modules include: an ledger writer configured to record, through a first write module of the CQRS, a credential indicative of the transaction dataset to the ledger; and a ledger reader configured to detect credentials on the ledger with a matching notification token and to read such matching credentials through the first read module of the CQRS.

This approach may be employed in cases where the credential indicating the protocol includes a timestamp indicating the time of the record on the ledger. This approach may be employed in the case where the credentials indicating the protocol include a Merkle (Merkle) hash of the transaction data set. The method may be employed when the hashed transaction data set includes a proof of the corresponding multi-sided authorization commercial intention message and a proof of the current protocol used to convert the commercial intention message into the transaction data set.

This approach may be employed in the case where each of the plurality of distributed nodes includes a different module of CQRS. This approach may also be employed in cases where the reduced subset of nodes includes the first write module of the CQRS.

This method may be employed in the case of detecting a matching notification token by the second read module of the CQRS. The method may include publishing the identified bulletin on a ledger. The method may further include calculating a unique shared secret for each participant and log writer pair. This approach may be employed in situations where a matching notification token may be identified by the party while keeping the other parties secret.

This approach may be employed in situations where the transaction dataset stores the current protocol as an Abstract Syntax Tree (AST). The method may also be employed in the case of updating a transaction dataset with a merck hash to form a Merck Abstract Syntax Tree (MAST).

The method may further comprise: an audit is performed to prove that the evolution of the protocol from the first transaction data set to the second transaction data set was properly authorized and properly performed, and to prove that all participants were notified of their related changes. The method may also be employed in situations where the audit has not demonstrated that participants are notified of changes that are not relevant to them.

An exemplary embodiment system for distributed multi-sided bookkeeping, comprising: a business intent unit configured to receive previously agreed upon and normalized rules; a selection unit configured to receive an authorization decision from the commercial intention unit; a processing unit configured to perform protocol evolution based on the authorization decision and the rules; a notification unit configured to notify the participant of the evolved protocol; and append only the ledger configured to: and storing the evolved protocol and the notification credential.

The system may include: an auditing unit configured to detect mutually contradictory protocols. The system may also be employed in situations where conflicting protocols detected are excluded based on credentials from the shared append-only ledger. The system may also be employed in cases where the auditing unit supports automatic auditing of the evolution of the authorizations and protocols.

The system may be employed in the case where only the append ledger supports the following functions: the participant is provided with partial insight into the agreement by a partial pool of agreements sufficient for the participant's own authorization and records, wherein the partial pool of agreements of the participant remains non-contradictory to the records of the other participants and verifiable in the range visible to the participant.

The system may include a Command Query Responsibilities Separation (CQRS) mode having a plurality of modules supporting interaction with append only ledgers; an ledger writer configured to record, through a first write module of the CQRS, a credential indicative of the transaction dataset to the ledger; and a ledger reader configured to detect credentials on the ledger with a matching notification token and to read such matching credentials through the first read module of the CQRS.

The system may be employed in situations where only the append ledger includes a blockchain. The system may be employed in the case where the credentials indicating the protocol include a timestamp indicating the time of the record on the ledger.

The system may be employed in the case where the credentials indicating the protocol include a merck hash of the transaction data set. The system may also be employed in situations where the hashed transaction data sets include a proof of the corresponding multi-sided authorization commercial intention messages and a proof of the current protocol used to convert the commercial intention messages into the transaction data sets.

The system may be employed in the case where each of the plurality of distributed nodes includes a different module of CQRS. The system may also be employed in the case where the reduced subset of nodes includes the first write module of the CQRS.

The system may be employed in situations where each node is configured to maintain an advertisement of the received identity on the ledger. The system may be employed in cases where each node is configured to compute a unique shared secret corresponding to the node's participants and any log writers. The system may be employed in situations where a matching notification token may be identified by a party while keeping the other parties secret. The system may be employed in the case of detecting a matching notification token by the second read module of the CQRS.

The system may be employed in situations where the transaction data set stores the current protocol as an Abstract Syntax Tree (AST). The system may also be employed in the case of updating a transaction dataset with a merck hash to form a Merck Abstract Syntax Tree (MAST).

The system may include an auditor configured to prove that the evolution of the agreement from the first transaction data set to the second transaction data set was properly authorized and properly performed, and to prove that all participants were notified of changes associated with them. The system may be employed in situations where the auditor has not proven to notify the participants of changes that are not relevant to them.

An exemplary implementation program sequence storage device tangibly embodying computer-executable program steps for manipulating data structures in distributed multi-edge bookkeeping, comprising program steps for: receiving previously agreed upon and normalized rules; receiving an authorization decision; based on the authorization decision and rules, performing protocol evolution; notifying participants of the protocol of the evolved protocol; and storing the evolved protocol and notification credential in a shared append-only ledger.

The apparatus may comprise steps for: detecting mutually contradictory protocols; and excluding contradictory agreements based on the shared additional ledger-only credentials. The apparatus may comprise steps for: the participant is provided with partial insight into the agreement by a partial pool of agreements sufficient for the participant's own authorization and records, wherein the partial pool of agreements of the participant remains non-contradictory to the records of the other participants and verifiable in the range visible to the participant.

The device may include steps for automatically auditing the authorization and evolution of the protocol. The apparatus may be employed in the case where only the append ledger includes a blockchain.

The apparatus may include steps for executing a transaction workflow between a plurality of participants, the executing comprising: a Command Query Role Separation (CQRS) mode having a plurality of modules is used to interact with an append only ledger, wherein the modules include: an ledger writer configured to record, through a first write module of the CQRS, a credential indicative of the transaction dataset to the ledger; and a ledger reader configured to detect credentials on the ledger with a matching notification token and to read such matching credentials through the first read module of the CQRS.

The device may be employed in the case where the credentials indicating the protocol include a timestamp indicating the time of the record on the ledger. The device may be employed in the case where the credentials indicating the protocol include a merck hash of the transaction data set. The apparatus may also be employed in situations where the hashed transaction data sets include a proof of the corresponding multi-sided authorization commercial intention messages and a proof of the current protocol used to convert the commercial intention messages into the transaction data sets.

The apparatus may be employed in the case where each of the plurality of distributed nodes includes a different module of CQRS. The apparatus may also be employed in the case where the reduced subset of nodes includes the first write module of the CQRS.

The apparatus may be employed in the case of detecting a matched notification token through the second read module of the CQRS. The apparatus may include a step for posting the identified bulletin on a ledger. The apparatus may include a step for calculating a unique shared secret for each participant and log writer pair. The device may be employed in situations where a matching notification token may be identified by the party while keeping the other parties secret.

The device may be employed in the case where the transaction data set stores the current protocol as an Abstract Syntax Tree (AST). The device may also be employed in the case of updating a transaction data set with a merck hash to form a Merck Abstract Syntax Tree (MAST).

The apparatus may include a step for performing an audit to prove that the evolution of the agreement from the first transaction data set to the second transaction data set was properly authorized and properly performed and that all participants were notified of changes associated with them. The device may also be employed in situations where the audit has not demonstrated that participants are notified of changes that are not relevant to them.

Drawings

Illustrative, non-limiting, exemplary embodiments will become more apparent from the following detailed description, particularly when taken in conjunction with the accompanying drawings, in which:

FIG. 1 is a schematic block diagram illustrating the evolution of a Digital Asset Modeling Language (DAMLTM) protocol through decision making according to an example embodiment of the present disclosure;

FIG. 2 is a schematic Abstract Syntax Tree (AST) parsing diagram according to an example embodiment of the disclosure;

FIG. 3 is a schematic block diagram illustrating evolution of DAMLTM protocols through decision making with Distributed Ledger Technique (DLT) log credential verification, according to an example embodiment of the present disclosure;

FIG. 4 is a schematic block diagram illustrating interested party identification in accordance with an exemplary embodiment of the present disclosure;

FIG. 5 is a schematic Merck-Abstract syntax Tree (MAST) resolution diagram according to an example embodiment of the present disclosure; and

Fig. 6 is a schematic system diagram showing a contract authorization and distribution framework (Contract Authorization and Distribution Framework, abbreviated CADF) according to an example embodiment of the present disclosure.

Detailed Description

The inventive concept will be described more fully with reference to the accompanying drawings in which exemplary embodiments are shown. The inventive concept may, however, be embodied in many different forms and should not be construed as being limited to the embodiments set forth herein. Like reference numerals may refer to like elements throughout the description. As used herein, the term "model" is defined as at least one set of agreements or potential transactions that may or may not represent digitally represented agreements or contracts with legal constraints according to certain management rules (e.g., perhaps provided by a master contract).

The exemplary embodiment system performs multi-edge bookkeeping, where protocols evolve along previously agreed and normalized rules due to authorization decisions, ensuring that participants are able to learn the protocols they are involved in, being able to exclude contradictory protocols by merely appending logs about the sharing of protocol conversions, the participants may have only partial insight into the protocols (which is sufficient for their authorization and logging), the participant's partial protocol library is kept non-contradictory to the other participant's logging and verifiable within the scope of what the participant is visible, and being able to automatically audit the evolution of the authorization and protocol.

As shown in fig. 1, the Digital Asset Modeling Language (DAMLTM) protocol evolution is indicated generally by the reference numeral 100. DAMLTM the previous protocol 110 is affected by the decision 112, resulting in DAMLTM the current protocol 114.

Turning to fig. 2, an exemplary DAMLTM Abstract Syntax Tree (AST) parse diagram is indicated generally by the reference numeral 200. Here, an operator 210 refers to a stub 212 and another operator 220. The further operator 220 refers to a first stub 222, a second stub 224 and a third stub 226. Although the exemplary AST is DAMLTM-based, the AST in alternative embodiments may be based on alternative Contract Specification Language (CSL).

Turning now to fig. 3, a DAMLTM protocol evolution utilizing Distributed Ledger Technology (DLT) log credential verification is indicated generally by the reference numeral 300. Here, the DLT blockchain global synchronization log includes blocks 310, 312, 314, 316, 318, 320, 322, 324, and 326.DAMLTM the previous protocol 330 is affected by decision 332, resulting in DAMLTM protocol 334.DAMLTM the previous protocol 330 is affected by alternative decision 336, resulting in DAMLTM alternative protocol 338. The credentials from block 326 are used to verify the previous protocol 330, while the credentials from block 318 are used to verify the protocol 334. However, since there are no credentials on the DLT blockchain log to verify the alternative protocol 338, the alternative protocol 338 is invalid.

As shown in fig. 4, a participant identification workflow is indicated generally by the reference numeral 400. Here, in function block 410, the log writer derives a token from the identity of the a-party and the secret key of the log writer. In function block 420, party a derives a token from the identity of the log writer and the secret key of party a. In input block 430, the notification token is utilized to receive credentials relating to the protocol of the a-party. The function block 432 may perform optional processing and is directed to a function block 434. The function block 434 determines the identity of the a-party and points to block 436. The function block 436 may perform optional processing and point to a function block 438. The function block 438 then determines the identity of the log writer.

Turning to fig. 5, a Merck Abstract Syntax Tree (MAST) DAMLTM parse diagram is indicated generally by the reference numeral 500. Here, the merck hash 540 references another merck hash 542 and the operator 520. Operator 520 references first stub 522, second stub 524, and third stub 526.

Turning now to fig. 6, a Contract Authorization and Distribution Framework (CADF) interconnect system is indicated generally by the reference numeral 600. Here, a global synchronization log 650 based on an exemplary Digital Ledger Technique (DLT) blockchain is connected to each of the first CADF unit 660 and the second CADF unit 670. The first and second CADF units communicate using a protocol written in DAMLTM, which DAMLTM may be converted to AST or MAST. The CADF system may authorize, store and request protocols from another CADF system on behalf of another party. The first CADF 660 is in turn connected to an Information Technology (IT) system 680 of party a, while the second CADF670 is in turn connected to a non-system 690 of party B.

The Digital Asset Modeling Language (DAMLTM) is a very expressive language that enables financial institutions to model protocols and execute protocols, where such modeling and execution is deterministic and deterministic. The Distributed Ledger Technique (DLT) based global synchronization log is a shared ledger with replication (such as, but not limited to, blockchain) with a synchronization mechanism called "consistency algorithm". A Contract Authorization and Distribution Framework (CADF) supports or includes services that selectively disclose contracts to participants and collect their decision authorizations.

The presently disclosed digital asset platform supports multiple roles, different roles may have different capabilities in terms of access and/or review protocols, or the presently disclosed digital asset platform technically supports the security of the platform. Unique design decisions in configuring damlm, DLT logs, and/or CADF provide a powerful tool to simplify (streamline) and execute contractual workflows between and within financial institutions.

The DAMLTM code models protocols between parties as models that generally ultimately refer to other DAMLTM models, each of which DAMLTM models evolve into new models through one's decision. The new model may involve other parties in or with the contract, may provide new decision choices, or may even be the same as the previous model. Unique attributes of DAMLTM language that are particularly suited for such purposes include: 1) The DAML model enumerates all the current possible choices of parties and their respective results. 2) The decision is such that the DAML model will evolve in limited steps to a new DAML model, after which the new DAML model waits for new decisions to evolve further. 3) The DAML model can be analyzed to infer: a) Current parties and their available choices; and b) a set of parties that will participate in the new contract when a current party decides to make any of its current selections. 4) DAML allows parts of the model to be extracted such that they are themselves also valid DAML models, but may have a smaller number of participants.

Although DAML is human-readable and editable, it can be converted into and form a well-defined and unique technical representation called an Abstract Syntax Tree (AST), as shown in FIG. 2. DAML allows operators, which may combine stubs or other operators. The operator may represent a decision option and a subtree of the operator may define the effect of the decision. As a result of the decision, the stub may be replaced with a model (also denoted AST).

Reliable bookkeeping of the current protocol is used to avoid contradictory protocols that are considered valid by either party at the same time. Distributed Ledger Technique (DLT) is an alternative to third party bookkeeping and bilateral bookkeeping. Its main advantage is scalability compared to double-sided bookkeeping, and its main advantage is resistance to attacks compared to third-party bookkeeping. The distributed ledger technique introduces multi-edge bookkeeping whereby network members cooperate to create a reliable shared infrastructure that determines the order of protocols. Once the order of protocols is clear, contradictory protocols can be resolved by considering only the earlier protocols as valid. The DLT global synchronization log is an append-only log (application-only log) of credentials for protocol evolution. The DLT log data structure is characterized by: complex integrity certificates based on digital signatures and cryptographic hashes. Members of the DLT log network can prove to themselves that their log copies match those of most network participants by executing a consistency algorithm. The benefits of DLT to contractors are: if each party decides that the DLT log should include all contracts, it can identify the complete current set of contracts while automatically excluding alternatives.

When representing the complete current contract set, the DLT log also serves as a publishing channel for declaring new contracts to participants. The participants need to be informed of the validity of the protocol. The presently disclosed digital asset platform stores notification tokens into the credentials of the new model. Participants may monitor their tokens. To protect the privacy of the party, the notification token is computed in such a way that only the writer of the log and the party know that the notification token is linked to the party.

The notification token is a function of the shared secret between the log writer and the notified party. The derivation of the shared secret may be achieved by advertising the identity of the log writer and the participant on the log in advance. The identity is associated with a public key, which is kept secret by the agent represented by the advertised identity. The log supports advertising and revocation of the identity for regular key scrolling or emergency revocation after security leaks affecting a party occur.

The Contract Authorization and Distribution Framework (CADF) is used for decisions that require proper authorization by the party making the choice. The platform collects digital signatures for business intent formatted into credential authorizations using DAML derived ASTs. Since DAML may not be authoritative, it needs to be provided on demand by the creator's network node. If the requestor does not have access to view the contract or has only replied to partially hidden AST (enough to support the creator's decision making process), delivery of the AST for signing may be denied.

The platform uses the Merck Abstract Syntax Tree (MAST) to hide the AST portion. Portions of an AST are replaced by the merck hash of their respective subtrees to create a MAST. The merck hash does not disclose anything about hidden information. The merck hash is computed in such a way that a digital signature based on a complete AST or any MAST it derives can be demonstrated by knowledge of the AST or any MAST it derives. Thus, parties will retain incomplete copy set content of the model that they have the right to view or need authorization. Their model stores are similar to polygonal bookkeeping, but are normalized and properly authorized.

Once sufficient authorization is collected, the new protocol will be demonstrated on the DLT log. The voucher does not disclose anything about the model content, but is compiled into a fingerprint that enables all participants to prove that the voucher is protocol specific. The polygon model library filtered by credentials on the DLT log fully and reliably defines the current protocol set for all participants.

The various network nodes connected to the shared infrastructure may have different roles. One node may fulfill several roles.

One role is "ledger writer". The network node that records the credentials into the append-only log is a ledger writer. Although not technically necessary, it will most likely also ensure that the recording of the credentials is contradictory as little as possible and so that the protocol it records is fully known and there is a complete record of this in its CADF. The roles of ledger writers may be shared by several nodes, so ledger writers need their joint authorization in the desired scenario.

Another role is "ledger reader". This is a network node representing parties that may be involved in some protocols or for supervising rights. The ledger reader will focus on the notification of its service on the DLT log and aggregate the partial database of the protocol through its CADF.

Yet another role is "auditor". The purpose of the auditor is to keep the ledger reader checked: the protocol evolution is proven to be properly executed and authorized, the participants are notified, and no contradictory protocols are recorded. Similar to ledger writers, auditors may have some knowledge of the protocol, but in addition, it may also learn the shared secret of multiple parties. Violations of the protocol by the ledger writer will be flagged by the auditor and will be handled outside of the shared infrastructure described. Since the auditor's task is to execute a checking algorithm that does not require human judgment or supervision, the auditor may be an autonomously executing algorithm that runs in a secure computing environment. The communication with the secure environment may be encrypted and configured such that no other data may leave the secure environment than any failed rule-validation set flags observed by the auditor.

By default, all parties to the protocol need to be authorized. The protocol may replace the previous protocol. The protocol is typically "multi-event (eventful)", as it depends on at least one external input or event, but this is not required. The syntax and interpretation of the agreement is entirely dependent on the parties agreeing to "closing (off ledger)". The ledger of the exemplary embodiment records such accounting protocols, but is not intended to explain them. In certain cases, such an agreement may be in accordance with the requirements of a legally executable contract for a given jurisdiction if such an agreement (which can result in a valid agreement being reached) is intended by the parties and their respective entitlements have legal status. In general, ledgers are not concerned with whether a given agreement is legally executable, and exemplary embodiments do not distinguish between a general agreement and an agreement that meets legally executable contract criteria. The inventive concept envisages, when required: the master contract can be used to give the DAML agreement as a legal identity to the contract in a particular jurisdiction.

All of the code, data structures, etc. discussed above may be stored in a non-transitory computer readable storage medium. The functional steps described herein may be performed by computer code executing on a processor. The various data manipulations described above may be accomplished with respect to a stored data structure to create a transformed data structure that is processed in different ways by a computer processor. The various functions of the embodiments allow the computing system to operate in a new manner to complete transactions and provide new benefits. The various flowchart steps may be performed by software modules executing on a computer processor. The various blocks shown in the figures may represent data structures, such as databases storing records, which are manipulated in the manner described to allow a computing system to manipulate and transform data.

Although the inventive concept has been described herein by way of example with respect to non-limiting exemplary embodiments; other alternatives, modifications, and variations will be apparent to those skilled in the relevant art based on the teachings disclosed herein. Accordingly, the scope of the appended claims is intended to include all such alternatives, modifications, and variations of the exemplary embodiments set forth herein, as well as equivalents that fall within the scope and spirit of the disclosure.

Claims

1. A method performed by one or more processors, comprising:

Receiving an input comprising a decision by a first party regarding a protocol between parties including the first party;

Deriving from the received input which of the participants of the protocol are affected by the decision of the first participant, wherein those participants affected by the decision of the first participant are part of the multiparty;

For each given party in the portion of the parties affected by the decision of the first party:

generating a notification token from the key of the given party and the key of the second party; and

The decision of the first party, the generated notification token and the identity of the second party are sent to the private data store of the given party,

Wherein the decision and the generated token of the first party are sent only to the private data store of the portion of the parties.

2. The method of claim 1, wherein transmitting the decision of the first party and the generated token comprises: the decision of the first party is converted into an abstract syntax tree AST, which is then sent.

3. The method of claim 1, wherein transmitting the decision of the first party and the generated token comprises: the decision of the first party is converted into an abstract syntax tree AST, a part of which is partially hidden with one or more merck hashes to form a merck abstract syntax tree MAST, which is then sent.

4. The method of claim 1, wherein the token is generated from any one of: (i) The identity of the given party and the private key of the second party, or (ii) the identity of the second party and the private key of the given party.

5. The method of claim 1, wherein the second party is a ledger writer node.

6. A system, comprising:

One or more processors configured to:

In response to receiving input comprising a decision by a first party regarding a protocol between parties including the first party, deriving from the received input which parties of the protocol are affected by the decision by the first party, wherein those parties affected by the decision by the first party are part of the parties;

Generating a notification token from the key of the given party and the key of the second party only for each given party of the parts of the parties affected by the decision of the first party; and

The decision of the first party, the generated notification token and the identity of the second party are sent to the private data store of the given party.

7. The system of claim 6, wherein the one or more processors are configured to: the decision of the first party is converted into an abstract syntax tree AST, which is then sent.

8. The system of claim 6, wherein the one or more processors are configured to: the decision of the first party is converted into an abstract syntax tree AST, a part of which is partially hidden with one or more merck hashes to form a merck abstract syntax tree MAST, which is then sent.

9. A non-transitory computer readable program storage device storing program instructions that, when executed, cause a computer to perform a method comprising:

10. The device of claim 9, wherein transmitting the decision of the first party and the generated token comprises: the decision of the first party is converted into an abstract syntax tree AST, which is then sent.

11. The device of claim 9, wherein transmitting the decision of the first party and the generated token comprises: the decision of the first party is converted into an abstract syntax tree AS T, a part of the AST is partially hidden with one or more merck hashes to form a merck abstract syntax tree MAST, which is then sent.

12. The apparatus of claim 9, wherein the token is generated from any one of: (i) The identity of the given party and the private key of the second party, or (ii) the identity of the second party and the private key of the given party.

13. The apparatus of claim 9, wherein the second party is a ledger writer node.