Ledger strategy #435
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,162 @@ | ||
| # Trusted Ledger (TLCC) | ||
|
|
||
| The purpose of TLCC is to establish a trusted view of the ledger (inside an enclave) | ||
| and enable ECC to verify ledger state receiveed from the (untrusted) peer. | ||
|
|
||
| ## Requirements | ||
|
|
||
| - ECC can query integrity metadata to validate ledger state received from the peer. | ||
| - TLCC must maintain a view on the ledger | ||
| - TLCC must be synronized with peer's ledger state | ||
| - Secure (authenticated) channel between ECC and TLCC to query metadata; | ||
| - ECC tx must perform read/write on a stable view of the ledger state | ||
| - (snapshot during a single transaction invocation) | ||
| - TLCC must detect read/write inconsistency | ||
| - TLCC must be able to perform identity validation (orderer, msp, etc...) | ||
| - TLCC must provide channel metadata (chaincode definition) | ||
| - Maintaining FPC chaincode state only is sufficient | ||
| - Validate "normal" Enclave Registry (ERCC) transactions; however, ERCC comes with "hard-coded" endorsement policy | ||
|
|
||
|
|
||
| ## Fabric high-level validation | ||
|
|
||
| TODO pseudo code here | ||
|
|
||
| Config validation: [source](https://github.com/hyperledger/fabric/blob/f27912f2f419c3b35d2c1df120f19585815eceb0/common/configtx/validator.go#L163) | ||
|
|
||
| - check config sequence number increased by 1 | ||
| - check is authorized Update [source](https://github.com/hyperledger/fabric/blob/f27912f2f419c3b35d2c1df120f19585815eceb0/common/configtx/update.go#L115) | ||
| - verify ReadSet [source](https://github.com/hyperledger/fabric/blob/f27912f2f419c3b35d2c1df120f19585815eceb0/common/configtx/update.go#L18) | ||
| - verify DeltaSet [source](https://github.com/hyperledger/fabric/blob/f27912f2f419c3b35d2c1df120f19585815eceb0/common/configtx/update.go#L68) | ||
| - for each item validate policy [source](https://github.com/hyperledger/fabric/blob/f27912f2f419c3b35d2c1df120f19585815eceb0/common/policies/policy.go#L133) | ||
|
|
||
| Lifecycle validation: | ||
|
|
||
|
|
||
| Default validation: | ||
|
|
||
| - Validating identities that signed the transaction | ||
| - read/write check? | ||
| - Verifying the signatures of the endorsers on the transaction | ||
| - can endorse? | ||
| - Ensuring the transaction satisfies the endorsement policies of the namespaces of the corresponding chaincodes. | ||
|
|
||
|
|
||
| ## Approach | ||
|
|
||
| Restrict Fabric functionality: | ||
|
|
||
| - keep Fabric validation changes in sync with TLCC | ||
| - Reduces validation logic to a minimum | ||
|
There was a problem hiding this comment. Definitely desirable, but my doubt is whether this is possible, given that ERCC and ECC are normal chaincodes, for which we run the normal validation procedure. However, this could open the possibility to implement specific validation plugins for both of them, avoiding the legacy validation. By doing this, we control the entire validation logic; we can implement a simple one and mirror the implementation in TLCC. |
||
| - minimizes catch-up | ||
| - Restrict the notion of endorsement policy; | ||
| - Simplify chaincode versioning (TODO) | ||
| - No chaincode updates for now | ||
| - Support for default MSP only | ||
|
|
||
|
|
||
| Any transactions/blocks with unsupported features are ignored/aborted | ||
|
There was a problem hiding this comment. somewhere we definitely have to be more explicit where we abort and, in particular, where we (safely can) ignore. My feeling is that by default we should abort and ignore only for explicit cases where we know it's safe to ignore .. |
||
|
|
||
| Defined process to develop TLCC: | ||
| - keep redundant validation code (in stock peer and TLCC) in sync | ||
| - keep code relation traceable and changes trackable | ||
| - consistent naming and code structure as much as possible | ||
| - bonus: | ||
| - automated code-changes notification; notifies whenever relevant Fabric code changes and might FPC must be updates. | ||
|
There was a problem hiding this comment. In practice I would expect an FPC release, say 2.2, to support Fabric 2.2. Then, when Fabric 2.3 comes out, a new FPC should follow to support it. |
||
|
|
||
| ### Non-features | ||
|
|
||
| - No state-based endorsement | ||
| - No custom MSP (no idemix) | ||
| - No support for custom endorsing/validation plugins for non-FPC and FPC chaincodes | ||
| - Authentication and decorators | ||
g2flyer marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - TODO check for more non-features in RFC | ||
|
|
||
| ## Design | ||
|
|
||
| ### Chaincode execution support | ||
| - secure channel | ||
| - validate proposal | ||
| - check org is "write" | ||
| - replay protection | ||
|
There was a problem hiding this comment. the view consistency/snapshot probably also belongs here? In that context, would be interesting to know how fabric currently does it: do they serialize update and endorsement or do they maintain different ledger states/views concurrently? the former is of course the easiest to implement (though requires an explicit notification by ecc that a tx is finished) but also means that a slow tx can hold of others (not that this is probably immediately the biggest concern for us :-)) (this in turn might ask for adding eventually the endorsement equivalent of the "Fabric high-level validation" section above?) |
||
|
|
||
| ### Ledger maintainance | ||
|
|
||
| Channel configuration: | ||
| - Parse channel definition | ||
| - parse consensus definition | ||
| - parse channel reader/writers | ||
| - validate block signatures (Note that this check implies correctness as onfig blocks are validated by the ordering service ([see code](https://github.com/hyperledger/fabric/blob/f27912f2f419c3b35d2c1df120f19585815eceb0/orderer/common/msgprocessor/standardchannel.go#L131))) | ||
| - Maintain msp metadata for signature validation | ||
| - parse Lifecycle policy | ||
| - validate Lifecycle policy | ||
| We only support: a majority of Org.member (See [Link](https://hyperledger-fabric.readthedocs.io/en/release-2.2/chaincode_lifecycle.html#install-and-define-a-chaincode)) | ||
|
|
||
| Access control: | ||
| - delegate this "reader/writer/admin" check to admins; | ||
g2flyer marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - TLCC only verifies endorsement policies and thereby implicitly the "writers" check is performed by the endorsers | ||
|
|
||
| MSP: | ||
| - One Org - One MSP mapping - One root cert | ||
| - Implement X509-based MSP | ||
| - Restrict: | ||
| - no intermediate | ||
| - no CRLs | ||
| - only support member role | ||
| - any certificate will match to role member | ||
g2flyer marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| Endorsing: | ||
| - Phase1: Designated enclave only | ||
| - Phase2: Any enclave that runs a particular FPC chaincode | ||
|
|
||
| Versioning: | ||
| - single autonomously monotonously increasing version number?? | ||
|
There was a problem hiding this comment. monotonically increasing version numbers for us will be a bit a challenge with it being MRENCLAVE ... ;-) [different story of course for ercc, though not sure whether for us the version really matters for ercc (compared to sequence numbers) as we look only at meta data changes and on that level version doesn't really have any effect? It is only relevant during the actual execution of the endorsement (which we delegate to normal peers for ercc)? |
||
|
|
||
| Non-FPC Validation: | ||
| - Transaction submitter identity validation | ||
| - submitter satisfies channel's writes policy | ||
| - ERCC endorsement signatures verification | ||
| - ERCC endorsement policy validation | ||
| - we only support (explicityly) Majority endorsement policy | ||
| - Restrict to ERCC namespace only | ||
|
|
||
| FPC Validation: | ||
| - Introduce FPC transaction type (similar to introduce FPC namespace) and create | ||
g2flyer marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| a dedicated FPC tx processor; (removes the need of custom validation plugins and interference with existing Fabric validation logic; and also gives more freedom to FPC validation logic as no it not longer bound to the structure and format of endorsement transaction). | ||
|
|
||
| - Support for (subset of) endorsing policies | ||
| - FPC Chaincode (see above) | ||
|
|
||
| - Parse chaincode definitions | ||
| - Transaction submitter identity validation | ||
| - submitter satisfies channel's writes policy | ||
|
|
||
| - FPC endorsement policy validation | ||
| - Support only: ANY | ||
g2flyer marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - FPC endorsement signatures | ||
|
|
||
|
|
||
| ## Development plan | ||
|
|
||
| ### short term | ||
| See approach above | ||
|
|
||
| We restrict the supported endorsement policies for lifecycle, ERCC, and FPC chaincodes. | ||
|
|
||
| ### mid/long term | ||
| Re-use Fabric code components inside trusted ledger enclave. This requires further development on go-support for SGX. Although some PoC based on graphene for go are already available but seems not be stable yet. | ||
|
|
||
| We may extend support for more enhanced endorsement policies in the future. | ||
|
|
||
| ### QA process | ||
|
|
||
| ## Implementation | ||
|
|
||
| - nanopb to parse fabric protos (alternatively we could try to use real proto for c) | ||
| - data state : levldb | ||
| - pros: | ||
| + snapshots; | ||
| + batchWrites | ||
| + c++ implementation open source | ||
| - cons: | ||
| + persistence needs syscalls | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the approach to modify Fabric in order to reduce the validation steps?
I think here you mean: design/implement a reduced validation procedure in TLCC -- compared to Fabric's legacy one.