Updated overview document

docs/cbdc-pppl-overview.md

@@ -49,15 +49,19 @@ Let us consider a set of operating principles based on which the proposed soluti
 - **Enforce ability to record and refer to one version of truth by standardised, immutable, timestamped, signed schema records:**
 - **Use proofs to avoid data sharing. Use consent and usage constraints where it is unavoidable:**
 
+<br/>
+<br/>
+
+![PPL Overview Diagram](images/ppl-image.png "Title")
 
 
 ## Parties in PPL Ecosystem:
 
-**Entities:** These are the entities who are legal persons which would include people, companies, trusts, associations etc which participate in monetary and goods flow. Each entity will have a globally unique identifier. This could be an external or internal identifier such as an Aadhaar or GSTIN or PAN with appropriate KYC performed.
+**Entities:** These are the entities who are legal persons or identities which would include people, companies, trusts, associations etc which participate in monetary and goods flow. Each entity will have a globally unique identifier. This could be an external or internal identifier such as an Aadhaar or GSTIN or PAN with appropriate KYC performed. The ledger should support anonymous parties subject to schema rules not constraining such identities.
 
-**Wallet Operators:** Wallet operators are agents of the legal persons. They are thus managed by or contracted out by the entities. The corresponding tech stack could be built, purchased or outsourced by entities. They have full and complete visibility into the monetary and commercial flows that the entity is involved or associated with. The PPL model will specify the protocols / APIs / behaviours that wallet operators will support, but it would be upto the entities to ensure that wallet operators adhere to such correctly. The role of the wallet operator is to be able to interact with the rest of the ecosystem even as it instills adequate confidence in the entities that its data remains private and is shared with other parties only consistent with the instructions or consent of the entity and with the regulatory framework in place for that type of data. By default wallet operators will not require to be regulated, but such a requirement is a conditional possibility based on the nature of the data they store.
+**Wallet Operators:** Wallet operators are agents of the legal persons or identities. They are thus managed by or contracted out by the entities. The corresponding tech stack could be built, purchased or outsourced by entities. They have full and complete visibility into the monetary and commercial flows that the entity is involved or associated with. The PPL model will specify the protocols / APIs / behaviours that wallet operators will be required to support, but it would be upto the entities to ensure that wallet operators adhere to such correctly. The role of the wallet operator is to be able to interact with the rest of the ecosystem even as it instills adequate confidence in the entities that its data remains private and is shared with other parties only consistent with the instructions or consent of the entity and with the regulatory framework in place for that type of data. By default wallet operators will not require to be regulated, but such a requirement is a conditional possibility based on the nature of the data they store.
 
-**Notaries:** Notaries are a federated group of systems who record the existence and sequence of various states and transactions (although they do not have access to the underlying private data). They can perform critical validations necessary for correct functioning of the overall system, assert existence of transactions, and if someone has full data about the transaction, they can assert its validity. Since wallet operators or the underlying schema definition could choose some data to be public, the notaries will also in effect implement a permissioned publicly visible chain of data for such public data. It is anticipated that notaries being important to provide the necessary trust and automate behaviour through the system will be regulated entities.
+**Notaries:** Notaries are a single or federated group of systems who record the existence and sequence of various states and transactions (although they do not have access to the underlying private data). They can perform critical validations necessary for correct functioning of the overall system, assert existence of transactions, and if a wallet operator has full data about the transaction, they can assert its validity to the extent of ensuring the proofs can be generated and verified as required. Since wallet operators or the underlying schema definition could choose some data to be public, the notaries will also in effect implement a permissioned publicly visible chain of data for such public data. It is anticipated that notaries being important to provide the necessary trust and automate behaviour through the system and will often be regulated entities. It should be noted that only notaries will be allowed to write to the ledger, but the protocols will ensure that no private data is ever required to be shared with the notaries. Transaction rules can choose to require a single global notary, a set of permissioned regulated notaries, or even a distributed model of anyone can be a notary. Which notary can notarise the transaction will be governed by that particular transaction rules as defined in the schema. 
 
 **Oracles:** These are external systems which can provide additional data related to constructs they specialise in that may be referenced on the ppl. Oracles may provide static data (eg. details of an e-invoice or eway bill given an id of the underlying instrument) or dynamic (eg. current foreign currency rate)
 
@@ -67,11 +71,11 @@ Let us consider a set of operating principles based on which the proposed soluti
 
 While there continues to be some discussion on whether some of the constructs will be token based or account based, for the purposes of this document it is assumed that where appropriate the UTXO model (Unspent Transaction Output) will be used to model value. The two most important constructs are *State* and *Transaction*.
 
-**State:** A state represents a snapshot of a piece of data at a point in time.  It could represent cash in the wallet, account balance, a liability to pay in the future, an eway bill, a contract to buy something at a future date. States may include data which is provided by oracles, by referencing the oracle and the primary identifier of that data. While we have not yet referred to it yet, such states will be stored in a wallet and will reference the wallet it is stored in. Even if the state has evolving characteristics, PPL will store data in an immutable fashion and thus a different version of that state will be stored yet again when it changes and the old version will be extinguished (or closed). 
+**State:** A state represents a snapshot of a piece of data at a point in time.  It could represent cash in the wallet, account balance, a liability to pay in the future, an eway bill, a contract to buy something at a future date. States may include data which is provided by oracles, by referencing the oracle and the primary identifier of that data. While we have not yet referred to it yet, such states will be stored in a wallet and will reference the wallet it is stored in. Even if the state has evolving characteristics, PPL will store data in an immutable fashion and thus a different version of that state will be stored yet again when it changes and the old version will be cancelled. 
 
 **Wallet:** A wallet is a holder for a variety of states. In the wallet itself, all the details of the state, public and private, will be fully stored along with all additional attributes as required by PPL protocol. Further the wallet will be the primary vehicle through which existing systems such as core banking or logistics management systems or ERPs will export/import their data so that the same becomes interoperable with PPL as a whole. 
 
-**Transaction:** A transaction is a construct which records states that are being closed and new ones that are being created as one atomic unit. Some subset of the data including the public parts of the states, and other necessary protocol required attributes will form the transaction and be shared with the notary for recording. Note that the transaction does not contain the private parts of the state. In addition to the wallets that contain the states that are a part of the transaction, additional wallets could also be specified for data sharing and regulatory purposes. In that case this transaction will be the token through notaries will ensure that the participating wallets have also received the data
+**Transaction:** A transaction is a construct which records states that are being cancelled and new ones that are being created as one atomic unit. Some subset of the data including the public parts of the states, and other necessary protocol required attributes will form the transaction and be shared with the notary for recording. Note that the transaction does not contain the private parts of the state. In addition to the wallets that contain the states that are a part of the transaction, additional wallets could also be specified for data sharing and regulatory purposes. In that case this transaction will be the token through notaries will ensure that the participating wallets have also received the data
 
 For easier operation, PPL may pre-identify some sub-classes of states that may be widely required and used
 
@@ -83,7 +87,11 @@ Some others could be invoice, eway bill (which could essentially just reference
 
 **Digital Coin:** While unclear if it needs to be separate from an IOU where the issuing party is RBI, and it is measured in INR, this would effectively form the CBDC token.
 
-**Smart Contract:** While this may be essentially a standing instruction in early days, over time it may also become a more complex smart contract which will trigger predetermined flows based upon pre agreed upon events. Exactly how the public / private part of the data of a smart contract will be split isn't clear yet, but all the data that is necessary for notaries to actually carry out the instructions will need to be public. 
+**Programmatic Contract:** While this may be essentially a standing instruction in early days, over time it may also become a more complex smart contract which will trigger predetermined flows based upon pre agreed upon events. Exactly how the public / private part of the data of a smart contract will be split isn't clear yet, but all the data that is necessary for notaries to actually carry out the instructions will need to be public.
+
+### Metadata constructs in PPL:
+
+An important part of PPL will be how the metadata itself be published to the ledger. Any party can choose to define a schema and publish it to PPL. Such schema elements can be imagined similar to table or index constructs in a database. They will instead publish the nature of states, transactions, events, proofs to be computed etc. They will be versioned and schemas can reference elements from other schemas. The goal is to be able to create a metadata system so that the wallet operators can validate data elements at points of ingress or egress and Notaries can store, validate and ensure appropriate proof generation and verification for each transaction on the ledger without the notary code base having to get changed for each schema that gets added. 
 
 ## Role of Wallet Operators:
 
@@ -99,14 +107,14 @@ As mentioned earlier wallet operators will be agents of various entities and wil
 Notaries will be a bunch of interchangeable and inter-operable federated services who will not have visibility into the private data of states and transactions. Some of their activities and responsibilities will include
 
 1. Validate and record the transactions and ensure that the public details of the same will be visible on the public ledger. The exact structure of the public ledger is too early to describe yet. 
-2. Demand proofs as required by the PPL, and validate proofs as offered by the wallet operators. 
+2. Demand proofs as required by the schema, and validate proofs as offered by the wallet operators. 
 3. Keep track of smart contracts and trigger further steps as required by the smart contract definition if applicable
 
 ## Role of Proofs
 
-Since the system is designed to keep data private, there will be a protocol defined to allow the wallets to be able to prove some conditions about the data to the notary. This will be based on implementing some mechanism of zero knowledge proofs and at least in the short term we are looking at implementing it using ZkSnarks. Some example of proofs will be 
+Since the system is designed to keep data private, there will be a protocol defined to allow the wallets to be able to prove some conditions about the data to the notary. This will be based on implementing some mechanism of zero knowledge proofs and at least in the short term we are looking at implementing it using ZkSnarks though multiple proof mechanisms could be supported. Some example of proofs will be 
 
-1. **Digital Hash:** The hash of a particular state works out to a particular hash value. This is to ensure that at any point in time in the future, it will be possible to prove if a particular fully detailed state was indeed logged with the notary along with the audit trail of its creation and extinguishing or transition into other states if any. 
+1. **Digital Hash:** The hash of a particular state works out to a particular hash value. This is to ensure that at any point in time in the future, it will be possible to prove if a particular fully detailed state was indeed logged with the notary along with the audit trail of its creation and canceling or transition into other states if any. 
 2. **No double spend (for value stores):** This will allow the notaries to validate that the amount being spent (or value being transferred out) is backed by an existing amount (or value) being owned by the spender, and that it has not already been spent (or transferred out).
 3. **Additional proofs required for mandatory validations:** This would be specific based on the state type. Note that in general the wallet operators will be required to implement most of the basic validations, and proofs will be used only for specific validations that are necessary to ensure overall system sanity given that proofs can be significantly more expensive computations.