Traducido del inglés al español - [Link].

com

Pila de bloques
Documento técnico

Muneb Ali Blockstack: una nueva Internet para aplicaciones descentralizadas

Ryan Shea [Link]

Jude Nelson Versión 1.1 del libro blanco técnico
Michael J. Freedman 12 de octubre de 2017

Copyright 2017 Blockstack PBC, una corporación de beneficio público. Todos los derechos reservados.
Partes de este documento técnico se publicaron anteriormente en las siguientes conferencias y
revistas revisadas por pares:

• M. Ali, J. Nelson, R. Shea y MJ Freedman,"Blockstack: un sistema global de nombres y

almacenamiento protegido por cadenas de bloques”, Conferencia técnica anual de
USENIX 2016, Denver, Colorado, junio de 2016.

• J. Nelson, M. Ali, R. Shea y MJ Freedman,"Ampliación de cadenas de bloques existentes

con Virtualchain”, Taller sobre criptomonedas distribuidas y registros de consenso,
Chicago, IL, julio de 2016.

• M. Ali, J. Nelson, R. Shea y MJ Freedman,"“Aumentar la confianza en sistemas

distribuidos con cadenas de bloques”, USENIX ;login: Número: Vol. 41, No. 3, Páginas
52-58, Otoño 2016.

DESCARGO DE RESPONSABILIDAD:Los tokens Blockstack son un activo criptográfico que Blockstack está desarrollando actualmente

Token LLC, una sociedad de responsabilidad limitada de Delaware, cuyo sitio web se puede encontrar en [Link].

Este documento técnico no constituye una oferta o venta de tokens Stacks ni ningún otro mecanismo de compra.

ing Stacks. Cualquier oferta o venta de tokens Stacks o cualquier instrumento relacionado se realizará únicamente en base a una decisión definitiva.

ofreciendo documentos para los tokens Stacks.

Esta comunicación puede considerarse material de “prueba de las aguas” según el Reglamento A de la Ley de Seguridad.

Ley de relaciones con inversionistas de 1933. No tenemos ninguna obligación de completar una oferta según el Reglamento A. Podemos elegir

hacer una oferta a algunas, pero no a todas, las personas que indiquen interés en invertir, y esa oferta

Es posible que no se realicen según el Reglamento A. Solo podremos realizar ventas después de la aprobación de la Bolsa de Valores.

La Comisión de Bolsa y Valores (SEC) ha “calificado” la declaración de oferta que hemos presentado ante la SEC. La información en

Esa declaración de oferta será más completa que la información que proporcionamos ahora y podría diferir en

Maneras importantes. Debe leer los documentos presentados ante la SEC antes de invertir.

No se solicita dinero ni ninguna otra contraprestación y, si se envía como respuesta, no se aceptará.

La oferta de compra de los valores puede ser aceptada y no se puede recibir ninguna parte del precio de compra hasta que se realice la oferta.

La declaración presentada por la empresa ante la SEC ha sido calificada por la SEC. Cualquier oferta de este tipo puede ser retirada.

o revocada, sin obligación o compromiso de ningún tipo, en cualquier momento antes del aviso de aceptación dado después

la fecha de calificación.

La manifestación de interés no implica obligación ni compromiso de ningún tipo.

Cualquier persona interesada en invertir en cualquier oferta de Stacks Tokens debe revisar nuestras divulgaciones y la

declaración de oferta presentada públicamente relacionada con dicha oferta, una copia de la cual está disponible en [Link].

Blockstack no está registrado, autorizado ni supervisado como corredor de bolsa o asesor de inversiones por la Secretaría de Comercio.

Comisión de Bolsa y Valores (SEC), la Autoridad Reguladora de la Industria Financiera (FINRA) o cualquier otra

autoridad reguladora financiera o autorizada para proporcionar cualquier asesoramiento o servicio financiero.
Blockstack: una nueva Internet para aplicaciones descentralizadas

Muneb Ali∗ Ryan Shea∗ Jude Nelson Michael J. Freedman†

[Link]
Versión 1.1 del libro blanco

12 de octubre de 2017

Abstracto

La Internet tradicional tiene muchos puntos centrales de falla y confianza, como (a) los servidores del Sistema
de nombres de dominio (DNS), (b) la infraestructura de clave pública y (c) los datos de los usuarios finales
almacenados en almacenes de datos centralizados. Presentamos el diseño y la implementación de una nueva
Internet, llamada Blockstack, donde los usuarios no necesitan confiar en servidores remotos. Eliminamos todos los
puntos de confianza del medio de la red y usamos cadenas de bloques para asegurar los enlaces de datos críticos.
Blockstack implementa servicios de identidad, descubrimiento y almacenamiento y puede sobrevivir a fallas de las
cadenas de bloques subyacentes. El diseño de Blockstack se basa en tres años de experiencia en un gran sistema
de producción basado en cadenas de bloques. Blockstack ofrece un rendimiento comparable a los servicios de
Internet tradicionales y permite una actualización de seguridad y confiabilidad muy necesaria para la Internet
tradicional.

1 Introducción
Internet fue diseñado hace más de 40 años y está mostrando signos de envejecimiento. Los servicios críticos de

Internet pueden quedar fuera de servicio por ataques como el ataque DDoS a los servidores DNS [1]. Además, en la

arquitectura actual de Internet, los usuarios confían implícitamente en ciertos servicios ocultos e intermediarios

como los servidores de nombres de dominio y las autoridades de certificación (CA). Estos puntos de confianza

pueden explotarse para engañar a los usuarios y hacer que se conecten a sitios web maliciosos, como el reciente

incidente en el que una CA turca emitió certificados de seguridad falsos para Google [2].

En la última década, hemos visto un cambio de las aplicaciones de escritorio (que se ejecutan localmente) a las

aplicaciones basadas en la nube que almacenan datos de los usuarios en servidores remotos. Estos servicios centralizados

son un objetivo principal para los piratas informáticos y con frecuencia son atacados. En 2016, Yahoo! admitió haber

perdido información de 500 millones de personas [3]. Problemas de seguridad con el núcleo de Internet

∗Coautor principal.
†Profesor de Ciencias de la Computación en la Universidad de Princeton y asesor de Blockstack.

1
La infraestructura y los modelos de datos centralizados de los servicios web creados sobre ella han
expuesto fallas en el diseño original de Internet.
Blockstack es un esfuerzo de código abierto para volver a descentralizar Internet; construye una nueva
Internet para aplicaciones descentralizadas y permite a los usuarios poseer directamente los datos de sus
aplicaciones [4]. Blockstack utiliza la capa de transporte de Internet existente (TCP o UDP) y los protocolos
de comunicación subyacentes y se centra en eliminar los puntos de centralización que existen en la capa de
aplicación. Blockstack puede admitir protocolos de capa de transporte alternativos, como los nuevos
protocolos de redes en malla [5].
Existen muchos desafíos técnicos fundamentales a la hora de crear un reemplazo totalmente
descentralizado para los componentes centrales de Internet, como DNS, infraestructura de clave
pública y backends de almacenamiento. Los nuevos usuarios/nodos deben establecer confianza en
la red y descubrir los datos relevantes sin depender de ningún servidor remoto. Las soluciones
descentralizadas deben ofrecer un rendimiento comparable al de Internet tradicional y escalar en
consecuencia. Nuestra implementación de Blockstack tiene tres componentes:

1. Una cadena de bloques, implementada utilizandocadenas virtuales[6], se utiliza para vincular propiedades digitales,

como nombres de dominio, a claves públicas. La cadena de bloques de Blockstack resuelve el problema de generar

confianza de manera descentralizada, es decir, un nuevo nodo en la red puede verificar de forma independiente

todas las vinculaciones de datos.

2. Una red de pares, llamadaAtlas, proporciona un índice global para la información de descubrimiento y

3. Un sistema de almacenamiento descentralizado, llamadoGea, proporciona backends de almacenamiento de

alto rendimiento sin introducir partes centrales de confianza.

Blockstack ya está implementado en producción y, hasta la fecha, se han registrado 74.000 nuevos
dominios en él y varias empresas y colaboradores de código abierto están desarrollando activamente
nuevos servicios utilizando Blockstack [4]. Hemos publicado Blockstack como código abierto [7].

2 Arquitectura del sistema

Blockstack tiene los siguientes objetivos de diseño:

[Link]ón y nombres descentralizados:Los usuarios finales deberían poder (a) registrar y utilizar
nombres legibles por humanos y (b) descubrir recursos de red asignados a nombres legibles
por humanos sin confiar en ninguna parte remota.

[Link] descentralizado:Los usuarios finales deberían poder utilizar sistemas de almacenamiento

descentralizados donde puedan guardar sus datos sin revelarlos a terceros remotos.

[Link] comparable:El rendimiento de extremo a extremo de la nueva arquitectura (incluidas las

búsquedas de nombres y recursos, el acceso al almacenamiento, etc.) debería ser comparable al de
Internet tradicional con servicios centralizados.

Hasta hace poco, se consideraba imposible construir sistemas de nombres descentralizados con nombres

legibles para humanos (ver el Triángulo de Zooko en la Sección 3) y el almacenamiento descentralizado

2
Los sistemas como BitTorrent, etc. no ofrecen un rendimiento/ancho de banda comparable a los servicios
centralizados [8]. Blockstack presenta una solución a estos problemas.

Decisión de diseño n.° 1: sobrevivir a las fallas de las cadenas de bloques subyacentes
Nuestra arquitectura no impone ninguna limitación sobre qué blockchain se puede utilizar con ella. Se puede

utilizar cualquier blockchain, siempre que proporcioneordenación total de operaciones (que es lo que hacen todas

las cadenas de bloques), pero las propiedades de seguridad y confiabilidad dependen directamente de la cadena

de bloques subyacente. Creemos que permitir la capacidademigrar El cambio de una cadena de bloques a otra es

importante porque permite que el sistema más grande sobreviva, incluso cuando la cadena de bloques subyacente

se ve comprometida. Nuestra arquitectura también permite múltiples cadenas de bloques subyacentes y trata a las

cadenas de bloques como canales de comunicación que brindan operaciones totalmente ordenadas; cualquier

cantidad de canales de comunicación subyacentes puede funcionar siempre que puedan brindar individualmente

operaciones totalmente ordenadas.

Decisión de diseño n.° 2: mantener la complejidad y la lógica fuera de las cadenas de bloques Muchas cadenas de

bloques, como Namecoin [9] o Ethereum [10], implementan tanto la lógica de control como el plano de

almacenamiento de datos a nivel de la cadena de bloques (aunque dejan abierta la posibilidad de utilizar

almacenes de datos externos en el futuro). Creemos que no utilizar cadenas de bloques para el almacenamiento de

datos es necesario para la escalabilidad y mantener la lógica compleja fuera de las cadenas de bloques es

importante tanto para la seguridad como para la escalabilidad. No se debería exigir a los nodos de la red que

calculen programas complejos no confiables solo para mantenerse sincronizados con la red. Además, es difícil

introducir nuevas características en las cadenas de bloques después de que se hayan implementado y hayan

ganado uso en el mundo real. Presentamos el concepto decadenas virtuales(Sección 4) que puede construir

máquinas de estados arbitrarios sobre cadenas de bloques sin requerir ninguna modificación de las cadenas de

bloques subyacentes. La abstracción del ordenamiento total de las operaciones, sobre las cadenas de bloques

subyacentes, funciona como la “cintura estrecha” de nuestra arquitectura y mantiene la complejidad fuera de las

cadenas de bloques.

Decisión de diseño n.° 3: índice escalable para datos globales

Cualquier red descentralizada requiere un índice de los datos que almacena. Volviendo a los primeros días
de las redes de pares, Napster introdujo un índice centralizado con transferencia de archivos
descentralizada en 1999. BitTorrent también comenzó con rastreadores centralizados (índices) y luego
introdujo índices descentralizados basados en DHT. Las redes de pares basadas en DHT son susceptibles a
ataques Sybil e históricamente han sido poco confiables y difíciles de escalar, especialmente con mucha
rotación. Experimentamos estos problemas de primera mano ya que nuestra red de pares inicial para
Blockstack se basaba en Kademlia DHT. Introdujimos una nueva red de pares no estructurada, llamada red
Atlas, que resuelve un caso particular de almacenamiento descentralizado utilizando redes de pares: el
caso en el que (a) el conjunto de datos es pequeño en tamaño y (b) hay una lista global de todos los
elementos indexados disponibles para la red. En Atlas, los nodos mantienen una réplica de estado del
100%. El enfoque no estructurado es más fácil de implementar, no tiene costos adicionales para mantener
la estructura de enrutamiento y es resistente a ataques a nodos específicos (cada nodo tiene una copia
completa de los datos).

3
 Almacenamiento
Amazon S3 Caja de caída Microsoft Azure Servidor FreeNAS Unidad de Google

Red de pares
Hash del archivo de zona Archivo de zona

Las URI en los archivos de zona

apuntan a datos almacenados

base de datos local

Nombre de dominio Clave pública Zona

Hash del archivo electrónico

Las transacciones son parsed como actualizaciones a la nombre db

BloClic cadena
norte n+1 n+2 n+3 n+4

Figura 1:Descripción general de la arquitectura Blockstack.

2.1 Capas de bloques

La arquitectura de Blockstack tiene tres capas, como se muestra en la Figura 1), con una capa (la
capa de cadena de bloques) en el plano de control y dos capas (la red de pares y el almacenamiento
de datos) en el plano de datos. El plano de control se ocupa de volúmenes de datos más pequeños y
se ocupa principalmente de generar confianza [11] y definir la correlación entre los nombres legibles
por humanos y los recursos de la red. El plano de datos contiene información sobre cómo descubrir
datos (rutas/punteros a datos) y los backends de almacenamiento reales. Los datos se replican
ampliamente y no importa de qué fuente los clientes lean los datos; los clientes pueden verificar de
forma independiente desde el plano de control si recibieron los datos correctos o no.

Capa 1: Cadena de bloques

En nuestra arquitectura, la cadena de bloques ocupa la capa más baja y cumple dos funciones: proporciona
el medio de almacenamiento para las operaciones y proporciona consenso sobre el orden en el que se
escribieron las operaciones. Virtualchain codifica las operaciones en transacciones en la cadena de bloques
subyacente. La cadena de bloques proporciona una abstracción de operaciones totalmente ordenadas a
Virtualchain y funciona como la "cintura estrecha" de nuestra arquitectura. Mucha complejidad, como las
operaciones de minería, los algoritmos de consenso, las fluctuaciones de las criptomonedas, etc., se
esconden debajo de esta abstracción. Las capas superiores solo se preocupan de leer/escribir operaciones
totalmente ordenadas y pueden operar sobre cualquier cadena de bloques.
La capa de blockchain también incluye unacadena virtual, que define nuevas operaciones sin requerir
cambios en la cadena de bloques subyacente. Nodos de las cadenas de bloques subyacentes

4
No conocen esta capa. Las cadenas virtuales son como máquinas virtuales, donde una máquina virtual específica

como Debian 8.7 puede ejecutarse sobre una máquina física específica. Se pueden definir diferentes tipos de

cadenas virtuales y se ejecutan sobre la cadena de bloques subyacente específica. Las operaciones de cadena

virtual se codifican en transacciones de cadena de bloques válidas como metadatos adicionales. Los nodos de

cadena de bloques ven las transacciones sin procesar, pero la lógica para procesar las operaciones de cadena

virtual solo existe en el nivel de cadena virtual.

Las reglas para aceptar o rechazar operaciones de cadenas virtuales se definen en la cadena virtual específica,

por ejemplo, una cadena virtual que define una única máquina de estados que implementa operaciones para un

sistema de nombres global. Las operaciones aceptadas por las reglas definidas en nuestra cadena virtual se

procesan para construir una base de datos que almacena información sobre el estado global del sistema de

nombres junto con los cambios de estado en cualquier bloque de la cadena de bloques.

Capa 2: Red de pares

Blockstack utiliza una red de pares para el descubrimiento. La red de pares es parte del plano de datos.
Nuestra arquitectura separa la tarea dedescubriendorecursos (es decir, rutas a los datos) del
almacenamiento real de datos. Esto evita la necesidad de que el sistema adopte un servicio de
almacenamiento particular desde el principio y, en cambio, permite que coexistan múltiples proveedores
de almacenamiento, incluidos los sistemas de almacenamiento en la nube y P2P.
La implementación de Blockstack utilizaarchivos de zonapara almacenar información de enrutamiento, que

son idénticos a los archivos de zona DNS en su [Link] de zonase almacenan en la capa de

descubrimiento, implementada como una red de pares por [Link] usuarios no necesitan confiar en la capa

de descubrimientoporque la integridad de cualquier registro de datos en la capa de descubrimiento se puede

verificar comprobando el hash respectivo de ese registro de datos en el plano de control.

En la implementación actual de Blockstack, los nodos forman una red de pares, llamada red Atlas (Sección 5),

para almacenararchivos de zonaLa red de pares sólo permitearchivos de zonaser escrito sipicadillo(archivo de zona

) se anunció previamente en la cadena de bloques. Esto efectivamente incluye en la lista blanca los datos que se

pueden almacenar en la red de pares. Los registros de datos que representan rutas (independientemente de

dónde se obtengan) se pueden verificar y, por lo tanto, no se pueden alterar. En la implementación actual de la red

Atlas, los nodos pares mantienen una copia completa de todosarchivos de zonadesde el tamaño dearchivos de

zonaes relativamente pequeño (4 KB por archivo). Mantener una copia completa de todos los datos de
enrutamiento solo supone un costo de almacenamiento marginal además del almacenamiento de los datos de la

cadena de bloques (que es del orden de varios GB).

Capa 3: Almacenamiento

La capa superior (capa 3) es la capa de almacenamiento, que alberga los valores de datos reales y forma parte del

plano de datos. Todos los valores de datos almacenados están firmados por una clave de propietario definida en el

plano de control. Al almacenar los valores de datos fuera de la cadena de bloques, Blockstack permite valores de

tamaño arbitrario y una variedad de backends de [Link] usuarios no necesitan confiar en la capa de

almacenamientoy puede verificar su integridad en el plano de control. Nuestro diseño se beneficia del rendimiento

y la confiabilidad de los sistemas de almacenamiento en la nube backend utilizados y ofrece un rendimiento

comparable a los servicios de Internet tradicionales.

Blockstack implementa un sistema de nombres descentralizado, llamadoNombre de la cadena de bloques

5
Sistema(BNS) definiendo operaciones en una nueva cadena virtual y almacenando datos de descubrimiento
en una red de pares llamadaRed Atlas(Sección 5). Nuestra cadena virtual utiliza la cadena de bloques
subyacente para lograr un consenso sobre el estado de BNS y vincula los nombres a los registros de datos.
Basándose en el protocolo de consenso de la cadena de bloques subyacente, nuestra cadena virtual puede
proporcionar un orden total para todas las operaciones admitidas por BNS, como registros de nombres,
actualizaciones de nombres y transferencias de nombres. Nuestra cadena virtual representa el estado
global de BNS, incluido quién posee un nombre en particular y qué datos están asociados con un nombre.
Presentamos más detalles sobre estos componentes en las siguientes secciones.

3 BNS: Sistema de nombres de blockchain

El Internet tradicional utiliza el Sistema de nombres de dominio (DNS) para asignar nombres legibles por
humanos a direcciones IP (que proporcionan la ubicación de los nodos y el contenido). Cuando los usuarios
de Internet escriben [Link] en su navegador, los servidores DNS devuelven la asignación del nombre
legible por humanos a una dirección IP. ICANN, una organización sin fines de lucro, administra el DNS y los
servidores raíz. Estos servidores son un punto central de confianza y falla; pueden quedar fuera de línea
por ataques DDoS y las asignaciones de dominios pueden modificarse ya sea forzando cambios en los
servidores DNS o falsificando respuestas de ellos.
En Blockstack, necesitamos un reemplazo descentralizado para DNS, es decir, un sistema que vincule nombres

legibles por humanos con datos de descubrimiento pero que no tenga puntos centrales de falla o control. Existe

una escuela de pensamiento que sostiene que los nombres legibles por humanos no son importantes y que los

identificadores criptográficos largos combinados con motores de búsqueda pueden reemplazar a DNS [12, 13, 14].

Consideramos que los nombres legibles por humanos son esenciales para brindar una buena experiencia de

usuario y, en la práctica, sería muy difícil convencer a los usuarios de Internet de que cambien sus hábitos y dejen

de usar nombres legibles por humanos en línea.

El desarrollo de sistemas de nombres plantea un desafío informático fundamental. Hay tres

propiedades que podríamos desear que tuviera un nombre: el nombre es (1) único (lo que significa
que no hay ninguna situación en la que dos personas puedan crear y usar independientemente un
nombre único como [Link]), (2) legible por humanos (un nombre debería ser como Paul, no
1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa) y (3) descentralizado (los nombres deberían ser elegidos
por los usuarios en los bordes de la red y no en nombre de los usuarios por una autoridad central en
el centro). El desafío informático es que, antes de las cadenas de bloques, los sistemas de nombres
solo permitían dos de esas tres propiedades [15], nunca las tres al mismo tiempo. Esta limitación se
llamaEl Triángulo de Zooko [16]. Por ejemplo, las claves públicas son únicas y descentralizadas, ya
que los usuarios pueden generarlas en sus computadoras sin hablar con ningún servicio central,
pero no son legibles por humanos. Los nombres de usuario de Twitter son legibles por humanos y
únicos, pero no están descentralizados (Twitter, la empresa, controla el espacio de nombres). Los
apodos son legibles por humanos y descentralizados (los usuarios pueden elegir cualquier apodo
para cualquier persona), pero no son únicos. Las cadenas de bloques cuadran el Triángulo de Zooko
y, por primera vez, es posible tener nombres legibles por humanos que sean únicos sin usar ningún
servicio centralizado [16].
Namecoin [9] fue el primer sistema en construir un sistema de nombres descentralizado utilizando un

6
blockchain. Nuestra experiencia en la gestión de una red de producción en Namecoin reveló ciertos
problemas de seguridad y confiabilidad que resaltan la necesidad de utilizar la red blockchain más
grande y segura [17].

3.1 Operaciones del BNS

Presentamos el diseño de un nuevo sistema de nombres basado en blockchain, llamado Blockchain Name
System (BNS). Nuestra implementación de BNS ha estado funcionando en producción durante más de 3
años. En nuestra nueva Internet, BNS es un reemplazo para DNS y está destinado a proporcionar una
funcionalidad similar pero sin ningún servidor raíz central. En BNS, los nombres son propiedad de
direcciones criptográficas de la blockchain subyacente y sus claves privadas asociadas (por ejemplo, claves
privadas basadas en ECDSA utilizadas en Bitcoin [18]). Un usuariopedidos anticipadosy luegoregistrosun
nombre en un proceso de confirmación de dos fases. Esto se hace para evitar la ejecución anticipada, en la
que un atacante puede competir con el usuario en el registro del nombre, ya que un atacante podrá ver la
transacción no confirmada en la red. El primer usuario que escriba con éxito tanto una transacción de
preorden como una de registro recibe la propiedad del nombre. Además, cualquier preorden anterior deja
de ser válida cuando se registra un nombre. Una vez que se registra un nombre, un usuario puede
actualizarel par nombre-valor enviando una transacción de actualización y cargando el enlace nombre-
valor. NombretransferirLas operaciones simplemente cambian la dirección a la que se le permite firmar
transacciones posteriores, mientras querevocarLas operaciones deshabilitan cualquier operación adicional
para los nombres.
En BNS, los nombres se organizan enespacios de nombres, que son el equivalente funcional de los dominios

de nivel superior en DNS: definen los costos y las tasas de renovación de los nombres. Al igual que los nombres, los

espacios de nombres deben ordenarse previamente y luego registrarse. Como se muestra en la Figura 2, en BNS,

la información de los dominios de nivel superior (espacios de nombres) se registra en un cadena de bloques raíz

Las entradas de los TLD pueden apuntar a otras cadenas de bloques que almacenan datos de los dominios

registrados en ese TLD. La cadena de bloques raíz también se puede utilizar para definir los TLD, en cuyo caso la

entrada del TLD apunta a la misma cadena de bloques. En DNS, los servidores raíz de DNS, los servidores de TLD y

los servidores autorizados están fuera delzona de confianzadel usuario final, donde la zona de confianza se define

como una máquina local o una red local y puede incluir un nodo controlado (y de confianza) por el usuario final en

el área amplia. La Figura 2 (arriba) muestra una consulta DNS recursiva para [Link]. La consulta se resuelve

fuera de la zona de confianza del usuario. En BNS, el servidor BNS local obtiene datos de la cadena de bloques de

las respectivas redes de cadenas de bloques (descentralizadas) y mantiene una copia local que se sincroniza

continuamente con las redes de cadenas de bloques. Los registros individuales de la cadena de bloques son

pequeños y contienen punteros a datos fuera de la cadena de bloques, por ejemplo, en una red de pares. Para

resolver un nombre, digamos [Link], el usuario final realiza una consulta al servidor BNS local que se ejecuta

dentro de su zona de confianza. El servidor BNS local observa el registro de la cadena de bloques respectivo y

obtiene el archivo de zona respectivo de una fuente externa, como una red de pares. La fuente externa para los

archivos de zona no es confiable. El hash del archivo de zona está presente en el registro de la cadena de bloques y

cualquier intento de manipulación se puede detectar fácilmente (verificando el hash). La figura 3 muestra un

ejemplo de archivo de zona BNS para un solo dominio.

7
 Servidores raíz DNS

3
6

2
Servidores TLD Servidores TLD
.com .educación
7

5 4

Servidor autorizado Servidor DNS local

por ejemplo, [Link] (cache)
1
8
Infraestructura central del DNS

mi
nd-usuario

Infraestructura descentralizada de BNS

Zona de confianza

4
1
Cadena de bloques raíz sincronizar

Servidor BNS local

(cache)

2
Cadena de bloques de TLD

. aplicación
Cadena de bloques de TLD

. identificación
sincronizar 3
Red de pares

Figura 2:Una consulta DNS recursiva (arriba) y una consulta BNS iterativa.

Figura 3:Un archivo de zona de ejemplo para BNS.

8
 Funciones de precios:Cualquiera puede crear un espacio de nombres o registrar nombres en un espacio de

nombres, ya que no existe una entidad central que impida que alguien lo [Link] de fijación de precios

definir qué tan costoso es crear un espacio de nombres o registrar nombres en un espacio de nombres. Definir

funciones de precios inteligentes es una forma de evitar el "acaparamiento de tierras", es decir, evitar que las

personas registren muchos espacios de nombres o nombres que en realidad no tienen intención de usar. BNS

tiene soporte para funciones de precios sofisticadas. Por ejemplo, creamos [Link]ónespacio de nombres

en nuestra implementación de BNS con una función de precios donde (a) el precio de un nombre disminuye con un

aumento en la longitud del nombre y (b) la introducción de caracteres no alfabéticos en los nombres también

reduce el precio. Con esta función de precios, el precio [Link] > [Link] > [Link]. La función se inspira

generalmente en la observación de que los nombres cortos con solo letras se consideran más deseables en

espacios de nombres como el de los nombres de usuario de Twitter. Es posible crear espacios de nombres donde

los registros de nombres también sean gratuitos. Además, esperamos que en el futuro haya un mercado de

revendedores de nombres, tal como lo hay para DNS. Una discusión detallada de las funciones de fijación de

precios está fuera del alcance de este documento técnico, y se recomienda al lector que consulte [15] para obtener

más detalles sobre las funciones de fijación de precios y los problemas de ocupación de nombres en los sistemas

de nombres descentralizados.

Blockstack utiliza BNS como sistema de nombres predeterminado. BNS se implementa definiendo una

máquina de estados y reglas para las transiciones de estados en una nueva cadena virtual. Almacenamos archivos

de zona en una nueva red de pares, llamadaRed AtlasPresentamos los detalles de nuestra implementación de BNS

con cadenas virtuales y Atlas en la Sección 4 y la Sección 5 respectivamente. Al igual que los nombres, los espacios

de nombres también tienen unfunción de fijación de precios[7]. Para iniciar el primer espacio de nombres en

Blockstack, [Link]ónEn el espacio de nombres, pagamos 40 bitcoins (10.000 dólares en ese momento) a la

red. Esto demuestra que incluso los desarrolladores de este sistema descentralizado tienen que seguir las reglas y

pagar las tarifas correspondientes.

3.2 Claves públicas en BNS

En Internet, los dominios DNS tradicionales se pueden utilizar con certificados digitales para mejorar
la seguridad. Los certificados digitales para sitios web son el elemento fundamental de la seguridad
en Internet. Cuando los usuarios ven el "candado verde", sienten que están en una conexión segura.
En segundo plano, su navegador comprueba el certificado digital del sitio web. El "candado verde"
representa que alguna autoridad de certificación (CA), como Verisign, emitió un certificado digital
para un sitio web y que el sitio web es propietario de ese certificado. La autoridad de certificación
puede emitir certificados "maliciosos" que se hacen pasar por empresas y sitios web sin su permiso y
los usuarios terminarían confiando en los certificados maliciosos, un problema real que ha sucedido
varias veces en la historia reciente, por ejemplo, Turktrust, una CA turca, emitió certificados
maliciosos para [Link] [2].
Una cadena de bloques puede utilizarse como mecanismo de distribución global de claves públicas y

certificados digitales. Dado que las cadenas de bloques ofrecen una visión global y son extremadamente difíciles

de manipular, sería poco práctico para un atacante alterar un certificado después de su emisión o presentar

información incorrecta solo a un subconjunto de usuarios. Además, en una PKI basada en cadenas de bloques no

hay CA centrales que puedan verse comprometidas para atacar el sistema.

9
 BNS ya proporciona asociaciones de claves públicas con nombres de dominio y todos los dominios, por

defecto, obtienen certificados. Si bien iniciativas como Lets Encrypt [19] están reduciendo el costo de obtener

certificados digitales y alentando a más sitios web a habilitar conexiones seguras, una gran mayoría de Internet

aún funciona con conexiones inseguras. Si el sistema de nombres vincula claves públicas por defecto, entonces

todos los sitios web tienen certificados de seguridad y la seguridad está activada por defecto. En BNS, los nombres

de dominio pueden servir como identificadores memorables para claves públicas. Los nombres en sí no implican

nada sobre la identidad y se usan solo como identificadores memorables. Las certificaciones de terceros se pueden

adjuntar al nombre memorable más adelante. Además, todos los nodos BNS tienen acceso a un solo estado global,

por lo que cualquier revocación de clave o cambio de estado en las asignaciones de clave pública no se puede

ocultar a ningún usuario.

4 Cadena virtual
Las cadenas de bloques públicas se están convirtiendo en un servicio de red universal. Sin embargo, es difícil

realizar cambios que rompan el consenso en las redes de cadenas de bloques de producción. La introducción de

nuevas características directamente en una cadena de bloques requiere que todos en la red, incluidos los mineros,

se actualicen. Estas actualizaciones potencialmente rompen el consenso y causan bifurcaciones [18]. Nuestra

experiencia con la cadena de bloques Namecoin muestra que iniciar cadenas de bloques nuevas y más pequeñas

conduce a problemas de seguridad, como la reducción de la potencia computacional necesaria para atacar la red, y

debe evitarse cuando sea posible [17]. Para superar esto, creamoscadenas virtuales, una cadena de bloques virtual

para crear máquinas de estados arbitrarios sobre cadenas de bloques que ya se encuentran en funcionamiento.

Las cadenas virtuales, al igual que las máquinas virtuales, permiten la capacidad de migrar (de una cadena de

bloques a otra) y mejorar la tolerancia a fallas. Usamos cadenas virtuales para migrar una red de producción de

Namecoin a Bitcoin anteriormente [20]. La migración demostró que las cadenas virtuales se podían usar para

hacer frente a fallas en la cadena de bloques subyacente.

Las cadenas de bloques proporcionan un registro de transiciones de estado totalmente ordenado y resistente

a la manipulación. Las nuevas aplicaciones pueden almacenar un registro de todos los cambios de estado en una

cadena de bloques pública, como Bitcoin [21], Litecoin [22] o Ethereum [10]. Al utilizar la cadena de bloques como

un canal de comunicación compartido, estas aplicaciones puedenEstado global de arranquede forma segura y

descentralizada, ya que cada nodo de la red puede construir independientemente el mismo estado.

Sin embargo, existen dos desafíos clave para el uso de cadenas de bloques como un elemento fundamental

para aplicaciones y servicios descentralizados:

1. En primer lugar, una cadena de bloques puede fallar, es decir, puede desconectarse, o su mecanismo
de consenso puede "centralizarse" al caer bajo lade factocontrol de una sola entidad. Para tolerar
tales fallas, debería ser posible migrar el estado de la aplicación entre cadenas de bloques de
manera eficiente.

2. El segundo desafío es que el registro de la aplicación puede bifurcarse y corromperse si la cadena de bloques

subyacente se bifurca. En una bifurcación de la cadena de bloques, los nodos en diferentes bifurcaciones

escribirán y leerán diferentes eventos. La cadena de bloques puede descartar y reordenar las transacciones

cuando se resuelven las bifurcaciones, lo que hace que los nodos de arranque construyan

10
 aa
enen
yoVyoioadotúaadolcyoyo
Ba
_domio_domipag,,yoyoaassyoyo
norteoapagmetro
código de operación, hash
nombre_op, hash
código de operación, hash
nombre_op, hash
norteo_do
apagmimetro
o_domipag,,yoyoaassyoyo

_domio_domipag,,yoyoaassyoyo
norteoapagmetro

Cadena de bloques

Figura 4: Operaciones de cadena virtual sobre una cadena de bloques subyacente.

Estado diferente al de los nodos que ya están en funcionamiento. Las aplicaciones deben poder recuperarse de las

bifurcaciones de la cadena de bloques.

4.1 Diseño de cadenas virtuales

Virtualchain es una cadena de bloques virtual (una capa lógica) para construir múltiples máquinas de estado sobre

una cadena de bloques. Las cadenas virtuales procesan transacciones en las cadenas de bloques subyacentes para

construir máquinas de estado sobre las cadenas de bloques. Las cadenas virtuales proporcionan una

mod de consistencia fork* el [23]. Aplicación n nodos repl ay sus registros a achi s vísperaaplicación norte-
nivelconsenso en cada en dos nodos se pondrán de acuerdo
bloque hb, tales como las ock si y o solamente

caso si la aplicación tra acciones que se toman bloquear dejar t sobre un bl él nodos en Estado Si
ntico.
su estado resultante se después de ejecutar la operaciones un ide en bloquebson tical, entonces el eir

generaconsenso picadillopara ese bloque k será el idénticos. Consenso s hace hashes ena ble

Nodos para auditar de forma independiente y consultar de manera eficiente sus historiales, así como detectar bifurcaciones.

y luego migrar el estado entre bloques cadenas.

La figura 4 muestra cómo las cadenas virtuales con procesar únicamente transacciones relevantes (transacciones

códigos de operación de cadena virtual válidos) de la cadena de bloques subyacente e ignorar otras transacciones

acciones. Las transacciones aceptadas por virtualchain se organizan en bloques virtuales que están
vinculados entre sí por un hash de consenso por bloque; el hash de consenso en un bloque refleja
Todo el historial de cadenas virtuales anteriores. La cadena virtual de Blockstack implementa una máquina de

estados BNS. Nuestra cadena virtual actual utiliza Bitcoin como El bloque subyacente es un en. El nuevo
Los códigos de operación se anuncian en Bitcoin transacciones en campo designado para agregardatos imaginativos,
llamadoOP DEVOLVEREste es uno de los casos de uso más grandes deOP DEVOLVERactas
en la cadena de bloques de Bitcoin hoy [24].
Modelo de consistencia:La mayoría de p sentido[ Bloque público nos acosan cada variante deNaka moto con-
18], lo que permite la concurrencia bifurcaciones de líderes diferentes. Apariencia ding conflictivo bloque ng ks crea
blockchain, que los pares resuelven y usando ap techo-de-w orco [25] yo [Link] acciones
en la bifurcación con la mayor prueba de trabajo se consideran autoritarias; las transacciones conflictivas
se descartan silenciosamente, mientras que las transacciones no conflictivas se incorporan a los bloques
posteriores.
El consenso de Nakamoto otorga a las cadenas de bloques la propiedad de que las bifurcaciones más largas

son exponencialmente más raras si no hay particiones de red duraderas y si la mayor parte del procesamiento

11
 cadena virtual tx

bn-8 … bn-5 bn-4 bn-3 bn-2 bn-1 bn

}

}
}
}
CH(n-4) CH(n-3) CH(n-2) CH(n-1) V = Merkle(tx∈b )
norte norte

P = {CH(p) | p = n - 2i }
norte

CH(n) = Hash(V + P )
norte norte

Figura 5: Hash de consenso,es(norte), construcción a partir de transacciones de cadena virtual.

El poder está controlado por pares honestos [18]. Esto significa que la mayoría de las veces, las transacciones

aLos iones son ve Muy probable a ser dura ble a segunda linea Rizable después [Link] númerobmi
a debcabellos
( confirmaciones complementos y ser en appen
) tengo Encima de
muerto nosotros usar
el quinto estos pro porsími s a iejemplo-
Máquinas de estado replicadas (RSM) consistentes con fork* sobre cadenas de bloques públicas. Los nodos
de aplicación leen la cadena de bloques para construir réplicas de máquinas de estado y enviar nuevas
transacciones a la cadena de bloques para ejecutar transiciones de estado.
Hashes de consenso:Para avanzar, los nodos leen nuevas transacciones de blockchain.
acciones y determinar si cada transacción de las cadenas de bloques subyacentes representa o no una
transición de estado válida en la cadena virtual. Dado que cualquiera puede escribir transacciones y estas
pueden retrasarse arbitrariamente, los nodos deben poder filtrar transacciones (y también
transiciones de estado asociadas) e ignoran las transacciones que se relacionan con una bifurcación en la
que no están interesados. Logramos esto al requerir que la corrientehash de consensoSe anuncia en
nuevas transacciones.
Un hash de consenso es un hash criptográfico que cada nodo calcula en cada bloque. Se deriva de las
transiciones de estado aceptadas en el último bloque procesado y una serie geométrica de hashes de
consenso calculados previamente. La figura 5 muestra este proceso. Tesis∈bnortesea la secuencia de
registros de transacciones que se encuentran en el bloquebnorte, dejarMerkle(Tesis∈bnorte) sea una función
que calcule la raíz del árbol de Merkle sobre estas transacciones, y seaPicadillo(incógnita) sea una función
hash criptográfica. Luego, definimoses(norte) para ser el hash de consenso en el bloquenorte, dónde

Vnorte=Merkle(Tesis∈bnorte) (1)

es(norte) =Picadillo(Vnorte+PAGnorte) (2)

Bloquearb0contiene la primera entrada de registro, mientras quePAGnortees la serie geométrica de

hashes de consenso previos a partir deb, es decir, el hash de consenso del bloque anterior, hace dos
bloques, hace cuatro bloques, etc.

12
 Los usuarios incluyen sus últimos datos conocidoses(norte) en cada transacción que envían a través de sus

clientes, y las aplicaciones ignoran las transiciones de estado con hashes de consenso "obsoletos" (demasiado

antiguos) o desconocidos. De esta manera, las aplicaciones ignoran las bifurcaciones de su propio registro, y los

usuarios de la aplicación (o los clientes que están usando) pueden saber cuándo volver a intentar las transacciones

perdidas (anunciando transiciones de estado). Al hacerlo,Los hashes de consenso conservan la propiedad de unirse

como máximo una vez de consistencia fork*:una aplicación aceptará una transición de estado con es(norte) sólo si

ha aceptado todas las transiciones de estado anteriores que se derivarones(norte).

Consultas rápidas:No todos los usuarios tendrán una copia de la cadena de bloques completa en su máquina.

Utilizamos un protocolo para consultas rápidas que es útil para crear “nodos livianos” que no necesitan cadenas de

bloques ni réplicas de estado. En cambio, pueden consultar “nodos completos” de alta disponibilidad pero no

confiables (que tienen una copia completa de la cadena de bloques) según sea necesario. Por ejemplo, la cadena

virtual de Blockstack utiliza esta característica para implementar un protocolo de verificación de nombre simple

(SNV) [26].

Para consultas rápidas, los usuarios de la aplicación obtienenes(norte) desde un nodo confiable, como
uno que se ejecuta en el mismo host. Un usuario puede usar este nodo confiablees(norte) para consultar
transiciones de estado anteriores de nodos no confiables en una cantidad logarítmica de tiempo y espacio.
Para ello, consulta y verifica iterativamentePAGnorteyMerkle(Tesis∈bnorte) usandoes(norte) hasta
se encuentraes(norte") yMerkle(Tesis∈b" norte), dóndeb"es el bloque que contiene el estado
transición a consulta. Una vez que hayaMerkle(Tesis∈b" norte), puede solicitar y verificar lo anterior
transiciones de estado (Tesis∈b" norte).

Detección y recuperación de bifurcaciones de blockchain:Si los registros de transacciones nunca se bifurcan

retroactivamente, la lógica de la aplicación y los hashes de consenso pueden preservar la propiedad de solicitud legítima de

consistencia de bifurcación*. Las bifurcaciones retroactivas en cadenas de bloques de prueba de trabajo son muy poco

probables, peropoderEsto ocurre porque una entidad puede (teóricamente) crear una cadena de bloques más larga con un

historial de transacciones diferente de los bloques antiguos (lo que se denomina "reorganización de la cadena profunda").

Las bifurcaciones de corta duración, por otro lado, son bastante comunes y no son un problema para las aplicaciones o

servicios creados con cadenas virtuales. Los nodos evitanhorquillas de corta duración Al aceptar únicamente transacciones

suficientemente confirmadas. Las aplicaciones pueden aumentar la cantidad de confirmaciones requeridas para disminuir

la probabilidad de pérdida o reordenamiento, por ejemplo, Blockstack requiere 10 confirmaciones (en la cadena de bloques

de Bitcoin).

Para detectarreorganizaciones de cadena profunda,Un nodo ejecuta múltiples procesos que se suscriben a una serie

geométrica de alturas de bloque anteriores. Si un proceso de una altura inferior obtiene un hash de consenso diferente al

de uno de una altura superior, es posible que se haya producido una bifurcación de la cadena de bloques y que todos los

procesos de alturas superiores tengan un estado potencialmente divergente. Esto significa que todos los nodos en

ejecución pueden estar en un conjunto de bifurcaciones distinto al de los nodos de arranque.

Podemos automatizar el descubrimiento de reorganizaciones profundas, pero reconciliar los conjuntos de bifurcaciones requiere

intervención humana, ya que las acciones irreversibles que realiza la aplicación pueden basarse en transiciones de estado que ahora

se han perdido. Afortunadamente, las bifurcaciones de larga duración son poco frecuentes y lo suficientemente graves como para ser

ampliamente detectadas [27] [28] [29]. Esto significa que cuando ocurren, los usuarios finales o los desarrolladores de aplicaciones

pueden determinar qué transacciones se vieron afectadas y volver a enviar las transiciones de estado.

13
Cadena de bloques A

bn-4 bn-3 bn-2 bn-1 bn

migrar_a(B, estado en bn)

Cadena de bloques B

b'n-4 b'n-3 b'n-2 b'n-1 bn'

migrar_desde(A, estado en b) migrar_finish()

norte

Figura 6: Un marco para migrar de la cadena de bloques A a la cadena de bloques B.

4. 2 créditos óseo
- té en Migratios en
Las cadenas virtuales pueden sobrevivir al fallo de una cadena de bloques subyacente migrando su estado
a otra cadena de bloques. Para ello es necesario anunciar un bloque futuro hasta el cual la cadena de
bloques actual será válida (no se aceptarán nuevas transacciones en la cadena de bloques actual después
de ese bloque) y, a continuación, ejecutar unaCompromiso de dos pasospara vincular el estado existente a
la nueva cadena de bloques. túy 6 s cómo
gramo es el fr amotrabajar con aquí migratorio en
/ servicio
De la cadena de bloques A a la B. Para comenzar, la aplicación ministro actor (s) año
y anuncio es un fut ura sin confesión

bloque después del cual la cadena de bloques actual wl i yo no yo largo o el a servicio a

Seamos nosotros educación f Páginas por segundo Dakota del Norte

envía transacciones especiales de “migración” tanto a la cadena de bloques actual como a la nueva (para anunciar

el proceso de migración). El administrador o los administradores (a) adquieren un bloqueo en la nueva cadena de

bloques, (b) escriben el estado actual de la aplicación (excluyendo las transiciones de estado históricas) en la nueva

cadena de bloques y (c) liberan el bloqueo en la nueva cadena de bloques y abren la nueva cadena de bloques a

nuevas transacciones. Virtualchain verifica que las transacciones de migración estén firmadas por el mismo

principal y verifica que el último estado conocido en la antigua cadena de bloques sea coherente con el hash de

consenso anunciado en la nueva cadena de bloques. Esto permite una migración entre cadenas sin problemas.

Virtualchain se publica como código abierto [30] y los desarrolladores pueden construir otros tipos de máquinas de

estado usándolo.

5 Red Atlas
Las cadenas de bloques tienen un ancho de banda limitado y no pueden almacenar muchos datos. Cada nodo de la

red tiene una copia de los datos almacenados en las cadenas de bloques, y normalmente crecen de forma lineal

con el tiempo; por ejemplo, la cadena de bloques de Bitcoin creció de 14 GB a 120 GB entre 2014 y 2017 [31]. En

nuestra arquitectura, solo se guardan en la cadena de bloques los punteros a los valores de los datos; las redes

entre pares se utilizan como almacenamiento adicional. En la implementación de Blockstack, las redes entre pares

almacenan archivos de zona para BNS (estos archivos de zona son idénticos a los archivos de zona DNS).

14
El uso de redes de pares aumenta significativamente la capacidad de almacenamiento, pero conlleva otros
desafíos: las redes de pares tradicionales son susceptibles a ataques Sybil [32] y no son una fuente
confiable de datos, especialmente en condiciones de alta rotación.
En las redes de pares, los nodos participantes tienen los mismos privilegios y colaboran para realizar
una función o proporcionar un servicio. Las redes de pares se popularizaron mediante el intercambio de

redes como Napster en 1999 [33]. archivos. Los nodos en una red de pares mantienen una conexión.

a un subconjunto de otros pares en la red y estas conexiones pueden ser estructuradas o no estructuradas

(conexiones aleatorias a pares). En nuestra arquitectura, utilizamos redes de pares para el descubrimiento de

contenido. Los punteros a archivos de datos grandes se almacenan en redes de pares, mientras que los datos

reales residen en backends de almacenamiento (Sección 6).

La confiabilidad de las aplicaciones y servicios que se ejecutan en nuestra arquitectura de Internet depende de la

confiabilidad de la capa de cadena de bloques y de los pares de descubrimiento/almacenamiento. De las diferentes capas,

las redes de pares utilizadas para el descubrimiento son las más vulnerables a los problemas de confiabilidad (los

proveedores de almacenamiento en la nube tienen acuerdos de nivel de servicio con un tiempo de actividad del 99,9 % [34]

y las cadenas de bloques se replican completamente entre pares). En teoría, cualquier persona o empresa puede decidir

ejecutar un índice (centralizado) de datos de descubrimiento para su aplicación/servicio en particular. Las aplicaciones

también pueden elegir indexar/duplicar solo un espacio de nombres (TLD) en particular, y no tienen que indexar los

punteros a todos los datos. Esto ayuda con la escalabilidad. Digamos que haymetro espacios de nombres connortepares

nombre-valor en cada espacio de nombres. En lugar de indexarOh(metro×norte) registros, puedes indexarlosOh(norte)

registros ynorteEl espacio de nombres puede ser significativamente pequeño. Sin embargo, de manera realista, la red

global Blockstack debería tener al menos un servicio de descubrimiento predeterminado, si no más, para todos los datos,

además de cualquier servicio de descubrimiento especializado específico para cada aplicación. Además, el servicio de

descubrimiento global no puede violar el principio de confianza a confianza y no puede centralizarse. Esto implica la

necesidad de utilizar redes descentralizadas entre pares para el descubrimiento de contenido.

Desafíos de las redes de pares:Las redes de pares se han estudiado en profundidad en

sistemas distribuidos [35, 8] y los investigadores han identificado varios desafíos con ellas.

• Escalabilidad:En redes de pares no estructuradas, a medida que aumenta el número de pares

participantes, aumenta el número de mensajes intercambiados para una búsqueda [35]. Las redes
de pares no estructuradas prácticas utilizan “superpares” (KaZaA [36]) o rastreadores centralizados
(eDonkey 2000 [37]). Las redes de pares estructuradas, en su mayoría basadas en tablas hash
distribuidas (DHT), reducen el número de mensajes necesarios para las búsquedas a, por lo general,
Oh(registronorte),pero sufren problemas como ataques Sybil y pérdida de nodos [38].

• Actuación:Las lecturas y escrituras en redes entre pares tienen una latencia muy variable según el
diseño subyacente, pero en la mayoría de los casos, el peor rendimiento de las búsquedas es
inaceptable; una solicitud puede rebotar innecesariamente a través de varios enlaces de red de alta
latencia antes de ser procesada. Algunos trabajos sobre DHT (como DSHT [39] y Beehive [40])
intentan solucionar este problema para los datos solicitados con frecuencia, pero no ayudan al
rendimiento de cola larga y funcionan solo para cierto tipo de cargas de trabajo.

• Fiabilidad:Las redes públicas de pares permiten que cualquiera pueda escribir en ellas. Para gestionar

tantos datos, simplemente eliminan los datos obsoletos. Las aplicaciones deben volver a anunciar

15
 Los datos se actualizan con cierta frecuencia para mantenerlos disponibles. Las fuentes de datos pueden

desconectarse antes de volver a publicarse [41]. Las redes de pares estructuradas pueden dividirse en una o más

redes disjuntas debido a particiones y volver a unirse más tarde. Esto puede generar un estado inconsistente;

algunos clientes pueden ver un valor para la clave y otros clientes pueden ver un valor diferente.

• Escritura de datos basura:Sin algún mecanismo de control de acceso o limitación de velocidad, las redes

entre pares no tienen forma de limitar la cantidad de datos que se insertan. Un adversario puede inundar la

red entre pares con una gran cantidad de datos basura y dejar fuera de servicio a los nodos.

• Ataque Eclipse de [Link] las redes estructuradas entre pares, un atacante puede tomar el control
de los vecinos de todos los nodos que almacenan un par clave/valor particular y censurar
efectivamente los nodos/claves de la red. Estos ataques Sybil son un problema general para las
redes estructuradas entre pares, sin buenas soluciones disponibles sin requerir guardianes
centralizados o intervención humana en las conexiones entre pares [42].

Para BNS, el tamaño de los archivos de zona individuales es bastante pequeño (<4 KB) y el espacio total

necesario para almacenarlos aumenta linealmente con la cantidad de registros de dominio. Actualmente, solo se

necesitan 300 MB para almacenar todos los archivos de zona de los 70 000 dominios registrados en BNS y 100 GB

de espacio pueden almacenar archivos de zona para los 250 millones de dominios de ICANN (que es más pequeño

que el tamaño de la cadena de bloques actual de Bitcoin). Inspirados por la necesidad de almacenar los archivos de

zona (de tamaño pequeño) de BNS, diseñamos una nueva red de pares llamadaRed AtlasLa red Atlas resuelve un

caso particular de almacenamiento descentralizado mediante redes entre pares: el caso en el que:

1. El conjunto de datos es pequeño en tamaño y

2. Hay un índice completo de datos disponibles en la red.

Todos los nodos Atlas mantienen una réplica de estado del 100 % y se organizan en una red
superpuesta no estructurada. El enfoque no estructurado es más fácil de implementar, no tiene gastos
generales para mantener la estructura de enrutamiento y es resistente a ataques dirigidos a nodos.
Cuando se inicia un nuevo nodo Atlas, primero obtiene el índice de todos los [Link] hashes de
valoresalmacenados en la cadena de bloques. Después de obtener el índice, los nodos Atlas se comunican
con sus pares para obtener pares clave/valor que no tienen. La red Atlas implementa un gráfico aleatorio K-
regular. Cada nodo seleccionaKotros nodos al azar para que sean sus vecinos utilizando el algoritmo
Metropolis-Hastings Random Walk con aceptación retrasada (MHRW-DA [43]), y les pide regularmente el
conjunto de pares clave/valor que tienen. Los pares extraen los pares clave/valor faltantes en orden de
menor a mayor para maximizar la disponibilidad, es decir, los nuevos pares clave/valor escritos en la red
tienen preferencia para la propagación a través de la red. Además de almacenar los pares clave/valor
localmente, los pares también pueden escribirlos en ubicaciones de respaldo remotas (por ejemplo, un
servicio como Dropbox o S3) para una protección adicional contra la pérdida de datos. Cuando un par
recibe un par clave/valor faltante, lo envía a sus vecinos inmediatos que aún no lo tienen.

Los nodos Atlas ya conocen los hashes de los archivos de zona, de modo que nadie puede cargar datos no

válidos. Los datos se replican enOh(norte) en lugar de solo en un pequeño subconjunto de nodos (típico de las

redes basadas en DHT). La red Atlas hace que los ataques de censura sean más fáciles de implementar.

16
caro. Censurar toda la red requiere atacarOh(norte) nodos. Por el contrario, sóloOh(registronorte)Es
necesario tomar el control de los nodos DHT para censurar un par clave/valor para todos. Incluso
entonces, el nodo víctima detectará la censura a menos que el atacante también eclipse el nodo
Bitcoin de la víctima (lo que requiere construir una bifurcación fraudulenta de la cadena de bloques
con suficiente prueba de trabajo). Creemos que la red Atlas es un importante paso adelante hacia
una red de pares confiable, difícil de censurar y descentralizada.
En nuestra implementación de producción, durante septiembre de 2015 y noviembre de 2016, usamos
una red DHT basada en Kademlia. No notamos ningún ataque de eclipse de nodo explícito, pero
encontramos particiones de la superposición de DHT donde algunos nodos alojados en Hong Kong y
Europa terminaron en una partición diferente. La pérdida de clientes es un problema general con los DHT
estructurados. Nuestros nodos DHT fueron programados para no aceptar escrituras de datos a menos que
haya un hash de los datos presente en la cadena de bloques, es decir, alguien haya pagado una tarifa para
obtener acceso para escribir datos. La red de descubrimiento basada en DHT sirvió como un diseño inicial
aceptable, pero con una red en crecimiento, la pérdida de clientes diaria y horaria se convirtió en un
problema mayor. La implementación de Blockstack cambió a la red Atlas desde la red de descubrimiento
basada en DHT en el otoño de 2016, y desde noviembre de 2016, hemos estado distribuyendo archivos de
zona BNS utilizando la red Atlas.
Particiones de red:La red Atlas es más confiable que la red DHT anterior. En nuestra implementación de
DHT, nos topamos con frecuencia con problemas de partición de red en los que algunos nodos, por
ejemplo, en Hong Kong, se desconectaban de la red principal de DHT. Entre septiembre de 2015 y
septiembre de 2016, hubo al menos 7 incidentes importantes en los que tuvimos que trabajar con nuestra
comunidad para restaurar particiones de red en nuestra implementación de DHT. Desde que nos
migramos completamente a la red Atlas, entre noviembre de 2016 y el momento de escribir este artículo
(mayo de 2017), no hemos tenido ningún incidente de partición de red ni ninguna otra interrupción de la
red. De hecho, no existe el concepto de partición de red en la red, ya que Atlas no está estructurado y todos
los nodos tienen una réplica completa.
Recuperación de nodos:Los nodos Atlas pueden recuperarse de fallas por sí solos. Si el índice local de
los datos de Atlas se corrompe, los nodos pueden reconstruirlo a partir de los datos de la cadena de
bloques. Los nodos también pueden volver a obtener todos los archivos de zona en caso de pérdida de
datos. Realizamos un experimento en el que destruimos intencionalmente los archivos de zona en los
nodos Atlas yEl 100% de nuestros nodos pudieron recuperarse por completo de una pérdida total de datos
en cuestión de horas. La red Atlas se autocura en ese aspecto y puede recuperarse de fallas incluso si
quedan muy pocas copias de datos en la red de pares.

6 Gaia: almacenamiento descentralizado

En la Internet tradicional, una vez que los usuarios finales establecen una conexión segura con un sitio web como

[Link], inician sesión en el servicio y conservan todos sus datos en el servicio remoto. Este modelo, junto

con los avances en la computación en la nube, traslada toda la complejidad y los datos de los usuarios a la nube

remota, y los dispositivos de los usuarios existen como "pantallas tontas". Esto supone un cambio radical respecto

del espíritu de una Internet descentralizada en la que los dispositivos de los usuarios finales debían gestionar la

complejidad y la lógica.

17
 Capa de almacenamiento
Caja de caída Amazonas S 3 Unidad de Google Gratis Servidor NAS

(endatos cifrados)

Red de pares

búsqueda(URI)

Capa de descubrimiento
Nodo par
(índice completo)

)
ash
a(h
ed
squ
bú

Capa de cadena virtual

Bloque N-5 Bloque N-4 Bloque N-3 Bloque N-2 Bloque N-1 Bloque N

(nombre, almohadilla)

Figura 7: OhRevisión de ia y pasos f o

Georgia mirando hacia arriba d aejército de reserva.

Blockstack tiene el potencial de liberar a los usuarios de estos silos de datos al brindarles acceso a un sistema

de almacenamiento descentralizado, llamadoGea, que proporciona un rendimiento comparable al de los

proveedores de nube centralizados. Los usuarios pueden iniciar sesión en aplicaciones y servicios mediante una

identidad descentralizada basada en blockchain [44] y guardar los datos generados por las aplicaciones/servicios

en los backends de almacenamiento que son propiedad del usuario (en lugar del proveedor de servicios). La

filosofía de diseño de Gaia es reutilizar los proveedores de nube y la infraestructura existentes de una manera que

los usuarios finales no necesiten confiar en los proveedores de nube subyacentes. Tratamos a los proveedores de

almacenamiento en la nube (como Dropbox, Amazon S3 y Google Drive) como "unidades tontas" y almacenamos

datos cifrados y/o firmados en ellos. Los proveedores de nube, como Dropbox, no tienen visibilidad de los datos

del usuario; solo ven blobs de datos cifrados. Además, dado que las claves públicas asociadas o los hashes de datos

se pueden descubrir a través del canal de blockchain, los proveedores de nube no pueden manipular los datos del

usuario.

En Gaia, el archivo de zona del usuario contiene un registro URI que apunta a los datos, y los datos se
construyen para incluir una firma de la clave privada del usuario. Escribir los datos implica firmar y replicar
los datos (pero no el archivo de zona), y leer los datos implica obtener el archivo de zona y los datos,
verificar quepicadillo(archivo de zona) coincide con el hash en la cadena de bloques y verifica la firma de los
datos con la clave pública del usuario. Esto permite que las escrituras sean tan rápidas como lo permitan el
algoritmo de firma y el sistema de almacenamiento subyacente, ya que la actualización de los datos no
altera el archivo de zona y, por lo tanto, no requiere ninguna transacción de la cadena de bloques. Sin
embargo, los lectores y escritores deben emplear un sistema de control de versiones de datos.

18
esquema para evitar consumir datos obsoletos.

La Figura 7 muestra una descripción general de Gaia. Mostramos un ejemplo de blob de datos cifrados
con tres copias replicadas en Dropbox, Google Drive y un servidor FreeNAS (y no en Amazon S3). En nuestra
implementación de Blockstack, tenemos controladores para proveedores de nube individuales como
Dropbox y S3, y los integramos como backends de almacenamiento. Esto oculta las API individuales para
backends de almacenamiento y expone una interfaz PUT/GET simple para los usuarios de Blockstack. Al
buscar datos por un nombre, [Link], funciona de la siguiente manera:

1. Busque elnombreen la cadena virtual para obtener el (nombre, hash) par.

2. Busque elpicadillo(nombre) en la red Atlas para obtener el archivo de zona correspondiente (todos los pares

en la red Atlas tienen la réplica completa de todos los archivos de zona).

3. Obtenga la URI del backend de almacenamiento del archivo de zona y busque la URI para conectarse al

backend de almacenamiento.

4. Lea los datos (descifrelos si es necesario y si tiene los derechos de acceso) y verifique la
firma o hash correspondiente.

Actuación:El objetivo de nuestra arquitectura es ofrecer un rendimiento comparable al de los

proveedores de nube tradicionales. Presentamos importantes ventajas en seguridad y tolerancia a fallos
eliminando los puntos centrales de control y fallos, y pagar una pequeña sobrecarga en el rendimiento de
lectura/escritura vale totalmente la pena siempre que la sobrecarga no sea significativa ni perceptible para
los usuarios promedio. Evaluamos el rendimiento de lectura y escritura de Gaia para demostrar que lee y
escribe archivos a velocidades competitivas con el almacenamiento subyacente. Gaia agrega una
sobrecarga de espacio de almacenamiento constante insignificante por archivo (aproximadamente
archivos un 5 % más grandes con compresión). Hay una sobrecarga de CPU para el cifrado y la compresión,
pero como la diferencia de tamaño de archivo es muy pequeña, el rendimiento de la red para lecturas y
escrituras es similar al acceso directo al servicio de almacenamiento subyacente.
Medimos el rendimiento de escritura y los costos asociados con la carga de archivos de 1, 10 y 100
megabytes a Amazon S3. Vemos que el costo asociado con la CPU es del orden de 2 segundos para
archivos grandes (100 MB). Aún quedan muchas optimizaciones de rendimiento de bajo costo en nuestra
implementación. De manera similar, leer archivos cifrados desde Blockstack con S3 como backend de
almacenamiento es competitivo con una lectura directa desde S3. Las fuentes de costo, la verificación de la
firma y el descifrado de los datos, están limitadas por la CPU, mientras que en la práctica el rendimiento
estará limitado en gran medida por la red para el uso en áreas amplias.
Escalabilidad del sistema:La capa de almacenamiento de nuestra arquitectura no es un cuello de botella de

escalabilidad. Los sistemas de almacenamiento en la nube contemporáneos son altamente escalables [34]. La red

Atlas también escala bien porque no indexa archivos de usuarios individuales o fragmentos de archivos, sino que

indexa punteros a los backends de almacenamiento del usuario. Los backends de almacenamiento se ocupan de la

mayor parte de la lectura/escritura de datos, y la red Atlas solo participa cuando (a) un usuario está cambiando o

actualizando sus backends de almacenamiento o asignaciones de claves públicas, o (b) se registran nuevos

usuarios en el sistema. Al registrar nuevos dominios/usuarios, los hashes de archivos de zona deben anunciarse en

la cadena de bloques subyacente. Las cadenas de bloques subyacentes suelen tener un ancho de banda bajo y son

el cuello de botella de la escalabilidad (en relación con Atlas).

19
Estamos explorando la opción de agrupar múltiples transacciones de cadena virtual en una sola
transacción de cadena de bloques [45] para abordar la escalabilidad de la cadena de bloques. Esto puede
permitirnos registrar varios cientos de millones de usuarios finales. Escalar Blockstack a miles de millones
de usuarios en la práctica probablemente revelará problemas de escalabilidad que no son obvios en este
momento y abordar estos desafíos es un área de trabajo futuro.

7 Conclusión
Presentamos Blockstack, una nueva Internet descentralizada protegida por cadenas de bloques. Blockstack
ofrece a los desarrolladores una pila completa para crear aplicaciones descentralizadas que incluyen
servicios de identidad, descubrimiento y almacenamiento. Blockstack puede introducir nuevas funciones
sin modificar las cadenas de bloques subyacentes y puede sobrevivir a las fallas de las cadenas de bloques
subyacentes. El diseño de Blockstack se basa en 3 años de experiencia en producción de uno de los
sistemas de producción basados en cadenas de bloques más grandes hasta la fecha. Nuestros resultados
de rendimiento muestran que Blockstack puede ofrecer un rendimiento comparable a los servicios en la
nube en la Internet tradicional y solo introduce una pequeña sobrecarga de CPU. Hemos publicado
Blockstack como código abierto [7].

Expresiones de gratitud

Muneeb y Ryan iniciaron Blockstack en 2014 y, a lo largo de los años, muchas personas han
contribuido. Nos gustaría agradecer a Larry Salibra, Guy Lepage, Patrick Stanley, Aaron Blankstein,
John Light y a más de 2500 miembros de la comunidad de código abierto por sus contribuciones.
Actualizaremos esta lista a medida que publiquemos nuevas versiones del informe técnico.

Referencias
[1] L. Newman, “Lo que sabemos sobre la interrupción masiva del servicio de Internet en la costa este del viernes”, octubre de 2016.
[Link]

[2] S. Rosenblatt, “Los certificados falsos de sitios turcos crean la amenaza de sitios falsos de Google”, enero de 2013. // http:
[Link]/2oArU6O.

[3] N. Perlroth, “Yahoo dice que los piratas informáticos robaron datos de 500 millones de usuarios en 2014”, septiembre de 2016. // http:
[Link]/2oAqn0G.

[4] “Sitio web Blockstack”, 2017.[Link]

[5] “Redes en malla de Gotenna”.[Link]
[6] J. Nelson, M. Ali, R. Shea y MJ Freedman, “Extensión de cadenas de bloques existentes con virtualchain”,
enTaller sobre criptomonedas distribuidas y registros de consenso (DCCL'16), (Chicago, IL), junio de
2016.
[7] “Lanzamiento del código fuente de Blockstack v0.14”, 2017.[Link]
[8] R. Hasan, Z. Anwar, W. Yurcik, L. Brumbaugh y R. Campbell, “Un estudio de técnicas de almacenamiento peer-
to-peer para sistemas de archivos distribuidos”, enActas de la Conferencia Internacional sobre Tecnologías de
la Información: Codificación y Computación (ITCC'05) - Volumen 02, ITCC '05, págs. 205-213, 2005.

[9] “Namecoin”.[Link]
[10] V. Buterin, “Una plataforma de aplicaciones descentralizadas y contratos inteligentes de próxima generación”, tech.
rep., 2017.[Link]

20
[11] M. Ali, J. Nelson, R. Shea y MJ Freedman, “Impulsar la confianza en sistemas distribuidos con cadenas de
bloques”,USENIX;inicio de sesión:, vol. 41, núm. 3, págs. 52–58, 2016.
[12] H. Balakrishnan, S. Shenker y M. Walfish, “Referencia libre semántica en sistemas distribuidos
vinculados”, enSistemas peer-to-peer II, vol. 2735 deApuntes de clases de informática, págs. 197–206,
Springer Berlín / Heidelberg, 2003.
[13] Juan Benet, “IPFS - Sistema de archivos P2P con dirección de contenido y versiones”, borrador, [Link], 2015.
[Link]
[14] D. Mazieres, M. Kaminsky, MF Kasshoek y E. Witchel, “Separación de la gestión de claves de la seguridad del sistema de
archivos”, enProcedimiento 17º SOSP, (Kiawah Island Resort, Carolina del Sur), 1999.

[15] H. Kalodner, M. Carlsten, P. Ellenbogen, J. Bonneau y A. Narayanan, “Un estudio empírico de Namecoin
y lecciones para el diseño de espacios de nombres descentralizados”,WEIS '15: Actas del 14El
Taller sobre la economía de la seguridad de la información, junio de 2015.
[16] D. Kaminsky, “Explorando el triángulo: explorando la perspectiva de Aaron Swartz sobre el triángulo de Zookos”, enero
de 2011.[Link]

[17] M. Ali, J. Nelson, R. Shea y M. Freedman, “Blockstack: un sistema global de nombres y almacenamiento asegurado por
cadenas de bloques”, enActas de la Conferencia técnica anual de USENIX (ATC '16)Junio de 2016.

[18] J. Bonneau, A. Miller, J. Clark, A. Narayanan, JA Kroll y EW Felten, “Sok: Perspectivas de investigación y
desafíos para bitcoin y criptomonedas”, enSimposio IEEE sobre seguridad y privacidad 2015, SP 2015,
San José, California, EE. UU., del 17 al 21 de mayo de 2015, págs. 104–121, 2015.
[19] “Vamos a encriptar.”[Link]
[20] “Por qué Blockstack está migrando a la cadena de bloques de Bitcoin”. [Link]
¿Por qué Blockstack está migrando a la cadena de bloques de Bitcoin?

[21] Satoshi Nakamoto, “Bitcoin: Un sistema de efectivo electrónico peer-to-peer”, informe tecnológico, 2009.
[Link]
[22] “Litecoin”.[Link]
[23] J. Li y D. Maziéres, “Más allá de un tercio de réplicas defectuosas en sistemas tolerantes a fallas
bizantinas”, en Actas del 4º Simposio USENIX/ACM sobre diseño e implementación de sistemas en red
(NSDI '07), (febrero), 2007.
[24] “Estadísticas de uso de bitcoin OP RETURN”. Recuperado de[Link] mayo de 2017.
[25] M. Jakobsson y A. Juels, “Pruebas de trabajo y protocolos de budín de pan”, enRedes de información
seguras, págs. 258–272, Springer, 1999.
[26] “Protocolo simplificado de verificación de nombres”.[Link]
[27] “Propuesta de mejora de Bitcoin 50”. [Link]
[Link].
[28] “Propuesta de mejora de Bitcoin 66”. [Link]
[Link].
[29] “Lista de CVE de Bitcoin”.[Link]
[30] “Lanzamiento del código fuente de Virtualchain v0.14.1”, mayo de 2017. [Link]
cadena virtual.
[31] “Tamaño de la cadena de bloques de Bitcoin”.[Link]

[32] JR Douceur, “El ataque de la sibila”, enDocumentos revisados del primer taller internacional sobre sistemas
peer-to-peer, IPTPS '01, (Londres, Reino Unido), págs. 251–260, Springer-Verlag, 2002.
[33] B. Carlsson y R. Gustavsson,El ascenso y la caída de Napster: un enfoque evolutivo, págs. 347–354.
Springer Berlín Heidelberg, 2001.
[34] “Google Cloud Storage SLA”. Recuperado de[Link] mayo de 2017.

[35] BP B, K. Bertels y S. Vassiliadis, “Un estudio de redes peer-to-peer”, en16º taller sobre circuitos,
sistemas y procesamiento de señales (proRISC), 2005.
[36] J. Liang, R. Kumar y K. Ross, “La superposición KaZaA: un estudio de medición”, septiembre de 2004.
[37] O. Heckmann, A. Bock, A. Mauthe y R. Steinmetz, “La red de intercambio de archivos eDonkey”, en Año
de graduación de GI (2)(P. Dadam y M. Reichert, eds.), vol. 51 deLNI, págs. 224–228, GI.
[38] EK Lua, J. Crowcroft, M. Pias, R. Sharma y S. Lim, “Un estudio y comparación de esquemas de redes
superpuestas peer-to-peer”,Comun. Encuestas Tuts., vol. 7, págs. 72–93, abril de 2005.

21
[39] MJ Freedman, E. Freudenthal y D. Mazieres, “Democratizar la publicación de contenidos con coral”, en
Procedimiento 1.º INDE, (San Francisco, California), 2004.
[40] V. Ramasubramanian y EG Sirer, “Beehive: rendimiento de búsqueda O(1) para distribuciones de consultas de
ley de potencia en superposiciones peer-to-peer”, enActas de la 1ª Conferencia sobre el Simposio sobre
Diseño e Implementación de Sistemas en Red - Volumen 1, NSDI'04, págs. 8–8, 2004.
[41] MJ Freedman, “Experiencias con coralcdn: una visión operativa de cinco años”, enActas de la 7ª
Conferencia USENIX sobre diseño e implementación de sistemas en red, ENDI'10, 2010.
[42] C. Lesniewski-Laas y MF Kaashoek, “Whānau: una tabla hash distribuida a prueba de Sybil”, en Actas del
7º Simposio USENIX sobre diseño e implementación de sistemas en red (NSDI '10), (San José, CA), abril
de 2010.
[43] C.-H. Lee, X. Xu y DY Eun, “Más allá del recorrido aleatorio y los muestreadores de Metropolis-Hastings:
por qué no debería retroceder para obtener un muestreo de gráficos imparcial”, enActas de la 12ª
Conferencia internacional conjunta ACM SIGMETRICS/PERFORMANCE sobre medición y modelado de
sistemas informáticos, SIGMETRICS '12, págs. 319–330, 2012.
[44] “¿Qué es un identificador de bloque?.”[Link]
[45] “Libro blanco de Chainpoint”.[Link]

22