Tau Chain – Code or Money (traduccion)

Código o pago, ¿Qué acción debe realizarse primero?

Posteado Jul 21, 2015, 7:18 PM por Ohad Asor [ Actualizado el Jul 21, 2015, 8:02 PM ]

Supongamos el caso hipotético de que Lisa sea programadora y Bart, un hombre de negocios.

A Bart le gustaría que Lisa desarrolle un software para su empresa. Debido a que ellos no se conocen, es natural que se formulen la siguiente pregunta: ¿cómo podrían confiar el uno en el otro? A Bart le gustaria pagar cuando el software esté terminado y funcionando correctamente, a Lisa le gustaria recibir por adelantado el pago de su labor, con el fin de evitar el riesgo de trabajar sin recibir remuneración alguna. Sería justo llegar a una especie de acuerdo intermedio que los deje contentos a ambos; por ejemplo, definiendo las metas de trabajo; sin embargo, esto no resolverá totalmente el tema de la confianza, sólo lo minimizará un poco.

¿De qué manera se puede resolver este problema a través de aplicaciones descentralizadas? Gracias al algoritmo de la cadena de bloques se resuelve de alguna manera el problema de la confianza en la mayoría de los casos. Por ejemplo, con el Bitcoin se puede demostrar la propiedad de la divisa mediante una firma criptográfica, que les permite utilizar este dinero. ¿Este método podría ser de ayuda para Bart y Lisa?

La cadena de bloques podría ser de utilidad solo cuando se trata de un bien raíz de vital importancia. Es en menor escala una característica propia de la cadena de bloques y en mayor escala una característica del código fuente. A partir de esta afirmación surge una interrogante mucho más simple: Cuando Bart reciba el código fuente, ¿cómo podrá saber si funciona apropiadamente?

La verificación del software, así como también la realización de pruebas sobre su correcto funcionamiento y el control de calidad son fundamentales para la vida útil del mismo. No están hechos a prueba de personas poco inteligentes: comúnmente nos vemos enfrentados a software con errores de programación; dicha inestabilidad guarda relación con desfases que van en contra de lo que se pudiera esperar de un software, brechas de seguridad y mal funcionamiento del mismo. Programar software de calidad es un proceso lento, costoso y sujeto a conjeturas, que además presenta difíciles tasas de convergencia.

Hace mucho tiempo los expertos en informática tienen conocimiento de que esta situación se debe a la naturaleza lógica de los lenguajes de programación. Sería fantástico si pudiésemos expresar formalmente las especificaciones del software que necesitamos, y si el computador pudiera indicar si un determinado código fuente cumple con dichas exigencias. De hecho, esto podría ser una realidad si seleccionamos un subconjunto de los lenguajes de programación denominado: Totally Functional Programming Languages (Lenguajes de programación totalmente funcionales), cuya sigla en inglés es (TFPL).

Si pensamos en un código TFPL, las afirmaciones probables respecto a este tipo de código son exactamente las afirmaciones correctas; por lo tanto, siempre es posible entregar una prueba, junto con el código fuente, que cumpla con determinadas especificaciones del software. Este no es el caso de los lenguajes que cumplen a cabalidad con las especificaciones de la máquina de Turing, como ya se mencionó en mi publicación anterior.

Entonces, Lisa podría desarrollar el programa en (TFPL) y Bart podría verificar que el mismo cumpla con las especificaciones que solicitó. En muchos casos, Bart tendría que contratar a un programador que escriba aquellas especificaciones formales, pero desde luego, la expresión de las especificaciones es un trabajo mucho más sencillo que el cumplimiento de dichas exigencias.

Ahora que ya hemos resuelto el problema de verificación cabe preguntarse cómo solucionar el problema de la confianza en la forma de pago planteado al principio del texto.

Para resolver el problema del código y su pago, que es similar al dilema de qué fue primero el huevo o la gallina, Tau-Chain bridará una solución a la brevedad.

Tau es un lenguaje (TFPL), es decir le da significado/sentido (TFPL) a los lenguajes existentes (la familia de lenguajes RDF, caracterizados por una gran legibilidad para el humano). El cliente de Tau cumple la función de poner a prueba y verificar un teorema, de manera que puede comprobar afirmaciones respecto a un determinado código de lenguaje Tau. Este último también funciona como un nodo de cadena de bloques; sin embargo, las pruebas pueden ser simplemente pruebas en el sentido matemático hasta sistema de tipos Tau, que abarcan todas las máquinas de Turing finitas; es decir, prácticamente todo tipo de computadores.

Entonces, Bart podría guardar dinero en una dirección multifirma junto con Lisa (que sería el equivalente de un bitcoin en una cuenta bancaria compartida que requiere ambas firmas), y especifica que en Tau la divisa será entregada a Lisa sólo si ella presenta pruebas de que su código cumple con todas las especificaciones solicitadas. Dichas pruebas serán verificadas por la red completa, por así decirlo, o por personas que minan bitcoins, la forma específica depende nuevamente de las reglas impuestas por el usuario y de la manera en que se construye esa divisa específica sobre Tau. Finalmente Lisa será recompensada de manera segura a través del pago que ella merece por su trabajo.

Cabe señalar que Bart puede tener la seguridad de que Lisa no ha ocultado alguna sorpresa en el código, ya que puede verificar de forma automática que el código no realiza acciones incorrectas como acceder a información confidencial. Por lo tanto, estamos en presencia de una nueva era en el mundo de la informática, dónde es posible confiar en el software y las personas pueden confiar las unas en las otras cuando se realiza una amplia gama de transacciones.

¿Difícil de creer?


Ya terminamos un sistema de verificación muy poderoso, que fue sometido a una gran cantidad de pruebas. Aún no está en condiciones óptimas, pero seguimos trabajando para lograrlo. Requiere un mayor desarrollo para superar un sistema de razonamiento RDF y convertirse en un nodo completo Tau. Es necesario terminar los sistema de tipos con restricciones, completar la integración de la cadena de Bloques y el sistema DHT, construir el bloque genesis, una vez realizado todo lo anterior, ¡voilá!

Créditos

Autor: Ohad Asor

Traducción: Virgilio Leonardo Ruilova, colaborador anónimo.

Licencia de la traducción: Creative Commons – Atribución – Compartir Igual

Licencia del original: Copyright, por Ohad Asor

Anuncios

Democracia descentralizada y la importancia de sus primeros usuarios

Publicado el 31 de Agosto de 2015, 11:22 PM por Ohad Asor   [Actualizado el 31 de Agosto de 2015, 11:23 PM ]

Hemos hablado recientemente acerca de las propiedades lógicas y técnicas de Tau y ahora es el momento de darse el tiempo de contemplar en forma global esta tecnología. Planteamos que el lenguaje de programación de Tau consiste básicamente en un conjunto de reglas y lógica. Encontramos estos dos elementos en muchos otros aspectos de la vida; un ejemplo relativamente simple: la estructura de lógica pura de las soluciones para los problemas de nuestro entorno podría ser empleada de manera automática para lidiar con los problemas no resueltos, e incluso es factible de ser aplicada dentro de un campo completamente ajeno como las estructuras químicas isomorficas para algunos programas computacionales

Cabe destacar que el tema principal que nos convoca es la democracia descentralizada.

Es posible formalizar leyes a través de la tecnología Tau así como también analizar las posibles consecuencias y verificar su consistencia de manera descentralizada. Dentro de la tecnología Tau no es posible interactuar directamente con las leyes de la realidad; sin embargo, Tau funciona de acuerdo a sus propias reglas. De hecho, la red se autodefine y se autocorrige. El software cliente es un compilador que descarga el código fuente de la cadena de bloques y ejecuta el código. El código podría variar de un bloque a otro, y lo ideal es que dicho código sufra modificaciones y mejoras con el paso del tiempo. Básicamente, las partes más relevantes del código dentro del software cliente son las condiciones para aceptar el siguiente bloque.

Las reglas, protocolo y comportamiento específico de la red son evidentemente factores de gran importancia dentro de la evolución de la misma. Por el contrario, no es nuestro afán dedicarnos a la especificación de las características anteriores por sobre el Genesis, sino más bien determinar de qué manera las reglas pueden cambiar, sin tener en cuenta el verdadero origen de esas reglas.

La lógica e infraestructura de Tau hacen posible la separación de los contextos. Definimos contexto como un conjunto de reglas que se aplican sólo a los participantes que desean por voluntad propia adherirse al mismo. La terminología proviene del mundo RDF, Marco de Descripción de Recursos (del inglés Resource Description Framework): el lenguaje Tau está formado por conjuntos de cuatro elementos (sujeto- verbo-objeto-contexto); por lo tanto, el hecho o regla descrito en el (sujeto-verbo-objeto) se aplica solamente a un contexto determinado. Sin embargo, es posible reutilizar el código de manera transversal dentro de los contextos. Esto se explica mediante el siguiente código en RDF:

context1:subject context2:predicate

Los contextos pueden ser vinculados en la cadena raíz (del inglés root chain) así como las cadenas laterales (del inglés side chain) pueden ser vinculadas en la cadena del Bitcoin. Gracias a este proceso es posible la implementación de un software descentralizado sin necesidad de emplear personas dedicadas a la minería de Bitcoin, debido a que todas las funciones Hash criptográficas otorgadas a cualquier cadena lateral también aseguran la cadena raíz.

En cada contexto es factible encontrar una serie de reglas personalizadas. Por ende, la cadena raíz no debiera intervenir en lo que sucede dentro de los contextos personalizados; sin embargo, define exclusivamente las reglas que son fundamentales para la existencia de la cadena raíz. En Tau es posible llevar a cabo un bootstrap obedeciendo reglas arbitrarias sencillas, incluso una lista de los primeros colaboradores o una inserción centralizada del código ejecutada por nosotros mismos.

Cualquiera sean dichas reglas, estas son temporales; la primera tarea es definir de que manera serían modificadas y en que momento llevar a cabo estos cambios. Posteriormente, seguimos el proceso de reglamentación que formalizamos en una primera fase y definimos en conjunto estas reglas. Los desarrolladores de Tau, nos sentimos muy comprometidos en la participación activa de todos los procesos posteriores al genesis, pero no acaparamos en forma alguna el poder. Todos los usuarios de Tau comienzan a trabajar en génesis en igualdad de condiciones.

Pusimos sobre la mesa tecnología para la democracia descentralizada, que puede ir escalando posiciones dentro de la democracia, sobre un pequeño grupo en la forma de contextos Tau, y quién sabe, incluso la democracia descentralizada podría derivar en leyes estatales. No vemos barreras técnicas para lo anterior; no obstante, carecemos de un conjunto de reglas definitivo e irrefutable.

La tarea es ardua y las implicaciones filosóficas son abrumadoras. Sin embargo, existe un límite para las soluciones que nos entrega la tecnología; por ejemplo, ésta nos puede brindar una plataforma para la democracia descentralizada, pero es imposible que configure nuestras reglas. No es necesario poner tanto énfasis en la importancia de realizar un procedimiento de bootstrapping sobre una democracia descentralizada y en la formación de su “constitución”; por lo tanto, solamente daré a conocer que gran parte de la comunidad de lectores comparten conmigo la sensación de que probablemente podemos realizar pequeños cambios que sin lugar a dudas traerían mejoras notables en comparación con nuestra situación actual.

Desde luego no es conveniente que como desarrolladores de un sistema democrático nos hagamos cargo de la configuración de sus reglas.

Evidentemente la formalización de una democracia descentralizada para nuestra vida cotidiana no está dentro de las obligaciones de los primeros usuarios, sino que es parte de un proceso a mayor escala. Los primeros usuarios tendrán que definir cómo cambiar las reglas de la cadena raíz, ni siquiera preocuparse de lidiar con detalles técnicos tales como el tamaño máximo del bloque; sin embargo, cabe preguntarse qué ocurre si deseamos cambiar el tamaño del bloque y concretamente cuáles serían las condiciones para realizar un cambio de regla en la cadena raíz. Es una interesante prueba de fuego en sí misma. Casi se puede imaginar la forma en que evolucionarán las reglas de las reglas cambiantes a partir de nuestras nuevas habilidades lógicas de descentralización. Esperamos de verdad que la evolución de Tau no sea solamente una colaboración económica, de código y conocimiento, sino más bien un aporte ético

Texto original de Ohad Asor

Este trabajo ha sido liberado para los Comunes, bajo licencia copyright de tipo Creative Commons- Atribución –  No Comercial, puede ser usado sin fines de lucro bajo las libertades que da la misma.

Corrección de estilo por Marcela Reyes