Блясък и нищета на atomic swaps

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

Основната мотивация на всеки специалист по сигурност е желанието да избегне отговорност.

Провидението беше благосклонно, напуснах ICO, без да изчакам първата необратима транзакция, но скоро се оказах за разработката на криптобиржа.

Аз— категорично не съм Момчето Кибальчиш, и един строг поглед е достатъчен, за да предам всички ключове и пароли. Така основната ми цел като архитект беше да разположа горещия зъб на криптоанализа колкото се може по-далеч от важните за мен елементи на инфраструктурата.

Не твои ключове, не твои проблеми

Строим система за обмен на активи и искаме да изключим междинното съхранение на тези активи при нас, но трябва да гарантираме безопасността на сделката.

Можеш да играеш ролята на съдия в спори и да извършваш сделки с портфейли, изискващи два от трите подписа: на купувача, продавача и ескроу.

Обаче, ако участник успешно атакува ескроу, той получава желаните два подписа.

Атомарният своп е схема за обмен, при която гарантът е смарт-контракт, който допуска само честно поведение.

Както в загадката за вълка, козата и зеле, можеш да действаш само по единствения правилен сценарий и носиш загуби, ако отклоняваш от него.

Само вместо алчни животни, редът се осигурява от хеш функция, при която е толкова трудно да се намери колизия, че дори няма смисъл да започваш.

Стъпка първа: загадка

Предположим, че Алиса една прекрасна сутрин иска да предаде на Боб биткойн в замяна на купчина „криптоюани“.

• Тя загадыва някаква голяма тайна
• Получава от него хеш
• Превежда биткойните на смарт-контракт, откъдето парите може да вземе Боб, представяйки тайната (хешът от нея трябва да е равен на посочения в договора)
• В случай, че Боб не се появи до вечерта, Алиса може да вземе обратно своите биткойни.

Стъпка втора: примамка

В играта влиза Боб и превежда „криптоевро“ на своя контракт, който е написан така, че:

• Алиса може да вземе „криптојените“, представяйки секретно число
• Не по-рано от обяд Боб, при отсъствието на Алиса, може да върне депозита

Стъпка трета: отгадка в примамката

Алиса идва за своите пари и взима парите от договора на Боб, като разкрива своята тайна.

Завършваща стъпка: загадката е разгадана

Боб вижда транзакцията и със соколски поглед извлича от нея тайната, представена от Алиса на договора. Тази тайна той използва, за да вземе своите биткойни.

Когато нещо не върви по план

Ако Алиса изведнъж се окаже смъртна, Боб взима своите юани за обяд.

От своя страна, Алиса ще върне биткойн вечерта, ако предателският Боб реши да задържи парите до по-добри времена.

Ако предпочитате картинка пред текст, на Хабра има по-подробно и визуално обяснение на атомарните свопове.

Разликата между таймаутите е предназначена да ни предпази от злонамерената Алиса, която взима парите на Боб в последния момент, а таймаутът изтича, докато той треперещи вмъква hex в транзакцията.

Участниците не могат да загубят парите си, максимум, ще трябва да изчакат връщането.

Подкрепа в блокчейнитеТова е проста, като валенок схема, която изисква от взаимодействуващите блокчейн системи само малко:

• Подкрепа за смарт контракти с поне едно разклонение
• И двата блокчейна трябва да поддържат еднакви хеш алгоритми (не забравяйте да проверите дължината на тайната)
• Таймлоковете.

На пръв поглед, вече можем да кажем "сбогом" на борсата, нашата среща беше грешка, но не тук.

При всичките си предимства решенията на атомарния своп не блестят с ликвидност. В голяма степен защото в най-популярната двойка BTC-USD фиатната част не беше напълно токенизирана.
Успехът на USDT роди цяла вълна от стабилни монети в ERC20 формат на всякакъв вкус, от най-кастодиалния USDC до алгоритмичния DAI.

Затова за улеснение ще говорим по-нататък за това, че Алиса продава биткойни на Боб в замяна на някакви ERC20 токени, и се надяваме на късмета на стабилизаторите, благо, че имаме още много по-технически проблеми.

Скорост

Биткойн и Ethereum самостоятелно не са чак толкова бързи, а сега чак толкова ни се налага да изчакаме първо един депозит с всички потвърждения, после втори.

Всичко това е, защото първо парите внася участникът, който знае тайната, а опонентът чака финализация и едва след това превежда своята част.

Освен това, ние имаме работа с много волатилен актив, така че за това време курсът може да се промени съществително, а промяната на условията вече не е лесна.

Конфиденциалност

Всеки обмен оставя артефакти и в двете блокчейна. Внимателният наблюдател може да забележи идентични хешове в смарт договорите и да направи логично заключение, че е извършена сделка, от която могат да произлязат много умозаключения от курсови до данъчни.

Когато борсата знае за твоите дела — това е изключително неприятно, а когато всеки знае — това е неприятно вдвойна.

Usability

Специалността на блокчейн изобщо, и на ефира в частност. Нека да видим какви действия трябва да предприемат продавачът и купувачът.

От гледна точка на продавача всичко е сравнително просто: просто трябва да преведе биткойн на p2sh адрес. С ефира всичко е много по-сложно.

ДоговорНека разгледаме среден договор от GitHub за своп:

contract iERC20 {
    function totalSupply() public view returns (uint256);
    function transfer(address receiver, uint numTokens) public returns (bool);
    function balanceOf(address tokenOwner) public view returns (uint);
    function approve(address delegate, uint numTokens) public returns (bool);
    function allowance(address owner, address delegate) public view returns (uint);
    function transferFrom(address owner, address buyer, uint numTokens) public returns (bool);
}

contract Swapper {

    struct Swap {
        iERC20 token;
        bytes32 hash;
        uint amount;
        uint refundTime;
        bytes32 secret;
    }

    mapping (address => mapping(address => Swap)) swaps;

    function create(iERC20 token, bytes32 hash, address receiver, uint amount, uint refundTime) public {
        require(swaps[msg.sender][receiver].amount == 0); // check is swap with given hash already exists
        require(token.transferFrom(msg.sender, address(this), amount)); // transfer locked tokens to swap contract
        swaps[msg.sender][receiver] = Swap(token, hash, amount, refundTime, 0x00); // create swap
    }
    
    function hashOf(bytes32 secret) public pure returns(bytes32) {
        return sha256(abi.encodePacked(secret));
    }


    function withdraw(address owner, bytes32 secret) public {
        Swap memory swap = swaps[owner][msg.sender];
        require(swap.secret == bytes32(0));
        require(swap.hash == sha256(abi.encodePacked(secret))); // swap exists
        swaps[owner][msg.sender].secret = secret;
        swap.token.transfer(msg.sender, swap.amount);
    }

    function refund(address receiver) public {
        Swap memory swap = swaps[msg.sender][receiver];
        require(now > swap.refundTime);
        delete swaps[msg.sender][receiver];
        swap.token.transfer(msg.sender, swap.amount);
    }
}

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

• Боб трябва да извика в договора на токена метода approve, давайки на договора за своп достъп до своите токени
• Боб създава своп и договора с помощта на метода transferFrom които взима на своя адрес токените на изпращача
• Алиса в withdraw разкрива секрет и контрактът извиква превод

Повечето портфейли и криптоборси не поддържат approve токени, и не без причина.

Самите потребители често грешат и просто превеждат токени към контракта, след което токените просто изчезват. Коментарите в Etherscan са пълни със стенания на нещастни.

А за да се извика контракт, е необходимо да се плати такса в ETH, затова и двете страни трябва да имат налично ETH преди началото на сделката, а малко хора искат да се занимават с това.

Газов контейнер

Първо е добре да премахнем проверката на изпращача навсякъде, където е възможно, и да предположим, че имаме някой, който страда от излишък на газ и извиква контракти за всички желаещи.

Модернизиран контракт

contract Swapper {

    struct Swap {
        iERC20 token;
        address receiver;
        uint amount;
        address refundAddress;
        uint refundTime;
    }

    mapping (bytes32 => Swap) swaps;

    function create(iERC20 token, bytes32 hash, address receiver, uint amount, address refundAddress, uint refundTime) public {
        require(swaps[hash].amount == 0); // use hash once
        require(token.transferFrom(msg.sender, address(this), amount));
        swaps[hash] = Swap(token, receiver, amount, refundAddress, refundTime);
    }


    function withdraw(bytes memory secret) public {
        bytes32 hash = sha256(secret);
        Swap memory swap = swaps[hash];
        require(swap.amount > 0);
        delete swaps[hash];
        swap.token.transfer(swap.receiver, swap.amount);
    }

    function refund(bytes32 hash) public {
        Swap memory swap = swaps[hash];
        require(now > swap.refundTime);
        delete swaps[hash];
        swap.token.transfer(swap.refundAddress, swap.amount);
    }
}

Контрактно-ключовият дуализъм и EIP 712

Както знаем, адресът в ефира може да бъде контракт, а може и да бъде субект, тоест ключ.
Основното занятие на ключа е да подписва някакви съобщения.

Можем да използваме като изпращач Боб-контракт, който извършва всички необходими действия, след като преди това е проверил подписа на Боб-ключа.

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

Боб-контракт

library EIP712ProxyLibrary {
    function hashCommand(address sender, iERC20 token, Swapper swapper, bytes32 hash, address receiver, uint amount, address refundAddress, uint refundTime) public view returns(bytes32);
}

contract ProxyBob {
    address owner;

    constructor(address _owner) public {
        owner = _owner;
    }

    function createSwap(Swapper swapper, iERC20 token, bytes32 hash, address receiver, uint amount, address refundAddress, uint refundTime, uint8 v, bytes32 r, bytes32 s) public {
        require(owner == ecrecover(EIP712ProxyLibrary.hashCommand(address(this), token, swapper, hash, receiver, amount, refundAddress, refundTime), v, r, s));
        token.approve(address(swapper), amount);
        swapper.create(token, hash, receiver, amount, refundAddress, refundTime);
    }
}

За работа с подписите на сложни структури от данни в Ethereum съществува стандарт EIP 712, можете да прочетете повече за него в блога на портфейла Metamask

Разделяй и владей

Често сценарият на хакване на Ethereum контракт изглежда така:

• Участникът влага средства в контракта
• След това вади средствата
• Нещо не върви както трябва
• Неправомерният взема парите отново и отново

Ако се върнем към нашия първи пример, нещо не върви както трябва, ако загадката е празен набор от байтове.

Как да откраднем милионСъздаваме своп с хеш 0x66687aadf862bd776c8fc18b8e9f8e20089714856ee233b3902a591d0d5f2925
Това е sha256 от 0x0000000000000000000000000000000000000000000000000000000000000000
Предаваме секрет и вземаме нашите токени
Предаваме отново и вземаме чужди, всичко заради това, че 0 = 0

Създавайки отделен контракт за всяка сделка, можем да изолираме контрактите на ниво EVM.

Но и това не е всичко: сега всяка сделка има свой адрес, на който могат да се прехвърлят токени от всякакъв портфейл или борса.

Изоставени контракти и create2

Но сега за всяка сделка трябва да създаваме контракт и да чакаме купувачът да прехвърли трудовия си "криптофенинг". В схемата "сутрин контрактите, вечер парите" винаги съществува опасност купувачът да изчезне, а ефирът за създаването на контракта вече да е изразходван.

Не може ли да направим така, че сутрин парите, а вечер байтовете?

В хардфорка Constantinople разработчиците EIP 1014 добавиха инструкция create2, която създава нов контракт на детерминиран адрес

keccak256( 0xff ++ address ++ salt ++ keccak256(init_code))[12:]

Където

• address — адрес на фабричния контракт
• salt — някакво число, смисълът на което ще разберем в следващата серия
• init_code — байт-код на контракта и параметри на конструктора.

ФабрикаИнструкцията работи само чрез assembly, затова фабриката изглежда малко плашещо:

contract Factory {
  event Deployed(address addr, uint256 salt);

  function create2(bytes memory code, uint256 salt) public {
    address addr;
    assembly {

      addr := create2(0, add(code, 0x20), mload(code), salt)
    }

    emit Deployed(addr, salt);
  }
}

Кодът на вашия контракт можете да получите с помощта на web3:

const MyContract = new web3.eth.Contract(ABI, {})
const код = MyContract.deploy({
    data: BYTECODE,
    arguments: contructorArgs  
}).encodeABI();
const factory = new web3.eth.Contract(FACTORY_ABI, factoryAddress);
tx = factory.methods.create2(код, salt);

Поради ограничената поддръжка в solidity, газът за контракта може да се изчислява неправилно заради някои особености на ефира.

Особено е приятно, че в случай на недостатъчен газ, контрактът пада с вътрешна грешка, без да съобщава, че газът не е достатъчен, както би могло да се очаква.

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

Ворон ворону око не изважда.

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

Как да направим така, че хешът да не бъде разкрит?

Самият своп пренасяме в офлайн: участниците обменят подписи за превод към своп-контракта, а след това частният ключ се разкрива тайно.

Стъпка по стъпка.Създават се два "мултисиг", от които може да се изтегли средства при наличие на подписи от Алиса и Боб.

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

Алиса и Боб паралелно депозират средства.

• Алиса измисля тайна и предава на Боб хеша на тайната и подписа на транзакцията, която прехвърля биткойни на адреса на свопа.
• Боб предава на Алиса подписа за изтегляне на токени на своп-контракта с измисления хеш.
• Алиса съобщава на Боб тайната.

В този момент настъпва хармония: и Алиса, и Боб могат по всяко време да завършат сделката. В такава дружелюбна обстановка те могат да обменят подписи за изтегляне на пари на окончателните адреси.

За външен наблюдател това изглежда така, сякаш парите са преминали през контракт с мултиподпис 2 от 2.

И такава схема позволява на двете страни да правят депозит едновременно, тъй като тайната се измисля вече след всички потвърждения.

Level 2.

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

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

Стъпка по стъпка.

• Продавача измисля тайна и дава на купувача хеша на тайната и подписа на транзакцията, където част от средствата се прехвърлят на p2sh адреса на свопа, а остатъкът се връща на адреса на продавача.
• Клиентът предава подпис, който позволява да се извлекат токени и връщане на адреса на получателя.
• Продавачът разкрива тайна
• Историята се повтаря с нова тайна, като към свопа и връщането се добавя още извеждане на предишно закупено на адреса на купувача и вече платено на адреса на продавача

Сега имаме достъп до високоскоростна p2p търговия, важно е да следим времето и да затворим сделката преди изтичането на времето.

Въпреки това, малко променяйки нашите договори, можем да подарим на нашите канали безсмъртие, което значително ще улесни създаването на мрежа.

Но за това ще разкажем в следващата серия.

Източник: habr.com