Module 1 → Lesson 8 → Part 2 of 8
Проблема двойного расходования
Lesson contents
- Почему вообще появилась идея криптовалют
- Проблема двойного расходования
- Почему обычным цифровым деньгам нужен доверенный центр
- Первые попытки создать цифровые деньги
- Cypherpunks: деньги, приватность и свобода от посредника
- Hashcash, b-money и Bit Gold: идеи, из которых вырос Bitcoin
- Bitcoin: что именно удалось соединить в работающую систему
- Итоги: какую проблему на самом деле решали криптовалюты
What you'll learn
Одни и те же деньги нельзя потратить дважды
В предыдущей части мы увидели главную проблему цифровых денег: цифровые данные можно копировать.
Но настоящая проблема глубже.
Допустим, Emma имеет 100 цифровых единиц.
Она создает две операции: операцию A — «Emma → Alex: 100» — и почти одновременно операцию B — «Emma → Sofia: 100».
Каждая операция сама по себе выглядит нормально.
Но выполнить обе нельзя.
У Emma было только 100, а потратить она пытается 200.
Это и есть проблема двойного расходования.
- 1У Emma есть 100 единиц — этой суммы хватает ровно на одну операцию.
- 2Операция A пытается отправить эти 100 единиц Alex.
- 3Операция B почти одновременно пытается отправить те же 100 единиц Sofia — обе действительными быть не могут.
Определение
Проще: одни и те же деньги пытаются одновременно прожить две финансовые жизни.
Для денежной системы такой талант совершенно лишний.
С наличными проблема решается физикой
У Emma есть одна банкнота 100 €.
Она передает ее Alex.
После этого банкнота находится у Alex.
До передачи: у Emma 100 €, у Alex 0 €.
После передачи: у Emma 0 €, у Alex 100 €.
Чтобы передать ту же самую физическую банкноту Sofia, Emma сначала должна снова ее получить.
Физический объект не может одновременно лежать в двух кошельках.
По крайней мере без очень интересной физики, которой платежные системы пока не пользуются.
У цифровых данных такого ограничения нет
Допустим, денежная единица представлена обычными данными.
Emma может отправить их Alex, а затем ту же копию — Sofia.
Alex получает корректный файл.
Sofia получает точно такой же корректный файл.
Теперь возникает вопрос: кто настоящий владелец?
Файл сам этого не знает.
Подлинность не решает проблему
Предположим, мы используем цифровую подпись.
Emma действительно подписала обе операции своим настоящим ключом: «Emma → Alex: 100» — подпись корректна, и «Emma → Sofia: 100» — подпись тоже корректна.
Подделки нет.
Злоумышленник не украл ключ.
Обе операции действительно создала Emma.
Но денег на обе операции все равно недостаточно.
Очень важное различие
Цифровая подпись отвечает на вопрос: кто разрешил эту операцию?
Но double spending требует ответить еще и на другой: были ли эти средства уже использованы раньше?
Это уже вопрос не только криптографии.
Это вопрос состояния системы и истории операций.
Нужно знать, что произошло раньше
Представим, что Emma получила 100.
Дальше существуют две версии событий.
Версия 1: в 10:00 — «Emma → Alex: 100», в 10:01 — «Emma → Sofia: 100». Тогда первая операция может быть действительной, а вторая — уже нет.
Версия 2: в 10:00 — «Emma → Sofia: 100», в 10:01 — «Emma → Alex: 100». Теперь ситуация обратная.
Значит, для цифровой денежной системы важны не только сами операции.
Важен их порядок.
А если операции произошли почти одновременно?
Вот здесь становится интереснее.
Emma отправляет Alex 100 в 12:00:00.
И практически одновременно отправляет Sofia 100.
Но сеть не обязана доставить информацию всем участникам в одинаковом порядке.
Например, узел A первым увидел «Emma → Alex», а узел B первым увидел «Emma → Sofia».
Оба узла пока действуют честно.
Они просто получили информацию в разном порядке.
- 1Узел A первым получил операцию «Emma → Alex» и считает первой именно ее.
- 2Узел B первым получил операцию «Emma → Sofia» и считает первой ее — сеть должна согласовать один общий порядок конфликтующих операций.
Сеть не имеет единого «сейчас»
Это важное свойство распределенных систем.
В обычной жизни нам кажется, что события происходят в одном общем порядке: сначала A, потом B, потом C.
Но в компьютерной сети информация распространяется не мгновенно.
У разных участников некоторое время может быть разная картина происходящего.
Пример
Есть четыре участника сети: Node A, Node B, Node C, Node D.
Emma отправляет две конфликтующие операции.
Через несколько секунд ситуация может выглядеть так: Node A видит, что Alex получил 100; Node B видит, что Sofia получила 100; Node C видит, что Alex получил 100; Node D еще не видел ни одной операции.
Так какую историю считать правильной?
Именно это необходимо решить системе.
Центральный банк или обычный банк решает это просто
Если существует один официальный оператор, через которого проходит операция и который ведет официальный учет, банк может сказать: операция Alex была зарегистрирована первой.
После этого баланс Emma становится 0.
И операция Sofia отклоняется.
Один реестр — один ответ
У централизованной системы есть очень мощное свойство: существует один официальный источник текущего состояния.
Например, баланс Emma равен 0.
Если другая копия данных говорит, что баланс Emma равен 100, она просто считается неактуальной или неправильной.
Но мы хотим попробовать без центрального оператора
Теперь убираем банк.
Получается сеть из независимых узлов A, B, C, D, связанных между собой.
Каждый участник может иметь копию истории.
Возникает новая задача: как сделать так, чтобы в итоге все честные участники пришли к одной версии истории?
Не обязательно мгновенно.
Но система должна уметь прийти к согласованному состоянию.
Double spending — это не просто «скопировали монету»
Это полезно понять точно.
Иногда проблему объясняют так: «кто-то скопировал цифровую монету».
Для первого знакомства это допустимо.
Но технически точнее говорить: участник пытается создать две несовместимые операции, каждая из которых претендует на использование одной и той же стоимости.
То есть проблема находится в конфликте операций, а не обязательно в существовании двух одинаковых файлов.
Банковский пример
У Emma 500 €.
Она создает платеж A — «500 € → Alex» — и платеж B — «500 € → Sofia».
Банковская система принимает A.
После этого баланс Emma становится 0 €.
Теперь B не соответствует текущему состоянию.
Он должен быть отклонен.
В распределенной системе нужно добиться того же результата
Система без центрального банка тоже должна в итоге сказать: A принято, B отклонено — или наоборот: B принято, A отклонено.
Но не «A принято, B принято», если на обе операции средств не хватало.
Значит, система должна определять порядок
Это один из ключевых элементов решения.
Если операции конфликтуют, сеть должна каким-то образом определить: какая операция вошла в признанную историю раньше?
Затем следующие операции проверяются уже относительно обновленного состояния.
Но нельзя просто доверять времени на компьютере
Можно подумать: «пусть победит операция с более ранним временем».
Проблема в том, что часы разных компьютеров могут немного отличаться, быть неправильно настроены или намеренно подделываться.
Например, у операции «Emma → Alex» timestamp 12:00:01, а у операции «Emma → Sofia» timestamp 11:59:58.
Кто гарантирует, что второй timestamp действительно отражает реальный порядок?
Никто — если мы просто поверили часам отправителя.
Значит, нужен общий механизм упорядочивания
Распределенная денежная система должна каким-то образом договориться: какие операции допустимы; в каком порядке они учитываются; какая история считается основной; какие конфликтующие операции отклоняются.
Именно здесь проблема double spending превращается в проблему консенсуса.
Напомним консенсус
Мы уже встречали этот термин.
Для цифровых денег это означает: сеть должна прийти к общему мнению о том, какие операции формируют действительную историю.
А если часть участников обманывает?
Еще сложнее.
Представим, что некоторые участники намеренно пытаются убедить сеть, что правильная операция — Alex, а другие — что правильная операция Sofia.
Распределенная система должна работать не только тогда, когда все идеально честны.
Она должна учитывать возможность ошибок, отключений, задержек и злонамеренного поведения.
Поэтому просто «раздать всем копию реестра» недостаточно
Можно создать тысячу копий базы данных.
Но если они начинают расходиться — копия 1 говорит про Alex, копия 2 про Sofia, копия 3 про Alex, копия 4 вообще пока не определилась — само количество копий проблему не решает.
Нужно правило: каким образом эти копии снова придут к одному состоянию.
Децентрализация начинается не с количества компьютеров
Это важный вывод.
Тысяча серверов, которыми полностью управляет одна компания, — это технически распределенная инфраструктура.
Но управление остается централизованным.
И наоборот, сеть независимых участников должна иметь правила согласования, иначе вместо децентрализации получится просто очень дорогой спор между компьютерами.
Что должна уметь система цифровых денег
Чтобы противостоять double spending, системе нужно как минимум пять вещей.
Проверить право на операцию: есть ли у отправителя необходимое право распоряжаться средствами?
Проверить наличие средств: существуют ли эти средства в текущем состоянии?
Проверить историю: не были ли они уже использованы?
Упорядочить конфликтующие операции: какая операция учитывается первой?
Согласовать результат: как независимые участники приходят к одной версии состояния?
- 1Право распоряжения — у отправителя есть право распоряжаться этими средствами.
- 2Наличие средств — эти средства существуют в текущем состоянии системы.
- 3История операций — эти средства еще не были использованы раньше.
- 4Порядок — при конфликте определено, какая операция учитывается первой.
- 5Согласование — независимые участники приходят к одной версии состояния.
- 6Финальность — результат операции считается окончательным по правилам системы.
И здесь появляется еще одна проблема
Допустим, сеть согласилась: «Emma → Alex: 100».
Но насколько окончательным является это решение?
Может ли через минуту история измениться?
Через час?
Через день?
Это вопрос финальности транзакции.
Мы подробно разберем его позже.
Сейчас достаточно понимать: не всякое появление операции в сети автоматически означает ее абсолютную окончательность.
Финальность
Разные платежные и блокчейн-системы достигают финальности по-разному.
Пока нам важен только сам вопрос.
Почему double spending настолько фундаментален
Если его не решить, пользователь не может быть уверен, что полученные деньги действительно принадлежат ему.
Представим магазин.
Alex продает ноутбук за 1 000 цифровых единиц.
Он видит перевод и отдает товар.
Через несколько минут сеть принимает другую историю: эти же 1 000 были отправлены Sofia.
Alex отдал ноутбук, но не получил окончательных денег.
Такая денежная система долго не проживет.
Поэтому получатель должен понимать окончательность платежа
В банковском мире мы уже видели похожий принцип: «отправлено» не всегда равно «окончательно зачислено».
В криптовалютных системах это станет еще важнее.
Например, позже мы увидим подтверждения, блоки, глубину транзакции, разные модели финальности.
Но всему свое время.
Главное, что нужно запомнить
- Double spending — попытка использовать одну и ту же цифровую стоимость больше одного раза.
- Физические деньги естественным образом ограничены физическим владением, а цифровые данные легко копируются и передаются нескольким получателям.
- Цифровая подпись подтверждает автора операции, но сама не доказывает, что средства еще не были потрачены.
- Для предотвращения двойного расходования необходимо учитывать историю операций.
- Порядок конфликтующих операций имеет значение.
- В распределенной сети разные участники могут сначала увидеть разные операции.
- Поэтому системе нужен механизм согласования единой действительной истории.
- Просто создать много копий реестра недостаточно — нужно определить, как они приходят к общему состоянию.
- Double spending тесно связан с задачей консенсуса.
- Получателю важно знать не только, что транзакция появилась, но и насколько ее результат уже считается окончательным.
Что дальше
Мы увидели два возможных подхода.
Первый очень простой: есть один официальный оператор, и он определяет правильную историю.
Второй значительно сложнее: центрального оператора нет, и участники должны согласовать историю сами.
Поэтому долгое время электронные деньги строились вокруг доверенного центра.
И это было вполне рациональное решение.
Следующий вопрос: почему обычным цифровым деньгам практически всегда был нужен центральный оператор — и что именно он делал такого, что оказалось так трудно заменить?
Об этом — в следующей части — «Почему обычным цифровым деньгам нужен доверенный центр».
- Double spending — попытка использовать одну и ту же цифровую стоимость больше одного раза.
- Физические деньги естественным образом ограничены физическим владением, а цифровые данные легко копируются и передаются нескольким получателям.
- Цифровая подпись подтверждает автора операции, но сама не доказывает, что средства еще не были потрачены.
- Для предотвращения двойного расходования необходимо учитывать историю операций.
- Порядок конфликтующих операций имеет значение.
- В распределенной сети разные участники могут сначала увидеть разные операции.
- Поэтому системе нужен механизм согласования единой действительной истории.
- Просто создать много копий реестра недостаточно — нужно определить, как они приходят к общему состоянию.
- Double spending тесно связан с задачей консенсуса.
- Получателю важно знать не только, что транзакция появилась, но и насколько ее результат уже считается окончательным.
The same money cannot be spent twice
In the previous part we saw the main problem with digital money: digital data can be copied.
But the real problem runs deeper.
Suppose Emma has 100 digital units.
She creates two operations: operation A — «Emma → Alex: 100» — and, almost simultaneously, operation B — «Emma → Sofia: 100».
Each operation on its own looks fine.
But both of them cannot be carried out.
Emma had only 100, yet she is trying to spend 200.
This is exactly the double-spending problem.
- 1Emma has 100 units — this amount is enough for exactly one operation.
- 2Operation A tries to send those 100 units to Alex.
- 3Operation B, almost simultaneously, tries to send the same 100 units to Sofia — both cannot be valid.
Definition
Put more simply: the same money tries to live two financial lives at once.
For a monetary system, this talent is entirely unwanted.
With cash the problem is solved by physics
Emma has a single €100 banknote.
She hands it to Alex.
After that, the banknote is with Alex.
Before the transfer: Emma has €100, Alex has €0.
After the transfer: Emma has €0, Alex has €100.
To hand the same physical banknote to Sofia, Emma first has to get it back.
A physical object cannot lie in two wallets at the same time.
At least not without some very interesting physics that payment systems do not yet make use of.
Digital data has no such limitation
Suppose a monetary unit is represented as ordinary data.
Emma can send it to Alex, and then send the same copy to Sofia.
Alex receives a valid file.
Sofia receives exactly the same valid file.
Now a question arises: who is the real owner?
The file itself does not know.
Authenticity does not solve the problem
Suppose we use a digital signature.
Emma really did sign both operations with her genuine key: «Emma → Alex: 100» — the signature is valid, and «Emma → Sofia: 100» — the signature is valid too.
There is no forgery.
No attacker stole the key.
Emma genuinely created both operations.
But there is still not enough money for both operations.
A very important distinction
A digital signature answers the question: who authorized this operation?
But double spending also requires answering another one: had these funds already been used before?
That is no longer only a matter of cryptography.
It is a matter of the system's state and the history of operations.
You need to know what happened earlier
Imagine that Emma received 100.
From there, two versions of events are possible.
Version 1: at 10:00 — «Emma → Alex: 100», at 10:01 — «Emma → Sofia: 100». Then the first operation can be valid, and the second one no longer is.
Version 2: at 10:00 — «Emma → Sofia: 100», at 10:01 — «Emma → Alex: 100». Now the situation is reversed.
So, for a digital monetary system, the operations themselves are not all that matters.
Their order matters.
And what if the operations happened almost simultaneously?
This is where it gets more interesting.
Emma sends Alex 100 at 12:00:00.
And practically at the same moment she sends Sofia 100.
But the network is not obliged to deliver the information to all participants in the same order.
For example, node A saw «Emma → Alex» first, while node B saw «Emma → Sofia» first.
Both nodes are still acting honestly.
They simply received the information in a different order.
- 1Node A received the operation «Emma → Alex» first and considers it to be the first one.
- 2Node B received the operation «Emma → Sofia» first and considers it to be the first one — the network must agree on a single common order for conflicting operations.
The network has no single "now"
This is an important property of distributed systems.
In everyday life it seems to us that events happen in one common order: first A, then B, then C.
But in a computer network information does not spread instantaneously.
For some time, different participants may have a different picture of what is happening.
An example
There are four network participants: Node A, Node B, Node C, Node D.
Emma sends two conflicting operations.
A few seconds later the situation may look like this: Node A sees that Alex received 100; Node B sees that Sofia received 100; Node C sees that Alex received 100; Node D has not yet seen a single operation.
So which history should be considered correct?
That is exactly what the system has to decide.
A central bank or an ordinary bank solves this easily
If there is one official operator through whom the operation passes and who keeps the official records, the bank can say: Alex's operation was registered first.
After that, Emma's balance becomes 0.
And Sofia's operation is rejected.
One registry — one answer
A centralized system has a very powerful property: there is one official source of the current state.
For example, Emma's balance is 0.
If another copy of the data says that Emma's balance is 100, it is simply treated as out of date or incorrect.
But we want to try without a central operator
Now we remove the bank.
What we get is a network of independent nodes A, B, C, D, connected to one another.
Each participant can hold a copy of the history.
A new task arises: how do we make it so that, in the end, all honest participants arrive at one version of the history?
Not necessarily instantly.
But the system must be able to reach an agreed state.
Double spending is not simply "someone copied a coin"
This is worth getting exactly right.
Sometimes the problem is explained like this: "someone copied a digital coin".
For a first introduction that is acceptable.
But it is technically more accurate to say: a participant is trying to create two incompatible operations, each of which claims the use of one and the same value.
That is, the problem lies in the conflict between operations, and not necessarily in the existence of two identical files.
A banking example
Emma has €500.
She creates payment A — «€500 → Alex» — and payment B — «€500 → Sofia».
The banking system accepts A.
After that, Emma's balance becomes €0.
Now B does not match the current state.
It has to be rejected.
In a distributed system the same result must be achieved
A system without a central bank must also, in the end, say: A accepted, B rejected — or the other way around: B accepted, A rejected.
But not "A accepted, B accepted", if there were not enough funds for both operations.
So the system must determine the order
This is one of the key elements of the solution.
If operations conflict, the network must somehow determine: which operation entered the recognized history earlier?
Subsequent operations are then checked against the updated state.
But you cannot simply trust the time on a computer
You might think: "let the operation with the earlier time win".
The problem is that the clocks of different computers can differ slightly, be misconfigured, or be deliberately falsified.
For example, the operation «Emma → Alex» has a timestamp of 12:00:01, while the operation «Emma → Sofia» has a timestamp of 11:59:58.
Who guarantees that the second timestamp really reflects the actual order?
No one — if we simply trusted the sender's clock.
So a common ordering mechanism is needed
A distributed monetary system must somehow agree on: which operations are permissible; in what order they are recorded; which history is considered the main one; which conflicting operations are rejected.
This is exactly where the double-spending problem turns into a consensus problem.
A reminder about consensus
We have already come across this term.
For digital money this means: the network must reach a common view of which operations form the valid history.
And what if some participants cheat?
That is even harder.
Imagine that some participants deliberately try to convince the network that the correct operation is Alex's, and others that the correct operation is Sofia's.
A distributed system must work not only when everyone is perfectly honest.
It must account for the possibility of errors, outages, delays, and malicious behavior.
That is why simply "handing everyone a copy of the registry" is not enough
You can create a thousand copies of the database.
But if they start to diverge — copy 1 says Alex, copy 2 says Sofia, copy 3 says Alex, copy 4 has not decided yet — the sheer number of copies does not solve the problem.
A rule is needed: how these copies will come back to a single state.
Decentralization does not begin with the number of computers
This is an important conclusion.
A thousand servers fully controlled by a single company is technically distributed infrastructure.
But control remains centralized.
And conversely, a network of independent participants must have rules for reaching agreement, otherwise, instead of decentralization, you get simply a very expensive argument between computers.
What a digital money system must be able to do
To withstand double spending, a system needs at least five things.
Check the right to the operation: does the sender have the necessary right to dispose of the funds?
Check that the funds exist: do these funds exist in the current state?
Check the history: have they already been used?
Order conflicting operations: which operation is recorded first?
Agree on the result: how do independent participants arrive at one version of the state?
- 1Right of disposal — the sender has the right to dispose of these funds.
- 2Existence of funds — these funds exist in the current state of the system.
- 3History of operations — these funds have not been used before.
- 4Order — in a conflict, it is determined which operation is recorded first.
- 5Agreement — independent participants arrive at one version of the state.
- 6Finality — the result of the operation is considered final under the system's rules.
And here another problem appears
Suppose the network has agreed: «Emma → Alex: 100».
But how final is that decision?
Could the history change a minute later?
An hour later?
A day later?
This is a question of transaction finality.
We will examine it in detail later.
For now it is enough to understand: not every appearance of an operation in the network automatically means its absolute finality.
Finality
Different payment and blockchain systems achieve finality in different ways.
For now, only the question itself matters to us.
Why double spending is so fundamental
If it is not solved, a user cannot be sure that the money they received really belongs to them.
Imagine a shop.
Alex sells a laptop for 1,000 digital units.
He sees the transfer and hands over the goods.
A few minutes later the network accepts a different history: those same 1,000 were sent to Sofia.
Alex gave away the laptop but did not receive final money.
A monetary system like that will not last long.
That is why the recipient must understand the finality of a payment
In the banking world we have already seen a similar principle: "sent" does not always equal "finally credited".
In cryptocurrency systems this will become even more important.
For example, later we will see confirmations, blocks, transaction depth, and different models of finality.
But everything in its own time.
The main things to remember
- Double spending is an attempt to use one and the same digital value more than once.
- Physical money is naturally limited by physical possession, whereas digital data is easily copied and sent to several recipients.
- A digital signature confirms the author of an operation, but does not by itself prove that the funds have not yet been spent.
- To prevent double spending, the history of operations must be taken into account.
- The order of conflicting operations matters.
- In a distributed network, different participants may initially see different operations.
- That is why the system needs a mechanism for agreeing on a single valid history.
- Simply creating many copies of the registry is not enough — you have to define how they arrive at a common state.
- Double spending is closely tied to the consensus problem.
- It matters to the recipient to know not only that a transaction has appeared, but also how far its result is already considered final.
What comes next
We have seen two possible approaches.
The first is very simple: there is one official operator, and it determines the correct history.
The second is significantly harder: there is no central operator, and the participants have to agree on the history themselves.
That is why, for a long time, electronic money was built around a trusted center.
And that was a perfectly rational choice.
The next question: why did ordinary digital money almost always need a central operator — and what exactly did it do that turned out to be so hard to replace?
That is the subject of the next part — "Why ordinary digital money needs a trusted center".
- Double spending is an attempt to use the same digital value more than once.
- Physical money is naturally limited by physical possession, whereas digital data is easily copied and sent to several recipients.
- A digital signature confirms who authored an operation, but doesn't prove the funds haven't already been spent.
- Preventing double-spending requires taking the history of operations into account.
- The order of conflicting operations matters.
- In a distributed network, different participants may see different operations first.
- So the system needs a mechanism for agreeing on a single valid history.
- Simply making many copies of the ledger isn't enough — you have to define how they arrive at a shared state.
- Double spending is closely tied to the consensus problem.
- The recipient needs to know not only that a transaction has appeared, but how final its result is already considered to be.
Τα ίδια χρήματα δεν μπορούν να ξοδευτούν δύο φορές
Στο προηγούμενο μέρος είδαμε το κύριο πρόβλημα των ψηφιακών χρημάτων: τα ψηφιακά δεδομένα μπορούν να αντιγραφούν.
Όμως το πραγματικό πρόβλημα είναι βαθύτερο.
Ας υποθέσουμε ότι η Emma έχει 100 ψηφιακές μονάδες.
Δημιουργεί δύο πράξεις: την πράξη A — «Emma → Alex: 100» — και σχεδόν ταυτόχρονα την πράξη B — «Emma → Sofia: 100».
Κάθε πράξη από μόνη της φαίνεται φυσιολογική.
Όμως δεν είναι δυνατόν να εκτελεστούν και οι δύο.
Η Emma είχε μόνο 100, ενώ προσπαθεί να ξοδέψει 200.
Αυτό ακριβώς είναι το πρόβλημα της διπλής δαπάνης.
- 1Η Emma έχει 100 μονάδες — αυτό το ποσό επαρκεί ακριβώς για μία πράξη.
- 2Η πράξη A προσπαθεί να στείλει αυτές τις 100 μονάδες στον Alex.
- 3Η πράξη B σχεδόν ταυτόχρονα προσπαθεί να στείλει τις ίδιες 100 μονάδες στη Sofia — δεν μπορούν να είναι έγκυρες και οι δύο.
Ορισμός
Πιο απλά: τα ίδια χρήματα προσπαθούν να ζήσουν ταυτόχρονα δύο οικονομικές ζωές.
Για ένα νομισματικό σύστημα αυτό το ταλέντο είναι εντελώς περιττό.
Με τα μετρητά το πρόβλημα λύνεται από τη φυσική
Η Emma έχει ένα χαρτονόμισμα 100 €.
Το δίνει στον Alex.
Μετά από αυτό το χαρτονόμισμα βρίσκεται στον Alex.
Πριν από τη μεταβίβαση: η Emma έχει 100 €, ο Alex έχει 0 €.
Μετά τη μεταβίβαση: η Emma έχει 0 €, ο Alex έχει 100 €.
Για να μεταβιβάσει το ίδιο φυσικό χαρτονόμισμα στη Sofia, η Emma πρέπει πρώτα να το αποκτήσει ξανά.
Ένα φυσικό αντικείμενο δεν μπορεί να βρίσκεται ταυτόχρονα σε δύο πορτοφόλια.
Τουλάχιστον όχι χωρίς μια πολύ ενδιαφέρουσα φυσική, την οποία τα συστήματα πληρωμών δεν χρησιμοποιούν ακόμη.
Τα ψηφιακά δεδομένα δεν έχουν τέτοιον περιορισμό
Ας υποθέσουμε ότι μια νομισματική μονάδα αναπαρίσταται από συνηθισμένα δεδομένα.
Η Emma μπορεί να τα στείλει στον Alex και έπειτα το ίδιο αντίγραφο στη Sofia.
Ο Alex λαμβάνει ένα σωστό αρχείο.
Η Sofia λαμβάνει ακριβώς το ίδιο σωστό αρχείο.
Τώρα προκύπτει το ερώτημα: ποιος είναι ο πραγματικός ιδιοκτήτης;
Το ίδιο το αρχείο δεν το γνωρίζει.
Η γνησιότητα δεν λύνει το πρόβλημα
Ας υποθέσουμε ότι χρησιμοποιούμε ψηφιακή υπογραφή.
Η Emma υπέγραψε πράγματι και τις δύο πράξεις με το πραγματικό της κλειδί: «Emma → Alex: 100» — η υπογραφή είναι σωστή, και «Emma → Sofia: 100» — η υπογραφή είναι επίσης σωστή.
Δεν υπάρχει πλαστογραφία.
Κανένας κακόβουλος δράστης δεν έκλεψε το κλειδί.
Και τις δύο πράξεις τις δημιούργησε πράγματι η Emma.
Όμως τα χρήματα και πάλι δεν επαρκούν για τις δύο πράξεις.
Μια πολύ σημαντική διάκριση
Η ψηφιακή υπογραφή απαντά στο ερώτημα: ποιος ενέκρινε αυτή την πράξη;
Όμως το double spending απαιτεί να απαντηθεί και ένα άλλο: έχουν ήδη χρησιμοποιηθεί αυτά τα κεφάλαια νωρίτερα;
Αυτό δεν είναι πλέον ζήτημα μόνο κρυπτογραφίας.
Είναι ζήτημα της κατάστασης του συστήματος και του ιστορικού των πράξεων.
Πρέπει να ξέρουμε τι συνέβη νωρίτερα
Ας φανταστούμε ότι η Emma έλαβε 100.
Στη συνέχεια υπάρχουν δύο εκδοχές των γεγονότων.
Εκδοχή 1: στις 10:00 — «Emma → Alex: 100», στις 10:01 — «Emma → Sofia: 100». Τότε η πρώτη πράξη μπορεί να είναι έγκυρη, ενώ η δεύτερη όχι πλέον.
Εκδοχή 2: στις 10:00 — «Emma → Sofia: 100», στις 10:01 — «Emma → Alex: 100». Τώρα η κατάσταση είναι αντίστροφη.
Άρα, για ένα ψηφιακό νομισματικό σύστημα δεν έχουν σημασία μόνο οι ίδιες οι πράξεις.
Έχει σημασία η σειρά τους.
Και αν οι πράξεις έγιναν σχεδόν ταυτόχρονα;
Εδώ τα πράγματα γίνονται πιο ενδιαφέροντα.
Η Emma στέλνει στον Alex 100 στις 12:00:00.
Και σχεδόν ταυτόχρονα στέλνει στη Sofia 100.
Όμως το δίκτυο δεν είναι υποχρεωμένο να παραδώσει την πληροφορία σε όλους τους συμμετέχοντες με την ίδια σειρά.
Για παράδειγμα, ο κόμβος A είδε πρώτος την «Emma → Alex», ενώ ο κόμβος B είδε πρώτος την «Emma → Sofia».
Και οι δύο κόμβοι ενεργούν προς το παρόν έντιμα.
Απλώς έλαβαν την πληροφορία με διαφορετική σειρά.
- 1Ο κόμβος A έλαβε πρώτος την πράξη «Emma → Alex» και θεωρεί πρώτη ακριβώς αυτήν.
- 2Ο κόμβος B έλαβε πρώτος την πράξη «Emma → Sofia» και θεωρεί πρώτη αυτήν — το δίκτυο πρέπει να συμφωνήσει σε μία κοινή σειρά των συγκρουόμενων πράξεων.
Το δίκτυο δεν έχει ένα ενιαίο «τώρα»
Αυτή είναι μια σημαντική ιδιότητα των κατανεμημένων συστημάτων.
Στην καθημερινή ζωή μας φαίνεται ότι τα γεγονότα συμβαίνουν με μία κοινή σειρά: πρώτα A, μετά B, μετά C.
Όμως σε ένα δίκτυο υπολογιστών η πληροφορία δεν διαδίδεται ακαριαία.
Διαφορετικοί συμμετέχοντες μπορεί για κάποιο διάστημα να έχουν διαφορετική εικόνα των όσων συμβαίνουν.
Παράδειγμα
Υπάρχουν τέσσερις συμμετέχοντες στο δίκτυο: Node A, Node B, Node C, Node D.
Η Emma στέλνει δύο συγκρουόμενες πράξεις.
Μετά από μερικά δευτερόλεπτα η κατάσταση μπορεί να μοιάζει έτσι: ο Node A βλέπει ότι ο Alex έλαβε 100· ο Node B βλέπει ότι η Sofia έλαβε 100· ο Node C βλέπει ότι ο Alex έλαβε 100· ο Node D δεν έχει δει ακόμη καμία πράξη.
Ποιο ιστορικό, λοιπόν, πρέπει να θεωρηθεί σωστό;
Ακριβώς αυτό πρέπει να αποφασίσει το σύστημα.
Μια κεντρική τράπεζα ή μια συνηθισμένη τράπεζα το λύνει απλά
Αν υπάρχει ένας επίσημος φορέας, μέσα από τον οποίο περνά η πράξη και ο οποίος τηρεί το επίσημο μητρώο, η τράπεζα μπορεί να πει: η πράξη προς τον Alex καταχωρίστηκε πρώτη.
Μετά από αυτό το υπόλοιπο της Emma γίνεται 0.
Και η πράξη προς τη Sofia απορρίπτεται.
Ένα μητρώο — μία απάντηση
Ένα κεντρικό σύστημα έχει μια πολύ ισχυρή ιδιότητα: υπάρχει μία επίσημη πηγή της τρέχουσας κατάστασης.
Για παράδειγμα, το υπόλοιπο της Emma είναι 0.
Αν κάποιο άλλο αντίγραφο δεδομένων λέει ότι το υπόλοιπο της Emma είναι 100, θεωρείται απλώς παρωχημένο ή λανθασμένο.
Όμως θέλουμε να δοκιμάσουμε χωρίς κεντρικό φορέα
Τώρα αφαιρούμε την τράπεζα.
Προκύπτει ένα δίκτυο από ανεξάρτητους κόμβους A, B, C, D, συνδεδεμένους μεταξύ τους.
Κάθε συμμετέχων μπορεί να έχει ένα αντίγραφο του ιστορικού.
Προκύπτει ένα νέο πρόβλημα: πώς να γίνει ώστε τελικά όλοι οι έντιμοι συμμετέχοντες να καταλήξουν σε μία εκδοχή του ιστορικού;
Όχι απαραίτητα ακαριαία.
Όμως το σύστημα πρέπει να μπορεί να φτάσει σε μια συμφωνημένη κατάσταση.
Το double spending δεν είναι απλώς «αντέγραψαν ένα νόμισμα»
Αυτό είναι χρήσιμο να το κατανοήσουμε με ακρίβεια.
Μερικές φορές το πρόβλημα εξηγείται έτσι: «κάποιος αντέγραψε ένα ψηφιακό νόμισμα».
Για μια πρώτη γνωριμία αυτό είναι αποδεκτό.
Όμως τεχνικά είναι ακριβέστερο να λέμε: ένας συμμετέχων προσπαθεί να δημιουργήσει δύο ασύμβατες πράξεις, καθεμία από τις οποίες διεκδικεί τη χρήση της ίδιας αξίας.
Δηλαδή το πρόβλημα βρίσκεται στη σύγκρουση των πράξεων και όχι απαραίτητα στην ύπαρξη δύο πανομοιότυπων αρχείων.
Τραπεζικό παράδειγμα
Η Emma έχει 500 €.
Δημιουργεί την πληρωμή A — «500 € → Alex» — και την πληρωμή B — «500 € → Sofia».
Το τραπεζικό σύστημα αποδέχεται την A.
Μετά από αυτό το υπόλοιπο της Emma γίνεται 0 €.
Τώρα η B δεν αντιστοιχεί στην τρέχουσα κατάσταση.
Πρέπει να απορριφθεί.
Σε ένα κατανεμημένο σύστημα πρέπει να επιτευχθεί το ίδιο αποτέλεσμα
Ένα σύστημα χωρίς κεντρική τράπεζα πρέπει επίσης τελικά να πει: η A έγινε δεκτή, η B απορρίφθηκε — ή αντίστροφα: η B έγινε δεκτή, η A απορρίφθηκε.
Όχι όμως «η A έγινε δεκτή, η B έγινε δεκτή», αν τα κεφάλαια δεν επαρκούσαν και για τις δύο πράξεις.
Άρα, το σύστημα πρέπει να καθορίζει τη σειρά
Αυτό είναι ένα από τα βασικά στοιχεία της λύσης.
Αν οι πράξεις συγκρούονται, το δίκτυο πρέπει με κάποιον τρόπο να καθορίσει: ποια πράξη μπήκε νωρίτερα στο αναγνωρισμένο ιστορικό;
Έπειτα οι επόμενες πράξεις ελέγχονται πλέον ως προς την ενημερωμένη κατάσταση.
Όμως δεν μπορούμε απλώς να εμπιστευόμαστε την ώρα του υπολογιστή
Θα μπορούσε κανείς να σκεφτεί: «ας κερδίσει η πράξη με την πιο πρώιμη ώρα».
Το πρόβλημα είναι ότι τα ρολόγια διαφορετικών υπολογιστών μπορεί να διαφέρουν λίγο, να είναι ρυθμισμένα λανθασμένα ή να παραποιούνται σκόπιμα.
Για παράδειγμα, η πράξη «Emma → Alex» έχει timestamp 12:00:01, ενώ η πράξη «Emma → Sofia» έχει timestamp 11:59:58.
Ποιος εγγυάται ότι το δεύτερο timestamp αντικατοπτρίζει πράγματι την πραγματική σειρά;
Κανείς — αν απλώς εμπιστευτήκαμε το ρολόι του αποστολέα.
Άρα, χρειάζεται ένας κοινός μηχανισμός ταξινόμησης
Ένα κατανεμημένο νομισματικό σύστημα πρέπει με κάποιον τρόπο να συμφωνήσει: ποιες πράξεις είναι επιτρεπτές· με ποια σειρά καταχωρούνται· ποιο ιστορικό θεωρείται το κύριο· ποιες συγκρουόμενες πράξεις απορρίπτονται.
Ακριβώς εδώ το πρόβλημα του double spending μετατρέπεται σε πρόβλημα συναίνεσης.
Ας θυμηθούμε τη συναίνεση
Έχουμε ήδη συναντήσει αυτόν τον όρο.
Για τα ψηφιακά χρήματα αυτό σημαίνει: το δίκτυο πρέπει να καταλήξει σε μια κοινή άποψη για το ποιες πράξεις σχηματίζουν το έγκυρο ιστορικό.
Και αν ένα μέρος των συμμετεχόντων εξαπατά;
Ακόμη πιο πολύπλοκο.
Ας φανταστούμε ότι κάποιοι συμμετέχοντες προσπαθούν σκόπιμα να πείσουν το δίκτυο ότι η σωστή πράξη είναι αυτή προς τον Alex, ενώ άλλοι ότι η σωστή πράξη είναι αυτή προς τη Sofia.
Ένα κατανεμημένο σύστημα πρέπει να λειτουργεί όχι μόνο όταν όλοι είναι απόλυτα έντιμοι.
Πρέπει να λαμβάνει υπόψη την πιθανότητα σφαλμάτων, αποσυνδέσεων, καθυστερήσεων και κακόβουλης συμπεριφοράς.
Γι' αυτό το να «μοιράσουμε σε όλους ένα αντίγραφο του μητρώου» δεν αρκεί
Μπορούμε να δημιουργήσουμε χίλια αντίγραφα της βάσης δεδομένων.
Όμως αν αρχίσουν να αποκλίνουν — το αντίγραφο 1 λέει για τον Alex, το αντίγραφο 2 για τη Sofia, το αντίγραφο 3 για τον Alex, το αντίγραφο 4 δεν έχει καν αποφασίσει ακόμη — ο ίδιος ο αριθμός των αντιγράφων δεν λύνει το πρόβλημα.
Χρειάζεται ένας κανόνας: με ποιον τρόπο αυτά τα αντίγραφα θα καταλήξουν ξανά σε μία κατάσταση.
Η αποκέντρωση δεν ξεκινά από τον αριθμό των υπολογιστών
Αυτό είναι ένα σημαντικό συμπέρασμα.
Χίλιοι διακομιστές, τους οποίους διαχειρίζεται πλήρως μία εταιρεία, αποτελούν τεχνικά μια κατανεμημένη υποδομή.
Όμως η διαχείριση παραμένει κεντρική.
Και αντίστροφα, ένα δίκτυο ανεξάρτητων συμμετεχόντων πρέπει να έχει κανόνες συμφωνίας, αλλιώς αντί για αποκέντρωση θα προκύψει απλώς μια πολύ ακριβή διαμάχη μεταξύ υπολογιστών.
Τι πρέπει να μπορεί να κάνει ένα σύστημα ψηφιακών χρημάτων
Για να αντιμετωπίσει το double spending, το σύστημα χρειάζεται τουλάχιστον πέντε πράγματα.
Έλεγχος του δικαιώματος για την πράξη: έχει ο αποστολέας το απαραίτητο δικαίωμα να διαθέτει τα κεφάλαια;
Έλεγχος της ύπαρξης των κεφαλαίων: υπάρχουν αυτά τα κεφάλαια στην τρέχουσα κατάσταση;
Έλεγχος του ιστορικού: μήπως έχουν ήδη χρησιμοποιηθεί;
Ταξινόμηση των συγκρουόμενων πράξεων: ποια πράξη καταχωρείται πρώτη;
Συμφωνία για το αποτέλεσμα: πώς καταλήγουν οι ανεξάρτητοι συμμετέχοντες σε μία εκδοχή της κατάστασης;
- 1Δικαίωμα διάθεσης — ο αποστολέας έχει το δικαίωμα να διαθέτει αυτά τα κεφάλαια.
- 2Ύπαρξη κεφαλαίων — αυτά τα κεφάλαια υπάρχουν στην τρέχουσα κατάσταση του συστήματος.
- 3Ιστορικό πράξεων — αυτά τα κεφάλαια δεν έχουν χρησιμοποιηθεί ξανά νωρίτερα.
- 4Σειρά — σε περίπτωση σύγκρουσης είναι καθορισμένο ποια πράξη καταχωρείται πρώτη.
- 5Συμφωνία — οι ανεξάρτητοι συμμετέχοντες καταλήγουν σε μία εκδοχή της κατάστασης.
- 6Οριστικότητα — το αποτέλεσμα της πράξης θεωρείται οριστικό σύμφωνα με τους κανόνες του συστήματος.
Και εδώ εμφανίζεται ακόμη ένα πρόβλημα
Ας υποθέσουμε ότι το δίκτυο συμφώνησε: «Emma → Alex: 100».
Όμως πόσο οριστική είναι αυτή η απόφαση;
Μπορεί σε ένα λεπτό το ιστορικό να αλλάξει;
Σε μία ώρα;
Σε μία μέρα;
Αυτό είναι ζήτημα οριστικότητας συναλλαγής.
Θα το αναλύσουμε λεπτομερώς αργότερα.
Προς το παρόν αρκεί να καταλάβουμε: δεν σημαίνει κάθε εμφάνιση μιας πράξης στο δίκτυο αυτόματα την απόλυτη οριστικότητά της.
Οριστικότητα
Διαφορετικά συστήματα πληρωμών και blockchain επιτυγχάνουν την οριστικότητα με διαφορετικούς τρόπους.
Προς το παρόν μας ενδιαφέρει μόνο το ίδιο το ερώτημα.
Γιατί το double spending είναι τόσο θεμελιώδες
Αν δεν λυθεί, ο χρήστης δεν μπορεί να είναι σίγουρος ότι τα χρήματα που έλαβε του ανήκουν πραγματικά.
Ας φανταστούμε ένα κατάστημα.
Ο Alex πουλά έναν φορητό υπολογιστή για 1.000 ψηφιακές μονάδες.
Βλέπει τη μεταφορά και παραδίδει το προϊόν.
Μετά από μερικά λεπτά το δίκτυο αποδέχεται ένα άλλο ιστορικό: τα ίδια αυτά 1.000 στάλθηκαν στη Sofia.
Ο Alex παρέδωσε τον φορητό υπολογιστή, αλλά δεν έλαβε οριστικά χρήματα.
Ένα τέτοιο νομισματικό σύστημα δεν θα επιβιώσει για πολύ.
Γι' αυτό ο παραλήπτης πρέπει να κατανοεί την οριστικότητα της πληρωμής
Στον τραπεζικό κόσμο έχουμε ήδη δει μια παρόμοια αρχή: το «στάλθηκε» δεν ισοδυναμεί πάντα με το «πιστώθηκε οριστικά».
Στα συστήματα κρυπτονομισμάτων αυτό θα γίνει ακόμη πιο σημαντικό.
Για παράδειγμα, αργότερα θα δούμε επιβεβαιώσεις, μπλοκ, βάθος συναλλαγής, διαφορετικά μοντέλα οριστικότητας.
Όμως όλα στην ώρα τους.
Το βασικό που πρέπει να θυμάστε
- Double spending — η προσπάθεια χρήσης της ίδιας ψηφιακής αξίας περισσότερες από μία φορές.
- Τα φυσικά χρήματα περιορίζονται με φυσικό τρόπο από τη φυσική κατοχή, ενώ τα ψηφιακά δεδομένα αντιγράφονται εύκολα και μεταβιβάζονται σε πολλούς παραλήπτες.
- Η ψηφιακή υπογραφή επιβεβαιώνει τον δημιουργό της πράξης, αλλά από μόνη της δεν αποδεικνύει ότι τα κεφάλαια δεν έχουν ακόμη ξοδευτεί.
- Για την αποτροπή της διπλής δαπάνης είναι απαραίτητο να λαμβάνεται υπόψη το ιστορικό των πράξεων.
- Η σειρά των συγκρουόμενων πράξεων έχει σημασία.
- Σε ένα κατανεμημένο δίκτυο διαφορετικοί συμμετέχοντες μπορεί αρχικά να δουν διαφορετικές πράξεις.
- Γι' αυτό το σύστημα χρειάζεται έναν μηχανισμό συμφωνίας για ένα ενιαίο έγκυρο ιστορικό.
- Το να δημιουργήσουμε απλώς πολλά αντίγραφα του μητρώου δεν αρκεί — πρέπει να καθοριστεί πώς καταλήγουν σε μια κοινή κατάσταση.
- Το double spending συνδέεται στενά με το πρόβλημα της συναίνεσης.
- Για τον παραλήπτη είναι σημαντικό να γνωρίζει όχι μόνο ότι η συναλλαγή εμφανίστηκε, αλλά και κατά πόσο το αποτέλεσμά της θεωρείται ήδη οριστικό.
Τι ακολουθεί
Είδαμε δύο πιθανές προσεγγίσεις.
Η πρώτη είναι πολύ απλή: υπάρχει ένας επίσημος φορέας και αυτός καθορίζει το σωστό ιστορικό.
Η δεύτερη είναι σημαντικά πιο πολύπλοκη: δεν υπάρχει κεντρικός φορέας και οι συμμετέχοντες πρέπει να συμφωνήσουν για το ιστορικό μόνοι τους.
Γι' αυτό για πολύ καιρό τα ηλεκτρονικά χρήματα χτίζονταν γύρω από ένα έμπιστο κέντρο.
Και αυτή ήταν μια απολύτως λογική λύση.
Το επόμενο ερώτημα: γιατί τα συνηθισμένα ψηφιακά χρήματα χρειάζονταν σχεδόν πάντα έναν κεντρικό φορέα — και τι ακριβώς έκανε αυτός που αποδείχθηκε τόσο δύσκολο να αντικατασταθεί;
Γι' αυτό — στο επόμενο μέρος — «Γιατί τα συνηθισμένα ψηφιακά χρήματα χρειάζονται ένα έμπιστο κέντρο».
- Το double spending είναι μια προσπάθεια χρήσης της ίδιας ψηφιακής αξίας περισσότερες από μία φορές.
- Το φυσικό χρήμα περιορίζεται φυσικά από τη φυσική κατοχή, ενώ τα ψηφιακά δεδομένα αντιγράφονται εύκολα και αποστέλλονται σε πολλούς παραλήπτες.
- Μια ψηφιακή υπογραφή επιβεβαιώνει ποιος δημιούργησε μια συναλλαγή, αλλά δεν αποδεικνύει ότι τα κεφάλαια δεν έχουν ήδη ξοδευτεί.
- Η αποτροπή της διπλής δαπάνης απαιτεί να λαμβάνεται υπόψη το ιστορικό των συναλλαγών.
- Η σειρά των αντικρουόμενων συναλλαγών έχει σημασία.
- Σε ένα κατανεμημένο δίκτυο, διαφορετικοί συμμετέχοντες μπορεί να δουν πρώτα διαφορετικές συναλλαγές.
- Έτσι το σύστημα χρειάζεται έναν μηχανισμό για τη συμφωνία ενός ενιαίου έγκυρου ιστορικού.
- Το να δημιουργήσεις απλώς πολλά αντίγραφα του μητρώου δεν αρκεί — πρέπει να οριστεί πώς καταλήγουν σε μια κοινή κατάσταση.
- Το double spending συνδέεται στενά με το πρόβλημα της συναίνεσης.
- Ο παραλήπτης πρέπει να γνωρίζει όχι μόνο ότι μια συναλλαγή έχει εμφανιστεί, αλλά και πόσο οριστικό θεωρείται ήδη το αποτέλεσμά της.