Added flow diagram

Signed-off-by: artem.ivanov <[email protected]>

indy-besu/docs/design/contracts.puml

@@ -1,7 +1,5 @@
 @startuml
 
-
-
 left to right direction
 
 package "Smart Contracts" {
@@ -18,20 +16,23 @@ package "Smart Contracts" {
 
         component [Account Control]
         note right of [Account Control]
-          Control whether to accept write transactions
+          **Besu specific**
+          Top level control whether to accept write transactions
           - only senders with 'trustee' role can deploy new contracts
           - only senders with not-empty roles can write transactions
         end note
 
         component [Validator Control]
         note right of [Validator Control]
+          **Besu specific**
           Control the list of network validator nodes
           - only steward can add/remove nodes
         end note
 
         component [Upgrade Control]
         note right of [Upgrade Control]
           Control versions of deployed contracts
+          - UUPS proxy pattern
           - all contracts depends on Upgrade Control contract
           - define common rules for contracts upgrade
         end note
@@ -44,13 +45,18 @@ package "Smart Contracts" {
             component [Indy Did Registry]
             note bottom of [Indy Did Registry]
               Manage `indy2` DID method records
+              - legacy DID identifier
               - did doc stored in the contract storage
+              - many-to-one relationship with account
             end note
 
             component [Ethereum Did Registry]
             note bottom of [Ethereum Did Registry]
               Manage `ethr` DID method records
+              - DID identifier is an account address
+              - one-to-one relationship with account
               - `did:ethr` spec implies that DID exist by default
+              - uses events approach
               - extended to control versioning
             end note
 

indy-besu/docs/design/endorsement.md

@@ -81,10 +81,11 @@ fn build_endorse_did_transaction(
 
 ### DID Ethr registry
 
-`did:ethr` allows using Ethereum addresses as identifier without prior its registration on the network, so that DID
-assume to be written by default.
+`did:ethr` allows using Ethereum addresses as identifier without prior its registration on the network. 
 
-Endorsement is available to modify DID properties via the set of contract methods:
+So that DID assume to be written by default -> endorsement is not needed.
+
+Endorsement is needed to modify DID properties, what can be done using the set of existing contract methods:
 
 ```
 function setAttributeSigned(address identity, uint8 sigV, bytes32 sigR, bytes32 sigS, bytes32 name, bytes memory value, uint validity)
@@ -98,6 +99,12 @@ function revokeDelegateSigned(address identity, uint8 sigV, bytes32 sigR, bytes3
 function changeOwnerSigned(address identity, uint8 sigV, bytes32 sigR, bytes32 sigS, address newOwner)
 ```
 
+#### Contracts
+
+Should we extend DidEthrRegistry contract to add roles check? 
+
+> We already extended `DidEthrRegistry` to use UpgradeControl
+
 #### VDR
 
 TO BE defined later.

indy-besu/docs/design/flow.puml

@@ -0,0 +1,107 @@
+@startuml
+
+skinparam BoxPadding 20
+
+box "Node"
+participant "Contracts" as C
+endbox
+
+box "Trustee" #LightYellow
+actor "Agent" as T
+participant "VDR" as TV
+participant "Wallet" as TW
+endbox
+
+box "Endorser"
+actor "Agent" as E
+participant "VDR" as EV
+participant "Wallet" as EW
+endbox
+
+box "Faber" #LightYellow
+actor "Agent" as F
+participant "VDR" as FV
+participant "Wallet" as FW
+endbox
+
+== Setup actors ==
+
+E->EW: Create account (with seed)
+E->EV: Init client (node address and contracts ABI)
+T->TW: Create account (with seed)
+T->TV: Init client (node address and contracts ABI)
+F->FW: Create account
+F->FV: Init client (node address and contracts ABI)
+
+== Assign role ==
+
+E-->T: Pass Account address
+T->TV: Build transaction to assign Endorser role
+T->TV: Get bytes to sign
+T->TW: Sign transaction
+T->TV: Set transaction signature
+T->TV: Submit transaction
+TV->C: Send transaction
+C-->C: Execute RoleControl.assignRole contract
+
+== Create Indy Did ==
+
+E->EV: Build Did Document
+E->EV: Build and sign transaction to create Did
+E->EV: Submit transaction
+EV->C: Send transaction
+C-->C: Execute IndyDidRegistry.createDid contract
+
+== Create Ethr Did ==
+
+note across
+  DID is an account address and not require writing on the ledger
+end note
+
+E->EV: Build and sign transaction to add DID attribute (Service)
+E->EV: Submit transaction
+EV->C: Send transaction
+C-->C: Execute EthrExtDidRegistry.setAttribute contract
+
+== Endorse Indy Did ==
+
+F->FV: Build Did Document
+F->FV: Encode Did Document
+F->FW: EdDSA sign did document bytes
+F-->E: Pass Did Document, Signature
+E->EV: Build and sign transaction to endorse Did
+E->EV: Submit transaction
+EV->C: Send transaction
+C-->C: Execute IndyDidRegistry.endorseDid contract
+
+== Endorse Ethr Did ==
+
+note across
+  Not needed as DID imply to be written by default
+  Owner can add resource without endorsement need
+end note
+
+== Create Schema (any DID method) ==
+
+E->EV: Build Schema
+E->EV: Build and sign transaction to create Schema
+E->EV: Submit transaction
+EV->C: Send transaction
+C-->C: Execute SchemaRegistry.createSchema contract
+C-->C: Resolve and verify issuerDid ownership
+
+== Endorse Schema (any DID method) ==
+
+F->FV: Build Schema
+F->FV: Encode Schema
+F->FW: EdDSA sign Schema bytes
+F-->E: Pass Schema, Signature
+E->EV: Build and sign transaction to endorse Schema
+E->EV: Submit transaction
+EV->C: Send transaction
+C-->C: Execute SchemaRegistry.endorseSchema contract
+C-->C: Resolve and verify issuerDid ownership
+
+==  ==
+
+@enduml

indy-besu/docs/design/registry.md

@@ -8,7 +8,7 @@ The main question is whether we need to validate storing object or not?
 #### Pros
 
 * Only mostly correct data written on the ledger
-  * Perform full validation is really difficult in solidity 
+  * byt we do only [part of the validation](#validation-we-do-for-the-moment) - perform the full validation is really difficult in solidity 
 
 #### Cons
 
@@ -27,9 +27,12 @@ The main question is whether we need to validate storing object or not?
           we have to restore its original form
 * Inferiority of the performed validation
 * Contract size is very big and exceed the limit for public network 
-  * Deployment limitation as contracts can be deployed only to gas free networks
+  * We had to change default contract size setting in the Besu config
+  * Deployment limitation, as contracts can be deployed only to gas free networks
 * Inefficient from the gas point of view
 * Finiteness as we can support only specific object versions and formats without upgrade
+  * For example, if new service type supported we need to update both: contract and VDR
+* Strong relationship with VDR library - it does conversion of formats 
 
 ##### Validation we do for the moment
 
@@ -78,5 +81,6 @@ The main question is whether we need to validate storing object or not?
 * Duplication:
   * Some fields must be passed as an independent parameters for doing obligatory state checks
     * Like issuer DID for schema and cred def 
-
+* Strong relationship with VDR library?
+  * VDR must perform the validation of sending data
 

indy-besu/vdr/src/utils/mod.rs

@@ -9,4 +9,4 @@ pub fn encode_contract_param<T: Into<ContractParam>>(obj: T) -> VdrResult<Vec<u8
     let contract_param: ContractParam = obj.into();
     let encoded = ethabi::encode(&[contract_param]);
     Ok(encoded)
-}
+}