Ethereum: Plataforma de Contratos Inteligentes y Aplicaciones Descentralizadas de Próxima Generación
Abstract
Satoshi Nakamoto's development of Bitcoin in 2009 has often been hailed as a radical development in money and currency, being the first example of a digital asset which simultaneously has no backing or intrinsic value and no centralized issuer or controller. However, another, arguably more important, part of the Bitcoin experiment is the underlying blockchain technology as a tool of distributed consensus, and attention is rapidly starting to shift to this other aspect of Bitcoin. Commonly cited alternative applications of blockchain technology include using on-blockchain digital assets to represent custom currencies and financial instruments (colored coins), the ownership of an underlying physical device (smart property), non-fungible assets such as domain names (Namecoin), as well as more complex applications involving having digital assets being directly controlled by a piece of code implementing arbitrary rules (smart contracts) or even blockchain-based decentralized autonomous organizations (DAOs).
What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create "contracts" that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code. A bare-bones version of Namecoin can be written in two lines of code, and other protocols like currencies and reputation systems can be built in under twenty lines. Smart contracts, cryptographic "boxes" that contain value and only unlock it if certain conditions are met, can also be built on top of the platform, with vastly more power than that offered by Bitcoin scripting because of the added powers of Turing-completeness, value-awareness, blockchain-awareness, and state.
Abstract
Ethereum es una plataforma de criptomonedas y aplicaciones descentralizadas de nueva generacion que introduce una blockchain con un lenguaje de programacion Turing-completo incorporado. Esto permite a cualquier persona escribir smart contracts y aplicaciones descentralizadas donde pueden crear sus propias reglas arbitrarias para la propiedad, los formatos de transaccion y las funciones de transicion de estado.
La innovacion fundamental de Ethereum es combinar la tecnologia blockchain pionera de Bitcoin con un entorno de programacion de proposito general. Mientras que Bitcoin proporciona un sistema simple de transicion de estado para mover moneda de una cuenta a otra, Ethereum proporciona una plataforma donde los desarrolladores pueden construir cualquier tipo de aplicacion descentralizada que puedan imaginar, desde monedas alternativas e instrumentos financieros hasta sistemas de registro de dominios y organizaciones descentralizadas.
Ethereum logra esto construyendo lo que es esencialmente la capa fundacional abstracta definitiva: una blockchain con un lenguaje de programacion Turing-completo incorporado, que permite a cualquier persona escribir smart contracts y aplicaciones descentralizadas donde pueden crear sus propias reglas arbitrarias para la propiedad, los formatos de transaccion y las funciones de transicion de estado. Una version basica de Namecoin puede escribirse en dos lineas de codigo, y otros protocolos como monedas y sistemas de reputacion pueden construirse en menos de veinte.
Introduction and Existing Concepts
The concept of decentralized digital currency, as well as alternative applications like property registries, has been around for decades. The anonymous e-cash protocols of the 1980s and the 1990s, mostly reliant on a cryptographic primitive known as Chaumian blinding, provided a currency with a high degree of privacy, but the protocols largely failed to gain traction because of their reliance on a centralized intermediary. In 1998, Wei Dai's b-money became the first proposal to introduce the idea of creating money through solving computational puzzles as well as decentralized consensus, but the proposal was scant on details as to how decentralized consensus could actually be implemented. In 2005, Hal Finney introduced a concept of reusable proofs of work, a system which uses ideas from b-money together with Adam Back's computationally difficult Hashcash puzzles to create a concept for a cryptocurrency, but once again fell short of the ideal by relying on trusted computing as a backend.
In 2009, a decentralized currency was for the first time implemented in practice by Satoshi Nakamoto, combining established primitives for managing ownership through public key cryptography with a consensus algorithm for keeping track of who owns coins, known as "proof of work." The mechanism behind proof of work was a breakthrough in the space because it simultaneously solved two problems. First, it provided a simple and moderately effective consensus algorithm, allowing nodes in the network to collectively agree on a set of canonical updates to the state of the Bitcoin ledger. Second, it provided a mechanism for allowing free entry into the consensus process, solving the political problem of deciding who gets to influence the consensus, while simultaneously preventing sybil attacks. It does this by substituting a formal barrier to participation, such as the requirement to be registered as a unique entity on a particular list, with an economic barrier -- the weight of a single node in the consensus voting process is directly proportional to the computing power that the node brings. Since then, an alternative approach has been proposed called proof of stake, calculating the weight of a node as being proportional to its currency holdings and not computational resources; the discussion of the relative merits of the two approaches is beyond the scope of this paper but it should be noted that both approaches can be used to serve as the backbone of a cryptocurrency.
The Bitcoin blockchain has proven remarkably robust in practice over the subsequent years of operation, but it is inherently limited in what it can accomplish beyond simple value transfer. Bitcoin's scripting language is intentionally designed to be restrictive, lacking loops, Turing-completeness, and many other features that would be necessary to build more complex applications. This limitation, while providing safety from certain classes of attacks, severely restricts what can be built on top of Bitcoin. Over the following years, numerous attempts to extend Bitcoin's functionality emerged: colored coins sought to use the Bitcoin blockchain to track ownership of alternative assets, Namecoin attempted to create a decentralized name registration database, and various metacoin protocols aimed to build additional layers on top of Bitcoin's transaction format. While these approaches showed promise, they were ultimately constrained by Bitcoin's scripting capabilities and the inability to access blockchain data from within scripts.
What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create "contracts" that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code.
Introduction and Existing Concepts
El concepto de moneda digital descentralizada, asi como aplicaciones alternativas como registros de propiedad, existe desde hace decadas. Los protocolos anonimos de dinero electronico de las decadas de 1980 y 1990, en su mayoria dependientes de una primitiva criptografica conocida como cegamiento de Chaum, proporcionaban una moneda con un alto grado de privacidad, pero los protocolos en gran medida no lograron ganar traccion debido a su dependencia de un intermediario centralizado. En 1998, el b-money de Wei Dai se convirtio en la primera propuesta en introducir la idea de crear dinero mediante la resolucion de rompecabezas computacionales asi como el consenso descentralizado, pero la propuesta era escasa en detalles sobre como el consenso descentralizado podria realmente implementarse.
En 2009, una moneda descentralizada fue implementada en la practica por primera vez por Satoshi Nakamoto, combinando primitivas establecidas para gestionar la propiedad a traves de criptografia de clave publica con un algoritmo de consenso para rastrear quien posee las monedas, conocido como "proof of work". El mecanismo detras del proof of work fue un avance en el campo porque resolvio simultaneamente dos problemas. Primero, proporciono un algoritmo de consenso simple y moderadamente efectivo, permitiendo a los nodos de la red acordar colectivamente un conjunto de actualizaciones canonicas al estado del libro mayor de Bitcoin. Segundo, proporciono un mecanismo para permitir la entrada libre al proceso de consenso, resolviendo el problema politico de decidir quien puede influir en el consenso, mientras simultaneamente prevenia ataques sybil.
La blockchain de Bitcoin ha demostrado ser notablemente robusta a lo largo de sus anos de operacion, pero es inherentemente limitada. El lenguaje de scripting de Bitcoin esta intencionalmente disenado para ser restrictivo y no Turing-completo, careciendo de bucles y muchas otras caracteristicas que serian necesarias para construir aplicaciones mas complejas. Esta limitacion existe para prevenir bucles infinitos y otras formas de ataques computacionales, pero restringe severamente lo que puede construirse sobre Bitcoin.
Durante los ultimos cinco anos, ha habido varios intentos de extender la funcionalidad de Bitcoin. Los colored coins buscaron usar la blockchain de Bitcoin para rastrear la propiedad de activos alternativos, Namecoin intento crear una base de datos descentralizada de registro de nombres, y varios protocolos metacoin buscaron construir capas adicionales sobre Bitcoin. Aunque estos enfoques mostraron promesa, finalmente estaban limitados por las capacidades de scripting de Bitcoin y la incapacidad de acceder a datos de la blockchain desde dentro de los scripts.
Lo que Ethereum pretende proporcionar es una blockchain con un lenguaje de programacion Turing-completo completamente desarrollado que puede usarse para crear "contratos" que pueden usarse para codificar funciones de transicion de estado arbitrarias, permitiendo a los usuarios crear cualquiera de los sistemas descritos anteriormente, asi como muchos otros que aun no hemos imaginado, simplemente escribiendo la logica en unas pocas lineas de codigo.
Bitcoin As A State Transition System
From a technical standpoint, the ledger of a cryptocurrency such as Bitcoin can be thought of as a state transition system, where there is a "state" consisting of the ownership status of all existing bitcoins and a "state transition function" that takes a state and a transaction and outputs a new state which is the result. In a standard banking system, for example, the state is a balance sheet, a transaction is a request to move \(X from A to B, and the state transition function reduces the value in A's account by \)X and increases the value in B's account by \(X. If A's account has less than \)X in the first place, the state transition function returns an error. Hence, one can formally define:
APPLY(S,TX) - S' or ERROR
In the banking system defined above:
APPLY({ Alice: \(50, Bob: \)50 },send \(20 from Alice to Bob") = { Alice: \)30, Bob: $70 }
But:
APPLY({ Alice: \(50, Bob: \)50 },send $70 from Alice to Bob) = ERROR
The "state" in Bitcoin is the collection of all coins (technically, "unspent transaction outputs" or UTXO) that have been minted and not yet spent, with each UTXO having a denomination and an owner (defined by a 20-byte address which is essentially a cryptographic public key). A transaction contains one or more inputs, with each input containing a reference to an existing UTXO and a cryptographic signature produced by the private key associated with the owner's address, and one or more outputs, with each output containing a new UTXO to be added to the state.
The state transition function APPLY(S,TX) - S' can be defined roughly as follows:
- For each input in TX:
- If the referenced UTXO is not in S, return an error.
- If the provided signature does not match the owner of the UTXO, return an error.
- If the sum of the denominations of all input UTXO is less than the sum of the denominations of all output UTXO, return an error.
- Return S with all input UTXO removed and all output UTXO added.
The first half of the first step prevents transaction senders from spending coins that do not exist, the second half of the first step prevents transaction senders from spending other people's coins, and the second step enforces conservation of value. In order to use this for payment, the protocol is as follows. Suppose Alice wants to send 11.7 BTC to Bob. First, Alice will look for a set of available UTXO that she owns that totals up to at least 11.7 BTC. Realistically, Alice will not be able to get exactly 11.7 BTC; say that the smallest she can get is 6+4+2=12. She then creates a transaction with those three inputs and two outputs. The first output will be 11.7 BTC with Bob's address as its owner, and the second output will be the remaining 0.3 BTC "change", with the owner being Alice herself.
Bitcoin As A State Transition System
Desde un punto de vista tecnico, el libro mayor de una criptomoneda como Bitcoin puede considerarse como un sistema de transicion de estado, donde hay un "estado" que consiste en el estatus de propiedad de todos los bitcoins existentes y una "funcion de transicion de estado" que toma un estado y una transaccion y produce un nuevo estado que es el resultado. En un sistema bancario estandar, por ejemplo, el estado es un balance general, una transaccion es una solicitud para mover \(X de A a B, y la funcion de transicion de estado reduce el valor en la cuenta de A en \)X y aumenta el valor en la cuenta de B en \(X. Si la cuenta de A tiene menos de \)X en primer lugar, la funcion de transicion de estado devuelve un error.
El "estado" en Bitcoin es la coleccion de todas las monedas (tecnicamente, "salidas de transaccion no gastadas" o UTXO) que han sido acunadas y aun no gastadas, donde cada UTXO tiene una denominacion y un propietario (definido por una direccion de 20 bytes que es esencialmente una clave publica criptografica). Una transaccion contiene una o mas entradas, donde cada entrada contiene una referencia a un UTXO existente y una firma criptografica producida por la clave privada asociada con la direccion del propietario, y una o mas salidas, donde cada salida contiene un nuevo UTXO para ser anadido al estado.
La funcion de transicion de estado APPLY(S,TX) - S' puede definirse aproximadamente de la siguiente manera:
- Para cada entrada en TX, si el UTXO referenciado no esta en S, devolver un error.
- Si la firma proporcionada no coincide con el propietario del UTXO, devolver un error.
- Si la suma de las denominaciones de todos los UTXO de entrada es menor que la suma de las denominaciones de todos los UTXO de salida, devolver un error.
- Devolver S con todos los UTXO de entrada eliminados y todos los UTXO de salida anadidos.
La primera mitad del primer paso previene que los remitentes de transacciones gasten monedas que no existen, la segunda mitad del primer paso previene que los remitentes gasten monedas de otras personas, y el segundo paso asegura la conservacion de valor. Para usar esto para pagos, el protocolo es el siguiente: supongamos que Alice quiere enviar 11.7 BTC a Bob. Primero, Alice buscara un conjunto de UTXO disponibles que posee y que sumen al menos 11.7 BTC. De manera realista, Alice no podra obtener exactamente 11.7 BTC; digamos que lo minimo que puede obtener es 6+4+2=12. Entonces crea una transaccion con esas tres entradas y dos salidas. La primera salida sera 11.7 BTC con la direccion de Bob como propietario, y la segunda salida sera el "cambio" restante de 0.3 BTC, siendo la propietaria la propia Alice.
Mining
If we had access to a trustworthy centralized service, this system would be trivial to implement; it could simply be coded exactly as described, using a centralized server's hard drive to keep track of the state. However, with Bitcoin we are trying to build a decentralized currency system, so we will need to combine the state transaction system with a consensus system in order to ensure that everyone agrees on the order of transactions. Bitcoin's decentralized consensus process requires nodes in the network to continuously attempt to produce packages of transactions called "blocks." The network is intended to produce roughly one block every ten minutes, with each block containing a timestamp, a nonce, a reference to (i.e. hash of) the previous block and a list of all of the transactions that have taken place since the previous block. Over time, this creates a persistent, ever-growing, "blockchain" that constantly updates to represent the latest state of the Bitcoin ledger.
The algorithm for checking if a block is valid, expressed in this paradigm, is as follows:
- Check if the previous block referenced by the block exists and is valid.
- Check that the timestamp of the block is greater than that of the previous block and less than 2 hours into the future.
- Check that the proof of work on the block is valid.
- Let
S[0]be the state at the end of the previous block. - Suppose TX is the block's transaction list with n transactions. For all i in 0...n-1, set
S[i+1] = APPLY(S[i],TX[i]). If any application returns an error, exit and return false. - Return true, and register
S[n]as the state at the end of this block.
Essentially, each transaction in the block must provide a valid state transition from what was the canonical state before the transaction was executed to some new state. Note that the state is not encoded in the block in any way; it is purely an abstraction to be remembered by the validating node and can only be (securely) computed for any block by starting from the genesis state and sequentially applying every transaction in every block. Additionally, note that the order in which the miner includes transactions into the block matters; if there are two transactions A and B in a block such that B spends a UTXO created by A, then the block will be valid if A comes before B but not otherwise.
The one validity condition present in the above list that is not found in other systems is the requirement for "proof of work." The precise condition is that the double-SHA256 hash of every block, treated as a 256-bit number, must be less than a dynamically adjusted target, which as of the time of this writing is approximately \(2^{187}\). The purpose of this is to make block creation computationally "hard," thereby preventing sybil attackers from remaking the entire blockchain in their favor. Because SHA256 is designed to be a completely unpredictable pseudorandom function, the only way to create a valid block is simply trial and error, repeatedly incrementing the nonce and seeing if the new hash matches.
At the current target of \(\sim 2^{187}\), the network must make an average of \(\sim 2^{69}\) tries before a valid block is found; in general, the target is recalibrated by the network every 2016 blocks so that on average a new block is produced by some node in the network every ten minutes. In order to compensate miners for this computational work, the miner of every block is entitled to include a transaction giving themselves 25 BTC out of nowhere. Additionally, if any transaction has a higher total denomination in its inputs than in its outputs, the difference also goes to the miner as a "transaction fee." Incidentally, this is also the only mechanism by which BTC are issued; the genesis state contained no coins at all.
In order to better understand the purpose of mining, let us examine what happens in the event of a malicious attacker. Since Bitcoin's underlying cryptography is known to be secure, the attacker will target the one part of the Bitcoin system that is not protected by cryptography directly: the order of transactions. The attacker's strategy is simple:
- Send 100 BTC to a merchant in exchange for some product (preferably a rapid-delivery digital good).
- Wait for the delivery of the product.
- Produce another transaction sending the same 100 BTC to himself.
- Try to convince the network that his transaction to himself was the one that came first.
Once step (1) has taken place, after a few minutes some miner will include the transaction in a block, say block number 270000. After about one hour, five more blocks will have been added to the chain after that block, with each of those blocks indirectly pointing to the transaction and thus "confirming" it. At this point, the merchant will accept the payment as finalized and deliver the product. Since we are assuming this is a digital good, delivery is instant. Now, the attacker creates another transaction sending the 100 BTC to himself. If the attacker simply releases it into the wild, the transaction will not be processed; miners will attempt to run APPLY(S,TX) and notice that TX consumes a UTXO which is no longer in the state. So instead, the attacker creates a "fork" of the blockchain, starting by mining another version of block 270000 pointing to the same block 269999 as a parent but with the new transaction in place of the old one. Because the block data is different, this requires redoing the proof of work. Furthermore, the attacker's new version of block 270000 has a different hash, so the original blocks 270001 to 270005 do not "point" to it; thus, the original chain and the attacker's new chain are completely separate. The rule is that in a fork the longest blockchain is taken to be the truth, and so legitimate miners will work on the 270005 chain while the attacker alone is working on the 270000 chain. In order for the attacker to make his blockchain the longest, he would need to have more computational power than the rest of the network combined in order to catch up (hence, "51% attack").
Mining
Si tuvieramos acceso a un servicio centralizado confiable, este sistema seria trivial de implementar; simplemente podria codificarse exactamente como se describe, usando el disco duro de un servidor centralizado para rastrear el estado. Sin embargo, con Bitcoin estamos tratando de construir un sistema de moneda descentralizado, por lo que necesitaremos combinar el sistema de transicion de estado con un sistema de consenso para asegurar que todos esten de acuerdo en el orden de las transacciones. El proceso de consenso descentralizado de Bitcoin requiere que los nodos en la red intenten continuamente producir paquetes de transacciones llamados "bloques". La red esta disenada para producir aproximadamente un bloque cada diez minutos, con cada bloque conteniendo una marca de tiempo, un nonce, una referencia al (es decir, hash del) bloque anterior y una lista de todas las transacciones que han tenido lugar desde el bloque anterior.
Con el tiempo, esto crea una "blockchain" persistente y en constante crecimiento que se actualiza constantemente para representar el estado mas reciente del libro mayor de Bitcoin. El algoritmo para verificar si un bloque es valido, expresado en este paradigma, es el siguiente:
- Verificar si el bloque anterior referenciado por el bloque existe y es valido.
- Verificar que la marca de tiempo del bloque es mayor que la del bloque anterior y menor a 2 horas en el futuro.
- Verificar que el proof of work del bloque es valido.
- Sea S el estado al final del bloque anterior.
- Supongamos que TX es la lista de transacciones del bloque con n transacciones. Para todo i en 0...n-1, establecer S = APPLY(S,TX[i]). Si alguna aplicacion devuelve un error, salir y devolver falso.
- Devolver verdadero y registrar S como el estado al final de este bloque.
Esencialmente, cada transaccion en el bloque debe proporcionar una transicion de estado valida desde lo que era el estado canonico antes de que la transaccion se ejecutara hasta algun nuevo estado. Hay que notar que el estado no esta codificado en el bloque de ninguna manera; es puramente una abstraccion que debe ser recordada por el nodo validador y solo puede ser calculada (de forma segura) para cualquier bloque comenzando desde el estado genesis y aplicando secuencialmente cada transaccion en cada bloque.
El minero es recompensado por su trabajo computacional con bitcoins recien creados mas las comisiones de transaccion. El proceso de mineria funciona de la siguiente manera: los mineros toman la cabecera del bloque y la hashean repetidamente con diferentes valores de nonce hasta encontrar un hash que este por debajo de un cierto objetivo de dificultad. Cuando un minero encuentra dicho hash, transmite el bloque a la red, y otros nodos verifican que el hash es valido y que todas las transacciones en el bloque son validas. El objetivo de dificultad se ajusta automaticamente por el protocolo cada 2016 bloques (aproximadamente dos semanas) para asegurar que los bloques se produzcan a un ritmo aproximadamente constante.
Hay que notar que a largo plazo, la seguridad de la blockchain depende de que los mineros tengan un incentivo financiero para comportarse honestamente. Si un atacante controla mas del 50% del poder de mineria de la red, potencialmente podria ejecutar un "ataque del 51%" creando una blockchain alternativa que crezca mas rapido que la cadena honesta. Sin embargo, tal ataque requeriria enormes recursos computacionales y probablemente resultaria en que las recompensas de mineria del atacante perdieran su valor a medida que la red perdiera confianza en la integridad de la blockchain.
Merkle Trees
Merkle trees are a fundamental data structure used in Bitcoin blocks to enable efficient and secure verification of transaction inclusion. A Merkle tree is a binary tree of hashes where the leaf nodes contain hashes of individual transactions, and each interior node contains the hash of its two children, recursively building up to a single root hash that is stored in the block-header/" class="glossary-link" data-slug="block-header" title="block header">block header. This hierarchical structure allows anyone to verify that a specific transaction is included in a block by downloading only the Merkle branch—the chain of hashes from the transaction up to the root—rather than downloading all transactions in the block.
The efficiency gains are substantial: while a full Bitcoin node must store the entire blockchain (approximately 15GB as of 2013), a simplified payment verification (SPV) node only needs to download block headers containing Merkle roots, requiring just 4MB of data. To verify a transaction, an SPV node requests the Merkle branch from full nodes, which requires only \(O(\log n)\) data where \(n\) is the number of transactions in a block. This logarithmic scaling makes it feasible to run lightweight clients on mobile devices and low-resource environments.
Bitcoin's use of Merkle trees demonstrates a key principle: cryptographic structures can dramatically reduce the trust and resource requirements for participating in a decentralized network. This same principle underlies Ethereum's design, where Merkle trees are used not only for transactions but also for state and receipt storage, enabling even more sophisticated light client protocols.
Merkle Trees
Los Merkle trees son una estructura de datos fundamental utilizada en los bloques de Bitcoin para permitir la verificacion eficiente y segura de la inclusion de transacciones. Un Merkle tree es un arbol binario de hashes donde los nodos hoja contienen hashes de transacciones individuales, y cada nodo interior contiene el hash de sus dos hijos, construyendose recursivamente hasta un unico hash raiz que se almacena en la cabecera del bloque. Esta estructura jerarquica permite a cualquiera verificar que una transaccion especifica esta incluida en un bloque descargando solo la rama del Merkle tree, la cadena de hashes desde la transaccion hasta la raiz, en lugar de descargar todas las transacciones del bloque.
Las ganancias en eficiencia son sustanciales: mientras que un nodo completo de Bitcoin debe almacenar toda la blockchain (aproximadamente 15GB en 2013), un nodo de verificacion de pagos simplificada (SPV) solo necesita descargar las cabeceras de los bloques que contienen las raices del Merkle tree, requiriendo solo 4MB de datos. Para verificar una transaccion, un nodo SPV solicita la rama del Merkle tree a los nodos completos, lo que requiere solo O(log n) datos donde n es el numero de transacciones en un bloque. Esta escalabilidad logaritmica hace factible ejecutar clientes ligeros en dispositivos moviles y entornos con recursos limitados.
El uso de Merkle trees por parte de Bitcoin demuestra un principio clave: las estructuras criptograficas pueden reducir dramaticamente los requisitos de confianza y recursos para participar en una red descentralizada. Este mismo principio subyace en el diseno de Ethereum, donde los Merkle trees se utilizan no solo para transacciones sino tambien para el almacenamiento de estado y recibos, permitiendo protocolos de clientes ligeros aun mas sofisticados.
Alternative Blockchain Applications
The success of Bitcoin's blockchain inspired numerous attempts to extend the concept beyond simple currency. Namecoin, launched in 2010, was one of the earliest examples—a decentralized name registration database built on a blockchain, allowing users to register names in a distributed namespace that no central authority could censor or revoke. Colored coins emerged as a way to represent alternative assets on the Bitcoin blockchain by "tagging" specific transaction outputs to represent ownership of real-world assets, company shares, or other cryptocurrencies. Metacoins and meta-protocols like Mastercoin (later Omni) layered additional functionality on top of Bitcoin by encoding extra data in Bitcoin transactions and building separate protocol rules on top.
However, all these approaches suffered from fundamental limitations imposed by Bitcoin's architecture. The Bitcoin scripting language is intentionally restricted—it cannot access blockchain state, lacks loops and complex control flow, and provides limited introspection into transaction values. Building sophisticated applications required awkward workarounds: encoding metadata in transaction fields never intended for that purpose, relying on off-chain infrastructure for complex logic, or accepting severe limitations on what the protocol could accomplish.
These constraints motivated the search for a more general-purpose blockchain platform. Rather than building yet another special-purpose protocol on top of Bitcoin's limited foundation, Ethereum takes a different approach: providing a blockchain with a built-in Turing-complete programming language, allowing anyone to write smart contracts and decentralized applications with arbitrary rules for ownership, transaction formats, and state transition functions.
Alternative Blockchain Applications
El exito de la blockchain de Bitcoin inspiro numerosos intentos de extender el concepto mas alla de la simple moneda. Namecoin, lanzado en 2010, fue uno de los primeros ejemplos: una base de datos descentralizada de registro de nombres construida sobre una blockchain, que permitia a los usuarios registrar nombres en un espacio de nombres distribuido que ninguna autoridad central podia censurar o revocar. Los colored coins surgieron como una forma de representar activos alternativos en la blockchain de Bitcoin "etiquetando" salidas de transaccion especificas para representar la propiedad de activos del mundo real, acciones de empresas u otras criptomonedas. Los metacoins y metaprotocolos como Mastercoin (posteriormente Omni) anadieron funcionalidad adicional sobre Bitcoin codificando datos extra en las transacciones de Bitcoin y construyendo reglas de protocolo separadas encima.
Sin embargo, todos estos enfoques sufrian de limitaciones fundamentales impuestas por la arquitectura de Bitcoin. El lenguaje de scripting de Bitcoin esta intencionalmente restringido: no puede acceder al estado de la blockchain, carece de bucles y flujo de control complejo, y proporciona introspeccion limitada sobre los valores de las transacciones. Construir aplicaciones sofisticadas requeria soluciones alternativas incomodas: codificar metadatos en campos de transaccion que nunca fueron destinados para ese proposito, depender de infraestructura fuera de la cadena para logica compleja, o aceptar limitaciones severas en lo que el protocolo podia lograr.
Estas restricciones motivaron la busqueda de una plataforma blockchain de proposito mas general. En lugar de construir otro protocolo de proposito especial sobre la base limitada de Bitcoin, Ethereum toma un enfoque diferente: proporcionar una blockchain con un lenguaje de programacion Turing-completo incorporado, permitiendo a cualquier persona escribir smart contracts y aplicaciones descentralizadas con reglas arbitrarias para la propiedad, los formatos de transaccion y las funciones de transicion de estado.
Scripting
Bitcoin Script, the language used to define spending conditions for Bitcoin transactions, is intentionally designed with severe limitations. It is not Turing-complete—most notably, it lacks loops and complex control flow structures. The language operates as a simple stack-based execution environment where operations push and pop values, evaluate cryptographic conditions, and ultimately return true or false to determine whether a transaction is valid. While this simplicity provides security benefits and makes formal analysis easier, it also makes many types of applications impossible to implement.
These limitations fall into three main categories. First, the lack of Turing-completeness prevents implementing complex state machines, decision trees, or any algorithm requiring iteration. Second, value-blindness means that scripts cannot specify fine-grained control over withdrawal amounts—a UTXO can only be spent in its entirety, with change sent to a new output. A script cannot, for example, limit withdrawals to a maximum of X per day while leaving the remainder locked. Third, the lack of blockchain state awareness means that UTXO are either spent or unspent with no intermediate states, making multi-stage contracts impossible to implement purely on-chain.
These constraints make sophisticated applications like decentralized autonomous organizations, savings wallets with withdrawal limits, decentralized exchanges, or prediction markets either impossible or require awkward off-chain mechanisms. An advanced financial contract might require access to market data, the ability to maintain internal state across multiple transactions, and complex conditional logic—none of which Bitcoin Script can provide. Ethereum removes these limitations by providing a Turing-complete language with full access to blockchain state.
Scripting
Bitcoin Script, el lenguaje utilizado para definir las condiciones de gasto de las transacciones de Bitcoin, esta intencionalmente disenado con severas limitaciones. No es Turing-completo — notablemente, carece de bucles y estructuras complejas de flujo de control. El lenguaje opera como un entorno de ejecucion simple basado en pila donde las operaciones empujan y extraen valores, evaluan condiciones criptograficas y finalmente devuelven verdadero o falso para determinar si una transaccion es valida. Aunque esta simplicidad proporciona beneficios de seguridad y facilita el analisis formal, tambien hace imposible implementar muchos tipos de aplicaciones.
Estas limitaciones se dividen en tres categorias principales. Primero, la falta de completitud de Turing impide implementar maquinas de estado complejas, arboles de decision o cualquier algoritmo que requiera iteracion. Segundo, la ceguera de valor significa que los scripts no pueden especificar un control detallado sobre las cantidades de retiro — un UTXO solo puede gastarse en su totalidad, con el cambio enviado a una nueva salida. Un script no puede, por ejemplo, limitar los retiros a un maximo de X por dia mientras deja el resto bloqueado. Tercero, la falta de conciencia del estado de la blockchain significa que los UTXO estan gastados o no gastados sin estados intermedios, haciendo imposible implementar contratos de multiples etapas puramente en la cadena.
Estas restricciones hacen que aplicaciones sofisticadas como organizaciones autonomas descentralizadas, carteras de ahorro con limites de retiro, exchanges descentralizados o mercados de prediccion sean imposibles o requieran mecanismos incomodos fuera de la cadena. Un contrato financiero avanzado podria requerir acceso a datos del mercado, la capacidad de mantener un estado interno a traves de multiples transacciones y logica condicional compleja — nada de lo cual Bitcoin Script puede proporcionar. Ethereum elimina estas limitaciones proporcionando un lenguaje Turing-completo con acceso completo al estado de la blockchain.
Ethereum
Ethereum's fundamental goal is to provide a blockchain with a built-in Turing-complete programming language that allows anyone to write smart contracts and decentralized applications where they can create their own arbitrary rules for ownership, transaction formats, and state transition functions. Rather than designing a protocol for specific applications like currency, name registration, or asset trading, Ethereum provides a foundational layer—a blockchain-based distributed computing platform that developers can use to build any application they can imagine.
The architecture differs fundamentally from Bitcoin's UTXO model. Ethereum uses an account-based system where the blockchain state consists of a mapping from addresses to account objects. Each account has a balance, a transaction counter (nonce), and for contract accounts, associated code and storage. The platform includes a built-in Turing-complete programming language for writing contract code that executes in the Ethereum Virtual Machine (EVM), a stack-based execution environment that processes transactions and state transitions.
This generality enables a vast range of applications: alternative cryptocurrencies with custom issuance rules, financial derivatives and stablecoins, identity and reputation systems, decentralized file storage, decentralized autonomous organizations (DAOs), and much more. The whitepaper emphasizes that Ethereum is not optimized for any particular use case but instead provides the fundamental building blocks—accounts, transactions, a Turing-complete language, and gas-metered execution—that developers can combine to create whatever applications the ecosystem demands.
Ethereum
El objetivo fundamental de Ethereum es proporcionar una blockchain con un lenguaje de programacion Turing-completo incorporado que permita a cualquier persona escribir smart contracts y aplicaciones descentralizadas donde puedan crear sus propias reglas arbitrarias para la propiedad, los formatos de transaccion y las funciones de transicion de estado. En lugar de disenar un protocolo para aplicaciones especificas como moneda, registro de nombres o comercio de activos, Ethereum proporciona una capa fundacional: una plataforma de computacion distribuida basada en blockchain que los desarrolladores pueden usar para construir cualquier aplicacion que puedan imaginar.
La arquitectura difiere fundamentalmente del modelo UTXO de Bitcoin. Ethereum utiliza un sistema basado en cuentas donde el estado de la blockchain consiste en un mapeo de direcciones a objetos de cuenta. Cada cuenta tiene un saldo, un contador de transacciones (nonce), y para las cuentas de contrato, codigo asociado y almacenamiento. La plataforma incluye un lenguaje de programacion Turing-completo incorporado para escribir codigo de contrato que se ejecuta en la Maquina Virtual de Ethereum (EVM), un entorno de ejecucion basado en pila que procesa transacciones y transiciones de estado.
Esta generalidad permite una vasta gama de aplicaciones: criptomonedas alternativas con reglas de emision personalizadas, derivados financieros y stablecoins, sistemas de identidad y reputacion, almacenamiento de archivos descentralizado, organizaciones autonomas descentralizadas (DAOs), y mucho mas. El whitepaper enfatiza que Ethereum no esta optimizado para ningun caso de uso en particular, sino que proporciona los bloques de construccion fundamentales — cuentas, transacciones, un lenguaje Turing-completo y ejecucion medida por gas — que los desarrolladores pueden combinar para crear cualquier aplicacion que el ecosistema demande.
Ethereum Accounts
In Ethereum, the state is made up of accounts, and there are two fundamental types. Externally owned accounts (EOAs) are controlled by private keys and have no associated code—they represent human users or external entities interacting with the blockchain. Contract accounts are controlled by their contract code and are activated when they receive a message or transaction. Both types share a common structure: every account has a nonce (a counter used to ensure each transaction can only be processed once), an ether balance, and for contracts specifically, contract code and persistent storage.
Ether is the primary internal cryptocurrency of Ethereum, serving as both a medium of value transfer and the fundamental unit for paying transaction fees (gas). Unlike Bitcoin's UTXO model where value is distributed across multiple unspent outputs, Ethereum accounts maintain a simple balance that increases when they receive ether and decreases when they send it. This account-based model simplifies many types of applications, particularly those requiring persistent state or complex access control, though it introduces different security considerations compared to Bitcoin's approach.
The distinction between EOAs and contract accounts is crucial to understanding Ethereum's operation. EOAs can initiate transactions by creating and signing messages with their private keys, paying gas fees to have their transactions included in blocks. Contract accounts cannot initiate transactions themselves but can send messages to other contracts in response to receiving a transaction or message, enabling complex chains of execution where a single external transaction triggers multiple contract-to-contract interactions.
Ethereum Accounts
En Ethereum, el estado esta compuesto por cuentas, y hay dos tipos fundamentales. Las cuentas de propiedad externa (EOAs) estan controladas por claves privadas y no tienen codigo asociado — representan usuarios humanos o entidades externas que interactuan con la blockchain. Las cuentas de contrato estan controladas por su codigo de contrato y se activan cuando reciben un mensaje o transaccion. Ambos tipos comparten una estructura comun: cada cuenta tiene un nonce (un contador utilizado para asegurar que cada transaccion solo pueda procesarse una vez), un saldo de ether, y para los contratos especificamente, codigo de contrato y almacenamiento persistente.
Ether es la criptomoneda interna principal de Ethereum, sirviendo tanto como medio de transferencia de valor como la unidad fundamental para pagar comisiones de transaccion (gas). A diferencia del modelo UTXO de Bitcoin donde el valor esta distribuido entre multiples salidas no gastadas, las cuentas de Ethereum mantienen un saldo simple que aumenta cuando reciben ether y disminuye cuando lo envian. Este modelo basado en cuentas simplifica muchos tipos de aplicaciones, particularmente aquellas que requieren estado persistente o control de acceso complejo, aunque introduce diferentes consideraciones de seguridad comparado con el enfoque de Bitcoin.
La distincion entre EOAs y cuentas de contrato es crucial para entender el funcionamiento de Ethereum. Las EOAs pueden iniciar transacciones creando y firmando mensajes con sus claves privadas, pagando comisiones de gas para que sus transacciones sean incluidas en bloques. Las cuentas de contrato no pueden iniciar transacciones por si mismas, pero pueden enviar mensajes a otros contratos en respuesta a recibir una transaccion o mensaje, permitiendo cadenas complejas de ejecucion donde una unica transaccion externa desencadena multiples interacciones de contrato a contrato.
Messages and Transactions
Transactions in Ethereum are signed data packages created by externally owned accounts and broadcast to the network. A transaction contains the recipient address, a cryptographic signature proving the sender's identity, the amount of ether to transfer, an optional data field (crucial for interacting with contracts), STARTGAS (the maximum number of computational steps the transaction is allowed to take), and GASPRICE (the fee per computational step the sender is willing to pay). Miners collect these transactions, validate them, execute them, and include them in blocks, receiving the gas fees as compensation.
Messages are conceptually similar to transactions but are produced by contracts rather than external actors. When a contract's code executes, it can send messages to other contracts—these internal messages contain the sender (the contract address), recipient, an amount of ether to transfer, an optional data payload, and a STARTGAS limit. Messages enable contract-to-contract communication, allowing complex applications to be built from multiple interacting contracts rather than monolithic programs.
The gas mechanism is crucial for preventing abuse: every computational step, storage operation, and data byte in a transaction consumes gas. If a transaction runs out of gas before completing, all state changes are reverted (except the gas payment to the miner), preventing infinite loops or excessive computation from grinding the network to a halt. The sender specifies both the total gas budget (STARTGAS) and the price they're willing to pay per unit (GASPRICE), and any unused gas is refunded after execution completes.
Messages and Transactions
Las transacciones en Ethereum son paquetes de datos firmados creados por cuentas de propiedad externa y transmitidos a la red. Una transaccion contiene la direccion del destinatario, una firma criptografica que prueba la identidad del remitente, la cantidad de ether a transferir, un campo de datos opcional (crucial para interactuar con contratos), STARTGAS (el numero maximo de pasos computacionales que la transaccion puede realizar) y GASPRICE (la comision por paso computacional que el remitente esta dispuesto a pagar). Los mineros recopilan estas transacciones, las validan, las ejecutan y las incluyen en bloques, recibiendo las comisiones de gas como compensacion.
Los mensajes son conceptualmente similares a las transacciones pero son producidos por contratos en lugar de actores externos. Cuando el codigo de un contrato se ejecuta, puede enviar mensajes a otros contratos — estos mensajes internos contienen el remitente (la direccion del contrato), el destinatario, una cantidad de ether a transferir, una carga de datos opcional y un limite de STARTGAS. Los mensajes permiten la comunicacion de contrato a contrato, permitiendo que aplicaciones complejas se construyan a partir de multiples contratos interactuantes en lugar de programas monoliticos.
El mecanismo de gas es crucial para prevenir abusos: cada paso computacional, operacion de almacenamiento y byte de datos en una transaccion consume gas. Si una transaccion se queda sin gas antes de completarse, todos los cambios de estado se revierten (excepto el pago de gas al minero), previniendo que bucles infinitos o computacion excesiva paralicen la red. El remitente especifica tanto el presupuesto total de gas (STARTGAS) como el precio que esta dispuesto a pagar por unidad (GASPRICE), y cualquier gas no utilizado se reembolsa despues de que la ejecucion se completa.
Ethereum State Transition Function
The Ethereum state transition function APPLY(S,TX) - S' defines how a transaction transforms the blockchain state, and it follows a precise sequence of steps. First, the system checks transaction validity: verifying the signature is correct, confirming the nonce matches the sender's account nonce, and ensuring the sender has sufficient balance to pay the upfront cost (STARTGAS × GASPRICE plus the value being sent). If any check fails, the transaction is rejected before execution begins. If valid, the transaction fee is deducted from the sender's account, the sender's nonce is incremented, and an initial gas counter is set to STARTGAS minus a per-byte fee for the transaction data.
Next, the system transfers the specified ether value from the sender to the recipient. If the recipient is an externally owned account, this completes the transaction. If the recipient is a contract account, the contract's code runs in the Ethereum Virtual Machine, consuming gas for each operation until either the code completes successfully, the code explicitly halts, or the gas runs out. During execution, the contract can read and modify its storage, send messages to other contracts, and create new contracts.
Finally, if the value transfer failed (insufficient balance) or code execution failed (running out of gas or hitting an error), all state changes are reverted—except that the sender still pays gas fees to the miner for the computation performed. If execution succeeded, the remaining gas is refunded to the sender, and the gas that was consumed is sent to the miner as a fee. This mechanism ensures that miners are compensated for computation while preventing runaway execution from consuming unbounded resources.
Ethereum State Transition Function
La funcion de transicion de estado de Ethereum APPLY(S,TX) - S' define como una transaccion transforma el estado de la blockchain, y sigue una secuencia precisa de pasos. Primero, el sistema verifica la validez de la transaccion: verificando que la firma sea correcta, confirmando que el nonce coincide con el nonce de la cuenta del remitente, y asegurando que el remitente tiene saldo suficiente para pagar el costo inicial (STARTGAS x GASPRICE mas el valor enviado). Si alguna verificacion falla, la transaccion es rechazada antes de que comience la ejecucion. Si es valida, la comision de transaccion se deduce de la cuenta del remitente, el nonce del remitente se incrementa, y se establece un contador de gas inicial a STARTGAS menos una tarifa por byte para los datos de la transaccion.
A continuacion, el sistema transfiere el valor de ether especificado del remitente al destinatario. Si el destinatario es una cuenta de propiedad externa, esto completa la transaccion. Si el destinatario es una cuenta de contrato, el codigo del contrato se ejecuta en la Maquina Virtual de Ethereum, consumiendo gas por cada operacion hasta que el codigo se completa exitosamente, el codigo se detiene explicitamente, o el gas se agota. Durante la ejecucion, el contrato puede leer y modificar su almacenamiento, enviar mensajes a otros contratos y crear nuevos contratos.
Finalmente, si la transferencia de valor fallo (saldo insuficiente) o la ejecucion del codigo fallo (quedarse sin gas o encontrar un error), todos los cambios de estado se revierten — excepto que el remitente aun paga las comisiones de gas al minero por la computacion realizada. Si la ejecucion fue exitosa, el gas restante se reembolsa al remitente, y el gas consumido se envia al minero como comision. Este mecanismo asegura que los mineros sean compensados por la computacion mientras previene que la ejecucion descontrolada consuma recursos ilimitados.
Code Execution
The Ethereum Virtual Machine (EVM) is the runtime environment where contract code executes—a low-level, stack-based virtual machine similar in concept to the Java Virtual Machine or WebAssembly. Contract code is stored as a sequence of bytes, where each byte represents an operation (opcode) that the EVM can execute. The execution model is deliberately simple and deterministic: every node running the EVM with the same input state and transaction must arrive at the same output state, ensuring consensus across the network.
The EVM provides three distinct types of storage for computation. The stack is a last-in-first-out (LIFO) structure limited to 1024 elements, used for immediate operation values. Memory is an infinitely expandable byte array that persists only for the duration of a single message call and is reset between executions. Storage is the persistent key-value store permanently associated with each account/" class="glossary-link" data-slug="contract-account" title="contract account">contract account, where contracts maintain their long-term state across transactions. These storage types are priced differently in gas—stack and memory operations are cheap, while storage operations are expensive to prevent blockchain bloat.
During execution, contract code has access to crucial context: it can read the message sender's address, the amount of ether sent, the data payload provided by the caller, and block-level properties like the current block number, timestamp, and miner address. The code can return an output byte array to the caller and can send messages to other contracts or create new contracts. This execution model is Turing-complete—loops and complex control flow are possible—but the gas mechanism ensures that all computation terminates in bounded time, solving the halting problem economically rather than through language restrictions.
Code Execution
La Maquina Virtual de Ethereum (EVM) es el entorno de ejecucion donde se ejecuta el codigo de los contratos — una maquina virtual de bajo nivel basada en pila, similar en concepto a la Maquina Virtual de Java o WebAssembly. El codigo del contrato se almacena como una secuencia de bytes, donde cada byte representa una operacion (opcode) que la EVM puede ejecutar. El modelo de ejecucion es deliberadamente simple y determinista: cada nodo que ejecute la EVM con el mismo estado de entrada y transaccion debe llegar al mismo estado de salida, asegurando el consenso a traves de la red.
La EVM proporciona tres tipos distintos de almacenamiento para la computacion. La pila (stack) es una estructura de ultimo en entrar, primero en salir (LIFO) limitada a 1024 elementos, utilizada para valores de operacion inmediatos. La memoria (memory) es un arreglo de bytes infinitamente expandible que persiste solo durante la duracion de una unica llamada de mensaje y se reinicia entre ejecuciones. El almacenamiento (storage) es el almacen persistente de clave-valor permanentemente asociado con cada cuenta de contrato">cuenta de contrato, donde los contratos mantienen su estado a largo plazo entre transacciones. Estos tipos de almacenamiento tienen precios diferentes en gas — las operaciones de pila y memoria son baratas, mientras que las operaciones de almacenamiento son costosas para prevenir la inflacion de la blockchain.
Durante la ejecucion, el codigo del contrato tiene acceso a contexto crucial: puede leer la direccion del remitente del mensaje, la cantidad de ether enviada, la carga de datos proporcionada por el invocador, y propiedades a nivel de bloque como el numero de bloque actual, la marca de tiempo y la direccion del minero. El codigo puede devolver un arreglo de bytes de salida al invocador y puede enviar mensajes a otros contratos o crear nuevos contratos. Este modelo de ejecucion es Turing-completo — los bucles y el flujo de control complejo son posibles — pero el mecanismo de gas asegura que toda la computacion termine en un tiempo limitado, resolviendo el problema de la detencion de manera economica en lugar de a traves de restricciones del lenguaje.
Blockchain and Mining
The Ethereum blockchain is fundamentally similar to Bitcoin's, serving as a database containing every transaction ever executed. However, while Bitcoin stores only a transaction list, Ethereum stores both the transaction list and the most recent state. Each block in Ethereum contains the previous block's hash, a state root (the root hash of the Patricia trie">Merkle Patricia trie representing the entire state), a transaction root, a receipt root (storing data from transaction execution), along with difficulty, timestamp, and nonce values. The state itself is a large Merkle Patricia trie mapping addresses to account objects, where each account has a balance, nonce, code (if present), and storage.
Ethereum uses a modified version of the GHOST (Greedy Heaviest Observed Subtree) protocol to address security issues that arise from fast block times. In traditional longest-chain protocols, fast blocks lead to high stale rates, reducing network security and increasing centralization risks as large miners waste less computation on stales. GHOST includes stale blocks (called "uncles" in Ethereum) in the calculation of which chain is longest, and provides partial rewards to uncle blocks, incentivizing miners to reference them. This allows Ethereum to maintain a target block time of approximately 12 seconds while preserving network security.
The mining algorithm works similarly to Bitcoin's proof-of-work, requiring miners to find a nonce such that the hash of the block is below a certain difficulty target. However, Ethereum's memory-hard mining algorithm (Ethash) is designed to be ASIC-resistant, promoting a more decentralized mining ecosystem. The difficulty adjusts dynamically based on block times to maintain the ~12 second target, ensuring consistent block production while the GHOST protocol provides security guarantees despite the faster block times compared to Bitcoin's 10-minute average.
Blockchain and Mining
La blockchain de Ethereum es fundamentalmente similar a la de Bitcoin, sirviendo como una base de datos que contiene cada transaccion jamas ejecutada. Sin embargo, mientras que Bitcoin almacena solo una lista de transacciones, Ethereum almacena tanto la lista de transacciones como el estado mas reciente. Cada bloque en Ethereum contiene el hash del bloque anterior, una raiz de estado (el hash raiz del Patricia trie">Merkle Patricia trie que representa el estado completo), una raiz de transacciones, una raiz de recibos (que almacena datos de la ejecucion de transacciones), junto con valores de dificultad, marca de tiempo y nonce. El estado en si es un gran Merkle Patricia trie que mapea direcciones a objetos de cuenta, donde cada cuenta tiene un saldo, nonce, codigo (si esta presente) y almacenamiento.
Ethereum utiliza una version modificada del protocolo GHOST (Greedy Heaviest Observed Subtree) para abordar problemas de seguridad que surgen de tiempos de bloque rapidos. En los protocolos tradicionales de cadena mas larga, los bloques rapidos conducen a altas tasas de obsolescencia, reduciendo la seguridad de la red y aumentando los riesgos de centralizacion ya que los grandes mineros desperdician menos computacion en bloques obsoletos. GHOST incluye bloques obsoletos (llamados "tios" en Ethereum) en el calculo de cual cadena es mas larga, y proporciona recompensas parciales a los bloques tio, incentivando a los mineros a referenciarlos. Esto permite a Ethereum mantener un tiempo de bloque objetivo de aproximadamente 12 segundos mientras preserva la seguridad de la red.
El algoritmo de mineria funciona de manera similar al proof of work de Bitcoin, requiriendo que los mineros encuentren un nonce tal que el hash del bloque este por debajo de un cierto objetivo de dificultad. Sin embargo, el algoritmo de mineria de uso intensivo de memoria de Ethereum (Ethash) esta disenado para ser resistente a ASIC, promoviendo un ecosistema de mineria mas descentralizado. La dificultad se ajusta dinamicamente basandose en los tiempos de bloque para mantener el objetivo de ~12 segundos, asegurando una produccion de bloques consistente mientras el protocolo GHOST proporciona garantias de seguridad a pesar de los tiempos de bloque mas rapidos comparados con el promedio de 10 minutos de Bitcoin.
Applications
The applications that can be built on Ethereum fall into three broad categories. The first category is financial applications, providing users with more powerful ways to manage and enter contracts involving their money. This includes sub-currencies, financial derivatives, hedging contracts, savings wallets with withdrawal limits, wills that distribute funds automatically, and even employment contracts that calculate payment based on verified work completion. These applications leverage Ethereum's programmability to create complex financial instruments that would be impossible or extremely difficult to implement in traditional systems or even on Bitcoin.
The second category is semi-financial applications, where money is involved but there is also a substantial non-monetary component to what is being done. A perfect example is self-enforcing bounties for solutions to computational problems. Someone could post a computational problem along with a reward, and the contract could automatically verify submitted solutions and pay out the bounty to the first correct answer. This category bridges pure finance and other domains, using economic incentives to solve problems or coordinate behavior.
The third category is applications that have nothing to do with money at all, such as online voting and decentralized governance systems. These non-financial applications demonstrate Ethereum's flexibility as a general-purpose platform. Examples include decentralized domain name systems like Namecoin, reputation systems, decentralized file storage, and organizational governance tools. Of all these application types, token systems have emerged as the most common and fundamental, serving as building blocks for many other applications.
Applications
Las aplicaciones que pueden construirse sobre Ethereum se dividen en tres amplias categorias. La primera categoria son las aplicaciones financieras, que proporcionan a los usuarios formas mas poderosas de gestionar y participar en contratos que involucran su dinero. Esto incluye sub-monedas, derivados financieros, contratos de cobertura, carteras de ahorro con limites de retiro, testamentos que distribuyen fondos automaticamente, e incluso contratos de empleo que calculan pagos basandose en la verificacion de trabajo completado. Estas aplicaciones aprovechan la programabilidad de Ethereum para crear instrumentos financieros complejos que serian imposibles o extremadamente dificiles de implementar en sistemas tradicionales o incluso en Bitcoin.
La segunda categoria son las aplicaciones semi-financieras, donde el dinero esta involucrado pero tambien hay un componente no monetario sustancial en lo que se esta haciendo. Un ejemplo perfecto son las recompensas auto-ejecutables para soluciones a problemas computacionales. Alguien podria publicar un problema computacional junto con una recompensa, y el contrato podria verificar automaticamente las soluciones enviadas y pagar la recompensa a la primera respuesta correcta. Esta categoria tiende un puente entre las finanzas puras y otros dominios, utilizando incentivos economicos para resolver problemas o coordinar comportamiento.
La tercera categoria son las aplicaciones que no tienen nada que ver con el dinero, como los sistemas de votacion en linea y gobernanza descentralizada. Estas aplicaciones no financieras demuestran la flexibilidad de Ethereum como plataforma de proposito general. Los ejemplos incluyen sistemas de nombres de dominio descentralizados como Namecoin, sistemas de reputacion, almacenamiento de archivos descentralizado y herramientas de gobernanza organizacional. De todos estos tipos de aplicaciones, los sistemas de tokens han surgido como los mas comunes y fundamentales, sirviendo como bloques de construccion para muchas otras aplicaciones.
Token Systems
Token systems are surprisingly straightforward to implement on Ethereum, despite being one of the most powerful and common applications. At their core, token systems are simply a database with a single operation: subtract X units from account A and add X units to account B, with the condition that A had at least X units before the transaction and the transaction is authorized by A. The implementation requires maintaining a mapping of addresses to balances and providing a transfer function that performs the appropriate checks before moving tokens between accounts.
The contract code for a basic token system is remarkably simple and can be written in just a few lines. It consists of a data structure mapping addresses to balances, an initialization function that assigns initial token supply, and a transfer function that checks the sender's balance and authorization before executing the transfer. This simplicity stands in stark contrast to the complexity required to implement similar systems on Bitcoin, which would require significant workarounds and limitations due to Bitcoin's restricted scripting capabilities.
Tokens on Ethereum can represent virtually anything of value. They might represent sub-currencies with their own monetary policies, financial derivatives tracking external assets, company shares with dividend rights, loyalty points in customer programs, commodities like gold or oil, or even representations of physical property. The programmability of Ethereum allows these tokens to have arbitrary rules governing their behavior, such as transfer restrictions, automatic burning mechanisms, dividend distributions, or governance rights. This flexibility has made token systems the foundational building block for much of the Ethereum ecosystem.
Token Systems
Los sistemas de tokens son sorprendentemente sencillos de implementar en Ethereum, a pesar de ser una de las aplicaciones mas poderosas y comunes. En esencia, los sistemas de tokens son simplemente una base de datos con una unica operacion: restar X unidades de la cuenta A y agregar X unidades a la cuenta B, con la condicion de que A tenia al menos X unidades antes de la transaccion y la transaccion esta autorizada por A. La implementacion requiere mantener un mapeo de direcciones a saldos y proporcionar una funcion de transferencia que realice las verificaciones apropiadas antes de mover tokens entre cuentas.
El codigo del contrato para un sistema de tokens basico es notablemente simple y puede escribirse en solo unas pocas lineas. Consiste en una estructura de datos que mapea direcciones a saldos, una funcion de inicializacion que asigna el suministro inicial de tokens, y una funcion de transferencia que verifica el saldo y la autorizacion del remitente antes de ejecutar la transferencia. Esta simplicidad contrasta fuertemente con la complejidad requerida para implementar sistemas similares en Bitcoin, que requeriria soluciones alternativas significativas y limitaciones debido a las capacidades restringidas de scripting de Bitcoin.
Los tokens en Ethereum pueden representar virtualmente cualquier cosa de valor. Pueden representar sub-monedas con sus propias politicas monetarias, derivados financieros que rastrean activos externos, acciones de empresas con derechos a dividendos, puntos de fidelidad en programas de clientes, materias primas como oro o petroleo, o incluso representaciones de propiedad fisica. La programabilidad de Ethereum permite que estos tokens tengan reglas arbitrarias que gobiernen su comportamiento, como restricciones de transferencia, mecanismos de quema automatica, distribuciones de dividendos o derechos de gobernanza. Esta flexibilidad ha hecho de los sistemas de tokens el bloque de construccion fundamental para gran parte del ecosistema de Ethereum.
Financial Derivatives and Stable-Value Currencies
Financial derivatives represent one of the most fundamental and important applications of Ethereum smart contracts. A simple hedging contract demonstrates the basic mechanism: party A deposits a certain amount of ether worth \(1000, party B deposits an equivalent amount, and the contract records the USD value of ether at that moment using a data feed. After 30 days, the contract recalculates the value and sends ether worth \)1000 to A and the remainder to B. If the price of ether has risen, A receives fewer ether but maintains $1000 value; if it has fallen, A receives more ether to maintain that value. This allows A to hedge against volatility while B speculates on price movements.
The implementation of such contracts requires access to external data through oracle contracts or data feeds. These oracles provide price information, weather data, or other real-world information that contracts need to execute properly. While oracles introduce a trust dependency, they can be designed with redundancy and cryptoeconomic incentives to provide reliable data. The contract itself simply queries the oracle, performs calculations based on that data, and distributes funds according to its programmed logic.
Stablecoins and more complex financial instruments can be built using similar mechanisms. A stablecoin contract might maintain a reserve of ether and issue tokens pegged to a fiat currency, automatically adjusting supply or collateral requirements based on price feeds. Options contracts, futures, swaps, and other derivatives that would normally require complex legal frameworks and trusted intermediaries can instead be encoded as self-executing smart contracts. This programmable finance infrastructure enables sophisticated financial engineering while maintaining the transparency and security guarantees of blockchain technology.
Financial Derivatives and Stable-Value Currencies
Los derivados financieros representan una de las aplicaciones mas fundamentales e importantes de los smart contracts de Ethereum. Un simple contrato de cobertura demuestra el mecanismo basico: la parte A deposita una cierta cantidad de ether con valor de \(1000, la parte B deposita una cantidad equivalente, y el contrato registra el valor en USD del ether en ese momento usando un feed de datos. Despues de 30 dias, el contrato recalcula el valor y envia ether por valor de \)1000 a A y el resto a B. Si el precio del ether ha subido, A recibe menos ether pero mantiene el valor de $1000; si ha bajado, A recibe mas ether para mantener ese valor. Esto permite a A cubrirse contra la volatilidad mientras B especula sobre los movimientos de precio.
La implementacion de tales contratos requiere acceso a datos externos a traves de contratos oraculo o feeds de datos. Estos oraculos proporcionan informacion de precios, datos meteorologicos u otra informacion del mundo real que los contratos necesitan para ejecutarse correctamente. Aunque los oraculos introducen una dependencia de confianza, pueden disenarse con redundancia e incentivos criptoeconomicos para proporcionar datos confiables. El contrato en si simplemente consulta al oraculo, realiza calculos basados en esos datos y distribuye fondos de acuerdo con su logica programada.
Las stablecoins y instrumentos financieros mas complejos pueden construirse utilizando mecanismos similares. Un contrato de stablecoin podria mantener una reserva de ether y emitir tokens vinculados a una moneda fiduciaria, ajustando automaticamente el suministro o los requisitos de colateral basandose en feeds de precios. Los contratos de opciones, futuros, swaps y otros derivados que normalmente requeririan marcos legales complejos e intermediarios de confianza pueden en su lugar codificarse como smart contracts auto-ejecutables. Esta infraestructura de finanzas programables permite una ingenieria financiera sofisticada manteniendo las garantias de transparencia y seguridad de la tecnologia blockchain.
Identity and Reputation Systems
A name registration system similar to Namecoin is trivially implementable on Ethereum and serves as the simplest example of an identity system. The contract maintains a database with a key-value table mapping names to associated data (such as IP addresses, public keys, or other information). Anyone can register a name by sending a transaction to the contract along with a small registration fee, provided that name is not already taken. The owner can update the associated data at any time, and names can be made transferable or permanent according to the rules encoded in the contract.
More advanced identity systems can be built on this foundation to include reputation scores, web of trust relationships, and decentralized identity verification. For example, a contract could maintain reputation scores based on verified transactions, peer ratings, or completion of tasks. These scores would be publicly visible and cryptographically tied to specific addresses, creating a portable reputation that follows users across applications. Web of trust systems could allow users to vouch for others' identities, building social graphs that help distinguish legitimate users from bad actors.
Such identity and reputation systems become particularly powerful when integrated with other applications. A marketplace could require minimum reputation scores for sellers, a loan platform could adjust interest rates based on borrower reputation, or a social network could use web of trust to filter spam and fraudulent content. By providing a shared infrastructure for identity that any application can query, Ethereum enables a new class of trust-based applications that don't rely on centralized identity providers or proprietary reputation systems.
Identity and Reputation Systems
Un sistema de registro de nombres similar a Namecoin es trivialmente implementable en Ethereum y sirve como el ejemplo mas simple de un sistema de identidad. El contrato mantiene una base de datos con una tabla clave-valor que mapea nombres a datos asociados (como direcciones IP, claves publicas u otra informacion). Cualquiera puede registrar un nombre enviando una transaccion al contrato junto con una pequena tarifa de registro, siempre que ese nombre no este ya tomado. El propietario puede actualizar los datos asociados en cualquier momento, y los nombres pueden hacerse transferibles o permanentes de acuerdo con las reglas codificadas en el contrato.
Sistemas de identidad mas avanzados pueden construirse sobre esta base para incluir puntuaciones de reputacion, relaciones de red de confianza y verificacion de identidad descentralizada. Por ejemplo, un contrato podria mantener puntuaciones de reputacion basadas en transacciones verificadas, calificaciones de pares o completacion de tareas. Estas puntuaciones serian publicamente visibles y criptograficamente vinculadas a direcciones especificas, creando una reputacion portatil que sigue a los usuarios a traves de las aplicaciones. Los sistemas de red de confianza podrian permitir a los usuarios avalar la identidad de otros, construyendo grafos sociales que ayudan a distinguir usuarios legitimos de actores maliciosos.
Tales sistemas de identidad y reputacion se vuelven particularmente poderosos cuando se integran con otras aplicaciones. Un mercado podria requerir puntuaciones minimas de reputacion para los vendedores, una plataforma de prestamos podria ajustar las tasas de interes basandose en la reputacion del prestatario, o una red social podria usar la red de confianza para filtrar spam y contenido fraudulento. Al proporcionar una infraestructura compartida de identidad que cualquier aplicacion puede consultar, Ethereum permite una nueva clase de aplicaciones basadas en la confianza que no dependen de proveedores de identidad centralizados o sistemas de reputacion propietarios.
Decentralized File Storage
Decentralized file storage can be implemented through Ethereum contracts that coordinate between users who need storage and providers who offer it. In a "decentralized Dropbox" model, users would pay a monthly fee to upload files, with the contract distributing payments to storage providers who prove they are actually storing the data. The proof mechanism works through periodic cryptographic challenges: the contract randomly selects portions of files and asks providers to supply Merkle tree proofs demonstrating they possess that data. Providers who fail challenges or go offline would lose their deposits and future payment stream.
This approach offers several advantages over centralized storage. Merkle tree proofs enable efficient verification—users and the contract can confirm file availability without downloading entire files. The system naturally distributes files across multiple independent providers, creating redundancy without requiring explicit replication protocols. Economic incentives align provider behavior with user needs: providers earn money by reliably storing data and lose money if they fail to do so. This eliminates the trust requirement inherent in centralized storage solutions.
Storage costs in such a system can potentially be lower than centralized alternatives for several reasons. The elimination of monopoly pricing allows market competition to drive costs down to near the actual cost of storage. Implicit redundancy from multiple users storing similar files can reduce total storage requirements. There's no need for expensive data center infrastructure or corporate overhead. However, challenges remain around payment mechanisms, ensuring adequate provider participation, and managing the tradeoff between redundancy and cost. Despite these challenges, decentralized storage demonstrates how Ethereum can coordinate complex multi-party interactions through economic incentives alone.
Decentralized File Storage
El almacenamiento descentralizado de archivos puede implementarse a traves de contratos de Ethereum que coordinan entre usuarios que necesitan almacenamiento y proveedores que lo ofrecen. En un modelo de "Dropbox descentralizado", los usuarios pagarian una tarifa mensual para subir archivos, con el contrato distribuyendo pagos a los proveedores de almacenamiento que demuestren que realmente estan almacenando los datos. El mecanismo de prueba funciona a traves de desafios criptograficos periodicos: el contrato selecciona aleatoriamente porciones de archivos y pide a los proveedores que proporcionen pruebas de Merkle tree demostrando que poseen esos datos. Los proveedores que fallen en los desafios o se desconecten perderian sus depositos y flujo de pagos futuros.
Este enfoque ofrece varias ventajas sobre el almacenamiento centralizado. Las pruebas de Merkle tree permiten una verificacion eficiente — los usuarios y el contrato pueden confirmar la disponibilidad de archivos sin descargar archivos completos. El sistema distribuye naturalmente los archivos entre multiples proveedores independientes, creando redundancia sin requerir protocolos de replicacion explicitos. Los incentivos economicos alinean el comportamiento del proveedor con las necesidades del usuario: los proveedores ganan dinero almacenando datos de manera confiable y pierden dinero si no lo hacen. Esto elimina el requisito de confianza inherente en las soluciones de almacenamiento centralizado.
Los costos de almacenamiento en tal sistema pueden ser potencialmente mas bajos que las alternativas centralizadas por varias razones. La eliminacion de precios monopolicos permite que la competencia del mercado reduzca los costos cerca del costo real de almacenamiento. La redundancia implicita de multiples usuarios almacenando archivos similares puede reducir los requisitos totales de almacenamiento. No hay necesidad de infraestructura costosa de centros de datos o gastos generales corporativos. Sin embargo, persisten desafios en torno a los mecanismos de pago, asegurar una participacion adecuada de proveedores y gestionar el equilibrio entre redundancia y costo. A pesar de estos desafios, el almacenamiento descentralizado demuestra como Ethereum puede coordinar interacciones complejas de multiples partes solo a traves de incentivos economicos.
Decentralized Autonomous Organizations
A Decentralized Autonomous Organization (DAO) is a virtual entity that has a set of members or shareholders who collectively have the right to spend the entity's funds and modify its code. A typical DAO operates with a simple rule: 67% of members are needed to make spending decisions or modify the organization's code. Members can submit proposals, vote on them, and if a proposal receives sufficient support, the contract automatically executes the decision. Membership shares can be transferable, allowing a liquid market for DAO participation, and different classes of shares can have different voting rights or economic claims.
The simplest DAO design is a self-modifying contract that maintains a list of members and requires a 2/3 majority vote to change any aspect of the contract, including its own voting rules. Members would submit code changes as transactions, other members would vote, and upon reaching the threshold, the contract would update itself. More sophisticated designs might include delegated voting systems where members can assign their voting power to representatives, or liquid democracy where votes can be delegated but reclaimed at any time for important decisions.
DAOs can serve various purposes beyond simple fund management. A DAO could function as a decentralized corporation, hiring contractors, purchasing services, and distributing profits to shareholders—all governed by smart contract code rather than traditional legal structures. It could operate as a decentralized investment fund, with members voting on which projects to fund. It could manage a commons resource, with stakeholders voting on allocation rules. The key insight is that by encoding governance rules in transparent, immutable code and tying them to economic stake, DAOs can coordinate group decisions without requiring traditional hierarchical management or legal enforcement.
Decentralized Autonomous Organizations
Una Organizacion Autonoma Descentralizada (DAO) es una entidad virtual que tiene un conjunto de miembros o accionistas que colectivamente tienen el derecho de gastar los fondos de la entidad y modificar su codigo. Una DAO tipica opera con una regla simple: el 67% de los miembros son necesarios para tomar decisiones de gasto o modificar el codigo de la organizacion. Los miembros pueden enviar propuestas, votar sobre ellas, y si una propuesta recibe suficiente apoyo, el contrato ejecuta automaticamente la decision. Las participaciones de membresia pueden ser transferibles, permitiendo un mercado liquido para la participacion en la DAO, y diferentes clases de participaciones pueden tener diferentes derechos de voto o reclamaciones economicas.
El diseno mas simple de una DAO es un contrato auto-modificable que mantiene una lista de miembros y requiere una mayoria de 2/3 de votos para cambiar cualquier aspecto del contrato, incluyendo sus propias reglas de votacion. Los miembros enviarian cambios de codigo como transacciones, otros miembros votarian, y al alcanzar el umbral, el contrato se actualizaria a si mismo. Disenos mas sofisticados podrian incluir sistemas de votacion delegada donde los miembros pueden asignar su poder de voto a representantes, o democracia liquida donde los votos pueden ser delegados pero reclamados en cualquier momento para decisiones importantes.
Las DAOs pueden servir a diversos propositos mas alla de la simple gestion de fondos. Una DAO podria funcionar como una corporacion descentralizada, contratando proveedores, comprando servicios y distribuyendo beneficios a los accionistas — todo gobernado por codigo de smart contract en lugar de estructuras legales tradicionales. Podria operar como un fondo de inversion descentralizado, con los miembros votando sobre que proyectos financiar. Podria gestionar un recurso comun, con los interesados votando sobre las reglas de asignacion. La idea clave es que al codificar las reglas de gobernanza en codigo transparente e inmutable y vincularlas a una participacion economica, las DAOs pueden coordinar decisiones de grupo sin requerir gestion jerarquica tradicional o aplicacion legal.
Further Applications
Beyond the major categories already discussed, Ethereum enables numerous other applications. Savings wallets with sophisticated security features can impose daily withdrawal limits while providing emergency keys for recovery, protecting users from theft while maintaining ultimate control. Crop insurance contracts can automatically pay farmers based on weather data feeds, eliminating claims processing and reducing administrative overhead. Peer-to-peer gambling applications can operate without any trusted intermediary, with smart contracts holding stakes and automatically paying winners based on verifiable random numbers or real-world event data.
On-chain prediction markets allow users to bet on future events, creating powerful forecasting mechanisms through the wisdom of crowds. These can be augmented with SchellingCoin-style protocols to create decentralized oracles: participants independently report data (like election results or weather conditions), and those whose reports match the majority receive rewards while outliers are penalized. This cryptoeconomic approach incentivizes honest reporting and can provide reliable real-world data to other contracts without requiring trust in any single oracle provider.
Multi-signature wallets represent another important application, enabling shared control of funds between multiple parties. A 2-of-3 multi-sig wallet might require any two of three designated parties to approve a transaction before funds can be spent, useful for escrow arrangements, corporate treasuries, or personal security. Decentralized marketplaces can combine identity systems, reputation scores, escrow contracts, and dispute resolution mechanisms to enable peer-to-peer commerce without centralized platforms. Each of these applications demonstrates how Ethereum's programmability enables new trust models and organizational structures.
Further Applications
Mas alla de las categorias principales ya discutidas, Ethereum permite numerosas otras aplicaciones. Las carteras de ahorro con caracteristicas de seguridad sofisticadas pueden imponer limites de retiro diarios mientras proporcionan claves de emergencia para la recuperacion, protegiendo a los usuarios del robo mientras mantienen el control ultimo. Los contratos de seguro de cosechas pueden pagar automaticamente a los agricultores basandose en feeds de datos meteorologicos, eliminando el procesamiento de reclamaciones y reduciendo los gastos administrativos. Las aplicaciones de apuestas entre pares pueden operar sin ningun intermediario de confianza, con smart contracts manteniendo las apuestas y pagando automaticamente a los ganadores basandose en numeros aleatorios verificables o datos de eventos del mundo real.
Los mercados de prediccion en la cadena permiten a los usuarios apostar sobre eventos futuros, creando poderosos mecanismos de pronostico a traves de la sabiduria de las masas. Estos pueden aumentarse con protocolos tipo SchellingCoin para crear oraculos descentralizados: los participantes reportan datos independientemente (como resultados electorales o condiciones meteorologicas), y aquellos cuyos reportes coinciden con la mayoria reciben recompensas mientras los valores atipicos son penalizados. Este enfoque criptoeconomico incentiva el reporte honesto y puede proporcionar datos del mundo real confiables a otros contratos sin requerir confianza en ningun proveedor de oraculo individual.
Las carteras multifirma representan otra aplicacion importante, permitiendo el control compartido de fondos entre multiples partes. Una cartera multifirma 2-de-3 podria requerir que dos de tres partes designadas aprueben una transaccion antes de que los fondos puedan gastarse, util para acuerdos de deposito en garantia, tesorerias corporativas o seguridad personal. Los mercados descentralizados pueden combinar sistemas de identidad, puntuaciones de reputacion, contratos de deposito en garantia y mecanismos de resolucion de disputas para permitir el comercio entre pares sin plataformas centralizadas. Cada una de estas aplicaciones demuestra como la programabilidad de Ethereum permite nuevos modelos de confianza y estructuras organizacionales.
Miscellanea And Concerns
Ethereum's implementation of the modified GHOST protocol includes specific rules for uncle inclusion and rewards. Uncles must be direct children of the current block's ancestor (between 2 and 7 generations back), must be valid block headers, must be distinct from previous uncles, and must not be direct ancestors of the current block. Uncle blocks receive 87.5% of the standard block reward, while the including block receives an additional 3.125% per uncle included (up to two uncles). This incentive structure encourages miners to reference stale blocks they observe, strengthening network security while rewarding miners who experienced temporary bad luck with network propagation.
The transaction-fee/" class="glossary-link" data-slug="transaction-fee" title="fee">fee system is based on the concept of "gas," where every computational operation has a fixed gas cost. For example, a multiplication operation costs 5 gas, a SHA256 hash costs 20 gas, and every transaction has a base cost of 21,000 gas. Users specify both a gas limit (maximum gas they're willing to consume) and a gas price (how much ether they'll pay per unit of gas). This system serves multiple purposes: it prevents infinite loops and denial-of-service attacks by ensuring all computation is paid for, it creates a market for block space where users bid via gas prices, and it allows miners to set a minimum gas price they're willing to accept, protecting network resources.
Scalability remains a significant concern, as every node/" class="glossary-link" data-slug="full-node" title="full node">full node must process every transaction to verify the state. Current blockchain architectures struggle to match centralized systems' transaction throughput. Potential solutions include state sharding, where different nodes process different subsets of transactions, and a transition from proof-of-work to proof-of-stake consensus, which could enable more efficient block production. Light clients using Merkle proofs can verify transactions without processing all blocks, but someone must still process everything. These scalability challenges represent active areas of research and development critical to Ethereum's long-term viability.
Miscellanea And Concerns
La implementacion de Ethereum del protocolo GHOST modificado incluye reglas especificas para la inclusion y recompensas de tios. Los tios deben ser hijos directos de un ancestro del bloque actual (entre 2 y 7 generaciones atras), deben ser cabeceras de bloque validas, deben ser distintos de tios anteriores y no deben ser ancestros directos del bloque actual. Los bloques tio reciben el 87.5% de la recompensa estandar de bloque, mientras que el bloque que los incluye recibe un 3.125% adicional por cada tio incluido (hasta dos tios). Esta estructura de incentivos anima a los mineros a referenciar bloques obsoletos que observan, fortaleciendo la seguridad de la red mientras recompensa a los mineros que experimentaron mala suerte temporal con la propagacion de la red.
El sistema de comisiones se basa en el concepto de "gas", donde cada operacion computacional tiene un costo fijo en gas. Por ejemplo, una operacion de multiplicacion cuesta 5 gas, un hash SHA256 cuesta 20 gas, y cada transaccion tiene un costo base de 21,000 gas. Los usuarios especifican tanto un limite de gas (maximo de gas que estan dispuestos a consumir) como un precio de gas (cuanto ether pagaran por unidad de gas). Este sistema sirve multiples propositos: previene bucles infinitos y ataques de denegacion de servicio al asegurar que toda la computacion se pague, crea un mercado para el espacio de bloques donde los usuarios pujan mediante precios de gas, y permite a los mineros establecer un precio minimo de gas que estan dispuestos a aceptar, protegiendo los recursos de la red.
La escalabilidad sigue siendo una preocupacion significativa, ya que cada nodo completo">nodo completo debe procesar cada transaccion para verificar el estado. Las arquitecturas blockchain actuales luchan por igualar el rendimiento de transacciones de los sistemas centralizados. Las soluciones potenciales incluyen el sharding de estado, donde diferentes nodos procesan diferentes subconjuntos de transacciones, y una transicion de proof of work a consenso proof of stake, que podria permitir una produccion de bloques mas eficiente. Los clientes ligeros que usan pruebas de Merkle pueden verificar transacciones sin procesar todos los bloques, pero alguien debe seguir procesando todo. Estos desafios de escalabilidad representan areas activas de investigacion y desarrollo criticas para la viabilidad a largo plazo de Ethereum.
Conclusion
The Ethereum protocol was originally conceived as an upgraded version of a cryptocurrency, providing advanced features like on-blockchain escrow, withdrawal limits, and financial contracts through a highly generalized programming language. However, the Ethereum protocol moves far beyond just currency. Protocols around decentralized file storage, decentralized computation, and decentralized prediction markets, among dozens of other concepts, have the potential to substantially increase the efficiency of the computational industry and provide a massive boost to other peer-to-peer protocols by adding for the first time an economic layer.
Rather than providing a limited set of operations designed for specific use cases, Ethereum provides a Turing-complete programming language that enables developers to build any application they can design. Want to invent your own financial derivative? Create your own currency? Establish a government on the blockchain? These are all trivially implementable with Ethereum's scripting system. The platform's power lies not in predicting what applications will be built, but in providing the foundational infrastructure that makes building them easy.
The concept of an arbitrary state transition function as implemented by the Ethereum protocol provides a platform with unique potential. Rather than being a closed-ended, single-purpose protocol intended for specific applications in data storage, gambling, or finance, Ethereum is open-ended by design, and we believe it is extremely well-suited to serving as a foundational layer for a large number of both financial and non-financial protocols in the years to come. The applications that will be built on Ethereum in the future may be ones we cannot even imagine today, and that open-ended possibility represents the true promise of the platform.
Conclusion
El protocolo de Ethereum fue concebido originalmente como una version mejorada de una criptomoneda, proporcionando caracteristicas avanzadas como depositos en garantia en la blockchain, limites de retiro y contratos financieros a traves de un lenguaje de programacion altamente generalizado. Sin embargo, el protocolo de Ethereum va mucho mas alla de solo la moneda. Los protocolos en torno al almacenamiento descentralizado de archivos, la computacion descentralizada y los mercados de prediccion descentralizados, entre docenas de otros conceptos, tienen el potencial de aumentar sustancialmente la eficiencia de la industria computacional y proporcionar un impulso masivo a otros protocolos peer-to-peer al agregar por primera vez una capa economica.
En lugar de proporcionar un conjunto limitado de operaciones disenadas para casos de uso especificos, Ethereum proporciona un lenguaje de programacion Turing-completo que permite a los desarrolladores construir cualquier aplicacion que puedan disenar. Quieres inventar tu propio derivado financiero? Crear tu propia moneda? Establecer un gobierno en la blockchain? Todo esto es trivialmente implementable con el sistema de scripting de Ethereum. El poder de la plataforma no radica en predecir que aplicaciones se construiran, sino en proporcionar la infraestructura fundacional que hace facil construirlas.
El concepto de una funcion de transicion de estado arbitraria implementada por el protocolo de Ethereum proporciona una plataforma con un potencial unico. En lugar de ser un protocolo cerrado, de proposito unico, destinado a aplicaciones especificas en almacenamiento de datos, apuestas o finanzas, Ethereum es abierto por diseno, y creemos que es extremadamente adecuado para servir como capa fundacional para un gran numero de protocolos tanto financieros como no financieros en los anos venideros. Las aplicaciones que se construiran sobre Ethereum en el futuro pueden ser aquellas que ni siquiera podemos imaginar hoy, y esa posibilidad abierta representa la verdadera promesa de la plataforma.
References and Further Reading
The Ethereum whitepaper builds upon extensive prior work in cryptocurrency and distributed systems research. The foundational Bitcoin protocol is described in Satoshi Nakamoto's original 2008 paper "Bitcoin: A Peer-to-Peer Electronic Cash System," which introduced the concept of blockchain-based digital currency. Early attempts to extend Bitcoin's functionality include Namecoin, a decentralized name registration system demonstrating blockchain applications beyond currency, though limited by Bitcoin's restricted scripting capabilities.
The colored coins whitepaper proposed a method for representing alternative assets on the Bitcoin blockchain by "coloring" specific bitcoins to represent other assets, while Mastercoin attempted to create a protocol layer on top of Bitcoin for more complex financial instruments. Both highlighted the limitations of building on Bitcoin and motivated the need for a more flexible platform. The concept of decentralized autonomous corporations, explored in Bitcoin Magazine, provided theoretical foundations for organizational governance through smart contracts.
Key technical components include simplified payment verification (SPV) for light clients, Merkle trees for efficient data verification, and Patricia tries for Ethereum's state representation. The GHOST (Greedy Heaviest Observed Subtree) protocol, described in a 2013 cryptography paper, addresses security issues arising from fast block times and forms the basis for Ethereum's consensus mechanism. These references represent the intellectual foundations upon which Ethereum was built, combining insights from cryptocurrency, distributed systems, cryptography, and game theory to create a general-purpose blockchain platform.
References and Further Reading
El whitepaper de Ethereum se basa en un extenso trabajo previo en investigacion de criptomonedas y sistemas distribuidos. El protocolo fundacional de Bitcoin se describe en el articulo original de 2008 de Satoshi Nakamoto "Bitcoin: A Peer-to-Peer Electronic Cash System", que introdujo el concepto de moneda digital basada en blockchain. Los primeros intentos de extender la funcionalidad de Bitcoin incluyen Namecoin, un sistema de registro de nombres descentralizado que demuestra aplicaciones de blockchain mas alla de la moneda, aunque limitado por las capacidades restringidas de scripting de Bitcoin.
El whitepaper de colored coins propuso un metodo para representar activos alternativos en la blockchain de Bitcoin "coloreando" bitcoins especificos para representar otros activos, mientras que Mastercoin intento crear una capa de protocolo sobre Bitcoin para instrumentos financieros mas complejos. Ambos resaltaron las limitaciones de construir sobre Bitcoin y motivaron la necesidad de una plataforma mas flexible. El concepto de corporaciones autonomas descentralizadas, explorado en Bitcoin Magazine, proporciono fundamentos teoricos para la gobernanza organizacional a traves de smart contracts.
Los componentes tecnicos clave incluyen la verificacion de pagos simplificada (SPV) para clientes ligeros, Merkle trees para la verificacion eficiente de datos y Patricia tries para la representacion de estado de Ethereum. El protocolo GHOST (Greedy Heaviest Observed Subtree), descrito en un articulo de criptografia de 2013, aborda problemas de seguridad que surgen de tiempos de bloque rapidos y forma la base del mecanismo de consenso de Ethereum. Estas referencias representan los fundamentos intelectuales sobre los cuales se construyo Ethereum, combinando conocimientos de criptomonedas, sistemas distribuidos, criptografia y teoria de juegos para crear una plataforma blockchain de proposito general.
Related Whitepapers
$USDT
Tether
Tether: Fiat currencies on the Bitcoin blockchain
30 shared concepts · 2016
$BCH
Bitcoin Cash
Bitcoin Cash: Peer-to-Peer Electronic Cash for the World
33 shared concepts · 2017
$DOGE
Dogecoin
Dogecoin: A Community-Driven Cryptocurrency
28 shared concepts · 2013
$USDC
USD Coin
USD Coin (USDC): A Stablecoin by Circle and Coinbase
20 shared concepts · 2018
$BTC
Bitcoin
Bitcoin: A Peer-to-Peer Electronic Cash System
20 shared concepts · 2008