owner-ов может быть несколько:
modifier onlyOwner() {
if (msg.sender != owner1 && msg.sender != owner2) {
throw;
}
_;
}
// constructor
function Token (address _owner1, address _owner2)
{
owner1 = _owner1;
owner2 = _owner2;
}
Topic: ETH токены (Read 1572 times)
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 для тех функций, которые будут разрешены только для администрации. Это запретит к ним доступ остальных.
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 для тех функций, которые будут разрешены только для администрации. Это запретит к ним доступ остальных.
да owner - это конкретный адрес. При создании контракта выставляется на владельца. Есть функция transferOwnership
А можно ли, чтобы токен эмитировался бесконечно при выполнении определённых условий?
Допустим, на контракт кинули 1ETH - он выпустил и кинул отправителю 1 токен, кинули 100eth - контракт создал ещё 100 токенов и выслал, и так бессрочно..
можно. только думаю биржа не захочет размещать такой токен у себяДопустим, на контракт кинули 1ETH - он выпустил и кинул отправителю 1 токен, кинули 100eth - контракт создал ещё 100 токенов и выслал, и так бессрочно..
Adshares с бесконечной эмиссией.
нормальная биржа вроде того же битрекса, полоникса.
Наследовать свой контракт от этого например.
https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/ownership/Ownable.sol
Потом можно выставлять модификатор к функции onlyOwner и только владелец контракта сможет вызвать эту функцию
ferumflex, подскажите, как можно реализовать "права администратора" в смарт контракте?
Вот он запущен, висит себе пассивно, ждёт команд. Кто-то кинул в него эфиром, приказал сработать, контракт сделал.
А что если этот контракт должен для кого-то определённого делать больше, чем для всех?
Например, есть такой токен в единичном экземпляре, и владелец этого токена имеет эксклюзивные права на некоторые команды.,
Вот он запущен, висит себе пассивно, ждёт команд. Кто-то кинул в него эфиром, приказал сработать, контракт сделал.
А что если этот контракт должен для кого-то определённого делать больше, чем для всех?
Например, есть такой токен в единичном экземпляре, и владелец этого токена имеет эксклюзивные права на некоторые команды.,
Наследовать свой контракт от этого например.
https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/ownership/Ownable.sol
Потом можно выставлять модификатор к функции onlyOwner и только владелец контракта сможет вызвать эту функцию
А можно ли, чтобы токен эмитировался бесконечно при выполнении определённых условий?
Допустим, на контракт кинули 1ETH - он выпустил и кинул отправителю 1 токен, кинули 100eth - контракт создал ещё 100 токенов и выслал, и так бессрочно..
можно. только думаю биржа не захочет размещать такой токен у себя Допустим, на контракт кинули 1ETH - он выпустил и кинул отправителю 1 токен, кинули 100eth - контракт создал ещё 100 токенов и выслал, и так бессрочно..
mapping(address => uint) balances;
Эта строчка делает из простого контракта денежный контракт. Таблица балансов - это сущность денег, она существует во всех денежных системах - в вещных, наличных, кредитных, электронных и т.д.
Эта строчка делает из простого контракта денежный контракт. Таблица балансов - это сущность денег, она существует во всех денежных системах - в вещных, наличных, кредитных, электронных и т.д.
Обычно идут токены с фиксированной комиссией или выпуском на этапе ico(после ico кол-во фиксируется и нельзя его уже изменить никак). Общий баланс я бы сделал с помощью мультисиг кошелька. Покупка за эфир - просто нужно реализовать отдельный контракт.
Самый простой (как по мне): с фиксированной комиссией и с возможностью покупать через эфир (второй контракт).
Самый простой (как по мне): с фиксированной комиссией и с возможностью покупать через эфир (второй контракт).
Не понял про фиксированную комиссию. Может имелось ввиду с фиксированной эмиссией?
А для чего второй контракт для покупки токена за эфир. Вроде как видел примеры, как в контракте токена делают отдельные методы для установки/чтения курса, и ещё пару для покупики/продажи токена за эфир. В чём целесообразность выносить в отдельный контракт?
Обычно идут токены с фиксированной комиссией или выпуском на этапе ico(после ico кол-во фиксируется и нельзя его уже изменить никак). Общий баланс я бы сделал с помощью мультисиг кошелька. Покупка за эфир - просто нужно реализовать отдельный контракт.
Самый простой (как по мне): с фиксированной комиссией и с возможностью покупать через эфир (второй контракт).
Самый простой (как по мне): с фиксированной комиссией и с возможностью покупать через эфир (второй контракт).
а ещё такой вопрос. токены есть смысл делать с возможностью увеличения / уменьшения общей эмиссии:
от чего отталкиваться делая выбор в сторону того или иного подхода?
- фиксированные (без такой возможности)
- майнингом (по разным правилам)
- с пополнением и/или снятием с общего баланса через функции для владельца
- с пополнением через покупку за эфир
от чего отталкиваться делая выбор в сторону того или иного подхода?
т.е. даже если токен не полностью erc20, он тоже должен иметь массив, событие и функцию под указанными именами, что бы быть распознаным.
Я думаю да. А зачем Вам не полностью erc20, вы можете взять стандартный токен и добавить в него свой функционал. Также стандарты не стоят на месте появляются новые например https://github.com/ethereum/EIPs/issues/223
т.е. даже если токен не полностью erc20, он тоже должен иметь массив, событие и функцию под указанными именами, что бы быть распознаным.
ERC20 это стандарт токенов. По этому стандарту контракт должен реализовать определенные функции(это называется реализовывает интерфейс). И да если переименовать transfer в transfer1, то уже не поймут что это токен. посмотрите здесь как реализованы токены
https://github.com/OpenZeppelin/zeppelin-solidity/tree/master/contracts/token
https://github.com/OpenZeppelin/zeppelin-solidity/tree/master/contracts/token
наверное сам нашёл.
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.
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.
Пытаюсь понять, почему при установке контрактов mist некоторые из них сам определяет как контракты валюты и помещает внизу основного аккаунта. В клиентах эфира есть функционал, который работает только с контрактами-токенами (кошелёк с возможностью хранить и пересылать). Интересно, как он определяет что перед ним такой контракт перед тем как его туда поместить.
если скажете зачем это может быть более конструктивный ответ.
Да это деление на токены и не токены - условное. Просто есть смарт-контракты, некоторые из которых могут выполнять функцию платежного средства, хранить балансы и реализовывать некоторый стандартный набор функций, присущий токенам. Эфиримной виртуальной машине глубоко безразлично, что перед ней - токен, или любой другой контракт. Она их никак не различает)
ссылкой не поделитесь? (мне не лень искать, просто не получилось).
т.е. есть зарезервированные имена функций и переменных, по которым токены выделяются из всех остальных контрактов? т.е. если я переименую функцию transfer в transfer1 то evm не поймёт что перед ней контракт валюты?
т.е. есть зарезервированные имена функций и переменных, по которым токены выделяются из всех остальных контрактов? т.е. если я переименую функцию transfer в transfer1 то evm не поймёт что перед ней контракт валюты?
У контракт есть определенный интерфейс(читай функции которые можно вызвать, с определенными названиями). Контракты могут вызывать другие контракты
Поясните кто знает, пожалуйста, по каким критериям эфириум клиенты распознают среди всех контрактов те, которые являются токенами. Т.е. есть какой-то контракт с прикладной логикой и есть контракт в котором могут храниться и пересылаться балансы. Почему контракт второго типа можно "использовать рядом" с основным кошельком?
Jump to: