Date   

Re: Single Channel BC network. Is it a good approach?

Mahwish Anwar
 

Been reading the comments.
2 channels would make sense when, for example:

Org 1-5 keep the same data. They will see chain code 1, and ledger 1. Let's say servers. 
Majority orgs approve, meaning 3 would endorse.

Org 6-7 for example, are on channel 2. They will see chain code 2, and ledger 2. Let's say data-generating devices.
Majority orgs approve, meaning 2 would endorse.

Is there a way to link both ledgers? for example, some data from ledger 2 becomes input (transaction) for org 1?


Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 05/07/2021 11:00am-12:00pm #cal-reminder

fabric@lists.hyperledger.org Calendar <fabric@...>
 

Reminder: Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When: Friday, 7 May 2021, 11:00am to 12:00pm, (GMT-04:00) America/New York

Where:https://zoom.us/my/hyperledger.community.backup?pwd=dkJKdHRlc3dNZEdKR1JYdW40R2pDUT09

View Event

Organizer: Pam Andrejko pama@...

Description: Documentation workgroup call.
Agenda, minutes and recordings :https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

Join Zoom Meeting
https://zoom.us/j/6223336701?pwd=dkJKdHRlc3dNZEdKR1JYdW40R2pDUT09
 
Meeting ID: 622 333 6701
Passcode: 475869


Re: Single Channel BC network. Is it a good approach?

Todd Little
 

Hi Nikos,

 

Remember that a channel basically represents a single ledger.  So if  you only need a single ledger  you only need a single channel. 

 

Regarding your comment “use the most (if not all) distributed peers of the network in order to endorse the transaction”, who endorses and how many endorsers are needed is a matter of trust.  The more endorsing organizations the more likelihood the transaction results can be trusted.  The basic idea is that you want organizations to endorse and not just any peers because if an organization has been compromised or acting in a Byzantine manner, then it’s likely all of its peers have been compromised.  For an attacker to compromise a transaction, it would need to compromised enough organizations to meet the endorsement policy.  With 10 organizations and an endorsement policy requiring 4 organization endorse, an attacker would need compromise at least 4 organizations in the network, something that would likely be very difficult to accomplish.  If you’re super paranoid, then make the endorsement policy requiring 9 of the 10 organizations to endorse, or even 10 out of 10 (although be careful with N out of N endorsement policies, especially with config changes as removing an organization maybe difficult if it has disappeared.)

 

The initiator of a transaction is always known as is all the endorsers as they all sign the proposal.  Why do you want to hide who proposed it?  Also, what exactly do you mean by “without knowing the SC of organization A(who proposed it)”?  The smart  contracts are installed and instantiated on some of the peers, not necessarily all of the peers.  However all the peers on the channel will receive the ledger, even if they don’t have the smart contract installed and instantiated.

 

Maybe a better description of what you are trying to achieve would help with recommendations.

 

-tl

 

From: fabric@... <fabric@...> On Behalf Of Nikos Karamolegkos
Sent: Thursday, May 6, 2021 4:37 AM
To: fabric@...
Subject: [Hyperledger Fabric] Single Channel BC network. Is it a good approach?

 

I am thinking of building an BC network with N organization in one common channel. Each organization would have M peers. The transaction endorsement policy will be based in a number P of endorsements. P will be greater than M so that a transaction could not be approved by a single organization. Also P may be just a bit smaller than N*M in order to minimize the risk of malicious peer nodes  in an organization and at the same time for diversity. It is common logic that all these N organization will share the same ledger and the same chaincode (smart contracts). Firstly, can I have multiple chaincodes in a single channel? Secondly (and not so important), ideally I would like the peers of the organization B,C,D to execute the transaction without knowing the SC of organization A(who proposed it). I assume that is impossible. Is this true? I have read about private data collection concept and I conclude that such a thing is not supported.

In other words, I would like to use the SC to evaluate and enforce the rules of transactions and at the same time to use the most (if not all) distributed peers of the network in order to endorse the transaction (hence the idea with the single channel). Whereas I can not that in a private way is a plus, if not I have to sacrifice it.

 

-- 
Nikos Karamolegkos
R & D engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)


Re: Single Channel BC network. Is it a good approach?

Nikos Karamolegkos <nkaram@...>
 

Really thank you all. So the paragraph Endorsement Policy here is wrong (I have seen it to other links too)?

As far as for the privacy, I understand that in a single channel network is there is no way to endorse and execute transactions in private. So i have to sacrifice it or change the BC network architecture (e.g different channels as the fabric logic requires)


Re: Single Channel BC network. Is it a good approach?

David Enyeart
 

Endorsements are fundamentally based on the number of endorsing organizations, not the number of endorsing peers, since ultimately you want to ensure that organizations have executed and signed off on a transaction. For example you may require that a regulator has signed off on a transaction, but it doesn't really matter which peer within the regulator actually signs off. You can refer to https://hyperledger-fabric.readthedocs.io/en/latest/endorsement-policies.html for more info.

All the endorsing peers will execute the smart contract, so I'm not following how you'd plan on keeping the smart contract private to a single organization. Starting in v2.x you actually can have each organization run different smart contracts, but typically that is to enable each organization to optionally add their own validations which extend some common and agreed upon smart contract logic. If you are trying to keep those 'extensions' private to each org, then you can do that. So long as the endorsements result in the same exact transaction results including read-write sets, and all the required organizations sign it, then it doesn't matter if the actual smart contract logic is identical on each organization's peers.


Dave Enyeart
IBM Blockchain
enyeart@...

"Nikos Karamolegkos" ---05/06/2021 08:31:34 AM---Sorry, I used SC for smart-contract. So "A majority of peers in the channel must endorse transaction

From: "Nikos Karamolegkos" <nkaram@...>
To: David Enyeart <enyeart@...>
Cc: fabric@...
Date: 05/06/2021 08:31 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Single Channel BC network. Is it a good approach?
Sent by: fabric@...





Sorry, I used SC for smart-contract. So "A majority of peers in the channel must endorse transactions of a specific type" means that if one of M endorser peers endorse the transaction in each organization of N. Then if N/2 + 1 orgs ‍‍‍‍‍‍‍ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd

Sorry, I used SC for smart-contract.

So "A majority of peers in the channel must endorse transactions of a specific type" means that if one of M endorser peers endorse the transaction in each organization of N. Then if N/2 + 1 orgs agree the transaction is approved? Why I can not have M endorsers peers in each organization and set a rule like "at least M-2 peers of A, B, C, D, E, F, G (of N orgs) must endorse transactions of type V" ?

On 6/5/21 2:36 μ.μ., David Enyeart wrote:

      I don't understand the last question... what is SC in this context?
--
Nikos Karamolegkos
R & D engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)





Re: Single Channel BC network. Is it a good approach?

Nikhil Gupta
 

Hi NIkos,

Endorsement policies are based on organizations only, not the number of peers. Once an organization is added to the endorsement policy, they only need to deploy one peer to endorse a transaction, though multiple peers are recommended for high availability.

Nik

On Thu, May 6, 2021 at 9:10 AM Nikos Karamolegkos <nkaram@...> wrote:
Also, I am a bit confused with this "Endorsement policy is based on the number of endorsing peers from unique organizations, not the total number peers. For example if you have 10 orgs with 3 peers each, and you need a majority to approve, you'd need at least 6 peers from different organizations to approve." statement.
Can you analyze it more?


Re: Single Channel BC network. Is it a good approach?

Nikos Karamolegkos <nkaram@...>
 

Also, I am a bit confused with this "Endorsement policy is based on the number of endorsing peers from unique organizations, not the total number peers. For example if you have 10 orgs with 3 peers each, and you need a majority to approve, you'd need at least 6 peers from different organizations to approve." statement.
Can you analyze it more?


Different World States DB as a mechanism for data isolation #fabric-questions

Santiago Figueroa Lorenzo
 

Hi, I am using cross-chaincode to take advantage of the fact that I can store data in isolation in different world states. However, I am not clear whether storing in different world states offers advantages with respect to data security over other mechanisms such as private data collections or creation of multiple channels. 

Is there any benchmark that compares these three features?




Re: Single Channel BC network. Is it a good approach?

Nikos Karamolegkos <nkaram@...>
 

Sorry, I used SC for smart-contract.

So "A majority of peers in the channel must endorse transactions of a specific type" means that if one of M endorser peers endorse the transaction in each organization of N. Then if N/2 + 1 orgs agree the transaction is approved? Why I can not have M endorsers peers in each organization and set a rule like "at least M-2 peers of A, B, C, D, E, F, G (of N orgs) must endorse transactions of type V" ?

On 6/5/21 2:36 μ.μ., David Enyeart wrote:
I don't understand the last question... what is SC in this context?
-- 
Nikos Karamolegkos
R & D engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)


Re: Single Channel BC network. Is it a good approach?

David Enyeart
 

Endorsement policy is based on the number of endorsing peers from unique organizations, not the total number peers. For example if you have 10 orgs with 3 peers each, and you need a majority to approve, you'd need at least 6 peers from different organizations to approve. In other scenarios, some organizations are more trusted than other organizations (e.g. regulator, auditor, network founder), so you may only require endorsement from a peer of that organization plus a peer of the transacting organization.

Yes, a channel can have multiple chaincodes deployed. A single channel is a viable deployment, just be aware that all members of the channel will be able to see all data on the channel. Sometimes you'll want that, sometimes you won't. You'd want to introduce private data collections if you want to hide some of the channel data but not the fact that organizations are transacting (with the option to disclose private data in the future and prove the legitimacy of it against the on-chain hashes). You'd want to introduce additional channels if you want complete privacy between sets of transacting organizations.

I don't understand the last question... what is SC in this context?


Dave Enyeart

"Nikos Karamolegkos" ---05/06/2021 06:37:28 AM---I am thinking of building an BC network with N organization in one common channel. Each organizatio

From: "Nikos Karamolegkos" <nkaram@...>
To: fabric@...
Date: 05/06/2021 06:37 AM
Subject: [EXTERNAL] [Hyperledger Fabric] Single Channel BC network. Is it a good approach?
Sent by: fabric@...





I am thinking of building an BC network with N organization in one common channel. Each organization would have M peers. The transaction endorsement policy will be based in a number P of endorsements. P will be greater than M so that a transaction ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd

I am thinking of building an BC network with N organization in one common channel. Each organization would have M peers. The transaction endorsement policy will be based in a number P of endorsements. P will be greater than M so that a transaction could not be approved by a single organization. Also P may be just a bit smaller than N*M in order to minimize the risk of malicious peer nodes  in an organization and at the same time for diversity. It is common logic that all these N organization will share the same ledger and the same chaincode (smart contracts). Firstly, can I have multiple chaincodes in a single channel? Secondly (and not so important), ideally I would like the peers of the organization B,C,D to execute the transaction without knowing the SC of organization A(who proposed it). I assume that is impossible. Is this true? I have read about private data collection concept and I conclude that such a thing is not supported.

In other words, I would like to use the SC to evaluate and enforce the rules of transactions and at the same time to use the most (if not all) distributed peers of the network in order to endorse the transaction (hence the idea with the single channel). Whereas I can not that in a private way is a plus, if not I have to sacrifice it.

--
Nikos Karamolegkos
R & D engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)





Single Channel BC network. Is it a good approach?

Nikos Karamolegkos <nkaram@...>
 

I am thinking of building an BC network with N organization in one common channel. Each organization would have M peers. The transaction endorsement policy will be based in a number P of endorsements. P will be greater than M so that a transaction could not be approved by a single organization. Also P may be just a bit smaller than N*M in order to minimize the risk of malicious peer nodes  in an organization and at the same time for diversity. It is common logic that all these N organization will share the same ledger and the same chaincode (smart contracts). Firstly, can I have multiple chaincodes in a single channel? Secondly (and not so important), ideally I would like the peers of the organization B,C,D to execute the transaction without knowing the SC of organization A(who proposed it). I assume that is impossible. Is this true? I have read about private data collection concept and I conclude that such a thing is not supported.

In other words, I would like to use the SC to evaluate and enforce the rules of transactions and at the same time to use the most (if not all) distributed peers of the network in order to endorse the transaction (hence the idea with the single channel). Whereas I can not that in a private way is a plus, if not I have to sacrifice it.


-- 
Nikos Karamolegkos
R & D engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)


Re: [External] : [Hyperledger Fabric] IoT with frequent data and possibly incorrect data sometimes

Mahwish Anwar
 

Thanks for all replies. 
So, we are saying that, 

ED register via REST. These ED can be same or different orgs.
ED send messages via REST with their tokens. I am using JWT. Any better option? This token is a private key for the ED.

I am doing the same to register users for an org.

Back to my question, so theoretically I can assume user or ED - depending on the scenario. Nothing changes in terms of implementation?
--
Regards,
Mahwish Anwar.


Re: Update expired orderer org admin certificate and orderer certs #fabric-questions #fabric-orderer #signcerts #fabric

Mattia Bolzonella
 

Hi, I'm working on the solution proposed, now I'm using a cli peer to do my channel update operations, before doing that I set the following variables in the peer cli:

CORE_PEER_LOCALMSPID=MyOrderersMSP

CORE_PEER_TLS_CERT_FILE=Expired TSL Orderer cert

CORE_PEER_TLS_KEY_FILE=Expired TSL Orderer key

CORE_PEER_TLS_ROOTCERT_FILE=Not expired TLS CA root cert for MyOrdererMSP

CORE_PEER_MSPCONFIGPATH=Expired msp MyOrdererMSP (all expired certs of orderers and admin org)

 

Now when i run the following command: 

peer channel fetch config crypto/sys-channel-with-tls-expired-tesst.pb -o orderer0.obscureddomain.com:7050  -c sys-channel --tls --cafile  $ORDERER_TLS_CA_CERT --tlsHandshakeTimeShift 1240h

(the certs expired 100h ago)

I get the error:

ERRO 001 Cannot run peer because error when setting up MSP of type bccsp from directory path/to/orderMSP_admin/msp: signing identity expired 107h4m58.724186994s ago

 


So, if I cannot do a fetch of the channel config (I managed to do it with a new admin cert), ho can i do the channel update? Because i think I need the expired orderer admin MSP in order to sign the channel update configuration, or am I missing something?

 

 


Re: [External] : [Hyperledger Fabric] IoT with frequent data and possibly incorrect data sometimes

Mark Rakhmilevich
 

Hi Nikos,

   Yes, that’s one common approach we’ve seen.  The EDs don’t have to belong to the same organization, they could send their data to different aggregators if desired based on some contractual agreements, geolocation, etc..  The point is that a Fabric org with an MSPId can register and enroll client orgs, which then get a unique certificate – with the MSPId of the issuing org but the unique enrollment name in CN field.  Their transaction is then signed by that cert and the chaincode can extract the unique CN to apply any relevant access rules or other business logic.

 

Best Regards,

   Mark

 

From: fabric@... <fabric@...> On Behalf Of Nikos Karamolegkos
Sent: Wednesday, May 5, 2021 2:13 AM
To: fabric@...
Subject: Re: [External] : [Hyperledger Fabric] IoT with frequent data and possibly incorrect data sometimes

 

So mark in order to recap, you propose each ED to be a different user which send data via REST to an aggregator (i.e a BC client) who acts as intermediate to match the data from each ED to the respective BC user? Are this EDs belong to the same organization in order use the same aggregator?


Re: 回复: missing tags for go chaincode developement dependencies

Matthew Sykes
 

We have chosen not to add version tags to the modules because they tend to evolve compatibly and are mostly disconnected from the fabric releases. For example, if you pull any version of fabric-chaincode-go, it should work with any version of fabric. A similar statement can be made for the protocol buffers (barring additions made to support recent versions).

If we started adding tags that reflected the fabric versions, this would break the semantic versioning and require consumers to change their import paths to reflect `v2` of Fabric. If we started doing proper semantic versioning, we would end up bumping minor versions regularly and it would skew heavily from the released versions. Instead, we've chosen to stay with v0 semantics.

To make a long story short, the module versioning is disjoint from the fabric versioning and in place of tags we've used branches that map to the fabric version. When you `go get` your module, you can use `@branch` to pull the latest from the branch. The `go.mod` will then be updated with the commit timestamp and hash of the repository hosting the module. We are not the only ones to do this. (See golang.org/x/{crypto,sync,sys,time.tools}).

It does seem we've messed up with fabric-chaincode-go, however, since we don't have any branches there. That should probably be fixed for release-2.2+.

On Tue, May 4, 2021 at 9:20 PM david liu <david-khala@...> wrote:

Hi Fabric maintainers,

Is there any updates on this? I am happy to hear any consideration on why not pushing named git tag to fabric-chaincode-go and fabric-protos-go.

If it is intended and designed as a WON’T DO, an clarification is welcomed to help us feedback to community members.

 

发件人: 刘 宇翔
发送时间: 2021420 21:05
收件人: fabric@...; twg-china@...
主题: missing tags for go chaincode developement dependencies

 

Hi Fabric maintainers, 


As some community member and me found for a while, 

Both following repositories have no git tags yet pushed to Github

github.com/hyperledger/fabric-chaincode-go
github.com/hyperledger/fabric-protos-go

This will introduce a result that fabric go chaincode developer have to suffer from go.mod dependency versioning issue. such as 

v0.0.0-20200511190512-bcfeb58dd83a
 
Each time we get lost in what 20200511190512 indicates. We have to guess whether it is 2.2.x or 2.3.x
 
Can you consider give tags to them, in a similar way in fabric itself. then we could pin to use v2.2.x as dependency version.


Best Regards,

David Liu



--
Matthew Sykes
matthew.sykes@...


Re: Two peers disagree about transaction validity

Carlo Innocenti
 

Thanks Dave.
No CouchDB in the picture here - as you guessed; and SQLite/BDB in Oracle Blockchain Platform behaves the same way as GoLevelDB does when it comes to commits. So, I suppose we are left with the option of a disk or network error.
Thanks for the help,
Minollo

On 5/5/21 3:17 PM, David Enyeart wrote:

The only time we've seen something like this was back when the community CouchDB image had a bad configuration setting:
delayed_commits = true

With that configuration, it was possible for CouchDB to not fsync a write to disk in crash scenarios. Then in a subsequent transaction, since there would be different versions in state db for a key, it is possible for a committing peer to disagree with an endorsed readset version and invalidate the transaction, while peers that endorsed the transaction validate the transaction. So the first thing to check is whether the peers have ever used a CouchDB image with the bad configuration (if the delayed_commits setting is omitted from CouchDB config, then it defaults to false and there should be no such issue). We don't see the issue when using CouchDB without the bad config, or with goleveldb, and haven't tested with SQLite (I assume you are asking about a peer in the Oracle blockchain platform).

To resolve, you'd have to compare with other peers (or bring up a new peer) to determine which of the existing peers is in bad state and needs to be retired. The block commit hash that is logged upon every block commit (at least if you joined the channel on v1.4.2 or later) can help identify which peer is in bad state and needs to be retired.


Dave Enyeart

"Carlo Innocenti" ---05/05/2021 02:02:32 PM---Hi all. I have an HLF network which has ended up in a situation where the

From: "Carlo Innocenti" <minollo@...>
To: fabric@...
Date: 05/05/2021 02:02 PM
Subject: [EXTERNAL] [Hyperledger Fabric] Two peers disagree about transaction validity
Sent by: fabric@...





Hi all.

I have an HLF network which has ended up in a situation where the
stateDB of two virtually identical peers (same channel, same chaincode)
diverged; digging into it, the problem is that a txn in a past block was
flagged as valid by peer0, but invalid (mvcc_read_conflict) by peer1.
It's the only txn in the block; the txn sets a couple of K/V pairs in a
PDC (not accessible by either peer). I guess the error is triggered by
validateNsHashedReadSets() check, but that's entirely based on public
ledger data (hashes), and I can't think of any situation where this
could happen (other than disk or network errors).
Has anyone seen a similar problem? Any suggestion?

I suppose the only way to recover from this situation is to wipe out
both peers' ledgers and stateDBs and force them to pull the blocks again
from the ordering service (going through validation again) - correct?

Thanks,
Minollo











Re: Two peers disagree about transaction validity

David Enyeart
 

The only time we've seen something like this was back when the community CouchDB image had a bad configuration setting:
delayed_commits = true

With that configuration, it was possible for CouchDB to not fsync a write to disk in crash scenarios. Then in a subsequent transaction, since there would be different versions in state db for a key, it is possible for a committing peer to disagree with an endorsed readset version and invalidate the transaction, while peers that endorsed the transaction validate the transaction. So the first thing to check is whether the peers have ever used a CouchDB image with the bad configuration (if the delayed_commits setting is omitted from CouchDB config, then it defaults to false and there should be no such issue). We don't see the issue when using CouchDB without the bad config, or with goleveldb, and haven't tested with SQLite (I assume you are asking about a peer in the Oracle blockchain platform).

To resolve, you'd have to compare with other peers (or bring up a new peer) to determine which of the existing peers is in bad state and needs to be retired. The block commit hash that is logged upon every block commit (at least if you joined the channel on v1.4.2 or later) can help identify which peer is in bad state and needs to be retired.


Dave Enyeart

"Carlo Innocenti" ---05/05/2021 02:02:32 PM---Hi all. I have an HLF network which has ended up in a situation where the

From: "Carlo Innocenti" <minollo@...>
To: fabric@...
Date: 05/05/2021 02:02 PM
Subject: [EXTERNAL] [Hyperledger Fabric] Two peers disagree about transaction validity
Sent by: fabric@...





Hi all.

I have an HLF network which has ended up in a situation where the
stateDB of two virtually identical peers (same channel, same chaincode)
diverged; digging into it, the problem is that a txn in a past block was
flagged as valid by peer0, but invalid (mvcc_read_conflict) by peer1.
It's the only txn in the block; the txn sets a couple of K/V pairs in a
PDC (not accessible by either peer). I guess the error is triggered by
validateNsHashedReadSets() check, but that's entirely based on public
ledger data (hashes), and I can't think of any situation where this
could happen (other than disk or network errors).
Has anyone seen a similar problem? Any suggestion?

I suppose the only way to recover from this situation is to wipe out
both peers' ledgers and stateDBs and force them to pull the blocks again
from the ordering service (going through validation again) - correct?

Thanks,
Minollo










Two peers disagree about transaction validity

Carlo Innocenti
 

Hi all.

I have an HLF network which has ended up in a situation where the stateDB of two virtually identical peers (same channel, same chaincode) diverged; digging into it, the problem is that a txn in a past block was flagged as valid by peer0, but invalid (mvcc_read_conflict) by peer1. It's the only txn in the block; the txn sets a couple of K/V pairs in a PDC (not accessible by either peer). I guess the error is triggered by validateNsHashedReadSets() check, but that's entirely based on public ledger data (hashes), and I can't think of any situation where this could happen (other than disk or network errors).
Has anyone seen a similar problem? Any suggestion?

I suppose the only way to recover from this situation is to wipe out both peers' ledgers and stateDBs and force them to pull the blocks again from the ordering service (going through validation again) - correct?

Thanks,
Minollo


Re: Purge Private Data - by individual transaction - on trigger

David Enyeart
 

The only mention of the "private data store" aka "private writeset storage" is this sentence:

"Upon validation/commit, the private data is moved to their copy of the private state database and private writeset storage. The private data is then deleted from the transient data store."

Basically, it is a data structure of private data organized by block (similar to the public write sets in the blockchain), that is used to feed other peers that are members of the collection when they are catching up the block height. It is not documented further since it is an implementation detail abstracted from user, but will become more important to document once the purge feature gets implemented.


Dave Enyeart

"Simeon MacMillen" ---05/05/2021 10:50:22 AM---Hi David, In your original email, you mentioned a private data store in addition

From: "Simeon MacMillen" <industrial_eng@...>
To: David Enyeart <enyeart@...>
Cc: fabric <fabric@...>
Date: 05/05/2021 10:50 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Purge Private Data - by individual transaction - on trigger
Sent by: fabric@...





Hi David,

In your original email, you mentioned a private data store in addition
to the transient and private [world] state.  Is the "private data store"
a separate, append-only ledger used with collections?

If there is any documentation on this, I would be interested to learn
more.  (I tried searching through the documentation but haven't located
any references to this term.  The Private Data page only mentions the
state database and transient store.)


Regards,
Simeon MacMillen

Ref:
https://hyperledger-fabric.readthedocs.io/en/release-2.3/private-data/private-data.html 
Ref:
https://hyperledger-fabric.readthedocs.io/en/release-2.3/private-data-arch.html 



On 5/4/21 7:12 AM, David Enyeart wrote:

        Note that deletePrivateData only deletes from private state.
The private data remains in the private data store (committed data) and
transient store (uncommitted data) for other peers that may be running
behind to pull.










Re: Update expired orderer org admin certificate and orderer certs #fabric-questions #fabric-orderer #signcerts #fabric

Chris Gabriel <alaskadd@...>
 

Yes, that is it.  You got it!

On May 5, 2021, at 10:50 AM, Mattia Bolzonella <mattia.bolzonella@...> wrote:

Just to be clear about what you told me to replace in my system channel configuration, sorry but I want to be 100% sure about what I'm doing:
My json looks like this:

"channel_group": {
    "groups": {
      "Application": { <- MAIN SECTION APPLICATION
        "groups": {
          "OrderersMSP": {
            "groups": {},
            "mod_policy""Admins",
            "policies": {
              "Admins": {
                "mod_policy""Admins",
               // other sections
              "Readers": {
              },
              "Writers": {
            },
            "values": { 
              "MSP": {
                "mod_policy""Admins",
                "value": {
                  "config": {
                    "admins": [ 
                      "EXPIRED CERT BASE64" <--- TO REPLACERIGHT?
                     ],
                    "crypto_config": {
                      "identity_identifier_hash_function""SHA256",
                      "signature_hash_family""SHA2"
                    },
                    "fabric_node_ous": {
                      "admin_ou_identifier": {
                        "certificate""NOT EXPIRED",
                        "organizational_unit_identifier""admin"
                      },
                      "client_ou_identifier": {
                        "certificate""SAME as admin_ou_identifier",
                        "organizational_unit_identifier""client"
                      },
                      "enable"true,
                      "orderer_ou_identifier": {
                        "certificate""SAME as previous",
                        "organizational_unit_identifier""orderer"
                      },
                      "peer_ou_identifier": {
                        "certificate""same as previuos",
                        "organizational_unit_identifier""peer"
                      }
                    },
                    .... other sections
                 } 
                }
            }
        }
    }, // End of Application section
    "Consortiums": { <- MAIN SECTION CONSORTIUM
        "groups": {
          "SampleConsortium": {
            "groups": {
              "IfinPeerMSP": {
                "groups": {},
                "mod_policy""Admins",
                "policies": {
                }, // other sections
                "values": {
                  "MSP": {
                    "mod_policy""Admins",
                    "value": {
                      "config": {
                        "admins": [
                          "EXPIRED" <- TO REPLACE?
                        ],
                        "crypto_config": {
                          "identity_identifier_hash_function""SHA256",
                          "signature_hash_family""SHA2"
                        },
                        "fabric_node_ous": {
                          "admin_ou_identifier": {
                            "certificate""NOT Expired",
                            "organizational_unit_identifier""admin"
                          },
                          "client_ou_identifier"
                            "certificate": "NOT Expired",
                            "organizational_unit_identifier""client"
                          },
                          "enable"true,
                          "orderer_ou_identifier": {
                            "certificate""NOT Expired",
                            "organizational_unit_identifier""orderer"
                          },
                          "peer_ou_identifier": {
                            "certificate""NOT Expired",
                            "organizational_unit_identifier""peer"
                          }
                        },
                       // others
                      },
                      "type"0
                    },
                  }
                },
               
              }
            },
        },
      
      },
    // ORDERER SECTION WILL BE MODIFIED IN ANOTHER TRANSACTION


Thank you again,

Mattia
 

1201 - 1220 of 11120