Informe técnico de Ethereum

Este artículo introductorio fue publicado originalmente en 2013 por Vitalik Buterin, el fundador de Ethereum, antes del lanzamiento del proyecto en 2015. Vale la pena señalar que Ethereum, como muchos proyectos de software de código abierto impulsados ​​por la comunidad, ha evolucionado desde su inicio inicial.

Aunque tiene varios años, mantenemos este documento porque continúa sirviendo como una referencia útil y una representación precisa de Ethereum y su visión. Para conocer los últimos desarrollos de Ethereum y cómo se realizan los cambios en el protocolo, recomendamos esta guía .

Un contrato inteligente de próxima generación y una plataforma de aplicaciones descentralizada

El desarrollo de Bitcoin de Satoshi Nakamoto en 2009 a menudo ha sido aclamado como un desarrollo radical en dinero y moneda, siendo el primer ejemplo de un activo digital que simultáneamente no tiene respaldo o valor intrínseco y no tiene un emisor o controlador centralizado. Sin embargo, otra parte, posiblemente más importante, del experimento de Bitcoin es la tecnología blockchain subyacente como una herramienta de consenso distribuido, y la atención está comenzando a desplazarse rápidamente a este otro aspecto de Bitcoin. Las aplicaciones alternativas comúnmente citadas de la tecnología blockchain incluyen el uso de activos digitales en blockchain para representar monedas e instrumentos financieros personalizados ( monedas de colores ), la propiedad de un dispositivo físico subyacente ( propiedad inteligente), activos no fungibles como nombres de dominio (Namecoin), así como aplicaciones más complejas que implican tener activos digitales controlados directamente por un código que implementa reglas arbitrarias ( contratos inteligentes ) o incluso organizaciones autónomas descentralizadas (DAO) basadas en blockchain . Lo que Ethereum pretende proporcionar es una cadena de bloques con un lenguaje de programación Turing completo incorporado que se puede usar para crear «contratos» que se pueden usar para codificar funciones de transición de estado arbitrarias, lo que permite a los usuarios crear cualquiera de los sistemas descritos anteriormente. , así como muchos otros que aún no nos hemos imaginado, simplemente escribiendo la lógica en unas pocas líneas de código.

Introducción a Bitcoin y conceptos existentes

Historia

El concepto de moneda digital descentralizada, así como aplicaciones alternativas como registros de propiedad, ha existido durante décadas. Los protocolos anónimos de efectivo electrónico de las décadas de 1980 y 1990, en su mayoría dependientes de una primitiva criptográfica conocida como cegamiento chaumiano, proporcionaron una moneda con un alto grado de privacidad, pero los protocolos en gran medida no lograron ganar terreno debido a su dependencia de un intermediario centralizado. . En 1998, el b-money de Wei Dai se convirtió en la primera propuesta para introducir la idea de crear dinero mediante la resolución de acertijos computacionales y el consenso descentralizado, pero la propuesta era escasa en detalles sobre cómo se podría implementar el consenso descentralizado. En 2005, Hal Finney introdujo un concepto de pruebas de trabajo reutilizables, un sistema que usa ideas de b-money junto con los difíciles acertijos computacionalmente Hashcash de Adam Back para crear un concepto para una criptomoneda, pero una vez más no alcanzó el ideal al confiar en la computación confiable como backend. En 2009, Satoshi Nakamoto implementó por primera vez en la práctica una moneda descentralizada, combinando primitivas establecidas para administrar la propiedad mediante criptografía de clave pública con un algoritmo de consenso para realizar un seguimiento de quién posee las monedas, conocido como «prueba de trabajo».

El mecanismo detrás de la prueba de trabajo fue un gran avance en el espacio porque resolvió simultáneamente dos problemas. Primero, proporcionó un algoritmo de consenso simple y moderadamente efectivo, permitiendo que los nodos de la red acuerden colectivamente un conjunto de actualizaciones canónicas del estado del libro mayor de Bitcoin. En segundo lugar, proporcionó un mecanismo para permitir la libre entrada en el proceso de consenso, resolviendo el problema político de decidir quién puede influir en el consenso y, al mismo tiempo, evitar los ataques de las sibila. Lo hace sustituyendo una barrera formal a la participación, como el requisito de estar registrado como una entidad única en una lista en particular, con una barrera económica: el peso de un solo nodo en el proceso de votación por consenso es directamente proporcional a la potencia informática. que trae el nodo. Desde entonces,prueba de participación , calculando el peso de un nodo proporcional a sus tenencias de moneda y no recursos computacionales; la discusión de los méritos relativos de los dos enfoques está más allá del alcance de este documento, pero debe tenerse en cuenta que ambos enfoques pueden usarse para servir como la columna vertebral de una criptomoneda.

Aquí hay una publicación de blog de Vitalik Buterin, el fundador de Ethereum, sobre la prehistoria de Ethereum .

Bitcoin como sistema de transición estatal

Desde un punto de vista técnico, el libro mayor de una criptomoneda como Bitcoin se puede considerar como un sistema de transición de estado, donde hay un «estado» que consiste en el estado de propiedad de todos los bitcoins existentes y una «función de transición de estado» que toma un estado. y una transacción y genera un nuevo estado que es el resultado. En un sistema bancario estándar, por ejemplo, el estado es un balance general, una transacción es una solicitud para mover \ $ X de A a B, y la función de transición del estado reduce el valor en la cuenta de A en \ $ X y aumenta el valor. en la cuenta de B por \ $ X. Si la cuenta de A tiene menos de \ $ X en primer lugar, la función de transición de estado devuelve un error. Por tanto, se puede definir formalmente:

APPLY(S,TX) -> S' or ERROR

En el sistema bancario definido anteriormente:

APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }

Pero:

APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR

El «estado» en Bitcoin es la colección de todas las monedas (técnicamente, «salidas de transacciones no gastadas» o UTXO) que se han extraído y aún no se han gastado, y cada UTXO tiene una denominación y un propietario (definido por una dirección de 20 bytes que es esencialmente una clave pública criptográfica). Una transacción contiene una o más entradas, y cada entrada contiene una referencia a una UTXO existente y una firma criptográfica producida por la clave privada asociada con la dirección del propietario, y una o más salidas, y cada salida contiene una nueva UTXO que se agregará a el estado.

La función de transición de estado APPLY(S,TX) -> S'se puede definir aproximadamente de la siguiente manera:

1. Para cada entrada en TX:
   • Si el UTXO referenciado no está S, devuelve un error.
   • Si la firma proporcionada no coincide con el propietario del UTXO, devuelve un error.
2. Si la suma de las denominaciones de todas las entradas UTXO es menor que la suma de las denominaciones de todas las salidas UTXO, devuelve un error.
3. Regrese S'con todas las entradas UTXO eliminadas y todas las salidas UTXO agregadas.

La primera mitad del primer paso evita que los remitentes de transacciones gasten monedas que no existen, la segunda mitad del primer paso evita que los remitentes de transacciones gasten monedas de otras personas y el segundo paso refuerza la conservación del valor. Para usar esto para el pago, el protocolo es el siguiente. Suponga que Alice quiere enviar 11.7 BTC a Bob. En primer lugar, Alice buscará un conjunto de UTXO disponibles que posea y que asciendan al menos a 11,7 BTC. Siendo realistas, Alice no podrá obtener exactamente 11,7 BTC; digamos que lo más pequeño que puede obtener es 6 + 4 + 2 = 12. Luego crea una transacción con esas tres entradas y dos salidas. La primera salida será 11.7 BTC con la dirección de Bob como su propietario, y la segunda salida será el «cambio» restante de 0.3 BTC, siendo la propietaria la propia Alice.

Minería

Si tuviéramos acceso a un servicio centralizado confiable, este sistema sería trivial de implementar; simplemente se podría codificar exactamente como se describe, utilizando el disco duro de un servidor centralizado para realizar un seguimiento del estado. Sin embargo, con Bitcoin estamos tratando de construir un sistema monetario descentralizado, por lo que necesitaremos combinar el sistema de transición estatal con un sistema de consenso para asegurarnos de que todos estén de acuerdo con el orden de las transacciones. El proceso de consenso descentralizado de Bitcoin requiere que los nodos de la red intenten continuamente producir paquetes de transacciones llamados «bloques». La red está destinada a producir aproximadamente un bloque cada diez minutos, y cada bloque contiene una marca de tiempo, un nonce, una referencia a (es decir. hash de) el bloque anterior y una lista de todas las transacciones que han tenido lugar desde el bloque anterior. Con el tiempo, esto crea una «cadena de bloques» persistente y en constante crecimiento que se actualiza constantemente para representar el estado más reciente del libro mayor de Bitcoin.

El algoritmo para comprobar si un bloque es válido, expresado en este paradigma, es el siguiente:

1. Compruebe si el bloque anterior al que hace referencia el bloque existe y es válido.
2. Compruebe que la marca de tiempo del bloque sea mayor que la del bloque anterior  y menos de 2 horas en el futuro
3. Compruebe que la prueba de trabajo en el bloque sea válida.
4. Sea S[0]el estado al final del bloque anterior.
5. Supongamos que TXes la lista de transacciones del bloque con ntransacciones. Para todo iincluido 0...n-1, establezca S[i+1] = APPLY(S[i],TX[i])Si alguna aplicación devuelve un error, salga y devuelva falso.
6. Devuelve verdadero y registra S[n]como el estado al final de este bloque.

Esencialmente, cada transacción en el bloque debe proporcionar una transición de estado válida desde lo que era el estado canónico antes de que se ejecutara la transacción a un nuevo estado. Tenga en cuenta que el estado no está codificado en el bloque de ninguna manera; es puramente una abstracción que debe recordar el nodo de validación y solo se puede calcular (de forma segura) para cualquier bloque comenzando desde el estado de génesis y aplicando secuencialmente cada transacción en cada bloque. Además, tenga en cuenta que el orden en el que el minero incluye transacciones en el bloque es importante; si hay dos transacciones A y B en un bloque de modo que B gasta un UTXO creado por A, entonces el bloque será válido si A viene antes que B pero no de otra manera.

La única condición de validez presente en la lista anterior que no se encuentra en otros sistemas es el requisito de «prueba de trabajo». La condición precisa es que el hash SHA256 doble de cada bloque, tratado como un número de 256 bits, debe ser menor que un objetivo ajustado dinámicamente, que en el momento de escribir este artículo es aproximadamente 2 ¹⁸⁷ . El propósito de esto es hacer que la creación de bloques sea computacionalmente «difícil», evitando así que los atacantes de Sybil rehagan toda la cadena de bloques a su favor. Debido a que SHA256 está diseñado para ser una función pseudoaleatoria completamente impredecible, la única forma de crear un bloque válido es simplemente prueba y error, incrementando repetidamente el nonce y viendo si el nuevo hash coincide.

En el objetivo actual de ~ 2 ¹⁸⁷ , la red debe realizar un promedio de ~ 2 ⁶⁹ intentos antes de encontrar un bloque válido; en general, el objetivo es recalibrado por la red cada 2016 bloques, de manera que en promedio algún nodo de la red produce un nuevo bloque cada diez minutos. Para compensar a los mineros por este trabajo computacional, el minero de cada bloque tiene derecho a incluir una transacción que se otorgue a sí mismos 12.5 BTC de la nada. Además, si alguna transacción tiene una denominación total más alta en sus entradas que en sus salidas, la diferencia también va al minero como una «tarifa de transacción». Por cierto, este es también el único mecanismo mediante el cual se emiten BTC; el estado de génesis no contenía monedas en absoluto.

Para comprender mejor el propósito de la minería, examinemos qué sucede en el caso de un atacante malintencionado. Dado que se sabe que la criptografía subyacente de Bitcoin es segura, el atacante apuntará a la única parte del sistema Bitcoin que no está protegida directamente por la criptografía: el orden de las transacciones. La estrategia del atacante es simple:

1. Envíe 100 BTC a un comerciante a cambio de algún producto (preferiblemente un bien digital de entrega rápida)
2. Espere la entrega del producto
3. Producir otra transacción enviándose los mismos 100 BTC a sí mismo
4. Trate de convencer a la red de que su transacción para sí mismo fue la primera.

Una vez que se ha realizado el paso (1), después de unos minutos, algún minero incluirá la transacción en un bloque, digamos el bloque número 270. Después de aproximadamente una hora, se habrán agregado cinco bloques más a la cadena después de ese bloque, con cada uno de esos bloques que apuntan indirectamente a la transacción y por lo tanto la «confirman». En este punto, el comerciante aceptará el pago como finalizado y entregará el producto; dado que asumimos que se trata de un bien digital, la entrega es instantánea. Ahora, el atacante crea otra transacción enviándose los 100 BTC a sí mismo. Si el atacante simplemente lo libera, la transacción no se procesará; los mineros intentarán correr APPLY(S,TX)y notar queTXconsume un UTXO que ya no está en el estado. Entonces, en cambio, el atacante crea una «bifurcación» de la cadena de bloques, comenzando por extraer otra versión del bloque 270 que apunta al mismo bloque 269 como padre, pero con la nueva transacción en lugar de la anterior. Debido a que los datos del bloque son diferentes, esto requiere rehacer la prueba de trabajo. Además, la nueva versión del bloque 270 del atacante tiene un hash diferente, por lo que los bloques originales 271 a 275 no «apuntan» a él; por lo tanto, la cadena original y la nueva cadena del atacante están completamente separadas. La regla es que en una bifurcación se considera que la cadena de bloques más larga es la verdad, por lo que los mineros legítimos trabajarán en la cadena 275 mientras el atacante solo está trabajando en la cadena 270. Para que el atacante haga que su blockchain sea la más larga,

Árboles Merkle

Izquierda: basta con presentar solo un pequeño número de nodos en un árbol de Merkle para dar una prueba de la validez de una rama.

Derecha: cualquier intento de cambiar cualquier parte del árbol Merkle eventualmente conducirá a una inconsistencia en algún lugar de la cadena.

Una característica de escalabilidad importante de Bitcoin es que el bloque se almacena en una estructura de datos de varios niveles. El «hash» de un bloque es en realidad solo el hash del encabezado del bloque, una pieza de datos de aproximadamente 200 bytes que contiene la marca de tiempo, el nonce, el hash del bloque anterior y el hash raíz de una estructura de datos llamada árbol Merkle que almacena todas las transacciones. en el bloque. Un árbol Merkle es un tipo de árbol binario, compuesto por un conjunto de nodos con una gran cantidad de nodos hoja en la parte inferior del árbol que contiene los datos subyacentes, un conjunto de nodos intermedios donde cada nodo es el hash de sus dos hijos, y finalmente un único nodo raíz, también formado por el hash de sus dos hijos, que representa la «parte superior» del árbol. El propósito del árbol de Merkle es permitir que los datos de un bloque se entreguen por partes: un nodo puede descargar solo el encabezado de un bloque de una fuente, la pequeña parte del árbol relevante para ellos de otra fuente y aún estar seguro de que todos los datos son correctos. La razón por la que esto funciona es que los hashes se propagan hacia arriba: si un usuario malintencionado intenta intercambiar una transacción falsa en la parte inferior de un árbol Merkle, este cambio provocará un cambio en el nodo de arriba y luego un cambio en el nodo de arriba. , finalmente cambiando la raíz del árbol y por lo tanto el hash del bloque, haciendo que el protocolo lo registre como un bloque completamente diferente (casi con certeza con una prueba de trabajo inválida).

El protocolo del árbol de Merkle es posiblemente esencial para la sostenibilidad a largo plazo. Un «nodo completo» en la red Bitcoin, uno que almacena y procesa la totalidad de cada bloque, ocupa alrededor de 15 GB de espacio en disco en la red Bitcoin en abril de 2014 y está creciendo en más de un gigabyte por mes. Actualmente, esto es viable para algunas computadoras de escritorio y no para teléfonos, y más adelante, en el futuro, solo las empresas y los aficionados podrán participar. Un protocolo conocido como «verificación de pago simplificado» (SPV) permite que exista otra clase de nodos, llamados «nodos ligeros», que descargan los encabezados de bloque, verifican la prueba de trabajo en los encabezados de bloque y luego descargan solo las «ramas «asociado con transacciones que son relevantes para ellos.

Aplicaciones alternativas de blockchain

La idea de tomar la idea subyacente de la cadena de bloques y aplicarla a otros conceptos también tiene una larga historia. En 1998, Nick Szabo presentó el concepto de títulos de propiedad seguros con autoridad de propietario , un documento que describe cómo «los nuevos avances en la tecnología de bases de datos replicadas» permitirán un sistema basado en blockchain para almacenar un registro de quién posee qué tierra, creando un marco elaborado que incluye conceptos tales como propiedad, posesión adversa e impuesto territorial georgiano. Sin embargo, lamentablemente no había disponible un sistema de base de datos replicado efectivo en ese momento, por lo que el protocolo nunca se implementó en la práctica. Sin embargo, después de 2009, una vez que se desarrolló el consenso descentralizado de Bitcoin, comenzaron a surgir rápidamente una serie de aplicaciones alternativas.

• Namecoin : creado en 2010, Namecoin se describe mejor como una base de datos de registro de nombres descentralizada. En protocolos descentralizados como Tor, Bitcoin y BitMessage, es necesario que haya alguna forma de identificar cuentas para que otras personas puedan interactuar con ellas, pero en todas las soluciones existentes, el único tipo de identificador disponible es un hash pseudoaleatorio como 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. Idealmente, a uno le gustaría poder tener una cuenta con un nombre como «george». Sin embargo, el problema es que si una persona puede crear una cuenta llamada «george», entonces otra persona puede usar el mismo proceso para registrar a «george» y hacerse pasar por él. La única solución es un paradigma de primero en presentar, donde el primer registrador tiene éxito y el segundo falla, un problema que se adapta perfectamente al protocolo de consenso de Bitcoin. Namecoin es la implementación más antigua y exitosa de un sistema de registro de nombres que utiliza tal idea.
• Monedas de colores : el propósito de las monedas de colores es servir como protocolo para permitir a las personas crear sus propias monedas digitales o, en el importante caso trivial de una moneda con una unidad, tokens digitales, en la cadena de bloques de Bitcoin. En el protocolo de monedas de colores, uno «emite» una nueva moneda asignando públicamente un color a un UTXO de Bitcoin específico, y el protocolo define de forma recursiva el color de otros UTXO para que sea el mismo que el color de las entradas que la transacción que los creó gastó. (se aplican algunas reglas especiales en el caso de entradas de colores mezclados). Esto permite a los usuarios mantener carteras que contienen solo UTXO de un color específico y enviarlas como bitcoins normales, retrocediendo a través de la cadena de bloques para determinar el color de cualquier UTXO que reciben.
• Metacoins : la idea detrás de una metacoin es tener un protocolo que viva encima de Bitcoin, utilizando transacciones de Bitcoin para almacenar transacciones de metacoin pero con una función de transición de estado diferente APPLY'. Debido a que el protocolo de metacoin no puede evitar que aparezcan transacciones de metacoin no válidas en la cadena de bloques de Bitcoin, se agrega una regla que indica que si APPLY'(S,TX)devuelve un error, el protocolo predeterminado esAPPLY'(S,TX) = S. Esto proporciona un mecanismo sencillo para crear un protocolo de criptomoneda arbitrario, potencialmente con características avanzadas que no se pueden implementar dentro del propio Bitcoin, pero con un costo de desarrollo muy bajo, ya que las complejidades de la minería y las redes ya están manejadas por el protocolo de Bitcoin. Las metacoins se han utilizado para implementar algunas clases de contratos financieros, registro de nombres e intercambio descentralizado.

Por lo tanto, en general, hay dos enfoques para construir un protocolo de consenso: construir una red independiente y construir un protocolo sobre Bitcoin. El primer enfoque, aunque razonablemente exitoso en el caso de aplicaciones como Namecoin, es difícil de implementar; cada implementación individual necesita arrancar una cadena de bloques independiente, así como construir y probar todo el código de red y transición de estado necesario. Además, predecimos que el conjunto de aplicaciones para la tecnología de consenso descentralizada seguirá una distribución de la ley de potencia donde la gran mayoría de las aplicaciones serían demasiado pequeñas para justificar su propia cadena de bloques, y observamos que existen grandes clases de aplicaciones descentralizadas, particularmente autónomas descentralizadas. organizaciones, que necesitan interactuar entre sí.

El enfoque basado en Bitcoin, por otro lado, tiene el defecto de que no hereda las funciones de verificación de pago simplificadas de Bitcoin. SPV funciona para Bitcoin porque puede usar la profundidad de la cadena de bloques como un proxy de validez; en algún momento, una vez que los antepasados ​​de una transacción se remontan lo suficiente, es seguro decir que eran legítimamente parte del estado. Los metaprotocolos basados ​​en blockchain, por otro lado, no pueden obligar al blockchain a no incluir transacciones que no son válidas dentro del contexto de sus propios protocolos. Por lo tanto, una implementación de metaprotocolo SPV completamente segura necesitaría escanear hacia atrás hasta el comienzo de la cadena de bloques de Bitcoin para determinar si ciertas transacciones son válidas o no. Actualmente, todas las implementaciones «ligeras» de metaprotocolos basados ​​en Bitcoin se basan en un servidor confiable para proporcionar los datos,

Scripting

Incluso sin ninguna extensión, el protocolo de Bitcoin en realidad facilita una versión débil de un concepto de «contratos inteligentes». UTXO en Bitcoin puede ser propiedad no solo de una clave pública, sino también de un script más complicado expresado en un lenguaje de programación simple basado en pila. En este paradigma, una transacción que gasta UTXO debe proporcionar datos que satisfagan el guión. De hecho, incluso el mecanismo básico de propiedad de la clave pública se implementa a través de un script: el script toma una firma de curva elíptica como entrada, la verifica con la transacción y la dirección que posee el UTXO, y devuelve 1 si la verificación es exitosa y 0 en caso contrario. Existen otros scripts más complicados para varios casos de uso adicionales. Por ejemplo, uno puede construir un script que requiera firmas de dos de tres claves privadas dadas para validar («

Sin embargo, el lenguaje de secuencias de comandos implementado en Bitcoin tiene varias limitaciones importantes:

• Falta de completitud de Turing , es decir, si bien existe un gran subconjunto de cómputo que admite el lenguaje de scripting de Bitcoin, no lo admite casi todo. La categoría principal que falta son los bucles. Esto se hace para evitar bucles infinitos durante la verificación de la transacción; en teoría, es un obstáculo superable para los programadores de scripts, ya que cualquier bucle puede simularse simplemente repitiendo el código subyacente muchas veces con una declaración if, pero conduce a scripts que son muy ineficientes en cuanto al espacio. Por ejemplo, implementar un algoritmo de firma de curva elíptica alternativo probablemente requeriría 256 rondas de multiplicación repetidas, todas incluidas individualmente en el código.
• Ceguera al valor : no hay forma de que un script UTXO proporcione un control detallado sobre la cantidad que se puede retirar. Por ejemplo, un caso de uso poderoso de un contrato de Oracle sería un contrato de cobertura, donde A y B ingresan \ $ 1000 en BTC y después de 30 días el script envía \ $ 1000 en BTC a A y el resto a B. Esto sería requieren un oráculo para determinar el valor de 1 BTC en USD, pero incluso entonces es una mejora masiva en términos de confianza y requisitos de infraestructura sobre las soluciones totalmente centralizadas que están disponibles ahora. Sin embargo, debido a que los UTXO son todo o nada, la única forma de lograrlo es a través del truco muy ineficiente de tener muchos UTXO de diferentes denominaciones (por ejemplo, un UTXO de 2 ^k por cada k hasta 30) y tener O elegir cuál UTXO para enviar a A y cuál a B.
• Falta de estado : un UTXO puede gastarse o no gastarse ; no hay oportunidad para contratos o guiones de múltiples etapas que mantengan cualquier otro estado interno más allá de eso. Esto dificulta la realización de contratos de opciones de varias etapas, ofertas de intercambio descentralizadas o protocolos de compromiso criptográfico de dos etapas (necesarios para obtener recompensas computacionales seguras). También significa que UTXO solo se puede usar para construir contratos simples y únicos y no contratos «con estado» más complejos, como organizaciones descentralizadas, y dificulta la implementación de metaprotocolos. El estado binario combinado con la ceguera al valor también significa que otra aplicación importante, los límites de retiro, es imposible.
• Ceguera de blockchain: los UTXO son ciegos a los datos de blockchain como el nonce, la marca de tiempo y el hash del bloque anterior. Esto limita severamente las aplicaciones en los juegos de azar y en varias otras categorías, al privar al lenguaje de programación de una fuente potencialmente valiosa de aleatoriedad.

Por lo tanto, vemos tres enfoques para crear aplicaciones avanzadas además de la criptomoneda: crear una nueva cadena de bloques, usar secuencias de comandos sobre Bitcoin y crear un metaprotocolo sobre Bitcoin. La creación de una nueva cadena de bloques permite una libertad ilimitada para crear un conjunto de funciones, pero a costa del tiempo de desarrollo, el esfuerzo inicial y la seguridad. El uso de secuencias de comandos es fácil de implementar y estandarizar, pero sus capacidades son muy limitadas, y los metaprotocolos, aunque fáciles, adolecen de fallas en la escalabilidad. Con Ethereum, tenemos la intención de construir un marco alternativo que proporcione ganancias aún mayores en la facilidad de desarrollo, así como propiedades de clientes ligeros aún más fuertes, mientras que al mismo tiempo permite que las aplicaciones compartan un entorno económico y la seguridad de la cadena de bloques.

Ethereum

La intención de Ethereum es crear un protocolo alternativo para crear aplicaciones descentralizadas, proporcionando un conjunto diferente de compensaciones que creemos que serán muy útiles para una gran clase de aplicaciones descentralizadas, con especial énfasis en situaciones en las que el tiempo de desarrollo es rápido, la seguridad para pequeñas y las aplicaciones poco utilizadas y la capacidad de las diferentes aplicaciones para interactuar de manera muy eficiente son importantes. Ethereum hace esto construyendo lo que es esencialmente la última capa fundamental abstracta: una cadena de bloques con un lenguaje de programación Turing completo integrado, que permite a cualquiera escribir contratos inteligentes y aplicaciones descentralizadas donde pueden crear sus propias reglas arbitrarias para la propiedad, formatos de transacción y funciones de transición de estado. Una versión básica de Namecoin se puede escribir en dos líneas de código, y otros protocolos como monedas y sistemas de reputación se pueden construir en menos de veinte. Los contratos inteligentes, las «cajas» criptográficas que contienen valor y solo lo desbloquean si se cumplen ciertas condiciones, también se pueden construir en la parte superior de la plataforma, con mucho más poder que el que ofrece el scripting de Bitcoin debido a los poderes adicionales de la completitud de Turing, conciencia de valor, conciencia de blockchain y estado.

Filosofía

El diseño detrás de Ethereum está destinado a seguir los siguientes principios:

1. Simplicidad : el protocolo Ethereum debería ser lo más simple posible, incluso a costa de cierto almacenamiento de datos o ineficiencia de tiempo. Idealmente, un programador promedio debería poder seguir e implementar toda la especificación,  para realizar plenamente el potencial democratizador sin precedentes que aporta la criptomoneda y promover la visión de Ethereum como un protocolo abierto a todos. Cualquier optimización que agregue complejidad no debe incluirse a menos que esa optimización proporcione un beneficio muy sustancial.
2. Universalidad : una parte fundamental de la filosofía de diseño de Ethereum es que Ethereum no tiene «características».  En cambio, Ethereum proporciona un lenguaje de scripting interno de Turing completo, que un programador puede usar para construir cualquier contrato inteligente o tipo de transacción que pueda definirse matemáticamente. ¿Quiere inventar su propio derivado financiero? Con Ethereum, puedes. ¿Quiere hacer su propia moneda? Configúrelo como un contrato Ethereum. ¿Quiere configurar un Daemon o Skynet a gran escala? Es posible que deba tener algunos miles de contratos entrelazados y asegúrese de alimentarlos generosamente para hacer eso, pero nada lo detiene con Ethereum al alcance de su mano.
3. Modularidad : las partes del protocolo Ethereum deben diseñarse para que sean lo más modulares y separables posible. En el transcurso del desarrollo, nuestro objetivo es crear un programa en el que, si se hiciera una pequeña modificación del protocolo en un lugar, la pila de aplicaciones continuaría funcionando sin más modificaciones. Innovaciones como Ethash (ver el Apéndice de Yellow Paper o el artículo wiki ), árboles Patricia modificados ( Yellow Paper , wiki ) y RLP ( YP , wiki) deben implementarse, y se implementan, como bibliotecas independientes con funciones completas. Esto es así que, aunque se usan en Ethereum, incluso si Ethereum no requiere ciertas características, dichas características también se pueden usar en otros protocolos. El desarrollo de Ethereum debe realizarse al máximo para beneficiar a todo el ecosistema de criptomonedas, no solo a sí mismo.
4. Agilidad : los detalles del protocolo Ethereum no están escritos en piedra. Aunque seremos extremadamente juiciosos al hacer modificaciones a las construcciones de alto nivel, por ejemplo, con la hoja de ruta de fragmentación , abstrayendo la ejecución, con solo la disponibilidad de datos consagrada en consenso. Las pruebas computacionales más adelante en el proceso de desarrollo pueden llevarnos a descubrir que ciertas modificaciones, por ejemplo, en la arquitectura del protocolo o en la Máquina Virtual Ethereum (EVM), mejorarán sustancialmente la escalabilidad o la seguridad. Si se encuentran esas oportunidades, las aprovecharemos.
5. No discriminación y no censura : el protocolo no debe intentar restringir o prevenir activamente categorías específicas de uso. Todos los mecanismos reguladores del protocolo deben diseñarse para regular directamente el daño y no intentar oponerse a aplicaciones indeseables específicas. Un programador puede incluso ejecutar un script de bucle infinito encima de Ethereum mientras esté dispuesto a seguir pagando la tarifa de transacción por paso computacional.

Cuentas de Ethereum

En Ethereum, el estado se compone de objetos llamados «cuentas», cada cuenta tiene una dirección de 20 bytes y las transiciones de estado son transferencias directas de valor e información entre cuentas. Una cuenta de Ethereum contiene cuatro campos:

• El nonce , un contador que se usa para asegurarse de que cada transacción solo se pueda procesar una vez
• El saldo de ether actual de la cuenta
• El código de contrato de la cuenta , si está presente
• El almacenamiento de la cuenta (vacío por defecto)

«Ether» es el principal combustible criptográfico interno de Ethereum y se utiliza para pagar tarifas de transacción. En general, hay dos tipos de cuentas: cuentas de propiedad externa , controladas por claves privadas, y cuentas de contrato , controladas por su código de contrato. Una cuenta de propiedad externa no tiene código, y uno puede enviar mensajes desde una cuenta de propiedad externa creando y firmando una transacción; en una cuenta de contrato, cada vez que la cuenta de contrato recibe un mensaje, su código se activa, lo que le permite leer y escribir en el almacenamiento interno y enviar otros mensajes o crear contratos a su vez.

Tenga en cuenta que los «contratos» en Ethereum no deben verse como algo que deba «cumplirse» o «cumplirse»; más bien, son más como «agentes autónomos» que viven dentro del entorno de ejecución de Ethereum, siempre ejecutando una pieza de código específica cuando un mensaje o transacción los «empujan», y tienen control directo sobre su propio saldo de éter y su propia clave / value store para realizar un seguimiento de las variables persistentes.

Mensajes y transacciones

El término «transacción» se usa en Ethereum para referirse al paquete de datos firmado que almacena un mensaje que se enviará desde una cuenta de propiedad externa. Las transacciones contienen:

• El destinatario del mensaje
• Una firma que identifica al remitente
• La cantidad de éter para transferir del remitente al destinatario
• Un campo de datos opcional
• Un STARTGASvalor, que representa el número máximo de pasos computacionales que la ejecución de la transacción puede tomar
• Un GASPRICEvalor, que representa la tarifa que paga el remitente por paso de cálculo.

Los tres primeros son campos estándar que se esperan en cualquier criptomoneda. El campo de datos no tiene función por defecto, pero la máquina virtual tiene un código de operación que un contrato puede usar para acceder a los datos; como un ejemplo de caso de uso, si un contrato funciona como un servicio de registro de dominio en blockchain, entonces es posible que desee interpretar que los datos que se le pasan contienen dos «campos», el primer campo es un dominio para registrar y el segundo siendo el campo la dirección IP para registrarlo. El contrato leería estos valores de los datos del mensaje y los guardaría adecuadamente.

El STARTGASyGASPRICELos campos son cruciales para el modelo anti-denegación de servicio de Ethereum. Para evitar bucles infinitos accidentales u hostiles u otro desperdicio computacional en el código, se requiere que cada transacción establezca un límite en la cantidad de pasos computacionales de ejecución de código que puede usar. La unidad fundamental de cálculo es «gas»; Por lo general, un paso computacional cuesta 1 gas, pero algunas operaciones cuestan cantidades más altas de gas porque son más costosas computacionalmente o aumentan la cantidad de datos que deben almacenarse como parte del estado. También hay una tarifa de 5 gas por cada byte en los datos de la transacción. La intención del sistema de tarifas es exigir que un atacante pague proporcionalmente por cada recurso que consumen, incluidos el cálculo, el ancho de banda y el almacenamiento; por lo tanto,

Mensajes

Los contratos tienen la capacidad de enviar «mensajes» a otros contratos. Los mensajes son objetos virtuales que nunca se serializan y existen solo en el entorno de ejecución de Ethereum. Un mensaje contiene:

• El remitente del mensaje (implícito)
• El destinatario del mensaje
• La cantidad de éter para transferir junto con el mensaje.
• Un campo de datos opcional
• Un STARTGASvalor

Esencialmente, un mensaje es como una transacción, excepto que es producido por un contrato y no por un actor externo. Se produce un mensaje cuando un contrato en ejecución de código ejecuta el CALLcódigo de operación, que produce y ejecuta un mensaje. Como una transacción, un mensaje lleva a la cuenta del destinatario ejecutando su código. Por lo tanto, los contratos pueden tener relaciones con otros contratos exactamente de la misma manera que los actores externos.

Tenga en cuenta que la asignación de gas asignada por una transacción o contrato se aplica al gas total consumido por esa transacción y todas las sub-ejecuciones. Por ejemplo, si un actor externo A envía una transacción a B con 1000 gas y B consume 600 gas antes de enviar un mensaje a C, y la ejecución interna de C consume 300 gas antes de regresar, entonces B puede gastar otros 100 gas antes de correr. sin gasolina.

Función de transición del estado de Ethereum

La función de transición de estado de Ethereum APPLY(S,TX) -> S'se puede definir de la siguiente manera:

1. Compruebe si la transacción está bien formada (es decir, tiene el número correcto de valores), la firma es válida y el nonce coincide con el nonce en la cuenta del remitente. Si no, devuelve un error.
2. Calcule la tarifa de transacción como STARTGAS * GASPRICEy determine la dirección de envío a partir de la firma. Reste la tarifa del saldo de la cuenta del remitente e incremente el nonce del remitente. Si no hay suficiente saldo para gastar, devuelve un error.
3. Inicialice GAS = STARTGASy retire una cierta cantidad de gas por byte para pagar los bytes en la transacción.
4. Transfiera el valor de la transacción de la cuenta del remitente a la cuenta receptora. Si la cuenta receptora aún no existe, créela. Si la cuenta receptora es un contrato, ejecute el código del contrato hasta su finalización o hasta que la ejecución se quede sin gas.
5. Si la transferencia de valor falló porque el remitente no tenía suficiente dinero, o la ejecución del código se quedó sin combustible, revierte todos los cambios de estado excepto el pago de las tarifas y agrega las tarifas a la cuenta del minero.
6. De lo contrario, reembolse las tarifas por todo el gas restante al remitente y envíe las tarifas pagadas por el gas consumido al minero.

Por ejemplo, suponga que el código del contrato es:

if !self.storage[calldataload(0)]:
    self.storage[calldataload(0)] = calldataload(32)

Tenga en cuenta que, en realidad, el código del contrato está escrito en el código EVM de bajo nivel; este ejemplo está escrito en Serpent, uno de nuestros lenguajes de alto nivel, para mayor claridad, y se puede compilar en código EVM. Suponga que el almacenamiento del contrato comienza vacío y se envía una transacción con un valor de 10 éter, 2000 gas, 0,001 precio de gas éter y 64 bytes de datos, con los bytes 0-31 que representan el número 2y los bytes 32-63 que representan la cadena CHARLIE. El proceso para la función de transición de estado en este caso es el siguiente:

1. Compruebe que la transacción sea válida y esté bien formada.
2. Compruebe que el remitente de la transacción tiene al menos 2000 * 0,001 = 2 éter. Si es así, reste 2 éter de la cuenta del remitente.
3. Inicializar gas = 2000; Suponiendo que la transacción tiene 170 bytes de longitud y la tarifa de bytes es 5, reste 850 para que queden 1150 de gas.
4. Reste 10 éter más de la cuenta del remitente y agréguelo a la cuenta del contrato.
5. Ejecute el código. En este caso, esto es simple: verifica si 2se usa el almacenamiento en el índice del contrato , se da cuenta de que no lo es y, por lo tanto, establece el almacenamiento en el índice 2en el valor CHARLIE. Suponga que esto requiere 187 gas, por lo que la cantidad restante de gas es 1150 – 187 = 963
6. Agregue 963 * 0.001 = 0.963 éter de nuevo a la cuenta del remitente y devuelva el estado resultante.

Si no hubiera ningún contrato en el extremo receptor de la transacción, entonces la tarifa total de la transacción sería simplemente igual a la proporcionada GASPRICEmultiplicada por la longitud de la transacción en bytes, y los datos enviados junto con la transacción serían irrelevantes.

Tenga en cuenta que los mensajes funcionan de manera equivalente a las transacciones en términos de reversiones: si la ejecución de un mensaje se agota, entonces la ejecución de ese mensaje y todas las demás ejecuciones desencadenadas por esa ejecución se revierten, pero las ejecuciones principales no necesitan revertirse. Esto significa que es «seguro» que un contrato cancele otro contrato, ya que si A llama a B con G gas, entonces se garantiza que la ejecución de A perderá como máximo G gas. Finalmente, tenga en cuenta que existe un código de operación CREATE, que crea un contrato; su mecánica de ejecución es generalmente similar a CALL, con la excepción de que el resultado de la ejecución determina el código de un contrato recién creado.

Ejecución de código

El código en los contratos de Ethereum está escrito en un lenguaje de código de bytes de bajo nivel, basado en pilas, denominado «código de máquina virtual Ethereum» o «código EVM». El código consta de una serie de bytes, donde cada byte representa una operación. En general, la ejecución del código es un bucle infinito que consiste en realizar repetidamente la operación en el contador del programa actual (que comienza en cero) y luego incrementar el contador del programa en uno, hasta llegar al final del código o un error o STOPo RETURNse detecta instrucción. Las operaciones tienen acceso a tres tipos de espacio en el que almacenar datos:

• La pila , un contenedor de último en entrar, primero en salir al que se pueden empujar y saltar valores
• Memoria , una matriz de bytes infinitamente expandible
• El almacenamiento a largo plazo del contrato , un almacén clave / de valor. A diferencia de la pila y la memoria, que se restablecen después de que finaliza el cálculo, el almacenamiento persiste a largo plazo.

El código también puede acceder al valor, el remitente y los datos del mensaje entrante, así como los datos del encabezado del bloque, y el código también puede devolver una matriz de bytes de datos como salida.

El modelo de ejecución formal del código EVM es sorprendentemente simple. Mientras se ejecuta la máquina virtual Ethereum, la tupla puede definir su estado computacional completo (block_state, transaction, message, code, memory, stack, pc, gas), donde block_statees el estado global que contiene todas las cuentas e incluye saldos y almacenamiento. Al comienzo de cada ronda de ejecución, la instrucción actual se encuentra tomando el pc-ésimo byte de code(o 0 si pc >= len(code)), y cada instrucción tiene su propia definición en términos de cómo afecta la tupla. Por ejemplo, ADDsaca dos elementos de la pila y empuja su suma, reduce gasen 1 e incrementa pcen 1, ySSTOREsaca los dos elementos superiores de la pila e inserta el segundo elemento en el almacenamiento del contrato en el índice especificado por el primer elemento. Aunque hay muchas formas de optimizar la ejecución de la máquina virtual Ethereum a través de la compilación justo a tiempo, se puede realizar una implementación básica de Ethereum en unos pocos cientos de líneas de código.

Blockchain y Minería

La cadena de bloques Ethereum es similar en muchos aspectos a la cadena de bloques de Bitcoin, aunque tiene algunas diferencias. La principal diferencia entre Ethereum y Bitcoin con respecto a la arquitectura blockchain es que, a diferencia de Bitcoin (que solo contiene una copia de la lista de transacciones), los bloques Ethereum contienen una copia tanto de la lista de transacciones como del estado más reciente. Aparte de eso, otros dos valores, el número de bloque y la dificultad, también se almacenan en el bloque. El algoritmo básico de validación de bloques en Ethereum es el siguiente:

1. Compruebe si el bloque anterior al que se hace referencia existe y es válido.
2. Compruebe que la marca de tiempo del bloque sea mayor que la del bloque anterior al que se hace referencia y menos de 15 minutos en el futuro
3. Compruebe que el número de bloque, la dificultad, la raíz de la transacción, la raíz del tío y el límite de gas (varios conceptos específicos de Ethereum de bajo nivel) sean válidos.
4. Compruebe que la prueba de trabajo en el bloque sea válida.
5. Sea S[0]el estado al final del bloque anterior.
6. Sea TXla lista de transacciones del bloque, con ntransacciones. Para todos ien 0...n-1, juego S[i+1] = APPLY(S[i],TX[i]). Si alguna aplicación devuelve un error, o si el gas total consumido en el bloque hasta este punto supera el GASLIMIT, devuelve un error.
7. Déjelo S_FINALestar S[n], pero agregando la recompensa en bloque pagada al minero.
8. Compruebe si la raíz del árbol Merkle del estado S_FINALes igual a la raíz del estado final proporcionada en el encabezado del bloque. Si es así, el bloque es válido; de lo contrario, no es válido.

El enfoque puede parecer muy ineficiente a primera vista, porque necesita almacenar el estado completo con cada bloque, pero en realidad la eficiencia debería ser comparable a la de Bitcoin. La razón es que el estado se almacena en la estructura del árbol y, después de cada bloque, solo es necesario cambiar una pequeña parte del árbol. Por lo tanto, en general, entre dos bloques adyacentes, la gran mayoría del árbol debería ser el mismo y, por lo tanto, los datos se pueden almacenar una vez y hacer referencia a ellos dos veces utilizando punteros (es decir, hashes de subárboles). Un tipo especial de árbol conocido como «árbol Patricia» se utiliza para lograr esto, incluida una modificación al concepto de árbol Merkle que permite insertar y eliminar nodos, y no solo cambiarlos, de manera eficiente. Además, debido a que toda la información del estado es parte del último bloque,

Una pregunta frecuente es «dónde» se ejecuta el código de contrato, en términos de hardware físico. Esto tiene una respuesta simple: el proceso de ejecutar el código del contrato es parte de la definición de la función de transición de estado, que es parte del algoritmo de validación del bloque, por lo que si se agrega una transacción al bloque B, se ejecutará la ejecución del código generado por esa transacción. por todos los nodos, ahora y en el futuro, que descarguen y validen el bloque B.

Aplicaciones

En general, hay tres tipos de aplicaciones además de Ethereum. La primera categoría son las aplicaciones financieras, que brindan a los usuarios formas más eficaces de administrar y celebrar contratos utilizando su dinero. Esto incluye sub-monedas, derivados financieros, contratos de cobertura, carteras de ahorros, testamentos y, en última instancia, incluso algunas clases de contratos de trabajo a gran escala. La segunda categoría son las aplicaciones semifinancieras, en las que hay dinero de por medio, pero también hay un lado no monetario importante de lo que se está haciendo; un ejemplo perfecto son las recompensas autoaplicables por soluciones a problemas computacionales. Finalmente, existen aplicaciones como la votación en línea y la gobernanza descentralizada que no son financieras en absoluto.

Sistemas de fichas

Los sistemas de tokens en blockchain tienen muchas aplicaciones que van desde sub-monedas que representan activos como USD u oro hasta acciones de la empresa, tokens individuales que representan propiedad inteligente, cupones seguros e infalsificables e incluso sistemas de tokens sin vínculos con el valor convencional en absoluto, utilizados como punto. sistemas de incentivación. Los sistemas de tokens son sorprendentemente fáciles de implementar en Ethereum. El punto clave a entender es que una moneda, o sistema de fichas, es fundamentalmente una base de datos con una operación: restar X unidades de A y dar X unidades a B, con la condición de que (1) A tenía al menos X unidades antes de la transacción. y (2) la transacción es aprobada por A. Todo lo que se necesita para implementar un sistema de tokens es implementar esta lógica en un contrato.

El código básico para implementar un sistema de tokens en Serpent tiene el siguiente aspecto:

def send(to, value):
    if self.storage[msg.sender] >= value:
        self.storage[msg.sender] = self.storage[msg.sender] - value
        self.storage[to] = self.storage[to] + value

Esto es esencialmente una implementación literal de la función de transición de estado del «sistema bancario» descrita más arriba en este documento. Es necesario agregar algunas líneas adicionales de código para proporcionar el paso inicial de distribución de las unidades monetarias en primer lugar y algunos otros casos extremos, e idealmente se agregaría una función para permitir que otros contratos consulten el saldo de una dirección . Pero eso es todo lo que hay que hacer. En teoría, los sistemas de tokens basados ​​en Ethereum que actúan como sub-monedas pueden incluir potencialmente otra característica importante de la que carecen las meta-monedas basadas en Bitcoin en cadena: la capacidad de pagar tarifas de transacción directamente en esa moneda. La forma en que esto se implementaría es que el contrato mantendría un saldo de ether con el que reembolsaría el ether utilizado para pagar las tarifas al remitente, y recargaría este saldo recolectando las unidades monetarias internas que recibe en tarifas y revendiéndolas en una subasta constante. Por lo tanto, los usuarios necesitarían «activar» sus cuentas con ether, pero una vez que el ether esté allí, sería reutilizable porque el contrato lo reembolsaría cada vez.

Derivados financieros y divisas de valor estable

Los derivados financieros son la aplicación más común de un «contrato inteligente» y una de las más sencillas de implementar en el código. El principal desafío en la implementación de los contratos financieros es que la mayoría de ellos requieren referencia a un ticker de precios externo; por ejemplo, una aplicación muy deseable es un contrato inteligente que protege contra la volatilidad del éter (u otra criptomoneda) con respecto al dólar estadounidense, pero hacer esto requiere que el contrato sepa cuál es el valor de ETH / USD. La forma más sencilla de hacerlo es a través de un contrato de «alimentación de datos» mantenido por una parte específica (por ejemplo, NASDAQ) diseñado para que esa parte tenga la capacidad de actualizar el contrato según sea necesario y proporcionar una interfaz que permita a otros contratos enviar mensaje a ese contrato y obtenga una respuesta que proporcione el precio.

Dado ese ingrediente crítico, el contrato de cobertura se vería de la siguiente manera:

1. Espere a que la parte A ingrese 1000 ether.
2. Espere a que la parte B ingrese 1000 ether.
3. Registre el valor en USD de 1000 ether, calculado consultando el contrato de alimentación de datos, en el almacenamiento, digamos que es \ $ x.
4. Después de 30 días, permita que A o B «reactiven» el contrato para enviar \ $ x en ether (calculado consultando el contrato de alimentación de datos nuevamente para obtener el nuevo precio) a A y el resto a B.

Tal contrato tendría un potencial significativo en el comercio criptográfico. Uno de los principales problemas citados sobre la criptomoneda es el hecho de que es volátil; aunque muchos usuarios y comerciantes pueden desear la seguridad y la conveniencia de tratar con activos criptográficos, es posible que no deseen enfrentar la perspectiva de perder el 23% del valor de sus fondos en un solo día. Hasta ahora, la solución propuesta con más frecuencia han sido los activos respaldados por el emisor; la idea es que un emisor cree una sub-moneda en la que tiene derecho a emitir y revocar unidades, y proporcionar una unidad de la moneda a cualquiera que les proporcione (fuera de línea) una unidad de un activo subyacente específico (por ejemplo, oro , DÓLAR ESTADOUNIDENSE). Luego, el emisor se compromete a proporcionar una unidad del activo subyacente a cualquiera que envíe una unidad del activo criptográfico.

En la práctica, sin embargo, los emisores no siempre son confiables y, en algunos casos, la infraestructura bancaria es demasiado débil o demasiado hostil para que existan tales servicios. Los derivados financieros ofrecen una alternativa. Aquí, en lugar de que un solo emisor proporcione los fondos para respaldar un activo, un mercado descentralizado de especuladores, apostando a que el precio de un activo de referencia criptográfico (por ejemplo, ETH) subirá, juega ese papel. A diferencia de los emisores, los especuladores no tienen la opción de incumplir su parte del trato porque el contrato de cobertura mantiene sus fondos en custodia. Tenga en cuenta que este enfoque no está completamente descentralizado, porque todavía se necesita una fuente confiable para proporcionar el ticker de precios, aunque podría decirse que aún así se trata de una mejora masiva en términos de reducción de los requisitos de infraestructura (a diferencia de ser un emisor,

Sistemas de identidad y reputación

La criptomoneda alternativa más antigua de todas, Namecoin , intentó utilizar una cadena de bloques similar a Bitcoin para proporcionar un sistema de registro de nombres, donde los usuarios pueden registrar sus nombres en una base de datos pública junto con otros datos. El caso de uso más citado es el de un sistema DNS , que asigna nombres de dominio como «bitcoin.org» (o, en el caso de Namecoin, «bitcoin.bit») a una dirección IP. Otros casos de uso incluyen la autenticación de correo electrónico y sistemas de reputación potencialmente más avanzados. Aquí está el contrato básico para proporcionar un sistema de registro de nombres similar a Namecoin en Ethereum:

def register(name, value):
    if !self.storage[name]:
        self.storage[name] = value

El contrato es muy sencillo; todo es una base de datos dentro de la red Ethereum que se puede agregar, pero no modificar ni eliminar. Cualquiera puede registrar un nombre con algún valor, y ese registro se queda para siempre. Un contrato de registro de nombre más sofisticado también tendrá una «cláusula de función» que permitirá a otros contratos consultarlo, así como un mecanismo para que el «propietario» (es decir, el primer registrador) de un nombre cambie los datos o transfiera la propiedad. Incluso se puede agregar la funcionalidad de reputación y web de confianza en la parte superior.

Almacenamiento de archivos descentralizado

En los últimos años, ha surgido una serie de empresas emergentes de almacenamiento de archivos en línea populares, la más destacada es Dropbox, que busca permitir a los usuarios cargar una copia de seguridad de su disco duro y hacer que el servicio almacene la copia de seguridad y permita al usuario acceder a ella. a cambio de una cuota mensual. Sin embargo, en este punto, el mercado de almacenamiento de archivos es a veces relativamente ineficiente; una mirada superficial a varias soluciones existentes muestra que, sobre todo en el nivel de 20 a 200 GB del «valle inquietante» en el que no entran en juego ni las cuotas gratuitas ni los descuentos a nivel empresarial, los precios mensuales de los costos de almacenamiento de archivos convencionales son tales que usted paga más que el costo de todo el conducir en un solo mes. Los contratos de Ethereum pueden permitir el desarrollo de un ecosistema de almacenamiento de archivos descentralizado, donde los usuarios individuales pueden ganar pequeñas cantidades de dinero alquilando sus propios discos duros y el espacio no utilizado se puede utilizar para reducir aún más los costos de almacenamiento de archivos.

La pieza clave que sustenta un dispositivo de este tipo sería lo que hemos denominado el «contrato de Dropbox descentralizado». Este contrato funciona de la siguiente manera. Primero, uno divide los datos deseados en bloques, encripta cada bloque para privacidad y construye un árbol Merkle a partir de él. Luego, uno hace un contrato con la regla de que, cada N bloques, el contrato elegiría un índice aleatorio en el árbol de Merkle (utilizando el hash del bloque anterior, accesible desde el código del contrato, como fuente de aleatoriedad), y le daría X ether al primera entidad en proporcionar una transacción con una prueba de propiedad del bloque, similar a una verificación de pago simplificada, en ese índice particular del árbol. Cuando un usuario desea volver a descargar su archivo, puede usar un protocolo de canal de micropagos (por ejemplo, pagar 1 szabo por 32 kilobytes) para recuperar el archivo;

Una característica importante del protocolo es que, aunque puede parecer que uno está confiando en muchos nodos aleatorios para que no decidan olvidar el archivo, se puede reducir ese riesgo a casi cero dividiendo el archivo en muchas partes mediante el intercambio secreto, y mirando los contratos para ver que cada pieza todavía está en posesión de algún nodo. Si un contrato todavía está pagando dinero, eso proporciona una prueba criptográfica de que alguien todavía está almacenando el archivo.

Organismos autónomos descentralizados

El concepto general de «organización autónoma descentralizada» es el de una entidad virtual que tiene un determinado conjunto de miembros o accionistas que, quizás con una mayoría del 67%, tienen derecho a gastar los fondos de la entidad y modificar su código. Los miembros decidirían colectivamente cómo la organización debería asignar sus fondos. Los métodos para asignar los fondos de un DAO pueden variar desde recompensas, salarios hasta mecanismos aún más exóticos, como una moneda interna para recompensar el trabajo. Básicamente, esto replica las trampas legales de una empresa tradicional o sin fines de lucro, pero utilizando solo la tecnología de cadena de bloques criptográfica para su cumplimiento. Hasta ahora, gran parte de la conversación en torno a los DAO se ha centrado en el modelo «capitalista» de una «corporación autónoma descentralizada» (DAC) con accionistas que reciben dividendos y acciones negociables; una alternativa, tal vez descrita como una «comunidad autónoma descentralizada», haría que todos los miembros tuvieran una participación igual en la toma de decisiones y requeriría que el 67% de los miembros existentes aceptaran agregar o eliminar un miembro. El requisito de que una persona solo puede tener una membresía debería ser aplicado colectivamente por el grupo.

Un esquema general de cómo codificar un DAO es el siguiente. El diseño más simple es simplemente una pieza de código que se modifica automáticamente y que cambia si dos tercios de los miembros están de acuerdo con un cambio. Aunque el código es teóricamente inmutable, uno puede evitarlo fácilmente y tener mutabilidad de facto al tener fragmentos del código en contratos separados y tener la dirección de los contratos a llamar almacenada en el almacenamiento modificable. En una implementación simple de dicho contrato DAO, habría tres tipos de transacciones, que se distinguen por los datos proporcionados en la transacción:

• [0,i,K,V]para registrar una propuesta con índice ipara cambiar la dirección en el índice de almacenamiento Ka valorV
• [1,i]registrar un voto a favor de la propuesta i
• [2,i]para finalizar la propuesta isi se han realizado suficientes votos

El contrato tendría entonces cláusulas para cada uno de estos. Mantendría un registro de todos los cambios de almacenamiento abiertos, junto con una lista de quienes votaron por ellos. También tendría una lista de todos los miembros. Cuando cualquier cambio de almacenamiento llega a dos tercios de los miembros que lo votan, una transacción de finalización podría ejecutar el cambio. Un esqueleto más sofisticado también tendría capacidad de votación incorporada para funciones como enviar una transacción, agregar miembros y eliminar miembros, e incluso podría proporcionar Democracia líquida- delegación de votos al estilo (es decir, cualquiera puede asignar a alguien para que vote por ellos, y la asignación es transitiva, por lo que si A asigna B y B asigna C, C determina el voto de A). Este diseño permitiría a la DAO crecer orgánicamente como una comunidad descentralizada, permitiendo que las personas eventualmente deleguen la tarea de filtrar quiénes son miembros a los especialistas, aunque a diferencia del «sistema actual», los especialistas pueden aparecer y desaparecer fácilmente con el tiempo. a medida que los miembros individuales de la comunidad cambian sus alineaciones.

Un modelo alternativo es para una corporación descentralizada, donde cualquier cuenta puede tener cero o más acciones, y se requieren dos tercios de las acciones para tomar una decisión. Un esqueleto completo implicaría la funcionalidad de gestión de activos, la capacidad de hacer una oferta para comprar o vender acciones y la capacidad de aceptar ofertas (preferiblemente con un mecanismo de igualación de órdenes dentro del contrato). También existiría la delegación al estilo de la Democracia Líquida, generalizando el concepto de «junta directiva».

Otras aplicaciones

1. Carteras de ahorro . Suponga que Alice quiere mantener sus fondos a salvo, pero le preocupa que pueda perder o que alguien piratee su clave privada. Ella pone ether en un contrato con Bob, un banco, de la siguiente manera:

• Alice sola puede retirar un máximo del 1% de los fondos por día.
• Bob solo puede retirar un máximo del 1% de los fondos por día, pero Alice tiene la capacidad de realizar una transacción con su llave desactivando esta capacidad.
• Alice y Bob juntos pueden retirar cualquier cosa.

Normalmente, el 1% por día es suficiente para Alice, y si Alice quiere retirarse más, puede contactar a Bob para obtener ayuda. Si la llave de Alice es pirateada, ella corre hacia Bob para mover los fondos a un nuevo contrato. Si pierde su llave, Bob eventualmente sacará los fondos. Si Bob resulta ser malicioso, entonces ella puede desactivar su capacidad de retraerse.

2. Seguro de cosechas . Se puede hacer fácilmente un contrato de derivados financieros pero utilizando una fuente de datos del clima en lugar de cualquier índice de precios. Si un agricultor en Iowa compra un derivado que paga inversamente en base a la precipitación en Iowa, entonces si hay una sequía, el agricultor automáticamente recibirá dinero y si hay suficiente lluvia, el agricultor estará feliz porque sus cultivos irían bien. Esto se puede ampliar al seguro contra desastres naturales en general.

3. Una fuente de datos descentralizada . Para los contratos financieros por diferencia, en realidad puede ser posible descentralizar la alimentación de datos a través de un protocolo llamado SchellingCoin . SchellingCoin básicamente funciona de la siguiente manera: N partes ingresan al sistema el valor de un dato dado (por ejemplo, el precio ETH / USD), los valores se ordenan y todos los que se encuentran entre el percentil 25 y 75 obtienen una ficha como recompensa. Todos tienen el incentivo de proporcionar la respuesta que todos los demás brindarán, y el único valor en el que un gran número de jugadores puede estar de acuerdo de manera realista es el valor predeterminado obvio: la verdad. Esto crea un protocolo descentralizado que teóricamente puede proporcionar cualquier número de valores, incluido el precio ETH / USD, la temperatura en Berlín o incluso el resultado de un cálculo duro particular.

4. Fideicomiso inteligente de múltiples firmas . Bitcoin permite contratos de transacciones de firma múltiple donde, por ejemplo, tres de cada cinco claves determinadas pueden gastar los fondos. Ethereum permite una mayor granularidad; por ejemplo, cuatro de cada cinco pueden gastar todo, tres de cada cinco pueden gastar hasta un 10% por día y dos de cada cinco pueden gastar hasta un 0,5% por día. Además, Ethereum multisig es asincrónico: dos partes pueden registrar sus firmas en la cadena de bloques en diferentes momentos y la última firma enviará automáticamente la transacción.

5. Computación en la nube. La tecnología EVM también se puede utilizar para crear un entorno informático verificable, lo que permite a los usuarios pedir a otros que realicen cálculos y luego, opcionalmente, pedir pruebas de que los cálculos en ciertos puntos de control seleccionados al azar se realizaron correctamente. Esto permite la creación de un mercado de computación en la nube donde cualquier usuario puede participar con su computadora de escritorio, computadora portátil o servidor especializado, y la verificación al azar junto con los depósitos de seguridad se pueden utilizar para garantizar que el sistema sea confiable (es decir, los nodos no pueden hacer trampa de manera rentable) . Aunque tal sistema puede no ser adecuado para todas las tareas; las tareas que requieren un alto nivel de comunicación entre procesos, por ejemplo, no se pueden realizar fácilmente en una gran nube de nodos. Sin embargo, otras tareas son mucho más fáciles de paralelizar; proyectos como SETI @ home,

6. Juegos de azar entre pares . Cualquier número de protocolos de juego de igual a igual, como el Cyberdice de Frank Stajano y Richard Clayton , se puede implementar en la cadena de bloques Ethereum. El protocolo de juego más simple es en realidad simplemente un contrato por diferencia en el siguiente bloque hash, y a partir de ahí se pueden construir protocolos más avanzados, creando servicios de juego con tarifas casi nulas que no tienen la capacidad de hacer trampa.

7. Predicción de mercados . Siempre que se disponga de un oráculo o SchellingCoin, los mercados de predicción también son fáciles de implementar, y los mercados de predicción junto con SchellingCoin pueden llegar a ser la primera aplicación principal de futarquía como protocolo de gobernanza para organizaciones descentralizadas.

8. Mercados descentralizados en cadena , utilizando el sistema de identidad y reputación como base.

Miscelánea y preocupaciones

Implementación modificada de GHOST

El protocolo «Greedy Heaviest Observed Subtree» (GHOST) es una innovación introducida por primera vez por Yonatan Sompolinsky y Aviv Zohar en diciembre de 2013. La motivación detrás de GHOST es que las cadenas de bloques con tiempos de confirmación rápidos actualmente sufren de seguridad reducida debido a una alta tasa de obsolescencia, porque los bloques tardan cierto tiempo en propagarse a través de la red, si el minero A extrae un bloque y luego el minero B extrae otro bloque antes de que el bloque del minero A se propague a B, el bloque del minero B terminará desperdiciado y no contribuirá a la seguridad de la red. Además, hay un problema de centralización: si el minero A es un grupo de minería con un 30% de hashpower y B tiene un 10% de hashpower, A correrá el riesgo de producir un bloque obsoleto el 70% del tiempo (desde el otro 30% del tiempo). A produjo el último bloque y, por lo tanto, obtendrá datos de minería de inmediato) mientras que B tendrá el riesgo de producir un bloque obsoleto el 90% del tiempo. Por lo tanto, si el intervalo de bloque es lo suficientemente corto para que la tasa de obsolescencia sea alta, A será sustancialmente más eficiente simplemente en virtud de su tamaño. Con estos dos efectos combinados, es muy probable que las cadenas de bloques que producen bloques rápidamente conduzcan a que un grupo de minería tenga un porcentaje suficientemente grande de la potencia de hash de la red para tener control de facto sobre el proceso de minería.

Como lo describen Sompolinsky y Zohar, GHOST resuelve el primer problema de pérdida de seguridad de la red al incluir bloques obsoletos en el cálculo de qué cadena es la «más larga»; es decir, no solo el padre y los antepasados ​​posteriores de un bloque, sino también los descendientes obsoletos del antepasado del bloque (en la jerga de Ethereum, «tíos») se agregan al cálculo de qué bloque tiene el mayor respaldo total de prueba de trabajo eso. Para resolver el segundo problema del sesgo de centralización, vamos más allá del protocolo descrito por Sompolinsky y Zohar, y también proporcionamos recompensas en bloque a los obsoletos: un bloque obsoleto recibe el 87,5% de su recompensa base, y el sobrino que incluye el bloque obsoleto recibe el resto. 12,5%. Sin embargo, las tarifas de transacción no se otorgan a los tíos.

Ethereum implementa una versión simplificada de GHOST que solo baja siete niveles. En concreto, se define de la siguiente manera:

• Un bloque debe especificar un padre y debe especificar 0 o más tíos
• Un tío incluido en bloque Bdebe tener las siguientes propiedades:
• Debe ser un hijo directo de la k-ésima generación de ancestros de B, donde 2 <= k <= 7.
• No puede ser un antepasado de B
• Un tío debe ser un encabezado de bloque válido, pero no es necesario que sea un bloque previamente verificado o incluso válido
• Un tío debe ser diferente de todos los tíos incluidos en bloques anteriores y todos los demás tíos incluidos en el mismo bloque (no doble inclusión)
• Por cada tío Uen el bloque B, el minero de Bobtiene un 3,125% adicional agregado a su recompensa de base de monedas y el minero de U obtiene el 93,75% de una recompensa de base de monedas estándar.

Esta versión limitada de GHOST, con tíos incluibles solo hasta 7 generaciones, se usó por dos razones. Primero, GHOST ilimitado incluiría demasiadas complicaciones en el cálculo de qué tíos para un bloque dado son válidos. En segundo lugar, GHOST ilimitado con compensación como se usa en Ethereum elimina el incentivo para que un minero extraiga en la cadena principal y no en la cadena de un atacante público.

Tarifa

Debido a que cada transacción publicada en la cadena de bloques impone a la red el costo de tener que descargarla y verificarla, existe la necesidad de algún mecanismo regulador, que generalmente involucra tarifas de transacción, para evitar abusos. El enfoque predeterminado, utilizado en Bitcoin, es tener tarifas puramente voluntarias, confiando en que los mineros actúen como guardianes y establezcan mínimos dinámicos. Este enfoque ha sido recibido muy favorablemente en la comunidad de Bitcoin, particularmente porque está «basado en el mercado», permitiendo que la oferta y la demanda entre los mineros y los remitentes de transacciones determinen el precio. El problema con esta línea de razonamiento es, sin embargo, que el procesamiento de transacciones no es un mercado; aunque es intuitivamente atractivo interpretar el procesamiento de transacciones como un servicio que el minero ofrece al remitente, en realidad, cada transacción que incluya un minero deberá ser procesada por cada nodo de la red, por lo que la gran mayoría del costo del procesamiento de la transacción corre a cargo de terceros y no del minero que toma la decisión de incluir o no eso. Por lo tanto, es muy probable que ocurran problemas de tragedia de los comunes.

Sin embargo, como resulta que esta falla en el mecanismo basado en el mercado, cuando se le da una suposición simplificadora inexacta particular, se cancela mágicamente. El argumento es el siguiente. Suponer que:

1. Una transacción conduce a koperaciones, ofreciendo la recompensa kRa cualquier minero que la incluya donde Rsea ​​establecida por el remitente ky Rsea ​​(aproximadamente) visible para el minero de antemano.
2. Una operación tiene un costo de procesamiento de Cpara cualquier nodo (es decir, todos los nodos tienen la misma eficiencia)
3. Hay Nnodos de minería, cada uno con exactamente la misma potencia de procesamiento (es decir, 1/Ndel total)
4. No existen nodos completos que no sean mineros.

Un minero estaría dispuesto a procesar una transacción si la recompensa esperada es mayor que el costo. Por lo tanto, la recompensa esperada es kR/Nporque el minero tiene la 1/Nposibilidad de procesar el siguiente bloque, y el costo de procesamiento para el minero es simple kC. Por lo tanto, los mineros incluirán transacciones donde kR/N > kC, o R > NC. Tenga en cuenta que Res la tarifa por operación proporcionada por el remitente y, por lo tanto, es un límite inferior del beneficio que el remitente obtiene de la transacción, y NCes el costo para toda la red en conjunto de procesar una operación. Por lo tanto, los mineros tienen el incentivo de incluir solo aquellas transacciones para las cuales el beneficio utilitario total excede el costo.

Sin embargo, existen varias desviaciones importantes de esos supuestos en la realidad:

1. El minero paga un costo más alto para procesar la transacción que los otros nodos de verificación, ya que el tiempo de verificación adicional retrasa la propagación del bloque y, por lo tanto, aumenta la posibilidad de que el bloque se vuelva obsoleto.
2. Existen nodos completos no mineros.
3. La distribución del poder minero puede terminar siendo radicalmente desigual en la práctica.
4. Existen especuladores, enemigos políticos y locos cuya función de utilidad incluye causar daño a la red, y pueden establecer contratos inteligentemente donde su costo es mucho menor que el costo pagado por otros nodos de verificación.

(1) proporciona una tendencia para que el minero incluya menos transacciones y (2) aumentos NC; por tanto, estos dos efectos se anulan, al menos parcialmente, entre sí. (3) y (4) son el problema principal; para resolverlos, simplemente instituimos un límite flotante: ningún bloque puede tener más operaciones que BLK_LIMIT_FACTORel promedio móvil exponencial a largo plazo. Específicamente:

blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) +
floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR)

BLK_LIMIT_FACTORy EMA_FACTORson constantes que se establecerán en 65536 y 1.5 por el momento, pero probablemente se cambiarán después de un análisis adicional.

Hay otro factor que desincentiva los tamaños de bloque grandes en Bitcoin: los bloques que son grandes tardarán más en propagarse y, por lo tanto, tienen una mayor probabilidad de volverse obsoletos. En Ethereum, los bloques que consumen mucho gas también pueden tardar más en propagarse porque son físicamente más grandes y porque tardan más en procesar las transiciones de estado de la transacción para validarlas. Este desincentivo de retraso es una consideración importante en Bitcoin, pero menos en Ethereum debido al protocolo GHOST; por lo tanto, confiar en límites de bloque regulados proporciona una línea de base más estable.

Computación y completitud de Turing

Una nota importante es que la máquina virtual Ethereum es Turing-complete; esto significa que el código EVM puede codificar cualquier cálculo que pueda llevarse a cabo, incluidos los bucles infinitos. El código EVM permite realizar un bucle de dos formas. Primero, hay una JUMPinstrucción que permite que el programa salte de regreso a un punto anterior en el código, y una JUMPIinstrucción para hacer un salto condicional, permitiendo declaraciones comowhile x < 27: x = x * 2. En segundo lugar, los contratos pueden llamar a otros contratos, lo que permite realizar un bucle mediante la recursividad. Esto naturalmente conduce a un problema: ¿pueden los usuarios malintencionados básicamente cerrar mineros y nodos completos forzándolos a entrar en un bucle infinito? El problema surge debido a un problema en ciencias de la computación conocido como el problema de detención: no hay forma de saber, en el caso general, si un programa dado se detendrá o no.

Como se describe en la sección de transición de estado, nuestra solución funciona al requerir que una transacción establezca un número máximo de pasos computacionales que se le permite tomar, y si la ejecución lleva más tiempo, el cálculo se revierte pero las tarifas aún se pagan. Los mensajes funcionan de la misma manera. Para mostrar la motivación detrás de nuestra solución, considere los siguientes ejemplos:

• Un atacante crea un contrato que ejecuta un bucle infinito y luego envía una transacción que activa ese bucle al minero. El minero procesará la transacción, ejecutará el bucle infinito y esperará a que se quede sin gasolina. A pesar de que la ejecución se queda sin combustible y se detiene a la mitad, la transacción sigue siendo válida y el minero aún reclama la tarifa del atacante por cada paso de cálculo.
• Un atacante crea un bucle infinito muy largo con la intención de obligar al minero a seguir calculando durante tanto tiempo que para cuando finalice el cálculo habrán salido algunos bloques más y el minero no podrá incluir la transacción. para reclamar la tarifa. Sin embargo, el atacante deberá enviar un valor para STARTGASlimitar el número de pasos computacionales que puede tomar la ejecución, de modo que el minero sepa de antemano que el cálculo tomará una cantidad excesivamente grande de pasos.
• Un atacante ve un contrato con un código de alguna forma send(A,contract.storage[A]); contract.storage[A] = 0y envía una transacción con suficiente gas para ejecutar el primer paso pero no el segundo (es decir, hacer un retiro pero no dejar que el saldo baje). El autor del contrato no necesita preocuparse por protegerse contra tales ataques, porque si la ejecución se detiene a la mitad de los cambios, se revierten.
• Un contrato financiero funciona tomando la mediana de nueve fuentes de datos patentadas para minimizar el riesgo. Un atacante se apodera de una de las fuentes de datos, que está diseñada para ser modificable a través del mecanismo de llamada de dirección variable que se describe en la sección sobre DAO, y la convierte para ejecutar un bucle infinito, intentando así forzar cualquier intento de reclamar fondos de el contrato financiero para quedarse sin gasolina. Sin embargo, el contrato financiero puede establecer un límite de gas en el mensaje para evitar este problema.

La alternativa a la completitud de Turing es la completitud de Turing, donde JUMPyJUMPIno existen y solo se permite que exista una copia de cada contrato en la pila de llamadas en un momento dado. Con este sistema, el sistema de tarifas descrito y las incertidumbres en torno a la efectividad de nuestra solución podrían no ser necesarios, ya que el costo de ejecutar un contrato estaría limitado por su tamaño. Además, el carácter incompleto de Turing ni siquiera es una limitación tan grande; De todos los ejemplos de contratos que hemos concebido internamente, hasta ahora solo uno requería un bucle, e incluso ese bucle podría eliminarse haciendo 26 repeticiones de un fragmento de código de una línea. Dadas las serias implicaciones de la completitud de Turing y el beneficio limitado, ¿por qué no simplemente tener un lenguaje de Turing incompleto? En realidad, sin embargo, el carácter incompleto de Turing está lejos de ser una solución clara al problema. Para ver por qué, considere los siguientes contratos:

C0: call(C1); call(C1);
C1: call(C2); call(C2);
C2: call(C3); call(C3);
...
C49: call(C50); call(C50);
C50: (run one step of a program and record the change in storage)

Ahora, envíe una transacción a A. Por lo tanto, en 51 transacciones, tenemos un contrato que ocupa 2 ⁵⁰Pasos computacionales. Los mineros podrían intentar detectar tales bombas lógicas con anticipación manteniendo un valor junto con cada contrato que especifique el número máximo de pasos computacionales que puede tomar, y calculando esto para contratos que llaman a otros contratos de manera recursiva, pero eso requeriría que los mineros prohibieran los contratos que crean otros contratos (dado que la creación y ejecución de los 26 contratos anteriores podrían fácilmente integrarse en un solo contrato). Otro punto problemático es que el campo de dirección de un mensaje es una variable, por lo que, en general, es posible que ni siquiera sea posible saber qué otros contratos llamará un contrato determinado con anticipación. Por lo tanto, en general, tenemos una conclusión sorprendente: la completitud de Turing es sorprendentemente fácil de manejar,

Moneda y emisión

La red Ethereum incluye su propia moneda incorporada, ether, que tiene el doble propósito de proporcionar una capa de liquidez primaria para permitir un intercambio eficiente entre varios tipos de activos digitales y, lo que es más importante, proporcionar un mecanismo para pagar las tarifas de transacción. Por conveniencia y para evitar discusiones futuras (vea el debate actual sobre mBTC / uBTC / satoshi en Bitcoin), las denominaciones estarán preetiquetadas:

• 1: wei
• 10 ¹² : szabo
• 10 ¹⁵ : finney
• 10 ¹⁸ : éter

Esto debe tomarse como una versión ampliada del concepto de «dólares» y «centavos» o «BTC» y «satoshi». En un futuro cercano, esperamos que «ether» se use para transacciones ordinarias, «finney» para microtransacciones y «szabo» y «wei» para discusiones técnicas sobre tarifas e implementación de protocolos; las denominaciones restantes pueden resultar útiles más adelante y no deben incluirse en los clientes en este momento.

El modelo de emisión será el siguiente:

• Ether se lanzará en una venta de divisas al precio de 1000-2000 ether por BTC, un mecanismo destinado a financiar la organización Ethereum y pagar por el desarrollo que ha sido utilizado con éxito por otras plataformas como Mastercoin y NXT. Los compradores anteriores se beneficiarán de mayores descuentos. El BTC recibido de la venta se utilizará en su totalidad para pagar salarios y recompensas a los desarrolladores y se invertirá en varios proyectos con y sin fines de lucro en el ecosistema de Ethereum y criptomonedas.
• Se asignará 0,099 veces la cantidad total vendida (60102216 ETH) a la organización para compensar a los primeros contribuyentes y pagar los gastos denominados en ETH antes del bloque de génesis.
• 0.099x la cantidad total vendida se mantendrá como reserva a largo plazo.
• Se asignará 0,26 veces la cantidad total vendida a los mineros por año para siempre después de ese punto.

Grupo En el lanzamiento Después de 1 año Después de 5 años

---

Unidades monetarias 1.198X 1.458X 2.498X Compradores 83.5% 68.6% 40.0% Reserva gastada antes de la venta 8.26% 6.79% 3.96% Reserva usada después de la venta 8.26% 6.79% 3.96% Mineros 0% 17.8% 52.0%

Tasa de crecimiento de la oferta a largo plazo (porcentaje)

A pesar de la emisión de moneda lineal, al igual que con Bitcoin, con el tiempo, la tasa de crecimiento de la oferta tiende a cero.

Las dos opciones principales en el modelo anterior son (1) la existencia y el tamaño de un grupo de dotación y (2) la existencia de un suministro lineal en crecimiento permanente, en contraposición a un suministro limitado como en Bitcoin. La justificación del fondo de dotación es la siguiente. Si el fondo de dotación no existiera y la emisión lineal se redujera a 0.217x para proporcionar la misma tasa de inflación, entonces la cantidad total de éter sería 16.5% menos y, por lo tanto, cada unidad sería 19.8% más valiosa. Por lo tanto, en el equilibrio se compraría un 19,8% más de éter en la venta, por lo que cada unidad volvería a ser exactamente tan valiosa como antes. La organización también tendría 1.198x más BTC, que se puede considerar dividida en dos partes: el BTC original y el 0.198x adicional. Por tanto, esta situación es exactamente equivalentea la dotación, pero con una diferencia importante: la organización posee únicamente BTC y, por lo tanto, no está incentivada para respaldar el valor de la unidad de éter.

El modelo de crecimiento de oferta lineal permanente reduce el riesgo de lo que algunos ven como una concentración excesiva de riqueza en Bitcoin, y brinda a las personas que viven en las épocas presente y futura una oportunidad justa de adquirir unidades monetarias, mientras que al mismo tiempo retienen un fuerte incentivo para obtener y mantener éter porque la «tasa de crecimiento de la oferta» como porcentaje todavía tiende a cero con el tiempo. También teorizamos que debido a que las monedas siempre se pierden con el tiempo debido a descuido, muerte, etc., y la pérdida de monedas se puede modelar como un porcentaje del suministro total por año, el suministro total de moneda en circulación de hecho eventualmente se estabilizará en un valor. igual a la emisión anual dividida por la tasa de pérdida (por ejemplo, a una tasa de pérdida del 1%, una vez que la oferta llega a 26X, se extraerá 0.26X y se perderá 0.26X cada año, creando un equilibrio).

Tenga en cuenta que en el futuro, es probable que Ethereum cambie a un modelo de prueba de participación por seguridad, reduciendo el requisito de emisión a algún lugar entre cero y 0.05X por año. En el caso de que la organización Ethereum pierda financiación o por cualquier otro motivo desaparezca, dejamos abierto un «contrato social»: cualquiera tiene derecho a crear una futura versión candidata de Ethereum, con la única condición de que la cantidad de ether debe ser como máximo igual a 60102216 * (1.198 + 0.26 * n)dondenes el número de años después del bloqueo génesis. Los creadores son libres de realizar ventas colectivas o asignar parte o la totalidad de la diferencia entre la expansión de suministro impulsada por PoS y la expansión de suministro máxima permitida para pagar el desarrollo. Las actualizaciones candidatas que no cumplan con el contrato social se pueden dividir justificadamente en versiones compatibles.

Centralización minera

El algoritmo de minería de Bitcoin funciona haciendo que los mineros calculen SHA256 en versiones ligeramente modificadas del encabezado del bloque millones de veces una y otra vez, hasta que finalmente un nodo presenta una versión cuyo hash es menor que el objetivo (actualmente alrededor de ²¹⁹²). Sin embargo, este algoritmo de minería es vulnerable a dos formas de centralización. En primer lugar, el ecosistema minero ha llegado a estar dominado por los ASIC (circuitos integrados específicos de la aplicación), chips de computadora diseñados y, por lo tanto, miles de veces más eficientes en la tarea específica de la minería de Bitcoin. Esto significa que la minería de Bitcoin ya no es una búsqueda altamente descentralizada e igualitaria, que requiere millones de dólares de capital para participar de manera efectiva. En segundo lugar, la mayoría de los mineros de Bitcoin en realidad no realizan la validación de bloques localmente; en cambio, confían en un grupo de minería centralizado para proporcionar los encabezados de bloque. Este problema es posiblemente peor: en el momento de escribir este artículo, los tres principales grupos de minería controlan indirectamente aproximadamente el 50% de la potencia de procesamiento en la red Bitcoin,

La intención actual en Ethereum es usar un algoritmo de minería en el que se requiere que los mineros obtengan datos aleatorios del estado, calculen algunas transacciones seleccionadas al azar de los últimos N bloques en la cadena de bloques y devuelvan el hash del resultado. Esto tiene dos importantes beneficios. Primero, los contratos de Ethereum pueden incluir cualquier tipo de cálculo, por lo que un ASIC de Ethereum sería esencialmente un ASIC para el cálculo general, es decir. una mejor CPU. En segundo lugar, la minería requiere acceso a toda la cadena de bloques, lo que obliga a los mineros a almacenar toda la cadena de bloques y al menos ser capaces de verificar cada transacción. Esto elimina la necesidad de grupos de minería centralizados; Si bien los grupos de minería todavía pueden cumplir el papel legítimo de igualar la aleatoriedad de la distribución de recompensas, esta función puede ser igualmente útil en grupos de igual a igual sin control central.

Este modelo no está probado y puede haber dificultades en el camino para evitar ciertas optimizaciones inteligentes cuando se utiliza la ejecución de contratos como algoritmo de minería. Sin embargo, una característica notablemente interesante de este algoritmo es que permite a cualquiera «envenenar el pozo», al introducir una gran cantidad de contratos en la cadena de bloques diseñados específicamente para bloquear ciertos ASIC. Existen incentivos económicos para que los fabricantes de ASIC utilicen ese truco para atacarse entre sí. Por lo tanto, la solución que estamos desarrollando es, en última instancia, una solución humana económica adaptativa en lugar de una solución puramente técnica.

Escalabilidad

Una preocupación común sobre Ethereum es el problema de la escalabilidad. Al igual que Bitcoin, Ethereum adolece del defecto de que cada transacción debe ser procesada por todos los nodos de la red. Con Bitcoin, el tamaño de la cadena de bloques actual es de aproximadamente 15 GB, creciendo aproximadamente 1 MB por hora. Si la red Bitcoin procesara las 2000 transacciones de Visa por segundo, aumentaría en 1 MB por tres segundos (1 GB por hora, 8 TB por año). Es probable que Ethereum sufra un patrón de crecimiento similar, agravado por el hecho de que habrá muchas aplicaciones en la parte superior de la cadena de bloques de Ethereum en lugar de solo una moneda como es el caso de Bitcoin, pero mejorada por el hecho de que los nodos completos de Ethereum deben almacenar solo el estado en lugar de todo el historial de blockchain.

El problema con un tamaño de cadena de bloques tan grande es el riesgo de centralización. Si el tamaño de la cadena de bloques aumenta a, digamos, 100 TB, entonces el escenario probable sería que solo una cantidad muy pequeña de grandes empresas ejecuten nodos completos, y todos los usuarios habituales utilicen nodos SPV ligeros. En tal situación, surge la preocupación potencial de que los nodos completos puedan unirse y todos acuerden hacer trampa de alguna manera rentable (por ejemplo, cambiar la recompensa del bloque, darse BTC). Los nodos de luz no tendrían forma de detectar esto de inmediato. Por supuesto, es probable que exista al menos un nodo completo honesto, y después de unas horas la información sobre el fraude se filtraría a través de canales como Reddit, pero en ese momento sería demasiado tarde: los usuarios normales deberían organizar un esfuerzo por poner en lista negra los bloques dados, un problema de coordinación masivo y probablemente inviable en una escala similar a la de realizar un ataque exitoso del 51%. En el caso de Bitcoin, esto es actualmente un problema, pero existe una modificación de blockchain.sugerido por Peter Todd que aliviará este problema.

A corto plazo, Ethereum utilizará dos estrategias adicionales para hacer frente a este problema. Primero, debido a los algoritmos de minería basados ​​en blockchain, al menos cada minero se verá obligado a ser un nodo completo, creando un límite inferior en el número de nodos completos. En segundo lugar, y lo que es más importante, sin embargo, incluiremos una raíz de árbol de estado intermedio en la cadena de bloques después de procesar cada transacción. Incluso si la validación de bloques está centralizada, siempre que exista un nodo de verificación honesto, el problema de centralización puede evitarse mediante un protocolo de verificación. Si un minero publica un bloque no válido, ese bloque debe tener un formato S[n]incorrecto o el estado es incorrecto. Dado que S[0]se sabe que es correcto, debe haber algún primer estado S[i]que sea incorrecto dondeS[i-1]es correcto. El nodo de verificación proporcionaría el índice i, junto con una «prueba de invalidez» que consiste en el subconjunto de nodos del árbol Patricia que necesitan procesar APPLY(S[i-1],TX[i]) -> S[i]. Los nodos podrían usar esos nodos de Patricia para ejecutar esa parte del cálculo y ver que el S[i]generado no coincide con el S[i]proporcionado.

Otro ataque, más sofisticado, involucraría a los mineros malintencionados que publican bloques incompletos, por lo que ni siquiera existe la información completa para determinar si los bloques son válidos o no. La solución a esto es un protocolo de desafío-respuesta: los nodos de verificación emiten «desafíos» en forma de índices de transacción de destino, y al recibir un nodo, un nodo ligero trata el bloque como no confiable hasta que otro nodo, ya sea el minero u otro verificador, proporciona un subconjunto de nodos Patricia como prueba de validez.

Conclusión

El protocolo Ethereum se concibió originalmente como una versión mejorada de una criptomoneda, que proporciona características avanzadas como depósito en garantía en blockchain, límites de retiro, contratos financieros, mercados de juegos de azar y similares a través de un lenguaje de programación altamente generalizado. El protocolo Ethereum no «admitiría» ninguna de las aplicaciones directamente, pero la existencia de un lenguaje de programación completo de Turing significa que, en teoría, se pueden crear contratos arbitrarios para cualquier tipo de transacción o aplicación. Sin embargo, lo más interesante de Ethereum es que el protocolo Ethereum va mucho más allá de la mera moneda. Protocolos en torno al almacenamiento de archivos descentralizado, computación descentralizada y mercados de predicción descentralizados, entre docenas de otros conceptos similares, tienen el potencial de aumentar sustancialmente la eficiencia de la industria computacional y proporcionar un impulso masivo a otros protocolos peer-to-peer al agregar por primera vez una capa económica. Por último, también existe una gran variedad de aplicaciones que no tienen nada que ver con el dinero.

El concepto de una función de transición de estado arbitraria implementado por el protocolo Ethereum proporciona una plataforma con un potencial único; En lugar de ser un protocolo cerrado y de un solo propósito destinado a una variedad específica de aplicaciones en almacenamiento de datos, juegos de azar o finanzas, Ethereum tiene un diseño abierto y creemos que es extremadamente adecuado para servir como base capa para una gran cantidad de protocolos financieros y no financieros en los próximos años.