Dada la tendencia actual de crecimiento de la red Ethereum, ¿es práctico el contrato inteligente para uso/almacenamiento a largo plazo?

Mi pregunta es en realidad tres partes (sí, sé sobre el próximo desarrollo de fragmentación en curso):

  1. Es gratis acceder a los datos de la red Ethereum (normalmente no necesitamos el resto de la cadena de bloques, pero necesitamos almacenar todo para acceder a una pequeña parte? ¿Dónde está el beneficio económico de esto? No hay recompensa para los mineros... Sé que ipfs también por cierto)
  2. Almacenar contratos inteligentes y procesarlos, etc. puede requerir un costo más alto (en gas) donde los usuarios participantes deben estar en una especie de lista (mapeo). ¿Es económicamente viable almacenar todo esto y procesarlo incluso con gas a largo plazo? Porque, si no me equivoco, el nodo Ethereum actual realmente requiere SSD (sí, requiere un nodo completo) para ejecutarse, y eso puede convertirse fácilmente en TB de datos en un futuro cercano. (Precio de almacenamiento/procesamiento frente al procesamiento del tamaño de la cadena de bloques... ¿Es Ethereum Network sostenible/viable para un contrato inteligente muy popular?)
  3. ¿Cuántos datos podemos almacenar en Ethereum Network nuevamente? ¿Ilimitado? Desde el punto de vista de un contrato único. Escuché que puede almacenar la mayor cantidad de datos siempre que no supere los 100 GB. Entiendo que la base de datos backend subyacente es leveldb... LEVELDB... ¿100 GB? Eso no va a ser un almacenamiento práctico para IOT.

Solo responda a estas preguntas si es un programador avanzado. Gracias.

Respuestas (2)

  1. Sí, obtener datos de la cadena de bloques es gratis. Puede sincronizar un nodo completo usted mismo (se necesitan ~ 50 gb actualmente, de unas horas a un día para sincronizar según su sistema/red), sincronizar un nodo ligero (unos pocos gb como máximo y unos minutos para sincronizar), o use nodos públicos de infuras (instantáneas, no se requiere sincronización, pero también confiables).

  2. Por supuesto, debe obtener la cantidad necesaria para almacenar en el contrato lo más pequeña posible. En general, si no necesita operar/recuperar los datos en la cadena, debe almacenar algo como un hash de IPFS y almacenar los datos reales en IPFS. Almacene solo lo que se necesita en la cadena. Esto significa saldos, permisos, etc., pero no cosas como avatares de usuarios o comentarios.

  3. La cantidad de datos que puede almacenar es ilimitada. El único factor de desaceleración es que es caro. Cuesta 20k de gasolina crear una palabra de 256 bits almacenada y 5k de gasolina para actualizarla después. A los precios actuales de la gasolina, eso es 4-5 centavos y 1 centavo. Ignorando la caída del precio del gas y solo hay 8 millones de gas por bloque, para asignar 1 gb de almacenamiento en cadena, costaría aproximadamente $ 500,000 solo por la asignación, sin incluir el costo de 21k tx y los otros códigos de operación que serían necesarios.

Para agregar a la respuesta existente.

  1. ...¿dónde está el beneficio económico de esto?

Un par de ideas:

  1. Está ayudando a mantener segura la red y, por extensión, también su ETH. Al ejecutar un nodo honesto y completo (sin minería), está agregando al grupo de nodos que ejecutan una versión honesta de los algoritmos de consenso. Su nodo puede validar bloques y transacciones, y evitar la propagación de transacciones deshonestas. Cuanto más sana sea la red, más segura será para sus inversiones.

  2. Puedes ejecutar tu propia billetera. No hay necesidad de depender de un tercero, independientemente de cuán confiables sean supuestamente. Una vez más, sus fondos están más seguros.

  1. ...y eso puede convertirse fácilmente en TB de datos en un futuro cercano.

Consulte El tamaño de la cadena de bloques de Ethereum no superará 1 TB en el corto plazo para obtener una descripción de los modos de poda y sincronización existentes. Esto no tiene en cuenta la fragmentación. (Vitalik: " Viene fragmentación ")

  1. ... Entiendo que la base de datos backend subyacente es leveldb... LEVELDB... 100GB?

Depende de la implementación del cliente. Geth usa LevelDB. Parity usa RocksDB (sí, bien, es una bifurcación de LevelDB). Puede escribir una implementación utilizando cualquier base de datos que desee: la especificación Yellow Paper, en la medida en que es una especificación, no menciona la base de datos subyacente.

Eso no va a ser un almacenamiento práctico para IOT.

Quizás no ahora mismo. Los modos de poda y fragmentación ayudarán. Al igual que la Ley de Kryder cuando se aplica al hardware IOT.