Hice esa pregunta en Bitcointalk, pero hasta ahora no obtuve respuesta. Como Lior ha propuesto hacer de Stackexchange el principal medio de intercambio sobre Ardor, estoy preguntando aquí.
Como leí en las preguntas frecuentes , el principal inconveniente de los contratos ligeros es que no son totalmente confiables, porque no se puede garantizar que el "propietario del contrato" realmente ejecute el contrato.
Entonces, por ejemplo, si el contrato es un "contrato de intercambio" que debería darle algún token para ARDR (por ejemplo , este intercambio de IGNIS/ARDR ), entonces si el propietario del contrato no ejecuta el contrato, no obtendrá los tokens ( y el propietario del contrato podría robar su ARDR).
Puede ejecutar el contrato usted mismo, pero AFAIK no puede lograr que el "propietario del contrato" firme la transacción de intercambio sin ejecutarla él mismo; solo puede validar que el contrato hace lo que debe hacer de acuerdo con el código fuente. (Corríjame si me equivoco aquí).
Pero tal vez podrías hacer lo siguiente:
Primero ejecuta el contrato usted mismo y calcula la "transacción esperada" que debería resultar de él, en función de la entrada de su transacción planificada (en este caso, la transacción que lo recompensa con tokens de su ARDR).
Ahora emite una transacción por fases ("transacción condicional") con la condición de la "transacción esperada": en el caso de intercambio, recibe el monto del token calculado de la cuenta del contrato.
Si el contrato no se ejecuta o no le brinda la cantidad de token esperada, la transacción vence en algún bloque en el futuro.
De esta manera, el propietario del contrato solo puede gastar las monedas resultantes cuando el propietario del contrato ejecuta el contrato. Por lo tanto, está a salvo de los "estafadores selectivos" que ejecutan contratos una vez y nunca más.
El propietario del contrato también está seguro: el contrato debe poder construirse de manera que se compruebe primero que realmente puede producir la transacción deseada. Si no, simplemente no emite la "transacción esperada". Así que no pasa nada (solo que tenemos una transacción por fases inútil registrada en la cadena de bloques, pero creo que es un problema menor y crea el incentivo para activar el contrato solo con posibles condiciones).
¿Es posible este escenario? No lo he leído en las discusiones sobre contratos ligeros. Si no, creo que sería una buena adición, ya que entonces los contratos ligeros serían tan poco confiables (o casi tan confiables) como los contratos inteligentes de Ethereum (o incluso más, ya que los contratos de Ethereum pueden quedarse sin combustible).
AFAIK, necesitaría un nuevo tipo de Transacción por fases, una similar a la que requiere una transacción vinculada, pero con la capacidad de no requerir el hash de transacción completo (que es imposible de calcular en esta situación), pero la transacción "sin firmar" o el cantidad de un token/moneda a recibir.
Saludos, d5000
Una idea de cómo resolverlo funciona así:
El remitente envía la transacción desencadenante del contrato en fases con un modelo de aprobación de revelación de secreto basado en el hash de un secreto que genera.
El contrato activado por esta transacción desencadenante envía la(s) transacción(es) de respuesta con un modelo de aprobación compuesto compuesto por el mismo hash del secreto utilizado por la transacción desencadenante y el hash completo de la transacción desencadenante.
Lo que sucede a continuación es lo siguiente:
Si el remitente aprueba la transacción desencadenante, también puede aprobar la transacción del contrato, ya que se basan en el mismo secreto.
Si el remitente no aprueba la transacción desencadenante, tanto la transacción desencadenante como la transacción enviada por el contrato caducan.
Si el remitente intenta aprobar la transacción del contrato pero no aprueba su propia transacción, la transacción del contrato no se aprobará ya que también se basa en el hash completo de la transacción desencadenante que no está aprobado en la cadena de bloques.
Para implementar esto, necesitamos al menos dos cambios en el diseño existente: 1. Activar un contrato mediante una transacción por etapas que aún no se aprobó, que actualmente no se admite. 2. Mejore el modelo de aprobación de hash completo por transacción para que tenga la opción de aprobarse solo si el hash completo representa una transacción aprobada por fases y no solo una transacción almacenada en la cadena de bloques como lo es ahora.
d5000