Платформа Solana является одной из самых необычных. Чтобы понять Solana недостаточно прочитать белую бумагу, нужно ещё понимать как работают распределенные системы, как они синхронизируются, как ведется учёт времени и многое другое.
Перед вами перевод Белой Книге, где описывается основная концепция Solana - доказательство истории (Proof-of-History, PoH).
Материал предназначен людям, которые понимают Ethereum и хотят дополнить свою копилку знаний новой архитектурой блокчейна. Перевод доработан через расширение пояснительной части, там где это показалось полезным.
Данная статья поможет всем интересующимся лучше узнать про технические особенности платформ: Cosmos, Polkadot, Avalanche.
Эти платформы нацелены на горизонтальное масштабирование с асинхронной гетерогенной сетевой моделью, где предметноспецифичные блокчейны сосуществуют в рамках общей сетевой модели и при необходимости взаимодействуют друг с другом. У каждой платформы есть свои собственные подходы и компромиссы по достижению межцепочной экономической безопасности. Они нацелены на создание блокчейнового междусетья, которое способно вместить не сотни тысяч (как сегодня), а миллионы активных пользователей в день и полноценно реализовать концептуальное видение Web3, принадлежащего и контролируемого пользователями.
Цель этой статьи - помочь разработчикам, исследователям, предпринимателям и всем, кто изучает блокчейн и децентрализованные системы, понять эту смену парадигмы в блокчейн сетях.
“Библиотеки можно рассматривать, как неявные базовые смарт-контракты для смарт-контрактов, которые их используют” из документации языка Solidity
Библиотека в Solidity - это тип смарт-контракта, содержащий многократно используемый код. После развертывания в блокчейне (развёртывается только один раз) ему присваивается определённый адрес, а его свойства / методы могут многократно использоваться другими смарт-контрактами в сети Ethereum.
Они позволяют вести разработку более модульным способом. Иногда полезно думать о библиотеке как о куске кода, который можно вызвать из любого смарт-контракта без необходимости его повторного развертывания.
Наша реализация почти готова: мы реализовали все основные механики смарт-контракта Биржи, включая функции ценообразования, обмена, выпуска LP-токенов и сбора комиссии. Похоже, что наш клон завершен, однако нам не хватает смарт-контракта Фабрики.
Сегодня мы реализуем его и наш клон Uniswap V1 будет завершен.
Продолжаем серию статей про язык Solidity и платформу Ethereum. В этой статье будет рассказываться про адреса в Ethereum. Статья была написана в августе 2019 года, с той порой язык изменился, поэтому несоответствия в описании автора были исправлены.
Во введении проведено сравнение Ethereum адресов с почтовыми адресами в реальном мире.
Техническая часть начинается с раздела "Что такое (технически) адрес в Ethereum?"
Это вторая часть серии статей о программировании DeFi смарт-контрактов. В предыдущей части мы впервые соприкоснулись с Uniswap, его основной механикой и начали создавать контракт Биржи. Контракт Биржи может принимать ликвидность от пользователей, рассчитывать суммы вывода и выполнять обмены.
Сегодня мы собираемся закончить реализацию Uniswap V1. Хотя это не будет полная копия Uniswap V1, но она будет иметь все основные функции.
Эта часть наполнена новым кодом, поэтому давайте перейдем непосредственно к нему.
Лучший способ научиться чему-то - научить других. Второй лучший способ научиться чему-то - сделать это самому. Я решил объединить эти два способа и научить себя и вас программировать DeFi сервисы на Ethereum (и любых других блокчейнах, основанных на EVM - Ethereum Virtual Machine).
Мы сосредоточимся на том, как работают эти сервисы, попытаемся понять экономическую механику, которая делает их такими, какие они есть (а все они основаны на экономической механике). Мы будем выяснять, разбирать, изучать и создавать основные механизмы DeFi.
В документации Solidity модификаторы определяются следующим образом:
Модификаторы можно использовать для изменения поведения функций декларативным способом.
Из этого определения можно понять, что модификатор направлен на изменение поведения функции, к которой он присоединен.
Например, автоматическая проверка условий перед выполнением функции (для этого модификаторы в основном и используются).
Модификаторы уменьшают избыточность кода. Вы можете повторно использовать один и тот же модификатор в нескольких функциях, если вы проверяете одно и то же условие в смарт-контракте.
Комментарий от переводчика: статья по меркам Ethereum и языка Solidity относительно старая, аж 2018 года, но ряд идей и подходов будут полезны начинающим.
В настоящее время я работаю над Dapp, первый крупный этап разработки которого подходит к концу. Поскольку издержки на транзакции всегда являются большой проблемой для разработчиков, я хочу использовать эту статью, чтобы поделиться некоторыми соображениями, которые я получил за последние пару недель/месяцев в этой области с точки зрения оптимизации.
