ETH токены

[ShDenis]

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

[ferumflex]

У контракт есть определенный интерфейс(читай функции которые можно вызвать, с определенными названиями). Контракты могут вызывать другие контракты

[ShDenis]

ссылкой не поделитесь? (мне не лень искать, просто не получилось).
т.е. есть зарезервированные имена функций и переменных, по которым токены выделяются из всех остальных контрактов? т.е. если я переименую функцию transfer в transfer1 то evm не поймёт что перед ней контракт валюты?

[nagor2]

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

[hero10]

если скажете зачем это может быть более конструктивный ответ.

[ShDenis]

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

[ShDenis]

наверное сам нашёл.

ERC: 20
Title: Token standard
Status: Draft
Type: Informational
Created: 19-11.2015
Resolution: https://github.com/ethereum/wiki/wiki/Standardized_Contract_APIs
Abstract
The following describes standard functions a token contract can implement.
Motivation
Those will allow dapps and wallets to handle tokens across multiple interfaces/dapps.
The most important here are, transfer, balanceOf and the Transfer event.

[ferumflex]

ERC20 это стандарт токенов. По этому стандарту контракт должен реализовать определенные функции(это называется реализовывает интерфейс). И да если переименовать transfer в transfer1, то уже не поймут что это токен. посмотрите здесь как реализованы токены
https://github.com/OpenZeppelin/zeppelin-solidity/tree/master/contracts/token

[ShDenis]

т.е. даже если токен не полностью erc20, он тоже должен иметь массив, событие и функцию под указанными именами, что бы быть распознаным.

[ferumflex]

т.е. даже если токен не полностью erc20, он тоже должен иметь массив, событие и функцию под указанными именами, что бы быть распознаным.

Я думаю да. А зачем Вам не полностью erc20, вы можете взять стандартный токен и добавить в него свой функционал. Также стандарты не стоят на месте появляются новые например https://github.com/ethereum/EIPs/issues/223

[ShDenis]

а ещё такой вопрос. токены есть смысл делать с возможностью увеличения / уменьшения общей эмиссии:

• фиксированные (без такой возможности)
• майнингом (по разным правилам)
• с пополнением  и/или снятием с общего баланса через функции для владельца
• с пополнением через покупку за эфир

от чего отталкиваться делая выбор в сторону того или иного подхода?

[ferumflex]

Обычно идут токены с фиксированной комиссией или выпуском на этапе ico(после ico кол-во фиксируется и нельзя его уже изменить никак). Общий баланс я бы сделал с помощью мультисиг кошелька. Покупка за эфир - просто нужно реализовать отдельный контракт.


Самый простой (как по мне): с фиксированной комиссией и с возможностью покупать через эфир (второй контракт).

[ShDenis]

Обычно идут токены с фиксированной комиссией или выпуском на этапе ico(после ico кол-во фиксируется и нельзя его уже изменить никак). Общий баланс я бы сделал с помощью мультисиг кошелька. Покупка за эфир - просто нужно реализовать отдельный контракт.


Самый простой (как по мне): с фиксированной комиссией и с возможностью покупать через эфир (второй контракт).

Не понял про фиксированную комиссию. Может имелось ввиду с фиксированной эмиссией?
А для чего второй контракт для покупки токена за эфир. Вроде как видел примеры, как в контракте токена делают отдельные методы для установки/чтения курса, и ещё пару для покупики/продажи токена за эфир. В чём целесообразность выносить в отдельный контракт?

[valutov]

mapping(address => uint) balances;

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

[ferumflex]

А можно ли, чтобы токен эмитировался бесконечно при выполнении определённых условий?
Допустим, на контракт кинули 1ETH - он выпустил и кинул отправителю  1 токен, кинули 100eth - контракт создал ещё 100 токенов и выслал, и так бессрочно..

можно. только думаю биржа не захочет размещать такой токен у себя

[ferumflex]

нормальная биржа вроде того же битрекса, полоникса.

ferumflex,  подскажите, как можно реализовать "права администратора" в смарт контракте?
Вот он запущен, висит себе пассивно, ждёт команд. Кто-то кинул в него эфиром, приказал сработать, контракт сделал.
А что если этот контракт должен для кого-то определённого делать больше, чем для всех?
Например, есть такой токен в единичном экземпляре, и владелец этого токена имеет эксклюзивные права на некоторые команды.,

Наследовать свой контракт от этого например.
https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/ownership/Ownable.sol
Потом можно выставлять модификатор к функции onlyOwner и только владелец контракта сможет вызвать эту функцию

[valutov]

А можно ли, чтобы токен эмитировался бесконечно при выполнении определённых условий?
Допустим, на контракт кинули 1ETH - он выпустил и кинул отправителю  1 токен, кинули 100eth - контракт создал ещё 100 токенов и выслал, и так бессрочно..

можно. только думаю биржа не захочет размещать такой токен у себя

Adshares с бесконечной эмиссией.

[ferumflex]

да owner - это конкретный адрес. При создании контракта выставляется на владельца. Есть функция transferOwnership

[ShDenis]

contract Owned {
    address public     owner;                                                   // администратор
    function Owned() {                                                          // конструктор
        owner = msg.sender;
    }
    modifier onlyOwner {
        require(msg.sender == owner);
        _;
    }
    function transferOwnership(address newOwner) onlyOwner {
        owner = newOwner;
    }
}
contract Token is Owned{                                                     

}

простой контракт для получения адреса владельца токена (владелец же будет заливать его в сеть, => msg.sender будет адресом владельца.) transferOwnership позволяет сменить владельца, но сделать это может только текущий владелец. Далее наследуем этот класс в классе токена и пользуемся модификатором onlyOwner для тех функций, которые будут разрешены только для администрации. Это запретит к ним доступ остальных.

[valutov]

owner-ов может быть несколько:

modifier onlyOwner() {
      if (msg.sender != owner1 && msg.sender != owner2) {
        throw;
      }
      _;
    }
   
    // constructor
    function Token (address _owner1, address _owner2)
    {
        owner1 = _owner1;
        owner2 = _owner2;
    }