Смарт-контракты и возможность их применения
Привет, Хабр! На связи участник профессионального сообщества NTA Незнанов Дмитрий.
Эфириум и зачем он нужен
Блокчейн все больше интегрируется в системы хранения и контроля документов. Преимущество этой технологии заключается в отсутствии практической возможности манипуляции данными, записанными в систему, благодаря тому, что информацию в базу данных можно только добавлять, но не перезаписывать. В то же время, истинность документа легко прослеживается, так как каждый видит, кем он был записан в блокчейн.
Рассмотрим смарт-контракты на базе блокчейн Ethereum
Ethereum — платформа для создания децентрализованных онлайн‑сервисов на базе блокчейна, работающих на базе умных контрактов. Реализована как единая децентрализованная виртуальная машина. Был предложен основателем журнала Bitcoin Magazine Виталиком Бутериным в конце 2013 года. Сеть была запущена 30 июля 2015 года.
Эфириум, в отличие от биткоина, внутри проекта функционирует не только как платежное средство, а как способ обеспечения смарт‑контрактов в блокчейн платформах. Сам же смарт‑контракт является обычной программой, выполняющей соглашения между двумя и более сторонами при достижении какого‑нибудь события.
Смарт‑контракты можно использовать везде, где нужно выполнять функцию автоматического контроля и управления исполнения контрактных обязательств. И в отличие от юридических контрактов, основанных на доверии сторон и требующих участия третей стороны для контроля исполнения, смарт контракты используют технологию блокчейн для обеспечения прозрачности, надежности и неизменности информации.
Смарт‑контракты устраняют необходимость участия посредников и позволяют снизить риски для всех сторон. Их можно сравнить с автоматами для покупки газировки, где исключается посредник в виде продавца. Аппарат работает автономно, без посторонней помощи.
Однако, несмотря на все преимущества, у смарт‑контрактов есть и недостатки. Они зависят от технологии блокчейн и могут быть уязвимы к хакерским атакам или выходом из строя инфраструктуры, что может привести к краже или потере данных, а также временной невозможности пользоваться смарт‑контрактом.
Для написания смарт‑контрактов используются разные среды разработки и языки программирования. Например, язык Solidity. Его можно использовать в среде разработки Remix и VS Code.
Solidity — это один из 4-х языков программирования, наряду с Serpent, LLL и Mutant, спроектированных для трансляции в байт‑код виртуальной машины Ethereum. Синтаксически похож на JavaScript. Один из самых главных плюсов — наличие большого количества библиотек, доступных для использования, а так же большое количество документации и большое сообщество.
Также в смарт‑контрактах используются стандарты для операции над токенами. В моем примере, описанном более подробно ниже, использовался стандарт ERC 1155. В отличие от предыдущего стандарта ERC-721, этот стандарт имеет ряд преимуществ, такие как:
1. Гибкость. Созданные с помощью этого стандарта токены имеют разные функции и параметры, которые могут быть настроены под определенные задачи.
2. Уникальность. Все токены имеют уникальный идентификатор, что позволяет избежать путаницы.
3. Поддержка разных типов данных. Стандарт позволяет хранить различные типы данных, такие как строки, числа, даты и т. д.
4. Низкие комиссии. Транзакции с использованием ERC-1155 имеют низкие комиссии, что важно для приложений, где производится множество транзакций.
5. Прозрачность. Все операции записываются в блокчейн Ethereum, что обеспечивает прозрачность и надежность системы. т. е. все транзакции и изменения состояния токенов могут быть проверены и подтверждены.
6. Безопасность. Имеются ряд функций, улучшающих безопасность связанных смарт‑контрактов. Например, можно установить лимит на количество токенов, которые могут быть отправлены на адрес, что помогает предотвратить DoS атаки.
В России есть несколько причин, по которым использование смарт‑контрактов затруднено.
Одна из них — это отсутствие регулирования в области блокчейн и смарт‑контрактов. Нет никаких ясных правил и законов, которые определяют, как эти технологии можно использовать и как их регулировать. Также существуют проблемы с юридической точки зрения, связанные с использованием смарт‑контрактов. Например, как адаптировать смарт‑контракты к существующему законодательству или какая юрисдикция применяется к смарт‑контрактам. До сих пор эти и другие вопросы не решены.
Также использованию не способствует слабое понимание людей, что такое блокчейн и смарт‑контракты, и как они могут быть использованы.
Основной проблемой реализации было незнание новых инструментов, и, несмотря на обильное количество документации, было тяжело их изучать без наглядных примеров, которых очень мало по данной тематике.
Как работает мой смарт-контракт
Для примера разберем смарт‑контракт, который выступает площадкой‑гарантом сделок с NFT. Сам смарт‑контракт будет представлять из себя продажу/обмен цифровых активов, например, NFT картинок и будет выполнен следующим образом:
1. Смарт‑контракт для создания самих NFT:
— Регулирует количество созданных объектов.
— Генерация ссылки для просмотра метаданных.
— Генерация ссылки для просмотра картинок.
2. Смарт‑контракт для обмена/продажи NFT:
— Реализация выставления определённого NFT на продажу с заданием цены за штуку (для продавца).
— Возможность просмотра, сколько стоит единица товара (для покупателя).
— Возможность покупки (для покупателя).
— Возможность снятия денег с контракта (для продавца).
— Привязка контракта покупки к контракту создания NFT.
Возьмем для примера 3 токена с разными id и в разном количестве.
В контракте для владельца имеется возможность безвозмездной передачи токенов любому пользователю в любом количестве.
Также владелец может подтверждать смарт‑контракты для продажи из своего контракта.
В контракте для покупателей есть функции выставления токенов на продажу, покупки токенов, проверки их стоимости и вывода средств со счета смарт‑контракта (только для владельца).
Касаемо безопасности, есть ряд проверок, которые не дадут случайным людям вывести средства со счета смарт‑контракта, а также не дадут выставить на продажу токены, которых нет у того, кто хочет их выставить. При покупке токенов производится проверка отправленных средств, если их меньше необходимого, то операция отменяется. Для наглядности представлю упрощенную версию того, в какой последовательности и по какой логике происходят проверки.
Здесь показана логика добавления токена на продажу. Как видно из схемы, смарт‑контракт проверяет наличие доступных токенов и подтвержден ли смарт‑контракт владельцем. Далее используются функции покупки и вывода средств, которые описаны ниже по тексту, где безопасность берет на себя стандарт ERC-1155. Он обеспечивает безопасный перевод средств и токенов. В отличие от старого стандарта ERC-721, ERC-1155 более гибок в настройке, что помогает обеспечить и безопасность, и оптимизацию смарт‑контракта, что не мало важно, ведь за затраченные ресурсы на передачу токенов взимается плата, а отсутствие безопасности не идет на пользу смарт‑контракту.
Вместо эфира (Ether) используется самая мелкая единица — Wei.
1 Ether = 1 000 000 000 000 000 000 (1018) Wei
Wei удобнее, чем Ether, когда речь идет об оплате транзакций, не отнимающих много ресурсов.
Функция addListing:
function addListing(address ContractAddress, uint256 price, uint256 tokenId) public{
ERC1155 token = ERC1155(ContractAddress);
require(token.balanceOf(msg.sender, tokenId) > 0, "Caller must own the token");
require(token.isApprovedForAll(msg.sender, address(this)), "Contract must be approved");
listings[ContractAddress][tokenId] = Listing(price, msg.sender);
} AddListing должен работать только для людей, которые имею токен. Чтобы пользоваться другим смарт‑контрактом из своего контракта, необходимо импортировать ERC1155 и задать адрес контракта, с которым нужно взаимодействовать.
Далее идет первая проверка.
require(token.balanceOf(msg.sender, tokenId) > 0, "Caller must own the token");У того, кто вызывает функцию, на самом деле есть быть хотя бы один токен в наличии, который человек хочет продать. Если выполняется условие, то все в порядке, функция вызывается, однако если нет, то выводится ошибка «Запрашивающий должен владеть токеном» и выполнение функции будет прекращено.
Также нужно проверить, одобрен ли смарт‑контракт Trade для перемещения токенов. Сделано это, чтобы неодобренные контракты не могли взаимодействовать с другими смарт‑контрактами.
require(token.isApprovedForAll(msg.sender, address(this)), "Contract must be approved");В случае, если контракт одобрен, то функция выполнится, а если нет, то выведется ошибка «Контракт должен быть одобрен» и функция прекратит выполнение.
listings[ContractAddress][tokenId] = Listing(price, msg.sender);И в конце этой функции задам определенному ID в определенном контракте цену и счет продавца.
Следующая функция purchase:
function purchase(address ContractAddress, uint256 tokenId, uint256 amount) public payable{
Listing memory item = listings[ContractAddress][tokenId];
require(msg.value >= item.price * amount, "insufficient funds sent");
balance[item.seller] += msg.value;
ERC1155 token = ERC1155(ContractAddress);
token.safeTransferFrom(item.seller, msg.sender, tokenId, amount, "");
}Если покупатель хочет что‑то приобрести, то он должен указать номер контракта, ID токена и количество предметов. Также у функции есть приписка payable, обозначающая, что вызов этой функции требует оплаты.
Listing memory item = listings[ContractAddress][tokenId];
require(msg.value >= item.price * amount, "insufficient funds sent");
Тут получаем listing для товара и проводим проверку, что средства были отправлены в нужном количестве для покупки определенного количества товара. В случае если msg.value будет меньше цены товара, умноженного на его количество, то функция прекратит свое выполнение и будет выдана ошибка «Отправлено недостаточно средств».
balance[item.seller] += msg.value;Поступившие с продажи средства записываются на баланс.
И в конце идет передача NFT другому пользователю.
token.safeTransferFrom(item.seller, msg.sender, tokenId, amount, "");
Функция withdraw позволяет забрать средства со счета контракта.
function withdraw(uint256 amount, address payable destAddress) public{
require(amount <= balance[msg.sender], "insufficient funds");
destAddress.transfer(amount);
balance[msg.sender] -= amount;
}Для получения средств на свой счет нужно указать количество средств для перевода и счет, куда нужно перевести средства.
И сразу идет проверка.
require(amount <= balance[msg.sender], "insufficient funds");Если человек хочет взять больше, чем есть на счету контракта, то функция прекратит свою работу и выведется сообщение «Недостаточно средств».
Если же все условия выполнены, то средства перечисляются на указанный счет.
destAddress.transfer(amount);
balance[msg.sender] -= amount;
Если немного помечтать о возможностях смарт‑контрактов, то само по себе их использование облегчает работу аналитика тем, что все транзакции прозрачные и всегда видно кто, что, кому и в каком количестве переводит.
Также смарт‑контракты можно использовать для подтверждения передачи документов с подтверждением получения и отдачи файла без возможности его подмены. Это может помочь контролировать передачу документов и их получение без возможности подмены или подлога другого документа, т.к. всегда будет видно, что был отправлен и получен один и тот же файл, а не какой‑то другой. Но данный способ передачи файлов подвержен тем же проблемам, что и у других смарт‑контрактов. Также существует проблема того, что владельцем блокчейн инфраструктуры является один человек, который может влиять на ее работоспособность.
Заключение
Смарт‑контракт — это очень полезный инструмент, который можно применять в различных областях: от финансов до медицины. Они позволяют автоматизировать процессы и делают их более прозрачными и надежными.
Основными проблемами для их использования является сложность написания и понимания, а также недостаточная юридическая основа для их регулирования. Кроме того, существуют риски, связанные с безопасностью и надежностью смарт‑контрактов и блокчейна в целом.
Для полноценного использования смарт‑контрактов в России необходимо изменить некоторые аспекты законодательства, а также определить ответственность сторон при использовании смарт‑контрактов.
