Este artículo analiza cómo se deben asignar y organizar los nodos de Descartes, según el tipo de DApp y cómo interactúan sus usuarios con ella. Esta es una pieza importante a considerar a medida que avanza para construir su DApp computacionalmente intensiva sin comprometer la seguridad de sus usuarios.
Comencemos recapitulando los conceptos básicos.
El consenso global sobre una cadena de bloques pública es un recurso muy costoso y debe utilizarse con parsimonia. A medida que crea e implementa un contrato inteligente, todos los nodos productores de bloques de la red deben emular todas las instrucciones de su contrato. Debido a que todos los contratos inteligentes existentes compiten con usted por espacios escasos dentro del siguiente bloque, eso eventualmente conduce a que la red alcance la capacidad. Cuando sucede, las tarifas de la red se disparan a medida que los usuarios comienzan a participar en una subasta para garantizar un lugar para sus transacciones. En Ethereum, vimos que eso sucedía con Cryptokitties. Ahora vemos que vuelve a suceder con los primeros experimentos en DeFi.
Esta condición idiosincrásica no se puede resolver correctamente en la capa de consenso, incluso con fragmentación o DPoS. En cualquier caso, la velocidad a la que se crean los bloques no se escala con los usuarios o con la adición de productores de bloques, lo que tarde o temprano genera congestión a medida que aumenta el uso de la red.
Es refrescante darse cuenta de que no se necesita un consenso global para que la mayoría de las DApps permanezcan descentralizadas. En términos generales, si las partes interesadas en la DApp pueden llegar a un acuerdo entre ellas fuera de la cadena, pueden contar con una mejora dramática en los recursos disponibles para ellos. Esa mejora podría darse en términos de cálculo, rendimiento, almacenamiento o cualquier combinación de estas dimensiones.
Este es un principio común de las soluciones de capa 2. Los roll-ups aumentan el rendimiento, mientras que las cadenas laterales y el plasma permiten que las DApps se expandan tanto en rendimiento como en almacenamiento. Descartes, por otro lado, se expande en capacidad computacional.
Con Descartes, las DApps pueden ponerse de acuerdo sobre los resultados de tareas computacionalmente intensivas que comprenden billones de pasos, sin que ninguno de los procesos toque la cadena de bloques. En casos raros en los que algunas personas intentan reclamar un resultado falso, la cadena de bloques se utiliza como un tribunal supremo, lo que garantiza que la parte honesta pueda resolver el resultado correcto en la cadena. Además, incluso cuando las partes no están de acuerdo, el costo en cadena para resolver la disputa es insignificante, ya que emplea un famoso algoritmo para la verificación interactiva.
En este caso, la cadena de bloques no se utiliza como una computadora descentralizada. Por el contrario, la capa computacional se elimina de los grilletes del consenso global y la cadena de bloques se convierte en un tribunal computacional. Este tribunal garantiza que cualquier reclamo honesto se resuelve en cadena mientras castiga económicamente a los reclamantes maliciosos. En consecuencia, esta garantía desincentiva fuertemente el mal comportamiento en primer lugar, haciendo que los ataques sean raros mientras los participantes disfrutan de una interacción eficiente fuera de la cadena.
Es importante tener en cuenta que, a medida que los desarrolladores de DApp de Descartes se alejan del consenso global, deben tener cuidado de reemplazarlo por una estructura de consenso local que sea lo suficientemente robusta para sus sistemas. Eso puede ser más fácil de lograr de lo que parece a primera vista ya que:
Descartes asegura que el resultado correcto del cálculo se establezca inequívocamente en cadena, siempre que al menos uno de los validadores sea honesto.
Por lo tanto:
El consenso local es confiable si la DApp puede asegurarse de que al menos un nodo Descartes participante esté disponible y responda;
En caso de disputas, se utilizan las fuertes garantías del consenso global (aunque de forma muy rentable a través de un juego de verificación).
Por lo tanto:
Si la topología de los nodos de Descartes está correctamente diseñada para una DApp dada, conservará una cantidad suficiente de descentralización y las mismas garantías de seguridad de la cadena de bloques subyacente.
La siguiente pregunta es qué comprende una cantidad suficiente de descentralización, ya que este parece ser el ingrediente final para una configuración exitosa.
Cartesi deja la elección de los nodos de validación al desarrollador de DApp. Son los mejores candidatos para determinar la topología adecuada de nodos ya que saben qué garantías debe brindar el sistema a sus usuarios. ¿Es un juego para dos jugadores o es un juego multijugador con un número ilimitado de jugadores? ¿O es una aplicación DeFi con una gran cantidad de usuarios?
Por tanto, veamos cuáles son las posibilidades. En primer lugar, los nodos de Descartes pueden ser ejecutados por los propios usuarios de DApp o por un tercero. Esta podría ser una organización en la que confíen para representar sus intereses.
Un usuario de DApp que decida ejecutar su propio nodo Descartes conservará la autonomía total, aunque eso conlleva inconvenientes. El usuario tiene que instalar y mantener un nodo por sí mismo. Deben asegurarse de que su nodo esté disponible y receptivo, con una conexión a Internet confiable, especialmente en casos de disputas mediadas por . Finalmente, necesitan que sus nodos se financien con suficientes tokens para pagar las transacciones y que se coloquen como garantía si necesitan defenderse de un reclamante malicioso.
En términos generales, es inconveniente y potencialmente riesgoso para una persona promedio ejecutar su propio nodo de Descartes. Si su nodo no tiene fondos suficientes o no está en línea cuando es necesario, corre el riesgo de perder plazos importantes y no puede defender los intereses de sus propietarios.
Por esa razón, actualmente estamos trabajando en una infraestructura en la nube que genera automáticamente nodos Cartesi para usuarios de DApp. Discutiremos este tema con más detalle más adelante.
Si bien Cartesi conserva la capacidad de cualquier persona para instalar y ejecutar sus nodos, entendemos que la mayoría de los usuarios de DApp no quieren cargar con esta responsabilidad técnica. Las DApps exitosas ocultarán tanto como sea posible las idiosincrasias de de sus usuarios. En última instancia, para la adopción exitosa de DApps, la propia y Cartesi deben ser lo más transparentes posible para los usuarios, de la misma manera que las bases de datos y los servidores de aplicaciones son invisibles para quien quiera usar una aplicación móvil.
Organicemos más esta discusión, comenzando por presentar las tres opciones posibles para DApps y usuarios:
Los usuarios ejecutan sus nodos; los usuarios eligen a alguien en quien confían para ejecutar los nodos en su nombre; los usuarios confían en un quórum de nodos administrado por organizaciones acreditadas.
La primera es una opción totalmente descentralizada, pero también inconveniente y arriesgada para los usuarios si se les obliga. El tercero es el menos descentralizado, pero también el más eficiente.
Una configuración híbrida que permite a los usuarios seleccionar libremente (1) o (2) arriba les da total flexibilidad, asegurando la máxima conveniencia o la máxima descentralización usuario por usuario. En ese sentido, desde la perspectiva del desarrollador de DApp, si agrupamos las dos primeras opciones, tenemos:
Configuración centrada en el usuario; Configuración de quórum;
Para la configuración centrada en el usuario, las DApps les permiten a los usuarios decir qué nodos quieren usar. Opcionalmente, podrían facilitar la experiencia de los usuarios preseleccionando una organización de confianza de forma predeterminada en su nombre. La DApp también puede sugerir organizaciones presentando una lista ordenada por reputación u otro método de preferencia del desarrollador.
Finalmente, las DApps deberían proporcionar una forma intuitiva para que los usuarios más valientes configuren sus propios nodos, ya sea en localhost o en cualquier otro lugar de Internet.
Este enfoque maximiza la conveniencia para los usuarios más optimistas al tiempo que les otorga visibilidad y opciones sobre las organizaciones que se pueden utilizar. Para los más pesimistas y conocedores de la tecnología, la opción de usar un nodo Descartes de propiedad aún se conserva.
En su versión actual, Descartes no escala bien con el número de partes que validan el cálculo con sus propios nodos de Descartes. La razón es que al final del cálculo, Descartes espera que un solo nodo sea el reclamante. Si otro nodo plantea una disputa, el segundo nodo entrará en el juego de verificación contra el reclamante. Al final de la disputa, el resultado ganador se establece como un nuevo reclamo y comienza un nuevo período desafiante. Si un tercer nodo no está de acuerdo con la afirmación actual, comienza un nuevo juego de verificación, y así sucesivamente.
Actualmente, el protocolo de resolución de disputas para múltiples desacuerdos debe ejecutarse en serie. Si tenemos 1000 nodos en desacuerdo entre sí, en el peor de los casos, el tiempo total para finalizar todo el arbitraje será 999 veces el período de cada juego de verificación. Tenga en cuenta que el tiempo para un solo juego de verificación puede variar de horas a días. Existen alternativas a la ejecución en serie, con consecuencias complejas pero también con una solución que será desarrollada por el equipo y discutida en detalle en un artículo futuro.
El nodo honesto tiene la garantía de demostrar su verdadero reclamo en la cadena eventualmente, pero el tiempo transcurrido puede convertirse en un factor preocupante. Para comprender esto, considere el siguiente ataque. 1000 usuarios interactúan con una DApp hipotética, cada uno ejecutando sus propios nodos de Descartes. 999 nodos se están coludiendo al presentar 999 afirmaciones falsas diferentes solo para retrasar la finalidad del resultado tanto como sea posible.
Debido a estos ataques a gran escala, no es aconsejable permitir que una DApp maneje 1000 nodos con nuestra arquitectura actual. Sin embargo, también debemos señalar que este tipo de ataque es muy costoso de implementar y en la mayoría de los casos inútil ya que cada parte deshonesta sufriría una dura sanción.
Cuando consideramos aplicaciones adecuadas para configuraciones centradas en el usuario, hay una clase especial que debemos mencionar. Los juegos de dos jugadores constituyen un amplio grupo de DApps potenciales que requieren solo dos nodos de Descartes, un nodo reclamante y un nodo retador.
Por ejemplo, si desea crear un juego en el que los jugadores se desafíen entre sí para obtener la puntuación más alta, pueden jugar todo el juego fuera de la cadena en el lado del cliente y enviar su registro de acciones del juego a su nodo Descartes. La máquina Cartesi verifica la jugabilidad emulando el juego con el registro de acciones del jugador y recalculando su puntuación de forma determinista. Si la disponibilidad de los datos del registro está garantizada (por ejemplo, comprimiéndolo e insertándolo en los eventos de la cadena de bloques), ambos jugadores pueden verificar las puntuaciones de los demás, y el ganador seguramente podrá demostrar su reclamo sobre la cadena de bloques si es necesario.
Además, también puede crear un torneo basado en corchetes donde el jugador con la puntuación más alta gana un premio. Eso funciona porque los torneos basados en corchetes se pueden reducir a rondas uno contra uno, donde dos jugadores se desafían entre sí por la puntuación más alta. En este caso, incluso con una cantidad arbitrariamente grande de jugadores y nodos, el enfoque de configuración centrado en el usuario puede ser una buena opción. Eso es precisamente lo que hicimos con Creepts y si no vio la base técnica de nuestro torneo de defensa de torres descentralizado, puede leerlo en detalle aquí.
En la configuración del quórum, los usuarios no pueden elegir los nodos de Descartes. En cambio, esa tarea se deja en manos de los desarrolladores, quienes seleccionan cuidadosamente las organizaciones para validar la computación de sus DApps. Seleccionan instituciones de acuerdo con la reputación, la disponibilidad o cualquier otro criterio relevante en el contexto particular de la aplicación.
Esto sería análogo a tener su software de back-end ejecutándose en AWS, Google Cloud y MS Azure al mismo tiempo, con todas las empresas verificando cada uno de los cálculos, por lo que nadie tendría que confiar en ninguna entidad.
Como Descartes necesita al menos un participante honesto para garantizar la exactitud de los resultados en la cadena, cualquier organización puede usar la cadena de bloques para probar una afirmación correcta. Eso puede ocurrir a expensas de que los malhechores sean recortados en grandes garantías. El dinero recolectado podría luego dividirse entre los usuarios de DApp para obtener una compensación por la molestia causada por retrasar la finalización de los resultados en la cadena.
De hecho, existe una razón más sólida para que las organizaciones se comporten de manera eficiente y honesta. Serían necesariamente transparentes, revelando nombres de personal y empresas, y posiblemente aceptando también alguna responsabilidad legal por mala conducta o errores. El daño causado por la pérdida de reputación puede exceder fácilmente la garantía perdida, haciendo que esta última sea opcional.
En cualquier caso, la selección de unas pocas instituciones acreditadas para validar los cálculos hace que sea muy poco probable que ocurran faltas y errores.
A diferencia de la configuración centrada en el usuario en la versión actual de Descartes, un quórum permite que un número ilimitado de usuarios compartan el estado de DApp. Esa sería la configuración elegida para muchos servicios DeFi que puede construir con Cartesi. Eso también es cierto para los juegos que involucran a una gran cantidad de jugadores como los MMORPG.
Un quórum también puede lograr fácilmente una mayor eficiencia. Los validadores podrían proporcionar mayores capacidades computacionales y, por lo tanto, acortar el tiempo hasta la finalidad. Otra forma de reducir el tiempo hasta la finalidad es hacer que el validador del reclamante recopile fuera de la cadena las firmas de todos los demás nodos que confirmen el reclamo. El reclamante luego demuestra con una sola transacción en cadena que ya se ha alcanzado un consenso unánime. Eso elimina la necesidad de un período de espera desafiante.
La infraestructura de nube en la que el equipo de Cartesi está trabajando actualmente tiene en cuenta la portabilidad. Nos estamos preparando para asociarnos con varias instituciones, dándoles el mismo sistema que la propia Cartesi ofrecerá a los usuarios. En este caso, Cartesi se convierte en una de las varias organizaciones de validación disponibles para DApps y sus usuarios.
Ahora resumimos las posibles topologías en función de cómo los usuarios interactúan entre sí en la DApp. Tenga en cuenta que la configuración del quórum puede ser suficientemente buena en cualquier circunstancia, a menos que exista una necesidad real de maximizar la descentralización o involucrar validadores anónimos.
Si está desarrollando su DApp con Cartesi, debe comprender cuándo los usuarios dependen de una transición de estado común. Eso es diferente del número de usuarios activos en la DApp.
Por ejemplo, puede implementar un juego de póquer con Cartesi donde solo 2 jugadores juegan entre sí. Su DApp puede servir a miles de usuarios simultáneamente, pero cualquier partido determinado solo interesa a los dos jugadores involucrados. En ese caso, el enfoque centrado en el usuario está perfectamente bien y se recomienda. Lo mismo sería cierto para los torneos ilimitados basados en corchetes (como se explicó anteriormente) y también para DApps donde pequeños grupos de usuarios necesitan compartir el estado.
Como también explicamos anteriormente, no recomendamos el enfoque centrado en el usuario para aplicaciones en las que demasiados usuarios comparten el estado. Dicho esto, es parte de la hoja de ruta de Cartesi eliminar por completo esa restricción, lo que permite una forma eficiente de que un número ilimitado de nodos se enfrenten entre sí y, por lo tanto, maximice la descentralización. Más información sobre ese tema vendrá en un artículo dedicado en el futuro.
Como siempre, te animamos a que traigas tus preguntas a nuestro canal de Discord.