Lecciones aprendidas sobre la implementación de contratos inteligentes

En medio de la noticia de su reciente disputa con la Comisión de Bolsa y Valores de los Estados Unidos, es probable que relativamente pocas personas hayan escuchado sobre la competencia de Red Abierta de Telegram que ocurrió hace algunas semanas. Fue un evento histórico que transformó la escritura de la comunidad de desarrolladores de TON, que alguna vez fue minúscula, 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 en torno a la nueva plataforma y resolvió problemas existentes relacionados con la falta de documentación sobre contratos inteligentes al proporcionar 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 sucedió durante y después del concurso 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 uso 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 TON requerían que los concursantes escribieran un contrato inteligente.

Debido a la falta de documentación sobre la escritura para TON usando FunC, los participantes del concurso debían analizar y aprender de los ejemplos existentes, que se habían subido a un pequeño Repositorio de GitHub

y el sitio web de prueba TON junto con algunos detalles teóricos. Si bien esta no fue una tarea difícil en general, comprender las necesidades básicas de un lenguaje basado únicamente en ejemplos puede resultar desafiante. Sin embargo, la mayoría de los concursantes pudieron comenzar a escribir libremente en FunC después de los primeros días.

Lo esencial – Al escribir un contrato inteligente usando FunC, necesitábamos comprender cómo implementar y compilar el contrato inteligente, así como también cómo llamar a las funciones usando argumentos. La completa falta de información detallada sobre este aspecto fundamental del lenguaje, además de no haber ejemplos que muestren los pasos completos, fue casi ridícula por su ironía. Montones breve directriz fue extremadamente útil para quienes participaron en la competencia, pero fue solo una introducción a la escritura de contratos inteligentes en TON que convenientemente omitió ejemplos o información detallada sobre la implementación y ejecución de llamadas a funciones en contratos inteligentes. Eventualmente, todos descubrieron cómo hacer todo esto, pero tomó mucho tiempo y esfuerzo.

Tareas del concurso

Hubo dos tareas del total de cinco que quiero destacar: 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 cadena de bloques) para que sea más rápido, menos costoso y más personalizado. Los usuarios tienen sus propias cuentas en la cadena de bloques y pueden enviar transacciones entre ellos utilizando sus sumas depositadas. Para esto, 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, que se analizarán a continuación.

Las partes A y B envían monedas al contrato inteligente, haciendo depósitos para abrir un canal de pago entre ellas.

Para abrir el canal de pago, los fondos deben depositarse en el contrato inteligente de ambos lados.

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 comprender que todo esto ocurre fuera de la cadena y que en algún momento, las partes deberán 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

Se supone que las partes podrían intentar retirar injustamente todos los fondos dentro del grupo. Debido a esto, cada parte debe demostrar que la suma que van a retirar les pertenece. Para probar esto, cada parte debe enviar su firma, que prueba correctamente el estado (suma A, suma B y alguna otra información).

El canal de pago sincrónico tiene un número de estado que no cambia a menos que se cumplan requisitos específicos, como recibir la confirmación y la firma de la Parte B. Por lo tanto, la Parte A no puede enviar varias transacciones a B seguidas, 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 con su propia clave privada y luego enviar el nuevo estado y firma a B. Parte B luego firma este estado y envía su firma de regreso 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 llama un canal sincrónico.

Una transacción fuera de la cadena de la Parte A a la Parte B a través de un canal de pago asincrónico

En un canal de pago asincrónico, cada contraparte tiene su propio grupo de estados. Cada estado consta de la cantidad que la Parte A recibió de la Parte B, la cantidad de transacciones que la Parte A envió a la Parte B, la cantidad que B envió a A y la cantidad de transacciones que B envió a A. A diferencia de un canal de pago síncrono, A y B no necesitan esperar la confirmación el uno del otro, solo necesitan enviar un estado firmado.

El aspecto más difícil para ambos canales es el proceso de retirada. El contrato inteligente debe verificar que cada parte haya proporcionado los datos correctos antes de que se puedan retirar los fondos. Necesitamos verificar las firmas de estado 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 último estado.

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 proporciona ninguna información. Todo esto debe estar escrito en FunC y probado exhaustivamente para ser seguro.

Soluciones y competidores

Según el oficial del concurso canal, hay 68 presentaciones.

La mayoría de las presentaciones fueron billeteras de múltiples firmas y solucionadores del sistema de nombres de dominio (o DNS). Sin embargo, varios envíos son para canales de pago. Escribir canales de pago era la tarea más compleja de la competencia, por lo que los pocos equipos fuertes (como 363, 375, 381) que pudieron producir tales soluciones fueron más prominentes que las otras.

¿Que sigue?

Actualmente, hay entre 10 y 20 equipos con suficientes habilidades y conocimientos para comenzar a construir la infraestructura de TON, y probablemente transferirán la mayoría de las soluciones exitosas de Ethereum a TON. El concurso TON y su incentivo de premio de $ 200,000 impulsaron en gran medida la cantidad de equipos que pueden trabajar con la plataforma al brindar la oportunidad de adquirir experiencia con ella de primera mano. Ahora, los equipos participantes están listos para construir sus propios proyectos o startups en TON.

Conclusiones clave para el equipo de Button Wallet

Como primeros usuarios de TON y amantes de Telegram, mi equipo y yo decidimos participar en el concurso 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. Por lo tanto, hicimos no solo un contrato inteligente, sino también muchos envoltorios que permitieron trabajar con TON mucho más fácilmente. Después de terminar el canal sincrónico, aprovechamos el conocimiento de nuestra experiencia de 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 muchísimo de todas las tareas y deseamos haber tenido más tiempo para implementarlas todas. Sin embargo, ganamos el primer lugar para el mejor canal de pago síncrono, así como el tercer lugar para el mejor canal de pago asíncrono.

Los puntos de vista, pensamientos y opiniones expresados ​​aquí son solo del autor y no necesariamente reflejan o representan los puntos de vista y opiniones de Cointelegraph.