Supongamos que existe Fancycoin, una moneda alternativa ERC20 que tiene alguna funcionalidad implementada por el EVM. Hace algunas cosas no triviales que consumen gas.
Según tengo entendido, puedo recibir Fancycoin en mi billetera si alguien me lo envía, sin tener ningún éter.
Mi pregunta es: si tengo Fancycoin y quiero usarlo para hacer algo (tal vez verifique un oráculo, o haga cálculos con algunos datos internos de un bloque, etc.) pero no tengo éter en mi billetera, ¿No podré usar ninguna de las funciones de Fancycoin? Como se menciona en la respuesta a la pregunta vinculada en el primer comentario a continuación, probablemente no podré enviar Fancycoin a otra persona). Sin embargo, ¿las funciones en Fancycoin que requieren gas podrían pagarse en Fancycoin de alguna manera, y no en éter?
Responder a lo anterior cuenta como una respuesta a mi pregunta, pero en caso de que desee ampliar: creo que, en general, me interesa cómo las monedas construidas sobre Ethereum interactúan con el éter. no entiendo esto
La respuesta predeterminada sería: No, no puede usar una cuenta sin Ether para nada relacionado con Fancycoin, ya que cualquier interacción con un token estándar requiere una transacción que debe firmar y transmitir a la red y, a la inversa, pagar los costos de transacción en Ether (al menos por el momento solo puedes pagar tarifas en Ether).
La respuesta más interesante es: Sí, cambiando un poco los requisitos. Usted firma una transacción fuera de la cadena, la envía a otra persona (por ejemplo, por medio de una paloma, correo postal o señales de humo). Que alguien más pueda enviar esa transacción y potencialmente obtener una pequeña recompensa por hacerlo.
La idea anterior no está del todo solucionada (los problemas de seguridad indicados permanecen), pero el siguiente boceto funciona, lo acabo de probar en Remix con un poco de ayuda de la consola geth web3:
pragma solidity ^0.4.13;
/*
Author: Dr. Sebastian C. Buergel for Validity Labs AG
License: MIT
aim:
allow account without ETH but in possession of tokens to transfer tokens
approach:
sign message off-chain, send to other user, incentivize that user to broadcast message and get token as reward
remaining issues and solutions:
- replay protection (use nonce),
- frontrunning by other nodes (commit-reveal),
- timeout (expiry time)
step 0: choose amount, recipient (to), and reward (in tokens) for broadcaster
step 1: obtain hash from `calcHash` (off-chain, offline)
step 2: sign hash (off-chain, offline), e.g. using geth web3 console:
var signature = web3.eth.sign(web3.eth.accounts[0], hash);
var r = signature.substring(0,66);
var s = '0x' + signature.substring(66,130);
var v = '0x' + signature.substring(130,132); // make sure it is 27 or 28, else add 27
step 3: send transaction to someone else
step 4: that other account broadcasts the message by sending it to `broadcast`, funds get transferred and broadcaster gets reward
*/
contract Fancycoin {
event Transfer(address indexed _from, address indexed _to, uint256 _value);
mapping(address => uint) public balanceOf;
uint public totalSupply;
constructor(uint supply) {
totalSupply = supply;
balanceOf[msg.sender] = supply;
}
function transfer(address _to, uint256 _value) returns (bool success) {
return transferFromTo(msg.sender, _to, _value);
}
function transferFromTo(address _from, address _to, uint _value) internal returns (bool success) {
if (balanceOf[_from] >= _value && _value > 0) {
balanceOf[_from] -= _value;
balanceOf[_to] += _value;
Transfer(_from, _to, _value);
return true;
} else { return false; }
}
// helper function since web3.sha3 is not (yet) able to concatenate arguments in the same way that solidity does it
function calcHash(uint amount, address to, uint reward) constant returns (bytes32) {
return sha3(amount, to, reward);
}
function verify(uint amount, address to, uint reward, uint8 v, bytes32 r, bytes32 s) constant returns(address) {
bytes memory prefix = "\x19Ethereum Signed Message:\n32";
bytes32 prefixedHash = sha3(prefix, sha3(amount, to, reward));
return ecrecover(prefixedHash, v, r, s);
}
function broadcast(uint amount, address to, uint reward, uint8 v, bytes32 r, bytes32 s) {
address sender = verify(amount, to, reward, v, r, s);
assert(transferFromTo(sender, msg.sender, reward));
assert(transferFromTo(sender, to, amount));
}
}
rvalor a vlínea de valor.web3.utils.soliditySha3(param1 [, param2, ...])se concatenará y calcHash generalmente es innecesario. Existen contratos de servicios públicos en la cadena o simplemente se implementan localmente. Más importante aún, el broadcastdiseño puede agotar los fondos para la emisora debido a los pasos de afirmación, por lo que sería más seguro si se realizara una llamada de solo lectura para probar antes de enviar a la red.Acabo de responder y proporcionó un enlace a la biblioteca universal, lo que permite integrar fácilmente esta funcionalidad en cualquier contrato inteligente: https://ethereum.stackexchange.com/a/46546/3032
Cualquiera podrá realizar transacciones para cualquier persona de forma segura y sin confianza. Por ejemplo, el servicio puede realizar transacciones para sus usuarios (con sus firmas digitales por transacción) y compensar las tarifas de ETH con tarifas de token propias.
¡De hecho, tengo un ejemplo de un contrato maestro (que debe almacenar ether) que puede crear billeteras para niños que no necesitan individualmente contener ether!
Destacalo si te gusta: https://github.com/Meshugah/ERC20-CommonGasWallet
Richard Horrocks
wapití
Richard Horrocks