Este es un editorial de opinión de Mark Jeftovic, cofundador y director ejecutivo de easyDNS Technologies Inc. y autor de “Managing Mission Critical Domains and DNS”.
Desde el momento en que descubrí Bitcoin en 2013, supe que eventualmente tendría que haber una forma de hacer referencia a las direcciones de las billeteras usando etiquetas legibles por humanos.
El gran problema con las direcciones largas de Bitcoin es que no son memorables y, a pesar de las características seudónimas o anónimas de Bitcoin, muchas veces desea poder afirmar o verificar fácilmente que la dirección de una billetera pertenece a una entidad específica: piense donaciones a una organización benéfica o un crowdfund. Esto afecta a todas las cadenas de bloques.
Como un tipo de DNS (sistema de nombres de dominio), he visto esta película antes: DNS se inventó para resolver el mismo problema con el direccionamiento IPv4. Con el tiempo, el DNS evolucionó para hacer mucho más: no solo agregó la capacidad de resolver direcciones IPv6, sino que también se usa cada vez más para transmitir metadatos sobre un espacio de nombres. Pensar Registros SRV, NAPTRlistas de bloqueo RBL, zonas de política de respuesta (RPZ) y el registro TXT ubicuo (que se usa para SPF, DMARC, DKIM y cualquier otra cosa que no se ajuste de forma nativa al protocolo).
A lo largo viene Bitcoin y tenemos el mismo problema, escrito en grande.
El problema específico de Bitcoin y Lightning
Parece que gran parte de la actividad de transacciones de pago se trasladará a la capa 2 con protocolos como Lightning y, más recientemente, la llegada de la dirección del rayo.
Las direcciones Lightning dependen en el pago LNURL protocolo, y se parecen mucho a una dirección de correo electrónico:
vía: https://github.com/andrerfneves/lightning-address/blob/master/README.md
La nomenclatura de la dirección de correo electrónico es la manera perfecta de transmitir información de identidad. Demarca fácilmente las organizaciones y las subdivide en unidades o personas dentro de ellas. Todo el mundo ya está acostumbrado a este formato y, como veremos, tiene el potencial de transmitir mucha más información que los buzones de correo de destino.
Durante años anticipé que este formato se convertiría en el estándar de facto para puntos finales de identidad con protocolo de Iniciacion de Sesion (SIP) y XMPP.
SIP y XMPP no dominaron el mundo de la manera que esperaba (al menos no todavía) y, durante un tiempo, los identificadores comenzaron a gravitar hacia plataformas centralizadas como los identificadores de Twitter y los ID de usuario de Github. Siempre encontré esto burlón, especialmente entre los Bitcoiners.
Con Lightning Addresses, vemos un camino de regreso hacia los identificadores descentralizados, ya que las direcciones de correo electrónico están descentralizadas, dentro de los límites del propio sistema DNS (más sobre esto a continuación).
Solo hay un problema: a la especificación LNURL tal como se define le falta un nivel de abstracción. Sin él, el caso de uso de direcciones de iluminación se vuelve muy limitado.
Dada la dirección Lightning:
satoshi@ejemplo.com
Eso significa que, según la especificación actual, el descriptor de pago se ubicará en:
https://example.com/.well-known/lnurlp/satoshi/
Pero, ¿y si Satoshi no tiene acceso al servidor web example.com? Si seguimos con la analogía de la dirección de correo electrónico: el hecho de que tenga esto como su dirección no significa que el servidor con el nombre de host correspondiente sea el lugar donde se entrega el correo electrónico.
De hecho, probablemente ese no sea el caso más a menudo de lo que es. Por esta razón, existe el tipo de registro MX en DNS, que agrega un nivel adicional de direccionamiento indirecto para controlar el destino del correo electrónico. Pueden dirigir la entrega de correo electrónico a nombres de host que operan bajo un nombre de dominio completamente diferente (piense en las personas que usan un proveedor de correo electrónico externo, pero con su propio dominio personalizado).
Lo mismo debe suceder con las direcciones Lightning en gran medida por las mismas razones. Es posible que el nombre de host a la derecha de ‘@’ no tenga ningún servidor web o que el usuario esté indebidamente confinado a usar una dirección Lightning donde el componente del nombre de host solo puede ser el del servidor web donde está alojado el archivo JSON. Eso puede ser un problema cuando se publica una dirección Lightning que el usuario desea cambiar en el futuro.
Como experto en DNS, la solución parecía obvia, pero fui culpable de pensar demasiado:
En 2017, lo que entonces era el Grupo de Trabajo del Servicio de Nombres de Ethereum me invitó a una reunión en Londres para elaborar la especificación del registro ENS.
Salí de esa reunión pensando que debe haber un nuevo registro de recursos de DNS, un nuevo tipo de registro que pueda hacer referencia a los recursos de la cadena de bloques desde el DNS heredado.
En mi opinión, se vería como un registro SRV o NAPTR, que tenía diferentes campos para protocolos, puertos y ponderaciones (el hecho de que los navegadores web de hoy en día aún no miren los registros SRV para direcciones web es una de las grandes oportunidades perdidas de la era de Internet).
Mi abreviatura de trabajo era “BCPTR” para “Blockchain Pointer” y tenía una especificación demasiado complicada y enrevesada para señalar exactamente a qué cadena de bloques apuntaba un registro y qué tipo de recurso era.
Luego, en el problema de Lightning GitHub, donde se discutía el LNURL RFC, alguien sugirió simplemente anteponer una dirección con el “_lud16” subdominio
El uso de guiones bajos para diferenciar ciertos atributos de nombres de los nombres de host reales ha existido por un tiempo. Se utilizó en la especificación SRV RR original. RFC2872 y luego descrito como “alcance de subrayado” en RFC 8552.
La sugerencia inmediatamente explotó en mi cerebro y me di cuenta de que había estado pensando demasiado en esto durante años.
Una etiqueta de alcance en DNS, como _tcp o _udp, no distingue entre mayúsculas y minúsculas y las vemos en registros SRV y NAPTR para uso en aplicaciones SIP, VOIP y ENUM, balanceo de carga, sin mencionar en registros TXT para DKIM y DomainKeys.
Muy bien, cualquier etiqueta DNS válida, como _lud16 o _btc, nos proporciona un mecanismo para limitar una respuesta a una consulta que coincida con el alcance, en el nodo principal del árbol DNS.
Sentido:
$ORIGIN ejemplo.com.
_ie.test IN TXT “esto es una prueba”_eg.test IN TXT “esta es una prueba separada”
Una consulta de DNS para el tipo TXT en “test.example.com” no devolverá una respuesta (NXDOMAIN).
Una consulta de DNS para el tipo TXT en “_ie.test.example.com” solamente devuelve un resultado para el primer registro.
Una consulta de DNS para el tipo TXT en “test._ie.example.com” solamente devolver el segundo registro.
En otras palabras, tenemos múltiples registros TXT para el prueba.ejemplo.com leaf, sin embargo, solo devolveremos la consultada con la etiqueta scoped, la que comienza con un guión bajo.
Resulta que esto es bastante poderoso para nuestros propósitos. También es la solución más fácil y óptima en nuestro caso de uso porque:
- Todo el mundo puede usarlo.
- Es un formato que la gente reconoce fácilmente.
- Se puede adaptar a cualquier dirección de correo electrónico existente a través de DNS.
- Proporciona la capacidad de que exista un registro json en otro lugar que no sea el servidor (como funciona un registro MX).
- Puede proporcionar cualquier tipo de carga útil.
- Puede funcionar en todas las cadenas de bloques.
Cómo se podría utilizar el alcance de subrayado en cadenas de bloques
Al tomar el formato de dirección de correo electrónico utilizado en Lightning Addresses: , podemos usar la convención a través del DNS para especificar todo tipo de puntos finales para la misma identidad:
$ ORIGEN bombthrower.com.
_lud16.markjr EN TXT “https://my.ln-node/.well-known/lnurlp/markjr“
_btc.markjr EN TXT “bc1qu059yx6ygg9e6tgedktlsndm56jrckyf3waszl”
_ens.markjr EN TXT “0xEbE7CcC5A0D656AD3A153AFA3d543160B2E9EdFb”
Podemos llegar allí desde aquí sin romper nada que ya esté en su lugar:
- Las aplicaciones que ya usan la dirección LNURL siempre pueden seguir usándola
- Las aplicaciones pueden agregar la búsqueda de DNS
¡Pero el DNS está centralizado!
Es cierto que el DNS tiene una estructura de árbol invertido que termina en la raíz “.”. Pero incluso esa raíz está bastante descentralizada y comprende miles de servidores operados por al menos 13 operadores dispares. El DNS heredado puede estar lógicamente centralizado, pero en realidad funciona más como una especie de federación descentralizada.
Incluso esto está cambiando, evolucionando. Creo que finalmente terminaremos donde los espacios de nombres se extienden a ambos lados de la raíz del árbol invertido existente y las cadenas de bloques completamente descentralizadas.
Algo de esto ya está aquí hoy: podría usar algo como Pilas y dominios .btc que se conecta a Bitcoin y probablemente habrá otros espacios de nombres creados directamente sobre Bitcoin.
No todos los espacios de nombres descentralizados tienen solucionadores de DNS heredados, pero eso también cambiará. También se está trabajando en un nuevo DNSresolvers implementación que resolverá los dominios Stacks, .btc y HNS por Handshake y los dominios de nivel superior imparables. Puede probarlo a través de búsquedas en alpha.dnsresolvers.com:
% cavar +short easydns.btc @alpha.dnsresolvers.com
3.14.49.122
(Este servidor es una prueba de concepto y desaparecerá en el futuro, por favor no lo agregues a su resolv.conf.)
¡Todo esto, y también resuelve el problema de la cuenta falsa de Twitter!
Una vez que hacemos una convención para usar el alcance de subrayado, encontramos que podemos resolver todo tipo de problemas usando los métodos existentes.
Veamos el problema del identificador falso de Twitter que afecta al espacio de Bitcoin.
La estructura de datos de un usuario de Twitter se ve así:
Con el alcance del guión bajo, podemos afirmar el verdadero identificador de Twitter del nombre de host en el elemento url usando la siguiente convención:
$ ORIGEN bombthrower.com.
stuntpope._twitter EN TXT “StuntPope”
*._twitter EN TXT “falso”
Por sí solo, esto no hace nada. Nadie va a abrir una ventana de terminal y escribir:
“dig -t TXT +pequeño stuntpope._twitter.bombthrower.com”
… para averiguar si la persona que le envía un DM le dice: “¿Cómo va su comercio hoy?” soy realmente yo, o uno de los legiones de impostores de StuntPope en Twitter. (Estoy bromeando, por supuesto, nadie en su sano juicio se haría pasar por mí. Pero para muchas de las luminarias fintwit, esto es un problema real).
Pero lo que puede suceder si esto se convierte en la convención, es que los desarrolladores pueden crear ganchos rápidos y sucios en sus aplicaciones para realizar estas búsquedas.
Cuando un perfil de Twitter falso se hace pasar por alguien, normalmente copian todos los datos palabra por palabra, incluido el nombre de host en el campo URL del perfil de Twitter. Si el usuario real tiene los registros descritos anteriormente, entonces la convención de buscar el falso identificador de Twitter en el real La URL perderá el registro TXT de _twitter real para el perfil real y golpeará el registro comodín, lo que provocará una falta de coincidencia.
Hemos lanzado una extensión de Chrome de prueba de concepto a través de la fácilDNS Githubque hace exactamente eso con tres modos:
A) No se afirma información;
B) El perfil coincide con la información afirmada;
C) El perfil no coincide con la información afirmada (es falso).
Todo esto y más se puede hacer usando convenciones muy simples en un protocolo ubicuo que ya está implementado.
Conclusión
Las direcciones de billetera se prestan a necesitar algún tipo de mecanismo de nomenclatura. Existen múltiples casos de uso en los que la necesidad de afirmar de forma segura una dirección a partir de una identidad tiene prioridad sobre el seudónimo o el anonimato.
Además, para usar etiquetas o identificadores legibles por humanos, necesitamos una capa de abstracción que brinde flexibilidad y un formato que sea fácilmente reconocible.
Finalmente, podemos lograr todo esto utilizando el DNS, que ya es la base de la infraestructura técnica de Internet, ya es una federación descentralizada y está en camino de anclarse en protocolos descentralizados de Capa 1. Podemos hacerlo sin agregar ningún tipo de registro nuevo ni agregar ningún protocolo a las especificaciones existentes.
Esta es una publicación de invitado de Mark Jeftovic. Las opiniones expresadas son totalmente propias y no reflejan necesariamente las de BTC Inc o Revista Bitcoin.
