NEAR.ai → NEAR Protocol

23 de agosto de 2018 | ILLIA POLOSUKHIN

Hace poco más de un año, Alexander Skidanov y yo pusimos en marcha NEAR.ai. Creíamos firmemente que la síntesis de programas (program synthesis), campo que estudia la programación automatizada partiendo de una especificación humana, iba a transformar el desarrollo de software y el mundo en general.

La síntesis de programas se propone generar programas informáticos a partir de especificaciones de usuario, para así poner a disposición de todo el mundo capacidades que a día de hoy resultan muy escasas.

El año pasado, en ICLR 2017, nos encontramos con diversos artículos de varios laboratorios de investigación y nos entusiasmamos ante la oportunidad de trasladar dicha tecnología al mercado. Tanto Alex como yo habíamos tratado de explorar la síntesis de programas en nuestra época universitaria, pero el aprendizaje automatizado (machine learning) se hallaba en una fase tan inicial por entonces, que no resultaba muy factible realizar cualquier tipo de progreso.

Tras la conferencia, nos imaginamos cómo sería la compañía y nos dimos cuenta que la primera prioridad sería establecer un benchmark para la comunidad. Así como el benchmark ImageNet promovió el campo de la visión por ordenador a pasos agigantados al proporcionar a los practicantes una clara métrica de comparación, nosotros creíamos que un dataset complejo supondría un desafío para la comunidad, así como una guía para la investigación.

Pusimos en marcha NEAR.ai bajo la hipótesis que podríamos expandir los límites de la investigación en el campo de la síntesis de programas y, al mismo tiempo, proporcionar un producto transformador impulsado por esta tecnología.

Tanto Alex como yo hemos participado en competiciones de programación (Alex ganó la medalla de oro en ACM ICPC 2008), y ambos pensábamos que los problemas diseñados para los humanos que participan en este tipo de desafíos serían un buen punto de partida para los ordenadores embarcados en la síntesis de programas.

Las competiciones de programación generan muy buenos datos para aprendizaje automatizado (machine learning). Cada competición de programación generalmente conlleva la resolución de 5–10 problemas de creciente dificultad, planteados en lenguaje natural. Los problemas son resueltos por los participantes en varios lenguajes de programación, produciendo así el corpus paralelo de descripción -los pares de código.

Durante un año, reunimos más de 30 mil problemas y 10 millones de soluciones. Muchos de los problemas eran difíciles de solucionar incluso para un ingeniero de software medio, por lo que nos centramos en aquellos que eran simples (por ejemplo, A y B en CodeForces o 250 en TopCoder). Incluso en dicho caso, las descripciones de tareas resultaban complejas: la variedad de conceptos y el lenguaje empleado en las descripciones excedían la capacidad de captura del modelo. Asimismo, algunos problemas requerían pasos de razonamiento lógico y conocimientos matemáticos externos. Con la idea de simplificar la primera tarea nos apoyamos en una colaboración abierta distribuida (crowdsourcing) con la comunidad CodeForces, para así transformar las descripciones de los problemas en una “descripción de solución”.

Resultados publicados en ICML 2018 en el dataset NAPS

Parte del dataset que reunimos lo publicamos en nuestro artículo para ICML 2018 titulado “NAPS: Natural Program Synthesis dataset”. Sin embargo, a pesar de todo este trabajo, y después de ejecutar con este conjunto de datos modelos de última generación (los cuales combinaban “deep learning” y técnicas de búsqueda regulares), descubrimos que los resultados distaban mucho de poder ser utilizados en la práctica (en torno a un 12% en nuestro mejor modelo).

Junto con el trabajo técnico, reunimos feedback de potenciales usuarios para asegurarnos de que existiera una demanda real en el mercado para nuestra solución. Construimos prototipos (sin ningún ML) y los pusimos a prueba utilizando el modelo Wizard-of-OZ (o human-in-the-loop).

Después de diversas iteraciones, nos dimos cuentas de que el ML, específicamente la comprensión del lenguaje natural, todavía no estaba a punto.

Entretanto, unas pocas ideas nos condujeron a nuestra transición:

• En consideración a nuestro trabajo en síntesis de programas, nuestros mentores sugirieron que exploráramos el campo de la generación de smart contracts para Ethereum. A día de hoy, resulta complicado para un ingeniero medio programar contratos probables, un problema que puede ser abordado de forma efectiva por la síntesis de programas.
• Cuanto más hablábamos con gente que deseaba desarrollar aplicaciones, mayor entusiasmo percibíamos respecto a la creación de apps utilizando el blockchain, para así proporcionar incentivos monetarios y mejorar la privacidad y seguridad.

El blockchain conecta diversos dispositivos en una nube única que proporciona a los desarrolladores una base de datos de rápido acceso, computación y facilidad para la transacción de dinero.

Así que nos sentamos con nuestros amigos David “Pieguy” Stolp y Evgeny Kuzyakov, que habían estado experimentando con el blockchain durante el año anterior, para así aprender más sobre el sector. A medida que nos adentramos en la “madriguera”, nos dimos cuenta tanto de las oportunidades como de las limitaciones que presentaban los actuales sistemas blockchain.

En el caso de los desarrolladores, el blockchain proporciona una infraestructura que, en la actualidad, requiere meses de configuración: redes resilientes frente a particiones, una base de datos y computación siempre disponibles, facilidad de cumplimiento regulatorio en materia de GDPR, y una menor necesidad de compliance regulatorio local. Además, los emprendedores pueden idear modelos de negocio completamente nuevos para empresas erigidas sobre la blockchain.

En el caso de los usuarios, el blockchain garantiza la privacidad y seguridad de los datos. Los smart contracts proporcionan garantías y pueden ser estudiados (probablemente no por parte del usuario, pero cualquier noticia sobre un contrato malicioso correrá como la pólvora, mientras que las filtraciones de datos que se producen en cotos privados pueden ser encubiertas).

Por otro lado, existen motivos por los que, a día de hoy, nuevas aplicaciones no están siendo desarrolladas en la blockchain. Ethereum, la plataforma para apps descentralizadas más popular en la actualidad, procesa 14 transacciones por segundo a nivel mundial. Repito, 14 llamadas de API por segundo a nivel mundial, la mayor parte de las cuales son de exchanges y trading especulativo, lo que hace que resulte más difícil utilizarla. En consecuencia, cada transacción tarda entre minutos y horas en llegar al ledger (libro mayor contable).

Existen nuevos protocolos que presumen de solventar el problema de rendimiento del blockchain:

• EOS — ha sido lanzado recientemente y tuvo una de las ICOs más grandes, pero al final emplea a 21 personas para firmar los bloques -lo que significa que esas 21 personas deciden la composición del ledger. Todos se conocen entre sí y comparten un enorme incentivo monetario a no penalizar (slash) por mal comportamiento, incluso en el caso de haber aprobado “double spends” (dobles gastos) o si deciden reescribir el historial.
• IOTA — buena idea desde una perspectiva general: no hay bloques y cada dispositivo IOT puede postear transacciones que serán confirmadas por otros que, a su vez, también posteen transacciones. El problema radica en los detalles: cada nodo debe realizar 5 minutos de proof of work para postear las transacciones (de lo contrario “spamearían”), lo que significa que la finalidad se alcanza en >5 minutos. Asimismo, cada dispositivo IOT debe mantener una gran parte de la DAG que ha sido construida o será fácilmente engañado para que apruebe “dobles gastos”, lo que impide que el protocolo se ejecute en dispositivos IOT reales. Para empeorar las cosas, existe un Coordinador, un sistema de control mantenido de forma central, para así evitar ataques de tipo long-range (de largo alcance).

Existen otros protocolos, muchos de los cuales todavía están desarrollando su tecnología, pero todos y cada uno de ellos carece de un elemento conceptual. Todas las plataformas que han tenido éxito comenzaron acercando a los desarrolladores a los usuarios, en lugar de simplemente construir mejores herramientas para desarrolladores.

Y esto es lo que daría pie a NEAR protocol:

• Permitir a los desarrolladores crear dApps móviles nativas del blockchain y ejecutarlas allí donde se encuentran los usuarios (teléfonos móviles), proporcionando a los primeros una rampa de acceso clave a las dApps.
• Mediante el sharding por estado (sharding by state), permitir a la blockchain escalar de forma lineal con el número de nodos en la red (nos fijamos como objetivo ~100k tps @ 1 millón de nodos móviles).
• Permitir a los emprendedores del blockchain iterar y presentar de forma rápida modelos de negocio exitosos, al disponer tanto de una blockchain escalable como de un acceso fácil a los usuarios, a través de la primera blockchain nativa para móviles.

En otras palabras: NEAR es una blockchain proof-of-stake completamente “shardeada” (fully sharded), que ha sido específicamente diseñada para que los teléfonos móviles puedan participar de forma plena desde el primer día.

Para lograrlo, estamos diseñando cada componente del protocolo, desde la interconexión, consenso y sharding de estado y ejecución, al funcionamiento del cliente de usuario. Puedes leer nuestro primer artículo expositivo y mantenerte conectado para más información: a continuación, publicaremos los artículos técnicos de sharding y consenso.

Hemos reunido a un dream team de desarrolladores: 3 medallistas de oro del ICPC (Mikhail fue campeón mundial 2 veces), 3 de los primeros MemSQL (que crearon sharding para la base de datos distribuida) y 4 Xooglers (construyeron sistemas distribuidos a escala).

Durante las próximas semanas, compartiremos detalles técnicos y nuestras ideas sobre el espacio blockchain y las aplicaciones que creemos que nuestro protocolo hará eclosionar.

Para seguir nuestros progresos puedes utilizar:

• Twitter — https://twitter.com/nearprotocol,
• Medium — https://medium.com/nearprotocol,
• Telegram — http://t.me/cryptonear,

Por último,

Darle las gracias a Alexander Skidanov, Maksym Zavershynskyi, Erik Trautman, Aliaksandr Hudzilin y Bowen Wang por ayudarme a elaborar este post.