 It's happening. Yes. All right. So we'll kick it off. So I maybe I just said just a few words really just say that this is the first ever telco in Asia Pacific time zone. We normally have India, the other way right all the way over to the west coast of the US so it's very exciting to have this first one in this period and I think different as the chair I'll pass it over to you and we have a great speaker today. Please. Yeah, thanks. Thanks, Julian. And good morning. Good afternoon. Good evening to all of you. My name is Mipin Bhatti and I'm chair of this telecom sick. And so the goal of this telecom sick is to discuss more use cases of blockchain in telecom space and quick introduction like we wrote two solution brief one of like one on integrated settlement second is on IOT and IOT and today we have a talk on IOT as well so and the second one is more on the IOT is decentralized ID and access management for IOT networks. We have a bi weekly calls every Thursday and we have a guest speakers and today this is the first call in Asia Pacific and today we have Ali, thanks Ali for for accepting our request. Ali is in as a research fellow at Queensland University of Technology and today he will talk about blockchain adaptation in the Internet of Things. Thanks Ali and Flores is yours. Yeah, thanks for inviting me. So I guess I can share my screen. So can you see the slide now? Yeah, yeah. Okay, so hello everyone and thanks for joining us. Thanks Julian and Mipin for inviting me and having me here. So today I'm going to talk about blockchain adaptation in the Internet of Things. My talk would be more focused on the challenges and difficulties we have in adopting blockchain in the IOT context. So, yep, let's discuss very briefly what is Internet of Things so IOT is basically the board around us which is getting more connected and more connected. So as we have more devices, we're capturing information about our daily lives and sending this information to say service providers where this data is being captured, processed and then some results being sent back to the devices that can be like actions or some services offered to us. IOT is becoming more and more popular with the sort of services it is offering and the number of IOT devices is increasing in each and every year. And of course this huge number of devices will capture a huge volume of information about our daily lives, about different aspects of our daily life which are shared with the service providers. Currently the IOT ecosystems basically relies on a three tiered architecture where we have the low power or resource available IOT devices like the sensors or even your smartwatch connecting to a gateway which can be in this example we have here it can be like your mobile phone. The data captured by the IOT devices have been sent to the gateway and then the gateway will send it to a cloud service provider for processing and for the services that they offer. So the main aim of having this three tiered architecture is that because the IOT devices have low resources they can't technically afford signing or applying a huge sort of strong security algorithms. So we replace like a gateway in between so that the gateway can handle all those processes and send the information to the cloud service providers. So although IOT offers quite a lot of benefits, there are challenges there as well. The first challenge we're discussing is that the existing solutions as we've discussed are centralized so that means all the communications, communications, authorizations happens through this central controller. So even if two devices are sitting in the same room and next to each other, if they want to talk to each other they have to go through, the packets have to go through technically the service provider. So considering IOT when we have millions of devices, this solution might not be scalable because that's central controller will become the single point of failure or we'll have to tackle with a huge volume of packets. Security and privacy are the other significant challenges. So as I said, so the IOT devices have limited security or limited resources so that they come with even no security safeguards built in security safeguards. The embedded algorithms are quite weak and normally they use defaults and sort of username passwords. So we have seen the mirrored botnet where they use all the IOT devices and then it launches in distributed denial of service attack and those successful actually. The other challenges around the privacy. So all these devices, all these sensors capture quite a lot of information about our daily lives. I assume that in your smart home you have motion sensors, you have smart lights and do a smart doorbells and all these things that capture information about your daily life. So the service providers will technically have huge volume of information about you about different aspects and technically they can build a virtual profile about you which will compromise your privacy. At the current and existing ecosystem, all the IOT data has been stored by the cloud service providers. So they maintain the data, they sort of process the data so as the user you have no or very limited control over your data and you can't particularly monitor who the data has been shared with but the processing has been done on the data and all these things. So you technically trust that the service provider is actually doing is technically honest and wouldn't do anything malicious against using your data or selling your data to someone else. So would there be any solution to these challenges and a couple of other challenges that exist in the current IOT ecosystem. So in this talk, we're going to discuss how blockchain can tackle these challenges and and can benefit from that. So given that this is a talk in Harper Ledger, so basically skip the basic introduction of blockchain. So I assume that everyone in the call will know all the basics. So but what are the salient features of the blockchain that we can use and which makes it attractive for IOT. So blockchain offers like a distributed management system. So in blockchain we don't have any central server. So all the nodes are peers so they can communicate they sort of share information and all together manage the system and reach consensus over the state of the ledger. So in blockchain, sort of modifying or removing the contents of the blockchain database is impossible, which is called like immutability feature, and that creates like a very attractive feature for IOT that it offers also auditability and traceability because all the historical transactions are being stored in the blockchain and will be there permanently technically. Blockchain achieves sort of distributed trust. So two users might not necessarily trust each other but they can trust the system, they can trust the framework, and they can trust that if something is happening on the blockchain according to the rules and the agreements then they can trust on the other participants. Like when you're trading Bitcoin with someone else, you don't know that person but technically because you trust the system so you will trust that actually that payment will happen. And anonymity is the other feature which is interesting in blockchain for IOT. In blockchain the users are known by a public key and sort of we don't know about their real identity. So this makes them anonymous and that can be an interesting thing for IOT, although it has some limitations as well, which we will discuss more. I mean despite this interesting features that blockchain have, I mean applying it in the IOT context isn't straightforward, so it involves a couple of challenges. Today we will discuss about the scale and overheads, memory footprint and anonymity and privacy challenges involved with applying blockchain in the IOT context. So it works mentioning that by saying blockchain we basically mean public blockchain like Bitcoin and Ethereum where the users can join so some of the discussions we have. So with the private blockchain because of the scale because of the trust levels, it might not be that much huge or I mean of course they are still a challenge, but it might not be that much huge. But most of our discussions are around public blockchains. So scale and overheads, in a blockchain system transactions and blocks are broadcast and verified by all the participating nodes. So that means if a new transaction, if a new block is generated in the network, it has to be broadcasted and this ties back to the distributed management of the blockchain. So where we're saying everyone can participate in managing the system. So at least if you want to receive this information you will receive all the new blocks and the new transactions. In a blockchain system multiple validators may attempt to sort of same block simultaneously so that means, I mean we have also some sort of leader selection algorithms where you have like a leader, which will store a block in a blockchain a particular block. So then this wouldn't apply to them, but most of the existing consensus algorithms have like a leader. They are in a way that multiple validators simultaneously work on a single block, and then the one that solves the puzzle or follows the consensus algorithm sooner would be the winner and can sort of store the his block into the blockchain and the rest has to go and proceed with the next block. So this sort of lacks efficiency in the context of energy. So we have delay and processing overhead for retrieving previously stored transactions in a blockchain. So in crypto currencies, this might not be that a big problem because it's just one transaction before. And there's no that much frequent access to the data, but in IoT we technically demand frequent access to the data which has been stored for instance. In a supply chain scenario, we need to go back and retrieve the historical view of the transactions and of the particular product to make sure that actually it is it comes from where it claims right so then we need to frequently access the previously stored information. So in blockchain committing new blocks demand resources this is ties back to the consensus algorithm. So this resources can be computational resources bandwidth. And also it has the delay in committing new transactions. There is a sort of a non trivial delay which is even more in the public blockchains because to make sure that actually there's no malicious activity there. So we have to sort of add this delay a bit. And also the nose have to agree on which state of the ledger and also receiving confirmation that is sort of to prevent double the spending. We need to receive confirmation in the blockchain system to technically make sure that our transaction will be stored in the blockchain. Most of the existing blockchains suffer from lack of throughput. I did total number of transactions that can be stored per second. And that is sort of a very huge problem in IoT because in IoT we have like millions of devices millions of transactions. And so the system should be a scalable and should have that throughput to manage all this information so technically if the system doesn't have that through though there would be more delay even more than the existing delay with the consensus algorithms so that sort of create a big problem. So why scale and overheads and all these things that I've discussed are challenges in IoT because the IT devices have limited resources technically it can be computational bandwidth storage or energy. So they don't have that much of resources to spend on on this management of the blockchain system and their resources should be spent wisely for for their own operation. So they're real time most of the IT applications demand real time transaction settlement. For instance, if you are in front of your door you want to open the door. Technically you can't wait for half an hour to do it to reopen. As I mentioned in IoT we demand frequent access to the data and to the to the technical transactions that we have stored because we want to audit. We want to make sure that everything is happening correctly and we need to sort of verify the integrity of information. And the other problem is that the number of participants in the blockchain, the services that are the number of participants in IoT, the services that they offer and all these are ever increasing. So new services are introduced, new people join sort of millions of transactions just join and added to the blockchain system and to the IoT system. So there are some solutions proposed to address these sort of challenges in the literature. I will discuss this in a very high level and sort of category or way. So the first group of solutions are the hierarchical approaches where, instead of having all the nodes in a single flat sort of blockchain layer, we will create so private chains in different levels and the transactions in each level or broadcast only among the nodes in each level and sort of each blockchain is connected to the pattern. That can be by storing the hash of the blockchain or any other method. So this will sort of to some extent address the previous problems that we have mentioned, for instance, you don't need to broadcast and verify everything in the main chain, sort of the number of transactions in the main chain will significantly reduce because more of the transactions will be in the private chains, sort of they will be stored here, it will introduce more sort of privacy because less and less amount of information are stored here. And also it will be easier to manage. But there are some drawbacks like centralization and the delay in both. Shorting is another solution proposed in the literature where we create parallel sort of ledgers where the participants in each of the shorts or the group of nodes in each of the shorts will only manage the transactions within that chart. And then sort of limiting the number of nodes in each sort and then they can communicate with the other nodes in the short. So technically, as sort of David mentioned in theory that the increase in trans transaction throughput is linear because I mean, if you have four shorts, then the throughput would be four times more than the truth without a flat sort of blockchain. So challenges as well here, for instance, how these shorts can talk if a transaction involves or needs verification of another transaction in another short or if they want to talk. But shorting is also a solution that has been proposed in the literature. So initially, blockchain came with Bitcoin and the proof of work. However, we all know that proof of work isn't that much effective in terms of energy and all the challenges we have mentioned. So new consensus algorithm have been proposed in the literature like proof of a state where the validator of the next block is sort of decided based on this the amount of the state the lock in the blockchain and then the more the state you like the higher would be the chance of being the next validator. The proof of lap time is an algorithm proposed by Intel technically it's, it depends on the, it relies on a hardware Intel CPUs, and the way it works is technically saying that whenever I know that our validator wants to generate a block. So you have to wait for a particular period of time for a random period of time and that random period of time is generated in a trusted execution environment, which is built in in Intel CPUs. So that means, and, and that is in a way that others can also verify that you have waited for that period of time so that technically means that this algorithm will rely on would require all the participants to to sort of have Intel CPUs. So the authority again is a consensus algorithm based on the reputation of the nose algorithm also uses a kind of sort of a version of proof of a state where sort of depending on the depending on your assets that you have in the occurrences in the system. They will select the committee of the nose and then from that committee one of the nose will be selected as the validator of the next block. I mean, of course we have all these optimized consensus algorithm and many more consensus algorithm that are even before each and every day. So they have some limitations like throughput management so when we're talking about throughput management it's not just saying having high throughput. We in all your TV demand the system which would be self scaling. So that means if the number of transactions increases if the load in the network increases the system should be able to handle that overheads in terms of computational bandwidth overhead efficiency as we discussed most of them work on in most of them multiple validators have to work on the same block and the delay in committing transactions as we discussed. So I'm just discussing some of the solutions that we have proposed in our earlier researches. One solution is called light with scalable blockchain or LSV that we have proposed in 2017 and the extension version published in 2019. So based on LSV we so LSV technically relies on a network which is cluster. So that means we have the overlay network the overlay network technically is the blockchain network peer to peer network. So we divide the overlay network into different clusters and then the clusters only the cluster heads which we call them overlay block managers will sort of participate in managing the block. So that means the cluster members don't need to be involved in the in management of the blockchain they don't receive the transactions and blocks and only the transaction of lots of broadcast among the overlay block managers. So we have proposed a couple of algorithms like a distributed time based consensus algorithm distributed thrust algorithm and throughput management algorithm which I will go through them and sort of briefly mentioned explain the fundamental concepts in LSV with separate the traffic flow or the transaction flow from the data flow so if a traffic or transactions are broadcast we don't broadcast the data. So IOT data is a sort of the chain which is common in most IOT applications and the overlay block managers will also do access control so that means the cluster members can set policies on who can access them. And then the overlay block manager will follow those policies and forwarding the transactions and blocks to each of the cluster members. So the spam accounts in LSV we are relying on a certificate authority that the nodes needs to receive a certificate from certificate authority or they need to bear in point in a Bitcoin system so that they will be able to create an account in LSV. Okay, so the first algorithm that we've proposed is that distributed time based consensus algorithm DTC. And the high level concept is that we're saying that one each validator in the network each OBM can generate one block per consensus period. So, for instance, here the consensus period is 10 minutes so each of these nodes is allowed to create one block per 10 minutes. So there would be a random waiting time before block generation to prevent sort of simultaneous stories of a block. And also to ensure that the nodes will follow the algorithms we rely on neighbor monitoring algorithms. So we're saying for instance in this example, assume that this OBM is a malicious node and creates blocks in one minute time intervals. So what will happen is that the neighbors will receive the block they will verify the first block and they will broadcast the first block, but the second and the third block wouldn't match with the consensus period because the consensus period is 10 minutes so this node has to wait for 10 minutes to be able to generate another block in the blockchain. So then the block two and three will be discarded by the other participating nodes. So then technically the security of LSV will rely on neighbor monitoring algorithms. So as I mentioned in conventional blockchains the nodes has to sort of verify all the new blocks and transactions. And that will create a huge overhead for even verifying what has already been stored in the blockchain. To address this limitation or this challenge, we introduce a distributed thrust algorithm where then it relies on two trust models like the direct evidence on indirect evidence. So the direct evidence is if Clusterhead A has previously verified a block generated by Clusterhead B then they have direct evidence. And indirect evidence is if Clusterhead A has not previously verified something generated by Clusterhead B, but it has verified something generated by Clusterhead C and C says that B is trusted. In that case, if there would be an indirect evidence about this block generated by B. So they will build up trust as shown here as the number of previously validated blocks increases. You can see that then the percentage of transactions that need to be verified in a block will decrease. This table is just an example. The point is that the percentage of transactions that need to be verified never should reach zero because there's no absolute trust in the network. And it has to be defined based on the number of validators, number of Clusterheads in the network. Okay, so this will will sort of help reducing the overheads and this percentage is sort of a randomly selected number of nodes in the in the new blocks to make sure that actually if there is a invalid transaction for at least one of the nodes in the network will be able to capture that. So we talked about the throughput management algorithms. So we're proposing a distributed throughput management algorithm where we are defining a utilization value. The utilization depends on n which is the number of nodes in each cluster, or which is the load of them and the consensus period, divided by Tmax which is the maximum number of transactions in each block and the total number of OBMs in the network. The thing is here is to sort of keep alpha between an alpha min and alpha max, which can be like zero and one. And if alpha exceeds alpha max, that means the load is more than what the network can store in the blockchain. So what will happen is that LSP has two tunable parameters. So one is the consensus period. So we're going to reduce the consensus period. So that means previously, for instance, the consensus period was 10 minutes. Now they will reduce it to five minutes. So that means they can store more transactions. But then there is a minimum threshold for that, which is the two times a maximum end to end delay in the network to make sure that actually in the new block generated will reach to the other nodes in the network. And then the consensus period hit that minimum. What they will do is that they will tune or increase the number of overlay block managers in the network, or increasing the value of M. This way, actually, the LSP ensures that they can actually manage the throughput and achieve self scaling. And the beauty is that it not only manages when building increases, but if the load even decreases and then we have more throughput than what the network requires. It can reduce the number of blocks or the consensus period in a way that the resources are not wasted. So here a couple of results with probably a little skip just in the matter of time. So we recently are working in another project called three chain project where we are trying to build a new optimized blockchain for it considering different aspects of the blockchain. Our first work is on the consensus and on the computational overhead around consensus and delay, which the results is in the paper calling three chain and architecture is shown here. So the key concepts between of the three chain is that we will have instead of having a single ledger. We are having multiple product ledgers that each of these ledgers is managed by a particular node in the network. So let's say that in particular validator. So we have as you can see here, five validators in the network. And these five validators, each of them will manage one of these letters. So then they know. So they know what they're supposed to manage and what they have to do in the network. Some very basic concepts. Three chain relies on the hash functions. So hash function is the main point or the main function that three chain is using, which is in all the blockchains. So in a hash function, the output normally is something like this as alpha one, alpha two and the K would be the size of the hash function output. So technically what three chain is doing is that we are defining the consensus code range. So what is consensus code range. It refers to the most significant bits of the hash function output. For instance, if the size of the consensus code range is one, then it would be just alpha one. And then the size of the consensus code range depends on how many validators we have in the network. So for instance, you can see that the possible values in the hash function can be like on numbers or alphabets, right. This would be like 62 values. So if you have 63 value validators in the network, then the size of the consensus code range would be two. So we also defining a vague dictionary, a vague dictionary is the weight corresponding to each possible value in the hash function output. And for instance, that is each of these values is allocated to a weight in the network. And we have a key weight metric, which is the metric referring to the cumulative weight of each hash function output, which can be technically a public key. For instance, to calculate the KWM for this public key or which is this is like the hash of the public key. So we would say based on the disk weight dictionary, we will grab the weight corresponding to each of these values and 482 would be the KWM value for this public key. So again, three chain is a leader selection algorithm. So we select a leader for each of the ledgers and we rely on the hash function output, which is sort of a hash function output is a random algorithm. So we rely on the hash function output for managing this and for selecting the validator of each blocks. So the randomization achieves in two levels. The first level is the transaction level. So what the transaction level means is that for each transaction, the validator is randomly selected based on the hash of the transaction content. So, for instance, here, the transaction ID or the hash of the transaction content starts with a letter D, right. So, and from the table below we see that this public, this sort of validator with ID 13 with this public is responsible for storing transactions that the consensus code range starts with D, right. So that means we randomly allocate each transaction to one of the validators in the network so that, and the other one is in the blockchain level. So the blockchain level is that, again, we randomly allocate the consensus code range to one of the validators. So during the bootstrapping, when we generate this node, we will sort of gather information about all the nodes that want to be validators, and we will divide the can prepare the like the consensus code range, depending on their, how many nodes we have. And then we will say, for each of these validators, we calculate the KWM, the node with the highest KWM would be allocated the first consensus code range, and so on and so forth. So, for instance, in here, we see that the node that is responsible for this letter is the node who has to collect all the transactions where the hash of the transaction content starts with letters A to M. So this way to reach and technically achieves two levels of randomization, where a validator is randomly allocated to a consensus code range, and a transaction again is randomly allocated to a validator in the network and to achieve the security. So there's no other sort of algorithm needed to follow for starting or committing new blocks to the blockchain. So that means that makes reaching actually very fast. So once a node receives a transaction that falls within this consensus code range. So it has to just collect them when the size of the pending transactions reached the predefined threshold, then it will broadcast a new block. And the thing is that because they are chaining to their own ledger, they don't need to wait for, and there wouldn't be any forking technically because each of these ledgers, each of these ledgers has a unique validator dedicated to that ledger, which always they know, and the hash of the previous ledger. In some cases, the load in the network may increase over time depending on what's the period between reforming the network or creating these two different genesis blocks. So then if that's the case, a node might request for a new validator to join the network and then they will divide the consensus code range between each other. So in this example, I'm create a forking in the network. So, again, the hash function is random we we can't guarantee that the load will be exactly divided between these two nodes, but at least it will be reduced. And the ledger reformation is that to prevent the nodes from malicious activities and all these things so during each epoch times. If the node has to reform and restructure the network, they will create another genesis block, and all the nodes has to select a new public key. And if the new nodes want wants to join, they will they can join and then a new sort of ledger and new allocations will be created as you can see here we have more validator so the consensus code range is now smaller than the double the spending. I mean, through each end is basically developed for all your two applications where we we don't have that module of transferring assets, but there are cases that we need to transfer assets and we need to protect against double the spending. So we are discussing how to each end will protect against double the spending. And one way to to for successful double the spending attack, because that remember that the hash of the transaction is random, right. So if you want to create the two transactions then technically they have to go to two different validators you don't know who that validators would be. What we have here is that the validator of the input transaction has to sign the transaction that is going to be a spec. So that means if I'm validator a, and I have received the transaction that uses a transaction mind by validator be as the input. Then I have to sign send this transaction to the valid to validate or be and ask so you can you should sign this transaction for me. And then when that validate or signs that transaction. So that means this transaction has not been already spent. So when the validator be signs that transactions, it will set a flag for that transaction saying that this transaction has been spent. And it will send the signature to me and the sign transaction to me, I will use and I will destroy the sign transaction to the blockchain. So now that the only possible way to do this attack is that I'm controlling validator be. So if I'm controlling validator be then I will technically sign the both transactions saying that it's not been spent while I'm sort of malicious and sort of claiming something for false. So what will happen is that over the time. So when the other validators would receive these blocks, they will verify and they will make sure that actually if there's a double spending or not. And then it when they detect that they know who is responsible for that because it's only the validator be who is claiming false so we know who to blame. And that's like another beauty of three chain which which makes which makes it clear who is responsible for the attack. And then that note will be isolated from the network. Okay, so some of the results as you can see here. The processing overhead for storing a new transaction in the blockchain is quite low. And which makes three chain quite fast in terms of storing new blocks and new transactions in the blockchain. So here's the load balancing which I will skip and another aspect of three chain is because of because we know where each transaction has been stored. So we technically. So if you want to retry the transaction. We don't need to go through all the database or the blockchain database, we technically can only go through and search in the ledger corresponding to that transaction based on the hash of the transaction content, which significantly reduce the retrieving time. And as you can see as the number of validators increases, the number of transactions in each ledger will decrease technically, and then it will lead to shorter period of time for session. So that means we technically when we are storing information in blockchain we are categorizing them to reduce this time. Okay, so this is all about scale and overheads. So what we're going to discuss would be about the memory footprint of the blockchain or the storage aspect of the blockchain. Blockchain is immutable, right. Immutability helps security helps auditability has to protect double the spending attack. But there are some others aspects of it as well. So it will face with an ever increasing database, which we can technically remove information from that database. So the size of the current Bitcoin blockchain is 310 gigabytes. And consider an IoT with millions of transactions the size will be significantly larger and sort of how we can how we can sort of manage this database. So what we see is another issue so blockchain will when you saw something in blockchain that will remain there, right, so you can't control anything. So what if one of your keys is leaked or what if using techniques that I will later mention someone de anonymizes you, and they know your real identity. They know your real identity they know your keys and technically all your information is in the blockchain. So you cannot do anything about that. So they will have all the information there. Of course that the data normally is encrypted and normally is not the sort in the blockchain but even the pattern of communications and even the pattern of interactions would be enough for the attackers. Regulations like GDPR, the users and the users demand the right for the data to be forgotten. So that's not possible in blockchain and also what if someone stores something illegal in the blockchain database, how can we tackle with that sort of in the illegal information in the block. So there are some solutions proposed again in the literature, and one of them is to sort of data off chain. So we will sort of data associated with the oddity devices in an off chain database, and we will have the hash of that data in the blockchain as a sort of evidence that we will we will not change the data over the period of time. Of course this will help improving or reducing the size of the blockchain database but again, we will still need to store millions of transactions in the blockchain database, which will again increase the size of the database. Some algorithms like the chameleon hash function they allow you to modify the data, but still have the same hash value or still be able to validate the same hash value. So this way you can technically create and use this type of hash function, and then over the time you can technically modify the data or modify transactions or modify even the content of a block, and then still ensure the blockchain consistency. And you can see here a very high level view of how chameleon hash function works is when you want to generate a key will input a secret value, it will create a hash key and a trapdoor key. So this trapdoor key is technically the key that you will use for creating the collision. So when you want to create a hash, you will send the message the hash key and there would be an string and a hash value as the output. So you will require this string for verification and this is string is technically what allows you to sort of create a collision. When you want to create a collision, you will send the new message, the previous message, the hash of the previous message, and the trapdoor key and the string of the previous message to the algorithm, and it will create a new string. So that new string can be used to with the verification algorithm to sort of any with the new message, and it will say that it is verified and the hash will match right so that that prevent any inconsistency in the network. Other methods will rely on summarizing say, of the transactions, like mimble mimble which is employed in Bitcoin. The idea here is that when you have a group of transactions, so technically what you can do is that you can group them as one transaction, and you will ignore the transactions or input outputs that are already spent in this transaction. So for instance, transaction one output two is used as the input of transaction two, right, so we don't need to include neither output two nor input five in this final transaction. And, but for instance here output two is sent somewhere else probably will be will be used somewhere else in the network in the future transactions so we need to include it in here. There was also encryptions for the input output values and other items that mimble mimble reuse but this is the very summary of what they do to sort of make sure that the database size is small. We have also proposed a solution called move PC memory optimize and flexible blockchain which will allow the users to sort of experience the right to be forgotten for the data to be forgotten and allows the users to remove information from the blockchain. Technically what we are doing is that we are introducing a new layer called more PC layer on top of the blockchain existing blockchains. And then this layer will manage all the removal of removal of transactions. So very hard level view on how it would work so is that technically in conventional blockchains when you want to calculate the hash of the block, you will have the content of all transactions and the block header. What we are proposing is that instead of the content we technically can use the transaction ID which is again the hash of the content of the transaction. And if we want to remove a transaction we simply will remove the content but keep the keep the transaction ID in the blockchain. So that means still there would be a level of auditability there would be the nose will still be able to verify this. And to verify all the transactions. And the consistency is maintained. So, in all your users demand different types of flexibility demand their flexibility and storing the transaction so you don't need you don't necessarily might not need to store your transaction permanently. Say that you signed a contract with the service provider for one year after one year you don't need those transactions as a record. We're introducing temporary transactions for these cases. We're introducing summarizable transactions where I mean this is similar to the concept in mimble mimble but all these transactions belong to the same user. So in mimble mimble it can be different users. We're saying that each user can summarize all this transaction to a single user transaction, which will contain all the information about this transaction so that means the auditability will still be achieved. But you have to technically store this transaction off the chain. So changing means that if you're if the transaction has the hash of a data which is stored in a cloud, you technically can remove. You technically can compress that data in the cloud to return to save to help saving the space, but you can update your transaction in the blockchain to refer to the age data and the permanent, which is as always. In most BC we are introducing a storage free, which is basically in conventional blockchains they charge for the computational resources they need the validators need to allocate. But in most BC we are saying that in IOT storage will also be something important so we have to go charge the users for the amount of transaction they start generating and to be paid for the to the nodes that is stored the blockchain. So this is basically saying how the share for each of the nodes that are storing the blockchain will be calculated in summary it's like what is the size of the blockchain. What is the amount of the database you are storing and for how long and depending on that there will be a share for each of the nodes. So even this storage we will motivate and incentivize the users to remove the transactions from the blockchain saying that if you want to generate a new transaction and you had a previous transaction in the blockchain. So why not removing that one and in and you can store a new one for free. So that means you wouldn't need to pay the storage fee. So this way we'll try to incentivize the users to remove transaction otherwise the user might not find enough incentive to remove the transactions from the blockchain. We allow transaction removals to be to happen in different layers in the user can remove a service provider can remove. This is in a case like a user is hacked or is malicious and storing something legal and the network can do it. For instance if a user wants to offload all the overheads to the network. When a user or a service provider wants to remove a transaction and that transaction so that means transaction has is already in the blockchain. So the first step is that you have to prove that you are the owner of that transaction so how you will do it normally you use public key and signature. But then in all your team and we have millions of transactions and each transaction probably with a new public key, how you're going to store all those public keys and keep track of which transaction generated with which of the public keys. So then the key management would be a problem. So we are introducing generator very far concept so this is basically saying that we create the hash of assigned value, which is the previous transaction ID and the secret value. And this would be unique for each transaction so that means for each transaction this would be unique and to show that you are the owner of that transaction. You need to reveal the, you need to prove that you know the private key associated with this public key. And you know also the hash of the gbs. So this will help the other notes to create this value and then also create this value sort of to prove that you are the owner of that transaction. So basically with the network doing that, so you don't need to tackle or struggle with the key management because you will have all these, you will say to the network that you have to do with this and you will set up the conditions when you're generating the transaction so that that means all those information is included within the, the signed hash in the transaction content, and we will introduce fields like memory optimization mode and the memory optimization setup. For instance, if it's a temporary transaction, then we have to remove the transaction from the blockchain. Some of the results that showing that it would improve the memory overhead. And here is a recent work and again tackling the same problem. But here instead of having the move BC layer on top, we are introducing a layer between the peer to peer network and the main chain. So technically we are saying that if you want to store information in the blockchain, you should you can decide on whether you wanted to be permanently stored in the public blockchain. Or you want to start it in a sort of a temporary chain where the data would be immutable would be trusted for a particular period of time. And after that it will be removed from the ledger. We introduced two techniques. One is blackboard so blackboard is technically a public database where everyone can sort of read, but no one can write on the authorize users can write. And this is building on the assumption that there is a trusted third party there. So we studied this in the context of energy trading. The assumption was that so we have the grid operator and we trust them basically they are running the network they're providing with the like transmission lines and all these things. So we there is a level of trust there so then we can use that trust level and saying that okay you manage this database. So if we don't want to trust anyone, we can technically have a removable ledger applying the same concept as move BC, and saying that all the transactions here would be temporary, and this removal ledger would be managed by the validators in the public blockchain. So that means in a public blockchain if you're generating a new block. Technically, you will also add the hash of the transactions in the removal ledger from your perspective. You can also create a new block in the removal ledger. And then you will broadcast both these blocks, the new blocks in the main chain and the new blocks in temporary chain. And if your block has been accepted in the main chain, your block will also be accepted in temporary chain. So these are basically the solutions we had and the challenges for memory optimizations. And that last but not least a very important problem is around anonymity and privacy. We know that blockchain is anonymous right so we know that one, all the users in the blockchain system are known by a public key. So, and this public key can be changed per transaction per device. So that means if Bob has 10 devices, each of those devices will have a different public key and and each transaction generated by that device will have will be using a different public key again. So anonymity basically has been studied in cryptocurrencies. So at least we haven't found any sort of work doing anonymity around. IOT applications in in blockchains. So most of my discussions will focus on cryptocurrencies but the same concept can be applied on on other blockchains in other applications as well so that means the concept would be similar. We have different attributes for anonymity. One is the anonymity of an entity so we're saying that when an entity is creating something transaction in the blockchain, you others shouldn't be able to find out about the real identity recipient anonymity means that if I'm transferring assets to someone that was the person who is being paid technically it's identity should remain anonymous. We shouldn't be able to link different transactions or even trace different link different transactions to a user or trace the previous transactions generated by the same user. The values used in the transaction like the input output values should should be remain hidden or technically they were using encryption for this part. And metadata linkability which is more common in IOT so when we have metadata we should make sure that actually with having that metadata someone else cannot sort of find out about our audit transactions or try to link different transactions that we have generated to a single and then sort of create the pool of our transactions and try to de-anonymize us. So then you know the know ability is also something that is the future of encryption. So user de-anonymization or the attacks against anonymity and privacy in IOT. One way to do the user de-anonymization is to have an active interaction with the user. So that means if a user is offering sort of if a user is selling something using Bitcoin or something then we can try to avoid with different public keys and try to capture the public keys they use the information they're offering and using this information try to sort of gather information and sort of de-anonymize the user. We can also analyze the network traffic in terms of the IP addresses linking them to the users or the network level traffic. So this is basically saying that in blockchain we have entry points. So that means when a new nodes wants to join the blockchain system they have to go through one node to connect them to the network. So you can join and sort of listen to the nodes who are connecting to that entry point and sort of link the IP addresses of the nodes with the public key. We can also analyze the option data. It's like a company might reveal their public key in their website and so a user might reveal their public key in a forum or something like that. But the most complicated way of sort of analyzing the transactions is through the transaction graph and the address graphs. So basically here the concept is that say T1 is a transaction, it uses two public keys as the input and two public keys as the output. So with the transaction graph we're just simply creating saying this type of graph saying what is the transaction, what are the inputs and what are the outputs. With the address graph we rely on some sort of concepts. For instance one is if a user is sort of spending two transactions as an input. So then these two transactions belong to the same user. So that means that's technically because the user knows the private key corresponding to both of this right. So that means here we can say P1 either belongs to P7 or to P8, technically to the owner of P7 or to the P8. The same applies to P2. And sort of using this way we'll create an address graph which we then can analyze and go to a user graph which we would say what are the transactions or what are the public keys a user has used and what are the transactions be and sort of trying to de-anonymize the users, which is a bit of a complicated method. But the studies show that it can be successful. How to protect against these attacks? Mixing servers. So basically they will receive some inputs, they will generate outputs with new keys and sort of mixing the previous one, removing the historical view of the transactions. We can rely on cryptographic methods like line signature when you hide the actual value of a field but the others can accept it and can sign that value. We can use the ring signature to remain anonymous among the group of nodes. So then technically we don't know what exactly is the node or which of the nodes has actually signed the transaction. But we know that one of the nodes in that group has been. And another very interesting aspect is when machine learning comes into play. So we know that in IoT all the transactions will correspond to the, I mean, they can be generated by devices, right? And they may or may not include data. So let's assume the worst case, let's assume that we don't have any data. Or the data has been encrypted, right? But all we have is the sort of transactions generated by devices and we know that, right? We know that they are generated by devices. The thing is that the devices will generate transactions with a particular pattern, right? The same concept applies to IoT even where you can sit in the network traffic and listen to the traffic and based on that you can say what type of devices you might have in the network. The beauty of blockchain is that you don't need real-time access, right? Because blockchain has the historical view and information of the system. So what you can do is that you can apply machine learning algorithms on top of blockchain and train your algorithm with the different datasets and see if any of those devices are installed in an IoT setting. We have done this in an IoT, in a smart home setting. We used a smart home database traffic dataset. We populated a blockchain accordingly. So for each of the communications, we created a transaction. There was no data stored on the blockchain and that was being stored in the blockchain database. On top of that, we applied machine learning. So we applied different type of machine learnings here on discussing the informed attack type where the attacker knows the type of devices. So that means the attacker knows that this traffic comes from a smart home, right? And it knows that technically what devices can be stored in a smart home. So to protect the privacy, we have proposed some obfuscation methods like we propose delayed transactions where instead of when a communication happens, you wouldn't immediately create a transaction. You will wait for a random period of time and then you will create a transaction. When we have multiple nodes for ledger, so that means the transactions in a single ledger might be shared with multiple nodes and then we have multiple packet per transaction. So that means say that when the device created 10 packets, we will create a summary of all those 10 packets and create a transaction accordingly that will be sent to the blockchain. So all these methods will create the patterns, right? So the way that machine learning is using to identify the users is technically using the patterns that there exist in the transactions and in the transaction flow. So here you can see that when we have the different number of devices per ledger, you can see that initially when we had two devices or one device that we had very high success rate. We actually could classify the type of devices and it increases to 50% where we could classify and we could say what type of devices has been installed in that smart home. And you can see that the obfuscation methods we're proposing will reduce the chance, but it's still there is a chance that detecting that what devices have been installed and compromising the privacy. So here as well you can see that again we use multiple packets for transactions. You can see that we are still able to sort of identify what devices have been installed and what using multiple packets will reduce the chance. And the same concept applies to when we have multiple devices per ledger. So these results basically show that when we have blockchain, we can, blockchain for IoT, we can apply machine learning and go through on top of that to identify the users and to link, to identify the devices to identify and then link that devices to a particular user. And that will be like a huge risk against privacy because remember that we said that blockchain is immutable that all your history of information will be publicly available in blockchain, and you can't do anything about it if the users are successful in de-analyzing you. And technically, it would be there forever. There are some other challenges around anonymity in IoT as well and that's the tradeoff that we have between privacy and trust. So if we want to trust someone, we have to know who they are, right? But in blockchain system we technically don't know who they are and because the other user also don't want us to know. Let me explain that through an example here. Assume that this is an energy trading example. This home on the left side has a solar panels as excess energy, you want to sell energy. And the other home here on the right side as basically is a consumer. It needs energy. So the consumer wants to buy energy and there are nodes in the network saying that, hey, we are, we have solar panels, we have excess energy, buy from us, pay us that I will send you energy. How this consumer can actually trust that the node who is saying I'm a smart, I'm a solar panel is actually solar panel or has excess energy. How we make sure that it's not an attacker that wants to sort of just charges for nothing, right? So here the consumer demands to know that when you're saying you're a solar panel or you have excess energy, I have to make sure that actually you're right. But again, the producer don't want to reveal this identity because if it's revealed the identity then people can track the energy consumption generation, people can track the profit it will get for selling and for selling the excess energy and all the information, such information. And even they would be like safety concerns because if you know the energy consumption, the real time energy consumption of a smart home or the home, you can technically guess when someone is home or when someone isn't home. Ali, I think we're over the hour now. I think this is my last slide. Yeah, we'll quickly go over that. So, so we proposed like a solution for that, which is a certificate of existence saying that so here we are building on the concept that the smart meters have trust each other. And they're tamper resistance basically. So what is happening is that the manufacturer of the smart meters will generate a set of one publicly private keepers and then they will populate that in the meat and the smart meter. When the meter is deployed, it will generate a number of publicly private key create a merculetry using the public keys and then send that information to another meter in the network. So then the verify meter or the meter was receiving the information will sort of verify that this information comes from a genuine smart meter using the certificate authority, which is the manufacturer. And then it will sign the route. So this route is basically used as the certificate of existence. And whenever the device wants to generate a transaction, it will just populate the route, the signed route, and uses one of the public keys used in the So all the notes can see is that very far meter has signed this, but technically it's not the very far meter was using this transaction was was generating this transaction so there's no link between the very far meter and the actual meter is generating this so then we can trust that it is a smart meter, but in the meantime we're protecting the privacy of the user who is using this. And again, we have covered scale and overheads memory and the anonymity which are the key challenges in adopting blockchain in it, and thanks for attention, I think over time, but thanks, thanks for your attention. No problem, no problem. So I think normally we finish in an hour. At least these things but I think we've got we've got have a few questions. So we have less questions. Can you see the questions. Can you pick out the questions from the from the chat. I just asked anyone else who has a question you know just my pup. I think we'll just have maybe answer a few questions. Yeah, so they said, so they said, in food supply chain we probably don't need to store data permanently can we do it on non permanent manner. Yes, I mean that's technically why we're saying that we need sort of temporary transactions in iot because in iot is not like an estate that we have to go through everything from the beginning. So it's like a meat generated somewhere and has been once the consumer bought it and it's done right. So we don't need the record of that probably so we don't need to store that information in the blockchain in the public blockchain at least. So we can still make sure that there is would be auditability by storing the hashes. And that's how and why we're suggesting that the hash of this information has to be sort of in the public blockchain. So how is malicious node identified because validator happens on chosen nodes based on the hash value. So in in sort of in three chain we basically are saying that the validators have to again go and receive a certificate from a certificate and that certificate authority might request for the real identity might be like burning point in Bitcoin to protect the anonymity, but to prevent like cyber attack what as what you mentioned, we do require to limit the spam accounts and we do it by relying on a certificate authority. And I think those are the questions. Thank you that was excellent. A lot of detail there. And, and so any other questions. I think we would probably run out of time anyway right. So, do you want to finish with anything. We've got lots of people. Most comments here are excellent thanks. So, do you want to add anything to this. I think he's having problems with his. I'll just, I'll just this Neema here. So I'll thank and thank Ali for for the great talk this is exactly why why why we invited Ali here because he's he's an expert in the problems that blockchain faces and then entering the IOT market. So yeah, so it would be, it would be very interesting to have you Ali on board that the telecom sick in hyper ledger, as well as the other the other attendees here. Joining telecom sick is quite simple and we're open for for everyone to join. Just, just search this online find our wiki and join the join the member list and we'll send the emails about the next events. Thanks again Ali for joining us. Thanks, thanks Ali and thanks for new concepts like tree chain temporary mutability certificate of existence like really really new concepts and thanks for sharing. I want to add one more point Ali can you share your all peoples to us so that we can share it on our telecom sick as well so that everyone can read. Yeah, yeah, that's not a problem. Yeah. Thanks. Thank you everyone for joining us. Okay, take care everyone keep safe. Thank you. Thanks.