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

[ShDenis]

Такой вопрос. Я ленивый разработчик, и хочу малыми телодвижениями на свой сайт у хостера в сети добавить страничку с интерфейсом для тестирования своего смарт контракта эфириума. У меня есть желание использовать для этих целей какой-нибудь сторонний, доступный в интернете блокчейн через 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 (со страницы сайта на сервере хостинга)?

[1714913023]

1714913023

[1714913023]

1714913023

[nagor2]

Такой вопрос. Я ленивый разработчик, и хочу малыми телодвижениями на свой сайт у хостера в сети добавить страничку с интерфейсом для тестирования своего смарт контракта эфириума. У меня есть желание использовать для этих целей какой-нибудь сторонний, доступный в интернете блокчейн через 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 (со страницы сайта на сервере хостинга)?

1. Да, можно.
2. Зависит.
3. Зависит.
4. Не понял вопроса.
5. Поставить либо поискать публичные халявные.
6. Да, можно. Нужно только иметь публичный адрес.

Для установки ноды вы можете воспользоваться любой машиной, у которой есть публичный IP и достаточно места на жестком диске, после чего прикрутить к своей странице web3.js (можно его скачать к себе на хостинг или грузить по урлу откуда угодно, это уже вам решать)

Дальше пишете в своем скрипте адрес ноды с включеным RPC сервером, указываете порт и поехали.

Можно ноду не ставить, а поискать в интернете публичные. Наверняка такие найдутся.

Если что - обращайтесь, помогу)

Дмитрий
+7 (913) 714 0888 (WhatsApp)
nagor@academ.org

[ShDenis]

не подкинете адреса доступных в сети web3.js и ноды)
публичный IP - это статический?
Тот IP который видит тот же самый yandex.xml (подписав его так: Ваш текущий IP) - подойдёт для текущего доступа к локальной ноде на testrpc?

[nagor2]

не подкинете адреса доступных в сети web3.js и ноды)
публичный IP - это статический?
Тот IP который видит тот же самый yandex.xml (подписав его так: Ваш текущий IP) - подойдёт для текущего доступа к локальной ноде на testrpc?

https://github.com/ethereum/web3.js/tree/develop/dist - тут несколько различных вариантов библиотеки.
Если вам достаточно простого функционала, там можно облегченные версии библиотеки подключать.

Подключать можно прямо так, по урлу https://github.com/ethereum/web3.js/blob/develop/dist/web3.js или скачать ее себе на хостинг.

Публичный - это не статический. Статический вы себе сами на компе можете прописать любой. Но его с внешней сети не видно будет. Это будет айпишник в сети вашего провайдера, а то и того хуже - внутренний айпишник вашей собственной локалки, если на входе у вас стоит какой-нибудь маршрутизатор. Тогда нужно будет через него какой-нибудь порт пробрасывать на вашу домашнюю машину, а у вашего провайдера попросить публичный айпишник. Обычно это стоит дополнительно примерно бакс в месяц. А может и бесплатно дадут. Все) Потом ставите себе ноду домой, запускаете ее с возможностью подключения как к RPC серверу и можете подключаться хоть откуда. Хоть с вашего хостинга.

На хостинге в вашем скрипте пишите web3 = new Web3(new Web3.providers.HttpProvider("http://127.0.0.1:8545"));

Только вместо 127.0.0.1 пишете ваш адрес, а вместо 8545 пишите порт, который будете пробрасывать с маршрутизатора. Все. Дальше можете посылать любые команды ноде вашей, которые разрешили, запуская ее. Можно там, например, майнинг запретить, или что-нибудь еще.

Чур мне плюс в репутацию за ответ)

[nagor2]

https://ethereum.stackexchange.com/questions/517/are-there-any-public-free-nodes-to-connect-a-dapp-front-end

Вот тут товарищ ищет тоже, что и вы. Ему отвечают, что халявных таких нод нету. Есть только интерфейсы, типа прокси запросов к нодам. Указывают, какие API есть. Но они не поддерживают RPC запросы и web3.js к ним не подключится. Нужно использовать их собственные либы.

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

[poddubnuy]

не подкинете адреса доступных в сети web3.js и ноды)
публичный IP - это статический?
Тот IP который видит тот же самый yandex.xml (подписав его так: Ваш текущий IP) - подойдёт для текущего доступа к локальной ноде на testrpc?

Крупные провайдеры используют динамические серые IP. Динамические- это при каждой новой сессии меняются, а серые - 10.0.0.0 до 10.255.255.255 и 172.16.0.0 до 172.31.255.255 то есть в сети интернет таких адресов не может быть, они есть только в локалке, А с сетью общаются через NAT. После которого в сети у тебя появляется реальный IP. (но понятно динамический) Публичный статический IP- покупаешь у провайдера. А вообще рекомендую использовать DNS имя, Оно не меняется (пока за него платишь) А публичный статический IP даже при оплате всегда могут отобрать, ты сам можешь поменять провайдера, и т.д. и т.п. (правда не все сервисы поддерживают привязку к DNS.)

[ShDenis]

не подкинете адреса доступных в сети web3.js и ноды)
публичный IP - это статический?
Тот IP который видит тот же самый yandex.xml (подписав его так: Ваш текущий IP) - подойдёт для текущего доступа к локальной ноде на testrpc?

Крупные провайдеры используют динамические серые IP. Динамические- это при каждой новой сессии меняются, а серые - 10.0.0.0 до 10.255.255.255 и 172.16.0.0 до 172.31.255.255 то есть в сети интернет таких адресов не может быть, они есть только в локалке, А с сетью общаются через NAT. После которого в сети у тебя появляется реальный IP. (но понятно динамический) Публичный статический IP- покупаешь у провайдера. А вообще рекомендую использовать DNS имя, Оно не меняется (пока за него платишь) А публичный статический IP даже при оплате всегда могут отобрать, ты сам можешь поменять провайдера, и т.д. и т.п. (правда не все сервисы поддерживают привязку к DNS.)

т.е. я вполне могу поднять локальную RPC ноду, узнав этот свой реальный ip, который получился после NAT (потом гляну, что это такое вообще) подпихнуть его в web3.js и спокойно тестировать свой скрипт на хостинге, пока не перегружу свой модем, я правильно понимаю? После перезагрузки я получу новый реальный IP, поменяю его в исходниках и далее буду спокойно тестироваться. И таким образом для отладки я обойдусь без покупки реального статического белого IP.

Порт в этом случае указывать тот с которым стартанула RPC нода (там вроде можно задавать)?

[ShDenis]

попробовал сделать как написал, получил такое:
Ошибка карты кода: request failed with status 404
URL ресурса: http://xxxxxxxxxxxxxxxx.com/sc-js/web3-light.js
URL карты кода: web3-light.js.map
ReferenceError: Web3 is not defined
 

[nagor2]

Чуть позже напишу пример кода

[ShDenis]

спасибо, было бы неплохо, несмотря на то, что есть в интернете немало примеров.

меня ещё сама архитектура решения "немного" путает. web3.js это клиентская или клиент-серверная библиотека (набор библиотек). Т.е. Что должно лежать на хостинге рядом с сайтом и подключаться на html страничку вот так: <scrip ... src=""></script>  - достаточно ли одного файла из вот этого набора: https://github.com/ethereum/web3.js/tree/develop/dist или им нужны ещё какие-нибудь зависимости?

Путаюсь, потому как есть установка web3.js через npm install web3 и доступен целый набор скриптов этого web3 на github (https://github.com/ethereum/web3.js), что явно больше чем просто один файл скрипта для включения его в страничку html. Плюс можно общаться через web3 через консоль напрямую с запущенным geth. Получается, что на ноде должна работать серверная часть библиотеки web3. Т.е. её нужно устанавливать на локальном компьютере для работы в браузере загруженной странички html с внедрённой клиентской частью. В добавок ко всему этому недопониманию, при установке (npm install web3) под windows  валится куча ошибок gyp error... Получается, сейчас, похоже что, есть какая-то web3 установленная вместе с geth, но похоже, что она не работает если запускается testrpc вместо geth.

[verudza]

Услугу выделенной ноды можно заказать
https://infura.io/

[ShDenis]

оригинально, спасибо. но для полноты понимания вопроса работы интерфейса с нодой, хотелось бы на своей ноде тренироваться.

[nagor2]

написал вкратце, как это делается, но статейка еще не прошла модерацию. Ждемс.

[ShDenis]

оченьждёмс. а пока, не знаете как вот такое побороть:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:8545/. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

архитектура стандартная:
локальный web сервер apache
html+js+web3
geth -dev

[nagor2]

https://habrahabr.ru/post/344270/

[ferumflex]

Я всем реклмендую фреймворк truffle. В нем есть шаблон который включает в себя простенький контракт токена и веб интерфейс взаимодействия с ним. Это все работает на webpack. Сам такое делал, работает хорошо

[ShDenis]

всем больше спасибо, но ребята, проблема у меня, как у обособленного самообучающегося разработчика не в том, что бы найти пример кода на js, который подключается к ноде и вызывает функции смарт контрактов, а проблема в правильном построении архитектуры и налаживании рабочего процесса. Так, для тестирования, я пробовал подключиться со своего сайта на сервере хостера - проблема с доступом к локальной ноде. Запустил сервер apache (на виртуалке) и стреляю с localhost получаю ошибку Cross-Origin Request Blocked... Пошёл в контору которая решила заняться смарт контрактами профессионально у меня в районе, что бы опыта у них поднабраться, они спрашивают, как я представляю работу со мной, если у меня уже есть работа((((((

[ShDenis]

так, вот это получилось победить: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:8545/
теперь могу тестировать на локальном компьютере, причём и с локальным web сервером и с обычного хостинга. Теперь вторая часть вопроса:

Какая наиболее типовая архитектура при разворачивании децентрализованного приложения в продакшене? Вижу несколько вариантов:
1. Выделенный сервер с полной установкой ноды (дорого)
2. Заставлять пользователей ставить metamask (не политкорректно)
3. Вариант verudza - заказать услугу выделенной ноды (это похоже на новое решение, не думаю что многие им пользовались)
4. Поднять ноду на отдельном компьютере со статичным сетевым IP и держать его включенным всегда (сомневаюсь что так вообще кто-нибудь делает)
5. Другой, не ведомый мне вариант

[ShDenis]

подниму тему - как обычно разворачивают готовые приложения с вёб интерфейсом на базе смарт контрактов?

[ferumflex]

подниму тему - как обычно разворачивают готовые приложения с вёб интерфейсом на базе смарт контрактов?

1. Заливают смартконтракт в сеть.
2. Делают html/js которое работает с MetaMask

Вот пример такого шаблона https://github.com/ConsenSys/truffle-webpack-demo

Вот я сам делал для одного хакатона(демо). Должен быть активен плагин метамаск и выбрана ropsten сеть

https://worlaxgraphics.github.io/woroom-hackathon/dest/