Glans och fattigdom i atombyten

Vad är dåligt med atomära swappar och hur kan kanaler hjälpa dem, vad som hände med hårdgaffeln Constantinople och hur ska man agera när man inte har råd att betala för gas.

Huvudmotivation för varje säkerhetsspecialist är en önskan att undvika ansvar.

Försynen var nådig, jag lämnade ICO:t utan att vänta på den första irreversibla transaktionen, men snart befann jag mig istället med att utveckla en kryptobörs.

Jag är definitivt inte Malchish Kibalchish, och en enda sträng blick räcker för att jag ska ge upp alla nycklar och lösenord. Därför var mitt huvudsakliga mål som arkitekt att placera den heta stinger av kryptografi så långt bort som möjligt från de infrastrukturella delar jag höll kärt.

Inte dina nycklar, inte dina problem.

Vi bygger ett system för tillgångshandel och vill utesluta mellanlagring av dessa tillgångar hos oss, men måste säkerställa att transaktionen är säker.

Vi kan agera som domare i en tvistig situation och genomföra transaktioner med plånböcker som kräver två av tre signaturer: köparens, säljarens och escrow.

Men om en deltagare framgångsrikt attackerar escrow, får han de två önskade signaturerna.

En atomär swap är en byteordning där en smart kontrakt är garant som endast tillåter ärligt beteende.

Som i gåtan om vargen, geten och kålen kan du endast agera enligt det enda korrekta scenariot och du får förluster om du avviker från det.

Men istället för giriga djur säkerställs ordningen genom en hash-funktion, där det är så svårt att hitta en kollision att det inte ens är värt att börja.

Steg ett: gåtan.

Anta att Alice en vacker morgon vill överföra Bitcoin till Bob mot en näve "krypto-yuaner".

• Hon väljer en stor hemlighet.
• Får en hash från honom.
• Överför Bitcoin till en smart kontrakt, från vilken Bob kan hämta pengarna genom att presentera hemligheten (hashet måste överensstämma med det som anges i kontraktet).
• Om Bob inte kommer för sina Bitcoin till kvällen kan Alice ta tillbaka dem.

Steg två: lockbetet.

Bob går in i spelet och överför "krypto-euro" till sin kontakt, som är skriven på ett sådant sätt att:

• Alice kan ta "krypto-yuanerna" om hon presenterar det hemliga numret.
• Inte tidigare än vid lunchtid kan Bob, om Alice inte dyker upp, återfå insättningen.

Steg tre: lösningen på lockbetet.

Alice kommer för sina pengar och tar pengarna från Bobs kontrakt, samtidigt som hon avslöjar sin hemlighet.

Avslutande steg: gåtan är löst

Bob ser transaktionen och med sitt skarpa öga plockar han ut hemligheten som Alice presenterade för kontraktet. Denna hemlighet använder han för att hämta sina bitcoins.

När något går fel

Om Alice plötsligt blir dödlig, hämtar Bob sina yuan vid lunch.

I sin tur återbetalar Alice bitcoins på kvällen om den svikna Bob väljer att hålla kvar pengarna tills bättre tider.

Om du föredrar bilder framför text, finns det en mer detaljerad och visuell förklaring av atomära swaps på Habr. arbetet med atomära swaps.

Skillnaden mellan tidsgränser är avsedd att skydda oss från den illvilliga Alice, som snor Bobs pengar i sista stund, medan han med darrande fingrar skriver in hex i transaktionen.

Deltagarna kan inte förlora sina pengar, max får de vänta på återbäringen.

Stöd i blockkedjorDetta är ett enkelt schema, som kräver väldigt lite från de interagerande blockkedjorna:

• Stöd för smarta kontrakt med minst en förgrening
• Båda blockkedjorna måste stödja samma hash-algoritmer (glöm inte att kontrollera längden på hemligheten)
• Tidslåser.

Vid första anblick verkar det möjligt att säga till börsen "farväl, vårt möte var ett misstag", men så enkelt är det inte.

Trots sina fördelar imponerar lösningarna på atomic swap inte med likviditet. Mycket av detta beror på att den mest populära paret BTC-USD inte var helt tokeniserad.
Framgången för USDT har gett upphov till en hel våg av stabila mynt i ERC20-format, från det mest förvarade USDC till det mest algoritmiska DAI.

Därför kommer vi för enkelhetens skull att resonera vidare om att Alice säljer bitcoins till Bob för några ERC20-tokens, och hoppas på stabilisatorernas framgång, eftersom vi har många fler tekniska problem.

Hastighet

Bitcoin och Ethereum är kanske inte särskilt snabba på egen hand, och här måste vi först vänta på en insättning med alla bekräftelser, sedan den andra.

Detta beror på att pengarna först sätts in av deltagaren som känner till hemligheten, medan motparten väntar på finaliteten och först därefter överför sin del.

Dessutom hanterar vi en mycket volatil tillgång, så under denna tid kan kursen förändras avsevärt, och det är svårt att ändra villkoren.

Sekretess

Varje utbyte lämnar artefakter på båda blockkedjorna. En noggrann iakttagare kan märka identiska hashvärden i smarta kontrakt och dra logiska slutsatser, allt från valutakursförändringar till skattefrågor.

När börsen känner till dina affärer — är det extremt obehagligt; när alla känner till dem — är det dubbelt obehagligt.

Användarvänlighet

Kärnan i blockkedjan, och speciellt Ethereum. Låt oss titta på vilka åtgärder som säljaren och köparen måste vidta.

Ur säljarens perspektiv är allt relativt enkelt: man behöver bara överföra Bitcoin till en p2sh-adress. Med Ethereum är det mycket mer komplicerat.

KontraktLåt oss titta på ett genomsnittligt kontrakt för swap på 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 if 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);
    }
}

Varning! Använd inte detta och andra kontrakt från artikeln i produktion, de är skrivna endast för demonstrationsändamål. Särskilt detta.

• Bob måste kalla på tokenkontraktets metod approve, vilket ger swap-kontraktet tillgång till sina tokens
• Bob skapar en swap och kontraktet med metoden transferFrom hämtar avsändarens tokens till sin adress
• Alice i withdraw avslöjar hemligheten och kontraktet kallas överföring

De flesta plånböcker och kryptobörser stödjer inte approve tokens, och inte utan anledning.

Användarna gör ofta misstag och överför bara tokens till kontraktet, vilket gör att tokens bara går förlorade. Kommentarer på Etherscan är fulla med klagomål från olyckliga användare.

För att kalla kontraktet måste man betala en avgift i ETH, vilket innebär att båda parter måste ha detta innan affären inleds, och det är det få som vill syssla med.

Gasbolaget

Först bör man ta bort avsändarverifiering där det är möjligt och anta att vi har någon som lider av överflödig gas och kallar kontrakt för alla som vill.

Moderniserat kontrakt

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);
    }
}

Kontrakts-nyckeldualism och EIP 712

Som vi vet kan en adress på Ethereum vara ett kontrakt, eller så kan det vara ett subjekt, d.v.s. en nyckel.
Nyckelns huvuduppgift är att signera meddelanden.

Vi kan använda Bob-kontraktet som avsändare, som utför alla nödvändiga pass, efter att ha verifierat Bob-nyckelns signatur.

Nu kan vem som helst sponsra en deltagaravgift, men beslutsrätten har endast den som känner till nyckeln.

Bob-kontrakt

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);
    }
}

För att arbeta med signaturer av komplexa datatyper i Ethereum finns det en standard EIP 712, du kan läsa mer om det i Metamask plånbokens blogg

Dela och härska

Ofta ser ett scenario för att hacka en Ethereum-kontrakt ut så här:

• Deltagaren sätter in medel i kontraktet
• Sen tar de ut medlen
• Något går fel
• Angriparen tar pengarna om och om igen

Om vi återgår till vårt första exempel, går något fel om gåtan är en tom uppsättning bytes.

Hur man stjäl en miljonSkapa en swap med en hash 0x66687aadf862bd776c8fc18b8e9f8e20089714856ee233b3902a591d0d5f2925
Detta är sha256 av 0x0000000000000000000000000000000000000000000000000000000000000000
Vi överför hemligheten och hämtar våra tokens
Vi överför igen och hämtar andras, allt för att 0 = 0

Genom att skapa ett separat kontrakt för varje affär kan vi isolera kontrakten på EVM-nivå.

Men det är inte allt: nu har varje affär sin egen adress, dit man kan överföra tokens från vilken plånbok eller börs som helst.

Övergivna kontrakt och create2

Men nu måste vi skapa ett kontrakt för varje affär och vänta på att köparen överför sitt arbetsrelaterade "kryptovaluta". I schemat "kontrakt på morgonen, pengar på kvällen" finns alltid risk att köparen drar sig ur, medan eter för att skapa kontraktet redan har spenderats.

Kan vi inte göra så att pengarna är på morgonen och bytes på kvällen?

I hard fork Constantinople lade utvecklarna EIP 1014 till en instruktion create2, som skapar ett nytt kontrakt på en deterministisk adress

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

Där

• address — adressen till fabriks-kontraktet
• salt — ett nummer vars syfte vi kommer att förstå i nästa avsnitt
• init_code — byte-koden för kontraktet och konstruktörens parametrar.

FabrikenInstruktionen fungerar endast genom assembly, så fabriken ser lite skrämmande ut:

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);
  }
}

Din kontraktskod kan erhållas med hjälp av web3:

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

På grund av begränsat stöd i solidity kan gasen för kontraktet beräknas felaktigt på grund av vissa subtiliteter i eter.

Särskilt trevligt är det att i händelse av otillräcklig gas misslyckas kontraktet med ett internt fel, utan att ange att gasen inte räckte, som man kanske skulle förvänta sig.

Nu kan vi översätta tokens till kontrakt utan att förbereda dem i förväg, och tills vi publicerar dem på nätet kommer ingen att förstå vad kontraktet gör.

Kråkan hackar inte varandras ögon.

Det är uppenbart att en riktig analytiker, särskilt en som fått bra investeringar för att bekämpa fiender till systemet genom penningtvätt, inte stoppas av sådana barnsliga knep, och efter skapandet av kontraktet kommer han ändå att se hash.

Hur gör man så att hash inte avslöjas?

Själva swapen flyttar vi till off-chain: deltagarna byter signaturer för överföring till swap-kontraktet, och sedan avslöjas hemligheten privat.

Steg för stegTvå "multisig"-kontrakt skapas, från vilka medel kan hämtas med signaturer från Alice och Bob.

För att en eventuell avstängning av någon av deltagarna inte ska bli en tragedi, lägger vi till den gamla goda timeouten.

Alice och Bob sätter in insättningar parallellt.

• Alice föreslår en hemlighet och överlämnar till Bob hash av hemligheten och signaturen av transaktionen som överför bitcoin till swap-adressen.
• Bob överlämnar en signatur till Alice för uttag av tokens till swap-kontraktet med den föreslagna hashen.
• Alice meddelar Bob hemligheten.

Vid det här laget inträder harmoni: både Alice och Bob kan när som helst avsluta affären. I en sådan vänlig miljö kan de byta signaturer för att ta ut pengar till slutadresser.

För en utomstående observatör ser det ut som om pengarna har passerat genom ett kontrakt med multiparaf som kräver 2 av 2.

Dessutom tillåter ett sådant schema båda parter att sätta in insättningar samtidigt, eftersom hemligheten föreslås först efter alla bekräftelser.

Nivå 2

Eftersom vi kan ta ut pengar till en adress och inte publicera den interimistiska transaktionen, finns det inget som hindrar oss från att ta ut pengar till flera adresser och utföra ett obegränsat antal interimistiska transaktioner. Det är inte nödvändigt för en swap, men när man väl har börjat samla swap är det svårt att stanna.

Nu kan Alice och Bob ge sig ut på djupet. Till exempel, automatiskt beräkna det genomsnittliga priset genom att byta satsar per sekund, eller helt enkelt koppla samman marknadsgöraren och likviditetsmottagaren direkt.

Steg för steg

• Säljaren föreslår en hemlighet och ger köparen hash av hemligheten och signaturen av transaktionen där en del av medlen överförs till p2sh-adressen för swapen, medan resten återgår till säljarens adress.
• Kunden överför en signatur som möjliggör att tokens och växelpengar kan överföras till mottagarens adress.
• Säljaren avslöjar hemligheten
• Historien upprepas med en ny hemlighet, där tidigare köpt som redan har betalats till säljaren läggs till växeln och växelpengarna.

Nu har vi tillgång till högsnabb p2p-handel, det är viktigt att hålla ett öga på tiden och stänga affären innan tidsgränsen.

Men genom att justera våra kontrakt lite kan vi ge våra kanaler odödlighet, vilket kommer att förenkla nätverksuppbyggnaden avsevärt.

Men det får vi berätta mer om i nästa avsnitt.

Källa: habr.com