Нужно ли пользователям монет ERC20 хранить эфир?

Предположим, что существует Fancycoin, альткойн ERC20, некоторые функции которого реализованы с помощью EVM. Он делает некоторые нетривиальные вещи, которые потребляют газ.

Насколько я понимаю, я могу получить Fancycoin на свой кошелек, если кто-то отправит его мне, не имея при этом эфира.

У меня такой вопрос: если у меня есть Fancycoin и я хочу использовать его для каких-то действий (может быть, он проверяет оракула или выполняет вычисления с некоторыми данными, внутренними для блока и т. д.), но у меня нет эфира в моем кошельке, я не смогу использовать какие-либо функции Fancycoin? Как упоминалось в ответе на вопрос, указанный в первом комментарии ниже, я, вероятно, не смогу отправить Fancycoin кому-то еще.) Однако могут ли функции в Fancycoin, требующие газа, оплачиваться в Fancycoin, а не в эфире?

Ответ на вышесказанное считается ответом на мой вопрос, но на случай, если вы захотите расширить: я думаю, что в целом меня интересует, как монеты, построенные поверх Ethereum, взаимодействуют с эфиром. Я этого не понимаю.

Я согласен, что связанный вопрос близок, но это не то же самое. Я лишь мимоходом упомянул транзакции в своем вопросе.
Понятно - я отрекаюсь, поскольку вы спрашиваете что-то более общее.

Ответы (3)

Ответ по умолчанию: Нет, вы не можете использовать учетную запись без эфира для чего-либо, связанного с Fancycoin, так как любое взаимодействие со стандартным токеном требует транзакции, которую вам нужно подписать и транслировать в сеть и, наоборот, оплатить транзакционные издержки в Эфир (по крайней мере, на данный момент вы можете оплачивать сборы только в Эфире).

Более интересный ответ: да, несколько изменив требования. Вы подписываете транзакцию вне сети, отправляете ее кому-то другому (например, с помощью голубя, обычной почты или дымовых сигналов). Что кто-то другой сможет отправить эту транзакцию и получить за это небольшое вознаграждение.

Приведенная выше идея не вся отлажена (обозначенные проблемы с безопасностью остаются), но следующий скетч работает, я только что протестировал его в Remix с небольшой помощью консоли 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));
    }

}
Выглядит отлично, просто предложение переместить комментарий подписи [27,28] из строки rзначения в vстроку значения.
пересматривая это сейчас, пара вещей. менее критично, web3.utils.soliditySha3(param1 [, param2, ...])будет конкатенация, а calcHash, как правило, не нужен. В цепочке существуют контракты на коммунальные услуги, или они просто реализуются локально. Что еще более важно, broadcastдизайн может истощить средства для вещательной компании из-за шагов утверждения, поэтому было бы безопаснее, если бы перед отправкой в ​​​​сеть выполнялся вызов только для чтения для тестирования.

Только что ответил и дал ссылку на универсальную библиотеку, позволяющую легко интегрировать этот функционал в любой смарт-контракт: https://ethereum.stackexchange.com/a/46546/3032

Любой сможет выполнять транзакции для кого угодно безопасным и ненадежным способом. Например, сервис может выполнять транзакции для своих пользователей (с их цифровыми подписями на транзакции) и компенсировать комиссию ETH собственными комиссиями за токены.

На самом деле у меня есть пример мастер-контракта (который должен хранить эфир), который может создавать дочерние кошельки, которым по отдельности не нужно хранить эфир!

Пожалуйста, поставьте звездочку, если вам это нравится: https://github.com/Meshugah/ERC20-CommonGasWallet