Uno de los principales desafíos de seguridad de Internet en los últimos veinte años ha sido el problema bastante simple de proteger las cuentas de los usuarios. En este momento, los usuarios tienen cuentas con cientos de sitios web y docenas de contraseñas, lo que lleva a largo números de hacks ya que los sitios web individuales, a menudo administrados por personas que no son particularmente hábiles en los puntos más finos de la criptografía y la seguridad en Internet, se ven explotados por piratas informáticos cada vez más inteligentes, y los usuarios con frecuencia se enfrentan a la complejidad de recordar cientos de contraseñas ya sea haciéndolos simples o haciéndolos todos iguales – con frecuencia muy resultados desafortunados. Con el tiempo, sin duda se ha desarrollado un mosaico de soluciones ad-hoc, incluido el uso de la cuenta de correo electrónico de uno como respaldo universal, y software de “administrador de contraseñas” como Lastpass, aunque a un alto costo: tales soluciones retienen gran parte de la complejidad subyacente de acceso basado en contraseña o dar a empresas centralizadas grados muy altos de control sobre su vida en línea.
Hay muchas llamadas a conseguir librar de contraseñas, pero la pregunta es: ¿con qué los reemplazamos? Hay muchas ideas, que van desde “una sola contraseña para gobernarlos a todos” hasta la autenticación de teléfonos inteligentes, dispositivos de hardware especializados y biometría y todo tipo de políticas M-de-N de múltiples factores, pero incluso estas construcciones más complejas hasta ahora han sido típicamente específico de la aplicación: muchos bancos ahora le brindan un dispositivo de acceso especializado para iniciar sesión en su cuenta bancaria, pero si confía en su seguridad, no puede usarlo también para acceder a su correo electrónico. En general, vemos que el problema de cómo administrar mejor el control de acceso de los usuarios y minimizar los riesgos de pérdida y robo de claves es lo suficientemente complejo como para que nunca se resuelva “de una vez por todas”, por lo que la mejor manera de resolverlo es permitir un mercado libre de soluciones para prosperar y dejar que cada usuario elija cuáles funcionan mejor para ellos; sin embargo, la manera de hacer que eso realmente suceda es por desagregación el mercado de “soluciones de control de acceso” del mercado de “servicios”. Es decir, exactamente lo que somos en gran medida no haciendo ahora mismo.
El dispositivo de acceso de hardware a mi cuenta bancaria UBS. Recuérdame, ¿por qué no puedo usar esto también para asegurar mis dominios en Namecheap?
¿Entonces cómo hacemos eso? El primer paso es introducir algún uso bien ubicado de la última abstracción: el código completo de Turing. En lugar de, a nivel de protocolo, permitir que los usuarios especifiquen una contraseña, o proporcionar un conjunto preseleccionado de proveedores, o incluso un estándar que se basa en hablar con un servidor de elección del usuario, permita que las políticas de acceso se especifiquen en el código para ser ejecutado en una máquina virtual determinista (donde el EVM es un buen comienzo como cualquier otro). El código puede incluir verificaciones de firmas digitales usando alguna algoritmo criptográfico (para que obtenga compatibilidad con versiones posteriores con criptografía cuántica segura de forma gratuita), que puede incluir claves almacenadas en la computadora del usuario, claves derivadas directamente de una contraseña, claves guardadas en un dispositivo de hardware o cualquier política arbitraria que incluya cualquier combinación de las anteriores. De esta manera, la innovación puede ocurrir en los mecanismos de control de acceso. sin ninguna necesidad para que los sitios web (u otros sistemas que requieran autenticación) hagan cualquier cosa para adaptarse a los nuevos cambios. Además, el sistema permite perfectamente organizaciones para usar el esquema usando controles de acceso de varias personas de inmediato, sin necesidad de integración adicional.
El siguiente paso es el código dependiente de la operación completa de Turing. Para muchas aplicaciones, desea tener la capacidad de autorizar a algunos usuarios para que realicen algunas operaciones pero no otras; por ejemplo, es posible que desee autorizar a un administrador de sistemas a cambiar la dirección IP a la que apunta un nombre de dominio, pero no vender el dominio directamente. Para acomodar esto, la abstracción necesita cambiar. Una configuración simple de “Turing-complete-code as signature” podría tener la siguiente forma:
VM(code, server-provided nonce ++ signature) ?= 1
Donde máquina virtual es una máquina virtual que ejecuta código, tomando un nonce proporcionado por el servidor y una firma como entrada, y la verificación de verificación es para ver si la salida es 1 o no. Un ejemplo simple de código que se podría poner es un verificador de firma digital de curva elíptica. Para permitir diferentes requisitos de autorización según la operación, desea:
VM(code, server-provided nonce ++ operation_data ++ signature) ?= 1
Se necesitaría proporcionar una firma con cada operación que el usuario desee realizar (esto tiene el beneficio de proporcionar una prueba definitiva, verificable por terceros, de que se autorizó una operación); los datos de la operación (imagine el nombre de la función y los argumentos codificados en un ABI estilo Ethereum) se agregaría como un argumento para la máquina virtual, y la firma tendría que estar sobre el nonce y los datos de operación.
Esto te lleva bastante lejos, pero en algunos casos no lo suficiente. Un ejemplo simple es este: ¿qué sucede si desea dar permiso a alguien para retirar pequeñas cantidades de dinero pero no grandes cantidades, es decir. un límite de retiro? En ese caso, el problema que debe superar es simple: ¿qué pasa si alguien limitado por un límite de retiro de $100 intenta evadirlo simplemente ejecutando un script para retirar $90 una y otra vez? Para resolver esto, necesita un límite de retiro más inteligente; esencialmente, algo así como “máximo $ 100 por día”. Otro caso natural es la revocación de clave: si una clave se piratea o se pierde, desea reemplazarla y quiere asegurarse de que el mundo descubra que su política cambió para que los atacantes no puedan intentar hacerse pasar por usted bajo su antigua política.
Para superar este último obstáculo, debemos ir un paso más allá: necesitamos Turing-completo operación dependiente con estado políticas; es decir, las operaciones deben poder cambiar el estado de la política. Y aquí es donde no solo entran en juego la criptografía, sino específicamente las cadenas de bloques. Por supuesto, podría tener un servidor central que administre todo, y muchas personas están perfectamente bien confiando en un servidor central, pero las cadenas de bloques son moderadamente valiosas aquí porque son más convenientes, brindan una historia creíble de neutralidad y son más fáciles de estandarizar. En última instancia, como sería bastante dañino para la innovación elegir permanentemente “una cadena de bloques para gobernarlos a todos”, lo que queremos estandarizar es un mecanismo mediante el cual los usuarios puedan descargar módulos para admitir alguna blockchain o solución centralizada como lo deseen.
Para las aplicaciones basadas en cadenas de bloques, tener una política de estado aplicada directamente en la cadena de bloques tiene sentido natural; no hay necesidad de involucrar a otra clase especial de intermediarios, y la gente puede empezar a hacerlo ahora mismo. La abstracción de una “cuenta” que ofrece Ethereum hace que sea extremadamente fácil trabajar con este enfoque: si su aplicación funciona con usuarios simples que tienen claves privadas, también funciona para casi todo tipo de usuarios individuales, multipartidistas, impulsados por hardware, militares. grado o cualquier otra política que los usuarios presenten en el futuro.
Para otras aplicaciones, los usuarios pueden desear privacidad, tanto en las operaciones de cambio de estado que realizan como en la naturaleza de su política en un momento determinado. Por esta razón, es probable que desee una solución como Halcóndonde la cadena de bloques aún garantiza la seguridad del proceso pero, gracias a las maravillas de la tecnología a prueba de conocimiento cero, no sabe nada de lo que se está asegurando; antes de que se implemente Hawk, pueden ser suficientes formas más simples de criptografía, como firmas en anillo.
Otras aplicaciones
La seguridad de la cuenta es la primera y más básica aplicación del concepto de código como política, también hay otras. Uno simple es un registro de nombres de dominio. Onename, uno de los populares servicios de “registro de nombres descentralizado”, actualmente planea implementar una función en la que los dominios de nivel superior pueden elegir políticas de tarifas para subdominios en función de la cantidad de letras, consonantes y vocales. Esto es útil, pero por supuesto económicamente feo: definitivamente hay cientos de características además de letras, consonantes y vocales que pueden influir en el precio de un nombre de dominio, y las personas pueden incluso querer experimentar con otras estrategias de registro como diferentes tipos de subastas.
Una vez más, una solución aún mejor es aplicar algo de modularidad simple: dejar que las personas creen su propio espacio de nombres en código completo de Turing con estado. Si está haciendo esto en una plataforma donde existe un código completo de Turing con estado, puede permitir que una dirección controle un subdominio y luego, tada, ya es compatible con las políticas de subdominio completo de Turing con estado. Esta es la esencia de la programación orientada a objetos: exponer una interfaz y permitir que otros objetos, que pueden tener un código interno arbitrariamente complejo, satisfagan esa interfaz.
Otro es el comercio de acciones privadas. Particularmente en el caso de empresas privadas, el comercio de acciones no es y no puede ser completamente libre y sin restricciones de la misma manera que lo es el comercio de criptomonedas; las empresas a menudo quieren tener restricciones tales como:
- Dar acciones a los empleados y permitirles venderlas solo después de un período de tiempo.
- Requerir que los nuevos accionistas sean aprobados por los accionistas existentes, con la posibilidad de que dichas aprobaciones vengan con un límite sobre cuántas acciones puede poseer ese titular específico
- Procedimientos de compra forzosa
- Restringir la tasa máxima a la que se venden las acciones (es decir, límites de retiro) o requerir períodos de espera u ofrecer a otros titulares específicos el derecho de preferencia
Claro, puede crear una plataforma privada de negociación de acciones basada en blockchain para un cliente y proporcionar las restricciones que ese cliente desea. Pero, ¿y si otros clientes quieren restricciones diferentes? También puede cortar el problema de raíz, al menos en la “capa de aplicación central”, y resolverlo de una vez por todas… permitiendo que cada acción individual, representada como una moneda secundaria, tenga restricciones representadas como código completo de Turing con estado.
Esta funcionalidad se puede representar en la API “token” ampliándola, por ejemplo, de la siguiente manera:
- obtener Saldo Mínimo (cuenta): obtenga el saldo mínimo que una cuenta puede tener en el momento actual
- obtenerSaldoMáximo(cuenta): obtenga el saldo máximo que una cuenta puede tener en el momento actual
En resumen, las aplicaciones no tienen políticas; Las aplicaciones interactúan con objetos (cuentas de usuario, monedas, etc.), y los objetos tienen políticas. Alternativamente, incluso más corto:
¿Está creando una aplicación de derivados financieros basada en blockchain y alguien le pide que agregue una función para permitir una votación entre múltiples proveedores de fuentes de datos en lugar de solo uno? Ni siquiera lo pienses; en su lugar, simplemente configure una dirección de proveedor de alimentación de datos y permita que los usuarios creen sus propias políticas; la ventaja es que cualquiera que sea el código que usen o escriban, también podrán usarlo para proporcionar fuentes de datos de manera más segura para el dapp de arbitraje. ¿Está creando un sistema DNS y alguien le pide que introduzca soporte para tipos de subasta específicos para subdominios? No lo haga en el nivel de DNS raíz; en su lugar, permita que los subdominios sean direcciones y permita a los usuarios inventar sus propios algoritmos de subasta; independientemente de los algoritmos que inventen, también podrán usarlos para su registro para nombres de usuario de chat descentralizados.
Este es el beneficio de la abstracción: el diseño de políticas de seguridad de cuentas puede convertirse en un campo de estudio independiente, y cualquier solución nueva que exista se puede aplicar instantáneamente en todas partes. Algunas personas querrán confiar en un tercero; otros querrán tener una autorización de firma múltiple entre cinco de sus propios dispositivos diferentes, y algunos querrán una clave para ellos mismos con la opción de que tres de cinco amigos se reúnan para restablecer la clave a una nueva. Algunos querrán una política de acceso en la que, si no realizan transacciones dentro de los doce meses, se presume que están muertos y un abogado obtendrá acceso para poder ejecutar su testamento, por todas de sus activos digitales. Y algunos querrán una política que otorgue control total a una clave para las aplicaciones que se declaran de baja seguridad, pero dos de tres claves para las aplicaciones que se declaran de alta seguridad. El diseño de la política de precios del registro de nombres también puede volverse autónomo, al igual que la política de restricción de propiedad de activos digitales, un campo que interesaría a todos, desde pequeñas y grandes corporaciones tradicionales hasta DAO basadas en la comunidad. Y ese es el poder de un código completo de Turing con estado.
