 So hello, everyone. I will present to you about Sikorca, which is a site project I have been working on. It's not really core development. So I don't know how it came up in the first day, but we will have a quick look at it. So who am I? I'm Leveriz. I have been working as a core developer since fall of 2014. Later, I ended up in various other parts of the ecosystem. And since over a year now, I'm working with Brainbot as the Rider Network team lead. You're going to see a very awesome presentation from our team tomorrow at round four about riding from Augusto and Doridana. So what is Sikorca? It's something that I have a passion for, being able to provide presence proofs for decentralized applications in order to be able to have various applications that use locations for various purposes in the blockchain. So the purpose would be to make locations and objects programmable. The team is small, as I said right now. We are two people mainly working on it. Konstantinos Paparas, also known as Kelsos, he is the awesome Android developer who has been making the Android app of Sikorca and me as the guy doing the theorem smart contracts. We are also talking with some people who make hardware verification devices. And we are trying to create an ecosystem around this. So about the generic system overview. Sikorca, it's a network of detectors that aims to provide proof of presence for decentralized applications. We can have different types of detectors and contracts can choose the detector depending on their own security requirements. A user can interact with a contract via the use of the mobile app. And the most exciting thing would be for objects to directly interact with a contract through the use of small chips that we call tags. Use cases for such a system, well, there are many. You can prove your presence in a particular location for bureaucratic reasons. Picture, for example, yourself unemployed and having to go to the unemployment office every first of the month and prove that you were in that particular location. Customer loyalty programs, you get, let's say, discount tokens for being in a particular soap games, augmented reality games, Pokemon Go in the blockchain. And the most exciting use case would be objects directly interacting with smart contracts. Say you rent a power tool. The minute you return the tool to its charging station, a blockchain transaction is made in order to pay for your usage of this tool. There are various different detector types. We have designed the system in a modular fashion so you can add more detectors as the ecosystem progresses. The deployer of the contract, so the people who create contracts can choose their own detectors depending on their security requirements. I'm going to present a bit about some hardware detectors that we have worked with. This is a very interesting one that's developed by a company called Revealoo. We are cooperating with them and they have created a temporal Bluetooth tracker that you can see on the picture on the left. It can provide accuracy for locations up to 20 meters, if I remember correctly. And its most interesting feature is that it is privacy-preserving because the user can exchange temporal keys with the device and actually specify for how long he wants to be tracked. This is really important because this way we can avoid a big brother scenario where we have a network of these detectors tracking everyone forever. As a user, you can choose how long you want to be tracked by an application that uses these detectors. For a more simplified version of a detector, here we can see a flushing QR code detector, so a device that just flashes QR codes every number of seconds, let's say 10 here. And its code is essentially a signed message that the user would need to include with his transaction to the contract. Of course, it's an Ethereum ecosystem application, so there need to be smart contracts. We have two basic smart contracts. One is a registry of all Sikorka-enabled contracts and the second, an interface for a contract to implement in order to be able to interface with the Sikorka ecosystem. The registry is rather simple, just you can add or remove contracts to a mapping and get an index of all contracts for using geospatial indexing applications. The Sikorka interface is a bit more convoluted, but its main feature is a modifier that allows any contract that inherits it to specify a function that will need proof of presence. So you just put a modifier on the function that would require proof of presence and then that function would need to be checked by a detector. As I said, we have created an Android app. It's using the Go Ethereum Lite client Android libraries. And you can see a screenshot here on the right. You can create and deploy contracts with it or interact with already deployed contracts and see how many contracts are around you and also interact with detectors. The source code is open source. It's in our GitHub. You can download it and play with it. Because it's using the Lite client, I would like to please ask anyone who is running a Gith node, please add minus, minus Lite, serve at least 10 or any other value so that we can be finding peers. Because at the moment, that's a problem, but I heard that things will improve as time goes on. So, usage scenarios. This is the most trivial usage scenario. There is no detector. The contract trusts your mobile phone to provide the GPS coordinates and that they are correct. This can, of course, very easily be spoofed and that's the whole reason why we have introduced hardware detectors. So, with hardware detector, the mobile phone would interact with the detector and then the detector would authorize the user's phone for an amount of time. And then the user would be able to interact with the contract for this amount of time. A variation of this would be when instead of the contract interacting with the user, the detector instead sends a signed message back to the user which the user would have to include with his transactions. And finally, the more interesting scenario would be no user, just an object. An object with a small tip, a tag as we say, that as soon as it comes in the range of a detector, then a transaction is fired. The power tool pictured here in the graph, for example, could be returned to its charging station and then pay for itself for how much time you have rented it. So, here is a demo of our Android application. Here is the loading screen. We can see on the menu on the left our account, balance, number of peers, et cetera. This is in Robson. So, we are in Berlin, we are in Langestrasse and we want to deploy a contract that uses detectors. We can specify the type of detector, either Bluetooth or manual specification, which in this case is a QR code detector. We paste the address and we have to provide a name. So, because this is a discount token contract, we will just say discount token example. We have to provide an authorization duration in a number of seconds and since it's a token, we also have to provide the number of tokens that total supply. Since it's in Robson, as you probably all know if you are using it, we need to give a hell of a lot of gas, 100 gigaway, which is a lot, and unlock the account. Very, very secure password, please don't say this. And so, that creates a transaction that is sent to the network. Now, we are waiting for a transaction to get included in the block and as soon as that happens, we will get a notification inside the app and then also outside. And if we check Robson, then we can see, yeah, something happened to the video here, but anyway, you can see that in Robson it's shown in Ethoscan. So, for the other scenario, we find the same contract and we want to interact with it. Remember, we deployed it with a QR code detector. So when we appear to interact with it, we have to select QR code and then the device, our mobile app will have to scan the detector's QR code. That will generate assigned methods, but we have to include the transaction. Remember, Robson, so a lot of gas and that will allow us to create a transaction which we will send to the blockchain. While we are waiting for it to get mined, you get a loading screen and once it's sent, then you will have to wait again for it to get mined and you get a notification inside the application and outside and then you have actually interacted with the detector, proved your presence and claim some tokens. So, essentially, as you can see, Cicorca is kind of an ecosystem of various parties. There are the people who will deploy and maintain detectors which provide hardware verification for Cicorca contracts. Then you have the people who deploy the contracts and those who interact with them. These are all people with different incentives and we have to think of how to properly incentivize these different parties. This is totally under research and we are just thinking on the problem and we would like to provide some kind of incentivization mechanism. This is just a rough idea. Maybe end users and contract employers or only one of these parties would be paying minor fees to the contracts and these fees would be forwarded then as a closed ecosystem to the people who maintain the detectors. This is all just rough ideas right now. If any of you actually have any good ideas on that, I would really like to hear from your feedback so just find me around the conference and we can talk about it. So, our technical challenge is ahead. Basically, how to combine input from various detector types. Since we have the QR code, Bluetooth, we can add different ones and a contract can actually have multiple detectors. We have to find ways to combine the input. We have to deal with device grinding fraud. That is when a smart guy pretends to be multiple people by just having 10 devices with him and then claiming all the tokens for himself. Identity systems would come really in handy here. And of course, privacy. We are talking about location transactions in an open ledger such as the blockchain. You do not want everything open about you in the blockchain. We are thinking about that and looking closely at the ZK Snarks research. So, as for our next steps, we want to reach the first stable version of the application, make it available in the Android App Store and then further net to the development of the ecosystem. These slides that I showed about hardware and the builders and the authors of contracts and the users. So, essentially that's all. If any of you are really interested in the problem of proving your presence for decentralized applications, please find me around the conference and let's have a chat. For more up-to-date information, just follow either me or Kelsos in Twitter or GitHub. And yeah, that's all. Thank you very much.