Ethereum: Plataforma de Contratos Inteligentes e Aplicações Descentralizadas de Próxima Geração
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 e uma plataforma de criptomoedas e aplicacoes descentralizadas de nova geracao que introduz uma blockchain com uma linguagem de programacao Turing-completa incorporada. Isso permite que qualquer pessoa escreva smart contracts e aplicacoes descentralizadas onde podem criar suas proprias regras arbitrarias para propriedade, formatos de transacao e funcoes de transicao de estado.
A inovacao fundamental do Ethereum e combinar a tecnologia blockchain pioneira do Bitcoin com um ambiente de programacao de proposito geral. Enquanto o Bitcoin fornece um sistema simples de transicao de estado para mover moeda de uma conta para outra, o Ethereum fornece uma plataforma onde desenvolvedores podem construir qualquer tipo de aplicacao descentralizada que possam imaginar, desde moedas alternativas e instrumentos financeiros ate sistemas de registro de dominios e organizacoes descentralizadas.
O Ethereum alcanca isso construindo o que e essencialmente a camada fundacional abstrata definitiva: uma blockchain com uma linguagem de programacao Turing-completa incorporada, permitindo que qualquer pessoa escreva smart contracts e aplicacoes descentralizadas onde podem criar suas proprias regras arbitrarias para propriedade, formatos de transacao e funcoes de transicao de estado. Uma versao basica do Namecoin pode ser escrita em duas linhas de codigo, e outros protocolos como moedas e sistemas de reputacao podem ser construidos em menos de vinte.
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
O conceito de moeda digital descentralizada, assim como aplicacoes alternativas como registros de propriedade, existe ha decadas. Os protocolos anonimos de dinheiro eletronico das decadas de 1980 e 1990, em sua maioria dependentes de uma primitiva criptografica conhecida como cegamento de Chaum, forneciam uma moeda com alto grau de privacidade, mas os protocolos em grande parte nao conseguiram ganhar tracao devido a sua dependencia de um intermediario centralizado. Em 1998, o b-money de Wei Dai tornou-se a primeira proposta a introduzir a ideia de criar dinheiro atraves da resolucao de quebra-cabecas computacionais, bem como consenso descentralizado, mas a proposta era escassa em detalhes sobre como o consenso descentralizado poderia realmente ser implementado.
Em 2009, uma moeda descentralizada foi implementada na pratica pela primeira vez por Satoshi Nakamoto, combinando primitivas estabelecidas para gerenciar propriedade atraves de criptografia de chave publica com um algoritmo de consenso para rastrear quem possui as moedas, conhecido como "proof of work". O mecanismo por tras do proof of work foi um avanco no campo porque resolveu simultaneamente dois problemas. Primeiro, forneceu um algoritmo de consenso simples e moderadamente eficaz, permitindo que os nos da rede concordassem coletivamente em um conjunto de atualizacoes canonicas ao estado do livro-razao do Bitcoin. Segundo, forneceu um mecanismo para permitir a entrada livre no processo de consenso, resolvendo o problema politico de decidir quem pode influenciar o consenso, enquanto simultaneamente prevenia ataques sybil.
A blockchain do Bitcoin provou ser notavelmente robusta ao longo de seus anos de operacao, mas e inerentemente limitada. A linguagem de scripting do Bitcoin e intencionalmente projetada para ser restritiva e nao Turing-completa, carecendo de loops e muitas outras funcionalidades que seriam necessarias para construir aplicacoes mais complexas. Essa limitacao existe para prevenir loops infinitos e outras formas de ataques computacionais, mas restringe severamente o que pode ser construido sobre o Bitcoin.
Nos ultimos cinco anos, houve varias tentativas de estender a funcionalidade do Bitcoin. Os colored coins buscaram usar a blockchain do Bitcoin para rastrear a propriedade de ativos alternativos, o Namecoin tentou criar um banco de dados descentralizado de registro de nomes, e varios protocolos metacoin buscaram construir camadas adicionais sobre o Bitcoin. Embora essas abordagens tenham mostrado promessa, foram finalmente limitadas pelas capacidades de scripting do Bitcoin e pela incapacidade de acessar dados da blockchain de dentro dos scripts.
O que o Ethereum pretende fornecer e uma blockchain com uma linguagem de programacao Turing-completa totalmente desenvolvida que pode ser usada para criar "contratos" que podem ser usados para codificar funcoes de transicao de estado arbitrarias, permitindo aos usuarios criar qualquer um dos sistemas descritos acima, bem como muitos outros que ainda nao imaginamos, simplesmente escrevendo a logica em poucas linhas 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
Do ponto de vista tecnico, o livro-razao de uma criptomoeda como o Bitcoin pode ser pensado como um sistema de transicao de estado, onde ha um "estado" que consiste no status de propriedade de todos os bitcoins existentes e uma "funcao de transicao de estado" que recebe um estado e uma transacao e produz um novo estado que e o resultado. Em um sistema bancario padrao, por exemplo, o estado e um balanco patrimonial, uma transacao e uma solicitacao para mover \(X de A para B, e a funcao de transicao de estado reduz o valor na conta de A em \)X e aumenta o valor na conta de B em \(X. Se a conta de A tem menos de \)X inicialmente, a funcao de transicao de estado retorna um erro.
O "estado" no Bitcoin e a colecao de todas as moedas (tecnicamente, "saidas de transacao nao gastas" ou UTXO) que foram cunhadas e ainda nao gastas, onde cada UTXO tem uma denominacao e um proprietario (definido por um endereco de 20 bytes que e essencialmente uma chave publica criptografica). Uma transacao contem uma ou mais entradas, onde cada entrada contem uma referencia a um UTXO existente e uma assinatura criptografica produzida pela chave privada associada ao endereco do proprietario, e uma ou mais saidas, onde cada saida contem um novo UTXO a ser adicionado ao estado.
A funcao de transicao de estado APPLY(S,TX) - S' pode ser definida aproximadamente da seguinte forma:
- Para cada entrada em TX, se o UTXO referenciado nao esta em S, retornar um erro.
- Se a assinatura fornecida nao corresponde ao proprietario do UTXO, retornar um erro.
- Se a soma das denominacoes de todos os UTXO de entrada e menor que a soma das denominacoes de todos os UTXO de saida, retornar um erro.
- Retornar S com todos os UTXO de entrada removidos e todos os UTXO de saida adicionados.
A primeira metade do primeiro passo impede que os remetentes de transacoes gastem moedas que nao existem, a segunda metade do primeiro passo impede que os remetentes gastem moedas de outras pessoas, e o segundo passo garante a conservacao de valor. Para usar isso para pagamentos, o protocolo e o seguinte: suponha que Alice queira enviar 11.7 BTC para Bob. Primeiro, Alice procurara um conjunto de UTXO disponiveis que ela possui e que somem pelo menos 11.7 BTC. Realisticamente, Alice nao conseguira obter exatamente 11.7 BTC; digamos que o minimo que ela pode obter e 6+4+2=12. Ela entao cria uma transacao com essas tres entradas e duas saidas. A primeira saida sera 11.7 BTC com o endereco de Bob como proprietario, e a segunda saida sera o "troco" restante de 0.3 BTC, sendo a proprietaria a propria 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
Se tivessemos acesso a um servico centralizado confiavel, este sistema seria trivial de implementar; poderia simplesmente ser codificado exatamente como descrito, usando o disco rigido de um servidor centralizado para rastrear o estado. No entanto, com o Bitcoin estamos tentando construir um sistema de moeda descentralizado, entao precisaremos combinar o sistema de transicao de estado com um sistema de consenso para garantir que todos concordem com a ordem das transacoes. O processo de consenso descentralizado do Bitcoin requer que os nos na rede tentem continuamente produzir pacotes de transacoes chamados "blocos". A rede e projetada para produzir aproximadamente um bloco a cada dez minutos, com cada bloco contendo um carimbo de tempo, um nonce, uma referencia ao (ou seja, hash do) bloco anterior e uma lista de todas as transacoes que ocorreram desde o bloco anterior.
Com o tempo, isso cria uma "blockchain" persistente e em constante crescimento que se atualiza constantemente para representar o estado mais recente do livro-razao do Bitcoin. O algoritmo para verificar se um bloco e valido, expresso neste paradigma, e o seguinte:
- Verificar se o bloco anterior referenciado pelo bloco existe e e valido.
- Verificar que o carimbo de tempo do bloco e maior que o do bloco anterior e menor que 2 horas no futuro.
- Verificar que o proof of work do bloco e valido.
- Seja S o estado no final do bloco anterior.
- Suponha que TX e a lista de transacoes do bloco com n transacoes. Para todo i em 0...n-1, definir S = APPLY(S,TX[i]). Se qualquer aplicacao retornar um erro, sair e retornar falso.
- Retornar verdadeiro e registrar S como o estado no final deste bloco.
Essencialmente, cada transacao no bloco deve fornecer uma transicao de estado valida do que era o estado canonico antes da transacao ser executada para algum novo estado. Note que o estado nao esta codificado no bloco de nenhuma forma; e puramente uma abstracao a ser lembrada pelo no validador e so pode ser calculada (de forma segura) para qualquer bloco comecando a partir do estado genesis e aplicando sequencialmente cada transacao em cada bloco.
O minerador e recompensado por seu trabalho computacional com bitcoins recem-criados mais as taxas de transacao. O processo de mineracao funciona da seguinte forma: os mineradores pegam o cabecalho do bloco e fazem hash dele repetidamente com diferentes valores de nonce ate encontrar um hash que esteja abaixo de um certo alvo de dificuldade. Quando um minerador encontra tal hash, transmite o bloco para a rede, e outros nos verificam que o hash e valido e que todas as transacoes no bloco sao validas. O alvo de dificuldade e ajustado automaticamente pelo protocolo a cada 2016 blocos (aproximadamente duas semanas) para garantir que os blocos sejam produzidos a uma taxa aproximadamente constante.
Note que a longo prazo, a seguranca da blockchain depende dos mineradores terem um incentivo financeiro para se comportar honestamente. Se um atacante controlar mais de 50% do poder de mineracao da rede, ele pode potencialmente executar um "ataque de 51%" criando uma blockchain alternativa que cresce mais rapido que a cadeia honesta. No entanto, tal ataque exigiria enormes recursos computacionais e provavelmente resultaria nas recompensas de mineracao do atacante se tornando sem valor a medida que a rede perdesse confianca na integridade da 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
Merkle trees sao uma estrutura de dados fundamental utilizada nos blocos do Bitcoin para permitir a verificacao eficiente e segura da inclusao de transacoes. Um Merkle tree e uma arvore binaria de hashes onde os nos folha contem hashes de transacoes individuais, e cada no interior contem o hash de seus dois filhos, construindo-se recursivamente ate um unico hash raiz que e armazenado no cabecalho do bloco. Essa estrutura hierarquica permite que qualquer pessoa verifique que uma transacao especifica esta incluida em um bloco baixando apenas o ramo do Merkle tree — a cadeia de hashes desde a transacao ate a raiz — em vez de baixar todas as transacoes do bloco.
Os ganhos de eficiencia sao substanciais: enquanto um no completo do Bitcoin deve armazenar toda a blockchain (aproximadamente 15GB em 2013), um no de verificacao de pagamento simplificada (SPV) so precisa baixar os cabecalhos dos blocos contendo as raizes do Merkle tree, exigindo apenas 4MB de dados. Para verificar uma transacao, um no SPV solicita o ramo do Merkle tree aos nos completos, o que requer apenas O(log n) dados onde n e o numero de transacoes em um bloco. Essa escalabilidade logaritmica torna viavel executar clientes leves em dispositivos moveis e ambientes com recursos limitados.
O uso de Merkle trees pelo Bitcoin demonstra um principio-chave: estruturas criptograficas podem reduzir drasticamente os requisitos de confianca e recursos para participar de uma rede descentralizada. Esse mesmo principio fundamenta o design do Ethereum, onde Merkle trees sao usados nao apenas para transacoes, mas tambem para armazenamento de estado e recibos, permitindo protocolos de clientes leves ainda mais 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
O sucesso da blockchain do Bitcoin inspirou inumeras tentativas de estender o conceito alem da simples moeda. Namecoin, lancado em 2010, foi um dos primeiros exemplos — um banco de dados descentralizado de registro de nomes construido sobre uma blockchain, permitindo que os usuarios registrassem nomes em um espaco de nomes distribuido que nenhuma autoridade central poderia censurar ou revogar. Os colored coins surgiram como uma forma de representar ativos alternativos na blockchain do Bitcoin "marcando" saidas de transacao especificas para representar a propriedade de ativos do mundo real, acoes de empresas ou outras criptomoedas. Os metacoins e metaprotocolos como Mastercoin (posteriormente Omni) adicionaram funcionalidade extra sobre o Bitcoin codificando dados adicionais nas transacoes do Bitcoin e construindo regras de protocolo separadas por cima.
No entanto, todas essas abordagens sofriam de limitacoes fundamentais impostas pela arquitetura do Bitcoin. A linguagem de scripting do Bitcoin e intencionalmente restrita — nao pode acessar o estado da blockchain, carece de loops e fluxo de controle complexo, e fornece introspecao limitada sobre os valores das transacoes. Construir aplicacoes sofisticadas exigia solucoes alternativas desajeitadas: codificar metadados em campos de transacao que nunca foram destinados para esse proposito, depender de infraestrutura fora da cadeia para logica complexa, ou aceitar limitacoes severas no que o protocolo poderia realizar.
Essas restricoes motivaram a busca por uma plataforma blockchain de proposito mais geral. Em vez de construir mais um protocolo de proposito especial sobre a base limitada do Bitcoin, o Ethereum adota uma abordagem diferente: fornecer uma blockchain com uma linguagem de programacao Turing-completa incorporada, permitindo que qualquer pessoa escreva smart contracts e aplicacoes descentralizadas com regras arbitrarias para propriedade, formatos de transacao e funcoes de transicao 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, a linguagem usada para definir as condicoes de gasto das transacoes do Bitcoin, e intencionalmente projetada com severas limitacoes. Nao e Turing-completa — notavelmente, carece de loops e estruturas complexas de fluxo de controle. A linguagem opera como um ambiente de execucao simples baseado em pilha onde as operacoes empurram e extraem valores, avaliam condicoes criptograficas e finalmente retornam verdadeiro ou falso para determinar se uma transacao e valida. Embora essa simplicidade forneca beneficios de seguranca e facilite a analise formal, tambem torna impossivel implementar muitos tipos de aplicacoes.
Essas limitacoes se dividem em tres categorias principais. Primeiro, a falta de completude de Turing impede a implementacao de maquinas de estado complexas, arvores de decisao ou qualquer algoritmo que requeira iteracao. Segundo, a cegueira de valor significa que os scripts nao podem especificar controle detalhado sobre as quantias de saque — um UTXO so pode ser gasto em sua totalidade, com o troco enviado para uma nova saida. Um script nao pode, por exemplo, limitar saques a um maximo de X por dia enquanto deixa o restante bloqueado. Terceiro, a falta de consciencia do estado da blockchain significa que os UTXO estao gastos ou nao gastos sem estados intermediarios, tornando impossivel implementar contratos de multiplas etapas puramente na cadeia.
Essas restricoes tornam aplicacoes sofisticadas como organizacoes autonomas descentralizadas, carteiras de poupanca com limites de saque, exchanges descentralizadas ou mercados de predicao impossiveis ou exigem mecanismos desajeitados fora da cadeia. Um contrato financeiro avancado pode exigir acesso a dados de mercado, a capacidade de manter estado interno atraves de multiplas transacoes e logica condicional complexa — nada do que o Bitcoin Script pode fornecer. O Ethereum elimina essas limitacoes fornecendo uma linguagem Turing-completa com acesso completo ao estado da 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
O objetivo fundamental do Ethereum e fornecer uma blockchain com uma linguagem de programacao Turing-completa incorporada que permita a qualquer pessoa escrever smart contracts e aplicacoes descentralizadas onde possam criar suas proprias regras arbitrarias para propriedade, formatos de transacao e funcoes de transicao de estado. Em vez de projetar um protocolo para aplicacoes especificas como moeda, registro de nomes ou negociacao de ativos, o Ethereum fornece uma camada fundacional — uma plataforma de computacao distribuida baseada em blockchain que os desenvolvedores podem usar para construir qualquer aplicacao que possam imaginar.
A arquitetura difere fundamentalmente do modelo UTXO do Bitcoin. O Ethereum usa um sistema baseado em contas onde o estado da blockchain consiste em um mapeamento de enderecos para objetos de conta. Cada conta tem um saldo, um contador de transacoes (nonce), e para contas de contrato, codigo associado e armazenamento. A plataforma inclui uma linguagem de programacao Turing-completa incorporada para escrever codigo de contrato que e executado na Maquina Virtual Ethereum (EVM), um ambiente de execucao baseado em pilha que processa transacoes e transicoes de estado.
Essa generalidade permite uma vasta gama de aplicacoes: criptomoedas alternativas com regras de emissao personalizadas, derivativos financeiros e stablecoins, sistemas de identidade e reputacao, armazenamento de arquivos descentralizado, organizacoes autonomas descentralizadas (DAOs), e muito mais. O whitepaper enfatiza que o Ethereum nao e otimizado para nenhum caso de uso particular, mas sim fornece os blocos de construcao fundamentais — contas, transacoes, uma linguagem Turing-completa e execucao medida por gas — que os desenvolvedores podem combinar para criar qualquer aplicacao que o ecossistema 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
No Ethereum, o estado e composto por contas, e ha dois tipos fundamentais. As contas de propriedade externa (EOAs) sao controladas por chaves privadas e nao possuem codigo associado — representam usuarios humanos ou entidades externas interagindo com a blockchain. As contas de contrato sao controladas pelo seu codigo de contrato e sao ativadas quando recebem uma mensagem ou transacao. Ambos os tipos compartilham uma estrutura comum: cada conta tem um nonce (um contador usado para garantir que cada transacao so possa ser processada uma vez), um saldo de ether, e para os contratos especificamente, codigo de contrato e armazenamento persistente.
Ether e a criptomoeda interna principal do Ethereum, servindo tanto como meio de transferencia de valor quanto como unidade fundamental para pagar taxas de transacao (gas). Diferentemente do modelo UTXO do Bitcoin onde o valor esta distribuido entre multiplas saidas nao gastas, as contas do Ethereum mantem um saldo simples que aumenta quando recebem ether e diminui quando o enviam. Esse modelo baseado em contas simplifica muitos tipos de aplicacoes, particularmente aquelas que requerem estado persistente ou controle de acesso complexo, embora introduza diferentes consideracoes de seguranca comparado com a abordagem do Bitcoin.
A distincao entre EOAs e contas de contrato e crucial para entender o funcionamento do Ethereum. As EOAs podem iniciar transacoes criando e assinando mensagens com suas chaves privadas, pagando taxas de gas para que suas transacoes sejam incluidas em blocos. As contas de contrato nao podem iniciar transacoes por si mesmas, mas podem enviar mensagens para outros contratos em resposta ao recebimento de uma transacao ou mensagem, permitindo cadeias complexas de execucao onde uma unica transacao externa desencadeia multiplas interacoes de contrato para 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
As transacoes no Ethereum sao pacotes de dados assinados criados por contas de propriedade externa e transmitidos para a rede. Uma transacao contem o endereco do destinatario, uma assinatura criptografica provando a identidade do remetente, a quantidade de ether a transferir, um campo de dados opcional (crucial para interagir com contratos), STARTGAS (o numero maximo de passos computacionais que a transacao pode realizar) e GASPRICE (a taxa por passo computacional que o remetente esta disposto a pagar). Os mineradores coletam essas transacoes, as validam, as executam e as incluem em blocos, recebendo as taxas de gas como compensacao.
As mensagens sao conceitualmente similares as transacoes, mas sao produzidas por contratos em vez de atores externos. Quando o codigo de um contrato e executado, ele pode enviar mensagens para outros contratos — essas mensagens internas contem o remetente (o endereco do contrato), o destinatario, uma quantidade de ether a transferir, uma carga de dados opcional e um limite de STARTGAS. As mensagens permitem a comunicacao de contrato para contrato, possibilitando que aplicacoes complexas sejam construidas a partir de multiplos contratos interagindo entre si em vez de programas monoliticos.
O mecanismo de gas e crucial para prevenir abusos: cada passo computacional, operacao de armazenamento e byte de dados em uma transacao consome gas. Se uma transacao ficar sem gas antes de ser concluida, todas as mudancas de estado sao revertidas (exceto o pagamento de gas ao minerador), prevenindo que loops infinitos ou computacao excessiva paralisem a rede. O remetente especifica tanto o orcamento total de gas (STARTGAS) quanto o preco que esta disposto a pagar por unidade (GASPRICE), e qualquer gas nao utilizado e reembolsado apos a execucao ser concluida.
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
A funcao de transicao de estado do Ethereum APPLY(S,TX) - S' define como uma transacao transforma o estado da blockchain, e segue uma sequencia precisa de etapas. Primeiro, o sistema verifica a validade da transacao: verificando que a assinatura esta correta, confirmando que o nonce corresponde ao nonce da conta do remetente, e garantindo que o remetente tem saldo suficiente para pagar o custo inicial (STARTGAS x GASPRICE mais o valor enviado). Se qualquer verificacao falhar, a transacao e rejeitada antes que a execucao comece. Se valida, a taxa de transacao e deduzida da conta do remetente, o nonce do remetente e incrementado, e um contador de gas inicial e definido como STARTGAS menos uma taxa por byte para os dados da transacao.
Em seguida, o sistema transfere o valor de ether especificado do remetente para o destinatario. Se o destinatario e uma conta de propriedade externa, isso completa a transacao. Se o destinatario e uma conta de contrato, o codigo do contrato e executado na Maquina Virtual Ethereum, consumindo gas para cada operacao ate que o codigo seja concluido com sucesso, o codigo pare explicitamente, ou o gas se esgote. Durante a execucao, o contrato pode ler e modificar seu armazenamento, enviar mensagens para outros contratos e criar novos contratos.
Finalmente, se a transferencia de valor falhou (saldo insuficiente) ou a execucao do codigo falhou (ficar sem gas ou encontrar um erro), todas as mudancas de estado sao revertidas — exceto que o remetente ainda paga as taxas de gas ao minerador pela computacao realizada. Se a execucao foi bem-sucedida, o gas restante e reembolsado ao remetente, e o gas consumido e enviado ao minerador como taxa. Esse mecanismo garante que os mineradores sejam compensados pela computacao enquanto previne que a execucao 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
A Maquina Virtual Ethereum (EVM) e o ambiente de execucao onde o codigo dos contratos e executado — uma maquina virtual de baixo nivel baseada em pilha, similar em conceito a Maquina Virtual Java ou WebAssembly. O codigo do contrato e armazenado como uma sequencia de bytes, onde cada byte representa uma operacao (opcode) que a EVM pode executar. O modelo de execucao e deliberadamente simples e deterministico: cada no executando a EVM com o mesmo estado de entrada e transacao deve chegar ao mesmo estado de saida, garantindo o consenso atraves da rede.
A EVM fornece tres tipos distintos de armazenamento para computacao. A pilha (stack) e uma estrutura de ultimo a entrar, primeiro a sair (LIFO) limitada a 1024 elementos, usada para valores de operacao imediatos. A memoria (memory) e um array de bytes infinitamente expansivel que persiste apenas durante a duracao de uma unica chamada de mensagem e e reiniciada entre execucoes. O armazenamento (storage) e o armazem persistente de chave-valor permanentemente associado a cada conta de contrato">conta de contrato, onde os contratos mantem seu estado de longo prazo entre transacoes. Esses tipos de armazenamento tem precos diferentes em gas — as operacoes de pilha e memoria sao baratas, enquanto as operacoes de armazenamento sao caras para prevenir o inchaamento da blockchain.
Durante a execucao, o codigo do contrato tem acesso a contexto crucial: pode ler o endereco do remetente da mensagem, a quantidade de ether enviada, a carga de dados fornecida pelo invocador, e propriedades a nivel de bloco como o numero do bloco atual, o carimbo de tempo e o endereco do minerador. O codigo pode retornar um array de bytes de saida ao invocador e pode enviar mensagens para outros contratos ou criar novos contratos. Esse modelo de execucao e Turing-completo — loops e fluxo de controle complexo sao possiveis — mas o mecanismo de gas garante que toda a computacao termine em tempo limitado, resolvendo o problema da parada de forma economica em vez de atraves de restricoes da linguagem.
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
A blockchain do Ethereum e fundamentalmente similar a do Bitcoin, servindo como um banco de dados contendo cada transacao ja executada. No entanto, enquanto o Bitcoin armazena apenas uma lista de transacoes, o Ethereum armazena tanto a lista de transacoes quanto o estado mais recente. Cada bloco no Ethereum contem o hash do bloco anterior, uma raiz de estado (o hash raiz do Merkle Patricia trie representando o estado completo), uma raiz de transacoes, uma raiz de recibos (armazenando dados da execucao de transacoes), junto com valores de dificuldade, carimbo de tempo e nonce. O estado em si e um grande Merkle Patricia trie mapeando enderecos para objetos de conta, onde cada conta tem um saldo, nonce, codigo (se presente) e armazenamento.
O Ethereum usa uma versao modificada do protocolo GHOST (Greedy Heaviest Observed Subtree) para abordar problemas de seguranca que surgem de tempos de bloco rapidos. Nos protocolos tradicionais de cadeia mais longa, blocos rapidos levam a altas taxas de obsolescencia, reduzindo a seguranca da rede e aumentando os riscos de centralizacao ja que grandes mineradores desperdicam menos computacao em blocos obsoletos. O GHOST inclui blocos obsoletos (chamados "tios" no Ethereum) no calculo de qual cadeia e mais longa, e fornece recompensas parciais aos blocos tio, incentivando mineradores a referencia-los. Isso permite ao Ethereum manter um tempo de bloco alvo de aproximadamente 12 segundos enquanto preserva a seguranca da rede.
O algoritmo de mineracao funciona de forma similar ao proof of work do Bitcoin, exigindo que os mineradores encontrem um nonce tal que o hash do bloco esteja abaixo de um certo alvo de dificuldade. No entanto, o algoritmo de mineracao de uso intensivo de memoria do Ethereum (Ethash) e projetado para ser resistente a ASIC, promovendo um ecossistema de mineracao mais descentralizado. A dificuldade se ajusta dinamicamente com base nos tempos de bloco para manter o alvo de ~12 segundos, garantindo uma producao de blocos consistente enquanto o protocolo GHOST fornece garantias de seguranca apesar dos tempos de bloco mais rapidos comparados com a media de 10 minutos do 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
As aplicacoes que podem ser construidas sobre o Ethereum se dividem em tres amplas categorias. A primeira categoria sao as aplicacoes financeiras, fornecendo aos usuarios formas mais poderosas de gerenciar e participar de contratos envolvendo seu dinheiro. Isso inclui sub-moedas, derivativos financeiros, contratos de hedge, carteiras de poupanca com limites de saque, testamentos que distribuem fundos automaticamente, e ate contratos de emprego que calculam pagamentos com base na verificacao de trabalho concluido. Essas aplicacoes aproveitam a programabilidade do Ethereum para criar instrumentos financeiros complexos que seriam impossiveis ou extremamente dificeis de implementar em sistemas tradicionais ou mesmo no Bitcoin.
A segunda categoria sao as aplicacoes semi-financeiras, onde o dinheiro esta envolvido, mas tambem ha um componente nao monetario substancial no que esta sendo feito. Um exemplo perfeito sao as recompensas auto-executaveis para solucoes de problemas computacionais. Alguem poderia publicar um problema computacional junto com uma recompensa, e o contrato poderia verificar automaticamente as solucoes enviadas e pagar a recompensa para a primeira resposta correta. Essa categoria faz a ponte entre financas puras e outros dominios, usando incentivos economicos para resolver problemas ou coordenar comportamento.
A terceira categoria sao as aplicacoes que nao tem nada a ver com dinheiro, como sistemas de votacao online e governanca descentralizada. Essas aplicacoes nao financeiras demonstram a flexibilidade do Ethereum como plataforma de proposito geral. Os exemplos incluem sistemas de nomes de dominio descentralizados como Namecoin, sistemas de reputacao, armazenamento de arquivos descentralizado e ferramentas de governanca organizacional. De todos esses tipos de aplicacoes, os sistemas de tokens surgiram como os mais comuns e fundamentais, servindo como blocos de construcao para muitas outras aplicacoes.
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
Os sistemas de tokens sao surpreendentemente simples de implementar no Ethereum, apesar de serem uma das aplicacoes mais poderosas e comuns. Em sua essencia, os sistemas de tokens sao simplesmente um banco de dados com uma unica operacao: subtrair X unidades da conta A e adicionar X unidades a conta B, com a condicao de que A tinha pelo menos X unidades antes da transacao e a transacao e autorizada por A. A implementacao requer manter um mapeamento de enderecos para saldos e fornecer uma funcao de transferencia que realize as verificacoes apropriadas antes de mover tokens entre contas.
O codigo do contrato para um sistema de tokens basico e notavelmente simples e pode ser escrito em apenas algumas linhas. Consiste em uma estrutura de dados mapeando enderecos para saldos, uma funcao de inicializacao que atribui o fornecimento inicial de tokens, e uma funcao de transferencia que verifica o saldo e a autorizacao do remetente antes de executar a transferencia. Essa simplicidade contrasta fortemente com a complexidade necessaria para implementar sistemas semelhantes no Bitcoin, que exigiria solucoes alternativas significativas e limitacoes devido as capacidades restritas de scripting do Bitcoin.
Os tokens no Ethereum podem representar virtualmente qualquer coisa de valor. Podem representar sub-moedas com suas proprias politicas monetarias, derivativos financeiros que rastreiam ativos externos, acoes de empresas com direitos a dividendos, pontos de fidelidade em programas de clientes, commodities como ouro ou petroleo, ou ate representacoes de propriedade fisica. A programabilidade do Ethereum permite que esses tokens tenham regras arbitrarias governando seu comportamento, como restricoes de transferencia, mecanismos de queima automatica, distribuicoes de dividendos ou direitos de governanca. Essa flexibilidade tornou os sistemas de tokens o bloco de construcao fundamental para grande parte do ecossistema 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
Os derivativos financeiros representam uma das aplicacoes mais fundamentais e importantes dos smart contracts do Ethereum. Um simples contrato de hedge demonstra o mecanismo basico: a parte A deposita uma certa quantidade de ether no valor de \(1000, a parte B deposita uma quantidade equivalente, e o contrato registra o valor em USD do ether naquele momento usando um feed de dados. Apos 30 dias, o contrato recalcula o valor e envia ether no valor de \)1000 para A e o restante para B. Se o preco do ether subiu, A recebe menos ether mas mantem o valor de $1000; se caiu, A recebe mais ether para manter esse valor. Isso permite que A se proteja contra a volatilidade enquanto B especula sobre os movimentos de preco.
A implementacao de tais contratos requer acesso a dados externos atraves de contratos oraculo ou feeds de dados. Esses oraculos fornecem informacoes de precos, dados meteorologicos ou outras informacoes do mundo real que os contratos precisam para executar corretamente. Embora os oraculos introduzam uma dependencia de confianca, podem ser projetados com redundancia e incentivos criptoeconomicos para fornecer dados confiaveis. O contrato em si simplesmente consulta o oraculo, realiza calculos com base nesses dados e distribui fundos de acordo com sua logica programada.
Stablecoins e instrumentos financeiros mais complexos podem ser construidos usando mecanismos similares. Um contrato de stablecoin poderia manter uma reserva de ether e emitir tokens atrelados a uma moeda fiduciaria, ajustando automaticamente o fornecimento ou os requisitos de colateral com base em feeds de precos. Contratos de opcoes, futuros, swaps e outros derivativos que normalmente exigiriam marcos legais complexos e intermediarios confiaveis podem ser codificados como smart contracts auto-executaveis. Essa infraestrutura de financas programaveis permite engenharia financeira sofisticada mantendo as garantias de transparencia e seguranca da 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
Um sistema de registro de nomes similar ao Namecoin e trivialmente implementavel no Ethereum e serve como o exemplo mais simples de um sistema de identidade. O contrato mantem um banco de dados com uma tabela chave-valor mapeando nomes para dados associados (como enderecos IP, chaves publicas ou outras informacoes). Qualquer pessoa pode registrar um nome enviando uma transacao para o contrato junto com uma pequena taxa de registro, desde que esse nome ainda nao esteja em uso. O proprietario pode atualizar os dados associados a qualquer momento, e os nomes podem ser tornados transferiveis ou permanentes de acordo com as regras codificadas no contrato.
Sistemas de identidade mais avancados podem ser construidos sobre essa base para incluir pontuacoes de reputacao, relacoes de rede de confianca e verificacao de identidade descentralizada. Por exemplo, um contrato poderia manter pontuacoes de reputacao baseadas em transacoes verificadas, avaliacoes de pares ou conclusao de tarefas. Essas pontuacoes seriam publicamente visiveis e criptograficamente vinculadas a enderecos especificos, criando uma reputacao portatil que segue os usuarios atraves das aplicacoes. Os sistemas de rede de confianca poderiam permitir que os usuarios atestassem a identidade de outros, construindo grafos sociais que ajudam a distinguir usuarios legitimos de atores maliciosos.
Tais sistemas de identidade e reputacao se tornam particularmente poderosos quando integrados com outras aplicacoes. Um marketplace poderia exigir pontuacoes minimas de reputacao para vendedores, uma plataforma de emprestimos poderia ajustar as taxas de juros com base na reputacao do tomador, ou uma rede social poderia usar a rede de confianca para filtrar spam e conteudo fraudulento. Ao fornecer uma infraestrutura compartilhada de identidade que qualquer aplicacao pode consultar, o Ethereum permite uma nova classe de aplicacoes baseadas em confianca que nao dependem de provedores de identidade centralizados ou sistemas de reputacao proprietarios.
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
O armazenamento descentralizado de arquivos pode ser implementado atraves de contratos Ethereum que coordenam entre usuarios que precisam de armazenamento e provedores que o oferecem. Em um modelo de "Dropbox descentralizado", os usuarios pagariam uma taxa mensal para enviar arquivos, com o contrato distribuindo pagamentos aos provedores de armazenamento que provem que estao realmente armazenando os dados. O mecanismo de prova funciona atraves de desafios criptograficos periodicos: o contrato seleciona aleatoriamente porcoes de arquivos e pede aos provedores que fornecam provas de Merkle tree demonstrando que possuem aqueles dados. Os provedores que falharem nos desafios ou ficarem offline perderiam seus depositos e fluxo de pagamentos futuros.
Essa abordagem oferece varias vantagens sobre o armazenamento centralizado. As provas de Merkle tree permitem verificacao eficiente — os usuarios e o contrato podem confirmar a disponibilidade de arquivos sem baixar arquivos inteiros. O sistema distribui naturalmente os arquivos entre multiplos provedores independentes, criando redundancia sem exigir protocolos de replicacao explicitos. Os incentivos economicos alinham o comportamento do provedor com as necessidades do usuario: os provedores ganham dinheiro armazenando dados de forma confiavel e perdem dinheiro se nao o fizerem. Isso elimina o requisito de confianca inerente nas solucoes de armazenamento centralizado.
Os custos de armazenamento em tal sistema podem ser potencialmente mais baixos que as alternativas centralizadas por varias razoes. A eliminacao de precos monopolistas permite que a competicao de mercado reduza os custos para perto do custo real de armazenamento. A redundancia implicita de multiplos usuarios armazenando arquivos semelhantes pode reduzir os requisitos totais de armazenamento. Nao ha necessidade de infraestrutura cara de data centers ou custos corporativos gerais. No entanto, permanecem desafios em torno dos mecanismos de pagamento, garantir participacao adequada de provedores e gerenciar o equilibrio entre redundancia e custo. Apesar desses desafios, o armazenamento descentralizado demonstra como o Ethereum pode coordenar interacoes complexas de multiplas partes apenas atraves 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
Uma Organizacao Autonoma Descentralizada (DAO) e uma entidade virtual que possui um conjunto de membros ou acionistas que coletivamente tem o direito de gastar os fundos da entidade e modificar seu codigo. Uma DAO tipica opera com uma regra simples: 67% dos membros sao necessarios para tomar decisoes de gasto ou modificar o codigo da organizacao. Os membros podem enviar propostas, votar nelas, e se uma proposta receber apoio suficiente, o contrato executa automaticamente a decisao. As participacoes de membresia podem ser transferiveis, permitindo um mercado liquido para a participacao na DAO, e diferentes classes de participacoes podem ter diferentes direitos de voto ou reivindicacoes economicas.
O design mais simples de uma DAO e um contrato auto-modificavel que mantem uma lista de membros e requer maioria de 2/3 de votos para alterar qualquer aspecto do contrato, incluindo suas proprias regras de votacao. Os membros enviariam mudancas de codigo como transacoes, outros membros votariam, e ao atingir o limiar, o contrato se atualizaria. Designs mais sofisticados poderiam incluir sistemas de votacao delegada onde os membros podem atribuir seu poder de voto a representantes, ou democracia liquida onde os votos podem ser delegados mas reivindicados a qualquer momento para decisoes importantes.
As DAOs podem servir a diversos propositos alem da simples gestao de fundos. Uma DAO poderia funcionar como uma corporacao descentralizada, contratando prestadores de servicos, comprando servicos e distribuindo lucros aos acionistas — tudo governado por codigo de smart contract em vez de estruturas legais tradicionais. Poderia operar como um fundo de investimento descentralizado, com os membros votando sobre quais projetos financiar. Poderia gerenciar um recurso comum, com as partes interessadas votando sobre as regras de alocacao. A ideia-chave e que ao codificar as regras de governanca em codigo transparente e imutavel e vincula-las a uma participacao economica, as DAOs podem coordenar decisoes de grupo sem exigir gestao hierarquica tradicional ou aplicacao 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
Alem das categorias principais ja discutidas, o Ethereum possibilita numerosas outras aplicacoes. Carteiras de poupanca com recursos de seguranca sofisticados podem impor limites de saque diarios enquanto fornecem chaves de emergencia para recuperacao, protegendo os usuarios contra roubo enquanto mantem o controle final. Contratos de seguro agricola podem pagar automaticamente aos agricultores com base em feeds de dados meteorologicos, eliminando o processamento de sinistros e reduzindo os custos administrativos. Aplicacoes de apostas peer-to-peer podem operar sem nenhum intermediario confiavel, com smart contracts mantendo as apostas e pagando automaticamente aos vencedores com base em numeros aleatorios verificaveis ou dados de eventos do mundo real.
Os mercados de predicao on-chain permitem que os usuarios apostem em eventos futuros, criando poderosos mecanismos de previsao atraves da sabedoria das massas. Estes podem ser aprimorados com protocolos do tipo SchellingCoin para criar oraculos descentralizados: os participantes reportam dados independentemente (como resultados eleitorais ou condicoes meteorologicas), e aqueles cujos relatorios correspondem a maioria recebem recompensas enquanto os valores discrepantes sao penalizados. Essa abordagem criptoeconomica incentiva o relato honesto e pode fornecer dados do mundo real confiaveis para outros contratos sem exigir confianca em nenhum provedor de oraculo individual.
As carteiras multisig representam outra aplicacao importante, permitindo o controle compartilhado de fundos entre multiplas partes. Uma carteira multisig 2-de-3 poderia exigir que duas de tres partes designadas aprovem uma transacao antes que os fundos possam ser gastos, util para acordos de garantia, tesourarias corporativas ou seguranca pessoal. Os marketplaces descentralizados podem combinar sistemas de identidade, pontuacoes de reputacao, contratos de garantia e mecanismos de resolucao de disputas para permitir o comercio peer-to-peer sem plataformas centralizadas. Cada uma dessas aplicacoes demonstra como a programabilidade do Ethereum permite novos modelos de confianca e estruturas organizacionais.
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
A implementacao do Ethereum do protocolo GHOST modificado inclui regras especificas para inclusao e recompensas de tios. Os tios devem ser filhos diretos de um ancestral do bloco atual (entre 2 e 7 geracoes atras), devem ser cabecalhos de bloco validos, devem ser distintos de tios anteriores e nao devem ser ancestrais diretos do bloco atual. Os blocos tio recebem 87.5% da recompensa padrao de bloco, enquanto o bloco que os inclui recebe um adicional de 3.125% por cada tio incluido (ate dois tios). Essa estrutura de incentivos encoraja os mineradores a referenciar blocos obsoletos que observam, fortalecendo a seguranca da rede enquanto recompensa mineradores que tiveram ma sorte temporaria com a propagacao da rede.
O sistema de taxas e baseado no conceito de "gas", onde cada operacao computacional tem um custo fixo em gas. Por exemplo, uma operacao de multiplicacao custa 5 gas, um hash SHA256 custa 20 gas, e cada transacao tem um custo base de 21.000 gas. Os usuarios especificam tanto um limite de gas (maximo de gas que estao dispostos a consumir) quanto um preco de gas (quanto ether pagarao por unidade de gas). Esse sistema serve a multiplos propositos: previne loops infinitos e ataques de negacao de servico garantindo que toda computacao seja paga, cria um mercado para espaco de bloco onde os usuarios fazem lances via precos de gas, e permite que mineradores definam um preco minimo de gas que estao dispostos a aceitar, protegendo os recursos da rede.
A escalabilidade continua sendo uma preocupacao significativa, ja que cada no completo deve processar cada transacao para verificar o estado. As arquiteturas blockchain atuais lutam para igualar o throughput de transacoes dos sistemas centralizados. Solucoes potenciais incluem sharding de estado, onde diferentes nos processam diferentes subconjuntos de transacoes, e uma transicao de proof of work para consenso proof of stake, que poderia permitir producao de blocos mais eficiente. Clientes leves usando provas de Merkle podem verificar transacoes sem processar todos os blocos, mas alguem ainda precisa processar tudo. Esses desafios de escalabilidade representam areas ativas de pesquisa e desenvolvimento criticas para a viabilidade de longo prazo do 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
O protocolo Ethereum foi originalmente concebido como uma versao aprimorada de uma criptomoeda, fornecendo recursos avancados como garantias on-blockchain, limites de saque e contratos financeiros atraves de uma linguagem de programacao altamente generalizada. No entanto, o protocolo Ethereum vai muito alem de apenas moeda. Os protocolos em torno de armazenamento descentralizado de arquivos, computacao descentralizada e mercados de predicao descentralizados, entre dezenas de outros conceitos, tem o potencial de aumentar substancialmente a eficiencia da industria computacional e fornecer um impulso massivo para outros protocolos peer-to-peer ao adicionar pela primeira vez uma camada economica.
Em vez de fornecer um conjunto limitado de operacoes projetadas para casos de uso especificos, o Ethereum fornece uma linguagem de programacao Turing-completa que permite aos desenvolvedores construir qualquer aplicacao que possam projetar. Quer inventar seu proprio derivativo financeiro? Criar sua propria moeda? Estabelecer um governo na blockchain? Tudo isso e trivialmente implementavel com o sistema de scripting do Ethereum. O poder da plataforma nao reside em prever quais aplicacoes serao construidas, mas em fornecer a infraestrutura fundacional que torna facil construi-las.
O conceito de uma funcao de transicao de estado arbitraria implementada pelo protocolo Ethereum fornece uma plataforma com potencial unico. Em vez de ser um protocolo fechado, de proposito unico, destinado a aplicacoes especificas em armazenamento de dados, apostas ou financas, o Ethereum e aberto por design, e acreditamos que e extremamente adequado para servir como camada fundacional para um grande numero de protocolos tanto financeiros quanto nao financeiros nos anos vindouros. As aplicacoes que serao construidas sobre o Ethereum no futuro podem ser aquelas que nem podemos imaginar hoje, e essa possibilidade aberta representa a verdadeira promessa da 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
O whitepaper do Ethereum se baseia em um extenso trabalho previo em pesquisa de criptomoedas e sistemas distribuidos. O protocolo fundacional do Bitcoin e descrito no artigo original de 2008 de Satoshi Nakamoto "Bitcoin: A Peer-to-Peer Electronic Cash System", que introduziu o conceito de moeda digital baseada em blockchain. As primeiras tentativas de estender a funcionalidade do Bitcoin incluem o Namecoin, um sistema de registro de nomes descentralizado que demonstra aplicacoes de blockchain alem da moeda, embora limitado pelas capacidades restritas de scripting do Bitcoin.
O whitepaper de colored coins propos um metodo para representar ativos alternativos na blockchain do Bitcoin "colorindo" bitcoins especificos para representar outros ativos, enquanto o Mastercoin tentou criar uma camada de protocolo sobre o Bitcoin para instrumentos financeiros mais complexos. Ambos destacaram as limitacoes de construir sobre o Bitcoin e motivaram a necessidade de uma plataforma mais flexivel. O conceito de corporacoes autonomas descentralizadas, explorado na Bitcoin Magazine, forneceu fundamentos teoricos para governanca organizacional atraves de smart contracts.
Os componentes tecnicos chave incluem verificacao de pagamento simplificada (SPV) para clientes leves, Merkle trees para verificacao eficiente de dados e Patricia tries para a representacao de estado do Ethereum. O protocolo GHOST (Greedy Heaviest Observed Subtree), descrito em um artigo de criptografia de 2013, aborda problemas de seguranca que surgem de tempos de bloco rapidos e forma a base do mecanismo de consenso do Ethereum. Essas referencias representam os fundamentos intelectuais sobre os quais o Ethereum foi construido, combinando conhecimentos de criptomoedas, sistemas distribuidos, criptografia e teoria dos jogos para criar uma plataforma blockchain de proposito geral.
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