| Table of Contents |
|---|
Key Points
...
Potential Value Opportunities
Potential Challenges
Dealing with expired certs is indeed difficult. Use a blockchain service that has experience with preventing and resolving cert expirations.
How to manage key rotations to make ledger queries easier
Dave >>
I’ll also say that a cert rotation test using a single orderer node is not representative of production environments. Orderer nodes use the certs in the consenter section to identify each other. If there is only one orderer node it doesn’t have any other orderer nodes to identify! Everything else validates against the org-level issuing CAs configured in the channel MSPs, and since both the old and new certs were issued by the CAs configured in the channel MSPs, they are all still valid.
Baohua >>
It's normal as the old certs are still considered valid by the network.
When it's expired, the transactions signed with old credentials will be blocked.
On Tue, Mar 28, 2023 at 6:03 PM Vijaya Bhaskar <acvbhaskar94@gmail.com> wrote:
Hi All,
I am trying to renew the certificates (identity and tls) of the network.
Following are the steps i have followed.
1)created the network (on kubernetes)
2)executed some transactions and verified it in couch db
3) generated new set of certificates for orderer and peers (i have one orderer and one peer( one peer org))
4) since i have 2 channels , one system channel and one application channel,
a)did a system update (replacing the base64 of newly generated cert in the consenter section) for system channel
b) did another system update for application channel
now, before swapping the new certs, i tried to execute a transaction which went through successfully (the old certs are still not expired).
is this normal or am i missing something?
Rotate MPC shards as an option to Key rotations where feasible
Designing a Smart Contract process where oracles are needed
General idea,
avoid calling directly from the contract ( chaincode ) to an external service
in Fabric, all validator nodes that execute the contract will be calling the oracle first.
If any validator has an environment issue calling the oracle, it will slow overall execution ( approval ) of the contract transaction.
Better idea
1> call the oracle BEFORE submitting the contract transaction request - include any key data from the oracle in the request
all the validators will run faster with lower error risks
2> choreograph the workflow
use a parent ( or first contract ) that
calls the oracle with a single validator and writes the oracle result to the ledger
calls the normal contract transaction request with either the oracle result or a link to the result on the ledger or world state db
Candidate Solutions
Create a Fabric Write and Read channels for better performance, history
Fabric v2+ has 16 possible channels for separated ledgers
The limitations of the system channel have been eliminated
A performance option - create a fast write channel, automatically copy new blocks to a read channel
The write ledger can be shorter using purge and archive
Using block events, copy the latest block and write to the read channel
The read ledger can have more history
Implementing CQRS - command query responsibility segregation
Run GraphQL queries against the read historical ledger for traceability queries ( vs World State queries )
It may be more efficient to ‘replay’ the blocks/transactions rather than use the chaincode APIs. See the sample of how to process all prior blocks/transactions using block events:
https://github.com/hyperledger/fabric-samples/tree/main/off_chain_data
Your block/transaction re-processing could for example write to a new chain. You could write the original state data as well as some of the original transaction metadata to the new chain to preserve as much historical record as possible.
Dealing with expired certs is indeed difficult. I would highly recommend using a blockchain service that has experience with preventing and resolving cert expirations.
Step-by-step guide for Example
...