Hyperledger Foundation Fabric, 6 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Accelerated Hyperledger Fabric for Supply Chain Application... Muthukumar Kumaraswamy & Haris Javaid

Description

Accelerated Hyperledger Fabric for Supply Chain Applications in Semiconductor Industry - Muthukumar Kumaraswamy & Haris Javaid, AMD

Efficient supply chain tracking is a key requirement in semiconductor industry to limit the grey market by providing transparency, product provenance and detection of counterfeit units. It is estimated that 7.5 billion dollars are wasted in semiconductor grey market every year. AMD has developed a Hyperledger Fabric based solution for tracking of its supply chain operations to provide increased transparency and product provenance, thus reducing the impact of grey market. Since performance at scale is a key requirement, FPGA based hardware acceleration is used which can enable processing of tens of thousands of transactions per second. This session will discuss production implementation challenges, use of hardware acceleration, automated deployment processes, and a short demo at the end. The audience will leave the session with a better understanding of designing a scalable supply chain application for the semiconductor industry, leveraging hardware acceleration technology.

Sessions Details & Slides (if available): https://sched.co/14H5X
Access All Sessions: https://events.linuxfoundation.org/hyperledger-global-forum/program/schedule/
----
Hyperledger – Open Source Blockchain Technologies

Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use

Discord: https://discord.gg/rVCn4j7UFd
Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory

Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter

Follow-us on Twitter @Hyperledger

Learn about Hyperledger Membership: https://www.hyperledger.org/about/join

#Hyperledger #Blockchain
License
Creative Commons Attribution license (reuse allowed)

A

uh Hello good evening, everyone thanks a lot for coming here. I hope this is the last session for you, so I'm in between your Junior's journey and I apologize.

A

So today we have interesting topic about how we can accelerate hyperledger fabric specifically and what's the use case, we tried using in this case so for every for any blockchain. The business value is very important before going to weathering tax rate and what kind of model we need to choose and other things in AMD. We try to make this journey like five years before when hyperledger dot was nine got released, but that time we don't have like any strong business use case.

A

So we don't proceed further and again we restarted this journey like a year before so we'll walk through like what we have done, quick disclaimer and just a quick update about AMD. As you all know like, we are Semiconductor Company and we have presence in all the possible combinations of acceleration, as well as on Nick, as well as like standard CPUs and refugees, and also our presence is there and all the way from Edge to cloud and even Beyond like most of the satellites, Mass Rover and all the serious and also like AMD presence?

A

Is there all the way from supercomputers to Edge? So with all this presence, it also creates a unique challenge as a company for us the challenges, mainly on this particular area.

A

In the recent covet situation, you might have heard about a chip shortage which created a huge uh publicity for chip companies. So there is a constant news, at least for past six months and specifically for automotive. You might have heard many of the countries like people has to wait for somewhere between, like two months to two quarters to get a new car, and this is the first time in U.S history.

A

The youth Market used car market price Court increased with all these things, since, due to a shortage, we also seeing a different kind of Market happen again. Semiconductor, so that one we generally call as a gray market. So, as you point out few areas here, the huge like a revenue loss also because of this gray Market one is like the current estimations around 75 billion dollar loss because of various High P laws, as well as like tampered chips and other things, and it also have a huge impact to the job market itself.

A

So how we can address this kind of things, so we always constantly look for how we can give a like a proper, workable chip to our customer. There is nothing called tampered and they are not buying it from wrong Source. It's supposed to do what it's supposed to do.

A

So as part of this, we validated, and we worked on various Solutions specifically when it comes to supply chain. In a blockchain use case, we came out with like a three different options: how we can use a blockchain for this to address this name. So one is like a product prominence, as you all know, and we also looked into both tokenization as well as like a POS, is more like a point of sales. So what happened between like a distributor to a real client? Are they getting a real product? What we're shipping?

A

At the end, we started focusing more towards the product provenance, where we have a lot of use cases to address and solve.

A

So when it comes to product provenance, just I want to touch base. This is a very, very abstract, simplified diagram of semiconductor supply chain market. So we have a Dye Bank where the law Fab creates the our product, then we have a packaging. Then we have a separate team for testing and we also have a finished codes from there. There it's getting shipped as well as like it goes to a customer. Sometimes we also have like a contract manufacturer.

A

So it's a huge chain before we are getting that like real customers are getting the finished goods, so in all this whole model. What is happening here is previously. The EMT is a central party where the receiver data they will filter out something and they'll send it to us next process.

A

Similarly, it is happening throughout and AMD is being a central point for all this data management. Now, with blockchain solution, what we are looking is how we can make like a mesh so that all the parties can exchange data freely and again, based on a smart contract. We will get whatever the data what they want.

A

And during this process one more interesting observation: what we made is, since we are making it as a blockchain, the number of transactions, obviously going to increase compared to standard database, where I can have like a really huge table with multiple columns and people can keep on updating. But here everything is based on transactions, so what does it mean? Is we need like high performance blockchain? So one is like a transaction volume is going to be, keep increasing and all my following process.

A

Those also needs like a higher performance because they are looking like something like a database level. It's a kind of performance. We have traditional blockchain, generally Lacks, and also we don't want to create like a very complex architecture with hundreds of nodes. We also make it full process simplified.

A

So this is the time we are looking to various Solutions. What is available to Market, which can address some of our future needs. So, while doing a research, what I noticed is within aimed itself one of our researcher done some kind of acceleration, blockchain use case. So let me invite Harris to proceed the next steps. Thank you.

B

B

So um I'm gonna be a bit more technical than muthu because he was exploring the business use case, and why do we uh wanted to go into the blocks in space and the supply chain and product provenance? uh uh I'm gonna be a little bit more technical, so before I go into the details, just to give you a quick um recap of how transactions flow through a hyperledger fabric Network.

B

So most of you would already know this that there is a client on the left hand, side transactions get created and it is sent to endorsing peers after the transactions have been endorsed. There are enough endorsements on a transaction.

B

The client would send that those transactions to the ordering service where the consensus protocol is run and, finally, what comes out of there is blocks of transactions and those blocks are sent to all the peers in the system which is highlighted as yellow here we call them validator peers I will come to that later, and these blogs are validated transactions unvalidated, finally committed to The Ledger.

B

So what I want to highlight here is that, in our observation and experience, the validator appears significantly limit the performance of a high political fabric, Network and the way these transactions flow through this life cycle. The third party, the external party, can only see the data after the blocks have been validated and committed to The Ledger, and that's when the transaction is confirmed.

B

So that is why we wanted to look into these validator peers and see what are the performance bottlenecks and how we can improve it and accelerate it for higher transaction volumes near real-time updates.

B

So here is a snapshot of a performance dashboard from one of our validator peers in the network. So what we are trying to show here is that we just took the standard, vanilla fabric Pier using couchdb, and the performance you get from such a peer is about only 150 transactions per. Second, that's far from what we wanted to kind of achieve at the end of the day, and we are not the only one to get this sort of performance.

B

There are a lot of other papers which I've highlighted here um and, and those papers have already also shown multiple times. That validator appears become one of the major bottlenecks in a high pressure fabric. Network.

B

So let me switch gears and talk about fpga cards. um So an a video card is just like a GPU card. You can buy it off the shelf and then you can plug it into the PCI sword of your server. But unlike GPU cards, you can actually program these fpga cards with custom Hardware accelerator, which you can build for your particular application, and not only that you can actually reprogram these fpga cards for different sorts of applications. So I can program it for a blockchain application.

B

I can program it for a machine learning application and so on so inside an fpga card typically is something called adaptive. Soc chip, a simple example, is shown on the left hand side you can see, you might not be able to read all this, but there are a lot of blocks here. So some of these blocks are arm processors. There are blocks which do pcie connectivity, their blogs, which do ethernet connectivity, but the most important part is in the middle, the red block, which is called adaptable, Hardware or programmable Hardware.

B

So this is where your programmable custom Hardware can go, and then you can reprogram this for different custom Hardwares. So what we can actually do with an fpga card is that we can actually program it to do. Compute, network storage acceleration all together in a single card, and then we can also have it um connected to the CPU, and we can have a hardware, software co-design kind of a setup which is much much accelerated for the application you want to implement.

B

So with that in mind, coming back to hyperledger fabric and the validator appears becoming bottleneck, our solution to that problem is the accelerator. We call blockchain machine so essentially, blockchain machine is an accelerated validator peer for hyperledger fabric and you can see a picture there. So it's a server a multi-core server with an fpga card or maybe multiple fpga cards in future, and it's programmed for the accelerator we designed for hyperger fabric validator.

B

um It is specifically designed for high performance. So what I mean by that is much higher transaction validation rates are reduced, block validation, latency.

C

B

On um and then um it is also designed to be adaptable. So what I mean by adaptability here is that all of you would know that hyperledger fabric by Design supports smart contracts right, so you can install a new smart contract. So what? If someone installs a new smart contract, we should be able to adapt our program reprogram. Our Hardware upgrade it to include the new smart contract and that's how we can have more smart contracts supported over time and then. Finally, the blockchain machine peer is compatible with existing nodes in the network.

B

So what why that is important is because I can bring up a fabric Network where all the nodes are standard nodes, for example, standard peer order, nodes and then one of the nodes is a blockchain machine peer and that will work with all these existing nodes as well, and that's how you can first evaluate it, see whether it gives the right performance you want and then later you can upgrade over multiple Cycles, the rest of the nodes in the system as well.

B

So the current status for our work is that it's available for fabric V 1.4, although that I don't think anybody uses that anymore and it's also available for V 2.2, and it has already been open sourced as a hyperledger Labs project called fabric machine. The software code is all open source and the hardware is available on request. So if you want to try it out, please reach out to us.

B

So let me give a little bit of more details of what blockchain machine is so here's an overview as I mentioned earlier. We have a server multi-core CPU here on the right hand, side and an fpga card plugged into the PCI slot, and there are a bunch of modules inside the fpga card, so the fpga card has a network interface.

B

So what that means is that all the network traffic comes into the fpga card and then goes through these modules, and what these modules are trying to do is that they Implement certain types of network acceleration, for example, efficient transfer and access of block and transaction data from the ethernet packets. There's.

C

B

Accelerator, which accelerates the verification and validation of the transactions and overall, what happens is that data comes in gets processed and then it's ready for the CPU to be accessed and further processed on the CPU side. So we call this bump in the wire processing. It's a very typical term and it's a very popular pair Paradigm for high performance Computing. So data streams in through the fpga card goes all the way to the CPU.

B

So a little bit more details, protocol processor at a very high level, we have a very Hardware friendly protocol to send blocks from order to the validator peer, and then it will extract all the relevant data that is needed for validation of the block and the transactions. For example, transaction IDs, block, IDs, read, write, set, people who work with fabric would know this and how you do the endorsement policies and so on, and then the block processor is basically the compute accelerator.

B

We have um different types of block and transaction level pipelines here, so what we are trying to achieve is that we want to process as many transactions in parallel and in a pipeline fashion so that we can achieve high throughput and internally. It has a lot of different types of transaction processing, engines, validation, engines and so on.

B

And finally, we have something called a memory map or a register map. So the idea here is that once the data has been processed transactions has been validated. The results are basically written into some sort of a register map which can be accessed by the CPU. So we provide a go language. Api, which is then used by the fabric software code, to basically interact with the hardware, get the data out of the hardware and then combine it with the block on the software side, and this also provides us a way to basically overlap.

B

Communication overlap, computation that is happening on the CPU side versus the fpga. So we can have certain operations running on CPU, while other operations during an fpga in parallel as well. So we can overlap these computations.

B

So here is the final snapshot of how the whole system looks like in terms of implementation and in terms of how the hardware and software is partitioned. On the left hand, side, we have the entire system where you can see the cmaccept system uh without going into details. Essentially, a cmax of system allows you connectivity to the ethernet port or the network port on the fpga, so ethernet packets coming through here then, on the right hand, side we have a qdms subsystem.

B

Basically, that provides you connectivity and access to the CPUs, so CPU can interact with the accelerator and then in the middle. The user Logic box is where the accelerator goes. So you can see we have the protocol block, processor and the maps and everything in there on the right hand, side here we show how the hardware software basically runs different operations of the validator peer so in a typical standard, vanilla fabric validator up here.

B

All of these happen on the CPU side, but then for us we basically offload most of the computationally Intensive operations, for example, verification of the block, verification or validation of the transactions. The videos you see the database mvcc and so on all on the hardware and then the CPU is only reading that data. The final data from the fpga, the hardware accelerator, combining it with the block writing it to the ledger. So what comes out here? The Ledger from this blockchain machine here, is basically exactly the same as any other peer in the system.

B

So now the main question, the billion dollar question, what we were able to achieve with all this. So here is a quick snapshot. We have a lot more results. So if you're interested, we have a research paper in ICDC as the distributed computing systems conference, you can take a look at that. But what I'm trying to highlight here is that, on the left hand, side is a standard fabric, validator Pier, with multiple CPUs it can achieve up to about 6 000 transactions per second and on the right hand, side.

B

With this blocks in machine, we were able to see up to 70 000 transactions per second as well in validation, throughput. So the way we Benchmark this is using high pressure, caliper standard benchmarking tool. We use the small Bank Benchmark, which is a typical banking application that creates accounts, transfer, monies and so on, and then all these peers are using level DB. So now, I'll stop here and then hand it back to Mutu. Who will talk about how we took this research project and then applied it and integrated into a production level. Network thank.

A

You Harris so Harris was able to convince us like yes, we can get like higher throughput, but as a typical it like. We are not convinced yet, whether it's going to work or we need to do some different, like type of programming, there's compatible. All those questions are any other customers. It exist for us also.

A

So what we done next is as part of the process. We want to implement this particular supply chain solution. Initially, we haven't used any of this custom Hardware. We just use like assets like a phase, one typical like standard software, written everything for CPU and we are able to make our actual application work. First then, as a phase two, what we've done is we introduced this particular blockchain machine to one of the only one Arc to see how it works.

A

It was able to work like transparently, specifically like Harris and stifu who's from who's, our blockchain SME. They work together and we are able to do everything like transparently without doing any code, change from developer or developing different point of view So. Currently, we are in phase three, so we are working on how we can introduce this blockchain mission to multi blocks.

A

So the government ideas is more like a simplified diagram. So what our current thought processes we'll have a standard, um hyper hyperledger Network, where AMD already has a blockchain machine and we are going to introduce to a couple of customers at later stage and slowly introduce to various vendors and partners whom we are working.

A

So what we've done on AMD side? Is it's not just implementing for sake of blockchain? So here we also introduce like the full application scope as it is, for example, this particular application integrated all the way from our Erp to our client application. So we also took like a modular approach.

A

For example, like we, we had like message queues where all the data is getting received from our standard systems, and we also created, like a client worker, it's more like a parallel workers as a transaction processor, and we also created various rest engines, so that it is like a standard, ID interface plus order chain code and other things for running in our accelerated hardware, and we also create like additional half chain databases and we do created like separate client applications. Also, especially in this case.

A

It's a mobile application, which is using like back end, have hypology fabric now, I can short a quick demo, which is like a recorded.

C

Semiconductor supply chain is a space where significant value can be extracted from Enterprise blockchain Solutions deploy chain is an interconnection of organizations, activities and resources for transforming raw materials into a finished product for delivery to the End customer.

C

Managing the Integrity of products and processes in a multi-stakeholder supply chain environment is a significant challenge with Rising expectations from our customers on end-to-end visibility, establishing reliable provenance, preventing fraud and counterfeiting is crucial for AMD.

C

Now that compute intensive tasks are addressed by the blockchain machine, AMD is able to create a supply chain pilot to Showcase, a real world implementation using accelerated hyperledger fabric.

A

Okay, so this depends like a quick demo like how we developed a UI, which is like mobile reading and also like the entire process in which, in various steps like various transactions, are created with proper transaction code, and people can go back and verify instead of blockchain what is happening under particular transactions.

A

So this this is the application which we created for some of our external customers and moving up so we'll also show what exactly happens on the performance aspect.

B

In this video we show a live demo of our hypology fabric network, with Hardware accelerated validator peer. We set up a typical Prometheus and grafana based dashboard to look at a few performance. Metrics of validator appears for this demo. We only show the most relevant metrics.

B

First I would like to go through the configuration we used, which is shown here in the top row.

B

As you can see, we use fabric V 2.2, and we also report the total number of blocks that have been committed to The Ledger. So far, The Ledger has more than 60 000 transactions.

B

The first set of metrics, which I would like to focus on is related to the validation of block and its transactions.

B

We Define this as the time it takes to validate all the transactions of a block and commit them to the state database.

B

The top row shows this throughput for a vanilla appear running on a multi-core server. While the second row shows the same for an fpga accelerated peer, we configured a block size of 50, but it can be smaller, sometimes depending on the incoming transaction rate, as shown here.

B

The software up here is only able to achieve a few hundred transactions per second, which we realize is because of this lower database accesses. We use couchdb as the state database, because our application needs to run various queries on the committed data afterwards.

B

The hardware peer, on the other hand, is able to process thousands of transactions per second, because all of the bottleneck operations in validation phase are being executed on the fpga card. This results in a huge speed up. It is shown here on the right hand, side.

B

You can also see the throughput over time of both the hardware and software peers plotted in real time as the transactions are received and validated by the peers.

B

The second set of metrics is related to committing of the block to disk this Ledger. The reason we separate out this operation is that it always runs on the CPU here. What I would like to highlight is that The Ledger throughput of both the hardware and the software up here, is about the same, because the Ledger is written by the CPU.

B

The third set of metrics is the commit throughput of the peer, which is a combination of the validation and Ledger throughputs of the fear shown earlier here. You can see that the commit throughput of the software appear is very close to its validation throughput because it is dominated by the database accesses.

B

The hardware here, on the other hand, delivers at least 10 times more throughput and sometimes much more because of the hardware acceleration. This is shown as the speed up here. On the right hand, side.

B

However, a very interesting point to note here is that this throughput is quite a bit lower than the validation throughput of the hardware fear reported at the top.

B

From further analysis, we found out that, even after offloading bottleneck operations to Hardware the fabric, software running on the CPU is still much slower. We realize that we need to better optimize the software in tandem with the hardware, for example, we can use a better disk to improve Ledger throughput and better overlap operations in hardware and software.

B

We are currently working on these optimizations. Thank you.

A

So, overall, we are able to achieve like a better performance like this. What we could see during the peak, like the pure validation aspect, point of view we are able to get up to 20x 120x and whereas, like a entire operations, we are able to get somewhere between 10 to 20 x 4..

A

So all this are happening using this particular lvu c1100 fpga card. So this is like commercially available called like.

A

So when it comes to implementation of this whole solution, so we found like a standard. I t approach, like all the deployment is happening through cicd, because we have to try out like multiple times like we are like entire test automation, pipeline Creator and all the integration happened through like a standard rest interface, so that as a customer or a various application, no need to rewrite, and also like, from our creature point of view, we decoupled all the aspect in that way.

A

That's not tightly coupled and there's no dependency of either Hardware or blockchain version or Erp version. All the suspect and also monitoring is kind of key. We also created some additional monitoring aspect as you've seen previously in Prometheus and other aspects as well so entirely. We created like a to end deployment methodology so that it can be ready for production deployment.

A

Some of the insights I cannot call it the challenges. The first Insight is more about how to do an order. Adoption, for example, like always, there is some kind of tile mobile I need to put like a new hardware and other things, but nowadays in the Enterprise data center outside it became like more and more commercial or visible, for example, for many of the training we use the GPU.

A

Similarly, like acceleration, also coming into mainstream in many of the Enterprise data center itself and as usual, get your management support, so that the whole process can happen. Smooth and complaints on legal is very important, and because here we're talking about a smart contract and other things which are more close to Legal, rather than like it code, so we'd be involved with compliance and legal while you're thinking about a blockchain itself and address all their concerns and questions. Why blockchain what it cannot do and what it can do all the respect and security.

A

Also, very tricky portion like a social like infosec, has tons of questions about the security of the whole solution, as it is so that also we are able to address and UI that that is one piece they are. We haven't considered the initial stage. Then later we found out for blockchain, we may need like a different type of UI so that we can show the full sense of blockchain.

A

So this one of the overall like key takeaways, so what we noticed is we are able to do like a better traceability with the whole model of this blockchain, so that all the data is coming straight away to this particular blockchain aspect, and also we are able to prove like there can be the gray Market tracking can be happened better and overall, we are able to reduce the overall Administration and paperwork because of this.

A

Otherwise we need to go and scrap some other website to find out whether it is valid and all those things and overall we are able to find out like better transaction throughput, which can be usable once we are going into mainstream with multiple partners and customers.

A

So with this particular solution, we are very confident we should be able to get minimum 10x and much much more Beyond using this quarter. Explanation. Thank you.

A

A

D

Yeah hi, thanks for this very insightful presentation. I have uh basically two maybe three questions so um the first one is, um if you're, using the fpga. How did you get the code into the fpga? Did you use some kind of high level description, language and then Port it over via vhdl or what's a tool chain that you used for that and, um if you're using fpga and want to scale it?

D

um Isn't there some point in time where you want to move all this into an Asic, because it's much cheaper if you want to have a lot of them and last, not least um well, this is maybe I, don't know if you can comment on that, but you mentioned that we have a shortage in the semiconductor supply chain currently, but I heard that this is current currently reversed, because we have uh in some areas at least a surplus of of chips. So how is that going to balance out in the near term? Hopefully thanks. Maybe.

A

I can add another last question like other two questions: yes, okay, and especially when it comes to shortage after Trends are currently reversing, but what we notice is whenever there's a shortage of semiconductor, the gray Market became like more and more visible and many of our customers. It's industry, why, like they end up buying somewhere in eBay, they are not sure like. Is it a real product, they're buying and all this aspect? So that's where we want to have like a product provenance aspect, the other two questions like yes, so.

B

For the first one, the implementation is a combination of a few different uh setups, so we have used hls. We have also used vhdl. We have also used something else called uh P4 language which is specifically for Network processing. So, for example, our protocol processor, that's implemented in P4 is a high level language and then you can compile it into vhdl.

B

Some of the parts are in hls, but then the main core of the blog processor, like the validation of transactions and things like that, those are in vhdl for the best performance you can get out of it. So whatever we found uh make more sense, we use that for the implementation. So it's not like you have to use a certain thing. You can Implement in any way, if you want as long as you get the performance out of it um for the second or what was the second question.

B

Oh yes, so yeah I agree with you I think at some point we would have to move uh these into. Let's say hardened blocks, either inside the Adaptive SOC or have a separate basic for it once it becomes a more mainstream kind of thing. At this point, it's more of uh um still, we are exploring. We have something which you're trying to move into production, but yes, I would agree once it matures it should go and become A6 or some hardened blocks inside fpga chips.

B

Bear in mind that AC.

E

Cost 50 to 100 million dollars, so you have to balance.

D

By us once the right time, how how far.

B

But typically I think for something like our private insurance. Instead, it's going to be years away.

B

So the question is: when it's going to be available in the cloud.

A

Cloud a little bit challenges now still we are in a pirate stage, so once it dot options coming like much more or mainstream, definitely there's a possibility of cloud, but that's one chart because we are using network port or fpg, which is not generally exposed in many of the public clouds. But there are a few specific use cases. They were ready to open it up, so one shot option will become like same definitely. We can look into it right now.

A

It's currently available in some of the collo clouds, not a standard public clouds to try it out.

B

Yeah, so basically, the implementation is not specific to an fpga card in your own premises. Server like Amazon F1 instance, is ffpg accounts. This should work there, but because the fpgas are receiving data directly from the network, so the fpga network ports should have network access, which is typically not provided by Cloud providers once that becomes available. Of course, this should be available to try out there too.

A

One more question from here.

E

So, um first of all, do you really need to to support 14 000 transactions per second in your um system um and also how many um third-party systems or internal systems you have to integrate to um to make this uh a viable solution?.

A

Only for this particular small client type, we end up integrating with around seven to eight different systems for data frame, the the transaction per second, then many of the data is coming as a burst to us, so that is why the transaction rate keep increasing. It's not like a sustained, like 20 000 transaction throughout the day, so we don't want to cube it like as much as possible. We want to complete it faster, but still it's currently focused on very, very small setup product, not for the wider AMD product range.

B

Yeah just to add for that 14 000 transactions, as he said, if you have a burst of transactions coming into the system, uh if you know about queuing Theory, the the delay and the latency for transactions will increase exponentially. So what we want is because we want almost near real-time updates. So under the peak workload, we want to be able to support as much transactions per second as we can just like. You know a Visa, a system where you know during shopping sessions like a shopping season.

B

They typically say that they have to do 65, 70, 000 transactions per second, but in normal workloads, maybe they're only doing ten thousand fifteen thousand. But if you don't, if the system is not able to support 65 or 70 000 during the shopping season, they will be huge delays like minutes hours, for transactions to settle down. So the same thing applies here as well, and that's why.

D

A

Have fpga card to accelerate.

B

F

So this is maybe a technical question, but I was wondering where you got most of the speed up from uh CPU to fpga. Was it the data access or the actual computations themselves.

B

um So um yeah, if you're more interested, you can look at our paper. But the summary is, um if I remember correctly, about 10 to 20 percent of the time is spent on accessing the data, because all the data and high pressure fabric is uh uses protocol buffers, it's a layered structure. So if you do profiling, you will see about 10 20 10 to 20 percent of the time we spend there accessing the transaction, the data, the endorsement uh uh polit, so not policy the endorsements and so on uh the rest of the day.

B

The rest of the time is actually spent about 50 percent in the actual ecd essay verification. So the digital signatures, which uses ecdss scheme that takes about 50 to 60 and in some cases up to 70 percent of time, with the shot, 256 hashing as well and then the rest 10 20, 25 percent- is spending level DB accesses.

B

So we are getting most of the speed up by using multiple of these ecdsa engines in the fpga have like parallel and pipelined transaction processing which efficiently uses these engines to do the verifications as fast as possible, and then because we have in Hardware database, which is of course going to be faster than what you will get as go level DB. So that's where the rest of the speedo comes from.

G

I think one last question: on from my side the Herrera consensus you can replace with the existing the the orders with hedera consensus protocol. That's what I heard have you tried that if you do that, then your problem goes away.

B

A

B

The hedera consensus protocol and it can replace raft, but what do you mean by the problem going away? Can you elaborate I thought.

G

That waterways will go away once you replace raft with the hedera. Then you get this hundred thousand transaction per second in hyperledger itself, I I'm I'm, not very sure, I'm, not a techie, but the way I understood I explained it.

B

I'll look into it later and get back to you.

H

I'm not sure about the outright performance, but it is another hyperledger Labs project, so you should be able to take a quick look at it. On the on the cloud side, though, there are a couple of uh like I'm thinking of equinix metal, which used to be packet. I mean it'd, be interesting to sort of talk to folks like that, um possibly Rich Cloud. So in other words, once you get beyond the hyperscale clouds, there are some bare metal, Cloud providers that could be interested in this.

A

Yeah yeah, we are already working with few badminton providers to see how we can host so right now we are planning to host some of the demo environments so that people can come and try it out. So we are working with few windows in this aspect.

B

Any other questions.

A

Okay, if not uh thank you thanks a lot for attending the session, we'll all meet you in Guinness, okay,.

B