Una billetera de contrato inteligente segura, modular y actualizable que permite la adopción masiva de Web3
________ ________ ________ ________
| __ | __ | __ \ _____
| / | | | ___/ / |
__ __ _ _ / / /
| \ | / /_/__
_ ______ _ _ _ _ _ _ \ _ \ ________
| _______ | | __ | | __ | | __ | | __ | _______ |
La modularidad es uno de los principios clave en la ingeniería de software. La arquitectura y el código modulares permiten una alta reutilización, un fácil mantenimiento y pruebas, una menor interdependencia entre los componentes y, lo más importante, proporcionan un propósito y una funcionalidad sencillos que reducen los errores de código y los problemas de seguridad.
Barz también considera la modularidad como el principio clave en toda la arquitectura general y a nivel de código.
Para lograr modularidad, imponemos el estándar EIP-2535 Diamond, Multi-Facet Proxy y proporcionamos cada conjunto de funciones en una sola faceta adjunta a Diamond (Barz). Estos módulos incluyen:
Cada uno de estos módulos podrá ser acoplado y desacoplado por el propietario cuando lo desee.
Barz desconecta el almacenamiento de cada módulo a través de FacetStorage
, y los módulos de Barz solo accederán al FacetStorage
que el módulo necesita. Esto reduce la posibilidad de acceder a almacenamiento innecesario y modificaciones no deseadas del almacenamiento desde los módulos, especialmente durante la actualización de la implementación. Con esta arquitectura de separar el almacenamiento que utiliza cada módulo, Barz ayuda a evitar que cada módulo tenga colisiones de almacenamiento, lo que reduce la introducción de vulnerabilidades potenciales en el patrón de proxy.
La arquitectura de Barz también ofrece beneficios en las actualizaciones. Mientras que el patrón de proxy convencional requiere actualizar toda la implementación lógica para actualizar una parte de ella, Barz solo necesita que los módulos relevantes se reemplacen en consecuencia, lo que introduce la capacidad de actualización modular de las cuentas.
La arquitectura modular ayuda a dividir el código en módulos más pequeños, lo que contribuye a aislar y limitar la funcionalidad de cada módulo. Esto ayuda a reducir la superficie de ataque y limitar el daño potencial causado por una brecha de seguridad en un módulo. Esto se maximiza junto con la arquitectura de Barz de acceder únicamente al almacenamiento que necesita el módulo.
A diferencia de otras arquitecturas actualizables que necesitan una actualización de todo el contrato lógico o de todo el módulo que contiene el conjunto de funciones, la arquitectura de Barz admite la capacidad de actualización modular para cada función, lo que permite la máxima modularidad y capacidad de actualización en el contrato de billetera.
Como resultado de esto, nuestro contrato de cuenta "Barz" admite el esquema de firma múltiple. Los usuarios podrán cambiar el esquema de firma sin problemas con llamadas a funciones en el contrato de la cuenta. Esto permite a los usuarios múltiples opciones de UX de billetera, por ejemplo:
Usuarios que desean una interacción fluida y sin respaldo de clave privada. Pueden usar ECDSA en el esquema de firma Secp256r1 y usar la clave de acceso ("WebAuthn") para proteger de forma segura su clave privada en el administrador de contraseñas (por ejemplo, llavero de iCloud).
Los usuarios que deseen utilizar el estilo de billetera convencional o billeteras de hardware pueden utilizar el esquema de firma ECDSA("Secp256k1") para la verificación de firma.
Actualmente, admitimos 2 esquemas de firma (ECDSA en Secp256k1 y Secp256r1 Curve), sin embargo, continuaremos ampliando nuestro soporte para múltiples esquemas de firma diferentes, incluidos BLS y PQC, etc.
Esto es posible gracias a una arquitectura modular en la que las facetas de firma se adjuntan y separan de la faceta de la cuenta según la preferencia del usuario con respecto a la UX que cada esquema de firma podría proporcionar.
Durante la actualización del esquema de firma, la función de actualización debe verificar lo siguiente:
yarn
yarn compile
yarn test
yarn size
forge test