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";
Topic: Внедрение интерфейса к ethereum смарт-контракту. (Read 849 times)
5. Если такое можно провернуть, то где взять адреса ноды с RPC и web3.js, которые мне помогут сосредоточиться на тестировании интерфейса а не на запуске всей этой архитектуры.
Так же интересуюсь подобным вопросом.
Появились ли у вас интересные находки?
Взлом сайта подразумевает не только получение доступа к нему и увод с него файлов с паролями или инфы из БД. Обычно при взломе на сайт заливается шелл, который что-то вытворяет от имени сайта, например, перенаправляет пользователей куда-нибудь, показывает левую рекламу, что-то ворует из оставленного пользователями. Например, пароли...
Конечно это не 100% безопасность. Но это убережет большое кол-во пользователей от потерь в случае взлома(Вы же будете мониторить ситуацию, правда?). Это намного лучше чем хранить приватные ключи на сайте. Тогда в случае взлома, все пользователи потеряют все.Безопаснее (но дороже за счёт комиссий на переводы) уводить деньги с потенциально небезопасных аккаунтов на сайте на свои личные аккаунты) на время, когда сайт не нужен. Если же речь о небольших суммах, то можно и не уводить.
Кто это должен делать? Давайте разберем все возможные варианты:1. Это делает скрипт на сайте(автоматически). В этом случае приватный ключ хранится на сайте в каком либо виде, и его можно получить и при взломе все выведут. Небезопасно
2. Это делает админ(в ручном режиме). Ну тогда все транзакции должен подтверждать админ вручную с помощью метамаска(например). Это безопасно но не удобно.
Вообщем есть две крайности,
1. Все автоматизировано, деньги сами переводятся туда сюда, смартконтракты сами запускаются. Вас взломали - деньги вы потеряли.
2. Все подтверждается вручную.
3. это может делать сам пользователь, добровольно, получив предварительное уведомление о небезопаснсоти хранения больших сумм на аккаунте.
Восхищаюсь такими людьми имеют желание прилагать минимум усилий и жить в шоколаде. З такими светлое буржуазное будущее. Один творец и мыслитель, а кругом масса хищников-прилипал. Так будем двигаться в светлое будущее та ша на горбу приживателей.
лень двигатель прогресса.
Взлом сайта подразумевает не только получение доступа к нему и увод с него файлов с паролями или инфы из БД. Обычно при взломе на сайт заливается шелл, который что-то вытворяет от имени сайта, например, перенаправляет пользователей куда-нибудь, показывает левую рекламу, что-то ворует из оставленного пользователями. Например, пароли...
Конечно это не 100% безопасность. Но это убережет большое кол-во пользователей от потерь в случае взлома(Вы же будете мониторить ситуацию, правда?). Это намного лучше чем хранить приватные ключи на сайте. Тогда в случае взлома, все пользователи потеряют все.Безопаснее (но дороже за счёт комиссий на переводы) уводить деньги с потенциально небезопасных аккаунтов на сайте на свои личные аккаунты) на время, когда сайт не нужен. Если же речь о небольших суммах, то можно и не уводить.
Кто это должен делать? Давайте разберем все возможные варианты:1. Это делает скрипт на сайте(автоматически). В этом случае приватный ключ хранится на сайте в каком либо виде, и его можно получить и при взломе все выведут. Небезопасно
2. Это делает админ(в ручном режиме). Ну тогда все транзакции должен подтверждать админ вручную с помощью метамаска(например). Это безопасно но не удобно.
Вообщем есть две крайности,
1. Все автоматизировано, деньги сами переводятся туда сюда, смартконтракты сами запускаются. Вас взломали - деньги вы потеряли.
2. Все подтверждается вручную.
Восхищаюсь такими людьми имеют желание прилагать минимум усилий и жить в шоколаде. З такими светлое буржуазное будущее. Один творец и мыслитель, а кругом масса хищников-прилипал. Так будем двигаться в светлое будущее та ша на горбу приживателей.
Взлом сайта подразумевает не только получение доступа к нему и увод с него файлов с паролями или инфы из БД. Обычно при взломе на сайт заливается шелл, который что-то вытворяет от имени сайта, например, перенаправляет пользователей куда-нибудь, показывает левую рекламу, что-то ворует из оставленного пользователями. Например, пароли...
Безопаснее (но дороже за счёт комиссий на переводы) уводить деньги с потенциально небезопасных аккаунтов на сайте на свои личные аккаунты) на время, когда сайт не нужен. Если же речь о небольших суммах, то можно и не уводить.
Безопаснее (но дороже за счёт комиссий на переводы) уводить деньги с потенциально небезопасных аккаунтов на сайте на свои личные аккаунты) на время, когда сайт не нужен. Если же речь о небольших суммах, то можно и не уводить.
про небезопасность хранения ключей на хостинге на каждом углу рассказывают. Ну а почему бы не организовать работу без хранения больших сумм на таких
Наверное же не зря предупреждают 
Мне кажется можно сделать так:
1. На сайте сгенерить сид для кошелька
2. Пользователь вводит пароль от кошелька
3. На сервере сохраняем только сид и адрес кошелька, пароль не сохраняем. Таким образом если у нас только сид без пароля сервер не может перевести деньги с кошелька.
4. Когда нужно вызвать смартконтракт спрашиваем у пользователя пароль и осуществляем траназкцию.
Минус такого: если нужно сделать транзакцию без пользователя (например по крону) то нужно писать емейлы пользователю чтобы он зашел и ввел пароль
про небезопасность хранения ключей на хостинге на каждом углу рассказывают. Ну а почему бы не организовать работу без хранения больших сумм на таких аккаунтах, например так:
1. зарегистрировался пользователь в панели, сгенерировать ему новый кошелёк с хранимыми на сайте ключами
2. пользователю передали расценки на работу и его адрес для пополнения, уведомив о небезопасном хранении и порекомендовав минимальный перевод достаточный для работы.
2a. или вместо пункта 2 порекомендовали завести самостоятельно кошелёк на mew (или другой нормальный) и по выходу с панели - отправлять остатки с баланса аккаунта на сайте на этот, более безопасный, кошелёк, в случае работы с не маленькими суммами.
3. организовать процесс по смене кошелька пользователя на сайте в случае его взлома.
1. зарегистрировался пользователь в панели, сгенерировать ему новый кошелёк с хранимыми на сайте ключами
2. пользователю передали расценки на работу и его адрес для пополнения, уведомив о небезопасном хранении и порекомендовав минимальный перевод достаточный для работы.
2a. или вместо пункта 2 порекомендовали завести самостоятельно кошелёк на mew (или другой нормальный) и по выходу с панели - отправлять остатки с баланса аккаунта на сайте на этот, более безопасный, кошелёк, в случае работы с не маленькими суммами.
3. организовать процесс по смене кошелька пользователя на сайте в случае его взлома.
2. Заставлять пользователей ставить metamask (не политкорректно)
вот пример дружелюбного интерфейса пользователя, оплачивающего самостоятельно сервис:
Зашёл на сайт, залогинился в панель управления, внёс деньги на счёт при помощи VISA, начал работать с функциональностью смартконтракта за свои деньги.
Т.е. пользователь не заморачивается даже открытием собственной учётной записи в эфириуме, не только что не ставит дополнительных плагинов, или устанавливает браузер, которым он может и не пользуется. Для такой работы нужно связать UI и блокчейн со смартконтрактом без участия пользователя. Создать (подтянуть) его учётную запись в блокчейне, пополнить её эфиром по текущему курсу и выполнять операции со смарт контрактом от её имени.
Пока не будет такого подхода, использование смарт контрактов массами будет тормозиться.
вот пример дружелюбного интерфейса пользователя, оплачивающего самостоятельно сервис:
Зашёл на сайт, залогинился в панель управления, внёс деньги на счёт при помощи VISA, начал работать с функциональностью смартконтракта за свои деньги.
Т.е. пользователь не заморачивается даже открытием собственной учётной записи в эфириуме, не только что не ставит дополнительных плагинов, или устанавливает браузер, которым он может и не пользуется. Для такой работы нужно связать UI и блокчейн со смартконтрактом без участия пользователя. Создать (подтянуть) его учётную запись в блокчейне, пополнить её эфиром по текущему курсу и выполнять операции со смарт контрактом от её имени.
Пока не будет такого подхода, использование смарт контрактов массами будет тормозиться.
На текущий момент это самый лучший вариант запуска смартконтрактов на стороне пользователя.
Запускать функции смартконтракта, вносить деньги на его счет. Это может работать только если пользование сервисом платное. Тогда можно выйти хотя бы в 0. Но безопасность этого решения нулевая. Взломают сайт получат доступ ко всем кошельками пользователям и выведут все деньги с них
2. Заставлять пользователей ставить metamask (не политкорректно)
вот пример дружелюбного интерфейса пользователя, оплачивающего самостоятельно сервис:
Зашёл на сайт, залогинился в панель управления, внёс деньги на счёт при помощи VISA, начал работать с функциональностью смартконтракта за свои деньги.
Т.е. пользователь не заморачивается даже открытием собственной учётной записи в эфириуме, не только что не ставит дополнительных плагинов, или устанавливает браузер, которым он может и не пользуется. Для такой работы нужно связать UI и блокчейн со смартконтрактом без участия пользователя. Создать (подтянуть) его учётную запись в блокчейне, пополнить её эфиром по текущему курсу и выполнять операции со смарт контрактом от её имени.
Пока не будет такого подхода, использование смарт контрактов массами будет тормозиться.
вот пример дружелюбного интерфейса пользователя, оплачивающего самостоятельно сервис:
Зашёл на сайт, залогинился в панель управления, внёс деньги на счёт при помощи VISA, начал работать с функциональностью смартконтракта за свои деньги.
Т.е. пользователь не заморачивается даже открытием собственной учётной записи в эфириуме, не только что не ставит дополнительных плагинов, или устанавливает браузер, которым он может и не пользуется. Для такой работы нужно связать UI и блокчейн со смартконтрактом без участия пользователя. Создать (подтянуть) его учётную запись в блокчейне, пополнить её эфиром по текущему курсу и выполнять операции со смарт контрактом от её имени.
Пока не будет такого подхода, использование смарт контрактов массами будет тормозиться.
подниму тему - как обычно разворачивают готовые приложения с вёб интерфейсом на базе смарт контрактов?
1. Заливают смартконтракт в сеть.
2. Делают html/js которое работает с MetaMask
Вот пример такого шаблона https://github.com/ConsenSys/truffle-webpack-demo
Вот я сам делал для одного хакатона(демо). Должен быть активен плагин метамаск и выбрана ropsten сеть
https://worlaxgraphics.github.io/woroom-hackathon/dest/
подниму тему - как обычно разворачивают готовые приложения с вёб интерфейсом на базе смарт контрактов?
так, вот это получилось победить: 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. Другой, не ведомый мне вариант
теперь могу тестировать на локальном компьютере, причём и с локальным web сервером и с обычного хостинга. Теперь вторая часть вопроса:
Какая наиболее типовая архитектура при разворачивании децентрализованного приложения в продакшене? Вижу несколько вариантов:
1. Выделенный сервер с полной установкой ноды (дорого)
2. Заставлять пользователей ставить metamask (не политкорректно)
3. Вариант verudza - заказать услугу выделенной ноды (это похоже на новое решение, не думаю что многие им пользовались)
4. Поднять ноду на отдельном компьютере со статичным сетевым IP и держать его включенным всегда (сомневаюсь что так вообще кто-нибудь делает)
5. Другой, не ведомый мне вариант
всем больше спасибо, но ребята, проблема у меня, как у обособленного самообучающегося разработчика не в том, что бы найти пример кода на js, который подключается к ноде и вызывает функции смарт контрактов, а проблема в правильном построении архитектуры и налаживании рабочего процесса. Так, для тестирования, я пробовал подключиться со своего сайта на сервере хостера - проблема с доступом к локальной ноде. Запустил сервер apache (на виртуалке) и стреляю с localhost получаю ошибку Cross-Origin Request Blocked... Пошёл в контору которая решила заняться смарт контрактами профессионально у меня в районе, что бы опыта у них поднабраться, они спрашивают, как я представляю работу со мной, если у меня уже есть работа((((((
Я всем реклмендую фреймворк truffle. В нем есть шаблон который включает в себя простенький контракт токена и веб интерфейс взаимодействия с ним. Это все работает на webpack. Сам такое делал, работает хорошо
оченьждёмс. а пока, не знаете как вот такое побороть:
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
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
написал вкратце, как это делается, но статейка еще не прошла модерацию. Ждемс.
оригинально, спасибо. но для полноты понимания вопроса работы интерфейса с нодой, хотелось бы на своей ноде тренироваться.
Услугу выделенной ноды можно заказать
https://infura.io/
https://infura.io/
спасибо, было бы неплохо, несмотря на то, что есть в интернете немало примеров.
меня ещё сама архитектура решения "немного" путает. web3.js это клиентская или клиент-серверная библиотека (набор библиотек). Т.е. Что должно лежать на хостинге рядом с сайтом и подключаться на html страничку вот так: - достаточно ли одного файла из вот этого набора: 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.
меня ещё сама архитектура решения "немного" путает. web3.js это клиентская или клиент-серверная библиотека (набор библиотек). Т.е. Что должно лежать на хостинге рядом с сайтом и подключаться на html страничку вот так:
Путаюсь, потому как есть установка 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.
Чуть позже напишу пример кода
попробовал сделать как написал, получил такое:
Ошибка карты кода: request failed with status 404
URL ресурса: http://xxxxxxxxxxxxxxxx.com/sc-js/web3-light.js
URL карты кода: web3-light.js.map
ReferenceError: Web3 is not defined
Ошибка карты кода: request failed with status 404
URL ресурса: http://xxxxxxxxxxxxxxxx.com/sc-js/web3-light.js
URL карты кода: web3-light.js.map
ReferenceError: Web3 is not defined
не подкинете адреса доступных в сети 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.) публичный IP - это статический?
Тот IP который видит тот же самый yandex.xml (подписав его так: Ваш текущий IP) - подойдёт для текущего доступа к локальной ноде на testrpc?
т.е. я вполне могу поднять локальную RPC ноду, узнав этот свой реальный ip, который получился после NAT (потом гляну, что это такое вообще) подпихнуть его в web3.js и спокойно тестировать свой скрипт на хостинге, пока не перегружу свой модем, я правильно понимаю? После перезагрузки я получу новый реальный IP, поменяю его в исходниках и далее буду спокойно тестироваться. И таким образом для отладки я обойдусь без покупки реального статического белого IP.
Порт в этом случае указывать тот с которым стартанула RPC нода (там вроде можно задавать)?
не подкинете адреса доступных в сети 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.) публичный IP - это статический?
Тот IP который видит тот же самый yandex.xml (подписав его так: Ваш текущий IP) - подойдёт для текущего доступа к локальной ноде на testrpc?
https://ethereum.stackexchange.com/questions/517/are-there-any-public-free-nodes-to-connect-a-dapp-front-end
Вот тут товарищ ищет тоже, что и вы. Ему отвечают, что халявных таких нод нету. Есть только интерфейсы, типа прокси запросов к нодам. Указывают, какие API есть. Но они не поддерживают RPC запросы и web3.js к ним не подключится. Нужно использовать их собственные либы.
Отвечающие указали какой-то rpc сервер, но он принимает только подписанные транзакции, то есть ваши клиенты должны будут ставить себе еще одну примочку к браузеру, чтобы подписывать транзакции у себя, а потом отправлять их вам.
Вот тут товарищ ищет тоже, что и вы. Ему отвечают, что халявных таких нод нету. Есть только интерфейсы, типа прокси запросов к нодам. Указывают, какие API есть. Но они не поддерживают RPC запросы и web3.js к ним не подключится. Нужно использовать их собственные либы.
Отвечающие указали какой-то rpc сервер, но он принимает только подписанные транзакции, то есть ваши клиенты должны будут ставить себе еще одну примочку к браузеру, чтобы подписывать транзакции у себя, а потом отправлять их вам.
не подкинете адреса доступных в сети web3.js и ноды)
публичный IP - это статический?
Тот IP который видит тот же самый yandex.xml (подписав его так: Ваш текущий IP) - подойдёт для текущего доступа к локальной ноде на testrpc?
публичный 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 пишите порт, который будете пробрасывать с маршрутизатора. Все. Дальше можете посылать любые команды ноде вашей, которые разрешили, запуская ее. Можно там, например, майнинг запретить, или что-нибудь еще.
Чур мне плюс в репутацию за ответ)
не подкинете адреса доступных в сети web3.js и ноды)
публичный IP - это статический?
Тот IP который видит тот же самый yandex.xml (подписав его так: Ваш текущий IP) - подойдёт для текущего доступа к локальной ноде на testrpc?
публичный IP - это статический?
Тот IP который видит тот же самый yandex.xml (подписав его так: Ваш текущий IP) - подойдёт для текущего доступа к локальной ноде на testrpc?
Такой вопрос. Я ленивый разработчик, и хочу малыми телодвижениями на свой сайт у хостера в сети добавить страничку с интерфейсом для тестирования своего смарт контракта эфириума. У меня есть желание использовать для этих целей какой-нибудь сторонний, доступный в интернете блокчейн через RPC и чей-нибудь сторонний web3.js. Т.е. хостинг шаред, и не хочу ничего ставить через администраторов, даже web3.js. (Это же просто .js библиотека, которую я могу с любого доступного адреса в интернете подгрузить через Блокчейн, я так понимаю, я и не поставлю, без покупки целого выделенного сервера. Сколько он там весит уже. Methamask не рассматриваю. Разве что их ноду с RPC. Т.е. интересует следующая инфа:
1. Можно ли вообще такое провернуть
2. Какова вообще архитектура запускаемых больших проектов (т.е. где обычно хранятся у них noda с блокчейном, web3.js и сам сайт)
3. Какова вообще архитектура запускаемых малых проектов (маленький сайт, но с подключением) (т.е. где обычно хранятся у них noda с блокчейном, web3.js и сам сайт)
4. Какова вообще архитектура запускаемых проектов без подключения к блокчейну, просто на лэндинге и с отправкой всех на mist для переводов (т.е. где обычно хранятся у них noda с блокчейном, web3.js и сам сайт)
5. Если такое можно провернуть, то где взять адреса ноды с RPC и web3.js, которые мне помогут сосредоточиться на тестировании интерфейса а не на запуске всей этой архитектуры.
6. Можно ли подключиться таким образом к локальной (домашней) ноде на testrpc (со страницы сайта на сервере хостинга)?
1. Можно ли вообще такое провернуть
2. Какова вообще архитектура запускаемых больших проектов (т.е. где обычно хранятся у них noda с блокчейном, web3.js и сам сайт)
3. Какова вообще архитектура запускаемых малых проектов (маленький сайт, но с подключением) (т.е. где обычно хранятся у них noda с блокчейном, web3.js и сам сайт)
4. Какова вообще архитектура запускаемых проектов без подключения к блокчейну, просто на лэндинге и с отправкой всех на mist для переводов (т.е. где обычно хранятся у них noda с блокчейном, web3.js и сам сайт)
5. Если такое можно провернуть, то где взять адреса ноды с RPC и web3.js, которые мне помогут сосредоточиться на тестировании интерфейса а не на запуске всей этой архитектуры.
6. Можно ли подключиться таким образом к локальной (домашней) ноде на testrpc (со страницы сайта на сервере хостинга)?
Jump to: