Blockchain y BGP, ¿qué?

El título de este post puede resultar sorprendente a más de una persona, pero, conociendo la incansable actividad del IETF, nada debería sorprendernos. Actualmente el IETF mantiene actividades vinculadas, por ejemplo, a arquitecturas de datacenter asociadas a requisitos de computación de LLMs (Large Language Models) o la internet cuántica. Por supuesto, las tecnologías de registro distribuido o DLTs (Distributed Ledger Technologies) y en particular blockchain, no podían quedar fuera de su “radar”.

IETF no es el único organismo estandarizador incorporando DLTs dentro de sus iniciativas. Otros como el IEEE han definido su propio marco conceptual para estas tecnologías:

Sin embargo, volvamos al IETF. Como dos iniciativas destacadas podemos citar:

  • El grupo satp (Secure Asset Transfer Protocol) centrado en la interoperabilidad entre las redes de activos digitales. Sí, eso es, por ejemplo, pagar con bitcoins en la red Bitcoin y recibir ethers en Ethereum.

Este grupo cuenta ya con diferentes drafts en progresos como el de definición de la arquitectura básica draft-hardjono-sat-architecture o casos de uso para esta interoperabilidad entre estas redes draft-ietf-satp-usecases.

Sin embargo, el trabajo del IETF no se limita a lo anterior, sino que está trabajando en un draft de carácter informativo que contempla el uso de blockchain y “smart contracts” para la securización de políticas BGP: draft-mcbride-rtgwg-bgp-blockchain.

Estando lejos de ser un experto en blockchain, me permito algunos comentarios acerca de este documento. Como propuesta es interesante desde el punto de vista de replantearnos el modelo de RPKI que actualmente utilizamos para la protección ante “route leaks” bien intencionadas, bien accidentales, pero aún incapaz de validar AS-PATHs completos que especificaciones como ASPA esperan autenticar en el futuro. Sin embargo, deja aún muchas incógnitas abiertas que ojalá sucesivas versiones del draft vayan concretando.

El documento plantea blockchain como una alternativa al sistema de RPKI apoyado en el “trust anchor” de los RIRs. Sin embargo, tampoco promueve eliminarlo, puesto que lo considera de utilidad para autenticar a los usuarios y mineros del blockchain. Si buscamos eliminar esta dependencia de los RIRs, no lo estamos logrando con esta aproximación.

No perdamos de vista que el éxito de blockchain se fundamenta en terminar con la necesidad de depender de bases de datos centralizadas, muchas veces controladas por jugadores que influyen en el sistema de manera interesada. En este caso, ¿es el RPKI sustentado en los RIRs un problema para los operadores que dependen de ellos? Sinceramente, no lo parece en la actualidad.

El documento también deja abierto el algoritmo de consenso que este blockchain utilizaría: proof-of-work, proof-of-stake, … Queda fuera del alcance del draft.

¿Cuál sería la incentivación de los mineros que dedican recursos de computación para la generación de la cadena de bloques? En blockchains de activos digitales los incentivos son claros, pero en este escenario no parecen existir.

Por otra parte, los DLTs presentan retos específicos que comienzan a vislumbrarse en documentos como draft-trossen-rtgwg-impact-of-dlts, destacando la importancia de minimizar la latencia en la distribución dentro de la red. Hemos de esperar también evoluciones que permitan a los DLTs optimizar su funcionamiento sobre redes IP.

En definitiva, estamos ante un documento interesante que muestra de la continua innovación en el IETF que, como mucho otros antes, puede quedar en nada, pero con seguridad los esfuerzos a él dedicados repercutirán en futuras actividades. Sin embargo, no hemos de esperar que suponga ninguna disrupción en BGP ni a corto ni a medio plazo. Me atrevería incluso a decir hoy que es una solución en busca de un problema.

¡¡¡No te pierdas nuevas entradas del blog!!!

¡No hago spam! Sólo recibirás un correo cuando haya una nueva entrada en el blog.


Publicado

en

por

Comentarios

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *