We'll get started here.
How is everybody doing?
I hope you've been having a good time with the conference.
And welcome to talk, so we're going to talk about,
well, the question is, was Leslie Lamport right?
And it's a bit of a loaded question and you could say,
well, maybe it's a bit clickbaity like in a YouTube way.
But what we're going to do is we're going to look at some of the papers
that were written by Leslie Lamport over the past 50 years or so.
And you can see, well, first evaluate what they,
the concepts are in them, but also kind of look at the questions
and sort of, are they still relevant in today's world?
First, I think you should know who we are.
So I'm Sarah Kristoff, I'm a staff software engineer at Adera.
And I am the founder of the Leslie Lamport fan club.
Everyone can join after the talk and please email Leslie himself
and let him know that I started this club for him.
And I'm Nick Jackson, I am member number two of the Leslie Lamport fan club.
So, so our agenda, we're going to have a look at a little bit of a history lesson.
We're going to look at consensus, consistency, concurrency,
clocks and gossip.
And let's get moving.
So it was a kind of a bit of history, one of the most sort of attributable
famous papers that Leslie has written is probably the Byzantine generals problem.
So what we want to do with the talk is we're going to kind of take that theme,
and we're going to run it through all of the other examples.
Hopefully.
Now, where this sort of came from, where did the Byzantine Empire come from?
Well, it came from way, way back when when Emperor Constantine
back in the Roman Empire decided that he wanted to create a new capital for Rome.
So they created this capital on the old Greek settlement of Byzantium.
Now, the capital was known as Constantinople.
Are there any, they might be Giants fans?
Because, you know, obviously now that Istanbul was Constantinople.
And now that that happened in the third century, but by the fifth century,
the Byzantine Empire had really grown.
It was like growing in quite a lot of strength.
So again, Emperor Justinian decided that he was running the eastern Roman Empire
Byzantine that he was going to take over Rome.
And that was his ambition, and he did, and he united the sort of the whole thing,
which leads us into the setting for our theme, which is around 500 years later.
So let's introduce our cast of Heroes and Villains.
So Emperor Romanoz in 1034 was actually the Emperor of the Byzantine Empire.
He was, well, he got sick.
He was married to Emperor Szovi, who allegedly also poisoned him,
because Szovi was having an affair, allegedly,
with Michael the Money Changer, who then later became the Emperor of the Byzantine Empire.
Now, Michael was a Money Changer.
Michael was basically a counterfitter.
But Michael was also not particularly well versed in government or business.
So to run the kind of the complex side of governance,
Michael employed his brother, John the Unic.
Now, our generals, we have George Manalix.
George was one of the most fierce generals,
the most successful generals in the Byzantine army at this time.
But he couldn't do this alone.
And the Byzantine Empire, which I think was really fascinating,
wasn't just kind of self-supported.
They actually had an army of Vikings, the Varangians,
led by Harold Sigginson, who later became the future king of Denmark,
as a kind of a general, the top general in the army as well.
I think it's pretty fascinating, but we can get into the real stuff.
And that brings us to the two generals problem.
So in this problem, this is kind of a runs back into a classic paper.
Things around the sort of the 70s, and it was around the concept of database consistency.
And the concept is that if only one general attacks, both will be defeated.
If none of them attack, they both live to fight another day.
And if they both attack, then they can take the city.
So it's around that achieving consensus.
And the problem is written to be, it's not solvable, right?
Because to be able to ensure that consistency in a system where messages are not necessarily guaranteed,
you can end up with a situation like this.
So Harold and Georgeus, they want to attack a city.
So George says to Harold, hey, I'm going to attack at 10 a.m.
Can you confirm?
And then I will attack with you.
So Harold sends a message back and says, hey, yeah, sure.
Let's attack at 10 a.m.
Confirm you got my message, so I know we're both going to attack.
And then George sends a message back, which says, I'm confirming your confirmation.
Can you confirm that you receive my confirmation so that I know that we're both going to attack?
And then Harold sends a message back, says I'm confirming your confirmation.
Can you confirm you got my confirmation?
And this goes on and on and on and on.
And ultimately, because they never know whether any of these messages could be intercepted by the enemy,
well, you know, you can't kind of have that consistency.
So at the time, the kind of Michael is looking at this and he says, well, I need a solution.
And what can that sort of solution be?
So he speaks to John the Unic and they come up with this solution here,
which is where John suggests that if Michael acts as a commander and then we have the two generals of George and Harold,
then if Michael issues an order to George and if George exchanges that order with Harold, then they should be able to come to consensus.
But it doesn't work because if a message gets intercepted, now in all of the sort of the paper on the Byzantine General,
Leslie Lamport treats this or he calls it a traitor.
So in this instance, Michael is a traitor, but what they're really implying is that it could be a faulty node inside of a system,
or it could be a fault with a message.
So you end up with this situation here.
And then if you kind of boil that down, what you can see is that because of this faulty message, don't look at that.
Then you actually end up with an inconclusive situation because both George and Harold have conflicting pieces of information.
How do you fix it?
Well, you fix it by introducing another general.
So John says, well, if we introduce one more general into the mix and we're all exchanging messages in the same way,
then we should still be able to, we should now be able to achieve consensus.
So in the instance here, so John is acting as the traitor.
Michael sends attack messages to all three generals.
Harold and George exchange attack messages.
John sends retreat message. He changes the instruction or the messages has been intercepted and has changed by the Syracuse in.
But then can they receive consensus?
And if you look at now when you kind of sum up all of those different votes, you can still see the George and Harold can achieve consensus because they have two attacks.
They received a retreat, but they still can come to the consensus that they're going to have an attack.
And that's one of the cause of the paper.
The core of the paper is that for a Byzantine problem to be solved, everybody who is an acting part in the problem has to be able to agree on the same outcome.
So let's kind of make look at it as another way.
What if Michael is the traitor?
What if his message gets incorrectly intercepted?
So you can see here again, George and Harold receive attack.
John now receives retreat and sends retreat, but if we look at the combination of that, we still can achieve consensus.
So now we've proven that for four generals, we can achieve consensus in the presence of a single traitor.
Now in the paper, Leslie writes this as three and plus one, where M is the number of traders.
So the number of generals that you need to achieve consensus with one traitor is three plus one or four.
Now if you have two traders, it's seven.
Now I looked at this and I was like seven, you need seven generals to come to consensus, that doesn't make sense to me.
I thought five would be fine because, you know, if two of them don't get a message, you've still got three, you can still come to consensus.
It's not the case, so let's look at the proof.
So one traitor for two traders, we need seven, three ten generals and four thirteen, and that's following on from the formula.
So now we don't have a kind of a slide for this, it's kind of going to be, sorry, a picture, but you can see here that the commander issues attack,
every one of the latinants, I've got five latinants here, six generals and total.
Now what each lieutenant does is each lieutenant sends the commander's message to each other lieutenant.
So they can all see what everybody else received.
Lieutenant three in lieutenant four are traders, however.
So to achieve consensus, they all have to agree on the same thing, and you can see here they all agree on attack.
Now we're just kind of ignoring the traders out of this.
So I looked at this, and I was like, but that doesn't prove three and plus one.
Like this proves that this does work with less, unless the commander is a trader.
So if we look at what happens when the commander is a trader, you can see that with the commander being a trader under lieutenant is a trader,
then the overall kind of consensus can be affected.
And now, lieutenant one has retreat, lieutenant five has retreat two and three are attacks.
They don't have consensus, which means they would fail to kind of win the battle.
So let's add the additional general link here.
And we're going to add the additional general in, so now we have seven.
And we're theoretically satisfying that formula, three and plus one.
But we still have inconsistency.
So we have this three and plus one, and we still have inconsistency because it's still possible with the two traders to influence the kind of the outcome.
And the reason for this is when I read the paper and I'm looking through it is I missed a core step.
The core step is that Leslie Lampord also states that to kind of identify and validate what you need are T plus one voting rounds.
Where T is the number of traders and was previously known the traders, why don't make this up?
This is this kind of average written.
But we have T plus one.
And if we can look at those rules on there, what what an example voting round would be is that every lieutenant sends their value to everybody else.
They try to find an outcome.
If they then they send the result onto others.
And then the little ten's going to use that data to complete a final outcome.
So if we kind of look at that, then we can now see that the lieutenant two receives all of the data from every other lieutenant.
And they can see that actually the consensus amongst the other lieutenant is retreat.
So then if they change their decision to retreat, they now have consensus among all of the generals and the formula works.
But what if we kind of say, all right, let's now apply that additional round to the six generals?
Can we achieve consensus with six generals?
And the answer is no.
Because the kind of that we can't, we're still not, well, we're getting a volume of attack, which still didn't give us consensus on the sort of the previous.
So the formula stands.
Three M plus one with T plus one voting rounds.
And you can solve the Byzantine generals problem.
And it's just cool.
Like this goes back, obviously, to 1034.
But also, I think the paper when it was originally written was 1978.
And we'll talk about that later, but we kind of still see this today.
Cool.
Now we're going to talk about consistency.
So in the time of the Byzantine Empire, we are still trying to figure out how to handle consistent communication.
Even though we have the Byzantine generals problem,
figuring out how to handle just transparent open communication, like you would in a relationship is pretty difficult.
Thank you.
So the best stages are built on open and honest communication.
So how do we have that happen when we have different militias, different lieutenant and maybe faulty pigeons?
So in typical Michael fashion, he asks John the Unic,
Hey, how do I figure out how to handle like inconsistent communication from my generals,
from my lieutenant, from myself, from you?
And John the Unic identified three key areas to make modalities or models for better communication across these militias.
And just to keep in the story, I've kept what they are really called underneath,
and then what we're calling them in terms of the story on top.
So he said we're going to have focus on message consistency, soldier availability,
and tolerance to bad actors.
Couldn't find a good way to say tolerance to network petitions in like 10-10-35 terms.
So that's what we get.
So John the Unic proposed four different models.
Aventual week strong and sequential consistency.
So for eventual consistency means that we can't really guarantee that the message would be delivered,
but no promises also on when a different general inquires to the lieutenant.
Hey, have you received this message?
Are you up to date?
You will eventually get it.
You will eventually get the most up to date message.
So we can see here, don't wait.
Thank you.
No.
You can see here that general one says, hey, are we going to attack?
I'm sending an update.
Hey, we attack.
John choose, are we attacking?
No, we're eating.
We're having dinner.
But eventually the lieutenant comes up today and tells the third general.
Yes, we are attacking.
So eventually consistency.
Yes.
I'm going to do this now.
I'm better at this.
Anyways, for a week consistency, there are no promises, no guarantees.
You can send updates.
There's no guarantee from the lieutenant that he will get the update.
But also on top of that, there's no guarantees or safety promises on when the other general
will receive that update as well.
For strong consistency means that every ask or update to the general and also every read
will have the most up to date information.
So this is very hard to actually deploy.
So they created something called.
Strong sequential.
I can make a really cute image so I use the comic.
So basically strong sequential is something that Lampart proposed or John the Unic.
Choose your character here.
What it means is that we don't really care about the things that happen in between.
We only care about the end goal.
So in terms of strong sequential, we can say that hey, the messages may arrive out of order.
They may arrive in order.
What cares is that we get to the right purpose.
And a good video that I watched about this because I've been studying this all week.
Which is fun.
It's basically like if you've ever commented something on Facebook or you've twisted before.
And you'll see that someone has commented before you after you refresh.
That is sequential.
Strong sequential consistency, which is that you'll see those updates happen after.
And it will get to the right order, but you might see them not when you do it the first time.
So consistently models are used in everyday seizures or in everyday distribution systems.
You've probably heard about them a bunch of you deal with databases.
And I think they're pretty good to know, especially when designing systems.
Limer talks a lot about using math.
Oh, sorry.
Limer talks a lot about using math to design these distributed systems.
And I think consistency models are things that aren't shown enough when making these systems.
So that we can know.
Nick, you're so bad at this.
So in a more Limer-esque state of mind, knowing consistency models will help you deal with
down time or when you're creating these systems.
What you want to do with these types of messages and what consistency guarantees you want to give.
And then you can give the next one.
Okay, cool.
And now on to concurrency.
This one is short and sweet, too.
Sorry.
Cool.
So Limer and I don't have a lot of things in common.
But what we do in common is that he's never taken computer science course
and neither have I.
But he did write a talk or a white paper on how to teach concurrency from his point of view.
So the sad part about this is after I attempted to teach this.
I kind of can call it a computer science course and we will no longer have these things in common.
So Limer starts about talking about how computer science is based off of the
figuring out what is a computation.
Because computer science is the study of computation.
So for the purpose of this talk, thank you.
We can state that a computation is a sequence of steps.
But that leads us to our next question, which is what is a step?
And for the purpose of this talk, a step is one state, a transition from one state to another.
Now, Limer and his white papers like Staharp about how he thinks technology should work.
And I think he's right.
He says that in Western society, we focus a lot on actions and verbiage.
And so in computation, we are focusing a lot on the transition and how these verbs influence how we think about computers.
But what he says is that we should think of computations and computational hardware
as just state machines, right?
I only care about the present state I am in and how I transition to the next state and not the past.
So with that in mind, we will only focus on basically how to transition from states and not the actions to transition from states.
So Limer goes on to talk about invariances, which is a term I've never heard until his paper.
So an invariance is a condition that can is always true throughout the execution of the program.
And he talks a lot about inductive invariances, which is basically similar to strong sequential concurrency.
Man, that's hard to say fast, which is basically we do not care about the things that happen in between an execution.
We only care about that we get to that true and state goal.
So a very simple way to understand invariances is if your base invariance is n equals 1, then your inductive invariance, which could also get to that true state, is n equals 1 n n plus 1.
You get to the same n equals 1 value in either way.
I found this quote really cute, mainly because when he talks about computer engineers, he says she, no, maybe happy.
Anyway, what's an engineer understands what a computation is and how it is described.
She can understand the most important concept of in concurrency.
So I thought you were cool to lay out how to teach concurrency in a different way than just going into like talking about mutual exclusions and semifores, which we will get to.
Awesome, so in 1965, a guy with a name, who I'm not going to try and say right now, had a paper called the solution of problem and concurrent programming control and he proposed the requirement of mutual exclusion.
And if those of you who have really taken compsi 101, probably know about this and those who don't, what's up, good job.
Mutual exclusion is a way to present race conditions and concurrent executions.
Yes. Now, Lampart created his own mutual exclusion algorithm called the bakery algorithm.
Lampart calls out that in the original mutual exclusion algorithm, it satisfies the deadlock freedom.
Meaning that if one or more processes try to enter the critical section, one of them must succeed.
Now, in more recent papers, which I guess are younger papers, they try to satisfy a more difficult.
They call it, no, go back. They try to satisfy a stronger requirement, which is the starvation freedom requirement.
Meaning that every process that tries to enter the critical section eventually does so.
And so the bakery algorithm does satisfy the starvation requirement.
As pretty simple, honestly, if you've ever been to a bakery, you know how this works, which is you go in, you take a number, you wait.
And so every process that enters the bakery or every customer that enters the bakery goes in takes a number and waits.
When it is cold, then it places its order and you take it and you leave. Now, there's a couple things to take into mind here.
One is that when you take the number and you're waiting, you are in a non-critical section of the code.
So you can walk around, you can text on your phone, you can do whatever.
But when you are talking and you're placing that order, you're in critical code execution.
Now, a couple of requirements are met by this, basically saying that you can't have a process that hangs and basically tries to take an order forever.
Another thing that they also try to meet is a process halting.
I didn't know a good way to say in the algorithm here how a process would all.
It would just be like if you were taking an order and then you just like plopped over.
So it basically says if that does happen, then you exit into the non-critical section.
It would be like if you got pushed away back into the bakery.
And you can at any time, as long as you're in the non-critical section, re-enter the critical section.
So you can order as many times as you would like as long as you do not halt.
This is a good way to stop concurrent programs from reading and writing and updating at the same time.
Well, now, this is pretty simple.
The bakery algorithm, this is his first, like, basic way of solving it.
What he then does throughout the paper, which you can read on your own time, is go into the, do constructive bakery algorithm and the distributed bakery algorithm.
Basically, we try to make sure that the lower number always goes first.
No one halts in the critical section.
And that everyone at least gets one attempt at ordering.
And that leads us up to kind of looking at the concept of time.
Now back in the, the Byzantine Empire, they did have distributed time.
They had a distributed clock, which we still have today.
It's the big orange ball up in the sky.
And that was the kind of the primary source of understanding what the time was.
You would have to use a sundial in, in combination with, with obviously the sun to understand time.
Now, in general, if you just kind of want an approximation of time, that is absolutely fine.
But the issue is when you need absolute time and you need to, to be kind of for some things like if you want to do message ordering based on time, then you need to be much more precise.
Where kind of sort of in certain his paper in 78 Lampo is addressing this as a problem.
And one of the kind of the examples that he's citing is that, you know, in later revisions, even with prompt things like NTP, you can still have clock drift.
And even if clock drift is by milliseconds, if one machine doesn't have the same exact representation of time that another machine, when it comes to event ordering based on time, you can run into problems and you can end up with mismatched orders.
So if we, we kind of look at our theoretical scenario and see how this, this could work, it would be like this.
So we have Michael and George and Michael decides that, hey, we're going to attack the city and we're going to attack the city at 1030.
Now, Michael uses a physical clock to time stamp his message at 842.
George receives his message, but George then says, no, we shouldn't be attacking at 1030. We need to attack it 830.
So what he does is he then sends a message to everybody.
Time stamping it from what his clock says, which is 841, and sends it onto everything everybody else.
Now the problem is when Harold and John receive this message on when to attack.
We, you know, we can't guarantee the order of the messages.
So what they're doing is they're using those time stamps to sort the order.
Because Michael's time stamp is later than George's, they take Michaels.
So Michael and George attack at 830 and Harold and John attack at 1030.
So to kind of solve the problem of physical clocks in this way, lampor suggests a very, very straightforward and simple solution.
And that is to use what is known, a lampor clock, which is that every message will have a distributed scalar clock value attached to it rather than the physical value.
So then he proposes that the kind of the way that the system would function is like this.
So every general has a logical counter T.
Every time an event occurs, the new value of T is T plus 1.
Every time a message is sent, the new value, again, is T plus 1.
And then T is also added on to the message.
So when another general receives a message, what they can do is they can look at that value of T.
Now if that value of T is greater than their values or what we're using T, the message T there is T prime.
They will replace it with their own value and add one.
And then in principle this works really well.
So we can see here if we kind of look at that.
A couple more rules on that.
I will show you the chart in a second.
Lampor clocks mostly work.
Now again, but there are issues.
So what they can guarantee with a lampor clock is that if the event A happens before B, the lampor clock value of A will be less than B.
But what you can't guarantee is that if a lampor clock value is less than another one, that that event happened before.
And that's because clock values can run out of sync.
It's also possible to have two events with the same timestamp and lampor clock doesn't do well with concurrency.
But depending on the scenario, it's a very simple solution that works incredibly well.
So if we kind of apply lampor clocks here, so initially Michael's initial clock value is zero.
So he sends a message, increments to one, adds it to the message.
George then receives that.
He takes the timestamp value here because it's greater than his own clock value, adds one to it.
And then sends his own message, which has now has a value of three.
So when we look at Harold and John, well Harold and John now don't need to worry about the physical clock value, what they're looking at is that the lampor clock value.
The original message that they got from Michael has two attributed to it.
But then the later message that they got from George has four attributed to it.
So they can identify what the correct order of those messages are.
Very, very simple mechanism.
What strikes me is really quite lovely about this is that a lot of this research when it was kind of done by Leslie certainly the earlier papers.
He was writing about the problems and systems and distributed computing and probably didn't even have computer on his desk.
I mean, I think there's a very sort of high value, maybe a new number typewriter.
A lot of this is done very theoretically and through sort of hand computation, which I think is beautiful.
But kind of back to the kind of the point here, let's look at some of the problems and then we can have an issue here with concurrency.
So in the instance that Michael sends a message saying, hey, we're going to attack at 1030.
But George doesn't wait for Michael's message to arrive. He says, no, we should attack at 830.
So in effect, they're sending the messages exactly the same time. They both have a clock value of 1.
So then Harold and John, when they receive those messages, they receiving two messages of value of 1.
So what do they do? How do they distinguish which value, which message should take precedence over the other?
And the way that kind of Leslie discusses this and attempts to solve this problem is same or look in a situation like this, what you need is a tie break.
And a tie break, when you have two messages with the same timestamp, is just an algorithm that you'll use to kind of determine what the order will be.
You know, this could be just a lexical rule sort of list of the names of the nodes.
You could have a predetermined dictionary or a predetermined order.
The key thing is that every single node in the system needs to have an implement the same tie break mechanism.
So whilst you might not have guaranteed message ordering, at least you have consistency in the order.
Now, if you kind of want to solve the problems and look at things in a more complex way, vector clocks are a different approach looking this.
A vector clock works in the way that rather than keeping sort of a unified single scalar for all the clock value in the entire system, it maintains a vector, which is shared amongst all of the nodes.
But each dimension in that vector has the individual clock value.
And this allows you to do comparison to be able to identify things like concurrency better, a little bit of homework to kind of read that up on maybe.
But I'm going to hand back over to Sarah and probably press the button really badly for her when she talks about gossip protocols.
And do lots of pointing at you. Cool. Our last ish topic is going to be on gossip protocols, which is slightly import-esque, but not really.
So if you've ever been on high school, which I've talked a lot about today for some reason, you are familiar with how a rumor spreads throughout a high school.
Basically, someone starts saying that I haven't watched Mean Girls in a really long time, but I think Regina George is mean.
And then eventually the whole school knows and then you have to leave school and like, you know, move states and whatever.
The same thing as how like gossip protocols are created, it's a infectious or rumor style based protocol that is decentralized and peer to peer and focuses on nodes sharing information with another in their cluster to spread information about the cluster status.
So how a gossip protocol works, and please don't look too hard. Did you change these?
Yeah, I changed those.
Sick. Anyways, for around one of gossip protocols, you can see that G is talking to B interest information with B about either status of the cluster or node status, sending an update.
It could be like a livelyist probe or it could be saying, hey, I'm dead.
And now that B has this information about G, G can go tell or B can go tell. We should chose names. B can go tell F and D all about this.
And it will start to spread throughout the cluster itself. Basically, as G keeps propagating information about itself, B is now eating.
G in that spread of this information and it will propagate throughout the cluster until we have everyone knowing all of G's drama.
And you can see here it shows this image just because it looked really busy, not even going to hide it here.
So you can see here that basically how gossip protocols work.
Cool. So we talked a lot about Byzantine failures today. And in the beginning, Nick gave like actual discussion on how Byzantine failures and the paper was ran.
Gossip protocols are very susceptible to Byzantine failures.
This is because there is no like hardening techniques on it. It is just I'm sending messages to nodes trusted within my network to spread information.
So it can be right with this information. Now there is a lot of work on Byzantine fault tolerant gossip protocols, but I would say that ones that we have worked with.
Basically, you weren't built that way. And I'm talking more about like member list or any other type of like decentralized peer communication network that you use.
You can use different types of authentication to try and prevent this, but add it to basis things like swim, which is a what is it scalable weekly consistent infections style protocol, which is the one I've seen most implemented.
You can have any type of Byzantine fault tolerance. So you can have things where your cluster or server will fall over because we haven't protected against this.
And now to talk about Byzantine fault tolerance.
I'll talk about the cloud third one and then we'll talk about the robin hood one and even though this is recorded, this is all allegedly.
So cloud fair in 2020 had a Byzantine fault tolerance that happened a huge outage.
And so you can see that Byzantine fault tolerance is still very alive today.
And then basically, in 2020, there was a person who you might be looking at who removed a lamp or time stamp that was on a basically like the gossip protocol moved one case statement as a little baby intern.
And what happened is that there would be this thundering herd-esque problem where no one could come to like a consistent consensus on like how to communicate and nodes would start to topple over.
This caused a huge robin hood outage that was on CNN.
And then the person who might have done this found out via a team meeting on accident.
So you can see that just removing one case statement can cause a loss of multi millions of dollars.
And then the picture of the first Byzantine fault, which is basically that there was this like shuttle that NASA had.
And this thing needed to be turned a little bit more because they kept getting like interchanging yes and no values from the the valve that was like monitoring it.
And so the computer system wasn't able to like reach a consensus and give information because they just had to turn something.
So Byzantine fault tolerance is all around us today.
It's also the thing that probably enables most of your favorite meme kinds because Byzantine fault tolerance is used in things like blockchain.
It's also used in a lot of systems where you need sort of absolute assurance.
So things like maybe I'm I'm going to have something which affects human human life.
I don't want a singular sort of to rely on a single point of failure. I want to have multiple points of failure.
But I want multiple kind of I want to be able to achieve consensus on that.
Lampart crooks. I mean one of the kind of core patterns that we use in distributed systems now is a venting.
And the kind of the the ability to have a lamp or clock which is very low impact on the system.
The ability very fast to calculate very very simple and has a low message overhead is still used in inventing based systems.
You can obviously go a little bit more complex. You can use back to clocks.
You can even use things like lamp or clocks and effect the clocks with Byzantine consensus.
But all of these things got up Byzantine fault tolerance lamp or clocks concurrency consensus.
They are the thing which empower the systems that we're building and using today.
And it really does fascinate me that a lot of these core concepts come back from those kind of core papers that were written in the 70s.
But the kind of the the concepts of which which were no idea of the kind of things that they would be applied in today.
Still all true and are still relevant.
And we we kind of want to thanks somebody for that to me.
Yeah, I mean it brings us back to the original question which was fuzzy lamp or a man who has written so many papers that the scroll and never on his thing just released a book by the way everyone should read it.
I printed it out and also was a man at his time would get into fights with newspapers and things like that who would call him.
Maybe a little I don't know what the like politically correct term here is just so that he's just having a little bit too much fun with his papers and people would call them hard to read and maybe just like an interesting fun guy.
So was he right and the answer I've come to and probably have said for like way too long it's yeah he was right.
We have and come across these problems all the time in technology and he found them in the 1970s.
But on top of that he made these papers fun and interesting even though everyone hates Paxos and they think it's over complicated and they rather choose raft.
Like he was right to teach things like the part time parliament which is the original paper of Paxos in a fun consumable way that isn't hugely technical and full of like algebraic expressions.
So just to say thank you so much for listening I hope you all can run away and and go and find a bunch of reading on on Leslie Lampot and some of his work because it is revolutionary use an absolute pioneer of the industry and a fascinating individual.
Do we have time for questions.
And here's some references but there's a ton more you should go check out his website your exit Microsoft it's the Azure Slabs website sick.
But if anyone has questions you can raise your hand and I'll sprint up to you and if not you can walk down here.