Michael Steiner
Michael Steiner
what we currently have, see #281 for more scalable version ...
Re-open to make MVP decision explicit (even though this is status-quo)
> 2\. Further isolating FPC transactions from Fabric ones The challenge is, though, that current trusted ledger architecture, besides validation of fpc chaincode transaction, relies on proper validation of (a)...
> * A config block is accepted by orderers if and only if it is signed by a quorum of orderers in BFT (or a single one in CFT) >...
Thanks for the clarification. In this case as mentioned in my PS i agree with you that verifying orderer signature for config-update messages should be enough. Given that we need...
> You don't want to implement the Fabric configuration parsing at its whole. It's a deep rabbit hole and you might hurt the earth's inner core. Ultimately, we have to...
With FPC Lite / FPC 1.0 this issue is tabled for now until we come back to future extensions including rollback protection ....
See #273 and #274 for "sibling" features
btw: With externalized validation we have to be quite careful when going to support more than one enclave: Our `__invoke` query also has from a fabric perspective a valid R/W...
On a high-level, the approach is to derive a key from the contract master key and then derive a transaction-encryption-randomness seed from that key using a PRF with the _complete_...