Когда имеет смысл использовать сервер узла для приложения, использующего смарт-контракты?

Мне интересно, есть ли примеры случаев, когда было бы целесообразно использовать типичное клиент-серверное приложение Node.js, в котором узел блокчейна будет работать на сервере. На первый взгляд, это вернет проблемы централизации, связанные с доверием к серверу, если это сам сервер, на котором работает узел. Однако мне было интересно, есть ли реальные случаи, когда это было бы уместно (здесь есть вопросы людей, которые, кажется, делают это - например , это ).

Для дальнейшего разъяснения: я прочитал этот пост, в котором утверждается, что инструменты, необходимые для разработки Dapp, еще не собраны. Таким образом, мне было интересно подумать об альтернативах, которые все еще могли бы использовать функции надежности блокчейна и т. Д., Но работали в рамках клиент-серверной среды.

Ответы (5)

Я думаю, что ответ @JohnAllen не имеет для меня смысла. Наиболее распространенная практика заключается в том, чтобы интерфейсный пользовательский интерфейс DApp был реализован как приложение NodeJS, которое использует библиотеку Javascript Web3 для связи с узлом Ethereum, работающим локально, то есть на том же сервере, что и приложение NodeJS.

Здесь сервер NodeJS сам по себе не запускает узел Ethereum. (Позаботьтесь о том, чтобы различать два варианта использования термина «узел» здесь). И узел Ethereum (который может быть geth, Parity, pyethapp или любое другое клиентское программное обеспечение Ethereum), и приложение NodeJS работают на одной и той же машине. Узел Ethereum — это клиент блокчейна Ethereum, с которым он синхронизирован. Приложение NodeJS, взаимодействующее с локально работающим узлом Ethereum, фактически снижает централизацию, поскольку различным приложениям не нужно доверять какому-то конкретному удаленному узлу Ethereum. Кроме того, учетные записи всегда создаются на локальном узле, поскольку сгенерированные закрытые ключи должны оставаться на локальном компьютере. Команды для создания учетных записей и управления ими находятся вweb3.eth.personalинтерфейс, который по умолчанию включен только через IPC (межпроцессное взаимодействие), т.е. может работать только на локальном узле Ethereum.

ДОПОЛНЕНИЕ . Если внешний интерфейс DApp обслуживается приложением NodeJS, работающим на определенном сервере, это вводит некоторую централизацию. Однако до тех пор, пока DApp все еще может поддерживать состояние своей модели (используя «модель» в смысле MVC), даже если сервер NodeJS выходит из строя, и если кто-либо еще может разместить приложение NodeJS, таким образом восстанавливая «представление» MVC и предоставление доступа к серверной части (код контракта, развернутый на блокчейне), то недостаток централизации сводится к минимуму. Итак, я хочу сказать, что централизация/децентрализация не является классификацией черного или белого. Любое приложение лежит где-то на спектре. DApp можетчтобы его пользовательский интерфейс также обслуживался децентрализованно, например, я слышал, что для этого предлагались Swarm и IPFS, но я не знаю более подробной информации о том, как это будет сделано. Все зависит от конкретного случая и от того, насколько децентрализация действительно нужна.

Спасибо за разъяснения! Думаю, я понимаю, что вы имеете в виду. Было бы правильно заявить, что в приложении nodejs web3 const web3 = new Web3(new Web3.providers.HttpProvider(provider));всегда будет в коде на стороне клиента, а не в коде на стороне сервера. Это правильно?
«Наиболее распространенная практика заключается именно в том, чтобы интерфейсный интерфейс DApp был реализован как приложение NodeJS». NodeJS вообще не является интерфейсом или пользовательским интерфейсом.
Приложение NodeJS передает HTML/JS/CSS в обычный браузер, который конечные пользователи могут использовать для взаимодействия с DApp. Это внешний интерфейс DApp, а серверный — код контракта, развернутый в блокчейне. Я поищу более четкое объяснение этого.
В ответ на комментарий @mcansado выше, web3объект может быть либо в клиентском, либо в серверном коде, ссылаясь на дополнение к моему ответу. Это будут разные уровни централизации. Я думаю, что если вы используете браузер Mist, то web3объект находится только на стороне клиента.
@AjoyBhatia. У меня есть вопрос. Если я создаю свой кошелек / учетные записи на стороне клиента с помощью web3.eth.accounts, как я могу «опубликовать» их на своем локальном узле? Мой провайдер - вебсокет.
@underdog - вы должны задать это как отдельный новый вопрос, чтобы другие с таким же вопросом могли найти его с помощью поиска.

Это в основном не имеет смысла для меня, вот почему:

где узел блокчейна будет работать на сервере

Определение a blockchain node— это один из многих тысяч узлов Ethereum, которые хранят данные блокчейна и часто отвечают на запросы об этих данных.

Итак, когда у вас есть архитектура с сервером Ethereum nodeи Node.jsклиентом, что будет делать сервер Node.js?

Обычно Node.jsиспользуется для ответа на запросы со стороны сервера, выполнения логики и запросов к централизованной базе данных; но с Dapps блокчейн и web3(который является серверной или клиентской библиотекой) запрашивают данные блокчейна, а узел Ethereum отвечает запрошенными данными, которые затем возвращаются клиенту.

Вы упоминаете о хранении данных в Node.jsкомментарии. Другой вариант — хранить данные централизованно или IPFS. Вы можете хранить простой хэш или CID (идентификатор контента) в цепочке, а данные, на которые указывает хеш, в централизованной базе данных, запрашивать хэши, хранящиеся в цепочке (содержимое которых закодировано в хеше), запрашивать ваши данные. по хэшу, запустите ту же хеш-функцию для запрошенных данных, чтобы убедиться, что они одинаковы, а затем верните эти данные вашему клиенту.

Я также не уверен (отсюда и вопрос), но может быть так, что если приложение полагалось на блокчейн только для некоторых своих функций, было бы полезно иметь сервер узла для обработки остальных (что он может сделать быстро) , используя блокчейн только для важных данных. Например, вы можете хранить большие данные в централизованном хранилище и проверять целостность в блокчейне, который можно использовать при необходимости.
Да, это один из возможных шаблонов. Вы можете хранить хэш контента в блокчейне и контент в централизованных решениях. Мы почти пошли по этому пути на Disten.se, но решили использовать IPFS для хранения контента (и хранить только хеш в контракте: github.com/Distense/distense/blob/… ). Если вы храните свои данные централизованно, вы можете разрешить или сделать контент удобным rehashing, чтобы пользователи могли убедиться, что контент одинаков.
Спасибо за ответ! Мой дополнительный вопрос здесь: уверен, что сервер можно использовать для обработки подключений к централизованной БД и маршрутизации. В таком случае всякий раз, когда создается документ/запись, хэш должен быть сгенерирован на стороне клиента и отправлен в блокчейн. Учитывая это, всякий раз, когда сервер отвечал, мы могли вычислить хэш ответа и сравнить его с тем, который мы сохранили в цепочке в первую очередь. Однако ничего из этого не сработает, если узел работает на сервере. Если доступ к цепочке осуществляется через сервер, целостность хэша и т. д. может быть поставлена ​​под сомнение.
(закончились символы). В этом случае наиболее целесообразной архитектурой является клиент-сервер, использующий узел, но позволяющий клиентам одновременно запускать узел в блокчейне. Серверу не нужно было бы запускать его. Это правильно? Извините за длинные комментарии, просто хочу убедиться, что я правильно понял.
if the server is the one running the node<- Вы имеете в виду, что если geth nodeсервер и сервер Node.js работают на одном компьютере, хэш может быть скомпрометирован на пути к хранению в цепочке? Вероятно, это так, но тогда в принципе все может быть скомпрометировано. Просто помните Node.jsсервер и geth nodeэто две совершенно разные вещи .
Я имею в виду, что если к блокчейну подключен только сервер, а взаимодействие клиента с ним осуществляется только через серверную часть. И я согласен, в этом случае все было бы скомпрометировано, что и было первоначальным смыслом вопроса. Имеет ли это смысл?

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

Действительно, клиенты блокчейна на стороне клиента действительно имеют смысл только тогда, когда пользователь — человек с веб-браузером. В любой межмашинной транзакции процесс NodeJS имел бы больше смысла.

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

Что касается подписи, я определенно считаю, что безопаснее оставить ключи в руках пользователя, но вполне разумно ожидать, что некоторые службы будут подписывать от имени пользователя из процесса на стороне сервера.

Клиент блокчейна — это просто некоторое программное обеспечение, которое позволяет другому контексту получить доступ к блокчейну. В нем нет ничего, что принуждало бы его к тому или иному контексту, и если децентрализованная сеть действительно взлетит и обеспечит масштабируемость и производительность, я думаю, что более сложным вопросом станет ответ на вопрос: «В каком контексте вы бы никогда не хотели, чтобы клиент блокчейна в?"

Мне было интересно подумать об альтернативах, которые все еще могли бы использовать функции надежности блокчейна и т. Д., Но работали в рамках клиент-серверной среды.

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

Упрощенным примером гибридных децентрализованных приложений может быть децентрализованное приложение для залога токена ERC20 в обмен на ETH. Теперь кредитор и заемщик хотят обсудить процентные ставки и срок кредита. Заемщик также хочет знать, готов ли кто-нибудь предложить ему более выгодные ставки. Этот процесс обнаружения может происходить через централизованную службу без необходимости тратить ETH на газ для каждого сообщения. На этом этапе может существовать определенная цензура, когда кредиторы, предлагающие более низкие ставки, по какой-то причине вам не показываются, но вы не берете на себя никакого риска и все еще можете отказаться от процесса.

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

Таким образом, на одном этапе вы жертвуете недоверием ради скорости и стоимости, а на другом используете недоверие ради безопасности.

Конечно. Например, представьте, что у вас есть интернет-магазин (например, по продаже смартфонов), написанный на node.js. Вы хотели бы подключить его к блокчейну, чтобы контролировать, например, платежи. Таким образом, клиенты будут платить по вашему адресу через Metamask или Mist, а серверная часть вашего магазина будет подключена к узлу Ethereum (который может быть на том же сервере), чтобы проверить, был ли платеж выполнен, и продолжить выполнение заказа.

В этом случае сервер с узлом ethereum не является способом централизации приложения, это просто способ доступа к смарт-контрактам/учетным записям компьютерной системой, а не самим человеком.

Когда имеет смысл использовать сервер узла для приложения, использующего смарт-контракты?
СпросиСетьПолитика конфиденциальности1y, 0v