 hypothetical application you could say so consider we would like to measure electricity usage or energy usage by a client and there are already some companies which are working on on a product like this where you can generate a transaction let's say every second which measures how much electricity or energy are using and this transaction is then recorded on a blockchain and afterwards the blockchain data could be analyzed for fine-grained tracking fine-grained usage and billing as well as if let's say some clients have solar panels or other forms of renewable energies and they are pumping energy into the grid that can also be tracked and measured to these transactions and then they can get rebates for their for their electricity bills so we want to look at this example from performance and scalability part of you so consider here at the bottom if we look at some articles published online about a year ago and different companies which are trying to work on this as a test project and the data we could gather from there was if there is a single supplier and then a few major consumers or clients for that supplier we might look at about some 30 000 transactions being generated per hour but if you want to take this small test project and scale it out into some kind of let's say a grid for a big city or a national grid for an entire country we would be looking at billions of transactions being generated per hour and of course if the systems which are backing up and which are being used to create these transactions cannot process these transactions in real time then the whole idea of using blockchain for fine-grained real tracking goes away so we did some more analysis on top of that and what we figured out was if we take the current blockchain systems which are mostly software only and we assume we can improve them by a magnitude of order like by 10x even then we would only be able to support about a thousand million transactions or one billion transactions per hour so if you're looking at a national grid that's far more more than what the current software systems with additional transactions can achieve and that's how we at Xarlings came to look at this blockchain scalability and performance issues area to see whether we can use hardware to accelerate and go beyond the software only ball which is the limitation of current systems so keeping that example in mind here on the left I have some of the performance or scalability metrics for example I want to increase the transaction per second rate what's the benefit of that I can do better when tracking of the energy usage as well as I can support more participants in the system but what does it mean to scale that out in terms of the infrastructure which is going to and this kind of a blockchain system in terms of compute we need faster execution of transactions in terms of networking because there are multiple nodes and peers in the system which talk to each other we need better networking faster networking to process the transactions and move them around from nodes to different nodes in the system and likewise in terms of storage the storage will grow very fast so we need you know more and more storage but also we need higher access rates for that storage because we have many more transactions coming in on a per second on a per second time frame so we need to do much more accesses to the database so I'm not going to go through all these all these rows here but the idea is that whichever way we try to slice it in terms of the performance and scalability metrics here on the left our understanding is that we need an integrated approach to network compute storage acceleration if we want to go beyond the software wall of the current blockchain systems and I will go into some of more details of this in the future okay now switching gears to what Xoling says and what we do some of the folks might know but I get this question about because primarily hyperledger projects were created from people who are most in the software domain so just a quick overview of Xoling so Xoling says the inventor of FPGA which stands for field programmable gate arrays you can think of this as a chip hardware chip which can be programmed again and again so just like you can upgrade a software after you have shipped you know one of your products just like that you can reprogram your hardware and fix some bugs in your hardware so it gives you the flexibility that typically software systems have and as of now Xoling produces different kind of FPGA chips, boards and some development kits as well as it also provides acceleration libraries or software libraries which kind of provide seamless integration to other software applications if they want to benefit from the hardware acceleration and recently Xoling says also been producing acceleration cards which are just like other you can think of them as you have a GPU card which you can use for acceleration likewise you can have an FPGA card you can plug it into a server and you can use it for acceleration of your applications and many cloud providers like Amazon web services have these acceleration cards are available in their servers and you can run them and use them if you want to I'll skip the rest of the info which is just some numbers and then give you a bit of more idea of what a programmable acceleration platform looks like so here is a typical chip which has a few different type of components the first one here on the left hand side called scalar engines they are basically processors like ARM processors where you can run your software applications here on the right hand side you have some intelligent engines these are basically specialized custom designed hardware accelerators for example mat engines for machine learning inference some signal processing engines for signal processing applications and then in the middle here we have the adaptable hardware which is basically the FPGA so this is the part where you can take your hardware design and program it and then you can change it over time as well if you want to and then here at the bottom there are some hardened IPs which let you connect this compute this extensive type of compute engines to different type of other systems for example there is the PCIe IP here there's DDR4 for memory connections there are internet cores here and so on and these chips are now available as part of these acceleration cards one of them is shown here called LBO which you can just buy off the shelf and you can basically plug them into your server and then you can use them for acceleration so before I go into the work which I want to demonstrate today just want to give you a bit of background of our group we started looking at blockchain about one and a half to two years ago initially we started with the public blockchains so those of those who don't know blockchains are either public or private slash permissioned in public blockchains the very famous example is bitcoin and then in private there are a lot of different options but hybrid fabric from IBM which started from IBM is one of the most popular one so with public blockchain there's a company called Bitmain and that's one of the largest providers of mining pools in the world and we collaborated with them they had a system which is shown here on the right hand side so this is a pool from Bitmain and then they would use a proxy which would take a job from this pool the job basically represents creation of a new block on the blockchain and the faster a pool can create a new block it has a higher chance of adding it onto the blockchain that's how these bitcoin and public blockchains are designed so it's very important that you are able to take this job or this new block which the pool is proposing and be able to distribute it to the end miners which are going to do the actual work so latency networking latency matters a lot so we worked with them on accelerating this part of the system where we took their strata mining proxy and implemented it on an FPGA system using the sync chip from XarLinks and we were able to show many orders of magnitude of improvement in latency and they were able to excuse me they were able to test it in their own production system and then we published it at the Kripovali conference then we moved on to the private blockchains we looked at Hyperledger we started with profiling and benchmarking Hyperledger fabric and we came to figure out that there are a lot of areas where software is not very fast at the moment there are a lot of bottlenecks which are very suitable for hardware acceleration especially FPGAs so that's how we got started Hyperledger fabric and initially we proposed some software only database access optimizations and we published that work at IEEE mascot last year so now I'm going to talk more about what we have been doing in the last six to nine months and this is where we bring in full hardware acceleration into Hyperledger. A bit of background about fabric before I go into what we did fabric consists of a network of different nodes and these nodes execute so each node is like a server which is executing some part of a software application and here the nodes are represented at the top so we have clients which basically generate transactions we have endorsing peers which basically take the transactions and process them there's something called ordering service which would create blocks and then there are some other nodes which are non-endorsing which only take blocks and the process does so a typical flow of how a transaction flows through a fabric blockchain network is that a client will generate a transaction send it to a number of endorsing peers and wait for the endorsements from those peers these peers would tell whether this transaction is valid and so on and once the client has enough endorsements it would send that transaction back to the ordering service so ordering service would get a lot of transactions from different clients and we'll put them order them into a block and once a block is created that block is sent out to all the peers irrespective of whether they are endorsing peers or non-endorsing peers and these peers would take the whole block validate all the transactions in the block and then finally commit that block to the ledger or add it to the blockchain so that is kind of the generic flow of how transaction goes through a fabric network and in many other permissioned or private blockchains the flow is more or less the same with you know minor like minor changes here and there that's kind of the idea of permissioned networks so there is no proof of work kind of algorithms which are typically used in bitcoin or proof of stake algorithms are typically used in public blockchain systems okay so let me come to why we did blockchain machine so when we started looking at fabric and we did a lot of performance benchmarking and fabric and looked at a lot of previous work which was done on it which is mentioned here at the one of our papers is also here we figured out that validation phase is one of the major bottlenecks for the fabric blockchain and the primary reason for that could be broken down into three parts here there is a lot of cryptographic operations which are done because each transaction has some kind of a signature which needs to be validated some transactions have multiple signatures the block has a signature so there are a lot of cryptographic operations which are done during the validation the second is that a lot of block and transaction data involves un-martialing of protocol buffers the protocol buffer is a serialization and a deserialization protocol from google where you can take some data and then serialize it and send it out to any other machine which can understand protocol buffers and they can and the other machine can then or the other application can then deserialize it so that involved that took a lot of compute in the validation phase and finally the state database accesses were typically slow and were one of the major bottlenecks so we looked at this and we figured out that this is something which we can actually uh actually offload or accelerate to the use of hardware accelerators on FPGAs so we started with the goal of building hardware accelerators which are FPGA based for hyperledger fabric and we wanted to improve certain performance metrics like transaction throughput or block and we implemented the validation on the pier which is slightly different from an endorsing pier in that it only performs the validation phase it does not do any endorsement of transactions and our blockchain machine was implemented on a network attached accelerator card from Xilinx called LVU which I showed earlier and at the hardware level we did two things to kind of evaluate the bottlenecks which I mentioned in the last slide that we tried to read the block and transaction data directly from the hardware interface coming into the FPGA so there is no need for this data to go all the way to the CPU and get processed in the software and then get sent back to the to the FPGFR processing so we bypass all that and instead we introduced our own custom protocol and we were able to retrieve this data directly from the interface of the FPGA card and then we implemented a very efficient integrated block level transaction level pipeline in the FPGA to do the validation of transactions blocks in a parallel pipeline manner so that we can achieve significant improvement in transaction throughput and as of now we integrated this blockchain machine with Hyperledger Fabric version 1.4.5 and we are working on upgrading that to one of the more recent versions of Fabric so the current status is we have a proof of concept where we have a server with a standard network interface card and Xilinx LVU based network interface card we generate the blockchain machine hardware using a predefined number of transaction validators so you can think of this as the number of transaction validators is configurable in our system so based on the application you want to run or multiple applications you want to run you can have four transaction validators or eight and you can have better throughput and likewise the hardware is generated using a predefined set of chain codes so chain code is basically the code which is part of the transaction which is executed during the endorsement phase and then it's checked back again during the validation phase so if you have multiple applications they can have different chain codes or different business logic which they're implementing through chain codes and finally we integrated this whole setup with Hyperledger Caliper which is another project from Hyperledger it's a benchmarking tool this is a standard way of benchmarking different Hyperledger projects so we integrated our work with that so that we can benchmark it and in all the experiments all the testing we have done so far we saw at least an order of magnitude improvement 10x improvement in the transaction commit throughput when we compare to a software validation only here so let me go into a bit of more details of the demo so as I mentioned the demo is run using Hyperledger Caliper the Caliper sets up the Hyperledger network which involves bringing up different peers bringing up the order and it also brings up our blockchain so we modified Caliper with some of our own internal as with some of our own improvements and we have returned some other scripts and automation tools around Caliper to enable all this and for this particular demo we ran small bank benchmark this is an application which mimics which mimics banking application banking operations for example I can create an account I can transfer some dollars from account A to account B and so on and then in the fabric network the way we organized it is that we use two organizations you can think of this as two banks for example ANC and Commonwealth Bank and each of these organizations has two peers and a single separate ordering service for which is ordering blocks for these two organizations in each of the organizations the first peer is an endorsing peer so it can accept transactions it can endorse those transactions as well as it can validate blocks later after the blocks are sent from the ordering service the other peer was only a non-endorsing peer it does not do any endorsement of the transactions but only validate support blocks so this is how we do the apple to apple comparison so we look at this non-endorsing software only peer and then compare it with our blockchain machine the endorsement policy here two of two basically means that for every transaction to be valid in this system it has to have an endorsement from organization one which is bank A and organization two which is bank two and finally we added the blockchain machine as the third non-endorsing peer to organization one and in our setup the ordering service would send the blocks to the lead peer in each organization as well as it will send those blocks to the blockchain machine okay there are a few questions i'll get to them after the demo yeah okay moving on to the demo setup for the blockchain machine we used xerlinks lvu 250 board it's available off the shelf anybody can get that block can get that board and and then can use it with our solution um and uh getting into a little bit of more details for caliper this is not really that uh needed here but just wanted to give an idea that we created six different virtual machines on multiple servers and one of the machine one of the vm is acting as an auditor and then four of them are acting as the four peers in the two organizations and then we have a client vm which is uh creating transactions at an aggregated rate of about 500 transactions per second and sending those to the peers as well as the auditor and we had a separate server which is set up as the blockchain machine as i mentioned earlier and we configured that uh blockchain machine with eight transaction validators you can think of this as it's kind of equivalent to what i mentioned here as the eight vsc threads so these threads are basically eight parallel threads which are used by the software to validate transactions so we use a similar number of transaction validators in our hardware as well okay uh this is just a video of the demo but i'm going to switch my developer mode now and uh i'll show you a live demo of the work we have done okay so this is one of the servers we have we have set up a few different vm's and from one of the virtual machines i'm going to run our custom script which basically would run all the sorry my screen is a bit messed up sorry about that reduce the font size a bit i increased it to make sure that everybody can see it easily but now i cannot see what i'm typing here so uh i'm going to go back to the original one and at least start something first so what's happening here is it's creating a few different identities for the different peers and auditors inside the fabric network and is trying to bring up that network thanks i'm not sure i'm gonna get to it so people who are familiar with fabric and hardware would be able to i don't really understand what you're talking about see some of these commands as being heavily used in then uh fabric internally uh depends on uh doctors so doctors are containers can bring up it's like lightweight containers which can bring up in in different servers to run different parts of the application so once um that part is done um we will run the hardware peer okay it's kind of getting a little bit harder for me to read so i'm gonna go back to a smaller thing so this is how i started the hardware peer okay so now i'm switching back to the other command line where i was running the benchmark from within a virtual machine so you can see a lot of transactions being sent and some of these transactions have errors this is uh uh this is deliberate because the benchmark is designed in a way that it would create both good and bad transactions and so that you can test the system that in case the both the good and the bad and it would send about 10 000 transactions to these peers at five in the transaction per second here you could see that the benchmark has finished sending transactions and it's going to gather some logs from these virtual machines and then we're going to analyze those logs to look at the to look at the performance metrics so this will take a few seconds some of the logs are a little big so now it's shutting down those containers and the VMs because the benchmark is almost done we're going to switch back to our hardware peer and we're going to shut that down okay so the benchmark ran successfully it will put some numbers here and there in different files so i'm not going to show those numbers here but switch back to my presentation where i have put them into a small graph so it's easy to come into the acceleration results one of the things which first i want to point out is that these are only for the validation phase so again remember that we implemented the non-endorsing or validation only peer in our blockchain machine as of now and when measuring the commit throughput the total validation phase also has another operation at the end where it would actually commit the block the ledger or the blockchain which is basically writing that into the file system so that part can be done asynchronously so that part is excluded here when being performance measurements because it's asynchronous and it does not affect the performance so the commit throughput here the first graph is plotting the block latency in milliseconds for the entire block and the second graph here is the commit throughput which is in thousands so you can see this peer one of organization one which is a software-only peer was able to achieve blockchain which is peer two in organization one was able to achieve about 46,000 transactions per second so this is about 15x data and if you're wondering why some of the block latencies here are a bit lower than these block latencies so these two peers here on the left hand side these are the endorsing peers so recall they do both endorsement of incoming transactions as well as validation of the entire block but these three peers here are the non-endorsing peers they do not endorse any transactions and they only validate the incoming block so that's why their latencies are slightly smaller than the endorsing peers okay so with that i am going to sum up my talk and give you a bit of a high-level overview of what our region of this blockchain project is so consider that we have accelerator cards available from xolins or any other fpga render so those cards are plugged into servers and they form the lowest layer here for the hardware accelerator cards and then here at the top we have different blockchain projects under hyperlager umbrella there is hyperlager fabric which we used but there are also other projects like hyperlager basis which are ethereum based and so on and we would like to work on these layers in the middle and what our goal here is that we would like to provide a very basic hardware shell with implicit core functionalities of a blockchain machine and then on top of that we can have programmability in the form of different chain codes you can install or different accelerators you want to use inside that blockchain machine and then these get plugged into the we with the help of some ethia adapters into the standard software for these three layers what it actually means to work on is that we can look at the transaction flow in a very generic way that transaction is created and then it gets executed and then validated then gets formed into a blog and then the blog gets validated and added onto the ledger for the blockchain and each of these steps involve one or more of either compute storage or networking so for example the demo which i just demonstrated falls under this step four here where multiple transactions are created are already part of a blog and that blog needs to be validated and added onto the blockchain and this operation is very compute and storage intensive and then we accelerated this part but in future we're going to of course look into these other operations or the other parts of the system through which the transaction has to flow and then look at acceleration opportunities there with that we have a few you could say short term future work goals and a few medium from long term so short term is we are already working on migrating these two fabric version 2.2 um the reason is 2.2 is the more is the most recent long term support working from hybrid fabric and many people are already transitioning to fabric 2.x so we are already working on migrating over blockchain 2.2 then in the near term we are also looking at something called hydrological maps this is another area under the hydrological consortium where people can share their work which is non-production ready which is more in the research space which is not ready yet for you know widespread adoption so we are already working on a proposal and with the last project and then in the medium term and long term we definitely want to look at other blockchain systems as I mentioned hydrological basu which is based on material without people work or hydrological sort of which is based on Intel's sdx technology so we would like to look at these other blockchain systems profile them understand them better and see that there are any acceleration opportunities in those blockchain platforms as well and then finally last but not least um we are always looking for collaboration opportunities with other companies and and other researchers from universities so if you have any ideas or if you hear something you can work them together please do with that I will stop here and I would love to have your questions oh since Dr. Harris uh any questions I saw some questions in the chat box okay sure uh let me so there is a comment from this example sounds like a tokenization model interested to see how I feel I can build no token based model um Amar would you like to elaborate a bit on your question or suggestion my question when I saw the model that you uh both at the beginning about the energy and there is a feeling system and the monetization of this I hope okay this is from the tokenized so why this is like how can it be in a hyper ledger that fit in a hyper ledger infrastructure so that just was a question uh hoping you think my mind that I understand now it's just an example that you will show it at the beginning probably what the question was about my my question actually but yeah my question actually is about uh redefining uh chain code but you uh so you have to accelerate the hardware uh you say that you can uh free program okay so in a case like uh I have a business case like I'm building blockchain network where the uh there is there is the participants in the network who can create a chain code uh for the smart phone smart phone that uh logic uh like on daily basis like a spotlight like I can say I can say it's not like the one place uh business project that will run at the time it's actually gonna change uh daily so we define chain code here it's like uh deployed once and uh installed on the network or it can on the runtime I can change the chain right so that's a very good question and it's one of the areas we are currently working on so um yes so what you're referring to is that you have a chain code and then you upgrade it so you study with working 1.0 then after a few days or second day you wanted to change the business logic so you just like in fabric you can install working 2.0 for your chain code so as of today we if you want to upgrade your chain code yes you can do it but you have to regenerate the whole hardware and then you have to reprogram the accelerated card and then you can get online again in the system and that's like work but that is not a very very good and flexible solution so we understand that and we are working on a better solution for that where you would be able to kind of um just like in hyperlidic fabric you can write a small chain code programming go lang or any of the lang and then you can call it so we are looking at creating some kind of a small i wouldn't say microprocessor but you know a smart contract engine and then you can basically write the new business logic on top of that or maybe you already have it in one of your own high-level languages like go lang and then we can just compile that into the machine code or the assembly language for that smart code or smart contract engine which we are working on at the moment so that's work in the progress but the demo we just showed at this point we have to we can answer your question or you have any any other follow-up yeah thanks okay thanks so there is another question from um Sidra um shouldn't be performance improvement by 10x did you also analyze the use of multiple lbo boards if single board was used with number of validator nodes had any um so as of now we haven't looked at multiple lbo boards so our setup is that a single lbo board is like a single pier or a single node but inside that single node just like on the hyperledger fabric software spec you can have multiple threads to to basically run the vscc which is the validation system chain code and based on policy uh evaluation uh you can have multiple threads to do that which can process these transactions in parallel so within this single pier node on a single lbo board we have just like that multiple validators and of course if we use more validators we can get back their performance we use less number of validator nodes we get less performance okay i got a question uh i'm not working on blockchain the question is about the performance gain what's that the speedup from it's from parallelism because intuitively the speedup should be higher if there's a massive use problem level parallelism it seems the interaction between f2.j and the database very hard to cut this may take a significant amount of time okay thanks for the question um you know let me clarify a little bit more about the architecture so the architecture was deliberately left out of the thought because it's company work so we are going to uh because you know kind of it of course but yeah we are also going to make it um open source in future as i said i'm going to be hyped for the last project but i can give a little bit of more detail about um about that um so at this point we do not have any interaction with the artist the data is is all in memory uh so it's an all-memory database right on the fpga card so uh yes it is still of course one of the bottlenecks even in our system but still it's much much much better and faster than the cpu using the database from its memory as well as hard as so you know there are some there is a very famous paper called my step right where they just used where they just assume that the whole database is residing inside the memory of the cpu so and in that case they were able to show that they can scale that break to about 20,000 seconds per second but in our case since we can even further optimize that even at the clock cycle level because um i know how many uh cycles it would take to read or write into my status which is all of the fpga so i can even do a bit of better optimization there so that's we have a bit of we have a better improvement uh from that the second improvement comes from the fact so in this validation phase yes database accesses are slow but still the major bottleneck is the cryptographic operation the verifying signatures takes a long time and on the cpu side let's say you're using intel silver zon or the zon gold they have a few number of hard wired blocks in their cpu's which can do some of the cryptographic operations but of course you cannot scale that right on top of that it's multi-threading so in our case it's it's basically the hardware is generated by us it's configurable so i can tune it much better that can program it according to whichever application i am with from the top of it so that's the other part where we gain much more improvement because we do both parallel and pipeline evaluation of the signatures and that's where most of the thank you okay there are some other questions on the chat so we asked can you explain a bit about smart contract engine um so that's something which is under progress so we don't have a full implementation of that yet but uh well i know we do so i'm from the same university so uh what i would say you can think of it as let's say uh microcoded engine or let's say as an ALU in a processor but that's you know only does execution of smart contracts and then of course we could uh because smart contracts they can have like this in which language we are going to support etc the the type of operations which are supported cannot be any arbitrary operation so we can kind of optimize it there it still works under progress in the sense that we are looking at different design on them and we are not there but it's still in our these stages of course there is another question on the chat how is the mapping of the VMs into the xarling's boards uh this question actually so let me elaborate on the question already so with our own experiments so we've been doing experiments with caliber with our own chain codes and also the sample chain codes there what we've faced is that the networking latency when you when you distribute these components of the fabric is is massive so now so we've tried running the whole thing on a single laptop uh running them across uh the same cloud provider different cloud providers hybrid scenarios and you see there like the the the the lenses are massive so my question here is that so first of all so these six VMs that you mentioned uh where are they located as in there are kind of all everything is happening on your board or is there any other machine that's uh that's involved i i would like to know a little bit more about that thanks great question yeah i totally agree with you the the moment you try to go uh let's say you take your VMs and you want to divide them across the wide area network yeah the latency of the network comes into play and uh you would probably see that your bottlenecks start shifting towards maybe the ordering service or the client sending instructions etc but in this particular case because we were um focused on um looking at the validation phase so we tried to avoid those because their network latency would be a problem because otherwise the the performance benchmarking we are doing would be diluted or would not be equivalent to the actual system so our VMs were located in our own private i wouldn't say cloud but we have a small set up of a few different servers which are connected to a local area network and our xilinx board our boards are also connected to the same local area network so we did all these experiments on local area network with VMs in different servers and uh for us uh as you would know that in that setting network latency that problem thanks thanks questions from audience to dr harris hi harris can i just ask a quick question uh can you go back to that slide at the end with all the time uh this one so you've got the blockchain uh yes and what about the others what level have you built so far so we have right right yeah so so that yeah that's actually the whole idea here so even for the blockchain shell we have implemented most of the core functionality to let's say need this for but let's say in future we uh look at hyperlegger they sue or some other blockchain problem figure out oh there's something else which could also be a core component and has to be in the machine shell so that would go there too uh but then with the with the other two layers yeah we only pick those things which were needed by fabric and only implemented them because this demo was specifically for fabric and now we are looking into some of the other things but there what we need was for example um if you're working with fabric so when you get a transaction you have to validate the transaction and you validate the transaction based on some kind of a policy so if you remember i mentioned something about two of two investment policy that if this transaction has an endorsement from bank a and bank b then it's a valid transaction actually added to the ledger so that's one of the uh uh so against we would add there that i'm implementing a two of two investment policy which would mean that okay i have a small either hardware circuit there or maybe a small micro for the engine there which would look at these features of this particular transaction and then see whether it satisfies this boolean policy or not so that's one of the examples that would go into the configurability which is some accelerator plugins so that's an example of that the second is uh let's say the database itself so for our case we built a very small database which is a key value store uh because fabric uses go level dv as one of the default databases is basically a key value store but since this is hardware v is pretty big to a certain size of the event so if you're looking at some other application some other blocks of the platform that could be different or you might need a very different database design so that would go and then with the second layer which is like programmability the user chain code so user chain code is like the smart contract the business logic and for our case uh that was small then but then again you put it in the ethereum ethereum has its own ethereum virtual machine which could also be implemented on hardware and then you will and then you write your program in a very high level like solidity and you can add it into ethereum virtual machine instructions and then you run that here so that's the part where the user chain code so as of now most of the things we did and we really were specific to the fabric but now yeah of course we're at the other blockchains or yeah if the community wants to contribute to it we are more than happy you know where to do that because we can you know spend time on this or we want to explore this time from further because we have the resources we are going to the very specific agenda to at least showcase a basic system and show that you know there is potential here for hardware acceleration and private permitting blocks and systems so can I just follow that up to the other question I don't know much about this why do you actually how do you actually so if I put any normal machine would it have the same speed up effect? just so so let's talk about fabric but this is the filter on fabric so let's talk about that first not like the generic and if you just talk about fabric let me actually go back what about fabric and this validation phase here each here which is like a single machine but it could be a multi-core machine right so you put 24 cores there you put 48 cores there has to one be small things sequentially one by one so what we did was first thing is we tried to see where you can parallelize things and then this could be pipeline let's say you know some transactions are here then I could have some more other connections in this space like that so that means it's like that now if you put a single machine with 48 cores the current fabric software would only parallelize this part as I said this part but yes it's here that's this nature of the change and again it only parallelizes it across transactions not over that because I think it's so putting like hand machine doesn't make sense here because this whole sequence has to be done in a single machine and has to be done sequentially yes you can put 10 of them then you know that you will be moving data around the communication latency will come into place so most probably whatever benefits you're going to get you will lose them and the second part this is again has to be sequential or unless you do some smart pipelining of this whole but there are some other parts where you can put more machines and then the hardware actually will make sense for example this endorsement here there has been one paper recently as well and we also believe the same thing that we started in both endorsement and validation for acceleration candidate but then we looked at endorsement so what happened in an endorsement is that you send a transaction to appear it will execute that transaction which internally means that it would be executing the smart contract or the chain code which is part of that transaction and then sending a result back the client saying yes I endorse the contract that it's valid now in a system where I want to go from hundred transactions per section to 300 transactions per second I can put three machine each and make hundred transactions per second but I would get an aggregated rate of endorsement into the contract per second but that does not happen in the validation because irrespective of whether you are endorsing or annuling this part has to be done by every peer in the system and has to be added to each replica of the plot and that's why here putting more machines or skilling about using multiple machines doesn't make sense but in endorsement it does make sense and we personally believe and I probably believe that endorsement is not a very good candidate for hardware acceleration. Thank you very much. I thought that was good. Thank you very much. Cool. Oh good. You know, ending of this meetup. So any last question from audience to the doctor? Yeah sure go ahead. Okay this is Tor from your study. So after you get some 10 times speed up what is the most important that experience? I'm sorry can you repeat it again after getting 10x speed up here? So in your current state of the solution sometimes what is the most important that? Okay so if you look at software so we don't know of any of the fabric as of today but there are some software optimizations that we can ask here so the best numbers we have seen so far is about 20,000 seconds per second from state of the art so if you compare that it's 46,000 which we have with minimum hardware so that still would be better than what we have seen in the software. Of course in Twitter we might be doing some more optimizations just on the basis. And in terms of the second question what are the other bottlenecks? So I believe that once the development phase significantly liked what we have now for and then if you test the system with just sending in 20,000 seconds per second I think the ordering service will be like one of the other that of course becomes a bad issue. So the more workload you try to put on the service would begin so many times that you have to process it, you have to send those bigger to the peers. I think the networking service can choose to significantly improve the performance of the software. Thank you very much. How good everyone sends Dr. Harris for your brilliant content and insightful answers. So thanks everyone for you know joining this meetup. I appreciate your time. Have a nice day, nice evening. We'll see you next time. Thank you very much. Thank you, Harris. Thanks, Harris. Bye. Bye bye. Thanks, Harris.