SB
Как только у тебя все токены уникальные, проблема исчезает, потому что по каждому токену можно будет понять, кто его выпустил
Посмотрел
Вроде подходит erc721Enumerable, спасибо!
Вроде подходит erc721Enumerable, спасибо!
Size: a a a
2020 February 20
k
Дешевле?
Это бесплатно
k
В данном случае shell выступает в роли "web браузера" и дает возможность получить доступ к предоставляемым услугам
k
А возможность хранить данные и компилить исходники - бонус
k
+ утилиты(wget,nano,vim,git и тд)
ЕЛ
Народ, а есть блокчейн с блоками по требованию? Когда есть транзакция, тогда и блок формируется.
ЕЛ
Хранить данные - самое оно же.
ph
Ябучие блохчейны
ЕЛ
Ябучие блохчейны
Они самые
ЕЛ
Можно, конечно, ipfs для этого прикрутить
SB
Как только у тебя все токены уникальные, проблема исчезает, потому что по каждому токену можно будет понять, кто его выпустил
Такой вопрос теперь
Ты бы посоветовал под каждый эвент делать новый контракт erc721, или использовал бы один контракт для всех билетов всех эвентов?
Ты бы посоветовал под каждый эвент делать новый контракт erc721, или использовал бы один контракт для всех билетов всех эвентов?
@
тебе надо как-то решить проблему первиночного нахождения контракта на блокчейне. если у тебя один контракт то его адрес можно забить в клиент.
если несколько, то надо делать контракт который будет знать об контрактах отдельных эвентов.
зато второй вариант даёт гораздо больше гибкости.
если несколько, то надо делать контракт который будет знать об контрактах отдельных эвентов.
зато второй вариант даёт гораздо больше гибкости.
@
в одном эвенте у тебя билеты можно переписать на другого. в другом нельзя. в третьем это можно сделать не ранее чем за сутки. а в чётвертом вообще можно бабки вернуть за сутки
SB
тебе надо как-то решить проблему первиночного нахождения контракта на блокчейне. если у тебя один контракт то его адрес можно забить в клиент.
если несколько, то надо делать контракт который будет знать об контрактах отдельных эвентов.
зато второй вариант даёт гораздо больше гибкости.
если несколько, то надо делать контракт который будет знать об контрактах отдельных эвентов.
зато второй вариант даёт гораздо больше гибкости.
можно использовать фабрику как контракт, который знает об контрактах отдельных эвентов
SB
в одном эвенте у тебя билеты можно переписать на другого. в другом нельзя. в третьем это можно сделать не ранее чем за сутки. а в чётвертом вообще можно бабки вернуть за сутки
меня больше смущает возможная коллизия ticketID :)
в смысле, что если все будут писать в один контракт, то придется эвентам как-то договариваться об использовании tokenID
а если разделены, то там все по порядку можно делать
в смысле, что если все будут писать в один контракт, то придется эвентам как-то договариваться об использовании tokenID
а если разделены, то там все по порядку можно делать
YB
Ну контракт может считать айди билета как конкатенацию айди эвента и айди билета, в чем проблема.
YB
Короче, не видно ни проблемы, ни решения. Что то, что другое, суть одно и то же топологически.
KP
меня больше смущает возможная коллизия ticketID :)
в смысле, что если все будут писать в один контракт, то придется эвентам как-то договариваться об использовании tokenID
а если разделены, то там все по порядку можно делать
в смысле, что если все будут писать в один контракт, то придется эвентам как-то договариваться об использовании tokenID
а если разделены, то там все по порядку можно делать
Ну пиши в билет
Но вообще если у тебя контракт генерит ticketID, то коллизий быть не должно — на то он и блокчейн чтобы транзакции линеаризировать надёжненько
msg.sender и потом айди хоть какой.Но вообще если у тебя контракт генерит ticketID, то коллизий быть не должно — на то он и блокчейн чтобы транзакции линеаризировать надёжненько
KP
Я бы всё в одном контракте бы делал.