<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/">
    <channel>
        <title>emapeire.eth</title>
        <link>https://paragraph.com/@emapeire</link>
        <description>▲</description>
        <lastBuildDate>Wed, 29 Apr 2026 13:46:34 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>https://github.com/jpmonette/feed</generator>
        <language>en</language>
        <image>
            <title>emapeire.eth</title>
            <url>https://storage.googleapis.com/papyrus_images/bc2681ba4693abc70e5e8428267316481f893ef12260b162e70283b8759b4460.png</url>
            <link>https://paragraph.com/@emapeire</link>
        </image>
        <copyright>All rights reserved</copyright>
        <item>
            <title><![CDATA[Diagrama: capas de la Blockchain]]></title>
            <link>https://paragraph.com/@emapeire/diagrama-capas-de-la-blockchain</link>
            <guid>0Rtswc4lWd7Bfy1HmqHQ</guid>
            <pubDate>Mon, 25 Apr 2022 01:10:55 GMT</pubDate>
            <description><![CDATA[El stack enteroL0: transferencia de datos / mineros — L1: blockchains — L2: velocidad / escalabilidad — L3: (d)apps.Capa por capaCapa 0 (L0)Capa 0 (L0): transferencia de datos / mineros.La planta baja. Aquí es donde existen Internet, el hardware y las conexiones que permiten que las capas 1 como Bitcoin funcionen sin problemas. Las capas 0 están permitiendo que sucedan varias cosas:Permitir que las cadenas de bloques interactúen entre sí Un gran ejemplo es Cosmos, que crea un ecosistema de ca...]]></description>
            <content:encoded><![CDATA[<h2 id="h-el-stack-entero" class="text-3xl font-header !mt-8 !mb-4 first:!mt-0 first:!mb-0">El stack entero</h2><figure float="none" data-type="figure" class="img-center" style="max-width: null;"><img src="https://storage.googleapis.com/papyrus_images/8150dd6e09ef4b1fb89cf23140bedd62113c244d292e11b2e62665d88aadb95b.png" alt="L0: transferencia de datos / mineros — L1: blockchains — L2: velocidad / escalabilidad — L3: (d)apps." blurdataurl="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=" nextheight="600" nextwidth="800" class="image-node embed"><figcaption HTMLAttributes="[object Object]" class="">L0: transferencia de datos / mineros — L1: blockchains — L2: velocidad / escalabilidad — L3: (d)apps.</figcaption></figure><h1 id="h-capa-por-capa" class="text-4xl font-header !mt-8 !mb-4 first:!mt-0 first:!mb-0">Capa por capa</h1><h3 id="h-capa-0-l0" class="text-2xl font-header !mt-6 !mb-4 first:!mt-0 first:!mb-0">Capa 0 (L0)</h3><figure float="none" data-type="figure" class="img-center" style="max-width: null;"><img src="https://storage.googleapis.com/papyrus_images/575722d950aaf680e91df09efe1cc1b8b689ad609511c0d90c1d85de9c5d7728.png" alt="Capa 0 (L0): transferencia de datos / mineros." blurdataurl="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=" nextheight="600" nextwidth="800" class="image-node embed"><figcaption HTMLAttributes="[object Object]" class="">Capa 0 (L0): transferencia de datos / mineros.</figcaption></figure><p>La planta baja. Aquí es donde existen Internet, el hardware y las conexiones que permiten que las capas 1 como Bitcoin funcionen sin problemas. Las capas 0 están permitiendo que sucedan varias cosas:</p><ol><li><p>Permitir que las cadenas de bloques interactúen entre sí Un gran ejemplo es Cosmos, que crea un ecosistema de cadenas de bloques interoperables gracias a su ‘<a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://tendermint.com/ibc/">Tendermint IBC</a>’ (Protocolo de comunicación entre cadenas de bloques). Para los desarrolladores, esto es enorme. Si una Dapp puede funcionar en una cadena de bloques, puede funcionar automáticamente en otras cadenas de bloques siempre que se construyan utilizando la misma capa 0. No es necesario invertir más tiempo y recursos para construir la misma aplicación en otra cadena.</p></li><li><p>Transacciones más rápidas y baratas Con IBC, el consenso de PoS se puede lograr en varias cadenas, lo que da como resultado que los tiempos de finalización se produzcan casi instantáneamente (finalidad = cuando se aprueba un bloque, no se puede revertir y se considera irreversible). El resultado son transacciones más rápidas y económicas entre intercambios de cadenas.</p></li><li><p>Infraestructura para desarrolladores Los desarrolladores no necesitan comenzar desde cero y construir sus cadenas de bloques desde el principio. Muchas características están preconstruidas y listas para implementarse de inmediato.</p></li></ol><h3 id="h-capa-1-l1" class="text-2xl font-header !mt-6 !mb-4 first:!mt-0 first:!mb-0">Capa 1 (L1)</h3><figure float="none" data-type="figure" class="img-center" style="max-width: null;"><img src="https://storage.googleapis.com/papyrus_images/26161e1c626d937b06f32bebc07c71fabaeb57c9fabf3ec725063def796a746b.png" alt="Capa 1 (L1): cadenas de bloques (blockchains)." blurdataurl="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=" nextheight="600" nextwidth="800" class="image-node embed"><figcaption HTMLAttributes="[object Object]" class="">Capa 1 (L1): cadenas de bloques (blockchains).</figcaption></figure><p>Las capas 1 son cadenas de bloques (Bitcoin y Ethereum) que procesan y finalizan transacciones en su propia cadena de bloques. Aquí es donde tienen lugar cosas como el consenso (PoW, PoS) y todos los detalles técnicos como el tiempo de bloqueo y la resolución de disputas.</p><ul><li><p>Los tres aspectos más importantes de las cadenas de bloques están conquistando el <strong>trilemma blockchain: descentralización, seguridad y escalabilidad</strong>. Todavía ninguna cadena de bloques ha logrado los tres.</p></li></ul><h3 id="h-capa-2-l2" class="text-2xl font-header !mt-6 !mb-4 first:!mt-0 first:!mb-0">Capa 2 (L2)</h3><figure float="none" data-type="figure" class="img-center" style="max-width: null;"><img src="https://storage.googleapis.com/papyrus_images/d4a9530986783162100b2d99ea4812fc67f047e37e65d0d177695e8382e15a90.png" alt="Capa 2 (L2): velocidad / escalabilidad." blurdataurl="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=" nextheight="600" nextwidth="800" class="image-node embed"><figcaption HTMLAttributes="[object Object]" class="">Capa 2 (L2): velocidad / escalabilidad.</figcaption></figure><p>Las capas 2 son integraciones de terceros que se utilizan junto con las capas para aumentar la escalabilidad y las transacciones por segundo (rendimiento del sistema).</p><ul><li><p>Cuando escuches sobre zero-knowledge rollups (zk-rollups), cadenas laterales (side chains), o cualquier cosa que tenga que ver con acelerar el rendimiento de las transacciones, es probable que sea la capa 2.</p></li></ul><h3 id="h-capa-3-l3" class="text-2xl font-header !mt-6 !mb-4 first:!mt-0 first:!mb-0">Capa 3 (L3)</h3><figure float="none" data-type="figure" class="img-center" style="max-width: null;"><img src="https://storage.googleapis.com/papyrus_images/f22a236676e61e9702cd32b9b63ac5922669f85a796cbdebb3154b35097badc3.png" alt="Capa 3 (L3): (d)apps." blurdataurl="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=" nextheight="600" nextwidth="800" class="image-node embed"><figcaption HTMLAttributes="[object Object]" class="">Capa 3 (L3): (d)apps.</figcaption></figure><p>La capa 3 es la capa de aplicación. Esta es la interfaz de usuario con la que nosotros, como consumidores, interactuamos.</p><p>*****Traducción al español del post <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://medium.com/@nick.5montana/blockchain-layers-l0-l1-l2-l3-in-a-diagram-569162398db">original</a> de <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://medium.com/@nick.5montana"><strong>Nicky Montana</strong></a>.</p>]]></content:encoded>
            <author>emapeire@newsletter.paragraph.com (emapeire.eth)</author>
            <enclosure url="https://storage.googleapis.com/papyrus_images/ec127d06b7bc18817e6f857e10b497bc9d13830b458f02f962372ac1fca9f0ae.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Los beneficios de los Optimistic Rollups frente a los ZK-Rollups]]></title>
            <link>https://paragraph.com/@emapeire/los-beneficios-de-los-optimistic-rollups-frente-a-los-zk-rollups</link>
            <guid>CuLmLzhfyx6Ft9w6Bchq</guid>
            <pubDate>Sat, 16 Apr 2022 19:46:21 GMT</pubDate>
            <description><![CDATA[Con la amplitud de la investigación sobre soluciones de escalabilidad off-chain, los rollups se han convertido en el candidato principal para impulsar cadenas de bloques seguras y escalables. Los Zk-rollups han atraído la mayor parte de la atención a pesar de tener una funcionalidad relativamente pequeña en comparación con sus contrapartes optimistas. A pesar de esta atención, los optimistic rollups tienen muchas ventajas sobre la variante zero-knowledge (conocimiento cero) que vale la pena e...]]></description>
            <content:encoded><![CDATA[<p>Con la amplitud de la investigación sobre soluciones de escalabilidad <em>off-chain</em>, los <em>rollups</em> se han convertido en el candidato principal para impulsar cadenas de bloques seguras y escalables. Los <em>Zk-rollups</em> han atraído la mayor parte de la atención a pesar de tener una funcionalidad relativamente pequeña en comparación con sus contrapartes <em>optimistas</em>. A pesar de esta atención, los <em>optimistic rollups</em> tienen muchas ventajas sobre la variante <em>zero-knowledge</em> (conocimiento cero) que vale la pena explorar.</p><h2 id="h-rollups" class="text-3xl font-header !mt-8 !mb-4 first:!mt-0 first:!mb-0">Rollups</h2><p>Los <strong><em>rollups</em></strong> son un tipo de <em>blockchain</em> que envía sus bloques a otra cadena (a la capa base o <em>L1</em>) que proporciona consenso y verifica la disponibilidad de datos del mismo bloque. Un <em>rollup</em> también puede agregar varios bloques y publicarlos juntos como un solo lote. Para los <strong><em>rollups optimistas</em></strong>, <strong>la capa base asume que las transacciones son correctas de manera predeterminada</strong>. Si una parte desea disputar el bloqueo, se genera una <strong><em>prueba de fraude</em></strong> para verificar la invalidez. A diferencia de los <em>rollups</em> <em>optimistas</em>, los <strong><em>zk-rollups</em></strong> <strong>requieren que cada bloque reciba validación para garantizar la validez</strong>, lo que se realiza a través de <strong><em>pruebas de validez</em></strong>.</p><h2 id="h-costos-de-transaccion" class="text-3xl font-header !mt-8 !mb-4 first:!mt-0 first:!mb-0">Costos de transacción</h2><p>Los costos que deben pagar los <em>rollups</em> para publicar transacciones en la capa base se pueden separar en dos categorías: <strong>costos fijos</strong> y <strong>variables</strong>. <strong>Los costos fijos son los costos que debe pagar el <em>rollup</em> por lote</strong>, incluso si no contiene transacciones. <strong>Los costos variables son los costos marginales que se acumulan con cada transacción adicional incluida en el lote</strong>.</p><p>Los <em>zk-rollups</em> tienen los costos fijos <strong>más altos</strong> entre los dos <em>rollups</em> por un amplio margen debido a la <em>prueba de validez</em>. El costo de enviar una <em>prueba de validez</em> a la capa base está determinado por su tamaño. Los <strong><em>SNARKs</em></strong> incurren en costos más bajos debido a su tamaño más pequeño, consumiendo aproximadamente 500k — 1M de gas en el <em>EVM</em>. Los <strong><em>STARKs</em></strong> incurren en costos más altos que los <em>SNARKs</em> debido a su tamaño de prueba más grande, consumiendo entre 1 millón y 5 millones de gas según el tamaño de la prueba. Los <em>rollups</em> <em>optimistas</em> no soportan este costo porque no se requieren pruebas, excepto en caso de disputas.</p><p>Una vez que aumenta la actividad en los <em>rollups</em>, el costo variable de los datos de transacción se convierte en el factor más importante que afecta las tarifas de transacciones de los <em>rollups</em>. Los datos de transacciones se envían mediante el <em>rollup</em> a <em>Ethereum</em> en forma de datos de llamadas, que tienen un costo de 16 gas por <em>byte</em> para datos de llamadas distintos de cero. Si bien el costo de los datos de llamadas es fijo, el precio por unidad de gas fluctúa según la demanda de espacio en bloque. A medida que más transacciones acompañan a cada lote, los aumentos de costos totales se amortizan entre todas las transacciones.</p><p>Los lotes más frecuentes que se envían a la capa base también incurren en más gastos de costos fijos acumulativos, por lo que algunos <em>zk-rollups</em> solo envían lotes grandes para amortizar el costo entre un conjunto más grande de transacciones. Por cierto, la amortización puede reducir las tarifas de transacción a pesar del aumento del costo total del lote, aunque esto solo es verdad hasta cierto punto. La medida en que los resúmenes están limitados es la capacidad de procesamiento de datos en la capa base.</p><p>Cuando los <em>rollups</em> operan a bajos niveles de actividad, los <em>rollups</em> <em>optimistas</em> tienen la ventaja en cuanto a costes ya que reducen sus costos fijos más allá de los <em>zk-rollups</em>. Cuando se opera a mayores niveles de actividad, el costo variable de enviar datos se convierte en el principal determinante de las tarifas de los <em>rollups</em>. El tipo de <em>rollup</em> que puede reducir el costo de los datos por transacción tiene una ventaja para escalar sus costos.</p><h2 id="h-equivalencia-con-la-evm" class="text-3xl font-header !mt-8 !mb-4 first:!mt-0 first:!mb-0">Equivalencia con la EVM</h2><p>Si bien los <em>rollups</em> apuntan a escalar <em>Ethereum</em>, muchos también intentan emular el mismo entorno para reducir la fricción al mover el ecosistema de aplicaciones de <em>Ethereum</em> a los mismos <em>rollups</em>. El grado en que el <em>rollup</em> implementa el mismo entorno en <em>Ethereum</em> se puede dividir en dos categorías: <strong>compatibilidad con la <em>EVM</em></strong> y <strong>equivalencia con la <em>EVM</em></strong>.</p><p><strong>La</strong> <strong>compatibilidad con la <em>EVM</em></strong> <strong>es la aproximación de la <em>EVM</em> dentro del <em>rollup</em></strong>. La mayoría de las funciones de la <em>EVM</em> están presentes, y los contratos de <em>Ethereum</em> se pueden portar, pero requieren algunos cambios en el código del contrato para ejecutarse en el <em>rollup</em>. <strong>La equivalencia con la <em>EVM</em></strong> <strong>es una implementación idéntica de la <em>EVM</em> dentro de un <em>rollup</em></strong>, donde todos los códigos de operación están presentes y los contratos de <em>Ethereum</em> pueden trasladarse al <em>rollup</em> con cambios mínimos.</p><p>En comparación con los <em>rollups</em> <em>optimistas</em>, los <em>zk-rollups</em> tienen una desventaja sustancial al volverse compatibles y comparables con la <em>EVM</em>, debido a la complejidad de implementar la misma <em>EVM</em> de una manera compatible con la implementación <em>‘zero-knowledge’</em>. Algunos códigos de operación son intrínsecamente difíciles de procesar en el circuito <em>zk</em>, y otras características, como ciertas herramientas criptográficas primitivas y pre-compiladores, también tienen problemas de incompatibilidad con <em>zkEVM</em>. La falta de problemas comparables es la razón por la que los <em>rollups</em> <em>optimistas</em> compatibles con <em>EVM</em> han estado activos durante más de un año, mientras que todavía no hay un <em>zk-rollup</em> en la red principal con dicha funcionalidad.</p><h2 id="h-requisitos-de-hardware" class="text-3xl font-header !mt-8 !mb-4 first:!mt-0 first:!mb-0">Requisitos de hardware</h2><p>Para garantizar que un <em>rollup</em> permanezca activo a pesar de las condiciones adversas, los requisitos de <em>hardware</em> deben mantenerse razonables de modo que otro nodo pueda intervenir para mantener la operación si falla el nodo inicial o un conjunto de ellos. <strong>En un <em>rollup optimista</em></strong>, <strong>un <em>secuenciador</em> debe estar operativo para crear lotes y publicarlos en la capa base</strong>. El <em>probador</em> solo está obligado a generar <em>pruebas de fraude</em> durante las disputas. <strong>En un <em>zk-rollup</em></strong>, <strong>tanto el <em>probador</em> como el <em>secuenciador</em> son necesarios para que la cadena progrese</strong>.</p><p>Si bien los <em>secuenciadores</em> en ambas construcciones de <em>rollup</em> tienen la misma función, los <em>probadores</em> difieren significativamente. <strong>Los <em>probadores</em> de los <em>zk-rollups</em> generan <em>pruebas de validez</em> que dan fe de cada lote</strong>, lo que requiere el cálculo de muchos compromisos criptográficos para generarlas. El alto costo de generar una <em>prueba de validez</em> aumenta los requisitos de <em>hardware</em> para ejecutar un <em>probador</em> y, al mismo tiempo, reduce la cantidad de personas que podrían <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://community.starknet.io/t/starknet-decentralization-tendermint-based-suggestion/998">iniciar un <em>probador</em></a> si fuera necesario. Es importante destacar que los retiros y las salidas forzadas se inician en el <em>rollup</em> mediante la producción de un nuevo bloque, por lo que los requisitos de <em>hardware</em> elevados en última instancia reducen la resistencia a la censura de los <em>zk-rollups</em> en comparación con los <em>rollups optimistas</em>.</p><h2 id="h-la-finalizacion" class="text-3xl font-header !mt-8 !mb-4 first:!mt-0 first:!mb-0">La Finalización</h2><p>El punto en el que las transacciones se consideran definitivas varía según los diseños de ambos <em>rollups</em>. Los <em>rollups optimistas</em> pueden publicar bloques con frecuencia cada pocos minutos, mientras que los <em>zk-rollups</em> están limitados por el tiempo de generación de la prueba: una <em>prueba de validez</em> debe acompañar cada lote que se envía a la capa base. Por ejemplo, si un lote espera cinco horas antes de enviarse a la capa base, las transacciones dentro de ese lote no reciben confirmación previa ni garantías de finalización.</p><p>La finalización es el tiempo que tarda una transacción en considerarse definitiva desde el punto de vista del contrato de la capa base. La finalización de una transacción permite que los fondos se retiren del <em>rollup</em> a otra cadena. Los <em>rollups optimistas</em> tienen una finalización nativa más lenta en comparación con los <em>zk-rollups</em>, ya que la finalización solo puede ocurrir una vez que ha pasado la ventana de disputa, que para la mayoría de los <em>rollups optimistas</em> es del orden de una semana. Sin embargo, se puede proporcionar una finalización más rápida para los retiros a través de <em>proveedores de liquidez</em>. El usuario inicia un retiro y el <em>proveedor de liquidez</em> intercambia sus <em>tokens</em> por un monto equivalente en la cadena de destino. La desventaja es que debe haber suficiente liquidez para retirar los <em>tokens</em>, de lo contrario, se debe usar el retiro nativo con la ventana de disputa. Debido a esto, los <em>zk-rollups</em> tienen una finalización nativa más rápida, pero los <em>rollups optimistas</em> tienen confirmaciones más rápidas y pueden tener una finalización más rápida para <em>tokens</em> líquidos.</p><h2 id="h-conclusion" class="text-3xl font-header !mt-8 !mb-4 first:!mt-0 first:!mb-0">Conclusión</h2><p>Los <em>zk-rollups</em> han recibido toda la publicidad como el futuro de la escalabilidad <em>rollup</em>, sin embargo, los <em>rollups optimistas</em> han demostrado ser candidatos viables y beneficiosos como una solución completamente funcional en la actualidad.</p><ol><li><p>Los <em>rollups optimistas</em> tienen costos fijos más bajos que los <em>zk-rollups</em> para enviar lotes a la capa base. A menor escala, esto da como resultado tarifas más bajas; sin embargo, esto puede cambiar a medida que aumenta la actividad y los datos de transacciones se conviertan en el costo marginal más grande para las tarifas acumuladas.</p></li><li><p>La compatibilidad y la equivalencia con la <em>EVM</em> son significativamente más fáciles de implementar para los <em>rollups optimistas</em>, ya que no tienen que luchar con las características difíciles e incompatibles que presentan las pruebas <em>zk</em>.</p></li><li><p>Los <em>zk-rollups</em> tienen altos requisitos de <em>hardware</em> para operar un <em>probador</em> debido al costo de generar una <em>prueba de validez</em>. Los requisitos más altos disminuyen la barrera de entrada y, en última instancia, reducen la resistencia a la censura del <em>zk-rollup</em>, ya que es necesario que haya un <em>probador</em> y un <em>secuenciador</em> para garantizar que el <em>rollup</em> continúe produciendo bloques. Como resultado, los <em>rollups optimistas</em> pueden tener una resistencia a la censura comparativamente mayor.</p></li><li><p>Los <em>rollups optimistas</em> pueden proporcionar confirmaciones y finalizaciones más rápidas para <em>tokens</em> líquidos a través de <em>proveedores de liquidez</em>, mientras que los <em>zk-rollups</em> brindan una finalización más rápida para retiros nativos y <em>tokens</em> no líquidos.</p></li></ol><p>*****<em>Traducción al español del artículo </em><a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://www.alexbeckett.xyz/the-benefits-of-optimistic-rollups-compared-to-zk-rollups/"><em>original</em></a><em> por </em><strong><em>Alex Beckett</em></strong><em>.-</em></p>]]></content:encoded>
            <author>emapeire@newsletter.paragraph.com (emapeire.eth)</author>
            <enclosure url="https://storage.googleapis.com/papyrus_images/60f96b4f3b4bec32b251b9ab72201c5466609a172d6e3d131450acb6a336091b.png" length="0" type="image/png"/>
        </item>
        <item>
            <title><![CDATA[El significado de la Descentralización]]></title>
            <link>https://paragraph.com/@emapeire/el-significado-de-la-descentralizaci-n</link>
            <guid>0hi5VsI2hwkVgu52qJ1t</guid>
            <pubDate>Thu, 07 Apr 2022 01:01:50 GMT</pubDate>
            <description><![CDATA[La “Descentralización” es una de las palabras que se usa con más frecuencia en el espacio de la criptoeconomía y, a menudo, incluso se la ve como la completa razón de ser de una blockchain, pero también es una de las palabras que quizás se define peor. Se han gastado miles de horas de investigación y miles de millones de dólares en hashpower con el único propósito de intentar lograr la descentralización, protegerla y mejorarla, y cuando las discusiones se tornan en rivalidades, es extremadame...]]></description>
            <content:encoded><![CDATA[<p>La <em>“Descentralización”</em> es una de las palabras que se usa con más frecuencia en el espacio de la criptoeconomía y, a menudo, incluso se la ve como la completa razón de ser de una <em>blockchain</em>, pero también es una de las palabras que quizás se define peor. Se han gastado miles de horas de investigación y miles de millones de dólares en <em>hashpower</em> con el único propósito de intentar lograr la descentralización, protegerla y mejorarla, y cuando las discusiones se tornan en rivalidades, es extremadamente común que los defensores de un protocolo (o extensión del mismo) afirmen que las propuestas opuestas están <em>“centralizadas”</em> como un último argumento decaído.</p><p>Pero a menudo hay mucha confusión en cuanto a lo que realmente significa esta palabra. Considere, por ejemplo, el siguiente diagrama completamente inútil, pero desafortunadamente demasiado común:</p><figure float="none" data-type="figure" class="img-center" style="max-width: null;"><img src="https://storage.googleapis.com/papyrus_images/035057fce6f13735c90ed4714a8e622d0c21a81da34cf554ac66df812105814b.png" alt="Gráfico #1" blurdataurl="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=" nextheight="600" nextwidth="800" class="image-node embed"><figcaption HTMLAttributes="[object Object]" class="">Gráfico #1</figcaption></figure><p>Ahora, considere las dos respuestas en <em>Quora</em> para: <em>“</em><a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://www.quora.com/Whats-the-difference-between-distributed-and-decentralized-in-Bitcoin-land"><em>cuál es la diferencia entre distribuido y descentralizado</em></a><em>”</em>. El primero esencialmente repite el diagrama anterior, mientras que el segundo hace la afirmación completamente diferente en cuanto a que: <em>“distribuido significa que no todo el procesamiento de las transacciones se realiza en el mismo lugar”</em>, mientras que <em>“descentralizado significa que ni una sola entidad tiene control sobre todo el procesamiento”</em>. Por otro lado, la respuesta principal en <em>Ethereum stack exchange</em> da un <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://ethereum.stackexchange.com/questions/7812/question-on-the-terms-distributed-and-decentralised">diagrama muy similar</a>, ¡pero con las palabras <em>“descentralizado”</em> y <em>“distribuido”</em> intercambiadas! Claramente, hay un orden en está aclaración.</p><h2 id="h-tres-tipos-de-descentralizacion" class="text-3xl font-header !mt-8 !mb-4 first:!mt-0 first:!mb-0">Tres tipos de Descentralización</h2><p>Cuando la gente habla de la descentralización del software, en realidad hay tres ejes separados de centralización/descentralización de los que pueden estar hablando. Si bien en algunos casos es difícil ver cómo se puede tener uno sin el otro, en general son bastante independientes entre sí. Los ejes son los siguientes:</p><ul><li><p><strong>(Des)centralización arquitectónica:</strong> ¿cuántas <strong>computadoras físicas</strong> componen un sistema? ¿Cuántas de esas computadoras puede tolerar averiarse en un solo momento?</p></li><li><p><strong>(Des)centralización política:</strong> ¿cuántos <strong>individuos</strong> u <strong>organizaciones</strong> controlan en última instancia las computadoras que componen el sistema?</p></li><li><p><strong>(Des)centralización lógica:</strong> ¿la <strong>interfaz</strong> y las <strong>estructuras de datos</strong> que presenta y mantiene el sistema se parecen más a un solo objeto monolítico o a un enjambre amorfo? Una heurística simple es: si usted corta el sistema por la mitad, incluidos los proveedores y los usuarios, ¿las dos mitades seguirán funcionando completamente como unidades independientes?</p></li></ul><p>Podemos intentar poner estas tres dimensiones en un gráfico:</p><figure float="none" data-type="figure" class="img-center" style="max-width: null;"><img src="https://storage.googleapis.com/papyrus_images/d8f72cce85cc8308a8982ac53d2eb44a3ee6b98bf0df7979c1802999b68a8e5d.png" alt="Gráfico #2" blurdataurl="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=" nextheight="600" nextwidth="800" class="image-node embed"><figcaption HTMLAttributes="[object Object]" class="">Gráfico #2</figcaption></figure><p>Tenga en cuenta que muchas de estas ubicaciones son muy difíciles y muy discutibles. Pero intentemos pasar por cualquiera de ellos:</p><ul><li><p>Las corporaciones tradicionales están políticamente centralizadas (un CEO), arquitectónicamente centralizadas (una oficina central) y lógicamente centralizadas (realmente no se pueden dividir por la mitad).</p></li><li><p>El derecho civil se basa en un organismo legislativo centralizado, mientras que el derecho consuetudinario se basa en precedentes creados por muchos jueces individuales. El derecho civil todavía tiene cierta descentralización arquitectónica, ya que hay muchos tribunales que, sin embargo, tienen una gran discreción, pero el derecho consuetudinario tiene más. Ambos están lógicamente centralizados (<em>“la ley es la ley”</em>).</p></li><li><p>Los lenguajes están lógicamente descentralizados; el inglés hablado entre Alice y Bob y el inglés hablado entre Charlie y David no tienen porqué coincidir en absoluto. No se requiere una infraestructura centralizada para que exista un idioma, y ​​las reglas de la gramática inglesa no son creadas ni controladas por una sola persona (mientras que el esperanto fue inventado originalmente por <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://es.wikipedia.org/wiki/L._L._Zamenhof"><em>Ludwig Zamenhof</em></a>, aunque ahora funciona más como un idioma vivo que evoluciona gradualmente sin autoridad)</p></li><li><p><a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://www.bittorrent.com/es/">BitTorrent</a> está lógicamente descentralizado de manera similar a como lo está el inglés. Las redes de entrega de contenido son similares, pero están controladas por una sola empresa.</p></li><li><p>Las <em>blockchains</em> están políticamente descentralizadas (nadie las controla) y arquitectónicamente descentralizadas (no hay un punto central de falla de infraestructura) pero están lógicamente centralizadas (hay un estado comúnmente acordado y el sistema se comporta como una sola computadora).</p></li></ul><p>Muchas veces, cuando las personas hablan de las virtudes de una <em>blockchain</em>, describen los convenientes beneficios de poseer <em>“una base de datos central”</em>; que la centralización es centralización lógica, y es un tipo de centralización que podría decirse que en muchos casos es buena (aunque <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://twitter.com/juanbenet"><em>Juan Benet</em></a> de <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://ipfs.io/"><em>IPFS</em></a> también presionaría por la descentralización lógica siempre que sea posible, porque los sistemas lógicamente descentralizados tienden a ser buenos para sobrevivir a las particiones de red, funcionan bien en regiones del mundo que tienen poca conectividad, etc.; véase también <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://scuttlebot.io/more/articles/design-challenge-avoid-centralization-and-singletons.html">este artículo de Scuttlebot</a> que defiende explícitamente la descentralización lógica).</p><p>La centralización arquitectónica a menudo conduce a la centralización política, aunque no necesariamente: en una democracia formal, los políticos se reúnen y votan en alguna cámara de gobierno físico, pero los mantenedores de esta cámara no terminan obteniendo una cantidad sustancial de poder sobre la toma de decisiones como resultado. En los sistemas computarizados, la descentralización arquitectónica, pero no política, puede ocurrir si hay una comunidad en línea que usa un foro centralizado por conveniencia, pero donde existe un contrato social ampliamente aceptado de que si los dueños del foro actúan maliciosamente, todos se trasladarán a un foro diferente (las comunidades que se forman en torno a la rebelión contra lo que ven como censura en otro foro probablemente tengan esta propiedad en la práctica).</p><p>La centralización lógica hace que la descentralización arquitectónica sea más difícil, pero no imposible: vea cómo ya se ha demostrado que las redes de consenso descentralizadas funcionan, pero son más difíciles que mantener BitTorrent. Y la centralización lógica dificulta la descentralización política: en los sistemas lógicamente centralizados, es más difícil <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://www.coindesk.com/markets/2016/07/18/the-hard-fork-whats-about-to-happen-to-ethereum-and-the-dao/">resolver</a> la <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://en.bitcoin.it/wiki/Block_size_limit_controversy">contención</a> simplemente aceptando la frase de <em>“vive y deja vivir”</em>.</p><h2 id="h-tres-razones-para-la-descentralizacion" class="text-3xl font-header !mt-8 !mb-4 first:!mt-0 first:!mb-0">Tres razones para la descentralización</h2><p>La siguiente pregunta es, en primer lugar, ¿por qué es útil la descentralización? En general, se plantean varios argumentos:</p><ul><li><p><strong>Modelo de tolerancia-a-fallos:</strong> los sistemas descentralizados tienen menos probabilidades de fallar accidentalmente porque dependen de muchos componentes separados entre sí.</p></li><li><p><strong>Resistencia a los ataques:</strong> los sistemas descentralizados son más costosos de atacar, destruir o manipular porque carecen de <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://starwars.fandom.com/wiki/Thermal_exhaust_port">puntos centrales sensibles</a> que puedan ser atacados a un costo mucho menor que el tamaño económico del sistema circundante.</p></li><li><p><strong>Resistencia a la colusión:</strong> es mucho más difícil para los participantes en los sistemas descentralizados conspirar para actuar de manera que los beneficie a expensas de otros participantes, mientras que los líderes de las corporaciones y los gobiernos se confabulan de manera que se benefician a sí mismos pero perjudican a los ciudadanos y clientes menos coordinados, empleados y público en general todo el tiempo.</p></li></ul><p>Los tres argumentos son importantes y válidos, pero los tres argumentos conducen a algunas conclusiones interesantes y diferentes una vez que se comienza a pensar en las decisiones de protocolo con las tres perspectivas individuales en mente. Tratemos de expandir cada uno de estos argumentos uno por uno.</p><p>Con respecto al modelo de tolerancia-a-fallos, el argumento central es simple. ¿Qué es menos probable que suceda: que falle una sola computadora o que falle cinco de cada diez computadoras todas al mismo tiempo? El principio no genera controversia y se usa en la vida real en muchas situaciones, incluidos motores a reacción, <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://en.wikipedia.org/wiki/Emergency_power_system">generadores de energía de respaldo</a>, particularmente en lugares como hospitales, infraestructura militar, diversificación de cartera financiera y, sí, redes informáticas.</p><p>Sin embargo, este tipo de descentralización, si bien sigue siendo eficaz y muy importante, a menudo resulta ser una panacea mucho menor de lo que a veces predeciría un modelo matemático ingenuo. La razón es la <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://en.wikipedia.org/wiki/Common_cause_and_special_cause_(statistics)#Common_mode_failure_in_engineering">falla-de-modo-común</a>. Claro, cuatro motores a reacción tienen menos probabilidades de fallar que un motor a reacción, pero ¿qué sucede si los cuatro motores se fabricaron en la misma fábrica y el mismo empleado deshonesto introdujo una falla en los cuatro?</p><p>¿Las <em>blockchains</em>, tal como son hoy en día, logran protegerse contra las fallas-de-modo-común? No necesariamente. Considere los siguientes escenarios:</p><ul><li><p>Todos los nodos en una <em>blockchain</em> ejecutan el mismo software de cliente, y resulta que este software de cliente tiene un error.</p></li><li><p>Todos los nodos de una <em>blockchain</em> ejecutan el mismo software de cliente, y el equipo de desarrollo de este software resulta ser socialmente corrupto.</p></li><li><p>El equipo de investigación que propone actualizaciones de protocolo resulta ser socialmente corrupto.</p></li><li><p>En una <em>blockchain</em> con <em>PoW</em>, el 70% de los mineros están en el mismo país, y el gobierno de este país decide apoderarse de todas las granjas mineras por motivos de seguridad nacional.</p></li><li><p>La mayoría del hardware de minería está construido por la misma empresa, y esta empresa es sobornada o coaccionada para implementar una puerta trasera que permite que este hardware se apague a voluntad.</p></li><li><p>En una <em>blockchain</em> con <em>PoS</em>, el 70% de las monedas en <em>stake</em> se mantienen en un <em>exchange</em>.</p></li></ul><p>Una visión holística en la descentralización en el modelo de tolerancia-a-fallos sería analizar todos estos aspectos y vería cómo se pueden minimizar. Algunas conclusiones naturales que surgen son bastante obvias:</p><ul><li><p>Es de vital importancia tener <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://www.reddit.com/r/ethereum/comments/3pdskt/how_many_ethereum_implementations_are_there/">múltiples competencias en las implementaciones</a>.</p></li><li><p>El <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://github.com/ethereum/EIPs/issues">conocimiento</a> de las <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://medium.com/@Vlad_Zamfir/the-history-of-casper-part-1-59233819c9a9">consideraciones</a> <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://medium.com/@Vlad_Zamfir/the-history-of-casper-chapter-2-8e09b9d3b780">técnicas</a> <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://medium.com/@Vlad_Zamfir/the-history-of-casper-chapter-3-70fefb1182fc">detrás</a> de las <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://medium.com/@Vlad_Zamfir/the-history-of-casper-chapter-4-3855638b5f0e">actualizaciones</a> de <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://medium.com/@Vlad_Zamfir/the-history-of-casper-chapter-5-8652959cef58">protocolo</a> <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ">debe</a> <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://medium.com/@VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735">democratizarse</a>, para que más personas puedan sentirse cómodas <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://gitter.im/ethereum/casper-scaling-and-protocol-economics">participando</a> en discusiones de investigación y criticando los cambios de protocolo que son claramente malos.</p></li><li><p>Los principales desarrolladores e investigadores deben ser empleados por <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://ethereum.org/en/">múltiples</a> <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://www.parity.io/">empresas</a> <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://blog.ethereum.org/2017/01/19/update-integrating-zcash-ethereum/">u</a> organizaciones (o, alternativamente, muchos de ellos pueden ser voluntarios).</p></li><li><p>Los algoritmos de minería deben diseñarse de manera que <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://github.com/ethereum/wiki/wiki/Ethash">minimicen el riesgo de centralización</a>.</p></li><li><p>Idealmente, usamos <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ"><em>proof of stake</em></a> para alejarnos por completo del riesgo de centralización de hardware (aunque también debemos tener cuidado con los nuevos riesgos que surgen debido a <em>PoW</em>).</p></li></ul><p>Tenga en cuenta que el requisito para el modelo de tolerancia-a-fallos en su forma más ingenua se enfoca en la descentralización arquitectónica, pero una vez que comience a pensar en el modelo de tolerancia-a-fallos de la comunidad que rige el desarrollo continuo del protocolo, será también importante la descentralización política.</p><p>Ahora, veamos la resistencia al ataque. En algunos modelos económicos puros, a veces se obtiene el resultado de que la descentralización ni siquiera importa. Si se crea un protocolo en el que se garantice que los validadores perderán $50 millones si ocurre un ataque del 51% (es decir, una reversión de la finalidad), entonces realmente no importa si los validadores están controlados por una empresa o 100 empresas: $50 millones de seguridad económica es el margen para un margen de seguridad económica de $50 millones. De hecho, existen <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://electowiki.org/wiki/Arrow%27s_impossibility_theorem">profundas</a> <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://www.sciencedirect.com/science/article/abs/pii/S0899825610000394">razones</a> de <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://es.wikipedia.org/wiki/Tragedia_de_los_bienes_comunales">teoría de juegos</a> por las que la centralización puede incluso maximizar esta noción de seguridad económica (el modelo de selección de transacciones de las <em>blockchains</em> existentes refleja esta idea, ya que la inclusión de transacciones en bloques a través de mineros/proponentes de bloques es en realidad una dictadura de rotación muy rápida).</p><p>Sin embargo, una vez que adopta un modelo económico más rico, y particularmente uno que admite la posibilidad de coerción (o cosas mucho más leves como ataques DoS dirigidos contra nodos), la descentralización se vuelve más importante. Si amenaza a una persona con la muerte, de repente $50 millones ya no le importarán tanto. Pero si los $50 millones se distribuyen entre diez personas, entonces hay que amenazar a diez veces más personas y hacerlo todo al mismo tiempo. En general, el mundo moderno se caracteriza en muchos casos por un ataque/defensa asimétrico a favor del atacante: un edificio que cuesta $10 millones para construir puede costar menos de $100.000 para destruir, pero la ventaja del atacante es a menudo sublineal: si un edificio que cuesta $ 10 millones para construir cuesta $100.000 para destruir, un edificio que cuesta $1 millón para construir puede costar de manera realista tal vez $ 30.000 para destruir. Cuanto más pequeño el edificio dará mejores ratios de beneficio.</p><p>¿A qué conduce este razonamiento? En primer lugar, presiona fuertemente a favor del <em>PoS</em> sobre <em>PoW</em>, ya que el hardware de la computadora es fácil de detectar, regular o atacar, mientras que las monedas se pueden ocultar mucho más fácilmente (<em>proof of stake</em> también tiene una fuerte resistencia a los ataques <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51">por otras razones</a>). En segundo lugar, es un punto a favor para tener equipos de desarrollo ampliamente distribuidos, incluida la distribución geográfica. En tercer lugar, implica que tanto el modelo económico como el modelo de tolerancia-a-fallos deben tenerse en cuenta al diseñar protocolos de consenso.</p><p>Finalmente, podemos llegar a quizás el argumento más intrincado de los tres, la resistencia a la colusión. La colusión es difícil de definir; quizás la única forma verdaderamente válida de decirlo es simplemente decir que la colusión es <em>“coordinación que no nos gusta”</em>. Hay muchas situaciones en la vida real en las que, aunque sería ideal tener una coordinación perfecta entre todos, un subgrupo puede coordinarse mientras que los demás no pueden, es peligroso.</p><p>Un ejemplo simple es la ley antimonopolio: barreras regulatorias deliberadas que se colocan para dificultar que los participantes de un lado del mercado se reúnan y actúen como un monopolio y obtengan ganancias externas a expensas del otro lado del mercado y el bienestar social en general. Otro ejemplo son las <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://publicintegrity.org/politics/rules-against-coordination-between-super-pacs-candidates-tough-to-enforce/">reglas contra la coordinación activa entre candidatos y super-PACs en los Estados Unidos</a>, aunque han resultado difíciles de aplicar en la práctica. Un ejemplo mucho más pequeño es una regla en <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://www.chesskid.com/learn/articles/heres-a-chance-to-play-magnus-carlsen">algunos torneos de ajedrez</a> que impide que dos jugadores jueguen muchas partidas entre sí para intentar aumentar la puntuación de un jugador. No importa dónde mires, los intentos de evitar la coordinación no deseada en instituciones sofisticadas están en todas partes.</p><p>En el caso de los protocolos <em>blockchain</em>, el razonamiento matemático y económico detrás de la seguridad del consenso a menudo se basa de manera crucial en el modelo de elección descoordinada, o en la suposición de que el juego consta de muchos pequeños actores que toman decisiones de forma independiente. Si cualquier actor obtiene más de 1/3 del poder de minería en un sistema de <em>proof of work</em>, puede obtener ganancias descomunales mediante la <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://arxiv.org/abs/1311.0243">minería egoísta</a>. Sin embargo, ¿podemos realmente decir que el modelo de elección descoordinada es realista cuando el 90% del poder de minería de la red Bitcoin está lo suficientemente bien coordinado como para presentarse juntos en la misma conferencia?</p><figure float="none" data-type="figure" class="img-center" style="max-width: null;"><img src="https://storage.googleapis.com/papyrus_images/a884fd0372958659e4b8961737ccd15da36bba23e482b9039dbc0085efa3b7a4.jpg" alt="Scaling bitcoin conf" blurdataurl="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=" nextheight="600" nextwidth="800" class="image-node embed"><figcaption HTMLAttributes="[object Object]" class="">Scaling bitcoin conf</figcaption></figure><p>Los defensores de la <em>blockchain</em> también señalan que las cadenas de bloques son más seguras para construir porque no pueden cambiar sus reglas arbitrariamente por capricho cuando lo deseen, pero este caso sería difícil de defender si todos los desarrolladores de software y de protocolo estuviesen trabajando en la misma empresa, siendo parte de la misma familia y sentándose en la misma habitación. El punto es que estos sistemas no deberían actuar como monopolios unitarios egoístas. Por lo tanto, ciertamente tu puedes argumentar que las cadenas de bloques serían más seguras si estuvieran más descoordinadas.</p><p>Sin embargo, esto presenta una paradoja fundamental. Muchas comunidades, incluida la de Ethereum, a menudo son elogiadas por tener un fuerte espíritu comunitario y por poder coordinarse rápidamente para implementar, liberar y activar un <em>hard fork</em> para solucionar problemas de denegación de servicio en el protocolo dentro de los seis días. Pero, ¿cómo podemos fomentar y mejorar este buen tipo de coordinación, pero al mismo tiempo evitar la <em>“mala coordinación”</em> que consiste en que los mineros intenten engañar a todos los demás coordinando repetidamente un ataques del 51%?</p><p>Hay tres formas de responder a esto:</p><ul><li><p>No se moleste en mitigar la coordinación no deseada; en su lugar, intente crear protocolos que puedan resistirlo.</p></li><li><p>Intente encontrar un término medio que permita suficiente coordinación para que un protocolo evolucione y avance, pero no lo suficiente como para permitir ataques.</p></li><li><p>Trate de hacer una distinción entre la coordinación beneficiosa y la coordinación dañina, y haga que la primera sea más fácil y la segunda más difícil.</p></li></ul><p>El primer enfoque constituye una <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://medium.com/@Vlad_Zamfir/the-history-of-casper-chapter-4-3855638b5f0e#.36ojr6ybl">gran parte</a> de la filosofía de diseño de <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://academy.binance.com/es/articles/ethereum-casper-explained">Casper</a>. Sin embargo, por sí solo es insuficiente, ya que confiar únicamente en la economía no logra abordar las otras dos categorías de preocupaciones sobre la descentralización. El segundo es difícil de diseñar explícitamente, especialmente a largo plazo, pero a menudo sucede accidentalmente. Por ejemplo, el hecho de que los desarrolladores centrales de bitcoin generalmente hablen inglés pero los mineros generalmente hablen chino puede verse como un feliz accidente, ya que crea una especie de gobierno <em>“bicameral”</em> que dificulta la coordinación, con el beneficio adicional de reducir el riesgo de falla-de-modo-común, ya que las comunidades inglesa y china razonarán al menos un poco por separado debido a la distancia y las dificultades de comunicación y, por lo tanto, es menos probable que ambas cometan el mismo error.</p><p>El tercero es un desafío social más que otra cosa; Las soluciones respecto a éste pueden incluir:</p><ul><li><p>Intervenciones sociales que intentan aumentar la lealtad de los participantes a la comunidad en torno a la <em>blockchain</em> en su conjunto y sustituir o desalentar la posibilidad de que los jugadores de un lado del mercado se vuelvan directamente leales entre sí.</p></li><li><p>Promover la comunicación entre diferentes <em>“lados del mercado”</em> en un mismo contexto, de manera de reducir la posibilidad de que tanto validadores como desarrolladores o mineros comiencen a verse como una <em>“clase”</em> que debe coordinarse para defender sus intereses frente a otras clases.</p></li><li><p>Diseñar el protocolo de tal manera que reduzca el incentivo para que los validadores/mineros participen en <em>“relaciones especiales”</em> uno a uno, redes de retransmisión centralizadas y otros mecanismos similares de súper protocolo.</p></li><li><p>Normas claras sobre cuáles son las propiedades fundamentales que se supone que tiene el protocolo y qué tipo de cosas no se deben hacer, o al menos se deben hacer solo en circunstancias muy extremas.</p></li></ul><p>Este tercer tipo de descentralización, la descentralización como evitación de coordinación no deseada, es quizás el más difícil de lograr, y las compensaciones son inevitables. Quizás la mejor solución sea confiar en gran medida en el único grupo que está garantizado que estará bastante descentralizado: los usuarios del protocolo.</p><p>[ Esto es una traducción del <a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274">post original</a> de <em>Vitalik Buterin</em> ]</p>]]></content:encoded>
            <author>emapeire@newsletter.paragraph.com (emapeire.eth)</author>
            <enclosure url="https://storage.googleapis.com/papyrus_images/5b6d944bc4a612fcf4f901248f3039a85b001f43695205ce9714f58d3e6c5e16.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[La Web 3.0: cómo la tecnología blockchain está cambiando al mundo]]></title>
            <link>https://paragraph.com/@emapeire/la-web-3-0-c-mo-la-tecnolog-a-blockchain-est-cambiando-al-mundo</link>
            <guid>zzJDB9fUeo94x0iG5pfj</guid>
            <pubDate>Mon, 28 Feb 2022 01:35:12 GMT</pubDate>
            <description><![CDATA[➡️ La tecnología está en constante desarrollo debido a las innumerables innovaciones de este mercado cambiante. Es por ello que la especialización, junto a las prácticas coherentes de este ecosistema, son las herramientas para el futuro del mañana 🚀 El uso de lenguajes programables y de maquetación hacen, hoy en día, los cimientos base de toda una arquitectura con estructuras sólidas en el campo de la computación 3.0. ✔️ Frameworks, bibliotecas, librerías, stacks, lenguajes interpretados y c...]]></description>
            <content:encoded><![CDATA[<p>➡️ La tecnología está en constante desarrollo debido a las innumerables innovaciones de este mercado cambiante. Es por ello que la especialización, junto a las prácticas coherentes de este ecosistema, son las herramientas para el futuro del mañana 🚀</p><p>El uso de lenguajes programables y de maquetación hacen, hoy en día, los cimientos base de toda una arquitectura con estructuras sólidas en el campo de la computación 3.0.</p><p>✔️ Frameworks, bibliotecas, librerías, stacks, lenguajes interpretados y compiladores, gestores de versiones y un gran amplio espectro de opciones nos muestran el camino por donde estamos parados, y por donde debemos seguir construyendo el futuro.</p><p>✔️ El desarrollo y el diseño son cualidades muy importantes a la hora de procesar cierta información específica, en particular cuando se interpretan diversas interacciones e intervienen diferentes actores de diferentes campos.</p><p>✔️ La revolución de la web 3.0, donde abundan los “smart contracts”, y donde están dirigidos por un conjunto de cadenas de bloques -como libros contables- llamados “blockchains”, no son más que cambios en la conformidad cotidiana donde se lograrán nuevas formas de transaccionar productos y servicios por el internet.</p><p>Los protocolos, que ya forman parte de este universo, son la clave para facilitar la interacción entre los usuarios y su integración a este ecosistema cada vez más creciente.</p><p>➡️ Un poco de historia. Satoshi Nakamoto, un experto en criptografía, publicó, en 2008, un “white paper” llamado: “Bitcoin: A Peer-to-Peer Electronic Cash System” (en español: Bitcoin: Un Sistema de Efectivo Electrónico Usuario-a-Usuario). Esta documentación de 9 páginas habla de cómo es posible, mediante el uso de la tecnología blockchain, crear un sistema de dinero electrónico (llamado bitcoin) para intercambiar libremente valor monetario entre usuarios.</p><p><a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://bitcoin.org/bitcoin.pdf"><strong><em>White paper en inglés</em></strong></a></p><p><a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://bitcoin.org/files/bitcoin-paper/bitcoin_es_latam.pdf"><strong><em>White paper en español</em></strong></a></p><p>No solo esto compite con las empresas bancarias más grandes del planeta, sino que a diferencia de ellas, esta tecnología representa una mejora en el estilo de vida de las personas. Gracias a su transparencia, la descentralización es la mayor de sus ventajas, sacando de lado al principal ente regulador en todo este asunto, el Banco Central (cuyo nombre denomina su identidad, y que por defecto principal conlleva a la Reserva Federal de los Estados Unidos de América).</p><p>Ahora bien, cómo puedo estar tan seguro que esta tecnología tan particular no representa ningún tipo de riesgo para mis interacciones diarias. Seguiremos abordando sobre ello.</p><p>La red de Bitcoin (the Bitcoin network) fue lanzada mundialmente el 3 de Enero del 2009, poniendo en funcionamiento así la más grande red descentralizada del mundo hasta la fecha. A su vez, no debemos confundir la red con la moneda digital en sí. La red está compuesta por todos los conjuntos de bloques encadenados entre sí y validados por nodos al rededor de todo el mundo. Aquellos nodos están formados por computadoras con gran potencia de procesamiento (mayormente con GPUs -placas de video-) que están sincronizadas mediante al acceso mundial del internet. Por último, y no menos importante, la moneda digital o criptomoneda “bitcoin”: conformada así por bits (unos -1- y ceros -0-).</p><p>Todo este ecosistema permite tener las ventajas de una red de transacciones, con el plus de una moneda nativa de la misma, la cual se puede usar para pagar dichas transferencias.</p><p>Cada usuario que se integra en este sistema descentralizado debe tener en cuenta diferentes etapas propiamente dichas de integración:</p><p>Debe tenerse en cuenta que como la red y la moneda son descentralizadas (o sea, que no pueden ser controladas por ningún ente ni persona física) la misma va a poseer una volatilidad esperable en su valor -financiero-, como así en usuarios que la utilizan -confianza de la misma-. Para contra restar este tipo de problemas, el 51% de la red (porcentaje de mayoría democrática) valida cada una de las transacciones para que no se comentan fraudes de ningún tipo. También, por yuxtaposición, las transacciones poseen un hash único que la hacen incorruptibles a cambios forzados por cualquier índole.</p><p>Las monedas poseen un respaldo en una red segura y transparente, tanto así que “el libro contable” posee una trazabilidad descrita en la propia red Bitcoin, es decir, que está a disposición de manera que el público la vea. Cada transacción es pública y por lo tanto debe corresponder a una dirección o “address” única, esto refiere a que cada billetera o “wallet” posee un número único como si hablásemos de nuestro CBU/CVU bancario. Como es de esperarse, nuestra dirección pública nos remite a nuestra cuenta privada, la cual tendrá una clave privada propiamente dicha que solo nosotros tendremos, y solo nosotros disponemos para nuestro conocimiento (como si hablásemos de nuestra contraseña del Home Banking). Cada transacción es incorruptible, lo que quiere decir que no se puede modificar una vez hecha.</p><p>Las billeteras son espacios digitales donde se almacenan nuestros activos, a diferencia de una cuenta bancaria, nosotros poseemos nuestras claves privadas que nos permitirán acceder solo a nosotros a los activos ante mencionados, como así depender solo de nosotros para disponer de cualquier eventualidad. Cada billetera posee una red particular (más allá de la red de Bitcoin) y cada una usa su criptomoneda en particular, pero hablemos por ahora solo de la red de Bitcoin y sus diferencias entre sus propias redes.</p><p>Lightning Network es una red de transferencia instantánea que pertenece a Bitcoin, la misma tiene una característica particular, ya que se pueden crear transacciones paralelas llamadas “sidechains” para que sean más efectivas a la hora de transferir montos rápidamente. Esta red es una consecuencia de las altas comisiones y demoras que conllevan las redes “Legacy” o principales de Bitcoin, es por ello que cuanto más avanza la tecnología nos permite mayores libertades a la hora de intercambiar nuestros activos con mayor facilidad.</p><p>➡️ Como conclusión, me gustaría entrar en la discusión de cómo las empresas de tecnología o “Starups” impactan a la hora de construir proyectos innovadores en este ecosistema tan dinámico y cambiante.</p><p>En todo proyecto es fundamental una buena relación entre los equipos multidisciplinarios (de diseño, desarrollo, marketing, finanzas, etc.) y el usuario, no solo para una correcta resolución de los problemas abordados, sino que así también, para una correcta armonía entre las partes que trabajan en el mismo.</p><p>La implementación del conjunto de las partes es fundamental a la hora de resolver situaciones críticas, donde requerir una visión práctica será la clave de cómo se resuelve una instancia con una visión mucho más amplia.</p><p>El carácter de un profesional debe ser visionario, con perspectivas realistas y constancias en sus actos. La organización y la responsabilidad es fundamental. Fomentar las buenas prácticas como: adaptarse al contexto laboral en equipo, y desempeñar un buen papel, sobre todo, en tomas de decisiones relevantes, relevará el correcto rendimiento del trabajo que se esté realizando. La disposición al aprendizaje de nuevas herramientas y tecnologías, que optimicen el desarrollo y desempeño profesional, serán el fin para alcanzar nuevas oportunidades y experiencias de empleo.</p><p>La dedicación debe estar a la vanguardia de las exigencias actuales. Ser perfectible y autodidacta definen una personalidad en constante progreso. Poseer carácter y ambición, en constante construcción, demuestra claridad decisiva, donde todos los proyectos que requieran de innovaciones formen parte del lenguaje que manejen aquellos profesionales.</p><p>Terminando así este artículo de Web3.0, espero que les haya servido de ayuda alguna e inspire a muchos a seguir construyendo este bello mundo relacionado con la diversidad de la tecnología en constante movimiento.</p>]]></content:encoded>
            <author>emapeire@newsletter.paragraph.com (emapeire.eth)</author>
            <enclosure url="https://storage.googleapis.com/papyrus_images/ec127d06b7bc18817e6f857e10b497bc9d13830b458f02f962372ac1fca9f0ae.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Web 3.0: how blockchain technology is changing the world]]></title>
            <link>https://paragraph.com/@emapeire/web-3-0-how-blockchain-technology-is-changing-the-world</link>
            <guid>g5Nn2yTAy1hdq8fshLwf</guid>
            <pubDate>Tue, 15 Feb 2022 21:47:10 GMT</pubDate>
            <description><![CDATA[➡️ Technology is constantly developing due to the countless innovations of this changing market. That is why specialization, together with the coherent practices of this ecosystem, are the tools for the future of tomorrow 🚀 The use of programmable and layout languages ​​make, today, the base foundations of an entire architecture with solid structures in the field of computing 3.0. ✔️ Frameworks, libraries, stacks, interpreted languages ​​and compilers, version managers and a wide spectrum of...]]></description>
            <content:encoded><![CDATA[<p>➡️ Technology is constantly developing due to the countless innovations of this changing market. That is why specialization, together with the coherent practices of this ecosystem, are the tools for the future of tomorrow 🚀</p><p>The use of programmable and layout languages ​​make, today, the base foundations of an entire architecture with solid structures in the field of computing 3.0.</p><p>✔️ Frameworks, libraries, stacks, interpreted languages ​​and compilers, version managers and a wide spectrum of options show us the way where we stand, and where we must continue to build the future.</p><p>✔️ Development and design are very important qualities when processing certain specific information, particularly when interpreting various interactions and involving different actors from different fields.</p><p>✔️ The web 3.0 revolution, where <em>“smart contracts”</em> abound, and where they are directed by a set of blockchains -like ledgers-, they are nothing more than changes in daily compliance where new ones will be achieved ways to transact products and services over the internet.</p><p>The protocols, which are already part of this universe, are the key to facilitating interaction between users and their integration into this increasingly growing ecosystem.</p><p>➡️ A bit of history. Satoshi Nakamoto, an expert in cryptography, published, in 2008, a <em>“white paper”</em> called: <em>“Bitcoin: A Peer-to-Peer Electronic Cash System”</em>. This 9-page documentation talks about how it is possible, through the use of blockchain technology, to create an electronic money system (called bitcoin) to freely exchange monetary value between users.</p><p><a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://bitcoin.org/bitcoin.pdf"><strong><em>Bitcoin Whitepaper</em></strong></a></p><p>Not only does this compete with the largest banking companies on the planet, but unlike them, this technology represents an improvement in people’s lifestyles. Thanks to its transparency, decentralization is the greatest of its advantages, leaving aside the main regulator in all this matter, the Central Bank (whose name it calls its identity, and which by main default leads to the Federal Reserve of the United States from America).</p><p>Now, how can I be so sure that this particular technology does not represent any type of risk for my daily interactions. We will continue to address about it.</p><p>The Bitcoin network (the Bitcoin network) was launched worldwide on January 3, 2009, thus putting into operation the largest decentralized network in the world to date. In turn, we must not confuse the network with the digital currency itself. The network is made up of all sets of blocks chained together and validated by nodes around the world. Those nodes are made up of computers with great processing power (mostly with GPUs -video boards-) that are synchronized by means of worldwide internet access. Last but not least, the digital currency or cryptocurrency <em>“bitcoin”</em>: thus made up of bits (ones -1- and zeros -0-).</p><p>All this ecosystem allows to have the advantages of a network of transactions, with the plus of a native currency of the same, which can be used to pay these transfers.</p><p>Each user that is integrated into this decentralized system must take into account different stages of integration:</p><p>It should be taken into account that since the network and the currency are decentralized (that is, they cannot be controlled by any entity or individual), it will have an expected volatility in its value -financial-, as well as in users who use it -trust of it-. To counteract these types of problems, 51% of the network (percentage of the democratic majority) validates each of the transactions so that fraud of any kind is not discussed. Also, by juxtaposition, transactions have a unique hash that makes them incorruptible to forced changes of any kind.</p><p>The coins have a backup in a secure and transparent network, so much so that <em>“the accounting book”</em> has a traceability described in the Bitcoin network itself, that is, it is available for the public to see. Each transaction is public and therefore must correspond to a unique <em>“address”</em>, this refers to the fact that each <em>“wallet”</em> has a unique number as if we were talking about our bank CBU/CVU. As expected, our public address refers us to our private account, which will have a private key itself that only we will have, and only we have for our knowledge (as if we were talking about our Home Banking password). Each transaction is incorruptible, which means that it cannot be modified once it is made.</p><p>Wallets are digital spaces where our assets are stored, unlike a bank account, we have our private keys that will allow us to access only the aforementioned assets, as well as depending only on us to dispose of any eventuality. Each wallet owns a particular network (beyond the Bitcoin network) and each uses its particular cryptocurrency, but let’s talk for now only about the Bitcoin network and its differences between their own networks.</p><p>Lightning Network is an instant transfer network that belongs to Bitcoin, it has a particular characteristic, since parallel transactions called “sidechains” can be created to be more effective when transferring amounts quickly. This network is a consequence of the high commissions and delays that the <em>“Legacy”</em> or main Bitcoin networks entail, which is why the more technology advances it allows us greater freedom when it comes to exchanging our assets more easily.</p><p>➡️ In conclusion, I would like to enter into the discussion of how technology companies or <em>“Starups”</em> impact when building innovative projects in this dynamic and changing ecosystem.</p><p>In every project, a good relationship between the multidisciplinary teams (design, development, marketing, finance, etc.) and the user is essential, not only for a correct resolution of the problems addressed, but also for a correct harmony between the parts that work on it.</p><p>The implementation of all the parts is essential when solving critical situations, where requiring a practical vision will be the key to how an instance with a much broader vision is resolved.</p><p>The character of a professional must be visionary, with realistic perspectives and constancy in his actions. Organization and responsibility is essential. Encouraging good practices such as: adapting to the team work context, and playing a good role, especially in making relevant decisions, will reveal the correct performance of the work being carried out. The willingness to learn new tools and technologies, which optimize professional development and performance, will be the end to reach new opportunities and employment experiences.</p><p>Dedication must be at the forefront of today’s demands. Being perfectible and self-taught define a personality in constant progress. Possessing character and ambition, in constant construction, demonstrates decisive clarity, where all projects that require innovations are part of the language used by those professionals.</p><p>Ending this Web 3.0 article like this, I hope it has been of some help to you and inspires many to continue building this beautiful world related to the diversity of technology in constant movement.</p>]]></content:encoded>
            <author>emapeire@newsletter.paragraph.com (emapeire.eth)</author>
            <enclosure url="https://storage.googleapis.com/papyrus_images/ec127d06b7bc18817e6f857e10b497bc9d13830b458f02f962372ac1fca9f0ae.jpg" length="0" type="image/jpg"/>
        </item>
    </channel>
</rss>