En medio de las noticias de su reciente pelea con la Comisión de Valores y Bolsa de los Estados Unidos (SEC, por sus siglas en inglés), relativamente pocas personas han oído hablar de la competencia Open Network de Telegram que tuvo lugar hace algunas semanas. Fue un hito que transformó la una vez minúscula comunidad de desarrolladores de TON en Fift (el lenguaje de programación de propósito general de TON), que difiere mucho de los lenguajes comunes debido a su enfoque de bajo nivel.
El concurso atrajo a nuevos desarrolladores, construyó una comunidad alrededor de la nueva plataforma y resolvió los problemas existentes relacionados con la falta de documentación sobre Contratos Inteligentes, proporcionando ejemplos de ellos y cómo se implementan en TON. Mi equipo, Button Wallet, y yo también participamos, y hemos resumido todo lo que pasó durante y después del concurso de TON.
Falta de documentación
FunC - El otro lenguaje de TON para escribir Contratos Inteligentes es FunC, un lenguaje de alto nivel similar a C con funciones y variables que es mucho más fácil de leer y escribir que el Fift de propósito general. Una comparación similar sería C# y CIL. Sin embargo, antes del concurso, apenas había documentación de FunC. Esto planteó un problema, ya que la mayoría de las tareas del concurso de TON exigían que los concursantes redactaran un Contrato Inteligente.
Debido a la falta de documentación para escribir para TON usando FunC, los participantes del concurso necesitaban analizar y aprender de los ejemplos existentes, que habían sido subidos a un pequeño repositorio de GitHub y al sitio web de prueba de TON junto con algunos detalles teóricos. Aunque esto no fue una tarea difícil en general, comprender las necesidades básicas de un idioma basado sólo en ejemplos puede ser todo un reto. Sin embargo, la mayoría de los concursantes pudieron empezar a escribir libremente en FunC después de los primeros días.
Fundamentos - Cuando escribimos un Contrato Inteligente usando FunC, necesitábamos entender cómo desplegar y compilar el Contrato Inteligente, así como cómo llamar a las funciones usando argumentos. La completa falta de información detallada sobre este aspecto fundamental de la lengua -además de no haber ningún ejemplo que muestre los pasos completos- era casi ridícula por su ironía. La breve guía de TON fue extremadamente útil para aquellos que participaron en el concurso, pero fue sólo una introducción a la redacción de Contratos Inteligentes en TON que convenientemente omitió ejemplos o información detallada sobre la implementación y ejecución de llamadas de función en contratos inteligentes. Eventualmente, todos se dieron cuenta de cómo hacer todo esto, pero tomó mucho tiempo y esfuerzo.
Tareas del concurso
De las cinco tareas totales que quiero destacar, dos eran: el canal de pago asíncrono y el canal síncrono. Pero primero, ¿qué es un canal de pago?
Un canal de pago es una forma de enviar transacciones entre dos partes fuera de la cadena (es decir, fuera de la Blockchain) para que sea más rápido, menos costoso y más personalizado. Los usuarios tienen sus propias cuentas en la Blockchain y pueden enviar transacciones entre ellos utilizando sus sumas depositadas. Para ello, un Contrato Inteligente especial almacena los fondos depositados de las dos partes mientras el canal de pago está abierto. Los retiros requieren un Contrato Inteligente que contenga ciertos datos, los cuales serán discutidos a continuación.
Las Partes A y B envían monedas al contrato inteligente, realizando depósitos para abrir un canal de pago entre ellas.
Para abrir el canal de pago, los fondos deben ser depositados en el Contrato Inteligente por ambas partes.
La Parte A envía una transacción a la Parte B, cambiando el estado del canal de pago de (a, b) a uno nuevo.
Si el canal de pago está abierto, las transacciones se pueden enviar entre partes con una velocidad de más de 100.000 transacciones por segundo. Es importante entender que todo esto sucede fuera de la cadena y que, en algún momento, las partes tendrán que llegar a un acuerdo y retirar sus fondos del Contrato Inteligente.
Una transacción fuera de la cadena de A a B a través de su canal de pago sincrónico.
Es de suponer que las partes podrían intentar retirar injustamente todos los fondos del fondo común. Por ello, cada parte debe demostrar que la suma que va a retirar le pertenece. Para probar esto, cada parte necesita enviar su firma, la cual prueba correctamente el estado (suma A, suma B, y alguna otra información).
El canal de pago síncrono tiene un número de estado que no cambia a menos que se cumplan requisitos específicos, como la confirmación y firma de la Parte B receptora. Por lo tanto, la Parte A no puede enviar varias transacciones a B consecutivas, ya que cada nuevo estado requiere una firma de ambas partes.
Al enviar una transacción a la Parte B, la Parte A necesita crear un estado que cambie la cantidad que pertenecerá tanto a A como a B, firmar este estado usando su propia clave privada, y luego enviar el nuevo estado y la firma a B. La Parte B luego firma este estado y envía su firma de vuelta a la Parte A, confirmando así el estado de la transacción. La Parte A no puede enviar otra transacción a la Parte B hasta que B cree un nuevo estado. Debido a esto, se le llama canal síncrono.
Una transacción fuera de la cadena de la Parte A a la Parte B a través de un canal de pago asíncrono.
En un canal de pago asincrónico, cada contraparte tiene su propio grupo de estados. Cada estado consiste en la cantidad que la Parte A recibió de la Parte B, el número de transacciones que la Parte A ha enviado a la Parte B, la cantidad que B envió a A, y el número de transacciones que B ha enviado a A. A diferencia de un canal de pago síncrono, A y B no necesitan esperar la confirmación de uno a otro, sólo necesitan enviar un estado firmado.
El aspecto más difícil para ambos canales es el proceso de retirada. El Contrato Inteligente necesita verificar que cada parte haya proporcionado los datos correctos antes de poder retirar los fondos. Tenemos que comprobar las firmas de los Estados y también que este Estado es el último. Si hay un conflicto entre las partes, el Contrato Inteligente debe resolverlo de acuerdo con el estado más reciente.
Debe haber protección contra el envío de los mismos datos a diferentes canales de pago, así como una resolución para cuando una de las partes no proporcione ninguna información. Todo esto debe estar escrito en FunC y probado a fondo para que sea seguro.
Soluciones y competencia
Según el canal oficial del concurso, se recibieron 68 propuestas.
La mayoría de las presentaciones eran billeteras de firmas múltiples y sistemas de nombres de dominio (o DNS) que resolvían el problema. Sin embargo, varias de las propuestas se refieren a los canales de pago. La redacción de los canales de pago era la tarea más compleja de la competencia, por lo que los pocos equipos fuertes (como 363, 375, 381) que fueron capaces de producir tales soluciones fueron más prominentes que los demás.
¿Qué es lo siguiente?
Actualmente, hay entre 10 y 20 equipos con suficientes habilidades y conocimientos para empezar a construir la infraestructura de TON, y es probable que transfieran la mayoría de las soluciones exitosas de Ethereum a TON. El concurso de TON y su incentivo de 200.000 dólares para el fondo de premios aumentó enormemente el número de equipos que pueden trabajar con la plataforma al ofrecer la oportunidad de adquirir experiencia de primera mano. Ahora, los equipos participantes están listos para construir sus propios proyectos o startups en TON.
Conclusiones claves para el equipo de Button Wallet
Como los primeros que adoptaron TON y amantes de Telegram, mi equipo y yo decidimos participar en el concurso de TON. Teníamos un gran equipo de ocho personas. Para nuestra solución, decidimos construir canales de pago síncronos y asíncronos. Aunque cometimos algunos errores durante el concurso, logramos hacer un canal de pago sincrónico con todos los contenedores que permiten depósitos, retiros y la transferencia de transacciones utilizando nuestra interfaz de línea de comandos. Así que, no sólo hicimos un Contrato Inteligente, sino un montón de contenedores que permitieron trabajar con TON mucho más fácilmente. Después de terminar el canal síncrono, aprovechamos el conocimiento de nuestra experiencia en el desarrollo de Plasma y construimos otro contrato inteligente que implementa pagos asíncronos fuera de la cadena. Sin embargo, no pudimos escribir todos los contenedores antes de la fecha límite.
Disfrutamos mucho de todas las tareas y desearíamos haber tenido más tiempo para implementarlas todas. Sin embargo, ganamos el primer lugar por mejor canal de pago síncrono, así como el tercer lugar por mejor canal de pago asíncrono.
Sigue leyendo:
- BNY Mellon y Credit Suisse habrían participado en la venta de tokens de Telegram
- SEC solicita la intervención del Reino Unido para forzar a que un antiguo asesor de Telegram testifique
- Un juez conserva la moción de la SEC para anular la defensa de Telegram por vaguedad
- Las naciones miembros de BRICS discuten la creación de una nueva cripto para un sistema de pago unificado
- Kik entrega su fondo Defend Crypto a la Blockchain Association
- Zuckerberg testificará ante el Congreso sobre Libra
Los puntos de vista, pensamientos y opiniones aquí expresados son responsabilidad exclusiva del autor y no reflejan ni representan necesariamente los puntos de vista y opiniones de Cointelegraph.
Nick Kozlov es el Director Técnico de Button Wallet, un desarrollador de software e investigador, así como uno de los ganadores del concurso TON.