Crust proporciona una red de almacenamiento descentralizada para el ecosistema Web3, admite múltiples protocolos de capa de almacenamiento, incluido IPFS, y proporciona interfaces a la capa de aplicación.
La pila de tecnología de Crust también puede soportar una capa de computación descentralizada. Crust tiene como objetivo construir un ecosistema de nube distribuida que valore la propiedad y la privacidad de los datos.
Los sistemas Substrate y FRAME utilizados para el desarrollo en tiempo de ejecución definen un poderoso conjunto de funciones primitivas para construir la infraestructura blockchain. Usar los dos juntos crea un método novedoso para resolver problemas existentes. Este artículo describirá una aplicación real en la que las funciones de Substrate se utilizan para implementar una billetera activa de múltiples direcciones.
Las billeteras activas generalmente significan mantener las claves de gasto en dispositivos en línea para que las transacciones se puedan crear y transmitir fácilmente, pero los riesgos suelen ser mayores. Este artículo explorará algunas de las abstracciones de la cuenta de Substrate (cuentas de firmas múltiples, cuentas de proxy y cuentas derivadas) cómo podemos construir una billetera activa que pueda admitir millones de direcciones de manera segura.
Si necesita guardar tokens para varias cuentas de usuario, pero desea proporcionar a cada cliente su propia dirección de depósito, entonces dicha billetera será muy útil. La solución simple es generar una nueva dirección de depósito para cada cliente generando un nuevo par de claves. Pero procesar todos estos pares de claves rápidamente no es fácil. ¿Y si tienes miles de usuarios? Usando la abstracción de cuentas de Substrate, podemos construir una solución más escalable y segura.
ID de cuenta y fuente
Antes de comenzar a construir una billetera caliente, debemos sentar las bases para que se use. Cuando los usuarios interactúan con la cadena de bloques, están llamando a ciertas funciones. La colección de estas funciones "asignables" forma la interfaz de la cadena de bloques.
Dado que la función programable se llama desde el exterior, la cadena de bloques puede preocuparse primero por quién realmente llamó a la función. Primero, una función debe verificar si la persona que llama está autorizada para ejecutar la función. En segundo lugar, es posible que la cadena necesite saber exactamente quién llamó a la función para actualizar cierta información sobre la persona que llama. Si la persona que llama es una cuenta, es posible que la cadena deba actualizar el saldo de la cuenta, por ejemplo, para deducir las tarifas de transacción.
Es posible que esté pensando, "¿Qué significa eso si la persona que llama es una cuenta?" Las funciones en Substrate no son de la cuenta en sí, sino de los orígenes. Por ejemplo, el sistema de gobierno de Polkadot tiene una serie de fuentes especiales que tienen privilegios, como la asignación de fondos de tesorería o la revocación de Slash. Si usa Substrate para diseñar su propia cadena de bloques, puede crear su propia fuente personalizada. Sin embargo, una cosa para recordar en este artículo es que las cuentas son solo una variación de la fuente del sustrato. Puede imaginar que Substrate le dice a la función programable: "La fuente de esta programación es una cuenta".
Ahora que hemos logrado el primer salto en la abstracción, necesitamos una forma de saber a qué cuenta se refiere la fuente de la función. Si ha utilizado alguna cadena de bloques, es posible que esté acostumbrado a utilizar un ID de cuenta como clave pública correspondiente a la clave privada. Esto no es un problema, esto también se puede utilizar en sustrato. En este sentido, una cuenta es identificada por una clave pública y autorizada por la correspondiente clave privada.
El sustrato admite más abstracciones. El ID de cuenta puede ser cualquier número de 32 bytes. [1] Puede ser la clave pública correspondiente a la clave privada, pero no es necesaria. Solo requiere algún tipo de método de autorización. Al igual que en él, debe haber alguna forma única de generar este número de identificación de cuenta para que Substrate pueda completar la oración al principio de lo anterior: "La fuente de esta programación es la cuenta identificada por este número". [2]
Función hash
Las funciones hash siempre han aparecido en blockchain. Los bloques están realmente vinculados por su valor hash. Pero usaremos las propiedades de la función hash para lograr otros dos propósitos: generar ID de cuenta e identificar llamadas a funciones.
La función hash acepta una entrada de tamaño arbitrario y la asigna a una salida de tamaño fijo (por ejemplo, 32 bytes). Sin embargo, no solo mapea datos a cualquier número de 32 bytes, sino que también debe mapear determinísticamente datos únicos a un número único. Da la casualidad de que 32 bytes pueden capturar elementos astronómicos. [3]
Por ejemplo, podemos obtener información sobre la cadena, como "polkadot-treasury", y usar una función hash para convertirla en un ID de cuenta (32 bytes). Alternativamente, podemos obtener información sobre ciertas transacciones, como "transferir 10 unidades a la cuenta 123 ..." y creer que el hash es la única imagen de esa información.
Cuenta con múltiples firmas
Con estos, podemos comenzar a construir la primera parte de una billetera activa: cuentas multifirma. Debido al volumen general, una cuenta de múltiples firmas puede no parecer parte de una billetera popular, pero esta cuenta servirá como base de seguridad para el resto de los componentes, y el volumen que acabamos de mencionar no obstaculizará el uso diario.
Algunas cadenas de bloques utilizan firmas múltiples cifradas, donde varios titulares de claves firman una sola transacción fuera de la cadena antes de enviar la transacción en la cadena. El sistema de firmas múltiples que viene con FRAME de Substrate funciona de otra manera: genera ID de cuenta basados en las cuentas individuales que componen la firma múltiple y los umbrales necesarios requeridos para la distribución de las cuentas generadas. Substrate agrega un prefijo especial de múltiples firmas a toda esta información y la aplica un hash para obtener una salida de 32 bytes, que se utilizará como el ID de cuenta de múltiples firmas. Tenga en cuenta que este ID de cuenta no tiene una clave privada asociada.
Para autorizar la transacción desde la nueva ID de cuenta, los miembros de la firma múltiple utilizan la llamada de función que desean realizar en la cuenta de firma múltiple para enviar la transacción en la cadena. Sin embargo, no es eficiente para todos enviar una llamada de función; puede ser grande y el espacio de bloque es escaso (y por lo tanto costoso). La función hash vuelve a ser útil: solo una cuenta necesita enviar la llamada a la función real; otras solo envían el hash. Solo necesitan decir: "Aceptamos usar este hash para llamar a la función a través de una cuenta de firma múltiple" sin volver a enviar la función.
Esta firma múltiple en sí misma es demasiado torpe para ser utilizada como una billetera activa, porque requiere que varios titulares de claves envíen transacciones para que funcione. Pero es altamente seguro, puede usarlo como una cuenta básica y podemos convertirlo en una billetera caliente sin sacrificar su seguridad.
Cuenta proxy
La cuenta proxy permite que la dirección de firma múltiple delegue la autoridad de gasto a otra cuenta, que se utilizará como billetera activa mientras se mantiene la seguridad de la firma múltiple. Configuraremos un agente retrasado por única vez para administrar los gastos y otro (o más) agentes instantáneos para administrar la seguridad de esta cuenta de múltiples firmas.
La cuenta de proxy otorga los privilegios de una cuenta a otra cuenta para realizar llamadas de función en nombre de la cuenta. Estos privilegios pueden ser específicos, como "solo transacciones relacionadas con hipotecas", o amplios, como "todas las transacciones que no impliquen la transferencia de fondos", o incluso privilegios completos como "cualquier transacción".
Para crear un agente, solo necesita realizar una transacción desde la cuenta para ser agente y especificar qué otra cuenta es el agente y sus privilegios. Una vez establecida la relación de agencia, la cuenta de proxy puede realizar transacciones para la cuenta de proxy, básicamente diciéndole a la cadena: "Soy el agente de la cuenta, tengo estos privilegios y quiero representar la cuenta de proxy". La lógica de la cadena verificará que el agente tenga los privilegios correctos y utilizará la fuente de la cuenta proxy para distribuir la función.
Agregar un retraso de tiempo agrega una capa de seguridad. Imagine una demora de 600 bloques (una hora en Polkadot). La cuenta de proxy seguirá enviando la transacción, diciendo que es un proxy con ciertos privilegios, pero solo anunciará el valor hash de la llamada a la función que desea realizar. El propietario de la cuenta de proxy puede solicitar la llamada de función real y revisarla. Si el propietario no está de acuerdo, puede rechazar la llamada a la función enviando otra transacción antes de que expire el tiempo de demora. Después del retraso de tiempo, el agente puede enviar la llamada de función real correspondiente al anuncio, que luego es programado por Substrate. [4]
Para nuestro caso de uso, el titular de la clave de firma múltiple realizará una transacción para configurar otra cuenta como agente retrasado con todos los privilegios, incluidas las transferencias de saldo, por ejemplo. Quizás esta cuenta proxy exista en un servidor en línea que pueda realizar transacciones automáticamente. Siempre que se realiza una transacción, primero debe anunciar el hash y luego enviar la llamada a la función real a otros titulares de la cuenta (para simplificar, tratamos a este otro titular de la cuenta como un miembro de múltiples firmas), y ellos pueden verificar que la función llame no es malicioso. Si es maliciosa, la firma múltiple puede realizar una transacción a tiempo para rechazar la llamada y, por prudencia, determinar que la cuenta de proxy ha sido robada y eliminarla.
Esta configuración funciona, pero aún podemos hacer que sea más conveniente de usar. Si utilizamos un solo agente, es posible que necesitemos una demora prolongada, ya que puede ser difícil coordinar suficientes titulares de claves de firma múltiple para realizar transacciones de rechazo en poco tiempo. Pero una cuenta puede tener varias cuentas de proxy con diferentes privilegios. Para resolver este problema, configure a cada titular de clave de firma múltiple como un agente con privilegios de no transferencia, especialmente el privilegio de rechazar notificaciones de agentes retrasados.
Introduzcamos brevemente esta configuración. En el centro, tenemos una cuenta de firmas múltiples. La cuenta no tiene una clave privada, pero hay dos formas de controlarla: utilizar una cuenta proxy retrasada o recopilar suficientes firmantes de cuentas de miembros. Cada miembro de la firma múltiple también tiene la capacidad de rechazar transacciones del agente con privilegios completos, pero si ningún otro miembro se une a la transacción de firma múltiple, no se puede realizar la transferencia de saldo.
Es una billetera activa con todas las funciones por sí misma, simplemente elimine el proxy y configure una nueva billetera activa para cambiar la tecla de acceso rápido (una cuenta de proxy con privilegios completos) sin cambiar su dirección (una cuenta de firma múltiple). Pero nuestra declaración inicial del problema requería que miles de usuarios usaran una dirección de depósito única. Hasta ahora, solo tenemos un usuario.
Cuenta de derivados
Hasta ahora, hemos utilizado varios métodos para acceder a una cuenta con múltiples firmas. Ahora, usaremos una cuenta para acceder a muchas cuentas.
Cada cuenta en Substrate tiene un árbol de cuentas de derivados al que se puede acceder. Para obtener la identificación de la cuenta, Substrate utiliza naturalmente el algoritmo hash. Al aplicar el hash al ID de la cuenta que llama con el índice requerido y el prefijo derivado, Substrate crea un nuevo ID de cuenta. Por ejemplo, el remitente proporciona una llamada a la función y un índice, diciendo: "Quiero programar esta función desde una cuenta derivada con este índice".
Es posible que haya adivinado lo que sucederá más tarde. El propietario de la billetera puede asignar un índice a cada usuario y proporcionar una identificación de cuenta derivada como la dirección de depósito del usuario. Para acceder a los fondos, la dirección de poder emitirá una transacción para transferir los fondos desde la dirección derivada de la cuenta de firma múltiple.
Específicamente, el índice está limitado a 16 bits o 65.536 cuentas derivadas, pero también se puede anidar. En otras palabras, cada cuenta de derivados puede tener su propio conjunto de 65.536 cuentas de derivados, y así sucesivamente. El segundo nivel del árbol tendrá más de 4 mil millones de cuentas.
Imagen completa
Finalmente, usemos este conocimiento. Imagina que el usuario con índice 11 te paga y tienes unas "cuentas de ahorro" para depositar fondos. La transacción completa se ve así: "Soy el agente de una cuenta de múltiples firmas y quiero transferir fondos de una cuenta de derivados de múltiples firmas (índice 11) a una cuenta de ahorros".
Suponiendo que todo es normal para el regulador, el tiempo de demora expirará y el agente podrá transmitir la transacción completa. Si el miembro de firma múltiple piensa que la tecla de acceso rápido debe cambiarse, simplemente puede generar una nueva clave y eliminar la clave anterior como un proxy sin afectar la firma múltiple o cualquiera de sus direcciones derivadas.
La figura anterior muestra el diagrama esquemático de la billetera que hemos configurado: la firma múltiple (MS) está controlada por un conjunto de n teclas (indicadas como k), y el agente de retardo de tiempo (H) está configurado como una tecla de acceso rápido. Puede derivar direcciones casi ilimitadas (conjuntos de d) a partir de firmas múltiples.
Podemos optimizar aún más este flujo de trabajo. Substrate también proporciona funciones para enviar un lote de llamadas a funciones. Si los usuarios realizan depósitos y retiros en sus cuentas de derivados de forma regular, puede enviarlos todos en un solo lote de transferencias.
La abstracción de cuentas en cadena de Substrate proporciona una forma poderosa de administrar cuentas. Al reducir la cantidad de claves reales requeridas y acceder a las cuentas de acuerdo con reglas formales en lugar de claves privadas, puede operar miles de cuentas sin tener que lidiar con la limitación de almacenar un número igual de claves de firma. Este artículo solo se centra en un ejemplo de creación de una billetera activa, pero todas las abstracciones están aisladas y pueden estar compuestas por aplicaciones más avanzadas.
Notas:
No tiene que ser de 32 bytes. Puede crear el tiempo de ejecución como desee, pero no quiero que este artículo vaya más allá del alcance necesario. ↩︎
Una explicación rápida de la palabra "único", en un sentido estricto, mi significado aquí es más estricto que la definición en el diccionario ordinario. Un relato es único, no porque solo pueda tener una representación, sino que se puede demostrar que todas las representaciones (o una serie de representaciones) son iguales. Puede haber una cantidad ilimitada de métodos para generar un número específico (cuenta), pero siempre que todos estos métodos generen la misma cuenta, la cuenta puede considerarse única. Explicar las matemáticas en detalle será lo suficientemente complicado como para hacer su cabeza grande, pero generaremos ID de cuenta y los pasaremos entre funciones. La clave aquí es que no importa cuántas funciones tengamos juntas (concatenadas) para llegar a una ID de cuenta, que representa el mismo ID de cuenta en términos de actuar como fuente de envío. ↩︎
Si está interesado, 32 bytes pueden contener hasta 1,15 x 10 ^ 77. La distancia al borde del universo observable es de 45,7 mil millones de años luz, que es 4,32x10 ^ 23 kilómetros o 4,32x10 ^ 29 mm. Si lo consideramos un disco óptico plano, su área es de 5,87 x 10 ^ 59 milímetros cuadrados. Aún nos diferenciamos en 10 ^ 18 o mil millones de cuadrados. Por lo tanto, la posibilidad de que dos entradas hash diferentes tengan la misma salida es como si ambos elementos cayeran en el mismo milímetro cuadrado en el universo observable, luego se descompongan en una cuadrícula de mil millones por mil millones, y luego todos caigan en el mismo cuadrado. . Estos cuadrados tienen 1 picómetro (picómetro) de ancho. Como referencia, el diámetro de un átomo de helio es de 62 picómetros. ↩︎
De hecho, siempre que el agente emita una notificación, cualquier cuenta puede enviar la llamada, pero por pragmatismo, se supone que nuestra billetera activa solo usa la misma cuenta para la notificación y el envío. ↩︎
Original: https://www.parity.io/building-a-hot-wallet-with-substrate-primitives/
Traducción: Comunidad PolkaWorld
Acerca de Crust Network
Crust proporciona una red de almacenamiento descentralizada para el ecosistema Web3, admite múltiples protocolos de capa de almacenamiento, incluido IPFS, y proporciona interfaces a la capa de aplicación. La pila de tecnología de Crust también puede soportar una capa de computación descentralizada. Crust tiene como objetivo construir un ecosistema de nube distribuida que valore la propiedad y la privacidad de los datos.
La primera fase del "Proyecto Ark" de la red de prueba de incentivos se lanzó el 30 de noviembre y todos son bienvenidos a unirse a la experiencia de prueba. Crust Network se ha unido sucesivamente al Substrate Builders Program, Web3.0 Bootcamp, y obtuvo la subvención de la Web3 Foundation.
Relacionado con Crust:
Informe técnico de
Crust v1.9.3 Informe técnico económico de Crust Network v.0.7
Indicadores y economía de los tokens de Crust Network
Comprenda rápidamente la nube distribuida de Crust Network
官 网 ： https: //crust.network/
Twitter ： @CrustNetwork
Medio ： https: //medium.com/@crustnetwork
GitHub ： https: //github.com/crustio
Telegram ： https: //t.me/CrustNetwork
