Estandarizar SPV y tokens para cinco mil millones de usuarios activos diarios.
Por Ryan X Charles
Introducción
Para llegar a cinco mil millones de usuarios activos diarios de Bitcoin, es importante implementar y estandarizar las billeteras de Pago Simplificado Verificado (SPV) con soporte para activos digitales tokenizados, incluidas las principales monedas fiduciarias del mundo como el dólar estadounidense.
Podemos resumir estas iniciativas de la siguiente manera:
- Implementar y estandarizar carteras SPV . Carteras SPV, descritas en el libro blanco original pero nunca implementado por completo, permite a los usuarios poseer y realizar transacciones en efectivo digital. Aunque el usuario no sabrá cómo funciona, lo que sucede es que su dispositivo envía y recibe automáticamente transacciones de otras personas y entidades y verifica las propias transacciones del usuario. Esto no solo permite todos los casos de uso sin custodia, como pequeñas transacciones en efectivo, sino que también es importante para la seguridad de Bitcoin en su conjunto que los encabezados de bloque se distribuyan ampliamente en las carteras SPV del usuario final. La amplia distribución de los encabezados de bloque es lo que evita que los nodos cometan fraude y es la característica central que distingue a una cadena de bloques pública frente a una base de datos privada. No solo necesitamos implementar SPV, sino que debemos hacerlo de una manera estandarizada e interoperable a través del ecosistema.
- Implemente y estandarice activos digitales tokenizados en Bitcoin . La mayoría de las personas no enviarán ni recibirán Bitcoin de forma consciente. En cambio, enviarán y recibirán su moneda fiduciaria local u otros activos digitales como acciones y bonos. Bajo el capó, Bitcoin se está utilizando para pagar a los nodos para sellar su transacción en la cadena de bloques. Pero los costos son tan pequeños que resultan insignificantes para la mayoría de los usuarios. Para que los tokens funcionen en Bitcoin, necesitamos tanto los protocolos técnicos para hacerlo como las empresas (y tal vez los gobiernos) para respaldar los activos. Es importante que estos protocolos estén estandarizados para que puedan implementarse y usarse ampliamente en todo el ecosistema.
Esta no es una lista completa de tareas que debemos completar para llegar a cinco mil millones de usuarios activos diarios. Necesitamos aprender, construir, probar, iterar, reconstruir, educar, comercializar, vender y otra vez como cualquier otra industria. En este artículo nos vamos a concentrar solo en la parte de estándares técnicos de la iniciativa. Nuestro objetivo es estandarizar todo lo necesario para llegar a cinco mil millones de usuarios activos diarios.
El Comité de Normas Técnicas
La Asociación de Bitcoin anunció recientemente el Comité de Normas Técnicas (TSC) . El objetivo del TSC es establecer y mantener un proceso para crear estándares técnicos que utilicen Bitcoin como protocolo base. El TSC en realidad no creará estándares, pero se asegurará de que cualquier persona que desee crear un estándar tenga un proceso claro a seguir que dará como resultado estándares reales que se utilizan ampliamente.
Paymail ( consulte también la documentación de Money Button ) es un ejemplo de un estándar que ya hemos creado, pero que aún no se ha estandarizado formalmente. Crearemos un estándar formal para paymail y todos los demás estándares que necesitamos para dar como resultado SPV y tokens en todo el ecosistema. Debido a que los tokens son tan críticos para los casos de uso de Bitcoin, y debido a que los protocolos de tokens están altamente vinculados a muchos estándares posibles relacionados con SPV, incluimos la hoja de ruta de tokens junto con la hoja de ruta de SPV.
Money Button y otras compañías seguirán el proceso descrito por el TSC para comenzar a estandarizar el futuro de las billeteras, incluyendo especialmente SPV y tokens. Este artículo motiva el proceso de estandarización para aumentar la colaboración en todo el ecosistema, ya que los estándares requieren un amplio acuerdo por su naturaleza.
La definición de SPV y tokens
No hay carteras SPV en este momento. Esto es un poco sorprendente teniendo en cuenta que SPV se describió en el documento técnico original. ¿Por qué ninguna billetera realmente ha implementado SPV?
Esencialmente, se ha pasado por alto el SPV porque Bitcoin ha sido ampliamente malinterpretado y mal implementado. Muchas personas que se involucraron en Bitcoin estaban motivadas para hacer algo más que crear las tuberías de la economía mundial. Su visión no requería escala, seguridad, experiencia del usuario o legalidad, por lo que nunca implementaron SPV.
Para aquellos de nosotros que queremos una adopción mundial y que creemos que la visión original de Bitcoin nos llevará allí, debemos ocuparnos de lo básico ahora. Es nuestra responsabilidad hacer que se realicen SPV y tokens.
Actualmente existen carteras sin custodia, pero no llegan lo suficientemente lejos para un SPV real. Las propiedades de una billetera SPV son las siguientes :
- Las transacciones deben enviarse de igual a igual . No hay ninguna razón para que un pagador confíe en que una transacción se transmita a través de nodos cuando podría entregar la transacción de igual a igual directamente al destinatario. Esto permite transacciones instantáneas y es mucho más escalable, ya que no requiere que el destinatario escanee la cadena de bloques o se suscriba a un servicio para encontrar su pago.
- Las transacciones deben incluir entradas y pruebas de Merkle . Para que el destinatario valide su transacción mientras está fuera de línea, es importante que pueda ver las transacciones de entrada y las pruebas de inclusión (pruebas de Merkle) para las entradas. Las transacciones de entrada son necesarias para validar la transacción y las pruebas de Merkle son necesarias para saber que las monedas provienen originalmente de la cadena de bloques. Aunque muchas personas estarán en línea cuando reciban una transacción, es importante que nuestros protocolos no excluyan casos de uso realistas y que las conexiones a Internet no sean 100% confiables. El caso de uso fuera de línea también es importante para la futura extensibilidad para admitir canales de pago que no se envían a los nodos.
- Las billeteras deben rastrear los encabezados de bloque de los nodos . La billetera del usuario final puede rastrear los últimos encabezados de bloque de los nodos utilizando una forma estandarizada de Miner ID y Merchant API . Si alguna vez se da el caso de que un nodo comete un fraude, por ejemplo, al cambiar los encabezados del bloque, es importante que los encabezados del bloque se distribuyan ampliamente para evitarlo. Esto no requiere que las billeteras del usuario final hagan algo costoso (SPV es barato), pero sí requiere que los desarrolladores de billeteras sean conscientes de hacer SPV correctamente para asegurarse de que exista este mecanismo de seguridad.
Los tokens necesitan las siguientes propiedades:
- Protocolo de token estandarizado, o al menos un protocolo de envoltura . Actualmente no tenemos un protocolo de token estandarizado, pero hay varios en desarrollo. Si es posible, es deseable tener solo un estándar para que las empresas tengan menos que implementar. Sin embargo, algunos protocolos de token pueden ser más apropiados para algunos casos de uso que para otros. Para permitir esto, puede ser mejor estandarizar un contenedor de tokens que nos permita usar tokens de manera interoperable entre servicios sin preocuparnos por los detalles dentro de cada protocolo. Esto permitirá que exista un mercado de muchos protocolos diferentes y, al mismo tiempo, limitará la cantidad de trabajo que deben realizar las empresas para implementar nuevos protocolos.
- Empresas o gobiernos del mundo real que respaldan activos . Los tokens no son útiles si no tienen valor. Es importante que tengamos acciones, bonos y monedas fiduciarias del mundo real. Cada una de estas clases de activos tiene muchos tipos diferentes de activos emitidos por gobiernos o corporaciones en todo el mundo. Puede haber muchas iniciativas paralelas en lugares que resuelvan diferentes piezas de este rompecabezas. Los protocolos de token deben desarrollarse en colaboración con estas empresas para asegurarse de que los protocolos se utilicen realmente.
SPV y tokens, por su naturaleza, requieren estándares interoperables. Una billetera que implementa SPV y tokens de forma patentada no tiene ninguna ventaja sobre los sistemas que ya existen, como el pago centralizado y la gestión de datos. Para obtener los beneficios de Bitcoin, estas cosas deben estandarizarse para permitir un mercado competitivo.
Por qué SPV y los tokens son importantes para cinco mil millones de usuarios activos diarios
SPV y tokens son requisitos previos para cinco mil millones de usuarios activos diarios por las siguientes razones:
- SPV es necesario para escalar Bitcoin . A medida que aumenta el volumen de transacciones en la red, aumenta el costo de ejecutar el software del nodo. Ya es un costo prohibitivo para los usuarios normales ejecutar el software del nodo y solo se volverá más costoso. Siempre ha sido la intención que los usuarios finales ejecuten SPV, que requiere una potencia computacional lo suficientemente baja como para que incluso los teléfonos con funciones puedan hacerlo. SPV ampliamente implementado es la única forma de llegar a cinco mil millones de usuarios activos diarios.
- SPV es necesario para la seguridad de Bitcoin . Curiosamente pasado por alto, es necesario que los encabezados de bloque estén ampliamente distribuidos para que Bitcoin sea seguro. Si todos tienen los encabezados de bloque, nadie puede desenrollar la cadena de bloques. Algunas personas han promovido la idea de que todos deberían ejecutar el software de nodo, lo que daría como resultado que todos tuvieran los encabezados de bloque, pero esto no funcionará porque tiene un costo prohibitivo. Sin embargo, SPV es extremadamente barato y escalable , por lo que es una forma de distribuir los encabezados de bloque ampliamente, casi gratis.
- SPV es necesario para Bitcoin privado . Bitcoin permite a los usuarios poseer realmente sus datos y su dinero. Para muchas transacciones, los usuarios desean privacidad. El efectivo digital en las carteras SPV permite transacciones verdaderamente privadas. Solo el usuario y el destinatario de los fondos saben quiénes son los participantes de la transacción. A medida que aumenta la escala de Bitcoin, aumenta la privacidad porque encontrar una transacción es como encontrar una aguja en un pajar que sigue creciendo. Los usuarios no obtienen estos beneficios si deben confiar en terceros confiables para realizar transacciones en su nombre, porque entonces el tercero confiable lo sabe todo.
- SPV es necesario para Bitcoin utilizable . Bitcoin permite una mejor experiencia de usuario que el sistema de pago tradicional para muchos casos de uso, especialmente pequeñas transacciones en efectivo y micropagos. Las transacciones pequeñas en efectivo no requieren el cumplimiento de Know-Your-Customer (KYC), lo que significa que los usuarios no necesitan escanear su pasaporte para usar el servicio. Por lo tanto, es fácil crear y destruir carteras SPV sin ninguna acción por parte del usuario. El uso de SPV en contraste con una billetera de custodia habilita este caso de uso.
- Los tokens son necesarios para Bitcoin utilizable . Los tokens son clave porque a la mayoría de los usuarios no les importará Bitcoin (BSV), el activo digital. En su lugar, usarán una billetera que administra los activos digitales que realmente les interesan, como su moneda fiduciaria local para transacciones en efectivo o su cartera de inversiones, incluidas acciones y bonos. En la mayoría de los casos, los usuarios no sabrán que están usando Bitcoin, de la misma manera que la mayoría de los usuarios ahora saben que están usando Internet.
SPV y tokens son necesarios (pero no suficientes) para cinco mil millones de usuarios activos diarios.
Una hoja de ruta de estandarización
La intención de este artículo no es argumentar a favor de ningún estándar en particular (excepto los estándares existentes, como paymail ), sino argumentar que necesitamos tener una hoja de ruta de estandarización con estándares pequeños y modulares que se desarrollen desde los estándares más básicos hasta los más complejos. Normas. Cada estándar modular tendrá algunas empresas interesadas en diseñarlo e implementarlo. El hecho de que encajen como piezas de rompecabezas en una hoja de ruta de estandarización alentará a más empresas a incorporarse, ya que verán que el juego final es algo que todos queremos.
Como tal, la siguiente es una hoja de ruta de estandarización hipotética que nos llevará a cinco mil millones de usuarios activos diarios con SPV y tokens. Nuestra esperanza es que las empresas proporcionen comentarios sobre esta hoja de ruta y que los estándares que realmente diseñamos e implementamos resolverán el mismo conjunto de problemas, pero pueden verse diferentes en detalle a los detalles aquí descritos.
1. Paymail
Paymail, tal como se lanzó originalmente, resuelve dos problemas importantes: una forma de tener nombres que sean legibles por humanos y legibles por máquinas simultáneamente, y una forma de tener un punto final para que los usuarios puedan comunicarse (o su dispositivo pueda comunicarse en su nombre) con la otra persona o entidad. También teníamos la capacidad de entregar direcciones y claves públicas en el protocolo de correo de pago original , pero estos deben considerarse MVP de correo de pago . El valor real de Paymail es que es un protocolo extensible para nombrar y realizar consultas y podemos usarlo para resolver muchos de los otros problemas de SPV y tokens. La mayor parte del valor del correo de pago se entregará con el tiempo, ya que se amplía para resolver innumerables problemas que dependen de los nombres y las consultas.
2. Firmas, cifrado e intercambio de claves Diffie-Hellman (DH)
Muchos protocolos que queremos usar además de Bitcoin requerirán datos firmados y / o cifrados. Money Button ya ha implementado firmas y cifrado dentro y fuera de la cadena y se usa ampliamente en todo el ecosistema. Necesitamos estandarizar las firmas y el cifrado por su propio bien, pero también con la intención de que se reutilicen dentro de otros protocolos de nivel superior que se analizan a continuación, como facturas y KYC.
Las firmas y el cifrado a menudo solo tienen sentido en el contexto de un secreto compartido y la derivación de nuevas claves y, como tal, deberían incluir el intercambio de claves DH en estos estándares, junto con cualquier otra primitiva criptográfica que planeemos reutilizar en protocolos de nivel superior. .
Dependencias :
- Paymail . Si bien no todas las firmas o el cifrado deben adjuntarse a un correo de pago , muchos sí. La clave pública en el protocolo de correo de pago original se puede utilizar para firmas, cifrado e intercambio de claves DH.
3. KYC
Las regulaciones de Conozca a su cliente (KYC) juegan un papel importante en todo el ecosistema. Cada vez que un usuario necesita escanear su pasaporte o identificación gubernamental, probablemente se deba a las regulaciones de KYC. Los intercambios y carteras deben seguir las regulaciones de KYC.
KYC puede resultar irritante para el usuario final si tiene que escanear su pasaporte una y otra vez. Pero un concepto relacionado es que al usuario le gusta saber cuál es la verdadera identidad de la parte al otro lado de la transacción, como cuando realiza una compra en una tienda o con otra persona con la que el usuario está comerciando. Esto es bueno para los usuarios finales. Una buena solución para KYC puede resolver ambos problemas, brindando los beneficios de la experiencia del usuario y eliminando la necesidad de escanear el pasaporte una y otra vez.
Esencialmente, la forma de resolver KYC es permitir que empresas de identidad de terceros como Jumio , o carteras o intercambios que actúen en su nombre, firmen el correo de pago de un usuario . Esto, en combinación con un sistema de autenticación de correo de pago estandarizado , permitirá a los usuarios iniciar sesión en los servicios y brindar acceso a la información de KYC sin primero escanear su pasaporte por enésima vez.
La misma tecnología se puede utilizar para permitir que las empresas demuestren su identidad al usuario final oa otras empresas.
Dependencias :
- Paymail . La solución propuesta para KYC requiere una extensión para paymail que permite a los proveedores de KYC de terceros firmar el correo de pago del usuario .
- Firmas, cifrado e intercambio de claves DH . El correo de pago está firmado y los datos privados deberán estar encriptados.
4. Facturas
Los usuarios deben poder enviar y recibir facturas de una manera estandarizada donde un usuario con una billetera puede enviar una factura a otra billetera. La noción de facturas reemplazará casi con certeza el uso casual de enviar dinero a una dirección o un correo de pago . Las facturas se pueden firmar, autenticar y rastrear de una manera que hace que la contabilidad sea mucho mejor que sin ellas. Las facturas son estándar en los negocios y deberíamos ser para Bitcoin.
BIP 270 es un estándar propuesto, pero aún no se ha implementado ampliamente. Podemos usar BIP 270, pero debemos asegurarnos de resolver también los problemas que no resuelve BIP 270, incluida la firma más especialmente de las facturas, que requerirán KYC y estándares relacionados primero.
Dependencias :
- Paymail . Este es el destino y la procedencia de la factura y cómo hacemos KYC.
- Firmas, cifrado e intercambio de claves DH . Se usa solo para firmar / cifrar facturas o se usa en combinación con KYC.
- KYC . La posibilidad de firmar una factura con su nombre real o el nombre de su empresa.
5. NAT transversal
Para enviar mensajes peer-to-peer a través de Internet, que es necesario para enviar transacciones y pruebas de Merkle, debemos preocuparnos por un problema altamente técnico con respecto al funcionamiento de Internet basado en ipv4. Este problema es la traducción de direcciones de red (NAT), lo que significa que el enrutador entre el usuario e Internet cambiará automáticamente su dirección IP y hace que sea bastante difícil enviarles un mensaje directamente desde el exterior a menos que primero hayan establecido una conexión. Existe una variedad de técnicas para resolver este problema. No propondremos ninguna solución en particular aquí, aparte de señalar que las soluciones implican un poco de criptografía y, como tal, cualquier solución probablemente requerirá firmas y cifrado.
Dependencias :
- Firmas, cifrado e intercambio de claves DH . Lo más probable es que se utilice para autenticar a la parte comunicante.
6. Mensajería entre pares
SPV requiere que enviemos transacciones peer-to-peer. Además, las transacciones de entrada y las pruebas de Merkle también se envían junto con el pago. Es posible que un protocolo de mensajería peer-to-peer pueda usarse para otras cosas además de las transacciones (como el chat de usuario a usuario), pero las transacciones serán el caso de uso principal.
Tenga en cuenta que en este ejemplo asumo que las facturas se implementan primero, pero también sería posible construir un sistema de facturas sobre la infraestructura de mensajería de igual a igual.
Dependencias :
- Paymail . El nombre y el punto final de la persona o entidad a la que el usuario está enviando mensajes.
- Firmas, cifrado e intercambio de claves DH . La criptografía se utiliza para todos los mensajes por motivos de privacidad y autenticidad.
- NAT transversal . La única forma de hacer llegar un mensaje a un usuario final es con alguna resolución al cruce de NAT.
7. Pista de auditoría en cadena
Muchos protocolos se vuelven más seguros si los eventos se registran en cadena, incluida la entrega de la dirección de recepción en el correo de pago . Sería útil una forma estandarizada de realizar el registro en cadena.
Dependencias :
- Paymail . Lo más probable es que los registros estén etiquetados con un correo de pago .
- Firmas, cifrado e intercambio de claves DH . Lo más probable es que los registros estén firmados y encriptados con un correo de pago .
8. Transacciones de igual a igual, pruebas de Merkle y transacciones de entrada.
SPV requiere que las transacciones en sí se envíen directamente al destinatario junto con la entrada y las transacciones y las pruebas de Merkle para que el destinatario pueda validar la transacción antes de enviarla a un nodo.
Tenga en cuenta que Money Button, Handcash y Simply.Cash ya han implementado una versión de transacciones de igual a igual , que es un punto de partida útil para SPV completo.
Dependencias :
- Paymail . Dónde enviar la transacción y de dónde proviene.
- Firmas, cifrado e intercambio de claves DH . La criptografía se utiliza para todos los mensajes por motivos de privacidad y autenticidad.
- NAT transversal . La única forma de hacer llegar un mensaje a un usuario final es con alguna resolución al cruce de NAT.
- Mensajería peer-to-peer . Lo más probable es que este protocolo se construya directamente sobre el protocolo de mensajería de igual a igual.
9. Tokens o protocolo de contenedor de tokens
Para facilitar la implementación, es deseable que tengamos exactamente un estándar de protocolo de token. Sin embargo, dada la historia de nuestra industria y la proliferación de proyectos que crean protocolos de token, es posible que nunca tengamos una situación en la que haya un protocolo de token dominante. Por lo tanto, deberíamos considerar estandarizar un protocolo contenedor simple y flexible para tokens que permitirá a los desarrolladores de protocolos de tokens innovar dentro de un contenedor estándar para que.
Los tokens ERC 20 son el protocolo de contenedor de tokens para Ethereum.
Lo más probable es que los tokens no dependan de ninguno de los otros estándares de esta lista, pero pueden usarse dentro de ellos. Por ejemplo, es posible que el protocolo de facturación no comience a admitir tokens, pero es posible que deba ampliarse para hacerlo.
10. Nombres y avatares para paymail
Sería útil ver nombres y rostros junto a los correos de pago en su lista de contactos.
Dependencias :
- Paymail . Para quién es el nombre y el avatar .
- Firmas, cifrado e intercambio de claves DH . Para firmar los nombres y avatares.
11. Cumplimiento del GAFI
El Grupo de Acción Financiera Internacional (GAFI) crea recomendaciones para que los gobiernos nacionales regulen su industria financiera. Las recomendaciones se siguen ampliamente a nivel mundial y debemos cumplirlas. Las nuevas recomendaciones del GAFI requieren que las empresas comuniquen información KYC para transacciones de moneda digital. Ya se ha creado un protocolo para solucionar este problema: InterVASP . Tendremos la opción de usar InterVASP o rodar el nuestro o algunos de ambos.
Dependencias :
- Paymail . Es casi seguro que nuestra solución se debe construir sobre el correo de pago para que el envío y la recepción de transacciones sean simples y compatibles con nuestros sistemas existentes.
- KYC . También tenemos la opción de utilizar nuestra propia tecnología KYC en el protocolo.
12. Autenticación de Paymail o " iniciar sesión con Paymail "
Debido a que Money Button adoptó operaciones criptográficas básicas, incluidas las firmas , las empresas han comenzado a implementar " iniciar sesión con correo de pago " informal al deslizar el botón Money. Esta es una gran solución para el problema de la experiencia del usuario al iniciar sesión en un sitio web sin usar otro nombre de usuario y contraseña nuevos, y también una forma de proporcionar acceso autorizado a la billetera del usuario. Esto hace posibles innumerables aplicaciones y se puede combinar con otros protocolos como KYC para permitir el inicio de sesión único en instituciones financieras sin tener que escanear el pasaporte una vez más. Probablemente sea mejor extender esta idea para convertirla en un protocolo. Podemos llamar a esto autenticación de correo de pago o " iniciar sesión con correo de pago ".
Este protocolo no solo debe permitir que uno inicie sesión, sino que también debe incluir protocolos para otorgar permiso a la billetera del usuario. Por ejemplo, el usuario puede otorgar acceso para gastar pequeñas cantidades de dinero automáticamente o firmar o cifrar o descifrar datos automáticamente. Estas extensiones se pueden agregar después de que se cree primero el protocolo básico para iniciar sesión.
Dependencias :
- Paymail . El nombre que usa para iniciar sesión es su correo de pago y reutilizamos los puntos finales https para otras propiedades del protocolo, como otorgar permiso.
- Firmas, cifrado e intercambio de claves DH . Estos serán necesarios para la autenticación y la privacidad.
Conclusión
Hemos argumentado que SPV y tokens son necesarios para lograr cinco mil millones de usuarios activos diarios para Bitcoin. Cinco mil millones provienen de la cantidad de agentes económicos adultos en el planeta. Si podemos alcanzar este número, podemos decir con confianza que hemos logrado la adopción global de Bitcoin.
Para tener SPV y tokens, no se trata solo de que una empresa los implemente. SPV y los tokens son, por naturaleza, protocolos que deben adoptarse ampliamente para que sean significativos. Deben ser estándares.
El Comité de Normas Técnicas (TSC) se ha creado para facilitar la creación de normas. El siguiente paso es una hoja de ruta en la que las empresas diseñan e implementan estándares que les son útiles en un orden particular que permite que los estándares se reutilicen entre sí con dependencias inteligentes. Comenzamos con los estándares más básicos primero y construimos hacia arriba.
Lo que hemos descrito en este artículo es una hoja de ruta hipotética para crear estándares modulares que darán como resultado SPV y tokens ampliamente implementados. La hoja de ruta aquí no propone ningún estándar concreto que no sean los que ya existen (particularmente el correo de pago ). En cambio, la hoja de ruta está destinada a provocar discusiones y ser referenciada por empresas que ya están trabajando en estos estándares. La intención es que la hoja de ruta de las normas reales sea similar a esta lista, pero lo más probable es que incluya más y mejores soluciones, después de que se hayan llevado a cabo las discusiones pertinentes.
Ryan X. Charles es el fundador de Money Button y miembro del Comité de Normas Técnicas .
publicado por powpress
Estandarizar SPV y tokens para cinco mil millones de usuarios activos diarios.
8 de sep. De 2020
https://powping.com/posts/ef72d7cb5e0ce6a7457dffc79f9c17e791cc50d18f049d5e89736c624d805a04