 The first presentation is titled, Topic-Based Service Discovery for Ethereum Peer-to-Peer Network. It looks like Honor Askajil from Lancaster University will be the one presenting this. So I'll let you take it away from here. Thank you. So this is joint work with Mihal, Sergi, Etienne and Felix. Talk is about the discovery system for Ethereum. So quick outline. First going to give a brief overview of the Ethereum ecosystem. Then I'll introduce a topic-based method for discovery. And then I'll go through the objectives and challenges of a discovery system in an open decentralized system like Ethereum. And then we'll quickly present our proposed discovery system and then conclude the talk. So Ethereum is one of the largest permissionless blockchain. It's home to Ether cryptocurrency. It supports touring complete smart contracts. And Ethereum ecosystem is not about just the mainnet and the Ether, obviously. There are many of these decentralized applications. According to a recent study, there are close to 4,000 of them. And they vary in terms of popularity, which means that the adoption of each application, the number of peers adopting each application can differ a lot. It's highly desirable for peers running an application to form a dedicated application-specific peer-to-peer network among themselves. This is basically to confine the dissemination of application-specific messages like event notifications. So we have a general large Ethereum network which is unstructured actually. And then we have a discovery system where we have, where we build separate peer-to-peer networks between nodes that are running the same applications. Here, the colors in this picture corresponds to an application. So any node who wants to join a target applications network must find and appear that is already part of this network. And this picture is a bit misleading because a node actually can be part of multiple applications. The objective of the discovery system is basically for peers to establish application-level connections. The existing discovery system of Ethereum uses a brute-force approach where nodes perform random walks. Basically, a node picks a random ID, a destination ID. And because the nodes are arranged in a distributed hash table, a DHT, it uses a built-in DHT get method to efficiently find nodes closest to a random ID. And along the random walk, with the nodes that you encounter, you perform a handshake to find out which application this other node supports. And if two nodes support the same application, then they can actually form a connection. But this random brute-force approach is problematic for two reasons. It's slow for peers to find others for unpopular applications where there are not too many peers. And also, there are these unnecessary handshakes between nodes that are not even running the same application. And what we propose instead is a topic-based discovery. Again, we have a DHT, but unlike the previous approach, where we didn't really take advantage of the structure of the DHT, here we can do that. Basically, nodes to be discovered, a node must register itself with other nodes. This is called registering an ad or advertisement. And nodes advertise themselves under specific topics. And the topic is basically a pseudonym for an application. And all nodes in the system must assume the following roles. As a registrar role, you store advertisements not only for your own topic, but for all the topics in the network. And you store the ads in a topic table. It's indexed by topic and it's a list of node records. I'll have an example of ad registration in the next slide. As an advertiser who wants to be discovered, you register your ads with other nodes. And as a searcher who was just trying to join or you're trying to re-establish or you're trying to form new connections because your existing connections are gone, you try to find other nodes that are listed under specific topics. So as an example, here node 15 is trying to register an ad. Basically provides its own node record and a desired topic ID. A node record is basically a node's identifier. It's connectivity information like IP address and port number and some other security related stuff. It's important to note here that the topic table is a shared resource that is shared across all the topics and it has a limited size. So it's important to secure this resource. Ads, when they're registered, they eventually expire after some number of seconds. This is because we don't want to keep persistent ads in the network because in an open system, people can join and leave. Quick overview of the Ethereum DHT before I move on. It's based on Cadamlia. Node IDs are just a short hashed form of nodes public key. And the distance between two IDs is the length of their common prefix and you can map any data item or topic to this DHT ID space by hashing it. And based on the distance metric, each node, each DHT node can actually form a routing table where peers are organized by their distance to the source node. So the peers in this bucket have a distance of one with the source node who is maintaining the routing table. The last bucket, let's say this is the bucket five in this example actually has the peers whose distance is at least five. So distance five and more for the last one. And Ethereum DHT has built-in get and put functionality, efficient routing mechanism with limited number of steps. And you can find efficiently nodes closes to a target ID. Next, I'll go through objectives and challenges. One objective is an important one, it's a security, but to explain this, the first explain this application level connection concept. Ethereum, each peer maintains a total of 50 connection slots. Some of them are limited to the source node some of them are initiated outbound to these connections. So, and some of them are inbound. And this, these small number of connection slots need to be protected from eclipsing attacks because in an eclipsing attack, an adversary together with its symbols monopolizes the connections of a victim. And once it achieves this, the adversary can feed the victim any information at once. And there are some existing work to prevent eclipsing attacks, but I'm not going to go into details. Some of these approaches we actually also use in our work. So security is an important objective and adversaries have multiple reasons to attack the discovery system. One is for financial gain, because for instance, once you eclipse a node, you can then launch subsequent attacks like double-spending attacks. Another reason could be to block or slow down the discovery for some competing applications. And the objectives are therefore to have its discovery system that works under a Byzantine environment and limits the impact of symbols. In an open decentralized system, nodes can just create symbols at no cost. Some related challenges. So one example attack is to prevent, one challenge is to prevent malicious registrars. A malicious registrar can basically ignore ad registrations or lookups as part of a denial of service attack or a more powerful attack would be to return bogus or targeted results. So for instance, to a lookup request, an adversary can just return a list of records of symbols that it generated as part of an eclipse attack. Also, nodes can place their symbols at strategic locations in the DHT to increase the impact of the attack so that they're discoverable easier. Malicious advertisers on the other hand can similarly generate a pool of symbols and then spam other nodes with lots of registrations. One possible solution to this is a proof of work scheme like have the advertisers here solve a puzzle and consume some resources. But this is also not a very desirable solution because you give unfair advantage to resource rich nodes. In general, proof of work has this kind of disadvantage. Remaining objectives are having a load balanced, lightweight and fast discovery. So load balance means that there's similar overhead across all the nodes. So we don't want any hotspots in the network. You also would like a lightweight mechanism for registration in terms of messaging or state maintenance for existing or ongoing registrations. And we would like to have a fast discovery. So once you register an ad, you want to be discovered fast. A related question to these is how do you find the right subset of registrars to send advertisements to and the right subset of nodes to send search queries to so that these two sets actually intersect and meet that common nodes. Two solutions I'll describe here. One is using the DHT built and put and get. Here we have a topic ID mapped here into the DHT space and both registrations and lookups will basically go directly to the nodes closest to the topic hash. This approach is fast for search, fast for discovery, but it's easy to attack because symbols can be just placed close to the topic hash. Also it introduces hotspots. For instance, if this topic is a very popular one, then these nodes closest to this topic hash will be very busy. The random placement, the one I just described before with a random walk, it's difficult to attack because nodes won't know where to place their symbols because you just randomly search. It also gives you good load balancing property, but it's also not fast to do search because especially for unpopular applications, it might take a while to find peers. So I'll go through two main research questions as part of my proposed discovery system, but I'll talk about these one by one. So the first question is, how do you achieve a good load balancing? And then how do you secure the discovery mechanism while keeping the ad registrations lightweight? And ideally discovery system must continue operating under heavy presence of symbols. Our approach is basically a hybrid of the DHT put and get operations and random placement. So what we do is we form a topic oriented bucket organization into the routing table. So we call this a registration table where the peers are organized by their distance to the topic hash, not to the distance, not the distance from this node. And then we combine this bucket organization together with intra bucket random ad placement. So let me describe with the search first on this figure. So for search... Sorry to interrupt. We are right at the 15 minute mark. So if you're able to sum it up in about a minute, that would be great, sorry for interrupting. Sure, no problem. So for the search, we start from the farthest bucket and do some random search here, random walk and then with encountered nodes, we search on these nodes. If we have enough results, we move on to the next bucket and so on. And this approach actually gives you good load balancing while keeping this randomness, which is good for security. And for the admission mechanism, for the attacks against topic table, advertisers send their information and then we compute a waiting time and place this in a ticket. And then the advertiser must wait for the duration of this waiting time and then come back and then they might be admitted. Their advertisement might be admitted. And the waiting time is based on a diversity of this advertiser, its IP address and ID from the contents of the topic table of the registrar. So that's the main idea of how to protect against symbols because symbols tend to come from small number of IP addresses, for instance. It's just a sample of our results. We have more detailed results and this is an ongoing work, not published yet. But looking at the number of registrations in a simulation where 20% of nodes are symbols, the red bars actually show the successful registrations by symbols and a large proportion of the registrations are by other honest nodes. And the topics are from most popular to least popular here. And but the attacks against least popular topic is a bit more effective. These individual bars are for different number of IP pools that attackers have when they're launching the civil attacks. And I guess I'll just finish it here. And then I'll talk time. Thank you very much.