Az intelligens szerződés címének meghatározása az üzembe helyezés előtt: a CREATE2 használata titkosítási cseréhez

A blokklánc témája nem szűnik meg nemcsak mindenféle hype forrása lenni, hanem technológiai szempontból nagyon értékes ötletek is. Ezért nem kerülte meg a napfényes város lakóit. Az emberek közelről néznek, tanulnak, és megpróbálják átadni a hagyományos információbiztonság terén szerzett szakértelmüket a blokklánc rendszerekre. Eddig a helyén van: a Rostelecom-Solar egyik fejlesztése képes ellenőrizni a blokklánc alapú szoftverek biztonságát. És közben felmerül néhány gondolat a blokklánc közösség alkalmazott problémáinak megoldásával kapcsolatban. Az egyik ilyen life hack – hogyan lehet meghatározni egy intelligens szerződés címét üzembe helyezés előtt a CREATE2 segítségével – ma szeretném megosztani veletek.

A CREATE2 műveleti kódot ez év február 28-án adták hozzá a Konstantinápolyi hard fork-ban. Az EIP-ben leírtak szerint ezt a műveleti kódot elsősorban az állami csatornákhoz vezették be. Mi azonban egy másik probléma megoldására használtuk.

Vannak egyenleggel rendelkező felhasználók a tőzsdén. Minden felhasználónak meg kell adnunk egy Ethereum-címet, amelyre bárki küldhet tokeneket, ezáltal feltöltheti fiókját. Nevezzük ezeket a címeket „pénztárcának”. Amikor a tokenek pénztárcákba érkeznek, egyetlen pénztárcába (hotwallet) kell küldenünk őket.

A következő szakaszokban elemzem a probléma CREATE2 nélküli megoldásának lehetőségeit, és elmondom, miért hagytuk el őket. Ha csak a végeredmény érdekli, a „Végső megoldás” részben megtalálhatja.

Ethereum címek

A legegyszerűbb megoldás az új Ethereum-címek létrehozása az új felhasználók számára. Ezek a címek lesznek a pénztárcák. A tokenek pénztárcából hotwalletbe történő átviteléhez alá kell írnia a tranzakciót a funkció meghívásával átruházás() a pénztárca privát kulcsával a háttérből.

Ennek a megközelítésnek a következő előnyei vannak:

• ez egyszerű
• a tokenek pénztárcából hotwalletbe történő átvitelének költsége megegyezik egy függvényhívás költségével átruházás()

Azonban úgy döntöttünk, hogy nem ezt a megközelítést, mert van egy nagy hátránya: valahol tárolni kell a privát kulcsokat. Nemcsak elveszhetnek, hanem gondosan kell kezelnie a kulcsokhoz való hozzáférést is. Ha ezek közül legalább az egyik veszélybe kerül, akkor egy adott felhasználó tokenek nem jutnak el a forró pénztárcához.

Hozzon létre külön intelligens szerződést minden felhasználó számára

Ha minden egyes felhasználó számára külön intelligens szerződést telepít, elkerülheti a pénztárcák privát kulcsainak a szerveren való tárolását. A tőzsde felhívja ezt az intelligens szerződést, hogy átvigye a tokeneket a hotwalletbe.

Ettől a megoldástól is eltekintettünk, mivel a felhasználónak nem mutatható meg a pénztárca címe okosszerződés kiépítése nélkül (ez valóban lehetséges, de meglehetősen összetett módon, egyéb hátrányokkal, amelyekről itt nem térünk ki). A tőzsdén egy felhasználó annyi fiókot hozhat létre, amennyire szüksége van, és mindegyiknek saját pénztárcára van szüksége. Ez azt jelenti, hogy pénzt kell költenünk egy szerződés bevezetésére anélkül, hogy biztosak lennénk abban, hogy a felhasználó használni fogja ezt a fiókot.

Opcode CREATE2

Az előző módszer problémájának megoldására a CREATE2 műveleti kód használata mellett döntöttünk. A CREATE2 lehetővé teszi, hogy előre meghatározza azt a címet, ahol az intelligens szerződés telepítésre kerül. A cím kiszámítása a következő képlettel történik:

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

, ahol:

• cím — a CREATE2-t hívó intelligens szerződés címe
• só - véletlenszerű érték
• init_code — intelligens szerződés bájtkódja a telepítéshez

Ez biztosítja, hogy a felhasználónak megadott cím valóban tartalmazza a kívánt bájtkódot. Sőt, ez az intelligens szerződés bármikor telepíthető, amikor szükségünk van rá. Például amikor egy felhasználó úgy dönt, hogy először használja a pénztárcáját.

Ezenkívül az intelligens szerződés címét minden alkalommal kiszámíthatja a tárolás helyett, mert:

• cím a képletben állandó, mivel ez a pénztárcagyárunk címe
• só — user_id hash
• init_code állandó, mivel ugyanazt a pénztárcát használjuk

További fejlesztések

A korábbi megoldásnak még van egy hátránya: fizetni kell az intelligens szerződés bevezetéséért. Azonban meg lehet szabadulni tőle. Ehhez meghívhatja a függvényt átruházás(), és akkor önpusztító() a pénztárca konstruktorban. És akkor az okosszerződés kiépítéséhez szükséges gázt visszaadják.

A közhiedelemmel ellentétben a CREATE2 műveleti kóddal többször is telepíthet egy intelligens szerződést ugyanarra a címre. Ennek az az oka, hogy a CREATE2 ellenőrzi, hogy a célcím nonce értéke nulla (a konstruktor elején "1" értéket kap). Ebben az esetben a függvény önpusztító() minden alkalommal visszaállítja a nonce címeket. Tehát ha újra meghívja a CREATE2-t ugyanazokkal az argumentumokkal, a nonce ellenőrzés átmegy.

Kérjük, vegye figyelembe, hogy ez a megoldás hasonló az Ethereum cím opcióhoz, de nincs szükség privát kulcsok tárolására. A pénztárcából a hotwalletbe történő pénzátvitel költsége megközelítőleg megegyezik egy funkció hívásának költségével átruházás(), mivel nem fizetünk az intelligens szerződések telepítéséért.

Végső döntés

Eredetileg készítette:

• funkciója, hogy sót kapjon user_id
• egy intelligens szerződés, amely meghívja a CREATE2 műveleti kódot a megfelelő sóval (azaz pénztárcagyár)
• pénztárca bájtkódja, amely megfelel a következő konstruktorral kötött szerződésnek:

constructor () {
    address hotWallet = 0x…;
    address token = 0x…;
    token.transfer (hotWallet, token.balanceOf (address (this)));
    selfdestruct (address (0));
}

Minden új felhasználónál számítással megmutatjuk a pénztárca címét

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

Amikor egy felhasználó tokeneket visz át a megfelelő tárcacímre, a háttérprogramunk egy Transfer eseményt lát a paraméterrel _nak nek, megegyezik a pénztárca címével. Ezen a ponton már lehetséges a felhasználó egyenlegének növelése a tőzsdén a pénztárca telepítése előtt.

Ha egy pénztárcacím elegendő számú tokent halmoz fel, azokat egyszerre átvihetjük a hotwalletbe. Ehhez a háttérrendszer meghívja az intelligens szerződésgyár funkciót, amely a következő műveleteket hajtja végre:

function deployWallet (соль uint256) {
    bytes memory walletBytecode =…;
    // invoke CREATE2 with wallet bytecode and salt
}

Így meghívásra kerül a pénztárca intelligens szerződés konstruktora, amely az összes tokenjét átviszi a hotwallet címére, majd önmegsemmisíti.

A teljes kód megtalálható itt. Kérjük, vegye figyelembe, hogy ez nem a mi gyártási kódunk, mivel úgy döntöttünk, hogy optimalizáljuk a pénztárca bájtkódját, és opkódokban írtuk meg.

Szerző: Pavel Kondratenkov, az Ethereum specialistája

Forrás: will.com