Contratos inteligentes - Permisos y agrupación de usuarios en la cadena de bloques

Estoy tratando de entender los contratos SMART y me gustaría que me ayudaran con mi comprensión. Creo que la mejor manera de responder a mis preguntas es con escenarios de ejemplo.

  1. Si tengo un servicio de notario en blockchain, tendré un contrato llamado Notary.sol. Esto contendrá detalles como el propietario, el destinatario, el documento. Una vez que todas las partes han firmado el documento, se envía una confirmación a alguna parte. Mi pregunta es que cada vez que un nuevo documento necesita ser notariado, ¿debo enviar un nuevo contrato a la cadena de bloques nuevamente para que haya una nueva "instancia" con un nuevo estado, etc.?

  2. Además del ejemplo del notario, me gustaría que el contrato inteligente verifique detalles adicionales de las otras partes antes de que se les permita firmar. Por ejemplo, verificar sus permisos o simplemente tomar su nombre. Para hacer esto, ¿llamaría a otro contrato inteligente como un evento para recuperar el resultado antes de continuar con el resto del contrato?

  3. En el sector de la salud, hay médicos y pacientes. Por ejemplo, un médico puede tener muchos pacientes. Un paciente puede tener un médico de cabecera. La relación similar se aplica a profesores y estudiantes (relaciones de muchos a muchos). Esto podría complicarse más con el almacenamiento de las calificaciones de los estudiantes. Esto parece más apropiado para administrar esto en una base de datos relacional, pero la cadena de bloques se usa para administrar la confianza en la transacción de registro. En el caso del ejemplo médico pacientes. Es posible que desee un contrato para trasladar a todos los pacientes a otro médico si el actual se retira o se jubila. Eso requiere que la cadena de bloques sepa qué pacientes pertenecen al médico. ¿Cómo podría controlar eso en la cadena de bloques o en los contratos?

  4. ¿Cómo me aseguro de que solo determinados usuarios puedan ejecutar un contrato? ¿El contrato tendrá sus direcciones que podamos validar antes de la ejecución?

Con suerte, estas son preguntas claras y agradezco las respuestas.

Gracias

Respuestas (1)

  1. La opción más fácil (y económica) probablemente sería usar el mismo contrato para todos los documentos. Tendría una lógica en su contrato que permitiera a una parte crear un documento (quizás usando un hash del documento) y especificar las partes que deben firmarlo.

  2. Cualquiera de las soluciones funcionará bien. Todo depende de tu arquitectura. Si cree que la implementación es más simple si usa un contrato separado para la administración de permisos, hágalo.

  3. Tienes razón al pensar que es mejor dejar algunas cosas fuera de la cadena de bloques y en una base de datos relacional. Por un lado, no puede realizar consultas complejas de datos a bajo costo (o, a veces, en absoluto). Mi consejo es mantener las cosas lo más simples posible. Un ejemplo de estructura de datos que podría usar para asociar médicos con pacientes es un mapa simple de las direcciones de los pacientes con las direcciones de los médicos:

    // map of patients to doctors
    mapping (address => address) patientsDoctors;
    
  4. Sí, el contrato necesitará conocer la dirección del usuario, pero esto no significa que deba conocer la dirección en el momento de la creación del contrato. Por ejemplo, su contrato puede tener uno admin, asignado en la creación del contrato, al que se le permite mutar un mapa de agents. Ciertas funciones tendrían que fallar si msg.senderno están contenidas en el agentsmapa.

¿Sería demasiado costoso destruir y crear un nuevo contrato inteligente cada vez que necesitamos un documento notariado? Hmm, un mapa podría funcionar, pero creo que debe haber un equilibrio entre lo que está almacenado en la base de datos y lo que está almacenado en la cadena de bloques.
@Decrypter Depende de sus definiciones de "demasiado caro". Creé dos contratos hoy. Crear uno costó 923 000 de gas y el otro 1 271 000 de gas. Esto es bastante más caro que una simple transferencia, tan barato como 21.000.