Using the default configuration I can run all the functions inside the application folder of commercial paper on test-network without any problem

If I edit the default signature policy in the approval and commitment of the chaincode definition i am unable to run the issue.js code without experiencing the service discovery error: 

" Connect to Fabric gateway.

Use network channel: mychannel.

Use org.papernet.commercialpaper smart contract.

Submit commercial paper issue transaction.

2021-03-26T12:05:04.277Z - error: [DiscoveryService]: send[papercontract] - Channel:mychannel received discovery error:failed constructing descriptor for chaincodes:<name:"papercontract" >

Error processing transaction. Error: DiscoveryService: papercontract error: failed constructing descriptor for chaincodes:<name:"papercontract" >

Error: DiscoveryService: papercontract error: failed constructing descriptor for chaincodes:<name:"papercontract" >

    at DiscoveryService.send (/home/sangieri/TestProject/commercial-paper/organization/magnetocorp/application/node_modules/fabric-common/lib/DiscoveryService.js:363:11)

Disconnect from Fabric gateway.

Issue program complete."

 

According to documentation, to edit the signature policy I use the following commands:

peer lifecycle chaincode approveformyorg --orderer localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --signature-policy "OR('Org1.peer', 'Org2.peer')" --name papercontract -v 0 --package-id $PACKAGE_ID --sequence 1 --tls --cafile $ORDERER_CA

peer lifecycle chaincode commit -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --peerAddresses localhost:7051 --tlsRootCertFiles ${PEER0_ORG1_CA} --peerAddresses localhost:9051 --tlsRootCertFiles ${PEER0_ORG2_CA}  --channelID mychannel --signature-policy "OR('Org1.peer', 'Org2.peer')" --name papercontract -v 0 --sequence 1 --tls --cafile $ORDERER_CA --waitForEvent

 

The Anchor peer are set. 

The connectionOptions in issue.js are set properly: 

let connectionOptions = {

            identity: userName,

            wallet: wallet,

            discovery: { enabled:true, asLocalhost: true }

        };

 

Any help? 

 

Hyperledger Fabric Contributor Meeting

When: Every other Wednesday 9am US Eastern, 13:00 UTC (during US daylight savings time)

Where: https ://zoom.us/j/51849 47650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Agendas and Recordings: https://wiki.hyperledger.org/display/fabric/Contributor+Meetings

----------------------------------------------------------------------------------------------------

Agenda for March 17, 2021
There are no big agenda topics scheduled for this week yet.
We will do a quick update on the transition from 'master' to 'main' as the default branch.
Feel free to propose an agenda item!

For March 31 meeting, an update on the Fabric Gateway is planned.

Dear Community members! 

IDEAS Center has been deeply involved in the development of SmartBFT consensus library and would like to propose RFC https://github.com/hyperledger/fabric-rfcs/pull/33 that argues about  the necessity of BFT protocol as part of enterprise grade blockchain platform. The RFC highlights the implementation details and the efforts required to integrate the library into Hyperledger Fabric. Currently we are seeking for engagements with community and in particular with Hyperledger Fabric maintainers in order to identify milestones and formulate reasonable integration strategy and the roadmap, striving to generate small self containable deliverables and providing on going support going forward. 

In the heart of the BFT ordering service for Hyperledger Fabric implementation lies a new consensus library, based on the BFT-Smart protocol, implemented in Go. The library presents APIs suited for permissioned blockchain applications, such as Fabric. It delegates many of the core functions that any such library must use to the application employing it, allowing for maximal flexibility and generality. For example, cryptographic functions, identity management, as well as point to point communication are not embedded but are exposed through proper interfaces, to be implemented by the application using it. This allowed us to re-use some of the sophisticated mechanisms that Fabric already possessed. In the quest to make Fabric a truly end-to-end BFT system, it is not enough to augment the ordering service alone. We took special care to ensure that the peer and the client SDK interact properly with the BFT ordering service.

We chose to implement the BFT-Smart protocol because of its simplicity and elegance. This protocol is significantly simpler than PBFT, because it does not allow for a transaction pipeline. In BFTSmart there is only a single proposed transaction by a given leader at any point in time, which dramatically simplifies the view change sub-protocol. This simplicity greatly increases our confidence in the correctness of the implementation and reduced the effort it took to implement the library. However, these advantages come with a cost – reduced performance. This is especially salient when comparing against the highly mature and optimized etcd/raft library, which uses pipelining extensively. Despite the cost of reduced performance relative to etcd/raft, our implementation exhibits levels of performance that are sufficient for most permissioned blockchain applications: a 7 node BFT ordering service (𝐹 = 2) can support over 2500 TPS in a LAN, and over 1000 TPS in a WAN. These numbers are for a single channel; a Fabric network can scale horizontally by adding channels.

IDEAS Center is managing Smart BFT additional development at the moment and will be responsible for the following support and new Fabric versions compatibility.

https://github.com/SmartBFT-Go/consensus/

https://github.com/SmartBFT-Go/fabric/

Thank you!

Begin forwarded message:

From: Oleg Martianov <olegmartianov@...>

Subject: Smart BFT

Date: 17 September 2020, 17:41:51 GMT+3

To: fabric@...

Hello Team!

SC Idea sponsored and worked on BFT based ordering service - Smart BFT (BYZANTINE FAULT TOLERANCE) library (https://github.com/SmartBFT-Go/consensus/) that has been developed in Open Source by IBM Research lab in the frames of the contract with SC Idea. There is an implementation of Hyperledger Fabric BFT based ordering service which is built on top of Smart BFT library: https://github.com/SmartBFT-Go/fabric/

SC Idea team would like to suggest resources and integrate BFT based ordering service with the Hyperledger Fabric mainstream, we strongly believe that that will significantly improve functionality and provide long long desired  end to end functionality into. In order to initiate the process we would like to propose RFC: https://github.com/hyperledger/fabric-rfcs/pull/33

We would be glad to hear and collect your feedback and really looking forward for fruitful collaboration and maintainers support for our initiative.

Thank you all for the discussion and your input!
I think we now have a high-level understanding of what has to be done, looks simple enough.
Now we start the process of drafting the RFC. It will take some time though, as we want to familiarize ourselves with the internals of the code and the architecture from the Fabric dev point of view, but I hope it will not take more than 3-4 weeks.

--
// Vitalii Demianets @ norbloc AB

On Tue, Feb 23, 2021 at 3:56 PM Manish Sethi <manish.sethi@...> wrote:

In regards to changes to the blockstore, Jason is right that they would be very trivial. For the peers case, this function (https://github.com/hyperledger/fabric/blob/e0253ef0466e4e16364f3d1d3cc537ad9d8b1c4f/common/ledger/blkstorage/blockstore_provider.go#L103) does the job. For the orderer, I would expect an even simpler function (say, "BootstrapFromSnapshotInfo"), as there is nothing much other than the information of the initial state that needs to be supplied.

Thanks,

Manish

On Tue, Feb 23, 2021 at 6:27 AM Vitalii Demianets <vitalii@...> wrote:

Hi Jason!

>
> At a very high level I would suggest.
>
> 1) Modifying the channel participation API to allow specifying a minimum block sequence number to replicate to when joining.
> 2) Add a new pruning function to the channel participation API, which allows reconfiguring that minimum block sequence to a higher sequence number. (Implicitly existing channels would have this sequence set to 0).
> 3) Ignoring the system channel case, instead prereq-ing that channel participation API.
> 4) Introducing a new return status for the Deliver API indicating to peers and clients that the sequence is too old to help users understand why a block request is being rejected.  You'll actually notice that the APi already has the notion of 'OLDEST' as a seek position, as the earliest incarnations of the orderer ledger were RAM based and self-pruning.
>
> Perhaps Manish can weigh in here, but I believe the block storage code was already modified in the peer to handle starting from a later block.  The orderer uses a thin wrapping layer around the peer blockstore, so if not already exposed, exposing it should be relatively simple.

In the above description you do not mention snapshot at all. Do I understand this correctly that we basically do not need any of the peer snapshot functionality (private data collections, stateDB, transactions id list) to start an orderer from an arbitrary block? Basically from your description it follows that we only need to supply the latest config block and the desired start block number, and the orderer will happily start from that info? (given it is able to fetch the start block and other blocks on top of it)
In other words, for orderers the "snapshot" is only the latest config block + start block number?

>
> It might also be helpful to extend the block height discovery in the orderer block replication to discover the lowest block height as well, to detect when an orderer cannot catch up, though I'm not sure I would consider this a blocking item for an initial implementation.

Yes, in our use case the condition that we start the orderer from the block that can be discovered is satisfied, so it makes sense not to add this complexity from the start.
After all if an orderer is not able to find a block, it will be more or less obvious from the logs.

>
> I would argue that the most challenging aspect of implementing pruning at the orderer is an operational one.  The orderers are necessarily not involved in the peer snapshot operations, but, if the orderers prune to a block after the peer's most recent snapshot, onboarding will be broken until peers take a new snapshot.  In the worst case, if the orderer prunes before the blocks are disseminated to the peers, then data loss could occur.
>

We are going to keep several peers as "archiving" nodes, having all the history of blocks from block 0.
Will this solve the issue?

--
// Vitalii Demianets @ norbloc AB

Sorry I misclick the commit link. The correct one is this. Also, this answer made me believe that raspberry pi4 is supported (even at an early stage). I can take a look on the problem but I need some clues. Where should I start?

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