nefera606
commented
4 years ago Propuesta para modificar publicKeyRegistry a contrato actualizable
Una de las limitaciones de los contratos actualizables de openzeppelin es el tema de crear un contrato actualizable desde otro contrato(ver el enlace abajo), por simplificar he modificado AlastriaIdentityManager.sol para que no se cree ningún contrato en su constructor, y a su vez, reciben como parámetros las direcciones de los contratos ya creado previamente(entiendo que una vez los contratos sean actualizables, el impacto de este cambio es mínimo), en el caso de que la creación de esos contratos tienen que ser desde el mismo AlastriaIdentityManager por temas por ejemplo de gobernanza etc, podríamos optar por este método propuesto por openzeppelin: post
Para actualizar la variable previousPublishedVersion en siguientes actualizaciones habría que crear otro método setter ya que una vez el contrato es actualizable usando este approach, el método inicialize solo se llamará una única vez después de la creación de su contrato proxy, y no se llamarán en las sucesivas actualizaciones siguientes.
Si ven bien los planteamientos aquí enumero los cambios realizados:
87: upgradeable publicKeyRegistry using openzeppelin
94: Scripts for deploy and update smart contracts(solamente adaptado upgradeable publicKeyRegistry)
The change for set the registries addresses out of the initialize and constructor is a good idea. The governability of the contracts does not need a hot deploy from the Identity Manager, only with the owner transfer it can be done. We need to automatize that process in each upgrade to make everything consistent.
Jiang-dxc
Propuesta para modificar publicKeyRegistry a contrato actualizable
Una de las limitaciones de los contratos actualizables de openzeppelin es el tema de crear un contrato actualizable desde otro contrato(ver el enlace abajo), por simplificar he modificado AlastriaIdentityManager.sol para que no se cree ningún contrato en su constructor, y a su vez, reciben como parámetros las direcciones de los contratos ya creado previamente(entiendo que una vez los contratos sean actualizables, el impacto de este cambio es mínimo), en el caso de que la creación de esos contratos tienen que ser desde el mismo AlastriaIdentityManager por temas por ejemplo de gobernanza etc, podríamos optar por este método propuesto por openzeppelin: post
Para actualizar la variable previousPublishedVersion en siguientes actualizaciones habría que crear otro método setter ya que una vez el contrato es actualizable usando este approach, el método inicialize solo se llamará una única vez después de la creación de su contrato proxy, y no se llamarán en las sucesivas actualizaciones siguientes.
Si ven bien los planteamientos aquí enumero los cambios realizados:
87: upgradeable publicKeyRegistry using openzeppelin
94: Scripts for deploy and update smart contracts(solamente adaptado upgradeable publicKeyRegistry)