Внедрение интерфейса к ethereum смарт-контракту.

[ShDenis]

2. Заставлять пользователей ставить metamask (не политкорректно)

вот пример дружелюбного интерфейса пользователя, оплачивающего самостоятельно сервис:
Зашёл на сайт, залогинился в панель управления, внёс деньги на счёт при помощи VISA, начал работать с функциональностью смартконтракта за свои деньги.
Т.е. пользователь не заморачивается даже открытием собственной учётной записи в эфириуме, не только что не ставит дополнительных плагинов, или устанавливает браузер, которым он может и не пользуется. Для такой работы нужно связать UI и блокчейн со смартконтрактом без участия пользователя. Создать (подтянуть) его учётную запись в блокчейне, пополнить её эфиром по текущему курсу и выполнять операции со смарт контрактом  от её имени.
Пока не будет такого подхода, использование смарт контрактов массами будет тормозиться.

[1714092514]

1714092514

[1714092514]

1714092514

[1714092514]

1714092514

[1714092514]

1714092514

[ferumflex]

2. Заставлять пользователей ставить metamask (не политкорректно)

вот пример дружелюбного интерфейса пользователя, оплачивающего самостоятельно сервис:
Зашёл на сайт, залогинился в панель управления, внёс деньги на счёт при помощи VISA, начал работать с функциональностью смартконтракта за свои деньги.
Т.е. пользователь не заморачивается даже открытием собственной учётной записи в эфириуме, не только что не ставит дополнительных плагинов, или устанавливает браузер, которым он может и не пользуется. Для такой работы нужно связать UI и блокчейн со смартконтрактом без участия пользователя. Создать (подтянуть) его учётную запись в блокчейне, пополнить её эфиром по текущему курсу и выполнять операции со смарт контрактом  от её имени.
Пока не будет такого подхода, использование смарт контрактов массами будет тормозиться.

На текущий момент это самый лучший вариант запуска смартконтрактов на стороне пользователя.

Запускать функции смартконтракта, вносить деньги на его счет. Это может работать только если пользование сервисом платное. Тогда можно выйти хотя бы в 0. Но безопасность этого решения нулевая. Взломают сайт получат доступ ко всем кошельками пользователям и выведут все деньги с них

[ShDenis]

про небезопасность хранения ключей на хостинге на каждом углу рассказывают. Ну а почему бы не организовать работу без хранения больших сумм на таких аккаунтах, например так:
1. зарегистрировался пользователь в панели, сгенерировать ему новый кошелёк с хранимыми на сайте ключами
2. пользователю передали расценки на работу и его адрес для пополнения, уведомив о небезопасном хранении и порекомендовав минимальный перевод достаточный для работы.
2a. или вместо пункта 2 порекомендовали завести самостоятельно кошелёк на mew (или другой нормальный) и по выходу с панели - отправлять остатки с баланса аккаунта на сайте на этот, более безопасный, кошелёк, в случае работы с не маленькими суммами.
3. организовать процесс по смене кошелька пользователя на сайте в случае его взлома.

[ferumflex]

про небезопасность хранения ключей на хостинге на каждом углу рассказывают. Ну а почему бы не организовать работу без хранения больших сумм на таких

Наверное же не зря предупреждают

Мне кажется можно сделать так:
1. На сайте сгенерить сид для кошелька
2. Пользователь вводит пароль от кошелька
3. На сервере сохраняем только сид и адрес кошелька, пароль не сохраняем. Таким образом если у нас только сид без пароля сервер не может перевести деньги с кошелька.
4. Когда нужно вызвать смартконтракт спрашиваем у пользователя пароль и осуществляем траназкцию.


Минус такого: если нужно сделать транзакцию без пользователя (например по крону) то нужно писать емейлы пользователю чтобы он зашел и ввел пароль

[ShDenis]

Взлом сайта подразумевает не только получение доступа к нему и увод с него файлов с паролями или инфы из БД. Обычно при взломе на сайт заливается шелл, который что-то вытворяет от имени сайта, например, перенаправляет пользователей куда-нибудь, показывает левую рекламу, что-то ворует из оставленного пользователями. Например, пароли...

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

[criptoguruBEST]

Восхищаюсь такими людьми имеют желание прилагать минимум усилий и жить в шоколаде. З такими светлое буржуазное будущее. Один творец и мыслитель, а кругом масса хищников-прилипал. Так будем двигаться в светлое будущее та ша на горбу приживателей.   

[ferumflex]

Взлом сайта подразумевает не только получение доступа к нему и увод с него файлов с паролями или инфы из БД. Обычно при взломе на сайт заливается шелл, который что-то вытворяет от имени сайта, например, перенаправляет пользователей куда-нибудь, показывает левую рекламу, что-то ворует из оставленного пользователями. Например, пароли...

Конечно это не 100% безопасность. Но это убережет большое кол-во пользователей от потерь в случае взлома(Вы же будете мониторить ситуацию, правда?). Это намного лучше чем хранить приватные ключи на сайте. Тогда в случае взлома, все пользователи потеряют все.

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

Кто это должен делать? Давайте разберем все возможные варианты:
1. Это делает скрипт на сайте(автоматически). В этом случае приватный ключ хранится на сайте в каком либо виде, и его можно получить и при взломе все выведут. Небезопасно

2. Это делает админ(в ручном режиме). Ну тогда все транзакции должен подтверждать админ вручную с помощью метамаска(например). Это безопасно но не удобно.


Вообщем есть две крайности,
1. Все автоматизировано, деньги сами переводятся туда сюда, смартконтракты сами запускаются. Вас взломали - деньги вы потеряли.
2. Все подтверждается вручную.

[Jaath]

Такой вопрос. Я ленивый разработчик, и хочу малыми телодвижениями на свой сайт у хостера в сети добавить страничку с интерфейсом для тестирования своего смарт контракта эфириума. У меня есть желание использовать для этих целей какой-нибудь сторонний, доступный в интернете блокчейн через RPC и чей-нибудь сторонний web3.js. Т.е. хостинг шаред, и не хочу ничего ставить через администраторов, даже web3.js. (Это же просто .js библиотека, которую я могу с любого доступного адреса в интернете подгрузить через <script... на страничке, правильно?). Блокчейн, я так понимаю, я и не поставлю, без покупки целого выделенного сервера. Сколько он там весит уже. Methamask не рассматриваю. Разве что их ноду с RPC. Т.е. интересует следующая инфа:
1. Можно ли вообще такое провернуть
2. Какова вообще архитектура запускаемых больших проектов (т.е. где обычно хранятся у них noda с блокчейном, web3.js и сам сайт)
3. Какова вообще архитектура запускаемых малых проектов (маленький сайт, но с подключением) (т.е. где обычно хранятся у них noda с блокчейном, web3.js и сам сайт)
4. Какова вообще архитектура запускаемых проектов без подключения к блокчейну, просто на лэндинге и с отправкой всех на mist для переводов (т.е. где обычно хранятся у них noda с блокчейном, web3.js и сам сайт)
5. Если такое можно провернуть, то где взять адреса ноды с RPC и web3.js, которые мне помогут сосредоточиться на тестировании интерфейса а не на запуске всей этой архитектуры.
6. Можно ли подключиться таким образом к локальной (домашней) ноде на testrpc (со страницы сайта на сервере хостинга)?

Рекомендую обратить внимание на проект TokenGo, у них планируется свой вебинтерфейс для создания смарт контрактов, а так же можно будет прикручивать через API все, что пожелаете. Может данное решение в будущем Вам пригодится.

[ShDenis]

Восхищаюсь такими людьми имеют желание прилагать минимум усилий и жить в шоколаде. З такими светлое буржуазное будущее. Один творец и мыслитель, а кругом масса хищников-прилипал. Так будем двигаться в светлое будущее та ша на горбу приживателей.   

лень двигатель прогресса.

[ShDenis]

Взлом сайта подразумевает не только получение доступа к нему и увод с него файлов с паролями или инфы из БД. Обычно при взломе на сайт заливается шелл, который что-то вытворяет от имени сайта, например, перенаправляет пользователей куда-нибудь, показывает левую рекламу, что-то ворует из оставленного пользователями. Например, пароли...

Конечно это не 100% безопасность. Но это убережет большое кол-во пользователей от потерь в случае взлома(Вы же будете мониторить ситуацию, правда?). Это намного лучше чем хранить приватные ключи на сайте. Тогда в случае взлома, все пользователи потеряют все.

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

Кто это должен делать? Давайте разберем все возможные варианты:
1. Это делает скрипт на сайте(автоматически). В этом случае приватный ключ хранится на сайте в каком либо виде, и его можно получить и при взломе все выведут. Небезопасно

2. Это делает админ(в ручном режиме). Ну тогда все транзакции должен подтверждать админ вручную с помощью метамаска(например). Это безопасно но не удобно.


Вообщем есть две крайности,
1. Все автоматизировано, деньги сами переводятся туда сюда, смартконтракты сами запускаются. Вас взломали - деньги вы потеряли.
2. Все подтверждается вручную.

3. это может делать сам пользователь, добровольно, получив предварительное уведомление о небезопаснсоти хранения больших сумм на аккаунте.

[bomj]

5. Если такое можно провернуть, то где взять адреса ноды с RPC и web3.js, которые мне помогут сосредоточиться на тестировании интерфейса а не на запуске всей этой архитектуры.

Так же интересуюсь подобным вопросом.
Появились ли у вас интересные находки?

[bomj]

const MAINET_RPC_URL = 'https://mainnet.infura.io/metamask';
const ROPSTEN_RPC_URL = 'https://ropsten.infura.io/metamask';
const KOVAN_RPC_URL = 'https://kovan.infura.io/metamask';
const RINKEBY_RPC_URL = 'https://rinkeby.infura.io/metamask';


var ipaddr_prov_rinkeby = "http://35.185.16.215:8545";
var ipaddr_prov_main = "http://104.197.142.219:17348";