¿Tendría esto sentido como una aplicación de contrato inteligente? Tratando de entender las características y limitaciones

Estoy empezando a leer sobre Ethereum y los contratos inteligentes y surgen algunas preguntas en mi mente.

Puedo entender que los contratos inteligentes se pueden usar, por ejemplo, para hacer una apuesta a favor o en contra de que va a estar nevando en Cambridge en un día específico, y puedo imaginar fácilmente cómo funcionaría un contrato inteligente como ese.

Sin embargo, imaginemos un caso más complejo.

  1. La empresa tiene un programa de recompensas por errores.
  2. El usuario encuentra un error y lo informa a la empresa, y quiere asegurarse de que la empresa le pague una vez que se haya solucionado el error.
  3. La empresa paga al usuario con un token digital en la cadena de bloques de Ethereum.

¿Significa esto que necesitamos codificar y crear un nuevo contrato inteligente firmado por ambas partes para cada error que informe cada usuario? Si este fuera el caso, ¿sería demasiado oneroso publicar un nuevo contrato en la cadena de bloques para cada informe de error?

¿O significa que necesitamos crear un contrato inteligente más genérico que pueda enviarle una transacción, donde cada transacción tiene un informe de error adjunto?

(No estoy tratando de hacer esto, solo para entender. Así que imaginemos que podemos codificar una función genérica isBugFixed(bug) que devuelve verdadero o falso para cada error que le pasamos)

Además, parece que el usuario tendría que pagar para enviar un nuevo informe de errores, ya sea para crear un nuevo contrato o para enviar una nueva transacción. ¿Estoy en lo correcto al decir que esto no se puede evitar sin una figura centralizada que actúe como intermediario y publique informes sobre la cadena de bloques, reduciendo así la descentralización (¿y si dos usuarios informan el mismo error al mismo tiempo? No habría nada similar como "el consenso sobre la cadena más larga", pero el intermediario tomaría la decisión).

¿Cree que la mejor decisión en tal caso sería confiar en una autoridad central que verifique los informes y los errores y use la cadena de bloques solo para transferencias de tokens o podría construirse todo como una aplicación descentralizada?

Gracias

Respuestas (1)

Además, parece que el usuario tendría que pagar para enviar un nuevo informe de errores, ya sea para crear un nuevo contrato o para enviar una nueva transacción.

Seguro.

¿Estoy en lo correcto al decir que esto no se puede evitar sin una figura centralizada que actúe como intermediario y publique informes sobre la cadena de bloques, reduciendo así la descentralización (¿y si dos usuarios informan el mismo error al mismo tiempo? No habría nada similar como "el consenso sobre la cadena más larga", pero el intermediario tomaría la decisión).

Primero, debe haber una gran cantidad de informes en caso de que estemos hablando de que sucederá con frecuencia. Por otro lado, podría suceder, y podemos resolverlo bastante fácilmente.

  1. no es un hecho que 2 informes se coloquen en el mismo bloque, por lo que su marca de tiempo será diferente
  2. puede tener otro contrato inteligente, que reciba informes y los clasifique con algún algoritmo antes de que realmente publique el informe de error en algún lugar (es decir, en una página web de la dapp)
  3. de todos modos, los errores serán corregidos por programadores humanos, quienes realmente decidirán si se trata de un error o no.

Conclusión: su escenario puede descentralizarse, pero aún no del todo. Pero puede ser que algún día la IA lo cambie. Por eso

¿Significa esto que necesitamos codificar y crear un nuevo contrato inteligente firmado por ambas partes para cada error que informe cada usuario?

sí, lo hace