Creo que la gran desconexión es que la mayoría de los normies no saben cuál es el tamaño del conjunto UTXO, solo entienden el "tamaño del bloque". En pocas palabras, el tamaño de la cadena de bloques (es decir, el tamaño total de todos los bloques) solo afecta el tiempo de sincronización inicial al configurar un nodo desde cero. Esto puede crecer en un máximo de 4 MB por bloque (en realidad alrededor de 2 MB). En teoría, solo hay que sincronizar un nodo desde cero una vez en la vida... en el caso de los nodos nuevos, puede omitir la sincronización descargando un conjunto UTXO y, a continuación, verificando que el nuevo nodo tenga el mismo hash del conjunto UTXO que uno de los nodos más antiguos. NO NECESITA almacenar todos los bloques, ni debería, a menos que tenga una buena razón. Por lo tanto, la optimización del tamaño de la cadena de bloques no reduce significativamente los recursos mínimos necesarios para ejecutar un nodo. En el mejor de los casos, reduce ligeramente el uso del ancho de banda. Si almacena todos los bloques, debido a la regla de consenso actual, debe planificar un aumento de 2 MB por bloque para planificar su actualización de hardware. Más importante que el tamaño de la cadena de bloques, es lo que todos DEBEN almacenar: el tamaño del conjunto UTXO. Los desarrolladores se preocupan mucho más por el tamaño del conjunto UTXO porque determina el almacenamiento mínimo necesario para ejecutar un nodo completo. (Un "nodo completo" significa que verifica todos los bloques, no necesariamente los almacena todos). El conjunto UTXO solía ser de alrededor de 4 GB. Debido a las inscripciones y BRC-20, ha crecido a unos 12 GB. El conjunto UTXO no almacena OP_RETURN datos ni firmas. Si desea que su nodo siga funcionando sin problemas en dispositivos pequeños, concéntrese en minimizar el tamaño del conjunto UTXO, no el tamaño de la cadena de bloques. Y esta es la razón por la que a muchos desarrolladores realmente no les importan OP_RETURN límites.