Contrato hijo vs estructura

Digamos que necesito almacenar y manipular la recopilación de datos complejos en el contrato inteligente. Puede haber reglas complejas que definan quién y cómo puede cambiar un elemento. Puede haber varios millones de artículos en la colección.

Hay 2 formas de implementar esa lógica

  1. Uso de contrato de niño:
elemento de datos del contrato {
    bytes32 clave;
    valor de cadena;

    función Elemento de datos (bytes32 k, cadena v) {
        clave = k;
        valor = v;
    }
}
contrato DAppInterface {
    mapeo (bytes32 => dirección) elementos de datos públicos;

    función addDataItem (bytes32 k, cadena v) externo {
        elementos de datos [k] = nuevo elemento de datos (k, v);
    }
}
  1. Usando estructura:
contrato DAppInterface {

    estructura elemento de datos {
        bytes32 clave;
        valor de cadena;
    }

    mapeo (bytes32 => Elemento de datos) elementos de datos públicos;

    función addDataItem (bytes32 k, cadena v) externo {
        elementos de datos[k].key = k;
        elementos de datos[k].valor = v;
    }
}

¿Cuál es la ventaja de usar uno u otro enfoque? ¿Cuáles son las pautas para elegir uno frente a otro?

Respuestas (1)

En la mayoría de las circunstancias, las estructuras de datos, incluso las más complicadas, deberían ser estructuras.

Aquí hay algunas razones para elegir estructuras:

  • Los contratos son más caros. Tendrá que pagar por la creación del contrato inicialmente, y cada vez que acceda a él, deberá pagar por una llamada a otros contratos. Esto es mucho, mucho más caro que un sha3 para una búsqueda dentro del propio almacenamiento del contrato.
  • Los contratos deben replicar el código. Todo contrato debe contener la lógica de fijación y alteración de valores, que deberá pagar en gasolina. Una estructura solo necesita un conjunto de funciones.
  • Los contratos están expuestos. Cualquiera puede enviar un mensaje a un contrato. Si utiliza un contrato para almacenar estructuras de datos, deberá administrar el acceso manualmente.
  • Las bibliotecas pueden ser lo que realmente estás buscando. Si se encuentra buscando funciones en una estructura de datos (es decir foo.bar(), ), puede usar un contrato de biblioteca para hacerlo sin la complejidad adicional de crear contratos para cada instancia.

Aquí hay algunas razones por las que los contratos serían superiores:

  • Los contratos pueden ser polimórficos. Un contrato podría contener código arbitrario. Esto permite que se entremezclen múltiples tipos, o incluso que los usuarios traigan su propia lógica.
  • La lógica se dividirá. En este contrato de registrador, cada Escritura podría haber sido una estructura. Al hacer que los Deeds sean sus propios contratos, hay menos superficie de ataque para los propios Deeds, lo que reduce la posibilidad de otro desastre a escala de TheDAO.
  • Los contratos están expuestos. Si los usuarios tienen que configurar sus estructuras de datos, tener una dirección única con la que puedan interactuar directamente puede resultar más simple.
  • Los contratos son contratos. Un contrato hijo puede hacer cualquier cosa que un contrato pueda hacer. Si las estructuras de datos, por alguna razón, poseyeran cosas como lo haría una dirección, entonces tener un contrato sería muy superior. Un contrato puede contener Ether directamente, a diferencia de una estructura que comparte el saldo del contrato principal con otras estructuras.

Sin embargo, estos son menos comunes. Mi consejo: pruébelo primero con estructuras y use contratos de estructuras de datos como último recurso.

¿El número de transacciones y la cantidad de datos almacenados en el contrato pueden afectar la decisión de utilizar un contrato o una estructura secundarios? Digamos que tengo una DApp de subasta donde cada artículo en venta tendría una cantidad de transacciones relacionadas con él (ofertas, pago, información de envío agregada, etc.). Esa DApp se puede implementar con estructuras y un solo contrato. Pero en ese caso habrá muchas transacciones ejecutándose simultáneamente contra ese contrato y el almacenamiento para ese contrato crecerá muy rápido. El contrato secundario permitiría aislar las transacciones y el almacenamiento del artículo vendido.
En la versión actual de Ethereum, no hay transacciones simultáneas (se prevé que esto cambie). Ya sea que se trate de un contrato o de varios, las transacciones aún se realizan de una en una. De manera similar, se almacena la misma cantidad ya sea en el mismo contrato o en varios (gastos generales aparte). Después de un cierto nivel de complejidad, el contrato individual comienza a tener sentido. Si cada subasta es su propio contrato, será mucho más fácil trabajar con los saldos de los usuarios, por ejemplo.
¿Qué saber si el uso del contrato infantil va a ser mejor en la capacidad de actualización? Dado que el diseño de la estructura de datos no está fijado a un solo contrato, podríamos actualizar cualquier cosa
Contrato hijo vs estructura
RespuestasAquíPolítica de privacidad1y, 0v