Practice Exams:

Blockchain CBSA – Objectives – Hyperledger Part 2

  1. Hyperledger Fabric Whiteboard Discussion

Okay I’m over here at Aww Amp. com. This is a free whiteboard solution and what I’m going to do is just walk you through the steps through a transaction because I think it’s important to talk about some of the node types, the peers, but also how the transactions occur. So I did a quick little diagram and I have my MSP and the CA up here.

The MSP is the membership service provider and the CA is a certificate authority. We have our client application here as well and remember that the client app is going to utilize the SDK APIs that are required and will have its own set of keys and certificates as well. We have the order nodes. Now the orderer nodes remember do what they’re going to facilitate the processing of transactions and place them pretty much in a FIFO approach first in first out approach to be written to the database. Now we have over here different peers.

I won’t be too specific on which one is what. It doesn’t sort of matter per se but generally they’re going to be committing peers or they’re going to be endorsing peers and you may want to have as many or as little as possible depends on your requirements when you’re setting up your blockchain services. Now another thing that might be recommended is you may want to have a secondary MSP as well. So you might want to draw one in over here for example and I’ll just do that quickly here and we’ll just call this MSP as well. Number two just in case, in case this goes down then we have an alternate that can manage the certificates.

When it comes to basically facilitating a transaction the first thing that happens is that the applications, all the peers here they have to basically enroll with the MSP. Now the MSP is going to course provide them the transaction certificates, the Es Certs which are the enrollment certificates. That’s really the main thing that is going to do is validate certificates and provide certificates as well. The second thing we want to consider is the and I’m going to change my pen color here.

Let’s change it to blue actually blue, I got blue already. Let’s change it to purple. So the first thing that really happens is right here the client app is going to submit a proposal and this proposal again this is a little bit hard to deal with as far as the mouse here but basically the proposal is going to be sent. The second thing that’s going to happen is that these endorsing peers, let’s say these are endorsing peers here are going to get this and basically look at the proposal and say is this valid or is it not?

Also too as part of the endorser’s role is going to look at the policies that are in place. So if you require two nodes or four nodes to endorse the transaction then you need to have four nodes to basically endorse and when I say nodes, I’m really saying peers. But basically you need four peers to endorse that transaction proposal after it is endorsed. What’s going to happen is that the application is going to submit that proposal back to essentially the ordering service.

So it’ll go back here. Once this goes back, what actually happens in the background is once it’s endorsed, it’s going to have that sent. That’s really the second thing. And then the third thing that occur is that it will be sent back from the client app to the ordering nodes, basically saying it’s been endorsed. Basically it’s similar to you going to a notary saying I need my papers endorsed, that I am who I am.

Once you get that stamp saying that the notary says you’re good, you go send back that transaction and then the order, what it’s going to do is take that transaction and then put them into blocks. That’s going to be the fourth thing here. Now, I’m not going to attempt to do blocks here very well, but again, I’ll put that in a different color.

And these are the blocks that will be put together, assembled, and then what will happen? They’ll be written to the blockchain here. And again, a little hard to see, but basically you have your blocks. They’re going to be assembled into a transaction, which is going to be written to the blockchain. Now remember that the database and the transaction logs are going to be either, let’s see, level DB or coach DB. So just remember that in the back of your head because we’ll be talking about that as well. The next thing that’s going to happen after it’s packaged up and everything looks good is that the orderer will then place those blocks on the blockchain and send them to all the peers that are on that channel.

Now remember, on a hyperledger blockchain you could have one channel or 30, whatever you want to set up. And you may have, for example, let me get a different color, yellow. You may have, for example, these notes here, let’s say on one channel and then the other tiers might be, or nodes I should say will be on another channel. So we could change the color just to identify this. And so what we have here is, let’s say this is channel one and this is channel two. What we’ve done, let’s say at a high level, is we created two channels where essentially these nodes are going to be able to endorse the transactions. So the peers and nodes, when I say nodes and peers are sort of interchangeable in that sense, we have committing peers and endorsing peers, but they’re really nodes is what they are and these peers are going to endorse that transaction.

Now if you have two different channels, only the peers that are here will be able to see the transactions that occur here. They can’t see what happens over here and let me get my pen again. So basically this channel is separate and this channel is separate. These peers have access to the transactions submitted to these peers and this channel is only for these peers. Again, pretty straightforward from that perspective. Now the peers will then commit them to the ledger. Now we also know, and let me get my little text box here, we know that channels, they can have essentially separate and they do have actually separate blockchain services. And I’m trying to make sure this keeps on the screen here, basically they can be separate blockchain services.

So basically you have separate database and log, for example. Now, with that said, that’s essentially at a high level, how this all works. Basically step, the first thing that really has to happen is that the peers have to be enrolled. So basically the certificates have to be dished out. You need your t shirts, your e certs. The second thing that really happens, but the first step from an application standpoint, once the peers are good to go, is that the application is going to submit the proposal. The second thing is the endorsement peers are going to endorse it or not. The third thing that’s going to happen is that the application will get it back and then submit it back to the order.

Service nodes, or the orders as are also known, once the orderers get it, it’s going to place it up and basically get it ready to put them in as blocks into the database. Once that occurs, the orderer will then deliver the blocks to all the peers essentially that are on the channel. And so you’re effectively having a separate blockchain here and a separate blockchain here as well, and they’ll commit them to the appropriate ledgers. That’s essentially a transaction 101 view. I hope that helped out and Craig turn things up. There’s essentially five or six steps, depending on how you look at it, to set up a transaction in hyperledger fabric. Let’s go ahead and move on to the next module.

  1. Whiteboard – Hyperledger Fabric Channels

Well, let’s talk about what a channel is. And essentially a channel is probably perhaps one of the more useful features that enterprises really appreciate with hyperledger fabric. Now think of a hyperledger fabric channel as essentially a private subnet. This is going to be sort of like a tunnel subnet, however you want to look at it, basically it’s a private communication space. With that said, if we have a blockchain here with, let’s say right here, let me get my pen with let’s say 12345 and then seven total peers, what happens if I don’t want to have every peer participate in a blockchain transaction for whatever reason, I want to have privacy.

Well, to do that, I simply would create a channel. In this case here, I would just simply create a channel between, let’s say this pier and this pier. Now as part of this channel, we’re going to have our own little ledger and transaction logs as well. Now when we do that, it’s going to communicate only between these two peers. Basically when we do this, of course, for each member of a channel, we want to course determine a leading peer generally.

And a leading peer of course, is what that’s going to determine how the communication works, how the ordering service is going to behave on behalf of the member. If there’s no leader identified, then the course is an algorithm already built in to determine the workflow. But basically we want to think of a channel as nothing more than a private subnet. And what is a subnet in networking? Basically it’s nothing more than a private address space.

With that said, this is a channel. But one more note, if for some reason we want to have this note and just give you another example, let’s say this is A-B-C and D. Now let’s say we have specific transactions that are between A and B, but then we have other transactions that are between all the other members. So basically this transaction will be propagated to all the peers. So we could specify the type of transactions that are going to be private and the ones that may not be so private.

And when we do that, we want to just realize that we want to specify the peers that can join the channel. And basically when we create a channel, it’s going to be two or more peers. And that channel of course, is going to have what, a separate ledger, a separate log? Also two, we want to specify an anchor peer.

We want to specify a leading peer generally so that the gossip protocol can communicate in an appropriate manner. With that said, when we create the ledger, it is going to create a genesis block. So a block zero will be for this ledger as well. And then if we have the other peers and notes that communicate in a transaction with A and B, they’ll have access to the ledger that’s available to everyone else. Or what we could do is create for example, C and B can have their own essentially channel. And again, we have a lot of flexibility with how we set up channels and hyper ledger fabric. Let’s go ahead and move on.