¿Existe un límite (teórico) para la cantidad de datos que puede almacenar un contrato?

¿Existe un límite teórico para la cantidad de datos que un contrato puede almacenar mientras se ejecuta en una red privada en la que el gas no es una preocupación?

Contexto: en un Dapp financiero que reemplazará a los sistemas de pago globales, el rendimiento de tx/s es sin duda un factor limitante que se discute ampliamente. Pero eso no es a lo que me refiero aquí. ¿Puede un contrato almacenar 1GB, 1TB,... datos en un contrato? Los datos no se escribirían de una sola vez, sino que se acumularían con el tiempo.

Ejemplo: supongamos el mejor de los casos en el que logramos exprimir una sola transacción de tokens que viven encima de un contrato inteligente en 100 bytes. Con un rendimiento de 1000 tps, esto produciría 100*1000*3600*24*31*12 = 3,2 TB/año. Siéntase libre de adivinar si / cuándo esto será posible.

¿Está 100% seguro de que necesita almacenar todos estos registros por toda la eternidad? Si se trata de comunicar cosas entre las partes, usar mensajes Whisper podría ser mejor. Otra opción sería guardar un hash de 32 bytes que apunte a los datos reales en Swarm o IPFS, etc.
Buen punto, estoy bastante seguro de que no los necesito para toda la eternidad, solo trato de entender los fundamentos. Estoy seguro de que quiero todos esos registros inicialmente, pero sería genial poder moverlos a IPFS después de N bloques, por ejemplo, después de un período de auditoría típico de un año. Parece difícil implementar eso en un contrato sin centralización en este momento (muévase de blockchain a IPFS y asegúrese de que las cosas correctas estén ahora en IPFS).

Respuestas (2)

El almacenamiento del contrato es una clave de 32 bytes y un valor de 32 bytes, por lo que el máximo que puede almacenar un solo contrato es de alrededor de 1,46 GB (32^32).

Falso. Hay 2^256 claves diferentes, y cada clave puede almacenar 32 bytes, por lo que hay un total de 2^261 bytes que se pueden almacenar. Dicho esto, para entonces la cadena de bloques de Ethereum probablemente se romperá debido a una colisión de hash...

Gracias, actualicé y arreglaré mi comentario aquí ethereum.stackexchange.com/questions/986/…
¿Qué quieres decir breakcon que fallará toda la cadena de bloques? ¿No hay comprobaciones de hashes duplicados? ¿Se tendrá que rebobinar/rehacer la transacción hasta que no ocurra ninguna colisión?
@BlockChange Si se descubren hashes duplicados, hay problemas mucho mayores porque eso significaría que el algoritmo hash se ha roto. Como referencia, para @ 2 ^ 261, suponiendo que pueda calcular 1 hash por picosegundo, aún necesitaría más tiempo del que tenemos hasta la muerte por calor del universo para encontrar un conflicto como ese, a menos que el algoritmo hash esté roto
2^261 = #bytes que se pueden almacenar con 2^256 direcciones, cada una almacenando 2^5 (=32) bytes. No tiene nada que ver con el algoritmo hash. El algoritmo hash utilizado es el hash Keccak de 256 bits, lo que proporciona 2^256 valores hash posibles, pero no tendría que esperar hasta el último para que se produzca una colisión. Recuerda el problema del cumpleaños (también conocido como la paradoja del cumpleaños). La probabilidad de colisión es > 99 % después de 2^130 valores. Con 2^160 de esos valores como direcciones de 2^160 contratos, P(colisión) > 99.999999.... % (no estoy seguro de cuántos 9 después del punto decimal)
@Earlz: el punto es que hay aproximadamente 2 ^ 35 segundos en un milenio (1000 años). Entonces, al ritmo de crear 1 contrato por segundo, se necesitarían 2^125 milenios para crear 2^160 contratos. Obtener colisiones mucho antes de eso NO implica que el algoritmo hash esté "roto".
no puede ser literalmente 2^261 en una implementación real, ¿verdad? No puede imaginar que sea físicamente posible. ¿No tenemos que modular el hash por el tamaño de almacenamiento real? En ese caso, ¿cuál es este tamaño de almacenamiento real?

El almacenamiento del contrato es una clave de 32 bytes y un valor de 32 bytes, por lo que el máximo que puede almacenar un solo contrato es de alrededor de 2^261 bytes (2^256 * 32b).

En una cadena privada donde el gas no es una preocupación, dado que el espacio de direcciones es de 160 bits, suponiendo que se pueda usar todo, se pueden crear 2^160 contratos. Entonces, en teoría, alrededor de 2^421 bytes es el máximo que pueden almacenar los contratos.

Te encontrarías con colisiones de hash mucho antes de crear 2^160 contratos; 2^80 es probablemente una estimación más razonable.
¿Por qué habría una colisión de hash después de crear 2^80 contratos? @Nick Johnson
¿Puede el valor de una clave ser un struct, que puede tener más de 32 bytes? @eth♦
@Alper Las claves de almacenamiento de contratos solo pueden ser de 32 bytes.
¿Existe un límite (teórico) para la cantidad de datos que puede almacenar un contrato?
RespuestasAquíPolítica de privacidad1y, 0v