¿Podría SPV soportar mil millones de usuarios de Bitcoin ? Evaluando una afirmación de escalabilidad

Jameson Lopp es ingeniero de software en BitGo, creador de statoshi.info y fundador de bitcoinsig.com.

En este artículo de Opinión , Lopp analiza en profundidad las afirmaciones de que es seguro eliminar el límite de tamaño de bloque de Bitcoin y, en su lugar, confiar en los métodos existentes de "verificación de pago simplificada" (SPV).

Una nueva afirmación se está perpetuando en el debate sobre la escalabilidad de Bitcoin .

Hemos escuchado que es seguro eliminar el límite de tamaño de bloque porque Bitcoin puede escalar fácilmente a bloques enormes que darían soporte a miles de millones de usuarios mediante los métodos existentes de "verificación simplificada de pagos" (SPV). Supuestamente, SPV es muy escalable debido a la pequeña cantidad de datos que requiere que un cliente SPV almacene, envíe y reciba.

Profundicemos en esta afirmación y examinémosla desde múltiples perspectivas.

Cómo funciona SPV

Satoshi

describió el diseño de alto nivel para SPV en elLibro blanco de Bitcoin, aunque no se implementó hasta dos años después cuando Mike Hearn creó BitcoinJ.

Al descartar transacciones que no eran relevantes para la billetera del cliente SPV, logró obtener ahorros sustanciales en el uso del disco. Se necesitaron otros 18 meses para... BIP 37Se publicará una especificación para el filtrado Bloom de transacciones, basándose así en la raíz Merkle del encabezado del bloque para demostrar la inclusión de una transacción en un bloque, como Satoshi había descrito. Esto redujo considerablemente el uso del ancho de banda.

Cuando un cliente SPV se sincroniza con la red Bitcoin , se conecta a ONE o más nodos Bitcoin totalmente validados, determina el último bloque en la punta de la cadena y luego solicita todos los encabezados de bloque con un comando "getheaders" para los bloques desde el último bloque que sincronizó hasta la punta de la cadena.

Si el cliente SPV solo está interesado en transacciones específicas correspondientes a una billetera, construirá un filtro Bloom basado en todas las direcciones para las cuales su billetera posee claves privadas y enviará un comando "filterload" a los nodos completos para que sepan que solo deben devolver transacciones que coincidan con el filtro.

Después de sincronizar los encabezados de bloque y posiblemente cargar un filtro Bloom, el cliente SPV envía un comando "getdata" para Request cada bloque individual (posiblemente filtrado) que no pudo ver desde la última vez que estuvo en línea, secuencialmente.

Una vez que el cliente está sincronizado, si permanece conectado a los pares del nodo completo, solo recibirá mensajes de inventario "inv" para las transacciones que coincidan con el filtro Bloom cargado.

Escalado de clientes SPV

Desde el punto de vista del cliente, el filtrado de Bloom es un medio muy eficiente para encontrar transacciones relevantes en la cadena de bloques, utilizando al mismo tiempo recursos mínimos de CPU, ancho de banda y espacio en disco.

Cada encabezado de bloque de Bitcoin ocupa tan solo 80 bytes, por lo que, al momento de escribir este artículo, solo representa 38 megabytes de datos para los más de ocho años de historia de la cadena de bloques. Cada año (aproximadamente 52 560 bloques), solo se añaden 4,2 megabytes, independientemente del tamaño de los bloques en la cadena de bloques.

El árbol de Merkle que se utiliza para demostrar la inclusión de una transacción en un bloque también escala muy bien. Dado que cada nueva capa que se añade al árbol duplica el número total de hojas que puede representar, no se necesita un árbol muy profundo para demostrar de forma compacta la inclusión de una transacción, incluso en un bloque con millones de transacciones.

a través de Dominando Bitcoin

La estructura de datos del árbol de Merkle es tan eficiente que puede representar 16 millones de transacciones con una profundidad de tan solo 24, lo que basta para representar un bloque de 8 GB. Sin embargo, la prueba del árbol de Merkle para dicha transacción ocupa menos de 1 KB.

📷víaDominando Bitcoin

Está bastante claro que, desde la perspectiva de un cliente SPV, la red Bitcoin podría escalarse a bloques de varios gigabytes y los clientes SPV tendrían pocos problemas para procesar las pequeñas cantidades de datos requeridas, incluso en un teléfono móvil con una conexión 3G.

Pero, por desgracia, escalar la red de Bitcoin no es tan sencillo.

Escalado del servidor SPV

Si bien SPV es increíblemente eficiente para los clientes, no lo es para el servidor, es decir, los nodos completos a los que los clientes SPV realizan solicitudes. Este método presenta baja escalabilidad por diversas razones.

Los nodos de la red deben procesar una cantidad enorme de datos para devolver los resultados de un solo par, y deben repetir este trabajo en cada bloque para cada par que lo solicita. La E/S de disco se convierte rápidamente en un cuello de botella.

Cada cliente SPV debe sincronizar toda la blockchain desde la última vez que tuvo contacto con la red o, si cree que no detectó transacciones, deberá volver a escanear toda la blockchain desde la fecha de creación de la billetera. En el peor de los casos, al momento de escribir este artículo, esto representa aproximadamente 150 GB. El nodo completo debe cargar cada bloque del disco, filtrarlo según las especificaciones del cliente y devolver el resultado.

Dado que las cadenas de bloques son un tipo de libro de contabilidad de solo anexión, esta cantidad nunca dejará de crecer. Sin cambios de protocolo extensos, la poda de cadenas de bloques es incompatible con BIP 37, ya que espera que todos los bloques estén disponibles en todos los nodos completos que anuncian NODE_BLOOM.

A los clientes SPV de BIP 37 se les puede engañar por omisión. Para evitarlo, los clientes SPV se conectan a múltiples nodos (generalmente cuatro) aunque aún no es una garantía: los clientes SPV pueden ser particionados de la red principal por un ataque Sybil. Esto multiplica por cuatro la carga en la red de nodos completos.

Para cada cliente SPV conectado que se haya sincronizado con la punta de la cadena de bloques, cada bloque y transacción entrante debe filtrarse individualmente. Esto implica un consumo considerable de tiempo de CPU y debe realizarse por separado para cada cliente SPV conectado.

Analizando los números

Al momento de escribir este artículo, hay aproximadamente 8300 nodos completos en ejecución que aceptan conexiones entrantes; unos 8000 de ellos anuncian NODE_BLOOM y, por lo tanto, deberían ser capaces de atender solicitudes de clientes SPV. Pero, ¿cuántos clientes SPV puede soportar razonablemente el número actual de nodos completos en escucha?

¿Qué se necesitaría para que la red estuviera compuesta de nodos completos que pudieran soportar mil millones de usuarios diarios y bloques lo suficientemente grandes como para acomodar sus transacciones?

Bitcoin CORE tiene un máximo predeterminado de 117 conexiones entrantes, lo que generaría un límite superior de 936 000 sockets disponibles en la red. Sin embargo, la mayoría de estos sockets ya están ocupados.

Cada nodo completo se conecta a otros ocho nodos completos por defecto. Luke-Jr, desarrollador de Bitcoin CORE (en borrador). recuento de nodos Se estima que hay 100 000 nodos en total al momento de escribir este artículo; 92 000 de los cuales no tienen sockets disponibles para clientes SPV. Esto consume 800 000 sockets disponibles solo para nodos completos, dejando solo 136 000 sockets disponibles para clientes SPV.

Esto me lleva a concluir que alrededor del 85 % de los sockets disponibles son consumidos por la malla de nodos completos. (Cabe destacar que el método de estimación de Luke-Jr no puede determinar cuánto tiempo pasan conectados los nodos que no escuchan; seguramente al menos algunos se desconectan y reconectan periódicamente).

Mi nodo que alimentastatoshi.infoTiene un promedio de 100 pares de nodo completo (ocho salientes y 92 entrantes) y 25 clientes SPV. Esto representa el 80 % de los sockets disponibles, que son utilizados por nodos completos.

Si queremos que mil millones de clientes SPV puedan usar un sistema así, será necesario contar con suficientes recursos de nodo completo disponibles para atenderlos: sockets de red, ciclos de CPU, E/S de disco, etc. ¿Podemos hacer que los cálculos funcionen?

Para darle a las afirmaciones de escalamiento de SPV el beneficio de la duda, utilizaré algunas suposiciones conservadoras de que cada uno de los mil millones de usuarios de SPV:

– Enviar y recibir una transacción por día.

– Sincronizar su billetera con la punta de la cadena de bloques una vez al día.

– Consulta cuatro nodos diferentes al sincronizar para reducir las probabilidades de que te mientan por omisión.

Mil millones de transacciones diarias, si se distribuyeran uniformemente (lo cual seguramente no ocurriría), resultarían en aproximadamente 7 millones de transacciones por bloque. Debido a la gran escalabilidad de los árboles de Merkle, solo se necesitarían 23 hashes para demostrar la inclusión de una transacción en dicho bloque: 736 bytes de datos más un promedio de 500 bytes para la transacción.

Si agregamos otros 12 KB de encabezados de bloque por día, un cliente SPV seguiría utilizando solo alrededor de 20 KB de datos por día.

Sin embargo, mil millones de transacciones diarias generan 500 GB de datos de blockchain que los nodos completos almacenan y procesan. Y cada vez que un cliente SPV se conecta y solicita encontrar las transacciones de su billetera del día anterior, cuatro nodos completos deben leer y filtrar 500 GB de datos cada uno.

Recordemos que actualmente hay alrededor de 136.000 sockets disponibles para clientes SPV en la red de 8.000 nodos completos que los sirven. Si cada cliente SPV usa cuatro sockets, solo 34.000 clientes pueden sincronizarse con la red simultáneamente. Si hubiera más personas conectadas a la vez, otros usuarios que intentaran abrir su billetera recibirían errores de conexión al intentar sincronizar con la punta de la blockchain.

Por lo tanto, para que la red actual admita mil millones de usuarios de SPV que se sincronizan una vez al día, aunque solo 34 000 pueden sincronizarse en un momento dado, son 29 400 "grupos" de usuarios que deben conectarse, sincronizarse y desconectarse: cada usuario debería poder sincronizar los datos del día anterior en menos de tres segundos.

Esto plantea un BIT enigma, ya que requeriría que cada nodo completo pudiera leer y filtrar 167 GB de datos por segundo por cliente SPV de forma continua. Con 20 clientes SPV por nodo completo, eso equivale a 3333 GB por segundo. Desconozco cualquier dispositivo de almacenamiento capaz de tal rendimiento. Debería ser posible crear una enorme matriz RAID 0 de discos de estado sólido de alta gamaque pueden alcanzar alrededor de 600 MB/s cada uno.

Necesitaría 5555 unidades para alcanzar el rendimiento objetivo. El disco de ejemplo enlazado cuesta 400 $ al momento de escribir este artículo y tiene aproximadamente 1 TB de capacidad, suficiente para almacenar bloques equivalentes a dos días en esta red teórica. Por lo tanto, necesitaría una nueva matriz de discos cada dos días, lo que costaría más de 2,2 millones de $; esto equivale a más de 400 millones de $ para almacenar bloques equivalentes a un año y, al mismo tiempo, mantener el rendimiento de lectura requerido.

Por supuesto, podemos experimentar con estas suposiciones y ajustar varias cifras. ¿Podemos crear un escenario en el que el coste del nodo sea más razonable?

Vamos a intentarlo:

¿Qué pasaría si tuviéramos 100 000 nodos completos, todos con discos giratorios de alta capacidad y más económicos, y de alguna manera los convenciéramos de aceptar conexiones de clientes SPV? ¿Y si además modificáramos el software del nodo completo para que admitiera 1000 clientes SPV conectados?

Esto nos daría 100 millones de sockets disponibles para clientes SPV, capaces de soportar 25 millones de clientes SPV simultáneos en la red. Por lo tanto, cada cliente SPV dispondría de 2160 segundos al día para sincronizarse con la red. Para que un nodo completo pudiera KEEP la demanda, necesitaría mantener una velocidad de lectura constante de 231 MB/s por cliente SPV, lo que resultaría en 231 GB/s suponiendo 1000 clientes SPV conectados.

Un disco duro de 7200 RPM puede leer aproximadamente 220 MB/s, por lo que podría lograr este rendimiento de lectura con una matriz RAID 0 de un BIT más de 1000 unidades.

Al momento de escribir esto, puedes comprar unoUnidad de 10 TB por 400 dólares, por lo tanto, una matriz RAID de estas unidades de $400,000 le permitiría almacenar bloques equivalentes a 20 días: esto equivale a una cantidad mucho más manejable de $7.2 millones para almacenar bloques equivalentes a un año y al mismo tiempo lograr los requisitos de rendimiento de lectura de disco.

Cabe destacar que ONE en su sano juicio utilizaría una matriz RAID 0 con tantas unidades, ya que un solo fallo dañaría toda la matriz. Por lo tanto, una matriz RAID con tolerancia a fallos sería aún más cara y de menor rendimiento. Además, parece increíblemente optimista que 100 000 organizaciones estén dispuestas a desembolsar millones de dólares al año para operar un nodo completo.

Otro punto a destacar es que estas estimaciones conservadoras también suponen que los clientes SPV se coordinarían de alguna manera para distribuir sus tiempos de sincronización uniformemente a lo largo del día. En realidad, habría picos y valles de actividad cíclicos diarios y semanales; la red necesitaría una capacidad considerablemente mayor a la estimada anteriormente para satisfacer la demanda máxima.

De lo contrario, muchos clientes SPV no podrían sincronizarse durante las horas pico de uso.

Curiosamente, resulta que cambiar el número de sockets por nodo no afecta la carga total de ningún nodo completo; este sigue necesitando procesar la misma cantidad de datos. Lo que realmente importa en esta ecuación es la proporción de nodos completos por cliente SPV. Y, por supuesto, el tamaño de los bloques en la cadena que los nodos completos necesitan procesar.

El resultado final parece ineludible: el costo de operar un nodo completo capaz de atender la demanda de SPV de mil millones de transacciones diarias en cadena sería astronómico.

Buscando un punto medio

A estas alturas, está bastante claro que mil millones de transacciones por día ponen el costo de operar un nodo con validación completa fuera del alcance de todas las entidades, excepto las más ricas.

Pero, ¿qué sucede si invertimos este cálculo y, en cambio, tratamos de encontrar una fórmula para determinar el costo de agregar carga a la red incrementando el rendimiento de las transacciones en cadena?

Para que la red Bitcoin admita una cantidad objetivo de transacciones por segundo (sumando capacidad para 86.400 nuevos usuarios diarios netos), podemos calcular los requisitos de rendimiento de disco por nodo como:

Esto nos da el rendimiento mínimo de lectura de disco por segundo para que un nodo completo atienda la demanda de los clientes SPV. Con las características actuales de la red y la Tecnología disponible, podemos extrapolar un costo estimado de operación del nodo utilizando el rendimiento de disco como cuello de botella supuesto. Tenga en cuenta que seguramente habrá otras limitaciones de recursos que entrarán en juego, lo que incrementará el costo de operación del nodo completo.

Para elcálculos siguientesUtilicé estas suposiciones:

– Tamaño promedio de transacción en bytes = 500 bytes segúnstatoshi.info.

– Número total de usuarios de SPV = ONE por transacción por día.

– Sockets consumidos por un cliente SPV = estándar de cuatro.

– Número de sockets disponibles para clientes SPV en cada nodo completo = número calculado previamente de 20.

– Total de sockets de red disponibles para clientes SPV = número calculado previamente de 136 000.

– Costo del espacio y el rendimiento del disco duro = $400 Unidades de 10 TB y 7200 RPM en configuración RAID 0.

Desafortunadamente, los requisitos de rendimiento del disco y, por lo tanto, el costo de operar un nodo completo aumentan cuadráticamente en relación con el número de transacciones por segundo. Los costos se vuelven rápidamente insostenibles para la mayoría de las entidades.

Como referencia, recuerde que Visa procesa aproximadamente 2000 transacciones por segundo. En Bitcoin , esto requeriría discos por un valor de casi 200 000 dólares solo para KEEP la demanda de SPV. ONE destacar que estos gráficos KEEP el número de nodos completos constante en 8000; en realidad, probablemente disminuirían a medida que aumentara el costo, lo que aceleraría aún más los requisitos de rendimiento y el costo de operación de los nodos restantes.

Esto parece ser una fuerza agravante de la centralización de nodos.

Las encuestas (poco científicas) que realicé un año antes mostraban que el 98 % de los operadores de nodos no pagarían más de 100 $ al mes por operar un nodo, incluso si tuvieran una gran inversión en Bitcoin. Apuesto a que un aumento de un orden de magnitud en las transacciones en cadena de bitcoin resultaría en la pérdida de la mayoría de los nodos completos, mientras que un aumento de dos órdenes de magnitud resultaría en la pérdida del 90 % o más de los nodos.

Creo que es seguro asumir que muy pocas entidades estarían dispuestas a tomarse la molestia de construir matrices RAID para ejecutar un nodo completo. De ser así, es insostenible afirmar que tales aumentos serían convenientes para el usuario promedio, ya que no habría suficiente rendimiento de disco de nodo completo ni suficientes sockets disponibles para satisfacer la demanda de SPV.

Otras debilidades del SPV

SPV es ideal para usuarios finales que no requieren la seguridad ni la Privacidad de un nodo con validación completa. Sin embargo, existen numerosas razones que podrían considerarse limitantes para una red Bitcoin compuesta principalmente por SPV, independientemente de su escalabilidad.

SPV realiza suposiciones importantes que dan como resultado una seguridad y Privacidad más débiles que un nodo con validación completa:

• Los clientes de SPV confían en que los mineros validarán y aplicarán correctamente las reglas de Bitcoin; asumen que la blockchain con la mayor prueba de trabajo acumulada también es válida. Puedes Aprende sobre la diferencia entre los modelos de seguridad de SPV y de nodo completo en este artículo.
• Los clientes SPV asumen que los nodos completos no les mentirán por omisión. Un nodo completo no puede mentir diciendo que una transacción existió en un bloque cuando en realidad no existió, pero sí puede mentir diciendo que una transacción que sí existe en un bloque no ocurrió.
• Debido a que los clientes SPV buscan la eficiencia, solo Request datos de las transacciones que les pertenecen. Esto resulta en una pérdida masiva de Privacidad.

Curiosamente, el coautor de BIP 37, Matt Corallo,se arrepiente de haberlo creado:

Un problema importante hoy en día para la Privacidad de los usuarios del sistema son los filtros de bloom BIP37 SPV. Lo siento, lo escribí yo.

Los clientes SPV con filtro Bloom de BIP 37 tienenBásicamente no hay PrivacidadIncluso con tasas de falsos positivos irrazonablemente altas, Jonas Nick [ingeniero de seguridad de Blockstream] descubrió que, con una sola clave pública, podía determinar el 70 % de las demás direcciones pertenecientes a una billetera determinada.

[incrustar]https://www.youtube.com/watch?v=HScK4pkDNds[/incrustar]

Se puede solucionar la poca Privacidad de SPV dividiendo los filtros Bloom entre muchos pares, aunque esto empeoraría aún más la escalabilidad de SPV al colocar más carga en más nodos completos.

BIP 37 también es vulnerable a ataques triviales de denegación de servicio. El código de demostración esdisponible aquíque es capaz de paralizar nodos completos al realizar muchas solicitudes de inventario rápidas a través de filtros especialmente construidos que provocan una búsqueda continua de disco y un alto uso de CPU.

El autor de la prueba de concepto del ataque, el desarrollador CORE Peter Todd, explica:

"El problema fundamental es que se puede consumir una cantidad desproporcionada de ancho de banda de E/S de disco con muy poco ancho de banda de red".

Incluso a día de hoy, las alertas de fraude que Satoshi describió en el libro blanco no se han implementado. De hecho, las investigaciones en este ámbito han demostrado que podría no ser posible implementar alertas de fraude ligeras.

Por ejemplo, una alerta de fraude solo funciona si se obtienen los datos necesarios para demostrar el fraude; si un minero no proporciona esos datos, no se puede generar la alerta. Por lo tanto, los clientes SPV no cuentan con el nivel de seguridad que Satoshi imaginó.

Desde una perspectiva general, un mundo compuesto principalmente por nodos SPV facilita enormemente los cambios de consenso, como el límite total de monedas o incluso la edición del libro mayor. Menos nodos con validación completa implican una aplicación más centralizada de las reglas de consenso y, por lo tanto, una menor resistencia a su modificación. Algunos pueden considerarlo una característica; la mayoría, sin duda, un defecto.

Posibles mejoras

La seguridad y escalabilidad de SPV podrían mejorarse de diversas maneras mediante pruebas de fraude, indicios de fraude, pruebas de entrada, pruebas de gasto, etc. Sin embargo, que yo sepa, ninguna de estas ha superado la fase de concepto, y mucho menos está lista para su implementación en producción.

Compromisos del filtro Bloom

podría mejorar la Privacidad, pero existe una compensación en cuanto a utilidad entre el tamaño del filtro y su tasa de falsos positivos: si es demasiado grueso, los pares descargarán demasiados bloques de falsos positivos, y si es demasiado fino, los filtros serán absolutamente gigantescos y poco prácticos para que cualquiera los descargue con un cliente SPV.

Esto reduciría la carga en el rendimiento del disco de nodo completo, pero la contrapartida sería un mayor ancho de banda tanto para los clientes SPV como para los nodos completos porque se tendrían que transferir bloques enteros a través de la red.

Este Filtrado compacto del lado del cliente propuesto recientemente Elimina los problemas de Privacidad , pero requiere que se descarguen bloques completos si hay una coincidencia con el filtro (¡aunque no necesariamente a través de la red p2p!).

Compromisos de UTXO

Podría permitir que los clientes SPV sincronicen su conjunto actual de UTXO y, por lo tanto, el saldo de su billetera sin necesidad de que el nodo completo escanee toda la blockchain. En cambio, proporcionaría una prueba de la existencia de las UTXO.

Es posible que sea posible protegerse contra ataques DoS de filtro Bloom al requerir que los clientes SPV envíen una prueba de trabajo (insostenible en un dispositivo alimentado por batería como un teléfono) o micropagos basados ​​en canales (imposibles de iniciar si un cliente aún no ha recibido dinero), pero ninguno ofrece una solución directa.

Los requisitos de lectura de disco para nodos completos probablemente podrían reducirse de varias maneras mediante una mejor indexación de datos y el procesamiento por lotes de solicitudes de clientes SPV.

Ryan X Charles señaló en los comentarios que usar el protocolo de pago de BIP70 para indicar directamente a alguien el ID UTXO del pago que se le envía eliminaría la necesidad de usar filtros Bloom, ya que podrían Request los datos directamente a los nodos completos. Esto es increíblemente eficiente si se está dispuesto a aceptar la compensación por la Privacidad .

Basta decir que hay mucho margen de mejora: será necesario superar muchos desafíos para mejorar la escalabilidad en cadena.

Soluciones de escalado adecuadas

Si ignoramos la multitud de otros problemas diversos con el escalamiento a tamaños de bloques más grandes, como la latencia de propagación de bloques, el escalamiento del conjunto UTXO, los tiempos de sincronización inicial de la cadena de bloques y las compensaciones de seguridad y Privacidad , puede ser técnicamente posible escalar Bitcoin a mil millones de usuarios diarios en cadena si hay entidades dispuestas a invertir recursos significativos para desarrollar mejoras de software y operar la infraestructura requerida.

Sin embargo, parece muy improbable que Bitcoin evolucione orgánicamente de esa manera, ya que existen maneras mucho más eficientes de escalar el sistema. La más eficiente es una forma de escalado que ya se utiliza: la consolidación en torno a proveedores de API centralizados. Suele haber grandes sacrificios en términos de confianza y Privacidad al emplear estos métodos, pero muchas de estas interacciones implican acuerdos contractuales que mitigan algunos de los riesgos.

En términos de escalado sin necesidad de confianza, los protocolos de Capa 2 como Lightning ofrecen un escalado mucho más eficiente, ya que los grandes volúmenes de datos transferidos solo se envían entre un pequeño número de partes directamente involucradas en una transacción fuera de la cadena. Se puede considerar la diferencia entre una capa de comunicación Ethernet de difusión general y una capa IP enrutada: Internet no podría escalar sin enrutamiento, ni tampoco el Internet del Dinero.

Si bien este enfoque de escalamiento es mucho más complejo técnicamente que el escalamiento centralizado tradicional y requerirá superar algunos desafíos únicos, la inversión inicial de recursos para la investigación y el desarrollo de estos protocolos de enrutamiento rendirá enormes dividendos a largo plazo, ya que reducen la carga que debe soportar toda la red en órdenes de magnitud.

También hay muchas opciones intermedias que se pueden explorar:

– Esquemas de custodia centralizados con Privacidad perfecta que utilizan tokens Chaum como HashCash.

– Sistemas centralizados de prueba de conocimiento cero sin custodia, comoTumbleBit.

– Cadenas laterales federadas (multifirma semiconfiables) https://elementsproject.org/sidechains/.

– Protegido por mineros (semi-confiable)cadenas de transmisión.

Soy Todavía convencido que a largo plazo, Bitcoin necesitará bloques mucho más grandes.

Pero seamos pacientes y diplomáticos e intentemos escalar el sistema lo más eficientemente posible mientras mantenemos sus propiedades de seguridad y Privacidad .

Un PayPal auditable y ligeramente descentralizado seguramente tendría utilidad si fuera funcional desde el punto de vista del usuario promedio, pero no ofrecería el nivel de soberanía financiera del que disfrutan hoy los bitcoiners.

Gracias a Matt Corallo, Mark Erhardt y Peter Todd por revisar y brindar comentarios sobre este artículo.

Aviso legal: CoinDesk es una subsidiaria de Digital Currency Group, que tiene participación accionaria en Blockstream.