Solidez: ¿Cómo podría disminuir el uso de gas de estructuras complejas?

La estructura es muy costosa como se indica aquí: parece extremadamente costosa cuando se almacena el tipo de estructura.

https://www.cryptocompare.com/coins/guides/what-is-the-gas-in-ethereum/ :

sstore 100 Pagado por una operación SSTORE normal (duplicado o renunciado a veces).

[P] ¿Qué decidió duplicarlo?

Por ejemplo, tengo la siguiente estructura definida dentro de una biblioteca: la siguiente operación en el interior insert()cuesta casi 150,000 de gas . Almacenando string, uinty bytebajo la estructura.

lib.sol

library Lib {
  struct job {
    string      hash;  // string hash_index_folderType;
    uint       index;  //
    byte  folderType;  //
  }
}

Ejemplo.sol

import "./Lib.sol"
contract Example{
   using Lib for Lib.data;
   function insert( string key, byte folderType ){
     uint currentIndex = cluster.jobStatus[jobKey].length;
     cluster.submittedJobs.push( Lib.job({hash: key, index: 
   currentIndex, folderType: folderType }) );
  }
}

Sé que almacenar datos es la operación más costosa en un contrato inteligente.

Pero como sabemos, el éter sigue aumentando (pasó de 50 $ a 240 $, lo que significa que el costo de la memoria aumentó 5 veces) y el precio del almacenamiento también aumenta rápidamente para los clientes, ya que el precio de la minería no disminuye. Así que estoy buscando la forma más compacta y eficiente de usar la memoria.

=> Mientras ether aumentaba, ¿por qué el precio del gas no disminuye para la memoria?

[P] Mi pregunta está relacionada con el lugar de almacenamiento structdentro de la biblioteca y si lo almaceno en el mismo archivo que insert()existe, ¿disminuye el uso de gas? Si no es así: ¿es una buena idea combinar todas las variables agregándolas a una cadena y almacenarlas como una variable de cadena única en lugar de una estructura? ¿Podría ayudar a disminuir el uso de gas?

Como ejemplo:

import "github.com/Arachnid/solidity-stringutils/strings.sol";
string hash_index_folderType = key.toSlice().concat(currentIndex.toSlice().concat(folderType.toSlice());