Умные контракты повышают уровень автономности рабочих процессов организации. При использовании одного и того же протокола сети и даже одного и того же кода контракта возможны ситуации различного уровня автономности. Поэтому важно понимать, какой тип рабочего процесса данный контракт будет поддерживать.
Умные контракты в сети Ethereum можно использовать для двух типов задач:
- Поддержки рабочих процессов окружающего мира с использованием технологии блокчейн;
- Создания автономных рабочих процессов.
Используя умный контракт для поддержки рабочих процессов окружающего мира, мы добиваемся децентрализации процесса вычисления и хранения данных, участвующих в транзакции пользователя. Результат — повышение доверия к проекту при наличии у пользователя доверия к алгоритмам рабочего процесса, оракулу и протоколу сети.
В случае же с автономным рабочим процессом результат преобразования входных данных пользователя в выходные умным контрактом происходит исключительно заложенным алгоритмом. Тем самым доверие пользователя к проекту зависит от доверия к алгоритмам рабочего процесса и протоколу сети.
Простой пример с токеном
Для примера давайте рассмотрим умный контракт токена и умный контракт токена с эмиссией. Основное отличие между этими двумя токенами, как раз в наличии/отсутствии функции эмиссии.
Строки 15 -21:
function emission(uint _value) onlyOwner
{
// Overflow check
if (_value + totalSupply < totalSupply) throw;
totalSupply += _value;
balances[owner] +=_value;
}
Токен, эмиссия которого выполняет Externally owned account (EOA), будет являться умным контрактом, поддерживающим внешний рабочий процесс.
Токен, эмиссия которого выполняется в момент создания и в дальнейшем никем не контролируется, будет представлять из себя умный контракт, обеспечивающий автономный рабочий процесс для пользователя.
Пример с перегонным кубом
Рассмотрим две ситуации, в каждой из которых есть взаимодействие одного контракта токена с другим через контракт перегонный куб, т.е. вы отправляете Токен 1 на контракт перегонный куб, который сжигает Токены 1 и эмиссирует Токены 2.
Ситуация 1. Перегонный куб с автономными рабочими процессами.
Возьмём два контракта токена с эмиссией и контракт перегонного куба. Выполнил начальную эмиссию в каждом из них для примера:
- Токен 1. Начальная эмиссия 10 000 токенов.
- Токен 2. Начальная эмиссия 50 000 токенов.
После чего назначим владельцем обоих токенов контракт перегонного куба и зададим пропорцию 1 к 5. Тем самым контракт перегонного куба при получении N Токенов 1 должен будет после их сжигания эмиссировать N*5 Токенов 2. И в обратно направлении — при сжигании N Токенов 2, соотвественно, эмиссировать N*1/5 Токенов 1.
После того, как умному контракту перегонного куба будут переданы функции эмиссии обоих токенов, мы получим ситуацию, в которой ни один вход или выход не использует в своей работе данные из окружающей среды, а значит данный пример отражает полностью автономный процесс взаимодействия токенов и системы в целом.
Ситуация 2. Перегонный куб с влиянием оракула на всю систему.
Произведём аналогичные действия на старте, как и в ситуации 1, но оставим эмитентом Токена 1 пользовательский аккаунт.
Что мы можем сказать о схеме с включенным оракулом для эмиссии Токена 1? Оракул влияет на рабочий процесс умного контракта Токена 1.
Но если мы просмотрим процесс взаимодействия между токенами через перегонный куб, то получим в результате, что действия оракулам на прямую влияют на процессы Токена 2.
Если в ситуации 1 при правильно подобранных начальных эмиссиях Токена 1 и Токена 2 и правильном коэффициенте преобразования в перегонном кубе мы получали полностью стабильную систему:
Состояние 1: 10 000 Токенов 1 50 000 Токенов 2 Состояние 2: 0 Токенов 1 100 000 Токенов 2 Состояние 3: 20 000 Токенов 1 0 Токенов 2 Состояние 4: 10 000 Токенов 1 50 000 Токенов 2
То в ситуации 2 действия оракула могут приводить к бесконечному количеству вариантов поведения системы. Значит взаимосвязь токенов и наличие оракула, влияющего на Токен 1, превращает всю систему в поддержку рабочих процессов окружающего мира, где от поведения оракула зависит стабильность системы. Поэтому пользователям требуется доверять в такой ситуации не только алгоритмам умного контракта и протоколу, но и оракулу.
Сложная модель рабочих процессов с использованием умных контрактов
Организация может использовать множество умных контрактов, часть которых реализуют автономный рабочий процесс, часть поддерживает внешние рабочие процессы. Существует крайняя и, на мой взгляд, наиболее сложная схема взаимодействия, демонстрирующая случай, когда один умный контракт участвует в различных рабочих процесса, при этом какие-то процессы автономны, а какие-то зависят от оракула.
На рисунке выше представлена модель работы организации, использующей контракт «Банк эфиров» для хранения выплат по страховым случаям участников контракта страхования фермеров на основании данных о погоде от оракула.
При этом с умным контрактом «Банк эфиров» напрямую могут взаимодействовать другие пользователи для хранения своих средств.
В итоге мы получаем, что в случае рассмотрения контракта «Банк эфиров» со стороны системы страхования фермеров, данный контракт участвует в рабочем процессе, зависящем от оракула, а значит для фермера «Банк эфиров» поддерживает рабочий процесс из окружающего мира.
С точки зрения же прямых пользователей контракта «Банк эфиров», данный контракт поддерживает автономный рабочий процесс.
На пути ДАО
Децентрализованная автономная организация для поддержания собственных рабочих процессов должна использовать автономные рабочие процессы. Оракул для ДАО — это путь к уменьшению зависимости общества от привычных регуляторов организационных процессов, которые способны превратиться в автономные. Тем самым ДАО не зависит от оракулов, но дает инструменты, внутри которых часть рабочего процесса переходит в автономное состояние.
Словарь
- Рабочий процесс — процесс преобразования входов в выходы.
- Оракул — наиболее распространенное наименование участника сети, который обеспечивает отправку данных из внешнего мира в блокчейн в рамках определенного рабочего процесса.