I
Или что то такое. Но даже если так, то когда она будет генерить event, может не хватить газа у транзакции тк промежуточный контракт думаю что там просто адрес и пошлет газ для обычного перевода
Size: a a a
2021 March 31
RM
Почему ресив? Чужой смарт контракт не узнвет же об этой функции. Вроде есть function fallback ?
Я думал это в вашем контракте можно добавить
I
А что если парсить дата на предмет совпадения наших депозитных адресов и руками уже зачислять такие странные транзакции
RM
А нельзя делать депозиты через один контракт ?
Который потом дальше отправляет эфир или токены на другие адреса
Который потом дальше отправляет эфир или токены на другие адреса
I
А нельзя делать депозиты через один контракт ?
Который потом дальше отправляет эфир или токены на другие адреса
Который потом дальше отправляет эфир или токены на другие адреса
Как мы определим кому начислить эфир в системе? Мы же не знаем какому юзеру какой адрес отправителя соответсвует
RM
Можно подробней как это у Вас работает по шагам ?
RM
Можно через mapping связать адрес пользователя и адрес депозитного кошелька
I
У нас сервис (типа биржа). У каждого юзера свой адрес для депозита. Мы зарание их генерируем много. Мы не знаем с какого ажреса придет эфир. Как прмшел- зачисляем в системе в кабинет ему эфир
RM
А зачем много адресов ?
Почему нельзя использовать один глобальный депозит контракт и в нем в fallback функции обновлять данные по msg.sender и делать Event когда пользователь отправляет эфир
Почему нельзя использовать один глобальный депозит контракт и в нем в fallback функции обновлять данные по msg.sender и делать Event когда пользователь отправляет эфир
I
А зачем много адресов ?
Почему нельзя использовать один глобальный депозит контракт и в нем в fallback функции обновлять данные по msg.sender и делать Event когда пользователь отправляет эфир
Почему нельзя использовать один глобальный депозит контракт и в нем в fallback функции обновлять данные по msg.sender и делать Event когда пользователь отправляет эфир
пришел эфир на контракт - а кто его прислал? какой юзер? какой id у него в базе?
RM
Зачем id ?
msg.sender
msg.sender
RM
Потом обновлять виртуальный баланс на контракте, кто сколько положил и вывел
RM
receive {
balance[msg.sender] = balance[msg.sender].add(msg.value)
emit event
}
withdraw (amount) {
require (balance[msg.sender] >= amount)
// Можно добавить cut коммиссии сервиса
balance[msg.sender] = balance[msg.sender].sub(amount)
(msg.sender). transfer(amount)
}RM
receive {
balance[msg.sender] = balance[msg.sender].add(msg.value)
emit event
}
withdraw (amount) {
require (balance[msg.sender] >= amount)
// Можно добавить cut коммиссии сервиса
balance[msg.sender] = balance[msg.sender].sub(amount)
(msg.sender). transfer(amount)
}С телефона не удобно писать, но смысл понятен.
Такой контракт может обслуживать тысячи пользователей и не надо генерировать адреса и усложнять сервер
Такой контракт может обслуживать тысячи пользователей и не надо генерировать адреса и усложнять сервер
RM
receive {
balance[msg.sender] = balance[msg.sender].add(msg.value)
emit event
}
withdraw (amount) {
require (balance[msg.sender] >= amount)
// Можно добавить cut коммиссии сервиса
balance[msg.sender] = balance[msg.sender].sub(amount)
(msg.sender). transfer(amount)
}Как дополнительная фишка можно юзать balance для кабинета
RM
Тогда вообще не надо слушать события, все будет работать автоматически и более надежно
IK
Когда следующий сбор в аля-клабхаусе, надеюсь прямо тут, в телеграме?
В четверг. Это извечный спор где проводить. Но пока у нас в КХ хотя бы новые люди появляются вне сообщества. Можете провести голосование тут если кто то принципиально против.
IK
По поводу формата общения по четвергам. Я предлагаю брать список тем, примерно на 1.5 часа. На каждую тему выделять несколько минут (например кто то модерирует) на обсуждение. После обсуждение всех тем свободное общение. Как вам идея? Темы можно брать как общие из децентр мира, так и сугубо по недельным техническим репортам эфира, типа Ethereum weekly.
IK
Если возражений нет давайте завтра пробовать.