Ссылка на видео-туториал и подробное объяснение
В этом материале речь пойдет про стандарт EIP-2535, также широко известен как Diamond или Multi-Facet Proxy. Стандарт дает возможность создавать модульные, обновляемые смарт контракты, которые обладают рядом преимуществ перед такими стандартами обновляемых контрактов как Transparent и UUPS.
SOLID это аббревиатура, которая обозначает пять принципов объектно-ориентированного программирования. Эти принципы помогают разработчикам писать качественный и поддерживаемый код. Вот как выглядят эти принципы.
В первой теоретической части мы поговорили про то, что такое обновляемый смарт-контракт и как работают обновления.
Напомним, что большинство вещей всегда требует некоторого обновления. Но тогда данные, хранящиеся в блокчейн, неизменяемы. Так как же тогда смарт-контракты могут быть обновляемыми?
Короткий ответ заключается в том, что смарт-контракты сами по себе не могут изменяться - они постоянны и неизменяемы после развертывания на блокчейне. Но dApp может быть разработан таким образом, чтобы один или несколько смарт-контрактов работали вместе, обеспечивая его "бэкенд". Это означает, что мы можем обновить схему взаимодействия между этими смарт-контрактами. Модернизация смарт-контракта не означает, что мы изменяем код развернутого смарт-контракта, а означает, что мы меняем один смарт-контракт на другой. Мы делаем это таким образом, что (в большинстве случаев) конечному пользователю не придется менять способ взаимодействия с dApp.
В идеальном децентрализованном приложении мы бы хотели хранить все в блокчейне на смарт-контрактах — в хранилище Ethereum: данные не могут быть изменены несанкционированным способом. Но запись какой-либо информации, размером 32 байта обойдется нам в 20000 газа. На момент написания статьи это примерно $0.26, c одной стороны не много, но что если мы хотим хранить в хранилище какой-то значительный массив информации.
В поисках решения данной проблемы экосистема Ethereum дает множество альтернативных вариантов. Как правило, в выбранном пути есть компромисс между доступностью и ценной. Вариант описанный в этой статье может обойтись крайне дешево в реализации, при должном подходе и понимании темы.
В этой статье вы узнаете про Деревья Меркла — специальный алгоритм хэширования данных, благодаря которому, мы сможем сохранить всю полноту необходимой информации, не прибегая к постоянному перезаписыванию содержимого хранилища Ethereum.
Видео-туториал: https://www.youtube.com/watch?v=1aC1_AlCuT8
Сегодня поговорим про такой полезный инструмент как AccessControl от OpenZeppelin, данная библиотека позволит вам регулировать доступ к разного рода функционалу на ваших умных контрактах и не только.
Вы сможете объявлять роли, присваивать эти роли другим пользователям и даже назначать роли для адресов, которые будут назначать другие роли. Это невероятный, гибкий и простой инструмент, с которым должен быть знаком каждый разработчик умных контрактов. А теперь к делу!
Дата "The Merge" приближается, то есть сейчас самое время понять, что же это значит для индустрии в целом и для людей в частности. The Merge — переход эфира с Proof-of-work (PoW) на Proof-of-stake (PoS). Почему это ключевое событие последних лет — разбираемся в этом тексте.
Документация содержит хорошие подробные туториалы,я лишь немного хочу раскрыть их для рунета.
Децентрализованные приложения или dApps - это приложения, которые не полагаются на централизованный сервер или бэкэнд, а используют технологии Web3, такие как блокчейн и оракулы для хранения своей логики и функций бэкэнда, что делает их защищенными от взлома и безопасными.
В этом техническом руководстве вы узнаете как создать простой dApp, который позволяет пользователю получать и хранить текущую цену Ethereum в смарт-контракте. Готовую демонстрационную версию можно найти на GitHub.
Гибридный смарт-контракт — это приложение, состоящее из двух частей:
1) Смарт-контракт — код, который работает исключительно на блокчейне
2) Децентрализованная сеть(и) оракулов — безопасные сервисы вне блокчейн, поддерживающие смарт-контракт.
Эти два компонента беспрепятственно и безопасно взаимодействуют друг с другом, образуя единое гибридное приложение смарт-контракта. В результате код на блокчейне дополняется множеством уникальных и важных способов, открывая множество новых вариантов использования, которые были бы невозможны только с помощью кода на блокчейн из-за технических, юридических или финансовых ограничений.
Важно отметить, что DON по-прежнему обеспечивают очень высокий уровень устойчивости к взлому и надежности, соответствующий гарантиям, предоставляемым смарт-контрактом, но они делают это в изолированной среде вне блокчейн с использованием множества различных подходов к безопасности.
Хотя технологии на основе блокчейна обладают многими качествами, которые отличают их от других вычислительных парадигм, их основным ценностным предложением является генерация криптографической истины. В самом простом смысле, криптографическая истина — это форма вычислений и ведения учета, которая является более точной, доступной, проверяемой и защищенной от взлома, чем существующие альтернативы.
Криптографическая истина происходит от инфраструктуры с минимизацией доверия - кода, который работает именно так, как задумано, потому что его выполнение и проверка не зависят от доверия к незнакомцам или неконтролируемым переменным. Блокчейн генерирует минимизацию доверия, используя криптографию для аутентификации данных и обеспечения хронологического порядка записей, а также децентрализованный консенсус для подтверждения новых записей и сохранения их неизменности. Благодаря этому механизму многосторонние процессы могут отслеживаться и выполняться на общем, достоверно нейтральном бэкенде, который стимулируется к честному управлению.
77+ примеров использования смарт-контрактов
В своей основе, контракты определяют условия и обязанности при обмене чем-либо между двумя и более независимыми сторонами. Исторически так сложилось, что требовался централизованный арбитраж для подтверждения, что условия контракта соблюдаются. Благодаря появлению технологии блокчейн и смарт-контрактов, мы можем заменить централизованных арбитражеров на децентрализованную инфраструктуру, сокращая таким образом риски всех участников и повышая при этом эффективность исполнения.
Однако, из-за механизмов консенсуса в блокчейне, смарт-контракты не имеют встроенной функции или возможности связываться с внешними ресурсами, такими как поставщики данных или сервисы API, как средством верификации исхода реальных событий, происходящих за пределами блокчейна. Это создает так называемую проблему оракулов в блокчейне и является одним из самых серьезных препятствий для исполнения смарт-контрактов.
Чтобы преодолеть отсутствие такого связующего звена, гибридные смарт-контракты используют оракулы в качестве посредника для сбора информации из внешних источников данных, предоставления информации во внешние источники, и для вычислений off-chain. Оракулы обеспечивают не только двустороннюю связь между смарт-контрактами и внешним миром, но и безопасную среду, которая защищает от любого риска единой точки отказа (single point of failure), например, от манипуляции данных или системного сбоя.
Второй уровень (Layer 2, L2) - это любая офф-чейн сеть, система или технология, построенная поверх блокчейна (обычно известного как сеть первого уровня), которая помогает расширить возможности сети базового уровня. Сети второго уровня могут поддерживать любой блокчейн для внедрения таких улучшений, как например, более высокая пропускная способность транзакций.
Одним из основных требований к сети, системе или технологии второго уровня является то, что она наследует безопасность блокчейна, на базе которого она построена. Данные транзакций должны в той или иной форме проверяться и подтверждаться базовой сетью блокчейна, а не отдельным набором узлов. Например, сайдчейны часто не считаются вторым уровнем, поскольку они обычно используют собственные механизмы консенсуса и валидаторы, что приводит к иному набору гарантий безопасности, чем в сети базового уровня.
Для блокчейнов, которые жертвуют масштабируемостью для достижения более высокой децентрализации и безопасности, второй уровень обеспечивает большую пропускную способность транзакций, что может привести к снижению комиссий. Второй уровень можно рассматривать как одно из решений проблемы масштабируемости, обеспечивающее быстрое и масштабируемое исполнение без ущерба для децентрализации и безопасности.
К переполнению относятся числовые вычисления, результат которых превосходит объём памяти, отведённого для хранения. В Solidity диапазон, который может представлять тип данных uint8, составляет 256 чисел от 0 до 255. Когда тип uint8 используется для вычисления 255 + 1, произойдет переполнение, поэтому результат вычислений будет равен 0, минимальному значению, которое может представлять тип uint8.
Если в контракте есть уязвимость переполнения, фактический результат вычисления может значительно отличаться от ожидаемого результата. Это повлияет на нормальную логику контракта и может привести к потере средств. Однако существуют ограничения версии для уязвимости переполнения. В версиях Solidity <0.8 переполнение не будет сообщать об ошибке, но в версиях >= 0.8 переполнение вызовет ошибку.
Cardano и Ethereum — блокчейны, у которых схожие возможности и они неизбежно подвергаются сравнению друг с другом. Постепенно расстановка сил меняется, и о Cardano всё чаще говорят как об «убийце Ethereum». Разбираемся в особенностях технологии Cardano, смотрим, есть ли основания для слухов и рассказываем, почему Cardano может стать мощнее, быстрее и доступнее, чем Ethereum или Bitcoin.
Многим из вас, наверное, известно, что в теории, смарт-контракты в EVM-подобных системах, являются неизменяемыми (immutable), но на практике это уже давно не так. И речь даже не о таких свойствах как Pausable, то есть каких-то переменных состояния контракта, которые могут влиять на его работоспособность, а о более серьезных возможностях изменения бизнес-логики контракта. В этой статье я опишу основные приемы и остановлюсь подробнее на одном из них, на BeaconProxy.
Привет! Для меня некоторое время было удивительно, почему некоторые проекты стали выбирать ERC-721 протокол для выплаты дивидентов, неужели это дань моде? Но поразмыслив немного, я, кажется, пришел к пониманию в чем преимущества этого подхода.
В этой статье не будет деталей о самих протоколах, только мои рассуждения об их применении.
В этой статье я расскажу как с помощью микроконтроллера ESP8266 подключиться к приватной Ethereum сети и вызвать смарт-контракт.
Основная задача:
Изучить, как хранить данные IoT на комбинации on-chain (Ethereum Blockchain) и off-chain хранилищ (IPFS и Ethereum Swarm) в зашифрованном виде и использовать их в модели публикации-подписки в режиме реального времени без использования каких-либо протоколов M2M, таких как MQTT или CoAP. Оценить производительность этой системы с точки зрения количества транзакций, которые могут быть выполнены в секунду и оптимизировать ее работу.
Предыдущие части статьи:
Безопасное хранение данных IoT в частном блокчейне Ethereum. Часть 1
Безопасное хранение данных IoT в частном блокчейне Ethereum. Часть 2
В этой части статьи в главе 6 мы проводим эксперименты по хранению данных с использованием традиционных баз данных, а также предложенной системы с использованием Ethereum Blockchain, IPFS и Swarm. Чтобы понять стоимость безопасности IoT, мы проводим эксперименты по оценке производительности предложенной системы.
В главе 7 мы попытаемся обобщить выводы, сделанные в данной статье, и завершим ее ретроспективным обзором 2 измерений производительности этих систем хранения данных вместе с блокчейном.
Если раньше вы писали программы для обычных приложений, таких как скрипты Web-сайтов или Desktop-приложения, то скорее всего сильно не задумывались о том, чтобы экономить оперативную или дисковую память. В современных компьютерах ее достаточно много, и если речь не идет о каких-либо специальных применениях, то память можно особо не экономить.
Однако при создании программ Solidity нужно учитывать, что стоимость публикации смарт-контракта, а также стоимость вызова его функций может очень сильно зависеть от того, сколько в контракте используется памяти, какой и каким именно образом.
Для измерения стоимости вызова функций смарт-контракта, а также для изучения распределения памяти подготовим стенд в виде проекта Hardhat.
