diff --git a/indy-besu/docs/design/contracts.png b/indy-besu/docs/design/contracts.png index b9cda467c..fdc23fb9a 100644 Binary files a/indy-besu/docs/design/contracts.png and b/indy-besu/docs/design/contracts.png differ diff --git a/indy-besu/docs/design/contracts.puml b/indy-besu/docs/design/contracts.puml index 1450feb1d..8bfc95b08 100644 --- a/indy-besu/docs/design/contracts.puml +++ b/indy-besu/docs/design/contracts.puml @@ -1,7 +1,5 @@ @startuml - - left to right direction package "Smart Contracts" { @@ -18,13 +16,15 @@ 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 @@ -32,6 +32,7 @@ package "Smart Contracts" { 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 diff --git a/indy-besu/docs/design/endorsement.md b/indy-besu/docs/design/endorsement.md index 8297d6d95..7d644f305 100644 --- a/indy-besu/docs/design/endorsement.md +++ b/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. diff --git a/indy-besu/docs/design/flow.png b/indy-besu/docs/design/flow.png new file mode 100644 index 000000000..f0367659f Binary files /dev/null and b/indy-besu/docs/design/flow.png differ diff --git a/indy-besu/docs/design/flow.puml b/indy-besu/docs/design/flow.puml new file mode 100644 index 000000000..a6a2f8e0a --- /dev/null +++ b/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 \ No newline at end of file diff --git a/indy-besu/docs/design/registry.md b/indy-besu/docs/design/registry.md index 30a3cc6cf..1932606ae 100644 --- a/indy-besu/docs/design/registry.md +++ b/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 diff --git a/indy-besu/vdr/src/utils/mod.rs b/indy-besu/vdr/src/utils/mod.rs index e4e386ae3..d445c81dd 100644 --- a/indy-besu/vdr/src/utils/mod.rs +++ b/indy-besu/vdr/src/utils/mod.rs @@ -9,4 +9,4 @@ pub fn encode_contract_param>(obj: T) -> VdrResult