{"id":139,"date":"2016-02-09T14:21:25","date_gmt":"2016-02-09T14:21:25","guid":{"rendered":"https:\/\/santiagomarquezsolis.com\/?p=139"},"modified":"2024-05-31T14:25:05","modified_gmt":"2024-05-31T14:25:05","slug":"ethereum-whitepaper-traducido-al-castellano","status":"publish","type":"post","link":"https:\/\/santiagomarquezsolis.com\/index.php\/2016\/02\/09\/ethereum-whitepaper-traducido-al-castellano\/","title":{"rendered":"Ethereum Whitepaper traducido al Castellano"},"content":{"rendered":"<p>Buenas a todos!!! Pues s\u00ed, sigo vivo, ja, ja, ya sab\u00e9is que actualizo el blog cuando realmente tengo algo importante que contarte, no me gusta llenar este espacio de cosas que no aporten valor. De momento puedo deciros que pronto estar\u00e1 disponible la conversi\u00f3n de la\u00a0<strong>Diosa de Cozumel<\/strong>\u00a0y que las adaptaciones a 3D de<strong>\u00a0<a href=\"https:\/\/www.youtube.com\/watch?v=WMSvCvpAxDw\" target=\"_blank\" rel=\"noopener\">3D Colossal Cave Adventure<\/a><\/strong>, va tambi\u00e9n viento en popa, creo que pronto podr\u00e9 mostraros novedades.<\/p>\n<p>Dicho lo cual,\u00a0<strong>\u00bfqu\u00e9 os traigo hoy por estos lares?<\/strong>\u00a0Seguramente algo que a m\u00e1s de uno os resultar\u00e1 \u00fatil, la traducci\u00f3n del whitepaper de Ethereum en castellano. El motivo de esta traducci\u00f3n se debe a que en los\u00a0<strong><a href=\"http:\/\/www.meetup.com\/es-ES\/MeetBMad\/events\/227799723\/\" target=\"_blank\" rel=\"nofollow noopener\">Madrid Bitcoin Meetup Home Page<\/a><\/strong>, de manera recurrente nos preguntan sobre \u00e9l y hay quien llega a confundir Ethereum con Bitcoin, pensando que ambas cosas son lo mismo. Siempre digo que lo mejor es recurrir al paper original, tanto del uno como del otro, pero como de Bitcoin ya existe traducci\u00f3n al castellano y de Ethereum, no la he encontrado por ning\u00fan lado, y tampoco me\u00a0supon\u00eda demasiado esfuerzo hacerla,\u00a0\u00a0sirva para ayudar a clarificar las cosas (por cierto, si hay algo que no resulte claro o que no est\u00e9 del todo bien traducido, dame un toque y lo actualizo, aunque he procurado que sea castellanamente legible, no vas a encontrarte con un texto del Google Traslator ;-)).<\/p>\n<p>Y por hacer un poco de publicidad adicional a\u00a0<strong><a href=\"http:\/\/www.amazon.es\/Bitcoin-sistema-financiero-Ense%C3%B1ando-criptomonedas-ebook\/dp\/B00U0N3SSS\/ref=sr_1_1?ie=UTF8&amp;qid=1453240180&amp;sr=8-1&amp;keywords=bitcoin+jaque\" target=\"_blank\" rel=\"nofollow noopener\">Bitcoin. \u00bfJaque mate al sistema financiero?<\/a><\/strong>, en Amazon tienes el primero de la serie de 5 que estoy escribiendo sobre el tema, creo que te ayudar\u00e1 a clarificar muchos conceptos b\u00e1sicos sobre su importancia en el entramado financiero y econ\u00f3mico mundial.<\/p>\n<p>PD.- Tambi\u00e9n puedes leerlo directamente desde\u00a0<a href=\"http:\/\/www.santiagomarquezsolis.com\/ethereum-whitepaper-traducido-al-castellano\/\" target=\"_blank\" rel=\"nofollow noopener\">mi web<\/a>.<\/p>\n<p>3&#8230;.2&#8230;.1&#8230;. comenzamos \ud83d\ude09<\/p>\n<p><strong>Ethereum Whitepaper<\/strong><\/p>\n<h3>(Traducci\u00f3n Santiago M\u00e1rquez Sol\u00eds @smarquezsolis \u2013 smarquezsolis@gmail.com)<\/h3>\n<p><strong>Una nueva generaci\u00f3n de Contratos Inteligentes y Plataforma para Aplicaciones Descentralizada<\/strong><\/p>\n<p>El desarrollo de Bitcoin por Satoshi Nakamoto en 2009, a menudo ha sido aclamado como un desarrollo radical en los conceptos de dinero y moneda, siendo el primer ejemplo de un activo digital que posee al mismo tiempo, carencia de \u201c<strong>valor intr\u00ednseco<\/strong>\u201d o respaldo y la inexistencia de ning\u00fan tipo de emisor centralizado o controlador. Sin embargo otra, posiblemente m\u00e1s importante, parte del experimento Bitcoin, es la tecnolog\u00eda subyacente de la cadena de bloques (blockchain), como una herramienta de consenso distribuido, de modo que la atenci\u00f3n est\u00e1 empezando a cambiar r\u00e1pidamente a este otro aspecto de Bitcoin. Son com\u00fanmente citados los usos alternativos de la tecnolog\u00eda blockchain, que incluir\u00edan entre otros la representaci\u00f3n, dentro de la propia cadena de bloques, de activos digitales, como podr\u00edan ser: las monedas personalizadas, los instrumentos financieros (\u201c<strong>monedas de colores<\/strong>\u201c), la propiedad de un dispositivo f\u00edsico subyacente (\u201c<strong>propiedad inteligente<\/strong>\u201c), los activos no fungibles, tales como nombres de dominio (\u201c<strong>Namecoin<\/strong>\u201c), as\u00ed como aplicaciones m\u00e1s complejas que implican tener activos digitales controlados directamente por un fragmento de c\u00f3digo que implementar\u00eda reglas arbitrarias (\u201c<strong>contratos inteligentes<\/strong>\u201c) o incluso \u201c<strong>organismos aut\u00f3nomos descentralizados<\/strong>\u201d (DAO) que tambi\u00e9n podr\u00edan estar basados en la cadena de bloques. Lo que Ethereum pretende es, proporcionar una cadena de bloques que tenga incorporada un lenguaje de programaci\u00f3n del tipo Turing-completo y que se pueda utilizar para crear \u201ccontratos\u201d. Estos a su vez pueden utilizarse para codificar funciones de transici\u00f3n entre estados arbitrarios, de modo, que se permitir\u00eda a los usuarios crear cualquiera de los sistemas descritos anteriormente, as\u00ed como muchos otros que a\u00fan no han sido imaginados, simplemente escribiendo su l\u00f3gica en unas pocas l\u00edneas de c\u00f3digo.<\/p>\n<p><strong>Tabla de Contenidos<\/strong><\/p>\n<ul>\n<li>Historia\n<ul>\n<li>Bitcoin como un Sistema de Transici\u00f3n de Estados<\/li>\n<li>Miner\u00eda<\/li>\n<li>Arboles de Merkle<\/li>\n<li>Aplicaciones Alternativas de la Cadena de Bloques (Blockchain)<\/li>\n<li>Guiones (Scripting)<\/li>\n<\/ul>\n<\/li>\n<li>Ethereum\n<ul>\n<li>Cuentas de Ethereum<\/li>\n<li>Mensajes y Transacciones<\/li>\n<li>Funci\u00f3n de Transici\u00f3n de Estados de Ethereum<\/li>\n<li>Ejecuci\u00f3n de C\u00f3digo<\/li>\n<li>Cadena de Bloques y Miner\u00eda<\/li>\n<\/ul>\n<\/li>\n<li>Aplicaciones\n<ul>\n<li>Sistemas de Testigos (Tokens)<\/li>\n<li>Derivados Financieros<\/li>\n<li>Sistemas de Identificaci\u00f3n y Reputaci\u00f3n<\/li>\n<li>Almacenamiento de Ficheros Distribuidos<\/li>\n<li>Organizaciones Aut\u00f3nomas Descentralizadas<\/li>\n<li>Otras Aplicaciones<\/li>\n<\/ul>\n<\/li>\n<li>Varios y Preocupaciones\n<ul>\n<li>Implementaci\u00f3n Modificada de GHOST<\/li>\n<li>Tasas (Fees)<\/li>\n<li>Computaci\u00f3n y Turing Completo<\/li>\n<li>Moneda y Emisi\u00f3n<\/li>\n<li>Centralizaci\u00f3n de la Miner\u00eda<\/li>\n<li>Escalabilidad<\/li>\n<\/ul>\n<\/li>\n<li>Conclusiones<\/li>\n<li>Referencias y Lecturas Adicionales<\/li>\n<\/ul>\n<h2>Introducci\u00f3n a Bitcoin y Conceptos Previos<\/h2>\n<h3>Historia<\/h3>\n<p>El concepto de moneda digital descentralizada, y\u00a0 sus aplicaciones alternativas como puede ser el registro de propiedad, ha existido durante d\u00e9cadas. Los protocolos an\u00f3nimos de e-cash de los 80 y la d\u00e9cada de 1990, en su mayor\u00eda dependen de una primitiva criptogr\u00e1fica conocida como primitiva ciega de Chaum (<strong>Chaumian blinding<\/strong>), que proporcionaba una moneda con un alto grado de privacidad, pero que no llegar\u00eda a despegar debido a su dependencia de un intermediario centralizado. En 1998,\u00a0<strong>b-Money<\/strong>\u00a0de Wei Dai, se convirti\u00f3 en la primera propuesta que introducir\u00eda la idea de creaci\u00f3n de dinero a trav\u00e9s de la resoluci\u00f3n de puzzles computacionales, as\u00ed como el consenso descentralizado, pero la propuesta se mostr\u00f3 escasa en los detalles de c\u00f3mo podr\u00eda ser implementado \u00e9ste consenso descentralizado en la pr\u00e1ctica. En 2005, Hal Finney introdujo el concepto de \u201c<strong>pruebas reutilizables de trabajo<\/strong>\u201c, un sistema que utilizaba algunas ideas de b-Money junto con, los rompecabezas computacionalmente dif\u00edciles de romper de Adam Back de tipo Hashcash, para volver a crear un concepto de criptomoneda, pero que una vez m\u00e1s, se quedar\u00eda corta al apoyarse en el uso de inform\u00e1tica de confianza en el backend. Fue en 2009, \u00a0cuando se implementa por primera vez, en la pr\u00e1ctica, una moneda descentralizada por Satoshi Nakamoto, combinando primitivas ya establecidas para la gesti\u00f3n de la propiedad, a trav\u00e9s de la criptograf\u00eda de clave p\u00fablica, m\u00e1s un algoritmo de consenso para llevar la cuenta de qui\u00e9n es el due\u00f1o de las monedas, conocido como \u201cprueba de trabajo\u201d.<\/p>\n<p>El mecanismo detr\u00e1s de la prueba de trabajo fue un gran avance, ya que resuelve simult\u00e1neamente dos problemas. En primer lugar, proporciona un algoritmo de consenso simple y moderadamente eficaz, permitiendo que los nodos de la red, se pongan de acuerdo colectivamente, en un conjunto de actualizaciones perfectas del estado actual del libro contable de Bitcoin. En segundo lugar, proporciona un mecanismo para permitir la entrada libre en el proceso de consenso, resolviendo el problema pol\u00edtico de decidir qui\u00e9n va a influir en el consenso, y evitando al mismo tiempo los ataques de tipo Sybil. Lo hace mediante la sustituci\u00f3n de dos barreras: la barrera formal para participar, es decir, el requisito de estar registrado como una entidad \u00fanica en una lista particular, y la barrera econ\u00f3mica \u2013 el peso de un solo nodo en el proceso de votaci\u00f3n por consenso es directamente proporcional a la potencia de c\u00e1lculo de la que el nodo dispone. Desde entonces, se ha propuesto un enfoque alternativo, llamado\u00a0<em>prueba de participaci\u00f3n<\/em>\u00a0(<em>proof of stake)<\/em>, en donde el peso de un nodo debe ser proporcional a su posesi\u00f3n de moneda y no a sus recursos computacionales; la discusi\u00f3n sobre los m\u00e9ritos relativos de los dos enfoques van m\u00e1s all\u00e1 del alcance de este documento, pero cabe se\u00f1alar que ambos pueden ser utilizados y servir como columna vertebral de una criptomoneda.<\/p>\n<h3>Bitcoin c\u00f3mo un Sistema de Transici\u00f3n de Estados<\/h3>\n<div class=\"slate-resizable-image-embed slate-image-embed__resize-full-width\"><img decoding=\"async\" src=\"https:\/\/media.licdn.com\/dms\/image\/C4D12AQGRbST9wPhr5A\/article-inline_image-shrink_400_744\/0\/1520065774398?e=1722470400&amp;v=beta&amp;t=mmIVOnenSf5-2OZ0VIvUcmtoV--fhpbbG9tL9z6I2D4\" data-media-urn=\"\" data-li-src=\"https:\/\/media.licdn.com\/dms\/image\/C4D12AQGRbST9wPhr5A\/article-inline_image-shrink_400_744\/0\/1520065774398?e=1722470400&amp;v=beta&amp;t=mmIVOnenSf5-2OZ0VIvUcmtoV--fhpbbG9tL9z6I2D4\" \/><\/div>\n<p>Desde un punto de vista t\u00e9cnico, el libro contable de una criptomoneda como Bitcoin, puede ser visto \u00a0como un sistema de transici\u00f3n de estados, donde hay un \u201cestado\u201d inicial (que consiste en el estado de propiedad de todos los Bitcoin existentes) y una \u201cfunci\u00f3n de transici\u00f3n de estado\u201d que toma un estado (inicial) y una transacci\u00f3n y emite un nuevo estado, que es el resultado. En un sistema bancario est\u00e1ndar, por ejemplo, el estado es un balance, una transacci\u00f3n es una solicitud para mover X$ de A hasta B, y donde la funci\u00f3n de transici\u00f3n de estado reduce el valor en la cuenta de A por X$ y aumenta el valor de la cuenta B en X$. De manera que si la cuenta de A tiene menos de X$, en primer lugar, la funci\u00f3n de transici\u00f3n de estado devuelve un error. Por lo tanto, esta operativa se puede definir formalmente como:<\/p>\n<h5>APPLY(S,TX) -&gt; S\u2019 o ERROR<\/h5>\n<p>En el sistema bancario que se ha definido anteriormente:<\/p>\n<h5>APPLY({ Alice: $50, Bob: $50 },\u201denviar $20 de Alice a Bob\u201d) = { Alice: $30, Bob: $70 }<\/h5>\n<p>Pero:<\/p>\n<h5>APPLY({ Alice: $50, Bob: $50 },\u201denviar $70 de Alice a Bob\u201d) = ERROR<\/h5>\n<p>El \u201cestado\u201d en Bitcoin es la colecci\u00f3n de todas las monedas (t\u00e9cnicamente, \u201csalidas no utilizadas de una transacci\u00f3n\u201d o UTXO o UTXoutput) que han sido acu\u00f1adas y todav\u00eda no gastadas, cada UTXO tiene una denominaci\u00f3n y un propietario (definida por una direcci\u00f3n de 20 bytes que es esencialmente una clave criptogr\u00e1fica p\u00fablica [1]). Una transacci\u00f3n contiene una o m\u00e1s entradas, cada entrada contiene una referencia a una UTXO existente y una firma criptogr\u00e1fica producida por la clave privada asociada con la direcci\u00f3n del propietario, y una o m\u00e1s salidas, cada salida contiene una nueva UTXO que se a\u00f1adir\u00e1 al estado.<\/p>\n<p>El funci\u00f3n de transici\u00f3n de estado APPLY(S,TX) -&gt; S\u2019\u00a0puede definirse aproximadamente del modo siguiente:<\/p>\n<ol>\n<li>Por cada entrada en TX:\n<ul>\n<li>Si la UTXO referenciada no est\u00e1 en S, devolver un error.<\/li>\n<li>Si la firma proporcionada no coincide con el propietario de la UTXO, devolver un error.<\/li>\n<\/ul>\n<\/li>\n<li>Si la suma de todas las entradas UTXO es menor que la suma de todas las salidas UTXO, devolver un error.<\/li>\n<li>Devolver Scon todas las entradas UTXO eliminadas y con todas las salidas UTXO a\u00f1adidas.<\/li>\n<\/ol>\n<p>La primera mitad de la primera etapa, impide al remitente de la transacci\u00f3n, gastar monedas que no existen, mientras que la segunda mitad de la primera etapa, impide al remitente de la transacci\u00f3n gastar las monedas de otras personas. El segundo paso sirve para hacer cumplir la conservaci\u00f3n del valor. Con el fin de utilizar este mecanismo para el pago, el protocolo funciona del modo siguiente: Supongamos que Alicia quiere enviar 11,7 BTC a Bob. En primer lugar, Alicia buscar\u00e1 un conjunto de transacciones UTXO que est\u00e9n disponibles y en donde ella sea la propietaria, al menos, de un m\u00ednimo de 11,7 BTC. Siendo realistas, Alicia no ser\u00e1 capaz de encontrar exactamente 11,7 BTC; supongamos que la cantidad m\u00e1s peque\u00f1a que puede conseguir es 6 + 4 + 2 = 12. Lo que a continuaci\u00f3n har\u00e1, ser\u00e1 crear una transacci\u00f3n con esas tres entradas y dos salidas, tales que la primera salida ser\u00e1 de 11,7 BTC con la direcci\u00f3n de Bob como propietario, y la segunda salida ser\u00e1 de 0,3 BTC, correspondiente al \u00a0\u201ccambio\u201d que queda, y que tendr\u00e1 como due\u00f1o a ella misma.<\/p>\n<h3>Miner\u00eda<\/h3>\n<div class=\"slate-resizable-image-embed slate-image-embed__resize-full-width\"><img decoding=\"async\" src=\"https:\/\/media.licdn.com\/dms\/image\/C4E12AQGNCRg-WGL7tg\/article-inline_image-shrink_400_744\/0\/1520548848169?e=1722470400&amp;v=beta&amp;t=9uqBlJOc4aLr8kmzSN8pokaC9dgKPTDZwKgTQQZGsmE\" data-media-urn=\"\" data-li-src=\"https:\/\/media.licdn.com\/dms\/image\/C4E12AQGNCRg-WGL7tg\/article-inline_image-shrink_400_744\/0\/1520548848169?e=1722470400&amp;v=beta&amp;t=9uqBlJOc4aLr8kmzSN8pokaC9dgKPTDZwKgTQQZGsmE\" \/><\/div>\n<p>Si tuvi\u00e9ramos acceso a un servicio centralizado de confianza, este sistema ser\u00eda trivial de implementar; simplemente podr\u00eda codificarse exactamente como se describe, usando el disco duro de un servidor centralizado para realizar un seguimiento de los estados. Sin embargo, con Bitcoin, lo que estamos tratando de construir, es un sistema de moneda descentralizada, por lo que tendremos que combinar, por un lado, un sistema para controlar el estado de las transacciones y por otro, un sistema de consenso, con el fin de garantizar que todo el mundo est\u00e1 de acuerdo en el orden de las operaciones. El proceso de consenso descentralizado de Bitcoin, requiere de nodos de red para intentar producir, continuamente, paquetes de transacciones denominados \u201cbloques\u201d. La red est\u00e1 dise\u00f1ada para crear m\u00e1s o menos un bloque cada diez minutos, de modo que cada bloque contiene un sello de tiempo, y una referencia (un hash) al bloque anterior, as\u00ed como \u00a0una lista de todas las transacciones que se han producido desde el \u00faltimo bloque. Con el paso del tiempo, se va creando una, cada vez mayor, cadena de bloques o \u201cblockchain\u201d persistente, que se actualiza constantemente para representar el \u00faltimo estado del libro contable de Bitcoin.<\/p>\n<p>El algoritmo para comprobar si un bloque es v\u00e1lido, expresado en este paradigma, es el siguiente:<\/p>\n<ol>\n<li>Comprobar si el bloque anterior referenciado por el bloque actual existe y es v\u00e1lido.<\/li>\n<li>Comprobar que el sello de tiempo del bloque actual es mayor que el del bloque previo pero menor de 2 horas en el futuro.<\/li>\n<li>Comprobar que la prueba de trabajo del bloque es v\u00e1lida.<\/li>\n<li>Sea S[0]el estado al final del bloque anterior.<\/li>\n<li>Supongamos que TX es la lista de transacci\u00f3n del bloque con n\u00a0 Para todo\u00a0i\u00a0en\u00a00\u2026n-1, establecer \u00a0S[i+1] = APPLY(S[i],TX[i]).\u00a0Si alguna devuelve un error, salir y devolver falso (false).<\/li>\n<li>Devolver verdadero (true), y registrar S[n]\u00a0como el estado al final de este bloque.<\/li>\n<\/ol>\n<p>En esencia, cada transacci\u00f3n dentro del bloque, debe proporcionar una transici\u00f3n de estado v\u00e1lida desde lo que fue su estado original antes de que la transici\u00f3n fuera ejecutada, hasta el nuevo estado. N\u00f3tese, que el estado no est\u00e1 codificado en el bloque de ninguna manera; es puramente una abstracci\u00f3n recordada por el nodo de validaci\u00f3n y s\u00f3lo puede (de forma segura) ser calculada, para cualquier bloque, partiendo del estado g\u00e9nesis y aplicando secuencialmente cada transacci\u00f3n a cada bloque. Adem\u00e1s, el orden en que el minero incluye las transacciones dentro del bloque importa, es decir, si hay dos transacciones A y B en un bloque, tal que B gasta una UTXO creada por A, entonces el bloque ser\u00e1 v\u00e1lido si A viene antes que B, pero no de otra manera.<\/p>\n<p>La \u00fanica condici\u00f3n de validez presente en la lista de arriba, que no se encuentra en otros sistemas, es el requisito de \u201cprueba de trabajo\u201d. La condici\u00f3n precisa es que el hash doble SHA256 de cada bloque, tratado como un n\u00famero de 256 bits, debe ser inferior a un valor ajustado din\u00e1micamente, que en el momento de escribir este art\u00edculo es de aproximadamente 2187. El objetivo es hacer la creaci\u00f3n de un bloque computacionalmente dif\u00edcil, de este modo, se previene que atacantes de tipo Sybil pudieran rehacer toda la cadena de bloques a su favor. Debido a que SHA256 est\u00e1 dise\u00f1ado para ser una funci\u00f3n pseudoaleatoria completamente impredecible, la \u00fanica manera de crear un bloque v\u00e1lido es simplemente por ensayo y error, increment\u00e1ndolo repetidamente solo una vez y ver si el nuevo hash coincide.<\/p>\n<p>Con el objetivo actual de ~2187, la red debe realizar un promedio de ~269\u00a0intentos antes de encontrar un bloque v\u00e1lido. En general, el valor objetivo se vuelve a recalibrar cada 2016 bloques, lo que significa que, en promedio, un nuevo bloque se produce por alg\u00fan nodo de la red, cada diez minutos. Con el fin de compensar a los mineros por este trabajo computacional, el minero de cada bloque tiene derecho a incluir una transacci\u00f3n que le otorga a si mismo 25 BTC sacados de la nada. Adem\u00e1s, si cualquier transacci\u00f3n tiene un valor mayor en sus entradas (inputs) que en sus salidas (outputs), la diferencia tambi\u00e9n va al minero en concepto de \u201ctarifa de transacci\u00f3n\u201d o \u201ctransaction fee\u201d. Por cierto, este es el \u00fanico mecanismo por el cual los BTC se emiten, el estado g\u00e9nesis no conten\u00eda monedas.<\/p>\n<p>Con el fin de comprender mejor los efectos de la miner\u00eda, examinemos lo que suceder\u00eda en el caso de un atacante malicioso. Dado que la criptograf\u00eda subyacente de Bitcoin se conoce por ser segura, un supuesto atacante se centrar\u00eda en la parte del sistema Bitcoin que no est\u00e1 protegida por la criptograf\u00eda directamente: el orden de las transacciones. La estrategia del atacante es simple:<\/p>\n<ol>\n<li>Enviar 100 BTC a un comerciante a cambio de alg\u00fan producto (preferiblemente un bien digital de r\u00e1pida entrega)<\/li>\n<li>Esperar a la entrega del producto<\/li>\n<li>Producir otra transacci\u00f3n enviando los mismos 100 BTC a s\u00ed mismo.<\/li>\n<li>Tratar de convencer a la red que la transacci\u00f3n enviada a si mismo fue la que se realiz\u00f3 primero.<\/li>\n<\/ol>\n<p>Una vez que el paso (1) ha tenido lugar, despu\u00e9s de unos minutos, alg\u00fan minero incluir\u00e1 la transacci\u00f3n en un bloque, por ejemplo el bloque n\u00famero 270000. Despu\u00e9s de aproximadamente una hora, se habr\u00e1n a\u00f1adido cinco bloques m\u00e1s a la cadena despu\u00e9s de ese bloque, con cada uno de esos bloques indirectamente apuntado a la transacci\u00f3n y as\u00ed \u201cconfirmando\u201d la misma. En este punto, el comerciante aceptar\u00e1 el pago como finalizado y entregar\u00e1 el producto, y como estamos asumiendo que es un bien digital, la entrega es inmediata. Ahora, el atacante crea otra transacci\u00f3n enviando 100 BTCs a s\u00ed mismo. Si el atacante simplemente la libera, la transacci\u00f3n no ser\u00e1 procesada; los mineros intentaran ejecutar la funci\u00f3n APPLY(S,TX)\u00a0y observaran que TX\u00a0consume una \u00a0UTXO que no est\u00e1 en el estado que deber\u00eda ser. La opci\u00f3n del atacante ser\u00e1 crear una bifurcaci\u00f3n (fork) de la cadena de bloques, comenzando a minar otra versi\u00f3n del bloque 270000 que apuntar\u00e1 al bloque 269999 como padre, pero con la nueva transacci\u00f3n en lugar de la antigua. Dado que los datos del bloque son diferentes, esto requiere rehacer la prueba de trabajo. Por tanto, la nueva versi\u00f3n del bloque 270000 del atacante tiene un hash diferente, por lo que los bloques originales del 270001 al \u00a0270005, no estar\u00e1n apuntando a \u00e9l. Es decir, la cadena original y la nueva cadena del atacante est\u00e1n completamente separadas. La regla es que cuando hay una bifurcaci\u00f3n (fork) se tome la cadena de bloques m\u00e1s larga como verdadera, y as\u00ed los mineros leg\u00edtimos trabajaran en la cadena de 270,005 mientras que el atacante solo estar\u00e1 trabajando en la cadena de 270,000. Para que el atacante pudiera hacer de su cadena de bloques la m\u00e1s larga, tendr\u00eda que tener m\u00e1s poder computacional que el resto de la red combinada con el fin de ponerse al d\u00eda (es decir, \u201cel ataque del 51%\u201d).<\/p>\n<h3>\u00c1rboles de Merkle<\/h3>\n<div class=\"slate-resizable-image-embed slate-image-embed__resize-full-width\"><img decoding=\"async\" src=\"https:\/\/media.licdn.com\/dms\/image\/C4E12AQG2PKWt9mLa8w\/article-inline_image-shrink_400_744\/0\/1520548848248?e=1722470400&amp;v=beta&amp;t=ngtItqocv5w5mRPbZEVSq5EDnqBIAVVg_8KzbRn8-5o\" data-media-urn=\"\" data-li-src=\"https:\/\/media.licdn.com\/dms\/image\/C4E12AQG2PKWt9mLa8w\/article-inline_image-shrink_400_744\/0\/1520548848248?e=1722470400&amp;v=beta&amp;t=ngtItqocv5w5mRPbZEVSq5EDnqBIAVVg_8KzbRn8-5o\" \/><\/div>\n<p><em>Izquierda: es suficiente con presentar solamente un peque\u00f1o n\u00famero de nodos en un \u00e1rbol de Merkle para dar una prueba de la validez de la rama.<\/em><\/p>\n<p><em>Derecha: cualquier intento de cambiar cualquier parte de un \u00e1rbol de Merkle finalmente dar\u00e1 una inconsistencia en alg\u00fan lugar de la cadena.<\/em><\/p>\n<p>Una caracter\u00edstica importante de la escalabilidad en Bitcoin es que los bloques se almacenan en una estructura de datos de m\u00faltiples niveles. El \u201chash\u201d de un bloque actualmente es solamente el hash de la cabecera del bloque, un fragmento de datos de unos 200 bytes que contiene la fecha y hora (sello de tiempo), \u00a0el nonce (en criptograf\u00eda se llama nonce a un n\u00famero arbitrario que solamente se utiliza una \u00fanica vez al realizar alg\u00fan tipo de operaci\u00f3n), el hash del bloque anterior y el hash ra\u00edz de una estructura de datos llamada \u00e1rbol de Merkle que almacena todas las transacciones del bloque. Un \u00e1rbol de Merkle es un tipo de \u00e1rbol binario, compuesto por un conjunto de nodos con un gran n\u00famero de nodos hoja en la parte inferior del \u00e1rbol que contiene los datos subyacentes, un conjunto de nodos intermedios donde cada nodo es el hash de sus dos hijos, y finalmente un \u00fanico nodo ra\u00edz, tambi\u00e9n formado por el hash de sus hijos, que representa la parte superior (\u201ctop\u201d) del \u00e1rbol. El objetivo de los \u00e1rboles de Merkle es permitir que los datos de un bloque puedan ser entregados por partes: un nodo puede descargar solamente la cabecera de un bloque desde un fuente, y otra peque\u00f1a parte del \u00e1rbol relevante para \u00e9l, \u00a0desde otra fuente, y todav\u00eda asegurar que los datos son correctos. La raz\u00f3n por lo que esto funciona es porque los hashes se propagan hacia arriba: si un usuario malintencionado intenta hacer un cambio en una transacci\u00f3n falsa en la parte inferior del \u00e1rbol de Merkle, este cambio provocar\u00e1 un cambio en el nodo superior y seguidamente otro cambio en el nodo por encima de este, hasta que finalmente, se produzca un cambio en la ra\u00edz del \u00e1rbol y por tanto en el hash del bloque, haciendo que el protocolo tenga que registrarlo como un bloque completamente diferente (y casi con toda seguridad con una prueba de trabajo inv\u00e1lida).<\/p>\n<p>El protocolo de \u00e1rbol de Merkle es, sin duda esencial para la sostenibilidad a largo plazo. Un \u201cnodo completo\u201d en la red Bitcoin, que almacena y procesa la totalidad de cada bloque, requiere unos 15 GB de espacio en disco en Abril de 2014, cantidad que est\u00e1 creciendo a un ritmo de un gigabyte al mes. Actualmente, esto es viable para algunos ordenadores de escritorio pero no para m\u00f3viles, posteriormente solo empresas y aficionados ser\u00e1n capaces de participar. El protocolo conocido como \u201cverificaci\u00f3n del pago simplificado\u201d (\u201csimplified payment verification\u201d o SPV) permite que otra clase de nodos puedan existir, los llamados nodos ligeros o \u201clight nodes\u201d, que descargan los encabezados de los bloques, realizan la verificaci\u00f3n de la prueba de trabajo en \u00e9stos, y luego descargan solamente las \u201cramas\u201d asociadas a las transacciones que son relevantes para ellos. Esto permite que los nodos ligeros determinar con una fuerte garant\u00eda de seguridad cual es el estado de cualquier transacci\u00f3n Bitcoin, y sus balances actuales, descargando solamente una porci\u00f3n muy peque\u00f1a de toda la cadena de bloques.<\/p>\n<h3>Aplicaciones Alternativas de la Cadena de Bloques (Blockchain)<\/h3>\n<p>La idea de coger la tecnolog\u00eda subyacente de la cadena de bloques y aplicarla a otros conceptos tambi\u00e9n tiene una larga historia. En 2005, Nick Szabo y su \u201cT\u00edtulos de propiedad seguros con autorizaci\u00f3n de propietario\u201d, es un documento que describe c\u00f3mo \u201clos nuevos avances en la tecnolog\u00eda de base de datos replicada\u201d servir\u00edan para que un sistema basado en la cadena de bloques, almacenara un registro de qui\u00e9n es due\u00f1o de qu\u00e9 tierra, junto con la creaci\u00f3n de un marco elaborado que incluir\u00eda conceptos como la prescripci\u00f3n adquisitiva y los impuestos sobre la tierra. Sin embargo y por desgracia, no exist\u00eda un sistema eficaz de replicaci\u00f3n de base de datos en ese momento, por lo que el protocolo nunca fue implementado en la pr\u00e1ctica. Despu\u00e9s de 2009, sin embargo, una vez que el consenso descentralizado de Bitcoin se desarroll\u00f3 comenzaron a emerger una serie de aplicaciones alternativas:<\/p>\n<ul>\n<li><strong>Namecoin<\/strong>\u00a0\u2013 creada en 2010,\u00a0<a href=\"https:\/\/namecoin.org\/\" target=\"_blank\" rel=\"nofollow noopener\">Namecoin<\/a>\u00a0se describe mejor como una base de datos de registro de nombres descentralizada. En los protocolos descentralizados como Tor, Bitcoin y BiMessage, tiene que haber alguna manera de identificar las cuentas para que otras personas puedan interactuar con ellas, pero en todas las soluciones existentes, el \u00fanico tipo de identificador disponible, es un hash pseudoaleatorio como: 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. Lo ideal y lo que a uno le gustar\u00eda, es ser capaz de tener una cuenta con un nombre como \u201cGeorge\u201d. Sin embargo, el problema es que si una persona puede crear una cuenta llamada \u201cgeorge\u201d, entonces otra persona puede utilizar el mismo proceso para registrar \u201cgeorge\u201d para s\u00ed, y hacerse pasar por la primera persona. La \u00fanica soluci\u00f3n es un paradigma del tipo first-to-file, en donde el primer registrador tiene \u00e9xito y el segundo no \u2013 un problema perfectamente adecuado para el protocolo de consenso Bitcoin. Namecoin es la implementaci\u00f3n m\u00e1s antigua y exitosa, de un sistema de registro de nombres usando esa idea.<\/li>\n<li><strong>Colored coins<\/strong>\u00a0\u2013 el objetivo de las monedas coloreadas es servir como un protocolo que permita a la gente crear sus propias monedas digitales \u00a0o, en el caso trivial (pero importante) de una moneda con una sola unidad, crear fichas digitales (digital tokens) sobre la cadena de bloques de Bitcoin. En el protocolo de las monedas coloreadas, alguien \u201cemite\u201d una nueva moneda asignando p\u00fablicamente un color determinado a una transacci\u00f3n Bitcoin UTXO espec\u00edfica, as\u00ed el protocolo definir\u00e1, de forma recursiva, el color de otra UTXO para que sea del mismo color que el de las entradas que se pasaron para crearla (aplic\u00e1ndose \u00a0algunas reglas especiales en el caso de darse entradas mixtas de color). Esto permite a los usuarios tener carteras que contienen solamente UTXO de un color espec\u00edfico y que pueden enviar de la misma manera que los Bitcoin normales, y adem\u00e1s usar la cadena de bloques para determinar el color de cada UTXO que reciben.<\/li>\n<li><strong>Metacoins<\/strong>\u00a0\u2013 la idea detr\u00e1s de las Metacoin es tener un protocolo que funciona en la parte superior del protocolo Bitcoin, utilizando las transacciones Bitcoin para almacenar a su vez las transacciones de las Metacoins, las cuales tienen funciones de transici\u00f3n de estado diferentes y que llamaremos,\u00a0APPLY\u2019. Debido a que en el protocolo Metacoin no se puede impedir que aparezcan transacciones Metacoin no v\u00e1lidas sobre la cadena de bloques de Bitcoin, se a\u00f1ade una regla tal que si APPLY'(S,TX) devuelve un error, \u00a0el valor por defecto del protocolo ser\u00e1 APPLY'(S,TX) = S. Esto proporciona un mecanismo f\u00e1cil para la creaci\u00f3n de un protocolo arbitrario para una criptomoneda, potencialmente con caracter\u00edsticas avanzadas pero que no se puede implementar en el interior de Bitcoin, y que tendr\u00eda un coste muy bajo de desarrollo porque las complejidades de la miner\u00eda y la interconexi\u00f3n en red ya son tratadas por el propio protocolo Bitcoin. Las Metacoins se han utilizado para implementar algunas clases de contratos financieros, registro de nombres e intercambio descentralizado.<\/li>\n<\/ul>\n<p>En general, hay dos enfoques entorno a la construcci\u00f3n de un protocolo de consenso: la construcci\u00f3n de una red independiente, y la creaci\u00f3n de un protocolo en la parte superior de Bitcoin. El primer enfoque, con un \u00e9xito razonable en el caso de aplicaciones como Namecoin, es dif\u00edcil de implementar; cada implementaci\u00f3n individual necesita de su propia cadena de bloques independiente, as\u00ed como construir y probar todas las transiciones de estado necesarias y el c\u00f3digo de interconexi\u00f3n de red. Adem\u00e1s, podemos predecir que el conjunto de aplicaciones que usaran la tecnolog\u00eda de consenso descentralizado seguir\u00e1 una distribuci\u00f3n de leyes de potencia, en donde la gran mayor\u00eda de las aplicaciones ser\u00e1n demasiado peque\u00f1as como para justificar su propia cadena de bloques, por no decir que existen grandes clases de aplicaciones descentralizadas, particularmente las organizaciones aut\u00f3nomas descentralizadas, que necesitan interactuar unas con otras.<\/p>\n<p>Por otro lado, la aproximaci\u00f3n basada en Bitcoin tiene el defecto de que no hereda las caracter\u00edsticas de verificaci\u00f3n de pago simplificado de Bitcoin. SPV funciona para Bitcoin, porque puede utilizar la profundidad de la cadena de bloques como un sustituto para la validez; en alg\u00fan momento, alguno de los antecesores de una transacci\u00f3n estar\u00e1n lo suficientemente lejos en el tiempo, que es seguro decir que leg\u00edtimamente forman parte del estado. Por otro lado, los meta protocolos basados en la cadena de bloques, no pueden obligar a la cadena de bloques a no incluir las transacciones que no son v\u00e1lidas en el contexto de sus propios protocolos. Por lo tanto, una implementaci\u00f3n de un meta protocolo SPV totalmente segura necesitar\u00eda retroceder todo el camino, hasta el comienzo de la cadena de bloques de Bitcoin, para determinar si ciertas transacciones son v\u00e1lidas o no. Actualmente, todas las implementaciones \u201cligeras\u201d de protocolos de metadatos basados en Bitcoin, dependen de un servidor de confianza para proporcionar los datos, lo que posiblemente es un resultado claramente poco \u00f3ptimo especialmente cuando uno de los prop\u00f3sitos principales de una criptomoneda es eliminar la necesidad de la confianza.<\/p>\n<h3>Secuencias de Comandos (Guiones o Scripts)<\/h3>\n<p>Incluso sin ninguna extensi\u00f3n, actualmente el protocolo Bitcoin facilita una versi\u00f3n simple del concepto de \u201ccontrato inteligente\u201d (smart contracts). En Bitcoin una UTXO puede no solamente pertenecer a una determinada clave, sino tambi\u00e9n a una complicada secuencia de comandos (o guiones o scripts) expresados en un lenguaje de programaci\u00f3n que se basa en el uso de una sencilla pila. En este paradigma, una transacci\u00f3n que haga el gasto de esa UTXO debe proporcionar los datos que satisfagan la secuencia de comandos. De hecho, incluso el mecanismo de propiedad de clave p\u00fablica b\u00e1sica se implementa a trav\u00e9s de una secuencia de comandos: se toma una firma de curva el\u00edptica como entrada, se verifica contra la transacci\u00f3n y la direcci\u00f3n que posee la UTXO, y se devuelve 1 si la verificaci\u00f3n es exitosa y 0 en caso contrario.<\/p>\n<p>Existen otras secuencias de comandos m\u00e1s complicadas, para casos de uso adicionales. Por ejemplo, se puede construir una secuencia de comandos que requiera el uso de dos de tres claves privadas dadas para hacer una validaci\u00f3n (\u201cmultisig\u201d), configuraci\u00f3n que es \u00fatil para cuentas corporativas, de ahorro o en algunas situaciones de aplicaciones comerciales. Las secuencias de comandos tambi\u00e9n pueden usarse para pagar recompensas por la soluci\u00f3n de problemas computacionales, e incluso uno puede construir una secuencia de comandos que diga algo como \u201c\u00e9sta Bitcoin UTXO es tuya si puedes proporcionar una prueba SPV de haberme enviado una transacci\u00f3n Dogecoin con \u00e9sta denominaci\u00f3n\u201d, lo que en esencia permitir\u00eda el intercambio descentralizado entre criptomonedas (cross-cryptocurrency exchange).<\/p>\n<p>Sin embargo, el lenguaje de secuencia de comandos implementado en Bitcoin tiene varias limitaciones importantes:<\/p>\n<ul>\n<li><strong>No es Turing-completo<\/strong>\u00a0\u2013 es decir, aunque hay un subconjunto de operaciones que el lenguaje de secuencia de comandos de Bitcoin soporta, no lo soporta todo. La categor\u00eda principal que falta son los bucles, que no existen para evitar la existencia de bucles infinitos durante la verificaci\u00f3n de las transacciones; \u00a0teoricamente es un obstaculo superable para los programadores, ya que cualquier bucle puede ser simulado simplemente repitiendo el c\u00f3digo subyacente muchas veces con una sentencia if, pero que da lugar a secuencias de comandos ineficientes en cuesti\u00f3n de espacio. Por ejemplo, la implementaci\u00f3n de un algoritmo de firma de curva el\u00edptica alternativo, probablemente requerir\u00eda de 256 multiplicaciones repetidas incluidas de forma individual en el c\u00f3digo.<\/li>\n<li><strong>Value-blindness<\/strong>\u00a0\u2013 no hay manera de que una secuencia de comandos UTX0 provea un control de grano fino sobre la cantidad que puede ser retirada. Por ejemplo, un caso de uso interesante seria el de un or\u00e1culo en un contrato de cobertura, donde dos partes A y B ponen Bitcoin por valor de 1.000$, despu\u00e9s de 30 d\u00edas la secuencia de comandos env\u00eda 1.000$ en BTC a A y el resto a B, para poder hacerlo se requiere del or\u00e1culo para determinar el valor que tiene 1 BTC en USD. Aunque esta soluci\u00f3n demuestra ser una enorme mejora en t\u00e9rminos de confianza y requisitos de infraestructura, sobre las soluciones totalmente centralizadas que est\u00e1n disponibles actualmente, deja cuestiones abiertas. Debido a que las UTXO son del tipo o todo o nada, la \u00fanica manera de lograrlo es a trav\u00e9s de un truco muy ineficiente que consiste en tener muchas UTXO con denominaciones diferentes (por ejemplo. una UTXO de 2k para cada k hasta 30) y que habr\u00e1 que elegir qu\u00e9 UTXO se envia a A y cual a B.<\/li>\n<li><strong>Ausencia de estado<\/strong>\u00a0\u2013 \u00a0Una UTXO puede ser gastada o no, no hay oportunidad para contratos de varias etapas o secuencias de comandos que mantengan cualquier otro estado interno m\u00e1s all\u00e1 de eso, lo que hace que sea dif\u00edcil hacer contratos de m\u00faltiples estados, ofertas de intercambio descentralizadas o protocolos criptogr\u00e1ficos de dos \u00e9tapas (necesarios para tener primas computacionales seguras). Tambi\u00e9n significa que las UTXO s\u00f3lo se pueden utilizar para construir contratos simples de un solo uso y no contratos \u201ccon estado\u201d m\u00e1s complejos, tales como las organizaciones descentralizadas y haciendo dif\u00edcil de implementar meta-protocolos adicionales. Este estado binario combinado con el value-blindness anterior, significa que otra aplicaci\u00f3n importante, como son los l\u00edmites de retirada de dinero, son imposibles de realizar.<\/li>\n<li><strong>Blockchain-blindness<\/strong>\u00a0\u2013 Las UTXO son \u201cciegas\u201d cara a los datos de la cadena de bloques como puede ser el nonce, \u00a0el sello de tiempo o el hash del bloque previo. Esto limita seriamente las aplicaciones en los juegos de azar y otras categor\u00edas, al privar al lenguaje de una fuente potencialmente valiosa de aleatoriedad.<\/li>\n<\/ul>\n<p>As\u00ed, vemos tres enfoques para la creaci\u00f3n de aplicaciones avanzadas sobre la base de las criptomonedas: construcci\u00f3n de una nueva blockchain, usar secuencias de comandos por encima de \u00a0Bitcoin, y construir un meta-protocolo tambi\u00e9n por encima de Bitcoin. La construcci\u00f3n de una nueva blockchain permite una libertad ilimitada en la construcci\u00f3n de un conjunto de caracter\u00edsticas, pero a costa de tiempo de desarrollo, esfuerzo para ponerlo en marcha y seguridad. El uso de secuencias de comandos es f\u00e1cil de implementar y estandarizar, pero est\u00e1n muy limitados en sus capacidades y meta-protocolos, siendo adem\u00e1s f\u00e1cil que sufran fallos en escalabilidad. Con Ethereum, tenemos la intenci\u00f3n de construir un marco alternativo que proporciona ganancias a\u00fan mayores en la facilidad de desarrollo, as\u00ed como propiedades m\u00e1s fuertes en los clientes ligeros, mientras que al mismo tiempo permite que las aplicaciones compartan un entorno econ\u00f3mico y de seguridad en la cadena de bloques.<\/p>\n<h2>Ethereum<\/h2>\n<p>El objetivo de Ethereum es crear un protocolo alternativo para construir aplicaciones descentralizadas, proporcionando un conjunto diferente de posibilidades que creemos va a ser muy \u00fatil para este tipo de aplicaciones, con especial \u00e9nfasis en situaciones donde son importantes: un tiempo de desarrollo r\u00e1pido, la seguridad en aplicaciones peque\u00f1as y que rara vez se utilizan, y la capacidad de que aplicaciones diferentes interactuen de manera muy eficiente. Ethereum hace esto mediante la construcci\u00f3n de lo que es esencialmente una capa abstracta funcional definitiva: una cadena de bloques con un lenguaje de programaci\u00f3n integrado del tipo Turing-completo, que permite que cualquiera pueda escribir contratos inteligentes y aplicaciones descentralizadas que pueden crear sus propias reglas arbitrarias para la gesti\u00f3n de la propiedad, los formatos de transacci\u00f3n y las funciones de transici\u00f3n de estados. Una versi\u00f3n escueta de Namecoin se puede escribir en dos l\u00edneas de c\u00f3digo, y otros protocolos como monedas y sistemas de reputaci\u00f3n se pueden construir con menos de veinte. Los contratos inteligentes, las \u201ccajas\u201d criptogr\u00e1ficas que contienen un determinado valor y que s\u00f3lo se desbloquean si se cumplen ciertas condiciones, tambi\u00e9n puede ser incorporadas en la parte superior de la plataforma, con mucho m\u00e1s poder que el que ofrece el lenguaje de secuencias de comandos de Bitcoin, debido a los potencia a\u00f1adida del Turing-completo, el valor-conocimiento (value-awareness), el blockchain-conocimiento (blockchain-awareness)<a href=\"http:\/\/www.santiagomarquezsolis.com\/ethereum-whitepaper-traducido-al-castellano\/#_ftn1\" target=\"_blank\" rel=\"nofollow noopener\">[1]<\/a>\u00a0y el estado.<\/p>\n<h3>Cuentas Ethereum<\/h3>\n<p>En Ethereum, el estado se compone de objetos llamados \u201ccuentas\u201d, cada una de estas cuentas tiene una direcci\u00f3n y transiciones de estado, que pueden ser transferencias de valor o de informaci\u00f3n entre cuentas. Una cuenta de Ethereum contiene cuatro campos:<\/p>\n<ul>\n<li>El\u00a0<strong>nonce<\/strong>, un contador usado para asegurar que cada transacci\u00f3n puede ser procesada solamente una vez.<\/li>\n<li>El\u00a0<strong>balance actual de \u00e9ter (ether)<\/strong>\u00a0de la cuenta<\/li>\n<li>El\u00a0<strong>c\u00f3digo del contrato<\/strong>\u00a0de la cuenta, si existe<\/li>\n<li>El\u00a0<strong>almacenamiento de la cuenta<\/strong>\u00a0(vacio por defecto)<\/li>\n<\/ul>\n<p>\u201cEther\u201d \u00a0es el principal cripto-combustible de Ethereum, y se utilize para pagar los tasas de la transacci\u00f3n. \u00a0En general, hay dos tipos de cuentas: cuentas de propiedad externas (externally owned account o EOAs), controladas por una clave privada, y cuentas de contrato, controladas por un c\u00f3digo de contrato. Una cuenta de propiedad externa no tiene c\u00f3digo, y se pueden enviar mensajes desde ella mediante la creaci\u00f3n y la firma de una transacci\u00f3n; en una cuenta de contrato, cada vez que la cuenta de contrato recibe un mensaje, su c\u00f3digo se activa, lo que le permite leer y escribir en el almacenamiento interno y enviar otros mensajes o crear otros contratos de vuelta.<\/p>\n<p>Tenga en cuenta que los \u201ccontratos\u201d en Etereum no deben ser vistos como algo que debe ser \u201ccumplidos\u201d; m\u00e1s bien, son m\u00e1s como \u201cagentes aut\u00f3nomos\u201d que viven dentro del entorno de ejecuci\u00f3n de Ethereum, siempre ejecutan una pieza espec\u00edfica de c\u00f3digo cuando son \u201cempujados\u201d por un mensaje o una transacci\u00f3n, y que tiene un control directo sobre su propio balance de ether y su propia llave\/valor (key\/value) almacenada para realizar un seguimiento de las variables persistentes.<\/p>\n<h3>Mensajes y Transacciones<\/h3>\n<p>El t\u00e9rmino \u201ctransacci\u00f3n\u201d se utiliza en Ethereum para referirse a un paquete de datos firmado que almacena un mensaje para ser enviado desde una cuenta de propiedad externa (externally owned account o EOAs). Las transacciones contienen:<\/p>\n<ul>\n<li>El receptor del mensaje<\/li>\n<li>Una firma que identifica al remitente.<\/li>\n<li>La cantidad de \u00e9ter para transferir desde el emisor al receptor.<\/li>\n<li>Un campo de datos opcional.<\/li>\n<li>Un valor STARTGAS, que representa el n\u00famero m\u00e1ximo de pasos computacionales que se permite tomar a la ejecuci\u00f3n de las transacciones.<\/li>\n<li>Un valor GASPRICE, que representa la cuota que paga el remitente por cada paso computacional.<\/li>\n<\/ul>\n<p>Los tres primeros se corresponden con campos est\u00e1ndar que se esperan en cualquier criptomoneda. El campo de datos no tiene ninguna funci\u00f3n por defecto, pero la m\u00e1quina virtual tiene un c\u00f3digo de operaci\u00f3n mediante el cual un contrato puede tener acceso a estos datos; por ejemplo, si un contrato est\u00e1 funcionando como un servicio de registro de dominios en la cadena de bloques, entonces se podr\u00eda interpretar los datos que se pasan a ella como que contiene dos \u201ccampos\u201d, el primer campo ser\u00eda un dominio a registrar y el segundo campo la direcci\u00f3n IP para registrarlo. El contrato leer\u00eda estos valores a partir de los datos del mensaje y los colocar\u00eda apropiadamente en su sitio.<\/p>\n<p>Los campos STARTGAS y GASPRICE son cruciales en el modelo de servicio anti rechazo de Ethereum. A fin de evitar bucles infinitos accidentales u hostiles u otro desperdicio computacional en el c\u00f3digo, se requiere que cada transacci\u00f3n establezca un l\u00edmite en el n\u00famero de pasos de c\u00e1lculo de ejecuci\u00f3n que el c\u00f3digo puede utilizar. La unidad fundamental de computaci\u00f3n es el \u201cgas\u201d; y por lo general, un paso computacional cuesta 1 unidad de gas. Hay algunas operaciones con un mayor costo de gas porque son m\u00e1s caras o bien computacionalmente hablando, o bien porque aumentan la cantidad de datos que deben ser almacenados como parte de su estado. Tambi\u00e9n hay una tarifa de 5 unidades de gas por cada byte de datos de la transacci\u00f3n. La intenci\u00f3n del sistema de tasas es exigir a un posible atacante el pago proporcional por todos los recursos que consuma, incluyendo la computaci\u00f3n, el ancho de banda y el almacenamiento. Por lo tanto, cualquier transacci\u00f3n que se dirige a la red consume una mayor cantidad de cualquiera de estos recursos y debe tener una cuota de gas m\u00e1s o menos proporcional al incremento.<\/p>\n<h3>Mensajes<\/h3>\n<p>Los contratos tienen la habilidad de enviar \u201cmensajes\u201d a otros contratos. Los mensajes son objetos virtuales que nunca son serializados y que existen solamente en el entorno de ejecuci\u00f3n de Ethereum. Un mensaje contiene:<\/p>\n<ul>\n<li>El remitente del mensaje (impl\u00edcito).<\/li>\n<li>El receptor o beneficiario del mensaje.<\/li>\n<li>La cantidad de ether a transferir junto con el mensaje.<\/li>\n<li>Un campo de datos opcional.<\/li>\n<li>Un valor STARTGAS.<\/li>\n<\/ul>\n<p>En esencia, un mensaje es como una transacci\u00f3n, excepto porque son originadas por un contrato y no por un actor externo. Un mensaje se produce cuando un contrato que est\u00e1 actualmente ejecutando c\u00f3digo ejecuta la llamada CALL\u00a0opcode, que produce y ejecuta un mensaje. Como una transacci\u00f3n, un mensaje se dirige a un receptor que ejecuta su c\u00f3digo. Por lo tanto, los contratos pueden tener relaciones con otros contratos exactamente de la misma manera que los actores externos pueden.<\/p>\n<p>Tenga en cuenta que la cantidad de gas asignada a una transacci\u00f3n o a un contrato, se aplica al total del gas consumido por esa transacci\u00f3n y a todas sus sub-ejecuciones. Por ejemplo, si un actor externo A env\u00eda una transacci\u00f3n a B con 1000 unidades de gas y B consume 600 unidades de gas antes de enviar un mensaje a C, y la ejecuci\u00f3n interna de C consume 300 unidades de gas antes de finalizar, entonces B podr\u00e1 gastar otras 100 unidades de gas antes de quedarse sin el.<\/p>\n<h3>Funci\u00f3n de Transici\u00f3n de Estados de Ethereum<\/h3>\n<div class=\"slate-resizable-image-embed slate-image-embed__resize-full-width\"><img decoding=\"async\" src=\"https:\/\/media.licdn.com\/dms\/image\/C4E12AQFO0rGYBY_AjA\/article-inline_image-shrink_400_744\/0\/1520548852317?e=1722470400&amp;v=beta&amp;t=kz7mERagmQucVwJ_7OUUFhcEsX1ZJDCnQA8Ajo2iPnM\" data-media-urn=\"\" data-li-src=\"https:\/\/media.licdn.com\/dms\/image\/C4E12AQFO0rGYBY_AjA\/article-inline_image-shrink_400_744\/0\/1520548852317?e=1722470400&amp;v=beta&amp;t=kz7mERagmQucVwJ_7OUUFhcEsX1ZJDCnQA8Ajo2iPnM\" \/><\/div>\n<p>En Ethereum la funci\u00f3n de transici\u00f3n de estado,\u00a0APPLY(S,TX) -&gt; S\u2019\u00a0puede ser definida como sigue:<\/p>\n<ol>\n<li>Comprobar si la transacci\u00f3n est\u00e1 bien formada (es decir, tiene el n\u00famero correcto de valores), la firma es v\u00e1lida, y el valor del nonce coincide con el valor del nonce en la cuenta del remitente. Si no se produce, devuelve un error.<\/li>\n<li>Calcula la tarifa de la transacci\u00f3n como STARTGAS * GASPRICE, y determina la direcci\u00f3n de env\u00edo de la firma. Resta esta tarifa del balance de la cuenta del remitente e incrementa el valor del nonce. Si no hay balance suficiente para gastar, devuelve un error.<\/li>\n<li>Inicializa GAS = STARTGAS, y saca una cierta cantidad de gas por byte a pagar por los bytes de la transacci\u00f3n.<\/li>\n<li>Transfiere el valor de la transacci\u00f3n desde la cuenta del remitente a la cuenta del destinatario. Si la cuenta de destino no existe todav\u00eda, la crea. Si la cuenta de destino es un contrato, ejecuta el c\u00f3digo del contrato hasta su finalizaci\u00f3n o hasta que la ejecuci\u00f3n agote la cantidad de gas.<\/li>\n<li>Si el valor de la transferencia falla porque el remitente no tiene suficiente dinero, o porque la ejecuci\u00f3n del c\u00f3digo agote el gas, se revierten todos los estados excepto el del pago de la tasa, que se a\u00f1ade a la cuenta del minero.<\/li>\n<li>En otro caso, devolver la cuota del gas restante al remitente, y enviar la tarifa por el pago del gas consumido al minero.<\/li>\n<\/ol>\n<p>Por ejemplo, supongamos que el c\u00f3digo del contrato es el siguiente:<\/p>\n<blockquote>\n<p class=\"left\">if !self.storage[calldataload(0)]:<\/p>\n<p class=\"left\">\u00a0 \u00a0self.storage[calldataload(0)] = calldataload(32)<\/p>\n<\/blockquote>\n<p>En realidad, el c\u00f3digo del contrato est\u00e1 escrito en c\u00f3digo de bajo nivel de la EVM (Ethereum Virtual Machine); el siguiente ejemplo escrito en Serpent (uno de nuestros lenguajes de alto nivel) para mayor claridad, puede ser compilado a c\u00f3digo EVM. Supongamos que el almacenamiento del contrato comienza vac\u00edo, y una transacci\u00f3n se env\u00eda con un valor de 10 unidades de ether, 2.000 unidades de gas, 0.001 unidades de precio del gas ether, y 64 bytes de datos, donde los bytes del \u00a00 al 31 representan el n\u00famero 2 y los bytes del 32 al 63 representan la cadena CHARLIE. En este caso, el proceso que sigue la funci\u00f3n de transici\u00f3n de estado es el siguiente:<\/p>\n<ol>\n<li>Comprobar que la transacci\u00f3n es v\u00e1lida y est\u00e1 bien formada.<\/li>\n<li>Comprobar que el remitente de la transacci\u00f3n tiene al menos 2000 * 0.001 = 2 unidades de ether. Si esto es as\u00ed, restar estas 2 unidades de ether de la cuenta del remitente.<\/li>\n<li>Inicializa gas = 2000; asumiendo que la longitud de la transacci\u00f3n es de 170 bytes y la tarifa por byte es de 5 unidades, restar 850 (170 x 5) lo que deja 1150 unidades de gas.<\/li>\n<li>Restar 10 unidades m\u00e1s de ether de la cuenta del remitente, y a\u00f1adirlos a la cuenta del contrato.<\/li>\n<li>Ejecutar el c\u00f3digo. En este caso, es simple: comprueba si el almacenamiento del contrato con \u00edndice 2 est\u00e1 siendo usado, observa que no lo est\u00e1 y lo establece con el valor de CHARLIE. Suponiendo que esto consume 187 unidades de gas, la cantidad de gas restante que queda es de 1150 \u2013 187 = 963<\/li>\n<li>A\u00f1adir 963 * 0.001 = 0.963 unidades de ether de vuelta a la cuenta del remitente, y devolver el estado resultante.<\/li>\n<\/ol>\n<p>Si no hab\u00eda ning\u00fan contrato en el extremo receptor de la transacci\u00f3n, la tasa total de la transacci\u00f3n simplemente ser\u00eda igual al GASPRICE proporcionado multiplicado por la longitud de la transacci\u00f3n en bytes, los datos que se env\u00edan junto con la transacci\u00f3n ser\u00edan irrelevantes.<\/p>\n<p>Tenga en cuenta que los mensajes funcionan de forma equivalente a las transacciones en t\u00e9rminos de reversi\u00f3n: si la ejecuci\u00f3n de un mensaje se queda sin gas, entonces la ejecuci\u00f3n de ese mensaje, junto con todas las dem\u00e1s ejecuciones desencadenados por \u00e9ste, se revierten, pero no asi las ejecuciones de los padres que no tienen porque hacerlo. Esto significa que es \u201cseguro\u201d para un contrato llamar a otro contrato, por ejemplo si A llama a B con G unidades de gas, entonces la ejecuci\u00f3n de A, tiene garantizado que c\u00f3mo m\u00e1ximo, podr\u00eda perder esta cantidad de G unidades de gas, pero no m\u00e1s. Por \u00faltimo, hay un c\u00f3digo de operaci\u00f3n, CREATE, que crea un contrato; su mec\u00e1nica de ejecuci\u00f3n es generalmente similar a CALL, con la excepci\u00f3n de que al finalizar la ejecuci\u00f3n se devuelve el c\u00f3digo de un contrato de nueva creaci\u00f3n.<\/p>\n<h3>Ejecuci\u00f3n de C\u00f3digo<\/h3>\n<p>El c\u00f3digo en los contratos de Ethereum, est\u00e1 escrito en un lenguaje de c\u00f3digos de bytes (o bytecode) de bajo nivel y basado en el uso de una pila (stack-based bytecode language), y que es conocido como \u201cC\u00f3digo de M\u00e1quina Virtual de Ethereum\u201d o \u201cc\u00f3digo EVM<a href=\"http:\/\/www.santiagomarquezsolis.com\/ethereum-whitepaper-traducido-al-castellano\/#_ftn2\" target=\"_blank\" rel=\"nofollow noopener\">[2]<\/a>\u201c. El c\u00f3digo consta de una serie de bytes, donde cada byte representa una operaci\u00f3n. En general, la ejecuci\u00f3n de c\u00f3digo es un bucle infinito que consiste en realizar repetidas veces la operaci\u00f3n que se encuentra en el contador de programa actual (que comienza en cero) y que se va incrementando en uno, hasta que se alcanza o bien el final del c\u00f3digo, o un error, o una instrucci\u00f3n STOP o se detecta la instrucci\u00f3n RETURN. Las operaciones tienen acceso a tres tipos de espacios donde almacenar datos:<\/p>\n<ul>\n<li>La\u00a0<strong>pila (stack)<\/strong>, es un contenedor donde el \u00faltimo elemento en entrar es el primero en salir y donde los valores pueden meterse y sacarse.<\/li>\n<li><strong>Memoria (Memory)<\/strong>, una matriz de bytes que es infinitamente ampliable,<\/li>\n<li>Almacenamiento\u00a0<strong>(storage)\u00a0<\/strong>a largo plazo del contrato del tipo clave\/valor (key\/value store). A diferencia de la pila y la memoria, que se limpian despu\u00e9s de finalizar la ejecuci\u00f3n, el almacenamiento persiste en largo plazo.<\/li>\n<\/ul>\n<p>El c\u00f3digo tambi\u00e9n puede acceder al valor, el remitente y a los datos del mensaje entrante, as\u00ed como a los datos de la cabecera del bloque. El c\u00f3digo puede tambi\u00e9n devolver una matriz de bytes de datos como salida.<\/p>\n<p>El modelo formal de ejecuci\u00f3n de c\u00f3digo EVM es sorprendentemente simple. Mientras la m\u00e1quina virtual de Ethereum est\u00e1 en ejecuci\u00f3n, su estado completo puede ser definido por la tupla (block_state, transaction, message, code, memory, stack, pc, gas), donde\u00a0block_state\u00a0es el estado global que contiene todas las cuentas e incluye los saldos y almacenamientos. Al inicio de cada \u00e9tapa de ejecuci\u00f3n, la instrucci\u00f3n en curso se encuentra\u00a0 en el pc-esimo byte de code\u00a0(o 0 ifpc &gt;= len(code)), cada instrucci\u00f3n tiene su propia definici\u00f3n en t\u00e9rminos de c\u00f3mo afecta a la tupla. Por ejemplo,\u00a0la instrucci\u00f3n ADD\u00a0saca dos elementos de la pila e introduce en ella su suma, reduce el gas en 1 e incrementa el pc\u00a0tambi\u00e9n en 1. La instrucci\u00f3n\u00a0SSTORE\u00a0empuja hacia abajo los dos primeros elementos de la pila e inserta el segundo elemento en el \u00edndice especificado por el primer elemento. Aunque hay muchas maneras de optimizar la ejecuci\u00f3n sobre la m\u00e1quina virtual de Ethereum a trav\u00e9s de la compilaci\u00f3n just-in-time, la implementaci\u00f3n b\u00e1sica de Ethereum puede hacerse con unos cientos de l\u00edneas de c\u00f3digo.<\/p>\n<h3>Cadena de Bloques y Miner\u00eda<\/h3>\n<p>&nbsp;<\/p>\n<div class=\"slate-resizable-image-embed slate-image-embed__resize-full-width\"><img decoding=\"async\" src=\"https:\/\/media.licdn.com\/dms\/image\/C4E12AQH2CLqF7wrwsQ\/article-inline_image-shrink_400_744\/0\/1520548852503?e=1722470400&amp;v=beta&amp;t=H7kUUuVf1R4yagHFg5yRct6yc8kW_MAKY20k9UUJEGs\" data-media-urn=\"\" data-li-src=\"https:\/\/media.licdn.com\/dms\/image\/C4E12AQH2CLqF7wrwsQ\/article-inline_image-shrink_400_744\/0\/1520548852503?e=1722470400&amp;v=beta&amp;t=H7kUUuVf1R4yagHFg5yRct6yc8kW_MAKY20k9UUJEGs\" \/><\/div>\n<p>La cadena de bloques de Ethereum es similar a la de Bitcoin en muchas cosas, aunque tambi\u00e9n tiene algunas diferencias. La diferencia principal entre Ethereum y Bitcoin respect a la arquitectura de la cadena de bloques es que, a diferencia de Bitcoin, los bloques de Ethereum contienen una copia tanto de la lista de transacciones como del estado m\u00e1s reciente. A parte de eso, otros dos valores, el n\u00famero de bloques y la dificultad, tambi\u00e9n est\u00e1n almacenados en el bloque. El algoritmo b\u00e1sico de validaci\u00f3n de bloque en Ethereum es el siguiente:<\/p>\n<ol>\n<li>Comprueba si el bloque previo referenciado existe y es v\u00e1lido.<\/li>\n<li>Comprueba que el sello de tiempo del bloque es mayor que el bloque previo referenciado y menor de 15 minutos en el futuro.<\/li>\n<li>Comprueba el n\u00famero de bloque, la dificultad, la transacci\u00f3n raiz, la ra\u00edz t\u00eda y el l\u00edmite de gas (varios conceptos de bajo nivel espec\u00edficos de Ethereum) son v\u00e1lidos.<\/li>\n<li>Comprueba que la prueba de trabajo del bloque es v\u00e1lida.<\/li>\n<li>Establece S[0]como el estado al final del bloque previo.<\/li>\n<li>Establece TXcomo la lista de transacciones del bloque, con n\u00a0transacciones. Para todo\u00a0i\u00a0en\u00a0..n-1, establece S[i+1] = APPLY(S[i],TX[i]). Si alguna aplicaci\u00f3n devuelve un error, o si la cantidad de gas consumido por el bloque hasta este momento exceed el GASLIMIT, devuelve un error.<\/li>\n<li>EstableceS_FINAL\u00a0como\u00a0S[n], pero a\u00f1adiendo al bloque la recompense pagada por el minero.<\/li>\n<li>Comprueba si la raiz del \u00e1rbol de Merkle del estado S_FINAL es igual a la raiz del estado final proporcionada por la cabecera del bloque. Si esto es as\u00ed, el bloque es v\u00e1lido, en otro caso, no lo es..<\/li>\n<\/ol>\n<p>El enfoque puede parecer muy ineficiente a primera vista, porque necesita almacenar el estado completo de cada bloque, pero en realidad la eficiencia deber\u00eda ser comparable a la de Bitcoin. La raz\u00f3n es que el estado se almacena en una estructura de \u00e1rbol, y despu\u00e9s de cada bloque s\u00f3lo una peque\u00f1a parte del mismo necesita ser cambiada. As\u00ed, en general, entre dos bloques adyacentes la gran mayor\u00eda del \u00e1rbol debe ser el mismo, y por tanto, los datos pueden ser almacenados una vez y referenciarse dos veces usando punteros (es decir, hashes de sub\u00e1rboles). Un tipo especial de \u00e1rbol, conocido como un \u201c\u00e1rbol Patricia\u201d, se utiliza para lograr esto, incluyendo una modificaci\u00f3n en el concepto de \u00e1rbol de Merkle que permite a los nodos ser insertados y borrados, y no s\u00f3lo cambiados, de manera eficiente. Adem\u00e1s, dado que toda la informaci\u00f3n de estado es parte del \u00faltimo bloque, no hay necesidad de almacenar toda la historia de la cadena de bloques \u2013 una estrategia que, si se pudiera aplicar a Bitcoin, se puede calcular que proporcionar\u00eda un ahorro en espacio de 5 a 20 veces.<\/p>\n<p>Una de las preguntas m\u00e1s frecuentes es \u201cdonde\u201d se ejecuta el c\u00f3digo del contrato, en t\u00e9rminos de hardware f\u00edsico. Esto tiene una respuesta simple, el proceso de ejecuci\u00f3n del c\u00f3digo del contrato es parte de la definici\u00f3n de la funci\u00f3n de transici\u00f3n, que a su vez forma parte del algoritmo de validaci\u00f3n del bloque, por tanto si una transacci\u00f3n se a\u00f1ade dentro del bloque B, el c\u00f3digo generado por esa transacci\u00f3n ser\u00e1 ejecutado por todos los nodos, ahora y en el futuro, que descarguen y validen el bloque B.<\/p>\n<h2>Aplicaciones<\/h2>\n<p>En general, hay tres tipos de aplicaciones que pueden implementarse en la capa superior de Ethereum. La primera categor\u00eda son las aplicaciones financieras, que proporcionan a los usuarios formas m\u00e1s poderosas de administrar y gestionar los contratos usando su dinero. Esto incluye submonedas, derivados financieros, contratos de cobertura, carteras de ahorro, testamentos, y en \u00faltima instancia, incluso algunos tipos de contratos de trabajo. La segunda categor\u00eda son aplicaciones semifinancieras donde el dinero est\u00e1 involucrado pero hay un lado no monetario de peso; un ejemplo perfecto de esto son las recompensas por la soluci\u00f3n de problemas computacionales. Por ultimo, hay aplicaciones como\u00a0 el voto online y el gobierno descentralizado que no son aplicaciones financieras en absoluto.<\/p>\n<h3>Sistema de Testigos (Tokens<a href=\"http:\/\/www.santiagomarquezsolis.com\/ethereum-whitepaper-traducido-al-castellano\/#_ftn3\" target=\"_blank\" rel=\"nofollow noopener\"><strong>[3]<\/strong><\/a>)<\/h3>\n<p>Un sistema de testigos (tokens) construido sobre la cadena de bloques tiene un rango de aplicaciones muy amplio, que van desde las submonedas que pueden representar activos como el d\u00f3lar o el oro, hasta acciones de empresas, testigos individuales que representan propiedad inteligente, cupones seguros infalsificables e incluso sistemas de testigos simb\u00f3licos, sin v\u00ednculos con un valor convencional y que pueden usarse como sistemas de incentivaci\u00f3n. Los sistemas de testigos son sorprendentemente f\u00e1ciles de implementar en Ethereum. El punto clave a entender, es que toda monada, o sistema de testigos, fundamentalmente es una base de datos con una operaci\u00f3n: substraer X unidades de A y dar X unidades a B, con la condici\u00f3n que (1) A tiene al menos X unidades antes de la transacci\u00f3n y (2) la transacci\u00f3n est\u00e1 aprobada por A. Todo lo que se necesita para poner en la pr\u00e1ctica un sistema de testigos es implementar \u00e9sta l\u00f3gica en un contrato.<\/p>\n<p>El c\u00f3digo b\u00e1sico para implementar un sistema de testigos (tokens) en Serpent se parece a lo siguiente:<\/p>\n<blockquote>\n<p class=\"left\">def send(to, value):<\/p>\n<p class=\"left\">if self.storage[msg.sender] &gt;= value:<\/p>\n<p class=\"left\">\u00a0 \u00a0 self.storage[msg.sender] = self.storage[msg.sender] \u2013 value<\/p>\n<p class=\"left\">\u00a0 \u00a0 self.storage[to] = self.storage[to] + value<\/p>\n<\/blockquote>\n<p>Lo anterior, es esencialmente la implementaci\u00f3n literal de la funci\u00f3n de transici\u00f3n de estado de un\u00a0 \u201csistema bancario\u201d descrita m\u00e1s arriba en este documento. Unas pocas de l\u00edneas de c\u00f3digo adicionales se a\u00f1adir\u00edan para la etapa inicial de distribuci\u00f3n de las unidades monetarias o de algunos casos extremos, lo ideal ser\u00eda a\u00f1adir una funci\u00f3n que dejara a otros contratos consultar el balance de una direcci\u00f3n. Pero eso es todo lo que hay que hacer. Teoricamente, el sistema de testigos de Ethereum actuando como submonedas puede potencialmente incluir otra caracter\u00edstica importante de las que carecen las metamonedas basadas en la cadena de Bitcoin: la capacidad de pago de comisiones por transacci\u00f3n directamente en esa moneda. La forma en la que esto ser\u00eda implementado es que el contrato mantendr\u00eda el balance de ether que reembolsar\u00eda para pagar las comisiones al remitente, y rellenando su balance recogiendo las unidades de moneda interna de las comisiones que revender\u00eda en una subasta de ejecuci\u00f3n cont\u00ednua. Los usuarios tendr\u00edan la necesidad de \u201cactivar\u201d sus cuentas con ether, pero una vez que el ether est\u00e1 alli volver\u00eda a ser reutilizable porque el contrato se lo devolver\u00e1 cada vez.<\/p>\n<h3>Derivados Financieros y Monedas de Valor Estable<\/h3>\n<p>Los derivados financieros son la aplicaci\u00f3n m\u00e1s com\u00fan de un \u201ccontrato inteligente\u201d y uno de los m\u00e1s simples de implementar en c\u00f3digo. El principal desaf\u00edo que entra\u00f1an su implementaci\u00f3n es que la mayor\u00eda de ellos requieren una referencia a un precio externo, por ejemplo, una aplicaci\u00f3n muy deseable ser\u00eda un contrato inteligente (contrato de cobertura en este caso) que cubriera contra la volatilidad del ether (u otra criptomoneda) con respecto al d\u00f3lar estadounidense, pero para poder hacer esto se requiere que el contrato sepa cu\u00e1l es el valor entre ETH\/USD. La forma m\u00e1s simple de hacer esto es a trav\u00e9s de un contrato de \u201cfuente de datos\u201d mantenido por una parte espec\u00edfica designada (por ejemplo NASDAQ) de manera que esa parte tiene la habilidad de actualizar el contrato cuando es necesario y proporcionando un interface que permite a otros contratos enviar un mensaje a \u00e9ste y obtener una respuesta de vuelta con el precio.<\/p>\n<p>Teniendo en cuenta este ingrediente cr\u00edtico, el contrato de cobertura se ver\u00eda de la siguiente manera:<\/p>\n<ol>\n<li>Esperar una entrada de la parte A de 1000 ether.<\/li>\n<li>Esperar una entrada de la parte B de 1000 ether.<\/li>\n<li>Registrar el valor en USD de 1000 ether, calculado mediante la consulta de un contrato de fuente de datos, que devuelve que el valor es de $x.<\/li>\n<li>Despu\u00e9s de 30 d\u00edas, permitir que A o B \u201creactiven\u201d el contrato a fin de enviar $x unidades de ether (calculado consultando otra vez el contrato de la fuente de datos para obtener el nuevo precio) a A y el resto a B.<\/li>\n<\/ol>\n<p>Tal contrato tendr\u00eda un potencial significativo en el criptocomercio. Uno de los principales problemas citados al hablar de criptomonedas es de hecho su volatilidad; y es que aunque muchos usuarios y comerciantes pueden ver la seguridad y conveniencia de tratar con activos criptogr\u00e1ficos, muchos no desean enfrentar la perspectiva de perder el 23% del valor de sus fondos en un solo d\u00eda. Hasta ahora, la soluci\u00f3n m\u00e1s com\u00fanmente propuesta ha sido la de emisi\u00f3n de activos con respaldo, es decir, la idea es que un emisor crea una sub-moneda para la que tiene derecho de emisi\u00f3n y revocaci\u00f3n de unidades, adem\u00e1s de asignarlas a cualquier persona que les proporcione (de manera offline) una unidad de un activo subyacente especificado (por ejemplo, el oro, o el d\u00f3lar americano). El emisor se compromete a proporcionar a su vez, una unidad del activo subyacente a cualquier persona que env\u00eda una unidad del cripto-activo. Este mecanismo permite que cualquier activo no criptogr\u00e1fico sea \u201celevado\u201d a la categor\u00eda de cripto-activo, siempre que se pueda confiar en el emisor.<\/p>\n<p>En la pr\u00e1ctica sin embargo, los emisores no son siempre confiables, y en algunos casos, la infraestructura bancaria es demasiado d\u00e9bil o demasiado hostil, para que estos servicios puedan existir. Los derivados financieros son una alternativa. Aqu\u00ed, en lugar de un \u00fanico emisor que proporcione los fondos para respaldar un activo, hay un mercado descentralizado de especuladores que juegan este papel, apostando a que el precio de un activo criptogr\u00e1fico de referencia (por ejemplo, ETH) va a subir. A diferencia de los emisores, los especuladores no tienen la opci\u00f3n de dejar de pagar su parte del trato debido a que el contrato de cobertura mantiene sus fondos en fideicomiso. Tenga en cuenta que este enfoque no es totalmente descentralizado, ya que una fuente de confianza sigue siendo necesaria para proporcionar el precio de referencia, aunque podr\u00eda decirse que incluso todav\u00eda se trata de una enorme mejora en t\u00e9rminos de reducci\u00f3n de las necesidades de infraestructura (a diferencia de un emisor, la emisi\u00f3n de un indicador de precios no requiere de licencias y es probable que se pueden clasificar como libertad de expresi\u00f3n) y reduce la posibilidad de fraude.<\/p>\n<h3>Sistemas de Identificaci\u00f3n y Reputaci\u00f3n<\/h3>\n<p>La criptomoneda alternativa m\u00e1s antigua de todas, Namecoin, intent\u00f3 utilizar una cadena de bloques como la de\u00a0 Bitcoin para proporcionar un sistema de registro de nombres, donde los usuarios pueden registrar sus nombres en una base de datos p\u00fablica junto a otros datos. El principal caso de uso citado ser\u00eda el sistema de DNS, donde se mapear\u00edan los nombres de dominio como \u201cbitcoin.org\u201d (o en el caso de Namecoin, \u201cbitcoin.bit\u201d) a una direcci\u00f3n IP. Otros casos de uso incluyen la autenticaci\u00f3n de correo electr\u00f3nico y sistemas de reputaci\u00f3n potencialmente m\u00e1s avanzados. Aqu\u00ed vemos el contrato b\u00e1sico para proporcionar un sistema de registro de nombres del tipo Namecoin sobre Ethereum:<\/p>\n<blockquote>\n<p class=\"left\">def register(name, value):<\/p>\n<p class=\"left\">if !self.storage[name]:<\/p>\n<p class=\"left\">\u00a0 \u00a0self.storage[name] = value<\/p>\n<\/blockquote>\n<p>El contrato es muy simple; es una base de datos dentro de la red Ethereum donde se puede agregar, pero no modificar o eliminar. Cualquier persona puede registrar un nombre con alg\u00fan valor y ese registro queda para siempre. Un contrato m\u00e1s sofisticado de registro de nombres tambi\u00e9n podr\u00eda tener \u201ccl\u00e1usulas de funci\u00f3n\u201d que permitir\u00edan que otros contratos pudieran realizar consultas, as\u00ed como un mecanismo para el \u201cpropietario\u201d (es decir, el primero que registr\u00f3) de un nombre que le habilitar\u00eda para cambiar los datos o transferir la propiedad. Incluso en la parte superior se podr\u00eda agregar funcionalides asociadas a la reputaci\u00f3n o a confianza en la web.<\/p>\n<h3>Almacenamiento Descentralizado de Ficheros<\/h3>\n<p>En los \u00faltimos a\u00f1os, han surgido una serie de nuevas empresas de almacenamiento de archivos en l\u00ednea muy populares (siendo Dropbox\u00a0 la m\u00e1s prominente de todas) y que buscan permitir a los usuarios subir una copia de seguridad de su disco duro a la que puede acceder a cambio de una cuota mensual. Sin embargo, en este momento el mercado de almacenamiento de archivos es a veces relativamente ineficiente y una mirada superficial a diferentes soluciones existentes muestra que, sobre todo en el \u201cvalle inquietante\u201d que se situar\u00eda en el nivel de los 20 a los 200 GB y en donde no entran en juego ni las opciones gratu\u00edtas ni los descuentos de nivel empresarial, los precios mensuales son m\u00e1s de lo que estar\u00edamos pagando por el disco duro 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\u00f1as cantidades de dinero por el alquiler de sus propios discos duros y el espacio no utilizado, lo que se puede utilizar para impulsar costos de almacenamiento de archivos m\u00e1s bajos.<\/p>\n<p>La pieza clave de un dispositivo de este tipo ser\u00eda lo que hemos denominado el \u201ccontrato Dropbox descentralizada\u201d. Este contrato funciona como sigue. En primer lugar, divide los datos deseados en bloques, que se cifran para garantizar su privacidad, y a partir de ah\u00ed se construye un \u00e1rbol de Merkle sobre ellos. Luego se crea un contrato con la regla siguiente,\u00a0 cada N bloques, el contrato escoge un \u00edndice al azar en el \u00e1rbol de Merkle (utilizando el hash del bloque anterior, accesible desde el c\u00f3digo del contrato, como fuente de aleatoriedad), y dando X cantidad de ether a la primera entidad que suministre una transacci\u00f3n con verificaci\u00f3n de pago simplificado como prueba de la propiedad del bloque en ese \u00edndice en particular del \u00e1rbol. Cuando un usuario desea volver a descargar su archivo, puede utilizar un protocolo de canal de micropagos para recuperarlo (por ejemplo, pagar 1 szabo por 32 kilobytes.); el m\u00e9todo m\u00e1s eficiente de pago para el pagador ser\u00eda no publicar la transacci\u00f3n hasta el final, y sustituy\u00e9ndola con una un poco m\u00e1s lucrativa, con el mismo nonce, despu\u00e9s de cada 32 kilobytes.<\/p>\n<p>Una caracter\u00edstica importante del protocolo es que, a pesar de que puede parecer que uno est\u00e1 confiando en muchos nodos aleatorios que podr\u00edan decidir olvidar el archivo, se puede reducir ese riesgo hasta casi cero al dividir el archivo en muchos pedazos a trav\u00e9s de la compartici\u00f3n de secretos y usando los contratos para ver que fragmento se encuentra todav\u00eda en posesi\u00f3n de alguno de los nodos. Si un contrato todav\u00eda est\u00e1 pagando dinero, esto proporciona una prueba criptogr\u00e1fica que alguien por ah\u00ed fuera sigue almacenando el archivo.<\/p>\n<h3>Organizaciones Aut\u00f3nomas Descentralizadas<\/h3>\n<p>El concepto general de una \u201corganizaci\u00f3n aut\u00f3noma descentralizada\u201d es el de una entidad virtual que tiene un cierto conjunto de socios o accionistas que, tal vez con una mayor\u00eda del 67%, tienen el derecho de gastar los fondos de la entidad y modificar su c\u00f3digo. Los miembros decidir\u00e1n colectivamente sobre c\u00f3mo la organizaci\u00f3n debe asignar sus fondos. Los m\u00e9todos para la asignaci\u00f3n de los fondos de una DAO<a href=\"http:\/\/www.santiagomarquezsolis.com\/ethereum-whitepaper-traducido-al-castellano\/#_ftn4\" target=\"_blank\" rel=\"nofollow noopener\">[4]<\/a>\u00a0podr\u00edan variar y ser del tipo de: recompensas, sueldos o incluso mecanismos a\u00fan m\u00e1s ex\u00f3ticos, tales como una moneda interna para recompensar el trabajo. Esto esencialmente replica las trampas legales de una empresa tradicional o sin \u00e1nimo de lucro pero utilizando la tecnolog\u00eda criptogr\u00e1fica de la cadena de bloques para su ejecuci\u00f3n. Hasta ahora la mayor parte de la charla alrededor de las DAOs ha sido sobre un modelo \u201ccapitalista\u201d de \u201ccorporaci\u00f3n aut\u00f3noma descentralizada\u201d (DAC) con acciones negociables y accionistas que reciben dividendos; o tambi\u00e9n sobre otra alternativa descrita como \u201ccomunidad aut\u00f3noma descentralizada\u201d, donde todos los miembros tienen una participaci\u00f3n igual en la toma de decisiones y que requiere que al menos el 67% de los miembros existentes est\u00e9n de acuerdo para a\u00f1adir o eliminar miembros. El requisito para que una persona pueda estar afiliada necesitar\u00eda entonces ser impuesta colectivamente por el grupo.<\/p>\n<p>Un esquema general de c\u00f3mo codificar una DAO es el siguiente. El dise\u00f1o m\u00e1s simple ser\u00eda un fragmento de c\u00f3digo que se cambiar\u00eda a si mismo si dos tercios de los miembros est\u00e1n de acuerdo con el cambio. Aunque el c\u00f3digo es te\u00f3ricamente inmutable, se puede conseguir esto f\u00e1cilmente y tener la mutabilidad de facto, teniendo trozos de c\u00f3digo en contratos separados, y guardando en el almacenamiento modificable la direcci\u00f3n del contrato que tiene que invocarse. En una sencilla implementaci\u00f3n de dicho contrato DAO, habr\u00eda tres tipos de transacciones, que se distinguen por los datos que proporcionan:<\/p>\n<ul>\n<li>[0,i,K,V]\u00a0para registrar una propuesta con \u00edndice\u00a0I \u00a0para cambiar la direcci\u00f3n del almacenamiento de \u00edndice K al valor V<\/li>\n<li>[0,i]\u00a0para registrar un voto a favor de la propuesta\u00a0i<\/li>\n<li>[2,i]\u00a0para finalizar la propuesta\u00a0i\u00a0si se han realizado suficientes votos<\/li>\n<\/ul>\n<p>El contrato tendr\u00eda entonces cl\u00e1usulas para cada una de ellas. Se mantendr\u00eda un registro de todos los cambios en el almacenamiento abiertos, junto con una lista de quien vot\u00f3 por ellos. Tambi\u00e9n se tendr\u00eda una lista de todos los miembros. Cuando cualquier cambio en el almacenamiento consigue que dos tercios de los miembros con derecho a voto voten por \u00e9l, entonces una transacci\u00f3n de finalizaci\u00f3n podr\u00eda ejecutar el cambio. Un esqueleto m\u00e1s sofisticado, tambi\u00e9n habr\u00eda incorporado en esta capacidad de voto, otras caracter\u00edsticas como el env\u00edo de una transacci\u00f3n, la adici\u00f3n o eliminaci\u00f3n de miembros, e incluso podr\u00eda proporcionar un estilo de voto por delegaci\u00f3n del estilo de la Democracia L\u00edquida<a href=\"http:\/\/www.santiagomarquezsolis.com\/ethereum-whitepaper-traducido-al-castellano\/#_ftn5\" target=\"_blank\" rel=\"nofollow noopener\">[5]<\/a>\u00a0(es decir, cualquiera puede asignar a otro para que vote por \u00e9l, teniendo en cuenta que la asignaci\u00f3n es transitiva y que si A asigna a B y B asigna a C, entonces C determinar\u00eda la votaci\u00f3n de A). Este dise\u00f1o permitir\u00eda al DAO crecer org\u00e1nicamente como una comunidad descentralizada, dejando a las personas delegar eventualmente en miembros especialistas, aunque a diferencia de los especialistas \u201cdel sistema actual\u201d, ahora estos pueden aparecer o desaparecer en el tiempo \u00a0a medida que los miembros individuales de la comunidad cambian sus posiciones<a href=\"http:\/\/www.santiagomarquezsolis.com\/ethereum-whitepaper-traducido-al-castellano\/#_ftn6\" target=\"_blank\" rel=\"nofollow noopener\">[6]<\/a>.<\/p>\n<p>Un modelo alternativo podr\u00eda servir para una sociedad descentralizada donde cualquier cuenta puede tener cero o m\u00e1s acciones, y donde se requieren dos tercios de las acciones para tomar una decisi\u00f3n. Un esqueleto completo implicar\u00eda funcionalidad para la gesti\u00f3n de activos, la capacidad de hacer una oferta para comprar o vender acciones, y la capacidad de aceptar las ofertas (preferiblemente con un mecanismo de emparejamiento de las \u00f3rdenes dentro del contrato). La delegaci\u00f3n tambi\u00e9n existir\u00eda al estilo de una Democracia L\u00edquida, generalizando el concepto de un \u201cconsejo de administraci\u00f3n\u201d.<\/p>\n<h3>Otras Aplicaciones<\/h3>\n<ol>\n<li><strong>Carteras de Ahorro<\/strong>. Supongamos que Alicia quiere guardar sus fondos a salvo, pero est\u00e1 preocupada porque ella pueda perder o alguien pueda hackear su clave privada. Ella pone ether en un contrato con Bob, que es un banco, como sigue:<\/li>\n<\/ol>\n<ul>\n<li>Alicia\u00a0solamente puede retirar un m\u00e1ximo del 1% de sus fondos cada d\u00eda.<\/li>\n<li>Bob solo puede retirar un m\u00e1ximo de 1% de los fondos por d\u00eda, pero Alicia tiene la capacidad de hacer una transacci\u00f3n con su clave que anule esta capacidad.<\/li>\n<li>Alicia y Bob juntos pueden retirar cualquier cantidad.<\/li>\n<\/ul>\n<p>Normalmente, un 1% al d\u00eda es suficiente para Alicia, y si Alicia quiere retirar m\u00e1s, puede contactar con Bob para que la ayude. Si la clave de Alicia es hackeada, \u00a0le pide a Bob que mueva los fondos a otro contrato. Si ella pierde su clave, Bob pondr\u00e1 eventualmente poner los fondos fuera. Si Bob se vuelve malicioso, Alicia puede anular la capacidad de Bob para retirar sus fondos.<\/p>\n<ol>\n<li><strong>Seguros para cosechas<\/strong>. Uno puede f\u00e1cilmente hacer un contrato para un derivado financiero usando una fuente de datos del tiempo clim\u00e1tico en vez del \u00edndice de un precio. Si un granjero en Iowa compra un derivado que le paga inversamente bas\u00e1ndose en las precipitaciones de lluvia en Iowa, entonces si hay una sequ\u00eda, el agricultor autom\u00e1ticamente recibir\u00e1 dinero y del mismo modo si hay suficiente lluvia, estar\u00e1 feliz porque sus cultivos estar\u00e1n bien. Esto se puede ampliar de manera general a cualquier tipo de seguros por desastres naturales.<\/li>\n<li><strong>Fuentes de datos descentralizadas<\/strong>. Para los contratos financieros por diferencia, es actualmente posible descentralizar la fuente de datos mediante un protocolo llamado \u201c<a href=\"http:\/\/blog.ethereum.org\/2014\/03\/28\/schellingcoin-a-minimal-trust-universal-data-feed\/\" target=\"_blank\" rel=\"nofollow noopener\">SchellingCoin<\/a>\u201c. SchellingCoin b\u00e1sicamente funciona del siguiente modo: N partes ponen juntas en el sistema el valor de un determinado dato (por ejemplo el precio ETH\/USD), los valores est\u00e1n ordenados, y todo el mundo entre el percentil 25 y el 75 obtienen una recompensa. Todos tienen el incentivo de proporcionar la misma respuesta que el resto proporcione, de manera que solamente el valor proporcionado y que tiene un mayor n\u00famero de apariciones, es el que se considera como verdadero por defecto. Esto crea un protocolo descentralizado que te\u00f3ricamente proporcionar\u00eda cualquier n\u00famero de valores, incluyendo el precio anterior, la temperatura en Berlin o incluso el resultado particular de una operaci\u00f3n computacional muy costosa.<\/li>\n<li><strong>Custodia multifirma inteligente<\/strong>. Bitcoin permite contractos con transacciones multifirma donde, por ejemplo, tres de cinco claves dadas pueden gastar los fondos. Ethereum permite m\u00e1s granularidad; por ejemplo, cuatro de cinco pueden gastar todo, tres de cinco pueden gastar hasta un 10% diario, y dos de cinco pueden gastar hasta un 0.5% diario. Adicionalmente, la multifirma en Ethereum es as\u00edncrona, dos partes pueden registrar sus firmas en la cadena de bloques en diferentes momentos y la \u00faltima de ellas autom\u00e1ticamente enviar\u00e1 la transacci\u00f3n.<\/li>\n<li><strong>Computaci\u00f3n en la nube<\/strong>. La tecnolog\u00eda de la EVM puede ser usada tambi\u00e9n para crear entornos de computaci\u00f3n verificables, lo que permite que unos usuarios pidan a otros efectuar c\u00e1lculos computacionales y opcionalmente, en ciertos puntos de control aleatorios y seleccionados, comprobar que estos fueron realizados correctamente. Esto permitir\u00eda la creaci\u00f3n de un mercado computacional en la nube, donde cualquier usuario puede participar con su ordenador de sobremesa, port\u00e1til o servidor especializado, y que junto con los puntos de control y los dep\u00f3sitos de seguridad se puede utilizar para garantizar que el sistema es confiable (es decir, los nodos no pueden enga\u00f1ar de modo rentable). Aunque tal sistema puede no ser adecuado para todo tipo de tareas; tareas que requieren un alto nivel de comunicaci\u00f3n entre procesos, por ejemplo, y que no pueden ser realizadas f\u00e1cilmente en una gran nube de nodos. Otras tareas, sin embargo, son mucho m\u00e1s f\u00e1ciles de paralelizar; proyectos como SETI @ home, Folding @ home y algoritmos gen\u00e9ticos pueden ser f\u00e1cilmente implementados en la parte superior de dicha plataforma.<\/li>\n<li><strong>Sistemas de juegos y apuestas peer to peer<\/strong>. Cualquier numero de protocolos de juegos peer to peer (de igual a igual), tales como\u00a0<a href=\"http:\/\/www.cl.cam.ac.uk\/~fms27\/papers\/2008-StajanoCla-cyberdice.pdf\" target=\"_blank\" rel=\"nofollow noopener\">Cyberdice<\/a>de Richard Clayton, puede implementarse sobre la cadena de bloques de Ethereum. El protocolo de juego m\u00e1s simple, es en realidad un contrato por diferencia con el hash del bloque siguiente, cualquier protocolo m\u00e1s avanzado se puede construir a partir de ah\u00ed, creando servicios de juego con tasas cercanas a cero y que no tienen capacidad para hacer trampas.<\/li>\n<li><strong>Predicci\u00f3n de Mercados<\/strong>. Proporcionando un or\u00e1culo o SchellingCoin, la predicci\u00f3n de mercados es f\u00e1cil de implementar. La predicci\u00f3n de mercados junto con SchellingCoin puede proporcionar la primera aplicaci\u00f3n de futarqu\u00eda<a href=\"http:\/\/www.santiagomarquezsolis.com\/ethereum-whitepaper-traducido-al-castellano\/#_ftn7\" target=\"_blank\" rel=\"nofollow noopener\">[7]<\/a>\u00a0como protocolo de gobierno para organizaciones descentralizadas.<\/li>\n<li><strong>Mercados Descentralizados On-chain<\/strong>, usando como base los sistemas de identidad y reputaci\u00f3n<\/li>\n<\/ol>\n<h2>Varios y Preocupaciones<\/h2>\n<h3>Implementaci\u00f3n Modificada GHOST<\/h3>\n<p>El protocolo \u201cGreedy Heaviest Observed Subtree\u201d (Ghost) es una innovaci\u00f3n introducida por primera vez por Yonatan Sompolinsky y Aviv Zohar en diciembre de 2013. La motivaci\u00f3n detr\u00e1s de GHOST es que las cadenas de bloques con tiempos de confirmaci\u00f3n m\u00e1s r\u00e1pidos, actualmente sufren de seguridad reducida debido a una alta tasa de caducidad \u2013 es decir, los bloques se toman un cierto tiempo en propagarse a trav\u00e9s de la red, si un minero A mina un bloque y seguidamente un minero B mina otro bloque antes que el bloque del minero A se propague a B, el bloque del minero B terminar\u00e1 desaprovechado y no contribuir\u00e1 a la seguridad de la red. Adem\u00e1s, hay un problema de centralizaci\u00f3n: si el minero A es un grupo (un pool) minero que posee el 30% del poder de hash y B tiene el 10% de este poder, A tendr\u00e1 un riesgo de producir un bloque caducado solo el 70% del tiempo (ya que el otro 30% de las veces A produjo el \u00faltimo bloque y obtendr\u00e1 los datos de la miner\u00eda de inmediato), mientras que B tendr\u00e1 un riesgo de producir un bloque caducado el 90% de las veces. Por lo tanto, si el intervalo entre bloques es lo suficientemente corto como para que esta tasa de caducidad sea alta, A ser\u00e1 sustancialmente m\u00e1s eficiente simplemente en virtud de su tama\u00f1o. Con estos dos efectos combinados, las cadenas de bloques que producen bloques m\u00e1s r\u00e1pidamente, es muy probable que est\u00e9n siendo generadas, por una piscina de miner\u00eda que tiene suficiente porcentaje de poder de hash en la red y que de facto, tiene el control sobre el proceso de miner\u00eda.<\/p>\n<p>Seg\u00fan lo descrito por Sompolinsky y Zohar, GHOST resuelve el primer problema de p\u00e9rdida de seguridad de la red mediante la inclusi\u00f3n de bloques caducados en el c\u00e1lculo de cual es la cadena \u201cm\u00e1s larga\u201d; es decir, no s\u00f3lo los padres y otros antepasados de un bloque, sino tambi\u00e9n los descendientes caducados de los antepasados del bloque (en la jerga de Ethereum, \u201ct\u00edos\u201d) se a\u00f1aden al c\u00e1lculo, asi el bloque tiene la mayor prueba de trabajo que lo respalda. Para resolver el segundo problema de sesgo de la centralizaci\u00f3n, vamos m\u00e1s all\u00e1 del protocolo descrito por Sompolinsky y Zohar, y tambi\u00e9n se ofrecen recompensas por los bloques caducados: un bloque caducado recibe el 87,5% de su recompensa base, y el sobrino, que incluye al bloque caducado, recibe el restante 12,5%. Los gastos de transacci\u00f3n, sin embargo, no se otorgan a los t\u00edos.<\/p>\n<p>Ethereum implementa una versi\u00f3n simplificada de GHOST la cual solamente desciende siete niveles. Espec\u00edficamente se define del modo siguiente:<\/p>\n<ul>\n<li>Un bloque debe especificar un padre, y debe especificar 0 o m\u00e1s tios.<\/li>\n<li>Un t\u00edo incluido en un bloque B debe tener las siguientes propiedades:\n<ul>\n<li>Debe ser hijo directo de la k-esima generaci\u00f3n antepasada de B, donde 2 &lt;= k &lt;= 7.<\/li>\n<li>No puede ser un antepasado de B<\/li>\n<li>Un tio debe tener una cabecera de bloque v\u00e1lida, pero no tiene que ser de un bloque previamente verificado o incluso v\u00e1lido<\/li>\n<li>Un tio debe ser diferente de todos los t\u00edos incluidos en los bloques previos y de todos los otros t\u00edos incluidos dentro del mismo bloque (no-doble-inclusi\u00f3n)<\/li>\n<\/ul>\n<\/li>\n<li>Por cada t\u00edo U en el bloque B, \u00a0el minero de B obtiene un 3.125% adicional que se a\u00f1ade a su recompensa coinbase, el minero de U obtiene el 93.75% de la recompensa coinbase est\u00e1ndar.<\/li>\n<\/ul>\n<p>Esta versi\u00f3n limitada de GHOST, con t\u00edos incluibles solamente hasta 7 generaciones fue utilizada por dos razones. Primera, un GHOST ilimitado incluir\u00eda demasiadas complicaciones en el c\u00e1lculo de cual tio es v\u00e1lido para un bloque dado. Segundo, un GHOST ilimitado con compensaci\u00f3n como se usa en Ethereum elimina el incentivo para que el minero mine en la cadena principal y no en la cadena de un atacante.<\/p>\n<h3>Tasas<\/h3>\n<p>Debido a que cada transacci\u00f3n publicada en la cadena de bloques impone a la red el costo de tener que descargarla y comprobarla, hay una necesidad de alg\u00fan mecanismo de regulaci\u00f3n, que normalmente implica tasas de transacci\u00f3n, para evitar abusos. El enfoque predeterminado, utilizado en Bitcoin, es tener tasas puramente voluntarias, confiando en los mineros para que act\u00faen como los guardianes y establezcan m\u00ednimos din\u00e1micos. Y ha sido recibido particularmente, en la comunidad Bitcoin, muy favorablemente porque est\u00e1 \u201cbasado en el mercado\u201d, lo que permite que la oferta y la demanda entre los mineros y los transmisores de transacci\u00f3n determinen el precio. El problema con esta l\u00ednea 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 est\u00e1 ofreciendo al transmisor, en realidad, cada transacci\u00f3n que un minero incluye tendr\u00e1 que ser procesada por cada nodo de la red, por lo que la gran mayor\u00eda de los costes de procesamiento de la transacci\u00f3n se soportan por terceros y no por el minero que est\u00e1 tomando la decisi\u00f3n de si debe o no incluirla. Por lo tanto, la tragedia de los comunes es un problema que es muy probable que pueda ocurrir.<\/p>\n<p>Sin embargo, resulta que este fallo en el mecanismo basado en el mercado, cuando se da un supuesto inexacto simplificado en particular, por arte de magia se cancela a s\u00ed mismo. El argumento es el siguiente. Supongamos que:<\/p>\n<ol>\n<li>Una transacci\u00f3n conduce a k operaciones, ofreciendo una recompensa de kR a cualquier minero que la incluya y en donde R es fijado por el emisor y k y R son (m\u00e1s o menos) visibles de antemano para el minero.<\/li>\n<li>Una operaci\u00f3n tiene un costo de procesamiento C para cualquier nodo (es decir, todos los nodos tienen la misma eficacia)<\/li>\n<li>Hay N nodos de miner\u00eda, cada uno con una potencia de procesamiento exactamente igual (es decir 1\/N del total).<\/li>\n<li>No existen nodos completos no mineros.<\/li>\n<\/ol>\n<p>Un minero estar\u00eda dispuesto a procesar una transacci\u00f3n si la recompensa esperada es mayor que el costo. Por lo tanto, la recompensa esperada es kR\/N donde el minero tiene una probabilidad de 1\/N de procesar el siguiente bloque, y el costo de procesamiento para el minero es simplemente kC. Seg\u00fan esto, los mineros incluir\u00e1n las transacciones donde kR\/N&gt;KC, o R&gt;NC. Tenga en cuenta que R es la tarifa por operaci\u00f3n proporcionado por el emisor, y es por tanto un l\u00edmite inferior en el beneficio que para el emisor se deriva de la transacci\u00f3n, y NC es el costo para toda la red que en conjunto procesa la operaci\u00f3n. Por lo tanto, los mineros tienen el incentivo para incluir s\u00f3lo aquellas operaciones para las que el beneficio utilitario total exceda el costo.<\/p>\n<p>Sin embargo, hay varias desviaciones importantes de estos supuestos en realidad:<\/p>\n<ol>\n<li>El minero hace pagar un costo m\u00e1s alto para procesar la transacci\u00f3n que los otros nodos de verificaci\u00f3n, ya que los tiempos adicionales de verificaci\u00f3n retarda la propagaci\u00f3n del bloque y por tanto aumenta la posibilidad de que \u00e9ste se convierta en uno caducado.<\/li>\n<li>Existen nodos completos no mineros.<\/li>\n<li>La distribuci\u00f3n de potencia minera puede acabar siendo radicalmente igualitaria en la pr\u00e1ctica.<\/li>\n<li>Los especuladores, enemigos pol\u00edticos y locos cuya una \u00fanica funci\u00f3n de utilidad es causar da\u00f1os a la red, y que h\u00e1bilmente pueden establecer contratos en los que su coste es mucho menor que el coste pagado por otros nodos de verificaci\u00f3n.<\/li>\n<\/ol>\n<p>(1) conlleva una tendencia a que el minero incluya menos transacciones, y (2) aumenta NC; por lo tanto, estos dos efectos, al menos parcialmente se anulan entre s\u00ed. (3) y (4) son el principal problema; para resolverlos basta simplemente con instituir una tapa flotante: ning\u00fan bloque puede tener m\u00e1s operaciones que BLK_LIMIT_FACTOR veces el promedio m\u00f3vil exponencial a largo plazo. Espec\u00edficamente:<\/p>\n<blockquote>\n<p class=\"left\">blk.oplimit = floor((blk.parent.oplimit * (EMAFACTOR \u2013 1) + floor(parent.opcount * BLK_LIMIT_FACTOR)) \/ EMA_FACTOR)<\/p>\n<\/blockquote>\n<p>BLK_LIMIT_FACTOR y EMA_FACTOR son constantes que se establecer\u00e1 en 65.536 y 1,5 por el momento, pero es probable que se cambian despu\u00e9s de un an\u00e1lisis m\u00e1s detallado.<\/p>\n<p>Hay otro factor que desincentiva grandes tama\u00f1os de bloque de Bitcoin: los bloques que son grandes llevan m\u00e1s tiempo en propagarse, y por tanto tienen una mayor probabilidad de convertirse en caducados. En Ethereum, los bloques con un alto consumo de gas tambi\u00e9n pueden tomar m\u00e1s tiempo en propagarse tanto porque pueden ser f\u00edsicamente m\u00e1s grande o debido a que necesitan m\u00e1s tiempo para procesar y validar las transiciones de estado de transacci\u00f3n. Esto retraso descentivador es una consideraci\u00f3n importante en Bitcoin, pero no tanto en Ethereum debido al protocolo GHOST; por lo tanto, bas\u00e1ndose en los l\u00edmites regulados de bloque proporciona una base m\u00e1s estable.<\/p>\n<h3>Computaci\u00f3n y Turing-Completo<\/h3>\n<p>Una importante caracter\u00edstica de la M\u00e1quina Virtual de Ethereum es que es Turing completo; esto significa que en el c\u00f3digo EVM se puede codificar cualquier c\u00e1lculo concebible, incluyendo bucles infinitos. El c\u00f3digo EVM permite los bucles de dos maneras. En primer lugar, hay una instrucci\u00f3n JUMP que permite al programa volver (saltar) de nuevo a un punto anterior en el c\u00f3digo, y una instrucci\u00f3n JUMPI que sirve para hacer saltos condicionales, lo que permitir\u00eda declaraciones como: mientras x &lt;27: x = x * 2. En segundo lugar, los contratos pueden llamar a otros contratos, permitiendo potencialmente hacer bucles trav\u00e9s de la recursividad. Esto conduce naturalmente a un problema: \u00bfpueden los usuarios maliciosos tirar a bajo a mineros y nodos completos oblig\u00e1ndoles a entrar en un bucle infinito? El problema surge debido a un problema en inform\u00e1tica conocido como el problema de la parada<a href=\"http:\/\/www.santiagomarquezsolis.com\/ethereum-whitepaper-traducido-al-castellano\/#_ftn8\" target=\"_blank\" rel=\"nofollow noopener\">[8]<\/a>\u00a0(halting problem): no hay manera de saber, de manera general, si un determinado programa se detendr\u00e1 (halt).<\/p>\n<p>Como se describe en la secci\u00f3n de transici\u00f3n de estado, nuestra soluci\u00f3n funciona requiriendo a las operaciones establecer un n\u00famero m\u00e1ximo de pasos computacionales que se les permite gastar, de modo que si la ejecuci\u00f3n lleva m\u00e1s tiempo de computaci\u00f3n que la permitida, \u00e9sta se revierte pero las tasas a\u00fan se pagan. Los mensajes funcionan de la misma manera. Para mostrar la motivaci\u00f3n detr\u00e1s de nuestra soluci\u00f3n, considere los siguientes ejemplos:<\/p>\n<ul>\n<li>Un atacante crea un contrato que ejecuta un bucle infinito y, a continuaci\u00f3n, env\u00eda una transacci\u00f3n para activar ese bucle a un minero. El minero procesar\u00e1 la transacci\u00f3n, que ejecuta el bucle infinito, y esperar\u00e1 a que se quede sin gas. A pesar de que la ejecuci\u00f3n se queda sin gasolina y se detiene a medio camino, la transacci\u00f3n sigue siendo v\u00e1lida y el minero todav\u00eda reclama la cuota del atacante para cada paso de c\u00e1lculo.<\/li>\n<li>Un atacante crea un bucle infinito muy largo con la intenci\u00f3n de obligar al minero mantener los c\u00e1lculos durante tanto tiempo, que cuando \u00e9ste termine unos cuantos bloques m\u00e1s se habr\u00e1n generado y no va a serle posible incluir la transacci\u00f3n para reclamar la tarifa. Sin embargo, se requerir\u00e1 al atacante presentar un valor para STARTGAS que limitar\u00e1 el n\u00famero de pasos de c\u00e1lculo que esta ejecuci\u00f3n puede llevar a cabo, el minero sabe de antemano que el c\u00e1lculo llevar\u00e1 un n\u00famero excesivamente grande de pasos.<\/li>\n<li>Un atacante observa un contrato que tiene un c\u00f3digo de la siguiente forma: send(A,contract.storage[A]); contract.storage[A] = 0, y env\u00eda una transacci\u00f3n con suficiente gas para ejecutar el primer paso pero no el segundo (por ejemplo, haciendo una retirado pero no dejando que el balance disminuya). El autor del contrato no necesita preocuparse de c\u00f3mo protegerse contra estos ataques, porque la ejecuci\u00f3n se parar\u00e1 a la mitad.<\/li>\n<li>Un contrato financiero funciona tomando la mediana de nueve fuentes de datos propietarias con el fin de minimizar el riesgo. Un atacante compromete una de estas fuentes de datos, que est\u00e1 dise\u00f1ado para ser modificables a trav\u00e9s del mecanismo de llamada de direcci\u00f3n de variable descrito en el apartado de los DAOs, y la convierte para ejecutar un bucle infinito, intentando de ese modo que cualquier intento de reclamar los fondos de el contrato financiero se quede sin gas. Sin embargo, el contrato financiero puede establecer un l\u00edmite de gas en el mensaje para evitar este problema.<\/li>\n<\/ul>\n<p>La alternativa a Turing complete es Turing incompleto o no completo, donde JUMP\u00a0y\u00a0JUMPI no existen y solamente una copia de cada contrato tiene permitido existir en la pila de llamadas en cada momento dado. Con este sistema, el sistema de tasas descrito y las incertidumbres alrededor de la eficacia de nuestra soluci\u00f3n puede que no sea necesaria, ya que el costo de la ejecuci\u00f3n de un contrato ser\u00eda acotado superiormente por su tama\u00f1o. Adem\u00e1s, Turing-incompleto ni siquiera es una limitaci\u00f3n tan grande; de entre todos los ejemplos de contratos que hemos concebido internamente, hasta ahora s\u00f3lo uno requiere un bucle, y hasta ese bucle podr\u00edan eliminarse al hacer 26 repeticiones de una pieza de una sola l\u00ednea de c\u00f3digo. Teniendo en cuenta las serias implicaciones de ser Turing completo, y el beneficio limitado, \u00bfpor qu\u00e9 no simplemente tener un lenguaje Turing incompleto? En realidad, sin embargo, ser Turing incompleto est\u00e1 lejos de ser una soluci\u00f3n ordenada al problema. Para ver por qu\u00e9, considere los siguientes contratos:<\/p>\n<blockquote>\n<p class=\"left\">C0: call(C1); call(C1);<\/p>\n<p class=\"left\">C1: call(C2); call(C2);<\/p>\n<p class=\"left\">C2: call(C3); call(C3);<\/p>\n<p class=\"left\">\u2026<\/p>\n<p class=\"left\">C49: call(C50); call(C50);<\/p>\n<p class=\"left\">C50: (ejecuta un paso de un programa y guarda el cambio en el almac\u00e9n)<\/p>\n<\/blockquote>\n<p>Ahora, env\u00eda una transacci\u00f3n a A. As\u00ed, en 51 transacciones, tenemos un contrato que toma 250 pasos de c\u00e1lculo (o ejecuci\u00f3n). Los mineros podr\u00edan tratar de detectar este tipo de bombas l\u00f3gicas antes, manteniendo un valor, junto a cada contrato, que especifique el n\u00famero m\u00e1ximo de pasos de c\u00e1lculo que puede tener, y recalcul\u00e1ndolo para contratos que a su vez llaman a otros contratos de forma recursiva, pero esto requerir\u00eda de los mineros el prohibir contratos que crearan otros contratos (la creaci\u00f3n y ejecuci\u00f3n de los 26 contratos anteriores podr\u00edan ser f\u00e1cilmente agrupados en un solo contrato). Otro punto problem\u00e1tico es que el campo de direcci\u00f3n de un mensaje es una variable, por lo que en general, podr\u00eda incluso no ser posible decir que otros contratos ser\u00e1n llamados desde un contrato determinado. De ah\u00ed que, consider\u00e1ndolo todo, tenemos una sorprendente conclusi\u00f3n: manejar el Turing completo es sorprendentemente f\u00e1cil, y la falta de Turing completo es igualmente sorprendentemente dif\u00edcil de manejar, a menos que, exactamente los mismos controles est\u00e9n en su lugar \u2013 pero en ese caso \u00bfpor qu\u00e9 no dejar simplemente que el protocolo sea Turing completo?<\/p>\n<h3>Moneda y Emisi\u00f3n<\/h3>\n<p>La red Ethereum incluye su propio sistema monetario, el ether, que tiene el doble objetivo de proporcionar una capa de liquidez primaria para permitir el intercambio eficiente entre los distintos tipos de activos digitales, y m\u00e1s importante, proporcionar un mecanismo para el pago de las comisiones por transacciones. Para mayor comodidad y evitar debates futuros (v\u00e9ase los debates en Bitcoin sobre el uso de mBTC\/uBTC\/satoshi), las denominaciones ser\u00e1n pre etiquetadas como:<\/p>\n<ul>\n<li>1: wei<\/li>\n<li>1012: szabo<\/li>\n<li>1015: finney<\/li>\n<li>1018: ether<\/li>\n<\/ul>\n<p>Y que deben\u00a0ser tomados como\u00a0una versi\u00f3n ampliada\u00a0del concepto de\u00a0\u201cd\u00f3lares\u201d y \u201ccentavos\u201d o\u00a0\u201cBTC\u201d y \u201cSatoshi\u201d.\u00a0En un futuro cercano, esperamos\u00a0que el \u201cether\u201d\u00a0 se utilice para\u00a0transacciones ordinarias,\u00a0\u201cfinney\u201d\u00a0para\u00a0microtransacciones\u00a0y \u201cszabo\u201d y \u201cwei\u201d\u00a0para discusiones\u00a0t\u00e9cnicas en torno a\u00a0los honorarios y\u00a0aplicaci\u00f3n\u00a0del protocolo;\u00a0las denominaciones\u00a0restantes\u00a0pueden llegar a ser\u00a0\u00fatiles m\u00e1s adelante\u00a0y no deben ser incluidas en\u00a0los clientes\u00a0en este momento.<\/p>\n<p>El modelo de emission ser\u00e1 como sigue:<\/p>\n<ul>\n<li>El ether se pondr\u00e1 a la venta a un precio de entre 1000-2000 unidades de ether por BTC, un mecanismo destinado a financiar la organizaci\u00f3n Ethereum y a pagar el desarrollo. Esta opci\u00f3n ha sido utilizada con \u00e9xito por otras plataformas como Mastercoin y NXT. Los primeros compradores se beneficiar\u00e1n de descuentos m\u00e1s grandes. Los BTC recibidos de esta venta ser\u00e1n utilizados en su totalidad para pagar sueldos y recompensas a los desarrolladores e invertir en diversos proyectos tanto con fines de lucro como sin ellos, dentro del ecosistema de las criptomonedas y Ethereum.<\/li>\n<li>0.099x de la cantidad total vendida (60.102.216 ETH) se destinar\u00e1n a la organizaci\u00f3n para compensar a los primeros contribuyentes y pagar los gastos denominados en ETH antes del bloque g\u00e9nesis.<\/li>\n<li>0.099x de la cantidad total vendida se mantendr\u00e1 como reserva a largo plazo.<\/li>\n<li>Despu\u00e9s de ese punto, el 0.26x de la cantidad total vendida se destinar\u00e1 a los mineros por a\u00f1o para siempre.<\/li>\n<\/ul>\n<div class=\"slate-resizable-image-embed slate-image-embed__resize-full-width\"><img decoding=\"async\" src=\"https:\/\/media.licdn.com\/dms\/image\/C4E12AQF7TaWa0cGhhw\/article-inline_image-shrink_400_744\/0\/1520548848322?e=1722470400&amp;v=beta&amp;t=B9UZPK0xDtotSy6Lx4MKYechb6-Uc3gGP6Z4Aq-pbcM\" data-media-urn=\"\" data-li-src=\"https:\/\/media.licdn.com\/dms\/image\/C4E12AQF7TaWa0cGhhw\/article-inline_image-shrink_400_744\/0\/1520548848322?e=1722470400&amp;v=beta&amp;t=B9UZPK0xDtotSy6Lx4MKYechb6-Uc3gGP6Z4Aq-pbcM\" \/><\/div>\n<p class=\"center\"><strong>Tasa Crecimiento y Suministro a Largo Plazo (porcentaje)<\/strong><\/p>\n<p><em>A pesar de seguir una emisi\u00f3n de moneda lineal, al igual que con Bitcoin, con el tiempo la tasa de crecimiento de la oferta tiende a cero.<\/em><\/p>\n<p>Las dos opciones principales del anterior modelo son (1) la existencia y el tama\u00f1o de una piscina de dotaci\u00f3n, y (2) la existencia de un suministro lineal permanentemente creciente, en oposici\u00f3n a un suministro cerrado como en Bitcoin. La justificaci\u00f3n de la piscina de dotaci\u00f3n es la siguiente. Si no existiera, y la emisi\u00f3n lineal se redujese a 0.217x para poder proporcionar la misma tasa de inflaci\u00f3n, entonces la cantidad total de ether ser\u00eda un 16,5% menor y entonces cada unidad ser\u00eda 19,8% m\u00e1s valiosa. Por lo tanto, para mantener el equilibrio es necesario comprar un 19,8% m\u00e1s de ether en la venta, por lo que cada unidad vuelve a ser, una vez m\u00e1s, exactamente tan valiosa como antes. La organizaci\u00f3n tambi\u00e9n tendr\u00eda entonces 1.198x como mucho en BTC, y que puede considerarse que estar\u00eda dividido en dos partes: los BTC originales, y el 0.198x adicional. Esta situaci\u00f3n es\u00a0<em>exactamente equivalente<\/em>\u00a0a la dotaci\u00f3n, pero con una diferencia importante y es que la organizaci\u00f3n mantiene \u00fanicamente BTC, por lo que no est\u00e1 incentivada en apoyar el valor de la unidad de ether.<\/p>\n<p>El modelo permanente de crecimiento lineal de la oferta reduce el riesgo de lo que algunos ven como una concentraci\u00f3n excesiva de la riqueza en Bitcoin, y da a los individuos que viven tanto en el presente como en eras futuras, una buena oportunidad para adquirir unidades de moneda, mientras que al mismo tiempo conserva un fuerte incentivo para obtener y mantener ether porque la \u201ctasa de crecimiento de la oferta\u201d como porcentaje tender\u00e1 a cero con el tiempo. Tambi\u00e9n teorizamos que, debido a que siempre existen monedas que se pierden con el tiempo debido a negligencias, muerte, etc, esta p\u00e9rdida puede modelarse como un porcentaje en la oferta total por a\u00f1o, de este modo y con el tiempo, el suministro de divisas totales en circulaci\u00f3n, se estabilizar\u00e1 en un valor igual a la emisi\u00f3n anual dividido por la tasa de p\u00e9rdida (por ejemplo, con una tasa de p\u00e9rdida del 1%, una vez que el suministro de moneda alcance el 26X entonces, se crear\u00e1 un equilibrio entre el \u00a00,26X que ser\u00e1 minado, y los otros 0,26X que se perder\u00edan cada a\u00f1o).<\/p>\n<p>Tenga en cuenta que en el futuro, es probable que Ethereum cambie a un modelo de prueba de participaci\u00f3n (proof of stake) por seguridad, reduciendo el requisito de emisi\u00f3n hasta alg\u00fan punto entre cero y 0.05x por a\u00f1o. En el caso de que la organizaci\u00f3n Ethereum perdiera financiaci\u00f3n o por cualquier otra raz\u00f3n desapareciera, se deja abierto un \u201ccontrato social\u201d en donde cualquier persona tiene derecho a crear una futura versi\u00f3n candidata de Ethereum, con la \u00fanica condici\u00f3n de que la cantidad de ether debe ser como m\u00e1ximo igual a 60102216 * (1,198 + 0,26 * n) donde n es el n\u00famero de a\u00f1os despu\u00e9s del bloque g\u00e9nesis. Los creadores son libres de vender, ceder parte o la totalidad de la diferencia entre la expansi\u00f3n de la oferta PoS-accionar\u00edada y la ampliaci\u00f3n m\u00e1xima permisible como pago por el desarrollo. Las actualizaciones candidatas que no cumplan con el contrato social pueden ser bifurcadas justificadamente a versiones compatibles.<\/p>\n<h3>Centralizaci\u00f3n de la Miner\u00eda<\/h3>\n<p>El algoritmo de miner\u00eda Bitcoin funciona usando mineros que ejecutan la funci\u00f3n SHA256, sobre versiones ligeramente modificada de la cabecera de un bloque, millones de veces una y otra vez, hasta que finalmente uno de ellos obtine una versi\u00f3n v\u00e1lida cuyo hash es inferior al objetivo (en la actualidad alrededor de 2192). Sin embargo, este algoritmo de miner\u00eda es vulnerable a dos formas de centralizaci\u00f3n. En primer lugar, el ecosistema de la miner\u00eda ha llegado a ser dominado por ASIC (circuitos integrados de aplicaci\u00f3n espec\u00edfica), que son chips de computadora dise\u00f1ados para este prop\u00f3sito, y por tanto miles de veces m\u00e1s eficientes en la tarea espec\u00edfica de la miner\u00eda Bitcoin. Esto significa que la miner\u00eda Bitcoin ya no es una actividad altamente descentralizada e igualitaria, sino que se requiere de millones de d\u00f3lares de capital para poder participar de manera efectiva. En segundo lugar, la mayor\u00eda de los mineros Bitcoin en realidad no realizan una validaci\u00f3n del bloque localmente sino que utilizan una piscina (pool) de miner\u00eda centralizada para proporcionar las cabeceras de los bloques. Este problema es posiblemente peor: en el momento de escribir esto, los tres principales grupos mineros controlan indirectamente aproximadamente el 50% de la potencia de procesamiento de la red Bitcoin, aunque esto se ve mitigado por el hecho de que los mineros pueden cambiar a otras piscinas mineras si una piscina o coalici\u00f3n intentar\u00e1 un ataque de 51%.<\/p>\n<p>La intenci\u00f3n actual en Ethereum es utilizar un algoritmo de miner\u00eda donde se requiere que los mineros busquen datos aleatorios del estado, calculen algunas transacciones seleccionadas al azar de los \u00faltimos N bloques en la cadena de bloques, y devuelvan el hash del resultado. Esto tiene dos beneficios importantes. Primero, los contratos de Ethereum pueden incluir cualquier clase de computaci\u00f3n, por tanto, un ASIC Ethereum esencialmente ser\u00eda un ASIC para computaci\u00f3n general, por ejemplo una mejor CPU. Segundo, la miner\u00eda requiere acceder a toda la cadena de bloques, forzando a los mineros a almacenarla por completo y al menos ser capaces de verificar cada transacci\u00f3n. Esto elimina la necesidad de pools de miner\u00eda centralizados, y aunque pueden todav\u00eda servir para el papel leg\u00edtimo de la distribuci\u00f3n aleatoria de la recompensa, esta funci\u00f3n puede ser realizada igualmente bien con una piscina de igual a igual (peer-to-peer) sin ning\u00fan control central.<\/p>\n<p>Este modelo no est\u00e1 probado, y puede haber dificultades a lo largo del camino para evitar ciertos tipos de optimizaciones inteligentes como usar la ejecuci\u00f3n de un contrato como algoritmo de miner\u00eda. Sin embargo, una interesante y notable caracter\u00edstica de este algoritmo es que permite a cualquiera \u201cenvenenar el pozo\u201d mediante la introducci\u00f3n de un gran n\u00famero de contratos en la cadena de bloques espec\u00edficamente dise\u00f1ados para bloquear ciertos ASICS. Los incentivos econ\u00f3micos que existen para los fabricantes ASIC podr\u00edan motivar usar tal truco para atacarse unos a otros. Por tanto, la soluci\u00f3n que estamos desarrollando es, en \u00faltima instancia, una soluci\u00f3n humana de adaptaci\u00f3n econ\u00f3mica\u00a0 m\u00e1s que una puramente t\u00e9cnica.<\/p>\n<h3>Escalabilidad<\/h3>\n<p>Una preocupaci\u00f3n com\u00fan acerca de Ethereum es el tema de la escalabilidad. Al igual que Bitcoin, Ethereum adolece del defecto de que cada transacci\u00f3n debe ser procesada por cada nodo de la red. Con Bitcoin, el tama\u00f1o de la blockchain actual est\u00e1 alrededor de 15 GB, creciendo cerca de 1 MB por hora. Si la red Bitcoin tuviera que procesar 2000 transacciones por segundo del tipo VISA, crecer\u00eda a raz\u00f3n de un 1 MB cada tres segundos (1 GB por hora, 8 TB por a\u00f1o). Ethereum es probable que sufra un patr\u00f3n de crecimiento similar, agravada por el hecho de que habr\u00e1 muchas aplicaciones en la parte superior de la cadena de bloques de Ethereum, en lugar de s\u00f3lo una moneda como es el caso de Bitcoin, pero mejorada por el hecho de que en Ethereum los nodos completos s\u00f3lo necesitan almacenar el estado en lugar de toda la historia de la cadena de bloques.<\/p>\n<p>El problema con un tama\u00f1o tan grande de la cadena de bloques es el riesgo de la centralizaci\u00f3n. Si el tama\u00f1o de \u00e9sta aumentar\u00e1 a, digamos, 100 TB, el escenario m\u00e1s probable ser\u00eda que s\u00f3lo un n\u00famero muy reducido de grandes empresas correr\u00eda nodos completos, con todos los usuarios regulares utilizando nodos ligeros del tipo SPV. En tal situaci\u00f3n, surge la preocupaci\u00f3n potencial que estos nodos completos podr\u00edan unirse y ponerse deacuerdo para enga\u00f1ar de alguna manera que resultara rentable (por ejemplo, cambiar la recompensa en BTC por bloque que reciben). Los nodos ligeros no tendr\u00edan forma de detectar esto inmediatamente. Por supuesto, es probable que exista al menos un nodo completo honesto, y es seguro que despu\u00e9s de algunas horas la informaci\u00f3n sobre el fraude podr\u00eda aparecer y filtrarse a trav\u00e9s de canales como Reddit, pero en ese momento ya ser\u00eda demasiado tarde: y aunque los usuarios comunes podr\u00edan organizarse para crear una lista negra con estos bloques, estar\u00edamos ante un problema que implicar\u00eda un movimiento de coordinaci\u00f3n masiva y probablemente inviable, con una escala similar a la de un ataque del 51% exitoso. En el caso de Bitcoin, esto es actualmente un problema, aunque existe una modificaci\u00f3n para la cadena de bloques sugerida por Peter Todd que lo aliviar\u00eda.<\/p>\n<p>En el corto plazo, Ethereum utilizar\u00e1 dos estrategias adicionales para hacer frente a este problema.Primero, debido a los algoritmos de minado basados en la cadena de bloques, cada minero estar\u00eda forzado a ser un nodo completo, lo que ya crear\u00eda una cota m\u00ednima en este n\u00famero de nodos. En segundo\u00a0 lugar y m\u00e1s importante, incluiremos un estado intermedio en la ra\u00edz del \u00e1rbol en la cadena de bloques despu\u00e9s de procesar cada transacci\u00f3n. Incluso si la validaci\u00f3n de un bloque es centralizada, mientras exista un nodo de verificaci\u00f3n honesto el problema de la centralizaci\u00f3n puede eludirse mediante un protocolo de verificaci\u00f3n. Si un minero publica un bloque inv\u00e1lido, lo ser\u00e1 porque el bloque est\u00e1 o mal formado o el estado S[n]\u00a0es incorrecto. Dado que se conoce que S[0]\u00a0es correcto, deber\u00eda haber alg\u00fan estado inicial S[i]\u00a0que es incorrecto pero donde S[i-1]\u00a0es correcto. El nodo de verificaci\u00f3n proporcionar\u00eda el indice i, junto con una \u201cprueba de invalidez\u201d\u00a0 que consistir\u00eda en un subconjunto de nodos del \u00e1rbol Patricia que necesitar\u00edan procesar la funci\u00f3n APPLY(S[i-1],TX[i]) -&gt; S[i]. Los nodos ser\u00edan capaces de usar estos nodos para ejecutar esa parte de ejecuci\u00f3n y ver que el S[i]\u00a0generado no coincide con el S[i]\u00a0proporcionado.<\/p>\n<p>Otro ataque m\u00e1s sofisticado, ser\u00eda involucrar a mineros maliciosos para que publicaran bloques incompletos, de este modo ni siquiera existir\u00eda informaci\u00f3n completa para determinar si son o no v\u00e1lidos. La soluci\u00f3n a esto es un protocolo del tipo desaf\u00edo-respuesta: los nodos de verificaci\u00f3n emitir\u00edan \u201cdesaf\u00edos\u201d en forma de \u00edndices de transacci\u00f3n de destino, un nodo ligero tratar\u00eda el bloque como que no es de confianza hasta que otro nodo, un minero u otro verificador, proporcione un subconjunto de nodos Patricia como prueba de su validez.<\/p>\n<h2>Conclusiones<\/h2>\n<p>El protocolo Ethereum fue originalmente concebido como una versi\u00f3n actualizada de criptomoneda, proporcionando caracter\u00edsticas avanzadas como: las garant\u00edas dentro de la cadena de bloques, los l\u00edmites de retirada, los contratos financieros, los juegos de azar y aplicaciones similares a trav\u00e9s de un lenguaje de programaci\u00f3n generalizado. El protocolo Ethereum no \u201csoporta\u201d ninguna de las aplicaciones directamente, pero la existencia de un lenguaje de programaci\u00f3n del tipo Turing-completo significa que todo contrato arbitrario puede, te\u00f3ricamente, crearse para cualquier tipo de transacci\u00f3n o aplicaci\u00f3n. Sin embargo lo que es m\u00e1s interesante de Ethereum es que el protocolo va m\u00e1s all\u00e1\u00a0de ser solamente una moneda. Protocolos sobre almacenamiento de archivos descentralizado, computaci\u00f3n descentralizada y la predicci\u00f3n de mercados descentralizados, entre otra docena de conceptos, tienen el potencial de incrementar sustancialmente la eficiencia de la industria computacional, y proporcionar un gran impulso a otros protocolos peer-to-peer a\u00f1adiendo por primera vez una capa econ\u00f3mica. Por \u00faltimo, tambi\u00e9n hay una variedad considerable de aplicaciones que no tienen nada que ver con el dinero en absoluto.<\/p>\n<p>El concepto de una funci\u00f3n de transici\u00f3n de estados, arbitraria e implementada como es proporcionada por el protocolo Ethereum, facilita una plataforma con un potencial \u00fanico. En lugar de ser un protocolo de prop\u00f3sito \u00fanico y cerrado, destinado a un conjunto espec\u00edfico de aplicaciones en el \u00e1mbito del almacenamiento de datos, los juegos de azar o las finanzas, Ethereum es, por dise\u00f1o, abierto y creemos que puede muy bien adaptarse como una capa fundacional para un gran n\u00famero de aplicaciones tanto financieras como no financieras que vendr\u00e1n en los pr\u00f3ximos a\u00f1os.<\/p>\n<h2>Notas y Lecturas Adicionales<\/h2>\n<h4>Notas<\/h4>\n<ol>\n<li>Un lector avanzado notar\u00e1 que de hecho una direcci\u00f3n Bitcoin es el hash de la clave p\u00fablica de una curva el\u00edptica, y no la clave p\u00fablica en si misma. Sin embargo, es de hecho perfectamente leg\u00edtimo en la terminolog\u00eda criptogr\u00e1fica referirse al hash de la pubkey como clave p\u00fablica. Esto es porque la criptograf\u00eda de Bitcoin puede ser considerada como un algoritmo de firma digital personalizada, donde la clave p\u00fablica consiste en el hash de la pubkey ECC. La firma consiste en la pubkey ECC concatenada con la firma ECC, el algoritmo de verificaci\u00f3n implica comprobar la pubkey ECC en la firma contra el hash de la pubkey que la ECC proporciona como clave p\u00fablica y luego verificar la firma ECC contra la pubkey ECC.<\/li>\n<li>Tecnicamente, la media de los 11 bloques previos.<\/li>\n<li>Internamente, 2 y \u201cCHARLIE\u201d son ambos n\u00fameros, este \u00faltimo representado en formato big-endian base 256. Los numerous pueden estar entre 0 y un m\u00e1ximo de 2256-1.<\/li>\n<\/ol>\n<h4>Lecturas Adicionales<\/h4>\n<ol>\n<li>Intrinsic value:<a href=\"http:\/\/bitcoinmagazine.com\/8640\/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it\/\" target=\"_blank\" rel=\"nofollow noopener\">http:\/\/bitcoinmagazine.com\/8640\/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it\/<\/a><\/li>\n<li>Smart property:<a href=\"https:\/\/en.bitcoin.it\/wiki\/Smart_Property\" target=\"_blank\" rel=\"nofollow noopener\">https:\/\/en.bitcoin.it\/wiki\/Smart_Property<\/a><\/li>\n<li>Smart contracts:<a href=\"https:\/\/en.bitcoin.it\/wiki\/Contracts\" target=\"_blank\" rel=\"nofollow noopener\">https:\/\/en.bitcoin.it\/wiki\/Contracts<\/a><\/li>\n<li>B-money:<a href=\"http:\/\/www.weidai.com\/bmoney.txt\" target=\"_blank\" rel=\"nofollow noopener\">http:\/\/www.weidai.com\/bmoney.txt<\/a><\/li>\n<li>Reusable proofs of work:<a href=\"http:\/\/www.finney.org\/~hal\/rpow\/\" target=\"_blank\" rel=\"nofollow noopener\">http:\/\/www.finney.org\/~hal\/rpow\/<\/a><\/li>\n<li>Secure property titles with owner authority:<a href=\"http:\/\/szabo.best.vwh.net\/securetitle.html\" target=\"_blank\" rel=\"nofollow noopener\">http:\/\/szabo.best.vwh.net\/securetitle.html<\/a><\/li>\n<li>Bitcoin whitepaper:<a href=\"http:\/\/bitcoin.org\/bitcoin.pdf\" target=\"_blank\" rel=\"nofollow noopener\">http:\/\/bitcoin.org\/bitcoin.pdf<\/a><\/li>\n<li>Namecoin:<a href=\"https:\/\/namecoin.org\/\" target=\"_blank\" rel=\"nofollow noopener\">https:\/\/namecoin.org\/<\/a><\/li>\n<li>Zooko\u2019s triangle:<a href=\"http:\/\/en.wikipedia.org\/wiki\/Zooko's_triangle\" target=\"_blank\" rel=\"nofollow noopener\">http:\/\/en.wikipedia.org\/wiki\/Zooko\u2019s_triangle<\/a><\/li>\n<li>Colored coins whitepaper:<a href=\"https:\/\/docs.google.com\/a\/buterin.com\/document\/d\/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE\/edit\" target=\"_blank\" rel=\"nofollow noopener\">https:\/\/docs.google.com\/a\/buterin.com\/document\/d\/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE\/edit<\/a><\/li>\n<li>Mastercoin whitepaper:<a href=\"https:\/\/github.com\/mastercoin-MSC\/spec\" target=\"_blank\" rel=\"nofollow noopener\">https:\/\/github.com\/mastercoin-MSC\/spec<\/a><\/li>\n<li>Decentralized autonomous corporations, Bitcoin Magazine:<a href=\"http:\/\/bitcoinmagazine.com\/7050\/bootstrapping-a-decentralized-autonomous-corporation-part-i\/\" target=\"_blank\" rel=\"nofollow noopener\">http:\/\/bitcoinmagazine.com\/7050\/bootstrapping-a-decentralized-autonomous-corporation-part-i\/<\/a><\/li>\n<li>Simplified payment verification:<a href=\"https:\/\/en.bitcoin.it\/wiki\/Scalability#Simplifiedpaymentverification\" target=\"_blank\" rel=\"nofollow noopener\">https:\/\/en.bitcoin.it\/wiki\/Scalability#Simplifiedpaymentverification<\/a><\/li>\n<li>Merkle trees:<a href=\"http:\/\/en.wikipedia.org\/wiki\/Merkle_tree\" target=\"_blank\" rel=\"nofollow noopener\">http:\/\/en.wikipedia.org\/wiki\/Merkle_tree<\/a><\/li>\n<li>Patricia trees:<a href=\"http:\/\/en.wikipedia.org\/wiki\/Patricia_tree\" target=\"_blank\" rel=\"nofollow noopener\">http:\/\/en.wikipedia.org\/wiki\/Patricia_tree<\/a><\/li>\n<li>GHOST:<a href=\"http:\/\/www.cs.huji.ac.il\/~avivz\/pubs\/13\/btc_scalability_full.pdf\" target=\"_blank\" rel=\"nofollow noopener\">http:\/\/www.cs.huji.ac.il\/~avivz\/pubs\/13\/btc_scalability_full.pdf<\/a><\/li>\n<li>StorJ and Autonomous Agents, Jeff Garzik:<a href=\"http:\/\/garzikrants.blogspot.ca\/2013\/01\/storj-and-bitcoin-autonomous-agents.html\" target=\"_blank\" rel=\"nofollow noopener\">http:\/\/garzikrants.blogspot.ca\/2013\/01\/storj-and-bitcoin-autonomous-agents.html<\/a><\/li>\n<li>Mike Hearn on Smart Property at Turing Festival:<a href=\"http:\/\/www.youtube.com\/watch?v=Pu4PAMFPo5Y\" target=\"_blank\" rel=\"noopener\">http:\/\/www.youtube.com\/watch?v=Pu4PAMFPo5Y<\/a><\/li>\n<li>Ethereum RLP:<a href=\"https:\/\/github.com\/ethereum\/wiki\/wiki\/%5BEnglish%5D-RLP\" target=\"_blank\" rel=\"nofollow noopener\">https:\/\/github.com\/ethereum\/wiki\/wiki\/%5BEnglish%5D-RLP<\/a><\/li>\n<li>Ethereum Merkle Patricia trees:<a href=\"https:\/\/github.com\/ethereum\/wiki\/wiki\/%5BEnglish%5D-Patricia-Tree\" target=\"_blank\" rel=\"nofollow noopener\">https:\/\/github.com\/ethereum\/wiki\/wiki\/%5BEnglish%5D-Patricia-Tree<\/a><\/li>\n<li>Peter Todd on Merkle sum trees:<a href=\"http:\/\/sourceforge.net\/p\/bitcoin\/mailman\/message\/31709140\/\" target=\"_blank\" rel=\"nofollow noopener\">http:\/\/sourceforge.net\/p\/bitcoin\/mailman\/message\/31709140\/<\/a><\/li>\n<\/ol>\n<p>\u2014\u2013<\/p>\n<p><strong>NOTAS INCLUIDAS PARA CLARIFICAR LA TRADUCCION<\/strong><\/p>\n<p><a href=\"http:\/\/www.santiagomarquezsolis.com\/ethereum-whitepaper-traducido-al-castellano\/#_ftnref1\" target=\"_blank\" rel=\"nofollow noopener\">[1]<\/a>\u00a0Se estar\u00eda refiriendo a la existencia de las propiedades value-blindness y blockchain-blindness que en este caso si estar\u00edan inclu\u00eddas en Ethereum.<\/p>\n<p><a href=\"http:\/\/www.santiagomarquezsolis.com\/ethereum-whitepaper-traducido-al-castellano\/#_ftnref2\" target=\"_blank\" rel=\"nofollow noopener\">[2]<\/a>\u00a0Ethereum Virtual Machine<\/p>\n<p><a href=\"http:\/\/www.santiagomarquezsolis.com\/ethereum-whitepaper-traducido-al-castellano\/#_ftnref3\" target=\"_blank\" rel=\"nofollow noopener\">[3]<\/a>\u00a0Hay quien traduce los tokens en espa\u00f1ol por fichas, pero creo que es m\u00e1s correcto definirlos como \u201ctestigos\u201d con la idea de que act\u00faa como algo simb\u00f3lico y representan un testimonio dentro del sistema Ethereum.<\/p>\n<p><a href=\"http:\/\/www.santiagomarquezsolis.com\/ethereum-whitepaper-traducido-al-castellano\/#_ftnref4\" target=\"_blank\" rel=\"nofollow noopener\">[4]<\/a>\u00a0Preferimos dejar por claridad las siglas inglesas DAO que su equivalente en espa\u00f1ol OAD.<\/p>\n<p><a href=\"http:\/\/www.santiagomarquezsolis.com\/ethereum-whitepaper-traducido-al-castellano\/#_ftnref5\" target=\"_blank\" rel=\"nofollow noopener\">[5]<\/a>\u00a0La Democracia L\u00edquida tambi\u00e9n es lo mismo que Democracia Delegativa Revocable<\/p>\n<p><a href=\"http:\/\/www.santiagomarquezsolis.com\/ethereum-whitepaper-traducido-al-castellano\/#_ftnref6\" target=\"_blank\" rel=\"nofollow noopener\">[6]<\/a>\u00a0Tal vez en espa\u00f1ol ser\u00eda m\u00e1s exacto hablar de roles o capacidades.<\/p>\n<p><a href=\"http:\/\/www.santiagomarquezsolis.com\/ethereum-whitepaper-traducido-al-castellano\/#_ftnref7\" target=\"_blank\" rel=\"nofollow noopener\">[7]<\/a>\u00a0He traducido la palabra inglesa \u201cfutarchy\u201d como \u201cfutarqu\u00eda\u201d, porque no he encontrado un t\u00e9rmino en espa\u00f1ol equivalente, de hecho, dudo que exista. Hace referencia a una forma de gobierno, propuesta por Robin Hanson que utilizan medidas de bienestar y los mercados de predicci\u00f3n nacionales para determinar qu\u00e9 pol\u00edticas tendr\u00e1n el efecto m\u00e1s positivo.<\/p>\n<p><a href=\"http:\/\/www.santiagomarquezsolis.com\/ethereum-whitepaper-traducido-al-castellano\/#_ftnref8\" target=\"_blank\" rel=\"nofollow noopener\">[8]<\/a>\u00a0Este problema es muy conocido y se aplica a las m\u00e1quinas de Turing.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Buenas a todos!!! Pues s\u00ed, sigo vivo, ja, ja, ya sab\u00e9is que actualizo el blog cuando realmente tengo algo importante que contarte, no me gusta llenar este espacio de cosas que no aporten valor. De momento puedo deciros que pronto estar\u00e1 disponible la conversi\u00f3n de la\u00a0Diosa de Cozumel\u00a0y que las adaptaciones a 3D de\u00a03D Colossal [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":140,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2,12,30],"tags":[16,17,37,59],"class_list":["post-139","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","category-cripto","category-ethereum","tag-blockchain","tag-cripto","tag-ethereum","tag-traduccion"],"jetpack_featured_media_url":"https:\/\/santiagomarquezsolis.com\/wp-content\/uploads\/2024\/05\/traduccion-e1717165428318.jpg","_links":{"self":[{"href":"https:\/\/santiagomarquezsolis.com\/index.php\/wp-json\/wp\/v2\/posts\/139","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/santiagomarquezsolis.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/santiagomarquezsolis.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/santiagomarquezsolis.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/santiagomarquezsolis.com\/index.php\/wp-json\/wp\/v2\/comments?post=139"}],"version-history":[{"count":1,"href":"https:\/\/santiagomarquezsolis.com\/index.php\/wp-json\/wp\/v2\/posts\/139\/revisions"}],"predecessor-version":[{"id":141,"href":"https:\/\/santiagomarquezsolis.com\/index.php\/wp-json\/wp\/v2\/posts\/139\/revisions\/141"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/santiagomarquezsolis.com\/index.php\/wp-json\/wp\/v2\/media\/140"}],"wp:attachment":[{"href":"https:\/\/santiagomarquezsolis.com\/index.php\/wp-json\/wp\/v2\/media?parent=139"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/santiagomarquezsolis.com\/index.php\/wp-json\/wp\/v2\/categories?post=139"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/santiagomarquezsolis.com\/index.php\/wp-json\/wp\/v2\/tags?post=139"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}