Desarrollo de contratos inteligentes, revisados antes del código

¿Qué compara la primera revisión del contrato?

1 revisión previa al desarrollo compara las reglas que envías con el comportamiento que necesitas que el contrato ejecute. Identificamos decisiones faltantes antes de la implementación, y luego acordamos qué trabajo pertenece a la cadena.

La tabla separa 4 áreas de trabajo que pueden estar en un mismo proyecto. Tus reglas deciden cuáles aplican. Un contrato puede cumplir una función. Los contratos conectados necesitan más decisiones de interfaz.

Para cada acción, registramos quién la inicia, qué condiciones aplican y qué cambia. También anotamos las acciones rechazadas y los resultados esperados para el usuario. Esto le da a tu equipo una revisión concreta antes de que el código convierta los supuestos en comportamiento del contrato.

Si una criptomoneda es parte del diseño, conecta este trabajo con la creación y despliegue de tokens.

7 datos de entrada que mantienen visibles las decisiones del contrato

7 datos de entrada nos dan un punto de partida práctico para la especificación del contrato. Envía lo que tengas; marca los elementos sin respuesta en lugar de tratar las suposiciones como reglas aprobadas.

• Propósito del producto: el trabajo que el contrato debe realizar.
• Flujos de usuario: acciones desde la entrada hasta la finalización.
• Roles: usuarios, administradores y cada permiso que necesiten.
• Reglas de negocio: condiciones, plazos y casos excepcionales.
• Preferencia de red: la red objetivo, si ya está seleccionada.
• Interfaces: contratos existentes y requisitos de la aplicación.
• Necesidades de revisión: requisitos operativos, legales o de auditoría conocidos.

Para vesting, incluye:

• Fuente de asignación, beneficiario y condición de inicio.
• Patrón de liberación y proceso de reclamación.
• Si alguien puede modificar un calendario y quién puede autorizar esa acción.

Para staking, anota:

• Pasos de depósito y retiro.
• Entradas de recompensas y reglas de reclamación.
• Comportamiento en pausa.

Señalamos las dependencias y las decisiones abiertas en la revisión. Luego pedimos a tu equipo que apruebe los criterios de aceptación. Esa aprobación le da a la implementación una referencia clara.

Si tu trabajo va más allá del código del contrato, el desarrollo Web3 puede cubrir el producto más amplio. El desarrollo de dApps aborda la capa de aplicación.

3 ventanas de desarrollo, desde las reglas hasta el lanzamiento

3 ventanas de trabajo mantienen separadas las decisiones de producto, el código y la preparación para el lanzamiento. El calendario exacto sigue los comportamientos acordados del contrato, las integraciones y las necesidades de revisión.

1. Ventana de reglas: mapeamos roles, acciones, condiciones y casos extremos. Tu equipo resuelve las decisiones que afectan el comportamiento del contrato.
2. Ventana de especificación: registramos los comportamientos aprobados y los criterios de aceptación. Revisas el documento antes de que comience la implementación.
3. Ventana de desarrollo: implementamos la lógica acordada del contrato. Mantenemos el código alineado con la especificación revisada.
4. Ventana de tests: comprobamos rutas esperadas, permisos, entradas inválidas y casos extremos especificados. Los hallazgos y las opciones de producto no resueltas se registran para su revisión.
5. Ventana de lanzamiento: preparamos notas de configuración y detalles de entrega. Si se incluye una revisión independiente, coordinamos sus materiales y preguntas.

Cada ventana termina con un artefacto o decisión revisable, no con una aprobación asumida. Puedes ver qué está listo y qué necesita aún una respuesta. Para un producto conectado, confirma qué equipo es responsable de la integración de la aplicación. También confirma qué interfaces del contrato utilizará.

¿Qué pueden decirte los tests y las auditorías de contratos?

Los tests muestran si el contrato sigue los comportamientos acordados en su especificación. Una auditoría independiente es una revisión separada, con su propia evaluación y hallazgos.

Vinculamos cada comportamiento central a comprobaciones específicas:

• Acciones de usuario.
• Permisos.
• Entradas inválidas.
• Interacciones entre partes del contrato incluidas en el plan.

Resumimos la ejecución de los tests y registramos los elementos abiertos en lenguaje sencillo. Eso ayuda a tu equipo a distinguir un problema de código de una regla de producto que aún necesita una decisión.

Para una revisión externa, prepara la versión exacta de la fuente, una breve descripción del flujo del contrato, los supuestos conocidos, las dependencias y las instrucciones de test. Podemos organizar esos materiales, rastrear las preguntas del revisor y ayudar al equipo a verificar las correcciones acordadas. Los tests de desarrollo y la coordinación de la auditoría están separados del trabajo propio del revisor.

Una ejecución de tests no puede determinar cómo se comportará un contrato desplegado bajo todas las condiciones de red. El proveedor de auditoría seleccionado controla sus hallazgos. El comportamiento de la wallet y las integraciones de terceros también quedan fuera del código del contrato que construimos. Mantén esos límites en la decisión de lanzamiento, junto con la especificación, el registro de tests y los hallazgos de la revisión.

3 registros para llevar del desarrollo al lanzamiento

3 registros le dan a tu equipo una entrega utilizable: las reglas aprobadas, la evidencia de los tests y las notas de despliegue. Acordamos su contenido antes de que comience el trabajo, para que tu equipo sepa qué esperar.

• Registro de auditoría: mantenemos el trabajo de auditoría separado. Si una auditoría externa es parte del plan, su proveedor es dueño de su evaluación; nosotros coordinamos los materiales y las respuestas.
• Token o aplicación: alinea las decisiones de interfaz con la creación y despliegue de tokens o el desarrollo de dApps.
• Sitio web: un sitio web Web3 puede planificarse como un componente de producto separado.

En DigitalMedia1, revisamos las reglas y las interfaces antes de la implementación. Luego vinculamos los tests a esos comportamientos aprobados. Envíanos tu brief de producto, la red preferida y los materiales de contrato existentes. Los revisaremos y te enviaremos un presupuesto por escrito en un plazo de 2 días laborables.

Cómo trabajamos

1. 1 — Envía las reglas del productoVentana: antes de la especificación. Envía flujos de usuario, roles, preferencia de red, código existente y necesidades de revisión conocidas.
2. 2 — Revisa los límites del contratoVentana: revisión del plan. Identificamos dependencias, decisiones abiertas y los comportamientos que necesitan aprobación.
3. 3 — Aprueba la especificaciónVentana: antes de la implementación. Tu equipo revisa roles, flujos, casos extremos y criterios de aceptación.
4. 4 — Desarrolla y pruebaVentana: implementación y tests. Construimos la lógica acordada y registramos las comprobaciones contra el comportamiento especificado.
5. 5 — Prepara la entregaVentana: preparación del lanzamiento. Proporcionamos notas de despliegue y coordinamos cualquier trabajo de auditoría externa incluido.