Okay, let's do it like this. Thank you very much Peter for all the efforts for the I2P
deff room and by the way, do you hear me back there? Yes, lovely. Okay, right. I hope that
the sound check is good now and we're not muted anymore. I'm the I2P guy. I'm one of
the I2P guys and I'm talking about fully distributed networks with their specific
problems. Fully distributed means truly fully distributed. So today we're also talking about
systems without any trust involved, at least in theory. All right, hands up please. Who's
familiar and is using I2P or who's familiar with I2P? Yes. Oh, I love you guys. That's
really awesome. We have one third which is familiar with I2P so I'm really rushing through
the I2P part. But then I'd like to talk about my depressive, my depressing last 12 months,
which gave me really a hard time with implementing a persistent storage layer based on I2P and I
will tell you why and I will tell you about all my failures and problems and yeah, I will
complain a lot. No, we're talking about bit about Byzantine fault tolerance and the good
and the bad of the past year. Right. Diva, I'm working for Diva Exchange but it's only
an association based in Switzerland. I'm sometimes a lecturer at the University, at
the Lucerne University of Applied Science, and there I'm talking about microservices
and fully distributed trustless systems and stuff like that. But I'm singing nobody's song
so I'm really totally completely independent and so is Diva Exchange. So we're not some
coin guys or token guys, which doesn't mean that this is bad, we're just not like that.
So hello I2P network. I2P is well known as a dark net because the media talks about it
as a dark net, which means and we'll talk about it later that it has something to do
with confidentiality and anonymity. But at the end it's an overlay network. So we have
the existing internet and on top of that we place software routers to pack the traffic
into packages, repackaging them, encrypting them and sending them over several hops and
routers through the network. And like this we receive a confidential and anonymous message
transport. I2P is no storage layer. Whatever you hear about the dark net that there is
content stored etc. That's not true. I2P is not able to store content by itself. There
are storage mechanisms like the interplanetary file system which is linked to file coin and
these are storage layers. But these storage layers do not necessarily feature confidential
and anonymous transport. Often they even fail on implementing such a layer. Six, seven months
ago we made a study at the Devalor exchange and we were interested obviously in how big
is the latency of UDP package transport on the I2P network. And as you can see it's slow,
really slow. And that's the price for privacy. Anonymity, confidentiality is not for free.
There is a price attached and this price tag within the I2P network is time. It's slow.
Maybe but that's a theory and we need to look at the university into it. Maybe with a strongly
increased number of routers maybe we can increase the bandwidth. But that's just maybe. I don't
know. We have to do scientific research on that. But this is the current state. Now a
dark net, an overlay network as I2P has cryptographic addresses. They are public keys and often it's
a hash of a public key. And these B32 addresses so long cryptographic strings like up here
are not human friendly. I will not talk about so-called triangle at 6.30 this evening in
this room. You will have a presentation about this topic which is for sure also highly
interesting. But we have these hashes and we need to map them to human friendly names.
That's our job which we have to do in such a network. And that's why that's the motivation
we need at DNS. But the only thing which I2P really has is a local address book. So each
router, each note, there is nothing like a central authority. Each private note has its
own look up key value store. It's called address book. So there you have a friendly name like
diva.i2p linked to a hash or to a B32 address to simplify things. And if I'm loading somebody
else's address book, this is a choke because that's a trusted operation. And within I2P
we usually say we don't trust no one, it's trustless. So obviously we cannot just load
address books from somewhere. Additionally within the I2P network if you're looking at
the specifications and if you're looking at how the network is working today, we do have
jump services, we do have kind of like registries, but all these services are again a delegation
of trust, nothing which we really want. And as you can see ladies and gentlemen, I'm really
critical towards the I2P network. I see the central components which we have within this
network and I'm criticizing them. But not criticizing in a negative manner, I'm rather
trying to make me as a developer and also the other developers to be aware of these
central components. Right. Now Goethe, German, des Pudelskerren, the core of it all. Why
are we doing this at diva? Why am I doing this? I want to have a service, a storage
service and hence a DNS service which is A, fully anonymous, B, immutable, C, really
barrier free. And barrier free is an interesting concept if you start to think about it. A coin,
whatever it is, Filecoin, Namecoin, Monero, Bitcoin, Ethereum, I don't care, is not by
its definition barrier free because, well, you have to acquire it somehow. So there is
a barrier and barrier free in the meaning of device change means you have a very low hardware
requirement to enter the network just to drop a name, a raspberry or any other low power
device and ta-da, your member of the network and you can store stuff. And if the barrier
is that low, by definition, the spam will be high. So we have to think about a cost function
but the question is how is this cost function going to look like? We're going to discuss
this in a minute and trustless. Again, I2P is built, architected, engineered in the last
20 years as a trustless system. Trustless means I really need to only look at my own
node and either my node is right or it's wrong. I don't need to care to whom I'm connecting
to because every data which is incoming, I have to verify myself. If I'm not doing the
local math, I'm trusting somebody else and that's a bad idea in the context of I2P. Trust.
I can tell you trust me the earth is flat. Now we all know that the concept of trust means
I'm believing in a wrong set of root data or made upset. It's just invented and as if
I'm starting to invent root data, I can prove anything because the root data is fake. I
don't like that word. The root data is made up. Now if you're building your system of
trust, your system will grow and we know in IT, but actually at least the view I have
from my specific scientific point of view that the larger systems are growing, the more
problems we do have in these systems because we need to introduce regulation that the trust
is not abused. More regulation means later even more regulation and so it gets more and
more complicated over time. One of the typical solutions, at least what I'm lecturing about
is keep your system small. So base your decisions on math, base your system on math, keep them lean
and at the end add a cost function to prevent spam or abuse to be a bit more generic. I2P
is at least from my point of view, a network which enables
small and lean systems. Right, where am I? 1540. In history, building a DNS on a fully
distributed network, the approach isn't new. One of the older approaches is our systems
which are based on the hash cash function which was properly described in 1990s and then
leads to proof of work systems and these proof of work systems, they created currencies,
like we all know Bitcoin. Maincoin then came in and other things which are proof of work. What
I can guarantee you is proof of work is working. Proof of work as a cost function is mathematically,
at least what we know today, perfectly working but it's extremely inefficient because it's a race.
It's a race for the fastest solution. This is a bit trivial but at the end of the day it's a race
and this race is inefficient. Now, I always resisted to implement yet another proof of
work function, not because it's not working, just I didn't want it. What I also not wanted
was the Filecoin interplanetary file system solution which is a validator approach because
validator approach means nothing else and Filecoin did its moit. They used DRAN to select
validators but they're just shifting the problem from their own system to another system and
then they say we're solved but that's not true. At the end you just move the attack vector
away from your own system just to open up another attack vector and for me, just for me,
currency based, proof of work based or validator based is not really an approach and as I
am an economist which I studied, I feel very uneasy, very, very uneasy about non-fungible
currencies. There aren't many. A few are. Make your own research and you will find out which
are really fungible. The others are difficult. Let me put it like this. Then there are Naive
concepts which are very nice, highly performing but at the end you need in the area of DNS
and in the area of DBA what we're talking about, immutability and integrity. Right, I want to
lose a few words about the CAP theorem because consistency, availability and partition tolerance
are a triangle within this CAP theorem and it's said that you have to choose two out
of these three. Now some blockchain guys said hey we solved it, now we have all three. At
least with Butante's fault tolerance I have my doubts and honestly I do not see any concept
out in the wild which really solves that problem except proof of work and we don't want that.
So this year and that was part of my biggest struggle. We had to leave and that was the
talk I had in 2023 exactly here at this place about democratic Butante's fault tolerance
which is developed by the University in Lausanne in Switzerland and also in Sydney, Australia
and sorry guys with I2P this concept is not working because and we're talking about fallacies
right afterwards about the problems with such networks, democratic Butante's fault tolerance
was a fail. So we went as Diva chain into eventual consistency because the big problems
in distributed computing known since the 90s are things like we have zero network latency
wrong, we have unlimited bandwidth wrong, we have a secure network wrong and we all know
that as Diva Loppers but sometimes in the lab we go into a perfect world, dream of something,
create something and then in the real world it's not working and that's why my biggest
tip for every blockchain developer in the universe tested on I2P. If it's still working
you probably done a good job and that's exactly one of the core messages. I2P has that many
network transport problems which are the price for privacy and which we want that it's
a very good test case, a very good transport layer for all the blockchain developers out
there including myself. So what we did in the last 12 months with Diva chain and obviously
you'll find it on GitHub, we created a transaction based system which is barrier free, immutable,
trustless and based on I2P, so fully anonymous. It's working now, it's working since about
three weeks. The students, the last three weeks at the University of Applied Science in Lucerne
wrote a little prototype with I2P but they had a lot of API troubles and struggles because
I made mistakes so it was my mistake and at the end I couldn't present here the final
prototype but because of me not because of the students, they did a good job. And what
we're thinking today is how to implement the cost function because at the end a barrier
free system I already said that will attract a lot of spam, a lot of DNS spam, a lot of
content spam, a lot of whatever we can use this system for spam and that's not me as
one of the developers that's not my intention. So probably it will be a function of availability
and a function of cooperation and when you read this now and when you think this is new,
no it's not. Filecoin already implemented this since 2014. The only problem they had
was their validator selection so they made the mistake of using a validator function
to implement their consensus but this they call this proof of storage, the function of
availability and the other one they call it proof of window consistency or something
like that but you have to prove two things. First you have to prove in the network, prove
means mathematical proof that your content is stored and B that your content is continuously
stored. So these concepts here are not new, I would just like think about it a bit more
and then implement it. I already talked about my core failures or our core failures in our
very little team. Democratic Britsantin false tolerance, a very nice concept, a very nice
book, I learned a lot, it didn't work. The eventual consistency approach is working since
a few weeks, API is highly unstable, I have a lot of coding work ahead of me, in front
of me and I'm looking very much for feedback so if anybody is interested in hacking in,
I'm always happy if somebody wants to contribute and the academia feedback was also very positive
so I could show a few interesting things in the past months. Please in the last two minutes
take out, in the last minute take out this take out, we believe that the eventual consistent
DNS or blockchain like system used for this DNS challenge is a reasonable approach, eventual
consistent so we drop blockchain consensus and replace it by eventual consistency transaction
based. The core challenges as know today, we need to implement the cost function which
is reasonable, decisions, decisions in our wording or nothing else, there is a global
state where all peers and I2P network agree on a specific state of data and the participation
is very welcome. In the presentation on the web which you'll find in this deaf room on
the fourth step page you find all the sources and some more stuff so if you have questions
please shoot. Yes please. Could you explain what you meant by immutability? His question
was could you please explain what you mean by immutability? The answer is once written
never change again. Yes please.
Right he's asking in our system we're going to have a lot of traffic, we're going to
have a lot of records stored right did I did I summarize that correctly and that's a problem
right or that's your question in terms of storage right first compared to other approaches
Diva chain because DNS is a side project we never like handshake or other projects we
never intended to replace the current domain name systems therefore the clear net we always
wanted to match I2P names like Diva.I2P because nobody is going to give us a domain to be
32 addresses so no we don't have much traffic there and so the storage problem is nothing
I'm currently thinking about but yes there will be sooner or later scalability questions
you're absolutely right but in this baby state I don't really care. Yes please.
This question was if it's immutable how can I change things? In the blockchain world you
never change a record you just let it live in a block or let's call it inner transaction
and then you just create a new transaction on top and this new transaction is the new
state because in a blockchain you always look from the top and the last state is the thing
you believe in because it's properly proved using math. Is your answer given? Okay. Maybe
a question from the phone? No other questions? Thank you.