Blockchain - Sicherheit auch ohne Trust Center

1. 00:00Now when we talk about linked timestamps, then it's about us trying to make it to record the order of messages.
2. 00:09Maybe to review what happened, what have we discussed so far?
3. 00:15We discussed consistency models, we have discussed error models,
4. 00:18we have a relatively simple consensus algorithm, who is based on the counting of votes
5. 00:26and the establishment of a majority of votes, the democratic consensus algorithm.
6. 00:30We dealt with how Sybil attacks, so pretences can be fended off by other participants,
7. 00:39had seen there that the proof of work is a remedy, to find out and differentiate between real participants and fake participants.
8. 00:48And we have a system where we already have without the existence of a trust center,
9. 00:56that the generals, these Byzantine generals. can really agree on a command,
10. 01:02that in a distributed network really the systems, the systems involved can agree on common data, on consistency.
11. 01:14What's missing is that we can determine the chronological sequence of the individual commands in the previous scenario.
12. 01:25But when we think of an application in the financial sector, for example, so transfer systems, then of course it is quite essential to know, in what order were transfers and money receipts made there.
13. 01:40So the question is, how can we make sure that we will not only achieve consistency, but that we will also to record the chronological order of the individual commands without a doubt.
14. 01:56And there it helps and is an approach, if you trust a central timestamp service.
15. 02:06So there's a service provider that just keeps sending the individual message with her transmission time, which no one will question, because the trust in this central timestamp server is given,
16. 02:24Well, it's one of those timestamp services, who has in our picture with the Byzantine generals, there were different orders,
17. 02:35Attack, there was retreat, attack, retreat, and this order is important, and by the timestamp service each message is provided with such a time stamp.
18. 02:48The question of this timestamp service is of course is also important in many other contexts.
19. 02:56So when it comes to how to prove an identity, also prove when a message or document was created or a message was posted.
20. 03:08There's techniques, there's lots of papers, this is also a very important part of trust systems.
21. 03:15Let's have a look at the way we're gonna do this now. in such a distributed system.
22. 03:20There we have the situation of the many different participants, and the question is how can we link these messages together? without using a central timestamp service.
23. 03:41And the idea is again, with the help of cryptographic methods we can establish that trust, namely through a hash chain.
24. 03:52So hash values, hash functions, we already have I've talked about it several times in this class, too,
25. 03:59we had a close look at the last price, how this works (unv. #00:04:07-7# )
26. 04:06and which is now simply done when an attack is given, then this attack, the hash value, is calculated.
27. 04:15And if the next order comes now, this command calculates the hash value again,
28. 04:22and the hash value of the first command and the hash value of the second command, which are processed to a new hash value.
29. 04:32So here is no longer solvable in this value, what's the order, but it's when you know the order, it's easy to calculate that the attack was before that attack.
30. 04:45So, and so it continues now, now comes the next value, the hash value is calculated from this command,
31. 04:51is connected to a new hash value, that has been using this previous command history in a hash value with this new command,
32. 05:01and in this way, these individual commands will be are welded together in their chronological order.
33. 05:12Welded by the mechanism, that they calculate a hash value.
34. 05:17The crucial thing with the hash function was yes, that it won't translate back,
35. 05:22but that you can check again and again in this way, what was the order without any possibility, to intervene now by falsifying.
36. 05:32Because a fake would be to use different hash values, which can then no longer be confirmed.
37. 05:43The whole model now depends on here in front, what does the head of this chain look like?
38. 05:53If the head of this chain, if all over it agree, then there's nothing left to shake here,
39. 06:01then these hash values are exactly the order of the different commands, given in the various places in the network, which is then traceable.
40. 06:13So we have a trusted timestamp service, we are not dependent on a trust authority that always stamps that,
41. 06:23but through this concatenation we can ensure that the order, the chronological sequence of the messages is recorded.
42. 06:35What's important is the head of the linked list, which must be generally accepted by all participants, because that's how the rest of the chain comes out.
43. 06:48Here one has considered oneself, that must be published naturally, everyone needs to have access to these distributed systems.
44. 06:55How can you do that?
45. 06:57And that's where the idea came from, in a newspaper, in print media, the head of such an episode on a weekly basis, of such a timestamp sequence.
46. 07:09Here for example for the first time 95 in the New York Times or in the Guardian, New York Times was that message,
47. 07:16where this hash value for a particular blockchain, because this is then used within this block chain, as a chronological definition of the sequence of commands.

To enable the transcript, please select a language in the video player settings menu.