Hoy te traemos un artículo sumamente útil, importante y trascendental para todos aquellos que formen parte del núcleo de los nuevos empresarios. Serás testigo de las opiniones y referencias directas de muchos individuos importantes que trabajan en Ardor. No te lo pierdas, si lo tuyo son los negocios este artículo es hora para ti y para tus ideas. Tenlo por seguro. Entérate de todos los métodos que utilizaron para evitar a toda costa que los contratos bloqueen los fondos de los usuarios.
El inicio del proyecto de Ardor
Comenzar un gran proyecto de desarrollo de software siempre está asociado con muchos riesgos e incertidumbres. Cuando empezamos a trabajar en Ardor en 2016 los riesgos eran enormes, pero lo logramos. Ardor fue lanzado en mainnet en enero de 2018 como prometimos con su primera cadena infantil Ignis implementando las características del blockchain NXT y más. Desde entonces, hemos estado trabajando para añadir más funcionalidad y utilidad a este increíble producto.
Una persona sabia me dijo una vez, cuando necesitas entregar un gran proyecto de software, en lugar de pasar varios meses en la planificación, simplemente debes empezarlo. Los conocimientos y la experiencia que obtendrás en una semana te resultarán mucho más útiles que meses de planificación. Y así lo hicimos con el proyecto de contratos ligeros. Sin embargo, una cosa que no sabíamos cómo resolver por adelantado era cómo evitar que un contrato bloqueara los fondos del usuario en caso de que el corredor del contrato no pudiera (o no quisiera) ejecutar el contrato.
Como ya hemos comentado anteriormente, los contratos ligeros no forman parte del consenso. Sólo los nodos de los corredores de contratos, que decidan hacerlo, los ejecutarán. Pero entonces, como usuario que envía fondos a un contrato, ¿cómo puedo estar seguro de que el contrato se ejecutará y no bloqueará mis fondos? Ahora, tenemos una solución.
El nacimiento de la solución efectiva para los contratos ligeros
La mayoría de los marcos de contratos inteligentes no necesitan preocuparse por el bloqueo de los fondos de los usuarios, ya que la ejecución de los contratos forma parte del consenso. Si un nodo no ejecuta un contrato cuando debería, el nodo se deja en una horquilla.
Los incidentes históricos de bloqueo de fondos fueron el resultado de un error en el propio contrato. No en el marco de ejecución. Un ejemplo notable fue el contrato multisig de Ethereum Paritytech. Que se cambió de un estado autónomo a una biblioteca cuando los desarrolladores olvidaron eliminar el método de matanza.
Pero este enfoque de requerir que cada nodo ejecute cada contrato claramente no es escalable. Así que la gente propuso ideas alternativas como Plasma. Este describe un método para trasladar la ejecución de contratos a las cadenas infantiles. No te sorprendas si esto te suena familiar a lo que hacemos en Ardor. Las grandes mentes piensan igual, pero entonces los diseñadores de Plasma se encuentran con el mismo problema, si no todos están obligados a ejecutar un contrato, ¿cómo se asegura de que alguien lo ejecutará en absoluto y no sólo bloquear sus fondos?
El libro blanco del plasma menciona una idea de salida masiva. En caso de que alguien actúe maliciosamente en alguna cadena infantil. Todo el mundo puede escapar de ella. Creemos que es una mala idea, ya que es compleja de implementar y fácil de manipular. En cambio, nuestro enfoque es diferente. En realidad no enviamos los fondos a la cuenta del contrato hasta que éste se ejecuta con éxito.
El cimiento que sustenta un proceso rentable
Una gran cosa acerca de Ardor es que lo estamos construyendo sobre la rica funcionalidad de NXT. No estamos empezando desde cero como muchas de las otras soluciones de blockchain. NXT ya tiene una característica poco conocida que llamamos «phasing by hashed secret». La idea es que una transacción se presente junto con un hash de un secreto generado por una función de hash bien conocida.
Los saldos (u otros cambios de estado) sólo se actualizan una vez que el secreto es revelado por una transacción de aprobación separada. En caso de que el secreto no sea revelado por una determinada altura de bloque. La transacción permanece dentro de blockchain pero los saldos no se actualizan. Esta funcionalidad existe en NXT y ha estado en producción desde 2015.
Sencillez al momento de resolver el problema
Ahora podemos aprovechar esta pequeña gema utilizando Lightweight Contracts. El cliente que financia el contrato especificará un hash de un secreto que sólo ellos conocen. El contrato, que se ejecuta sobre la base de esta transacción desencadenante. Presentará su propia transacción utilizando el mismo «hashed secret».
Una vez que el cliente revele el secreto, ambas transacciones se aplicarán juntas como una sola operación atómica. Si el cliente decide no revelar el secreto, ambas transacciones permanecerán en la cadena de bloqueo pero sus cambios de balance serán ignorados.
Por lo tanto, si el contrato no se ejecuta, el cliente no revelará el secreto, por lo que cuando se alcance la altura de la fase, sus fondos serán liberados. Solución local simple, sin necesidad de salida en masa o similar.