depositIcpForSubaccount to review #8
Conversation
josemariasosa
left a comment
josemariasosa
left a comment
There was a problem hiding this comment.
Luce bien.Esta semana lo mandamos a producción. 🐦⬛
|
Buenísimo, lo que no consideré en su momento, y que iba a revisar en estos días es que para el proceso de withdraw posiblemente haya que hacer las modificaciones equivalentes para que los stackers también puedan hacer withdraw especificando la subaccount. |
Lo que estaba viendo es que para hacer withdraw el usuario debe tener a la mano, además de su propia cuenta, también el número de subcuenta, lo que podría dificultar/entorpecer los retiros. Cómo ves? |
Que tal José María, está tarde reviso exhaustivamente los dos últimos commits que hice, en donde agregué unos cambios para lo del flujo de withdraw con subaccounts. Ni bien vea que está todo bien te aviso. Voy a tratar de hacer un deploy local de los contratos involucrados para hacer todas las pruebas necesarias |
2 participants
Buenas... no estoy seguro de si este cambio pueda llegar a romper algo, estuve revisando y al parecer no. La idea es la siguiente.
✨ Soporte para depósitos individualizados mediante subcuentas en staking
Descripción:
Objetivo:
Permitir que canisters con múltiples usuarios realicen staking de ICP desde subcuentas únicas, facilitando la identificación individual de cada usuario interno.
Cambios Principales:
Nuevas Funciones:
getDepositAddressForSubaccount(subaccount: Blob)Genera una dirección de depósito combinando el Principal del llamante con una subcuenta específica (subaccount), permitiendo a los usuarios externos (o canisters) definir identificadores únicos para sus usuarios internos.
depositIcpForSubaccount(subaccount: Blob)Procesa el depósito asociado a la subcuenta especificada, garantizando que los tokens minteados se asignen correctamente a la cuenta del usuario (caller + subcuenta ) combinada.
Modificaciones en doDepositIcpFor:
Nueva Firma: doDepositIcpFor(user: Principal, _subaccount: ?Blob)
Ahora acepta un parámetro opcional _subaccount para soportar tanto el flujo tradicional (sin subcuenta) como el nuevo flujo (con subcuenta).
Cálculo de Subcuenta:
Si _subaccount es null, se deriva la subcuenta directamente del Principal del usuario (comportamiento original).
Si _subaccount está definido, se combina con el Principal del usuario mediante una operación de suma modular byte a byte (ver accountToSubaccount).
Detalles Técnicos:
Lógica de Combinación de Subcuentas:
La función accountToSubaccount fusiona la subcuenta base (derivada del Principal del usuario) con la subcuenta proporcionada por ese usuario, generando un identificador único para cada subcuenta que ese mismo usuario especifique en futuras interacciones.
Riesgo de Colisión:
La suma modular utilizada ((a1[i] + a2[i]) % 256) tiene una probabilidad extremadamente baja de colisión si las subcuentas proporcionadas (a2) son generadas de manera única (e.g., mediante UUIDs o contadores controlados por el canister externo).
Notas Adicionales:
Retrocompatibilidad:
Las modificaciones en las funciones existentes (depositIcp, depositIcpFor) no implican cambios en su firma ni en su comportamiento, ya que estos cambios están relacionados a la llamada interna a la función doDepositIcpFor la cual, debido a la modificación introducida, se invoca ahora con el parámetro _subaccount = null, preservando el comportamiento original.
Verificación de Seguridad:
Se asegura que los tokens minteados se asignen a cuentas cuyo owner será el principal del caller, e identificables individualmente por la subaccount especificada en el nuevo parámetro y derivada externamente del principal del usuario o de cualquier otro valor que el caller quiera establecer para identificarla de otras cuentas de su misma propiedad