Author

Topic: Проектирование сервисов на ETH (Read 958 times)

full member
Activity: 256
Merit: 102
преимущество смарт контрактов в том что Вы можете посмотреть их код и точно знать как они работают. Банальный пример реализация лотереи на смарт контрактах.  Второй пример это как раз проведения ICO на смарт контрактах. В целом нужно больше примеров внедрения, чтобы они получили популярность
full member
Activity: 313
Merit: 103
Вопрос хороший. А как иначе нести смарт контракты в массы? Или  спрошу иначе - а для чего вообще нужны смарт контракты, если у них нет преимуществ перед массовым пользователем?
full member
Activity: 256
Merit: 102
В целом я понимаю Вас. Если Вы хотите сделать сервис, который предоставляет какой то функционал, и для расчетов использовать свой токен, то либо пользователь сам покупает токены, ставит метамаск и сам все контролирует. Либо это делаете Вы за него, он только пополняет счет в долларах либо другой валюте, получает токены на аккаунт и Вы списываете их за услуги. Ну вообщем второй способ ничем не отличается от большинства сервисов. Они делают тоже самое. Нужно ли Вам вообще в этом случае связываться со смартконтрактами?
full member
Activity: 313
Merit: 103
Сделайте сервис, который принимает ваши токены и делает что Вам надо. Есть плагин MetaMask для Chrome с помощью которого можно подтверждать транзакции. А какие сервисы Вы имеете ввиду, которые выживают без хтмл фронтенда? Большинство сервисов ограничиваются покупкой токенов, а чтобы купить токены хтмл фронтенд не нужен, достаточно знать адрес кошелька куда послать деньги чтобы в ответ получить токены.

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

С другой стороны, токен это инструмент расчёта, используемый в сервисе. Для него важно наличие пользователей с криптокошельками. Он должен свободно покупаться и продаваться всеми желающими. И вот получается, что часть пользователей могут зарегистрировать свои кошельки самостоятельно и будут иметь на них балансы. Другая, более массовая часть пользователей, будет иметь только аккаунты на фронтенде сайта. Я так понимаю, что мне самому придётся для них создавать аккаунты с моим токеном, привязывая криптокошелёк к аккаунту и пополнять в соответствие с заявленым на сайте курсом к фиату (в соответствие с их платежами)? А для тех, кто с кошельками просто предоставить сервис привязки кошелька к аккаунту на сайте? Вдальнейшем, при обращени к услуге, пользователи будут делать это через html фронтенд, а в бакграунде будет отрабатывать смарт контракт, который будет проводить расчёты с привязанными в учётных записях этих пользоватей адресами кошельков этих пользователей, запрашивая у них пароли, так получается?

п.с. как то много слов получилось...
full member
Activity: 313
Merit: 103
full member
Activity: 256
Merit: 102
Сделайте сервис, который принимает ваши токены и делает что Вам надо. Есть плагин MetaMask для Chrome с помощью которого можно подтверждать транзакции. А какие сервисы Вы имеете ввиду, которые выживают без хтмл фронтенда? Большинство сервисов ограничиваются покупкой токенов, а чтобы купить токены хтмл фронтенд не нужен, достаточно знать адрес кошелька куда послать деньги чтобы в ответ получить токены.
full member
Activity: 313
Merit: 103
1. можно то да, это понятно, но делают ли так серьёзные проекты? По-моему, запускать функции с кошелька, миста и прочих клиентов - это не сервис, это издевательство над пользователями и полный крест на бизнес идее. таким пользоваться никто не будет.
2. добыть бы где-нибудь описание реализованного проекта по схеме: беру фиат, организую новый аккаунт в эфире, ложу на него токены пропорционально фиата. Чтобы не изобретать велосипед.
3. как упростить пункт 2, если у человека есть возможность самому купить эфир, или мой токен.
full member
Activity: 256
Merit: 102
1. Html фронтенд это просто удобный способ для запуска функций контракта. А так можно и с кошелька их запускать или с MEW
2. В начале нужно купить эфир и потому уже по старинке. Есть сервисы которые берут фиат и меняют на крипту
3. Не понял вопрос
full member
Activity: 313
Merit: 103
Появилось желание потренироваться в создании сервиса на смарт контракте(ах) и вот есть вопрос по взаимосвязи пользователей, которые ни разу не знают ни о каких криптовалютах, а с контрактом на моём собственном токене и подавно. Про привязку web интерфейса к контратам немного уже знаю, сайты делаю профессионально, php не проблема. Но вот сама архитектура решений с этими токенами в основе не ясна... Вобщем есть пару вопросов:

1. как выживают смарт контракты серьёзных сервисов без html фронтенда? (подозреваю что никак и что они просто есть бесполезный бэкенд, но не уверен)
2. если у человека деньги на карточке в рублях а мой сервис работает на моих крипто токенах эфира - как обычно (и как правильно) в таких случаях организовывается взаимодействие, чтобы пользователь мог расплатиться карточкой за услугу на моём "умном сервисе". Или, быть может, у кого есть пример организации такого взаимодействия?
3. Если я хочу организовать помимо оплаты сервиса в рублях возможность пользоваться смартконтрактом (или правильнее сервисом, с фронтендом) для тех, кто знаком с криптовалютой и обзаведётся моим токеном без проблем, то таких людей пускать в общий поток клиентов или взаимодействие с ними организовывается иначе?
Jump to: