La cadena de retransmisión es la parte central de la red Polkadot, que contiene la lógica principal de la red. Es necesario que la cadena de retransmisión asuma esta lógica central antes de que la parachain pueda comenzar a funcionar y se pueda desarrollar XCM. Pero con el paso del tiempo, ahora se puede considerar que estas lógicas centrales se han migrado a la parachain del sistema. Como resultado, el Dr. Gavin Wood y Joe Petrowski de la Fundación Web3 iniciaron RFC-32, proponiendo migrar la lógica de múltiples subsistemas de la cadena de retransmisión a la "parachain del sistema" que juntos forman toda la red Polkadot.
Entonces, ¿por qué descomponer parte de la lógica de la cadena de retransmisión en parachains del sistema? ¿Qué características se desglosan primero? ¡Echa un vistazo a la información importante recopilada por PolkaWorld a continuación!
¿Por qué quieres hacer esto? **
La red Polkadot está diseñada para escalar y permitir que múltiples máquinas de estado independientes (es decir, parachains) funcionen bajo una garantía común de seguridad y validez. Para lograr esta garantía, la Relay Chain cuenta con una colección de validadores que son los principales responsables de la seguridad de la Relay Chain. Sin embargo, no todos los validadores se ocupan directamente de las transiciones de estado de las parachains. Cada transición de estado de la parachain es manejada por un subconjunto de validadores, llamado grupo de respaldo. Esto significa que no todos los validadores se ocupan directamente de todas las transiciones de estado de la parachain, solo un subconjunto de ellos es responsable de manejar las transiciones de estado.
Pero cuando se producen transiciones de estado en la cadena de retransmisión, todos los validadores deben participar en la ejecución para garantizar la coherencia y la seguridad de la red. Sin embargo, un efecto secundario de este diseño es un cuello de botella en el rendimiento, ya que cada cambio de estado requiere una validación en toda la red, lo que aumenta la latencia y limita el rendimiento.
Pero si la transición de estado de la cadena de retransmisión se puede realizar en la parachain, esto liberará algunos recursos. Esto significa que la parte de los recursos del validador que de otro modo se utilizaría para las transiciones de estado de la cadena de retransmisión se puede reutilizar, proporcionando a la red más tiempo de núcleo, es decir, más espacio de bloque.
En general, hay varias razones principales para migrar parte de la lógica de la cadena de retransmisión a la parachain del sistema:
Rendimiento y escalabilidad: Al migrar cierta lógica y responsabilidades a una parachain del sistema, la cadena de retransmisión puede centrarse en sus responsabilidades principales, mejorando el rendimiento y la escalabilidad de la red en general.
Optimización de recursos: Cuando parte de la lógica se migra a la parachain del sistema, la cadena de retransmisión puede liberar más recursos para otras tareas, como el procesamiento de mensajes entre cadenas o proporcionar seguridad a más parachains.
Modularidad y flexibilidad: El diseño modular facilita la modificación, actualización o adición de nuevas funciones sin interferir con el funcionamiento principal de la cadena de relés. Esto proporciona una mayor flexibilidad para la innovación futura y la expansión de funciones.
Seguridad: Separar partes de la lógica de la cadena de retransmisión reduce el riesgo de un único punto de fallo. En una parachain de sistema separada, si una parachain es atacada o falla, es poco probable que afecte a la cadena de retransmisión u otras parachains.
Más oportunidades de parachain: Al liberar los recursos de la cadena de retransmisión, la red Polkadot puede soportar más uniones de parachains, ampliando aún más su ecosistema.
Optimización de características específicas: A medida que Polkadot evoluciona, algunas características o lógica pueden requerir optimizaciones especializadas o métodos de procesamiento especializados. Trasladar estas funciones a parachains de sistemas especializados garantiza que se procesen y optimicen de forma óptima.
**¿Qué funciones se desglosarán en parachains del sistema? **
Los siguientes módulos y subsistemas son opciones posibles para migrar fuera de la cadena troncal:
1.Identidad
Saldos
Staking (Staking)
Huelga
Proveedor de elecciones
Lista de bolsas
NIS
Grupos de nominaciones
Eliminación rápida de staking
Gobernanza
Tesorería y recompensas
Votación por condena
Referéndum
Nota: Los módulos actuales de subastas y crowdlending ya no se utilizarán, sino que serán reemplazados por un nuevo sistema llamado Coretime. Los detalles sobre la cadena de sistemas de Coretime y sus interfaces se describen en RFC-1 y RFC-5, respectivamente. Polkadot Fellowship también está desarrollando parachains Coretime. Para obtener más información sobre el progreso de Polkadot, consulte Progreso del 3º trimestre de Polkadot: se lanzaron 5 nuevas parachains, USDC entra en el ecosistema, el stake, las cuentas segregadas y los eventos on-chain crecen significativamente.
¿Cómo puedo migrar? **
Algunos subsistemas se pueden migrar de la cadena de retransmisión a otras ubicaciones de forma relativamente sencilla. Usando la autenticación como ejemplo, simplemente puede bloquear los cambios de estado en la cadena de retransmisión y establecer el estado inicial para la nueva cadena utilizando el estado asociado con la autenticación. Este estado inicial y la lógica asociada, o módulos, se utilizan para iniciar una nueva cadena.
Sin embargo, hay subsistemas que no pueden tener ningún tiempo de inactividad durante el proceso de migración porque son críticos para el buen funcionamiento de toda la red, como el staking y la gobernanza. Aun así, estos subsistemas críticos pueden coexistir con otras cadenas de sistemas con permisos similares durante algún tiempo. Al igual que "Gov1" y "OpenGov" coexistieron cuando se introdujo este último.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
GavinWood propone minimizar la cadena de relés
La cadena de retransmisión es la parte central de la red Polkadot, que contiene la lógica principal de la red. Es necesario que la cadena de retransmisión asuma esta lógica central antes de que la parachain pueda comenzar a funcionar y se pueda desarrollar XCM. Pero con el paso del tiempo, ahora se puede considerar que estas lógicas centrales se han migrado a la parachain del sistema. Como resultado, el Dr. Gavin Wood y Joe Petrowski de la Fundación Web3 iniciaron RFC-32, proponiendo migrar la lógica de múltiples subsistemas de la cadena de retransmisión a la "parachain del sistema" que juntos forman toda la red Polkadot.
Entonces, ¿por qué descomponer parte de la lógica de la cadena de retransmisión en parachains del sistema? ¿Qué características se desglosan primero? ¡Echa un vistazo a la información importante recopilada por PolkaWorld a continuación!
¿Por qué quieres hacer esto? **
La red Polkadot está diseñada para escalar y permitir que múltiples máquinas de estado independientes (es decir, parachains) funcionen bajo una garantía común de seguridad y validez. Para lograr esta garantía, la Relay Chain cuenta con una colección de validadores que son los principales responsables de la seguridad de la Relay Chain. Sin embargo, no todos los validadores se ocupan directamente de las transiciones de estado de las parachains. Cada transición de estado de la parachain es manejada por un subconjunto de validadores, llamado grupo de respaldo. Esto significa que no todos los validadores se ocupan directamente de todas las transiciones de estado de la parachain, solo un subconjunto de ellos es responsable de manejar las transiciones de estado.
Pero cuando se producen transiciones de estado en la cadena de retransmisión, todos los validadores deben participar en la ejecución para garantizar la coherencia y la seguridad de la red. Sin embargo, un efecto secundario de este diseño es un cuello de botella en el rendimiento, ya que cada cambio de estado requiere una validación en toda la red, lo que aumenta la latencia y limita el rendimiento.
Pero si la transición de estado de la cadena de retransmisión se puede realizar en la parachain, esto liberará algunos recursos. Esto significa que la parte de los recursos del validador que de otro modo se utilizaría para las transiciones de estado de la cadena de retransmisión se puede reutilizar, proporcionando a la red más tiempo de núcleo, es decir, más espacio de bloque.
En general, hay varias razones principales para migrar parte de la lógica de la cadena de retransmisión a la parachain del sistema:
**¿Qué funciones se desglosarán en parachains del sistema? **
Los siguientes módulos y subsistemas son opciones posibles para migrar fuera de la cadena troncal:
1.Identidad
Saldos
Staking (Staking)
Huelga
Proveedor de elecciones
Lista de bolsas
NIS
Grupos de nominaciones
Eliminación rápida de staking
Tesorería y recompensas
Votación por condena
Referéndum
Nota: Los módulos actuales de subastas y crowdlending ya no se utilizarán, sino que serán reemplazados por un nuevo sistema llamado Coretime. Los detalles sobre la cadena de sistemas de Coretime y sus interfaces se describen en RFC-1 y RFC-5, respectivamente. Polkadot Fellowship también está desarrollando parachains Coretime. Para obtener más información sobre el progreso de Polkadot, consulte Progreso del 3º trimestre de Polkadot: se lanzaron 5 nuevas parachains, USDC entra en el ecosistema, el stake, las cuentas segregadas y los eventos on-chain crecen significativamente.
¿Cómo puedo migrar? **
Algunos subsistemas se pueden migrar de la cadena de retransmisión a otras ubicaciones de forma relativamente sencilla. Usando la autenticación como ejemplo, simplemente puede bloquear los cambios de estado en la cadena de retransmisión y establecer el estado inicial para la nueva cadena utilizando el estado asociado con la autenticación. Este estado inicial y la lógica asociada, o módulos, se utilizan para iniciar una nueva cadena.
Sin embargo, hay subsistemas que no pueden tener ningún tiempo de inactividad durante el proceso de migración porque son críticos para el buen funcionamiento de toda la red, como el staking y la gobernanza. Aun así, estos subsistemas críticos pueden coexistir con otras cadenas de sistemas con permisos similares durante algún tiempo. Al igual que "Gov1" y "OpenGov" coexistieron cuando se introdujo este último.