Loom Network a Škálovateľnosť Etherea pomocou Sidechains

Škálovateľnosť nielen Etherea ale aj každého ďalšieho blockchainu je problém, o ktorom nikto nechcel počuť a každý sa ho bál až do roku 2017, kým projekt Cryptokitties, exponenciálne naberajúci na popularite, nezačal spomaľovať sieť a nevytlačil čas cenu gasu za transakcie do výšin.

josh-riemer-729195-unsplash

Téma CryptoKitties je viac než len vyčerpaná, keďže bola omieľaná dlhé mesiace v každom crypto-news. Okrem popularity, projekt CryptoKitties poukázal na jednu dôležitú vec. Štádium, v akom sa momentálne nachádza Ethereum poukazuje na to, že sieť nieje pripravená na enormné množstvo užívateľov a trafficu na sieti, ktoré prichádza so spustením úspešnej Dapplikácie. Preto je nutné nájsť riešenie pre tento problém a toto je aj téma tohto článku.

Trilemma

Jednou z teórií technológie blockchain je, že sieť môže podporovať iba dve z nasledujúcich možností: bezpečnosť, decentralizáciu a škálovateľnosť. Táto “trilemma” – bola a je výzvou Ethereum developerov, pretože sa vždy snažia zachovať základné princípy technológie blockchiain (decentralizácia a bezpečnosť), zatiaľ čo sa snažia túto technológiu prispôsobiť a “poľudštiť” (UX) pre širšiu adopciu vo svete. Niektoré z návrhov pre riešenie tohto problému ale vážne ovplyvňujú základné princípy, ktorými sú práve bezpečnosť a decentralizácia.

Používanie altcoinov bolo jedným z prvých teoretických riešení škálovateľnosti blockchainu. V princípe ide o upustenie od myšlienky jediného blockchainu, na ktorom prebiehajú všetky operácie a namiesto toho je predstavený model, v ktorom koexistujú viaceré altcoiny, kde všetky fungujú na samostatných ledgeroch. Práve takéto zredukovanie operácii per blockchain a vytvorenie samostatných blockchainov – sidechainov k jednotlivým dapplikáciám by malo pomôcť škálovateľnosti nielen Ethereum blockchainu. Nerieši však trilemma problém. Práve s menším počtom uzlov v sieti na každom takomto blockchaine prichádza aj vyššia pravdepodobnosť, resp. náchylnosť na útoky a škodlivých užívateľov v sieti. Preto toto riešenie hoc výrazne napomáha škálovateľnosti technológie blockchain, výrazne ale ovplyvňuje jej bezpečnosť.

Za zmienku stojí aj ďalšie riešenie škálovateľnosti – zväčšovanie veľkosti bloku(Increasing block size). Ak by Ethereum komunita volila v prospech zväčšenia veľkosti bloku, všetky uzly(nodes) v sieti by rovnako procesovali všetky operácie v sieti ako doteraz s tým, že viac transakcií by sa sprocesovalo za rovnaký čas. Tým pádom by došlo k vyššej priepustnosti, resp. laicky povedané, došlo by k zrýchleniu siete. Vyššou veľkosťou blocku ale vyžaduje aj väčšie množstvo energie. To znamená, že stále menšie množstvo uzlov v sieti, minerov, by bolo schopných udržať produkciu. Pre budúcnosť by to znamenalo to, že pravdepodobne by sieť v budúcnosti prevádzkovala len malá skupina superpočítačov, čo logicky znamená centralizáciu.

Hlavné sústredenie pri vývoji technológie blockchain bolo vždy na bezpečnosť a decentralizáciu. Preto v súčasnosti hlavnou prekážkou pre škálovateľnosť je fakt, že každý uzol v sieti spracováva každú transakciu. Hoci je tento proces bezpochyby bezpečný a decentralizovaný, natívne nám neposkytuje veľa priestoru pre rast. Tu práve prichádza otázka trillemy. Sme schopní adoptovať pre naše dapplikácie technológiu Ethereum v takej miere, aby sme ju dokázali škálovať a neovplyvnili sme bezpečnosť alebo decentralizáciu?

V súčasnosti sú vo vývoji štyri protokoly, ktoré práve túto otázku riešia – Sharding, Plasma, Raiden. Za zmienku stojí Casper, ktorý ale je vyvýjaný v rámci Ethereum protokolu ako celku a je to obsiahlejšia téma.

V tomto článku sa budeme bližšie venovať práve sidechainom a scalability riešeniu zvanom Plasma, ktorý bol predstavený 10. augusta 2017 Vitalikom Buterinom a Josephom Poonom.

O Plasme v krátkosti

Podobne ako Bitcoin Lighting Network, Plasma predstavuje riešenie alebo spôsob uskutočňovania off-chain transakcií, pričom bezpečnosť týchto transakcií je zabezpečovaná “materským” blockchainom, ako v prípade Plasma technológie je to Ethereum blockchain. Plasma umožňuje vytváranie “child” blockchainov, ktoré sú stále v spojení s ich “materským” blockchainom, v prípade technológie Plasma je to Ethereum blockchain. Tieto child-chains môžu dokonca vytvárať svoje sub-child-chains. Plasma a sidechainy sú v podstate vetvy rôznych chainov v spojení s ich materským blockchainom. Procesovanie smart contractov bude vždy prebiehať ako na Ethereovej sieti s tou výnimkou, že iba konečný výsledok celého procesu je uložený v materskom chaine, resp. je tam premietnutý výsledok procesu. Môžeme si to predstaviť ako hierarchickú štruktúru blockchainov, procesujúce informácie periodicky späť do ich materského chainu.

0_gHDyU65BfvNG-VHn

V konečnom dôsledku nám z toho vyplýva, že vďaka minimálnemu počtu uzlov v sidechaine a tým aj vďaka vyššej rýchlosti a zanedbateľným nákladoch na gas môžeme procesovať komplexnejšie operácie, resp. komplexnejší kód v smart contractoch, kde len konečný výsledok sa premietne späť do hlavného chainu – v prípade Plasma do Ethereum blockchainu. To umožňuje developerom vytvárať celé aplikácie na technológii blockchain s tisíckami userov, bez obáv zo škálovateľnosti či obmedzení.

 

Čo sú teda hlavné výhody Plasmy?

  • Plasma pomôže Ethereu spracovávať oveľa väčšie datasety ako je v súčasnosti možné.
  • Vďaka veľkému nárastu transakčnej kapacity/priepustnosti umožňuje rôznym aplikáciám s komplexnejšími operáciami bežať na technológii blockchain.
  • Nižší počet uzlov na sieti procesuje len transakcie zo sidechainu. Tým pádom poplatky za transakcie sú zanedbateľne malé.
  • Plasma nám pomôže zbaviť sa zbytočných dát, v súčasnosti ukaldaných do main-chainu. Ušetrí to obrovské množstvo energie a pamäte na main-chain uzloch.
  • Plasma je kompatibilná s rôznymi on-chain riešeniami škálovateľnosti ako napríklad sharding, rôzne veľkosti blokov a podobne.

Plasma v praxi – Plasma Cash a DAppChain

V súčasnosti celý ekosystém dapplikácií trpí neefektivitou. Neefektivitou v smere miešania sa transakcií finančných s transakciami v podobe spúšťania funkcií na smart contractoch a interagovania s funkcionalitou dapplikácií. Či už sa jedná o inštrukciu v smart contracte alebo transfer miliónov dolárov medzi peňaženkami, každá takáto transakcia je v súčasnosti spracovávaná s rovnakou úrovňou zabezpečenia. V podstate toto nie je samotným problémom. Bezpečnosť je vždy prvoradá, keďže aj príkaz na smart contract môže mať hodnotu miliónov. Problém je však škálovateľnosť a situácie, kedy nie sú príkazy na smart contracty vyslovene len napríklad, o uvoľňovaní financií ale len manipulácia s dátami, prípadne nejaký update. Je to ako platiť si premium funkcionalitu, keď potrebuje len basic. Nie každá transakcia v dapplikácii vyžaduje rovnakú úroveň zabezpečenia. Útočník alebo hacker má oveľa menší záujem exploitovať a škodiť transakciám v rámci dapplikácií, kde sa jedná doslova o mikrotransakcie, ako naopak v prípade útokov ako double-spending, ktoré môžu mať hodnotu miliónov eur.

Loom Network

Práve tento problém – problém škálovateľnosti DApplikácií rieší projekt Loom a ich DAppChain. DAppChain ako ďalšia vrstva nad Ethereovým blockchainom. Hlavnou filozofiou Loom DappChainu je vytvoriť pre každú dapp osobitný sidechain, ktorý funguje paralelne s Ethereovým mainchainom a s assetmi zabezpečnými práve technológiou Plasma.

1 dapp = 1 sidechain

Podľa zdrojov z Loom-u, táto filozofia “1 dapp = 1 sidechain” prináša niekoľko výhod. Prvou výhodou môže byť využitie alternatívneho konsenzus mechanizmu, ako napríklad DPoS – Delegated Proof of Stake), čo prinesie výraznú optimalizáciu v kontexte škálovateľnosti chainu. Druhou výhodou je využitie ako core sidechainu Ethereum blockchain, čo umožňuje tokenom ako ERC20 a ERC721 fungovať na sidechaine a komunikovať s Ethereum blockchainom vďaka Plasme. Podľa Loom-u, implementácia spomínaného Delegated Proof of Stake konsenzus umožňuje vyvíjať robustné dapplikácie s transakciami, ktoré sú “gas-less”, to znamená, že sú bez obvyklých nákladov na gas, ktorý sa vyžaduje na Ethereum mainchaine a zároveň transakcie prebiehajú v zlomku sekundy. Toto nastavenie umožňuje vytvárať dapplikácie, ktoré na bežnom chaine doteraz neboli moc efektívne, prípadne veľmi nákladné, ako napríklad hry a tokenová ekonomika v hrách či celé decentralizované sociálne siete.

Úloha technológie Plasma je v tomto prípade zabezpečenie dôvery medzi hlavným Ethereum chainom a DAppChainom, ako napríklad transfer ERC20 či ERC721 tokenov z Ethereum mainchain na DAppChain a zasa späť, bez potreby dôvery v konsenzuálny mechanizmus na DAppChaine. Prejdime ale od teórie k praxi a ukážme si to na reálnom príklade.

Loom Transfer Gateway

[Poznámka autora – Tutoriál je určený pre pokročilých programátorov z oblasti technológie blockchain a Etherea. Pokiaľ ste len na začiatku, určite odporúčam začať s TruffleNetwork.]

Transfer Gateway ako už nám naznačuje voľný preklad do slovenčiny, predstavuje bránu medzi Ethereum blockchainom a Loom dappchainom. Bránu pre transfer tokenov na sidechaine a ich bezpečný prenos späť na Ethereum mainchain. Podľa oficiálnej dokumentácie Loom networku je v tomto momente podporovaný len štandard tokenov ERC721 a podpora pre ERC20 by mala byť čoskoro implementovaná. S malými úpravami dokážeme však už teraz transferovať ERC20 a tým logicky aj ERC223 medzi mainchainom a sidechainom. Skôr než prejdeme ku kódu, začnime najskôr s vysvetlením čo vlastne Transfer Gateway je a ako funguje.

Transfer Gateway pozostáva zo štyroch hlavných komponentov:

  • Gateway smart contract na strane Ethereum blockchainu
  • Gateway smart contract na strane Loom dappchainu
  • Address mapper smart contract na strane Loom dappchainu
  • Loom Gateway Oracle ako standalone proces

Každá adresa peňaženky na Ethereum blockchaine, ktorá chce interagovať s Loom dappchainom, musí byť s ním spárovaná. V skratke, automaticky pri transferovaní tokenov, je vytvorená párovacia adresa na Loom dappchaine k danej peňaženke.

Aby užívateľ dokázal preniesť svoje tokeny na dappchain, musí ich najprv tranferovať na Gateway smart contract na Ethereum blockchaine, ktorý nasledovne emituje “deposit event” – informáciu o tom, že užívateľ poslal tokeny na Gateway smart contract. Tento deposit event je vyzdvihnutý Gateway Oraclom, ktorý ma za úlohu observovať tieto eventy na smart contract na Ethereum blockchaine a informovať o týchto eventoch Gateway smart contract na strane Loom dappchainu. V momente ako Gateway smart contract na strane Loom dappchainu má informáciu o depositovaných tokenoch na Ethereum Gateway, Loom dappchain Gateway vytvorí klon týchto tokenov na strane Loom dappchainu.

Snímka obrazovky 2018-12-18 o 17.06.25

Ak chce užívateľ svoje tokeny preniesť späť na Ethereum blockchain, musí ich najprv transfernúť na Loom dappchain gateway, ktorý vytvorí požiadavku na výber tokenov, ktorá je pripravená na podpis. Gateway Oracle túto požiadavku vyzdvihne, podpíše a posunie informáciu o podpise Loom dappchain gateway, ktorý notifikuje užívateľa o tom, že jeho tokeny sú pripravené na Ethereum Gateway a môže transakciou podpísať výber týchto tokenov späť na jeho peňaženku.

Snímka obrazovky 2018-12-18 o 17.06.33

Pre lepší prehľad a pochopenie ako Loom dappchain funguje, prejdime ku kódu. Zdrojový kód k spusteniu vlastného dappchainu si môžete naklonovať z môjho Github repozitára na tejto adrese GITHUB LINK.

Minimálne požiadavky:

  • node >= 8
  • wget
  • nc (pre kontrolu obsadených portov)
  • MetaMask

Začneme naklonovaním repozitára:

git clone https://github.com/OndroS/looom-transfer-gateway-tutorial.git

Po naklonovaní repa vidíme súborovú štruktúru ako:

├── dappchain
├── truffle-ethereum
├── truffle-dappchain
├── transfer-gateway-scripts
└── webclient
  • dappchain – obsahuje binary k loom dappchain, dappchain oracle a config súbor
  • transfer-gateway-scripts – JS script, ktorý sa stará o mapovanie adries peňaženiek
  • truffle-dappchain – Ethereum core loom dappchainu, obsahuje zdrojáky k smart contractom a scripty pre deploy
  • truffle-ethereum – Lokálny Ethereum chain na Ganache, pre účely testu a simulácie mainchainu, obsahuje zdrojáky k smart contractom a scripty pre deploy
  • webclient – obsahuje UI komponenty a logiku medzi mainchainom a dappchainom

Po naklonovaní repa môžeme nainštalovať všetky potrebné súčasti spustením scriptu:

./transfer_gateway setup

Keď setupnutie všetkých balíčkov prejde v poriadku, sme pripravení sidechain spustiť:

./transfer_gateway start

Script transfer_gateway a príkaz start nám spustia lokálne servery a spustia deploy pre Ganache ethereum blockchain a Loom dappchain. Deploy zabezpečuje Truffle. Kto prišiel do kontaktu s TruffleNetwork, veľmi jednoducho pochopí fungovanie sidechainu a jeho následnú modifikáciu.

Na interakciu s dapplikáciou musíte mať nainštalovaný Metamask. Keďže ideme interagovať s lokálnou inštanciou blockchainu, metamask si musíme prepnúť na lokalhost network, defaultne nastavenou na port 8545.

Po prepnutí siete si importujeme defaultný účet automaticky generovaný Ganache inštanciou etherea pomocou nasledujúceho privatekey:

0xbb63b692f9d8f21f0b978b596dc2b8611899f053d68aec6c1c20d1df4f5b6ee2

 

Ak by sme si chceli prejsť celý zdrojový kód detailne, nebol by to tutoriál ale celý román, preto vyberiem najpodstatnejšie súčasti, ktoré v kratkosti popíšem. štruktúra a celkovo kód je jednoduchý na pochopenie, preto zbehlejší JS programátor pochopí vzťahy veľmi rýchlo. Prípadne je k dispozícii oficiálna dokumentácia transfer gateway, ktorá pomôže určite lepšie.

Začnime config yaml file-om z prvej zložky “dappchain”. Súbor obsahuje všetky konkrétne presmerovania a linky, podstatné pre binary loomu a loom oraclu, zabezpečujúci spojenie medzi dvoma chainami. Z komentárov je jasné, k čomu patrí aký riadok:

# This is a unique identifier for the DAppChain used in this example
ChainID: 'default'
# This enables the latest version of the contract registry maintained by the DAppChain, which is
# required in order for the Transfer Gateway to be able verify DAppChain contract ownership.
# This setting must not be changed after the DAppChain starts for the first time!
RegistryVersion: 2
# Transfer Gateway Settings
TransferGateway:
# Enables the Gateway Go contract (DAppChain Gateway), must be the same on all nodes.
ContractEnabled: true

# Enables the in-process Gateway Oracle.
OracleEnabled: true

# Address of the Ganache network where the Mainnet Solidity contracts are deployed
# (take a look at the truffle-ethereum directory).
EthereumURI: 'http://127.0.0.1:8545'

# Address of the Mainnet Gateway contract deployed to the Ganache network above.
MainnetContractHexAddress: '0xf5cad0db6415a71a5bc67403c87b56b629b4ddaa'

# Private key that will be used by the Gateway Oracle to sign pending withdrawals.
MainnetPrivateKeyPath: 'oracle_eth_priv.key'

# Private key that will be used by the Gateway Oracle to send txs to the DAppChain Gateway.
DAppChainPrivateKeyPath: 'oracle_priv.key'

# Address of DAppChain node the Gateway Oracle should interact with.
DAppChainReadURI: 'http://localhost:46658/query'
DAppChainWriteURI: 'http://localhost:46658/rpc'

# These control how frequently the Gateway Oracle will poll the DAppChain and Ganache.
DAppChainPollInterval: 1 # seconds
MainnetPollInterval: 1 # seconds

# Number of seconds to wait before starting the Gateway Oracle, this allows the DAppChain node
# to spin up before the Gateway Oracle tries to connect to it.
OracleStartupDelay: 5

# Number of seconds the Gateway Oracle should wait between reconnection attempts if it encounters
# a network error of some kind.
OracleReconnectInterval: 5

Najpodstatnejšou súčasťou je samotný Gateway smart contract. Stará sa o emitovanie eventov hneď po tom ako užívateľ naňho spravil deposit jeho tokenov. Emitovaná eventy následne prevezme Loom Oracle, ktorý ich posunie ďalej ako to bolo popisované vyššie, prípadne uvoľní tokeny pre ich withdrawal. Konkrétne tento Gateway smart contract zvládne manažovanie nielen ERC721 ale aj ERC20 a Etherea.

pragma solidity ^0.4.24;

import "openzeppelin-solidity/contracts/token/ERC721/ERC721.sol";
import "openzeppelin-solidity/contracts/token/ERC20/ERC20.sol";
import "openzeppelin-solidity/contracts/math/SafeMath.sol";
import "openzeppelin-solidity/contracts/token/ERC721/ERC721Receiver.sol";
import "./ERC20Receiver.sol";
import "./ValidatorManagerContract.sol";


contract Gateway is ERC20Receiver, ERC721Receiver, ValidatorManagerContract {

  using SafeMath for uint256;

  struct Balance {
    uint256 eth;
    mapping(address => uint256) erc20;
    mapping(address => mapping(uint256 => bool)) erc721;
  }

  mapping (address => Balance) balances;

  event ETHReceived(address from, uint256 amount);
  event ERC20Received(address from, uint256 amount, address contractAddress);
  event ERC721Received(address from, uint256 uid, address contractAddress);

  enum TokenKind {
    ETH,
    ERC20,
    ERC721
  }

  /**
   * Event to log the withdrawal of a token from the Gateway.
   * @param owner Address of the entity that made the withdrawal.
   * @param kind The type of token withdrawn (ERC20/ERC721/ETH).
   * @param contractAddress Address of token contract the token belong to.
   * @param value For ERC721 this is the uid of the token, for ETH/ERC20 this is the amount.
   */
  event TokenWithdrawn(address indexed owner, TokenKind kind, address contractAddress, uint256 value);

  constructor (address[] _validators, uint8 _threshold_num, uint8 _threshold_denom)
    public ValidatorManagerContract(_validators, _threshold_num, _threshold_denom) {
  }

  // Deposit functions
  function depositETH() private {
    balances[msg.sender].eth = balances[msg.sender].eth.add(msg.value);
  }

  function depositERC721(address from, uint256 uid) private {
    balances[from].erc721[msg.sender][uid] = true;
  }

  function depositERC20(address from, uint256 amount) private {
    balances[from].erc20[msg.sender] = balances[from].erc20[msg.sender].add(amount);
  }

  // Withdrawal functions
  function withdrawERC20(uint256 amount, bytes sig, address contractAddress)
    external
    isVerifiedByValidator(amount, contractAddress, sig)
  {
    balances[msg.sender].erc20[contractAddress] = balances[msg.sender].erc20[contractAddress].sub(amount);
    ERC20(contractAddress).transfer(msg.sender, amount);
    emit TokenWithdrawn(msg.sender, TokenKind.ERC20, contractAddress, amount);
  }

  function withdrawERC721(uint256 uid, bytes sig, address contractAddress)
    external
    isVerifiedByValidator(uid, contractAddress, sig)
  {
    require(balances[msg.sender].erc721[contractAddress][uid], "Does not own token");
    ERC721(contractAddress).safeTransferFrom(address(this),  msg.sender, uid);
    delete balances[msg.sender].erc721[contractAddress][uid];
    emit TokenWithdrawn(msg.sender, TokenKind.ERC721, contractAddress, uid);
  }

  function withdrawETH(uint256 amount, bytes sig)
    external
    isVerifiedByValidator(amount, address(this), sig)
  {
    balances[msg.sender].eth = balances[msg.sender].eth.sub(amount);
    msg.sender.transfer(amount); // ensure it's not reentrant
    emit TokenWithdrawn(msg.sender, TokenKind.ETH, address(0), amount);
  }

  // Approve and Deposit function for 2-step deposits
  // Requires first to have called `approve` on the specified ERC20 contract
  function depositERC20(uint256 amount, address contractAddress) external {
    ERC20(contractAddress).transferFrom(msg.sender, address(this), amount);
    balances[msg.sender].erc20[contractAddress] = balances[msg.sender].erc20[contractAddress].add(amount);
    emit ERC20Received(msg.sender, amount, contractAddress);
  }

  // Receiver functions for 1-step deposits to the gateway

  function onERC20Received(address _from, uint256 amount)
    public
    returns (bytes4)
  {
    require(allowedTokens[msg.sender], "Not a valid token");
    depositERC20(_from, amount);
    emit ERC20Received(_from, amount, msg.sender);
    return ERC20_RECEIVED;
  }

  function onERC721Received(address _from, uint256 _uid, bytes)
    public
    returns (bytes4)
  {
    require(allowedTokens[msg.sender], "Not a valid token");
    depositERC721(_from, _uid);
    emit ERC721Received(_from, _uid, msg.sender);
    return ERC721_RECEIVED;
  }

  function () external payable {
    depositETH();
    emit ETHReceived(msg.sender, msg.value);
  }

  // Returns all the ETH you own
  function getETH(address owner) external view returns (uint256) {
    return balances[owner].eth;
  }

  // Returns all the ETH you own
  function getERC20(address owner, address contractAddress) external view returns (uint256) {
    return balances[owner].erc20[contractAddress];
  }

  // Returns ERC721 token by uid
  function getNFT(address owner, uint256 uid, address contractAddress) external view returns (bool) {
    return balances[owner].erc721[contractAddress][uid];
  }
}

Pokiaľ si otvoríme smart contracty v súborových zložkách truffle, pre loom dappchian a ethereum, jedná sa len o dvojice smart contract pre ERC tokeny, ktoré v tomto tutoriále nestoja za reč a sú základom práce. Pre nás je podstatný ERC20:

pragma solidity ^0.4.24;

import "openzeppelin-solidity/contracts/token/ERC20/StandardToken.sol";
import "openzeppelin-solidity/contracts/AddressUtils.sol";
import "./ERC20Receiver.sol";


contract GameToken is StandardToken {
  string public name = "GameToken";
  string public symbol = "GTK";
  uint8 public decimals = 18;

  address gateway;

  bytes4 constant ERC20_RECEIVED = 0xbc04f0af;

  using AddressUtils for address;

  // one billion in initial supply
  uint256 public constant INITIAL_SUPPLY = 1000000000;

  constructor (address _gateway) public {
    totalSupply_ = INITIAL_SUPPLY * (10 ** uint256(decimals));
    balances[msg.sender] = totalSupply_;
    gateway = _gateway;
  }

  // Additional functions for gateway interaction, influenced from Zeppelin ERC721 Impl.

  function depositToGateway(uint256 amount) external {
    safeTransferAndCall(gateway, amount);
  }

  function safeTransferAndCall(address _to, uint256 amount) public {
    transfer(_to, amount);
    require(
      checkAndCallSafeTransfer(msg.sender, _to, amount),
      "Sent to a contract which is not an ERC20 receiver"
    );
  }

  function checkAndCallSafeTransfer(address _from, address _to, uint256 amount) internal returns (bool) {
    if (!_to.isContract()) {
        return true;
    }

    bytes4 retval = ERC20Receiver(_to).onERC20Received(_from, amount);
    return(retval == ERC20_RECEIVED);
  }
}

Podstatnou modifikáciou contractu v truffle-ethereum zložke je ale funkcia pre depositovanie na Gateway smart contract:

function depositToGateway(uint amount) public {
  safeTransferFrom(msg.sender, gateway, amount);
}

A zasa na strane truffle-dappchain, zložka obsahuje smart contracty pre správu a  mintovanie tokenov na strane loom dappchainu. Keď užívateľ depozituje ERC20 token z Etheruem blockchainu na dappchain, Gateway contract na strane dappchainu vymintuje korešpondujúcu čiastku tokenov na strane dappchainu:

function mint(uint256 _uid) public {
  require(msg.sender == gateway);
  _mint(gateway, _uid);
}

Treba si pamätať, že Gateway contract na strane dappchainu musí byť autorizovaný mintovať tokeny na strane dappchainu. To znamená, že peňaženky musia byť vždy spárované a peňaženka na strane Ethereum blockchainu musí byť dokázateľným vlastníkom tokenom depositovaných na Gateway na strane Ethereum blockchainu.

Pre tých, ktorým sa nechce spúšťať celú appku, pripájam zopár screenshotov. Prvý je signovanie do dappky, kde zároveň na pozadí prebieha párovanie adries.

Snímka obrazovky 2018-12-19 o 12.19.56

Po prihlásení vidíme balance svojich tokenov, ktoré môžeme transferovať na Loom dappchain. Keďže stále robíme transfer tokenov na Ethereum Gateway, musíme platiť gas.

Snímka obrazovky 2018-12-19 o 12.20.32

Na pozadí, po depozitovaní na Ethereum Gateway, je emitovaný event na základe ktorého Loom Oracle posunie informáciu o deposite na Gateway na strane Loomu. Následne sú vymintované tokeny a pripravené na použitie v peňaženke na dappchaine.

Snímka obrazovky 2018-12-19 o 12.42.49

 

Záver

Tento tutoriál predstavuje len veľmi stručný úvod do problematiky sidechainov a riešenia škálovateľnosti na Ethereovom blockchaine. Čerpal som len z dostupných zdrojov v oficiálnej dokumentácie Loom Networku. Dokumentácia je žiaľ veľmi nekompletná a človek musí štúdiu ich knižníc venovať enormné množstvo času pre pochopenie a následnú implementáciu. Celý tento čas by bol ušetrený prehľadnou dokumentáciu, nielen strohými inštrukciami, ktoré v súčasnosti Loom poskytuje. Snáď sa to do budúcnosti zlepší, pretože ja osobne Loom vnímam ako projekt s obrovským potenciálom a širokým využitím v budúcnosti a to nielen v hernom priemysle. Nechajme sa ale prekvapiť.

 

Related Posts