Smart contracts

En este artículo repasamos los protocolos blockchain que incorporan Smart Contracts.

¿Qué es un smart contract?

En el mundo blockchain es más parecido a un programa informático que a un contrato de los que estamos acostumbrados a ver en los bancos o los seguros.
Los smart contracts se compilan, desplegan y se ejecutan en máquinas virtuales de los nodos de la red blockchain.
Habitualmente los smart contracts se compilan en código de bytes que los nodos son capaces de gestionar y ejecutar.
En la blockchain se registran las transacciones realizadas de esos smart contracts.

La mayoría de los protocolos blockchain son open-source y permiten crear dApps (aplicaciones distribuidas).

Los smart contracts suelen hacer uso de un token propio de cada blockchain que se consume en su despliegue y ejecución.

Los smart contracts no se pueden modificar una vez se han desplegado en la blockchain, tampoco se puede eliminar la información, hay que tenerlo en cuenta de cara a las nuevas reglas de la protección de datos, en concreto con el "derecho al olvido".

Uno de los usos actuales de los smart contracts es la creación de tokens de tipo ERC20.

Aunque Ethereum fue el primer protocolo blockchain especializado en smart contracts que salió a la luz, actualmente existen varios protocolos que pujan por ser el mejor.

Esta es una lista de protocolos blockchain que permiten smart contracts. Ordenada siguiendo el market cap (la capitalización de mercado).

Algunos de ellos aún están en desarrollo y prometen muchas cosas. Actualmente Ethereum y NEM son las apuestas más fiables a la hora de desarrollar smart contracts, pero habrá que estar pendiente de cual se desmarca del resto.

smart contracts ejemplos

A continuación se puede ver un smart contract de tipo ERC20 desarrollado en Solidity (gracias a OpenZeppelin):

pragma solidity ^0.4.24;

import "./IERC20.sol";
import "../../math/SafeMath.sol";


/**
 * @title Standard ERC20 token
 *
 * @dev Implementation of the basic standard token.
 * https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md
 * Originally based on code by FirstBlood: https://github.com/Firstbloodio/token/blob/master/smart_contract/FirstBloodToken.sol
 */
contract ERC20 is IERC20 {
  using SafeMath for uint256;

  mapping (address => uint256) private _balances;

  mapping (address => mapping (address => uint256)) private _allowed;

  uint256 private _totalSupply;

  /**
  * @dev Total number of tokens in existence
  */
  function totalSupply() public view returns (uint256) {
    return _totalSupply;
  }

  /**
  * @dev Gets the balance of the specified address.
  * @param owner The address to query the balance of.
  * @return An uint256 representing the amount owned by the passed address.
  */
  function balanceOf(address owner) public view returns (uint256) {
    return _balances[owner];
  }

  /**
   * @dev Function to check the amount of tokens that an owner allowed to a spender.
   * @param owner address The address which owns the funds.
   * @param spender address The address which will spend the funds.
   * @return A uint256 specifying the amount of tokens still available for the spender.
   */
  function allowance(
    address owner,
    address spender
   )
    public
    view
    returns (uint256)
  {
    return _allowed[owner][spender];
  }

  /**
  * @dev Transfer token for a specified address
  * @param to The address to transfer to.
  * @param value The amount to be transferred.
  */
  function transfer(address to, uint256 value) public returns (bool) {
    require(value <= _balances[msg.sender]);
    require(to != address(0));

    _balances[msg.sender] = _balances[msg.sender].sub(value);
    _balances[to] = _balances[to].add(value);
    emit Transfer(msg.sender, to, value);
    return true;
  }

  /**
   * @dev Approve the passed address to spend the specified amount of tokens on behalf of msg.sender.
   * Beware that changing an allowance with this method brings the risk that someone may use both the old
   * and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this
   * race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards:
   * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
   * @param spender The address which will spend the funds.
   * @param value The amount of tokens to be spent.
   */
  function approve(address spender, uint256 value) public returns (bool) {
    require(spender != address(0));

    _allowed[msg.sender][spender] = value;
    emit Approval(msg.sender, spender, value);
    return true;
  }

  /**
   * @dev Transfer tokens from one address to another
   * @param from address The address which you want to send tokens from
   * @param to address The address which you want to transfer to
   * @param value uint256 the amount of tokens to be transferred
   */
  function transferFrom(
    address from,
    address to,
    uint256 value
  )
    public
    returns (bool)
  {
    require(value <= _balances[from]);
    require(value <= _allowed[from][msg.sender]);
    require(to != address(0));

    _balances[from] = _balances[from].sub(value);
    _balances[to] = _balances[to].add(value);
    _allowed[from][msg.sender] = _allowed[from][msg.sender].sub(value);
    emit Transfer(from, to, value);
    return true;
  }

  /**
   * @dev Increase the amount of tokens that an owner allowed to a spender.
   * approve should be called when allowed_[_spender] == 0. To increment
   * allowed value is better to use this function to avoid 2 calls (and wait until
   * the first transaction is mined)
   * From MonolithDAO Token.sol
   * @param spender The address which will spend the funds.
   * @param addedValue The amount of tokens to increase the allowance by.
   */
  function increaseAllowance(
    address spender,
    uint256 addedValue
  )
    public
    returns (bool)
  {
    require(spender != address(0));

    _allowed[msg.sender][spender] = (
      _allowed[msg.sender][spender].add(addedValue));
    emit Approval(msg.sender, spender, _allowed[msg.sender][spender]);
    return true;
  }

  /**
   * @dev Decrease the amount of tokens that an owner allowed to a spender.
   * approve should be called when allowed_[_spender] == 0. To decrement
   * allowed value is better to use this function to avoid 2 calls (and wait until
   * the first transaction is mined)
   * From MonolithDAO Token.sol
   * @param spender The address which will spend the funds.
   * @param subtractedValue The amount of tokens to decrease the allowance by.
   */
  function decreaseAllowance(
    address spender,
    uint256 subtractedValue
  )
    public
    returns (bool)
  {
    require(spender != address(0));

    _allowed[msg.sender][spender] = (
      _allowed[msg.sender][spender].sub(subtractedValue));
    emit Approval(msg.sender, spender, _allowed[msg.sender][spender]);
    return true;
  }

  /**
   * @dev Internal function that mints an amount of the token and assigns it to
   * an account. This encapsulates the modification of balances such that the
   * proper events are emitted.
   * @param account The account that will receive the created tokens.
   * @param amount The amount that will be created.
   */
  function _mint(address account, uint256 amount) internal {
    require(account != 0);
    _totalSupply = _totalSupply.add(amount);
    _balances[account] = _balances[account].add(amount);
    emit Transfer(address(0), account, amount);
  }

  /**
   * @dev Internal function that burns an amount of the token of a given
   * account.
   * @param account The account whose tokens will be burnt.
   * @param amount The amount that will be burnt.
   */
  function _burn(address account, uint256 amount) internal {
    require(account != 0);
    require(amount <= _balances[account]);

    _totalSupply = _totalSupply.sub(amount);
    _balances[account] = _balances[account].sub(amount);
    emit Transfer(account, address(0), amount);
  }

  /**
   * @dev Internal function that burns an amount of the token of a given
   * account, deducting from the sender's allowance for said account. Uses the
   * internal burn function.
   * @param account The account whose tokens will be burnt.
   * @param amount The amount that will be burnt.
   */
  function _burnFrom(address account, uint256 amount) internal {
    require(amount <= _allowed[account][msg.sender]);

    // Should https://github.com/OpenZeppelin/zeppelin-solidity/issues/707 be accepted,
    // this function needs to emit an event with the updated approval.
    _allowed[account][msg.sender] = _allowed[account][msg.sender].sub(
      amount);
    _burn(account, amount);
  }
}

smart contracts ethereum

Utilizan la criptomoneda Ether y el gas. Este protocolo es el más utilizado para realizar ICOs, gracias a los smart contracts de tipo ERC20, que son contratos de tipo Token.

Actualmente usa el mecanismo de consenso PoW (Proof of Work), la famosa minería.
Está previsto que a finales de Octubre se rebaje la recompensa por bloque de 3 ETH a 2 ETH, y el año 2019 se cambiará el consenso por uno de tipo PoS (Proof of Stake).

Uno de los problemas que tiene por delante es la escalabilidad, el ratio de transacciones por segundo que es capaz de realizar lo hace inviable para cualquier proyecto de gran envergadura.

Se suele usar solidity para escribir los smart contracts

Visita este curso de ethereum con solidity para conocer más detalles de este protocolo blockchain.

smart contracts EOS

EOS es un proyecto de Block.one que es una compañía de software focalizada a blockchain.

Usa el mecanismo de consenso DPoS (Delegated Proof of Stake).

Consta de varias partes; el nodeos que es el proceso que ejecuta un nodo. Un nodo crea los bloques, y proporciona una API de acceso.
cleos que es un programa de linea de comandos que permite interactuar con la blockchain y permite gestionar wallets.
keosd es un componente que permite almacenar claves EOS en wallets.

Se suele usar C++ para escribir los smart contracts

smart contracts Stellar

Son algo complicados pues parece un añadido al protocolo.

Se puede usar cualquier lenguaje en el que tenga una API creada por stellar, y es una especie de composición de transacciones que se ejecutan según ciertas condiciones.

smart contracts Cardano

Utilizan la criptomoneda ADA.

Cardano es un protocolo blockchain que ha nacido de una filosofía científica.

Usa el mecanismo de consenso Ouroboros PoS (Proof of Stake).

Consta de varias partes; Daedalus que es la wallet que permite ejecutar dapps.

Se suele usar Plutus para escribir los smart contracts. Es un lenguaje de estilo Haskell.

smart contracts Tron

En principio es compatible con la EVM de Ethereum, con lo que se pueden usar los smarts contracts de solidity.

Promete una alta tasa de transacciones por segundo (unas 2000 por segundo).

La red de nodos consta de 3 tipos: Witness, que es el responsable de producir bloques. Nodo completo, que provee de una API y emite las transacciones y los bloques. Nodo solidity, que sincroniza bloques irrevocables y APIs de interrogación.

smart contracts NEO

Originado en China.

Se puede usar otros lenguajes para crear smart contracts.

Utiliza un algoritmo de consenso de tipo PoS (Proof of Stake). De todos modos una de las críticas que recibe es que está demasiado "centralizado". La distribución de los tokens queda limitada a la fundación NEO y a compañías chinas.

Se apoya en dos tokens: NEO y NeoGas. El primero se usa para gestionar la red de nodos. El segundo se usa para pagar las operaciones, almacenar tokens y smart contracts y varias otras tareas.

smart contracts Tezos

Usa un mecanismo de consenso PoS (Proof of Stake) y también se puede usar delegación.

No existe un límite para poder participar en el consenso y poder recibir recompensas.

El acto de publicar bloques se llama "baking". Así pues los "bakers" se encargan de validar transacciones y añadirlas a la blockchain, recibiendo un recompensa en Tez.

Los smart contracts en Tezos no son como en Ethereum, no hay un ordenador mundial que ejecuta código, sino que gestiona y posibilita transacciones.

Utiliza su propio lenguaje "Michelson", que tiene una curva de aprendizaje elevada. Podría parecerse un poco al script de bitcoin. No es un lenguaje de alto nivel.

smart contracts NEM

NEM no es un protocolo blockchain para desarrollar smart contracts en sí mismo, pero permite la gestión de assets o tokens mediante la creación de Mosaics, de modo visual, sin tener que programar demasiado.

Los smart contracts se programan fuera de la blockchain, con lo que se puede elegir cualquier lenguaje. Esto tiene ciertas ventajas frente a Ethereum: se puede actualizar el código fácilmente, la ejecución suele ser más rápida que en una EVM (Ethereum Virtual Machine).

Para conocer en detalle NEM puedes visitar el artículo sobre la criptomoneda NEM.

smart contracts Lisk

Es una plataforma para constuir dApps (aplicaciones distribuidas), no es propiamente una plataforma de smart contracts.

Usa Javascript. La idea que persigue es hacer la vida más fácil a los desarrolladores para construir y desplegar dApps usando Javascript. Se apoya bastante en Node.js

Promete ser modular. Es decir se podrá personalizar tu propia sidechain, ya sea los tokens, las transacciones o el consenso.

Promete ser escalable mediante el uso de sidechains, que son blockchains separadas de la blockchain principal.

Consta de varias herramientas: Lisk Hub, que permite gestionar tu Lisk ID, gestionar tus tokens LSK, y votar para los delegados. En el futuro incorporará un exchange descentralizado y la posibilidad de lanzar tu propia ICO.
Lisk Core, que es una herramienta para desarrolladores que permite acceder a los datos de la blockchain de la mainnet, hacer más segura la red. Es montar un nodo de la red.
Lisk Commander, que es un CLI para acceder a Lisk Core.
Lisk Elements, que es una colección de librerías (criptografía, acceso API, firma, y varias constantes).

Usa el mecanismo de consenso de DPoS (Delegated Proof of Stake).