 Great and as a quick reminder, I'll drop the link to the live stream page in the zoom chat because there's also a chat on the YouTube page So we just want to keep an eye on both for Q&A. So you are live Sure. Shall I begin? Yes, please. Okay. Well, thanks very much for the invitation to the organizers So it's um, it's an interesting group for me and my colleague Alexander to to be here as we understand it It's a mixture of people who are interested in telecommunications and hyper ledger So, yeah, really interesting to meet everyone here and we want to make this as kind of interactive as possible So feel free just to shout out any questions during the talk and you know, I might even post some questions to you guys So this is the agenda So I'm just going to give you a quick overview of who and chain are and then there'll be two parts to the main talk So firstly, my colleague Alexander will talk about some research. We've done It's you know, it's ongoing research So there's plenty of opportunity here for you guys to give us feedback What do you think this is a good idea whether you have any suggestions, etc? I mean we'd be really interested to hear that and then I'm going to end with just something a bit more fun Which would be a general kind of discussion about what I'm calling high performance public blockchains because I'm not sure How aware you guys are of the kind of current current state of play in that particular area So, yeah, I'll just start with who are in chain. So we're a company with over 250 employees based in the UK, Switzerland and Slovenia. So I'm based in the UK. I'm in London My colleague Alexander who's in Switzerland, and then we have some people in Slovenia as well And we have 17 scientific researchers and I mean Alex are our two members of that team And we started out really as a research and development first company, which is you know A bit unusual and the research we're doing back then is really trying to lay the foundations to the kind of scientific foundations of Blockchain and how we might use that in you know At a large scale and for enterprises. We then introduced a software engineering department in 2016 and one very interesting Piece of software they produce is the node software for a blockchain called Bitcoin Satoshi vision BSV Which I'll talk more about later and it's the highest performing public Node software out there and by that I mean whichever metric you prefer like transaction volume block size throughput, etc Then we introduced a what would be a business service team in 2019 trying to look at the market seeing where the kind of inventions we have might best fit And we're gradually transitioning into a product company So starting to build out on a lot of this expertise, which is really exciting place to be right now Anyway, that's a bit of an overview of N chain and I'll now hand over to Alexander you so Hopefully he can control my screen. I think so. Let's see. Yeah, I can okay awesome Right, so let's run a bit for through the motivation for this research project Why we want to use the blockchain together with peer-to-peer networks So it was shown in the in in the academic literature that if you have a lack of economic incentives Peer-to-peer networks have difficulty scaling you might have some kind of community incentives whereby you share files, but that Already is applicable if the peer-to-peer networks are at large scale, so they wouldn't face this problem anyway So then if we do add economic incentives It was shown for example, I think it was first shown maybe in 2012 in a research paper by Microsoft that introducing this will add CBL attacks because Network nodes are then incentivized to create a lot of fake identities throughout the network and gather as many economic rewards as possible and the third motivation for this For for this research is a question that arise for example during covid times and and During covid times we saw a lot of Network load on peer-to-peer networks and there's a natural question on On how or who should pay for this network load? Right, so let's cover a bit of background in order to set up the work Let's look at first Nutella, which is quite a famous peer-to-peer network. It was the first decentralized network Of its kind that in and it was introduced in 2000 and funnily enough its name comes from Nutella and No, the found the legend says at least And it was or is still a file sharing network that I think it's still active So the request of Nutella is the the the the I picture of Nutella is the other simple and it's a request response type of Network interaction where we can request data to the network And the queries are sent to our peers and our peers forward the query to their peers once No disidentified that for the required data There's a Response and I'll send through the network back to us Notifying us that the data has been found they Containing also the information on of this spear so that we can establish a direct TCP or UDP connection with a node and We receive the data Now on to onion protocol, which we will turn on its head, but let's cover the basis of this first It was first introduced as For an anonymous communication and it's still being used for that and it was introduced in the mean 90s to protect us intelligence communication It's currently used as part of the of the Toro network if you Used that until now and it's Let's let's look at it's I hit the it's Architecture brief or and very succinct Overview of how it works. Let's say we have three nodes in the in the network and we want and want to Relate data securely to n3 passing and to such that and to has no idea of What it's being? What what it receives and what is sends to n3? So if you're aware of some cryptographic cryptographic concepts and one and then two first performer Diffie Helman kick exchange whereby they establish a shared secret between them This will be a cryptographic key and Then and one can establish another shared secret with and three through and two So and two will relay the public key of n1 to n3 and three can create the shared secret and they and it can send the notification that It has sent the It has created the shared secret and it sends its own public key So we at this stage we finalize the Diffie Helman key exchanges between all these nodes and we can Securely relay the data. So we encrypt the data in two layers using the first shares secret between n1 and n2 and Second shares secret between n1 and n3 at this one once n1 sends this encryption of the data to n2 and 2 can decrypt the first layer But it still doesn't know the data, right? So then it just sends the encrypted data to n3 and n3 can then decrypt the result and Do whatever it wants with with that data, right? This is a very simplified example of The onion protocol contains several other details, but this is a brief overview of how it works for a three nodes Right. So now that we cover the basis We can look at how we can enable Data transfers using Nutella and onion protocol while crucially enabling the economic incentives I The economic incentives I Mentioned and we will use blockchain for that right, so Let's cover Nutella and we will have a Nutella on chain So in this in this framework the the protocol runs as follows and one will send a request for data in a double hash And it will send to its peers also a transaction payment with some conditions We will cover a bit later and the n12 so the one of the peers will forward the request To its peers and one to one and then one to two now I want to pause at this stage that and Emphasize the fact that the transaction payment this is mined on the blockchain So when n1 sends the hashed request it will send the hashed request by a TCP IP for example To n11 and then mine the transaction payment with a can with the necessary conditions on a blockchain of its choice and The other peers do the same thing Right. So now we identified the green node and the green node has the data So then the green node lets the whole network know that it has the data by Publishing h0 of r so the inner hash of the request and Once it has made this broadcast letting everybody know that it has this data through h0 of r and one and then and one and the green node can Can start a connection well and one to one will send the data and Receive some payment from n1 and the payment will again be done through the blockchain Using a transaction or a sequence of transactions So crucially none of the other nodes will know what h0 of r is unless they know the data and for example the green node can have an association between Database associating possible requests with its data Right. So what are these conditions? I was Talking about and because this is a crucial part of using the blockchain having just normal payments can be enabled through I don't know any other kind of digital payments. Maybe you want to use some PayPal APIs or something like that, but with blockchain we we can establish some some conditions in with this payment Piers Will receive payment only if the pre-image of the first hash so only when h0 of r is Broadcast they don't receive money for a thing because if they did then they can just run away There's a question Is the data payload on the blockchain? No, the data payload doesn't have to be on the blockchain. I think that will That will blow up transaction sizes quite a bit and That's not necessary. I think so n1 well the peers between n1 and the green node can communicate in such a way that Let's say n1 will start receiving chunks of the data And for each chunk it will send back a payment This is basically creating a payment channel between n1 and the green node Right. Okay. So then the second spending condition is the fact that the broadcast of h0 of r will Sorry, the the peers will receive payment only if h0 of r is broadcast within a certain time frame so that's crucial for Having a very responsive peer-to-peer network and for this we do need a very high throughput blockchain that can mind transactions Rapidly so that this answer time is relevant Right. Another thing I want to emphasize here is the fact that the hashes don't have to be Cryptographic or they shouldn't be cryptographic because if they are then it makes it Very high for this thing to work if n1 makes a tie point its request then You know the data will never be found So we suggest using what's called locality sensitive hashes whereby if the hash has a type or then that's still fine either the hash will still be the same or It will just change slightly So that makes it a bit more practical now the peers the blue nodes in this case That's not a problem even if they want to brute force it and find this pre-image haze of r of the request They they won't have time to because if the if the answer time if the if the time frame n1 once answered Within it's like one or two seconds, then they won't have time to brute force and they treat the request or h0 of r So that's That's one observation to how how we can make this work Now before I move on and introduce how we can use the onion protocol and this is for the people in telecom working on Let's say 5g antennas and so on and maybe looking at the internet infrastructure Imagine the red node and the green node are Are 5g antennas and the blue nodes are data centers so In this case, what does it mean for n1 to receive payment to receive the data directly from the from the green node? it does they Communicating directly Will mean bypassing the internet infrastructure or having an additional infrastructure, so that's not Feasible in in a way, so When we the only way n1 can receive in this kind of infrastructure the the data from The green node will have to be from the blue node n1 to So this is why we introduced the onion protocol All or we use the onion protocol To to enable the The data transfer and we do we focus we switch focus on the onion protocol the onion protocol as I said was focused was Was developed with a Non-anonymity goal in mind, but we switch focus from that to payments. So what do I mean by that? if the red node that If all the communication for example is done in clear Right, what will happen? What can happen is that? n1 can for example sniff on the communication between the blue node and the green node Receive the data and never have to pay the blue node ever Right Then you can say okay Maybe we want to encrypt the data with let's say some TLS and n1 can't sniff but then if n1 pays for the whole for the whole chain of transaction payments as it should because let's say it requests a movie and It has to pay the cost for n1 to to relay the data then If we just use some TLS encryption Then well, yeah, a secure communication Protocol then n1 to can just decrypt and also benefit from the data. So that's not good either and lastly my third reason for why we use onion is Let's say Okay, so let's say we we make n1. We make the whole channel of communication use n1's private key to encrypt the whole data. Sorry though. Well the n1's public key to encrypt All the data But then again, we are back to this first case where n1 can sniff on any Segment of communication receive the data for free Right, so that's those are the three reasons why we need the onion protocol and I guess when you deploy it you can use an onion protocol maybe with Two layers you don't have to encrypt for all the hops you just need an outer layer encrypting with the keys of the Current hop and then the inner layer encrypting with the public key of n1 and that would be would be enough right So remarks as I said we can combine the request and data propagation protocols and The pros are we use the same peer-to-peer infrastructure to propagate the data We can control answer to requests using spending conditions but the cons obviously are if we we don't have a very high throughput infrastructure then if we use Onion in the way I explained then this might lead to lower propagation times right Are there any questions until? Okay, then I can move on and I can tie in the story because until now we talked about Payments, but we didn't talk about how we can keep the net and any of the peer-to-peer nodes honest So we for this we will record the network structure on chain Right. So as I said If we do this if we record the network structure on chain then Any dishonest note can be provably identified because many blockchains are public And this can have joining fees and specializations This will be mostly like a byproduct of recording the network structure on chain So how can we ensure that? Nodes are what knows what years are honest in the network peers can monitor each other's activity on the public blockchain and N1 will always maybe have questions like did N1 to forward my request and then one tool can have questions like did I receive enough payment for forwarding the request and all these questions can be Solved if we use a public blockchain where we store the structure of the peer-to-peer network So that N1 can look at the transaction and one to mind and see if If it mine transactions for its peers and similarly N1 to can compare How much it received with how much and one one received So, how do we do this? Let's say how do we record the peer-to-peer network structure when N1 wants to join the network It can establish a connection Handshake TCP IP connection and then for this connection it will send a transaction payment With again with some spending conditions So what are the spending conditions? N1 pays and two for connecting The second is N1 will deposit some additional funds In order to redeem the funds every time N1 disconnects from N2 it will have to signal this and Then it will recover the money. So in this way we can keep an integrity of the network structure on chain Because otherwise N1 could have just disconnected from the network and we would never know it So in this way we offer an incentive for N1 to be honest and signal when it disconnects But still if it doesn't N2 is entitled to receive the funds and then N1 can Specify or update its network. Let's say you have some You want some nodes to signal to the network that maybe they are like They are good for a file sharing or they want to be used some kind of like a DNS type of node you can End up modularizing a bit of peer-to-peer network depending on the rows Right. So finally I want to talk about Sibyl attacks and the Sibyl attacks if they are Executed they can blow up data request payments by for example Freaking a node into thinking it has more peers and it actually has Blow up data propagation payments for example in the onion Protocol It can take a node to think and think so that it thinks that it has The data was received through many many hops instead of just one for example And this can be prevented if we have a third trusted third party whereby nodes are issued some certificates on chain well through web of some kind of web of trust and I think we are achieving a web of trust by having this fairness Furnace type of protocol between nodes where nodes can monitor that he is and they can they They are trying to make sure everybody's Being honest Right Okay, so other questions Right, so I don't know for lightning network The The inner details of the lightning network But we are very much focused in this architecture on providing the right incentives and I think By using a very high-performance blockchain such as VSV you can Handle all the you can you can handle a lot of transactions Directly on chain basically Yeah, I don't know if that answers the question. How do you avoid? Right, should we continue with the presentation or should I answer more questions on? Oh, please. Yeah, continue the presentation. So this is Alex's last slide. So After this, I'll Completely change gear. So I think it's best to ask any questions you want to ask to Alex right now Right, okay. I won't take long for my my bit Right. So how do you avoid legitimate looking nodes from polluting to? load Or otherwise Attack it so I guess this goes down again with The issuance of certificate of nodes on chain and I think once let's let's put it this way Once you detect the nodes detect an attack or you see fees bloating up You can punish your peers by never requesting By never sending requests through those nodes Right and what will happen is that those nodes will never receive payment Payment again. I think this is more it ends up like a very natural economic system whereby if Fees are bloated up so much that nodes don't have any incentives to To pay basically Yes Okay, cool. So then if there are not other questions or one you can take it away Sure. Okay One second, everyone can still see this screen. Okay. Thanks Alex So I think Alex gave a really interesting use case for a blockchain that could allow for A High transaction throughput at a very low cost and that's why we could record all of this data such as the network topology and Request someone asked about the lightning network. So to me if you're not familiar that is a layer to payment solution on top of BTC and My understanding is it's more geared towards payments and then settling those payments on on quite a complex payment channel on chain I don't think it can it can deal with Recording data immutably in terms of requests, etc So talk a little bit more about the type of blockchains that the construction Alex has presented might might be able to handle that type of idea so Firstly, I want people to just shout out at this point. So Can you give me any examples of public blockchains that you're aware of or you're a fan of or you've worked with? Just so we rule on the same page. I won't move on until I hear at least one or two suggestions Ethereum Yeah, if you're in for sure characterized by its ability to Smart contracts on chain and this notion of a global state very popular We mentioned BTC so I won't give you that any others that people have heard of Solana and Cardano. Yes, Solana and Cardano. Yep for sure Okay, thank you ever shout out and that was you Brian. So I've just taken a cup of some of the most Popular public blockchains that I just took from this website the day before this talk So you will see this is cut according to transaction volume. I don't actually think they have Solana here So it's not completely representative, but it gives you some idea of how many chat transactions are going on on these blockchains So Bitcoin BTC with the highest market cap in blue You'll see at the top there. So just a kind of smaller but not insignificant fraction of transactions Ripple has the most and Ethereum close second the one that Alexander and I are particularly Interested in is called Bitcoin SV which is in this kind of light green color and you'll see that represented there in the top left Okay, so it's just some examples of public blockchains and what what are the problems facing public blockchains in your opinion or Challenges we have to overcome. I would say it's proof of work versus proof of stake versus proof of history which is more Efficient based on the use cases Yeah, so it's interesting. So proof of work certainly has a high energy usage Proof of stake is doesn't require any link to hardware. I would say and proof of history is the Part of a hybrid consensus that Solana uses I think So, yeah, I suppose The word efficient Efficiency there is interesting one to pick up on because what what do we mean by that? You know if we use a lot of energy and therefore, you know at the moment see I to to maintain something like BTC, which is quite a low low volume blockchain and Primarily used for for payments and things like that. Perhaps that's not a very efficient use of energy But if we have a very scalable blockchain where You know a lot of people businesses in the world can use it as a kind of immutable record of history then That is potentially much more efficient use of that energy and perhaps you also don't need to use as much So I'll touch on that in the next slide Any others any other challenges? Well, there's the transaction latency transaction throughput. Yeah, yeah, yeah, yeah, exactly So transaction throughput is low meaning it can't be many transactions per second latency I I take that to me when I send a transaction I have to wait until I can be sure that it's actually confirmed on the network So yeah, both those things are our challenges Okay, thank you. So I won't ask anymore there But here are some that I wrote down so they're quite similar to what you've just suggested So high fees is another one particularly on public blockchains low transaction volume slow confirmation times So related to latency Sometimes they just have network outages because the technology is too new Particularly in the more more recently proposed blockchains One that I'd like to touch on is that is a long-term economic sustainability What is the outlook for these blockchains over the next 10 20 30 years? And there also can be issues with the how they've sold the tokens before the blockchain was launched particularly in the case of Ripple and funny enough a lot of these Issues were not present in the original design of Bitcoin I'm not going to all of them right now, but I love to talk to you more of you about that after the talk if you want but for now, I'm just gonna focus our discussion on Well, okay before we begin Is a little quiz so I was at a conference a couple of weeks ago called coin geek and in it they talked about the first the first blockchain and my question to you is Which year was this deployed? Another another related questions. Why is this chat holding a newspaper? Okay, so I'm in the chat said 1998 interesting Are they holding a newspaper for proof of time? Okay, yeah could be in what sense Well like when you have a hostage riding you hold up the next yeah New York Times show proof of life, right? Yeah, that's a terrifying but scary Fair analogy, I think Okay, so I mean one obvious answer would be 2009 when Bitcoin was released. It is earlier than that. Yeah 1998 Does anyone think it's even earlier? Okay, well, I'll put you out of your misery. So let's just play this clip and see what this guy has to say by the way, his name is a Stuart Haber and he he deployed him and his colleague Stuart, sorry Scott Stornetta deployed the first blockchain and here's his little explanation. So I hope you can hear the sound of this and Someone shout out if you can't So with that that is a So Scott and I deployed our system first in commercial in 1995 How did we achieve we we built a blockchain? but we needed to achieve worldwide consensus on Occasional ones of these hash values. Okay, how did we do that in 1995? Actually, we did this already in 1991 when it was still experimental code at at Belcore We built a new Merkle tree once a week out of the block by block hash values and put the root of the Merkle tree in a classified ad in the national edition of the Sunday, New York Times and so this is an ad in the Sunday, New York Times from whenever it wasn't when was that Ian two or three years ago walking through Times Square and I'm thinking it was like 2016 Yeah, it sounds about right. Yeah, and And why why would you put it in the New York Times? Excuse me? Why would you put this in the New York? The point is the point is that? Well here, I've got a little show. It's still happening, right? This here. Let's this is the New York Times from literally. Yes. I could have brought yesterday's today's Monday, September 5th 2021 that's the New York Times That's this one and if you I have to say this The lead story from about a month ago in New York Times was This delicious headline. Oh, yes, which Reminds me of the headline that was in the Genesis block of Bitcoin. Let me read it officials worry as crypto boom Invades banking. That's a frightening prospect, isn't it? Yes but if you follow the if you go to the inside page right there is a surety hash value a hash value of surety that depends on Every bit of the the registration requests received by surety servers in the week before September 5th and Because of the chaining depends on every bit of every request received by the servers Since we launched it in October 1991 Okay. Yeah, thanks for watching that. I mean, I was absolutely fascinated when I listened to this panel So hey, Barang Stornetta, they were referenced in the Bitcoin white paper I think more than one reference actually and they deployed this blockchain in 1995 and it's still going to this day and I don't if you caught exactly what he was saying but the way they did that was They would have a server that the surety server that would receive requests in a week and they would Collect those in a miracle tree just like in Bitcoin So that's a way from going for from a very large number of data entries to a very small miracle route and They published that in this lost and found column Sorry or notices and and lost and found in the New York Times And the reason they did this was because the New York Times was widely distributed, you know across the world in liabilities, etc. And they thought well, this is a Mechanism that's very difficult to cheat, you know, if it appears here then in order to to remove that proof you would have to either remove or edit all of these newspapers and Moreover, it was really a blockchain. So the next miracle proof also included the hash of the Previous miracle route. So it was chained together and the key point here I think is is the public nature of this process. So no proof of work incidentally and I'll send the link to this talk after the in a follow-up to email to this This meeting but even at that time Stornetta the moderator asked him, did you believe your system could scale and he said I had no concerns at all And the reason was they were using this mercury structure that allowed them to very very efficiently scale their system to as many Data items as they needed and their blockchain. It didn't contain a notion of payments It didn't solve the double spend problem, which is what Bitcoin really did But it was an immutable timestamp server of Documents and that was the problem. They were trying to solve it's like if you if you have a digitally signed document How do I know that signature wasn't just put on yesterday? How do I know it really was put on there 10 years ago? And they're very effective in that. So that's going back right to to you know, proto blockchain before Bitcoin then Bitcoin came along in 2009. Well, I mean the paper was released in 2008. It's first deployed in 2009 and There are different approaches along the way and I want to focus on two of them So one is what was called Bitcoin Satoshi vision And the other is Bitcoin core BTC, which is the one you'll be more familiar with which has the highest market cap and they were the same blockchain until 2017 when there was a Difference of opinion in where the where the the protocol should go There are a few differences, but one of the main ones was in block size So in BTC block size was restricted to one megabyte and as far as I can tell this was done for more of an ideological reason so that everyone who wanted to could run a node so if you keep the block size as small that's certainly possible whereas the BSV camp for know this should be market driven and The block sizes should be as large as as is needed for the people who want to use it So let's see where these two block chains have ended up now So the graph on the left try to took from this website again just yesterday The yellow line is BTC and this is average block sizes per day and you can see BTC It's just one megabyte the whole time It will always it will always max that out because there's more there's more demand than can be filled by that block and in BSC you can see It did start out as quite low lower than this one megabyte because it was People it wasn't a chain that people were just starting to use but then it grew pretty pretty quickly to average similar block size to to BTC and now eventually more recently we're averaging over a hundred megabyte blocks this every ten minutes Over a hundred megabyte block size needs to be propagated around the network and The fees are different as well. So it in BTC the fees are rather large I think the average is one or two dollars per transaction and in BSC They're very low and that's this statistic on the right that it's nearly seven thousand times more expensive to transact on BTC And that's in cost per byte So per byte of data, that's how much more expensive it is to to transact on the BTC So if we're characterizing these two BTC has small blocks and very high fees Whereas BSC has big blocks and very low fees and it's called Satoshi vision because it was most Aligned with the original vision of Satoshi through the white paper the original implementation and through the correspondence that keys that he did before He left the project and there was a recent report like an independent study trying to analyze Which blockchain was most closely aligned with the original vision and and that the conclusion was BSV Okay, so this might be all well and good you would say that it's not such a great statement to say well Obviously if the fees are lower then, you know, it's easier to have a higher transaction volume but The crucial part is that the relationship so suppose I Reduce my fees by a factor of 10, but it attracts a hundred times more Users to the system sending transactions then overall I'm actually Going to be an economic advantage And this has the big implication for the economy of the the mining market So the graph on the left has just changed but it looks quite similar and what you're seeing is the fee to Block subsidy ratio of the network. So this is how much Revenue a block generates for a miner. How much is made up of the transaction fee? So in BTC, you can see it's around 10 percent drop down recently to more like one percent and BSV is going in the other direction So it started out quite low which is later that low transaction volume and as the transaction volume has increased fees have remained low but the percent of the Block reward is much higher. So now we're getting to BSV nearly 10 percent and Why is this why is this significant does anyone know I'm trying to parse the The graph a bit about the mining the mining award versus the transaction fee Can you explain again the in that where they converge? One is getting lower mining rewards and higher transaction fees. Yeah, I think so I shouldn't change this before I presented but I think they shouldn't say the word water I think that should be block subsidy. So the subsidy is the fixed amount of Bitcoin that you get for mining a block 6.5 yeah, there actually is sorry it is there because this is there's an implicit subsidy there Yeah, this is the total reward. How much of that which is a combination of subsidy and Total transaction fees and this is what percentage of that is transaction fees well based on that I think the The challenge in the future for BTC is as the having events occur, right? There's going to be less Mining awards. So you need the transaction fees, but you don't want them to skyrocket. Obviously, right? Yeah, exactly that right. So it's the the harvening of the block subsidy So this is the subsidy is the fixed number of bitcoins you get when you find a block and it starts it out with 50 Bitcoins per block in 2009 and the halves on average every four years. So went down to 25 25, et cetera. It's now 6.25 in 2024 so only a few years away. It'll halve them again to 3.175 and we'll keep reducing by half And if you're going to fix your block size, I mean no matter what it is You don't have much wiggle room if you're a minor you want to recover the losses You're making every four years. Then you are going to have to raise the fees So that could be a big problem facing BTC in the future. What do you do about that? I don't know but BSV has this other dimension which is transaction volume. So as long as you keep Increasing your transaction volume, you can make up the shortfall and This graph doesn't quite do it justice because of sorry the previous graph and transaction volume because that was the average per day But in BSV some of the blocks are very small some are very very large and actually a very significant event happened A couple of months ago The first time ever on any public blockchain There was a two gigabyte block on BSV and there was more More revenue in the transaction fee than there was in the block subsidy so we're getting to a point where it's becoming more and more of a Stable economic system long term and so eventually when the block subsidy reduces to zero We're making so much transaction fee by that point. It doesn't matter So this is the long-term economic sustainability of both blockchains and you know It's it's something that's not talked about a lot, but it's very very important And we believe fundamentally the correct approach is to have bigger blocks Smaller fee and a higher transaction volume Okay, so how do we get there and this This slide is called Terra node because Terra knows that a project at Enchain which is the next kind of upgrade to the node software and exactly as the name suggests the goal Is to get to blocks the one terabyte in size And how do you do that? So we're getting close to the limit of scaling up on those software, which means you can If you keep upgrading your computer's hardware, then you can process more transactions You have more bandwidth from more memory But they'll get to a point where you just can't do it on one machine anymore So instead your node will be a cluster and you just keep adding cluster nodes to deal with the the higher Demand and they're actually they they prototype this and tested it They're very confident that they can get close to a hundred percent scale factor And as you people might know being telecoms minded One of the tricky things will be bandwidth So this is a very interesting research question. If you're in the telecoms industry, how do we get? One terabyte size blocks propagating around the network What does that mean for transactions? So I just did some quick calculations and that should be A million transactions a second need to be sent around the network And it's it's kind of different from other types of data transfer in the sense that A transaction needs to be registered at every node. So it's like the propagation of a state update for that particular UTXO So very interesting research question I'm for sure going to have to use expertise from the telecoms industry If anyone is interested in finding out more about that, then please just have a chat with me or Alex afterwards Okay, that that was really it for my part of the talk. So thanks for listening I'm sort of shouting out and I just thought I end with this slide Which doesn't even make sense grammatically, but like what if we're a group of people From hyper ledger bitcoin sv and and the telecommunication industry What do we have to say to each other? And a part of me thinks actually hyper ledger is more There's more ways that Hyper ledger and bsv can complement each other than than other public blockchains because My understanding of hyper ledger is it's very effective in creating private Private distributed ledger networks and perhaps bitcoin sv is the complement to that. So just like In the original blockchain, they wanted to publish A hash commitment of their data once a week in a newspaper perhaps Hyper ledger in a private blockchain context wants to Have some of that in a on a more transparent Immutable ledger. Perhaps it's something like they want the access control structure or identity management On a public ledger, but actually the majority of the transactions will be on their prices could be something like that And yeah, it's the same with the telecommunications network as Alexander I think discussed well about how do you deal with incentives and I read the other day like a very funny story that Squid game which is the show that I'm sure everyone has watched it It became so popular that there were real Bandwidth issues and it wasn't clear who should be paying for that which element of the infrastructure should be Fitting the bill for for all of this extra bandit So yeah, I guess that is a real problem, right if I'm reading about it in the newspaper and perhaps that's something a public blockchain might have Have a contribution to Okay, and lastly, thanks for listening and here's some references to things I've talked about And I'll share this after the talk if you don't learn any more about many things you've talked about So yeah, that's it from from my talk. I'll look at the chat to see if there are any questions So thank you all for the talk and It was a it's neema here. Oh, hi Yeah, so thanks. It was a it was a very interesting talk. Also the use case That we had the peer peer to peer networks. There was lots of questions interesting questions as well and Regarding the the final hyper ledger walking into a bar with bitcoin sv or Really the the idea of hyper ledger and initially was To provide that consortium blockchain space As an alternative to to public blockchains, right? But then as it progressed There are now lots of projects within the hyper ledger umbrella that are trying to actually kind of bridge the Make a bridge between hyper ledger and lots of other public blockchains we have kind of a separate Consortium blockchain that could also be connected to any public blockchain In a controlled manner, of course So it's not really Hyper ledger is not really just dedicated private blockchain. So first of all, there are lots of sub projects in in hyper ledger Well, that's something that we're quite interested in is Can you create a permissioned environment within a public blockchain and you know quite A silly analogy but one that I think is is is maybe fair. This is how I think about it like in the early days of the internet you had Different organizations have their own internet, right? And that worked very well Because they had their own controlled environment, but over time people realized It really does work best if we use one protocol the internet tcpip protocol and If we're careful enough we can migrate our private networks into the cloud And then get the best of both worlds and I wonder if a similar process might we might think about that is happening here Well, I mean, I think that the analogy Does make some sense, but at the end of the day all of these Like when you want to deploy hyper ledger network, you are more likely to use actually the internet infrastructure, right? Because you have to make sure that your nodes are going to be able to talk to each other, right? And you're not going to deploy your own Optical infrastructure to connect the the hyper ledger nodes, right? So you are kind of going over the internet, right? So yeah, I mean and then similar to what we have now with The enterprise networks on the internet. They use their own Protocols they use VPNs and those are the tools they use to kind of create their own island within the the whole internet that we have so I think that's kind of a better analogy to kind of trying to see where hyper ledger and its ecosystem could actually Be relevant in the world of public blockchains Right, but there's no denying that There's that there's market for both of these Let's say and there are lots of good use cases for both of these types of blockchains, right? So for that peer-to-peer network that that we just saw Of course, like a consortium blockchain wouldn't really be kind of ideal for that use case, right? Because you want everyone to be able to join and host kind of peers and in that network But then you have also lots of other use cases where Just you can't even imagine having that use case in a public blockchain, right? So yeah, I mean The thing that I really appreciate here is that We have really similar concerns here because usually when you go to the To the public blockchain kind of world People don't have the concerns that we have especially in telecom sick group We have really big concerns around The transaction throughput and the latency because We can't just wait 10 minutes for the transaction to go through, right? So we really need kind of live information real time Kind of transactions as well. So I think that's something that we can definitely work on Could I tell you now you brought that up? Just how that works in bitcoin SV So as I'm sure a lot of you are aware in btc the block confirmation times are 10 minutes But they also have another feature which Is equally challenging which is called replaced by fee So if I send the transaction to a btc mode and then a few minutes later I send a transaction spending the same output but for a higher fee Then they will prefer the second transaction because they will get a higher fee now In bitcoin SV By the way, that wasn't in the original design of bitcoin in the white paper It says no should accept the first seen transaction And it's related to scaling as well because if you're a node that is dealing with A million transactions a second The the logic of having to replace some of those transactions and all the knock on effects downstream Is so costly that it's not even worth a while to do it So what they did in in tera node is the rule is If it's a first seen transaction We will record it and we pledge to do that and you can you can lean on our reputation as miners to Have assurance that that transaction is the one that will be published in a block and that's an instant thing So as long as I I can as long as I send my transaction to the majority of nodes And they tell me they're gonna It was the first seen transaction Then I can be assured that it will be mine into a block. So we call that um, zero Zero confirmation um transactions and that's why in psv you can send money instantly So again, a lot of these problems at scale kind of iron themselves out Let's sorry to interrupt you. Yeah, no, no, no that that's uh And then we have similar let's say in hyper ledger fabric. There's Mechanisms that allow you to limit the number of verifiers and limit the number of endorsers That you need for a transaction to go through right and that kind of helps with the With the the transaction throughput and latency and so on but at the end of the day We usually In consortium blockchains and private blockchains. We don't really have kind of that concept of prioritizing transactions based on the fees because usually we don't really have Transaction fees we have If you're assuming that there are some partners that are partners in business, they're kind of deploying this consortium blockchain and They don't really need to worry about Kind of transaction fees and they actually don't want to And even if you go to larger scale use cases of consortium blockchains such as iot That's also quite a bit kind of difficult to imagine Asking kind of iot devices to pay transaction fees or charge transaction fees to transmit sensor data to uh to their network and Imagine that the only thing that you're trying to do With the blockchain here for iot is to kind of make sure that it's more secure than the connectivity, right? but then if you if you try to Go to an operator or to a vendor and say we're going to charge you a fee to be able to Transmit your data from your sensors to your network. That's just not going to work uh, usually they're not the big fan of paying fees so And and that that doesn't really i mean you can go to them and say i'm going to reduce the the Transaction latency by 500 percent if you pay certain amount of transaction fee, but that's just not Really they they they prefer to Put in lots of more resources for their let's say Blockchain nodes the central kind of the kind of edge Let's say hyper legend blockchain nodes Rather than kind of paying third party verifiers to actually Verify the transactions. So that's really i'm trying to really at the same time trying to find similar kind of Paths here It's converging on the same idea that If you want real utility, which is high transaction volume and low latency and Let's put it another way For utility you want very low fees and you want your transaction to so you're in a situation where there are zero fees and the question is how do you How do you deal with? Double spends and your solution was you just accept the first one you've seen And that's it and that's very advantageous from a utility perspective because it means I'm not going to worry that in 10 minutes time after i've already sent another million transactions The the first one will change. So we're talking the same language there I think the only difference really is is the fee very very low or is it zero and That's the difference between a consortium model, I guess and a public blockchain And they have different features like you say I say the public blockchain is interesting if we can get to a long-term economics economically stable model Then we can have high confidence that That blockchain will survive forever whereas a consortium You have the advantage of zero fees, but I suppose It will survive as long as the consortium survives It is quite a naive way. I might look at it, but there's the trade-off And also privacy except that you mentioned Yeah, I mean definitely there's I mean there there are ways to solve the privacy concern even okay, but then I don't see any telecom operator Kind of invest like Making their entire network depend on a transaction fee And even if it's very very low now It's going to fluctuate with the price of a coin right, so I mean They Network operators want to be able to predict their costs Years ahead, right? So they're not going to Build in something a fee into their system Even if it's very very low at the moment Yeah, that has the potential of growing. I don't know 10 000 percent in the in the next 10 years, right? That's just it makes it very unsustainable for Yeah, so why why a process that is currently fee free would you ever introduce a fee for I think that's a very fair argument and I wouldn't contradict that I'd say there might be some circumstances, which is not every single transaction, but it might be more like registering nodes to begin with and how you manage The topology of the network that might be something you're prepared to pay a small fee for for that to be quite transparent um, and I would also think of the other The other aspect to this which is not necessary what bsv can do for the telecoms industry, but what the telecoms industry can do for bsv because If we if adoption continues to increase maybe bsv will be the new squid game right where we There's a very interesting challenge there to manage Who is paying for that and how can we make it more efficient? um, and even with you know high volume data streaming you can introduce payment channels where The only on-chain transaction is the final settlement and that you can do using Nakamoto payment channels. So that there you're getting into a situation of pay per second of of Video rather than a subscription to Netflix and maybe that can help Manage that bandwidth Yeah, I mean It is it interesting and one of the reasons that I actually was very interested to invite you guys for the for the talk was that In the telecom hyper ledger telecom sick. We have really focused on use cases of blockchain for telecom What when I saw your use case with the kind of peer-to-peer networks and how they can support let's say kind of a blockchain Kind of or or how blockchain can support peer-to-peer networks and kind of Add some value there It was it was interesting for me because that that's something that we can also move towards uh, so yeah, uh, I think we have to If there are no more questions, let's just close it here. But It was a very interesting talk again. Thank you for For the talk and we would we would be very interested to have you and all of the participants that are now on the call joining our Y-weekly calls It's always always at the same time that does now We have the if you go to the chat we have the mailing list so you can join the mailing list and There's also the link to the wiki We would be more than happy to continue this conversation In our Y-weekly meetings Thanks again My pleasure. Well do right now is if I can just I've pasted the references to the chat if anyone wants to look up some of the things we talked about just then Um, and thanks again for inviting. I was really uh, stimulating discussion and thanks for your Great. Thank you very much on Thank you. Thanks. Thanks, Sarah Thank you. Bye. Yes. Bye