Всем привет! Относительно недавно выпустили LayerZero V2 и я решил разобрать новую версию OFT. В данной статье рассмотрим основные функции OFT V2, развернем в двух тестовых сетях свой токен и переведем токены из одной сети в другую.

Начало

Для начала я создам проект hardhat

npx hardhat 

Дальше установим пакеты layerzerolabs

npm install @layerzerolabs/lz-evm-oapp-v2

Если данный способ вам не удобен, то просто копируйте контракт MyOFTV2 ниже в remix, потом компилируйте и все зависимости установятся сами. Но не забудьте включить optimizer при компиляции.

Теперь создадим свой контракт MyOFTV2.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.23;
import "@layerzerolabs/lz-evm-oapp-v2/contracts/oft/OFT.sol";
contract MyOFTV2 is OFT{    
    constructor(        
      string memory _name,        
      string memory _symbol,        
      address _lzEndpoint,        
      address _delegate    
    ) OFT(_name, _symbol, _lzEndpoint, _delegate){        
        _mint(msg.sender, 1000 * 10 ** decimals());    
    }
}

По факту мы просто наследуем контракт OFT и минтим на наш адрес токены для перевода в будущем.

Уже можно деплоить данный контракт в двух сетях и выполнять все наши задачи, но давайте рассмотрим что происходит под капотом, когда мы хотим перевести токены из одной сети в другую.

Обзор функций L0.

Начнем с самого интересного и это то, как происходит cross chain swap токенов.

Если мы перейдем в контракт OFT, то увидим две функции _debit и _credit. Данные функции переопределены из ядра OFTCore.

Это нужно для того, чтоб мы могли добавить свою логику при переводе токенов и не изменять ядро.

 function _debit(
        uint256 _amountLD,
        uint256 _minAmountLD,
        uint32 _dstEid
    ) internal virtual override returns (uint256 amountSentLD, uint256 amountReceivedLD) {
        (amountSentLD, amountReceivedLD) = _debitView(_amountLD, _minAmountLD, _dstEid);

        _burn(msg.sender, amountSentLD);
    }
    function _credit(
        address _to,
        uint256 _amountLD,
        uint32
    ) internal virtual override returns (uint256 amountReceivedLD) {
        
        _mint(_to, _amountLD);
        return _amountLD;
    }

Данные две функции предназначены для того, чтоб мы могли использовать механизм перевода токенов из одной сети в другую. Команда L0 это решила при помощи функций _mint и _burn. Смысл в том, чтоб при переводе токенов из Сети A мы сжигали токены из кошелька сети A и дальше чеканили токены в сети B на наш кошелек в сети B.

Продвигаемся глубже и заходим в контракт OFTCore. Там есть достаточно много интересного, но пройдемся по самому главному.

sharedDecimals это функция которая дает нам возможность установить общий decimals для не evm сетей, так как некоторые сети имеют max uint64, что меньше чем evm ethereum max uint256 например.

 function sharedDecimals() public pure virtual returns (uint8) {        
     return 6;    
 }

функции send и _lzReceive очень важны во время перевода, так как они взаимодействуют с endpoint L0.

 function send(
        SendParam calldata _sendParam,
        MessagingFee calldata _fee,
        address _refundAddress
    ) external payable virtual returns (MessagingReceipt memory msgReceipt, OFTReceipt memory oftReceipt) {
        (uint256 amountSentLD, uint256 amountReceivedLD) = _debit(
            _sendParam.amountLD,
            _sendParam.minAmountLD,
            _sendParam.dstEid
        );

        (bytes memory message, bytes memory options) = _buildMsgAndOptions(_sendParam, amountReceivedLD);

        msgReceipt = _lzSend(_sendParam.dstEid, message, options, _fee, _refundAddress);
		oftReceipt = OFTReceipt(amountSentLD, amountReceivedLD);

        emit OFTSent(msgReceipt.guid, _sendParam.dstEid, msg.sender, amountSentLD);
    }

    function _lzReceive(
        Origin calldata _origin,
        bytes32 _guid,
        bytes calldata _message,
        address /*_executor*/, // @dev unused in the default implementation.
        bytes calldata /*_extraData*/ // @dev unused in the default implementation.
    ) internal virtual override {
        address toAddress = _message.sendTo().bytes32ToAddress();
  		uint256 amountReceivedLD = _credit(toAddress, _toLD(_message.amountSD()), _origin.srcEid);

        if (_message.isComposed()) {
            bytes memory composeMsg = OFTComposeMsgCodec.encode(
                _origin.nonce,
                _origin.srcEid,
                amountReceivedLD,
                _message.composeMsg()
            );

            endpoint.sendCompose(toAddress, _guid, 0 /* the index of the composed message*/, composeMsg);
        }

        emit OFTReceived(_guid, _origin.srcEid, toAddress, amountReceivedLD);
    }

Endpoint - это специальные смарт-контракты L0, которые принимают обрабатывают и отправляют наши транзакции между сетями. Это если коротко.

И так функции send и _lzReceive работают с endpoint, но что именно они отправляют и принимают?

В протоколе L0 есть такое понятие options (ранее вы могли слышать про них как adapterParams).

Options - это способ передачи информации между сетями, так как сеть B не имеет ни какого понятия о состоянии сети A. Есть разные виды options, которые предоставляет нам L0. Нас же интересует lzReceiveOption. Эти параметры используются для передачи газа, который мы будем тратить для доставки сообщения и передачи msg.value, если это необходимо.

Для их генерации команда L0 предоставила нам уже готовые функции. Их можно посмотреть в документации и открыть в remix

Из важного, раньше наши options могли начинаться с так называемых магических числе 0001 и 0002 (идентификаторы options), но они устарели и их больше не используют. Теперь только 0003.

Я для примера сгенерировал options с gas 200000 и msg.value 0. Это такие стандартные параметры, которые даже в документации L0 предоставляются.

 0x00030100110100000000000000000000000000030d40

функция send вызывается при отправке сообщения или в нашем случае токенов. Все наши параметры, которые мы передаем собираются и отправляются в _lzSend функцию, которая в свою очередь выполняя некоторые проверки и отправляет наше сообщение в endpoint.

Endpoint принимает наш запрос, обрабатывает и отправляет в сеть B транзакцию, вызвав для этого функцию _lzReceive.

О входных значениях кроме options для функции send поговорим чуть позже.

Функция _lzReceive уже будет вызываться конечной точкой (endpoint) в нашем контракте в сети B , и обрабатывать (расшифровывать) запакованные options. И таким образом наш перевод токенов будет завершен.

Также у нас появляются новые понятия как SD LD. Грубо говоря это выравнивание по decimals разных сетей при помощи sharedDecimals. Как раз поэтому мы увидим новый параметр функции send, чуть позже.

function _toLD(uint64 _amountSD) internal view virtual returns (uint256 amountLD) {
        return _amountSD * decimalConversionRate;
    }
    function _toSD(uint256 _amountLD) internal view virtual returns (uint64 amountSD) {
        return uint64(_amountLD / decimalConversionRate);
    }

Если мы продвинемся дальше и перейдем в контракт OAppOptionsType3

То там будет новая интересная функция setEnforcedOptions

function setEnforcedOptions(EnforcedOptionParam[] calldata _enforcedOptions) public virtual onlyOwner {
        for (uint256 i = 0; i < _enforcedOptions.length; i++) {
             _assertOptionsType3(_enforcedOptions[i].options);
            enforcedOptions[_enforcedOptions[i].eid][_enforcedOptions[i].msgType] = _enforcedOptions[i].options;
        }

        emit EnforcedOptionSet(_enforcedOptions);
    }

Данная функция позволяет жёстко установить параметры options, то есть при вызове функции send, данные условия будут вызываться каждый раз.

Теперь функция setPeer

function setPeer(uint32 _eid, bytes32 _peer) public virtual onlyOwner {
        peers[_eid] = _peer;
        emit PeerSet(_eid, _peer);
    }

Данная функция позволяет установить связь между нашими контрактами в разных сетях. В принципе все.

Это было очень кратко и поверхностно, но для общего понимания процесса думаю достаточно, возможно в будущем разберем весь протокол более подробно.

Также разумеется я рассмотрел не все функции, но тем не менее давайте развернем наш OFT и выполним перевод.

Деплой

Так как я работаю в hardhat, то я и деплой буду выполнять через hardhat. Если вы работаете в remix, то вам будет нужно подключить свой метамаск в нужной сети и деплоить уже там.

НО я советую научиться пользоваться hardhat и делать все там, потому что это более профессионально и быстрее, если научиться.

Скрипт для деплоя в hardhat

В файл deploy.js в папку scripts вставляем данный код.

const hre = require("hardhat");

async function main() {

  const [deployer] = await ethers.getSigners();

  console.log("Deploying contracts with the account:", deployer.address);

  console.log("Account balance:", (await deployer.getBalance()).toString());
  
  const token = await ethers.deployContract("MyOFTV2", ["Token name", "Token symbol", "0x6edce65403992e310a62460808c4b910d972f10f", "Your wallet address"]);

  console.log("Token address:", await token.address);
  
}

main()
  .then(() => process.exit(0))
  .catch((error) => {
    console.error(error);
    process.exit(1);
  });ocess.exit(1);
  });

Я тут ни чего особенного не делаю, просто деплой.

Параметры конструктора:

Первый, это название токена

Второй, это символ токена

Третий, это адрес endpoint

Четвертый, это адрес владельца контракта, то есть наш адрес кошелька.

Адреса endpoint

Я тут покажу два адреса, работать буду в них.

Sepolia (Testnet)​

endpointId: 40161
endpoint: 0x6edce65403992e310a62460808c4b910d972f10f

Mumbai (Polygon Testnet)​

endpointId: 40109
endpoint: 0x6edce65403992e310a62460808c4b910d972f10f

Как можно заметить адреса одинаковые, L0 позаботились о нас.

endpointId (eid) это идентификатор конечной точки (ранее chainID). По ним endpoint понимает в какую сеть нужно отправить транзакцию.

hardhat config

  require("@nomicfoundation/hardhat-toolbox");
require("@nomiclabs/hardhat-etherscan");
const PRIVATE_KEY = "YOUR_KEY"
module.exports = {
  solidity: {
    compilers: [
      {
        version: "0.8.23",
        settings: {
          optimizer: {
            enabled: true,
            runs: 200,
          },
        },
      },
    ],
  },
  networks: {
      hardhat: {
        forking: {
          url: "https://eth-mainnet.g.alchemy.com/v2/API",
          blockNumber: 18928295
        },
      },
      main: {
        url: "https://eth-mainnet.g.alchemy.com/v2/API",
        chainId: 1,
        accounts: [
          PRIVATE_KEY
        ],
      },
      mumbai: {
        url: "https://polygon-mumbai.g.alchemy.com/v2/API",
        chainId: 80001,
        accounts: [
          PRIVATE_KEY
        ],
      },
      sepolia: {
        url: "https://eth-sepolia.g.alchemy.com/v2/API",
        chainId: 11155111,
        accounts: [
          PRIVATE_KEY
        ],
      },
  
      
    },
    etherscan:{
      apiKey: "API",
    }
  }

Берите его и вставляйте в hardhat.config.js

Устанавливайте свои параметры в пустые места:

PRIVATE_KEY - приватник вашего кошелька метамаск. Как его брать думаю все знают.

API для сетей sepolia и mumbai - я использую alchemy, но вы можете брать откуда вам удобно. Как создать свое приложение в alchemy можно легко найти в интернете или у меня в прошлых статьях.

Дальше есть такой интересный параметр etherscan в конце конфига. Он нужен для верификации наших контрактов. Его можно взять, если вы зайдете на ehterscan mainnet и poligonscan mainnet и авторизуетесь. Потом зайдете в свой профиль, и там найдете вкладку API Keys. Заходим и создаем.

И так, вы должны были создать 2 api ключа для etherscan и polygonscan, которые мы будем потом вставлять по очереди и верифицировать контракт.

Возможно это кажется достаточно сложным, но уверяю вас, если вы это сделаете, то вам больше не придется по пол часа тыкать в remix, чтоб верифицировать контракты, а просто одной командой в секунду подтверждать.

Данные настройки конфига и деплой скрипт можно использовать дальше в своих проектах просто копипастом и не париться.

Теперь команды деплоя.

Если вы работаете в remix, то просто нажимаем кнопку deploy, предварительно подключив метамаск и выбрав нужную сеть. И не забываем что при компиляции вы должны были включить optimizer.

Для hardhat:

Открываем терминал, и мы должны находится в директории своего проекта.

Выполняем 2 команды:

Sepolia:

npx hardhat run scripts\deploy.js --network sepolia 

Mumbai

npx hardhat run scripts\deploy.js --network mumbai 

Если вы сделали все правильно, указали в конфиге все параметры, то у вас должно все получиться. Сохраняем адрес развернутого контракта, и можно его открыть в etherscan и polygonscan

Теперь верификация. Самое приятное, это то что нам не нужно использовать параметр все в одном файле (flatten), как это обычно делают при верификации через remix, и отображаться в etherscan каждый контракт будет отдельно, не как один огромный файл с кучей контрактов в нем.

Если вы использовали remix, то вам нужно сделать контракт MyOFTV2 flatten и перейти в etherscan. Там уже делать верификацию через него. Как это делать я уже показывал в прошлых статьях или вы можете найти в интернете.

Команды для верификации hardhat:

Sepolia:

Вставляем в hardhat.config.js api keys от etherscan в параметр etherscan и выполняем команду

npx hardhat verify --network sepolia Address deploy contract "MyOFTV2" "MOV" "0x6edce65403992e310a62460808c4b910d972f10f" "0xA788815dDDEfb278F06C248b03e7bBc1e5Ed6009" 

Mumbai:

Вставляем в hardhat.config.js api keys от polygonscan в параметр etherscan и выполняем команду

npx hardhat verify --network mumbai address deploy contract "MyOFTV2" "MOV" "0x6edce65403992e310a62460808c4b910d972f10f" "0xA788815dDDEfb278E06F248b03e7bBc1e5Ed6009" 

Заменяем фразу Address deploy contract на адрес вашего контракта в сети sepolia и mumbai соответственно.

Также передаем параметры конструктора, я тут для примера написал свои, но вы меняйте их на свои, которые вы указывали во время деплоя. Можете скопировать их из deploy.js скрипта своего

Если вы все сделали правильно, то у вас должно было все получиться и теперь можно открывать etherscan и polygonscam и там уже работать.

Перевод токенов

Для начала открываем наш контракт в etherscan sepolia

Переходим во вкладку Write Contract и подключаем кошелек, который мы использовали во время деплоя контрактов.

Далее находим функцию setPeer

Вставляем eid mumbai и адрес контракта в сети mumbai.

eid: 40109
bytes32: 0x000000000000000000000000b68C9f0c26c0911A81A3e33338abb28245F935Ef

Теперь подключайтесь к polygonscan mumbai и делаем тоже самое, но указываем параметры сети sepolia

eid: 40161
bytes32: 0x0000000000000000000000009fb877E638F9e6De44D3043a74077eA8C8395537

Теперь возвращаемся в наш контракт в сети sepolia

И нам нужно установить enforcedOptions, вызываем функцию setEnforcedOptions

[{eid: 40109,msgType: 1,options: 0x00030100110100000000000000000000000000030d40},{eid: 40109,msgType: 2,options: 0x00030100110100000000000000000000000000030d40}]

Здесь мы передаем массив структур с двумя элементами, можно скопировать мой и просто вставить.

структура состоит из 3 параметров:

1) eid уже известный нам параметр
40109 для mumbai

2) msgType тут есть только 2 типа сообщения и мы оба укажем, хоть будем пользоваться только SEND

SEND = 1

SEND_AND_CALL = 2

3) Это наши сгенерированные options ранее. 0x00030100110100000000000000000000000000030d40

Теперь главное мы выполняем вызов функции send

Наконец разбираемся с параметрами функции send:

msg.value: 0.002 
dstEid: 40109 
to: 0x000000000000000000000000a788815dddefb278e06c248b03e7bbc1e5ed6009
amountLD: 543212345432123
minamountLD: 543000000000000
extraOptions: 0x
composeMsg: 0x
oftCmd: 0x
nativeFee: 2000000000000000
lzTokenFee: 0
_refundAddress: 0xA788815dDDEfb278E06C248b03e7bBc1e5Ed6009

msg.value - это сумма на оплату транзакции в другой сети, 0.02 будет нам достаточно

dstEid - уже знаем

to - адрес на который мы переводим токены в другой сети

amountLD - количество токенов

minamountLD - минимальное количество токенов, которое будет отправлено, так как мы помним что у нас есть sharedDecimals которые, выравнивают decimals для не evm сетей, и так как мы указали 6, а у нашего токена decimals 18, то разумеется будет нужно выравнивать цену и мы сами можем указать это число. Как это сделать? Просто указать до 6 знаков amount. Так как у меня amount только 15 знаков, то и соответственно максимальное возможное число это 543000000000000 в minamountLD

extraOptions - дополнительные опции которые склеиваются с enforcedOptrions если это требуется. Главное не дублируйте их, а то 2 раза выполните транзакцию.

composeMsg - дополнительное сообщение или логика, которое выполниться после перевода, если это требуется

nativeFee - ВАЖНО указать тоже число что и msg.value

lzTokenFee - если вы хотите оплатить в токенах L0, иначе 0

_refundAddress - адрес куда придут средства в случае неудачно транзакции.

Теперь вызываем функцию send и смотрим на нашу транзакцию в LayerZero scan

Для этого вставляйте в поиск L0 scan хэш вашей транзакции сети sepolia

Вот допустим моя транзакция которую я только что указал,

Тут мы можем увидеть хэш транзакции в сети sepolia и потом хэш транзакции в сети mumbai, дожидаемся Status: Delivered и проверяем баланс токенов в сети mumbai

Если мы зайдем в наш контракт в mumbai и вызовем функцию balanceOf, то увидим, что баланс токенов у нас увеличился, и как мы видим сумма была выравнена. (P.S там 643,а не 543, потому что я уже переводил до этого токены)

Особенность OFT V2 как можно заметить это sharedDecimals, и если вы работаете в evm сетях подобных ethereum, то лучше ставить sharedDecimals = 18.

На этом думаю можно закончить. Сегодня мы не только выполнили перевод токенов между сетями, но и разобрались что именно происходит в этот момент. Всем удачи.

Полезные ссылки:

Различие OFT V1 и OFT V2

Документация L0

моя транзакция на L0 scan

Мой телегам канал

Привет всем! В данной статье я попытаюсь рассказать, как работает zkSync под капотом, как формируются блоки и транзакции. Все это будет представлено простым языком для понимания широкой аудитории.

На чем основан zkSync:

Доказательства нулевого разглашения (ZKPs):

• Определение: Это криптографические протоколы, которые позволяют доказать, что утверждение верно, не раскрывая информацию о самом утверждении.
• Применение: ZKP используются для повышения приватности, например в блокчейне, где они подтверждают действительность утверждения, не раскрывая основных данных.

ZK Rollups:

• Определение: Это масштабируемое решение для блокчейнов, которое повышает пропускную способность и снижает затраты на транзакции, перемещая обработку большей части транзакций вне цепи блоков. Они используют доказательства нулевого разглашения для обеспечения криптографических гарантий о действительности транзакций, не раскрывая деталей транзакций.
• Принцип работы: В ZK Rollups большинство транзакций происходит вне цепи блоков, и лишь краткая информация периодически отправляется на основной блокчейн. Затем доказательства нулевого разглашения используются для подтверждения действительности вычислений вне цепи.

ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge):

• Определение: Это конкретный тип систем доказательств нулевого разглашения, обеспечивающий лаконичные и неинтерактивные доказательства знания.
• Применение: ZK-SNARKs известны в блокчейн-приложениях, таких как Zcash, где они позволяют проверять транзакции без раскрытия отправителя, получателя или суммы транзакции.
• Принцип работы: ZK-SNARKs используют математические конструкции, такие как эллиптические кривые и алгебраическая геометрия, для обеспечения эффективных и безопасных доказательств нулевого разглашения. Их краткость особенно ценна в блокчейне, где эффективность критически важна.

Подробнее про данные концепции можно узнать здесь.

Итак, про технологии я кратко рассказал, давайте уже ближе к теме:

Основные компоненты zkSync:

Смарт-контракты:

• Смарт-контракт L1 и L2: Обеспечивают взаимодействие между L1 (основной блокчейн) и L2 (сайдчейн zkSync).
• Мостовые контракты: Организуют перемещение активов между L1 и L2.
• Контракт объединения zkSync на Ethereum: Объединяет L2-активы в контракты на L1.
• Контракт верификатора доказательства L1: Проверяет доказательства от серверной части перед добавлением блоков в L1.

Серверная часть (Узел сети zkSync):

• Мониторинг смарт-контракта L1: Отслеживает депозиты или приоритетные операции.
• Поддержание мемпула: Принимает транзакции (Postgres).
• Извлечение транзакций из мемпула: Выполняет транзакции на виртуальной машине и изменяет состояние.
• Генерация блоков цепочки zkSync: Подготавливает схемы для блоков, подлежащих проверке.
• Отправка блоков и доказательств в смарт-контракт L1: Публикация API web3, совместимого с Ethereum.

ZkEvm:

• Виртуальная машина: Выполняет смарт-контракты способом, совместимым с вычислениями с нулевым разглашением данных.

Приложение Prover:

• Приложение для проверки: Принимает блоки и метаданные, создает для них доказательство достоверности zk.

Уровень хранения:

• Различные компоненты и подкомпоненты взаимодействуют через уровень хранения БД.

State Keeper:

• Доступ к хранилищу ВМ для State Keeper: Компонент, отвечающий за обработку выполнения транзакций и создание миниблоков и пакетов L1.

Данный список отображает главные механизмы работы, но я не буду останавливаться на каждом компоненте подробно, только на неочевидных моментах.

Генерация блоков цепочки zkSync:

Из документации zksync:

Блоки L2 в настоящее время не играют основной роли в системе. Это функция совместимости для поддержки инструментов, таких как Metamask, ожидающих частого изменения блока. Это позволяет инструментам предоставлять пользователям обратную связь, подтверждая, что их транзакция была добавлена.

Грубо говоря отправив транзакцию, вы моментально увидите ее выполнение, но она не будет еще добавлена в основную цепочку и сохранена на L1.

Основные шаги для завершения транзакции:

• Выполнить транзакцию в блоке State Keeper & Seal
• Создать свидетеля
• Создайте доказательство
• Проверка доказательства на L1

Выполнить транзакцию в блоке State Keeper & Seal

Задача State Keeper — брать транзакции из мемпула и помещать их в пакет L1. Это делается с помощью process_l1_batch() метода (метод написан на языке Rust)

Этот метод берет следующую транзакцию из мемпула (которая может быть либо L1Tx, либо L2Tx, но L1Tx всегда имеет приоритет и они выполняются первыми), выполняет ее и проверяет, готов ли пакет L1 к запечатыванию

L1Tx - это в основном депозиты или выводы средств из системы.

Теперь про пакеты L1

На данной картине очевидно показано как работает запечатывание пакетов L1.

У нас есть транзакции L1tx и L2tx, транзакции L1tx разумеется идут в приоритете, и все эти транзакции собираются в миниблоки L2, эти миниблоки в свою очередь собираются в пакет L1, который как мы знаем State Keeper готовит к запечатыванию.

У пакетов L1 (State Keeper) есть ограничение в 750 транзакций и еще ряд ограничений связанных с газлимитом и публикационными данными в 120кб

После того как State Keeper собрал пакет L1, нужно создать свидетеля

Так как State Keeper выполняет операции, но не заявляет об их выполнении открыто, нам нужно создать доказательство zk или перейти на новый этап выполнения транзакции

Создать свидетеля.

Если говорить простым языком, то нам нужно доказать заранее, что операция, которую мы выполнили, возможна. Алгоритм берет одну транзакцию и проверяет ее.

Например:

Я хочу присвоить a = 44

В обычном случае мы бы просто присвоили переменную считав данные из хранилища.

Но в нашем случае мы должны проверить пути меркла и создать набор хешей, чтоб показать что эта операция возможна, и что мы не обманываем.

Еще более простым языком мы должны найти текущий корень дерева меркла и взять его хеш, после чего взять наше число 44 и доказать ее существование в хранилище, то есть проверить, что хеш дерева меркла не поменялся. Дальше мы должны создать новый хеш, который показывает что мы присвоили a=44 и таким образом докажем, что 44 существует в хранилище и создаем новый хеш в дереве меркла

Если вы не знакомы с деревьями и деревом меркла, то этот этап будет трудно понять, поэтому советую ознакомиться.

И так:

Благодаря такой системе мы создаем свидетеля, который говорит нам, что да, транзакции возможны, и мы ему верим.

Следующий этап, это генерация доказательства

Создайте доказательство

Тут мы берем наши данные свидетеля из прошлого пункта и разбиваем его на более мелкие части, создаем из них полиномы (математическое выражение), после чего в силу вступают zkSNARK. Чтоб сгенерировать само доказательство мы вычисляем это выражение в разных точках, и для этого требуется очень большие вычислительные мощности.

Вот наглядный пример как происходит вычисление доказательства вида ZK

Проверка доказательства на L1

Попробую объяснит на палацах:

У нас есть 4 переменных:

• C : это ключи проверки
• In : представляет корневой хеш перед блоком транзакции.
• Out : представляет корневой хеш после блока транзакции.
• P : Это доказательство, предоставленное доказывающим.

Логика этого заключается в том, что совпадающее доказательство «P» может существовать только в том случае, если C(In) == Out.

Мы просто говорим, что наше вычисленное доказательство P имеет смысл, если наши хеши In и Out согласованы при помощи ключа C.

Главная задача этого пункта - сохранять синхронизацию L1 и L2

Все данные в технологии ZK Rollups хранятся как calldata и zksync не исключение

Смарт-контракты:

Рассмотрим различие ВМ эфира и zksync

Поток Эфириума:

1. Написание Кода в Solidity: Начинаем с написания смарт-контракта на языке Solidity.
2. Компиляция с Solc: Используем компилятор solc для преобразования кода в байт-код EVM, байт-код развертывания и ABI.
3. Развертывание на Ethereum: Отправляем байт-код развертывания на адрес 0x000 в сеть Ethereum, где происходит выполнение байт-кода развертывания и размещение контракта по уникальному адресу.
4. Взаимодействие с Контрактом: Теперь можем отправлять транзакции на адрес контракта, используя ABI для правильной передачи аргументов функций.
5. Выполнение на EVM: Весь байт-код выполняется на Ethereum Virtual Machine (EVM), имеющей стек, память и хранилище.

Поток zkSync:

1. Система Проверки (zkEVM): Основная часть zkSync - это система проверки. Используется виртуальная машина zkEVM, имеющая другой набор кодов операций и регистров.
2. Компиляция с zk-solc: Используем отдельный компилятор zk-solc для создания байт-кода, совместимого с zkEVM.
3. Развертывание в zkSync: Отправляем скомпилированный код в zkSync, где его выполнение происходит на zkEVM. Новые контракты могут быть развернуты в системе контрактов zkSync.
4. Преимущества отдельного компилятора: Использование отдельного компилятора позволяет более быстрые и дешевые модификации, а также увеличивает гибкость системы.

Таким образом, в случае zkSync, используется отдельная виртуальная машина (zkEVM) и компилятор (zk-solc) для обеспечения возможности эффективного проведения доказательств в системе проверки.

Сжатие байт кода смарт-контрактов

Поскольку zkSync являемся накопителем — все байт-коды, которые контракты используют в нашей цепочке, должны быть скопированы в L1 (чтобы при необходимости цепочку можно было реконструировать из L1).

Учитывая необходимость сократить используемое пространство, байт-код сжимается перед отправкой в ​​L1.

На высоком уровне байт-код разбивается на коды операций (размером 8 байт), присваивается двухбайтовый индекс, а вновь сформированная последовательность байтов (индексы) проверяется и отправляется на L1

000000000000000A
000000000000000D
000000000000000A
000000000000000C
000000000000000B
000000000000000B
000000000000000D
000000000000000A

Словарь

0 -> 0xA (count: 3)
1 -> 0xD (count: 2, first seen: 1)
2 -> 0xB (count: 2, first seen: 4)
3 -> 0xC (count: 1)

Сжатый байткод

0008 0000
000000000000000A
000000000000000D
000000000000000B
000000000000000C

0000 0001 0000 0003 0002 0002 0001 0000

Дальше данный байт-код проходит проверку и публикуется на L1. Для этого есть отдельный смарт-контракт.

На самом деле данные или транзакции, которые мы просто отправляем, тоже сжимаются своими алгоритмами.

Также есть таблица, где показаны основные коды операций

Как вы могли заметить я часто упоминал серверную часть, это нам говорит, что zkSync на данный момент не полностью децентрализованный протокол, и поэтому может прослеживаться цензура, но как нам заверяют разработчики, это не произойдет и они стремятся перейти к полностью децентрализованной системе. Будем ждать.

Как происходят обращение к смарт-контрактам L1:

ZkSync используем настройку DiamondProxy, которая позволяет иметь фиксированную неизменяемую точку входа (DiamondProxy), которая перенаправляет запросы к различным контрактам (кранам), которые могут быть независимо обновлены и/или заморожены.

Diamond

Технически этот смарт-контракт L1 действует как соединитель между Ethereum (L1) и zkSync (L2). Этот контракт проверяет подтверждение действительности и доступность данных, обрабатывает связь L2 <-> L1, завершает переход состояния L2 и многое другое.

На уровне L2 также развернуты важные контракты, которые также могут выполнять логику, называемую системными контрактами . Использование связи L2 <-> L1 может повлиять как на L1, так и на L2

На самом деле в zkSync есть кучу разных контрактов и каждый выполняет свою роль, но если я начну о всех них рассказывать, то на это уйдет слишком много времени, поэтому оставлю данную тему на другой раз.

На этом все. Я постарался донести вам достаточно трудную информацию, которую сложно осознать с первого раза, так что если вы что то поняли, уже хорошо. Теперь вы знаете как на самом деле происходят транзакции и формирования блоков в zkSync это далеко не все решения, которые есть в zkSync, но для понимания я думаю достаточно. На самом деле очень сильный проект, который подает большие надежды.

Ресурсы:

Документация zkSync

Мой телеграмм канал

Всем примет. Сегодня говорим об экземплярах контрактов и их особенностях. Покажу как работать с ними и их подводные камни.

Для чего вообще нам нужны экземпляры контрактов?

Взаимодействия с контрактом:

Самое очевидное, это для взаимодействия с контрактом.
Например: у нас есть контракт А, который реализует методы, и мы хотим их использовать у себя в контракте.

Раздельная функциональность:

Иногда наш код удобно разделить на части, но как это было у меня в прошлом проекте, наследование использовать не получиться, потому что код слишком большой и в следствии смарт-контракт не может быть развернут. В таком случае нам приходит на помощь экземпляры контрактов.

Управление доступом:

Также удобно создавать ролевую систему, тоже было показано в прошлом проекте, где вызов функций смарт-контракта A мог только смарт-контракт B

В общем это очень сильный инструмент для разработки, без которого нельзя. Важно понимать, что мы можем брать экземпляр только развернутого контракта. Поэтому мы передаем адрес контракта для его инициализации.

Пример использования:

Самый очевидный и популярный пример:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.9;
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
contract A{    
    IERC20 token;    
    constructor(address _token){        
        token = IERC20(_token);    
    }
}

В данном примере я объявляю переменную типа интерфейс IERC20

token = IERC20(_token); - эта строка кода создает переменную token и присваивает ей значение, являющееся экземпляром смарт-контракта, реализующего интерфейс IERC20

address _token - это адрес любого токена ERC20.

Таким образом мы получаем доступ ко всем методам токена стандарта ERC20, адрес которого мы передали.

Более сложный пример:

 // SPDX-License-Identifier: MITpragma solidity ^0.8.9;
contract FirstContract{    
    struct human{        
        string name;        
        uint age;    
    }    
    address public owner;    
    mapping(address=>human) public humans;
    function setName(string calldata _name) public{        
        humans[msg.sender].name = _name;    
    }    
    function setAge(uint _age) public{        
        humans[msg.sender].age = _age;    
    }
}

 // SPDX-License-Identifier: MIT
 pragma solidity ^0.8.9;
 import "./test.sol";
contract B{    
    FirstContract public firstContract;    
        constructor(address _A){        
        firstContract = FirstContract(_A);    
    }
    function check() public view returns(string memory, uint){        
        (string memory _name, uint _age) = firstContract.humans(msg.sender);        
        return (_name, _age);    
    }    
    function checkOwner() public view returns(address){        
        return firstContract.owner();    
    }
}

Если у нас есть структура, маппинг или переменная, то обращаться мы можем к ней только под видом функции.

firstContract.owner() - для того, чтоб узнать содержимое переменной нам нужно обратиться к ней, как к функции.

firstContract.owner - так это выглядело, если бы у нас firstContract вызывался через наследование.

Для того, чтоб вытащить поля из структуры, которая находиться в маппинге, нужно создавать кортеж переменных и в данном случае мы обращаемся к маппингу как к функции, таким образом доставая нужные нам поля.

Если мы хотим достать только определенное поле структуры, то можно сделать так: (string memory _name, ) = firstContract.humans(msg.sender);

Тут я достаю только имя из нашей структуры.

Важно!

Мы не можем изменять переменные у экземпляра контракта в своем контракте, если нет функций, разрешающих это сделать.

Как видно у меня в примере, в FirstContract я создал 2 функции устанавливающие значения полям структуры. И теперь вызвав эти функции у себя в смарт-контракте, мы можем изменить эти поля.

Функции контракта B:

 function setName_(string memory _name) public{        
     firstContract.humans(msg.sender).name = _name;    
 }

Такая запись нам не подойдет.

 function setName_(string memory _name) public{        
     firstContract.setName(_name);    
  }

Такая запись подойдет.

Нужно понимать, что сам контракт B не видит эти функции, как при наследовании, поэтому нельзя взять экземпляр и таким образом использовать все его функции. Нужно явно объявлять их у себя.

Еще нельзя забывать, что мы должны импортировать интерфейс или сам смарт-контракт, чтоб наш контракт понимал с чем взаимодействовать.

В общем это основные особенности, при использовании экземпляра контракта. Мы должны рассматривать каждую переменную как функцию, а все остальное такое же как и в наследовании.

Это была небольшая статься, потому что я для себя подметил ряд необычных механик, которые думаю можно было рассмотреть. Всем удачи.

Мой тг канал.

Всем привет! В этой статье я заканчиваю свой проект с АБС на блокчейне. Получилось почти все что я хотел сделать и это меня радует. Расскажу про последние модули и доработки. Кто хочет потыкать весь код, то может найти его на гитхабе.

Начну с того, что я не смог реализовать все модули, но те которые я хотел смог. Также я не дописал похожие модули, которые уже существуют, так как там меняется только логика применения, а код по сути тот же.

В данной статье будут модули выдачи кредитов инвестиций и аналог Свифта для переводов между банками.

Статья будет не большой, так сказать завершающей.

Изменений почти нету с прошлой статьи поэтому сразу к новому:

 // SPDX-License-Identifier: MITpragma solidity ^0.8.9;
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "./clientsInfo.sol";
contract CreditAndInvest{    
    ClientInfo clientInfo;    
    address clientInfoAddress;    
    struct creditClient{        
        address client;        
        mapping(address=>uint) tokenBalanceCredit;    
    }    
    struct investClient{        
        address client;        
        mapping(address=>uint) tokenBalanceInvest;    
    }    
    mapping(address=>creditClient) creditClients;    
    mapping(address=>investClient) investClients;    
    event newCredit(address indexed client, address token, uint amount);    
    event newInvest(address indexed client, uint amount);    
    constructor(address clientInfo_){        
        clientInfo = ClientInfo(clientInfo_);        
        clientInfoAddress = clientInfo_;    
    }        
    function Credit(address sender, address token, uint amount) public{        
        emit newCredit(sender, token, amount);    
    }    
    function getCredit(address sender, address _client, address token, uint amount) public{        
        require(clientInfo.ownersBank(sender) == true, "not owner bank!");        
        clientInfo.getCredit(token, amount);        
        unchecked {            
            creditClients[_client].tokenBalanceCredit[token] += amount;        
        }    
    }    
    function invest(address sender, address token, uint amount) public{        
        //approve frontend        
        IERC20(token).transferFrom(sender, clientInfoAddress, amount);        
        emit newInvest(sender, amount);        
        //invest frontend    
    }
}

Модули кредитов и инвестиций я объединил, также расчет процента я решил оставить на фронт, потому что тупо удобнее.

Создаю две структуры для отслеживания балансов клиентов.

На самом деле тут все тоже самое, что и в аккредитиве: я хочу открыть кредит вызываю событие, которое сотрудник отслеживает и решает выдать мне кредит или нет.

В инвестициях все проще. Я просто делаю депозит в банк и вызываю событие, что я сделал инвестицию и в зависимости от типа инвестиции мне уже считают мой процент прибыли за период.

Аналог Свифта:

Я долго думал как сделать перевод между разными банками, чтоб он был быстрый и при этом мы могли делать перевод между любыми банками любой страны.

В общем, если банк использует мой вендор, то данная технология работает, в другом случае, нужно, чтоб была аналогичная функция для перевода как у моего вендора. В обще реализация не полная.

 function newTransfer(address fromBank, address toBank, address token, address toClient, uint amount) public{            
     updateBalanceInUSD(toClient);        
     (, int256 price, , , ) = AggregatorV3Interface(oracles[token]).latestRoundData();        
     require(price > 0, "Invalid price");        
     uint amountAllowance = IERC20(token).allowance(fromBank, toBank);        
     require(amountAllowance >= amount, "Not approve");        
     IERC20(token).transferFrom(fromBank, toBank, amount);         
     unchecked {            
         clients[toClient].balanceUsdt[token] += amount * uint(price);            
         clients[toClient].tokenBalance[token] += amount;        
     }    
 }    
 function transferBalanceFromBank(address sender, address to, address clientInfoBank, address token, uint amount, string memory inf) public{        
     updateBalanceInUSD(sender);        
     (, int256 price, , , ) = AggregatorV3Interface(oracles[token]).latestRoundData();        
     require(price > 0, "Invalid price");        
     unchecked {            
         clients[sender].balanceUsdt[token] -= amount * uint(price);            
         clients[sender].tokenBalance[token] -= amount;        
     }        
     IERC20(token).approve(clientInfoBank, amount);        
     bytes4 selector = bytes4(keccak256("newTransfer(address,address,address,address,uint256)"));        
     (bool success, ) = clientInfoBank.call(abi.encodeWithSelector(selector, address(this), clientInfoBank, token, to, amount));        
     require(success, "faild");        
     clients[sender].paymentInfo.push(payment(sender, to, inf, token, amount));    
 }

Добавлены функции в контракт clientInfo.

Для того, чтоб перевести деньги на другой банк, я буду использовать низкоуровневый вызов, который будет вызывать функцию, где уже будет происходить перевод. И соответственно я правильно отображаю балансы каждого клиента разных банков. Тема рабочая, при условии что вендоры одинаковые. Можно кончено передавать селектор функции другого вендора, отвечающего за перевод банку или депозит, таким образом обойти данную проблему, но я думаю в данном примере этого достаточно.

На этом я хочу закончить данный проект. Сделали достаточно много всего. Код был объёмным и много раз приходилось все переделывать, но в итоге исход положительный. Данную тему можно очень хорошо развить кому интересно, так что дерзайте. Я же вернусь к изучению solidity и его различным стандартам и особенностям. Всем кто следил спасибо.

Полный проект на гитхабе

Мой тг канал

Всем привет! Сегодня уже третья статья про АБС. Написал новый модуль аккредитив для банка. Появилось много необычного и интересного в проекте.

Начну с того, что я не бросал проект, просто времени было не много и появилась проблема в реализации, о которой я думал, но не знал что она придет так рано.

Трудности и изменения:

Начну как всегда с трудностей. Изначально я хотел, чтоб все модули соединялись между собой через наследование, это было бы удобно, потому что в одном контракте лежала бы вся информация и реализация, но проект оказался больше чем я думал и уже на втором модуле при тестах я получил ошибку при диполе о вылете из за нехватке газа, что говорит о том что невозможно оценить газ, а значит контракта слишком большой.

Решение простое: просто сделать каждый контракт отдельным.(каждый модуль это свой личный контракт). Пришлось перебирать весь код для решения проблемы. Так как контракт, где храниться информация о клиентах банка мне нужен в каждом модуле, следовательно нужно брать его экземпляр и в каждый модуль добавлять. Позже в коде все будет видно. Главная проблема заключается в том, что мы не можем менять состояние переменных структуры напрямую у экземпляра контракта, поэтому приходиться добавлять лишние функции и уже работать через них.

Также из за сложности кода решил пока что делать вендор для одного банка. Другими словами, такой вендор нужно отдельно деплоить для каждого нового банка. Но в будущем можно будет это исправить усложнив логику.

На самом деле в данной статье получилось так, что весь код прошлых статей абсолютно переписан, поэтому можно даже не смотреть на предыдущие статьи в этом плане.

Код:

Первый контракт clientInfo - содержит информацию о клиентах и основные функции по изменению состояний полей структуры клиента.

// SPDX-License-Identifier: MITpragma solidity ^0.8.9;
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@chainlink/contracts/src/v0.8/interfaces/AggregatorV3Interface.sol";
contract ClientInfo {        
    address public BANK;    
    address owner;    
    constructor(){        
        owner = msg.sender;    
    }    
    struct client{        
        string name;        
        address clientOwner;        
        address bank;        
        uint clientType;        
        bool accountDebet;        
        bool accountCredit;        
        payment[] paymentInfo;        
        document[] documents;        
        address[] allTokens;        
        mapping(address=>uint) balanceUsdt;        
        mapping(address=>uint) tokenBalance;    
    }    
    struct document{        
        uint typeDocument;        
        string documentInfo;        
        address document;    
    }    
    struct payment{        
        address from;        
        address to;        
        string message;        
        address token;        
        uint amount;    
    }    
    mapping(address=>mapping(uint=>bool)) public initSubscribe;    
    mapping(address=>client) public clients;        
    mapping(address=>address) oracles;    
    mapping(address=>bool) public ownersBank;
    mapping(address=>bool) module;    
    modifier onlyModules(address module_) {        
        require(module[module_] == true, "only module can call");        
        _;    
    }    
    modifier onlyOwner(){        
        require(msg.sender == owner, "not owner");        
        _;    
    }    
    function addModules(address _module) public onlyOwner{        
        module[_module] = true;    
    }    
    function createBank() public onlyModules(msg.sender){        
        BANK = msg.sender;        
        client storage newClientInfo = clients[msg.sender];        
        newClientInfo.name = "BANK";        
        newClientInfo.clientOwner = msg.sender;        
        newClientInfo.bank = msg.sender;        
        newClientInfo.accountDebet = true;        
        newClientInfo.accountCredit = true;        
        newClientInfo.clientType = 3;        
        newClientInfo.documents.push(document(0, "create bank", msg.sender));    
    }
    function addNeworacle(address token, address _oracle) public onlyModules(msg.sender){        
        oracles[token] = _oracle;    
    }
    function initializeClient(string calldata _name, address sender) public onlyModules(msg.sender){        
        require(BANK == msg.sender, "not bank");        
        require(clients[sender].bank != msg.sender || clients[sender].clientOwner != sender, "already exist");        
        client storage newClientInfo = clients[sender];        
        newClientInfo.name = _name;        
        newClientInfo.clientOwner = sender;        
        newClientInfo.bank = msg.sender;        
        newClientInfo.accountDebet = false;        
        newClientInfo.accountCredit = false;
        uint size;                
        assembly {            
            size := extcodesize(sender)        
        }        
        if (size > 0) {            
            bytes4 expectedFunctionSignature = bytes4(keccak256("check(uint256,address)"));            
            (bool success, ) = sender.call(abi.encodeWithSelector(expectedFunctionSignature, 1, sender));            
            require(success, "faild");            
            if(success == true){                
                newClientInfo.clientType = 1;                
                newClientInfo.documents.push(document(0, "entity person", sender));            
            }         
        }     
        else{            
            newClientInfo.clientType = 0;            
            newClientInfo.documents.push(document(0, "natural person", sender));        
        }        
        newClientInfo.paymentInfo.push(payment(sender, address(this), "new client", address(this), 0));        
    }       
    function setOwner(address _owner) public onlyModules(msg.sender){       
        require(msg.sender == BANK);        
        ownersBank[_owner] = true;    
    }
    function getClientInfo(address sender) public view onlyModules(msg.sender) returns(string memory,address, address, uint, uint, uint) {        
        return(clients[sender].name, clients[sender].clientOwner, clients[sender].bank, clients[sender].clientType, clients[sender].balanceUsdt[0xdAC17F958D2ee523a2206206994597C13D831ec7], clients[sender].tokenBalance[0xdAC17F958D2ee523a2206206994597C13D831ec7]);    
    }
    function setSubscribe(address sender, uint typeClient) public onlyModules(msg.sender){        
        initSubscribe[sender][typeClient] = true;    
    }
    function addAccount(address sender, uint typeAccount) public onlyModules(msg.sender){        
        if(typeAccount == 0){            
            clients[sender].accountDebet = true;        
        }        
        if(typeAccount == 1){            
            clients[sender].accountCredit = true;        
        }            
    }    
    function deletAccount(address sender, uint typeAccount) public onlyModules(msg.sender){         
        if(typeAccount == 0){            
            clients[sender].accountDebet = false;        
        }        
        if(typeAccount == 1){            
            clients[sender].accountCredit = false;        
        }    
    }    
    function updateBalanceInUSD(address sender) public{        
        for(uint i = 0; i < clients[sender].allTokens.length; i++){            
            (, int256 price, , , ) = AggregatorV3Interface(oracles[clients[sender].allTokens[i]]).latestRoundData();            
            uint balance = clients[sender].balanceUsdt[clients[sender].allTokens[i]];            
            clients[sender].balanceUsdt[clients[sender].allTokens[i]] = balance * uint(price);        
         }    
     }    
     function transferBalanceInBank(address sender, address to, address token, uint amount, string memory inf) public{        
         (, int256 price, , , ) = AggregatorV3Interface(oracles[token]).latestRoundData();        
         require(price > 0, "Invalid price");        
         unchecked {            
             clients[sender].balanceUsdt[token] -= amount * uint(price);            
             clients[sender].tokenBalance[token] -= amount;            
             clients[to].balanceUsdt[token] += amount * uint(price);            
             clients[to].tokenBalance[token] += amount;                    
         }        
         clients[sender].paymentInfo.push(payment(sender, to, inf, token, amount));    
     }    
     function invest(address sender, address token, uint amount) public{        
         (, int256 price, , , ) = AggregatorV3Interface(oracles[token]).latestRoundData();        
         require(price > 0, "Invalid price");        
         clients[sender].balanceUsdt[token] -= amount * uint(price);        
         clients[sender].tokenBalance[token] -= amount;        
         clients[BANK].balanceUsdt[token] += amount * uint(price);        
         clients[BANK].tokenBalance[token] += amount;        
         clients[sender].paymentInfo.push(payment(sender, address(this), "deposit balance", token, amount));    
     }     
     function depositBalance(address sender, address token, uint amount) public{        
         (, int256 price, , , ) = AggregatorV3Interface(oracles[token]).latestRoundData();        
         require(price > 0, "Invalid price");        
         clients[sender].balanceUsdt[token] += amount * uint(price);        
         clients[sender].tokenBalance[token] += amount;        
         clients[sender].paymentInfo.push(payment(sender, address(this), "deposit balance", token, amount));    
     }    
     function withdrawlBalance(address sender, address token, uint amount) public{        
         IERC20(token).transfer(sender, amount);        
         (, int256 price, , , ) = AggregatorV3Interface(oracles[token]).latestRoundData();        
         require(price > 0, "Invalid price");        
         unchecked{            
             clients[sender].balanceUsdt[token] -= amount * uint(price);            
             clients[sender].tokenBalance[token] -= amount;        
         }        
         clients[sender].paymentInfo.push(payment(address(this), sender, "withdrawal balance", token, amount));    
     }
}

В данном контракте все функции, которые вы уже видели, они были в контакте Core, но из за особенностей solidity они теперь тут. Единственное, что я добавил, это модификатор onlyModules на ряд функций, что их вызывать могут только модули. Это дает нам гарантию, что извне ни кто не будет обращаться к этим функциям, так как мне это не нужно. Ну и для тех полей структуры, которые мне нужно будет менять значение я сделал функцию по их изменению, например setSubscribe функция которая устанавливает в маппинге initSubscribe значение true.

Контракт CreateClients - содержит функционал создания клиента банка

// SPDX-License-Identifier: UNLICENSEDpragma solidity ^0.8.9;
import "./clientsInfo.sol";
contract CreateClients{    
    ClientInfo public clientInfo;    
    address letterOfCreditAddress;    
    constructor(address clientInfo_){        
        clientInfo = ClientInfo(clientInfo_);        
        letterOfCreditAddress = clientInfo_;    
    }    
    modifier onlyOwnerBank(address sender) {        
        require(clientInfo.ownersBank(sender) == true, "Not an owner bank");        
        _;    
    }    
    function checkOwnerBank() public view returns(bool){        
        return clientInfo.ownersBank(msg.sender);    
    }        
    function addAccountDebet(address sender) public {        
        (, address isOwnerAccount, , , ,) = clientInfo.clients(sender);        
        require(isOwnerAccount == sender, "Not client");        
        clientInfo.setSubscribe(sender, 0);    
    }    
    function addAccountCredit(address sender) public{          
        (, address isOwnerAccount, , , ,) = clientInfo.clients(sender);        
        require(isOwnerAccount == sender, "Not client");        
        clientInfo.setSubscribe(sender, 1);            
    }    
    function complitesubscribersAccount(address _client, uint typeAccount, address sender) public onlyOwnerBank(sender){        
        require(clientInfo.initSubscribe(_client, typeAccount) == true, "not complite");        
        require(typeAccount == 0 || typeAccount == 1, "error");        
        clientInfo.addAccount(_client, typeAccount);    
    }    
    function deletAccountDebet(address sender) public{        
        (, address isOwnerAccount, , , bool debet,) = clientInfo.clients(sender);        
        require(isOwnerAccount == sender, "Not client");        
        require(debet == true, "not open");         
        clientInfo.setSubscribe(sender, 0);    
    }    
    function deletAccountCredit(address sender) public{        
        (, address isOwnerAccount, , , , bool credit) = clientInfo.clients(sender);        
        require(isOwnerAccount == sender, "Not client");        
        require(credit == true, "not open");        
        clientInfo.setSubscribe(sender, 1);    
    }    
    function comliteDeletAccount(address _client, uint typeAccount, address sender) public onlyOwnerBank(sender){        
        require(clientInfo.initSubscribe(_client, typeAccount) == true, "not complite");        
        require(typeAccount == 0 || typeAccount == 1, "error");        
        clientInfo.deletAccount(_client, typeAccount);    
    }
}

Тут тоже все функции знакомые. Показываю, чтоб было понятно как я обращаюсь к контракту clientInfo и изменяю состояния полей структуры

Из интересного вот как вытаскивать поля из структуры, другие способы почему что не работают, компилятор ругается мол не видит их.

(, address isOwnerAccount, , , ,) = clientInfo.clients(sender);

Возможно это из за того, что он обращается к переменным как к функциям, например если я хочу вытащить переменную BANK из контракта clientInfo, я должен обратиться к ней так:

 clientInfo.BANK()

Или к маппингу так:

 clientInfo.ownersBank(sender) 

то есть в случае наследования было бы так:

clientInfo.ownersBank[sender]

В общем если будете работать с экземплярами контрактов, то учитывайте данную особенность.

Контракт Core - тоже старый контракт, все функции в нем знакомы, но покажу как его изменил с новым подходом:

 // SPDX-License-Identifier: UNLICENSEDpragma solidity ^0.8.9;
import "./Clients.sol";
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
contract Core is CreateClients{    
    address owner;    
    constructor(address clientInfo_) CreateClients(clientInfo_){        
        owner = msg.sender;    
    }    
    modifier onlyOwner() {        
        require(owner == msg.sender, "faild");        
        _;    
    }    
    function transferBalance(uint amount, address token, address to, address sender) public{        
        (, address isOwnerAccount, address bank, , bool debet,) = clientInfo.clients(sender);        
        (, address isOwnerAccountTo, address bankTo, , bool debetTo,) = clientInfo.clients(to);        
        require(isOwnerAccount == sender, "not client");        
        require(isOwnerAccountTo == to, "not client");        
        require(msg.sender == clientInfo.BANK(), "not bank");        
        require(debet == true, "not open account");        
        require(debetTo == true, "not open account");        
        require(bank == bankTo, "different bank");        
        clientInfo.updateBalanceInUSD(sender);        
        clientInfo.transferBalanceInBank(sender, to, token, amount, "new transfer balance");    
    }    
    function investing(address sender, address token, uint amount) public{        
        clientInfo.invest(sender, token, amount);    
    }    
    function deposit(uint amount, address token, address sender) public {        
        (, address isOwnerAccount, , , bool debet,) = clientInfo.clients(sender);        
        require(clientInfo.BANK() == msg.sender, "not bank");        
        require(isOwnerAccount == sender, "not client");        
        require(debet == true, "not open account");        
        require(IERC20(token).allowance(sender, address(this)) >= amount, "chek allowance");        
        clientInfo.updateBalanceInUSD(sender);        
        IERC20(token).transferFrom(sender, letterOfCreditAddress, amount);        
        clientInfo.depositBalance(sender, token, amount);    
    }    
    function withdrawal(uint amount, address token, address sender) public{        
        (, address isOwnerAccount, , , bool debet,) = clientInfo.clients(sender);        
        require(clientInfo.BANK() == msg.sender, "not bank");        
        require(isOwnerAccount == sender, "not client");        
        require(debet == true, "not open account");        
        require(IERC20(token).allowance(msg.sender, address(this)) >= amount, "chek allowance");        
        clientInfo.updateBalanceInUSD(sender);        clientInfo.withdrawlBalance(sender, token, amount);    
    }  
}

По факту тут идет дублирование функций из clientInfo, но с добавлением ряда условий и ограничений, сделал так для безопасности, и в рамках модификатора onlyModules. Ну и конечно наследует контракт CreateClients.

Новый контракт LettersOfCredit - это новый модуль который я реализовал в нашей АБС. Данный модуль это аккредитивы. Они работают по типу совершение сделки через гаранта, а банк в его роли. Например я (продавец) хочу продать 100 телефонов покупателю оптом, я заключаю аккредитив с банком и говорю, что после того как эти телефоны прибудут по месту назначения, банк покупателя обязуется выплатить деньги за эти телефоны в пользу продавцы, таким образом продавец уверен что его не обманут после отправки товара и ему заплатят. После покупатель уже с банком разбирается и оплачивает данный товар по частям как кредит или одним чеком. Я реализовал лишь концепцию и не соблюдал много условий, но в общем пойдет.

 // SPDX-License-Identifier: MIT
 pragma solidity ^0.8.9;
 import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
 import "./clientsInfo.sol";
 contract LettersOfCredit{    
     ClientInfo clientInfo;     
     struct letterofcredit{        
     address from;        
     address to;        
     uint amount;        
     address token;        
     string conditions;        
     uint stage;    
     }    
     mapping(address=>letterofcredit) public LettersOfCredits;    
         constructor(address clientInfo_){        
         clientInfo = ClientInfo(clientInfo_);    
     }    
     event newLetterOfCreditrequest(address to, string message);     
     function makeLettersOfCredit(address sender, address recipient, uint amount, address token, string calldata contitions) public {
         letterofcredit storage newLetterOfCredit = LettersOfCredits[sender];        
         newLetterOfCredit.from = sender;        
         newLetterOfCredit.to = recipient;        
         newLetterOfCredit.amount = amount;        
         newLetterOfCredit.token = token;        
         newLetterOfCredit.conditions = contitions;        
         newLetterOfCredit.stage = 1;    
     }    
     function confirmLetterOfCredit(address sender, address _client) public {        
         require(LettersOfCredits[_client].stage == 1, "Error");        
         require(clientInfo.ownersBank(sender) == true, "only owner bank can confirm");        
         LettersOfCredits[_client].stage = 2;    
     }    
     function sendLettersOfCredit(address sender, address _client) public{       
         require(LettersOfCredits[_client].stage == 2, "Error");        
         require(clientInfo.ownersBank(sender) == true, "only owner bank can send");        
         emit newLetterOfCreditrequest(LettersOfCredits[_client].to, LettersOfCredits[_client].conditions);        
         LettersOfCredits[_client].stage = 3;    
     }    
     function checkLetterOfCredit(address sender, address _client) public{        
         require(LettersOfCredits[_client].stage == 3, "Error");        
         require(clientInfo.ownersBank(sender) == true, "only bank can confirm check");        
         LettersOfCredits[_client].stage = 4;    
     }    
     function transferBalance_(uint amount, address token, address to, address sender) private{        
         clientInfo.updateBalanceInUSD(sender);        
         clientInfo.transferBalanceInBank(sender, to, token, amount, "new transfer balance letter of credit");    
     }       
     function checkLetter(address sender) public view returns(address, address, uint, address, string memory, uint){        
         return (LettersOfCredits[sender].from, LettersOfCredits[sender].to, LettersOfCredits[sender].amount, LettersOfCredits[sender].token, LettersOfCredits[sender].conditions, LettersOfCredits[sender].stage);    
     }    
     function sendMoney(address sender, address _client) public{        
         require(LettersOfCredits[_client].stage == 4, "error");        
         require(clientInfo.ownersBank(sender) == true, "only bank can send money");        
         transferBalance_(LettersOfCredits[_client].amount, LettersOfCredits[_client].token, LettersOfCredits[_client].to, clientInfo.BANK());        
         LettersOfCredits[_client].stage = 5;    
     }    
     function compliteLetterOfCredit(address sender, address _client) public {        
         require(LettersOfCredits[_client].stage == 5, "error");        
         require(clientInfo.ownersBank(sender) == true, "only bank can send money");        
         delete LettersOfCredits[_client];    
     }
 }

Я создаю еще одну структуру, которая хранит в себе всю нужную информацию о аккредитиве. В целом все поля понятные кроме stage. Его я использую для определения этапа выполнения сделки.

Функции:

makeLettersOfCredit - функция для создание аккредитива, передаем просто все данные, после создания аккредитива мы от лица банка его подтверждаем

confirmLetterOfCredit - тут как раз вступает в игру stage. После подтверждения он меняется на 2. Как видно каждую функцию я ограничиваю stage, и ее можно вызвать только в определенный момент, а не когда замочиться.

sendLettersOfCredit - функция оповещающая о том, что аккредитив вступает в силу, вызывая событие, так как их легко отслеживать на фронте.

checkLetterOfCredit - функция вызывается после того как банк проверил что услуга выполнена и можно отправлять деньги

transferBalance_ - приватная функция, которая делает сам перевод.

checkLetter - функция которая может выдать информацию об аккредитиве

sendMoney - функция которая переводит деньги, обратите внимание что отправитель денег не человек, который создал аккредитив, а банк.

compliteLetterOfCredit - эта функция закрывает аккредитив после его выполнения

В общем очень просто контракт с очевидными функциями. Также покрыл основную часть кода тестами. Это уже все на гитхабе, кому интересно.

Контракт OtherContract - уже знакомый нам ипровезированный банк (надо бы название поменять).

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.9;
import "./Core.sol";
import "./letterOfCredit.sol";
contract OtherContract{    
    Core public coreInstance;    
    LettersOfCredit public letterInsctance;    
    ClientInfo public clientInfo;    
    constructor(address _coreAddress, address _LetterOfCredit, address clientInfo_) {        
        coreInstance = Core(_coreAddress);        
        letterInsctance = LettersOfCredit(_LetterOfCredit);        
        clientInfo = ClientInfo(clientInfo_);    
    }    
    function checkClient(address client) public view returns(string memory,address, address, uint, uint, uint){        
        return clientInfo.getClientInfo(client);    
    }        
    function setOwnerBank() public{        
        clientInfo.createBank();    
    }    
    function setOwnerClient(address owner_)  public{            
        clientInfo.setOwner(owner_);    
    }    
    function addNeworacle_(address token, address oracle) public{        
        clientInfo.addNeworacle(token, oracle);    
    }    
    function investing_(address token, uint amount) public{        
        coreInstance.investing(msg.sender, token, amount);    
    }    
    function _checkLetter(address sender) public view returns(address, address, uint, address, string memory, uint){        
        return letterInsctance.checkLetter(sender);    
    }    
    function _makeLetterOfCerdit(address to, uint amount, address token, string calldata contitions) public {        
        letterInsctance.makeLettersOfCredit(msg.sender, to, amount, token, contitions);    
    }    
    function _confirmLetterOfCredit(address _client) public{        
        letterInsctance.confirmLetterOfCredit(msg.sender, _client);    
    }    
    function _sendLettersOfCredit(address _client) public{        
        letterInsctance.sendLettersOfCredit(msg.sender, _client);    
    }    
    function _checkLetterOfCredit(address _client) public{        
        letterInsctance.checkLetterOfCredit(msg.sender, _client);    
    }    
    function _sendMoney(address _client) public{        
        letterInsctance.sendMoney(msg.sender, _client);    
    }    
    function _compliteLetterOfCredit(address _client) public{        
        letterInsctance.compliteLetterOfCredit(msg.sender, _client);    
    }    
    function openAccount(address _client, uint typeAccount) public{        
        coreInstance.complitesubscribersAccount(_client, typeAccount, msg.sender);    
    }    
    function deletAccount(address _client, uint typeAccount) public{        
        coreInstance.comliteDeletAccount(_client, typeAccount, msg.sender);            
    }    
    function deletAccountDebet_() public{               
        coreInstance.deletAccountDebet(msg.sender);    
    }    
    function deletAccountCredit_() public{               
        coreInstance.deletAccountCredit(msg.sender);    
    }    
    function addAccountDebet_() public{               
        coreInstance.addAccountDebet(msg.sender);    
    }    
    function addAccountCredit_() public{               
        coreInstance.addAccountCredit(msg.sender);    
    }    
    function newClient(string calldata _name) public{        
        clientInfo.initializeClient(_name, msg.sender);    
    }    
    function balance(address token) public view returns(uint){        
        return IERC20(token).balanceOf(msg.sender);    
    }
    function depositeToBank(uint amount, address token) public{        
        //approve frontend        
        coreInstance.deposit(amount, token, msg.sender);    
    }    
    function transferBalanceInBank(uint amount, address token, address to) public{        
        coreInstance.transferBalance(amount, token, to, msg.sender);   
    }    
    function checkAllowance(address token) public view returns(uint){        
        return IERC20(token).allowance(msg.sender, address(this));    
    }
}

Тут все просто. В конструктор я передаю адреса моих модулей, получаю их экземпляр и просто вызываю все функции в одном контракте. Таким образом получаю доступ ко всем функциям.

На этом я закончу данную статью, надеюсь дальше буду чаще выкладывать их, но все зависит от сложности и времени, потому что пока я писал данный код столкнулся с очень многими мелкими проблемками, которые приходилось обходить и иногда уходило на это много времени.

Оставляю кому интересно:

Мой тг канал
Этот проект на гитхабе

Всем привет. Продолжаем создавать автоматизированную банковскую систему на блокчейне. В этой статье наш смарт-контракт Core был сильно изменен, так что будем разбираться по порядку.

Те кто не видел первую статью на эту тему настоятельно рекомендую просмотреть, чтоб понимать что происходит вообще тут.

Интересные моменты

Из интересного я переосмыслил концепцию. Изначально я хотел, чтоб мой вендор хранил всю информацию о всех банках, которые им бы пользовались. И соответственно вендор был бы нагружен всеми клиентами разных банков и самими банками. В процессе я понял, что это не удобно и слишком медленно. Я решил, что каждый банк будет интегрировать эту систему в свой смарт-контракт банка (получать экземпляр контракта через интерфейс и его адрес). Таким образом каждый смарт-контракт банка будет хранить всю информацию у себя внутри в безопасности. Из плюсов это анонимность каждого банка и эффективность. Из минусов, я пока не могу придумать как переводить средства из одно банка в другой одной транзакцией, потому что не могу менять балансы клиентов разных смарт-контрактов банков. Если у кого-то есть идеи, буду рад принять.

Вторя проблема, это отображение всего баланса в usd. Проблема в том, что наш клиент может иметь огромное количество токенов, у которых меняется цена токена за доллар и, чтоб отображать правильную цену аккаунта (в долларах) нам нужно обновлять баланс каждый определенный промежуток времени. Сделать это не трудно, но я пока не придумал как лучше.

Что мы сегодня реализуем:

Я реализую все оставшиеся функции ядра АБС. (почти)

Валютный учет
Безналичные расчеты
Учет и отчетность

Так же еще осталось много недочетов, которые я буду в будущем исправлять.

И как я уже сказал в функции "Безналичные расчеты" я не смог пока придумать перевод между разными банками (но это можно оставить на модуль SWIFT).

Код:

Вот новый контракт Core. Сначала я расскажу про изменения, потом уже про нововведения.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.9;
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@chainlink/contracts/src/v0.8/interfaces/AggregatorV3Interface.sol";
contract Core {    
    address owner;    
    mapping(address=>bool) public ownersBank;    
    address public BANK;    
    constructor(){        
        owner = msg.sender;    
    }    
    struct client{        
        string name;        
        address clientOwner;        
        address bank;        
        uint clientType;        
        bool accountDebet;        
        bool accountCredit;        
        bytes32[] paymentInfo;        
        document[] documents;        
        uint balanceUsdt;        
        mapping(address=>uint) tokenBalance;        
        uint balanceCredit;    
    }    
    struct document{        
        uint typeDocument;        
        string documentInfo;        
        address document;    
    }    
    mapping(address=>mapping(uint=>bool)) initSubscribe;    
    mapping(address=>client) private clients;   
    mapping(address=>address) oracles;
    modifier onlyOwner() {        
        require(owner == msg.sender, "faild");        
        _;    
    }    
    modifier onlyOwnerBank(address sender){        
        require(ownersBank[sender] == true);        
        _;    
    }    
    function checkOwnerBank() public view returns(bool){        
        return ownersBank[msg.sender];    
    }    
    modifier checkTransfer(address sender, address to) {        
        require(clients[sender].clientOwner == sender, "not client");        
        require(clients[to].clientOwner == to, "not client");        
        require(msg.sender == BANK, "not bank");        
        require(clients[sender].accountDebet == true, "not open account");        
        require(clients[to].accountDebet == true, "not open account");        
        require(clients[to].bank == clients[sender].bank, "different bank");        
        _;    
    }    
    function transferBalance(uint amount, address token, address to, address sender) public checkTransfer(sender, to){        
        (, int256 price, , , ) = AggregatorV3Interface(oracles[token]).latestRoundData();        
        require(price > 0, "Invalid price");        
        unchecked {            
            // need decimals             
            clients[sender].balanceUsdt -= (amount / 1000000) * (uint(price) / 100);             
            clients[sender].tokenBalance[token] -= amount;            
            clients[to].balanceUsdt += (amount / 1000000) * (uint(price) / 100);            
            clients[to].tokenBalance[token] += amount;                    
        }    
    }    
    function addNeworacle(address token, address _oracle) public onlyOwner(){        
        oracles[token] = _oracle;    
    }        
    //updateBalanceInUSD()???...    
    //function transferFromBank()???...        
    function deposit(uint amount, address token, address sender) public {        
        require(BANK == msg.sender, "not bank");        
        require(clients[sender].clientOwner == sender, "not client");        
        require(clients[sender].accountDebet == true, "not open account");        
        require(IERC20(token).allowance(sender, address(this)) >= amount, "chek allowance");        
        IERC20(token).transferFrom(sender, BANK, amount);        
        (, int256 price, , , ) = AggregatorV3Interface(oracles[token]).latestRoundData();        
        require(price > 0, "Invalid price");        
        clients[sender].balanceUsdt += (amount / 1000000) * (uint(price) / 100);        
        clients[sender].tokenBalance[token] += amount;
    }    
    function withdrawal(uint amount, address token, address oracle, address sender) public{        
        require(BANK == msg.sender, "not bank");        
        require(clients[sender].clientOwner == sender, "not client");        
        require(clients[sender].accountDebet == true, "not open account");        
        require(IERC20(token).allowance(msg.sender, address(this)) >= amount, "chek allowance");        
        IERC20(token).transferFrom(msg.sender, sender, amount);        
        (, int256 price, , , ) = AggregatorV3Interface(oracle).latestRoundData();        
        require(price > 0, "Invalid price");        
        clients[sender].balanceUsdt -= (amount / 1000000) * (uint(price) / 100);        
        clients[sender].tokenBalance[token] -= amount;    
    }      
    function balanceTokenAccount(address tokenAddress, address oracle, address sender) public view returns(uint, uint){        
        require(clients[sender].clientOwner == sender, "not client");        
        uint balance = IERC20(tokenAddress).balanceOf(sender);        
        (, int256 price, , , ) = AggregatorV3Interface(oracle).latestRoundData();        
        require(price > 0, "Invalid price");           
        return (balance, balance*(uint(price)/100));    
    }    
    function createBank() public{        
        BANK = msg.sender;    
    }    
    function setOwner(address _owner) public{        
        require(msg.sender == BANK);        
        ownersBank[_owner] = true;    }
    function initializeClient(string calldata _name, address sender) public{        
        require(BANK == msg.sender, "not bank");        
        require(clients[sender].bank != msg.sender || clients[sender].clientOwner != sender, "already exist");        
        client storage newClientInfo = clients[sender];        
        newClientInfo.name = _name;        
        newClientInfo.clientOwner = sender;        
        newClientInfo.bank = msg.sender;        
        newClientInfo.accountDebet = false;        
        newClientInfo.accountCredit = false;
        uint size;                
        assembly {            
        size := extcodesize(sender)        
    }        
    if (size > 0) {            
        bytes4 expectedFunctionSignature = bytes4(keccak256("check(uint256,address)"));            
        (bool success, ) = sender.call(abi.encodeWithSelector(expectedFunctionSignature, 1, sender));            
        require(success, "faild");            
        if(success == true){                
            newClientInfo.clientType = 1;                
            newClientInfo.documents.push(document(0, "entity person", sender));            
        }         
    } else{            
        newClientInfo.clientType = 0;            
        newClientInfo.documents.push(document(0, "natural person", sender));        
    }        
    newClientInfo.paymentInfo.push(bytes32(keccak256(bytes("Create client"))));        
    }    
    function getClientInfo(address _client) public view returns(string memory, address, address, bytes32[] memory, uint, uint, uint) {        
        return (clients[_client].name, clients[_client].clientOwner, clients[_client].bank, clients[_client].paymentInfo, clients[_client].balanceUsdt, clients[_client].tokenBalance[0xdAC17F958D2ee523a2206206994597C13D831ec7], clients[_client].tokenBalance[0x514910771AF9Ca656af840dff83E8264EcF986CA]);    
    }    
    function addAccountDebet(address sender) public{          
        require(sender == clients[sender].clientOwner, "Not client");        
        initSubscribe[sender][0] = true;    
    }    
    function addAccountCredit(address sender) public{          
        require(sender == clients[sender].clientOwner);        
        initSubscribe[sender][1] = true;    
    }    
    function complitesubscribersAccount(address _client, uint typeAccount, address sender) public onlyOwnerBank(sender){        
        require(initSubscribe[_client][typeAccount] == true, "not complite");        
        require(typeAccount == 0 || typeAccount == 1, "error");        
        if(typeAccount == 0){            
            clients[_client].accountDebet = true;            
            initSubscribe[_client][typeAccount] = false;        
        }        
        if(typeAccount == 1){            
            clients[_client].accountCredit = true;            
            initSubscribe[_client][typeAccount] = false;        
        }    
    }    
    function deletAccountDebet(address sender) public{        
        require(sender == clients[sender].clientOwner);        
        require(clients[sender].accountDebet == true, "not open");        
        initSubscribe[sender][0] = true;    
    }    
    function deletAccountCredit(address sender) public{        
        require(sender == clients[sender].clientOwner);        
        require(clients[sender].accountCredit == true, "not open");        
        initSubscribe[sender][1] = true;    
    }    
    function comliteDeletAccount(address _client, uint typeAccount, address sender) public onlyOwnerBank(sender){
        require(initSubscribe[_client][typeAccount] == true, "not complite");        
        require(typeAccount == 0 || typeAccount == 1, "error");        
        if(typeAccount == 0){            
            clients[_client].accountDebet = false;            
            initSubscribe[_client][typeAccount] = false;        
        }        
        if(typeAccount == 1){                      
            clients[_client].accountCredit = false;            
            initSubscribe[_client][typeAccount] = false;        
        }    
    }       
}

В структура client я добавил пару новых полей:
адрес банка и отображение балансов в двух видах usd и в токенах

ownersBank теперь хранит в себе сотрудников банка. То есть у них будут открыты возможности на подобии подтверждения/открытия счета клиента.

Также добавил ораклы для просмотра цены токена в долларах. Добавил функционал отображения цены в долларах токенов и функцию для сохранения новых адресов ораклов для токенов.

Добавил функцию для открытия банка createBank. Теперь владелец банка должен вызвать данную функцию чтоб указать свой банк - банком в контракте core.

Добавил пару промежуточных функций для проверки, например checkOwnerBank

Добавил функционал депозита и вывода средств в банк, а также перевод внутри банка.
deposit withdrawal transferBalance - функции безналичного расчета.

Добавил модификатор для перевода, который проверяет, чтоб все данные сходились и разрешал выполнить перевод средств.

Также добавил контракт, который эти функции реализует, что то типа банка на минималках. В нем я буду проверять функционал всего вендора.

Есть еще тесты, которые я написал, для проверки работы всех функций.

Если вы загляните на гитхаб, то увидите там еще один смарт-контракт swap. Он нужен только для тестов, чтоб можно было за эфир купить токены и проверить функционал deposit transferBalance.

Из интересного: так как ораклы показывают свою цены в своих decimals, то пришлось выравнивать эти значения с токенами. Пока что реализация кривая и только для usdt, в будущем сделаю по умному.

balanceTokenAccount по идее выводит цену токенов в usd и сами токены.

Вопрос с approve. Так как мы должны дать разрешение на списание токенов, то это уже нужно реализовывать через фронтенд банку, как это делает например uniswap. Внутри контракта это сделать не возможно. Главное понимать, что approve мы даем не банку а вендору (core), так как он осуществляет перевод. Таким образом я хочу добиться безопасности. То есть я хочу чтоб вендор был как контракт доверия всех людей, чтоб они понимали что банк их не обманет.

Еще надо четко понимать, что каждый вызов функции контракта core идет от банка, то есть msg.sender всегда смарт-контракт в core.

В общем делать еще много, но основной функционал реализован, осталось подчистить код и решить пару проблем и с ядром АБС закончили.

доп код контракта недо-банка:

contract OtherContract {    
    address public coreAddress;     
    Core public coreInstance;     
    constructor(address _coreAddress) {        
        coreAddress = _coreAddress;        
        coreInstance = Core(coreAddress);    
    }    
    function checkClient(address client) public view returns(string memory,address, address, bytes32[] memory, uint, uint, uint){        
        return coreInstance.getClientInfo(client);    
    }    
    function setOwnerBank() public{        
        coreInstance.createBank();    
    }    
    function setOwnerClient(address owner_)  public{            
        coreInstance.setOwner(owner_);    
    }    
    function openAccount(address client, uint typeAccount) public{        
        coreInstance.complitesubscribersAccount(client, typeAccount, msg.sender);    
    }    
    function addAccountDebet() public{               
        coreInstance.addAccountDebet(msg.sender);    
    }    
    function newClient(string calldata _name) public{        
        coreInstance.initializeClient(_name, msg.sender);    
    }    
    function balance(address token) public view returns(uint){        
        return IERC20(token).balanceOf(msg.sender);    
    }
    function depositeToBank(uint amount, address token) public{        
        //approve frontend        
        coreInstance.deposit(amount, token, msg.sender);    
    }    
    function getWETHPriceInUSD(address oracle) public view returns (uint256) {        
        (, int256 price, , , ) = AggregatorV3Interface(oracle).latestRoundData();        
        require(price > 0, "Invalid price");        
        return uint256(price) / 100; //делим на 100 так как decimals оракла 8 а у usdt decimals 6 => 8-6=2 лишние нули    
    }     
    function transferBalanceInBank(uint amount, address token, address to) public{         
        coreInstance.transferBalance(amount, token, to, msg.sender);     
    }
    function checkAllowance(address token) public view returns(uint){        
        return IERC20(token).allowance(msg.sender, address(this));     
    }
}

Надеюсь кому-то интересна данная тема, потому что проект необычный и достаточно много функциональный, то есть очень много тем затрагивает, следовательно большой опыт знаний накапливается. Всем спасибо.

Оставляю кому интересно:

Мой тг канал
Этот проект на гитхабе

Всем привет. Сидел я тут как-то и думал, а почему бы не сделать свою автоматизированную банковскую систему на блокчейне и соблюсти почти все правила учета и отчетности от ЦБ РФ. Мне показалось это интересно и возможным сделать. Разумеется ЦБ не примет эту систему, но как для практики программирования идея думаю не плохая.

Буду создавать все в лайв режиме, поэтому не знаю получиться сделать все что задумал.

Теория

Начну с теории и что нам нужно будет сделать.

АБС (автоматизированная банковская система) это совокупность аппаратных средств и программ для создания информационной среды, которая выполняет управленческие и финансовые задачи в условии реального времени у банка.

Добавлю также, что не надо путать слова автоматизированные и автоматические. Автоматизированные, где человек принимает окончательное решение, а в автоматических машина.

То, что я делаю не может быть принято ЦБ, потому что есть нарушения с моей стороны ряда статей ФЗ "О ЦБ РФ". Поэтому рассматриваем этот проект как просто тренировка и закрепление знаний.

Также нужно понимать, что я не создаю банк. Я создаю вендор, который можно интегрировать (в теории) в свой банк на блокчейне, если вы его создадите.

Модули АБС:

Немного о модулях АБС.

Фрон-офис - это взаимодействие с клиентом
Бэк-офис - это функционал системы
Мидл-офис - это функционал проводки или бух учет.

На данной картинке выделены основные модули, которые нам нужно будет по идее реализовать. Но как я уже говорил, я делаю все в лайв режиме и не знаю на данный момент что получиться сделать, а что нет.

Бухгалтерский учет будет является транзакциями в блокчейне, поэтому как такового бух учета у нас не будет. Но называть я буду его все равно так.

Еще один из недостатков: у нас не будет наличного расчета :(.

Расписывать функционал каждого модуля не буду, потому что долго и не нужно. Когда будем подходить к реализации модуля, тогда и буду его объяснять.

Начало:

Начнем с реализации ядра.

Модуль является функциональным ядром интегрированной банковской системы

Что я реализую в ядре:

1. Тип клиента
2. Ведение счетов
3. Платежный документооборот
4. Безналичные расчеты
5. Картотеки (дебетовые и кредитные карты)
6. Валютный учет(основой сделаем доллар)
7. Хранение всей информации о платежах
8. Учет и отчетность

В данной статье я реализую все кроме:
Валютный учет
Безналичные расчеты
Учет и отчетность

Код

И так для начала кину весь код, который есть на данный момент:

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.9;
contract Core {    
    address owner;    
    constructor(){        
        owner = msg.sender;    
    }    
    struct client{        
        string name;        
        address clientOwner;         
        uint clientType;         
        bool accountDebet;        
        bool accountCredit;        
        bytes32[] paymentInfo;        
        document[] documents;    
    }    
    struct document{        
        uint typeDocument;        
        string documentInfo;        
        address document;    
    }    
    mapping(address=>mapping(uint=>bool)) initSubscribe;    
    mapping(address=>client) clients;    
    modifier onlyOwner() {        
        require(owner == msg.sender, "faild");        
        _;    
    }    
    function initializeClient(string calldata _name) public payable{        
        client storage newClientInfo = clients[msg.sender];        
        newClientInfo.name = _name;        
        newClientInfo.clientOwner = msg.sender;               
        newClientInfo.accountDebet = false;        
        newClientInfo.accountCredit = false;
        uint size;        
        address addr = msg.sender;        
        assembly {            
            size := extcodesize(addr)        
        }        
        if (size > 0) {            
            bytes4 expectedFunctionSignature = bytes4(keccak256("myFunction(uint256,address)"));            
            (bool success, ) = addr.call(abi.encodeWithSelector(expectedFunctionSignature, 1, addr)); 
            require(success, "faild");           
            if(success == true){                
                newClientInfo.clientType = 1;                
                newClientInfo.documents.push(document(0, "entity person", msg.sender));            
            }         
        }else{                
            newClientInfo.clientType = 0;                
            newClientInfo.documents.push(document(0, "natural person", msg.sender));            
        }         
        newClientInfo.paymentInfo.push(bytes32(keccak256(bytes("Create client"))));        
    }    
    function addAccountDebet() public{          
        require(msg.sender == clients[msg.sender].clientOwner);        
        initSubscribe[msg.sender][0] = true;    
    }    
    function addAccountCredit() public{          
        require(msg.sender == clients[msg.sender].clientOwner);        
        initSubscribe[msg.sender][1] = true;    
    }    
    function complitesubscribersAccount(address _client, uint typeAccount) public onlyOwner{        
        require(initSubscribe[_client][typeAccount] == true, "not complite");        
        require(typeAccount == 0 || typeAccount == 1, "error");        
        if(typeAccount == 0){            
            clients[_client].accountDebet = true;            
            initSubscribe[_client][typeAccount] = false;        
        }        
        if(typeAccount == 1){            
            clients[_client].accountCredit = true;            
            initSubscribe[_client][typeAccount] = false;        
        }    
    }    
    function deletAccountDebet() public{        
        require(msg.sender == clients[msg.sender].clientOwner);        
        require(clients[msg.sender].accountDebet == true, "not open");        
        initSubscribe[msg.sender][0] = true;    
    }    
    function deletAccountCredit() public{        
        require(msg.sender == clients[msg.sender].clientOwner);        
        require(clients[msg.sender].accountCredit == true, "not open");        
        initSubscribe[msg.sender][1] = true;    
    }    
    function comliteDeletAccount(address _client, uint typeAccount) public onlyOwner{        
        require(initSubscribe[_client][typeAccount] == true, "not complite");        
        require(typeAccount == 0 || typeAccount == 1, "error");        
        if(typeAccount == 0){            
            clients[_client].accountDebet = false;            
            initSubscribe[_client][typeAccount] = false;        
        }        
        if(typeAccount == 1){                      
            clients[_client].accountCredit = false;            
            initSubscribe[_client][typeAccount] = false;        
        }    
    }       
}

Сразу говорю, что не буду размусоливать его. Буду показывать основные моменты и общую концепцию. Это не конечная версия кода, будет еще все меняться и добавляться.

Итак:

Для начала я создаю структуру client которая будет содержать все данные клиента. И структуру document, которая должна содержать информацию о ценных бумагах или важных расписках например.

Дальше создаю маппинг, который будет нужен для подтверждения открытия счета initSubscribe. И маппинг для общего сбора всех клиентов clients.

Функции

Функция initializeClient будет нужна для регистрации клиента в банке. Будут ставиться дефолтные значения, которые в будущем можно менять открывая новые привилегии. Из интересного, я решил разделять юрлицо и физлицо на два типа: если клиент, это обычный адрес кошелька, он будет физлицом, если же смарт-контракт то юрлицо. Проверку делаю через ассемблер функцией проверки на наличие кода extcodesize. Но так как это не гарантирует, что вызов идет от смарт-контракта, я добавил условие, что каждый контракт должен иметь функцию check, которая вызывается при проверке низкоуровневым вызовом, чтоб убедиться в том, что данный вызов идет из стороннего смарт-контракта.

Функции addAccountDebet, addAccountCredit, deletAccountDebet, deletAccountCredit нужны для запроса открытия/закрытия счета в банке.

complitesubscribersAccount и comliteDeletAccount нужны для владельца который будет решать можно ли открыть данному лицу счет или нет

Я создал смарт-контракт, который хочет открыть счет в банке, чтоб удостовериться в работе моей концепции.

contract OtherContract {    
    address public coreAddress;     
    Core public coreInstance; 
    constructor(address _coreAddress) {        
        coreAddress = _coreAddress;        
        coreInstance = Core(coreAddress);    
    }    
    function check(uint num, address addr) public pure{
    }    
    function callInitializeClient(string calldata _name) external {        
        coreInstance.initializeClient(_name);    
    }
}

Тут все просто. Передаю адрес Core и после создаю экземпляр смарт-контракта.

Дальше обязательно добавляем функцию check и функцию callInitializeClient, которая вызывает initializeClient

Чтоб все проверить, я создал hardhat проект, где будут все тесты.

На гитхабе будет все, кто хочет посмотреть, то ссылка в конце статьи.

Если вы хотите проверить, или что то добавить пишите мне в тг. Его можно найти в профиле моего канала.

На этом я закончу эту статью. Пока что нет ни чего особенного и интересного, но в голове строится необычная картина. На данный момент я рассказал все, что хотел. Дальше больше. Вроде как таких похожих проектов не видел ни где, поэтому надеюсь зайдет кому-то.

Мой тг для связи в шапке канала
Мой тг канал
Этот проект на гитхабе

Привет всем! Сегодня пойдет речь о флэш кредитах. Эта тема для меня показалось очень крутой и перспективной, потому что идея очень революционна в своем базисе.

Как работают флэш кредиты?

Flashloans - это моментальный кредит без залога, почти на любую сумму, так еще и можно сказать беспроцентный, ты отдаешь сверху всего 0.05% от той суммы, которую взял.

Это стало возможным благодаря атомарности блокчейна. То есть все транзакции неделимы. Или как написано в википедии. Либо все, либо ничего.

Именно поэтому такие протоколы как Aave могут предложить вам кредит на любую сумму в рамках одного блока.

Конечно есть и минусы. В следствие того, что мы должны взять кредит и отдать в рамках одного блока получается так, что эти деньги не на долго у нас в кармане. Поэтому пока мало идей как использовать flashloan. Чаще всего их используют для арбитража dex.

Ну ладно. Эту информацию можно найти в интернете очень просто, поэтому приступим к написанию смарт-контракта для flashloans!

Если у вас нету node.js то скачиваем тут . Нам понадобиться команда npm от туда.

Устанавливаем последнюю версию npm

npm install -g npm
npm -v

Для начала создаем проект hardhat, я думаю все уже знают как это сделать, а кто нет, то это очень просто.

В своей папки проекта через cmd пишем 4 команды:

npm init
npm install --save-dev hardhat
npx hardhat
npm install --save-dev "hardhat@^2.14.0" "@nomicfoundation/hardhat-toolbox@^2.0.0"

Устанавливаем ядро aave, чтоб подгрузить все СК, которые импортируем

npm install @aave/core-v3

В папке contracts пишем новый смарт-контракт, а тот который предоставлен удаляем. Назовем его SimpleFlashLoan.

// SPDX-License-Identifier: MITpragma solidity ^0.8.9;
import "@aave/core-v3/contracts/flashloan/base/FlashLoanSimpleReceiverBase.sol";
import "@aave/core-v3/contracts/interfaces/IPoolAddressesProvider.sol";
import "@aave/core-v3/contracts/dependencies/openzeppelin/contracts/IERC20.sol";
contract SimpleFlashLoan is FlashLoanSimpleReceiverBase {    
    address payable owner;    
    string public str;    
    constructor(address _addressProvider) FlashLoanSimpleReceiverBase(IPoolAddressesProvider(_addressProvider)) {        
        owner = payable(msg.sender);    
    }
    function fn_RequestFlashLoan(address _token, uint256 _amount) public {       
        address receiverAddress = address(this);        
        address asset = _token;        
        uint256 amount = _amount;        
        bytes memory params = "";        
        uint16 referralCode = 0;
        POOL.flashLoanSimple(            
          receiverAddress,            
          asset,            
          amount,            
          params,            
          referralCode        
        );    
    }    
    function  executeOperation(        
      address asset,        
      uint256 amount,       
      uint256 premium,        
      address initiator,        
      bytes calldata params    
    )  external override returns (bool) {                
        str = "NEW Logic in FlashLoans!";                
        uint256 totalAmount = amount + premium;        
        IERC20(asset).approve(address(POOL), totalAmount);
        return true;    
    }
    receive() external payable {}
}

Очень простой смарт-контракт из четырех функций.

Переменные смарт-контракта:

owner - владелец СК

str - просто строка

Конструктор:

Наш конструктор будет вызывать конструктор из смарт-контракта FlashLoanSimpleReceiverBase, который мы наследуем. Внутри того конструктора, мы должны передать аргумент, адрес провайдера пула Aave. Где его брать покажу позже.

Переменная _addressProvider внутри FlashLoanSimpleReceiverBase будет обернута в интерфейс IPoolAddressesProvider, после чего там будет вызвана функция getPool(), которая вернет нам адрес Proxy Pool (контракт, который реализует все функции флэш кредитов). И все это сохранится в переменную POOL, которую нужно обернуть в интерфейс IPOOL, как и наш адрес, чтоб получить доступ к функция Proxy Pool контракта.

На самом деле с точки зрения механики этого процесса, это самое сложное тут. Но если не париться, то просто передаем в конструктор адрес провайдера пула.

Функция fn_RequestFlashLoan

Это функция флэш кредита, которую мы будем вызывать.

Как мы помним, наша переменная POOL имеет возможность вызывать функции FlashLoan. Мы будем использовать только flashLoanSimple.

Если посмотреть в интерфейс, то мы увидим какие параметры нам нужно передать:

 function flashLoanSimple(    
  address receiverAddress,    
  address asset,    
  uint256 amount,    
  bytes calldata params,    
  uint16 referralCode  
 ) external;
 

receiverAddress - получатель кредита, в нашем случае наш СК
address receiverAddress = address(this)

asset - по сути адрес токена, который мы хотим взять в долг (у нас это аргумент функции _token)

amount - ну тут понятно, что это количество токенов, которое берем в долг.

params - это какая-то доп информация к кредиту, например сообщение или фраза. В нашем случае пустая строка. (Если будете что то передавать, то не забудьте перевести информацию в байты)

referralCode - я честно так и не понял смысл этого параметра. В интерфейсе написано, что это регистрация интегратора, инициирующего операцию, для потенциального вознаграждения. Я так и не понял как это реализовать, поэтому пишем 0, так как мы будем выполнять операцию сами.

Дальше через нашу любимую переменную POOL из FlashLoanSimpleReceiverBase вызываем функцию flashLoanSimple и передам все параметры.

Функция executeOperation

Данная функция будет сама вызываться после того, как на счет нашего смарт-контракта придут средства.

Эту функцию нужно обязательно реализовать, так как она будет возвращать кредит. Эту функцию мы переопределяем, поэтому ее называем именно так. Без нее при вызове функции fn_RequestFlashLoan будет ошибка.

P.S внутри flashLoanSimple вызывается функция executeFlashLoanSimple в которой есть require, в котором идем проверка на то, что существует и правильно задана функция executeOperation со всеми параметрами. Там это делается очень хитро, поэтому забрать себе все токены не получиться, придется возвращать ((

По факту там такие же переменные как и в fn_RequestFlashLoan, помимо premium, переменная, которая отвечает за процент кредита. На сегодня это 0.05% от суммы.

Внутри функции мы можем производить логику с этими токенами, которые мы взяли в кредит. Для примера я задаю значение строке. Да, это не связано с токенами, но для простоты, я показал где нужно реализовывать логику. Дальше мы считаем токены, которые мы должны вернуть

Да с подсчетом токенов обмануть не получиться, я пробовал

После мы даем approve через интерфейс IERC20, на списание токенов и там они переводятся на адрес Pool proxy.

Хоть 2 последних аргумента мы не используем, они нужны для этой функции, иначе будет ошибка

Ура наш смарт-контракт FlashLoan готов. Давайте его развернем в сети Sepolia и проверим его работоспособность.

Теперь, где же брать адреса пулов и токенов:

Для тестнета тут

Нам нужна вкладка sepolia

PoolAddressesProvider-Aave 0x0496275d34753A48320CA58103d5220d394FF77F

Для маиннета тут

Мой скрипт деплоя:

const hre = require('hardhat');const ethers = hre.ethers;
const path = require('path');
async function main() {  
  const [deployer] = await ethers.getSigners();
  console.log("account deploy:", deployer.address);
  console.log("Account balance:", (await deployer.getBalance()).toString());
  const FlashLoan = await ethers.getContractFactory("SimpleFlashLoan"); //название контракта
  const FlashLoanDeploy = await FlashLoan.deploy("0x0496275d34753A48320CA58103d5220d394FF77F");  
  await FlashLoanDeploy.deployed()  
  console.log("address:", FlashLoanDeploy.address);
}
main()  
.then(() => process.exit(0))  
.catch((error) => {   
   console.error(error)    
 process.exit(1)  
})

Самый обычный скрипт на деплой. Думаю объяснять тут нечего.

Дальше как развернуть в любой сети наш смарт-контракт.

Способов много, я пользуюсь своим:

В качестве провайдера я использую Alchemy.

Регистрируемся и заходим в раздел apps - create app.

Тут выбираем сеть sepolia

Нажимаем create App и видим Api key и все остальное. Копируем HTTPS ссылку

Дальше я покажу мой hardhat.config.js

 require("@nomicfoundation/hardhat-toolbox");
const PRIVATE_KEY = "PRIVATE KEY"
module.exports = {  
  solidity: "0.8.17",  
  networks: {    
    sepolia: {      
      url: "https://eth-sepolia.g.alchemy.com/v2/API KEY",      
      chainId: 11155111,     
      accounts: [        
        PRIVATE_KEY      
      ],    
  },    
    goerli: {      
      url: "https://eth-goerli.g.alchemy.com/v2/API KEY",      
      chainId: 5,      
      accounts: [        
        PRIVATE_KEY      
      ],    
    },    
    main: {      
      url: "https://eth-mainnet.g.alchemy.com/v2/API KEY",      
      chainId: 1,      
      accounts: [        
        PRIVATE_KEY      
      ],    
    },    
    polygon: {      
      url: "https://polygon-mainnet.g.alchemy.com/v2/API KEY",      
      chainId: 137,      
      accounts: [        
        PRIVATE_KEY      
      ],    
    },  
  },
};

Вместо url вставляете скопированную ссылку HTTPS из alchemy.

Там где accounts вы должны вставить свой приватный ключ кошелька.

Где его взять:

Заходите в Metamask и нажимаете на Export Private key.

Там его копируете и в конфиг вставляете.

Все конфиг настрен, деплой скрипт готов.

Команда для запуска скрипта deploy.js в сети sepolia:

Если вы как я меняли deploy.js скрип в проекте hardhat, то вот команда для его запуска:

 npx hardhat run scripts\deploy.js --network sepolia

P.S сеть можно использовать любую

Главное чтоб у вас на аккаунте, у которого вы взяли Private Key были тестовые токены sepolia.

Взять токены можно тут

Если у вас все прошло четко, то ваш смарт-контракт уже в сети.

Заходим во вкладку mempool alchemy

Ваша транзакция в последней строчки или первая сверху

Нажимаете на HASH и потом переходим в transaction

Там будет address TO, переходим и видим наш смарт-контракт в etherscan

Во вкладке contracts нужно верифицировать ваш СК.

Для этого нажимаем на Verify and Publish.

Выбираем single File

Версию компилятора (Та которая у вас стоит в конфиге. У меня 0.8.17)

Выбираем вид лицензии. (Я использую MIT)

Дальше нам нужно вставить код смарт-контракта, но со всеми файлами, которые мы импортировали. Чтоб это сделать быстро и просто заходим в remix. Создаем новый файл и вставляем туда наш смарт-контракт

Тыкаем на наш смарт-контракт и нажимаем на flatten. Таким образом мы получим все смарт-контракты в одном файле Flashloans_flattened.sol в моем случае.

Заходим в него и первой строчкой добавляем лицензию. Он ее не добавляет. Это важно. После берем и все копируем.

Потом все вставляем в etherscane.

Нажимаем на verify and publish и ждем. Если все правильно, то идем обратно в наш смарт-контракт на etherscan

Чтоб затестить наш кредит мы должны передать чуть чуть токенов в наш контракт для комиссии кредита. Я буду использовать dai токены.

Важно. AAVE используют свои токены для тестовых сетей и чтоб их получить идем сюда

У названия токена нажимаем кнопку и добавляем их токен dai в метамаск

Нажимаем на подчеркнутую строчку и получим их токены DAI

ЭТО не настоящий DAI, а аля DAI от AAVE. Их создали для упрощения тестирования и, чтоб в их тестовых пулах было достаточно токенов для всех.

Переходим на смарт-контракт токена dai и переводим чуть чуть токенов (я переведу 1 токен) на наш смарт-контракт flashloan по его адресу.

amount в decimals, поэтому так много нулей.

Когда перевели токены на смарт-контракт flashloans, наконец, мы можем взять кредит!

Возвращаемся в наш смарт-контракт и вызываем функцию fn_RequestFlashLoan

Аргумент _token это адрес токена dai:

dai - 0x68194a729C2450ad26072b3D33ADaCbcef39D574

amount я взял 100 dai

_amount - 1000000000000000000000

После выполнения транзакции идем смотреть ее в etherscan

Если все прошло успешно то мы увидим:

ERC20 Tokens Transferred: На наш смарт-контракт перевели 100 токенов dai и потом их забрали с процентами. Все работает ура!

Если вы зайдете в Read Contract и откроете строчку, то там будет наше сообщение, которое мы установили в функции executeOperation.

На этом думаю можно закончить. У нас получилось реализовать Flashloan, это может не каждый рядовой пользователь как сказали AAVE в своей документации. Так что мы чуть чуть круче. Дальше больше. Возможно потом покажу как можно свапать токены которые мы взяли в кредит. Тоже интересно. Удачи!

tg: мой телеграмчик)

github: этот проект на гит хабе

Привет всем! Сегодня пойдет о самом популярном стандарте который есть на данный момент, это ERC721 или в простонародье NFT. Так как я понимаю, что это ну уж очень заезженная тема, я решил раскрыть ее немного с другой стороны, а именно, через upgrades.

Да я понимаю, что уже третья статья про proxy и upgradeable СК, но все таки тут будет достаточно полезно это улучшение. Ведь может быть случай, что вы создали свою коллекцию и она так завирусилась, что вы хотите например добавить функционал холдерам NFT и выдавать разные бонусы за их активность. Но если вы не сделали вашу NFT коллекцию обновляемой, то могут возникнуть сложности.

Расскажу одну вещь для общего развития. Из за своей популярности NFT, многие стали думать, что NFT это картинка. НО, я хочу быть уверенным, что вы так не думаете. Потому что NFT, это non-fungible token или невзаимозаменяемые токены. То есть это токены, которые не могут быть поделены на части, и поэтому у них нет decemals, как у ЕРС20. Да, эта особенность позволила нам прикреплять за токеном какое то изображение, звук, видео или еще что-то, а можно и не прикреплять, в любом случае, это не меняет его сущность этих токенов

К чему я вел это долгое вступление?

Очень много людей стали хейтить разработчиков NFT за то, что они хранят данные прикреплённые к токену, например изображения, на внешних платформах, таких как filecoin и другие. Мол это ни фига не NFT. Они же их хранят в базе данных и каждый может получить к ним доступ. Формально это так, но нужно понимать, что хранение изображений в блокчейне будет стоить космических денег. Поэтому была и предложена эта реализация хранения. Причем если смотреть глубже, то чаще всего используется протокол ipfs, который генерирует ссылку через хэшировние криптографическими методами, для получения уникального и не повторимого cid, который уже используется в NFT. Сорян подгорело. У меня все.

IERC721Upgradeable

 // SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
import "./IERC165Upgradeable.sol";
interface IERC721Upgradeable is IERC165Upgradeable {       
    event Transfer(address indexed from, address indexed to, uint256 indexed tokenId);
    event Approval(address indexed owner, address indexed approved, uint256 indexed tokenId);
    event ApprovalForAll(address indexed owner, address indexed operator, bool approved);
    function balanceOf(address owner) external view returns (uint256 balance);
    function ownerOf(uint256 tokenId) external view returns (address owner);
    function safeTransferFrom(        
      address from,        
      address to,        
      uint256 tokenId,        
      bytes calldata data    
    ) external;
    function safeTransferFrom(        
      address from,        
      address to,        
      uint256 tokenId    
    ) external;
    function transferFrom(        
      address from,        
      address to,        
      uint256 tokenId    
    ) external;
    function approve(address to, uint256 tokenId) external;
    function setApprovalForAll(address operator, bool _approved) external;
    function getApproved(uint256 tokenId) external view returns (address operator);
    function isApprovedForAll(address owner, address operator) external view returns (bool);}

Это обычный интерфейс ERC721 ни чего особенного. Даже чем то похож на ERC20. Я не буду объяснять что здесь за функции, и сделаю это по мере реализации стандарта дальше. Думаю так будет понятнее.

ERC721Upgradeable

 // SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
import "./IERC721Upgradeable.sol";
import "./IERC721ReceiverUpgradeable.sol";
import "./IERC721MetadataUpgradeable.sol";
import "./utils/AddressUpgradeable.sol";
import "./utils/ContextUpgradeable.sol";
import "./utils/StringsUpgradeable.sol";
import "./ERC165Upgradeable.sol";
import "./utils/Initializable.sol";
contract ERC721Upgradeable is Initializable, ContextUpgradeable, ERC165Upgradeable, IERC721Upgradeable, IERC721MetadataUpgradeable {    using AddressUpgradeable for address;    using StringsUpgradeable for uint256;
    string private _name;
    string private _symbol;
    mapping(uint256 => address) private _owners;
    mapping(address => uint256) private _balances;
    mapping(uint256 => address) private _tokenApprovals;
    mapping(address => mapping(address => bool)) private _operatorApprovals;
    function __ERC721_init(string memory name_, string memory symbol_) internal onlyInitializing {        
        __ERC721_init_unchained(name_, symbol_);    
    }
    function __ERC721_init_unchained(string memory name_, string memory symbol_) internal onlyInitializing {        
        _name = name_;        
        _symbol = symbol_;    
    }
    function supportsInterface(bytes4 interfaceId) public view virtual override(ERC165Upgradeable, IERC165Upgradeable) returns (bool) {        
        return            
          interfaceId == type(IERC721Upgradeable).interfaceId ||            
          interfaceId == type(IERC721MetadataUpgradeable).interfaceId ||            
          super.supportsInterface(interfaceId);    
    }
    function balanceOf(address owner) public view virtual override returns (uint256) {        
        require(owner != address(0), "ERC721: address zero is not a valid owner");        
        return _balances[owner];    
    }
    function ownerOf(uint256 tokenId) public view virtual override returns (address) {       
        address owner = _ownerOf(tokenId);        
        require(owner != address(0), "ERC721: invalid token ID");        
        return owner;    
    }
    function name() public view virtual override returns (string memory) {        
        return _name;    
    }
    function symbol() public view virtual override returns (string memory) {        
        return _symbol;    
    }
    function tokenURI(uint256 tokenId) public view virtual override returns (string memory) {        
        _requireMinted(tokenId);
        string memory baseURI = _baseURI();        
        return bytes(baseURI).length > 0 ? string(abi.encodePacked(baseURI, tokenId.toString())) : "";    
    }
    function _baseURI() internal view virtual returns (string memory) {        
        return "";    
    }
    function approve(address to, uint256 tokenId) public virtual override {       
        address owner = ERC721Upgradeable.ownerOf(tokenId);        
        require(to != owner, "ERC721: approval to current owner");
        require(            
        _msgSender() == owner || isApprovedForAll(owner, _msgSender()), 
         "ERC721: approve caller is not token owner or approved for all"        );
        _approve(to, tokenId);    
    }
    function getApproved(uint256 tokenId) public view virtual override returns (address) {        
        _requireMinted(tokenId);
        return _tokenApprovals[tokenId];    
    }
    function setApprovalForAll(address operator, bool approved) public virtual override {        
        _setApprovalForAll(_msgSender(), operator, approved);    
    }
    function isApprovedForAll(address owner, address operator) public view virtual override returns (bool) {        
        return _operatorApprovals[owner][operator];    
    }
    function transferFrom(        
      address from,       
      address to,        
      uint256 tokenId    
    ) public virtual override {        
        require(_isApprovedOrOwner(_msgSender(), tokenId), "ERC721: caller is not token owner or approved");
        _transfer(from, to, tokenId);   
    }
    function safeTransferFrom(        
      address from,        
      address to,       
      uint256 tokenId    
    ) public virtual override {        
        safeTransferFrom(from, to, tokenId, "");    
    }
    function safeTransferFrom(        
      address from,        
      address to,        
      uint256 tokenId,        
      bytes memory data    
    ) public virtual override {       
        require(_isApprovedOrOwner(_msgSender(), tokenId), "ERC721: caller is not token owner or approved");        
        _safeTransfer(from, to, tokenId, data);    
    }
    function _safeTransfer(        
      address from,       
      address to,        
      uint256 tokenId,        
      bytes memory data    
    ) internal virtual {       
        _transfer(from, to, tokenId);       
        require(_checkOnERC721Received(from, to, tokenId, data), "ERC721: transfer to non ERC721Receiver implementer");    
    }
    function _ownerOf(uint256 tokenId) internal view virtual returns (address) {        
        return _owners[tokenId];    
    }
    function _exists(uint256 tokenId) internal view virtual returns (bool) {        
        return _ownerOf(tokenId) != address(0);    
    }
    function _isApprovedOrOwner(address spender, uint256 tokenId) internal view virtual returns (bool) {       
        address owner = ERC721Upgradeable.ownerOf(tokenId);        
        return (spender == owner || isApprovedForAll(owner, spender) || getApproved(tokenId) == spender);    
    }      
    function _safeMint(address to, uint256 tokenId) internal virtual {        
        _safeMint(to, tokenId, "");    
    }
    function _safeMint(        
      address to,        
      uint256 tokenId,        
      bytes memory data    
    ) internal virtual {        
        _mint(to, tokenId);        
        require(            
        _checkOnERC721Received(address(0), to, tokenId, data),            
        "ERC721: transfer to non ERC721Receiver implementer");    
    }
   function _mint(address to, uint256 tokenId) internal virtual {        
        require(to != address(0), "ERC721: mint to the zero address");        
        require(!_exists(tokenId), "ERC721: token already minted");
        _beforeTokenTransfer(address(0), to, tokenId, 1);
        require(!_exists(tokenId), "ERC721: token already minted");
        unchecked {           
            _balances[to] += 1;        
        }
        _owners[tokenId] = to;
        emit Transfer(address(0), to, tokenId);
        _afterTokenTransfer(address(0), to, tokenId, 1);    
    }
    function _burn(uint256 tokenId) internal virtual {       
        address owner = ERC721Upgradeable.ownerOf(tokenId);
        _beforeTokenTransfer(owner, address(0), tokenId, 1);
        owner = ERC721Upgradeable.ownerOf(tokenId);
        delete _tokenApprovals[tokenId];
        unchecked {           
            _balances[owner] -= 1;        
        }        
        delete _owners[tokenId];
        emit Transfer(owner, address(0), tokenId);
        _afterTokenTransfer(owner, address(0), tokenId, 1);    
    }
    function _transfer(        
      address from,       
      address to,        
      uint256 tokenId    
    ) internal virtual {        
        require(ERC721Upgradeable.ownerOf(tokenId) == from, "ERC721: transfer from incorrect owner");        
        require(to != address(0), "ERC721: transfer to the zero address");
        _beforeTokenTransfer(from, to, tokenId, 1);
        require(ERC721Upgradeable.ownerOf(tokenId) == from, "ERC721: transfer from incorrect owner");        delete _tokenApprovals[tokenId];
        unchecked {           
            _balances[from] -= 1;           
            _balances[to] += 1;        
        }        
        _owners[tokenId] = to;
        emit Transfer(from, to, tokenId);
        _afterTokenTransfer(from, to, tokenId, 1);    
    }
    function _approve(address to, uint256 tokenId) internal virtual {       
        _tokenApprovals[tokenId] = to;        
        emit Approval(ERC721Upgradeable.ownerOf(tokenId), to, tokenId);    
    }
    function _setApprovalForAll(        
      address owner,        
      address operator,       
      bool approved    
    ) internal virtual {        
      require(owner != operator, "ERC721: approve to caller");        
      _operatorApprovals[owner][operator] = approved;        
      emit ApprovalForAll(owner, operator, approved);    
    }
    function _requireMinted(uint256 tokenId) internal view virtual {        
        require(_exists(tokenId), "ERC721: invalid token ID");    
    }
    function _checkOnERC721Received(        
      address from,        
      address to,        
      uint256 tokenId,        
      bytes memory data    
    ) private returns (bool) {        
        if (to.isContract()) {            
            try IERC721ReceiverUpgradeable(to).onERC721Received(_msgSender(), from, tokenId, data) returns (bytes4 retval) {               
                return retval == IERC721ReceiverUpgradeable.onERC721Received.selector;            
            } catch (bytes memory reason) {                
                if (reason.length == 0) {                    
                    revert("ERC721: transfer to non ERC721Receiver implementer");               
                } else {                    
                    assembly {                        
                        revert(add(32, reason), mload(reason))                    
                    }                
                }            
            }        
        } else {            
            return true;        
        }
    }
    function _beforeTokenTransfer(        
        address from,        
        address to,       
         uint256 firstTokenId,        
         uint256 batchSize   
    ) internal virtual {}
    function _afterTokenTransfer(        
      address from,        
      address to,       
      uint256 firstTokenId,        
      uint256 batchSize    
    ) internal virtual {}
    function __unsafe_increaseBalance(address account, uint256 amount) internal {       
        _balances[account] += amount;    
    }    
    uint256[44] private __gap;
 }

Маппинги:

mapping(uint256 => address) private _owners;
mapping(address => uint256) private _balances;
mapping(uint256 => address) private _tokenApprovals;
mapping(address => mapping(address => bool)) private _operatorApprovals;

Первый маппинг будет хранить адрес владельца токена по его индексу.

Второй маппинг будет хранить баланс токенов у владельца

Третий маппинг будет хранить индекс токена на перевод по адресу

Четвертый маппинг будет хранить разрешение на перевод всех токенов сразу у его владельца (этих токенов), какому то человеку.

Пройдемся по функциям основного контракта:

__init__

 function __ERC721_init(string memory name_, string memory symbol_) internal onlyInitializing {        
        __ERC721_init_unchained(name_, symbol_);    
    }
    function __ERC721_init_unchained(string memory name_, string memory symbol_) internal onlyInitializing {        
        _name = name_;        
        _symbol = symbol_;    
    }

Эти функции нам нужны для определения названия и символа токенов, потому что в обновляемых смарт-контрактах как мы знаем нельзя использовать конструктор.

supportsInterface

 function supportsInterface(bytes4 interfaceId) public view virtual override(ERC165Upgradeable, IERC165Upgradeable) returns (bool) {        
        return            
          interfaceId == type(IERC721Upgradeable).interfaceId ||            
          interfaceId == type(IERC721MetadataUpgradeable).interfaceId ||            
          super.supportsInterface(interfaceId);    
    }

Регистрирует контракт как средство реализации интерфейса, определенного селектора interfaceId. Просто вернет информацию о том, что СК поддерживает интерфейсы IERC721Upgradeable и IERC721MetadataUpgradeable.

balanceOf и ownerOf

function balanceOf(address owner) public view virtual override returns (uint256) {        
        require(owner != address(0), "ERC721: address zero is not a valid owner");        
        return _balances[owner];    
    }
    function ownerOf(uint256 tokenId) public view virtual override returns (address) {       
        address owner = _ownerOf(tokenId);        
        require(owner != address(0), "ERC721: invalid token ID");        
        return owner;    
    }
    function _exists(uint256 tokenId) internal view virtual returns (bool) {        
        return _ownerOf(tokenId) != address(0);    
    }

Функция balanceOf вернет баланс токенов у адреса. Функция ownerOf вернет владельца токена, вызвав _ownerOf и проверит, что адрес не нулевой. Все происходит через маппинги.

name и symbol

  function name() public view virtual override returns (string memory) {        
        return _name;    
    }
    function symbol() public view virtual override returns (string memory) {        
        return _symbol;    
    }

Вернут имя и символ токена как в ERC20

Функции tokenURI и _baseURI

 function tokenURI(uint256 tokenId) public view virtual override returns (string memory) {        
        _requireMinted(tokenId);
        string memory baseURI = _baseURI();        
        return bytes(baseURI).length > 0 ? string(abi.encodePacked(baseURI, tokenId.toString())) : "";    
    }
    function _baseURI() internal view virtual returns (string memory) {        
        return "";    
    }

_baseURI это общее начало у ссылки на вашу картинку если простым языком. tokenURI возвращает картинку к которой прикреплен данный токен. Это так сказать наши метаданные. Ведь все любят NFT не за то, что они являются не взаимозаменяемыми токенами, а за то, что они дают нам возможность прикреплять за ними свое "искусство" и делать его уникальным. Функцию _requireMinted напишем позже, но она просто проверяет, что такой токен существует.

Approve функции

function approve(address to, uint256 tokenId) public virtual override {       
        address owner = ERC721Upgradeable.ownerOf(tokenId);        
        require(to != owner, "ERC721: approval to current owner");
        require(_msgSender() == owner || isApprovedForAll(owner, _msgSender()), 
         "ERC721: approve caller is not token owner or approved for all");
        _approve(to, tokenId);    
    }
    function getApproved(uint256 tokenId) public view virtual override returns (address) {        
        _requireMinted(tokenId);
        return _tokenApprovals[tokenId];    
    }
    function setApprovalForAll(address operator, bool approved) public virtual override {        
        _setApprovalForAll(_msgSender(), operator, approved);    
    }
    function isApprovedForAll(address owner, address operator) public view virtual override returns (bool) {        
         return _operatorApprovals[owner][operator];    
    }
     function _isApprovedOrOwner(address spender, uint256 tokenId) internal view virtual returns (bool) {       
        address owner = ERC721Upgradeable.ownerOf(tokenId);        
        return (spender == owner || isApprovedForAll(owner, spender) || getApproved(tokenId) == spender);    
    } 
    function _approve(address to, uint256 tokenId) internal virtual {       
        _tokenApprovals[tokenId] = to;        
        emit Approval(ERC721Upgradeable.ownerOf(tokenId), to, tokenId);    
    }
    function _setApprovalForAll(        
      address owner,        
      address operator,       
      bool approved    
    ) internal virtual {        
      require(owner != operator, "ERC721: approve to caller");        
      _operatorApprovals[owner][operator] = approved;        
      emit ApprovalForAll(owner, operator, approved);    
    }

approve функция как и в ERC20 дает нам разрешение на списывание токенов с нашего аккаунта. В начале передаем переменной owner владельца токена, который мы передали, после чего мы проверяем является ли человек, который вызвал функцию владельцем данного токена. Если да то вызывается функция _approve, где мы даем разрешение адресу to.

getApproved просто вернет адрес, кому был дан апрув. С проверкой, что такой токен существует.

setApprovalForAll устанавливает разрешение на перевод всех токенов, которые есть у человека. То есть если у вас 5 nft данного проекта, то вы даете разрешение на перевод всех пяти токенов. Вызывает внутри функцию _setApprovalForAll, где мы можем либо дать разрешение на все токены, либо убрать. (По маппингу это делаем)

_isApprovedOrOwner будет проверять: дано разращение или нет. Обращается к getApproved и к isApprovedForAll, таким образом мы узнаем информацию сразу про все случаи разрешения. И так же узнает является ли владелец токена его владельцем как не странно.

Функции transfer

 function transferFrom(        
      address from,       
      address to,        
      uint256 tokenId    
    ) public virtual override {        
        require(_isApprovedOrOwner(_msgSender(), tokenId), "ERC721: caller is not token owner or approved");
        _transfer(from, to, tokenId);   
    }
    function safeTransferFrom(        
      address from,        
      address to,       
      uint256 tokenId    
    ) public virtual override {        
        safeTransferFrom(from, to, tokenId, "");    
    }
    function safeTransferFrom(        
      address from,        
      address to,        
      uint256 tokenId,        
      bytes memory data    
    ) public virtual override {       
        require(_isApprovedOrOwner(_msgSender(), tokenId), "ERC721: caller is not token owner or approved");        
        _safeTransfer(from, to, tokenId, data);    
    }
    function _safeTransfer(        
      address from,       
      address to,        
      uint256 tokenId,        
      bytes memory data    
    ) internal virtual {       
        _transfer(from, to, tokenId);       
        require(_checkOnERC721Received(from, to, tokenId, data), "ERC721: transfer to non ERC721Receiver implementer");    
    }
    function _transfer(        
      address from,       
      address to,        
      uint256 tokenId    
    ) internal virtual {        
        require(ERC721Upgradeable.ownerOf(tokenId) == from, "ERC721: transfer from incorrect owner");        
        require(to != address(0), "ERC721: transfer to the zero address");
        _beforeTokenTransfer(from, to, tokenId, 1);
        require(ERC721Upgradeable.ownerOf(tokenId) == from, "ERC721: transfer from incorrect owner");        delete _tokenApprovals[tokenId];
        unchecked {           
            _balances[from] -= 1;           
            _balances[to] += 1;        
        }        
        _owners[tokenId] = to;
        emit Transfer(from, to, tokenId);
        _afterTokenTransfer(from, to, tokenId, 1);    
    }
    

transferFrom Переводит токен, и проверяет дано было разрешение или нет через _isApprovedOrOwner. Ну и вызывает _transfer. Там снова идет проверка, что данный вызов от овенра токена и то, что получатель не нулевой адрес. _beforeTokenTransfer это функция каких то идей перед переводом, но их нет, и дальше смотрим, что эти идеи не привели к тому, что владелец токена поменялся (а вдруг идеи есть). После просто переводим токен. В маппенге владельцев мы меняем владельца токена. Сорри за многочисленную тавтологию. Ну и там мы можем вызвать функцию _afterTokenTransfer идей, которых нет после перевода как всегда.

safeTransferFrom делает все тоже самое, но эту функцию рекомендуют использовать по возможности вместо transferFrom из за одной особенности:

_checkOnERC721Received

function _checkOnERC721Received(        
      address from,        
      address to,        
      uint256 tokenId,        
      bytes memory data    
    ) private returns (bool) {        
        if (to.isContract()) {            
            try IERC721ReceiverUpgradeable(to).onERC721Received(_msgSender(), from, tokenId, data) returns (bytes4 retval) {               
                return retval == IERC721ReceiverUpgradeable.onERC721Received.selector;            
            } catch (bytes memory reason) {                
                if (reason.length == 0) {                    
                    revert("ERC721: transfer to non ERC721Receiver implementer");               
                } else {                    
                    assembly {                        
                        revert(add(32, reason), mload(reason))                    
                    }                
                }            
            }        
        } else {            
            return true;        
        }
    }

Данная особенность в safeTransferFrom заключается в том, что мы проверяем случай перевода на другой СК, так как мы помнем, что смарт-контракты также как и адресы кошельков могут владеть токенами. И если такой случай произошел. (isContract из прошлой статьи). Мы будем смотреть, что смарт-контракт, который хочет перевести токены поддерживает интерфейс IERC721ReceiverUpgradeable. Если да, то вызывается функция onERC721Received, и возвращается селектор, этот селектор должен быть равен селектору onERC721Received, если это не произошло, то мы откатываем транзакцию. И через ассемблер получаем причину отката. Это нужно для того, чтоб мы внутри СК, который делает этот вызов не делали разные пакости при переводе.

Функции mint

 function _safeMint(address to, uint256 tokenId) internal virtual {        
        _safeMint(to, tokenId, "");    
    }
    function _safeMint(        
      address to,        
      uint256 tokenId,        
      bytes memory data    
    ) internal virtual {        
        _mint(to, tokenId);        
        require(            
        _checkOnERC721Received(address(0), to, tokenId, data),            
        "ERC721: transfer to non ERC721Receiver implementer");    
    }
   function _mint(address to, uint256 tokenId) internal virtual {        
        require(to != address(0), "ERC721: mint to the zero address");        
        require(!_exists(tokenId), "ERC721: token already minted");
        _beforeTokenTransfer(address(0), to, tokenId, 1);
        require(!_exists(tokenId), "ERC721: token already minted");
        unchecked {           
            _balances[to] += 1;        
        }
        _owners[tokenId] = to;
        emit Transfer(address(0), to, tokenId);
        _afterTokenTransfer(address(0), to, tokenId, 1);    
    }
    function _burn(uint256 tokenId) internal virtual {       
        address owner = ERC721Upgradeable.ownerOf(tokenId);
        _beforeTokenTransfer(owner, address(0), tokenId, 1);
        owner = ERC721Upgradeable.ownerOf(tokenId);
        delete _tokenApprovals[tokenId];
        unchecked {           
            _balances[owner] -= 1;        
        }        
        delete _owners[tokenId];
        emit Transfer(owner, address(0), tokenId);
        _afterTokenTransfer(owner, address(0), tokenId, 1);    
    }
     function _requireMinted(uint256 tokenId) internal view virtual {        
        require(_exists(tokenId), "ERC721: invalid token ID");    
    }

_safeMint это функция чеканки новых токенов. Мы можем делать ограничение или его не делать (supply). Но это уже надо в своем СК если хотите. А мы же вызываем _mint, где и происходит чеканка. Так же мы не забываем проверить, что функцию минт не хотят хакнуть, через _checkOnERC721Received

Второй _safeMint дает нам возможность еще передать данные data при минте

Минт работает по принципу: кто вызвал, тот и получил токен. Перед пополнением баланса мы должны сделать ряд проверок, что вызываемый адрес не нулевой, что такой токен по id не был уже заминчен. Ну и установить владельца данного токена через маппинг.

_burn логично, что удаляет токены у того, кто вызвал эту функцию.

_requireMinted, функция, которая помогает нам определить является ли этот токен уже заминченым.

функции ownerOf и exists

function _ownerOf(uint256 tokenId) internal view virtual returns (address) {        
        return _owners[tokenId];    
    }

exists вернет true или false, если токен существует или нет.

В целом весь стандарт реализован

ERC721URIStorageUpgradeable

 // SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
import "./ERC721Upgradeable.sol";
import "./utils/Initializable.sol";
abstract contract ERC721URIStorageUpgradeable is Initializable, ERC721Upgradeable {    
    function __ERC721URIStorage_init() internal onlyInitializing {    
    }
    function __ERC721URIStorage_init_unchained() internal onlyInitializing {    
    }    
    using StringsUpgradeable for uint256;
    mapping(uint256 => string) private _tokenURIs;
    function tokenURI(uint256 tokenId) public view virtual override returns (string memory) {        
        _requireMinted(tokenId);
        string memory _tokenURI = _tokenURIs[tokenId];        
        string memory base = _baseURI();
        if (bytes(base).length == 0) {            
            return _tokenURI;        
        }        
        if (bytes(_tokenURI).length > 0) {            
            return string(abi.encodePacked(base, _tokenURI));        
        }
        return super.tokenURI(tokenId);    
    }
    function _setTokenURI(uint256 tokenId, string memory _tokenURI) internal virtual {        
        require(_exists(tokenId), "ERC721URIStorage: URI set of nonexistent token");        
        _tokenURIs[tokenId] = _tokenURI;    
    }
    function _burn(uint256 tokenId) internal virtual override {        
        super._burn(tokenId);
        if (bytes(_tokenURIs[tokenId]).length != 0) {            
            delete _tokenURIs[tokenId];        
        }    
    }
    uint256[49] private __gap;
}

Этот контракт помогает нам хранить метаданные по id токена.

mapping(uint256 => string) private _tokenURIs;

Хранит по маппингу ссылку на метаданные токена.

tokenURI делает тоже самое, что и в самом стандарте.

_setTokenURI устанавливает токену ссылку на метаданные.

_burn стирает метаданные из токена. Таким образом можно перезаписать их в случае необходимости.

В целом это весь стандарт. Конечно тут можно добавить кучу дополнений, но мы говорим про сам стандарт, поэтому без воды.

Пишем свой ERC721Upgradeabl проект.

Так как я уже говорил ранее, что не вижу смысла изобретать велосипед в proxy СК, то мы будем брать готовое решение из openzeppelin.

Для создания своего проекта будем использовать Wizard

 // SPDX-License-Identifier: MIT pragma solidity ^0.8.9; 
 import "@openzeppelin/contracts-upgradeable/token/ERC721/ERC721Upgradeable.sol"; 
 import "@openzeppelin/contracts-upgradeable/token/ERC721/extensions/ERC721URIStorageUpgradeable.sol"; 
 import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol"; 
 import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol"; 
 import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol"; 
 import "@openzeppelin/contracts-upgradeable/utils/CountersUpgradeable.sol"; 
 contract MyToken is Initializable, ERC721Upgradeable, ERC721URIStorageUpgradeable, OwnableUpgradeable, UUPSUpgradeable { 
     using CountersUpgradeable for CountersUpgradeable.Counter;
     CountersUpgradeable.Counter private _tokenIdCounter;
      
     function initialize() initializer public { 
         __ERC721_init("MyToken", "MTK"); 
         __ERC721URIStorage_init(); 
         __Ownable_init(); 
         __UUPSUpgradeable_init(); 
     } 
     function _baseURI() internal pure override returns (string memory) { 
         return "https://"; 
     }
     function safeMint(address to, string memory uri) public onlyOwner { 
         uint256 tokenId = _tokenIdCounter.current(); 
         _tokenIdCounter.increment();
         _safeMint(to, tokenId); 
         _setTokenURI(tokenId, uri); 
     } 
     function _authorizeUpgrade(address newImplementation) internal onlyOwner override {}
     function _burn(uint256 tokenId) internal override(ERC721Upgradeable, ERC721URIStorageUpgradeable) { 
         super._burn(tokenId); 
     } 
     function tokenURI(uint256 tokenId) public view override(ERC721Upgradeable, ERC721URIStorageUpgradeable) returns (string memory) { 
         return super.tokenURI(tokenId); 
     } 
}

Чтоб все библиотеки подтянулись мы должны импортировать их

 npm install @openzeppelin/contracts-upgradeable

Так же, чтоб работали скрипты для деплоя

 npm install --save-dev @openzeppelin/hardhat-upgrades

И импортируем в hardhat.config.js

 require('@openzeppelin/hardhat-upgrades');

Я надеюсь что такое hardhat объяснять не надо, но если что, то у меня есть уже статьи про это. Или посмотрите документация про деплой через hardhat тут

Так вот сверху уже готовый NFT смарт-контракт для деплоя.

Первая переменная будет счетчиком наших токенов. Это структура Counter с одной переменной uint из СК CounterUpgradeable. И так же мы для нее подключили библиотеку c математическими операциями.

Вместо конструктора для деплоя мы используем функцию initialize, где передаем название и символ токена.

_baseURI вернет начало ссылки на токен. Ну я поставил https:// но можно и свое.

safeMint функция покупки нфт, или чеканка. Можно ее использовать для своих минтинг сайтов. Внутри мы прибавляем на один _tokenIdCounter и разумеется в переменную tokenId передаем номер NFT. После мы просто вызываем функцию safeMint, где привязываем к адресу to текущий id NFT. Ну и устанавливаем uri для того, чтоб мы могли ей передать метаданные.

_authorizeUpgrade обязательная функция для UUPS proxy как мы помним.

tokenURI возвращает метаданные токена по id, например чтоб вывести их на экран на сайте.

super означает вызвать функцию из дочернего контракта, где она есть.

В целом как деплоить обновляемые контракты я показывал в прошлой статье, поэтому не буду повторяться, но могу сказать что тут все ровно тоже самое

Думаю на этом все. Сегодня я рассказал про ERC721, но не про обычную его реализацию а про upgradeable. Дальше больше. Я считаю это на много интереснее, чем читать про обычный заезженный стандарт, который уже каждый второй об шерстил вдоль и поперек. Удачи!

Полезные ссылки:

Wizard

Как деплоить СК

Деплой через upgade

Деплой ERC721Upgradeable

Стандарт ERC721

tg: мой телеграмчик)

Всем привет, сегодня пойдет речь о proxy, и стандарте ERC1967. В прошлой статье, а уже рассказывал про этот паттерн, но в этот раз мы подробно рассмотрим его и напишем сами с нуля.

Начну с того, что есть два типа proxy upgradeable smart-contract. Первый тип это Transparent, а второй UUPS.

Transparent более старый тип, он работает по принципу все обновление и администрирования происходит в самом proxy. Это более затратно по газу, но более понятно с точки зрения логики.

UUPS более новый тип и более актуальный на данный момент. Он работает по принципу обновление и администрирования происходит в самой реализации. То есть все функции для обновления и администрирования находятся в самом смарт контракте, а не в proxy. По факту мы увидим, что для нашего смарт-контракта, который мы хотим обновлять нам понадобиться просто унаследовать контракт UUPSUpgradeable, и реализовать все функции для обновления.

Как вы поняли мы идем в ногу со временем, и поэтому рассмотрим второй тип proxy.

Начнем по порядку. У нас будет много разных смарт-контрактов и давайте я вам объясню для чего каждый из них будет нужен, а потом мы их разберем.

Proxy.sol - этот смарт-контракт вы может помните из прошлой статьи. Он реализует наш вызов delegatecall, на СК

initializable.sol - этот смарт-контракт позволит нам создать псевдо конструктор, об этом по подробнее позже.

ERC1967Upgrade.sol - смарт-контракт, который реализует все наши функции установки и обновления Implementation и слотов для них.

ERC1967.sol - смарт-контракт, который реализует обновляемый proxy, то есть наследует все из ERC1967Upgrade.sol

Address.sol - смарт-контракт, который будет нам помогать проверять адрес СК и делегировать вызовы. В общем небольшая утилита.

StorageSlot.sol - смарт-контракт, который поможет с записью и чтением информации в слоты, чтоб избежать конфликтов с обновляемыми СК.

P.S если не понятно о каких слотах идет речь и об их проблеме поймете по позже

Так же понадобиться интерфейс IERC1822.sol, для проверки адреса Implementation

Разбор контрактов

Proxy

 // SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
abstract contract Proxy {
    function _delegate(address implementation) internal virtual {        
        assembly {
            calldatacopy(0, 0, calldatasize())
            let result := delegatecall(gas(), implementation, 0, calldatasize(), 0, 0)
            returndatacopy(0, 0, returndatasize())
            switch result            
            case 0 {                
                revert(0, returndatasize())            
            }            
            default {                
                return(0, returndatasize())            
            }        
        }    
    }    
    function _implementation() internal view virtual returns (address);
    
    function _fallback() internal virtual {        
        _beforeFallback();        
        _delegate(_implementation());    
    }
    fallback() external payable virtual {        
        _fallback();    
    }
    receive() external payable virtual {        
        _fallback();    
    }
    function _beforeFallback() internal virtual {}
}

Об этом СК я уже рассказывал, и поэтому не буду подробно останавливаться. Здесь есть функция _delegate, которая на низкоуровневом языке делает вызов delegatecall и таким образом вызывает функции у Implementation, то есть у нашего СК. Чтоб мы могли вызывать все функции СК, то мы используем fallback функцию, которая вызывается всегда, когда в смарт-контракт попадает функция, которой не существует. И таким не хитрым способом Proxy получает доступ ко всем функциям нашего СК.

Address

 // SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
library Address {        
    function isContract(address account) internal view returns (bool) {
        return account.code.length > 0;    
    }
    function functionDelegateCall(address target, bytes memory data) internal returns (bytes memory) {        
        return functionDelegateCall(target, data, "Address: low-level delegate call failed");    
    }
    function functionDelegateCall(        
        address target,        
        bytes memory data,        
        string memory errorMessage    
    ) internal returns (bytes memory) {        
        (bool success, bytes memory returndata) = target.delegatecall(data);        
        return verifyCallResultFromTarget(target, success, returndata, errorMessage);    
    }
    function verifyCallResultFromTarget(        
      address target,        
      bool success,       
      bytes memory returndata,        
      string memory errorMessage    
    ) internal view returns (bytes memory) {        
        if (success) {            
            if (returndata.length == 0) {                            
                require(isContract(target), "Address: call to non-contract");            
            }            
            return returndata;        
        } else {            
            _revert(returndata, errorMessage);        
        }    
    }
    function _revert(bytes memory returndata, string memory errorMessage) private pure {        
        if (returndata.length > 0) {            
            assembly {                
                let returndata_size := mload(returndata)                
                revert(add(32, returndata), returndata_size)            
            }        
        } else {            
            revert(errorMessage);        
        }    
    }
}

На самом деле в openzeppelin там еще есть функции в этом СК, но они нам не нужны, поэтому я оставил только те, которые мы будем использовать.

isContract - эта функция проверяет на то, что адрес является смарт-контрактом. account.code.length должен быть больше нуля если это СК, а если это просто адрес, то разумеется размер кода равен нулю.

functionDelegateCall - вызывает в себе functionDelegateCall, это своего рода перегрузка функции, но это не важно, важно то, что это обычный delegatecall, на адрес который мы передали. Дальше мы можем увидеть, что идет
return verifyCallResultFromTarget

verifyCallResultFromTarget - функция, которая будет проверять наш результат после delegatecall. Как она это делает: Если переменная success равна true, то идем дальше, если нет то откат через функцию revert (о ней позже), если все таки true, то мы дальше начинаем проверять наши данные, которые вернули после вызова, если они равны нулю, то может возникнуть вопрос, а это вообще адрес смарт-контракта? Поэтому через require мы проверяем что наш адрес это СК, через функцию isContract из Address.sol. Если же данные есть, то мы точно знаем, что это адрес СК и возвращаем их.

А если у нас не прошел delegatecall, то мы попадаем в функцию revert.

Тут мы смотрим, если у нас данные больше нуля, то мы делаем махинацию на assembly. Я сейчас постараюсь объяснить что происходит, но если вы на знакомы с тем как храниться динамические данные в солидити может показаться не понятно.

let returndata_size := mload(returndata) тут мы в переменную загружаем первые 32 байта из returndata, потому что функция mload считывает первые 32 байта. Так как returndata имеет тип bytes memory, то первые 32 байта, являются длиной returndata (длина 32 байта). Таким образом переменная returndata_size становиться указателем на длину returndata. Надеюсь понятно.

revert(add(32, returndata), returndata_size) функция revert работает по принципу вернуть данные начиная с такого то места и с такой то длиной данных, так как мы знаем что первые 32 байта указывают на длину, то мы их пропускаем с помощью add(32, returndata) (add это сумма) и возвращаем данные, которые лежат после 32 байт длины. Таким образом мы вернем причину отката и сделаем откат. Ну а если данных нет, то просто причину вернем errorMessage и все.

Теперь еще один вспомогательный контракт, это StorageSlot

 // SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
library StorageSlot {    
    struct AddressSlot {        
        address value;    
    }
    struct BooleanSlot {        
       bool value;    
    }        
    function getAddressSlot(bytes32 slot) internal pure returns (AddressSlot storage r) {                
        assembly {            
            r.slot := slot        
        }   
    }
    function getBooleanSlot(bytes32 slot) internal pure returns (BooleanSlot storage r) {               
        assembly {            
            r.slot := slot        
        }    
    }
}

Тут тоже на много больше функций чем я покажу, но я не вижу смысла нагружать бесполезной инфой. У нас есть 2 простые структуры. И есть 2 функции, которые возвращают через ассемблер данные находящиеся в том или ином слоте в памяти, но вернее сказать слоты в storage. Первый вернет адрес на том месте, второй bool переменную. Все просто.

Initializable

 // SPDX-License-Identifier: MIT
pragma solidity ^0.8.2;
import "../utils/Address.sol";
abstract contract Initializable {       
    uint8 private _initialized;
    bool private _initializing;
    
    event Initialized(uint8 version);
    
    modifier initializer() {        
        bool isTopLevelCall = !_initializing;        
        require(            
          (isTopLevelCall && _initialized < 1) || (!Address.isContract(address(this)) && _initialized == 1),
          "Initializable: contract is already initialized"        
        );        
        _initialized = 1;        
        if (isTopLevelCall) {            
            _initializing = true;        
        }        
        _;        
        if (isTopLevelCall) {           
             _initializing = false;            
             emit Initialized(1);        
        }    
    }
    modifier reinitializer(uint8 version) {        
        require(!_initializing && _initialized < version,
         "Initializable: contract is already initialized");
        _initialized = version;       
        _initializing = true;        
        _;        
        _initializing = false;        
        emit Initialized(version);    
    }
    modifier onlyInitializing() {        
        require(_initializing, "Initializable: contract is not initializing");        
        _;    
    }
    function _disableInitializers() internal virtual {        
        require(!_initializing, "Initializable: contract is initializing");        
        if (_initialized != type(uint8).max) {            
            _initialized = type(uint8).max;            
            emit Initialized(type(uint8).max);        
        }    
    }
    function _getInitializedVersion() internal view returns (uint8) { 
        return _initialized;    
    }
    function _isInitializing() internal view returns (bool) {        
        return _initializing;    
    }
}

Тут мы просто создаём модификаторы для того, чтоб функцию можно было вызвать только 1 раз. То есть псевдо конструктор. initializer это и делает. Как видно внутри модификатора, сначала идет проверка require, что наша функция еще не была вызвана ни разу. Для этого переменная _initialized должна быть меньше нуля и isTopLevelCall true. isTopLevelCall просто как флаг для того, чтоб не возможно было вызвать функцию саму в себе и перевызвать функцию(псевдо конструктор). Надеюсь понятно. Таким образом мы создали псевдо конструктор.

Модификатор reinitializer работает так же, но для новых версий вашего СК. Главное отличие в том, что мы смотрим чтоб новая версия _initialized была больше предыдущей.

onlyInitializing просто смотрит был вызван конструктор или нет. Если нет то откат.

_disableInitializers работает по принципу блокировки СК, если нам хочется предотвратить повторную инициализацию, поставив максимальное число uint8 = 255, то мы больше не сможем инициализировать функции. Что логично, ведь в reinitializer есть условие что версия должна быть больше предыдущей. И в initializer, что переменная _initialized меньше одного.

Ну и две функции. Одна возвращает версию, другая возвращает _initializing переменную(True или False), то есть инициализирован контракт или нет.

Интерфейс IERC1822

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
interface IERC1822Proxiable {    
    function proxiableUUID() external view returns (bytes32);
}

Просто возвращает слот хранения адреса implementation для UUPS proxy

ERC1967Upgrade

 // SPDX-License-Identifier: MIT
pragma solidity ^0.8.2;
import "../utils/Address.sol";
import "../utils/StorageSlot.sol";
import "../interfaces/draft-IERC1822.sol";
abstract contract ERC1967Upgrade {     
    bytes32 private constant _ROLLBACK_SLOT = 0x4910fdfa16fed3260ed0e7147f7cc6da11a60208b5b9406d12a635614ffd9143;
    bytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;
    event Upgraded(address indexed implementation);
    function _getImplementation() internal view returns (address) {        
        return StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value;    
    }
    function _setImplementation(address newImplementation) private {        
        require(Address.isContract(newImplementation), 
        "ERC1967: new implementation is not a contract");       
        StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value = newImplementation;    
    }
    function _upgradeTo(address newImplementation) internal {        
        _setImplementation(newImplementation);        
        emit Upgraded(newImplementation);    
    }
    function _upgradeToAndCall(        
      address newImplementation,        
      bytes memory data,        
      bool forceCall    
    ) internal {        
        _upgradeTo(newImplementation);        
        if (data.length > 0 || forceCall) {              
            Address.functionDelegateCall(newImplementation, data);       
        }    
    }
    
    function _upgradeToAndCallUUPS(address newImplementation, bytes memory data, bool forceCall) internal {        
        if (StorageSlot.getBooleanSlot(_ROLLBACK_SLOT).value) {            
            _setImplementation(newImplementation);        
        } else {            
            try IERC1822Proxiable(newImplementation).proxiableUUID() returns (bytes32 slot) {                
                require(slot == _IMPLEMENTATION_SLOT, "ERC1967Upgrade: unsupported proxiableUUID");            
            } catch {                
                revert("ERC1967Upgrade: new implementation is not UUPS");            
            }           
            _upgradeToAndCall(newImplementation, data, forceCall);        
         }    
         
    }       
    bytes32 internal constant _ADMIN_SLOT = 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103;
    event AdminChanged(address previousAdmin, address newAdmin);
    function _getAdmin() internal view returns (address) {        
        return StorageSlot.getAddressSlot(_ADMIN_SLOT).value;    
    }
    function _setAdmin(address newAdmin) private {       
        require(newAdmin != address(0), "ERC1967: new admin is the zero address");        
        StorageSlot.getAddressSlot(_ADMIN_SLOT).value = newAdmin;   
    }
    function _changeAdmin(address newAdmin) internal {        
        emit AdminChanged(_getAdmin(), newAdmin);        
        _setAdmin(newAdmin);    
    }
   uint256[50] private __gap;
}

Тут у меня тоже не все написано, потому что в openzeppelin есть такая реализация, как beacon, которую я не использую.

Первая и вторая переменная constant, это номер слота переменных, которые специально спрятаны, чтоб избежать взломов и атак на наш proxy. Дальше мы увидим как они используются. То есть переменные под этими слотами мы не знаем где находятся и поэтому к ним сложно добраться.

Чтоб их получить мы делали что то на подобии этого :
bytes32 private constant implementationPosition = bytes32(uint256( keccak256('eip1967.proxy.implementation')) - 1 ));

Функции:

_getImplementation

function _getImplementation() internal view returns (address) {        
        return StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value;    
    }

При помощи нашего StorageSlot достает из нашего слота адрес implementation.

_setImplementation

function _setImplementation(address newImplementation) private {        
        require(Address.isContract(newImplementation), 
        "ERC1967: new implementation is not a contract");       
        StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value = newImplementation;    
    }

При помощи Address проверяем что наш новый адрес, это СК. И просто в наш слот _IMPLEMENTATION_SLOT устанавливаем новый адрес.

_upgradeTo

function _upgradeTo(address newImplementation) internal {        
        _setImplementation(newImplementation);        
        emit Upgraded(newImplementation);    
    }

Функция установки нового implementation. Просто вызываем _setImplementation так как она private.

_upgradeToAndCall

function _upgradeToAndCall(        
      address newImplementation,        
      bytes memory data,        
      bool forceCall    
    ) internal {        
        _upgradeTo(newImplementation);        
        if (data.length > 0 || forceCall) {              
            Address.functionDelegateCall(newImplementation, data);       
        }    
    }

В целом тоже самое что и _upgradeTo, но мы можем еще передать data, и благодаря этому сделать низкоуровневый вызов, обычно используется во время установки implemenation и вызывает функцию initialize, как конструктор. Если
data = 0, то мы пропускаем этот вызов. ForceCall работает так, что даже если data=0, все равно делать delegatecall. Зачем это я так и не понял, потому что почти всегда используют false у данной переменной.

_upgradeToAndCallUUPS

function _upgradeToAndCallUUPS(address newImplementation, bytes memory data, bool forceCall) internal {        
        if (StorageSlot.getBooleanSlot(_ROLLBACK_SLOT).value) {            
            _setImplementation(newImplementation);        
        } else {            
            try IERC1822Proxiable(newImplementation).proxiableUUID() returns (bytes32 slot) {                
                require(slot == _IMPLEMENTATION_SLOT, "ERC1967Upgrade: unsupported proxiableUUID");            
            } catch {                
                revert("ERC1967Upgrade: new implementation is not UUPS");            
            }           
            _upgradeToAndCall(newImplementation, data, forceCall);        
         }    
         
    }     

Функция, которая обновляет implementation для UUPS. Тут мы смотрим на _ROLLBACK_SLOT, если в нем находится true переменная, то устанавливаем implementation первый раз, если нет, то это означает, что это новая версия СК и нужно добавить пару проверок. При помощи try catch мы пытаемся, обращаясь через интерфейс от лица нового implementation к функции proxiableUUID (ее напишем позже), узнать слот хранения implementation. Это нужно делать чтоб у нас получилось вернуть значение. Если у нас не получиться это сделать, значит может быть такое, что кто то делегирует эту функцию (_upgradeToAndCallUUPS) саму в себя и тем самым блокирует контракт. И еще slot, он должен быть равен слоту _IMPLEMENTATION_SLOT. Если же не получилось, то просто откат. И только потом, когда все проверки прошли, мы уже обновляем наш implementation адрес.

Дальше слот хранения админа СК.

Админ функции

  function _getAdmin() internal view returns (address) {        
        return StorageSlot.getAddressSlot(_ADMIN_SLOT).value;    
    }
    function _setAdmin(address newAdmin) private {       
        require(newAdmin != address(0), "ERC1967: new admin is the zero address");        
        StorageSlot.getAddressSlot(_ADMIN_SLOT).value = newAdmin;   
    }
    function _changeAdmin(address newAdmin) internal {        
        emit AdminChanged(_getAdmin(), newAdmin);        
        _setAdmin(newAdmin);    
    }

Ну тут все просто. _getAdmin по слоту возвращает админа. _setAdmin проверяет, что новый адрес не нулевой и устанавливает в _ADMIN_SLOT нового овнера. _changeAdmin меняет админа, при помощи _setAdmin.

uint256[50] private __gap строчка, которая гарантирует, что не будет проблем со слотами, не будет наложений и смещений. Грубо говоря это резервация пространства для новых переменных в бедующих обновлениях. То есть в данном случает у нас есть целых 50 свободных слотов.

ERC1967

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
import "../Proxy.sol";
import "./ERC1967Upgrade.sol";

contract ERC1967Proxy is Proxy, ERC1967Upgrade {    
    uint8 private _initializd;    uint256 public x1;    
    constructor(address _logic, bytes memory _data) payable {        
        _upgradeToAndCall(_logic, _data, false);    
    }    
    function _implementation() internal view virtual override returns (address impl) {        
        return ERC1967Upgrade._getImplementation();    
    }    
}

Это наш Proxy СК. Тут мы реализуем конструктор, в котором вызываем _upgradeToAndCall и устанавливаем implementation.

Ну и _implementation функция, которая возвращает наш адрес СК.

По идее всю логику нужно реализовать тут, но это не советуют делать и для этого создают СК, который наследует этот и там уже все реализуют.

UUPSUpgradeable

 // SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
import "./interfaces/draft-IERC1822.sol";
import "./ERC1967/ERC1967Upgrade.sol";
import "./utils/Initializable.sol";
abstract contract UUPSUpgradeable is IERC1822Proxiable, ERC1967Upgrade, Initializable {    
    function __UUPSUpgradeable_init() internal onlyInitializing {    
    }
    function __UUPSUpgradeable_init_unchained() internal onlyInitializing {    
    }    
    address private immutable __self = address(this);
    modifier onlyProxy() {        
        require(address(this) != __self, 
        "Function must be called through delegatecall");        
        require(_getImplementation() == __self, 
        "Function must be called through active proxy");        
        _;   
    }
    modifier notDelegated() {         
         require(address(this) == __self, 
         "UUPSUpgradeable: must not be called through delegatecall");        
         _;    
    }
    function proxiableUUID() external view virtual override notDelegated returns (bytes32) {        
        return _IMPLEMENTATION_SLOT;    
    }
    function upgradeTo(address newImplementation) public virtual onlyProxy {        
        _authorizeUpgrade(newImplementation);        
        _upgradeToAndCallUUPS(newImplementation, new bytes(0), false);    
    }
    function upgradeToAndCall(address newImplementation, bytes memory data) public payable virtual onlyProxy {        
         _authorizeUpgrade(newImplementation);        
         _upgradeToAndCallUUPS(newImplementation, data, true);    
    }
    function _authorizeUpgrade(address newImplementation) internal virtual;
    uint256[50] private __gap; 
}

__UUPSUpgradeable_init и __UUPSUpgradeable_init_unchained нужны по факту для инициализации каких то идей, но их нет. А так, если серьезно, то используется для проверки, что инициализация псевдо конструктора прошла.

onlyProxy модификатор, который говорит что только Proxy может вызывать функции.

notDelegated не дает делегировать функции.

Это все нужно если у нас есть функции с одинаковыми селекторами, и чтоб не произошел казус. И некоторые функции нельзя было делегировать для безопасности, как мы уже и заметили в _upgradeToAndCallUUPS.

proxiableUUID

Та самая функция которая возвращает слот implementstion, и мы ее вызывали в _upgradeToAndCallUUPS.

upgradeTo очевидно, что просто обновляет наш адрес СК (implementation), и upgradeToAndCall делает тоже самое. В целом понятно, что идет вызов функций из ERC1967Upgrade.

_authorizeUpgrade функция которая переопределяется в нашем СК, который мы хотим потом обновлять(implementation)

Пример СК, который мы хотим в будущем обновить:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
import "./utils/Initializable.sol";
import "./UUPSUpgradeable.sol";
contract V1 is Initializable, UUPSUpgradeable{    
    uint256 public number;    
    address owner;    
    modifier onlyOwner(){        
        require(owner == msg.sender, "error");        
        _;    
    }    
    function initialize(uint _number) public payable initializer {        
        __UUPSUpgradeable_init();        
        number = _number;        
        owner = msg.sender;    
    }    
    function _authorizeUpgrade(address newImplementation) internal onlyOwner override{}
}

И обновлённая версия

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
import "./utils/Initializable.sol";
import "./UUPSUpgradeable.sol";
contract V1 is Initializable, UUPSUpgradeable{    
    uint256 public number;    
    address owner;    
    uint256 public newNumber;
    modifier onlyOwner(){        
        require(owner == msg.sender, "error");        
        _;    
    }    
    function initialize(uint _number) public payable initializer {        
        __UUPSUpgradeable_init();        
        number = _number;
        newNumber = _newNumber;        
        owner = msg.sender;    
    }    
    function _authorizeUpgrade(address newImplementation) internal onlyOwner override{}
}

Нужно заметить что мы наследуем именно UUPSUpgradeable и Initializable.

Вот мы и реализовали свой ERC1967 proxy смарт-контракт. Сразу хочется сказать, что для использования этот код не рекомендуется. Потому что я убрал некоторые вещи, которые показались не очень нужными и поэтому не стоит рисковать и писать самим этот стандарт. Тот же самый beacon, который по хорошему тоже должен быть и случай Transparent как бы ни кто не исключал. Поэтому используйте версию из openzeppelin и не парьтесь. Главное что мы знаем как эта штука работает изнутри и понимаем что происходит и для чего это нужно. Это как минимум упростит написание своих upgradeable СК. А как максимум, вы будете знать то, что обычно другие считают не нужным знать.

Бонус

Если ты дожил до этого момента, то покажу скрип деплоя. На самом деле он есть в openzeppelin, но когда я писал его, то в некоторых моментах не мог сразу понять что от меня хотят.

Устанавливаем эту библиотеку для взаимодействия.

 npm install @openzeppelin/contracts-upgradeable

Деплой первой версии

 const { ethers, upgrades } = require("hardhat");
async function main() {  
  if (network.name === "hardhat") {    
  console.warn(      
  "You are trying to deploy a contract to the Hardhat Network, which" +   
   "gets automatically created and destroyed every time. Use the Hardhat" +        
   " option '--network localhost'"    
   );  
  }
  const [deployer] = await ethers.getSigners()
  console.log("Deploying with", await deployer.getAddress())
  const V1 = await ethers.getContractFactory("V1");  
  const v1 = await upgrades.deployProxy(V1.address, [53], {
    kind: 'uups'
  });  
  await v1.deployed();  
  console.log("deployed to:", v1.address);
}
main().catch((error) => { 
 console.error(error);  
 process.exitCode = 1;
});

Тут все как всегда, но есть изменение:

const v1 = await upgrades.deployProxy(V1.address, [0]);  

Мы деплоим не как обычно через deploy(), а через deployProxy. Передаем адрес СК и в массив, наши аргументы, которые будут переданы и вызваны в функции initialize, если такая имеется. И главное: если мы хотим делать деплой через UUPS, то это нужно явно указать через kind переменную. Так как по умолчанию будет использоваться transpenrent.

v1 переменная будет нашим Proxy смарт-контрактом, а не нашим смарт-контрактом V1.

Деплой новой версии

 const { ethers, upgrades } = require("hardhat");
async function main() {  
  if (network.name === "hardhat") {    
  console.warn(      
  "You are trying to deploy a contract to the Hardhat Network, which" +   
   "gets automatically created and destroyed every time. Use the Hardhat" +        
   " option '--network localhost'"    
   );  
  }
  addressProxy = 0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512
  const V2 = await ethers.getContractFactory("V2"); 
  const v2 = await upgrades.upgradeProxy(addressProxy, V2, {
    call:{
     fn:"initialize(uint256), 
     args:[35])
    }
    });
  
  console.log("deployed to:", v2.address);
}
main().catch((error) => { 
 console.error(error);  
 process.exitCode = 1;
});

Тут мы просто будем деплоить новую версию СК через upgradeProxy.

И необычная особенность upgradeProxy()

const v2 = await upgrades.upgradeProxy(addressProxy, V2, {
    call:{
     fn:"initialize(uint256), 
     args:[35]
    }
    });

Мы передаем адрес Proxy и новый адрес обновлённого СК. Последнюю переменную call нужно использовать в том случае, если нам снова нужно вызвать конструктор, и вот таким необычным способом нужно передавать туда функцию, которую мы хотим вызвать и аргументы в массиве. Тут не будет как в deployProxy, где достаточно передать аргументы и он сам найдет нашу функцию initialize и сделает все что нужно. Но и так нормально.

Ну на этом я пожалуй закончу свой долгий монолог про ERC1967. Сегодня мы изнутри посмотрели как работает Proxy и как мы можем обновлять свои СК. А главное узнали специфику и хитрости которые можно использовать для хранения информации, например через спрятанные слоты. Дальше больше. И теперь когда мы будем писать свои обновляемые СК мы будем знать что у этой машины под капотом.

Полезные ссылки:

Что такое proxy

Реализация Transparent и UUPS

Как написать скрипт деплой

API плагина upgrade

Реализация EIP-1967

tg: мой телеграмчик)

GitHub: Этот проект на гит хабе