Skip to content
This repository has been archived by the owner on May 26, 2022. It is now read-only.

[Spanish] White Paper.md

Joseph Cook edited this page May 24, 2022 · 16 revisions

馃洃 This wiki has now been deprecated. Please visit ethereum.org for up-to-date information on Ethereum. 馃洃

Contents

Un contrato inteligente de pr贸xima generaci贸n y una plataforma de aplicaci贸n descentralizada

El desarrollo de Bitcoin de Satoshi Nakamoto en el a帽o 2008[1a][1b]鈥2009[1c][1d] ha sido aclamado como una evoluci贸n radical en el dinero y la moneda, siendo el primer ejemplo de un activo digital que simult谩neamente no tiene respaldo o valor intr铆nseco[2] ni un emisor o controlador centralizado. Sin embargo, otra parte del experimento Bitcoin, discutiblemente m谩s importante, es la subyacente tecnolog铆a blockchain como una herramienta de consenso distribuido. La atenci贸n est谩 r谩pidamente comenzando a trasladarse a este otro aspecto de Bitcoin. Las aplicaciones alternativas com煤nmente citadas de la tecnolog铆a blockchain incluyen el uso de activos digitales en blockchain para representar monedas personalizadas e instrumentos financieros(colored coins),[3] la posesi贸n de un dispositivo f铆sico subyacente (propiedad inteligente),[4] activos no fungibles tales como nombres de dominio (Namecoin)[5] , as铆 como aplicaciones m谩s complejas que implican tener activos digitales controlados directamente por un c贸digo que implementa reglas arbitrarias conocidas como contratos inteligentes[6] o incluso organizaciones aut贸nomas descentralizadas basadas en blockchain (DAOs por sus siglas en ingl茅s)[7]

Lo que Ethereum intenta es proveer un blockchain con un lenguaje de programaci贸n integrado Turing completo, completamente desarrollado que puede ser utilizado para crear "contratos" que pueden ser utilizados para codificar funciones de transici贸n de estado arbitrarias, permitiendo a los usuarios crear cualquiera de los sistemas arriba descritos, as铆 como muchos otros que a煤n no hemos imaginados, simplemente escribiendo la l贸gica en pocas l铆neas de c贸digo.

Tabla de contenidos

Introducci贸n a Bitcoin y conceptos existentes

Historia

El concepto de moneda digital descentralizada, as铆 como aplicaciones alternativas como registros propietarios, han estado alrededor por d茅cadas. Los protocolos an贸nimos de dinero electr贸nico de los a帽os ochenta y noventa se basaron principalmente en un primitivo criptogr谩fico conocido como Chaumian Blinding.[8]

Chaumian Blinding proporcion贸 estas nuevas monedas con altos grados de privacidad, pero sus protocolos subyacentes en gran medida no lograron ganar tracci贸n debido a su dependencia de un intermediario centralizado. En 1988, el b-money de Wei Dai[10] se convirti贸 en la primer propuesta que introduce la idea de crear dinero a trav茅s de la soluci贸n de rompecabezas computacionales as铆 como del consenso descentralizado, pero la propuesta era escasa en los detalles sobre c贸mo podr铆a ser implementado el consenso descentralizado. En 2005, Hal Finney introduce el concepto de prueba de trabajo[10], un sistema que usa ideas de b-money junto con rompecabezas de dificultad computacional de Adam Back para crear el concepto de criptomoneda, pero una vez m谩s no estuvo a la altura del ideal pues depend铆a de c贸mputo de confianza como backend. En 2009, una moneda descentralizada fue por primera vez implementada en la pr谩ctica por Satoshi Nakamoto,[1c][1d]combinando las bases establecidas para el manejo de posesi贸n mediante de una llave criptogr谩fica p煤blica con un algoritmo de consenso para mantener el registro de quien posee monedas, conocido como "prueba de trabajo".

Bitcoin como un sistema de transici贸n de estado

statetransition.png

Desde una punto de vista t茅cnico, el libro mayor de una criptomoneda como el Bitcoin puede ser considerado como un sistema de transici贸n de estado, donde hay un "estado" que consiste en el estado de propiedad de todos los bitcoins existentes y una "funci贸n de transici贸n de estado" que toma un estado y una transacci贸n y produce como salida un nuevo estado que es el resultado.

En un sistema bancario est谩ndar, por ejemplo, el estado es un balance, una transacci贸n es una solicitud para mover $X de A a B, y la funci贸n de transici贸n de estado reduce el valor de la cuenta de A en $X y aumenta el valor de B cuenta por $X. Si la cuenta de A tiene menos de $ X en primer lugar, la funci贸n de transici贸n de estado devuelve un error. Por lo tanto, se puede definir formalmente:

APLICAR(S,TX) -> S' || ERROR

En el sistema bancario definido arriba:

APLICAR({ Alice: $50, Bob: $50 }, "env铆a $20 de Alice a Bob") = { Alice: $30, Bob: $70 }

Pero:

APLICAR({ Alicia: $50, Bob: $50}, "env铆a %70 de Alice a Bob") = ERROR

El "estado" en Bitcoin es la colecci贸n de todas las monedas (t茅cnicamente, resultados de transaci贸n no gastados" o UTXO) que han sido minados y a煤n no gastados, con cada UTXO teniendo una denominaci贸n y un due帽o (definido por una direcci贸n de 20 bytes que es esencialmente una llave criptogr谩fica p煤blica[Note 1]).

Una transacci贸n contiene una o m谩s entradas, cada una haciendo referencia a un UTXO existente y a una firma criptogr谩fica producida por la llave privada asociada a la direcci贸n del due帽o, y una o m谩s salidas, cada una conteniendo un nuevo UTXO para para agregar al estado.

La funci贸n de transici贸n APLICAR(S,TX) -> S' puede ser definida aproximadamente de la siguiente manera:

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

La primera mitad de el primer paso previene que el emisor de la transacci贸n env铆e monedas que no existen, la segunda mitad del primer paso previene que el emisor gaste monedas de otras personas, el segundo paso impone la conservaci贸n del valor. Para utilizar esto para pago, el protocolo es el siguiente. Supongamos que Alice quiere enviar 11.7 BTC a Bob. En primer lugar, Alice buscar谩 un conjunto de UTXO disponible que posea y que totalizar谩 al menos 11.7 BTC. Siendo realistas, Alice no podr谩 obtener exactamente 11.7 BTC; digamos que lo menos que puede obtener es 6 + 4 + 2 = 12. Luego crea una transacci贸n con esas tres entradas y dos salidas. La primera salida ser谩 11.7 BTC con la direcci贸n de BOB como su propietario, y la segunda salida ser谩 el restante 0.3 BTC "cambio". Si Alice no reclama este cambio envi谩ndolo a una direcci贸n de su propiedad, el minero podr谩 reclamarlo.

Miner铆a

block_picture.jpg

Si tenemos acceso a un servicio centralizado confiable, este sistema ser铆a trivial de implementar; podr铆a ser codificado exactamente como se describi贸, utilizando un disco duro de un servidor centralizado para mantener el registro del estado. Sin embargo, con Bitcoin estamos tratando de construir un sistema de moneda descentralizado, por ello necesitamos combinar el sistema de transici贸n de estado con un sistema de consenso para garantizar que todos est茅n de acuerdo en el orden de las transacciones. El proceso de consenso descentralizado de Bitcoin requiere los nodos en la red intenten continuamente producir paquetes de transacciones llamados "bloques". La red est谩 destinada a crear un bloque aproximadamente cada diez minutos, cada bloque conteniendo una estampa de tiempo, un nonce, una referencia a (es decir, hash) del bloque anterior y una lista de todas las transacciones que han tenido lugar desde el anterior bloque. Con el tiempo esto crea una "Cadena de bloques" (Blockchain) persistente y en constante crecimiento que se actualiza continuamente para representar el estado m谩s reciente del libro mayor de Bitcoin.

Los algoritmos para comprobar si un bloque es v谩lido, expresado en este paradigma como sigue:

  1. Verifica si el bloque previo referenciado por el bloque existe y es v谩lido.
  2. Verifica que la estampa de tiempo del bloque es mayor que la del bloque previo y menor que 2 horas en el futuro.
  3. Verifica que la prueba de trabajo en el bloque sea v谩lida.
  4. Sea S[0] el estado al final del bloque previo.
  5. Suponiendo TX como la lista de transacciones del bloque con n transacciones. Para todo i en 0...n-1, implica que S[i+1] = APLICA(S[i+1], TX[i]) Si alguna aplicaci贸n devuelve un error, sale y devuelve falso.
  6. Devuelve true, y registra S[n] como el estado al final de este bloque

Esencialmente, cada transacci贸n en el bloque deber谩 proveer un estado de transici贸n v谩lido del que era es estado can贸nico antes de que la transacci贸n fuera ejecutada a alg煤n nuevo estado. Tenga en cuenta que el estado no est谩 codificado en el bloque de ninguna manera; es puramente una abstracci贸n que debe ser recordada por el nodo de validaci贸n y s贸lo puede (de una forma segura) computarse para cualquier bloque comenzando desde el estado de g茅nesis y aplicando secuencialmente cada transacci贸n en el bloque. Adem谩s, tenga en cuenta que el orden en el cual el minero incluye las transacciones en el bloque importa; si hay dos transacciones A y B en un bloque de modo que B gasta un UTXO creado por A, entonces el bloque ser谩 v谩lido si A entra antes que B, pero no de otra manera.

La condici贸n de validez presente en la lista anterior que no se encuentra en otros sistemas es el requisito de "prueba de trabajo". La condici贸n precisa es que el hash doble SHA254[13] de cada bloque, tratado como un n煤mero de 256 bits, debe ser menor que un objetivo din谩micamente ajustado, que a partir del momento de escribir esto es aproximadamente 2187.

El prop贸sito de esto es hacer la creaci贸n de los bloques computacionalmente "dif铆cil", evitando as铆 que los ataques Sybil rehagan toda la cadena de bloques, a su favor. Debido a que SHA256 est谩 dise帽ado para ser una funci贸n pseudoaleatoria completamente impredecible, el 煤nico camino para crear un bloque v谩lido es simplemente prueba y error, repetidamente incrementando el nonce y y viendo si el hash nuevo coincide.

Al momento de escribir esto, para un objetivo de ~2187, la red debe realizar un promedio de ~ 269 intentos antes de encontrar un bloque v谩lido; en general, el objetivo es re-calibrado por la red cada 2016 bloques, de modo que en promedio, un nodo en la red produce un nuevo bloque cada diez minutos. Con la finalidad de compensar a los mineros por este trabajo computacional, el minero de cada bloque tiene derecho a incluir una transacci贸n que se 12.5 BTC de la nada. Adem谩s, si cualquier transacci贸n tiene una denominaci贸n total m谩s all谩 en sus entradas que en sus productos, la diferencia tambi茅n le corresponde al minero como una "tarifa de transacci贸n". Por cierto, este es tambi茅n el 煤nico mecanismo por el cual se emiten BTC; el estado de g茅nesis no conten铆a ninguna moneda en absoluto.

En favor de un mejor entendimiento del prop贸sito de miner铆a, examinemos qu茅 sucede en el evento de un atacante malicioso. Debido a que la subyacente criptograf铆a del Bitcoin es segura, el objetivo del atacante ser谩 la 煤nica parte del sistema Bitcoin que no est谩 protegida criptogr谩ficamente de forma directa: el orden de las transacciones. La estrategia del atacante es simple:

  1. Enviar 100 BTC a un comerciante a cambio de un producto (preferiblemente un bien digital de entrega r谩pida)
  2. Espera a que el producto sea entregado
  3. Produce otra transacci贸n enviando la misma cantidad de 100 BTC a si mismo.
  4. Trata de convencer a la red que la transacci贸n a 茅l mismo ocurri贸 primero.

Una vez que el paso (1) sucede, despu茅s de algunos minutos alg煤n minero incluir谩 la transacci贸n en el bloque, digamos el bloque n煤mero 270,000. Despu茅s de una hora, 5 o m谩s bloques han sido a帽adidos a la cadena despu茅s de ese bloque, con cada uno de esos bloque indirectamente apuntando a la transacci贸n, as铆 "confirmando" la transacci贸n.

En este punto el atacante crea otra transacci贸n enviando 100 BTC a s铆 mismo. Si el atacante simplemente libera al aire la transacci贸n, esta no ser铆a procesada; los minero tratar铆an de correr APLICAR(S,TX) y se percatar铆an que TX utiliza un UTXO que ya no es parte del estado. En vez de esto, el atacante crea un "fork" de la cadena del bloques Bitcoin, comenzando por minar otra versi贸n del bloque 270,000 apuntando al mismo bloque 269,999 como padre pero con la nueva transacci贸n en lugar de la anterior. Puesto que la informaci贸n del bloque es diferente esto requiere rehacer la prueba de trabajo del bloque de inter茅s.

Adem谩s, la nueva versi贸n del bloque 270,000 del atacante tiene un hash diferente, as铆 que los bloques originales 270,001 al 270,005 no 'apuntan' a este; As铆, la cadena original y la nueva cadena del atacante est谩n completamente separadas. La regla es que el bloque con la cadena m谩s larga es el verdadero, y as铆 los mineros leg铆timos trabajar谩n en la cadena 270,005 mientras que el atacante s贸lo est谩 trabajando en la cadena 270,000. Para que el atacante pueda hacer su cadena la m谩s larga, necesitar铆a tener mayor poder computacional que el resto de la red combinada para poder alcanzarla (por lo tanto, "51% ataque"). Los bloques bitcoin dependen del hash de todos los bloques anteriores.

Un atacante con inmenso poder computacional puede rehacer la prueba de trabajo (PoW) por una considerada suma de bloques y eventualmente ganar muchos bitcoins, pero como es descrito en la publicaci贸n de Satoshi,[1a] la recompensa de minar un bloque v谩lido es mucho m谩s mayor a la de quebrantar la red. Pero a la luz de la caida en recompensas de miner铆a, esto 煤ltimo puede no ser verdad.

脕rboles Merkle

SPV1 in bitcoin

01: basta con presentar solo un peque帽o n煤mero de nodos en un 谩rbol de Merkle para dar una prueba de la validez de la rama.

SPV2 in bitcoin

02: cualquier intento de cambiar cualquier parte del arbol Merkle eventualmente llevar谩 a inconsistencias en alg煤n lugar de la cadena.

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

El protocolo 谩rbol Merkle es discutiblemente esencial para la sostenibilidad en el largo plazo. Un "nodo completo" en la red Bitcoin, uno que guarda y procesa la totalidad de cada bloque, ocupa cerca de 15GB de espacio en la red Bitcoin a partir de abril de 2014, y est谩 creciendo m谩s de un gigabyte por mes. Actualmente, esto es viable para algunas computadoras de escritorio y no para tel茅fonos, y m谩s adelante en el futuro solo las empresas y los aficionados podr谩n participar. Un protocolo conocido como "verificaci贸n de pago simplificada" (SPV) permite que exista otra clase de nodos, llamados "nodos ligeros", que descargan los encabezados de los bloques, verifican la prueba de trabajo en los encabezados del bloque y luego solo descargan las "ramas". "Asociado con transacciones que son relevantes para ellos- Esto permite que los nodos ligeros determinen con una fuerte garant铆a de seguridad cu谩l es el estado de cualquier transacci贸n de Bitcoin, y su saldo actual, mientras se descarga solo una porci贸n muy peque帽a de la cadena de bloques completa.

Aplicaciones alternativas de la cadena de bloques

La idea de tomar la subyacente idea de la cadena de bloques y aplicarla a otros conceptos tambi茅n tiene una larga historia. En 2005, Nick Szabo presenta el concepto de t铆tulos de propiedad seguros con autorizaci贸n del propietario,[14] un documento que describe como "nuevos avances en la tecnolog铆a de bases de datos replicadas" permitir谩n un sistema basado en cadenas de bloques para almacenar un registro de qui茅n posee qu茅 tierra, creando un marco elaborado que incluye conceptos como homestanding, posesi贸n adversa y el impuesto Gregoriano a la tierra. Sin embargo, lamentablemente no exist铆a un sistema de base de datos replicado eficaz disponible en ese momento, por lo que el protocolo nunca se implement贸 en la pr谩ctica. Sin embargo, despu茅s de 2009, una vez que se desarroll贸 el consenso descentralizado de Bitcoin, r谩pidamente comenzaron a surgir varias aplicaciones alternativas.

Clone this wiki locally