En este artículo, exploraremos qué son los contratos inteligentes, cuáles son sus tipos, conoceremos diferentes plataformas de contratos inteligentes, sus características, y discutiremos cómo funcionan y qué ventajas pueden ofrecer. Este material será muy útil para los lectores que no están suficientemente familiarizados con el tema de los contratos inteligentes, pero desean acercarse a su comprensión.
Contrato tradicional vs. contrato inteligente
Antes de profundizar en los detalles, analicemos, a modo de ejemplo, las diferencias entre un contrato tradicional, que se establece en papel, y un contrato inteligente, que está presentado en formato digital.

¿Cómo funcionaba esto antes de la aparición de los contratos inteligentes? Imagina un grupo de personas que desean establecer algunas reglas y condiciones para la distribución de valores, así como un mecanismo para garantizar la ejecución de esta distribución según las reglas y condiciones establecidas. Entonces, se reunían, redactaban un documento donde anotaban sus datos identificativos, condiciones, valores involucrados, ponían una fecha y firmaban. Este contrato también era validado por una parte de confianza, como un notario. Luego, estas personas se separaban con su copia en papel de dicho contrato y comenzaban a realizar algunas acciones que podían no corresponder con el contrato en sí, es decir, hacían una cosa, mientras que en el papel estaba validado que debían hacer algo completamente diferente. ¿Y cómo salir de esta situación? En realidad, alguien del grupo debía llevar este documento, aportar pruebas, ir al juzgado y exigir que hubiera correspondencia entre el contrato y las acciones efectivas. A menudo, conseguir que se cumpla de manera justa lo que estipula el contrato puede ser complicado, lo que conduce a consecuencias desagradables.
¿Qué se puede decir sobre los contratos inteligentes? Combinan la posibilidad de redactar las condiciones del contrato y un mecanismo para su ejecución rigurosa. Si las condiciones fueron establecidas y se firmó la transacción o solicitud correspondiente, tras la aceptación de esta solicitud o transacción, ya no es posible modificar las condiciones o influir en su ejecución.
Hay un validador o toda una red, así como una base de datos que almacena todos los contratos inteligentes que han sido ejecutados en un estricto orden cronológico. También es importante que esta base de datos contenga todas las condiciones-disparadores para la ejecución del contrato inteligente. Además, debe tener en cuenta el valor que se describe en el contrato. Si se trata de alguna moneda digital, esta base de datos debe reflejarla.
En otras palabras, los validadores de contratos inteligentes deben tener acceso a todos los datos con los que opera el contrato inteligente. Por ejemplo, se debe utilizar una única base de datos para gestionar simultáneamente las monedas digitales, los saldos de los usuarios, las transacciones de los usuarios y las marcas de tiempo. Así, una condición en el contrato inteligente puede ser el saldo de un usuario en una moneda específica, la llegada de un determinado tiempo o la realización de una transacción, y no más que eso.
Definición de contrato inteligente
En general, la terminología fue inventada por el investigador Nick Szabo y aplicada por primera vez en 1994, y fue documentada en 1997 en un artículo que describe la idea de los contratos inteligentes.
Los contratos inteligentes implican que se lleva a cabo cierta automatización en la distribución de valor, que puede depender únicamente de las condiciones preestablecidas. En la forma más simple, esto se presenta como un contrato con condiciones claramente definidas, firmado por partes específicas.
Los contratos inteligentes están diseñados para minimizar la confianza en terceros. A veces, se elimina por completo el centro de decisión del que todo depende. Además, es más fácil auditar tales contratos. Esto es un resultado de algunas características del diseño de este sistema, pero a menudo entendemos por contrato inteligente un entorno descentralizado y la existencia de funciones que permiten a cualquier persona analizar la base de datos y realizar una auditoría completa del cumplimiento de los contratos. De esta manera, se garantiza la protección contra cambios de datos retros que conducirían a modificaciones en la ejecución del propio contrato. La digitalización de la mayoría de los procesos al crear y lanzar un contrato inteligente a menudo simplifica la tecnología y el costo de su implementación.
Un ejemplo simple — un servicio de Escrow
Veamos un ejemplo muy simple. Esto ayudará a comprender las capacidades funcionales de los contratos inteligentes, así como a orientarse mejor sobre en qué casos deben aplicarse.

También se puede implementar utilizando Bitcoin, aunque en este momento es difícil considerar a Bitcoin como una plataforma completa para contratos inteligentes. Así que tenemos a un comprador y una tienda en línea. El comprador quiere comprar un monitor en esta tienda. En el caso más simple, el comprador hace y envía el pago, y la tienda en línea lo acepta y lo confirma, después de lo cual envía el producto. Sin embargo, en esta situación existe una gran necesidad de confianza: el comprador debe confiar toda la cantidad del monitor a la tienda en línea. Dado que la tienda en línea puede tener una reputación baja a los ojos del comprador, existe el riesgo de que, por alguna razón, después de aceptar el pago, la tienda se niegue a prestar el servicio y no envíe el producto al comprador. Por lo tanto, el comprador se pregunta (y, en consecuencia, la tienda en línea también se hace esta pregunta) qué se puede aplicar en este caso para minimizar estos riesgos y hacer que tales transacciones sean más seguras.
En el caso de Bitcoin, se puede dar al comprador y al vendedor la posibilidad de elegir un mediador de manera independiente. Hay muchas personas que se dedican a resolver disputas. Nuestros participantes pueden elegir de una lista común de mediadores a aquel en quien ambos confíen. Juntos crean una dirección multisignature de 2 de 3, donde hay tres llaves y se necesitan dos firmas de cualquiera de las dos llaves para gastar monedas de esa dirección. Una llave será del comprador, la segunda de la tienda en línea y la tercera del mediador. Y en esta dirección multisignature, el comprador enviará la cantidad necesaria para pagar el monitor. Ahora, cuando el vendedor ve que el dinero está bloqueado durante un tiempo en una dirección multisignature que depende de él, puede enviar el monitor sin problemas por correo.
A continuación, el comprador recibe el paquete, examina el producto y toma una decisión sobre la compra final. Puede estar completamente de acuerdo con el servicio proporcionado y firmar la transacción con su clave, donde transfiere monedas desde la dirección de firma múltiple al vendedor, o puede sentirse insatisfecho. En el segundo caso, se comunica con el mediador para elaborar una transacción alternativa que redistribuya las monedas de otra manera.
Supongamos que el monitor llegó un poco rayado y no incluía el cable para conectarlo a la computadora, aunque en el sitio web de la tienda en línea se especificaba que el cable debía estar incluido. Entonces, el comprador recopila pruebas necesarias para demostrar al mediador que ha sido engañado en esta situación: toma capturas de pantalla del sitio web, fotografía el recibo de la entrega, captura imágenes de los rayones en el monitor y muestra que el sello ha sido roto y que el cable ha sido retirado. Por su parte, la tienda en línea recopila sus propias pruebas y las envía al mediador.
El mediador está interesado en satisfacer tanto la indignación del comprador como los intereses de la tienda en línea (más adelante entenderemos por qué). Elabora una transacción en la que las monedas desde la dirección de firma múltiple se gastarían en cierta proporción entre el comprador, la tienda en línea y el mediador, ya que él se queda con una parte como recompensa por su trabajo. Supongamos que el 90% del total va al vendedor, el 5% al mediador y el 5% como compensación al comprador. El mediador firma esta transacción con su clave, pero aún no puede aplicarse, porque se necesitan dos firmas, y solo hay una. Envía esta transacción tanto al comprador como al vendedor. Si al menos uno de ellos está satisfecho con esta opción de redistribución de monedas, la transacción se firmará de nuevo y se difundirá en la red. Para su validación, basta con que uno de los participantes en el trato acepte la propuesta del mediador.
Es importante elegir inicialmente un mediador en quien ambas partes confíen. De esta manera, él actuará independientemente de los intereses de uno u otro y evaluará la situación de manera objetiva. Si el mediador no proporciona una opción de distribución de monedas que satisfaga al menos a un participante, entonces, acordando juntos, tanto el comprador como la tienda en línea pueden transferir las monedas a una nueva dirección multisig, colocando sus dos firmas. La nueva dirección multisig se formará con un mediador diferente, que puede ser más competente en el tema y ofrecer una mejor opción.
Ejemplo con una residencia estudiantil y un refrigerador
Vamos a considerar un ejemplo más complejo, que muestra las capacidades del contrato inteligente de manera más clara.

Supongamos que hay tres chicos que recientemente se mudaron a la misma habitación en una residencia estudiantil. Los tres están interesados en comprar un refrigerador para su habitación, el cual usarán en conjunto. Uno de ellos se ofreció para reunir la cantidad necesaria para la compra del refrigerador y negociar con el vendedor. Sin embargo, se conocen desde hace poco tiempo y no hay suficiente confianza entre ellos. Obviamente, dos de ellos están arriesgando al darle el dinero al tercero. Además, necesitan llegar a un acuerdo sobre la elección del vendedor.
Pueden usar un servicio de escrow, es decir, elegir un mediador que controle la ejecución del acuerdo y resuelva disputas si surgen. Entonces, acordando, redactan un contrato inteligente y especifican ciertas condiciones en él.
La primera condición es que, antes de que llegue un momento determinado, digamos en el transcurso de una semana, se deben recibir tres pagos en la cuenta correspondiente del contrato inteligente desde direcciones específicas por un monto determinado. Si esto no ocurre, el contrato inteligente deja de ejecutarse y devuelve las monedas a todos los participantes. Si se cumple la condición, se establecen los valores de los identificadores del vendedor y del mediador, y se verifica que todos los participantes estén de acuerdo con la elección del vendedor y del mediador. Cuando se cumplan todas las condiciones, los fondos se transferirán a las direcciones indicadas. Este enfoque puede proteger a los participantes de fraudes de cualquier lado y elimina la necesidad de confiar.
Vemos en este ejemplo el principio de que esta posibilidad de establecer paso a paso los parámetros para cumplir cada condición permite crear sistemas de cualquier complejidad y profundidad de niveles anidados. Además, primero se puede definir la primera condición en el contrato inteligente y solo tras su cumplimiento, establecer los parámetros para la siguiente condición. En otras palabras, formalmente la condición se redacta, pero los parámetros para ella se pueden establecer ya durante su ejecución.
Clasificación de contratos inteligentes
Para la clasificación se pueden establecer diferentes grupos de criterios. Sin embargo, en el momento actual del desarrollo tecnológico, cuatro de ellos son relevantes.
Los contratos inteligentes se pueden distinguir según el entorno de ejecución, que puede ser centralizado o descentralizado. En caso de descentralización, tenemos una independencia y una resistencia a fallos mucho mayores en la ejecución de contratos inteligentes.
También se pueden distinguir según el proceso de establecimiento y ejecución de condiciones: pueden ser programables arbitrariamente, limitados o preestablecidos, es decir, estrictamente tipificados. Cuando en la plataforma de contratos inteligentes existen solo 4 contratos inteligentes determinados, los parámetros para ellos se pueden establecer de forma arbitraria. Por lo tanto, es mucho más fácil establecerlos: elegimos el contrato de la lista y pasamos los parámetros.
Según el método de iniciación, existen contratos inteligentes automatizados, es decir, que se autoejecutan al cumplirse determinadas condiciones, y hay contratos en los que se establecen condiciones, pero la plataforma no verifica automáticamente su cumplimiento, por lo que deben ser iniciados por separado.
Además, los contratos inteligentes se diferencian por el nivel de privacidad. Pueden ser completamente abiertos, parcialmente abiertos o completamente confidenciales. Esto último significa que los observadores externos no ven las condiciones de los contratos inteligentes. Sin embargo, el tema de la privacidad es muy amplio y es mejor considerarlo por separado del artículo actual.
A continuación, nos detendremos con más detalle en los tres primeros criterios para aportar mayor claridad sobre el tema actual.
Contratos inteligentes según el entorno de ejecución

Según el entorno de ejecución, se diferencian entre plataformas de contratos inteligentes centralizadas y descentralizadas. En el caso de contratos digitales centralizados, se utiliza un único servicio donde existe un solo validador y puede haber un servicio de respaldo y recuperación, que también es gestionado de manera centralizada. Hay una base de datos que almacena toda la información necesaria para establecer las condiciones del contrato inteligente y distribuir el valor considerado en esa misma base de datos del servicio. Este servicio centralizado tiene un cliente que establece condiciones mediante solicitudes específicas y utiliza dichos contratos. Debido a que la plataforma es centralizada, los mecanismos de autenticación pueden ser menos fiables que en las criptomonedas.
Como ejemplo, se pueden tomar los proveedores de telefonía móvil (diferentes operadores móviles). Supongamos que un operador lleva de forma centralizada el registro del tráfico en sus servidores, que puede transmitirse en diferentes formatos, como llamadas de voz, SMS, tráfico de internet móvil, y bajo diferentes estándares, así como lleva un registro de los fondos en los saldos de los usuarios. En consecuencia, el proveedor de telefonía móvil puede establecer contratos para el registro de los servicios prestados y su pago con diferentes condiciones. En tal caso, es fácil establecer condiciones como “envía un SMS con cierto código a cierto número y recibirás ciertas condiciones de distribución del tráfico”.
Se puede dar otro ejemplo: bancos tradicionales con funcionalidad de banca en línea avanzada y contratos muy simples como pagos regulares, conversión automática de pagos entrantes, deducción automática de intereses a la cuenta especificada, etc.
Si hablamos de contratos inteligentes en un entorno de ejecución descentralizado, entonces tenemos un grupo de validadores. En un escenario ideal, cualquier persona puede convertirse en validador. Gracias al protocolo de sincronización de la base de datos y al consenso alcanzado, tenemos una base de datos común que almacenará todas las transacciones con contratos estrictamente definidos, en lugar de consultas condicionales cuyos formatos cambian a menudo y no tienen una especificación abierta. Aquí, las transacciones contendrán instrucciones para la ejecución del contrato de acuerdo con una especificación estricta. Esta especificación es abierta y, por lo tanto, los propios usuarios de la plataforma pueden auditar y validar los contratos inteligentes. Aquí vemos que las plataformas descentralizadas superan a las centralizadas en términos de independencia y resiliencia, pero su diseño y mantenimiento son mucho más complicados.
Contratos inteligentes según el método de asignación y ejecución de condiciones
Ahora analicemos más a fondo cómo pueden diferir los contratos inteligentes en el método de asignación y ejecución de condiciones. Aquí nos enfocaremos en contratos inteligentes que son arbitrariamente programables y completos según Turing. Un contrato inteligente completo según Turing permite establecer prácticamente cualquier algoritmo como condición de ejecución del contrato: escribir bucles, realizar funciones de cálculo de probabilidades, etc., e incluso crear sus propios algoritmos de firma electrónica. En este caso, se refiere a la escritura realmente arbitraria de la lógica.
También se destacan contratos inteligentes arbitrarios, pero no completos según Turing. Esto incluye Bitcoin y Litecoin con su script. Se refiere a que se pueden usar solo ciertas operaciones en un orden arbitrario, pero no se pueden escribir bucles ni algoritmos propios.
Además, hay plataformas de contratos inteligentes que implementan contratos predefinidos. Entre ellas se encuentran Bitshares y Steemit. Bitshares cuenta con una serie de contratos inteligentes para el comercio, la gestión de cuentas, la administración de la propia plataforma y sus parámetros. Steemit es una plataforma similar, pero está más enfocada en la creación de contenido y blogs, es decir, almacena y procesa contenido de manera descentralizada.
Plataformas de contratos completamente Turing-completos incluyen Ethereum y RootStock, que aún se encuentra en desarrollo. Por ello, a continuación nos detendremos un poco más en la plataforma de contratos inteligentes Ethereum.
Contratos inteligentes por método de iniciación
Según el método de iniciación, los contratos inteligentes se pueden dividir al menos en dos grupos: automatizados y manuales (no automatizados). Los automatizados son aquellos que, con todos los parámetros conocidos y condiciones establecidas, se ejecutan completamente de manera automática, es decir, no requieren el envío de transacciones adicionales ni el gasto de comisiones extras en cada ejecución posterior. La propia plataforma tiene todos los datos para calcular cómo finalizará el contrato inteligente. La lógica no es arbitraria, sino previamente establecida y todo es predecible. Es decir, se puede evaluar de antemano la complejidad de la ejecución del contrato inteligente, utilizar una comisión constante para él y todos los procesos de su ejecución se llevan a cabo de manera más eficiente.
Para los contratos inteligentes que se programan de manera arbitraria, la ejecución no es automatizada. Para iniciar dicho contrato inteligente, se requiere crear una nueva transacción en cada paso, que llamará a la siguiente etapa de ejecución o al siguiente método del contrato inteligente, pagar la comisión correspondiente y esperar la confirmación de la transacción. La ejecución puede finalizar con éxito o no, ya que el código del contrato inteligente es arbitrario y pueden surgir momentos impredecibles, como un bucle infinito, la falta de algunos parámetros y argumentos, excepciones no manejadas, etc.
Cuentas en Ethereum
Tipos de cuentas en Ethereum
Veamos qué tipos de cuentas pueden existir en la plataforma Ethereum. Solo hay dos tipos de cuentas y no hay más opciones. El primer tipo se llama cuenta de usuario, y el segundo, cuenta de contrato. Analicemos en qué se diferencian.
La cuenta de usuario se gestiona únicamente con la clave privada de la firma electrónica. El propietario de la cuenta genera su par de claves para la firma electrónica utilizando el algoritmo ECDSA (Eliptic Curve Digital Signature Algorithm). Solo las transacciones firmadas con esta clave pueden alterar el estado de la cuenta.
La cuenta de contrato inteligente tiene una lógica distinta. Puede ser controlada solo mediante un código programático predefinido que define completamente el comportamiento del contrato inteligente: cómo dispondrá de sus monedas en ciertas circunstancias, por iniciativa de qué usuario y en qué condiciones adicionales se distribuirán esas monedas. Si ciertos aspectos no están previstos por los desarrolladores en el código programático, pueden surgir problemas. Por ejemplo, un contrato inteligente puede alcanzar un estado específico, en el cual no acepta la iniciación de further executions from any users. En tal caso, las monedas estarán en efecto congeladas, ya que el contrato inteligente no prevé una salida de este estado.
Cómo se crean cuentas en Ethereum
En el caso de la cuenta de usuario, el propietario genera por sí mismo un par de claves usando ECDSA. Es importante señalar que Ethereum utiliza para la firma electrónica el mismo algoritmo y la misma curva elíptica que Bitcoin, pero la dirección se calcula de manera ligeramente diferente. Aquí ya no se aplica el resultado del doble hash, como en Bitcoin, sino que se hace un hash único con la función Keccak de 256 bits. Se eliminan los bits menos significativos, es decir, los 160 bits menos significativos del valor de salida de la función hash. Como resultado, obtenemos una dirección en Ethereum, que ocupa 20 bytes.
Cabe destacar que el identificador de la cuenta en Ethereum se codifica en hex sin aplicar una suma de verificación, a diferencia de Bitcoin y muchos otros sistemas, donde la dirección se codifica en un sistema de numeración en base 58 con la adición de una suma de verificación. Esto significa que se debe tener cuidado al trabajar con identificadores de cuentas en Ethereum: incluso un error en el identificador garantizará la pérdida de monedas.
Hay una característica importante y es que la cuenta del usuario en la base de datos general se crea en el momento en que acepta el primer pago entrante.
En cuanto a la creación de una cuenta de contrato inteligente, se aplica un enfoque completamente diferente. Inicialmente, algún usuario escribe el código fuente del contrato inteligente, el cual luego se pasa a un compilador específico de la plataforma Ethereum, obteniendo el bytecode para su propia máquina virtual Ethereum. El bytecode resultante se coloca en un campo especial de la transacción. Esta se firma en nombre de la cuenta iniciadora. Luego, esta transacción se difunde por la red y despliega el código del contrato inteligente. La tarifa por realizar la transacción y, por lo tanto, por ejecutar el contrato se deduce del saldo de la cuenta iniciadora.
Cada contrato inteligente debe contener su propio constructor (de dicho contrato). Puede estar vacío o tener contenido. Después de que se ejecuta el constructor, se crea un identificador de cuenta del contrato inteligente, que se puede utilizar para enviar monedas, invocar ciertos métodos del contrato inteligente, etc.
Estructura de la transacción de Ethereum
Para que sea más claro, procederemos a revisar la estructura de la transacción de Ethereum y un ejemplo de código de contrato inteligente.

Una transacción de Ethereum consta de varios campos. El primero de ellos, nonce, es un número de secuencia de la transacción en relación con la propia cuenta que la difunde y es su autora. Esto es necesario para distinguir duplicados de transacciones, es decir, excluir el caso en que la misma transacción se acepta dos veces. Gracias a la aplicación del identificador, cada transacción tiene un valor hash único.
A continuación, se encuentra un campo como gas priceAquí se indica el precio al que la moneda base Ethereum se convierte en gas, que se utiliza para pagar la ejecución de contratos inteligentes y la asignación de recursos de la máquina virtual. ¿Qué significa esto?
En Bitcoin, las comisiones se pagan directamente en la moneda base — el propio bitcoin. Esto es posible gracias a un mecanismo simple de cálculo: pagamos estrictamente según el volumen de datos que contiene la transacción. En Ethereum, la situación es más compleja, porque es muy difícil partir del volumen de datos de la transacción. Aquí, la transacción también puede contener código programático que se ejecutará en la máquina virtual, y cada operación de la máquina virtual puede tener diferentes complejidades. También hay operaciones que asignan memoria para variables. Estas tendrán su propia complejidad, de la cual dependerá el pago por cada operación.
El costo de cada operación en equivalente a gas será constante. Se introduce precisamente para determinar el costo constante de cada operación. Según la carga en la red, cambiará el precio del gas, es decir, el coeficiente según el cual la moneda base se convertirá en esta unidad auxiliar para el pago de la comisión.
Hay otra particularidad de las transacciones en Ethereum: el bytecode que contiene para la ejecución en la máquina virtual se ejecutará hasta que termine con algún resultado (éxito-fracaso) o hasta que se gaste cierta cantidad de monedas asignadas para pagar la comisión. Es precisamente para evitar situaciones en las que todas las monedas del remitente se gasten en comisiones en caso de un error (por ejemplo, si se activa un ciclo infinito en la máquina virtual), que existe el siguiente campo — start gas (a menudo se le llama gas limit) — define la cantidad máxima de monedas que el remitente está dispuesto a gastar en la ejecución de una determinada transacción.
El siguiente campo se llama destination address. Aquí se escribe la dirección del destinatario de las monedas o la dirección de un contrato inteligente específico cuyos métodos serán llamados. Después de ello, sigue el campo value, donde se escribe la suma de monedas que se envían a la destination address.
A continuación, se encuentra un interesante campo llamado data, donde se inserta toda una estructura. No es un campo separado, sino toda una estructura en la que se define el código para la máquina virtual. Aquí se pueden colocar datos arbitrarios; para eso existen reglas específicas.
Y el último campo se llama firma. Al mismo tiempo, contiene tanto la firma electrónica del autor de esta transacción como la clave pública que se usará para verificar dicha firma. De la clave pública se puede obtener el identificador de la cuenta del remitente de esta transacción, es decir, identificar de manera única la cuenta del remitente en el sistema. En cuanto a la estructura de la transacción, hemos aclarado lo principal.
Ejemplo de código de contrato inteligente en Solidity
Ahora examinemos más de cerca el contrato inteligente más simple con un ejemplo.
contract Bank {
address owner;
mapping(address => uint) balances;
function Bank() {
owner = msg.sender;
}
function deposit() public payable {
balances[msg.sender] += msg.value;
}
function withdraw(uint amount) public {
if (balances[msg.sender] >= amount) {
balances[msg.sender] -= amount;
msg.sender.transfer(amount);
}
}
function getMyBalance() public view returns(uint) {
return balances[msg.sender];
}
function kill() public {
if (msg.sender == owner)
selfdestruct(owner);
}
}Arriba se presenta un código fuente simplificado que puede retener las monedas de los usuarios y devolverlas a pedido.
Entonces, hay un contrato inteligente Bank que realiza las siguientes funciones: acumula monedas en su saldo, es decir, al confirmar una transacción y desplegar este contrato inteligente, se crea una nueva cuenta que puede contener monedas en su saldo; recuerda a los usuarios y la distribución de monedas entre ellos; tiene varios métodos para gestionar los saldos, lo que significa que hay la posibilidad de recargar, retirar y verificar el saldo del usuario.
Vamos a recorrer cada línea del código fuente. En este contrato hay campos constantes. Uno de ellos, de tipo address, se llama owner. Aquí el contrato recuerda la dirección del usuario que creó este contrato inteligente. Luego, hay una estructura dinámica que guarda las correspondencias entre las direcciones de los usuarios y sus saldos.
Después de esto, sigue el método Bank — se llama igual que el contrato. Por lo tanto, es su constructor. Aquí se asigna a la variable owner la dirección de quien desplegó este contrato inteligente en la red. Esto es lo único que sucede en este constructor. Es decir, msg en este caso son exactamente los datos que se enviaron a la máquina virtual junto con la transacción que contiene todo el código de este contrato. Por lo tanto, msg.sender — es el autor de esta transacción que despliega este código. Él será el propietario del contrato inteligente.
El método deposit permite transferir mediante una transacción una cierta cantidad de monedas a la cuenta del contrato. En este caso, el smart contract, al recibir estas monedas, las mantiene en su saldo, pero registra en la estructura balances quién fue el remitente de estas monedas, para saber a quién pertenecen.
El siguiente método se llama withdraw y acepta un parámetro: la cantidad de monedas que alguien quiere retirar de este banco. Aquí se verifica si hay suficientes monedas en el saldo del usuario que llama a este método para enviarlas. Si las hay, entonces el smart contract devuelve esa cantidad de monedas al que lo ha invocado.
A continuación, está el método que verifica el saldo actual del usuario. Quien llama a este método se usará para obtener este saldo en el smart contract. Cabe destacar que el modificador de este método es view. Esto significa que el método no cambia en absoluto las variables de su clase y en realidad es solo un método de lectura. No se crea una transacción separada para invocar este método, no se paga comisión y todos los cálculos se realizan localmente, tras lo cual el usuario recibe el resultado.
El método kill es necesario para destruir el estado del smart contract. Además, aquí se establece una verificación adicional, para asegurar si el que invoca este método es el propietario del contrato. Si lo es, entonces el contrato se autodestruye, y la función de destrucción toma un parámetro: el identificador de la cuenta a la que el contrato enviará todas las monedas restantes en su saldo. En este caso, las monedas restantes se enviarán automáticamente a la dirección del propietario del contrato.
¿Cómo funciona un nodo completo de la red Ethereum?
Veamos esquemáticamente cómo se lleva a cabo la ejecución de tales smart contracts en la plataforma Ethereum y cómo funciona un nodo completo de la red.

Un nodo completo de la red Ethereum debe tener al menos cuatro módulos.
El primero, como en cualquier protocolo descentralizado, es el módulo de P2P networking — el módulo de conexión de red y trabajo con otros nodos, donde se intercambian bloques, transacciones e información sobre otros nodos. Este es un componente tradicional para todas las criptomonedas descentralizadas.
A continuación, tenemos un módulo de almacenamiento de datos de blockchain, procesamiento, selección de la rama prioritaria, adición de bloques, desvinculación de bloques, verificación de estos bloques, etc.
El tercer módulo se llama EVM (máquina virtual de Ethereum) — y es esto máquina virtual, que acepta bytecode de la transacción de Ethereum. Este módulo toma el estado actual de una cuenta determinada y realiza cambios en su estado basándose en el bytecode recibido. La versión de la máquina virtual en cada uno de los nodos de la red debe ser la misma. Los cálculos que se realizan en cada uno de los nodos de Ethereum son absolutamente idénticos, pero se llevan a cabo de manera asíncrona: alguien verifica y acepta esta transacción antes, es decir, ejecuta todo el código que contiene, y alguien lo hace después. Por consiguiente, al crear una transacción, esta se difunde en la red, los nodos la aceptan y, en el momento de la verificación, de la misma manera que en Bitcoin se ejecuta el Bitcoin Script, aquí se ejecuta el bytecode de la máquina virtual.
Una transacción se considera verificada si todo el código que contiene ha sido ejecutado, se ha generado un nuevo estado de una cuenta determinada y se ha guardado hasta que esté claro si esta transacción se ha aplicado o no. Si la transacción se ha aplicado, entonces este estado se considera no sólo ejecutado, sino ya también actual. Hay una base de datos que almacena el estado de cada cuenta para cada nodo de la red. Debido a que todos los cálculos se llevan a cabo de la misma manera y el estado de la blockchain es el mismo, la base de datos que contiene los estados de todas las cuentas también será idéntica para cada nodo.
Mitos y limitaciones de los contratos inteligentes
En lo que respecta a las limitaciones que existen para plataformas de contratos inteligentes similares a Ethereum, se pueden mencionar las siguientes:
- ejecución de código;
- asignar memoria;
- datos de blockchain;
- enviar pagos;
- crear un nuevo contrato;
- llamar a otros contratos.
Examinemos las limitaciones impuestas a la máquina virtual y, por lo tanto, disipemos algunos mitos sobre los contratos inteligentes. En la máquina virtual, que puede estar en Ethereum y en plataformas similares, se pueden realizar operaciones lógicas realmente arbitrarias, es decir, se puede escribir código y este se ejecutará allá, pudiendo además asignar memoria. Sin embargo, se paga una comisión por separado por cada operación y por cada unidad adicional de memoria asignada.
Además, la máquina virtual puede leer datos de la base de datos de la blockchain, para utilizar esos datos como desencadenadores para la lógica de los contratos inteligentes. La máquina virtual puede crear y enviar transacciones, puede crear nuevos contratos y llamar a métodos de otros contratos inteligentes que ya están publicados en la red: existen, son accesibles, etc.
El mito más común es que los contratos inteligentes de Ethereum pueden utilizar información de cualquier recurso en Internet en sus condiciones. La realidad es que la máquina virtual no puede enviar una solicitud a una fuente de información externa en Internet, es decir, no se puede crear un contrato inteligente que distribuya valor entre los usuarios dependiendo de, por ejemplo, cómo esté el clima afuera, o quién ganó en un campeonato, o basándose en cualquier otro incidente que suceda en el mundo exterior, porque la información sobre esos incidentes simplemente no existe en la base de datos de la plataforma en sí. Es decir, en la blockchain no hay nada sobre esto. Si no aparece allí, entonces la máquina virtual no puede usar esos datos como desencadenadores.
Desventajas de Ethereum
Enumeremos los principales. La primera desventaja es que existen algunas dificultades en el diseño, desarrollo y prueba de contratos inteligentes en Ethereum (en Ethereum, se utiliza el lenguaje Solidity para escribir contratos inteligentes). De hecho, las estadísticas muestran que un porcentaje muy alto de todos los errores se debe al factor humano. Esto es especialmente relevante para los contratos inteligentes ya escritos en Ethereum, que tienen una complejidad media o superior. Si la probabilidad de error es baja en contratos simples, en los contratos inteligentes complejos es muy común encontrar errores que pueden resultar en el robo de fondos, su congelación, la destrucción de contratos inteligentes de manera imprevista, entre otros. Ya se conocen muchos de esos casos.
La segunda desventaja es que la propia máquina virtual no es perfecta, ya que también está escrita por personas. Puede ejecutar comandos arbitrarios y aquí radica la vulnerabilidad: se pueden configurar de manera específica una serie de comandos que conducirán a consecuencias imprevistas. Este es un campo muy complejo, pero ya existen varios estudios que demuestran que estas vulnerabilidades están presentes en la versión actual de la red Ethereum y pueden ocasionar la falla de muchos contratos inteligentes.
Otra gran dificultad, que se puede considerar una desventaja, es que es posible, de manera práctica o técnica, llegar a la conclusión de que, si se compila el bytecode del contrato que se ejecutará en la máquina virtual, se puede definir un cierto orden específico de operaciones. Al ejecutarse en conjunto, estas operaciones sobrecargarán enormemente la máquina virtual y la ralentizarán de manera desproporcionada en relación con la comisión que se pagó por la ejecución de estas operaciones.
En el pasado, ya hubo un período de desarrollo de Ethereum en el que muchos chicos, que conocían a fondo el funcionamiento de la máquina virtual, encontraban vulnerabilidades. De hecho, las transacciones pagaban comisiones muy bajas, pero casi ralentizaban el funcionamiento de toda la red. Estos problemas son muy difíciles de resolver, ya que es necesario, en primer lugar, determinarlos, en segundo lugar, ajustar el precio para la realización de estas operaciones y, en tercer lugar, llevar a cabo un hard fork, lo que significa actualizar todos los nodos de la red a una nueva versión del software y luego activar simultáneamente estos cambios.
En cuanto a Ethereum, se han realizado muchas investigaciones y se ha obtenido una gran cantidad de experiencia práctica: tanto positiva como negativa, pero, sin embargo, todavía quedan complejidades y vulnerabilidades que se deben enfrentar de alguna manera.
Así que hemos terminado la parte temática del artículo, pasemos a las preguntas que surgen con bastante frecuencia.
Preguntas frecuentes
— Si todas las partes de un contrato inteligente en funcionamiento quieren cambiar los términos, ¿pueden cancelar este contrato inteligente mediante una multipfirma y luego crear un nuevo contrato inteligente con los términos actualizados para su ejecución?
Aquí la respuesta será ambigua. ¿Por qué? Porque, por un lado, el contrato inteligente se establece una vez y no implica cambios, pero, por otro lado, puede tener una lógica predefinida que prevé la modificación total o parcial de algunos términos. Es decir, si deseas cambiar algo en tu contrato inteligente, debes especificar de antemano las condiciones bajo las cuales puedes actualizar esos términos. Por lo tanto, solo de esta manera previsora se puede organizar la actualización del contrato. Pero también aquí se pueden presentar problemas: cometer un error y obtener la correspondiente vulnerabilidad. Por eso, estas cosas deben ser diseñadas y probadas con mucho detalle y cuidado.
— ¿Y si el mediador se colude con una de las partes participantes: escrow o contrato inteligente? ¿Es obligatorio un mediador en un contrato inteligente?
Un mediador no es obligatorio en un contrato inteligente. Puede no estar presente. Si en el caso de un escrow el mediador conspira con una de las partes, entonces sí, este esquema pierde rápidamente todo su valor. Por eso, los mediadores se eligen de tal manera que todas las partes involucradas en este proceso confían en ellos. En consecuencia, simplemente no transferirás monedas a una dirección multisignature con ese mediador en el que no confías.
— ¿Es posible transferir muchos tokens diferentes en una sola transacción de Ethereum desde tu dirección a diferentes direcciones de destino, como las direcciones de intercambio donde se comercian esos tokens?
Esta es una buena pregunta y se refiere al modelo de transacciones de Ethereum y su diferencia con el modelo de Bitcoin. Y esa diferencia es radical. En el modelo de transacciones de Ethereum, simplemente transferirás monedas, y se transfieren solo de una dirección a otra, sin cambio, solo una cantidad específica que indiques. En otras palabras, no es un modelo de salidas no gastadas (UTXO), sino un modelo de cuentas y balances correspondientes. Teóricamente, se puede enviar varios tokens diferentes en una sola transacción si escribes un contrato inteligente ingenioso, pero aún así tendrás que hacer muchas transacciones, crear el contrato, luego transferirle tokens y monedas, y luego invocar el método correspondiente. Esto requiere esfuerzo y tiempo, por lo que en la práctica no funciona así y todos los pagos en Ethereum se realizan en transacciones separadas.
— Uno de los mitos sobre la plataforma Ethereum es que es imposible describir condiciones que dependan de datos de un recurso externo de internet, ¿cómo se hace entonces?
La solución es que el propio contrato inteligente puede prever uno o varios llamados oráculos de confianza, que recogen datos sobre el estado de las cosas en el mundo exterior y los transmiten a los contratos inteligentes a través de métodos especiales. El contrato mismo considera como verdad los datos que recibe de las partes de confianza. Para mayor fiabilidad, simplemente se elige un grupo más grande de oráculos y se minimiza el riesgo de conspiración. El contrato mismo puede no tener en cuenta los datos de oráculos que contradicen a la mayoría.
Este tema está dedicado a una de las conferencias del curso en línea sobre Blockchain — “”.
Fuente: habr.com
