 Okay, you were live. President, could you please unmute yourself? Yes. Wonderful. Can you all hear me? Yeah, yeah, yeah. Perfect. You can start. Thank you. Thank you, everyone. It's a great pleasure to be with you all here today. Of course, they heard a lot of wonderful things about this group and about the audience. And it's very exciting to know if I come here and present the work that we are doing and hopefully get some feedback and learn a lot of things from your experiences in both industry and academia. So I'm first on the web and I'm an assistant professor at the University of California Irvine. And I'm also the lead architect at a startup called Anylog that works in enabling edge cloud applications with blockchain and decentralized technologies. And what I'll be talking about today is on a long-term vision that we have for smart cities. And when we think about smart cities, we think about all the wonderful applications, all the wonderful technologies that can be enabled with smart city technologies. We think about autonomous driving. We think about immersive technologies, smart surveillance to be able to react to emergencies in a timely manner. And all these wonderful technologies are things that are going to transform the citizens and users' lives. However, a lot of these technologies have been there and we thought about them as a community for many decades now, for three, even four decades. But we see that they're still not happening. They're not realized in our daily lives. And in a way, one way to look at this when we think about every facet and every different vertical for those type of smart city technologies, whether they're regular surveillance, autonomous vehicles, cloud management, things like industry 4.0 and others. One issue that is common between them is that usually they are handled in an isolated, siloed manner. And what we envision is missing in terms of enabling them and making them achieve their fullest potential is to have a unified data management and analysis and learning infrastructure. So instead of having this siloed view of every application, what would be nice is to have a view that is more unified, that encompasses all these different types of data that have a holistic and global view of everything that is happening in an infrastructure, whether it's a smart city or any other type of infrastructure that generates data where we want to get insights from such an infrastructure. And currently, when we think about unification, what we have is we think about doing data management in cloud data centers. And the main challenge when we think about utilizing cloud data centers is that they are far away from the users. Again, if we think in terms of the smart city application, these smart cities have low latency requirements in terms of their application. If we think about autonomous vehicles, for example, or if we think about immersive applications, whether they're based on wearables or virtual reality or augmented reality headsets, those require very fast response times and reaching the closest data center can take hundreds of milliseconds, if not more when we have large amounts of data like video data. So when we think, well, what is missing in terms of having a data management infrastructure, we see that although that centralization has got us so far, of course, we enjoy all its benefits in the applications and services that we enjoy every day. However, this centralization in the cloud is missing a lot of things and have many challenges when we think about delivering these future applications. Of course, we spoke about latency, the hard white area latency, but also there are the communication throughput demands requiring all the data to go to a centralized location can also be a burden on the applications. And now the past few years, we're seeing a growing number of regulations coming from government and different agencies that using cloud services also have restrictions. Now, for example, restrictions on how we can move the data, how the data can be utilized in different locations around the world. So if the cloud that we're enjoying today is not enough to support this future of applications, well, what is needed for a computing paradigm that is going to enable it? And if we look into a historical perspective, we are capable of co-vaccinating where the future is heading. One way to look into computing is that the computing paradigms in the past few decades have always been going through, or in a way having two types of forces that is pulling it into different directions. At the top here, we have the force of consolidation or the force of centralization. And when we think about this, it's the force where we want to bring more compute, more storage together, so we can get more potential out of these compute and storage units. So for example, mainframes in the old days, the cloud that we're enjoying today, these are examples of consolidation of resources. On the other hand, at the bottom of the slide, we see that there are phases of, or forces of distribution. And this phase of distribution, or force of distribution, is a force that aims to bring data closer to users so that we have more real-time response, we have faster response, and also the users have more control of their data. So what we are envisioning is that we are now moving to the next phase in computing where we're going from cloud computing, which we are enjoying right now, into the next distribution phase that is called the global scale edge. And we envisioned that global scale edge computing power them to look like this. So this is a map of the city of Irvine. And every star here represents an edge or fog node that extends cloud capabilities. So instead of having all the resources or the cloud resources being only on these data centers that are far away, we envisioned that there's going to be a lot of resources around cities, around the world, where we can utilize them to extend cloud applications and cloud capabilities closer to the user. So for example, here, if we have an autonomous vehicle, this autonomous vehicle can utilize the close by edge node for offloading resources, for offloading compute, for offloading storage to get a faster response about its processing requirements. And likewise, when we think about other real-time IoT applications that need to work together, instead of having to coordinate via a far away location in the data center, now they can coordinate via a closer by edge node that is closer to them. And in a way, this is not entirely new. It's not coming as a complete surprise because we're seeing that there's these steps that are taking us from the current cloud consolidation, centralized infrastructure into a more global scale edge type of data management. So an example we see here is multi-data center systems. Some of you might be familiar with things like Cloud Spanner, Yoga by DB and Conqueror to DB. Those types of data systems consider that instead of being in a single data center, they're going to be distributed across multiple data centers. And this is one way of, in a way, breaking free from the constraints of being in one consolidated or one centralized location into multiple locations that could be closer to users. Another step towards this direction is edge cloud systems. These are systems where they are mainly residing in a cloud data center. However, there are smaller components that are on the edge. They could be, for example, on a mobile device. They could be on the user's browser or any type of location that is closer to the user. And of course, examples of this are PouchDB that extends a cloud database in the data center into something that is on the edge node. And when we think about desegregation and decentralized systems, those are also enabling technologies to lead us into this global scale edge. And actually, this is one of the things that I'm going to be talking about today, especially decentralized systems and fault computing and how these two are important enabling technologies to get us to the global scale edge. And one question that might arise is, well, everything may look good, may look nice. If we have a lot of resources around us on the edge, well, this is going to enable us to utilize these resources and have more compute and so on. However, if you think about it, this is a massive infrastructure. You have edge nodes that need to be deployed everywhere around the world, but there is someone who needs to deploy them. If we compare this with something like cloud computing and cloud data centers, although that these are also huge infrastructures, but at the end of the day, it's constrained to a data center, an entity can come in, get from one of those big industry players and build a data center. But it's more difficult when we build an infrastructure that span a whole city and then replicate that in different cities around the country and around the world. So what is happening right now is that a lot of cloud companies and leaders in cloud computing are considering, well, what is the next step? And we see that it's matching how we are thinking about global scale edge because now they are doing these collaborations and relationships with telecommunication companies. So we think we see, for example, that Amazon NWS is doing a collaboration with Verizon as a telecommunication company. Similarly, we see that Microsoft Azure is making a collaboration with AT&T. And the nature of these collaborations is that these cloud providers realize that telecommunication companies are the entities that have the infrastructure on the edge. If we look into that camera picture with all these stars and edge nodes around the world and around the city, the infrastructure that already exists that can enable this is the infrastructure of telecommunication. And we see that this is something that clouds providers are interested in. But of course, at the same time, these telecommunication companies are also interested in it because this is a way for them to get into another type of business sector where it's more about computers, applications, and services that are different from traditional telecommunication services. So it's a win-win situation for both. But the main idea that I want to bring here is that this is where the world is heading, that we're starting from a centralized who solidated cloud, but now it's clarifying breaking free and getting into the edge. And with this type of contract model between the cloud providers and the telecommunication companies and because there was many of them, what we envision is going to be the system model of this type of environment is that there's going to be different nodes that are around the world, around the city. And each one of them here, the different stars with different colors are going to represent different entities that are managing them or deploying them. So for example, some of those nodes might be deployed by Amazon AWS. Some other of those nodes might be deployed by Verizon. Some of them might be deployed by public or private entities like a university or a government agency, or even smaller private entities that are running this infrastructure. So kind of like, I wanted to take kind of like a second, like look at this. And I don't know if I can imagine if we kind of like live in a world where this is the compute infrastructure. And what we are trying to do now is this is the future that we are looking forward to, that there's going to be a future where these computers are going to be ubiquitous around us in different locations, closer to the user. So we always start asking the next question, which is, well, if that's where the future is heading, well, we need to change how data management works. The current data management technologies are all reliance on being in centralized consolidated places like data centers. However, once we have this type of massive infrastructure, the story is going to be different. And we'll need to evolve and transform existing technologies to be able to react to the changes that this type of massive infrastructure would require. Of course, challenges like the availability of these edge nodes, like the sheer number of these edge nodes that could be in the thousands or tens of thousands of these edge nodes, how do we manage data coordinate between these edge nodes are important problems that we aim to tackle. And what I'm going to present today are in the wake of two ways that we're tackling this problem. I'm going to start with what we're doing with underlog, which is a startup in this space that aims to build a data infrastructure for this type of applications over this type of environments. And then later I'm going to give a brief overview of what we're doing as research projects in the lab at UCI to tackle the insuring challenges from these types of problems. But before I continue, of course, I just wanted to like emphasize if anyone has any kind of questions or any comments during the presentation, feel free to speak up. And of course, I'm going to also, I plan to leave Apple time at the end, before the end of the hours to hopefully have discussions on the concepts that we are covering here. So maybe let's take a quick pause. Anyone has any questions that they'd like to ask? There are some questions in the chat. I think, yeah, yeah. So my question is, do you have any focus on wavelength sounds or in the energy grid, putting telecommunications into the energy grid? Yeah, this is an excellent question. And actually this is something that I hope that for anyone in the audience who's working in these sectors that also in a way tell us how this reflects in their industry, from our perspective, we've been in talks with maybe similar sectors or industries, things like water companies, for example, where they have a massive infrastructure as well, that they need to have real-time processing of the events that are happening on the edge. I would imagine that similar challenges would be needed in things like the sectors that you spoke about. But yeah, so if I can, this is in a way our reflecting the way interaction with these types of sectors. Yeah, so I see someone raised their hand as well. Is there any other questions? Yeah, doctor. There's a question on the chat. When you talk about the stars on the map, does this indicate dedicated edge server? Oh, wonderful. Yeah, thank you for the question. Yes, perfect. I see it in the chat now. Thank you. So let's see. That's a very good question. So our treatment, or let's say our, I think I want maybe to separate between two things here. So there is a vision of where we think the world is heading and there is how we treat it and our research and in our work and underlaw. So when we think about the vision, of course, we envision that this is going to happen in different forms. Utilizing edge resources could be done at edge devices like mobile devices, laptops, but they can also be done in infrastructure like access points and so on. But also they can happen at the level of, let's say, base stations of telecommunication companies or dedicated edge data centers. The way that we treat it, we typically treat it as dedicated edge nodes, whether those are deployed as base stations or dedicated edge data centers or resources on the edge, in a way they have a lot of similarities there. But I think in the next coming years when this is starting to be realized, I would think that it would be really the full stack. Like we're gonna get from the smallest of devices all the way up until bigger dedicated devices. However, I think the first steps are going to be for dedicated devices because this is going to be the easier routes to extend cloud technology. Yeah. Okay. Yeah, I see the point. Yeah, so I was just thinking that I can donate my resources or volunteer. Wonderful. Because I'm working on this domain, yeah, but since you are going to start. Yeah. Oh, that's wonderful. And actually I'm going to get back into this issue because we're trying to build a network of such like environments. So I'll get back to that and refer to it at the end of the talk. But yeah, thank you for the question. Perfect. Yeah, I see Brett, you have your hand, yeah, go ahead. So with regards to node operations, do you have any purview or opinions or treatments about meshing? Yeah, that's a very good point. So of course, maybe to ensure that I get your points correctly. So in terms of mission, you mean like in a way having the edge nodes themselves communicate with each other directly in a mesh network fashion. Is that what you're referring to? Correct. Wonderful. So yeah, I think this is a wonderful question. And the way that we're thinking about how meshing is going to get into the picture is that it's typically going to get into the picture via the telecommunication infrastructure. So if we look into this new type of global scale environment, the network infrastructure is going to be one layer and the data infrastructure is going to be built on top of that. And of course, from our point of view, as long as communication is done in some way that is efficient between these edge nodes, that's what we kind of like, this is what we care about. However, we're also anticipating that efficient telecommunication technologies are going to be implemented. And from what we're seeing, and of course I know that a lot of the audience here would know more than me in this regard, which we see that meshing is going to be one of the enablers of future telecommunication technologies, especially with the edge to facilitate this fast communication between edge nodes. From our perspective, this is an important step in the communication infrastructure because we are not relying on cloud communication. We are not as much interested in edge to cloud communication, which is what is being optimized now in the current telecommunication infrastructure, but rather we're also interested in the edge to edge type of communication which technologies like meshing are going to be big enablers. And so of course we're looking with a kind of optimistic eyes that this is going to be an important part of enabling what we do as well. Yeah, thank you for the question. Okay, wonderful. So yeah, thank you. Thank you all for the questions. Of course we can also have more discussions at the end of the talk, but of course if there is any quick clarification questions, feel free to stop me at any point or if you have any comments, feel free to stop me at any point, all right? So now we get into the first part of our treatment of how do we build a data management infrastructure for this future data computing paradigm of the global scale edge? And we are kind of like we started with performing some research into how do you build a decentralized data management infrastructure for this type of environment? And now it's been a few years and we have a startup called Underlog that has a prototype that is being deployed now with different partners that are going to be presenting today. And the way to look into how we do data management in Underlog is by looking into what is the data management batteries that we're going to support? If we look into these autonomous car, which is an example of an edge node or an edge user that is trying to do processing of the data, that is trying to leverage resources for compute, for coordination with other cars, for coordination with the city for example, to know which part has worse traffic or better traffic, coordinating with things like navigation technologies to know which are the best routes. Doing all of this can happen via these edge nodes and the data is going to be published to these edge nodes. So for example, this autonomous vehicle could publish its data to these two fog or edge nodes that are close by. And now for someone who is asking a query about the data, for example, if I wanted to list all the cars that has entered the University of California at Irvine this morning, what Anilog does is that it performs an exploration phase to find what are the edge nodes that has that specific information I'm looking for. And this is very important because when we have an infrastructure, a data infrastructure with hundreds or thousands of nodes, we can't involve this large number of nodes in every step of operation. So what we will need to have is a way to explore what is the smallest amount of those devices or edge nodes that we need to communicate with to answer our question. And the main way that we are achieving this is by having a decentralized sharing and coordination layer. So all these edge nodes would know where the different data items and know how to perform the exploration of the data by having this decentralized layer that they can consult, that it can participate in to get a small amount of metadata that is distributed in a decentralized way to be able to find where the location of the data is. So now, when we get back to this query here, if I wanted to list all the cards that are entered at UCI this morning, the pattern is that I'm going to first send it to one of the Anilog nodes that are close by to me as well. And then that Anilog node is going to, using this decentralized layer of shared metadata going to find what are the locations that are closest that has that data that I'm looking for. And when we look into the Anilog node itself, the Anilog node itself, you can think of it as a layer that is sitting on top of an operating system that is being deployed. And this Anilog node has data management capabilities. So it has a database. We can interact with it using a rest interface and we can deploy it using our deployment scripts. But it has all the functionalities that you would imagine from this type of data management infrastructure. How do we ingest the data? How do we create schemas? How do we manage the storage, manage the processing? But also very important for these Edge and IoT applications, how do we monitor data and have alarms and monitors to know how to react to any anomalies or events that we are interested in? And the Anilog node, this is an Anilog node in isolation. It's way for interacting with the rest of the Anilog network or finding the other nodes is via this private or public blockchain layer that has the shared metadata about the whole network of Anilog nodes. And this shared metadata layer contain the policies of the whole network. So it's not only about exploration of other nodes but it's also about policies. So for example, I might have some sensitive data. I might have data that I want to share with specific stakeholders but not with everyone. So these policies in the shared metadata layer are going to tell us how do I react to the data? Do I need to encrypt it? Do I need to process it? Do I need to store it? If I store it, how reliable should the storage layer be? Do I need to replicate it, for example? So all these policies are managed through this shared metadata layer. And when we break out from that individual view of an Anilog node, now we see that we have a number of Anilog nodes that are working together. They know about each other and about the policies through the decentralized shared metadata layer. And then they can coordinate in a peer-to-peer fashion from one node to the other via communication technologies that would allow that. So the bigger picture here is that now this network of Anilog nodes are going to receive the data. And it's just the data that is coming from the smart city applications, from the IoT applications and devices. And we're going to ingest it and process it in the Anilog network. And now if we go into the top level view at the top right here, this is the application view where we have a dashboard that's, let's say we ask a question about the infrastructure, for example, what cars are moving here, what's going to say pedestrians are moving in which locations at what times. And the view that we provide that need to be provided is a unified data view. There is a lot of complexity that is happening. To be able to deploy a solution on the edge, there is a lot of complexity that needs to happen in how to manage the data and how to distribute the data. And this should not be exposed to the end user. So at the top here, what we represent is a virtualization of all these resources. So from a user's perspective, from an application perspective here at the top right, when they communicate with a single Anilog node in that network, which is represented here, that one Anilog node is going to provide a unified view of the data, is going to take over any processing, any communication with other Anilog nodes, doing the exploration, the policy management and all the other tasks that are needed to process a query that is sent by an application client and then provide it as a unified data view to that client. So from the client's perspective, it's as if it's a centralized database where there is no complexity and no distribution that is happening. So in a way it's achieving the best of both worlds, the ease of use from the user's perspective, but also utilizing the resources of the edge and being closer to the user in this way, which enables a real-time response and avoid all the challenges that come with centralization and cloud data centers. So now we're to perform a quick demo on Anilog and how it works. The demo is going to perform a real infrastructure. So these are nodes that are distributed around the world and they're actual nodes that are running right now that we're going to utilize for our demo. And the way that the demo works is that for some of these nodes, we have a feed of a stream of traffic that is feeding into the edge node. The edge node processes that streams and then generates a data table with this stream. So the stream that we're using, which is the only synthetic part of this demo, so the nodes here are distributed around the world, but the videos here we're using are synthetic videos of, or not synthetic, but pre-recorded videos that we're processing and then generating these tables that are maintained in each one of the edge nodes around the world. So each table would look something similar to this. Of course, this is a simplification, but mainly it has the car information, the time the detection happened, and then the speed of the car. And we're going to see how we can ask a question about these tables that are distributed around the world and how Anilog reacts to processing such a query that is distributed across different edge nodes. All right, let's me get into the demo here. So this is the application clients that we're going to be using and I'm going to get into the query to get the question I'm interested in, which is the question right here, which is I wanted to, sorry, the font is maybe a bit small, so I'm going to describe what the query is trying to do. The query is basically to select the information about the car of every car that was detected in the past hour. So we're getting to get information about all cars that were detected in the past hour, and we're going to sort it based on the speed of these cars. Of course, here we have some other parts of the query, which is more about formatting and kind of like how to interact with this, but this is the main part, the question that we're trying to ask. So if we press send to this query, as you see in a fraction of a second, we get these responses that are coming from all around the world. So for example, this entry here, it comes from Singapore, it actually comes from the interlog node that is in Singapore. This one comes from the interlog node that is in Atlanta. We have access to all this information by accessing the relevant edge nodes for the relevant interlog nodes that have the information I'm looking for. So what's happening under the hood here is that there is an exploration phase, this interlog client connected to all the single interlog clients, and then that interlog client received that query, and then based on that query and the policies that it knows, it directed the query to the nodes that has the information I'm looking for. And now I can even drill down into the information I'm looking for. So for example, well, I might say that well, I'm interested in these two cars that had these certain speeds, but I can drill down and see the actual videos that are related to them. So for example, if I selected this video here, I can press watch and then I would see, clarify that, well, this is the traffic footage that happened during the detection that led to the entry I was interested in. So kind of like with this interlog infrastructure, we're able to process data in a fraction of a second, and then even with this type of rich data that has videos and images, that would be very difficult to move if we're moving them in all locations or to a centralized location, if we're moving all the video data from tens or hundreds of cameras, this is very difficult to do, but if we have it in a distributed way and then we explore it and drill down on what we are interested in, it can be done in such an efficient way. And of course, what I presented is more of like an interactive type of interface. There are also other types of interfaces that we can build on top of that. And this is an example here of a dashboard that can utilize the interlog infrastructure. So for example, here we have this map of interlog nodes and information that we're trying to get about this infrastructure. We can do a continuous monitoring of the system and then a detection of any anomalies or events of interest that might happen during the processing. And of course, to be able to achieve all of these wonderful features and the efficient processing using the interlog database, there is a lot of research challenges that we need to address. And this involves these areas that we are tackling in our lab and in our practice with interlog including things like how do we coordinate? How do we do distributed processing across these nodes, right? My data could be in different interlog nodes and I need to have an efficient way to combine the data, to process the data, to aggregate the data and doing this with this type of environment where there is a massive number of nodes where their availability might not be perfect as cloud machines. If I'm doing this would be more challenging. Another one is how to deal with decentralization. When we have an interlog network nodes might join and leave at any time. So how do we maintain membership data? How do we ensure that as nodes are joining or leaving, we can perform our coordination in this decentralized way? There are multiple directions in terms of trust and security because as we utilize edge nodes, there is also some concerns about, well, how about the security of these nodes? Also how about the privacy of the data that are maintaining those nodes? What is the data protection implications? Things like GDPR regulations. So all of these types of challenges are things that are being addressed by both our group and other groups out there that are making us realize this type of edge data management where we can process the data on a massive infrastructure on the edge. And interlog is a manifestation of a lot of this research that we are trying to do. And we're hoping that as this research advances, as we can perform and incorporate more of that into our solutions. And currently interlog has been deployed in multiple partners, both in industry and academia. And this span groups that are interested in different types of technologies, whether it's smart city technologies, edge technologies, IOT technologies, things like industry 4.0, smart cities, smart buildings. All those types of technologies we have, like infrastructures and groups that we are collaborating with to really get the actual challenges and have a realistic view of what is needed in these types of applications. And currently at UCI, there is a number of faculty who are doing research in smart spaces and an infrastructure that is deploying IOT nodes and sensors and engine nodes across the campus and with partner campuses to perform research in data management, security and privacy and data protection regulations. And one thing that we are hoping to do is that we want to create a partnership with a network of both academic and industry deployments and test beds so that we can deploy IOT nodes and other types of solutions and then test in these types of test beds across different sectors and industries and see what are the challenges that we face, how we can advance them and how we can create collaborations that will help us overcome these types of challenges. And this also of course, comes back to an earlier question that I got from the audience here, which is if anyone here is interested, we're always looking to expand this network and add new partners and see how our analog solutions may benefit different sectors and lead us into something that would be useful for different applications. So now I'm going to talk very briefly on some of the research issues that we might encounter and how we're dealing with them in the research lab. And this is going to be a very brief treatment, but of course, if anyone is interested, feel free to reach out to me after the talk and I'll be happy to provide more resources about what we're doing. This work that I'm going to be presented now is also supported by various governments and industry agencies like the NSF and Meta for the specific work that I'm going to be presenting. And it's mainly about the coordination of the different types of resources in the global scale environment. So when we think about this global scale environment with all these different edge nodes, we can think of three levels of challenges that we need to address. The first level that is here at the bottom right is at the individual edge node level. At the individual edge node level, how do we manage this node's storage and processing in an efficient way? The other level is at the level between the edge nodes and a cloud infrastructure. Even though that we are extending the cloud to the edge, that doesn't mean that we're getting rid of the cloud. The cloud is still important, it's still useful for a lot of tasks. So it's always good to know what to do with the edge and what to do with the cloud. And this is another type of coordination problem that we deal with. So the third one is how do we coordinate across different edge clusters? So for example, if I have clusters of edge nodes and they want to coordinate with each other without having to go through the cloud or without having to go through a centralized entity, how do I manage this type of coordination in an efficient way? In our lab, we deal with all these three types of patches of communication, but I'm going to give a brief overview of the third part, which is how do we coordinate across the different clusters of compute? And one way to look into what's happening in this type of infrastructure is that every cluster of nodes, so here I'm showing three clusters of node, each cluster of node is grouped together and we want to be able to coordinate with these other clusters of nodes. And if we are utilizing a single decentralized layer, for example, a single private or public blockchain, this can itself present a bottleneck to the edge clusters. Of course, we have ways to avoid it being a bottleneck, but at the end of the day, we also want to utilize it in more and better ways. So how can we overcome this bottleneck and overcome the challenges that might come from utilizing a single decentralized infrastructure? And as we're seeing in a lot of decentralized technologies and blockchain technologies, one upcoming solution is the solution of sharding or partitioning a decentralized solution or a blockchain into multiple shards. So for example, instead of dealing with a single layer that is decentralized, a single blockchain layer, we can partition this. So we have multiple blockchain instances that are being utilized by one or more clusters each. And this allows scaling of these decentralized technologies as we have a larger and larger number of nodes. And of course, this could be useful because a lot of the operations as we observe and as we know about, especially IoT and inter-applications are local. So if I know that, let's say most of the coordination that is happening in Irvine is between users and citizens in Irvine, then there is less interaction with other cities around the US. So having a shard that only maintained the data and coordination for this city would be beneficial in this way. But of course there is a challenge, which is even if most of the communication and coordination and processing is happening within the cluster, there are still cross cluster communication and coordination that is happening. And if we partition the blockchain into multiple partitions, now doing this cross-partition coordination becomes even more difficult because now you have to coordinate between two different decentralization layers. And this is the main research question that we are actively working on right now. How do we build decentralization technologies and data management technologies that would enable us to efficiently perform this cross shard operations in a decentralized environment? One type of work that we've done, that we started with in this direction is called blockchain that was published a few years ago at ICDE, which perform a hierarchical abstraction of cross cluster communication. And at a high level, the main idea of this work is that what we do is that we perform coordination at the local level, but then at the global level, it's another layer of decentralization. So you can think of it as two layers of decentralization when that is at the local level and when that is happening at the global level. And the nice thing about this type of hierarchy is that what you do at the local level, in a lot of times, you can reduce the work that you need to do at the global level. And this is part of the insights that we present in this work in blockchain that I would be happy if anyone is interested to talk about it after the talk. And another work that we're doing in this area is called which block that we presented earlier this year in the conference EDBT, which is about, well, if I have all these different shards of decentralized data entities, how do I read from them consistently? And the problem that I'm referring to here is that let's say that they have data that I'm interested in in both this shard in the left and this shard in the center. And if I read from them, and I read from this shard A and then read from shard B, would that be sufficient? And what we find is that sometimes this can be problematic. So for example, imagine if they have two types of queries when that is writing X and Y, or sorry, when that is writing X and Y, for example, here writing X to be five and writing Y to be 10. And then another query that is writing X to be six and writing Y to be 11. So now these two transactions are ordered in this way. So with the consistent way of looking into this data is either that I see the updates from the first transaction only, or I see the updates from the second transaction as well as the first transaction. And as we see that it's possible that the read operations might have an inconsistent view of that data. If I read from the first transaction, I read from the second transaction for the other item. And this is, of course, is happening because if I partition the blockchain layer, now they become, they're not coordinated and we can have such inconsistencies when we're reading from each one of them individually. So we're developing technologies to have multi-versioning and dependency tracking that would allow us to read in a consistent way across these different shots. So kind of like this concludes my talk about the global scale edge. We think that the future is heading towards that direction. And what we are aiming to do, both in underlog and in our research lab is that we're trying to have a data layer that is going to have a unification of all the data that is on the edge so that we can participate in this network. We can manage data and just data, enable smart city technologies and have a unification of the view of all the resources that are being managed on the edge. And of course, at the end, I just want to also thank the wonderful partners in these projects, the Edge Lab students at UCI. This is our research group, the students who are leading this research and the transfer of this research to industry. And of course, underlog for being a wonderful partner and delivering these technologies and having a prototype that actually would deliver the promises of edge cloud data management. And of course, we also would like to thank the various sponsors of the research that we are doing and from the NSF and different industry partners as well. Thank you all for the earlier questions. I'm looking forward to hearing some more questions and also some comments. And what is even more important, if you disagree with anything of what I've said, I would also love to hear that to hear your point of view on where do you think the future is heading in terms of computing and data management. Yeah, thank you all. Well, it's wonderful. I see Brett's, yours is your heart, go ahead. Yes, thank you, thank you. I have a question about the legal frameworks of facial recognition. The GDRP has strict guidelines for processing personal data and the US has some cities such as Portland and San Francisco that bans or restricts the use of facial recognition. And various other countries such as Australia and Canada are in discussion. Do you have any treatments or methods with those artificial intelligence legal ethical frameworks? Wonderful, wonderful. That's a very important and timely question. Yeah, thank you for asking about that. And it's certainly one of the most important things and direction that we are dealing with right now. In fact, so this is one of those kind of like fundings that I mentioned here. So this second kind of a grant that I'm referring here, this is a 1.2 million grant that we just received from the NSF specifically to tackle the issue that you raised. When we think about data protection regulations like GDPR, CCPA in California, those impose restrictions on how data especially sensitive data and personal data should be processed. And a lot of the technologies that are coming in smart cities and engine IoT involve an interaction with people and pedestrians and citizens which make them susceptible to these regulations and make it important for us to deal with these types of regulations. I can tell you a little bit. So this project and this funding of this project has just started this year and we're hoping our goal in the next two to three years is to have a framework that is going to enable us to extend an existing data management technology to comply to data protection regulations like GDPR. So what we are proposing is what we call it a sidecar approach. So if we have let's say an analog infrastructure, we can start with the analog infrastructure and then have a layer of the sidecar approach that is going to intercept requests and data that has personal or assistive information. And then based on the policies, based on the regulations that we are compliant with it's going to process the data according to that. To give you one example that we started working on imagine if we're collecting data from users in the smart city or the smart space and then we're using it to build a machine learning model. Now, if one of the GDPR and data protection regulations is divided to be forgotten. If I get, if there is a user who sends a request to us saying that, well, I want all my data to be forgotten one of the things that we should do is not only simply removing the data from the different tables where we're recording that data but also any derived data like machine learning models like reports, analytics, all these different things also need to reflect this change that that user's data should not be there. And we're developing machine learning and differential privacy solutions to react to these types of requests in a sidecar approach that can be deployed with existing solutions. So that's kind of like a high level of view of what we're hoping to do, but of course I'm interested in if you're interested I can give you more of the papers that we have brought in that topic as well. Norah, thank you for that question. Any other questions or comments? Thanks Faisal for accepting our invitation. Great talk. So it's quite the line with what we are trying to do in the telecom sick group here. Just a quick question on the scalability of the solutions that you're providing. I know Sharding answers some aspects of it by breaking it down to smaller blockchains and so on. But like in summary, what is it that blockchain does for your use case that cockroach DB doesn't, right? Because we have the extra layers of complexity added when we were talking about blockchain as compared to like a simple distributed database, right? So just yeah. Yeah, that's a very good question. And actually your insight and observation is correct. In a way, this is why we emphasize that it's a decentralized data sharing layer. The implementation, the manifestation of how data sharing is happening depends on the application. If the application lends itself to an environment where there could be something like a distributed database that would maintain this shared metadata, then that could be the shared metadata layer. However, in a way, why we also emphasize a blockchain and why we emphasize a decentralization in this shared metadata layer is that we don't want the shared metadata to be handled by a separate layer of the system or a separate components of the system. Rather, the way that we are hoping to achieve it is in a way where every annual node can participate in the propagation of this metadata and the sharing of this metadata. And the reason for this is that we observed in some of the applications where there is a lot of mobility, where there is, where availability is sporadic. For example, where there is remote areas, applications where there is remote areas outside of communication limits. And also when there is disconnectivity in terms of, for example, power, all of these types of issues would lend themselves to a decentralized solution so that nodes can join in and leave without impacting the system. A lot of the existing distributed solutions would have more stringent requirements on the availability of the nodes that participate in the sharing and management of that data. Yeah. But maybe to summarize again, kind of if I can, at the same time, if it's a more predictable environment, using a more traditional distributed database would definitely be a way to go. Yeah, thanks. We have a last one question very quick. What trust mechanisms do you currently implement to ensure that a node delivers correct answers to a query? I think about consensus, yeah. Wonderful, wonderful. Yeah, that's a very good question as well. So currently, in terms of the annual prototype itself, we are thinking of integrating some of the research work that we're doing in the lab which utilizes different technologies for this trusted computation. We explore things like trusted execution environments like these. We also explore more software-based mechanisms like coordinating with a trusted entity and a concept that we call lazy trust to give an answer but then ensure that it's correct and later on making corrections if needed. Of course, this untrust might come because of maliciousness, but sometimes it also might come because I want to do an approximation of the query answer. In both cases, we utilize trusted execution environments as well as delayed background computation to ensure that any answers we gave were actually the correct answers. But yeah, this is very briefly but of course, happy to provide more after this talk. Yeah, and I think users can see the email ID as well now up here at the UCI.edu. So if you have any more queries, you can mail it. Wonderful. Thank you. Thank you, everyone. Next phase, I'll do that again. Thank you. So yeah, we'd be happy to have you, Faisal, or your team members on our calls on telecom sick. So we have like the entire call is an entire group is dedicated to use cases of blockchain in communications and edge computing is not very far away from that. So yeah, feel free to join, why we clean meetings, you or any of your team members. Often we work on use cases that companies or researchers like yourself bring into this group. We develop them further into either white papers or we even have some other facilities such as GitHub Labs where we can kind of get some help maybe from some people who are of expertise on developing applications. And then we could kind of enhance your use case with those and then kind of produce further results. Yeah, thank you very much, Faisal. Thank you so much, and yeah, of course, I heard a lot of things about this wonderful group and I agree that I think there is a lot of wonderful things happening. So hopefully, if I can look forward to the next meetings as well, and I really appreciate the wonderful questions and insights everyone provided. Great, and I'll send you a link so you know where to find that information for about upcoming meetings. Wonderful, wonderful. Great, well thanks everyone. Thanks everyone, thanks, bye.