Module 1 → Lesson 7 → Part 6 of 8
Единые точки доверия и отказа
Lesson contents
- Почему обычная финансовая система работает не идеально
- Зависимость от банков и других посредников
- Почему платежи могут быть медленными и дорогими
- Границы, валюты и международные переводы
- Блокировки, ограничения и контроль доступа к деньгам
- Единые точки доверия и отказа
- Что цифровизация банков решила — и чего не решила
- Итоги: какие проблемы подготовили почву для криптовалют
What you'll learn
А что будет, если банк просто перестанет работать?
Представим обычное утро.
Emma Lee открывает банковское приложение.
Не работает.
Пробует сайт.
Не работает.
Карта тоже не проходит.
При этом: деньги со счета никуда не исчезли; Emma не потеряла пароль; интернет работает; магазин готов принять оплату.
Но воспользоваться деньгами через этот канал пока нельзя.
Почему?
Потому что между Emma и ее банковским счетом находится инфраструктура банка.
Деньги могут существовать, а доступ — нет
Это важное различие.
У Emma по-прежнему может быть финансовое требование к банку: 5 000 €.
Но возможность выполнить операцию зависит от работоспособности: приложений; систем аутентификации; банковских баз данных; платежных шлюзов; сетевой инфраструктуры; внешних платежных систем.
То есть цифровые деньги зависят не только от правильного учета.
Они зависят еще и от доступности инфраструктуры.
Единая точка отказа
Простейший пример: пользователь обращается к единственному серверу, а тот уже обслуживает всю финансовую систему.
Если сервер остановился — все.
Система ждет, пока сервер вернется к жизни.
Но современный банк — не один компьютер
Здесь важно не создать карикатуру.
Крупная финансовая инфраструктура обычно строится совсем не так.
Используются: дублирование компонентов; кластеризация; резервные каналы связи; резервные центры обработки данных; резервные копии; процедуры восстановления.
Поэтому централизованная система совершенно не обязана иметь единственный физический сервер.
Это принципиально важно.
- 1Упрощенная (неверная) модель — пользователь обращается к единственному серверу, который и есть вся финансовая система.
- 2Реальная модель начинается с одного оператора, который определяет правила и полномочия.
- 3Оператор использует несколько площадок, географически распределенных.
- 4На каждой площадке работает несколько систем, а не один компьютер.
- 5Все это подкреплено резервированием — данные и мощности дублируются на случай отказа.
Централизация и единая точка отказа — не одно и то же
Система может быть централизована организационно и при этом очень хорошо распределена технически.
Например, один банк может использовать десятки площадок и тысячи серверов.
Но правила учета и полномочия все равно принадлежат одной организации.
Получается: технически — много систем и площадок, организационно — один оператор.
Эти вещи нельзя путать.
Что тогда значит «единая точка доверия»?
Рассмотрим другой вопрос.
Emma не знает, на каком именно сервере находится запись о ее 5 000 €.
И ей это не нужно.
Она доверяет организации: Банку A.
Именно банк определяет официальное состояние своего учета.
Если в приложении Emma 5 000 €, а в базе банка 4 500 €, то финансовую реальность нельзя установить голосованием между телефоном Emma и сервером банка.
Источник учетной записи — банковская система.
Центральный авторитет
Для банковского счета эту роль обычно выполняет банк.
Он: ведет записи; проверяет операции; применяет правила; исправляет ошибки; фиксирует результат.
Пользователь доверяет не отдельному серверу.
Он доверяет оператору системы.
И это очень удобно
Представим ошибку.
Система дважды списала 100 € за одну операцию.
Emma обращается в банк.
Банк может: проверить историю; установить причину; сделать корректирующую запись; восстановить правильный баланс.
Почему это возможно?
Потому что существует организация, имеющая полномочия определить, какое состояние учета является правильным.
Это одно из сильнейших преимуществ централизованной системы.
Но именно здесь появляется зависимость
Если весь официальный учет контролирует один оператор, пользователям приходится доверять, что он: не потеряет данные; корректно применяет правила; защищает систему; способен восстановиться после аварии; не допустит несанкционированных изменений; исполнит законные обязательства.
То есть появляется концентрация доверия.
Что может отказать
Проблема необязательно выглядит как «сломался сервер».
Отказ может происходить на разных уровнях.
Технический — например: сбой базы данных; отказ сети; ошибка программного обеспечения; повреждение оборудования.
Кибернетический — например: атака; компрометация учетных записей; ransomware; нарушение целостности данных.
Операционный — например: ошибочное обновление; неправильная конфигурация; человеческая ошибка.
Организационный — например: критическая ошибка самого оператора; прекращение работы сервиса; серьезный финансовый кризис организации.
Одна финансовая функция зависит сразу от нескольких видов устойчивости.
- 1Без резервирования — компонент отказывает, и сервис останавливается полностью.
- 2С резервированием — компонент отказывает, но failover переключает нагрузку, и сервис продолжает работу.
- 3С backup — авария происходит, но восстановление возвращает систему к корректному состоянию.
Коротко о терминах
High availability — архитектура, рассчитанная на продолжение работы при отказе отдельных компонентов.
Failover — переключение на резервный компонент или систему.
Backup — резервная копия данных.
Disaster recovery — процедуры восстановления после серьезного сбоя или аварии.
Не нужно запоминать все английские слова сейчас.
Главная мысль проще: надежная система заранее предполагает, что что-нибудь когда-нибудь сломается.
Компьютеры очень дисциплинированно подтверждают это правило.
Резервная копия и работающая резервная система — не одно и то же
Представим банк, который делает backup каждый день.
Отлично.
Но если основная система остановилась, наличие backup еще не означает мгновенное продолжение работы.
Нужно: восстановить данные; запустить инфраструктуру; проверить их целостность; определить правильную точку восстановления.
Поэтому backup — это не то же самое, что high availability.
Backup помогает восстановиться.
High availability помогает не останавливаться или сократить остановку.
В финансовой системе особенно важна точность восстановления
Для обычного сайта после аварии потеря нескольких последних просмотров страницы неприятна, но обычно не катастрофична.
Для банковского учета ситуация другая.
Перед сбоем у Sofia Martin было 7 430 €.
После восстановления нельзя получить 7 210 € с объяснением «примерно так и было».
Финансовый учет требует восстановления корректного состояния и истории операций.
Поэтому нужен не только backup, но и журнал событий
Система должна понимать: какие операции завершились; какие только начались; какие были подтверждены; какие изменения уже попали в учет.
Иначе после восстановления может возникнуть опасная ситуация: платеж уже выполнен, но система считает, что он еще не выполнялся.
А затем повторяет его.
Мы уже знаем, чем это может закончиться: двойным платежом.
Доступность — часть финансовой безопасности
Когда говорят о кибербезопасности банков, легко подумать только о краже данных.
Но безопасность включает как минимум три фундаментальных свойства.
Конфиденциальность — данные не получают посторонние.
Целостность — данные нельзя незаметно или неправомерно изменить.
Доступность — законный пользователь может получить доступ к необходимой функции тогда, когда она ему нужна.
Если банковская система идеально защищает записи, но не работает неделю, это тоже серьезная проблема безопасности.
Централизация облегчает защиту — и концентрирует последствия
Одна организация может: установить единые требования; централизованно обновлять системы; контролировать администраторов; проводить аудит; управлять резервированием.
Это преимущество.
Но если критическая ошибка затрагивает центральную инфраструктуру, последствия способны затронуть сразу очень много пользователей.
Знакомый компромисс: централизация позволяет проще единообразно управлять, но ошибка центрального уровня может иметь широкий эффект.
А можно ли убрать центральную точку?
Представим другую архитектуру.
Вместо одного официального экземпляра реестра есть несколько независимых участников, каждый из которых хранит информацию о состоянии системы.
Если один из узлов исчезнет, остальные могут продолжить работу.
На первый взгляд прекрасно.
Но появляется новая проблема.
Кто из них прав?
Допустим, один узел говорит: «Emma отправила Alex 100».
Другой узел говорит: «Emma эти 100 не отправляла».
Третий узел вообще временно недоступен.
Как определить правильную историю?
В централизованной системе ответ был: официальная база оператора.
В распределенной системе нужно создать механизм, позволяющий независимым участникам согласовать состояние.
И здесь появляется слово «консенсус»
Пока этого определения достаточно.
Подробно механизмы консенсуса мы будем разбирать позже.
- 1Централизованный реестр — клиенты обращаются к оператору, а тот ведет единственный официальный реестр; правильное состояние определяется без голосования.
- 2Распределенный реестр — независимые узлы хранят копии состояния и должны согласовать общую версию через консенсус.
Убрать центр — значит получить новые задачи
Если отказаться от центрального оператора, необходимо решить: кто хранит данные; кто принимает новые операции; как проверяется их корректность; как определяется порядок операций; что происходит, если участники не согласны; что делать с недоступными или злонамеренными участниками.
Центр исчез.
Проблемы не исчезли.
Они сменили форму.
Распределенная система тоже может зависеть от централизованных компонентов
Это особенно важно для будущего понимания криптовалют.
Допустим, сам блокчейн децентрализован.
Но пользователь работает через централизованную биржу, а уже она обращается к блокчейну.
Если биржа недоступна, пользователь может потерять доступ к операции через нее, хотя сам блокчейн продолжает работать.
Или: кошелек обращается к одному RPC-провайдеру, а тот уже обращается к блокчейну.
Блокчейн работает.
Но приложение не получает данные из-за отказа конкретного сервиса.
Поэтому слово «децентрализованный» нужно использовать аккуратно
Нельзя посмотреть на систему и сказать: «Там blockchain, значит единых точек отказа нет».
Нужно исследовать всю цепочку: протокол; узлы; кошелек; RPC; биржу; smart contract; bridge; эмитента актива; пользовательское устройство.
Централизация может исчезнуть в одном месте и появиться в другом.
Главное, что нужно запомнить
- Цифровые деньги зависят от доступности технологической инфраструктуры.
- Единая точка отказа — компонент, отказ которого может остановить критически важную функцию.
- Централизованная система не обязательно построена на одном сервере.
- Один оператор может использовать множество географически распределенных и резервируемых систем.
- Централизация означает прежде всего концентрацию полномочий и доверия, а не обязательно физическую концентрацию оборудования.
- Резервирование, failover, backups и disaster recovery решают разные задачи устойчивости.
- Для финансовой системы важно восстановить не приблизительное, а точное и согласованное состояние учета.
- Если центральный оператор убирается, возникает задача согласования состояния между независимыми участниками.
- Для этого распределенным системам необходим механизм консенсуса.
- Децентрализованный протокол не гарантирует отсутствия централизованных компонентов вокруг него.
- При анализе любой финансовой системы полезно спрашивать: где находятся реальные точки доверия и отказа?
Что дальше
Банковская система за последние десятилетия стала: мобильной; круглосуточной; автоматизированной; гораздо быстрее; намного удобнее.
Некоторые проблемы, которые раньше действительно были серьезными, современные платежные технологии уже существенно уменьшили.
Поэтому возникает важный вопрос: а нужны ли вообще новые денежные архитектуры, если банковские приложения уже работают за секунды?
Чтобы ответить честно, нужно отделить две вещи: что цифровизация банков уже решила и что осталось фундаментальным свойством самой архитектуры.
Об этом — в следующей части — «Что цифровизация банков решила — и чего не решила».
- Цифровые деньги зависят от доступности технологической инфраструктуры.
- Единая точка отказа — компонент, отказ которого может остановить критически важную функцию.
- Централизованная система не обязательно построена на одном сервере.
- Один оператор может использовать множество географически распределенных и резервируемых систем.
- Централизация означает прежде всего концентрацию полномочий и доверия, а не обязательно физическую концентрацию оборудования.
- Резервирование, failover, backups и disaster recovery решают разные задачи устойчивости.
- Для финансовой системы важно восстановить не приблизительное, а точное и согласованное состояние учета.
- Если центральный оператор убирается, возникает задача согласования состояния между независимыми участниками.
- Для этого распределенным системам необходим механизм консенсуса.
- Децентрализованный протокол не гарантирует отсутствия централизованных компонентов вокруг него.
- При анализе любой финансовой системы полезно спрашивать: где находятся реальные точки доверия и отказа?
And what happens if the bank simply stops working?
Imagine an ordinary morning.
Emma Lee opens her banking app.
It doesn't work.
She tries the website.
It doesn't work.
Her card doesn't go through either.
Meanwhile: the money in the account hasn't disappeared anywhere; Emma hasn't lost her password; the internet is working; the store is ready to accept payment.
But she can't use the money through this channel right now.
Why?
Because between Emma and her bank account stands the bank's infrastructure.
Money can exist while access does not
This is an important distinction.
Emma may still have a financial claim on the bank: €5,000.
But the ability to carry out an operation depends on the availability of: the apps; the authentication systems; the bank's databases; the payment gateways; the network infrastructure; the external payment systems.
In other words, digital money doesn't depend only on correct accounting.
It also depends on the availability of infrastructure.
Single point of failure
The simplest example: a user reaches out to a single server, and that server already serves the entire financial system.
If the server goes down — that's it.
The system waits for the server to come back to life.
But a modern bank isn't one computer
Here it's important not to draw a caricature.
Large financial infrastructure is usually built quite differently.
It uses: component duplication; clustering; backup communication channels; backup data centers; backup copies; recovery procedures.
So a centralized system is by no means required to have a single physical server.
This is fundamentally important.
- 1The simplified (incorrect) model — a user reaches a single server, which is the entire financial system.
- 2The real model starts with a single operator who defines the rules and authority.
- 3The operator uses several geographically distributed sites.
- 4Each site runs multiple systems, not a single computer.
- 5All of this is backed by redundancy — data and capacity are duplicated in case of failure.
Centralization and a single point of failure are not the same thing
A system can be centralized organizationally while being very well distributed technically.
For example, a single bank might use dozens of sites and thousands of servers.
But the accounting rules and authority still belong to one organization.
The result: technically — many systems and sites; organizationally — one operator.
These two things must not be confused.
So what does "a single point of trust" mean?
Let's consider another question.
Emma doesn't know which exact server holds the record of her €5,000.
And she doesn't need to.
She trusts the organization: Bank A.
It's the bank that determines the official state of its own records.
If Emma's app shows €5,000, but the bank's database shows €4,500, financial reality cannot be established by a vote between Emma's phone and the bank's server.
The source of the account record is the bank's system.
Central authority
For a bank account, this role is usually played by the bank.
It: keeps the records; verifies operations; enforces the rules; corrects errors; finalizes the result.
The user doesn't trust an individual server.
They trust the operator of the system.
And this is very convenient
Imagine an error.
The system charged €100 twice for a single operation.
Emma contacts the bank.
The bank can: check the history; establish the cause; make a corrective entry; restore the correct balance.
Why is this possible?
Because there exists an organization with the authority to determine which state of the record is correct.
This is one of the strongest advantages of a centralized system.
But this is exactly where dependency appears
If a single operator controls the entire official record, users have to trust that it: will not lose data; correctly applies the rules; protects the system; is able to recover after a disaster; will not allow unauthorized changes; will fulfill its legal obligations.
In other words, a concentration of trust appears.
What can fail
The problem doesn't necessarily look like "the server broke."
Failure can occur at different levels.
Technical — for example: a database failure; a network outage; a software bug; hardware damage.
Cyber — for example: an attack; compromised accounts; ransomware; a breach of data integrity.
Operational — for example: a faulty update; a misconfiguration; human error.
Organizational — for example: a critical mistake by the operator itself; discontinuation of the service; a serious financial crisis at the organization.
A single financial function depends on several kinds of resilience at once.
- 1Without redundancy — a component fails, and the service stops completely.
- 2With redundancy — a component fails, but failover shifts the load, and the service keeps running.
- 3With backup — a disaster occurs, but recovery brings the system back to a correct state.
A brief note on terms
High availability — an architecture designed to keep running when individual components fail.
Failover — switching to a backup component or system.
Backup — a copy of the data kept in reserve.
Disaster recovery — procedures for recovering after a serious failure or disaster.
There's no need to memorize all these English terms right now.
The main idea is simpler: a reliable system assumes in advance that something will eventually break.
Computers confirm this rule with great discipline.
A backup copy and a working backup system are not the same thing
Imagine a bank that makes a backup every day.
Excellent.
But if the main system goes down, having a backup doesn't by itself mean an instant continuation of service.
It's necessary to: restore the data; bring the infrastructure back online; verify its integrity; determine the correct recovery point.
So a backup is not the same thing as high availability.
A backup helps you recover.
High availability helps you avoid stopping, or shortens the stoppage.
In a financial system, the precision of recovery matters especially
For an ordinary website, losing the last few page views after a crash is unpleasant, but usually not catastrophic.
For bank accounting, the situation is different.
Before the failure, Sofia Martin had €7,430.
After recovery, she cannot end up with €7,210 and an explanation of "that's roughly what it was."
Financial accounting requires restoring the exact, correct state and history of operations.
That's why you need not just a backup, but an event log too
The system must understand: which operations completed; which only started; which were confirmed; which changes already made it into the records.
Otherwise, after recovery a dangerous situation can arise: a payment has already been made, but the system thinks it hasn't happened yet.
And then it repeats it.
We already know how that can end: a double payment.
Availability is part of financial security
When people talk about bank cybersecurity, it's easy to think only about data theft.
But security includes at least three fundamental properties.
Confidentiality — outsiders don't get the data.
Integrity — the data cannot be altered unnoticed or without authorization.
Availability — the legitimate user can access the function they need when they need it.
If a banking system protects its records perfectly but doesn't work for a week, that too is a serious security problem.
Centralization makes protection easier — and concentrates the consequences
A single organization can: set unified requirements; update systems centrally; control administrators; conduct audits; manage redundancy.
This is an advantage.
But if a critical failure affects the central infrastructure, the consequences can reach a great many users at once.
A familiar trade-off: centralization makes uniform management simpler, but an error at the central level can have a wide-reaching effect.
Can the central point be removed?
Let's imagine a different architecture.
Instead of a single official copy of the ledger, there are several independent participants, each holding information about the state of the system.
If one of the nodes disappears, the others can keep working.
At first glance, wonderful.
But a new problem appears.
Which one of them is right?
Suppose one node says: "Emma sent Alex 100."
Another node says: "Emma didn't send that 100."
A third node is temporarily unavailable altogether.
How do you determine the correct history?
In a centralized system, the answer was: the operator's official database.
In a distributed system, a mechanism is needed that lets independent participants agree on the state.
And this is where the word "consensus" comes in
For now, this definition is enough.
We'll go through consensus mechanisms in detail later.
- 1Centralized registry — clients contact the operator, who maintains the single official registry; the correct state is determined without any voting.
- 2Distributed registry — independent nodes hold copies of the state and must agree on a common version through consensus.
Removing the center means taking on new problems
If you give up a central operator, you have to decide: who stores the data; who accepts new operations; how their correctness is verified; how the order of operations is determined; what happens if participants disagree; what to do about unavailable or malicious participants.
The center is gone.
The problems haven't gone anywhere.
They've changed shape.
A distributed system can also depend on centralized components
This is especially important for understanding cryptocurrencies later on.
Suppose the blockchain itself is decentralized.
But the user operates through a centralized exchange, and it's the exchange that talks to the blockchain.
If the exchange is unavailable, the user may lose access to the operation through it, even though the blockchain itself keeps running.
Or: a wallet talks to a single RPC provider, and that provider talks to the blockchain.
The blockchain is working.
But the app isn't getting data, because of the failure of one particular service.
That's why the word "decentralized" needs to be used carefully
You can't just look at a system and say, "There's a blockchain, so there are no single points of failure."
You need to examine the whole chain: the protocol; the nodes; the wallet; the RPC; the exchange; the smart contract; the bridge; the asset issuer; the user's device.
Centralization can disappear in one place and reappear in another.
The main things to remember
- Digital money depends on the availability of technological infrastructure.
- A single point of failure is a component whose failure can stop a critically important function.
- A centralized system isn't necessarily built on a single server.
- A single operator can use many geographically distributed and redundant systems.
- Centralization means, above all, a concentration of authority and trust — not necessarily a physical concentration of hardware.
- Redundancy, failover, backups, and disaster recovery each solve different resilience problems.
- For a financial system, it matters to restore not an approximate but an exact and consistent state of the records.
- If the central operator is removed, the task of reconciling state among independent participants arises.
- For that, distributed systems need a consensus mechanism.
- A decentralized protocol doesn't guarantee the absence of centralized components around it.
- When analyzing any financial system, it's useful to ask: where are the real points of trust and failure?
What's next
Over the last few decades, the banking system has become: mobile; available around the clock; automated; much faster; far more convenient.
Some problems that used to be genuinely serious have already been substantially reduced by modern payment technology.
So an important question arises: are new monetary architectures even needed, if banking apps already work in seconds?
To answer honestly, two things need to be separated: what the digitization of banks has already solved, and what remains a fundamental property of the architecture itself.
That's the subject of the next part — "What the Digitization of Banks Has Solved — and What It Hasn't."
- Digital money depends on the availability of technological infrastructure.
- A single point of failure is a component whose failure can stop a critical function.
- A centralized system isn't necessarily built on a single server.
- One operator can use many geographically distributed, redundant systems.
- Centralization means, first and foremost, a concentration of authority and trust — not necessarily a physical concentration of hardware.
- Redundancy, failover, backups, and disaster recovery solve different resilience problems.
- For a financial system, what matters is restoring an exact, consistent record state — not an approximate one.
- Removing the central operator creates the problem of reconciling state among independent participants.
- Distributed systems need a consensus mechanism to do this.
- A decentralized protocol doesn't guarantee the absence of centralized components around it.
- When analyzing any financial system, it's useful to ask: where are the real points of trust and failure?
Και τι θα γίνει αν η τράπεζα απλώς σταματήσει να λειτουργεί;
Ας φανταστούμε ένα συνηθισμένο πρωινό.
Η Emma Lee ανοίγει την τραπεζική εφαρμογή.
Δεν λειτουργεί.
Δοκιμάζει την ιστοσελίδα.
Δεν λειτουργεί.
Ούτε η κάρτα περνάει.
Παρ' όλα αυτά: τα χρήματα από τον λογαριασμό δεν εξαφανίστηκαν πουθενά· η Emma δεν έχασε τον κωδικό της· το ίντερνετ λειτουργεί· το κατάστημα είναι έτοιμο να δεχτεί την πληρωμή.
Όμως δεν μπορεί προς το παρόν να χρησιμοποιήσει τα χρήματα μέσω αυτού του καναλιού.
Γιατί;
Επειδή ανάμεσα στην Emma και τον τραπεζικό της λογαριασμό βρίσκεται η υποδομή της τράπεζας.
Τα χρήματα μπορεί να υπάρχουν, αλλά η πρόσβαση όχι
Αυτή είναι μια σημαντική διάκριση.
Η Emma μπορεί να εξακολουθεί να έχει μια χρηματική απαίτηση έναντι της τράπεζας: 5.000 €.
Όμως η δυνατότητα εκτέλεσης της συναλλαγής εξαρτάται από τη λειτουργικότητα: των εφαρμογών· των συστημάτων ταυτοποίησης· των τραπεζικών βάσεων δεδομένων· των πυλών πληρωμών· της δικτυακής υποδομής· των εξωτερικών συστημάτων πληρωμών.
Δηλαδή τα ψηφιακά χρήματα δεν εξαρτώνται μόνο από τη σωστή λογιστική καταγραφή.
Εξαρτώνται επίσης και από τη διαθεσιμότητα της υποδομής.
Ενιαίο σημείο αστοχίας
Το απλούστερο παράδειγμα: ο χρήστης απευθύνεται σε έναν και μοναδικό διακομιστή, ο οποίος με τη σειρά του εξυπηρετεί ολόκληρο το χρηματοπιστωτικό σύστημα.
Αν ο διακομιστής σταματήσει — τέλος.
Το σύστημα περιμένει μέχρι ο διακομιστής να επανέλθει σε λειτουργία.
Όμως η σύγχρονη τράπεζα δεν είναι ένας υπολογιστής
Εδώ είναι σημαντικό να μη δημιουργήσουμε μια καρικατούρα.
Η μεγάλη χρηματοπιστωτική υποδομή συνήθως δεν χτίζεται καθόλου έτσι.
Χρησιμοποιούνται: διπλασιασμός στοιχείων· ομαδοποίηση (clustering)· εφεδρικά κανάλια επικοινωνίας· εφεδρικά κέντρα δεδομένων· αντίγραφα ασφαλείας· διαδικασίες αποκατάστασης.
Επομένως ένα κεντρικοποιημένο σύστημα δεν είναι καθόλου υποχρεωμένο να διαθέτει έναν και μοναδικό φυσικό διακομιστή.
Αυτό έχει θεμελιώδη σημασία.
- 1Απλοποιημένο (εσφαλμένο) μοντέλο — ο χρήστης απευθύνεται σε έναν και μοναδικό διακομιστή, ο οποίος αποτελεί ολόκληρο το χρηματοπιστωτικό σύστημα.
- 2Το πραγματικό μοντέλο ξεκινά με έναν φορέα λειτουργίας, ο οποίος καθορίζει τους κανόνες και τις εξουσίες.
- 3Ο φορέας χρησιμοποιεί πολλαπλές εγκαταστάσεις, γεωγραφικά κατανεμημένες.
- 4Σε κάθε εγκατάσταση λειτουργούν πολλαπλά συστήματα, όχι ένας υπολογιστής.
- 5Όλα αυτά υποστηρίζονται από πλεονασμό — τα δεδομένα και οι πόροι διπλασιάζονται σε περίπτωση αστοχίας.
Η κεντρικοποίηση και το ενιαίο σημείο αστοχίας δεν είναι το ίδιο πράγμα
Ένα σύστημα μπορεί να είναι κεντρικοποιημένο οργανωτικά και ταυτόχρονα πολύ καλά κατανεμημένο τεχνικά.
Για παράδειγμα, μία τράπεζα μπορεί να χρησιμοποιεί δεκάδες εγκαταστάσεις και χιλιάδες διακομιστές.
Όμως οι κανόνες λογιστικής καταγραφής και οι εξουσίες ανήκουν πάντα σε έναν οργανισμό.
Δηλαδή: τεχνικά — πολλά συστήματα και εγκαταστάσεις, οργανωτικά — ένας φορέας λειτουργίας.
Αυτά τα πράγματα δεν πρέπει να τα συγχέουμε.
Τι σημαίνει λοιπόν «ενιαίο σημείο εμπιστοσύνης»;
Ας εξετάσουμε ένα άλλο ζήτημα.
Η Emma δεν γνωρίζει σε ποιον ακριβώς διακομιστή βρίσκεται η εγγραφή για τα 5.000 € της.
Και δεν το χρειάζεται.
Εμπιστεύεται τον οργανισμό: την Τράπεζα Α.
Η ίδια η τράπεζα καθορίζει την επίσημη κατάσταση της λογιστικής της καταγραφής.
Αν στην εφαρμογή της Emma εμφανίζονται 5.000 €, ενώ στη βάση δεδομένων της τράπεζας 4.500 €, τότε η χρηματοοικονομική πραγματικότητα δεν μπορεί να καθοριστεί με ψηφοφορία ανάμεσα στο τηλέφωνο της Emma και τον διακομιστή της τράπεζας.
Η πηγή της καταγραφής είναι το τραπεζικό σύστημα.
Κεντρική αρχή
Για έναν τραπεζικό λογαριασμό, αυτόν τον ρόλο συνήθως τον εκτελεί η τράπεζα.
Αυτή: τηρεί τις εγγραφές· ελέγχει τις συναλλαγές· εφαρμόζει τους κανόνες· διορθώνει τα σφάλματα· καταγράφει το αποτέλεσμα.
Ο χρήστης δεν εμπιστεύεται έναν μεμονωμένο διακομιστή.
Εμπιστεύεται τον φορέα λειτουργίας του συστήματος.
Και αυτό είναι πολύ βολικό
Ας φανταστούμε ένα σφάλμα.
Το σύστημα χρέωσε δύο φορές 100 € για μία συναλλαγή.
Η Emma απευθύνεται στην τράπεζα.
Η τράπεζα μπορεί να: ελέγξει το ιστορικό· εντοπίσει την αιτία· κάνει διορθωτική εγγραφή· αποκαταστήσει το σωστό υπόλοιπο.
Γιατί είναι αυτό εφικτό;
Επειδή υπάρχει ένας οργανισμός που έχει την εξουσία να καθορίσει ποια κατάσταση της λογιστικής καταγραφής είναι η σωστή.
Αυτό είναι ένα από τα ισχυρότερα πλεονεκτήματα ενός κεντρικοποιημένου συστήματος.
Όμως ακριβώς εδώ εμφανίζεται η εξάρτηση
Αν ολόκληρη την επίσημη λογιστική καταγραφή την ελέγχει ένας φορέας λειτουργίας, οι χρήστες αναγκάζονται να εμπιστευτούν ότι αυτός: δεν θα χάσει δεδομένα· εφαρμόζει σωστά τους κανόνες· προστατεύει το σύστημα· είναι σε θέση να ανακάμψει μετά από ατύχημα· δεν θα επιτρέψει μη εξουσιοδοτημένες αλλαγές· θα εκπληρώσει τις νόμιμες υποχρεώσεις του.
Δηλαδή δημιουργείται συγκέντρωση εμπιστοσύνης.
Τι μπορεί να αστοχήσει
Το πρόβλημα δεν μοιάζει απαραίτητα με «χάλασε ο διακομιστής».
Η αστοχία μπορεί να συμβαίνει σε διαφορετικά επίπεδα.
Τεχνικό — για παράδειγμα: βλάβη βάσης δεδομένων· αστοχία δικτύου· σφάλμα λογισμικού· βλάβη εξοπλισμού.
Κυβερνητικό (κυβερνοασφάλειας) — για παράδειγμα: επίθεση· παραβίαση λογαριασμών· ransomware· παραβίαση της ακεραιότητας των δεδομένων.
Λειτουργικό — για παράδειγμα: εσφαλμένη ενημέρωση· λανθασμένη διαμόρφωση· ανθρώπινο λάθος.
Οργανωτικό — για παράδειγμα: κρίσιμο σφάλμα του ίδιου του φορέα λειτουργίας· διακοπή λειτουργίας της υπηρεσίας· σοβαρή οικονομική κρίση του οργανισμού.
Μία χρηματοοικονομική λειτουργία εξαρτάται ταυτόχρονα από αρκετά διαφορετικά είδη ανθεκτικότητας.
- 1Χωρίς πλεονασμό — ένα εξάρτημα αστοχεί και η υπηρεσία σταματά εντελώς.
- 2Με πλεονασμό — ένα εξάρτημα αστοχεί, όμως το failover μεταφέρει το φορτίο και η υπηρεσία συνεχίζει να λειτουργεί.
- 3Με backup — συμβαίνει ατύχημα, όμως η αποκατάσταση επαναφέρει το σύστημα στη σωστή κατάσταση.
Λίγα λόγια για τους όρους
High availability — αρχιτεκτονική σχεδιασμένη ώστε η λειτουργία να συνεχίζεται ακόμη κι όταν αστοχούν επιμέρους εξαρτήματα.
Failover — η μετάβαση σε ένα εφεδρικό εξάρτημα ή σύστημα.
Backup — αντίγραφο ασφαλείας δεδομένων.
Disaster recovery — διαδικασίες αποκατάστασης μετά από σοβαρή βλάβη ή ατύχημα.
Δεν χρειάζεται να απομνημονεύσετε όλες αυτές τις αγγλικές λέξεις τώρα.
Η βασική ιδέα είναι απλούστερη: ένα αξιόπιστο σύστημα προϋποθέτει εκ των προτέρων ότι κάτι κάποια στιγμή θα χαλάσει.
Οι υπολογιστές επιβεβαιώνουν αυτόν τον κανόνα με μεγάλη πειθαρχία.
Το αντίγραφο ασφαλείας και ένα λειτουργικό εφεδρικό σύστημα δεν είναι το ίδιο πράγμα
Ας φανταστούμε μια τράπεζα που κάνει backup κάθε μέρα.
Εξαιρετικά.
Όμως αν το κύριο σύστημα σταματήσει, η ύπαρξη backup δεν σημαίνει ακόμη άμεση συνέχιση της λειτουργίας.
Χρειάζεται: να αποκατασταθούν τα δεδομένα· να τεθεί σε λειτουργία η υποδομή· να ελεγχθεί η ακεραιότητά τους· να προσδιοριστεί το σωστό σημείο αποκατάστασης.
Επομένως το backup δεν είναι το ίδιο πράγμα με το high availability.
Το backup βοηθά στην αποκατάσταση.
Το high availability βοηθά να μη σταματήσει η λειτουργία ή να περιοριστεί η διακοπή.
Στο χρηματοπιστωτικό σύστημα η ακρίβεια της αποκατάστασης έχει ιδιαίτερη σημασία
Για μια συνηθισμένη ιστοσελίδα, μετά από ατύχημα, η απώλεια μερικών πρόσφατων προβολών σελίδας είναι δυσάρεστη, αλλά συνήθως όχι καταστροφική.
Για την τραπεζική λογιστική καταγραφή η κατάσταση είναι διαφορετική.
Πριν από τη βλάβη, η Sofia Martin είχε 7.430 €.
Μετά την αποκατάσταση δεν μπορεί να προκύψουν 7.210 € με την εξήγηση «περίπου έτσι ήταν».
Η χρηματοοικονομική καταγραφή απαιτεί την αποκατάσταση της ακριβούς κατάστασης και του ιστορικού των συναλλαγών.
Γι' αυτό χρειάζεται όχι μόνο backup, αλλά και αρχείο καταγραφής συμβάντων
Το σύστημα πρέπει να γνωρίζει: ποιες συναλλαγές ολοκληρώθηκαν· ποιες μόλις ξεκίνησαν· ποιες επιβεβαιώθηκαν· ποιες αλλαγές έχουν ήδη καταχωριστεί στη λογιστική καταγραφή.
Διαφορετικά, μετά την αποκατάσταση μπορεί να προκύψει μια επικίνδυνη κατάσταση: μια πληρωμή έχει ήδη εκτελεστεί, αλλά το σύστημα θεωρεί ότι δεν έχει ακόμη εκτελεστεί.
Και στη συνέχεια την επαναλαμβάνει.
Ήδη γνωρίζουμε πώς μπορεί να καταλήξει αυτό: σε διπλή πληρωμή.
Η διαθεσιμότητα είναι μέρος της χρηματοοικονομικής ασφάλειας
Όταν μιλάμε για την κυβερνοασφάλεια των τραπεζών, είναι εύκολο να σκεφτούμε μόνο την κλοπή δεδομένων.
Όμως η ασφάλεια περιλαμβάνει τουλάχιστον τρεις θεμελιώδεις ιδιότητες.
Εμπιστευτικότητα — τα δεδομένα δεν αποκτώνται από μη εξουσιοδοτημένα πρόσωπα.
Ακεραιότητα — τα δεδομένα δεν μπορούν να τροποποιηθούν απαρατήρητα ή παράνομα.
Διαθεσιμότητα — ο νόμιμος χρήστης μπορεί να αποκτήσει πρόσβαση στην απαραίτητη λειτουργία τη στιγμή που τη χρειάζεται.
Αν το τραπεζικό σύστημα προστατεύει άψογα τις εγγραφές, αλλά δεν λειτουργεί για μία εβδομάδα, αυτό αποτελεί επίσης σοβαρό πρόβλημα ασφάλειας.
Η κεντρικοποίηση διευκολύνει την προστασία — και συγκεντρώνει τις συνέπειες
Ένας οργανισμός μπορεί να: θεσπίσει ενιαίες απαιτήσεις· ενημερώνει κεντρικά τα συστήματα· ελέγχει τους διαχειριστές· διενεργεί ελέγχους (audit)· διαχειρίζεται τον πλεονασμό.
Αυτό είναι πλεονέκτημα.
Όμως αν ένα κρίσιμο σφάλμα επηρεάσει την κεντρική υποδομή, οι συνέπειες μπορούν να επηρεάσουν ταυτόχρονα πάρα πολλούς χρήστες.
Ένας γνώριμος συμβιβασμός: η κεντρικοποίηση επιτρέπει απλούστερη και ενιαία διαχείριση, όμως ένα σφάλμα σε κεντρικό επίπεδο μπορεί να έχει ευρεία επίδραση.
Μπορεί άραγε να αφαιρεθεί το κεντρικό σημείο;
Ας φανταστούμε μια διαφορετική αρχιτεκτονική.
Αντί για ένα μοναδικό επίσημο αντίγραφο του μητρώου, υπάρχουν πολλοί ανεξάρτητοι συμμετέχοντες, καθένας από τους οποίους διατηρεί πληροφορίες για την κατάσταση του συστήματος.
Αν ένας από τους κόμβους εξαφανιστεί, οι υπόλοιποι μπορούν να συνεχίσουν να λειτουργούν.
Με την πρώτη ματιά, υπέροχο.
Όμως εμφανίζεται ένα νέο πρόβλημα.
Ποιος από αυτούς έχει δίκιο;
Ας υποθέσουμε ότι ένας κόμβος λέει: «Η Emma έστειλε στον Alex 100».
Ένας άλλος κόμβος λέει: «Η Emma δεν έστειλε αυτά τα 100».
Ένας τρίτος κόμβος είναι προσωρινά εντελώς μη διαθέσιμος.
Πώς προσδιορίζεται η σωστή ιστορία;
Στο κεντρικοποιημένο σύστημα η απάντηση ήταν: η επίσημη βάση δεδομένων του φορέα λειτουργίας.
Στο κατανεμημένο σύστημα χρειάζεται να δημιουργηθεί ένας μηχανισμός που επιτρέπει στους ανεξάρτητους συμμετέχοντες να συμφωνήσουν για την κατάσταση.
Και εδώ εμφανίζεται η λέξη «συναίνεση»
Προς το παρόν αυτός ο ορισμός είναι αρκετός.
Τους μηχανισμούς συναίνεσης θα τους αναλύσουμε λεπτομερώς αργότερα.
- 1Κεντρικοποιημένο μητρώο — οι πελάτες απευθύνονται στον φορέα λειτουργίας, ο οποίος τηρεί το μοναδικό επίσημο μητρώο· η σωστή κατάσταση καθορίζεται χωρίς ψηφοφορία.
- 2Κατανεμημένο μητρώο — ανεξάρτητοι κόμβοι διατηρούν αντίγραφα της κατάστασης και πρέπει να συμφωνήσουν για μια κοινή έκδοση μέσω συναίνεσης.
Η αφαίρεση του κέντρου σημαίνει νέες προκλήσεις
Αν εγκαταλειφθεί ο κεντρικός φορέας λειτουργίας, πρέπει να αποφασιστεί: ποιος αποθηκεύει τα δεδομένα· ποιος δέχεται νέες συναλλαγές· πώς ελέγχεται η ορθότητά τους· πώς καθορίζεται η σειρά των συναλλαγών· τι συμβαίνει αν οι συμμετέχοντες διαφωνούν· τι πρέπει να γίνει με μη διαθέσιμους ή κακόβουλους συμμετέχοντες.
Το κέντρο εξαφανίστηκε.
Τα προβλήματα δεν εξαφανίστηκαν.
Άλλαξαν απλώς μορφή.
Και ένα κατανεμημένο σύστημα μπορεί να εξαρτάται από κεντρικοποιημένα στοιχεία
Αυτό έχει ιδιαίτερη σημασία για τη μελλοντική κατανόηση των κρυπτονομισμάτων.
Ας υποθέσουμε ότι το ίδιο το blockchain είναι αποκεντρωμένο.
Όμως ο χρήστης εργάζεται μέσω ενός κεντρικοποιημένου ανταλλακτηρίου, το οποίο με τη σειρά του απευθύνεται στο blockchain.
Αν το ανταλλακτήριο δεν είναι διαθέσιμο, ο χρήστης μπορεί να χάσει την πρόσβαση στη συναλλαγή μέσω αυτού, παρότι το ίδιο το blockchain συνεχίζει να λειτουργεί.
Ή: το πορτοφόλι απευθύνεται σε έναν πάροχο RPC, ο οποίος με τη σειρά του απευθύνεται στο blockchain.
Το blockchain λειτουργεί.
Όμως η εφαρμογή δεν λαμβάνει δεδομένα λόγω αστοχίας της συγκεκριμένης υπηρεσίας.
Γι' αυτό η λέξη «αποκεντρωμένο» πρέπει να χρησιμοποιείται προσεκτικά
Δεν μπορούμε απλώς να κοιτάξουμε ένα σύστημα και να πούμε: «Εκεί υπάρχει blockchain, άρα δεν υπάρχουν ενιαία σημεία αστοχίας».
Χρειάζεται να εξεταστεί ολόκληρη η αλυσίδα: το πρωτόκολλο· οι κόμβοι· το πορτοφόλι· το RPC· το ανταλλακτήριο· το smart contract· το bridge· ο εκδότης του περιουσιακού στοιχείου· η συσκευή του χρήστη.
Η κεντρικοποίηση μπορεί να εξαφανιστεί από ένα σημείο και να εμφανιστεί σε ένα άλλο.
Τα βασικά σημεία που πρέπει να θυμάστε
- Τα ψηφιακά χρήματα εξαρτώνται από τη διαθεσιμότητα της τεχνολογικής υποδομής.
- Το ενιαίο σημείο αστοχίας είναι ένα εξάρτημα του οποίου η αστοχία μπορεί να σταματήσει μια κρίσιμη λειτουργία.
- Ένα κεντρικοποιημένο σύστημα δεν χτίζεται απαραίτητα πάνω σε έναν διακομιστή.
- Ένας φορέας λειτουργίας μπορεί να χρησιμοποιεί πολλά γεωγραφικά κατανεμημένα και εφεδρικά συστήματα.
- Η κεντρικοποίηση σημαίνει πρωτίστως συγκέντρωση εξουσιών και εμπιστοσύνης, όχι απαραίτητα φυσική συγκέντρωση εξοπλισμού.
- Ο πλεονασμός, το failover, τα backups και το disaster recovery λύνουν διαφορετικά ζητήματα ανθεκτικότητας.
- Για το χρηματοπιστωτικό σύστημα είναι σημαντικό να αποκατασταθεί όχι μια κατά προσέγγιση, αλλά μια ακριβής και συνεπής κατάσταση της λογιστικής καταγραφής.
- Αν αφαιρεθεί ο κεντρικός φορέας λειτουργίας, προκύπτει η ανάγκη συμφωνίας της κατάστασης ανάμεσα σε ανεξάρτητους συμμετέχοντες.
- Γι' αυτό τα κατανεμημένα συστήματα χρειάζονται έναν μηχανισμό συναίνεσης.
- Ένα αποκεντρωμένο πρωτόκολλο δεν εγγυάται την απουσία κεντρικοποιημένων στοιχείων γύρω του.
- Κατά την ανάλυση οποιουδήποτε χρηματοπιστωτικού συστήματος είναι χρήσιμο να αναρωτιόμαστε: πού βρίσκονται τα πραγματικά σημεία εμπιστοσύνης και αστοχίας;
Τι ακολουθεί
Το τραπεζικό σύστημα τις τελευταίες δεκαετίες έχει γίνει: κινητό (mobile)· 24ωρο· αυτοματοποιημένο· πολύ πιο γρήγορο· πολύ πιο βολικό.
Ορισμένα προβλήματα που παλαιότερα ήταν πράγματι σοβαρά, οι σύγχρονες τεχνολογίες πληρωμών τα έχουν ήδη μειώσει σημαντικά.
Γι' αυτό προκύπτει ένα σημαντικό ερώτημα: χρειάζονται άραγε καθόλου νέες νομισματικές αρχιτεκτονικές, αφού οι τραπεζικές εφαρμογές λειτουργούν ήδη μέσα σε δευτερόλεπτα;
Για να απαντήσουμε ειλικρινά, πρέπει να διαχωρίσουμε δύο πράγματα: τι έχει ήδη λύσει ο ψηφιακός μετασχηματισμός των τραπεζών και τι παραμένει θεμελιώδες χαρακτηριστικό της ίδιας της αρχιτεκτονικής.
Γι' αυτό — στο επόμενο μέρος — «Τι έλυσε ο ψηφιακός μετασχηματισμός των τραπεζών — και τι δεν έλυσε».
- Το ψηφιακό χρήμα εξαρτάται από τη διαθεσιμότητα της τεχνολογικής υποδομής.
- Το ενιαίο σημείο αστοχίας είναι ένα στοιχείο του οποίου η αστοχία μπορεί να σταματήσει μια κρίσιμη λειτουργία.
- Ένα κεντρικοποιημένο σύστημα δεν είναι απαραίτητα χτισμένο πάνω σε έναν μόνο διακομιστή.
- Ένας φορέας μπορεί να χρησιμοποιεί πολλά γεωγραφικά κατανεμημένα και εφεδρικά συστήματα.
- Η κεντρικοποίηση σημαίνει πρωτίστως συγκέντρωση εξουσίας και εμπιστοσύνης, όχι απαραίτητα φυσική συγκέντρωση εξοπλισμού.
- Ο πλεονασμός, το failover, τα backups και το disaster recovery λύνουν διαφορετικά προβλήματα ανθεκτικότητας.
- Για ένα χρηματοοικονομικό σύστημα, αυτό που έχει σημασία είναι η αποκατάσταση μιας ακριβούς, συνεπούς κατάστασης μητρώου — όχι μιας κατά προσέγγιση.
- Η αφαίρεση του κεντρικού φορέα δημιουργεί το πρόβλημα του συντονισμού της κατάστασης μεταξύ ανεξάρτητων συμμετεχόντων.
- Τα κατανεμημένα συστήματα χρειάζονται έναν μηχανισμό συναίνεσης για αυτό.
- Ένα αποκεντρωμένο πρωτόκολλο δεν εγγυάται την απουσία κεντρικοποιημένων στοιχείων γύρω του.
- Όταν αναλύουμε οποιοδήποτε χρηματοοικονομικό σύστημα, είναι χρήσιμο να ρωτάμε: πού βρίσκονται τα πραγματικά σημεία εμπιστοσύνης και αστοχίας;