BNB Chain divide el poder de los activos en 4 roles mientras los administradores mantienen la clave

La versión de prueba Jenner de BNB Chain avanza un diseño de activos nativos que otorgaría a un administrador designado por la gobernanza el control sobre cuándo se pueden crear nuevos stablecoins y activos tokenizados.

Los emisores podrían tener el código disponible en la red y aún necesitarían que se activara una función separada antes de lanzar un token CAS20.

La versión 1.8.1 programada para el 16 de octubre establece a Jenner para la prueba de BNB Smart Chain en Chapel el 29 de octubre a las 02:30 UTC. Un anuncio anterior proporciona orientación sobre la red principal a finales de noviembre, aunque la hora exacta aún no se ha anunciado.

El estándar BEP-702 propuesto sigue etiquetado como Borrador y cubre la nueva familia de tokens CAS20, mientras que los tokens BEP-20 existentes permanecerían sin cambios. Su arquitectura separa tres preguntas: si la red admite una función, quién puede ejercer los poderes de un token y qué titulares pueden verse afectados por esos poderes.

CAS20 incorporaría el comportamiento común de los tokens en la lógica de la cadena nativa, implementado como precompilaciones con estado. El mismo diseño otorga a la gobernanza de la red un papel en la disponibilidad de la infraestructura, junto con el control del emisor sobre el activo en sí.

La gobernanza controlaría la apertura

Bajo BEP-702, la gobernanza de la cadena designa al administrador de activación a través de GovHub, el contrato de reenvío de gobernanza de BSC. El administrador luego realiza llamadas separadas para activar o desactivar funciones.

La implementación de activación de la versión refuerza esa división. Solo GovHub puede cambiar al administrador, y solo el administrador almacenado y no cero puede operar los interruptores.

El diseño proporciona interruptores separados para crear tokens de variante de Activo, crear tokens de variante de Stablecoin y escribir en el registro de políticas compartido.

Una vez que se habilita una variante, la ruta de creación de la fábrica no contiene una lista de aprobación de emisores individuales. El creador proporciona el administrador inicial del token y las instrucciones de inicialización. La lista blanca de acceso anticipado para emisores de BNB Chain no debe interpretarse como prueba de que este código licencia a cada emisor por separado.

Cerrar una función de creación de tokens detendría la creación de nuevos tokens CAS20 de esa variante. No detendría a un token existente de acuñar unidades adicionales bajo sus propios permisos, transferir saldos o administrar sus roles.

Para un emisor que planea un lanzamiento, la dependencia es concreta: instalar el soporte de Jenner y activar la creación para la variante de token nativo elegida son hitos diferentes. Para un titular existente, el mismo interruptor no es un mecanismo directo para mover o congelar un saldo. Los controles CAS20 propuestos de BNB Chain dividen la autoridad en cuatro roles, con incautaciones deshabilitadas por defecto.

El registro de políticas compartido crea una segunda dependencia después de que un token existe. Un administrador de token selecciona políticas para operaciones específicas, y cada política tiene su propio administrador responsable de la membresía.

La implementación de políticas etiquetadas restringe las escrituras en el registro detrás de la activación de funciones, incluidos los cambios en la membresía de la lista y las transferencias de administrador. Un token puede seguir consultando una lista existente incluso cuando esa lista no puede ser actualizada.

Considere una cuenta ya bloqueada por una política utilizada para transferencias. Si la función del registro de políticas está deshabilitada, el administrador de la lista no puede eliminar la cuenta mientras esa puerta esté cerrada. El titular podría seguir restringido bajo la regla existente, aunque la acción a nivel de red no congeló el token ni alteró sus saldos.

El administrador predeterminado del token aún puede vincular otra política existente, porque la vinculación de políticas a nivel de token está fuera del interruptor de escritura del registro. Eso es diferente de editar la lista compartida congelada, y depende de los permisos administrativos restantes del token.

Reutilizar una lista puede simplificar las operaciones a través de varios activos, pero concentra el efecto de una decisión de membresía. Un cambio en una política compartida puede alterar la elegibilidad de la misma cuenta en cada token y operación que la referencia.

Reemplazar al administrador de activación de la red restauraría el control del interruptor, pero por sí solo no corregiría una entrada de lista. Reabrir las escrituras de política y actualizar la membresía permitida son acciones separadas.

Los permisos de emisor rigen transferencias y confiscación

Dentro de un token, la administración de roles y la selección de políticas otorgan diferentes poderes. La acuñación, la auto-quema, la confiscación, la pausa y la reanudación utilizan roles separados.

Puedes asignar los poderes a diferentes direcciones o concentrarlos en la misma. La autoridad de activación de la red, la membresía de roles de token y la administración de listas de políticas siguen siendo permisos distintos incluso si una organización posee varios de ellos.

La implementación de transferencia ordinaria verifica al remitente y al receptor contra sus respectivas políticas, y verifica a un ejecutor delegado cuando mueve los fondos de otra cuenta.

La acuñación tiene una política de destinatario separada, por lo que el permiso para recibir unidades recién acuñadas no responde automáticamente a si una cuenta puede enviar tokens o actuar por otro titular.

La confiscación permitiría a un operador autorizado reasignar saldos elegibles sin el permiso del titular. Pero su configuración predeterminada protege a cada titular: otorgar un rol de confiscación por sí solo no hace que los saldos sean elegibles.

El código administrativo v1.8.1 llama a la regla del titular SEIZE_EXEMPT_POLICY. La autorización bajo ella protege la cuenta de la confiscación. En llamadas ordinarias después de la creación, la reasignación requiere que el titular falle en esa verificación de exención, además del rol de confiscación del token, una función de confiscación no pausada, un saldo suficiente y un destino válido permitido por la política del receptor de confiscación.

Cuando esos guardias pasan, seizeWithMemo elude las verificaciones de política de transferencia ordinaria y deja inalterado el suministro total. La quema, en cambio, destruye el suministro y, para las llamadas ordinarias de CAS20, toma solo los propios tokens del llamador bajo un rol separado.

Las restricciones de transferencia y la elegibilidad para la confiscación, en consecuencia, no pueden ser tratadas como intercambiables. La capacidad de una cuenta para realizar una transferencia ordinaria no determina si podría estar sujeta a una reasignación administrativa.

Pausar transferencias también no pausa la confiscación, que tiene su propia configuración de pausa y aún requiere sus otras salvaguardias.

Los controles de Cobalt de Base utilizan una separación similar de roles y elegibilidad en su estándar B20. La pregunta adicional relevante de CAS20 aquí es cómo la admisión de características a nivel de red de BNB Chain interactuaría con esos controles a nivel de token.

Los próximos hitos de BNB Chain son operativos

La página CAS20 de BNB Chain está buscando emisores de acceso anticipado y describe variantes de Stablecoin y Activo.

El arreglo de gobernanza también deja un compromiso para los emisores que adoptan lógica nativa. El código común reduce la necesidad de implementar el mismo comportamiento de token por separado, mientras que la propuesta advierte que un defecto en el cliente nativo podría afectar a múltiples tokens CAS20 y requerir otro hard fork para solucionarlo.

El fork de testnet del 29 de octubre es el próximo paso programado en el lanzamiento. Una fecha de lanzamiento de mainnet por sí sola aún dejaría preguntas separadas sobre qué dirección sostiene el rol de activación, cómo firma los cambios y qué características se han abierto.

Los lanzamientos de nuevos tokens dependerían de la admisión de características, el mantenimiento continuo de la lista compartida dependería de la disponibilidad del registro, y la exposición de los titulares a transferencias o confiscaciones dependería de los permisos y políticas que su emisor realmente configure.

Este contenido se ofrece únicamente con fines informativos generales y no constituye asesoramiento financiero, de inversión, legal ni fiscal. Cualquier evento, recompensa, promoción en línea o información relacionada que se mencione en el presente documento no debe considerarse como una recomendación, solicitud o invitación a comprar, vender, tradear o de negociar de otra manera con cualquier criptoactivo. Los criptoactivos son sumamente volátiles y pueden provocar pérdidas. La disponibilidad de los servicios, productos y eventos relacionados de WEEX puede variar según la región. Tienes la responsabilidad de asegurarte de que tu participación esté de acuerdo con las leyes y regulaciones locales vigentes.