Thesis or project ideas from my research


Send me mail if you are interested in a certain topic.


Byzantine protocols and sybill attacks in the bitcoin system, more...

Frequently over the last couple of years I had a tummy feeling, that we would should look more carefully at byzantine protocols for consensus instead of always depending on a simple fail-stop error model. The discussion at The Morning Paper on Decentralization in Bitcoin and Ethereum networks Gencer et al., FC’18 shows an interesting idea for the use of Byzantine protocols in the blockchain. The measurements show how many of the blocks are controlled by a small group of miners. The group is so small, that the energy hungry mining proof of work process seems like a total overkill. And the paper suggests that a byzantine quorum of the size of 20 miners would already distribute control better. Another very interesting measurement shows, that ping distance between bitcoin miners is rather short and equal and much shorter than with Etereum. This is not a technical problem for the blockchain algorithm to work, but it raises an interesting question: How do we know that the few important miners really are independent identities? In other words: the sybill attack question raises its head. The close ping distances let us assume that most important miners are in one geographical area. Which means, that they can be controlled by one state. So, replacing the proof-of-work algoritm with a distributed consensus would only solve the energy question, not the possible control of the blockchain by external entities. What if ping distances would be much more diverse? First, ping times can always be faked in the direction of slower answers. Second: what stops a state from running mining nodes in other states? This would make the whole system look much more distributed as it really is. And as far as I know, there is currently no solution for the sybil attack in general (one identity controlling several different identities) in peer-to-peer systems, let alone political control of miners or conspiration between them.

This shows nicely, that byzantine protocols are not a panacea for distributed systems. But there are many cases, where conspiration by an external super-power can be reasonably excluded. Byzantine protocls certainly help against few attackers and make distributed protocols much more reliable. A good starting point is again a discussion on The Morning Paper of Practical Byzantine Fault Tolerance by Castro and Liskov.

Addendum: I just realized that George Bissias, A. Pinar Ozisik, Brian N. Levine and Marc Liberatore have written a paper on Sybil-Resistant Mixing for Bitcoin which could offer a solution in the case of bitcoins.

Measuring traffic with Raspberry Pie and neuronal nets

While measuring dust levels has become rather easy due to Feinstaub selber messen there is nothing to measure noise or to count and analyse traffic available, at least not at decent prices and for the Linux/Raspy guys. The project has basically two parts. One: measure noise levels reliably and with A/C category. This allows to control e.g. nightly truck traffic through villages to avoid toll fees. The measurements need to be automatic and round the clock with timestamps. Data could either be stored on a stick/micro SD or transmitted via Ethernet/WLAN/GSM somewhere. POE or a battery pack might be necessary to allow easy installation.

Second: Based on the raw noise data, a neuronal network should distinguish the vehicle types: truck, traktor, regular car, motorbike. For trucks perhaps also distinguish two weight classes. A counter is needed as well. This allows a detailed traffic profile in a city or village. Of course, this part of the traffic analysis can happen offline. Ideally, the results should be available in the cloud.

The full monty would be if the software could detect the same vehicle across measurement stations. This allows a detailed profile of routes taken by cars and e.g also allows detecton of toll avoidance. Well, while we are at it: the doppler effect might allow us to even measure the speed of vehicles as the change of frequency per time unit.

I was unable to locate anything like this in the public domain yet. It would be no problem to buy a sound level meter for this project, but again: most only can be used with windows and are of no help here. Another alternative could be to use cheap smartphones for this purpose. Or a microphone (outside) connected to a Raspberry pie (inside). Let me know if you think about this project and we can discuss alternatives.

Proven Distributed System Protocols with DISEL

On my first day at work in 1986 I saw DAC, a grammar based HDLC protocol implementation written by my friend Claus Gittinger. He used Yacc to generate the code. The advantages were clear: if some weired behavior showed up, we looked at the grammar to see if there was a protocol violation. This made the protocol very easy to debug and to adapt for changes in the standard. Nowadys, DISEL (based on Coq) seem to allow even more. Programming and proving with distributed protocols Sergey et al., POPL 18 . Let me know it you would like to give it a test drive. Its dependent types make sure that the implementation is correct without refinement and verification is compositional.

Root-of-Trust Concepts

A secure core of a system is needed for secure processing. This works in cars as well as in PCs. Teslas RoT . Let me know if you would like to build something on a Raspbery Pie in an IoT context.

New DARPA research on secure hardware and verifiable systems

Looks like meltdown and sprectre and other attacks finally triggered some fundamental research on hardware and software for secure systems. System Security Integrated Through Hardware and Firmware (SSITH) program and Cyber Grand Challenge (CGC) . Let me know if you would like to look into the hardware or software side (theorem provers, deep learning)

Leslie Lamports Temporal Logic of Actions (TLA+)

Disributed Systems have always been kind of weak with respect to modeling their domain. TLA+ could change this. Amazon is using it for complex services . And it is used in classes on DS e.g. by Murat Demirbar. Your task would be to give it a test-drive in a demonstration project.

Universal sensor unit

Currently, a group at HdM is building a universal sensor unit. Several sensors can be installed to collect data on NO2, CO2, noise, temparature, location, other chemicals etc. In the simplest version you need to come by with a smartphone to unload the data into a cloud service. If more energy is available, the unit can push data by itself into the cloud via Wifi or GSM. All sensors should have us USB connector. The unit can be used to measure fine dust particles also, using a sensor from Stuttgart.

Time and Reliability of Distributed Algorithms

The paper on time in VMWare VMs made me kind of skeptical about the performance of distributed algorithms (e.g. failuer detection) in settings with instable time. The thesis would set up some VMs and test timing behavior of distributed algorithms for consensus or failure detection. Will jumps in time only affect liveness or even consistency?

Social Bots

Using bots to collect data from social networks, e.g. to investigate the creation and spreading of fake news.

Simulation and Visualization of complex dynamic systems

How to simulate distributed algorithms and their failure models to get a handle on complex protocols like Paxos. Or how to simulate a large scale site using components.

Socially Situated large-scale multi-touch devices

Social GUI construction and application integration for large-scale multi-touch installations. Social analysis of interaction patterns, technical design and implementation. The scale of those devices makes single user concepts useless and requires group interfaces.

Multi-Party Mobile Microphone

This has been a sore spot for quite a while: to enable discussions at events it is necessary that everybody has access to a microphone (this is also needed for streaming). Unfortunately the way this is done till now is through the use of long poles with microphones held by helpers into the public, by stationary microphones hanging from the ceiling in large numbers or by speakers leaving their seat and walking over to fixed microphones. This is all either too expensive or too clumsy given out narrow rows of seats and the need to hold events in different rooms each time.

My idea involved throwable microphones which can be centrally controlled and which are activated by pressing the ball. Most discussions involve only very few people and locations within a larger room and a small number of these ball-mics would be distributed across the room. Speakers can get access quickly. The following drawings might give you an idea: and a version that uses balloons hanging from the ceiling:

The article "the problem of many speakers" gives an explanation of the context.