Pactus Berlin: lo que conserva un anclaje vigente

Publicar software no equivale a cambiar el protocolo

El 28 de octubre de 2026, Pactus publicó la versión 1.17.0, llamada Berlin. Su anclaje nativo de estado da a una cuenta un lugar donde conservar un compromiso vigente con datos externos. La versión y su implementación están disponibles, pero PIP-50 condiciona la función al protocolo v5. Este artículo examina el diseño publicado y el código distribuido; no establece de forma independiente que la red principal haya pasado a v5.^[1][2][3]

PIP-51 indica que un proponente eleva la versión del bloque cuando el soporte anunciado que observa supera el 75% del poder del comité, no el 75% del número de nodos. PIP-50 precisa que es una regla de transición del proponente, no una prueba de validez del bloque basada en la estimación local de cada nodo. Esas estimaciones pueden diferir. Los nodos aceptan bloques v5 válidos y certificados; para producir el certificado necesario, más de dos tercios del poder del comité deben ejecutar software compatible con v5. Una etiqueta de versión o un porcentaje de soporte, por sí solos, no prueban que la transición haya terminado.^[3][4]

Una declaración vigente, no otro recibo

El memo de una transacción puede mostrar que una cuenta registró un resumen en el pasado. Eso no responde si todavía lo respalda. PIP-50 añade un anclaje opcional al estado actual de la cuenta, cubierto por el árbol de Merkle de cuentas existente y la raíz global del estado. Un nodo que haya podado cuerpos de transacciones antiguos aún puede leer esa ranura vigente.^[3]

La ranura contiene un hash de longitud acotada, una ubicación opcional de datos externos, una indicación de tipo, el depósito bloqueado y los campos de creación y actualización. No guarda el documento, una base de datos de la aplicación ni un índice de búsqueda. Por ejemplo, una aplicación que use un manifiesto de servicio podría cotejar el documento externo con el compromiso actual de la cuenta, en lugar de tratar una transacción antigua como prueba de que el manifiesto sigue vigente. Es un patrón de aplicación descrito por el PIP, no evidencia de un servicio desplegado.^[3]

El depósito corresponde a ocupar la ranura

Las reglas detalladas son más precisas que la formulación general del anuncio sobre depósitos al crear y actualizar. Crear una ranura bloquea al menos 1 PAC. Al actualizar una ya existente, el depósito adicional puede ser 0: se mantiene el bloqueo anterior y sigue aplicándose la comisión de transacción. El ejecutor de v1.17.0 solo comprueba el depósito mínimo cuando no existe un anclaje. Al eliminar la ranura, devuelve el depósito bloqueado menos la comisión de eliminación. Es un bloqueo reembolsable por ocupar estado actual, no un interés, un rendimiento ni una promesa de operaciones gratuitas.^[3][5]

La hora del bloque no es un reloj independiente

La altura y la hora de creación proceden del bloque que crea la ranura; el firmante no puede introducir campos de tiempo arbitrarios. Los campos de actualización se refieren al bloque que fijó el hash raíz actual. Cambiar solo la ubicación, la indicación de tipo o el depósito, conservando el mismo hash, no reinicia esa fecha. Tanto PIP-50 como el ejecutor de la versión etiquetada mantienen esta distinción.^[3][5]

Eso impide que el autor de una transacción escriba sin más la fecha que prefiera en la carga del anclaje. No convierte la marca de tiempo en un reloj externo de confianza. La hora Unix procede de la cabecera del bloque del proponente y está sujeta a los límites temporales que acepte el protocolo. PIP-50 señala que la altura del bloque determina el orden. La fecha asociada al resumen debe leerse como una observación de la cadena, no como prueba independiente de un instante exacto del mundo real.^[3]

Eliminar el anclaje también borra sus fechas

La promesa de resistir la poda tiene un alcance concreto: una ranura que siga en el estado actual puede leerse sin su transacción original. Tras eliminarla, GetAnchor indica que no hay ranura activa y desaparecen sus campos de tiempo. El estado actual por sí solo no distingue una cuenta que nunca creó un anclaje de otra que lo creó y después lo eliminó. Tampoco dice cuándo se eliminó: la evidencia está en la transacción de eliminación, que un nodo podado quizá ya no conserve.^[3]

La diferencia importa para los registros de revocación. Quitar la ranura termina la declaración vigente, pero no deja allí una marca de revocación permanente y fechada. El PIP describe otro patrón para pruebas que deban sobrevivir a la poda: conservar una ranura cuya raíz actual se comprometa con un registro de revocaciones. Su significado y los datos de respaldo siguen siendo responsabilidad de la aplicación.^[3]

Un hash coincidente deja preguntas abiertas

Comparar los bytes externos con el resumen registrado permite comprobar integridad bajo la convención de hash elegida. No demuestra que las afirmaciones del documento sean ciertas, que una dirección pertenezca a una persona concreta ni que el archivo externo vaya a seguir disponible. La ubicación opcional es una entrada no confiable y el consenso no la descarga ni la interpreta. Un compromiso puede representar varios elementos mediante un árbol de Merkle externo, pero los archivos y las pruebas de inclusión siguen circulando fuera de la cadena.^[3]

También hay una diferencia entre el compromiso del estado y la respuesta que aparece en pantalla. PIP-50 no incorpora en GetAnchor una prueba contra la raíz del estado. Un cliente que consulta el RPC o explorador de otra persona confía, por tanto, en la respuesta de ese servicio; el método por sí solo no elimina esa confianza. El valor del diseño de Berlin está en separar una declaración actual de la cuenta de los recibos históricos. Leerlo con precisión exige mantener separadas la integridad del documento, la identidad, el tiempo, la disponibilidad y la procedencia de la respuesta.^[3]