|
1 | 1 | # Transaction Endorser Support |
2 | 2 |
|
3 | | -Note that the ACA-Py transaction support is in the process of code refactor and cleanup. The following documents the current state, but is subject to change. |
4 | | - |
5 | 3 | ACA-Py supports an [Endorser Protocol](https://github.com/hyperledger/aries-rfcs/pull/586), that allows an un-privileged agent (an "Author") to request another agent (the "Endorser") to sign their transactions so they can write these transactions to the ledger. This is required on Indy ledgers, where new agents will typically be granted only "Author" privileges. |
6 | 4 |
|
7 | 5 | Transaction Endorsement is built into the protocols for Schema, Credential Definition and Revocation, and endorsements can be explicitely requested, or ACA-Py can be configured to automate the endorsement workflow. |
@@ -61,3 +59,44 @@ Endorsement: |
61 | 59 | For Authors, specify whether to automatically promote a DID to the wallet public DID after writing to the ledger. |
62 | 60 | ``` |
63 | 61 |
|
| 62 | +## How Aca-py Handles Endorsements |
| 63 | + |
| 64 | +Internally, the Endorsement functionality is implemented as a protocol, and is implemented consistently with other protocols: |
| 65 | + |
| 66 | +- a [routes.py](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/protocols/endorse_transaction/v1_0/routes.py) file exposes the admin endpoints |
| 67 | +- [handler files](https://github.com/hyperledger/aries-cloudagent-python/tree/main/aries_cloudagent/protocols/endorse_transaction/v1_0/handlers) implement responses to any received Endorse protocol messages |
| 68 | +- a [manager.py](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/protocols/endorse_transaction/v1_0/manager.py) file implements common functionality that is called from both the routes.py and handler classes (as well as from other classes that need to interact with Endorser functionality) |
| 69 | + |
| 70 | +The Endorser makes use of the [Event Bus](https://github.com/hyperledger/aries-cloudagent-python/blob/main/CHANGELOG.md#july-14-2021) (links to the PR which links to a hackmd doc) to notify other protocols of any Endorser events of interest. For example, after a Credential Definition endorsement is received, the TransactionManager writes the endorsed transaction to the ledger and uses the Event Bus to notify the Credential Defintition manager that it can do any required post-processing (such as writing the cred def record to the wallet, initiating the revocation registry, etc.). |
| 71 | + |
| 72 | +The overall architecture can be illustrated as: |
| 73 | + |
| 74 | + |
| 75 | + |
| 76 | +### Create Credential Definition and Revocation Registry |
| 77 | + |
| 78 | +An example of an Endorser flow is as follows, showing how a credential definition endorsement is received and processed, and optionally kicks off the revocation registry process: |
| 79 | + |
| 80 | + |
| 81 | + |
| 82 | +You can see that there is a standard endorser flow happening each time there is a ledger write (illustrated in the "Endorser" process). |
| 83 | + |
| 84 | +At the end of each endorse sequence, the TransactionManager sends a notification via the EventBus so that any dependant processing can continue. Each Router is responsible for listening and responding to these notifications if necessary. |
| 85 | + |
| 86 | +For example: |
| 87 | + |
| 88 | +- Once the credential definition is created, a revocation registry must be created (for revocable cred defs) |
| 89 | +- Once the revocation registry is created, a revocation entry must be created |
| 90 | +- Potentially, the cred def status could be updated once the revocation entry is completed |
| 91 | + |
| 92 | +Using the EventBus decouples the event sequence. Any functions triggered by an event notification are typically also available directly via Admin endpoints. |
| 93 | + |
| 94 | +### Create DID and Promote to Public |
| 95 | + |
| 96 | +... and an example of creating a DID and promoting it to public (and creating an ATTRIB for the endpoint: |
| 97 | + |
| 98 | + |
| 99 | + |
| 100 | +You can see the same endorsement processes in this sequence. |
| 101 | + |
| 102 | +Once the DID is written, the DID can (optionally) be promoted to the public DID, which will also invoke an ATTRIB transaction to write the endpoint. |
0 commit comments