Hace años, cuando empecé a trabajar en proyectos que atendían a miles de millones de usuarios, vi cómo las decisiones de infraestructura tomadas en los primeros días pueden remodelar el destino de toda una industria.

Incluso las plataformas lanzadas con las mejores intenciones de ser abiertas, neutrales y libres de control pueden deslizarse hacia formas de centralización.

No es porque alguien tenga la intención de ser “malo”; es simplemente la atracción gravitatoria natural de la tecnología y los mercados cuando ciertas decisiones de diseño se establecen desde el principio.

Las decisiones de diseño de infraestructura importan desde el primer día.

Estas decisiones de diseño central deben garantizar que la propia tecnología garantice la equidad y evite la consolidación del poder en primer lugar.

Hemos visto esta película antes

“El poder tiende a concentrarse, incluso si nadie lo planea”

Es una verdad sutil pero profunda que aprendí de primera mano mientras trabajaba en productos de Internet a gran escala.

Cuando nació la ‘industria descentralizada’, parecía una segunda oportunidad. Miramos a Bitcoin, Ethereum y otros como formas de escapar de las viejas estructuras de poder.

La narrativa fue directa: recuperar el control, eliminar intermediarios y permitir que el código garantice la equidad.

Pero tenemos que ser honestos, con el tiempo, las mismas presiones que centralizaron Internet también empezaron a actuar sobre estos sistemas ‘descentralizados’.

Pero, ¿cómo se centralizó Internet?

¿No empezó Internet como una red descentralizada de pares (P2P) que incluso podría resistir una guerra nuclear?

Para entender por qué estos sistemas descentralizados están sucumbiendo a las presiones de centralización, tienes que entender lo que sucedió con Internet.

Tienes que mirar cómo pasó de sus comienzos idealistas a un ecosistema altamente centralizado.

La Internet temprana: Cuando el Peer-to-Peer era la norma

“Al principio, nadie tenía todas las llaves y ningún jugador único estaba tomando todas las decisiones”

La versión más temprana de lo que ahora llamamos Internet básicamente comenzó bajo el Departamento de Defensa de los Estados Unidos, con cosas como ARPANET a finales de los años 60.

Fuente: @DailySwig

La idea desde el primer día fue evitar ese único punto de falla, asegurarse de que ningún punto caído pudiera llevarse todo lo demás con él.

Esta red fue diseñada deliberadamente para ser descentralizada.

La razón fue estratégica: un sistema distribuido podría resistir el fallo de cualquier nodo único, lo que haría que las comunicaciones fueran más resistentes ante interrupciones como mal funcionamiento del equipo o incluso condiciones de guerra.

Una red de comunicación fiable y descentralizada que podría resistir incluso un ataque nuclear.

Cada nodo era un “par” capaz de enviar y recibir datos sin depender de una autoridad centralizada única. Cualquier máquina, independientemente del hardware o sistema operativo, podría “hablar” TCP/IP e intercambiar datos.

En los años 70 y 80, las universidades y los laboratorios de investigación se conectaron a través de NSFNET y ARPANET, y de repente tuviste este entorno en el que nadie tenía todas las llaves y ningún jugador único estaba tomando todas las decisiones.

Apareció en los fundamentos:

TCP/IP, FTP, Telnet, grupos de noticias Usenet y DNS no se trataban de encerrar a nadie en un lugar. Había poco incentivo para imponer controles o jerarquías estrictas.

Usenet, por ejemplo, distribuía mensajes de forma completamente descentralizada P2P. DNS delegaba la autoridad de nombres en una jerarquía distribuida, pero cada componente aún actuaba como cliente y servidor en cierta medida.

Todo esto reforzó ese principio original:

una red que no se trataba solo de un gran jugador que estableciera las reglas, sino más bien un sistema en el que cualquiera pudiera conectarse y participar.

Pero a principios de los años 90, la World Wide Web y los navegadores cambiaron todo el juego.

La página recreada del primer sitio web (Imagen: CERN)

El auge del modelo cliente/servidor

Tim Berners-Lee: El visionario detrás de la World Wide Web

“A medida que la base de usuarios de Internet aumentaba, las suposiciones originales sobre la participación abierta y la confianza mutua comenzaron a mostrar grietas”

La World Wide Web, introducida en 1989-1991, se construyó sobre estándares abiertos (HTTP, HTML) deliberadamente colocados en el dominio público. En su forma más temprana, la Web hacía trivial para individuos, pequeñas organizaciones o cualquier persona con un módem y alojamiento poner un sitio web.

La infraestructura todavía era en gran parte “plana” y descentralizada, con innumerables páginas web independientes vinculadas entre sí en una federación suelta.

Pero a principios de los años 90 algo se volvió realmente popular.

Esto es cuando ‘Web Browsing’ se convirtió en la aplicación asesina.

Los sitios web se convirtieron en escaparates, medios de comunicación y centros de entretenimiento. La persona promedio no estaba ejecutando su propio servidor ni alojando sus propias páginas.

La página de inicio de Netscape en 1994, con su mascota Mozilla, como se ve en NCSA Mosaic 3.0

[Captura de pantalla: Alex Pasternack /OldWeb.today]

Ejecutaron navegadores web (clientes), primero con esos módems lentos, luego con banda ancha, para obtener contenido de servidores web grandes y conocidos. De repente, alojar grandes cantidades de datos y configurar sitios de comercio electrónico o motores de búsqueda se convirtió en algo importante.

Los primeros motores de búsqueda como AltaVista, Yahoo! y más tarde Google surgieron para ayudar a las personas a navegar por el mundo en línea en constante expansión.

El efecto de red se hizo más pronunciado: cuanto más personas usaban un motor de búsqueda, mejor podía refinar sus modelos de indexación y publicidad, reforzando su dominio.

El algoritmo de PageRank de Google lo convirtió en una puerta de enlace singular a la inmensidad de la web.

Eso impulsó el dinero y la atención hacia los grandes centros de datos, y aquellos que pudieron escalar y manejar esas cargas masivas salieron adelante.

A medida que surgieron Proveedores de Servicios de Internet para atender a millones de nuevos usuarios, la infraestructura se optimizó naturalmente para la entrega aguas abajo.

Las velocidades de descarga más rápidas que las velocidades de carga (conexiones de banda ancha asimétricas como ADSL o cable) tenían sentido económico porque la mayoría de los usuarios consumían más de lo que producían. La red “aprendió” que la mayoría de los puntos finales eran solo clientes.

Y a medida que la base de usuarios de Internet aumentaba, las suposiciones originales del diseño sobre la participación abierta y la confianza mutua comenzaron a mostrar grietas.

Seguridad, Cortafuegos y Puertas cerradas

“La libertad y la apertura sin salvaguardias pueden invitar a abusos que nos obligan a construir muros más altos.”

Los protocolos originales no habían sido diseñados para manejar una multitud masiva y diversa, muchos con intereses comerciales o motivaciones que ponían a prueba la apertura del sistema.

Sin salvaguardas reales, el spam se convirtió en un gran problema, aprovechando ese entorno abierto.

El diseño original y abierto permitía que cada host fuera accesible desde cualquier otro host, lo cual estaba bien cuando Internet era una comunidad pequeña y de confianza.

Pero a medida que crecía, los ataques, los intentos de piratería y las actividades maliciosas se disparaban.

Fuente:emailtray.com

Del mismo modo, sin alguna forma de mantener justo el uso del ancho de banda, algunas aplicaciones aprendieron a empujar los límites y obtener una ventaja a expensas de otros.

Estas brechas de diseño empujaron a Internet hacia una mayor regulación y control.

Para proteger las redes internas, las organizaciones implementaron firewalls para bloquear las conexiones entrantes. La traducción de direcciones de red (NAT) aísla aún más las máquinas internas detrás de una única dirección IP compartida.

Esto limitó la naturaleza de igual a igual de las comunicaciones.

Los hosts detrás de NAT y firewalls fueron efectivamente forzados a un papel solo de cliente, ya no directamente accesibles desde el mundo exterior.

Con el tiempo, estas decisiones de infraestructura se reforzaron mutuamente.

La Emergencia de gatekeepers

“Un puñado de empresas se dio cuenta de que controlar los centros de datos y poseer infraestructuras masivas de servidores les brindaba enormes ventajas competitivas.”

La complejidad y el costo de ejecutar su propio servidor desde casa, junto con barreras técnicas como NAT y firewalls, significaron que menos personas participaron como pares reales.

En otras palabras, el entorno prácticamente empujó a la Red hacia un puñado de gigantes centralizados.

A principios de la década de 2000, un puñado de empresas se dieron cuenta de que controlar los centros de datos y poseer infraestructuras de servidores masivas les otorgaba enormes ventajas competitivas.

Podrían proporcionar servicios más rápidos, confiables y convenientes que un par aleatorio en la red.

Esta tendencia estaba en esteroides a finales de los años 2000.

Fuente:datareportal.com

Los motores de búsqueda como Google, las grandes plataformas como Amazon, los gigantes de las redes sociales como Facebook y las redes de distribución de contenido construyeron infraestructuras masivas que entregaron contenido y aplicaciones a una velocidad y escala sin precedentes.

Estas grandes empresas también se sumaron al “ciclo virtuoso” de datos y algoritmos.

Cuanto más usuarios atrajeron, más datos recopilaron, lo que les permitió refinar sus productos, personalizar experiencias y dirigir anuncios de manera más precisa. Esto hizo que sus servicios fueran aún más atractivos, atrayendo a más usuarios y más ingresos.

Luego, el modelo de ingresos de Internet se inclinó fuertemente hacia la publicidad dirigida.

Con el tiempo, este ciclo de retroalimentación concentró aún más el poder, ya que los competidores más pequeños lucharon por igualar la inversión en infraestructura y las ventajas de datos de los grandes jugadores.

La infraestructura que antes podía ejecutarse desde un servidor personal o un centro de datos local se trasladó cada vez más a la nube.

Gigantes como Amazon (AWS), Microsoft (Azure) y Google Cloud ahora alojan la infraestructura principal de gran parte de Internet. Este cambio ocurrió porque ejecutar infraestructura a gran escala, segura y confiable se volvió tan complejo y costoso en términos de capital que solo unas pocas empresas pueden hacerlo de manera eficiente.

Las startups e incluso las empresas establecidas encontraron que era más barato y más sencillo depender de estos grandes proveedores de nube.

Servicios como CDNs (como Cloudflare o Akamai) y resolutores DNS también se han inclinado hacia unos pocos actores importantes.

Las ventajas de complejidad y costos de estas soluciones administradas significaron menos razones para que las organizaciones “construyeran su propia” infraestructura.

Gradualmente, los cimientos descentralizados como pequeños proveedores de servicios de Internet, alojamiento independiente y enrutamiento localizado dieron paso a un modelo en el que la mayoría del tráfico y los servicios dependen de un número reducido de intermediarios principales.

El Después: El Poder Concentrado en Pocas Manos

“Los grandes jugadores no comenzaron siendo malvados; simplemente se optimizaron para la conveniencia, el rendimiento y la ganancia.

Fue el resultado natural de las elecciones de diseño arquitectónico tempranas en la red subyacente.

Con la escala y la centralización llegó más poder y control.

Las grandes plataformas establecen sus propios términos de servicio, determinando qué contenido pueden ver o publicar los usuarios y cómo se recopilarán o venderán sus datos. Los usuarios tenían menos alternativas si no les gustaban estas políticas.

Con el tiempo, los algoritmos de recomendación y las políticas de contenido de estas plataformas se convirtieron en árbitros de facto del discurso público.

Paradójicamente, lo que comenzó como una red abierta y descentralizada que permitía un intercambio libre de ideas y contenido, ahora a menudo canaliza información a través de unos pocos gateways corporativos.

Ahora estas empresas, en algunos aspectos, ejercen un poder comparable al de los gobiernos: pueden dar forma al discurso público, influir en el comercio y controlar ecosistemas enteros de desarrolladores de terceros.

Una red originalmente diseñada para la interconexión libre y de igual a igual ahora orbita alrededor de potentes centros corporativos que pueden dar forma y controlar gran parte de la experiencia en línea.

Esto no fue algún gran plan para concentrar el poder. Tampoco esta situación se originó a partir de un solo ‘giro equivocado’.

Los grandes jugadores no empezaron siendo malvados; simplemente optimizaron la conveniencia, el rendimiento y el beneficio. Fue el resultado natural de las elecciones de diseño arquitectónico tempranas en la red subyacente.

Estas opciones no anticiparon cómo un público mucho más amplio y con un enfoque más comercial usaría el sistema y lo llevaría más allá de sus parámetros de diseño iniciales.

Con el tiempo, estas opciones se acumularon en un sistema en el que unas pocas empresas dominan.

Lo mismo está sucediendo ante nuestros ojos en la industria descentralizada.

El camino hacia la centralización está pavimentado con soluciones “temporales”

“La atracción hacia la centralización no siempre es el resultado de una intención maliciosa; a menudo, es un intento de solucionar problemas de un sistema que nunca se construyó para mantenerse descentralizado a gran escala.”

Al igual que Internet en sus inicios se alejó de sus ideales de pares y se desvió hacia las manos de algunos grandes actores, las tecnologías blockchain y ‘descentralizadas’ de hoy corren el riesgo de seguir el mismo camino.

Esto es más fácil de ver con los intentos de Ethereum de escalar.

Las altas tarifas y la baja capacidad de procesamiento llevaron a los desarrolladores a adoptar soluciones de Capa-2 (L2): rollups que agrupan transacciones fuera de la cadena y luego las liquidan en Ethereum. En teoría, estos L2 deberían conservar la naturaleza sin confianza de Ethereum.

En la práctica, muchos dependen de un único “secuenciador” (un servidor central que ordena las transacciones) administrado por una empresa.

Ahora mismo, una solución L2 en particular tiene la mayor actividad y valor total bloqueado, sin embargo, también es la más centralizada,

La idea es que la descentralización llegará algún día, pero hemos escuchado eso antes.

Con el tiempo, estas soluciones “temporales” tienen la forma de volverse permanentes. El mismo patrón puede surgir con enfoques futuros; algunos ni siquiera se molestan en prometer algún camino hacia la descentralización.

“Los inicios de sesión sociales” pueden parecer útiles: facilitan que las personas comiencen a usar un servicio sin tener que manejar claves privadas o interfaces complicadas. Pero si estos inicios de sesión dependen de un componente centralizado, una vez más estás confiando en una empresa para que haga lo correcto.

Por eso, cuando construimos zkLogin, lo construimos e integramos de manera confiable. Fue difícil, pero no podemos comprometernos e introducir centralización por conveniencia.

Surgió un patrón similar en el ecosistema NFT.

Un único mercado dominante se convirtió en el lugar principal para las ventas secundarias, capturando la mayor parte del volumen de negociación y convirtiéndose efectivamente en la plataforma de facto.

Hace poco tiempo, este mercado decidió dejar de aplicar pagos de regalías en las ventas secundarias.

Sí, aumentó el volumen de negociación, pero perjudica a los creadores que dependían de esos derechos de autor como una fuente clave de ingresos.

Este es un claro ejemplo de las consecuencias cuando las plataformas centralizadas pueden modificar las reglas en cualquier momento que deseen.

Su dominio también se extendió más allá del comercio, ya que muchos proyectos también dependían de sus API e infraestructura.

Cuando esta plataforma centralizada sufrió interrupciones, todo el ecosistema sintió el impacto, exponiendo la fuerte dependencia que se había formado.

Pero ¿por qué sigue pasando esto?

Porque los usuarios desean experiencias rápidas, económicas y fáciles. Los desarrolladores, bajo presión, a menudo recurren a soluciones familiares y confiables. Estas opciones son más simples y rápidas, pero pueden introducir puntos de control que socavan la descentralización.

Ninguno de estos pasos comienza como grandes planes para monopolizar. Solo son respuestas prácticas a desafíos técnicos y de mercado difíciles.

Pero con el tiempo, estos “parches” se integran en el ADN del sistema, creando una estructura en la que unos pocos jugadores tienen las llaves.

Es por eso que estos sistemas deben ser diseñados desde cero para los constructores, no solo para los consumidores.

Construyendo para constructores, no solo para consumidores

“Si le hubiera preguntado a la gente qué querían, habrían dicho caballos más rápidos”.

La mayoría de los consumidores solo quieren una versión mejor de lo que ya tienen.

Pero cuando solo perseguimos estas mejoras a corto plazo, corremos el riesgo de terminar con sistemas que parecen descentralizados en la superficie pero aún tienen algunos actores clave tirando de las cuerdas.

Si realmente queremos evitar repetir los errores que llevaron a los guardianes digitales de hoy, debemos enfocarnos en los creadores del futuro, los constructores, no solo en los consumidores.

Por eso siempre les digo a mi equipo que los consumidores siempre pedirán un caballo más rápido; son los constructores los que imaginan el automóvil.

0:00 / 0:38

Con los bloques de construcción adecuados, los desarrolladores pueden lanzar plataformas que no se vean obligadas a centralizarse por conveniencia. Pueden crear sistemas en los que ninguna entidad individual pueda dominar o encerrar a los usuarios, asegurando que los beneficios fluyan de manera más equitativa a todos los participantes.

Es por eso que estos sistemas deben ser diseñados desde cero para reforzar la descentralización, incluso cuando tienen que escalar a nivel de internet.

Deuda técnica vs Deuda de diseño

“La deuda técnica se puede solucionar con refactorización; la deuda de diseño a menudo requiere un reinicio total.”

Desde mis primeros años trabajando en sistemas que se escalaban a miles de millones de usuarios, una lección se quedó conmigo: una vez que un sistema se vuelve crítico para la misión, no puedes simplemente derribarlo y reconstruirlo sin causar una interrupción masiva.

Cuando millones de usuarios dependen de los comportamientos y suposiciones arraigados en su sistema, incluso proponer cambios arquitectónicos radicales se convierte en algo imposible de empezar.

Rompería aplicaciones, modelos de negocios y la confianza de comunidades enteras construidas sobre ellas.

Este es el concepto de “deuda de diseño” en su forma más severa.

Esto no se trata solo de la limpieza del código; se trata de elecciones arquitectónicas fundamentales que dictan cómo fluyen la confianza, el poder y el valor a través de la red.

En los primeros días de esta industria, lo que se denomina “trilema de la cadena de bloques o de la escalabilidad”, la idea de que no se puede tener descentralización, seguridad y escalabilidad al mismo tiempo, se trataba como una ley de la naturaleza.

La gente se construyó sobre esa suposición, creyendo que era tan inmutable como la gravedad. Pero no lo era.

Se originó a partir de arquitecturas iniciales defectuosas: estados compartidos globales masivos, modelos de datos limitados que hacían imposible la paralelización y la escalabilidad modular.

La única forma de avanzar es agrupar todas las transacciones juntas, obligando a todos los participantes a luchar por los mismos recursos limitados, independientemente de lo que estén haciendo. ¿El resultado? Subastas ineficientes para el espacio de bloque que aumentan los costos durante los picos de demanda y no logran aislar la congestión donde realmente ocurre.

Bajo estas condiciones, agregar capas (como L2 que dependen de secuenciadores centralizados o activos comprimidos que dependen de almacenamiento centralizado) solo tapaba las grietas.

Cada parche que tiene como objetivo solucionar problemas a corto plazo a menudo agrega más complejidad y más puntos de control centralizado, alejándose aún más de la visión original.

Así es como la deuda de diseño se acumula en una forma de “gravedad técnica” que atrae todo hacia la centralización.

Incluso los sistemas que nunca pretendieron ser porteros terminan reforzando las estructuras jerárquicas porque su arquitectura fundamental lo exige. Una vez que eso sucede, el camino de regreso a un estado verdaderamente descentralizado y sin confianza está bloqueado por intereses arraigados e inercia infraestructural.

La lección es clara: debes obtener la arquitectura correcta desde el principio.

Eso significa elegir modelos de datos que no incluyan todo en un único estado global, utilizar soluciones de almacenamiento verificables sin confiar en un intermediario, y seleccionar una capa de red que no dependa de un puñado de intermediarios poderosos.

Se trata de reimaginar toda la pila tecnológica desde el primer día.

Obteniendo los Fundamentos Correctos Desde el Primer Día

“La única verdadera cura para la deuda de diseño es no acumularla en primer lugar.”

Cuando hablamos de construir una infraestructura que no pueda ser malvada, realmente estamos hablando de tomar las decisiones arquitectónicas correctas desde el primer día.

Por eso, cuando diseñamos Sui, quisimos incorporar esos principios fundamentales desde el primer día.

Esto permite a los desarrolladores construir aplicaciones escalables, seguras y amigables para el usuario sin hacer esfuerzos adicionales ni depender de muletas centralizadas.

Considera el propio modelo de programación:

El enfoque centrado en objetos de Sui es una salida deliberada de los paradigmas basados en cuentas que han dominado muchas blockchains.

Modelo de programación centrado en objetos

En el núcleo de la filosofía de diseño de Sui se encuentra el modelo de programación centrado en objetos.

En un mundo donde los desarrolladores de Web2 naturalmente piensan en términos de objetos, como archivos, registros y activos, no tiene sentido reducir todo a un modelo de cuenta monolítico.

Hacerlo obliga a los desarrolladores a adoptar patrones de pensamiento poco naturales. Introduce complejidad que está lista para errores.

El modelo de programación centrado en objetos se alinea de forma natural con la forma en que los ingenieros de Web2 ya razonan sobre el software.

Los objetos sirven como ciudadanos de primera clase, lo que hace que sea simple representar activos, definir reglas y evitar problemas comunes, como errores de reentrada, sin código redundante y complicado.

Este modelo familiar reduce drásticamente la sobrecarga conceptual y los problemas comunes como la reentrancia. En lugar de escribir verificaciones de plantilla o barreras de protección complejas para prevenir exploits, los desarrolladores confían en Move VM para garantizar la seguridad a nivel de tiempo de ejecución.

Como resultado, el código es más legible, seguro y más fácil de entender.

Es un puente directo desde la mentalidad orientada a objetos de Web2 hasta el entorno sin confianza de Web3, posible gracias a partir de las suposiciones correctas desde el principio.

Escalando por Diseño, No por Cinta Adhesiva

Pero un gran modelo de programación no significa nada si se desmorona bajo carga.

Desde el principio, Sui fue construido para manejar cargas del mundo real. Fue diseñado para escalar horizontalmente manteniendo composabilidad atómica síncrona.

El modelo de objeto del sistema le da a Sui una comprensión detallada de qué partes del estado toca cada transacción, lo que permite la ejecución paralela a gran escala. Esto contrasta fuertemente con los sistemas basados en EVM, que deben bloquear todo el estado global. Esto ralentiza todo y fomenta soluciones centralizadas para descargar el volumen de transacciones.

Con Sui, cada objeto es efectivamente su propio fragmento. ¿Necesitas más capacidad? Agrega más potencia computacional para manejar la carga.

El prototipo de Pilotfish :https://blog.sui.io/pilotfish-execution-scalability-blockchain/

Los desarrolladores no tienen que preocuparse por la lógica de fragmentación, conectar múltiples dominios o armar la infraestructura para lograr escala.

Entonces, ¿cómo se puede manejar más tráfico a medida que crece la red, pero cómo se asegura una asignación justa de recursos?

Si un activo popular o dApp acapara el mercado de las actualizaciones de estado, puede aumentar los costos y degradar la experiencia para todos los demás.

En lugar de depender de una única subasta global para el espacio de bloque, donde una aplicación popular puede aumentar los precios para todos, los mercados locales de tarifas permiten que el sistema fije el precio de los recursos a un nivel más fino de granularidad.

Cada ‘objeto’ o fragmento puede tener su propio mercado de tarifas, asegurando que la congestión en una zona no se derrame y penalice partes no relacionadas de la red.

Todo está integrado en el diseño fundamental de la plataforma, asegurando que incluso a medida que aumenta la demanda, el sistema no vuelva a los aburridos patrones de guardianes y jardines amurallados.

Diseñar para la descentralización también significa construir la verificación directamente en las capas de almacenamiento y comunicación.

Si el almacenamiento de datos depende de una sola parte de confianza, vuelves a estar en el punto de partida. Necesitas soluciones de almacenamiento que permitan a cualquiera verificar la integridad de los datos sin depender de un intermediario.

Almacenamiento verificable sin hosts centralizados

Una aplicación verdaderamente descentralizada no puede depender de un único proveedor de nube o de una base de datos centralizada.

Walrus proporciona una capa de almacenamiento descentralizada y verificable comparable en poder y escala a ofertas centralizadas como AWS o Google Cloud.

Con Walrus, la verificabilidad de los datos no es una idea secundaria, sino una propiedad intrínseca.

Al integrar una capa de almacenamiento inherentemente verificable e inmutable, Walrus garantiza que los desarrolladores puedan ejecutar sitios web, alojar datos y construir aplicaciones completamente descentralizadas sin volver a caer en los patrones centralizados que intentamos evitar.

En otras palabras, Walrus extiende la filosofía de “correcto por construcción” desde la ejecución hasta el almacenamiento, asegurando la integridad de su aplicación en cada capa.

Ahora, diseñar para la descentralización también significa que no debería detenerse en la capa de consenso o ejecución; debería extenderse hasta la red misma.

Las capas de redes no deben depender de un puñado de ISP o servicios de enrutamiento poderosos. Eso también es centralización.

Una capa de networking construida para la descentralización

La interconexión es otra pieza del rompecabezas que a menudo se pasa por alto en Web3.

El enrutamiento tradicional de Internet está controlado por unos pocos ISP, lo que introduce posibles puntos de estrangulamiento y vulnerabilidades.

SCION es un protocolo de red de próxima generación que desafía este statu quo, haciendo que el enrutamiento sea más seguro, confiable y resistente al control centralizado.

Es una arquitectura de enrutamiento segura, de múltiples caminos, entre dominios que puede funcionar al lado del internet actual. Es una reimaginación completa de cómo los datos se mueven a través de las redes, construida con seguridad, control y rendimiento integrados en su núcleo.

Al integrar SCION en Sui, nos aseguramos de que la red subyacente no sea un único punto de falla o control.

Ninguna entidad única tiene el poder de dictar el flujo de datos, y los usuarios pueden confiar en que las rutas subyacentes no serán manipuladas o monopolizadas.

Al integrar la verificabilidad y la falta de permisos en cada capa, incluyendo el modelo de datos, el almacenamiento y la red, se reduce la superficie donde los puntos de control centralizados pueden tomar el control.

No estás añadiendo la descentralización como una idea secundaria; la estás incrustando en la base.

Esta simplicidad reduce la complejidad y mantiene la puerta cerrada a soluciones “convenientes” pero centralizadas. Lo más importante es que hacer bien los fundamentos significa nunca apostar por una mentalidad de “lo arreglaremos más tarde”.

Todos los caminos conducen de vuelta al diseño de sonido

La descentralización no es una cantidad de validadores. La verdadera descentralización se trata de la arquitectura que evita que el poder se concentre en un solo lugar.

El punto de todo lo que hemos explorado es simple: si quieres un sistema que no pueda ser malvado, tienes que empezar con la arquitectura correcta.

Si comienzas con suposiciones incorrectas, ninguna cantidad de código adicional o trucos ingeniosos te salvarán.

Una arquitectura que recompensa a los guardianes. Un modelo de datos que obliga a cada actor a competir por el mismo recurso escaso. Una capa de red diseñada alrededor de centros centralizados. Eventualmente, caerás en los mismos patrones antiguos de control y jerarquía.

Por eso es tan importante el trabajo arquitectónico de base.

La descentralización no se trata solo de contar cuántos nodos tienes. La verdadera descentralización significa diseñar a nivel de raíz para que la confianza, la equidad y la verificabilidad sean imposibles de eludir.

Significa construir sistemas donde ni un puñado de ballenas ni una empresa bien financiada puedan inclinar silenciosamente el campo de juego. Se trata de asegurar que cada participante tenga una oportunidad justa y que ningún punto de estrangulamiento, ninguna decisión de diseño sutil, pueda convertirse en centralización descontrolada.

Sui es un ejemplo de lo que sucede cuando diseñas con estos principios en mente desde el primer día en lugar de intentar adaptarlos después del hecho.

Cuando toda la pila, desde el modelo de programación hasta la capa de consenso, y desde la integración de usuarios hasta la disponibilidad de datos y la capa de interconexión, refuerza la apertura y neutralidad, se crea un entorno donde los constructores y usuarios prosperan en igualdad de condiciones.

Al comenzar desde los primeros principios y hacer cumplir la descentralización en cada capa, puedes crear una infraestructura que se mantenga fiel a su ethos, sin importar cuán grande sea su crecimiento.

Constrúyelo bien desde el principio y no necesitarás prometer arreglos futuros o medidas a medias.

Tendrás una red que es inherentemente justa, resiliente y lista para servir como la base para la próxima generación de experiencias digitales.

Descargo de responsabilidad:

1. Este artículo es una reimpresión de [X]. Todos los derechos de autor pertenecen al autor original [@EvanWeb3]. Si hay objeciones a esta reimpresión, por favor contacte al Aprendizaje de la puertael equipo y ellos lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones y puntos de vista expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. El equipo de Learn de Gate realiza traducciones del artículo a otros idiomas. A menos que se mencione lo contrario, está prohibido copiar, distribuir o plagiar los artículos traducidos.