Децентрализованная безопасность
В этой заметке я хотел бы обратить внимание на ряд подводных камней, встречающихся на пути любого блокчейн - разработчика, равно как и системного архитектора, перед которым стоит задача проектирования децентрализованной системы.
Проблема первая
Децентрализацию в контексте данной заметки удобнее представить как чемодан с двойным дном - двуличие янусоподобности которой обуславливает прежде всего тот факт, что в силу отсутствия центра, позволяющего отличить своего от чужого, недоверие должно присутствовать при обработке данных от любого участника сети, что, в свою очередь, порождает проблему доверия к данным, передаваемым участниками - система, имеющая и оперирующая только данными, имеющимися в ней в начале ее работы, бесполезна - система должна обладать интерактивностью, которую без внешних данных не получить.
Проблема вторая
Наличие сети, собравшей децентрализованных участников, несет под собой ограниченность сведений, имеющихся в распоряжении участников - и отсюда, необходимость в некоем третьем лице, поставляющем динамические данные, либо позволяющем эти данные выдавать в ответ на запрос одного из участников. Однако, любая автоматизация, при попытке формализации ее механизма, порождает уязвимость by design - наделяя участника сети браздами доверенного лица, необходимо эту доверенность чем-то подтвердить - например, выдав ему приватный ключ - позволяющий подписывать от имени системы некую динамическую информацию, поступающую в систему - будь то курс или кросс курс криптовалют, либо температура на побережье Майами Бич.
Проблема третья
Даже поверхностно проанализировав предположения первых двух проблем, становится ясно - реализовать без интерактива такую сеть невозможно по определению. Любой внешний источник информации, совмещенный с присвоением доверия этой информации прежде всего является источником опасности - чтобы взломать систему, достаточно взломать ее самое слабое место. А, в тяге за автоматизацией, любой разработчик рано или поздно сталкивается с проблемой - или автоматизировать процесс или сделать его полуавтоматическим (на данном слове у заказчиков, как правило, возникает топанье ногами и визг).
Потенциальное решение (устраивает заказчиков, устраивает разработчиков)
Согласитесь, в архитектуре, в которой на основании поступающих автоматически данных (например, кросс-курс базовой валюты к доллару) продаются, например, токены (например, из расчета поступившей на баланс смарт контракта валюты, пересчитываемой с учетом курса токена на курс токена в долларах) - единственной потерей могут стать токены (то их количество, которое будет неправомерно приобретено). Исходя из вышеперечисленного, если в смарт контракт добавить функцию sequestr (буквально - урезание), любые несоответствующие изменения количества токенов на балансе смарт-контракта, не соответствующие балансу базовой валюты, могут быть скорректированы функцией sequestr. Разумеется, данная функция не предусмотрена стандартом ERC20, но как workaround до появления нового, учитываюшего такие нюансы стандарта, вполне приемлемо.
Комментарии приветствуются!
Проблема первая
Децентрализацию в контексте данной заметки удобнее представить как чемодан с двойным дном - двуличие янусоподобности которой обуславливает прежде всего тот факт, что в силу отсутствия центра, позволяющего отличить своего от чужого, недоверие должно присутствовать при обработке данных от любого участника сети, что, в свою очередь, порождает проблему доверия к данным, передаваемым участниками - система, имеющая и оперирующая только данными, имеющимися в ней в начале ее работы, бесполезна - система должна обладать интерактивностью, которую без внешних данных не получить.
Проблема вторая
Наличие сети, собравшей децентрализованных участников, несет под собой ограниченность сведений, имеющихся в распоряжении участников - и отсюда, необходимость в некоем третьем лице, поставляющем динамические данные, либо позволяющем эти данные выдавать в ответ на запрос одного из участников. Однако, любая автоматизация, при попытке формализации ее механизма, порождает уязвимость by design - наделяя участника сети браздами доверенного лица, необходимо эту доверенность чем-то подтвердить - например, выдав ему приватный ключ - позволяющий подписывать от имени системы некую динамическую информацию, поступающую в систему - будь то курс или кросс курс криптовалют, либо температура на побережье Майами Бич.
Проблема третья
Даже поверхностно проанализировав предположения первых двух проблем, становится ясно - реализовать без интерактива такую сеть невозможно по определению. Любой внешний источник информации, совмещенный с присвоением доверия этой информации прежде всего является источником опасности - чтобы взломать систему, достаточно взломать ее самое слабое место. А, в тяге за автоматизацией, любой разработчик рано или поздно сталкивается с проблемой - или автоматизировать процесс или сделать его полуавтоматическим (на данном слове у заказчиков, как правило, возникает топанье ногами и визг).
Потенциальное решение (устраивает заказчиков, устраивает разработчиков)
Согласитесь, в архитектуре, в которой на основании поступающих автоматически данных (например, кросс-курс базовой валюты к доллару) продаются, например, токены (например, из расчета поступившей на баланс смарт контракта валюты, пересчитываемой с учетом курса токена на курс токена в долларах) - единственной потерей могут стать токены (то их количество, которое будет неправомерно приобретено). Исходя из вышеперечисленного, если в смарт контракт добавить функцию sequestr (буквально - урезание), любые несоответствующие изменения количества токенов на балансе смарт-контракта, не соответствующие балансу базовой валюты, могут быть скорректированы функцией sequestr. Разумеется, данная функция не предусмотрена стандартом ERC20, но как workaround до появления нового, учитываюшего такие нюансы стандарта, вполне приемлемо.
Комментарии приветствуются!
Комментарии
Отправить комментарий