Участники сообщества собрали общий фонд, написали правила в виде программы и договорились, что решения принимаются голосованием держателей голосов. Через полгода выяснилось, что голосует четверть участников, а крупнейший держатель может провести любое решение единолично. Механизм работает технически безупречно, а управление не работает вовсе. Разбираемся, как устроены такие системы, какие задачи решают и где проходит граница между замыслом и практикой.
Идея появилась в 2016 году и сразу столкнулась с серьёзным испытанием
Термин, обозначающий организацию, управляемую программно, вошёл в оборот в 2016 году. Тогда запустили систему, собиравшую средства в общий фонд. За короткий срок собралось более трёх с половиной миллионов единиц криптовалюты, что по курсу того времени превышало семьдесят миллионов долларов.
Через несколько недель система была взломана, и из фонда вывели около пятидесяти миллионов. Дальнейшие события оказались не менее показательными: чтобы вернуть средства, сеть, на которой работала система, разделили принудительно. Большинство участников перешли на новую ветку, меньшинство осталось на прежней.
Этот эпизод задал тон всей теме. С одной стороны, стало ясно, что программное управление уязвимо к ошибкам в коде. С другой стало видно, что при достаточной поддержке сообщество способно отменить задним числом то, что было записано в неизменяемом журнале. Заявленная неизменность оказалась условной.
Само понятие восходит к идеям девяностых годов, но широкое распространение получило с 2013 года. Часть исследователей считает первой такой организацией старейшую криптовалюту, где правила зашиты в код и применяются автоматически.
Управление строится на голосовании держателей специальных знаков
Работает это так. Организация выпускает знаки, дающие право голоса. Участники вносят средства и получают знаки пропорционально вкладу. Дальше любой держатель может предложить изменение, и по нему проводится голосование.
Решения бывают разными. Изменение правил работы, распределение средств, приём новых участников, назначение вознаграждения. Всё, что поддаётся описанию и подсчёту, может быть вынесено на голосование.
Голосование записывается в общий реестр, и результат нельзя подделать задним числом. Каждый может проверить, как распределились голоса и кто участвовал.
Практика выявила несколько проблем, о которых стоит сказать сразу.
Первая: знаки для голосования часто не используются. Значительная часть держателей просто не участвует, и кворум собирается из небольшого числа активных.
Вторая: возможна концентрация. Исследование нескольких организаций в финансовой сфере показало, что распределение знаков крайне неравномерно и сосредоточено у небольшого числа адресов.
Третья: голос не всегда отражает участие. Крупный держатель может не разбираться в конкретном вопросе, но его голос решает исход.
Четвёртая: делегирование. Чтобы бороться с неактивностью, ввели передачу голоса другому участнику. Это удобно, но углубляет концентрацию.
// подсчёт результата голосования с учётом веса
function tally(votes, proposals) {
const result = {};
for (const vote of votes) {
const weight = BigInt(vote.weight);
const target = vote.support ? "за" : "против";
result[target] = (result[target] || 0n) + weight;
}
const quorum = proposals.quorum;
const total = (result["за"] || 0n) + (result["против"] || 0n);
return {
за: result["за"] || 0n,
против: result["против"] || 0n,
кворум: total >= quorum,
принято: (result["за"] || 0n) > (result["против"] || 0n) && total >= quorum,
};
}Проверка кворума отдельной строкой не случайна. Без неё решение, принятое одним участником, формально считается законным.
Правила записываются в программу и выполняются автоматически
Техническая основа таких организаций это программы, хранящие состояние в общем реестре. Их называют смарт-контрактами, хотя название вводит в заблуждение: это не договор в юридическом смысле, а набор правил, который выполняется автоматически.
Понятие появилось ещё в девяностых годах. Автор термина приводил в пример торговый автомат: монета опущена, товар выдан, посредник не нужен. Современные реализации развили эту идею до программ, работающих на распределённой сети.
Устройство напоминает обычную программу. Есть состояние, то есть набор данных. Есть функции, меняющие состояние. Есть условия, при которых действие разрешено.
class Treasury:
def __init__(self):
self.balances = {}
self.owners = set()
self.threshold = 2
def deposit(self, sender, amount):
self.balances[sender] = self.balances.get(sender, 0) + amount
def propose(self, proposer, to, amount):
if proposer not in self.owners:
raise PermissionError("Только для участников")
if self.balances.get(self.address, 0) < amount:
raise ValueError("Недостаточно средств")
return {"to": to, "amount": amount, "approvals": 1}Здесь видно главное отличие от обычной программы: проверки встроены в код и не могут быть обойдены. Нельзя проголосовать, не будучи участником, нельзя вывести больше, чем есть.
Обратная сторона тоже очевидна. Ошибку в коде невозможно обойти: нет администратора, который отменит действие. Известны случаи, когда из-за одной опечатки средства становились недоступными навсегда.
Стоимость операций ограничивает сложность решений
Оплата за выполнение операций устроена по-особому. Каждое действие требует платы, которая называется газом. Размер зависит от сложности программы.
Отсюда практические ограничения. Очень сложная программа может оказаться невыгодной или вовсе невозможной к запуску: плата превышает разумные пределы. Циклы и объёмные вычисления обходятся дороже простых операций.
Второе ограничение это пропускная способность. В одной из сетей блок создаётся в среднем раз в десять минут, в другой раз в двенадцать секунд. Для сравнения, платёжные системы общего назначения обрабатывают около десяти тысяч операций в секунду. Разрыв огромен, и от него зависит, насколько сложные процессы можно автоматизировать.
Третье ограничение это рост цены при нагрузке. Чем больше желающих, тем дороже операция. В периоды ажиотажа плата за простой перевод вырастает в разы.
Четвёртое ограничение это необходимость связи. Без доступа к сети система не работает вовсе, и это отличает её от обычного приложения с локальными данными.
Понимание этих ограничений меняет подход к проектированию. На дорогой сети хранят только то, что требует доверия многих сторон: права, голоса, расчёты. Всё остальное выносят за её пределы.
Приложения для децентрализованных систем строятся по трём слоям
Разработка таких приложений имеет свою специфику. Обычно выделяют три части.
Первая это программы в сети. Они хранят состояние и выполняют правила. Именно здесь лежит то, что должно быть защищено от подмены одной стороной.
Вторая это внешний интерфейс. Обычная веб-страница, которая обращается к сети через промежуточный слой. Интерфейс можно написать на любом языке, потому что в итоге он просто формирует запросы.
Третья это промежуточный слой, упрощающий чтение. Прямое чтение из сети медленное и неудобное, поэтому данные индексируются и отдаются через обычные запросы.
async function connect() {
if (!window.ethereum) {
throw new Error("Расширение для работы с сетью не найдено");
}
const accounts = await window.ethereum.request({
method: "eth_requestAccounts",
});
return accounts[0];
}
async function sendProposal(contract, text) {
const account = await connect();
const data = contract.methods.propose(text).encodeABI();
return window.ethereum.request({
method: "eth_sendTransaction",
params: [{ from: account, to: contract.options.address, data }],
});
}Обратите внимание на проверку наличия расширения. Без него приложение не сможет подписать операцию, и пользователь должен получить понятное объяснение, а не пустой экран.
Второй момент касается подтверждения. Каждая операция требует подписи пользователя и оплаты. Интерфейс обязан показывать, что именно подтверждается и сколько это стоит. Скрытые операции разрушают доверие мгновенно.
Практика применения оказалась скромнее ожиданий
Статистика показывает картину, далёкую от первоначальных обещаний.
Исследование почти тысячи приложений в одной из популярных сетей выявило высокую концентрацию. Меньше пятой части проектов привлекли почти всех пользователей, около пяти процентов обеспечивали восемьдесят процентов операций, а восемьдесят процентов приложений имели меньше тысячи пользователей.
Причинами называют несколько обстоятельств. Сложность освоения: человеку нужно завести ключ, пополнить счёт, разобраться с подтверждениями. Стоимость операций: при небольших суммах плата составляет заметную долю. Непонимание отличий от обычного приложения: пользователь не видит, что даёт ему новая форма.
Второе наблюдение касается управления. Голосование требует внимания и времени, а выгода от участия размыта между всеми. Получается знакомая проблема: участвуют те, у кого есть интерес и ресурсы.
Третье наблюдение связано с прозрачностью. Открытость журнала не означает понятности. Читать операции может любой, но для этого нужны специальные инструменты и подготовка.
Где такой подход действительно полезен
Несмотря на скромную статистику, есть случаи, где механизм решает настоящую задачу.
Первый случай это общие фонды с несколькими распорядителями. Правило о том, что вывод требует согласия большинства, записывается в код и не может быть нарушено. Бухгалтерия становится публичной по умолчанию.
Второй случай это прозрачные выплаты. Вознаграждение участников рассчитывается по заранее объявленным правилам, и никто не может изменить формулу задним числом.
Третий случай это совместное владение. Доли фиксируются программно, передача доли происходит по ясной процедуре.
Четвёртый случай это публичные опросы с проверяемым результатом. Итог голосования можно пересчитать независимо.
Есть и случаи, где подход не подходит. Задачи, требующие скорости, плохо ложатся на медленную сеть. Задачи с высокой неопределённостью плохо описываются жёсткими правилами. Задачи, требующие ответственного за решение, не решаются автоматизацией.
Внедрение стоит начинать с малого и с ясной цели
Разумный порядок работы выглядит так.
Первый шаг это определение задачи. Что именно должно быть защищено от подмены? Если ответа нет, технология не нужна.
Второй шаг это описание правил. Простым текстом, до написания кода. Кто может вносить средства, кто голосует, каков порог, что происходит при споре.
Третий шаг это проверка на тестовой сети. Все сценарии прогоняются без реальных средств. Стоимость ошибки нулевая, а знания набираются быстро.
Четвёртый шаг это аудит. Программу проверяет независимый специалист. Это не формальность: цена ошибки может быть полной.
Пятый шаг это ограниченный запуск. Малые суммы, узкий круг участников, наблюдение.
Шестой шаг это план на случай сбоя. Что делать, если обнаружена уязвимость? Кто имеет право приостановить операции? Наличие такого плана важнее, чем его отсутствие по идейным соображениям.
Отдельный разбор касается юридической стороны вопроса
Техническая часть решена, а правовая остаётся неопределённой, и это влияет на практику.
Первое обстоятельство: программа не является договором в юридическом смысле. Автоматическое исполнение не заменяет обязательств, признаваемых правом.
Второе: статус объединения неясен. Кто отвечает по обязательствам, как платить налоги, как оформлять отношения с подрядчиками. Ответы различаются от страны к стране.
Третье: процедура возврата средств при ошибке не описана. Судебное вмешательство плохо совместимо с неизменяемым журналом.
Четвёртое: часть стран начала принимать правила, касающиеся таких объединений и программ. Ситуация меняется, и следить за ней приходится постоянно.
Пятое: практический вывод состоит в том, чтобы не полагаться только на код. Юридическое оформление и техническая реализация должны дополнять друг друга.
Сопоставление с обычной организацией помогает понять разницу
Полезно сравнить два способа ведения дел по нескольким признакам.
Первый признак это прозрачность. В обычной организации бухгалтерия доступна узкому кругу. В программной системе операции видит любой желающий.
Второй признак это скорость изменений. В обычной организации решение оформляется протоколом и вступает в силу. В программной требуется выпуск новой версии, а иногда и разделение сети.
Третий признак это стоимость ошибки. В обычной организации неверное решение можно отменить. В программной отмена либо невозможна, либо требует вмешательства, сопоставимого с аварией.
Четвёртый признак это участие. В обычной организации роли назначены. В программной участие добровольное, и явка часто низкая.
Пятый признак это ответственность. В обычной организации есть тот, кто отвечает. В программной ответственность размыта между держателями.
Из этого сопоставления следует простой вывод: выбирать форму стоит по задаче. Для прозрачных расчётов между партнёрами подходит программная. Для управления людьми и разрешения спорных ситуаций обычная остаётся надёжнее.
Что стоит проверить перед запуском
Первое: описан ли текстом свод правил до написания кода.
Второе: проверены ли все сценарии на тестовой сети.
Третье: посчитана ли стоимость типовых операций при текущей нагрузке.
Четвёртое: есть ли независимая проверка программы специалистом.
Пятое: предусмотрен ли порядок действий при обнаружении уязвимости.
Шестое: понятно ли, как участник выходит из объединения и получает свою долю.
Седьмое: продумано ли, что увидит человек без технической подготовки.
Эти семь вопросов занимают час обсуждения и снимают большую часть рисков. Технология здесь не главное: главное это ясность правил, по которым люди договариваются ими пользоваться.
Децентрализованное управление получилось темой, где техническая реализуемость опередила организационную зрелость. Записать правила в код несложно, а договориться о правилах, обеспечить участие и предусмотреть выход из спорной ситуации намного труднее. Там, где эти вопросы решены, механизм работает тихо и надёжно. Там, где нет, получается красивая оболочка с теми же проблемами, что и в обычной организации, только исправить их сложнее.