Sobre redes con consenso de Proof of Authority, al no tener mecanismo de emisión de token descentralizado, es necesario tener una idea de cómo distribuir el ether. Y esta herramienta, tiene que permitir entregar ether a aquellos que NO tengan capacidad de generarlo, y que además tenga restricciones para, al monitorear abusos, limitar o incluso expulsar a los receptores de ether.
...
...
@@ -31,7 +31,7 @@ Para eso, el contrato tiene un servicio para agregar candidatos, que realiza los
- Agregar un candidato a beneficiario, y el hash de una clave generada según un criterio arbitrario a nivel dapp, aunque esta clave tiene que ser universalmente única, y esa clave es revelada al usuario a nivel dapp
- A ese candidato, se le pasa una cantidad mínima de ether
- El candidato invoca al contrato, lo cual puede hacer porque se le habilitó el saldo suficiente, y pasa la clave sin aplicarle el hash al contrato, el contrato hashea la clave y compara con la pasada originalmente, si coincide, el candidato es aprobado
destileria2
La decisión de pasar el hash al contrato al principio es porque, como en blockchain todo es público, pasar la clave en ese momento no sirve para distinguir porque cualquiera la puede ver en cualquier momento, por eso el hash. Además en el momento que el candidato haga la verificación, ahí si pasa la clave original, porque si la clave es de hecho la correcta, el contrato la hashea y si coincide entonces ya está aprobado el candidato, y no hay problema con que la clave esté pública ya que no tiene utilidad
### Interfaz:
...
...
@@ -56,9 +56,7 @@ La decisión de pasar el hash al contrato al principio es porque, como en blockc
- getBeneficiaryCount() -> unsigned int: devuelve la cantidad de beneficiarios
- addSuitor(address add, string password) -> bool: devuelve true si el contrato tiene suficiente ether para transferir al candidato, y false en caso contrario. NO IMPLEMENTADO
- proveControl() -> bool: NO IMPLEMENTADO
- addSuitor(address add, string password) -> bool: devuelve true si el contrato tiene suficiente ether para transferir al candidato, y false en caso contrario.
Los métodos replenishAll y replenishList tienen funcionalidad similar a la de replenish pero para hacer reabastecimientos masivos
...
...
@@ -79,8 +77,3 @@ Aunque conceptualmente, ambos contratos son similares, porque tienen una lista d
- El nuevo, en los métodos que tienen loops implementados, no se hace verificación de gas, porque es algo que se puede estimar, ya que los casos son los sigs:
- Entre invocaciones no se hizo transacción que altere el tamaño de los beneficiarios, entonces al usar estimateGas del lado de geth o web3, es la estimación precisa
- Si se hacen invocaciones que alteran el tamaño de los beneficiarios, y esas transacciones están pendientes, se puede tomar estimar el costo de esas transacciones y agregarlo al de esta
### TODOs
- [x] Mecanismo de verificación de cuenta, para verificar que los beneficiarios a agregar son cuentas con clave privada bajo control, todavía queda decidir si esto es parte de este smart contract
- [ ] Implementar addSuitor y proveControl, que son los métodos para el mecanismo de verificación de cuenta
