Autor: KarenZ, Foresight News
Los días 25 y 26 de junio, la producción de bloques en la red principal de Base se detuvo durante dos días consecutivos. Base realizó posteriormente un análisis y señaló que ambas interrupciones se debieron al mismo problema subyacente: un bug en la lógica de construcción de bloques del secuenciador.
Según el análisis de Base, este fallo provocó que un estado de registro obsoleto permaneciera después de que fallara la validación de una transacción, afectando al cálculo del gas de transacciones válidas posteriores. Esto, a su vez, generaba bloques con transferencias de estado inválidas, deteniendo la producción de bloques en toda la red L2. Tras la primera parada, el equipo oficial solucionó el problema con un parche y reanudó la producción de bloques. Además, durante el reinicio del clúster del secuenciador de Base se produjo una condición de carrera en el restablecimiento del motor, lo que dificultó la resincronización y fue una causa indirecta de la breve interrupción ocurrida al día siguiente.
En esa misma ventana temporal, el lanzamiento planificado de B20 en la red principal de Base también fue puesto en pausa.
El 26 de junio, Base anunció: "Debido a los recientes problemas de estabilidad de la red, retrasaremos la activación del B20 Activation Registry en la red principal para garantizar un proceso de despliegue estable".
Este paso, aparentemente conservador, indica en realidad la importancia de B20. No se trata de una actualización periférica de una aplicación, sino de la puerta de entrada a nivel de cadena que Base pretende utilizar para acoger la emisión de stablecoins, RWA y más activos. Cuanto más cerca esté esta entrada de la capa base, más importante es no solo que las funciones estén completas, sino también que la estabilidad de la red, el ritmo de las actualizaciones y el diseño de permisos puedan soportar conjuntamente la carga.
B20: La interfaz nativa de Base para emitir tokens
B20 forma parte de la actualización de red Beryl de Base. Los tres cambios principales de Beryl son: introducir B20, reducir el período de finalización de retiro con una sola prueba común de 7 a 5 días, y mejorar el almacenamiento y rendimiento de los nodos mediante Reth V2.
B20 puede entenderse inicialmente de la manera más sencilla: es la versión de Base del ERC-20, pero coloca gran parte de la lógica que normalmente los proyectos escriben, auditan y mantienen por sí mismos, dentro de los componentes nativos de Base.
Un token ERC-20 común suele consistir en un contrato inteligente desplegado por el proyecto para gestionar lógica como balances, autorizaciones, transferencias, emisión (minting) y destrucción (burning). La diferencia de B20 radica en que, aunque el token sigue teniendo una dirección en cadena y puede ser invocado por wallets, exploradores y protocolos DeFi como un ERC-20, B20 se implementa mediante un programa precompilado en Rust, no mediante un contrato inteligente EVM, por lo que es más rápido y económico.
En otras palabras, los integradores externos ven una interfaz de token compatible con ERC-20, mientras que los emisores acceden a la infraestructura de emisión de tokens integrada en Base.
Por eso B20 se denomina estándar de token nativo de Base. La documentación oficial de Base señala que B20 es la propia versión de Base del ERC-20, compatible con llamadas y eventos estándar de ERC-20 como transfer, transferFrom, approve, balanceOf y allowance; además, añade capacidades extendidas como memos (notas), mint/burn, control de acceso mediante políticas, pausa granular y soporte para ERC-2612 permit (autorización por firma).
Aquí es necesario explicar por separado el ERC-2612 permit, es decir, la capacidad de autorización por firma. En un ERC-20 normal, cuando un usuario quiere que un contrato gaste sus tokens, normalmente debe enviar primero una transacción de approve, que requiere pagar gas. El ERC-2612 permit permite a los usuarios realizar esta autorización firmando offline con su wallet; el proyecto o aplicación puede luego enviar esa firma a la cadena. El usuario no necesita enviar una transacción de approve por separado, reduciendo una operación de approve en cadena.
Si se usa una analogía más cercana a la realidad, el ERC-20 tradicional es como si cada emisor construyera su propia casa siguiendo unos planos estándar, donde la calidad de la construcción depende de su desarrollo y auditoría. B20 se parece más a que Base proporciona una estructura prefabricada unificada: la entrada, la interfaz y las funciones clave están estandarizadas. El emisor sigue decidiendo los parámetros del activo y las reglas de gestión, pero las capacidades base provienen del mismo conjunto de componentes a nivel de cadena.
Desde el punto de vista del despliegue, B20 tampoco permite a los proyectos copiar simplemente un contrato de token. Todos los tokens B20 se crean a través del precompilado singleton B20 Factory, eligiendo durante la creación la variante Asset o Stablecoin e ingresando parámetros como nombre, símbolo, administrador inicial, límite de suministro, llamada de inicialización, etc.
Por lo tanto, el enfoque de B20 no es convertir la emisión de tokens en un botón de interfaz más bonito, sino llevar el proceso de emisión de "cada proyecto escribe su propio contrato" a "Base proporciona una interfaz de emisión unificada con capacidades de política integradas". Lo que reduce son los costes de desarrollo repetitivo de funciones estándar, al mismo tiempo que integra más profundamente la emisión de activos en las actualizaciones base de la propia capa de Base.
El verdadero enfoque está en el "control": permisos, listas negras/blancas, congelación y memos
El kit de herramientas para emisores que enumera Base oficialmente incluye: compatibilidad con ERC-20, ERC-2612 permit, control de acceso basado en roles (RBAC), mint/burn, límite de suministro opcional, políticas de transferencia, capacidad de quemar (burn) balances de direcciones congeladas por políticas, y memos (notas) en transferencias.
Estas funciones pueden parecer técnicas, pero aplicadas al trabajo práctico del emisor, abordan principalmente tres tipos de problemas: quién tiene permiso para gestionar el token, qué direcciones pueden participar en las transacciones y cómo dejar un registro rastreable de las operaciones en cadena.
Primero, los permisos de gestión pueden estratificarse. Quién puede hacer mint (emitir), burn (destruir), pausar transferencias, reanudar transferencias o modificar metadatos, no necesita mezclarse bajo un único permiso de administrador. La documentación de B20 enumera roles como administrador por defecto, minter, burner, pauser, resumer y gestor de metadatos. De esta manera, los emisores pueden asignar diferentes operaciones a diferentes roles, reduciendo el riesgo de que una única clave privada o administrador tenga demasiado poder.
Segundo, el ámbito de circulación del token puede restringirse mediante políticas. El Policy Registry de B20 admite listas blancas y listas negras. Los emisores pueden restringir por separado las direcciones remitentes de las transferencias, las direcciones receptoras de las transferencias y, en escenarios de transferFrom, a la parte que inicia la transferencia en nombre de otro; en escenarios de mint, también pueden restringir la dirección receptora de los nuevos tokens acuñados. En resumen, B20 puede controlar "quién envía, quién recibe, quién inicia una transferencia en nombre de otro" y también "a quién se entregan los nuevos tokens". Estas capacidades son especialmente importantes para stablecoins, RWA y activos sujetos a regulación, ya que estos activos suelen requerir direcciones con KYC, receptores restringidos, congelación y rutas de disposición posteriores.
Tercero, las operaciones en cadena pueden dejar un índice para el negocio. B20 admite memos, un campo de notas bytes32 adjunto a las operaciones con tokens. No sustituye un libro mayor off-chain completo, pero puede servir como punto de conexión entre la transacción on-chain y los registros off-chain. Por ejemplo, un pago on-chain puede corresponder a un número de pedido, un reembolso a una liquidación en backend, o una emisión a un lote de registros de distribución; el memo puede ayudar a emisores, wallets, custodios o servicios de indexado a emparejar esta información.
Resumen
Es importante aclarar que B20 solo pone las herramientas a disposición del emisor, no realiza automáticamente el cumplimiento normativo (compliance) por él. Cada ámbito de política se establece por defecto como ALWAYS_ALLOW durante la creación del token, es decir, permite todo por defecto. Si el emisor no configura activamente listas blancas, listas negras u otras restricciones, ese token B20 circulará libremente como un token abierto común.
En otras palabras, B20 otorga al emisor la capacidad de "establecer reglas", pero si se establecen reglas y cómo se configuran, sigue siendo responsabilidad del emisor.
Esto también explica por qué B20 está dirigido principalmente a emisores de stablecoins, creadores de tokens RWA y otros activos tokenizados. Las stablecoins necesitan capacidades de permiso y congelación, los RWA requieren restricciones de transferencia y mapeo con registros off-chain, y otros activos necesitan costes de emisión estandarizados más bajos. Estas tres demandas, aunque aparentemente diferentes, apuntan en el fondo al mismo problema: si una L2 puede proporcionar una base suficientemente unificada, suficientemente controlable y que a la vez pueda integrarse sin problemas en el ecosistema ERC-20 existente.
