Рецензия · 14. Глубже в технологию
← обычный вид главыНаведите курсор (или тапните) на абзац — подсветится пара EN↔RU. Выделите фрагмент русского текста, чтобы предложить улучшение — оно уйдёт issue в репозиторий.
14. A Deeper Dive into the Technology
14. Глубже в технологию
14.1 Preliminaries
14.1 Предварительные замечания
Back in Chapters 5 and 6, we laid out the basic technical tools that underlie blockchain technologies. We discussed how proof of work and proof of stake worked, how smart contracts worked, and so on. That was enough for us to discuss some of the general conceptual issues we have addressed thus far, but along the way, we frequently promised that we would eventually go into more detail about those technologies. In this chapter, we make good on that promise.
Ещё в главах 5 и 6 мы описали базовые технические инструменты, на которых стоят блокчейн-технологии. Мы разобрали, как работают доказательство работы и доказательство доли, как устроены смарт-контракты, и так далее. Этого хватало, чтобы обсуждать общие концептуальные вопросы, которыми мы занимались до сих пор, но по ходу дела мы не раз обещали, что однажды расскажем об этих технологиях подробнее. В этой главе мы выполняем обещание.
In saying this, we do not mean we are going to provide the only way of fleshing out the technical details. In point of fact, there is more than one technological solution; there are many promising technologies that already exist or that are being developed or that someone will think of soon enough. Our goal here is to describe the strategies that we like best, which include the tools that have been developed by the Institute of Free Technology, with some words along the way about the technologies that inspired them as well as our current understanding of the technological landscape.
При этом мы вовсе не претендуем на то, что предложим единственный способ проработать технические детали. На деле технологическое решение не одно: многообещающих технологий много — одни уже существуют, другие разрабатываются, третьи кто-нибудь вот-вот придумает. Наша цель — описать стратегии, которые нравятся нам самим, в том числе инструменты, созданные в Institute of Free Technology, попутно сказав несколько слов о технологиях, которые их вдохновили, и о том, каким мы сегодня видим технологический ландшафт.
These strategies are the ones that we have selected to talk about, given the needs, interests and abilities of existing blockchain communities and their members. You may have identified other needs, interests and abilities and may prefer a different set of strategies. That is to be expected. Our goal here is simply to lay out one approach to the available technologies and explain how it works and why people were motivated to develop this package of technologies. You are, of course, free to disagree with us and suggest that alternative technologies would do a better job addressing the limitations we discussed. We would welcome the mere existence of such debates, as it would be yet more evidence of the vitality and promise of blockchain technologies and their role in securing better governance and better lives for all of us. There is no single correct path to human flourishing. There are many paths, although we believe they all run through some form of decentralised blockchain technology.
Эти стратегии мы отобрали для разговора, исходя из нужд, интересов и возможностей существующих блокчейн-сообществ и их участников. Вы, возможно, разглядели другие нужды, интересы и возможности — и предпочли бы другой набор стратегий. Это естественно. Наша задача — просто изложить один из подходов к доступным технологиям, объяснить, как он работает и что двигало людьми, разработавшими именно этот пакет технологий. Вы, разумеется, вольны с нами не согласиться и заявить, что с ограничениями, о которых мы говорили, лучше справились бы другие технологии. Мы были бы рады уже самому существованию таких споров: это стало бы ещё одним свидетельством жизненной силы блокчейн-технологий, их перспектив и их роли в том, чтобы дать всем нам лучшее управление и лучшую жизнь. Единственно верного пути к процветанию человека нет. Путей много, хотя, по нашему убеждению, все они проходят через ту или иную форму децентрализованной блокчейн-технологии.
14.2 Durable, corruption-resistant, transparent archives
14.2 Долговечные, устойчивые к коррупции, прозрачные архивы
In Chapter 5, we discussed at length the importance of secure archives for human governance. As we saw, archives preserve the history of government decisions, of property ownership, of culture and of relations with other communities. Indeed, as we saw, it is arguable that the archive comes before the community and the state, or in any case, that the community and state cannot exist without the archive. Furthermore, if a state or community cannot reliably maintain records of its actions, then it undermines the ability of its members to know if they should exit because the community administration no longer conforms to their values. Similarly, if the records are not accessible, community members lose the ability to understand the relations their community has entered into, the actions it has taken and, again, whether it is conforming to community values.
В главе 5 мы подробно говорили о том, как важны для управления сообществами надёжные архивы. Как мы видели, архивы хранят историю правительственных решений, прав собственности, культуры и отношений с другими сообществами. Более того — мы видели и это, — есть основания утверждать, что архив первичнее сообщества и государства; во всяком случае, без архива ни сообщество, ни государство существовать не могут. Дальше — больше: если государство или сообщество не способно надёжно вести записи о собственных действиях, оно лишает своих членов возможности понять, не пора ли им на выход — не перестала ли администрация сообщества отвечать их ценностям. Точно так же, если записи недоступны, члены сообщества уже не могут разобраться, в какие отношения их сообщество вступило, какие действия предприняло и — опять же — верно ли оно ценностям сообщества.
Just as we saw that archives are very important, they are also very vulnerable. As we have seen in this book, in the past, they have been destroyed by revolutionaries, drug lords, conquistadors, counterrevolutionaries, invading armies, earthquakes and fires. They can also be lost, corrupted with bad data, hidden and otherwise made inaccessible (or incriminating parts can be made inaccessible). So, the issue is that for any sort of community, and certainly for blockchain communities and cyberstates, we desperately need some way to make such archives secure, incorruptible and accessible.
Но архивы не только очень важны — они ещё и очень уязвимы. Как мы видели на страницах этой книги, в прошлом их уничтожали революционеры, наркобароны, конкистадоры, контрреволюционеры, вторгшиеся армии, землетрясения и пожары. Их можно и потерять, испортить недостоверными данными, спрятать или иным способом сделать недоступными (целиком — или только компрометирующие части). Словом, вопрос стоит так: любому сообществу — а уж блокчейн-сообществам и кибергосударствам точно — отчаянно нужен способ сделать архивы защищёнными, неподдающимися порче и доступными.
The solution that we alluded to in Chapter 5 was to deploy decentralised archives that would be Byzantine fault tolerant. The idea is that there will not be a single point of failure; one would have to take down a vast portion of the network to destroy the archive. Nodes in the network could be targeted, but the network could survive such attacks. Of course, that is a very general claim. It is time to go into more detail.
Решение, на которое мы намекали в главе 5, — развернуть децентрализованные архивы, обладающие византийской отказоустойчивостью. Идея в том, что единой точки отказа не будет: чтобы уничтожить архив, пришлось бы вывести из строя огромную часть сети. Отдельные узлы сети могут стать мишенью, но сеть такие атаки переживёт. Конечно, это утверждение самого общего свойства. Пора перейти к деталям.
There are certainly many available options for distributed archives, including decentralised storage networks such as the InterPlanetary File System or IPFS (which is connected to the cryptocurrency Filecoin), Storj, Arweave and Sia. Some of these efforts have very good ideas for which we will advocate. To date, however, none of them offer a complete package of desirables.
Вариантов распределённых архивов, безусловно, немало — в том числе сети децентрализованного хранения данных, такие как InterPlanetary File System, или IPFS (с ней связана криптовалюта Filecoin), Storj, Arweave и Sia. В некоторых из этих проектов есть отличные идеи, за которые мы ещё будем агитировать. Однако полного набора желаемых свойств на сегодня не предлагает ни один из них.
Let us begin with some of the limits that a decentralised file service might run into. One problem, of course, is that nodes within a network are of varying quality. We are talking about hardware here, and hardware failures happen often, without warning, and it sometimes seems that they happen at the worst possible times. One solution to the problem is to replicate the data at multiple locations in the network as often as possible. On one extreme, this would mean reproducing everything at every node. However, this strategy is wildly inefficient, and it has a centralising effect in that only very large-capacity nodes can hold all the information relevant to the conduct of, for example, a cyberstate. The network would consist of a handful of nodes that had the ability to supply Amazon or Google levels of data storage.
Начнём с ограничений, в которые может упереться децентрализованный файловый сервис. Одна из проблем, конечно, в том, что узлы в сети разного качества. Речь здесь о «железе», а железо отказывает часто, без предупреждения — и, кажется, норовит отказать в самый неподходящий момент. Одно из решений — как можно чаще реплицировать данные в разных местах сети. В пределе это означало бы воспроизводить всё на каждом узле. Но такая стратегия дико неэффективна, и вдобавок она работает на централизацию: держать всю информацию, нужную для жизни, скажем, кибергосударства, смогут только узлы очень большой ёмкости. Сеть свелась бы к горстке узлов, способных хранить данные в масштабах Amazon или Google.
You might think that we could get by with less redundancy if we can quickly repair a failure in the network. For example, a network in which two copies of every piece of data exist might be viable if you could repair the information loss the second a node went down. You would have to rebuild the redundancy as soon as you lost it. The problem is that two nodes that happen to have the same information might collapse at the same time. There is also the problem that constantly pinging nodes to see if they are online and available has a computational cost of its own. Therefore, the solution seems to be that we want more redundancy than two copies of the information. However, whether the solution is to create three or ten or one thousand copies depends on two things: how quickly you need to identify the data loss, and how quickly you need to repair it.
Можно подумать, что мы обошлись бы меньшей избыточностью, умей мы быстро чинить сбои в сети. Скажем, сеть, где каждый фрагмент данных существует в двух копиях, могла бы оказаться жизнеспособной — если восстанавливать потерянную информацию в ту же секунду, как узел вышел из строя. Избыточность пришлось бы отстраивать заново сразу, как только она утрачена. Беда в том, что два узла, на которых волей случая лежит одна и та же информация, могут рухнуть одновременно. Есть и другая проблема: постоянно опрашивать узлы, проверяя, в сети ли они и доступны ли, — это отдельная вычислительная нагрузка. Выходит, избыточности нам нужно больше, чем две копии информации. А вот сколько копий создавать — три, десять или тысячу, — зависит от двух вещей: как быстро вам нужно обнаруживать потерю данных и как быстро — её восполнять.
There is also an additional problem here, which is that just because a node is supposed to have a certain piece of information does not mean that it does. A node in the network might claim to be keeping a piece of information safe in order to receive incentives of some form (i.e. payment), but it might be acting dishonestly. Thus, we need to assure ourselves that the nodes actually have the information they are supposed to. This will generate difficulties when the information that the node is supposed to hold is confidential – medical records, for example. Therefore, we want to know that they have the relevant information without having to see the data itself.
Есть и ещё одна загвоздка: если узлу положено хранить некий фрагмент информации, это ещё не значит, что он его хранит. Узел сети может утверждать, что бережно хранит данные, — ради вознаграждения в той или иной форме (проще говоря, платы), — а на деле вести нечестную игру. Значит, нужно убедиться, что узлы действительно располагают информацией, которая им доверена. А это оборачивается трудностями, когда порученная узлу информация конфиденциальна — например, медицинские записи. Стало быть, мы хотим знать, что нужная информация у узла есть, не заглядывая в сами данные.
Another concern is the issue of how incentives are supposed to work. Obviously, a distributed archive only works if people support the network and maintain the nodes that they are supposed to, but if the incentive structure is suboptimal, we might find that the incentives are only appealing (or mostly appealing) to very large data centres. This would have the effect of centralising the network all over again.
Другой повод для беспокойства — то, как должны работать стимулы. Понятно, что распределённый архив живёт лишь до тех пор, пока люди поддерживают сеть и содержат положенные им узлы; но если система стимулов выстроена неудачно, может оказаться, что стимулы эти привлекательны только (или главным образом) для очень крупных дата-центров. А в итоге сеть снова начала бы централизоваться.
Therefore, there are many potential issues, and we are not the first to worry about these matters. Let us discuss some of these concerns and connect them with previous attempts to allay them.
Словом, потенциальных проблем немало, и тревожимся о них не мы первые. Разберём некоторые из этих опасений и посмотрим, как их пытались снять до нас.
Earlier, we stated that we do not want (actually, cannot have) a distributed network with a huge number of redundancies. There has to be some redundancy, of course, but critically, we also have to know when there is a data retention failure. To put it another way, you have to repair data loss in the network, but before you can do that, you have to know that the data has been lost.
Выше мы говорили, что распределённая сеть с огромным числом резервных копий нам не нужна (а вернее — попросту недоступна). Какая-то избыточность, конечно, необходима, но принципиально важно и другое: надо знать, когда хранение данных дало сбой. Иначе говоря, потерю данных в сети нужно восполнять, но прежде нужно узнать, что данные потеряны.
One solution, adopted by the Codex decentralised file storage protocol developed by the Institute of Free Technology, relies on ‘erasure coding’. ‘Erasure coding’ builds upon an old idea known as ‘Reed-Solomon codes’, which were developed by Irving S. Reed and Gustave Solomon, staff members of MIT Lincoln Laboratory, in 1960. Their seminal article was titled ‘Polynomial Codes Over Certain Finite Fields’, and their idea ended up having many applications over the years, most notably in compact disks.1
Одно из решений — его использует Codex, протокол децентрализованного файлового хранения, разработанный в Institute of Free Technology, — опирается на erasure-кодирование (кодирование с восстановлением после стираний). Оно развивает давнюю идею — коды Рида — Соломона, которые в 1960 году создали сотрудники Лаборатории Линкольна (MIT) Ирвинг Рид и Густав Соломон. Их основополагающая статья называлась «Полиномиальные коды над некоторыми конечными полями» (Polynomial Codes Over Certain Finite Fields), а сама идея за прошедшие годы нашла массу применений — самое известное из них компакт-диски.1
The basic idea is this: to find out if a given piece of data has gone missing, you do not want to have to keep looking for the data itself or its absence. It is far more efficient to sprinkle some tracking information into the data – markers for the relevant data, if you will. For example, a given block of medical data might come with a code. You do not search for the medical data itself. You just search for the marker. If you ping a node for the marker and get no response, you have reason to believe that the data has gone missing, at least temporarily. Maybe the node has gone down. Or maybe bit rot has corrupted the medium of memory. It does not matter what happened; you just need to know that the information might have gone missing.
Суть в следующем. Чтобы выяснить, не пропал ли тот или иной фрагмент данных, не хочется всякий раз искать сами данные — или убеждаться в их отсутствии. Куда эффективнее вкрапить в данные немного служебной информации — если угодно, маркеры для нужных данных. Скажем, блок медицинских данных может идти в комплекте с кодом. Вы не ищете сами медицинские записи — вы ищете только маркер. Если вы запросили у узла маркер и не получили ответа, есть основания считать, что данные пропали — хотя бы на время. Может, узел вышел из строя. А может, носитель памяти повреждён «битовой гнилью». Что именно случилось — неважно; вам нужно лишь знать, что информация могла пропасть.
Of course, this only actually works if the node being pinged is a good citizen and is not trying to deceive you, for it is possible to dump the data that is supposed to be preserved and keep the relevant tracking marker. Some sort of auditing mechanism is required.
Разумеется, всё это работает лишь при условии, что опрашиваемый узел ведёт себя добропорядочно и не пытается вас обмануть: ведь можно выбросить данные, которые положено беречь, а маркер к ним оставить. Нужен какой-то механизм аудита.
While erasure coding supports data loss detection, this alone may not be enough in Byzantine decentralised systems. Malicious nodes might try to implement a wide range of strategies to pretend they are storing information. Why would they do this? Maybe they are trying to cut costs and want to reduce expenditure on storage and bandwidth, but at the same time, they want to receive payment for data storage. Or maybe they are politically malicious and are part of a plot to disappear important cultural or legal information across the network. We need to occasionally probe or audit the information that was allegedly held.
Erasure-кодирование помогает обнаруживать потерю данных, но в децентрализованных системах, где возможны византийские сбои, одного этого может не хватить. Злонамеренные узлы способны пускаться на самые разные уловки, изображая, будто хранят информацию. Зачем им это? Возможно, они урезают расходы: хотят тратить меньше на хранение и трафик, но при этом получать плату за хранение данных. А возможно, их злой умысел политического толка — они участвуют в заговоре, цель которого в том, чтобы важная культурная или правовая информация бесследно исчезла из сети. Значит, информацию, которая якобы хранится, нужно время от времени прощупывать — проводить аудит.
This is a well-studied problem in the academic literature, and it goes by names such as ‘proof of custody’ and ‘proof of space-time’, among others. Most of the existing solutions rely on a frequent random sampling of data blocks across the whole dataset. During this process, storage nodes have to provide clear evidence that they are in possession of the data they say they hold.
В академической литературе эта проблема хорошо изучена и известна под разными именами, среди которых — доказательство ответственного хранения (proof of custody) и доказательство пространства-времени (proof of space-time). Большинство существующих решений строится на частой случайной выборке блоков данных по всему массиву. В ходе такой проверки узлы-хранители обязаны убедительно подтвердить: данные, которые они, по их словам, держат у себя, действительно при них.
These mechanisms are widely understood today, and for the most part, they do the job they are supposed to do, but with a couple of caveats. First, there is an issue of efficiency. There is a huge computational cost to conducting data audits – going through the data line by line. Then, for decentralised archives, there is the problem of what you are going to compare that data against to see if it is accurate. You cannot use a centralised register of information because then you have a centralised solution to the problem – the ‘official’ record has become centralised and thus becomes an immediate point of vulnerability. Beyond this, there is the issue discussed earlier in this section, which is that sometimes the information you are auditing is private. Take the example of medical records (or state secrets or whatever you like). You would like to pass the audit without releasing the information being stored to the auditor.
Сегодня эти механизмы хорошо изучены и в целом делают то, что от них требуется, — но с парой оговорок. Первая — эффективность. Аудит данных, когда их перебирают строка за строкой, обходится в огромные вычислительные затраты. Дальше, в случае децентрализованных архивов встаёт вопрос: с чем сверять эти данные, чтобы убедиться в их точности? Централизованный реестр информации не годится — иначе и решение задачи выйдет централизованным: «официальная» запись стала централизованной, а значит, тут же превратилась в точку уязвимости. Вдобавок есть проблема, о которой мы уже говорили в этом разделе: иногда проверяемая информация приватна. Возьмите те же медицинские записи (или государственные тайны — что угодно). Хотелось бы пройти аудит, не раскрывая аудитору само хранимое содержимое.
Codex and other distributed databases leverage zero-knowledge proofs to prove the possession of information. Given that we have mentioned zero-knowledge proofs multiple times without much in the way of elaboration, let us now provide more detail about these groundbreaking cryptographic protocols.
Codex и другие распределённые базы данных подтверждают обладание информацией с помощью доказательств с нулевым разглашением. Мы уже не раз поминали доказательства с нулевым разглашением мимоходом, почти без пояснений, — пора наконец рассказать об этих революционных криптографических протоколах подробнее.
At its most abstract level, a zero-knowledge proof is simply a way of proving you have certain information or a certain ability without giving that information away or without exercising the ability. Note that this is stronger than simply supplying a marker or code as evidence that the data is held. This is much closer to a mathematical proof that you hold the relevant data.
Если описывать предельно абстрактно, доказательство с нулевым разглашением — это просто способ доказать, что вы владеете некой информацией или неким умением, не раскрывая самой информации и не пуская умение в ход. Заметьте: это сильнее, чем просто предъявить метку или код в подтверждение того, что данные хранятся. Это куда ближе к математическому доказательству того, что нужные данные действительно у вас.
Suppose that we have a computer program that we want to sell to you – let us say an image analysis program that can identify buried treasure (yes, this is a completely fictional example, but stay with us). You want us to show you that the program works, so you ask us to run it to demonstrate its capabilities. Sneakily, during our demonstration, we run the very computation that you want to have performed; the demo itself will reveal the location of the buried treasure. One solution is to carry out demonstrations in other domains, but you might argue that no test is really reliable unless you can see that it functions as promised in the domain in which you intend to use it. What are we to do about your demands for proof of ability?
Предположим, у нас есть компьютерная программа, которую мы хотим вам продать, — скажем, программа анализа изображений, умеющая находить зарытые клады (да, пример совершенно вымышленный, но потерпите). Вы хотите убедиться, что программа работает, и просите нас запустить её — показать, на что она способна. Но вот в чём подвох: во время демонстрации мы выполним то самое вычисление, которое вам и нужно, — и демонстрация сама раскроет, где зарыт клад. Можно, конечно, устроить показ на другом материале, но вы вправе возразить: тест по-настоящему надёжен, лишь когда видно, что программа работает как обещано именно там, где вы собираетесь её применять. Что же нам делать с вашим требованием доказать умение?
This is where zero-knowledge proofs come in. Let us say we want to prove to you that our program can do what we say it can without giving away the thing of value (let us say we are selling a program to perform some task). We can do this in the following way. We provide a proof that anyone who can do the task you have in mind, let us call it Task 0 – a computation of some kind – can do this only if they can perform a certain logically related task (possibly including a collection of subtasks). Let us call this Task 1. To reiterate, Task 1 and Task 0 are related mathematically; in terms of computer science, Task 1 is reducible to Task 0. The proof relies on a challenge to see that the individual can perform Task 1. Since performing Task 1 implies the ability to perform Task 0, then we can (with reasonable probability) assume that the individual has done (or can do) Task 0. Keep in mind that Task 0 is the task you are interested in. It is the one for which you are ready to pay. The other task is not worth anything to you per se, beyond the fact that it establishes that we can carry out Task 0. You can ask us to carry out enough of these computationally related tasks so that you are satisfied that our program can do what we claim it can. In effect, you issue a series of challenges to us in order to prove that our program can perform the tasks we claim it does.
Вот тут и приходят на помощь доказательства с нулевым разглашением. Допустим, мы хотим доказать вам, что наша программа умеет то, что мы о ней говорим, не отдавая при этом самого ценного (скажем, мы продаём программу для решения некой задачи). Сделать это можно так. Мы предъявляем доказательство: всякий, кто способен решить интересующую вас задачу — назовём её Задачей 0, это некое вычисление, — способен на это лишь при условии, что умеет выполнять определённую логически связанную с ней задачу (возможно, включающую целый набор подзадач). Назовём её Задачей 1. Повторим: Задача 1 и Задача 0 связаны математически; на языке информатики Задача 1 сводится к Задаче 0. Доказательство строится на испытании: нужно убедиться, что человек справляется с Задачей 1. А поскольку умение выполнить Задачу 1 влечёт за собой умение выполнить Задачу 0, мы можем (с разумной вероятностью) заключить, что он решил — или может решить — Задачу 0. Не забывайте: Задача 0 — та, что вам нужна. Именно за неё вы готовы платить. Другая задача сама по себе для вас ничего не стоит — кроме того, что она удостоверяет: с Задачей 0 мы справимся. Вы можете попросить нас выполнить столько таких вычислительно связанных задач, сколько потребуется, чтобы увериться: программа умеет то, что мы про неё говорим. По сути, вы бросаете нам один вызов за другим, а мы доказываем, что наша программа справляется с заявленными задачами.
Zero-knowledge proofs come in many forms. We are inclined to favour succinct non-interactive arguments of knowledge – better known as ‘zk-SNARKs’. The concept of SNARK-type proofs has been in the literature for several years, and they have also been implemented by protocols such as Zcash and the zero-knowledge rollups (ZK-rollups) used by the Ethereum protocol in so-called ‘layer-two applications’ (for example, protocols like Polygon zkEVM). Here, we can think of a layer-two protocol as a separate blockchain that performs operations rapidly but uses a more decentralised layer-one protocol like Ethereum as its secure settlement layer.
Доказательства с нулевым разглашением бывают самыми разными. Нам ближе всего лаконичные неинтерактивные аргументы знания — более известные как zk-SNARK. Идея доказательств типа SNARK живёт в научной литературе уже не первый год, и они воплощены на практике — в протоколах вроде Zcash и в роллапах с нулевым разглашением (ZK-роллапах), которые протокол Ethereum использует в так называемых «приложениях второго уровня» (например, в протоколах вроде Polygon zkEVM). Протокол второго уровня здесь можно представлять как отдельный блокчейн: операции он выполняет быстро, а в качестве надёжного расчётного слоя использует более децентрализованный протокол первого уровня — такой как Ethereum.
The key difference between a zk-SNARK and a standard zero-knowledge proof procedure (like we used to verify our fictional treasure-hunting software) is that the zk-SNARK is, as the name suggests, non-interactive. This means that you do not need to issue a series of challenges to inductively establish the proof of knowledge. The idea is that a common reference string that both the prover and verifier share is sufficient to achieve computational zero-knowledge without requiring interactions.2 The non-interactive nature of the proof also removes the necessity of direct communication between the proving party and the validating party. This means that anyone can take a zk-SNARK proof and validate it with the same level of confidence that any other party has. This would be particularly helpful to independent third parties that might suspect the proving party and the validator are colluding. Finally, non-interactive proof procedures are particularly useful in the case of blockchain protocols, as constant interactive queries would be computationally expensive.
Ключевое отличие zk-SNARK от стандартной процедуры доказательства с нулевым разглашением (вроде той, которой мы проверяли вымышленную программу-кладоискатель) в том, что zk-SNARK, как следует из самого названия, неинтерактивен. Иначе говоря, вам не нужно бросать вызов за вызовом, чтобы индуктивно выстроить доказательство знания. Идея в том, что общей опорной строки, которая есть и у доказывающего, и у проверяющего, достаточно, чтобы достичь вычислительного нулевого разглашения без всякого взаимодействия.2 Неинтерактивность доказательства избавляет и от необходимости прямой связи между доказывающей и проверяющей сторонами. А значит, любой может взять доказательство zk-SNARK и проверить его с той же степенью уверенности, что и все остальные. Особенно это ценно для независимых третьих сторон, подозревающих, что доказывающий и проверяющий в сговоре. Наконец, неинтерактивные процедуры доказательства особенно удобны в блокчейн-протоколах: постоянные интерактивные запросы обходились бы слишком дорого в вычислительном отношении.
A moment ago, we mentioned the ZK-rollups that are used by Ethereum layer-two protocols, and these are useful as well, for they offer proofs of the validity of batches of transactions instead of transaction-by-transaction proofs. This can be beneficial if we want to query multiple databases for proof of possession of certain data without requiring proof of every single query. Batched queries are more efficient.
Чуть выше мы упомянули ZK-роллапы, которые применяются в протоколах второго уровня Ethereum. Они тоже полезны: вместо доказательства по каждой транзакции в отдельности они дают доказательства валидности целых пакетов транзакций. Это удобно, когда мы хотим опросить несколько баз данных, подтверждают ли они обладание определёнными данными, не требуя доказательства на каждый отдельный запрос. Пакетные запросы эффективнее.
So far, we have been talking about failure detection, and we have argued that data loss can be detected in several ways. We can detect benign data loss through erasure coding, and we can detect malicious data loss through remote auditing using zk-SNARKs. However, it is not enough to simply detect the missing or corrupted data. There is also the question of what you are going to do about it. Data loss needs to be repaired, but it needs to be repaired efficiently.
До сих пор мы говорили об обнаружении сбоев и утверждали: потерю данных можно выявить несколькими способами. Безобидную потерю обнаруживает erasure-кодирование, злонамеренную — дистанционный аудит с помощью zk-SNARK. Но мало обнаружить, что данные пропали или повреждены. Встаёт вопрос: что вы будете с этим делать? Потерю данных нужно восполнять — и восполнять эффективно.
One thought would be that as soon as you detect a loss of data, you should immediately repair it, but this turns out to be an inefficient solution. Usually, when a node goes down, it is a temporary problem, such as a power loss or required maintenance. Rather than engage in a computationally costly and potentially unnecessary repair process immediately, it would be better to wait to see if the node comes online again with the data intact.
Первая мысль: обнаружил потерю данных — немедленно чини. Но такое решение оказывается неэффективным. Обычно узел выходит из строя ненадолго: отключилось электричество, понадобилось обслуживание. Чем сразу запускать вычислительно дорогой и, возможно, ненужный процесс восстановления, лучше подождать и посмотреть, не вернётся ли узел в сеть с данными в целости.
That said, nodes do go offline permanently and data degrades for any number of reasons. We believe a strategy known as ‘lazy repair’ is best positioned to balance these concerns. The basic idea is that you can tolerate data loss for a while because you have enough redundancy in your system, but when that data loss crosses a certain threshold, you must initiate repairs and restore the system’s necessary redundancies.
И всё же порой узлы уходят из сети насовсем, а данные портятся по множеству причин. Мы считаем, что лучше всего уравновесить эти соображения позволяет стратегия, известная как «ленивое восстановление» (lazy repair). Суть в том, что какое-то время потерю данных можно терпеть — избыточности в системе хватает; но когда потери переходят определённый порог, надо браться за ремонт и возвращать системе необходимый запас избыточности.
Codex, for example, implements a strategy that starts with an idea from the previously mentioned Reed and Solomon work – in particular, a strong Reed-Solomon algorithm in which multiple data blocks from a dataset can be lost before the dataset becomes irretrievable. This means that the network can tolerate multiple missing blocks and still be able to reconstruct the whole dataset quickly. This allows us to implement a bandwidth-efficient, ‘lazy’ recovery technique like that just described. The basic idea is that when your redundancy falls below a certain threshold, you execute the repair strategy. For example, where seven copies are routinely maintained, one might tolerate a loss down to four copies, after which the creation of additional blocks is triggered. This strategy saves the network from a constant desperate churn to repair every single piece of missing data.
Стратегия Codex, к примеру, отталкивается от идеи из уже упомянутой работы Рида и Соломона — точнее, от усиленного алгоритма Рида — Соломона, который позволяет потерять несколько блоков данных, прежде чем весь набор станет невосстановимым. Это значит, что сеть терпит пропажу сразу нескольких блоков — и всё равно способна быстро воссоздать набор данных целиком. А потому мы можем применить экономную по пропускной способности, «ленивую» технику восстановления — ту самую, что описана выше. Идея проста: как только избыточность опускается ниже определённого порога, включается процедура ремонта. Скажем, если в норме поддерживается семь копий, потерю можно терпеть, пока копий не останется четыре; после этого запускается создание дополнительных блоков. Такая стратегия избавляет сеть от постоянной лихорадочной гонки — чинить каждый пропавший кусочек данных.
Where does this leave us? The thought is that we can use a basket of existing technologies to not merely identify and repair data loss in the network but also to identify those losses and repair them in the most efficient way possible. It will not matter if those losses of data are accidental or caused by a malicious actor, we will be able to audit the data and repair it as necessary.
Что же мы имеем в итоге? Мысль такая: набор уже существующих технологий позволяет не просто выявлять и чинить потери данных в сети, но выявлять и чинить их самым эффективным из возможных способов. И неважно, случайна потеря или подстроена злоумышленником: мы сможем проверить данные и, если нужно, восстановить их.
All of this leads to an important question: Who conducts and pays for all this work, and how are they incentivised? The answer, of course, is that the network itself has to carry out these activities, which need to be hard coded into the design of the network. The incentives are those we have discussed throughout this book in terms of the value of having secure archives. The costs are borne by whomever happens to participate in the network. It is not a cost that is felt directly by network members, although perhaps indirectly in terms of greater transaction fees.
Всё это подводит нас к важному вопросу: кто ведёт и оплачивает всю эту работу и какие у него на то стимулы? Ответ, разумеется, таков: заниматься этим должна сама сеть, и эти функции нужно намертво зашить в её конструкцию. Стимулы — те самые, о которых мы говорим на протяжении всей книги: ценность защищённых архивов. Издержки ложатся на тех, кто оказался участником сети. Напрямую участники сети этих затрат не чувствуют — хотя, возможно, ощущают косвенно, через выросшие комиссии за транзакции.
However, in addition to the general role of the network in securing the archives, individual nodes have to do their part, too – nodes that need to be incentivised (in addition to time commitments, there are hardware and electricity expenses associated with running a node). Few people are going to run a node on a distributed network without some sort of compensation. Hypothetically, a network could demand that its members carry their weight by maintaining archival nodes, but another possibility is to incentivise people to run nodes by paying them through a system of rewards.
Но общей заботой сети о сохранности архивов дело не ограничивается: свою лепту должны вносить и отдельные узлы, а узлам нужны стимулы (держать узел — это не только затраты времени, но и расходы на оборудование и электричество). Мало кто станет держать узел распределённой сети без какого-то вознаграждения. Гипотетически сеть могла бы требовать, чтобы участники несли свою ношу и содержали архивные узлы, но есть и другой путь — создавать людям стимулы держать узлы, платя им через систему вознаграждений.
This leads to the last big issue regarding archives: What does the incentive structure look like? This is not a trivial issue at all because we want the incentives for nodes to be designed so that they help the network grow in desirable ways. As we noted earlier, a poorly designed incentive structure might simply pay the most money to those node operators storing the most data. However, this leads to giant data repositories and something that looks a lot like the centralised Internet we see today, with powerhouses like Amazon maintaining giant server farms. This, in turn, gives them a kill switch to shut down many protocols should they choose to do so or be asked to do so by nation states and other powers. What is the solution?
Отсюда последний большой вопрос, связанный с архивами: как должна выглядеть структура стимулов? Вопрос отнюдь не пустячный: стимулы для узлов надо выстроить так, чтобы они помогали сети расти в желательном направлении. Как мы уже отмечали, плохо продуманная структура стимулов может попросту платить больше всего тем операторам узлов, которые хранят больше всего данных. Но так вырастают гигантские хранилища данных — и нечто очень похожее на сегодняшний централизованный интернет, где тяжеловесы вроде Amazon держат исполинские серверные фермы. А это, в свою очередь, даёт им рубильник, которым можно вырубить множество протоколов — по собственному решению или по требованию национальных государств и других сил. В чём же решение?
One idea is to structure the incentives so that they are very high for smaller stores of data and that they diminish as the set of stored data increases in size. There can be further incentives for data that is not widely replicated within the system or for data that is prioritised for some reason (medical records come to mind).
Одна из идей — выстроить стимулы так, чтобы за небольшие массивы данных они были очень высоки и снижались по мере того, как объём хранимого растёт. Можно ввести дополнительные стимулы за данные, которые слабо реплицированы в системе, или за данные, по какой-то причине приоритетные (первыми на ум приходят медицинские записи).
Now clearly, this strategy sacrifices some efficiency for more decentralisation. However, such a sacrifice is well worth it for all the reasons addressed in this book. Decentralisation leads to many goods, including securing communities against corruption – a phenomenon with astronomical costs. Another way to put the point is that forsaking decentralisation to save a small amount of financial resources is penny wise and pound foolish.
Ясно, что эта стратегия жертвует долей эффективности ради большей децентрализации. Но такая жертва окупается с лихвой — по всем причинам, разобранным в этой книге. Децентрализация приносит множество благ, и среди них — защита сообществ от коррупции, явления с астрономической ценой. Можно сказать и иначе: отказываться от децентрализации, чтобы сберечь немного денег, — значит экономить на спичках.
14.3 Decentralised, secure communications
14.3 Децентрализованная защищённая связь
Effective states and communities need not only secure and transparent (when appropriate) archives but also private rails upon which their community members can communicate. Community members may wish to communicate with each other about business strategies or inventions or ideas for new technologies. They accordingly need to know that their communications on these matters are secure.
Дееспособным государствам и сообществам нужны не только защищённые и — где это уместно — прозрачные архивы, но и приватные каналы, по которым могут общаться их члены. Членам сообщества может понадобиться обсудить друг с другом деловую стратегию, изобретение или замысел новой технологии. А значит, им нужно знать, что такие переговоры защищены.
However, communities also need to have a secure means of communication to discuss political matters. The fact that blockchain communities and cyberstates find people to be largely politically aligned does not mean that no important political disputes arise. People need to be able to discuss these in private until they feel ready to go public with their ideas.
Но защищённая связь нужна сообществам и для обсуждения политических вопросов. Пусть в блокчейн-сообществах и кибергосударствах люди в целом политически близки — это не значит, что там не бывает серьёзных политических споров. Людям нужна возможность обсуждать их приватно, пока они не решат, что готовы выйти со своими идеями к публике.
There is, obviously, an interesting asymmetry here in that the state itself should have open and transparent communications while individuals need private and secure communications. Persons in state positions will have access to private communications protocols, and these can be abused for purposes of state business. This is a problem we will return to but in the meantime, for us to even begin this discussion, we need to talk about secure communications.
Здесь, разумеется, есть любопытная асимметрия: связь самого государства должна быть открытой и прозрачной, тогда как частным лицам нужна связь приватная и защищённая. У людей на государственных постах будет доступ к протоколам приватной связи — и этим можно злоупотребить, ведя по таким каналам государственные дела. К этой проблеме мы ещё вернёмся, а пока — чтобы это обсуждение вообще могло начаться — нужно поговорить о защищённой связи.
You might think that we have secure communications now, and to some extent, we do. However, there are important limitations in the current system of communication networks and communication technologies. Much of the infrastructure for encrypted communications is highly centralised, with all of the dangers that this entails. For example, while we can communicate using Pretty Good Privacy (PGP), and while this affords us the protection of military-grade encryption, there are points of failure. The key server, for example, is housed in a centralised location. Our existing communications network can refuse to carry encrypted communications. Or they can refuse to carry encrypted communications from a particular source. Furthermore, although we can use encrypted communication protocols, it is still possible for others to know that we are the ones communicating.
Может показаться, что защищённая связь у нас уже есть, — и отчасти это правда. Но у нынешней системы — сетей и технологий связи — есть серьёзные ограничения. Значительная часть инфраструктуры шифрованной связи жёстко централизована, со всеми вытекающими отсюда опасностями. Скажем, мы можем переписываться через Pretty Good Privacy (PGP), и это даёт нам защиту шифрованием военного уровня, — но точки отказа никуда не деваются. Сервер ключей, к примеру, размещён централизованно. Существующая сеть связи может отказаться передавать шифрованные сообщения. Или отказаться передавать шифрованные сообщения из конкретного источника. Наконец, даже когда мы пользуемся протоколами шифрованной связи, посторонние всё равно могут узнать, что общаемся именно мы.
It is worth reflecting on why this is important. Sometimes, the meta information of who is talking to whom is even more important than what they are talking about. A lot can be extracted from this metadata. There is the network of people communicating, the time they are communicating, a reasonably good idea of the amount of information they are communicating and one can determine who is at the centre of the group of people communicating – the hub, as it were. This is an issue for any sort of communication of political strategy, but it is also an issue for business dealings. Business leaders might wish to communicate about a potential merger without signalling that they are communicating with each other.
Стоит задуматься, почему это важно. Порой метаинформация — кто с кем говорит — значит даже больше, чем сам предмет разговора. Из метаданных можно извлечь очень многое: сеть общающихся между собой людей, время их сеансов связи, довольно точное представление об объёме переданной информации; наконец, можно вычислить, кто находится в центре общающейся группы, — так сказать, её хаб. Это проблема для любых переговоров о политической стратегии, но и для деловых отношений тоже. Руководители компаний могут захотеть обсудить возможное слияние, не выдавая самого факта, что они друг с другом общаются.
Therefore, there are many issues to contend with. Perhaps the biggest of them involves the possibility of nodes being restrictive about the information that they let pass. Should nodes have the ability to censor the flow of information through the network? One would hope not, although censorship in decentralised nodes is not at all unheard of.3
Словом, трудностей здесь хватает. Едва ли не главная из них — возможность того, что узлы начнут придирчиво отбирать, какую информацию пропускать. Должна ли у узлов быть власть цензурировать поток информации в сети? Хочется надеяться, что нет; впрочем, цензура на децентрализованных узлах — явление отнюдь не неслыханное.3
Of course, we have technologies that allow us to encrypt our communications, so the problem is not that someone might read our communications and then censor them. The problem is that someone might censor our communications based on their origin or destination. Someone might choose to censor nodes that originate in right-wing or left-wing or politically agnostic communities. Or they might censor communications that are addressed to such communities. Or they might choose to censor communications of a certain size because they indicate a certain degree of interest in contemporaneous political events. Can nodes do that? Sure, they can do it now because communications must propagate through the network, and this means that each node in the network is responsible for passing packets of communicated data around the network.
Разумеется, у нас есть технологии шифрования, так что проблема не в том, что кто-то прочтёт наши сообщения и затем подвергнет их цензуре. Проблема в том, что нашу переписку могут цензурировать, исходя из её источника или пункта назначения. Кто-то может взяться отсекать узлы, принадлежащие правым, левым или политически нейтральным сообществам. Или блокировать сообщения, адресованные таким сообществам. Или вырезать сообщения определённого объёма — ведь объём выдаёт известную степень интереса к текущим политическим событиям. Способны ли узлы на такое? Ещё как — уже сегодня: ведь сообщениям приходится распространяться по сети, а значит, каждый узел этой сети отвечает за то, чтобы передавать пакеты пересылаемых данных дальше по сети.
Fortunately, protocols like Waku – developed by the Institute of Free Technology – address these problems. The desideratum is to find a strategy in which network nodes pass communications while being blind not just to the content but also to the source, the destination and the amount of information. How can we do this?
К счастью, эти проблемы решают протоколы вроде Waku, разработанного Institute of Free Technology. Искомое — найти стратегию, при которой узлы сети передают сообщения вслепую: не видя ни содержания, ни источника, ни адресата, ни объёма информации. Как этого добиться?
The central idea behind Waku is that packets of information passed through the communications network are encapsulated in a way that does not reveal content or a known author or recipient. The nodes must simply pass the encapsulated information on. But how do we obscure the metadata?
Центральная идея Waku: пакеты информации, идущие по сети связи, инкапсулируются — упаковываются так, чтобы нельзя было узнать ни содержание, ни автора, ни получателя. Узлам остаётся просто передавать упакованную информацию дальше. Но как же скрыть метаданные?
The metadata can be blurred in several ways. First, to disguise the amount of information being sent, short messages can be filled with additional junk information. Large messages can be broken into packets. All of these messages will not be routed directly from point A to point B but rather will be routed randomly through the network in a way that is blind to their ultimate destination. All a node needs to know is if a particular capsule is for that particular node. It can ping it using zero-knowledge proofs. If it is for them, the capsule will verify this; if it is not, the capsule will not verify ownership, and it will be passed on to other nodes.
Размыть их можно несколькими способами. Во-первых, чтобы замаскировать объём отправляемой информации, короткие сообщения дополняют «мусорными» данными. Длинные сообщения разбивают на пакеты. Все эти сообщения пойдут не напрямую из точки А в точку Б — их маршрут по сети будет случайным, слепым к конечному пункту назначения. Узлу нужно знать лишь одно: предназначена ли конкретная капсула именно ему. Это он может проверить, «пропинговав» её с помощью доказательств с нулевым разглашением. Если капсула адресована ему, она это подтвердит; если нет — подтверждения принадлежности не будет, и капсула отправится дальше, к другим узлам.
Now clearly, we want the transfer of information to be efficient despite all this, and one of the key ways to achieve this is to organise the network along the lines of a scale-free network. Such networks are designed with several densely integrated hubs connected to many local nodes but also connected to other centralised hubs. Scale-free networks like this are familiar in nature – the human brain and airline flight networks being cases in point. For example, most airlines have a handful of centralised hubs, each of which is densely connected to regional airports. This sort of network (explained by Duncan J. Watts in his book Small Worlds) gives rise to the ‘six degrees of separation’ phenomenon. Such networks not only seem to emerge from natural phenomena and human activity but are wildly efficient from a mathematical point of view.4
При всём этом информация, понятно, должна передаваться эффективно, и один из главных способов этого добиться — выстроить сеть как безмасштабную. Такие сети строятся вокруг нескольких плотно сплетённых хабов: каждый связан со множеством локальных узлов — а заодно и с другими центральными хабами. Безмасштабные сети такого рода хорошо знакомы нам из природы, наглядные примеры тому — человеческий мозг и сети авиасообщения. Скажем, у большинства авиакомпаний есть горстка узловых аэропортов, и каждый из них плотно связан с региональными. Сети такого устройства — их разбирает Дункан Уоттс в книге «Малые миры» (Small Worlds) — и порождают феномен «шести рукопожатий». Мало того что такие сети, судя по всему, сами собой складываются и в природе, и в человеческой деятельности, — они ещё и умопомрачительно эффективны с математической точки зрения.4
Therefore, we can think of a communications network for a blockchain community as having this sort of organising principle, with communications encapsulated and passed throughout the network quite rapidly thanks to heavily interconnected hubs and with the metadata obscured thanks to the sender being known only to the addressee and the addressee only known to the sender. Even the amount of information within the capsule will also be unknown, as small batches of information can be sent with junk information, and large batches of information will be split up randomly. The idea would be to have each capsule contain precisely the same number of bits of information.
Стало быть, и сеть связи блокчейн-сообщества можно мыслить устроенной по этому же организующему принципу: сообщения инкапсулированы и благодаря густо переплетённым хабам быстро расходятся по сети, а метаданные скрыты — отправителя знает лишь адресат, адресата — лишь отправитель. Неизвестен будет даже объём информации в капсуле: малые порции отправляются с «мусорным» довеском, большие — случайным образом дробятся. Замысел в том, чтобы каждая капсула несла ровно одно и то же число битов информации.
At the end of the day, this strategy, as embodied in Waku, provides a private and secure means for network citizens to communicate with each other while obscuring who is communicating with whom, how much is being communicated and, if we wish, obscuring the time of communication as well. Most importantly, there will be no opportunity for nodes in the network to censor the information they are passing along, as they will have no idea what its content is, who its sender is or who its receiver is.
В конечном счёте эта стратегия — в том виде, в каком её воплощает Waku, — даёт гражданам сети приватный и защищённый способ общаться друг с другом, скрывая, кто с кем говорит, сколько информации передаётся, а при желании — и время сеанса связи. Главное же — у узлов сети не будет никакой возможности цензурировать то, что они передают: им не узнать ни содержания сообщения, ни его отправителя, ни получателя.
14.4 Cryptocurrencies and sound monetary policy
14.4 Криптовалюты и здравая денежная политика
We can hardly conclude this chapter without saying something about cryptocurrencies. We have avoided talking about cryptocurrencies throughout this book (except to use them as illustrations) because we want to highlight newer applications for blockchain technologies – in particular, those applications that support decentralised governance. However, cryptocurrencies are, of course, not peripheral to this project. They are essential to any attempt to provide decentralised-yet-cooperative human governance.
Едва ли можно закончить эту главу, не сказав ни слова о криптовалютах. На протяжении всей книги мы обходили их стороной (разве что привлекали для иллюстраций): нам хотелось выдвинуть на первый план более свежие применения блокчейн-технологий — прежде всего те, что служат децентрализованному управлению. Но криптовалюты, разумеется, не где-то на периферии нашего проекта. Без них не обойдётся ни одна попытка построить децентрализованное, но кооперативное управление сообществами.
This should not be surprising. It would be foolish to offer a platform for decentralised governance and not apply it to currencies. Traditional fiat currencies and traditional finance have all the drawbacks that we have discussed throughout this book – they offer up centralised points of failure, are vectors for attack and are magnets for corruption. And, let us be real: any account of human governance that avoided the fiscal sector of human governance would hardly be taken seriously. Managing monetary policy and regulating the financial sector is one of the principal elements of governance today and has been a central element of governance for millennia.
Ничего удивительного тут нет. Глупо было бы предложить платформу для децентрализованного управления — и не приложить её к деньгам. У традиционных фиатных валют и традиционных финансов все изъяны, о которых мы говорили на протяжении книги: они создают централизованные точки отказа, открывают векторы для атак и притягивают коррупцию, как магнит. И будем честны: описание управления сообществами, минующее его фискальный сектор, вряд ли примут всерьёз. Вести денежную политику и регулировать финансовый сектор — одна из главных задач управления сегодня — и оставалась ею на протяжении тысячелетий.
The fundamental question here is not whether decentralised-yet-cooperative governance should avail itself of cryptocurrencies, but rather what form of cryptocurrencies should be utilised. We can sharpen that question in the following way: Should blockchain communities utilise off-the-shelf, globally recognised cryptocurrencies like BTC and ETH, or should individual communities mint their own tokens with which to carry out their business? The answer is: Why not both?
Принципиальный вопрос здесь не в том, стоит ли децентрализованному, но кооперативному управлению пользоваться криптовалютами, а в том, какую форму криптовалют выбрать. Заострим вопрос: пользоваться ли блокчейн-сообществам готовыми, признанными во всём мире криптовалютами вроде BTC и ETH — или каждому сообществу чеканить собственные токены и вести дела в них? Ответ: а почему не то и другое разом?
In the first place, it would be foolish for any blockchain community not to allow the usage of core cryptocurrencies like BTC and ETH. They, at least as of this writing, are monetarily sound; BTC will eventually reach its hard-capped supply limit of 21 million coins, and as we write this, ETH is sometimes already deflationary – more ETH is burned in a transaction than minted as staking rewards.5 Furthermore, the more widely the currency is circulated and the more widely decentralised a cryptocurrency network, the safer it is. We have already discussed the monumental amount of resources it would take to initiate a successful attack against either of these networks. One would either have to acquire massive amounts of mining resources (in the case of BTC) or stake a massive amount of ETH. Plus, the nodes for both protocols are already widely scattered around the globe. Given these advantages, why would one opt for a community-specific cryptocurrency?
Начнём с того, что любому блокчейн-сообществу было бы глупо не разрешить у себя хождение базовых криптовалют вроде BTC и ETH. С денежной точки зрения они — по крайней мере на момент, когда пишутся эти строки, — здравы: предложение BTC рано или поздно упрётся в жёсткий потолок в 21 миллион монет, а ETH, пока мы это пишем, временами уже дефляционен — в транзакциях сжигается больше ETH, чем выпускается в виде наград за стейкинг.5 К тому же чем шире валюта обращается и чем сильнее децентрализована криптовалютная сеть, тем она безопаснее. Мы уже обсуждали, какие исполинские ресурсы понадобились бы для успешной атаки на любую из этих сетей: пришлось бы либо скупить огромные майнинговые мощности (в случае BTC), либо отправить в стейкинг колоссальный объём ETH. Вдобавок узлы обоих протоколов уже разбросаны по всему миру. При таких достоинствах — зачем вообще заводить криптовалюту отдельного сообщества?
There is utility to having individual blockchain communities issue their own cryptocurrencies. In doing so, the community is maintaining its own ledger and recording value that is inherent in the operation of the community. Such cryptocurrencies might be used to measure stake in a DAO or they might be used to reward people making contributions to the community or they might be used to carry out business that is of interest to the community in a cost-efficient way. Thousands of web3 protocols have issued their own tokens for these and other reasons. Doing so is fairly simple, and as the protocol grows, such issuance can give rise to the accumulation of wealth by holders within the community.
И всё же своя польза в собственной криптовалюте сообщества есть. Выпуская свою монету, сообщество ведёт собственный реестр и записывает в него ту ценность, что рождается в самой его работе. Такой криптовалютой можно измерять долю участия в ДАО, вознаграждать тех, кто вносит вклад в жизнь сообщества, или недорого вести дела, которые сообществу интересны. Тысячи web3-протоколов выпустили собственные токены по этим и другим причинам. Дело это довольно простое, а по мере роста протокола такой выпуск позволяет держателям внутри сообщества накапливать богатство.
The problem with a community-issued cryptocurrency is that if the community is smaller, it means the value of the network will be less and a 51% attack of the type discussed in the previous chapter is always a possibility. Is there a way to enjoy the community-specific features of a community-based cryptocurrency while simultaneously preserving the security and safety provided by coins like BTC and ETH? Certainly. The trick is to anchor the community-based cryptocurrency in the more decentralised global coins, using the latter as a kind of settlement layer.
Беда криптовалюты, выпущенной сообществом, в том, что у небольшого сообщества и сеть будет стоить меньше, а значит, атака 51 % — из тех, что мы обсуждали в предыдущей главе, — всегда остаётся возможной. Можно ли сохранить преимущества монеты, заточенной под своё сообщество, и одновременно не потерять безопасность и надёжность, которые дают монеты вроде BTC и ETH? Конечно. Фокус в том, чтобы закрепить криптовалюту сообщества в более децентрализованных глобальных монетах — использовать их как своего рода расчётный слой.
There are many ways to ground a community-based cryptocurrency in a protocol like Ethereum, for example, by issuing the community-based cryptocurrency as a layer-two coin – something analogous to coins like Polygon’s POL and Arbitrum’s ARB, albeit presumably smaller in scope. In any case, one idea would be to issue the coin as a kind of ZK-rollup of the form we discussed earlier in this chapter.
Укоренить монету сообщества в протоколе вроде Ethereum можно по-разному: например, выпустить её как монету второго уровня — что-то наподобие POL у Polygon и ARB у Arbitrum, только, надо думать, поскромнее размахом. Так или иначе, одна из идей — выпустить монету в виде своего рода ZK-роллапа — из тех, о которых мы говорили выше в этой главе.
Here is the idea. Let us say that our blockchain community issues a layer-two coin called Community, or CMTY for short. That, in effect, means that we have a layer-two ledger that carries out computations, records information, and keeps track of transactions and who owns what for our community. However, if it is a ZK-rollup, we can also do two other things. Firstly, we can use zero-knowledge proofs to prove that the transactions are being carried out according to some specified set of rules. Secondly, we can assemble those layer-two transactions into batches and, periodically, permanently record the history of those transactions on the layer-one network – in this case, on the Ethereum blockchain. Thus, we get the best of both worlds. We get a ledger, smart contracts and so on that are dedicated to our community and its interests, and we can offer proof that those transactions and computations are valid. However, we can anchor the results of those transactions on the Ethereum blockchain and benefit from that blockchain’s robust security, which is, in part, a product of its global node distribution.
Идея вот в чём. Допустим, наше блокчейн-сообщество выпускает монету второго уровня под названием Community, сокращённо — CMTY. По сути это значит, что у нас появляется реестр второго уровня, который выполняет вычисления, хранит информацию, ведёт учёт транзакций и того, кто чем владеет в нашем сообществе. Но если это ZK-роллап, мы можем сделать ещё две вещи. Во-первых, доказательствами с нулевым разглашением подтверждать, что транзакции проводятся по заранее заданному своду правил. Во-вторых, собирать транзакции второго уровня в пакеты и периодически навсегда записывать их историю в сеть первого уровня — в нашем случае в блокчейн Ethereum. Так мы получаем лучшее из обоих миров: реестр, смарт-контракты и всё прочее служат именно нашему сообществу и его интересам, и мы можем предъявить доказательство, что все эти транзакции и вычисления корректны. А результаты транзакций при этом закрепляем в блокчейне Ethereum — и пользуемся его прочной защитой, которую, в частности, обеспечивает глобальный разброс его узлов.
A related strategy is to borrow from the Eigenlayer protocol and ‘restake’ ETH into the new token. Staying with our example of CMTY, this means that one first stakes one’s ETH in a protocol like the liquid staking service Lido, yielding stETH, which represents staked ETH. In doing so, you have staked your ETH to help secure the network and will earn financial rewards for doing so, but now you have a token – stETH – that is tremendously valuable. One could then take that stETH and restake it as the security layer for CMTY. In this way, it would be extremely costly to try to seize control of the CMTY network. There would be real losses if the staked assets had to be surrendered as a result of penalties levied against such bad actors.
Родственная стратегия — позаимствовать приём протокола Eigenlayer и отправить ETH в «рестейкинг» под новый токен. Если остаться при нашем примере с CMTY, это значит вот что: сначала вы ставите свой ETH в стейкинг через протокол вроде Lido — сервиса ликвидного стейкинга — и получаете stETH, токен, представляющий поставленный в стейкинг ETH. Тем самым вы отдали свой ETH на защиту сети и будете получать за это вознаграждение, но теперь у вас на руках токен — stETH, — и токен этот чрезвычайно ценен. Этот stETH можно затем отправить в рестейкинг — сделать из него слой безопасности для CMTY. Тогда попытка захватить контроль над сетью CMTY обойдётся крайне дорого: если за такое злоумышленникам начислят штрафы и поставленные в стейкинг активы придётся отдать, потери будут самые настоящие.
If that sounds too good to be true, we must confess that there are limitations to this strategy. In the next chapter, we will see that there are conceptual limits to decentralisation, and layer-two protocols certainly reveal points of centralisation. The first problem begins with bridging information and cryptocurrencies from layer one to layer two. As we write this, there are no established decentralised cross-chain bridging solutions. Beyond this, layer-two protocols often operate on a single or a small number of dedicated servers. This means that even though we can monitor the operations and query for proof of their validity, if those transactions take place on a single server or a small number of servers, there are points of physical attack. Now, perhaps these difficulties can be overcome with layer-two redundancies, but this would lead to sacrificing the efficiency that we come to expect from layer-two protocols (if you have carried out transactions on Polygon or Arbitrum, you know how much faster and cheaper they were than similar transactions on Ethereum). Our point here is not that there are no solutions but simply that there are tradeoffs to any solution – security for efficiency, for example.
Если всё это звучит слишком хорошо, чтобы быть правдой, — признаемся: у этой стратегии есть пределы. В следующей главе мы увидим, что у децентрализации есть концептуальные границы, и уж протоколы второго уровня точно обнаруживают точки централизации. Первая проблема начинается с моста: информацию и криптовалюту надо переправлять с первого уровня на второй, а устоявшихся децентрализованных решений для кроссчейн-мостов, пока мы пишем эти строки, не существует. Кроме того, протоколы второго уровня часто работают на одном выделенном сервере или на горстке таких серверов. А значит, пусть мы и можем следить за их работой и запрашивать доказательства её корректности, — раз транзакции проходят на одном сервере или на нескольких, есть и точки для физической атаки. Возможно, эти трудности снимаются избыточностью на втором уровне, но тогда придётся пожертвовать эффективностью, которой мы от протоколов второго уровня как раз и ждём (если вам случалось проводить транзакции в Polygon или Arbitrum, вы знаете, насколько быстрее и дешевле они были, чем похожие транзакции в Ethereum). Мы вовсе не говорим, что решений нет; мы говорим лишь, что у любого решения есть своя цена — например, безопасность ценой эффективности.
We could continue delving into technical issues, but you probably already grasp our central point. There are technologies that are already well understood and some newer ones that can be combined in different ways to pursue the goals that we outlined in the first thirteen chapters of this book. Because there are conceptual limits to what we can accomplish, and because there will be tradeoffs in any strategy we pursue, it would be foolhardy to say that there is one single best strategy that we should follow exclusively. Indeed, different blockchain communities will doubtless settle on different technology stacks.
Можно было бы и дальше углубляться в технические тонкости, но главную мысль вы, скорее всего, уже уловили. Есть технологии, изученные вдоль и поперёк, есть и поновее — и их можно по-разному сочетать ради целей, которые мы наметили в первых тринадцати главах книги. Достижимому положены концептуальные пределы, любая стратегия потребует компромиссов — и потому было бы безрассудно объявлять, будто существует одна-единственная лучшая стратегия, которой только и следует держаться. Разные блокчейн-сообщества наверняка и остановятся на разных стеках технологий.
Acknowledging that there is no single best approach to blockchain technologies, we can still offer tools that we feel are optimal for building such communities. In this chapter, we have already mentioned Codex and Waku and, previously, Status. However, there is one piece of the technology stack that we have not mentioned yet – Nomos. We have waited this long to introduce Nomos because, at its core, Nomos is what this book is about. Nomos is a layer-one blockchain that is optimised for human governance. It is a platform designed to help us build blockchain communities that meet the desiderata that we have discussed in this book.
Признавая, что единственно верного подхода к блокчейн-технологиям нет, мы всё же можем предложить инструменты, которые сами считаем оптимальными для строительства таких сообществ. В этой главе мы уже упоминали Codex и Waku, а раньше — Status. Но об одной части стека технологий мы до сих пор не сказали ни слова — о Nomos. Мы так долго откладывали разговор о Nomos потому, что Nomos, в сущности, и есть то, о чём эта книга. Nomos — блокчейн первого уровня, оптимизированный для управления сообществами. Это платформа, задуманная как подспорье в строительстве блокчейн-сообществ, отвечающих тем требованиям, которые мы обсуждали на страницах этой книги.
We encourage readers to explore and apply these technologies, adjusting them as necessary and adapting them to their needs. You may have entirely different ideas about how to proceed, but that is also completely fine. We are not merely advocates of decentralisation for finance and governance but for the enterprise of building out new technologies as well. As we stated earlier, there is no best way to proceed here, and if there is, we certainly do not know which way that would be – no one does.
Мы призываем читателей осваивать и применять эти технологии — подстраивая их, где нужно, и приспосабливая к собственным нуждам. Возможно, у вас совсем другие мысли о том, как действовать, — и это тоже совершенно нормально. Мы ратуем за децентрализацию не только в финансах и управлении, но и в самом создании новых технологий. Как мы уже говорили, лучшего пути здесь нет, а если он и есть, нам он точно не известен — да и никому не известен.
You can learn more about the elements of the technology stack we prefer at the following websites: Codex (https://codex.storage/), Waku (https://waku.org/), Nomos (https://nomos.tech/) and Status (https://status.app/). Those interested in these technologies and the principles behind them may also find value in the rest of the Institute of Free Technology’s portfolio (https://free.technology/). Feel free to use these technologies or ignore them as you see fit.
Подробнее об элементах стека технологий, который предпочитаем мы, можно узнать на сайтах: Codex (https://codex.storage/), Waku (https://waku.org/), Nomos (https://nomos.tech/) и Status (https://status.app/). Тем, кого заинтересовали эти технологии и стоящие за ними принципы, может пригодиться и остальное портфолио Institute of Free Technology (https://free.technology/). Пользуйтесь этими технологиями — или проходите мимо, как сочтёте нужным.
There are some additional issues that we need to address. These recommended technologies, like any technologies, do not operate in isolation. They are technologies designed to be used by humans but by humans that hold certain values. Nothing works if we are not successfully aligned with our technologies, or perhaps, it would be better to say if they are not aligned with us. However, there are other conceptual issues that we also need to address – for example, whether anything can truly be trustless and whether anything can be truly decentralised. We turn to these fascinating conceptual issues in the next chapter.
Остаётся ещё несколько вопросов, которые нужно разобрать. Рекомендованные нами технологии, как и любые другие, не работают в пустоте. Они рассчитаны на людей — но на людей, которые придерживаются определённых ценностей. Ничего не выйдет, если мы не согласованы со своими технологиями, — а вернее сказать, если они не согласованы с нами. Есть, впрочем, и другие концептуальные вопросы, мимо которых не пройти: например, может ли что-нибудь по-настоящему «не требовать доверия» и может ли что-нибудь быть по-настоящему децентрализованным. К этим увлекательным вопросам мы и обратимся в следующей главе.